Orthanc and all its plugins are getting removed from testing
Dear all, Because of the bug #966655 [1], and because of the fact that orthanc-1.7.2+dfsg-2 is pending in the NEW queue [2], I cannot commit the fix regarding the missing build dependency on tzdata until the NEW packages get accepted. But, as #966655 is tagged as serious, the entire Orthanc ecosystem was removed from Debian testing during this week-end. Is there anything I can do to prevent this? Many thanks in advance for your help, Sébastien- [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966655 [2] https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-July/082973.html
Re: fix for #966470: biobambam2 autopkgtest failures
Hi Steffen, Steffen Möller, on 2020-08-09 21:44:23 +0200: > On 09.08.20 18:23, Étienne Mollier wrote: > > Steffen Möller, on 2020-08-08 23:41:18 +0200: > >> Sidenote: How is your Debian Maintainership doing? > > Since the question as been raised during last Friday's > > videoconference meeting, I contacted a DD in my city yesterday. > > I'll see what are his availabilities, if he is available. Since > > it's vacation time these days, he may not be around. > > You may then also have discussed that thread (on -devel?) started by > Enrico Zini iirc about avoiding f2f key signing during these (should-be) > lockdown-times. > > https://lists.debian.org/debian-project/2020/08/msg0.html > > Since we have met per video already ... I tend to think that it would be > fine. Over here we are asking those who return from vacation to stay in > quarantine, so - I think there may be a way around you meeting up locally. Ouch, no I missed it. Thank you for the pointers; I believe that there are still several lists I've yet to subscribe. Thanks also for the overall status on the covid-19 situation; asking to see a DD in person does not sound responsible at all. I suppose that meeting should be postponed for better days. > Andreas, Michael, Alex, ...? Take care -- Étienne Mollier Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/5, please excuse my verbosity. signature.asc Description: PGP signature
Re: libgclib - symbol file - please kindly educate me
Hi Steffen, I've pushed the new version of symbols file to the repository. As far as I see in the new version of libgclib the 3 symbols ( the ones in the diff you provided) are removed. This is quite bad and probably it makes sense to discuss that with upstream, since software using these symbols will be broken. Luckily none of the reverse deps of libgclib in Debian are using the removed symbols. Best regards, Ale On 8/9/20 4:33 PM, Steffen Möller wrote: Hi Alex, hi Andreas, This is what I get when I remove the -1 make[1]: Leaving directory '.../med-team/libgclib' dh_perl dh_link dh_strip_nondeterminism dh_compress dh_fixperms dh_missing dh_dwz -a dh_strip -a dh_makeshlibs -a dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libgclib2/DEBIAN/symbols doesn't match completely debian/libgclib2.symbols --- debian/libgclib2.symbols (libgclib2_0.11.10-1_amd64) +++ dpkg-gensymbolsGWl6pJ 2020-08-09 14:16:35.796448318 +0200 @@ -25,7 +25,7 @@ _Z10g2bit2baseh@Base 0.11.4 _Z10gcdb_allocj@Base 0.11.4 _Z10getFileExtPKc@Base 0.11.4 - _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10 +#MISSING: 0.11.10-1# _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10 _Z10getOvlCodeR6GffObjS0_Ribi@Base 0.11.10 _Z10parseFloatRPcRf@Base 0.11.4 _Z10replaceStrRPcS_@Base 0.11.4 @@ -79,13 +79,13 @@ _Z14gfo_cmpRefByIDPvS_@Base 0.11.4 _Z14translateCodonPKc@Base 0.11.4 _Z15printEditScriptP12GXEditScript@Base 0.11.4 - _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10 +#MISSING: 0.11.10-1# _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10 _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10 _Z15uint32_pack_bigPcj@Base 0.11.4 _Z16BED_addAttributeP8_IO_FILERiPKcz@Base 0.11.4 _Z16DefLTCompareProcI4GSegEiPvS1_@Base 0.11.4 _Z16gthreads_errExitiPKc@Base 0.11.4 - _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10 +#MISSING: 0.11.10-1# _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10 _Z16singleExonTMatchR6GffObjS0_Rii@Base 0.11.10 _Z17GreedyAlignRegionPKciiS0_iiP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4 _Z17GreedyAlignRegionPKciiS0_iP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4 dh_makeshlibs: error: failing due to earlier errors make: *** [debian/rules:13: binary] Error 1 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 ? Steffen On 09.08.20 07:00, Andreas Tille wrote: Hi Steffen, the patch you get from dh_makeshlibs needs to be edited. You simply sed -i 's/-1$//' debian/libgclib2.symbols should do the trick. Hope this helps Andreas. On Sat, Aug 08, 2020 at 11:39:24PM +0200, Steffen Möller wrote: Hello, to get the build process to first not fail and then be quiet, I changed the .symbols file as follows: diff --git a/debian/libgclib2.symbols b/debian/libgclib2.symbols index 6bef43a..aef012c 100644 --- a/debian/libgclib2.symbols +++ b/debian/libgclib2.symbols @@ -25,7 +25,8 @@libgclib.so.2 libgclib2 #MINVER# _Z10g2bit2baseh@Base 0.11.4 _Z10gcdb_allocj@Base 0.11.4 _Z10getFileExtPKc@Base 0.11.4 - _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.4 + _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10-1 + _Z10getOvlCodeR6GffObjS0_Ribi@Base 0.11.10-1 _Z10parseFloatRPcRf@Base 0.11.4 _Z10replaceStrRPcS_@Base 0.11.4 _Z10startsWithPKcS0_@Base 0.11.4 @@ -78,12 +79,15 @@libgclib.so.2 libgclib2 #MINVER# _Z14gfo_cmpRefByIDPvS_@Base 0.11.4 _Z14translateCodonPKc@Base 0.11.4 _Z15printEditScriptP12GXEditScript@Base 0.11.4 - _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.4 + _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10-1 + _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1 _Z15uint32_pack_bigPcj@Base 0.11.4 _Z16BED_addAttributeP8_IO_FILERiPKcz@Base 0.11.4 _Z16DefLTCompareProcI4GSegEiPvS1_@Base 0.11.4 _Z16gthreads_errExitiPKc@Base 0.11.4 - _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.4 + _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10-1 + _Z16singleExonTMatchR6GffObjS0_Rii@Base 0.11.10-1 + _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1 _Z17GreedyAlignRegionPKciiS0_iiP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4 _Z17GreedyAlignRegionPKciiS0_iP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4 _Z17gcvt_endian_setupv@Base 0.11.4 I have no idea why there is now a -1 attached to the version. I just know that it does not work without it. Can I upload as is? Best, Steffen
Re: fix for #966470: biobambam2 autopkgtest failures
Hi Étienne, On 09.08.20 18:23, Étienne Mollier wrote: > Steffen Möller, on 2020-08-08 23:41:18 +0200: >> Local build initiated. > Thanks for the upload, although, if I read my emails properly, > you've been beaten by Andreas at it. Yup. > I received a message from > him some time before about missing git tags in side branches > (again), so should have warned about it. Sorry if there was > some duplicate work. > >> Sidenote: How is your Debian Maintainership doing? > Since the question as been raised during last Friday's > videoconference meeting, I contacted a DD in my city yesterday. > I'll see what are his availabilities, if he is available. Since > it's vacation time these days, he may not be around. You may then also have discussed that thread (on -devel?) started by Enrico Zini iirc about avoiding f2f key signing during these (should-be) lockdown-times. https://lists.debian.org/debian-project/2020/08/msg0.html Since we have met per video already ... I tend to think that it would be fine. Over here we are asking those who return from vacation to stay in quarantine, so - I think there may be a way around you meeting up locally. Andreas, Michael, Alex, ...? Steffen
Re: RFS: Bug#957360: insighttoolkit4: ftbfs with GCC-10
Hi Steven, Steven Robbins, on 2020-08-08 17:25:05 -0500: > On Saturday, August 8, 2020 4:34:39 P.M. CDT Étienne Mollier wrote: > > > 2. I wonder whether some of the older patches (dating from 2016) should be > > > dropped; in particular: > > > > > > atomic_load.patch > > > > I'm missing context, and the issue tracker pointed to by the URL > > in the header does not seem to have migrated to the current > > platform unfortunately. :/ > > I managed to find it here: https://insightsoftwareconsortium.atlassian.net/ > browse/ITK-3413 > > But that doesn't shed a lot of light. The only thing I see relevant is "Make > the Load operation truly atomic - doesn't change anything on amd64 or i386, > but it may be of interest for other archs. " However, the patch removes one > usage of __sync_synchronize, but leaves another in the Store() function, > which > seems suspect. I would believe that there may have been a bug in the x86 > codegen in 2016, but we've got 4 years of compiler fixes since then, so I am > of > the opinion to remove this on that basis. And the basis that upstream ITK > has > not incorporated this change in 4 years. Okay, I guess this might be removed then. > > > itk4.10.0-python-wrapping.patch > > > > I have the impression that this second one is needed to avoid > > use of included third party libraries and use the one provided > > by Debian. > > You must be looking at a different patch. Indeed I erroneously had a look at the nifti patch; let's say that it was late in my TZ. :) > This one is: > > --- a/Modules/Filtering/ImageGrid/wrapping/itkResampleImageFilter.wrap > +++ b/Modules/Filtering/ImageGrid/wrapping/itkResampleImageFilter.wrap > @@ -8,6 +8,7 @@ >foreach(d ${ITK_WRAP_IMAGE_DIMS}) > foreach(t ${to_types}) >itk_wrap_template("${ITKM_VI${t}${d}}${ITKM_VI${t}${d}}" "${ITKT_VI${t} > ${d}},${ITKT_VI${t}${d}}") > + itk_wrap_template("${ITKM_I${t}${d}}${ITKM_I${t}${d}}" "${ITKT_I${t}$ > {d}},${ITKT_I${t}${d}}") > endforeach() >endforeach() > > I don't see any motivation to adding the extra wrapping. This patch was > added > in 2016, along with itk4.10.0_itkTriangleHelper.h.patch (since removed) to > fix > a build failure on amd64 (see #835761). The bug traces to ITK issue https:// > insightsoftwareconsortium.atlassian.net/browse/ITK-3466 which was said to be > addressed in 4.10.1 with this commit: https://github.com/ > InsightSoftwareConsortium/ITK/commit/be1e9f88ff036048148d4b8b887b8671739307d4 > This commit amounts to the content of the former > itk4.10.0_itkTriangleHelper.h.patch. > > I have run the build with this patch removed to no noticable effect -- only > test failure remains Test #2625: PythonExtras. > > This seems safe to remove. Agreed, assuming upstream fixed the corresponding issue somehow. > > > itk4.12.0-resource_cprobe.patch > > > > This last one seems needed for i386 support, but might require > > to check how behaves the targeted equipment before drop. Maybe > > I can attempt a build without the patch on my i386 alarm clock. > > I ran the build with this patch removed to no noticable effect -- only test > failure remains Test #2625: PythonExtras. But this was amd64. I'll do it > again on x86 before comitting the removal. I triggered a build on i386 without those patches, will see how it goes. I'm doing it on real hardware, so it smells like it will take quite a long time, hope it won't melt with these days' heat. About the Test #2625: PythonExtras, I failed to reproduce any issue at build time. Actually I see no such test there, as if something might have been missing on my side. I triggered an autopkgtest, in case I haven't been looking at the proper location. Kind Regards, -- Étienne Mollier Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
Re: fix for #966470: biobambam2 autopkgtest failures
Hi Steffen, Steffen Möller, on 2020-08-08 23:41:18 +0200: > Local build initiated. Thanks for the upload, although, if I read my emails properly, you've been beaten by Andreas at it. I received a message from him some time before about missing git tags in side branches (again), so should have warned about it. Sorry if there was some duplicate work. > Sidenote: How is your Debian Maintainership doing? Since the question as been raised during last Friday's videoconference meeting, I contacted a DD in my city yesterday. I'll see what are his availabilities, if he is available. Since it's vacation time these days, he may not be around. Kind Regards, -- Étienne Mollier Old rsa/3072: 5ab1 4edf 63bb ccff 8b54 2fa9 59da 56fe fff3 882d New rsa/4096: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/5, please excuse my verbosity. signature.asc Description: PGP signature
[RFS] wtdbg2
Hi, I've added autopkgtests for wtdbg2, since this uses extra data which blows up in size, I created a new binary for the same. Hence, this needs to go through the NEW queue. My changes are pushed to the team-repo here[1]. Needs review and sponsorship. [1]: https://salsa.debian.org/med-team/wtdbg2 Thanks and regards Nilesh
Re: libgclib - symbol file - please kindly educate me
Hi Alex, hi Andreas, This is what I get when I remove the -1 make[1]: Leaving directory '.../med-team/libgclib' dh_perl dh_link dh_strip_nondeterminism dh_compress dh_fixperms dh_missing dh_dwz -a dh_strip -a dh_makeshlibs -a dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libgclib2/DEBIAN/symbols doesn't match completely debian/libgclib2.symbols --- debian/libgclib2.symbols (libgclib2_0.11.10-1_amd64) +++ dpkg-gensymbolsGWl6pJ 2020-08-09 14:16:35.796448318 +0200 @@ -25,7 +25,7 @@ _Z10g2bit2baseh@Base 0.11.4 _Z10gcdb_allocj@Base 0.11.4 _Z10getFileExtPKc@Base 0.11.4 - _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10 +#MISSING: 0.11.10-1# _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10 _Z10getOvlCodeR6GffObjS0_Ribi@Base 0.11.10 _Z10parseFloatRPcRf@Base 0.11.4 _Z10replaceStrRPcS_@Base 0.11.4 @@ -79,13 +79,13 @@ _Z14gfo_cmpRefByIDPvS_@Base 0.11.4 _Z14translateCodonPKc@Base 0.11.4 _Z15printEditScriptP12GXEditScript@Base 0.11.4 - _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10 +#MISSING: 0.11.10-1# _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10 _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10 _Z15uint32_pack_bigPcj@Base 0.11.4 _Z16BED_addAttributeP8_IO_FILERiPKcz@Base 0.11.4 _Z16DefLTCompareProcI4GSegEiPvS1_@Base 0.11.4 _Z16gthreads_errExitiPKc@Base 0.11.4 - _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10 +#MISSING: 0.11.10-1# _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10 _Z16singleExonTMatchR6GffObjS0_Rii@Base 0.11.10 _Z17GreedyAlignRegionPKciiS0_iiP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4 _Z17GreedyAlignRegionPKciiS0_iP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4 dh_makeshlibs: error: failing due to earlier errors make: *** [debian/rules:13: binary] Error 1 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 ? Steffen On 09.08.20 07:00, Andreas Tille wrote: > Hi Steffen, > > the patch you get from dh_makeshlibs needs to be edited. You simply > > sed -i 's/-1$//' debian/libgclib2.symbols > > should do the trick. > > Hope this helps > > Andreas. > > On Sat, Aug 08, 2020 at 11:39:24PM +0200, Steffen Möller wrote: >> Hello, >> >> to get the build process to first not fail and then be quiet, I changed >> the .symbols file as follows: >> >> diff --git a/debian/libgclib2.symbols b/debian/libgclib2.symbols >> index 6bef43a..aef012c 100644 >> --- a/debian/libgclib2.symbols >> +++ b/debian/libgclib2.symbols >> @@ -25,7 +25,8 @@libgclib.so.2 libgclib2 #MINVER# >> _Z10g2bit2baseh@Base 0.11.4 >> _Z10gcdb_allocj@Base 0.11.4 >> _Z10getFileExtPKc@Base 0.11.4 >> - _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.4 >> + _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10-1 >> + _Z10getOvlCodeR6GffObjS0_Ribi@Base 0.11.10-1 >> _Z10parseFloatRPcRf@Base 0.11.4 >> _Z10replaceStrRPcS_@Base 0.11.4 >> _Z10startsWithPKcS0_@Base 0.11.4 >> @@ -78,12 +79,15 @@libgclib.so.2 libgclib2 #MINVER# >> _Z14gfo_cmpRefByIDPvS_@Base 0.11.4 >> _Z14translateCodonPKc@Base 0.11.4 >> _Z15printEditScriptP12GXEditScript@Base 0.11.4 >> - _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.4 >> + _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10-1 >> + _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1 >> _Z15uint32_pack_bigPcj@Base 0.11.4 >> _Z16BED_addAttributeP8_IO_FILERiPKcz@Base 0.11.4 >> _Z16DefLTCompareProcI4GSegEiPvS1_@Base 0.11.4 >> _Z16gthreads_errExitiPKc@Base 0.11.4 >> - _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.4 >> + _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10-1 >> + _Z16singleExonTMatchR6GffObjS0_Rii@Base 0.11.10-1 >> + _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1 >> _Z17GreedyAlignRegionPKciiS0_iiP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4 >> _Z17GreedyAlignRegionPKciiS0_iP16CGreedyAlignDataP8CAlnTrimb@Base >> 0.11.4 >> _Z17gcvt_endian_setupv@Base 0.11.4 >> >> I have no idea why there is now a -1 attached to the version. I just >> know that it does not work without it. >> >> Can I upload as is? >> >> Best, >> >> Steffen >> >>
Re: libgclib - symbol file - please kindly educate me
Also, there is no need to update symbols version, only add the new symbols. Symbols file is needed to track down the ABI changes. https://www.debian.org/doc/debian-policy/ch-sharedlibs.html "A symbols file documents, for each symbol exported by a library, the minimal version of the package any binary using this symbol will need. This is typically the version of the package in which the symbol was introduced." I am on a vac and most of the time Afk. Best regards, Alex On 8/9/20 7:00 AM, Andreas Tille wrote: Hi Steffen, the patch you get from dh_makeshlibs needs to be edited. You simply sed -i 's/-1$//' debian/libgclib2.symbols should do the trick. Hope this helps Andreas. On Sat, Aug 08, 2020 at 11:39:24PM +0200, Steffen Möller wrote: Hello, to get the build process to first not fail and then be quiet, I changed the .symbols file as follows: diff --git a/debian/libgclib2.symbols b/debian/libgclib2.symbols index 6bef43a..aef012c 100644 --- a/debian/libgclib2.symbols +++ b/debian/libgclib2.symbols @@ -25,7 +25,8 @@libgclib.so.2 libgclib2 #MINVER# _Z10g2bit2baseh@Base 0.11.4 _Z10gcdb_allocj@Base 0.11.4 _Z10getFileExtPKc@Base 0.11.4 - _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.4 + _Z10getOvlCodeR6GffObjS0_Rib@Base 0.11.10-1 + _Z10getOvlCodeR6GffObjS0_Ribi@Base 0.11.10-1 _Z10parseFloatRPcRf@Base 0.11.4 _Z10replaceStrRPcS_@Base 0.11.4 _Z10startsWithPKcS0_@Base 0.11.4 @@ -78,12 +79,15 @@libgclib.so.2 libgclib2 #MINVER# _Z14gfo_cmpRefByIDPvS_@Base 0.11.4 _Z14translateCodonPKc@Base 0.11.4 _Z15printEditScriptP12GXEditScript@Base 0.11.4 - _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.4 + _Z15transcriptMatchR6GffObjS0_Ri@Base 0.11.10-1 + _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1 _Z15uint32_pack_bigPcj@Base 0.11.4 _Z16BED_addAttributeP8_IO_FILERiPKcz@Base 0.11.4 _Z16DefLTCompareProcI4GSegEiPvS1_@Base 0.11.4 _Z16gthreads_errExitiPKc@Base 0.11.4 - _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.4 + _Z16singleExonTMatchR6GffObjS0_Ri@Base 0.11.10-1 + _Z16singleExonTMatchR6GffObjS0_Rii@Base 0.11.10-1 + _Z15transcriptMatchR6GffObjS0_Rii@Base 0.11.10-1 _Z17GreedyAlignRegionPKciiS0_iiP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4 _Z17GreedyAlignRegionPKciiS0_iP16CGreedyAlignDataP8CAlnTrimb@Base 0.11.4 _Z17gcvt_endian_setupv@Base 0.11.4 I have no idea why there is now a -1 attached to the version. I just know that it does not work without it. Can I upload as is? Best, Steffen