Re: [Debconf-discuss] using OpenPGP notations to indicate keysigning practices [was: Re: GPG keysigning?]

[Simon Richter]

On Tue, Jun 23, 2009 at 08:52:20PM +0200, martin f krafft wrote:

> Additional metadata, e.g. number and expiration date would
> be helpful.

Actually that'd be illegal in Germany -- ID numbers of identification
documents may not be stored in databases, with exactly two exceptions:

 - the issuing office can map (name, address, date of birth) -> number for
   inclusion in
 - the list of stolen documents, kept by the police (this list has no
   names)

   Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Steve Langasek]

On Wed, Jun 24, 2009 at 09:02:26AM +1000, Aníbal Monsalve Salazar wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Anibal Monsalve Salazar 

> * Package name: libposix

Why?

This is a subset of the interfaces provided by glibc, which must be present
on all systems.  So it would be stupid for any package in Debian to link
against libposix instead of just using libc.  Why do we want a library in
Debian that no packages should depend on?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#534429: ITP: haskell-utf8-string -- Haskell Library for operating on UTF8 strings

[Erik de Castro Lopo]

Package: wnpp
Severity: wishlist
Owner: Erik de Castro Lopo 


* Package name: haskell-utf8-string
  Version : 0.3.5
  Upstream Author : Galois Inc. 
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string
* License : BSD
  Programming Lang: Haskell
  Description : Haskell Library for operating on UTF8 strings

 A UTF8 layer for IO and Strings. The utf8-string package provides operations
 for encoding UTF8 strings to Word8 lists and back, and for reading and writing
 UTF8 without truncation.




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#534431: ITP: haskell-json -- Haskell library for serialising data to and from JSON

[Erik de Castro Lopo]

Package: wnpp
Severity: wishlist
Owner: Erik de Castro Lopo 


* Package name: haskell-json
  Version : 0.4.3
  Upstream Author : Sigbjorn Finne 
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/json
* License : BSD
  Programming Lang: Haskell
  Description : Haskell library for serialising data to and from JSON

 JSON (JavaScript Object Notation) is a lightweight data-interchange format. It
 is easy for humans to read and write. It is easy for machines to parse and
 generate. It is based on a subset of the JavaScript Programming Language,
 Standard ECMA-262 3rd Edition - December 1999.

 This library provides a parser and pretty printer for converting between
 Haskell values and JSON.




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Guus Sliepen]

On Wed, Jun 24, 2009 at 11:03:41AM +0100, Steve Langasek wrote:

> On Wed, Jun 24, 2009 at 09:02:26AM +1000, Aníbal Monsalve Salazar wrote:
> > * Package name: libposix
> 
> Why?
> 
> This is a subset of the interfaces provided by glibc, which must be present
> on all systems.  So it would be stupid for any package in Debian to link
> against libposix instead of just using libc.  Why do we want a library in
> Debian that no packages should depend on?

Just see it as dash vs. bash. Once libposix reaches maturity, I will certainly
consider linking applications I wrote myself against libposix. Applications
linked against it will probably use less memory and cannot inadvertently use
glibc extensions. This will make it easier to port those applications, and will
also make it easier to run things on embedded platforms.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Bug#533369: ITP: tinycalc -- Command line calculator for developers

[Christian Hammers]

Hi

Am Tue, 16 Jun 2009 23:22:44 +0200
schrieb Rocco Folino :

> Package: wnpp
> Severity: wishlist
> Owner: Rocco Folino 
> 
> 
> * Package name: tinycalc
>   Version : 0.1
>   Upstream Author : Rocco Folino 
> * URL : http://tinycalc.sourceforge.net
> * License : GPL
>   Programming Lang: C
>   Description : Command line calculator for developers
> 
> Tiny Calculator is a command line calculator for developers.
> It can resolve a complex expression mixing decimal, esadecimal an
> binary number. The result is automatic converted in decimal,
> esadecimal ad binary format. 

Sounds like apcalc which has been in Debian since more than 10 years...

 $ calc '0xff + min(10,20) + 0b0010'
267

 "Calc is an arbitrary precision arithmetic system that uses a C-like
 language. Calc is useful as a calculator, an algorithm prototyper and
 as a mathematical research tool. More importantly, calc provides one
 with a machine independent means of computation. Calc comes with a
 rich set of builtin mathematical and programmatic functions.
 ..."

Is there any benefit for another command-line calculator?

bye,

-christian-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Bryan Donlan]

On Wed, Jun 24, 2009 at 6:28 AM, Guus Sliepen wrote:
> On Wed, Jun 24, 2009 at 11:03:41AM +0100, Steve Langasek wrote:
>
>> On Wed, Jun 24, 2009 at 09:02:26AM +1000, Aníbal Monsalve Salazar wrote:
>> > * Package name    : libposix
>>
>> Why?
>>
>> This is a subset of the interfaces provided by glibc, which must be present
>> on all systems.  So it would be stupid for any package in Debian to link
>> against libposix instead of just using libc.  Why do we want a library in
>> Debian that no packages should depend on?
>
> Just see it as dash vs. bash. Once libposix reaches maturity, I will certainly
> consider linking applications I wrote myself against libposix. Applications
> linked against it will probably use less memory and cannot inadvertently use
> glibc extensions. This will make it easier to port those applications, and 
> will
> also make it easier to run things on embedded platforms.

