Re: Debian Buster release to partially drop non-systemd support

[Kamil Jońca]

Jonathan Dowland  writes:

> On Wed, Oct 17, 2018 at 08:33:47PM -0700, Russ Allbery wrote:
>>MAILTO was the main thing that I remember missing in terms of pure
>>functionality.
>
> This is not a complete substitute for all uses of MAILTO, but I found
> the following useful so I share it in case you weren't aware of it.
>
> Define a service specifically designed for sending status emails:
>
> status-email-user@.service:
>> [Service]
>> Type=oneshot
>> ExecStart=-/usr/local/bin/systemd-email %i
>> User=nobody
>> Group=systemd-journal
>
> (I also switch on a little status LED I have with another ExecStart
> line)
>
> /usr/local/bin/systemd-email:
>> systemctl status --full "$1" | mail -s "unit $1 failed" root
>
> Put an OnFailure= line in systemd units that you want to mail you if
> they go wrong
>
>> [Unit]
>> OnFailure=status-email-user@%n.service

But this not play well with exim4.
See:
https://lists.freedesktop.org/archives/systemd-devel/2018-September/041417.html
(and thread as a whole)
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Disks travel in packs.

Re: Debian Buster release to partially drop non-systemd support

[Jonathan Dowland]

On Thu, Oct 18, 2018 at 08:46:10AM +0200, Kamil Jońca wrote:

But this not play well with exim4.
See:
https://lists.freedesktop.org/archives/systemd-devel/2018-September/041417.html
(and thread as a whole)


Thanks for passing that along: I'm using it with Exim and haven't
noticed this particular problem, but it's useful to know it could
happen.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Debian Buster release to partially drop non-systemd support

[Adam Borowski]

On Thu, Oct 18, 2018 at 08:46:10AM +0200, Kamil Jońca wrote:
> > Put an OnFailure= line in systemd units that you want to mail you if
> > they go wrong
> >
> >> [Unit]
> >> OnFailure=status-email-user@%n.service
> 
> But this not play well with exim4.
> See:
> https://lists.freedesktop.org/archives/systemd-devel/2018-September/041417.html
> (and thread as a whole)

Ouch.  This is downright terrifying.  It should be quite obvious why things
other than exim can break when called from there.

And there's no good way for a random tool you may use to know it might get
suddenly SIGKILLed out of the blue.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary,
⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex,
⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.

Re: Debian Buster release to partially drop non-systemd support

[Jonathan Dowland]

On Thu, Oct 18, 2018 at 09:09:38AM +0100, Jonathan Dowland wrote:

Thanks for passing that along: I'm using it with Exim and haven't
noticed this particular problem, but it's useful to know it could
happen.


Ah, because I have User=nobody, and so the systemd sub-process can't
reap the privileged exim4 sub-process.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Debian Buster release to partially drop non-systemd support

[Kamil Jońca]

Adam Borowski  writes:

[..]
>
> Ouch.  This is downright terrifying.  It should be quite obvious why things
> other than exim can break when called from there.
>
> And there's no good way for a random tool you may use to know it might get
> suddenly SIGKILLed out of the blue.

The only workaround I found is to put in such 'oneshot' units

KillMode=none

just in case ...

I filled bug against systemd
https://github.com/systemd/systemd/issues/10299 but I do not know if I
am right.

KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
I cannot believe that God plays dice with the cosmos.
-- Albert Einstein, on the randomness of quantum mechanics

Re: Debian Buster release to partially drop non-systemd support

[Kamil Jońca]

Jonathan Dowland  writes:

> On Thu, Oct 18, 2018 at 09:09:38AM +0100, Jonathan Dowland wrote:
>>Thanks for passing that along: I'm using it with Exim and haven't
>>noticed this particular problem, but it's useful to know it could
>>happen.
>
> Ah, because I have User=nobody, and so the systemd sub-process can't
> reap the privileged exim4 sub-process.
This is irrelevant.
Only processes spawned from "--user"  units are safe.
Processes spawned from system units are killed regardless of 'User="
stanza. (I observed this on units with "User=news")
KJ

