Re: systemd-fsck?

[Marc Haber]

On Sat, 10 May 2014 17:49:46 +0100, Dimitri John Ledkov
 wrote:
>Users of sysvinit, are of two categories, those that "reverted to or
>wish to stay with sysvinit" or those that "simply use the default".
>It is desired to migrate "simply use the default" to the new default,
>systemd, if that is possible.

Users of sysvinit should IMO never be automatically converted.
Conversion to an init system that supports only a subset of the
features of sysvinit should always be a conscious decision of the
local admin since it might cause unexpected breakage.

Automatic conversion should only happen if the new package is a
feature-complete drop-in replacement of the old one. Systemd is not a
drop-in replacement.

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


--
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/e1wjnvi-0001lr...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sat, 10 May 2014 11:55:19 +0200, Matthias Urlichs
 wrote:
>Marc Haber:
>> Will it be the norm that the binaries replacing well-used shell
>> scripts on early boot only implement the features that Lennart deemed
>> useful? That would be a major turn-off, adding to the fact that early
>> boot will become undebuggable since one will not be able any more to
>> dump -x'es in shell scripts to see what's going on.
>
>This begs one question: Why would you want to?
>
>"systemctl status" tells you quite clearly what went wrong, "journalctl"
>shows you what the program printed in case it did get started … and so on.

If the system boots.

>If you manage not to get a login prompt, enable debug.service and you'll
>have a root shell on TTY 9. systemctl has even grown a --root argument,
>so you can do that to a mounted file system if you can't get even get an
>emergency prompt, or you can use it from the kernel command line.

I bet that there is something a vital debug option is missing. It is
virtually impossible to offer really complete debugging. -x is
agreeable a pain, but it shows _everything_ a script does, down to the
result of every subexpression in loop and decision constructs and
therefore offers the ultimate debugging.

>Sticking "-x" into scripts was a major PITA from the beginning. It grew
>even more pains as init-functions and colorful prompts came along, and I
>for one am VERY happy to finally get rid of that kind of "debugging".

I am always glad when I don't need to do it, but just having the
possibility of doing so makes things so much easier.

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


--
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/e1wjnyc-0001m5...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sat, 10 May 2014 15:28:34 +0200, Martin Steigerwald
 wrote:
>I did not make a technical statement about systemd. I understand the reasons 
>why Tech-CTTE chose it and while I am skeptical about the attitude of some 
>upstream and Debian developers regarding handling bug reports and feedback, I 
>am not generally opposed to it. I test drove it for some months some time ago, 
>before hibernation was broken when it is in use, and mostly enjoyed the test 
>drive.
>
>So please don´t use my feedback for any general anti systemd agenda. I am not 
>opposed to it. But it for it to be default certain criteria are not yet met. 
>In my eyes partly still open grave bugs and partly the handling or not 
>handling of them. I wish that systemd upstream developers and Debian packagers 
>adopt the "never break userspace" mantra of the kernel developers as "never 
>break applications and application oriented services and if you do take bug 
>reports seriously". Cause for me systemd is a system component. Yes, it lives 
>in otherspace, but it is so lowlevel that for me it is part of the system 
>which provides services to application (just like the kernel does).

+1  I could not have said that any better. Thanks Martin.

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


--
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/e1wjnb5-0001mt...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sat, 10 May 2014 18:00:02 +0200, Laurent Bigonville
 wrote:
>Le Sat, 10 May 2014 16:00:39 +0200,
>> Yet: I do think its about high time systemd developers and packagers
>> adopt an attitude of "never break userspace" like the kernel
>> developers do.
>
>Sure that the attitude "I don't care where the root cause of a problem
>lies", opening 3 different bugs against 3 different packages for the
>same issue and then complain publicly that the bug is not fixed is good
>and productive...
>
>May I remind you that everybody in Debian is working as a volunteer and
>that we have limited time and motivation and that this kind of
>continuous ranting is not helping.

Here is it again, the thought-terminating cliche of the volunteer. If
you voluntarily break things, you voluntarily fix them. If you don't
have time to fix your breakage, don't cause it.

>> The plain fact:
>> 
>> Using systemd breaks something that worked for probably a decade or
>> longer before however long that su is in that init script. So on what
>> account do you call calling "su" in an init script a bug? It may not
>> be the most elegant solution to do things, granted, but a bug? Come
>> on. Calling it a bug just cause systemd / policykit treat calling su
>> in an initscript as they do is quite arrogant in my eyes.
>
>IMVHO opening a PAM session in an initscript is a bad idea from day
>one, as you don't know which modules are being called, as it can create
>bogus audit trails or cause other subtile issues.

Just curious as the maintainer of another package using su in an init
script since 2001, how am I supposed to start a non-root process from
an init script?

>> Thats it.
>
>I personally think that systemd team (of which I'm NOT part) is already
>doing a really good work to fix integration issues, they are already
>providing patches or .services for main packages but they cannot fix
>everything.

No doubt they do, but in the few prominent cases they don't, they're
not helping their agenda by acting publicly the way they do. I really
like the idea of systemd and am happily willing to take the pain the
transition may cause, but I have already reached the state where I
refrain from bug reports against systemd because being told "go away"
in an impolite way is not good for my health.

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


--
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/e1wjnhr-0001p6...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sat, 10 May 2014 19:13:01 +0200, Matthias Urlichs
 wrote:
>Every compiler toolchain upgrade breaks a bunch of packages, sometimes in
>subtle ways, and mostly because the code was in some way non-standard.
>You don't complain about that, do you? So why is systemd different?

Because systemd breaks the system for users, not only for developers.

>Mind you, I am not defending the handling of this specific bug; certainly
>the systemd people's attitude is somewhat … let's call it abrasive …
>at times.

And this abrasive attitude is hurting. It's hurting systemd, it's
hurting users, it's hurting Debian and it's hurting open source.

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


--
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/e1wjnir-0001pi...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sat, 10 May 2014 20:57:28 +0100, Ben Hutchings
 wrote:
>On Sat, 2014-05-10 at 19:53 +0200, Jakub Wilk wrote:
>> * Matthias Urlichs , 2014-05-10, 19:13:
>> >Every compiler toolchain upgrade breaks a bunch of packages,
>> 
>> For end users? I don't think so.
>
>If a package is not changed to fix the FTBFS, then it will be removed
>from testing and will miss the next release.  The effect on end users is
>not immediate (package is still in stable and unstable) but there is
>breakage that other maintainers need to fix.

The effect is not immediate, yes. An unwanted change to systemd not
supporting a feature that it vital to booting non-trivial crypto disk
schemes is immediate on unstable users, and since systemd maintainers
do not consider this an RC bug, it wil make testing systems unbootable
in two weeks time.

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


--
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/e1wjnkx-0001pz...@swivel.zugschlus.de

Re: Avoiding system d

[Marc Haber]

On Sat, 10 May 2014 19:47:10 +0100, Brian 
wrote:
>On Sat 10 May 2014 at 12:05:25 -0400, John wrote:
>A couple of quotes from your mail:
>  > "I find myself appalled at the rude and domineering attitudes of
>  > almost all systemd's defenders."
>
>You're not looking for flames? You're kidding, aren't you? Your technical
>question is wrapped up in flame-baiting.

Sorry if that comes around at flame-baiting, but John describes the
way the systemd world socially interacts with its outside quite
accurately. It is the same for me: social interaction with systemd
(and this includes reading bug reports and mailing lists without
participating actively) takes fun out of using Linux for me just for
the social sake.

Something along the lines of systemd is technically needed and a good
idea, but the people behind it do not come along nice.

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


--
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/e1wjo1i-0001sj...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sat, 10 May 2014 22:13:01 +0200, Matthias Urlichs
 wrote:
>I also would not expect an "end user" to add "su foo -c /do/whatever" to
>/etc/rc.local. Your opinion may differ, that's OK.

Especially people who are not as Debian-centric as we are tend to do
exactly this. Simply because they don't know any better.

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


--
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/e1wjnlk-0001pj...@swivel.zugschlus.de

Re: correct use of su

[Marc Haber]

On Sat, 10 May 2014 23:11:10 -0700, Steve Langasek 
wrote:
>On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote:
>> The name "start-stop-daemon" would suggest this is inappropriate for cron
>> jobs, is that an invalid assumption I made?
>
>Perhaps a better name could have been chosen, in hindsight.  But in
>practice, s-s-d is the best available tool for uid switching in any
>noninteractive scripts.

Maybe we should change s-s-d to something like su-non-interactive (bad
name, didn't come up with something any better) and provide s-s-d as a
link.

Just out of curiosity: Which use is left to su if it is not supposed
to be used around init scripts and cron jobs any more? In interactive
sessions, we usually use sudo for fifteen years, is su really
completely deprecated for a decade and more?

>Systemd (as upstart) sidesteps this problem to a large degree by handling
>uid switching as a native directive, avoiding the need to call out to a
>separate command.

Just out of curiosity: What do I do when I convert an init script that
parses a mode 600 configuration file (containing passwords), does
necessary things as root and then starts a non-root daemon to systemd?
How do I do that with using a "native directive"?

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


--
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/e1wjo5e-0001sl...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sat, 10 May 2014 15:38:24 -0700, Steve Langasek 
wrote:
>I consider it of the highest importance that the transition to systemd not
>break running systems.

+1

>Some of the regressions introduced are going to turn out to be bugs in
>systemd.  Some of them are going to turn out to be latent bugs in other
>packages that are exposed by the transition to systemd.  The important thing
>here is that Debian developers (and bug reporters) work constructively
>*with* the systemd maintainers to properly isolate the cause of the bugs,

This works the other way around. Package maintainers (and this
explicitly includes the maintainers of big, important packages like
systemd has just become by KDE depending on it) _need_ to work with
the bug reporters without saying (explicitly or implicitly) "go away,
stupid minion, don't bother us with your problem".

It was pretty clear that introducing systemd to Debian as "needed on
every system running a reasonably current Desktop Environment" is
going to cause friction. If the systemd maintainers are not willing to
even assist in easing this friction even if they're not the fault of a
friction in their opinion, they should not have taken that endeavour
in the first place.

>> The plain fact:
>
>> Using systemd breaks something that worked for probably a decade or longer
>> before however long that su is in that init script.  So on what account do
>> you call calling "su" in an init script a bug?  It may not be the most
>> elegant solution to do things, granted, but a bug?  Come on.  Calling it a
>> bug just cause systemd / policykit treat calling su in an initscript as
>> they do is quite arrogant in my eyes.
>
>As the maintainer of the pam package in Debian, I assure you: this is a bug
>in dirmngr.  System services should not (must not) call interfaces that
>launch pam sessions as part of their init scripts.  su is one of those
>interfaces.

Is this documented anywhere, or is this only clear with detailed PAM
knowledge, which I have tried to build numerous times in the last ten
years and was never able due to (in my opinion) inadequate
documentation on the beginner level.

This is, btw, the same problem I have with dbus, *kit and numerous
other freedesktop-related software: There are truckloads of
documentation available, all written by people with intimate knowledge
of the software, lacking the two all-important first paragraphs like
"foo is a package doing baz, bar and bam, and to do so, it interacts
with DrizzleKit, BoggleBus and Fumble with the responsibility of
assisting with bar taken by BoggleBus". It's just missing the
description of the "big picture". I used to be able to help myself
getting this picture by dumping -x in shell scripts and running them,
but that possibility is taken away in more and more places.

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


--
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/e1wjntt-0001qw...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sat, 10 May 2014 16:27:00 +0200, Bas Wijnen 
wrote:
>This is the part you should _NEVER_ do.  It is YOUR responsibitiliy, as a
>maintainer (you are the maintainer, right?), to make sure that a bug that is
>reported in the wrong place gets sent to the right place.  It is GOOD that a
>user reports it (it is a real bug), and it isn't a problem if technically it
>isn't in your package; you just fix that.
>
>These sort of responses are giving you a bad name.  If you'd leave that
>statement out, the mail would be helpful.  With it, the user will feel that you
>tell them to "go away" (which was complained about in this very thread).

+1

Don't discourage people from reporting bugs, even if they do so at the
wrong place.

>Instead of complaining that the user reported the bug to the wrong package,
>please thank them for reporting it.  They're spending their time to make Debian
>better.  They are not trying to defame you.

+1

And, even they are not trying to defame you if they open the bug with
inflated severity and a noticable heat put in their words. They have
probably just recovered from a critical system breakage caused by your
package getting installed.

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


--
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/e1wjnwb-0001rb...@swivel.zugschlus.de

Re: correct use of su

[Adrien Clerc]

Le 11/05/2014 09:22, Marc Haber a écrit :
>> Systemd (as upstart) sidesteps this problem to a large degree by handling
>> uid switching as a native directive, avoiding the need to call out to a
>> separate command.
> Just out of curiosity: What do I do when I convert an init script that
> parses a mode 600 configuration file (containing passwords), does
> necessary things as root and then starts a non-root daemon to systemd?
> How do I do that with using a "native directive"?
>
In systemd, the ExecStartPre directive can be helpful. But the
documentation doesn't say if it is executed as the user defined in the
User directive, or as root. I guess the latter is done, but I'm too lazy
right now to test it :)


-- 
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/536f2d21.8070...@antipoul.fr

Re: correct use of su

[Lars Wirzenius]

On Sun, May 11, 2014 at 09:56:17AM +0200, Adrien Clerc wrote:
> In systemd, the ExecStartPre directive can be helpful. But the
> documentation doesn't say if it is executed as the user defined in the
> User directive, or as root. I guess the latter is done, but I'm too lazy
> right now to test it :)

>From the systemd.service[0] manual page (search for "User="):

PermissionsStartOnly=

Takes a boolean argument. If true, the permission-related
execution options, as configured with User= and similar
options (see systemd.exec(5) for more information), are only
applied to the process started with ExecStart=, and not to the
various other ExecStartPre=, ExecStartPost=, ExecReload=,
ExecStop=, and ExecStopPost= commands. If false, the setting
is applied to all configured commands the same way. Defaults
to false.

[0]: http://www.freedesktop.org/software/systemd/man/systemd.service.html

-- 
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers


-- 
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/20140511080509.ga32...@havelock.liw.fi

Re: systemd-fsck?

[Cyril Brulebois]

Marc Haber  (2014-05-11):
> Just curious as the maintainer of another package using su in an init
> script since 2001, how am I supposed to start a non-root process from
> an init script?

start-stop-daemon has:

   -c, --chuid username|uid[:group|gid]

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: systemd-fsck?

[Martin Steigerwald]

