Please block glj....@gmail.com from Debian lists [Re: UOC and Britsh Council lawsuit]

2024-04-22 Thread Steve Langasek
solved. > > "Kinda or not" > -- 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

Re: Package marked for autoremoval due to closed bug?

2024-03-14 Thread Steve Langasek
of the maintainers at this point, it's very much dependent on folks rebootstrapping armel and armhf against the new library names. Should these bugs be downgraded again to important severity? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer

Re: time_t progress report

2024-03-14 Thread Steve Langasek
ill be coordinated with the Release Team. > Am 27. Februar 2024 08:19:21 MEZ schrieb Steve Langasek : > >Hi Simon, > > > >On Mon, Feb 26, 2024 at 11:40:56AM +, Simon McVittie wrote: > >> > glib2.0 # already in experimental > > > >&g

Re: 64-bit time_t transition: cargo needs manual intervention

2024-03-12 Thread Steve Langasek
s: - unpack cargo and libstd-rust debs to the root via dpkg-deb -x - use equivs to mock up packages by these names with no dependencies and install those - bootstrap - enjoy -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer

Re: Requesting help with the t64 transition

2024-03-08 Thread Steve Langasek
nt in unstable for 2 days? I'm also not sure why it hasn't expired out of unstable given that it is superseded. -- 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

Re: 64-bit time_t transition in progress in unstable

2024-03-07 Thread Steve Langasek
com-err2 and libss2 don't use time_t, so > the rename to ...t64 was completely unnecessary. Yes, apologies, we can't assume any particular mapping from -dev packages to runtime lib packages in packages that have multiple -dev packages, so libcom-err2 and libss2 were swept up in the renaming and I

Re: Perl problem - loadable library and perl binaries are mismatched

2024-03-06 Thread Steve Langasek
tils-cbuilder-perl package anymore. (which, btw, was an arch: all package, so in any case it wouldn't be affected by the ABI transition.) -- 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 Dev

Re: 64-bit time_t transition in progress in unstable

2024-03-06 Thread Steve Langasek
On Thu, Mar 07, 2024 at 01:43:11AM +0500, Andrey Rahmatullin wrote: > On Wed, Mar 06, 2024 at 12:33:08PM -0800, Steve Langasek wrote: > > > > Are there instructions on how to progress an unstable system through > > > > this, or is the repo currently in a known

Re: 64-bit time_t transition in progress in unstable

2024-03-06 Thread Steve Langasek
r today?), if apt dist-upgrade is NOT working, I think we should want to see some apt output showing what's not working. -- 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

Re: time_t transition and bugs

2024-03-03 Thread Steve Langasek
an.net/1309262/ curl, nordugrid-arc, poppler, qtbase-opensource-src, and xmlrpc-c have been uploaded with the fix. petsc will take a little bit, as there are other bugs that need fixing at the same time. -- Steve Langasek Give me a lever long enough and a Fre

Re: Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

2024-02-28 Thread Steve Langasek
r the information, > let's see if this is a real issue or not. Furthermore, this is a downgrade from a replacing package to a replaced package. Unless you also --reinstall the package at the end, missing files are quite to be expected. -- Steve Langasek G

Re: time_t progress report

2024-02-26 Thread Steve Langasek
tainer name reverts in unstable that happen after this are not guaranteed to be picked up, and whatever package names we have on the Ubuntu side are going to be locked in for a 10-year LTS cycle. So I think any maintainer who's concerned about dependency compatibility with third-party de

Re: Another take on package relationship substvars

2024-02-23 Thread Steve Langasek
e these substvars, *IFF* there is not already a reference to the substvar in question in the package stanza in debian/control? This would provide adequate flexibility for any other exceptions that might be out there, beyond the Pre-Depends case. Cheers, -- Steve Langasek Giv

Re: time_t progress report

2024-02-23 Thread Steve Langasek
On Fri, Feb 23, 2024 at 04:36:43PM +0100, Guillem Jover wrote: > Hi! > On Mon, 2024-02-19 at 19:48:38 -0800, Steve Langasek wrote: > > I have coordinated with the gcc maintainer so that we can have the default > > flags in gcc-13 changed this week. > > We are th

