Bug#975381: marked as done (Subject: libinih: drop Debian's custom vendorisation)

2021-01-31 Thread Debian Bug Tracking System
Your message dated Sun, 31 Jan 2021 21:50:26 -0600
with message-id <20210201035026.ga2361...@mosca.iiec.unam.mx>
and subject line Re: libinih: drop Debian's custom vendorisation
has caused the Debian Bug report #975381,
regarding Subject: libinih: drop Debian's custom vendorisation
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
975381: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975381
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: tech-ctte
Severity: wishlist

Currently the package libinih uses some heavy patches, which aren't upstream
and aren't used by any other distro. I'm in favor of dropping this, but the
current maintainer disagrees and we weren't able to make any progess in the
discussion, so I want to put this here. Parts of the discussion can be found on
this MR: https://salsa.debian.org/yangfl-guest/inih/-/merge_requests/2

To understand this, one has to look a bit at the history behind inih. Upstream
was designed as a static library for embedded devices, and therefore has a lot
of compile time options. At this point, the current maintainer created a patch
to make all compile time option available on runtime.

When gamemode started using inih, I wanted to get rid of shipped inih code and
upstreamed a build system to inih for a shared library, that any distro can
use. This was done in version 48. Due to the popularity of gamemode, inih is
now found in most major distros (all without Debian's patches):
https://repology.org/project/inih/versions

There is a notable "exception": inih is not in Ubuntu's main repository. This
is a bit weird because gamemode is in main, but with the shipped inih source
which got dropped from 1.6, meaning gamemode is stuck on 1.5.1 on Ubuntu. I'm
not sure why, but I suspect the heavy patches make it harder to be included in
main.

Because the library was designed for embedded use cases where every little bit
of performance matters, the runtime patch was refused upstream. Dropping the
runtime patch from Debian actually isn't problem, no reverse dependency of
libinih uses compile time options anyway. However, due to the history of inih
in Debian is has the soversion 1, while upstream is soversion 0.

I want to drop the vendorisation of Debian and start a transition to soversion
0 (which is also a reason I contact the Technical Committee, as it's not clear
how this would be done). A transition is needed anyway since dropping the patch
is a breaking change anyway. If the Technical Committee agrees to this, I would
also gladly help to maintain this package since it is 2 version behind upstream
since almost half a year and I maintain gamemode, which is directly affected by
this.

This isn't urgent, but it would be nice to get this done till bulleseye.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEu0Wws/9WG9vUXuips1tJ6l1WPv4FAl+5BWIACgkQs1tJ6l1W
Pv7dyA//QMHV+BGlUzXIMCcBlkVnYe85/TT8xH2peZTZ7j5ULBwvGGVhYG1Dt8/A
PcziDIcVLhmEN6N5r9vTispp0McTy5nNpotVgZ/5KJ1+WzRS+7D1YGXyS6YOTF7H
p4rK7PMMok8Yvjrxe/k8TRqRL6tw9+1cXRYhSBQg0TQGPTCEPh5nlWSgSOTKyHAe
ZAcpeUmLXvI0fLHiKAyxtI2nVPadWy+MFlJP4oJU1ml5+4ZUqDZ/DcC+qeHE8tSh
8oFdtG4/3REtb1e2x0LfeV45oj/MBv7X6IyWaw5vvjzLEiZHxuY8SRgMpgBzkNaC
y675orpcwNKFFkA5PdlxtGstDfzoUi70Gl8sNMNFt26w3+eX9+w/CxpgSIftHp6/
2cJRlgjfN6a2Eog9skq6XhGGoVZ1HHjq1mAtinKw9Wv0L88hd62PCzRu+ZVScGr8
MNK43VxbP2PCBMWY5z9uFlANBbgY4R4wPbKjZmH9NJW3yJDXHeKjCGfDrw3KX/5l
eIC+CbfEMuPHl02HY6TJwn0cDeEsRiyrLA+4aHrG1Vxy92L+4PPsQuJts6DzmGej
HNiyXvaSC88ovkOk2mgxtPx+dgI3qpmpMzJYqkpHg2Eo5zn12DpiubsZRHmR/1Fz
hrE4lwvV3W1DN4ztQs/Faa9zsRgPrhgEVKJMuqCwLSDeMovXCsY=
=kj7T
-END PGP SIGNATURE-
--- End Message ---
--- Begin Message ---
Hello,

The Technical Committee has decided to close this bug without further
action, because:

- While this bug reflects a difference in opinion regarding the
  packaging of libinih, said conflict does not impact Debian. The
  submitter is an Ubuntu maintainer, and –as stated in the bug report–
  it could be fixed downstream (i.e. in Ubuntu itself). We will not
  overrule a Debian Developer on issues not pertinent to Debian.

- The bug was opened by Stephan Lachnit for the Technical Committee to
  act upon on November 21, 2020. That very same day, the Debian
  Developer who maintains this package replied. Three weeks later,
  Sean Whitton asked on behalf of the Technical Committee for further
  input to better understand the issues at hand. A couple of days
  later, Andreas Metzler showed some examples where Stephan's claims
  didn't hold. We had no further input from Stephan; we cann

Bug#978636: move to merged-usr-only?

2021-01-31 Thread Elana Hashman
On Mon, Jan 25, 2021 at 11:45:55AM -0700, Sean Whitton wrote:
> Dear Technical Committee members,
> 
> I call for votes on the following ballot to resolve #978636.  The voting
> period starts immediately and lasts for up to one week, or until the
> outcome is no longer in doubt (§6.3.1).
> 
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
> 
> Until after the release of 'bullseye', any implementation of this
> resolution must be done in the 'experimental' distribution, or otherwise
> kept out of the critical paths for the release of 'bullseye'.
> 
> We do not recommend any particular implementation of the migration.
> 
> Y: Yes, support only merged-usr in the 'bookworm' release.
> N: No, continue to support both layouts in 'bookworm'.
> F: Further Discussion
> ===END

I vote:

Y > F > N

- e


signature.asc
Description: PGP signature


Bug#978636: move to merged-usr-only?

2021-01-31 Thread Gunnar Wolf
Gunnar Wolf dijo [Sun, Jan 31, 2021 at 03:32:02PM -0600]:
> My vote is:
> 
> Y > F > N


...And to be clear: We at the TC are *not* doing detailed design
work. But I want to state (and not as part of the vote, but just as
yet another DD) that the only way I feel makes sense to continue now
is via Simon's ① option: Symlinking /bin → /usr/bin, /lib → /usr/lib,
/sbin → /usr/sbin, etc.

That will allow us to take a step later on to mandate packages not
shipping files in the no-longer-root-level-directories, but that
should be at least one further release cycle down the lane.


signature.asc
Description: PGP signature


Bug#978636: move to merged-usr-only?

2021-01-31 Thread Gunnar Wolf
Sean Whitton dijo [Mon, Jan 25, 2021 at 11:45:55AM -0700]:
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
> 
> Until after the release of 'bullseye', any implementation of this
> resolution must be done in the 'experimental' distribution, or otherwise
> kept out of the critical paths for the release of 'bullseye'.
> 
> We do not recommend any particular implementation of the migration.
> 
> Y: Yes, support only merged-usr in the 'bookworm' release.
> N: No, continue to support both layouts in 'bookworm'.
> F: Further Discussion
> ===END

My vote is:

Y > F > N


signature.asc
Description: PGP signature


Bug#978636: move to merged-usr-only?

2021-01-31 Thread Niko Tyni
On Mon, Jan 25, 2021 at 11:45:55AM -0700, Sean Whitton wrote:

> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
> 
> Until after the release of 'bullseye', any implementation of this
> resolution must be done in the 'experimental' distribution, or otherwise
> kept out of the critical paths for the release of 'bullseye'.
> 
> We do not recommend any particular implementation of the migration.
> 
> Y: Yes, support only merged-usr in the 'bookworm' release.
> N: No, continue to support both layouts in 'bookworm'.
> F: Further Discussion
> ===END

I vote:

Y > F > N

-- 
Niko Tyni   nt...@debian.org


signature.asc
Description: PGP signature


Bug#975075: analogies

2021-01-31 Thread Simon McVittie
Sorry for the delay in responding to this, but I wanted to wait until
the technical question before the committee had arrived at a result
before replying to it.

On Thu, 19 Nov 2020 at 06:49:37 -0800, Felix Lechner wrote:
> In Debian, users of 'sysvinit' strike me as such a "disfavored class".

This sounds as though you're saying that Debian maintainers making
technical decisions about the packages they maintain, affecting people
who have chosen to use or contribute to Debian, are ethically or morally
equivalent to a government whose citizens have little or no choice whose
jurisdiction they live under, making laws that discriminate or persecute
on the basis of characteristics like sexuality.

I don't think that's a reasonable analogy to make, and I suspect that
members of genuinely persecuted groups would feel that it's trivializing
their situation.

I hope that wasn't your intention, but please be careful about analogies
that relate to sensitive topics.

smcv



Bug#978636: move to merged-usr-only?

2021-01-31 Thread Simon McVittie
On Mon, 25 Jan 2021 at 11:45:55 -0700, Sean Whitton wrote:
> ===BEGIN
> The Technical Committee resolves that Debian 'bookworm' should support
> only the merged-usr root filesystem layout, dropping support for the
> non-merged-usr layout.
> 
> Until after the release of 'bullseye', any implementation of this
> resolution must be done in the 'experimental' distribution, or otherwise
> kept out of the critical paths for the release of 'bullseye'.
> 
> We do not recommend any particular implementation of the migration.
> 
> Y: Yes, support only merged-usr in the 'bookworm' release.
> N: No, continue to support both layouts in 'bookworm'.
> F: Further Discussion
> ===END

I vote Y > F > N.

This is on the assumption that we are defining merged /usr the
same way we did when we resolved #914897 in

(what Guillem Jover calls "merged /usr via aliased directories", with
symlinks like /bin -> usr/bin).

smcv