Re: support for merged /usr in Debian

[Marc Haber]

On Sun, 17 Jan 2016 00:20:33 +0100, Michael Biebl 
wrote:
>Amen. I'm much happier how the last couple of releases were handled. The
>release team(s) did an outstanding job.
>And things like autoremovals are a god send.

I am not opposed to autoremovals. I am opposed to removing packages
and not letting them back in after the bugs were fixed just because we
can. We have never done this, and we shold not do that for stretch.

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

Re: support for merged /usr in Debian

[Neil Williams]

On Sun, 17 Jan 2016 09:07:56 +0100
Marc Haber  wrote:

> On Sun, 17 Jan 2016 00:20:33 +0100, Michael Biebl 
> wrote:
> >Amen. I'm much happier how the last couple of releases were handled.
> >The release team(s) did an outstanding job.
> >And things like autoremovals are a god send.  
> 
> I am not opposed to autoremovals. I am opposed to removing packages
> and not letting them back in after the bugs were fixed just because we
> can. We have never done this, and we shold not do that for stretch.

That is just an untruth, sorry.

At some point before the end of every freeze for every release, we have
*always* done this. It is inevitable. It may be (and preferably will
be) a short period at the very end of the freeze. It is stupid to allow
a package to migrate into what is to become stable the day before the
release - there must be *very* special reasons. Typically, the only
package that does that is debian-cd.

There *must* be a cut off, there has *always* been a cut-off. Whether
or not RC bugs are fixed, the package will not migrate unless the
release team decide that it should. Most of the way through the freeze
that is automatic. As it gets closer to the release, this stops
happening automatically. Anything else would mean we'd never actually
release at all. The lack of migration *into* the release at no point
precludes the need for the release team to remove a package from the
release, so there will always be a time at the end of the freeze where
removals cannot be undone, no matter the protests or complaints. At the
very end of the freeze, removals are no longer automatic but still
happen - after the point where return is possible. To be fair, the
release team don't take those decisions lightly but such removals have
happened for each of the releases with which I've been involved (back
to Lenny). None of the affected packages had any possibility of
returning into the release once removed and this was duly considered
as part of the removal. Sometimes, removal is simply the only way to
fix the bugs - the release can't wait forever or be held hostage to
buggy packages.

The reverse dependencies are considered too, it might be a fault in your
package but your package will still be removed from the release and
there will be situations where it will not be allowed to return.

This has been done for all releases, it will continue to be necessary
for stretch and subsequent releases. Automatic removal does not always
allow automatic return. Manual removal also does not always allow
return. Nothing guarantees that your package will be in the release,
diligence is required to keep up with email and bug reports, right up
until the last steps of the release.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpzTpNsrKaLV.pgp
Description: OpenPGP digital signature

Communicating about the change in behaviour for ar

[Manoj Srivastava]

Hi,

I was trying to import the new version of make into unstable, and
 I discovered that t/10 tests about the archive related part of makes
 test suite failed. The reason was a change in the behaviour of ar,
 which is now configured with --enable-deterministic-archives. When
 adding files and the archive index use zero for UIDs, GIDs, timestamps,
 and use consistent file modes for all files.  When this option is used,
 if ar is used with identical options and identical input files,
 multiple runs will create identical output files regardless of the
 input files' owners, groups, file modes, or modification times. This
 seems like good news for reproducible builds.

Unfortunately, when using makes libxx(*.a) syntax for creating
 archives, make needs the timestamp of the file in order to decide to
 update it or not. With the current deterministic behavior of ar, the
 timestamp is always 0. This is behaviour that is not backwards
 compatible (as can be seen in the bug report #798804 and
 #798913). Some operations, instead of being no-ops, now rebuild theg/Lunar
 archive.

T think the change, because of the benefits of the
 reproducible builds, are a good thing, but I also think that they are
 not visible to the general user base (not all the users of ar and make
 are debian developers, and the release is not the only thing built
 using ar and make).  My recommendations is a NEWS file entry for
 binutils and make; and a mention in the release announcement for
 reproducible builds.

I have uploaded a version of make the defaults to adding U to the
 ARFLAGS, but, on research and reflection, I would be open to reverting
 that and adding a NEWS entry.

Manoj
-- 
Anything worth doing is worth overdoing.
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C

Re: support for merged /usr in Debian

[Tollef Fog Heen]

]] Marc Haber 

> We have never done this, and we shold not do that for stretch.

>From https://release.debian.org/jessie/freeze_policy.html:

After the 5th of February 2015, we will not allow packages to
re-enter testing if they are removed.

>From https://release.debian.org/wheezy/freeze_policy.html:

Rule #8. If your package has been removed recently (i.e. in the last
20 days) due to an RC bug, and you have an bugfix-only update
uploaded, you can contact the release team about letting your
package back in. Same as above: Do not expect us to find it out
ourselves. You need to push that.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: support for merged /usr in Debian

[Marc Haber]

On Sun, 17 Jan 2016 08:39:02 +, Neil Williams
 wrote:
>On Sun, 17 Jan 2016 09:07:56 +0100
>Marc Haber  wrote:
>
>> On Sun, 17 Jan 2016 00:20:33 +0100, Michael Biebl 
>> wrote:
>> >Amen. I'm much happier how the last couple of releases were handled.
>> >The release team(s) did an outstanding job.
>> >And things like autoremovals are a god send.  
>> 
>> I am not opposed to autoremovals. I am opposed to removing packages
>> and not letting them back in after the bugs were fixed just because we
>> can. We have never done this, and we shold not do that for stretch.
>
>That is just an untruth, sorry.
>
>At some point before the end of every freeze for every release, we have
>*always* done this. It is inevitable. It may be (and preferably will
>be) a short period at the very end of the freeze.

Of course. What I have understood is that this will be general freeze
policy from the beginning for stretch. I might have misunderstood in
the talk, and I didn't find a general freeze policy document to read
up on this yet.

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

Re: Removing sysV init files

[Alec Leamas]

Hi!

Thansk for long reply!

On 17/01/16 03:23, Jonathan de Boyne Pollard wrote:

Michael Biebl:


I wonder if nosh could be an option for non-linux. According to its
website it supports native systemd service files.



This caught my eye, so I thought that I'd demonstrate.  Before getting
to what I did, let's clear up some tangential points.




What resulted was a service that didn't start.  Hence "almost".

JdeBP /tmp $ svstat /tmp/lircd
/tmp/lircd: stopped since 2016-01-16 23:06:12 +; 2m 1s ago. , initially 
started
JdeBP /tmp $

It didn't start because the service unit was wrong.

A quick check of the log revealed that the service was trying to create
a local-domain socket at |/run/lirc/lircd| . But there was no
|/run/lirc/| directory on my system to contain that.


Now, the systemd scripts are the upstream ones, and they are used in 
several distributions. Hence, statements like "they are wrong"  in the 
sense that services doesn't start should be taken with some grain of 
salt. In this case, it seems like the nosh utility doesn't use the 
systemd tmfiles.d mechanisms which is the way to create temporary files 
and directories in the systemd world. However, this is not in the 
scripts, and should not be - it's in the rules file.


That said, there is always place for improvements. I'll answer to the 
other issues in a new thread, stay tuned.



There have been three System 5 rc scripts since May 2014; precisely so that 
there is a correspondence between service names, according to the commentary.

