Bug#934219: ITP: dmrconfig -- configuration utility for DMR radios

[Iain R. Learmonth]

Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth" 

* Package name: dmrconfig
  Version : 1.1
  Upstream Author : Serge Vakulenko
* URL : https://github.com/sergev/dmrconfig
* License : Apache
  Programming Lang: C
  Description : configuration utility for DMR radios

DMRconfig is a utility for programming digital radios via USB
programming cable. Supported radios:

 * TYT MD-380, Retevis RT3, RT8
 * TYT MD-390
 * TYT MD-2017, Retevis RT82
 * TYT MD-UV380
 * TYT MD-UV390, Retevis RT3S
 * TYT MD-9600
 * Baofeng DM-1701, Retevis RT84
 * Baofeng RD-5R, TD-5R
 * Baofeng DM-1801
 * Radioddity GD-77
 * Anytone AT-D868UV
 * Anytone AT-D878UV
 * BTECH DMR-6x2
 * Zastone D900
 * Zastone DP880
 * Radtel RT-27D

This will be maintained within the Debian Hamradio Packaging Team.

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

[Marc Haber]

On Wed, 07 Aug 2019 09:28:12 -0400, The Wanderer
 wrote:
>On 2019-08-07 at 04:26, Russell Stuart wrote:
>
>> On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote:
>> 
>>> I am using Debian for two decades now, and I realized that
>>> necessity two days ago.
>> 
>> Ditto - except for me it was a few seconds ago.
>
>In my case, it was when I read this thread last night. (After more like
>~1.5 decades of Debian, for what that's worth.)

Generating a new machine-id doesn't seem as easy as generating a new
ssh key: Removing /etc/machine-id doesn't do it as
systemd-machine-id-setup seems to pull the machine-id from dbus.

I have four Banana Pis with identical machine IDs because they were
cloned from a common image. Since that one originates from a Debian
Wiki Page about the Banana Pi I guess that the vast majority of Banana
Pis running Debian has this machine id.

How do I generate a new one?

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

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Ondřej Surý]

> Please stop hating on sysvinit

So, just to clarify…  so, it’s ok to hate systemd, but it’s not ok to hate 
sysvinit (spaghetti of shell scripts)?

O.
--
Ondřej Surý
ond...@sury.org



> On 7 Aug 2019, at 15:44, Ian Jackson  wrote:
> 
> Marc Haber writes ("Re: do packages depend on lexical order or 
> {daily,weekly,monthly} cron jobs?"):
>> We have already thrown sysvinit away.
> 
> No, we have not.
> 
> https://tracker.debian.org/pkg/sysvinit
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=sysvinit#_2_4_5
> https://tracker.debian.org/pkg/insserv
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=insserv#_4_3_5
> https://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2019-July/date.html
> 
> Ian.
> 

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

[Bernhard Schmidt]

Am 08.08.19 um 13:39 schrieb Marc Haber:
> On Wed, 07 Aug 2019 09:28:12 -0400, The Wanderer
>  wrote:
>> On 2019-08-07 at 04:26, Russell Stuart wrote:
>>
>>> On Wed, 2019-08-07 at 09:34 +0200, Marc Haber wrote:
>>>
 I am using Debian for two decades now, and I realized that
 necessity two days ago.
>>>
>>> Ditto - except for me it was a few seconds ago.
>>
>> In my case, it was when I read this thread last night. (After more like
>> ~1.5 decades of Debian, for what that's worth.)
> 
> Generating a new machine-id doesn't seem as easy as generating a new
> ssh key: Removing /etc/machine-id doesn't do it as
> systemd-machine-id-setup seems to pull the machine-id from dbus.
> 
> I have four Banana Pis with identical machine IDs because they were
> cloned from a common image. Since that one originates from a Debian
> Wiki Page about the Banana Pi I guess that the vast majority of Banana
> Pis running Debian has this machine id.
> 
> How do I generate a new one?

I followed
https://unix.stackexchange.com/questions/402999/it-is-ok-to-change-etc-machine-id
last time which means

rm -f /etc/machine-id
dbus-uuidgen --ensure=/etc/machine-id
rm /var/lib/dbus/machine-id
dbus-uuidgen --ensure

Last time I only removed /etc/machine-id (hoping it would be regenerated
on Reboot) rendered the machine unbootable.

FTR, I have also only recently learned about this. Duplicate machine-ids
can have very nasty consequences. We recently had a weird networking
issue at one department where clients got assigned the same address from
the dynamic DHCP pool and kicked each other out of the network.

It took us a while to figure out the admin had cloned Kubuntu 18.04
workstations that use systemd-networkd for network configuration.
systemd-networkd DHCP by default sends the machine-id as
client-identifier, and isc-dhcp by default uses the client-identifier
(if present) instead of the MAC address to track leases.

Bernhard

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Jim Popovitch]

On Thu, 2019-08-08 at 13:47 +0200, Ondřej Surý wrote:
> So, just to clarify…  so, it’s ok to hate systemd, but it’s
> not ok to hate sysvinit (spaghetti of shell scripts)?
> 

One has a spaghetti of shell scripts, the other has a kimchi of log
commands and hidden config files.

I think "out of sight, out of mind" comes into play here.

-Jim P.

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Philipp Kern]

On 2019-08-08 13:47, Ondřej Surý wrote:

Please stop hating on sysvinit


So, just to clarify…  so, it’s ok to hate systemd, but it’s not ok to
hate sysvinit (spaghetti of shell scripts)?


I don't think that's a constructive line of argument. At the same time 
it's not a race to the bottom in terms of features. I think our baseline 
should be thinking in terms of the features of the default we have.


I don't have a great answer about the added maintenance cost that 
sysvinit support puts on maintainers and thus they are rejecting certain 
changes. I would like to say that I appreciate the work but personally 
not care, but I have learned the hard way that just keeping things 
working is a ton of work. And if you don't pay that cost stuff keeps 
rotting. Some of that could be addressed with better integration 
testing. But at the same time it does not answer the question on who 
pays the cost of rebasing changes, especially with more upstream 
packages providing base services building more around reliable systemd 
services. I feel like the answer is temporarily throwing out those parts 
if needed or accept that they are broken until they get fixed, but that 
might not be universally accepted, I guess.


Kind regards
Philipp Kern

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Ondřej Surý]

> On 8 Aug 2019, at 14:08, Philipp Kern  wrote:
> 
> On 2019-08-08 13:47, Ondřej Surý wrote:
>>> Please stop hating on sysvinit
>> So, just to clarify…  so, it’s ok to hate systemd, but it’s not ok to
>> hate sysvinit (spaghetti of shell scripts)?
> 
> I don't think that's a constructive line of argument.

Maybe, but the email subject seemed too ironic to just let it be.

> At the same time it's not a race to the bottom in terms of features. I think 
> our baseline should be thinking in terms of the features of the default we 
> have.

And there’s the problem.  If we keep with sysvinit as a baseline of features 
provided by the init, we end up with just every init script having something 
like this:

do_tmpfiles() {
local type path mode user group age argument
if [ -r "$1" ]; then
if [ -x /bin/systemd-tmpfiles ]; then
/bin/systemd-tmpfiles --create "$1"
else
while read type path mode user group age argument; do
case "$type" in
d)
mkdir -p "$path";
chmod "$mode" "$path";
chown "$user:$group" "$path";
;;
\#*)
;;
*)
log_warning_msg "tmpfile.d type '$type' is not 
supported yet"
;;
esac
done < "$1"
fi
else
log_warning_msg "tmpfiles.d file '$1' doesn't exist or is not readable"
fi
}

> I don't have a great answer about the added maintenance cost that sysvinit 
> support puts on maintainers and thus they are rejecting certain changes. I 
> would like to say that I appreciate the work but personally not care, but I 
> have learned the hard way that just keeping things working is a ton of work. 
> And if you don't pay that cost stuff keeps rotting. Some of that could be 
> addressed with better integration testing. But at the same time it does not 
> answer the question on who pays the cost of rebasing changes, especially with 
> more upstream packages providing base services building more around reliable 
> systemd services. I feel like the answer is temporarily throwing out those 
> parts if needed or accept that they are broken until they get fixed, but that 
> might not be universally accepted, I guess.

The problem here that “sysvinit” or “systemd” are vague terms.  For some 
packages, sysvinit really means sysvrc, for other packages systemd means much 
more than just the service script (service activation, isolation, etc…) which 
is hard to mimick without systemd and friends.  For yet another group of 
packages (postfix, cyrus-imapd), it could have meant not having to develop own 
supervisor and just plug it into systemd.

All my packages still have sysvrc scripts, but it’s easy to dislike maintaining 
sysvinit script when you look at the difference:

   6 pkg-dns/bind9-9.14/debian/bind9.named.default
 145 pkg-dns/bind9-9.14/debian/bind9.named.init