time_t progress report

2024-02-19 Thread Steve Langasek
, no revdeps sipxtapi: failed # no sane ABI info; https://bugs.debian.org/1064328 snort: failed # obsolete, skip it python3.10: failed # soon to be obsolete skip it python3.11: failed # has to be handled manually, mark failed temporarily python3.12: failed Thanks, -- Steve Langasek Give me

Re: Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

2024-02-16 Thread Steve Langasek
fixup(pam_misc_conv_warn_time64, pam_misc_conv_warn_time); > +fixup(pam_misc_conv_die_time64, pam_misc_conv_die_time); > +} > +static void reset_warn_time() { > + pam_misc_conv_warn_time = 0; > + pam_misc_conv_warn_time64 = 0; > +} > + > +#else > + > +static void

Re: 64-bit time_t transition in progressL

2024-02-16 Thread Steve Langasek
experimental where possible, but we will not be pulling experimental versions into unstable as part of this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world

Re: 64-bit time_t transition in progress

2024-02-15 Thread Steve Langasek
On Tue, Feb 06, 2024 at 05:33:22PM +, Alberto Garcia wrote: > On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote: > > In fact, none of the t64 binaries currently being uploaded > > to experimental have the final ABI either, we're just using > > experimenta

Re: 64-bit time_t transition in progress

2024-02-15 Thread Steve Langasek
in gcc or glibc ? On Thu, Feb 08, 2024 at 08:07:19PM +0100, Ansgar wrote: > On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote: > > Once all of these packages have built in experimental and we have identified > > and addressed all adverse interactions with the usrmerge trans

libselinux1t64 (et al): breaks system in upgrade from unstable

2024-02-15 Thread Steve Langasek
> we'll have to clean up all those diversions, and in forky+1 we'll have > to delete the cleanup code, so while investing more now may seem more > expensive, it saves later. I think the cost of chasing upstreams about soname bumps and dual-abi'ing libraries swamps any savings for the maintain

Re: Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

2024-02-14 Thread Steve Langasek
and breaking the world has affected the timeline, yes. I now have a tested patch that I've raised as an MP in salsa: https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/9 I welcome review from the Debian libselinux maintainers prior to opening a discussion with upstream. (Which I will

Re: postgresql-16; wrong NMU versions (Re: 64-bit time_t transition in progress)

2024-02-05 Thread Steve Langasek
/log.txt Much better that there be a library transition only for the lesser-used library! -- 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://w

Re: 64-bit time_t transition in progress

2024-02-04 Thread Steve Langasek
On Mon, Feb 05, 2024 at 08:57:50AM +0200, Andrius Merkys wrote: > On 2024-02-02 19:46, Steve Langasek wrote: > > If there is no new version in experimental, or there is a new version BUT > > the patch against unstable applies cleanly to the version in experimental > >

Re: 64-bit time_t transition in progress

2024-02-03 Thread Steve Langasek
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

Re: 64-bit time_t transition in progress

2024-02-03 Thread Steve Langasek
e, 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

Re: 64-bit time_t transition in progress

2024-02-03 Thread Steve Langasek
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 hesi

Re: 64-bit time_t transition in progress

2024-02-02 Thread Steve Langasek
On Fri, Feb 02, 2024 at 07:34:46PM +0100, Bill Allombert wrote: > On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote: > > Dear developers, > > As mentioned previously on debian-devel[6], we know that there are a number > > of library packages being included in thi

Re: 64-bit time_t transition in progress

2024-02-02 Thread Steve Langasek
in experimental can ignore this transition and just use the new soname once it finally lands (is superseded by the next LTS version?) On Fri, Feb 02, 2024 at 09:46:10AM -0800, Steve Langasek wrote: > On Fri, Feb 02, 2024 at 05:27:02PM +, Scott Kitterman wrote: > > On February 2, 2024 4

Re: 64-bit time_t transition in progress

2024-02-02 Thread Steve Langasek
On Fri, Feb 02, 2024 at 05:27:02PM +, Scott Kitterman wrote: > On February 2, 2024 4:43:52 PM UTC, 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-NMU

Re: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition

2024-02-01 Thread Steve Langasek
On Thu, Feb 01, 2024 at 07:45:57AM +0100, Carsten Schoenert wrote: > Hello Steve, > Am 31.01.24 um 21:59 schrieb Steve Langasek: > ... > > Please find the patch for this NMU attached. > > If you have any concerns about this patch,

Re: 64-bit time_t: package lists, counts du jour, dd-list for NMUs

2024-01-22 Thread Steve Langasek
in the changelog. So I guess I'll work on fleshing out a rename map for these. On Sun, Jan 21, 2024 at 12:57:17AM -0800, Steve Langasek wrote: > Hello, > > Here is an updated analysis of the transition. This is based on a full > rerun on Debian unstable as of 2024-01-17 and inclu

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-21 Thread Steve Langasek
ot have an > > > > ABI > > > > breakage, especially in the long tail of libraries with few > > > > reverse-dependencies whose involvement in the transition is unlikely to > > > > substantially slow down Debian development. > I was look

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-20 Thread Steve Langasek
On Sun, Jan 07, 2024 at 09:30:37AM +0100, Rene Engelhard wrote: > Am 07.01.24 um 02:01 schrieb Steve Langasek: > > If you say you are going to fix eventual breakage (and not ignoring the > > test results!) and if that means fixing asm on all affected archs, then > > it's

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-19 Thread Steve Langasek
Hi again, On Sun, Jan 07, 2024 at 01:09:48PM +0100, Rene Engelhard wrote: > Am 07.01.24 um 04:38 schrieb Steve Langasek: > > The ordering here would be: > > - dpkg will be uploaded to experimental with 64-bit time_t in the default > >flags > > - the source packag

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timelineg

2024-01-18 Thread Steve Langasek
On Wed, Jan 17, 2024 at 09:33:12PM -0800, Steve Langasek wrote: > And my proposal for checking that set, since we're only talking about > runtime library packages, is to check whether any of the contents of these > packages in bookworm match ^/lib - as a runtime library package NOT

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-17 Thread Steve Langasek
Hi Colin, On Tue, Jan 09, 2024 at 01:32:11PM +, Colin Watson wrote: > On Mon, Jan 08, 2024 at 03:01:11PM -0800, Steve Langasek wrote: > > On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote: > > > On 05-01-2024 17:36, Rene Engelhard wrote: > > > > Also

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-08 Thread Steve Langasek
pportunity to catch such mistakes if they happen. -- 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...@ub

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-08 Thread Steve Langasek
use it will take time to get all the binary uploads done (longer than it will take to get the sourceful uploads to unstable done), so it's better to stage in experimental to minimize the window in unstable when uploads can be broken. -- Steve Langasek Give me a lever long enough

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-06 Thread Steve Langasek
On Sat, Jan 06, 2024 at 09:25:52AM +0100, Rene Engelhard wrote: > Hi, > Am 06.01.24 um 06:51 schrieb Steve Langasek: > > > > - dpkg will be uploaded to experimental with 64-bit time_t in the > > > > default > > > > flags > > [...] &

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-06 Thread Steve Langasek
On Sat, Jan 06, 2024 at 09:07:15AM +0100, Rene Engelhard wrote: > Am 06.01.24 um 06:51 schrieb Steve Langasek: > > > > - dpkg will be uploaded to experimental with 64-bit time_t in the > > > > default > > > > flags > > > I  think at that point

Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-06 Thread Steve Langasek
On Sat, Jan 06, 2024 at 10:01:30AM -0700, Sam Hartman wrote: > >>>>> "Steve" == Steve Langasek writes: > >> At one level, krb5-multidev only has an rdep of 5, but I suspect > >> the rdep count for libkrb5-dev is somewhat larger:-) I don't kn

Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-05 Thread Steve Langasek
On Fri, Jan 05, 2024 at 02:23:59PM -0700, Sam Hartman wrote: > >>>>> "Steve" == Steve Langasek writes: > Steve> - In multi-library packages, there is no reliable way to map > Steve> from a set of headers in a dev package to specific shared >

Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-05 Thread Steve Langasek
well. Reduces the count of revdeps to be rebuilt from 5450+169 to 5450+168 (not much improvement :). -- 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

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-05 Thread Steve Langasek
dress your concern. It's not as if there is going to be any time that it's ok to tell maintainers they can't use experimental at all because we're doing this transition. > >experimental with the new binary package names in order to clear binary > >NEW, in coordination > And wha

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-05 Thread Steve Langasek
On Fri, Jan 05, 2024 at 09:32:28PM +0100, Sebastian Ramacher wrote: > On 2024-01-05 11:06:09 -0800, Steve Langasek wrote: > > On Fri, Jan 05, 2024 at 06:53:50PM +0100, Sebastian Ramacher wrote: > > > Hi Steve > > > > - perl will also get a sourceful uploa

Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-05 Thread Steve Langasek
not? Sorry for the confusion. The two lists requiring binary package name changes are the attachments named 'source-packages' and 'lfs-and-depends-time_t'. This is what I fed into dd-list, and encompass 1248 source packages (1195 + 53). -- Steve Langasek Give me

64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-05 Thread Steve Langasek
the sourceful NMUs of the libraries will be reuploaded to unstable (without binaries, so that they can be promoted to testing without additional uploads). - perl will also get a sourceful upload, to manually handle 'perlapi' Provides. - binNMUs will be scheduled for all of the reverse-dep

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-05 Thread Steve Langasek
cies of libvlccore9 in the archive that are not VLC plugins (phonon4qt5-backend-vlc etc). Are these packages simply mis-linked against that library? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer

Re: Bug#1036884: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-05 Thread Steve Langasek
On Fri, Jan 05, 2024 at 12:05:57PM +, Simon McVittie wrote: > On Fri, 05 Jan 2024 at 00:17:04 -0800, Steve Langasek wrote: > > - In multi-library packages, there is no reliable way to map from a set of > > headers in a dev package to specific shared libraries in a

Re: 64-bit time_t: updated archive analysis, proposed transition plan with timeline

2024-01-05 Thread Steve Langasek
Hi Sebastian, On Fri, Jan 05, 2024 at 06:34:38PM +0100, Sebastian Ramacher wrote: > On 2024-01-05 00:23:00 -0800, Steve Langasek wrote: > > On Fri, Jan 05, 2024 at 12:17:04AM -0800, Steve Langasek wrote: > > > == Results == > > > The overall findings of this analys

Re: debian/copyright format and SPDX

2023-09-24 Thread Steve Langasek
On Fri, Sep 22, 2023 at 12:58:10PM +0200, Stephan Lachnit wrote: > On Fri, Sep 22, 2023 at 11:11 AM Steve Langasek wrote: > > SPDX defines an xml format only. They lost before they'd even started. > > debian/copyright is supposed to be human-readable first and foremost. XML >

Re: debian/copyright format and SPDX

2023-09-22 Thread Steve Langasek
traction and people centered on desktop files. > We failed to gain traction on the structure of the copyright file, and > spdx is the one who has won here. SPDX defines an xml format only. They lost before they'd even started. debian/copyright is supposed to be human-readable f

Re: Do not plan to support /usr/lib/pam.d for Debian pam

2023-09-15 Thread Steve Langasek
o are willing > to do the work have a larger share of power in the decision making. I would like to see that discussion happen. I don't think this thread is that discussion, and I'm not stepping forward to drive it. -- Steve Langasek Give me a lever long enough and a Fr

Re: /usr/-only image

2023-09-15 Thread Steve Langasek
s integration with the OS that has been done in /etc. -- 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.

Re: Do not plan to support /usr/lib/pam.d for Debian pam

2023-09-15 Thread Steve Langasek
e} which are constructed at package install time and therefore are inappropriate to ship in /usr. Shipping the same file in both /usr and /etc from application packages seems like it would be a reasonable workaround as far as it goes, but doesn't let us empty /etc/pam.d. -- Steve Langasek

Re: armhf NEON exception for chromium

2023-09-15 Thread Steve Langasek
On Fri, Sep 15, 2023 at 10:15:53PM +0200, Paul Gevers wrote: > Hi Steve, > On 15-09-2023 21:54, Steve Langasek wrote: > > armel != armhf > Of course > > and nobody should be running armel on a NEON-capable CPU... > Not sure why you say it like that, I guess you don't m

