Re: Debian 11

[Pierre-Elliott Bécue]

Hi Paul,

Paul Sutton  writes:

> Hi
>
> I installed Debian 11 on my new hard disk yesterday in preparation for
> the release,  everything went very smoothly, I did manage to skip 
> selecting a mirror (error on my part) but adding that manually worked
> fine after asking for help on IRC. Also good learning point on adding 
> items manually, so not a bad thing.
>
> Looks really nice, so really well done to the developer and other
> teams on the upcoming release.
>
> I have now set up a separate home partition too
>
> Keep up the good work

Thanks for your feedback, it's greatly appreciated!

Enjoy Debian 11!

Cheers,
--
PEB


signature.asc
Description: PGP signature

Re: Need help with Multi-Arch in systemd

[Simon McVittie]

On Thu, 08 Jul 2021 at 23:03:48 +0200, Michael Biebl wrote:
> [a separate libsystemd-shared-249 .deb] would also mean, that on every
> new upstream release, systemd would have to go through NEW

It seems like we're rejecting a good technical solution because
social/organisational factors block it (namely, new binary packages
triggering manual review from the ftp team even if there has not been
any significant change in how the package is organised, resulting in
manual review being artificially frequent for libraries that happen to
break ABI a lot, but infrequent for packages that aren't libraries or
don't break ABI).

This seems like a side-effect of the ftp team's two gatekeeping roles
(legal review and managing the namespaces of source and binary package
names) both having the dak override file as their implementation, rather
than necessarily anything that was designed or intended.

Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and auto-accept
packages from the given source package that match the regex, assigning
the given section/priority, without manual action? That would let the
ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/
in libs/optional, for example.

It seems like this would also be good for src:linux, where ABI breaks
are often tied to security fixes that should enter the archive ASAP.

smcv

automatic NEW processing [was Re: Need help with Multi-Arch in systemd]

[Michael Biebl]

Am 14.07.21 um 12:59 schrieb Simon McVittie:

Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and auto-accept
packages from the given source package that match the regex, assigning
the given section/priority, without manual action? That would let the
ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/
in libs/optional, for example.

It seems like this would also be good for src:linux, where ABI breaks
are often tied to security fixes that should enter the archive ASAP.


If something fully automated like this would be implemented, I would 
have much less concerns with this option.


As it stands today, NEW processing is simply to unpredictable. It can 
range from taking a a few hours/days to several months.


Regards,
Michael









OpenPGP_signature
Description: OpenPGP digital signature

Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]

[Michael Biebl]

Am 14.07.21 um 13:47 schrieb Michael Biebl:

Am 14.07.21 um 12:59 schrieb Simon McVittie:

Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and 
auto-accept

packages from the given source package that match the regex, assigning
the given section/priority, without manual action? That would let the
ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/
in libs/optional, for example.

It seems like this would also be good for src:linux, where ABI breaks
are often tied to security fixes that should enter the archive ASAP.


If something fully automated like this would be implemented, I would 
have much less concerns with this option.



Fwiw, I like your proposal and would like to see it implemented 
regardless of the issue at hand as I think it could be generally useful.


Thanks, Simon!




OpenPGP_signature
Description: OpenPGP digital signature

Re: Need help with Multi-Arch in systemd

[Timo Röhling]

* Simon McVittie  [2021-07-14 11:59]:

Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and auto-accept
packages from the given source package that match the regex, assigning
the given section/priority, without manual action? That would let the
ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/
in libs/optional, for example.

+1

Especially considering that library packages are subject to transitions
anyway, so they already receive much more scrutiny than, say, an
updated Python module.

Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Need help with Multi-Arch in systemd

[Bastian Blank]

On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote:
> Asking on #debian-systemd, Marco d'Itri suggested, that we move
> libsystemd-shared into a separate binary package. This would only help, if
> we moved libsystemd-shared into a Multi-Arch location (which means, we'd
> have to carry a patch against upstream). It would also mean, that on every
> new upstream release, systemd would have to go through NEW.
> So I'm not very keen on doing that.

Why do you think?  libsystemd-shared is a perfectly valid package name
and it does not change.

However, if you call it libsystemd-shared-249, it is supposed to be
stable.

Bastian

-- 
Is truth not truth for all?
-- Natira, "For the World is Hollow and I have Touched
   the Sky", stardate 5476.4.