-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html
Every creature has within him the wild, uncontrollable urge to punt.
-- Snoopy

"debian.pool.ntp.org" for Debian derivatives?

[Philipp Hahn]

Hello,

our business model is to we sell support for our own Debian based
distribution "Univention Corporate Server":


I recently had a discussion about NTP and their pool concept per vendor:
, but one question remains:

Are we (as a Debian derivate) allowed to hard-code and use the
"debian.pool.ntp.org" or must we apply for our own pool?

This might be interesting for other derivatives as well.

Thanks for any answer
Philipp (AKA pmh...@debian.org)

PS: Paying that extra money to ntp.org would certainly not kill use, but
adding that money instead to our currently already existing support of
Debian-LTS / DebConf sponsoring / ... would probably benefit a lot more
Debian (downstream) users and developers.
-- 
Philipp Hahn
Open Source Software Engineer

Univention GmbH
be open.
Mary-Somerville-Str. 1
D-28359 Bremen
Tel.: +49 421 22232-0
Fax : +49 421 22232-99
h...@univention.de

http://www.univention.de/
Geschäftsführer: Peter H. Ganten
HRB 20755 Amtsgericht Bremen
Steuer-Nr.: 71-597-02876

Bug#911293: ITP: libre-engine-re2-perl -- RE2 regex engine

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libre-engine-re2-perl
  Version : 0.13
  Upstream Author : David Leadbeater 
* URL : https://metacpan.org/release/re-engine-RE2
* License : Artistic or GPL-1+
  Programming Lang: Perl, C
  Description : RE2 regex engine

 re::engine::RE2 replaces perl's regex engine
 in a given lexical scope with RE2.
 .
 RE2 is a primarily DFA based regexp engine from Google
 that is very fast at matching large amounts of text.
 However it does not support look behind
 and some other Perl regular expression features.
 See RE2's website at  for more information.
 .
 Fallback to normal Perl regexp is implemented by this module.
 If RE2 is unable to compile a regexp it will use Perl instead,
 therefore features not implemented by RE2 don't suddenly stop working,
 they will just use Perl's regexp implementation.

The package is an optional dependency of upcoming Licensecheck.

The package will be maintained in the Perl group.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlvIV1oACgkQLHwxRsGg
ASEaTQ/8CmNfeehPWatlPCfK5glpt5aeViUUVivKYwXpeUo01luSjDG88NkshkdG
YPBjpCCskMWKEV6YHXEn7iQVlarNo+1kX3DQjjY45+friDi8trFqimjSMt61SDs5
LTyWtAexABr2yVhaqaiDaXEOK7wkuqUjcrx66jhv11fQ4l4PDpQRz0lO8Wm+9V5M
tG7p6f1PsR9xH+H7ddc+9abzotl56FDStoY/HN8ffca13DLRiwqBK6k2rSjJWdZO
NvJpp203VF5KDdKGRF5Iji9mECvt570jfJSsrxb0TGvef7b1w25IO+GKDccyzFoT
h/HmziMPB98iO43U9SxY3eNuf8e+aeTHcn2Yr0ohI6PKvXz9y8gaUHNCb0xZIW1c
S+faVAVS4yuQNAFIOGAXy1Ez22MzaRBcYwQR3ohvEvY4RIkCV6jAcGjBkdIS33VB
QXYjQVW23qxANrjXd/qzm72M1PxbSgFUHIAWFHZz5SHv1N8f/qMDdiS4MdFE3Fku
PfcvVXBLtL5kH3rlqxrFA1qn6VNo4nyyBLnVnPIbC7MmANT+gTcFe68o1Bxlf4oc
dtKVFn7eBpMBd48wJYFMPfH938mHgCrUbcx+yoNrD5fJb3PpfPwOsm1yokbS6ou7
y8pTw/gUeU6eUAroegU21z5HwCh6CE/s3NHPWzrMouM6nGZD/hE=
=u5Zs
-END PGP SIGNATURE-

