Re: [Help] One remaining build time error in toil
On Thu, Jul 13, 2023 at 09:42:01PM +0200, Andreas Tille wrote: > Hi folks, > > before I switch of my laptop for today I'd like to hand over some > remaining build time error in toil: On running the command that the test tries to run by hand, I see: | Traceback (most recent call last): | File "", line 198, in _run_module_as_main | File "", line 88, in _run_code | File "/build/toil-INKUvz/toil-5.11.0/.pybuild/cpython3_3.11_toil/build/toil/wdl/wdltoil.py", line 38, in |import WDL | ModuleNotFoundError: No module named 'WDL I think we don't have miniwdl in the archive at this point, so you'd need to package it. Best, Nilesh signature.asc Description: PGP signature
Re: GATK
Hi Andreas, Le 12/07/2023 à 15:01, Andreas Tille a écrit : Hi Pierre, I was wondering whether we might be able to package GATK for the next release. I've just fixed the watch file in Git. It would be great if you could have a look once you might find some spare cycles. Yeah, GATK is one of my main goals, with Nextflow. If I remember correctly, scala was a blocker but there might be a way to deal with it... Right now I am preparing the move of my family some hundreds of kilometers away, I expect to get more time to look at it closer afterwards. Still, as I said, GATK and Nextflow are my packaging goals in the team, and I am happy to say many dependencies have been added in the last year :) Kind regards Andreas. Best, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
[Help] One remaining build time error in toil
Hi folks, before I switch of my laptop for today I'd like to hand over some remaining build time error in toil: ___ WdlToilTest.test_empty_file_path ___ [gw0] linux -- Python 3.11.4 /usr/bin/python3.11 Traceback (most recent call last): File "/usr/lib/python3.11/unittest/case.py", line 57, in testPartExecutor yield File "/usr/lib/python3.11/unittest/case.py", line 623, in run self._callTestMethod(testMethod) File "/usr/lib/python3.11/unittest/case.py", line 579, in _callTestMethod if method() is not None: File "/builds/med-team/toil/debian/output/source_dir/src/toil/test/wdl/wdltoil_test.py", line 54, in test_empty_file_path assert b'Could not find' in stderr ^^^ AssertionError see https://salsa.debian.org/med-team/toil/-/jobs/4428408 Any help would be welcome to enable me starting with some new tasks tomorrow, ;-) Kind regards Andreas. -- http://fam-tille.de
Re: [Help] undefined symbol: H5Oget_info in uncalled
On Thu, Jul 13, 2023 at 05:53:51PM +0200, Andreas Tille wrote: > Hi, > > I could need some help for uncalled, where build time test fails with Seems to be because of https://github.com/skovaka/UNCALLED/commit/8a8585c8b2e3bf6748c231fb679888433bd44687 Fix pushed to salsa. Best, Nilesh signature.asc Description: PGP signature
[Help] undefined symbol: H5Oget_info in uncalled
Hi, I could need some help for uncalled, where build time test fails with ERROR: uncalled (unittest.loader._FailedTest.uncalled) -- ImportError: Failed to import test module: uncalled Traceback (most recent call last): File "/usr/lib/python3.11/unittest/loader.py", line 440, in _find_test_path package = self._get_module_from_name(name) File "/usr/lib/python3.11/unittest/loader.py", line 350, in _get_module_from_name __import__(name) File "/builds/med-team/uncalled/debian/output/source_dir/.pybuild/cpython3_3.11_uncalled/build/uncalled/__init__.py", line 1, in from _uncalled import * ImportError: /builds/med-team/uncalled/debian/output/source_dir/.pybuild/cpython3_3.11_uncalled/build/_uncalled.cpython-311-x86_64-linux-gnu.so: undefined symbol: H5Oget_info -- see https://salsa.debian.org/med-team/uncalled/-/jobs/4428370 Kind regards Andreas. -- http://fam-tille.de
Re: [Help] Could someone please have a look at gmap build failure
Hi César, Am Thu, Jul 13, 2023 at 09:49:03AM +0200 schrieb César Pomar: > I can also take a look. ... Thanks a lot for becoming involved Andreas. -- http://fam-tille.de
Re: [Help] Could someone please have a look at gmap build failure
Here is my fix https://salsa.debian.org/med-team/gmap/-/commit/596beba027da3944b0f45a9ffc9e03d1d9dca5ba On Thu, Jul 13, 2023 at 11:15 AM Michael R. Crusoe < michael.r.cru...@gmail.com> wrote: > Thanks César; I've done much of this already. I'll push my changes shortly > (testing the AVX512 level now) > > On Thu, Jul 13, 2023 at 9:49 AM César Pomar > wrote: > >> Hi, >> >> I think the same way. The code has multiple levels of vector extensions: >> SSE2, SSE3, AVX... AVX512. The code has macros to define the data types >> according to the selected extension. It's very possible that they focused >> on SSE3 or AVX (which are already the minimum supported by any machine) and >> neglected to test SSE2. >> >> I can also take a look. Additionally, since it supports up to AVX512, it >> would be good to create multiple binaries (as we did in VeryFastTree) with >> different levels so that modern hardware can take advantage of them while >> preserving compatibility. >> >> El jue, 13 jul 2023 a las 9:36, Michael R. Crusoe (< >> michael.r.cru...@gmail.com>) escribió: >> >>> The real error is at >>> >>> gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 >>> -DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -DGSNAP=1 >>> -mpopcnt -DHAVE_SSE2=1 -msse2 -mno-ssse3 -mno-sse4.1 -mno-sse4.2 -mno-avx2 >>> -g -O2 -ffile-prefix-map=/builds/med-team/gmap/debian/output/source_dir=. >>> -fstack-protector-strong -Wformat -Werror=format-security -c -o >>> gsnap_sse2-intersect-uint2.o `test -f 'intersect-uint2.c' || echo >>> './'`intersect-uint2.c >>> intersect-simd.c: In function 'v1': >>> intersect-simd.c:242:8: warning: implicit declaration of function >>> '_mm_lddqu_si128'; did you mean '_mm_loadu_si128'? >>> [-Wimplicit-function-declaration] >>> 242 | F0 = _mm_lddqu_si128((const __m128i *)(freq)); >>> |^~~ >>> |_mm_loadu_si128 >>> >>> I don't think upstream tested the SSE2 build recently; I'm looking at this >>> now >>> >>> >>> On Wed, Jul 12, 2023 at 2:01 PM Andreas Tille wrote: >>> Hi, I admit I'm bad in such hardware internals that seem to break the build of gmap: intersect-uint2.c:409:21: error: incompatible types when initializing type '__m128i' using type 'int' 409 | __m128i p = _mm_shuffle_epi8(v_a, * (__m128i *) &(shuffle_mask16[r*16])); | ^~~~ intersect-uint2.c:427:17: error: incompatible types when assigning to type '__m128i' from type 'int' 427 | v_b = _mm_lddqu_si128((const __m128i *) [i_b]); | ^~~ See https://salsa.debian.org/med-team/gmap/-/jobs/4423598 for the full build log. Any help would be welcome Andreas. -- http://fam-tille.de
Re: [Help] Could someone please have a look at gmap build failure
Thanks César; I've done much of this already. I'll push my changes shortly (testing the AVX512 level now) On Thu, Jul 13, 2023 at 9:49 AM César Pomar wrote: > Hi, > > I think the same way. The code has multiple levels of vector extensions: > SSE2, SSE3, AVX... AVX512. The code has macros to define the data types > according to the selected extension. It's very possible that they focused > on SSE3 or AVX (which are already the minimum supported by any machine) and > neglected to test SSE2. > > I can also take a look. Additionally, since it supports up to AVX512, it > would be good to create multiple binaries (as we did in VeryFastTree) with > different levels so that modern hardware can take advantage of them while > preserving compatibility. > > El jue, 13 jul 2023 a las 9:36, Michael R. Crusoe (< > michael.r.cru...@gmail.com>) escribió: > >> The real error is at >> >> gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 >> -DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -DGSNAP=1 >> -mpopcnt -DHAVE_SSE2=1 -msse2 -mno-ssse3 -mno-sse4.1 -mno-sse4.2 -mno-avx2 >> -g -O2 -ffile-prefix-map=/builds/med-team/gmap/debian/output/source_dir=. >> -fstack-protector-strong -Wformat -Werror=format-security -c -o >> gsnap_sse2-intersect-uint2.o `test -f 'intersect-uint2.c' || echo >> './'`intersect-uint2.c >> intersect-simd.c: In function 'v1': >> intersect-simd.c:242:8: warning: implicit declaration of function >> '_mm_lddqu_si128'; did you mean '_mm_loadu_si128'? >> [-Wimplicit-function-declaration] >> 242 | F0 = _mm_lddqu_si128((const __m128i *)(freq)); >> |^~~ >> |_mm_loadu_si128 >> >> I don't think upstream tested the SSE2 build recently; I'm looking at this >> now >> >> >> On Wed, Jul 12, 2023 at 2:01 PM Andreas Tille wrote: >> >>> Hi, >>> >>> I admit I'm bad in such hardware internals that seem to break the >>> build of gmap: >>> >>> intersect-uint2.c:409:21: error: incompatible types when initializing >>> type '__m128i' using type 'int' >>> 409 | __m128i p = _mm_shuffle_epi8(v_a, * (__m128i *) >>> &(shuffle_mask16[r*16])); >>> | ^~~~ >>> intersect-uint2.c:427:17: error: incompatible types when assigning to >>> type '__m128i' from type 'int' >>> 427 | v_b = _mm_lddqu_si128((const __m128i *) [i_b]); >>> | ^~~ >>> >>> See >>>https://salsa.debian.org/med-team/gmap/-/jobs/4423598 >>> for the full build log. >>> >>> Any help would be welcome >>> Andreas. >>> >>> -- >>> http://fam-tille.de >>> >>>
Public answer to doc who wants to help w GNUmed
Hi Vance, I've put your e-mail in BCC to not expose it to spammers in case you might care. All other content of your private mail which I'm responding to is not really private so I see no point in hiding my answer from other readers of the Debian Med mailing list. At first also thanks to Karsten to keep me in the row. ;-) Am Wed, Jul 12, 2023 at 08:44:43PM -0500 schrieb Vance R. Burns, MD: > Thank you for the quick response. I have an interest in helping with > whatever I can. I'm not sure what goes into maintaining packages but if it > can be learned from web resources and a Mentor I am willing to give it a > try. Inside the Debian Med team we are actually running a project to mentor newcomers: https://salsa.debian.org/med-team/community/MoM/-/wikis/Mentoring-of-the-Month-(MoM) However, I think the gnumed package is neither a good candidate for learning packaging (since all work is done) and the effort to maintain the package tends to zero. Karsten usually sends me a mail about a new release. When I receive this mail I'm firing up the script `routine-update` which in >95% does what it needs to do. So things are semi-automated and for this task no help is needed, actually. But I always want to invite newcomers who are positively interested into our nice project with a friendly team. The first I would like to recommend is to subscribe our mailing list https://lists.debian.org/debian-med/ There might be some technical discussion, very frequently about bioinformatics software which might not be your field of interest. Feel free to browse the web archive of previous postings first, whether this is some information you can bear with. > This might be brainstorming too far ahead, but I am wondering about a niche > distro Could you please explain your term "niche distro"? The Debian Med project is definitely the contrary of a niche distro since it is just plain Debian and we simply work with the Debian infra structure. Debian and its well known derivatives Ubuntu, Mint and countless others which all profit from the work of the Debian Med project (since it is pure Debian) are the contrary than a niche distro. I have seen in the past several Debian derivatives who maintained their own repository of packages. I'm observing this field since more than 20 years. I have not seen a single one of these niche derivatives that survived more than 10 years. They have all one thing in common: In the beginning some very enthusiastic developers started with some higher degree of freedom since they are not bound to all rules that are implied by Debian policy. In the run of the project they have spent a lot of time into their cute project. Later it turned out that they changed job, interests, less spare time whatever and the project became orphaned. The best example under these projects is Biolinux which did a great job and started to contribute directly to Debian somehow merging and thus saving quite a bit of their work. In short: I'm a bit careful if I hear "niche distro" and would like to hear what you might have in mind before I raise my opinion about this. > coming pre-packaged with your EHR, Dicom, libre office, a browser, > and webapp desktop links to uptodate, pubmed and so forth. Target user > would be medical, and it perhaps would be XFCE so that it could run on the > thin client PC's we use in the hospital. If you ask me you should check what you are actually missing inside Debian. Could we possibly design some metapackages that simply install what you want? If you are wondering what metapackages might be: These are defining dependencies from other packages. If you install a metapackage those dependencies will be installed. We have developed some web representation of those metapackages and here you can see the metapackages designed by the Debian Med team: https://blends.debian.org/med/tasks/ If you are missing some task or missing some depenency inside those metapackages please let us know. > I have an MX Linux distro that > I built out that way for use w citrix and cerner and then I use it from a > USB drive. It has all the cacerts built in so it trusts Entrust > certificate we use at work. I was using snapshot to back it up w gnome > disks, and realized, If I remove my username but keep all the mods, it's > basically MX for medical use. I do not know MX Linux and thus I can't judge about it. You are able to create live images from Debian as well if it is your main focus. > so I did a repo search for medical in the .deb distros and that is how I > found GNUmed. Nice. :-) > Imagine if we had a FOSS distro that could be put on limited hardware, for > community hospitals that can't afford a $37 million dollar EHR, AND > replace Windows Licence. Debian itself is not specifically designed for "limited" hardware. On the other hand it supports really cheap hardware like Raspberry Pi and others. Debian is not know for beeing specifically hungry for resources and I've
Re: [Help] Could someone please have a look at gmap build failure
Hi, I think the same way. The code has multiple levels of vector extensions: SSE2, SSE3, AVX... AVX512. The code has macros to define the data types according to the selected extension. It's very possible that they focused on SSE3 or AVX (which are already the minimum supported by any machine) and neglected to test SSE2. I can also take a look. Additionally, since it supports up to AVX512, it would be good to create multiple binaries (as we did in VeryFastTree) with different levels so that modern hardware can take advantage of them while preserving compatibility. El jue, 13 jul 2023 a las 9:36, Michael R. Crusoe (< michael.r.cru...@gmail.com>) escribió: > The real error is at > > gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 > -DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -DGSNAP=1 > -mpopcnt -DHAVE_SSE2=1 -msse2 -mno-ssse3 -mno-sse4.1 -mno-sse4.2 -mno-avx2 -g > -O2 -ffile-prefix-map=/builds/med-team/gmap/debian/output/source_dir=. > -fstack-protector-strong -Wformat -Werror=format-security -c -o > gsnap_sse2-intersect-uint2.o `test -f 'intersect-uint2.c' || echo > './'`intersect-uint2.c > intersect-simd.c: In function 'v1': > intersect-simd.c:242:8: warning: implicit declaration of function > '_mm_lddqu_si128'; did you mean '_mm_loadu_si128'? > [-Wimplicit-function-declaration] > 242 | F0 = _mm_lddqu_si128((const __m128i *)(freq)); > |^~~ > |_mm_loadu_si128 > > I don't think upstream tested the SSE2 build recently; I'm looking at this now > > > On Wed, Jul 12, 2023 at 2:01 PM Andreas Tille wrote: > >> Hi, >> >> I admit I'm bad in such hardware internals that seem to break the >> build of gmap: >> >> intersect-uint2.c:409:21: error: incompatible types when initializing >> type '__m128i' using type 'int' >> 409 | __m128i p = _mm_shuffle_epi8(v_a, * (__m128i *) >> &(shuffle_mask16[r*16])); >> | ^~~~ >> intersect-uint2.c:427:17: error: incompatible types when assigning to >> type '__m128i' from type 'int' >> 427 | v_b = _mm_lddqu_si128((const __m128i *) [i_b]); >> | ^~~ >> >> See >>https://salsa.debian.org/med-team/gmap/-/jobs/4423598 >> for the full build log. >> >> Any help would be welcome >> Andreas. >> >> -- >> http://fam-tille.de >> >>
Re: biopython 1.81 in experimental
Am Wed, Jul 12, 2023 at 10:32:08PM +0200 schrieb Étienne Mollier: > Not sure why this was caught only on arm64, as amd64 turned out > to be affected as well when I ran rebuild tests. Anyway, this > is fixed by the newer python-bcbio-gff version 0.7.0, which has > the good taste of being compatible with biopython 1.80 as well. > > I uploaded the new python-bcbio-gff, and once python-biopython > 1.80+dfsg-6 migrates to testing (tomorrow or Friday if all goes > well), v1.81 can migrate to unstable and the version bump should > overall be a breeze. Good job Andreas. -- http://fam-tille.de
Re: [Help] Could someone please have a look at gmap build failure
The real error is at gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 -DTARGET=\"x86_64-pc-linux-gnu\" -DGMAPDB=\"/var/cache/gmap\" -DGSNAP=1 -mpopcnt -DHAVE_SSE2=1 -msse2 -mno-ssse3 -mno-sse4.1 -mno-sse4.2 -mno-avx2 -g -O2 -ffile-prefix-map=/builds/med-team/gmap/debian/output/source_dir=. -fstack-protector-strong -Wformat -Werror=format-security -c -o gsnap_sse2-intersect-uint2.o `test -f 'intersect-uint2.c' || echo './'`intersect-uint2.c intersect-simd.c: In function 'v1': intersect-simd.c:242:8: warning: implicit declaration of function '_mm_lddqu_si128'; did you mean '_mm_loadu_si128'? [-Wimplicit-function-declaration] 242 | F0 = _mm_lddqu_si128((const __m128i *)(freq)); |^~~ |_mm_loadu_si128 I don't think upstream tested the SSE2 build recently; I'm looking at this now On Wed, Jul 12, 2023 at 2:01 PM Andreas Tille wrote: > Hi, > > I admit I'm bad in such hardware internals that seem to break the > build of gmap: > > intersect-uint2.c:409:21: error: incompatible types when initializing type > '__m128i' using type 'int' > 409 | __m128i p = _mm_shuffle_epi8(v_a, * (__m128i *) > &(shuffle_mask16[r*16])); > | ^~~~ > intersect-uint2.c:427:17: error: incompatible types when assigning to type > '__m128i' from type 'int' > 427 | v_b = _mm_lddqu_si128((const __m128i *) [i_b]); > | ^~~ > > See >https://salsa.debian.org/med-team/gmap/-/jobs/4423598 > for the full build log. > > Any help would be welcome > Andreas. > > -- > http://fam-tille.de > >
