Re: default character encoding for everything in debian

[Giacomo A. Catenazzi]

Bastian Blank wrote:
> On Tue, Aug 11, 2009 at 09:40:35PM +0200, Bernd Eckenfels wrote:
>> In article <20090811183800.ge5...@const.famille.thibault.fr> you wrote:
>>> Not necessarily.  Any sane implementation should just use wchar_t
>> Which could be UTF16 and therefore still has complicatd length semantics. 
> 
> No, wchar_t is UCS-4 (or UCS-2 in esoteric implementations like
> Windows).

No wchar_t is locale dependent (per POSIX).

BTW on gcc:

-fwide-exec-charset=charset
Set the wide execution character set, used for wide string and
character constants. The default is UTF-32 or UTF-16, whichever
corresponds to the width of wchar_t. As with -fexec-charset, charset can
be any encoding supported by the system's iconv library routine;
however, you will have problems with encodings that do not fit exactly
in wchar_t.

Note that default encoding is UTF-8, thus giving a UTF-32 wchar_t
in most developer machines.

ciao
cate


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

Re: default character encoding for everything in debian

[Giacomo A. Catenazzi]

Samuel Thibault wrote:
> Gunnar Wolf, le Tue 11 Aug 2009 13:28:08 -0500, a écrit :
>> while length(str) in any language up to the 1990s was a mere
>> substraction, now we must go through the string checking each byte to
>> see if it is a Unicode marker and substract the appropriate number of
>> bytes.
> 
> Not necessarily.  Any sane implementation should just use wchar_t and
> substraction gets back.

An implementation that use wchar_t is usually not sane, but usually
it is (also) buggy. It is very difficult (AFAIK not impossible,
but I'm not so sure) to write portable (POSIX way, so with changing
locales) programs using wchar_t.

The only way I know is to use sanely the wchar_t is to use as the simple
C standard requirements: only one runtime environment and locale.

PS: note that the binary encoding depend on compiler environment (but
such info is not exported).

ciao
cate


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

Re: Virtual package dyndns-client

[Timur Birsh]

Ben Hutchings wrote:

> If the virtual package name is to be meaningful, there must be some
> definition of what capabilities a dyndns-client provides to depending
> packages, e.g. a
> specific command and options.  Does that exist?

I think yes. There are wide range of broadband connection users without the 
static IP (ADSL, etc) who want provide some services to them friends, e.g. 
the FTP or the SSH services. At least in my country, there are a lot of such 
users through boom of the ADSL connections :)

-- 
Timur


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

Re: Debian packaging license (was: Re: RFC: DEP-3: Patch Tagging Guidelines).

[Romain Beauxis]

Le lundi 10 août 2009 09:58:04, Jonathan Yu a écrit :
> On Mon, Aug 10, 2009 at 1:13 AM, Charles Plessy wrote:
> > Le Tue, Jun 16, 2009 at 11:33:58AM +0800, Paul Wise a écrit :
> >> On Tue, Jun 16, 2009 at 7:20 AM, Charles Plessy wrote:
> >> > The dh_make template for debian/copyright induces many developers to
> >> > put their packaging work under the GPL, and I have already seen
> >> > packages whose license is otherwise BSD-ish with such patches. If the
> >> > maintainer suddenly goes MIA and the patch is non-trivial, then in
> >> > theory if we want to respect what is written, we are stuck with a
> >> > GPL'ed patch. Therefore, we have an optional License field to make
> >> > things crystal clear if necessary.
> >>
> >> Sounds like dh_make needs a bug report about the default packagaging
> >> license, could you file one?
> >
> > Dear all,
> >
> > we just had a case in the Debian Med packaging team where the upstream
> > author of software licensed under terms similar to the BSD license got
> > upset to see the Debian packaging licenced under the GPL, and posted a
> > reminder that GPLed contributions to his software will not be accepted.
>
> Yes, this is precisely why the pkg-perl team usually goes with "same
> terms as Perl itself" (Artistic | GPL) and whatever the upstream
> licensing terms are (usually Artistic | GPL but sometimes BSD).
>
> So for example if upstream is BSD-licensed, then I'd personally put
> something like:
> Artistic | GPL | BSD
> for the debian/* files
>
> My reasoning is that the upstream can get stuff like patches back into
> their software (the BSD) provision but also allows anyone that can use
> Perl to use the patch (Artistic | GPL). Further, if upstream decides
> later to change to the "same as Perl" license (it is probably the most
> popular license on CPAN), it is okay for them to do so (with our
> patches).
>
> In the case of Debian-Med (being an outsider and not knowing what the
> team works with), I'd say explicitly licensing your debian/* files
> under the same license as upstream would be appropriate, or perhaps a
> combination of upstream | GPL licensing. This is clearly a discussion
> we all need to have within teams/package groups/etc -- namely, what do
> we want our debian/* files to be licensed under.

And also what exactly is covered by the license claim. For instance, in the 
case of patches contained in debian/, I have some doubts about the license 
that applies. 

Usually, when one wants to propose a patch to a project, it has to do it under 
the original licence. That's particularly the case if the patch consists, for 
instance, of the diff of a commit from the current developpement code of the 
same upstream project...

Hence, are patches in debian/ covered by the license claimed for the project 
upstream, or for the debian packaging ?


Romain


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

Re: Automatic Debug Packages

[Russ Allbery]

Josselin Mouette  writes:
> Le mardi 11 août 2009 à 17:26 -0700, Russ Allbery a écrit :

>> I don't understand how what you say is related to what I said.  How
>> does having them in a separate archive affect whether or not I have to
>> download a 50GB package to get debugging symbols for KDE?  Whether that
>> download happens automatically or not, it's still a serious issue for
>> some network bandwidth profiles.

> By transparently, I mean without having to download the whole packages.

Oh, interesting.  This is the first that I've heard of that.  How would
that be done and how would the files be managed on disk on the client
system if they weren't part of a package?

> Most of our users wouldn’t have the bandwidth to debug KDE or GNOME
> packages otherwise.

If there's one debugging package per binary package, wouldn't the amount
of download bandwidth required be roughly equivalent, or at least close
enough, to any feasible per-file download mechanism for large library
collections?

>> Or using one debugging package per binary package by default, which
>> provides a level of granularity that makes this just not an issue.

> And creates other issues.

You've named one so far about which I'm dubious.  Are there any others?

-- 
Russ Allbery (r...@debian.org)   


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

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 17:26 -0700, Russ Allbery a écrit :
> > The main purpose of setting up an archive of debugging symbols is to be
> > able to use them transparently without installation, so that doesn’t
> > change much.
> 
> I don't understand how what you say is related to what I said.  How does
> having them in a separate archive affect whether or not I have to download
> a 50GB package to get debugging symbols for KDE?  Whether that download
> happens automatically or not, it's still a serious issue for some network
> bandwidth profiles.

By transparently, I mean without having to download the whole packages.
Most of our users wouldn’t have the bandwidth to debug KDE or GNOME
packages otherwise.

> > That said, it’s clearly a good reason to allow splitting ddebs manually
> > at the maintainer’s discretion for some of the largest packages.
> 
> Or using one debugging package per binary package by default, which
> provides a level of granularity that makes this just not an issue.

And creates other issues.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Automatic Debug Packages

[Russ Allbery]

Josselin Mouette  writes:
> Le mardi 11 août 2009 à 16:13 -0700, Russ Allbery a écrit :

>> Without the symlink, they're not valid Debian packages.  It seems like
>> a small price to pay for keeping them consistent with the rest of
>> Policy.

> The policy is just a document. The question is more about what this
> symlink would bring.

I don't agree with that decision-making process.  Absent some reason why
we should *not* be consistent, consistency should win by default.

> BTW, udebs don’t have a /usr/share/doc directory, so that makes a
> precedent.

udebs explicitly do not comply with Debian Policy; that is, in fact, part
of the point of udebs.  But so far there doesn't seem to be any reason for
debugging packages to not comply with Debian Policy (as opposed to udebs,
where there are many very good reasons).

(I also think that the way we handled udebs was and is suboptimal, and had
I been a Policy delegate at the time they were introduced, I would have
pushed for much clearer documentation of the udeb package format in
Policy.  But water under the bridge.)

>> In this case, I believe that, in order to comply with some of our
>> DFSG-free licenses, we will have to ship a copyright file in the debug
>> package.

> I’m not sure of what is necessary here. How do we deal with that
> specific issue in udebs?

I don't know what we do with udebs.

By my reading, we can't legally distribute binary packages covered under
the Expat license, for instance, without including a copy of the copyright
notice:

  Permission to use, copy, modify, and distribute this software and its
  documentation for any purpose and without fee is hereby granted,
  provided that the above copyright notice appear in all copies [...]

We've decided that shipping packages with a hard dependency on another
package that has the copyright notice satisfies this requirement, but a
debugging package for a whole source package can't easily have the same
hard dependency.  I suppose if it has a hard dependency on one of a set of
other packages, each of which has the copyright notice, that might be
sufficiently, although we miss the clean symlink pointer to where that
copyright notice is.

>> Also, some source packages are *huge*, and I don't want to have to
>> install 50GB of debugging information for, say, all of KDE just because
>> I want the debugging symbols for a single library.  I suppose that's
>> why you have the escape clause of letting maintainers do it differently
>> if they desire, but there I really would like to see us treat the
>> entire archive identically if at all possible.

> The main purpose of setting up an archive of debugging symbols is to be
> able to use them transparently without installation, so that doesn’t
> change much.

I don't understand how what you say is related to what I said.  How does
having them in a separate archive affect whether or not I have to download
a 50GB package to get debugging symbols for KDE?  Whether that download
happens automatically or not, it's still a serious issue for some network
bandwidth profiles.

> That said, it’s clearly a good reason to allow splitting ddebs manually
> at the maintainer’s discretion for some of the largest packages.

Or using one debugging package per binary package by default, which
provides a level of granularity that makes this just not an issue.

-- 
Russ Allbery (r...@debian.org)   


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

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 16:13 -0700, Russ Allbery a écrit :
> > Actually I don’t see the point in this symlink. It only makes things
> > more complicated, especially if there is no one-to-one mapping between
> > ddebs and debs.
> 
> Without the symlink, they're not valid Debian packages.  It seems like a
> small price to pay for keeping them consistent with the rest of Policy.

The policy is just a document. The question is more about what this
symlink would bring.

BTW, udebs don’t have a /usr/share/doc directory, so that makes a
precedent.

> > If we use build IDs (and this has quite some advantages, like being able
> > to do more than just dump the ddebs on a repository), this can lead to
> > having the same detached debugging symbols in two binary packages, since
> > sometimes a binary is built twice the same exact way and put in two
> > different binary packages.
> 
> Hm, really?  The toolchains that I'm familiar with basically never produce
> the same binary twice; something is always slightly different from
> timestamp information.  Could you give an example of such a case in the
> archive right now where identical binaries are in multiple packages so
> that I can better understand how this happens?

ISTR seeing this with evince/evince-gtk before the plugins were put in a
single package for both versions. Anyway I’ll let Emilio answer since he
did some testing about that specific issue.

> > The consensus on #debian-dak when we discussed this specific issue was
> > to use one ddeb for each source package by default, and to let the door
> > open to the maintainer overriding this default with several ddebs in a
> > source, using a new header in the control file. This way we can keep
> > things as simple as possible, without losing the possibility to handle
> > corner cases that will arise.
> 
> In this case, I believe that, in order to comply with some of our
> DFSG-free licenses, we will have to ship a copyright file in the debug
> package.

I’m not sure of what is necessary here. How do we deal with that
specific issue in udebs?

> Also, some source packages are *huge*, and I don't want to have to install
> 50GB of debugging information for, say, all of KDE just because I want the
> debugging symbols for a single library.  I suppose that's why you have the
> escape clause of letting maintainers do it differently if they desire, but
> there I really would like to see us treat the entire archive identically
> if at all possible.

The main purpose of setting up an archive of debugging symbols is to be
able to use them transparently without installation, so that doesn’t
change much.

That said, it’s clearly a good reason to allow splitting ddebs manually
at the maintainer’s discretion for some of the largest packages.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: default character encoding for everything in debian

[Harald Braumann]

On Tue, 11 Aug 2009 13:28:08 -0500
Gunnar Wolf  wrote:

> Harald Braumann dijo [Tue, Aug 11, 2009 at 01:33:58AM +0200]:
> > > There are a lot of users out there that are not willing to pay the
> > > price for increased generality.
> > 
> > Don't you mean s/users/programmers? As a user I don't see what
> > price I pay. I only see advantages in having a consistent encoding.
> > Which, btw., doesn't have to be UTF-8. In an ideal world every
> > programme would adhere to LC_CTYPE. But if the encoding has to be
> > configured then I would also prefer UTF-8 as the default.
> > 
> > Of course, for the programmer there might be a price to pay. And if
> > he's not willing to pay it, he can't be forced, anyway.
> > 
> > Or do you mean the user pays the price, because if the encoding is
> > set to UTF-8 then performance would suffer? In that case, I'd love
> > to see some real life numbers. I doubt the difference would be
> > noticeable. 
> 
> Yes, performance will suffer. We enjoyed many decades of blissfully
> ignoring the difference between a character and a byte. 

Well, a byte with the most significant bit always set to 0.

> So, while
> length(str) in any language up to the 1990s was a mere substraction,
> now we must go through the string checking each byte to see if it is a
> Unicode marker and substract the appropriate number of bytes. Also,
> for a very long time we didn't really care much what was a buffer's
> content - 

And in these glorious times more often than not unintelligible
rubbish was produced if you happened to not use a language that can be
written in ASCII. But this is besides the point. I do appreciate that
support for different character encodings causes pain for the
programmer. But the original post was about software that already
has got support for UTF-8 and whether it wouldn't be good idea to
configure it this way by default.
 
> Everything could be printed, even if it had control
> characters which made you beep (with the ocassional control sequence
> re-injecting output into the terminal as input). Now... Well, printing
> an unprintable string can cause segfaults in some cases.

My terminal supports UTF-8. I thought that this is not an issue any
more.

Cheers,
harry


signature.asc
Description: PGP signature

Re: Bits from the release team and request for discussion

[Stephen Gran]

This one time, at band camp, Anthony Towns said:
> Any thoughts? We could have such a vote over and done in about two weeks,
> with the DPL's consent, and it'd seem a lot more inclusive and less
> cabal-tastic than how things seem to be working atm...

Is there some reason we need something as heavyweight as a GR?  This
looks like a doodle poll that accidentally got ideas of grandeur and
thought it was helping Debian.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :sg...@debian.org |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Automatic Debug Packages

[Russ Allbery]

Josselin Mouette  writes:
> Le mardi 11 août 2009 à 13:03 -0700, Russ Allbery a écrit :

>> * These packages are normal Debian packages with normal package metadata,
>>   but will generally have a symlink in /usr/share/doc/ pointing
>>   to the package for which they provide debugging information.

> Actually I don’t see the point in this symlink. It only makes things
> more complicated, especially if there is no one-to-one mapping between
> ddebs and debs.

Without the symlink, they're not valid Debian packages.  It seems like a
small price to pay for keeping them consistent with the rest of Policy.

>> * What about contrib and non-free packages?  Do they just lose here?

> How about yes?

I'm okay with that as an answer.  I just want to document it if so.

> If we use build IDs (and this has quite some advantages, like being able
> to do more than just dump the ddebs on a repository), this can lead to
> having the same detached debugging symbols in two binary packages, since
> sometimes a binary is built twice the same exact way and put in two
> different binary packages.

Hm, really?  The toolchains that I'm familiar with basically never produce
the same binary twice; something is always slightly different from
timestamp information.  Could you give an example of such a case in the
archive right now where identical binaries are in multiple packages so
that I can better understand how this happens?

> The consensus on #debian-dak when we discussed this specific issue was
> to use one ddeb for each source package by default, and to let the door
> open to the maintainer overriding this default with several ddebs in a
> source, using a new header in the control file. This way we can keep
> things as simple as possible, without losing the possibility to handle
> corner cases that will arise.

In this case, I believe that, in order to comply with some of our
DFSG-free licenses, we will have to ship a copyright file in the debug
package.

Also, some source packages are *huge*, and I don't want to have to install
50GB of debugging information for, say, all of KDE just because I want the
debugging symbols for a single library.  I suppose that's why you have the
escape clause of letting maintainers do it differently if they desire, but
there I really would like to see us treat the entire archive identically
if at all possible.

-- 
Russ Allbery (r...@debian.org)   


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

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 13:03 -0700, Russ Allbery a écrit :
> * These packages are normal Debian packages with normal package metadata,
>   but will generally have a symlink in /usr/share/doc/ pointing
>   to the package for which they provide debugging information.

Actually I don’t see the point in this symlink. It only makes things
more complicated, especially if there is no one-to-one mapping between
ddebs and debs.

> Open questions:
> 
> * Can we limit this package namespace to *only* detached debugging
>   symbols, not all the other sorts of debugging packages that people
>   create with special compiler options or optional code features?

I think we should. The purpose of the proposal is to automate as much as
possible, not to open a new section where anyone can dump anything.

> * What about contrib and non-free packages?  Do they just lose here?

How about yes?

> * Can we require a one-to-one correspondance between binary package names
>   and debug package names that provide symbols for that binary package?  I
>   think we should; I think it would make the system more straightforward.

If we use build IDs (and this has quite some advantages, like being able
to do more than just dump the ddebs on a repository), this can lead to
having the same detached debugging symbols in two binary packages, since
sometimes a binary is built twice the same exact way and put in two
different binary packages. Using a single ddeb for the source package
avoids such issues. Alternatives imply to generate automatically lots of
Replaces and Conflicts fields, and this is just too fragile.

The consensus on #debian-dak when we discussed this specific issue was
to use one ddeb for each source package by default, and to let the door
open to the maintainer overriding this default with several ddebs in a
source, using a new header in the control file. This way we can keep
things as simple as possible, without losing the possibility to handle
corner cases that will arise.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: default character encoding for everything in debian

[Adam Borowski]

On Mon, Aug 10, 2009 at 09:04:37PM +0100, Roger Leigh wrote:
> If having a C.UTF-8 locale always available for system services is
> required for them to fully support UTF-8, then that needs adding to
> glibc.

It would also bring significant speed increase.  Since about everything
calls setlocale(), having the locale internal speeds up the typical process
startup sequence by 20%!  And that's 20% of the whole thing from fork(),
through link, up to getopt(), so it's not a speedup you can shake a stick at.
I'm speaking about having the locale supported natively by glibc, of course;
what the udeb does is merely shipping a generated locale file.

> For a locale available after /usr is mounted, a simple localedef
> invocation is all that's needed; for all times, after starting init,
> it needs the tables compiling into glibc as for the standard C locale.
> I've been looking at how to do the latter, but I'm not expert with the
> "3-level" locale tables and other glibc internals, so if anyone who
> knows the details of glibc locales could provide me with
> assistance/guidance here, that would be much appreciated.
> 
> For reference, this is bug #522776.  This would be great to have as a
> release goal for Squeeze, and (speculatively) a native C UTF-8 locale
> for Squeeze+1 to give us a default pure UTF-8 system from end-to-end.

I'm not an expert with glibc internals too, but a couple of years ago I
researched the issue a bit.  Apparently, there are only two first-class
locales: C and POSIX, all other get loaded from the disk.  In the past,
en_US.ISO-8859-1 and ru_RU.KOI8-R were such first-class ones as well, but
that's no more.  What I'd propose would be making C.UTF-8 built in.

Another possible optimization would be building the table used by 8-bit
isalpha/etc on the fly for all locales.  Iconving 128 characters is
certainly faster than opening a file on the disk, and (sanely) glibc doesn't
support character classification contrary to Unicode so this could result in
completely nuking all LC_CTYPE files for other locales as well.

-- 
1KB // Microsoft corollary to Hanlon's razor:
//  Never attribute to stupidity what can be
//  adequately explained by malice.


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

Re: Automatic Debug Packages

[Russ Allbery]

Philipp Kern  writes:
> On 2009-08-11, Russ Allbery  wrote:

>>> If it's legal to ship debugging symbols for them, I can't see why we
>>> couldn't support them normally.

>> The point is that you can't do this with an archive area, at least
>> using the simple algorithm I proposed above.

> Well you can.  I always thought concrete sections etc. are an
> implementation detail that has nothing to do with policy, but ok.

> Volatile uses volatile/main/ (which is a pain yet to be solved
> by moving to ftp-master), but you could as well do
> debug//.

Policy currently says this is a syntax error, so if volatile packages are
supposed to comply with Policy, could you file a bug against Policy so
that we can update this?  :)

-- 
Russ Allbery (r...@debian.org)   


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

Re: Automatic Debug Packages

[Philipp Kern]

["Followup-To:" header set to gmane.linux.debian.devel.general.]
On 2009-08-11, Russ Allbery  wrote:
>> If it's legal to ship debugging symbols for them, I can't see why we
>> couldn't support them normally.
> The point is that you can't do this with an archive area, at least using
> the simple algorithm I proposed above.

Well you can.  I always thought concrete sections etc. are an implementation
detail that has nothing to do with policy, but ok.

Volatile uses volatile/main/ (which is a pain yet to be solved by
moving to ftp-master), but you could as well do debug//.

Kind regards,
Philipp Kern


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

Re: default character encoding for everything in debian

[Jakub Wilk]

* Bastian Blank , 2009-08-11, 22:24:

> Not necessarily.  Any sane implementation should just use wchar_t
Which could be UTF16 and therefore still has complicatd length semantics.


No, wchar_t is UCS-4 (or UCS-2 in esoteric implementations like
Windows).


And in the most esoteric (while still conforming to the C standard) 
implementations it is not related to Unicode at all.


--
Jakub Wilk


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

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Russ Allbery wrote:
> Emilio Pozuelo Monfort  writes:
> 
>> You can build a .ddeb manually, yes. However for some cases
>> (e.g. packages using debhelper and building ELF binaries) a .ddeb will
>> be automatically created (if none is created manually) and detached
>> debugging symbols will be put there. I'll try to automatize other
>> languages too, so that having full archive coverage is as simpler as
>> possible.
> 
> Could you explain a bit more about what merits you see in creating
> something that we call a different type of package rather than just
> listing debug packages in debian/control and building them as we do now
> and handling section debug specially in the archive software?  Is it just
> the avoiding of the need to add a bunch of debian/control entries?

Yes, automatically doing it is the main idea. And by automatically I mean with
zero changes, not even adding a package to debian/control. We will still support
packages listing ddebs in debian/control and building them manually of course,
since we can't cover 100% of the archive automagically.

Emilio



signature.asc
Description: OpenPGP digital signature

Bug#541124: ITP: excalibur-logger -- Excalibur project's log management system

[Onkar Shinde]

Package: wnpp
Severity: wishlist
Owner: Onkar Shinde 


* Package name: excalibur-logger
  Version : 2.1
  Upstream Author : The Apache Software Foundation
* URL : http://excalibur.apache.org/
* License : Apache-2.0
  Programming Lang: Java
  Description : Excalibur project's log management system

Excalibur-Logger integrates neatly into the Avalon ECM and Excalibur-Fortress.
The main goal is to be able to define the log categories on a component basis
by specifying a 'logger' attribute which denotes the log category to use for
a particular component (given the component is LogEnabled or Loggable).



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

Re: Automatic Debug Packages

[Russ Allbery]

Emilio Pozuelo Monfort  writes:
> Russ Allbery wrote:

>> * These packages are normal Debian packages with normal package metadata,
>>   but will generally have a symlink in /usr/share/doc/ pointing
>>   to the package for which they provide debugging information.

> We haven't agreed on whether there should be one ddeb per source or per
> binary package, so I would leave this still opened.

Okay, although I certainly hope that we can agree on that.

>> * They will go into a separate "debug" archive area, so the Section of
>>   such packages will be debug/ where  is the section of the
>>   corresponding binary package for which they provide debugging data.
>
> Not sure about the archive area bit. What I talked with the ftpmasters
> was that they would be in a totally different archive, so instead of
> "ftp.debian.org/debian unstable main", you would have something like
> "ftp.debian.org/debian-debug unstable main". I don't think that's an
> "archive area" in Policy terms.

It's not.

Sounds like we need some input from ftpmaster here about how this will be
handled.  I would have thought it would be easier on the dak side to use
an archive area rather than a separate archive, but that would solve the
problem for contrib/non-free.

>> * Those packages must be listed in *.changes like any other packages that
>>   are part of an upload.  They may or may not be present in debian/control
>>   and in *.dsc depending on the mechanism the package maintainer uses to
>>   generate them.
>
> I guess that doesn't imply they need to be listed in Binary and
> Description, but that Files and Checksum-* are enough? If so, perfect.

They need not be listed in Binary.  I'm not sure if they'd need to be
listed in Description if we use an archive area, since that gives the
archive area to use, but it may be that dak can just special-case that
based on the package name.

>> * Can we limit this package namespace to *only* detached debugging
>>   symbols, not all the other sorts of debugging packages that people
>>   create with special compiler options or optional code features?
>
> Why should we limit it?  There currently are about 85 python -dbg
> packages. A lot more could be added. Why limit .ddebs to ELF binaries?
> Same for mono, I've added a (trivial) patch to dh_clistrip to support
> ddebs. We would gain support for many packages with exactly zero changes
> (or just a change to remove the -dbg where they exist). What are the
> benefits of such a limitation?

If you can produce a specific enumerated list of things like Python
debugging symbols and Mono debugging symbols that can go into these
packages, and the paths into which such things go, I'm okay with
documenting all of that.

If, however, these packages are just full separate Debian packages that
could contain anything at all the maintainer wanted to put in there, such
as binaries built with different options or with trace flags enabled by
default, I'm opposed to this proposal.  I don't think such packages should
be treated specially in Policy at all; at that point, they're just normal
Debian packages that should be listed in debian/control like any other and
the Policy change should be limited to adding a new section or archive
area for them if appropriate.

I don't think packages should get any special treatment or blessing, and
certainly not automated construction by helper programs, unless they are
known to contain a precise and limited type of information and never
anything else without a Policy change.  Otherwise, we have two classes of
packages for no particularly good reason, and we should instead just treat
them all as regular Debian packages, some of which possibly going into a
separate archive area.

>> * What about contrib and non-free packages?  Do they just lose here?

> If it's legal to ship debugging symbols for them, I can't see why we
> couldn't support them normally.

The point is that you can't do this with an archive area, at least using
the simple algorithm I proposed above.

>> * Can we require a one-to-one correspondance between binary package names
>>   and debug package names that provide symbols for that binary package?  I
>>   think we should; I think it would make the system more straightforward.
>
> I guess the Packages file could grow a "Has-DDeb: yes" line (or the
> Sources file if we go for one ddeb per source package).

I suppose, but that seems unrelated.  The debugging package archive or
archive area will have its own Packages file, and it seems fairly obvious
to me that that Packages file should list all the debug packages like a
normal archive Packages file.

-- 
Russ Allbery (r...@debian.org)   


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

Re: default character encoding for everything in debian

[Samuel Thibault]

Bernd Eckenfels, le Tue 11 Aug 2009 21:40:35 +0200, a écrit :
> In article <20090811183800.ge5...@const.famille.thibault.fr> you wrote:
> > Not necessarily.  Any sane implementation should just use wchar_t
> 
> Which could be UTF16 and therefore still has complicatd length semantics. 

??

wchar_t may be 32 or 16bit (in which case it can't express unicode after
U+), but it's still meant to have the simple length semantics.

> And even with UTF32 there are combining characters.

Which account for one character. Then there is a problem of rendering
width of course, but as I said it's there anyway as soon as you have
a font with varying letter widths, string manipulation don't pose any
problem anyway.

> But the length could be defined in code units - its just a question
> how usefull it is.

Of course.  It's rarely useful to take into account character width
yourself, unless you are rendering on a tty, but then speed usually
doesn't matter and you can afford calling wcswidth() on your string
as late as possible.

Samuel


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

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Russ Allbery wrote:
> Emilio Pozuelo Monfort  writes:
>> Russ Allbery wrote:
> 
>>> It sounds like listing them only in *.changes but not in *.dsc or
>>> debian/control may be the easiest approach.
>> Indeed, for the automatic-not-listed-in-debian-control ones. The others
>> would be listed everywhere, but that is okay.
> 
> Yes, agreed.
> 
> Okay, to summarize what I think we've generally agreed on:
> 
> * Packages containing separate debugging symbols will have a dedicated
>   package namespace, but that namespace will not be *-debug or *-dbg.
>   We'll instead create a new one for this purpose.
> 
> * These packages are normal Debian packages with normal package metadata,
>   but will generally have a symlink in /usr/share/doc/ pointing
>   to the package for which they provide debugging information.

We haven't agreed on whether there should be one ddeb per source or per binary
package, so I would leave this still opened.

> * They will go into a separate "debug" archive area, so the Section of
>   such packages will be debug/ where  is the section of the
>   corresponding binary package for which they provide debugging data.

Not sure about the archive area bit. What I talked with the ftpmasters was that
they would be in a totally different archive, so instead of
"ftp.debian.org/debian unstable main", you would have something like
"ftp.debian.org/debian-debug unstable main". I don't think that's an "archive
area" in Policy terms.

> * Those packages must be listed in *.changes like any other packages that
>   are part of an upload.  They may or may not be present in debian/control
>   and in *.dsc depending on the mechanism the package maintainer uses to
>   generate them.

I guess that doesn't imply they need to be listed in Binary and Description, but
that Files and Checksum-* are enough? If so, perfect.

> * The detached debugging symbols may use either the id or the debuglink
>   mechanisms -- see Manoj's message for a summary.
> 
> Open questions:
> 
> * Can we limit this package namespace to *only* detached debugging
>   symbols, not all the other sorts of debugging packages that people
>   create with special compiler options or optional code features?

Why should we limit it? There currently are about 85 python -dbg packages. A lot
more could be added. Why limit .ddebs to ELF binaries? Same for mono, I've added
a (trivial) patch to dh_clistrip to support ddebs. We would gain support for
many packages with exactly zero changes (or just a change to remove the -dbg
where they exist). What are the benefits of such a limitation?

> * What about contrib and non-free packages?  Do they just lose here?

If it's legal to ship debugging symbols for them, I can't see why we couldn't
support them normally.

> * Can we require a one-to-one correspondance between binary package names
>   and debug package names that provide symbols for that binary package?  I
>   think we should; I think it would make the system more straightforward.

I guess the Packages file could grow a "Has-DDeb: yes" line (or the Sources file
if we go for one ddeb per source package). Or we could have a different file for
this similar to the Maintainers one, I guess, since the trend seems to be to
split those files nowadays.

> At some point, someone should probably open a Policy bug to track this
> discussion and the resolution.

I would be happy to do that. I guess it can wait a bit until we have a bit more
consensus, or should I do it now and update it with whatever conclusions we 
reach?

Best,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: default character encoding for everything in debian

[Bastian Blank]

On Tue, Aug 11, 2009 at 09:40:35PM +0200, Bernd Eckenfels wrote:
> In article <20090811183800.ge5...@const.famille.thibault.fr> you wrote:
> > Not necessarily.  Any sane implementation should just use wchar_t
> Which could be UTF16 and therefore still has complicatd length semantics. 

No, wchar_t is UCS-4 (or UCS-2 in esoteric implementations like
Windows).

Bastian

-- 
Phasers locked on target, Captain.


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

Bug#541121: ITP: bdii -- integrator of LDAP databases

[Steffen Moeller]

Package: wnpp
Severity: wishlist
Owner: Steffen Moeller 

* Package name: bdii
  Version : 4.0.2
* URL : https://twiki.cern.ch/twiki//bin/view/EGEE/BDII
* License : needs to be clarified, still
  Description : integrator of LDAP databases

The Berkeley Database Information Index (BDII) consists of a standard
LDAP database which is updated by an external process. The update process
obtains LDIF from a number of sources and merges them. It then compares
this to the contents of the database and creates an LDIF file of the
differences. This is then used to update the database.



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

Re: Automatic Debug Packages

[Russ Allbery]

Emilio Pozuelo Monfort  writes:
> Russ Allbery wrote:

>> It sounds like listing them only in *.changes but not in *.dsc or
>> debian/control may be the easiest approach.
>
> Indeed, for the automatic-not-listed-in-debian-control ones. The others
> would be listed everywhere, but that is okay.

Yes, agreed.

Okay, to summarize what I think we've generally agreed on:

* Packages containing separate debugging symbols will have a dedicated
  package namespace, but that namespace will not be *-debug or *-dbg.
  We'll instead create a new one for this purpose.

* These packages are normal Debian packages with normal package metadata,
  but will generally have a symlink in /usr/share/doc/ pointing
  to the package for which they provide debugging information.

* They will go into a separate "debug" archive area, so the Section of
  such packages will be debug/ where  is the section of the
  corresponding binary package for which they provide debugging data.

* Those packages must be listed in *.changes like any other packages that
  are part of an upload.  They may or may not be present in debian/control
  and in *.dsc depending on the mechanism the package maintainer uses to
  generate them.

* The detached debugging symbols may use either the id or the debuglink
  mechanisms -- see Manoj's message for a summary.

Open questions:

* Can we limit this package namespace to *only* detached debugging
  symbols, not all the other sorts of debugging packages that people
  create with special compiler options or optional code features?

* What about contrib and non-free packages?  Do they just lose here?

* Can we require a one-to-one correspondance between binary package names
  and debug package names that provide symbols for that binary package?  I
  think we should; I think it would make the system more straightforward.

At some point, someone should probably open a Policy bug to track this
discussion and the resolution.

-- 
Russ Allbery (r...@debian.org)   


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

Re: default character encoding for everything in debian

[Bernd Eckenfels]

In article <20090811183800.ge5...@const.famille.thibault.fr> you wrote:
> Not necessarily.  Any sane implementation should just use wchar_t

Which could be UTF16 and therefore still has complicatd length semantics. 
And even with UTF32 there are combining characters.  Sadly.  But the length
could be defined in code units - its just a question how usefull it is.

Gruss
Bernd


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

Re: default character encoding for everything in debian

[Bernd Eckenfels]

In article <20090811182041.gd19...@cajita.gateway.2wire.net> you wrote:
> encodings are _completely_ incompatible with UTF8, so it is just not
> possible to tolerate broken text every now and then. Everything just
> breaks completely.

Or everything works out of the box, when you use it correctly...

Gruss
Bernd


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

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Russ Allbery wrote:
>> Having them in the Binary section in the .dsc and Binary and Description
>> in the .changes files would mean modifying
>> dpkg-buildpackage/dpkg-genchanges for ddebs not listed in
>> debian/control. However listing them in Files and Checksum-* in the
>> .changes requires no changes if you add the files to debian/files and
>> use dpkg-genchanges.
> 
> It sounds like listing them only in *.changes but not in *.dsc or
> debian/control may be the easiest approach.

Indeed, for the automatic-not-listed-in-debian-control ones. The others would be
listed everywhere, but that is okay.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Manoj Srivastava]

On Tue, Aug 11 2009, Steve Langasek wrote:


> But if this is all the more respect you have for your fellow (TC
> members|DDs|human beings), O Peerless and Saintly Policy Editor, then
> perhaps the project should reconsider whether that's a position you should
> hold.

The -vote list is -> that-away.

>
>> saying that policy team members should not do something that I had not
>> actually advocated (I never said that dpkg implementation was a
>> prerequisite to adding things to policy --- I just asked why that is
>> not the reasonable thing to do first).
>
>   "If we are going to enshrine ddebs into policy, we might as well
>   teach dpkg about ddebs."
>
>   http://lists.debian.org/debian-policy/2009/08/msg00044.html
>
> That was not a question.  But apparently, any statements you've made in
> emails more than a day old are "strawmen" that you're not responsible for.

It was a suggestion. It was not a dictum "do this or the rule
 shall not enter policy". The correct response is to point out why there
 is no need to teach dpkg anything, or why doing so is suboptimal (the
 former applies here).


>> >> Seems like if policy carves out a namespace for debug packages,
>> >>  it would serve for both automatically generated and hand crafted debug
>> >>  packages; and it is trivial for the automatic generation not to happen
>> >>  when there is an entry in debian/control for a debug package already,
>> >>  as long as there is a naming convention for debug packages.
>
>> > That's fair, but it doesn't guard against package name collisions with
>> > packages built from a *different* source package; so if manually-built
>> > packages are allowed to use the same namespace, there ought to be a policy
>> > in place that prevents them from being provided in a way that confuses the
>> > automated build process.
>> 
>> Umm, huh? If the name space carved out is foo-debug, or even
>>  foo-dbg, the only collision I see is a *different* package has a native name
>>  of foo-dbg and thus collides with the debugging symbols from foo.
>
>> If such packages existed, then not only would they create
>>  trouble with the current slew of debug packages, they can always be
>>  resolved by our normal disambiguation rules.
>
> The normal disambiguation rules involve telling someone to stop
> building a conflicting package.  If one of the parties is an automated
> build, that doesn't work so well.  Either the namespace should be
> clearly reserved, or the automatic build hooks are going to have to
> maintain a blacklist of packages not to act on.

The namespace for packages containing debug symbols out to be
 clearly resolved, and separated from the other non-debug-symbol
 packages, irrespective of the tools used to generate the debug symbol
 package.

The auto-tools would still have to look into debian/control, but
 that is an implementation detail.

manoj
-- 
A man wrapped up in himself makes a very small package.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Virtual package dyndns-client

[Russ Allbery]

Timur Birsh  writes:
> Torsten Landschoff wrote:

>> Timur Birsh brought it to my attention that my package ddclient
>> provides a virtual package "dyndns-client" that is not on the official
>> virtual package list at
>> http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
>> 
>> It seems that I have missed the requirement to request a new virtual
>> package here at the time I introduced the provides.
>> 
>> Therefore I now request that the virtual package
>> 
>>   dyndns-client
>> 
>> is added to the official list of virtual packages in Debian. If
>> consensus happens to be that this has no merits, I will of course
>> remove the Provides on ddclient.
>
> Can anyone please comment on this?

You need to file a bug against Debian Policy to update the virtual package
list.

-- 
Russ Allbery (r...@debian.org)   


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

Bug#541111: ITP: excalibur-logkit -- Lightweight and fast designed logging toolkit for Java

[Onkar Shinde]

Package: wnpp
Severity: wishlist
Owner: Onkar Shinde 


* Package name: excalibur-logkit
  Version : 2.0
  Upstream Author : The Apache Software Foundation
* URL : http://excalibur.apache.org/
* License : Apache-2.0
  Programming Lang: Java
  Description : Lightweight and fast designed logging toolkit for Java

Excalibur Logkit (previously avalon logkit) is a lightweight, fast, securely
designed logging toolkit. It is designed to integrate into existing 
applications.
Logkit is more lightweight than Log4j.



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

Re: Virtual package dyndns-client

[Ben Hutchings]

On Tue, Aug 11, 2009 at 08:34:47PM +0600, Timur Birsh wrote:
> Hi all,
> 
> Torsten Landschoff wrote:
> 
> > Timur Birsh brought it to my attention that my package ddclient provides
> > a virtual package "dyndns-client" that is not on the official virtual
> > package list at
> > http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
> > 
> > It seems that I have missed the requirement to request a new virtual
> > package here at the time I introduced the provides.
> > 
> > Therefore I now request that the virtual package
> > 
> >   dyndns-client
> > 
> > is added to the official list of virtual packages in Debian. If consensus
> > happens to be that this has no merits, I will of course remove the
> > Provides on ddclient.
> 
> Can anyone please comment on this?

If the virtual package name is to be meaningful, there must be some definition
of what capabilities a dyndns-client provides to depending packages, e.g. a
specific command and options.  Does that exist?

Ben.

-- 
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.


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

Re: Automatic Debug Packages

[Russ Allbery]

Emilio Pozuelo Monfort  writes:
> Manoj Srivastava wrote:

>> So I think at this point it is premature for policy to decide
>>  one way or the other about debug symbol packages being mentioned in
>>  the control file (and dsc and changes).

> They should be in the changes file so they are uploaded together with it
> to the archive (and so dak can process them). Not saying that should be
> mentioned in policy though :)

Well, there's little point in having a standards document if we don't use
it to describe what we're doing, not that we always manage to update it
sufficiently quickly.

> Having them in the Binary section in the .dsc and Binary and Description
> in the .changes files would mean modifying
> dpkg-buildpackage/dpkg-genchanges for ddebs not listed in
> debian/control. However listing them in Files and Checksum-* in the
> .changes requires no changes if you add the files to debian/files and
> use dpkg-genchanges.

It sounds like listing them only in *.changes but not in *.dsc or
debian/control may be the easiest approach.

-- 
Russ Allbery (r...@debian.org)   


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

Re: Ubuntu's crash reporting with "apport" -> Debian ?

[Philipp Kern]

On 2009-08-11, Steffen Moeller  wrote:
> KDE has improved rather dramatically with its crash reporting UI in its
> past few releases, I think. Now Ubuntu comes up with something along
> these lines for all kinds of applications: apport
> (https://launchpad.net/apport/).
> Is anything speaking against someone (me?) repackaging apport for Debian?

For that to be useful we need debug symbol creation first.  Refer to the
corresponding thread currently running on the same mailinglist.

Kind regards,
Philipp Kern



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

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Russ Allbery wrote:
> 
>> Emilio Pozuelo Monfort  writes:
>>> Manoj Srivastava wrote:
 To recap:
  1) packages with detached debugging symbols should be named
 ${package name}-${debug suffix}. As a corollary, no ordinary
 packages names may end in  ${debug suffix}.
>>> They may be automatically created. They may also be manually created (if
>>> they are listed in debian/control, so for complex packages where they
>>> need some manual work, it can be done).
>> Whether they're automatically or manually created is irrelevant for Debian
>> Policy.  Policy describes what the output should be, not what tools one
>> uses to get there.
>>
>> I think the relevant question for Policy is whether these packages will be
>> listed in debian/control in the source package, in Binary in the *.dsc
>> file, and in Binary/Files/Checksums-* in the *.changes file.  And I don't
>> know the answer to those three questions from the discussion so far.
> 
> Here is my take on this:
>  a) helper packages may be extended to created debug packages by
> default, whether or not they're mentioned in control. This means
> that any package rebuilt the next time will get debugging packages,
> even if the maintainer takes no action. Policy should not prevent
> this use case, so requiring that the control file mentions them
> should not be done.
>  b) Some upstream packages, even if helper packages are used, might not
> be readily amenable to automated generation of debug packages, and
> manual help might be required. In this category I would also like to
> throw in packages that do not use helper packages; since themanual
> crafting of debug symbol packages is a commonality. These packages
> have the debug packages in debian/control, and htey are built
> normally (either through custoim scripts, or helper packages). In
> this case, the helper should not automatically generate debug symbol
> packages; and thus give us a mechanism to over ride, on a package by
> package basis, the creation of automated debug packages.

ACK

> 
> So I think at this point it is premature for policy to decide
>  one way or the other about debug symbol packages being mentioned in the
>  control file (and dsc and changes).

They should be in the changes file so they are uploaded together with it to the
archive (and so dak can process them). Not saying that should be mentioned in
policy though :)

Having them in the Binary section in the .dsc and Binary and Description in the
.changes files would mean modifying dpkg-buildpackage/dpkg-genchanges for ddebs
not listed in debian/control. However listing them in Files and Checksum-* in
the .changes requires no changes if you add the files to debian/files and use
dpkg-genchanges.

> Another reason is that we should not be accepting any packages,
>  even debug packages, in the archive unless we have a check sum match in
>  a cryptographically signed file anyway.

Agreed. As per my previous paragraph, having them in Files and Checksum-* would
solve this.

Regards,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Steve Langasek]

On Tue, Aug 11, 2009 at 01:50:21PM -0500, Gunnar Wolf wrote:

> > I don't have a strong opinion on whether ddebs should be documented in
> > policy, but I certainly don't agree with requiring dpkg to understand them
> > as a prerequisite for implementing a general purpose, public archive for
> > auto-stripped debugging symbols packages.  There really is no reason for
> > dpkg to treat these packages specially - a simple namespace convention
> > imposed by Policy (i.e., reserving package names ending in "-ddeb" for use
> > by this archive, which is what has been proposed) is sufficient, and
> > requires no changes to dpkg, which is as it should be.

> > I think the .ddeb extension is a red herring.  There ought not be anything
> > new to teach dpkg, here; the only thing of relevance is that there not be
> > namespace clashes between the ddebs and the debs in the main archive, and
> > the filename is not relevant to that at all.

> I understand your concern about this extension, but I do see it as a
> merit. Of course, our tools must be aware of it.

Except no one has *any intention* of making our tools "be aware" of this
extension.  This is a different file name convention, with no other impact.

> And apt should know -before updating or whatnot- that a package was
> installed from a ddeb, if they are to share the base name.

It was not proposed to have the packages share the base name, and doing so
implies a much more onerous implementation in the package manager than we
would otherwise need.

-- 
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#541106: ITP: trend -- a general-purpose, efficient trend graph

[Yuri D'Elia]

Package: wnpp
Severity: wishlist
Owner: "Yuri D'Elia" 

* Package name: trend
  Version : 1.0
  Upstream Author : Yuri D'Elia 
* URL : http://www.thregr.org/~wavexx/software/trend/
* License : LGPL
  Programming Lang: C++
  Description : a general-purpose, efficient trend graph

trend is a general-purpose, efficient trend graph for "live" data. Data
is read in ASCII form from a file or continuously from a FIFO and
displayed in real-time into a multi-pass trend (much like a CRT
oscilloscope). trend can be used as a rapid analysis tool for
progressive or time-based data series together with trivial scripting.



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

Re: Automatic Debug Packages

[Gunnar Wolf]

Manoj Srivastava dijo [Tue, Aug 11, 2009 at 10:12:00AM -0500]:
> On Tue, Aug 11 2009, Roger Leigh wrote:
> 
> > On Tue, Aug 11, 2009 at 01:40:20PM +, Sune Vuorela wrote:
> >> On 2009-08-11, Manoj Srivastava  wrote:
> >> > So, we would still need to create   "/usr/lib/debug/"
> >> >  . /full/path/to/lib_or_binary/ in either case, and instead of the
> >> 
> >> no. it would be /usr/lib/debug/.build-id/NN/NN.debug
> >  ^
> > Why the need for a hidden directory in a public location?
> > What's wrong with /usr/lib/debug/build-id?
> >
> > I don't think the unnecessary obfuscation is warranted.
> 
> Because that is where gdb looks for them.

Umh, and for human joy, adding a symlink at
/usr/lib/debug/lib_or_binary_with_slashes_substituted_by_underscores
to it would be most welcome!

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Re: Automatic Debug Packages

[Steve Langasek]

On Mon, Aug 10, 2009 at 06:06:37PM -0500, Manoj Srivastava wrote:
> >> So, please keep heckling from the peanut gallery to a minimum,
> >>  please, and assume that policy editors have a modicum of sense when
> >>  dealing with their role duties.

> > If you were showing a modicum of sense, there would be no need to assume.

> > For example, not referring to a fellow member of the Technical Committee,
> > the constitutional authority on Debian technical policy, as "the peanut
> > gallery".

> The word you are looking for is not sense. It is respect.

> You expect respect based on the position you hold -- not the
>  arguments you made. I reject the notion that I should make exeptions
>  based on the office you hold (in other words, it is OK to call non-dd's
>  on the list members of the peanut gallery, but not the
>  oh-so-respectable ctte members such).

I don't think it's appropriate for you to refer to *any* participant on
debian-policy as "the peanut gallery".  I additionally think that referring
to a member of the TC that way is stupid.

My original post to this thread was a technical argument in direct response
to a series of technical propositions that you advanced.  This subthread has
since degenerated into a pissing contest, apparently because I've dared
trespass the bounds of the mailing list that is your marked territory.

Thanks for that.

But if this is all the more respect you have for your fellow (TC
members|DDs|human beings), O Peerless and Saintly Policy Editor, then
perhaps the project should reconsider whether that's a position you should
hold.

> saying that policy team members should not do something that I had not
> actually advocated (I never said that dpkg implementation was a
> prerequisite to adding things to policy --- I just asked why that is
> not the reasonable thing to do first).

  "If we are going to enshrine ddebs into policy, we might as well
  teach dpkg about ddebs."

  http://lists.debian.org/debian-policy/2009/08/msg00044.html

That was not a question.  But apparently, any statements you've made in
emails more than a day old are "strawmen" that you're not responsible for.

> >> Seems like if policy carves out a namespace for debug packages,
> >>  it would serve for both automatically generated and hand crafted debug
> >>  packages; and it is trivial for the automatic generation not to happen
> >>  when there is an entry in debian/control for a debug package already,
> >>  as long as there is a naming convention for debug packages.

> > That's fair, but it doesn't guard against package name collisions with
> > packages built from a *different* source package; so if manually-built
> > packages are allowed to use the same namespace, there ought to be a policy
> > in place that prevents them from being provided in a way that confuses the
> > automated build process.
> 
> Umm, huh? If the name space carved out is foo-debug, or even
>  foo-dbg, the only collision I see is a *different* package has a native name
>  of foo-dbg and thus collides with the debugging symbols from foo.

> If such packages existed, then not only would they create
>  trouble with the current slew of debug packages, they can always be
>  resolved by our normal disambiguation rules.

The normal disambiguation rules involve telling someone to stop building a
conflicting package.  If one of the parties is an automated build, that
doesn't work so well.  Either the namespace should be clearly reserved, or
the automatic build hooks are going to have to maintain a blacklist of
packages not to act 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

Re: Automatic Debug Packages

[Jonathan Yu]

On Tue, Aug 11, 2009 at 2:45 PM, Gunnar Wolf wrote:
> Russ Allbery dijo [Sat, Aug 08, 2009 at 05:51:33PM -0700]:
>> > You can build a .ddeb manually, yes. However for some cases
>> > (e.g. packages using debhelper and building ELF binaries) a .ddeb will
>> > be automatically created (if none is created manually) and detached
>> > debugging symbols will be put there. I'll try to automatize other
>> > languages too, so that having full archive coverage is as simpler as
>> > possible.
Automation is definitely the recipe for success when it comes to open source.
>>
>> Could you explain a bit more about what merits you see in creating
>> something that we call a different type of package rather than just
>> listing debug packages in debian/control and building them as we do now
>> and handling section debug specially in the archive software?  Is it just
>> the avoiding of the need to add a bunch of debian/control entries?
>
> I would add:
>
> • .ddebs could be autobuilt — I am not familiar with the procedure,
>  but I suppose a debian/control field would indicate whether this
>  package allows being built as a .ddeb (as there would be no way
>  i.e. to build a Perl module as a ddeb)
My question then is, would it be possible to get debugging symbols for
the C/XS stuff we compile? Especially for figuring out segfaults that
would be tremendously useful, even in the context of Perl modules.
>
> • Less namespace explosion. We would get rid of all the -debug
>  packages.
I understand what you mean, but I hope you don't intend get rid of
*all* those packages, because not all of them are what you expect them
to be. perl-debug for example is just Perl compiled with debugging
symbols enabled (you run it via debugperl rather than perl). Steve
Langasek mentioned this in a previous mail.
>
> --
> Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244
>
>
> --
> To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


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

Re: default character encoding for everything in debian

[Samuel Thibault]

Gunnar Wolf, le Tue 11 Aug 2009 13:28:08 -0500, a écrit :
> while length(str) in any language up to the 1990s was a mere
> substraction, now we must go through the string checking each byte to
> see if it is a Unicode marker and substract the appropriate number of
> bytes.

Not necessarily.  Any sane implementation should just use wchar_t and
substraction gets back.  The width of the text is another matter, but
it's a problem for truetype rendering anyway.  What is still costly is
then the conversion, which in principle only happens while talking with
other programs (files/socket/etc.)

Samuel


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

Re: Automatic Debug Packages

[Gunnar Wolf]

Steve Langasek dijo [Sun, Aug 09, 2009 at 05:15:39PM -0700]:
> > If we are going to enshrine ddebs into policy, we might as well
> >  teach dpkg about ddebs.
> 
> I don't have a strong opinion on whether ddebs should be documented in
> policy, but I certainly don't agree with requiring dpkg to understand them
> as a prerequisite for implementing a general purpose, public archive for
> auto-stripped debugging symbols packages.  There really is no reason for
> dpkg to treat these packages specially - a simple namespace convention
> imposed by Policy (i.e., reserving package names ending in "-ddeb" for use
> by this archive, which is what has been proposed) is sufficient, and
> requires no changes to dpkg, which is as it should be.
> 
> I think the .ddeb extension is a red herring.  There ought not be anything
> new to teach dpkg, here; the only thing of relevance is that there not be
> namespace clashes between the ddebs and the debs in the main archive, and
> the filename is not relevant to that at all.

I understand your concern about this extension, but I do see it as a
merit. Of course, our tools must be aware of it.  And apt should know
-before updating or whatnot- that a package was installed from a ddeb,
if they are to share the base name. But I feel ddebs will allow
debugging packages creation and installation to take place in a much
more transparent, automatic fashion. I think this will be in the
interest of both users and developers.

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Re: Automatic Debug Packages

[Gunnar Wolf]

Russ Allbery dijo [Sat, Aug 08, 2009 at 05:51:33PM -0700]:
> > You can build a .ddeb manually, yes. However for some cases
> > (e.g. packages using debhelper and building ELF binaries) a .ddeb will
> > be automatically created (if none is created manually) and detached
> > debugging symbols will be put there. I'll try to automatize other
> > languages too, so that having full archive coverage is as simpler as
> > possible.
> 
> Could you explain a bit more about what merits you see in creating
> something that we call a different type of package rather than just
> listing debug packages in debian/control and building them as we do now
> and handling section debug specially in the archive software?  Is it just
> the avoiding of the need to add a bunch of debian/control entries?

I would add:

• .ddebs could be autobuilt — I am not familiar with the procedure,
  but I suppose a debian/control field would indicate whether this
  package allows being built as a .ddeb (as there would be no way
  i.e. to build a Perl module as a ddeb)

• Less namespace explosion. We would get rid of all the -debug
  packages. 

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Re: Automatic Debug Packages

[Manoj Srivastava]

On Tue, Aug 11 2009, Russ Allbery wrote:

> Emilio Pozuelo Monfort  writes:
>> Manoj Srivastava wrote:
>
>>> To recap:
>>>  1) packages with detached debugging symbols should be named
>>> ${package name}-${debug suffix}. As a corollary, no ordinary
>>> packages names may end in  ${debug suffix}.
>
>> They may be automatically created. They may also be manually created (if
>> they are listed in debian/control, so for complex packages where they
>> need some manual work, it can be done).
>
> Whether they're automatically or manually created is irrelevant for Debian
> Policy.  Policy describes what the output should be, not what tools one
> uses to get there.
>
> I think the relevant question for Policy is whether these packages will be
> listed in debian/control in the source package, in Binary in the *.dsc
> file, and in Binary/Files/Checksums-* in the *.changes file.  And I don't
> know the answer to those three questions from the discussion so far.

Here is my take on this:
 a) helper packages may be extended to created debug packages by
default, whether or not they're mentioned in control. This means
that any package rebuilt the next time will get debugging packages,
even if the maintainer takes no action. Policy should not prevent
this use case, so requiring that the control file mentions them
should not be done.
 b) Some upstream packages, even if helper packages are used, might not
be readily amenable to automated generation of debug packages, and
manual help might be required. In this category I would also like to
throw in packages that do not use helper packages; since themanual
crafting of debug symbol packages is a commonality. These packages
have the debug packages in debian/control, and htey are built
normally (either through custoim scripts, or helper packages). In
this case, the helper should not automatically generate debug symbol
packages; and thus give us a mechanism to over ride, on a package by
package basis, the creation of automated debug packages.

So I think at this point it is premature for policy to decide
 one way or the other about debug symbol packages being mentioned in the
 control file (and dsc and changes).

I am also of the belief that perhaps the dsc and the changes
 file should treat them like normal .debs; and the differentiation occur
 at the archive level, when archive scripts try to determine where these
 packages go.

Another reason is that we should not be accepting any packages,
 even debug packages, in the archive unless we have a check sum match in
 a cryptographically signed file anyway.

manoj
-- 
Ten years of experience should add up to more than one year's experience
multiplied by ten.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bits from the release team and request for discussion

[Gunnar Wolf]

Anthony Towns dijo [Tue, Aug 11, 2009 at 01:07:33PM +1000]:
> So, with August almost half-way over, I guess the release team's not
> going to be doing much more to seek input from non-key teams/developers.
> 
> I still think it'd be interesting and useful to get broader input,
> though. Something like a choice amongst the following questions by GR
> might work:
> (…)

I basically oppose such a GR, as it is is merely speculative (who
knows _now_ or at the GR voting time when we will be close to
achieving our release goals?), and because it is a ruling on a
technical subject (at least according to some metrics). But if the
vote were to be held at all, I would add:

  6. The Debian project recognizes the responsible team to take any
 decisions regarding the freeze date and reach to be the Release
 Team, and accepts their best judgement in this regard.

BTW, reiterating so much on when Ubuntu is, when DebConf is and all
that... Is just too reiterative, if you allow me to reiterate ;-)

Greetings,

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


pgp7bym5vNeo7.pgp
Description: PGP signature

Re: default character encoding for everything in debian

[Gunnar Wolf]

Harald Braumann dijo [Tue, Aug 11, 2009 at 01:33:58AM +0200]:
> > There are a lot of users out there that are not willing to pay the
> > price for increased generality.
> 
> Don't you mean s/users/programmers? As a user I don't see what price I
> pay. I only see advantages in having a consistent encoding. Which,
> btw., doesn't have to be UTF-8. In an ideal world every programme would
> adhere to LC_CTYPE. But if the encoding has to be configured then I
> would also prefer UTF-8 as the default.
> 
> Of course, for the programmer there might be a price to pay. And if
> he's not willing to pay it, he can't be forced, anyway.
> 
> Or do you mean the user pays the price, because if the encoding is set
> to UTF-8 then performance would suffer? In that case, I'd love to see
> some real life numbers. I doubt the difference would be noticeable. 

Yes, performance will suffer. We enjoyed many decades of blissfully
ignoring the difference between a character and a byte. So, while
length(str) in any language up to the 1990s was a mere substraction,
now we must go through the string checking each byte to see if it is a
Unicode marker and substract the appropriate number of bytes. Also,
for a very long time we didn't really care much what was a buffer's
content - Everything could be printed, even if it had control
characters which made you beep (with the ocassional control sequence
re-injecting output into the terminal as input). Now... Well, printing
an unprintable string can cause segfaults in some cases.

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Re: default character encoding for everything in debian

[Gunnar Wolf]

Norbert Preining dijo [Mon, Aug 10, 2009 at 08:55:27PM +0200]:
> On Mo, 10 Aug 2009, Roger Leigh wrote:
> > Of course there's a penalty for certain operations.  But UTF-8 is about
> > as compact as an extended encoding is going to get.
> 
> Rubbish. You know why in Japan and other Asian countries UTF8 is not
> so common? Because many of their glyphs need 4 (four!) bytes, while
> for example jis-2022 (AFAIR) is much more compact.
> 
> We are not living in an ASCII world anymore.

It's not that much about the size as it is about backwards
compatibility. We users of Latin-based alphabets migrate easily to
UTF8, with occassional problems where we use diacritics. Eastern Asian
encodings are _completely_ incompatible with UTF8, so it is just not
possible to tolerate broken text every now and then. Everything just
breaks completely.

-- 
Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244


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

Ubuntu's crash reporting with "apport" -> Debian ?

[Steffen Moeller]

Hello,

KDE has improved rather dramatically with its crash reporting UI in its
past few releases, I think. Now Ubuntu comes up with something along
these lines for all kinds of applications: apport
(https://launchpad.net/apport/).

Is anything speaking against someone (me?) repackaging apport for Debian?

Thanks and regards,

Steffen


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

Re: Automatic Debug Packages

[Russ Allbery]

Emilio Pozuelo Monfort  writes:
> Manoj Srivastava wrote:

>> To recap:
>>  1) packages with detached debugging symbols should be named
>> ${package name}-${debug suffix}. As a corollary, no ordinary
>> packages names may end in  ${debug suffix}.

> They may be automatically created. They may also be manually created (if
> they are listed in debian/control, so for complex packages where they
> need some manual work, it can be done).

Whether they're automatically or manually created is irrelevant for Debian
Policy.  Policy describes what the output should be, not what tools one
uses to get there.

I think the relevant question for Policy is whether these packages will be
listed in debian/control in the source package, in Binary in the *.dsc
file, and in Binary/Files/Checksums-* in the *.changes file.  And I don't
know the answer to those three questions from the discussion so far.

>>  3) The detached debugging symbols should be placed in a subdirectory of
>> /usr/lib/debug, the exact path being determined by the mechanism
>> used (either build ids or debug links can and may be used)

> Don't forget that there are other debug info, like e.g. python dbg
> extensions or mono .mdb files. Those aren't placed in /usr/lib/debug, so
> we shouldn't restrict the ddeb packages content to files in
> /usr/lib/debug.

That's a separate issue that hasn't been raised so far.  I'm surprised
that you'd want to mix this in.  I thought the whole point of this
proposal was to handle detached binary symbols in a way that's predictable
from the name of the binary package so that they could be, for instance,
automatically installed based on user request.  I thought one of the key
points of the discussion so far was that they were *not* going to take
over all of the complex variety of stuff people put into -dbg packages.

If we're also adding Python debug extensions, are we adding separate
copies of binaries built with -O0 -g?  Whole libraries built with library
debugging support?  Binaries built with more verbose trace information?
That seems like huge scope creep to me.

> 5) There may only be one ddeb per source package (if more where needed,
> we could consider it).

Why would we do this?  Surely it makes more sense to have a one-to-one
correlation between debug packages and binary packages that contain the
binaries for which we have detached debugging symbols?

-- 
Russ Allbery (r...@debian.org)   


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

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Emilio Pozuelo Monfort wrote:
>> Manoj Srivastava wrote:
>>> Can you  point ot me the disadvantage of continuing to use what
>>>  dh_strip does now?
>> It can still be used, but you will miss the advantages of using build ids.
> 
> I guess I was trying to ask what the advantages were, apart from
>  the CRC check overhead that is skipped on load.  I presume that the crc
>  check sum has been demonstrated to be onerous. Are there any other
>  advantages I am missing?

We plan to provide a share through the network, that you can mount to virtually
have all the debugging symbols for the archive, downloading them as needed.

With build ids, assuming we have enough disk space, we could ship debugging
symbols for more than one version at a time, and the right one would be picked.
With the debuglink method, this wouldn't be possible as the files would need to
be shipped in the same place.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Manoj Srivastava]

On Tue, Aug 11 2009, Emilio Pozuelo Monfort wrote:

> Manoj Srivastava wrote:

>
>> OK, I guess that would work. But you still have the advantage,
>>  using the current debug link mechanism, of looking to see if you have
>>  debug symbols for a given executable/library easily, without having to
>>  compute potentially 3 checksums (depending on which algorithm was
>>  selected at build time) and trying to match that (in multiple
>>  directories).
>
> If you have the .ddeb package installed, you will have the debugging symbols
> installed :)

I guess that is true. Figure out which package the executable
 belongs to, check to see that the -ddeb package exists.

>
>> Can you  point ot me the disadvantage of continuing to use what
>>  dh_strip does now?
>
> It can still be used, but you will miss the advantages of using build ids.

I guess I was trying to ask what the advantages were, apart from
 the CRC check overhead that is skipped on load.  I presume that the crc
 check sum has been demonstrated to be onerous. Are there any other
 advantages I am missing?

manoj
-- 
innovate, v.: To annoy people.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: udev, init.d and a daemon

[Marco d'Itri]

On Aug 11, "Giacomo A. Catenazzi"  wrote:

> uinput is "input from userspace", so no hardware.
> But probably CONFIG_INPUT_UINPUT must be set "y" on debian kernels.
This is not so obvious. Looks like you should load the module from the
init script (and please do not bother removing it on shutdown, no need
to waste the time).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Automatic Debug Packages

[Bill Allombert]

On Mon, Aug 10, 2009 at 03:59:22PM -0700, Steve Langasek wrote:
> On Mon, Aug 10, 2009 at 09:46:49PM +0100, Roger Leigh wrote:
> > Reading through this thread, I don't see a compelling reason for using
> > a .ddeb extension given that they are just regular .debs, nor for
> > keeping the packages separate from the main archive (if the size of the
> > Packages file is an issue, can't they just go in a separate debug
> > section/component?)
> 
> Size of *the archive* is an issue.  They could live in a separate component,
> but as mentioned in the proposal, this component shouldn't by default be
> mirrored with the rest of the archive.

The size of the archive has been used to justify so much silliness that
it has become the Godwin law of Debian.

Debian mirrors are not required to have non-free/* so they should not
be required to have */debug either.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


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

Re: Automatic Debug Packages

[Julien Cristau]

On Tue, Aug 11, 2009 at 18:37:05 +0200, Emilio Pozuelo Monfort wrote:

> Manoj Srivastava wrote:
> >  2) These packages may just symlink
> > /usr/share/doc/${package name}-${debug suffix} to
> > /usr/share/doc/${package name}
> > (and of course, depend on ${package name}
> 
> 5) There may only be one ddeb per source package (if more where needed, we 
> could
> consider it).
> 
How do you make 2) and 5) work?  Seems to me one ddeb per binary package
makes much more sense.

Cheers,
Julien


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

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Manoj Srivastava wrote:
> Hi,
> 
> All right. Having been educated about the new build-id
>  mechanism, I think there is not reason for policy to prohibit either
>  approach, or to settle on one or the other.
> 
> To recap:
>  1) packages with detached debugging symbols should be named
> ${package name}-${debug suffix}. As a corollary, no ordinary
> packages names may end in  ${debug suffix}.

They may be automatically created. They may also be manually created (if they
are listed in debian/control, so for complex packages where they need some
manual work, it can be done).

>  2) These packages may just symlink
> /usr/share/doc/${package name}-${debug suffix} to
> /usr/share/doc/${package name}
> (and of course, depend on ${package name}
>  3) The detached debugging symbols should be placed in a subdirectory of
> /usr/lib/debug, the exact path being determined by the mechanism
> used (either build ids or debug links can and may be used)