vs

   6 pkg-dns/bind9-9.14/debian/bind9.named.default
  16 pkg-dns/bind9-9.14/debian/bind9.named.service
   1 pkg-dns/bind9-9.14/debian/bind9.named.tmpfile

And I can certainly understand why the maintainers would reject big patchset 
for policykit - the maintenance burden is not “hey, accept this patch”, but 
they would have to take care of the patchset every time something breaks, or 
there’s security issue.  Diverting too much from the upstream has 
non-negligible risks.

Ondrej
--
Ondřej Surý
ond...@sury.org

Re: Generating new IDs for cloning

[Marvin Renich]

* Bernhard Schmidt  [190808 07:48]:
> Am 08.08.19 um 13:39 schrieb Marc Haber:
> > How do I generate a new one?
> 
> I followed
> https://unix.stackexchange.com/questions/402999/it-is-ok-to-change-etc-machine-id
> last time which means

Hmm.  The advice in that link doesn't match what man machine-id says,
which is to replace /etc/machine-id with an empty file rather than
remove it, and then reboot.

I have no idea which is the "correct" solution, but if the man page is
correct, that seems to be the simpler solution.

Does anyone know what applications use this file for what purpose?  Is
this a systemd-ism?

...Marvin

Re: Generating new IDs for cloning

[Michael Stone]

On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:

Does anyone know what applications use this file for what purpose?  Is
this a systemd-ism?


man machine-id

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Holger Levsen]

On Thu, Aug 08, 2019 at 02:35:13PM +0200, Ondřej Surý wrote:
> And there’s the problem.  If we keep with sysvinit as a baseline of 
> features provided by the init, we end up with just every init script
> having something like this: [...]

it seems several people in this thread have missed the fact, that
sysvinit in Debian is maintained well again, eg there have been 17
uploads of it so far in 2019, see
https://tracker.debian.org/pkg/sysvinit/news/

(so I think the above fixes could all be made in one central place.)


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Philipp Kern]

On 2019-08-08 14:43, Holger Levsen wrote:

On Thu, Aug 08, 2019 at 02:35:13PM +0200, Ondřej Surý wrote:

And there’s the problem.  If we keep with sysvinit as a baseline of
features provided by the init, we end up with just every init script
having something like this: [...]


it seems several people in this thread have missed the fact, that
sysvinit in Debian is maintained well again, eg there have been 17
uploads of it so far in 2019, see
https://tracker.debian.org/pkg/sysvinit/news/

(so I think the above fixes could all be made in one central place.)


As a lot of the conflict between sysvinit and systemd was about the 
philosophy. So then the question boils down to what kind of feature 
development sysvinit *in Debian* is willing to do to do that. If the 
answer is "we really want the shell scripts as they have been since the 
beginning of time - and that is the scope of sysvinit" (which would not 
be true either, I know), then we cannot have that discussion either.


That's also to some degree why I think a solution to this problem is for 
the init diversity folks to figure out and we should not block on that. 
And that seems fine given the scope they have set for themselves.


Kind regards
Philipp Kern

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Holger Levsen]

On Thu, Aug 08, 2019 at 02:48:48PM +0200, Philipp Kern wrote:
[...] 
> That's also to some degree why I think a solution to this problem is for the
> init diversity folks to figure out and we should not block on that. And that
> seems fine given the scope they have set for themselves.

I agree with this, also the unquoted part.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Martin Steigerwald]

Philipp Kern - 08.08.19, 14:48:48 CEST:
> On 2019-08-08 14:43, Holger Levsen wrote:
> > On Thu, Aug 08, 2019 at 02:35:13PM +0200, Ondřej Surý wrote:
> >> And there’s the problem.  If we keep with sysvinit as a baseline of
> >> features provided by the init, we end up with just every init
> >> script
> >> having something like this: [...]
> > 
> > it seems several people in this thread have missed the fact, that
> > sysvinit in Debian is maintained well again, eg there have been 17
> > uploads of it so far in 2019, see
> > https://tracker.debian.org/pkg/sysvinit/news/
> > 
> > (so I think the above fixes could all be made in one central place.)
> 
> As a lot of the conflict between sysvinit and systemd was about the
> philosophy. So then the question boils down to what kind of feature
> development sysvinit *in Debian* is willing to do to do that. If the
> answer is "we really want the shell scripts as they have been since
> the beginning of time - and that is the scope of sysvinit" (which
> would not be true either, I know), then we cannot have that
> discussion either.
> 
> That's also to some degree why I think a solution to this problem is
> for the init diversity folks to figure out and we should not block on
> that. And that seems fine given the scope they have set for
> themselves.

I'd like to mention that people in the debian init diversity group not 
only work on sysvinit, but also on runit, elogind for example.

I believe there is not need to resolve the difference in philosophy. I 
switched all my systems to sysvinit meanwhile. One is on OpenRC. And so 
far I do not miss any features and enjoy the predictability. Probably 
only restarting services on failure – runit / s6 provide that. thinkfan 
fails sometimes for example, but with Systemd I did not even notice it. 
I prefer when whatever manages services to be invisible and I prefer 
policy to be in code I can easily review as an admin of my system.

So for me: No new features is actually a good thing. Software 
development got faster and faster and faster… but did things really get 
better? They for sure got more complex and more difficult to understand.

I bet it again it depends on different view points. And so there is a 
benefit to just agree to disagree. Sysvinit does not need to become like 
Systemd or vice versa.

Of course I do not object careful development of a feature here and 
there… and I am considering to switch to an init system that can restart 
services for my main laptop as well. Maybe runit, maybe… let's see. It 
has no urgent priority tough.

Thanks,
-- 
Martin

Re: Generating new IDs for cloning

[Marvin Renich]

* Michael Stone  [190808 08:42]:
> On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
> > Does anyone know what applications use this file for what purpose?  Is
> > this a systemd-ism?
> 
> man machine-id

The man page says what it is (a unique, random ID for the machine) and
how to initialize it, but says nothing about why it exists.  What
applications expect it to be there?

...Marvin

Re: Generating new IDs for cloning

[Michael Stone]

On Thu, Aug 08, 2019 at 11:41:52AM -0400, Marvin Renich wrote:

* Michael Stone  [190808 08:42]:

On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
> Does anyone know what applications use this file for what purpose?  Is
> this a systemd-ism?

man machine-id


The man page says what it is (a unique, random ID for the machine) and
how to initialize it, but says nothing about why it exists. What
applications expect it to be there?



From the man page:


  The machine ID does not change based on local or network configuration
  or when hardware is replaced. Due to this and its greater length, it
  is a more useful replacement for the gethostid(3) call that POSIX
  specifies.
[...]
  When a machine is booted with systemd(1) the ID of the machine will be
  established. If systemd.machine_id= or --machine-id= options (see
  first section) are specified, this value will be used. Otherwise, the
  value in /etc/machine-id will be used. If this file is empty or
  missing, systemd will attempt to use the D-Bus machine ID from
  /var/lib/dbus/machine-id, the value of the kernel command line option
  container_uuid, the KVM DMI product_uuid (on KVM systems), and finally
  a randomly generated UUID.

Re: Generating new IDs for cloning

[Marc Haber]

On Thu, 8 Aug 2019 11:50:07 -0400, Michael Stone 
wrote:
>On Thu, Aug 08, 2019 at 11:41:52AM -0400, Marvin Renich wrote:
>>* Michael Stone  [190808 08:42]:
>>> On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
>>> > Does anyone know what applications use this file for what purpose?  Is
>>> > this a systemd-ism?
>>>
>>> man machine-id
>>
>>The man page says what it is (a unique, random ID for the machine) and
>>how to initialize it, but says nothing about why it exists. What
>>applications expect it to be there?
>
>>From the man page:
>
>   The machine ID does not change based on local or network configuration
>   or when hardware is replaced. Due to this and its greater length, it
>   is a more useful replacement for the gethostid(3) call that POSIX
>   specifies.
>[...]
>   When a machine is booted with systemd(1) the ID of the machine will be
>   established. If systemd.machine_id= or --machine-id= options (see
>   first section) are specified, this value will be used. Otherwise, the
>   value in /etc/machine-id will be used. If this file is empty or
>   missing, systemd will attempt to use the D-Bus machine ID from
>   /var/lib/dbus/machine-id, the value of the kernel command line option
>   container_uuid, the KVM DMI product_uuid (on KVM systems), and finally
>   a randomly generated UUID.

What Marvin says: That doesn't explain anything.

I have, btw, just learned that systemd-networkd won't even attempt to
bring up your network if /etc/machine-id doesn't exist. duh.

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

Re: Generating new IDs for cloning

[Michael Stone]

On Thu, Aug 08, 2019 at 06:16:31PM +0200, Marc Haber wrote:

On Thu, 8 Aug 2019 11:50:07 -0400, Michael Stone 
wrote:

On Thu, Aug 08, 2019 at 11:41:52AM -0400, Marvin Renich wrote:

* Michael Stone  [190808 08:42]:

On Thu, Aug 08, 2019 at 08:37:16AM -0400, Marvin Renich wrote:
> Does anyone know what applications use this file for what purpose?  Is
> this a systemd-ism?

man machine-id


The man page says what it is (a unique, random ID for the machine) and
how to initialize it, but says nothing about why it exists. What
applications expect it to be there?



From the man page:


  The machine ID does not change based on local or network configuration
  or when hardware is replaced. Due to this and its greater length, it
  is a more useful replacement for the gethostid(3) call that POSIX
  specifies.
[...]
  When a machine is booted with systemd(1) the ID of the machine will be
  established. If systemd.machine_id= or --machine-id= options (see
  first section) are specified, this value will be used. Otherwise, the
  value in /etc/machine-id will be used. If this file is empty or
  missing, systemd will attempt to use the D-Bus machine ID from
  /var/lib/dbus/machine-id, the value of the kernel command line option
  container_uuid, the KVM DMI product_uuid (on KVM systems), and finally
  a randomly generated UUID.


What Marvin says: That doesn't explain anything.


I guess I need you to say what's confusing. It's an ID that doesn't 
change. You can look up gethostid to get a little more background. If 
you need an ID for a host it's useful. If you don't need an ID for a 
host, then it's not so useful. Once upon a time (gethostid(3) alludes to 
this) it was thought that an IPv4 would be a good unique ID, but with 
the rise of NAT it quickly became useless and hence the search for an 
alternative. The second paragraph is pretty clear that machine-id is one 
of a number of possible seeds for systemd to set the machine's ID. The 
rest of the file talks about how applications can use an API to get a 
constant ID based on the machine ID and that applications should 
generally not use the contents of the machine-id file directly. So to 
find out what applications use the file you'd have to look for 
references to the various APIs (such as 
sd_id128_get_machine_app_specific or dbus-uuidgen) which themselves use 
/etc/machine-id

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Simon Richter]

Hi,

On Thu, Aug 08, 2019 at 02:48:48PM +0200, Philipp Kern wrote:

> As a lot of the conflict between sysvinit and systemd was about the
> philosophy.

I wouldn't say "philosophy". These are different technical designs, and
each design has certain capabilities and limitations. It is not possible to
build a design that has the strengths of both but none of the weaknesses,
because you'd have to solve the halting problem for that.

For a desktop environment it makes a lot of sense to have a microservice
architecture such as the one that systemd provides. Typical desktop use
cases are "connect these Bluetooth headphones" and "allow the user on the
local console to select an active network card and configure settings".

The network device configuration case is a simple policy decision. The
logged-in user is the owner of the system and also the only stakeholder, so
in this case it makes sense to provide an interface that allows a
non-privileged user to perform a privileged action, limited by the
expressiveness of the interface. The network configuration API does not
allow setting up a complex routing table with multiple weighted
alternatives, because that is not part of the use case, and that is fine.

The bluetooth headset use case goes a bit beyond policy. There is still a
system-wide element (hardware access only for the local user), but most of
the software stack involved lives in userspace now and is orchestrated as
microservices, including a mechanism to topple the entire stack on error.
That is a sensible design choice -- if the user walks out of range with
their headset, there is no sensible way to provide audio service, and the
existing kernel audio APIs do not have an appropriate signaling mechanism.

For servers, the benefit is rather limited. There is no local user who
makes system-wide policy decisions, and hardware is not changing
dynamically either. The actual services provided are either implemented as
daemons (i.e. not microservices), or proper microservices run inside a
site-wide microservice framework such as Docker+Kubernetes, because a
system-local framework such as systemd is too limited to express the
dependencies. System boot time is significantly less important than service
response time, so "socket activation" for daemons is not useful in this
context either. We have had this for -literally- decades in the form of
inetd, and it has not been widely used, precisely for that reason.

The "desktop" and "server" use cases are so vastly different that it
doesn't make sense to try to squeeze both into a single design, because it
will not be good at either. There are other use cases that have
requirements that are not adequately serviced by either, for example
embedded systems or containers.

It is way more useful to have multiple alternatives that fit their
respective use cases well than one thing that attempts to do everything.

> So then the question boils down to what kind of feature
> development sysvinit *in Debian* is willing to do to do that. If the
> answer is "we really want the shell scripts as they have been since
> the beginning of time - and that is the scope of sysvinit" (which
> would not be true either, I know), then we cannot have that
> discussion either.

It is pretty close to the truth. The SystemV init design boils down to

 - there are two phases of system boot: kernel services (rcS.d) and user
   services (rc[1-5].d). User services can depend on kernel services.
 - configuration files are in an imperative language

The systemd design on the other hand:

 - there is a dependency tree of services that may depend on each other
 - configuration files are descriptive, with an exception for generators,
   which are imperative, but generate descriptive configuration fragments

The scope of sysvinit is to provide a minimal framework and then get out of
the way. Daemons can expect a working file system and to be able to create
listener sockets on INADDR_ANY or IN6ADDR_ANY. Anything beyond that is the
responsibility of the daemon.

The NTP daemon for some reason binds one socket per configured IP address,
so it needs to watch for network configuration events. Offloading that
responsibility into a common component would probably be possible, but
would not save any complexity because the main task of coordinating these
changes with the efforts to adjust the system clock would still be there.
As a result, it doesn't make any sense to make ntpd dependent on systemd
for its socket handling, and the only thing systemd is useful for is the
same thing that sysvinit also does: start the daemon some time after early
boot is complete.

The sanest thing we could do in Debian is to teach start-stop-daemon to
parse systemd .service files and pull its command line arguments from
there, so we could use service definitions as init scripts with a #! line.

For that to happen, we'd have to define .service files as an API though,
which would feature-freeze them, and I'm not sure the systemd people w

Bug#934245: ITP: libnektar++ -- Nektar++ spectral/hp element framework - libraries

[Chris Cantwell]

Package: wnpp
Severity: wishlist
Owner: Chris Cantwell 

* Package name: libnektar++
  Version : 5.0.0
  Upstream Author : Chris Cantwell 
* URL : http://www.nektar.info/
* License : MIT
  Programming Lang: C++
  Description : Nektar++ spectral/hp element framework - libraries

 Nektar++ is a C++ framework for the development of computational solvers for
 partial differential equations based on the spectral/hp element method.
 .
 This package contains the libraries which implement the spectral/hp element
 discretisation and associated support classes. It provides a tensor-product
 based finite element implementation designed to seemlessly and efficiently
 construct both low-order h-type solvers, and high-order p-type solvers, for
 a wide range of partial differential equations.
 .
 It supports: the representation of one-, two- and three-dimensional fields as
 a collection of piecewise continuous or discontinuous polynomial domains;
 embedded domains; hybrid-shaped elements; hierarchical and nodal expansion
 bases; and continuous and discontinuous Galerkin operators.


I am one of the leaders of this project. We develop and use the software daily
and there is a growing world-wide user base in academia and industry. Unlike
other finite element packages, Nektar++ natively supports the use of high-order
finite element methods. Packaging will be maintained as part of the Nektar++
project.

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

[Marc Haber]

On Wed, 7 Aug 2019 11:15:22 -0400, Marvin Renich 
wrote:
>I think this is a good idea, but will require work and coordination to
>accomplish.  A wiki.debian.org page with your ideas and (perhaps on a
>separate page) a place to list things that need updating after the
>physical copying is complete would be wonderful, if you feel motivated
>to get it started.  :-)  Hostname, machine-id (new to me too!), and ssh
>host keys can start the list.

https://wiki.debian.org/MachineId

as a beginning.

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

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Alf Gaida]

On Thu, 8 Aug 2019 19:10:42 +0200
Simon Richter  wrote:
> For servers, the benefit is rather limited. There is no local user who
i don't agree - systemd just work™ in the most cases. Without changing
a bit.
> The "desktop" and "server" use cases are so vastly different that it
> doesn't make sense to try to squeeze both into a single design,
No. They aren't.
> It is way more useful to have multiple alternatives that fit their
> respective use cases well than one thing that attempts to do
> everything.
No.
> > So then the question boils down to what kind of feature
> > development sysvinit *in Debian* is willing to do to do that. If the
No, it don't. We need sysvinit for some non-linux things and some
enthusiasts that are not switched to devuan yet - it would be sane to
abandon sysvinit, kfreebsd and the hurd alltogether or split them out.
Only my point of view.
> The sanest thing we could do in Debian is to teach start-stop-daemon
> to parse systemd .service files and pull its command line arguments
No. The sanest thing would be to consider systemd as winning system and
improve it - and let sysv bitrot.