Is libposix complete enough to link against for real programs yet? If
not, why should it be included at this time?
Moreover, can libposix and libc coexist in the same address space? If
not, all of debian's existing libraries will be incompatible with it.
It seems like the sort of thing that you might want to build an entire
distro against, or a custom/development build against, but not just
some programs in a distro...


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Debconf-discuss] using OpenPGP notations to indicate keysigning practices

[Sami Liedes]

On Tue, Jun 23, 2009 at 07:55:57PM -0700, Don Armstrong wrote:
> On Tue, 23 Jun 2009, Russ Allbery wrote:
> > For example, I think US drivers' licenses are only verifiable by
> > someone who's lived in that state or otherwise seen drivers'
> > licenses from that state.
> 
> Nah; there's a guide published[1] which has all of them. [If you're a
> bar tender or a notary, you have to be able to check them.]

But from an international POV I don't know if that's very useful.
Would you accept 50 different IDs issued by, say, Portugal, in a KSP?

Sami


signature.asc
Description: Digital signature

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Guus Sliepen]

On Wed, Jun 24, 2009 at 09:17:14AM -0400, Bryan Donlan wrote:

> Is libposix complete enough to link against for real programs yet? If
> not, why should it be included at this time?

I agree that if the only thing that works at this moment is the simplest "Hello
world" program, that it should not be packaged yet.

> Moreover, can libposix and libc coexist in the same address space?

What address space are you talking about? There is also dietlibc and uClibc,
who can coexist with glibc. But applications can only link against one of them
at the time of course.

> If not, all of debian's existing libraries will be incompatible with it.
> It seems like the sort of thing that you might want to build an entire
> distro against, or a custom/development build against, but not just
> some programs in a distro...

Having a glibc replacement for just a few programs is not an argument in itself
for not including this package. Perhaps I want to develop a program that needs
to run in an embedded environment that I want to test? Then I'd like to have a
libposix-dev package that I can use to build my own software with.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Bryan Donlan]

On Wed, Jun 24, 2009 at 9:34 AM, Guus Sliepen wrote:
> On Wed, Jun 24, 2009 at 09:17:14AM -0400, Bryan Donlan wrote:
>
>> Is libposix complete enough to link against for real programs yet? If
>> not, why should it be included at this time?
>
> I agree that if the only thing that works at this moment is the simplest 
> "Hello
> world" program, that it should not be packaged yet.
>
>> Moreover, can libposix and libc coexist in the same address space?
>
> What address space are you talking about? There is also dietlibc and uClibc,
> who can coexist with glibc. But applications can only link against one of them
> at the time of course.

I mean, if a program is using libposix, can it also link, for example,
libpng, which is built against the normal libc?
If libposix uses the brk() area for malloc this isn't possible, but if
it uses anonymous mmaps exclusively then it might be doable (of
course, one would need to be careful to free with the correct malloc
implementation).

>> If not, all of debian's existing libraries will be incompatible with it.
>> It seems like the sort of thing that you might want to build an entire
>> distro against, or a custom/development build against, but not just
>> some programs in a distro...
>
> Having a glibc replacement for just a few programs is not an argument in 
> itself
> for not including this package. Perhaps I want to develop a program that needs
> to run in an embedded environment that I want to test? Then I'd like to have a
> libposix-dev package that I can use to build my own software with.

For embedded environments, one will generally want a cross-compiling
toolchain, not just a library. You can't use the libc headers in
/usr/include, or libc's crt*.o start routines, after all, and even
uclibc abandoned the approach of hacking a host toolchain into using
its libraries. And for an embedded environment, a lot of the time
you'll have a different architecture on the target than the host
anyway.

This is all moot if libposix is still too incomplete to be usable of course :)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [Debconf-discuss] using OpenPGP notations to indicate keysigning practices

[Gunnar Wolf]

Russ Allbery dijo [Tue, Jun 23, 2009 at 06:23:31PM -0700]:
> > I will always challenge the "government-issued ID" due to the vastly
> > differing standards across the globe, but "travel document" is
> > actually a term that someone uttered earlier, which raises the bar a
> > lot higher.
> 
> For example, I think US drivers' licenses are only verifiable by someone
> who's lived in that state or otherwise seen drivers' licenses from that
> state.  I really dislike seeing people use them at key signings and
> would rather see people use passports.  I suspect you're going to see a
> ton of them in the 2010 Debconf key signing, though, since a lot of
> people in the US simply never bother to get a passport.

Driving licenses are expressly not accepted as official ID documents
in Mexico, even if they are government-issued.

-- 
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Michael Poole]

Guus Sliepen writes:

>> Moreover, can libposix and libc coexist in the same address space?
>
> What address space are you talking about? There is also dietlibc and uClibc,
> who can coexist with glibc. But applications can only link against one of them
> at the time of course.

I suspect the concern here is dynamically linked libraries.

Suppose myapp is linked against libposix (for whatever reason).
Suppose libfoo.so is linked against glibc (for whatever different
reason).  Finally, suppose that myapp links against libfoo.so.  When
this happens, what breaks, how badly, and how obviously?

Michael Poole


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#534429: ITP: haskell-utf8-string -- Haskell Library for operating on UTF8 strings

[Tom Rauchenwald]

Erik de Castro Lopo  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Erik de Castro Lopo 
>
>
> * Package name: haskell-utf8-string
>   Version : 0.3.5
>   Upstream Author : Galois Inc. 
> * URL : 
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string
> * License : BSD
>   Programming Lang: Haskell
>   Description : Haskell Library for operating on UTF8 strings
>
>  A UTF8 layer for IO and Strings. The utf8-string package provides operations
>  for encoding UTF8 strings to Word8 lists and back, and for reading and 
> writing
>  UTF8 without truncation.
> 

Hi,

this is the same as libghc6-utf8-string-dev  isn't it?

-tom

-- 
Let's just hope that all the world is run by Bill Gates 
before the Perl hackers can destroy it.
-- Erik Naggum


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: cc vs gcc

[Goswin von Brederlow]

"brian m. carlson"  writes:

> On Sun, Jun 21, 2009 at 10:29:37PM +0300, Peter Eisentraut wrote:
>> There is a bit of discussion in bug #487546 about whether using cc or gcc as 
>> the compiler is appropriate.
>> 
>> Particular questions:
>> 
>> * Are Debian packages supposed to be built by default using /usr/bin/gcc (or 
>> whatever gcc is first in the path)?  Or is it valid to use cc?
>
> cc has traditionally been the system-default compiler for a Unix system.
> Generally, it will support those options specified by POSIX for c99,
> since those are a fairly barebones set of options, but it is not
> mandated to (since it is not specified).
>
> Since Debian has it specified as an alternative, I would assume that any
> C compiler which implements those options would be satisfactory.
> Whether cc is a valid choice depends on whether the code will work with
> any such compiler.  If a program requires GCC, then it should specify
> gcc; if any old compiler will work, then cc should be fine.

That fails the reproducable test.

All uploaded packages should always be build with the same compiler,
the debian default gcc, unless a specific compiler is specified in
rules.

So I would say using cc is wrong.

MfG
Goswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: cc vs gcc

[Peter Clapham]

Hello Goswin,

Would you mind putting this into a ticket for us please.

Many thanks

Pete

"brian m. carlson"  writes:

  

On Sun, Jun 21, 2009 at 10:29:37PM +0300, Peter Eisentraut wrote:

There is a bit of discussion in bug #487546 about whether using cc or gcc as 
the compiler is appropriate.


Particular questions:

* Are Debian packages supposed to be built by default using /usr/bin/gcc (or 
whatever gcc is first in the path)?  Or is it valid to use cc?
  

cc has traditionally been the system-default compiler for a Unix system.
Generally, it will support those options specified by POSIX for c99,
since those are a fairly barebones set of options, but it is not
mandated to (since it is not specified).

Since Debian has it specified as an alternative, I would assume that any
C compiler which implements those options would be satisfactory.
Whether cc is a valid choice depends on whether the code will work with
any such compiler.  If a program requires GCC, then it should specify
gcc; if any old compiler will work, then cc should be fine.



That fails the reproducable test.

All uploaded packages should always be build with the same compiler,
the debian default gcc, unless a specific compiler is specified in
rules.

So I would say using cc is wrong.

MfG
Goswin


  




--
The Wellcome Trust Sanger Institute is operated by Genome Research 
Limited, a charity registered in England with number 1021457 and a 
company registered in England with number 2742969, whose registered 
office is 215 Euston Road, London, NW1 2BE. 



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Cyril Brulebois]

Guus Sliepen  (24/06/2009):
> On Wed, Jun 24, 2009 at 09:17:14AM -0400, Bryan Donlan wrote:
> 
> > Is libposix complete enough to link against for real programs yet? If
> > not, why should it be included at this time?
> 
> I agree that if the only thing that works at this moment is the simplest 
> "Hello
> world" program, that it should not be packaged yet.

Looking at the latest news I could find on the website[1]:
| Multiplatform support for libposix
| 
| Posted by hdante on June 6, 2009
| 
| I'm happy to announce that libposix is able to run "Hello World" in
| three different platforms: linux x86, linux x86_64 and FreeBSD x86.

 1. http://libposix.sourceforge.net/

I guess you have your answer.