From a Debian point of view, I suspect that the answer that you'll get from all 
of the Debian people who actually look into the situation is that if Debian 
Maintainer Stefan Lippers-Hollmann is willing to continue doing this work to 
maintain System 5 rc scripts for your software, you should let xem.  (-:



The basic question is basically already answered: we all agree that the 
systemd scripts should be maintained and reasonable patches accepted.


That said, I have sent a question to Stefan about his role here: is the 
maintainer? If so, what is his plans? However, I still havn't got any 
reply on this.


Despite original address fields I'm not cross-posting.


Cheers!

--alec

Re: support for merged /usr in Debian

[Marc Haber]

On Sat, 16 Jan 2016 20:24:34 +0100, Vincent Bernat 
wrote:
> ? 16 janvier 2016 17:37 +0100, Marc Haber  :
>
>>>You seem to always take vague examples to avoid being contradicted. You
>>>can execute any unit before and after network is setup through the
>>>dependency system.
>>
>> Show me how to set a certain option to a VLAN interface that is
>> created by /etc/systemd/network/foo.netdev and needs to be set before
>> the interface is taken "up" by /etc/systemd/network/foo.network. Both
>> unit files are processed by the same systemd-networkd.service with no
>> hook in between.
>
>#v+
>[Service]
>Type=oneshot
>ExecStart=/usr/bin/ip a l
>RemainAfterExit=yes
>
>[Install]
>WantedBy=multi-user.target
>
>[Unit]
>Description=Enable some unknown IPv6 feature now
>After=sys-subsystem-net-devices-vlan1.device
>Requires=sys-subsystem-net-devices-vlan1.device
>Before=sys-devices-virtual-net-vlan1.device
>Conflicts=sys-devices-virtual-net-vlan1.device
>#v-

Judging from man systemd.device, a .device file has something to do
with udev. A vlan device is not created by udev, it comes into
existence when a .netdev unit like 

|[1/501]mh@barrida:~$ cat /etc/systemd/network/int182.netdev 
|[NetDev]
|Name=int182
|Kind=vlan  
 
|   
 
|[VLAN] 
 
|Id=182 
 
|[2/502]mh@barrida:~$

is brought up. After the corresponding .network file:

|[2/502]mh@barrida:~$ cat /etc/systemd/network/int182.network
|[Match]
 
|Name=int182
 
|   
 
|[Network]  
 
|Description=int182 secure  
 
|DHCP=none  
 
|IPForward=yes  
 
|   
 
|[Address]  
 
|Address=192.168.182.254/24 
 
|   
 
|[Address]  
 
|Address=2a01:238:4071:3282::a3:100/64  
 
|
|[snip]
|
|[3/503]mh@barrida:~$ 

has been brought up, /proc/sys/net/ipv6/conf/int182/* options cannot
be set any more since the interface is already up. 

systemd upstrem acknowledged this issue by implementing, for example,
the IPv6AcceptRouterAdvertisements option. Unfortunately, because
systemd does not allow run-time extensions, one has to go this way
again and again and wait for a release of both systemd upstream and
the distribution when one needs other options such as the
accept_ra_from_local value.

>Of course, vlan1 is up because with networkd, configuring the "netdev" makes
>it up while in Debian, setting the IP makes it up. However, I don't see
>you whining about the lack of flexibility in Debian where you cannot
>execute a command when the interface is up but before it gets an IP.

Because ifupdown has pre-up and up options in /e/n/i and hooks for
scripts.

Btw, the word "whine" is offensive. Please cut that out.

>> People in the systemd community are asking us to not use
>> EnvironmentFile or otherwise Lennart might feel forced to remove it
>> since we're all using it wrong.
>>
>> This is what gets me absolutely furious.
>
>Already debunked here:
> https://lists.debian.org/debian-devel/2016/01/msg00384.html
>
>Also:
> https://lists.debian.org/debian-devel/2016/01/msg00075.html

Please note what prompted my outburst, and guess whose opinion gets
endorsed by systemd upstream.

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

Re: support for merged /usr in Debian

[Neil Williams]

On Sun, 17 Jan 2016 10:21:15 +0100
Marc Haber  wrote:

> On Sun, 17 Jan 2016 08:39:02 +, Neil Williams
>  wrote:
> >On Sun, 17 Jan 2016 09:07:56 +0100
> >Marc Haber  wrote:
> >  
> >> On Sun, 17 Jan 2016 00:20:33 +0100, Michael Biebl
> >>  wrote:  
> >> >Amen. I'm much happier how the last couple of releases were
> >> >handled. The release team(s) did an outstanding job.
> >> >And things like autoremovals are a god send.
> >> 
> >> I am not opposed to autoremovals. I am opposed to removing packages
> >> and not letting them back in after the bugs were fixed just
> >> because we can. We have never done this, and we shold not do that
> >> for stretch.  
> >
> >That is just an untruth, sorry.
> >
> >At some point before the end of every freeze for every release, we
> >have *always* done this. It is inevitable. It may be (and preferably
> >will be) a short period at the very end of the freeze.  
> 
> Of course. What I have understood is that this will be general freeze
> policy from the beginning for stretch. I might have misunderstood in
> the talk, and I didn't find a general freeze policy document to read
> up on this yet.

Then the only reasonable basis is to use the past freeze policies, as
linked by Tollef, as the reference for the talk. I fail to see why
there is so much fuss over this, there will always be a time when
autoremovals are not let back in and that time has proven to be fairly
consistent in length over previous releases. It allows the release team
to sort out the more complex issues, it allows time for DI to finalise
and a raft of other essential tasks.

If the total freeze period is shortened, as so many people want, the
proportion of time taken up by this portion of the freeze process is
likely to increase. So, therefore, it is right to remind people that a
short freeze means that it is *more* likely that any one specific
package is going to be affected by a removal which cannot be undone. A
shorter timeframe for the release as a whole means that the ban on
packages returning, RC bug fixes or not, becomes more noticeable and
needs to be applied more overtly than before. The earlier that starts,
the shorter the release process can become (although there is an
element of diminishing returns as the release itself takes a finite
amount of time and the archive keeps getting larger).

Once upon a time, this removal process was manual and only done at the
"soft" start of the freeze but it still continued after the point where
returns were possible. We're permanently in that "soft" freeze by
using automated removals, so the real freeze (where removed
packages are unable to return) looks more severe. This "soft" freeze
then isn't part of the freeze policy for stretch, it's already in place.

The freeze itself becomes a period of time when automatic returns are
initially slowed (only packages already in the queue), then restricted
to RC fixes only (where most of the freeze time gets used up), then
banned. Manual migrations to return removed packages stop at some point
too. At another point, automated removals stop but manual removals
continue - possibly right up until the very final steps of the release.
Hence, removals (manual and automatic) will happen when there is no
prospect of return. All the talk was doing was highlighting that this
process will continue but will appear more prominently in a shorter
total freeze. It may also affect more packages as the archive continues
to grow. That is just mathematics, it is inevitable.

We still release "when it's ready" but due to the size of the archive,
there must be a threshold where the release team can decide that x
percent of the archive being ready is enough, so that the release is
not held hostage to particular packages. The value of x hasn't been 100
for a long time. Reality means that volunteers need to allocate time to
do the release tasks, so a date needs to be set when people are
available but the date isn't set until after the release team decide
that the threshold has been met.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp5_L3VAPKmf.pgp
Description: OpenPGP digital signature

Re: support for merged /usr in Debian

[Marc Haber]

On Sun, 17 Jan 2016 11:25:50 +0100, Marc Haber
 wrote:
>Judging from man systemd.device, a .device file has something to do
>with udev. A vlan device is not created by udev, it comes into
>existence when a .netdev unit like 
>
>|[1/501]mh@barrida:~$ cat /etc/systemd/network/int182.netdev 
>|[NetDev]
>|Name=int182
>|Kind=vlan 
>  
>|  
>  
>|[VLAN]
>  
>|Id=182
>  
>|[2/502]mh@barrida:~$
>
>is brought up.

I forgot to give the eth0.network, which brings the connection between
VLAN device and physical device:

|[1/501]mh@barrida:~$ cat /etc/systemd/network/eth0.network 
|[Match]
 
|Name=eth0  
 
|   
 
|[Network]  
 
|VLAN=int181
 
|   
 
|[Network]  
 
|VLAN=int182
 
|   
 
|[Network]  
 
|VLAN=int183
 

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

Re: Communicating about the change in behaviour for ar

[Jérémy Bobbio]

Manoj Srivastava:
> I was trying to import the new version of make into unstable, and
>  I discovered that t/10 tests about the archive related part of makes
>  test suite failed. The reason was a change in the behaviour of ar,
>  which is now configured with --enable-deterministic-archives. When
>  adding files and the archive index use zero for UIDs, GIDs, timestamps,
>  and use consistent file modes for all files.  When this option is used,
>  if ar is used with identical options and identical input files,
>  multiple runs will create identical output files regardless of the
>  input files' owners, groups, file modes, or modification times. This
>  seems like good news for reproducible builds.
> 
> Unfortunately, when using makes libxx(*.a) syntax for creating
>  archives, make needs the timestamp of the file in order to decide to
>  update it or not. With the current deterministic behavior of ar, the
>  timestamp is always 0. This is behaviour that is not backwards
>  compatible (as can be seen in the bug report #798804 and
>  #798913). Some operations, instead of being no-ops, now rebuild theg/Lunar
>  archive.
> 
> T think the change, because of the benefits of the
>  reproducible builds, are a good thing, but I also think that they are
>  not visible to the general user base (not all the users of ar and make
>  are debian developers, and the release is not the only thing built
>  using ar and make).  My recommendations is a NEWS file entry for
>  binutils and make; and a mention in the release announcement for
>  reproducible builds.
> 
> I have uploaded a version of make the defaults to adding U to the
>  ARFLAGS, but, on research and reflection, I would be open to reverting
>  that and adding a NEWS entry.

In any case, I think we should communicate to users that something
unexpected (from the point view of make) is happening so they can adapt
their Makefile. What would you think of the attached patch series?

The warning is actually implemented in the second patch, but the first
one is required to be able to differentiate a non-existent archive or
member from a member with a timestamp set to 0.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   
From a40d198fb5a3a0387ce5b4f0f40e23cab2a535bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= 
Date: Sun, 17 Jan 2016 10:55:40 +
Subject: [PATCH 1/2] Make ar_member_date compatible with archives with
 timestamps set to 0

ar_scan() scanning function uses 0 to indicate that scanning should continue.
This made ar_member_date() unable to differentiate when it was unable to find
the requested member from a member with a timestamp set to 0.

We thus change its prototype to have its return value indicate if it has been
able to find the requested member. The timestamp is set through the newly given
pointer.
---
 ar.c   | 33 +
 commands.c |  5 -
 dir.c  |  7 +--
 makeint.h  |  2 +-
 remake.c   |  7 +++
 5 files changed, 38 insertions(+), 16 deletions(-)

diff --git a/ar.c b/ar.c
index 675572a..d10a8df 100644
--- a/ar.c
+++ b/ar.c
@@ -68,25 +68,39 @@ ar_parse_name (const char *name, char **arname_p, char **memname_p)
 
 /* This function is called by 'ar_scan' to find which member to look at.  */
 
+struct member_date_lookup
+{
+  const char *name;
+  time_t *member_date;
+};
+
 /* ARGSUSED */
 static long int
 ar_member_date_1 (int desc UNUSED, const char *mem, int truncated,
   long int hdrpos UNUSED, long int datapos UNUSED,
   long int size UNUSED, long int date,
   int uid UNUSED, int gid UNUSED, int mode UNUSED,
-  const void *name)
+  const void *data)
 {
-  return ar_name_equal (name, mem, truncated) ? date : 0;
+  const struct member_date_lookup *lookup_data = data;
+  if (ar_name_equal (lookup_data->name, mem, truncated))
+{
+  *lookup_data->member_date = date;
+  return 1;
+}
+  return 0;
 }
 
