Re: emboss and python-biopython stuck in Building state
Hi Aurelien, Aurelien Jarno, on 2024-04-25: > > Étienne Mollier, on 2024-04-23: > > > r-cran-hunspell looks also affected on armel: > > > > > > r-cran-hunspell (6d 7h 31m, arm-arm-01) > > > python-biopython (6d 5h 16m, arm-arm-03) > > > > > > also pyresample on arm64: > > > > > > emboss (6d 7h 49m, arm-arm-01) > > > pyresample (6d 7h 9m, arm-arm-04) > > > > > > and on armhf: > > > > > > pyresample (6d 7h 10m, arm-arm-01) > > > > > > none of which look to need that long to build. > > > > > > It could be that something went off with some Arm (ltd) runners. > > There are firewall issues on those buildds, the packages have been > built, but they can't be marked as such nor uploaded. Anyway they have > been given-back and rebuilt. Thank you for the status and give-backs! Have a nice day, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `-on air: Porcupine Tree - Sound Of Muzak signature.asc Description: PGP signature
Re: emboss and python-biopython stuck in Building state
Hi, On 2024-04-23 21:38, Étienne Mollier wrote: > Hi Wanna Build Team, > > Just in case this flown below the radar in the past week, you > might want to be aware of the below packages stuck in Building > state on various arm-arm-* buildd: > > Étienne Mollier, on 2024-04-23: > > Andrius Merkys, on 2024-04-23: > > > Five days ago I have uploaded emboss and python-biopython. Both are stuck > > > in > > > "Building" state since then, emboss on arm64 and python-biopython on > > > armel. > > > This is strange to me, as normally long builds timeout after periods of > > > inactivity (no output). I have successfully rebuilt emboss on amdahl.d.o > > > in > > > a couple of minutes. > > > > > > Has anybody experienced similar issues lately? > > > > r-cran-hunspell looks also affected on armel: > > > > r-cran-hunspell (6d 7h 31m, arm-arm-01) > > python-biopython (6d 5h 16m, arm-arm-03) > > > > also pyresample on arm64: > > > > emboss (6d 7h 49m, arm-arm-01) > > pyresample (6d 7h 9m, arm-arm-04) > > > > and on armhf: > > > > pyresample (6d 7h 10m, arm-arm-01) > > > > none of which look to need that long to build. > > > > It could be that something went off with some Arm (ltd) runners. There are firewall issues on those buildds, the packages have been built, but they can't be marked as such nor uploaded. Anyway they have been given-back and rebuilt. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net signature.asc Description: PGP signature
Could someone have a look into bali-phy [notificati...@github.com: Re: [bredelings/BAli-Phy] Test suite error in 4.0-beta7 (Issue #17)]
Hi folks, this is residing since some time in my inbox but I will not be able to deal with this. It would be great if someone might subscribe the issue below and update the bali-phy package accordingly. Kind regards Andreas. - Weitergeleitete Nachricht von Benjamin Redelings - Date: Mon, 01 Apr 2024 07:32:34 -0700 From: Benjamin Redelings To: bredelings/BAli-Phy Cc: Andreas Tille , Author Subject: Re: [bredelings/BAli-Phy] Test suite error in 4.0-beta7 (Issue #17) Hi Andreas, I finally did a beta9 release, so the issue should be fixed. Would you be able to build beta9 for experimental? -BenRI -- Reply to this email directly or view it on GitHub: https://github.com/bredelings/BAli-Phy/issues/17#issuecomment-2029850883 You are receiving this because you authored the thread. Message ID: - Ende weitergeleitete Nachricht - -- https://fam-tille.de
Re: Binary conflict between Midnight Commander and MinIO Client
On Wed, Apr 24, 2024 at 9:42 AM Andreas Tille wrote: > Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands: > > >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli > > > > Might I suggest that the link goes the other way, so that the symlink > > lives in /usr/bin? That way the existence of the lib directory is > > somewhat self-documenting. > > That's an interesting hint. In Debian Med we are using a common > directories > > /usr/lib/debian-med/bin/ > /usr/lib/debian-med/man/ > > where those binaries will be moved to and have some kind of a > README.Debian template[1]. Changing this to have the real executable / > manpage to /usr/lib/debian-med/* makes sense. I believe moving those binaries to a subdirectory of /usr/libexec/ would better comply with FHS 3.0. Maybe this could be done for the Trixie release? I guess a subdirectory of /usr/share/ would be appropriate for the extra manpages. Thank you, Jeremy Bícha
Re: Binary conflict between Midnight Commander and MinIO Client
Hi, Am Mon, Apr 22, 2024 at 09:28:29AM +0200 schrieb Philip Hands: > >> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli > > Might I suggest that the link goes the other way, so that the symlink > lives in /usr/bin? That way the existence of the lib directory is > somewhat self-documenting. That's an interesting hint. In Debian Med we are using a common directories /usr/lib/debian-med/bin/ /usr/lib/debian-med/man/ where those binaries will be moved to and have some kind of a README.Debian template[1]. Changing this to have the real executable / manpage to /usr/lib/debian-med/* makes sense. We simply advise Debian Med users to set PATH to that dir and have all the name-clashed binaries inside Debian Med without additional interaction. Kind regards Andreas. [1] https://salsa.debian.org/med-team/ea-utils/-/blob/master/debian/README.Debian?ref_type=heads -- https://fam-tille.de
If someone might care for raxml-ng this would be great (Was: [amkozlov/raxml-ng] What libpll code is really needed (Issue #164))
Hi, I never managed to finish raxml-ng packaging which would be a great thing to have. Some hints about its preconditions can be found inn the issue linked below. Kind regards Andreas. - Weitergeleitete Nachricht von Alexey Kozlov - Date: Fri, 18 Aug 2023 14:17:07 -0700 From: Alexey Kozlov To: amkozlov/raxml-ng Cc: Andreas Tille , Author Subject: Re: [amkozlov/raxml-ng] What libpll code is really needed (Issue #164) > If I simply would package libpll-2 in the very place where libpll was > packaged and I keep *that* name (without the -2) this would be pretty > convenient since its not a new Debian package and does not need any new > processing. Do you think this is the correct way to go? Yes, I think this is the way to go. In fact, in the next major raxml-ng release, both `libpll-2` and `pll-modules` will be superseded by the new lib `coraxlib`: https://codeberg.org/Exelixis-Lab/coraxlib This should hopefully solve the long-lasting historical name confusion. -- Reply to this email directly or view it on GitHub: https://github.com/amkozlov/raxml-ng/issues/164#issuecomment-1684443628 You are receiving this because you authored the thread. Message ID: - Ende weitergeleitete Nachricht - -- https://fam-tille.de
Re: [amkozlov/raxml-ng] What libpll code is really needed (Issue #164)
> If I simply would package libpll-2 in the very place where libpll was > packaged and I keep *that* name (without the -2) this would be pretty > convenient since its not a new Debian package and does not need any new > processing. Do you think this is the correct way to go? Yes, I think this is the way to go. In fact, in the next major raxml-ng release, both `libpll-2` and `pll-modules` will be superseded by the new lib `coraxlib`: https://codeberg.org/Exelixis-Lab/coraxlib This should hopefully solve the long-lasting historical name confusion. -- Reply to this email directly or view it on GitHub: https://github.com/amkozlov/raxml-ng/issues/164#issuecomment-1684443628 You are receiving this because you authored the thread. Message ID:
Re: emboss and python-biopython stuck in Building state
Hi Étienne, On 2024-04-23 20:25, Étienne Mollier wrote: r-cran-hunspell looks also affected on armel: r-cran-hunspell (6d 7h 31m, arm-arm-01) python-biopython (6d 5h 16m, arm-arm-03) also pyresample on arm64: emboss (6d 7h 49m, arm-arm-01) pyresample (6d 7h 9m, arm-arm-04) and on armhf: pyresample (6d 7h 10m, arm-arm-01) none of which look to need that long to build. It could be that something went off with some Arm (ltd) runners. Thanks for investigating the issue and contacting the Wanna Build Team. Let us see how that goes. Apparently something is off with arm-arm-* buildds, as arm-conova-* buildds worked just fine for me yesterday. Best wishes, Andrius
Re: emboss and python-biopython stuck in Building state
Hi Wanna Build Team, Just in case this flown below the radar in the past week, you might want to be aware of the below packages stuck in Building state on various arm-arm-* buildd: Étienne Mollier, on 2024-04-23: > Andrius Merkys, on 2024-04-23: > > Five days ago I have uploaded emboss and python-biopython. Both are stuck in > > "Building" state since then, emboss on arm64 and python-biopython on armel. > > This is strange to me, as normally long builds timeout after periods of > > inactivity (no output). I have successfully rebuilt emboss on amdahl.d.o in > > a couple of minutes. > > > > Has anybody experienced similar issues lately? > > r-cran-hunspell looks also affected on armel: > > r-cran-hunspell (6d 7h 31m, arm-arm-01) > python-biopython (6d 5h 16m, arm-arm-03) > > also pyresample on arm64: > > emboss (6d 7h 49m, arm-arm-01) > pyresample (6d 7h 9m, arm-arm-04) > > and on armhf: > > pyresample (6d 7h 10m, arm-arm-01) > > none of which look to need that long to build. > > It could be that something went off with some Arm (ltd) runners. It's a bit unclear to us whether there is something wrong on the package side. Symptoms make me suspect that affected buildd host(s) might be tired at the moment. In hope this helps, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Anathema - One Last Goodbye signature.asc Description: PGP signature
Re: emboss and python-biopython stuck in Building state
Hi Andrius, Andrius Merkys, on 2024-04-23: > Five days ago I have uploaded emboss and python-biopython. Both are stuck in > "Building" state since then, emboss on arm64 and python-biopython on armel. > This is strange to me, as normally long builds timeout after periods of > inactivity (no output). I have successfully rebuilt emboss on amdahl.d.o in > a couple of minutes. > > Has anybody experienced similar issues lately? r-cran-hunspell looks also affected on armel: r-cran-hunspell (6d 7h 31m, arm-arm-01) python-biopython (6d 5h 16m, arm-arm-03) also pyresample on arm64: emboss (6d 7h 49m, arm-arm-01) pyresample (6d 7h 9m, arm-arm-04) and on armhf: pyresample (6d 7h 10m, arm-arm-01) none of which look to need that long to build. It could be that something went off with some Arm (ltd) runners. In hope this helps, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/0, please excuse my verbosity `- signature.asc Description: PGP signature
emboss and python-biopython stuck in Building state
Hello, Five days ago I have uploaded emboss and python-biopython. Both are stuck in "Building" state since then, emboss on arm64 and python-biopython on armel. This is strange to me, as normally long builds timeout after periods of inactivity (no output). I have successfully rebuilt emboss on amdahl.d.o in a couple of minutes. Has anybody experienced similar issues lately? Best, Andrius
Re: Status of the t64 transition
Hi Sebastian, Andreas Tille, on 2024-04-19: > I've spotted these Debian Med packages. […] > Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher: […] > > jellyfish > > quorum […] > No idea how we can help here. Please let us know if we can do > something. About these two packages, I'm not 100% sure, but I believe some confusion may stem from jellyfish's support removal for 32-bit architectures[1,2]. This made the transition unnecessary so the package renaming has been undone in version 2.3.1-3, as far as I can witness in the changelog. This probably affected quorum transitively; and also this possibly affected crac, the other libjellyfish-2.0-2 reverse dependency, although I don't know why it hasn't stood out on the list. [1]: https://bugs.debian.org/1067166 [2]: https://github.com/gmarcais/Jellyfish/pull/202#issuecomment-2007544485 In hope this clarifies things, -- .''`. Étienne Mollier : :' : pgp: 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: Status of the t64 transition
Hi Sebastian, thank you for your work on t64 transition. Am Thu, Apr 18, 2024 at 09:22:02PM +0200 schrieb Sebastian Ramacher: I've spotted these Debian Med packages. > gentle > jellyfish > quorum > sbmltoolbox No idea how we can help here. Please let us know if we can do something. > anfo We like to fix gcc-12 issues (#1012893) in anfo but so far nobody managed to do so since it seems to be quite complex. If we are blocking progress with this package its probably a sign that it should be removed from Debian. > blasr We try to work on #1067374. > freebayes Upstream is working on bug #1067271. > vg This package is in a bad state in any case and we are aware of this. However, could you explain in how far is this affecting t64 transition since 32bit architectures are excluded? > If you maintain any of the packages above, please check their status and > help get them fixed. Any help in filing bugs, fixing packages, > requesting removals, etc. is appreciated so that we can look into > unblocking the whole stack and migrate it to testing. I fixed two packages of Debian Python Team and pinged about some packages in Debian Science Team. Kind regards Andreas. -- https://fam-tille.de
Re: Emboss not migrating due to autopkgtest error on s390x
Am Wed, Apr 17, 2024 at 03:20:27PM +0300 schrieb Andrius Merkys: > I have added the build-time test and filed the needed RM bugs + removed > python-biopython test-dependency on emboss on s390x. Thanks a lot Andreas. -- https://fam-tille.de
Re: Emboss not migrating due to autopkgtest error on s390x
Hi Nilesh, On 2024-04-16 17:03, Nilesh Patra wrote: On Tue, Apr 16, 2024 at 04:52:01PM +0300, Andrius Merkys wrote: On 2024-04-16 15:04, Nilesh Patra wrote: OTOH, does anyone actually use s390x for any med team package? If not, can we consider to add this too along with other 32-bit archs to our policy? Personally, I do not like the idea of deny-listing architectures in team policy. But I am not an uploader of emboss, I merely care for it as a dependency for oscar4. Sure, but if there is no user for those packages at all on s390x, would that not translate to: a) extra maintenance True. b) more build cycles / load on porter machines / more cost so on? I think this is a reasonable price to keep an architecture among release architectures. I would suggest the following course of action for emboss: 1. Add a build-time test calling emboss executable(s). This way builds will fail on s390x (and possibly other architectures) until #1069098 is fixed. 2. RM emboss for s390x without excluding s390x from build architectures. This way emboss will be able to migrate and there will be no action needed if/when #1069098 is fixed. Makes sense to me. I have added the build-time test and filed the needed RM bugs + removed python-biopython test-dependency on emboss on s390x. Best, Andrius
Re: Emboss not migrating due to autopkgtest error on s390x
Am Tue, Apr 16, 2024 at 07:33:15PM +0530 schrieb Nilesh Patra: > > I would suggest the following course of action for emboss: > > > > 1. Add a build-time test calling emboss executable(s). This way builds will > > fail on s390x (and possibly other architectures) until #1069098 is fixed. > > > > 2. RM emboss for s390x without excluding s390x from build architectures. > > > > This way emboss will be able to migrate and there will be no action needed > > if/when #1069098 is fixed. > > Makes sense to me. +1 Kind regards Andreas. -- https://fam-tille.de
Re: Emboss not migrating due to autopkgtest error on s390x
Hi Andrius, On Tue, Apr 16, 2024 at 04:52:01PM +0300, Andrius Merkys wrote: > On 2024-04-16 15:04, Nilesh Patra wrote: > > I suppose you meant "RM" instead of "BTS" here. Thanks for filing a report. > > No, I meant filing a BTS bug, which I did file as #1069098 in order to keep > track of the issue in previous Debian releases too. Right. > > OTOH, does anyone actually use s390x for any med team package? If not, can > > we > > consider to add this too along with other 32-bit archs to our policy? > > Personally, I do not like the idea of deny-listing architectures in team > policy. But I am not an uploader of emboss, I merely care for it as a > dependency for oscar4. Sure, but if there is no user for those packages at all on s390x, would that not translate to: a) extra maintenance b) more build cycles / load on porter machines / more cost so on? > I would suggest the following course of action for emboss: > > 1. Add a build-time test calling emboss executable(s). This way builds will > fail on s390x (and possibly other architectures) until #1069098 is fixed. > > 2. RM emboss for s390x without excluding s390x from build architectures. > > This way emboss will be able to migrate and there will be no action needed > if/when #1069098 is fixed. Makes sense to me. > What do you think? > > Andrius > Best, Nilesh signature.asc Description: PGP signature
Re: Emboss not migrating due to autopkgtest error on s390x
Hi, On 2024-04-16 15:04, Nilesh Patra wrote: I suppose you meant "RM" instead of "BTS" here. Thanks for filing a report. No, I meant filing a BTS bug, which I did file as #1069098 in order to keep track of the issue in previous Debian releases too. OTOH, does anyone actually use s390x for any med team package? If not, can we consider to add this too along with other 32-bit archs to our policy? Personally, I do not like the idea of deny-listing architectures in team policy. But I am not an uploader of emboss, I merely care for it as a dependency for oscar4. I would suggest the following course of action for emboss: 1. Add a build-time test calling emboss executable(s). This way builds will fail on s390x (and possibly other architectures) until #1069098 is fixed. 2. RM emboss for s390x without excluding s390x from build architectures. This way emboss will be able to migrate and there will be no action needed if/when #1069098 is fixed. What do you think? Andrius
Re: Emboss not migrating due to autopkgtest error on s390x
On Tue, Apr 16, 2024 at 02:40:40PM +0300, Andrius Merkys wrote: > On 2024-04-16 03:23, Aaron M. Ucko wrote: > > s390x is a 64-bit architure, so the time_t64 transition was a pure > > formality there. (The old s390 architecture would have been affected > > but retired several years ago.) > > Oh, right, it really is. > > Just checked on a porterbox, apparently all emboss executables segfault on > s390x since bullseye. I believe this deserves a proper BTS bug now. I suppose you meant "RM" instead of "BTS" here. Thanks for filing a report. OTOH, does anyone actually use s390x for any med team package? If not, can we consider to add this too along with other 32-bit archs to our policy? Best, Nilesh signature.asc Description: PGP signature
Bug#1069098: emboss: all executables segfault on s390x
Package: emboss Version: 6.6.0+dfsg-9 Severity: important Tags: bullseye bookworm trixie sid X-Debbugs-CC: debian-med@lists.debian.org Hello, All emboss executables segfault on s390x since bullseye. Segfault is evident when calling any of emboss executables without CLI arguments or only with '--help'. Checking with GDB on sid for 'gdb seqret' says: (gdb) run Starting program: /usr/bin/seqret [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. cvt_s (code=, ap=0x3ff99c0, put=0x3fff77b79b8 , cl=0x3ff9e70, flags=0x3ff99c8, width=-2147483648, precision=-2147483648) at ajfmt.c:352 352if(str) GDB localises the issue for seqret in a string formatting function. Andrius
Re: Emboss not migrating due to autopkgtest error on s390x
On 2024-04-16 03:23, Aaron M. Ucko wrote: s390x is a 64-bit architure, so the time_t64 transition was a pure formality there. (The old s390 architecture would have been affected but retired several years ago.) Oh, right, it really is. Just checked on a porterbox, apparently all emboss executables segfault on s390x since bullseye. I believe this deserves a proper BTS bug now. Best, Andrius
Re: Emboss not migrating due to autopkgtest error on s390x
Steven Robbins writes: > Perhaps that is something worth transmitting to the s390 porters list? > If true, it may mean the issue lies elsewhere and fixes there will mean > emboss > works again. s390x is a 64-bit architure, so the time_t64 transition was a pure formality there. (The old s390 architecture would have been affected but retired several years ago.) -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Emboss not migrating due to autopkgtest error on s390x
On Monday, April 15, 2024 2:06:00 A.M. CDT Andrius Merkys wrote: > GDB localises the issue in a string formatting function. I have a hunch > this might be related to time_64 transition, but cannot say more, alas. Perhaps that is something worth transmitting to the s390 porters list? If true, it may mean the issue lies elsewhere and fixes there will mean emboss works again. -Steve signature.asc Description: This is a digitally signed message part.
Re: Emboss not migrating due to autopkgtest error on s390x
Hi, On 2024-04-14 16:42, Andreas Tille wrote: according to tracker[1] emboss is not migrating due to a test suite error on s390x[2]. IMHO the appropriate thing to do is to also remove s390x architecture - but we also need to care for all rdepends (again after removing these for 32bit). Any volunteer to file the according bugs? emboss autopkgtest on s390x fails with SIGSEGV. GDB for 'gdb seqret' says: (gdb) run Starting program: /usr/bin/seqret [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. cvt_s (code=, ap=0x3ff99c0, put=0x3fff77b79b8 , cl=0x3ff9e70, flags=0x3ff99c8, width=-2147483648, precision=-2147483648) at ajfmt.c:352 352 if(str) GDB localises the issue in a string formatting function. I have a hunch this might be related to time_64 transition, but cannot say more, alas. Removal is the easiest solution for now. I guess adding architecture-is-little-endian to Build-Depends will to the trick to prevent building on s390x. Limiting to architecture-is-little-endian is probably a good idea. We do not have any evidence seqret works on any big-endian architecture. I volunteer to limit the architectures and file RM bugs. [1] https://tracker.debian.org/pkg/emboss [2] https://ci.debian.net/packages/e/emboss/testing/s390x/43624748/ Best, Andrius
We are currently maintaining exactly 1000 packages in main
Hi folks, by chance I looked at https://qa.debian.org/developer.php?email=debian-med-packaging%40lists.alioth.debian.org and realised: main (1000) ;-) Kind regards Andreas. -- https://fam-tille.de
Emboss not migrating due to autopkgtest error on s390x
Hi, according to tracker[1] emboss is not migrating due to a test suite error on s390x[2]. IMHO the appropriate thing to do is to also remove s390x architecture - but we also need to care for all rdepends (again after removing these for 32bit). Any volunteer to file the according bugs? I guess adding architecture-is-little-endian to Build-Depends will to the trick to prevent building on s390x. Kind regards Andreas. [1] https://tracker.debian.org/pkg/emboss [2] https://ci.debian.net/packages/e/emboss/testing/s390x/43624748/ -- https://fam-tille.de
Re: Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Control: severity -1 wishlist Hi, maude has been -rm'ed on 32-bit archs as per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068766 So this issue is now moot and I am downgrading the severity. On Thu, Apr 11, 2024 at 07:53:08AM +0200, Andreas Tille wrote: > Hi, > > Am Wed, Apr 10, 2024 at 03:33:53PM -0700 schrieb Steven Eker: > > I like that solution since I believe there are 64-bit platforms where long > > is 32-bits. I've updated my development version thus: > > > > // > > // timeValue.tv_sec is 64-bit since Linux kernel 5.6 but GMP doesn't > > yet have support > > // for long long which is a problem on platforms where long is less > > than 8 bytes. > > // > > #if SIZEOF_LONG < 8 > > double seconds = timeValue.tv_sec; > > #else > > long seconds = timeValue.tv_sec; > > #endif > > mpz_class nanoSeconds(seconds); > > Sounds like some working solution. It would help if you could tag a new > released to enable us fetching a fresh tarball incorporatinig this > change. > > > Of course I expect to drop support for 32-bit before 2038 - certainly when > > one our dependencies drops support. But I've gotten a bug report for > > building Maude on a Raspberry Pi. > > Raspian is based on Debian and if the 32bit ARM architectures fail here > Raspian people have a problem. > > Kind regards >Andreas. > > -- > https://fam-tille.de > Best, Nilesh signature.asc Description: PGP signature
Re: Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Hi, Am Wed, Apr 10, 2024 at 03:33:53PM -0700 schrieb Steven Eker: > I like that solution since I believe there are 64-bit platforms where long > is 32-bits. I've updated my development version thus: > > // > // timeValue.tv_sec is 64-bit since Linux kernel 5.6 but GMP doesn't > yet have support > // for long long which is a problem on platforms where long is less > than 8 bytes. > // > #if SIZEOF_LONG < 8 > double seconds = timeValue.tv_sec; > #else > long seconds = timeValue.tv_sec; > #endif > mpz_class nanoSeconds(seconds); Sounds like some working solution. It would help if you could tag a new released to enable us fetching a fresh tarball incorporatinig this change. > Of course I expect to drop support for 32-bit before 2038 - certainly when > one our dependencies drops support. But I've gotten a bug report for > building Maude on a Raspberry Pi. Raspian is based on Debian and if the 32bit ARM architectures fail here Raspian people have a problem. Kind regards Andreas. -- https://fam-tille.de
Re: Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
I like that solution since I believe there are 64-bit platforms where long is 32-bits. I've updated my development version thus: // // timeValue.tv_sec is 64-bit since Linux kernel 5.6 but GMP doesn't yet have support // for long long which is a problem on platforms where long is less than 8 bytes. // #if SIZEOF_LONG < 8 double seconds = timeValue.tv_sec; #else long seconds = timeValue.tv_sec; #endif mpz_class nanoSeconds(seconds); Of course I expect to drop support for 32-bit before 2038 - certainly when one our dependencies drops support. But I've gotten a bug report for building Maude on a Raspberry Pi. Steven On 4/10/24 14:59, Aaron M. Ucko wrote: Steven Eker writes: This is harmless on 64-bit architectures since Index will be a signed 64-bit integer and if it works on 32-bit architectures, it's a work around until GMP is fixed (hopefully before 2038). I know this suggestion is unorthodox, and quite possibly moot at this point in the context of official Debian packages -- but you might want to consider formally going through double here, at least on the relevant platforms. Precision loss shouldn't be a concern for another 140 million years or so by my reckoning, and I expect the additional conversion overhead would be negligible in practice. Thanks!
Re: Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Steven Eker writes: > This is harmless on 64-bit architectures since Index will be a signed > 64-bit integer and if it works on 32-bit architectures, it's a work > around until GMP is fixed (hopefully before 2038). I know this suggestion is unorthodox, and quite possibly moot at this point in the context of official Debian packages -- but you might want to consider formally going through double here, at least on the relevant platforms. Precision loss shouldn't be a concern for another 140 million years or so by my reckoning, and I expect the additional conversion overhead would be negligible in practice. Thanks! -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
Re: Bug#1068766: RM: maude [i386 armhf armel] -- ROM; Unsuitable for release on 32-bit archs
On Wed, Apr 10, 2024 at 05:59:13PM +0200, Karsten Hilbert wrote: > Am Wed, Apr 10, 2024 at 09:15:02PM +0530 schrieb Nilesh Patra: > > > since no-one uses med packages on these archs[1]. > > That's certainly not so. OK, I should have chosen different words - will do so next time. > Karsten > -- > GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B > Best, Nilesh signature.asc Description: PGP signature
Re: Bug#1068766: RM: maude [i386 armhf armel] -- ROM; Unsuitable for release on 32-bit archs
Am Wed, Apr 10, 2024 at 09:15:02PM +0530 schrieb Nilesh Patra: > since no-one uses med packages on these archs[1]. That's certainly not so. Karsten -- GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B
Bug#1068766: RM: maude [i386 armhf armel] -- ROM; Unsuitable for release on 32-bit archs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: ma...@packages.debian.org, ti...@debian.org, sramac...@debian.org, debian-med@lists.debian.org Control: affects -1 + src:maude User: ftp.debian@packages.debian.org Usertags: remove Hi, maude FTBFS on 32-bit archs and the temporary fix will explode at some point due to Y2038. This is due to gmp not having proper support for 32-bits. As was a concensus on -med, there's some agreement to remove 32-bit support for end-user applications since no-one uses med packages on these archs[1]. The maintainer/uploader of maude also agreed to the removal on 32-bit archs for this package in[2] [1]: https://lists.debian.org/debian-med/2024/03/msg00032.html [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067957#46
Re: Bug#1067957: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Hi, I'd suggest to set Build-Depends: architecture-is-64-bit, architecture-is-little-endian and remove 32bit architectures of maude. Kind regards Andreas. -- https://fam-tille.de
Re: libcifpp updated
Hi Maarten, On 2024-04-03 18:32, Maarten L. Hekkelman wrote: Could someone with the appropriate powers have a look a the updated package for libcifpp and upload it to the proper location? I guess it needs to go through experimental again? I can give it a look. I noticed that libcifpp git repository on salsa lacks some of the git tags for recent uploads, the latest being debian/5.0.4-1 although there seems to be ~10 uploads since then. Could you please push them? Tags would make it easier for me to see what has changed in between uploads. Best, Andrius
Re: [[maude-bugs]] [EXTERNAL] Re: Maude fails to build on armhf
Hi Sebastian, The lack of long long support in GMP has been the subject of some discussions: https://gmplib.org/list-archives/gmp-bugs/2020-June/thread.html#4771 https://gmplib.org/list-archives/gmp-discuss/2021-January/thread.html#6625 I don't see it happening soon - it took years for the x18 issue on Apple silicon to be fixed. In my development version I've modified the code to: Index seconds = timeValue.tv_sec; // this is 32-bit on 32-bit machines so mpz_class constuctor is defined mpz_class nanoSeconds(seconds); nanoSeconds *= BILLION; nanoSeconds += timeValue.tv_nsec; This is harmless on 64-bit architectures since Index will be a signed 64-bit integer and if it works on 32-bit architectures, it's a work around until GMP is fixed (hopefully before 2038). Steven On 4/9/24 00:01, Sebastian Ramacher wrote: Hi Steven On 2024-04-08 15:38:50 -0700, Steven Eker wrote: Hi Nilish, I don't have a 32-bit machine to test on, but my understanding is that Linux has moved to a 64-bit signed integer for time_t and this is a long long on 32-bit machines which is explicitly not supported by GMP's C++ API. This sounds like it needs to fixed in GMP then. https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Year_2038_problem__;!!DZ3fjg!--tzUBTnQHRKfnkc8PqaPE5gHxPm2QWswg2_MWTbLaWxFFDXu6jiPCjltocalTdckv2oG8G8tDajml0HNO6JIFyo$ https://urldefense.com/v3/__https://gmplib.org/manual/C_002b_002b-Interface-Integers__;!!DZ3fjg!--tzUBTnQHRKfnkc8PqaPE5gHxPm2QWswg2_MWTbLaWxFFDXu6jiPCjltocalTdckv2oG8G8tDajml0HNHAQQdRg$ I'm not happy converting a signed value to an unsigned value for all architectures. But mpz_class nanoSeconds(static_cast(timeValue.tv_sec)); should fix the problem, at least until 2038. Can you check that this works? If so I'll put it in the next public alpha. And this does not sound like a fix which we want. Best Sebastian
Re: [EXTERNAL] Re: [[maude-bugs]] Maude fails to build on armhf
Hi Steven On 2024-04-08 15:38:50 -0700, Steven Eker wrote: > Hi Nilish, > > I don't have a 32-bit machine to test on, but my understanding is that Linux > has moved to a 64-bit signed integer for time_t and this is a long long on > 32-bit machines which is explicitly not supported by GMP's C++ API. This sounds like it needs to fixed in GMP then. > > https://en.wikipedia.org/wiki/Year_2038_problem > https://gmplib.org/manual/C_002b_002b-Interface-Integers > > I'm not happy converting a signed value to an unsigned value for all > architectures. But > > mpz_class nanoSeconds(static_cast(timeValue.tv_sec)); > > should fix the problem, at least until 2038. Can you check that this works? > If so I'll put it in the next public alpha. And this does not sound like a fix which we want. Best Sebastian -- Sebastian Ramacher
Re: [EXTERNAL] Re: [[maude-bugs]] Maude fails to build on armhf
Hi Nilish, I don't have a 32-bit machine to test on, but my understanding is that Linux has moved to a 64-bit signed integer for time_t and this is a long long on 32-bit machines which is explicitly not supported by GMP's C++ API. https://en.wikipedia.org/wiki/Year_2038_problem https://gmplib.org/manual/C_002b_002b-Interface-Integers I'm not happy converting a signed value to an unsigned value for all architectures. But mpz_class nanoSeconds(static_cast(timeValue.tv_sec)); should fix the problem, at least until 2038. Can you check that this works? If so I'll put it in the next public alpha. Steven On 4/7/24 08:28, Nilesh Patra wrote: On Sun, Apr 07, 2024 at 07:45:33PM +0530, Nilesh Patra wrote: Hi, Maude fails to build on armhf/arm32 arch with: In file included from timeManagerSymbol.cc:64: timeActions.cc: In member function ‘void TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode*, ObjectSystemRewritingContext&)’: timeActions.cc:43:41: error: call of overloaded ‘__gmp_expr(__time64_t&)’ is ambiguous 43 | mpz_class nanoSeconds(timeValue.tv_sec); | ^ In file included from ../../src/BuiltIn/succSymbol.hh:28, from timeManagerSymbol.cc:53: /usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(double)’ 1646 | __GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS | ^~ /usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(float)’ Full long here: https://buildd.debian.org/status/fetch.php?pkg=maude=armhf=3.4-1=1712489526=0 And Debian bug report here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067957 Would be great if you have the cycles to look into it. This patch fixes the issue at hand but I am unsure if it is sensible to apply it. diff --git a/src/ObjectSystem/timeActions.cc b/src/ObjectSystem/timeActions.cc index 77395aa..63aa028 100644 --- a/src/ObjectSystem/timeActions.cc +++ b/src/ObjectSystem/timeActions.cc @@ -40,7 +40,7 @@ TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode* message, ObjectSystemRewriting DebugSave(r, clock_gettime(CLOCK_REALTIME, )); Assert(r == 0, "clock_gettime() failed: " << strerror(errno)); - mpz_class nanoSeconds(timeValue.tv_sec); + mpz_class nanoSeconds(static_cast(timeValue.tv_sec)); nanoSeconds *= BILLION; nanoSeconds += timeValue.tv_nsec; Best, Nilesh
Re: Maude fails to build on armhf
On Sun, Apr 07, 2024 at 07:45:33PM +0530, Nilesh Patra wrote: > Hi, > > Maude fails to build on armhf/arm32 arch with: > > In file included from timeManagerSymbol.cc:64: > timeActions.cc: In member function ‘void > TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode*, > ObjectSystemRewritingContext&)’: > timeActions.cc:43:41: error: call of overloaded ‘__gmp_expr(__time64_t&)’ is > ambiguous >43 | mpz_class nanoSeconds(timeValue.tv_sec); > | ^ > In file included from ../../src/BuiltIn/succSymbol.hh:28, > from timeManagerSymbol.cc:53: > /usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], > __mpz_struct [1]>::__gmp_expr(double)’ > 1646 | __GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS > | ^~ > /usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], > __mpz_struct [1]>::__gmp_expr(float)’ > > Full long here: > https://buildd.debian.org/status/fetch.php?pkg=maude=armhf=3.4-1=1712489526=0 > And Debian bug report here: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067957 > > Would be great if you have the cycles to look into it. This patch fixes the issue at hand but I am unsure if it is sensible to apply it. diff --git a/src/ObjectSystem/timeActions.cc b/src/ObjectSystem/timeActions.cc index 77395aa..63aa028 100644 --- a/src/ObjectSystem/timeActions.cc +++ b/src/ObjectSystem/timeActions.cc @@ -40,7 +40,7 @@ TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode* message, ObjectSystemRewriting DebugSave(r, clock_gettime(CLOCK_REALTIME, )); Assert(r == 0, "clock_gettime() failed: " << strerror(errno)); - mpz_class nanoSeconds(timeValue.tv_sec); + mpz_class nanoSeconds(static_cast(timeValue.tv_sec)); nanoSeconds *= BILLION; nanoSeconds += timeValue.tv_nsec; Best, Nilesh signature.asc Description: PGP signature
Maude fails to build on armhf
Hi, Maude fails to build on armhf/arm32 arch with: In file included from timeManagerSymbol.cc:64: timeActions.cc: In member function ‘void TimeManagerSymbol::getTimeSinceEpoch(FreeDagNode*, ObjectSystemRewritingContext&)’: timeActions.cc:43:41: error: call of overloaded ‘__gmp_expr(__time64_t&)’ is ambiguous 43 | mpz_class nanoSeconds(timeValue.tv_sec); | ^ In file included from ../../src/BuiltIn/succSymbol.hh:28, from timeManagerSymbol.cc:53: /usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(double)’ 1646 | __GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS | ^~ /usr/include/gmpxx.h:1646:3: note: candidate: ‘__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(float)’ Full long here: https://buildd.debian.org/status/fetch.php?pkg=maude=armhf=3.4-1=1712489526=0 And Debian bug report here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067957 Would be great if you have the cycles to look into it. Best, Nilesh signature.asc Description: PGP signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On Saturday, April 6, 2024 7:39:10 A.M. CDT Michael R. Crusoe wrote: > On 29/03/2024 19.44, Steven Robbins wrote: > > I am left with a question whether [reactively dropping troublesome > > architectures] is what you are proposing, or > > whether you mean to preemptively restrict the architectures even when > > they are not troublesome? I would support the former but the latter > > position seems unwarranted to me. > > At least the first, but preferably also the second. Why waste the computing > resources / climate damage / maintainer time when that does not benefit our > users? I guess I would say that, to me, the contention that there is a waste of resources like maintainer time is unproven. I have read all the replies but saw nothing that convinces me of that. What is your estimate of fraction of troublesome packages? > Yes, it is true that compiling for 32-bit and/or big-endian architectures > occasionally highlights coding errors that were otherwise hidden and could > cause problems later. But I'm proposing that it isn't worth it, and that if > a member of the team wishes to restrict the architectures built, they > should do so. To be very precise: I absolutely agree with the position that one doesn't need to adopt heroic efforts to deal with issues on minority architectures - which, in my mind, includes all non-release architectures. As I say, I adhere to this myself and years ago restricted ITK for this reason. Under current policy. In my case, ITK was far and away an outlier. Is your experience different? If we were to adopt policy language that makes it easier to "opt out" of universal architecture coverage - but not change the default - what fraction of packages do you expect you'd choose to opt out on? At this point, I don't see a need to change the default to "64 bits only" for everything in the debian-med umbrella. That seems counter to the Debian spirit. -Steve signature.asc Description: This is a digitally signed message part.
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 02/04/2024 07.54, Andreas Tille wrote: Hi, Am Mon, Apr 01, 2024 at 09:12:49PM +0200 schrieb Sascha Steinbiss: New packages that aren't "Architecture: all": 1. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the "Build-Depends" list in "debian/control". Nice, didn't know about these virtual packages before. Makes sense for new packages -- would this result in an equivalent effect as restricting the "Architecture" list in all binary packages? If we agree about the policy to restrict new packages to the said architectures I'd recommend adding this to our package template[1]. Draft MR is at https://salsa.debian.org/med-team/community/package_template/-/merge_requests/2 ; to be merged after the policy is accepted ; comments appreciated there OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 30/03/2024 01.00, Diane Trout wrote: On Thu, 2024-03-28 at 14:51 +0100, Michael R. Crusoe wrote: Like all policy proposals, this is not meant to be a hard rule for all time. We can and should revisit the issue later! What do you think of the policy being instead of "-med team packages MUST support all current Debian architectures", "-med team packages (CAN or SHOULD) try to support all current Debian architectures." Thank you for introducing this phrasing. I don't think there is a current Debian-Med team policy on architecture support. And from what I can see, there is nothing in the policy of Debian itself that packages SHOULD or MUST support all official Debian architectures. I would suggest "-med team packages SHOULD try to support all 64-bit little-endian architectures. Team packages are allowed to exclude 32-bit and/or big-endian architectures without justification." More details in the MR that I am preparing. Many packages do work fine, but some make no sense without being able to access much more than 4G of memory or have picky CPU architecture dependencies. I don't think the team should automatically turn off all more obscure architectures, but it seems very reasonable to be quite willing disable builds for things that cause problems outside of x86_64/arm64. And riscv64, which I predict will be the next big architecture for scientific computing in a few years. Which is why I'm proposing that we cast a wider net using "64-bit and little-endian". OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 29/03/2024 19.44, Steven Robbins wrote: On Thursday, March 28, 2024 8:51:01 A.M. CDT Michael R. Crusoe wrote: Therefore I personally conclude that: Support Debian-Med packages for 32-bit and/or big-endian architectures is not a good use of our limited resources. I am left with a question whether that is what you are proposing, or whether you mean to preemptively restrict the architectures even when they are not troublesome? I would support the former but the latter position seems unwarranted to me. At least the first, but preferably also the second. Why waste the computing resources / climate damage / maintainer time when that does not benefit our users? Yes, it is true that compiling for 32-bit and/or big-endian architectures occasionally highlights coding errors that were otherwise hidden and could cause problems later. But I'm proposing that it isn't worth it, and that if a member of the team wishes to restrict the architectures built, they should do so. Like all policy proposals, this is not meant to be a hard rule for all time. We can and should revisit the issue later! Absolutely. The working set of machines does change over time as you mention yourself. I remember doing neuroinformatics research coding on SGI IRIX machines -- which will surely date me. :-) :-D OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 29/03/2024 07.21, Andreas Tille wrote: Hi, I'm personally fine with Michaels suggestion in general. :+1: Am Fri, Mar 29, 2024 at 10:13:40AM +0530 schrieb Nilesh Patra: On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe" wrote: There are also packages inside debian med umbrella which are not necessarily related to medicine or bioinformatics. These include some general purpose python packages, some C/C++ libraries et. al. There are packages that reverse-depend on the same. I don't think it's a good idea to remove 32 bit support in *all* the packages that are under our umbrella, but probably only the ones that are end-user applications. When reading Michaels proposal I also was thinking about generic libraries we are packaging as pre-dependencies for our end-user applications. I'd be fine with mentioning those as exceptions from what I consider perfectly sensible for the packages that are really targeting at our user base. Ack. It may be good to move packages not related to medicine to different teams over time but some of them actually don't fit into any availability team as per my understanding and may have to be moved to debian/ namespace. What do you think? I'm not convinced that moving package out of our focus is a good idea. When we did so in the past these packages somehow went out of our focus and we hear back from them only by testing removal warnings. I have no problem with moving packages if there is some request from somewhere else and thus there is some convincing interest that the package is maintained properly. But I would not browse the packages maintained by our team, check which might be of general interest, seek in what other team it might be appropriate, become a member of that team and maybe learn that this team has quite a different policy than we have (as I learned in DPT recently). In short: Keep on maintaining what we have and apply common sense where to restrict the architectures sensibly. BTW. actively restricting the architectures for existing packages just creates work for no use. I think we should simply focus on new packages and those that create some troublesome bug reports that we can deal with by removing unused architectures. Sure, I'll adjust the proposal based upon this feedback and similar comments from others. One other hint: I consider it a good idea to forward our proposed change of policy to debian-devel@l.d.o (once we agreed upon the change - maybe in some MR) for two reasons: 1. There might be a chance we have overlooked something. 2. There might be other teams that are interested in a similar change of policy. This is reasonable, sure. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 29/03/2024 05.43, Nilesh Patra wrote: On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe" wrote: Alas this is an involved process. If we have to do it a lot, it would be nice if someone writes a tool to automate any aspect of the above! --- Fweh, that's a long email. Please do share your feedback here There are also packages inside debian med umbrella which are not necessarily related to medicine or bioinformatics. These include some general purpose python packages, some C/C++ libraries et. al. There are packages that reverse-depend on the same. I don't think it's a good idea to remove 32 bit support in *all* the packages that are under our umbrella, but probably only the ones that are end-user applications. I hear you, thanks. It may be good to move packages not related to medicine to different teams over time but some of them actually don't fit into any availability team as per my understanding and may have to be moved to debian/ namespace. Sure, no reason to abandon a package we care about if there isn't a welcoming team to receive it. What do you think? and on the Debian-Med Matrix channel for instant discussions: https://app.element.io/#/room/#debian-med:matrix.org I'll be happy to open another thread about it, but while we are at it, do you think it makes sense to make this as our official communication media? Most of us don't hang out on #debian-med IRC and it would be a little misleading for someone wanting to contact us. Should we just close the IRC channel and endorse the matrix channel as the official one? The current Debian-Med policy doesn't even mention the IRC channel. I agree, lets make the matrix room official! → https://salsa.debian.org/med-team/policy/-/merge_requests/2 Thanks, Nilesh OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 01/04/2024 21.12, Sascha Steinbiss wrote: Hi all, first of all thanks Michael for this idea and also for the elaborate proposal email that outlines the intended way to go quite well. Thanks! [...] Support Debian-Med packages for 32-bit and/or big-endian architectures is not a good use of our limited resources. Agreed. If there is agreement with this, then I would like an amend the Debain-Med team policy to make it clear that we, as a community of package maintainers and users, are okay with removing support for 32-bit and/or big-endian systems without discussion. I'd probably not go as far as to eagerly _remove_ all support for 32-bit as in RM'ing existing packages that still build and work fine. I'd rather like to see such a policy change to illustrate a common position that we'd rather disable an architecture and RM its binaries rather than fix a non-trivial issue on that platform, which might block a testing transition or cause some other roadblocks for the archs we actually care about. I know that many others in Debian care about their specific niche architecture and would be offended at some random maintainer just dismissing their subjectively reasonable request to fix things. Making it known beforehand where Debian Med puts its focus would help in making such situations feel less personal. How to make implement this policy with the tools available to us in 2024. New packages that aren't "Architecture: all": 1. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the "Build-Depends" list in "debian/control". Nice, didn't know about these virtual packages before. Makes sense for new packages -- would this result in an equivalent effect as restricting the "Architecture" list in all binary packages? Yes, but with the benefit that we don't have to add in new 64-bit/little-endian archs that appear, like that which has been done for riscv64 and loong64 quite often these last few years. Removing architectures in existing packages: [...] This approach looks good. As I said, I'd rather only go this way if the maintainer in question notices that there is a need to do so. I agree that if it turns out that for a package to be removed there are reverse dependencies outside of Debian Med's maintainership which would be affected, we would need to coordinate with the maintainers of these reverse dependencies. My gut feeling says these cases will be exceptional though. I think it could also make sense to think of what to do for other architectures that are not yet covered in Michael's proposal, such as (subjectively) obscure archs that still are considered official release architectures (riscv64, mips64el, ...) or all the non-official architectures (alpha, hurd-*, m68k, ...)? For non-official archs within the context of Debian-Med, I just ignore them unless a simple patch is provided in BTS. They don't block migration to testing, so I don't think about them. Cheers Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 28/03/2024 14.51, Michael R. Crusoe wrote: Dear colleagues and users, [snip] Fweh, that's a long email. Please do share your feedback here and on the Debian-Med Matrix channel for instant discussions: https://app.element.io/#/room/#debian-med:matrix.org Thank you all for the thoughtful and helpful replies! I will reply to some of your messages now and later I will open a merge request to the policy document later with specific text taking the feedback into account. I'll post the link here and we can continue to discuss the details. -- Michael R. Crusoe OpenPGP_signature.asc Description: OpenPGP digital signature
libcifpp updated
Could someone with the appropriate powers have a look a the updated package for libcifpp and upload it to the proper location? I guess it needs to go through experimental again? thanks, -maarten
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi, Am Mon, Apr 01, 2024 at 09:12:49PM +0200 schrieb Sascha Steinbiss: > > > If there is agreement with this, then I would like an amend the > > Debain-Med team policy to make it clear that we, as a community of > > package maintainers and users, are okay with removing support for 32-bit > > and/or big-endian systems without discussion. > > I'd probably not go as far as to eagerly _remove_ all support for 32-bit > as in RM'ing existing packages that still build and work fine. ACK. Finally also removing packages creates some work we finally want to save. I think we should simply apply this policy to new packages and those who start failing for whatever reason with no obvious fix / patch provided. > I know that many others in Debian care about their specific niche > architecture and would be offended at some random maintainer just > dismissing their subjectively reasonable request to fix things. Making > it known beforehand where Debian Med puts its focus would help in making > such situations feel less personal. Fully ACK. > > New packages that aren't "Architecture: all": 1. Add > > "architecture-is-64-bit" and "architecture-is-little-endian" to the > > "Build-Depends" list in "debian/control". > > Nice, didn't know about these virtual packages before. Makes sense for > new packages -- would this result in an equivalent effect as restricting > the "Architecture" list in all binary packages? If we agree about the policy to restrict new packages to the said architectures I'd recommend adding this to our package template[1]. > > Removing architectures in existing packages: > [...] > > This approach looks good. As I said, I'd rather only go this way if the > maintainer in question notices that there is a need to do so. > > I agree that if it turns out that for a package to be removed there are > reverse dependencies outside of Debian Med's maintainership which would > be affected, we would need to coordinate with the maintainers of these > reverse dependencies. My gut feeling says these cases will be > exceptional though. Sure. > I think it could also make sense to think of what to do for other > architectures that are not yet covered in Michael's proposal, such as > (subjectively) obscure archs that still are considered official release > architectures (riscv64, mips64el, ...) or As long as these do not create any trouble its perfectly fine to support these. > all the non-official architectures > (alpha, hurd-*, m68k, ...)? Hurd will be available next year. ;-P Kind regards Andreas. [1] https://salsa.debian.org/med-team/community/package_template/-/blob/master/debian/control?ref_type=heads -- https://fam-tille.de
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi all, first of all thanks Michael for this idea and also for the elaborate proposal email that outlines the intended way to go quite well. [...] Support Debian-Med packages for 32-bit and/or big-endian architectures is not a good use of our limited resources. Agreed. [...] However, I think it is okay if an individual Debian-Med maintainer wishes to support extra architectures, especially if upstream is supportive. Also, agreed. I am very likely not that maintainer. Various times already I have been struck by bug reports and failing builds for release platforms that are probably irrelevant for most users of the affected software. I pushed through to fix the issue while knowing that the typical user would not be using this specific software on, say, s390x or a Raspberry Pi. Yes, I am aware that having all that variety at our fingertips promotes experimentation, but does that really justify the extra effort? But if that maintainer can't keep up, and the package is causing problems for other Debian-Med packages, then we should be okay with removing the extra architectures again. ACK. If there is agreement with this, then I would like an amend the Debain-Med team policy to make it clear that we, as a community of package maintainers and users, are okay with removing support for 32-bit and/or big-endian systems without discussion. I'd probably not go as far as to eagerly _remove_ all support for 32-bit as in RM'ing existing packages that still build and work fine. I'd rather like to see such a policy change to illustrate a common position that we'd rather disable an architecture and RM its binaries rather than fix a non-trivial issue on that platform, which might block a testing transition or cause some other roadblocks for the archs we actually care about. I know that many others in Debian care about their specific niche architecture and would be offended at some random maintainer just dismissing their subjectively reasonable request to fix things. Making it known beforehand where Debian Med puts its focus would help in making such situations feel less personal. How to make implement this policy with the tools available to us in 2024. New packages that aren't "Architecture: all": 1. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the "Build-Depends" list in "debian/control". Nice, didn't know about these virtual packages before. Makes sense for new packages -- would this result in an equivalent effect as restricting the "Architecture" list in all binary packages? Removing architectures in existing packages: [...] This approach looks good. As I said, I'd rather only go this way if the maintainer in question notices that there is a need to do so. I agree that if it turns out that for a package to be removed there are reverse dependencies outside of Debian Med's maintainership which would be affected, we would need to coordinate with the maintainers of these reverse dependencies. My gut feeling says these cases will be exceptional though. I think it could also make sense to think of what to do for other architectures that are not yet covered in Michael's proposal, such as (subjectively) obscure archs that still are considered official release architectures (riscv64, mips64el, ...) or all the non-official architectures (alpha, hurd-*, m68k, ...)? Cheers Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Upgrading fis-gtm and closing CVE-2021-44496 CVE-2021-44504
Ping? Am Sat, Dec 09, 2023 at 06:13:24PM +0100 schrieb Andreas Tille: > Hi Amul, > > I realised that fis-gtm is lagging behind upstream some versions and the > Debian packaged fis-gtm is featuring CVE-2021-44496 and CVE-2021-44504. > It would be great if you could upgrade the Debian package to the latest > upstream version. > > Kind regards, > Andreas. > > -- > http://fam-tille.de > > -- https://fam-tille.de
Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with
Hello again, On 3/30/24 15:04, Nilesh Patra wrote: I have just uploaded it: https://salsa.debian.org/med-team/orthanc-python/-/commit/3cdc765442ab3fce9148c33ba865467983b11e0b Actually, the patch was more of a local workaround based on your system configuration and should stay the way it was for debci based workers/lxc backend. With that change the autopkgtest job fails[1] and that's a bad sign OK, fine, I've just removed the patch from the package. I'll manually reapply it on my local machine if needed. Best, Sébastien-
Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with
Now, the next problem is: The test always succeeds on my standard amd64 architecture. Despite many attempts, I am totally unable to reproduce #1062404. @Paul: How could I reproduce the issue? @Nilesh: Shouldn't this test simply be disabled? OK, I think I have finally found the culprit. This is most probably because the unit test doesn't properly test whether Orthanc has finalized its startup. Indeed, instead of testing the existence of the "orthanc" process, one has to wait until the REST API of Orthanc is actually available. I have just committed the fix: https://salsa.debian.org/med-team/orthanc-python/-/commit/9101662e09d956886da7394bacbb7e81d9cb511a I am now working on a new release that should hopefully close this issue. Do not hesitate to re-open the issue if my fix proves to be insufficient. Kind Regards, Sébastien-
Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with
On Sat, Mar 30, 2024 at 02:26:07PM +0100, Sébastien Jodogne wrote: > > For some reason, this is not taking needs-sudo restriction well. Can you > > try once with this > > patch (no need to re-compile) and let me know if that helps? > > > > diff --git a/debian/tests/control b/debian/tests/control > > index 5e8c44d..4f9b12a 100644 > > --- a/debian/tests/control > > +++ b/debian/tests/control > > @@ -1,3 +1,3 @@ > > Tests: run-unit-test > > Depends: @, python3, orthanc, curl, libcurl4, orthanc-python, procps > > -Restrictions: needs-sudo, allow-stderr, isolation-container > > +Restrictions: allow-stderr > > Wonderful! I confirm that with this patch, I am able to run autopkgtest as > follows: > > $ sudo autopkgtest -B ../build-area/orthanc-python_4.1+ds-3_amd64.deb -- > null > > I have just uploaded it: > https://salsa.debian.org/med-team/orthanc-python/-/commit/3cdc765442ab3fce9148c33ba865467983b11e0b Actually, the patch was more of a local workaround based on your system configuration and should stay the way it was for debci based workers/lxc backend. With that change the autopkgtest job fails[1] and that's a bad sign :-) > Now, the next problem is: The test always succeeds on my standard amd64 > architecture. Despite many attempts, I am totally unable to reproduce > #1062404. > > @Paul: How could I reproduce the issue? > > @Nilesh: Shouldn't this test simply be disabled? The test was added to ensure the binary actually works with rest of the Debian ecosytem -- if you feel that's not needed, sure feel free to drop it -- your judgement is more qualified than mine since you're the upstream maintainer, so I defer that decision onto you. [1]: https://salsa.debian.org/med-team/orthanc-python/-/jobs/5519508 Best, Nilesh signature.asc Description: PGP signature
Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with
Hi Nilesh, For some reason, this is not taking needs-sudo restriction well. Can you try once with this patch (no need to re-compile) and let me know if that helps? diff --git a/debian/tests/control b/debian/tests/control index 5e8c44d..4f9b12a 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -1,3 +1,3 @@ Tests: run-unit-test Depends: @, python3, orthanc, curl, libcurl4, orthanc-python, procps -Restrictions: needs-sudo, allow-stderr, isolation-container +Restrictions: allow-stderr Wonderful! I confirm that with this patch, I am able to run autopkgtest as follows: $ sudo autopkgtest -B ../build-area/orthanc-python_4.1+ds-3_amd64.deb -- null I have just uploaded it: https://salsa.debian.org/med-team/orthanc-python/-/commit/3cdc765442ab3fce9148c33ba865467983b11e0b Now, the next problem is: The test always succeeds on my standard amd64 architecture. Despite many attempts, I am totally unable to reproduce #1062404. @Paul: How could I reproduce the issue? @Nilesh: Shouldn't this test simply be disabled? Kind Regards, Sébastien-
Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with
Hi Sébastien, On Sat, Mar 30, 2024 at 12:51:56PM +0100, Sébastien Jodogne wrote: > On 3/30/24 12:41, Nilesh Patra wrote: > > > Once compilation is done, how can I execute autopkgtest? I have tried > > > multiple variations, including the most basic: > > > > > > $ sudo autopkgtest . -- null > > > $ sudo autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.changes -- > > > null > > > > This should work I suppose, in an unstable system. > > I however pass in the .deb instead of the .changes file. > > > > This is the command I use incase that helps you: > > > > $ sudo autopkgtest -B ../*.deb -- schroot unstable-amd64-sbuild > > > > You could use `-- null` if you don't use a schroot. > > > > If this still does not work, can you share the error that you see? > > In all of those commands (including yours, as well as if using ".deb" > instead of ".changes"), I always get the attached log. > > The actual test seems to never be executed: The autopkgtest command always > stops with the "Reading package lists...". Nothing more happens. > ... > Removing autopkgtest-satdep (0) ... > run-unit-testSKIP Cannot enable needs-sudo restriction: no ordinary > user available > autopkgtest [12:47:49]: summary > run-unit-testSKIP Cannot enable needs-sudo restriction: no ordinary > user available For some reason, this is not taking needs-sudo restriction well. Can you try once with this patch (no need to re-compile) and let me know if that helps? diff --git a/debian/tests/control b/debian/tests/control index 5e8c44d..4f9b12a 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -1,3 +1,3 @@ Tests: run-unit-test Depends: @, python3, orthanc, curl, libcurl4, orthanc-python, procps -Restrictions: needs-sudo, allow-stderr, isolation-container +Restrictions: allow-stderr signature.asc Description: PGP signature
Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with
Dear Nilesh, Thanks for your so fast support! On 3/30/24 12:41, Nilesh Patra wrote: Once compilation is done, how can I execute autopkgtest? I have tried multiple variations, including the most basic: $ sudo autopkgtest . -- null $ sudo autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.changes -- null This should work I suppose, in an unstable system. I however pass in the .deb instead of the .changes file. This is the command I use incase that helps you: $ sudo autopkgtest -B ../*.deb -- schroot unstable-amd64-sbuild You could use `-- null` if you don't use a schroot. If this still does not work, can you share the error that you see? In all of those commands (including yours, as well as if using ".deb" instead of ".changes"), I always get the attached log. The actual test seems to never be executed: The autopkgtest command always stops with the "Reading package lists...". Nothing more happens. Regards, Sébastien-$ sudo autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.deb -- null autopkgtest [12:47:42]: starting date and time: 2024-03-30 12:47:42+0100 autopkgtest [12:47:42]: version 5.33 autopkgtest [12:47:42]: host debian-unstable; command line: /usr/bin/autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.deb -- null autopkgtest [12:47:42]: testbed dpkg architecture: amd64 autopkgtest [12:47:42]: testbed apt version: 2.7.14 autopkgtest [12:47:42]: testbed running kernel: Linux 6.7.9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.7.9-2 (2024-03-13) autopkgtest [12:47:42]: unbuilt-tree . autopkgtest [12:47:42]: testing package orthanc-python version 4.1+ds-2 autopkgtest [12:47:42]: build not needed autopkgtest [12:47:42]: test run-unit-test: preparing testbed Get:1 file:/tmp/autopkgtest.I5zY18/binaries InRelease Ign:1 file:/tmp/autopkgtest.I5zY18/binaries InRelease Get:2 file:/tmp/autopkgtest.I5zY18/binaries Release [816 B] Get:2 file:/tmp/autopkgtest.I5zY18/binaries Release [816 B] Get:3 file:/tmp/autopkgtest.I5zY18/binaries Release.gpg Ign:3 file:/tmp/autopkgtest.I5zY18/binaries Release.gpg Get:4 file:/tmp/autopkgtest.I5zY18/binaries Packages [1,379 B] Reading package lists... Reading package lists... Building dependency tree... Reading state information... Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 0 B/193 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 file:/tmp/autopkgtest.I5zY18/binaries orthanc-python 4.1+ds-2 [193 kB] (Reading database ... 196769 files and directories currently installed.) Preparing to unpack .../binaries/./orthanc-python.deb ... Unpacking orthanc-python (4.1+ds-2) over (4.1+ds-2) ... Setting up orthanc-python (4.1+ds-2) ... Processing triggers for libc-bin (2.37-15.1) ... Processing triggers for orthanc (1.12.3+dfsg-1) ... orthanc-restart-trigger: restarting the Orthanc service W: --force-yes is deprecated, use one of the options starting with --allow instead. Reading package lists... Done Building dependency tree... Done Reading state information... Done Note, selecting 'autopkgtest-satdep' instead of '/tmp/autopkgtest.I5zY18/2-autopkgtest-satdep.deb' Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done The following NEW packages will be installed: autopkgtest-satdep 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/736 B of archives. After this operation, 0 B of additional disk space will be used. Get:1 /tmp/autopkgtest.I5zY18/2-autopkgtest-satdep.deb autopkgtest-satdep amd64 0 [736 B] Selecting previously unselected package autopkgtest-satdep. (Reading database ... 196769 files and directories currently installed.) Preparing to unpack .../2-autopkgtest-satdep.deb ... Unpacking autopkgtest-satdep (0) ... Setting up autopkgtest-satdep (0) ... (Reading database ... 196769 files and directories currently installed.) Removing autopkgtest-satdep (0) ... run-unit-testSKIP Cannot enable needs-sudo restriction: no ordinary user available autopkgtest [12:47:49]: summary run-unit-testSKIP Cannot enable needs-sudo restriction: no ordinary user available autopkgtest [12:47:49]: Binaries: resetting testbed apt configuration Hit:1 http://deb.debian.org/debian unstable InRelease Reading package lists...
Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with
On Sat, Mar 30, 2024 at 12:28:45PM +0100, Sébastien Jodogne wrote: > Hello, > > On 2/1/24 17:36, Nilesh Patra wrote: > > On Thu, Feb 01, 2024 at 01:55:21PM +0100, Sébastien Jodogne wrote: > > > Even if I'm tagged as the maintainer of "orthanc-python", I don't know > > > how autopkgtest/flaky works (I haven't implemented such tests by > > > myself). > > > > This is the script that runs for tests: > > > > > > https://salsa.debian.org/med-team/orthanc-python/-/blob/master/debian/tests/run-unit-test?ref_type=heads > > > > This is a basic script that should work and did work at least locally -- > > note that I only "sponsored" > > an upload for this package and did not delve very deep into the working > > detaiks. > > Please, I really need help here. Despite hours of trial and error, I'm still > unable to understand how autopkgtest works. Unfortunately, I can't find by > myself a Debian tutorial on how to run such tests. There's a tutorial inside the autopkgtest package itself: $ zcat /usr/share/doc/autopkgtest/README.running-tests.rst.gz > At time point, I build the package using the following command line: > > $ gbp buildpackage -us -uc --git-pristine-tar > --git-export-dir=../build-area/ -j4 > > Once compilation is done, how can I execute autopkgtest? I have tried > multiple variations, including the most basic: > > $ sudo autopkgtest . -- null > $ sudo autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.changes -- > null This should work I suppose, in an unstable system. I however pass in the .deb instead of the .changes file. This is the command I use incase that helps you: $ sudo autopkgtest -B ../*.deb -- schroot unstable-amd64-sbuild You could use `-- null` if you don't use a schroot. If this still does not work, can you share the error that you see? > as well as the use of qemu: > > $ sudo autopkgtest-build-qemu unstable /var/tmp/autopkgtest-unstable.img > $ sudo autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.changes -- > qemu /var/tmp/autopkgtest-unstable.img > > Could someone indicate me the proper way of calling autopkgtest so that I > can debug the test that was sponsored? I apologize that this upload is creating some un-necessary mess for you Best, Nilesh signature.asc Description: PGP signature
Re: [Debian-med-packaging] Bug#1062404: orthanc-python: flaky autopkgtest: Test failed with
Hello, On 2/1/24 17:36, Nilesh Patra wrote: On Thu, Feb 01, 2024 at 01:55:21PM +0100, Sébastien Jodogne wrote: Even if I'm tagged as the maintainer of "orthanc-python", I don't know how autopkgtest/flaky works (I haven't implemented such tests by myself). This is the script that runs for tests: https://salsa.debian.org/med-team/orthanc-python/-/blob/master/debian/tests/run-unit-test?ref_type=heads This is a basic script that should work and did work at least locally -- note that I only "sponsored" an upload for this package and did not delve very deep into the working detaiks. Please, I really need help here. Despite hours of trial and error, I'm still unable to understand how autopkgtest works. Unfortunately, I can't find by myself a Debian tutorial on how to run such tests. At time point, I build the package using the following command line: $ gbp buildpackage -us -uc --git-pristine-tar --git-export-dir=../build-area/ -j4 Once compilation is done, how can I execute autopkgtest? I have tried multiple variations, including the most basic: $ sudo autopkgtest . -- null $ sudo autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.changes -- null as well as the use of qemu: $ sudo autopkgtest-build-qemu unstable /var/tmp/autopkgtest-unstable.img $ sudo autopkgtest ../build-area/orthanc-python_4.1+ds-2_amd64.changes -- qemu /var/tmp/autopkgtest-unstable.img Could someone indicate me the proper way of calling autopkgtest so that I can debug the test that was sponsored? Kind Regards, Sébastien-
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On Thu, 2024-03-28 at 14:51 +0100, Michael R. Crusoe wrote: > > Like all policy proposals, this is not meant to be a hard rule for > all time. We can and should revisit the issue later! What do you think of the policy being instead of "-med team packages MUST support all current Debian architectures", "-med team packages (CAN or SHOULD) try to support all current Debian architectures." Many packages do work fine, but some make no sense without being able to access much more than 4G of memory or have picky CPU architecture dependencies. I don't think the team should automatically turn off all more obscure architectures, but it seems very reasonable to be quite willing disable builds for things that cause problems outside of x86_64/arm64. Diane signature.asc Description: This is a digitally signed message part
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On Thursday, March 28, 2024 8:51:01 A.M. CDT Michael R. Crusoe wrote: > Therefore I personally conclude that: > Support Debian-Med packages for 32-bit and/or big-endian architectures is > not a good use of our limited resources. I've used that as a personal policy for years. In my case, I restrict the architecture set ONLY when maintaining all architectures becomes a burden. So far it has happened only in one package (ITK), and its downstream dependencies. I am left with a question whether that is what you are proposing, or whether you mean to preemptively restrict the architectures even when they are not troublesome? I would support the former but the latter position seems unwarranted to me. > Like all policy proposals, this is not meant to be a hard rule for all time. > We can and should revisit the issue later! Absolutely. The working set of machines does change over time as you mention yourself. I remember doing neuroinformatics research coding on SGI IRIX machines -- which will surely date me. :-) -Steve signature.asc Description: This is a digitally signed message part.
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hello, On 2024-03-29 06:43, Nilesh Patra wrote:> There are also packages inside debian med umbrella which are not necessarily related to medicine or bioinformatics. These include some general purpose python packages, some C/C++ libraries et. al. There are packages that reverse-depend on the same. I don't think it's a good idea to remove 32 bit support in *all* the packages that are under our umbrella, but probably only the ones that are end-user applications. It may be good to move packages not related to medicine to different teams over time but some of them actually don't fit into any availability team as per my understanding and may have to be moved to debian/ namespace. I think Nilesh raises very important points. Personally I see no problem in leaving arch:any in debian/control and from time to time RMing the failing architectures. Best wishes, Andrius
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi Charles, Am Fri, Mar 29, 2024 at 03:48:07PM +0900 schrieb Charles Plessy: > > For the moment it would be easy to make sure at least new r-bioc-* > > packages are restricted to the said architectures by adding this to > > dh-r. > > I fully agree. I've pushed an (only weakly tested) patch to dh-r[1] implementing this. If you think this is fine, feel free to upload a new version of dh-r which enables wider testing. > By the way the next Bioconductor is scheduled for May 1st, shortly after > the R 4.4 release. Thanks for the information. I'd be super happy if this would be managed without my help in case I might become elected as DPL. I'm willing to take part but I have no idea how much my Debian time will be occupied. Kind regards Andreas. [1] https://salsa.debian.org/r-pkg-team/dh-r/-/commit/72571478f4bc889675a60a9a05d7ef31e8bbba15 -- https://fam-tille.de
irc #debian-med and #debian-med:matrix.org (was: Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages)
Hi, On Fri, Mar 29, 2024 at 07:21:27AM +0100, Andreas Tille wrote: > Am Fri, Mar 29, 2024 at 10:13:40AM +0530 schrieb Nilesh Patra: > > On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe" > > wrote: > > >and on the Debian-Med Matrix channel for instant discussions: > > >https://app.element.io/#/room/#debian-med:matrix.org > > > > I'll be happy to open another thread about it, but while we are at it, do > > you think it makes sense to make this as our official communication media? > > > > Most of us don't hang out on #debian-med IRC and it would be a little > > misleading for someone wanting to contact us. > > From my perspective the main drawpack of IRC is that you can't search in > history. What about setting the title of #debian-med IRC pointing to > our matrix channel? This would make easily clear what we prefered as > communication channel. > > > Should we just close the IRC channel and endorse the matrix channel as the > > official one? > > I do not use it but it makes sense to ask on IRC whether people > like this channel for whatever reason. FWIW, currently the title of the #debian-med IRC channel _does_ point to matrix: пет 29 09:54 -!- Topic for #debian-med: Find us now at https://app.element.io/#/room/#debian-med:matrix.org ! пет 29 09:54 -!- Topic set by ChanServ [servi...@services.oftc.net] [Wed Dec 21 01:54:21 2022] And: пет 29 09:54 [Users #debian-med] пет 29 09:54 [ azeem ] [ FloodServ ] [ matrix_ds ] [ tarzeau_ ] пет 29 09:54 [ charojovi[m] ] [ hlieberman] [ pabs] [ tassia ] пет 29 09:54 [ crusoe] [ joostvb ] [ pere] [ utkarsh2102] пет 29 09:54 [ dr-hax[m] ] [ KGB ] [ sanjkrsna[m]] [ yoh] пет 29 09:54 [ emollier ] [ KGB-2 ] [ satta ] пет 29 09:54 [ felipegmaia419] [ mapreri ] [ sivoais ] пет 29 09:54 -!- Irssi: #debian-med: Total of 22 nicks [0 ops, 0 halfops, 0 voices, 22 normal] пет 29 09:54 -!- Channel #debian-med created Mon Aug 20 03:47:08 2012 пет 29 09:54 -!- Irssi: Join to #debian-med was synced in 1 secs пет 29 09:54 -ChanServ(servi...@services.oftc.net)- [#debian-med] Welcome to Debian-Med -- enjoy Free Software! HTH, Bye, Joost
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Le Fri, Mar 29, 2024 at 07:21:27AM +0100, Andreas Tille a écrit : > > For the moment it would be easy to make sure at least new r-bioc-* > packages are restricted to the said architectures by adding this to > dh-r. I fully agree. By the way the next Bioconductor is scheduled for May 1st, shortly after the R 4.4 release. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy - You do not have my permission to use this email to train an AI -
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Hi, I'm personally fine with Michaels suggestion in general. Am Fri, Mar 29, 2024 at 10:13:40AM +0530 schrieb Nilesh Patra: > > > On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe" > wrote: > > There are also packages inside debian med umbrella which are not necessarily > related to medicine or bioinformatics. These include some general purpose > python packages, some C/C++ libraries et. al. There are packages that > reverse-depend on the same. I don't think it's a good idea to remove 32 bit > support in *all* the packages that are under our umbrella, but probably only > the ones that are end-user applications. When reading Michaels proposal I also was thinking about generic libraries we are packaging as pre-dependencies for our end-user applications. I'd be fine with mentioning those as exceptions from what I consider perfectly sensible for the packages that are really targeting at our user base. > It may be good to move packages not related to medicine to different teams > over time but some of them actually don't fit into any availability team as > per my understanding and may have to be moved to debian/ namespace. > > What do you think? I'm not convinced that moving package out of our focus is a good idea. When we did so in the past these packages somehow went out of our focus and we hear back from them only by testing removal warnings. I have no problem with moving packages if there is some request from somewhere else and thus there is some convincing interest that the package is maintained properly. But I would not browse the packages maintained by our team, check which might be of general interest, seek in what other team it might be appropriate, become a member of that team and maybe learn that this team has quite a different policy than we have (as I learned in DPT recently). In short: Keep on maintaining what we have and apply common sense where to restrict the architectures sensibly. BTW. actively restricting the architectures for existing packages just creates work for no use. I think we should simply focus on new packages and those that create some troublesome bug reports that we can deal with by removing unused architectures. One other hint: I consider it a good idea to forward our proposed change of policy to debian-devel@l.d.o (once we agreed upon the change - maybe in some MR) for two reasons: 1. There might be a chance we have overlooked something. 2. There might be other teams that are interested in a similar change of policy. > >and on the Debian-Med Matrix channel for instant discussions: > >https://app.element.io/#/room/#debian-med:matrix.org > > I'll be happy to open another thread about it, but while we are at it, do you > think it makes sense to make this as our official communication media? > > Most of us don't hang out on #debian-med IRC and it would be a little > misleading for someone wanting to contact us. >From my perspective the main drawpack of IRC is that you can't search in history. What about setting the title of #debian-med IRC pointing to our matrix channel? This would make easily clear what we prefered as communication channel. > Should we just close the IRC channel and endorse the matrix channel as the > official one? I do not use it but it makes sense to ask on IRC whether people like this channel for whatever reason. BTW, the Debian Med team is maintaining lots of packages in R pkg team - most prominently r-bioc-* packages but there are more packages dedicated to our user base. We should probably also write a R pkg policy (which is long overdue). For the moment it would be easy to make sure at least new r-bioc-* packages are restricted to the said architectures by adding this to dh-r. Kind regards Andreas. -- https://fam-tille.de
Re: Debian-Med policy proposal: 64-bit & little-endian only* for new packages
On 28 March 2024 7:21:01 pm IST, "Michael R. Crusoe" wrote: >Alas this is an involved process. If we have to do it a lot, it would be nice >if someone writes a tool to automate any aspect of the above! > >--- > >Fweh, that's a long email. Please do share your feedback here There are also packages inside debian med umbrella which are not necessarily related to medicine or bioinformatics. These include some general purpose python packages, some C/C++ libraries et. al. There are packages that reverse-depend on the same. I don't think it's a good idea to remove 32 bit support in *all* the packages that are under our umbrella, but probably only the ones that are end-user applications. It may be good to move packages not related to medicine to different teams over time but some of them actually don't fit into any availability team as per my understanding and may have to be moved to debian/ namespace. What do you think? >and on the Debian-Med Matrix channel for instant discussions: >https://app.element.io/#/room/#debian-med:matrix.org I'll be happy to open another thread about it, but while we are at it, do you think it makes sense to make this as our official communication media? Most of us don't hang out on #debian-med IRC and it would be a little misleading for someone wanting to contact us. Should we just close the IRC channel and endorse the matrix channel as the official one? Thanks, Nilesh
Debian-Med policy proposal: 64-bit & little-endian only* for new packages
Dear colleagues and users, I would like to propose a change to the Debian-Med team policy: https://med-team.pages.debian.net/policy/ Given that: 1. The package maintainers in the Debian-Med community are volunteers, and all of us have many other demands of our time 2. Debian-Med is targeting the use cases of "medical practice and research". 3. Medical institutions and researchers are almost entirely running on amd64 and arm64 systems. 4. The upstream maintainers of the tools and libraries packaged in Debian-Med are themselves almost entirely volunteers, or if they are maintaining scientific FOSS projects as part of their work then they have academic jobs. 5. There is no tradition of big-endian computing in the biomedical and life sciences. Therefore I personally conclude that: Support Debian-Med packages for 32-bit and/or big-endian architectures is not a good use of our limited resources. (Of course, if the package can only support a subset of the 64-bit+little-endian architectures, that is also acceptable.) However, I think it is okay if an individual Debian-Med maintainer wishes to support extra architectures, especially if upstream is supportive. But if that maintainer can't keep up, and the package is causing problems for other Debian-Med packages, then we should be okay with removing the extra architectures again. If there is agreement with this, then I would like an amend the Debain-Med team policy to make it clear that we, as a community of package maintainers and users, are okay with removing support for 32-bit and/or big-endian systems without discussion. Like all policy proposals, this is not meant to be a hard rule for all time. We can and should revisit the issue later! --- Personal thoughts on Debian's history of bringing up new architectures: 1. This is an aspect of Debian I find to be really impressive! I'm very grateful for it, and I have seen how other packaging systems struggle when they have to add a new architecture for the first time. 2. Note that this policy proposal is not "only amd64" or "only amd64 and arm64". I think supporting new architectures is important to avoid vendor lock-in and provide portability to the future. For example, I hope to see riscv64 HPC and personal computing become popular with researchers, software engineers, and (eventually) the public. 3. I still support adding in compatibility for non-amd64/arm64 to scientific software; especially if SIMD usage is responsible. But I don't think we should make it a team policy that doing such work is required. --- How to make implement this policy with the tools available to us in 2024. New packages that aren't "Architecture: all": 1. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the "Build-Depends" list in "debian/control". Removing architectures in existing packages: 1. Check which reverse-dependencies would also need removal (below is adapted from https://wiki.debian.org/ftpmaster_Removals#Before_requesting_removal ) Debian Developers can run `ssh mirror.ftp-master.debian.org "dak rm --architecture=armel,armhf,i386 --binary-only --partial --rdep-check --no-action $SOURCEPACKAGE"`. I don't know of an alternative for non-DDs, sorry. If any of the reverse-dependencies are not Debian-Med packages (and have successfully built on the affected architectures) then you must get the approval of those maintainers before proceeding. However, that could be a sign that the package should move out from Debian-Med to another team, like Debian-Science, or something non-research/science related. A good example of this is the zstd package, first packaged for Debian-Med in 2015 by Kevin Murray; "libzstd1" now has over 2300 reverse-dependencies! The package "graduated" from Debian Med in 2022 and now maintained by the RPM team 2. Add "architecture-is-64-bit" and "architecture-is-little-endian" to the "Build-Depends" list in "debian/control" and upload a new version of the package to "UNSTABLE". 3. Repeat #2 for each of the affected Debian-med reverse-dependencies (and coordinate with any other maintainers as needed) 4. `reportbug ftp.debian.org` to request a "ROM Package removal - Request Of Maintainer." and list the official architectures to remove the binary packages of: typically that would be "armel armhf i386 s390x". 5. Repeat #4 for each of the affected Debian-med reverse-dependencies. Coordinate with the other maintainers to do the same. 6. Help the FTP team by marking which removal bug block which dependency. 7. Wait for the packages to be removed and the new uploads to migrate to testing, responding to any queries from the FTP team. Alas this is an involved process. If we have to do it a lot, it would be nice if someone writes a tool to automate any aspect of the above! --- Fweh, that's a long email. Please do share your feedback here and on the Debian-Med Matrix channel for instant discussions:
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi Emanuele. Am Tue, Mar 19, 2024 at 12:16:16PM +0100 schrieb Emanuele Rocca: > I've uploaded a NMU to DELAYED/2: https://bugs.debian.org/1067147 Thanks a lot for your attempt to help. In principle we have a team wide low threshold NMU - so undelayed NMUs are fine. The kind of race condition in uploads might imply that some ping in advance might be helpful to avoid duplicated work. > With those changes dcmtk builds fine on both armel and armhf. I've > dropped the graphviz build-depend on those arches too, it can of course > be reintroduced once graphviz become installable again. Meanwhile your patch is imported and was uploaded by Michael - thanks to all who helped solving this. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi Andreas, On 2024-03-19 10:40, Andreas Tille wrote: > Since you all pinged that bug we now have another 4 weeks of time before > anything gets removed from testing. So we just need to bear the noise > from testing removal warnings of quite some packages (which I'd love to > get rid of thus uploading a fix would be great). I've uploaded a NMU to DELAYED/2: https://bugs.debian.org/1067147 With those changes dcmtk builds fine on both armel and armhf. I've dropped the graphviz build-depend on those arches too, it can of course be reintroduced once graphviz become installable again. Emanuele
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi again, sorry, I did not checked the situation. Am Tue, Mar 19, 2024 at 10:34:13AM +0100 schrieb Andreas Tille: > Testing removals are happening automatically if some RC bug exists > for a certain time without pinging. Just writing some additional > information to the bug in question would have prevented this but > nobody of us had sufficient capacity. That's a shame but will be > healed over time (which is hopefully not that long). Since you all pinged that bug we now have another 4 weeks of time before anything gets removed from testing. So we just need to bear the noise from testing removal warnings of quite some packages (which I'd love to get rid of thus uploading a fix would be great). Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Am Tue, Mar 19, 2024 at 09:52:49AM +0100 schrieb Jörg Riesmeier: > Dear all, > > > Indeed, and there is a simple fix too, which has been uploaded to > > experimental only so far: > > yes, there is a simple fix (that disables the error), but there is also a > more fundamental fix that (hopefully) solves the issue at its core: > > > https://git.dcmtk.org/?p=dcmtk.git;a=commit;h=bdc18c85b7fca130464dd745ea3efef3c9b8b94e Thanks for the additional pointer. > Furthermore, it feels kind of strange that the DCMTK package was about to be > removed because a rather insignificant test tool causes problems on a single > platform, and this test tool is even not part of any Debian package (see > "debian/rules" file): Testing removals are happening automatically if some RC bug exists for a certain time without pinging. Just writing some additional information to the bug in question would have prevented this but nobody of us had sufficient capacity. That's a shame but will be healed over time (which is hopefully not that long). Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi Sébastien, Am Tue, Mar 19, 2024 at 09:44:04AM +0100 schrieb Sébastien Jodogne: > > > > > > On 2024-03-19 06:24, Sébastien Jodogne wrote: > > > > Because of bug #1060104, a large majority of the packages related to > > > > medical imaging have just disappeared from Debian Unstable. To be precise s/Unstable/Testing/ (but its a shame anyway). > > > > But, if I correctly understand #1060104, it is specific to one single > > > > platform (armel). > > > > > > Indeed, and there is a simple fix too, which has been uploaded to > > > experimental only so far: > > > https://salsa.debian.org/med-team/dcmtk/-/commit/42583dfe9fd344a63cdbc278268d4176d4a22ec4 > > > > > > Mathieu (or someone else from debian-med), could you please apply that > > > to unstable as well? It seems that with the current state of unstable > > > the transition will take a while anyways. > > > > I will be away from any Debian tasks for at least another month > > unfortunately. The patch was suggested by an armel porter so I believe > > this is the right thing to do. Thanks for confirming. > > > Worth pointing out that right now dcmtk cannot be built in sid/armel due > > > to a missing build depend, namely graphviz. It seems worth applying the > > > fix to unstable anyways so that it does not fall through the cracks, and > > > we can schedule a binNMU later when graphviz is available again. > > I could try to upload this patch by myself to unstable. Unfortunately, I'm > not an uploader of the dcmtk package, so an intervention from a Debian > Developer is required to give me the proper access rights: > https://tracker.debian.org/pkg/dcmtk Upload permission granted. Feel free to keep on asking if something might not work as expected. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Dear all, > Indeed, and there is a simple fix too, which has been uploaded to > experimental only so far: yes, there is a simple fix (that disables the error), but there is also a more fundamental fix that (hopefully) solves the issue at its core: https://git.dcmtk.org/?p=dcmtk.git;a=commit;h=bdc18c85b7fca130464dd745ea3efef3c9b8b94e Furthermore, it feels kind of strange that the DCMTK package was about to be removed because a rather insignificant test tool causes problems on a single platform, and this test tool is even not part of any Debian package (see "debian/rules" file): override_dh_install-arch: [...] #remove test binaries [...] rm ./debian/dcmtk/usr/bin/drttest [...] Regards, Jörg -- Dr. Joerg Riesmeier, Etzhorner Weg 19, 26125 Oldenburg, Germany E-Mail: di...@jriesmeier.com, Homepage: www.jriesmeier.com
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Dear Emmanuele and Mathieu, On 3/19/24 08:51, Mathieu Malaterre wrote: On Tue, Mar 19, 2024 at 8:44 AM Emanuele Rocca wrote: Hi, On 2024-03-19 06:24, Sébastien Jodogne wrote: Because of bug #1060104, a large majority of the packages related to medical imaging have just disappeared from Debian Unstable. But, if I correctly understand #1060104, it is specific to one single platform (armel). Indeed, and there is a simple fix too, which has been uploaded to experimental only so far: https://salsa.debian.org/med-team/dcmtk/-/commit/42583dfe9fd344a63cdbc278268d4176d4a22ec4 Mathieu (or someone else from debian-med), could you please apply that to unstable as well? It seems that with the current state of unstable the transition will take a while anyways. I will be away from any Debian tasks for at least another month unfortunately. The patch was suggested by an armel porter so I believe this is the right thing to do. Worth pointing out that right now dcmtk cannot be built in sid/armel due to a missing build depend, namely graphviz. It seems worth applying the fix to unstable anyways so that it does not fall through the cracks, and we can schedule a binNMU later when graphviz is available again. I could try to upload this patch by myself to unstable. Unfortunately, I'm not an uploader of the dcmtk package, so an intervention from a Debian Developer is required to give me the proper access rights: https://tracker.debian.org/pkg/dcmtk Kind Regards, Sébastien-
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
On Tue, Mar 19, 2024 at 8:44 AM Emanuele Rocca wrote: > > Hi, > > On 2024-03-19 06:24, Sébastien Jodogne wrote: > > Because of bug #1060104, a large majority of the packages related to > > medical imaging have just disappeared from Debian Unstable. > > > > But, if I correctly understand #1060104, it is specific to one single > > platform (armel). > > Indeed, and there is a simple fix too, which has been uploaded to > experimental only so far: > https://salsa.debian.org/med-team/dcmtk/-/commit/42583dfe9fd344a63cdbc278268d4176d4a22ec4 > > Mathieu (or someone else from debian-med), could you please apply that > to unstable as well? It seems that with the current state of unstable > the transition will take a while anyways. I will be away from any Debian tasks for at least another month unfortunately. The patch was suggested by an armel porter so I believe this is the right thing to do. > Worth pointing out that right now dcmtk cannot be built in sid/armel due > to a missing build depend, namely graphviz. It seems worth applying the > fix to unstable anyways so that it does not fall through the cracks, and > we can schedule a binNMU later when graphviz is available again. -M
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Hi, On 2024-03-19 06:24, Sébastien Jodogne wrote: > Because of bug #1060104, a large majority of the packages related to > medical imaging have just disappeared from Debian Unstable. > > But, if I correctly understand #1060104, it is specific to one single > platform (armel). Indeed, and there is a simple fix too, which has been uploaded to experimental only so far: https://salsa.debian.org/med-team/dcmtk/-/commit/42583dfe9fd344a63cdbc278268d4176d4a22ec4 Mathieu (or someone else from debian-med), could you please apply that to unstable as well? It seems that with the current state of unstable the transition will take a while anyways. Worth pointing out that right now dcmtk cannot be built in sid/armel due to a missing build depend, namely graphviz. It seems worth applying the fix to unstable anyways so that it does not fall through the cracks, and we can schedule a binNMU later when graphviz is available again. Thanks! Emanuele
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Dear all, Because of bug #1060104, a large majority of the packages related to medical imaging have just disappeared from Debian Unstable. But, if I correctly understand #1060104, it is specific to one single platform (armel). My question is: Rather than penalizing all platforms (including the most common arm64) and thus a huge number of users working on healthcare application, couldn't a temporary measure be to remove the armel builds? Best Regards, Sébastien- On Sat, 24 Feb 2024 10:03:07 +0100 Sebastian Ramacher wrote: > Control: severity -1 serious > > On 2024-01-18 13:38:20 +0100, Mathieu Malaterre wrote: > > Control: severity -1 important > > > > On Mon, Jan 15, 2024 at 1:49 PM Emanuele Rocca wrote: > > [...] > > > For this reason I would > > > suggest to disable stackclash on the armel build of dcmtk (just like you > > > did in experimental) to make sure the package builds properly again, but > > > keep #1060104 open at a lower severity so that we don't lose track of > > > this. > > > > Done ! Thanks > > dcmtk is still failing to build on unstable buildds, so raising the > severity again to serious. Please only lower the severity once the > package builds again. > > Cheers > -- > Sebastian Ramacher
Re: Bug#1060104: dcmtk: FTBFS on armel: Error: bad immediate value for offset (4100)
Dear all, Because of bug #1060104, a large majority of the packages related to medical imaging have just disappeared from Debian Unstable. But, if I correctly understand #1060104, it is specific to one single platform (armel). My question is: Rather than penalizing all platforms (including the most common arm64) and thus a huge number of users working on healthcare application, couldn't a temporary measure be to remove the armel builds? Note that as far as I'm concerned, I cannot help on armel. Best Regards, Sébastien- On Sat, 24 Feb 2024 10:03:07 +0100 Sebastian Ramacher wrote: Control: severity -1 serious On 2024-01-18 13:38:20 +0100, Mathieu Malaterre wrote: > Control: severity -1 important > > On Mon, Jan 15, 2024 at 1:49 PM Emanuele Rocca wrote: > [...] > > For this reason I would > > suggest to disable stackclash on the armel build of dcmtk (just like you > > did in experimental) to make sure the package builds properly again, but > > keep #1060104 open at a lower severity so that we don't lose track of > > this. > > Done ! Thanks dcmtk is still failing to build on unstable buildds, so raising the severity again to serious. Please only lower the severity once the package builds again. Cheers -- Sebastian Ramacher
Re: Action needed for R-pkg Uploaders
Hi Joost, Am Mon, Mar 18, 2024 at 08:51:27AM +0100 schrieb Joost van Baal-Ilić: > Andreas: thanks a lot for this heads-up, and thanks HUGELY for maintaining the > bulk of the r-cran ecosystem in Debian for such a long time. Thanks to you. I just want to stress again the fact that it is extremely questionable that this will continue in case in my DPL term in case I might become elected. If you all as team members want to profit from up to date r-* packages you not only need to care for those packages you are mentioned as Uploader but care for team wide updates. In other words: "Any team member can and *should* upload team maintained packages no matter who is specified as Uploader." BTW, its perfectly welcome to add additional IDs to Uploaders. > Op Mon, Mar 11, 2024 at 03:47:42PM +0100 schreef Andreas Tille: > > > > > > > Joost van Baal-Ilić : > > r-cran-bdgraph > > r-cran-corpcor > > r-cran-d3network > > r-cran-farver > > r-cran-fdrtool > > r-cran-formatr > > r-cran-ggforce > > r-cran-ggm > > r-cran-ggrepel > > r-cran-glasso > > r-cran-highr > > r-cran-httpuv > > r-cran-huge > > r-cran-hunspell > > r-cran-knitr > > r-cran-lavaan > > r-cran-lisreltor > > r-cran-markdown > > r-cran-matrixcalc > > r-cran-mi > > r-cran-mime > > r-cran-nfactors > > r-cran-qgraph > > r-cran-rcppparallel > > r-cran-rockchalk > > r-cran-sem > > r-cran-semplot > > r-cran-semtools > > r-cran-statcheck > > r-cran-tweenr > > r-cran-yaml > > I'm afraid I won't have time to take care of those in the near > future. However, I _do_ plan to keep maintaining: > > r-cran-lavaan > r-cran-hunspell > r-cran-markdown > r-cran-httpuv > r-cran-statcheck > > (And I've just managed to do upload new upstream of r-cran-statcheck; > routine-update indeed makes life much easier :) Good. > So, would it be usefull to do an upload of the 31 - 5 = 26 other packages > dropping my name from Uploaders: so changing: > > Maintainer: Debian R Packages Maintainers > > Uploaders: Joost van Baal-Ilić > > into > > Maintainer: Debian R Packages Maintainers > > > in debian/control? I'm not really sure what might be the best way to go. Definitely it is not good to have somehow false information about Uploaders who do not intend to Upload the package in question. Technically its the easiest way to spot those packages who need an Uploader if there is nobody mentioned. We get a linitan warning (error?) about it and UDD will return the results quickly. It might possibly make sense as well to decide about droping some packages with no rdepends and low popcon to reduce the workload. For R packages there are several ways for users to install (either in plain R or cran2deb). If we realise interest in some package was lost and it just keeps us busy for no visible advantage for users, cleaning up our package pool might make sense. Kind regards Andreas. -- http://fam-tille.de
Re: Action needed for R-pkg Uploaders
Hi, Andreas: thanks a lot for this heads-up, and thanks HUGELY for maintaining the bulk of the r-cran ecosystem in Debian for such a long time. Op Mon, Mar 11, 2024 at 03:47:42PM +0100 schreef Andreas Tille: > > > Joost van Baal-Ilić : > r-cran-bdgraph > r-cran-corpcor > r-cran-d3network > r-cran-farver > r-cran-fdrtool > r-cran-formatr > r-cran-ggforce > r-cran-ggm > r-cran-ggrepel > r-cran-glasso > r-cran-highr > r-cran-httpuv > r-cran-huge > r-cran-hunspell > r-cran-knitr > r-cran-lavaan > r-cran-lisreltor > r-cran-markdown > r-cran-matrixcalc > r-cran-mi > r-cran-mime > r-cran-nfactors > r-cran-qgraph > r-cran-rcppparallel > r-cran-rockchalk > r-cran-sem > r-cran-semplot > r-cran-semtools > r-cran-statcheck > r-cran-tweenr > r-cran-yaml I'm afraid I won't have time to take care of those in the near future. However, I _do_ plan to keep maintaining: r-cran-lavaan r-cran-hunspell r-cran-markdown r-cran-httpuv r-cran-statcheck (And I've just managed to do upload new upstream of r-cran-statcheck; routine-update indeed makes life much easier :) So, would it be usefull to do an upload of the 31 - 5 = 26 other packages dropping my name from Uploaders: so changing: Maintainer: Debian R Packages Maintainers Uploaders: Joost van Baal-Ilić into Maintainer: Debian R Packages Maintainers in debian/control? Thanks, Bye, Joost
libbio-procedural-perl is marked for autoremoval from testing
libbio-procedural-perl 1.7.4-2 is marked for autoremoval from testing on 2024-04-22 It (build-)depends on packages with these RC bugs: 1065759: libbio-samtools-perl: FTBFS: lib/Bio/DB/Sam.xs:324:4: error: implicit declaration of function âbam_sort_coreâ; did you mean âbam_format1_coreâ? [-Werror=implicit-function-declaration] https://bugs.debian.org/1065759 This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
libbio-db-swissprot-perl is marked for autoremoval from testing
libbio-db-swissprot-perl 1.7.4-1 is marked for autoremoval from testing on 2024-04-22 It (build-)depends on packages with these RC bugs: 1065759: libbio-samtools-perl: FTBFS: lib/Bio/DB/Sam.xs:324:4: error: implicit declaration of function âbam_sort_coreâ; did you mean âbam_format1_coreâ? [-Werror=implicit-function-declaration] https://bugs.debian.org/1065759 This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
libbio-db-refseq-perl is marked for autoremoval from testing
libbio-db-refseq-perl 1.7.4-1 is marked for autoremoval from testing on 2024-04-22 It (build-)depends on packages with these RC bugs: 1065759: libbio-samtools-perl: FTBFS: lib/Bio/DB/Sam.xs:324:4: error: implicit declaration of function âbam_sort_coreâ; did you mean âbam_format1_coreâ? [-Werror=implicit-function-declaration] https://bugs.debian.org/1065759 This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
Re: Fwd: heudiconv FTBFS on i386
Hi Alexandre, Do we know any details on how much memory we have on that i386 box? meanwhile I made a record against nibabel https://github.com/nipy/nibabel/issues/1307 on this. Here -- we could potentially just skip (announce xfail) that particular test (test_reproin_largely_smoke) on i386? could even do upstream if would be of any help (to not mess around with patches etc) On Fri, 15 Mar 2024, Alexandre Detiste wrote: > Whoops I sent to the wrong list. > -- Forwarded message - > Date: mer. 13 mars 2024 à 11:07 > To: Debian Med Packaging Team > Hi, > I'm refreshing heudiconv. > It fails to build on i386. > https://salsa.debian.org/med-team/heudiconv/-/pipelines/651879 > The lazy solution is to drop more & more 32 bit support. > ... but maybe this package can still be fixed. > I'll have a look again later. > Greetings -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Fwd: heudiconv FTBFS on i386
Whoops I sent to the wrong list. -- Forwarded message - Date: mer. 13 mars 2024 à 11:07 To: Debian Med Packaging Team Hi, I'm refreshing heudiconv. It fails to build on i386. https://salsa.debian.org/med-team/heudiconv/-/pipelines/651879 The lazy solution is to drop more & more 32 bit support. ... but maybe this package can still be fixed. I'll have a look again later. Greetings
Re: How is autopkgtest working in Perl packages
Hi Andreas, Andreas Tille, on 2024-03-12: > Cool. It would be great if we could get rid of 32bit emboss related > packages to get back all those packages in testing which were removed > now. In the particular case of bioperl-run, there are only single Architecture: all "binary" packages, so nothing to remove from archives per se. I uploaded a revision that relaxes dependencies and recommendations so builds and tests should pass on every architectures, at the cost of not testing as many things as usual outside amd64, and sacrificing some checks for the autodep8 perl recommends test. Have a good evening, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `- signature.asc Description: PGP signature
Re: Bug#1065841: Taking over datalad to either Debian Med or Debian Science team
Hi Yaroslav, Am Tue, Mar 12, 2024 at 03:50:22PM -0400 schrieb Yaroslav Halchenko: > Let's keep DataLad under our (NeuroDebian) umbrella for now, since we > are also upstream there and project is active. We are also > working with Vasyl (CCed) to experiment with some semi-automation for > package updates/backports (for neurodebian) and datalad (and some of its > ecosystem) packages are the target. Packaging will be on salsa. We > might move them under larger Med or Science teams, but not just yet. That's perfectly fine and all I would like to see. No presure. > Re #1065841 specifically -- while trying to build updated package I > experienced some odd side-effect (pip started to try to install > tqdm) and didn't see immediate reason.I will see how well it goes on > debian infra after source only upload (did now). I perfectly trust you to maintain this package properly. I simply was querying this type of bug and thought datalad would nicely fit into Debian Science scope. Kind regards Andreas. -- http://fam-tille.de
Re: Bug#1065841: Taking over datalad to either Debian Med or Debian Science team
Hi Andreas, Let's keep DataLad under our (NeuroDebian) umbrella for now, since we are also upstream there and project is active. We are also working with Vasyl (CCed) to experiment with some semi-automation for package updates/backports (for neurodebian) and datalad (and some of its ecosystem) packages are the target. Packaging will be on salsa. We might move them under larger Med or Science teams, but not just yet. Re #1065841 specifically -- while trying to build updated package I experienced some odd side-effect (pip started to try to install tqdm) and didn't see immediate reason.I will see how well it goes on debian infra after source only upload (did now). Cheers, -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: How is autopkgtest working in Perl packages
Am Mon, Mar 11, 2024 at 10:29:30PM +0100 schrieb Étienne Mollier: > The change turns out to be much more involved than I initially > thought: we need to account for the build dependencies as well > as the recommends, and tests don't go skipped that easily, > because the control on skippable entries occurs after the > testbed is installed, which cannot occur since recommended > packages are uninstallable. I'll probably continue having a > look at bioperl-run during the week. Cool. It would be great if we could get rid of 32bit emboss related packages to get back all those packages in testing which were removed now. Kind regards Andreas. -- http://fam-tille.de
Re: How is autopkgtest working in Perl packages
Étienne Mollier, on 2024-03-11: > I think it may be skipped for now by > creating a debian/tests/pkg-perl/SKIP file containing: > > runtime-deps-and-recommends The change turns out to be much more involved than I initially thought: we need to account for the build dependencies as well as the recommends, and tests don't go skipped that easily, because the control on skippable entries occurs after the testbed is installed, which cannot occur since recommended packages are uninstallable. I'll probably continue having a look at bioperl-run during the week. Good night, -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Cynthesis - Incision signature.asc Description: PGP signature
Taking over datalad to either Debian Med or Debian Science team
Hi Yaroslav, once we agreed that we should probably move all Neurodebian packages to Debian Med to make it accessible for a bigger team. I was not really active for some time in this attempt. However, bug #1065841 brought datalad on my screen. I would love to see it maintained on Salsa either in Debian Science team (since it has wider usage) or Debiam Med (since we moved Neurodebian packages there). I'd volunteer to do the move if you agree to and by doing so also fix the two open bugs and run some `routine-update` on the packaging. What do you think? Kind regards AndreasI'd volunteer to do the move if you agree to and by doing so also fix the two open bugs and run some `routine-update` on the packaging. What do you think? Kind regards Andreas. -- http://fam-tille.de
Re: How is autopkgtest working in Perl packages
Hi Andreas, Andreas Tille, on 2024-03-11: > when trying to exclude clustalw and emboss from bioperl-run I learned > that its autopkgtest is failing for all architectures but amd64. The > reason is that the test wants to install pftools which is only available > on amd646. Thus all autopkgtests for other architectures are failing > with > >Broken autopkgtest-satdep:ppc64el Depends on pftools:ppc64el < none @un mH > > > > (and other not installable dependencies.) Unfortunately I do not see > any debian/tests/control file which is hidden by some Perl test magic > I do not know. Any hint how to relax the depencency from non-existent > packages? The operation of autodep8-pkg-perl is described on the Debian Perl Team pages[1] (the other DPT). Give that the suite that is failing is the one which attempts to install recommended packages no matter what, I think it may be skipped for now by creating a debian/tests/pkg-perl/SKIP file containing: runtime-deps-and-recommends I can do that for you if you are busy on other fronts. [1]: https://perl-team.pages.debian.net/autopkgtest.html Have a nice evening, :) -- .''`. Étienne Mollier : :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da `. `' sent from /dev/pts/1, please excuse my verbosity `-on air: Acid Rain - Solitude signature.asc Description: PGP signature
How is autopkgtest working in Perl packages
Hi, when trying to exclude clustalw and emboss from bioperl-run I learned that its autopkgtest is failing for all architectures but amd64. The reason is that the test wants to install pftools which is only available on amd646. Thus all autopkgtests for other architectures are failing with Broken autopkgtest-satdep:ppc64el Depends on pftools:ppc64el < none @un mH > (and other not installable dependencies.) Unfortunately I do not see any debian/tests/control file which is hidden by some Perl test magic I do not know. Any hint how to relax the depencency from non-existent packages? Kind regards Andreas. -- http://fam-tille.de
Action needed for R-pkg Uploaders
Hi R-pkg team members, as you might have possibly read I nominated myself for DPL for the next term[1]. I will pronounce in my platform clearly that I will stop my uploading activity to rather concentrate on my DPL tasks. I hope I will be able to really stop myself from uploading in case I might be elected. I will also express that I'm a bit afraid about the effect on the teams where I'm very active in. This is specifically true for the R-pkg team. I did lots of team uploads in this team as you might have observed for those packages where you are listed as Uploader (see below). I simply worked down the list of packages needing an update[2] if I have some spare minutes - no matter whether I'm Uploader or not. The `routine-update` script was of great help here since it basically does what it says. The fact that the list[2] became a bit longish is simply a sign that I was focussing on other things the last weeks - drafting my DPL platform etc. I might upload some packages from list if other things like cleaning up after time_t transition in some packages might occupy all my time. However, you need to expect that this list will grow even longer if nobody will stand up and fulfill the task I more or less silently did the last couple of years. I've put all those contributors in CC who had a hit in the UDD query SELECT DISTINCT uploaders FROM sources WHERE maintainer_email = 'r-pkg-t...@alioth-lists.debian.net' AND release = 'sid'; which means the package is maintained by R-pkg team and the package is in sid (so no old Uploaders). Below you see a list of the actual package which is listing you as Uploader. Please note that some people are mentioned with different e-mail addresses. BTW, this list also contains Nilesh Patra who declared to leave the team[3]. We need to replace him as Uploader (and he is not mentioned in To-Field). What I would like you to do is: 1. Verify the list of packages whether you want to keep on working on this/these package(s) (and if you have different e-mail addresses please stick to only one) 2. If you do not want to serve as Uploader any more please try to find a different Uploader (in the best case) and let this contributor replace your ID or simply remove your ID to not nurish the false hope that someone will care for this package actively 3. Make sure you are uploading your packages regularly for new upstream versions and check for potential bugs (listed at the end of[2]) 4. I'd be happy if you would do me the favour to upload those packages that are listing me as Uploader as long as I might serve as DPL (I do not plan to do so more than one year) Thanks a lot for your cooperation inside R-pkg team Andreas. [1] https://lists.debian.org/debian-vote/2024/03/msg2.html [2] https://salsa.debian.org/r-pkg-team/maintenance-utilities/-/blob/master/outdated_r-packages.txt [3] https://lists.debian.org/debian-r/2023/11/msg00054.html Packages maintained by Uploaders in R-pkg team. Alba Crespi : r-cran-data.table r-cran-fastmatch r-cran-metamix r-cran-nmf r-cran-nnls r-cran-phangorn r-cran-pkgmaker r-cran-registry r-cran-rngtools Andrius Merkys : r-cran-cyclocomp r-cran-lintr r-cran-rlinsolve r-cran-xmlparsedata Benjamin Eikel : r-cran-ggplot2 r-cran-munsell r-cran-scales Carlos Borroto : r-cran-plyr Charles Plessy : r-bioc-genomeinfodb r-bioc-genomeinfodbdata r-bioc-genomicalignments r-bioc-hdf5array r-bioc-iranges r-bioc-matrixgenerics r-bioc-rtracklayer r-bioc-s4arrays r-bioc-s4vectors r-bioc-summarizedexperiment r-bioc-xvector r-bioc-zlibbioc r-cran-biocmanager r-cran-epitools r-cran-genetics Chris Lawrence : r-cran-aer r-cran-amelia r-cran-bayesm r-cran-coda r-cran-eco r-cran-gam r-cran-geepack r-cran-gmaps r-cran-jsonlite r-cran-mapdata r-cran-mapproj r-cran-maps r-cran-matchit r-cran-mcmc r-cran-mcmcpack r-cran-mnp r-cran-pscl r-cran-psy r-cran-rjags r-cran-vgam r-cran-zelig Christopher Hoskin : r-bioc-rbgl Dirk Eddelbuettel : r-cran-rocr Doug Torrance : r-cran-m2r r-cran-orthopolynom r-cran-partitions r-cran-r.devices r-cran-r.rsp r-cran-sets Doug Torrance : r-cran-latte r-cran-mpoly Dylan Aïssi : r-cran-fitbitscraper r-cran-fitcoach r-cran-leaps r-cran-prettyr Dylan Aïssi : dh-r r-bioc-bioccheck r-bioc-biocviews r-bioc-impute r-bioc-mergeomics r-bioc-rhdf5filters r-bioc-tcgabiolinksgui.data r-bioc-zlibbioc r-cran-ape r-cran-beeswarm r-cran-bigmemory r-cran-bigmemory.sri r-cran-biocmanager r-cran-calibrate r-cran-clipr r-cran-clisymbols r-cran-devtools r-cran-factominer r-cran-flashclust r-cran-gee r-cran-ggsci r-cran-gh r-cran-ini r-cran-isoband r-cran-isospecr r-cran-locfit r-cran-lubridate r-cran-metamix r-cran-modeldata r-cran-qqman r-cran-ranger r-cran-rcmdcheck r-cran-rematch2 r-cran-remotes r-cran-reprex r-cran-reticulate r-cran-rstatix r-cran-rvest r-cran-selectr
clustalw lost in debian/dists/sid/main/binary-i386/Packages.{gx}z ?
Hi, I'm working on some time_t side effects on the emboss package and by doing so stumbled I upon the fact that i386 builds of packages with a Build-Dependency on clustalw are failing. You can see an example in Salsa CI for libbio-tools-run-alignment-clustalw-perl[1] which contains The following packages have unmet dependencies: builddeps:. : Depends: clustalw but it is not installable E: Unable to correct problems, you have held broken packages. When checking the package pool[2] I can find clustalw_2.1+lgpl-7_i386.deb which is easily installable in some chroot I created using sudo debootstrap --arch=i386 sid i386-chroot http://deb.debian.org/debian Debci seems to be fine in testing clustalw on all architectures[3] and according to build logs[4] all should be fine. Unfortunately wget -q -O - http://ftp.debian.org/debian/dists/sid/main/binary-i386/Packages.xz | xzgrep "Package: *clustalw" Packages.xz is empty and I wonder why. Is the Packages file for i386 just broken or is it me? Kind regards Andreas. [1] https://salsa.debian.org/perl-team/modules/packages/libbio-tools-run-alignment-clustalw-perl/-/jobs/5431253 [2] http://ftp.debian.org/debian/pool/main/c/clustalw/ [3] https://ci.debian.net/packages/c/clustalw/unstable/i386/ [4] https://buildd.debian.org/status/package.php?p=clustalw -- http://fam-tille.de
Build-Dependencies from emboss-lib for bioperl-run and python-biopython (Was: reverse dependencie)
Control: block -1 by 1065782 Hi Thorsten, Am Mon, Mar 04, 2024 at 06:41:28PM + schrieb Thorsten Alteholz: > there are still reverse dependencies that need to be taken care of: > > Checking reverse dependencies... > # Broken Depends: > emboss: jemboss I think this is a false positive since jemboss is built from the emboss source. > emboss-explorer: emboss-explorer Bug filed. > # Broken Build-Depends: > bioperl-run: emboss This needs further investigation. > embassy-domainatrix: emboss-lib (6.6.1~ <) Fixed Build-Depends. > embassy-domalign: emboss-lib (6.6.1~ <) Fixed Build-Depends. > embassy-domsearch: emboss-lib (6.6.0-1~ >=) >emboss-lib (6.6.1~ <) Fixed Build-Depends. > python-biopython: emboss This needs further investigation. > In case they matter, this needs to be addressed first. Please remove the > moreinfo tag once that is done. Thanks for checking. Once bioperl-run and python-biopython is fixed we reset moreinfo. Kind regards Andreas. -- http://fam-tille.de
Re: regarding filtering architectures
Hi Michael, Am Thu, Mar 07, 2024 at 12:23:15PM +0100 schrieb Michael R. Crusoe: > This is a great tip, thanks! > > I've pushed commits that use the provisions from the > architecture-properties package to clean up d/control for the following > packages: > > abyss > bazel-bootstrap > bowtie > bowtie2 > canu > diamond-aligner > gmap > jellyfish > kallisto > mmseqs2 > pbcopper > python-skbio > subread Very nice! That way we will not forget this in the next upgrade. I guess there are more candidates - my strategy would be to seek for loong in the list of architectures. Thanks for this effort Andreas. -- http://fam-tille.de
Re: regarding filtering architectures
This is a great tip, thanks! I've pushed commits that use the provisions from the architecture-properties package to clean up d/control for the following packages: abyss bazel-bootstrap bowtie bowtie2 canu diamond-aligner gmap jellyfish kallisto mmseqs2 pbcopper python-skbio subread On Sun, Mar 3, 2024 at 9:49 PM Andreas Tille wrote: > Hi, > > Paul has sent me a valuable hint. I totally missed this information > but will try to fix all our packages that are only available for 64 bit > architectures according to this. I'm just bouncing this information > to the list in case I'm not the only one who missed this simple option > to exclude 32bit. > > Kind regards > Andreas. > > Am Sun, Mar 03, 2024 at 07:28:57AM +0100 schrieb Paul Gevers: > > Hi Andreas, > > > > I just spotted two of you packages [1] where you stopped supporting 32 > bits. > > I'm not going to judge on that (I don't even look at the reason), but > > instead of hard-coding the list of architectures, could you use a > > Build-Dependens on architecture-is-64-bit (from > > https://packages.debian.org/unstable/architecture-properties). > > > > Rationale: https://lists.debian.org/debian-devel/2022/09/msg00105.html > > > > Paul > > > > [1] > https://tracker.debian.org/media/packages/e/emboss/control-6.6.0dfsg-13 > > [2] > https://tracker.debian.org/media/packages/r/r-bioc-rhtslib/control-2.4.1dfsg-2 > > > > Paul > > > > > -- > http://fam-tille.de > >
