Bug#1071614: transition: libmatio13
Le vendredi 31 mai 2024 à 12:43 +0200, Emilio Pozuelo Monfort a écrit : > On 31/05/2024 12:19, Sébastien Villemot wrote: > > Le vendredi 31 mai 2024 à 09:31 +0200, Emilio Pozuelo Monfort a écrit : > > > On 24/05/2024 19:34, Emilio Pozuelo Monfort wrote: > > > > On 22/05/2024 14:49, Sébastien Villemot wrote: > > > > > Package: release.debian.org > > > > > Severity: normal > > > > > X-Debbugs-Cc: libma...@packages.debian.org > > > > > Control: affects -1 + src:libmatio > > > > > User: release.debian@packages.debian.org > > > > > Usertags: transition > > > > > Control: forwarded -1 > > > > > https://release.debian.org/transitions/html/auto-libmatio.html > > > > > > > > > > Dear Release Team, > > > > > > > > > > Please schedule a transition for libmatio. > > > > > > > > > > I’ve successfully rebuilt all reverse dependencies against the new > > > > > version > > > > > (currently in experimental), except gnss-sdr and labplot which are > > > > > currently > > > > > unbuildable due to the qt5 transition. > > > > > > > > Let's wait for the Qt 5 transition then. > > > > > > The Qt 5 transition is over now, so assuming those two packages build > > > against > > > libmatio13, then go ahead with this. > > > > It turns out that labplot FTBFS against the new libmatio. I opened a > > bug and submitted a patch that fixes the issue. > > > > Should I upload libmatio to unstable now and then NMU labplot, or > > should I give some time to the labplot maintainer to react? > > Either way is fine. You can start the transition now as I believe libmatio > can > be smooth-updated, so we don't really have to block on labplot. Of course > fixing > it later if the maintainer doesn't would be good in order to complete the > transition. Thanks. I just uploaded the new libmatio to unstable. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1071614: transition: libmatio13
Le vendredi 31 mai 2024 à 09:31 +0200, Emilio Pozuelo Monfort a écrit : > On 24/05/2024 19:34, Emilio Pozuelo Monfort wrote: > > On 22/05/2024 14:49, Sébastien Villemot wrote: > > > Package: release.debian.org > > > Severity: normal > > > X-Debbugs-Cc: libma...@packages.debian.org > > > Control: affects -1 + src:libmatio > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > Control: forwarded -1 > > > https://release.debian.org/transitions/html/auto-libmatio.html > > > > > > Dear Release Team, > > > > > > Please schedule a transition for libmatio. > > > > > > I’ve successfully rebuilt all reverse dependencies against the new version > > > (currently in experimental), except gnss-sdr and labplot which are > > > currently > > > unbuildable due to the qt5 transition. > > > > Let's wait for the Qt 5 transition then. > > The Qt 5 transition is over now, so assuming those two packages build against > libmatio13, then go ahead with this. It turns out that labplot FTBFS against the new libmatio. I opened a bug and submitted a patch that fixes the issue. Should I upload libmatio to unstable now and then NMU labplot, or should I give some time to the labplot maintainer to react? Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1071614: transition: libmatio13
Package: release.debian.org Severity: normal X-Debbugs-Cc: libma...@packages.debian.org Control: affects -1 + src:libmatio User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-libmatio.html Dear Release Team, Please schedule a transition for libmatio. I’ve successfully rebuilt all reverse dependencies against the new version (currently in experimental), except gnss-sdr and labplot which are currently unbuildable due to the qt5 transition. Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1067842: transition: octave-9
Hi Graham, Le lundi 20 mai 2024 à 11:25 +, Graham Inggs a écrit : > octave-fits FTBFS on all architectures (#1070956), > and octave-stk FTBFS on 32-bit architectures (#1069477), > would you please take a look? octave-fits has been autoremoved from testing because we requested its removal from unstable (see #1070956). octave-stk has been autoremoved from testing hence it is no longer a blocker. Additionally, there were 3 other packages which were posing a problem: octave-ga, octave-queueing and octave-statistics. Those are arch:all packages whose autopkgtests in testing were broken by the new octave (but they have no dependency on octave-abi-*, since they are arch:all). We made source uploads for the three of them, so they should be good. I have a question: should we add a Breaks in octave against the old versions of these 3 packages, in order to force the simultaneous migration of all affected packages? I thought this was necessary, but the excuses for octave no longer mention octave-ga and octave-queueing (octave-statistics is still there because it has just been fixed). Note that the updated packages have a Depends: octave (>= 9.1.0). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1067842: transition: octave-9
Hi Graham, Le vendredi 10 mai 2024 à 09:57 +, Graham Inggs a écrit : > On Thu, 9 May 2024 at 08:09, Sebastian Ramacher wrote: > > plplot is involved in the gnat and octave transitions. So let's do this > > one after gnat is done. > > gnat 13 has migrated, please go ahead. Thanks. Uploaded and built on all release architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1067842: transition: octave-9
Package: release.debian.org Severity: normal X-Debbugs-Cc: debian-oct...@lists.debian.org User: release.debian@packages.debian.org Usertags: transition Dear Release Team, Please schedule a transition for the latest major upstream version of Octave, version 9. All the arch:any Octave addons need to be rebuild. Octave 9 has already been uploaded to experimental. A rebuild of all the packages affected by the transition has been performed. Several problems were fixed, and to the best of our knowledge, all packages are ready. We stand ready to upload and NMU as needed if other issues arise. Thanks, Ben file: title = "octave-9"; is_affected = .depends ~ "octave-abi-58" | .depends ~ "octave-abi-59"; is_good = .depends ~ "octave-abi-59"; is_bad = .depends ~ "octave-abi-58"; -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1055600: transition: suitesparse-7.3
Le vendredi 17 novembre 2023 à 07:43 +0100, Sebastian Ramacher a écrit : > On 2023-11-08 18:00:20 +0100, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-suitesparse.html > > Please schedule a transition for suitesparse 7.3, which currently sits in > > experimental. > > > > One the shared libraries got a SOVERSION bump (libcholmod4 → libcholmod5). > > The > > ABI change is minor and I’m therefore fairly confident that there won’t be > > any > > issue. > > Please go ahead. The transition is mostly complete. The only remaining issue is an autopkgtest failure of octave in testing, reported as #1056392. I’ve argued there that this issue only affects partial upgrades, and that I’m not sure how to fix it (if fixing is needed at all). Please advise. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1055600: transition: suitesparse-7.3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-suitesparse.html Dear Release Team, Please schedule a transition for suitesparse 7.3, which currently sits in experimental. One the shared libraries got a SOVERSION bump (libcholmod4 → libcholmod5). The ABI change is minor and I’m therefore fairly confident that there won’t be any issue. Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1053007: transition: suitesparse-7.2
Le mercredi 27 septembre 2023 à 19:09 +0200, Sebastian Ramacher a écrit : > On 2023-09-26 22:59:30 +0200, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: suitespa...@packages.debian.org > > Control: affects -1 + src:suitesparse > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-suitesparse.html > > > > Dear Release Team, > > > > Please schedule a transition for suitesparse 7.2. The new version is > > already in > > experimental. > > Please go ahead. Thanks, uploaded and built on all release architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1053007: transition: suitesparse-7.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: suitespa...@packages.debian.org Control: affects -1 + src:suitesparse Control: forwarded -1 https://release.debian.org/transitions/html/auto-suitesparse.html Dear Release Team, Please schedule a transition for suitesparse 7.2. The new version is already in experimental. One of the binary packages produced by src:suitesparse got a SOVERSION bump (libspqr3 → libspqr4). Three reverse dependencies are affected. I rebuilt them without trouble against the new version. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1039470: bullseye-pu: package openblas/0.3.13+ds-3+deb11u1
Le dimanche 30 juillet 2023 à 15:00 +0100, Jonathan Wiltshire a écrit : > On Mon, Jun 26, 2023 at 12:58:07PM +0200, Sébastien Villemot wrote: > > The problem that I am trying to fix is the following: the AVX512 kernel > > (nicknamed > > “SkylakeX”) is miscompiled in openblas 0.3.13+ds-3, so that openblas gives > > incorrect numerical results in the DGEMM function (basic matrix > > multiplication) > > on AVX512-capable hardware. > > Please go ahead. Thanks, uploaded. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1038943: bullseye-pu: package lapack/3.9.0-3+deb11u1
Le mardi 25 juillet 2023 à 21:37 +0100, Jonathan Wiltshire a écrit : > On Fri, Jun 23, 2023 at 03:11:18PM +0200, Sébastien Villemot wrote: > > [ Reason ] > > This oldstable update fixes important bug #1037188. > > > > The bug is in LAPACKE (the C interface to LAPACK, which is in Fortran). > > > > For symmetric eigenvalue problems, the returned eigenvector matrix > > is incorrect (when row-major layout of matrices is used). > > > > This is a regression from buster. The bug has been fixed in bookworm and > > sid. > > Please go ahead. Thanks, uploaded. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041227: transition: suitesparse
Le dimanche 16 juillet 2023 à 18:50 +0200, Sebastian Ramacher a écrit : > On 2023-07-15 23:25:28 +0200, Sébastien Villemot wrote: > > Please schedule a transition for suitesparse 7, which currently sits in > > experimental. > > Please go ahead. Thanks for driving this transition so far. I have noticed the build failures of octave on 32-bit architectures (that you reported in #1041460). Actually, it turns out that suitesparse 7 is partly broken on 32-bit architectures. Contrarily to what I said previously, there is an ABI change on 32-bit architectures. And due to the way that this ABI change was performed, it had the unintended consequence of breaking libspqr3 (provided by src:suitesparse) on 32-bit architectures. Upstream realized this too late (and did not make much publicity around it, so I was not aware of the issue before starting the transition). Upstream seems to be working on a fix, but at this point there is none available. The only affected package seems to be octave, for which there is a workaround (disabling libspqr use on 32-bit archs, which implies that some functionalities won’t be available there). I hope this situation is only temporary. There are two other reverse dependencies of libspqr (petsc and apbs) but so far they don’t seem to be affected (they probably are to some extent, but at least no FTBFS or autopkgtest failure in sight). Ideally I should have waited longer before starting this transition but it’s now too late (unless you think that the transition should be rolled back, though that seems a bit extreme given the limited extent of the breakage; in particular, 32-bit archs are probably not used that much for number crunching these days). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041227: transition: suitesparse
Le dimanche 16 juillet 2023 à 18:50 +0200, Sebastian Ramacher a écrit : > On 2023-07-15 23:25:28 +0200, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: suitespa...@packages.debian.org > > Control: affects -1 + src:suitesparse > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-suitesparse.html > > Control: block -1 by 1041059 1037905 1037622 1040694 1041225 1037858 > > > > Dear Release Team, > > > > Please schedule a transition for suitesparse 7, which currently sits in > > experimental. > > Please go ahead. Thanks, it’s now uploaded and built on all release architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1041227: transition: suitesparse
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: suitespa...@packages.debian.org Control: affects -1 + src:suitesparse Control: forwarded -1 https://release.debian.org/transitions/html/auto-suitesparse.html Control: block -1 by 1041059 1037905 1037622 1040694 1041225 1037858 Dear Release Team, Please schedule a transition for suitesparse 7, which currently sits in experimental. In this new major release, the SOVERSION of all libraries has been bumped, because some integer types part of the API have been redefined; however, this redefinition does not change anything on our release architectures. There are also a couple of other changes in headers that impact three reverse dependencies: libdogleg, siconos and octave. A fix is available for the three of them, and I stand ready to upload as needed. Four other reverse dependencies (yade, dolfin, openturns, sight) currently FTBFS for unrelated reasons. As a consequence, I could not verify that they build correctly against suitesparse 7 (but if they don’t, I’m fairly confident that they can be adapted). Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1040001: To strict version restrictions injected by dh-r (Was: Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing)
Le jeudi 06 juillet 2023 à 22:09 +0200, Andreas Tille a écrit : > Am Thu, Jul 06, 2023 at 09:13:46PM +0200 schrieb Sébastien Villemot: > > > I'm not sure so please explain in more detail. dh-r was designed to put > > > the lowest restriction regarding the versions. I remember some > > > discussion some time ago that Dirk thought we should put stronger > > > restrictions (and he is sometimes adding version restrictions manually > > > that are not helpful for backporting). If I will be sure I understand > > > your point exactly I can check the code and the relevant discussion. > > > (Feel free to file a bug report about this and we can discuss it there > > > if you think this makes more sense.) > > > > It comes from this line: > > https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L272 > > > > More precisely the “r-base-core (>= $rbase_version)” part, which > > imposes an unnecessarily tight restriction on the r-base-core version. > > Got it, thanks for the explanation. […] > I'd consider it sensible if you open a bug against dh-r where we can > document the change you are suggesting. Done in #1040515. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1040001: Seeking advise how to proceed with the transition / move R stack to testing (Was: Bug#1040001: transition: r-base)
Le jeudi 06 juillet 2023 à 21:02 +0200, Andreas Tille a écrit : > Am Thu, Jul 06, 2023 at 07:08:04PM +0200 schrieb Paul Gevers: > > PS: in a private discussion I had today, we noticed that r-* packages often > > (always?) have a dependency on r-base-core with a lower limited version > > equal to the r-base-core that was used during the build. With the > > appropriate API in Provides of r-base-core, this should no longer be > > necessary and ease migrations in the future. > > Could you please give some example to make sure I understand correctly? > > > We should probably file a bug > > against dh-r (I guess) to fix that dependency. Or did we conclude that > > wrong? > > I'm not sure so please explain in more detail. dh-r was designed to put > the lowest restriction regarding the versions. I remember some > discussion some time ago that Dirk thought we should put stronger > restrictions (and he is sometimes adding version restrictions manually > that are not helpful for backporting). If I will be sure I understand > your point exactly I can check the code and the relevant discussion. > (Feel free to file a bug report about this and we can discuss it there > if you think this makes more sense.) It comes from this line: https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/dh/R.pm#L272 More precisely the “r-base-core (>= $rbase_version)” part, which imposes an unnecessarily tight restriction on the r-base-core version. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1038933: transition: octave
Le samedi 01 juillet 2023 à 10:15 +0200, Sebastian Ramacher a écrit : > On 2023-06-23 10:32:52 +0200, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: oct...@packages.debian.org, debian-oct...@lists.debian.org > > Control: affects -1 + src:octave > > > > Dear Release Team, > > > > Please schedule a transition for the latest major upstream version of > > Octave, > > version 8. All the arch:any Octave addons need to be rebuild. > > Please go ahead. Thanks for your help! It looks like the transition is complete. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1039470: bullseye-pu: package openblas/0.3.13+ds-3+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: openb...@packages.debian.org Control: affects -1 + src:openblas Dear Release Team, [ Reason ] This oldstable update fixes important bug #1025480. As a reminder, OpenBLAS is a BLAS (basic linear algebra) implementation that provides kernels optimized for different generations of CPUs (ISAs). All the kernels are embedded in the library binary, and the kernel selection is done at runtime depending on the CPU model (this is called “dynamic arch” in the OpenBLAS jargon). The problem that I am trying to fix is the following: the AVX512 kernel (nicknamed “SkylakeX”) is miscompiled in openblas 0.3.13+ds-3, so that openblas gives incorrect numerical results in the DGEMM function (basic matrix multiplication) on AVX512-capable hardware. The cause of the problem is the following: the build-time check for determining whether the compiler is able to understand AVX512 assembly/intrinsics was doubly incorrect. It would test the build machine capabilities (instead of the compiler capabilities); and it would check for AVX2 instead of AVX512. As a consequence, on pre-AVX2 hardware, the build system would conclude that the compiler is not able to understand AVX512 primitives, and would create a broken AVX512 (SkylakeX) DGEMM kernel (essentially a Haswell kernel, but with some wrong assumptions, hence leading to incorrect numerical results). Versions 0.3.13+ds-3 and 0.3.13+ds-2, which are affected by the bug, were built on the x86-csail-01 build daemon in 2021, which I suppose was pre-Ivybridge. Binary packages built for e.g. on x86-conova-01 or x86-ubc-01 are not affected by the bug, so I suppose these machines has at least AVX2. But I do not have access to the build machine specifications to verify these conclusions. [ Impact ] Incorrect results in DGEMM (basic matrix multiplication) on AVX512-capable hardware (hence a pretty serious bug for numerical software). [ Tests ] I manually verified that, on an Ivybridge machine, the package built without the patch is buggy (i.e. gives incorrect results on AVX512-capable hardware), and the package built with the patch works fine. The internal testsuite of OpenBLAS still passes with the patch. [ Risks ] Risk is limited, since the patch should only affect AVX512 kernels (which are already broken anyways). [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] A quilt patch added, containing an upstream pull request. The patch removes the dependency of the binary package produced on the build machine specifications (i.e. it will build correct AVX512 kernel, irrespectively of the build machine). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org diff -Nru openblas-0.3.13+ds/debian/changelog openblas-0.3.13+ds/debian/changelog --- openblas-0.3.13+ds/debian/changelog 2021-04-18 10:36:29.0 +0200 +++ openblas-0.3.13+ds/debian/changelog 2023-06-25 21:56:08.0 +0200 @@ -1,3 +1,11 @@ +openblas (0.3.13+ds-3+deb11u1) bullseye; urgency=medium + + * avx512-dgemm.patch: new patch taken from upstream. Fixes incorrect numerical +results of DGEMM on AVX512-capable hardware, when the package has been built +on pre-AVX2 hardware (e.g. Intel Ivybridge). (Closes: #1025480) + + -- Sébastien Villemot Sun, 25 Jun 2023 21:56:08 +0200 + openblas (0.3.13+ds-3) unstable; urgency=medium * fix-arm64-sigill.patch: new patch, fixes SIGILL on arm64 with numpy. diff -Nru openblas-0.3.13+ds/debian/patches/avx512-dgemm.patch openblas-0.3.13+ds/debian/patches/avx512-dgemm.patch --- openblas-0.3.13+ds/debian/patches/avx512-dgemm.patch1970-01-01 01:00:00.0 +0100 +++ openblas-0.3.13+ds/debian/patches/avx512-dgemm.patch2023-06-25 21:56:08.0 +0200 @@ -0,0 +1,80 @@ +Description: Fix incorrect results of AVX512 DGEMM kernel when built on pre-AVX2 machine + When building OpenBLAS with dynamic arch selection on x86-64 hardware + that does not support AVX2 (e.g. Intel Ivybridge or earlier), then + the AVX512 (SkylakeX) kernel for DGEMM would produce incorrect + results (of course when run on AVX512-capable hardware). + . + The problem was that the check for determining whether the compiler + is able to understand AVX512 assembly/intrinsics was doubly + incorrect: it would test the build machine capabilities (instead of + the compiler capabilities); and it would check for AVX2 instead of + AVX512. As a consequence, on pre-AVX2 hardware, the build system + would conclude that the compiler is not able to understand AVX512 + primitives, and would create a broken AVX512 (SkylakeX) DGEMM kernel + (essentially a Haswell kernel, but with some wrong assumptions, hence
Bug#1038943: bullseye-pu: package lapack/3.9.0-3+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: lap...@packages.debian.org
Control: affects -1 + src:lapack
Dear Release Team,
[ Reason ]
This oldstable update fixes important bug #1037188.
The bug is in LAPACKE (the C interface to LAPACK, which is in Fortran).
For symmetric eigenvalue problems, the returned eigenvector matrix
is incorrect (when row-major layout of matrices is used).
This is a regression from buster. The bug has been fixed in bookworm and sid.
[ Impact ]
Incorrect numerical result (one of the worst kind of bug for numerical
software)
[ Tests ]
I verified that the proposed upload fixes the bug.
It introduces no regression in the internal LAPACK testsuite.
[ Risks ]
The patch affects a couple of leaf functions, so the risk
is limited.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
A quilt patch added, containing an upstream commit.
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
diff -Nru lapack-3.9.0/debian/changelog lapack-3.9.0/debian/changelog
--- lapack-3.9.0/debian/changelog 2020-08-01 16:15:54.0 +0200
+++ lapack-3.9.0/debian/changelog 2023-06-23 14:53:50.0 +0200
@@ -1,3 +1,11 @@
+lapack (3.9.0-3+deb11u1) bullseye; urgency=medium
+
+ * lapacke-syev-heev.patch: new patch, fixes eigenvector matrix in
+LAPACKE’s interface to symmetric eigenvalue problem (syev and heev
+functions) (Closes: #1037242)
+
+ -- Sébastien Villemot Fri, 23 Jun 2023 14:53:50 +0200
+
lapack (3.9.0-3) unstable; urgency=medium
[ Sébastien Villemot ]
diff -Nru lapack-3.9.0/debian/patches/lapacke-syev-heev.patch
lapack-3.9.0/debian/patches/lapacke-syev-heev.patch
--- lapack-3.9.0/debian/patches/lapacke-syev-heev.patch 1970-01-01
01:00:00.0 +0100
+++ lapack-3.9.0/debian/patches/lapacke-syev-heev.patch 2023-06-23
14:53:50.0 +0200
@@ -0,0 +1,215 @@
+Description: Fix eigenvector matrix in LAPACKE’s interface to symmetric
eigenvalue problem
+ The syev and heev functions, when passed jobz=V and called in row major order
+ mode, would return an incorrect eigenvector matrix (incorrect lower- or
+ upper-triangle part).
+Origin: upstream,
https://github.com/Reference-LAPACK/lapack/commit/7d5bb9e5e641772227022689162dd9cc47e64de0
+Bug: https://github.com/Reference-LAPACK/lapack/issues/850
+Bug-Debian: https://bugs.debian.org/1037242
+Last-Update: 2023-06-23
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/LAPACKE/src/lapacke_cheev_work.c
b/LAPACKE/src/lapacke_cheev_work.c
+index f505dfab0..aa78e678e 100644
+--- a/LAPACKE/src/lapacke_cheev_work.c
b/LAPACKE/src/lapacke_cheev_work.c
+@@ -78,7 +78,11 @@ lapack_int LAPACKE_cheev_work( int matrix_layout, char
jobz, char uplo,
+ info = info - 1;
+ }
+ /* Transpose output matrices */
+-LAPACKE_che_trans( LAPACK_COL_MAJOR, uplo, n, a_t, lda_t, a, lda );
++if ( jobz == 'V') {
++LAPACKE_cge_trans( LAPACK_COL_MAJOR, n, n, a_t, lda_t, a, lda );
++} else {
++LAPACKE_che_trans( LAPACK_COL_MAJOR, uplo, n, a_t, lda_t, a, lda
);
++}
+ /* Release memory and exit */
+ LAPACKE_free( a_t );
+ exit_level_0:
+diff --git a/LAPACKE/src/lapacke_cheevd_2stage_work.c
b/LAPACKE/src/lapacke_cheevd_2stage_work.c
+index e9e6a5d1d..d26c84785 100644
+--- a/LAPACKE/src/lapacke_cheevd_2stage_work.c
b/LAPACKE/src/lapacke_cheevd_2stage_work.c
+@@ -79,7 +79,11 @@ lapack_int LAPACKE_cheevd_2stage_work( int matrix_layout,
char jobz, char uplo,
+ info = info - 1;
+ }
+ /* Transpose output matrices */
+-LAPACKE_che_trans( LAPACK_COL_MAJOR, uplo, n, a_t, lda_t, a, lda );
++if ( jobz == 'V') {
++LAPACKE_cge_trans( LAPACK_COL_MAJOR, n, n, a_t, lda_t, a, lda );
++} else {
++LAPACKE_che_trans( LAPACK_COL_MAJOR, uplo, n, a_t, lda_t, a, lda
);
++}
+ /* Release memory and exit */
+ LAPACKE_free( a_t );
+ exit_level_0:
+diff --git a/LAPACKE/src/lapacke_cheevd_work.c
b/LAPACKE/src/lapacke_cheevd_work.c
+index 4c5f352a8..e8f212efb 100644
+--- a/LAPACKE/src/lapacke_cheevd_work.c
b/LAPACKE/src/lapacke_cheevd_work.c
+@@ -79,8 +79,11 @@ lapack_int LAPACKE_cheevd_work( int matrix_layout, char
jobz, char uplo,
+ info = info - 1;
+ }
+ /* Transpose output matrices */
+-LAPACKE_che_trans( LAPACK_COL_MAJOR, uplo, n, a_t, lda_t, a, lda );
+-
++if ( jobz == 'V') {
++LAPACKE_cge_trans( LAPACK_COL_MAJOR, n, n, a_t, lda_t, a, lda );
++} else {
++LAPACKE_che_trans(
Bug#1038933: transition: octave
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: oct...@packages.debian.org, debian-oct...@lists.debian.org Control: affects -1 + src:octave Dear Release Team, Please schedule a transition for the latest major upstream version of Octave, version 8. All the arch:any Octave addons need to be rebuild. Octave 8 has already been uploaded to experimental. A rebuild of all the packages affected by the transition has been performed. Several problems were fixed, and to the best of our knowledge, only one package is not ready (octave-stk; since it is a leaf package, it will be possible to temporarily exclude it from testing if it is not fixed by the time of the transition). We stand ready to upload and NMU as needed if other issues arise. Ben file: title = "octave"; is_affected = .depends ~ "octave-abi-57" | .depends ~ "octave-abi-58"; is_good = .depends ~ "octave-abi-58"; is_bad = .depends ~ "octave-abi-57"; -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1035069: unblock: zmat/0.9.8+ds-8
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: z...@packages.debian.org, debian-oct...@lists.debian.org Control: affects -1 + src:zmat Please unblock package zmat. The version in unstable adds a missing Breaks+Replaces needed for upgrades from bullseye (see #1035012). unblock zmat/0.9.8+ds-8 -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1033043: unblock: octave/7.3.0-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: oct...@packages.debian.org Control: affects -1 + src:octave Please unblock package octave. Version 7.3.0-2 fixes an issue that may arise during upgrades from Bullseye to Bookworm, namely a missing Breaks+Replaces with files moved from one package to another (see #1033011). The debdiff is attached. unblock octave/7.3.0-2 Thanks for your work, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org diff -Nru octave-7.3.0/debian/changelog octave-7.3.0/debian/changelog --- octave-7.3.0/debian/changelog 2022-11-05 09:29:53.0 +0100 +++ octave-7.3.0/debian/changelog 2023-03-15 17:55:33.0 +0100 @@ -1,3 +1,10 @@ +octave (7.3.0-2) unstable; urgency=medium + + * d/control: add missing Breaks+Replaces of octave-dev on old liboctave-dev +(Closes: #1033011) + + -- Sébastien Villemot Wed, 15 Mar 2023 17:55:33 +0100 + octave (7.3.0-1) unstable; urgency=medium * New upstream version 7.3.0 diff -Nru octave-7.3.0/debian/control octave-7.3.0/debian/control --- octave-7.3.0/debian/control 2022-11-05 09:29:48.0 +0100 +++ octave-7.3.0/debian/control 2023-03-15 17:54:42.0 +0100 @@ -144,6 +144,8 @@ gcc, g++ Enhances: octave +Breaks: liboctave-dev (<< 6.3.0-1) +Replaces: liboctave-dev (<< 6.3.0-1) Description: development files for the GNU Octave language Octave is a (mostly MATLAB® compatible) high-level language, primarily intended for numerical computations. It provides a convenient command-line
Bug#1009865: transition: octave
Le samedi 23 avril 2022 à 12:40 +0200, Rafael Laboissière a écrit : > * Sébastien Villemot [2022-04-22 11:19]: > > > Le jeudi 21 avril 2022 à 09:57 +0200, Sébastien Villemot a écrit : > > > Le mercredi 20 avril 2022 à 12:06 +0200, Sebastian Ramacher a écrit : > > > > On 2022-04-19 15:57:14 +0200, Sébastien Villemot wrote: > > > > > Package: release.debian.org > > > > > Severity: normal > > > > > User: release.debian@packages.debian.org > > > > > Usertags: transition > > > > > X-Debbugs-Cc: debian-oct...@lists.debian.org > > > > > > > > > > Please schedule a transition for octave. The new major upstream > > > > > release > > > > > (7.1.0), currently in experimental, changes the ABI. > > > > > > > > Please go ahead > > > > > > Thanks. The new version of octave was uploaded to unstable and built on > > > all release architectures. > > > > The transition is mostly over. I suggest to remove octave-mpi and > > octave-level-set from testing, and call it a day! > > Thanks, Sébastien! > > Version 0.3.1~git.2019.04.13-4 of the octave-level-set package, just > uploaded to unstable, seems to build correctly against Octave 7.1. Great, thanks. Then you should probably close #1009180. I now realize that two packages (octave-parallel and bart) fail their autopkgtest against the new octave. I’ll have a look next week. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1009865: transition: octave
Le jeudi 21 avril 2022 à 09:57 +0200, Sébastien Villemot a écrit : > Le mercredi 20 avril 2022 à 12:06 +0200, Sebastian Ramacher a écrit : > > On 2022-04-19 15:57:14 +0200, Sébastien Villemot wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > X-Debbugs-Cc: debian-oct...@lists.debian.org > > > > > > Please schedule a transition for octave. The new major upstream release > > > (7.1.0), currently in experimental, changes the ABI. > > > > Please go ahead > > Thanks. The new version of octave was uploaded to unstable and built on > all release architectures. The transition is mostly over. I suggest to remove octave-mpi and octave-level-set from testing, and call it a day! Thanks for your help, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1009865: transition: octave
Le mercredi 20 avril 2022 à 12:06 +0200, Sebastian Ramacher a écrit : > On 2022-04-19 15:57:14 +0200, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: debian-oct...@lists.debian.org > > > > Please schedule a transition for octave. The new major upstream release > > (7.1.0), currently in experimental, changes the ABI. > > Please go ahead Thanks. The new version of octave was uploaded to unstable and built on all release architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1009865: transition: octave
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-oct...@lists.debian.org Dear Release Team, Please schedule a transition for octave. The new major upstream release (7.1.0), currently in experimental, changes the ABI. Reverse dependencies have been rebuilt against the new version, and bugs filed: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=octave7;users=debian-oct...@lists.debian.org Most of them are now fixed. Only three are left, one of which concerning a package not in testing (octave-tisean), and the other two concerning leaf packages for which there is no obvious fix, and that could temporarily be removed from testing. Ben file: title = "octave"; is_affected = .depends ~ "octave-abi-56" | .depends ~ "octave-abi-57"; is_good = .depends ~ "octave-abi-57"; is_bad = .depends ~ "octave-abi-56"; Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#1003599: transition: octave
Le samedi 22 janvier 2022 à 09:27 +0100, Sebastian Ramacher a écrit : > On 2022-01-21 22:45:31 +0100, Sebastian Ramacher wrote: > > On 2022-01-18 19:25:08 +0100, Sébastien Villemot wrote: > > > Le mardi 18 janvier 2022 à 19:18 +0100, Sebastian Ramacher a écrit : > > > > On 2022-01-18 09:11:01 +0100, Sébastien Villemot wrote: > > > > > Le lundi 17 janvier 2022 à 11:03 +0100, Sébastien Villemot a écrit : > > > > > > Le dimanche 16 janvier 2022 à 21:11 +0100, Sebastian Ramacher a > > > > > > écrit : > > > > > > > On 2022-01-12 13:46:03 +0100, Sébastien Villemot wrote: > > > > > > > > Package: release.debian.org > > > > > > > > Severity: normal > > > > > > > > User: release.debian@packages.debian.org > > > > > > > > Usertags: transition > > > > > > > > X-Debbugs-Cc: debian-oct...@lists.debian.org > > > > > > > > > > > > > > > > Please schedule a transition for octave 6.4, which is currently > > > > > > > > in > > > > > > > > experimental. All Octave add-ons need to be recompiled, because > > > > > > > > of a change in > > > > > > > > the interface exposed to them. > > > > > > > > > > > > > > > > > > > > > > Please go ahead > > > > > > > > > > > > Thanks. octave 6.4.0-2 has been uploaded to unstable, and compiled > > > > > > on > > > > > > all release architectures. > > > > > > > > > > The recompilation process is almost completed. The only remaining > > > > > problem is octave-tisean which fails to rebuild on s390x (see #874116, > > > > > which is a long-standing issue). > > > > > > > > > > octave-tisean is a leaf package, so I suggest to remove it from > > > > > testing, so that we can complete the transition. > > > > > > > > Removal hint added. > > > > > > > > Note that octave-database's autopkgtest on armhf regressed. See > > > > https://ci.debian.net/data/autopkgtest/testing/armhf/o/octave-database/18432401/log.gz > > > > for the log > > > > > > I’ve tried to reproduce the failure on abel.d.o, but the autopkgtest > > > succeeded. I have no clue about the problem. If this is an option for > > > you, then I would simply force the migration despite the bad test. > > > > Bug filed (#1004158) and hint added. > > … and it's done. Thanks a lot for your help! -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1003599: transition: octave
Le jeudi 20 janvier 2022 à 08:56 +0100, Rafael Laboissière a écrit : > * Rafael Laboissière [2022-01-20 08:34]: > > > > Thanks for taking care of this transition, which went pretty smoothly, > > fortunately. Package octave-tisean is not active upstream since > > several years and it does not look like Bug#874116 is going to be > > fixed any soon. > > I forgot to mention that I will soon release a new version of > dh-octave, in order to complete the transition (liboctve-dev → > octave-dev). Note that this is not necessary at this stage. There is a transitional dummy package for liboctave-dev. We should postpone the upload of dh- octave until after the completion of the transition, unless there is another issue that I’m not aware of. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1003599: transition: octave
Le mardi 18 janvier 2022 à 19:18 +0100, Sebastian Ramacher a écrit : > On 2022-01-18 09:11:01 +0100, Sébastien Villemot wrote: > > Le lundi 17 janvier 2022 à 11:03 +0100, Sébastien Villemot a écrit : > > > Le dimanche 16 janvier 2022 à 21:11 +0100, Sebastian Ramacher a écrit : > > > > On 2022-01-12 13:46:03 +0100, Sébastien Villemot wrote: > > > > > Package: release.debian.org > > > > > Severity: normal > > > > > User: release.debian@packages.debian.org > > > > > Usertags: transition > > > > > X-Debbugs-Cc: debian-oct...@lists.debian.org > > > > > > > > > > Please schedule a transition for octave 6.4, which is currently in > > > > > experimental. All Octave add-ons need to be recompiled, because of a > > > > > change in > > > > > the interface exposed to them. > > > > > > > > > > > > > Please go ahead > > > > > > Thanks. octave 6.4.0-2 has been uploaded to unstable, and compiled on > > > all release architectures. > > > > The recompilation process is almost completed. The only remaining > > problem is octave-tisean which fails to rebuild on s390x (see #874116, > > which is a long-standing issue). > > > > octave-tisean is a leaf package, so I suggest to remove it from > > testing, so that we can complete the transition. > > Removal hint added. > > Note that octave-database's autopkgtest on armhf regressed. See > https://ci.debian.net/data/autopkgtest/testing/armhf/o/octave-database/18432401/log.gz > for the log I’ve tried to reproduce the failure on abel.d.o, but the autopkgtest succeeded. I have no clue about the problem. If this is an option for you, then I would simply force the migration despite the bad test. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1003599: transition: octave
Le lundi 17 janvier 2022 à 11:03 +0100, Sébastien Villemot a écrit : > Le dimanche 16 janvier 2022 à 21:11 +0100, Sebastian Ramacher a écrit : > > On 2022-01-12 13:46:03 +0100, Sébastien Villemot wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: transition > > > X-Debbugs-Cc: debian-oct...@lists.debian.org > > > > > > Please schedule a transition for octave 6.4, which is currently in > > > experimental. All Octave add-ons need to be recompiled, because of a > > > change in > > > the interface exposed to them. > > > > > > > Please go ahead > > Thanks. octave 6.4.0-2 has been uploaded to unstable, and compiled on > all release architectures. The recompilation process is almost completed. The only remaining problem is octave-tisean which fails to rebuild on s390x (see #874116, which is a long-standing issue). octave-tisean is a leaf package, so I suggest to remove it from testing, so that we can complete the transition. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1003599: transition: octave
Le dimanche 16 janvier 2022 à 21:11 +0100, Sebastian Ramacher a écrit : > On 2022-01-12 13:46:03 +0100, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-Cc: debian-oct...@lists.debian.org > > > > Please schedule a transition for octave 6.4, which is currently in > > experimental. All Octave add-ons need to be recompiled, because of a change > > in > > the interface exposed to them. > > > > Please go ahead Thanks. octave 6.4.0-2 has been uploaded to unstable, and compiled on all release architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#1003599: transition: octave
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debian-oct...@lists.debian.org Dear Release Team, Please schedule a transition for octave 6.4, which is currently in experimental. All Octave add-ons need to be recompiled, because of a change in the interface exposed to them. Note that, due to an upstream change, Octave add-ons no longer explicitly link against Octave libraries (i.e. those libraries are no longer in the ELF DT_NEEDED section, which is not an issue since they are dynamic loadable modules). As a consequence, we have decided to drop the (shared library) liboctaveN package. The shared libraries are now installed in private locations, per policy, and following upstream practice. We now exclusively rely on pseudo-package octave-abi-NN for tracking ABI requirements. The transition should be straightforward. Our expectation is that only one package (nlopt) will need a sourceful upload, and we will take care of it. Here is the Ben file (note that it’s different from the autogenerated one): title = "octave6.4"; is_affected = .depends ~ /liboctave8|octave-abi-55|octave-abi-56/; is_good = .depends ~ /octave-abi-56/; is_bad = .depends ~ /liboctave8|octave-abi-55/; Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org
Bug#987132: unblock: openblas/0.3.13+ds-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear Release Team,
Please unblock package openblas.
The version currently in unstable fixes serious bug #986996.
This bug causes crashes (with SIGILL) on some arm64 processors, in particular
when running numpy.
The fix is a backport of an upstream commit (as documented in the DEP-3 headers
of the patch), and it consists only in adding a “volatile” qualifier, so the
risk of regression should be limited. The debdiff is attached.
Note that openblas is a key package.
unblock openblas/0.3.13+ds-3
Thanks,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
diff -Nru openblas-0.3.13+ds/debian/changelog
openblas-0.3.13+ds/debian/changelog
--- openblas-0.3.13+ds/debian/changelog 2021-01-27 06:56:54.0 +0100
+++ openblas-0.3.13+ds/debian/changelog 2021-04-18 10:36:29.0 +0200
@@ -1,3 +1,10 @@
+openblas (0.3.13+ds-3) unstable; urgency=medium
+
+ * fix-arm64-sigill.patch: new patch, fixes SIGILL on arm64 with numpy.
+Thanks to Thomas Viehmann (Closes: #986996)
+
+ -- Sébastien Villemot Sun, 18 Apr 2021 10:36:29 +0200
+
openblas (0.3.13+ds-2) unstable; urgency=medium
[ Gianfranco Costamagna ]
diff -Nru openblas-0.3.13+ds/debian/patches/fix-arm64-sigill.patch
openblas-0.3.13+ds/debian/patches/fix-arm64-sigill.patch
--- openblas-0.3.13+ds/debian/patches/fix-arm64-sigill.patch1970-01-01
01:00:00.0 +0100
+++ openblas-0.3.13+ds/debian/patches/fix-arm64-sigill.patch2021-04-18
10:34:32.0 +0200
@@ -0,0 +1,26 @@
+Description: Fix SIGILL on arm64 when HWCAP_CPUID is not set
+ This is a crashing bug (SIGILL) that also affects numpy on arm64. One
+ line of processors affected are NVIDIA Tegra (Jetson devices).
+ .
+ On ARM64, openblas uses feature registers to detect the detailed
+ processor arch. It queries HWCAP_CPUID to check if the feature registers
+ are used. But due to a missing volatile declaration, gcc seems to break
+ this guarding in optimization.
+Origin: upstream,
https://github.com/xianyi/OpenBLAS/commit/6fe0f1fab9d6a7f46d71d37ebb210fbf56924fbc
+Bug-Debian: https://bugs.debian.org/986996
+Last-Update: 2021-04-18
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+diff --git a/driver/others/dynamic_arm64.c b/driver/others/dynamic_arm64.c
+index 4f1b12f2..37c0694b 100644
+--- a/driver/others/dynamic_arm64.c
b/driver/others/dynamic_arm64.c
+@@ -68,7 +68,7 @@ extern void openblas_warning(int verbose, const char * msg);
+ #endif
+
+ #define get_cpu_ftr(id, var) ({ \
+- __asm__("mrs %0, "#id : "=r" (var));\
++ __asm__ __volatile__("mrs %0, "#id : "=r" (var));
\
+ })
+
+ static char *corename[] = {
diff -Nru openblas-0.3.13+ds/debian/patches/series
openblas-0.3.13+ds/debian/patches/series
--- openblas-0.3.13+ds/debian/patches/series2021-01-27 06:56:54.0
+0100
+++ openblas-0.3.13+ds/debian/patches/series2021-04-18 10:29:14.0
+0200
@@ -6,3 +6,4 @@
matgen-symbols-not-included.patch
gensymbols-fix-detect-netlib.patch
riscv64-supported.patch
+fix-arm64-sigill.patch
Bug#987102: unblock: libretro-gambatte/0.5.0+git20160522+dfsg1-2.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear Release Team,
Please unblock package libretro-gambatte.
The version currently in unstable fixes important bug #911329.
This bug makes libretro-gambatte (a Game Boy emulator) unusable with GNOME
Games. It remains usable with retroarch, hence the non-RC severity.
A first attempt at fixing this bug had been made in a previous upload, but it
was not complete. This explains why the debdiff (in attachment) is quite small.
Also note that libretro-gambatte is a non-key leaf package.
unblock libretro-gambatte/0.5.0+git20160522+dfsg1-2.1
Thanks,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
diff -Nru libretro-gambatte-0.5.0+git20160522+dfsg1/debian/changelog
libretro-gambatte-0.5.0+git20160522+dfsg1/debian/changelog
--- libretro-gambatte-0.5.0+git20160522+dfsg1/debian/changelog 2019-03-03
01:06:24.0 +0100
+++ libretro-gambatte-0.5.0+git20160522+dfsg1/debian/changelog 2021-04-17
17:25:18.0 +0200
@@ -1,3 +1,11 @@
+libretro-gambatte (0.5.0+git20160522+dfsg1-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Really install .libretro file & AppStream metadata for integration with
+GNOME Games (Really closes: #911329)
+
+ -- Sébastien Villemot Sat, 17 Apr 2021 17:25:18 +0200
+
libretro-gambatte (0.5.0+git20160522+dfsg1-2) unstable; urgency=medium
* Team upload
diff -Nru libretro-gambatte-0.5.0+git20160522+dfsg1/debian/gambatte.libretro
libretro-gambatte-0.5.0+git20160522+dfsg1/debian/gambatte.libretro
--- libretro-gambatte-0.5.0+git20160522+dfsg1/debian/gambatte.libretro
2019-03-03 01:06:24.0 +0100
+++ libretro-gambatte-0.5.0+git20160522+dfsg1/debian/gambatte.libretro
2021-04-17 17:25:18.0 +0200
@@ -1,3 +1,4 @@
+[Libretro]
Type=Emulator
Version=1.0
Name=Gambatte
diff -Nru libretro-gambatte-0.5.0+git20160522+dfsg1/debian/install
libretro-gambatte-0.5.0+git20160522+dfsg1/debian/install
--- libretro-gambatte-0.5.0+git20160522+dfsg1/debian/install2019-03-03
01:06:24.0 +0100
+++ libretro-gambatte-0.5.0+git20160522+dfsg1/debian/install2021-04-17
17:25:09.0 +0200
@@ -1,2 +1,4 @@
#!/usr/bin/dh-exec
libgambatte/*.so usr/lib/${DEB_HOST_MULTIARCH}/libretro
+debian/libretro-gambatte.metainfo.xml usr/share/metainfo
+debian/gambatte.libretro usr/lib/${DEB_HOST_MULTIARCH}/libretro
Bug#987028: unblock: workrave/1.10.44-7.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: franc...@debian.org
Dear Release Team,
Please unblock package workrave.
The version currently in unstable fixes important bug #986968.
This bug makes workrave mostly unusable on GNOME, which is our default desktop
environment. The package remains usable on other desktop environments, hence
the non-RC severity.
The fix is a backport of an upstream commit (as documented in the DEP-3 headers
of the patch), so the risk of regression should be limited. Also, this is a
non-key leaf package.
The debdiff is attached.
unblock workrave/1.10.44-7.1
Thanks,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name
⠈⠳⣄ https://www.debian.org
diff -Nru workrave-1.10.44/debian/changelog workrave-1.10.44/debian/changelog
--- workrave-1.10.44/debian/changelog 2021-01-19 09:09:17.0 +0100
+++ workrave-1.10.44/debian/changelog 2021-04-15 21:29:48.0 +0200
@@ -1,3 +1,11 @@
+workrave (1.10.44-7.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * fix-gnome-extension-crash.patch: new patch, fixes GNOME extension crash at
+Shell startup. (Closes: #986968)
+
+ -- Sébastien Villemot Thu, 15 Apr 2021 21:29:48 +0200
+
workrave (1.10.44-7) unstable; urgency=medium
* Bump copyright years in debian/copyright.
diff -Nru workrave-1.10.44/debian/patches/fix-gnome-extension-crash.patch
workrave-1.10.44/debian/patches/fix-gnome-extension-crash.patch
--- workrave-1.10.44/debian/patches/fix-gnome-extension-crash.patch
1970-01-01 01:00:00.0 +0100
+++ workrave-1.10.44/debian/patches/fix-gnome-extension-crash.patch
2021-04-15 21:28:31.0 +0200
@@ -0,0 +1,183 @@
+Description: Fix crash in GNOME Shell extension
+ On GNOME Shell startup, the extension crashes and disables all other
+ extensions.
+Origin: backport,
https://github.com/rcaelers/workrave/commit/56af818cd3e148069134551aacc7b06043d8541a
+Bug: https://github.com/rcaelers/workrave/issues/281
+Bug-Debian: https://bugs.debian.org/986968
+Last-Update: 2021-04-14
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/frontend/applets/common/src/timebar.c
b/frontend/applets/common/src/timebar.c
+@@ -25,7 +25,7 @@
+ static void workrave_timebar_class_init(WorkraveTimebarClass *klass);
+ static void workrave_timebar_init(WorkraveTimebar *self);
+
+-static void workrave_timebar_init_ui(WorkraveTimebar *self);
++static void workrave_timebar_init_ui(WorkraveTimebar *self, cairo_t *c);
+ static void workrave_timebar_draw_filled_box(WorkraveTimebar *self, cairo_t
*cr, int x, int y, int width, int height);
+ static void workrave_timebar_draw_frame(WorkraveTimebar *self, cairo_t *cr,
int width, int height);
+ static void workrave_timebar_compute_bar_dimensions(WorkraveTimebar *self,
int *bar_width, int *sbar_width, int *bar_height);
+@@ -48,8 +48,6 @@ enum
+
+ struct _WorkraveTimebarPrivate
+ {
+- gchar *name;
+-
+ //! Color of the time-bar.
+ WorkraveColorId bar_color;
+
+@@ -77,9 +75,6 @@ struct _WorkraveTimebarPrivate
+ int width;
+ int height;
+
+-#ifndef USE_GTK2
+- GtkStyleContext *style_context;
+-#endif
+ PangoContext *pango_context;
+ PangoLayout *pango_layout;
+ };
+@@ -127,8 +122,10 @@ workrave_timebar_init(WorkraveTimebar *s
+ priv->secondary_bar_value = 100;
+ priv->secondary_bar_max_value = 600;
+ priv->bar_text = g_strdup("");
+-
+- workrave_timebar_init_ui(self);
++ priv->width = 0;
++ priv->height = 0;
++ priv->pango_context = NULL;
++ priv->pango_layout = NULL;
+ }
+
+
+@@ -249,80 +246,54 @@ workrave_timebar_draw_text(WorkraveTimeb
+ }
+
+
+-#ifndef USE_GTK2
+-static void
+-workrave_timebar_init_ui(WorkraveTimebar *self)
+-{
+- WorkraveTimebarPrivate *priv = workrave_timebar_get_instance_private(self);
+-
+- priv->style_context = gtk_style_context_new();
+-
+- GtkWidgetPath *path = gtk_widget_path_new();
+- gtk_widget_path_append_type(path, GTK_TYPE_BUTTON);
+- gtk_style_context_set_path(priv->style_context, path);
+- gtk_style_context_add_class(priv->style_context, GTK_STYLE_CLASS_TROUGH);
+-
+- GdkScreen *screen = gdk_screen_get_default();
+- priv->pango_context = gdk_pango_context_get_for_screen(screen);
+-
+- PangoFontDescription *font_desc = NULL;
+- gtk_style_context_get (priv->style_context, GTK_STATE_FLAG_ACTIVE, "font",
&font_desc, NULL);
+-
+- pango_context_set_language(priv->pango_context, gtk_get_default_language());
+- pango_context_set_font_description(priv->pango_context, font_desc);
+-
+- priv->pango_layout = pango_layout_new(priv->pango_context);
+- pango_layout_set_text(priv->pango_layout, "-9:59:59", -1);
+-
+- pango_layout_get_pixel_size(priv->pango_layout, &priv->width,
&priv->height);
+-
+- priv->width = MAX(priv->width + 2 * MARG
Bug#986105: unblock: zmat/0.9.8+ds-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team. Please unblock package zmat. The version currently in unstable fixes RC bug #985515. The debdiff is attached. unblock zmat/0.9.8+ds-3 Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org diff -Nru zmat-0.9.8+ds/debian/changelog zmat-0.9.8+ds/debian/changelog --- zmat-0.9.8+ds/debian/changelog 2020-11-13 19:32:24.0 +0100 +++ zmat-0.9.8+ds/debian/changelog 2021-03-29 17:58:31.0 +0200 @@ -1,3 +1,10 @@ +zmat (0.9.8+ds-3) unstable; urgency=medium + + * Team upload + * Fix libzmat.so symlink (Closes: #985515) + + -- Sébastien Villemot Mon, 29 Mar 2021 17:58:31 +0200 + zmat (0.9.8+ds-2) unstable; urgency=medium * Team upload diff -Nru zmat-0.9.8+ds/debian/rules zmat-0.9.8+ds/debian/rules --- zmat-0.9.8+ds/debian/rules 2020-11-13 19:32:24.0 +0100 +++ zmat-0.9.8+ds/debian/rules 2021-03-29 17:56:24.0 +0200 @@ -35,7 +35,7 @@ install -d debian/libzmat1-dev/usr/lib/$$arch; \ mv lib/libzmat.so debian/libzmat1/usr/lib/$$arch/libzmat.so.1; \ mv lib/libzmat.a debian/libzmat1/usr/lib/$$arch/libzmat.a; \ - ln -sf debian/libzmat1/usr/lib/$$arch/libzmat.so.1 debian/libzmat1-dev/usr/lib/$$arch/libzmat.so + ln -sf libzmat.so.1 debian/libzmat1-dev/usr/lib/$$arch/libzmat.so chmod -x zipmat.mex dh_install -poctave-zmat zipmat.mex $(OCTDIR)/zmat
Bug#984788: (pre-approval) unblock: octave/6.2.0-1
Hi Paul ! Le lundi 08 mars 2021 à 22:17 +0100, Paul Gevers a écrit : > On 08-03-2021 13:19, Sébastien Villemot wrote: > > This is a pre-approval request for unblocking package octave, version > > 6.2.0-1 > > > > Currently, bullseye contains a hand-crafted mercurial snapshot of octave. > > Uploading a snapshot was made necessary because the previous official > > release > > (6.1.0) had serious bugs, which were fixed in the mercurial repository. > > > > Since then, a new official upstream bugfix release has been made (6.2.0). > > For > > various reasons, it would be better to ship an official release in bullseye, > > hence this request. > > > > The debdiff is attached. I have filtered out all unrelevant stuff (copyright > > header changes, regenerated files). > > What you showed looks OK. Under the assumption that the upload happens > in the next week or so, go ahead. Thanks, I have made the upload. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#976386: transition: octave
Le lundi 21 décembre 2020 à 10:35 +0100, Sebastian Ramacher a écrit : > On 2020-12-20 19:30:13, Sébastien Villemot wrote: > > Le dimanche 20 décembre 2020 à 19:24 +0100, Paul Gevers a écrit : > > > On 20-12-2020 19:15, Sébastien Villemot wrote: > > > > I’m not familiar with britney’s output, but my impression is that the > > > > problem is related to src:plplot. The version in testing currently > > > > builds a binary package named octave-plplot, which has been dropped in > > > > the version currently in unstable (because it was not possible to build > > > > it against octave 6). > > > > > > > > Maybe britney needs to be given some hint to force the transition. > > > > > > plplot is part of the gnat-10 transition, which means the transitions > > > now got entangled. I'm not following close enough to know what that > > > means now. > > > > My understanding is that the gnat-10 transition is not a blocking > > factor, since gnat-10 is already in testing (as part of src:gcc-10). > > But maybe I got it wrong. > > The blocking issues is indeed plplot. The version in unstable dropped > the octave package, but the version in testing still has it. So it's > part of the octave transition. libplplotada3-dev in unstable depends on > gnat and gnat-10, so is unsable to migrate because gnat in testing still > depends on gnat-9 but gnat-9 and gnat-10 are conflicting with each > other. > > To unblock the situation, I currently see the following options: > * Upload plplot 5.15.0+dfsg-16 together with the change to drop > octave-plplot to testing-pu [1]. Then plplot would no longer be > involved > in the octave transition and octave would be able to migrate. > * Remove plplot and reverse dependencies from testing. > [1] > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#t-p-u Thanks for your analysis. I’m putting Rafael Laboissière (plplot maintainer and member of the Debian Octave Group) in CC, so that he can decide what is the best course of action. My impression is that an upload to testing-proposed-updates would be the least disrupting solution. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#976386: transition: octave
Hi Paul, Le dimanche 20 décembre 2020 à 19:24 +0100, Paul Gevers a écrit : > On 20-12-2020 19:15, Sébastien Villemot wrote: > > I’m not familiar with britney’s output, but my impression is that the > > problem is related to src:plplot. The version in testing currently > > builds a binary package named octave-plplot, which has been dropped in > > the version currently in unstable (because it was not possible to build > > it against octave 6). > > > > Maybe britney needs to be given some hint to force the transition. > > plplot is part of the gnat-10 transition, which means the transitions > now got entangled. I'm not following close enough to know what that > means now. My understanding is that the gnat-10 transition is not a blocking factor, since gnat-10 is already in testing (as part of src:gcc-10). But maybe I got it wrong. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#976386: transition: octave
Le mercredi 09 décembre 2020 à 17:06 +0100, Sébastien Villemot a écrit : > Le mardi 08 décembre 2020 à 11:31 +0100, Sebastian Ramacher a écrit : > > On 2020-12-04 13:32:04 +0100, Sébastien Villemot wrote: > > > Please schedule a transition for octave 6, which currently sits in > > > experimental. > > Please go ahead. > > Thanks. The new version of octave has been uploaded to unstable and is > now built and installed on all release archs. It’s been several days since the transition has (apparently) been ready to migrate to testing, still it did not. I’m not familiar with britney’s output, but my impression is that the problem is related to src:plplot. The version in testing currently builds a binary package named octave-plplot, which has been dropped in the version currently in unstable (because it was not possible to build it against octave 6). Maybe britney needs to be given some hint to force the transition. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#976386: transition: octave
Le mardi 08 décembre 2020 à 11:31 +0100, Sebastian Ramacher a écrit : > On 2020-12-04 13:32:04 +0100, Sébastien Villemot wrote: > > Please schedule a transition for octave 6, which currently sits in > > experimental. > Please go ahead. Thanks. The new version of octave has been uploaded to unstable and is now built and installed on all release archs. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#976386: transition: octave
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 976200 976199 976198 976201 976202 976203 976204 976205 976206 976207 976210 976212 976381 976382 976385 Dear Release Team, Please schedule a transition for octave 6, which currently sits in experimental. A rebuild of all affected packages has been done. Several problems have been identified, most of them already fixed in experimental. A few ones remain, but we (the Debian Octave Group) are confident that we can deal with them swiftly (if needed by NMU for those that we don’t maintain). We therefore think that this transition could take place before the bullseye transition freeze. Ben file: title = "octave"; is_affected = .depends ~ /liboctave7|octave-abi-53/ | .depends ~ /liboctave8|octave-abi-55/; is_good = .depends ~ /liboctave8|octave-abi-55/; is_bad = .depends ~ /liboctave7|octave-abi-53/; Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Bug#971903: transition: libmatio
Le mercredi 18 novembre 2020 à 20:43 +0100, Sebastian Ramacher a écrit : > On 2020-10-18 12:34:48 +0200, Sebastian Ramacher wrote: > > On 2020-10-09 14:32:21 +0200, Sébastien Villemot wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: > > > release.debian@packages.debian.org > > > > > > Usertags: transition > > > Control: block -1 by 971902 > > > Control: forwarded -1 > > > https://release.debian.org/transitions/html/auto-libmatio.html > > > > > > > > > Dear Release Team, > > > > > > Please schedule a transition for libmatio (SOVERSION bump from 9 > > > to 11). > > > > > > One reverse dependency, scilab, currently fails to build against > > > the new > > > version, a bug has been filed (see above). > > > > scilab is also involved in the ongoing ocaml transition. So let's > > wait > > until ocaml 4.11.1 migrated. > > Sorry for the long delay. Please go ahead. Thanks, I’ve done the upload. Note that there is no need to trigger a rebuild of scilab, since it will fail. I have submitted a patch fixing this problem, and I will do a team upload if needed. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ https://sebastien.villemot.name ⠈⠳⣄ https://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#971903: transition: libmatio
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: block -1 by 971902 Control: forwarded -1 https://release.debian.org/transitions/html/auto-libmatio.html Dear Release Team, Please schedule a transition for libmatio (SOVERSION bump from 9 to 11). One reverse dependency, scilab, currently fails to build against the new version, a bug has been filed (see above). Cheers, Ben file: title = "libmatio"; is_affected = .depends ~ "libmatio9" | .depends ~ "libmatio11"; is_good = .depends ~ "libmatio11"; is_bad = .depends ~ "libmatio9"; -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Bug#934630: transition: octave
Le mardi 08 octobre 2019 à 20:40 +0200, Paul Gevers a écrit : > On 08-10-2019 14:07, Sébastien Villemot wrote: > > All packages concerned by this transition are now fixed, the only > > exception being octave-mpi. For the latter, I suggest that it be > > removed from testing, because the fix is not obvious, and upstream has > > to be involved. > > I'll hint it away. > > What about the two autopkgtest failures, octave-splines and octave-tsa: > https://qa.debian.org/excuses.php?package=octave Thanks, I have just uploaded fixed versions for these two. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#934630: transition: octave
Le jeudi 03 octobre 2019 à 21:35 +0200, Sébastien Villemot a écrit : > Le jeudi 03 octobre 2019 à 09:14 +0200, Paul Gevers a écrit : > > > Octave has now been built everywhere. Will you take care of all the > > failures in the reverse build depends? There are 16 packages that need > > your attention before octave can migrate. I filed one FTBFS bug already, > > but waiting for autoremoval isn't the way forward. > > I intend to work on the failures, beginning with the packages are not > maintained by the Debian Octave Group (since their maintainers are not > responsible for the situation). Clearly there are more failures than I > had anticipated, but that should still be manageable. All packages concerned by this transition are now fixed, the only exception being octave-mpi. For the latter, I suggest that it be removed from testing, because the fix is not obvious, and upstream has to be involved. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#934630: Please fasttrack nlopt for octave transition
Dear ftpmasters, If time permits, would it be possible for you to fasttrack nlopt 2.6.1- 1 that stands in the NEW queue? The version in unstable currently fails to build and is blocking the octave transition. The version in the NEW queue should solve that problem. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#934630: transition: octave
Le jeudi 03 octobre 2019 à 09:14 +0200, Paul Gevers a écrit : > Octave has now been built everywhere. Will you take care of all the > failures in the reverse build depends? There are 16 packages that need > your attention before octave can migrate. I filed one FTBFS bug already, > but waiting for autoremoval isn't the way forward. I intend to work on the failures, beginning with the packages are not maintained by the Debian Octave Group (since their maintainers are not responsible for the situation). Clearly there are more failures than I had anticipated, but that should still be manageable. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#934630: transition: octave
Le mardi 01 octobre 2019 à 20:34 +0200, Paul Gevers a écrit : > On 01-10-2019 17:35, Sébastien Villemot wrote: > > It failed to build for a 3rd time. So the problem is not transient, and > > I could reproduce it on the porterbox. […] > > I’m tempted to drop -g for that particular file and particular arch. > > Does that seem ok to you? > > As I have only limited understanding in that area, I can't advice you on > that (maybe other release team members can). But for now I would say, go > ahead, you can always revisit it. I did that (actually I completely disabled -g for mipsel, that was easier to achieve), I verified that it works on the porterbox, and I made a new upload (octave 5.1.0-3). However this time it failed to build on all arches, because of texinfo 6.7.0.dfsg.2-2 which was buggy. Since then, texinfo 6.7.0.dfsg.2-3 has been uploaded which should fix that. Can you please give octave back? (probably with a extra versioned dep on texinfo) Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#934630: transition: octave
Le lundi 30 septembre 2019 à 20:45 +0200, Paul Gevers a écrit : > On 30-09-2019 13:43, Emilio Pozuelo Monfort wrote: > > On 30/09/2019 11:56, Sébastien Villemot wrote: > > > The new version (5.1.0-2) is now uploaded and built on all release > > > architectures, except on mipsel. The build failure seems transient to > > > me (memory exhausted), because version 5.1.0-1 built previously on the > > > same buildd, and there is nothing in the diff between the two versions > > > that can explain the problem. > > > > I have given it back. > > I tried it a second time. If it's three in a row, please check carefully > again. It failed to build for a 3rd time. So the problem is not transient, and I could reproduce it on the porterbox. For a given C++ source file, the generated assembly file is 303Mb large. Then the assembler hits the virtual space memory limit (which is only 2Gb on mipsel, if I understand correctly). The problem did not happen with the toolchain that was used to compile octave 5.1.0-1 (gcc 8 and binutils 2.31). However, I’m under the impression that it’s not really a bug, but rather another manifestation of the limitations of 32-bit architectures (as was discussed on -devel@ last August). I found two possible workarounds: either dropping -g, or replacing -O2 with -O. I’m tempted to drop -g for that particular file and particular arch. Does that seem ok to you? -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#934630: transition: octave
Hi Paul, Le dimanche 29 septembre 2019 à 21:57 +0200, Paul Gevers a écrit : > On Mon, 12 Aug 2019 17:53:33 +0200 =?utf-8?q?S=C3=A9bastien_Villemot?= > wrote: > > Please schedule a transition for octave 5. > > > > Most reverse dependencies have already been updated by the Debian Octave > > Group > > and should therefore be compatible with the new version. We stand ready to > > NMU > > other reverse dependencies should the need arise. > > Please go ahead. The new version (5.1.0-2) is now uploaded and built on all release architectures, except on mipsel. The build failure seems transient to me (memory exhausted), because version 5.1.0-1 built previously on the same buildd, and there is nothing in the diff between the two versions that can explain the problem. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#934627: transition: libmatio
Le lundi 23 septembre 2019 à 22:13 +0200, Paul Gevers a écrit : > Control: tags -1 confirmed > > On 12-08-2019 17:24, Sébastien Villemot wrote: > > Please schedule a transition for libmatio. The new version stands in > > experimental. I expect the transition to be smooth (only two symbols > > deprecated, and those are not used by reverse dependencies according to > > sources.debian.org). > > Please go ahead. Thanks. It is now uploaded and built on all release archs. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#934630: transition: octave
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-octave.html Dear Release Team, Please schedule a transition for octave 5. Most reverse dependencies have already been updated by the Debian Octave Group and should therefore be compatible with the new version. We stand ready to NMU other reverse dependencies should the need arise. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Bug#934627: transition: libmatio
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-libmatio.html Dear Release Team, Please schedule a transition for libmatio. The new version stands in experimental. I expect the transition to be smooth (only two symbols deprecated, and those are not used by reverse dependencies according to sources.debian.org). Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Bug#924470: unblock: slime/2:2.23+dfsg-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear Release Team,
Please unblock package slime. The version in unstable fixes #923786, by
adapting the Recommends field to the new Emacs package layout in Buster.
Debdiff attached.
unblock slime/2:2.23+dfsg-2
Thanks,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
diff -Nru slime-2.23+dfsg/debian/changelog slime-2.23+dfsg/debian/changelog
--- slime-2.23+dfsg/debian/changelog2018-12-23 18:56:18.0 +0100
+++ slime-2.23+dfsg/debian/changelog2019-03-07 09:21:47.0 +0100
@@ -1,3 +1,10 @@
+slime (2:2.23+dfsg-2) unstable; urgency=medium
+
+ * Use emacs metapackage in Recommends, instead of obsolete emacs24* and
+emacs25* packages. (Closes: #923786)
+
+ -- Sébastien Villemot Thu, 07 Mar 2019 09:21:47 +0100
+
slime (2:2.23+dfsg-1) unstable; urgency=medium
* New upstream release
diff -Nru slime-2.23+dfsg/debian/control slime-2.23+dfsg/debian/control
--- slime-2.23+dfsg/debian/control 2018-12-23 18:55:20.0 +0100
+++ slime-2.23+dfsg/debian/control 2019-03-07 09:19:49.0 +0100
@@ -22,7 +22,7 @@
Architecture: all
Depends: ${misc:Depends},
${elpa:Depends}
-Recommends: cl-swank (= ${source:Version}), info | info-browser, emacs25 |
emacs24 (>= 24.3) | emacs24-lucid (>= 24.3) | emacs24-nox (>= 24.3)
+Recommends: cl-swank (= ${source:Version}), info | info-browser, emacs (>= 46)
Suggests: hyperspec
Description: Superior Lisp Interaction Mode for Emacs (client)
SLIME is the Superior Lisp Interaction Mode for Emacs.
Bug#924467: unblock: openblas/0.3.5+ds-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, Please unblock package openblas. The version in unstable fixes #923607 (FTBFS when build host CPU is not detected). Some bits of context: OpenBLAS is an efficient implementation of BLAS (an API for numerical linear algebra routines), that provides specialized kernels (with some assembly) for different CPU micro-architectures. On amd64, arm64 and i386, the selection of the kernel is done at runtime, after detecting the CPU version (on other arches, the package is compiled with a single kernel, compatible with the arch baseline). It turns out that CPU detection is also done at build time, if the TARGET build variable is not set, for initializing a few variables. This triggers an FTBFS if the CPU is unknown to the build system. The fix consist in building with TARGET=GENERIC (a dummy generic CPU micro-archictecture). This also requires a small patch to make this works. The debdiff is attached. unblock openblas/0.3.5+ds-3 Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org diff -Nru openblas-0.3.5+ds/debian/changelog openblas-0.3.5+ds/debian/changelog --- openblas-0.3.5+ds/debian/changelog 2019-02-09 10:38:22.0 +0100 +++ openblas-0.3.5+ds/debian/changelog 2019-03-11 10:18:39.0 +0100 @@ -1,3 +1,13 @@ +openblas (0.3.5+ds-3) unstable; urgency=medium + + * Fix FTBFS when CPU of the build machine is not detected (amd64, arm64, i386) +- pass TARGET=GENERIC when building with DYNAMIC_ARCH=1 +- target-generic.patch: new patch taken from upstream, makes the above + possible +(Closes: #923607) + + -- Sébastien Villemot Mon, 11 Mar 2019 10:18:39 +0100 + openblas (0.3.5+ds-2) unstable; urgency=medium * skylakex-dgemm.patch: new patch, fixes DGEMM regression on SkylakeX. diff -Nru openblas-0.3.5+ds/debian/patches/series openblas-0.3.5+ds/debian/patches/series --- openblas-0.3.5+ds/debian/patches/series 2019-02-09 10:35:46.0 +0100 +++ openblas-0.3.5+ds/debian/patches/series 2019-03-11 10:07:18.0 +0100 @@ -6,3 +6,4 @@ matgen-symbols-not-included.patch order-files.patch skylakex-dgemm.patch +target-generic.patch diff -Nru openblas-0.3.5+ds/debian/patches/target-generic.patch openblas-0.3.5+ds/debian/patches/target-generic.patch --- openblas-0.3.5+ds/debian/patches/target-generic.patch 1970-01-01 01:00:00.0 +0100 +++ openblas-0.3.5+ds/debian/patches/target-generic.patch 2019-03-11 10:09:06.0 +0100 @@ -0,0 +1,20 @@ +Description: Make TARGET=GENERIC compatible with DYNAMIC_ARCH=1 +Origin: backport, https://github.com/xianyi/OpenBLAS/commit/5b95534afcc80d54f51bd766b617fd3f494ec65a +Bug: https://github.com/xianyi/OpenBLAS/issues/2048 +Bug-Debian: https://bugs.debian.org/923607 +Last-Update: 2019-03-11 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +diff --git a/kernel/Makefile.L3 b/kernel/Makefile.L3 +index eafcfb1b..bf5fffe8 100644 +--- a/kernel/Makefile.L3 b/kernel/Makefile.L3 +@@ -24,7 +24,7 @@ ifeq ($(TARGET), LOONGSON3B) + USE_TRMM = 1 + endif + +-ifeq ($(TARGET), GENERIC) ++ifeq ($(CORE), GENERIC) + USE_TRMM = 1 + endif + diff -Nru openblas-0.3.5+ds/debian/rules openblas-0.3.5+ds/debian/rules --- openblas-0.3.5+ds/debian/rules 2018-12-07 15:31:18.0 +0100 +++ openblas-0.3.5+ds/debian/rules 2019-03-04 15:11:28.0 +0100 @@ -11,10 +11,11 @@ # Build generic package with hardcoded max number of threads of 64 GENERIC_OPTIONS := NUM_THREADS=64 -# On x86 archs, enable dynamic arch selection +# On x86 and arm64 archs, enable dynamic arch selection +# TARGET=GENERIC is needed to avoid FTBFS when CPU detectin fails (see #923607) ENABLE_DYNAMIC_ARCHS := amd64 arm64 i386 kfreebsd-amd64 kfreebsd-i386 ifneq (,$(findstring $(DEB_HOST_ARCH),$(ENABLE_DYNAMIC_ARCHS))) - GENERIC_OPTIONS += DYNAMIC_ARCH=1 DYNAMIC_OLDER=1 + GENERIC_OPTIONS += DYNAMIC_ARCH=1 DYNAMIC_OLDER=1 TARGET=GENERIC endif # For other archs, there is no dynamic arch selection. To avoid selecting a
Bug#924464: unblock: cl-fad/20180430-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, Please unblock package cl-fad. The version in unstable fixes #923666, by simply marking an autopkgtest as flaky. Debdiff attached. unblock cl-fad/20180430-3 Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org diff -Nru cl-fad-20180430/debian/changelog cl-fad-20180430/debian/changelog --- cl-fad-20180430/debian/changelog2019-02-14 14:33:05.0 +0100 +++ cl-fad-20180430/debian/changelog2019-03-04 14:24:52.0 +0100 @@ -1,3 +1,10 @@ +cl-fad (20180430-3) unstable; urgency=medium + + * Mark the autopkgtest for clisp as flaky. It often segfaults. +(Closes: #923666) + + -- Sébastien Villemot Mon, 04 Mar 2019 14:24:52 +0100 + cl-fad (20180430-2) unstable; urgency=medium * Move maintenance to Debian Common Lisp Team. diff -Nru cl-fad-20180430/debian/tests/control cl-fad-20180430/debian/tests/control --- cl-fad-20180430/debian/tests/control2019-02-14 14:27:59.0 +0100 +++ cl-fad-20180430/debian/tests/control2019-03-04 14:23:51.0 +0100 @@ -8,4 +8,4 @@ Test-Command: clisp -norc debian/tests/runtests.lisp Depends: @, clisp -Restrictions: allow-stderr +Restrictions: allow-stderr, flaky
Bug#907342: transition: octave
Le mardi 02 octobre 2018 à 09:43 +0200, Emilio Pozuelo Monfort a écrit : > On 26/08/2018 21:05, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-octave.html > > > > Dear Release Team, > > > > Please schedule a transition for octave. The latest minor release (4.4.1) > > bumped the SOVERSION of liboctave. > > > > Since this ABI change, though not backward compatible, is minimal, the > > transition should be straightforward. In any case, we stand ready to fix > > issues > > and NMU if needed. > > > > The new version of octave is already in experimental. > > Please go ahead. Thanks. Octave 4.4.1 has been uploaded to unstable and is now compiled on all release architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: This is a digitally signed message part
Bug#907342: transition: octave
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-octave.html Dear Release Team, Please schedule a transition for octave. The latest minor release (4.4.1) bumped the SOVERSION of liboctave. Since this ABI change, though not backward compatible, is minimal, the transition should be straightforward. In any case, we stand ready to fix issues and NMU if needed. The new version of octave is already in experimental. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org
Bug#901155: transition: octave-4.4
Hi Emilio,
On Mon, Jun 18, 2018 at 10:24:56AM +0200, Emilio Pozuelo Monfort wrote:
> On 18/06/18 09:45, Sébastien Villemot wrote:
> > On Tue, Jun 12, 2018 at 08:36:54AM +0200, Emilio Pozuelo Monfort wrote:
> >> On 12/06/18 08:05, Sébastien Villemot wrote:
> >>> On Mon, Jun 11, 2018 at 11:18:01AM +0200, Emilio Pozuelo Monfort wrote:
> >>>> On 10/06/18 08:45, Sébastien Villemot wrote:
> >>>
> >>>>> Thanks. Octave 4.4.0-3 is now uploaded and built on all release
> >>>>> architectures.
> >>>>
> >>>> In case you didn't notice: the binNMUs are done and a bunch of packages
> >>>> failed
> >>>> to build. Please look at them.
> >>>
> >>> Could you please give back:
> >>> - lhapdf
> >>> - octave-geometry
> >>> - octave-communications
> >>>
> >>> These should be fixed by the latest dh-octave (0.5.3).
> >
> > Could you please also give back plplot? It should be fixed by the latest
> > swig.
>
> Given back.
We have fixed most build failures related to the octave 4.4 transition. We
think the four remaining packages should be removed from testing:
- libsbml: FTBFS for reasons not related to the transition (#901455), has
another RC bug (#896531), scheduled for removal on July 4th;
- octave-{odepkg,tisean,ltfat}: these packages are maintained by the Debian
Octave Group, and we currently don't have a patch to fix them. They're all
leaf packages, except octave-odepkg, whose reverse dependency octave-ocs will
therefore needs to be removed too.
Thanks,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
signature.asc
Description: PGP signature
Bug#901155: transition: octave-4.4
Hi Emilio, On Tue, Jun 12, 2018 at 08:36:54AM +0200, Emilio Pozuelo Monfort wrote: > On 12/06/18 08:05, Sébastien Villemot wrote: > > On Mon, Jun 11, 2018 at 11:18:01AM +0200, Emilio Pozuelo Monfort wrote: > >> On 10/06/18 08:45, Sébastien Villemot wrote: > > > >>> Thanks. Octave 4.4.0-3 is now uploaded and built on all release > >>> architectures. > >> > >> In case you didn't notice: the binNMUs are done and a bunch of packages > >> failed > >> to build. Please look at them. > > > > Could you please give back: > > - lhapdf > > - octave-geometry > > - octave-communications > > > > These should be fixed by the latest dh-octave (0.5.3). Could you please also give back plplot? It should be fixed by the latest swig. Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Re: octave/4.4.0-3 appears to break dynare/4.5.4-2 in testing
On Thu, Jun 14, 2018 at 10:58:47AM +0200, Paul Gevers wrote: > On 14-06-18 10:08, Sébastien Villemot wrote: > >> I saw an upload of dynare 4.5.5-2, which apparently tried to fix part of > >> this, but now the test for dynare migration¹ fails with a segfault of > >> octave. Looking at the list of installed packages and their versions, I > >> suspect dynare is missing a *versioned* dependency on the latest octave. > >> What do you think? > > I guess what's happening here is that the test bed contains dynare 4.5.5-2, > > liboctave5 and octave 4.2.2-3 (and not 4.4), which is a combination which is > > technically possible but indeed broken. > > So let's make sure the archive knows that. > > In any case, even though the dependency relationships are not perfect, > > nothing > > is actually broken, and the problem will disappear after the transition is > > complete. > I think the versioned Depends solution is correct. The reason why I > think we (as maintainers) should start caring more is that we need > autopkgtest to be able to figure this out by itself and for that it > needs to be fed with the right relations. This *is* making the > transition more difficult because the RT now has to judge if you made > the right assessment. It's so much easier if the test just passes. I have just uploaded dynare 4.5.5-3 which has a versioned dependency on octave 4.4. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#901155: transition: octave-4.4
Hi Emilio, On Mon, Jun 11, 2018 at 11:18:01AM +0200, Emilio Pozuelo Monfort wrote: > On 10/06/18 08:45, Sébastien Villemot wrote: > > Thanks. Octave 4.4.0-3 is now uploaded and built on all release > > architectures. > > In case you didn't notice: the binNMUs are done and a bunch of packages failed > to build. Please look at them. Could you please give back: - lhapdf - octave-geometry - octave-communications These should be fixed by the latest dh-octave (0.5.3). Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#901155: transition: octave-4.4
On Mon, Jun 11, 2018 at 11:18:01AM +0200, Emilio Pozuelo Monfort wrote: > On 10/06/18 08:45, Sébastien Villemot wrote: > > On Sat, Jun 09, 2018 at 07:52:12PM +0200, Emilio Pozuelo Monfort wrote: > > > >> On 09/06/18 16:22, Sébastien Villemot wrote: > >>> Package: release.debian.org > >>> Severity: normal > >>> User: release.debian@packages.debian.org > >>> Usertags: transition > >>> Control: forwarded -1 > >>> https://release.debian.org/transitions/html/auto-octave.html > >>> > >>> Dear Release Team, > >>> > >>> Please schedule a transition for octave 4.4. The new package is already in > >>> experimental. > >>> > >>> Few reverse dependencies will need sourceful NMUs. In any case, we stand > >>> ready > >>> to NMU. > >> > >> Go ahead. > > > > Thanks. Octave 4.4.0-3 is now uploaded and built on all release > > architectures. > > In case you didn't notice: the binNMUs are done and a bunch of packages failed > to build. Please look at them. Thanks. We have started to work on these. There are actually more failures than we had anticipated, sorry for that. I’ll keep you updated. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#901155: transition: octave-4.4
On Sat, Jun 09, 2018 at 07:52:12PM +0200, Emilio Pozuelo Monfort wrote: > On 09/06/18 16:22, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-octave.html > > > > Dear Release Team, > > > > Please schedule a transition for octave 4.4. The new package is already in > > experimental. > > > > Few reverse dependencies will need sourceful NMUs. In any case, we stand > > ready > > to NMU. > > Go ahead. Thanks. Octave 4.4.0-3 is now uploaded and built on all release architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#901155: transition: octave-4.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-octave.html Dear Release Team, Please schedule a transition for octave 4.4. The new package is already in experimental. Few reverse dependencies will need sourceful NMUs. In any case, we stand ready to NMU. Thanks! -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On Fri, Jun 01, 2018 at 08:20:48AM +0200, Andreas Tille wrote: > I have uploaded r-cran-pkgconfig at Thu May 31 20:37:04 BST 2018 [1] and it > was accepted to unstable at Thu May 31 20:53:21 BST 2018 [2]. However, > packages.d.o states it has r-api-3.4! :-( It's because r-cran-pkgconfig 2.0.1-3 has not yet been built (right now it is marked as "Needs-Build") > PS: Another random pick is r-cran-pwt with the same issue. :-( Re r-cran-pwt, it was accepted at Thu, 31 May 2018 21:39:48 +0200, but it has been marked as “Installed” (in the build logs page) only since 2h ago. And it is therefore not yet available on mirrors. So it looks like it's just a matter of waiting. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#896667: transition: r-base-3.5
Hi Dirk, On Thu, May 31, 2018 at 08:09:28AM -0500, Dirk Eddelbuettel wrote: > Can you confirm that now that we have > a) "green light" on the transition, and > b) the r-base package is in unstable > we should see binary: any packages being rebuilt -- which I do not yet > see. When will this start? Note that Andreas has already started to upload arch:all packages. You can see them on that page: https://release.debian.org/transitions/html/r-base-3.5.html … after clicking the “good” button. You will see some green lights appearing. Basically the transition will be finished once everything is green. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#896945: stretch-pu: package cffi/0.18.0-1+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
I have prepared (and uploaded) an update to the cffi package that fixes
#894543. The debdiff is attached.
Best,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
diff -u cffi-0.18.0/debian/changelog cffi-0.18.0/debian/changelog
--- cffi-0.18.0/debian/changelog
+++ cffi-0.18.0/debian/changelog
@@ -1,3 +1,12 @@
+cffi (1:0.18.0-1+deb9u1) stretch; urgency=medium
+
+ * Add missing files for cffi-libffi and cffi-toolchain. (Closes: #894543)
+ * Add missing Depends on gcc (for cffi-toolchain), pkg-config and
+libc6-dev | libc-dev (for cffi-grovel) and libffi-dev (for
+cffi-libffi).
+
+ -- Sébastien Villemot Thu, 26 Apr 2018 08:24:48 +
+
cffi (1:0.18.0-1) unstable; urgency=medium
* Quicklisp release update.
diff -u cffi-0.18.0/debian/control cffi-0.18.0/debian/control
--- cffi-0.18.0/debian/control
+++ cffi-0.18.0/debian/control
@@ -11,7 +11,11 @@
Package: cl-cffi
Architecture: all
-Depends: ${misc:Depends}, cl-alexandria, cl-trivial-features, cl-babel
+Depends: ${misc:Depends}, cl-alexandria, cl-trivial-features, cl-babel,
+ gcc,
+ libc6-dev | libc-dev,
+ pkg-config,
+ libffi-dev
Description: The Common Foreign Function Interface for Common Lisp
CFFI, the Common Foreign Function Interface, purports to be a portable foreign
function interface for Common Lisp. The CFFI library is composed of a
diff -u cffi-0.18.0/debian/install cffi-0.18.0/debian/install
--- cffi-0.18.0/debian/install
+++ cffi-0.18.0/debian/install
@@ -1 +1 @@
-*.asd examples/ tests/ uffi-compat/ src/ grovel/ usr/share/common-lisp/source/cl-cffi/
+*.asd examples/ tests/ uffi-compat/ src/ grovel/ libffi/ toolchain/ usr/share/common-lisp/source/cl-cffi/
signature.asc
Description: PGP signature
Bug#896667: transition: r-base-3.5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: debia...@lists.debian.org Dear Release Team, Please schedule a transition for R 3.5, which has just been uploaded to experimental. Due to changes in R internals, all R extension packages must be recompiled, that is 573 packages (of which 260 are arch:all, and will therefore need sourceful uploads). The transition will be managed jointly by Dirk Eddelbuettel and the Debian R Packages Team¹ (which ideally should be kept in CC of replies). We have not tried to recompile the 500+ packages, but we don’t expect any major issue. And should some arise, we stand ready to fix them. Best, Ben file: title = "r-base"; is_affected = .depends ~ "r-api-3.4" | .depends ~ "r-api-3.5"; is_good = .depends ~ "r-api-3.5"; is_bad = .depends ~ "r-api-3.4"; ¹ https://wiki.debian.org/Teams/r-pkg-team -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#889983: stretch-pu: package glade/3.20.0-2+deb9u1
On Fri, Feb 23, 2018 at 05:36:38PM +, Adam D. Barratt wrote: > On Fri, 2018-02-09 at 18:12 +0100, Sébastien Villemot wrote: > > I prepared a p-u for glade, fixing #859324 (basically glade eats a > > lot of CPU > > as soon as a non-trivial UI is created). > > > > Please go ahead. Thanks, uploaded. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#889983: stretch-pu: package glade/3.20.0-2+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
I prepared a p-u for glade, fixing #859324 (basically glade eats a lot of CPU
as soon as a non-trivial UI is created).
The debdiff is attached. It also includes Vcs changes related to the
salsa move.
Best,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
diff -Nru glade-3.20.0/debian/changelog glade-3.20.0/debian/changelog
--- glade-3.20.0/debian/changelog 2016-10-21 00:51:16.0 +0200
+++ glade-3.20.0/debian/changelog 2018-02-09 18:02:27.0 +0100
@@ -1,3 +1,16 @@
+glade (3.20.0-2+deb9u1) stretch; urgency=medium
+
+ * Team upload.
+
+ [ Sébastien Villemot ]
+ * fix-use-of-gtk-style-context-in-GladeDesignLayout.patch: new patch.
+Fixes high CPU usage. (Closes: #859324)
+
+ [ Jeremy Bicha ]
+ * Update Vcs fields and add debian/gbp.conf
+
+ -- Sébastien Villemot Fri, 09 Feb 2018 18:02:27 +0100
+
glade (3.20.0-2) unstable; urgency=medium
[ Jeremy Bicha ]
diff -Nru glade-3.20.0/debian/control glade-3.20.0/debian/control
--- glade-3.20.0/debian/control 2016-10-21 00:51:16.0 +0200
+++ glade-3.20.0/debian/control 2018-02-09 18:02:27.0 +0100
@@ -7,8 +7,8 @@
Priority: optional
Maintainer: Debian GNOME Maintainers
Uploaders: Andreas Henriksson , Emilio Pozuelo Monfort , Michael Biebl
-Vcs-Browser: https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/glade
-Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/glade
+Vcs-Git: https://salsa.debian.org/gnome-team/glade.git -B debian/stretch
+Vcs-Browser: https://salsa.debian.org/gnome-team/glade/tree/debian/stretch
Build-Depends: debhelper (>= 10),
gnome-pkg-tools (>= 0.10),
gnome-common,
diff -Nru glade-3.20.0/debian/control.in glade-3.20.0/debian/control.in
--- glade-3.20.0/debian/control.in 2016-10-21 00:44:23.0 +0200
+++ glade-3.20.0/debian/control.in 2018-02-09 17:51:16.0 +0100
@@ -3,8 +3,8 @@
Priority: optional
Maintainer: Debian GNOME Maintainers
Uploaders: @GNOME_TEAM@
-Vcs-Browser: https://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/glade
-Vcs-Svn: svn://anonscm.debian.org/pkg-gnome/desktop/unstable/glade
+Vcs-Git: https://salsa.debian.org/gnome-team/glade.git -B debian/stretch
+Vcs-Browser: https://salsa.debian.org/gnome-team/glade/tree/debian/stretch
Build-Depends: debhelper (>= 10),
gnome-pkg-tools (>= 0.10),
gnome-common,
diff -Nru glade-3.20.0/debian/gbp.conf glade-3.20.0/debian/gbp.conf
--- glade-3.20.0/debian/gbp.conf 1970-01-01 01:00:00.0 +0100
+++ glade-3.20.0/debian/gbp.conf 2018-02-09 18:00:38.0 +0100
@@ -0,0 +1,4 @@
+[DEFAULT]
+pristine-tar = True
+debian-branch = debian/stretch
+upstream-branch = upstream/3.20.x
diff -Nru glade-3.20.0/debian/patches/fix-use-of-gtk-style-context-in-GladeDesignLayout.patch glade-3.20.0/debian/patches/fix-use-of-gtk-style-context-in-GladeDesignLayout.patch
--- glade-3.20.0/debian/patches/fix-use-of-gtk-style-context-in-GladeDesignLayout.patch 1970-01-01 01:00:00.0 +0100
+++ glade-3.20.0/debian/patches/fix-use-of-gtk-style-context-in-GladeDesignLayout.patch 2018-02-09 17:44:05.0 +0100
@@ -0,0 +1,52 @@
+Description: Fix use of GTK+ style context in GladeDesignLayout.
+ It seems like modifying the style context in the 'draw' handler is not
+ recommended, and we need to save/restore the context.
+ .
+ Otherwise, for some widgets (GtkButton, GtkComboBox), the
+ GladeDesignLayout gets trapped in draw-damage loop.
+ .
+ See 0c076cc8828cd80f1f156a08569199675bf35165 for reference.
+Author: Arnaud Rebillout
+Origin: https://git.gnome.org/browse/glade/commit/?id=ac55fa78566145ac44d48ba88ec1351db5b4a99d
+Bug: https://bugzilla.gnome.org/show_bug.cgi?id=763624
+Bug-Debian: https://bugs.debian.org/859324
+Reviewed-By: Sébastien Villemot
+Last-Updated: 2018-02-09
+--- a/gladeui/glade-design-layout.c
b/gladeui/glade-design-layout.c
+@@ -1033,13 +1033,13 @@ draw_frame (GtkWidget *widget, cairo_t *cr, gboolean selected,
+ if (priv->widget_name)
+ {
+ GdkRectangle *rect = &priv->south_east;
+-
++ gtk_style_context_save (context);
+ gtk_style_context_add_class (context, "handle");
+ gtk_render_background (context, cr, rect->x, rect->y, rect->width, rect->height);
+ gtk_render_frame (context, cr, rect->x, rect->y, rect->width, rect->height);
+ gtk_render_layout (context, cr, rect->x + OUTLINE_WIDTH, rect->y + OUTLINE_WIDTH,
+ priv->widget_name);
+- gtk_style_context_remove_class (context, "handle");
++ gtk_style_context_restore (context);
+ }
+ }
+
+@@ -1084,6 +1084,7 @@ draw_selection (cairo_t *cr,
+ if (alloc.x < 0 || alloc.y < 0) return;
Bug#887060: testing migration happened despite FTBFS on arch:all buildd
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: britney Hi, Package src:octave-interval creates two binaries: - octave-interval (arch:any) - octave-interval-doc (arch:all) Version 3.1.0-3 was uploaded on 2018-01-07 as source-only: https://tracker.debian.org/news/899881 Compilation went fine on the arch:any buildds, but failed on the arch:all one: https://buildd.debian.org/status/fetch.php?pkg=octave-interval&arch=all&ver=3.1.0-3&stamp=1515343715&raw=0 Still, testing migration occurred on 2018-01-13: https://tracker.debian.org/news/901166 As of 2018-01-13, the dak status is the following: $ ssh coccia dak ls octave-interval octave-interval-doc octave-interval | 2.1.0-2 | stable | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x octave-interval | 2.1.0-2 | unstable | source octave-interval | 2.1.0-2 | unstable-debug | source octave-interval | 2.1.0-2+b1| unstable | kfreebsd-amd64, kfreebsd-i386 octave-interval | 3.1.0-3 | testing| source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x octave-interval | 3.1.0-3 | unstable | source, amd64, arm64, armel, armhf, hurd-i386, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x octave-interval | 3.1.0-3 | unstable-debug | source octave-interval-doc | 2.1.0-2 | stable | all octave-interval-doc | 2.1.0-2 | unstable | all octave-interval-doc | 3.1.0-2 | unstable | all i.e. octave-interval is present in testing but octave-interval-doc is not. (I will probably request soon a give-back for octave-interval-doc, so this state will not persist for long). Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#885420: transition: suitesparse
On Wed, Dec 27, 2017 at 10:10:04AM +0100, Emilio Pozuelo Monfort wrote: > On 26/12/17 22:47, Sébastien Villemot wrote: > > Please schedule a transition for suitesparse. Only one library had an SONAME > > bump, and actually there was no ABI change, so the transition should be > > straightforward. I am in touch with upstream, who hopefully will avoid such > > unneeded SONAME bumps in the future. > > Go ahead. Thanks. It’s now uploaded and compiled on all release architectures. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#885420: transition: suitesparse
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Control: forwarded -1 https://release.debian.org/transitions/html/auto-suitesparse.html Dear Release Team, Please schedule a transition for suitesparse. Only one library had an SONAME bump, and actually there was no ABI change, so the transition should be straightforward. I am in touch with upstream, who hopefully will avoid such unneeded SONAME bumps in the future. Thanks, Ben file: title = "suitesparse"; is_affected = .depends ~ "libsuitesparseconfig4" | .depends ~ "libsuitesparseconfig5"; is_good = .depends ~ "libsuitesparseconfig5"; is_bad = .depends ~ "libsuitesparseconfig4"; -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#879465: nmu: xindy_2.5.1.20160104-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: xi...@packages.debian.org, agmar...@debian.org Dear Release Team, Please schedule a binNMU of xindy, which has to be recompiled against the new ABI provided by clisp (note that ABI version is exposed by clisp through the provided pseudo-package clisp-fasl-loader-, whose value has therefore been bumped). Also note that xindy did FTBFS on armel and armhf because of a bug in clisp, which should now be fixed. It should therefore be given back on those arches. nmu xindy_2.5.1.20160104-2 . ANY -armel -armhf . unstable . -m "rebuild against clisp 1:2.49.20170913-3" gb xindy_2.5.1.20160104-2 . armel armhf Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#868558: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)
On Thu, Oct 12, 2017 at 09:13:54AM -0500, Dirk Eddelbuettel wrote: > > On 12 October 2017 at 15:58, Sébastien Villemot wrote: > | Thanks Charles for explaining this. > | > | Actually the migration has already happened, thanks to the Release Team that > | took appropriate action to mitigate the impact of the most recent uploads. > | > | This will soon be reflected in the tracker and various web pages. > | > | R-related uploads can therefore be resumed. > > Nice. > > Was there a way to read that off the (otherwise very impressive and helpful) > tracker status page? Or was is somewhere else? For the moment you can only see it on the main archive database: $ rmadison r-base r-base | 2.15.1-4 | oldoldstable | source, all r-base | 3.1.1-1| oldstable-kfreebsd | source, all r-base | 3.1.1-1+deb8u1 | oldstable | source, all r-base | 3.3.3-1~bpo8+1 | jessie-backports | source, all r-base | 3.3.3-1| stable | source, all r-base | 3.4.2-1| testing| source, all r-base | 3.4.2-1| unstable | source, all > This was a good dry run. Come R 3.5.0 next April we actually MUST rebuild > all packages rather than just doing it because we can. I'll circle back > closer to the date, the r-devel branch upstream is still a little shaky. Ok, looking forward to it. When it is ready, please follow the transition guidelines which are summarized there: https://wiki.debian.org/Teams/ReleaseTeam/Transitions The short version of it is: please open a transition bug and wait for an ack from the Release Team *before* uploading R 3.5 to unstable (but of course you are free to upload to experimental sooner). Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#868558: Would you please not upload new r-* packages until transition is finalised (Re: r-api-3.4)
On Thu, Oct 12, 2017 at 10:40:00PM +0900, Charles Plessy wrote: > the point is that r-base and all the other packages will only migrate to > testing when all of them will be ready at the same time. Packages need > 5 days to migrate to Testing and each upload resets the counter, thus > blocking the migration of all. Therefore, a break of 5 days without > uploads is needed if we want to see the r-* packages in Testing. Thanks Charles for explaining this. Actually the migration has already happened, thanks to the Release Team that took appropriate action to mitigate the impact of the most recent uploads. This will soon be reflected in the tracker and various web pages. R-related uploads can therefore be resumed. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#868558: transition: r-api-3.4
Hi, Here is a status update about the r-base 3.4 transition. All packages have been recompiled against R 3.4, and almost all of them have reached the required age before testing migration becomes possible. There are still a couple of blockers, given by britney's output (in the second autohint): * amd64: r-cran-maldiquantforeign, r-cran-readbrukerflexdata, r-cran-vcdextra * i386: r-cran-maldiquantforeign, r-cran-readbrukerflexdata, r-cran-vcdextra * armel: r-cran-knitr The reasons are as follows: - r-cran-vcdextra is too young (I had to upload it yesterday because of #878010) - r-cran-readbrukerflexdata is too young (it was uploaded with urgency=low) - r-cran-maldiquantforeign depends on the previous one - r-cran-knitr was uninstallable on armel, because node.js is no longer available on that arch. I made a new upload of r-cran-knitr that makes the package FTBFS on armel, and I filed an RM removal for armel (#878062) (I asked for fast processing on #-ftp) So we're almost there (and a couple of age-days or testing-RM could help finish it faster, but of course it's up to the Release Team). In the meantime, please everyone refrain from making any R-related upload, that would only delay the transition. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
On Thu, Sep 28, 2017 at 07:04:51AM -0500, Dirk Eddelbuettel wrote: > > On 28 September 2017 at 13:20, Sébastien Villemot wrote: > | On Thu, Sep 28, 2017 at 12:53:10PM +0200, Graham Inggs wrote: > | > On 28/09/2017 12:28, Sébastien Villemot wrote: > | > > Note that there are many arch:all R packages that will need sourceful > upload > | > > (they are easy to identify on the transition tracker whose URL is > above). > | > > | > Besides r-cran-nlp which doesn't show up in the tracker, I've found > several > | > other arch:all packages that don't depend on r-api-3, but do pick up a > | > dependency on r-api-3.4 after a rebuild: > | > | This makes me wonder whether arch:all packages really need a dependency on > r-api-*. > | > | If this value really tracks an API, as advertised, it makes sense. But if it > | actually tracks an ABI, as in the present case, then this situation is > | suboptimal and complicates transition. > | > | Maybe the best solution would therefore be to dissociate API and ABI > tracking. > | > | Moreover, packages automatically pick up a versioned dependency on > r-base-core. > | But this should not be necessary since we now have ABI tracking. It makes > | dependencies uselessly tight. > | > | Anyways, these (potential) improvements should probably wait for the next > | transition (planned in April if I understand correctly). > > There transitions, and then there are transitions. Let me explain: > > - right now a subset of 'source: any' package needs a rebuild; here we could > in fact discuss leaving 'source: all' out > > - R 3.5.0 will need a rebuild of all 'source: any' packages > > - In the past we rebuilds for nonAPI reasons: reorganisation of R's internal > help system (and internal file format) was one > > So we may as well through the big mantle of the so-called "API" transition > around all dependent packages. But we don't _have to_ right now. > > Can be argued either way. Do as you see fit. I now understand that we ideally need two API/ABI-like values instead of one: - one that is bumped when only arch:any packages need to be rebuilt - the other one that is bumped when both arch:any and arch:all packages should be rebuilt The first value would appear in the Depends of arch:any package, but not of arch:all ones; the second value would appear in the Depends of both arch:any and arch:all. Because, for this transition and for the next one (in April), we will have to make sourceful uploads of ~170 arch:all packages… that actually do not need to be rebuilt. And this is very painful because it must be done manually (contrary to rebuilds of arch:any packages that can be trigerred easily). If we adopted this scheme right now, that would save us a lot of work for the April transition (but not for this one, because we first have to convert arch:all packages to the new scheme). Please tell me what you think. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
On Thu, Sep 28, 2017 at 12:53:10PM +0200, Graham Inggs wrote: > On 28/09/2017 12:28, Sébastien Villemot wrote: > > Note that there are many arch:all R packages that will need sourceful upload > > (they are easy to identify on the transition tracker whose URL is above). > > Besides r-cran-nlp which doesn't show up in the tracker, I've found several > other arch:all packages that don't depend on r-api-3, but do pick up a > dependency on r-api-3.4 after a rebuild: This makes me wonder whether arch:all packages really need a dependency on r-api-*. If this value really tracks an API, as advertised, it makes sense. But if it actually tracks an ABI, as in the present case, then this situation is suboptimal and complicates transition. Maybe the best solution would therefore be to dissociate API and ABI tracking. Moreover, packages automatically pick up a versioned dependency on r-base-core. But this should not be necessary since we now have ABI tracking. It makes dependencies uselessly tight. Anyways, these (potential) improvements should probably wait for the next transition (planned in April if I understand correctly). -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
On Thu, Sep 28, 2017 at 12:33:39AM +0200, Emilio Pozuelo Monfort wrote: > Control: forwarded -1 > https://release.debian.org/transitions/html/r-base-3.4.html > Control: tags -1 confirmed > > On 24/09/17 15:36, Sébastien Villemot wrote: > > The latest upload of r-base, versioned 3.4.1.20170921-1, has bumped the ABI > > pseudo package from "r-api-3" to "r-api-3.4", as requested. > > > > Please therefore schedule rebuilds as necessary. > > Will do so. Thanks. Note that there are many arch:all R packages that will need sourceful upload (they are easy to identify on the transition tracker whose URL is above). Most of them are maintained by either Dirk, Debian Med or Debian Science. I am going to take care of those maintained by the Debian Science Team. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#875777: stretch-pu: package ecl/15.3.7+dfsg1-2+deb9u1
On Sat, Sep 23, 2017 at 05:25:15PM +0100, Jonathan Wiltshire wrote: > On Thu, Sep 14, 2017 at 02:45:16PM +0200, Sébastien Villemot wrote: > > I have prepared a stretch-pu for ecl. The debdiff is attached. It simply > > fixes > > #873091 by adding the dependency on libffi-dev. > > Please go ahead. Thanks, uploaded. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#868558: transition: r-api-3.4 [was Re: Bug#868558: nmu: multiple r-* packages]
Control: reopen -1 Control: retitle -1 transition: r-api-3.4 Control: user release.debian@packages.debian.org Control: usertags -1 = transition On Sun, Sep 10, 2017 at 04:15:00PM +, Niels Thykier wrote: > To be perfectly, honest, I would prefer if you did a proper ABI-like > transition over the Breaks. At this scale, Breaks seems too fragile and > too likely for people to get wrong. The latest upload of r-base, versioned 3.4.1.20170921-1, has bumped the ABI pseudo package from "r-api-3" to "r-api-3.4", as requested. Please therefore schedule rebuilds as necessary. The ben file should look like: title = "r-api-3.4"; is_affected = .depends ~ /r-api-3(\.4)?/; is_good = .depends ~ /r-api-3\.4/; is_bad = .depends ~ /r-api-3\b/; Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#875548: nmu: clisp_1:2.49.60+-2 mlpcap_0.9-17
On Tue, Sep 12, 2017 at 08:45:24AM +0200, Sébastien Villemot wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > > Dear Release Team, > > A mini-transition is underway following the SOVERSION bump of ffcall (see > [1]). > > Please schedule binNMUs for the two affected packages: > > nmu clisp_1:2.49.60+-2 . ANY . unstable . -m "rebuild against libffcall1a" > nmu mlpcap_0.9-17 . ANY . unstable . -m "rebuild against libffcall1a" A new upload of clisp has been made, so this request now concerns only mlpcap. Thanks, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#875777: stretch-pu: package ecl/15.3.7+dfsg1-2+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
I have prepared a stretch-pu for ecl. The debdiff is attached. It simply fixes
#873091 by adding the dependency on libffi-dev.
Best,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
diff -Nru ecl-15.3.7+dfsg1/debian/changelog ecl-15.3.7+dfsg1/debian/changelog
--- ecl-15.3.7+dfsg1/debian/changelog 2016-10-10 18:34:53.0 +0200
+++ ecl-15.3.7+dfsg1/debian/changelog 2017-09-14 14:33:03.0 +0200
@@ -1,3 +1,10 @@
+ecl (15.3.7+dfsg1-2+deb9u1) stretch; urgency=medium
+
+ * Team upload.
+ * Add dependency on libffi-dev for ecl (Closes: #873091).
+
+ -- Sébastien Villemot Thu, 14 Sep 2017 14:33:03 +0200
+
ecl (15.3.7+dfsg1-2) unstable; urgency=medium
* Add bignums-dont-collect-gmp-internal-memory.patch. (Closes: #777473)
diff -Nru ecl-15.3.7+dfsg1/debian/control ecl-15.3.7+dfsg1/debian/control
--- ecl-15.3.7+dfsg1/debian/control 2016-10-10 17:54:35.0 +0200
+++ ecl-15.3.7+dfsg1/debian/control 2017-09-14 14:32:34.0 +0200
@@ -25,7 +25,7 @@
Package: ecl
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libgmp3-dev, libncurses5-dev, libgc-dev, libatomic-ops-dev, gcc
+Depends: ${shlibs:Depends}, ${misc:Depends}, libffi-dev, libgmp3-dev, libncurses5-dev, libgc-dev, libatomic-ops-dev, gcc
Provides: lisp-compiler
Suggests: slime, ecl-doc
Description: Embeddable Common-Lisp: has an interpreter and can compile to C
signature.asc
Description: PGP signature
Bug#875565: RM: clapack/3.2.1+dfsg-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Dear Release Team, Please remove src:clapack from stretch. As explained in [1], its codebase is outdated and unmaintained, and duplicates that of src:lapack (more precisely, src:clapack is an automated translation from Fortran to C of an 8-year old version of src:lapack). A remove request from unstable has also been filed as #875564. Cheers, [1] https://lists.debian.org/debian-science/2017/09/msg00038.html -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#875548: nmu: clisp_1:2.49.60+-2 mlpcap_0.9-17
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Dear Release Team, A mini-transition is underway following the SOVERSION bump of ffcall (see [1]). Please schedule binNMUs for the two affected packages: nmu clisp_1:2.49.60+-2 . ANY . unstable . -m "rebuild against libffcall1a" nmu mlpcap_0.9-17 . ANY . unstable . -m "rebuild against libffcall1a" Best, [1] https://release.debian.org/transitions/html/auto-ffcall.html -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#868558: nmu: multiple r-* packages
On Sat, Sep 09, 2017 at 09:39:37AM -0500, Dirk Eddelbuettel wrote: > > On 9 September 2017 at 16:18, Sébastien Villemot wrote: > | But since I do not want to waste my time, I first need to be sure that you > would > | accept such a patch. > > Re-read > > http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html > > and construct (using R and my RcppAPT packages) the set of packages that > > - are reverse depends of r-base-core in Debian (just over 500+ iirc) > - have a src/ directory, ie are Archicture: any > - have .C or .Fortran calls below R/ > - use dynamic symbol registration > - but ignore whether they have been rebuilt > > so it would differ from my analysis. I reckon that you would end up with > maybe 100 to 150 (a guess) packages for which you would need a Breaks: > declaration. Thanks for the pointers and for the explanation. Indeed the list will be quite long, keeping in mind that some packages may appear several times with architecture qualifiers if version numbers differ across architectures (due for example to different binNMU version suffixes). > Now I, as maintainer of r-base, feel that I would not serve my users with the > added fragility of 100+ breaks statements. > > But you are of course free to create a locally patched package for local > tests and users. We know how quickly a local apt repo can be created. As > having this functionality seems rather important to you (while I remain more > than sceptical) I suggest you work on that in such a local package. Well, I am interested in having this fixed in Debian, not in a local package or repository. So I understand from your message that I cannot help. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#868558: nmu: multiple r-* packages
On Sat, Sep 09, 2017 at 08:53:49AM -0500, Dirk Eddelbuettel wrote: > On 9 September 2017 at 14:12, Sébastien Villemot wrote: > | On Sat, Sep 09, 2017 at 06:48:12AM -0500, Dirk Eddelbuettel wrote: > | > > | > On 9 September 2017 at 06:44, Niels Thykier wrote: > | > | Thanks to Sébastien and Andreas for explaining the issue. > | > > | > Well, was it "explained" ? They both raised and stressed a hypothetical > | > issue: That "there might be siutations where a partial upgrade breaks" > | > > | > We don't actually know whether this holds. This R 3.4.* change was not a > | > full-fledged ABI change. > | > | I made the following experiment: > | > | - started from a minimal stretch chroot > | - installed r-base and r-cran-spatial > | - upgraded r-base to the version from sid (but not r-cran-spatial) > > Come one. That's the situation of EVERY known bug in testing fixed in > unstable. No it’s not the same. In the present case, (partially-)upgrading to unstable *introduces* a bug. > I am done. This way too dogmatic for my taste. I feel sorry about the users > who will not get access to current, updated and bug free version of R because > of this. A wrong decision. I don’t want to argue about the soundness of this technical requirement. I am just interested in having this issue sorted out, since I am a R user and package maintainer. As already stated in <20170906144810.f663j3gykjcxo...@villemot.name>, I am willing to help by generating the correct list of Breaks that, if incorporated in the debian/control of r-base, would solve the issue. But since I do not want to waste my time, I first need to be sure that you would accept such a patch. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#868558: nmu: multiple r-* packages
On Sat, Sep 09, 2017 at 06:48:12AM -0500, Dirk Eddelbuettel wrote: > > On 9 September 2017 at 06:44, Niels Thykier wrote: > | Thanks to Sébastien and Andreas for explaining the issue. > > Well, was it "explained" ? They both raised and stressed a hypothetical > issue: That "there might be siutations where a partial upgrade breaks" > > We don't actually know whether this holds. This R 3.4.* change was not a > full-fledged ABI change. I made the following experiment: - started from a minimal stretch chroot - installed r-base and r-cran-spatial - upgraded r-base to the version from sid (but not r-cran-spatial) - ran the example described in #861333: $ R -e "library(spatial); example(surf.gls)" then I get a crash with the error message "object 'VR_frset' not found". So this confirms that partial upgrades are indeed broken. Best, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#868558: nmu: multiple r-* packages
Hi Dirk and others, On Fri, Sep 08, 2017 at 12:29:25PM -0500, Dirk Eddelbuettel wrote: > | The problem is that you can end up with r-bioc-makecdfenv_1.50.0-1 (i.e. > before > | the rebuild) and r-base_3.4.1-2, because nothing prevents that combination. > > You may misunderstand. Only packages that > > - have compiled code (ie arch: any, and a src/ directory) > - use .C() and .Fortran() > - actually use the up until recently optional registration > - have been built with R (<< 3.4.0) The point made by the Release Team is that packages that fulfill these 4 criterias may still be installed on system where R has been upgraded to 3.4. Such a bad combination can happen if a user does a partial upgrade from stretch to (upcoming) buster, by upgrading R core but not the CRAN packages fulfilling the 4 criterias. In that case the user ends up with a broken system (in the sense that those non-upgraded CRAN packages are not functional). I understand that this situation is not going to happen very often, but it may happen, and the Release Team wants to prevent this by introducing a Breaks relationship. Of course, please correct me if I am wrong. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#872818: stretch-pu: package cvxopt/1.1.4-1.5+deb9u1
On Wed, Aug 23, 2017 at 03:35:12PM +0200, Sébastien Villemot wrote: > On Tue, Aug 22, 2017 at 09:19:51PM +0100, Adam D. Barratt wrote: > > > On Mon, 2017-08-21 at 17:07 +0200, Sébastien Villemot wrote: > > > I would like to do a p-u for cvxopt, fixing bug #859579. > > > > > > By the time of the stretch release, cvxopt was not compatible with the > > > new API > > > of the GLPK library, so a compatibility layer had been introduced through > > > glpk-4.49.diff. But that patch had too much in it, it contained an > > > unneeded > > > compatibility function (lpx_main) that was using a missing symbol > > > (glp_main) > > > (and this missing symbol had not been detected at compile time, because > > > it is > > > in a dynamically-loaded shared object). > > > > Please go ahead. > > Thanks, uploaded. Woops, I realize that the changelog in my upload closes the wrong bug. Is it possible to reject the upload? Sorry for that. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#872818: stretch-pu: package cvxopt/1.1.4-1.5+deb9u1
On Tue, Aug 22, 2017 at 09:19:51PM +0100, Adam D. Barratt wrote: > On Mon, 2017-08-21 at 17:07 +0200, Sébastien Villemot wrote: > > I would like to do a p-u for cvxopt, fixing bug #859579. > > > > By the time of the stretch release, cvxopt was not compatible with the new > > API > > of the GLPK library, so a compatibility layer had been introduced through > > glpk-4.49.diff. But that patch had too much in it, it contained an unneeded > > compatibility function (lpx_main) that was using a missing symbol (glp_main) > > (and this missing symbol had not been detected at compile time, because it > > is > > in a dynamically-loaded shared object). > > Please go ahead. Thanks, uploaded. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄ http://www.debian.org signature.asc Description: PGP signature
Bug#872818: stretch-pu: package cvxopt/1.1.4-1.5+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Dear Release Team,
I would like to do a p-u for cvxopt, fixing bug #859579.
By the time of the stretch release, cvxopt was not compatible with the new API
of the GLPK library, so a compatibility layer had been introduced through
glpk-4.49.diff. But that patch had too much in it, it contained an unneeded
compatibility function (lpx_main) that was using a missing symbol (glp_main)
(and this missing symbol had not been detected at compile time, because it is
in a dynamically-loaded shared object).
The debdiff is attached.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁ Debian Developer
⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name
⠈⠳⣄ http://www.debian.org
diff -Nru cvxopt-1.1.4/debian/changelog cvxopt-1.1.4/debian/changelog
--- cvxopt-1.1.4/debian/changelog 2016-07-16 15:47:05.0 +
+++ cvxopt-1.1.4/debian/changelog 2017-08-21 14:55:52.0 +
@@ -1,3 +1,11 @@
+cvxopt (1.1.4-1.5+deb9u1) stretch; urgency=medium
+
+ * Team upload.
+ * d/p/glpk-4.49.diff: remove the compatibility layer for lpx_main(), it is
+not needed and uses a missing symbol. (Closes: #859579)
+
+ -- Sébastien Villemot Mon, 21 Aug 2017 16:55:52 +0200
+
cvxopt (1.1.4-1.5) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru cvxopt-1.1.4/debian/patches/glpk-4.49.diff cvxopt-1.1.4/debian/patches/glpk-4.49.diff
--- cvxopt-1.1.4/debian/patches/glpk-4.49.diff 2016-07-16 14:39:41.0 +
+++ cvxopt-1.1.4/debian/patches/glpk-4.49.diff 2017-08-21 14:54:50.0 +
@@ -26,7 +26,7 @@
===
--- /dev/null
+++ cvxopt-1.1.4/src/C/lpx.c
-@@ -0,0 +1,1516 @@
+@@ -0,0 +1,1511 @@
+/* lpx.c (old GLPK API) */
+
+/* Written by Andrew Makhorin , August 2013. */
@@ -1534,11 +1534,6 @@
+ return glp_bf_exists(lp);
+}
+
-+int lpx_main(int argc, const char *argv[])
-+{ /* stand-alone LP/MIP solver */
-+ return glp_main(argc, argv);
-+}
-+
+#endif
+
+/* eof */
@@ -1547,7 +1542,7 @@
===
--- /dev/null
+++ cvxopt-1.1.4/src/C/lpx.h
-@@ -0,0 +1,568 @@
+@@ -0,0 +1,565 @@
+/* lpx.h (old GLPK API) */
+
+/* Written by Andrew Makhorin , August 2013. */
@@ -2105,9 +2100,6 @@
+int lpx_is_b_avail(LPX *lp);
+/* check if LP basis is available */
+
-+int lpx_main(int argc, const char *argv[]);
-+/* stand-alone LP/MIP solver */
-+
+#ifdef __cplusplus
+}
+#endif
signature.asc
Description: PGP signature
Bug#866390: transition: octave 4.2
Le vendredi 30 juin 2017 à 12:26 +0200, Emilio Pozuelo Monfort a écrit : > On 30/06/17 12:03, Sébastien Villemot wrote: > > Le jeudi 29 juin 2017 à 19:41 +0200, Emilio Pozuelo Monfort a écrit : > > > On 29/06/17 14:10, Sébastien Villemot wrote: > > > > Package: release.debian.org > > > > Severity: normal > > > > User: release.debian@packages.debian.org > > > > Usertags: transition > > > > X-Debbugs-CC: pkg-octave-de...@lists.alioth.debian.org > > > > Control: forwarded -1 > > > > https://release.debian.org/transitions/html/auto-octave.html > > > > > > > > Dear Release Team, > > > > > > > > Please schedule a transition for octave 4.2. The new package is already > > > > in > > > > experimental. > > > > > > > > Few reverse dependencies will need sourceful NMUs. In any case, we > > > > stand ready to NMU. > > > > > > So how many rdeps (and which ones) fail to build atm? > > > > Sorry for not having been more specific. > > > > Of the 43 rdeps affected by the transition: > > > > - We tested the 10 that are not maintained by the Debian Octave Group. > > They all rebuild correctly. > > > > - We did not test the other 33 that are maintained by us. But they > > should be working fine with Octave 4.2 (according to upstream). And in > > the unlikely case of a build failure and no available patch, we can > > request temporary removals from testing, since these are leaf packages. > > If you think this is necessary before starting the transition, we can > > test them, even though we feel this is unnecessary work. > > No need to. You can go ahead. Thanks. Octave 4.2 is now uploaded and built on all release archs. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://sebastien.villemot.name `- GPG Key: 4096R/381A7594 signature.asc Description: This is a digitally signed message part
Bug#866390: transition: octave 4.2
Le jeudi 29 juin 2017 à 19:41 +0200, Emilio Pozuelo Monfort a écrit : > On 29/06/17 14:10, Sébastien Villemot wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > X-Debbugs-CC: pkg-octave-de...@lists.alioth.debian.org > > Control: forwarded -1 > > https://release.debian.org/transitions/html/auto-octave.html > > > > Dear Release Team, > > > > Please schedule a transition for octave 4.2. The new package is already in > > experimental. > > > > Few reverse dependencies will need sourceful NMUs. In any case, we stand > > ready to NMU. > > So how many rdeps (and which ones) fail to build atm? Sorry for not having been more specific. Of the 43 rdeps affected by the transition: - We tested the 10 that are not maintained by the Debian Octave Group. They all rebuild correctly. - We did not test the other 33 that are maintained by us. But they should be working fine with Octave 4.2 (according to upstream). And in the unlikely case of a build failure and no available patch, we can request temporary removals from testing, since these are leaf packages. If you think this is necessary before starting the transition, we can test them, even though we feel this is unnecessary work. Best, -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://sebastien.villemot.name `- GPG Key: 4096R/381A7594
Bug#866390: transition: octave 4.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-CC: pkg-octave-de...@lists.alioth.debian.org Control: forwarded -1 https://release.debian.org/transitions/html/auto-octave.html Dear Release Team, Please schedule a transition for octave 4.2. The new package is already in experimental. Few reverse dependencies will need sourceful NMUs. In any case, we stand ready to NMU. Thanks! -- .''`. Sébastien Villemot : :' :Debian Developer `. `' http://sebastien.villemot.name `- GPG Key: 4096R/381A7594 signature.asc Description: PGP signature
Bug#865695: stretch-pu: package octave-ocs/0.1.5-2+deb9u1
Le dimanche 25 juin 2017 à 22:51 +0200, Cyril Brulebois a écrit : > Sébastien Villemot (2017-06-23): > > I would like to update octave-ocs in stretch, in order to fix #865282. > > > > The problem comes from a patch that needs to be manually updated with each > > new > > upstream version (I know this is bad, shame on us), and it was not updated > > last > > time. > > > > The changelog is as follows: > > > > octave-ocs (0.1.5-2+deb9u1) stretch; urgency=medium > > > > * d/p/set_nonarch_path_for_pkg_add: refresh for this upstream version. > > Fixes loading of package functions into Octave path. (Closes: #865282) > > > > > > -- Sébastien Villemot Wed, 21 Jun 2017 > > > > 16:57:26 +0200 > > > > Full debdiff is attached. > > Looks good to me, feel free to upload. Thanks, uploaded. -- .''`.Sébastien Villemot : :' :Debian Developer `. `' http://sebastien.villemot.name `- GPG Key: 4096R/381A7594
