Re: 64-bit time_t transition in progress
Hi, Since the time transition is going to require an openmpi transition, I suggest that the mpi-defaults transition happen simultaneously; ie mpi-defaults to move 32-bit builds to mpich; openmpi 4.1.6-6 with t64 libs builds against 64-bit libs only. Note there is a 5.0.1-1 package in experimental for openmpi that is not ready for primetime; for the t64 transition use 4.1.6 not 5.0.1. Thanks Alastair On 02/02/2024 16:43, Steve Langasek wrote: Hello, debian-devel-announce wouldn't let me attach the file, but for those on debian-devel at least, you can find the dd-list of to-be-NMUed source packages attached. Thanks, -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Re: 64-bit time_t transition in progress
Hi, Le vendredi 02 février 2024 à 08:21 -0800, Steve Langasek a écrit : > The packages previously not reported are: > > flint > flint-arb About flint: if you need anything done, don't hesitate to ask me. About flint-arb: its code has been merged into flint, so it's abandoned upstream. The package is in FTBFS... only the sagemath package prevents its removal. Don't get blocked by this mess, you already have enough on your plate. Cheers, J.Puydt
Re: 64-bit time_t transition in progress
Il 02/02/2024 17:43, Steve Langasek ha scritto: Hello, debian-devel-announce wouldn't let me attach the file, but for those on debian-devel at least, you can find the dd-list of to-be-NMUed source packages attached. Thanks, Sorry to bother you (or anyone else who wants to answer) with a question that might be stupid, maybe I didn't understand something. From what I understand, for most of the packages involved a rebuild is enough but this rebuild must be done after that of all their dependencies (dependencies of dependencies etc...) involved to avoid unexpected events that could cause crashes on some architectures (in cases ABI changes occurred in the underlying dependencies but the rebuild was done before one of those). Having a package that depends on many and that part of those are themselves involved in various other chains, how do NMU (when needed) to unstable and rebuilds of other packages happen? A single NMU on unstable or rebuild (for each package involved) but with such an order so that when it is done all dependencies are already rebuild, or with multiple rebuilds between the various migration chains involved? Thanks for any reply and sorry for my bad english. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1062807: ITP: python-django-adminplus -- Easily add custom views to the Django admin
Package: wnpp Severity: wishlist Owner: Michael Fladischer X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: python-django-adminplus Version : 0.6 Upstream Contact: James Socol * URL : https://github.com/jsocol/django-adminplus * License : BSD-3-clause Programming Lang: Python Description : Easily add custom views to the Django admin AdminPlus aims to be the smallest possible extension to the excellent Django admin component that lets you add admin views that are not tied to models. It allows one to add simple custom views without mucking about with hijacking URLs, and providing links to them right in the admin index. I intend to maintain this as part of the DPT. -BEGIN PGP SIGNATURE- iQFPBAEBCgA5FiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAmW+OwMbHGZsYWRpc2No ZXJtaWNoYWVsQGZsYWRpLmF0AAoJEP/TyIuZfdFqZAUIAK9izLc61P3/98JrYE3d QAIGxPAfDmv3hQKBtKmGf/nITumnXvNWYp1IUq1o4YUBdhBzi7lFfiQGmyh3NFvM S14c0iH5rvKc+rhnQiKqk+rzUtKvVKQZRj7SBqRr7nL2CMs2DAJBccEzhvPa5pdU a9RKHPYQ6Yn4EdLb4dKueA/nCqb5Hk50rzalicWMpW4wmH5wWBPAsnwvH+Vvy6cw f3q3mw7n6XigSJ+3DqqqLpmTnb01uY5DtjSi9wxaHfzzJOTX2YN98pgOgVpUCtX4 gZ7VMeaoUwgj2xLt/Q3X9FnLWOee7Ih8vi1UryQmIT0DCn9p6H9QlU3qyHMbGfsY kZ8= =Kwk6 -END PGP SIGNATURE-
Re: 64-bit time_t transition in progress
On 2024-02-02 10:12:18 [-0800], Steve Langasek wrote: > Sorry, I mean to add: in the specific case of clamav, the source in > experimental has a new soname. So the patch will definitely not apply; and > we will want to NMU clamav to unstable, with a rename of whatever runtime > library package is there at the time the NMUs happen; so the version of > clamav in experimental can ignore this transition and just use the new > soname once it finally lands (is superseded by the next LTS version?) I just updated the upload in experimental including the t64 changes. I suggest to do the transition clamav at the same time. Sebastian
Re: 64-bit time_t transition in progress
On 2024-02-02 08:43:52 [-0800], Steve Langasek wrote: > Hello, Hi, > debian-devel-announce wouldn't let me attach the file, but for those on > debian-devel at least, you can find the dd-list of to-be-NMUed source > packages attached. OpenSSL is on the list. I did not see a NMU bug report. Was the bug missed or can it be removed the list of packages that require a NMU? > Thanks, Sebastian
Re: 64-bit time_t transition in progress
Le samedi 03 février 2024 à 10:16 +0100, julien.pu...@gmail.com a écrit : > > About flint: if you need anything done, don't hesitate to ask me. > In fact multi-arch is broken for flint and I can probably fix it: would a new upload go in your way or on the contrary help you ? [I'll refrain any move until you confirm I won't break your effort.] Cheers, J.Puydt
Bug#1062814: ITP: pioneer -- space adventure game set in the Milky Way galaxy
Package: wnpp Severity: wishlist Owner: Reiner Herrmann X-Debbugs-Cc: debian-devel@lists.debian.org, debian-devel-ga...@lists.debian.org * Package name: pioneer Version : 20240203 * URL : https://pioneerspacesim.net/ * License : GPL-3 (code), CC-BY-SA-3.0 (data) Programming Lang: C/C++ Description : space adventure game set in the Milky Way galaxy > Pioneer is a space adventure game set in our galaxy at the > turn of the 31st century. > > The game is open-ended, and you are free to eke out whatever > kind of space-faring existence you can think of. Explore > and trade between millions of star systems. Turn to a > life of crime as a pirate, smuggler or bounty hunter. > Travel through the territories of various factions > fighting for power, freedom or self-determination. The > universe is whatever you make of it. I intend to maintain it in the Games team.
Re: 64-bit time_t transition in progress
On 2024-02-03 Sebastian Andrzej Siewior wrote: > On 2024-02-02 08:43:52 [-0800], Steve Langasek wrote: >> debian-devel-announce wouldn't let me attach the file, but for those on >> debian-devel at least, you can find the dd-list of to-be-NMUed source >> packages attached. > OpenSSL is on the list. I did not see a NMU bug report. Was the bug > missed or can it be removed the list of packages that require a NMU? "These (0-day) NMUs started on Monday, and about 500 libraries have been uploaded to experimental so far. The goal is to get all source packages that can be SRUed to experimental uploaded by this weekend." The fact that no "We are done" message followed suggests that Steve and his colleagues are still working on it and will get to OpenSSL in due time. 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'
Re: 64-bit time_t transition in progress
On Sat, Feb 03, 2024 at 10:16:48AM +0100, julien.pu...@gmail.com wrote: > Le vendredi 02 février 2024 à 08:21 -0800, Steve Langasek a écrit : > > The packages previously not reported are: > > flint > > flint-arb > About flint: if you need anything done, don't hesitate to ask me. > About flint-arb: its code has been merged into flint, so it's abandoned > upstream. The package is in FTBFS... only the sagemath package prevents > its removal. Don't get blocked by this mess, you already have enough on > your plate. Thanks. These were added because flint 2.9.0-5 which was the current version in December successfully analyzed and showed no ABI breakage, but flint 3.01-2 which is now current can't be analyzed due to compilation errors. https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libflint-dev/base/log.txt So *maybe* a quirk could be added for a-c-c to let the headers be analyzed and show that no change is needed. Or maybe the analysis would show that the new version has introduced new entry points that do depend on time_t size. I can't tell from here. I'm not bothered either way, but by default we're going to wind up picking this up in the mass NMUs and libflint18 will change to libflint18t64, which will have no effect either way on users upgrading from stable releases since this is a new soname since bookworm. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: 64-bit time_t transition in progress
On Sat, Feb 03, 2024 at 03:22:33PM +0100, julien.pu...@gmail.com wrote: > Le samedi 03 février 2024 à 10:16 +0100, julien.pu...@gmail.com a > écrit : > > About flint: if you need anything done, don't hesitate to ask me. > In fact multi-arch is broken for flint and I can probably fix it: would > a new upload go in your way or on the contrary help you ? [I'll refrain > any move until you confirm I won't break your effort.] We are currently only uploading to experimental, for clearing NEW and for usrmerge analysis. Once that is all done and dpkg is uploaded to unstable, we will rebase all patches on whatever version of the library is in unstable at that time. You don't need to hold off on an upload to unstable for fear of conflicts. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: 64-bit time_t transition in progress
On Sat, Feb 03, 2024 at 12:04:49PM +0100, Fabio Fantoni wrote: > > debian-devel-announce wouldn't let me attach the file, but for those on > > debian-devel at least, you can find the dd-list of to-be-NMUed source > > packages attached. > From what I understand, for most of the packages involved a rebuild is > enough This list of packages are the packages that require sourceful changes because the runtime library packages must be renamed to declare the ABI incompatibility (or, if a package rename is not appropriate, then managed Breaks: against binaries built against the old ABI). We have a list of the packages that need no-change-rebuilds, but it's not this list. > but this rebuild must be done after that of all their dependencies > (dependencies of dependencies etc...) involved to avoid unexpected events > that could cause crashes on some architectures (in cases ABI changes > occurred in the underlying dependencies but the rebuild was done before > one of those). > Having a package that depends on many and that part of those are themselves > involved in various other chains, how do NMU (when needed) to unstable and > rebuilds of other packages happen? > A single NMU on unstable or rebuild (for each package involved) but with > such an order so that when it is done all dependencies are already rebuild, > or with multiple rebuilds between the various migration chains involved? Once all of the library packages have been uploaded to unstable and rebuilt, we will push no-change rebuilds of all packages depending on the old runtime library names. There should be no need for multiple rounds of uploads; *all* packages with dependencies on *any* of the renamed libraries will be triggered as a batch. There may be build failures if there are interdependencies between some of these packages because of unsatisfiable build dependencies, but those will be resolved semi-automatically in cooperation with the buildd maintainers and only one round of builds will actually be required. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
