Re: Future of /usr/bin/which in Debian?

[Calum McConnell]

On Fri, 2021-08-20 at 11:03 +0800, YunQiang Su wrote:
> Paul Wise  于2021年8月20日周五 上午10:50写道：
> > 
> > On Thu, Aug 19, 2021 at 9:17 PM Boyuan Yang wrote:
> > 
> > > So we will have https://salsa.debian.org/debian/which-gnu providing
> > > a binary
> > > package with name "which". I will upload it to the NEW queue soon.
> > 
> > Some folks on IRC wanted to package the FreeBSD which too, so I
> > suggest using which-gnu as the binary package name too.
> > 
> 
> For such a simple tool, do we really need such many versions?

Which which witches wish to which with will wildly wander.  We wish
welcome to witches which which with weird whichs, which will want whiches
which witches who were wasted winds when we were whelks used.  Which which
any witch uses is a decision whence the heart, which we wish to watch each
which make.


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

Re: Future of /usr/bin/which in Debian?

[YunQiang Su]

Paul Wise  于2021年8月20日周五 上午10:50写道：
>
> On Thu, Aug 19, 2021 at 9:17 PM Boyuan Yang wrote:
>
> > So we will have https://salsa.debian.org/debian/which-gnu providing a binary
> > package with name "which". I will upload it to the NEW queue soon.
>
> Some folks on IRC wanted to package the FreeBSD which too, so I
> suggest using which-gnu as the binary package name too.
>

For such a simple tool, do we really need such many versions?


> --
> bye,
> pabs
>
> https://wiki.debian.org/PaulWise
>


-- 
YunQiang Su

Re: Future of /usr/bin/which in Debian?

[Paul Wise]

On Thu, Aug 19, 2021 at 9:17 PM Boyuan Yang wrote:

> So we will have https://salsa.debian.org/debian/which-gnu providing a binary
> package with name "which". I will upload it to the NEW queue soon.

Some folks on IRC wanted to package the FreeBSD which too, so I
suggest using which-gnu as the binary package name too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Work-needing packages report for Aug 20, 2021

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1229 (new: 4)
Total number of packages offered up for adoption: 205 (new: 1)
Total number of packages requested help for: 60 (new: 0)

