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.
> Presumab
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 Li
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 digit
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?
> 2a.
The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.
Total number of orphaned packages: 1204 (new: 1)
Total number of packages offered up for adoption: 155 (new: 0)
Total number of packages reques
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:
https://wiki
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:
>
> T
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 vi
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 find
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
> compatibilit
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
Package: wnpp
Severity: wishlist
Owner: Stephen Kitt
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: pycrc
Version : 0.10.0
Upstream Author : Thomas Pircher
* URL : https://pycrc.org
* License : MIT
Programming Lang: Python
Description : CR
On Thu, 8 Jun 2023 at 09:46, Raphael Hertzog wrote:
>
> Hi,
>
> On Wed, 17 May 2023, Helmut Grohne wrote:
> > For completeness sake, there is one more entry in category 3: We can run
> > the dynamic loader from its canonical location explicitly, so we'd
> > modify maintainer scripts to start with:
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 bi
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 bi
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. :)
Hi,
On Wed, 17 May 2023, Helmut Grohne wrote:
> For completeness sake, there is one more entry in category 3: We can run
> the dynamic loader from its canonical location explicitly, so we'd
> modify maintainer scripts to start with:
>
> #!/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/bi
> 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 vi
19 matches
Mail list logo
