Changing how you do things: Was Re: merged /usr

[Tim Woodall]

On Mon, 16 Aug 2021, David Kalnischkies wrote:


/usr/bin/apt exists for 8 years now and the release notes advice using
it in every section. So, how come people are still typing apt-get
interactively to upgrade?

Best regards

David Kalnischkies

P.S.: For the avoidance of doubt: apt-get is of course going nowhere,
but that cuts both ways: It isn't changing as your fingers hate change ?
so e.g. no new interactive questions fingers aren't trained to answer?



One of the problems is that the "upgrade" path is never easy for
experienced users. One thing that could help would be something like:

-o APT::NewCommand=yes option (or something like that) that to
apt-get/apt-cache which took the command line and told you exactly what
apt incantation you need to achieve exactly the same results.

I'm looking at a script of mine that can take around 20 minutes to
complete and has 9 apt-get incantations.

I have things like;
DEBIAN_FRONTEND=noninteractive apt-get -q -y install \
  -o APT::Architecture=${ARCH} -o APT::Install-Recommends=false \
  -o APT::Get::Simulate=true -o RootDir=image apt | tee apt-simulate.log

and then the rest of the script depends on the contents of
apt-simulate.log

I could update it to apt - but the script currently supports four
releases across four architectures. So even if the changes are all
"no-brainers" it's going to take an overnight run to confirm that
everything still works. And if, inevitably, there are tweaks required,
then it becomes a long drawn out red queen's race. This is a personal
project "for fun" and "because I can" and time taken updating this
script to apt "because the documentation says I should" is time I cannot
spend on more interesting stuff (from my PoV)

Even upgrading from buster to bullseye is potentially fraught - perhaps
apt-simulate.log will change. One of my projects over the last few years
has been to slowly change so that everything now runs in VMs and each VM
should only do one thing - that way upgrades can be managed and breaking
changes can be handled one by one. I think I'm finally in position to
consider adopting systemd. I had dozens of init scripts, udev rules etc,
some of which have barely been touched for a couple of decades that will
all need to be rewritten, some of which I need to "just work" (and some
of which possibly don't do anything any more but I've never noticed...)

The script I commented on above is part of my project to ensure that any
and all changes to the default debian install are done via packages. I'm
not there yet but, for example, I can now rebuild a VM from scratch and
then diff things like /etc to check that I've captured everything in a
package. I started this project two years ago today (coincidence!) and
last week I finally got into the state where I can do that for
everything I use at home. I still have changes I need to package, and I
still have VMs that are running too many unrelated services, but I'm
slowly getting there.

Ironically, the /usr-merge is almost a "no brainer" for me. It's only
after reading the comments here that I realize it's actually a difficult
problem to solve cleanly because it's so easy for me to deal with. I can
see why Guillem is frustrated.

Re: Debian choice of upstream tarballs for packaging

[Simon Josefsson]

Paul Wise  writes:

> Hi all,
>
> I noticed that sometimes Debian's choice of upstream source for
> packaging can be suboptimal. This is especially apparent for the
> different per-language upstream packaging ecosystems[1], where the
> upstream packaging differs from the upstream VCS in some significant
> ways, including missing files, prebuilt files, embedded copies etc.
>
> While the upstream VCS also sometimes has these issues, it is often
> much less problematic than the upstream packaging ecosystems.

While I agree with the points you raise, and think I agree with your
overall goal, I see some problems with using upstream VCS as a source
for Debian packaging:

1) Trust paths.  Some upstreams sign release tarballs with an OpenPGP
release key that Debian trust for making releases.  Not all upstream
uses the same key to sign VCS tags/commits, and not all upstreams sign
VCS tags/commits at all.  While Debian can encourage and promote new
policies for upstream here, I don't think we are in a position to
require any uniform set of rules.  Signing tarballs is the current
established best practice -- moving to VCS builds needs a set of new
schemes to be established and deployed, and I don't see any single
universal solution today.

2) Bootstrapping projects from VCS is complex and requires additional
tools, and I think the Debian packaging process is well suited for this.
Two examples that I have run into:

  2a) Gnulib.  Several GNU-related projects import files from gnulib
  during VCS bootstrapping, and the way this happens is different for
  different projects.  The correct version of the files must be imported
  in the right way for things to work, and knowledge of which gnulib
  version is used is not always present in VCS but only in a released
  tarball.  How would this work when packaged in Debian?  A debian
  package containing the gnulib git repository could be added, to allow
  source packages to checkout the right version during build.

  2b) Cross-compilation and dependency cycles.  Bootstrapping from VCS
  may require a lot of tools that are optional when building from
  tarball, and in my experience the complete set of tools to bootstrap a
  project is rarely added as Build-Dep to Debian packages.  I feel some
  additional package build dependency mechanism would help here: maybe a
  Build-Bootstrap-Dep header to list the tools needed to generate a
  Debian source package?  And Build-Dep could list the tools needed to
  build Debian binary packages from the Debian source package.  I admit
  my understanding of the Debian packaging system is quite limited
  though.

3) Bootstrappable builds.  I think the underlying goal when it comes to
building from VCS may be to achieve bootstrappable builds -- see
https://www.bootstrappable.org/ -- however it seems to me that a lot of
care has to be taken when moving from tarball builds to VCS builds so we
don't make it harder to re-bootstrap the entire toolchain.  For example,
building GNU Coreutils from a tarball works fine in extremely old
environments, but building GNU Coreutils from VCS requires modern tools,
and perhaps some of them doesn't support older environments any more.

/Simon


signature.asc
Description: PGP signature

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

[Simon Richter]

Hi,

On 8/18/21 12:21 AM, Luca Boccassi wrote:


On Tue, 17 Aug 2021 at 20:17, Simon Richter  wrote:



I agree that it's likely the only thing we can do with the version of
dpkg that we ship now, and that will have to handle the upgrade for any
users that move from one stable release to the next provided there is no
project consensus to deviate from "apt dist-upgrade" as the preferred
method of upgrading to the next release.



