Bug#710349: ITP: maple-package -- utility for creating Maple Debian packages
Package: wnpp Severity: wishlist Owner: Jerome Benoit calcu...@rezozer.net * Package name: maple-package Version : 0.0.1 Upstream Author : Jerome Benoit calcu...@rezozer.net * License : GPL-2+ Programming Lang: bash, make Description : utility for creating Maple Debian packages Maple is a commercial Computer Algebra System (CAS) manufactured by the Canadian software company MapleSoft, a division of Waterloo Maple Inc.. This package will be meant to provide the capability to build Debian packages from the install material distributed by Maple by running a dedicated bash script that will mainly invoke a Makefile through the dh(1) tools. The aim of the game is to gain a (far) more comfortable integration of Maple into Debian systems. This package itself will be a native Debian package (Section: contrib/misc) governed by GPL-2+, but the Maple software will have to be purchased by the final user and will obviously remain governed by the copyright holder (MapleSoft, namely Waterloo Maple Inc.). This package will simply help the final user to create her/his/its own Maple packages and it will be her/his/its responsability to use the resulting package responsibly. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530060927.10998.1929.report...@nen.dnsalias.org
Re: Switching to mozilla ESR in stable-security
Hi, Josh Triplett wrote (29 May 2013 18:50:23 GMT) : As a user of sid who also maintains various systems running stable, I rely on packages like xul-ext-adblock-plus to make it easier to install specific addons systemwide. FTR, packaged XUL extensions make it easier to build Debian Live systems, too. In any case, thanks for considering switching to ESR! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/857gihc6c6@boum.org
Re: default MTA
On Mi, 29 mai 13, 15:59:35, Russ Allbery wrote: Andrei POPESCU andreimpope...@gmail.com writes: Exim is a listening daemon, even if it listens only on localhost in the default configuration. I'd prefer dma instead. It's better to have a listening daemon on localhost. There's no security threat, and there's some software that can't handle invoking a sendmail binary and always wants to speak SMTP to some port. I've run into this with both Java and PHP applications. This is, of course, possible to fix, but I can understand why Java programmers aren't thrilled by the idea of adding UNIX-specific code to fork and execute a program (which is something that you generally don't want to do in Java, since it's very expensive, and which is not portable), and similarly why web developers aren't enthused by fork and exec in a mod_php or similar context inside a possibly threaded web server. Maybe it makes sense to have virtual packages like mta-daemon, mta-forwarder, etc.? (regardless of which, if any, is installed by default) 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 signature.asc Description: Digital signature
Re: [clang] Report bugs on packages failing to build with clang
On 30/05/2013 01:51, Scott Kitterman wrote: Sylvestre Ledru sylves...@debian.org wrote: Hello, With the recent setup of the parallel build infrastructure using clang instead of gcc [1], I would like to start to report bugs on packages failing to build with clang (with patches if possible). The severity would be minor. Of course, I would do that only when the issue is upstream [2]. Any comments ? It seems to me that FTBFS with clang should be wishlist. I also considered this severity but the documentation [1] says for any feature request, and also for any bugs that are very difficult to fix due to major design considerations. Not sure it matches. Sylvestre [1] http://www.debian.org/Bugs/Developer#severities -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a70a8f.1000...@debian.org
Re: systemd .service file conversion
On Wed, May 29, 2013 at 09:10:41PM +0200, Wouter Verhelst wrote: This kind of madness is precisely described here: http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html [zillionth link to linux is not about choice mail] Because it's a very good read, still years later. It is unfortunate that the community hasn't learned from it. At Debian, traditionally we support more than one choice (at least for a while), until the community at large decides that option X is the best one (and then we drop support for all the other options). The downside of that is that it takes a lot longer for us to make a choice, but eventually you usually get the better option. This is stockholm syndromish - because Debian is held behind times by lack of decision making, we start finding good things in being behind. By switching early we can affect how a piece of software will evolve. Is there something you would like to change in systemd? Now it still probably possible - 2 years from now it has shipped in RHEL, and books will have been written about it - and changing it will be much harder. So our inability choose early means that we cannot influence the community as large - or even our own distribution in long term. While we are busy maintaining multiple indirection layers to support user choice, the early switching distributions are crafting the software that will eventually become the choice. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530084651.ga17...@afflict.kos.to
Re: Source build-dependencies
On Thu, 16 May 2013 16:58:13 +0200, Guillem Jover guil...@debian.org wrote: On Tue, 2013-05-14 at 08:50:39 +0800, Paul Wise wrote: On Mon, May 13, 2013 at 11:17 PM, Stéphane Glondu wrote: Le 13/05/2013 15:51, Paul Wise a écrit : [...] as long as there is a way to build-depend on the build-dependencies for a source package, that should be fine. As a bonus we can get rid of mk-build-deps :) How so? In my case, I already have metapackages for each system, so I can just add foo:build-deps to the Depends for those, instead of building fake packages with mk-build-deps. One of the problems with mk-build-deps is that the created packages need manual rebuilds whenever the Build-Depends change. It's not clear to me from what has been written in this sub-thread, if we are talking about magic srcpkg:build-deps substvars to be expanded at build time, or if those are supposed to be valid package specifiers that are expanded at run-time (ending up in Depends lines unexpanded, for example), or something else. As I understand it (and what I'd like) is just the possibility of specifying source packages rather than binary packages as build-dependencies. So for instance in my gcc-mingw-w64 package's control file, instead of specifying Build-Depends: ..., gcc-4.6-source, ... I'd specify Build-Depends: ..., gcc-4.6:source, ... Because gcc-4.6-source pulls in dependencies that the gcc-mingw-w64 package also needs, I'd also need to add those; it would be easier then to specify Build-Depends: ..., gcc-4.6:source, gcc-4.6:build-deps, ... instead, since gcc-4.6-source's dependencies are a subset of gcc-4.6's build-dependencies, and I'd rather not have to always change my package when the latter change. The only substvar-type treatment which would be useful then would be something to fill in Built-Using automatically. Regards, Stephen signature.asc Description: PGP signature
Re: Eliminating mail-transport-agent from standard
On Mon, May 27, 2013 at 08:27:36PM -0700, Josh Triplett wrote: In addition to determining the MTA pulled in by default for packages which require mail-transport-agent in order to function (the provider of default-mta), I'd like to propose as a release goal that we not have any MTA in standard anymore. I've actually worked towards this goal for a while now, and made a fair bit of progress; this mail documents the remaining work required, most of which is simple dependency/priority changes and patch application. +1 In this age of spam, installing email server should be explicit decision by system admin rather that something that becomes automatically when you install Debian. Riku -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530090617.gb17...@afflict.kos.to
Re: default MTA
* Chris Knadle chris.kna...@coredump.us [130529 08:29]: - Exim configuration is more human readable than Postifx's, IMHO. Postfix configuration is concise but terse, and there are typically blocks of options separated by commas that doesn't easily allow commenting on specific config options. Configurability is an important point. Having had to use postfix lately I'm quite suprised anyone voluntarily uses that thing. Postfix feels like some ad-hoc configuration gone absurd, by only making special use cases configuable and then misusing those options for other things. Together with this splitting in many little programs which all lack most of the information, configuring postfix is a large puzzle and any advanced postfix configuration (even from the official documentation) looks like McGyver was out of duct-tape but had to build a nuclear reactor from kitchen parts with only the transparent tape for office use. The only positive thing you can say about Postfix' configuration is that it might be better than sendmail's. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530091105.ga3...@client.brlink.eu
Re: systemd .service file conversion
This is stockholm syndromish - because Debian is held behind times by lack of decision making, we start finding good things in being behind. Do you realize that fedora is the beta version for red hat? They use the community to get free testing for their commercial product. Personally as a debian user I prefer having a system that works rather than being used as a guinea pig for a commercial product. I don't see how forcing users to use immature software that doesn't yet work very well is a good thing for anyone (except if you are a commercial company and use your free product to get free beta testing). I have tried systemd, and I like the approach it has, and in a few years I believe it has potential. But... using it to restart my computer i need to do an hard reset (and think of how happy would I be if my computer had been a server in a rack on the other side of the planet), and gave me several problems related to switching from X11 to vt and vice versa. At this point I can't see what decision is there to be made, systemd is not ready yet to replace sysvinit, if and when it will work reliably we can have this conversation. On a side note about Poettering, sometimes pulseaudio gets pulled in by some package that I install, and when this happens I stop hearing sounds from my computer, then I know I just need to remove it and everything will be fine again (this happened 2 months ago the last time), I am sure there is a fix for this but personally I find it much easier to just remove some piece of software that I didn't even need in the 1st place and is just causing malfunctioning after years of causing malfunctioning. So I really don't regard him as the best person there is to write core parts of my system. I'd trust him maybe with things like cowsay or nyancat that wouldn't cause too much havoc when they should fail. -- Salvo Tomaselli http://web.student.chalmers.se/~saltom/ signature.asc Description: This is a digitally signed message part.
Re: default MTA
On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. signature.asc Description: OpenPGP digital signature
Re: Debian systemd survey
Le mercredi 29 mai 2013 à 21:43 +0200, Marc Haber a écrit : That is one of my concerns: Once Debian GNU/Linux has systemd as default, noone will an longer provide init scripts, let alone tested init scripts, which will severely hurt non-Linux kernels in Debian. While entirely true, I think it demonstrates we are lacking adequate support for non-Linux kernels, and it should not prevent us from improving the init system for Linux. The current init scripts are not tested on non-Linux. The current *packages* are not tested on non-Linux. Most of the current packages appear completely dysfunctional once someone actually tries them on non-Linux – and this almost never happens because these architectures don’t have real testing/unstable users. Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1369908317.5185.182.camel@pi0307572
Re: default MTA
On Wed, 29 May 2013 23:12:39 +0300, Andrei POPESCU andreimpope...@gmail.com wrote: On Mi, 29 mai 13, 21:52:04, Marc Haber wrote: Yes. And many systems have intermittent connectivity, which rules out non-queueing mini-MTAs. Exim does the Job pretty well, and people who know what an MTA is will probably install their own anyway, so there is no need to change. Exim is a listening daemon, even if it listens only on localhost in the default configuration. It comes listening on localhost in default configuration. It can be trivially configured not to listen at all, or to listen on all interfaces. 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: http://lists.debian.org/e1ui00y-0008jk...@swivel.zugschlus.de
Re: default MTA
On Thu, 30 May 2013 10:18:07 +0300, Andrei POPESCU andreimpope...@gmail.com wrote: Maybe it makes sense to have virtual packages like mta-daemon, mta-forwarder, etc.? (regardless of which, if any, is installed by default) Show code, or at least an explanation about how you intend to do that. How will, for example, the virtual package provided by exim change depending on the setting for the QUEUERUNNER config option? 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: http://lists.debian.org/e1ui02t-0008jy...@swivel.zugschlus.de
Re: default MTA
On Thu, May 30, 2013 at 12:16:38PM +0200, Carlos Alberto Lopez Perez wrote: On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. Indeed it is interesting. Whereas Debian has a majority of GNU/Linux installation for _web_ servers according to: http://w3techs.com/technologies/details/os-linux/all/all it's a _relative_ majority, smaller than the sum of the other distros you've cited. Here's an experimental way to test the assumption of Debian leadership on the mail server market: let's switch our default to Postfix and see if the figures change :-) /SCNR -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: default MTA
On Thu, 30 May 2013 04:04:14 +0800, Thomas Goirand z...@debian.org wrote: On 05/29/2013 11:32 PM, Javier Fernandez-Sanguino wrote: On 29 May 2013 17:11, Josselin Mouette j...@debian.org wrote: Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a écrit : He will see a notification on his desktop. Clear, understandable and translated in his configured language: https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c (The code is different but already here in squeeze and wheezy.) I'm happy to see this use case is covered in GNOME. Me as well. Though not everyone uses GNOME (someone pointed out earlier in this list that we have more than 40 window managers in Debian!), and it is desirable, IMO, to also handle their use case. I think that people who are able to replace the default desktop with the desktop of their choice should be trusted to read their local mail as well. We may document this, but I don't think that we should spend personpower to provide a technical solution to that. There are things more important than that. We should make local mail or other messages trivially and automatically visible for people who have installed Debian in NNF[1] compliant way, but if one has gone to length to use something non-default, I think we can safely trust those people with taking other measures as well. Greetings Marc [1] Next, next, finish -- -- !! 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: http://lists.debian.org/e1ui04x-0008k9...@swivel.zugschlus.de
Re: default MTA
On Thursday, May 30, 2013 12:16:38 PM Carlos Alberto Lopez Perez wrote: On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. Since ~80% of the Exim installations are for an ancient version that AFAIK tell from a few moments of checking was never the version in a Debian release, I don't think that's it. Scott K signature.asc Description: This is a digitally signed message part.
Re: systemd .service file conversion
On 2013-05-30, Riku Voipio riku.voi...@iki.fi wrote: By switching early we can affect how a piece of software will evolve. Is there something you would like to change in systemd? Now it still probably possible - 2 years from now it has shipped in RHEL, and books will have been written about it - and changing it will be much harder. So our inability choose early means that we cannot influence the community as large - or even our own distribution in long term. While we are busy maintaining multiple indirection layers to support user choice, the early switching distributions are crafting the software that will eventually become the choice. Wise words. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnkqe9ja.j8.nos...@sshway.ssh.pusling.com
Re: default MTA
Ben Hutchings b...@decadent.org.uk writes: On Wed, May 29, 2013 at 09:06:59PM +0200, Adam Borowski wrote: On Wed, May 29, 2013 at 05:11:35PM +0200, Josselin Mouette wrote: Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a écrit : Take for example, smartmoontools [1]. Currently, if an end-user installs smartmoontools and a hard-disk fails (i.e. smartd detects a problem with one HD) he will *not* see any notification: the failure is sent through local e-mail. He will see a notification on his desktop. Clear, understandable and translated in his configured language: https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor.c (The code is different but already here in squeeze and wheezy.) What you propose requires: * adding desktop environment specific code to every facility that may need to send notifications * adding such notifications to every other desktop environment Wrong, we already have org.freedesktop.Notifications in GNOME, KDE and Xfce. So those two points become: * adding cross-desktop code to every facility that may need to send notifications * adding a notification daemon to task-lxde There are libraries to help with the first point, of course. Wouldn't a daemon watching /var/mail/root and turning any mail into desktop notifications solve most of this, while still allowing the same notifications to reach a sysadmin on non-desktop systems? The issue that worries me most about these desktop notification plans is the possibility that some package may decide to unnecessarily drop support for non-desktop systems, adding dependencies on the desktop notification system. I believe we already have had a few examples of such unnecessary dependencies on services which are nice to have, like GNOME depending on NetworkManager for example. The Clear, understandable and translated in his configured language point is unrelated the notification system. That requirement should be at least as strict for any mail to root. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871u8opye0@nemi.mork.no
Re: default MTA
On Wed, 29 May 2013 19:45:06 -0400, Chris Knadle chris.kna...@coredump.us wrote: I don't like the fact that the /etc/exim4/passwd.client file is in a plaintext format, but there are usually several such files on systems such that realistically we're only really safe as long as the machines we run haven't been broken into. And if you think about things, it is clear that the client needs the plaintext password to be able to use it. Even if certificate authentication, the most secure authentication scheme available today, is used, you need the private key on the client. That's exactly the point, and is why I would prefer not to write those notifications into a file that no one ever looks at. (Which is why I don't find sending them to syslog much more appealing, since the average desktop user is never going to look there either.) Somehow this problem reminds me of the event log used on a popular operating system. Most users don't read that log either. This is partly caused by the utter unusability of the default program delivered to read that binary log. Even the best Jvaqbjf people I know need to be poked to use Rirag Ivrjre. Usually, this results in a quick solution since the Jvaqbjf Event Log isn't as bad as its reputation past the usual access method. But people rather continue blind trial-and-error methods before taking a look at their logs. Btw, I fear that systemd's binary logs are going to import this method of inefficient work in our world. I surely hope I am wrong on this count. 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: http://lists.debian.org/e1ui08g-0008ps...@swivel.zugschlus.de
Re: Debian systemd survey
On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery r...@debian.org wrote: Using an imperative language for a descriptive purpose is a bad mismatch of tools and has been ever since the practical effect of init scripts has become fairly standardized. Some init scripts in Debian build dynamic configuration before the daemon is started. It has grown to be an important part of conffile and configuration management for software that cannot by itself read its configuration in snippets from a foo.conf.d directory. I am not sure how we would handle that in a descriptive approach. It has once been suggested by people to use wrappers around the daemon and to call that wrapper from the job description, but that strikes me as _much_ more ugly than having an init script. Greetings Ma old conservative sneg rc -- -- !! 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: http://lists.debian.org/e1uhzwx-0008dh...@swivel.zugschlus.de
Re: [clang] Report bugs on packages failing to build with clang
On Thursday, May 30, 2013 10:15:11 AM Sylvestre Ledru wrote: On 30/05/2013 01:51, Scott Kitterman wrote: Sylvestre Ledru sylves...@debian.org wrote: Hello, With the recent setup of the parallel build infrastructure using clang instead of gcc [1], I would like to start to report bugs on packages failing to build with clang (with patches if possible). The severity would be minor. Of course, I would do that only when the issue is upstream [2]. Any comments ? It seems to me that FTBFS with clang should be wishlist. I also considered this severity but the documentation [1] says for any feature request, and also for any bugs that are very difficult to fix due to major design considerations. Not sure it matches. Sylvestre [1] http://www.debian.org/Bugs/Developer#severities In that case, I'd say they aren't bugs at all. It may be that a FTBFS with clang is a symptom of some underlying issue that should be addressed, but I don't think non-wishlist bugs should be filed ONLY on the basis of that FTBFS. All that does is impose a burden on package maintainers to determine if the FTBFS is a real issue or not. I don't think that's appropriate for a MBF. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2885641.NaKQpy7T89@scott-latitude-e6320
Re: systemd .service file conversion
On Wed, 29 May 2013 21:10:41 +0200, Wouter Verhelst wou...@debian.org wrote: At Debian, traditionally we support more than one choice (at least for a while), until the community at large decides that option X is the best one (and then we drop support for all the other options). The downside of that is that it takes a lot longer for us to make a choice, but eventually you usually get the better option. The only reason why we seem to be unable to do so this time is that some people claim the sky will fall if we don't make a choice NOW!!1! I think it makes perfect sense for us to support systemd, openrc, and upstart, at least for the time being; I doubt we'll continue supporting all three options until the end of times, but we don't have to do that. At any rate, we *need* to support multiple options for our non-Linux ports, too, so this wouldn't be a lost effort. The init system case is special because supporting another init script system will most probably mean that all packages delivering an init script ($ ls /etc/init.d/ | wc -l = 116 on my small notebook system) will have to adapt. This is a major transition, and while we offer multiple init systems as officially supported, additional work is needed by all developers. 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: http://lists.debian.org/e1uhzzb-0008j5...@swivel.zugschlus.de
Re: systemd .service file conversion
On Thu, 30 May 2013 11:46:51 +0300, Riku Voipio riku.voi...@iki.fi wrote: By switching early we can affect how a piece of software will evolve. This is the case with software that has a cooperative upstream. systemd's upstream is known not to be. 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: http://lists.debian.org/e1ui00a-0008jd...@swivel.zugschlus.de
Re: default MTA
On Thu, 30 May 2013 11:11:06 +0200, Bernhard R. Link brl...@debian.org wrote: * Chris Knadle chris.kna...@coredump.us [130529 08:29]: - Exim configuration is more human readable than Postifx's, IMHO. Postfix configuration is concise but terse, and there are typically blocks of options separated by commas that doesn't easily allow commenting on specific config options. Configurability is an important point. Having had to use postfix lately I'm quite suprised anyone voluntarily uses that thing. Postfix feels like some ad-hoc configuration gone absurd, by only making special use cases configuable and then misusing those options for other things. Together with this splitting in many little programs which all lack most of the information, configuring postfix is a large puzzle and any advanced postfix configuration (even from the official documentation) looks like McGyver was out of duct-tape but had to build a nuclear reactor from kitchen parts with only the transparent tape for office use. While I don't consider postfix as bad as you describe, I tend to describe Postfix as the menu in a better restaurant: A relatively small number of sophisticated dishes which you can choose from, and if you like them, you will be perfectly satisfied. If you want fries instead of plain potatoes, you're basically hosed. Exim, on the other hand, is the fully equipped kitchen with a full larder and fridge, allowing you to cook exactly what you want, if you're willing to learn cooking or already bring some cooking knowledge. This approach might lead to something uneatable, though. Both solutions have their advantages and disadvantages. People should be able to choose. For the default case of an user not knowing what an MTA is, both exim and postfix are suitable to be the default in Debian. Exim's design is a bit 1990ies, with a big suid root binary, while Postfix's design is more modern regarding process structure and privilege separation. Being biased myself, I'd say not to change a running system and to keep exim as default. It would be nice to debconfize SMTP auth in the exim is the client case though, as this is a quite common use case. With my maintainer hat on, Patches are appreciated. 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: http://lists.debian.org/e1ui0gx-kg...@swivel.zugschlus.de
Re: Eliminating mail-transport-agent from standard
On Thu, 30 May 2013 12:06:17 +0300, Riku Voipio riku.voi...@iki.fi wrote: On Mon, May 27, 2013 at 08:27:36PM -0700, Josh Triplett wrote: In addition to determining the MTA pulled in by default for packages which require mail-transport-agent in order to function (the provider of default-mta), I'd like to propose as a release goal that we not have any MTA in standard anymore. I've actually worked towards this goal for a while now, and made a fair bit of progress; this mail documents the remaining work required, most of which is simple dependency/priority changes and patch application. +1 In this age of spam, installing email server should be explicit decision by system admin rather that something that becomes automatically when you install Debian. What is the danger of having a local email server on the system, in the way we install exim in the default? 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: http://lists.debian.org/e1ui0h5-kt...@swivel.zugschlus.de
Re: default MTA
On Wednesday, May 29, 2013 05:11:35 PM Josselin Mouette wrote: Le mercredi 29 mai 2013 à 16:31 +0200, Javier Fernandez-Sanguino a écrit : Take for example, smartmoontools [1]. Currently, if an end-user installs smartmoontools and a hard-disk fails (i.e. smartd detects a problem with one HD) he will *not* see any notification: the failure is sent through local e-mail. He will see a notification on his desktop. Clear, understandable and translated in his configured language: https://git.gnome.org/browse/gnome-disk-utility/tree/src/notify/gdusdmonitor .c (The code is different but already here in squeeze and wheezy.) I don’t see why he would need to see it again in a cryptic English e-mail. You are really looking for a solution to a nonexistent problem. Desktop notifications are really only useful for informing the user of things as they happen. If the user doesn't happen to be sitting at the screen when the notification happens, they'll never know. Even if they are using a system that allows them to go back and review their notification history when they return to their system, that's not the normal usage pattern. Desktop notifications are no more a complete solution to the problem of letting the user know than local mail is. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5100284.2cAPWE0nHA@scott-latitude-e6320
Re: Proposed mass bug filing: Removal of automake1.4, automake1.9, automake1.10 and automake1.11
Eric Dorland eric at debian.org writes: at the very beginning of the jessie release cycle I'd like to propose a mass bug filing to remove all the current automake packages in unstable (automake1.13 is in the NEW queue). Automake 1.4 in Erm. How about you’d have checked with the maintainers of those packages *before* shoving automake1.13 as “automake” into NEW, thus breaking the build of unrelated packages? http://buildd.debian-ports.org/status/ fetch.php?pkg=libnfsidmaparch=m68kver=0.25-5stamp=1369888632 Manual analysis: (pbuild7107)aranym:/# apt-get install automake1.11 Reading package lists... Done Building dependency tree Reading state information... Done Package automake1.11 is a virtual package provided by: automake 1:1.11.6-1 [Not candidate version] E: Package 'automake1.11' has no installation candidate (pbuild7107)aranym:/# apt-cache policy automake automake: Installed: (none) Candidate: 1:1.13.2-1 Version table: 1:1.13.2-1 0 500 http://ftp.de.debian.org/debian-ports/ unstable/main m68k Packages 1:1.11.6-1 0 500 http://ftp.de.debian.org/debian-ports/ unstable/main m68k Packages I expect more packages to FTBFS soonish. There’s no existing bugreport against *either* libnfsidmap *or* automake, and I’m not filing one because I don’t know which of those packages is in the wrong, for now, since this apparently didn’t get discussed any further. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130530t124356-...@post.gmane.org
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On 26-05-13 20:02, Bastien ROUCARIES wrote: On Sat, May 25, 2013 at 2:27 PM, Charles Plessy ple...@debian.org wrote: Hi Dennis and everybody, somewhat related to this, I would like to know if there is a package that could host Amazon's EC2 public certificate ? In Ubuntu it is added to the euca2ools package, because a program of this package can use it, but it is not part of the upstream source (which is not Amazon), so I really would prefer to ship the certificate somewhere else. I proposed ca-certificates earlier, but the result was inconclusive. http://bugs.debian.org/573857 Would there be a volunteer to maintain new package from scratch if needed ? Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? Could you elaborate on what it is you propose exactly, because I could interpret this in many different ways. D. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a72ee6.7040...@nikhef.nl
Re: systemd .service file conversion
On Thu, 30 May 2013 11:38:22 +0200, Salvo Tomaselli wrote: I have tried systemd, and I like the approach it has, and in a few years I believe it has potential. But... using it to restart my computer i need to do an hard reset (and think of how happy would I be if my computer had been a server in a rack on the other side of the planet), and gave me several problems related to switching from X11 to vt and vice versa. If you haven't already, please file bugs for these issues so that they can be investigated and fixed. -- Sam Morris https://robots.org.uk/ PGP key id 1024D/5EA01078 3412 EA18 1277 354B 991B C869 B219 7FDB 5EA0 1078 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2013.05.30.10.33...@robots.org.uk
Re: default MTA
On 30/05/13 12:27, Scott Kitterman wrote: On Thursday, May 30, 2013 12:16:38 PM Carlos Alberto Lopez Perez wrote: On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. Since ~80% of the Exim installations are for an ancient version that AFAIK tell from a few moments of checking was never the version in a Debian release, I don't think that's it. Scott K Exim 4.69 was shipped with Debian 5.0 (Lenny) http://archive.debian.net/lenny/exim4 signature.asc Description: OpenPGP digital signature
Re: Eliminating mail-transport-agent from standard
On Thu, 30 May 2013 12:40:03 +0200 Marc Haber mh+debian-de...@zugschlus.de wrote: On Thu, 30 May 2013 12:06:17 +0300, Riku Voipio riku.voi...@iki.fi wrote: On Mon, May 27, 2013 at 08:27:36PM -0700, Josh Triplett wrote: In addition to determining the MTA pulled in by default for packages which require mail-transport-agent in order to function (the provider of default-mta), I'd like to propose as a release goal that we not have any MTA in standard anymore. I've actually worked towards this goal for a while now, and made a fair bit of progress; this mail documents the remaining work required, most of which is simple dependency/priority changes and patch application. +1 In this age of spam, installing email server should be explicit decision by system admin rather that something that becomes automatically when you install Debian. What is the danger of having a local email server on the system, in the way we install exim in the default? Turn that on it's head: What is the benefit of having a local email server installed on every system compared to the space it takes up and the fact that it sits there unconfigured, doing nothing useful? So far, the only answer I've come across for that is because 'at' depends on it, to which the correct solution is: apt-get --purge autoremove at -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpwEmW0fnaFZ.pgp Description: PGP signature
Re: default MTA
On Thursday, May 30, 2013 01:01:46 PM Carlos Alberto Lopez Perez wrote: On 30/05/13 12:27, Scott Kitterman wrote: On Thursday, May 30, 2013 12:16:38 PM Carlos Alberto Lopez Perez wrote: On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. Since ~80% of the Exim installations are for an ancient version that AFAIK tell from a few moments of checking was never the version in a Debian release, I don't think that's it. Scott K Exim 4.69 was shipped with Debian 5.0 (Lenny) http://archive.debian.net/lenny/exim4 Thanks. I was looking at it wrong. It would, however, be a bit surprising if 1/3 of the mail servers on the internet were running Lenny at this point. It's also worth noting that only something like half the servers that provided a banner provided enough information to identify the software in use, so I'm not sure how much it really tells us. Scott K signature.asc Description: This is a digitally signed message part.
Re: default MTA
On 30-05-13 12:27, Marc Haber wrote: We should make local mail or other messages trivially and automatically visible for people who have installed Debian in NNF[1] compliant way, but if one has gone to length to use something non-default, I think we can safely trust those people with taking other measures as well. While that's true, if we're going to be make the effort to make sure such notifications are trivially and automatically visibe for NNF users, it would be a waste if we didn't do it in such a way that people who make only the slightest of modifications could benefit from it as well. If we're making something GNOME-specific, we don't do that. If we make an application that fits into any fdo-compliant notification area, we do. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a73882.4010...@debian.org
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On Thu, May 30, 2013 at 12:50 PM, Dennis van Dok denni...@nikhef.nl wrote: On 26-05-13 20:02, Bastien ROUCARIES wrote: On Sat, May 25, 2013 at 2:27 PM, Charles Plessy ple...@debian.org wrote: Hi Dennis and everybody, somewhat related to this, I would like to know if there is a package that could host Amazon's EC2 public certificate ? In Ubuntu it is added to the euca2ools package, because a program of this package can use it, but it is not part of the upstream source (which is not Amazon), so I really would prefer to ship the certificate somewhere else. I proposed ca-certificates earlier, but the result was inconclusive. http://bugs.debian.org/573857 Would there be a volunteer to maintain new package from scratch if needed ? Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? Could you elaborate on what it is you propose exactly, because I could interpret this in many different ways. Using only one lib for crypto (libnss) will allow to use only one trust certificate format D. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cae2spaa4bn36e02xmyrady7p7jkln6cbm+nclyn1j-yz-f+...@mail.gmail.com
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On Thu, May 30, 2013 at 12:50 PM, Dennis van Dok denni...@nikhef.nl wrote: On 26-05-13 20:02, Bastien ROUCARIES wrote: On Sat, May 25, 2013 at 2:27 PM, Charles Plessy ple...@debian.org wrote: Hi Dennis and everybody, somewhat related to this, I would like to know if there is a package that could host Amazon's EC2 public certificate ? In Ubuntu it is added to the euca2ools package, because a program of this package can use it, but it is not part of the upstream source (which is not Amazon), so I really would prefer to ship the certificate somewhere else. I proposed ca-certificates earlier, but the result was inconclusive. http://bugs.debian.org/573857 Would there be a volunteer to maintain new package from scratch if needed ? Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? Could you elaborate on what it is you propose exactly, because I could interpret this in many different ways. See also https://fedoraproject.org/wiki/FedoraCryptoConsolidation D. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAE2SPAa1qk-zLMb2Dau_H1vB9CzJKKye6=cz2re0o_stw9k...@mail.gmail.com
Re: default MTA
On 30-05-13 12:16, Carlos Alberto Lopez Perez wrote: On 29/05/13 08:18, Chris Knadle wrote: - Exim is more popular http://www.securityspace.com/s_survey/data/man.201201/mxsurvey.html This is actually quite interesting. Given that Postfix is the default MTA on RHEL/CentOS, SLES (SUSE) and Ubuntu; meanwhile Exim is only the default on Debian (AFAIK). I wonder if this means that Debian is used in more mail servers than the rest of the distributions together. From the bottom of that page: Exim (465,731 servers) Version Number of Servers Percent 4.69368,005 79.02% 4.7636,227 7.78% 4.7220,387 4.38% 4.7710,824 2.32% 4.678,297 1.78% 4.635,689 1.22% Other 16,302 3.50% 4.69 was the version of exim that shipped with Lenny; squeeze shipped with 4.72, wheezy with 4.80. If these are indeed all Debian servers, that would mean that 79.02% of 44.23% of 45.88% of all MX servers queried by these people use a no longer supported version of Debian. (79.02%: all exim servers running 4.69; 44.23%: percentage of all identifiable servers that is running exim; 45.88%: percentage of all MX servers that is running an identifiable mail server) -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a73b72.6020...@debian.org
Re: Debian systemd survey
On 30/05/13 11:19, Marc Haber wrote:
On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery r...@debian.org
wrote:
Using an imperative language for a descriptive purpose is a bad mismatch
of tools and has been ever since the practical effect of init scripts has
become fairly standardized.
Some init scripts in Debian build dynamic configuration before the
daemon is started. It has grown to be an important part of conffile
and configuration management for software that cannot by itself read
its configuration in snippets from a foo.conf.d directory.
I am not sure how we would handle that in a descriptive approach.
My preferred answer is give the daemon better configuration handling,
so you can get maximum benefit from having a declarative init, but if
that isn't an option:
systemd:
ExecStartPre=/usr/share/myservice/hack-up-the-config.sh
ExecStart=/usr/sbin/myservice
Upstart:
pre-start script
# entirely untested, but [1] suggests that this might be right?
/usr/share/myservice/hack-up-the-config.sh || { stop; exit 0; }
end script
script
/usr/sbin/myservice
end script
Or keep using a legacy sysvinit script (they'll have to remain supported
for quite some time, at least in runlevels 2-5, for LSB if nothing
else), or wrap the daemon in a shell script that does some initial setup
and eventually exec()s the real daemon (like openarena-server).
Perhaps your favourite package can't derive much/any benefit from a more
declarative init, but I would guess that 90%+ do. That's still a
significant reduction in the number of lines of shell script boilerplate
in the distribution :-)
S
[1]
http://upstart.ubuntu.com/cookbook/#stop-a-job-from-running-if-a-pre-start-condition-fails
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a738eb.9040...@debian.org
Re: default MTA
On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman deb...@kitterman.com wrote: Even if they are using a system that allows them to go back and review their notification history when they return to their system, It just occurred to me that you are describing a mail client. 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: http://lists.debian.org/e1ui1nv-0001ra...@swivel.zugschlus.de
Re: default MTA
On Thursday, May 30, 2013 05:11:06, Bernhard R. Link wrote: * Chris Knadle chris.kna...@coredump.us [130529 08:29]: - Exim configuration is more human readable than Postifx's, IMHO. Postfix configuration is concise but terse, and there are typically blocks of options separated by commas that doesn't easily allow commenting on specific config options. Configurability is an important point. Having had to use postfix lately I'm quite suprised anyone voluntarily uses that thing. Postfix feels like some ad-hoc configuration gone absurd, by only making special use cases configuable and then misusing those options for other things. There's a reason it feels like this. Postfix was designed with security in mind, but wasn't focused on being a general purpose MTA. It happens to /work/ pretty well in that role in many cases, though. http://shearer.org/MTA_Comparison#Postfix Exim is exactly the opposite: its design was focused on being a general purpose MTA, but wasn't focused on security. Yet this doesn't mean that Exim is insecure. http://shearer.org/MTA_Comparison#Exim Together with this splitting in many little programs which all lack most of the information, configuring postfix is a large puzzle and any advanced postfix configuration (even from the official documentation) looks like McGyver was out of duct-tape but had to build a nuclear reactor from kitchen parts with only the transparent tape for office use. This feels like a fitting description. [Postfix's master.cf file is what I find the most confusing.] The only positive thing you can say about Postfix' configuration is that it might be better than sendmail's. Sendmail's configuration is so unreadable that nobody [in their right mind] configures it in the native format and instead does it with m4 scripts. However with m4 scripts I think Sendmail configuration might actually be less confusing than Postfix's. -- Chris -- Chris Knadle chris.kna...@coredump.us GPG Key: 4096R/0x1E759A726A9FDD74 signature.asc Description: This is a digitally signed message part.
Re: Eliminating mail-transport-agent from standard
On Thu, 30 May 2013 12:28:28 +0100, Neil Williams codeh...@debian.org wrote: What is the benefit of having a local email server installed on every system compared to the space it takes up and the fact that it sits there unconfigured, doing nothing useful? It sits there with a well reasoned default configuration, taking care of archiving local notifications from a number of subsystems. It is our fault that we don't provide an adequate way of presenting those notifications to the local user by default. 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: http://lists.debian.org/e1ui1rd-0001rp...@swivel.zugschlus.de
Re: systemd .service file conversion
Marc Haber mh+debian-de...@zugschlus.de writes: On Thu, 30 May 2013 11:46:51 +0300, Riku Voipio riku.voi...@iki.fi wrote: By switching early we can affect how a piece of software will evolve. This is the case with software that has a cooperative upstream. systemd's upstream is known not to be. I never quite understood why people seem to think systemd upstream is uncooperative (well, apart from the whole non-linux porting deal, where their stance is completely understandable too). My experience so far suggests otherwise: I've have had very fruitful interactions with them, multiple times, in person and over the wire aswell. From the mailing list and IRC channel, I get the same impression I got when personally involved. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87mwrc7kuf.fsf@algernon.balabit
Re: default MTA
On Thu, May 30, 2013 at 12:31:22PM +0200, Marc Haber wrote: Btw, I fear that systemd's binary logs are going to import this method of inefficient work in our world. I surely hope I am wrong on this count. journalctl gives pretty much exactly the same output as /var/log/messages and so on. As a side-benefit, instead of using grep, it indexes various things so you can more quickly filter. For most use caes though, the switch is rather easy: journalctl | grep something vs grep something /var/log/messages and journalctl -f vs tail -f /var/log/messages So if you don't want to know anything, you don't need to know much. Further, you can keep another syslog running. In any case, journal is quite efficient. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530114817.ga16...@bkor.dhs.org
Re: Switching to mozilla ESR in stable-security
Le jeudi, 30 mai 2013 00.10:11, Philip Hands a écrit : Moritz Mühlenhoff j...@inutil.org writes: Willi Mann foss...@wm1.at schrieb: Moritz Muehlenhoff wrote: As such, we'll switch to releasing the ESR releases of iceweasel and icedove in stable-security. wouldn't it be better to do the bumps of major ESR versions in point releases? That might also allow a few more extensions to be updated. We need to release the security updates when ready and cannot realistically align the point releases with Mozilla releases. Does this perhaps indicate that these packages are not really suitable for stable, and should instead be provided via backports or some similar mechanism (i.e. a mozilla-bikeshed[1])? I concur. Although I very much understand the practical constraints leading to softening the no new upstream versions in stable policy for the specific case of browsers, it nevertheless feels as jumping on the no stability exists outside of the latest upstream releases bandwagon. If we can't handle the backporting of serious security issues on top of our stable version (in order to maximise the avoidance of regressions), then maybe said software shouldn't be shipped in stable in the first place. Thoughts ? OdyX signature.asc Description: This is a digitally signed message part.
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
On 30-05-13 13:16, Bastien ROUCARIES wrote: Using only one lib for crypto (libnss) will allow to use only one trust certificate format 'Allow only one' doesn't immediately strike me as beneficial, but I see what you mean. The discussion is similar to others (such as about which init system to support) where the question is 'why do we have X implementations of Y?' where X 1. There are pros and cons to such a bold plan as you propose. I can think of a few, and I'm sure others can think of many more. But more importantly, it takes effort to work out the plan, inventory the pros and cons, calculate the required efford and herd it along. Most work on Debian is on a voluntary basis, the available effort depends on what people will want to invest (even just to read this e-mail!). I'm not volunteering. But to seed the discussion (maybe): Pros: having only one crypto system will simplify the handling of certificates. Cons: - not all crypto libraries are equivalent; choosing one will exclude some functionality provided by others - we somehow have to deal with legacy systems that can't convert - adoption of new software that uses something else is harder Cheers, Dennis van Dok -- D.H. van Dok :: Software Engineer :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a74103.5040...@nikhef.nl
Bug#710382: ITP: jmtpfs -- FUSE based filesystem for accessing MTP devices
Package: wnpp Severity: wishlist Owner: Apollon Oikonomopoulos apoi...@gmail.com * Package name: jmtpfs Version : 0.4 Upstream Author : Jason Ferrara jason.ferr...@jacquette.com * URL : http://research.jacquette.com/jmtpfs-exchanging-files-between-android-devices-and-linux/ * License : GPL-3 Programming Lang: C++ Description : FUSE based filesystem for accessing MTP devices jmtpfs is a FUSE and libmtp based filesystem for accessing MTP (Media Transfer Protocol) devices. It was specifically designed for exchaning files between Linux (and Mac OS X) systems and newer Android devices that support MTP but not USB Mass Storage. The goal is to create a well behaved filesystem, allowing tools like find and rsync to work as expected. MTP file types are set automatically based on file type detection using libmagic. Setting the file appears to be necessary for some Android apps, like Gallery, to be able to find and use the files. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530120311.GA15484@marvin
Re: default MTA
On Thu, May 30, 2013 at 01:31:14PM +0200, Wouter Verhelst wrote: If we're making something GNOME-specific, we don't do that. If we make an application that fits into any fdo-compliant notification area, we do. Within GNOME we usually create a freedesktop.org solution, then use that within GNOME. This is how udisks works. A large generic part, then another GNOME-specific component. Seems the solutions are very focussed on the assumption that things cannot be changed. E.g. programs currently send email, so email it has to be forever. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530115601.gb16...@bkor.dhs.org
Re: Eliminating mail-transport-agent from standard
On Thu, 30 May 2013 13:54:35 +0200 Marc Haber mh+debian-de...@zugschlus.de wrote: On Thu, 30 May 2013 12:28:28 +0100, Neil Williams codeh...@debian.org wrote: What is the benefit of having a local email server installed on every system compared to the space it takes up and the fact that it sits there unconfigured, doing nothing useful? It sits there with a well reasoned default configuration, taking care of archiving local notifications from a number of subsystems. There are many systems where such notifications will never be generated and besides, why isn't /var/log/ suitable for those? (at least as a fallback?) It's not a huge issue because the kinds of systems I have in mind will use multistrap or debootstrap, not d-i, to do the installation so standard doesn't usually get installed at all. However, these systems work perfectly well without any MTA and the lack of notifications is *not* a valid reason to impose an MTA upon them. There is absolutely no reason why adding Priority: standard to such systems should impose an MTA. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpswYBbJ7eqr.pgp Description: PGP signature
Re: default MTA
On Thu, May 30, 2013 at 01:51:11PM +0200, Marc Haber wrote: On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman deb...@kitterman.com wrote: Even if they are using a system that allows them to go back and review their notification history when they return to their system, It just occurred to me that you are describing a mail client. Suggest receiving nagios notifications via email. Sometimes when you're busy your inbox is overloaded with stuff that is already up. Email is one way of getting notifications, but for desktop things, it is rather imperfect. Would be kind of funny to receive an email notification via email though :P -- Regards, Olav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530120057.gc16...@bkor.dhs.org
Re: systemd .service file conversion
On Thu, May 30, 2013 at 12:22:34PM +0200, Marc Haber wrote: This is the case with software that has a cooperative upstream. systemd's upstream is known not to be. I've seen as well as attended various conferences where systemd was explained. There have also been various systemd specific events. There was also a open meeting between systemd developers and systemd users at FOSDEM (which I attended). Interested people from various distributions discussed the state of systemd, what they want, etc. Upstream discussed planned changes, etc. Above is what happens in practice. Seems cooperative. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530121102.gd16...@bkor.dhs.org
Re: default MTA
On 30-05-13 13:56, Olav Vitters wrote: On Thu, May 30, 2013 at 01:31:14PM +0200, Wouter Verhelst wrote: If we're making something GNOME-specific, we don't do that. If we make an application that fits into any fdo-compliant notification area, we do. Within GNOME we usually create a freedesktop.org solution, then use that within GNOME. This is how udisks works. A large generic part, then another GNOME-specific component. Sure. Seems the solutions are very focussed on the assumption that things cannot be changed. E.g. programs currently send email, so email it has to be forever. No, that's not how I interpret the discussion. Doing important notifications through mail only means that many people won't see the important notifications due to the way we handle mail by default currently. So we need to fix that. However, the mail approach does have certain upsides for large installations and multi-user systems: - Regular users can't always see what's in syslog, so getting the output of their cron or at jobs there won't help them. - For the things that really really matter, it makes sense to have them sent to a central root mail address, so that in case of a large multi-system installation, the sysadmin knows when things go really really wrong. If we configure things so that root mail gets sent to the user that was created at install time by default, and then install some fdo notification thing that allows a user to read and mark read or delete (or both) mails in their local mailbox by default, that should work for both use cases. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a7457e.6020...@debian.org
Bug#710385: ITP: ruby-rgen -- Ruby modelling and generator framework
Package: wnpp Severity: wishlist Owner: Stig Sandbeck Mathisen s...@debian.org * Package name: ruby-rgen Version : 0.6.2 Upstream Author : Martin Thiede * URL : http://ruby-gen.org/ * License : MIT Programming Lang: Ruby Description : Ruby modelling and generator framework RGen is a framework for Model Driven Software Development (MDSD)in Ruby. This means that it helps you build Metamodels, instantiate Models, modify and transform Models and finally generate arbitrary textual content from it. RGen is a dependency for the new future parser in puppet 3.2.x -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530122019.15253.70847.report...@turbotape.w.bitbit.net
Re: default MTA
Marc Haber mh+debian-de...@zugschlus.de writes: On Thu, 30 May 2013 06:46:46 -0400, Scott Kitterman deb...@kitterman.com wrote: Even if they are using a system that allows them to go back and review their notification history when they return to their system, It just occurred to me that you are describing a mail client. Let's add biff and we have cross-desktop real-time notification in place :) Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738t4oe7z@nemi.mork.no
Re: systemd .service file conversion
On Thu, May 30, 2013 at 12:21:33PM +0200, Marc Haber wrote: The init system case is special because supporting another init script system will most probably mean that all packages delivering an init script ($ ls /etc/init.d/ | wc -l = 116 on my small notebook system) will have to adapt. This is a major transition, and while we offer multiple init systems as officially supported, additional work is needed by all developers. The systemd files should be pushed upstream (this is what other distributions have done and will do). Furthermore, systemd support sysvinit. Obviously there will be a pain when switching, but then I guess your argument is that any change is bad? -- Regards, Olav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530121653.ge16...@bkor.dhs.org
Re: systemd .service file conversion
On May 30, Gergely Nagy alger...@balabit.hu wrote: I never quite understood why people seem to think systemd upstream is uncooperative (well, apart from the whole non-linux porting deal, where their stance is completely understandable too). My experience so far There is also the kill features Red Hat does not care about deal, and the invent a new a configuration files scheme because it better suits RPM and Red Hat policies deal. Upstream is very cooperative, as long as your needs align with the ones of Red Hat. -- ciao, Marco signature.asc Description: Digital signature
Re: Switching to mozilla ESR in stable-security
* Didier Raboud: If we can't handle the backporting of serious security issues on top of our stable version (in order to maximise the avoidance of regressions), then maybe said software shouldn't be shipped in stable in the first place. Thoughts ? Which web browsers would remain in stable if we applied this criterion consistently? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5awljc7@mid.deneb.enyo.de
Re: Switching to mozilla ESR in stable-security
Le jeudi, 30 mai 2013 14.53:44, Florian Weimer a écrit : * Didier Raboud: If we can't handle the backporting of serious security issues on top of our stable version (in order to maximise the avoidance of regressions), then maybe said software shouldn't be shipped in stable in the first place. Thoughts ? Which web browsers would remain in stable if we applied this criterion consistently? Although that makes me very sad, if we (collectively) give up packaging browser extensions (hence letting our users rely on third-party repositories to get access to [non-]free binaries) and frozen browsers in stable, then maybe the correct answer to your question is none. OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201305301520.29815.o...@debian.org
Re: systemd .service file conversion
(I'm afraid to feed the troll) 2013/5/30 Marco d'Itri m...@linux.it: On May 30, Gergely Nagy alger...@balabit.hu wrote: I never quite understood why people seem to think systemd upstream is uncooperative (well, apart from the whole non-linux porting deal, where their stance is completely understandable too). My experience so far There is also the kill features Red Hat does not care about deal, Do you have an example? and the invent a new a configuration files scheme because it better suits RPM and Red Hat policies deal. Do you have an example? I have a example that show systemd taking non-RH solutions: /etc/hostname [ref] [ref]: http://0pointer.de/blog/projects/the-new-configuration-files Upstream is very cooperative, as long as your needs align with the ones of Red Hat. examples? Regards -- Mathieu Parent -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFX5sby+c5JAabcZoaByv_=jR5FtYv=0f+lqdrxb4fiwhgx...@mail.gmail.com
Re: [clang] Report bugs on packages failing to build with clang
On Thu, May 30, 2013 at 06:36:32AM -0400, Scott Kitterman wrote: In that case, I'd say they aren't bugs at all. It may be that a FTBFS with clang is a symptom of some underlying issue that should be addressed, but I don't think non-wishlist bugs should be filed ONLY on the basis of that FTBFS. All that does is impose a burden on package maintainers to determine if the FTBFS is a real issue or not. I don't think that's appropriate for a MBF. It's not like clang has non-standard ideas regarding the spec, often times these errors are more strict readings of the spec, and relying on gcc's quirks isn't a great idea. If code can be fixed, it'd a good idea, since gcc may (and has, in the past), changed non-standard behavior to be more correct. minor severity sounds good to me :) Cheers, Paul -- .''`. Paul Tagliamonte paul...@debian.org : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag signature.asc Description: Digital signature
Re: Switching to mozilla ESR in stable-security
On Thu, May 30, 2013 at 03:20:29PM +0200, Didier 'OdyX' Raboud wrote: Which web browsers would remain in stable if we applied this criterion consistently? Although that makes me very sad, if we (collectively) give up packaging browser extensions (hence letting our users rely on third-party repositories to get access to [non-]free binaries) and frozen browsers in stable, then maybe the correct answer to your question is none. And do you think that would be the best outcome for Debian users? FWIW, I don't. I think the compromise that the security team is proposing is much more reasonable than such an alternative. Note that the presence of non-free extension in the 3rd party repositories that come pre-configured with Debian-distributed browsers (and incresingly more other software) is a different problem. And one we should tackle, IMHO, but that's for a separate discussion. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530132922.gb6...@upsilon.cc
Bug#710394: ITP: javamail -- JavaMail API reference implementation
Package: wnpp Severity: wishlist Owner: Emmanuel Bourg ebo...@apache.org * Package name: javamail Version : 1.5.0 Upstream Author : Bill Shannon bill.shannon@oracle * URL : http://javamail.java.net * License : CDDL-1.1 | GPL-2 with Classpath Exception Programming Lang: Java Description : JavaMail API reference implementation The JavaMail API is a set of abstract APIs that model a mail system. The API provides a platform independent and protocol independent framework to build Java technology based email client applications. The JavaMail API provides facilities for reading and sending email. Service providers implement particular protocols. Several service providers are included with the JavaMail API package; others are available separately. The JavaMail API is implemented as a Java optional package that can be used on JDK 1.4 and later on any operating system. The JavaMail API is also a required part of the Java Platform, Enterprise Edition (Java EE). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530132738.3052.87137.reportbug@debiandev
Re: [clang] Report bugs on packages failing to build with clang
On Thursday, May 30, 2013 09:34:06 AM Paul Tagliamonte wrote: On Thu, May 30, 2013 at 06:36:32AM -0400, Scott Kitterman wrote: In that case, I'd say they aren't bugs at all. It may be that a FTBFS with clang is a symptom of some underlying issue that should be addressed, but I don't think non-wishlist bugs should be filed ONLY on the basis of that FTBFS. All that does is impose a burden on package maintainers to determine if the FTBFS is a real issue or not. I don't think that's appropriate for a MBF. It's not like clang has non-standard ideas regarding the spec, often times these errors are more strict readings of the spec, and relying on gcc's quirks isn't a great idea. If code can be fixed, it'd a good idea, since gcc may (and has, in the past), changed non-standard behavior to be more correct. minor severity sounds good to me :) For the ones that are actual errors, I agree. I don't think that FTBFS with clang is sufficient on it's own to determine that an error exists. Someone would need to look at the failure and see if it's really a bug before filing non-wishlist bugs. Scott K signature.asc Description: This is a digitally signed message part.
Re: Switching to mozilla ESR in stable-security
On Thu, May 30, 2013 at 8:53 PM, Florian Weimer wrote: Which web browsers would remain in stable if we applied this criterion consistently? The best browser ever; lynx. -- 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: http://lists.debian.org/caktje6gvmdr8pzydemdwyh69c-96cox7hxt-msyx_9-vop-...@mail.gmail.com
Re: default MTA
* Marc Haber mh+debian-de...@zugschlus.de [130530 12:39]: While I don't consider postfix as bad as you describe, I tend to describe Postfix as the menu in a better restaurant: A relatively small number of sophisticated dishes which you can choose from, and if you like them, you will be perfectly satisfied. If you want fries instead of plain potatoes, you're basically hosed. It's not that bad. Even the postfix kitchen can make fries. The tricky part is having one person served potatoes while the other person asks for fries, because the person putting those on the dish is not allowed to look at the order so they cannot determine from the drink whom they are making the food for. You need to employ two of them, one doing potatoes and the other one fries, but the waiter is not allowed to chose which kitchen the order is sent to, so you have to tell the waitor to write the order in a language the kitchen clerk cannot read, so the kitchen clerk will pass it to the person responsible for reading obliterated orders and this person you can tell it either give the order to the kitchen doing potatoes or the kitchen doing fries depending on what is wanted. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530135531.ga4...@client.brlink.eu
Re: systemd .service file conversion
Salvo Tomaselli wrote: I have tried systemd, and I like the approach it has, and in a few years I believe it has potential. But... using it to restart my computer i need to do an hard reset (and think of how happy would I be if my computer had been a server in a rack on the other side of the planet), and gave me several problems related to switching from X11 to vt and vice versa. Do you have any reason at all to believe that these were problems with systemd, rather than problems in Debian configuration or mostly independent bugs in other software that happened to trigger under systemd? Most likely the init that works most reliably in Debian for basic tasks like booting up a common default system and rebooting is still sysvinit. But that's not because of any positive quality of sysvinit, but rather because a lot of effort has been spent to paper over any problems. ANY init system can be tweaked to be able boot up and reboot a simple default system. That's not a relevant criterion to choose between them. If boot fails completely, in most cases that just demonstrates a lack of final polish. To make meaningful comparisons between systems, you need to at least see whether there are more fundamental problems underlying the failures, or why fixing or working around them takes more effort with some system. On a side note about Poettering, sometimes pulseaudio gets pulled in by some package that I install, and when this happens I stop hearing sounds from my computer, then I know I just need to remove it and everything will be fine I don't think PulseAudio works as an argument against him. See this mail for more details: https://lists.debian.org/1354241767.1887.76.camel@glyph.nonexistent.invalid -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1369921815.3628.71.camel@glyph.nonexistent.invalid
Re: Switching to mozilla ESR in stable-security
On 2013-05-29 20:50, Josh Triplett wrote: As a user of sid who also maintains various systems running stable, I rely on packages like xul-ext-adblock-plus to make it easier to install specific addons systemwide. I find it much easier to install those via the Debian packaging system rather than a user-level mechanism that involves running Firefox as one or more target users (or more likely doing the equivalent of creating a xul-ext-* package for local use). I realize that you can't maintain the full library of Firefox addons as packages, but I'm hoping that some of the most common and popular ones stick around and stay up to date, notably Adblock Plus, HTTPS Everywhere, and It's All Text. It was pointed out to me that Chrome supports policy definitions[1] where administrators can force certain extensions to be installed[2] and up-to-date. Now it might or might not make sense for packages to simply ship such a policy file, but at least it would provide a way for the administrator to have the same result. But I guess the Mozilla family does not support this yet? Kind regards Philipp Kern [1] http://www.chromium.org/administrators/policy-list-3 [2] /www.chromium.org/administrators/policy-list-3#ExtensionInstallForcelist -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0c705a399566a8ebb190a9ba2f5f2...@hub.kern.lc
Re: systemd .service file conversion
Mathieu Parent wrote: 2013/5/30 Marco d'Itri m...@linux.it: and the invent a new a configuration files scheme because it better suits RPM and Red Hat policies deal. Do you have an example? I think he's referring to the etc-overrides-lib semantics that systemd uses for configuration files. But it's wrong to describe that as better suits RPM and Red Hat policies; it's simply a better system than always having all configuration files in /etc and expecting users to possibly modify those same files, for reasons that are not specific to Red Hat. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1369922163.3628.75.camel@glyph.nonexistent.invalid
Re: libnss consolidation (was: X.509 and CA certificates for other purposes (i.e. the IGTF))
Le 30 mai 2013 14:08, Dennis van Dok denni...@nikhef.nl a écrit : On 30-05-13 13:16, Bastien ROUCARIES wrote: Using only one lib for crypto (libnss) will allow to use only one trust certificate format 'Allow only one' doesn't immediately strike me as beneficial, but I see what you mean. The discussion is similar to others (such as about which init system to support) where the question is 'why do we have X implementations of Y?' where X 1. There are pros and cons to such a bold plan as you propose. I can think of a few, and I'm sure others can think of many more. But more importantly, it takes effort to work out the plan, inventory the pros and cons, calculate the required efford and herd it along. Most work on Debian is on a voluntary basis, the available effort depends on what people will want to invest (even just to read this e-mail!). I'm not volunteering. But to seed the discussion (maybe): Pros: having only one crypto system will simplify the handling of certificates. Simplify security audit and get faits certification Avoid lice se issue with openssl ans GPL Avoid problem with gnutls ans suid Cons: - not all crypto libraries are equivalent; choosing one will exclude some functionality provided by others SEE compat layer - we somehow have to deal with legacy systems that can't convert - adoption of new software that uses something else is harder Cheers, Dennis van Dok -- D.H. van Dok :: Software Engineer :: www.nikhef.nl/grid :: Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On Wed, 2013-05-29 at 12:19 +0200, Dennis van Dok wrote: ...which is included in mozilla. That discussion should be taken there (indeed was[1]) as in Debian it was agreed we're not going to do better than Mozilla at judging CAs[2]. Yeah... sure... I was just mentioning it... Given that Mozilla performs pretty poorly with respect to security (not only in terms of certificates), that decision was probably not so good ;) Cheers, Chris smime.p7s Description: S/MIME cryptographic signature
Re: systemd .service file conversion
On Thu, May 30, 2013 at 04:50:15PM +0300, Uoti Urpala wrote: Do you have any reason at all to believe that these were problems with systemd, rather than problems in Debian configuration or mostly independent bugs in other software that happened to trigger under systemd? Whether or not systemd is responsible is not important if we are considering systemd as a default init: even if it is not responsible, if it exposes important bugs, those bugs need to be addressed before we could make a switch. What we need to make sure works is systemd in Debian, that is, integration is where all the work is going to be. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530141451.GA2864@debian
Re: Switching to mozilla ESR in stable-security
Hi Moritz. Moritz Muehlenhoff wrote: In the future the majority of packages should thus rather be installed through http://addons.mozilla.org instead of Debian packages. Form a security POV, I think this is really quite dangerous... actually tendency should go towards the direction that users install plugins addons only via the package management system. These plug-in systems which come with their own package/installation management are IMHO also quite bad from a philosophical POV... I mean they try to replace the traditional package management system, which is there and superior for very good reasons. Of course this doesn't mean that I wouldn't see the problem you face with keeping that stuff running and security supported. Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: default MTA
On Thu, 2013-05-30 at 07:53 -0400, Chris Knadle wrote: There's a reason it feels like this. Postfix was designed with security in mind, but wasn't focused on being a general purpose MTA. It happens to /work/ pretty well in that role in many cases, though. http://shearer.org/MTA_Comparison#Postfix Agreed,... but that also somehow indicates to me, that this would be the more appropriate default MTA. It will do quite securely what most people need, especially those end user who have no clue about running mailservers at all. If an expert admin is used to exim or anything else and thinks postfix cannot satisfy his demands,... it should be a simple task for him to switch :) Chris. smime.p7s Description: S/MIME cryptographic signature
Re: default MTA
On May 30, Chris Knadle chris.kna...@coredump.us wrote: There's a reason it feels like this. Postfix was designed with security in mind, but wasn't focused on being a general purpose MTA. Says who? Because I was around at the time, and I remember pretty well that the goal was to write a sendmail replacement. And apparently it worked. I think that ease of configurability is a major plus for Postfix when compared to Exim, since a common configurations is just a few lines long. -- ciao, Marco signature.asc Description: Digital signature
Multi-Arch for plugin packages
Hello!
I am maintaining one of the gkrellm2 plugin packages, namely
gkrellm2-cpufreq. All of these gkrellm2 plugin packages install their
plugins into /usr/lib/gkrellm2/plugins, including mine.
However, I was wondering whether the plugins should actually
get installed into /usr/lib/${DEB_HOST_MULTIARCH}/gkrellm2/plugins.
Since the plugins aren't really considered shared libraries, I
am not sure whether Multi-Arch has to be considered for these.
Anyone knows how Multi-Arch is handled for other similar plugin
packages, other than gkrellm2 plugins?
I have created a Multi-Arch version of my gkrellm2-cpufreq now,
but I haven't uploaded it yet.
Cheers,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a76a0d.6030...@physik.fu-berlin.de
Re: Multi-Arch for plugin packages
On Thu, May 30, 2013 at 11:02 PM, John Paul Adrian Glaubitz
glaub...@physik.fu-berlin.de wrote:
Hello!
I am maintaining one of the gkrellm2 plugin packages, namely
gkrellm2-cpufreq. All of these gkrellm2 plugin packages install their
plugins into /usr/lib/gkrellm2/plugins, including mine.
However, I was wondering whether the plugins should actually
get installed into /usr/lib/${DEB_HOST_MULTIARCH}/gkrellm2/plugins.
Since the plugins aren't really considered shared libraries, I
am not sure whether Multi-Arch has to be considered for these.
Anyone knows how Multi-Arch is handled for other similar plugin
packages, other than gkrellm2 plugins?
I have created a Multi-Arch version of my gkrellm2-cpufreq now,
but I haven't uploaded it yet.
Cheers,
Adrian
What we've done to IM module packages are exactly what you described,
they are plugins to UI toolkits (GTK+, Qt). But please be careful to
make sure they really work as expected when co-installed, i.e the i386
version of the application can use plugins from i386 path, and amd64
version of the program likewise.
--
Regards,
Aron Xu
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAMr=8w5xzOHgvmk0eovZ1EjMh17K=dmr6elpe872jkkyhah...@mail.gmail.com
Re: systemd .service file conversion
On May 30, Mathieu Parent math.par...@gmail.com wrote: (I'm afraid to feed the troll) Hint: before accusing somebody of trolling it is a good idea to find out who he is. There is also the kill features Red Hat does not care about deal, Do you have an example? Persistent naming of network interfaces. and the invent a new a configuration files scheme because it better suits RPM and Red Hat policies deal. Do you have an example? The /etc/ /lib/ /usr/lib/ split with files overriding each other, invented because RPM systems do not prompt the user on package upgrades and Red Hat does not support upgrading to the next major release. -- ciao, Marco signature.asc Description: Digital signature
Re: systemd .service file conversion
2013/5/30 Marco d'Itri m...@linux.it: On May 30, Mathieu Parent math.par...@gmail.com wrote: (I'm afraid to feed the troll) Hint: before accusing somebody of trolling it is a good idea to find out who he is. I apologize. -- Mathieu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFX5sbw4=z9+sr-fz4jpmmrhjbsywreqcf+ce6dijjcjxpw...@mail.gmail.com
Re: systemd .service file conversion
2013/5/30 Marco d'Itri m...@linux.it: On May 30, Mathieu Parent math.par...@gmail.com wrote: [···] There is also the kill features Red Hat does not care about deal, Do you have an example? Persistent naming of network interfaces. ... is entirely optional, and can be disabled if someone doesn't want it - but I can't see what is bad about it... Also, rationale and introduction to this feature is nicely documented: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Or do you mean something else? and the invent a new a configuration files scheme because it better suits RPM and Red Hat policies deal. Do you have an example? The /etc/ /lib/ /usr/lib/ split with files overriding each other, invented because RPM systems do not prompt the user on package upgrades and Red Hat does not support upgrading to the next major release. Well, that might have been one reason, but splitting the conf files has other advantages too. I like that I have the original file as reference, that I have very small config-override files which can easily be backed up, and it also simplifies updates, because I don't have to merge diffs of config files, but just need to adjust them later, if something has changed. So, this is not really RHEL specific, and some other non-RH software also has this scheme of storing config files. Regards, Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKNHny9ai+tL7mRb5qxyZ5vTWHuW54kRAEXE5f=x9y8tft6...@mail.gmail.com
Re: Multi-Arch for plugin packages
On 30/05/13 16:02, John Paul Adrian Glaubitz wrote:
I am maintaining one of the gkrellm2 plugin packages, namely
gkrellm2-cpufreq. All of these gkrellm2 plugin packages install their
plugins into /usr/lib/gkrellm2/plugins, including mine.
This seems appropriate.
However, I was wondering whether the plugins should actually
get installed into /usr/lib/${DEB_HOST_MULTIARCH}/gkrellm2/plugins.
You must install plugins to a location in which they will be loaded
correctly. :-)
It's usually fine for plugins to be in a non-multiarch location, because
you can only have one architecture's gkrellm2 installed - so it's OK
that you can't install gkrellm2-cpufreq:i386 and gkrellm2-cpufreq:amd64
at the same time, because only the one matching the architecture of
gkrellm2 would work anyway.
If the maintainer of gkrellm2 has already made it load from both
traditional and multiarch locations, then you may move the plugin to a
multiarch location (with an appropriate versioned dependency), but I
don't see any particular need to do so.
If the maintainer of gkrellm2 wants to make it load from *only* the
multiarch location, then that's a transition (involving a pile of
versioned Depends/Breaks), which they will have to coordinate with
plugin maintainers like you, and with the release team.
Anyone knows how Multi-Arch is handled for other similar plugin
packages, other than gkrellm2 plugins?
telepathy-mission-control-5 specifically isn't Multi-Arch, because I
didn't want to do a small transition (Mission Control + Empathy) for no
actual benefit.
The only plugins that do benefit from being Multi-Arch are those that
are loaded by more than one executable: glibc NSS modules, PAM modules,
ALSA plugins, that sort of thing. These usually have enough
reverse-dependencies that it's worth doing a gradual transition, by
having the plugin-loader load from both locations.
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51a76fef.6060...@debian.org
Re: default MTA
Marc Haber mh+debian-de...@zugschlus.de writes: Chris Knadle chris.kna...@coredump.us wrote: I don't like the fact that the /etc/exim4/passwd.client file is in a plaintext format, but there are usually several such files on systems such that realistically we're only really safe as long as the machines we run haven't been broken into. And if you think about things, it is clear that the client needs the plaintext password to be able to use it. Even if certificate authentication, the most secure authentication scheme available today, is used, you need the private key on the client. Which is why sending mail as a system service when doing so requires a user's ISP credentials is a dubious idea. If you send it from a user process, such as their mail client, you have sophisticated credential management capabilities available to you: everything from prompting to using a system keyring that's only decrypted when they're sitting in front of the computer. If you insist on giving your system processes the ability to authenticate as you, you end up storing random clear-text passwords in configuration files, readily available for theft by anyone who can read the contents of your hard drive or compromise the system user the MTA runs as. It's also a separation of privileges violation: why should your MTA be able to upload files to your web space or examine your billing and credit card information at your ISP? The situation is, of course, much improved if your ISP supports per-service or per-client passwords, like Google now does, at which point the password isn't as valuable and the security problem is less worrisome. You can also ameliorate the problem by using an encrypted file system, of course. But I doubt most users are doing that, and it still doesn't solve the separation of privileges issue. -- 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: http://lists.debian.org/87wqqgcw85@windlord.stanford.edu
Bug#710418: ITP: opendb -- PHP and MySQL based inventory application
Package: wnpp Severity: wishlist Owner: Michael Schultheiss schul...@debian.org * Package name: opendb Version : 1.5.0.7 Upstream Author : Jason Pell * URL : http://opendb.iamvegan.net * License : GPL v2 Programming Lang: PHP Description : PHP and MySQL based inventory application The Open Media Collectors Database (OpenDb) is a PHP and MySQL based inventory application that allows you to easily catalog and lend media-related information, including DVD, VCD, CD, VHS, games, books, and laser discs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530153340.9508.60610.report...@cartman.hq.amellus.com
Re: Multi-Arch for plugin packages
+++ Simon McVittie [2013-05-30 16:27 +0100]: The only plugins that do benefit from being Multi-Arch are those that are loaded by more than one executable: glibc NSS modules, PAM modules, ALSA plugins, that sort of thing. Or plugins that are used in build-depends. I don't know if this ever happens. Ideally not, and only the core program libraries would be needed to build against, but all sorts of crazy stuff goes on in people's builds. Does anyone know of examples? Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530154604.gy14...@stoneboat.aleph1.co.uk
Re: systemd .service file conversion
Jonathan Dowland wrote: On Thu, May 30, 2013 at 04:50:15PM +0300, Uoti Urpala wrote: Do you have any reason at all to believe that these were problems with systemd, rather than problems in Debian configuration or mostly independent bugs in other software that happened to trigger under systemd? Whether or not systemd is responsible is not important if we are considering systemd as a default init: even if it is not responsible, if it exposes You have the context wrong here. considering systemd as a default init is too vague. important bugs, those bugs need to be addressed before we could make a switch. What we need to make sure works is systemd in Debian, that is, integration is where all the work is going to be. Yes, there is integration work left. But that's really about the question is Debian ready to switch all user machines to systemd right now using the current packages?, and I think nobody would answer yes to that (before also updating systemd to a much newer upstream version, etc). I'm pretty sure that was not the context of the mail I was replying to. He was confusing what were likely integration issues with what would be more fundamental issues with systemd itself (that would make it less desirable to do the integration work and switch at all), and I tried to explain the difference. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1369927900.3628.93.camel@glyph.nonexistent.invalid
Re: Debian systemd survey
Marc Haber mh+debian-de...@zugschlus.de writes: Russ Allbery r...@debian.org wrote: Using an imperative language for a descriptive purpose is a bad mismatch of tools and has been ever since the practical effect of init scripts has become fairly standardized. Some init scripts in Debian build dynamic configuration before the daemon is started. It has grown to be an important part of conffile and configuration management for software that cannot by itself read its configuration in snippets from a foo.conf.d directory. I am not sure how we would handle that in a descriptive approach. Get rid of some of that complexity because it is pointless (you'll find that much of it is working around inadequacies in sysvinit). Get rid of more of it by building a static configuration from the dynamic configuration when it changes, where appropriate. For the rest, escape out to an imperative language to do that work. Something that upstart certainly supports, and that I believe systemd does as well. -- 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: http://lists.debian.org/87sj14cw3q@windlord.stanford.edu
Re: default MTA
On Thu, 30 May 2013 13:31:14 +0200, Wouter Verhelst wou...@debian.org wrote: On 30-05-13 12:27, Marc Haber wrote: We should make local mail or other messages trivially and automatically visible for people who have installed Debian in NNF[1] compliant way, but if one has gone to length to use something non-default, I think we can safely trust those people with taking other measures as well. While that's true, if we're going to be make the effort to make sure such notifications are trivially and automatically visibe for NNF users, it would be a waste if we didn't do it in such a way that people who make only the slightest of modifications could benefit from it as well. If we're making something GNOME-specific, we don't do that. If we make an application that fits into any fdo-compliant notification area, we do. I am with you on that count, provided that what we do does not eat too much effort that we might desperately need somewhere else. And from the requirement list for the solution of displaying those messages that has surfaced in this thread, I feel that a mail client is just the right tool do show the messages. 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: http://lists.debian.org/e1ui5im-0004ww...@swivel.zugschlus.de
Re: default MTA
On Thu, 30 May 2013 13:56:02 +0200, Olav Vitters o...@vitters.nl wrote: Seems the solutions are very focussed on the assumption that things cannot be changed. E.g. programs currently send email, so email it has to be forever. It is not a good idea to drop the way that 90 % of programs use to deliver messages. I really hate the idea of having a thing as fragile as dbus on a server just to collect status messages. 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: http://lists.debian.org/e1ui5jb-0004wd...@swivel.zugschlus.de
Re: default MTA
Marco d'Itri m...@linux.it writes: On May 30, Chris Knadle chris.kna...@coredump.us wrote: There's a reason it feels like this. Postfix was designed with security in mind, but wasn't focused on being a general purpose MTA. Says who? Because I was around at the time, and I remember pretty well that the goal was to write a sendmail replacement. And apparently it worked. Well, I'd say that at least part of the motivation was actually to write a qmail replacement, that didn't have someone with DJB's atitute to licensing as upstream -- it was for a long time called vmailer (v==vapour) as coined by DJB, and adopted by Wietse because it amused him. Given that it was qmail inspired, which was writen with the similar approach of having a crowd of distinct daemons perfornming one task each, with a UID for each, I'd say that the intent was to match qmail's security focus. If one were simply trying to replace Sendmail, the result might well have looked a lot more like Exim, with a monolithic executable, that forks into the various roles required. I think that ease of configurability is a major plus for Postfix when compared to Exim, since a common configurations is just a few lines long. I happen to agree with you, but it's clearly a matter of what one is used to, and of taste. It's also a question of what you want to do. Setting up SMTP-time rejection based on something like Spamassasin is far easier with Exim, for instance. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpPHvdXnaqUW.pgp Description: PGP signature
Bug#710421: ITP: pxe-pdhcp -- ProxyDHCP server for the non-DHCP server host
Package: wnpp Severity: wishlist Owner: Osamu Aoki os...@debian.org * Package name: pxe-pdhcp Version : 0.1 Upstream Author : FURUHASHI Sadayuki fr _at_ syuki.skr.jp * URL : http://svn.coderepos.org/share/lang/c/pxe-pdhcp/ * License : MIT Programming Lang: C Description : ProxyDHCP server for the non-DHCP server host Preboot Execution Environment (PXE) is a specification to boot PCs via the network connection. . There are 3 ways to set up the PXE. * Only with DHCP using the DHCPOFFER containing the PXE extension. -- dhcpd running with special DHCPOFFER in dhcpd.conf . * Run the ProxyDHCP server on the same server as the DHCP server. -- pxe + dhcpd running on the same server. * Run the ProxyDHCP server on a server different from the DHCP server. -- pxe-pdhcp (no dhcpd should be installed together) . This pxe-pdhcp package provides the support to the last option and this option is the most useful for people on the consumer grade home network since DHCP server can be left untouched which is impossible with other two options. . For BOOTP or DHCP needed for acquiring an IP address, it should be served from a different server than the one running this pxe-pdhcp. . For TFTP needed for transferring files, such as tftpd-hpa (or atftpd), it can be run on any server. . This program is a single purpose package and simpler to configure than the multi-feature dnsmasq package for the ProxyDHCP. --- The upstream source is old (2007) and not active. But there are patches on the web. The folllowing updates are made to fit for Debian. * string boundary patch. (http://d.hatena.ne.jp/flalin/about) * etherboot + syslog patch. (daydream.tripp...@gmail.co) * add pid file generation patch. (osamu) * Add Debian lsb init script. (osamu) * Cleaned source tree to make this as new upstream tar. I will make new URL for updated source as alioth git repo. Osamu signature.asc Description: Digital signature
Re: default MTA
On Thu, 30 May 2013 16:42:28 +0200, Christoph Anton Mitterer cales...@scientia.net wrote: Agreed,... but that also somehow indicates to me, that this would be the more appropriate default MTA. It will do quite securely what most people need, especially those end user who have no clue about running mailservers at all. Exim does it the same way. This is no argument for a change. 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: http://lists.debian.org/e1ui5ri-0004xg...@swivel.zugschlus.de
Re: default MTA
On Thu, 30 May 2013 16:53:56 +0200, m...@linux.it (Marco d'Itri) wrote: I think that ease of configurability is a major plus for Postfix when compared to Exim, since a common configurations is just a few lines long. How many lines does an average update-exim4.conf.conf have? 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: http://lists.debian.org/e1ui5sk-0004xo...@swivel.zugschlus.de
Re: Debian systemd survey
On Thu, 30 May 2013 12:32:59 +0100, Simon McVittie s...@debian.org
wrote:
On 30/05/13 11:19, Marc Haber wrote:
On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery r...@debian.org
wrote:
Using an imperative language for a descriptive purpose is a bad mismatch
of tools and has been ever since the practical effect of init scripts has
become fairly standardized.
Some init scripts in Debian build dynamic configuration before the
daemon is started. It has grown to be an important part of conffile
and configuration management for software that cannot by itself read
its configuration in snippets from a foo.conf.d directory.
I am not sure how we would handle that in a descriptive approach.
My preferred answer is give the daemon better configuration handling,
so you can get maximum benefit from having a declarative init, but if
that isn't an option:
That is often not an option. In my case, for example, it's skills. I
would not dare to write configuration handling code in C code that is
destined to run as root, while I don't have much issues in writing
such code in perl or even in shell. otoh, I maintain quite some daemon
packages that have their code written in C.
Additionally, this this traditionally written daemon does not work
nicely with systemd, so change the daemon instead of making systemd
behave as if it was destined for Unixoid OSses attitude is a big
topic for systemd opponents.
systemd:
ExecStartPre=/usr/share/myservice/hack-up-the-config.sh
ExecStart=/usr/sbin/myservice
Can the hack-up-the-config.sh give an error message that is shown to
the user? Can it abort the daemon start? How would systemd handle this
case if it is configured to make sure the daemon is always running?
Upstart:
pre-start script
# entirely untested, but [1] suggests that this might be right?
/usr/share/myservice/hack-up-the-config.sh || { stop; exit 0; }
end script
script
/usr/sbin/myservice
end script
Ugly. Same questions apply.
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: http://lists.debian.org/e1ui5co-0004w0...@swivel.zugschlus.de
Re: systemd .service file conversion
On Thu, 30 May 2013 17:07:08 +0200, Matthias Klumpp m...@debian.org wrote: So, this is not really RHEL specific, and some other non-RH software also has this scheme of storing config files. And it is still completely inferior even to dpkg-conffile handling, which has huge wishes left open as well. 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: http://lists.debian.org/e1ui5f6-0004wa...@swivel.zugschlus.de
Re: systemd .service file conversion
On Thu, 30 May 2013 14:16:53 +0200, Olav Vitters o...@vitters.nl wrote: On Thu, May 30, 2013 at 12:21:33PM +0200, Marc Haber wrote: The init system case is special because supporting another init script system will most probably mean that all packages delivering an init script ($ ls /etc/init.d/ | wc -l = 116 on my small notebook system) will have to adapt. This is a major transition, and while we offer multiple init systems as officially supported, additional work is needed by all developers. The systemd files should be pushed upstream (this is what other distributions have done and will do). Furthermore, systemd support sysvinit. How many features of systemd do we lose if we only use it to invoke daemons via the init script compatibility layer? I doubt the change makes sense if we end up doing things this way. Obviously there will be a pain when switching, but then I guess your argument is that any change is bad? My argument is that the one job one tool approach that Unixoid OSses use is a good approach and that I am extremely reluctant to drop it for a topic _this_ central in the operating system. And I am also opposing changes that will help in dropping the universal out of Debian's claim. 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: http://lists.debian.org/e1ui5h3-0004wk...@swivel.zugschlus.de
Re: systemd .service file conversion
On Thu, May 30, 2013 at 04:35:07PM +0200, Marco d'Itri wrote: On May 30, Mathieu Parent math.par...@gmail.com wrote: Do you have an example? The /etc/ /lib/ /usr/lib/ split with files overriding each other, invented because RPM systems do not prompt the user on package upgrades and Red Hat does not support upgrading to the next major release. I assume this is your interpretation? Upstream never said anything like above. I forgot the details, just has nothing to do with what you're suggesting. In any case, as a sysadmin you can configure systemd in /etc. This is pretty much like any other package. Aside from that there are some files somewhere else. -- Regards, Olav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130530162721.gf16...@bkor.dhs.org
Re: systemd .service file conversion
Matthias Klumpp wrote: 013/5/30 Marco d'Itri m...@linux.it: On May 30, Mathieu Parent math.par...@gmail.com wrote: [···] There is also the kill features Red Hat does not care about deal, Do you have an example? Persistent naming of network interfaces. ... is entirely optional, and can be disabled if someone doesn't want it - but I can't see what is bad about it... Also, rationale and introduction to this feature is nicely documented: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Or do you mean something else? I think Marco meant udev dropping support for the older variant of persistent names, the one the article you linked to refers at 'For a longer time udev shipped support for assigning permanent ethX names to certain interfaces based on their MAC addresses.'. As described in the article, there certainly were reasons other than Red Hat does not care about it to drop this feature. Whether it would have been preferable to keep optional support somewhat longer for backwards compatibility is another question. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1369931671.3628.106.camel@glyph.nonexistent.invalid
Re: Debian systemd survey
On Wed, May 22, 2013 at 08:35:52PM +0200, John Paul Adrian Glaubitz wrote: Please leave the FUD at the door. Writing upstart jobs is not difficult; while there are some gotchas currently with process lifecycle (which will be fixed soon), there is also very complete documentation (for these issues, and generally). systemd's unit files are still way simpler than upstart job files since these are just more or less a simple set of instructions to give systemd some hints on how to deal with the targets and services, it actually does most of the work automatically without the need of scripts at all (which are obviously still required for upstart). That's patently false. Upstart does not *require* scripts. It *supports* scripts, out of a recognition that C is not always the language of choice for implementation. This enables upstart jobs to do things like providing compatibility with existing, shell-based /etc/default/* files than packages are already using for daemon configuration; it enables rapid prototyping and more flexible customization and iteration of upstart jobs for debugging and development (because unlike the systemd developers, the upstart developers aren't trying to sell anyone a bill of goods about how their existing units are perfect and nothing will ever need to be patched downstream). But there is nothing in upstart that requires the use of scripts; anything that's done using 'script' in an upstart job could equally be done with 'exec', or could be built into a C daemon. The fact that a set of typical startup operations are handled in upstart by scripts is a design choice to not hard-code such policy into pid 1. This does not in any way speak to the complexity of the job file or unit file syntax. But this is ground that you and I have covered before, so I'm disappointed to see this claim being repeated. https://lists.debian.org/debian-devel/2012/02/msg00896.html -- 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: Multi-Arch for plugin packages
On Thu, May 30, 2013 at 04:27:43PM +0100, Simon McVittie wrote: Anyone knows how Multi-Arch is handled for other similar plugin packages, other than gkrellm2 plugins? telepathy-mission-control-5 specifically isn't Multi-Arch, because I didn't want to do a small transition (Mission Control + Empathy) for no actual benefit. The only plugins that do benefit from being Multi-Arch are those that are loaded by more than one executable: glibc NSS modules, PAM modules, ALSA plugins, that sort of thing. These usually have enough reverse-dependencies that it's worth doing a gradual transition, by having the plugin-loader load from both locations. Right. The rule of thumb here should be to only put plugins to a multiarch directory if the loader of the plugins is a library that it's interesting to enable as Multi-Arch: same. -- 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: Debian systemd survey
On Thu, May 30, 2013 at 12:32:59PM +0100, Simon McVittie wrote:
On 30/05/13 11:19, Marc Haber wrote:
On Wed, 29 May 2013 13:10:57 -0700, Russ Allbery r...@debian.org
wrote:
Using an imperative language for a descriptive purpose is a bad mismatch
of tools and has been ever since the practical effect of init scripts has
become fairly standardized.
Some init scripts in Debian build dynamic configuration before the
daemon is started. It has grown to be an important part of conffile
and configuration management for software that cannot by itself read
its configuration in snippets from a foo.conf.d directory.
I am not sure how we would handle that in a descriptive approach.
My preferred answer is give the daemon better configuration handling,
so you can get maximum benefit from having a declarative init, but if
that isn't an option:
systemd:
ExecStartPre=/usr/share/myservice/hack-up-the-config.sh
ExecStart=/usr/sbin/myservice
Upstart:
pre-start script
# entirely untested, but [1] suggests that this might be right?
/usr/share/myservice/hack-up-the-config.sh || { stop; exit 0; }
end script
script
/usr/sbin/myservice
end script
While you could do it this way, I think it would be better to do this:
pre-start exec /usr/share/myservice/hack-up-the-config.sh
exec /usr/sbin/myservice
No need to use 'script' if you're just running a single command (that just
forks a shell uselessly). And for a pre-start that's not expected to fail
in the normal case, there's no need to worry about a clean stop of the job
from the pre-start; the only difference this makes is to whether upstart
tries repeatedly to start the job and hits the respawn limit, or whether the
job is stopped immediately when there's a failure. So that's a trade-off
between a little bit of extra log spam, vs. spawning an extra shell.
Or keep using a legacy sysvinit script (they'll have to remain supported
for quite some time, at least in runlevels 2-5, for LSB if nothing
else), or wrap the daemon in a shell script that does some initial setup
and eventually exec()s the real daemon (like openarena-server).
Yes. A lot of the people expressing concern about being forced to migrate
to non-sysvinit seem to be overlooking the fact that both upstart and
systemd provide backwards-compatibility for sysvinit scripts. So changing
the default init comes with no obligation on maintainers to write
configuration files for the new thing before they're convinced of its
utility.
--
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: Switching to mozilla ESR in stable-security
On 05/30/2013 09:29 PM, Stefano Zacchiroli wrote: On Thu, May 30, 2013 at 03:20:29PM +0200, Didier 'OdyX' Raboud wrote: Which web browsers would remain in stable if we applied this criterion consistently? Although that makes me very sad, if we (collectively) give up packaging browser extensions (hence letting our users rely on third-party repositories to get access to [non-]free binaries) and frozen browsers in stable, then maybe the correct answer to your question is none. And do you think that would be the best outcome for Debian users? FWIW, I don't. I think the compromise that the security team is proposing is much more reasonable than such an alternative. I agree with both Zack and Didier here. Maybe the best way forward is to have backports activated by default (there's already a patch available for that, not sure if it has been applied to d-i yet). Then when installing a desktop (since backports are now fully part of Debian), we could provide browsers from there (maybe as a Recommends:, so it isn't forced into our users ?). Thoughts? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a78c69.40...@debian.org
Re: X.509 and CA certificates for other purposes (i.e. the IGTF)
On 30/05/13 13:19, Bastien ROUCARIES wrote: On Thu, May 30, 2013 at 12:50 PM, Dennis van Dok denni...@nikhef.nl wrote: On 26-05-13 20:02, Bastien ROUCARIES wrote: On Sat, May 25, 2013 at 2:27 PM, Charles Plessy ple...@debian.org wrote: Hi Dennis and everybody, somewhat related to this, I would like to know if there is a package that could host Amazon's EC2 public certificate ? In Ubuntu it is added to the euca2ools package, because a program of this package can use it, but it is not part of the upstream source (which is not Amazon), so I really would prefer to ship the certificate somewhere else. I proposed ca-certificates earlier, but the result was inconclusive. http://bugs.debian.org/573857 Would there be a volunteer to maintain new package from scratch if needed ? Maybe crypto consolidation arround libnss will greatly help here. jessie release goal ? Could you elaborate on what it is you propose exactly, because I could interpret this in many different ways. See also https://fedoraproject.org/wiki/FedoraCryptoConsolidation One of the GSoC project areas that did not go ahead covers this same topic. You can find some of the ideas by reading through the proposal I put up and the responses from three students http://wiki.debian.org/SummerOfCode2013/Projects#Improving_PKI_on_Debian Some of it overlaps with what Fedora are discussing -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a78d41.1070...@pocock.com.au
Re: Switching to mozilla ESR in stable-security
On 30-05-13 19:29, Thomas Goirand wrote: Maybe the best way forward is to have backports activated by default No. If we're going down that route, we might as well give up on doing a stable release. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51a78ffd.9020...@debian.org