Re: OpenRC is there (was: Debian Buster release to partially drop non-systemd support)

[Thomas Goirand]

On 10/13/18 12:58 PM, Holger Levsen wrote:
> On Sat, Oct 13, 2018 at 06:01:43AM +0100, Ben Hutchings wrote:
>>> Has policy changed regarding support for multiple inits, or is it just that
>>> no one is maintaining the shim and sysvinit-core?
>>
>> The latter.  systemd-shim has been orphaned for over 2 years, and has
>> RC bugs.   sysvinit currently has two maintainers, but they've only
>> ever made one upload (over a year ago).
> 
> It seems that these facts are either largely ignored or unknown and I
> wonder if some noise should be made so that interested people can pick
> up the work now and not only complain later.

Please also consider that OpenRC is in Debian, and well maintained.
OpenRC is a very good alternative to sysv-rc, and it supports old-style
sysv-rc init scripts (with LSB headers).

Cheers,

Thomas Goirand (zigo)

Re: "debian.pool.ntp.org" for Debian derivatives?

[Ian Jackson]

Philipp Hahn writes (""debian.pool.ntp.org" for Debian derivatives?"):
> Are we (as a Debian derivate) allowed to hard-code and use the
> "debian.pool.ntp.org" or must we apply for our own pool?

The NTP pool folks would like you to use your own pool.  So would
Debian, I'm pretty sure.

> PS: Paying that extra money to ntp.org would certainly not kill use, but
> adding that money instead to our currently already existing support of
> Debian-LTS / DebConf sponsoring / ... would probably benefit a lot more
> Debian (downstream) users and developers.

I wasn't aware that they charged commercial entities in this kind of
situation but that seems reasonable to me.  IDK how much the charge
is.  You are getting a service from pool.ntp.org, and as a commercial
entity you should pay your suppliers.

If the charge is too much, you could always run your own ntp server.

If you continue to use the Debian pool to avoid paying them, then you
are using their facilities without permission.  I don't know what
German law is like but in the UK that would be the crime of
unauthorised access to a computer system.  Also they could probably
sue you for the money.

TBH I doubt they would get you prosecuted or sue you - because they're
not that kind of people and wouldn't want to harm the free software
community = but I hope you will agree that you should act legally!

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: "debian.pool.ntp.org" for Debian derivatives?

[Daniel Baumann]

On 10/18/2018 11:22 AM, Philipp Hahn wrote:
> Are we (as a Debian derivate) allowed to hard-code and use the
> "debian.pool.ntp.org" or must we apply for our own pool?

the idea between the different pool CNAMEs is that when one vendor does
something bad/wrong, the queries of devices running that version of ntp
can be easier diverted to /dev/null.

hence, as long as you don't "modify" the ntp package from debian in your
derivative, there is no need/gain of applying for an own ntp pool.

(re "modify": use your best judgement. fictional example: if you would
recompile the unmodified source package from debian with some weird
toolchain/settings in your derivative which would be likely to break
stuff, I would err on the side of causion and apply for a pool.)

Regards,
Daniel

Re: "debian.pool.ntp.org" for Debian derivatives?

[Philipp Hahn]

Hello Ian et al.,

Am 18.10.18 um 12:40 schrieb Ian Jackson:
> Philipp Hahn writes (""debian.pool.ntp.org" for Debian derivatives?"):
>> Are we (as a Debian derivate) allowed to hard-code and use the
>> "debian.pool.ntp.org" or must we apply for our own pool?
> 
> The NTP pool folks would like you to use your own pool.  So would
> Debian, I'm pretty sure.

Q: So must all Debian derivatives patch NTP and re-compile¹ it as
Debians pool is hard-coded:

> $ apt download ntp
> $ ar p ntp_1%3a4.2.8p10+dfsg-3+deb9u2_amd64.deb | tar xfO data.tar.xz 
> ./etc/ntp.conf | grep ^pool
> pool 0.debian.pool.ntp.org iburst
> pool 1.debian.pool.ntp.org iburst
> pool 2.debian.pool.ntp.org iburst
> pool 3.debian.pool.ntp.org iburst