> For that to happen, we'd have to define .service files as an API
> though, which would feature-freeze them, and I'm not sure the systemd
> people would be happy about that.
No one would be happy about. Blocking upstream development or trying to
be more clever than upstream is generally a bad idea. And i really like
the idea.
> System-wide systemd-only services past the early boot stage are just
> bad design, do not currently exist and we shouldn't encourage their
> creation.
And why. elaborate it a bit more ...

Cheers Alf

PS: I'm not a systemd fanboi - i just use it - and i'm happy that it
goes out of my way most of the time - on desktop and servers. And i'm
an old fart, so i know the time before systemd well - to be honest, if
someone would turn back time i would abandon Linux and go back to some
sane system like Windows. I just don't want one minute on sysv anymore.
In Linux it is dead for the vast majority - and i'm thankful for.

-- 
Alf Gaida
BDBF C688 EFAD BA89 5A9F  464B CD28 0A0B 4D72 827C

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Vincent Bernat]

 ❦  8 août 2019 19:10 +02, Simon Richter :

> For servers, the benefit is rather limited. There is no local user who
> makes system-wide policy decisions, and hardware is not changing
> dynamically either. The actual services provided are either implemented as
> daemons (i.e. not microservices), or proper microservices run inside a
> site-wide microservice framework such as Docker+Kubernetes, because a
> system-local framework such as systemd is too limited to express the
> dependencies. System boot time is significantly less important than service
> response time, so "socket activation" for daemons is not useful in this
> context either. We have had this for -literally- decades in the form of
> inetd, and it has not been widely used, precisely for that reason.

inetd performance is very low because it needs to spawn one instance for
each connection. systemd socket activation has absolutely 0 overhead
except on the first connection (where systemd needs to start the
service).
-- 
After all, all he did was string together a lot of old, well-known quotations.
-- H. L. Mencken, on Shakespeare


signature.asc
Description: PGP signature

Re: Generating new IDs for cloning

[Russ Allbery]

Michael Stone  writes:

> So to find out what applications use the file you'd have to look for
> references to the various APIs (such as
> sd_id128_get_machine_app_specific or dbus-uuidgen) which themselves use
> /etc/machine-id

I believe the point of the question was to see if anyone had already done
this and knew the results, to save the effort of a research project if the
information is already documented somewhere or known to someone.

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

Re: Bug#929752: Changing quote signs in GPL allowed? [Was: Bug#929752: installation-guide: left quotes in gpl.xml are not correctly rendered in pdf ]

[Holger Wansing]

Control: tags -1 + pending


