Re: Autopkgtest for falcon
Hi, Andreas,
على الأربعاء 18 كانون الثاني 2017 05:33، كتب Andreas Tille:
> Hi again,
>
> On Wed, Jan 18, 2017 at 11:34:44AM +0100, Andreas Tille wrote:
>> Hi Afif,
>>
>> On Wed, Jan 18, 2017 at 01:33:55AM -0800, Afif Elghraoui wrote:
>>>
>>> falcon's new release fails autopkgtest, which I have not gotten around to
>>> debugging, so I have not uploaded it.
>>
>> I'll have a look and let you know.
>
> As promised I had a look. I'm usually providing the test that is runned
> as autopkgtest also as user runnable script. To see what I mean I
> commited a change to Git and hope you like it. For me this has two
> advantages:
>
> 1. Users can easily reproduce what is tested by just doing
> sh /usr/share/doc/falcon/run-unit-test
> 2. The developer can run this script on the local machine sparing
> the overhead of creating the virtual environment which is a
> quicker approach to finding errors inside the test suite (even
> no final guarantee that the test will succeede in the sandbox).
>
> I hope you like this change.
I'm fine with the idea, but it's not something I would do. This seems to
me like something that is better implemented within autopkgtest itself
(like for tests that don't specify the "breaks-testbed" restriction) or
something rather than on a per-package basis. I generally prefer to keep
the packaging simple, which is why I haven't manually set hardening
flags on every individual package (dpkg-buildflags could globally set it
if it is appropriate), why I don't change default compression methods
without good reason, and why I don't put the dummy watch line for
upstreams that don't tag releases (maybe there is a possibility to have
uscan not fail if there is no watch line to process) and such.
I won't revert this kind of change-- I just won't initiate it or go out
of my way to maintain it.
> With this script I get:
>
> ...
> 2017-01-18 13:21:44,348[ERROR] Task Node(1-preads_ovl/m_00001) failed with exit-code=256
> 2017-01-18 13:21:44,348[INFO] recently_satisfied: set([])
> 2017-01-18 13:21:44,348[INFO] Num satisfied in this iteration: 0
> 2017-01-18 13:21:44,348[INFO] Num still unsatisfied: 2
> 2017-01-18 13:21:44,348[ERROR] Some tasks are recently_done but not satisfied: set([Node(1-preads_ovl/m_00001)])
> 2017-01-18 13:21:44,348[ERROR] ready: set([])
> submitted: set([])
> Traceback (most recent call last):
> File "/usr/lib/falcon/bin/fc_run.py", line 4, in <module>
> __import__('pkg_resources').run_script('falcon-kit==0.7', 'fc_run.py')
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 719, in run_script
> self.require(requires)[0].run_script(script_name, ns)
> File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 1504, in run_script
> exec(code, namespace, namespace)
> File "/usr/lib/falcon/pylib/falcon_kit-0.7-py2.7-linux-x86_64.egg/EGG-INFO/scripts/fc_run.py", line 5, in <module>
> main(sys.argv)
> File "/usr/lib/falcon/pylib/falcon_kit-0.7-py2.7-linux-x86_64.egg/falcon_kit/mains/run1.py", line 461, in main
> main1(argv[0], args.config, args.logger)
> File "/usr/lib/falcon/pylib/falcon_kit-0.7-py2.7-linux-x86_64.egg/falcon_kit/mains/run1.py", line 136, in main1
> input_fofn_plf=input_fofn_plf,
> File "/usr/lib/falcon/pylib/falcon_kit-0.7-py2.7-linux-x86_64.egg/falcon_kit/mains/run1.py", line 414, in run
> wf.refreshTargets(exitOnFailure=exitOnFailure)
> File "/usr/lib/falcon/pylib/pypeflow-1.0.0-py2.7.egg/pypeflow/simple_pwatcher_bridge.py", line 226, in refreshTargets
> self._refreshTargets(updateFreq, exitOnFailure)
> File "/usr/lib/falcon/pylib/pypeflow-1.0.0-py2.7.egg/pypeflow/simple_pwatcher_bridge.py", line 297, in _refreshTargets
> failures, len(unsatg)))
> Exception: We had 1 failures. 2 tasks remain unsatisfied.
> makefile:4: recipe for target 'run-synth0' failed
> make[1]: *** [run-synth0] Error 1
> make[1]: Leaving directory '/tmp/falcon-test.0Rc93v'
> makefile:21: recipe for target 'full-test' failed
>
>
> Is this the same issue you was talking about? I admit I have no good
> idea how to fix it but just want to make sure that we are in sync here.
>
That looks about right. Don't worry about this one. I've requested
upstream (a while ago) to document how to debug failed runs and they've
accepted my bug report. I may go back and ask about this specific case,
though ours is not a supported installation.
Thanks and regards
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
Reply to: