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

[Helmut Grohne]

Hi Steve,

On Tue, May 16, 2023 at 09:04:10PM -0700, 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 are
> aware, 32-bit time_t runs out of space in 2038; the exact date is now less
> than 15 years away.  It is not too early to start addressing the question of
> 32-bit architecture compatibility, as there are already reports in the wild
> of calendar failures for future events on 32-bit archs.

Thanks for not having dropped the ball on this and for the detailed
analysis.

> 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 that we proceed with it at the start of the trixie release cycle.

Can we try to distinguish affected packages into those that change their
downstream interface (i.e. mostly shared libraries changing ABI) and
those that do not (e.g. application packages)? Do I understand correctly
that those 500 mentioned earlier are the former category and the these
4900 to 6200 are the latter category?

Please bear in mind that packages are already starting to enable time64
support. coreutils is built with time64 for a while already and tar was
recently switched to time64 (see #1026204).

As such, I think it would be good to treat these categories as more
distinct. When in doubt, we should treat a package as breaking its
interface though.

> === 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=64
>   by default on 32-bit archs.  (Note that this enables LFS support, because
>   glibc’s 64-bit time_t implementation is only available with LFS also
>   turned on, to avoid a combinatorial explosion of entry points.)

There already is a pending patch for feature+time64 see #1030159. You
are asking to enable this by default effectively.

> * … 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 mentioned in
>   https://wiki.debian.org/ReleaseGoals/64bit-time.

I think this needs a second thought. coreutils and tar already enable
time64 on i386 and I expect that more things will. From my point of
view, such updates are a good thing and we should not skip them on i386,
because they do not affect ABI.

It is not as simple as this unfortunately. While coreutils and tar have
been simple, other packages will likely depend on their libraries being
time64. In such cases, we will be unable to enable time64 unless we also
the underlying libraries do so a well. Then we have maintainers (such as
Russ, but I also vaguely remember other maintainers) who want to bump
soname to unconditionally enable time64.

As a result, I expect that i386 would become a wild mixture of time64
and time32. Do you have thoughts on how to deal with the resulting mess?

I would also like to point out that there is a third option on the table
that nobody seems to be talking about. Instead of changing (breaking)
the ABI of libraries, we may also consider adding a time64 ABI to
existing libraries. A header can trivially detect whether time64 is
being requested by checking the relevant macros and in such cases divert
functions affected by time64 to 64bit-aware variants. Thus, a library
may become time64-compatible without breaking ABI with non-time64 users.
The obvious downside of this is that is quite a lot of effort and is
probably infeasible unless upstream cooperates, but I think this should
be considered as an option for difficult cases where we have both
non-lfs and time64 downstream users in large numbers. Do you agree?

> * For a small number of packages (~80) whose ABI is not sensitive to time_t
>   but IS sensitive to LFS, along with their reverse-dependencies, filter out
>   the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1]. 
>   Maintainers may choose to introduce an ABI transition for LFS, but as this
>   is not required for time_t, we should not force it as part of *this*
>   transition.  If there is a package that depends on both a time_t-sensitive
>   library and an LFS-sensitive but time_t-insensitive library, however, then
>   the LFS library will need to transition.  

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
lfs on the lower level library, but the upper one uses it with lfs by
having enabled time64. How do you intend to deal with such cases?

> * In order to not unnecessarily break compatibility with third-party (or
>   obsolete) packages on architectures where the ABI is not act

booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Helmut Grohne]

Hi,

This bootstrap aspect got me and I discussed this with a number of
people and did some research.

On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote:
> I don't think this is true? At least not in the broader sense: if you
> compile something on Debian, it will obviously get linked against
> libraries and dependencies as they are in Debian.
> Perhaps what you mean is that, given an entire separate sysroot-like
> tree, passing the appropriate compiler and linker flags and
> environment variables, you can use the local compiler we ship to build
> 'foreign' programs. That is true, but again it requires to set up the
> environment appropriately, including linker flags. And the caller
> needs to ensure the environment, including linker flags, is
> appropriate for the target environment (I guess 'host' environment, in
> GNU parlance). Therefore, I don't think it would be unreasonable to
> require that if the target environment is split-usr, then the caller
> also needs to specify an appropriate
> '-Wl,--dynamic-linker=/lib/ld-whatever' option.

Given the feedback, I am convinced that changing PT_INTERP is a stupid
idea regardless of whether it is technically feasible. There must be a
better way. Let's step back a bit.

The underlying problem here is performing the initial filesystem
bootstrap. The semantics of this are a bit vague as they are not spelled
out in policy, so we will have to derive them from implementations.

I think the major players are (in descending popularity):
 * debootstrap
 * mmdebstrap
 * cdebootstrap
 * multistrap

multistrap predates mmdebstrap and when there was no mmdebstrap, I used
it a lot. When attempting to test it, I totally couldn't convince it to
bootstrap from an unsigned or locally signed repository.  The patch in
#908451 didn't cut it. I also note that it creates a /lib64 -> /lib
symbolic link which feels quite incompatible with merged-/usr.  For
these reasons, I am dropping multistrap from the tools under
consideration and recommend removing it from the archive. If you happen
to use multistrap, now would be a good moment to tell me. Personally,
all of my use cases of multistrap have been converted to mmdebstrap and
that made a lot of things simpler.

cdebootstrap vaguely works though unsigned operation seems dysfunctional
as it runs apt-get update during cdebootstrap-helper-apt.postinst and
that fails. I happen to not have figured out why and treat this failure
as a success.

So the most popular implementations quite evidently are debootstrap and
mmdebstrap and both "just work". I note though that they work quite
differently:
 * debootstrap (depending on flags including --variant) pre-merges its
   chroot while mmdebstrap relies on packages doing it.

   I think that the question whether a distribution is merged is a
   property of the distribution and not the bootstrap tool, so I
   strongly recommend following mmdebstrap's view on this. The
   debootstrap way means that we have to include patches for every
   derivative, which is a process that does not scale well.

 * mmdebstrap operates in two phases. It first unpacks and configures a
   rather minimal set of packages and then proceeds to adding packages
   passed to --include in a second phase once essential is fully
   configured while debootstrap immediately unpacks everything.

   I think the debootstrap approach is slightly worse here, because it
   means that preinst scripts of non-essential packages cannot rely on
   essential packages having been configured.

In any case, we have to deal with both behaviours.

After this little excursion into bootstrap technology, let's go back to
the /usr-merge and its effects.

I think at this point, we have quite universal consensus about the goal
of moving files to their canonical location (i.e. from / to /usr) as a
solution to the aliasing problems while we do not have consensus on
precisely how to do this (i.e. with changing dpkg or without). If you
believe that this is not consensus, please speak up.

So in a distant future our packages will not contain any files in /bin
or /lib. In particular, this affects /bin/sh and the dynamic loader,
both of which are required to run maintainer scripts, which are
currently required for creating the symbolic links. Boom.

Solutions have been proposed to this and I think they all fall into one
of the following four categories.

 1. Don't move. We just keep those files that require a particular
location (such as /bin/sh or the dynamic loader) in their
non-canonical location. As such, maintainer scripts will be able to
run and perform the conversion to symbolic links afterwards.

 2. Move and ship links. Since we unpack all essential data.tar before
running the first maintainer script, having one package contain the
compatibility symlinks is enough to fix the problem.

 3. Move and avoid using non-canonical locations. This is the approach
where we write maintainer scripts as #!/usr/bin/sh and consider

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[G. Branden Robinson]

At 2023-05-17T11:30:36+0200, Helmut Grohne wrote:
> This bootstrap aspect got me and I discussed this with a number of
> people and did some research.

I'd like to nominate you for a Russ Allbery Award for the most useful
post to the thread.  Your attention to concrete, empirical details,
arising necessarily from practical experimentation rather than pure
cogitation, made the nature of the problems here clearly comprehensible
to me.  And if I was befogged, I'll wager other people were too.

Regards,
Branden


signature.asc
Description: PGP signature

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Marco d'Itri]

On May 17, Helmut Grohne  wrote:

> Given the feedback, I am convinced that changing PT_INTERP is a stupid
> idea regardless of whether it is technically feasible. There must be a
> better way. Let's step back a bit.
Me too, I was never persuaded.

>  4. Change the bootstrap protocol. In essence, this has been attempted
> in debootstrap by creating these symlinks prior to unpack, but no
> consensus has evolved around this approach yet. The category is
> wider though and generally requires changes to all bootstrapping
> tools.
I think that this is being dismissed too easily, mostly because the
mmdebstrap maintainer has been fighting it due to a philosophical 
preference.

> Moving on to category 4 feels rather obvious, especially because work
> has been done there in debootstrap. The approach in debootstrap however
> is one that I see as a dead end, because it causes us to maintain this
> code multiple times. It's the number of derivatives times the number of
> bootstrap tools and that doesn't scale.
But the code is trivial. It is currently more complex than it is needed 
in debootstrap only because initially it needed to support the biarch 
libc packages, but since nowadays they create the top level symlinks 
themselves then it can be made as simple as:

for dir in bin sbin lib; do
ln -s usr/"$dir" "$TARGET/$dir"
mkdir -p "$TARGET/usr/$dir"
done

Indeed, usrmerge does not have any architecture-specific knowledge 
anymore.

> https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap. In particular,
> making architecture bootstrap become chrootless would likely be a
> generic solution to this and other problems.  However, any change needs
> to propagate to a stable release in all bootstrapping tools.  Therefore
> we cannot reasonably finish the transition before forky.  This makes
Why not?

> So what's left is category 1. I looked into what the minimum set of
> files to be retained could be. To do that end, I moved everything and
> then reverted as much as was needed to make bootstrapping work.
>  * /lib64/ld-linux-x86-64.so.2 (hopefully obvious)
>  * /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 (link target)
>  * /bin/sh (hopefully obvious)
>  * /bin/dash (link target)
Interesting approach. If it is so much simple, why are you not persuaded 
that it could be a good solution until the bootstrapping tools are 
updated?

>  * /bin/bash (usrmerge runs ldd, which is a #!/bin/bash script)
>  * /bin/more (update-alternatives doesn't like its absence)
>  * /bin/cp (unless usrmerge stops hard coding its path)
These can be easily fixed, maybe the ldd issue too.

> The other major takeaway is that a significant
> chunk of the problems mentioned in this mail cannot be fixed by
> modifying dpkg only.
Agreed.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Luca Boccassi]

On Wed, 17 May 2023 at 10:31, Helmut Grohne  wrote:
>
> Hi,
>
> This bootstrap aspect got me and I discussed this with a number of
> people and did some research.
>
> On Sun, May 07, 2023 at 12:51:21PM +0100, Luca Boccassi wrote:
> > I don't think this is true? At least not in the broader sense: if you
> > compile something on Debian, it will obviously get linked against
> > libraries and dependencies as they are in Debian.
> > Perhaps what you mean is that, given an entire separate sysroot-like
> > tree, passing the appropriate compiler and linker flags and
> > environment variables, you can use the local compiler we ship to build
> > 'foreign' programs. That is true, but again it requires to set up the
> > environment appropriately, including linker flags. And the caller
> > needs to ensure the environment, including linker flags, is
> > appropriate for the target environment (I guess 'host' environment, in
> > GNU parlance). Therefore, I don't think it would be unreasonable to
> > require that if the target environment is split-usr, then the caller
> > also needs to specify an appropriate
> > '-Wl,--dynamic-linker=/lib/ld-whatever' option.
>
> Given the feedback, I am convinced that changing PT_INTERP is a stupid
> idea regardless of whether it is technically feasible. There must be a
> better way. Let's step back a bit.
>
> The underlying problem here is performing the initial filesystem
> bootstrap. The semantics of this are a bit vague as they are not spelled
> out in policy, so we will have to derive them from implementations.
>
> I think the major players are (in descending popularity):
>  * debootstrap
>  * mmdebstrap
>  * cdebootstrap
>  * multistrap
>
> multistrap predates mmdebstrap and when there was no mmdebstrap, I used
> it a lot. When attempting to test it, I totally couldn't convince it to
> bootstrap from an unsigned or locally signed repository.  The patch in
> #908451 didn't cut it. I also note that it creates a /lib64 -> /lib
> symbolic link which feels quite incompatible with merged-/usr.  For
> these reasons, I am dropping multistrap from the tools under
> consideration and recommend removing it from the archive. If you happen
> to use multistrap, now would be a good moment to tell me. Personally,
> all of my use cases of multistrap have been converted to mmdebstrap and
> that made a lot of things simpler.
>
> cdebootstrap vaguely works though unsigned operation seems dysfunctional
> as it runs apt-get update during cdebootstrap-helper-apt.postinst and
> that fails. I happen to not have figured out why and treat this failure
> as a success.
>
> So the most popular implementations quite evidently are debootstrap and
> mmdebstrap and both "just work". I note though that they work quite
> differently:
>  * debootstrap (depending on flags including --variant) pre-merges its
>chroot while mmdebstrap relies on packages doing it.
>
>I think that the question whether a distribution is merged is a
>property of the distribution and not the bootstrap tool, so I
>strongly recommend following mmdebstrap's view on this. The
>debootstrap way means that we have to include patches for every
>derivative, which is a process that does not scale well.
>
>  * mmdebstrap operates in two phases. It first unpacks and configures a
>rather minimal set of packages and then proceeds to adding packages
>passed to --include in a second phase once essential is fully
>configured while debootstrap immediately unpacks everything.
>
>I think the debootstrap approach is slightly worse here, because it
>means that preinst scripts of non-essential packages cannot rely on
>essential packages having been configured.
>
> In any case, we have to deal with both behaviours.
>
> After this little excursion into bootstrap technology, let's go back to
> the /usr-merge and its effects.
>
> I think at this point, we have quite universal consensus about the goal
> of moving files to their canonical location (i.e. from / to /usr) as a
> solution to the aliasing problems while we do not have consensus on
> precisely how to do this (i.e. with changing dpkg or without). If you
> believe that this is not consensus, please speak up.
>
> So in a distant future our packages will not contain any files in /bin
> or /lib. In particular, this affects /bin/sh and the dynamic loader,
> both of which are required to run maintainer scripts, which are
> currently required for creating the symbolic links. Boom.
>
> Solutions have been proposed to this and I think they all fall into one
> of the following four categories.
>
>  1. Don't move. We just keep those files that require a particular
> location (such as /bin/sh or the dynamic loader) in their
> non-canonical location. As such, maintainer scripts will be able to
> run and perform the conversion to symbolic links afterwards.
>
>  2. Move and ship links. Since we unpack all essential data.tar before
> running the first maintainer scr

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Andrea Pappacoda]

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-merged-/usr systems, pointing to 
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2, why would it be an issue to 
have /lib64/ld-linux-x86-64.so.2 point to 
/usr/lib64/ld-linux-x86-64.so.2? Why do we want binaries to look for 
the loader in /usr/lib64/ld-linux-x86-64.so.2 if that would still be a 
symlink to /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2?


Sorry in advance if this sounds like a dumb question, and thanks again 
for your involvement in all of this!

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Jeremy Stanley]

On 2023-05-16 17:05:25 -0700 (-0700), Russ Allbery wrote:
[...]
> Well, believe what you believe, but I literally do that daily, as
> does anyone else who regularly uses software from a Rust or Go
> ecosystem.  Not a single work day goes by without me running, on
> some random Ubuntu or Red Hat or Debian system, binaries that were
> compiled on some random other Linux distribution (often I have no
> idea which one).
[...]

Throwing another common one on the heap, similar to the previous
Steam example, Python wheels with compiled extensions are often
distributed on PyPI for a fictional "manylinux" platform which
indicates they're intended to be usable on most GNU/Linux
distributions (though in their case, they compile on ~ancient RHEL
versions to achieve that). One way that manulinux wheels are less
like Rust or Go is that they typically don't use static compilation,
but rather vendor in additional dynamically-linked libs which are
unlikely to be present on the target installations.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

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

[Craig Small]

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 are
> aware, 32-bit time_t runs out of space in 2038; the exact date is now less
> than 15 years away.  It is not too early to start addressing the question
> of
> 32-bit architecture compatibility, as there are already reports in the wild
> of calendar failures for future events on 32-bit archs.
>
Hi Steve,
  Have they also considered the same issue with utmp?

https://github.com/thkukuk/utmpx/blob/main/Y2038.md

Some of it is reasonably easy to fix by changing the utmp-related calls
with the systemd equivalents, but not all fields are available.

 - Craig

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Russ Allbery]

Jeremy Stanley  writes:

> Throwing another common one on the heap, similar to the previous Steam
> example, Python wheels with compiled extensions are often distributed on
> PyPI for a fictional "manylinux" platform which indicates they're
> intended to be usable on most GNU/Linux distributions (though in their
> case, they compile on ~ancient RHEL versions to achieve that). One way
> that manulinux wheels are less like Rust or Go is that they typically
> don't use static compilation, but rather vendor in additional
> dynamically-linked libs which are unlikely to be present on the target
> installations.

Yeah, I've not been digging too deeply into cases like this since they
wouldn't be affected by the original proposal that started this off (it
wouldn't change binaries compiled with normal Debian tools or change what
ABI Debian can execute), but if we move into the more general question of
"does anyone care about building binaries on one Linux system and running
them on another," I think there are quite a lot of examples.

Another one just from the Python world is conda, which provides a parallel
set of pre-compiled libraries in addition to the Python modules and
expects to be able to install and run them on arbitrary systems outside of
a chroot or container, just by manipulating the dynamic loader search
path.  Conda is very widely used in scientific computing, where a lot of
use cases require Python libraries with substantial underlying C library
components that often do not have compatible or sufficiently optimized
versions packaged for the underlying distribution.

There are also, obviously, non-free software use cases galore, including I
suspect some in the Debian non-free archive, where binaries built on other
Linux distributions are being run on Debian systems.  I remember, in a
previous job, changing a few files in /etc to convince the Oracle
installer that a Debian system was actually a Red Hat system so that it
would run, and the resulting binaries then worked fine (and it would have
been a huge problem for us if they hadn't).  I think Oracle subsequently
added more support for Debian, or at least Ubuntu, but I'm sure there are
other cases like that still around today.

-- 
Russ Allbery (r...@debian.org)  

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

[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 are
> > aware, 32-bit time_t runs out of space in 2038; the exact date is now less
> > than 15 years away.  It is not too early to start addressing the question
> > of
> > 32-bit architecture compatibility, as there are already reports in the wild
> > of calendar failures for future events on 32-bit archs.

> Hi Steve,
>   Have they also considered the same issue with utmp?

> https://github.com/thkukuk/utmpx/blob/main/Y2038.md

> Some of it is reasonably easy to fix by changing the utmp-related calls
> with the systemd equivalents, but not all fields are available.

This isn't something that's specifically come up.  I think there's general
recognition that there will be other software that needs to be fixed in ways
not addressed by simply turning on -D_TIME_BITS=64.  I'm currently
restricting my focus to the latter, since it's the part that will require
distro-wide coordination.

Thanks,
-- 
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 vor...@debian.org


signature.asc
Description: PGP signature

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

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 solution to the aliasing problems
Helmut> while we do not have consensus on precisely how to do this
Helmut> (i.e. with changing dpkg or without). If you believe that
Helmut> this is not consensus, please speak up.

I agree we have strong consensus that we want to move files to their
canonical locations.

I'm not entirely sure I'd agree that we have consensus that's our
solution to the aliasing problem.
there are other competing reasons why we might want to move files to
their canonical locations.

If for example we accomplish the move to canonical locations by changing
dpkg, we might well get some form of aliasing support in dpkg.

This mostly doesn't matter.
If we're going to move files to their canonical location, it doesn't
matter much why.
There is one potential area where it might.

If the reason for preferring one bootstrap protocol over another depends
on why we're moving files to their canonical locations, I think we'd
need to dig into that very carefully and examine that part of your
consensus call a bit more.


signature.asc
Description: PGP signature

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> Moving on to category 4 feels rather obvious, especially
Helmut> because work has been done there in debootstrap. The
Helmut> approach in debootstrap however is one that I see as a dead
Helmut> end, because it causes us to maintain this code multiple
Helmut> times. It's the number of derivatives times the number of
Helmut> bootstrap tools and that doesn't scale.

Like others, I don't find this analysis compelling.
I'd like to better understand why the number of derivatives is in the
cross product.
I suspect most derivatives are going to move to merged /usr, and so I
suspect most if not all derivatives can be treated the same.

What am I missing?


signature.asc
Description: PGP signature

Bug#1036226: ITP: libe131 -- library for the E1.31 (sACN) protocol

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-devel@lists.debian.org, matthias.geiger1...@tutanota.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libe131
  Version : 1.4.0
  Upstream Contact: Hugo Hromic 
* URL : https://github.com/hhromic/libe131.git
* License : Apache-2.0
  Programming Lang: C
  Description : library for the  E1.31 (sACN) protocol

I intend to package libe131. It's one of the libraries needed to 
devendor Openrgb. Fron the description: 

>This is a lightweight C/C++ library that provides a simple API for packet, 
> client and server programming to be used for communicating with devices
> implementing the E1.31 (sACN) protocol. 

This protocol is appearantly used to control lighting devices.

The packaging is already done and can be viewed at 
https://salsa.debian.org/debian/libe131.

I'd need a sponsor for the initial upload.

regards,

werdahias

-BEGIN PGP SIGNATURE-

iQJUBAEBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmRlElkgHG1hdHRoaWFz
LmdlaWdlcjEwMjRAdHV0YW5vdGEuZGUACgkQGL0QaztsVHWYRhAArw/wFDMZ+5cw
UenwvAYy3Qnx5GRsnARooxAtF6yRUW3i/U06XnMSh06LAosqUItdqgWi+7hJuLlD
a50ZqSu4MrfSkFT3pCSTDXn9a6hmOBVSKaMTB8TCaUmFUV5tuF1f4rvMq7bXC61r
zbRsZYexWxeOafqSxC4AhiCEpD/SnnN0IGoQceVRD63jOxnNtAFXx88sQiQZu/he
6gvI4dEONXrtLS7LaK/+lIGSmX2tEmz5SMEJuvKJnxSso7WKZYbLblzMmhCp2Wti
oXsNr2uQL5z8zkdH4XzTohshB8jn7jjKDaAujPj/58D++GwiS8levmU+6TjXf7HR
IQwCv6yZ1tbcu1cYywHWjTbC0YwimBY6y8J7Jw8O63jWEzDj3sHroyCfXdrXPlj2
wxSTcvMzCvSWtoIFM0O51CKyGimh3935x7jsZmWg0VZOsEKWYmPD96DQ8ONFxAF/
brQaTZeH+Cr1F33pRpX3yXofEs7qJHwsbQcOKnHI6p8dqdQQzA8C91m0jby+Gz5D
WsmAEjfzHwkKWppjmRtKCz4kvL6cnnYgioS1caxGH8NiLN/Zbvi1RfZKV4oR18zZ
3ZBJ7AQBG0g5fdd3TvVi/nyC//MnAStz2ut3PooQgB9lXdchYjrG1Lj5eoRTIoIn
iHr2LFIuNIFhvopq0oE8jaznHRYuKQk=
=/256
-END PGP SIGNATURE-

Bug#1036236: ITP: cityhash -- hashing functions for strings

[Matthias Geiger]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-devel@lists.debian.org, t...@debian.org, 
matthias.geiger1...@tutanota.de

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: cityhash
  Version : git snapshot
  Upstream Contact: Jyrki Alakuijala 
* URL : https://github.com/google/cityhash
* License : MIT
  Programming Lang: C++
  Description : hashing functions for strings

I intend to package cityhash. It's a library providing hashing functions fot 
strings.  The functions mix the
input bits thoroughly but are not suitable for cryptography. 
 This library is needed to fully devondor ppsspp. The packaging is already done 
and can be viewed at https://salsa.debian.org/debian/cityhash.
tar kindly agreed to sponsor the intial upload.

regrads,

werdahias

-BEGIN PGP SIGNATURE-

iQJUBAEBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmRlMrAgHG1hdHRoaWFz
LmdlaWdlcjEwMjRAdHV0YW5vdGEuZGUACgkQGL0QaztsVHXRNw/+Nrs52V66Y4O8
OicclBomJl+Om2+U924PQnAst4VBBW3OH2bSOZkCyZBtu/zFgbFpmQGdL4vcmu5Q
d7S9OpOmagmvy8fJumiPetmuD0VLCcN/nIxVAyG0enFeXX9ZG1Ti2Onlyhkl1mKD
E8zowrpwsLC3P3Zj5Zr/s5zW7XbnWvApCbL1Iv372eTbeneUQ2nXsoq0qjHX3RAg
CoIo/qq0oy54Y0HHGdoABjheLH7I5rl25DXVRK0ausHrAszz5wJBYEO6OHoQ4u3i
RXDjJbv+zLeHTMFB6kB00nLAhnVd8I5WVLAu7WWHCPjgmopRjxI9XUW/E9GB5ZMh
ZQlW8zOBrWlQx7EtzZRKuMKJiRluQpkuewzNwdmz9I99O50lB28lxDiKP5qngSOS
lcMs/mZasXBwpEJyPgmwmj64XbIeq3TsTKqARdbTT5RVmzGZE4n74PE7+GUKiuWz
X+i7Jbwx8Kyp1XNUM+FRZQ9JolCO2RgNsb5+tyRRJafkNRtNIQZON+N83hayYjGI
LXlAI+qIXQK01YFNctqf76T1crRywmo/sOqd+dDfGkUekWD/ohy8IUCpc4hkOaYs
ib4HHFdlANwwjRIAs6Z+eRABiQ73A9EBSISOODpEwTcDxILzjY7J6nNUbZmNSm6V
HwVAAv/VIE0MR2Q1W1N1fMPBQpAU7Z0=
=RM/7
-END PGP SIGNATURE-

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Roger Lynn]

On 15/05/2023 19:00, Simon McVittie wrote:
> On Sun, 14 May 2023 at 23:37:34 +0200, Josh Triplett wrote:
>> People build things on Debian that are not Debian packages. People
>> compile binaries on Debian, and expect them to work on any system that
>> has sufficiently new libraries.
> 
> *raises hand*
> 
> Hello, I represent an example of those people. With my $work hat on,
> I'm involved in maintaining a family of Debian derivatives (the Steam
> Runtime) that is used to run Steam games on arbitrary distributions,
> including but not limited to Debian. Some of these binaries are built
> on a Debian derivative, but run on an arbitrary other distribution,
> using a RPATH[1] to find their non-glibc dependencies.

As another much smaller example, which I hope is still relevant, I have
taken binaries from Debian stable or oldstable armel and run them for
diagnostic purposes on embedded boards which only have Busybox installed and
for which I don't have a convenient build environment.

Regards,
Roger

PS Apologies if I've followed up incorrectly - I read debian-devel through
an NNTP gateway. - And I screwed up the reply so Simon and the bug got a
different copy.

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Luca Boccassi]

On Wed, 17 May 2023 at 01:05, Russ Allbery  wrote:
>
> Luca Boccassi  writes:
>
> > It does say something interesting. When we started, the assertion was
> > that packages not relying on the symlink being present was fundamental
> > for portability and cross-compatibility. Then, it shrinked to
> > portability and cross-compatibility of a subset of packages. Now it
> > further shrank to portability and cross-compatibility of a subset of
> > packages of a subset of vintages.
>
> I think it's pretty clear that I'm totally failing to communicate what I
> was getting at with this example and the process is becoming incredibly
> frustrating, so I'm going to stop trying here.
>
> > But does it really work, or do we just hope it does? I personally see a
> > great deal of signals that say it doesn't. For one, in 2023, "build one
> > binary and run it everywhere" doesn't really seem to me to be the
> > principal choice in terms of portability.
>
> Well, believe what you believe, but I literally do that daily, as does
> anyone else who regularly uses software from a Rust or Go ecosystem.  Not
> a single work day goes by without me running, on some random Ubuntu or Red
> Hat or Debian system, binaries that were compiled on some random other
> Linux distribution (often I have no idea which one).
>
> > It might have been once, and there might be a number of relevant use
> > cases still, but it seems to me the industry has largely gone in a very
> > different direction nowadays.
>
> I do think the industry is moving away (well, has already moved away) from
> Linux Standards Base pre-compiled C binaries without wrappers like snap or
> flatpak, although there are some very notable exceptions, such as Steam's
> special use cases explained elsewhere on the thread.  I don't believe the
> industry is moving away from Go and Rust binaries, so this is, I think, a
> more complicated picture than your description indicates.

I know absolutely nothing about Go, and preciously little about Rust,
but my understanding from news article and so on was that both of
those ecosystems pretty openly avoid "traditional" distributions, in
favour of their own self-contained ecosystems. So would that use case
be affected, even by an hypothetical and at this point extremely
unlikely archive-wide change? Meaning, are those randomly compiled
Go/Rust binaries you run for work taken from the Debian archive, or
locally/externally/self compiled? I do know we do ship a number of
those, although I am very oblivious to the number and nature of that
subset. And conversely, if the hypothetical change was just to the
essential set, I assume there's no Go/Rust there, right?

> > Not everything of course, but wouldn't it be worth it to specify core
> > items such as cross-compatibility requirements? Not in terms of
> > implementation details, but in terms of what the goals and the minimum
> > expectations are. There are obviously some, and they are obviously of
> > great importance to many, and yet to me it feels like they shift every
> > time I ask a different question.
>
> I am certainly never going to say no to more maintained documentation.
> That would be great.  If you're feeling motivated and you're willing to
> really listen to what people are saying and accept and understand a lot of
> ambiguity and a lot of assumptions that don't match your assumptions, go
> for it!
>
> I personally am not even doing justice to Policy in its existing scope, so
> this isn't something I will personally be tackling.  Honestly, I should
> have spent all of the time I spent on this thread working on Policy
> instead.  :)

Sure, I can add that to my todo list. But I have already two policy
items open for review, so certainly won't get to it before those are
sorted, hint hint :-)
(probably it would have been best not to mention it, lol)

> > But if you prefer to focus on first principles, that's great! I've been
> > asking this a lot: is cross-distribution harmonization a core
> > requirement? Is it important enough to trump other goals and
> > distro-local benefits? If so, isn't it worth to discuss it and then
> > pencil it down?
>
> I think some parts of it are a core requirement.  It would be very
> surprising, and very bad, if we couldn't run Go and Rust binaries built on
> another distribution, for example, or if Go or Rust binaries built on
> Debian couldn't be used on other distributions, both subject to the normal
> constraints of glibc cross-compatibility that everyone building binaries
> already knows about.  I think other parts of it are not a core
> requirement, but still something that is nice to have and that we
> shouldn't break without a really good reason.
>
> I think the specific details of the Linux Standards Base process mostly
> didn't turn into something the Linux world wanted to support going
> forward, and thus LSB harmonization, while an interesting idea, is no
> longer a requirement in general.  However, we still follow some pieces of
> it that wer

Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Russ Allbery]

Luca Boccassi  writes:
> On Wed, 17 May 2023 at 01:05, Russ Allbery  wrote:

>> I do think the industry is moving away (well, has already moved away)
>> from Linux Standards Base pre-compiled C binaries without wrappers like
>> snap or flatpak, although there are some very notable exceptions, such
>> as Steam's special use cases explained elsewhere on the thread.  I
>> don't believe the industry is moving away from Go and Rust binaries, so
>> this is, I think, a more complicated picture than your description
>> indicates.

> I know absolutely nothing about Go, and preciously little about Rust,
> but my understanding from news article and so on was that both of those
> ecosystems pretty openly avoid "traditional" distributions, in favour of
> their own self-contained ecosystems.

I think apt-cache search will show that's a significant overstatement and
quite a lot of Go and Rust code is packaged for Debian.  Lots of Debian
maintainers put a lot of hard work into that.

> So would that use case be affected, even by an hypothetical and at this
> point extremely unlikely archive-wide change?

If we only modified specific core packages to use a different PT_INTERP,
obviously only those packages would be affected and execution of general
Go and Rust binaries would not be affected.  I suspect none of those core
packages today are Go or Rust.  (I do think it's likely that we'll have
critical bootstrapping packages written in Rust within the next decade,
though.)

If all Debian packages were built with a different PT_INTERP but the
toolchain itself was not modified, then Go and Rust binaries packaged for
Debian could not be copied to and run on non-Debian Linux systems (unless
it happened to work by accident because those Linux systems were also
/usr-merged and thus the non-canonical PT_INTERP also was present on those
systems).  This would be unfortunate and surprising and I'm sure that it
would break use cases that currently work, but it probably wouldn't be
catastrophic.  Still, it would obviously be a regression.

If the toolchain shipped with Debian were modified to build binaries with
a different PT_INTERP, then Go and Rust binaries built with that toolchain
would not work on other Linux distributions.  If every other major Linux
distribution were /usr-merged and thus the modified PT_INTERP worked
somewhat by accident on most other distributions, this likewise would
still break some things for some people, but similar to the previous point
it would be a regression but probably wouldn't be catastrophic.  It would
be more serious than the previous problem, though, since now we're
affecting user-built binaries and not just packaged binaries.  Many more
of those will be built with the intent to copy them to other systems.

If changes caused Go and Rust binaries built on Debian to not work on
numerous major non-Debian Linux distributions, I would consider that a
serious release-critical bug.  But that doesn't seem all that likely from
this specific change assuming that the modified PT_INTERP would also be
present on other major Linux distributions such as Red Hat, Fedora, SuSE,
Arch, Gentoo, etc.  I am *assuming* those are all /usr-merging, and thus
it might be, but I have not tracked this and do not know if that's true.

-- 
Russ Allbery (r...@debian.org)  

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

[Guillem Jover]

Hi!

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=64
>   by default on 32-bit archs.  (Note that this enables LFS support, because
>   glibc’s 64-bit time_t implementation is only available with LFS also
>   turned on, to avoid a combinatorial explosion of entry points.)

As has been mentioned, there's future=+time64 support in dpkg git HEAD
targeted at 1.22.0. This gets automatically disabled on ports where
time_t is known to be 64-bits (even if the port is 32-bits). When time64
is set it does indeed force future=+lfs. (But I've got locally a few
commits fixing and improving the logic for some of the ports which
will push out in a bit.)

I'm perhaps missing something, but the ordering here seems wrong/odd?
Enabling this by default globally before the shared libraries affected
by the ABI have been handled seems to me would mean a mess of ABIs
in unstable until the entire thing converges?

> * … 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 mentioned in
>   https://wiki.debian.org/ReleaseGoals/64bit-time.

Like Russ, I'm also dubious about this, and introduces a special case
and complexity that does not seem warranted TBH. If this was the case it
would seem to me it would disallow SOVERSION bumps for example, which we
have never been concerned with.

> * For a small number of packages (~80) whose ABI is not sensitive to time_t
>   but IS sensitive to LFS, along with their reverse-dependencies, filter out
>   the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1]. 
>   Maintainers may choose to introduce an ABI transition for LFS, but as this
>   is not required for time_t, we should not force it as part of *this*
>   transition.  If there is a package that depends on both a time_t-sensitive
>   library and an LFS-sensitive but time_t-insensitive library, however, then
>   the LFS library will need to transition.  

