Re: [Git][med-team/python-pauvre][master] patch for build test failing to start
Hi Étienne, I'mm CCing Debian Med list due to possibly wider interest On Sat, Apr 25, 2020 at 07:52:06PM +0200, Étienne Mollier wrote: > Andreas Tille, on 2020-04-25 19:07:10 +0200: > > Amusingly, I was beginning to write down an email on this topic; > but your message showed up first. :) :-) > > thanks a lot for tackling this. Just a remark. I think its more > > flexible if you set PYTHONPATH via > > > > override_dh_auto_test: > > ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) > > PYTHONPATH=$(CURDIR)/... > > endif > > > > The hardcoded path might lead to failures if you intend to re-use > > that code as autopkgtest or so. > > Thanks for the tip! I was unsure how to put that properly, but > this looks definitely like a more robust approach; I just > implemented that. Nice. :-) > Not sure what to do about the subsequent > call to `python3 ../../../pauvre_main.py ...`, but it works at t > time. I was wondering about the test script calling some executable named pauvre which does not exist. May be the most elegant solution would rather to add a wrapper script (say debian/bin/pauvre) add PATH=$(CURDIR)/debian/bin ... and simply use this wrapper which does not require any patch of the code. > This kind of looks like something to bring up to > upstream, existing testing assumes the command is in the PATH > already, but in this testing context I fear it might be error > prone: it could easily be empty or, worse, point to the > "outdated" operating system version. My suggestion above should work around this - but pointing this out to upstream makes sense. > Otherwise, I reached a point where I'm under the impression that > the test suite might depend on external data. When running the > test, I hit the following error: > > FileNotFoundError: [Errno 2] File > b'/build/python-pauvre-0.1924/.pybuild/cpython3_3.8/build/pauvre/tests/testdata/gff_files/Bf201706.gff' > does not exist > > But, there is no such .gff file in the whole directory. There > are a few references to other repositories in various files, for > more testing, but haven't located such files yet. I'd check upstream Git repository. If you fail to find it there its probably a good idea to ask upstream. > > Please keep on the good work. Its really appreciated > > You're welcome, I try my best, Thanks again Andreas. -- http://fam-tille.de
Re: RFS : new upstream version of jebl2
On Sat, Apr 25, 2020 at 02:49:03PM +0200, Pierre Gruet wrote: > > done would be helpful. I've pushed latest upstream but did not > > found the time to update the old patches to the new version. > > Getting this extremely outdated package updated would be great. > > Thanks for the suggestion; I have begun working on it. Really great! > Updating the patches > is done, but I am facing build issues that you had already seen one year and > a half ago, related to some header file H5private.h. Do you remember about > that issue? Otherwise no worry, I will investigate :-) My guess ist that the name "*private" means that this is a private interface that should *not* be used. :-( > Afterwards, I will be interested in packaging the dependencies of snpeff as > you suggested yesterday. I will fill ITP bugs when I am ready for beginning > this. That would be extremely helpful as I said. > Enjoy your week-end --- at home, as for me, I'm afraid :-( , I need to admit I'm living at such a beatiful place - lots of tourists would enjoy it if they could travel here. So its not really hard to spent the weekend here and at walking distance surroundings. But anybody who contributed to Debian Med is invited to visit me here once traveling becomes possible again. ;-) See you Andreas. -- http://fam-tille.de
Re: [covid-19] Reviving tensorflow packaging effort (Was: Missing dependancies for streamlit)
On Sat, Apr 25, 2020, 12:36 Mo Zhou wrote: > Hi Tille, > > Is there any COVID-19 package using pytorch blocked due to its absense? > > A good news is that I've managed to strip the whole third_party/ > directory of src:pytorch, and started to forward my patches to upstream[1]. > When all my modifications entered the upstream repo, I'll be quite > confident that our src:pytorch package can enter the archive without > any (annoying) embedded sources [2]. > > What I'm doing now is to wait for the upstream to merge my commits, and > for the ftp-masters to accept my NEW dependency packages. > > In that sense, I'd like to take the COVID-19 shortcut to pass NEW > quickly, if any COVID-19 related package needs pytorch. > > --- According to my status page > https://qa.debian.org/developer.php?login=lumin > these are the NEW dependency packages: > > fp16 > fxdiv > gloo > onnx > psimd > pthreadpool > Go ahead and add them to https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/NEW-Requests > I'll start to re-debianize src:pytorch from scratch when all of my > commits had been upstreamed. > Any reason to not add the removed files/folders to the Files-Excluded stanza of debian/copyright and repack the source while you wait? > --- all of my on-going work are publically available: > https://salsa.debian.org/deeplearning-team > https://github.com/cdluminate/pytorch (messy, not rebased yet) > The links to my PRs can be found on [1] > > [1] https://github.com/pytorch/pytorch/issues/14699 > [2] Finally, we will have a modern deep learning framework in the > archive. It's better than having nothing even if I'm working on the > cpu-only (free) version. > > On Wed, Apr 08, 2020 at 10:06:12AM +0200, Andreas Tille wrote: > > Hi Mo, > > > > On Wed, Apr 08, 2020 at 02:46:06AM +, Mo Zhou wrote: > > > On Tue, Apr 07, 2020 at 11:49:07AM +0200, Andreas Tille wrote: > > > > On Tue, Apr 07, 2020 at 08:56:45AM +0100, Rebecca N. Palmer wrote: > > > > > tensorflow 1.10 was packaged in experimental, but with reduced > performance, > > > > > and was removed because this was considered not worth it: > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935769 > > > > > > > > Ah I simply forgot this. Thanks for refreshing my mind. > > > > > > After that I tried to refresh the packaging and uploaded tensorflow 2.0 > > > to the NEW queue. The ftp-master complained about the embedded snapshot > > > version of Eigen3. Ftp-masters are not convinced even if I said > > > tensorflow FTBFS against the version shipped in our archive, and it > > > could waste lots of my time and energy to patch the related code. > > > > I can understand your feeling. I've re-read the discussion[1] about > > including eigen3 into the tensorflow source. The most promising > > statement was given in > > > > > https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-March/079169.html > > > >Sean Whitton spwhitton at spwhitton.name > >Tue Mar 3 04:04:52 GMT 2020 > > > >Rejected per your request, but from my point of view this discussion > is > >not over -- Policy 4.13 says that packages *should* not use > convenience > >copies of code, not that they *must* not. > > > >Thank you for all your work on uploading useful ML packages. > > > > At first: Thanks also from me! > > > > >From my point of view that is not a lost case so we should really try > > again. > > > > > I was so angry at that time so I deleted my name from the maintainers > > > and wrote the git message "I'm dropping this burden.". > > > > Well, sometimes personal feelings are dominating our actions. I hope we > > could form some real team around this to spread the technical as well as > > the organisational burden. > > > > > So another kind notice for whoever is willing to take over tensorflow: > > > also be prepared to fuss with ftp-master. > > > > I need to admit that I'm absolutely happy about ftpmaster. They are > > currently *extremely* supportive to our COVID-19 hackathon and > 30 > > packages made it from upload to unstable in less than 24 hours! > > > > Since I consider it a "promising time" to reach a lot for deep learning > > tools in Debian which are frequently used in those tools to hunt down > > COVID-19 I'd like to call for help here for trying again to get > > tensorflow in - this time even with the Python3 module. > > > > Lumin has written an own build system for the C++ library since he has > > found out that the upstream build system is not usuable for Debian. > > Regarding the Python3 module he said that its not simply a matter of > > adapting his build system but "significantly extend" it since the python > > building process is much more complicated than the process for C++. > > > > Any takers for this task? > > > > Kind regards > > > >Andreas. > > > > > > [1] > https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-March/079054.html > > > > -- > > http://fam-tille.de > > >
Re: RFS : new upstream version of jebl2
Hi Andreas, Le 25/04/2020 à 11:20, Andreas Tille a écrit : > Hi again, > > perhaps also getting > >https://salsa.debian.org/med-team/libsis-jhdf5-java > > done would be helpful. I've pushed latest upstream but did not > found the time to update the old patches to the new version. > Getting this extremely outdated package updated would be great. > Thanks for the suggestion; I have begun working on it. Updating the patches is done, but I am facing build issues that you had already seen one year and a half ago, related to some header file H5private.h. Do you remember about that issue? Otherwise no worry, I will investigate :-) Afterwards, I will be interested in packaging the dependencies of snpeff as you suggested yesterday. I will fill ITP bugs when I am ready for beginning this. > > Kind regards > Andreas. > Enjoy your week-end --- at home, as for me, I'm afraid :-( , Pierre
Re: [covid-19] Reviving tensorflow packaging effort (Was: Missing dependancies for streamlit)
On 25.04.20 13:42, Andreas Tille wrote: Hi Mo, On Sat, Apr 25, 2020 at 10:20:32AM +, Mo Zhou wrote: Is there any COVID-19 package using pytorch blocked due to its absense? I admit I can not say without doing detailed research on the set of relevant packages[3] A good news is that I've managed to strip the whole third_party/ directory of src:pytorch, and started to forward my patches to upstream[1]. When all my modifications entered the upstream repo, I'll be quite confident that our src:pytorch package can enter the archive without any (annoying) embedded sources [2]. Cool! What I'm doing now is to wait for the upstream to merge my commits, and for the ftp-masters to accept my NEW dependency packages. In that sense, I'd like to take the COVID-19 shortcut to pass NEW quickly, if any COVID-19 related package needs pytorch. Frankly speaking: A lot of the relevant high level tools of epidemiology are using deep learning technologies. So its not really wrong to say its relevant for COVID-19 fighting. It is relevant - also for the interpretation of patterns in structural data. Rosetta comes to mind. --- According to my status page https://qa.debian.org/developer.php?login=lumin these are the NEW dependency packages: fp16 fxdiv gloo onnx psimd pthreadpool I'll start to re-debianize src:pytorch from scratch when all of my commits had been upstreamed. --- all of my on-going work are publically available: https://salsa.debian.org/deeplearning-team Cool. I've added this to the Blends machine-readable gatherer since several interesting Blends packages are there. It would be great if you could add these to the according Debian Science and Debian Med tasks. BTW, what might be interesting for you: Olek is very actively working on bazel: https://salsa.debian.org/olek/bazel https://github.com/cdluminate/pytorch (messy, not rebased yet) The links to my PRs can be found on [1] [1] https://github.com/pytorch/pytorch/issues/14699 [2] Finally, we will have a modern deep learning framework in the archive. It's better than having nothing even if I'm working on the cpu-only (free) version. Thanks a lot for all your work. Its extremely helpful. I just installed the official ROCm packages on an Ubuntu machine of mine and was happy that this all worked. What you are doing is very impressive, indeed. Steffen [3] https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/COVID-19-Hackathon-packages-needing-work
Re: [covid-19] Reviving tensorflow packaging effort (Was: Missing dependancies for streamlit)
Hi Mo, On Sat, Apr 25, 2020 at 10:20:32AM +, Mo Zhou wrote: > > Is there any COVID-19 package using pytorch blocked due to its absense? I admit I can not say without doing detailed research on the set of relevant packages[3] > A good news is that I've managed to strip the whole third_party/ > directory of src:pytorch, and started to forward my patches to upstream[1]. > When all my modifications entered the upstream repo, I'll be quite > confident that our src:pytorch package can enter the archive without > any (annoying) embedded sources [2]. Cool! > What I'm doing now is to wait for the upstream to merge my commits, and > for the ftp-masters to accept my NEW dependency packages. > > In that sense, I'd like to take the COVID-19 shortcut to pass NEW > quickly, if any COVID-19 related package needs pytorch. Frankly speaking: A lot of the relevant high level tools of epidemiology are using deep learning technologies. So its not really wrong to say its relevant for COVID-19 fighting. > --- According to my status page > https://qa.debian.org/developer.php?login=lumin > these are the NEW dependency packages: > > fp16 > fxdiv > gloo > onnx > psimd > pthreadpool > > I'll start to re-debianize src:pytorch from scratch when all of my > commits had been upstreamed. > > --- all of my on-going work are publically available: > https://salsa.debian.org/deeplearning-team Cool. I've added this to the Blends machine-readable gatherer since several interesting Blends packages are there. It would be great if you could add these to the according Debian Science and Debian Med tasks. BTW, what might be interesting for you: Olek is very actively working on bazel: https://salsa.debian.org/olek/bazel > https://github.com/cdluminate/pytorch (messy, not rebased yet) > The links to my PRs can be found on [1] > > [1] https://github.com/pytorch/pytorch/issues/14699 > [2] Finally, we will have a modern deep learning framework in the > archive. It's better than having nothing even if I'm working on the > cpu-only (free) version. Thanks a lot for all your work. Its extremely helpful. Kind regards Andreas. [3] https://salsa.debian.org/med-team/community/2020-covid19-hackathon/-/wikis/COVID-19-Hackathon-packages-needing-work -- http://fam-tille.de
Re: [covid-19] Reviving tensorflow packaging effort (Was: Missing dependancies for streamlit)
Hi Tille, Is there any COVID-19 package using pytorch blocked due to its absense? A good news is that I've managed to strip the whole third_party/ directory of src:pytorch, and started to forward my patches to upstream[1]. When all my modifications entered the upstream repo, I'll be quite confident that our src:pytorch package can enter the archive without any (annoying) embedded sources [2]. What I'm doing now is to wait for the upstream to merge my commits, and for the ftp-masters to accept my NEW dependency packages. In that sense, I'd like to take the COVID-19 shortcut to pass NEW quickly, if any COVID-19 related package needs pytorch. --- According to my status page https://qa.debian.org/developer.php?login=lumin these are the NEW dependency packages: fp16 fxdiv gloo onnx psimd pthreadpool I'll start to re-debianize src:pytorch from scratch when all of my commits had been upstreamed. --- all of my on-going work are publically available: https://salsa.debian.org/deeplearning-team https://github.com/cdluminate/pytorch (messy, not rebased yet) The links to my PRs can be found on [1] [1] https://github.com/pytorch/pytorch/issues/14699 [2] Finally, we will have a modern deep learning framework in the archive. It's better than having nothing even if I'm working on the cpu-only (free) version. On Wed, Apr 08, 2020 at 10:06:12AM +0200, Andreas Tille wrote: > Hi Mo, > > On Wed, Apr 08, 2020 at 02:46:06AM +, Mo Zhou wrote: > > On Tue, Apr 07, 2020 at 11:49:07AM +0200, Andreas Tille wrote: > > > On Tue, Apr 07, 2020 at 08:56:45AM +0100, Rebecca N. Palmer wrote: > > > > tensorflow 1.10 was packaged in experimental, but with reduced > > > > performance, > > > > and was removed because this was considered not worth it: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935769 > > > > > > Ah I simply forgot this. Thanks for refreshing my mind. > > > > After that I tried to refresh the packaging and uploaded tensorflow 2.0 > > to the NEW queue. The ftp-master complained about the embedded snapshot > > version of Eigen3. Ftp-masters are not convinced even if I said > > tensorflow FTBFS against the version shipped in our archive, and it > > could waste lots of my time and energy to patch the related code. > > I can understand your feeling. I've re-read the discussion[1] about > including eigen3 into the tensorflow source. The most promising > statement was given in > > > https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-March/079169.html > >Sean Whitton spwhitton at spwhitton.name >Tue Mar 3 04:04:52 GMT 2020 > >Rejected per your request, but from my point of view this discussion is >not over -- Policy 4.13 says that packages *should* not use convenience >copies of code, not that they *must* not. > >Thank you for all your work on uploading useful ML packages. > > At first: Thanks also from me! > > >From my point of view that is not a lost case so we should really try > again. > > > I was so angry at that time so I deleted my name from the maintainers > > and wrote the git message "I'm dropping this burden.". > > Well, sometimes personal feelings are dominating our actions. I hope we > could form some real team around this to spread the technical as well as > the organisational burden. > > > So another kind notice for whoever is willing to take over tensorflow: > > also be prepared to fuss with ftp-master. > > I need to admit that I'm absolutely happy about ftpmaster. They are > currently *extremely* supportive to our COVID-19 hackathon and > 30 > packages made it from upload to unstable in less than 24 hours! > > Since I consider it a "promising time" to reach a lot for deep learning > tools in Debian which are frequently used in those tools to hunt down > COVID-19 I'd like to call for help here for trying again to get > tensorflow in - this time even with the Python3 module. > > Lumin has written an own build system for the C++ library since he has > found out that the upstream build system is not usuable for Debian. > Regarding the Python3 module he said that its not simply a matter of > adapting his build system but "significantly extend" it since the python > building process is much more complicated than the process for C++. > > Any takers for this task? > > Kind regards > >Andreas. > > > [1] > https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-March/079054.html > > -- > http://fam-tille.de >
Re: RFS : new upstream version of jebl2
Hi again, perhaps also getting https://salsa.debian.org/med-team/libsis-jhdf5-java done would be helpful. I've pushed latest upstream but did not found the time to update the old patches to the new version. Getting this extremely outdated package updated would be great. Kind regards Andreas. On Fri, Apr 24, 2020 at 11:27:20PM +0200, Andreas Tille wrote: > Hi Pierre, > > On Fri, Apr 24, 2020 at 11:17:40PM +0200, Pierre Gruet wrote: > > > > Thanks for the review and the upload. I must admit I had not thought about > > the new upstream message that would remain... I only considered keeping the > > meaningful, ``understandable'' part of the version number. I will consider > > this choice next time. > > OK, I'd suggest just to leave the version number delivered by uscan. But > this has time for a next upload. > > > > Work on Java packages is extremely welcome since we have an unfortunate > > > lack of Java knowledge in the team. If you need some inspiration what > > > task to tackle next - I'm happy to hand over other Java tasks. ;-) > > > > I'm taking note! I will thus consider working on other Java packages then. > > The most important task would be to package the dependencies for snpeff. > I wrote down what I found out in d/changelog in salsa: > >https://salsa.debian.org/med-team/snpeff/-/blob/master/debian/changelog > > If you would manage to tackle only one of these that would be really > helpful. > > > Have a nice week-end, > > Same to you > >Andreas. > > -- > http://fam-tille.de > > -- http://fam-tille.de
Bug#958763: lintian: Please allow language extensions in packages for specific teams
Package: lintian Version: 2.67.0 Severity: wishlist Hi, as suggested by Chris Lamb I hereby asking for either ignoring or setting severity to either experimental or pedantic for certain teams for the issue script-with-language-extension This should happen for the teams Debian Med Packaging Team Debian Science Team Kind regards and thanks for maintaining lintian Andreas. [1] https://lists.debian.org/debian-med/2020/04/msg00248.html -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (501, 'testing'), (50, 'buildd-unstable'), (50, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.34-5 ii bzip21.0.8-2 ii diffstat 1.63-1 ii dpkg 1.19.7 ii dpkg-dev 1.19.7 ii file 1:5.38-4 ii gettext 0.19.8.1-10 ii gpg 2.2.20-1 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.36+b3 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl 0.48-1 ii libclass-xsaccessor-perl 1.19-3+b3 ii libclone-perl0.43-2 ii libcpanel-json-xs-perl 4.19-1 ii libdevel-size-perl 0.83-1+b1 ii libdpkg-perl 1.19.7 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl 1.06-1 ii libhtml-parser-perl 3.72-5 ii libio-async-loop-epoll-perl 0.20-1 ii libio-async-perl 0.75-1 ii libjson-maybexs-perl 1.004000-1 ii liblist-compare-perl 0.53-1 ii liblist-moreutils-perl 0.416-1+b5 ii libmoo-perl 2.004000-1 ii libmoox-aliases-perl 0.001006-1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl0.108-1 ii libsereal-decoder-perl 4.011+ds-1 ii libsereal-encoder-perl 4.011+ds-1 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3200-1 ii libtry-tiny-perl 0.30-1 ii libtype-tiny-perl1.010001-1 ii libunicode-utf8-perl 0.62-1+b1 ii liburi-perl 1.76-2 ii libxml-libxml-perl 2.0134+dfsg-2 ii libxml-writer-perl 0.625-1 ii libyaml-libyaml-perl 0.81+repack-1 ii man-db 2.9.1-1 ii patchutils 0.3.4-2+b1 ii perl [libdigest-sha-perl]5.30.0-10 ii t1utils 1.41-3 ii xz-utils 5.2.4-1+b1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b6 Versions of packages lintian suggests: ii binutils-multiarch 2.34-5 ii libtext-template-perl 1.58-1 -- no debconf information