Don't forget that there are other debug info, like e.g. python dbg extensions or
mono .mdb files. Those aren't placed in /usr/lib/debug, so we shouldn't restrict
the ddeb packages content to files in /usr/lib/debug.

>  4) Otherwise, these packages are normal debian packages

5) There may only be one ddeb per source package (if more where needed, we could
consider it).


Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Josselin Mouette wrote:
> 
>> Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
>>> Except you have not indicated how you (or debhelper) is going to
>>>  intercept ld to add the requisite arguments.
>> http://lists.debian.org/debian-devel-changes/2009/07/msg01229.html
> 
> So the proposal is to add --enable-linker-build-id to CFLAGS?

That is passed to the GCC build, so that from now on GCC will always pass
--build-id to the linker. So you don't need to do anything if your package uses
GCC (gcc/g++).

> OK, I guess that would work. But you still have the advantage,
>  using the current debug link mechanism, of looking to see if you have
>  debug symbols for a given executable/library easily, without having to
>  compute potentially 3 checksums (depending on which algorithm was
>  selected at build time) and trying to match that (in multiple
>  directories).

If you have the .ddeb package installed, you will have the debugging symbols
installed :)

> Can you  point ot me the disadvantage of continuing to use what
>  dh_strip does now?

It can still be used, but you will miss the advantages of using build ids.

Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Manoj Srivastava]