Am Sonntag, 11. Mai 2014, 08:57:29 schrieb Marc Haber:
> >IMVHO opening a PAM session in an initscript is a bad idea from day
> >one, as you don't know which modules are being called, as it can create
> >bogus audit trails or cause other subtile issues.
> 
> Just curious as the maintainer of another package using su in an init
> script since 2001, how am I supposed to start a non-root process from
> an init script?

Hmmm, start-stop-daemon can take a user argument.

output=$(start-stop-daemon --start --quiet --exec $DAEMON \
--oknodo --pidfile $PIDFILE --umask 027 --chuid dirmngr 
\
-- --daemon --sh) || return 1

works just well here and gives:

martin@merkaba:~> ps aux | head -1 ; ps aux | grep dirmngr | grep -v grep
USER   PID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
dirmngr   1106  0.0  0.0  17412  1368 ?Ss   Mai10   0:02 
/usr/bin/dirmngr --daemon --sh


For the record: I am not in disagreement of fixing this in dirmngr init script.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


-- 
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/2285690.2OTcgiLF2I@merkaba

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Marc Haber:
> >"systemctl status" tells you quite clearly what went wrong, "journalctl"
> >shows you what the program printed in case it did get started … and so on.
> 
> If the system boots.
> 
If it does not, you cannot stick '-x' into an init script either.

I haven't yet seen a system where booting with init=/bin/bash works but
booting systemd in emergency mode does not. And you can recover from the
latter without a reboot, and with your system in a sane state, much more
easily -- which is great if you have one of those Dell monsters which spend
an eternity in their excuse for a BIOS.

> virtually impossible to offer really complete debugging. -x is
> agreeable a pain, but it shows _everything_ a script does

That is true, but it's even simpler if there's no script to stick '-x' into
in the first place, because PID1 knows perfectly well how to do it on its
own and will give you a complete status, including failed preconditions
and whatnot. SysV init doesn't even *have* preconditions.

And if there is a script (for whatever reason), well, stick your '-x' into
it and restart its systemd service: the journal will have the shell trace.

-- 
-- Matthias Urlichs


-- 
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/20140511082202.ga13...@smurf.noris.de

Re: systemd-fsck?

[Martin Steigerwald]

Am Samstag, 10. Mai 2014, 21:36:42 schrieb Laurent Bigonville:
> Le Sat, 10 May 2014 19:13:01 +0200,
> Matthias Urlichs  a écrit :
> 
> Hi,
> 
> [...]
> 
> > > Telling "Go away, the bug is elsewhere" is just not an approbiate
> > > reaction for developers of a low level system component.
> > 
> > For the record: I do not disagree with this statement.
> 
> I think there are some misunderstanding here.
> 
> The initial bugreport really sounded like a feature request / changes
> of behavior not an actual bug.
> 
> And IMHO pointing the user to the documentation so the user can change
> it himself was perfectly correct.

I tried this and it just didn´t work, which I reported as well:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727645#50

But got ignored.

I think I still would like to have this. As it I still get a password prompt 
if trying to hibernate with two KDE sessions on which share a single seat. One 
private one and one work one.

I just don´t get it where on a single seat system being asked for a password 
on hibernate could make even make remote sense. At least not as a *default* 
case. I probably would understand it for shutting down… but all that will 
happen is that processes are put to sleep. Well network connection may break. 
But honestly: Did you ever see a laptop with one seat being used by mutiple 
users that would not know and talk to each other when to hibernate the 
machine? And how would entering a password in that case be helpful to change 
their behaviour if they do not? If they one who triggers the hibernate doesn´t 
care he or she will enter the password and be done with it. I do think this is 
such a rare corner case that it does not make even remote sense to have such 
behaviour as a default.

With all the implications this has: Cause in current behaviour of Plasma 
desktop this creates a security problem. First the screenlocker locks the 
screen, then the dialog to ask the password opens up. I can unlock the screen, 
but if I enter the password, it hibernates almost immediately with the screen 
unlocked unless I have the chance to lock it before by pressing Ctrl-Alt-L 
quickly enough. Granted I would see this as a bug in how Plasma desktop 
handles things. But again: It is changing the default behaviour without 
looking at what will break.

I think this behaviour make as much sense as asking for a root password for 
setting up a printer as Linus´ daughter was asked once. (I know this can be 
configured by group memberships in Debian.)

I strongly dislike that such a kind of behaviour is being pushed as a default 
onto the users on a single seat system. It is unintuitive, regresses over the 
behaviour that was there for the last decades, and in its current form even 
introduces a security problem. Do you expect all users that get annoyed by it 
to change their PolicyKit configuration?

So yes, I agree fixing the su in dirmngr. But I don´t think this is sufficient 
and propose not asking for hibernate password on a single seat system. 
Especially as you are not asked for a password on suspend either. I can 
suspend without a password just fine.

Really: Can it get any more inconsistent, unintuitive and annoying?

Thus I don´t agree with you merging all the reported bugs into dirmngr fixing 
the init script in it in my eyes is just fixing part of the reported problem.

> Looking at the original bug again, it seems that there were actually
> several issues. The bug with dirmngr creating a logind session and the
> fact that pam_loginuid was not properly set (login-session-id set to
> MAX_INT).

It was for a reason I reported several bugs, as I after the feedback I got was 
not sure against which component to report it on.

> The former bug will be fixed soon (I've pushed a NMU to the delayed/3
> queue) and the later should have been fixed in KDM for quite sometimes
> now.

Thank you very much. I appreciate it.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


--
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/9722989.GBrqMUSZlJ@merkaba

Re: systemd-fsck?

[Martin Steigerwald]

Am Samstag, 10. Mai 2014, 15:38:24 schrieb Steve Langasek:
> On Sat, May 10, 2014 at 04:00:39PM +0200, Martin Steigerwald wrote:
> > > The root cause of this bug is in the initscript of dirmngr that us using
> > > su instead of start-stop-daemon.
> > > 
> > > su is starting a PAM session which then call pam_systemd. This
> > > should not happen for daemons.
> > > 
> > > Again here systemd is only doing what he's instructed to do; not
> > > allowing a user to create a DOS for other logged in users. So please
> > > get dirmngr fixed instead of blaming systemd/logind. I've reopened the
> > > initial bug opened against dirmngr about the fact that the initscript
> > > is calling su (#668890)
> > 
> > Thats exactly the kind of reaction I meant:
> > 
> > Frankly, I just *don´t* care where it is fixed. If its in dirmngr, fine.
> > 
> > Yet: I do think its about high time systemd developers and packagers adopt
> > an attitude of "never break userspace" like the kernel developers do.
> 
> I consider it of the highest importance that the transition to systemd not
> break running systems.
> 
> But Laurent is correct here: the bug in this case is in dirmngr, not in
> systemd.  It's not reasonable to hold systemd to blame when other packages
> that were using wrong interfaces now have their bugs exposed because of
> logind.  In fact, I'm surprised that this particular bug in dirmngr wasn't
> already a problem *before* systemd, since consolekit's behavior (including
> the integration with PAM sessions) was nearly identical.

I beg to differ. Correct is a definition of people believing in a certain 
behaviour to be correct. I am more interested in sane, not in supposedly 
correct behaviour.

Let me elaborate:

Sure, I agree fixing the dirmngr init script, tested the fix and posted the 
patch from Maurizio without the word wrap issues onto the bug report.

Yet I do not think this fixes all of the reported problem.

Why?

I am still asked for a password confirmation on hibernating on a single seat 
system as default behaviour if systemd is running.

Why does this do not make much sense to me? Why do I think it *breaks* 
existing setups in a horrible way?

1) How often did you see more than one user using a single seat machine 
together without being able to talk about when to hibernate it? How would 
asking a password help to improve the situation if one of them chooses not to 
talk about it?

2) How much sense does it make that it just suspends without asking a password 
then?

3) How much sense does it make that with Network Manager I can just stop the 
network connection as a user without being asked a password, which in addition 
to pausing the processes is the only consequence of a longer hibernation?

4) And how about that with current behaviour of KDE it even introduces a 
security issue on top of annoying the user: KDE first locks the screen, then 
the password confirmation dialog appears, but invisible behind locker screen. 
Then the user wonders what is happening here, why the machine does not just 
hibernate, then the user eventuall unlocks the screen again, sees the password 
prompt, thinks "WTF!", enters the password and the machine almost immediately 
hibernates without locking the screen again.

Can it get anymore unpredictable and inconsistent for the user?

I reported all of this in the bug reports. Yet Laurent merged them all 
together and reassigned them to dirmngr, which is comfortable for pushing 
systemd as default as soon as possible. I am not even sure he read the bug 
reports.

Would you like to see the described behaviour as a default on a single seat 
machine for a user who may happens to open a private and a work session on a 
laptop?

I don´t.
 
> Laurent is not being a systemd apologist by pointing this out.  I know from
> the PAM bugs I've worked with him on that he cares deeply about getting the
> core structure of session handling right in Debian.  But doing that in a
> fashion that's maintainable over the long term means having a *design*, and
> stable *interfaces* that are supported - not a blanket promise to never
> break anything in the system that is relying on unintended side effects of
> the current implementation.

As written elsewhere, by "not breaking it" I also mean to care about "when I 
still break something for a good reason" to get it fixed there – before having 
systemd activated on an apt-get dist-upgrade.

And considering the points I made above I do not even remotely see a sensible 
design pattern in here.
 
> Some of the regressions introduced are going to turn out to be bugs in
> systemd.  Some of them are going to turn out to be latent bugs in other
> packages that are exposed by the transition to systemd.  The important thing
> here is that Debian developers (and bug reporters) work constructively
> *with* the systemd maintainers to properly isolate the cause of the bugs,
> so that we can move forward together towards a stable jessie with systemd
> as the default... in

Re: systemd-fsck?

[Martin Steigerwald]

Am Sonntag, 11. Mai 2014, 00:55:43 schrieb Kevin Chadwick:
> previously on this list Steve Langasek contributed:
> > > Using systemd breaks something that worked for probably a decade or
> > > longer
> > > before however long that su is in that init script.  So on what account
> > > do
> > > you call calling "su" in an init script a bug?  It may not be the most
> > > elegant solution to do things, granted, but a bug?  Come on.  Calling it
> > > a
> > > bug just cause systemd / policykit treat calling su in an initscript as
> > > they do is quite arrogant in my eyes.
> > 
> > As the maintainer of the pam package in Debian, I assure you: this is a
> > bug
> > in dirmngr.  System services should not (must not) call interfaces that
> > launch pam sessions as part of their init scripts.  su is one of those
> > interfaces.
> 
> In that case should it be one of those interfaces.
> 
> He is right, books tell you (for decades) quite rightly to do just that
> in rc.local for example. Examples are all over the internet, so if this
> breaks your system are you or RedHat going to change all those books
> and websites to say but if you are using Linux post 20?? you now have to
> do it differently unless you use Slackware or maybe Gentoo or???, that
> is irresponsible or bad planning or configuration or perhaps money in
> RedHat's pocket for support if I was inclined to be sinical.
> 
> "The su utility allows a user to run a shell with the user and group
> ID of another user without having to log out and in as that other user."

+1

I would start with the manpage of su:

DESCRIPTION
   The su command is used to become another user during a login
   session. Invoked without a username, su defaults to becoming the
   superuser. The optional argument - may be used to provide an
   environment similar to what the user would expect had the user
   logged in directly.


I think it can´t get much clearer than that. Become another user during a 
login session.

Nothing at all about that su spawns another login session. During a login 
session even indicates the opposite of it.

So it doesn´t.

According to the documentation at least.

So I do not even see the behaviour in dirmngr init script as a bug anymore. It 
is using *documented* functionality.

I´d still replace it with start-stop-daemon as it seems to work fine and seems 
to be more standardized to me, yet, the "su" manpage IMHO does not leaves a 
doubt here.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


--
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/16278908.jPxC3ESdYJ@merkaba

Re: systemd-fsck?

[Martin Steigerwald]

Am Sonntag, 11. Mai 2014, 09:13:09 schrieb Marc Haber:
> On Sat, 10 May 2014 16:27:00 +0200, Bas Wijnen 
> 
> wrote:
> >This is the part you should _NEVER_ do.  It is YOUR responsibitiliy, as a
> >maintainer (you are the maintainer, right?), to make sure that a bug that
> >is reported in the wrong place gets sent to the right place.  It is GOOD
> >that a user reports it (it is a real bug), and it isn't a problem if
> >technically it isn't in your package; you just fix that.
> >
> >These sort of responses are giving you a bad name.  If you'd leave that
> >statement out, the mail would be helpful.  With it, the user will feel that
> >you tell them to "go away" (which was complained about in this very
> >thread).
> +1
> 
> Don't discourage people from reporting bugs, even if they do so at the
> wrong place.

Honestly I did not have an idea about what the right place would be.

And added to that: I even don´t have one now.

I admit I lack full understanding of what is doing what in this scenario.

Yet the su manpage clearly states that su doesn´t open a new login session. So 
if it does, its a bug in su´s behaviour. This directly contradicts Steve´s 
argument.

I´d still would use start-stop-daemon in dirmngr init script. Yet, as I 
outlined in my other mails, this does not fix all of the issue.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


--
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/3242449.Ety7AiuGEE@merkaba

Re: systemd-fsck?

[Vincent Bernat]

 ❦ 11 mai 2014 08:58 +0200, Marc Haber  :

>>Mind you, I am not defending the handling of this specific bug; certainly
>>the systemd people's attitude is somewhat … let's call it abrasive …
>>at times.
>
> And this abrasive attitude is hurting. It's hurting systemd, it's
> hurting users, it's hurting Debian and it's hurting open source.

Constant whining does not help. su is opening a new session, it always
has. Get over with it. systemd maintainers are doing a very good job
while being constantly criticized by a small set of people.
-- 
panic ("No CPUs found.  System halted.\n");
2.4.3 linux/arch/parisc/kernel/setup.c


signature.asc
Description: PGP signature

Bug#747706: ITP: libtypes-datetime-perl -- type constraints and coercions for datetime objects

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libtypes-datetime-perl
  Version : 0.001
  Upstream Author : Toby Inkster 
* URL : https://metacpan.org/release/Types-DateTime
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : type constraints and coercions for datetime objects

 Types::DateTime is a type constraint library suitable for use with
 Moo/Moose attributes, Kavorka sub signatures, and so forth.

This package is needed by recent releases of libweb-id-perl.

It will be maintained inside the pkg-perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJTb09YXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWIKMIAI2Hu1AVuNOgrUUxJOpeNCJy
2/6wBLVlLrbxUuOqWO4lMr8IfdjzJA8JFYgg7YAdJMhZ/nHC/JPxjSLWbUrHf4w3
hnUSOejThR5mFiMz+jyYJ8uAzk1lgKXMYrs1Nc4dQ9ZEj2qd9ma8t9hRgFkG+SOT
RYMaA5SdOlAqpC2yaxk4IV1rDdb2UfdmhqYojTlkGxSBy5ataRy9s6vAFO+e15JY
2Av5WUl41wluZbxilBeWmMyh7P3rl721j+IR7vnTQGZhEvxB6XNrgsVsbCZWx7Sn
CPkgIj9dK/edqMxPlbmbXEJePV3rMwV5rNPtFu1uUJClVxZUuTxv2z43XObtaK8=
=6uHG
-END PGP SIGNATURE-


-- 
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/20140511102220.13106.48327.report...@bastian.jones.dk

Re: systemd-fsck?

[Marc Haber]

On Sun, 11 May 2014 10:22:02 +0200, Matthias Urlichs
 wrote:
>That is true, but it's even simpler if there's no script to stick '-x' into
>in the first place, because PID1 knows perfectly well how to do it on its
>own and will give you a complete status, including failed preconditions
>and whatnot. SysV init doesn't even *have* preconditions.

a PID 1 systemd knows what Lennart thinks is necessary for it to know,
and we both know how nice he acts when somebody disagrees with him.

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


--
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/e1wjrnv-0003vg...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois 
wrote:
>Marc Haber  (2014-05-11):
>> Just curious as the maintainer of another package using su in an init
>> script since 2001, how am I supposed to start a non-root process from
>> an init script?
>
>start-stop-daemon has:
>
>   -c, --chuid username|uid[:group|gid]

Will a script doing this be portable to other Linuxes or even BSD
Unices?

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


--
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/e1wjrnz-0003vp...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sun, 11 May 2014 11:54:37 +0200, Vincent Bernat 
wrote:
> ? 11 mai 2014 08:58 +0200, Marc Haber  :
>
>>>Mind you, I am not defending the handling of this specific bug; certainly
>>>the systemd people's attitude is somewhat … let's call it abrasive …
>>>at times.
>>
>> And this abrasive attitude is hurting. It's hurting systemd, it's
>> hurting users, it's hurting Debian and it's hurting open source.
>
>Constant whining does not help. su is opening a new session, it always
>has. Get over with it. systemd maintainers are doing a very good job
>while being constantly criticized by a small set of people.

The small set of people is increasing. Please note that I was not
opposed to systemd previously. I only was afraid of having to interact
with unfriendly people, and latest information and event shows that
this fear was not without reason.

It hurts people and issues when valid issues are disqualified as
"whining", btw.

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


--
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/e1wjrqs-0003wk...@swivel.zugschlus.de

Re: Guile language support in make

[Santiago Vila]

On Sat, May 10, 2014 at 06:38:15PM -0700, Manoj Srivastava wrote:
> I would like to solicit the opinion of the developers about the
>  value of adding Guile support to the default make package, at the
>  expense of two smallish additional dependencies.
>  http://blog.melski.net/2013/11/29/whats-new-in-gnu-make-4-0/ has a
>  write up on what guile support would bring.

I would just add guile support to the normal package.

A few more libraries in the build-depends will not make as much harm
as a lot of people trying to guess why Debian make does not support
guile and why they have to install another different binary.

IMHO, the bootstrapping thing is a problem to be solved by build
stages, not by trimming functionality or by multiplying the number of
binary packages. The gettext package, for example, has a long build-depends
line, and I don't think that would be a reason to make different gettext 
packages.

Thanks.


-- 
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/2014050204.ga6...@cantor.unex.es

Re: Bug#706336: RFP: wmfs2 -- tiling window manager

[Andrei POPESCU]

Control: reassign -1 wnpp

On Du, 28 apr 13, 17:24:49, Anti Thesis wrote:
> Package: wmfs2
> Severity: wishlist
> 
> WMFS2 is a lightweight and highly configurable tiling window manager for X 
> written in C. wmfs2 is a free software distributed under the BSD license. it 
> can be drive from keyboard or mouse and it's configuration stands in one text 
> file easily understandable

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Bug#706338: RFP: dictator -- Rapid Serial Visual Presentation (RSVP) text file reading

[Andrei POPESCU]

Control: reassign -1 wnpp

On Du, 28 apr 13, 17:27:34, Anti Thesis wrote:
> Package: dictator
> Severity: wishlist
> 
> Dictator is a program for on-screen reading of text files, developed with the 
> intention of making it easier to read some of the fine electronic texts 
> available on the net, such as those produced by The Gutenberg Project.
> 
> License: GNU GPL.
> URL: http://dictator.kieranholland.com/dictator.html

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: systemd-fsck?

[Martin Steigerwald]

Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber:
> On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois 
> 
> wrote:
> >Marc Haber  (2014-05-11):
> >> Just curious as the maintainer of another package using su in an init
> >> script since 2001, how am I supposed to start a non-root process from
> >> an init script?
> >
> >start-stop-daemon has:
> >   -c, --chuid username|uid[:group|gid]
> 
> Will a script doing this be portable to other Linuxes or even BSD
> Unices?

Good question and I think the answer is a no.

So… instead of changing the script it may be better to provide a systemd unit 
file for dirmngr, then the script can remain as it is.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


--
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/2533469.hbZhCQRriv@merkaba

Re: Bug#706342: RFP: alopex -- tiling window manager

[Andrei POPESCU]

Control: reassign -1 wnpp

On Du, 28 apr 13, 17:33:32, Anti Thesis wrote:
> Package: alopex
> Severity: wishlist
> 
> Alopex is a tiling, tagging, window manager with status bar tabs.
> 
> License: GNU GPL
> URL: https://github.com/TrilbyWhite/alopex
> Alternative URL: http://trilbywhite.github.io/alopex/index.html

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: Bug#720394: RFP: lxc-docker -- create lightweight, protable, self-sufficient containers

[Andrei POPESCU]

Control: reassign -1 wnpp
Control: retitle -1 RFP: lxc-docker -- create lightweight, portable, 
self-sufficient containers

On Mi, 21 aug 13, 13:44:53, Johannes Graumann wrote:
> Package: lxc-docker
> Version: 0.5.3-1
> Severity: wishlist
> 
> Hello,
> 
> As per http://www.docker.io/: "Docker is an open-source project to easily 
> create lightweight, 
> portable, self-sufficient containers from any application. The same container 
> that a developer 
> builds and tests on a laptop can run at scale, in production, on VMs, bare 
> metal, OpenStack 
> clusters, public clouds and more."
> 
> Ubuntu has it (https://launchpad.net/~dotcloud/+archive/lxc-docker/+packages) 
> and installation
> of that is straight forward in debian 
> (http://www.grendelman.net/wp/docker-on-debian-wheezy/).
> 
> Please provide as native debian package.
> 
> Sincerely, Joh
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.10-2-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages lxc-docker depends on:
> ii  aufs-tools  1:3.0+20130111-3
> ii  bsdtar  3.1.2-7
> ii  lxc 0.9.0~alpha3-2
> 
> lxc-docker recommends no packages.
> 
> lxc-docker suggests no packages.
> 
> -- no debconf information

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Re: systemd-fsck?

[Laurent Bigonville]

Marc Haber wrote:
> On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois 
> wrote:
> >Marc Haber  (2014-05-11):
> >> Just curious as the maintainer of another package using su in an
> >> init script since 2001, how am I supposed to start a non-root
> >> process from an init script?
> >
> >start-stop-daemon has:
> >
> >   -c, --chuid username|uid[:group|gid]
> 
> Will a script doing this be portable to other Linuxes or even BSD
> Unices?

(Almost) all the initscript that are today in Debian are using this.

For other distributions (and other Unix based OS) most of (all?) the
initscripts are already different anyway.

Regards,
Laurent


-- 
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/20140511134739.5c6e1...@fornost.bigon.be

Re: systemd-fsck?

[Tollef Fog Heen]

]] Martin Steigerwald 


> DESCRIPTION
>The su command is used to become another user during a login
>session. Invoked without a username, su defaults to becoming the
>superuser. The optional argument - may be used to provide an
>environment similar to what the user would expect had the user
>logged in directly.
> 
> 
> I think it can´t get much clearer than that. Become another user during a 
> login session.
> 
> Nothing at all about that su spawns another login session. During a login 
> session even indicates the opposite of it.
> 
> So it doesn´t.
> 
> According to the documentation at least.
> 
> So I do not even see the behaviour in dirmngr init script as a bug anymore. 
> It 
> is using *documented* functionality.

Init scripts don't run in the context of a login session, so no, it's
not.  It's using undefined behaviour and just like all other transitions
we've had in Debian we discover bugs when packages are using the
implementation defined (or undefined) behaviour rather than the
specified and documented behaviour.

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


-- 
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/87d2fkvam7@xoog.err.no

Bug#747722: ITP: libmatch-simple-xs-perl -- XS backend for match::simple

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libmatch-simple-xs-perl
  Version : 0.001
  Upstream Author : Toby Inkster 
* URL : https://metacpan.org/release/match-simple-XS
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : XS backend for match::simple

 match::simple::XS is a faster XS-based implementation of match::simple.
 .
 Depending on what sort of matches done, it is likely to be several
 times faster. In extreme cases, such as matching a string in an
 arrayref, it can be twenty-five times faster, or more. However, where
 $that is a single regexp, it's around 30% slower.
 .
 Overall though, the performance improvement should be worthwhile.

libmatch-simple-xs-perl is recommended by recent releases of
libmatch-simple-perl.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJTb2kWXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWR5YIAKpQecZrwnqPZ5JFdc7c/4Z+
ucU7JNhZeIYxyCgcHFFOwQFMzjQjvbp6YSPhEBEmRs/USCC3NlrfCZqy4YiRYx1v
aD9DMlMLi4oQvouGwljNknxzQQmX+/2lTBSygyIlVJEu3g3+hgm2j9uwB/fagBQK
7e87W2MHDLCEF3zTzKGXYLpN2PWgE+bE8gc4BwQ0/TcWLGXnXDmeCf1XW1CEbhMg
EI66xchNuQwQvBjLHilKjPZi/OqqRMV4o4Sg6hPm7/aA0CKDhVRr2AFqKNucR+zC
iLtMrIbxg69C5fogkFkCoaKK7n3g/LtiK3o75JF2MVcppOwD4jydOrPng922Qbk=
=8NjR
-END PGP SIGNATURE-


-- 
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/20140511121209.5319.87893.report...@bastian.jones.dk

Re: ignoring bugs with no maintainer (Re: Removal of emacs23 from unstable/testing)

[Andrei POPESCU]

On Sb, 10 mai 14, 18:56:24, Holger Levsen wrote:
> 
> Having these bugs rott in a corner of the BTS almost nobody ever looks at is 
> a 
> disservice to our users. IMO there should be 0 bugs open against 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=

To also bring some numbers to this:

$ unk-pkg count any all
1066
 
> Oh, and emacs bugs "only" make up 20% of those bugs... IMO all should 
> be dealt with, i just picked emacs as the emacs23 removal announce 
> mail reminded me...

$ unk-pkg count any open
1043
$ unk-pkg count emacs open
255

Last time someone (Bcc'd) tried to tackle these (admittedly without 
contacting the maintainer in advance) the contributor was prevented from 
doing so and was requested to either check them against emacs24 or leave 
them alone. It's not hard to imagine what happened...

For anyone wishing to work on these I attach the script I have been 
using.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt
#!/bin/sh -e
# script to handle bugs with no maintainer
#
# Needs:
# w3m - to retrieve the webpage with bugs
# mail - to be able to close bugs
#
# Suggested workflow would be:
#
# $ unk-pkg list any all
#
# to get a full list of bugs and look for patterns
#
# unk-pkg list  open
#
# this should provide you with a list of bugs for a package/pattern to
# decide on further action, contact maintainers, etc.
#
# unk-pkg list  patch
#
# these bugs contain patches, you might want to investigate
# whether they are still valuable
#
# unk-pkg close  open
#
# assuming you already created the message body (after discussing
# with maintainers) as $PKG.mail this will send a test message
#
# To: $bugs-done@localhost
# Bcc: $USER@localhost
#
# add 'notest' to send a real -done message to all bugs,
# Bcc: debian...@lists.debian.org

BTS_URL="http://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=";
DUMP="$(date +%F).dump"
ACTION="$1"
PKG="$2"
CRITERIA="$3"
CRIT_RE="\[.*\]"
BTS="bugs.debian.org"
QA="debian...@lists.debian.org"


if [ "any" = "$PKG" ];
then
PKG_RE="^.*#[[:digit:]].*\[.*\].*\[.*\]"
else
PKG_RE="^.*#[[:digit:]].*\[.*\].*\[.*${PKG}.*\]"
fi


if ! [ "notest" = "$4" ];
then
BTS="localhost"
QA="$USER@localhost"
fi

do_get_dump() {

if ! [ -f $DUMP ];
then
w3m -dump -cols 200 "$BTS_URL" > "$DUMP"
fi

}

do_filter() {

do_get_dump
grep "$PKG_RE" $DUMP | grep $COUNT $MATCH $CRIT_RE

}

do_get_bugs() {

do_filter | sed -e 's/^.*#\([[:digit:]]*\)[[:space:]]\[.*$/\1/'

}

do_close () {

if [ "any" = "$PKG" ];
then
echo "You are trying to close too many bugs, try specific packages (or 
patterns) first"
exit 1
fi

if ! [ -f $PKG.mail ];
then
echo "Missing file containing message body"
exit 1
fi

for BUG_NR in `do_get_bugs`;
do
BUGS_DONE="$BUG_NR-done@$BTS $BUGS_DONE"
done

cat $PKG.mail | mail -E -s "Closing old bugs filed against $PKG (or related 
packages)" \
-b $QA \
$BUGS_DONE

}

do_usage() {
echo "Usage: $0   "
exit 1
}

if [ x"$1" = "x" ];
then
do_usage
fi