lsore...@csclub.uwaterloo.ca (Lennart Sorensen) wrote:
> On Tue, Aug 06, 2019 at 08:30:56PM +0200, Holger Wansing wrote:
> > I was about to commit these changes, however it came to my mind if such
> > changes to the GPL are allowed?
> > 
> > At least the English variant of the GPL is 'official' and is not to be
> > changed, so what about changing the quoting signs into   
> > entities?
> 
> gpl.xml isn't official.  It isn't one of the files from the FSF.
> There is a gpl-2.0.dbk[1] version available which in fact does use 
> and  while every other file format uses ` and '.  So at least
> there is precedence for using  tags instead.  After all if you
> decided to use the docbook file as your source text, you would get the
> quotes desired.
> 
> [1] https://www.gnu.org/licenses/old-licenses/gpl-2.0.dbk

Therefore I have committed the changes; tagging this bug as pending.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Russ Allbery]

Ondřej Surý  writes:

> So, just to clarify…  so, it’s ok to hate systemd, but it’s not ok to
> hate sysvinit (spaghetti of shell scripts)?

Personally, I'd be happy if people would just stop hating on any free
software in general.  Even buggy free software is someone's effort,
released into the world hopefully for our benefit.  These conversations
would be so much easier to have if they were framed in terms of costs and
benefits, different use cases, and personal preferences, rather than
making supposedly-objective statements grounded in strong personal
opinions about the merits or worthlessness of some piece of software.

Far, far beyond init systems, I wish we would be less denegrating and
dismissive even of small pieces of software with obvious problems that
people propose packaging.  We can say that something needs various
improvements to make sense to include in Debian without hating on it.
Maybe that sort of positive and thankful attitude would then carry over to
larger and more controversial pieces of software.

(And yes, I wish upstreams would take that same advice, but I know how to
preach to this audience and have less ability to preach to other
audiences, so)

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

Re: Generating new IDs for cloning

[Marvin Renich]

* Michael Stone  [190808 12:34]:
> I guess I need you to say what's confusing. It's an ID that doesn't change.
> You can look up gethostid to get a little more background. If you need an ID

First, let me say that I am not trying to be intentionally obtuse.  I am
really interested to know what programs, more specifically, what
services in a "typical" installation, actually use machine-id (for one
or more definitions of "typical", e.g. desktop or server).

What prompted my question was that someone earlier in this thread stated
that when he removed this file the system became unbootable (I think it
was a banana pi).  What part of the boot process fails?  What other
things that are commonly installed on some large class of machines are
going to fail if this is either missing or identical to ten other
machines on the same network that I cloned from the same image?

Marc's comment that systemd-networkd fails is a good partial answer.
The fact that the man page belongs to the systemd package is another
good clue, but not an answer.  Was this file added as part of systemd
because it was believed that gethostid(3) was insufficient?  If so, what
parts of systemd use it?

...Marvin

Bug#934253: ITP: xdg-utils-cxx -- Implementation of the Free Desktop Standards in C++.

[Scarlett Moore]

Package: wnpp
Severity: wishlist
Owner: Scarlett Moore 

* Package name: xdg-utils-cxx
  Version : 1.0.0
  Upstream Author : Alexis López Zubieta
* URL : https://github.com/azubieta/xdg-utils-cxx
* License : MIT/X
  Programming Lang: C++
  Description : Implementation of the Free Desktop Standards in C++.

Implementation of the Free Desktop Standards in C++.

This is a project was started to fulfill the need of a reliable implementations 
of such standards in the AppImage project. It is totally standalone and only 
depends on the standard c++ libraries (stdlib).

It has been split in different modules according to the Free Desktop Standards, 
currently are implemented:

Desktop Entry 1.2 (mostly complete)
Base Dir 0.7 (draft)

This is a dependency of libappimage.

RE:Generating new IDs for cloning

[PICCA Frederic-Emmanuel]

did you tried this

https://codesearch.debian.net/search?q=machine-id&literal=1&perpkg=1

[OT] /etc/machine-id "must not be exposed in untrusted environments"

[Marvin Renich]

This is related to the thread Generating new IDs for cloning, but is
probably OT for this list.  I guess this is really a question for
systemd maintainers?  Should I file a bug?

The man page for machine-id says:

  This ID uniquely identifies the host. It should be considered
  "confidential", and must not be exposed in untrusted environments, in
  particular on the network.

Why is the file mode 0666?  Does it need to be non-root readable?  If
so, how can it be prevented from being exposed on the network if there
is any user access from the network?  Is this really a security concern?

...Marvin

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Ondřej Surý]

I pretty much agree with everything you just said.

O.
--
Ondřej Surý 

> On 8 Aug 2019, at 20:34, Russ Allbery  wrote:
> 
> Ondřej Surý  writes:
> 
>> So, just to clarify…  so, it’s ok to hate systemd, but it’s not ok to
>> hate sysvinit (spaghetti of shell scripts)?
> 
> Personally, I'd be happy if people would just stop hating on any free
> software in general.  Even buggy free software is someone's effort,
> released into the world hopefully for our benefit.  These conversations
> would be so much easier to have if they were framed in terms of costs and
> benefits, different use cases, and personal preferences, rather than
> making supposedly-objective statements grounded in strong personal
> opinions about the merits or worthlessness of some piece of software.
> 
> Far, far beyond init systems, I wish we would be less denegrating and
> dismissive even of small pieces of software with obvious problems that
> people propose packaging.  We can say that something needs various
> improvements to make sense to include in Debian without hating on it.
> Maybe that sort of positive and thankful attitude would then carry over to
> larger and more controversial pieces of software.
> 
> (And yes, I wish upstreams would take that same advice, but I know how to
> preach to this audience and have less ability to preach to other
> audiences, so)
> 
> -- 
> Russ Allbery (r...@debian.org)   
> 

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Paul Gevers]

Hi,

On 07-08-2019 16:57, Ian Jackson wrote:
> Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team: 
> ride like the wind, Bullseye!"):
>> No, what I have been perceiving (and pretty please note that this is my
>> personal "feeling") is that maintainers, specially library maintainers, have
>> even more and more "stuff to care for".
> 
> I can see why you feel that way.
> 
> I think maybe we need to make it easier for the maintainer of a
> widely-used library to push some of this out to depending packages.

I agree with this.

> (And I speak as a maintainer of a leaf package with a thorough
> autopkgtest suite which often blocks the migration of my
> dependencies.)
> 
> Lisandro, would it meet your needs if you had free licence to file RC
> bugs against all packages which were blocking your migration, before
> you had done the investigation yourself ?
>
> I think the effect would be that a maintainer of a dependent package
> would have to engage with the situation and if they did nothing for
> long enough, the autoremoval would kick in.  Then your library would
> be able to migrate.

Obviously this only works if the reverse dependency isn't also a key
package. So, in any case, please contact the release team early if you
experience problems, we can help.

> This seems similar to the approach we take with (say) new compilers,
> which trigger FTBFS bugs in depending packages.  The compiler
> maintainers do not investigate the issues - they file bugs, which
> eventually become RC, and then the depending packages must either be
> fixed our autoremoved.

I think we should also try to improve the visibility towards reverse
dependencies that their autopkgtest is blocking other packages. I would
love tracker (and the old pts) to show this on their page. (Working on
such a patch is on my TODO list, except not at the top).

> (Of course some library maintainers would prefer to do some
> investigation first.)

I can already trigger all the autopkgtests in unstable for packages that
are in experimental, so if you interested in this, please contact me.
This would enable library maintainers to at least have an overview of
what would happen. I could even activate this by default.

We also have an Outreachy intern working on a self-service corner on
ci.d.n, so that more testing can be done if people want it.

Paul



signature.asc
Description: OpenPGP digital signature

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Simon Richter]

Hi,

On Thu, Aug 08, 2019 at 08:15:29PM +0200, Vincent Bernat wrote:

> inetd performance is very low because it needs to spawn one instance for
> each connection. systemd socket activation has absolutely 0 overhead
> except on the first connection (where systemd needs to start the
> service).

If you specify "wait" instead of "nowait" for a TCP service, your service
is handed the listening socket, and can continue to accept more connections
on that socket.

This feature went unused not because noone thought of it, but because there
is no real world use case that benefits from it. Either the service is used
regularly, then it makes sense to keep the daemon in memory, or it isn't,
then the reduced complexity for one-shot services (to the point where you
can use a shell script as a service) is the benefit.

In the same way, we could have had automatic restart of services through
sysvinit easily: an include mechanism that allows additional inittab lines
to be pulled from /etc/inittab.d/* would be trivial to implement. That it
hasn't been done is not because no one has thought about it in the last
thirty years, but because its use is rather limited.

SystemV init does not define service monitoring, because "the process still
exists" is a useless metric, and proper monitoring tests service
availability instead. There is no point in automatically restarting a
crashed service either -- a crash has a reason that needs to be
investigated. There is no service that is at the same time so important
that it must not go down under any circumstances, and at the same time so
unimportant that problems with it do not warrant human attention.

The most useful thing systemd provides to server operators is a shorthand
form for specifying some items in the process environment. Where an init
script needs to set up the environment in the right order (e.g. go into the
chroot before dropping permissions), having a descriptive language there
takes care of some of the complexity -- but that is functionally equivalent
to passing these values as arguments to start-stop-daemon.

All of these things have been proposed multiple times over the last thirty
years. They look useful on the outset, but the real-world use is limited.

   Simon

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Russ Allbery]

Simon Richter  writes:

> In the same way, we could have had automatic restart of services through
> sysvinit easily: an include mechanism that allows additional inittab
> lines to be pulled from /etc/inittab.d/* would be trivial to
> implement. That it hasn't been done is not because no one has thought
> about it in the last thirty years, but because its use is rather
> limited.

Er, well... speaking as someone who tried to keep daemons running via
inittab and then gave up and tried using monit for a while, and then
switched to djb daemontools (all back before systemd existed), I'm not
sure this is quite right.  Those who tried to use this facility quickly
discovered that sysvinit was rather bad at it, and therefore started using
something else.

Problems included difficulty controlling respawn rates, sometimes-silent
permanent termination of the service when something went wrong, no support
for per-service fragments (easy to implement or not, no one implemented
it), weird behavior when daemons got into a crash loop, no good way to
externally control whether the service was temporarily disabled or not,
problems specifying and controlling start order, weird behavior with
standard input and output, and weirdness when changing the configuration.
djb started daemontools via a script in inittab and suggested just
rebooting the machine after initial configuration because getting init to
reload its configuration properly was too unpredictable.

Note that this is not a statement about Linux sysvinit specifically -- my
experiences were originally on Solaris.  The flaws in using inittab to
keep services running were universal among UNIX implementations.

systemd is *much* better at these things, as is runit, upstart, and
basically every other init system that came along after sysvinit.  This is
a very widely-known flaw in the sysvinit design and basically every
implementation that everyone else fixed.

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

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Michael Stone]

On Thu, Aug 08, 2019 at 01:08:41PM -0700, Russ Allbery wrote:

Simon Richter  writes:


In the same way, we could have had automatic restart of services through
sysvinit easily: an include mechanism that allows additional inittab
lines to be pulled from /etc/inittab.d/* would be trivial to
implement. That it hasn't been done is not because no one has thought
about it in the last thirty years, but because its use is rather
limited.


Er, well... speaking as someone who tried to keep daemons running via
inittab and then gave up and tried using monit for a while, and then
switched to djb daemontools (all back before systemd existed), I'm not
sure this is quite right.  Those who tried to use this facility quickly
discovered that sysvinit was rather bad at it, and therefore started using
something else.


Yup. Regardless of those who keep insisting that systemd doesn't add 
anything to a server environment, people happily using it for servers 
disagree. I assume those who insist that sysvinit did everything right 
simply either forget the problems it had or just accepted its 
limitations.



Note that this is not a statement about Linux sysvinit specifically -- my
experiences were originally on Solaris.  The flaws in using inittab to
keep services running were universal among UNIX implementations.


And until we got rid of legacy limitations, there was no way forward 
because everything was met with "but this is how its always worked and 
you'll never manage to change things on those other systems".

Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[Aurelien Jarno]

[ debian-arm is Cced: as armel and armhf might be impacted in the
  future]
[ debian-devel is Cced: as i386 might be impacted in the future]
[ debian-release is Cced: as the release has to agree with the 
  solution]


Hi all,

32-bit processes are able to address at maximum 4GB of memory (2^32),
and often less (2 or 3GB) due to architectural or kernel limitations.
There are many ways to support more than 4GB of memory on a system
(64-bit CPU and kernel, PAE, etc.), but in the end the limit per process
is unchanged.

As Debian builds packages natively, this 4GB limit also applies to
the toolchain, and it's not uncommon anymore to get a "virtual memory
exhausted" error when building big packages. Tricks have been used
to workaround that, like disabling debugging symbols or tweaking the
GCC garbage collector (ggc-min-expand option). This is the case for
example of firefox or many scientific packages. For leaf packages they
are usually left uncompiled on the corresponding architectures.

mips and mipsel are more affected by the issue as the virtual address
space is limited to 2GB. Therefore on those architectures, this issue
recently started to also affect core packages like ghc and rustc, and
the usual tricks are not working anymore. The case of ghc is interesting,
as the problem also now happens on non-official architectures like hppa
and x32. The *i386 architectures are not affected as they use the native
code generator. The armel and armhf architectures are not affected as
they use the LLVM code generator.

We are at a point were we should probably look for a real solution
instead of relying on tricks. Usually upstreams are not really
interested in fixing that issue [1]. The release team has made clear
that packages have to be built natively (NOT cross-built) [2]. Therefore
I currently see only two options:

1) Build a 64-bit compiler targeting the 32-bit corresponding
   architecture and install it in the 32-bit chroot with the other
   64-bit dependencies. This is still a kind of cross-compiler, but the
   rest of the build is unchanged and the testsuite can be run. I guess
   it *might* be something acceptable. release-team, could you please
   confirm?
   
   In the past it would have been enough to "just" do that for GCC, but
   nowadays, it will also be needed for rustc, clang and many more. The
   clang case is interesting as it is already a cross-compiler
   supporting all the architectures, but it default to the native
   target. I wonder if we should make mandatory the "-target" option,
   just like we do not call "gcc" anymore but instead "$(triplet)-gcc".
   Alternatively instead of creating new packages, we might just want
   to use the corresponding multiarch 64-bit package and use a wrapper
   to change the native target, ie passing -m32 to gcc or -target to
   clang.

2) Progressively drop 32-bit architectures when they are not able to
   build core packages natively anymore.

Any comments, ideas, or help here?

Regards,
Aurelien

[1] https://github.com/rust-lang/rust/issues/56888
[2] https://lists.debian.org/debian-release/2019/08/msg00215.html 

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


signature.asc
Description: PGP signature

Re: Please stop hating on sysvinit, systemd… and let go of the hating anyway (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Martin Steigerwald]

Russ Allbery - 08.08.19, 20:33:58 CEST:
> Ondřej Surý  writes:
> > So, just to clarify…  so, it’s ok to hate systemd, but it’s not ok
> > to
> > hate sysvinit (spaghetti of shell scripts)?
> 
> Personally, I'd be happy if people would just stop hating on any free
> software in general.  Even buggy free software is someone's effort,
> released into the world hopefully for our benefit.  These
> conversations would be so much easier to have if they were framed in
> terms of costs and benefits, different use cases, and personal
> preferences, rather than making supposedly-objective statements
> grounded in strong personal opinions about the merits or
> worthlessness of some piece of software.

Wonderful, Russ.

Definitely a +1 from me.

What if… just what if if SysVInit and Systemd are just different and none 
of them is even inherently better than the other. What if… just what if 
this is similar to KDE and GNOME, Linux and FreeBSD, Amiga and Atari, 
Ruby and Python, Vi and Emacs?

What if, just what if I just let go of all the judgments? Just for now. 
And see what happens then.

And of cause I can say I like this or that due to this and that… but an 
apparent other can say I like that or this due to that or this. What if, 
just what if in the end its just arbitrary? Its just opinions. What if, 
just what if none of this is *the* truth?

I believe this mind set would help a lot to just agree to disagree and 
move on with life.

Thanks,
-- 
Martin

Re: [OT] /etc/machine-id "must not be exposed in untrusted environments"

[Sven Joachim]

On 2019-08-08 15:20 -0400, Marvin Renich wrote:

> This is related to the thread Generating new IDs for cloning, but is
> probably OT for this list.  I guess this is really a question for
> systemd maintainers?  Should I file a bug?

No.

> The man page for machine-id says:
>
>   This ID uniquely identifies the host. It should be considered
>   "confidential", and must not be exposed in untrusted environments, in
>   particular on the network.
>
> Why is the file mode 0666?

0644, not 0666.

> Does it need to be non-root readable?

Presumably yes, since applications and services running as non-root will
likely want to access it.

> If so, how can it be prevented from being exposed on the network if
> there is any user access from the network?  Is this really a security
> concern?

No, but it is a privacy concern, since exposing the file over the
network may allow tracking your machine.

https://github.com/systemd/systemd/pull/4645
https://superuser.com/questions/1214704/can-an-attacker-exploit-my-etc-machine-id

HTH,
Sven

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[Ben Hutchings]

On Thu, 2019-08-08 at 22:38 +0200, Aurelien Jarno wrote:
[...]
> 1) Build a 64-bit compiler targeting the 32-bit corresponding
>architecture and install it in the 32-bit chroot with the other
>64-bit dependencies. This is still a kind of cross-compiler, but the
>rest of the build is unchanged and the testsuite can be run. I guess
>it *might* be something acceptable. release-team, could you please
>confirm?
>
>In the past it would have been enough to "just" do that for GCC, but
>nowadays, it will also be needed for rustc, clang and many more. The
>clang case is interesting as it is already a cross-compiler
>supporting all the architectures, but it default to the native
>target. I wonder if we should make mandatory the "-target" option,
>just like we do not call "gcc" anymore but instead "$(triplet)-gcc".
>Alternatively instead of creating new packages, we might just want
>to use the corresponding multiarch 64-bit package and use a wrapper
>to change the native target, ie passing -m32 to gcc or -target to
>clang.
[...]
> Any comments, ideas, or help here?
[...]

1a. Require 32-bit build environments to be multiarch with the
related 64-bit architecture also enabled.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed
- Carolyn Scheppner




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

Bug#934266: ITP: whawty-auth -- simple file based authentication suite

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: whawty-auth
  Version : 0.2
  Upstream Author : whawty contributors (see AUTHORS file)
* URL : https://github.com/whawty/auth/blob/master/AUTHORS
* License : BSD-3
  Programming Lang: Go
  Description : simple file based authentication suite

whawty.auth is a simple file based authentication suite. Its store uses flat
files containing password hashes. These hashes are currently based on scrypt but
the algorithm can be upgraded to newer/stronger formats on the fly. To find out
more about the storage backend read [SCHEMA.md].

It is possible to interact with whawty through a simple web UI, or a Unix socket
implementing the saslauthd protocol; a PAM module is provided using the socket.

[SCHEMA.md]: https://github.com/whawty/auth/blob/master/doc/SCHEMA.md

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl1Mk54RHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7Mu5Bw//dZTmXgHl4jJm6/cLO0K9IigH3TjrPyW8
yL89mJrUC4b7QjOfd9v5u7VzutIw/TK/DQ8gZHxbAIuAcvbSeWNGBibvs0ZIajw1
S8cWLH345kxf/vQxRjwdkxs3JsHFlqLnkrziJk3Q8JCAILvVo/4MHOeMC4Pcx/gO
NccibaHhVdG1xLgDKaeX97jR/xGiHFaXaJvPmFqf7qwFpcmXCUmdcrQftVFlzpxz
TCx0VlnwLh+nRJ5HMbAXWVi/+eClqqMPLmDOHyqHQsbbihs4boHp02D7Z44JLHN6
g9ankGH2t4PT2vM9f7pHazYfyp/O/AaNSHQMccBpQA6so7r+ZLh1bBhVY15VHZuF
0anJxAVEGjLF7Z+ix64xc6agXnqGxG1CyEjzdVOqnS06DtVlddc8p7WvMXdFFvgw
3and4nHt/P5FlUt/CvzG3merQkNThL3b62TMWwqCzekrfzgGxPHv5WmtBXUwdFGY
nF2khXtaicORawUWA68q+3rc/z5vpMEhEIThgipugvqbS0V8p6NZkt0u5Lxuo/2f
hHrk8JD9e2pWKQNLBuRxrG2z64m56HXXVMdGW3cB/HZe3B6nSzigYFEHdFwy1TmN
VA3uYMQfSWv209sKgPCu747y99YCj3m0gt62XIMvRTk+DfSXpA/KRb1YkTYFkViT
Jrlruk3qYuY=
=jBSi
-END PGP SIGNATURE-

Re: [OT] /etc/machine-id "must not be exposed in untrusted environments"

[Jonathan Carter]

On 2019/08/08 23:12, Sven Joachim wrote:
>> The man page for machine-id says:
>>
>>   This ID uniquely identifies the host. It should be considered
>>   "confidential", and must not be exposed in untrusted environments, in
>>   particular on the network.
>>
>> Why is the file mode 0666?
> 0644, not 0666.

444 even (original post gave me a fright so I checked).

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Generating new IDs for cloning (was Re: duplicate popularity-contest ID)

[Simon McVittie]

On Thu, 08 Aug 2019 at 13:39:54 +0200, Marc Haber wrote:
> Generating a new machine-id doesn't seem as easy as generating a new
> ssh key: Removing /etc/machine-id doesn't do it as
> systemd-machine-id-setup seems to pull the machine-id from dbus.

For historical reasons (dbus originated the concept and
systemd generalized it into a non-D-Bus-specific "API"), each of
systemd-machine-id-setup and dbus-uuidgen tries to copy the other's
machine ID, to avoid problems where processes that read the two files
in opposite orders disagree on what the machine's unique ID is.
If you delete or empty /etc/machine-id you should also delete
/var/lib/dbus/machine-id.

Making /etc/machine-id a 0-byte file is considered to be the canonical
way to clear it, rather than actually deleting it, because if systemd is
running on a completely read-only root filesystem, it has code to create
a machine ID on a tmpfs and bind-mount it over the top of the empty file.

If you are doing cloning, stateless systems or similar activities,
and you know you will have a valid /etc/machine-id (you either use
systemd or have taken other steps to have one), then you can make
/var/lib/dbus/machine-id a symlink to /etc/machine-id (dbus comes with a
systemd-tmpfiles file to do this). This is not done by default in Debian,
or by `dbus-uuidgen --ensure`, for historical reasons; maybe it should be,
but to be confident that it was a correct change I'd have to think about
the ways in which it might go wrong on non-systemd systems (with either
a non-systemd init like sysvinit, or no init at all like minimal chroots).

Maybe /etc/machine-id should be part of the "API" of a Debian system in
general (systemd or not)?

smcv

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[John Paul Adrian Glaubitz]

Hi!

On 8/8/19 10:38 PM, Aurelien Jarno wrote:
> Any comments, ideas, or help here?
I'm by no means a GHC nor Haskell expert, but I think it should be generally
feasible to add native code generation support in GHC for all architectures
which are supported by LLVM.

According to a bug report I saw upstream [1], adding native support for GHC
through LLVM is comparably easy and might be a good options for mips*, riscv*,
s390x and sparc* which all are officially supported by LLVM but have no NGC
in GHC (with the exception of SPARC which has a 32-bit NGC that James Clarke is
currently porting to SPARC64 [2]).

I would be willing to support such a project financially (e.g. BountySource).

Adrian

> [1] https://gitlab.haskell.org/ghc/ghc/issues/16783
> [2] https://github.com/jrtc27/ghc/tree/rebased

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Generating new IDs for cloning

[Simon McVittie]

On Thu, 08 Aug 2019 at 08:37:16 -0400, Marvin Renich wrote:
> Does anyone know what applications use this file for what purpose?  Is
> this a systemd-ism?

It originated as /var/lib/dbus/machine-id in D-Bus, and systemd picked it
up and generalized it into something non-D-Bus-specific. It isn't really
particularly specific to either D-Bus or systemd: they both provide it
as a piece of generically useful functionality for anything else that
wants it. Asking which applications use it is a bit like asking which
applications use gethostname(2): you are not going to get an exhaustive
list unless you use something like codesearch.

It's intended as an opaque, non-human-meaningful, persistent unique
identifier for a machine (or more precisely an OS installation), used as
a lookup key in state/configuration storage in the same sorts of places
you might be tempted to use a hostname.

Being opaque and non-human-meaningful is important for some of the
places where it's useful, because if a string is human-meaningful (like a
hostname), then people will sometimes want to change it, and when they do,
anything that was recording machine-specific state with the hostname as
unique identifer will no longer be able to associate the machine-specific
state with the machine, effectively resulting in data loss.

One example of the machine ID being used to identify hardware devices
is that GNOME stores screen layout configuration keyed by machine ID,
so that if you have an NFS-shared home directory or similar, it won't try
to use your laptop's monitor layout on your desktop (or keep overwriting
one layout with the other).

One example of the machine ID being used to identify an OS installation is
that if you use the systemd-boot EFI bootloader on a dual- or multi-boot
Linux system (e.g. Debian and Fedora sharing a disk), systemd-boot stores
each OS installation's kernel(s) in a directory named after the machine
ID, so that they won't collide.

smcv

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[Aurelien Jarno]

On 2019-08-08 22:23, Ben Hutchings wrote:
> On Thu, 2019-08-08 at 22:38 +0200, Aurelien Jarno wrote:
> [...]
> > 1) Build a 64-bit compiler targeting the 32-bit corresponding
> >architecture and install it in the 32-bit chroot with the other
> >64-bit dependencies. This is still a kind of cross-compiler, but the
> >rest of the build is unchanged and the testsuite can be run. I guess
> >it *might* be something acceptable. release-team, could you please
> >confirm?
> >
> >In the past it would have been enough to "just" do that for GCC, but
> >nowadays, it will also be needed for rustc, clang and many more. The
> >clang case is interesting as it is already a cross-compiler
> >supporting all the architectures, but it default to the native
> >target. I wonder if we should make mandatory the "-target" option,
> >just like we do not call "gcc" anymore but instead "$(triplet)-gcc".
> >Alternatively instead of creating new packages, we might just want
> >to use the corresponding multiarch 64-bit package and use a wrapper
> >to change the native target, ie passing -m32 to gcc or -target to
> >clang.
> [...]
> > Any comments, ideas, or help here?
> [...]
> 
> 1a. Require 32-bit build environments to be multiarch with the
> related 64-bit architecture also enabled.

Indeed, but that looks like the first step. From there do you think
a) the package is responsible for build-depending on the 64-bit
   toolchain and calling it with the right option to generate 32-bit
   binaries?
or
b) the build environment should be already configured to make the
   64-bit toolchain available transparently

I had option b) in mind, but option a) looks way easier to implement on
the infrastructure side, although a bit less on the packaging side. It
can also be a first step towards b). In that case we should also make
sure that using a 64-bit compiler doesn't switch the package build
system to a cross-compilation mode, where notably the testsuite is
disabled.

Aurelien

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


signature.asc
Description: PGP signature

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[Aurelien Jarno]

On 2019-08-08 23:57, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> On 8/8/19 10:38 PM, Aurelien Jarno wrote:
> > Any comments, ideas, or help here?
> I'm by no means a GHC nor Haskell expert, but I think it should be generally
> feasible to add native code generation support in GHC for all architectures
> which are supported by LLVM.
> 
> According to a bug report I saw upstream [1], adding native support for GHC
> through LLVM is comparably easy and might be a good options for mips*, riscv*,
> s390x and sparc* which all are officially supported by LLVM but have no NGC
> in GHC (with the exception of SPARC which has a 32-bit NGC that James Clarke 
> is
> currently porting to SPARC64 [2]).

Yes, that's clearly the way to go for the GHC issue. As a bonus it
greatly improves the performances.

That said it doesn't solve the problem in general, ie for rustc or the
future affected packages.

Aurelien

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

Re: [OT] /etc/machine-id "must not be exposed in untrusted environments"

[Simon McVittie]

On Thu, 08 Aug 2019 at 15:20:28 -0400, Marvin Renich wrote:
> The man page for machine-id says:
> 
>   This ID uniquely identifies the host. It should be considered
>   "confidential", and must not be exposed in untrusted environments, in
>   particular on the network.
> 
> Why is the file mode 0666?

I very much hope it's 0644 (rw-r--r-- or 0444 (r--r--r--). Mine is 0444.

> Does it need to be non-root readable?

Yes. Some of the applications that want an opaque unique identifier for
the machine, like dbus-launch(1) (which uses it to disambiguate between
machines sharing an X11 display), are unprivileged. If /etc/machine-id
wasn't readable by unprivileged users, then applications and services that
want a machine identifier would just have to invent another equally-unique
identifier (or use the hostname), which would have essentially the same
privacy implications as /etc/machine-id.

gethostname(2) and /etc/hostname are also world-readable. The machine-id
is just like the hostname, except that because it isn't human-meaningful,
people hopefully don't change it to something they like better and expect
not to lose their per-machine configuration and state as a result.

> If
> so, how can it be prevented from being exposed on the network if there
> is any user access from the network?  Is this really a security concern?

If applications routinely broadcast the machine ID on local LANs or
to an Internet server, then the operator of those LANs or servers
can tell whether connections are coming from the same or different
machines. Some people would consider this to be a privacy violation
("fingerprinting"). I suspect that the intention of that text is to
encourage authors of networked software that uses the machine ID to
think about this.

Analogous: don't tell those same LANs or servers your gethostname(2),
or your MAC address (without randomization), or your IPv6 address
(without "privacy extensions"), if you don't want them to be able to
tell which machine you are using.

smcv

Re: duplicate popularity-contest ID

[Bill Allombert]

On Tue, Aug 06, 2019 at 02:01:16PM -0400, Sam Hartman wrote:
> > "Bill" == Bill Allombert  writes:
> 
> Bill> This is potentially an excellent idea!
> 
> Bill> Does not /etc/machine-id suffer of exactly the same issue as
> Bill> /etc/popularity-contest.conf ?
> 
> A lot more procedures for cloning images know that they need to generate
> new /etc/machine-ids.
> 
> It's one of those things you tend to realize fairly quickly that you
> need to fix up in cloned images.
> Interactions with machined, systemd journal, and a few other things tend
> to make it obvious.

However there some points in "man machine-id" which are rather
problematic for popularity-contest:

  Optionally, for stateless systems, it is generated during runtime at
  early boot if it is found to be empty.

Unless such system has very high uptime, it is much preferable for
stateless systems with identical images to report with the same popcon
ID rather than generate identical ghost submissions with each boots
(which stays active for 20 days).

  The machine-id may also be set, for example when network
  booting, by setting the systemd.machine_id= kernel command line
  parameter or passing the option --machine-id= to systemd. A machine-id
  may not be set to all zeros.

It seems machine-id is too linked to the boot process to be usable by popcon.

   When a machine is booted with systemd(1) the ID of the machine will
   be established. If systemd.machine_id= or --machine-id= options (see
   first section) are specified, this value will be used.  Otherwise, the
   value in /etc/machine-id will be used. If this file is empty or missing,
   systemd will attempt to use the D-Bus machine ID from
   /var/lib/dbus/machine-id, the value of the kernel command line option
   container_uuid, the KVM DMI product_uuid (on KVM systems), and finally a
   randomly generated UUID.

Again this would generate ghost submissions.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: [OT] /etc/machine-id "must not be exposed in untrusted environments"

[Jim Popovitch]

On Thu, 2019-08-08 at 15:20 -0400, Marvin Renich wrote:
> This is related to the thread Generating new IDs for cloning, but is
> probably OT for this list.  I guess this is really a question for
> systemd maintainers?  Should I file a bug?
> 
> The man page for machine-id says:
> 
>   This ID uniquely identifies the host. It should be considered
>   "confidential", and must not be exposed in untrusted environments, in
>   particular on the network.
> 
> Why is the file mode 0666?  Does it need to be non-root readable? 

Mine is 0444, so that Chrome can read it.  /s

-Jim P.

Re: [OT] /etc/machine-id "must not be exposed in untrusted environments"

[Adam Borowski]

On Thu, Aug 08, 2019 at 11:12:37PM +0200, Sven Joachim wrote:
> On 2019-08-08 15:20 -0400, Marvin Renich wrote:
> > The man page for machine-id says:
> >
> >   This ID uniquely identifies the host. It should be considered
> >   "confidential", and must not be exposed in untrusted environments, in
> >   particular on the network.

> > If so, how can it be prevented from being exposed on the network if
> > there is any user access from the network?  Is this really a security
> > concern?
> 
> No, but it is a privacy concern, since exposing the file over the
> network may allow tracking your machine.

For example Chromium does so for Google-specific tracking id (some "cloud
management enrollment token").

But... if this ID must not be exposed on the network, why does it need to be
unique?  There's systemd-networkd leaking it to dhcp servers, but that's a
violation of a "must" requirement of their own standard, and other dhcp
clients don't have that problem.

Are there any other such issues?

Thus, what about just writing "Spartacus" to that file?  To avoid NIH, let's
use "d41d8cd98f00b204e9800998ecf8427e" as proposed by Jamey Fletcher.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Work-needing packages report for Aug 9, 2019

[wnpp]

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

Total number of orphaned packages: 1421 (new: 13)
Total number of packages offered up for adoption: 156 (new: 6)
Total number of packages requested help for: 54 (new: 0)

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



The following packages have been orphaned:

   asciidoc (#934015), orphaned 2 days ago
 Description: Highly configurable text format for writing
   documentation
 Reverse Depends: asciidoc asciidoc-base asciidoc-dblatex
   asciidoc-doc asciidoc-fop asciidoc-tests python3-tldp ruby-mizuho
 Installations reported by Popcon: 2996
 Bug Report URL: https://bugs.debian.org/934015

   clp (#934083), orphaned 2 days ago
 Description: Coin-or linear programming
 Reverse Depends: coinor-cbc coinor-clp coinor-libcbc-dev
   coinor-libcbc3 coinor-libcgl-dev coinor-libcgl1 coinor-libclp-dev
   coinor-libsymphony-dev coinor-libsymphony3 coinor-symphony (4 more
   omitted)
 Installations reported by Popcon: 89027
 Bug Report URL: https://bugs.debian.org/934083

   cmph (#934019), orphaned 2 days ago
 Description: C Minimal Perfect Hashing Library development files
 Reverse Depends: libcmph-dev libcmph-tools
 Installations reported by Popcon: 28
 Bug Report URL: https://bugs.debian.org/934019

   coinor-cbc (#934084), orphaned 2 days ago
 Description: Coin-or branch-and-cut mixed integer programming solver
 Reverse Depends: coinor-cbc coinor-libcbc-dev coinor-libcoinmp-dev
   coinor-libcoinmp1v5 libopenms2.4.0 libreoffice-calc mccs python-pulp
   python3-pulp topp
 Installations reported by Popcon: 88937
 Bug Report URL: https://bugs.debian.org/934084

   coinor-cgl (#934085), orphaned 2 days ago
 Description: COIN-OR Cut Generation Library
 Reverse Depends: coinor-cbc coinor-libcbc-dev coinor-libcbc3
   coinor-libcgl-dev coinor-libsymphony-dev coinor-libsymphony3
   coinor-symphony libopenms2.4.0 r-bioc-lpsymphony r-cran-rsymphony (1
   more omitted)
 Installations reported by Popcon: 89020
 Bug Report URL: https://bugs.debian.org/934085

   coinor-osi (#934086), orphaned 2 days ago
 Description: Osi (Open Solver Interface)
 Reverse Depends: coinor-cbc coinor-libcbc-dev coinor-libcbc3
   coinor-libcgl1 coinor-libclp-dev coinor-libclp1 coinor-libflopc++0
   coinor-libosi-dev coinor-libsymphony-dev coinor-libsymphony3 (5 more
   omitted)
 Installations reported by Popcon: 77581
 Bug Report URL: https://bugs.debian.org/934086

   coinor-symphony (#934087), orphaned 2 days ago
 Description: COIN-OR solver for mixed-integer linear programs
 Reverse Depends: coinor-libsymphony-dev coinor-symphony
   r-bioc-lpsymphony r-cran-rsymphony
 Installations reported by Popcon: 415
 Bug Report URL: https://bugs.debian.org/934087

   coinutils (#934088), orphaned 2 days ago
 Description: CoinUtils (Coin-or Utilities)
 Reverse Depends: coinor-cbc coinor-clp coinor-libcbc-dev
   coinor-libcbc3 coinor-libcgl-dev coinor-libcgl1 coinor-libclp-dev
   coinor-libclp1 coinor-libcoinutils-dev coinor-libflopc++0 (9 more
   omitted)
 Installations reported by Popcon: 77581
 Bug Report URL: https://bugs.debian.org/934088

   gnome-shell-pomodoro (#934017), orphaned 2 days ago
 Description: GNOME Shell time-management app
 Reverse Depends: gnome-shell-pomodoro
 Installations reported by Popcon: 671
 Bug Report URL: https://bugs.debian.org/934017

   libmrss (#934018), orphaned 2 days ago
 Description: C library for parsing, writing and creating RSS files
   or streams
 Reverse Depends: libmrss0-dbg libmrss0-dev rsstail
 Installations reported by Popcon: 154
 Bug Report URL: https://bugs.debian.org/934018

   libnxml (#934020), orphaned 2 days ago
 Description: C library for parsing, writing and creating xml 1.0/1.1
   files or streams
 Reverse Depends: libmrss0 libmrss0-dev libnxml0-dev morla
 Installations reported by Popcon: 227
 Bug Report URL: https://bugs.debian.org/934020

   smb2www (#933869), orphaned 4 days ago
 Description: SMB/CIFS network client with a web interface
 Installations reported by Popcon: 158
 Bug Report URL: https://bugs.debian.org/933869

   wand (#934012), orphaned 2 days ago
 Description: Python interface for ImageMagick library
 Installations reported by Popcon: 71
 Bug Report URL: https://bugs.debian.org/934012

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



The following packages have been given up for adoption:

   cppo (#933912), off

Re: Bypassing the 2/3/4GB virtual memory space on 32-bit ports

[Ben Hutchings]

On Fri, 2019-08-09 at 00:28 +0200, Aurelien Jarno wrote:
> On 2019-08-08 22:23, Ben Hutchings wrote:
[...]
> > 1a. Require 32-bit build environments to be multiarch with the
> > related 64-bit architecture also enabled.
> 
> Indeed, but that looks like the first step. From there do you think
> a) the package is responsible for build-depending on the 64-bit
>toolchain and calling it with the right option to generate 32-bit
>binaries?
> or
> b) the build environment should be already configured to make the
>64-bit toolchain available transparently
> 
> I had option b) in mind, but option a) looks way easier to implement on
> the infrastructure side, although a bit less on the packaging side. It
> can also be a first step towards b).

Yes - if relatively few packages are hitting the limits, I think it
makes sense to implement (a) in the short term fix for them, then work
on (b) as the longer term solution.

> In that case we should also make
> sure that using a 64-bit compiler doesn't switch the package build
> system to a cross-compilation mode, where notably the testsuite is
> disabled.

Right.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.




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

Re: Please stop hating on sysvinit (was Re: do packages depend on lexical order or {daily,weekly,monthly} cron jobs?)

[Vincent Bernat]

 ❦  8 août 2019 21:47 +02, Simon Richter :

>> inetd performance is very low because it needs to spawn one instance for
>> each connection. systemd socket activation has absolutely 0 overhead
>> except on the first connection (where systemd needs to start the
>> service).
>
> If you specify "wait" instead of "nowait" for a TCP service, your service
> is handed the listening socket, and can continue to accept more connections
> on that socket.
[...]

My bad, I didn't know that.

> This feature went unused not because noone thought of it, but because there
> is no real world use case that benefits from it. Either the service is used
> regularly, then it makes sense to keep the daemon in memory, or it isn't,
> then the reduced complexity for one-shot services (to the point where you
> can use a shell script as a service) is the benefit.

Reality seems different. Almost nothing was using inetd (tftpd is the
only daemon I have in mind), while many daemons adopted systemd socket
activation. For example, OpenSSH (optional), Docker (by default), CUPS
(by default), libvirt (by default, several services), Dovecot (by
default). It seems the key difference is that socket-activated services
are regular services. They can be started manually if we want them to be
and they inherit everything systemd is able to provide to services.
-- 
Localise input and output in subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Bits from the Release Team: ride like the wind, Bullseye!

[Pirate Praveen]

On 2019, ഓഗസ്റ്റ് 9 1:16:23 AM IST, Paul Gevers  wrote:
>I can already trigger all the autopkgtests in unstable for packages
>that
>are in experimental, so if you interested in this, please contact me.
>This would enable library maintainers to at least have an overview of
>what would happen. I could even activate this by default.

Yes, please do this by default so we can have a better picture of the 
transition. Though for many libraries we also need to rebuild reverse build 
dependencies. I have been using salsa.debian.org/ruby-team/meta/build for this. 
Right now I'm interested in libgit2, grpc and protobuf transitions.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.