[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debian-devel-digest Digest V2011 #156



SlieiWorksw9sw9ssmzpbbbbbbbmpmm
2011.03.02. 14:47 ezt írta ( <debian-devel-digest-request@liskkkmmmmmmsķmts.debian.org>):May9p
>ö9p
> Content-Type: text/k
>'
> debian-devel-digest 😞    o  x                       'Volume 2011 : Issue 156oipjlbojijl
>m'> Today's Topics:
>   Re: potential MBF: first alternate d  [ Scott Kitterman <debian@kitterman.c ]
>   Re: Potential memory leaks reported   [ sean finney <seanius@debian.org> ]
>   Re: Potential memory leaks reported   [ Adrian von Bidder <avbidder@fortytw ]
>   Re: enable/disable flags in /etc/def  [ Tollef Fog Heen <tfheen@err.no> ]
>   Re: enable/disable flags in /etc/def  [ Stefano Zacchiroli <zack@debian.org ]
>   Re: Potential memory leaks reported   [ Wouter Verhelst <wouter@debian.org> ]
>   Re: enable/disable flags in /etc/def  [ sean finney <seanius@debian.org> ]
>   Re: enable/disable flags in /etc/def  [ sean finney <seanius@debian.org> ]
>   Re: potential MBF: first alternate d  [ Emilio Pozuelo Monfort <pochu@debia ]
>   Bug#616071: ITP: python-oejskit -- p  [ Anders Hammarquist <iko@debian.org> ]
>   Re: potential MBF: first alternate d  [ Paul Wise <pabs@debian.org> ]
>   Re: potential MBF: first alternate d  [ Holger Levsen <holger@layer-acht.or ]
>   Re: potential MBF: first alternate d  [ Jan Hauke Rahm <jhr@debian.org> ]
>   Re: potential MBF: first alternate d  [ Shachar Shemesh <shachar@debian.org ]
>   Re: enable/disable flags in /etc/def  [ Simon McVittie <smcv@debian.org> ]
>   Re: Call for projects for Google Sum  [ Adrian von Bidder <avbidder@fortytw ]
>   Re: Call for projects for Google Sum  [ Bernd Zeimetz <bernd@bzed.de> ]
>   Re: Call for projects for Google Sum  [ Cyril Brulebois <kibi@debian.org> ]
>
> Date: Tue, 1 Mar 2011 23:24:24 -0500
> From: Scott Kitterman <debian@kitterman.com>
> To: debian-devel@lists.debian.org
> Subject: Re: potential MBF: first alternate depends not available in main
> Message-Id: <201103012324.24545.debian@kitterman.com>
> Content-Type: Text/Plain;
>   charset="iso-8859-15"
> Content-Transfer-Encoding: 7bit
>
> On Monday, February 28, 2011 10:05:22 am Holger Levsen wrote:
> > Hi,
> >
> > piuparts in master-slave mode currently cannot test packages which first
> > alternate depends is not available in main, ie the secvpn package depends
> > on "adduser, bc, ssh, ppp, timeout | coreutils (>= 7.5-1), sudo" and
> > timeout is only available in lenny and etch, thus piuparts cannot test
> > secvpn in squeeze, wheezy and sid. That's a bug in piuparts.
> >
> > Another popular example is a depends on "apache | apache2"...
> >
> > So I think it's also a bug in those packages, of which there are more then
> > 100 but less than 200.
> > (To my regret I have to admit there is another bug in piuparts and
> > http://piuparts.debian.org/sid/state-dependency-does-not-exist.html lists a
> > few packages incorrectly.)
> >
> > But, anyway, I believe that the first depends of an alternate depends
> > relation should be available in main and propose to file bugs about this.
> >
> > Do you agree this warrants a mass bug filing? I couldn't find this written
> > out in policy so these bugs would be wishlist, which probably would make
> > them not warrant a mass bug filing...
> >
> > Comments?
>
> It seems to me not worth a mass bug filing.  This doesn't seem like something
> that would affect user's systems.  Is there a rationale for imposing this
> ordering other than puiparts can't deal with it?
>
> Scott K
>
> Date: Wed, 2 Mar 2011 07:43:39 +0100
> From: sean finney <seanius@debian.org>
> To: Ron Johnson <ron.l.johnson@cox.net>
> Cc: debian-devel@lists.debian.org
> Subject: Re: Potential memory leaks reported by Valgrind against some
>         frequently used commands
> Message-ID: <20110302064339.GA27783@cobija.connexer.com>
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Tue, Mar 01, 2011 at 08:38:42PM -0600, Ron Johnson wrote:
> > On 03/01/2011 06:19 AM, ximalaya wrote:
> >> BTW, I ever tried on Redhat Linux 9, no such problem.
> >>
> >
> > This is the interesting part.  Is RH keeping their patches, or are
> > upstream and other distros just not determining them worthwhile?
>
> given that RH9 is like what, 10 years old, i'd think that it's just as
> likely that the utilities just weren't leaky at the time.
>
>
>         sean
>
> Date: Wed, 2 Mar 2011 07:52:53 +0100
> From: Adrian von Bidder <avbidder@fortytwo.ch>
> To: debian-devel@lists.debian.org
> Subject: Re: Potential memory leaks reported by Valgrind against some frequently used commands
> Message-Id: <201103020753.00447@fortytwo.ch>
> Content-Type: multipart/signed;
>   boundary="nextPart4592254.VR4bC6SFDz";
>   protocol="application/pgp-signature";
>   micalg=pgp-sha1
> Content-Transfer-Encoding: 7bit
>
> --nextPart4592254.VR4bC6SFDz
> Content-Type: Text/Plain;
>   charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Hi!
>
> On Wednesday 02 March 2011 03.38:42 Ron Johnson wrote:
> > On 03/01/2011 06:19 AM, ximalaya wrote:
> > > Hi all,
> >=20
> > [snip]
> >=20
> > > BTW, I ever tried on Redhat Linux 9, no such problem.
> >=20
> > This is the interesting part.  Is RH keeping their patches, or are
> > upstream and other distros just not determining them worthwhile?
>
> Or is it an eglibc <> libc issue? (Not sure what libc RH is using.)
>
>
> =2D- vbi
>
>
> =2D-=20
> Vertrauen ist gut.  Anwalt ist saugeil.
>
> --nextPart4592254.VR4bC6SFDz
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Description: This is a digitally signed message part.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAABAgAGBQJNbelHAAoJEGfYVHb4mT6VsA4QAI1jf5khCoGhbwQo6lR4UfwI
> ySBaUreV1rmPrYEetWTcZ85aKBB1+FzCmBfNr4QNbqgy0Ri9dXhkTjKKs4spUxUN
> T/iWGcoLMGGlyC73ktNsXO9nkH/Z17AEnpldavblODgoGe1KPZFDQhPeBUFotoux
> k79PuXlcLvVbZmdnvEIy6lJsfMStGD96ThFCAlvtcjL5oTESiGkr78KDDkWOAyys
> 7b9tycCoJqSYfGk7+xYiedx/C1edCItoh3BZPJY8qPjpaR32fMnaNpJGDG/eOOqb
> eWEyHazKb29rP9jtVbLUXpImEVKr+ddQIEpWtnsi/DjJsvG+Xxzi5cKAYayabItl
> JFTdEjGMcYZqXxJAFi4drAaGhHgbtUy68csWWy+FbWmW73Fm9zdCVzsxrZc7rHt+
> pJNS+VHUVOu+rs88tnRvwKFPNbNjjz+qFEkhCOOmemPDayKuyxHXv5vZfWfFsWET
> sRMvLM+1Z5TMCDZ3OwxgXXwZv04cJ5kWbZKGYX+8dqMHrzGO48WjZ+xHTO62gAY+
> 9Tp24BnEf8XT49gT3B2N4yM22HFmAdMwVJiC49DICHJbwgMKAftw3ybC9YN0zTAS
> HcaopVfFzzPWouol+7KF5dPq5LtsaaOQt3EJU8j8qvoPRPxrXapkWpdB48w5NM7l
> JZW8mMCGpO3vc8NfvkM4
> =2xoz
> -----END PGP SIGNATURE-----
>
> --nextPart4592254.VR4bC6SFDz--
>
> Date: Wed, 02 Mar 2011 08:32:07 +0100
> From: Tollef Fog Heen <tfheen@err.no>
> To: debian-devel@lists.debian.org
> Subject: Re: enable/disable flags in /etc/default
> Message-ID: <87d3maou4o.fsf@qurzaw.varnish-software.com>
> Content-Type: text/plain; charset=us-ascii
>
> ]] Raphael Geissert
>
> | Tollef Fog Heen wrote:
> | > I think insserv makes it even more complicated, since I believe services
> | > might
> | > be pulled in, even if they're disabled.  (Or it might be that insserv
> | > just throws its hands into the air and tells you it doesn't know how to
> | > do something the next time update-rc.d is run.)
> |
> | No, it doesn't.
>
> Oh, indeed, it just ignores the fact that a required service is disabled
> without warning.
>
> --
> Tollef Fog Heen
> UNIX is user friendly, it's just picky about who its friends are
>
> Date: Wed, 2 Mar 2011 09:41:18 +0100
> From: Stefano Zacchiroli <zack@debian.org>
> To: debian-devel@lists.debian.org
> Subject: Re: enable/disable flags in /etc/default
> Message-ID: <20110302084118.GA19359@upsilon.cc>
> Content-Type: multipart/signed; micalg=pgp-sha1;
>         protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq"
> Content-Disposition: inline
>
> --45Z9DzgjV8m4Oswq
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Mar 01, 2011 at 06:16:06PM +0000, Ben Hutchings wrote:
> > > Do other distro's use service for this?
> > > What's the reason update-rc.d is limited to maintainer scripts?
> > =20
> > No, they use chkconfig.
>
> Ironically, the last paragraph of chkconfig description reads:
>
>   In Debian, there are several tools with similar functionality, but
>   users coming from other Linux distributions will find the tools in
>   this package more familiar.
>
> without telling which those "several tools" are. According to this
> thread, the recommended tool among them is "mv" (in the hope that the
> sysadm knows by heart that they have to run insserv afterwards).
>
> Cheers.
>
> --=20
> Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
> zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
> Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
> ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
>
> --45Z9DzgjV8m4Oswq
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iD8DBQFNbgKn1cqbBPLEI7wRAolEAJ0bJu+qwk5b9xH3dfrFAS7DYxzc5QCeK4Ap
> QlPlvL+YXacPDNsRP1C/cnA=
> =Hk20
> -----END PGP SIGNATURE-----
>
> --45Z9DzgjV8m4Oswq--
>
> Date: Wed, 2 Mar 2011 10:17:54 +0100
> From: Wouter Verhelst <wouter@debian.org>
> To: Ron Johnson <ron.l.johnson@cox.net>
> Cc: debian-devel@lists.debian.org
> Subject: Re: Potential memory leaks reported by Valgrind against some
>  frequently used commands
> Message-ID: <20110302091754.GK3124@celtic.nixsys.be>
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Tue, Mar 01, 2011 at 08:38:42PM -0600, Ron Johnson wrote:
> > On 03/01/2011 06:19 AM, ximalaya wrote:
> > >Hi all,
> > [snip]
> > >
> > >BTW, I ever tried on Redhat Linux 9, no such problem.
> > >
> >
> > This is the interesting part.  Is RH keeping their patches, or are
> > upstream and other distros just not determining them worthwhile?
>
> Not really. The interesting part is 'was this done with the same version
> of valgrind?'
>
> Note that valgrind has a feature to blacklist false positives and issues
> (like this one) that don't matter at all.
>
> --
> The biometric identification system at the gates of the CIA headquarters
> works because there's a guard with a large gun making sure no one is
> trying to fool the system.
>   http://www.schneier.com/blog/archives/2009/01/biometrics.html
>
> Date: Wed, 2 Mar 2011 10:21:27 +0100
> From: sean finney <seanius@debian.org>
> To: Olaf van der Spek <olafvdspek@gmail.com>, debian-devel@lists.debian.org,
>         Russ Allbery <rra@debian.org>,
>         Raphael Geissert <geissert@debian.org>
> Cc: Steve Langasek <vorlon@debian.org>
> Subject: Re: enable/disable flags in /etc/default
> Message-ID: <20110302092127.GB27783@cobija.connexer.com>
> Content-Type: text/plain; charset=iso-8859-1
> Content-Disposition: inline
> Content-Transfer-Encoding: 8bit
>
> On Tue, Mar 01, 2011 at 08:30:24PM +0100, Olaf van der Spek wrote:
> > > time the package is upgraded.  i mean, it's not even that great for
> > > maintainer scripts, as evidenced by the total inconsistency for how
> > > developers are managing enabling/disabling of their services.
> >
> > Isn't that handled by DH for simple cases?
>
> i don't think the simple cases are the problems here.  the problems arise
> on the maintainer side when they want to do anything different from the
> standard boilerplate dh stuff, like for example conditionally enable/disable
> a service.  i actually attempted to do this The Right Way once with nsca,
> and it was really hard and involved lots of querying of invoke-rc.d.
>
> On Tue, Mar 01, 2011 at 11:58:44PM +0100, Stig Sandbeck Mathisen wrote:
> > The "short term" issue is figuring out if the current practice of
> > DONT_DISABLE_ENABLEMENT=false and friends in /etc/default is something
> > we want to keep doing.
>
> i would guess that the numbers are already overwhelmingly in favor of
> abandoning this practice, if it were reasonably easy and straightforward
> to do.
>
> > The "long term" issue is having a toolset, for the end user, for
> > starting and stopping services, enabling and disabling services when
> > booting, installing and upgrading, and setting a global policy for what
> > the initial status of an installed service should be.
>
> i'd agree with Russ that doing this sooner rather than later would
> actually accelerate the abandonment of the practice.. that is i don't
> think most people are doing it because they think "this is how it should
> be done", but rather "i can't find a better way to do it".
>
> > A RHEL service can be started manually, but will not be started at
> > system boot unless explicitly configured to do so with "chkconfig".
>
> and in our case it's renaming a symlink with sysv init, but i find
> it extremely irritating that we can't just provide a damn wrapper
> for that on out of the box installs so debian works like every other
> linux system out there with a reasonably sane chkconfig and/or service
> interface.
>
> On Tue, Mar 01, 2011 at 09:24:52PM -0600, Raphael Geissert wrote:
> > Olaf van der Spek wrote:
> > > So what *is* the proper UI?
> >
> > Interesting that everyone talks about update-rc.d but it appears that nobody
> > has read its documentation:
> >
> > > A common system administration error is to delete the links with
> <snip>
> >
> > That means:
> > # mv /etc/rc2.d/S??apache2 /etc/rc2.d/K00apache2
> > # insserv # this bit is not documented, it seems
> >
> > And that's it, apache2 won't be started on runlevel 2.
>
> and that's pretty much how it works on every other linux/unix like
> (sysv anyway, modulo changing some paths) system out there, at least
> under the hood.
>
> ...but that's not an interface, that's an implementation detail.  a very much
> nonzero number of people are very confused when coming to debian because
> the tools that they've come to learn and use on other linux systems aren't
> present, and when they google or ask on support channels they're given a mixture
> of sometimes conflicting answers.
>
> i spoke with steve briefly on irc this morning and he mentioned that there
> were some (perhaps-unpublished?) notes from the DebConf BoF on init systems,
> does anyone still have a copy of those?  is there any other central place
> where this stuff is being discussed?
>
>
>         sean
> --
>
> Date: Wed, 2 Mar 2011 10:31:39 +0100
> From: sean finney <seanius@debian.org>
> To: Stefano Zacchiroli <zack@debian.org>
> Cc: debian-devel@lists.debian.org
> Subject: Re: enable/disable flags in /etc/default
> Message-ID: <20110302093138.GC27783@cobija.connexer.com>
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> hi zack,
>
> On Wed, Mar 02, 2011 at 09:41:18AM +0100, Stefano Zacchiroli wrote:
> > without telling which those "several tools" are. According to this
> > thread, the recommended tool among them is "mv" (in the hope that the
> > sysadm knows by heart that they have to run insserv afterwards).
>
> there's a few packages that provide the same or similar kind of
> functionality, like sysv-rc-conf, bum, and rcconf.  but none of
> these are anything remotely "standard" in terms of what people
> would be used to seeing, they'd have to find the package names
> and install them and learn how to use them, etc (and it may be
> that even with said utilities that they still have to run
> insserv, d'oh)...
>
>
>         sean
>
> Date: Wed, 02 Mar 2011 09:53:46 +0000
> From: Emilio Pozuelo Monfort <pochu@debian.org>
> To: debian-devel@lists.debian.org
> Subject: Re: potential MBF: first alternate depends not available in main
> Message-ID: <4D6E13AA.7070309@debian.org>
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 7bit
>
> On 02/03/11 04:24, Scott Kitterman wrote:
> > It seems to me not worth a mass bug filing.  This doesn't seem like something
> > that would affect user's systems.  Is there a rationale for imposing this
> > ordering other than puiparts can't deal with it?
>
> If you have non-free enabled and install a package from main, it should install
> the dependencies from main. So you should have e.g. "rar | rar-nonfree" instead
> of the other way round.
>
> Cheers,
> Emilio
>
> Date: Wed, 02 Mar 2011 10:57:19 +0100
> From: Anders Hammarquist <iko@debian.org>
> To: Debian Bug Tracking System <submit@bugs.debian.org>
> Subject: Bug#616071: ITP: python-oejskit -- python driven _javascript_ unit testing
> Message-ID: <20110302095719.27916.19736.reportbug@fido.openend.se>
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
>
> Package: wnpp
> Severity: wishlist
> Owner: Anders Hammarquist <iko@debian.org>
>
> * Package name    : python-oejskit
>   Version         : 0.9.0
>   Upstream Author : Open End AB, Samuele Pedroni <pedronis@openend.se>
> * URL             : http://pypi.python.org/pypi/oejskit
> * License         : MIT
>   Programming Lang: python
>   Description     : python driven _javascript_ unit testing
>
> jskit contains infrastructure and in particular a py.test plugin to enable
> running tests for _javascript_ code inside browsers directly using py.test as
> the test driver. Running inside the browsers comes with some speed cost, on
> the other hand it means for example the code is tested against the real-
> world DOM implementations.
>
> The approach also enables to write integration tests such that the
> _javascript_ code is tested against server-side Python code mocked as
> necessary. Any server-sideframework that can already be exposed through
> WSGI (or for which a subset of WSGI can be written to accommodate the jskit
> own needs) can play along.
>
> Date: Wed, 2 Mar 2011 18:45:59 +0800
> From: Paul Wise <pabs@debian.org>
> To: debian-devel@lists.debian.org
> Subject: Re: potential MBF: first alternate depends not available in main
> Message-ID: <AANLkTime83fP_AkmNFb-0rgSHdt731fPL8HLK_SYkE3J@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Wed, Mar 2, 2011 at 5:53 PM, Emilio Pozuelo Monfort <pochu@debian.org> wrote:
>
> > If you have non-free enabled and install a package from main, it should install
> > the dependencies from main. So you should have e.g. "rar | rar-nonfree" instead
> > of the other way round.
>
> non-free stuff shouldn't be in main depends at all IMO, even as an alternative.
>
> --
> bye,
> pabs
>
> http://wiki.debian.org/PaulWise
>
> Date: Wed, 2 Mar 2011 11:51:01 +0100
> From: Holger Levsen <holger@layer-acht.org>
> To: debian-devel@lists.debian.org
> Subject: Re: potential MBF: first alternate depends not available in main
> Message-Id: <201103021151.02321.holger@layer-acht.org>
> Content-Type: multipart/signed;
>   boundary="nextPart1534117.tnyPWLf3cB";
>   protocol="application/pgp-signature";
>   micalg=pgp-sha1
> Content-Transfer-Encoding: 7bit
>
> --nextPart1534117.tnyPWLf3cB
> Content-Type: text/plain;
>   charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline
>
> Hi,
>
> On Mittwoch, 2. M=C3=A4rz 2011, Paul Wise wrote:
> > non-free stuff shouldn't be in main depends at all IMO, even as an
> > alternative.
>
> I (somewhat) agree.
>
> And I think non-existing stuff is worse than non-free...
>
> But, I can see how it can be useful (users, derivatives), thus I think it j=
> ust=20
> shouldn't be the first alternative.
>
>
> cheers,
>         Holger
>
> --nextPart1534117.tnyPWLf3cB
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Description: This is a digitally signed message part.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQBNbiEWUHLQNqxYNSARArtuAKDMCO/3h2FahoFjTKoXfveEJ+JpMQCgtY6q
> FS17rWVKahka5myJ5huvqn0=
> =wjia
> -----END PGP SIGNATURE-----
>
> --nextPart1534117.tnyPWLf3cB--
>
> Date: Wed, 2 Mar 2011 11:53:53 +0100
> From: Jan Hauke Rahm <jhr@debian.org>
> To: debian-devel@lists.debian.org
> Subject: Re: potential MBF: first alternate depends not available in main
> Message-ID: <20110302105353.GA7921@ca.home.jhr-online.de>
> Content-Type: text/plain; charset=iso-8859-1
> Content-Disposition: inline
> Content-Transfer-Encoding: 8bit
>
> On Wed, Mar 02, 2011 at 11:51:01AM +0100, Holger Levsen wrote:
> > Hi,
> >
> > On Mittwoch, 2. März 2011, Paul Wise wrote:
> > > non-free stuff shouldn't be in main depends at all IMO, even as an
> > > alternative.
> >
> > I (somewhat) agree.
> >
> > And I think non-existing stuff is worse than non-free...
> >
> > But, I can see how it can be useful (users, derivatives), thus I think it just
> > shouldn't be the first alternative.
>
> +1
>
> --
>  .''`.   Jan Hauke Rahm <jhr@debian.org>               www.jhr-online.de
> : :'  :  Debian Developer                                 www.debian.org
> `. `'`   Member of the Linux Foundation                    www.linux.com
>   `-     Fellow of the Free Software Foundation Europe      www.fsfe.org
>
> Date: Wed, 02 Mar 2011 13:03:37 +0200
> From: Shachar Shemesh <shachar@debian.org>
> To: Paul Wise <pabs@debian.org>
> CC: debian-devel@lists.debian.org
> Subject: Re: potential MBF: first alternate depends not available in main
> Message-ID: <4D6E2409.20602@debian.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 7bit
>
> On 02/03/11 12:45, Paul Wise wrote:
> > On Wed, Mar 2, 2011 at 5:53 PM, Emilio Pozuelo Monfort<pochu@debian.org>  wrote:
> >
> >
> >> If you have non-free enabled and install a package from main, it should install
> >> the dependencies from main. So you should have e.g. "rar | rar-nonfree" instead
> >> of the other way round.
> >>
> > non-free stuff shouldn't be in main depends at all IMO, even as an alternative.
> >
> >
>
> Then please state what you think should happen in the case pointed out
> by Emilio.
>
> Shachar
>
>
> --
> Shachar Shemesh
> Lingnu Open Source Consulting Ltd.
> http://www.lingnu.com
>
> Date: Wed, 2 Mar 2011 12:37:25 +0000
> From: Simon McVittie <smcv@debian.org>
> To: debian-devel@lists.debian.org
> Cc: debian-devel-games@lists.debian.org
> Subject: Re: enable/disable flags in /etc/default
> Message-ID: <20110302123725.GB2226@reptile.pseudorandom.co.uk>
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> (Cross-posting to d-d-games for discussion of the Quake III-based games)
>
> On Tue, 01 Mar 2011 at 15:20:52 -0800, Russ Allbery wrote:
> > Speaking as someone who has a few of the DONT_NOT_DISABLE_SERVICE
> > variables in some of my packages
>
> Speaking as another implementor of similar variables: I added them in
> openarena-server, quake3-server and tremulous-server (game dedicated servers),
> with the servers disabled by default, for these reasons:
>
> * openarena currently Depends: openarena-server for common game logic that
>   both need; in principle I could add a 5MB openarena-common and make
>   openarena-server only contain scripts, or add an openarena-server-run
>   only containing the init script, but I didn't really fancy another trip
>   through the NEW queue...
>
> * running a Quake III (-based) server from an init script is somewhat less
>   capable than running it in screen from a cron @reboot job or something (which
>   is documented as an alternative in README.Debian), since you lose the
>   ability for an admin to enter console commands in the running server
>
> * I believe it's reasonably common to run several server instances on the
>   same machine (e.g. for different game types or map cycles), which isn't at
>   all straightforward from an init script
>
> The other good option I've seen for packages where the init script isn't
> necessarily the preferred way to run the server is to split the package,
> so the server binary and supporting files are in one binary package (e.g.
> dnsmasq-base, git-daemon, mysql-server-core-5.1) and the init glue is in
> another (dnsmasq, git-daemon-run, mysql-server-5.1).
>
> In that arrangment, alternative setups (dnsmasq run internally by libvirt-bin,
> a git-daemon for occasional use run from inetd, mysql run internally by KDE)
> can depend on the package containing the actual server, and not the one with
> the init scripts. This does lead to proliferation of tiny packages and a
> larger Packages file, though...
>
>     S
>
> Date: Wed, 2 Mar 2011 13:57:34 +0100
> From: Adrian von Bidder <avbidder@fortytwo.ch>
> To: debian-devel@lists.debian.org
> Subject: Re: Call for projects for Google Summer of Code 2011
> Message-Id: <201103021357.41550@fortytwo.ch>
> Content-Type: multipart/signed;
>   boundary="nextPart2080489.5QE45HdAFa";
>   protocol="application/pgp-signature";
>   micalg=pgp-sha1
> Content-Transfer-Encoding: 7bit
>
> --nextPart2080489.5QE45HdAFa
> Content-Type: Text/Plain;
>   charset="iso-8859-15"
> Content-Transfer-Encoding: quoted-printable
>
> On Wednesday 02 March 2011 10.43:44 Ana Guerrero wrote:
>
> > Debian is applying as mentoring organization to the Google Summer of Code
> > (GSoC) this year
>
> Dealing with the init scripts / service enable / disable mess. See current=
> =20
> d-devel discussion.
>
> As much a discussion / social skills project as a coding project, so I'm no=
> t=20
> sure if GSoC is the right place.
>
> Or do it as a pure coding project, implement a proper set of tools, but the=
> n=20
> it's a question if it will be adopted into Debian in the end, which would=20
> mean wasted effort.
>
> (And please don't start discussion of the actual problem here, there's the=
> =20
> other thread for this...)
>
> cheers
> =2D- vbi
>
> =2D-=20
> Jetzt ist der Herr Bush Pr=E4sident, und weil ihm wieder langweilig ist,
> will er endlich den Saddam loswerden. Der Herr Bush hat n=E4mlich keine
> Praktikantin.
>         -- http://bush.d0t.de/
>
> --nextPart2080489.5QE45HdAFa
> Content-Type: application/pgp-signature; name=signature.asc
> Content-Description: This is a digitally signed message part.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAABAgAGBQJNbj6/AAoJEGfYVHb4mT6VwuYP/14JyhZat3kG7Y6wNdUgjWJe
> vOsz/US2238sjGWhTcqg4sYF4J5XwCtsWuE0pvByG+LxkgSjZQpKkLWXrSRKTmHu
> dl+9HY1KvBWVN8rf4K3Fteah3sxsa0uICfvLDcgLx2ToYw7qK32MkoxwKfc1Duxa
> 9D6Zh867R1wKszL0fO5SOI1L5otniKKnFdPgimQI7RZsJHGrJD1JapDgEH1qI13I
> Q6WZidHtaHKh1Lu1DG7RYajQKW+qPxSygYJXi8mSPuNGDCvDdKdAG3xf7E+wrD0S
> xdLGBoQOTpRh30LmX6smthfJcEbfdjggOA7QUe7F+hndD5QSn6ckWb5MQFGTzTzF
> IHFM6Tq4Whn4b81usncbJHw/JldazBAiEqxym7ZC52Z34+vbbFOZ+BabNSy7DIbZ
> dEnW6gu5GCS7BwiYjfmLDKPtl6uFTFcjGW+AvJZ0Dk+Eo2tn6d4T0PFhjhjpcE6C
> 4UWoY/MU5Vynyc2fCW++H/HKsZjQ250NifLw4pp1w+ifXigM2AkPGESKZbwY09si
> PHgiLVd+0k2E7eE93DJ+TgJg/xXdEZjhEDPSt6pkC6Iifncwktdf9uNZBs6iI/2v
> fxMPVAetOW/9SK1KVQmnNiu5SP1vYuKCQ46A04QpCFdIfX+68le1ypBRGAWDjtHI
> BN5p4rhhKdwhGNlXEJWS
> =Cdzr
> -----END PGP SIGNATURE-----
>
> --nextPart2080489.5QE45HdAFa--
>
> Date: Wed, 02 Mar 2011 14:16:04 +0100
> From: Bernd Zeimetz <bernd@bzed.de>
> To: debian-devel@lists.debian.org
> Subject: Re: Call for projects for Google Summer of Code 2011
> Message-ID: <4D6E4314.2010107@bzed.de>
> Content-Type: text/plain; charset=ISO-8859-15
> Content-Transfer-Encoding: 7bit
>
> On 03/02/2011 01:57 PM, Adrian von Bidder wrote:
> > On Wednesday 02 March 2011 10.43:44 Ana Guerrero wrote:
> >
> >> Debian is applying as mentoring organization to the Google Summer of Code
> >> (GSoC) this year
> >
> > Dealing with the init scripts / service enable / disable mess. See current
> > d-devel discussion.
>
> What about a project which prepares a migration to
> http://www.freedesktop.org/wiki/Software/systemd ?
>
>
>
> --
>  Bernd Zeimetz                            Debian GNU/Linux Developer
>  http://bzed.de                                http://www.debian.org
>  GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
>
> Date: Wed, 2 Mar 2011 14:19:26 +0100
> From: Cyril Brulebois <kibi@debian.org>
> To: debian-devel@lists.debian.org
> Subject: Re: Call for projects for Google Summer of Code 2011
> Message-ID: <20110302131926.GU10822@debian.org>
> Content-Type: multipart/signed; micalg=pgp-sha1;
>         protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e"
> Content-Disposition: inline
>
> --cNdxnHkX5QqsyA0e
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> Bernd Zeimetz <bernd@bzed.de> (02/03/2011):
> > What about a project which prepares a migration to
> > http://www.freedesktop.org/wiki/Software/systemd ?
>
> yay for portability.
>
> KiBi.
>
> --cNdxnHkX5QqsyA0e
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1uQ94ACgkQeGfVPHR5Nd2HfQCgu89a49icaRGmH1xFySrTRY6A
> QZAAn3z6duSn0BfwrG82zF73CaXBNajH
> =LN2m
> -----END PGP SIGNATURE-----
>
> --cNdxnHkX5QqsyA0e--
>


Reply to: