Re: Jessie Release Date: 2015-04-25

[Forgot to send it to the list.] On 06.04.2015 00:21, Russ Allbery wrote: Alexander Cherepanov writes: At the time of posting, there was a bug for unrar in this list. I think this one -- https://bugs.debian.org/774171 , it was fixed the next day. Do I understand it right: a bug in a non-fr

Re: Jessie Release Date: 2015-04-25

Alexander Cherepanov writes: > At the time of posting, there was a bug for unrar in this list. I think > this one -- https://bugs.debian.org/774171 , it was fixed the next day. > Do I understand it right: a bug in a non-free package could be > release-critical for Debian? I thought non-free area

Re: Jessie Release Date: 2015-04-25

On 2015-03-31 21:58, Niels Thykier wrote: * unfixed RC bugs in key packages, please see [1]. [1] https://udd.debian.org/bugs/?release=jessie_and_sid&merged=ign&keypackages=only&fnewerval=7&flastmodval=7&rc=1&ctags=1&cdeferred=1&sortby=id&sorto=asc&format=html#results At the time of postin

Re: Jessie Release

Balder García García writes: > Hi, I only want to know when will jessie released , I am waitting for > SteamOS final version, but first you must launch jessie, thanks for your > time! The Debian project doesn't commit to specific release dates ahead of time. Rather, we have a set of things that

Re: Jessie Release

On 29/01/15 09:32, Balder García García wrote: > Hi, I only want to know when will jessie released , I am waitting for > SteamOS final version, but first you must launch jessie, thanks for your > time! // Hola, solo quería saber cuando se lanzará la versión estable de > Debian Jessie, estoy pendi

Re: jessie release goal: verbose build logs

Stéphane Glondu writes: >> http://lindi.iki.fi/lindi/structured-buildlogs/logs/hello-2.6-1_amd64.build > > How do you do that exactly? Can't remember the exact details but you can get the script with git clone http://lindi.iki.fi/lindi/git/structured-buildlogs.git/ -Timo -- To UNSUBSCRIBE, e

Re: jessie release goal: verbose build logs

Le 14/06/2013 15:19, Timo Juhani Lindfors a écrit : >> This doesn't really help when trying to diagnose things, and even for >> successful >> builds it's valuable to have the complete build log, including the parts how >> the >> upstream build system is called from the Debian packaging. > > This

Re: Jessie release goal: DNSSEC as default recursive resolver

On Sun, Oct 27, 2013 at 12:08 AM, Thomas Goirand wrote: > I'd find it very nice if we had, by default, DNSSEC resolving in Debian, I've been running this configuration for a while (using unbound on my laptop) and during my recent travels in Europe I discovered networks that are problematic in som

Re: Jessie release goal: DNSSEC as default recursive resolver

Op 03-11-13 19:05, Marko Randjelovic schreef: > On Sun, 3 Nov 2013 12:32:40 +0100 > Bastian Blank wrote: > >> On Sun, Nov 03, 2013 at 11:15:36AM +0100, Marko Randjelovic wrote: >>> Just to say we should not expect to much from DNSSEC because DNSSEC is >>> centralized: >> >> Could you explain the

Re: Jessie release goal: DNSSEC as default recursive resolver

Op 03-11-13 16:21, Thomas Goirand schreef: > On 10/30/2013 10:56 PM, Wouter Verhelst wrote: >> At any rate, my main point was that we should not default to using a >> system-local recursive resolver which ignores the ISP-provided one, just >> because that's the "easiest" way to do DNSSEC these days

Re: Jessie release goal: DNSSEC as default recursive resolver

That's a just a load of crap (decentralize everything, yeah!) and has nothing to do with DNSSEC really. The problem of P2P DNS and why it can't work was already explained several times, f.e. read here for nice summary from Paul Wouters: https://nohats.ca/wordpress/blog/2012/04/09/you-cant-p2p-the

Re: Jessie release goal: DNSSEC as default recursive resolver

On Sun, 3 Nov 2013 12:32:40 +0100 Bastian Blank wrote: > On Sun, Nov 03, 2013 at 11:15:36AM +0100, Marko Randjelovic wrote: > > Just to say we should not expect to much from DNSSEC because DNSSEC is > > centralized: > > Could you explain the problems you see a bit more verbose? > > > https://g

Re: Jessie release goal: DNSSEC as default recursive resolver