or only the commercial derivatives?


>> PS: Paying that extra money to ntp.org would certainly not kill use, but
>> adding that money instead to our currently already existing support of
>> Debian-LTS / DebConf sponsoring / ... would probably benefit a lot more
>> Debian (downstream) users and developers.

First of all: We don't what to cheat them or Debian, but the question is
interesting enough as it can have legal questions for all derivatives.

> I wasn't aware that they charged commercial entities in this kind of
> situation but that seems reasonable to me.  IDK how much the charge
> is.  You are getting a service from pool.ntp.org, and as a commercial
> entity you should pay your suppliers.

The question remains, if "Debian" can be our supplier and allow us (and
any other derivatives) to use their pool?

> If the charge is too much, you could always run your own ntp server.

Any sane setup needs at least 4 servers. That is why there is that pool
project so not everyone has to run their own farm of NTP servers around
the world themselves.

> If you continue to use the Debian pool to avoid paying them, then you
> are using their facilities without permission.
...
> TBH I doubt they would get you prosecuted or sue you - because they're
> not that kind of people and wouldn't want to harm the free software
> community = but I hope you will agree that you should act legally!

Normally I tell our customers to ask their Internet providers for their
preferred NTP servers, as they usually run their own farm, which are
then close to their customers (network wise). Many routers have a
built-in NTP server anyway. This normally improves the accuracy and
reduces network traffic as with the pool you can get servers from the
other end of the world. Lucky you if you get that information from your
provider via DHCP (option nntp-server).

Even if your provider does not run its own farm, you can still
re-configure your servers to use at least the pool for your continent or
country, which hopefully are closer by network vise, too.

As an end-user you are not bound by that pool.ntp.org rule and can
configure whatever server you like.

But not as a software or Operating System vendors: I MUST NOT use
'pool.ntp.org'.

So my question is more like "is it okay to not change Debians default
NTP server selection", so the initial setup and those lazy enough to not
change the default get a sane time?

Philipp


¹: not a big deal for us, but we try to stay as closely to Debian as we can.

Re: "debian.pool.ntp.org" for Debian derivatives?

[Ansgar Burchardt]

On Thu, 2018-10-18 at 13:57 +0200, Philipp Hahn wrote:
> So my question is more like "is it okay to not change Debians default
> NTP server selection", so the initial setup and those lazy enough to
> not change the default get a sane time?

I don't think Debian can answer that question and suggest to ask the
pool operators.  This seems to be the correct list:
  https://lists.ntp.org/listinfo/pool

A related question is the use of API keys that are included in some
packages (e.g. chromium).  These are also vendor-specific, but cannot
be really secret (as they are included in the binaries and could be
extracted even for proprietary software).

Ansgar

Re: Debian Buster release to partially drop non-systemd support

[Felipe Sateler]

On Thu, 18 Oct 2018 06:58:14 +0100, Jonathan Dowland wrote:

> On Wed, Oct 17, 2018 at 08:33:47PM -0700, Russ Allbery wrote:
>>MAILTO was the main thing that I remember missing in terms of pure
>>functionality.
> 
> This is not a complete substitute for all uses of MAILTO, but I found
> the following useful so I share it in case you weren't aware of it.
> 
> Define a service specifically designed for sending status emails:
> 
> status-email-user@.service:
>> [Service]
>> Type=oneshot
>> ExecStart=-/usr/local/bin/systemd-email %i 
>> User=nobody
>> Group=systemd-journal

`nobody` is not a particularly good user to use for this. Should you have 
any non-mappable uids (like user namespaces or some nfs configurations), 
they will appear owned by `nobody`. You should probably use instead:

DynamicUser=yes
SupplementaryGroups=systemd-journal


-- 
Saludos

Bug#911335: ITP: cpdb-libs -- Common Print Dialog Backends - Interface Library for Backends

[Till Kamppeter]

Package: wnpp
Severity: wishlist
Owner: Till Kamppeter 

* Package name: cpdb-libs
  Version : 1.1.2
  Upstream Author : Nilanjana Lodh 
* URL : https://github.com/OpenPrinting/cpdb-libs
* License : MIT
  Programming Lang: C
  Description : Common Print Dialog Backends - Interface Library for 
Backends

This is already packaged for Ubuntu. This is the long description of
the Ubuntu package:

 The Common Print Dialog Backends project provides a D-Bus interface
 so that the print dialogs of GUI applications and the communication
 with the print technologies (CUPS/IPP, Google Cloud Print, Save to
 File, ...)  are put into separate executables to be separately
 exchangeable.
 .
 The print dialogs of the different GUI toolkits and applications
 (GTK, Qt, LibreOffice, ...) are the frontends and to communicate with
 the different print technologies they use common backends. This way
 one simply adds new backends for new print technologies and updates
 the backends for changes in the print technologies, and immediately
 all applications are up-to-date, without need of modifying the code
 of the GUI toolkits or applications.
 .
 This package contains the library which provides the functions needed
 by both the frontends and the backends.

The idea is to decouple the print dialog's GUI code (GTK, Qt,
LibreOffice, ... The frontends) from the code which communicates with
actual print technologies (CUPS, IPP, Google Cloud Print, Save to
File, ... The backends) to make them independently
interchangable. This way one can do things like

- Add a new print technology and it is immediately available for all
  GUI apps. Especially an online print service provider could simply
  put its backend into the Snap Store and asks his Linux users to
  install it.

- A change in a print technology, for example new functionality in
  CUPS, can be covered by simply updating the CUPS backend. No need to
  change all GUI libraries.

- User logs in for Google Cloud Print once and not separately for each
  GUI platform to get his cloud printers into all the apps.

- In case of a security bug in the communication code with one print
  technology only the backend needs to get fixed, not several GUI
  libs.

This package contains the general libraries which especially provide a
session D-Bus interface between the print dialogs (frontends) and the
print technology backends.

For this to work at least one print technology backend package is
needed. These packages are suggested in separate bug reports.

Of the GUIs LibreOffice already supports this system and only needs to
get rebuilt with this library. Patches for GTK and a modified Qt print
dialog are in the works.

All packages are already available as Ubuntu packages in Ubuntu's
Universe part. The maintenance in Debian should be done in the Debian
Printing Team.

I am not a Debian Developer but OdyX (Didier Raboud, o...@debian.org)
is willing to upload these packages.

Bug#911340: ITP: cpdb-backend-cups -- Common Print Dialog Backends - CUPS/IPP Backend

[Till Kamppeter]

Package: wnpp
Severity: wishlist
Owner: Till Kamppeter 

* Package name: cpdb-backend-cups
  Version : 1.1.0
  Upstream Author : Nilanjana Lodh 
* URL : https://github.com/OpenPrinting/cpdb-backend-cups
* License : MIT
  Programming Lang: C
  Description : Common Print Dialog Backends - CUPS/IPP Backend

This package needs cpdb-libs, ITP here:

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

This is already packaged for Ubuntu. This is the long description of
the Ubuntu package:

 This is the CUPS/IPP backend for print dialogs using the Common Print
 Dialog Backends concept of OpenPrinting. It makes the dialog list CUPS
 print queues and driverless-capable IPP printers and allows printing
 on these using the dialog.

The idea is to decouple the print dialog's GUI code (GTK, Qt,
LibreOffice, ... The frontends) from the code which communicates with
actual print technologies (CUPS, IPP, Google Cloud Print, Save to
File, ... The backends) to make them independently
interchangable. This way one can do things like

- Add a new print technology and it is immediately available for all
  GUI apps. Especially an online print service provider could simply
  put its backend into the Snap Store and asks his Linux users to
  install it.

- A change in a print technology, for example new functionality in
  CUPS, can be covered by simply updating the CUPS backend. No need to
  change all GUI libraries.