(Don't Cc me if you keep d-d@ in the loop, thanks already.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

Bug#534472: ITP: ttf-monapo - Japanese TrueType font, monapo

[Hideki Yamane]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: ttf-monapo
Version: 20090423
Upstream Author: UTUMI Hirosi 
 Information-technology Promotion Agency, Japan.
 Anonymous  
URL: http://www.geocities.jp/ep3797/modified_fonts_01.html
License: IPA Font License (OSI approval) 
 http://www.opensource.org/licenses/ipafont.html
Description: Japanese TrueType font, monapo
 Monapo font is a combined font, that uses IPAfont and monafont.
 It has almost same width as MS P Gothic, so it can show 
Japanese 
 Ascii Art properly.

-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/iijmio-mail.jp
 http://wiki.debian.org/HidekiYamane




-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: cc vs gcc

[Alberto Garcia]

On Wed, Jun 24, 2009 at 04:45:26PM +0200, Goswin von Brederlow wrote:

> All uploaded packages should always be build with the same compiler,
> the debian default gcc, unless a specific compiler is specified in
> rules.
> 
> So I would say using cc is wrong.

Moreover, in the case of C++ (also mentioned in the bug report) there
used to be ABI compatibility problems even between different versions
of GCC (though to be honest I don't know if that's still true).

So you if you compile two packages using different compilers (via
/usr/bin/c++) you could have problems using them together.

Berto


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

/emul/ia32-linux to lib32 transition

[Artur R. Czechowski]

Hello,
I made a quick glance at /emul/ia32-linux to lib32 transition in BTS.
There was some bugreports submitted. All I spotted can be seen using
following link: http://42.pl/u/1GEo
Shouldn't all of them be set to RC severity as they are uninstallable at
the moment?

Additionaly, I've found that ia32-libs and ia32-libs-gtk has no bugreport
for transition submitted.

Regards
Artur
-- 
Święta mogą być Twoje! Pakiet podstawowy już od 9,99 (bez karpia i choinki)
/yacoob/


signature.asc
Description: Digital signature

Re: [Debconf-discuss] using OpenPGP notations to indicate keysigning practices

[Peter Eisentraut]

On Wednesday 24 June 2009 16:58:52 Gunnar Wolf wrote:
> Driving licenses are expressly not accepted as official ID documents
> in Mexico, even if they are government-issued.

That just begs the question: official to whom, and why?  Ultimately, the 
office clerk, the bar tender, or the key signer will have to use best 
judgement whether the evidence produced establishes a link between a person 
and an identity.  Of course the bar tender for example might have a legal 
framework about what to accept and not to accept.  But I don't think it is 
going to be successful to enforce a law like that for key signing.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Steve Langasek]

On Wed, Jun 24, 2009 at 12:28:24PM +0200, Guus Sliepen wrote:
> > This is a subset of the interfaces provided by glibc, which must be present
> > on all systems.  So it would be stupid for any package in Debian to link
> > against libposix instead of just using libc.  Why do we want a library in
> > Debian that no packages should depend on?

> Just see it as dash vs. bash.

I *don't* see it as this, because I can't see any way that libposix will
ever be useful to have used by other Debian packages.  dash is useful to
have as the *default* /bin/sh on Debian systems; libposix would not be
useful to have by default.

> Once libposix reaches maturity, I will certainly consider linking
> applications I wrote myself against libposix. Applications linked against
> it will probably use less memory

Why would they use less memory?

> and cannot inadvertently use glibc extensions.

So instead you get to reimplement all the extensions you need, in the name
of "portability"?

> and will also make it easier to run things on embedded platforms.

Why does this make anything easier?  If you're rebuilding your whole system
against libposix, you're not doing that in the archive, so packaging
libposix seems largely irrelevant to this; if you aren't rebuilding your
whole system against libposix, you get two libcs, so that's hardly a win for
embedded systems.

On Wed, Jun 24, 2009 at 03:34:32PM +0200, Guus Sliepen wrote:
> > Moreover, can libposix and libc coexist in the same address space?

> What address space are you talking about? There is also dietlibc and
> uClibc, who can coexist with glibc.

uclibc doesn't appear to be packaged.

dietlibc is packaged - in a manner that appears to violate pretty much all
the principles of Policy 8.1 and shared library best practices in general.
(No distinguishing soname distinct from the .so used at build time, to allow
for ABI changes; one of the libs is installed executable (why? it's libdl,
ok, but is that actually used as the dynamic linker for dietlibc-linked
executables?); the libs are installed under /usr/lib/diet/lib, which seems
to imply use of rpath.)

I'm skeptical of the utility of such a level of coexistence.

> Having a glibc replacement for just a few programs is not an argument in 
> itself
> for not including this package. Perhaps I want to develop a program that needs
> to run in an embedded environment that I want to test? Then I'd like to have a
> libposix-dev package that I can use to build my own software with.

If there are to be embedded environments that will use libposix, then that's
an argument for packaging it - but since these environments don't exist
today, it seems premature to me to put the package in Debian.  Are there any
use cases for this that are both non-theoretical and non-crackful?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Guus Sliepen]

On Wed, Jun 24, 2009 at 05:47:16PM -0400, Steve Langasek wrote:

> > Once libposix reaches maturity, I will certainly consider linking
> > applications I wrote myself against libposix. Applications linked against
> > it will probably use less memory
> 
> Why would they use less memory?

Since they don't link against a large library. Granted, that is only a benefit
if all running programs link against libposix instead of glibc.

> > and cannot inadvertently use glibc extensions.
> 
> So instead you get to reimplement all the extensions you need, in the name
> of "portability"?

Yes, if that is what it takes for my application to work on platforms that do
not have glibc.