That is the case only if the plan is to deprecate support for
external/third-party repositories/packages, since there's no way to do
the required per-package work on those, and this strategy can only
work (and that's a non-trivial assumption already, given so far it has
a 100% failure rate) if every single package that will ever be
installed on every single system is updated individually.


My expectation would be that there are rather few third-party packages 
installing files into the directories we want to clear out, and we have 
two years in which we can tell people to get these packages updated.



Also the "unsupportable" statement is kinda hard to reconcile with the
reality of this being default on Ubuntu for 2+ years, which uses the
very same dpkg. It would be very useful to have someone from Canonical
comment on what problems are there in reality? Launchpad shows only 2
bugs, which appears to be both corner cases:
https://bugs.launchpad.net/ubuntu/+source/usrmerge


That is why I wrote "provided there is no project consensus to deviate 
from "apt dist-upgrade" as the preferred method of upgrading to the next 
release." This is what Ubuntu did.


We can repeat that, which will anger a lot of users.

   Simon



OpenPGP_signature
Description: OpenPGP digital signature

Re: Debian choice of upstream tarballs for packaging

[Simon Richter]

Hi,

On 8/18/21 5:04 AM, Paul Wise wrote:


This is also an additional burden on package maintainers: explaining how
they arrived at that particular "upstream" package in a reproducible way



Debian explaining how we arrived at a particular orig.tar.gz is well
established; use a debian/watch file. It supports accessing git
repositories directly.


Yes, but it needs to be explained on a per-package basis, especially if 
there is an upstream .tar.gz. Debian has historically shipped bitwise 
identical files from upstream, and has been lauded for that as it makes 
verification easy.



and why what we ship as "orig" is different from upstream, and what
the copyright and licensing situation for that derived work is.



I see it another way, the upstream packages/tarballs are usually a
derived work of their VCS, adding cruft that should not be there and
removing files that should be there.


I am talking from a legal point of view. We would be creating a derived 
work from upstream VCS that is different than the official upstream 
release, and then claim this to be the "original" source.


There is a reason we highlight removal of files for licensing reasons in 
the file name with a large "dfsg" marker: to indicate that this is a 
derived work. If we were to prefer upstream VCS to upstream release 
tarballs, I'd expect a similar marker.


   Simon



OpenPGP_signature
Description: OpenPGP digital signature

Re: Debian 11 Bullseye Setup Problems Error Report

[admin4]

Hello Paul,

thanks for the timely reply.

On 8/18/21 4:33 AM, Paul Wise wrote:
> On Tue, Aug 17, 2021 at 10:39 AM admin4 wrote:
>
>> today was the day trying out the new Debian 11 with LTS (LTS is a reason for 
>> users consider switching to Ubuntu, so good choice there)
> Debian 11/bullseye is not in LTS mode yet. Debian 10/buster will be in
> LTS mode in a year's time when regular security support for it ends.

thanks for the info, alright, sounds good, Debian 10 runs just fine
right now :)

> Debian 11/bullseye will be in LTS mode one year after the release of
> Debian 12/bookworm in approximately two year's time.
>
>> 2) the problems:
>>
>> E1: (error1) problem: Debian 11 won't install
> Please ask for help debugging this on Debian support channels and once
> you know what the problem is, then file an installation report.
>
> https://www.debian.org/support
> https://www.debian.org/releases/stable/amd64/ch05s04#submit-bug
>
>> S1: (suggestion1) there needs to be an easy way to report errors
> The Debian bug reporting tool is called reportbug, please file issues
> using it. If you don't know which package is at fault, you can ask on
> our support channels to find out.
is this tool available during setup? with no network connection?
https://itsfoss.com/bug-report-debian/

>
> https://www.debian.org/Bugs/Reporting
> https://www.debian.org/support
>
>> Q1: (question1): why is there nor vi nor less included in the setup?

in theory yes... in reality try this:

wget https://thesquareplanet.com/feed.xml

cat feed.xml |nano # wohooo it works

*Too many errors from stdin**
*

*Buffer written to nano.save*

*# argh, only works for small files!?*

can not handle large files?


> Sounds like a question for the support channel, but I assume it is
> because nano is available, which is a user-friendly alternative to vi,
> and can also replace less.

"Note that your installation report will be published in the Debian Bug
Tracking System (BTS) and forwarded to a public mailing list."

"Make sure that you *use an e-mail address that you do not mind being
made public*"

https://www.debian.org/releases/stable/amd64/ch05s04#submit-bug


here we go admin4 into the spam database... for trying to report a
problem and improve a GNU Linux distribution.

will try that

cu

Re: merged /usr

[Simon McVittie]

On Tue, 17 Aug 2021 at 23:24:26 -0400, Theodore Ts'o wrote:
> That being said, you do have a good point that there might be scripts
> that have "/sbin/fsck." hard-coded in the shell scripts, just as
> I've seen /bin/rm, /bin/mv, etc., hard coded in some shell scripts ---
> not to mention "#!/bin/sh" or "#!/bin/bash" as the first line in
> gazillions of scripts.  So getting rid of all of compatibility
> symlinks whether done via a symlink tree or top-level symlinks for
> /bin, /sbin, /lib, etc., is probably not realistic for decades.

Yes. This is a large part of why merged-/usr goes for the
maximum-compatibility approach: make literally everything in /bin
(etc.) available via both /bin and /usr/bin (etc.), so that if someone
has hard-coded one of those paths into a script or similar, it doesn't
matter which one they chose (which in the case of upstream software might
have been correct for their distro but not for historical Debian). Doing
this for everything is simpler and more consistent than trying to decide
whether it's necessary case-by-case.

I'm not sure whether there's any plan to remove the /bin, /sbin, /lib
symlinks *ever* - things like /bin/sh are a de facto API, and the
ELF interpreters like /lib/ld-linux.so.2 are part of their respective
architectures' interoperable ABIs (to the extent that we make exceptions
to our usual reluctance to use libQUAL directories, in order to accommodate
/lib64/ld-linux-x86-64.so.2 and similar).

I suspect that hard-coding paths to "sbin executables" might be more
common than "bin executables", because /sbin:/usr/sbin are not in the
default PATH for non-root users on distros like Debian (that's the point
of sbin after all), but it's sometimes useful for non-root users to invoke
a sbin executable even though they are not root - for example to run mkfs
on a disk image in a file, or to query the contents of the ldconfig cache.

> That being said, the number of inodes that we might need for symlink
> farms for /bin, /sbin, et.al. is *not* something I'm terribly fond of.
> It's probably not a show-stopper to add that many symlinks,
> but... yelch.  So my personal preference, even if it required making
> changes in dpkg so it was aware of directory aliases, and requiring
> that dpkg getting updated first in the bullseye->bookworm upgrade
> would be to stick with usrmerge.

Yes. The Technical Committee unanimously voted for merged-/usr (with
the directory aliasing, as implemented in usrmerge and debootstrap)
in #914897, and did not modify this view in #978636, so I'm glad you
agree. Our concern was more about the number of "moving parts" involved
in setting up the symlink farms than about the inode count and aesthetic
properties of a symlink farm, but I can't say the symlink farm is very
appealing aesthetically either!

> On that front: is the list of potential problems vis-a-vis dpkg and
> usrmerge here[1] comprehensive?
> 
> [1] https://wiki.debian.org/Teams/Dpkg/MergedUsr

I believe so.

