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

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 cou

Re: Debian choice of upstream tarballs for packaging

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 signif

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

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

Re: Debian choice of upstream tarballs for packaging

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

Re: Debian 11 Bullseye Setup Problems Error Report

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 no

Re: merged /usr

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

Re: Debian 11 Bullseye Setup Problems Error Report

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

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

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 h

Re: Debian Policy 4.6.0.0 released

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

Re: Debian 11 Bullseye Setup Problems Error Report

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 com

Re: Debian 11 Bullseye Setup Problems Error Report

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

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

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 us

Re: Debian 11 Bullseye Setup Problems Error Report

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

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

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 a

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

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 : Arti

Re: Debian Policy 4.6.0.0 released

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 sho

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

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

Re: merged /usr

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 t

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

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

src:developers-reference - pt_BR translation initiative

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]

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

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 us

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

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

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

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 man

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

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

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

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

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

> 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

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

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

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#ver

Re: Debian Policy 4.6.0.0 released

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

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

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 experimenta

Re: Debian Policy 4.6.0.0 released

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

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

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

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

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

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

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 inadve

Re: Debian Policy 4.6.0.0 released

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 i

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

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

* 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 toolch

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

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

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

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

Re: Debian choice of upstream tarballs for packaging

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 usu

Re: Debian 11 Bullseye Setup Problems Error Report

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

Re: Debian 11 Bullseye Setup Problems Error Report

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 use

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

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 a

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

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 comp

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

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

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

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 fil