> > and will also make it easier to run things on embedded platforms.
> 
> Why does this make anything easier?  If you're rebuilding your whole system
> against libposix, you're not doing that in the archive, so packaging
> libposix seems largely irrelevant to this; if you aren't rebuilding your
> whole system against libposix, you get two libcs, so that's hardly a win for
> embedded systems.

If I'm compiling I'd rather do it on a fast desktop with all my usual stuff
installed than on an embedded system.

> If there are to be embedded environments that will use libposix, then that's
> an argument for packaging it - but since these environments don't exist
> today, it seems premature to me to put the package in Debian.  Are there any
> use cases for this that are both non-theoretical and non-crackful?

Although I disagree with your other reasons for not including this library in 
Debian,
I agree that it shouldn't be packaged yet since it is quite unusable in this 
stage :)

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Bryan Donlan]

On Wed, Jun 24, 2009 at 6:24 PM, Guus Sliepen wrote:
> On Wed, Jun 24, 2009 at 05:47:16PM -0400, Steve Langasek wrote:
>
>> > Once libposix reaches maturity, I will certainly consider linking
>> > applications I wrote myself against libposix. Applications linked against
>> > it will probably use less memory
>>
>> Why would they use less memory?
>
> Since they don't link against a large library. Granted, that is only a benefit
> if all running programs link against libposix instead of glibc.

What makes you think libposix will be smaller? It is currently very
incomplete; by the time it reaches a full implementation of POSIX, it
may well be the same size as libc.

>> > and will also make it easier to run things on embedded platforms.
>>
>> Why does this make anything easier?  If you're rebuilding your whole system
>> against libposix, you're not doing that in the archive, so packaging
>> libposix seems largely irrelevant to this; if you aren't rebuilding your
>> whole system against libposix, you get two libcs, so that's hardly a win for
>> embedded systems.
>
> If I'm compiling I'd rather do it on a fast desktop with all my usual stuff
> installed than on an embedded system.

Again, this is what a cross-compile toolchain is for (mandatory if
your embedded platform is anything other than your desktop arch!). You
could adapt the crosstool buildscripts that uclibc uses, for example.
If you just use debian's normal GCC, you're going to have a hell of a
time convincing it to not use libc's include files/statically-linked
startup objects/dynamic linker.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Pierre Habouzit]

On Thu, Jun 25, 2009 at 12:24:40AM +0200, Guus Sliepen wrote:
> On Wed, Jun 24, 2009 at 05:47:16PM -0400, Steve Langasek wrote:
> 
> > > Once libposix reaches maturity, I will certainly consider linking
> > > applications I wrote myself against libposix. Applications linked against
> > > it will probably use less memory
> > 
> > Why would they use less memory?
> 
> Since they don't link against a large library.

Which is a ridiculous argument given what the S in .so means. As soon as
at least one always running program on your system uses glibc, you want
to only use glibc if you want to save memory. It's simple as that.


-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Switching the default /bin/sh to dash

[Raphael Geissert]

Hello everybody,

I think everyone readying this list is more than aware of the intention to 
switch to dash as the default /bin/sh.
A lot of work has been done on many sides to make this switch doable and as 
smooth as possible and plenty of people has been contributing by testing, 
filing bugs, providing patches, fixing bugs and by using dash.

After a discussion on IRC of the main blockers to make this change happen 
*really soon now*, we (Luk Claes and I) have not identified any major 
blocker. We are therefore proposing to:

Switch the default /bin/sh to dash in the following weeks

What actually needs to be done is:
* Make dash essential and make it replace the current /bin/sh symlink.

What won't change:
* Bash will still be used as the default interactive shells for users

Side effects:
* Errors caused by the use of bashisms.
* Faster boot, builds, and general usage of /bin/sh scripts.
* Reduced memory footprint when running /bin/sh scripts.

Counter side effects:
* During the following weeks I will be working on providing patches for the 
known issues (check the list at [1]),
* and performing another archive-wide checkbashisms check on binary packages,
* debian/rules,
* and then an archive rebuild with dash as /bin/sh should follow.

Policy references:
* Section 10.4[2]:
 "Scripts may assume that /bin/sh implements the SUSv3 Shell Command Language"
 "If a shell script requires non-SUSv3 features from the shell interpreter 
other than those listed above, the appropriate shell must be specified in the 
first line of the script"

Facts:
* Dash's inst popcon from Debian: 10679
* Over 724 issues detected and fixed
* It's been more than three years since Ubuntu made the switch,
   without all the extra bashisms-hunting Debian has done,
   without rolling it back.

References of interest:
[1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-rele...@lists.debian.org&tag=goal-dash
[2]http://www.debian.org/doc/debian-policy/ch-files.html#s-scripts
[3]https://wiki.ubuntu.com/DashAsBinSh
[4]http://manpages.debian.net/cgi-bin/man.cgi?query=checkbashisms
[5]http://release.debian.org/lenny/goals.txt
[6]http://lists.debian.org/debian-release/2009/04/msg00133.html

Summarising:
Unless a major blocker shows up, the switch is going to be done on the 
following weeks.

Regards,
-- 
Raphael Geissert - Debian Maintainer
www.debian.org - get.debian.net


signature.asc
Description: This is a digitally signed message part.

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Guus Sliepen]