Re: armhf NEON exception for chromium

2023-09-15 Thread Steve Langasek
list of > features of that machine.) armel != armhf and nobody should be running armel on a NEON-capable CPU... or chromium on an armel-only system. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can m

Re: Questionable Package Present in Debian: fortune-mod

2023-08-21 Thread Steve Langasek
he views expressed, in all of the packages in the archive. An audit of that sort would certainly be unrealistic. -- 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

Re: Questionable Package Present in Debian: fortune-mod

2023-08-21 Thread Steve Langasek
ons of religious texts would presumably be the first things > tossed onto the pyre. Don't you think it's a bit hyperbolic to equate "not distributing a text in our archive" to "book burning"? -- Steve Langasek Give me a lever long enough and a Free OS Debian Deve

Re: Questionable Package Present in Debian: fortune-mod

2023-08-18 Thread Steve Langasek
als > who have themselves engaged in terrorism or other violence toward > individuals and groups, supported those who have engaged in such > activities, or been otherwise complicit in such. Lol bothsidesing anarchism and fascism -- Steve Langasek Give me a lever long en

Re: Potential MBF: packages failing to build twice in a row

2023-08-14 Thread Steve Langasek
t; bothered me. It just hasn't bothered me enough to investigate what the proper > way to solve it is. It hasn't bothered me enough to bother other people with > this issue. Agreed. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer t

Re: Mini-DebConf in Cambridge, UK - November 23-26 2023

2023-07-23 Thread Steve Langasek
hile it's best practice when replying to make sure you're sending to the right address, the fact that it winds up in your announce imap folder is a local configuration issue, not a question of where it was sent. -- Steve Langasek Give me a lever long enough and a Free OS Debian De

Re: proposal: dhcpcd-base as standard DHCP client starting with Trixie

2023-07-21 Thread Steve Langasek
And I can say that I am a happy user of netplan across multiple systems, with no need to manage networkd configuration directly. -- 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

Re: 64-bit time_t: an update

2023-07-21 Thread Steve Langasek
On Thu, Jul 20, 2023 at 12:30:50AM +0100, Simon McVittie wrote: > On Wed, 19 Jul 2023 at 14:27:21 -0700, Steve Langasek wrote: > > to understand the impact that a change to the size of > > time_t will have on a library's ABI, it must be possible to compile the > > headers

64-bit time_t: an update

2023-07-19 Thread Steve Langasek
n having some of these library packages excluded from the transition is welcome to contribute fixes up to that deadline that will let us analyze them and show that the ABI has not changed. Your thoughts? -- Steve Langasek Give me a lever long enough and a Free OS Deb

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-07-06 Thread Steve Langasek
482 1039564 Also closing WNPP bug(s): ===== -- 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

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-06-13 Thread Steve Langasek
On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote: > On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote: > > The difference in my view is that the changes to handle Provides: are > > something that should persist in the packaging (until the next soname >

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-06-08 Thread Steve Langasek
if we find that there isn't consensus. If we need more assurance that the project supports the decision, I think it's better to go straight for a GR. I wouldn't like this to drag on too long into the trixie release cycle. -- Steve Langasek Give me a lever long enough and a F

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-06-06 Thread Steve Langasek
Hi Helmut, On Tue, Jun 06, 2023 at 09:33:22AM +0200, Helmut Grohne wrote: > On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote: > > * … but NOT on i386.  Because i386 as an architecture is primarily of > > interest for running legacy binaries which cannot be rebuil

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

2023-05-30 Thread Steve Langasek
both sells them and provides them free to people in need. They receive x86-64 systems that they determine are *too old to be worth refurbishing* and they e-cycle them. Hanging on to systems using power-hungry chips from 20 years ago instead of intercepting a system such as this is not reducing

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-05-22 Thread Steve Langasek
On Mon, May 22, 2023 at 06:24:53PM -0700, Steve Langasek wrote: > > We don't need to enable/fix it for everything though. A rebuild check of > > affected libraries to see how much work this adds would be a good idea. > Isn't it a problem not just for library ABIs but also for any

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-05-22 Thread Steve Langasek
but also for any other packages rebuild with -D_TIME_BITS=64, because the code will be consuming the 64-bit prototype from the headers but using the 32-bit symbol at runtime? (Which is a better answer in terms of automation, because then we can just put it in dpkg-buildflags) -- Steve Langasek

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-05-22 Thread Steve Langasek
vance - either now or by delaying the time_t transition. I don't see any way to avoid this via automated source analysis, so the only option (given that we can't avoid the time_t transition forever) is to rebuild and then find out what breaks, which I think is best done at the beg

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-05-19 Thread Steve Langasek
On Tue, May 16, 2023 at 09:04:10PM -0700, Steve Langasek wrote: > Based on the analysis to date, we can say there is a lower bound of ~4900 > source packages which will need to be rebuilt for the transition, and an > upper bound of ~6200.  I believe this is a manageable transition, and

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

