On Thu, 2023-05-18 at 12:01:40 -0700, Steve Langasek wrote:
> 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:
>
> […
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: 1200 (new: 10)
Total number of packages offered up for adoption: 157 (new: 0)
Total number of packages reque
Hi,
On 5/18/23 18:08, Luca Boccassi wrote:
Without it, leaving them in place makes no difference for usrmerged
systems, and allows derived distributions that don't need usrmerge to
continue using our packages.
Not quite. Having packages only ship files under /usr (and possibly
/etc) is very
[[ debian-devel in CC, to get a wider audience regarding reStructuredText ]]
Hi,
I worked on this recently, and I have something like a prototype ready.
It can be found (as html) at
https://people.debian.org/~holgerw/release-notes_sphinx/
while the git repo containing the migration is at
https:/
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/
Thanks for the info. What is the plan for landing t
Christoph Biedl writes:
> My first idea was to check for "Using 32bit time_t in a packed
> structure", something a C compiler could warn about - assuming
> on-disk/wire format data is handled in C structs, and omitting the
> "packed" attribute should have created trouble years ago.
I'm not sure
Steve Langasek wrote...
> I don't have any inkling how widespread this problem will be nor do I see
> any path towards automatically detecting such issues (a codesearch on time_t
> would return far too many false-positives to be useful).
While I doubt there is a perfect way to auto-detect this, I
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 -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS
On 2023-05-18 07:45 -0700, Russ Allbery wrote:
>
> 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
Russ Allbery writes:
> I'm afraid the problem with INN is worse than the history and overview
> databases. The on-disk CNFS header contains time_t, so if you're using
> CNFS as your spool storage, the whole article spool becomes unreadable.
Oh, wait! No, I'm wrong, CNFS actually does something
Marco d'Itri writes:
> I do not think that inn2 is going to be a problem, because it has been
> built with --enable-largefiles for quite a few releases (and yes,
> switching was a bit traumatic for the 32 bit systems involved).
> OTOH, inn will be affected. But inn systems are small enough nowad
On May 18, Steve Langasek wrote:
> So maybe the best workaround in the short term, if there's no immediate data
> migration path, would be to change the inn2 source to use unsigned long in
> place of time_t in the data format?
I do not think that inn2 is going to be a problem, because it has been
On Thu, 18 May 2023 at 07:39, Simon Richter wrote:
>
> Hi,
>
> On 5/18/23 02:15, Sam Hartman wrote:
>
> > Helmut> I think at this point, we have quite universal consensus
> > Helmut> about the goal of moving files to their canonical location
> > Helmut> (i.e. from / to /usr) as a so
On May 17 2023, Andrea Pappacoda wrote:
> Hi all,
>
> first of all thank you for this great thread. While I could feel some tension
> while
> reading it, it's completely normal and I've learned a lot.
>
> I have a question though: if /lib64/ld-linux-x86-64.so.2 is already a symlink
> on
> non-me
14 matches
Mail list logo
