Quoting Lucas Nussbaum (lu...@lucas-nussbaum.net):
> - When doing talks about something at Debconf or at another conference,
> take the opportunity to review and improve the corresponding dev-ref
> section. (That applies to the i18n chapter of dev-ref, which is
> apparently badly outdated).
On Sun, Sep 06, 2009 at 08:48:50PM +0200, Heiko Stübner wrote:
> as I was unsuccessful in finding similiar cases on the mailing lists I would
> like some input on the handling of corner-case in packaging.
> The package is fso-usaged from the freesmartphone.org software-stack and not
> yet in de
On Mon, Sep 07 2009, Pierre Habouzit wrote:
> On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote:
>> git format-patch alone will stil not be enough to generate a DEP3-compliant
>> header but would that resolve your concerns?
>
> It will be compatible if you relax the use of headers t
On Tue, Sep 08, 2009 at 01:13:45AM +0200, Serafeim Zanikolas wrote:
> On Mon, Sep 07, 2009 at 01:59:48PM -0700, Steve Langasek wrote [edited]:
> > On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote:
> > > but the primary benefits are making inetd support in maintainer scripts
> > > both ro
On Mon, Sep 07, 2009 at 10:30:14PM +0200, Raphael Hertzog wrote:
> On Sat, 05 Sep 2009, Guido Günther wrote:
> > I tried to point that out in June:
> > http://lists.debian.org/debian-devel/2009/06/msg00551.html
> > but failed. It'd be really helpful if DEP-3 would be compatible with the
> > git fo
On Mon, Sep 07, 2009 at 11:03:37PM +0200, Raphael Hertzog wrote:
> Hello,
>
> after several rounds of discussion on -devel, we now have a
> new standard defining meta-information to integrate on patches that we
> distribute/apply in our packages:
> http://dep.debian.net/deps/dep3/
Sorry I haven't
On Mon, Sep 07, 2009 at 01:59:48PM -0700, Steve Langasek wrote [edited]:
> On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote:
> > but the primary benefits are making inetd support in maintainer scripts
> > both robust and idempotent.
>
> update-inetd in its present form can already be us
On Mon, Sep 07, 2009 at 10:45:55PM +0200, Raphael Hertzog wrote:
> On Mon, 07 Sep 2009, Steve Langasek wrote:
> > I think the devref discussions (incl. bug traffic) need to be moved onto
> > debian-policy. We already have any number of bugs getting redirected from
> > policy to the devref, so it's
On Mon, Sep 07, 2009 at 11:19:02PM +0200, Julien Cristau wrote:
> > On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> > > * document that local policy will live in /etc/inetd.conf.d/ and any
> > > manual
> > > changes will be made effective by running update-inetd
> > I thin
On Mon, Sep 07, 2009 at 11:03:37PM +0200, Raphael Hertzog wrote:
>
> after several rounds of discussion on -devel, we now have a
> new standard defining meta-information to integrate on patches that we
> distribute/apply in our packages:
> http://dep.debian.net/deps/dep3/
at a quick look this aga
On Mon, 07 Sep 2009, Raphael Hertzog wrote:
> after several rounds of discussion on -devel, we now have a
> new standard defining meta-information to integrate on patches that we
> distribute/apply in our packages:
> http://dep.debian.net/deps/dep3/
s/standard/standard proposal/ of course, if that
Julien Cristau a écrit :
> FWIW, I'm not going to use something that I can't produce with git
> format-patch and feed to git send-email / git am since that feels like
> busy work; in particular the Author and Description fields are not
> needed given there's From and Subject with the same informati
On Fri, Sep 4, 2009 at 22:02:21 -0700, Steve Langasek wrote:
> On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> > * document that local policy will live in /etc/inetd.conf.d/ and any manual
> > changes will be made effective by running update-inetd
>
> I think this violate
On Fri, Sep 04, 2009 at 10:02:21PM -0700, Steve Langasek wrote:
> On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas wrote:
> > As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
> > proposal below to migrate it to dpkg triggers [0]
>
> > * update-inetd will drop
On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote:
> It's not just about supporting xinetd, as I hope the initial post
> made clear. It's using the xinetd syntax certainly (why reinvent
> the wheel when you can reuse the format as the superset used by all
> existing inetds?), but the pri
Package: wnpp
Severity: wishlist
Owner: Mehdi Dogguy
* Package name: ocamlviz
Version : 1.0
Upstream Author : Julien ROBERT, Guillaume VON TOKARSKI, FILLIATRE
Jean-Christophe, CONCHON Sylvain and LE FESSANT Fabrice
* URL : http://ocamlviz.lri.fr/
* License : L
On Mon, 07 Sep 2009, Lucas Nussbaum wrote:
> - There are many open bugs, about things that should really be fixed or
> added in dev-ref, but I don't have time to address them (I'm doing
> "please provide a patch and I'll integrate it"-maintainance).
As a co-maintainer, I must recognize that I
+1 for SCM compatibility.
Since version control is a best practice for packaging IMHO, I think we
should be able to apply those processes cleanly enough to let us
continue with them.
When we import patches from upstream, I think most adhere to some kind
of format, what is standard is where the pa
On Sun, Sep 06, 2009 at 11:30:25PM +0200, Marco d'Itri wrote:
> On Sep 04, Serafeim Zanikolas wrote:
>
> > As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the
> > proposal below to migrate it to dpkg triggers [0]
> Maybe you could have discussed it with the former maintain
On Sat, 05 Sep 2009, Guido Günther wrote:
> I tried to point that out in June:
> http://lists.debian.org/debian-devel/2009/06/msg00551.html
> but failed. It'd be really helpful if DEP-3 would be compatible with the
> git format-patch output.
Would it be helpful to say that From: can be an alias f
tag 8927 + wontfix
thanks
On Sun, Sep 06, 2009 at 11:30:25PM +0200, Marco d'Itri wrote [edited]:
> On Sep 04, Serafeim Zanikolas wrote:
> > * abolish /etc/inetd.conf and /etc/xinetd.d/ and instead auto-generate
> This is unacceptable, and I say this as the openbsd-inetd maintainer
> (which is ano
On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:
> Case 1:
> char *foo;
> if (asprintf(&foo, "%s equals %i", somestring, someint) < 0) {
> fprintf(stderr, "Failed to allocate memory");
> abort();
> }
>
> Case 2:
> ch
Steve Langasek writes:
> I think the devref discussions (incl. bug traffic) need to be moved onto
> debian-policy. We already have any number of bugs getting redirected
> from policy to the devref, so it's not as though there would be a
> massive traffic increase; and it would put the right set
On Mon, Sep 07, 2009 at 08:57:54PM +0200, David Paleino wrote:
> > Lucas Nussbaum, le Mon 07 Sep 2009 18:28:11 +0200, a écrit :
> > > We could simply decide that it's deprecated, and use a set of wiki
> > > pages to document our procedures.
> >
> > I would like to raise the fact that Internet is n
On Mon, Sep 07, 2009 at 03:51:54PM +0200, Bjørn Mork wrote:
> Do you really need the g_utf16_to_utf8 unicode translation? You could
> just as well let udev export the raw utf16 value and leave the
> conversion up to the users. They may want something different than utf8
> anyway.
man 3 iconv
--
On Mon, Sep 07, 2009 at 06:28:11PM +0200, Lucas Nussbaum wrote:
> First, we need to decide whether we want to continue to maintain
> developers-reference. We could simply decide that it's deprecated, and
> use a set of wiki pages to document our procedures. I see some value to
> a (mostly) self-co
On Monday 07 September 2009 20:27:24 Henrique de Moraes Holschuh wrote:
> On Mon, 07 Sep 2009, Josselin Mouette wrote:
> > Le lundi 07 septembre 2009 à 08:39 +0200, Petter Reinholdtsen a
écrit :
> > > I guess we were a bit unclear. The point is to use it for
> > > upgrades (ie when it exist), whi
On Mon, 7 Sep 2009 18:40:44 +0200, Samuel Thibault wrote:
> Lucas Nussbaum, le Mon 07 Sep 2009 18:28:11 +0200, a écrit :
> > We could simply decide that it's deprecated, and use a set of wiki
> > pages to document our procedures.
>
> I would like to raise the fact that Internet is not available
>
On Mon, 07 Sep 2009, Josselin Mouette wrote:
> Le lundi 07 septembre 2009 à 08:39 +0200, Petter Reinholdtsen a écrit :
> > I guess we were a bit unclear. The point is to use it for upgrades
> > (ie when it exist), while not installing /etc/inittab for new
> > installs, thus slowly getting rid of
Hi Julien!
On Mon, 07 Sep 2009, Julien Cristau wrote:
> On Mon, Sep 7, 2009 at 14:59:44 -0300, Henrique de Moraes Holschuh wrote:
>
> > khazad-dum:~$ lsusb ; ls -l /dev/serial/by-id/*
> > Bus 004 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA
> > Modem / E270 HSDPA/HSUPA Mode
On Mon, 07 Sep 2009, Steve Langasek wrote:
> On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 07 Sep 2009, Julien Cristau wrote:
> > > On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > > From what I can see in /lib/udev/rules.d, the ids files
On Mon, Sep 7, 2009 at 14:59:44 -0300, Henrique de Moraes Holschuh wrote:
> khazad-dum:~$ lsusb ; ls -l /dev/serial/by-id/*
> Bus 004 Device 003: ID 12d1:1003 Huawei Technologies Co., Ltd. E220 HSDPA
> Modem / E270 HSDPA/HSUPA Modem
> lrwxrwxrwx 1 root root 13 2009-09-07 14:56
> /dev/serial/by-id
On Mon, 07 Sep 2009, Steve Langasek wrote:
> On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> > On Mon, 07 Sep 2009, Julien Cristau wrote:
> > > On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > > From what I can see in /lib/udev/rules.d, the ids files
On Mon, Sep 07, 2009 at 02:59:44PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 07 Sep 2009, Julien Cristau wrote:
> > On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > > From what I can see in /lib/udev/rules.d, the ids files are only used to
> > > setup
> > > the (udev) env
Henrique de Moraes Holschuh wrote:
> On Mon, 07 Sep 2009, Julien Cristau wrote:
>> On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
>>> From what I can see in /lib/udev/rules.d, the ids files are only used to
>>> setup
>>> the (udev) environment variable ID_VENDOR_FROM_DATABASE
>>> (75
Steve Langasek wrote:
On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:
Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit :
For the record: Noone sane would replace g_strdup_printf with snprintf,
but with asprintf.
Case 1:
char *foo;
if (aspri
On Mon, 07 Sep 2009, Julien Cristau wrote:
> On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> > From what I can see in /lib/udev/rules.d, the ids files are only used to
> > setup
> > the (udev) environment variable ID_VENDOR_FROM_DATABASE
> > (75-net-description.rules, 75-tty-descrip
On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:
> Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit :
> > For the record: Noone sane would replace g_strdup_printf with snprintf,
> > but with asprintf.
> Case 1:
> char *foo;
> if (asprintf(&foo, "
On Sep 07, "Roberto C. Sánchez" wrote:
> As part of the shorewall package reorganization, the
> /etc/init.d/shorewall init script (and the symlinks to it) has moved
> from the shorewall-common package to the shorewall package. However,
> after the upgrade of shorewall-common (which has become a
Lucas Nussbaum, le Mon 07 Sep 2009 18:28:11 +0200, a écrit :
> We could simply decide that it's deprecated, and use a set of wiki
> pages to document our procedures.
I would like to raise the fact that Internet is not available
everywhere, so at least an easy way to get an offline copy of these
wo
As part of the shorewall package reorganization, the
/etc/init.d/shorewall init script (and the symlinks to it) has moved
from the shorewall-common package to the shorewall package. However,
after the upgrade of shorewall-common (which has become a dummy
package), and the installation of the new s
Hi,
I'm quite concerned about the state of developers-reference.
- I've basically been the only active maintainer for over a year.
- There are many open bugs, about things that should really be fixed or
added in dev-ref, but I don't have time to address them (I'm doing
"please provide a patc
Le lundi 07 septembre 2009 à 17:29 +0200, Michael Biebl a écrit :
> > So, again, why can't the programs that want to display this do the
> > lookup themselves? Both libpciaccess and libpci provide API for this as
> > far as I can tell.
>
> I am sure, they could. My guess is, it was added to udev
Package: wnpp
Severity: wishlist
Owner: Mathieu Malaterre
* Package name: srcml
Version : 20061109
Upstream Author : Dr. Michael Collard, Jonathan Maletic
* URL : http://www.sdml.info/projects/srcml/
* License : GPL
Programming Lang: C++
Description :
Le lundi 07 septembre 2009 à 17:32 +0200, Mike Hommey a écrit :
> Nobody has advised to strip them down from the library. Just to stop
> using glib in a small udev binary that only uses glib wrappers.
And I still believe this advice is wrong.
--
.''`. Josselin Mouette
: :' :
`. `' “I re
On Mon, Sep 07, 2009 at 05:15:44PM +0200, Josselin Mouette wrote:
> Le lundi 07 septembre 2009 à 16:56 +0200, Hendrik Sattler a écrit :
> > So no trying to convince glib upstream to reduce wrapper bloat? *sigh*
>
> What you are calling wrapper bloat is critical for portability of many
> applicati
Julien Cristau wrote:
> On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
>
>> From what I can see in /lib/udev/rules.d, the ids files are only used to
>> setup
>> the (udev) environment variable ID_VENDOR_FROM_DATABASE
>> (75-net-description.rules, 75-tty-description.rules, 78-sound-c
Le lundi 07 septembre 2009 à 16:56 +0200, Hendrik Sattler a écrit :
> So no trying to convince glib upstream to reduce wrapper bloat? *sigh*
What you are calling wrapper bloat is critical for portability of many
applications, since it behaves the same on all systems where Glib has
been ported. Ju
Zitat von Josselin Mouette :
Le lundi 07 septembre 2009 à 15:51 +0200, Bjørn Mork a écrit :
I'm suggesting that the utility uses lots of "g_" prefixed functions
while it's obvious that the author never ever evaluated the need for
these. I assume that's because the author is used to them always
Le lundi 07 septembre 2009 à 15:51 +0200, Bjørn Mork a écrit :
> I'm suggesting that the utility uses lots of "g_" prefixed functions
> while it's obvious that the author never ever evaluated the need for
> these. I assume that's because the author is used to them always being
> available.
>
> W
Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit :
> For the record: Noone sane would replace g_strdup_printf with snprintf,
> but with asprintf.
Case 1:
char *foo;
if (asprintf(&foo, "%s equals %i", somestring, someint) < 0) {
fprintf(stderr, "Fa
Package: wnpp
Severity: wishlist
Owner: "Dario Minnucci (midget)"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: mon-client
Version : 1.2.0
Upstream Author : Jim Trocki
* URL : http://mon.wiki.kernel.org/index.php/Download
* License : GPL-2+
On Mon, Sep 07 2009, Gabor Gombas wrote:
> Hi,
>
> On Sun, Sep 06, 2009 at 06:21:33PM -0500, Manoj Srivastava wrote:
>
>> Right. I did not copy the upstream. I also think that we have
>> invested a lot of effort in Debian in order to make Squeeze SELinux
>> compliant, and make it so that
Josselin Mouette writes:
> Le lundi 07 septembre 2009 à 11:48 +0200, Bjørn Mork a écrit :
>> You're not seriously suggesting that DeviceKit-disks usage of g_print
>> instead of printf is actually adding anything useful?
>
> Yeah sure, just look at g_print and not at the other symbols used by
> de
Package: wnpp
Severity: wishlist
Owner: Peter Pentchev
* Package name: libnet-epp-perl
Version : 0.12
Upstream Author : CentralNic Ltd - http://www.centralnic.com/
* URL : http://search.cpan.org/dist/Net-EPP/
* License : Perl
Programming Lang: Perl
Descript
On Mon, Sep 07, 2009 at 03:19:19PM +0200, Stéphane Glondu wrote:
> Do you have an example of such OS that is likely to be supported by
> freesmartphone.org ?
I know nothing about freesmartphone.org so I have no idea what they want
to support.
Gabor
--
-
Gabor Gombas a écrit :
> That won't work if upstream wants to support OSes other than Linux. My
> memory is getting hazy but I had to use the same technique in the past
> because not all OSes are capable of letting plugins resolve symbols from
> the main binary, at least not without extra complicat
Am Montag, den 07.09.2009, 13:30 +0200 schrieb Vincent Danjean:
> Gabor Gombas wrote:
> > On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:
> >
> >> Robert filed already after the upload of grub-legacy a RC bug so it
> >> doestn't migrate after the usual 10 days to testing.
> >>
> >>
On Mon, Sep 07, 2009 at 11:22:30AM +0200, Giacomo A. Catenazzi wrote:
> We have a lot of troubles when upstreams ship a debian/ directory
> in upstream tarball, thus I'll expect derivatives will have similar
> problems
I don't see it that way.
The reason why we have 'a lot of troubles' when upstr
Steve Langasek writes:
>> We have done this in the past in Debian without changing the SONAME in
>> places where compatibility of SONAME with other distributions is
>> important. Specifically, libkrb53 removed several private symbols and we
>> didn't change the SONAME. *However*, if you're thi
"Nikita V. Youshchenko" writes:
> As of today, debian does not contain this bug, because ffmpeg with this
> brakage happened not to be uploaded yet to debian. However, once it is,
> the bug will be in debian, and will have to be handled somehow.
mplayer is really meant to be using the internal
Zitat von Josselin Mouette :
Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit :
It rather needs to raise the question why simple low-level tools
use something
like libglib?
I’d rather raise the question why each of our simple low-level tools
implement its data structure
* Josselin Mouette [090907 12:37]:
> Are you suggesting that such an utility should implement its own linked
> list structure, and unicode translation functions? Are you aware of the
> security implications of using snprintf instead of g_strdup_printf?
For the record: Noone sane would replace g_s
On Mon, Sep 07, 2009 at 09:53:30AM +0100, Colin Watson wrote:
> On Sat, Sep 05, 2009 at 08:32:02PM +0200, Gabor Gombas wrote:
> > On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:
> > > Note that we only Suggests: os-prober and not Recommend: it like Ubuntu
> > > does because of 491872
Gabor Gombas wrote:
> On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:
>
>> Robert filed already after the upload of grub-legacy a RC bug so it
>> doestn't migrate after the usual 10 days to testing.
>>
>> Note that we only Suggests: os-prober and not Recommend: it like Ubuntu
>> doe
Le lundi 07 septembre 2009 à 11:48 +0200, Bjørn Mork a écrit :
> You're not seriously suggesting that DeviceKit-disks usage of g_print
> instead of printf is actually adding anything useful?
Yeah sure, just look at g_print and not at the other symbols used by
devkit-disks-part-id :
g_free g_slist
On Mon, Sep 7, 2009 at 05:15:19 +0200, Michael Biebl wrote:
> From what I can see in /lib/udev/rules.d, the ids files are only used to setup
> the (udev) environment variable ID_VENDOR_FROM_DATABASE
> (75-net-description.rules, 75-tty-description.rules, 78-sound-card.rules).
>
> There are no sym
Colin Watson wrote:
> On Sat, Sep 05, 2009 at 10:55:42PM +0200, Frans Pop wrote:
>> I would not recommend having os-prober installed for this.
>
> We should make it more efficient and less intrusive, but that's
> perfectly feasible in os-prober itself and would be a good idea anyway.
My main poin
Josselin Mouette writes:
> Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit :
>> It rather needs to raise the question why simple low-level tools use
>> something
>> like libglib?
>
> I’d rather raise the question why each of our simple low-level tools
> implement its data s
Goswin von Brederlow wrote:
I also would rather have a native package in Debian and then have
Debian derivatives convert the package using Debians tar.gz as
orig.tar.gz and put their derivate specific changes into diff.gz.
Shipping a source with 0 byte diff.gz in Debian seems stupid and
shippin
On Sat, Sep 05, 2009 at 08:32:02PM +0200, Gabor Gombas wrote:
> On Sat, Sep 05, 2009 at 03:03:40PM +0200, Felix Zielcke wrote:
> > Note that we only Suggests: os-prober and not Recommend: it like Ubuntu
> > does because of 491872
> > So if anyone want to help that we Recommend it again, then help t
On Sat, Sep 05, 2009 at 11:03:10PM +0200, Frans Pop wrote:
> On Saturday 05 September 2009, Frans Pop wrote:
> > It has never been intended to be used as part of an update-grub script
> > and to be run every time the bootloader configuration is updated
> > because a new/updated kernel was installed
On Sat, Sep 05, 2009 at 10:55:42PM +0200, Frans Pop wrote:
> Philipp Kern wrote:
> > Do you have os-prober installed?
>
> I would not recommend having os-prober installed for this. os-prober has
> always been intended to be run only _once_, mostly when a new system is
> installed. It exists as a
Le lundi 07 septembre 2009 à 08:39 +0200, Petter Reinholdtsen a écrit :
> I guess we were a bit unclear. The point is to use it for upgrades
> (ie when it exist), while not installing /etc/inittab for new
> installs, thus slowly getting rid of the file while ensuring the
> switch do not affect up
Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit :
> It rather needs to raise the question why simple low-level tools use
> something
> like libglib?
I’d rather raise the question why each of our simple low-level tools
implement its data structures and basic routines in its
On Mon, Sep 07, 2009 at 02:12:52PM +0800, Paul Wise wrote:
> Sounds like upstream should be persuaded to move the shared library
> code into the daemon since there is no reason for it to be in a
> library.
That won't work if upstream wants to support OSes other than Linux. My
memory is getting ha
[Rene Mayrhofer]
> Please don't. As you correctly pointed out, the current Debian init
> architecture is one of the most painful and outdated (not to say
> broken) parts in the whole system. It's really time to move away
> from old cruft (and I consider inittab to be cruft of little use at
> this t
On 2009-09-07, Andrew R Kelley wrote:
> --000e0cd3b27cf19d880472f5f8d4
> Content-Type: text/plain; charset=ISO-8859-1
>
> Can we have amarok 1.4 as an option to use? in my opinion, amarok 2 is not
> usable yet. I decided to give it a try when it replaced 1.4 in squeeze, but
> it's missing many 1.4
Hi,
On Sun, Sep 06, 2009 at 06:21:33PM -0500, Manoj Srivastava wrote:
> Right. I did not copy the upstream. I also think that we have
> invested a lot of effort in Debian in order to make Squeeze SELinux
> compliant, and make it so that turning on SELinux is fairly easy. I
> have asked
79 matches
Mail list logo
