Re: Call for Jessie Release Goals
On Wed, Sep 11, 2013 at 9:17 PM, Jonathan Wiltshire j...@debian.org wrote: Release goals are areas of functionality which developers would like to see as an aim for the next release. They will not hold up the release, but allow the bugs opened for that goal to be of severity 'important'. I am not sure if this qualify as Release goals. So I'd like to ask first what people think of using C++11 in the next release. I know of a couple of C++ libraries which could be compiled with the new gcc compilation option. And I have at least one application (no shared lib) which requires C++11 to compile properly. Since C++11 introduce an ABI incompatibility [*], this may not be a Release Goal but simply a tech-ctte decision. Comments ? -M [*] http://gcc.gnu.org/wiki/Cxx11AbiCompatibility -- 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/CA+7wUswH4jbsGyU87g1e7d7QC=29-tq-q8pdawtuga2dgi1...@mail.gmail.com
Re: Call for Jessie Release Goals
On 18 September 2013 03:42, Mathieu Malaterre ma...@debian.org wrote: On Wed, Sep 11, 2013 at 9:17 PM, Jonathan Wiltshire j...@debian.org wrote: Release goals are areas of functionality which developers would like to see as an aim for the next release. They will not hold up the release, but allow the bugs opened for that goal to be of severity 'important'. I am not sure if this qualify as Release goals. So I'd like to ask first what people think of using C++11 in the next release. I know of a couple of C++ libraries which could be compiled with the new gcc compilation option. And I have at least one application (no shared lib) which requires C++11 to compile properly. Since C++11 introduce an ABI incompatibility [*], this may not be a Release Goal but simply a tech-ctte decision. Comments ? I think I have replied about similar requests before (not sure if it was on these mailing lists). In essence, at the moment we do not have any compiler stdlib with complete and stable ABI for C++11. It is expected that gcc4.8 will break C++11 ABI to further implement the standard. Other non-default compilers also are fully featured at the moment (w.r.t. C++11 compiler features). Thus at the moment we cannot consider switching. One can compile with C++11 enable where one must, but also one then gets to keep the ABI incompatibilities down the road (boost / template libraries especially). While one would want to start using C++11, it's not default at the moment and not feasible to make the default standard level C++11. Regards, Dmitrijs. -- 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/CANBHLUgYHMH6OymwjNc-b2O_ryuv6i_wKqDd=cnvmgzdb07...@mail.gmail.com
Re: Call for Jessie Release Goals
Am 18.09.2013 15:38, schrieb Dmitrijs Ledkovs: On 18 September 2013 03:42, Mathieu Malaterre ma...@debian.org wrote: On Wed, Sep 11, 2013 at 9:17 PM, Jonathan Wiltshire j...@debian.org wrote: Release goals are areas of functionality which developers would like to see as an aim for the next release. They will not hold up the release, but allow the bugs opened for that goal to be of severity 'important'. I am not sure if this qualify as Release goals. So I'd like to ask first what people think of using C++11 in the next release. I know of a couple of C++ libraries which could be compiled with the new gcc compilation option. And I have at least one application (no shared lib) which requires C++11 to compile properly. Since C++11 introduce an ABI incompatibility [*], this may not be a Release Goal but simply a tech-ctte decision. Comments ? I think I have replied about similar requests before (not sure if it was on these mailing lists). In essence, at the moment we do not have any compiler stdlib with complete and stable ABI for C++11. It is expected that gcc4.8 will break C++11 ABI to further implement the standard. Well, GCC 4.8 should not break anything more. Upcoming GCC versions may be another matter. Did somebody try to rebuild the archive in c++11 mode? 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/5239b2c2.8070...@debian.org
Re: jessie release goals
On 2013-05-19 09:17:31 +0200, Jean-Christophe Dubacq wrote: Le 16/05/2013 08:43, Vincent Lefevre a écrit : On 2013-05-15 20:27:09 +0200, Jean-Christophe Dubacq wrote: No. Your server comes unconfigured, you do configure it while the other is still working, and then you stop the service on the first, finish syncing the mailboxes, switch the MX record, and then you can go to rest. This is not possible, as I have only one server (which is sufficient for a personal server). If this is a first configuration, then the mail was not working before anyway. So you are not losing thousands of emails. It this is not, then you are already configured, and debconf will not touch your files. It was a complete reinstallation (not an upgrade). Of course, I could copy the configuration files. But if there were incompatible changes in the new version of postfix, things could break. So, I wanted to restart from clean config files and update them. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130522091835.ga25...@xvii.vinc17.org
Re: blhc and hardening flags (was: Re: jessie release goals)
That reminds me. Is there a way to get blhc to tell me *which* line in a build log makes it think that compiler flags are hidden? I agree that would be really useful https://buildd.debian.org/~brlink/packages/r/remctl.html is reporting that the compiler flags are hidden. So far as I know, this is false, but this package builds Perl, PHP, Python, and Ruby extensions, and it's possible that one of those build systems is misconfigured. But I can't tell from this page which line it's upset about. Usually what I do is to copy the whole page and pass it through the blhc on my local system. In your case I get this message: NONVERBOSE BUILD: compiling remctl.c Your build logs include: make[4]: Entering directory `/build/buildd-remctl_3.4-2-amd64-evcdS_/remctl-3.4/ruby' compiling remctl.c linking shared-object remctl.so make[4]: Leaving directory `/build/buildd-remctl_3.4-2-amd64-evcdS_/remctl-3.4/ruby' Seems like a valid warning to me -- =Do- N.AND -- 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/cann5kou4h4b6o4tqfshetkwb7yvbtkjue-tdndt4lhym1-m...@mail.gmail.com
Re: jessie release goals
Le 16/05/2013 08:43, Vincent Lefevre a écrit : On 2013-05-15 20:27:09 +0200, Jean-Christophe Dubacq wrote: No. Your server comes unconfigured, you do configure it while the other is still working, and then you stop the service on the first, finish syncing the mailboxes, switch the MX record, and then you can go to rest. This is not possible, as I have only one server (which is sufficient for a personal server). If this is a first configuration, then the mail was not working before anyway. So you are not losing thousands of emails. It this is not, then you are already configured, and debconf will not touch your files. Sincerly, -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: jessie release goals
On Sb, 18 mai 13, 14:55:46, Charles Plessy wrote: Le Fri, May 17, 2013 at 08:29:42PM -0600, Bob Proulx a écrit : Andrei POPESCU wrote: Andreas Beckmann wrote: now might be the right time to start a discussion about release goals for jessie. How about setting default umask for users (uid = 1000) to 002? +1. It would be a useful default. See also: http://wiki.debian.org/umask Thanks, I just moved it under Debate. 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: jessie release goals
On 16-05-13 21:27, Clint Byrum wrote: Excerpts from Wouter Verhelst's message of 2013-05-14 03:22:14 -0700: On 13-05-13 05:59, Mark Symonds wrote: Can we keep the distribution simple enough for nearly anyone to understand? No. The goal of Debian is not to be simple. While we should document things as much as possible so that the interested can learn how things work, in no case should we ever avoid doing the technically sound because it is difficult to understand. One could argue the opposite: making things hard to understand is technically unsound because it compromises the ability of engineers to understand and change or fix it. There is a very wide gap between making things hard to understand and making things simple enough so that nearly anyone can understand it... I believe that the latter is at least as bad an idea as the former. -- 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/519724d6.80...@debian.org
Re: jessie release goals
On 2013-05-18 14:55:46 +0900, Charles Plessy wrote: http://wiki.debian.org/umask It says: An umask of 022 gives write permission to the other group members. Is it true? -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130518083354.ga12...@xvii.vinc17.org
Re: jessie release goals
On Sb, 18 mai 13, 10:33:54, Vincent Lefevre wrote: On 2013-05-18 14:55:46 +0900, Charles Plessy wrote: http://wiki.debian.org/umask It says: An umask of 022 gives write permission to the other group members. Is it true? Probably a typo, fixed. 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: jessie release goals
On Tue, 14 May 2013 17:37:59 +0100, Wookey woo...@wookware.org wrote: +++ Stephen Kitt [2013-05-13 19:26 +0200]: Yes, but that's not the problem. Take the premise that the target directory structure is as described above, so most library development packages ship as many headers as possible in /usr/include. For now we'll assume all mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32; but to use mingw-targeted libraries other than mingw-w64-...-dev (libgtk for example), the mingw toolchain needs to look in /usr/include as well. This is all fine as long as libc6-dev is not installed (say perhaps with sbuild and cross-build-essential). But in a typical work environment, libc6-dev will be installed, and because we'll always be cross-compiling on the buildds, packages which need to build stuff for the host to run during the build (wine-gecko does this) need build-essential too, so libc6-dev headers end up in /usr/include and are picked up by the mingw toolchain. Thank you for explaining this. I now understand your issue. It is helpful to have an example of why a full-split might have advantages over an 'only arch-dependent' split. Or at least that we need to be careful about what the definition of 'arch-dependent' is, if we want to include windows ABIs, or uclibc ABIs (I think those two cases may well amount to the same problem). Can anyone from BSD camp tell us whether having glibc-dev headers installed in a common dir would break cross-building for them too? Simon has expanded on this helpfully already: 'glibc is somewhat special as part of the ABI' (remembering that multiarch maps to ABIs). Right, and thank you Simon for explaining things more clearly than I could! It's good to know about this before the design is set in stone, so this conversation is timely. What I'm not sure about is whether the multiarch-cross design is seriously broken or if it's just a matter of packaging libc-dev correctly to allow for non-glibc platforms. Multiarch has thus far largely been thought of in terms of platforms you can also install Debian to as well as build for. But multiarch-cross ought to be a good fit for crossing to other platforms (within reason) too. So we should certainly consider whether we can sensibly accomodate that or not. I'm not quite sure how best to decide that. Some people need to try some stuff and report back, I suspect. Quite likely! I should probably just rebuild the mingw toolchain using multiarch paths and see what breaks ;-). Would simply moving all the libc headers to /usr/include/$multiarch fix mingw builds? How many other libraries are similarly affected? I think as far as libc is concerned, moving the headers away should be enough. Off the top of my head the only packages I can see causing trouble is linux-libc-dev, and kernel-specific packages like it (so basically anything which is linux-any rather than any, or kfreebsd-specific or hurd-specific, with files in /usr/include). In a perfect world nothing else should: if a header file is in /usr/include (or a well-known subdirectory), the corresponding library should be available on all Debian architectures and partial architectures. Certainly from the point of view of Debian packages that should be enough: it's the usual problem of packaging reverse-dependencies, albeit slightly extended (since a build-dependency for a host-based portion of a cross-build may confuse the target-specific portions of the build). For end-users it's not quite so simple, and if we want Debian to be a nice platform for cross-building we may need to be stricter (and I realise that's a big if anyway, and cross-builders should know what they're doing well enough to cope with the deficiencies here). The easy solution to deal with partial architectures' limitations is to move everything out of /usr/include, the hard solution is to make sure as many libraries as possible are available for the partial architectures... It all boils down to what the baseline is for all Debian architectures, and hence what is common across all architectures. As Simon points out stuff which uses pkg-config should be safe enough. Likewise configure scripts which check the library as well as the header files. Regards, Stephen signature.asc Description: PGP signature
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On Fri, 17 May 2013 13:42:30 +0200, Holger Levsen hol...@layer-acht.org wrote: On Freitag, 17. Mai 2013, Marc Haber wrote: We're going to have a TC decision or a GR about this anyway. why do you think so? Because I think that a decision of this magnitude should not be taken by a single developer, not even by M'd. 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/e1udpo2-0006gy...@swivel.zugschlus.de
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On Mon, 13 May 2013 02:31:02 +0200, m...@linux.it (Marco d'Itri) wrote: Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev depend on either upstart or systemd. I would rather not be the one who will choose which one of them, so I hope that we will get to a consensus about this. We're going to have a TC decision or a GR about this anyway. 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/e1udesn-0006mx...@swivel.zugschlus.de
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
Hi Marc, On Freitag, 17. Mai 2013, Marc Haber wrote: We're going to have a TC decision or a GR about this anyway. why do you think so? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: /bin/sh (was Re: jessie release goals)
On 2013-05-07 14:23:47 +, Thorsten Glaser wrote: Shells suitable for /bin/sh are currently bash, dash, mksh. I forgot about that (partly because of workarounds), but due to the SIGINT problem, I think that *currently*, among these 3 shells, bash is the most suitable one, and mksh is a bit better than dash. Indeed /bin/sh is used by system(), meaning that in particular, it is often executed to run interactive programs, some of which trapping SIGINT. If the shell doesn't implement WCE[*], one may get spurious failures (e.g. when Ctrl-G is typed in some versions of Emacs, Ctrl-C in gdb, etc.). [*] http://www.cons.org/cracauer/sigint.html AFAIK, only bash and ksh93 implement WCE. And mksh has an optimization so than when the mksh -c string consists of only one command, the problem doesn't occur (because in such a case, the shell does not fork, but exec's the command, so that the shell is no longer involved when the signal is sent). I believe posh can be made suitable with a bit of hacking it (e.g. adding fixes from mksh) and coreutils moving /usr/bin/printf to /bin/printf (best way out of the Md issue, really). But posh doesn't implement WCE either. My bug reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683671 for dash http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708633 for posh http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708634 for mksh -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130517132350.ga10...@ypig.lip.ens-lyon.fr
Re: jessie release goals
Andrei POPESCU wrote: Andreas Beckmann wrote: now might be the right time to start a discussion about release goals for jessie. How about setting default umask for users (uid = 1000) to 002? +1. It would be a useful default. Bob signature.asc Description: Digital signature
Re: jessie release goals
Le Fri, May 17, 2013 at 08:29:42PM -0600, Bob Proulx a écrit : Andrei POPESCU wrote: Andreas Beckmann wrote: now might be the right time to start a discussion about release goals for jessie. How about setting default umask for users (uid = 1000) to 002? +1. It would be a useful default. See also: http://wiki.debian.org/umask http://wiki.debian.org/Debate Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130518055546.gg17...@falafel.plessy.net
Re: jessie release goals
On Sun, May 12, 2013 at 05:06:26PM +0200, Matthias Klose wrote: Am 12.05.2013 16:18, schrieb Daniel Schepler: Maybe we could have a release goal of dropping as many lib32* and lib64* packages as possible in favor of multi-arch. (And also as many package dependencies on libc6-[i386|amd64] as possible, which would in addition mean limiting some packages to arch:i386 if they currently provide a fake arch:amd64 package with an i386 binary.) Of course, to completely get rid of everything including libc6-* and lib32gcc1, etc., we'd need special configuration on the buildds to continue building gcc with multilib support; and the GCC maintainer has expressed resistance to being that radical even if we could get this buildd support. Well, GCC should keep building with a sane amount of effort. And that currently means not depending on a foreign architecture on the buildds. So before this can happen: - get dpkg ready to accept b-d's on foreign architectures. - get GCC ready to search for gcc_lib_dir for foreign multilibs. and get this submitted upstream before getting it to the Debian packages. - find a solution for multilibs which are not fully supported architectures, but only partial ports, or ports maintained outside the archive. - get the buildd infrastructure ready. - find a solution that GCC's b-d's may not be installable anymore with the current approach to binNMUs. It is wrong to drop the current multilib support before these are implemented and in place. So what do you commit to work on? I don't think that there are that many packages where you can or should drop multilib support. So it would be wrong to drop multilib support for zlib (GCC, gdb), ncurses, readline, expat (gdb) now. And there are not that many more packages providing multilib support. Matthias Is multilib realy the way to keep doing things? Gcc supports cross-compiling and I see multilib as just some hack to cross-compile for a foreign arch that you can also execute natively on the target. So why not in the future promote using i486-linux-gnu-gcc instead of gcc -m32? Yes, I know there is still some way to go to get cross-compiling working flawlessly with multiarch. But that was always planed as second step and with jessie we can do that step. So maybe after jessie multilib could be dropped and then the problem of uninstallable foreign B-Ds wouldn't occur. Gcc build times would also improve substancialy. MfG Goswin PS: gcc-defaults could provide a gcc wrapper that picks the right triplet-gcc-x.y depending on -mXX for backward compatibility. -- 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/20130516095710.GB2181@frosties
Re: jessie release goals
On Sun, May 12, 2013 at 12:17:06PM +0200, Vincent Lefevre wrote: On 2013-05-07 23:53:07 +0800, Thomas Goirand wrote: Now please, do the same reasoning with some other services, like Apache, pure-ftpd, or bind, and explain to me why you would like to have these installed, but not working. I agree for these services (though Apache is useless after just being installed, as one just has a dummy web page). But not for I've installed apache a bunch of times with the default configuration. After that the webpages are placed in /var/www and everything works. So I wouldn't say a apache default installation is useless. It works just fine and if the default config is not what one intends to use then it does no harm between being installed and being fully configured. At least I don't consider serving that single it works page as harmfull. MfG Goswin -- 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/20130516100729.GC2181@frosties
Re: jessie release goals
On Lu, 06 mai 13, 14:49:57, Andreas Beckmann wrote: Hi, now might be the right time to start a discussion about release goals for jessie. How about setting default umask for users (uid = 1000) to 002? 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: jessie release goals
On Wed, May 15, 2013 at 09:43:02PM +0200, Christoph Biedl wrote: Christoph Anton Mitterer wrote... 2) No more packages that bypass the package management system and secure apt: a) There are still several (typically non-free) packages which download stuff from the web, install or at least un-tar it somwhere without checking any integrity information that would be hardcoded in that package. b) Another problem are IMHO plugins like Firefox extensions, kinda bypassing APT. I think at least those that are installed via a package, shouldn't be upgradable/overwritable anymore with online versions. I'd like to enhance that topic to the question under which circumstances a package is allowed to phone home, i.e. to contact a service provided by upstream without the consent of the user. For the records, I wouldn't mind much if the rule is never. Still an answer might be not as easy as it seems, a few situations: * Automatic update checks don't make sense, mostly they confuse users. * As an example, nagios3 upstream embedded several requests to the nagios homepage on the start page of any local installation. That I consider both annoying and a privacy breach, so I patched that away locally. But perhaps such behaviour should be banned entirely. * On the other hand, there are packages that do need frequent updates, virus scanners to start with, also ad blockers. Not sure whether these should be granted an exception. If not, somebody would have to take the task to provide these updates in an APT way. Just sharing a few thoughts on that ... Christoph I wouldn't mind never. An absolute requirement I think is a don't do it again option (for the user). For example every time I start eric it tells me there is an update. I know there is an update. It told me so the last 1000 times I started it. And I still don't want to break my stable system. I also wouldn't mind a debconf question in cases where the apt way is not practicable but security can still be maintained. Which would be for the *-installer packages that download the actual thing from the internet. I would rather not have them but sometimes they are unavoidable. Phoning home at runtime without explicit admin/user permission is never OK though. MfG Goswin -- 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/20130516101829.GD2181@frosties
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 05:29:45PM +0200, Sven Joachim wrote: On 2013-05-11 11:22 +0200, Goswin von Brederlow wrote: While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. I think that dash could probably stop diverting /bin/sh, now that bash no longer ships it (as of version 4.2-1). That would make it possible to locally divert /bin/sh for those who want it (#538822, #540512). Double that for multiarch on amd64/i386 because there is bash:i386 and bash:amd64 that both work just fine as /bin/sh. Trying to install a foreign bash or dash fails horribly though with the current diversion hack. Huh? No it doesn't, dpkg handles this just fine (apt doesn't because it does not support crossgrades, but that is another story). Make sure you have dpkg = 1.16.2, though. When I checked that last the mainatienr scripts would fail horribly because you can't have a thrid package doing a diversion. Dpkg never was a problem in itself. Proposed solution: - New virtual package system-shell with something essential depending on it (base-files?) Would probably need pre-depends so that system-shell cannot be removed temporarily (similar situation as with awk). Yes, verry similar. I actualy would like the same solution for awk to fix the problem that during bootstrap there is no awk link. - bash, dash pre-depend on system-shell for the transition - new packages system-shell-name Provides, Replaces, Conflicts: system-shell contains /bin/sh - /bin/name symlink None of system-shell-* would be essential but through the dependency of something essential at least one would always be installed (pseudo-essential). One of them (system-shell-dash) should have a higher priority than the rest to be singled out as the default and the essential package would depend system-shell-dash | system-shell. Choosing /bin/sh is then simply done by installing the right package and dpkg does the change atomically. Only if the packages declare Conflicts/Replaces on every real provider of system-shell, and with apt you lose outright because it insists on removing the conflicting package(s) first. We worked out the system during the second last Debconf, so nearly two years ago. I would have to look up my notes at home but that wasn't a problem. The virtual package works just fine as placeholder for all real packages since they all provide it. And about the removing the conflicting package(s) first I'm not sure if that wasn't an issue because system-shell is a virtual package or if the solution was to use Break/Replaces. But it worked in the right order with a set of dummy packages we made to test the solution. No messing around in pre/postinst/rm scripts or race conditions where the link might disapear for a while. No artificial limit on how many system-shell-* packages there could be. I'm afraid your plan as outlined is not going to work. Cheers, Sven This was just a loose summary of the general idea from memory. I might not have expressed all the finer details (correctly) but the solution we came up with worked. The details also include a bunch of tricky hacks to reassign the diversion during the initial upgrade so that at no time the /bin/sh link disapears. That was actualy the hardest part to figure out. MfG Goswin -- 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/20130516103544.GE2181@frosties
Re: /bin/sh (was Re: jessie release goals)
On Sun, May 12, 2013 at 02:40:39AM +0100, Wookey wrote: +++ Steve Langasek [2013-05-11 09:33 -0700]: On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote: While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. See also: Linux is not about choice. All this added complexity to provide users a choice about something that doesn't matter undermines the robustness of the base system. Please stop. Yes, the diversion hack should be superseded by a single, static symlink belonging to the dash package, and the rest of this pointless complexity should be jettisoned. I'm very keen to lose the diversion hack. It causes pain for cross-debootstrapping, especially on embedded images. If /bin/sh is no longer a diversion by dash/bash then that frees up the use of diversions for the admin or other packages. So that works too. Someone would need to make a case for replacing dash as /bin/sh. What do we get for enabling /bin/mksh fill that role too, for example? If it really is just better then why not just swap from dash to mksh and everyone can benefit? So lets say I'm convinced mksh is the better /bin/sh for everyone. How do I test that it actualy works at all? How do I get other people to test? Currenlty there is no way to say: Here, try installing this packages and report if anything breaks. Swappable system shells is a nice idea, but Steve is right that it's a critical thing that really does need to work so there has to be some real gain from futzing with it. If it can be done cleanly then great. If not then lets see if we can't just pick one (almost) everyone can live with. Wookey Problem is Debian picked *2* and both created a diversion on /bin/sh and play ping-pong with that. At the time the system-shell-* solution was considered there was no way for e.g. bash to not ship /bin/sh. It seems now that has changed so yeah, maybe we can go to just simply a plain /bin/sh. Then people that want a different /bin/sh, and there are those, are free to use diversions again. MfG Goswin -- 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/20130516104405.GF2181@frosties
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 08:44:30PM +0100, Roger Leigh wrote: On Sat, May 11, 2013 at 08:52:29PM +0200, Josselin Mouette wrote: Being able to choose between two entirely different desktop environments, with different user experiences, is a good thing. Being able to choose between two /bin/sh shells or two /sbin/init implementations is not. The shell I can agree with. It is required to provide a POSIX shell, so as long as it is fully functional and performs well, just picking one and sticking with it is absolutely fine. You are disagreeing with yourself, kind of. If there is only exactly one system shell and everything is tuned to work with only that one system shell then the system will no be for a POSIX shell but for THAT shell. The history with bash as /bin/sh has proven that. The only realistic way to keep scripts compatible with a POSIX shell is to have multiple shells that have POSIX as common base. So be truthfull and say you are fine with picking XYZ as system shell and have everything rely on sh being XYZ. I also disagree with the assumption that being able to choose a system shell is a bad thing. I actualy find it kind of important. By picking dash as /bin/sh (and it isn't going to go back to bash, right?) you are forcing dash to be installed. Also bash practically has to be installed simply because dash as interactive shell for users sucks. For a Debian derivativ aimed at some embedded platform it might be far better to simply have one shell that works for both /bin/sh and interactive user shells. This would be greatly simplified by having more than one choice for the system shell in Debian. Support for other shells would be better tested and easier to maintain over time. MfG Goswin -- 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/20130516110324.GG2181@frosties
Re: /bin/sh (was Re: jessie release goals)
On Sun, May 12, 2013 at 02:40:39AM +0100, Wookey wrote: +++ Steve Langasek [2013-05-11 09:33 -0700]: On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote: While that might be of some interest the real goal of the change was to be able to have more than *2* packages provide /bin/sh. Currently, due to the totaly screwed up way this is done, only dash or bash can be /bin/sh. This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. See also: Linux is not about choice. All this added complexity to provide users a choice about something that doesn't matter undermines the robustness of the base system. Please stop. Yes, the diversion hack should be superseded by a single, static symlink belonging to the dash package, and the rest of this pointless complexity should be jettisoned. I'm very keen to lose the diversion hack. It causes pain for cross-debootstrapping, especially on embedded images. Someone would need to make a case for replacing dash as /bin/sh. What do we get for enabling /bin/mksh fill that role too, for example? If it really is just better then why not just swap from dash to mksh and everyone can benefit? Nobody wan't to mess with the default (yet). Swappable system shells is a nice idea, but Steve is right that it's a critical thing that really does need to work so there has to be some real gain from futzing with it. If it can be done cleanly then great. If not then lets see if we can't just pick one (almost) everyone can live with. Wookey The current diversion hack is insane. That certainly needs to go. I hope everyone can agree on that. The system-shell idea is a way out of that without loosing the choice what /bin/sh shall be. Currently that choice is between bash and dash. Picking just dash as /bin/sh would be an (acceptable) regression since it would open back the possibility to diver the shell locally (or by other packages). I like the system-shell idea better because it is cleaner (less likely to break) than diverting /bin/sh (both locally and by packages). Note: it would also allow changing the shell (in debian or in derivatives) in the future without running into the same diversion problems again. MfG Goswin -- 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/20130516112005.GI2181@frosties
Re: /bin/sh (was Re: jessie release goals)
Hi Thorsten On 11-05-13 20:26, Thorsten Glaser wrote: Steve Langasek vorlon at debian.org writes: This is not a sensible goal. Choice of /bin/sh should *not* be the goal, the goal should be to get a good, fast, minimal, policy-compliant /bin/sh for *everyone*. Sure. We just disagree which one that is. See also: Linux is not about choice. Debian is not just about Linux. While a choice of $SHELL is useful for a user and something we should support (through things like chsh), I fail to see how a choice of /bin/sh is extremely critical. I also fail to see how the above statement factors in this entire discussion. Oh, sorry, I forgot, you work for Canonical (which totally explains some of your writings in the other eMail too, which I’m not going to comment on). Of course, for *buntu people it’s not about choice. This is an ad-hominem attack, which has no place on -devel. Please take that elsewhere (/dev/null, preferably). [...] In Debian, Developers are also users, and it can only be the UNIVERSAL operating system when there is choice. Wrong. Yes, the diversion hack should be superseded by a single, static symlink belonging to the dash package Why dash? It’s clearly inferiour, buggy and not taken care of well. Because at the time this decision was taken, dash was the only available candidate. [...] choose their system shell. I don’t even care about the default, I’d be happy were it mksh or mksh-static of course, but I don’t. And I’ve successfully run both Debian and Kubuntu with mksh as system shell.) All else being equal, you're right that a choice of shell for /bin/sh is a good thing, and you're also right that changing /bin/sh to some other implementation usually doesn't bring with it any negative effects once it's done. In fact, policy requires that this is possible. However, all else is *not* equal. Contrary to the awk situation, large parts of the Debian packaging format rely on /bin/sh functionalty, and will break (and leave the system in an inconsistent state) if /bin/sh is nonexistent at the wrong moment. I'm not saying it's impossible to implement this the right way, but doing so will cause a lot of pain and a lot of problems before we get there. That is precisely why the /bin/sh change was implemented with a diversion rather than an alternative; the latter is much more fragile and brings with it a much larger risk of screwing the user over and leaving them with a system that won't boot, and can't easily be fixed by just doing dpkg --configure -a. This is a *bad* thing. For an issue that few of our users care about, it is questionable to risk so much. In addition, people who know enough about the issue to want to switch /bin/sh away from dash and to another implementation usually also are knowledgeable enough to just call the ln -sf command manually. We might wish to document the circumstances under which this is a safe thing to do (and why the alternatives system isn't used), but that's about it. No, it is NOT about choice. It is about providing a high quality, free operating system to our users. This ridiculous complexity in /bin/sh But your users may have a more broad horizon than you, as Canonical employee, can imagine. Having met Steve in person and talked with him on multiple occasions, I can assure you that there are few people in Debian who have as broad an understanding of the needs of the Debian (and by extension, Free Software) community and its users. This remark is insulting and not based in fact. Please retract it. -- 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/5194c192.60...@debian.org
Re: /bin/sh (was Re: jessie release goals)
On 15-05-13 17:39, Thorsten Glaser wrote: As for your requests of data: I do not provide them. As I said above, I’m pushing for freedom of choice, not switching the default; of course I’d be happy with the latter, even more so actually, but it must be a thing not driven by me; I see. In that case, might I suggest a change of strategy? I understand your desire to not let your own biases get in the way of technically sound decisions (and that's admirable), but in this case, I think it's not the right thing to do. Providing freedom of choice for the system shell isn't something that's wanted by a lot of our users, and it isn't something you'll be likely to get many people to buy in to. On the other hand, if you manage to provide sound technical arguments as to why switching the system shell away from dash and to mksh might be a good idea, I don't see why we would reject it. We'd prefer to avoid having to do yet another switch, so the arguments would have to be fairly compelling; but if they are, hey, more power to you. If you're not really about choice but are about promoting mksh, then that's really what you'd like, too. [...] Using the diversion mechanism to change /bin/sh is highly risky and was never supported. Actually, dash uses a diversion too, so it was supported pretty well. Well, no, not really; it causes many problems... -- 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/5194c8ca.6090...@debian.org
Re: jessie release goals
On 13-05-13 06:16, Paul Wise wrote: On Mon, May 13, 2013 at 1:01 AM, Philip Hands wrote: I don't know about you, but I find it quite reassuring to be able to confirm that the first half of an install is going pretty well when I get to see the useless dummy page from Apache. I'd imagine someone installing their first web server would also find that reassuring (I still remember grinning broadly when first seeing it). If it were also their first Debian server, then forcing them to find an extra ON switch after installing apache just seems like an extra and unneeded barrier. I think it would be better for apache to ask via debconf which vhosts you want to setup and which directories/configs/etc they should use. No. Absolutely not. Configuring a daemon through debconf is useful only for the most simple of daemons. I did it for nbd-server, and am starting to regret that decision. For apache, you'll need to fine-tune the configuration in almost every case, which will then cause annoying UCF prompts at every upgrade. The should it run on install? question is a matter of taste and judgement, which is why it is not the case with rsyncd. We have debconf to resolve matters of taste. There is such a thing as overuse of debconf. -- 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/5194cf04.6030...@debian.org
Re: jessie release goals
Thomas Goirand z...@debian.org writes: Now please, do the same reasoning with some other services, like Apache, pure-ftpd, or bind, and explain to me why you would like to have these installed, but not working. As a developer I have often found use for having Apache installed, just so I can start it as a user with an ad hoc configuration. This is useful for testing the code I work on which can be either apache modules or mod_perl applications. For the same reason I have nginx installed, to be able to perform experiments with how nginx needs to be configured to perform different tasks. I don't need any of these packages to start a service listening on port 80 serving some default set of pages. As I don't have any other webserver installed it is not a problem as such that one of them ends up listening on port 80, but I have always found it a bit bothersome that I just get a random deamon listening on port 80. It have never bothered me enough to complain, but if I have been using nginx on port 80 and stuff then suddenly broke after installing apache (and rebooting) I might have been quite a bit irritated. I am not complaining, just describing a scenario for having Apache installed without wanting to use it as the system webserver. I have never experience the same use cases for bind nor pure-ftpd. //Makholm -- 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/87ehd7cfv2@vps1.hacking.dk
Re: /bin/sh (was Re: jessie release goals)
On Wed, May 15, 2013 at 03:39:54PM +, Thorsten Glaser wrote: As for your requests of data: I do not provide them. As I said above, I???m pushing for freedom of choice, not switching the default; of course I???d be happy with the latter, even more so actually, but it must be a thing not driven by me; if there???s enough other people (especially DDs) interested in actually doing that it has potential to get taken a bit seriously at all; if I???m involved, all bets are off (especially now, I guess). There are two issues you mix here: 1) Using mksh as /bin/sh by default. I see no issue with you providing the data. If mksh provides significant benefits, I guess others will jump on the boat as well. Just make sure to include the method of measurement, so others can reproduce the results. If all else fails, your data probably points out some weaknesses in dash, that can result in a better dash. 2) Making /bin/sh configurable. As I and a number of others have explained already, this choice comes at a cost. I'm inclined to say that this cost is even higher than just changing /bin/sh globally. So for this you need even better arguments, since it is hard enough to clean the current mess. The approach to just do the work is indeed a good argument. If the bash maintainer has indeed remained silent on your present work, you might need to take other measures to fix this rc bug in dash. For instance the ctte can be asked for advice (as opposed to overruling a maintainer). Thanks for your work here, I have long dropped this ball after running into silence on other involved parties. Using the diversion mechanism to change /bin/sh is highly risky and was never supported. Actually, dash uses a diversion too, so it was supported pretty well. I was not precise enough here. With diversion mechanism I meant local (i.e. admin controlled) diversion. This is broken precisely because dash is currently (ab)using diversions to change /bin/sh. It was never supported in the sense, that we left the corresponding bug open all the time and changed the release notes instead. So we basically meant the same thing. Helmut -- 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/20130516110528.ga14...@alf.mars
Re: jessie release goals
On 2013-05-15 20:27:09 +0200, Jean-Christophe Dubacq wrote: No. Your server comes unconfigured, you do configure it while the other is still working, and then you stop the service on the first, finish syncing the mailboxes, switch the MX record, and then you can go to rest. This is not possible, as I have only one server (which is sufficient for a personal server). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130516064300.ga19...@ioooi.vinc17.net
Re: jessie release goals
Excerpts from Wouter Verhelst's message of 2013-05-14 03:22:14 -0700: On 13-05-13 05:59, Mark Symonds wrote: Can we keep the distribution simple enough for nearly anyone to understand? No. The goal of Debian is not to be simple. While we should document things as much as possible so that the interested can learn how things work, in no case should we ever avoid doing the technically sound because it is difficult to understand. One could argue the opposite: making things hard to understand is technically unsound because it compromises the ability of engineers to understand and change or fix it. -- 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/1368732264-sup-...@fewbar.com
Re: jessie release goals
Christoph Biedl debian.a...@manchmal.in-ulm.de schrieb: Another thing: Hardening already has been a release goal but there still are packages around without. Agreed. I made a concentrated effort for Wheezy by submitting lots of patches for crucial packages and the general adoption among maintainers is increasing. Also, Simon Ruderich's blhc tool has been very useful and hardening checks are now also part of lintian. Everyone who wants to drive the adoption further should simply submit patches to the BTS and user-tag them, see [1] Cheers, Moritz [1] http://lists.debian.org/debian-devel-announce/2012/02/msg00016.html -- 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/slrnkpad13.4ph@inutil.org
blhc and hardening flags (was: Re: jessie release goals)
Moritz Mühlenhoff j...@inutil.org writes: Agreed. I made a concentrated effort for Wheezy by submitting lots of patches for crucial packages and the general adoption among maintainers is increasing. Also, Simon Ruderich's blhc tool has been very useful and hardening checks are now also part of lintian. That reminds me. Is there a way to get blhc to tell me *which* line in a build log makes it think that compiler flags are hidden? https://buildd.debian.org/~brlink/packages/r/remctl.html is reporting that the compiler flags are hidden. So far as I know, this is false, but this package builds Perl, PHP, Python, and Ruby extensions, and it's possible that one of those build systems is misconfigured. But I can't tell from this page which line it's upset about. -- 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/87k3mywv99.fsf...@windlord.stanford.edu
Re: /bin/sh (was Re: jessie release goals)
On Tue, May 7, 2013 at 4:23 PM, Thorsten Glaser t...@debian.org wrote: Andreas Beckmann anbe at debian.org writes: now might be the right time to start a discussion about release goals for jessie. Here are some points that come into my mind right now (and * Resolve that /bin/sh issue (see the open RC bugs against dash which just got ignored for a stable release for the *second* time) e.g. by transitioning to Goswin’s system-shell-foo package, and then request (eventually require) packages to declare any dependencies on shell interpreters other than /bin/sh explicitly (begin by changing lintian to not warn about these as bash still and dash newly is Essential, then change Policy(IIRC) to request these dependencies to be explicit), so that jessie+2, if not jessie+1, can be run without dash and bash installed, which would mean encouraging maintainers of “core” tools to not depend on them for their maintainer scripts, init scripts, etc. (debootstrap would probably need to be adjusted to cope but we’ve got two releases time for that). Shells suitable for /bin/sh are currently bash, dash, mksh. I believe posh can be made suitable with a bit of hacking it (e.g. adding fixes from mksh) and coreutils moving /usr/bin/printf to /bin/printf (best way out of the Md issue, really). I believe ksh93 can be made suitably by making 'alias local=typeset' implicit like pdksh did. Solaris 11, OpenSolaris and Illumos use ksh93 as /bin/sh, /usr/bin/sh and /usr/bin/ksh, partially for the massive performance gain over the old Bourne shell and the busybox-like shell builtins (for example ksh93v- comes, among others, with basename cat chgrp chmod chown cksum cmp comm cp cut date dirname egrep expr fds fmt fgrep fold getconf grep head id join ln logname md5sum mkdir mkfifo mktemp mv paste pathchk printf rev rm rmdir stty sum sync tail tee tty uname uniq wc) as builtin, all conforming to the POSIX/SUSv4 standards (tested and certified!!), SystemV extensions and all extensions which are implemented by both GNU and BSD the same way if they do not violate POSIX/SUSv4 in the first place. Josh -- 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/caeemktpgvtozhjxjsosyyhhwsa6-pxxufnvqmg5h3mwcw1x...@mail.gmail.com
Re: /bin/sh (was Re: jessie release goals)
]] brian m. carlson On Wed, May 15, 2013 at 02:12:10AM +0200, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. http://www.freedesktop.org/software/systemd/man/journald.conf.html Storage=none Silly me. I expected that if I installed systemd, that the appropriate man pages would be shipped with the package: As you might have noticed, we are not yet shipping the latest upstream version. Upstream has added more documentation in the meantime. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txm4danb@qurzaw.varnish-software.com
Re: /bin/sh (was Re: jessie release goals)
]] brian m. carlson On Wed, May 15, 2013 at 02:29:40AM +0200, John Paul Adrian Glaubitz wrote: On 05/15/2013 02:16 AM, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in The format may be binary, but it certainly is not proprietary [1] I really can't believe people are still coming up with that non-sense. Maybe because I read it on LWN (http://lwn.net/Articles/468381/): All complaints about UUIDs were quickly overshadowed by another issue once the full proposal was posted: one might charitably say that there is not, yet, a consensus around the proposed new logfile format. In a sense, that is unsurprising, since that format is deliberately undocumented and explicitly subject to change at any time. You'll pardon me if I believe that LWN is a reputable source for information. This was approximately correct a year and a half ago. It's not correct today, partly because people did want the format to be documented and for it to settle down. I have no idea why people assume that a binary format means it can only be processed with a special, proprietary tool. Binary simply means what it means, binary and not text which means it's a more stream-lined and machine-readable format as opposed to a text format with no formatting at all. It means that it works completely differently from every existing Unix log parser on the planet. syslog is hardly no formatting at all. syslog and other log files isn't structured particularly well. And, when it comes to processing, binary data is actually *easier* to process. Everyone who has ever written a text parser themselves will agree. I have written several, and I still prefer plain text. I want to use the same tools to parse my logs that I have used for years, like logcheck. Text files is the Unix way. Nothing stops you from having plain text log files too while using the systemd journal. We're not planning on taking the old/regular-format files away. Adding the journal means you get more information, you get better searchability and so on. If you don't want that, turn it off. I want it, since it'll make it easier for me to manage my systems. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ppwsdahz@qurzaw.varnish-software.com
Re: /bin/sh (was Re: jessie release goals)
On Tue, May 14, 2013 at 08:59:57AM +, Thorsten Glaser wrote: Helmut Grohne helmut at subdivi.de writes: What are the benefits of using shells other than dash for /bin/sh? (as Why does dash get special treatment, anyway? It was ???suddenly??? in Debian after having been used in Ubuntu, but??? there never was an evaluation of shells. dash gets special treatment cause it is /bin/sh now. And that happened because at the time of evaluation it was deemed significantly better than bash. Which leads us to the real question: I still believe the codebase of mksh is better (modulo issues introduced due to the active development), but I???m happy with freedom to choose one???s own system shell??? Can you quantify those benefits of using mksh? To that end I propose a few questions, whose answers may help in this discussion. What issues of dash does mksh solve? How many users are affected? Is there a benefit in performance? How large is the margin? (asides from the two things you mentioned) From what you said I count your argument as a belief argument, because it came without data. Sorry. ??? or provide an mksh-static binary package. Which could also be used in initrd. Having the same shell for /bin/sh and the initrd actually is something that can reduce complexity. Did you talk to the initramfs maintainers about this idea? (Reference?) Most arguments and weighting of benefits and costs was already done by Russ Allbery and Steve Langasek, but one thing was not quite right: Using the diversion mechanism to change /bin/sh is highly risky and was never supported. Even if Debian only supports running dash (or bash) as /bin/sh and we ignore problems from broken scripts, there still is the breakage resulting from the diversion itself. As far as I can tell it still breaks dash upgrades in all cases. So even the ambitious user running mksh as /bin/sh and reporting patches for scripts using dashisms (I never imagined using that word), would be screwed with the next upgrade. From my point of view a change in handling /bin/sh is highly desirable precisely now, because we all know that the current way is broken and it was that way for two releases already. Fixing it will cause other problems (unless all involved parties are geniuses), so fixing it early in the release cycle is important. As far as I can tell from the huge bug log partial fixes are already in place and patches are available for the remainders[1]. IMHO go ahead an break sid now? Waiting longer means never fixing it or dragging it into the next freeze. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538822#289 Helmut -- 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/20130515065550.ga12...@alf.mars
Re: /bin/sh (was Re: jessie release goals)
Le mardi 14 mai 2013 à 23:26 +, brian m. carlson a écrit : For better or for worse, sysvinit provides a lot of modularity. systemd provides none of that modularity Maybe you should read a bit about systemd before saying such nonsense. The real-world systemd (not the imaginary software you keep criticizing) is much *more* modular than sysvinit. -- .''`. 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/1368603484.23162.43.camel@pi0307572
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 06:26:40PM +, Thorsten Glaser wrote: Oh, sorry, I forgot, you work for Canonical (which totally explains some of your writings in the other eMail too, which I’m not going to comment on). Of course, for *buntu people it’s not about choice. I think you are totally out of order, here. You could equally be criticised of having your judgement clouded by your involvement with MirOS. That would be just as absurd. Steve has been contributing to Debian much longer than you, or I have, or Ubuntu has existed. -- 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/20130515091755.GC22791@debian
Re: jessie release goals
On 2013-05-15 01:00:37 +0800, Thomas Goirand wrote: On 05/13/2013 07:08 PM, Vincent Lefevre wrote: On 2013-05-07 23:54:36 +0800, Thomas Goirand wrote: On 05/07/2013 04:00 AM, Vincent Lefevre wrote: This can be fine for some daemons/servers. For instance, for a web server, displaying a default web page is harmless. But what about a mail server? Any default config would probably lead to loss of mail if things like virtual alias domains are used. If you set your MX pointer before setting-up your mail server, then it's your fault if you loose some mails, and not at all the fault of the way postfix (for example) is packaged. In one case, this was after a full reinstallation of the server (not Debian, but the problem would be the same). I didn't have the choice. This is, IMO, a very special case. And removing the MX pointer several hours before the reinstallation would also have resulted in loss of mail. Why do you think so? Normally, a mail server can be down for up to a day, without any lost of mail. Here this is more than a mail server being down. It is a domain without a MX; doesn't this mean a direct reject? Actually removing the MX pointer wouldn't be OK, as the client may look at the A record instead, which can't be removed without temporarily affecting other services. So, I'm not sure what should be done (except iptables...). The cleanest solution, IMHO, would have been to use iptables to prevent SMTP connections before installing postfix, but for someone who doesn't know iptables yet, that's more complex than having the control on whether the daemon is started or not at install time. I don't think iptables is more complex than postfix I meant that instead of learning one software, one would have to learn several ones. (in fact, to some degree, it might even be more simple, considering how complex postfix is). I do expect any administrator handling postfix to also know iptables. In my case, I don't. Well, I used it in the past, but forgot, and things have changed. And by not looking closely at the documentation, one can easily do something wrong (e.g. forget IPv6 rules). Anyway, I don't think this is a reason good enough to have postfix to not start when you install it, and add one more step when configuring it. Anyway one more step is needed in both cases: * If postfix has not started yet, start it at the end. * If postfix has already started, reload the configuration. You are also considering a specific case of the SMTP server, where it is used to receive outbound emails. Sometimes, you only install a mail server to handle system mails (like cron jobs, and so on). In this case, it would really be not convenient to have the daemon not starting by default. Hmm, OK, it seems that postfix works differently from exim (with exim, the daemon is not needed to send a local mail: the sendmail interface does all the job). Then, I think that it would be better to have another debconf question for the Internet Site case (and Internet with smarthost?) in order to let the admin decide whether he wants to listen to all interfaces now or later. The goal would be to benefit from the automatic config from the first debconf questions, but let the admin terminate advanced configuration. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130515144038.gb24...@ypig.lip.ens-lyon.fr
Re: jessie release goals
Russ Allbery rra at debian.org writes: The cvs package went down the debconf path, and it never failed to annoy me. When I installed the cvs package to get the cvs command-line client to access remote CVS repositories, it asked me where I wanted to create a Or even automatically created one, yeah. That’s fixed in wheezy. bye, //mirabilos (maintainer of GNU CVS in Debian and MirBSD) -- 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.20130515t171900-...@post.gmane.org
Re: /bin/sh (was Re: jessie release goals)
On 2013-05-07 14:23:47 +, Thorsten Glaser wrote: Shells suitable for /bin/sh are currently bash, dash, mksh. [...] I have no idea whether yash or zsh can be made suitable, but I think both could, if the maintainers and possibly upstream are interested. Though zsh has an option to emulate sh, it may still not be completely compatible. Upstream fixes incompatibilities when it is easy. But some incompatibilities may remain. If sh needs special multibyte (UTF-8) support for some features in UTF-8 locales, there may be a problem with zsh, as in sh emulation mode, multibyte support is completely disabled, and enabling it yields incompatibilities (that's why http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659932 is still there). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130515153344.gc24...@ypig.lip.ens-lyon.fr
Re: /bin/sh (was Re: jessie release goals)
Jonathan Dowland jmtd at debian.org writes: I think you are totally out of order, here. You could equally be criticised of having your judgement clouded by your involvement with MirOS. That would I admit being biased for that very reason. And that’s also the reason I try to push for freedom of choice, instead of for a change of the default. be just as absurd. Steve has been contributing to Debian much longer than you, or I have, or Ubuntu has existed. Okay, I accept this. Vorlon writes: A minimum demonstration of competence on the part of anyone proposing to change the shell again is to fix those RC bugs without introducing new ones. The problem here is communication. If you read the bug logs and, IIRC, mailing list maybe too, from that time, and ask Goswin how we tried to get a solution working during DebČevapćičiConf, you’ll find I tried precisely that. The dash maintainer agreed to try out the plan, but the bash maintainer IIRC never replied, and we suffered (and probably still do) from a shortage of people understanding debconf, diversions and other involved magic. So, please do not accuse me of not trying to fix that situation – yet there’s only ever so much a sole DD and a nōn-DD can do (why _is_ Goswin on hold, anyway?). Helmut writes: Did you talk to the initramfs maintainers I did not do that yet. As you can see, it’s hard enough to get taken seriously in the first place (see also #532324 which, by the way, I got told by several other DDs after the CTTE non-ruling that they agree with me). As for your requests of data: I do not provide them. As I said above, I’m pushing for freedom of choice, not switching the default; of course I’d be happy with the latter, even more so actually, but it must be a thing not driven by me; if there’s enough other people (especially DDs) interested in actually doing that it has potential to get taken a bit seriously at all; if I’m involved, all bets are off (especially now, I guess). Using the diversion mechanism to change /bin/sh is highly risky and was never supported. Actually, dash uses a diversion too, so it was supported pretty well. As for “breaking sid”: Yes please. The current diversion that’s already in place prevents another diversion being set, so the only way for squeeze and up for an admin to change their local system shell is to run sudo ln -sf mksh-static /bin/sh (and one for sh.1.gz manpage) and reapply that occasionally after upgrades (of dash only, from what I can gather). And with that, here comes Vorlon again. I see you have facts about the history for me; these are welcome. I think that’s my karma quota for the day; have a nice evening everyone! bye, //mirabilos ObCAPTCHA: earthward (I think Wouter’s sig quote was added automatically, but GMane offering this one to me now is just funny.) -- 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.20130515t172855-...@post.gmane.org
Re: /bin/sh (was Re: jessie release goals)
On 05/14/2013 06:07 PM, Philip Hands wrote: He missed the fact that you were contrasting one non-crashing init, that is capable of restarting dead services, with another non-crashing init setup that is not able to do so (without help). Oh, indeed I missed that point! Thanks Phil. 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/5193b8c5@debian.org
Re: /bin/sh (was Re: jessie release goals)
On 05/15/2013 05:52 AM, Vincent Bernat wrote: I have still hard time to consider that you absolutely did not mention something related to a bootloader. I believe Phil Hands explained better than I would what I tried to explain. On 05/15/2013 05:52 AM, Vincent Bernat wrote: Like in the previous discussions, you use some twisted tactics to make the consensus difficult to reach I can assure you that I don't have such intention. I'm not trying to make the consensus difficult to reach, at least not through this list : I hope that OpenRC being a workable solution will make it harder to choose though, since I like it a lot and that it will work for kFreeBSD and Hurd, though until then, it's pointless to argue for it, so I'm trying (hard) not to do it... :) 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/5193b927.1090...@debian.org
Re: /bin/sh (was Re: jessie release goals)
Am 15.05.2013 02:12, schrieb Michael Biebl: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. http://www.freedesktop.org/software/systemd/man/journald.conf.html Storage=none And I forgot to mention: systemd is one of the best, if not the best documented open source project I've seen so far. From man pages to blog stories to wiki pages, it's simply amazing how much effort upstream, especially Lennart, is invensting into great documetation. I know from personal experience how hard it is, to write good documentation and also actually keep it up-to-date. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: jessie release goals
Le 15/05/2013 16:40, Vincent Lefevre a écrit : Here this is more than a mail server being down. It is a domain without a MX; doesn't this mean a direct reject? Actually removing the MX pointer wouldn't be OK, as the client may look at the A record instead, which can't be removed without temporarily affecting other services. So, I'm not sure what should be done (except iptables...). start anything that does not speak SMTP on port 25. while true; do nc -l 25; done should be enough for all your needs. This does not require knowing any iptables stuff. But someone managing a SMTP server at this level of care should know something about networking. Hmm, OK, it seems that postfix works differently from exim (with exim, the daemon is not needed to send a local mail: the sendmail interface does all the job). Then, I think that it would be better to have another debconf question for the Internet Site case (and Internet with smarthost?) in order to let the admin decide whether he wants to listen to all interfaces now or later. The goal would be to benefit from the automatic config from the first debconf questions, but let the admin terminate advanced configuration. No. Your server comes unconfigured, you do configure it while the other is still working, and then you stop the service on the first, finish syncing the mailboxes, switch the MX record, and then you can go to rest. This is no black magic. What you want is being over-cautious and will lead to people not understanding the basics or misanswering a debconf question to have non-functional servers and not being aware of it. I am definitely in the camp of you install a service, you get a working, minimal, safe configuration. Sincerly, -- -- Jean-Christophe Dubacq signature.asc Description: OpenPGP digital signature
Re: jessie release goals
Christoph Anton Mitterer wrote... 2) No more packages that bypass the package management system and secure apt: a) There are still several (typically non-free) packages which download stuff from the web, install or at least un-tar it somwhere without checking any integrity information that would be hardcoded in that package. b) Another problem are IMHO plugins like Firefox extensions, kinda bypassing APT. I think at least those that are installed via a package, shouldn't be upgradable/overwritable anymore with online versions. I'd like to enhance that topic to the question under which circumstances a package is allowed to phone home, i.e. to contact a service provided by upstream without the consent of the user. For the records, I wouldn't mind much if the rule is never. Still an answer might be not as easy as it seems, a few situations: * Automatic update checks don't make sense, mostly they confuse users. * As an example, nagios3 upstream embedded several requests to the nagios homepage on the start page of any local installation. That I consider both annoying and a privacy breach, so I patched that away locally. But perhaps such behaviour should be banned entirely. * On the other hand, there are packages that do need frequent updates, virus scanners to start with, also ad blockers. Not sure whether these should be granted an exception. If not, somebody would have to take the task to provide these updates in an APT way. Just sharing a few thoughts on that ... Christoph -- 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/1368645...@msgid.manchmal.in-ulm.de
Re: jessie release goals
Another thing: Hardening already has been a release goal but there still are packages around without. After having seen the proctetion catching a programming bug I think more importance should be put on that, either by considering all packages rc-buggy that should be built with hardening wrappers but are not - or at least packages providing code that, in some sort of order: * has the setsuid set, * usually/regulary runs as root, * is a daemon. Also, debhelper 9 has eased usage of hardening wrappers as lot so a major excuse not to add them is now void. Christoph -- 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/1368647...@msgid.manchmal.in-ulm.de
Re: /bin/sh (was Re: jessie release goals)
On Wed, May 15, 2013 at 05:33:44PM +0200, Vincent Lefevre wrote: Though zsh has an option to emulate sh, it may still not be completely compatible. Upstream fixes incompatibilities when it is easy. But some incompatibilities may remain. If sh needs special multibyte (UTF-8) support for some features in UTF-8 locales, there may be a problem with zsh, as in sh emulation mode, multibyte support is completely disabled, and enabling it yields incompatibilities (that's why http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659932 is still there). Some years ago, Apple shipped zsh as /bin/sh for Mac OS X. It broke a lot of things at the time, including some of the autotools. I also tried zsh as /bin/sh, but found that debconf didn't work at all. Don't get me wrong, I love zsh, but without some serious work, it isn't at all a viable candidate for /bin/sh. I use mksh-static for /bin/sh. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
On 05/13/2013 06:05 AM, Josselin Mouette wrote: Le dimanche 12 mai 2013 à 19:40 +0200, Helmut Grohne a écrit : With all due respect, this might be utter bullshit, but is at least [citation needed]. I have yet to see a failing pid 1 (be that sysv, upstart or systemd). Acquiring data on failure modes of any of those systems appears like a difficult task and d-devel might not be the best place to discuss that. Having a rock-stable PID 1 is nice and all, but it doesn’t help you if something important crashes. On a production server, if apache crashes and fails to reload properly because the scripts don’t get the ordering right, it doesn’t help you that init is still running fine. That is quite not truth. Let's say you have a broken HDD, and that you forgot to setup grub on the 2nd HDD or something else that will prevent boot up. In one case, you're totally screwed, on the other, you just restart Apache ! It would help you to have an init implementation that can detect which components can be initialized and at what time. For that, we have stuff like monit, which have been working in production for years without issues, and which has some other very interesting features (like sending you a mail when the process changes PID). You aren't much on the server things are you? 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/5191e7ab.80...@debian.org
Re: parsable copyright format 1.0 (jessie release goals)
On 2013-05-13, Robert Collins robe...@robertcollins.net wrote: The use cases are not at all fringe: every company I have worked at since open source became the dominant source of libraries has had some set of rules and policies around which licenses to use when, and good data about that makes decision making easier. As a trivial example GPL 2 only code is But how many companies would actually base their decisions upon the content of debian/copyright (which might be wrong or outdated) instead of actually *checking* themselves? /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/slrnkp3rm1.j8.nos...@sshway.ssh.pusling.com
Re: /bin/sh (was Re: jessie release goals)
Le mardi 14 mai 2013 à 15:28 +0800, Thomas Goirand a écrit : On 05/13/2013 06:05 AM, Josselin Mouette wrote: Having a rock-stable PID 1 is nice and all, but it doesn’t help you if something important crashes. On a production server, if apache crashes and fails to reload properly because the scripts don’t get the ordering right, it doesn’t help you that init is still running fine. That is quite not truth. Let's say you have a broken HDD, and that you forgot to setup grub on the 2nd HDD or something else that will prevent boot up. In one case, you're totally screwed, on the other, you just restart Apache ! Yes of course, because a different init system will magically make your other disk bootable. It would help you to have an init implementation that can detect which components can be initialized and at what time. For that, we have stuff like monit, which have been working in production for years without issues, and which has some other very interesting features (like sending you a mail when the process changes PID). If you use tools like monit, you should be able to understand that such behavior should be standard for daemons shipped in Debian, and that sysadmins should not have to configure it themselves. Such tools also have limitations that systemd and upstart do not have, such as having to use heuristics (sometimes convoluted ones) to detect when a service is ready. You aren't much on the server things are you? I might not have setup any datacenter in a tax haven, but next time, you might want to look at who people are before giving them lessons, especially when you are unable to tell the difference between an init system and a bootloader. kthxbye, -- .''`. 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/1368521486.3585.1616.camel@pi0307572
Re: /bin/sh (was Re: jessie release goals)
Helmut Grohne helmut at subdivi.de writes: What are the benefits of using shells other than dash for /bin/sh? (as Why does dash get special treatment, anyway? It was “suddenly“ in Debian after having been used in Ubuntu, but… there never was an evaluation of shells. I still believe the codebase of mksh is better (modulo issues introduced due to the active development), but I’m happy with freedom to choose one’s own system shell… (asides from the two things you mentioned) … or provide an mksh-static binary package. Which could also be used in initrd. 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.20130514t105738-...@post.gmane.org
Re: /bin/sh (was Re: jessie release goals)
On 05/14/2013 04:51 PM, Josselin Mouette wrote: Yes of course, because a different init system will magically make your other disk bootable. This is absolutely *NOT* what I said. Nothing in my message compares this or that init system. I just replied that when you have apache, it's easier to recover than with the PID1 crashing. That's it, nothing more, nothing less. If you use tools like monit, you should be able to understand that such behavior should be standard for daemons shipped in Debian, and that sysadmins should not have to configure it themselves. I do think that restarting crashed daemons is a nice feature, yes. Though I believe OpenRC has this feature too (I have no time to check for that fact right now, but I think I remember reading it somewhere). Also, I still believe that monit does its job well on the server side, and that a generalized tool will not be adapted for it. Only for servers, we should receive emails when there's something that happens with a daemon, I don't want my laptop to do that, even for Apache that I run there. So yes, it should be configured by the admin!!! Such tools also have limitations that systemd and upstart do not have, such as having to use heuristics (sometimes convoluted ones) to detect when a service is ready. I'm well aware that cgroups are important, yes. Though no, I don't think systemd or upstart would be good tools to do what monit does (unless they send emails? I haven't seen such a feature in upstart and systemd...) especially when you are unable to tell the difference between an init system and a bootloader. What lead you to believe I can't make such difference? The fact that I hacked a bit with OpenRC (and bloged about it), and that I am mentoring a GSoC around it, should give enough clue that I do know what an init system does. BTW, I didn't intend to make you angry, or to give lessons. Please don't take it this way, I was only kidding you (eg: joking *with* you, not trying to expose you in public). 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/519209bb.5080...@debian.org
Re: /bin/sh (was Re: jessie release goals)
Josselin Mouette j...@debian.org writes: Le mardi 14 mai 2013 à 15:28 +0800, Thomas Goirand a écrit : On 05/13/2013 06:05 AM, Josselin Mouette wrote: Having a rock-stable PID 1 is nice and all, but it doesn’t help you if something important crashes. On a production server, if apache crashes and fails to reload properly because the scripts don’t get the ordering right, it doesn’t help you that init is still running fine. That is quite not truth. Let's say you have a broken HDD, and that you forgot to setup grub on the 2nd HDD or something else that will prevent boot up. In one case, you're totally screwed, on the other, you just restart Apache ! Yes of course, because a different init system will magically make your other disk bootable. Erm, no that's not what he was saying. He was assuming that there must be a fault somewhere, so if it's not in the init scripts, it must be in systemd -- this of course is nonsense, but if you start from that assumption then it is better for apache to fail to restart than it is for systemd to crash. He missed the fact that you were contrasting one non-crashing init, that is capable of restarting dead services, with another non-crashing init setup that is not able to do so (without help). Just thought I'd clear that up. 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 pgpu90seuXXzC.pgp Description: PGP signature
Re: jessie release goals
On 13-05-13 05:59, Mark Symonds wrote: Can we keep the distribution simple enough for nearly anyone to understand? No. The goal of Debian is not to be simple. While we should document things as much as possible so that the interested can learn how things work, in no case should we ever avoid doing the technically sound because it is difficult to understand. -- 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/51921056.9030...@debian.org
Re: jessie release goals
Quoting Wouter Verhelst (2013-05-14 12:22:14) On 13-05-13 05:59, Mark Symonds wrote: Can we keep the distribution simple enough for nearly anyone to understand? No. The goal of Debian is not to be simple. While we should document things as much as possible so that the interested can learn how things work, in no case should we ever avoid doing the technically sound because it is difficult to understand. -- 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/ Did you pick that quote to support your point, or was it added automatically? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -- 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/20130514111818.4452.28...@bastian.jones.dk
Re: parsable copyright format 1.0 (jessie release goals)
On Sun, May 12, 2013 at 07:52:25PM +0800, Thomas Goirand wrote: Being able to write tools to extract the license of any given package. Well, extract what the maintainer thought the license was when they wrote debian/copyright. What correlation that has with reality is an open 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/20130514111930.GA3761@debian
Re: jessie release goals
On Tue, May 7, 2013 at 9:06 AM, Thijs Kinkhorst th...@debian.org wrote: I suggest that you file a bug against php5 with suggested changes and we can discuss the pros and cons of each for jessie. And I must add that I consider very rude to push your (sometimes extreme, sometimes very usefull) ideas how should PHP in Debian look like directly as a freaking *release goals* instead of opening this first in php-maint list for discussion. All in all I don't see any Release Goal material yet, here. +1 O. -- Ondřej Surý ond...@sury.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/CALjhHG_+6nBjVF+ejTEmXJxtVKVA4TEm=BsxCctqdb04=ld...@mail.gmail.com
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 08:44:30PM +0100, Roger Leigh wrote: ... forcing the rest of the world to conform to our worldview. One desktop environment, and an awful one at that, dictating the init system we use is a complete farce. Debian is a lot bigger than GNOME, and if we have to, I'd vote for junking it entirely. As much as I liked GNOME over competing desktops in the past, this time I have to fully agree with this statement of yours. Kind regards, --Toni++ -- 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/20130514131241.ga10...@spruce.wiehl.oeko.net
Re: /bin/sh (was Re: jessie release goals)
On Tue, 2013-05-14 at 08:59 +, Thorsten Glaser wrote: Helmut Grohne helmut at subdivi.de writes: What are the benefits of using shells other than dash for /bin/sh? (as Why does dash get special treatment, anyway? It was “suddenly“ in Debian after having been used in Ubuntu, but… there never was an evaluation of shells. [...] Because it's our very own tiny shell: http://en.wikipedia.org/wiki/Debian_Almquist_shell Ben. -- Ben Hutchings Make three consecutive correct guesses and you will be considered an expert. signature.asc Description: This is a digitally signed message part
Re: jessie release goals
On Mon, May 13, 2013 at 07:26:15PM +0200, Stephen Kitt wrote: On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow goswin-...@web.de wrote: On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote: The big issue which crops up then isn't so much the directory structure's impact on the build process, but rather its impact on the packaging process. If the target directory structure depends on whether we're building for a full Debian architecture or for a partial architecture or just some cross-compiler target, that means ad-hoc changes in the packaging for the various cases and that much more friction (see for example http://bugs.debian.org/671437 - although in zlib's case packaging changes are necessary to build for Windows). But it wouldn't. The target directory structure would be the same across all builds. It would always be /usr/include/[$(DEB_HOST_MULTIARCH)] and /usr/lib/[$(DEB_HOST_MULTIARCH)]. The effect of partial architecture is simply that not everything needs to be build for that architecture and the partial architecture might not be self hosting. E.g. we can cross build for mingw but we wouldn't be including windows in Debian nor run a buildd on windows. Yes, but that's not the problem. Take the premise that the target directory structure is as described above, so most library development packages ship as many headers as possible in /usr/include. For now we'll assume all mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32; but to use mingw-targeted libraries other than mingw-w64-...-dev (libgtk for example), the mingw toolchain needs to look in /usr/include as well. Every compile has to look in /usr/inlclude/triplet and /usr/include/. mingw is no special case there. This is all fine as long as libc6-dev is not installed (say perhaps with sbuild and cross-build-essential). But in a typical work environment, libc6-dev will be installed, and because we'll always be cross-compiling on the buildds, packages which need to build stuff for the host to run during the build (wine-gecko does this) need build-essential too, so libc6-dev headers end up in /usr/include and are picked up by the mingw toolchain. Only architecture independent header are in /usr/include. Now in the case of w32/w64 as architectures those headers must also be suitable for windows or they are no longer architecture independent. I guess that is the problem you see. I don't see that anything changes for the layout. You just added a rather strange arch which breaks the architecture independency of libc6-dev stuff. Is that any different from building for a uclibc system? I think you have the same problem there. How much of libc6-dev and other libs are we talking about here? Packages could also have: foo-dev-common:all (or all foo-dev): /usr/include/foo.h foo-dev:w32: /usr/include/w32/foo.h - ../foo.h foo-dev:w64: /usr/include/w64/foo.h - ../foo.h Then mingw would only need to look there. This would be special casing those archs. So not an ideal solution. Likewise for other -dev packages which may be available for the host architecture but not the target architecture. Imagine the confusion then for configure scripts! Yes, that is a big problem. Luckily we have Build-Depends/Conflicts so all the right packages are there and all the wrong packages are not. For buildds that shouldn't be a problem. Also any link test for libs will fail if the -dev is not installed for the right arch. As far as I can see there are three solutions to this: * split headers completely Possible without any toolchain changes. Just move the files in every -dev package. * drop the idea of building mingw packages using the existing Debian packaging I don't think mingw is overly special there. Cross-compiling, esspecially for a different libc, will be verry similar. * add patches to all supported packages so that they build differently when targeting mingw (and any other partial architecture which can't share /usr/include) * install w32/w64 packages in a sysroot, i.e. prefix every file on unpack. Not sure how well that would work with maintainer scripts though. For other cross-compiles one can use chroot but you probably don't want / can't use that for w32/w64. This could be done during build. Sort of like option 3. A small patch to move debian/package/* to debian/package/usr/lib/mingw/ before building the deb. Fedora went with the second solution; they have mingw-specific packages for everything they build targeting Windows. If we could build-depend on source packages (which has been mentioned elsewhere in this thread) this would be possible on Debian too, although it would be a bit of a chore for me (and whoever else wants to chip in). But I wouldn't want supporting a non-free operating system to become a chore for more Debian developers than necessary! (The aim of all the mingw work as far as Debian is concerned, apart from
Re: jessie release goals
Paul Wise wrote: Probably the rsync package should just ask you via debconf if you want to serve any directories and what their names and paths should be. Since most folks who have rsync installed don't need rsyncd, the default would be to not setup anything. No, it should not. 60 packages depend on rsync. Installing a package like git should not require batting away debconf prompts about unusual configurations that, if something is typed into them, can expose the system to security holes. -- see shy jo signature.asc Description: Digital signature
Re: jessie release goals
+++ Stephen Kitt [2013-05-13 19:26 +0200]: Yes, but that's not the problem. Take the premise that the target directory structure is as described above, so most library development packages ship as many headers as possible in /usr/include. For now we'll assume all mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32; but to use mingw-targeted libraries other than mingw-w64-...-dev (libgtk for example), the mingw toolchain needs to look in /usr/include as well. This is all fine as long as libc6-dev is not installed (say perhaps with sbuild and cross-build-essential). But in a typical work environment, libc6-dev will be installed, and because we'll always be cross-compiling on the buildds, packages which need to build stuff for the host to run during the build (wine-gecko does this) need build-essential too, so libc6-dev headers end up in /usr/include and are picked up by the mingw toolchain. Thank you for explaining this. I now understand your issue. It is helpful to have an example of why a full-split might have advantages over an 'only arch-dependent' split. Or at least that we need to be careful about what the definition of 'arch-dependent' is, if we want to include windows ABIs, or uclibc ABIs (I think those two cases may well amount to the same problem). Can anyone from BSD camp tell us whether having glibc-dev headers installed in a common dir would break cross-building for them too? Simon has expanded on this helpfully already: 'glibc is somewhat special as part of the ABI' (remembering that multiarch maps to ABIs). It's good to know about this before the design is set in stone, so this conversation is timely. What I'm not sure about is whether the multiarch-cross design is seriously broken or if it's just a matter of packaging libc-dev correctly to allow for non-glibc platforms. Multiarch has thus far largely been thought of in terms of platforms you can also install Debian to as well as build for. But multiarch-cross ought to be a good fit for crossing to other platforms (within reason) too. So we should certainly consider whether we can sensibly accomodate that or not. I'm not quite sure how best to decide that. Some people need to try some stuff and report back, I suspect. Would simply moving all the libc headers to /usr/include/$multiarch fix mingw builds? How many other libraries are similarly affected? 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/20130514163759.ge2...@stoneboat.aleph1.co.uk
Re: jessie release goals
On 05/13/2013 07:08 PM, Vincent Lefevre wrote: On 2013-05-07 23:54:36 +0800, Thomas Goirand wrote: On 05/07/2013 04:00 AM, Vincent Lefevre wrote: This can be fine for some daemons/servers. For instance, for a web server, displaying a default web page is harmless. But what about a mail server? Any default config would probably lead to loss of mail if things like virtual alias domains are used. If you set your MX pointer before setting-up your mail server, then it's your fault if you loose some mails, and not at all the fault of the way postfix (for example) is packaged. In one case, this was after a full reinstallation of the server (not Debian, but the problem would be the same). I didn't have the choice. This is, IMO, a very special case. And removing the MX pointer several hours before the reinstallation would also have resulted in loss of mail. Why do you think so? Normally, a mail server can be down for up to a day, without any lost of mail. The cleanest solution, IMHO, would have been to use iptables to prevent SMTP connections before installing postfix, but for someone who doesn't know iptables yet, that's more complex than having the control on whether the daemon is started or not at install time. I don't think iptables is more complex than postfix (in fact, to some degree, it might even be more simple, considering how complex postfix is). I do expect any administrator handling postfix to also know iptables. Anyway, I don't think this is a reason good enough to have postfix to not start when you install it, and add one more step when configuring it. You are also considering a specific case of the SMTP server, where it is used to receive outbound emails. Sometimes, you only install a mail server to handle system mails (like cron jobs, and so on). In this case, it would really be not convenient to have the daemon not starting by default. Of course, YMMV depending on what you do with mail... 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/51926db5.2040...@debian.org
Re: jessie release goals
Philip Hands wrote: Vincent Lefevre writes: I agree for these services (though Apache is useless after just being installed, as one just has a dummy web page). I don't know about you, but I find it quite reassuring to be able to confirm that the first half of an install is going pretty well when I get to see the useless dummy page from Apache. I also find the empty default placeholder very useful. I wouldn't call it useless at all. There are no security issues. I see no resource differences since if it wasn't intended to be used then it shouldn't have been installed. Also, I am often hosting some service in a subdirectory. No top level page is needed. I often have no reason to modify that top level page ever and leave it unchanged. The service hosted in a subdirectory continues independently. If things were changed to force users to create a dummy top level page and enable the server then it would add additional required work over what is done now. The RedHat assumptions on this issue make me as unhappy as the Debian ones appear to make you unhappy. I suggest that this is just a matter of taste. Agreed. Strongly! Bob signature.asc Description: Digital signature
Re: jessie release goals
Joey Hess jo...@debian.org writes: Paul Wise wrote: Probably the rsync package should just ask you via debconf if you want to serve any directories and what their names and paths should be. Since most folks who have rsync installed don't need rsyncd, the default would be to not setup anything. No, it should not. 60 packages depend on rsync. Installing a package like git should not require batting away debconf prompts about unusual configurations that, if something is typed into them, can expose the system to security holes. +1 Debconf should be used in cases where a substantial percentage of the people installing the package are going to want the thing Debconf is prompting about. If the vast majority of users aren't going to care about that functionality at all, either the package should be split (generally the best move) or the unusual configuration should be documented elsewhere (like README.Debian) and possibly automated with an external configuration tool. The cvs package went down the debconf path, and it never failed to annoy me. When I installed the cvs package to get the cvs command-line client to access remote CVS repositories, it asked me where I wanted to create a directory to host CVS repositories. I bet fewer than 1% of the people installing cvs wanted to do anything of the sort. For the specific case of rsync, I think we should just make rsync and rsyncd (or rsync-server) packages and be done with it. Yes, small packages are to be avoided in general, but when the packages are used by people with very different needs and one of them wants to add init scripts to launch a daemon, to me that's a good reason for a package split. I've been mildly annoyed for years at all the systems I have that have a completely useless rsync init script installed that runs with every boot. -- 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/87bo8d4het@windlord.stanford.edu
Re: /bin/sh (was Re: jessie release goals)
On Tue, May 14, 2013 at 08:59:57AM +, Thorsten Glaser wrote: Helmut Grohne helmut at subdivi.de writes: What are the benefits of using shells other than dash for /bin/sh? (as Why does dash get special treatment, anyway? Because /bin/sh is special under Debian policy, as an essential interpreter. So the right thing for the project is to treat *some* POSIX sh implementation specially. I don't think anyone (except you) actually cares if this should be mksh or dash - we care that it should *not* be bash which is too heavyweight, but I don't think there are any strong arguments why mksh or dash should be preferred. Which means that there is no strong argument for switching away from dash, since that change would cause more work and introduce more bugs for no material gain. It was “suddenly“ in Debian after having been used in Ubuntu, but… there never was an evaluation of shells. No, you are apparently lacking in historical context. The effort to switch to dash by default began in Debian; it was accomplished in Ubuntu more quickly because Ubuntu had no established userbase at the time and could ignore the problem of local diversions of /bin/sh. Debian then had to play catch-up with the implementation of its own plan. I still believe the codebase of mksh is better (modulo issues introduced due to the active development), but I’m happy with freedom to choose one’s own system shell… The end user can always add a local diversion again to point /bin/sh at mksh if they choose. But I don't see any reason why an end user should care about this, period. -- 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: parsable copyright format 1.0 (jessie release goals)
* Sune Vuorela nos...@vuorela.dk [130512 12:43]: It is too much work for far too little gain. What *is* the gain? What is the gain of copyright files? One big gain of a copyright file is the act of doing it. For software to be distributable every copyright owner has to have given his permission. To know that you have all those permissions, you first need to know who those people actually are. It also documents our reasonable exercises to reach our believe that this is distributable. I'd guess in some legislations such efford can make the difference between just distribute it no more and pay for every copy that was made. 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/20130514212524.ga3...@client.brlink.eu
Re: /bin/sh (was Re: jessie release goals)
❦ 14 mai 2013 11:54 CEST, Thomas Goirand z...@debian.org : Yes of course, because a different init system will magically make your other disk bootable. This is absolutely *NOT* what I said. Nothing in my message compares this or that init system. I just replied that when you have apache, it's easier to recover than with the PID1 crashing. That's it, nothing more, nothing less. And you conveniently removed you original message: That is quite not truth. Let's say you have a broken HDD, and that you forgot to setup grub on the 2nd HDD or something else that will prevent boot up. In one case, you're totally screwed, on the other, you just restart Apache ! I have still hard time to consider that you absolutely did not mention something related to a bootloader. Like in the previous discussions, you use some twisted tactics to make the consensus difficult to reach by using false claims, repeating them over and over, then claiming otherwise and asking references until everyone gets tired. -- panic(Attempted to kill the idle task!); 2.2.16 /usr/src/linux/kernel/exit.c pgpHJWSiu0FEC.pgp Description: PGP signature
Re: /bin/sh (was Re: jessie release goals)
On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. It is also not better if you want an init that does not dump its own log messages to LOG_KERN. As a reasonably sane person, it had never occurred to me to put non-kernel logs under LOG_KERN for any reason whatsoever. For better or for worse, sysvinit provides a lot of modularity. systemd provides none of that modularity, and there are a lot of things it does that I'd rather disable (or better yet, uninstall) because they're just wrong. When I've used upstart and sysvinit, I've never had functionality that I wanted to disable and remove. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. http://www.freedesktop.org/software/systemd/man/journald.conf.html Storage=none -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: /bin/sh (was Re: jessie release goals)
Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in The format may be binary, but it certainly is not proprietary [1] Michael [1] http://www.freedesktop.org/wiki/Software/systemd/journal-files -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: /bin/sh (was Re: jessie release goals)
On 05/15/2013 02:16 AM, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in The format may be binary, but it certainly is not proprietary [1] I really can't believe people are still coming up with that non-sense. I have no idea why people assume that a binary format means it can only be processed with a special, proprietary tool. Binary simply means what it means, binary and not text which means it's a more stream-lined and machine-readable format as opposed to a text format with no formatting at all. And, when it comes to processing, binary data is actually *easier* to process. Everyone who has ever written a text parser themselves will agree. 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/5192d6f4.6090...@physik.fu-berlin.de
Re: /bin/sh (was Re: jessie release goals)
And, when it comes to processing, binary data is actually *easier* to process. Everyone who has ever written a text parser themselves will agree. I guess everyone who has used grep, tr, sed and so on will disagree? -- Salvo Tomaselli http://web.student.chalmers.se/~saltom/ -- 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/2166875.xrvvLYdKdA@hal9000
Re: /bin/sh (was Re: jessie release goals)
On Wed, May 15, 2013 at 02:29:40AM +0200, John Paul Adrian Glaubitz wrote: On 05/15/2013 02:16 AM, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in The format may be binary, but it certainly is not proprietary [1] I really can't believe people are still coming up with that non-sense. Maybe because I read it on LWN (http://lwn.net/Articles/468381/): All complaints about UUIDs were quickly overshadowed by another issue once the full proposal was posted: one might charitably say that there is not, yet, a consensus around the proposed new logfile format. In a sense, that is unsurprising, since that format is deliberately undocumented and explicitly subject to change at any time. You'll pardon me if I believe that LWN is a reputable source for information. I have no idea why people assume that a binary format means it can only be processed with a special, proprietary tool. Binary simply means what it means, binary and not text which means it's a more stream-lined and machine-readable format as opposed to a text format with no formatting at all. It means that it works completely differently from every existing Unix log parser on the planet. syslog is hardly no formatting at all. And, when it comes to processing, binary data is actually *easier* to process. Everyone who has ever written a text parser themselves will agree. I have written several, and I still prefer plain text. I want to use the same tools to parse my logs that I have used for years, like logcheck. Text files is the Unix way. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
On Wed, May 15, 2013 at 02:12:10AM +0200, Michael Biebl wrote: Am 15.05.2013 01:26, schrieb brian m. carlson: On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote: This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. It is not better if you don't want proprietary binary-format logs in /var/log with no documented way to turn them off. http://www.freedesktop.org/software/systemd/man/journald.conf.html Storage=none Silly me. I expected that if I installed systemd, that the appropriate man pages would be shipped with the package: vauxhall ok % man journald.conf No manual entry for journald.conf -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: /bin/sh (was Re: jessie release goals)
❦ 11 mai 2013 22:08 CEST, Josselin Mouette j...@debian.org : I can't agree with having no choice with regard to init. We aren't all using GNOME, and Debian is used in an extremely diverse set of fields for a multitude of different purposes. No one init is appropriate for all of these applications. systemd fails on safety grounds alone for a good number of uses. That much complexity is an unacceptable risk for PID1 failure. This is utter bullshit and you should already know it. Systemd is much more reliable as a whole than any other implementation. I have yet to see a use case where it is not better. Unfortunately, its current implementation in Debian has some serious drawbacks: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669101 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=697962 Don't get me wrong: I would love to have systemd as a default init. It would solve many problems and bugs like above would be fixed because the burden would not rely on systemd maintainers alone (and I suspect the bugs are here because systemd has to integrate with the current SysV init). I only point the current problems with systemd as an example as what we get with the current situation: inability to fully use systemd. One year ago, there was a good plan for this: 1. Switch to systemd as default init (or Upstart). 2. Provide a conversion system from (more descriptive) systemd unit files to some other still supported systems (like the old SysV) with the ability to override the conversion by shipping an init.d file. There was a GSoC for this. I remember that the code is here but there was no followup. Switching to a default modern init has two benefits: 1. The benefits from the modern init system alone. 2. A proper integration into Debian by removing old cruft from packages making the new init work as intended by upstream (and therefore less buggy) and move the responsability of a working init system to other packages (nobody would blame sysvinit package for a problem in some init.d files, it should be the same for systemd). The conversion mechanism is a compromise solution for those that want freedom of choice on the init system. Unfortunately, switching to systemd unit files is a requirement for the whole thing to work and it implies that we switch to systemd by default and it is a project choice. So, no way to get forward here until we get a consensus. -- Program defensively. - The Elements of Programming Style (Kernighan Plauger) pgp4F2LQZivFp.pgp Description: PGP signature
Re: /bin/sh (was Re: jessie release goals)
On Du, 12 mai 13, 20:31:08, John Paul Adrian Glaubitz wrote: The difference between a shell and an init system is that the former is directly exposed to the user while the latter will only be visible to developers and admins most of the time. It makes sense to be able to customize your user interface, but I don't think it makes sense to be able to customize a core component like the init daemon. AFAICT the discussion is about /bin/sh, not about the login shell. For most users it will not make much difference which of dash, bash, etc. provides /bin/sh. 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: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On Mon, May 13, 2013 at 02:31:02AM +0200, Marco d'Itri wrote: On May 13, Holger Levsen hol...@layer-acht.org wrote: actually, while it has been brought up as a theoretical/wrong argument, that we cannot switch our linux installation ship with $this init system, while the kfreebsd port uses $that init system, I'd say nobody is seriously saying this now. We will support several init systems anyway. At least for jessie+X. Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev depend on either upstart or systemd. I would rather not be the one who will choose which one of them, so I hope that we will get to a consensus about this. Neither choice is acceptable, as you are undoubtedly aware. There is no need for udev to be dependent upon a specific init system, other than laziness. Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- 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/20130513074623.go21...@codelibre.net
Re: jessie release goals
Paul Wise p...@debian.org writes: On Mon, May 13, 2013 at 1:01 AM, Philip Hands wrote: I don't know about you, but I find it quite reassuring to be able to confirm that the first half of an install is going pretty well when I get to see the useless dummy page from Apache. I'd imagine someone installing their first web server would also find that reassuring (I still remember grinning broadly when first seeing it). If it were also their first Debian server, then forcing them to find an extra ON switch after installing apache just seems like an extra and unneeded barrier. I think it would be better for apache to ask via debconf which vhosts you want to setup and which directories/configs/etc they should use. The should it run on install? question is a matter of taste and judgement, which is why it is not the case with rsyncd. We have debconf to resolve matters of taste. The current state of rsyncd is probably my fault (as initial packager of rsync). One _could_ have an rsyncd package, containing just a commented out example /etc/rsyncd.conf and the init.d script, but I don't really see the point. If ...ENABLE=false settings are banned in defaults files (as I've come to think they should be) then in the case of rsyncd, one could make the running of the daemon conditional on the existence of the $RSYNC_CONFIG_FILE file (which is not shipped in the package). Probably the rsync package should just ask you via debconf if you want to serve any directories and what their names and paths should be. Since most folks who have rsync installed don't need rsyncd, the default would be to not setup anything. It looks to me as though your apache and rsyncd suggestions are straying into the forbidden territory of using debconf as a registry. As for the matter of taste, if someone wants to have a debconf question along the likes of: Disable all daemons by default at install time? and tweak update-rc.d et al to attempt to do something appropriate, and oversee the resulting deluge of bugs, then that seems like a reasonable use of debconf. Doing that might even flush out some existing bugs in the way some packages deal with daemons being started during an install, thus contributing to the quality of Debian generally. Seems like a lot of effort though, and I cannot imagine any of the whingers actually taking on the task. 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 pgp2QOhhH5vW7.pgp Description: PGP signature
Re: jessie release goals
On Mon, May 13, 2013 at 5:20 PM, Philip Hands wrote: It looks to me as though your apache and rsyncd suggestions are straying into the forbidden territory of using debconf as a registry. I didn't advocate storing such info in debconf. PS: I'm subscribed. -- 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/CAKTje6EsUovG81CkL9zB1LE3ec56vK7E=onn_whn3setvu0...@mail.gmail.com
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
Marco d'Itri m...@linux.it writes: On May 13, Holger Levsen hol...@layer-acht.org wrote: actually, while it has been brought up as a theoretical/wrong argument, that we cannot switch our linux installation ship with $this init system, while the kfreebsd port uses $that init system, I'd say nobody is seriously saying this now. We will support several init systems anyway. At least for jessie+X. Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev depend on either upstart or systemd. I would rather not be the one who will choose which one of them, so I hope that we will get to a consensus about this. Do you really think that upstart is a viable option? No matter what the technical merits, the inevitable flame war regarding copyright assignment seems very likely to render upstart a non-starter as an essential element of Debian. 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 pgpkiOv9ltmJL.pgp Description: PGP signature
Re: jessie release goals
On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote: ]] Vincent Lefevre I agree for these services (though Apache is useless after just being installed, as one just has a dummy web page). So useful, since you can then put files into the docroot and serve those files. But the admin needs to do something (e.g. put these files) after installing Apache. *Just after* Apache is installed, it is useless and it takes useless resources. It is probably not much a problem at this time since one may think that something will shortly be done to have useful pages, but such pages could also disappear in the future. Let me explain with more details: My only use of Apache on some machine is because of sensord. But it may happen that in a few months, I would no longer need sensord and may remove the package. In this case, it would make sense to stop the Apache daemon automatically in order to free some resources. This would be dependencies between services... (An analogy to your example could be an imap server being useless, since there's no mail to be fetched on a freshly installed server.) Perhaps, if the machine is not configured yet to receive mail (even locally). Then, see above... But not for postfix, which can reject mail by default without an initial configuration. Since it is not working by default, and loses mail, the daemon shouldn't be enabled by default. IIRC, postfix defaults to local mail only, listening on localhost only, so how it would reject mail by default, I'm not sure? According to the history of my config files, this was not the case on my Debian machine where I installed postfix. This may depend on the answers to some questions at install time (there is something like that for exim, I don't remember for postfix), but in such a case, I answered according to my use of postfix. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130513104609.gh26...@ioooi.vinc17.net
Re: jessie release goals
]] Vincent Lefevre On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote: ]] Vincent Lefevre But not for postfix, which can reject mail by default without an initial configuration. Since it is not working by default, and loses mail, the daemon shouldn't be enabled by default. IIRC, postfix defaults to local mail only, listening on localhost only, so how it would reject mail by default, I'm not sure? According to the history of my config files, this was not the case on my Debian machine where I installed postfix. This may depend on the answers to some questions at install time (there is something like that for exim, I don't remember for postfix), but in such a case, I answered according to my use of postfix. So you configured it through debconf, in a non-default way, and it refused mails according to how you configured it. I don't see what the postfix package should have done differently here. It would be more confusing for it to ask you about how it should handle mail and then just not handle mail for you after that. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zjvz87p4@qurzaw.varnish-software.com
Re: jessie release goals
On 2013-05-07 23:54:36 +0800, Thomas Goirand wrote: On 05/07/2013 04:00 AM, Vincent Lefevre wrote: This can be fine for some daemons/servers. For instance, for a web server, displaying a default web page is harmless. But what about a mail server? Any default config would probably lead to loss of mail if things like virtual alias domains are used. If you set your MX pointer before setting-up your mail server, then it's your fault if you loose some mails, and not at all the fault of the way postfix (for example) is packaged. In one case, this was after a full reinstallation of the server (not Debian, but the problem would be the same). I didn't have the choice. And removing the MX pointer several hours before the reinstallation would also have resulted in loss of mail. The cleanest solution, IMHO, would have been to use iptables to prevent SMTP connections before installing postfix, but for someone who doesn't know iptables yet, that's more complex than having the control on whether the daemon is started or not at install time. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130513110857.gi26...@ioooi.vinc17.net
Re: jessie release goals
Vincent Lefevre vinc...@vinc17.net writes: On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote: ]] Vincent Lefevre I agree for these services (though Apache is useless after just being installed, as one just has a dummy web page). So useful, since you can then put files into the docroot and serve those files. But the admin needs to do something (e.g. put these files) after installing Apache. *Just after* Apache is installed, it is useless and it takes useless resources. It is probably not much a problem at this time since one may think that something will shortly be done to have useful pages, but such pages could also disappear in the future. Let me explain with more details: My only use of Apache on some machine is because of sensord. But it may happen that in a few months, I would no longer need sensord and may remove the package. In this case, it would make sense to stop the Apache daemon automatically in order to free some resources. This would be dependencies between services... If that's what you want it would make more sense to remove the apache package to free even more resources. 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 pgpx6cv38TAVt.pgp Description: PGP signature
Re: jessie release goals
On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote: ]] Vincent Lefevre On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote: ]] Vincent Lefevre But not for postfix, which can reject mail by default without an initial configuration. Since it is not working by default, and loses mail, the daemon shouldn't be enabled by default. IIRC, postfix defaults to local mail only, listening on localhost only, so how it would reject mail by default, I'm not sure? According to the history of my config files, this was not the case on my Debian machine where I installed postfix. This may depend on the answers to some questions at install time (there is something like that for exim, I don't remember for postfix), but in such a case, I answered according to my use of postfix. So you configured it through debconf, in a non-default way, and it refused mails according to how you configured it. AFAIK, debconf is the *only* choice. Perhaps debconf has a way to use the default configuration, but that's also bad (and even worse, since more mail could be rejected) as by default, postfix listens on all interfaces: inet_interfaces (default: all) I don't see what the postfix package should have done differently here. It would be more confusing for it to ask you about how it should handle mail and then just not handle mail for you after that. It could have asked: Do you want me to start the postfix daemon now, or wait after some additional manual configuration? Do this or that to start the daemon. Answering something like local mail would be wrong, as a manual update of the config file from, say, loopback-only to all could be overwritten after an upgrade of the package. I don't know about postfix, but something like that happened to me with exim. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130513112012.gj26...@ioooi.vinc17.net
Re: jessie release goals
]] Vincent Lefevre On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote: ]] Vincent Lefevre On 2013-05-12 18:51:10 +0200, Tollef Fog Heen wrote: ]] Vincent Lefevre But not for postfix, which can reject mail by default without an initial configuration. Since it is not working by default, and loses mail, the daemon shouldn't be enabled by default. IIRC, postfix defaults to local mail only, listening on localhost only, so how it would reject mail by default, I'm not sure? According to the history of my config files, this was not the case on my Debian machine where I installed postfix. This may depend on the answers to some questions at install time (there is something like that for exim, I don't remember for postfix), but in such a case, I answered according to my use of postfix. So you configured it through debconf, in a non-default way, and it refused mails according to how you configured it. AFAIK, debconf is the *only* choice. Perhaps debconf has a way to use the default configuration, but that's also bad (and even worse, since more mail could be rejected) as by default, postfix listens on all interfaces: No, it does not, since the default configuration («Local only») sets inet_interfaces = loopback-only And re debconf, the way to use the default configuration the first time around is to just press enter. Or set the debconf frontend to noninteractive. I don't see what the postfix package should have done differently here. It would be more confusing for it to ask you about how it should handle mail and then just not handle mail for you after that. It could have asked: Do you want me to start the postfix daemon now, or wait after some additional manual configuration? Do this or that to start the daemon. If you want to do that, use policy-rc.d, or heck, do what you should do anyway: run an ip filter that rejects any incoming services except those you want to expose to the world. Answering something like local mail would be wrong, as a manual update of the config file from, say, loopback-only to all could be overwritten after an upgrade of the package. I don't know about postfix, but something like that happened to me with exim. If that happens without asking the admin, that's an RC bug. AFAICS, the postfix postinst handles the case of pre-existing configuration files completely fine. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878v3jdsik@qurzaw.varnish-software.com
Re: jessie release goals
On 2013-05-13 12:02:31 +0100, Philip Hands wrote: Vincent Lefevre vinc...@vinc17.net writes: My only use of Apache on some machine is because of sensord. But it may happen that in a few months, I would no longer need sensord and may remove the package. In this case, it would make sense to stop the Apache daemon automatically in order to free some resources. This would be dependencies between services... If that's what you want it would make more sense to remove the apache package to free even more resources. Yes, but similarly, there's no way to do this automatically. There's also a problem that the man pages are in the package: $ dpkg -L apache2.2-common | grep /man/ /usr/share/man/man8 /usr/share/man/man8/apache2.8.gz /usr/share/man/man8/a2ensite.8.gz /usr/share/man/man8/apache2ctl.8.gz /usr/share/man/man8/a2enmod.8.gz /usr/share/man/man8/apachectl.8.gz /usr/share/man/man8/a2dissite.8.gz /usr/share/man/man8/a2dismod.8.gz There's no way to read this documentation first or keep it (this is useful if one wants to write/maintain a script that tests whether apache2 is available or not, for instance). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130513113330.gk26...@ioooi.vinc17.net
Re: jessie release goals
On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote: ]] Vincent Lefevre On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote: So you configured it through debconf, in a non-default way, and it refused mails according to how you configured it. AFAIK, debconf is the *only* choice. Perhaps debconf has a way to use the default configuration, but that's also bad (and even worse, since more mail could be rejected) as by default, postfix listens on all interfaces: No, it does not, since the default configuration («Local only») sets This is not the default configuration, just the default choice (it is not written Default configuration). What is written in the dialog is confusing. The mail server configuration type that best meets [my] needs is clearly Internet Site. Instead of best meets your needs, it should say before additional configuration (or it could say both). Also at this time, the user is not yet aware that the config will be incomplete, and he could choose Internet Site thinking that everything will be fine at the end of the debconf questions. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- 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/20130513120214.gl26...@ioooi.vinc17.net
Re: jessie release goals
]] Vincent Lefevre On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote: ]] Vincent Lefevre On 2013-05-13 13:01:27 +0200, Tollef Fog Heen wrote: So you configured it through debconf, in a non-default way, and it refused mails according to how you configured it. AFAIK, debconf is the *only* choice. Perhaps debconf has a way to use the default configuration, but that's also bad (and even worse, since more mail could be rejected) as by default, postfix listens on all interfaces: No, it does not, since the default configuration («Local only») sets This is not the default configuration, just the default choice (it is not written Default configuration). I'm looking forward to an essay on the differences between «the configuration you end with when selecting the default choice» and «the default configuration». -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874ne7dppj@qurzaw.varnish-software.com
Re: Merging / and /usr (was: jessie release goals)
On Fri, May 10, 2013 at 10:07:18AM +0200, Marc Haber wrote:
On Thu, 9 May 2013 18:17:29 +0200, m...@linux.it (Marco d'Itri) wrote:
On May 09, Bernhard R. Link brl...@debian.org wrote:
Or in other words: to make essential functionality not available if
/usr is broken.
Again: this is not we are discussing. Essential functionality is moving
to /usr anyway
Which is a really really bad thing. Some anonymous upstream is forcing
us to decrease the reliability of our systems. I really hate that
idea.
Don't we all. But it has already hapened.
Having a seperate / means you have an instant rescue image that has
just the right kernel and tools you need to repair the rest of your
system.
OK, so you could have an even *smaller* / with a *real* independent
rescue image like grml in /boot.
Having the rescue image _this_ independent is not really desireable
since one would probably have to deal with outdated or non-existing
rescue tools in the independent image while the correct software in
the correct version is on the system's own / file system.
Or you would have a known working and good version of tools while the
system (being unstable) might have any number of bugs in them.
Note: The rescue image could be dynamically generated on updates or
come as prebuild images. Or you could have both. And a stable and
latest flavour on top. The rescue image will be no more out of date
than any other package in debian.
You also have one small filesystem with all the important
stuff like /etc in it while the boring large distro stuff is in
another partition. You also have a partition border between
most of the random stuff and the important stuff.
Indeed, if the content of /{bin,sbin,lib} is moved to /usr you can have
a small filesystem with all the important stuff like /etc in it and the
boring large distro stuff (like 100 MB of kernel modules for each
kernel, currently in /lib) in another partition.
But I'll have the fsck version that is guaranteed to fit my /usr file
system in the big /usr file system, so I'll be forced to use an fsck
from a rescue image which might not be the current one, possibly
causing even more damage.
Greetings
Marc
Fsck is in the initramfs (added combined with the mnount /usr patches)
so you can fix your /usr and even your / from there already.
Has anyone actualy compiled data about fsck problems respective to
filesystem size? I can't remember EVER having a fsck problem with /usr
ever since I switched to keeping it read-only. And that was somewhere
in early 2.4.x times.
MfG
Goswin
--
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/20130513123820.GH8366@frosties
Re: jessie release goals
On 05/13/2013 08:33 AM, Tollef Fog Heen wrote: ]] Vincent Lefevre On 2013-05-13 13:32:51 +0200, Tollef Fog Heen wrote: No, it does not, since the default configuration («Local only») sets This is not the default configuration, just the default choice (it is not written Default configuration). I'm looking forward to an essay on the differences between «the configuration you end with when selecting the default choice» and «the default configuration». It seems obvious to me. The default configuration is the one you get when not specifying any configuration at all. (E.g. when you omit a config file entirely, or include only a blank config file, or a config file with only comments.) The configuration you get when specifying the default choice is whatever configuration the default choice defines, which may very well not be the same as not specifying any configuration at all. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- 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/5190e121.7000...@fastmail.fm
Re: Merging / and /usr (was: jessie release goals)
On Thu, May 09, 2013 at 12:03:43PM +0100, Roger Leigh wrote: On Thu, May 09, 2013 at 11:50:31AM +0200, Goswin von Brederlow wrote: If you make /usr a symlink to / then there will be to distinct paths to each file and that will confuse dpkg. The first problem that comes to mind is package A containing /bin/foo and package B containing /usr/bin/foo. Dpkg will happily install both without noticing the file overwrite conflict. Or package A 1.0 contains /bin/foo and package A 1.1 contains /usr/bin/foo. IIrc then dpkg will unpack A 1.1 (overwrite /bin/foo with /usr/bin/foo) and then remove /bin/foo. Leaving you without /usr/bin/foo. This is all very true. Once we have /usr mounted in the initramfs, we can correct such duplicate paths to prevent this; packages which provide a binary in /bin and a symlink in /usr/bin to make the binary available in early boot can simply move the binary back to /usr--it will be guaranteed to be available in early boot. Since two different paths would then be effectively equivalent, maybe we might also need dpkg itself to be aware of this so that it will refuse to overwrite, in addition to a manual audit of the existing paths. My current work on this is at http://anonscm.debian.org/gitweb/?p=users/rleigh/initramfs-tools.git;a=shortlog;h=refs/heads/usrmount It works for mounting a local /usr; testing NFS and NFS/local combinations is on my TODO list for tonight. This still needs further cleanup and testing. It will be ready for wider testing in a few days. It also needs a patch to util-linux so it doesn't try to fsck a mounted /usr at boot. Regards, Roger I totaly support your initramfs patches to mount /usr. But that is a long way away from the merge / + /usr. Which I don't feel has a good solution yet. All the proposals so far have major faults leading to corrupted and even unbootable systems. As I see it the way to go is: 1) mount /usr in initramfs now so we simply don't have to care wether it is seperate or not. You are well on the way there. 2) possibly remove patches that put stuff in / with compat symlinks in /usr/ provided they conflict with an older initramfs. Might be good to wait a release before doing that so we don't add tons of dependencies on the intramfs version. 3) wait a release (unless we do that for 2) 4) remove all / instead of /usr patches, remove / + /usr duplicates 5) wait a release 6) consider the / + /usr situation again That would give at least 4 years before merging / and /usr becomes an issue. I think talk about doing this for jessie is seriously premature given the solutions for merging proposed so far. MfG Goswin -- 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/20130513125102.GI8366@frosties
Re: jessie release goals
Vincent Lefevre vinc...@vinc17.net writes: On 2013-05-13 12:02:31 +0100, Philip Hands wrote: Vincent Lefevre vinc...@vinc17.net writes: My only use of Apache on some machine is because of sensord. But it may happen that in a few months, I would no longer need sensord and may remove the package. In this case, it would make sense to stop the Apache daemon automatically in order to free some resources. This would be dependencies between services... If that's what you want it would make more sense to remove the apache package to free even more resources. Yes, but similarly, there's no way to do this automatically. [regarding automation, see the last couple of paragraphs below] There's also a problem that the man pages are in the package: $ dpkg -L apache2.2-common | grep /man/ /usr/share/man/man8 /usr/share/man/man8/apache2.8.gz /usr/share/man/man8/a2ensite.8.gz /usr/share/man/man8/apache2ctl.8.gz /usr/share/man/man8/a2enmod.8.gz /usr/share/man/man8/apachectl.8.gz /usr/share/man/man8/a2dissite.8.gz /usr/share/man/man8/a2dismod.8.gz I suppose you could file a wishlist bug requesting a -doc package, but I'd expect that to be marked wontfix, since the effort is probably not justified by the size of audience that would appreciate such a change. There's no way to read this documentation first or keep it (this is useful if one wants to write/maintain a script that tests whether apache2 is available or not, for instance). no way is a bit strong. There are several ways of getting at the man pages without installing apache. If you're OK with it just being the manpage from current testing: http://man.cx/apache2(8) If you must see the man page from a particular package: dget apache2.2-common mkdir -p ./tmp/apache2.2-common dpkg -X apache2.2-common_2.2.22-13_amd64.deb ./tmp/apache2.2-common then if you want just brief access: man -l tmp/apache2.2-common/usr/share/man/man8/apache2.8.gz or for longer term, create a ~/man dir, say, add that to your MANPATH and move the man pages into place -- all possible without root access, and certainly without risking running daemons or other side effects that might arise from a mismatch between your expectations and reality. Returning to your original point, it's not even as though it's hard to disable an installed service on Debian. I normally do that by stopping the service and then adding something like this as the second line of the init.d script: exit 0 # disabled rather than removed in order to keep the man pages around -- pgh 2013-05-23 which (particularly when committed to etckeeper with a similar message) makes sure that the reason for deviating from the norm is clear to others (and to my forgetful self) in future. Since the init.d script is a conffile, you get reminded of your decision to disable the service on every upgrade, which often saves a lot of head scratching. You seem to want the system to guess what's in your head, which may be fine some of the time, but if you later install another package that, unknown to you, has acquired some sort of web interface in the latest version, then presumably that would result in the system guessing (wrongly) that apache should be automatically re-enabled for you. I can do without surprises like that. Actually, I just installed sensord to see what you were getting at with your claim that you wanted apache to stop running if you removed sensord. I see no plumbing in sensord that is intended to provoke apache to run, or even help apache know that there's anything for it to publish (so no apache.conf snippet, no automatically created directory for the RRD images). The postrm script only does an update-rc.d remove on purge, and certainly does not have anything to remove RRD graphs, so how apache is supposed to guess that you don't want to publish them any more just because you removed a vaguely related package is a bit of a puzzle. What exactly are you expecting to happen in this sensord removal scenario that is supposed to provoke Apache to automatically decide that you don't need it running any more? Cheers, Phi. -- |)| 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 pgpZJLdXWTYen.pgp Description: PGP signature
Re: systemd^wfoo on linux, bar on bsd,so what (Re: /bin/sh (was Re: jessie release goals)
On 2013-05-12 21:31, m...@linux.it wrote: Maybe kfreebsd will do, but as I explained at FOSDEM I plan to make udev depend on either upstart or systemd. do you have a link to a presentation, blog post, or whatever explaining the rationale behind this? i didn't found anything on FOSDEM website thanks -- 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/839db3167af8c830fff68c3f25b87...@zumbi.com.ar
Re: jessie release goals
On Mon, May 13, 2013 at 7:33 PM, Vincent Lefevre wrote: Yes, but similarly, there's no way to do this automatically. apt-get autoremove is automatic, or if you want that earlier you could remove sensord using aptitude which will automatically remove unused dependencies. There's also a problem that the man pages are in the package: ... There's no way to read this documentation first or keep it (this is useful if one wants to write/maintain a script that tests whether apache2 is available or not, for instance). You could file a wishlist bug asking for it to be split out into apache2-man, or use the apache2-doc package. -- 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/CAKTje6GskYUiRVbdPS=Z77yVidC-2URVGugBd=hnramqaut...@mail.gmail.com