On 10/30/2013 10:56 PM, Wouter Verhelst wrote: > At any rate, my main point was that we should not default to using a > system-local recursive resolver which ignores the ISP-provided one, just > because that's the "easiest" way to do DNSSEC these days. Correct, that's not the *only* reason! :) An

Re: Jessie release goal: DNSSEC as default recursive resolver

On Sun, Nov 03, 2013 at 11:15:36AM +0100, Marko Randjelovic wrote: > Just to say we should not expect to much from DNSSEC because DNSSEC is > centralized: Could you explain the problems you see a bit more verbose? > https://gnunet.org/uva2013 This is just an announcement and nothing about DNSSE

Re: Jessie release goal: DNSSEC as default recursive resolver

Just to say we should not expect to much from DNSSEC because DNSSEC is centralized: https://gnunet.org/uva2013 -- http://mr.flossdaily.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive:

Re: Jessie release goal: DNSSEC as default recursive resolver

Op 29-10-13 17:35, Ian Jackson schreef: > Wouter Verhelst writes ("Re: Jessie release goal: DNSSEC as default recursive > resolver"): >> There is nothing in DNSSEC which makes it inherently incompatible with >> using DNS forwarders. Talking to the root DNS servers is

Re: Jessie release goal: DNSSEC as default recursive resolver

On Tue, Oct 29, 2013, at 17:35, Ian Jackson wrote: > Wouter Verhelst writes ("Re: Jessie release goal: DNSSEC as default > recursive resolver"): > > There is nothing in DNSSEC which makes it inherently incompatible with > > using DNS forwarders. Talking to the roo

Re: Jessie release goal: DNSSEC as default recursive resolver

Wouter Verhelst writes ("Re: Jessie release goal: DNSSEC as default recursive resolver"): > There is nothing in DNSSEC which makes it inherently incompatible with > using DNS forwarders. Talking to the root DNS servers is fun and all, > but there's really no good reason w

Re: Jessie release goal: DNSSEC as default recursive resolver

On 2013-10-29 22:03:59 (+0800), Thomas Goirand wrote: > On 10/29/2013 03:42 AM, Wouter Verhelst wrote: > > There's also no reason why you _need_ a local DNS server to be able to > > do DNSSEC resolving; you can theoretically use a stub resolver (though > > I'm not sure if there's a stub resolver i

Re: Jessie release goal: DNSSEC as default recursive resolver

On 10/29/2013 03:42 AM, Wouter Verhelst wrote: > Op 28-10-13 19:28, Thomas Goirand schreef: >> So, as per the replies we've read, it seems that the only way to >> implement DNSSEC would be to first check if it works, and if it doesn't, >> fallback to the locally provided recursive DNS server. > >

Re: Jessie release goal: DNSSEC as default recursive resolver

Op 28-10-13 19:28, Thomas Goirand schreef: > So, as per the replies we've read, it seems that the only way to > implement DNSSEC would be to first check if it works, and if it doesn't, > fallback to the locally provided recursive DNS server. This feels upside down to me. There is nothing in DNSSE

Re: Jessie release goal: DNSSEC as default recursive resolver

> So, as per the replies we've read, it seems that the only way to > implement DNSSEC would be to first check if it works, and if it doesn't, > fallback to the locally provided recursive DNS server. I still think a switch on/off (whatever the default) should be considered because if anyone decides

Re: Jessie release goal: DNSSEC as default recursive resolver

On 10/28/2013 10:29 PM, Adam Borowski wrote: > On Mon, Oct 28, 2013 at 01:01:13PM +0100, Thijs Kinkhorst wrote: >> On Sat, October 26, 2013 18:52, Ondřej Surý wrote: >>> we can adopt dnssec-trigger >> >> I think it's indeed very important that a default install uses the DHCP >> provided DNS-serve

Re: Jessie release goal: DNSSEC as default recursive resolver

On Mon, Oct 28, 2013 at 01:01:13PM +0100, Thijs Kinkhorst wrote: > On Sat, October 26, 2013 18:52, Ondřej Surý wrote: > > we can adopt dnssec-trigger > > I think it's indeed very important that a default install uses the DHCP > provided DNS-servers or locally configured resolvers, because in man

Re: Jessie release goal: DNSSEC as default recursive resolver