-/* Return the modtime of NAME.  */
+/* Read the modtime of NAME in MEMBER_DATE.
+   Returns 1 if NAME exists, 0 otherwise.  */
 
-time_t
-ar_member_date (const char *name)
+int
+ar_member_date (const char *name, time_t *member_date)
 {
   char *arname;
   char *memname;
-  long int val;
+  int found;
+  struct member_date_lookup lookup_data;
 
   ar_parse_name (name, &arname, &memname);
 
@@ -107,11 +121,14 @@ ar_member_date (const char *name)
   (void) f_mtime (arfile, 0);
   }
 
-  val = ar_scan (arname, ar_member_date_1, memname);
+  lookup_data.name = memname;
+  lookup_data.member_date = member_date;
+  found = ar_scan (arname, ar_member_date_1, &lookup_data);
 
   free (arname);
 
-  return (val <= 0 ? (time_t) -1 : (time_t) val);
+  /* return 0 (not found) if the archive does not exist or has inva

Re: support for merged /usr in Debian

[Vincent Bernat]

 ❦ 17 janvier 2016 11:25 +0100, Marc Haber  :

>>Of course, vlan1 is up because with networkd, configuring the "netdev" makes
>>it up while in Debian, setting the IP makes it up. However, I don't see
>>you whining about the lack of flexibility in Debian where you cannot
>>execute a command when the interface is up but before it gets an IP.
>
> Because ifupdown has pre-up and up options in /e/n/i and hooks for
> scripts.

ifupdown doesn't give a hook for executing something after putting the
interface up and before setting an IP address. This can be useful to
check if we are plugged to the right switch port or to wait for the STP
state of the remote switch to be "forwarding". That's a different kind
of limitation.

networkd puts the interface up when creating it. It introduces an
unfortunate limitation, just workaround it with an unit file. You'll
have to accept at some point that upstream wants networkd to only cover
the most common use cases and that for more complex setups, you have
other solutions (like ifupdown, network manager or manual unit files).

> Btw, the word "whine" is offensive. Please cut that out.

What's the proper english verb for someone who complains everytime in a
negative way? Maybe "rant" would be more appropriate.

>>> People in the systemd community are asking us to not use
>>> EnvironmentFile or otherwise Lennart might feel forced to remove it
>>> since we're all using it wrong.
>>>
>>> This is what gets me absolutely furious.
>>
>>Already debunked here:
>> https://lists.debian.org/debian-devel/2016/01/msg00384.html
>>
>>Also:
>> https://lists.debian.org/debian-devel/2016/01/msg00075.html
>
> Please note what prompted my outburst, and guess whose opinion gets
> endorsed by systemd upstream.

I don't know what you mean. But I can understand that upstream prefers
to endorse opinion of people who engage in constructive discussions
instead of "ranting".
-- 
Familiarity breeds contempt -- and children.
-- Mark Twain


signature.asc
Description: PGP signature

lirc systemd packaging (Was: Removing sysV init files)

[Alec Leamas]

On 17/01/16 03:23, Jonathan de Boyne Pollard wrote:
> Michael Biebl:
>
>> I wonder if nosh could be an option for non-linux. According to its
>> website it supports native systemd service files. I have to admit
>> though, I never looked at nosh myself, so I have no idea how far that
>> "systemd support" goes.
>
> This caught my eye, so I thought that I'd demonstrate.  Before  getting
> to what I did, let's clear up some tangential points.
>
> Alec Leamas:
>
>> The systemd setup [for lirc] is three different services, the sysV
>> [setup] one. There is no systemd service directly corresponding to the
>> sysV one.
>
> The Debian revision log says that that's not in fact true.
>
> http://anonscm.debian.org/viewvc/pkg-lirc?view=revision&revision=521
>
> There have been three System 5 rc scripts since May 2014; precisely so
> that there *is* a correspondence between service names, according to the
> commentary.
>
>  From a Debian point of view, I suspect that the answer that you'll get
> from all of the Debian people who actually look into the situation is
> that if Debian Maintainer Stefan Lippers-Hollmann is willing to continue
> doing this work to maintain System 5 rc scripts for your software, you
> should let xem.  (-:

OK, here is two things both covered in my reply in original thread:
- Stefan's role. A statement from him on this would be good.
- We should incorporate reasonable sysV patches including those in 
current svn tree in upcoming update, agreed.


> I suggest that you should probably pay more attention to the System 5 rc
> scripts, because your systemd units aren't up to scratch and don't do as
> good a job.  I discovered this by running your |lircd.socket| and
> |lircd.service| unit files through the nosh conversion process and
> seeing what resulted.  Your "bad gut feeling" about your System 5 rc
> files is, ironically, misplaced and should be about your systemd 
mechanisms.


There is certainly two possibilities here: that the systemd scripts are 
wrong, or that the nosh utility fails. I presume that if the scripts 
actually works in the sense that they start the services (which they do) 
we need to take a look at nosh, right?


> Yes the nosh package can take this sort of thing
[snip]


> What resulted was a service that didn't start.  Hence "almost".
>
> JdeBP /tmp $ svstat /tmp/lircd
> /tmp/lircd: stopped since 2016-01-16 23:06:12 +; 2m 1s ago. , 
initially started

> JdeBP /tmp $
>
> It didn't start because the service unit was wrong.

No, it's because nosh fails.

> A quick check of the log revealed that the service was trying to create
> a local-domain socket at |/run/lirc/lircd| . But there was no
> |/run/lirc/| directory on my system to contain that.  Your systemd units
> didn't make one; and one doesn't appear by telepathy.  (-:  Stefan
> Lippers-Hollmann's System 5 rc scripts *do* make this directory,

As I stated in previous reply, temporary files are created using the 
tmpfiles.d mechanism (where the .service/.socket files isn't involved in 
any way).


[upstream hat on] If it would make things easier, we could of course use 
other mechanisms as long as they works if it makes nosh's task easier. 
Patches (upstream!) welcome!


> however.  They have this near the start:
>
> [ -d "/run/lirc" ] || mkdir -p "/run/lirc"
>
> The systemd service unit file way of doing the same thing is:
>
> [Service]
> RuntimeDirectory=lirc

Well, it's a possibility. However, the lirc packaging uses tmpfiles.d.

> So I edited that into your |lircd.service| and had another go.  This
> time I was hit by a problem with "quirks mode" conversion (which I don't
> use all that often).  Since your |lircd| program doesn't actually rely
> upon any systemd quirks as far as I can see, I simply switched to "ideal
> mode" conversion and converted a third time:
>
> JdeBP /tmp $ convert-systemd-units --no-systemd-quirks ./lircd.socket
> JdeBP /tmp $ sudo system-control start /tmp/lircd

Sorry, I don't follow you here. What are these quirks, is it something 
to be used, and then why?


> Now I was hit by the fact that you'd hardwired the pathname
> |/usr/sbin/lircd| into your service unit.  This isn't wrong from a Linux
> systemd operating system perspective.  But I'm doing this on FreeBSD
> (PC-BSD 10.2, in fact) to demonstrate that the nosh toolset very much
> does provide the tools for non-Linux operating systems.  The
> FreeBSD-supplied lircd installs into |/usr/local/sbin |not |/usr/sbin|,
> because that's the rule for non-operating-system stuff.  Fortunately,
> there are at least two ways around this.  I took the one that uses
> |$PATH|. The conversion tool can be told |ExecStart=lircd| and that will
> make a service bundle that will just work for either |/usr/sbin/lircd|
> or |/usr/local/sbin/lircd| .  So I edited that into your |lircd.service|


OK. Isn't this just one of those things we do from time to time when 
packaging stuff?


[upstream hat on] I'd certainly accept a

Re: Removing sysV init files

[Jonathan de Boyne Pollard]

Jonathan de Boyne Pollard:


It didn't start because the service unit was wrong.

A quick check of the log revealed that the service was trying to 
create a local-domain socket at |/run/lirc/lircd| .  But there was no 
|/run/lirc/| directory on my system to contain that.  Your systemd 
units didn't make one; and one doesn't appear by telepathy.  (-:  
Stefan Lippers-Hollmann's System 5 rc scripts *do* make this 
directory, however. [...]



Alec Leamas:

Now, the systemd scripts are the upstream ones, and they are used in 
several distributions. Hence, statements like "they are wrong" in the 
sense that services doesn't start should be taken with some grain of 
salt.  In this case, it seems like the nosh utility doesn't use the 
systemd tmfiles.d mechanisms which is the way to create temporary 
files and directories in the systemd world.


I'd have used that if I'd found one.  I looked, as that's the other way 
of doing this instead of the |RuntimeDirectory| setting.  There's *is 
no* tmpfiles snippet in your source tree, that I could find.  Your 
|/systemd/| subdirectory (at 
http://sourceforge.net/p/lirc/git/ci/master/tree/systemd/) contains only 
unit files, notice; and there's nothing elsewhere that I could find.   
So yes: your service unit files are wrong, or your source tree that you 
give to the world is incomplete.  You don't provide complete 
configuration for a functional system.


Also note that Lennart Poettering would like you to use 
|RuntimeDirectory| for this in preference to tmpfiles snippets, and have 
your program do that in preference to either, since you are configuring 
it to run as the superuser.  So there's an argument, at least from the 
systemd people, that /your daemon//program/ is incomplete.


   http://lists.freedesktop.org/archives/systemd-devel/2013-July/012024.html

I did enjoy the Mouse Trap nature of your lircd-setup service, that I 
looked at when looking for where you could be hiding your creation of 
the |/run/lirc/| directory.  Your lircd service unit pulls in another 
oneshot service unit that in turn invokes a Python program 
(http://sourceforge.net/p/lirc/git/ci/master/tree/tools/lircd-setup), 
which then reads a configuration file for a string, that it in turn 
passes to the POSIX-compatible shell for execution as an arbitrary shell 
command (with superuser privileges, of course). There's definitely a 
middle man to be cut out, there.  Learn from the mistakes in the systemd 
House of Horror.  (-:


   
http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/systemd-house-of-horror/

Alec Leamas:

That said, I have sent a question to Stefan about his role here: is 
the maintainer? If so, what is his plans? However, I still havn't got 
any reply on this.



You can actually look the answer to the first question up for yourself:

   https://packages.debian.org/source/sid/lirc

That's how I knew that xe was one of the maintainers.  (-:

Re: support for merged /usr in Debian

[Marc Haber]

On Sun, 17 Jan 2016 12:29:42 +0100, Vincent Bernat 
wrote:
> ? 17 janvier 2016 11:25 +0100, Marc Haber  :
>>>Of course, vlan1 is up because with networkd, configuring the "netdev" makes
>>>it up while in Debian, setting the IP makes it up. However, I don't see
>>>you whining about the lack of flexibility in Debian where you cannot
>>>execute a command when the interface is up but before it gets an IP.
>>
>> Because ifupdown has pre-up and up options in /e/n/i and hooks for
>> scripts.
>
>ifupdown doesn't give a hook for executing something after putting the
>interface up and before setting an IP address. This can be useful to
>check if we are plugged to the right switch port or to wait for the STP
>state of the remote switch to be "forwarding". That's a different kind
>of limitation.

Anyway, ifupdown used to be a lot more flexible than networkd is
today. networkd is still the better solution.

>networkd puts the interface up when creating it. It introduces an
>unfortunate limitation, just workaround it with an unit file. You'll
>have to accept at some point that upstream wants networkd to only cover
>the most common use cases and that for more complex setups, you have
>other solutions (like ifupdown, network manager or manual unit files).

networkd's feature set is celearly made for servers, otherwise it
would not support bonding, VLANs and bridging, hardly part of the
"most common use cases". IPv6 is much more common than bonding, for
example.

Networkd is just plagued by upstream's aversion against giving people
a choice and is hence missing an interface for local extensions. I
hate the idea of having to go through the same motions again and again
for every setting that the kernel people decided to expose. The kernel
community is so much easier to work with.

>> Btw, the word "whine" is offensive. Please cut that out.
>
>What's the proper english verb for someone who complains everytime in a
>negative way? Maybe "rant" would be more appropriate.

How about "complain"?

 People in the systemd community are asking us to not use
 EnvironmentFile or otherwise Lennart might feel forced to remove it
 since we're all using it wrong.

 This is what gets me absolutely furious.
>>>
>>>Already debunked here:
>>> https://lists.debian.org/debian-devel/2016/01/msg00384.html
>>>
>>>Also:
>>> https://lists.debian.org/debian-devel/2016/01/msg00075.html
>>
>> Please note what prompted my outburst, and guess whose opinion gets
>> endorsed by systemd upstream.
>
>I don't know what you mean. But I can understand that upstream prefers
>to endorse opinion of people who engage in constructive discussions
>instead of "ranting".

One can discuss constructiveness. The discussion was like:

Harald: "Please extend the EnvironmentFile syntax, I'd like to use it
in a slightly different way for my use case"
systemd upstream: "You're using it wrong. I should never have
implemented it."
systemd fanboi: "Let's remove it then!"
Harald: "No, I'm using it."
systemd fanboi: "You're using it wrong, systemd upstream said. Please
don't force systemd upstream to remove the feature by still continuing
to use it the wrong way! It's much better to fix your outdated daemon
to have its own configuration file instead of relying on command line
options since it's work for systemd to pass them! And, btw, your whole
way of doing system administration is wrong, please change it to the
only right way that we documented as being the only right way two
weeks ago!"
Zugschlus: ""

That's not what I call "constructive". It's talking about destroying
existing and working setups instead of caring for user wishes.

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

Re: support for merged /usr in Debian

[Tom H]

On Sun, Jan 10, 2016 at 12:09 PM, Marc Haber
 wrote:
> On Sun, 10 Jan 2016 09:53:52 +0100, Tom H  wrote:
>>
>> Lennart didn't even say that he wanted to get rid of "EnvironmentFile=".
>>
>>> From the same-named thread on systemd-devel@:
>>
>> --- 8< ---
>> 1)
>> I probably should never have added EnvironmentFile= in the first place.
>>
>> 2)
>> I think EnvironmentFile= was a mistake, and I explained why. But then
>> again, I am not planning to remove it, and I never suggested that.
>> --- > 8 ---
>>
>> He advocated the use of drop-ins, as you (Philipp) do.
>
> Yes. But two of his militant fanbois suggested in the following that
> the option should be removed because of Lennarts reasoning. In the
> following, one of them said that if the option will be removed in the
> future, it would be "our" because "we" had been using the option
> "wrong" and have thus "forced lennart" to remove it since we refused
> to be "educated" about "proper" use of systemd.

Johann (I can't think of the other "fanboi" to whom you're referring)
has argued in the past for the removal of rc.local and sysvinit
compatibility. Let's assume that Lennart removes support for them as
well as for "EnvironmentFile=", will it really be something that'll be
worth getting upset about? I'm not trying to provoke you, I'm just
thinking it through.

For EnvironmentFile, does it really matter whether you edit a file
under "/etc/default/" or under "/etc/systemd/system/"? As I said
up-thread, I'm wouldn't like setting up nfs without "EnvironmentFile="
but it's something that'll just take a little longer initially,
whether I'm using config management or not. And then it'll be the
same, since I only change these files at setup.

For rc.local, does it really matter whether you edit "/etc/rc.local"
or a file under "/etc/systemd/system/"? Personally, even if I've used
rc.local when in a hurry, I've always made a point of creating a
sysvinit script, upstart job, or systemd service unit later. If the
rc.local support's removed, I might even create my own
"/etc/systemd/system/rc-local.service" to parse "/etc/rc.local" for
cases when I don't have the time to think through the dependencies of
a proper unit.

There's residual anger at systemd because it more or less snookered
distros and users into adopting it, but being angry at every little
change seems OTT, no matter how Lennart expresses his musts and
must-nots and his likes and dislikes.

Bug#811275: ITP: uclibc-ng -- uClibc-ng is an implementation of the standard C library that is much smaller than glibc, which makes it useful for embedded systems.

[Waldemar Brodkorb]

Package: wnpp
Severity: wishlist
Owner: Waldemar Brodkorb 

* Package name: uclibc-ng
  Version : 1.0.11
  Upstream Author : Waldemar Brodkorb 
* URL : http://www.uclibc-ng.org/
* License : LGPL
  Programming Lang: C
  Description : uClibc-ng is an implementation of the standard C library 
that is much smaller than glibc, which makes it useful for embedded systems.

uClibc-ng is a small C library for developing embedded Linux systems. It is
much smaller than the GNU C Library, but nearly all applications supported by
glibc also work perfectly with uClibc-ng.
uClibc-ng is a spin-off of uClibc (from Erik Andersen) from 
http://www.uclibc.org.

Re: lirc systemd packaging (Was: Removing sysV init files)

[Simon McVittie]

On 17/01/16 11:36, Alec Leamas wrote:
> On 17/01/16 03:23, Jonathan de Boyne Pollard wrote:
>> A quick check of the log revealed that the service was trying to create
>> a local-domain socket at |/run/lirc/lircd| . But there was no
>> |/run/lirc/| directory on my system to contain that.  Your systemd units
>> didn't make one
> 
> As I stated in previous reply, temporary files are created using the
> tmpfiles.d mechanism (where the .service/.socket files isn't involved in
> any way).

I'm not sure that nosh should claim to support systemd units if it
doesn't either support tmpfiles.d, or depend on a standalone
implementation of the tmpfiles.d "protocol" (that is guaranteed to be
run before systemd units with DefaultDependencies=yes). The tmpfiles.d
mechanism is rather simple, and the ability to assume that tmpfiles.d
entries are supported is one of the factors that contributes to systemd
units being simple and declarative.

S

Bug#811294: ITP: tabview -- curses command-line CSV and list (tabular data) viewer

[Yuri D'Elia]

Package: wnpp
Severity: wishlist
Owner: "Yuri D'Elia" 

* Package name: tabview
  Version : 1.4.1
  Upstream Author : Scott Hansen 
* URL : https://github.com/firecat53/tabview
* License : MIT
  Programming Lang: Python
  Description : curses command-line CSV and list (tabular data) viewer

tabview is both a minimal, stand-alone curses command-line CSV/tabular-data
viewer and a Python module that can be used to view basic Python types directly
in an interactive spreadsheet.

The curses interface offers VIM-like keyboard bindings, sorting and full-text
incremental search.

---

There are currently very few alternatives to tabview in debian. I've used "sc"
and "teapot" (not in Debian) to the same extent, however both are complete
spreadsheet programs (with sc requiring an extra "import" step), whereas
tabview allows to just view a csv/tsv file easily.

tabview is both helpful stand-alone, but also works greatly when used in
combination with ipython or any interactive python session, allowing one to
browse through a large data table visually. To this extent, I'm using tabview
heavily with the scipy stack.

I'm planning to maintain this package in the python-modules team.

Bug#811299: ITP: gtabview -- simple graphical tabular data viewer

[Yuri D'Elia]

Package: wnpp
Severity: wishlist
Owner: "Yuri D'Elia" 

* Package name: gtabview
  Version : 0.6
  Upstream Author : Yuri D'Elia 
* URL : https://github.com/wavexx/gtabview
* License : MIT
  Programming Lang: Python
  Description : simple graphical tabular data viewer

Simple graphical tabular data viewer that can be used both stand-alone and as a
Python module for various files and Python/Pandas/NumPy data structures.

---

There are currently very few alternatives to gtabview in debian. I've used "sc"
and "teapot" (not in Debian) to the same extent, however both are complete
spreadsheet programs (with sc requiring an extra "import" step), whereas
gtabview allows to just view a tabular text file easily.

I'm also packaging "tabview" (see ITP #811294), which is the curses analogue.

gtabview is both helpful stand-alone, but also works greatly when used in
combination with ipython or any interactive python session, allowing one to
browse through a large data table visually. To this extent, I'm using gtabview
heavily within emacs and the scipy stack.

I'm planning to maintain this package in the python-modules team.

Bug#811335: ITP: ruby-minitest-hooks -- Around and before/after hooks for Minitest

[Dmitry Borodaenko]

Package: wnpp
Severity: wishlist
Owner: Dmitry Borodaenko 

* Package name: ruby-minitest-hooks
  Version : 1.4.0
  Upstream Author : Jeremy Evans
* URL : http://github.com/jeremyevans/minitest-hooks
* License : MIT
  Programming Lang: Ruby
  Description : Around and before/after hooks for Minitest

minitest-hooks adds around and before_all/after_all/around_all hooks for
Minitest. This allows you do things like run each suite of specs inside
a database transaction, running each spec inside its own savepoint
inside that transaction, which can significantly speed up testing for
specs that share expensive database setup code.

---

This module is used in the tests of the newer versions of ruby-sequel.

I plan to maintain this package in Debian Ruby team.

-- 
Dmitry Borodaenko


signature.asc
Description: PGP signature

Bug#811337: ITP: ruby-minitest-shared-description -- Shared specs and shared spec subclasses for Minitest

[Dmitry Borodaenko]

Package: wnpp
Severity: wishlist
Owner: Dmitry Borodaenko 

* Package name: ruby-minitest-shared-description
  Version : 1.0.0
  Upstream Author : Jeremy Evans
* URL : http://github.com/jeremyevans/minitest-shared_description
* License : MIT
  Programming Lang: Ruby
  Description : Shared specs and shared spec subclasses for Minitest

Minitest supports shared specs by default using plain ruby modules, but
does not support shared spec subclasses. In addition to making it
possible to share subclasses, minitest-shared_desciption also provides a
slightly nicer interface for sharing specs.

---

This module is used in the tests of the newer versions of ruby-sequel.

I plan to maintain this package in Debian Ruby team.

-- 
Dmitry Borodaenko