Re: Need help with Multi-Arch in systemd

[Bastian Blank]

On Wed, Jul 14, 2021 at 11:59:11AM +0100, Simon McVittie wrote:
> It seems like this would also be good for src:linux, where ABI breaks
> are often tied to security fixes that should enter the archive ASAP.

As security updates are hand approved, accepting by NEW does not help
that much.

Bastian

-- 
Peace was the way.
-- Kirk, "The City on the Edge of Forever", stardate unknown

Bug#991109: ITP: golang-github-newrelic-go-agent -- library for monitoring go applications

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-newrelic-go-agent
  Version : 3.13.0-1
  Upstream Author : New Relic
* URL : https://github.com/newrelic/go-agent
* License : Apache-2.0
  Programming Lang: Go
  Description : library for monitoring go applications

This package is a dependency of step-ca (#990946)

Bug#991112: ITP: golang-github-stoewer-go-strcase -- go library for converting between naming formats

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-stoewer-go-strcase
  Version : 1.2.0-1
  Upstream Author : A. Stoewer
* URL : https://github.com/stoewer/go-strcase
* License : Expat
  Programming Lang: Go
  Description : go library for converting between naming formats
 This library converts between different kinds of naming formats such as camel
 case (CamelCase), snake case (snake_case) or kebab-case (kebab-case).

This package is an indirect dependency of caddy (#810890)

Re: automatic NEW processing [was Re: Need help with Multi-Arch in systemd]

[Philipp Kern]

On 14.07.21 13:47, Michael Biebl wrote:

Am 14.07.21 um 12:59 schrieb Simon McVittie:

Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and 
auto-accept

packages from the given source package that match the regex, assigning
the given section/priority, without manual action? That would let the
ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/
in libs/optional, for example.

It seems like this would also be good for src:linux, where ABI breaks
are often tied to security fixes that should enter the archive ASAP.


If something fully automated like this would be implemented, I would 
have much less concerns with this option.


As it stands today, NEW processing is simply to unpredictable. It can 
range from taking a a few hours/days to several months.


And yet it should not dictate technical solutions. We basically see the 
same thing with nvidia-graphics-drivers that break your running 
applications when the libraries are upgraded and you don't reboot. 
Arguably the proper solution is to version them with the full 
major/minor version. But I can see how that's a total hassle with NEW 
processing for both for the maintainer and to the FTP team.


I do recall that the FTP masters would've been generally open to have 
such an auto-approver (but maybe I'm wrong), but that no-one stepped up 
yet to code it up?


Kind regards
Philipp Kern

Re: Debian 11

[Paul Sutton]

On 14/07/2021 11:25, Pierre-Elliott Bécue wrote:

Hi Paul,

Paul Sutton  writes:


Hi

I installed Debian 11 on my new hard disk yesterday in preparation for
the release,  everything went very smoothly, I did manage to skip
selecting a mirror (error on my part) but adding that manually worked
fine after asking for help on IRC. Also good learning point on adding
items manually, so not a bad thing.

Looks really nice, so really well done to the developer and other
teams on the upcoming release.

I have now set up a separate home partition too

Keep up the good work


Thanks for your feedback, it's greatly appreciated!

Enjoy Debian 11!

Cheers,
--
PEB



No problem you're welcome.

One comment, not sure if this will help people, running xfce4,  seemed 
rather slow on my system. I used Window Manager tweaks to turn off the 
compositor and it is much faster and more responsive.


I will see what is loaded at start up to see if there is anything I can 
remove that is not needed.


Regards

Paul

--
Paul Sutton, Cert Cont Sci (Open)
https://personaljournal.ca/paulsutton/
OpenPGP : 4350 91C4 C8FB 681B 23A6 7944 8EA9 1B51 E27E 3D99

Pronoun : him/his/he

21st Debian Conference August 22 to August 29, 2021.
DebCamp from August 15 to August 21, 2021

https://debconf21.debconf.org/


OpenPGP_0x8EA91B51E27E3D99.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

XFCE4 notes

[Paul Sutton]

Hi All

Am I right in thinking that xfce4-notes has been removed?  I have 
installed xfce4-goodies and it isn't installed.


apt search xfce4-notes
Sorting... Done
Full Text Search... Done
xfce4-goodies/testing,now 4.14.0 amd64 [installed]
  enhancements for the Xfce4 Desktop Environment

Appears to suggest that installing xfce4-goodies will install 
xfce4-notes. Unless I am interpreting that incorrectly.


Thankfully, it used good old plain text, so all my notes are still 
readable.


Thanks

Paul
--
Paul Sutton, Cert Cont Sci (Open)
https://personaljournal.ca/paulsutton/
OpenPGP : 4350 91C4 C8FB 681B 23A6 7944 8EA9 1B51 E27E 3D99

Pronoun : him/his/he

21st Debian Conference August 22 to August 29, 2021.
DebCamp from August 15 to August 21, 2021

https://debconf21.debconf.org/


OpenPGP_0x8EA91B51E27E3D99.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: XFCE4 notes

[Michael Biebl]

Am 14.07.21 um 19:54 schrieb Paul Sutton:

Hi All

Am I right in thinking that xfce4-notes has been removed?  I have 
installed xfce4-goodies and it isn't installed.


From unstable/testing that is correct.

See
https://tracker.debian.org/pkg/xfce4-notes-plugin
specifically
https://tracker.debian.org/news/1114283/removed-181-3-from-unstable/




OpenPGP_signature
Description: OpenPGP digital signature

merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Thorsten Glaser]

Sean Whitton dixit:

>* #978636 move to merged-usr-only?
>
>  We were asked to decide whether or not Debian 'bookworm' should
>  continue to support systems which are not using the merged-usr
>  filesystem layout.  We decided that support should not continue beyond
>  Debian 'bullseye'.

What? WHAT? ＷＨＡＴ？

>  The decision is captured here:
>  

No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
Debian is becoming untenable. Years ago, I had hoped it won’t.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Bug#991121: ITP: golang-github-google-cel-spec -- go library implementing Common Expression Language

[Peymaneh Nejad]

Package: wnpp
Severity: wishlist
Owner: Peymaneh Nejad 

* Package name: golang-github-google-cel-spec
  Version : 0.5.1-1
  Upstream Author : Google
* URL : https://github.com/google/cel-spec
* License : Apache-2.0
  Programming Lang: Go
  Description : go library implementing Common Expression Language
 The Common Expression Language (CEL) is a simple expression language built on
 top of protocol buffer types. It implements common semantics for
 expression evaluation, enabling different applications to more easily
 interoperate.

This package is an indirect dependency of caddy (#810890)

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Guillem Jover]

On Wed, 2021-07-14 at 19:54:56 +, Thorsten Glaser wrote:
> Sean Whitton dixit:
> >* #978636 move to merged-usr-only?
> >
> >  We were asked to decide whether or not Debian 'bookworm' should
> >  continue to support systems which are not using the merged-usr
> >  filesystem layout.  We decided that support should not continue beyond
> >  Debian 'bullseye'.
> 
> What? WHAT? ＷＨＡＴ？
> 
> >  The decision is captured here:
> >  
> 
> No reason provided either. This stinks. I’m v̲e̲r̲y̲ disappointed.
> Debian is becoming untenable. Years ago, I had hoped it won’t.

I've been meaning to send a note about this for some time now, but
as I feel it keeps getting ignored, it always seems a bit pointless.

But in any case, given that merged-usr-via-aliased-dirs is not really
supported by dpkg anyway, it is broken by design [B], I have no
intention whatsoever to break any of my systems with such layout going
forward, I'm thus planning to spend any necessary volunteer time
implementing any fix, workaround or solution required to avoid having
to use it, in detriment of other Debian volunteer time. I already
started some time ago with dpkg-fsys-usrunmess(8), present already in
the upcoming bullseye release.

[B] 


Thanks,
Guillem

Re: What are desired semantics for /etc/shells?

[Guillem Jover]

Hi!

On Tue, 2021-06-15 at 13:31:15 +0200, Felix C. Stegerman wrote:
> FYI I just noticed another inconsistency: on my merged /usr systems
> (installed as such, not converted later w/ usrmerge), /etc/shells
> contains both /bin/ and /usr/bin/ paths for some shells, but not all
> (e.g. no /usr/bin/sh, no /bin/screen).
> 
>   $ sort /etc/shells
>   # /etc/shells: valid login shells
>   /bin/bash
>   /bin/dash
>   /bin/rbash
>   /bin/sh
>   /usr/bin/bash
>   /usr/bin/dash
>   /usr/bin/rbash
>   /usr/bin/screen
>   /usr/bin/tmux

Yeah, welcome to the wondrous world of merged-/usr-via-aliased-dirs,
where these paths are aliased, and can be used in places that will
end trying to match against literal entries in /etc/shells, and fail.

While I think I might have been aware of this issue, I never explicitly
tracked it in , added now,
thanks!

Regards,
Guillem

Re: Need help with Multi-Arch in systemd

[Guillem Jover]

On Wed, 2021-07-14 at 11:59:11 +0100, Simon McVittie wrote:
> On Thu, 08 Jul 2021 at 23:03:48 +0200, Michael Biebl wrote:
> > [a separate libsystemd-shared-249 .deb] would also mean, that on every
> > new upstream release, systemd would have to go through NEW
> 
> It seems like we're rejecting a good technical solution because
> social/organisational factors block it (namely, new binary packages
> triggering manual review from the ftp team even if there has not been
> any significant change in how the package is organised, resulting in
> manual review being artificially frequent for libraries that happen to
> break ABI a lot, but infrequent for packages that aren't libraries or
> don't break ABI).

Yes. I was mentioning exactly this the other day on the
#debian-bootstrap IRC channel.

In addition having this automatic support could make life easier for
many other potential packages.

> This seems like a side-effect of the ftp team's two gatekeeping roles
> (legal review and managing the namespaces of source and binary package
> names) both having the dak override file as their implementation, rather
> than necessarily anything that was designed or intended.

Yes, plus section and priority-spaces. But then, I don't see why a binary
package rename should trigger a new legal audit.

> Would it be feasible for dak to have a list of binary package name
> regexes mapped to a source package and a section/priority, and auto-accept
> packages from the given source package that match the regex, assigning
> the given section/priority, without manual action? That would let the
> ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/
> in libs/optional, for example.

What I had in mind was that DAK would gain support for automatic
ACCEPT of binary package renames due to SONAME version bumps,
something like this:

  * If the new bin:lib:
- replaces an existing bin:lib from the same
  source, where  is lower than .
- contains a shared library mapping to that package name.
- is in section */libs or */oldlibs.
  * Then → auto-ACCEPT, pre-filling the new section/priority from the
old binary package.
  * Otherwise → NEW.

I guess it could potentially be further extended later on to cover
other safe non shared library cases.

But if that's too much to ask, either due to implementation or policy
concerns, I'd take an explicit allowlist letting specific cases
through, such as the systemd one, instead of having to settle for
either suboptimal or wrong solutions for the problem at hand, due
to the currently required workflow being too cumbersome.

Thanks,
Guillem

Re: Need help with Multi-Arch in systemd

[Michael Biebl]

Am 09.07.21 um 14:24 schrieb Helmut Grohne:

Now let's do something stupid. Rename systemd to systemd-core (taking
all files with it, please refrain from discussing the name unless you
seriously consider doing this). Mark it Multi-Arch: allowed. Add a new,
empty binary package systemd. It is Multi-Arch: foreign and depends on
systemd-core:any. This approach would technically satisfy all three
requirements, but it feels a little crazy to me.


[..]


And I fear we have another related issue that we swept under the carpet
thus far. man systemd.exec explains SystemCallArchitectures=native.



You are right. Thinking more about this, splitting out libsystemd-shared 
as a Multi-Arch: same library will not help with 
SystemCallArchitectures=native, which is used by the services in 
systemd-{container,journal-remote,...}.
So splitting out libsystemd-shared, while in theory a nice solution, is 
not the right one in this case. We really need to ensure that systemd 
and systemd-* are of of the same architecture.


I still think that my idea of having a ":arch" annotation as counterpart 
to ":any" would be the most elegant way to achieve this. But since this 
is only an idea and not implemented, it's not something I can make use 
of. Do you think there is a chance we could convince dpkg and apt 
maintainers to add support for that?



Alternatively, your idea of systemd-core/systemd got me thinking.
While I don't like the prospect of moving all (conf)files and state from 
one package to another, maybe we can turn this idea around.


We introduce an empty systemd-native package, which is 
Architecture:linux-any but *not* Multi-Arch: foreign/same/allowed.


systemd and all systemd-* packages would depend on systemd-native.
This would link the architecture of systemd and systemd-* together and 
ensure they are the same.

Would this work for your cross-compile use-case?

Michael



OpenPGP_signature
Description: OpenPGP digital signature

Re: merged /usr considered harmful

[Thorsten Glaser]

Guillem Jover dixit:

>I've been meaning to send a note about this for some time now, but
>as I feel it keeps getting ignored, it always seems a bit pointless.

Yeah, I saw this popping up multiple times in that bugreport ☹

>But in any case, given that merged-usr-via-aliased-dirs is not really
>supported by dpkg anyway, it is broken by design [B], I have no

Time for another GR? Leaving Debian behind?

>intention whatsoever to break any of my systems with such layout going

Yeah, this totally caught me by surprise. I guess I’ll have to
figure out how to switch *all* my systems from sid to bullseye
*fast*, now. This also effectively ends debian-ports work for me…

Not amused,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Re: Need help with Multi-Arch in systemd

[Helmut Grohne]

Hi Michael,

On Thu, Jul 15, 2021 at 12:22:59AM +0200, Michael Biebl wrote:
> You are right. Thinking more about this, splitting out libsystemd-shared as
> a Multi-Arch: same library will not help with
> SystemCallArchitectures=native, which is used by the services in
> systemd-{container,journal-remote,...}.

That is correct, but it actually goes beyond systemd-* using systemd.
Any other service can face the very same problem.

> So splitting out libsystemd-shared, while in theory a nice solution, is not
> the right one in this case. We really need to ensure that systemd and
> systemd-* are of of the same architecture.

We have two related issues at hand. One is the libsystemd-shared
architecture matching and the other is the SystemCallArchitectures
matching. You appear to imply that both issues need to be addressed by
one common solution. Sure that would be nice, but is it required? Maybe
these issues are not that related after all.

Let us for a moment assume that we could magically make
SystemCallArchitectures work by locking users to the same architecture
as systemd. That would be bad in terms for mixed multiarch systems and
cross grading, because you essentially lock all daemons to the same
architecture as systemd. You fix the problem, by removing flexibility.

I also proposed a solution here, which is avoiding
SystemCallArchitectures=native. Initially, that sounds like a
maintenance nightmare until you notice that it can be solved on a
technical level. We already have dh_installsystemd. How bad would it be
to have dh_installsystemd change .service files and automatically
replace =native with a concrete architecture (in arch:any packages
only)? systemd would no longer detect the architecture of services from
its own one but rather use the one documented by the package. The mixing
of architectures that our earlier solution broke would now partially
work. We'd fix one package and binNMU the pile.

So while these problems are related, I think that forcing the
architectures to equal is a suboptimal solution for
SystemCallArchitectures.

> I still think that my idea of having a ":arch" annotation as counterpart to
> ":any" would be the most elegant way to achieve this. But since this is only
> an idea and not implemented, it's not something I can make use of. Do you
> think there is a chance we could convince dpkg and apt maintainers to add
> support for that?

If you replace :arch with :$DEB_HOST_ARCH, it already works today with
apt and dpkg, but not dose. The question is not whether we can implement
that (it already is), but whether we want to endorse these semantics or
not.

> Alternatively, your idea of systemd-core/systemd got me thinking.
> While I don't like the prospect of moving all (conf)files and state from one
> package to another, maybe we can turn this idea around.
> 
> We introduce an empty systemd-native package, which is
> Architecture:linux-any but *not* Multi-Arch: foreign/same/allowed.
> 
> systemd and all systemd-* packages would depend on systemd-native.
> This would link the architecture of systemd and systemd-* together and
> ensure they are the same.

I think this technically works. We also have prior art for this. blas
temporarily added such a package as a measure to fix #760936.

> Would this work for your cross-compile use-case?

I don't think this would negatively affect cross compiling. It could
affect people who try to run mixed-architecture systems though.

Given Simon's and Guillem's replies, I presently favour fixing the NEW
processing to package the library separately and fix
SystemCallArchitectures using dh_installsystemd, because it is
technically sound and does not negatively impact multiarch use cases.

Should I file a bug about SystemCallArchitectures such that we can track
it somewhere?

Helmut