Hi,

All right. Having been educated about the new build-id
 mechanism, I think there is not reason for policy to prohibit either
 approach, or to settle on one or the other.

To recap:
 1) packages with detached debugging symbols should be named
${package name}-${debug suffix}. As a corollary, no ordinary
packages names may end in  ${debug suffix}.
 2) These packages may just symlink
/usr/share/doc/${package name}-${debug suffix} to
/usr/share/doc/${package name}
(and of course, depend on ${package name}
 3) The detached debugging symbols should be placed in a subdirectory of
/usr/lib/debug, the exact path being determined by the mechanism
used (either build ids or debug links can and may be used)
 4) Otherwise, these packages are normal debian packages

The  ${debug suffix} nay be ddeb,  or something else to be
 decided.

Comments?

manoj
-- 
Well, it's hard for a mere man to believe that woman doesn't have equal
rights. Dwight D. Eisenhower
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Automatic Debug Packages

[Manoj Srivastava]

On Tue, Aug 11 2009, Josselin Mouette wrote:

> Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
>> Except you have not indicated how you (or debhelper) is going to
>>  intercept ld to add the requisite arguments.
>
> http://lists.debian.org/debian-devel-changes/2009/07/msg01229.html

So the proposal is to add --enable-linker-build-id to CFLAGS?

