Re: Guile language support in make
#secure method=pgpmime mode=sign On Sun, May 11 2014, Steve McIntyre wrote: Thinking about the poor people trying to bootstrap things, I'm tempted to suggest doing this as two separate source packages. Make is *so* far down the bottom of the stack that adding a dependency on another language could cause significant problems. Well, I was thinking of build profiles for that. --8---cut here---start-8--- Build-Depends: guile-2.0-dev !profile.withguile Packagte: make Build-Profiles: !withguile Package: make-guile Build-Profiles: withguile --8---cut here---end---8--- I know I can't do that until Jess is released and dpkg 1.17.2 is in stable. In the meanwhile, looking at gnuplot and kerrberos, I see how I can do detached build directories and dh overrides to actually build two binary packages from the same source package. What I don't see is how to manage to add the build dependency without inconveniencing bootstrapping with a single source package. I don't have the energy to create a brand new source package from the same mangled make upstream source. manoj -- Of course power tools and alcohol don't mix. Everyone knows power tools aren't soluble in alcohol... -- Crazy Nigel Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C -- 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/874n0wyhw5@glaurung.internal.golden-gryphon.com
Re: correct use of su
On Sun, May 11, 2014 at 11:12:08AM +1000, Brian May wrote: On 11 May 2014 03:13, Matthias Urlichs matth...@urlichs.de wrote: su does a bunch of things that are perfectly appropriate for something that creates a new login. That's its job. I am still a bit confused, isn't this only when you use the -l su flag? The '-l' flag is defined rather vaguely in the documentation, but in practice it appears to only impact the inheritance of environment variables. Does su do stuff (e.g. pam session stuff) even without the -l flag? 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. Running a daemon under its own UID is an almost-completely different problem. We already have a tool which does this (start-stop-daemon), which has been recommended for this task for umpteen years, and which still works if there is no .service file – for whatever reason. As a debian developer I was unaware of this. What about the task of running a short program for a brief duration, e.g. from cron scripts? Is using su considered acceptable? e.g. /etc/cron.daily/spamassassin on wheezy has numerous references to su. I think there might be other packages, this is just one I could find the quickest. Cronjobs are not always shortlived either, and can also cause these sorts of phantom sessions to show up to logind. I don't think we want to use su for cronjobs. 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. 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. -- 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?
On Sat, 10 May 2014 17:49:46 +0100, Dimitri John Ledkov x...@debian.org 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?
On Sat, 10 May 2014 11:55:19 +0200, Matthias Urlichs matth...@urlichs.de 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?
On Sat, 10 May 2014 15:28:34 +0200, Martin Steigerwald mar...@lichtvoll.de 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?
On Sat, 10 May 2014 18:00:02 +0200, Laurent Bigonville bi...@debian.org 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?
On Sat, 10 May 2014 19:13:01 +0200, Matthias Urlichs matth...@urlichs.de 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?
On Sat, 10 May 2014 20:57:28 +0100, Ben Hutchings b...@decadent.org.uk wrote: On Sat, 2014-05-10 at 19:53 +0200, Jakub Wilk wrote: * Matthias Urlichs matth...@urlichs.de, 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
On Sat, 10 May 2014 19:47:10 +0100, Brian a...@cityscape.co.uk 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?
On Sat, 10 May 2014 22:13:01 +0200, Matthias Urlichs matth...@urlichs.de 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
On Sat, 10 May 2014 23:11:10 -0700, Steve Langasek vor...@debian.org 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?
On Sat, 10 May 2014 15:38:24 -0700, Steve Langasek vor...@debian.org 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?
On Sat, 10 May 2014 16:27:00 +0200, Bas Wijnen wij...@debian.org 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
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
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?
Marc Haber mh+debian-de...@zugschlus.de (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?
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?
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?
Am Samstag, 10. Mai 2014, 21:36:42 schrieb Laurent Bigonville: Le Sat, 10 May 2014 19:13:01 +0200, Matthias Urlichs matth...@urlichs.de 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?
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... instead of wasting all our energy throwing blame at each other for the bugs that
Re: systemd-fsck?
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?
Am Sonntag, 11. Mai 2014, 09:13:09 schrieb Marc Haber: On Sat, 10 May 2014 16:27:00 +0200, Bas Wijnen wij...@debian.org 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?
❦ 11 mai 2014 08:58 +0200, Marc Haber mh+debian-de...@zugschlus.de : 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
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard d...@jones.dk -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libtypes-datetime-perl Version : 0.001 Upstream Author : Toby Inkster toby...@cpan.org * 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?
On Sun, 11 May 2014 10:22:02 +0200, Matthias Urlichs matth...@urlichs.de 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?
On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de (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?
On Sun, 11 May 2014 11:54:37 +0200, Vincent Bernat ber...@debian.org wrote: ? 11 mai 2014 08:58 +0200, Marc Haber mh+debian-de...@zugschlus.de : 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
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
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
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?
Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber: On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de (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
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
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?
Marc Haber wrote: On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de (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?
]] 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
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard d...@jones.dk -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libmatch-simple-xs-perl Version : 0.001 Upstream Author : Toby Inkster toby...@cpan.org * 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)
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 pkg-pattern 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 pkg-pattern patch
#
# these bugs contain patches, you might want to investigate
# whether they are still valuable
#
# unk-pkg close pkg-pattern 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 command pkg-pattern criteria
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
-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 a...@cityscape.co.uk 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
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard d...@jones.dk -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libtypes-uuid-perl Version : 0.002 Upstream Author : Toby Inkster toby...@cpan.org * 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
Package: wnpp Severity: wishlist Owner: Niko Tyni nt...@debian.org * 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
On May 11, Manoj Srivastava sriva...@ieee.org 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
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
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard d...@jones.dk -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libtest-api-perl Version : 0.001 Upstream Author : David Golden dagol...@cpan.org * 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?
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)
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
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?
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
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard d...@jones.dk -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libtest-modern-perl Version : 0.007 Upstream Author : Toby Inkster toby...@cpan.org * 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?
On Sun, 11 May 2014 13:16:43 +0200, Martin Steigerwald mar...@lichtvoll.de wrote: Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber: On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de (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?
On Sun, 11 May 2014 13:47:39 +0200, Laurent Bigonville bi...@debian.org 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
On Sun, 11 May 2014 14:50:55 +0200, Florian Lohoff f...@zz.de 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?
* Marc Haber mh+debian-de...@zugschlus.de [140511 16:09]: On Sun, 11 May 2014 13:16:43 +0200, Martin Steigerwald mar...@lichtvoll.de wrote: Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber: On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de (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 z...@debian.org : :' : 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?
* Marc Haber mh+debian-de...@zugschlus.de [140511 16:12]: On Sun, 11 May 2014 13:47:39 +0200, Laurent Bigonville bi...@debian.org 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 z...@debian.org : :' : 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
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
2014-05-11 15:55 GMT+02:00 Marc Haber mh+debian-de...@zugschlus.de: On Sun, 11 May 2014 14:50:55 +0200, Florian Lohoff f...@zz.de 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
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard d...@jones.dk -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: libtypes-uri-perl Version : 0.001 Upstream Author : Toby Inkster toby...@cpan.org * 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
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
-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 mh+debian-de...@zugschlus.de: On Sun, 11 May 2014 14:50:55 +0200, Florian Lohoff f...@zz.de 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
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
On Sat, May 10, 2014 at 11:10 AM, Jérémy Lal kapo...@melix.org 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
]] 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
The Wanderer wande...@fastmail.fm 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) http://www.eyrie.org/~eagle/ -- 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?
Marc Haber wrote: On Sun, 11 May 2014 13:16:43 +0200, Martin Steigerwald mar...@lichtvoll.de wrote: Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber: On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de (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)
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?
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?
On Sun, 11 May 2014 18:48:46 +0200, Laurent Bigonville bi...@debian.org 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
On Sun, May 11, 2014 at 5:58 PM, Bastien ROUCARIES
roucaries.bast...@gmail.com wrote:
On Sat, May 10, 2014 at 11:10 AM, Jérémy Lal kapo...@melix.org 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
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?
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 b...@decadent.org.uk wrote: On Sat, 2014-05-10 at 19:53 +0200, Jakub Wilk wrote: * Matthias Urlichs matth...@urlichs.de, 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?
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 mar...@lichtvoll.de wrote: Am Sonntag, 11. Mai 2014, 12:53:39 schrieb Marc Haber: On Sun, 11 May 2014 10:04:15 +0200, Cyril Brulebois k...@debian.org wrote: Marc Haber mh+debian-de...@zugschlus.de (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
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?
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?
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
Package: wnpp Severity: wishlist Owner: Marcin Kulisz (kuLa) deb...@kulisz.net * Package name: python-fysom Version : 1.0.15 Upstream Author : Maximilien Riehl m...@riehl.io * 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
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
]] 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)
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
Package: wnpp Severity: wishlist Owner: Antoine Millet anto...@inaps.org * Package name: confiture Version : 2.0 Upstream Author : Antoine Millet anto...@inaps.org * 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?
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)
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?
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?
El Sun, 11 de May 2014 a las 1:49 PM, Michael Biebl bi...@debian.org escribió: Am 11.05.2014 19:37, schrieb Helmut Grohne: I trust you to be technically right on this. Still the number of packages getting this wrong is stunning[1]. Therefore I'd argue that [1] http://codesearch.debian.net/search?q=su+-c+path%3Adebian%2F+path%3Ainit If I counted correctly, there are 5 packages using su in their init script, dirmngr being one of them. Considering that we have ~1200 SysV init scripts in Debian, I don't consider this number stunning at all. And yes, we should fix those init scripts. I do not believe that list is at all comprehensive. One example would be the init script for the package rotter. Best regards, -- Cameron Norman
Re: systemd-fsck?
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 21; 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 21; 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 21
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 -
21
fetchmail/init.d/fetchmail: su -s /bin/sh -c $DAEMON
$OPTIONS --nosyslog --nodetach -v -v $USER - 21
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 21
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 21
inn2/init.d/inn2:su news -c '/usr/lib/news/bin/rc.news stop'
/var/log/news/rc.news 21
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: (su - nobody -s /bin/sh -c $SENDMAIL
$owner $i ) /dev/null /dev/null 20
opennebula/init.d/opennebula:su
Re: ignoring bugs with no maintainer (Re: Removal of emacs23 from unstable/testing)
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
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
-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
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=detailaid=314680group_id=1atid=21 signature.asc Description: This is a digitally signed message part
Re: Alioth tracker
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
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
On 11/05/14 09:18, Marc Haber wrote: On Sat, 10 May 2014 19:47:10 +0100, Brian a...@cityscape.co.uk 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?
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?
Carlos Alberto Lopez Perez clo...@igalia.com 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) http://www.eyrie.org/~eagle/ -- 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
Bas Wijnen wij...@debian.org 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) http://www.eyrie.org/~eagle/ -- 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?
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?
Steve Langasek vor...@debian.org 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) http://www.eyrie.org/~eagle/ -- 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?
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
Accepted aumix 2.9.1-3 (source all amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Format: 1.8
Date: Wed, 30 Apr 2014 01:06:42 +0200
Source: aumix
Binary: aumix-common aumix aumix-gtk
Architecture: source all amd64
Version: 2.9.1-3
Distribution: unstable
Urgency: low
Maintainer: Stefan Ott ste...@ott.net
Changed-By: Stefan Ott ste...@ott.net
Description:
aumix - Simple text-based mixer control program
aumix-common - Simple text-based mixer control program (common files)
aumix-gtk - Simple mixer control program with GUI and text interfaces
Closes: 580827 629500 647138 697318 724004 727325
Changes:
aumix (2.9.1-3) unstable; urgency=low
.
[ Stefan Ott ]
* debian/rules:
- Run dh-autoreconf when building closes: #727325
- Set our LDFLAGS in a way that does not mess with the defaults
* debian/control:
- Build-depend on autotools-dev and dh-autoreconf
- Use canonical URIs for Vcs-* fields
- Switched to debhelper 9
- Removed deprecated DM-Upload-Allowed field
- Bumped Standards-Version to 3.9.5
* debian/aumix-gtk.menu:
- Swapped the long title entries closes: #724004
- Enable the console version of aumix in X terminals
* debian/patches:
- 15_man-fixes.patch: Clarify -C flag closes: #580827
- 17_zh-tw-po.patch: Added zh_TW translation
- 18_ncursesw.patch: Use ncurses with wide-char supportcloses: #629500
* debian/xaumix: Recognise lxterm, uxterm and koi8rxterm closes: #697318
* debian/aumix{-gtk}.desktop: Added keywords
* debian/aumix-common.aumix.init: Added description
.
[ Peter Eisentraut ]
* Added support for status action in init script closes: #647138
Checksums-Sha1:
1a8921e605f821159985d7bb7cf624aaff58f5a6 2057 aumix_2.9.1-3.dsc
5d0742f17ce4a3294b571e197b768310f224b9bb 34980 aumix_2.9.1-3.debian.tar.xz
2df01baf8192d3de6622b1148f2897065a6e642d 45936 aumix-common_2.9.1-3_all.deb
72dc5e7594ba2c7bffadef5c4bacc1095df12994 66142 aumix_2.9.1-3_amd64.deb
7697adcc92512056e21155d414a295ee4fa062a5 71568 aumix-gtk_2.9.1-3_amd64.deb
Checksums-Sha256:
5ca9a95009d395df7969165653f1090a798a3af90999f900bb34fa3943975b2b 2057
aumix_2.9.1-3.dsc
e4d397ac0b6f1a35d29ce4da6b75de1391c13de27ca16837a004e225ad5336dd 34980
aumix_2.9.1-3.debian.tar.xz
4e67207a7ac1e1a59fe1259980e80f8c2ae7fbfc4a00da55dc0600aab87668b2 45936
aumix-common_2.9.1-3_all.deb
6ccfc778e8217774ffebd45600aa45895577b55ad5d99f7620e84331cd0a151d 66142
aumix_2.9.1-3_amd64.deb
94b7ad3728bcbe3bdd3c729737f4951eb6b831625c6ed54710bbc222edcc7e62 71568
aumix-gtk_2.9.1-3_amd64.deb
Files:
510cf993966373815eb46fea899a7e5c 45936 sound extra aumix-common_2.9.1-3_all.deb
780622479793002bc7b7a443271af811 66142 sound extra aumix_2.9.1-3_amd64.deb
e62bd81d5e6a334a3f25225995cca825 71568 sound extra aumix-gtk_2.9.1-3_amd64.deb
15749e8e4e02369fa8c72999abf461f0 2057 sound extra aumix_2.9.1-3.dsc
d458f3f030590182b25aa7ceac15cc97 34980 sound extra aumix_2.9.1-3.debian.tar.xz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBCAAGBQJTYPuUAAoJEKv/7bJACMb5c0cQAIeXNfKY7Qpu7m4n0HYbOdHN
A0EtYN0oxMEjbqebdkGx1BzWQkysoh8dAENHtDl+W0CcQt3R/1/7yPzoBiHX7UHq
sc4TO14KGvr0Qf8QWCYCx6Q3yyu+bVhH5APyd5POLxZrZ3aE5Rejza5kKwt5rs2J
r3b3Psc8hyYe+tiw91ZPOF74uxJnRnHfg1zkoAioMvwc9x8pcHjKeqlUQC+lzaX9
lfWN6hs1rpdkOTQQsPQaHG0uRFX2Z9zZB0XKBgvhb0tMNZezspVX+d3lZoM7aNQg
e8yvdBLdz3SGmugo/vJOLmysKrSfR9CD10uBgXVzUB75oBKEjzerjZC2skP/mxFz
4zy6XDvyPBCR+d3+v231jP6aT2zF59hv8jmw2oqushJfsc8cw60SC3J81koXhle1
gojzZvxfqQkk3WdY4629nGvrDVLEfR2c9YADSAgrzaXYrV5EIA23xoTIcCq1yO9A
9VVo2GYR9DsE9OIHGgE6pU4dgrWdZHBGKk01YcbzXlwb4YxO1nROekT40I84QgF1
pn12shgfbSf1J7MXrafsmoJNA2dBwV4Uc6hvZp1McL9nAZ/3p9e3nCpiTV+YzdZa
FdpczzeSNcf/dw10jIG3nlskUYsdG9mxCgw2oaYVWspQqKVYcM9JyixbCg6aHzUb
DGefEqXjATaPkDaTW7HW
=TcNK
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/e1wjq9l-00087g...@franck.debian.org
Accepted libio-socket-ssl-perl 1.984-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 11 May 2014 10:01:07 +0200 Source: libio-socket-ssl-perl Binary: libio-socket-ssl-perl Architecture: source all Version: 1.984-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Angel Abad an...@debian.org Description: libio-socket-ssl-perl - Perl module implementing object oriented interface to SSL sockets Changes: libio-socket-ssl-perl (1.984-1) unstable; urgency=medium . * Imported Upstream version 1.984 * debian/copyright: Update debian/* years Checksums-Sha1: eb126dfdbc02d1060926538b96e0fa91e1ce 1931 libio-socket-ssl-perl_1.984-1.dsc 16f45ccb7c605591943465d55fa6fdec65a3e631 165995 libio-socket-ssl-perl_1.984.orig.tar.gz c35abd241c67baa8af672d3bd1a9d290ca8dbe6b 7824 libio-socket-ssl-perl_1.984-1.debian.tar.xz fc92cd900e94b6652dcb3676f107f9298b9adb11 156190 libio-socket-ssl-perl_1.984-1_all.deb Checksums-Sha256: e54a961e04afdb9e5d562d3b282094ea1649fe7af07163b1556882e261d30ed4 1931 libio-socket-ssl-perl_1.984-1.dsc c79ccf4c7550225f4b36358767f435f433b3253ea532b40749058559fa8f3614 165995 libio-socket-ssl-perl_1.984.orig.tar.gz 42802baf3939e2adcc29856ce22c169c310d27147ad91d474cb8472b10c9e247 7824 libio-socket-ssl-perl_1.984-1.debian.tar.xz f498841afb9119c896274677ba216026d7387b14f124895b787ccd251a036b25 156190 libio-socket-ssl-perl_1.984-1_all.deb Files: 6dc065d5122b8f1a4f91279d694f8fac 156190 perl optional libio-socket-ssl-perl_1.984-1_all.deb 240e2b74548c5b145e3e458e27861b97 1931 perl optional libio-socket-ssl-perl_1.984-1.dsc d2a2554c9394fb774d37ed7e14a8d172 165995 perl optional libio-socket-ssl-perl_1.984.orig.tar.gz 5cfccfe029d46d84fb53851b4ef0514c 7824 perl optional libio-socket-ssl-perl_1.984-1.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlNvMBwACgkQCY2uR+47wnlUhACgg+kKBxeHvxvQPrlO0dCtsNpC LwYAmwULHx+VkzjNC7cSC3MlKhu2xhDO =c9tu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wjqgn-0003rc...@franck.debian.org
Accepted libpath-tiny-perl 0.054-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sat, 10 May 2014 21:07:24 +0200 Source: libpath-tiny-perl Binary: libpath-tiny-perl Architecture: source all Version: 0.054-1 Distribution: unstable Urgency: medium Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Jonas Smedegaard d...@jones.dk Description: libpath-tiny-perl - file path utility Changes: libpath-tiny-perl (0.054-1) unstable; urgency=medium . [ upstream ] * New release(s) + The 'is_file' method now does -e ! -d and not -f because -f is often more restrictive than people intend or expect. + Add 'chmod' method with symbolic chmod support (a=r,u+rx). + Fix throw error when constructing path with undef or zero-length parts -- e.g. with child(). + The 'basename' method now takes a list of suffixes to remove before returning the name. + Add FREEZE/THAW/TO_JSON serialization helpers. + When constructing a Path::Tiny object from another, the original is returned unless it's a temp dir/file. This significantly speeds up calling path($path) if $path is already a Path::Tiny object. . [ Jonas Smedegaard ] * Fix build-depend on perl (previously missed by CDBS when present also as preference to modules). * Have git-buildpackage suppress eventual upstream .gitignore files. Checksums-Sha1: 6dd25da5b2ec214811c91f2724f840f6e947dd94 2321 libpath-tiny-perl_0.054-1.dsc fd8a40d17de9df669b1eec4015a331da2d98c01f 68414 libpath-tiny-perl_0.054.orig.tar.gz fe4bdb3d9c7635a408f801df6972f5c17eca0ff2 4592 libpath-tiny-perl_0.054-1.debian.tar.xz ac8ef8f61d6100c923196bca3db63301d60fb6d0 49156 libpath-tiny-perl_0.054-1_all.deb Checksums-Sha256: c805fdb92131f77d2f4983651bb80334edf45a596a7747336a2d45bf56a7aed4 2321 libpath-tiny-perl_0.054-1.dsc eae44f0b3be64a80262ae255344b619765c851cf4ff1f9b3c65142596c85a3bf 68414 libpath-tiny-perl_0.054.orig.tar.gz f68f596c14d1227615c9498044502520028a5f776515578af25facf88f0c31d3 4592 libpath-tiny-perl_0.054-1.debian.tar.xz 2a166d889f3ff3d92e1e8bd3ca26d9ecc2f23a7a7e6ed027dc1c715ad967c6e3 49156 libpath-tiny-perl_0.054-1_all.deb Files: acaa199aa3319f9751b3f05704882900 49156 perl optional libpath-tiny-perl_0.054-1_all.deb 6e8d164bca3804065fe2fbe25d91ad46 2321 perl optional libpath-tiny-perl_0.054-1.dsc de3d32e277ecd26a86b70f4b9f15ce4d 68414 perl optional libpath-tiny-perl_0.054.orig.tar.gz cead04b9eda6ad321deae8f63e1662dc 4592 perl optional libpath-tiny-perl_0.054-1.debian.tar.xz -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQJ8BAEBCgBmBQJTbzYzXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5RkUzRTlDMzY2OTFBNjlGRjUzQ0M2ODQy QzdDMzE0NkMxQTAwMTIxAAoJECx8MUbBoAEhW78P/3ElDqXvj/qfHdpHuyMTS8hd wixSlK1M5x3n2EAPescH+u09Aqcn4pNYKZqN69KpCiU7je9Zvb9sFaejeU6FMeEV OxQ9ZUFOMurIi7+GWmyMEUU78QnrcziDb0pw+WPNWRyfXRETDtG2b1bxStXhYvCJ jLS5Xejg+0HIClnuYGXhjCji93T4op+9WKNhGl70jcmlKjOngI6RF64EyUDBbEJI 2cOdspGmAolGF3asHycxYPP4MYsrdyAkfaWfil1oMJfnBNsPah8E2JZtpD8AaoK2 zkgEiZ0874r4vK2wrM/mWdpLVnSc+nfMXu48BCyprxyvfirWGFpSrYpppNupwWdm Gz7EdlLyt6+f7T2TfBg4mz+afo5uTyR79vuYph5o/4NduxzCq9jSaJ3cKPhjvTQc 3CGokZoxQo9DMxS1DJ/iOmff4VluRoShG4bgbFnnaKzifb7tZh5Mq02VdRtfEqGa dGdnNWBWaMWjSJKegZvGxMk4Z33a+V1zTOGJ12mIW24V0AWO6W/igJqK7GW1zsm2 naEnu+9hSNry55niraM7kMBuymHGudCMNuWXhMPOmMPkvlcPxSndjxzuIdi2HvXq VUB0VGszJD6crobQcSuJm6KJx871yWQdzv/NCWc+D/HcqnKNoOgq7h50pN8xyJUq uqry7tQFUjeh3HSjMPmo =JGKy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wjqh4-0003yz...@franck.debian.org
Accepted wajig 2.14 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 11 May 2014 09:47:20 +0200 Source: wajig Binary: wajig Architecture: source all Version: 2.14 Distribution: unstable Urgency: low Maintainer: Graham Williams graham.willi...@togaware.com Changed-By: Tshepang Lekhonkhobe tshep...@gmail.com Description: wajig - unified package management front-end for Debian Closes: 691857 Changes: wajig (2.14) unstable; urgency=low . * SOURCE: Auto-complete package names (suggested by Reuben Thomas) . * PURGE-REMOVED: If one removed (not purged) a foreign arch package, and then ran 'wajig purge-removed', it would attempt to remove package with the same name but on the current architecture; Closes: #691857 Checksums-Sha1: 2a94b420be0e2495320e43507284cac135992c47 1586 wajig_2.14.dsc 6f262589671ea27b64c6a2fa36478e96014c6a8e 48044 wajig_2.14.tar.xz 579e74d0da3c5af3b2503824df1f885fc18cd165 54668 wajig_2.14_all.deb Checksums-Sha256: cb23e43c8b0f2682a1bacd0dc35c44e05f2e6ae492b9d1817e13682593843508 1586 wajig_2.14.dsc 1c94f0ee4d994fd1aa85c157ab9fb5b020ca302835bce5718313acef1ff387cf 48044 wajig_2.14.tar.xz 4d2e51f9cf0edc33e2447a826eda51a46b2a9780c2db1a440d74a974122fc93e 54668 wajig_2.14_all.deb Files: 018e76465751e40f4727c366879644b1 1586 admin optional wajig_2.14.dsc 2b021056e55b6bb778686958e3430517 48044 admin optional wajig_2.14.tar.xz 422a83d9def96cc697e80dcea4ac9122 54668 admin optional wajig_2.14_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTby3BAAoJEClXKy9QC/Sit5EQAKhA53yySitFuVjJ3I81gam/ +dOksBxsVUK3hm2edq5FGVk/7MI5dOuq7JsgIrudCB2i9BxbyaRfYH5VY2Jo9F8Q J2yPTRhXa8P7HhEXjcLwsozSRItArvPnYV3aslGufQvvUubiNdt2J9ZESrLis7d2 9teeVhPhGq/LaoTM4mKPHp7nr4M+ZosySW1L0h4GHZp9D/SRU90oPuR37dVTtvCc yzIqhwnR+wEkV+229zejby9PBPNrKN3R1BRSrlrKuoWaAeWa1sGXt9OT22Z3GSgZ sLdncQnOr3HPwcgQNQIN4g6+ee+Q4J3wNONsrzm/vvss0XwSuaCgdN3/FMAyB/8f cdzAkPmSAC5a0S8Ogn8FPUPrJXH19HlGHNflsojEMZH5VGhAe+GMbpxZj2bKO76L C4ZTlL4HJqUu3AEtw4KK9UBmLZQ0UgGM/vM4ytXhqxkDQGjtjo6UHiRG9b+TCPLQ s5DmGC9LiEqEjf7izX5fcZ9+HezcBPeKQr1yaYHNGFQ4KWjZvbvnwk2Jj3OqXZfn iHq9sICwQFgOQ85EGCLV/b0HkTP/Os1L5Ak1hAKDENnE+88Q/Fi5wfgAQg6Z9Xx2 KekJNEamAMrEGaaF7XS/v2W1Dz+XcebkIbyL/Tz5rkTHPK9dpfw6/xh4rSf98P7B 1rIDalJfT7as6gne6qI4 =aLgJ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1wjqj5-00040r...@franck.debian.org
