Bug#1067813: nmu: spatialite_5.1.0-3
Package: release.debian.org Severity: normal X-Debbugs-Cc: spatial...@packages.debian.org Control: affects -1 + src:spatialite User: release.debian@packages.debian.org Usertags: binnmu nmu spatialite_5.1.0-3 . armel armhf . unstable . -m "Rebuild with libminizip1t64" https://packages.debian.org/sid/libspatialite8t64
Processed: nmu: spatialite_5.1.0-3
Processing control commands: > affects -1 + src:spatialite Bug #1067813 [release.debian.org] nmu: spatialite_5.1.0-3 Added indication that 1067813 affects src:spatialite -- 1067813: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067813 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: nmu: spatialite_5.1.0-3
Processing control commands: > affects -1 + src:spatialite Bug #1067812 [release.debian.org] nmu: spatialite_5.1.0-3 Added indication that 1067812 affects src:spatialite -- 1067812: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067812 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1067812: nmu: spatialite_5.1.0-3
Package: release.debian.org Severity: normal X-Debbugs-Cc: spatial...@packages.debian.org Control: affects -1 + src:spatialite User: release.debian@packages.debian.org Usertags: binnmu nmu spatialite_5.1.0-3 . armel armhf . unstable . -m "Rebuild against libminizip1t64" To unblock the spatialite rdeps it needs to build with libminzip-dev (>= 1:1.3.dfsg-3.1) on armel & armhf.
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Wed, 27 Mar 2024, Wookey wrote: >I looked at this last week, but got stuck because openjdk-17's >build-deps included graphviz Build-Depends-Indep: graphviz, pandoc You don’t need that. Use dpkg-checkbuilddeps -B, or manual inspection of the .dsc (packages.d.o does show the difference between adep and idep but not the profiles, unfortunately, and these can be key in ordering decisions). >another blocked chain with ghostscript,cups and libgtk2 conflicting >about their t64 status. You do need the t64 versions of all that, and the latest openjdk-17 fixed the issue with libcups2 (Ubuntu initially forgot to move that to t64 while Debian did that early, and openjdk-?? followed the former). > apt : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed You should get that rebuilt, yes. On the other hand, if everything else is falling into place, it’s not a problem for apt to uninstall itself just in that one build chroot ☻ > libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be > installed > libcups2t64 : Breaks: libcups2 (< 2.4.7-1.2) but 2.4.7-1+b1 is to be installed > libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2 is to be > installed These are fine. > libcups2 : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed Force that away; nothing from this is actually used during the openjdk build in a way sufficient to impact the build. >But dose now says there is a solution, unlike last week. Oh, dose… right… here I was checking all of them manually ^^ (which did give me a better impression of where to break the cycles and what to upload earlier). >> openjdk-21 is in a similar situation, build-depending on itself, while >> openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively. >I presume the same, but don't actually know how old a java you can use >to bootstrap each newer java. Is it always just one version? AIUI it’s always just one version; I know it was so until 17, but I don’t think this has loosened (I asked in IRC, but got no answer until I went to sleep). >> Presumably once we have a single OpenJDK version that is installable, >> it would be possible to step through 18,19,20,21 building each version >> with the previous one. You’d have to patch them to both address the t64 issues and make it imply nocheck (or quinn-diff doesn’t pick it up as installable). It’s best to get at least 17 and 21 (which AIUI is the one we’ll want for trixie?) built this way. I think, unless users complain, we can these days go without 8 and probably even without 11. (You’d be surprised at the amount of users wanting 8, so I now provide those in a private repo of mine, but so far amd64/i386-only has sufficed for those. For the purposes for which 8 is still in sid, dropping armel and armhf will _most likely_ also suffice; ELTS still wants them, but rebuilt in jessie and stretch chroots so there is no re‐ bootstrapping to be done.)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On 2024-03-26 10:35 +, Simon McVittie wrote: > It seems that some of the dependency chains for packages that are still > waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the > default Java version for most architectures and Build-Depends on itself > (with an alternative dependency on openjdk-16, but that no longer exists). > evolution-data-server -> libphonenumber-dev is an example. > > Are the ARM or Java teams intending to re-bootstrap openjdk-17 somehow? I looked at this last week, but got stuck because openjdk-17's build-deps included graphviz which was also uninstallable and led to another blocked chain with ghostscript,cups and libgtk2 conflicting about their t64 status. Checking again now, apt still complains: The following packages have unmet dependencies: apt : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed libasound2t64 : Breaks: libasound2 (< 1.2.11-1) but 1.2.10-3 is to be installed libcups2 : Depends: libgnutls30 (>= 3.8.1) but it is not going to be installed libcups2t64 : Breaks: libcups2 (< 2.4.7-1.2) but 2.4.7-1+b1 is to be installed libnettle8t64 : Breaks: libnettle8 (< 3.9.1-2.2) but 3.9.1-2 is to be installed But dose now says there is a solution, unlike last week. So it should be possible to get the dependencies in place (without unreasonable jiggery-pokery) and bootstrap it. I'll have another go tomorrow. > Or do maintainers of packages that build both a C/C++ library and Java > bindings from a single source package need to disable its Java bindings > on the affected architectures, either temporarily or permanently? Some of that might still be expedient, but hopefully we can get a t64 java soon and it won't be necessary. We have to do that sooner or later anyway. > openjdk-21 is in a similar situation, build-depending on itself, while > openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively. > Presumably once we have a single OpenJDK version that is installable, > it would be possible to step through 18,19,20,21 building each version > with the previous one. I presume the same, but don't actually know how old a java you can use to bootstrap each newer java. Is it always just one version? Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Tue, 26 Mar 2024, Jeffrey Walton wrote: >Nothing beats a native compile in your basement. Yes, definitely. >> Do they run stock Debian armhf? > >So the CubieTruck is embarrassingly down level: Oofff… >The Wandboard is doing better: Right, close enough anyway. >I don't mind shipping to Europe if you don't mind paying the VAT. I >think you will be the fourth or fifth Debian maintainer I've sent >hardware to. So sending from outside the eurozone, that can get tricky fast (depending on the value, they also want import duties on top), I think that might just be overkill for a oneshot helping out. Let’s see if I can get an account on a project box first, or work with someone who has. (I’m not intending to add going into ARM development on top of what I already try to balance… right now, I’m mostly helping m68k through t64, so Adrian does not burn out, he’s also got sh4 and powerpc to do, and the whole rest of d-ports with the mini-dak trouble of keeping old binary packages around.) But I do thank you for that offer. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Tue, Mar 26, 2024 at 7:44 PM Thorsten Glaser wrote: > > I’m answering back from the $dayjob address because Googlemail > cannot communicate with normal mailservers. > > >I can send you two dev boards, if you want them. The first is > >Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is > >CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4). Both work, but I > >don't use them much anymore. I've mostly moved on to Aarch64. > > That is certainly an option, if you don’t want them any more and want > to ship them to .de, although it’ll likely take longer than just getting > access on a suitable project machine. RAM is tight on them, but with > swap the compiling should work. Both seem to have serial console, good. Nothing beats a native compile in your basement. It sure beats the snot out of a cross-compile, or an emulator like a Debian QEMU/Chroot. I switched to the dev boards after getting frustrated with cross-compiles. (So many makefiles are poorly written, and can't handle a simple cross-compile). And I run a first class swap file on all of my dev boards. SDcards are easy to replace. A SDcard lasts 6 to 9 months before you start seeing unexplained file system errors. That's around the time you know it's time to replace the SDcard. > Do they run stock Debian armhf? So the CubieTruck is embarrassingly down level: cubietruck:~$ lsb_release -a Distributor ID: Linaro Description:Linaro 14.04 Release:14.04 Codename: trusty The Wandboard is doing better: wandboard:~$ lsb_release -a Distributor ID: Debian Description:Debian GNU/Linux 11 (bullseye) Release:11 Codename: bullseye I don't mind shipping to Europe if you don't mind paying the VAT. I think you will be the fourth or fifth Debian maintainer I've sent hardware to. Jeff
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
Hi Jeffrey, I’m answering back from the $dayjob address because Googlemail cannot communicate with normal mailservers. >I can send you two dev boards, if you want them. The first is >Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is >CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4). Both work, but I >don't use them much anymore. I've mostly moved on to Aarch64. That is certainly an option, if you don’t want them any more and want to ship them to .de, although it’ll likely take longer than just getting access on a suitable project machine. RAM is tight on them, but with swap the compiling should work. Both seem to have serial console, good. Do they run stock Debian armhf? Thanks, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
On Tue, Mar 26, 2024 at 6:30 PM Thorsten Glaser wrote: > > [...] > > The options for the armel/armhf porters are to either get the > .debs from me, install them in a chroot, and then the other B-D, > and rebuild the packages, or to use dpkg --force-depends to > install the dependencies (which makes it hard to use apt to > install the other ones unless you also edit /var/lib/dpkg/status > by hand first, something I was already used to from my reviving > m68k back in 2012–2015) into the chroot then rebuild there. > > I will gladly help if it’s made possible for me to help. This > cannot be done on a porterbox because it’s still impossible to > either install arbitrary .debs into a chroot there or to obtain > root in the chroot to be able to force installation in the absence > of some Depends. > > So if you have a fast armhf box or two, ideally with chroots > already made for sid, which you don’t mind temporarily giving > me root on, I’m in, otherwise I’ll answer questions from these > doing that work if needed. I can send you two dev boards, if you want them. The first is Wandboard Dual (Cortex-A9, ARMv7 with NEON), and the second is CubieTruck 5 (Cortex-A7, ARMv7 with NEON and VFPv4). Both work, but I don't use them much anymore. I've mostly moved on to Aarch64. Provide your postal mailing address, if you want them. Jeff
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Hi,
>In the -ports world, hppa doesn't have Java anyway, while m68k, powerpc
>and sh4 seem to have had a re-bootstrap at some point; so I think it's
>only the release architectures armel and armhf that have a problem here.
I hacked that, and I tried to do armel and armhf as well but
dak stopped me, whereas mini-dak was not as strict.
I did the observation that doko changed their source packages
to have the binaries Recommend instead of Depend on the libraries
in question. (Unfortunately neither before the transition started
nor coordinated with the openjdk-8 maintainer (me).)
I downloaded the latest binary packages of openjdk-{8,11,17,21},
changed all references to the libraries in question to refer to
their t64 counterparts, bumped the version number, repacked the
.deb files and updated the .changes files as if to do a binNMU.
After uploading, I used wanna-build to set the priority high so
they get rebuilt before someone considers using them.
mini-dak accepted these, but dak requires that the archive has
the corresponding source available, and since new versions (the
part before the Debian hyphen-minus) had already been uploaded,
it did not have them at hand any more either.
The rebuild process succeeded, as openjdk building itself does
indeed not use the libraries in question (or at least those
parts of their interface that are time_t-relevant).
I don’t have access to a fast armel machine (only an RPi 1) and
to no armhf machine, so I’m not in the situation of throwing the
.debs from above into a chroot to rebuild the current sources.
I *was* considering writing to whereever the t64 transition was
coordinated for ARM, we’re using #debian-ports on OFTC for the
d-ports architectures and I couldn’t find out where to write to
for arm{el,hf}, so this mail of yours comes at a good time ;-)
The options for the armel/armhf porters are to either get the
.debs from me, install them in a chroot, and then the other B-D,
and rebuild the packages, or to use dpkg --force-depends to
install the dependencies (which makes it hard to use apt to
install the other ones unless you also edit /var/lib/dpkg/status
by hand first, something I was already used to from my reviving
m68k back in 2012–2015) into the chroot then rebuild there.
I will gladly help if it’s made possible for me to help. This
cannot be done on a porterbox because it’s still impossible to
either install arbitrary .debs into a chroot there or to obtain
root in the chroot to be able to force installation in the absence
of some Depends.
So if you have a fast armhf box or two, ideally with chroots
already made for sid, which you don’t mind temporarily giving
me root on, I’m in, otherwise I’ll answer questions from these
doing that work if needed.
I *think* 8/11/17/21 are the only versions we need to handle.
This does save us from having to rebootstrap this.
bye,
//mirabilos
- --
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (MirBSD)
Comment: ☃ ЦΤℱ—８ ☕☂☄
iQIcBAEBCQAGBQJmA0vXAAoJEHa1NLLpkAfg0ZQQAI7P7qoVfADQrrsuNHAShvTB
lRvuK1br7bHRmqUx89dDwjOG1k0Xji3X3OURZldlhPCk99SJxQP3DLoCX5cmCzIA
IDyq+GoxREjJ/uyb4b6/qTAgSh7ZdRqxEfbVLsukL1i+wRs6dNw2Wg64i/R538jE
+yncg7zMyrWSA+3815i7BRfdMZBEk9E1qgW3hlnhueVfgANuyBLzzJchSstjunqE
0OcIukVQ30HaWaALmAfGcl7lcfM0sUFXL+EVpA8aBsVWNzZHtMIPnmI+yx8X4NOo
BOkfcYbPI928VZ/91meibSb9FXk8ShnO+zv+gU6dX74RlVoqOIeg6UQ/r2Cy+Up9
ssnksqTWTSkw1/n9bRNNiU8/O4kI5xV6FCUk2CaOsk+diQfXpoga50TR6DRM52tp
mjtBetkI1qK9vA0Y1VS+KoPp/FDYwFBKXiU3Jax9L7koaT5wGCurILqNTbDGVe19
2nmnphBUeIFniPByiItSEv7jH9GgxZyrwRvonYYpDXNeXFa0ymTNzKzrIG2ZqMrz
LcELgtIb6OD+WDYajUMOlTRBj2N9rFodruKyMcdUfc4so3OoFnS3cOdBvWBk/NdX
sFRgES39Ak5xgA3f4hP2ba03KZOFH2iIT3M8ZtZhH7eOIdhErKIUG0t6hxpWFdiV
ntE5WUlefRxovhbTOXKa
=KoS1
-END PGP SIGNATURE-
Bug#1067745: bookworm-pu: package nvidia-settings/535.171.04-1~deb12u1
Control: tags -1 + confirmed On Tue, 2024-03-26 at 11:09 +0100, Andreas Beckmann wrote: > In order to upgrade src:nvidia-graphics-drivers to the 535 LTS series > (the 525 series currently in stable is already EoL), we need to > update > some additional packages (some driver components can be built from > source and reside in contrib). Please go ahead. Regards, Adam
Processed: Re: Bug#1067745: bookworm-pu: package nvidia-settings/535.171.04-1~deb12u1
Processing control commands: > tags -1 + confirmed Bug #1067745 [release.debian.org] bookworm-pu: package nvidia-settings/535.171.04-1~deb12u1 Added tag(s) confirmed. -- 1067745: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067745 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1067742: bookworm-pu: package nvidia-xconfig/535.171.04-1~deb12u1
Control: tags -1 + confirmed On Tue, 2024-03-26 at 10:51 +0100, Andreas Beckmann wrote: > In order to upgrade src:nvidia-graphics-drivers to the 535 LTS series > (the 525 series currently in stable is already EoL), we need to > update > some additional packages (some driver components can be built from > source and reside in contrib). Please go ahead. Regards, Adam
Processed: Re: Bug#1067742: bookworm-pu: package nvidia-xconfig/535.171.04-1~deb12u1
Processing control commands: > tags -1 + confirmed Bug #1067742 [release.debian.org] bookworm-pu: package nvidia-xconfig/535.171.04-1~deb12u1 Added tag(s) confirmed. -- 1067742: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067742 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1067739: bookworm-pu: package nvidia-persistenced/535.171.04-1~deb12u1
Processing control commands: > tags -1 + confirmed Bug #1067739 [release.debian.org] bookworm-pu: package nvidia-persistenced/535.171.04-1~deb12u1 Added tag(s) confirmed. -- 1067739: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067739 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1067739: bookworm-pu: package nvidia-persistenced/535.171.04-1~deb12u1
Control: tags -1 + confirmed On Tue, 2024-03-26 at 10:40 +0100, Andreas Beckmann wrote: > In order to upgrade src:nvidia-graphics-drivers to the 535 LTS series > (the 525 series currently in stable is already EoL), we need to > update > some additional packages (some driver components can be built from > source and reside in contrib). Please go ahead. Regards, Adam
Bug#1036884: libgpgme11t64 binNMUs
The next good target for binNMUs that wasn't done yet (AFAICS) is https://release.debian.org/transitions/html/auto-gpgme1.0.html -- WBR, wRAR signature.asc Description: PGP signature
Processed: nmu: libjcat_0.2.0-2+b1
Processing control commands: > affects -1 + src:libjcat Bug #1067769 [release.debian.org] nmu: libjcat_0.2.0-2+b1 Added indication that 1067769 affects src:libjcat -- 1067769: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067769 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1067769: nmu: libjcat_0.2.0-2+b1
Package: release.debian.org Severity: normal X-Debbugs-Cc: libj...@packages.debian.org Control: affects -1 + src:libjcat User: release.debian@packages.debian.org Usertags: binnmu nmu libjcat_0.2.0-2 . armel armhf . unstable . -m "rebuild against libgpgme11t64" Possibly not very high impact, but I think this would unblock fwupd. smcv
Bug#1036884: transition: time64_t -> sphinxbase
I think binNMUs for packages involved in https://release.debian.org/transitions/html/auto-sphinxbase.html would be useful. If I'm reading correctly, that would unblock ffmpeg on armel/armhf (or at least get some way towards it), and ffmpeg is involved in a bunch of other sub-transitions. (I hope this is an OK format to make suggestions in?) Thanks, smcv
Bug#1067729: nmu: exim4_4.97-5
On 2024-03-26 Andreas Metzler wrote: [...] > nmu exim4_4.97-5 . armel armhf hppa m68k . unstable . -m "Rebuild against > libspf2-dev >= 1.2.10-8.1 (64-bit time_t transition)" > The first t64-changed libspf2 was uninstallable on the 32bit archs, > which is why exim4 was not bin-nmued successfully there yet. This is > fixed now. > This can only be done successfully after libtirpc 1.3.4+ds-1.2 has > passed NEW processing. libtirpc has been accepted. :-) The exim4 changelog entry should refer to -8.2, though: nmu exim4_4.97-5 . armel armhf hppa m68k . unstable . -m "Rebuild against libspf2-dev 1.2.10-8.2 (64-bit time_t transition)" cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Processed: nmu: xmlrpc-c_1.33.14-11
Processing control commands: > affects -1 + src:xmlrpc-c Bug #1067762 [release.debian.org] nmu: xmlrpc-c_1.33.14-11 Added indication that 1067762 affects src:xmlrpc-c -- 1067762: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067762 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1067762: nmu: xmlrpc-c_1.33.14-11
Package: release.debian.org Severity: normal X-Debbugs-Cc: xmlrp...@packages.debian.org Control: affects -1 + src:xmlrpc-c User: release.debian@packages.debian.org Usertags: binnmu nmu xmlrpc-c_1.33.14-11 . armel armhf . unstable . -m "Rebuild for time_t" https://packages.debian.org/unstable/libxmlrpc-core-c3t64
Bug#1067749: marked as done (nmu: ffmpeg_7:6.1.1-3)
Your message dated Tue, 26 Mar 2024 13:09:02 +0100 with message-id and subject line Re: Bug#1067749: nmu: ffmpeg_7:6.1.1-3 has caused the Debian Bug report #1067749, regarding nmu: ffmpeg_7:6.1.1-3 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.) -- 1067749: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067749 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal X-Debbugs-Cc: ffm...@packages.debian.org Control: affects -1 + src:ffmpeg User: release.debian@packages.debian.org Usertags: binnmu Manual (bootstrap?) builds of ffmpeg on armel, armhf seem to have been done with libglib2.0-0, which is depended on by at least libavcodec-extra60. nmu ffmpeg_7:6.1.1-3 . armel armhf . unstable . -m "rebuild against libglib2.0-0t64" Thanks, smcv --- End Message --- --- Begin Message --- On 2024-03-26 10:39:03 +, Simon McVittie wrote: > Package: release.debian.org > Severity: normal > X-Debbugs-Cc: ffm...@packages.debian.org > Control: affects -1 + src:ffmpeg > User: release.debian@packages.debian.org > Usertags: binnmu > > Manual (bootstrap?) builds of ffmpeg on armel, armhf seem to have been done > with libglib2.0-0, which is depended on by at least libavcodec-extra60. It was an upload with the pkg.ffmpeg.stage1 and pkg.ffmpeg.noextra build profiles. > nmu ffmpeg_7:6.1.1-3 . armel armhf . unstable . -m "rebuild against > libglib2.0-0t64" Scheduled Cheers -- Sebastian Ramacher--- End Message ---
Bug#1067748: marked as done (nmu: vlc_3.0.20-3)
Your message dated Tue, 26 Mar 2024 13:04:17 +0100 with message-id and subject line Re: Bug#1067748: nmu: vlc_3.0.20-3 has caused the Debian Bug report #1067748, regarding nmu: vlc_3.0.20-3 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.) -- 1067748: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067748 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal X-Debbugs-Cc: v...@packages.debian.org Control: affects -1 + src:vlc User: release.debian@packages.debian.org Usertags: binnmu nmu vlc_3.0.20-3 . riscv64 . unstable . -m "Rebuild with libqt5core5t64" https://packages.debian.org/sid/vlc-plugin-qt --- End Message --- --- Begin Message --- On 2024-03-26 15:15:49 +0500, Andrey Rakhmatullin wrote: > Package: release.debian.org > Severity: normal > X-Debbugs-Cc: v...@packages.debian.org > Control: affects -1 + src:vlc > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu vlc_3.0.20-3 . riscv64 . unstable . -m "Rebuild with libqt5core5t64" Scheduled Cheers -- Sebastian Ramacher--- End Message ---
Bug#1067746: marked as done (nmu: poppler_22.12.0-2.2)
Your message dated Tue, 26 Mar 2024 13:04:04 +0100 with message-id and subject line Re: Bug#1067746: nmu: poppler_22.12.0-2.2 has caused the Debian Bug report #1067746, regarding nmu: poppler_22.12.0-2.2 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.) -- 1067746: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067746 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal X-Debbugs-Cc: popp...@packages.debian.org Control: affects -1 + src:poppler User: release.debian@packages.debian.org Usertags: binnmu nmu poppler_22.12.0-2.2 . riscv64 . unstable . -m "Rebuild with libqt5core5t64" See https://packages.debian.org/sid/libpoppler-qt5-1t64 --- End Message --- --- Begin Message --- On 2024-03-26 15:10:01 +0500, Andrey Rakhmatullin wrote: > Package: release.debian.org > Severity: normal > X-Debbugs-Cc: popp...@packages.debian.org > Control: affects -1 + src:poppler > User: release.debian@packages.debian.org > Usertags: binnmu > > nmu poppler_22.12.0-2.2 . riscv64 . unstable . -m "Rebuild with > libqt5core5t64" Scheduled Cheers -- Sebastian Ramacher--- End Message ---
Processed: nmu: ffmpeg_7:6.1.1-3
Processing control commands: > affects -1 + src:ffmpeg Bug #1067749 [release.debian.org] nmu: ffmpeg_7:6.1.1-3 Added indication that 1067749 affects src:ffmpeg -- 1067749: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067749 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1067749: nmu: ffmpeg_7:6.1.1-3
Package: release.debian.org Severity: normal X-Debbugs-Cc: ffm...@packages.debian.org Control: affects -1 + src:ffmpeg User: release.debian@packages.debian.org Usertags: binnmu Manual (bootstrap?) builds of ffmpeg on armel, armhf seem to have been done with libglib2.0-0, which is depended on by at least libavcodec-extra60. nmu ffmpeg_7:6.1.1-3 . armel armhf . unstable . -m "rebuild against libglib2.0-0t64" Thanks, smcv
Bug#1036884: transition: time64_t - openjdk-17 needs re-bootstrap on armel,armhf
It seems that some of the dependency chains for packages that are still waiting to be rebuilt on armel,armhf now end at openjdk-17, which is the default Java version for most architectures and Build-Depends on itself (with an alternative dependency on openjdk-16, but that no longer exists). evolution-data-server -> libphonenumber-dev is an example. Are the ARM or Java teams intending to re-bootstrap openjdk-17 somehow? Or do maintainers of packages that build both a C/C++ library and Java bindings from a single source package need to disable its Java bindings on the affected architectures, either temporarily or permanently? openjdk-21 is in a similar situation, build-depending on itself, while openjdk-22 and openjdk-23 build-depend on -21 and -22 respectively. Presumably once we have a single OpenJDK version that is installable, it would be possible to step through 18,19,20,21 building each version with the previous one. In the -ports world, hppa doesn't have Java anyway, while m68k, powerpc and sh4 seem to have had a re-bootstrap at some point; so I think it's only the release architectures armel and armhf that have a problem here. smcv
Processed: nmu: vlc_3.0.20-3
Processing control commands: > affects -1 + src:vlc Bug #1067748 [release.debian.org] nmu: vlc_3.0.20-3 Added indication that 1067748 affects src:vlc -- 1067748: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067748 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1067748: nmu: vlc_3.0.20-3
Package: release.debian.org Severity: normal X-Debbugs-Cc: v...@packages.debian.org Control: affects -1 + src:vlc User: release.debian@packages.debian.org Usertags: binnmu nmu vlc_3.0.20-3 . riscv64 . unstable . -m "Rebuild with libqt5core5t64" https://packages.debian.org/sid/vlc-plugin-qt
Bug#1067746: nmu: poppler_22.12.0-2.2
Package: release.debian.org Severity: normal X-Debbugs-Cc: popp...@packages.debian.org Control: affects -1 + src:poppler User: release.debian@packages.debian.org Usertags: binnmu nmu poppler_22.12.0-2.2 . riscv64 . unstable . -m "Rebuild with libqt5core5t64" See https://packages.debian.org/sid/libpoppler-qt5-1t64
Processed: nmu: poppler_22.12.0-2.2
Processing control commands: > affects -1 + src:poppler Bug #1067746 [release.debian.org] nmu: poppler_22.12.0-2.2 Added indication that 1067746 affects src:poppler -- 1067746: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067746 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1067745: bookworm-pu: package nvidia-settings/535.171.04-1~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu [ Reason ] In order to upgrade src:nvidia-graphics-drivers to the 535 LTS series (the 525 series currently in stable is already EoL), we need to update some additional packages (some driver components can be built from source and reside in contrib). [ Impact ] Driver components of different major versions may not work well together (untested combinations) or at least confuse users. In nvidia-driver there is a versioned (major part only) Recommends on nvidia-settings that would otherwise be unsatisfiable. [ Tests ] Would require nvidia hardware and driver usage. [ Risks ] Low. Upgrading the nvidia driver stack to new upstream releases in stable has been done in the past. [ Checklist ] [*] *all* changes are documented in the d/changelog [.] I reviewed all changes and I approve them (excluding a review of the upstream changes) [*] attach debdiff against the package in (old)stable [*] the issue is verified as fixed in unstable [ Changes ] +nvidia-settings (535.171.04-1~deb12u1) bookworm; urgency=medium + + * Rebuild for bookworm. + + -- Andreas Beckmann Tue, 26 Mar 2024 10:53:55 +0100 + +nvidia-settings (535.171.04-1) unstable; urgency=medium + + * New upstream release 535.171.04. +- Updated the nvidia-settings control panel to ensure that the entire + Display Configuration page can be used when the Layout window is shown. +- Updated the nvidia-settings control panel to allow the primary display + to be set on any GPU in a multi-GPU system. + * New upstream release 535.146.02. +- Fixed a bug that caused the nvidia-settings control panel to crash + when running on Wayland with newer versions of libwayland-client. + * New upstream release 535.54.03. +- Fixed a bug that prevented SLI Mosaic controls from being displayed in + * New upstream release 535.43.02. +- Added power usage and power limits information to nvidia-settings + PowerMizer page. + the nvidia-settings control panel when using GSP Firmware. + + -- Andreas Beckmann Mon, 25 Mar 2024 11:28:14 +0100 + +nvidia-settings (530.41.03-1) unstable; urgency=medium + + * New upstream release 530.41.03. + * Switch B-D from pkg-config to pkgconf. + + -- Andreas Beckmann Tue, 19 Mar 2024 19:47:39 +0100 - pkg-config was already a transitional package in bookworm. debian/changelog | 32 debian/control |2 debian/patches/12_nvidia-settings.desktop.diff |2 doc/nvidia-settings.desktop|2 doc/version.mk |2 samples/version.mk |2 src/Makefile |4 src/gtk+-2.x/ctkappprofile.c |7 src/gtk+-2.x/ctkdisplayconfig.c| 184 +++- src/gtk+-2.x/ctkdisplayconfig.h|1 src/gtk+-2.x/ctkdisplaydevice.c| 74 + src/gtk+-2.x/ctkdisplaylayout.c| 23 src/gtk+-2.x/ctkevent.c|5 src/gtk+-2.x/ctkframelock.c| 351 +++- src/gtk+-2.x/ctkframelock.h|5 src/gtk+-2.x/ctkgridlicense.c | 424 -- src/gtk+-2.x/ctkgridlicense.h |4 src/gtk+-2.x/ctkpowermizer.c | 148 +++ src/gtk+-2.x/ctkpowermizer.h |6 src/libXNVCtrl/NVCtrl.h| 33 src/libXNVCtrl/version.mk |2 src/libXNVCtrlAttributes/NvCtrlAttributes.h|8 src/libXNVCtrlAttributes/NvCtrlAttributesNvml.c| 275 +++--- src/libXNVCtrlAttributes/NvCtrlAttributesPrivate.h | 81 +- src/nv_grid_dbus.h |6 src/nvml.h | 840 ++--- src/parse.c| 10 src/version.mk |2 src/wayland-connector.c|5 version.mk |2 30 files changed, 1941 insertions(+), 601 deletions(-) [ Other info ] This is a rebuild of the package from sid with no further changes. I do not plan to update src:libxnvctrl in main (which uses a copy of the same source tarball as src:nvidia-settins in contrib) from the 525 to the 535 series. Andreas nvidia-settings_535.171.04-1~deb12u1.diff.xz Description: application/xz
Bug#1067742: bookworm-pu: package nvidia-xconfig/535.171.04-1~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu [ Reason ] In order to upgrade src:nvidia-graphics-drivers to the 535 LTS series (the 525 series currently in stable is already EoL), we need to update some additional packages (some driver components can be built from source and reside in contrib). [ Impact ] Driver components of different major versions may not work well together (untested combinations) or at least confuse users. [ Tests ] Would require nvidia hardware and driver usage. [ Risks ] Low. Upgrading the nvidia driver stack to new upstream releases in stable has been done in the past. [ Checklist ] [*] *all* changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in (old)stable [*] the issue is verified as fixed in unstable [ Changes ] +nvidia-xconfig (535.171.04-1~deb12u1) bookworm; urgency=medium + + * Rebuild for bookworm. + + -- Andreas Beckmann Tue, 26 Mar 2024 10:42:46 +0100 + +nvidia-xconfig (535.171.04-1) unstable; urgency=medium + + * New upstream release. + + -- Andreas Beckmann Mon, 25 Mar 2024 11:01:38 +0100 + +nvidia-xconfig (530.41.03-1) unstable; urgency=medium + + * New upstream release. + + -- Andreas Beckmann Tue, 19 Mar 2024 18:19:15 +0100 + +nvidia-xconfig (525.147.05-1) unstable; urgency=medium + + * New upstream release. + * Switch B-D from pkg-config to pkgconf. + + -- Andreas Beckmann Mon, 12 Feb 2024 01:00:28 +0100 - pkg-config was already a transitional package in bookworm. - Upstream changes are only the version bump. [ Other info ] This is a rebuild of the package from sid with no further changes. Andreas diff --git a/debian/changelog b/debian/changelog index 7388e99..c4aae45 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,28 @@ +nvidia-xconfig (535.171.04-1~deb12u1) bookworm; urgency=medium + + * Rebuild for bookworm. + + -- Andreas Beckmann Tue, 26 Mar 2024 10:42:46 +0100 + +nvidia-xconfig (535.171.04-1) unstable; urgency=medium + + * New upstream release. + + -- Andreas Beckmann Mon, 25 Mar 2024 11:01:38 +0100 + +nvidia-xconfig (530.41.03-1) unstable; urgency=medium + + * New upstream release. + + -- Andreas Beckmann Tue, 19 Mar 2024 18:19:15 +0100 + +nvidia-xconfig (525.147.05-1) unstable; urgency=medium + + * New upstream release. + * Switch B-D from pkg-config to pkgconf. + + -- Andreas Beckmann Mon, 12 Feb 2024 01:00:28 +0100 + nvidia-xconfig (525.85.05-1) unstable; urgency=medium * New upstream release. diff --git a/debian/control b/debian/control index cb08ba1..409c3aa 100644 --- a/debian/control +++ b/debian/control @@ -7,7 +7,7 @@ Uploaders: Build-Depends: debhelper-compat (= 13), m4, - pkg-config, + pkgconf, xserver-xorg-dev, Rules-Requires-Root: no Standards-Version: 4.6.2 diff --git a/debian/copyright b/debian/copyright index 074b28c..a187e54 100644 --- a/debian/copyright +++ b/debian/copyright @@ -124,8 +124,9 @@ Copyright: (c) 1997-2001 by The XFree86 Project, Inc. License: other-XFree Files: debian/* -Copyright: © 2005 Randall Donald - © 2010-2023 Andreas Beckmann +Copyright: + © 2005 Randall Donald + © 2010-2024 Andreas Beckmann License: GPL-2+ License: GPL-2 diff --git a/debian/salsa-ci.yml b/debian/salsa-ci.yml index 24a535b..d0f7c0e 100644 --- a/debian/salsa-ci.yml +++ b/debian/salsa-ci.yml @@ -1,7 +1,6 @@ --- include: - - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml - - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml + - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml variables: SALSA_CI_COMPONENTS: 'main contrib' diff --git a/version.mk b/version.mk index 36f5738..89404cd 100644 --- a/version.mk +++ b/version.mk @@ -1,4 +1,4 @@ -NVIDIA_VERSION = 525.85.05 +NVIDIA_VERSION = 535.171.04 # This file. VERSION_MK_FILE := $(lastword $(MAKEFILE_LIST))
Bug#1067739: bookworm-pu: package nvidia-persistenced/535.171.04-1~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
In order to upgrade src:nvidia-graphics-drivers to the 535 LTS series
(the 525 series currently in stable is already EoL), we need to update
some additional packages (some driver components can be built from
source and reside in contrib).
[ Impact ]
Driver components of different major versions may not work well together
(untested combinations) or at least confuse users.
[ Tests ]
Would require nvidia hardware and driver usage.
[ Risks ]
Low. Upgrading the nvidia driver stack to new upstream releases in
stable has been done in the past.
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in (old)stable
[*] the issue is verified as fixed in unstable
[ Changes ]
+nvidia-persistenced (535.171.04-1~deb12u1) bookworm; urgency=medium
+
+ * Rebuild for bookworm.
+
+ -- Andreas Beckmann Tue, 26 Mar 2024 01:13:10 +0100
+
+nvidia-persistenced (535.171.04-1) unstable; urgency=medium
+
+ * New upstream release.
+
+ -- Andreas Beckmann Mon, 25 Mar 2024 10:51:19 +0100
+
+nvidia-persistenced (530.41.03-1) unstable; urgency=medium
+
+ * New upstream release.
+ * Switch B-D from pkg-config to pkgconf.
+
+ -- Andreas Beckmann Tue, 19 Mar 2024 17:59:21 +0100
+
+nvidia-persistenced (525.147.05-1) unstable; urgency=medium
+
+ * New upstream release.
+ * Update the list of supported drivers.
+
+ -- Andreas Beckmann Fri, 26 Jan 2024 23:34:41 +0100
- pkg-config was already a transitional package in bookworm.
- The transitional -tesla driver packages have been removed from
dependency alternatives.
[ Other info ]
This is a rebuild of the package from sid with no further changes.
Andreas
diff --git a/debian/changelog b/debian/changelog
index 4a6ead7..4cd4301 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,29 @@
+nvidia-persistenced (535.171.04-1~deb12u1) bookworm; urgency=medium
+
+ * Rebuild for bookworm.
+
+ -- Andreas Beckmann Tue, 26 Mar 2024 01:13:10 +0100
+
+nvidia-persistenced (535.171.04-1) unstable; urgency=medium
+
+ * New upstream release.
+
+ -- Andreas Beckmann Mon, 25 Mar 2024 10:51:19 +0100
+
+nvidia-persistenced (530.41.03-1) unstable; urgency=medium
+
+ * New upstream release.
+ * Switch B-D from pkg-config to pkgconf.
+
+ -- Andreas Beckmann Tue, 19 Mar 2024 17:59:21 +0100
+
+nvidia-persistenced (525.147.05-1) unstable; urgency=medium
+
+ * New upstream release.
+ * Update the list of supported drivers.
+
+ -- Andreas Beckmann Fri, 26 Jan 2024 23:34:41 +0100
+
nvidia-persistenced (525.85.05-1) unstable; urgency=medium
* New upstream release.
diff --git a/debian/control b/debian/control
index 488080e..a55bf29 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,7 @@ Uploaders:
Andreas Beckmann ,
Build-Depends:
debhelper-compat (= 13),
- pkg-config,
+ pkgconf,
libtirpc-dev,
m4,
Rules-Requires-Root: no
@@ -21,8 +21,7 @@ Multi-Arch: foreign
Pre-Depends:
${misc:Pre-Depends}
Depends:
- libnvidia-cfg1 [!i386 !armhf !ppc64el]
- | libnvidia-tesla-cfg1 [amd64 arm64 ppc64el]
+ libnvidia-cfg1 [!i386 !armhf]
| libnvidia-tesla-470-cfg1 [amd64 arm64 ppc64el]
| libnvidia-cfg.so.1
| libnvidia-cfg1-any,
diff --git a/debian/copyright b/debian/copyright
index 929b9c2..61fef5c 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -9,12 +9,12 @@ Disclaimer:
NVIDIA drivers in non-free.
Files: *
-Copyright: Copyright (C) 2004-2022 NVIDIA Corporation
+Copyright: Copyright (C) 2004-2023 NVIDIA Corporation
License: Expat
Files: debian/*
Copyright:
- © 2014-2023 Andreas Beckmann
+ © 2014-2024 Andreas Beckmann
License: Expat
License: Expat
diff --git a/debian/salsa-ci.yml b/debian/salsa-ci.yml
index 14fa000..c3d1fdf 100644
--- a/debian/salsa-ci.yml
+++ b/debian/salsa-ci.yml
@@ -1,7 +1,6 @@
---
include:
- - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
- -
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+ -
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/recipes/debian.yml
variables:
SALSA_CI_COMPONENTS: 'main contrib non-free'
diff --git a/nv-ioctl-numa.h b/nv-ioctl-numa.h
index 3fad820..1d456ec 100644
--- a/nv-ioctl-numa.h
+++ b/nv-ioctl-numa.h
@@ -62,6 +62,7 @@ typedef struct nv_ioctl_numa_info
uint64_t memblock_size __aligned(8);
uint64_t numa_mem_addr __aligned(8);
uint64_t numa_mem_size __aligned(8);
+uint8_t use_auto_online;
nv_offline_addresses_t offline_addresses __aligned(8);
} nv_ioctl_numa_info_t;
diff --git a/nvidia-numa.c b/nvidia-numa.c
index afc8fe4..0fbd287 100644
--- a/nvidia-numa.c
+++ b/nvidia-numa.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2018, NVIDIA CORPORATION.
+ * Copyright (c) 2018-2023, NVIDIA CORPORATION.
*
* Permission is hereby granted, free of charge, to any person
* ob