Hmm, I'm not sure whether I'm not understanding this point. Perhaps it
is assuming that future=-lfs will strip the LFS options from the
emitted flags? (If so that only disables the feature, but does no
stripping). Also as mentioned above when the +time64 feature is enabled
an -lfs would not be effective at all anyway, and should not! Because if
the time64 flags are emitted glibc will error out if the LFS ones are
not set. (See .)

So perhaps this means to say that in these cases we'd use:

  DEB_BUILD_MAINT_OPTIONS=future=-time64

?

> * In order to not unnecessarily break compatibility with third-party (or
>   obsolete) packages on architectures where the ABI is not actually
>   changing, on 64-bit archs + i386, emit a Provides/Replaces/Breaks of the
>   old library package name.  A sample implementation of the necessary
>   packaging changes is at
>   https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/time-t-me.

I appreciate the desire to reduce inflicting these effects on arches
that are not affected, but I don't _think_ (or do not recall) we have
ever done this kind of special casing when doing similar ABI changing
transitions in the past? And while ports have clearly arch-specific
divergences when it comes to dependencies, it seems to me this would
create a divide at a very different scale? Say for upgrade paths and
similar testing.

Personally, I'm not sure I'd be thrilled to add that kind of code to
packages I maintain. :)

> [1] Seeing that the future is now, maybe we want to consider changing the
> canonical name for this from future=-lfs to abi=-lfs?  Bikeshed at will!

Well, we are still not done with LFS, and I'm not seeing the end of that,
so it seemed appropriate at the time, and it kind of still does. :) The
«abi» name seems nice in that it conveys more clearly than «future» that
this can break the ABI (although not necessarily so), but in this case
it's probably better to err on the scarier meaning. So I'll check what
it would take to introduce an alias for that and ponder about it as
there's of course the danger of added confusion. But thanks for the
suggestion!

Thanks,
Guillem

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

[Richard Laager]

I support transitioning to 64-bit time_t. Thank you for taking this on!


Gentoo has a similar migration:
https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration

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." That 
links to:

https://inbox.sourceware.org/libc-alpha/874js2iqlg@oldenburg.str.redhat.com/

Has that issue been considered here? (I can't speak intelligently on it 
at this time. I just want to make sure it's on your radar.)



On 2023-05-16 23:04, Steve Langasek wrote:

* For a small number of packages (~80) whose ABI is not sensitive to time_t
   but IS sensitive to LFS, along with their reverse-dependencies, filter out
   the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1].
   Maintainers may choose to introduce an ABI transition for LFS, but as this
   is not required for time_t, we should not force it as part of*this*
   transition.


My gut feeling is that this is a mistake. I think Debian should just 
bite the bullet and force the LFS transition too.


First off, it seems that would simplify the planning, as you don't need 
to determine "[i]f there is a package that depends on both a 
time_t-sensitive library and an LFS-sensitive but time_t-insensitive 
library". Furthermore, that state could change in the future. In other 
words, someone could upload a new package that meets that criteria, 
which would then force a library to transition at that point. But would 
that requirement to transition get noticed, or would we end up with 
subtle breakage?


Also, how many separate times would someone have to do those LFS 
transitions vs just doing it all now in one shot?


I know it's not my place to volunteer you/others to do more work. But I 
worry about doing something half-way rather than just pulling the thread 
now. Doubly so since it's a relatively small set of additional packages 
compared to the size of the rest of the transition already being planned.



Back to time_t...

Application-level workarounds can complicate things...

Upstream NTPsec and gpsd had some conversations about the optional 
64-bit time_t. They (and other projects) can have a shared-memory 
connection where the size and layout of the struct varies depending on 
sizeof(time_t). The glibc optional 64-bit time_t makes that complicated, 
as it's possible for the two applications to be mismatched.


The conclusion we came to (which has been implemented in gpsd, but has 
not yet been implemented in NTPsec) is to split the time_t and put the 
high bits into a spot that was reserved/padding, but only in the case 
where we have optional 64-bit time_t and 32-bit ints. This provides 
compatibility between modified and unmodified applications until 2038, 
and modified applications work together thereafter. If you're curious, 
the relevant subthread is:

https://www.mail-archive.com/devel@ntpsec.org/msg09645.html

With the Debian transition, we could end up with a mismatch where one 
side (gpsd) is sized with 32-bit fields and doing the split thing and 
the other (NTPsec) will be sized with 64-bit time_t, which is 
incompatible. Whether that happens is dependent on how exactly the 
applications implement the check to decide to do the split thing. I've 
raised that question on the gpsd bug:

https://gitlab.com/gpsd/gpsd/-/issues/152#note_1395291465

There are certainly solutions to that. In no way am I suggesting that 
should block the transition. By all means, transition and we will sort 
things out.


--
Richard



OpenPGP_signature
Description: OpenPGP digital signature

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

[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 different suffix (c102, c2, ldbl, g…), drop
> >   it at this time.

> This is possibly me being too fiddly (and also I'm not 100% sure that I'll
> get to this in time), but ideally I'd like to do an upstream SONAME
> transition for one of my shared libraries (and probably will go ahead and
> change it for i386 as well, since I'm dubious of the need to run old
> binaries with new libraries in this specific case).

> What's the best way for me to do that such that I won't interfere with the
> more automated general transition?  Will you somehow automatically detect
> packages that have already been transitioned?  Or should I wait until the
> package has been automatically transitioned and *then* do an upstream
> transition?

It would be possible to automatically detect that a package has been
transitioned, by a combination of:

- checking the date of the last source upload (if it's after dpkg-buildflags
  defaults have changed, or not)
- inspecting the symbols referenced from glibc by the library to confirm
  whether it includes any 64-bit time_t variants

It's doable, but I think it would be rather a lot of work for an edge case
where the maintainers could simply revert the NMU if they determined it was
unnecessary.

> > Your thoughts?

> The one additional wrinkle is that there are packages that, due to
> historical error or unfortunate design choices, have on-disk data files
> that also encode the width of time_t.  (I know of inn2, which is partly my
> fault, but presumably there are more.)  Rebuilding that package with the
> 64-bit time_t flags would essentially introduce an RC bug (data loss)
> because it will treat its existing data files as corrupt.  Do you have any
> idea how to deal with this case?

> (The LFS transition was kind of a mess and essentially required users to
> do manual data migration.  This time around, maybe we'll manage to write a
> conversion program in time.)

INN is called out on https://wiki.debian.org/ReleaseGoals/64bit-time.
Unfortunately, I know it depends on at least one library package that has an
ABI change (libpam0g), though it happens that only libpam_misc, which INN
doesn't link to, has an ABI change; so we could adjust that source package
to not do the time_t switch if that's the only blocker.  But it also
build-depends on libkrb5-dev and libssl-dev, both of which are affected by
time_t.

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 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).  It really depends
on maintainers knowing what the code in their packages does.

