Re: New version of fast5 does not build
Hi Afif, On Thu, Jan 19, 2017 at 09:13:20PM -0800, Afif Elghraoui wrote: > > See https://github.com/thegenemyers/DALIGNER/issues/35 I've added a comment. BTW, I could need similar help for contacting authors about freeing their code: https://lists.debian.org/debian-med/2016/09/msg00068.html https://lists.debian.org/debian-med/2016/07/msg00083.html Any reader of our list might step in here and write to the authors showing that I'm not the only one who is interested. Kind regards Andreas. -- http://fam-tille.de
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 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: 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
Re: New version of fast5 does not build
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). > > 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. > > > > 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. > python-avro's new release is a release candidate, which I do not consider > suitable for Stable. OK. > python-cobra's new release has no user-visible changes and I do not consider > it worth uploading. I believe I documented this in the UNRELEASED changelog. OK. > 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. > 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. > 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. Kind regards Andreas. > >[1] > >https://udd.debian.org/dmd/?email1=debian-med-packag...@lists.alioth.debian.org=html -- http://fam-tille.de
Re: New version of fast5 does not build
Hi, Andreas,
On الأربعاء 18 كانون الثاني 2017 00:50, Andreas Tille wrote:
Hi Afif,
I'm currently trying to update all our packages to latest upstream
(according to developers dashboard[1]) since January 25 might be the
last one to get new versions inzo next stable release. I was stumbling
upon fast5 which you commited to Git. The Build fails with:
I: pybuild base:184: python2.7 setup.py clean
/usr/lib/x86_64-linux-gnu: could not find Boost Python library file; use
BOOST_DIR or BOOST_LIB_DIR/BOOST_PYTHON_LIB
E: pybuild pybuild:276: clean: plugin distutils failed with: exit code=1:
python2.7 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 2.7 --dir python returned
exit code 13
debian/rules:26: recipe for target 'override_dh_auto_clean' failed
make[1]: *** [override_dh_auto_clean] Error 25
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.
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.
falcon's new release fails autopkgtest, which I have not gotten around
to debugging, so I have not uploaded it.
python-avro's new release is a release candidate, which I do not
consider suitable for Stable.
python-cobra's new release has no user-visible changes and I do not
consider it worth uploading. I believe I documented this in the
UNRELEASED changelog.
pbbam needs a patch to be reworked. This was a patch that I forwarded
upstream, but was ignored, and the files were modified differently.
sprai has a new release, but I wanted to include the autopkgtest with it
in the next upload.
daligner/dazzdb/dascrubber probably have new upstream snapshots that
need to be packaged.
I only really have time to work on these on weekends and I worked on
some non-DebianMed packages last weekend. 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.
[1]
https://udd.debian.org/dmd/?email1=debian-med-packag...@lists.alioth.debian.org=html
regards
Afif
--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