Please refer to https://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   gimp-texturize (#992311), orphaned 2 days ago
 Description: generates large textures from a small sample
 Installations reported by Popcon: 968
 Bug Report URL: https://bugs.debian.org/992311

   mysqltcl (#992337), orphaned 2 days ago
 Description: interface to the MySQL database for the Tcl language
 Installations reported by Popcon: 124
 Bug Report URL: https://bugs.debian.org/992337

   python-slip (#992361), orphaned 2 days ago
 Reverse Depends: policycoreutils-dbus policycoreutils-gui
   python3-slip-dbus
 Installations reported by Popcon: 1576
 Bug Report URL: https://bugs.debian.org/992361

   tclcurl (#992338), orphaned 2 days ago
 Description: Tcl bindings to libcurl
 Installations reported by Popcon: 47
 Bug Report URL: https://bugs.debian.org/992338

1225 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   bitlbee-facebook (#992288), offered 3 days ago
 Installations reported by Popcon: 32
 Bug Report URL: https://bugs.debian.org/992288

204 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   apache2 (#910917), requested 1041 days ago
 Description: Apache HTTP Server
 Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom
   apache2-suexec-pristine backuppc bfh-container-server
   courier-webadmin cvsweb debbugs-web doc-central (139 more omitted)
 Installations reported by Popcon: 93392
 Bug Report URL: https://bugs.debian.org/910917

   asciio (#968843), requested 362 days ago
 Description: dynamically create ASCII charts and graphs with GTK+2
 Installations reported by Popcon: 65
 Bug Report URL: https://bugs.debian.org/968843

   aufs (#963191), requested 425 days ago
 Description: driver for a union mount for Linux filesystems
 Reverse Depends: fsprotect
 Installations reported by Popcon: 11041
 Bug Report URL: https://bugs.debian.org/963191

   autopkgtest (#846328), requested 1723 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker sbuild-qemu
 Installations reported by Popcon: 1195
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 3616 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 634
 Bug Report URL: https://bugs.debian.org/642906

   cargo (#860116), requested 1591 days ago
 Description: Rust package manager
 Reverse Depends: dh-cargo
 Installations reported by Popcon: 2287
 Bug Report URL: https://bugs.debian.org/860116

   courier (#978755), requested 231 days ago
 Description: Courier mail server
 Reverse Depends: courier-faxmail courier-filter-perl courier-imap
   courier-ldap courier-mlm courier-mta courier-pcp courier-pop
   courier-webadmin couriergrey (3 more omitted)
 Installations reported by Popcon: 964
 Bug Report URL: https://bugs.debian.org/978755

   cron (#984736), requested 165 days ago
 Description: new maintainer need
 Reverse Depends: apticron autolog backintime-common btrfsmaintenance
   buildd checksecurity clamtk cricket email-reminder exim4-base (20
   more omitted)
 Installations reported by Popcon: 199542
 Bug Report URL: https://bugs.debian.org/984736

   cyrus-imapd (#921717), requested 923 days ago
 Description: Cyrus mail system - IMAP support
 Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev
   cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication
 Installations reported by Popcon: 424
 Bug Report URL: https://bugs.debian.org/921717

   cyrus-sasl2 (#799864), requested 2157 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav
   cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd
   cyrus-murder (78 more omitted)
 Installations reported by Popcon: 199021
 Bug Report URL: https://bugs.debian.org/799864

   dbad (#947550), requested 600 days ago
 Description: dnsmasq-based ad-

Re: merged /usr vs. symlink farms

[Craig Small]

On Fri, 20 Aug 2021 at 09:56, Theodore Ts'o  wrote:

> P.S.  I had a vague memory that there was some update in the long
> distant past where we did require a manual upgrade of dpkg first.  Or
> is my memory playing tricks on me?  I do know that a manual update of
> dpkg is the first step in a crossgrade
>
There was an instance of this. I cannot remember if it was the libc4/a.out
or something to do with libstdc but it was library-related and a bit of a
pain for end-users.

In any case, it was not an ideal situation or something we should aim for.

 - Craig

Re: merged /usr vs. symlink farms

[Theodore Ts'o]

On Thu, Aug 19, 2021 at 10:39:45PM +0200, Simon Richter wrote:
> 
> I think no one likes that idea, but it's the only solution that doesn't
> immediately fail because it requires a dpkg update that hasn't shipped with
> the current stable release, breaks local packages (kernel modules, firmware,
> site-wide systemd configuration), or both.

This could be solved if we could somehow require dpkg to be updated
before any other packages during the the next update, no?

Breaking this constraint means that we can't make "apt-get
dist-update" work seemlessly --- but what if we were to change the
documented procedure for doing a major update?

That's not ideal, granted, but how does that compare against the other
alternatives?

- Ted

P.S.  I had a vague memory that there was some update in the long
distant past where we did require a manual upgrade of dpkg first.  Or
is my memory playing tricks on me?  I do know that a manual update of
dpkg is the first step in a crossgrade

Re: Q: Use https for {deb,security}.debian.org by default

[Jeremy Stanley]

On 2021-08-19 16:37:13 -0400 (-0400), Kyle Edwards wrote:
> On 8/19/21 3:46 PM, Simon Richter wrote:
> > For the most part, users would configure https if they are behind a
> > corporate firewall that disallows http, or modifies data in-flight so
> > signature verification fails, everyone else is better off using plain
> > http.
> 
> Or they might configure https on the sheer principle of not wanting to have
> their traffic hoovered up by their ISP or anyone else who might be
> listening.

While this does complicate it, a snooping party can still know the
site they're connecting to via SNI happening unencrypted, and packet
sizes/pacing likely give away which pages or files are being
retrieved based on their length. And that's not even getting into
how "trusted" certificate authorities give away certificates for any
hostname if your MitM knows the right people, and CDNs are now in
the business of snooping on everyone's traffic for sites where they
handle SSL/TLS termination. HTTPS as deployed on the open Internet
is a sip of security with several gulps of theater.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Future of /usr/bin/which in Debian?

[Boyuan Yang]

在 2021-08-18星期三的 22:59 +0200，Geert Stappers写道：
> On Wed, Aug 18, 2021 at 07:56:05PM +, Clint Adams wrote:
> > On Wed, Aug 18, 2021 at 09:48:29PM +0200, Geert Stappers wrote:
> > } } I'm happy to transition /usr/bin/which to alternatives
> > > Which alternatives would that be?
> > 
> > I meant
> > 
> > update-alternatives --install /usr/bin/which which
> > /usr/bin/which.debianutils 0
> > 
> > in postinst and so on so that FreeBSD which and GNU which and friends
> > could
> > take over.
> 
> Please do.  Make such take over possible.
> It is what 
> https://salsa.debian.org/debian/debianutils/-/merge_requests/6#note_242172
> is asking for.

So we will have https://salsa.debian.org/debian/which-gnu providing a binary
package with name "which". I will upload it to the NEW queue soon.

Still not sure about the the package's priority. Now I am using Priority:
optional, but we may raise it later if needed.

Thanks,
Boyuan Yang


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

Bug#992539: ITP: which-gnu -- Utility to show the full path of commands

[Boyuan Yang]

Package: wnpp
Severity: wishlist
Owner: Boyuan Yang 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: which-gnu
  Version : 2.21
  Upstream Author : Carlo Wood 
* URL : https://savannah.gnu.org/projects/which
* License : GPL-3+
  Programming Lang: C
  Description : Utility to show the full path of commands

 This package provides GNU implementation of which command.
 This tool provides the functionality to show the full path
 of commands.

This package comes as an alternative to the /usr/bin/which command as
previously provided by debianutils. Please also refer to
https://lists.debian.org/debian-devel/2021/08/msg00204.html for a background.
Also check https://salsa.debian.org/debian/which-gnu/ for the git packaging
repo.

My name is on lowNMU list so package co-maintenance is welcome. Feel free to
let me know if you also would like to be listed as package uploader.

-- 
Regards,
Boyuan Yang


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

Re: merged /usr vs. symlink farms

[Simon Richter]

Hi,

On 8/19/21 4:45 PM, Theodore Ts'o wrote:


FWIW, from following the discussion, I've become more and more
convinced that a symlink farm is *not* the right answer, regardless of
whether it is done centrally or via individual packages moving files
and created symlinks if necessary in individual maintainer scripts.


I think no one likes that idea, but it's the only solution that doesn't 
immediately fail because it requires a dpkg update that hasn't shipped 
with the current stable release, breaks local packages (kernel modules, 
firmware, site-wide systemd configuration), or both.


The dpkg team are rightfully skeptical about introducing a policy 
decision into the codebase, especially as the next dist-upgrade that 
users are going to perform will upgrade dpkg somewhere in the middle of 
the process, after several of its dependencies, which are precisely the 
packages affected. You can't change default behavior here, you can't 
introduce a new critical control field because it would create a 
Depends/Pre-Depends loop, ...


What *could* be done in dpkg is to change the policy for replacing a 
directory with a symlink. Currently, those entries are dropped, and the 
comment next to the code responsible for that suggests that the most 
common scenario where that would be seen were broken packages where 
someone swapped source and destination while creating a symlink.


But: a new policy would still have to honor file conflicts. The /lib 
directory cannot be replaced with a symlink until all packages that ship 
a directory here are gone. Because /lib/ld-linux.so.2 is part of the 
ABI, that cannot happen on its own, so we can probably narrow this down 
to "until all packages that ship regular files below /lib are gone."


As I understand it, that is where the symlink farming approach comes 
from: when the other packages move their regular files out of the way 
and replace them by symlinks, we have a criterion by which we can decide 
that the entire hierarchy can be replaced by a symlink.


We still need a mechanism in either dpkg or a package handling the 
transition that actually performs this operation. If we can do this in a 
package without touching dpkg, then IMO that would be preferable, but in 
either case that mechanism needs to be defined first.



Speaking personally, I'm not super excited about /usr unification.
But then again, I don't work on projects such as embedded systems,
containerized systems, etc., which seem to benefit from /usr
unification, and there *is* value in being similar to other Linux
distributions.


In my embedded projects, unification is counterproductive, because the 
initramfs effectively takes on the functionality of the root filesystem, 
except it cannot be modified in-place anymore with dpkg, and instead I 
need a script that copies relevant files, follows dependencies and then 
creates a compressed read-only root filesystem I can use for early boot.


That is about as convenient as using cramfs as the root filesystem, 
except it needs a lot more memory, and I cannot prepare this on the host.


Starting systemd without /usr, /proc and /sys mounted has been broken 
for ages, so booting without an initramfs simply does not work anyway there.


With sysvinit, it still mostly works, although some programs (also 
mostly from the systemd ecosystem) fail before /usr is mounted as they 
are missing libraries.


My expectation is that systemd will take over initramfs generation 
during the next release cycle, that might make the situation a bit more 
bearable as we can then reuse dependency information from units instead 
of having a shell script recreate it using heuristics.


Right now, a kernel update on a 150 MHz NiosII CPU takes several hours 
because the initramfs rebuild is just so slow, so for embedded systems, 
Debian as it is is close to unusable anyway and I believe embedded 
systems vendors have jumped ship a while ago. I have.


   Simon



OpenPGP_signature
Description: OpenPGP digital signature

Re: Q: Use https for {deb,security}.debian.org by default

[Kyle Edwards]

On 8/19/21 3:46 PM, Simon Richter wrote:
For the most part, users would configure https if they are behind a 
corporate firewall that disallows http, or modifies data in-flight so 
signature verification fails, everyone else is better off using plain 
http.


Or they might configure https on the sheer principle of not wanting to 
have their traffic hoovered up by their ISP or anyone else who might be 
listening.


Kyle

Re: Q: Use https for {deb,security}.debian.org by default

[Philipp Kern]

On 19.08.21 21:48, Paul Gevers wrote:

On 19-08-2021 21:46, Simon Richter wrote:

For the most part, users would configure https if they are behind a
corporate firewall that disallows http, or modifies data in-flight so
signature verification fails, everyone else is better off using plain http.

Except for the security archive, where https can prevent a
man-in-the-middle from serving you outdated information and thus deprive
you from updates.


For a week until Valid-Until expires. Note that the denial of service 
equally works for HTTPS, it's just more noisy.


Kind regards
Philipp Kern

Re: Q: Use https for {deb,security}.debian.org by default

[Paul Gevers]

Hi,

On 19-08-2021 21:46, Simon Richter wrote:
> For the most part, users would configure https if they are behind a
> corporate firewall that disallows http, or modifies data in-flight so
> signature verification fails, everyone else is better off using plain http.

Except for the security archive, where https can prevent a
man-in-the-middle from serving you outdated information and thus deprive
you from updates.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Re: Q: Use https for {deb,security}.debian.org by default

[Simon Richter]

Hi,

On 8/19/21 3:38 PM, Hideki Yamane wrote:


  Now deb.debian.org and security.debian.org provide https access
  but created sources.list file use http for those. Is there any
  reason to use http instead of https for them? (traffic, policy,
  etc...) If not, how about to change it?


There is little benefit to do so, it just increases processing overhead 
and breaks caching proxies, most importantly transparent proxies in 
large hosting companies and large container deployments.


For the most part, users would configure https if they are behind a 
corporate firewall that disallows http, or modifies data in-flight so 
signature verification fails, everyone else is better off using plain http.


   Simon



OpenPGP_signature
Description: OpenPGP digital signature

Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system

[Michael Biebl]

Am 19.08.21 um 16:28 schrieb Theodore Ts'o:

OK, thanks for confirming this.  What really worried me was this text
in lintian:

N:   Systemd in Debian searches for unit files in /lib/systemd/system/ and
N:   /etc/systemd/system. Notably, it does *not* look in
N:   /usr/lib/systemd/system/ for service files.


This warning is definitely wrong/outdated.
I'll see that this is going to be fixed.

Thanks for raising this issue.


Michael




OpenPGP_signature
Description: OpenPGP digital signature

Re: merged /usr vs. symlink farms

[Theodore Ts'o]

On Thu, Aug 19, 2021 at 11:17:17AM +0100, Simon McVittie wrote:
> In this specific case, I think the thing you're having a problem with is
> the gradual, file-by-file migration of executables into /usr by individual
> packages and individual packages' maintainers. That's not merged-/usr:
> merged-/usr does the migration all at once, by creating the aliasing
> symlinks (and then we can clean up the contents of data.tar.* to put all
> /usr-like files below /usr at our leisure, during the next release cycle,
> without needing maintainer script glue).

FWIW, from following the discussion, I've become more and more
convinced that a symlink farm is *not* the right answer, regardless of
whether it is done centrally or via individual packages moving files
and created symlinks if necessary in individual maintainer scripts.

The symlink farm idea seems to be pushed by the dpkg team, because
it's clear that supprorting directory aliasing by having /bin ->
usr/bin, /lib -> /usr/lib, etc., top-level symlinks does create more
work for the dpkg team, and they seem to be put off by the fact that
they hadn't agreed to do that work, and they appear to claim that they
weren't consulted in advance.

But if we are going to follow how Fedora, Solaris, etc, have been
moving elimitating the traditional /{bin,sbin,lib} and
/usr/{bin,sbin,lib} split, directory aliasing the way Fedora, Solaris,
etc. have done things is the only way to go.

Perhaps the dpkg team should have been consulted earlier, and if they
could have convincingly argued that this was a show stopper, or they
had demanded that someone else should have provided the engineering
effort to make dpkg handle the directory aliasing *first*, perhaps we
shouldn't have even stated in the /{bin,sbin,lib} ->
/usr/{bin,sbin,lib} unification journey, despite the fact that all of
the other distributions have gone down that path.

Speaking personally, I'm not super excited about /usr unification.
But then again, I don't work on projects such as embedded systems,
containerized systems, etc., which seem to benefit from /usr
unification, and there *is* value in being similar to other Linux
distributions.

In any case, that's water on the bridge.  We are where we are, and
stopping midway through the /usr unification journey would be a far
worse outcome.  And given that we've already lost the benefits of the
split /usr architecture (specifically, the ability to boot without
/usr being mounted, which I recognize is not as useful in the 21st
century) --- we should push on and finish the job.

Given that symlink farms have all sorts of downsides, the best path
foward seems to be to teach dpkg about the top-level directory
aliasing, and simply handling this appropriately.  Issues such as the
/bin/sh vs. /usr/bin/sh unification causing problems with /etc/shells
is an issue all distributions have to deal with anyway, and we can
look to see how they have handled it.

Cheers,

- Ted

Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system

[Theodore Ts'o]

On Thu, Aug 19, 2021 at 11:46:21AM +0200, Michael Biebl wrote:
> Am 19.08.21 um 08:27 schrieb Michael Biebl:
> > I'll check later today, if i-s-h (init-system-helpers) does properly
> > handle this new path. If so, I'd say the bug should be reassigned to
> > lintian and we should start transitioning the files to
> > /usr/lib/systemd/system.
> 
> I now remember updating i-s-h [1].
> 
> So we should be safe using /usr/lib/systemd/system I'd say.

OK, thanks for confirming this.  What really worried me was this text
in lintian:

N:   Systemd in Debian searches for unit files in /lib/systemd/system/ and
N:   /etc/systemd/system. Notably, it does *not* look in
N:   /usr/lib/systemd/system/ for service files.

This implied that it was *systemd* that didn't like /usr/lib/systemd,
and I didn't understand the subtlty that it was really the how
Debian's init-system-helpers worked which was the issue.

So it sounds like it's OK for me to upload a package like e2fsprogs
with a systemd unit file, despite the lintian flagging this as an
error.

  - Ted

Re: Q: Use https for {deb,security}.debian.org by default

[Tim Woodall]

Is there any way to estimate what proportion of clients are behind a
proxy? security.debian.org in particular could possibly see a lot more
traffic when there are things like kernel updates.
(Clearly it's not possible to determine how many clients a caching proxy
might be serving)

Are there any plans/thoughts to drop http access?



On Thu, 19 Aug 2021, Hideki Yamane wrote:


Hi,

Now deb.debian.org and security.debian.org provide https access
but created sources.list file use http for those. Is there any
reason to use http instead of https for them? (traffic, policy,
etc...) If not, how about to change it?

Bug#992511: ITP: python-pathos -- parallel graph management and execution in heterogeneous computing

[Romain Porte]

Package: wnpp
Severity: wishlist
Owner: Romain Porte 
X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@microjoe.org

* Package name: python-pathos
  Version : 0.2.8
  Upstream Author : Mike McKerns
* URL : https://github.com/uqfoundation/pathos
* License : BSD-3-clause
  Programming Lang: Python
  Description : parallel graph management and execution in heterogeneous 
computing

This package is introduced as a dependency for python-statmake, which is
required for building the new release of fonts-cantarell from source.

Bug#992509: ITP: python-pox -- utilities for filesystem exploration and automated builds

[Romain Porte]

Package: wnpp
Severity: wishlist
Owner: Romain Porte 
X-Debbugs-Cc: debian-devel@lists.debian.org,, deb...@microjoe.org

* Package name: python-pox
  Version : 0.3.0
  Upstream Author : Mike McKerns
* URL : //github.com/uqfoundation/pox
* License : BSD-3-clause
  Programming Lang: Python
  Description : utilities for filesystem exploration and automated builds

This package is introduced as a dependency for the python-pathops
package, which is required for building the new version of
fonts-cantarell from source.

Q: Use https for {deb,security}.debian.org by default

[Hideki Yamane]

Hi,

 Now deb.debian.org and security.debian.org provide https access
 but created sources.list file use http for those. Is there any
 reason to use http instead of https for them? (traffic, policy,
 etc...) If not, how about to change it?


-- 
Hideki Yamane 

Bug#992504: ITP: python-ppft -- distributed and parallel Python

[Romain Porte]

Package: wnpp
Severity: wishlist
Owner: Romain Porte 
X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@microjoe.org

* Package name: python-ppft
  Version : 1.6.6.4
  Upstream Author : Mike McKerns
* URL : https://github.com/uqfoundation/ppft
* License : BSD-like
  Programming Lang: Python
  Description : distributed and parallel Python

Parallel Python module (pp) provides an easy and efficient way to create
parallel-enabled applications for SMP computers and clusters. pp module
features cross-platform portability and dynamic load balancing. Thus
application written with pp will parallelize efficiently even on
heterogeneous and multi-platform clusters (including clusters running
other application with variable CPU loads). Visit
http://www.parallelpython.com for further information.

This package is introduced as a dependency for python-pathops, which is
a new required dependency for fonts-cantarell.

Bug#992503: [RFC] [meta][WiP] URL specification with IPv6 zone identifiers

[Bastien Roucariès]

Package: general
Severity: minor
Tags: upstream ipv6
Forwarded: https://github.com/whatwg/url/issues/392

Dear all,

They are some push to change the RFC in order to support browsing to IPV6
address with zone identifier.

It will help some of us to get configuration of industrial appliance.

Link Local addresses (fe80::/10) are used for addressing devices in your local
subnet. They can be automatically generated and using the IPv6 multicast
address ff02::1, all hosts on the local subnet can easily be located.

However browsers like Chrome or Firefox do not support entering link local
addresses inside a URL, which prevents accessing devices locally with a
browser, for instance for configuring them.

Link local addresses need zone identifiers to specify which network device to
use as an outgoing interface. This is because you have link local addresses on
every interface and your network stack does not know on its own, which
interface to use. So typically a link local address is something on the line of
fe80::fae4:e3ff:fee2:37a4%eth0, where eth0 is the zone identifier.

However, I do not know if debian is ready for this for next release so, open a
bug in order to track issue. I suppose we will need also a user tag

Rational and workarround for the time being here
https://ungleich.ch/u/blog/ipv6-link-local-support-in-browsers/

Last draft here
https://www.ietf.org/archive/id/draft-carpenter-6man-rfc6874bis-02.html

Bastien

Re: testing for rootfs vs. /usr reproducibility regressions

[Simon McVittie]

On Thu, 19 Aug 2021 at 10:06:27 +0200, Helmut Grohne wrote:
> On Tue, Aug 17, 2021 at 05:19:06PM +0100, Simon McVittie wrote:
> > If we want to make buildd chroots merged-/usr any time soon, then I
> > think we need to say this class of bugs is RC for bookworm.
> 
> For a moment, let us assume perfection of this plan: Reproducible builds
> identify all of the cases that need to be fixed. We bump them to RC
> bugs. We fix them all. Then we change unstable to be merged-/usr and
> we're done. Are we? We still need to support partial upgrades from
> bullseye to bookworm, so - as you pointed out earlier - all packages in
> bookworm will have to keep this support property. However, our
> defaulting to merged-/usr makes it impossible for reproducible builds to
> test it as producing an unmerged chroot is no longer possible.
> Effectively, the unmerged case will be untested and as a consequence
> will be broken.

Is this the scenario you're concerned about?

* We reach a point where every package in bookworm builds identically
  (or with only non-/usr-related variation) in non-merged-/usr and
  merged-/usr chroots, i.e. the bugs falling into classification
  
https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
  have all been fixed

* We deploy an automatic transition mechanism that makes all bookworm
  installations, including chroots, convert to merged-/usr (for example,
  making usrmerge transitively Essential would be one possible
  implementation, although perhaps not the best one)

* Now our buildd chroots are all merged-/usr, and additionally we can
  no longer easily test for /usr-related reproducibility

* The foo maintainer uploads foo_1.0 that has a regression, introducing a
  *new* /usr-related unreproducibility (for example it might end up
  hard-coding /usr/bin/sh when built in a merged-/usr environment, rather
  than the /bin/sh that is correct for traditional environments, even
  though earlier versions of foo did not have that bug)

* The regression is not detected because we can't easily test for it any more

* A user carries out a partial upgrade in which foo_1.0 is upgraded before
  whatever part of the system is responsible for carrying out the transition
  mechanism

* Now foo doesn't work on that user's system

I agree that's a potential failure mode, although the window for regression
is not necessarily very long (foo would have to regress after the automatic
transition is already in place).

> For this plan to work, we will have to support unmerged chroots until
> the end of bookworm, which appears to contradict the premise we started
> with.

One way we could escape from this would be to observe that the earliest
point at which it is OK for package maintainers to rely on merged-/usr is
when the bookworm+1 development cycle opens, therefore it is OK to have
a mechanism for bookworm chroots/containers to be special-cased to opt out
from the merged-/usr transition, as long as those chroots/containers will
never be upgraded to bookworm+1 (because in practice we tend to discard
and re-bootstrap chroots/containers rather than upgrading them).
Conceptually, those chroots/containers are stuck in the "upgrade from
bullseye to bookworm almost but not quite complete" state, forever.

If desired, we could declare this to be formally unsupported, but
make reproducible-builds do it anyway, purely as a way to get test
coverage. This would be conceptually similar to the way people regularly
do archive rebuilds with a gcc that is not supported as the default yet,
in order to get the information we need before we can make it the default
- but in reverse, with the "old" configuration being the one that is
formally unsupported.

reproducible-builds could do something like this:

* for build1: do a merged-/usr chroot/container as (will become) usual
* for build2: bootstrap a chroot/container with --no-merged-usr, and set
  whatever flag opts-out from the transition

or (matching what they do for buster/bullseye):

* bootstrap a chroot/container with --no-merged-usr
* for build1: use it as-is (opting out from the transition if necessary)
* for build2: enable the transition and let it happen, or install usrmerge
  manually

Or, if the transition ends up being done during boot, either in the
initramfs or in normal user-space, then chroots/containers would
"naturally" not transition without manual action - similar to the way
chroots/containers don't pick up kernel or initramfs behaviour changes
like the changed default for /proc/sys/kernel/unprivileged_userns_clone
in bullseye, because their kernel is not their own.

smcv

Re: merged /usr vs. symlink farms

[Simon McVittie]

On Thu, 19 Aug 2021 at 10:06:27 +0200, Helmut Grohne wrote:
> You keep proposing adding /bin/foo -> /usr/bin/foo symbolic links via
> maintainer scripts.

I'm not proposing this! I'm trying to *not* need to do that in any more
packages, and instead do usrmerge or equivalent, so that individual
packages' maintainers don't have to take per-package action to move
their files from /bin,/sbin,/lib* into /usr while creating compatibility
symlinks for non-merged-/usr systems.

However, I know Guillem and some others object to that strategy, so I'm
trying to also be clear about which of the fixes that are necessary with
usrmerge would be equally necessary for a symlink-farm-based strategy,
if people who prefer a symlink-farm-based strategy gain consensus for
that strategy.

Exactly how the symlinks in a symlink-farm-based strategy are created
is orthogonal to whether packages need to avoid hard-coding (e.g.) /bin/env
or /usr/bin/sh, in filesystem layouts where both paths with and without /usr
exist, which would break the installation of that package onto the traditional
filesystem layout where only /usr/bin/env and /bin/sh exist.

I agree that if a symlink-farm-based strategy is used, then delegating the
creation of the individual symlinks to individual packages' maintainer
scripts has practical problems, and it would be better to centralize the
creation of those symlinks (somehow). I think it's up to the people who
want to generate symlink farms to solve that problem.

Note that what the Technical Committee resolved as the desired state
is merged /usr with aliasing symlinks such as /bin -> usr/bin, not a
symlink farm with individual symlinks such as /bin/sh -> /usr/bin/sh,
precisely because we are concerned about the number of "moving parts"
involved in setting up a symlink farm. (Speaking for myself here, not
for the TC, but I don't think I'm misrepresenting anyone's position on
the symlink farm approach by saying this.)

> The collateral damage of the merged-/usr
> work to the work I'm interested in is huge.

In this specific case, I think the thing you're having a problem with is
the gradual, file-by-file migration of executables into /usr by individual
packages and individual packages' maintainers. That's not merged-/usr:
merged-/usr does the migration all at once, by creating the aliasing
symlinks (and then we can clean up the contents of data.tar.* to put all
/usr-like files below /usr at our leisure, during the next release cycle,
without needing maintainer script glue).

The aliasing symlinks create problems for dpkg, as Guillem has documented
elsewhere, and as a result some people are pursuing a symlink-farm-based
alternative to the aliasing symlinks. If that symlink-farm-based approach
is taken, then yes, we will need either a centralized mechanism to
construct those symlink farms, or a lot of maintainer script glue
(and, again, the Technical Committee's recommendation was to not do that).

The packages that needed maintainer-script changes *before* merged-/usr,
in order to enable merged-/usr, are those that previously shipped files
at both /foo and /usr/foo in their data.tar.*, such as
coreutils (<< 8.24-1) for /{usr/,}bin/touch. The reason they need
maintainer script code is that we still support non-merged-/usr systems;
their maintainer scripts are a no-op on merged-/usr systems, so if the
bookworm release only supported merged-/usr, then their maintainer
script code could disappear during the bookworm+1 cycle.

I agree that *those* maintainer scripts are creating extra work for
people working on DPKG_ROOT and similar things, and would not have been
necessary if we had not gone in the direction of merged-/usr in around
2016. If we can make those unnecessary, or more declarative, then that
would be a good direction.

smcv

Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system

[Michael Biebl]

Am 19.08.21 um 08:27 schrieb Michael Biebl:
I'll check later today, if i-s-h (init-system-helpers) does properly 
handle this new path. If so, I'd say the bug should be reassigned to 
lintian and we should start transitioning the files to 
/usr/lib/systemd/system.


I now remember updating i-s-h [1].

So we should be safe using /usr/lib/systemd/system I'd say.

There is a cosmetic issue that the enablement symlinks in 
/etc/systemd/system/*.target/ will now be dangling on unmerged systems 
(they will point at the files in /lib/systemd/system). But systemd will 
consider such services as enabled. At least, as long we still build 
systemd with split-usr support.
If anyone wants to provide a patch to fixup such symlinks on upgrades, 
then this would be nice.


Michael


[1] 
https://salsa.debian.org/debian/init-system-helpers/-/commit/552e993488a403bf88aa342f73bf0b22ce62ff16





OpenPGP_signature
Description: OpenPGP digital signature

Re: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system

[Luca Boccassi]

On Thu, 2021-08-19 at 08:27 +0200, Michael Biebl wrote:
> Am 19.08.2021 um 06:18 schrieb Theodore Ts'o:
> > There appears to be a rather major regression in debhelper 1.13.4 and
> > 1.13.4nmu1, which is forcing unit files to go in
> > /usr/lib/systemd/system, instead of /lib/systemd/systemd (where sytemd
> > will actually pay attention to them).
> 
> 
> Installing those files in /usr/lib/systemd/system is fine.
> systemd itself will handle them just as well as when they are installed 
> in /lib/systemd/system (see systemd-analyze unit-paths).
> It's our own tooling (debhelper, i-s-h, lintian) which preferred a 
> single path, i.e. /lib/systemd/system.
> 
> I wanted to get debhelper updated anyway in the bookworm release cycle 
> to prefer /usr/lib/systemd/system over /lib/systemd/system, but 
> obviously this should have happened in a more orderly fashion, i.e. 
> lintian would have been updated first.
> 
> I'll check later today, if i-s-h (init-system-helpers) does properly 
> handle this new path. If so, I'd say the bug should be reassigned to 
> lintian and we should start transitioning the files to 
> /usr/lib/systemd/system.
> 
> 
> Michael



This is indeed the right thing to do moving forward, so updating
Lintian would be the best outcome. Thanks!

-- 
Kind regards,
Luca Boccassi


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

Re: Debian choice of upstream tarballs for packaging

[Jonas Smedegaard]

Quoting Marc Haber (2021-08-19 09:12:27)
> On Tue, 17 Aug 2021 19:16:05 +0200, Jonas Smedegaard 
> wrote:
> >Quoting Marc Haber (2021-08-17 18:56:59)
> >> There is, for example, one distribution that is based on Ubuntu 
> >> (maybe they thought that ubuntu would be too hard to install) and 
> >> does not support upgrades. Their FAQ says "we cannot support 
> >> upgrades because we're based on Debian which doesnt support 
> >> upgrades".
> >
> >Sorry, I fail to understand what was the point of last paragraph 
> >above. Would you mind spelling it out to me?
> 
> This was just a rant about a downstream distribution that broke one 
> Debian's key feature (seamless, supported, painless upgrades) and 
> blamed their own failure on Debian.

Ah, thanks.  I get it now.  Sorry for my think skull...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: A summary of where I think we are on the technical side of the merged /usr discussion

[Helmut Grohne]

Hi Simon,

On Tue, Aug 17, 2021 at 05:19:06PM +0100, Simon McVittie wrote:
> If we want to make buildd chroots merged-/usr any time soon, then I
> think we need to say this class of bugs is RC for bookworm.

I fear there might be a logic trap here.

For a moment, let us assume perfection of this plan: Reproducible builds
identify all of the cases that need to be fixed. We bump them to RC
bugs. We fix them all. Then we change unstable to be merged-/usr and
we're done. Are we? We still need to support partial upgrades from
bullseye to bookworm, so - as you pointed out earlier - all packages in
bookworm will have to keep this support property. However, our
defaulting to merged-/usr makes it impossible for reproducible builds to
test it as producing an unmerged chroot is no longer possible.
Effectively, the unmerged case will be untested and as a consequence
will be broken.

For this plan to work, we will have to support unmerged chroots until
the end of bookworm, which appears to contradict the premise we started
with.

> This class of bugs applies equally to anything that makes an executable
> available at both /bin/foo and /usr/bin/foo, so even if people want to
> disregard the two Technical Committee resolutions on the subject of
> merged-/usr and look for consensus around symlink farms in the root
> filesystem instead, we'll probably still need to make sure bugs of this
> class get fixed.

You keep proposing adding /bin/foo -> /usr/bin/foo symbolic links via
maintainer scripts. Indeed people are already adding such links.
Unfortunately, the way they do it breaks DPKG_ROOT. It also undermines
the work of Niels Thykier, myself and others to reduce the number of
maintainer scripts in Debian. The collateral damage of the merged-/usr
work to the work I'm interested in is huge.

Would it be possible to add some central helper for the creation of
these links such that I could fix this helper once instead of hunting
down hundreds of copies of these DPKG_ROOT bugs with ever more being
added? Or maybe we could even do this declaratively by adding a
/usr/share/usr-merge.d/ file containing paths that need compat
symlinks that would be instated by some essential package via triggers?

We keep saying that Debian work is voluntary, but this is only true in
theory, because Debian is about integrating and combining components. I
would like to ignore merged-/usr, but the collateral damage has cost me
at least a week already (mostly due to having broken dpkg-shlibdeps).
The story is worse for Guillem Jover. We can assert that the current
/usr-merge implementation is significantly hampering innovation by
dumping work on people that would otherwise improve Debian. It is this
aspect that makes me unhappy about merged-/usr. The support received
from merged-/usr proponents with diagnosing and fixing issues is
suboptimal.

Yours disappointed

Helmut

Re: Debian 11 Bullseye Setup Problems Error Report

[admin4]

Hello all valuable and constructive contributors :)

1) so thanks again for Debian it is just a lovely distro

2) forgot to mention: was using the net install ISOs for the test
(hardware used server hp proliant g6 (amd64) (the raid is detected
fine!)

and lenovo laptop x60s (i386)


https://ftp.halifax.rwth-aachen.de/debian-cd/11.0.0/amd64/iso-cd/


 1. because they are minimalism
 2. let me install just what is needed
 3. fit on a CD

testers are an important part of the team :)

https://www.youtube.com/watch?v=HTFbLyUQSbw


best regards

On 8/18/21 12:33 PM, Andrey Rahmatullin wrote:
> On Wed, Aug 18, 2021 at 12:25:58PM +0200, admin4 wrote:
>> Hello all, in short,
>>
>>   * is there a Debian "testing" team?, that does test setups of Debian
>> ISOs on a bunch of different hardware with priority on the most used
>> CPUs like amd64 and i386, (free and non-free versions)),
>>   * before the ISOs spread across the world on all those nice download
>> servers, for further "public beta" testing?
>>   * does-it-work-well.sh script could
>>   o 1) ask the user if everything works fine (rating from 1 to 5 stars)
>>   + and user can add a comment ( send some praise or comments
>> what does/did not work )
>>   o 2) scan the hardware specs of the system
>>   + anonymized! without any serials and mac addresses or ip
>> addresses or screen resolutions!, before uploading it to
>> debian.org/hardware-compatibility-list
>>   # where the hardware is marked in green (works) orange
>> (can be made to work with this (link) workaround) or red
>> (fails, no fix available currently)
> Yes, testing the pre-release ISOs and filing installation-report bugs is
> encouraged during freezes.

Re: Debian choice of upstream tarballs for packaging

[Marc Haber]

On Tue, 17 Aug 2021 19:16:05 +0200, Jonas Smedegaard 
wrote:
>Quoting Marc Haber (2021-08-17 18:56:59)
>> There is, for example, one distribution that is based on Ubuntu (maybe 
>> they thought that ubuntu would be too hard to install) and does not 
>> support upgrades. Their FAQ says "we cannot support upgrades because 
>> we're based on Debian which doesnt support upgrades".
>
>Sorry, I fail to understand what was the point of last paragraph above. 
>Would you mind spelling it out to me?

This was just a rant about a downstream distribution that broke one
Debian's key feature (seamless, supported, painless upgrades) and
blamed their own failure on Debian.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834