Re: Autopkgtest for falcon
Hi, Andreas, على الخميس 19 كانون الثاني 2017 05:08، كتب Andreas Tille: > On Thu, Jan 19, 2017 at 12:44:31AM -0800, Afif Elghraoui wrote: [...] >> >> 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 fully agree here. > >> 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), > > Seems you can read my mind: I was always wondering why hardening=+all > would not be the default and individual maintainers should take some > means if the package does not build with this setting. I admit I took > the wimpy approach to not ask for this since if you ask for such > features it takes some time to discuss and just copying a single line > to the rules file takes less time in the very moment ... > I think there were two additional flags and one of them has already become default. I was planning to ignore the lintian infos until they went away on their ownl. >> why I don't change default compression methods >> without good reason, > > I think there is no need for this any more (if I get your question > right). > I meant about the upstream tarballs (like when repacking, I use default options unless the package is very big and can benefit from changing it) >> 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 admit when inventing a new watch file version (version=4) it would > have been cheap to define extra metadata to express the upstream status > properly instead of doing dirty tricks like I'm doing currently. The > thing is if you have this kind of "good ideas" you should be up to also > implement these - at least a proof of concept. I did so with the > Files-Excluded feature which I wanted so urgently that I was up to > spending my time on it. I think I have my turn on time investment in > this very topic but I was hesitating with the watch file thingy. For me > its now important to keep my developers dashboard free from noise which > I can approach by some copy-n-pasting - I don't mind whether its a hack > or a field ... as long as I do not need to spend extra time on it. > I guess this uscan exit code doesn't bother since I'm generally checking my own DDPO rather than the developer's dashboard (though I agree the latter is more concise for looking at all Debian Med packages). >> I won't revert this kind of change-- I just won't initiate it or go out >> of my way to maintain it. > > That's perfectly fine. Great > >>> ... >>> 2017-01-18 13:21:44,348[ERROR] Task Node(1-preads_ovl/m_1) failed with >>> exit-code=256 [...] >>> 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. > > But possibly not for Stretch any more, right? (Which is fine - just > asking whether I can ignore this and focus on other things.) > I might be able to get it figured out in time, but you can feel free to ignore it. regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: New version of fast5 does not build
على الخميس 19 كانون الثاني 2017 05:14، كتب Andreas Tille: > On Wed, Jan 18, 2017 at 11:59:36PM -0800, Afif Elghraoui wrote: >>> daligner/dazzdb/dascrubber probably have new upstream snapshots that need to be packaged. >>> >>> OK, these do not create any singnal on my dashboard so I'll leave this >>> for now. >> >> That is because upstream doesn't make releases. I've just updated them now. > > Yes, I know. BTW, I have usccessfully requested release tags for > pbbarcode. So I personally will open an issue for any Github project > I'm stumbling upon since it has no tags. I have heard about that these > developers are a bit stubborn about tags but I'll try my own luch > anyway. > See https://github.com/thegenemyers/DALIGNER/issues/35 I did not get any response to this ticket until I tried pinging the author via email. It was still not a positive response. I don't think I've ever managed to convince anybody of making release tags, so I've somewhat given up. >>> Sure. That's for most of us the normal situation. I did not intended >>> to create any pressure - just wanted to coordinate a bit. We do what we >>> manage to do and if some newer version is not ready than be it so. I >>> just wanted to prevent that I might have used some spare cycles to >>> polish old software if some new might have pending tasks I could have >>> easily done. >>> >> >> In case you are referring to pbbarcode, that upstream has deprecated some >> software while people are still relying on it, so I don't consider this a >> waste. > > Yes, upstream of pbbarcode confirmed its deprecated but its now tagged > and thus does not create any noise any more in our QA tools. BTW, I > restricted the test suite to some tests since the second part took > *incredibly* long (so long that I even stopped the process on my > laptop). I'm not sure whether this is "*intended operation* or whether > this is a sign of a failure. > I remember there was this test that took a while, but I'd go do something else while I ran it. > But no, I was not refering to any specific package in my paragraph above. > Ok >> pbh5tools is in a similar situation. > > I left it untouched since it did not raised any signal in the QA tools. > It is in good shape. I just pointed out that this is another one that upstream will tell you is deprecated. regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Re: New version of beagle
Hi Dylan, On Thu, Jan 19, 2017 at 04:54:59PM +0100, Dylan wrote: > Yes, uscan reports a new version of beagle (27Jul16.86a) but it is not > a true new version, it is the same version already in Debian > (4.1~160727-86a+dfsg-1). > Upstream uses a bad versioning scheme based on dates which "breaks" > our system and seems not be interested in changing it by a more > standard versioning scheme. > So, I converted the version by something more standard (maybe not > optimal, I understand). I think your conversion makes some sense. There would even be a chance to uversionmangle s/Jan/01/;s/Feb/02/; ... s/(\d\d)(\d\d)(\d\d)/$3$2$1/ to get a sortable date out of this. But before we start inventing really crazy things in d/watch I wrote another e-mail to upstream (list in CC). > Maybe, I should disable the watch file using something like that [1] > but the current watch file permits me to quickly/regularly check if > new upstream version is released. I'd really love to get watch files working and hope that upstream will consider sane versions after a second mail. Honestly, what does it tell about the code itself if upstream has no idea how to do proper versioning? > Any suggestions to avoid to create some noise in the future with this > watch file ? :-) > [1] https://people.debian.org/~eriberto/#fake-packages This would be the very last means. Lets wait for upstream response and keep on thinking what to do next. Thanks for the clarification Andreas. -- http://fam-tille.de
Please consider a more convenient versioning of your download tarball
Hi Brian, I'm writing you on behalf of the Debian Med team which is a team inside Debian with the objective to package free software in life sciences and medicine for official Debian. On our so called biology tasks page we are also listing beagle[1] since it is also included in Debian. As you see on this page[1] it seems that there is a new upstream version available but this is actually not really the case. The reason for this "new upstream version" warning is that you are using a quite unconvenient versioning system for your download archive. That's pretty ... uhmmm, I have no idea how to describe - amongst our more than 500 packages there is no project where you can not sensibly sort download archives alphabethically. So I would suggest you could change the current beagle.27Jul16.86a.src.zip into something like beagle.160727.86a.src.zip or something like this since your date format does not help in sorting and leads to confusion on users side (probably not only for Debian users). Thanks for your cooperation Andreas. [1] https://blends.debian.org/med/tasks/bio#beagle -- http://fam-tille.de
New version of beagle
Hi Bob, uscan reports a new version of beagle. Do you think you will manage to update it until this weekend or do you have good reasons to the current version? If its just time constraints at your side please raise a signal here. Kind regards Andreas. -- http://fam-tille.de
Re: New version of fast5 does not build
On Wed, Jan 18, 2017 at 11:59:36PM -0800, Afif Elghraoui wrote: > >OK, seems like something we want to do later (I'd prefer a separate > >package for a separate download tarball since in the end this might be > >easier to maintain - but nothing to do here for the moment whatever we > >do). > > > > I agree. Multi-orig tarballs are a pain in the neck to maintain, at least > with gbp. Yes. > >Seems you know better than me whet to do here as well. > > > >>daligner/dazzdb/dascrubber probably have new upstream snapshots that need to > >>be packaged. > > > >OK, these do not create any singnal on my dashboard so I'll leave this > >for now. > > That is because upstream doesn't make releases. I've just updated them now. Yes, I know. BTW, I have usccessfully requested release tags for pbbarcode. So I personally will open an issue for any Github project I'm stumbling upon since it has no tags. I have heard about that these developers are a bit stubborn about tags but I'll try my own luch anyway. > >Sure. That's for most of us the normal situation. I did not intended > >to create any pressure - just wanted to coordinate a bit. We do what we > >manage to do and if some newer version is not ready than be it so. I > >just wanted to prevent that I might have used some spare cycles to > >polish old software if some new might have pending tasks I could have > >easily done. > > > > In case you are referring to pbbarcode, that upstream has deprecated some > software while people are still relying on it, so I don't consider this a > waste. Yes, upstream of pbbarcode confirmed its deprecated but its now tagged and thus does not create any noise any more in our QA tools. BTW, I restricted the test suite to some tests since the second part took *incredibly* long (so long that I even stopped the process on my laptop). I'm not sure whether this is "*intended operation* or whether this is a sign of a failure. But no, I was not refering to any specific package in my paragraph above. > pbh5tools is in a similar situation. I left it untouched since it did not raised any signal in the QA tools. Kind regards Andreas. -- http://fam-tille.de
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_1) 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_1)])
> 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
> __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
> 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
Re: New version of fast5 does not build
Hi, Andreas, On الأربعاء 18 كانون الثاني 2017 02:34, Andreas Tille wrote: Hi Afif, On Wed, Jan 18, 2017 at 01:33:55AM -0800, Afif Elghraoui wrote: I guess it should be not to hard to fix the clean target but I'm wondering whether you might intend to continue on this. This new version, if I remember correctly, has made the example program into a production program, but that now has an additional dependency which is not packaged. I think this is the only difference from the current release. To feasibly handle this, I think we would need to make a multi-orig tarball with this new dependency (since it is from the same upstream and I believe no other program uses it anyway) and put this program into a new binary package. OK, seems like something we want to do later (I'd prefer a separate package for a separate download tarball since in the end this might be easier to maintain - but nothing to do here for the moment whatever we do). I agree. Multi-orig tarballs are a pain in the neck to maintain, at least with gbp. It would be also nice to know which of the packages you are Uploader will be uploaded in the next couple of days and where you would like to get help. [...] pbbam needs a patch to be reworked. This was a patch that I forwarded upstream, but was ignored, and the files were modified differently. SO I'll leave it for you. sprai has a new release, but I wanted to include the autopkgtest with it in the next upload. Seems you know better than me whet to do here as well. daligner/dazzdb/dascrubber probably have new upstream snapshots that need to be packaged. OK, these do not create any singnal on my dashboard so I'll leave this for now. That is because upstream doesn't make releases. I've just updated them now. I only really have time to work on these on weekends and I worked on some non-DebianMed packages last weekend. Sure. That's for most of us the normal situation. I did not intended to create any pressure - just wanted to coordinate a bit. We do what we manage to do and if some newer version is not ready than be it so. I just wanted to prevent that I might have used some spare cycles to polish old software if some new might have pending tasks I could have easily done. In case you are referring to pbbarcode, that upstream has deprecated some software while people are still relying on it, so I don't consider this a waste. pbh5tools is in a similar situation. I will try to work on the onces I consider worth uploading this weekend. I was considering working on sprai a little earlier tonight, but that didn't happen. That's fine. Just ping here if you need assistance. Thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