On Wed, Jun 24, 2009 at 06:33:44PM -0400, Bryan Donlan wrote:

> >> Why would they use less memory?
> >
> > Since they don't link against a large library. Granted, that is only a 
> > benefit
> > if all running programs link against libposix instead of glibc.
> 
> What makes you think libposix will be smaller? It is currently very
> incomplete; by the time it reaches a full implementation of POSIX, it
> may well be the same size as libc.

Glibc implements much more than just POSIX, and it is not known for its
leanness, hence the existence of dietlibc, uClibc, etc.

> > If I'm compiling I'd rather do it on a fast desktop with all my usual stuff
> > installed than on an embedded system.
> 
> Again, this is what a cross-compile toolchain is for (mandatory if
> your embedded platform is anything other than your desktop arch!). You
> could adapt the crosstool buildscripts that uclibc uses, for example.
> If you just use debian's normal GCC, you're going to have a hell of a
> time convincing it to not use libc's include files/statically-linked
> startup objects/dynamic linker.

That's true. Probably something the upstream maintainer should consider to
provide.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Pierre Habouzit]

On Thu, Jun 25, 2009 at 12:41:43AM +0200, Pierre Habouzit wrote:
> On Thu, Jun 25, 2009 at 12:24:40AM +0200, Guus Sliepen wrote:
> > On Wed, Jun 24, 2009 at 05:47:16PM -0400, Steve Langasek wrote:
> > 
> > > > Once libposix reaches maturity, I will certainly consider linking
> > > > applications I wrote myself against libposix. Applications linked 
> > > > against
> > > > it will probably use less memory
> > > 
> > > Why would they use less memory?
> > 
> > Since they don't link against a large library.
> 
> Which is a ridiculous argument given what the S in .so means. As soon as
> at least one always running program on your system uses glibc, you want
> to only use glibc if you want to save memory. It's simple as that.

PS: I read the full mail, and the postulate that all Debian can link
against libposix is wrong to begin with, because too many GNU stuff
heavily relies on GNU extensions to the libc. That's exactly why
kFreeBSD uses a GNU libc instead of the BSD one


-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Re: Bug#534429: ITP: haskell-utf8-string -- Haskell Library for operating on UTF8 strings

[Erik de Castro Lopo]

Tom Rauchenwald wrote:

> this is the same as libghc6-utf8-string-dev  isn't it?

Yes it is. I realised my mistake and closed the ITP bug. Sorry
everyone.

Cheers,
Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Pierre Habouzit]

On Thu, Jun 25, 2009 at 12:54:35AM +0200, Guus Sliepen wrote:
> On Wed, Jun 24, 2009 at 06:33:44PM -0400, Bryan Donlan wrote:
> 
> > >> Why would they use less memory?
> > >
> > > Since they don't link against a large library. Granted, that is only a 
> > > benefit
> > > if all running programs link against libposix instead of glibc.
> > 
> > What makes you think libposix will be smaller? It is currently very
> > incomplete; by the time it reaches a full implementation of POSIX, it
> > may well be the same size as libc.
> 
> Glibc implements much more than just POSIX, and it is not known for its
> leanness, hence the existence of dietlibc, uClibc, etc.

Most of its fat comes from stuff like Sun RPC, or gconv, that thanks to
eglibc you can switch off. I'm not saying libposix is a stupid idea,
just that it's meaningless to package it in Debian (especially in its
current state, but that's _really_ orthogonal).

-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems

[Samuel Thibault]

Pierre Habouzit, le Thu 25 Jun 2009 00:41:43 +0200, a écrit :
> > > Why would they use less memory?
> > 
> > Since they don't link against a large library.
> 
> Which is a ridiculous argument given what the S in .so means.

And linking against a 100MB library will generally _not_ eat 100MB
memory during execution.

Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#534507: ITP: kalternatives -- graphical alternatives system configuration tool

[Pino Toscano]

Package: wnpp
Severity: wishlist
Owner: Pino Toscano 

* Package name: kalternatives
  Version : 0.12
  Upstream Author : Pino Toscano 
* URL : 
http://kde-apps.org/content/show.php/Kalternatives?content=16016
* License : GPL
  Programming Lang: C++
  Description : graphical alternatives system configuration tool

 Kalternatives offers a GUI to configure the alternative systems (a
 system that allows you to select one alternative file for many in the
 filesystem).
 .
 This is an advanced GUI of the update-alternatives program shipped with dpkg.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Michael Biebl]

Raphael Geissert wrote:
> Hello everybody,
> 
> I think everyone readying this list is more than aware of the intention to 
> switch to dash as the default /bin/sh.

> 
> Summarising:
> Unless a major blocker shows up, the switch is going to be done on the 
> following weeks.

\o/, finally.

Thanks for all your hard work,

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Linkcserére felkérés

[Sandor Kerekes]

Üdvözlöm!