case "$CRITERIA" in
open)
CRIT_RE="\[.*|.*|.*☺.*\]"
MATCH="--invert-match"
;;
closed)
if [ "close" = "$1" ];
then
echo "You are trying to close already closed bugs..."
exit 1
fi
CRIT_RE="\[.*|.*|.*☺.*\]"
;;
patch)
if [ "close" = "$1" ];
then
echo "Closing bugs with patches?"
exit 1
fi
CRIT_RE="\[.*|+|.*\]"
;;
all)
if [ "close" = "$1" ];
then
echo "Closing all bugs? Some may contain patches or may be closed 
already."
exit 1
fi
;;
*)
if ! [ "refresh" = "$1" ];
then
echo "Criteria must be one of open, closed, patch, all."
do_usage
fi
;;
esac

case "$ACTION" in
refresh)
# get an updated list of bugs
if [ -f $DUMP ];
then
rm -f $DUMP
fi
do_get_dump
COUNT=--count
CRITERIA="all"
echo "Total bugs: `do_filter`"
;;
list)
# list bugs filtered by some criteria
do_filter
;;
count)
# same as list, but display count only
COUNT="--count"
do_filter
;;
bugs)
# display just the bug numbers
do_get_bugs
;;
close)
# do mass close (mail to -done) using prepared template
do_close
;;
*)
do_usage
;;
esac


signature.asc
Description: Digital signature

Re: Avoiding system d

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/11/2014 03:18 AM, Marc Haber wrote:

> On Sat, 10 May 2014 19:47:10 +0100, Brian 
> wrote:
> 
>> On Sat 10 May 2014 at 12:05:25 -0400, John wrote:
>> 
>> A couple of quotes from your mail:
>> 
>>> "I find myself appalled at the rude and domineering attitudes of
>>> almost all systemd's defenders."
>> 
>> You're not looking for flames? You're kidding, aren't you? Your
>> technical question is wrapped up in flame-baiting.
> 
> Sorry if that comes around at flame-baiting, but John describes the
> way the systemd world socially interacts with its outside quite
> accurately. It is the same for me: social interaction with systemd
> (and this includes reading bug reports and mailing lists without
> participating actively) takes fun out of using Linux for me just for
> the social sake.
> 
> Something along the lines of systemd is technically needed and a good
> idea, but the people behind it do not come along nice.

Well said. This expresses a large and important part of my own viewpoint
on this.

Even if you change nothing about the software itself, think about how
you present yourselves, people! Saying something different, or even only
saying the same thing differently, can make a very large difference in
how people perceive and react to you - and to what you're advocating.

I don't post often, but when I do, I often go well out of my way and
take considerable trouble to try to get this right. (Though I also often
fail in the attempt.)

- --
   The Wanderer ("me too!")

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTb2x/AAoJEASpNY00KDJrUfcP+QGf0AADuUNR4UKBNKsfAFqa
JXxhVcs8OpXiorAaV8ZUHGm4ozaU5xEDf9hi0TYMMsrX8KZJ2PHk/OTWig8vXSNd
XTvLdJIppIRBbZ7ZbAMLFPsd9bOMo/XDohxqFCyct7EitJeyD/j+LoXDsqMWbY98
9ErTg9BCxqObPC0kvV0/2Lai3voiW+dBcAkdTDWnhUUnx+3HRpcOJnKz/SxflqMb
k/m5zKzg9n5sOODdTxNzNYcswqvBDIsw8X+MQ73aQV15TvMn8lf2PSGR9kjYdZwS
kAJMfaEpxBUQ2vtBRU2+3FmYF28EshWHNAmg06cIMD4ztPozOUbnYnhnT+mEytwP
d2W40AWiCQDUzLXFubHtoo8voKvBKtptsiXeqx8CAspPwVRWTH8ZcXv88G5YiyEy
RLta4e4+ud7+VV3NpEOdAAh149785DVqtVLvORtavbzCcXBF1JQZLboiU2jIUGVg
EWMWh3XyGd/1h4/GOgykaolidWNFrdMuRNEn6U0QLFi4SIDox7uS7U1FawUnAqix
QfJyvYB4Z5ii/AHl0SHdpaxmdyyymZXN6RTKm5V4gVB7zdey8dErCXrdw//5EUjl
SSORt6z078kmASAFRutipaFWM4xxN3tJh6Hy1YnLW6hV/QSmP0JVCDs4T0Y4DKA0
f+LNU5QwaA0cYrhCP5gM
=Hn7q
-END PGP SIGNATURE-


-- 
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/536f6c80.9010...@fastmail.fm

Bug#747729: ITP: libtypes-uuid-perl -- type constraints for UUIDs

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libtypes-uuid-perl
  Version : 0.002
  Upstream Author : Toby Inkster 
* URL : https://metacpan.org/release/Types-UUID
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : type constraints for UUIDs

 Types::UUID is a type constraint library suitable for use with
 Moo/Moose attributes, Kavorka sub signatures, and so forth.

This package is (indirectly) required by recent releases of
libweb-id-perl.

It will be maintained inside the pkg-perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJTb21rXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWY/8IAMNUOp2szZfNsVtgWoRdex81
WkmGahcHbOdiiCGnfZeBNFjGrmvzW/30qaHPZdogHN7JzmEK+0bz2TTy/59nTUAD
L9PzUKzkqlqK8Vv+iQytC7nTzJyVhYCejLcC2O86PmYZz3kUj7RpdOmhktpk9y1J
/frIITZVZEk4V8K6igK4SHcZuXnoIlcGcMIdlfvpGf7/q16AaTVyIK+MNB8cR8va
wQb4MDVFDSLJve8BWrPCzX8wMSroFdi3ejRenDPm5VHsO824/n3qMz2Ecg7+j6j5
XW+i7sgvSsY1t/5sjGRK+yE/9EomM0Q2JUxdgJUf7KmV9ybG+9gwuEBAGpfLGoE=
=IC33
-END PGP SIGNATURE-


-- 
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/20140511123035.9722.53684.report...@bastian.jones.dk

Bug#747731: ITP: libpackage-constants-perl -- list constants defined in a package

[Niko Tyni]

Package: wnpp
Severity: wishlist
Owner: Niko Tyni 

* Package name: libpackage-constants-perl
  Version : 0.04
  Upstream Author : Jos Boumans
* URL : https://metacpan.org/release/Package-Constants
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : list constants defined in a package

Package::Constants is being removed from the Perl core. The core version
will be deprecated in Perl 5.20 and removed in 5.22.

The perl package will recommend the separate package for one release
cycle to ensure smooth upgrades.

The package will be maintained under the pkg-perl umbrella.


-- 
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/20140511125213.17547.93743.reportbug@estella.local.invalid

Re: Guile language support in make

[Marco d'Itri]

On May 11, Manoj Srivastava  wrote:

> Building two binary packages from a single source seems hackish,
>  since make and make-guile would require  ./configure to be run again,
>  and each target of the ./debin/rules might need cleanup/restart. Not
>  unsolvable, but messy, and I do not have the motivation to do
>  that. Patches welcome, of course.
I do this for the inn2 package and it has worked well for years.
Another (much simpler) example is kmod, which build a deb and a udeb.
If ./configure is not buggy and works when called from a build directory 
then building two binary packages from the same source is trivial.

Since it is installed on so many systems, I believe that a lean make 
package is still worthwhile.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Avoiding systemd

[Florian Lohoff]

On Sat, May 10, 2014 at 03:47:47PM -0700, Steve Langasek wrote:
> This one.
> 
> The systemd package contains other dbus services that you don't want to try
> to exclude from a desktop system; and libpam-systemd provides necessary
> integration with policykit on those same systems.

So basically what you say is Debian ended support for other init systems
because whatever one chooses you pull in half the systemd?

I was against all the systemd stuff because i saw this coming. 

There is no way to avoid the "userspace.exe" blob Debian is soon made of. 

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

Bug#747732: ITP: libtest-api-perl -- test a list of subroutines provided by a module

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libtest-api-perl
  Version : 0.001
  Upstream Author : David Golden 
* URL : https://metacpan.org/module/Test::API
* License : Apache-2.0
  Programming Lang: Perl
  Description : test a list of subroutines provided by a module

 Test::API checks the subroutines provided by a module.  This is useful
 for confirming a planned API in testing and ensuring that other
 functions aren't unintentionally included via import.

This package is (indirectly) required by recent releases of
libweb-id-perl.

It will be maintained inside the pkg-perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJTb3X/XxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWKiIH/3fUUXHFak+fXN1xjkn/iJJk
QnuCW0EGFilBdiTaHsRySHFVCEnob+mxyx4cpcb1vSk1Dm4UtyjBMVOJItbjP7QP
4gzw2HEtgG1mn/djgJaKgE6Pk6s9oGqpADQqZwNfPb7fZrkXQ/SGSjYwT22eD5Gw
lUidZnR65E8Z7o00qLga285fnXruJ/bg26bujGD/HUvcFIrg62CvZ9fmJW6UfHjj
kmLVboad4FKbq0rpvpdyObc1iq6n54y/Tf1USiw8mZL5YBzXAosobUthtWvZPM90
XT3i6KPjoCzFUlreL/qBOU7Mt/wJH8PjE1oXQaPgE+EGNatUVK7jVzmqgMZY99U=
=JwpH
-END PGP SIGNATURE-


-- 
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/20140511130714.27327.26381.report...@bastian.jones.dk

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Martin Steigerwald:
> Yet the su manpage clearly states that su doesn´t open a new login session.

Does not.

The manpage states that su is meant to change your UID _during_ a login session.
If there is no such thing, the fact that it creates a new session for you
should not be too surprising.

-- 
-- Matthias Urlichs


-- 
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/20140511133328.gb13...@smurf.noris.de

Re: ignoring bugs with no maintainer (Re: Removal of emacs23 from unstable/testing)

[Santiago Vila]

On Sat, May 10, 2014 at 06:56:24PM +0200, Holger Levsen wrote:
> I believe all those bugs should be either reassigned to emacs23 (and soon 24) 
> or just be closed with an informal message, also offering to reopen and 
> reassign to emacs23/24 if applicable. [...]

Closing them would be a disservice to our users. A bug in emacs does
not stop being a bug in emacs just because the Debian package changed
its name, or because the bug is old, or because the maintainer didn't
have time to check whether it applies to the new version or not. If
this is the case, fine, ask for help.

If I remember well, bugs in pine that were still bugs in alpine were
reassigned to alpine as being its "sucessor" (the alpine project originated
from pine source, after all). In this case it is the GNU emacs
package, so the new packages are clearly the sucessor of the old ones.

So, the natural thing to do would be to reassign them. 

Thanks.


-- 
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/20140511133949.ga7...@cantor.unex.es

Re: Alioth tracker

[Daniel Pocock]

On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote:
> Hi,
> 
> is someone processing the items on the Alioth tracker?
> 
> There are currently 184 reuqests open, some trivial requests already
> since two years (like [1]).
> 
> I filed a ticket there a month ago, and still did not get any
> response yet.
> 
> What is the reason that the processing there is so slow? Is there a way
> to change that?
> 
> Also, although alioth is an official Debian server (right? It has .org
> suffix), it does not use the Debian bug system, but its own ticket
> system. I asked that already some time ago, and got the recommendation
> to ask that on alioth directly. However, since the response time there
> is so long, I doubt that there will be a discussion about this.
> 


Other people have had problems with alioth too:

- write permissions on VCS directory for new projects

- mailing list creation requests waiting for admin approval

On non-Debian sites (e.g. Sourceforge, github) things like this are
fully automated (for better or worse).

For mailing lists:
- could list creation be fully automated if they are on a debian.net
subdomain?
- could all DDs be given rights to approve alioth.d.o mailing list
creation (with a dispute process for any controversial approvals)?

For repositories:
- would moving to a single tool (e.g. Git) make it easier to automate
and help to eliminate the bugs we currently see on alioth?
- could we have a debian.org solution (alioth or elsewhere) that
automatically mirrors all Git repositories that DDs maintain themselves
on github or other public locations?

Any of these things could help reduce the admin burden, maybe there are
other approaches too?


-- 
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/536f821a.5030...@pocock.pro

Re: systemd-fsck?

[Matthias Urlichs]

Hi,

Marc Haber:
> >start-stop-daemon has:
> >   -c, --chuid username|uid[:group|gid]
> 
> Will a script doing this be portable to other Linuxes or even BSD
> Unices?
> 
No. BSD has daemon(8). If you want portability, you probably need to check
what's available. (start-stop-daemon, daemon (on BSDs), sudo)

FreeBSD's /bin/su, by the way, is using PAM too (see the manpage).
So I wouldn't trust it to not do any session magic either.

-- 
-- Matthias Urlichs


-- 
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/20140511134515.gc13...@smurf.noris.de

Bug#747747: ITP: libtest-modern-perl -- precision testing for modern perl

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libtest-modern-perl
  Version : 0.007
  Upstream Author : Toby Inkster 
* URL : https://metacpan.org/release/Test-Modern
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : precision testing for modern perl

 Test::Modern provides the best features of Test::More, Test::Fatal,
 Test::Warnings, Test::API, Test::LongString, and Test::Deep, as well as
 ideas from Test::Requires, Test::DescribeMe, Test::Moose, and
 Test::CleanNamespaces.
 .
 Test::Modern also automatically imposes strict and warnings on your
 script, and loads IO::File. (Much of the same stuff Modern::Perl does.)
 .
 Although Test::Modern is a modern testing framework, it should run fine
 on pre-modern versions of Perl. It should be easy to install on Perl
 5.8.9 and above; and if you can persuade its dependencies to install
 (not necessarily easy!), should be OK on anything back to Perl 5.6.1.

This package is (indirectly) required by recent releases of
libweb-id-perl.

It will be maintained inside the pkg-perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJTb4NbXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vW9eoH/2FA87KYM+zxBh+Xhm0f3ItH
KBcCnvOjWjntuglwBuRtCJXkZYG/cD1+PS/bWNLJDlEpOLisXZ6yoBKnuAEz5KkL
IQBeZlAZGTxK+otCs3ZsmghG3hHupKUTLmFI/XqgXh9V0Ji/FFU8jgNyszggLCf/
dcesaqI9X5rAZr0f6FbVD/2nRc6Hc/lwU7E/I7d2WgBpWOciUtALkt8ocB2UQefE
LG2XUyjl6ntinA5ovPASfGoi0/fSv49q7lHXL6ydbVK66nQ0L0/7PN70pYg/dhtP
u+v2DgekFMQgbpcwCaKCgcMqX/865N/R8vUWdinxYRXQE/Qw6yF+sbWmQXFMkLU=
=f27Y
-END PGP SIGNATURE-


-- 
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/20140511140414.1357.71621.report...@bastian.jones.dk

Re: systemd-fsck?

[Marc Haber]

On Sun, 11 May 2014 13:16:43 +0200, Martin Steigerwald
 wrote:
>Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber:
>> On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois 
>> 
>> wrote:
>> >Marc Haber  (2014-05-11):
>> >> Just curious as the maintainer of another package using su in an init
>> >> script since 2001, how am I supposed to start a non-root process from
>> >> an init script?
>> >
>> >start-stop-daemon has:
>> >   -c, --chuid username|uid[:group|gid]
>> 
>> Will a script doing this be portable to other Linuxes or even BSD
>> Unices?
>
>Good question and I think the answer is a no.
>
>So… instead of changing the script it may be better to provide a systemd unit 
>file for dirmngr, then the script can remain as it is.

This will also cause double effort since Debian needs special handling
that no other distribution obviously needs.

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


--
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/e1wjubz-00045l...@swivel.zugschlus.de

Re: systemd-fsck?

[Marc Haber]

On Sun, 11 May 2014 13:47:39 +0200, Laurent Bigonville
 wrote:
>For other distributions (and other Unix based OS) most of (all?) the
>initscripts are already different anyway.

Is it right to force that?

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


--
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/e1wjucj-00045t...@swivel.zugschlus.de

Re: Avoiding systemd

[Marc Haber]

On Sun, 11 May 2014 14:50:55 +0200, Florian Lohoff  wrote:
>There is no way to avoid the "userspace.exe" blob Debian is soon made of. 

To be fair, the major Linuxes will soon be made of that. Red Hat wants
it that way.

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


--
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/e1wjueg-00045i...@swivel.zugschlus.de

Re: systemd-fsck?

[Christian Hofstaedtler]

* Marc Haber  [140511 16:09]:
> On Sun, 11 May 2014 13:16:43 +0200, Martin Steigerwald
>  wrote:
> >Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber:
> >> On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois 
> >> 
> >> wrote:
> >> >Marc Haber  (2014-05-11):
> >> >> Just curious as the maintainer of another package using su in an init
> >> >> script since 2001, how am I supposed to start a non-root process from
> >> >> an init script?
> >> >
> >> >start-stop-daemon has:
> >> >   -c, --chuid username|uid[:group|gid]
> >> 
> >> Will a script doing this be portable to other Linuxes or even BSD
> >> Unices?
> >
> >Good question and I think the answer is a no.
> >
> >So… instead of changing the script it may be better to provide a systemd 
> >unit 
> >file for dirmngr, then the script can remain as it is.
> 
> This will also cause double effort since Debian needs special handling
> that no other distribution obviously needs.

Except that, on RHEL6(*), if you use `su -` (or similar) in your init
script, your service basically becomes unstoppable using the
standard mechanisms (except using a wild `kill` orgy).

*: which uses upstart as it's init

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-


-- 
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/20140511141844.ga21...@nq.home.zeha.at

Re: systemd-fsck?

[Christian Hofstaedtler]

* Marc Haber  [140511 16:12]:
> On Sun, 11 May 2014 13:47:39 +0200, Laurent Bigonville
>  wrote:
> >For other distributions (and other Unix based OS) most of (all?) the
> >initscripts are already different anyway.
> 
> Is it right to force that?

This is already true today for a long list of other reasons, and the
one thing more doesn't matter. (In other news, LSB init scripts work
nowhere except on Debian(-derivates).)

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-


-- 
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/20140511142004.gb21...@nq.home.zeha.at

Re: Alioth tracker

[Jörg Frings-Fürst]

Hi,

Am Sonntag, den 11.05.2014, 15:58 +0200 schrieb Daniel Pocock:
> 
> On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote:
> > Hi,
> > 
> > is someone processing the items on the Alioth tracker?
[...]
> 
> Other people have had problems with alioth too:
> 
> - write permissions on VCS directory for new projects

and by takeover as new maintainer.
It's really not good that a new package version is online and in Vcs is
only a old version.


> 
> - mailing list creation requests waiting for admin approval
> 
> On non-Debian sites (e.g. Sourceforge, github) things like this are
> fully automated (for better or worse).
> 
[...]

> For repositories:
> - would moving to a single tool (e.g. Git) make it easier to automate
> and help to eliminate the bugs we currently see on alioth?
> - could we have a debian.org solution (alioth or elsewhere) that
> automatically mirrors all Git repositories that DDs maintain themselves
> on github or other public locations?

and / or DD can approve the rights to the maintainers.

> Any of these things could help reduce the admin burden, maybe there are
> other approaches too?
+1


Regards,
Jörg



-- 
pgp Fingerprint: 7D13 3C60 0A10 DBE1 51F8  EBCB 422B 44B0 BE58 1B6E
pgp Key: BE581B6E
CAcert Key S/N: 0E:D4:56

Jörg Frings-Fürst
D-54526 Niederkail

IRC: j_...@freenode.net
 j_...@oftc.net






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

Re: Avoiding systemd

[Matthias Klumpp]

2014-05-11 15:55 GMT+02:00 Marc Haber :
> On Sun, 11 May 2014 14:50:55 +0200, Florian Lohoff  wrote:
>>There is no way to avoid the "userspace.exe" blob Debian is soon made of.
>
> To be fair, the major Linuxes will soon be made of that. Red Hat wants
> it that way.
Oh come on!
Do we really have to repeat the same init-FUD crap for all eternity on
any discussion like that?

Sidenote: I am pretty glad how people are working together to fix
init-transition related errors :-) (with people from upstart and
sysvinit-sides involved constructively as well, which is great and
will in the end lead to a pretty robust solution, I think)

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/


-- 
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/CAKNHny_phu=2ebnn6s805a8d001u2vlrxbcdiygogz_c2o6...@mail.gmail.com

Bug#747750: ITP: libtypes-uri-perl -- type constraints and coercions for URIs

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: libtypes-uri-perl
  Version : 0.001
  Upstream Author : Toby Inkster 
* URL : https://metacpan.org/release/Types-URI
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : type constraints and coercions for URIs

 Types::URI is a type constraint library suitable for use with Moo/Moose
 attributes, Kavorka sub signatures, and so forth.

This package is (indirectly) required by recent releases of
libweb-id-perl.

It will be maintained inside the pkg-perl team.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQF8BAEBCgBmBQJTb4xSXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ3NjQ4ODQwMTIyRTJDNTBFQzUxRDQwRTI0
RUMxQjcyMjM3NEY5QkQ2AAoJEE7BtyI3T5vWFuQH/ie0o8KaJgj0qZ4uFw6ob7YH
IPmJu30e6l5L45SF0LIoOe8xZS2pCnS/tmyFWQkQKdP4ET7D804+vLKRx8gmyil0
Ctqxk1IqEdNOtVkXPg8gk3RuE8BVkDk8bKiSpsHgxxYFJv8s2MC0HpYLJrJRTPwz
59e+nLX5kgJr3kBBOZjaOxfaT5rXatvBSMHfMi5P8xvc2cC3e9KKIpybfdR28ALQ
yWvIDDKD/cdyOWVk9qylKcDhU5gV4hwS14BvalNhuLmxvmNUmSqVYvX8goqGyRzR
KS49RFRRDqaWkx1kw+YOSMx+iptJr1kUUePJTQTXj6L0SS73uQrLR/EpSukzE24=
=zVO+
-END PGP SIGNATURE-


-- 
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/20140511144230.4845.64097.report...@bastian.jones.dk

Re: Alioth tracker

[Jonas Smedegaard]

Quoting Daniel Pocock (2014-05-11 15:58:50)
> On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote:
>> is someone processing the items on the Alioth tracker?

Thanks for raising that general question here, Ole.  I have been 
wondering too.


> Other people have had problems with alioth too:

[details snipped]

Please, for each item, refer to its bugreport, to encourage moving 
discussions on details to that bugreport, and only discuss the overview 
here.

The way you present it has a high risk of being interpreted as whining 
(which I am confident wasn't your intention).

> On non-Debian sites (e.g. Sourceforge, github) things like this are
> fully automated (for better or worse).

I believe some of the issues you mentioned has been recently been 
automated - but I prefer handling the details at each bugreport.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Avoiding systemd

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/11/2014 10:21 AM, Matthias Klumpp wrote:

> 2014-05-11 15:55 GMT+02:00 Marc Haber :
> 
>> On Sun, 11 May 2014 14:50:55 +0200, Florian Lohoff  wrote:
>> 
>>> There is no way to avoid the "userspace.exe" blob Debian is soon
>>> made of.
>> 
>> To be fair, the major Linuxes will soon be made of that. Red Hat
>> wants it that way.
> 
> Oh come on!
> 
> Do we really have to repeat the same init-FUD crap for all eternity
> on any discussion like that?

Not for all eternity, but probably for as long as any significant number
of people who are in a position to observe and participate in (or at
least jump into) such a discussion have those concerns, yes.

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTb47CAAoJEASpNY00KDJrnUMP/R/pHNCwpXjOGjiuuWvTFfsG
n8QptqAJvemqlc8vZ5oLUob+ifAreudYS2pkXKLfgXz1oj+36q3Jy9tqkKjyH17H
0NNJq17iJg41JHWYxtL9sQO28xqPsYX4jL/tuaKU00pejLmngZW6SN/chhSAUgjr
HO2X5P/S6zMDeeBrv5T21M6mPRs0DhlCCRxy8mcQ+qBH8hPd89Mk/YyYT7+4nQVr
a1NCWx0Lw57XMNI659ufwCysKrZGqQKar1FaZZfLy9WXxUeoGcd80e7OC+FwIRdn
bBS/7KVstpcjyLKvADL8ZPLPuq5zTHYkO1ItFda2hwSR6frL3dui58qFabpksV1L
gNAUido+lbD2svH1NIjgLqFBAThsEsjbSRp6ZiD0ZnFodSYzBjLs/AiX9K4/E8Fu
3km3LQlXb0OEBBXNAb+0eRLrXkBsY+8004Re1zfkG21XoTwwmUgbXLavRi9h6nDx
FpMWfv9SPKMGKPX5gn17RuctuRBGtlcL5lcVLfr0eCi7quG9WJ8plwv++1ilNtc/
lP3TGp/tsA4jcr13m8eB/RhxzsaS16NcsG0uhhCK59Udi0AtGK5ztNsytiu8+cPg
gu1BGWIQG9wWpIVhv1s4Q+xFseivPXlFxcAwjZ5jxMLpEafD8wDmbA6pD30VASIu
2mAcL3djnMVTNchOHcXJ
=EZs7
-END PGP SIGNATURE-


-- 
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/536f8ec2.2090...@fastmail.fm

Re: Deprecating/removing racoon/ipsec-tools from Debian GNU/Linux and racoon from Debian/kfreebsd

[Steven Chamberlain]

Hello,

I wish racoon/ipsec-tools could stay for just a little longer.  I'd like
some time to evaluate it, against the *SWAN implementations, for
GNU/kFreeBSD jessie.  IPSEC has not been enabled yet in Debian default
kernels, but it is a personal goal to have it in the jessie release.

When I last had the chance to work on this, racoon seemed like the best
available candidate due in part to a spate of security problems in
openswan/strongswan, and freeswan not being maintained any more IIRC.

I don't think systemd support should cause an issue for any existing
package until jessie+1.  And then I think systemd proponents should help
you with a unit file if one is needed.  And finally, it might still be
useful at least as a kfreebsd-any package.

When I have some time to resume work on IPSEC I hope I can then give
some helpful feedback.

Thanks,
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


-- 
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/536f9e4d.2070...@pyro.eu.org

Re: copyrighted embedded ICC profiles in images

[Bastien ROUCARIES]

On Sat, May 10, 2014 at 11:10 AM, Jérémy Lal  wrote:
> Hi,
>
> Jonas Smedegaard brought to my attention that an image file [0]
> can embed a copyrighted ICC profile without license.

Note that lintian detect these naked (not embeded) profile by default.

> Since it's something that not many people seems to be aware of,
> maybe it might be useful to have a lintian check for that.
>
> That command [1] shows positives on my /usr/share/
> Most of them are HP or Apple embedded profiles.
>
> Regards,
> Jérémy
>
>
> [0]
> http://www.color.org/profile_embedding.xalter
> [1]
> find . -regextype posix-extended -iregex '.*\.(jpg|png)' -exec sh -c
> 'identify -verbose "$0" | grep -i copyright && echo "$0"' {} \;
>
> (this shows also false positives with an empty Copyright field).
>
>
>
>
> --
> 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/1399713019.31695.3.camel@imac.chaumes
>


--
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/CAE2SPAaEj=t3orseprugagbv+vybwxkimnzgxvb5d_ecy44...@mail.gmail.com

Re: Alioth tracker

[Tollef Fog Heen]

]] Daniel Pocock 

> On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote:
>
> > What is the reason that the processing there is so slow? Is there a way
> > to change that?

I think it's quite clear and has been for a while that we need more
active admins for Alioth.

> Other people have had problems with alioth too:
> 
> - write permissions on VCS directory for new projects
> 
> - mailing list creation requests waiting for admin approval

Mailing lists are managed through gforge and there's no manual approval
process that I know of.

> Any of these things could help reduce the admin burden, maybe there are
> other approaches too?

Help fix bugs in fusionforge, hang out in #alioth try to help people and
we'd be happy to get more people involved.

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


-- 
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/m2bnv4jn8e@rahvafeir.err.no

Re: Avoiding systemd

[Russ Allbery]

The Wanderer  writes:

> Not for all eternity, but probably for as long as any significant number
> of people who are in a position to observe and participate in (or at
> least jump into) such a discussion have those concerns, yes.

Meanwhile, many of the nice, polite, calm, and constructive systemd folks
that you really want to have conversations with are completely burned out
by the non-stop sniping (for *months* now) by people like Kevin Chadwick,
who dominate every thread on the topic, and by and large have given up on
reading or responding to debian-devel threads.  So the people who are
interested in going another round on the fight, on both sides, are
dominating the discussion.

How do you think we should break out of this cycle?

The impression that one gets (which admittedly is coming from a position
of exhaustion with the whole thing) is that you think all systemd
advocates should behave like saints regardless of provocation, and are
holding that up as the only behavior that will convince you that the
systemd community aren't all assholes.  I don't think that's the
impression you want to send, but somehow building a different impression
is probably key to breaking this cycle.

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


-- 
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/87ha4wguge@windlord.stanford.edu

Re: systemd-fsck?

[Laurent Bigonville]