-- 
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 vor...@debian.org


signature.asc
Description: PGP signature

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

[Steve Langasek]

Hi Helmut,

On Wed, May 17, 2023 at 08:31:13AM +0200, Helmut Grohne 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 that we proceed with it at the start of the trixie release cycle.

> Can we try to distinguish affected packages into those that change their
> downstream interface (i.e. mostly shared libraries changing ABI) and
> those that do not (e.g. application packages)? Do I understand correctly
> that those 500 mentioned earlier are the former category and the these
> 4900 to 6200 are the latter category?

Yes, those are the categories in question.  The 500-600 library packages
expose time_t as part of their ABI; the other packages are those that
build-depend on those libraries and therefore will need no-change rebuilds
to remain compatible.

> Please bear in mind that packages are already starting to enable time64
> support. coreutils is built with time64 for a while already and tar was
> recently switched to time64 (see #1026204).

> As such, I think it would be good to treat these categories as more
> distinct. When in doubt, we should treat a package as breaking its
> interface though.

Packages that have opted in to 64-bit time_t upstream without it being set
in dpkg-buildflags are de facto out of scope for this transition.

> > === 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=64
> >   by default on 32-bit archs.  (Note that this enables LFS support, because
> >   glibc’s 64-bit time_t implementation is only available with LFS also
> >   turned on, to avoid a combinatorial explosion of entry points.)

> There already is a pending patch for feature+time64 see #1030159. You
> are asking to enable this by default effectively.

Thanks, good to know this is in progress.  Yes, this would need to be
enabled by default for the migration.

> > * … 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
> >   mentioned in https://wiki.debian.org/ReleaseGoals/64bit-time.

> I think this needs a second thought. coreutils and tar already enable
> time64 on i386 and I expect that more things will. From my point of
> view, such updates are a good thing and we should not skip them on i386,
> because they do not affect ABI.

Sure, that's fine, but those would necessarily be taken case-by-case and
don't argue for -D_TIME_BITS=64 by default on i386, since that would
extensively break library ABIs depended on by legacy software.

> It is not as simple as this unfortunately. While coreutils and tar have
> been simple, other packages will likely depend on their libraries being
> time64. In such cases, we will be unable to enable time64 unless we also
> the underlying libraries do so a well.

Still, should be handled case-by-case?

> Then we have maintainers (such as Russ, but I also vaguely remember other
> maintainers) who want to bump soname to unconditionally enable time64.

Well, that's their prerogative, and presumably as upstream they know whether
the library is of relevance to legacy i386 binaries.  The good news is,
since it is an upstream SONAME change, if there IS a need to provide the old
ABI on i386, this could be done as a separate source package shipping the
old binary package name.  In which case, the packaging is still simplified
overall if i386 does not set -D_TIME_BITS=64 by default.

> As a result, I expect that i386 would become a wild mixture of time64
> and time32. Do you have thoughts on how to deal with the resulting mess?

As the person who was responsible for killing off i386 in Ubuntu as a host
architecture, I may not be the best person to ask about a mess that only
occurs from continuing to use i386 as a host architecture in Debian, unless
you want the same answer ;)

In practice though, I don't think we're going to see a huge amount of work
from upstreams to enable 64-bit time_t.  coreutils and tar are software
whose core functionality deals with files and their timestamps; there's very
little other software that falls in this category, and of the other software
that does, I expect there to be very VERY little software with significant
library dependencies.

So in effect, my position would be "wait and see, and deal with complexities
as they occur".

> I would also like to point out that there is a third option on the table
> that nobody seems to be talking about. Instead of changing (breaking)
> the ABI of libraries, we may also consider adding a time64 ABI to
> existing libraries. A header can trivially detect whether time64 is
> being requested by checking the relevant macros and in such cases divert
> func

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

[Steve Langasek]

On Wed, May 17, 2023 at 08:14:52PM -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." That links to:
> https://inbox.sourceware.org/libc-alpha/874js2iqlg@oldenburg.str.redhat.com/

> Has that issue been considered here? (I can't speak intelligently on it at
> this time. I just want to make sure it's on your radar.)

Thanks, I was unaware of this.  Sounds like feature=+time64 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   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: booststrapping /usr-merged systems (was: Re: DEP 17: Improve support for directory aliasing in dpkg)

[Simon Richter]

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 solution to the aliasing problems
 Helmut> while we do not have consensus on precisely how to do this
 Helmut> (i.e. with changing dpkg or without). If you believe that
 Helmut> this is not consensus, please speak up.



I agree we have strong consensus that we want to move files to their
canonical locations.



I'm not entirely sure I'd agree that we have consensus that's our
solution to the aliasing problem.


It's the other way around: moving the files as a solution to the 
aliasing problem is the strongest argument in favour of moving the files 
inside the packages.


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.



If for example we accomplish the move to canonical locations by changing
dpkg, we might well get some form of aliasing support in dpkg.


IMO, that is still the preferred solution:

 - it is actually safe, because dpkg knows what is going on and can 
reject conflicting changes
 - there is no guarantee that usrmerge will be permanent or the last 
transition of this kind

 - it also solves the bootstrap problem

   Simon