Miközben potenciális link partnert kerestem az ügyfelem weboldalának 
(casino oldal), rátaláltam a maga weboldalára.
Úgy gondoltam, megpróbálom felkérni Önt egy linkcserére, ami 
mindkettőnk számára hasznos lenne a Google internetes kereső 
rangsorolásában és így több forgalmat hozva a weboldalainknak!
Én elhelyezném az Ön linkjét az én oldalamon: http://www.domoart.hu 
-n.(PR 3)

Ha érdekli a dolog, kérem válaszoljon!

Előre is köszönöm!

Biztos vagyok benne, hogy ez egy hosszú üzleti kapcsolat kezdete!
Köszönöm figyelmét és kívánok további sok sikert!

Tisztelettel:

Kerekes Sándor


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[John Goerzen]

On Wed, Jun 24, 2009 at 05:51:58PM -0500, Raphael Geissert wrote:
> Side effects:
> * Errors caused by the use of bashisms.

And the really important side-effect is that user scripts on all sorts
of installed systems could experience trouble.

> * Faster boot, builds, and general usage of /bin/sh scripts.

That could be accomplished by just setting the bangpath different,
right?

> * Reduced memory footprint when running /bin/sh scripts.

That's a nice thing.

Both of these are nice to have, of course, but we need to make sure
this is documented explicitly, well, and in BIG UPPERCASE LETTERS in
the release notes.  This could be a significant issue at companies
that have done a lot of scripting outside the archive.

> * It's been more than three years since Ubuntu made the switch,
>without all the extra bashisms-hunting Debian has done,
>without rolling it back.

Not necessarily relevant.  They have a reputation (whether deserved or
not is a different discussion) of breaking people's machines on
upgrade, and don't have the server penetration Debian does either.

-- John


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Raphael Geissert]

Hi,

I just noticed I forgot to say something:

> What won't change:
> * Bash will still be used as the default interactive shells for users
* the sh symlink won't be modified on existing installations

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Raphael Geissert]

John Goerzen wrote:

> On Wed, Jun 24, 2009 at 05:51:58PM -0500, Raphael Geissert wrote:
>> Side effects:
>> * Errors caused by the use of bashisms.
> 
> And the really important side-effect is that user scripts on all sorts
> of installed systems could experience trouble.

You are right, you made me notice I forgot to mention something:
* the sh symlink won't be modified on existing installations

> 
>> * Faster boot, builds, and general usage of /bin/sh scripts.
> 
> That could be accomplished by just setting the bangpath different,
> right?

Of every single /bin/sh script? sure

> 
>> * Reduced memory footprint when running /bin/sh scripts.
> 
> That's a nice thing.
> 
> Both of these are nice to have, of course, but we need to make sure
> this is documented explicitly, well, and in BIG UPPERCASE LETTERS in
> the release notes.  This could be a significant issue at companies
> that have done a lot of scripting outside the archive.

Of course this is going to be mentioned on the release notes (just like the
switch to rsyslog as the default syslogd); but like I just said, the change
will only immediately affect new installations.

> 
>> * It's been more than three years since Ubuntu made the switch,
>>without all the extra bashisms-hunting Debian has done,
>>without rolling it back.
> 
> Not necessarily relevant.  They have a reputation (whether deserved or
> not is a different discussion) of breaking people's machines on
> upgrade, and don't have the server penetration Debian does either.

It's relevant in the sense that
* we are not making a "never done before" move,
* many issues have been fixed because of their change,
* many upstreams are now aware of bashisms.

I won't object any of your other statements, but in this case we are not
discussing if what Ubuntu did was right or wrong, nor anything else. And as
such, what matters is that they made the move and it has worked for over
three years.

Thanks for your comments, and I hope that with the extra clarification I've
addressed your concerns.

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Hendrik Sattler]

Am Donnerstag 25 Juni 2009 05:21:45 schrieb Raphael Geissert:
> I just noticed I forgot to say something:
> > What won't change:
> > * Bash will still be used as the default interactive shells for users
>
> * the sh symlink won't be modified on existing installations

So that it will be even more strange that a script with bashisms works on some 
Debian Squeeze systems but not on others? Yeah, great idea.
And so that all users that upgrade do not benefit from the goal of this change? 
Even better.
I usually don't like those not-on-upgrade exceptions.

HS


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Raphael Geissert]

Hendrik Sattler wrote:

> Am Donnerstag 25 Juni 2009 05:21:45 schrieb Raphael Geissert:
>> I just noticed I forgot to say something:
>> > What won't change:
>> > * Bash will still be used as the default interactive shells for users
>>
>> * the sh symlink won't be modified on existing installations
> 
> So that it will be even more strange that a script with bashisms works on
> some Debian Squeeze systems but not on others? Yeah, great idea.

reportbug indicates what /bin/sh points to, and it should be irrelevant,
since many people have been using all sort of shell interpreters as /bin/sh
for many many years.

> And so that all users that upgrade do not benefit from the goal of this
> change? Even better.

This is to avoid causing undesirable effects when upgrading. People have
always been concerned about such kind of changes, and they are more than
right. The goal is not to cause a chaos.

> I usually don't like those not-on-upgrade exceptions.
> 