Marc Haber wrote:
> On Sun, 11 May 2014 13:16:43 +0200, Martin Steigerwald
>  wrote:
> >Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber:
> >> On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois
> >> 
> >> 
> >> wrote:
> >> >Marc Haber  (2014-05-11):
> >> >> Just curious as the maintainer of another package using su in
> >> >> an init script since 2001, how am I supposed to start a
> >> >> non-root process from an init script?
> >> >
> >> >start-stop-daemon has:
> >> >   -c, --chuid username|uid[:group|gid]
> >> 
> >> Will a script doing this be portable to other Linuxes or even BSD
> >> Unices?
> >
> >Good question and I think the answer is a no.
> >
> >So… instead of changing the script it may be better to provide a
> >systemd unit file for dirmngr, then the script can remain as it is.
> 
> This will also cause double effort since Debian needs special handling
> that no other distribution obviously needs.

Could you please explain me how it could cause double effort as the
initscript the the dirmngr package is shipping is _already_ debian
specific and that I don't see any initscript shipped by upstream in the
tarball?

The initscript had to be fixed anyway, I could indeed have also added a
systemd sevice file but I didn't think it will fit a NMU.


--
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/20140511184846.285c7...@fornost.bigon.be

Re: ignoring bugs with no maintainer (Re: Removal of emacs23 from unstable/testing)

[Ben Hutchings]

On Sun, 2014-05-11 at 15:39 +0200, Santiago Vila wrote:
> On Sat, May 10, 2014 at 06:56:24PM +0200, Holger Levsen wrote:
> > I believe all those bugs should be either reassigned to emacs23 (and soon 
> > 24) 
> > or just be closed with an informal message, also offering to reopen and 
> > reassign to emacs23/24 if applicable. [...]
> 
> Closing them would be a disservice to our users.

But it is less of a disservice than ignoring it completely.

[...]
> So, the natural thing to do would be to reassign them. 

I think the natural thing to do is to close with a message explaining
how to reopen and reassign if the bug is still present in emacs24.

Alternately, ask whether it is still present and then reassign/close
depending on the response (or lack of response within a time limit).

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.


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

Re: systemd-fsck?

[Helmut Grohne]

On Sat, May 10, 2014 at 03:38:24PM -0700, Steve Langasek wrote:
> As the maintainer of the pam package in Debian, I assure you: this is a bug
> in dirmngr.  System services should not (must not) call interfaces that
> launch pam sessions as part of their init scripts.  su is one of those
> interfaces.

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
this is not solely a problem to be solved in individual packages.

It is not the first time we are facing this kind of breakage. A very
similar case recently happened when shells of system users were switched
to nologin. It broke quite a few packages, still that change was
accomplished and the offending packages (at least most of them) were
fixed.

Can we please have a MBF on this issue, fix the packages and have
systemd gain Breaks for all the packages it highlights this bug on? And
until systemd has the relevant Breaks, it should have a
transition-blocker RC bug. We do have procedures for these kinds of
things.

Thanks

Helmut

[1] http://codesearch.debian.net/search?q=su+-c+path%3Adebian%2F+path%3Ainit
Apparently the query misses more results such as
http://sources.debian.net/src/ejabberd/2.1.11-1/debian/init.d
http://sources.debian.net/src/fetchmail/6.3.26-1/debian/init
http://sources.debian.net/src/nvi/1.81.6-11/debian/init
Very likely there is more.


-- 
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/20140511173734.ga14...@alf.mars

Re: systemd-fsck?

[Marc Haber]

On Sun, 11 May 2014 18:48:46 +0200, Laurent Bigonville
 wrote:
>Marc Haber wrote:
>> This will also cause double effort since Debian needs special handling
>> that no other distribution obviously needs.
>
>Could you please explain me how it could cause double effort as the
>initscript the the dirmngr package is shipping is _already_ debian
>specific and that I don't see any initscript shipped by upstream in the
>tarball?

This is a general problem, not only one of dirmngr.

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


--
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/e1wjxgo-0005c6...@swivel.zugschlus.de

Re: copyrighted embedded ICC profiles in images

[Bastien ROUCARIES]

On Sun, May 11, 2014 at 5:58 PM, Bastien ROUCARIES
 wrote:
> On Sat, May 10, 2014 at 11:10 AM, Jérémy Lal  wrote:
>> Hi,
>>
>> Jonas Smedegaard brought to my attention that an image file [0]
>> can embed a copyrighted ICC profile without license.
>
> Note that lintian detect these naked (not embeded) profile by default.
>
>> Since it's something that not many people seems to be aware of,
>> maybe it might be useful to have a lintian check for that.
>>
>> That command [1] shows positives on my /usr/share/
>> Most of them are HP or Apple embedded profiles.

Note that pdf are also affected ...
>>
>> Regards,
>> Jérémy
>>
>>
>> [0]
>> http://www.color.org/profile_embedding.xalter
>> [1]
>> find . -regextype posix-extended -iregex '.*\.(jpg|png)' -exec sh -c
>> 'identify -verbose "$0" | grep -i copyright && echo "$0"' {} \;
>>
>> (this shows also false positives with an empty Copyright field).
>>
>>
>>
>>
>> --
>> 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/1399713019.31695.3.camel@imac.chaumes
>>


--
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/CAE2SPAauMTKKjMmm=wu2hhj22yrdzgx6174fcngtfoymcjc...@mail.gmail.com

Re: correct use of su

[Kevin Chadwick]

previously on this list Steve Langasek contributed:

> Yes.  This has been the case for su in Debian since 1999, and to do
> otherwise would break a variety of configurations where session setup is
> required in order for, e.g., the su process to have access to the files of
> the target user.

It seems to me that someone needlessly? dropped the ball in 1999 then
and this should have perhaps been a new flag or added to -l where PAM
is in use, as it fundamentally changes the behaviour contrary to the
varying titles of su.

Now done of course and for so long I wouldn't know what the fallout to
debian and other things would be and so the best way to fix this bug
today at all. I do know that I would much prefer if a script in rc.local
that uses su to drop priviledges and maybe even then sudo to re-gain
one or two worked on all unix-like systems and without having to deal
with debians overly complex scripts in comparison to bsd or create a
systemd unit (I think it's clear I wouldn't). However as I don't use
polkit and use sudo to handle my suspending and shutdowns I think I
probably could without issue anyway? 

Not being a PAM fan but only locking it down a little on systems with
it. I can't say I fully understand the weight of grounds with which
"must not" was stated though.

I hope I don't get flamed as I am not enjoying or intentionally bashing
these things for any political reason and I'm actually rather busy. I
simply strive for what I see as simpler and better alternatives in ease
of use/config and lack of exploits and don't believe I should have to
hide anything.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
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/248613.30904...@smtp148.mail.ir2.yahoo.com

systemd-sysv: #747535 Was: Re: systemd-fsck?

[Svante Signell]

severity 747535 serious
thanks

Please Tollef :(

On Sun, 2014-05-11 at 09:00 +0200, Marc Haber wrote:
> On Sat, 10 May 2014 20:57:28 +0100, Ben Hutchings
>  wrote:
> >On Sat, 2014-05-10 at 19:53 +0200, Jakub Wilk wrote:
> >> * Matthias Urlichs , 2014-05-10, 19:13:
> >> >Every compiler toolchain upgrade breaks a bunch of packages,
> >> 
> >> For end users? I don't think so.
> >
> >If a package is not changed to fix the FTBFS, then it will be removed
> >from testing and will miss the next release.  The effect on end users is
> >not immediate (package is still in stable and unstable) but there is
> >breakage that other maintainers need to fix.
> 
> The effect is not immediate, yes. An unwanted change to systemd not
> supporting a feature that it vital to booting non-trivial crypto disk
> schemes is immediate on unstable users, and since systemd maintainers
> do not consider this an RC bug, it wil make testing systems unbootable
> in two weeks time.

Can we please separate the bugs in this thread: This one is about
systemd-sysv being dragged in by network-manager and gdm3  via
libpam-systemd, effectively changing init system to systemd _without_
notifying the user, not dirmngr using sudo or start-stop-daemon:#668890,
#670700




-- 
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/1399832419.2096.114.camel@PackardBell-PC

dirmngr:#668890, #670700 Was: Re: systemd-fsck?

[Svante Signell]

On Sun, 2014-05-11 at 18:48 +0200, Laurent Bigonville wrote:
> Marc Haber wrote:
> > On Sun, 11 May 2014 13:16:43 +0200, Martin Steigerwald
> >  wrote:
> > >Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber:
> > >> On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois
> > >> 
> > >> 
> > >> wrote:
> > >> >Marc Haber  (2014-05-11):
> > >> >> Just curious as the maintainer of another package using su in
> > >> >> an init script since 2001, how am I supposed to start a
> > >> >> non-root process from an init script?
> > >> >
> > >> >start-stop-daemon has:
> > >> >   -c, --chuid username|uid[:group|gid]
> > >> 
> > >> Will a script doing this be portable to other Linuxes or even BSD
> > >> Unices?
> > >
> > >Good question and I think the answer is a no.
> > >
> > >So… instead of changing the script it may be better to provide a
> > >systemd unit file for dirmngr, then the script can remain as it is.
> > 
> > This will also cause double effort since Debian needs special handling
> > that no other distribution obviously needs.
> 
> Could you please explain me how it could cause double effort as the
> initscript the the dirmngr package is shipping is _already_ debian
> specific and that I don't see any initscript shipped by upstream in the
> tarball?
> 
> The initscript had to be fixed anyway, I could indeed have also added a
> systemd sevice file but I didn't think it will fit a NMU.

Can we please separate the bugs in this thread: This one is about
dirnmgr not network-manager and gdm3 dragging in systemd as init
default, #747535.



-- 
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/1399832433.2096.116.camel@PackardBell-PC

Re: Avoiding systemd

[Kevin Chadwick]

previously on this list Russ Allbery contributed:

> by the non-stop sniping (for *months* now) by people like Kevin Chadwick,

Well I have only responded to incorrect statements and have tried to
ignore any that are not from debian developers and may not affect the
future of debian but you can't always tell if the person is a debian
developer or not (no @debian.org or footer).

I shall do myself and some of you a favour however but maybe not the
world and unsubscribe as I think I will be unable to ignore everything
especially incorrect or innacurate sweeping statements such as found
on the following link which I assume is a form of consensus from the
developers.

https://wiki.debian.org/Debate/initsystem/systemd

"Embedded systems benefit from speed improvements, shell-less design,
ability to remove optional components, and lower memory footprint."

Perhaps I should mention that some of my work involves programming
embedded systems including linux and deeper embedded.

I have been considering my options (Slackware, but hopefully and
most beneficially Openbsd and a linux kernel) recently anyway and
whilst I won't cut off my nose to spite my face. I have been wondering
if whilst having debian repos available of so many packages is
convenient offline perhaps it is limiting me to an out of date subset
of available compilable code when most additional tools are small and I
am quite capable of fixing any issues with impact. Threads have also
brought into question the security of those repos and DVDs, where I
thought it was rather higher (atleast I know how trustable a program is
if I download it manually).

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
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/773142.30904...@smtp148.mail.ir2.yahoo.com

Re: systemd-fsck?

[Kevin Chadwick]

previously on this list Matthias Urlichs contributed:

> I haven't yet seen a system where booting with init=/bin/bash works but
> booting systemd in emergency mode does not.

Have you added me to a killfile?

I mentioned such a bug as happened in Arch testing in this very thread
or do you mean a debian system?

How it wasn't found before hitting testing beats me but doesn't
surprise me on arch. I imagine it wouldn't happen even on debian
experimental as I would hope upstream code would be tested out of
tree first? I got the impression it was a systemd release with the
segfault but find that hard to believe too but perhaps arch used pid1
differently to upstream testers.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
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/639917.30904...@smtp148.mail.ir2.yahoo.com

Re: systemd-fsck?

[Kevin Chadwick]

previously on this list Matthias Urlichs contributed:

> > Will a script doing this be portable to other Linuxes or even BSD
> > Unices?
> >   
> No. BSD has daemon(8). If you want portability, you probably need to check
> what's available. (start-stop-daemon, daemon (on BSDs), sudo)
> 

I can tell you that not all systems (pclinux os and others) have sudo
though I think they should and why should people know or re-learn how
to use sudo for that. The only portable and intuitive thing almost
guaranteed to be available is su, atleast it was.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
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/273168.30904...@smtp148.mail.ir2.yahoo.com

Bug#747812: ITP: python-fysom -- fysom provides a python finite state machine

[Marcin Kulisz (kuLa)]

Package: wnpp
Severity: wishlist
Owner: "Marcin Kulisz (kuLa)" 

* Package name: python-fysom
  Version : 1.0.15
  Upstream Author : Maximilien Riehl 
* URL : https://github.com/mriehl/fysom
* License : MIT
  Programming Lang: Python
  Description : fysom provides a python finite state machine

This standalone python micro-framework providing a finite state machine.


-- 
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/20140511185406.2368.84564.report...@bashton004.kulisz.net

Re: Alioth tracker

[Daniel Pocock]

On 11/05/14 18:26, Tollef Fog Heen wrote:
> ]] Daniel Pocock 
> 
>> On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote:
>>
>>> What is the reason that the processing there is so slow? Is there a way
>>> to change that?
> 
> I think it's quite clear and has been for a while that we need more
> active admins for Alioth.
> 
>> Other people have had problems with alioth too:
>>
>> - write permissions on VCS directory for new projects
>>
>> - mailing list creation requests waiting for admin approval
> 
> Mailing lists are managed through gforge and there's no manual approval
> process that I know of.


When creating a list, it tells me the list will be approved within 6-24
hours

Previously when I created lists, I would receive an email from mailman
some hours later giving me the list password - this is the usual mailman
behavior when the mailman site admin approves a list.  Maybe that is
entirely within mailman and not gforge.

>> Any of these things could help reduce the admin burden, maybe there are
>> other approaches too?
> 
> Help fix bugs in fusionforge, hang out in #alioth try to help people and
> we'd be happy to get more people involved.

If people have not already stepped forward to fill these gaps then that
is the very reason why I was suggesting further automation or cutting
back on things like legacy VCS support.

Hopefully the burden of support and the capacity of volunteers will then
converge at a point where it is sustainable.

I'm not criticizing anybody for this situation, nor am I trying to prod
anybody into action - I just feel that if volunteers are limited, it is
better to constrain the scope of the service.


-- 
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/536fd070.1090...@pocock.pro

Re: Alioth tracker

[Tollef Fog Heen]

]] Daniel Pocock 

> On 11/05/14 18:26, Tollef Fog Heen wrote:
> > ]] Daniel Pocock 
> > 
> >> On 08/05/14 12:27, Оlе Ѕtrеісhеr wrote:
> >>
> >>> What is the reason that the processing there is so slow? Is there a way
> >>> to change that?
> > 
> > I think it's quite clear and has been for a while that we need more
> > active admins for Alioth.
> > 
> >> Other people have had problems with alioth too:
> >>
> >> - write permissions on VCS directory for new projects
> >>
> >> - mailing list creation requests waiting for admin approval
> > 
> > Mailing lists are managed through gforge and there's no manual approval
> > process that I know of.
> 
> 
> When creating a list, it tells me the list will be approved within 6-24
> hours

Hmm, I think that approval is automatic.  At least I haven't seen any
nagging from fusionforge to approve mailing lists.

> >> Any of these things could help reduce the admin burden, maybe there are
> >> other approaches too?
> > 
> > Help fix bugs in fusionforge, hang out in #alioth try to help people and
> > we'd be happy to get more people involved.
> 
> If people have not already stepped forward to fill these gaps then that
> is the very reason why I was suggesting further automation or cutting
> back on things like legacy VCS support.

Automating things takes effort too.

> Hopefully the burden of support and the capacity of volunteers will then
> converge at a point where it is sustainable.
> 
> I'm not criticizing anybody for this situation, nor am I trying to prod
> anybody into action - I just feel that if volunteers are limited, it is
> better to constrain the scope of the service.

I'm not disagreeing, I think we're providing a much poorer service level
for Alioth than what we should do.  Sadly, I don't have the motivation
to spend much time there nowadays.

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


-- 
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/87bnv4nm0l@xoog.err.no

Re: ignoring bugs with no maintainer (Re: Removal of emacs23 from unstable/testing)

[Santiago Vila]

On Sun, May 11, 2014 at 06:29:22PM +0100, Ben Hutchings wrote:
> On Sun, 2014-05-11 at 15:39 +0200, Santiago Vila wrote:
> [...]
> > So, the natural thing to do would be to reassign them. 
> 
> I think the natural thing to do is to close with a message explaining
> how to reopen and reassign if the bug is still present in emacs24.

Hmm. What if the user changed email address and does not reply? We are
not interested in fixing the bug anymore?

If we are going to close bugs because the email from the submitter
is no longer valid, we don't need a package name change like
"emacs23 -> emacs24" for that, we could close every bug which is old
enough with a message saying "We are closing this bug to check that
your email is still valid. Please reopen if it is".

Perhaps we need to do something about packages having too many open
bugs. I don't know. But please don't use package renames as an excuse
for doing it wrong.


-- 
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/20140511195535.ga8...@cantor.unex.es

Bug#747823: ITP: confiture -- Python library to parse configuration files

[Antoine Millet]

Package: wnpp
Severity: wishlist
Owner: Antoine Millet 

* Package name: confiture
  Version : 2.0 
  Upstream Author : Antoine Millet 
* URL : https://github.com/NaPs/Confiture
* License : MIT
  Programming Lang: Python
  Description : Python library to parse configuration files

A Python library to parse highly structured, hierarchical, configuration
files using a developer friendly API. The configuration format lets one create
nested sections of any deep, typing (string, number, boolean or list)
and external file inclusion.

Confiture also embeds a powerful schema validation system allowing to
define composite types (like "file" or "ip address") and provides an
integration with the argparse module.

This package will be submitted to the Python Modules Packaging Team.


-- 
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/20140511204736.4984.28434.reportbug@jerk

Re: systemd-fsck?

[Michael Biebl]

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.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: ignoring bugs with no maintainer (Re: Removal of emacs23 from unstable/testing)

[Santiago Vila]

On Sat, May 10, 2014 at 06:56:24PM +0200, Holger Levsen wrote:
> Having these bugs rott in a corner of the BTS almost nobody ever looks at is 
> a 
> disservice to our users. IMO there should be 0 bugs open against 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=

If that's really desirable, I wonder if it would be possible for our
BTS to keep these bugs assigned to the "last maintainer" the package
had in its lifetime. That would be better than "unknown" in most cases.


-- 
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/20140511204923.ga9...@cantor.unex.es

Re: systemd-fsck?

[Michael Biebl]

Am 10.05.2014 08:06, schrieb Norbert Preining:
> One of the things that systemd breaks (not checked on Debian, but
> on other systems), is that screen session are killed when logging out
> of the ssh session.
> 
> This is a *fundamental* change in behaviour, and does break a lot
> of setups and systems.

While you can configure systemd to kill screen sessions when the users
logs out, the default in Debian isn't setup this way.
So please refrain before making such broad and uninformed statements.
They could easily be mistaken as FUD.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: systemd-fsck?

[Cameron Norman]

El Sun, 11 de May 2014 a las 1:49 PM, Michael Biebl  
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: systemd-fsck?

[Michael Biebl]

Am 11.05.2014 22:49, schrieb Michael Biebl:
> 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.

Seems this codesearch query was incomplete indeed.

I did a grep over a local archive checkout (from 2014-01-11)

The result is 62 occurences of the string "su ", in 40 different SysV
init scripts (see attachement). Still a quite manageable number.



