K
Content-Type: text/plain
debian-devel-digest Digest Volume 2011 : Issue 156
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--