Bug#940595: transition: hypre
On 2019-11-09 05:45, Paul Gevers wrote: Hi Drew, On 03-11-2019 21:01, Paul Gevers wrote: On 30-10-2019 08:26, Drew Parsons wrote: So yes, the unversioned libhypre package name is certainly the option that will preserve the greatest sanity (I'll proceed directly with 2.18.2 once you give the thumbs up). Thumbs up. All migrated. Closing this bug. Thanks Paul. Since we've got this ABI-free upstream with hypre, to save overworking you with future patch updates for little patch version updates (Z in X.Y.Z), I'm thinking to treat them as minor, so proceeding without a formal transition. I can request a binNMU for petsc/sundials/slepc. Alternatively, more often than not there's a petsc upgrade waiting at the same time as a hypre upgrade (for example petsc 3.12 is waiting in experimental at the moment). Maybe next time we can consider running a joint hypre/petsc/slepc transition. To save the busywork of hypre patch version transitions. Drew
Bug#940595: transition: hypre
Control: tags -1 confirmed Hi Drew, On 30-10-2019 08:26, Drew Parsons wrote: > So yes, the unversioned libhypre package name is certainly the option > that will preserve the greatest sanity (I'll proceed directly with > 2.18.2 once you give the thumbs up). Thumbs up. Paul signature.asc Description: OpenPGP digital signature
Bug#940595: transition: hypre
On 2019-10-30 15:21, Drew Parsons wrote: hypre 2.18.1 is now ready in experimental. I've implemented the common libhypre option with shlibs patch-version dependency. If this approach proves problematic in practice then we can switch back to version-based library package names afterwards if we need to. I've confirmed petsc and sundials build successfully. Let's do this transition. p.s. for bonus lols, I just checked and yes, 2.18.2 has just been released... So yes, the unversioned libhypre package name is certainly the option that will preserve the greatest sanity (I'll proceed directly with 2.18.2 once you give the thumbs up). (they're releasing unusually rapidly lately. Previously there have been less than 2 releases each year).
Bug#940595: transition: hypre
On 2019-10-18 15:56, Emilio Pozuelo Monfort wrote: On 17/10/2019 17:05, Drew Parsons wrote: Hi Emilio, this is rather awkward. Hypre upstream has just released 2.18.1, so this would be the one to run the transition on. ... "The hypre team currently does nothing to ensure application binary interface (ABI) compatibility. As a result, all releases (major, minor, or patch) should be treated as incompatible." It means we have to run a new library package for each patch release, and therefore have to jump back into the NEW queue with libhypre-2.18.1. It's either that, or provide only a generic libhypre package and apply rigidly strict shlib files depending strictly on a given version. ... Right, the strict dependency via shlibs and provides would make testing migrations harder as everything would need to transition at the same time (hypre and all rdeps). However there are three rdeps and you control two of them, so it doesn't look like a terrible situation. hypre 2.18.1 is now ready in experimental. I've implemented the common libhypre option with shlibs patch-version dependency. If this approach proves problematic in practice then we can switch back to version-based library package names afterwards if we need to. I've confirmed petsc and sundials build successfully. Let's do this transition. Drew
Bug#940595: transition: hypre
On 2019-10-18 15:56, Emilio Pozuelo Monfort wrote: On 17/10/2019 17:05, Drew Parsons wrote: Control: tags -1 - confirmed On 2019-10-17 15:23, Emilio Pozuelo Monfort wrote: Control: tags -1 confirmed On 17/10/2019 05:53, Drew Parsons wrote: On 2019-10-12 22:19, Emilio Pozuelo Monfort wrote: On 12/10/2019 16:08, Drew Parsons wrote: Thanks Emilio. 2.18.0 is now released, and waiting now in the new queue. Perhaps we should hold on a bit and jump straight to 2.18.0. That will save having to process 2 transitions. What do you think? Sure, that makes sense. Let us know once things are ready for 2.18. hypre 2.18 is accepted now and built in experimental already. petsc seems to perform fine with the new version and sundials builds successfully. Let's proceed with the transition. Ack. Hi Emilio, this is rather awkward. Hypre upstream has just released 2.18.1, so this would be the one to run the transition on. The particular awkwardness is that upstream does not believe in shared libraries, and therefore does not maintain ABI compatibility even in patch releases. I asked explicitly about it, https://github.com/hypre-space/hypre/issues/56, and so they've added a comment to their documentation: "The hypre team currently does nothing to ensure application binary interface (ABI) compatibility. As a result, all releases (major, minor, or patch) should be treated as incompatible." It means we have to run a new library package for each patch release, and therefore have to jump back into the NEW queue with libhypre-2.18.1. It's either that, or provide only a generic libhypre package and apply rigidly strict shlib files depending strictly on a given version. I'd be interested to hear which option you think is best. A strict shlibs dependency with a generic ABI-free package name would save having to traverse the NEW queue each time but would be a little brutal on testing migrations and general archive robustness. Right, the strict dependency via shlibs and provides would make testing migrations harder as everything would need to transition at the same time (hypre and all rdeps). However there are three rdeps and you control two of them, so it doesn't look like a terrible situation. OTOH bumping the package name (if that's what upstream does with the SONAME) is probably preferable despite the NEW roundtrip. Another option would be for you to review the changes in point releases and assess whether there is an ABI break or not, and avoid bumping the shlibs / provides in that case. In fact you could mix the two, shipping e.g. libhypre-2.18 with Provides: hypre-abi-2.18.0, and strict dependencies on that for rdeps. Then if you update to 2.18.1 and there's no ABI break, you don't change that. But that may be overcomplicating things for a package with so few rdeps. Thanks for the options, Emilio. Tracking ABI changes manually sounds like a recipe for disaster, especially if upstream is promising to be capricious with ABI changes. Given the small number of rdeps, the strict shlibs might prove less painful than putting up with the NEW queue wait. Normally the new versions don't happen so often, upstream has just been a bit busier than usual the last month or two. I'll have a think on it a little then choose one option or the other. Would need to jump into NEW queue anyway to get the libhypre shlibs option started. Drew
Bug#940595: transition: hypre
On 17/10/2019 17:05, Drew Parsons wrote: > Control: tags -1 - confirmed > > On 2019-10-17 15:23, Emilio Pozuelo Monfort wrote: >> Control: tags -1 confirmed >> >> On 17/10/2019 05:53, Drew Parsons wrote: >>> On 2019-10-12 22:19, Emilio Pozuelo Monfort wrote: On 12/10/2019 16:08, Drew Parsons wrote: > > Thanks Emilio. 2.18.0 is now released, and waiting now in the new queue. > Perhaps we should hold on a bit and jump straight to 2.18.0. That will > save > having to process 2 transitions. What do you think? Sure, that makes sense. Let us know once things are ready for 2.18. >>> >>> hypre 2.18 is accepted now and built in experimental already. petsc seems >>> to >>> perform fine with the new version and sundials builds successfully. Let's >>> proceed with the transition. >> >> Ack. > > > Hi Emilio, this is rather awkward. Hypre upstream has just released 2.18.1, > so > this would be the one to run the transition on. > > The particular awkwardness is that upstream does not believe in shared > libraries, and therefore does not maintain ABI compatibility even in patch > releases. > I asked explicitly about it, https://github.com/hypre-space/hypre/issues/56, > and > so they've added a comment to their documentation: > > "The hypre team currently does nothing to ensure application binary interface > (ABI) compatibility. As a result, all releases (major, minor, or patch) should > be treated as incompatible." > > It means we have to run a new library package for each patch release, and > therefore have to jump back into the NEW queue with libhypre-2.18.1. It's > either that, or provide only a generic libhypre package and apply rigidly > strict > shlib files depending strictly on a given version. > > I'd be interested to hear which option you think is best. A strict shlibs > dependency with a generic ABI-free package name would save having to traverse > the NEW queue each time but would be a little brutal on testing migrations and > general archive robustness. Right, the strict dependency via shlibs and provides would make testing migrations harder as everything would need to transition at the same time (hypre and all rdeps). However there are three rdeps and you control two of them, so it doesn't look like a terrible situation. OTOH bumping the package name (if that's what upstream does with the SONAME) is probably preferable despite the NEW roundtrip. Another option would be for you to review the changes in point releases and assess whether there is an ABI break or not, and avoid bumping the shlibs / provides in that case. In fact you could mix the two, shipping e.g. libhypre-2.18 with Provides: hypre-abi-2.18.0, and strict dependencies on that for rdeps. Then if you update to 2.18.1 and there's no ABI break, you don't change that. But that may be overcomplicating things for a package with so few rdeps. Cheers, Emilio
Bug#940595: transition: hypre
Control: tags -1 - confirmed On 2019-10-17 15:23, Emilio Pozuelo Monfort wrote: Control: tags -1 confirmed On 17/10/2019 05:53, Drew Parsons wrote: On 2019-10-12 22:19, Emilio Pozuelo Monfort wrote: On 12/10/2019 16:08, Drew Parsons wrote: Thanks Emilio. 2.18.0 is now released, and waiting now in the new queue. Perhaps we should hold on a bit and jump straight to 2.18.0. That will save having to process 2 transitions. What do you think? Sure, that makes sense. Let us know once things are ready for 2.18. hypre 2.18 is accepted now and built in experimental already. petsc seems to perform fine with the new version and sundials builds successfully. Let's proceed with the transition. Ack. Hi Emilio, this is rather awkward. Hypre upstream has just released 2.18.1, so this would be the one to run the transition on. The particular awkwardness is that upstream does not believe in shared libraries, and therefore does not maintain ABI compatibility even in patch releases. I asked explicitly about it, https://github.com/hypre-space/hypre/issues/56, and so they've added a comment to their documentation: "The hypre team currently does nothing to ensure application binary interface (ABI) compatibility. As a result, all releases (major, minor, or patch) should be treated as incompatible." It means we have to run a new library package for each patch release, and therefore have to jump back into the NEW queue with libhypre-2.18.1. It's either that, or provide only a generic libhypre package and apply rigidly strict shlib files depending strictly on a given version. I'd be interested to hear which option you think is best. A strict shlibs dependency with a generic ABI-free package name would save having to traverse the NEW queue each time but would be a little brutal on testing migrations and general archive robustness. I've preemptively de-confirmed the transition. Drew
Bug#940595: transition: hypre
Control: tags -1 confirmed On 17/10/2019 05:53, Drew Parsons wrote: > On 2019-10-12 22:19, Emilio Pozuelo Monfort wrote: >> On 12/10/2019 16:08, Drew Parsons wrote: >>> >>> Thanks Emilio. 2.18.0 is now released, and waiting now in the new queue. >>> Perhaps we should hold on a bit and jump straight to 2.18.0. That will save >>> having to process 2 transitions. What do you think? >> >> Sure, that makes sense. Let us know once things are ready for 2.18. > > hypre 2.18 is accepted now and built in experimental already. petsc seems to > perform fine with the new version and sundials builds successfully. Let's > proceed with the transition. Ack. Emilio
Bug#940595: transition: hypre
On 2019-10-12 22:19, Emilio Pozuelo Monfort wrote: On 12/10/2019 16:08, Drew Parsons wrote: Thanks Emilio. 2.18.0 is now released, and waiting now in the new queue. Perhaps we should hold on a bit and jump straight to 2.18.0. That will save having to process 2 transitions. What do you think? Sure, that makes sense. Let us know once things are ready for 2.18. hypre 2.18 is accepted now and built in experimental already. petsc seems to perform fine with the new version and sundials builds successfully. Let's proceed with the transition. Drew
Bug#940595: transition: hypre
On 2019-10-12 22:19, Emilio Pozuelo Monfort wrote: Control: tags -1 - confirmed Hi Drew, On 12/10/2019 16:08, Drew Parsons wrote: On 2019-10-12 21:59, Emilio Pozuelo Monfort wrote: I'd like to proceed with the hypre transition to 2.17.0. I've tested that petsc and sundials build successfully with the new hypre. Please go ahead. Thanks Emilio. 2.18.0 is now released, and waiting now in the new queue. Perhaps we should hold on a bit and jump straight to 2.18.0. That will save having to process 2 transitions. What do you think? Sure, that makes sense. Let us know once things are ready for 2.18. Thanks again. I'll send the note once it's stabilised in experimental. Drew
Bug#940595: transition: hypre
Control: tags -1 - confirmed Hi Drew, On 12/10/2019 16:08, Drew Parsons wrote: > On 2019-10-12 21:59, Emilio Pozuelo Monfort wrote: >>> >>> I'd like to proceed with the hypre transition to 2.17.0. >>> >>> I've tested that petsc and sundials build successfully with the new >>> hypre. >> >> Please go ahead. > > Thanks Emilio. 2.18.0 is now released, and waiting now in the new queue. > Perhaps we should hold on a bit and jump straight to 2.18.0. That will save > having to process 2 transitions. What do you think? Sure, that makes sense. Let us know once things are ready for 2.18. Cheers, Emilio
Bug#940595: transition: hypre
On 2019-10-12 21:59, Emilio Pozuelo Monfort wrote: I'd like to proceed with the hypre transition to 2.17.0. I've tested that petsc and sundials build successfully with the new hypre. Please go ahead. Thanks Emilio. 2.18.0 is now released, and waiting now in the new queue. Perhaps we should hold on a bit and jump straight to 2.18.0. That will save having to process 2 transitions. What do you think? Drew
Bug#940595: transition: hypre
Control: tags -1 confirmed On 17/09/2019 17:35, Drew Parsons wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > I'd like to proceed with the hypre transition to 2.17.0. > > I've tested that petsc and sundials build successfully with the new > hypre. Please go ahead. Emilio
Bug#940595: transition: hypre
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition I'd like to proceed with the hypre transition to 2.17.0. I've tested that petsc and sundials build successfully with the new hypre. Ben file: title = "hypre"; is_affected = .depends ~ "libhypre-2.16.0" | .depends ~ "libhypre-2.17.0"; is_good = .depends ~ "libhypre-2.17.0"; is_bad = .depends ~ "libhypre-2.16.0"; -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
