Re: Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Simon Richter]

Hi

On 2/29/24 14:57, Steve Langasek wrote:


Furthermore, this is a downgrade from a replacing package to a replaced
package. Unless you also --reinstall the package at the end, missing files
are quite to be expected.


I wonder if this could be improved -- e.g. by ignoring Replaces: 
relationships from about-to-be-removed packages.


   Simon

Re: Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Steve Langasek]

On Thu, Feb 29, 2024 at 06:53:56AM +0100, Paul Gevers wrote:
> On 29-02-2024 4:47 a.m., Christoph Anton Mitterer wrote:
> > @d-d:
> > - How can it happen that purge *t64 packages and at the same time install
> >the previous package, and then the so file is missing?
> >I mean it's clear that they use the same name, but shouldn't DPKG handle
> >the cleanly?

> Well, officially downgrading isn't supported (although it typically works)
> *and* losing files is one of the problems of our merged-/usr solution (see
> [1]). I *suspect* this might be the cause. We're working hard (well, helmut
> is) to protect us and our users from loosing files on upgrades. We don't
> protect against downgrades.

> Obviously there might be issues, but you are running unstable *during* a
> transition. You have to expect some troubles. Thanks for the information,
> let's see if this is a real issue or not.

Furthermore, this is a downgrade from a replacing package to a replaced
package. Unless you also --reinstall the package at the end, missing files
are quite to be expected.

-- 
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: Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Paul Gevers]

Hi,

On 29-02-2024 4:47 a.m., Christoph Anton Mitterer wrote:

@d-d:
- How can it happen that purge *t64 packages and at the same time install
   the previous package, and then the so file is missing?
   I mean it's clear that they use the same name, but shouldn't DPKG handle
   the cleanly?


Well, officially downgrading isn't supported (although it typically 
works) *and* losing files is one of the problems of our merged-/usr 
solution (see [1]). I *suspect* this might be the cause. We're working 
hard (well, helmut is) to protect us and our users from loosing files on 
upgrades. We don't protect against downgrades.


Obviously there might be issues, but you are running unstable *during* a 
transition. You have to expect some troubles. Thanks for the 
information, let's see if this is a real issue or not.


Paul

[1] https://subdivi.de/~helmut/dep17.html


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065022: libglib2.0-0t64: t64 transition breaks the systems

[Christoph Anton Mitterer]

Package: libglib2.0-0t64
Version: 2.78.4-2
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: debian-devel@lists.debian.org

Hey.


CCing d-d since there seems some further deeper problem with the t64
transition (namely lib files getting lost, when "downgrading" i.e.
reverting).


Earlier tonight I've upgraded this day’s packages which included
numerous that made the t64 transition (see the attached aptitude log
for the whole process, first the upgrade, and then "bi-secting" to
find the culprit).

Immediately afterwards, starting GUI programs from the still running
desktop environment caused failures like:
$ evince

(evince:17537): GLib-GIO-CRITICAL **: 04:18:22.610: 
g_settings_schema_source_lookup: assertion 'source != NULL' failed

(evince:17537): GLib-GIO-CRITICAL **: 04:18:22.610: 
g_settings_schema_source_lookup: assertion 'source != NULL' failed

(evince:17537): GLib-GIO-ERROR **: 04:18:22.658: No GSettings schemas are 
installed on the system
Trace/breakpoint trap
$ gedit

(gedit:17585): GLib-GIO-ERROR **: 04:18:35.012: No GSettings schemas are 
installed on the system
Trace/breakpoint trap
$

I suspected a reboot might be needed but after that even the display
manager didn't start anymore.
I saw errors like:
Feb 29 02:51:14 heisenberg kernel: traps: at-spi-bus-laun[17935] trap int3 
ip:7fdceec49587 sp:7ffd0acdade0 error:0 in 
libglib-2.0.so.0.7800.4[7fdceec05000+99000]
Feb 29 02:51:52 heisenberg kernel: traps: at-spi-bus-laun[17941] trap int3 
ip:7f52e53ee587 sp:7ffcc69b0fc0 error:0 in 
libglib-2.0.so.0.7800.4[7f52e53aa000+99000]


My first guess was glib, so I downgraded that (everything from the source
package), but that didn't help.

As you can see from the aptitude log, I then moved on downgrade further
of the previously upgraded packages, several times I've rebooted in-
between (e.g. after downgrading things like *pam* and *systemd*).

Along the way I saw the most weirdest effects:
- logind was apprently in some bogus state, which I think might
  have been the reason, why X/the display manager remained black/hung for
  several minutes:
  Feb 29 03:37:21 heisenberg lightdm[139886]: Failed to get list of logind 
seats: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate 
service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)

- At some point, when installing packages via aptitude
  # aptitude
  
  Performing actions...
  
  
  And it also hung at the end shortly after finishing the
  upgrade/downgrade.

- When downgrading packages that had a t64 transition, sometimes
  the lib file was gone.
  I.e. I removed the *t64 package and re-installed the old one
  and then the .so file for libapt-pkg6.0 and libpam0g was missing.
  How can that happen?


Eventually I downgraded the gcr/gck stuff, and then it worked again.

From that I went forward and upgrade all the various packages again, to
see where the problem actuall is.

Turns out, it's probably actually libglib.

When I install the first time libglib2.0-0t64 (and purge libglib2.0-0),
things start to break apart.
When I re-install libglib2.0-0t64, things work again (it seems regardless
of the gcr/gck stuff).


Long story short:
@glib maintainers:
- there's something wrong with the transition (unless even that need for
  the re-install is already a sign for some deeper issues)

@d-d:
- How can it happen that purge *t64 packages and at the same time install
  the previous package, and then the so file is missing?
  I mean it's clear that they use the same name, but shouldn't DPKG handle
  the cleanly?

Thanks,
Chris

PS: I'll attach the aptitude log only to the bug and not to d-d, in
order not to spam so many people with it.
It's probably anyway uselesss, but might help to find out why
downgrading gck/gcr stuff helped first, without re-installing the
glib package.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libglib2.0-0t64 depends on:
ii  libc6 2.37-15
ii  libffi8   3.4.6-1
ii  libmount1 2.39.3-6
ii  libpcre2-8-0  10.42-4+b1
ii  libselinux1   3.5-2
ii  zlib1g1:1.3.dfsg-3+b1

Versions of packages libglib2.0-0t64 recommends:
ii  libglib2.0-data   2.78.4-2
ii  shared-mime-info  2.4-1
ii  xdg-user-dirs 0.18-1

Versions of packages libglib2.0-0t64 suggests:
pn  low-memory-monitor  

-- no debconf information

Re: New requirements for APT repository signing

[Phil Wyett]

On Wed, 2024-02-28 at 20:20 +0100, Julian Andres Klode wrote:
> APT 2.7.13 just landed in unstable and with GnuPG 2.4.5 installed,
> or 2.4.4 with a backport from the 2.4 branch, requires repositories
> to be signed using one of
> 
> - RSA keys of at least 2048 bit
> - Ed25519
> - Ed448
> 
> Any other keys will cause warnings. These warnings will become
> errors in March as we harden it up for the Ubuntu 24.04 release,
> which was the main driver to do the change *now*.
> 
> If you operate third-party repositories using different key
> algorithms, now is your time to migrate before you get hit
> with an error.
> 
> For the Ubuntu perspective, feel free to check out the discourse
> post:
> 
> https://discourse.ubuntu.com/t/new-requirements-for-apt-repository-signing-in-24-04/42854

Hi,

Could I be pointed to the public conversation, any plans or bug reports related 
to this
update and transition etc. for affected users?

Thanks.

Regards

Phil

-- 
Playing the game for the games sake.

Web:

* Debian Wiki: https://wiki.debian.org/PhilWyett
* Website: https://kathenas.org
* Social Debian: https://pleroma.debian.social/kathenas/
* Social Instagram: https://www.instagram.com/kathenasorg/




signature.asc
Description: This is a digitally signed message part

Re: Setting permissions on new users in postinst

[Peter Pentchev]

