Simon McVittie dixit:
>opt-in to (2.) is available via -D_FILE_OFFSET_BITS=64 for the subset
>of libraries that can support it without breaking ABI, and similarly
Right, but e.g. refuses to work under it.
>That wasn't actually the reason for my concern. As far as I'm aware, the
>glibc dynamic
On Thu, 06 Jul 2023 at 16:33:22 +, Thorsten Glaser wrote:
> Simon McVittie dixit:
> >architecture would need to have a new dpkg architecture name, multiarch
> >tuple, GNU tuple (i?86-linux-gnut64?) and canonical ELF linker path.
>
> Bit of bikeshedding on the name, of course. timet64 (or a
> "Helmut" == Helmut Grohne writes:
Helmut> I concur. Given Simon's analysis and the replies even when
Helmut> combined with earlier messages, I now see significantly more
Helmut> voices for the opinion:
Helmut> i386 primarily exists for running legacy binaries and
On Thu, Jul 06, 2023 at 04:49:34PM +, Thorsten Glaser wrote:
> The Wanderer dixit:
> >> snes emulator. last upstream release 2007
> >>> zsnes deb otherosfs optional arch=any-i386
> >FWIW: though I haven't touched it in quite some while, I recall from all
> FWIW, I occasionally use zsnes
The Wanderer dixit:
>> snes emulator. last upstream release 2007
>>> zsnes deb otherosfs optional arch=any-i386
>
>FWIW: though I haven't touched it in quite some while, I recall from all
FWIW, I occasionally use zsnes and it works well.
But yes, hand-written assembly was part of that IIRC.
Simon McVittie dixit:
>On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote:
[…]
>> i.e we could keep the existing i386 for the gamers and have i386t64
>> (or whatever we call it) for ongoing use of i386 as a real OS.
>
>On Fri, 09 Jun 2023 at 16:39:38 +, Thorsten Glaser wrote:
>> Ideally we’d
On Wed, 05 Jul 2023 at 17:22:14 +0100, Wookey wrote:
> On 2023-06-06 11:45 +0100, Simon McVittie wrote:
> > 1. i386 as a fully-featured architecture that you can run independently
> >on 32-bit x86 systems from roughly the 2000-2010 era
> >
> > 2. i386 as a multiarch foreign architecture to
On 2023-06-06 11:45 +0100, Simon McVittie wrote:
I missed most of this conversation due to being on holiday, so just catching up
now.
I hesitate to continue the i386-distraction thread because what's
actually important is getting this transition underway on the other
arches, particularly arm32
On Mon, 26 Jun 2023 at 20:33, Aurelien Jarno wrote:
>
> On 2023-06-09 16:39, Thorsten Glaser wrote:
> > In particular I would, at the same time, like the baseline lowered
> > to i586 again. It was raised mostly for multimedia stuff, and it’s
> > now justifyable to ask people to use amd64 or armhf
On 2023-06-09 16:39, Thorsten Glaser wrote:
> In particular I would, at the same time, like the baseline lowered
> to i586 again. It was raised mostly for multimedia stuff, and it’s
> now justifyable to ask people to use amd64 or armhf or something for
> that.
This is plainly wrong. The current
> > Oh, wait! No, I'm wrong, CNFS actually does something smart and encodes
> > the header in ASCII when writing it to disk.
> >
> > Okay, phew, this isn't going to be nearly as bad as I had thought.
>
> Good news. It would be great if you could add relevant info to the wiki page:
>
On Tue, 2023-06-13 at 21:41:50 -0700, Steve Langasek wrote:
> After thinking about it, I'd like to suggest the following approach.
>
> - dpkg with the new default behavior uploaded to experimental
> - libraries uploaded to experimental with the new package names (so, NEW
> processing gets done)
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
> > change, at which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384
Helmut Grohne dixit:
>I'm inclined to call this consensus now and therefore ask those that do
>not agree with it to reply here - even if your reply is only stating
I disagree.
I would like to see a long-term commitment against electronic waste
Hi Everyone
It goes without saying that the Debian Code of Conduct applies to all
Debian communication platforms (https://www.debian.org/code_of_conduct),
but in addition to that, please try to go further when it comes to
potentially long, and technical discussions that many will try to
On Fri, 2023-06-09 at 09:22 +, Holger Levsen wrote:
> On Fri, Jun 09, 2023 at 11:49:21AM +0800, Paul Wise wrote:
> > > You mean by somehow refreshing the signatures there?
> > Some ideas for that are here:
> > https://bugs.debian.org/763419
> > https://bugs.debian.org/820423
>
> interesting.
On Fri, 09 Jun 2023 at 11:04:47 +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
>
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> > modern x86_64 systems
>
> Are these use-cases likely to work with future library ABIs, or
> do
On Fri, Jun 09, 2023 at 11:49:21AM +0800, Paul Wise wrote:
> > You mean by somehow refreshing the signatures there?
> Some ideas for that are here:
> https://bugs.debian.org/763419
> https://bugs.debian.org/820423
interesting. thanks for those pointers!
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
On Fri, Jun 09, 2023 at 12:25:21PM +0800, Paul Wise wrote:
> Has anyone checked what percentage of these binaries will still run
> adequately after 2038 with 32-bit time_t?
All, because you don't need to provide those programs with a correct
time. But this is all a positive decisions.
>
On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> 2. i386 as a multiarch foreign architecture to run legacy binaries on
> modern x86_64 systems
> 2a. legacy native Linux i386 binaries
> 2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> complete i386
On Thu, 2023-06-08 at 08:57 +, Holger Levsen wrote:
> You mean by somehow refreshing the signatures there?
Some ideas for that are here:
https://bugs.debian.org/763419
https://bugs.debian.org/820423
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
Description: This is a
On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> 2. i386 as a multiarch foreign architecture to run legacy binaries on
> modern x86_64 systems
Are these use-cases likely to work with future library ABIs, or
do they need old library ABIs from when the binaries were compiled?
>
Simon McVittie left as an exercise for the reader:
> Debian-style multiarch or Fedora/Arch-style multilib is a much, much
this is at least the second time you've drawn this distinction
in this thread. for anyone else who, like me, was uneasy with
their understanding of the concept:
On Wed, 07 Jun 2023 at 12:25:58 +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> > When considering the future of i386, a factor that we need to bear in
> > mind is that there are two major use-cases for i386, with requirements
> > that sometimes conflict:
>
>
On Tue, 06 Jun 2023 at 21:45:31 +0200, Alexis Murzeau wrote:
> On 06/06/2023 12:45, Simon McVittie wrote:
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> > modern x86_64 systems
> > 2a. legacy native Linux i386 binaries
> > 2b. legacy Windows i386 binaries
On Thu, Jun 08, 2023 at 05:57:49PM +, Holger Levsen wrote:
> RFC on d-d-a? That's at least less heavy than a GR and yet way more
> visible than just a thread on d-d.
The problem with doing an RFC on d-d-a is that it doesn't give us a clear,
timeboxed path to converging on a decision if we
On Thu, Jun 08, 2023 at 07:14:17PM +0200, Helmut Grohne wrote:
> I concur. Given Simon's analysis and the replies even when combined with
> earlier messages, I now see significantly more voices for the opinion:
>
> i386 primarily exists for running legacy binaries and binary
>
Hi Steve,
On Tue, Jun 06, 2023 at 12:45:42PM -0700, Steve Langasek wrote:
> I have a different read on the consensus here. While there has been a lot
> of discussion about whether to continue supporting i386 as a host arch,
> almost everyone participating in the thread who said they want this is
Simon McVittie dijo [Thu, Jun 08, 2023 at 10:33:45AM +0100]:
> - For game-related use cases in particular, 2030 GPU models aren't going
> to work with 2023 user-space graphics drivers (typically Mesa or
> NVIDIA-proprietary) because the 2030 GPU didn't exist yet at the time
> the 2023 driver
On Thu, 08 Jun 2023 at 11:19:15 +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
>
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> > modern x86_64 systems
> > 2a. legacy native Linux i386 binaries
> > 2b. legacy Windows i386
On Thu, Jun 08, 2023 at 11:19:15AM +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> > modern x86_64 systems
> > 2a. legacy native Linux i386 binaries
> > 2b. legacy Windows i386
On Thu, Jun 08, 2023 at 11:19:15AM +0800, Paul Wise wrote:
> Would it be feasible to drop i386 but still support this use-case by
> requiring folks to use historical releases on archive.debian.org?
You mean by somehow refreshing the signatures there?
Would IMO also be useful for other archs. :)
> On 8 Jun 2023, at 06:19, Paul Wise wrote:
>
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
>
>> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>>modern x86_64 systems
>>2a. legacy native Linux i386 binaries
>>2b. legacy Windows i386 binaries
Le jeu. 8 juin 2023 à 05:31, Paul Wise a écrit :
>
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
>
> > 2. i386 as a multiarch foreign architecture to run legacy binaries on
> >modern x86_64 systems
> >2a. legacy native Linux i386 binaries
> >2b. legacy Windows i386
On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> 2. i386 as a multiarch foreign architecture to run legacy binaries on
> modern x86_64 systems
> 2a. legacy native Linux i386 binaries
> 2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> complete i386
On 2023-06-07 Paul Wise wrote:
[...]
> There was another option mentioned earlier in the thread that could
> help resolve some aspects of these conflicts; make 32-bit arches
> (or just i386) support both time_t ABIs, like glibc and Linux do.
> The 64-bit time_t ABI would be the default but the
Hi!
On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote:
> On Fri, May 19, 2023 at 05:34:56AM +0200, Guillem Jover wrote:
> > Enabling time64 explicitly is what also had first come to my mind,
> > which does not seem too onerous if all the debhelper override
> > disappears? :) Then NEW
Hi, late on the thread, but...
On Tue, 30 May 2023 at 19:51, Diederik de Haas wrote:
>
> [Please CC me in replies as I'm not subscribed to this list]
>
> I hope I'm not too late for this discussion ...
>
> Steve McIntyre wrote:
> > Luca Boccassi wrote:
> > >On Fri, 19 May 2023 at 12:42, Steve
On 2023-06-07 at 03:19, Sune Vuorela wrote:
> On 2023-06-07, Paul Wise wrote:
>
>> On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote:
>>
>>> I've been reading the discussion around i386 a bit and found the
>>> direction it has taken a little unproductive.
>>
>> I note that there are a
On Wed, 07 Jun 2023 at 07:19:39 -, Sune Vuorela wrote:
> On 2023-06-07, Paul Wise wrote:
> > I note that there are a number of packages available on i386 but not
> > available on amd64, is anyone planning on an MBF about this issue?
>
> game stuff, mostly contrib, likely binary data for
Hi,
On Wed, Jun 7, 2023, at 09:19, Sune Vuorela wrote:
> lisp runtie. unsure why restricted
>> cmucl deb lisp optional arch=i386
>> cmucl-clm deb lisp optional arch=i386
cmucl contains a compiler and is self hosting (the compiler is used to create
the new version of the environment). x86 is
On 2023-06-07, Paul Wise wrote:
> On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote:
>
>> I've been reading the discussion around i386 a bit and found the
>> direction it has taken a little unproductive.
>
> I note that there are a number of packages available on i386 but not
> available on
On Tue, 2023-06-06 at 12:45 -0700, Steve Langasek wrote:
> since we don't really have an "i386 porting team"
The release team have registered Adrian Bunk as an i386 porter:
https://release.debian.org/testing/arch_spec.yaml
--
bye,
pabs
https://wiki.debian.org/PaulWise
signature.asc
On Tue, 2023-06-06 at 09:33 +0200, Helmut Grohne wrote:
> I've been reading the discussion around i386 a bit and found the
> direction it has taken a little unproductive.
I note that there are a number of packages available on i386 but not
available on amd64, is anyone planning on an MBF about
On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:
There was another option mentioned earlier in the thread that could
On Tue, 06 Jun 2023 at 12:27:56 -0600, Gunnar Wolf wrote:
> there is the possible
> case of people running I-don't-know-which proprietay productivity tool
> provided as a binary that cannot be convinced of a 64-bit time_t that
> will receive errors when the timeocalypse approaches
Sure, and
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 rebuilt against a new
>
Hi,
On 06/06/2023 12:45, Simon McVittie wrote:
2. i386 as a multiarch foreign architecture to run legacy binaries on
modern x86_64 systems
2a. legacy native Linux i386 binaries
2b. legacy Windows i386 binaries via Wine (which requires a somewhat
complete i386 Linux library
Simon McVittie dijo [Tue, Jun 06, 2023 at 11:45:26AM +0100]:
> On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote:
> > Judging from the conversation, killing i386 quite obviously is desired
> > by some participants, but evidently not by all. How quickly we want to
> > kill it is not
On Jun 06, Simon McVittie wrote:
> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:
Agreed. I will be more blunt: an i386 port which cannot run old i386
binaries would be
On Tue, 6 Jun 2023 at 11:46, Simon McVittie wrote:
>
> On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote:
> > Judging from the conversation, killing i386 quite obviously is desired
> > by some participants, but evidently not by all. How quickly we want to
> > kill it is not obvious to
On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote:
> Judging from the conversation, killing i386 quite obviously is desired
> by some participants, but evidently not by all. How quickly we want to
> kill it is not obvious to me.
When considering the future of i386, a factor that we need
Hi Steve,
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 rebuilt against a new
> ABI, changing the ABI on i386 would be counterproductive, as
On Friday, 2 June 2023 20:59:27 CEST Wouter Verhelst wrote:
> "complain on -devel" is not part of the job
That wasn't my intend, but I obviously horribly failed at that.
Won't happen again o/
signature.asc
Description: This is a digitally signed message part.
On Wed, May 31, 2023 at 11:24:15PM +0200, Diederik de Haas wrote:
> On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote:
[...]
> > 20+ year old machines are typically more power hungry, more expensive,
> > less performant, and less reliable than an up-to-date raspberry pi. If
> > you want
Adam Borowski left as an exercise for the reader:
> Instead of RasPis as suggested by many in this thread, I'd instead suggest
> whatever is the current model of Odroid-H2+:
I was intrigued, but https://ameridroid.com/products/odroid-h2
suggests it's been out of stock since 2021?
--
nick black
On Wed, May 31, 2023 at 10:10:56PM +, Andrew M.A. Cater wrote:
> As someone who owned and happily used an Asus eePC several years ago: very
> nice, silent - it also had a flash disk from the earliest days of flash disks.
Instead of RasPis as suggested by many in this thread, I'd instead
On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
>
> I would be VERY disappointed if Debian would abandon people who do NOT have
> the means to just buy new equipment whenever they feel like it.
Debian is a Do-ocracy. Which is to say, it's a volunteer project.
People work on
On Wed, 2023-05-31 at 00:51 +0200, Diederik de Haas wrote:
> I would be VERY disappointed if Debian would abandon people who do NOT have
> the means to just buy new equipment whenever they feel like it.
There are Debian contributors who are in this position (although
perhaps not with i386
On Wed, May 31, 2023 at 11:24:15PM +0200, Diederik de Haas wrote:
> On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote:
> > On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> My point is: what about people who don't have the option to *buy*
> anything (new or used), for
On Wed May 31, 2023 at 12:44 PM CEST, Wouter Verhelst wrote:
> On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> > While it may be a no-brainer for a person with a $/€ 1000 a month residual
> > income to just buy new hardware whenever they feel like it, that is not
the
> >
On Wed, 2023-05-31 at 19:48 +0100, Wookey wrote:
> On 2023-05-31 07:29 -0500, John Goerzen wrote:
>
> > > Hanging on to systems using power-hungry chips from 20 years ago instead
> > > of
> > > intercepting a system such as this is not reducing the number of computers
> > > that end up in the
On 2023-05-31 07:29 -0500, John Goerzen wrote:
> > Hanging on to systems using power-hungry chips from 20 years ago instead of
> > intercepting a system such as this is not reducing the number of computers
> > that end up in the waste stream, it just keeps you stuck with a more
> > power-hungry
John Goerzen dijo [Wed, May 31, 2023 at 07:29:38AM -0500]:
> (...)
> I guess the question is: is this use case too niche for Debian to
> continue supporting? I would suggest that as long as we have 32-bit
> ARM, are the challenges for 32-bit x86 really worse?
Do note, however, the ARM64 started
Alexandre Detiste dijo [Wed, May 31, 2023 at 01:00:42PM +0200]:
> Le mer. 31 mai 2023 à 12:44, Wouter Verhelst a écrit :
> > 20+ year old machines are typically more power hungry, more expensive,
> > less performant, and less reliable than an up-to-date raspberry pi.
>
> Embedded systems and
On Wed, May 31, 2023 at 07:29:38AM -0500, John Goerzen wrote:
Hi,
> I guess the question is: is this use case too niche for Debian to
> continue supporting? I would suggest that as long as we have 32-bit
> ARM, are the challenges for 32-bit x86 really worse?
If I assume for a moment that the
On Wed, May 31, 2023 at 01:00:42PM +0200, Alexandre Detiste wrote:
Hi,
> Embedded systems and medical one can be crazily expensive to maintain
> and even more to replace but some will run on i386 for a long time more
The question is: Is that a target for a future Debian installation and/or
a
On Tue, May 30 2023, Steve Langasek wrote:
> For businesses, the transition from 32-bit to 64-bit was several
> depreciation cycles ago.
>
> In my city, there is a non-profit that accepts donations of old computers,
> refurbishes them, installs Linux, and both sells them and provides them free
>
Le mer. 31 mai 2023 à 12:44, Wouter Verhelst a écrit :
> 20+ year old machines are typically more power hungry, more expensive,
> less performant, and less reliable than an up-to-date raspberry pi.
Embedded systems and medical one can be crazily expensive to maintain
and even more to replace but
On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> While it may be a no-brainer for a person with a $/€ 1000 a month residual
> income to just buy new hardware whenever they feel like it, that is not the
> case for everyone.
[...]
> It's absolutely true that modern machines are
If there's a well-supported social or technical reason to remove the
i386 Debian installer, I think that it would still be disappointing,
but acceptable.
I don't know what those reasons are yet (I've imagined that they could
be maintainer burden -- but as mentioned, I don't think there's much
Hi,
Quoting Diederik de Haas (2023-05-31 00:51:06)
> > If people have strong opinions about that plan, let us know please.
>
> I have *strong* opinions about this.
>
> https://lists.debian.org/debian-kernel/2023/01/msg00372.html was a message/
> plea to not forget about supporting OLD systems.
On Wed, May 31, 2023 at 12:51:06AM +0200, Diederik de Haas wrote:
> > >+1 for stopping publishing installers for i386, it has been mentioned
> > >many times but it's always worth repeating: electricity costs to keep
> > >running i386 hardware are already way higher than what it costs to buy
> > >a
[Please CC me in replies as I'm not subscribed to this list]
I hope I'm not too late for this discussion ...
Steve McIntyre wrote:
> Luca Boccassi wrote:
> >On Fri, 19 May 2023 at 12:42, Steve McIntyre wrote:
> >> I'm planning on stopping publishing installer images for i386
> >> soon. Why? We
Hi Steve,
On Wed, May 17, 2023 at 10:39:21PM -0700, Steve Langasek wrote:
> > I note that this may pose problems with intra-library interaction. Say
> > we need to enable time64 on a higher level library and a lower level
> > library does not use time_t, but uses off_t. As such, you'd opt out of
On Fri, 26 May 2023 at 00:27, Roger Lynn wrote:
>
> On 21/05/2023 07:00, James Addison wrote:
> > On Fri, 19 May 2023 at 22:58, Ansgar wrote:
> >> One of the problems with popcon is that it draws too much attention to
> >> old releases which isn't really interesting when talking about future
>
On 21/05/2023 07:00, James Addison wrote:
> On Fri, 19 May 2023 at 22:58, Ansgar wrote:
>> One of the problems with popcon is that it draws too much attention to
>> old releases which isn't really interesting when talking about future
>> developments. If one looks at arch usage per release (as
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 other packages
On Sat, May 20, 2023 at 12:28:41PM +0100, Wookey wrote:
> I was aware of it (the gentoo info is linked on the 64bit-time wiki
> page), but had not yet looked into how significant an issue this actually
> was, so had not documented it. (frankly, I was hoping we could avoid
> tying yet another
On Fri, May 19, 2023 at 05:34:56AM +0200, Guillem Jover wrote:
> > The proposal is to treat this as a flag day, where the toolchain (in this
> > case, dpkg-buildflags) changes, then we upload the affected libraries in a
> > short period of time, then once they're built and through new we rebuild
Hi Simon
On 2023/05/19 17:30, Simon McVittie wrote:
1. same as in recent Ubuntu: just enough packages (mostly libraries) to
configure it as a multiarch foreign architecture on an amd64 system,
and run legacy Linux i386 binaries directly or legacy Windows i386
binaries via Wine
2.
On Wed, May 17, 2023 at 01:45:10PM +0800, YunQiang Su wrote:
> For mipsel, we have one more thing to do:
> - NaN2008 vs NaN legacy
> So I'd prefer rebootstrap (only for mipsel).
> And In fact we did it: https://repo.oss.cipunited.com/debian/
I am also rebuilding Debian/mipsel from stretch on
On Fri, 19 May 2023 at 22:58, Ansgar wrote:
>
> On Fri, 2023-05-19 at 19:40 +0100, James Addison wrote:
> > Do we know how often the i386 installer is downloaded compared to
> > amd64, and could/should we start with updated messaging where those
> > are provided before removing users' ability to
On 2023-05-20 Wookey wrote:
> On 2023-05-17 20:14 -0500, Richard Laager wrote:
>> They mention, "We likely have to complete Modern C porting first to remove
>> any instances of -Wimplicit-function-declaration otherwise the redirects in
>> glibc for e.g. time->time64 won't actually work."
>> Has
On Sat, 20 May 2023 at 09:39, Cyril Brulebois wrote:>
> James Addison (2023-05-20):
> > Replying individually, but may bring this back on-list depending on
> > what I learn:
> >
> > On Sat, 20 May 2023 at 06:00, Cyril Brulebois wrote:
> > >
> > > If you're concerned about the impact of no
On 2023-05-17 20:14 -0500, Richard Laager wrote:
>
> They mention, "We likely have to complete Modern C porting first to remove
> any instances of -Wimplicit-function-declaration otherwise the redirects in
> glibc for e.g. time->time64 won't actually work."
> Has that issue been considered here?
(2-in-1 reply.)
Ansgar (2023-05-19):
> On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote:
> > Hmm. I find the netboot installer archives very useful for rescue
> > purposes. This sometimes involves PC hardware too old for amd64. I
> > PXE booted a 20+ year old laptop with no DVD/CD drive
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
> propose
On Fri, 2023-05-19 at 19:40 +0100, James Addison wrote:
> Do we know how often the i386 installer is downloaded compared to
> amd64, and could/should we start with updated messaging where those
> are provided before removing users' ability to install on their
> systems?
>
> (i386 remains the
Ansgar writes:
> On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote:
>> Hmm. I find the netboot installer archives very useful for rescue
>> purposes. This sometimes involves PC hardware too old for amd64. I PXE
>> booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD
>>
On Fri, 2023-05-19 at 20:57 +0200, Bjørn Mork wrote:
> Hmm. I find the netboot installer archives very useful for rescue
> purposes. This sometimes involves PC hardware too old for amd64. I PXE
> booted a 20+ year old laptop with no DVD/CD drive (Compaq Evo N410c - CD
> drive was part of the
Steve McIntyre writes:
> 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 therefore to ship i386 installer images
> for bookworm as normal (including bookworm point releases
On Fri, 19 May 2023 at 12:42, Steve McIntyre wrote:
>
> I'm planning on stopping publishing installer images for i386
> soon. Why? We should be strongly encouraging users to move away from
> it as a main architecture. If they're still installing i386 on 64-bit
> hardware, then that's a horrible
Am 19.05.23 um 19:23 schrieb Cyril Brulebois:
Hi,
Andrew M.A. Cater (2023-05-19):
I'd honestly suggest *just* publishing DVD1 for i386.
Netinst requires internet access: DVD1 can be used to install a basic
system without this. Scrap *everything else* for i386 installation media.
I'm not
Hi!
On Fri, 2023-05-19 at 12:42:32 +0100, Steve McIntyre wrote:
> Guillem Jover wrote:
> >On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote:
> >> > […], I'm also dubious about this, and introduces a special case
> >> > and complexity that does not seem warranted TBH. If this was the case
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 similar I guess?
>
>> i386 is in a
Am 19.05.23 um 17:30 schrieb Simon McVittie:
On Fri, 19 May 2023 at 09:19:35 -0500, G. Branden Robinson wrote:
I have to ask how someone would conduct an install to a 32-bit x86 machine
running under emulation, assuming no OS on the simulated machine.
I see four levels of support that we
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 therefore to ship i386 installer
Colin Watson wrote:
>On Fri, May 19, 2023 at 09:19:35AM -0500, G. Branden Robinson wrote:
>> Well, maybe not a strong view, but a sense of vague unease--possibly an
>> ill-informed one. As someone who has used SIMH for "real" work[1], I
>> have to ask how someone would conduct an install to a
Hi,
Andrew M.A. Cater (2023-05-19):
> I'd honestly suggest *just* publishing DVD1 for i386.
>
> Netinst requires internet access: DVD1 can be used to install a basic
> system without this. Scrap *everything else* for i386 installation media.
I'm not sure how dropping one netinst ISO is going
1 - 100 of 132 matches
Mail list logo
