Bug#1056204: marked as done (nmu: texlive-bin_2023.20230311.66589-7)
Your message dated Thu, 23 Nov 2023 17:04:49 +0100
with message-id <9c7c4cdd-437b-4ec7-9c86-8440a900b...@web.de>
and subject line Re: Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7
has caused the Debian Bug report #1056204,
regarding nmu: texlive-bin_2023.20230311.66589-7
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1056204: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056204
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: texlive-...@packages.debian.org
Control: affects -1 + src:texlive-bin
nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild against
new zlib"
Hello,
Since the upload of zlib1g 1:1.3.dfsg-1, installing texlive-binaries
texlive-base fails:
fmtutil failed. Output has been stored in
/tmp/fmtutil.ndDMEWN5
[...]
fmtutil: running `luatex -ini -jobname=luatex -progname=luatex luatex.ini' ...
PANIC: unprotected error in call to Lua API (zlib library version does not
match - header: 1.2.13, library: 1.3)
Aborted
And indeed texlive-bin checks the zlib version:
https://codesearch.debian.net/search?q=zlib+library+version+does+not+match=en
texlive-bin_2023.20230311.66589-7/texk/web2c/luatexdir/luazlib/lzlib.c
if (strncmp(version, ZLIB_VERSION, 4))
{
lua_pushfstring(L, "zlib library version does not match - header: %s,
library: %s", ZLIB_VERSION, version);
lua_error(L);
}
So a binnmu of the texlive-bin source package seems needed on all archs
to fix installing texlive-binaries.
Samuel
--- End Message ---
--- Begin Message ---
On 18.11.2023 20:18, Samuel Thibault wrote:
nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild against new
zlib"
Hello,
Since the upload of zlib1g 1:1.3.dfsg-1, installing texlive-binaries
texlive-base fails:
fmtutil failed. Output has been stored in
/tmp/fmtutil.ndDMEWN5
The issue has been solved, in Bug#1056586 we'll discuss better / more
sustainable solutions. Closing this request here.
Hilmar
--
sigfault
OpenPGP_signature.asc
Description: OpenPGP digital signature
--- End Message ---
Re: FTBFS: tests fail in clean environment
On Thu, Nov 23, 2023 at 09:20:37AM -0500, Nicolas Mora wrote: >Hello, > >On Tue, 21 Nov 2023 13:30:31 + Steve McIntyre wrote: >> Source: libssh2 >> Version: 1.9.0-2 >> Severity: serious >> Tags: ftbfs patch >> >> Hi! >> >> Building libssh2 using debuild in a clean local chroot, I get test >> failures and even a core dump! >> >Thanks for reporting the bug, although I have concerns on its scope. > >The package you have found the issue is the bullseye one, and the package >updates for oldstable are allowed mostly for security patches. > >Your bug is related to the test suite, and the patch won't change the binary >files in the package, so I assume the patch isn't going to be allowed for >proposed-updates. > >I've added the release team to ask for their opinion. > >Friends from the release team, do you have a feedback on this? Ah, apologies - that version is bogus, it's just the version on the bullseye machine I ran reportbug from. The tests are failing on current unstable source. -- Steve McIntyre, Cambridge, UK.st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me
Re: FTBFS: tests fail in clean environment
Hello, On Tue, 21 Nov 2023 13:30:31 + Steve McIntyre wrote: Source: libssh2 Version: 1.9.0-2 Severity: serious Tags: ftbfs patch Hi! Building libssh2 using debuild in a clean local chroot, I get test failures and even a core dump! Thanks for reporting the bug, although I have concerns on its scope. The package you have found the issue is the bullseye one, and the package updates for oldstable are allowed mostly for security patches. Your bug is related to the test suite, and the patch won't change the binary files in the package, so I assume the patch isn't going to be allowed for proposed-updates. I've added the release team to ask for their opinion. Friends from the release team, do you have a feedback on this? /Nicolas
Bug#1056585: RM: hinawa-utils/0.3.0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: ken...@xdump.org Here is the some reasons to remove hinawa-utils from testing: * The hinawa-utils depends on libhinawa (2.x), and the newer release of libhinawa (4.x) drops obsolete features. hinawa-utils depends on the obsolete (removed) features. Thus hinawa-utils is useless without it. * The newer release of libhinawa (4.x) should be in next stable release, but because of breaking dependency, it blocks migration of libhinawa (4.x) from unstable. * The upstream author develops such a obsolete feature into separate library - libhitaki, but it is not packaged yet in debian. * hinawa-utils is under maintenance mode, so I have no idea when it supports libhitaki yet. So, I decided to remove it and it should not be part of next stable release (for now) In the future, if libhitaki was packaged in debian and hinawa-utils supports it, then salvage hinawa-utils package which supports libhitaki again. Related bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056354
Re: OpenSSL transition to testing
Le jeu. 23 nov. 2023 à 14:17, Sebastian Andrzej Siewior < sebast...@breakpoint.cc> a écrit : > On 2023-11-22 22:15:43 [+0100], Jérémy Lal wrote: > > Plase wait a moment before doing more uploads. > > I am gonna deal with it before the end the week. Sorry for that. > > Sorry for any trouble I may have caused. I haven't had any response and > I wasn't granted any free rider card so I started backporting on SAT > evening. And to not make it look selfish I looked at the CVEs, too. This > and testing took a while. > I just (wrongly) assumed the other testsuite failures is just my local > setup problem… > Don't worry, I'm the one lagging behind. I've started work on latest 18.x update, and will check those. Jérémy
Re: OpenSSL transition to testing
On 2023-11-22 22:15:43 [+0100], Jérémy Lal wrote: > Plase wait a moment before doing more uploads. > I am gonna deal with it before the end the week. Sorry for that. Sorry for any trouble I may have caused. I haven't had any response and I wasn't granted any free rider card so I started backporting on SAT evening. And to not make it look selfish I looked at the CVEs, too. This and testing took a while. I just (wrongly) assumed the other testsuite failures is just my local setup problem… > Jérémy Sebastian
Re: OpenMPI / MPI transition
On 23/11/2023 12:44, Drew Parsons wrote: On 2023-11-23 12:13, Emilio Pozuelo Monfort wrote: Hi, On 23/11/2023 09:36, Alastair McKinstry wrote: Hi, OpenMPI has a new upstream release 5.0.0. It is in experimental now; the SOVERSION for libraries remains 40.X (minor version increment), there is an SOVERSION increment for private libraries only so in theory this is not an ABI transition. However 5.0.0 drops 32-bit system support. The default MPI implementation for each architecture is set in mpi-defaults; this allows a per-arch MPI choice; in practice we currently use OpenMPI for all archs. The other choice is MPICH. So the question becomes: do we switch MPI for just 32-bit archs, or all? What are the release teams opinion on this transition? Having the same implementation across the board makes things easier for testing purposes et al, however I don't see that as a blocker for not having separate implementations. True, in one sense it's simpler to have the same default MPI. But we've set up our package infrastructure so that in principle it should not matter. One architecture does not (or should not) depend on another, so it shouldn't break packages just because we'd have different MPI implementations on different architectures. On the contrary, "actively" using both implementations could lead to more robust packages overall as MPI bugs get fixed against both implementations. What are your thoughts on it? Is there a strong reason why we should stick with OpenMPI for 64bit releases? Or from a different POV, what are the risks of changing the implementation? Introducing a different set of bugs? One point to consider is that upstream developers of several of our numerical libraries have time and again suggested to us that we use mpich instead of openmpi, even before this v5 shift. They perceive (rightly or wrongly) that mpich is more robust, more reliable. It would be useful to know whether that changes with v5, or whether their complaints are historical and openmpi has already fixed the bugs that concerned them. mpich has had its own share of bugs over the years. My memory told me RMA support was an issue in openmpi, but when I checked my facts, it was mpich that had to be fixed (https://github.com/pmodels/mpich/issues/6110) Drew My understanding is that MPICH has been typically the reference implementation, higher quality but less performant, particularly with the range of fabrics. Certainly I've seen mostly OpenMPI but not MPICH on various HPC machines. People would use either OpenMPI or a vendors MPI (which may be forked MPICH with added network hardware support). I'd really like to hear from upstream users whether they are still encountering OpenMPI issues. Personally I favour splitting, using MPICH on 32-bit archs to flush out bugs, and doing so early in the dev cycle (now) so there is time to change if necessary. Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Re: OpenMPI / MPI transition
On 2023-11-23 12:13, Emilio Pozuelo Monfort wrote: Hi, On 23/11/2023 09:36, Alastair McKinstry wrote: Hi, OpenMPI has a new upstream release 5.0.0. It is in experimental now; the SOVERSION for libraries remains 40.X (minor version increment), there is an SOVERSION increment for private libraries only so in theory this is not an ABI transition. However 5.0.0 drops 32-bit system support. The default MPI implementation for each architecture is set in mpi-defaults; this allows a per-arch MPI choice; in practice we currently use OpenMPI for all archs. The other choice is MPICH. So the question becomes: do we switch MPI for just 32-bit archs, or all? What are the release teams opinion on this transition? Having the same implementation across the board makes things easier for testing purposes et al, however I don't see that as a blocker for not having separate implementations. True, in one sense it's simpler to have the same default MPI. But we've set up our package infrastructure so that in principle it should not matter. One architecture does not (or should not) depend on another, so it shouldn't break packages just because we'd have different MPI implementations on different architectures. On the contrary, "actively" using both implementations could lead to more robust packages overall as MPI bugs get fixed against both implementations. What are your thoughts on it? Is there a strong reason why we should stick with OpenMPI for 64bit releases? Or from a different POV, what are the risks of changing the implementation? Introducing a different set of bugs? One point to consider is that upstream developers of several of our numerical libraries have time and again suggested to us that we use mpich instead of openmpi, even before this v5 shift. They perceive (rightly or wrongly) that mpich is more robust, more reliable. It would be useful to know whether that changes with v5, or whether their complaints are historical and openmpi has already fixed the bugs that concerned them. mpich has had its own share of bugs over the years. My memory told me RMA support was an issue in openmpi, but when I checked my facts, it was mpich that had to be fixed (https://github.com/pmodels/mpich/issues/6110) Drew
Re: OpenMPI / MPI transition
Hi, On 23/11/2023 09:36, Alastair McKinstry wrote: Hi, OpenMPI has a new upstream release 5.0.0. It is in experimental now; the SOVERSION for libraries remains 40.X (minor version increment), there is an SOVERSION increment for private libraries only so in theory this is not an ABI transition. However 5.0.0 drops 32-bit system support. The default MPI implementation for each architecture is set in mpi-defaults; this allows a per-arch MPI choice; in practice we currently use OpenMPI for all archs. The other choice is MPICH. So the question becomes: do we switch MPI for just 32-bit archs, or all? What are the release teams opinion on this transition? Having the same implementation across the board makes things easier for testing purposes et al, however I don't see that as a blocker for not having separate implementations. What are your thoughts on it? Is there a strong reason why we should stick with OpenMPI for 64bit releases? Or from a different POV, what are the risks of changing the implementation? Introducing a different set of bugs? For release architectures, the 32bit ones would be armel, armhf and i386. Cheers, Emilio
Processed: transition: ppp
Processing control commands: > affects -1 + src:ppp Bug #1056574 [release.debian.org] transition: ppp Added indication that 1056574 affects src:ppp -- 1056574: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056574 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1056574: transition: ppp
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: p...@packages.debian.org Control: affects -1 + src:ppp Hello Release Team friends, I uploaded ppp-2.5.0-1+1 to experimental back in September, and I think it's time to unleash it on unstable, ideally in the next few days. This is an ABI break both due to the new upstream version but there are also significant changes in this release that may break dependent packages. The upload I'm planning, 2.5.0-1+2, only has a minor fix for loong64 and a changelog fix. As usual this isn't a traditional library package upload so the Ben file looks a bit foreign. See #890204 for a previous time we did this. Thanks, Chris Ben file: title = "ppp"; is_affected = .build-depends ~ /ppp-dev/; is_good = .depends ~ /ppp \(>= 2\.5\.0-1\+~\)/ | .breaks ~ /ppp \(<< 2\.5\.0-1\+~\)/; is_bad = .depends ~ /ppp \(>= 2\.4\.9-1\+~\)/ | .breaks ~ /ppp \(<< 2\.4\.9-1\+~\)/;
OpenMPI / MPI transition
Hi, OpenMPI has a new upstream release 5.0.0. It is in experimental now; the SOVERSION for libraries remains 40.X (minor version increment), there is an SOVERSION increment for private libraries only so in theory this is not an ABI transition. However 5.0.0 drops 32-bit system support. The default MPI implementation for each architecture is set in mpi-defaults; this allows a per-arch MPI choice; in practice we currently use OpenMPI for all archs. The other choice is MPICH. So the question becomes: do we switch MPI for just 32-bit archs, or all? What are the release teams opinion on this transition? regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1055857: transition: opm-common
Control: tags -1 moreinfo On 2023-11-12 21:42:20 +0100, Markus Blatt wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > X-Debbugs-Cc: debian-scie...@lists.debian.org > > Dear Debian release team, > > A new upstream release of OPM is available. To ease migration to testing I am > requesting a mini-transition. Uploading to unstable would probably work even > without a transition, but I would like to play it safe. > > This should only affect the OPM source packages opm-common, opm-grid, opm- > models, opm-simulators and opm-upscaling. > > I have already uploaded new versions to experimental that seemed to have built > without any issues, see [1]. > (please explain about the transition: impacted packages, reason, ... > for more info see: https://wiki.debian.org/Teams/ReleaseTeam/Transitions) > > Ben file: > > title = "libopm-common-2023"; > is_affected = .depends ~ "libopm-common-2023.04" | .depends ~ "libopm- > common-2023.10"; > is_good = .depends ~ "libopm-common-2023.10"; > is_bad = .depends ~ "libopm-common-2023.04"; libopm-common has a Provides: libopm-common-X, but the shared library included in libopm-common also has a SONAME of libopm-common.X. Why is the packaging not following the common practice of matching the package name with the SONAME? Cheers -- Sebastian Ramacher
Processed: Re: Bug#1055857: transition: opm-common
Processing control commands: > tags -1 moreinfo Bug #1055857 [release.debian.org] transition: opm-common Added tag(s) moreinfo. -- 1055857: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055857 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1056308: transition: wireshark
Processing control commands: > tags -1 confirmed Bug #1056308 [release.debian.org] transition: wireshark Added tag(s) confirmed. -- 1056308: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056308 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1055699: marked as done (transition: spglib)
Your message dated Thu, 23 Nov 2023 09:21:11 +0100 with message-id and subject line Re: Bug#1055699: transition: spglib has caused the Debian Bug report #1055699, regarding transition: spglib to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1055699: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055699 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, I would like to request a transition slot for spglib (experimental -> unstable) due to soname bump. Current ben tracker [1] is OK. Rebuild results for reverse dependencies: * avogadrolibs: OK * c2x: OK * cod-tools: needs a trivial patch, I will upload it * cp2k: OK * gabedit: OK Thanks, Andrius [1] https://release.debian.org/transitions/html/auto-spglib.html --- End Message --- --- Begin Message --- On 2023-11-10 22:33:53 +0100, Sebastian Ramacher wrote: > Control: tags -1 confimred > > On 2023-11-10 10:42:38 +0200, Andrius Merkys wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: transition > > > > Hello, > > > > I would like to request a transition slot for spglib > > (experimental -> unstable) due to soname bump. Current ben tracker [1] > > is OK. > > Please go ahead. The old binaries got removed from testing. Cheers -- Sebastian Ramacher--- End Message ---
Bug#1056308: transition: wireshark
Control: tags -1 confirmed On 2023-11-20 11:37:49 +0100, Bálint Réczey wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: transition > > Dear Release Team, > > I'd like to update wireshark in unstable. The only reverse dependency to be > rebuilt is libvirt [1]. Please go ahead. Cheers > > Libvirt fails to rebuild for me locally on an Ubuntu system in an unstable > schroot environment with and without wireshark with the same test error: > > ... > --- stderr > --- > TEST: virnetsockettest > Cannot identify IPv4/6 availability > ... > Summary of Failures: > > 124/173 libvirt:bin / virnetsockettestFAIL > 0.05s exit status 1 > > Ok: 171 > Expected Fail: 0 > Fail: 1 > Unexpected Pass:0 > Skipped:1 > Timeout:0 > ... > > I believe libvirt will build fine with the updated wireshark package on the > buildds. > > Thank you, > Balint > > [1] https://release.debian.org/transitions/html/auto-wireshark.html -- Sebastian Ramacher