On Thu, Feb 29, 2024 at 11:12:27AM +1100, Brian May wrote:
> See bug #1064349.
> 
> I think the problem (correct me if I am wrong!) is that the postinst -
> debian/amavisd-new.postinst - does (simplified):
> 
> === cut ===
> #DEBHELPER#
> 
> case "$1" in
> configure)
> # configure file permissions to use new amavis user
> ...
> esac
> === cut ===
> 
> 
> This means that #DEBHELPER# expands to the code that creates the
> users and starts the daemons.
> 
> === cut ===
[snip the expanded code added by debhelper]
> 
> [ similar for other services that are disabled by default ]
> === cut ===
> 
> I think we have a race condition, the daemon tries to start before we
> setup the file permissions correctly. Both on sysvinit and systemd, but
> seems we can get away with this more with systemd. Probably because of
> the extra checks in the initd script that systemd version doesn't have.
> 
> But I can't move the #DEBHELPER# to the bottom, because then the setting
> the file permissions would fail because we haven't added the user yet.
> 
> How do I fix this?

I haven't tested that, but my first attempt would be to add --no-start to
the invocation of dh_installsystemd in your rules file (you may need to
add an override_dh_installsystemd target to do that), and then your
postinst script would look something like that:

  #DEBHELPER#

  setup file permissions

  deb-systemd-invoke start unit1 unit2...

Hope that helps!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Setting permissions on new users in postinst

[Brian May]

See bug #1064349.

I think the problem (correct me if I am wrong!) is that the postinst -
debian/amavisd-new.postinst - does (simplified):

=== cut ===
#DEBHELPER#

case "$1" in
configure)
# configure file permissions to use new amavis user
...
esac
=== cut ===


This means that #DEBHELPER# expands to the code that creates the
users and starts the daemons.

=== cut ===
# Automatically added by dh_installsysusers/13.14.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
   systemd-sysusers ${DPKG_ROOT:+--root="$DPKG_ROOT"} amavisd-new.conf
fi
# End automatically added section
# Automatically added by dh_installsystemd/13.14.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
# The following line should be removed in trixie or trixie+1
deb-systemd-helper unmask 'amavis.service' >/dev/null || true

# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled 'amavis.service'; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable 'amavis.service' >/dev/null || true
else
# Update the statefile to add new symlinks (if any), which need 
to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state 'amavis.service' >/dev/null || 
true
fi
fi
# End automatically added section
# Automatically added by dh_installsystemd/13.14.1
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = 
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
if [ -n "$2" ]; then
_dh_action=restart
else
_dh_action=start
fi
deb-systemd-invoke $_dh_action 'amavis.service' >/dev/null || 
true
fi
fi
# End automatically added section

[ similar for other services that are disabled by default ]
=== cut ===

I think we have a race condition, the daemon tries to start before we
setup the file permissions correctly. Both on sysvinit and systemd, but
seems we can get away with this more with systemd. Probably because of
the extra checks in the initd script that systemd version doesn't have.

But I can't move the #DEBHELPER# to the bottom, because then the setting
the file permissions would fail because we haven't added the user yet.

How do I fix this?

(Please CC responses to me, thanks)
-- 
Brian May @ Linux Penguins

Fwd: Fix for missing gsettings desktop schemas on unstable

[Ash Joubert]

I know the time_t transition is in progress but there could have been a 
nicer experience for users on unstable:


Feb 29 10:31:30 ripley systemd[914]: Starting at-spi-dbus-bus.service - 
Accessibility services bus...
Feb 29 10:31:30 ripley at-spi-bus-laun[984]: Cannot get the default 
GSettingsSchemaSource - is the gsettings-desktop-schemas package installed?
Feb 29 10:31:30 ripley systemd[914]: at-spi-dbus-bus.service: Main 
process exited, code=killed, status=5/TRAP
Feb 29 10:31:30 ripley systemd[914]: at-spi-dbus-bus.service: Failed 
with result 'signal'.
Feb 29 10:31:30 ripley kernel: traps: at-spi-bus-laun[984] trap int3 
ip:7f46709b4587 sp:7ffea37840b0 error:0 in 
libglib-2.0.so.0.7800.4[7f467097+99000]
Feb 29 10:31:30 ripley systemd[914]: Failed to start 
at-spi-dbus-bus.service - Accessibility services bus.


