y
>a user-controlled key is equally problematic as non-free firmware.
>Trisquel and Guix avoids these, and I recall seeing stuff like that in
>Debian -- https://tracker.debian.org/pkg/shim-signed -- but it is good
>to know that we have more things to work.
Sigh.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...
Jon Dowland wrote:
>
>I'm *fairly* sure that a more pressing issue is that MoinMoin requires
>Python 2, which has been abandoned.
>
>At least the stable and deployed versions: 2.0.0a1 is the first release
*nod*
I think we have moin2 packages just about ready for use, but I have
worries: it's not
Jonas wrote:
>Quoting Steve McIntyre (2025-01-14 15:16:49)
>> Jonas wrote:
>> >Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
>> >>
>> >> thank you for the offer but why not have the follow up in a publicly
>> >> archived
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
Erm, WTF? How about keeping this on a main project list. And maybe
even include the current people working on web and wiki admin?
Unimpressed...
--
Steve McIntyre, Cambridge, UK.st...
GnuPG.
There's a lot of loaded words in what you write there.
Debian has *always* added config, applied patches and adapted upstream
behaviour of upstream packages to make them fit our needs better. Why
should GnuPG be any different?
--
Steve McIntyre, Cambridge, UK.
aking the
changes necessary to satisfy the Devuan developers that a separate distro is
no longer needed.
--
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
r now and tell
people to look there.
* Set up ai-summary.debian.net and post there, alongside suitable
disclaimer text.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...
on our
lists. If you want to publish them, publish them somewhere separately
IMHO.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...
ing, etc) and I also absolutely 100% did
NOT want NetworkManager managing my ethernet port and had it configured via
netplan instead.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
U
ult.
It hasn't been AFAIK, no. d-i always asks, with the default being "no".
--
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...
n both Debian and Ubuntu - to my consternation as a member of
the Ubuntu Release Team, since that increases the number of flavor images
we have to manage releases of ;)
- Canonical has not discontinued its development of lxd. I think the larger
Free Software community pol
oo many to be
>bothered to check between 10 and 999 commits.
I understand what you're trying to say, but that's a disingenuous
comparison. systemd is a massive (some would say *too* massive)
project with fingers in many pies. How many of those people have
touched *networking* bits?
-
On Mon, Jun 24, 2024 at 12:18:56PM +0200, somebody *claiming* to be Luna
Jernberg wrote:
Just to be 100% clear, that mail didn't come from Luna's normal gmail
account but was instead spoofed and sent via emkei.cz, a "free online
fake mailer". It's now blocked from
ng on? The mass-NMUs included a
lintian override to suppress this warning.
--
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
port for other armhf devices for both Ubuntu and Ubuntu Core to come soon
in 24.04.
--
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
ved.
>
> "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
that way.
>
>nvi adds to the subversive ones, with bash, etc.
What on earth do you mean by "subversive" here??
--
Steve McIntyre, Cambridge, UK.st...@einval.com
"Arguing that you don't care about the right to privacy because you have
noth
ogtool to Salsa?
>
>Not speaking for logtool obviously, but maintaining simple packages on salsa is
>just useless bureaucracy.
So that's OK for *you* only in this case. Now consioder for the
project as a whole. Every package that differs from the norm is more
effort for anybody else to
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
those should still
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
> &
one in Ubuntu is:
- 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 De
n 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
Similarly, libcom-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
all the libextutils-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 t
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
t is done (later 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.
https://paste.debian.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 Free
me troubles. Thanks for 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
ansition through, we aren't going to vary it by
much. So maintainer 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
maintai
gate 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
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 therefore
failed
# no sane ABI info, 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 Lang
_compat_time() {
> +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;
> +}
> +
are being staged in 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
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
> > experi
this be made the default 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 w
the package rename without so rename and then in forky
> 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 bum
in unstable 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 upst
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
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
> > (n
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
aded 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
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
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
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
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-b
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,
libdmtx0b and libvibrant6b at least have explanations 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
library does not 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.
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&#
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
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 m
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
On Fri, Jan 05, 2024 at 09:17:52PM +0100, Paul Gevers wrote:
> Hi Steve,
> On 05-01-2024 17:36, Rene Engelhard wrote:
> > Also a problem is that experimental also might already contain totally
> > unrelated updates like new upstream versions...
> I share this worry. Have you
cause 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 l
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
> > [...]
>
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
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'
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
>
LFS and is a
false-positive, I've removed this as 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 i
ld address 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 c
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
which do 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 Lang
g defaults
will be uploaded to unstable
- 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'
Provi
On Fri, Jan 05, 2024 at 06:53:50PM +0100, Sebastian Ramacher wrote:
> Hi Steve
> > - perl will also get a sourceful upload, to manually handle 'perlapi'
> > Provides.
> Can we combine this one with the upcoming perl transition? See #1055955.
Pros and cons of combin
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
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
ot;my gpg/$TOOL segfaults on your input", I want to be able to
>point them at a documented decision and say "please report a bug to
>$TOOL" instead of taking a week off to port everything again to gpg.
>
>Thank you for all the work you've done on this
would i do?: reinstall some packages? reinstall the whole system?
>
>(maybe this should be in a bug against release-notes)
Maybe a wrapper script to just report likely problems would be a good
plan.
--
Steve McIntyre, Cambridge, UK.st...@einval.com
We don't need no education.
We don't need no thought control.
ly hope so!
So I've just set up a ProtonMail test account to verify. Mailing to
myself, it already clearly knew about my PGP key (I've already had
lots of encrypted mails from ProtonMail users), but sending to a
different address that came through in plain text.
So *that* doesn't
.org will encrypt the email that
>>is sent to the BTSe...which has the effect of making Debian development
>>veiled in plain sight rather than "in the open".
>
>Does it not encrypt email per-sender?
Ewww, I certainly hope so!
Do we have any examples of encrypted ma
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. XM
> gain 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 h
It would be lovely to get this enabled! It's a pain point for me also, on
occasion.
-Steve
he project.
> I appreciate the value of doing work and having people who 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
o pam, it'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 http
ession-noninteractive} 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
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
the 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
s 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
s 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
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
has
> 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
So while 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 Fr
and get human-editable
netplan files out), it's certainly close. 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
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
> > he
in 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
Debian Develop
1038482
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
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
>
they can work even if we don't have the library loader
>on the ABI-compliant path?
What exactly do you mean here? You know that even a statically linked
executable needs an interpreter defined in the ELF header?
--
Steve McIntyre, Cambridge, UK.st...@einval.com
a decision 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
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
ons of old computers,
refurbishes them, installs Linux, and 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 in
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 al
ABIs 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
ver, I fail to see any way
that we can effectively mitigate this in advance - 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
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
Steve Langasek wrote:
>
>On Fri, May 19, 2023 at 12:42:32PM +0100, Steve McIntyre wrote:
>> >If the main reason is to support non-free binaries, at least to me
>> >that does not seem like a very compelling reason. And people can
>> >always use old chroots or s
Andrew Cater wrote:
>On Fri, May 19, 2023 at 03:03:40PM +0100, Steve McIntyre wrote:
>>
>> I had been thinking about doing similar for installer images too, but
>> with other work going on too I think it got too late in the cycle to
>> make that change. My plan is there
ootstrap and {s,}chroot will cover the vast majority of
needs. That's how we've been building i386 software already for ages
in Debian already.
More complex things can be done if needed: loopback mount an image,
debootstrap, install a kernel, etc. I don't see this as somethin
1 - 100 of 4373 matches
Mail list logo