On Sat, October 26, 2013 18:52, Ondřej Surý wrote: >> The safe default is still to rely on the organizational DNS resolvers as >> provided by DHCP or local manual configuration. > > we can adopt dnssec-trigger > (https://www.nlnetlabs.nl/projects/dnssec-trigger/) for such scenarios. I think it's

Re: Jessie release goal: DNSSEC as default recursive resolver

On Sat, Oct 26, 2013 at 08:57:54PM +0200, Marco d'Itri wrote: > On Oct 26, Thomas Goirand wrote: > > I'd find it very nice if we had, by default, DNSSEC resolving in Debian, > > at least in the "default" configuration (whatever that means). By this, > I agree with the general principle, but I do n

Re: Jessie release goal: DNSSEC as default recursive resolver

On 10/27/2013 01:52 AM, Ondřej Surý wrote: > I still think that the Debian should be a technology leader. > Conservative, but technology leader. And DNSSEC adoption would help the > case. > > Also the DSA has already enabled DANE (DNSSEC validated TLS certs) on > Debian's MTAs, the postfix 2.11 wi

Re: Jessie release goal: DNSSEC as default recursive resolver

> On Sat, Oct 26, 2013, at 18:58, Kevin Chadwick wrote: > > I believe the reliability (DOS) issues that DNSSEC imposes coupled with > > Please, not this again. If you say DNSSEC DOS issue, you must state all > the other issues that DNS has. > Not really, the security issues are already catered f

Re: Jessie release goal: DNSSEC as default recursive resolver

On Oct 26, Thomas Goirand wrote: > I'd find it very nice if we had, by default, DNSSEC resolving in Debian, > at least in the "default" configuration (whatever that means). By this, I agree with the general principle, but I do not think that a recursive resolver should be installed by default on

Re: Jessie release goal: DNSSEC as default recursive resolver

Hi Russ, On Sat, Oct 26, 2013, at 18:20, Russ Allbery wrote: > Thomas Goirand writes: > > > If this means installing a recursive DNS resolver by default (unbound > > pops to my mind, since it has the feature by default), I'd say be it, > > though probably that is more of an open question, and an

Re: Jessie release goal: DNSSEC as default recursive resolver

On Sat, Oct 26, 2013, at 18:58, Kevin Chadwick wrote: > I believe the reliability (DOS) issues that DNSSEC imposes coupled with Please, not this again. If you say DNSSEC DOS issue, you must state all the other issues that DNS has. > the low level of adoption It's certainly more adopted than IPv6

Re: Jessie release goal: DNSSEC as default recursive resolver

> If I'm not mistaking (please correct me), Fedora has the feature, and > it's been a long time they do. FreeBSD as well (they have unbound in the > default installer). OpenBSD also removed bind and switched to unbound > (or at least is planning on doing it, I'm not sure). Debian shouldn't be > lef

Re: Jessie release goal: DNSSEC as default recursive resolver

Thomas Goirand writes: > If this means installing a recursive DNS resolver by default (unbound > pops to my mind, since it has the feature by default), I'd say be it, > though probably that is more of an open question, and an implementation > details. I personally wouldn't mind at all if the Debi

Re: jessie release goal: verbose build logs

(Resending; first copy failed due to MIME non-8-bit-cleanliness damage.) Joey Hess writes ("Re: jessie release goal: verbose build logs"): > I've attached a simple proof of concept you can try it out with building > your own packages. For example: > >dpkg-build

Re: jessie release goal: verbose build logs

On Wed, 14 Aug 2013, Guillem Jover wrote: > Definitely, and planned (#476221) to be fixed pretty soon. But the > problem is that this can not be enabled by default (only through an > option initially, until the upper layers rely on a dpkg-buildpackage > with such option and use it) because the diff

Re: jessie release goal: verbose build logs

Hi, On Tue, 13 Aug 2013, Russ Allbery wrote: > debuild, pbuilder, and related packages currently use > ../__.build for this output. Maybe the > lower-level build architecture should take over maintaining that log file > instead and those tools should be modified to assume that's already > happeni

Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

Am 13.08.2013 21:10, schrieb Adam Borowski: > So I guess it would be best to put the threshold at automated vs > human-supervised builds. What about setting the flag per-tool rather than > per-deployment? For example, pbuilder would default to verbose (as you > can't restart builds) while dpkg-bu

Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

Dmitrijs Ledkovs wrote: > We have build log analyzers running for the build logs. Checking heuristically for problems you know about does not help find the class of problems you don't know about yet. > How about a new DEB_BUILD_OPTION="silent" which opts into silent build > log? Does that sound r

Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

Adam Borowski angband.pl> writes: > Non-spammy builds are better for builds done by a human. No. They’re better for builds done by the developers of the upstream software on their own systems where they know what they’re doing. And even then, it’s a big maybe. Every other human is a packager

Re: jessie release goal: verbose build logs

Hi! On Tue, 2013-08-13 at 22:08:34 +0200, Joey Hess wrote: > At DebConf, Enrico came up with this idea: When the package is building > with the display going to the console, something could intercept the > stdout and convert \n to \r. Let stderr through untouched. The result > would be a build tha

Re: jessie release goal: verbose build logs

Hi! On Tue, 2013-08-13 at 15:16:49 -0700, Russ Allbery wrote: > Joey Hess writes: > > Also it could save the whole log to someplace when minimizing the > > console output, to refer back to. Perhaps ../$package_$version.buildlog > > (which gets a step closer to including that in the dsc and upload

Re: jessie release goal: verbose build logs

Joey Hess writes: > Joey Hess wrote: >> (The implementation needs to be improved; it should read both stdout >> and stderr and multiplex them properly. And it should check if stdout >> is not to a TTY, and if so avoid munging the build log output. The only >> other problem is that `make` outputs

Re: jessie release goal: verbose build logs

Joey Hess wrote: > (The implementation needs to be improved; it should read both stdout and > stderr and multiplex them properly. And it should check if stdout is not > to a TTY, and if so avoid munging the build log output. The only other > problem is that `make` outputs the lines it runs to stder

Re: jessie release goal: verbose build logs

Joey Hess wrote: > Making all builds verbose by default has both advantages and > disadvantages. > > The disadvantages include making builds possibly so noisy that when one > runs them during daily work, once ignores all output. Including > important compiler warnings. > > (This is the same reaso

Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

On Tue, Aug 13, 2013 at 08:30:16PM +0200, Dmitrijs Ledkovs wrote: > In controlled environments, one doesn't get to re-run a build, as the > instances are stripped-down and destroyed on build failure E.g. all > the jenkins instances running debian package builds, PPAs, > auto-package-tests, automate

Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

On 13 August 2013 19:59, Julien Cristau wrote: > [why oh why are you breaking threading?] > > On Tue, Aug 13, 2013 at 19:51:52 +0200, Dmitrijs Ledkovs wrote: > >> We have build log analyzers running for the build logs. And the >> important compiler warnings (errors) fail the build. >> If we make t

Re: Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

[why oh why are you breaking threading?] On Tue, Aug 13, 2013 at 19:51:52 +0200, Dmitrijs Ledkovs wrote: > We have build log analyzers running for the build logs. And the > important compiler warnings (errors) fail the build. > If we make this opt-in, we will fail to achieve this goal. As when on

Opt-out or Opt-in vebose build logs Re: jessie release goal: verbose build logs

On 13 August 2013 14:36, Joey Hess wrote: > Dmitrijs Ledkovs wrote: >> Is there any reason this hasn't been applied yet? >> Can I NMU this, as debhelper is marked as LowNMU package. > > Not for reasons such as allowing patches like this. > Ok. > Making all builds verbose by default has both adva

Re: jessie release goal: verbose build logs

Dmitrijs Ledkovs wrote: > Is there any reason this hasn't been applied yet? > Can I NMU this, as debhelper is marked as LowNMU package. Not for reasons such as allowing patches like this. Making all builds verbose by default has both advantages and disadvantages. The disadvantages include making

Re: jessie release goal: verbose build logs

On 17 June 2013 23:58, Dmitrijs Ledkovs wrote: > tags 680686 patch > thanks > > On 14 June 2013 12:35, Matthias Klose wrote: >> >> - Fix debhelper not passing --disable-silent-rules by default. >>#680686 >>I think cdbs already does this. > > Patch attached for autoconf dh build system. c

Re: jessie release goal: verbose build logs

This is now documented at http://wiki.debian.org/ReleaseGoals/VerboseBuildLogs -- 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/51d6afef.8060...@debian.org

Re: jessie release goal: verbose build logs

> On 14/06/2013 13:49, Wookey wrote: > > +++ Matthias Klose [2013-06-14 13:35 +0200]: > >> Much more often than I do like it, I see bug reports for the toolchain just > >> pointing to a build log. Then looking at the build log, you often just see > >> > >> CC ... > >> CCLD ... (sometimes even co

Re: jessie release goal: verbose build logs

On Fri, 14 Jun 2013 14:14:39 +0200, Jakub Wilk wrote: > >- File and track issues for packages not enabling verbose builds. > >https://buildd.debian.org/~brlink/bytag/W-compiler-flags-hidden.html > > I attached a dd-list for the lazy. But note that "false positives > are possible, especially when

Re: jessie release goal: verbose build logs

On Fri, Jun 14, 2013 at 14:14:39 +0200, Jakub Wilk wrote: > Debian X Strike Force [long list] Working on fixing these (adding --disable-silent-rules) as I update them. Will take a while though... Cheers, Julien signature.asc Description: Digital signature

Re: jessie release goal: verbose build logs

* Matthias Klose [130614 13:36]: > Verbose build logs allow to analyse package builds and give hints to more > issues > regarding the build, especially for the hardening flags. The lintian > hardening > checks are incomplete, because they rely on the inspection of the generated > binaries, whic

Re: jessie release goal: verbose build logs

Hi I agree we need good build logs. On 14-06-13 14:14, Jakub Wilk wrote: > * Matthias Klose , 2013-06-14, 13:35: >> So I'm proposing for jessie: >> >> - File and track issues for packages not enabling verbose builds. >> https://buildd.debian.org/~brlink/bytag/W-compiler-flags-hidden.html > > I a

Re: jessie release goal: verbose build logs

Hi, I completely agree on the goal and disable silent rules where I notice them, but: On Fri, Jun 14, 2013 at 01:35:34PM +0200, Matthias Klose wrote: > - Change Debian policy to recommend or require verbose build logs. >#628515 Change buildds. Do we have autosiging now for all buildds? TTB

Re: jessie release goal: verbose build logs

Matthias Klose writes: > This doesn't really help when trying to diagnose things, and even for > successful > builds it's valuable to have the complete build log, including the parts how > the > upstream build system is called from the Debian packaging. This is a useful goal. However, since fix

Re: jessie release goal: verbose build logs

On 2013-06-14, Jakub Wilk wrote: > I attached a dd-list for the lazy. But note that "false positives are > possible, especially when building in parallel". I've just sample-checked 4 packages I'm involved in and 100% of those four I checked was false positives. We need a better detection. But

Re: jessie release goal: verbose build logs

On 14/06/2013 13:49, Wookey wrote: > +++ Matthias Klose [2013-06-14 13:35 +0200]: >> Much more often than I do like it, I see bug reports for the toolchain just >> pointing to a build log. Then looking at the build log, you often just see >> >> CC ... >> CCLD ... (sometimes even colorized) >> [.

Re: jessie release goal: verbose build logs

Hi, On 14/06/13 13:35, Matthias Klose wrote: > Much more often than I do like it, I see bug reports for the toolchain just > pointing to a build log. Then looking at the build log, you often just see > > CC ... > CCLD ... (sometimes even colorized) > > This doesn't really help when trying to

Re: jessie release goal: verbose build logs

+++ Matthias Klose [2013-06-14 13:35 +0200]: > Much more often than I do like it, I see bug reports for the toolchain just > pointing to a build log. Then looking at the build log, you often just see > > CC ... > CCLD ... (sometimes even colorized) > > This doesn't really help when trying to d

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 kno

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 serv

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 rec

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 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'

Re: jessie release goals

On Tue, 14 May 2013 17:37:59 +0100, Wookey 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/incl

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 -- h

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 - Web: 100% accessible validated (X)HTML - Blog:

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". Wh

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 settin

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 wou

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: /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 be

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: 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 abou

Re: /bin/sh (was Re: jessie release goals)

On Tue, May 7, 2013 at 4:23 PM, Thorsten Glaser wrote: > > Andreas Beckmann 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

blhc and hardening flags (was: Re: jessie release goals)

Moritz Mühlenhoff 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.

Re: jessie release goals

Christoph Biedl 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, Sim

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

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 pos

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

Re: jessie release goals

Thomas Goirand 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

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 ima

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 t

Re: /bin/sh (was Re: jessie release goals)

Hi Thorsten On 11-05-13 20:26, Thorsten Glaser wrote: > Steve Langasek 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 wh

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* packa

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 /

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* packa

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 scre

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 o

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 discussio

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 worki

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|am

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

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

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 th

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 te

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

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 previo

  1   2   3   >