rednotebook just refused to start!

Cheers,
Ash.


 Forwarded Message 
Subject: Fix for missing gsettings desktop schemas on unstable
Date: Thu, 29 Feb 2024 11:56:48 +1300
From: Ash Joubert 
To: debian-u...@lists.debian.org

There is a huge transition underway on unstable to migrate to 64-bit 
time_t. After upgrading to the new libglib2.0-0t64, nothing could find 
gsettings desktop schemas, breaking applications like rednotebook and 
reportbug (lol), and after a reboot, stopping services like at-spi from 
starting, causing huge timeouts at system and application start.


A workaround that worked for me was to reinstall gsettings-desktop-schemas:

# apt-get reinstall gsettings-desktop-schemas
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not 
upgraded.

Need to get 660 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://ftp.debian.org/debian sid/main amd64 
gsettings-desktop-schemas all 46~beta-3 [660 kB]

Fetched 660 kB in 2s (431 kB/s)
(Reading database ... 35 files and directories currently installed.)
Preparing to unpack .../gsettings-desktop-schemas_46~beta-3_all.deb ...
Unpacking gsettings-desktop-schemas (46~beta-3) over (46~beta-3) ...
Setting up gsettings-desktop-schemas (46~beta-3) ...
Processing triggers for libglib2.0-0t64:amd64 (2.78.4-2) ...

Cheers,

--
Ash Joubert (they/them) 
Director / Game Developer
Transient Software Limited 
New Zealand

Bug#1065009: ITP: golang-github-muhlemmer-httpforwarded -- Library for parsing the HTTP Forwarded header (RFC-7239)

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-muhlemmer-httpforwarded
  Version : 0.1.0-1
  Upstream Author : Tim Möhlmann