Michael




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
auth2db/init.d/auth2db: su -p -s /bin/sh "$USER" -c "$DAEMON $1 
3>/dev/null"
bucardo/init.d/bucardo: su bucardo --command "$DAEMON start"
bucardo/init.d/bucardo: su bucardo --command "$DAEMON reload_config"
bucardo/init.d/bucardo: su bucardo --command "$DAEMON stop"
buildbot/init.d/buildmaster:su -s /bin/sh \
buildbot-slave/init.d/buildslave:su $suopt - ${SLAVE_USER[$mi]} \
clamav-freshclam/init.d/clamav-freshclam:  su "$DatabaseOwner" -p -s /bin/sh -c 
"freshclam -l $UpdateLogFile --datadir $DatabaseDirectory"
console-log/init.d/console-log:  if su --shell=$SHELL --command="head -n 1 
$file" $USER > /dev/null 2>&1; then
couchdb/init.d/couchdb:if su $COUCHDB_USER -c "$command"; then
cpushare/init.d/cpushare:   if ! su nobody -c 
/usr/lib/cpushare/seccomp-test >/dev/null 2>&1; then
dirmngr/init.d/dirmngr: output=$(su -c ". /lib/lsb/init-functions && 
umask 027 && start_daemon -p $PIDFILE $DAEMON --daemon --sh" dirmngr) || return 
1
distributed-net/init.d/distributed-net: su daemon -c "chrt -b 0 
$DAEMON $OPTIONS"
distributed-net/init.d/distributed-net: su daemon -c "$DAEMON 
$OPTIONS -shutdown" > /dev/null 2>&1
distributed-net/init.d/distributed-net: su daemon -c "$DAEMON 
$OPTIONS -restart" 2> /dev/null
distributed-net/init.d/distributed-net: su daemon -c "$DAEMON 
$OPTIONS -restart" 2> /dev/null
distributed-net/init.d/distributed-net: su daemon -c "$DAEMON $OPTIONS 
-fetch"
distributed-net/init.d/distributed-net: su daemon -c "$DAEMON $OPTIONS 
-flush"
distributed-net/init.d/distributed-net: su daemon -c "$DAEMON $OPTIONS 
-update"
echolot/init.d/echolot: su "$USER" -c "$command"
ejabberd/init.d/ejabberd:su $EJABBERDUSER -c "$EJABBERDCTL $action" 
>/dev/null
ejabberd/init.d/ejabberd:su $EJABBERDUSER -c "$EJABBERD -noshell -detached"
ejabberd/init.d/ejabberd:exec su $EJABBERDUSER -c "$EJABBERD"
fetchmail/init.d/fetchmail: su -s /bin/sh -c 
"/usr/bin/strace -tt $* $DAEMON $OPTIONS --nosyslog --nodetach -v -v" $USER <&- 
2>&1
fetchmail/init.d/fetchmail: su -s /bin/sh -c "$DAEMON 
$OPTIONS --nosyslog --nodetach -v -v" $USER <&- 2>&1
flumotion/init.d/flumotion: su -s /bin/sh -c "umask 026; unset HOME; $1" 
flumotion
freevo/init.d/freevo_encodingserver:  exec su --shell /bin/sh freevo -c "$0 $@"
freevo/init.d/freevo_recordserver:  exec su --shell /bin/sh freevo -c "$0 $@"
freevo/init.d/freevo_rssserver:  exec su --shell /bin/sh freevo -c "$0 $@"
freevo/init.d/freevo_webserver:  exec su --shell /bin/sh freevo -c "$0 $@"
freevo/init.d/freevo_xserver: openvt -f -c 9 -- su --shell /bin/sh freevo -c  
"startx  $DAEMONLOG   -- :1 vt9  -quiet"
freevo/init.d/freevo_xserver:su --shell /bin/sh freevo -c "$DAEMON --stop"
freevo/init.d/freevo_xserver:su --shell /bin/sh freevo -c "$DAEMON --stop"
gozerbot/init.d/gozerbot:   su $RUNUSER -c "$NAME >> 
/var/log/gozerbot.log 2>&1 &"
gozerbot/init.d/gozerbot:   su $RUNUSER -c gozerbot-init
inn2/init.d/inn2:su news -c /usr/lib/news/bin/rc.news > 
/var/log/news/rc.news 2>&1
inn2/init.d/inn2:su news -c '/usr/lib/news/bin/rc.news stop' >> 
/var/log/news/rc.news 2>&1
jenkins/init.d/jenkins:# so we let su do so for us now
jenkins-slave/init.d/jenkins-slave:# so we let su do so for us now
jsonbot/init.d/jsonbot:   su $RUNUSER -c "jsb-fleet -d $DATADIR 
$ARGSTRING 2>/dev/null &"
jsonbot/init.d/jsonbot:   su $RUNUSER -c "jsb-init -d /var/cache/jsb"
lfc-dli/init.d/lfc-dli:$DAEMON "su $LFCUSER -c \"$DLIDAEMON -l 
$DLIDAEMONLOGFILE\""
libapache2-mod-shib2/init.d/shibd:DIAG=$(su -s $DAEMON $DAEMON_USER -- 
-t $DAEMON_OPTS 2>/dev/null)
nethack-common/init.d/nethack-common:# a child shell through 'su -c', 
so instead we use a helper
nethack-common/init.d/nethack-common:su --shell=/bin/sh -c 
/usr/lib/games/nethack/recover-helper "$owner"
nvi/init.d/nviboot:

Re: ignoring bugs with no maintainer (Re: Removal of emacs23 from unstable/testing)

[Don Armstrong]

On Sat, 10 May 2014, Holger Levsen wrote:
> On Mittwoch, 7. Mai 2014, Rob Browning wrote:
> > If we can, I'd like to remove emacs23 from unstable/testing before the
> > freeze.  To make that possible, any relevant packages will need to
> > migrate to emacs24, or just include support for emacs24.
> 
> what's your plan for dealing with old bugs against emacs23? 

The right solution for these (and other bugs which happen when source
packages are renamed) is for the bugs to follow the new source package
name.

Eventually this is the way it will work in the BTS, but doing so
requires me to complete the postgresql migration work.

-- 
Don Armstrong  http://www.donarmstrong.com

All bad precedents began as justifiable measures.
 -- Gaius Julius Caesar in "The Conspiracy of Catiline" by Sallust


-- 
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/20140511215214.gk13...@teltox.donarmstrong.com

Re: Alioth tracker

[Charles Plessy]

Le Sun, May 11, 2014 at 03:58:50PM +0200, Daniel Pocock a écrit :
> 
> Other people have had problems with alioth too:
> 
> - write permissions on VCS directory for new projects
> 
> - mailing list creation requests waiting for admin approval

Thanks Daniel for raising the issue.

For mailing lists, I read in the thread that it may not be a problem anyway,
but I just wanted to add one thing: in many cases the lists to be created are a
maintainer list and a commit list, and this could be replaced completely by the
“new PTS” (see http://dep.debian.net/deps/dep2/ and http://pts.debian.net/).
People who have time to give but do not have the right skill set to work on
Alioth or Mailman may consider helping the new PTS instead.

Cheers,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20140511225715.gb13...@falafel.plessy.net

Re: copyrighted embedded ICC profiles in images

[David Prévot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

>> Le samedi 10 mai 2014 à 13:37 +0100, Ben Hutchings a écrit :

>>> This sounds like a ludicrous overreach of copyright.  Isn't an ICC
>>> descriptive, rather than creative?

According to the International Color Consortium, profiles provide
content that “vendor […] can copyright.” [0]

0: http://www.color.org/faqs.xalter#p14

Regards

David

P.-S.: Full quote of the FAQ item for d-d readers benefits follows.


Q. Are profiles copyrighted?

A. ICC has no formal position on the use of profiles. It is really up to
the software vendor. However, since the software vendor effectively
holds copyright on the profile (which is specified in a tag) the licence
to use their software permits them to prohibit public posting of
profiles. One of their motivations could be that if such profiles could
be freely exchanged it would limit the number of sales of their
software. Also, from a technical perspective it is dangerous to publish
such profiles for many devices. A profile for a printer, for example, is
only valid for the substrate and inks for which it was made and it is
for this reason that few device manufacturers publish profiles for their
devices.

Any ICC profile is produced using proprietary software. All ICC define
is the nature of the tags, which tags are mandatory and which are
optional, and how the data should be defined in them. The contents of
the tables are vendor specific and each uses different algorithms. It is
this that gives the vendor something which they can copyright.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJTcAHmAAoJEAWMHPlE9r08FaMIAJT9hrc2hcNPqeKAypkBzF1m
yRQNrt1WhI+JMH5Fb+vTIJiT5gXtBVuHX3g33fsP3P60wIEjH+VX8hZ2nm0nUa+V
/Kjb1YqNTKbIXF8pOS3L719dX9PmylESmokGzCRnLc7OLEopHrFV5Mfu4CRyFy8M
s5BhECwnhELih8i0vPKYhiCSFe/HW9WATTXGe+v8BVfuZy2dkA7HVVoJfv/Vf1s5
OoOBZP8q371in9ttsNg0QSbcqkmSXRk9O1L8e/NYm0N83IDENOOL0Q92kl4KPUUb
tBvaAyj8hkIeXzHo8G0Oldlw04M24TVYzyaQgy+A4MONE6x6Px4Lww2KC3sTb1c=
=ok8T
-END PGP SIGNATURE-


-- 
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/537001e7.8080...@debian.org

Re: Alioth tracker

[Russell Stuart]

On Sun, 2014-05-11 at 21:38 +0200, Tollef Fog Heen wrote:
> I'm not disagreeing, I think we're providing a much poorer service level
> for Alioth than what we should do.  Sadly, I don't have the motivation
> to spend much time there nowadays.

I have for years hosted my own projects in a minimalistic fashion [0],
and as a consequence have been nagged to provide "modern amenities" like
issue trackers and DCVS.  The obvious solution would be to move to free
hosting like sourceforge, but sourceforge is closed source.  Then I
joined Debian.  Alioth seemed like a natural fit, so I started moving my
projects to it.

But now I've decided that's not such a good idea.  Not because of some
of the issues mentioned in this thread - like DVCS support of lacking
features in Fusion Forge.  I can work around them.

My problem is Alioth isn't reliable enough.  In week or so I used it:

a.  As Ole mentioned, there are 180 odd open support requests, dating
back 7 years.  It's not that things aren't being done - Stephen Gran
in particular appears to regularly attend to the list and close
issues.  However, there should be no support requests open for more
than a few weeks (and ideally at most a couple of days).  Many of
these old "support requests" are bugs or features, and there are
separate trackers for those.  In other words, the support list needs
to be triaged.  If after triage there are still support requests
more than a month old, the clearly Alioth needs extra admin
manpower.  Right now it is difficult to tell if manpower is really
the issue.

b.  For a while when I was using it is was horribly slow (as in taking
minutes to send a response to a HTTP request).  I could not see
why.  After a day or so the issue went away and it because usable
again.

c.  Then I started getting mysterious failures.  After a bit of digging
around I noticed /tmp was at 100%.  Someone fixed this after a few
hours.

d.  At the same time I noticed disk space it is sitting 94% usage.
The amount of disk used is under 600GB.

e.  I suspect running out of disk space on /tmp caused a number of
other issues for me [1].  The details aren't relevant here.  What is
relevant is in order to diagnose what was going I poked around the
file system, and noticed a number of other much older projects were
suffering from the same issues.  Since this means among other things
they can't use the DVCS, presumably they had been abandoned.

f.  After seeing all this, I decided I had better do some "due
diligence" and what backup arrangements were in place.  As far as
I can tell there aren't any.

At this point I reluctantly decided I had to use why I was trying to
avoid - a commercial provider running close source.

If three things changed on Alioth I would move back.  They are:

A.  Solve the disk space problems.
B.  A backup system.
C.  Support list triaged, and it's length viewed as a KPI.

If the Alioth team thinks I could be useful in getting this things done,
I'd be happy to become part of it.  Even if they don't, I'd be happy to
donate 2 x 4TB drives so the disk space issue can be fixed - assuming
there are remote hands available to fit them.

[0]  http://www.stuart.id.au/russell/files
[1]
https://alioth.debian.org/tracker/index.php?func=detail&aid=314680&group_id=1&atid=21


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

Re: Alioth tracker

[Paul Wise]

On Mon, May 12, 2014 at 8:27 AM, Russell Stuart wrote:

> sourceforge is closed source.

That is no longer the case, sourceforge folks implemented a new
codebase called Allura, are running it, released it under the Apache
license and continue to develop it as an Apache Software Foundation
project.

http://allura.apache.org/
http://sourceforge.net/projects/allura/

> B.  A backup system.

The Debian sysadmins have backups of alioth in place.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/CAKTje6EJEJErnnc4f=E5v=-g6ylfzv1fmestmeknthvqdog...@mail.gmail.com

Re: systemd pulled in automatically

[Bas Wijnen]

On Sun, May 11, 2014 at 08:20:33PM +0200, Svante Signell wrote:
> Can we please separate the bugs in this thread: This one is about
> dirnmgr not network-manager and gdm3 dragging in systemd as init
> default, #747535.

Speaking of that, I made a suggestion that AFAIK fixes the issue, which isn't
in the bug log yet.  So here it is again:

If the order of the dependencies of libpam-systemd is switched, so it becomes
systemd-shim | systemd-sysv, the result will be:
- If systemd is not installed, systemd-shim will be installed and the original
  init system will continue functioning.
- If systemd is installed, it will satisfy this dependency and systemd-shim
  will not be installed.

Sounds like exactly what I would expect when upgrading random other packages
such as Network Manager.  Systemd is not "the next version of my init system",
and switching to it is a switch, not an upgrade.  It shouldn't happen
automatically as if it is an upgrade.  Especially because there is no technical
reason for it at all.

This dependency order is different from the "regular" order of dependencies,
where the recommended alternative is listed first.  There is a good reason for
this.  The recommended alternative is an init system, which replaces other init
systems.  For other packages, the main question is "if this functionality is
not installed on the system yet, which package do we recommend to use for it?"
But that question is not applicable here, because there always is an init
system installed.

Thanks,
Bas


-- 
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/20140512010139.gv10...@fmf.nl

Re: Avoiding system d

[Carlos Alberto Lopez Perez]

On 11/05/14 09:18, Marc Haber wrote:
> On Sat, 10 May 2014 19:47:10 +0100, Brian 
> wrote:
>> On Sat 10 May 2014 at 12:05:25 -0400, John wrote:
>> A couple of quotes from your mail:
>>  > "I find myself appalled at the rude and domineering attitudes of
>>  > almost all systemd's defenders."
>>
>> You're not looking for flames? You're kidding, aren't you? Your technical
>> question is wrapped up in flame-baiting.
> 
> Sorry if that comes around at flame-baiting, but John describes the
> way the systemd world socially interacts with its outside quite
> accurately. It is the same for me: social interaction with systemd
> (and this includes reading bug reports and mailing lists without
> participating actively) takes fun out of using Linux for me just for
> the social sake.
> 
> Something along the lines of systemd is technically needed and a good
> idea, but the people behind it do not come along nice.
> 

Completely agree.

I think the following article resumes very well the attitude of those
developers pushing for systemd:

"""
The systemd developers are responding to upstart and launchd and android
init as things they must _defeat_, an establish a new standard by
crushing all the competing implementations. This means developers who
want gradual staged transitions, and thus ask questions like "what if I
don't want to switch yet", or "how do I get the old behavior out of the
new thing", are enemies of systemd. Those questions are anathema to the
systemd plan for world domination, if you're not using their stuff
already you're the enemy, a relic of history to be buried. We can't opt
out and see how it goes, we must fight to stay where we are. The systemd
developers are basically taking the Microsoft approach to development:
they don't want you to have the option of NOT using their stuff.
""" http://www.landley.net/notes.html#23-04-2014

About the original question of John:

I think that apt/preferences is not the best way to avoid something to
be installed. I tried it on the past, and when apt don't has another way
of solving the dependencies it will install the unwanted package anyway.

The most efficient way I found to avoid a package to be installed, is to
create a meta-package that conflicts with the one(s) you want to avoid,
and put that package on hold.

Thorsten has uploaded a package that conflicts with the systemd ones
[1], you can install it, and put it on hold. That should avoid any
systemd bits on your system until you unhold or remove the package
systemd-must-die.

To put it on hold (after installing it):

echo systemd-must-die hold | sudo dpkg --set-selections

And check that it is on hold with:

dpkg --get-selections | grep hold


Regards!


[1]
http://article.gmane.org/gmane.linux.debian.devel.general/193110
http://users.unixforge.de/~tglaser/debs/dists/etch/wtf/Pkgs/mirabilos-support/systemd-must-die_8_all.deb




signature.asc
Description: OpenPGP digital signature

Re: systemd-fsck?

[Carlos Alberto Lopez Perez]

On 10/05/14 00:50, Russ Allbery wrote:
> we should also prepare for that situation
> and ensure that any switch of an init system via package installation
> results in a critical debconf warning so that no one is caught by
> surprise.
> 
> This has the advantage of future-proofing against any later change of init
> system, letting us reuse the mechanisms that we put in place for this one.

Can we make this policy?

One of the maintainers of systemd says that otherwise he don't thinks
this behavior is unsuitable for release: https://bugs.debian.org/747535#46



signature.asc
Description: OpenPGP digital signature

Re: systemd-fsck?

[Russ Allbery]

Carlos Alberto Lopez Perez  writes:
> On 10/05/14 00:50, Russ Allbery wrote:

>> we should also prepare for that situation and ensure that any switch of
>> an init system via package installation results in a critical debconf
>> warning so that no one is caught by surprise.

>> This has the advantage of future-proofing against any later change of
>> init system, letting us reuse the mechanisms that we put in place for
>> this one.

> Can we make this policy?

We need to work on Policy for the entire systemd transition, rather badly.
Help is definitely desirable there.  I had planned on starting that months
ago, but my regular job has been a disaster over the past months (four
major reorganizations in eight months, complete with surprise layoffs),
and therefore haven't been able to put any time into it.  There is
considerable draft material available as part of the tech-ctte discussion
that would make a good starting point.

The Policy framework is probably the right place to have the discussion
about how to handle the transition.  I actually will be moderately
surprised if it proves that controversial.  It wasn't elsewhere in this
thread; we were moving pretty fast towards a reasonable consensus on how
to handle it.

> One of the maintainers of systemd says that otherwise he don't thinks
> this behavior is unsuitable for release: https://bugs.debian.org/747535#46

This, however, *is* the wrong way to have this discussion.  Arguing over
whether this is an RC bug just comes across as attempting to coerce other
people into doing the work you care about, which makes the whole thing
needlessly confrontational.  Instead, propose solutions and patches.
There's no need to ever have an argument about how important it is to
finish the work if we instead use that energy to simply *do* the work.

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


-- 
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/87a9anelw9@windlord.stanford.edu

Re: systemd pulled in automatically

[Russ Allbery]

Bas Wijnen  writes:

> If the order of the dependencies of libpam-systemd is switched, so it
> becomes systemd-shim | systemd-sysv, the result will be:

> - If systemd is not installed, systemd-shim will be installed and the
>   original init system will continue functioning.
> - If systemd is installed, it will satisfy this dependency and systemd-shim
>   will not be installed.

> Sounds like exactly what I would expect when upgrading random other
> packages such as Network Manager.

Will systemd-shim work once logind is upgraded to 208?  My understanding
is that 208 will be going into unstable soon.  We certainly want to have
208 (and, actually, something later than that) for jessie.

If systemd-shim is 208-ready, then yes, this is appealing for the reasons
that you describe.  If it's not ready yet, we should probably hold off on
making this sort of change until it is, since otherwise dependencies would
be satisfied but the resulting system wouldn't actually *work* properly.
(Alternately, we could block 208 from coming into unstable until
systemd-shim is ready, but I'm a bit dubious that's a good idea.)

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


-- 
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/8761lbelqp@windlord.stanford.edu

Re: systemd-fsck?

[Steve Langasek]

On Sun, May 11, 2014 at 08:06:14PM -0700, Russ Allbery wrote:
> > One of the maintainers of systemd says that otherwise he don't thinks
> > this behavior is unsuitable for release: https://bugs.debian.org/747535#46

> This, however, *is* the wrong way to have this discussion.  Arguing over
> whether this is an RC bug just comes across as attempting to coerce other
> people into doing the work you care about, which makes the whole thing
> needlessly confrontational.  Instead, propose solutions and patches.
> There's no need to ever have an argument about how important it is to
> finish the work if we instead use that energy to simply *do* the work.

RC bug severity has an important function in blocking package migrations to
testing.  If someone is concerned that a particular regression in behavior
is sufficiently severe that it should block the new version of the package
from testing, they certainly should set the bug severity in the first
instance.  The maintainer may disagree, in which case one is free to
escalate it to the release team precisely as Tollef has suggested.  But
there's nothing inappropriate about having this discussion directly with the
maintainer first.

We certainly shouldn't insist that anyone who spots something they think is
a release-critical bug be personally responsible for providing a patch and
getting it accepted in the narrow window before the package automatically
migrates to testing.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd-fsck?

[Russ Allbery]

Steve Langasek  writes:

> RC bug severity has an important function in blocking package migrations
> to testing.  If someone is concerned that a particular regression in
> behavior is sufficiently severe that it should block the new version of
> the package from testing, they certainly should set the bug severity in
> the first instance.

Ah, sorry, yes.  This is a good point that I neglected.  The RC severity
discussion is perfectly fine if one is worried about impact on testing for
exactly the reasons you state.

That said, it's still not a good reason to try to get something into
Policy, or a good way of starting a Policy discussion.  (Among other
things, it's not the role of Policy to determine RC severity.  That's the
call of the release team, although they will certainly take existing
Policy consensus into account.)  Policy is about figuring out what the
right thing to do is, but can't allocate resources, and is too slow to be
the place to control whether things migrate to testing.

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


-- 
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/87mwend2vs@windlord.stanford.edu

Re: systemd-fsck?

[Steve Langasek]

On Sun, May 11, 2014 at 09:10:21AM +0200, Marc Haber wrote:
> >> The plain fact:

> >> Using systemd breaks something that worked for probably a decade or longer
> >> before however long that su is in that init script.  So on what account do
> >> you call calling "su" in an init script a bug?  It may not be the most
> >> elegant solution to do things, granted, but a bug?  Come on.  Calling it a
> >> bug just cause systemd / policykit treat calling su in an initscript as
> >> they do is quite arrogant in my eyes.

> >As the maintainer of the pam package in Debian, I assure you: this is a bug
> >in dirmngr.  System services should not (must not) call interfaces that
> >launch pam sessions as part of their init scripts.  su is one of those
> >interfaces.

> Is this documented anywhere, or is this only clear with detailed PAM
> knowledge, which I have tried to build numerous times in the last ten
> years and was never able due to (in my opinion) inadequate
> documentation on the beginner level.

It's not documented anywhere; it's an emergent property which is obvious if
you understand the underlying design, but not something that was ever
designed per se.  It might not be a bad idea to document it, though I'm not
sure where the best place to do this would be.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: systemd-fsck?

[Tollef Fog Heen]

]] Steve Langasek 

> The maintainer may disagree, in which case one is free to escalate it
> to the release team precisely as Tollef has suggested.  But there's
> nothing inappropriate about having this discussion directly with the
> maintainer first.

Right, and I didn't complain about the initial severity, but once people
start getting into severity ping-pong it gets tedious.

> We certainly shouldn't insist that anyone who spots something they think is
> a release-critical bug be personally responsible for providing a patch and
> getting it accepted in the narrow window before the package automatically
> migrates to testing.

They're not responsible for it, no.  That doesn't mean they can take an
update hostage by saying «this must be fixed or I'll continue raising
the severity of this bug» either.  (I'm not saying you said or implied
that.)

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


-- 
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/87d2fjms7c@xoog.err.no