2023-05-19 Thread Steve Langasek
care about test results for it because it has no end-user application!) -- 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

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

2023-05-19 Thread Steve Langasek
ic" Unix *roff behavior. Dustin Kirkland once did a demo where he booted every 6-monthly Ubuntu release since the dawn of time in a VM (15+ at the time, I think). That's much more useful for software archaeology of this sort than providing i386 host support in *future* Debian releases. -- Steve Lan

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

2023-05-19 Thread Steve Langasek
programs is a compelling reason to keep binary-compatibility on i386. But I counter that unless you care about this, there's no reason to keep i386 as an architecture *at all*. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-05-18 Thread Steve Langasek
ame handling for mipsel as for other 32-bit archs wrt compatibility provides; do you agree? -- 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

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-05-18 Thread Steve Langasek
On Thu, May 18, 2023 at 03:04:30AM +0200, Guillem Jover wrote: > On Tue, 2023-05-16 at 21:04:10 -0700, Steve Langasek wrote: > > === Technical details === > > The proposed implementation of this transition is as follows: > > * Update dpkg-buildflags to emit -

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-05-18 Thread Steve Langasek
should also emit -Wno-implicit-function-declaration; cc:ing the bug on dpkg regarding implementation of that interface. -- 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

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-05-17 Thread Steve Langasek
ckages? >+ Which? > I understand that answering these questions on a per-package basis is > far from trivial. That much is evident from your analysis. I think this > is ok. Even if such a service says "unknown" 10% of the time, that'd > still be very useful. Do you

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-05-17 Thread Steve Langasek
On Tue, May 16, 2023 at 09:31:05PM -0700, Russ Allbery wrote: > Steve Langasek writes: > > * Largely via NMU, add a “t64” suffix to the name of runtime library > > packages whose ABI changes on rebuild with the above flags.  If an > > affected library already has a diffe

Re: 64-bit time_t transition for 32-bit archs: a proposal

2023-05-17 Thread Steve Langasek
Hi Craig, On Wed, May 17, 2023 at 10:14:17PM +1000, Craig Small wrote: > On Wed, 17 May 2023 at 14:10, Steve Langasek wrote: > > Over on debian-arm@lists, there has been discussion on and off for several > > months now about the impending 32-bit timepocalypse. As many of you ar

64-bit time_t transition for 32-bit archs: a proposal

2023-05-16 Thread Steve Langasek
packages under the old name on upgrade. * In the future when the upstream SONAME changes, the t64 suffix should be dropped. Your thoughts? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move

Bug#1034266: ITP: pam-session-timelimit -- permit configuring time limits for user sessions

2023-04-11 Thread Steve Langasek
Package: wnpp Severity: wishlist Owner: Steve Langasek * Package name: pam-session-timelimit Version : 0.5 Upstream Author : Steve Langasek * URL : https://github.com/vorlonofportland/pam_session_timelimit * License : LGPLv3 Programming Lang: C Description

Re: DEB_BUILD_OPTIONS=nowerror

2023-02-28 Thread Steve Langasek
ld results to identify Werror-related failures with high signal would require two parallel builds, one with and without the flag, built against the same baseline. So since this is infeasible, if Debian decides to pass -Wno-error by default from dpkg-buildflags, we might find ourselves diver