I'd prefer if comments were restricted to objective arguments and not
subjective; specially when they include unneeded sarcasm.

Regards,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Mike Hommey]

On Thu, Jun 25, 2009 at 06:47:07AM +0200, Hendrik Sattler wrote:
> Am Donnerstag 25 Juni 2009 05:21:45 schrieb Raphael Geissert:
> > I just noticed I forgot to say something:
> > > What won't change:
> > > * Bash will still be used as the default interactive shells for users
> >
> > * the sh symlink won't be modified on existing installations
> 
> So that it will be even more strange that a script with bashisms works on 
> some 
> Debian Squeeze systems but not on others? Yeah, great idea.
> And so that all users that upgrade do not benefit from the goal of this 
> change? 
> Even better.
> I usually don't like those not-on-upgrade exceptions.

I'd say if /bin/sh points to the current default (/bin/bash), then it
should be modified. OTOH, if it was modified locally by the admin to
point somewhere else, leave it alone.

Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Frank Lin PIAT]

On Thu, 2009-06-25 at 06:47 +0200, Hendrik Sattler wrote:
> Am Donnerstag 25 Juni 2009 05:21:45 schrieb Raphael Geissert:
> > I just noticed I forgot to say something:

(BTW, scripts not only loads faster under dash, they also run faster in
Dash.)

> > > What won't change:
> > > * Bash will still be used as the default interactive shells for users
> >
> > * the sh symlink won't be modified on existing installations
> 
> So that it will be even more strange that a script with bashisms works on 
> some 
> Debian Squeeze systems but not on others? 

Upgraded systems don't behave exactly like new systems, this isn't
specific for Debian.
The release notes can document those changed behaviors, isn't it? (the
NEWS.Debian too)
And every one RTFM.

> And so that all users that upgrade do not benefit from the goal of this 
> change? 

This is the difference between upgrading a system, and installing a new
system:

When upgrading a system, you want your existing applications to keep
working the same way, so you prefer to keep the "backward compatible
way" (see John Goerzen's concerns about "entreprise-made" shell
scripts).

On the other hand, when an application is installed [on a fresh system],
it is ok to introduce new behavior, since it is much more easier to
detect incompatible scripts as you write/install them.

> I usually don't like those not-on-upgrade exceptions.

FYI, I have worked on modular tool (a Posix script;), that can test and
warn such changes on upgraded systems. I would a test for [bd]ash.
  http://wiki.debian.org/UpgradeAdvisor


Regards,

Franklin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Luk Claes]

Mike Hommey wrote:
> On Thu, Jun 25, 2009 at 06:47:07AM +0200, Hendrik Sattler wrote:
>> Am Donnerstag 25 Juni 2009 05:21:45 schrieb Raphael Geissert:
>>> I just noticed I forgot to say something:
 What won't change:
 * Bash will still be used as the default interactive shells for users
>>> * the sh symlink won't be modified on existing installations
>> So that it will be even more strange that a script with bashisms works on 
>> some 
>> Debian Squeeze systems but not on others? Yeah, great idea.
>> And so that all users that upgrade do not benefit from the goal of this 
>> change? 
>> Even better.
>> I usually don't like those not-on-upgrade exceptions.
> 
> I'd say if /bin/sh points to the current default (/bin/bash), then it
> should be modified. OTOH, if it was modified locally by the admin to
> point somewhere else, leave it alone.

How do you make the difference between an administrator choosing for the
default and one choosing for bash specifically?

I think it's best to either leave it alone (preferred option) or ask the
administrator (using debconf) if he wants to change to the default. In
any case it should be mentioned in the Release Notes and other
documentation regarding Squeeze.

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Artur R. Czechowski]

On Thu, Jun 25, 2009 at 07:31:15AM +0200, Mike Hommey wrote:
> On Thu, Jun 25, 2009 at 06:47:07AM +0200, Hendrik Sattler wrote:
> > Am Donnerstag 25 Juni 2009 05:21:45 schrieb Raphael Geissert:
> > > I just noticed I forgot to say something:
> > > > What won't change:
> > > > * Bash will still be used as the default interactive shells for users
> > > * the sh symlink won't be modified on existing installations
[cut]
> I'd say if /bin/sh points to the current default (/bin/bash), then it
> should be modified. OTOH, if it was modified locally by the admin to
> point somewhere else, leave it alone.
What about debconf question?

Regards
Artur


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Stig Sandbeck Mathisen]

Mike Hommey  writes:

> I'd say if /bin/sh points to the current default (/bin/bash), then it
> should be modified. OTOH, if it was modified locally by the admin to
> point somewhere else, leave it alone.

That would potentially break locally written or installed scripts.  Not
touching the /bin/sh link on upgrade seems less harmful.

-- 
Stig Sandbeck Mathisen


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Switching the default /bin/sh to dash

[Christian Perrier]

Quoting Raphael Geissert (atom...@gmail.com):

> Switch the default /bin/sh to dash in the following weeks


/me applauses

(I'm using dash as /bin/sh for about NN years now: IIRC I switched after
Marga's work in the GSOC about the boot process speed up)




signature.asc
Description: Digital signature