OK, I guess that would work. But you still have the advantage,
 using the current debug link mechanism, of looking to see if you have
 debug symbols for a given executable/library easily, without having to
 compute potentially 3 checksums (depending on which algorithm was
 selected at build time) and trying to match that (in multiple
 directories).

Can you  point ot me the disadvantage of continuing to use what
 dh_strip does now?

manoj
-- 
I have the simplest tastes.  I am always satisfied with the best. Oscar
Wilde
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Manoj Srivastava wrote:
> On Tue, Aug 11 2009, Josselin Mouette wrote:
> 
>> Le mardi 11 août 2009 à 08:24 -0500, Manoj Srivastava a écrit :
>>> Hmm. I see very little benefit here. Firstly, to use build id,
>>>  you have to intercept the upstream build system and add --build-id
>>>  (and perhaps the --build-id-style) option to ld, instead of the current
>>>  method of letting the upstream build happen and working on the produced
>>>  objects -- this is more intrusive.  And what do we gain?
>> Without build IDs, GDB has no sure way to map the binary to the correct
>> detached symbols. Therefore it will read the whole file to compute its
>> CRC32 (!) and compare it to the one stored in the gnu_debuglink section
>> of the binary.
>>
>> This sole issue is responsible for gdb taking up to several minutes to
>> produce a backtrace for binaries using big libraries like xulrunner. And
>> don’t even think of using the debugging symbols over the network in this
>> case.
> 
> Yes, that would indeed be silly -- if you have managed to
>  intercept ld  and added --build-id to the executable, it would be silly
>  not to have the file in the location gdb will look in.
> 
> However, if you do not use the build-id mechanism, and use what
>  we currently use in dh_strip and friends, objcopy --add-gnu-debuglink
>  adds information that gdb looks at to figure out where the debug
>  symbols live -- and no CRC check sum is ever performed. 

It still is AFAIK:

   * The executable contains a "debug link" that specifies the name of
 the separate debug info file.  The separate debug file's name is
 usually `EXECUTABLE.debug', where EXECUTABLE is the name of the
 corresponding executable file without leading directories (e.g.,
 `ls.debug' for `/usr/bin/ls').  In addition, the debug link
 specifies a CRC32 checksum for the debug file, which GDB uses to
 validate that the executable and the debug file came from the same
 build.

That says the debug link contains the CRC checksum. But GDB still needs to
perform it to make sure it matches that of the debug file.

Cheers,
Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 10:39 -0500, Manoj Srivastava a écrit :
> However, if you do not use the build-id mechanism, and use what
>  we currently use in dh_strip and friends, objcopy --add-gnu-debuglink
>  adds information that gdb looks at to figure out where the debug
>  symbols live -- and no CRC check sum is ever performed. 

As I explained, the CRC checksum is performed unconditionally when the
gnu_debuglink mechanism is used.

> Given the difficulty in intercepting ld commands in upstream
>  build systems, I would  be inclined to just standardize the debug link
>  method, given that it produces human readable file names (so I can
>  determine manually if I have debugging symbols for some library or
>  not) as an added bonus. 

Providing a script looking at the build-id and telling whether the
debugging symbols are installed is a matter of a few lines of shell
code.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Josselin Mouette wrote:
> Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
>> Except you have not indicated how you (or debhelper) is going to
>>  intercept ld to add the requisite arguments.
> 
> http://lists.debian.org/debian-devel-changes/2009/07/msg01229.html

Also see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535237 for reference.

Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Manoj Srivastava]

On Tue, Aug 11 2009, Josselin Mouette wrote:

> Le mardi 11 août 2009 à 08:24 -0500, Manoj Srivastava a écrit :
>> Hmm. I see very little benefit here. Firstly, to use build id,
>>  you have to intercept the upstream build system and add --build-id
>>  (and perhaps the --build-id-style) option to ld, instead of the current
>>  method of letting the upstream build happen and working on the produced
>>  objects -- this is more intrusive.  And what do we gain?
>
> Without build IDs, GDB has no sure way to map the binary to the correct
> detached symbols. Therefore it will read the whole file to compute its
> CRC32 (!) and compare it to the one stored in the gnu_debuglink section
> of the binary.
>
> This sole issue is responsible for gdb taking up to several minutes to
> produce a backtrace for binaries using big libraries like xulrunner. And
> don’t even think of using the debugging symbols over the network in this
> case.

Yes, that would indeed be silly -- if you have managed to
 intercept ld  and added --build-id to the executable, it would be silly
 not to have the file in the location gdb will look in.

However, if you do not use the build-id mechanism, and use what
 we currently use in dh_strip and friends, objcopy --add-gnu-debuglink
 adds information that gdb looks at to figure out where the debug
 symbols live -- and no CRC check sum is ever performed. 

So a mixed mode approach would indeed be bad. But a pure debug
 link method does not have these stated drawbacks.

Given the difficulty in intercepting ld commands in upstream
 build systems, I would  be inclined to just standardize the debug link
 method, given that it produces human readable file names (so I can
 determine manually if I have debugging symbols for some library or
 not) as an added bonus. 

manoj
-- 
Work is the crab grass in the lawn of life. Schulz
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Automatic Debug Packages

[Emilio Pozuelo Monfort]

Steve Langasek wrote:
> On Mon, Aug 10, 2009 at 09:46:49PM +0100, Roger Leigh wrote:
>> Reading through this thread, I don't see a compelling reason for using
>> a .ddeb extension given that they are just regular .debs, nor for
>> keeping the packages separate from the main archive (if the size of the
>> Packages file is an issue, can't they just go in a separate debug
>> section/component?)
> 
> Size of *the archive* is an issue.  They could live in a separate component,
> but as mentioned in the proposal, this component shouldn't by default be
> mirrored with the rest of the archive.

What's exactly what we will do!

Emilio



signature.asc
Description: OpenPGP digital signature

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 10:11 -0500, Manoj Srivastava a écrit :
> Except you have not indicated how you (or debhelper) is going to
>  intercept ld to add the requisite arguments.

http://lists.debian.org/debian-devel-changes/2009/07/msg01229.html

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Bits from the release team and request for discussion

[Manoj Srivastava]

On Tue, Aug 11 2009, Matthew Johnson wrote:

> On Tue Aug 11 10:12, Giacomo A. Catenazzi wrote:
>> Personally I don't think we should do a GR to recommend a freeze or release 
>> date.
>> We already used the DPL election to push a release, when it was *long* due, 
>> but
>> I don't think we should push a freeze.
>
> Zack has been patching devotee to allow more informal (and not at all
> binding) polls to be run with the same infrastructure. I think this
> could be a suitable candidate to run using that. It allows us to have a
> poll which can only be voted in by DDs and not easily stuffed, but
> without having to go through the pain of a formal resolution.

Hmm? Why haven't these patches been sent upstream, then?  I have
 been also working at devotee-ng, which will have a plug-in
 architecture, to allow votes to add in dfferent pre-processing stacks
 (mime/gpg-decrypt, vs plain ballot vs DB lookup), to bypass checks
 (gpg, ldap), or add new ones, and to change the vote tallying
 algorithm, and add in new response/publish modules.

Forking devotee at this point seems to serve little purpose,
 given that upstream is not hostile.

manoj

-- 
We are MicroSoft.  You will be assimilated.  Resistance is
futile. Attributed to B.G., Gill Bates
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Automatic Debug Packages

[Manoj Srivastava]

On Tue, Aug 11 2009, Sune Vuorela wrote:

> On 2009-08-11, Manoj Srivastava  wrote:
>> Hmm. I see very little benefit here. Firstly, to use build id,
>>  you have to intercept the upstream build system and add --build-id
>>  (and perhaps the --build-id-style) option to ld, instead of the current
>>  method of letting the upstream build happen and working on the produced
>>  objects -- this is more intrusive.  And what do we gain?
>
> The plan is to make --build-id the default (As it is on many other
> distributions).
>
>>
>>   * For the "build ID" method, GDB looks in the `.build-id'
>>  subdirectory of the global debug directory for a file named
>>  `NN/.debug', where NN are the first 2 hex characters of
>>  the build ID bit string, and  are the rest of the bit
>>  string.  (Real build ID strings are 32 or more hex characters, not
>>  10.)
>>
>> So, we would still need to create   "/usr/lib/debug/"
>>  . /full/path/to/lib_or_binary/ in either case, and instead of the
>
> no. it would be /usr/lib/debug/.build-id/NN/NN.debug

Right. Mostly human unreadable.

>>  lib-or-exec name, create NN/.debug file there (which is non
>>  human readable, really). What have we gained? There is no potential for
>>  file name conflicts, since if there are file name conflicts in the
>>  debug symbol files, there would be file name conflicts in the
>>  corresponding packages, which is already a bug in Debian.
>>
>> I see added complexity with no real benefit for us: it might
>>  have value in an environment where file conflicts are not verboten.
>
> And the next step is to provide /usr/lib/debug/.build-id exported from
> some internet service so that you download debugging symbols on demand,
> for example thru drkonqi or bug-buddy or maybe directly with gdb.

You can just export /usr/lib/debug/ from the central service
 equally easily, no difference there -- you can just provide the current
 Sid/testing/stable snapshot.


> Having a reliable way of getting from a random library version and
> random executable version to get the exact corresponding debug symbols,
> the build-id method is just much more reliable.

Except you have not indicated how you (or debhelper) is going to
 intercept ld to add the requisite arguments.

manoj
-- 
Murray's Rule: Any country with "democratic" in the title isn't.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Automatic Debug Packages

[Manoj Srivastava]

On Tue, Aug 11 2009, Roger Leigh wrote:

> On Tue, Aug 11, 2009 at 01:40:20PM +, Sune Vuorela wrote:
>> On 2009-08-11, Manoj Srivastava  wrote:
>> > So, we would still need to create   "/usr/lib/debug/"
>> >  . /full/path/to/lib_or_binary/ in either case, and instead of the
>> 
>> no. it would be /usr/lib/debug/.build-id/NN/NN.debug
>  ^
> Why the need for a hidden directory in a public location?
> What's wrong with /usr/lib/debug/build-id?
>
> I don't think the unnecessary obfuscation is warranted.

Because that is where gdb looks for them.

manoj
-- 
Probably the earliest fly swatters were nothing more than some sort of
striking surface attached to the end of a long stick.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Automatic Debug Packages

[Josselin Mouette]

Le mardi 11 août 2009 à 08:24 -0500, Manoj Srivastava a écrit :
> Hmm. I see very little benefit here. Firstly, to use build id,
>  you have to intercept the upstream build system and add --build-id
>  (and perhaps the --build-id-style) option to ld, instead of the current
>  method of letting the upstream build happen and working on the produced
>  objects -- this is more intrusive.  And what do we gain?

Without build IDs, GDB has no sure way to map the binary to the correct
detached symbols. Therefore it will read the whole file to compute its
CRC32 (!) and compare it to the one stored in the gnu_debuglink section
of the binary.