- User logs in for Google Cloud Print once and not separately for each
  GUI platform to get his cloud printers into all the apps.

- In case of a security bug in the communication code with one print
  technology only the backend needs to get fixed, not several GUI
  libs.

This package contains the backend for access local and remote CUPS
print queues and IPP network printers. It supplies information about
the printers, their capabilities, and user-settable options and it
passes print jobs on to printers. The print dialogs (using cpdb-libs)
connect to this backend via D-Bus. To do so, it is enough to have this
backend package installed.

For this to work at least one application with a print dialog using
cpdb-libs must be installed.

Of the GUIs LibreOffice already supports this system and only needs to
get rebuilt with this library. Patches for GTK and a modified Qt print
dialog are in the works.

All packages are already available as Ubuntu packages in Ubuntu's
Universe part. The maintenance in Debian should be done in the Debian
Printing Team.

I am not a Debian Developer but OdyX (Didier Raboud, o...@debian.org)
is willing to upload these packages.

Bug#911342: ITP: cpdb-backend-gcp -- Common Print Dialog Backends - Google Cloud Print Backend

[Till Kamppeter]

Package: wnpp
Severity: wishlist
Owner: Till Kamppeter 

* Package name: cpdb-backend-gcp
  Version : 1.1.0
  Upstream Author : Abhijeet Dubey 
* URL : https://github.com/OpenPrinting/cpdb-backend-gcp
* License : MIT
  Programming Lang: C
  Description : Common Print Dialog Backends - Google Cloud Print Backend

This package needs cpdb-libs, ITP here:

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

This is already packaged for Ubuntu. This is the long description of
the Ubuntu package:

 This is the Google Cloud Print backend for print dialogs using the
 Common Print Dialog Backends concept of OpenPrinting. It makes the
 dialog list the Google Cloud Print destinations set by the current
 user plus the option to drop the job as PDF on the Google Drive and
 allows printing on these using the dialog.
 .
 For a user to be able to use this facility he must set up his Google
 account in the "Online Accounts" section of GNOME Control Center.

The idea is to decouple the print dialog's GUI code (GTK, Qt,
LibreOffice, ... The frontends) from the code which communicates with
actual print technologies (CUPS, IPP, Google Cloud Print, Save to
File, ... The backends) to make them independently
interchangable. This way one can do things like

- Add a new print technology and it is immediately available for all
  GUI apps. Especially an online print service provider could simply
  put its backend into the Snap Store and asks his Linux users to
  install it.

- A change in a print technology, for example new functionality in
  CUPS, can be covered by simply updating the CUPS backend. No need to
  change all GUI libraries.

- User logs in for Google Cloud Print once and not separately for each
  GUI platform to get his cloud printers into all the apps.

- In case of a security bug in the communication code with one print
  technology only the backend needs to get fixed, not several GUI
  libs.

This package contains the backend for access the printers and the
Google Drive (to save as PDF) of the Google account of the current
user. It supplies information about the Google-registered printers,
their capabilities, and user-settable options and it passes print jobs
on to Google. The print dialogs (using cpdb-libs) connect to this
backend via D-Bus. To do so, it is enough to have this backend package
installed and each user who wants to use it, logged into his Google
account via Online Accounts.

For this to work at least one application with a print dialog using
cpdb-libs must be installed.

Of the GUIs LibreOffice already supports this system and only needs to
get rebuilt with this library. Patches for GTK and a modified Qt print
dialog are in the works.

All packages are already available as Ubuntu packages in Ubuntu's
Universe part. The maintenance in Debian should be done in the Debian
Printing Team.

I am not a Debian Developer but OdyX (Didier Raboud, o...@debian.org)
is willing to upload these packages.

Re: Debian Buster release to partially drop non-systemd support

[Bernd Zeimetz]