Re: DEB_BUILD_OPTIONS=nowerror

2023-02-27 Thread Steve Langasek
On Mon, Feb 27, 2023 at 03:06:25PM -0700, Sam Hartman wrote: > >>>>> "Steve" == Steve Langasek writes: > Steve> If this is for people doing out-of-archive builds who don't > Steve> want to deal with failures from -Werror, I can see how having

Re: DEB_BUILD_OPTIONS=nowerror

2023-02-27 Thread Steve Langasek
or dpkg-buildflags to be changed to emit -Wno-error *by default*, with an option flag along the lines of DEB_BUILD_OPTIONS=Werror that lets you turn it on instead. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I

Re: OpenMPI 5.0 to be 32-bit only ?

2023-02-14 Thread Steve Langasek
ving it. > > > ... > > > The point of going  64-bit only is to clean up data structures and remove > > > technical debt: Hence 5.x will start a cleanup and removal of 32-bit code. > > > > > > The next point release may work on 32-bit by just bypassing th

Re: setting sysctl net.ipv4.ping_group_range

2023-01-07 Thread Steve Langasek
ommon sysctl settings among different distributions would be in the Linux kernel, instead of diverging from the kernel defaults in userspace and representing this as "common". -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer

Re: Firmware GR result - what happens next?

2022-10-02 Thread Steve Langasek
t think the base-files maintainer would like) or apt. -- 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

Re: ifupdown/dhcp

2022-05-16 Thread Steve Langasek
On Mon, May 16, 2022 at 08:46:04PM +0200, Ben Hutchings wrote: > On Sun, 2022-05-08 at 22:07 +0200, Steve Langasek wrote: > [...] > > Ubuntu no longer uses isc-dhcp by default, because it no longer uses > > ifupdown; NetworkManager and networkd both have their own implement

Re: ifupdown/dhcp

2022-05-08 Thread Steve Langasek
ill be the only game in town. It would be a good idea to make sure as part of the deprecation of isc-dhcp-client that we get initramfs integration of whatever is the preferred replacement. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer

Re: RFC: pam: dropping support for NIS/NIS+?

2022-04-22 Thread Steve Langasek
asswordrequisite pam_cracklib.so retry=3 > difok=3 minlen=14 > Yes, I surely would miss the NIS support. If your users are using yppasswd on the NIS master for changing passwords, then evidently you are not relying on support for NIS in PAM. (yppasswd doesn't even link agains

Re: RFC: pam: dropping support for NIS/NIS+?

2022-04-21 Thread Steve Langasek
going to offer it up as a solution without some evidence of demand (which I would say this thread hasn't yet established), since it would require additional work on the package. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set

Re: RFC: pam: dropping support for NIS/NIS+?

2022-04-21 Thread Steve Langasek
rom is not a sane security policy, and I don't think we should indefinitely make Debian worse for all other users (bigger minimal system == worse) to cater to users of these obsolete, insecure systems. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer

Re: Firmware - what are we going to do about it?

2022-04-20 Thread Steve Langasek
o perhaps someone wants to be particularly clever and give the installer an appropriately-sized empty partition in the partition table that the firmware bits could be blatted into. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer

RFC: pam: dropping support for NIS/NIS+?

2022-04-20 Thread Steve Langasek
+ in the next Debian release, would anybody miss it? Or has everyone moved on to LDAP / AD by now? -- 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

Re: Firmware - what are we going to do about it?

2022-04-20 Thread Steve Langasek
> Are we again in the world of "Everyone must adapt because I'm different" ? > > > > We ain't gonna go back to this WOKE thinking and "positive > > discrimination bullshit", please no ! > > > Samuel > > > > > > > -- > > Pol

Re: Seeking consensus for some changes in adduser

2022-03-10 Thread Steve Langasek
tem capabilities; and as far as I'm aware we have no filesystems that support fscaps extended attributes but NOT acls, nor am I aware of any archive formats that would preserve fscaps without also preserving acls. -- Steve Langasek Give me a lever long enough and a Free OS Debian

  1   2   3   4   5   6   7   8   9   10   >