This sole issue is responsible for gdb taking up to several minutes to
produce a backtrace for binaries using big libraries like xulrunner. And
don’t even think of using the debugging symbols over the network in this
case.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'   “I recommend you to learn English in hope that you in
  `- future understand things”  -- Jörg Schilling


signature.asc
Description: Ceci est une partie de message numériquement signée

Re: Automatic Debug Packages

[Roger Leigh]

On Tue, Aug 11, 2009 at 01:40:20PM +, Sune Vuorela wrote:
> On 2009-08-11, Manoj Srivastava  wrote:
> > So, we would still need to create   "/usr/lib/debug/"
> >  . /full/path/to/lib_or_binary/ in either case, and instead of the
> 
> no. it would be /usr/lib/debug/.build-id/NN/NN.debug
 ^
Why the need for a hidden directory in a public location?
What's wrong with /usr/lib/debug/build-id?

I don't think the unnecessary obfuscation is warranted.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Re: Virtual package dyndns-client

[Timur Birsh]

Hi all,

Torsten Landschoff wrote:

> Timur Birsh brought it to my attention that my package ddclient provides
> a virtual package "dyndns-client" that is not on the official virtual
> package list at
> http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
> 
> It seems that I have missed the requirement to request a new virtual
> package here at the time I introduced the provides.
> 
> Therefore I now request that the virtual package
> 
>   dyndns-client
> 
> is added to the official list of virtual packages in Debian. If consensus
> happens to be that this has no merits, I will of course remove the
> Provides on ddclient.

Can anyone please comment on this?

-- 
Timur


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

Bug#541074: ITP: libdap -- Scientific Network Data Access Protocol library

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: libdap
  Version : 3.9.3
  Upstream Author : OpenDAP
* URL : http://www.opendap.org
* License : GPL, W3C
  Programming Lang: C++
  Description : Scientific  Network Data Access Protocol library

 OPeNDAP provides software that allows you to access data over the internet,
 from programs that weren't originally designed for that purpose, as well
 as some that were. While OPeNDAP is the original developer of the Data Access
 protocol which its software uses, many other groups have adopted DAP
 and provide compatible clients, servers and software development kits.
 .
 The DAP is a NASA community standard; here is the offical link to the
 specification.
 .
 With OPeNDAP software, you access data using a URL, just like a URL you
 would use to access a web page. However, before you request any data,
 you need to know how to request it in a form your browser can handle.
 OPeNDAP data is stored in binary form, and by default, it is
 transmitted that way, too.

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: powerpc (ppc)



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

Bug#541068: ITP: libuuid-tiny-perl -- pure Perl module to generate v1, v3, v4, and v5 UUIDs

[Christine Spang]

Package: wnpp
Severity: wishlist
Owner: Christine Spang 

* Package name: libuuid-tiny-perl
  Version : 1.01
  Upstream Author : Christian Augustin 
* URL : http://search.cpan.org/dist/UUID-Tiny/
* License : Perl (GPL-1+ | Artistic)
  Programming Lang: Perl
  Description : pure Perl module to generate v1, v3, v4, and v5 UUIDs

 UUID::Tiny provides a simple, non-object-oriented interface for
 generating UUIDs from Perl code. It is not suitable for
 performance-sensitive UUID generation or for applications that
 require v1 UUIDs generated from a real MAC address (this module
 generates random MAC addresses), but otherwise provides a simpler
 Perl interface for UUID generation than alternatives.



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

Re: Bits from the release team and request for discussion

[Matthew Johnson]

On Tue Aug 11 10:12, Giacomo A. Catenazzi wrote:
> Personally I don't think we should do a GR to recommend a freeze or release 
> date.
> We already used the DPL election to push a release, when it was *long* due, 
> but
> I don't think we should push a freeze.

Zack has been patching devotee to allow more informal (and not at all
binding) polls to be run with the same infrastructure. I think this
could be a suitable candidate to run using that. It allows us to have a
poll which can only be voted in by DDs and not easily stuffed, but
without having to go through the pain of a formal resolution.

Matt
-- 
Matthew Johnson


signature.asc
Description: Digital signature

Plz Add Me For All Themes Links Exchange.................

[abdul rahaman]

 <123direct...@gmail.com>


*Hi All,*

*Plz Add Me For All Themes Links Exchange.*

*Thanks. & Regards
Rahaman MA


*

Re: Automatic Debug Packages

[Sune Vuorela]

On 2009-08-11, Manoj Srivastava  wrote:
> Hmm. I see very little benefit here. Firstly, to use build id,
>  you have to intercept the upstream build system and add --build-id
>  (and perhaps the --build-id-style) option to ld, instead of the current
>  method of letting the upstream build happen and working on the produced
>  objects -- this is more intrusive.  And what do we gain?

The plan is to make --build-id the default (As it is on many other
distributions).

>
>   * For the "build ID" method, GDB looks in the `.build-id'
>  subdirectory of the global debug directory for a file named
>  `NN/.debug', where NN are the first 2 hex characters of
>  the build ID bit string, and  are the rest of the bit
>  string.  (Real build ID strings are 32 or more hex characters, not
>  10.)
>
> So, we would still need to create   "/usr/lib/debug/"
>  . /full/path/to/lib_or_binary/ in either case, and instead of the

no. it would be /usr/lib/debug/.build-id/NN/NN.debug

>  lib-or-exec name, create NN/.debug file there (which is non
>  human readable, really). What have we gained? There is no potential for
>  file name conflicts, since if there are file name conflicts in the
>  debug symbol files, there would be file name conflicts in the
>  corresponding packages, which is already a bug in Debian.
>
> I see added complexity with no real benefit for us: it might
>  have value in an environment where file conflicts are not verboten.

And the next step is to provide /usr/lib/debug/.build-id exported from
some internet service so that you download debugging symbols on demand,
for example thru drkonqi or bug-buddy or maybe directly with gdb.

Having a reliable way of getting from a random library version and
random executable version to get the exact corresponding debug symbols,
the build-id method is just much more reliable.

/Sune


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

Bug#541066: ITP: libxml-atom-simplefeed-perl -- No-fuss generation of Atom syndication feeds

[Christine Spang]

Package: wnpp
Severity: wishlist
Owner: Christine Spang 

* Package name: libxml-atom-simplefeed-perl
  Version : 0.86
  Upstream Author : Aristotle Pagaltzis 
* URL : http://search.cpan.org/dist/XML-Atom-SimpleFeed/
* License : Perl (GPL-1+ | Artistic)
  Programming Lang: Perl
  Description : Perl module for generation of Atom syndication feeds

 This module provides a minimal API for generating Atom syndication feeds
 quickly and easily. It supports all aspects of the Atom format, but has
 no provisions for generating feeds with extension elements.
 .
 You can supply strings for most things, and the module will provide
 useful defaults. When you want more control, you can provide data
 structures, as documented, to specify more particulars.
 .
 This module has a much smaller dependency chain than XML::Atom.



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

Re: udev, init.d and a daemon

[Petter Reinholdtsen]

[Giacomo A. Catenazzi]
> Problems:
> - How to force the deamon to be loaded BEFORE xorg in insserv?
>   I don't find a "before of" dependency in LSB headers

The header is X-Start-Before.  In this case, I would use an entry like
this:

  # X-Start-Before: xdm kdm gdm ldm sdm

to make sure your script is started before the display managers.  See
http://wiki.debian.org/LSBInitScripts> or insserv(8) for more
info on the available headers.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Automatic Debug Packages

[Manoj Srivastava]

On Tue, Aug 11 2009, Sune Vuorela wrote:

> On 2009-08-10, Manoj Srivastava  wrote:
>> On Mon, Aug 10 2009, Sune Vuorela wrote:
>>
>>> On 2009-08-10, Manoj Srivastava  wrote:
 I would also add that the debug symbols should live in
  "/usr/lib/debug/" . /full/path/to/lib_or_binary, blessing the current
  practice.
>>>
>>> You are missing the new features of build-id as written earlier by
>>> insisting on this.

Hmm. I see very little benefit here. Firstly, to use build id,
 you have to intercept the upstream build system and add --build-id
 (and perhaps the --build-id-style) option to ld, instead of the current
 method of letting the upstream build happen and working on the produced
 objects -- this is more intrusive.  And what do we gain?

  * For the "build ID" method, GDB looks in the `.build-id'
 subdirectory of the global debug directory for a file named
 `NN/.debug', where NN are the first 2 hex characters of
 the build ID bit string, and  are the rest of the bit
 string.  (Real build ID strings are 32 or more hex characters, not
 10.)

So, we would still need to create   "/usr/lib/debug/"
 . /full/path/to/lib_or_binary/ in either case, and instead of the
 lib-or-exec name, create NN/.debug file there (which is non
 human readable, really). What have we gained? There is no potential for
 file name conflicts, since if there are file name conflicts in the
 debug symbol files, there would be file name conflicts in the
 corresponding packages, which is already a bug in Debian.

I see added complexity with no real benefit for us: it might
 have value in an environment where file conflicts are not verboten.

manoj
-- 
An apology for the devil: it must be remembered that we have heard only
one side of the case. God has written all the books.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Bug#541051: ITP: libconfig-gitlike-perl -- Perl module for Git-compatible config file parsing

[Christine Spang]

Package: wnpp
Severity: wishlist
Owner: Christine Spang 

* Package name: libconfig-gitlike-perl
  Version : 1.0
  Upstream Authors: Alex Vandiver ,
Christine Spang 
* URL : http://search.cpan.org/dist/Config-GitLike/
* License : Perl (GPL-1+ | Artistic)
  Programming Lang: Perl
  Description : Perl module for Git-compatible config file parsing

 Config::GitLike provides a Perl interface for parsing, writing, and
 managing configuration files of the format used by the version control
 system Git. It supports config-file inheritance in the same way that
 Git does: system-wide, user-wide, and per-directory config files can
 be specified and loaded, with values from more local files overriding
 those in less-local files.
 .
 More information on this config format can be found at:
 http://www.kernel.org/pub/software/scm/git/docs/git-config.html



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

Bug#541049: ITP: libpath-dispatcher-perl -- flexible and extensible command-line dispatch for Perl programs

[Christine Spang]

Package: wnpp
Severity: wishlist
Owner: Christine Spang 

* Package name: libpath-dispatcher-perl
  Version : 0.13
  Upstream Author : Shawn Moore 
* URL : http://search.cpan.org/dist/Path-Dispatcher/
* License : Perl (GPL-1+ | Artistic)
  Programming Lang: Perl
  Description : flexible and extensible command-line dispatch for Perl 
programs

 Path::Dispatcher is a Perl module that allows you to find code
 to run based on matching a path against a list of rules.
 .
 The basic operation is that of dispatch. Dispatch takes a path and a
 list of rules, and it returns a list of matches. From there you can
 "run" the rules that matched. These phases are distinct so that, if you
 need to, you can inspect which rules were matched without ever running
 their codeblocks.
 .
 Path::Dispatcher was inspired by the Jifty web framework's dispatcher,
 Jifty::Dispatcher.



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

Re: udev, init.d and a daemon

[Giacomo A. Catenazzi]

Marco d'Itri wrote:

On Aug 11, "Giacomo A. Catenazzi"  wrote:


- How to handle the common case: keyboard is already attached
  (daemon is in /usr filesystem), with udev.


cd /lib/udev/
. ./hotplug.functions
wait_for_file /dev/log


Thanks. I was looking for such function since years!




- How to load uinput module?  Actually I modprobe and I pool

I expect that it would be autoloaded by udev when the hardware is
installed.


uinput is "input from userspace", so no hardware.
But probably CONFIG_INPUT_UINPUT must be set "y" on debian kernels.



- init.d script is still need for shutdown phase

Is there any point in killing such a daemon on shutdown instead of
letting the generic init scripts do it?


Maybe. I like to manually start and stop daemons (especially
for tests), and for upgrades I think we need a sysadmin method for stop and
(re)start a deamon.
But I'll think more about this.

Anyway, thanks!

ciao
cate


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

Re: Bug#541013: O: at -- Delayed job execution and batch processing

[Sandro Tosi]

Hi all,

On Tue, Aug 11, 2009 at 10:48, Sandro Tosi wrote:
> Package: wnpp
> Severity: normal
>
> The current maintainer of at, Ryan Murray ,
> is apparently not active anymore.  Therefore, I orphan this package now.
>
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.

exactly. Please, pretty please, whoever will adopt this package check
this [1] and in particular [2]

[1] http://lists.debian.org/debian-qa/2009/08/msg00047.html
[2] http://lists.debian.org/debian-qa/2009/08/msg00048.html

forming a team on alioth is the right thing to do, so please do the
necessary action to achieve it.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi


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

Bug#541021: ITP: libutempter -- A privileged helper for utmp/wtmp updates

[Fathi Boudra]

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

Package name: libutempter
 Version: 1.1.5
Upstream Author: Dmitry V. Levin 
URL: http://freshmeat.net/projects/libutempter
License: LGPL 2.1
Description: A privileged helper for utmp/wtmp updates

 The libutempter library provides interface for terminal emulators such as
 screen and xterm to record user sessions to utmp and wtmp files.

 The utempter is a privileged helper used by libutempter library to manipulate
 utmp and wtmp files.



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

Re: Bug#540813: ITP: gamessq -- gamess scheduling frontend

[Manuel Prinz]

Am Dienstag, den 11.08.2009, 11:00 +0200 schrieb Michael Banck:
> Well, for general-purpose job scheduling, see recent threads on
> debian-science.  There are at least slurm-llnl and gridengine (though
> both very heavy-weight),

Though SLURM is not the smallest resource manager around, it's very,
very easy to set up and maintain -- and well documented. (I know people
using it on multi-core desktop machines.) GAMESS input file creation
could probably be scripted and used in SLURM via hooks.

That said, I have nothing against GamessQ being in Debian. I'd be quite
nice to have Gamess in main, though. But that's not going to happen, I
fear...

Best regards
Manuel


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

rkhunter: Did anybody review it's code?

[Siggy Brentrup]

Hi list,

while looking at rkhunter bugs, I noticed maintainer arguing with a
bogus test on Bug#518405, for details see my followup there.  (I know
I forgot parenthesises in the 1st command line)

Given the test is from rkhunter's code, I doubt it's usefulness now
before someone more competent than me reviewed the code.

Thanks
  Siggy
-- 
Please don't Cc: me when replying, I might not see either copy.
   bsb-at-psycho-dot-informationsanarchistik-dot-de
   or:bsb-at-psycho-dot-i21k-dot-de
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org


signature.asc
Description: Digital signature

Re: udev, init.d and a daemon

[Marco d'Itri]

On Aug 11, "Giacomo A. Catenazzi"  wrote:

> - How to handle the common case: keyboard is already attached
>   (daemon is in /usr filesystem), with udev.

cd /lib/udev/
. ./hotplug.functions
wait_for_file /dev/log

> - How to load uinput module?  Actually I modprobe and I pool
I expect that it would be autoloaded by udev when the hardware is
installed.

> - init.d script is still need for shutdown phase
Is there any point in killing such a daemon on shutdown instead of
letting the generic init scripts do it?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Bug#540813: ITP: gamessq -- gamess scheduling frontend

[Michael Banck]

Hi,

On Tue, Aug 11, 2009 at 10:16:44AM +0200, Patrick Winnertz wrote:
> > Are you sure such specialized software is useful?  I assume this will
> > go into contrib, as gamess itself is (AFAIK) non-free?
> Yepp, indeed, gamess is not available in debian (due to license issues),
> but can freely downloaded from the website of the group.
> 
> I'm not sure if this really belongs into contrib, it's starting up and
> working without gamess around, but without gamess around you can't
> start the processing. 

Is it still useful for manual post-processing or input-generation of
Gamess jobs?  In that case, I guess it would be fine to go in main.

(Though note that maybe avogadro can do the same, is fully Free Software
and has an active upstream)
  
> > Maybe having a general-purpose job scheduler or some local-job
> > application which also supports free codes would be better.
> Well.  there is no other job scheduler around. As this eases the
> handling of gamess very much, this should surely be packaged. 
> 
> If you can step up with a better alternative, please do :) I'm using
> gamess on a regular basis and I don't know another alternative for job
> scheduling. 

Well, for general-purpose job scheduling, see recent threads on
debian-science.  There are at least slurm-llnl and gridengine (though
both very heavy-weight), plus a possible upload of openpbs/torque and
several smaller ones.

If you ask for a Gamess-specific scheduler, I guess you are right that
there are currently no alternatives in the archive.


cheers,

Michael


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

Re: Bug#540813: ITP: gamessq -- gamess scheduling frontend

[Patrick Winnertz]

Hey,

> Are you sure such specialized software is useful?  I assume this will
> go into contrib, as gamess itself is (AFAIK) non-free?
Yepp, indeed, gamess is not available in debian (due to license issues),
but can freely downloaded from the website of the group.

I'm not sure if this really belongs into contrib, it's starting up and
working without gamess around, but without gamess around you can't
start the processing. 
 
> Maybe having a general-purpose job scheduler or some local-job
> application which also supports free codes would be better.
Well.  there is no other job scheduler around. As this eases the
handling of gamess very much, this should surely be packaged. 

If you can step up with a better alternative, please do :) I'm using
gamess on a regular basis and I don't know another alternative for job
scheduling. 

Greetings
Winnie


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

udev, init.d and a daemon

[Giacomo A. Catenazzi]

Hello,

I've a problem designing a boot script, and I find no example.

The problem:
- Logitech G15 (and like) USB keyboards have a LCD display and few
  (or lots) extra keys
- g15daemon is a deamon need to handle the display, and to handle the
  extra keys in xorg (xkb-data (>= 0.9+cvs.20070428-1) )
- g15daemon requires the kernel module uinput, to push back the
  extra keys (after decoding it, according to keyboard version)

Actual solution:
- a standard init.d script, which start and stop a deamon

Now I'm thinking/writing about a event based rule (with udev) which
handles also some short disconnection of USB bus on some systems.

Problems:
- How to force the deamon to be loaded BEFORE xorg in insserv?
  I don't find a "before of" dependency in LSB headers
- How to handle the common case: keyboard is already attached
  (daemon is in /usr filesystem), with udev.
- How to load uinput module?  Actually I modprobe and I pool
  to see if the device is created, every 0.1 seconds for 5 seconds.
  Note this could be done concurrently detaching the command, but
  anyway is not event based as I would like.

any suggestions/example?
How would it work on upstart?

Notes:
- actually g15daemon doesn't support multiple keyboards, but
  libg15 library does.
- init.d script is still need for shutdown phase

ciao
cate




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

Re: Bits from the release team and request for discussion

[Giacomo A. Catenazzi]

Anthony Towns wrote:

On Fri, Jul 31, 2009 at 05:39:23AM +1000, Anthony Towns wrote:

On Thu, Jul 30, 2009 at 07:28:58PM +0200, Luk Claes wrote:

About freeze timing we think that DebConf should definitely not fall
into a freeze



We noticed that releases in the first quarter of the year
worked out quite well in the past like both Etch and Lenny. Taking these
into consideration we think it would be best to freeze in December.



We'll be consulting all key teams within Debian to see how their plans
and schedules can fit into a new timeline. Before the end of August we
hope to have finished this process of consultation and be able to
present the new plan to you.



Why not have a developer poll as to what month(s) would most suit
people for the freeze, rather than limiting it to "key teams"?


So, with August almost half-way over, I guess the release team's not
going to be doing much more to seek input from non-key teams/developers.

I still think it'd be interesting and useful to get broader input,
though. Something like a choice amongst the following questions by GR
might work:

  1. The Debian project recommends that the release team target
 December 2009 for squeeze's freeze, and work hard to avoid allowing
 the freeze to slip by more than a few weeks. The project notes this
 is approximately 10 months after lenny's release, and approximately
 18 months after lenny's freeze. The project acknowledges this may
 assist in synchronising Debian 6.0 and Ubuntu 10.04 LTS, may assist
 in setting up regular freezes every second December, and is intended
 to allow Debian 6.0 to be released prior to DebConf 2010.

(...)


Any thoughts? We could have such a vote over and done in about two weeks,
with the DPL's consent, and it'd seem a lot more inclusive and less
cabal-tastic than how things seem to be working atm...


Later Luk wrote that now December 2009 seems an unrealistic target, but he
would talk to other teams to discuss the freeze date/period before announcing
again.

IMHO we should wait a formal decision of RMs before a GR.

Personally I don't think we should do a GR to recommend a freeze or release 
date.
We already used the DPL election to push a release, when it was *long* due, but
I don't think we should push a freeze.

ciao
cate


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

Re: Automatic Debug Packages

[Sune Vuorela]

On 2009-08-10, Manoj Srivastava  wrote:
> On Mon, Aug 10 2009, Sune Vuorela wrote:
>
>> On 2009-08-10, Manoj Srivastava  wrote:
>>> I would also add that the debug symbols should live in
>>>  "/usr/lib/debug/" . /full/path/to/lib_or_binary, blessing the current
>>>  practice.
>>
>> You are missing the new features of build-id as written earlier by
>> insisting on this.
>
> Please, Do enlighten me.

>From earlier in this thread:

|instead of objcopy and stuff people current do, either manually or with
|the help of dh_strip and wrap it in a foo-dbg.deb by using the
|.gnu_debuglink to and the expected paths by gdb and friends on where to
|find it, instead use the newfangled build id and put it in a appropriate
|hashed directory structure, as gdb and friends also are able to pick up,
|and then wrap it in a foo.ddeb package.
|
|There is nothing actually magic in it, except making it easy to use, but
|for more technical details, 
|see the --build-id option to ld(1) for more details about what build-id is
|and the gdb manual chapter 15.2 for more info about debugging
|information in seperate files.

http://permalink.gmane.org/gmane.linux.debian.devel.general/143053

/Sune


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