Re: Is missing SysV-init support a bug?

[Cameron Norman]

On Tue, Oct 18, 2016 at 11:23 AM, Lars Wirzenius  wrote:
> On Tue, Oct 18, 2016 at 07:34:28PM +0200, Xen wrote:
>> If that is the case then they have enbedded hostility into their name simply
>> becaus eit offends normal grammar roles.
>
> I don't that's it at all.
>
> The reason many people react to the SystemD spelling is becuase, for
> some years now, trolls use that spelling when harrassing others about
> systemd.
>
> Calling it SystemD indicates to many people that you're the kind of
> person show turns up from nowhere, and starts spreading fear,
> uncertainty, and doubt about systemd, or presenting conspiracy
> theories about it, or making ad hominem attacks on its authors. People
> with bad experiences from previous systemd discussions will assume
> you're that kind of troll, regardless of the value of any of your
> claims or statements may have. Or at least I do.

Those reading so much into such a small and understandable
capitalization mistake (SystemV -> SystemD) should learn to take
themselves less seriously and view things from different perspectives.

Re: Dropping upstart jobs (or not)

[Cameron Norman]

On Fri, Jun 3, 2016 at 4:31 PM, Michael Biebl <bi...@debian.org> wrote:
> Hi,
>
> I just became aware recently that upstart has been removed from the
> archive (unstable/testing) [1].
>
> Now I'm wondering what to do about the upstart job files that were added
> to various packages. Do we
> - continue to ship them, assuming we have users that keep upstart
> installed when upgrading to stretch.
> - drop them from the package but don't remove the obsolete conffiles.
> This would mean we keep the upstart jobs on upgrades. (probably makes
> our debian qa people unhappy though, who run adequate)

The latter seems like an undesirable. Packages should be orphaning
conffiles as little as possible.

--
Cameron Norman

Re: Tighter systemd integration for stretch?

[Cameron Norman]

 On Aug 8, 2015, at 10:16 AM, Frank Bauer frank.c.ba...@gmail.com wrote:
 
 Hi,
 
 I have upgraded my main machine from wheezy to jessie (like I do since
 woody) this morning without much problems - kudos all!
 
 I spent the day exploring systemd and its ecosystem and have noticed
 Debian is in kind of a transitional phase.
 
 Zb. acpid is installed by default, but the events are handled by
 systemd-logind anyway. There is no issue for me to remove acpid and
 acpi-support-base (which I did), but it would be cool to have just one
 thing for the given usecase installed by default.
 
 Digging further I have configured the systemd-networkd (my setup is
 pretty simple configuration using bridge) and was able to get rid of
 isc-dhcp-client, isc-dhcp-common, ntpdate and in the end ifupdown.
 
 So my question is, whether we can expect more systemd integration out
 of the box (hey, it is installed anyway) and more streamlining of the
 surrounding packages?
 

systemd-networkd is still WIP and some basic functions (temporarily disabling 
an interface for reconfiguration) are not available.

 Example: now the net.agent of udev complains in the syslog several
 times for various devices:
 
 ERROR: /sbin/ifup not found. You need to install the ifupdown package.
 net.agent add event for br0 not handled.

You need to move the udev integration of ifup down to the ifupdown package 
instead of having it in udev. There should be more about this in the 
debian-devel archives under the ifupdown orphanage thread.

Cheers,
--
Cameron Norman


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/bf4c6fdd-8c4a-4b2d-ba7c-d65d88fc4...@gmail.com

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces

[Cameron Norman]

On Wed, May 27, 2015 at 4:18 AM, Russell Stuart
russell-deb...@stuart.id.au wrote:
 On Wed, 2015-05-27 at 12:33 +0200, Marco d'Itri wrote:
 (I am shocked, shocked that there is no flood of people here rushing to
 save ifupdown... :-) )

 Until systemd-networkd can run scripts on events no defence is required.

Martin Pitt is actually working on that in Ubuntu. See the following blueprint:

https://blueprints.launchpad.net/ubuntu/+spec/core-1505-networkd-vs-ifupdown

--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRJM2Q5SO-zm7duUriuWFZYAnw7g9_YKd2KJAWb=5zv...@mail.gmail.com

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces

[Cameron Norman]

On Wed, May 27, 2015 at 5:29 PM, Josh Triplett j...@joshtriplett.org wrote:
 On Wed, May 27, 2015 at 05:06:38PM -0700, Cameron Norman wrote:
 On Wed, May 27, 2015 at 4:36 PM, Josh Triplett j...@joshtriplett.org wrote:
  Simon McVittie wrote:
  One thing that an adopter could very usefully do with ifupdown would be
  to coordinate with the systemd maintainers on moving net.agent
  (Debian-specific udev glue to invoke ifupdown) from udev into ifupdown,
  so that it does not need to be present at all on systems that rely on a
  non-ifupdown tool like NM. That would also mean that the ifupdown
  maintainer would be free to alter the precise details of how net.agent
  and ifupdown interact, since they would now control both ends of the 
  API.
 
  I'd *love* to see that happen.  I've seen discussions about that, and
  they always seemed to stall out.

 Then why not submit patches to ifupdown? It is not like it offers any
 benefit to ifupdown users, so it is not really something the ifupdown
 maintainer would be inclined to go out of his/her way to accomplish.
 You can QA upload it really easily now too.

 Because I have no interest in developing ifupdown; I'd just like to see
 net.agent no longer run on systems *without* ifupdown.

Well then you just explained why the discussions seem to stall out:
people who will benefit (i.e. not ifupdown maintainers/users) have no
interest in touching ifupdown at all (at least it seems so).

--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfrkjwp4i5mfhjjk_cwhzvlhekhz-pteqr9ejgkpv5ur...@mail.gmail.com

Re: Bug#786902: O: ifupdown -- high level tools to configure network interfaces

[Cameron Norman]

On Wed, May 27, 2015 at 4:36 PM, Josh Triplett j...@joshtriplett.org wrote:
 Simon McVittie wrote:
 One thing that an adopter could very usefully do with ifupdown would be
 to coordinate with the systemd maintainers on moving net.agent
 (Debian-specific udev glue to invoke ifupdown) from udev into ifupdown,
 so that it does not need to be present at all on systems that rely on a
 non-ifupdown tool like NM. That would also mean that the ifupdown
 maintainer would be free to alter the precise details of how net.agent
 and ifupdown interact, since they would now control both ends of the API.

 I'd *love* to see that happen.  I've seen discussions about that, and
 they always seemed to stall out.

Then why not submit patches to ifupdown? It is not like it offers any
benefit to ifupdown users, so it is not really something the ifupdown
maintainer would be inclined to go out of his/her way to accomplish.
You can QA upload it really easily now too.

--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfrk8b8py9hns81htwldhj0snrm_pa2p6jgirqj0cyh5...@mail.gmail.com

Re: Proposal: enable stateless persistant network interface names

[Cameron Norman]

On Sat, May 9, 2015 at 2:36 PM, Josh Triplett j...@joshtriplett.org wrote:
 Marvin Renich wrote:
 * Martin Pitt mp...@debian.org [150509 05:27]:
  TBH, hotpluggable USB network adapters which change all the time sound
  like a corner case in a server world where you have hand-written
  config files referring to interface names. They are of course common
  on the client side, but there stable interface names don't matter at
  all. But see below.

 I disagree that stable interface names do not matter for USB adaptors
 for consumer laptops.  I have owned two laptops where the on-board WiFi
 adaptor was too new to have reliable Linux drivers until 6-12 months
 after I purchased them.  While waiting for the Linux drivers, I used a
 USB WiFi dongle that has good kernel support.  I have plugged the
 adaptor into different USB ports based on where my laptop was situated
 wrt varied surroundings.  I suspect (with no real data to back it up)
 that the biggest use of USB WiFi dongles on consumer machines is when
 the on-board WiFi doesn't work for some reason (too new or broken).  In
 this case, it is often the main internet connection and a stable name is
 important.

 Why?  What does a stable name matter in the case you mentioned?

 Were you actually using ifupdown to manage the varied set of wireless
 networks?  Because if not, then the name shouldn't matter.

Does networkd handle this situation well?

--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfr+xo1f7iirx67r51xwsjwivahdoopbrqewqq2zwhhs...@mail.gmail.com

Re: State of Roundcube packaging in Debian?

[Cameron Norman]