* URL : https://github.com/muhlemmer/httpforwarded
* License : BSD-3-clause
  Programming Lang: Go
  Description : Library for parsing the HTTP Forwarded header (RFC-7239)

 The httpforwarded go package provides utility functions for working
 with the Forwarded HTTP header as defined in RFC-7239
 (https://tools.ietf.org/html/rfc7239). This header is proposed to
 replace the X-Forwarded-For and X-Forwarded-Proto headers, amongst
 others.
 .
 This package was heavily inspired by the mime package in the standard
 library, more specifically the ParseMediaType() function.

This is a new dependency required to update golang-github-zitadel-oidc
and will be team-maintained within the Go Packaging Team.


signature.asc
Description: This is a digitally signed message part

Re: On merging bin and sbin

[Gioele Barabucci]

On 28/02/24 19:08, Peter Pentchev wrote:

On Wed, Feb 28, 2024 at 08:47:48AM -0600, r...@neoquasar.org wrote:

From: Gioele Barabucci 

This is a quick'n'dirty list of binaries present in both /bin and /sbin:

arping bin net/iputils-arping sbin net/arping (+ Conflicts:)


Are any of these (like arping) literally duplicates of the same binary for some 
reason? Or are they true conflicts (different binaries with the same name)?


I don't know about many of the others (although I have my suspicions), but
the two programs that just happen to both be called arping are not
the same at all: they have different functionality, conflicting
command-line options, etc.


And that is one of issues.

Without looking, could you say which package installs `arping` in /bin 
and make it available for non-root users?


Policy also has a couple of things to say. For example 
https://www.debian.org/doc/debian-policy/ch-files.html#binaries



Two different packages must not install programs with different
functionality but with the same filenames
That can (should?) be interpreted as "no same basename". Otherwise root 
will face and ambiguous choice between the one in /bin and the one in /sbin.


In any case, many of these clashes are known. This is why some of these 
packages declare Conflicts: with each other. However...



Be aware that adding Conflicts is normally not the best solution when
two packages provide the same files. Depending on the reason for that
conflict, using alternatives or renaming the files is often a better
approach.

https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts

Regards,

--
Gioele Barabucci

Re: On merging bin and sbin

[Andrey Rahmatullin]

On Wed, Feb 28, 2024 at 08:47:48AM -0600, r...@neoquasar.org wrote:
> Are any of these (like arping) literally duplicates of the same binary for 
> some reason? Or are they true conflicts (different binaries with the same 
> name)?
arping is definitely not a duplicate, iputils-arping and arping are
different implementations.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: On merging bin and sbin

[Peter Pentchev]

On Wed, Feb 28, 2024 at 08:47:48AM -0600, r...@neoquasar.org wrote:
> > From: Gioele Barabucci 
> > Sent: Wednesday, February 28, 2024 08:22
> > To: debian-devel@lists.debian.org
> > Subject: Re: On merging bin and sbin
> > 
> > On 28/02/24 14:12, rhys wrote: 
> > > Last thing:  The idea of detecting cases where multiple binaries have the 
> > > same name is a verey good one.  It should also be possible to automate 
> > > this effort in a number of ways.  I would be happy to help with this, if 
> > > it's just a matter of someone putting in the effort.  A number of "crude 
> > > by effective" methods have already come to mind, some of which only 
> > > require access to the repos to accomplish.  (The laziest method involves 
> > > having a test machine with EVERY package installed... but I'm not sure if 
> > > that is practical.) 
> > 
> > Contents-{all,amd64} has most of the info you need. dumat.db has _all_ 
> > the info you need (and cacin is using that). 
> > 
> > This is a quick'n'dirty list of binaries present in both /bin and /sbin: 
> > 
> > arping bin net/iputils-arping sbin net/arping (+ Conflicts:) 
> > bitesize bin devel/ubuntu-dev-tools sbin misc/libbpf-tools 
> > crm bin mail/crm114 sbin admin/crmsh 
> > fai bin python/python3-flask-autoindex sbin admin/fai-client 
> > faxq bin comm/mgetty-fax sbin comm/hylafax-server (+ Conflicts:) 
> > gearmand bin perl/gearman-server sbin misc/gearman-job-server 
> > htpasswd bin httpd/apache2-utils sbin web/merecat (+ Conflicts:) 
> > ipp* bin net/ippsample sbin net/cups-ipp-utils (+ Conflicts:) 
> > newaliases bin mail/esmtp-run sbin 
> > mail/courier-mta,mail/opensmtpd,mail/ssmtp (+ Conflicts: + Provide:) 
> > raddebug bin libs/librad0-tools sbin net/freeradius 
> > sendfax bin comm/hylafax-client sbin comm/mgetty-fax (+ Conflicts:) 
> > sethdlc bin hamradio/ax25-tools sbin comm/dahdi 
> > siggen bin sound/siggen sbin utils/tripwire 
> > sslh bin perl/libnet-proxy-perl sbin net/sslh (+ Conflicts:) 
> > tcpconnect bin net/tcputils sbin misc/libbpf-tools 
> > tcpd bin graphics/tcm sbin net/tcpd 
> > update-locale bin web/gosa-dev sbin localization/locales 
> 
> Are any of these (like arping) literally duplicates of the same binary for 
> some reason? Or are they true conflicts (different binaries with the same 
> name)?

I don't know about many of the others (although I have my suspicions), but
the two programs that just happen to both be called arping are not
the same at all: they have different functionality, conflicting
command-line options, etc.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Re: On merging bin and sbin

[rhys]

Are any of these (like arping) literally duplicates of the same binary for some 
reason? Or are they true conflicts (different binaries with the same name)?

--J

Sent from my mobile device.

From: Gioele Barabucci 
Sent: Wednesday, February 28, 2024 08:22
To: debian-devel@lists.debian.org
Subject: Re: On merging bin and sbin

On 28/02/24 14:12, rhys wrote: 
> Last thing:  The idea of detecting cases where multiple binaries have the 
> same name is a verey good one.  It should also be possible to automate this 
> effort in a number of ways.  I would be happy to help with this, if it's just 
> a matter of someone putting in the effort.  A number of "crude by effective" 
> methods have already come to mind, some of which only require access to the 
> repos to accomplish.  (The laziest method involves having a test machine with 
> EVERY package installed... but I'm not sure if that is practical.) 

Contents-{all,amd64} has most of the info you need. dumat.db has _all_ 
the info you need (and cacin is using that). 

This is a quick'n'dirty list of binaries present in both /bin and /sbin: 

arping bin net/iputils-arping sbin net/arping (+ Conflicts:) 
bitesize bin devel/ubuntu-dev-tools sbin misc/libbpf-tools 
crm bin mail/crm114 sbin admin/crmsh 
fai bin python/python3-flask-autoindex sbin admin/fai-client 
faxq bin comm/mgetty-fax sbin comm/hylafax-server (+ Conflicts:) 
gearmand bin perl/gearman-server sbin misc/gearman-job-server 
htpasswd bin httpd/apache2-utils sbin web/merecat (+ Conflicts:) 
ipp* bin net/ippsample sbin net/cups-ipp-utils (+ Conflicts:) 
newaliases bin mail/esmtp-run sbin 
mail/courier-mta,mail/opensmtpd,mail/ssmtp (+ Conflicts: + Provide:) 
raddebug bin libs/librad0-tools sbin net/freeradius 
sendfax bin comm/hylafax-client sbin comm/mgetty-fax (+ Conflicts:) 
sethdlc bin hamradio/ax25-tools sbin comm/dahdi 
siggen bin sound/siggen sbin utils/tripwire 
sslh bin perl/libnet-proxy-perl sbin net/sslh (+ Conflicts:) 
tcpconnect bin net/tcputils sbin misc/libbpf-tools 
tcpd bin graphics/tcm sbin net/tcpd 
update-locale bin web/gosa-dev sbin localization/locales 

Regards, 

-- 
Gioele Barabucci 

Re: On merging bin and sbin

[Gioele Barabucci]

On 28/02/24 14:12, rhys wrote:

Last thing:  The idea of detecting cases where multiple binaries have the same name is a 
verey good one.  It should also be possible to automate this effort in a number of ways.  
I would be happy to help with this, if it's just a matter of someone putting in the 
effort.  A number of "crude by effective" methods have already come to mind, 
some of which only require access to the repos to accomplish.  (The laziest method 
involves having a test machine with EVERY package installed... but I'm not sure if that 
is practical.)


Contents-{all,amd64} has most of the info you need. dumat.db has _all_ 
the info you need (and cacin is using that).


This is a quick'n'dirty list of binaries present in both /bin and /sbin:

arping bin net/iputils-arping sbin net/arping (+ Conflicts:)
bitesize bin devel/ubuntu-dev-tools sbin misc/libbpf-tools
crm bin mail/crm114 sbin admin/crmsh
fai bin python/python3-flask-autoindex sbin admin/fai-client
faxq bin comm/mgetty-fax sbin comm/hylafax-server (+ Conflicts:)
gearmand bin perl/gearman-server sbin misc/gearman-job-server
htpasswd bin httpd/apache2-utils sbin web/merecat (+ Conflicts:)
ipp* bin net/ippsample sbin net/cups-ipp-utils (+ Conflicts:)
newaliases bin mail/esmtp-run sbin 
mail/courier-mta,mail/opensmtpd,mail/ssmtp (+ Conflicts: + Provide:)

raddebug bin libs/librad0-tools sbin net/freeradius
sendfax bin comm/hylafax-client sbin comm/mgetty-fax (+ Conflicts:)
sethdlc bin hamradio/ax25-tools sbin comm/dahdi
siggen bin sound/siggen sbin utils/tripwire
sslh bin perl/libnet-proxy-perl sbin net/sslh (+ Conflicts:)
tcpconnect bin net/tcputils sbin misc/libbpf-tools
tcpd bin graphics/tcm sbin net/tcpd
update-locale bin web/gosa-dev sbin localization/locales

Regards,

--
Gioele Barabucci

Re: On merging bin and sbin

[rhys]

A few thigns I have seen in this thread:

Fedora/Arch/Whomever:  I don't think it matters who thought of what first.  
Sometimes, it's okay to be different.  I have moved all of my systems away from 
Slackware and Fedora/RedHat/etc. TO Debian because I think Debian does it 
better.  Please do not think that the "pull of RedHat" means anything.  Even 
the larger industry is not necessarily "in love" with RedHat and its variants 
so much that the members of the Debian project should feel any "pull" from 
there, except perhaps that the reverse is also true.  If they have a GOOD idea, 
maybe we should do that.  But the idea isn't "good" or "bad" just because 
Fedora is doing it (or Arch or anyone else).

So regardless of who thought of these filesystem merges (no one will get 
"credit" anyway), the main question is whether or not it's a good idea in the 
first place.

The original split between /bin and /sbin was decades ago.  It was done for 
good reasons, and as far as I can tell, those reasons have not changed.  There 
are still binaries (both CLI-invoked and fully automated) that non-admins have 
little or no business having in their PATHs.

Also, there have been numerous occasions in my many years when I thought that 
merging two collections seemed "simpler," only to find that the result was so 
large that it became a new problem.  While obviously a separate directory for 
each file (the other extreme) would be silly, there is no danger of that here.  
Having a single directory with all executables in it sounds messy and dangerous 
to me, and reminds me of how MS-DOS would do things.

(Side note:  Be wary of discussions that assume that daemons are never executed 
by hand.  Postfix, dhcpd, httpd, syslog-ng, and many others have "syntax check" 
functions built into the daemon binaries that are often executed manually.  
Version checks are often "daemon --version" or similar.  Don't get caught in 
the assumption that "no one runs httpd by hand."  Yes.  They do.)

I would also suggest that what Marco said is perhaps the most important:

> I think that the benefits from doing this are tiny, and just adding 
> /usr/sbin/ to the $PATH would solve almost everything.

Not only is this the most important point (effort vs. value), but if people 
believe that a directory merger would be beneficial, adding the /sbin 
directories to users' PATHs is not only the FASTER way to accomplish that, but 
it is EASILY REVERSED.  Far easier to make a change to /etc/profile than to 
change how dozens of packages' build parameters are set.

Last thing:  The idea of detecting cases where multiple binaries have the same 
name is a verey good one.  It should also be possible to automate this effort 
in a number of ways.  I would be happy to help with this, if it's just a matter 
of someone putting in the effort.  A number of "crude by effective" methods 
have already come to mind, some of which only require access to the repos to 
accomplish.  (The laziest method involves having a test machine with EVERY 
package installed... but I'm not sure if that is practical.)

Let me know if I can help.

--J

> On Feb 28, 2024, at 05:52, Marco d'Itri  wrote:
> 
> On Feb 28, Helmut Grohne  wrote:
> 
>> Please allow me to push back on this one as well by raising a few
>> concerns.
> Also, I think that the benefits from doing this are tiny, and just 
> adding /usr/sbin/ to the $PATH would solve almost everything.
> 
> -- 
> ciao,
> Marco

Bug#1064959: ITP: python-usb-devices -- Python tools for mapping, describing, and resetting USB devices

[Edward Betts]

Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python-usb-devices
  Version : 0.4.5
  Upstream Author : J. Nick Koston 
* URL : https://github.com/bluetooth-devices/usb-devices
* License : MIT
  Programming Lang: Python
  Description : Python tools for mapping, describing, and resetting USB 
devices

  A comprehensive toolkit for interacting with USB and Bluetooth devices in
  Python. Offering functionally to map USB device connections, describe
  device attributes, and perform device reset operations.
  .
  Ideal for developers aiming to integrate USB device management into their
  projects, it supports asynchronous programming paradigms and is designed to
  work seamlessly with modern Python async features.

I plan to maintain this package as part of the Python team.

Re: On merging bin and sbin

[Gioele Barabucci]

On 28/02/24 12:25, Ansgar 🙀 wrote:

 This can be good, but it can also be seen as a pollution of
your shell completion. I note that Fedora seems to have added /sbin to
the user $PATH by default, which is not what Debian has done. I do not
think we have consensus on this and would raise an objection of my own.


/sbin not in PATH by default makes many more veteran users unhappy. 


Also non veteran users, given that certain commands in /sbin just work 
fine when run as non-root (or actually should _not_ be run as root 
because they trust their input). For example:


* fatlabel
* findfs
* fsck.*
* isosize
* mkfs.*
* route
* tarcat

But aside from the $PATH question, cacin work on ensuring that there are 
no conflicts between /sbin and /bin is worth pursuing as these conflicts 
are just bugs waiting to happen.


Regards,

--
Gioele Barabucci

Re: On merging bin and sbin

[Marco d'Itri]

On Feb 28, Helmut Grohne  wrote:

> Please allow me to push back on this one as well by raising a few
> concerns.
Also, I think that the benefits from doing this are tiny, and just 
adding /usr/sbin/ to the $PATH would solve almost everything.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: On merging bin and sbin

[Ansgar 🙀]

Hi Helmut,

On Wed, 2024-02-28 at 07:41 +0100, Helmut Grohne wrote:
> I see that you are working on merging /bin and /sbin, for instance
> via
> brltty bug #1064785. Again Fedora is pioneering this matter and their
> documentation is at
> https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin.

This summary is wrong. Other Linux distributions like Arch Linux have
done that over 10 years ago.

So I wouldn't call Fedora pioneering anything here (same as before with
merged-/usr which many people also claim Fedora or others invented).

> Apart from the implementation side, this is a more user visible
> change.
> As you complete programs in a user shell, more programs become
> available.

I totally agree: we should aim at moving all service binaries such as
daemons which are not directly invoked by users out of PATH to
/usr/lib{,exec} or similar to make shell completion more helpful.

>  This can be good, but it can also be seen as a pollution of
> your shell completion. I note that Fedora seems to have added /sbin
> to
> the user $PATH by default, which is not what Debian has done. I do
> not
> think we have consensus on this and would raise an objection of my
> own.

/sbin not in PATH by default makes many more veteran users unhappy.
Especially as even su (not `su -`) no longer does that (an incompatible
change in one of the last Debian releases).

Ansgar

On merging bin and sbin

[Helmut Grohne]

Hi cacin,

I see that you are working on merging /bin and /sbin, for instance via
brltty bug #1064785. Again Fedora is pioneering this matter and their
documentation is at
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin.

Please allow me to push back on this one as well by raising a few
concerns.

Fundamentally, turning sbin into a symlink pointing to bin is causing
aliasing problems that we currently have a hard time fixing up for the
/usr-merge. If doing this, I think we need a different technical
approach. Doing the aliasing mess again does not sound like a valid
option to me. In the /usr-merge discussion, alternatives have been
proposed. For instance, there as a proposal that would manage a symlink
farm via dpkg triggers until the aliased directory would become
unpopulated (by packages) and then turn the farm into a symlink. If
doing the symlink first, I think we need changes to dpkg before
creating such a symlink to make this approach viable.

Apart from the implementation side, this is a more user visible change.
As you complete programs in a user shell, more programs become
available. This can be good, but it can also be seen as a pollution of
your shell completion. I note that Fedora seems to have added /sbin to
the user $PATH by default, which is not what Debian has done. I do not
think we have consensus on this and would raise an objection of my own.

That said, I appreciate your work on analyzing the situation as it also
uncovers tangential problems e.g. where different packages put programs
with different functionality into bin and sbin. It is up to
interpretation of Debian policy whether that should be considered an
RC-bug (10.1 "same filenames"). In general, I think that having each
program name on either bin or sbin but not both is a desirable property
and it should be easier to gain consensus on this. As we've seen with
arcstat (zfs vs nordugrid), doing so will take a long time. Where we
expect downstreams to not have hardcoded paths to programs
/usr/sbin/foo, dropping a symlink from sbin/foo -> ../bin/foo probably
is reasonable, but needs to be reviewed case by case.

As we see, this is not a single change to be working on, but multiple
related and interdependent topics. Disentangling these matters and
making the intention clear is key to moving this forward.

Regardless of whether we (as a project) want sbin merged into bin or
not, reducing conflicts (different functionality but same name) between
sbin and bin is a hard prerequisite, difficult to achieve and probably
and agreeable goal.

Helmut