On 10/13/18 12:58 PM, Holger Levsen wrote:
> On Sat, Oct 13, 2018 at 06:01:43AM +0100, Ben Hutchings wrote:
>>> Has policy changed regarding support for multiple inits, or is it just that
>>> no one is maintaining the shim and sysvinit-core?
>>
>> The latter.  systemd-shim has been orphaned for over 2 years, and has
>> RC bugs.   sysvinit currently has two maintainers, but they've only
>> ever made one upload (over a year ago).
> 
> It seems that these facts are either largely ignored or unknown and I
> wonder if some noise should be made so that interested people can pick
> up the work now and not only complain later.


I don't think that is only the smaller issue we are facing here. The
bigger "problems" for those who do not like systemd will be:

- the typical package maintainer won't test initscripts
- more and more upstreams are shipping systemd services only and skip
init script creation.

For my packages I can state that I do not have a single machine which is
not using systemd - and to be honest - I won't waste my time in
writing/debugging initscripts. If there is one, I'll review it if it
looks sane and then maybe ship it. And I'm saying "maybe" here, as for
new packages, I will NOT shit it as active init script because I will
only put stuff in my packages I have tested well enough.

After using a lot of systemd now I will never go back to init scripts.
Systemd comes with a steep learning curve, but one you've stated using
its features you'll never go back.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

Bug#911345: ITP: cpdb-backend-file -- Common Print Dialog Backends - Print-to-File Backend

[Till Kamppeter]

Package: wnpp
Severity: wishlist
Owner: Till Kamppeter 

* Package name: cpdb-backend-file
  Version : 1.0.1
  Upstream Author : Ayush Bansal 
* URL : https://github.com/OpenPrinting/cpdb-backend-file
* License : MIT
  Programming Lang: C
  Description : Common Print Dialog Backends - Print-to-File Backend

This package needs cpdb-libs, ITP here:

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

This is already packaged for Ubuntu. This is the long description of
the Ubuntu package:

 This is the Print-to-File backend for print dialogs using the Common Print
 Dialog Backends concept of OpenPrinting. It makes the dialog list one
 single print queue and if you print to it, the data is put into a PDF file
 and not sent to a printer.

The idea is to decouple the print dialog's GUI code (GTK, Qt,
LibreOffice, ... The frontends) from the code which communicates with
actual print technologies (CUPS, IPP, Google Cloud Print, Save to
File, ... The backends) to make them independently
interchangable. This way one can do things like

- Add a new print technology and it is immediately available for all
  GUI apps. Especially an online print service provider could simply
  put its backend into the Snap Store and asks his Linux users to
  install it.

- A change in a print technology, for example new functionality in
  CUPS, can be covered by simply updating the CUPS backend. No need to
  change all GUI libraries.

- User logs in for Google Cloud Print once and not separately for each
  GUI platform to get his cloud printers into all the apps.

- In case of a security bug in the communication code with one print
  technology only the backend needs to get fixed, not several GUI
  libs.

This package contains a backend which creates a printer entry in all
print dialogs (using cpdb-libs) which drops jobs sent to it simply in
PDF files. The backend instructs the print dialogs to show a printer
entry and to pop-up a "Save as ..." dialog when hitting "Print"
(and/or selecting the "Destination File Name" option).

For this to work at least one application with a print dialog using
cpdb-libs must be installed.

Of the GUIs LibreOffice already supports this system and only needs to
get rebuilt with this library. Patches for GTK and a modified Qt print
dialog are in the works.

All packages are already available as Ubuntu packages in Ubuntu's
Universe part. The maintenance in Debian should be done in the Debian
Printing Team.

I am not a Debian Developer but OdyX (Didier Raboud, o...@debian.org)
is willing to upload these packages.

Re: "debian.pool.ntp.org" for Debian derivatives?

[Yao Wei (魏銘廷)]

We are probably accepting their TOS without reading them first:

https://www.ntppool.org/tos.html

Yao Wei

(This email is sent from a phone; sorry for HTML email if it happens.)