On Sun, Mar 15, 2015 at 3:32 PM, Christian Kastner deb...@kvr.at wrote:
 On 2015-03-15 21:38, John Goerzen wrote:
 On 03/14/2015 07:36 AM, Vincent Bernat wrote:
 The main difficulty is to handle the 0.9.5 to 1.x upgrade where the
 configuration files change.
 I assume you mean the config files change in some dramatic way; that is,
 some way that means the existing files won't work anymore?

 If that is the case, why does this have to be a big deal?  Couldn't you
 just warn people that the upgrade will break their config, point them to
 the docs, and call it good?  After all, if that is all upstream
 provides, isn't it better than nothing?

 Another alternative would be to not implement the upgrade path at all,
 and provide a separate roundcube-1.1 package instead, for those willing
 to do the migration manually (which I'd argue is a low price to pay).

I do not think it wise to package every point release since roundcube
does not intend to break the configs every point release as they did
in version 1. However packaging a roundcube-1 is useful IMO (and it
would be version 1.0 then 1.1 then 1.2 etc.).

Cheers,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfrjqexvstscv3a+kdsr0auyq0hlcnqaakevhekcrtc7...@mail.gmail.com

Re: conflicts between Debian's and upstream's Debian package

[Cameron Norman]

El vie, 20 de feb 2015 a las 12:04 , Harald Dunkel ha...@afaics.de 
escribió:

Hi folks,

I would like to use upstream's Debian/Ubuntu packages for a
certain tool 'foo'. Its closer to what I need, and I don't
have migrate between both versions before asking the mailing
list for help or for reporting/fixing problems.

Problem: The Debian maintainer messed up the version numbers
and had to introduce a 1: for his foo package. Now upstream's
package always appears to be out of date, forcing me to override
apt-get.


Not the cleanest option, but can upstream just introduce the 1: as well?

Cheers,
--
Cameron Norman

Re: how to remove libsystemd0 from a live-running debian desktop system

[Cameron Norman]

On Mon, Feb 16, 2015 at 8:14 AM, Matthias Klumpp matth...@tenstral.net wrote:
 2015-02-16 16:26 GMT+01:00 Alastair McKinstry alastair.mckins...@sceal.ie:
 [...]
 An an example, i've been a long-term linux developer, DD; i've developed
 and promoted Linux not just on the desktop but both in embedded systems
 and in HPC systems. In all these I've been comfortable that I've been
 able to adapt Linux, reconfigure, do what was needed to get it going on
 any size of device, and get my changes either accepted upstream,
 maintain them locally in my organisation or both. With systemd I don't
 think I could do that, and thats very disempowering.

 Why do you think you can't do that anymore? Systemd is used on
 embedded devices, reaching from the Jolla smartphone to things like
 the Vocore or Raspberry Pi.

Kind of off topic, but are the RPi and Jolla embedded systems? The
weakest Raspberry Pi has almost ten times as much RAM as the vocore.
And both have discrete GPUs. I don't know, it seems like a stretch to
call those two embedded.

--
Cameron Noramn


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRK4WbE1m-LT=0478+rd4_rwaa3gnpqh6q59uvkdaf2...@mail.gmail.com

Re: init script cannot stop pid process

[Cameron Norman]

On Wed, Feb 11, 2015 at 1:25 PM, Mateusz Łukasik mat...@linuxmint.pl wrote:
 Hello,

 I make darkhttpd package and have a small issue.

 I prepare init script:
 https://github.com/mati75/darkhttpd/blob/master/debian/init and for run
 script with start parameter is working fine:

 www-data  4615  4615  0.01  0.1  12456  1548 ?Ss   22:13 0:00
 /usr/bin/darkhttpd /var/www --daemon --uid www-data --gid www-data --log
 /var/log/darkhttpd/access.log

 But with stop and status is some issue:

 status all time return:

 [FAIL] darkhttpd is not running ... failed!

 stop:

 [ ok ] Stopping web server: darkhttpd.

 and here the point is darkhttpd still works.

This is almost assuredly because darkhttpd is not writing its PID
file. If you fix that, you should be fine.


 Next fact is that I don't see anything pid file in /run which should be
 making by init script and I don't know where I make mistake.

 darkhttpd can provides pidfile by itself, but where I see that problem:

 error: can't create pidfile /var/run/darkhttpd.pid: Permission denied

Permission error tells me that the daemon is dropping root before
writing the PID file, which is not exactly wrong, but causes problems
in this case. Either in the init script, or in the daemon prior to
dropping priveleges, make sure to create the PID file with the correct
priveleges so it can later be written to when darkhttpd is not root.

Simply adding the following in the start action of the init file,
prior to starting the daemon, should do the trick:

touch $PIDFILE
chown www-data:www-data $PIDFILE

Good luck,
--
Cameron Norman


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRJyeYPLKMiCsSccE=vbjg3zrv3bj8uefvymc2xoaoe...@mail.gmail.com

Re: motd handling in jessie

[Cameron Norman]

On Sun, Jan 25, 2015 at 11:45 AM, Russ Allbery r...@debian.org wrote:
 Michael Biebl bi...@debian.org writes:

 Why run this on every boot?

 The main thing that you want to be up-to-date are things like the running
 kernel version, and you have no other good way of detecting that, I don't
 think.

 It's not like this stuff takes very long to run, and it will happily
 parallelize.

 If the update-motd.d interface is supposed to also show information like
 list of outdated packages, etc, wouldn't some other mechanism to trigger
 an update, be better.

 What trigger do you have in mind that would detect that you just rebooted
 the system into that new kernel that you installed six weeks ago but never
 used?

 I suggested a cron job, but maybe there are better ways, like apt hooks,
 dpkg triggers, etc.

 A cron job is strictly worse than running it at boot in every metric that
 I can think of.

Well we can do both. If these update-motd scripts actually differ in
their result day by day, and the server is only rebooted maybe once a
week (if not less often), then running them once at boot is not
enough.

So to have them up to date in that respect, you need to either have a
cron job or invoke the update-motd scripts on every login. Invoking
them on every login could make it difficult to access bogged down
servers.

Regards,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfrjovostyztiz3acvbz_7io8znhrnazaq-yimc37wyv...@mail.gmail.com

Accepted pygopherd 2.0.18.3+nmu4 (source all) into unstable

[Cameron Norman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 08 Dec 2014 17:25:38 -0800
Source: pygopherd
Binary: pygopherd pygfarm
Architecture: source all
Version: 2.0.18.3+nmu4
Distribution: unstable
Urgency: medium
Maintainer: John Goerzen jgoer...@complete.org
Changed-By: Cameron Norman camerontnor...@gmail.com
Description:
 pygfarm- Collection of add-on modules for Pygopherd
 pygopherd  - Modular Multiprotocol Gopher/HTTP/WAP Server in Python
Closes: 771501
Changes:
 pygopherd (2.0.18.3+nmu4) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Copy gophermap from /usr/share, not /usr/share/doc (Closes: #771501)
Checksums-Sha1:
 3eb77bf4e0647356500ea27a69e07247969b72d3 1809 pygopherd_2.0.18.3+nmu4.dsc
 5dc940aea9e5a544bb717835312dea263d86cafd 275272 pygopherd_2.0.18.3+nmu4.tar.gz
 3d9aae600f5a5510372a732863c518e17b2324f3 218118 pygopherd_2.0.18.3+nmu4_all.deb
 b729854ce062c05abe6059e3ff2533b2f45c734c 7490 pygfarm_2.0.18.3+nmu4_all.deb
Checksums-Sha256:
 8334aab1a8de0a1fc7a2375fe45274c78b94bdb5a511c74229fb35eb72e7deda 1809 
pygopherd_2.0.18.3+nmu4.dsc
 c2f660a60723cc22820682970358af40a2fb6544d45d782792ef877355c9dff5 275272 
pygopherd_2.0.18.3+nmu4.tar.gz
 56033934c93d3b49bc3f0172e80b6e10ed65fc8e696a143038d03757bab6e254 218118 
pygopherd_2.0.18.3+nmu4_all.deb
 37e4ecb3515b0cb4de5ab9772c28f562444d8cd2339211db54740dd1cc0d1157 7490 
pygfarm_2.0.18.3+nmu4_all.deb
Files:
 6d7a0e2c613ba3f55f181399a3816aff 1809 net optional pygopherd_2.0.18.3+nmu4.dsc
 b91409ca317ad18357e180abe8e038c7 275272 net optional 
pygopherd_2.0.18.3+nmu4.tar.gz
 659f4e4b0737b8eed9fd07d882aca2e6 218118 net optional 
pygopherd_2.0.18.3+nmu4_all.deb
 28a0b61e692a2bd9190a445610fbb479 7490 net optional 
pygfarm_2.0.18.3+nmu4_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJUhyNHXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGbHYQAK1VB7m0XAGzGeIDCemhx/SA
Q5OseFsNjM/qrJx554Yzy1rH+5/R7hWUB7+rw+7LfVWI9PMUgOMGd1WIU6xq4VbL
eXoL6P/jb2sgycm6vI/ITwDbgGtfKFY0MXBOSDw22PGDvpiIGyfmshs8VGSF5zgV
XRSDlhPc112HKXN1XIgfEHLxJKZ+TKkKs7AA2Pc9gvpcjvZxV7b+QL/+M5aq8nhJ
D2vnnCxE3j7jq48nmISKi6lzaen/ff/LZglJmlABa6ADvHZ4LHmk3pAd5nML5hrX
D9Q4Ov5WBWQhZwdmJThdJl+AGyuIBLmFpIpnRkqmdB7yNDcsXQ9Bkm/mRj72NZh2
1O3IoWXNxpFhmdTdRxtJoW+gxdrep4PfI7Up0Nt6umbVbm+liElnTbyly5+hF3Q4
0eunxRMgd/xtqRPyVB3CL9MR1a/Au8oCpUjsBmnujC6McCsx6F83/X7q9BY7ukdw
aS57paQqjcgZnGNHCOCyj1SWA8crKCTIVPi2GpcSy9W/MCPFKy1OAvm6SLeZLqui
Ml+AEnl38DMSsu1daa3ZZQOC5cAMSEWQEVLr3a0btOXmEnow11cHvo7byjIn/SDv
AjPF92F9OO4G/EOYCp/seI+NFxoSbnAs2hdw8GRSug3jzjMijVZOX/XEdet5ptrf
zFojOJxaLhFqTLCBOdms
=ZGjd
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1y0cas-0001fu...@franck.debian.org

Re: Technical committee acting in gross violation of the Debian constitution

[Cameron Norman]

On Fri, Nov 28, 2014 at 4:32 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Thu, Nov 27, 2014 at 10:02:06PM +0100, Martin Steigerwald wrote:
 And well, I also wonder why systemd --user functionality is in the *same*
 binary than the PID 1 stuff… but well… I brought this upstream to no avail.
 OK, since this is a different forum, let me go over the reasons once again.

 The code paths in systemd which differ between --system and --user are
 relatively small.

 [snip]

 The
 majority, like the unit dependency logic, starting of processes,
 notifications from services, opening of sockets, watching of paths,
 etc, etc, are all shared.  Actually systemd --user is probably closer
 to systemd --system running in a container than to systemd --system
 running on the host, because both run without full privileges and
 simply skip mounting of various things and other low-level setup.

 In this scenario it is natural to structure the code as a single binary
 that conditionalized parts of it logic as necessary.

+1


 At least the logind stuff appears to be separate:
 Yes, logind does not share many high-level code paths with the systemd
 binary, so it is natural to keep them separate.

 OTOH, systemd and systemd-logind use the same primitives like string
 handling, configuration file parsing (including the logic of drop-in
 directories and /etc-overrides-/run-overrides-/usr/lib), and a bunch
 of other utility functions, which are provided by the shared systemd
 libraries, so it is much easier to develop them in a single repository.

Do you really think logind and systemd are the only pieces of C
software that struggle with strings or config parsing? Those are
definitely a couple of things that could be split out into a separate
library so we all do not have to either (a) suffer through it,
tediously writing another solution or (b) throw our software in
systemd's git repo and use the same release cycle and license and all
the other implications of being in the same repo (including not having
commit access to your own software automatically).

The config aspects especially so. It would be very positive if
software knew they could just depend on a really simple library and
get config parsing for basically free, since then users would
eventually only have to know how to write one config format and
software would only have to know how to read (parse) that same one.

I do not know why I am discussing this here though, haha.

Cheers,
--
Cameron Norman


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/CALZWFRJu892a
xx8auf+epvnggs2bts10fg4xkuqfoeof...@mail.gmail.com

Re: init system policy

[Cameron Norman]

On Thu, Nov 20, 2014 at 8:28 AM, Russ Allbery r...@debian.org wrote:
 Jonas Smedegaard d...@jones.dk writes:

 Seems to me this is a similar limitation as for config.d structures - as
 an example apache2 is now far more modular than in the past but I no
 longer as sysadmin get notified what exactly has changed when I upgrade
 a system with customizations, as I did in the past thanks to the
 monolithic configfile being a conffile.

 There was some discussion about this a while back, and I vaguely remember
 that systemd comes with a tool that will tell you exactly what you're
 overriding.  I'm not sure if that work got all the way to producing a nice
 Debian-aware tool or not.

 Personally (and this is just a wishlist), I'd love to have functionality
 similar to apt-listchanges that would (optionally) show me a report of
 every change to any unit file that I've overridden on each upgrade.

But systemd is not the only package to provide a vendor config in /lib
(or /usr/share or /usr/lib) and allow it to be overridden by a file in
/etc. One example is mountall, which provides a base fstab in
/lib/init/ that is overridden by entries in /etc/fstab. networkd and
many other systemd components are similar in this as well. I think
debian conffiles need a generic mechanism that allows packages to
associate files in /etc with files in the vendor directories like /lib
so that the admin is notified when the vendor supplied configuration
is changed. Maybe it could look like this, in
`debian/package.conffiles` :

# traditional conffiles entries
/etc/package/main.conf
# new entries
# admin-supplied vendor-supplied
/etc/package/other.conf /usr/share/package/other.conf
/etc/systemd/system/package.service /lib/systemd/system/package.service
/etc/systemd/system/package.service.d/* /lib/systemd/system/package.service

Seeing as systemd upstream is pushing the stateless systems idea,
and there is definitely merit to it, I think this is the best way to
tackle the issue.

Best wishes,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfr+iosvcpxucmttt_1ck7c1jxrupgss_qbnacfwuplc...@mail.gmail.com

Re: Being part of a community and behaving

[Cameron Norman]

On Thu, Nov 13, 2014 at 2:02 AM, Bálint Réczey bal...@balintreczey.hu wrote:
 Dear Josselin,

 I have just noticed your blog post on planet.debian.org:
 https://np237.livejournal.com/34598.html

 I would like to ask you to resist the temptation of publishing similar posts.
 It makes fun of part of our community which you are well aware of and
 it also shows corpses which probably did not ring a bell in you.

 None of those show good taste and by having it aggregated on
 planet.debian.org it shows the whole project in bad light, too.

I disliked the post because I felt like it would create an annoying
and circular discussion, possibly on debian-devel.

Well look what happened... we went through about 50 sometimes long
messages, and maybe (maybe!) five were useful (thinking about the
syslog-ng bug found).

Can we please stop? Active Debian developers are considering just
leaving -devel because of discussions like these.

Thanks,
--
Cameron Norman


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFR+pec6=sPec4wmT0+JRTWdd5�wbkt16m4qeulm-0...@mail.gmail.com

Re: Being part of a community and behaving

[Cameron Norman]

On Thu, Nov 13, 2014 at 11:30 PM, Gergely Nagy
alger...@madhouse-project.org wrote:
 Cameron == Cameron Norman camerontnor...@gmail.com writes:

  OK, so the system has syslog-ng installed.  For what ever reason
  syslog-ng
  is not starting automatically, but starts manually by systemctl.
 
  syslog-ng version 3.5.6-2
  systemd version 215-5+b1
 
  Maybe some failure to sync status correctly?  syslog-ng does ship
  with a
  service file.  What does:
 
  systemctl status syslog-ng
 
  say?  Particularly the Loaded and Active fields should have some
  hint as
  to what's going on that's preventing the service from starting
  automatically.

 Cameron Apparently this is a known issue, and another person has 
 experienced
 Cameron it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426

 That and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769499 are
 closely related, and will be fixed in the next syslog-ng upload (likely
 early next week). I know how to fix both, but lacked the time to
 implement said fixes so far.

This is a great chance to use the 'newcomer' tag recently added as an
official tag. It is for relatively simple bugs that a fix is known
for, but the maintainer just does not have the time. Please do
consider it in the future!

Thanks,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFR+iWMJKEkSmo_=6ysf1-0r67tyzdc0sqw_bmxegdgn...@mail.gmail.com

Re: Being part of a community and behaving

[Cameron Norman]

El jue, 13 de nov 2014 a las 6:15 , Patrick Ouellette 
poue...@debian.org escribió:

On Thu, Nov 13, 2014 at 06:07:33PM -0800, Russ Allbery wrote:

 Patrick Ouellette poue...@debian.org writes:

  I'm saying those things that logged to syslog now log to the 
journal, so
  cat /var/log/syslog doesn't work because the output that used to 
go

  there is redirected to the binary format journal file.

 If that's happening on your system, that's a bug.  It's definitely 
not
 happening on mine.  Could you provide more information, such as an 
example
 that's not in /var/log/syslog where you expect it but ended up in 
the

 journal, and what program is involved?



Since /var/log/syslog is empty, clearly there was an issue when my 
system

upgraded. I'll have to look into this to see what is going on.

(Kind of illustrates my point about another point of failure... No, I 
did

not plan or do this intentionally)


Apparently newer versions of systemd-journald do not forward to syslog 
by default; that has to be explicitly configured (although rsyslog 
already reads the journal and collects the logs). Not sure if 215 is 
affected by that behavior, will have to look it up later. What syslog 
implementation are you running?


Thanks,
--
Cameron Norman

Re: Being part of a community and behaving

[Cameron Norman]

El jue, 13 de nov 2014 a las 6:53 , Russ Allbery r...@debian.org 
escribió:

Patrick Ouellette poue...@debian.org writes:

 On Thu, Nov 13, 2014 at 06:19:32PM -0800, Russ Allbery wrote:


 Ow.  No, that's definitely a bug.  I'd love to understand what 
happened
 there, as that sounds like a pretty serious one.  That is not 
expected

 behavior.


 OK, so the system has syslog-ng installed.  For what ever reason 
syslog-ng

 is not starting automatically, but starts manually by systemctl.



 syslog-ng version 3.5.6-2
 systemd version 215-5+b1


Maybe some failure to sync status correctly?  syslog-ng does ship 
with a

service file.  What does:

systemctl status syslog-ng

say?  Particularly the Loaded and Active fields should have some hint 
as

to what's going on that's preventing the service from starting
automatically.


Apparently this is a known issue, and another person has experienced 
it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426


Cheers,
--
Cameron Norman

Re: Being part of a community and behaving

[Cameron Norman]

El jue, 13 de nov 2014 a las 6:57 , Cameron Norman 
camerontnor...@gmail.com escribió:
El jue, 13 de nov 2014 a las 6:53 , Russ Allbery r...@debian.org 
escribió:

Patrick Ouellette poue...@debian.org writes:

 On Thu, Nov 13, 2014 at 06:19:32PM -0800, Russ Allbery wrote:


 Ow.  No, that's definitely a bug.  I'd love to understand what 
happened
 there, as that sounds like a pretty serious one.  That is not 
expected

 behavior.


 OK, so the system has syslog-ng installed.  For what ever reason 
syslog-ng

 is not starting automatically, but starts manually by systemctl.



 syslog-ng version 3.5.6-2
 systemd version 215-5+b1


Maybe some failure to sync status correctly?  syslog-ng does ship 
with a

service file.  What does:

systemctl status syslog-ng

say?  Particularly the Loaded and Active fields should have some 
hint as

to what's going on that's preventing the service from starting
automatically.


Apparently this is a known issue, and another person has experienced 
it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760426


Arg. I read to quickly; this appears to be something quite different. 
Nevermind.


--
Cameron Norman

Re: Bug#741930: reportbug: add current init system information

[Cameron Norman]

On Tue, Nov 4, 2014 at 5:35 AM, Sandro Tosi mo...@debian.org wrote:
 Hi Michael et al,

 On Mon, Nov 3, 2014 at 1:19 PM, Michael Biebl bi...@debian.org wrote:
 provided above one requires to check a dir existence and the checking
 a command and then execute it to parse its output. it seems a bit
 fragile, and maybe only upstart check really the running processes

 The systemd system runtime directory is only created when systemd is the
 active PID 1. Could you elaborate why you think this approach is
 fragile? If those two tests (for systemd and upstart) would be brittle,
 we'd have a problem, since they are used all over the place.

 well, mkdir can create it too :) but ok, those checks are so embedded
 that i can ignore if the reportbug check if fooled to thing theres
 another systems (there will be bigger problems indeed) so I will just
 mimik their logic in the code; I changed the sample scripts, attached,
 and it would be nice if you all could give it another round (thanks to
 everyone who already did!) in particular to those having an upstart
 init system.

A few notes I have:

1. With Jessie and on, with sysvinit /sbin/init //will// be a link,
not the true init file. This would lead to unknowns when the init was
actually sysv.
2. With Upstart, /sbin/init is not a link, so that third test would
give a false positive for sysvinit when it was actually Upstart
(assuming the Upstart check gave a false negative).
3. Maybe you should embed the check for Upstart, so that you do not
have to source all of the init functions, and if that file is ever not
available you still get the correct check.
4. There is a tiny typo in the Upstart check. It needs an extra right
parenthese at the end of the message.

Cheers,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfr+qngxdby3x+qjwmupeg-9j-jmf5aaou7mdgs-toup...@mail.gmail.com

Re: Re: piece of mind

[Cameron Norman]

On Fri, Oct 24, 2014 at 8:54 AM, Josselin Mouette j...@debian.org wrote:
 Jonathan de Boyne Pollard wrote:
 You know, or at least should know, as well as I that one can
 centralize the code to do all of those things, and abstract them out 
 of
 daemons into a service manager, without that service manager being
 process #1.

 I don’t know whether you are aware of how a UNIX system works, but you
 might not have heard of how orphan processes are managed.

 From waitpid(2):
If a parent process terminates, then its zombie children (if any) are
adopted by init(8), which automatically performs a wait to  remove  the
zombies.

 Said otherwise, it is not possible to write a reliable service manager
 without integrating it to what happens in process #1.

You certainly can if you use PRCTL_SET_CHILD_REAPER (only on Linux
3.4+ I think), or do not support forking daemons.

Both options are undesirable in different ways, but systemd already
requires the prctl so any alternative would not be any worse than
systemd in that respect.

--
Cameron Norman


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRJUX+Pq34Y-R=roYUigfPrZkT8g+m7OeCxoHeLCXWee=a...@mail.gmail.com

Re: piece of mind

[Cameron Norman]

El mar, 21 de oct 2014 a las 7:03 , Josselin Mouette j...@debian.org 
escribió:

The Wanderer wande...@fastmail.fm wrote:
This is the problem. The init system should not be providing 
features
which other software might, post-boot and pre-shutdown, want 
to make use
of. (AFAIK sysvinit never did, and most - possibly all? - of 
the other
init-system candidates don't either.) Such features should be 
provided
separately, independent of what may happen to be running as 
PID 1.


These features cannot exist separately. Quoting the systemd position
statement:

[…] while it is true that a handful of trivial interfaces are not 
really

related to systemd (and could be split out if needed), most of these
features cannot be implemented without close integration to PID 1. It 
is

not possible to split the system cgroups arbitrator from the process
which starts services and sessions in cgroups. It is not possible to
ensure the relation of a log to a service if you do not have awareness
of how the service was launched. Et caetera.


Upstart can launch processes in cgroups using cgmanager since version 
1.13. Few things are truly impossible with programming, and making 
certain functions be implemented independent of or outside of PID 1 
does not come close to impossible.


Also, I do not understand the log statement. Once again, Upstart can 
hook up a job's stdout/err to a file in /var/log/upstart/, but I am not 
exactly sure what was being said so maybe I missed the point.


Cheers,
--
Cameron

Re: piece of mind

[Cameron Norman]

On Mon, Oct 20, 2014 at 6:43 AM, Adam Borowski kilob...@angband.pl wrote:
 On Mon, Oct 20, 2014 at 08:35:05AM +0200, Christoph Biedl wrote:
 * consider skipping jessie altogether in the hope jessie+1 will
 provide alternatives or, at least has a systemd where development
 speed went down significantly.

 That's backwards -- it's the future that's at risk, jessie is a fine release
 with just a handful of breakages that still might be fixed before it's out.

 Stuff I know that's broken with non-systemd:
 * the Utopia stack (restart, shutdown, suspend, hibernate, mounting USB
   drives, etc from GUI (with low-level tools like pm-utils working)).
   This is supposed to be handled by systemd-shim which doesn't currently
   work for me, but some folks report it being ok.

What versions (of shim and cgmgr) did you try it with? I thought these
types of issues were fixed in Sid :/

Thanks,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRLKjJ+mX3eUsU7jeaAc=35ZxPxB27=6xyy32zgyuop...@mail.gmail.com

Re: Migration from cron to cron-daemon?

[Cameron Norman]

On Thu, Oct 16, 2014 at 12:18 PM, Stephan Seitz
stse+deb...@fsing.rootsland.net wrote:
 Hi!

 I sent the attached message to debian-release, but I was told to ask in
 debian-devel.

 So here is the mail.

 Shade and sweet water!

 Stephan

 --
 | Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
 | Public Keys: http://fsing.rootsland.net/~stse/keys.html |


 -- Forwarded message --
 From: Stephan Seitz stse+deb...@fsing.rootsland.net
 To: debian-rele...@lists.debian.org
 Cc:
 Date: Thu, 16 Oct 2014 15:21:59 +0200
 Subject: Migration from cron to cron-daemon?
 Hi!

 Is there currently a migration from „cron” to „cron-daemon” as virtual
 package?

 New packages like brcon-run don’t provide cron anymore but cron-daemon.  And
 many packages like exim4-base or mgetty-fax haven’t changed their
 dependencies (and other packages their recommends).

 Some packages have already bug reports for this case. But shouldn’t this be
 a reason for a mass bug filling?

Getting a little bit off topic, is there a way for a package to depend
on the /etc/cron.{hourly,daily,etc} files being executed, but not
depend on the actual full crontab implementation?

This would allow for a more minimal cron daemon on certain setups (or
no cron daemon, plus the systemd glue that has appeared,
systemd-cron).

Thanks,
--
Cameron Norman


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfrjqvltrj9z1brcoedbsqyfrjzkgajcqctqzq17m2...@mail.gmail.com

Re: piece of mind (Re: Moderated posts?)

[Cameron Norman]

On Thu, Oct 16, 2014 at 3:02 AM, Martin Read zen75...@zen.co.uk wrote:
 On 15/10/14 23:01, Adam Borowski wrote:

 shim doesn't appear to work, at least for me.  To get basic functionality
 like shutdown from GUI, suspend or mounting USB drives, I needed to
 downgrade the whole Utopia stack to their last working versions.


 Out of interest, what's the bug number?

757348 (merged with 754850, 758746)
757698
747821
760281
759745 (assigned to gdm3 currently)
and possibly 741698 (assigned to lightdm currently, IIRC)

I think most of these bugs have been fixed with the recent releases of
cgmanager and systemd-shim, just waiting for maintainers to verify and
close them. (as well as for those version to make it to testing in a
week or so)

Cheers,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFR+WjXfRV4Hi7EQ=43=p9rtmgors+odtvjyan8vo9jh...@mail.gmail.com

Re: virt-manager

[Cameron Norman]

On Sat, Sep 27, 2014 at 7:58 AM, Fabrice Aeschbacher
fabrice.aeschbac...@gmail.com wrote:
 Dear maintainers,

 For now, virt-manager v1.x is in experimental only (1.0.1).

 The freeze for Jessie is approaching, and I wondered if something
 particular is preventing the package migration from experimental to
 unstable before the freeze (in less than 6 weeks).

Looks like this bug filed onto the version in experimental:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740047.

Seems like the maintainer might need help with it.

Cheers,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfrkb3nnb7zhjqzpqj7snmqsgva6yzfuoversx1w3ipv...@mail.gmail.com

Fwd: bash without importing shell functions from the environment

[Cameron Norman]

On Thu, Sep 25, 2014 at 12:35 PM, Josselin Mouette j...@debian.org wrote:
 Le jeudi 25 septembre 2014 à 16:29 +0100, Ian Jackson a écrit :
 I have prepared bash packages which do not honour any shell functions
 they find in the environment.  IMO that is a crazy feature, which
 ought to be disabled.  (I'm running this on chiark now and nothing has
 visibly broken yet.)

 Thanks for your effort.

 Since I’m pretty sure we haven’t uncovered all of bash’s “features”,
 wouldn’t it be a good opportunity to make a release goal of killing all
 scripts with a #!/bin/bash shebang?

FYI: I have removed the bug from CC, since this discussion seems a bit
separated from it.

Perhaps making all those scripts either depend on bash or transition
to /bin/sh would be a good idea. This could be done through a lintian
warning I think. Then people interested in working on fully
transitioning to /bin/sh could just find the reverse depends of bash
and the packages affected by the lintian warning.

Best regards,
--
Cameron Norman


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRL+tfaoLQ=0tme9zhosb20u9iqydbfu4s6oed6bdfm...@mail.gmail.com

Re: Trimming priority:standard

[Cameron Norman]

El vie, 12 de sep 2014 a las 10:12 , Theodore Ts'o ty...@mit.edu 
escribió:

On Fri, Sep 12, 2014 at 03:12:47PM +0100, Simon McVittie wrote:
 
 (Admittedly, cron has to be Priority:important anyway, to support
 logrotate - until/unless someone adds a logrotate.timer for 
systemd, and

 makes its cron job early-return if systemd is pid 1.)


It's inevitable that systemd will subsume cron, with an incompatible
configuration file format.  :-)


logrotate uses /etc/cron.{hourly,daily,weekly,yearly}/$jobname format, 
so systemd-cron can subsume cron's functionality (wrt to logrotate), 
and they will both use the same lack of a configuration file format (in 
favor of a directory format) :)


Best,
--
Cameron

Re: PackageKit cleanup: Do you use these functions?

[Cameron Norman]

El mié, 10 de sep 2014 a las 5:34 , Matthias Klumpp 
matth...@tenstral.net escribió:

Hello!
(This is just a quick heads-up for the PackageKit-using people in
Debian, so if you don't use PK, you can skip this mail.)
We are currently cleaning up PackageKit[1] upstream, which means some
functionality will soon no longer be available anymore.
Short-term (= with one of the next uploads to Debian), I will remove
the Smart backend from Debian, to use PackageKit with the Smart
package-manager. This backend has also been removed upstream.
So if you use/want to use PK with that backend, act now and implement
the necessary bits upstream! The backend is currently broken in
Debian, and carrying it around does not make much sense.
The other long-term removed features include:
 * Transaction hooks (scripts to run after and before Pk transactions)
 * Support for plugins
 * .desktop file database and package-list caches
 * maybe the debug-info installer as well, although that's in 
discussion


So, if you use one of these things, it would be good to think about a
replacement, or give feedback upstream to keep these features.
Depending on the state of PackageKit's reverse dependencies and other
factors (use of the features described above by users), I will include
the next release of PackageKit (1.0) which has the cleanup done in
Jessie or not (currently, keeping 0.9.x seems more likely)

PackageKit also has support for systemd-based offline-updates for a
while now, which downloads updates while the system is running, and
installs them in a special mode when the system is rebooting. This
should ensure that no breakage happens when running applications are
replaced with new versions. This is, however, a completely optional
feature, and updates of the system while it is running are still
possible with PK.


What are the options?

I would like if apps could say somehow (maybe an extension to the 
AppStream format?) whether they need offline updates, or if online is 
fine, so that it is only when needed. Also, an option to ignore apps' 
preferences and just do always offline or always online should be 
present (in PK's configuration).


Is this how the feature has been implemented? Do you think upstream 
(and you as an AppStream supporter / developer) would be enthusiastic 
about adding this, if it is not the status quo?


Thanks for the communication,
--
Cameron Norman

Re: upgrades must not change the installed init system [was: Re: Cinnamon environment now available in testing]

[Cameron Norman]

El lun, 8 de sep 2014 a las 9:07 , Matthias Urlichs 
matth...@urlichs.de escribió:

Hi,

Vincent Danjean:
 If I recall correctly, when Debian switched the default MTA, 
upgrades

 did not change the already installed.


You cannot have an MTA without configuring it, and nobody even tried 
to
implement auto-migration of the old default mailer's configuration to 
the
new one. Also, we didn't switch to a different default mailer because 
the

new one offered a heap of features and infrastructure which the other
lacked.

None of this applies to systemd.


I do not think that the reasons for switching are at all relevant. 
These examples are unanimously pointing to defaults only being defaults 
for new installation.


I think most people would expect that if XFCE remained the default 
desktop for Jessie, then GNOME users should not be switched over 
without even being asked. But this is not even a good example. What we 
are doing here is switching **everyone**, even those who are using a 
custom /sbin/init in their own repo or Upstart.


Furthermore, this switching is being done far more often than just at 
upgrade time: everytime a user installs something that depends or 
recommends libpam-systemd (indirectly or directly), he or she currently 
have to double check that their init system is not being switched out 
from under them. Install CUPS? Better know that you have to install 
systemd-shim if you want to keep your init system...


The fact is that most defaults changes do not modify current user's 
systems (MTA, syslog, desktop environment), and they definitely do not 
do so without asking about it first (see /bin/dash).


Even if you do want to change it at upgrade time silently, the 
systemd-sysv | systemd-shim bit does way more than that, and it does so 
constantly and without any immediate guidance (i.e. install 
systemd-shim).


A couple ways to make this better would be to add a message in 
systemd-sysv saying that the system is being switched over (and that 
installing systemd-shim may prevent this, at the cost of a less 
complete/solid/whatever logind implementation), just switching the 
dependencies around, or using virtual packages for logind dependencies 
(since apt knows what is the best decision already).


Please consider the above prospective actions, and give feedback or 
results.


Thank you for your time and effort,
--
Cameron Norman

Re: There should not be dependencies on systemd

[Cameron Norman]

El sáb, 6 de sep 2014 a las 2:18 , Ansgar Burchardt 
ans...@debian.org escribió:

Noel Torres env...@rolamasao.org writes:
 If you need dbus, you should Depend on dbus, and systemd should 
Provides dbus. 
 Then, if Ann programs her Own Dbus Implementation she can package 
it as aodi 
 (Ann's Own Dbus Implementation) and have aodi Provides dbus. Same 
for logind 
 (systemd Provides logind and random-package Depends logind), and 
any other 
 piece of the big systemd ecosystem.


 Any dependence on systemd or any other init system should be 
considered an RC 
 bug (except only packages designed to manage the init system, like 
an 
 imaginary systemd-tweaking-tool).


That doesn't change anything in practice as long as systemd would be 
the

only package providing logind. So until someone writes an alternative
implementation, it would just be useless work.


systemd-shim can get you a logind implementation w/o systemd as PID 1. 
With the above scenario (virtual packages like logind), apt would be 
smart and install the least disruptive package. Do you think that would 
be systemd-shim (no removal of current init) or systemd-sysv (removal 
of packages)?


Best,
--
Cameron Norman

Re: Cinnamon environment now available in testing

[Cameron Norman]

El dom, 7 de sep 2014 a las 3:45 , David Weinehall t...@debian.org 
escribió:

On Fri, Sep 05, 2014 at 12:37:12PM -0700, Cameron Norman wrote:
 On Fri, Sep 5, 2014 at 1:57 AM, Josselin Mouette j...@debian.org 
wrote:

  Noel Torres wrote:
  So we are clearly failing to follow the least surprise (for the 
user) path.

 
  Should not logind depend on systemd-shim | systemd-sysv instead?
 
  No. Systemd is the default init system. The default dependencies 
should

  reflect that.
 
 It has already been explained that it being the default makes the
 order switching irrelevant for what you recommend. If people are 
using

 the default init, the dependency will already be satisfied and life
 will not be disrupted. The same thing should happen if people are
 using a different init: that decision should be maintained unless 
they

 manually uninstall the package that satisfies the init package's
 dependency.


Most Debian systems aren't using sysvinit by active choice, but 
because
it was the default when they installed their machines, so this 
argument

doesn't really make sense.


But some are, and this completely leaves them out in the cold. One 
option is to put a heads up in systemd-sysv, or some other type of 
glue so that on an upgrade, people know what is happening to their 
systems.


Best regards,
--
Cameron

Re: Cinnamon environment now available in testing

[Cameron Norman]

On Fri, Sep 5, 2014 at 1:57 AM, Josselin Mouette j...@debian.org wrote:
 Noel Torres wrote:
 So we are clearly failing to follow the least surprise (for the user) path.

 Should not logind depend on systemd-shim | systemd-sysv instead?

 No. Systemd is the default init system. The default dependencies should
 reflect that.

It has already been explained that it being the default makes the
order switching irrelevant for what you recommend. If people are using
the default init, the dependency will already be satisfied and life
will not be disrupted. The same thing should happen if people are
using a different init: that decision should be maintained unless they
manually uninstall the package that satisfies the init package's
dependency.


 And from a purely functional point of view, it makes more sense to bring
 by default the standard, upstream-supported, well-tested solution, than
 the Debuntu-specific hack to use it with an inferior init system.

Another purely functional POV is that upgrading from wheezy to jessie
should not require switching your init system (or removing NM and
GNOME and more), as it does currently.

Cheers,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfr+20rlwdsgcecbuvxqkkpojxfdo3oy3vf5o-wolveb...@mail.gmail.com

Re: systemd, again (Re: Cinnamon environment now available in testing)

[Cameron Norman]

On Fri, Sep 5, 2014 at 5:20 AM, Matthias Urlichs matth...@urlichs.de wrote:
 Hi,

 Noel Torres:
 * superior: plain no

 Your opinion. Mine is hell yes. Both opinions are completely worthless,
 absent any reasoning.
 Could we please stop the systemd is good vs. systemd is bad bashing?

 In any case, IMHO a system that's been installed with wheezy, and
 then upgraded to jessie, should be identical to a system installed with
 jessie in the first place.

Regardless of whether I agree or not, I do not think a good way to do
this is through random dependencies of DE's or network manager.


 Thus, unless the user explicitly tells the apt{-get,itude} subsystem not
 to switch to systemd (by whatever means, the details of which I personally
 am not at all interested in), a dist-upgrade should do so.

Currently, this is impossible, since systemd-shim DNE on Wheezy.

Best wishes,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRJttF2DdbMfvF73sjTMRbDO9_388ruPtCg4doKSww=t...@mail.gmail.com

Re: Cinnamon environment now available in testing

[Cameron Norman]

On Thu, Sep 4, 2014 at 4:51 PM, Adam Borowski kilob...@angband.pl wrote:
 On Thu, Sep 04, 2014 at 02:57:16PM +0200, Margarita Manterola wrote:
 On Thu, Sep 4, 2014 at 9:43 AM, envite env...@rolamasao.org wrote:
  Does this Cinnamon for Debian include systemd ?

 Yes, for Linux it includes systemd.  For kFreeBSD it should be able to
 work without systemd, but some packages haven't compiled yet due to
 missing dependencies.

 If Cinnamon can work without systemd, why is it a hard dependency?

TL;DR `sudo apt-get install systemd-shim`

You are mistaken, it is not. What I suspect happened is that something
depended on logind (libpam-systemd) and libpam-systemd depends on
systemd-sysv | systemd-shim. This means that systems will have their
init system switched even if unneeded unless they predict the issue or
track down the dependency tree, then learn they have to install
systemd-shim (which does not exist on Wheezy, so you will have to
install systemd-sysv then another init after the upgrade). This bug
has been reported and marked as WONTFIX for reasons that have not been
fully explained (it is claimed people with init=/lib/systemd/systemd
in their kcmdline will experience breakage due to systemd-shim
conflicting with systemd-sysv, however this is actually not likely at
all according to the shim maintainer).

Best,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfrlfyhzzvnxnrnumzyhlbeuoqfmm5vmere5j6yqtxl+...@mail.gmail.com

Re: Jessie without systemd as PID 1?

[Cameron Norman]

El mié, 3 de sep 2014 a las 4:07 , Marco d'Itri m...@linux.it 
escribió:

On Sep 03, Steve Langasek vor...@debian.org wrote:

  
https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shimshow_installed=onwant_legend=onwant_ticks=onfrom_date=2014-01-01to_date=hlght_date=date_fmt=%25Y-%25mbeenhere=1
 
 Please stop using graphs showing how various teams have forced 
systemd onto users' systems as if it is somehow a democratic 
endorsement of the outcome.
I am not sure about how the concept of democracy applies to this, but 
the graph clearly shows that nobody is being forced to do anything 
and 
indeed about 4000 users choose to install systemd-shim and to not use 
systemd.


Ok, let me explain Steve's POV. Many packages depended on 
libpam-systemd before systemd-shim was ever in the archive, leading to 
systemd-sysv being installed by a normal dist-upgrade on Sid (and, 
although I am not sure, testing). The alternative was often to have 
GNOME or Network Manager removed, two very popular packages (and the 
latter quite important). Even after systemd-shim was uploaded to the 
archive (still at logind v204 here), libpam-systemd depended on 
systemd-sysv | systemd-shim. This meant that users' systems would 
switch init systems on a normal dist-upgrade *unless* they manually 
intervened and knew which package they had to install to avoid that. 
Finally, systemd v208 was uploaded to unstable with an unconditional 
dependency on systemd-sysv. All of these actions led to users 
experiencing a change of init system before they had taken action to 
change init systems, which means that the graphs are not reliable in 
claiming that the majority of users wanted systemd as their init system.


I can not speak for Steve, but I recognize that some or all of those 
actions above were called for. The final one especially (systemd v208 
upload), since their was ample warning and communication (something 
like one or two months I think), the move was a long time coming, and 
systemd was chosen as the default init system by then (not true for the 
other two actions).


I hope that helps you understand how the graph does not depict how many 
users elected to use systemd as their init system.


Best regards,
--
Cameron Norman

Re: Reverting to GNOME for jessie's default desktop

[Cameron Norman]

El mar, 12 de ago 2014 a las 12:11 , Theodore Ts'o ty...@mit.edu 
escribió:

On Tue, Aug 12, 2014 at 12:26:18PM -0400, Joey Hess wrote:

 See my 1st message to this thread.


Joey,

With respect to your question re HiDPI displays and Xfce, I'm using
Xfce4 from Debian Testing on a Lenovo T540p with 3k screen, and
setting things up was fairly straight forward.  I got most of what I
needed by setting Custom DPI Setting in Settings - Appearance -
Fonts - DPI.


Did you have to edit anything else as well? I wonder if there could be 
some installer hook that detects DPI and adjusts these settings 
automatically...




The main pain point that I've had is that Google Chrome doesn't
support HiDPI very well.  I've manually adjusted the zoom level which
mostly compensates almost everything except the buttons on the
toolbar, but that's a problem which is independent of the desktop
environment, and won't be fixed until Aura support for Linux
arrives[1].

[1] https://code.google.com/p/chromium/issues/detail?id=143619

So that's my experience with Xfce and HiDPI displays; at least for
this hacker, it was orders of magnitude less painful than dealing with
GNOME.  :-)


I would appreciate if you went into a little detail on what pain you 
had with GNOME for comparison purposes.


Thank you,
--
Cameron



Cheers,

- Ted

Re: Reverting to GNOME for jessie's default desktop

[Cameron Norman]

El mar, 12 de ago 2014 a las 5:06 , Michael Biebl bi...@debian.org 
escribió:

Am 13.08.2014 01:59, schrieb Vincent Bernat:

  ❦ 13 août 2014 01:44 +0200, Michael Biebl bi...@debian.org :

 I can not confirm your findings.

 If you increase the DPI settings under XFCE following the 
instructions

 posted by Ted, none of the UI elements besides text are scaled, no
 scaled cursor, no scaled icons, no scaled window decorations, etc.
 
 As I am using awesome, window decorations, desktop icons are quite
 unknown to me. What gets scaled for free is all the GTK and QT 
widgets.


Does that include UI elements which do *not* contain text, like 
scrollbars?


Probably relevant to Michael's inquiry: can we just get a few 
screenshots? It would be a lot easier to compare.


Best regards,
--
Cameron

Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop

[Cameron Norman]

El dom, 10 de ago 2014 a las 11:39 , Kees de Jong 
keesdej...@gmail.com escribió:

Why are we discussing CD/DVD sizes? Why not just use an USB
netinstall? It's then possible to download and install the stuff you
need, if you don't want to use a lot of bandwidth then choose no
desktop environment or XFCE/LXDE. But if you can spare some more time
then you can install GNOME/KDE. Seems like a good deal. And USB sticks
are cheaper (also easier to reuse) so I don't get the 'hurting
developing countries' argument.


CDs are cheap and easy to distribute and customize (with the Debian 
logo and artwork). Yes, we all have a number of 1+ GB USB drives that 
could easily fit GNOME, but are we willing to give those away or sell 
them cheaply? Being able to distribute a Debian CD that does not need 
an internet connection to try out or install is really beneficial for 
gaining users.


elementary OS is hitting this issue with how expensive it is to make 
customized USB drives (with their logo and stuff). I think the best 
chance they have of being able to sell USB drives in their online store 
is just the elementary coloring (a distinctive light blue).


netinstall is difficult for unreliable or limited bandwidth network 
connections (luckily it is perfect for me, someone who uses GNOME and 
has a good internet connection :)


Best regards,
--
Cameron Norman

Re: [Pkg-xfce-devel] Reverting to GNOME for jessie's default desktop

[Cameron Norman]

El vie, 8 de ago 2014 a las 9:00 , Marco d'Itri m...@linux.it escribió:

On Aug 08, Joey Hess jo...@debian.org wrote:

 I recently spent some time installing community computer labs in 
rural

 Brazil. Internet bandwidth was nearly nonexistant[1], so if you were
I am sure that we could have a great competition for finding 
potential 
users with even crappier connectivity and even more obsolete 
computers, 
and somebody would improve the record every time!



 If the xfce iso didn't exist, people in these situtations would
 not be able to install a usable Debian system.
I see a solution that would satisfy everybody: whoever is interested 
in
supporting this kind of situations could build CD images appropriate 
for 
them, and everybody else who does not live in the worst connected 
parts 
of the third world can continue using a modern desktop as usual.


Wow. So the people who do not have many resources should either (a) use 
what limited resources they have on making an ISO image or (b) screw 
off because first world people have better things to do.


I bet you also think that those people in developing nations should 
learn your language (even though their education is extremely limited 
as is), while those who have enough luck to live in a country with a 
great education system have no responsibility to use that education to 
learn another language.


I think Debian's official ISO should appeal to as many people as 
possible.


While GNOME has many qualities that make it appeal to the blind or 
non-english speaking, it is one of the biggest DE's, and that makes it 
less accesible to poorer people.


Bye,
--
Cameron Norman

Re: unlocking encfs during boot (Re: systemd now appears to be only possible init system in testing)

[Cameron Norman]

El lun, 28 de jul 2014 a las 8:21 , Michael Biebl bi...@debian.org 
escribió:

Am 28.07.2014 16:53, schrieb Michael Biebl:

 --8---
 [Unit]
 Description=Unlock EncFS
 DefaultDependencies=no
 After=local-fs.target
 Before=display-manager.service getty@tty1.service
 
 [Service]

 Type=oneshot
 RemainAfterExit=true
 Environment=RootDir=/home/.encfs/crypt
 Environment=MountPoint=/home/crypt
 ExecStart=/bin/sh -c systemd-ask-password --no-tty --timeout=30 
'Unlock

 EncFS' | encfs --stdinpass $RootDir $MountPoint
 ExecStop=/bin/umount $MountPoint
 
 [Install]

 WantedBy=sysinit.target
 --8---



To show you some additional cool systemd features, I'm going a step
further and make this unit file a completely generic template unit, so
it can easily be re-used, say if you have multiple encfs file systems 
to

unlock and you don't want to copy that file over and over again.

Only 3 small modifications are necessary:
- Rename the file unlock@.service
- Update Description: Description=Unlock %I EncFS
- Use EnvironmentFile=/etc/encfs/%I

The %I is the instance name specfier and denotes the part between
unlock@instance name.service. See man systemd.unit(5)

The resulting template unit looks like this and is completely generic:

--8---
[Unit]
Description=Unlock %I EncFS
DefaultDependencies=no
After=local-fs.target
Before=display-manager.service getty@tty1.service

[Service]
Type=oneshot
RemainAfterExit=true
EnvironmentFile=/etc/encfs/%I
ExecStart=/bin/sh -c systemd-ask-password --no-tty --timeout=30 
'Unlock

EncFS' | encfs --stdinpass $RootDir $MountPoint
ExecStop=/bin/umount $MountPoint

[Install]
WantedBy=sysinit.target
--8---

So how do we create a new encfs unit now?

- mkdir /etc/encfs/
- echo -e RootDir=/home/.encfs/crypt/\nMountPoint=/home/crypt 
/etc/encfs/home
- systemctl enable unlock@home.service
Note how the file name and the instance name match.


Maybe you could use BindsTo=/etc/encfs/%I.path (I think that would 
work, right?) so that you do not have to explicitly enable it. Although 
that would cause the MTPT to be unmounted if the file is deleted 
(unless the ExecStop= is removed)... Anyway, pretty cool.


Thanks for sharing,
--
Cameron Norman

Re: systemd-sysv/shim in testing

[Cameron Norman]

El Sun, 27 de Jul 2014 a las 11:23 AM, Sven Bartscher 
sven.bartsc...@weltraumschlangen.de escribió:

Greetings everyone,

As brought up in this[0] thread, systemd-shim became incompatible with
the latest versions of systemd and the alternative dependency was
removed.

While this is something I can totally understand, I don't think that
systemd should migrate to testing without the possibility to use
systemd-shim instead.

My reasoning about this is as follows:
Testing should be as close to a state in which it can be released as
possible (I don't have a citation for that and just remember that I 
did
read that somewhere, so please correct me if I'm wrong). Further we 
are

not planning to release jessie without systemd-shim (at least I hope
so, again please correct me if I'm wrong).

This shouldn't be a huge problem, since waiting a week longer until
systemd migrates shouldn't be that much of a problem, while it makes
the risk smaller to accidentally remove your desktop-environment at a
dist-upgrade (that's at least what apt wanted to do on my computer).

To make it short: I suggest that systemd should only migrate together
with systemd-shim.

[0]: https://lists.debian.org/debian-devel/2014/07/msg00839.html

Regards
Sven


Greetings,

Although I personally agree that personal choice of init system is 
important for the distribution, by a 4-4 vote, the TC decided not to 
make dependencies on one init system as PID Eins (1) (i.e. 
systemd-sysv) a release critical bug. I believe some of the reasons 
were that the move was preemptive (as systemd 204 was the current 
systemd version), or not in the scope of the TC (specifying the exact 
severity *is* a bit much). Instead, the TC voted to not rule on the 
matter.


I believe the choices are to repose the question to the TC, now that 
the situation has actually occurred, or begin a General Resolution. As 
far as I understand, a GR would only need a majority since the TC did 
not really make a ruling.


Best wishes,
--
Cameron Norman

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Fri, 25 de Jul 2014 a las 8:47 AM, Josh Triplett 
j...@joshtriplett.org escribió:

Martin Steigerwald wrote:
 Sure I can go through setting up chroot for that, yet I really 
think if my
 work requires changes in other packages and the recent systemd 
changes do require this kind of work, I *help* with these changes, 
instead of uploading my changes to unstable *before* the other 
packages have been fixed.


One point of clarification: systemd does not require changes in
systemd-shim or cgmanager.  systemd runs just fine with no such 
changes.

Those packages exist for people who for whatever reason don't want to
run systemd, and that's not something the systemd folks should be
expected to help with (any more than people who don't want to run
systemd would be expected to work on systemd).

The systemd maintainers already held systemd 204 back in unstable for
months waiting for the alternative to become viable.

It's not reasonable to expect every systemd upgrade in 
unstable/testing
to wait for an alternative init system to keep up.  If it does keep 
up,

great; there's no fundamental reason to *not* want that alternative to
work.  If it doesn't, oh well.


I agree, but would also add that other packages in Debian should at 
least try to keep support for other init systems by not depending on 
later logind's until systemd-shim is updated. It is clear (I think) 
that there are a number of reasons somebody would prefer to use an 
alternative init system (including a few unresolved bugs so far), and 
packages like GNOME or policykit should support more than just 
systemd-sysv.


--
Cameron Norman

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Fri, 25 de Jul 2014 a las 2:50 PM, Steve Langasek 
vor...@debian.org escribió:

On Fri, Jul 25, 2014 at 11:10:41PM +0200, Michael Biebl wrote:

 Am 25.07.2014 19:23, schrieb Steve Langasek:
  systemd-shim 6-4 has now been uploaded to unstable with a 
dependency on
  cgmanager, implementing the new post-v205 interfaces. 



 I just installed systemd-shim 6-4 and cgmanager 0.28-1.
 Unfortunately the cgmanager package seems to be not quite ready yet.



 The init script fails with



 # service cgmanager start
 [] Starting cgroup management daemon: cgmanagercgmanager: Failed
 mounting memory onto /run/cgmanager/fs/memory: No such file or 
directory

 cgmanager: Failed mounting cgroups
 cgmanager: Failed to set up cgroup mounts
 . ok



 on a default jessie kernel.


I believe this is bug #755990, already fixed by Serge in 0.28-2.


 Interestingly, the return code of the init script was 0.


Hmm, dunno about that.  Serge?


Oh this is easy. The init script calls s-s-d and does not check the 
return code (so always exits 0). I am just going to use set -e in the 
init script, only a couple tweaks are needed. I will get a merge 
request to the github repo in about 15 minutes.


Cheers,
--
Cameron Norman

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Fri, 25 de Jul 2014 a las 3:42 PM, Russ Allbery r...@debian.org 
escribió:

Cameron Norman camerontnor...@gmail.com writes:

 Oh this is easy. The init script calls s-s-d and does not check the 
return

 code (so always exits 0). I am just going to use set -e in the init
 script, only a couple tweaks are needed.


Please don't use set -e in init scripts.  See Policy 9.3.2:

Be careful of using set -e in init.d scripts.  Writing correct 
init.d
scripts requires accepting various error exit statuses when 
daemons

are already running or already stopped without aborting the init.d
script, and common init.d function libraries are not safe to call 
with
set -e in effect.  For init.d scripts, it's often easier to not 
use

set -e and instead check the result of each command separately.

Not mentioned there is another problem, namely that LSB mandates
particular exit codes for particular conditions in init scripts, and 
set

-e will not produce the correct exit codes.


I thought that start-stop-daemon (and status_of_proc) returned the 
correct codes, and whatever it returns you can relay / let the shell 
catch? The script is here 
(https://github.com/cgmanager/cgmanager/pull/14/files), if you wanted 
to take a look.


Best,
--
Cameron Norman

Re: systemd now appears to be only possible init system in testing

[Cameron Norman]

El Tue, 22 de Jul 2014 a las 4:39 PM, Vincent Lefevre 
vinc...@vinc17.net escribió:

On 2014-07-23 01:24:53 +0200, Vincent Lefevre wrote:

 On 2014-07-22 22:54:55 +0100, Julian Gilbey wrote:
  I just tried updating testing on my system.  I currently use
  sysvinit-core (reasons below), but aptitude is telling me that I
  should remove this in favour of systemd-sysv.  Hmm, why is that?
  Well, because the new version of libpam-systemd, 208-6, now 
depends on

  systemd-sysv rather than systemd-sysv | systemd-shim.
 
 As you can see with this dependency, you just need to install

 systemd-shim. No need to install systemd-sysv!
 
 The default (systemd-sysv) was just a poor choice from aptitude.


Sorry, I mixed up with another problem that occurred with previous
versions. I have no problems on my Debian/unstable machines
(libpam-systemd still depends on systemd-sysv | systemd-shim),
but I've just realized that the reason is that I temporarily
blocked systemd upgrades for another reason. This is probably
the best thing to do because seeing how things evolve.


I used this apt preferences part to keep systemd back to version 204 
until systemd-shim is updated:


   Package: systemd libsystemd-* libpam-systemd
   Pin: version 204*
   Pin-Priority: 1001

I noticed that not doing the libraries cause apt to try to upgrade them 
on dist-upgrade and do some weird operations like try to remove my 
current init system and install systemd-sysv or remove all of systemd, 
as well as NM and udisks and a lot of other packages.


Best wishes,
--
Cameron Norman

Re: Where to upload official OpenStack Debian images?

[Cameron Norman]

El Fri, 18 de Jul 2014 a las 4:49 AM, Steve McIntyre st...@einval.com 
escribió:


I think we could/should have space on cdimage etc. [for OpenStack 
images] - how big are we talking?


He said 350-400 GB, but it is highly probably he meant to type MB.

Re: OpenRC status (was: MATE 1.8 has now fully arrived in Debian)

[Cameron Norman]

El Wed, 4 de Jun 2014 a las 11:47 AM, Thomas Goirand z...@debian.org 
escribió:

On 06/04/2014 02:50 PM, Ritesh Raj Sarraf wrote:


 All I've tested so far is
 inside my test vm, where it works fine. I'd love to have it on my 
work

 laptop, if I just had a replacement for policykit.


There's nobody currently working on a policykit / logind replacement.
This is IMO out of the scope of an init system and should be a 
separated

project.



Are you sure you want to replace polkit? Seems like more work than 
necessary...


Anyway, I know Ryan Lortie (GNOME dev) was interested in defining what 
parts of logind GNOME would use by writing a library that only made 
calls to specific dbus methods and properties[1]. Perhaps if we do find 
somebody knowledgeable on the topic and/or interested in reimplementing 
logind they can give their input as to what is fine and what is more 
difficult to reimplement.


[1] http://blogs.gnome.org/desrt/2014/02/19/on-portability/ (towards 
the end)


Best regards,
--
Cameron

Re: MBF (Re: correct use of su)

[Cameron Norman]

El Mon, 12 de May 2014 a las 10:53 PM, Brian May 
br...@microcomaustralia.com.au escribió:

On 13 May 2014 15:44, Cameron Norman camerontnor...@gmail.com wrote:
I found another use of su that may need to be added to your list. 
rabbitmq (oddly) wraps itself up in a shell script, 
/usr/sbin/rabbitmq-server, which asserts the user is root or 
rabbitmq, and drops down to rabbitmq if it is root (using su), then 
starts the actual binary. The problem with this one is that it is 
upstream code and cannot use s-s-d for obvious reasons.




I would imagine that the init.d script just needs to be modified to 
use the -c option of start-stop-daemon, and that way 
/usr/sbin/rabbitmq-server will be called with the correct user and 
won't run su.




It looks like it already does this. I assume the user running the 
command manually would not hurt anything, correct?


I assume that the init.d script could also call the actual binary 
directly.




Yeah I dealing with issues with the PID being seemingly unpredictable 
(for some other thing I was doing), and that is how I fixed it.



Do wonder how many packages call su in this manner though.



It seems like there is a very real use case for it, I would assume a 
few more than what we have seen. Certainly not anything too formidable 
though.


Best,
--
Cameron Norman

Re: systemd-fsck?

[Cameron Norman]

El Mon, 12 de May 2014 a las 3:48 PM, Charles Plessy 
ple...@debian.org escribió:

Le Mon, May 12, 2014 at 11:21:15AM -0700, Josh Triplett a écrit :
 
 There *is* a reason we should push our users away from the 
non-default
 init: we want to make sure that only the users who specifically 
*want* a
 non-default init run one, and those are exactly the users prepared 
to
 deal with the additional challenges and support issues with doing 
so.
 Uers who don't care should end up running the default init system.  
It's
 easy enough for any user who *does* care to select a different set 
of

 installed packages.


Hi Josh and everybody,

how about the following heuristic:

on systems where appropriate task-desktop metapackages are installed, 
migrate automatically; on other systems, ask.


I think that it would minimise the total number of people who a) 
break their
desktop systems or block their upgrade by being afraid to migrate and 
b) break their server with an unsupervised migration.


Said differently, judging from what is written in the long threads 
here, people who do not want systemd seem to be running servers or 
exotic desktop systems, so how about only sending a debconf prompt in 
these cases ?




Is it not possible to tell if the sysvinit or upstart packages were 
installed manually, and give a prompt then (in addition to something 
like you described) ?


Best,
--
Cameron Norman

Re: MBF (Re: correct use of su)

[Cameron Norman]

El Mon, 12 de May 2014 a las 6:01 PM, Michael Biebl bi...@debian.org 
escribió:

Am 13.05.2014 02:54, schrieb Russ Allbery:

 Steve Langasek vor...@debian.org writes:
 
 AFAIK, d-i disabling of s-s-d is a historical workaround for 
packages
 not using invoke-rc.d (back in the days before it was a Policy 
must).

 Maybe it's time to drop this diversion of s-s-d?

 
 Yeah, that's just what I was thinking.  Any software that doesn't 
honor an invoke-rc.d policy is RC-buggy anyway, and it would be good 
to catch and fix that.
 


Given the responses so far, I might consider doing a MBF based on the
list I posted at [0]. I think this list is pretty complete wrt SysV 
init

scripts. I could extend that to cronjobs etc if there is interest.



I found another use of su that may need to be added to your list. 
rabbitmq (oddly) wraps itself up in a shell script, 
/usr/sbin/rabbitmq-server, which asserts the user is root or rabbitmq, 
and drops down to rabbitmq if it is root (using su), then starts the 
actual binary. The problem with this one is that it is upstream code 
and cannot use s-s-d for obvious reasons.


If I am wrong in thinking this usage would be buggy, then carry on.

Best,
--
Cameron Norman

Re: systemd-fsck?

[Cameron Norman]

El Sun, 11 de May 2014 a las 1:49 PM, Michael Biebl bi...@debian.org 
escribió:

Am 11.05.2014 19:37, schrieb Helmut Grohne:


 I trust you to be technically right on this. Still the number of
 packages getting this wrong is stunning[1]. Therefore I'd argue that

 [1] 
http://codesearch.debian.net/search?q=su+-c+path%3Adebian%2F+path%3Ainit



If I counted correctly, there are 5 packages using su in their init
script, dirmngr being one of them. Considering that we have ~1200 SysV
init scripts in Debian, I don't consider this number stunning at all.
And yes, we should fix those init scripts.



I do not believe that list is at all comprehensive. One example would 
be the init script for the package rotter.


Best regards,
--
Cameron Norman

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

[Cameron Norman]

Hello,

On Mon, May 5, 2014 at 3:29 AM, Matthias Urlichs matth...@urlichs.de wrote:
 Hi,

 [snip]

 The second case is a no-brainer. Many packages in Debian consist of more
 than one binary, of which you need at most one (if that). Do you really
 want to mass-file a bug against all of these _and_ the packages depending
 on them, or are you picking on systemd for non-technical reasons here?

 Sorry, but I suspect the latter.

Please do not assume bad faith; I hold none.

Best wishes,
--
Cameron


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRLBb=fzCkmvzxURubQ0V2+bWQLbPcWifzFPak=96fx...@mail.gmail.com

Re: A question about patches for upstream

[Cameron Norman]

On Mon, May 5, 2014 at 6:05 PM, Charles Plessy ple...@debian.org wrote:
 Le Mon, May 05, 2014 at 08:56:48PM +0200, Bas Wijnen a écrit :

 I'm happy to see that there is consensus anyway that forwarding bugs upstream
 is the task of the maintainer.

 Hi all,

 being a package maintainer, I am always uncomfortable when I have the
 impression that I am considered like a human patch-pushing machine that 
 extends
 the impact of mass-scale patch producers.  Luckily it is not happening often,
 but please let's take a point of view that is less patch-centric and more
 human-centric.

I am sorry if this was mentioned earlier in the conversation, but are
you talking about a specific package here?

Best,
--
Cameron


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRLyGSHXfaA_mYdxCsV7cx7npnJtm=+bkdha7vfh9af...@mail.gmail.com

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

[Cameron Norman]

El Sun, 4 de May 2014 a las 4:24 PM, Marco d'Itri m...@linux.it 
escribió:

On May 04, Kevin Chadwick ma1l1i...@yahoo.co.uk wrote:

 packages. I know our systems have no functional use for 
systemd-logind and yet lots seems to depend on it but it is less 
clear what depends on which parts and so why each of the many 
packages do so. Whilst avoiding



If something depends on it then it means that it really needs it.
If you do not need that something then feel free to uninstall it.



This is flawed for many reasons.

Example one: someone does not need logind, but removing it would remove 
their init system.


Example two: someone needs logind, but they do not need binfmt, nspawn, 
or networkd. Removing any of those would remove the init system, their 
window manager, most of their desktop environment, and their login 
manager.

Re: standalone logind (Re: Bits from the systemd + GNOME sprint)

[Cameron Norman]

El Sun, 4 de May 2014 a las 5:59 PM, Marco d'Itri m...@linux.it 
escribió:

On May 05, Cameron Norman camerontnor...@gmail.com wrote:

 Example one: someone does not need logind, but removing it would 
remove

 their init system.


So do not try to do it.



Constructive solution you have got there.

 Example two: someone needs logind, but they do not need binfmt, 
nspawn, or
 networkd. Removing any of those would remove the init system, their 
window

 manager, most of their desktop environment, and their login manager.

There is no need to remove any of these components even if you are 
not 
using them.



‘4’

I understand just fine how it is packaged. It is packaged in a way that 
pushes components down other's throats and tells users to simply 
disable them if they are not necessary.


This is incredibly unfair to those components' competitors because it 
is not a fair playing field. Some authors (those that do their work in 
the systemd source tree) get higher preference to others (those that 
prefer to not create a monolithic source tree, do not like systemd's 
license, do not like people to have commit access to their project 
unless they have earned it, and an array of more valid reasons).



Please come back when you will.



I feel this statement is condescending, rude, alienating, and 
dictatorial. Do not act this way toward me; I do not appreciate it.


Nos vemos,
--
Cameron

Re: Bits from the systemd + GNOME sprint

[Cameron Norman]

On Sat, May 3, 2014 at 6:04 AM, Tshepang Lekhonkhobe tshep...@gmail.com wrote:
 On Fri, May 2, 2014 at 1:26 AM, Jordi Mallach jo...@debian.org wrote:
 Michael B. also updated systemd to 208 in experimental.

 212 was released in March. Why not package that?

I believe people pushing AppArmor in Debian would appreciate that.
v210 adds a AppArmorProfile stanza.

Oh, and Ubuntu too.

Regards,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfrlhpdm--6elgtpj5xd8bast0pn9dcgu2d2mvjre0do...@mail.gmail.com

Re: Source Requirements

[Cameron Norman]

On Tue, Apr 29, 2014 at 2:34 PM, Dimitri John Ledkov x...@debian.org wrote:
 On 29 April 2014 21:02, Thomas Koch tho...@koch.ro wrote:
 On Tuesday, April 29, 2014 02:26:49 AM Scott Kitterman wrote:
 Recently there have been a number of questions about source requirements
 for the Debian archive.  The FTP master view of this are based on both
 item 1 of the social contract (Debian will remain 100% free) and item 2 of
 the DFSG (The program must include source code ...).  We consider source
 packages to be part of the Debian system and as such all files in source
 packages must come with their source as required by the DFSG (and be
 distributable under a free license).

 For clarity: Is it OK for languageCompilerX, which happens to be written in
 languageX, to ship a compiled binary of languageCompilerX in the source
 package for languageCompilerX?


 of course not, do a bootstrap each time, or provide a separate
 bootstrap package in the archive, such that other people can reproduce
 the boostrap process. circular build-dependency on one-self is always
 bad.
 What's your concrete example at the moment? or is this just a
 hypothetical corner case?

I am unsure if they have done so yet, but the developers of the Go
compiler expressed the intention to start writing the compiler in Go,
not C. They also wanted to write the compiler in the most recent
stable version of Go, so you would need Go 1.3 to compile Go 1.4 --
goc 1.1 would not compile anything but =1.2.

Best,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRKTf7vzO4XH01xsr-T2e=tkgwow6b-qz99rsgggbwd...@mail.gmail.com

Re: what to do with wayland, python3, gdm3/systemd, ...

[Cameron Norman]

On Mon, Apr 28, 2014 at 3:16 AM, Osamu Aoki os...@debian.org wrote:
 Hi,

 Questions are how Debian Jessie packages should be packaged with regards
 to configuration choices etc.:

  wayland support or not (I am skipping ones using libwayland-dev now)
  python3 support or not (Are we moving too?)
  X session autostart scripts under systemd

I would say yes to all. It does not seem like systemd user sessions
are going to be happening for Jessie, but it would be great if people
hacking together their user session could do so more easily. I have
seen a lot of people on Arch running systemd as their session init
system. I am assuming that the systemd user session stuff does not
require you to install anything systemd specific (except maybe
libsystemd-daemon) and still allows you to run ibus w/o systemd.

Best,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CALZWFRJ-gvStxMAbd4j=+nxshtjcl-smte24cfe_siykem6...@mail.gmail.com

Re: goals for hardening Debian: ideas and help wanted

[Cameron Norman]

On Thu, Apr 24, 2014 at 9:49 AM, Giacomo Mulas
giacomo.mula...@gmail.com wrote:
 On Thu, 24 Apr 2014, Steve Langasek wrote:

 The apparmor policies in Debian apply a principle of minimal harm,
 confining
 only those services for which someone has taken the time to verify the
 correct profile.  There are obviously pros and cons to each approach to
 MAC,
 which I'm not interested in arguing about; but one of the pros of the
 approach taken for apparmor is that all software *does* continue to work
 out
 of the box.  If you found it otherwise, I think you should be filing a bug
 report against apparmor.


 Good to know, actually I had tried apparmor quite some time ago and did not
 try again. I will give it another spin as soon as I can.

 However, I do not agree that I should file bugs against apparmor if a debian
 package does not work properly, it should go to the package manager (and
 maybe cc to some apparmor expert team).  It cannot be the maintainer(s) of
 apparmor to have to shoulder the effort of creating and maintaining profiles
 for all debian packages.  They may be called in for support, but regular
 package maintainers should be involved IMHO, otherwise it will never really
 take off and provide significantly better security.

Both of you have misunderstood each other.

Steve, Giacomo was advocating the creation of profiles/configurations
for all debian packages and considering it a serious bug if that was
not done.

Giacomo, Steve thought that you meant that unconfined applications
should work perfectly when the user is using a MAC, and not that they
should integrate with the MAC mechanism. So he was trying to explain
how AppArmor only interferes with explicitly configured (by the
package maintainer or user) profiles, and would not cause any harm to
non-confined applications. This is forgivably irrelevant, because you
are talking about confined applications.

Best regards,
--
Cameron Norman


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/calzwfrlhuawxatvzeb46jbuvozm54crpxac0ksx_wajx4pd...@mail.gmail.com

Re: goals for hardening Debian: ideas and help wanted

[Cameron Norman]

El Wed, 23 de Apr 2014 a las 7:57 PM, Paul Wise p...@debian.org 
escribió:

Hi all,

I have written a non-exhaustive list of goals for hardening the Debian
distribution, the Debian project and computer systems of the Debian
project, contributors and users.

https://wiki.debian.org/Hardening/Goals

If you have more ideas, please add them to the wiki page.

If you have more information, please add it to the wiki page.

If you would like to help, please choose an item and start work.



Would the inclusion of more AppArmor profiles be applicable?

Thanks,
--
Cameron Norman

Re: systemd - some more considerations

[Cameron Norman]

El Wed, 2 de Apr 2014 a las 7:12 PM, Norbert Preining 
prein...@logic.at escribió:

Hi

recent discussions on lkml really made me rethink the systemd
position.

How is it possible that:
* systemd maintainers (Kay Sievers) considers an obvious bug in
  his code that locks out users something not in need to be cared
  for?
https://bugs.freedesktop.org/show_bug.cgi?id=76935

* systemd maintainers (Lennart Poettering) does not care for
  segfaults in his code, even if it happens in pid 1.
https://bugs.freedesktop.org/show_bug.cgi?id=74589

* several kernel maintainer propose (not completely serious, but
  it shows the general opinion), to add
+   BUG_ON(!strcmp(current-comm, systemd));

Is this the upstream Debian wants to base its life on?

Scary scary scary.

Norbert

This really is not something suitable for debian-devel, unless you are 
actually proposing a GR to re-choose the init system, which you do not 
seem to be doing.


I also do not like systemd's method of development and maintenance, as 
well as a few design decisions, so I am working on Upstart support in 
Debian. If you are interested in helping, please get in touch. 
Alternatively, you could work on OpenRC, or even Epoch init.


Best Regards,
--
Cameron Norman

Re: Ifupdown dysfunctional, is a Provides: interface possible please?

[Cameron Norman]

El Fri, 28 de Mar 2014 a las 2:28 AM, Josselin Mouette 
j...@debian.org escribió:
Le vendredi 28 mars 2014 à 20:23 +1300, Matt Grant a écrit : 

 I sincerely would like to work with the ifupdown maintainer and
 systemd/udev crew to work all this out.  A basic level/interface of
 functionality for replaceable network configuration packages would 
be

 nice.


Alternatively, we could make NetworkManager the default.
It is already here, it works, and it doesn’t have such problems.



NetworkManager, as well as Connman, would essentially prevent a network 
mounted /usr (as well as wicd I believe, but need to check). networkd 
is the only option that *improves* the situation, and does not worsen 
it (a network mounted /usr with ifupdown is hard because wpa_supplicant 
requires some libraries that are in /usr/lib, but much less so than nm 
or connman, both of which reside in /usr themselves). networkd was 
specifically created to allow for even deeper remote fs situations 
(specifically, network mounted root).


I think any change to a new network configuration should not ignore the 
scenario of a network mounted /usr, as NM and connman seem to have done.


My 2¢,
--
Cameron Norman

Re: systemd and Linux are *fundamentally incompatible* - and I can prove it

[Cameron Norman]

El Sat, 29 de Mar 2014 a las 11:51 AM, Jan Gloser 
jan.renra.glo...@gmail.com escribió:
 Now that systemd has wrecked all kinds of previously working stuff, 
and many are beginning to realize the *impossibility* of getting 
systemd to  work *with* linux - I think this might have some effect 
this time around.


Hello everybody,

I've been watching this discussion, quite curious what would come up 
and now that I have read some responses I would like to say that


[snip]

I would also like to ask something the people who dislike systemd (as 
there seem to be more). I am not very proficient with such internals 
of debian, but you say things like systemd breaks things and systemd 
has no unified design and sytemd is possibly a security risk. But can 
you give some easily reproducible examples or setups, code samples, 
cucumber scenarios, whatever, that could clearly demonstrate how 
systemd breaks anything? Otherwise it's very hard for me to judge 
anything if I can't play around with it and truly see for myself that 
it's so EVIL. Otherwise if you just personally disagree with the 
design of systemd and can't describe such a scenario, why not just 
migrate to Gentoo or BSD?




systemd lacks the immense extensibility of Upstart. One example of this 
is udev integration. Upstart integrates with udev through an out of 
process (not PID1) bridge which emits events. This integration could 
have easily been done outside of Upstart's source tree, or with any 
other device event daemon (e.g. FreeBSD's devd, which listens to /dev 
for device events and reacts to them). This extensibility: keeps PID1 
small and minimal, so that unneeded bridges can easily be disable on 
more streamlined and specific setups; rips away licensing restrictions 
and contributor agreements; allows for disagreements and difficulties 
with upstream to be avoided; and finally increases portability of the 
init system.


Cheers,
--
Cameron Norman

Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* - and I can prove it)

[Cameron Norman]

El Fri, 28 de Mar 2014 a las 1:19 AM, Olav Vitters o...@vitters.nl 
escribió:

On Wed, Mar 26, 2014 at 11:38:40AM -0500, Kevin Toppins wrote:
 On 26 March 2014 10:13, Cameron Norman camerontnor...@gmail.com 
wrote:

 [...]
  That is pretty much impossible, according to the developers of 
the logind
  API and its single implementation. Perhaps a subset of the logind 
API for
  use by desktop environments / compositors would be more useful in 
this init
  and OS portability predicament. I think Matthias Clasen, a GNOME 
developer,
  actually recently expressed interest in this from a portable 
window manager

  and compositor's perspective.


Ryan Lortie said he'd work with others on some minimal logind like API
during 3.14 cycle. But focussed on entire GNOME stack, not just
gnome-shell. Complication being GDM (=extra work). Implementation on
non-Linux to be done by those developers (FreeBSD, etc; they seems to 
be

ok with that)



Thank you, that was who I was thinking of.

Best regards,
--
Cameron Norman

Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* - and I can prove it)

[Cameron Norman]

On Wed, Mar 26, 2014 at 3:40 AM, Thomas Goirand z...@debian.org wrote:

 On 03/25/2014 12:42 AM, Kevin Toppins wrote:
 Writing an independent, init system agnostic, logind API compatible
 daemon would be another good thing to do.


That is pretty much impossible, according to the developers of the logind
API and its single implementation. Perhaps a subset of the logind API for
use by desktop environments / compositors would be more useful in this init
and OS portability predicament. I think Matthias Clasen, a GNOME developer,
actually recently expressed interest in this from a portable window manager
and compositor's perspective.

Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* - and I can prove it)

[Cameron Norman]

El Wed, 26 de Mar 2014 a las 7:07 PM, gustavo panizzo gfa 
g...@zumbi.com.ar escribió:

On 03/26/2014 07:40 AM, Thomas Goirand wrote:

 If you want thing to move on, stop posting useless messages, and 
start
 working on alternatives. For example, helping adding more features 
to

 OpenRC would certainly help a way more than this post.


going offtopic here, do you know if there is any plan to use cgmanager
with openrc, i really like the idea of putting each service in it's 
own

cgroup



I was thinking about how to do something like this without requiring 
cgmanager to be started before the init system or moving the cgroups 
management into the init system itself. I wonder if dbus activation 
could be used to accomplish this. Of course, then one would not be able 
to put (in the case of Upstart) the socket bridge, dbus bridge, dbus, 
or anything those services need to boot into a cgroup, but one can 
still put stuff like Apache, lightdm/gdm/kdm/sddm, nginx, et al into a 
cgroup. Another option is to push the kernel maintainers to allow 
delegating parts of the cgroups tree to other processes, so that the 
init system could say you get a sub-hierarchy, you get a 
sub-hierarchy without the complication of multiple separate 
hierarchies. How do you suggest this integration with cgroups be done?


Best regards,
--
Cameron Norman

Re: stop posting useless cruft and get to work (systemd and Linux are *fundamentally incompatible* - and I can prove it)

[Cameron Norman]

El Wed, 26 de Mar 2014 a las 9:03 PM, gustavo panizzo gfa 
g...@zumbi.com.ar escribió:

On 03/26/2014 11:49 PM, Cameron Norman wrote:
I wonder if dbus activation
 could be used to accomplish this. Of course, then one would not be 
able
 to put (in the case of Upstart) the socket bridge, dbus bridge, 
dbus, or
 anything those services need to boot into a cgroup, but one can 
still
 put stuff like Apache, lightdm/gdm/kdm/sddm, nginx, et al into a 
cgroup.

 Another option is to push the kernel maintainers to allow delegating
 parts of the cgroups tree to other processes, so that the init 
system
 could say you get a sub-hierarchy, you get a sub-hierarchy 
without the
 complication of multiple separate hierarchies. How do you suggest 
this

 integration with cgroups be done?


i just want to put services inside cgroups, no socket activation, no
dbus, no dbus activation.



Haha. The problem there is that cgmanager uses dbus! So you need dbus 
installed + started before you can use cgroups with later kernels.


i would use it for servers, apache and friends, what i would really 
like
is to be able to run multiple instances of the same service each on 
it's

own cgroup.

something like

su - user -g cgroup_name -c command or a flag to start-stop-daemon,
cgroups could be created in advance by an init script (a 
Required-Start

in lsb slang)



I think cgexec is what you are looking for here. This would break with 
later versions of the linux kernel, though, because you need one 
centralized writer (e.g. cgmanager or systemd).


--
Cameron Norman

Re: systemd and Linux are *fundamentally incompatible* - and I can prove it

[Cameron Norman]

El Mon, 24 de Mar 2014 a las 9:42 AM, Kevin Toppins 
kevin.topp...@gmail.com escribió:

To all debian developers:


- systemd is *fundamentally incompatible* with linux


Now, I realize that's a bold claim, but if you are up for some 
reading, I will prove it.




I'll bite.


I even went to Lennart Poettering's google+ page and 

 - tried to warn everyone there that systemd was headed for failure

 - asked *Poettering* (in a different way) if he *could answer* what 
role systemd was to serve in linux



I said - I have a question for you. If you can answer it with one, 
and ONLY one, concept that describes fully what systemd is I will 
consider I might have misjudged this.


He replied...

 - systemd is a suite of basic building blocks to build an OS from



Maybe he was talking about the systemd project as a whole. systemd's 
source tree includes a number of different pieces of software, from 
udev to networkd. They are the basic building blocks. I will talk about 
systemd, the init system, specifically. This includes the journal 
(because it is mandatory and cannot be used without systemd) and the 
systemd binary, but not logind, udev, or anything else.


systemd starts, supervises, controls, and stops software according to 
dependencies, state, events, and chronology.


* start: simple execution, with optional environment and pre-created 
sockets. Decides to start when certain events occur (including device, 
socket, and bus events) or it is wanted by a starting unit, its own 
wants and dependencies are satisfied, its own conditions are true, and 
the moment is right (chronology is correct).

* supervise: monitors the process and optionally restarts it on failure.
* control: allows resource limits with cgroups, oom, nice, rlimit, and 
probably more. Hooks up its stdin/out/err.
* stop: stops the process and, optionally, that process's children 
(uses cgroups for this).


See the documentation for the following if they are not familiar to you:
* dependencies: Wants/WantedBy, Requires/RequiredBy (in 
man::systemd.unit)
* states: ConditionFileExists, ConditionFileExecutable, Condition* 
(probably in man::systemd.service)
* events: man::systemd.device, man::systemd.socket, 
Alias=dbus-org.foo.bar.service (in man::systemd.install)

* chronology: Before, After (probably in man::systemd.service)

I have heard you question why systemd recommends daemons to not 
fork/double fork. This is a pretty simple answer: it is costly and 
unnecessary, and systemd has less. To fork or daemonize is needless 
computation power that systemd does not require to be notified of the 
process's readiness. Furthermore, this makes it harder to supervise 
(track the PID and collect the stdout/err) the process. Lastly, it is a 
fair bit of unnecessary code on the daemon's part.


Any other questions?
--
Cameron Norman

Re: systemd and Linux are *fundamentally incompatible* - and I can prove it

[Cameron Norman]

El Tue, 25 de Mar 2014 a las 3:11 PM, Cameron Norman 
camerontnor...@gmail.com escribió:
See the documentation for the following if they are not familiar to 
you:
* dependencies: Wants/WantedBy, Requires/RequiredBy (in 
man::systemd.unit)
* states: ConditionFileExists, ConditionFileExecutable, Condition* 
(probably in man::systemd.service)
* events: man::systemd.device, man::systemd.socket, 
Alias=dbus-org.foo.bar.service (in man::systemd.install)

* chronology: Before, After (probably in man::systemd.service)



Sorry, pretty much all of that except the device and socket stuff is in 
systemd.unit.

Re: Preparing openjpeg 2.0

[Cameron Norman]

On Mon, Mar 24, 2014 at 4:38 AM, Mathieu Malaterre ma...@debian.org wrote:


   Which way should I go:

 1. Upload a src:openjpeg1 which will contains the legacy openjpeg 1.x
 branch and src:openjepg will get openjpeg 2.x or
 2. Upload a new src:openjpeg2 with the goal to get rid of src:openjpeg
 in a couple of debian release.


The former has the problem of people depending on openjpeg already and
using the 1.x API. Having a new package for the v2 API is better because
people have to explicitly use the new package+API, and they do not
experience sudden breakage.
--
Cameron Norman

Re: CUPS is now linked against OpenSSL

[Cameron Norman]

El sáb, 11 de ene 2014 a las 10:41 , Russ Allbery r...@debian.org 
escribió:

Matthias Klumpp matth...@tenstral.net writes:


 Changing this would only mean that CUPS forks have the option to be
 distributed under GPLv3. I don't see a reason why Apple should be
 against this.

Apple appears to be against anything containing the phrase GPLv3, to 
the
extent that their employees were even forbidden from reading GCC 
mailing

lists once the project started considering GPLv3 patches.  Presumably
their lawyers freaked out about something in the license, possibly the
patent handling.



It seems like it was the tivo-ization stuff. They license a lot of 
their stuff under the Apache v2 license, so I do not think it is the 
patent provisions that frighten them.


--
Cameron Norman