> some of
> them might not be hard to mitigate via brute force techniques (e.g.,
> adding /bin/*sh and /usr/bin/*sh to /etc/shells, etc.)

In many cases that's what's already happening.

smcv

Re: Debian 11 Bullseye Setup Problems Error Report

[Andrey Rahmatullin]

On Wed, Aug 18, 2021 at 10:54:17AM +0200, admin4 wrote:
> >> Q1: (question1): why is there nor vi nor less included in the setup?
Both are included, less has Priority: standard, vim-tiny has Priority:
important.

> in theory yes... in reality try this:
> 
> wget https://thesquareplanet.com/feed.xml
> 
> cat feed.xml |nano # wohooo it works
> 
> *Too many errors from stdin**
> *
> 
> *Buffer written to nano.save*
> 
> *# argh, only works for small files!?*
> 
> can not handle large files?
vi doesn't support this either. You just shouldn't pipe files to editors
and call `nano feed.xml` instead.

> "Note that your installation report will be published in the Debian Bug
> Tracking System (BTS) and forwarded to a public mailing list."
> 
> "Make sure that you *use an e-mail address that you do not mind being
> made public*"
> 
> https://www.debian.org/releases/stable/amd64/ch05s04#submit-bug
> 
> 
> here we go admin4 into the spam database... for trying to report a
> problem and improve a GNU Linux distribution.
Well, you mailed a mailing list directly instead, doing the same thing.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

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

[Luca Boccassi]

On Wed, 2021-08-18 at 10:43 +0200, Simon Richter wrote:
> Hi,
> 
> On 8/18/21 12:21 AM, Luca Boccassi wrote:
> 
> > On Tue, 17 Aug 2021 at 20:17, Simon Richter  wrote:
> 
> > > I agree that it's likely the only thing we can do with the version of
> > > dpkg that we ship now, and that will have to handle the upgrade for any
> > > users that move from one stable release to the next provided there is no
> > > project consensus to deviate from "apt dist-upgrade" as the preferred
> > > method of upgrading to the next release.
> 
> > That is the case only if the plan is to deprecate support for
> > external/third-party repositories/packages, since there's no way to do
> > the required per-package work on those, and this strategy can only
> > work (and that's a non-trivial assumption already, given so far it has
> > a 100% failure rate) if every single package that will ever be
> > installed on every single system is updated individually.
> 
> My expectation would be that there are rather few third-party packages 
> installing files into the directories we want to clear out, and we have 
> two years in which we can tell people to get these packages updated.

Given we are talking about /bin /lib and so on, there are many, many
that actually do. Most don't even use dpkg-buildpackage to build, let
alone debhelper, but third party systems like cmake/gradle, most often
than not vendored and pinned at a specific version. Or even worse
custom makefiles/scripts, which might not even be developed publicly.
The usrmerge approach deals with this just fine. What is the concrete
plan of action for the symlink-farm approach to 1) find them all out,
and 2) to update them all? There has to be one: otherwise there will be
an unspecified and unknowable large number of machines that forever
will be unable to run the proposed algorithm to switch from symlink
farm to actual usr-merged, with no path to move out of it, so the two
states will always have to be supported: symlinks farm and real merged-
usr.

> > Also the "unsupportable" statement is kinda hard to reconcile with the
> > reality of this being default on Ubuntu for 2+ years, which uses the
> > very same dpkg. It would be very useful to have someone from Canonical
> > comment on what problems are there in reality? Launchpad shows only 2
> > bugs, which appears to be both corner cases:
> > https://bugs.launchpad.net/ubuntu/+source/usrmerge
> 
> That is why I wrote "provided there is no project consensus to deviate 
> from "apt dist-upgrade" as the preferred method of upgrading to the next 
> release." This is what Ubuntu did.
> 
> We can repeat that, which will anger a lot of users.

What specific features/workaround/fixes/etc were implemented in the
Ubuntu upgrader to deal with merged-usr?

-- 
Kind regards,
Luca Boccassi


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

Re: Debian Policy 4.6.0.0 released

[Aurelien Jarno]

Hi,

On 2021-08-17 20:35, Sean Whitton wrote:
> Hello everyone,
> 
> I just pushed version 4.6.0.0 of the Debian Policy Manual and related
> documents to sid.  Below you will find the significant normative changes
> from the previously announced release of Policy (4.5.1).

[snip]

> 9.1.1
> No package is allowed to install files in ``/usr/lib64/``. Previously,
> this prohibition only applied to packages for 64-bit architectures.

This path is used by the multilib 64-bit toolchain on 32-bit
architectures, for instance libc6-amd64:i386, or a few essential
libraries like ncurses.

What kind of fix do you expect on the packages? Is it finally the time
to get rid of multilib and use pure multiarch instead?

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Re: Debian 11 Bullseye Setup Problems Error Report

[admin4]

Hello Andrey,

On 8/18/21 11:20 AM, Andrey Rahmatullin wrote:
> On Wed, Aug 18, 2021 at 10:54:17AM +0200, admin4 wrote:
 Q1: (question1): why is there nor vi nor less included in the setup?
> Both are included, less has Priority: standard, vim-tiny has Priority:
> important.

after setup is complete yes, but during the setup / when doing a setup
of Debian 11 iso via
https://ftp.halifax.rwth-aachen.de/debian-cd/11.0.0/


during the setup neither less nor vi are available in the consoles (what
gnu linux is used during setup? busybox?)

>> in theory yes... in reality try this:
>>
>> wget https://thesquareplanet.com/feed.xml
>>
>> cat feed.xml |nano # wohooo it works
>>
>> *Too many errors from stdin**
>> *
>>
>> *Buffer written to nano.save*
>>
>> *# argh, only works for small files!?*
>>
>> can not handle large files?
> vi doesn't support this either. You just shouldn't pipe files to editors
> and call `nano feed.xml` instead.

but then nano can not replace less as stated by p...@debian.org

best regards

Re: Debian 11 Bullseye Setup Problems Error Report

[Andrey Rahmatullin]

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.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Use files created during CI to seed trust and attract new users?

[Steffen Möller]

Hello,

When CI fails, I get an email and can chase things up with a look at the
output files. This is something I like a lot. As a user, though,
especially for scientific packages I would want to see the files that
have been created. This way I could confirm that, e.g., the generated
PDFs have usable fonts and if a test follows an established workflow for
a well-known dataset, I can also compare the results generated during
testing with the ones expected. "Expected" could be the files a Mac user
generated when installing the package locally, a less technical user may
know a tutorial (a nice one that I want to address is on
https://docs.qiime2.org/2021.4/tutorials/moving-pictures/) and would
then compare the CI-generated image with the one presented online by
upstream.

There are many problems with this suggestion, to mind come
 * amount of data to be handled as input
 * amount of data to be stored
 * unclear acceptance by users
 * too much extra compute
 * ... please add what comes to your mind ...

My sketch of an idea was that we could possibly have in analogy to the
debian/install files an extension to the test instructions that define a
set of files, preferably together with a description, that may be
worthwhile to be inspected by end users as a proof that the package
works. A test report would then be generated with links to these files.

Is this anything we would want to have? Do we have this already and I
just failed to find this?

Many thanks!
Steffen

Re: Debian 11 Bullseye Setup Problems Error Report

[admin4]

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)

just trying to help ensure the quality of Debian stays rock solid and
frustration free especially for new users, that might not want to wait
for days, until a fix is uploaded and then simply go to ubuntu

but as Debian is the basis for Ubuntu, if Debian is broken, so is then
probably Ubuntu

best regards

Re: Changing how you do things: Was Re: merged /usr

[David Kalnischkies]

On Wed, Aug 18, 2021 at 08:33:01AM +0100, Tim Woodall wrote:
> […] and time taken updating this
> script to apt "because the documentation says I should" is time I cannot
> spend on more interesting stuff (from my PoV)

For the record: The apt documentation says the opposite. /usr/bin/apt
is even annoyingly insistent on not being run inside a script or even
its output being redirected to a file.


I was talking (in half-jest) about interactive usage – aka your fingers
typing all commands manually into a terminal one by one. That is also
what the release notes are primarily concerned with.


We know perfectly well that apt-get is used all over the place in the
strangest of usecases by scripts potentially nobody knows howto or has
the time to maintain. As a result apt-get (and the rest of the apt-*
family) aren't changing their behaviour much if at all from release to
release, which results in some behaviour being suboptimal if not
downright bad, but the default none the less as it would be too costly
to change the default (a fun example of a minor change having unexpected
consequences is breaking Debian CD building with apt-cache show #712435).

apt on the other hand can be changed "at will" as we expect a being on
the other side of the terminal who is able to react to changes like
a new question asking if this potentially security relevant change is
okay & expected. Scripts can't usually react, with them we can only
communicate via failing the execution if we deem the risk high enough to
do so to hopefully summon a being capable of reasoning to look into the
failing of the script.


btw: `apt-config dump Binary::apt` will tell you (most) of the config
options apt changes compared to the 'old' defaults in apt-get and co.
There aren't that many (so far).


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#992429: ITP: libapache-session-mongodb-perl -- Apache::Session implementation for MongoDB databases

[Yadd]

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

* Package name: libapache-session-mongodb-perl
  Version : 0.21
  Upstream Author : Xavier Guimard 
* URL : https://metacpan.org/release/Apache-Session-MongoDB
* License : Artistic-1.0 or GPL-1+
  Programming Lang: Perl
  Description : Apache::Session implementation for MongoDB databases

Apache::Session::MongoDB module is an implementation of Apache::Session.
It uses the MongoDB backing store and no locking.

This module is one of the backends proposed by lemonldap-ng Web-SSO
system.

Cheers,
Yadd

Re: Debian Policy 4.6.0.0 released

[Scott Talbert]

On Tue, 17 Aug 2021, Sean Whitton wrote:


Hello everyone,

I just pushed version 4.6.0.0 of the Debian Policy Manual and related
documents to sid.  Below you will find the significant normative changes
from the previously announced release of Policy (4.5.1).

The formal upgrading checklist is short, but also included in this
release is important work by Russ Allbery to improve how we use Policy's
explicitly normative terms -- 'must', 'should', 'recommended', etc.
These keywords are now used more consistently.  We have also introduced
a new category of statements which we are calling "Policy advice".  The
addition of this category should make it easier to incorporate
descriptions of more of our best practices into Policy.  Please see 1.1.

There are also a number of miscellaneous corrections.  Thank you to
those who submitted bug reports and patches.

=*=*=*=

9.1.1
   No package is allowed to install files in ``/usr/lib64/``. Previously,
   this prohibition only applied to packages for 64-bit architectures.

12.1
   Manual pages may be included in dependencies, not only in the packages
   containing the things they document.


Hi,

The upgrading checklist on [1] is for version 4.5.2.  I could be wrong, 
but doesn't this usually match first parts of the policy version 
(4.6.0.0)?


[1] 
https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-5-2

Thanks,
Scott

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

[Tim Woodall]

On Tue, 17 Aug 2021, Sam Hartman wrote:


"Luca" == Luca Boccassi  writes:


   Luca> Wouldn't a pre-depends solve the ordering problem in this
   Luca> case?

No.

At least it's really hard to prove that it does, we have a bad track
record of getting it wrong, and if it were to work in a
specific instance it would depend on implementation details rather than
simply on guarantees made by the interfaces of dpkg and apt.

I'm not saying that something like that can't be part of a solution.  If
it is, it will be because someone put in real effort into reasoning
about the correctness of the solution.

--Sam




I'm not proposing this as a solution, or even a part solution, but I
have a script that generates a set of Depends: between essential
packages that (I believe) guarantees that they will install and will (I
hope) "fail" if no such solution is possible.

(I don't use this any more, I'm using "essential-on-a-diet" which I
manage manually but it's something I have which others might be able to
adapt into something more useful)

http://www.woodall.me.uk/debian/find_depends.sh

Re: merged /usr

[Marco d'Itri]

On Aug 18, Simon McVittie  wrote:

> I'm not sure whether there's any plan to remove the /bin, /sbin, /lib
> symlinks *ever* - things like /bin/sh are a de facto API, and the
> ELF interpreters like /lib/ld-linux.so.2 are part of their respective
> architectures' interoperable ABIs (to the extent that we make exceptions
> to our usual reluctance to use libQUAL directories, in order to accommodate
> /lib64/ld-linux-x86-64.so.2 and similar).
Indeed: there has never been any plan to remove the compatibility 
symlinks and I still see no point in trying.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

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

[Gunnar Wolf]

Clint Adams dijo [Wed, Aug 18, 2021 at 04:20:02AM +]:
> > Besides, will the new "which" tool be installed in Debian by default? Since
> > debianutils is Essential:yes, not providing "which" tool by default could
> > probably break some existing packages.
> 
> My personal opinion is that no one should be using `which` in maintainer
> scripts and that no one should be using `which` in an interactive shell
> unless it is a builtin of that shell.
> 
> There are a ton of postinst scripts relying on `which` right
> now, which makes sense because `type` and `command -v` used to be
> optional extensions to POSIX and not guaranteed to be provided
> by /bin/sh.

I agree with you, maintainer scripts should not rely on 'which'
anymore. However, what about users? 'which' is a standard Unix tool
since forever, and I expect many users to experience head scratching
when told it's not cool to use it anymore.

src:developers-reference - pt_BR translation initiative

[Thiago Pezzo (tico)]

Hi, there,

I have been thinking about opening a new translation front to our team, when
I saw Holger’s talk about the developer's reference handbook [1]. It would be
another great opportunity to our (small) team to contribute to the Debian
community.

I was considering a solution using OmegaT [2] along with git. Holger, are you
thinking about moving the files to some web platform that does not use git?
Because if this is the idea, I would prefer to wait and to not use the OmegaT
solution, so our team can move along with all other teams to the chosen
platform.

[1] 
https://debconf21.debconf.org/talks/93-srcdevelopers-reference-wants-your-help
[2] https://omegat.org

Thank you and be well!

Thiago Pezzo (tico)
Debian pt_BR Localization Team
https://wiki.debian.org/Brasil/Traduzir

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

[Andrey Rahmatullin]

On Wed, Aug 18, 2021 at 12:36:43PM -0500, Gunnar Wolf wrote:
> I agree with you, maintainer scripts should not rely on 'which'
> anymore. However, what about users? 'which' is a standard Unix tool
> since forever, and I expect many users to experience head scratching
> when told it's not cool to use it anymore.
Why is a standard Unix tool since forever shipped by a package called
debianutils, that has a description saying "Miscellaneous utilities
specific to Debian" and "used primarily by the installation scripts of
Debian packages"? Surely a standard Unix tool would, or at least could, be
shipped somewhere else?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#992446: ITP: django-graphiql-debug-toolbar -- Django Debug Toolbar for GraphiQL IDE

[Carsten Schoenert]

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

* Package name: django-graphiql-debug-toolbar
  Version : 0.1.4
  Upstream Author : mongkok 
* URL : https://github.com/flavors/django-graphiql-debug-toolbar
* License : MIT
  Programming Lang: Python
  Description : Django Debug Toolbar for GraphiQL IDE

 This package adds a debug toolbar within your Django application for
 the GraphiQL IDE.

This package is an direct dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.

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

[Ben Hutchings]

On Wed, 2021-08-18 at 22:58 +0500, Andrey Rahmatullin wrote:
> On Wed, Aug 18, 2021 at 12:36:43PM -0500, Gunnar Wolf wrote:
> > I agree with you, maintainer scripts should not rely on 'which'
> > anymore. However, what about users? 'which' is a standard Unix tool
> > since forever, and I expect many users to experience head scratching
> > when told it's not cool to use it anymore.
> Why is a standard Unix tool since forever shipped by a package called
> debianutils, that has a description saying "Miscellaneous utilities
> specific to Debian" and "used primarily by the installation scripts of
> Debian packages"? Surely a standard Unix tool would, or at least could, be
> shipped somewhere else?

3BSD first implemented 'which':

(1979).  This was csh-specific and I think it later became built-into
csh.

FreeBSD 2.1 introduced a new non-built-in implementation:

(1995).  This was written in Perl and then rewritten in C a few years
later.

Debian's implementation started out in 1995 or 1996 as a shell script
calling 'type', and remains a shell script.

Red Hat has yet another implementation:
,
 (1999 or earlier).  This is
written in C.

So 'which' has a very long history in csh, which was the default
interactive shell in many versions of Unix.  Its availability to other
shells dates back to the 90s (at least) but is not portable due to
there being multiple very different implementations.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. I realized that a large part of my life from then on was going
to be spent in finding mistakes in my own programs.
 - Maurice Wilkes, 1949


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

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

[Clint Adams]

On Wed, Aug 18, 2021 at 08:50:04PM +0200, Ben Hutchings wrote:
> 3BSD first implemented 'which':
> 
> (1979).  This was csh-specific and I think it later became built-into
> csh.
> 
> FreeBSD 2.1 introduced a new non-built-in implementation:
> 
> (1995).  This was written in Perl and then rewritten in C a few years
> later.
> 
> Debian's implementation started out in 1995 or 1996 as a shell script
> calling 'type', and remains a shell script.
> 
> Red Hat has yet another implementation:
> ,
>  (1999 or earlier).  This is
> written in C.
> 
> So 'which' has a very long history in csh, which was the default
> interactive shell in many versions of Unix.  Its availability to other
> shells dates back to the 90s (at least) but is not portable due to
> there being multiple very different implementations.

I'm happy to transition /usr/bin/which to alternatives if people are
interested in packaging all of these.

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

[Geert Stappers]

On Wed, Aug 18, 2021 at 06:53:45PM +, Clint Adams wrote:
> 
> I'm happy to transition /usr/bin/which to alternatives

Which alternatives would that be?


 | $ apt show alternatives
 | N: Unable to locate package alternatives
 | $



> if people are interested in packaging all of these.
> 




Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: Proposal to create unstable-proposed-updates suite for use during freeze

[Nilesh Patra]

> Hi,

> Problem: Currently uploading new upstream versions to unstable during freeze 
> is discouraged. It means users using unstable don't get new updates and 
> developers are forced to upload to experimental. Using experimental directly 
> is risky as it can have changes not ready for unstable also.
> Proposed solution: open unstable-proposed-updates with freeze and close it 
> when freeze is lifted. The packages in this suite can migrate to testing, 
> this avoids manual reuploads to unstable after freeze is lifted.

+1 to this.

 Please do not take this otherwise 

For me personally, it was an enormous amount of work (+mess?) to push
all my work to unstable. Most of my work was in git, some of it in
experimental, it is also hard to keep track of everything.
And post uploading to unstable too, its hard to keep (instant) track of the
buildds+debci for several dozens of packages I uploaded, and... I'm
still not sure if everything I intended to push is indeed pushed (though
I did do a few checks by now)

I do _not_ blame _anyone_ for it, but I think having such a suite would
really help in getting everything gets in as intended, and ofcourse
reduce the work post release.
However, it'd create a bit of extra work for buildd admins, but it
-probably- is worth the effort

> Optional: create a companion testing suite say rolling which may be used 
> during this time and a second Britney instance can manage migration to this 
> suite.

Sounds cool as well

Nilesh


signature.asc
Description: PGP signature

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

[Clint Adams]

On Wed, Aug 18, 2021 at 09:48:29PM +0200, Geert Stappers wrote:
> 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.

Re: Debian Policy 4.6.0.0 released

[Sean Whitton]

Hello,

On Wed 18 Aug 2021 at 10:57AM -04, Scott Talbert wrote:

> The upgrading checklist on [1] is for version 4.5.2.  I could be wrong,
> but doesn't this usually match first parts of the policy version
> (4.6.0.0)?
>
> [1] 
> https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-5-2

Fixed, thanks.  Will reach web mirrors later today.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Debian Policy 4.6.0.0 released

[Sean Whitton]

Hello,

On Wed 18 Aug 2021 at 11:10AM +02, Aurelien Jarno wrote:

>> 9.1.1
>> No package is allowed to install files in ``/usr/lib64/``. Previously,
>> this prohibition only applied to packages for 64-bit architectures.
>
> This path is used by the multilib 64-bit toolchain on 32-bit
> architectures, for instance libc6-amd64:i386, or a few essential
> libraries like ncurses.
>
> What kind of fix do you expect on the packages? Is it finally the time
> to get rid of multilib and use pure multiarch instead?

We did not intend to make any packages buggy with this change.  It was
thought to be just a clarification.

Russ, perhaps we should revert this?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Proposal to create unstable-proposed-updates suite for use during freeze

[Samuel Thibault]

Nilesh Patra wrote:
> Using experimental directly is risky as it can have changes not ready for 
> unstable also.

No. Enabling experimental in your sources.list doesn't actually change
anything. You have to explicitly request installing a given package from
experimental to pull it from experimental, and only that will be getting
updated from experimental, you won't inadvertently pull other packages
from experimental.

Samuel

Re: Debian Policy 4.6.0.0 released

[Johannes Schauer Marin Rodrigues]

Quoting Sean Whitton (2021-08-18 22:21:15)
> On Wed 18 Aug 2021 at 11:10AM +02, Aurelien Jarno wrote:
> 
> >> 9.1.1
> >> No package is allowed to install files in ``/usr/lib64/``. Previously,
> >> this prohibition only applied to packages for 64-bit architectures.
> >
> > This path is used by the multilib 64-bit toolchain on 32-bit
> > architectures, for instance libc6-amd64:i386, or a few essential
> > libraries like ncurses.
> >
> > What kind of fix do you expect on the packages? Is it finally the time
> > to get rid of multilib and use pure multiarch instead?
> 
> We did not intend to make any packages buggy with this change.  It was
> thought to be just a clarification.
> 
> Russ, perhaps we should revert this?

Or maybe it is finally the time to get rid of multilib and use pure multiarch
instead?

signature.asc
Description: signature

Re: Proposal to create unstable-proposed-updates suite for use during freeze

[Pirate Praveen]

On Wed, Aug 18, 2021 at 10:14 pm, Samuel Thibault 
 wrote:

Nilesh Patra wrote:
 Using experimental directly is risky as it can have changes not 
ready for unstable also.


No. Enabling experimental in your sources.list doesn't actually change
anything. You have to explicitly request installing a given package 
from
experimental to pull it from experimental, and only that will be 
getting

updated from experimental, you won't inadvertently pull other packages
from experimental.

Well, you have to inspect each package to decide if it is a 
only-uploaded-because-freeze or actually an experimental release. You 
don't get the guarantees of unstable - at least the maintainer thinks 
it is ready for a release.



Samuel

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

[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.



Groeten
Geert Stappers
-- 
Silence is hard to parse

Re: Proposal to create unstable-proposed-updates suite for use during freeze

[Cyril Brulebois]

Samuel Thibault  (2021-08-18):
> No. Enabling experimental in your sources.list doesn't actually change
> anything. You have to explicitly request installing a given package from
> experimental to pull it from experimental, and only that will be getting
> updated from experimental, you won't inadvertently pull other packages
> from experimental.

That's not entirely true. bullseye base, plus experimental:

kibi@tokyo:~$ sudo apt install -s crust-firmware
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  crust-firmware
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Inst crust-firmware (0.4-1 Debian:experimental [all])
Conf crust-firmware (0.4-1 Debian:experimental [all])

so you can still pull things from experimental “accidentally” if you're
not careful about the packages you request.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: Debian Policy 4.6.0.0 released

[Russ Allbery]

Sean Whitton  writes:
> On Wed 18 Aug 2021 at 11:10AM +02, Aurelien Jarno wrote:

>> This path is used by the multilib 64-bit toolchain on 32-bit
>> architectures, for instance libc6-amd64:i386, or a few essential
>> libraries like ncurses.
>>
>> What kind of fix do you expect on the packages? Is it finally the time
>> to get rid of multilib and use pure multiarch instead?

> We did not intend to make any packages buggy with this change.  It was
> thought to be just a clarification.

> Russ, perhaps we should revert this?

Yes, that was a subtlety that I had completely failed to grasp and didn't
realize this was way the rule was worded the way it was.  Sorry for that
mistake; we should revert it.

If we separately want to drop this in favor of pure multiarch, that's
great and we can always reflect that later, but we shouldn't make that
change based on my mistake in Policy.

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

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

[Clint Adams]

On Wed, Aug 18, 2021 at 10:59:08PM +0200, Geert Stappers wrote:
> Please do.  Make such take over possible.
> It is what 
> https://salsa.debian.org/debian/debianutils/-/merge_requests/6#note_242172
> is asking for.

Okay, you have it in debianutils 5.1-2.

Re: Debian Policy 4.6.0.0 released

[Jochen Sprickerhof]

* Sean Whitton  [2021-08-18 13:21]:

On Wed 18 Aug 2021 at 11:10AM +02, Aurelien Jarno wrote:


9.1.1
No package is allowed to install files in ``/usr/lib64/``. Previously,
this prohibition only applied to packages for 64-bit architectures.


This path is used by the multilib 64-bit toolchain on 32-bit
architectures, for instance libc6-amd64:i386, or a few essential
libraries like ncurses.

What kind of fix do you expect on the packages? Is it finally the time
to get rid of multilib and use pure multiarch instead?


We did not intend to make any packages buggy with this change.  It was
thought to be just a clarification.


Also with usrmerge libc6:amd64 will put a link in /usr/lib64/. Arguably 
this is covered in 3. but maybe should be considered.


Cheers Jochen


signature.asc
Description: PGP signature

Bug#992464: ITP: python-fastbencode -- Fast implementation of bencode serializer/deserializer

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 
X-Debbugs-Cc: debian-devel@lists.debian.org, gzl...@googlemail.com

* Package name: python-fastbencode
  Version : 0.0.4
  Upstream Author : Breezy Developers
* URL : http://github.com/breezy-team/fastbencode
* License : GPL
  Programming Lang: Python/C/Cython
  Description : Fast implementation of bencode serializer/deserializer

A fast (C/Cython-based) implementation of the bencode serialization
mechanism used by e.g. BitTorrent.

This is a new dependency for Breezy.

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

[Colin Watson]

On Wed, Aug 18, 2021 at 08:50:04PM +0200, Ben Hutchings wrote:
> Debian's implementation started out in 1995 or 1996 as a shell script
> calling 'type', and remains a shell script.

Not very important historical note: it's true that Debian had a "which"
command from 1995/1996 or so, but the current implementation doesn't
descend from that at all.

I wrote the earliest version of the current implementation from scratch,
as part of a job I held from 2000 to 2003; in that job, I worked on lots
of different Unix flavours, and we had NFS-mounted home directories so I
wanted a reasonably cross-platform ~/.bashrc.  The spectacular lack of
consistent behaviour of "which" across those platforms got in my way, so
I wrote a shell script that I could put in my ~/bin and use everywhere.
I don't remember exactly when I wrote it, but it can't have been before
2000 and I think it was probably around 2002.

I contributed that script to Debian in 2002 in response to
https://bugs.debian.org/94507, where it became clear that the previous
implementation wasn't really salvageable; Clint merged that in
debianutils 1.16.5.  It's been extended since then, but still has the
same basic approach.

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Re: Debian choice of upstream tarballs for packaging

[Paul Wise]

On Wed, Aug 18, 2021 at 8:10 AM Simon Josefsson wrote:

> 1) Trust paths.

Agreed, this is the main exception I mentioned when starting this thread.

>   2a) Gnulib.

Presumably upstream could be convinced to encode this information into
the VCS, perhaps into the standard autogen script that is usually run
before running ./configure for autotools projects, although Debian
just uses autoreconf by default. Or the debian/rules could have this
information added. Although hopefully the existing gnulib package
would just work. Since gnulib is meant as an embedded code copy IIRC,
another alternative would be to add the requisite files as a second
tarball containing the desired parts of gnulib, with component gnulib:
foo_1.2.3.orig-gnulib.tar.gz.

>   2b) Cross-compilation and dependency cycles.

The build profiles mechanism was invented to solve dependency cycles.
Unfortunately the Debian package build/storage infrastructure doesn't
yet support building non-default build profiles, so you have to
bootstrap manually on your own systems and or the porterboxen and then
upload the resulting binaries. We would need a way for maintainers to
specify the desired build profiles, support for storing non-default
build profiles in a separate archive (aka we need bikesheds) in dak
and support in the build infrastructure for using the desired build
profile and sending the results to the right bikeshed.

https://wiki.debian.org/BuildProfileSpec

Cross-builds mostly use the same packages as normal builds, except for
the cross-compiler, so these should be fine. I hear
gcc-for-host/gcc-for-build packages will improve the cross-compiling
situation, but IIRC this needs someone to work on it or review the
existing work.

http://crossqa.debian.net/
https://wiki.debian.org/CrossCompiling

> 3) Bootstrappable builds.

As I understand it from idling on their IRC channel, the
Bootstrappable Builds folks aim to not rely on all the non-source
files and other cruft in tarballs, so bootstrapping from VCS seems
like it should work just as well. I think it would be great if Debian
could become bootstrappable, probably starting with the higher levels
of the build stack (things like java) rather than the lower levels
from bare-metal to Linux/GCC, which are still in progress by the
Bootstrappable Builds folks.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian 11 Bullseye Setup Problems Error Report

[Paul Wise]

On Wed, Aug 18, 2021 at 9:12 AM admin4 wrote:

> cat feed.xml |nano # wohooo it works
>
> Too many errors from stdin

You need to tell nano to load stdin:

cat feed.xml | nano -

> here we go admin4 into the spam database... for trying to report a problem 
> and improve a GNU Linux distribution.

Please note that debian-devel is a public mailing list too, so your
email is already public.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian 11 Bullseye Setup Problems Error Report

[Paul Wise]

On Wed, Aug 18, 2021 at 10:42 AM admin4  wrote:

> is there a Debian "testing" team?

That is composed of everyone who uses Debian and especially those who
decide to report an issue they found.

> 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)),

The Debian CD team do installation testing of each new Debian release
and each new Debian point release. They don't do things like download
RSS feeds or try to use less/vi in the installer though, they just
follow the installer prompts.

https://wiki.debian.org/Teams/DebianCD/ReleaseTesting

> 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 )

I don't think that Debian has enough people to monitor these, we have
enough bug reports and mailing list/forum posts to keep up with as it
is.

> 2) scan the hardware specs of the system

There is a shared cross-distro hardware database:

https://wiki.debian.org/Hardware/Database
https://linux-hardware.org/
https://bsd-hardware.org/

Unfortunately the script used to upload to the database, called
hw-probe, isn't yet integrated into the Debian installer nor the
Debian live installer (calamares).

https://bugs.debian.org/964853
https://github.com/calamares/calamares/issues/1454

> anonymized! without any serials and mac addresses or ip addresses or screen 
> resolutions!, before uploading it to debian.org/hardware-compatibility-list

The above hardware database uses truncated salted hashes of some
hardware identifiers, in order to aggregate repeat uploads of hardware
probes of the same computer.

https://wiki.debian.org/PrivacyIssues#Data_sharing
https://github.com/linuxhw/hw-probe#privacy

> 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)

There isn't any way to automatically check if hardware works, you
would need the user to check each item of hardware, make sure they did
the check correctly and only then report it working correctly. We
could create a Debian Live distro for hardware
testing/compatibility/reporting/certification, but no-one has done
that yet, although there was an idea and discussion at DebConf to do
something similar some years ago.

http://wiki.debian.org/Hardware/Certification

There is a corner of our wiki where Debian users can report their
experience with installing Debian, as well as the option to file
installation reports, which feed back to the installer team.

https://wiki.debian.org/InstallingDebianOn

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Use files created during CI to seed trust and attract new users?

[Paul Wise]

On Wed, Aug 18, 2021 at 10:36 AM Steffen Möller wrote:

> When CI fails, I get an email and can chase things up with a look at the
> output files. This is something I like a lot. As a user, though,
> especially for scientific packages I would want to see the files that
> have been created.

These are already available in the form of the artifacts tarball, for eg:

https://ci.debian.net/data/autopkgtest/testing/amd64/2/2ping/14680325/artifacts.tar.gz

It is possible you are talking about Salsa CI rather than Debian CI though?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

[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).

On systems with ursmerge, things should still work, thanks to the
compatibility symlink, but this will cause packages with unit files
built since debhelper 1.13.4 was released to unstable, or uploaded as
source builds, to be incorrect, triggering a Lintian error and
breaking on systems that don't have usrmerge installed.

For more details and analysis, please see:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992469

I just wanted to post a warning that if you were planning on building
or uploading new source-only uploads to unstable now that Bullseye has
been released, and your package contains systemd unit files, you may
want to hold off until this bug gets fixed...

- Ted

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

[Peter Pentchev]

On Thu, Aug 19, 2021 at 12:18:51AM -0400, Theodore Ts'o wrote:
> 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).
> 
> On systems with ursmerge, things should still work, thanks to the
> compatibility symlink, but this will cause packages with unit files
> built since debhelper 1.13.4 was released to unstable, or uploaded as
> source builds, to be incorrect, triggering a Lintian error and
> breaking on systems that don't have usrmerge installed.
> 
> For more details and analysis, please see:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992469
> 
> I just wanted to post a warning that if you were planning on building
> or uploading new source-only uploads to unstable now that Bullseye has
> been released, and your package contains systemd unit files, you may
> want to hold off until this bug gets fixed...

Actually, I just reported #992465 against Lintian last night:
the Lintian error is outdated. See the original message in #987989 that
prompted the debhelper change:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987989#5

I got a scare yesterday, too, when I noticed a local rebuild moved
a unit file to /usr/lib/systemd/system/, but then I read #987989 and
then I actually tried it - and systemd happily found my service and
started it.

So, it's not as bad as it looks at first :)

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: WARNING: dh_installsystemd is moving unit files to /usr/lib/systemd/system

[Michael Biebl]

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