> On Oct 18, 2018, at 20:51, Ansgar Burchardt  wrote:
> 
>> On Thu, 2018-10-18 at 13:57 +0200, Philipp Hahn wrote:
>> So my question is more like "is it okay to not change Debians default
>> NTP server selection", so the initial setup and those lazy enough to
>> not change the default get a sane time?
> 
> I don't think Debian can answer that question and suggest to ask the
> pool operators.  This seems to be the correct list:
>  https://lists.ntp.org/listinfo/pool
> 
> A related question is the use of API keys that are included in some
> packages (e.g. chromium).  These are also vendor-specific, but cannot
> be really secret (as they are included in the binaries and could be
> extracted even for proprietary software).
> 
> Ansgar
> 

Work-needing packages report for Oct 19, 2018

[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: 1323 (new: 6)
Total number of packages offered up for adoption: 165 (new: 2)
Total number of packages requested help for: 57 (new: 0)

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



The following packages have been orphaned:

   cellwriter (#93), orphaned 3 days ago
 Description: grid-entry handwriting input panel
 Installations reported by Popcon: 118
 Bug Report URL: http://bugs.debian.org/93

   gniall (#97), orphaned 3 days ago
 Description: program that tries to learn a human language
 Installations reported by Popcon: 29
 Bug Report URL: http://bugs.debian.org/97

   libapache2-mod-auth-openid (#911032), orphaned 4 days ago
 Description: OpenID authentication module for Apache2
 Installations reported by Popcon: 43
 Bug Report URL: http://bugs.debian.org/911032

   libopkele (#911033), orphaned 4 days ago
 Description: OpenID support library in C++
 Reverse Depends: libapache2-mod-auth-openid libopkele-dev
 Installations reported by Popcon: 24
 Bug Report URL: http://bugs.debian.org/911033

   libpcre++ (#911034), orphaned 3 days ago
 Description: C++ wrapper class for pcre
 Reverse Depends: libaff4-0 libaff4-utils libpcre++-dev
 Installations reported by Popcon: 431
 Bug Report URL: http://bugs.debian.org/911034

   ngetty (#911035), orphaned 3 days ago
 Description: getty replacement - one single daemon for all consoles
 Installations reported by Popcon: 29
 Bug Report URL: http://bugs.debian.org/911035

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



The following packages have been given up for adoption:

   apache2 (#910917), offered 5 days ago
 Description: Apache HTTP Server
 Reverse Depends: 389-admin apache2 apache2-dbg apache2-ssl-dev
   apache2-suexec-custom apache2-suexec-pristine backuppc
   courier-webadmin cvsweb debbugs-web (151 more omitted)
 Installations reported by Popcon: 96200
 Bug Report URL: http://bugs.debian.org/910917

   fpart (#911246), offered yesterday
 Description: sort file trees and pack them into bags
 Installations reported by Popcon: 32
 Bug Report URL: http://bugs.debian.org/911246

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



For the following packages help is requested:

   autopkgtest (#846328), requested 687 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: autodeb-worker debci-worker
 Installations reported by Popcon: 1131
 Bug Report URL: http://bugs.debian.org/846328

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

   broadcom-sta (#886599), requested 283 days ago (non-free)
 Description: Broadcom STA Wireless driver (non-free)
 Installations reported by Popcon: 1978
 Bug Report URL: http://bugs.debian.org/886599

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

   cyrus-sasl2 (#799864), requested 1121 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (120 more omitted)
 Installations reported by Popcon: 199892
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 825 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 62443
 Bug Report URL: http://bugs.debian.org/831388

   developers-reference (#759995), requested 1510 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 11852
 Bug Report URL: http://bugs.debian.org/759995

   devscripts (#800413), requested 1115 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   autodeb-worker brz-debian bzr-builddeb customdeb debci
   debian-builde

Re: Debian Buster release to partially drop non-systemd support

[Narcis Garcia]

__
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 18/10/18 a les 22:07, Bernd Zeimetz ha escrit:
> For my packages I can state that I do not have a single machine which is
> not using systemd - and to be honest - I won't waste my time in
> writing/debugging initscripts.

Most of people want to use a GNU operating system.
You particularly seem to only need a Systemd operating system.