Re: proposed release goal: DEBIAN/md5sums for all packages

[Stefano Zacchiroli]

[ fully quoting my original request, for the sake of context
  preservation ]

On Fri, Aug 17, 2007 at 09:04:13AM +0200, Luk Claes wrote:
> Stefano Zacchiroli wrote:
>> [ Assuming is not too late to propose release goals of course ]
>> Hi, a long time ago we were wondering to have DEBIAN/md5sums generated
>> for all packages in the archive ... and we are still wondering!
>> Can we make it a release goal for lenny?
>> Cheers
>>
>> PS thanks to Romain Francoise which reminded me of this with his blog
>> entry
>> (http://blog.orebokech.com/2007/08/debian-packages-without-md5sums.html)
>
> With more than 600 issues, it's a bit early to make it a release goal IMHO. 
> Though making maintainers aware by upgrading the lintian check to a warning 
> and discussion on debian-devel about which exceptions are warranted (and 
> possible mass bug filing) will probably be a good idea to get the amount 
> reduced rather fast...

Ok, moving the discussion to -devel then. Please reply there, people.

In an attempt to prevent drift to a well-known counter argument:
DEBIAN/md5sums (used by debsums) are *not* intended as a mean to counter
security attacks, since they can be easily altered.  Rather, they are
useful as a general mechanism to check if something got corrupted due to
hardware/software failures and can be used to spot which packages need
to be reinstalled.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Bug#438460: ITP: i-doit -- Web-based IT documentation solution

[Mario Iseli]

Package: wnpp
Severity: wishlist
Owner: Mario Iseli <[EMAIL PROTECTED]>

* Package name: i-doit
  Version : 0.9
  Upstream Author : Joachim Winkler
Markus Wolfff
Daniel Kirsten
Niclas Potthast
Dennis Stuecken
Andre Woesten
Oliver Steigleder
Jens Knuth
Lars Hendrichs
* URL : http://www.i-doit.org
* License : Artistic
  Programming Lang: PHP
  Description : Web-based IT documentation solution

I-Doit is a web-based solution which provides almost all you need for
your IT documentation: Infrastructure documentation, device
documentation, license management, workflow management and planning and
even a contact management.

>From upstreams website:
I-doit documents IT-systems and their changes, defines emergency plans,
displays vital information and  helps  to ensure a stable and effcient
operation of IT-networks.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

ttf-liberation (Re: Debian on the Desktop - plans for Lenny?)

[Holger Levsen]

Hi,

On Thursday 09 August 2007 10:03, Christian Perrier wrote:
> > > > No, we should use the liberation fonts, which are designed to replace
> > > > the MS fonts.
> > > Have their licensing issues been solved?

Have those issues been communicated to upstream and what is their reaction?

The ITP includes the same question, in June, but no answer yet.


regards,
Holger


pgpMYpj8c6CNF.pgp
Description: PGP signature

Re: proposed release goal: DEBIAN/md5sums for all packages

[Romain Francoise]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> [ fully quoting my original request, for the sake of context
>   preservation ]

Thanks for initiating the discussion! :-)

> On Fri, Aug 17, 2007 at 09:04:13AM +0200, Luk Claes wrote:
>>
>> With more than 600 issues, it's a bit early to make it a release goal IMHO. 
>> Though making maintainers aware by upgrading the lintian check to a warning 
>> and discussion on debian-devel about which exceptions are warranted (and 
>> possible mass bug filing) will probably be a good idea to get the amount 
>> reduced rather fast...

One thing I've been pondering about is: are there any good reasons
*not* to have an md5sums control file?

It seems to me that the time spent to generate it on the buildds is
probably insignificant compared to the total time needed to build
the package...  And since generating it can be done with a trivial
shell command, it's not a complexity issue either.

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Stefano Zacchiroli]

On Fri, Aug 17, 2007 at 10:07:36AM +0200, Romain Francoise wrote:
> Thanks for initiating the discussion! :-)

Well, no, thank you, it's actually you who initiated the discussion :)

> One thing I've been pondering about is: are there any good reasons
> *not* to have an md5sums control file?

I fail to see any of those. I think that most of the packages without
the md5sums just happen to have been packaged before dh_md5sums was
available, and later on did not add its invocation to debian/rules.
Similarly all packages which uses cdbs for sure have the md5sums (since
cdbs invokes it).

I consider it to be one of the "new" packaging best practice which fails
to distribute "back in time" to old packages.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: proposed release goal: DEBIAN/md5sums for all packages

[Lars Wirzenius]

pe, 2007-08-17 kello 10:07 +0200, Romain Francoise kirjoitti:
> It seems to me that the time spent to generate it on the buildds is
> probably insignificant compared to the total time needed to build
> the package...  And since generating it can be done with a trivial
> shell command, it's not a complexity issue either.

It strikes me that if we want to make it policy, having dpkg generate
the checksums upon creating the .deb would be the simplest and best way
to do it. This way we wouldn't have to change packages to do it, and if
we ever want to change the format (sha1 as well as md5?) there's only
one place to change it.

-- 
Latest nerd movie: Once were hackers


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Lars Wirzenius]

pe, 2007-08-17 kello 10:58 +0200, Stefano Zacchiroli kirjoitti:
> I fail to see any of those. I think that most of the packages without
> the md5sums just happen to have been packaged before dh_md5sums was
> available,

There's also a number of packages packaged without using debhelper.
(Mine is, until I finally give up soon and re-package it with cdbs,
since anything else is too much work to conform to the Python policy.)

-- 
Policy is your friend. Trust the Policy. Love the Policy. Obey the
Policy.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debhelper - docbookxml manpages

[Sylvain Le Gall]

Hello,

I just read your script which is quite interesting. I am working on a
CDBS class for managing docbook-xml generated manpage and po4a
translation of it. For now, it works quite well and i have tested it in
some of my packages. You can have a look at this here:

http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/mk/docbook-manpage.mk?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/mk/po4a.mk?op=file&rev=0&sc=0
http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/rules?op=file&rev=0&sc=0

You can also have a look at other package i do with it: camlidl,
camomile. (same subversion repository, or use debcheckout).

I am maintaining the source of this CDBS class on a private VCS, but i
am willing to collaborate, if you think there is something that you can
reuse for po4a files (speaking for me, i think i will try to copy you
way to guess manpage section ;-).

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#423503: ttf-liberation (Re: Debian on the Desktop - plans for Lenny?)

[Alan Baghumian]

Hi,

Unfortunately, there was no answer about this licensing issue.

Alan

> Hi,
>
> On Thursday 09 August 2007 10:03, Christian Perrier wrote:
>> > > > No, we should use the liberation fonts, which are designed to
>> replace
>> > > > the MS fonts.
>> > > Have their licensing issues been solved?
>
> Have those issues been communicated to upstream and what is their
> reaction?
>
> The ITP includes the same question, in June, but no answer yet.
>
>
> regards,
>   Holger
>



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debhelper - docbookxml manpages

[Carl Fürstenberg]

On 8/17/07, Sylvain Le Gall <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I just read your script which is quite interesting. I am working on a
> CDBS class for managing docbook-xml generated manpage and po4a
> translation of it. For now, it works quite well and i have tested it in
> some of my packages. You can have a look at this here:
>
> http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/mk/docbook-manpage.mk?op=file&rev=0&sc=0
> http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/mk/po4a.mk?op=file&rev=0&sc=0
> http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/rules?op=file&rev=0&sc=0
>
> You can also have a look at other package i do with it: camlidl,
> camomile. (same subversion repository, or use debcheckout).
>
> I am maintaining the source of this CDBS class on a private VCS, but i
> am willing to collaborate, if you think there is something that you can
> reuse for po4a files (speaking for me, i think i will try to copy you
> way to guess manpage section ;-).
>
> Regards,
> Sylvain Le Gall
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>

I made first a cdbs script (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=docbook-xml-manpage.mk;att=1;bug=433852
), though without po4a support, then I was asked that it should be a
debhelper program instead. After that I got feedback that it shouldn't
build and install in the same script (from irc).

-- 
/Carl Fürstenberg <[EMAIL PROTECTED]>

Re: Debhelper - docbookxml manpages

[Sylvain Le Gall]

On 17-08-2007, Carl Fürstenberg <[EMAIL PROTECTED]> wrote:
> On 8/17/07, Sylvain Le Gall <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> I just read your script which is quite interesting. I am working on a
>> CDBS class for managing docbook-xml generated manpage and po4a
>> translation of it. For now, it works quite well and i have tested it in
>> some of my packages. You can have a look at this here:
>>
>> http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/mk/docbook-manpage.mk?op=file&rev=0&sc=0
>> http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/mk/po4a.mk?op=file&rev=0&sc=0
>> http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/rules?op=file&rev=0&sc=0
>>
>> You can also have a look at other package i do with it: camlidl,
>> camomile. (same subversion repository, or use debcheckout).
>>
>> I am maintaining the source of this CDBS class on a private VCS, but i
>> am willing to collaborate, if you think there is something that you can
>> reuse for po4a files (speaking for me, i think i will try to copy you
>> way to guess manpage section ;-).
>>
>> Regards,
>> Sylvain Le Gall
>>
>>
>> --
>> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
>> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>>
>>
>
> I made first a cdbs script (see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=docbook-xml-manpage.mk;att=1;bug=433852
> ), though without po4a support, then I was asked that it should be a
> debhelper program instead. After that I got feedback that it shouldn't
> build and install in the same script (from irc).
>

OK, now i see that you already know my CDBS class (since you derive you
first work on it).

I am really not sure it should be a debhelper script, since it will make
debhelper depends on docbook-xml... Which is not good in my mind. 

Maybe you could split the thing as this :
* define a debian/XXX.docbookxmlmanpages file, it contains all
  the toplevel xml file to install (firt column) and the generated manpage
  (optional, second column). If the generated manpage is not defined, it
  is assumed that it will be generated in the same directory of the
  source XML and using the name you can guess out of the XML file (just
  as you do in your debhelper script)
* the CDBS class will use the debian/*.docbookxmlmanpages as an input to
  guess what file to generate
* the debhelper script will use the debian/*.docbookxmlmanpages as an
  input to install the generated manpage.

People who don't want to use the CDBS class, can generate the manpage by
another way and still use everything (except the CDBS class). 

People who want to use the CDBS class, just have to write the manpage
;-)

If i am missing something, let me know. In particular, i don't have
followed the IRC talk about this (maybe you can send me a quick
summary). 

If you are interested in providing a full support of docbook XML
manpage, just tell me and i will give you a copy of my DARCS repository
so we can work on a good solution (before proposing to integrate it into
debhelper/cdbs).

Regards
Sylvain Le Gall

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debhelper - docbookxml manpages

[Carl Fürstenberg]

On 8/17/07, Sylvain Le Gall <[EMAIL PROTECTED]> wrote:
> On 17-08-2007, Carl Fürstenberg <[EMAIL PROTECTED]> wrote:
> > On 8/17/07, Sylvain Le Gall <[EMAIL PROTECTED]> wrote:
> >> Hello,
> >>
> >> I just read your script which is quite interesting. I am working on a
> >> CDBS class for managing docbook-xml generated manpage and po4a
> >> translation of it. For now, it works quite well and i have tested it in
> >> some of my packages. You can have a look at this here:
> >>
> >> http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/mk/docbook-manpage.mk?op=file&rev=0&sc=0
> >> http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/mk/po4a.mk?op=file&rev=0&sc=0
> >> http://svn.debian.org/wsvn/pkg-ocaml-maint/trunk/packages/cameleon/trunk/debian/rules?op=file&rev=0&sc=0
> >>
> >> You can also have a look at other package i do with it: camlidl,
> >> camomile. (same subversion repository, or use debcheckout).
> >>
> >> I am maintaining the source of this CDBS class on a private VCS, but i
> >> am willing to collaborate, if you think there is something that you can
> >> reuse for po4a files (speaking for me, i think i will try to copy you
> >> way to guess manpage section ;-).
> >>
> >> Regards,
> >> Sylvain Le Gall
> >>
> >>
> >> --
> >> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> >> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
> >>
> >>
> >
> > I made first a cdbs script (see
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=15;filename=docbook-xml-manpage.mk;att=1;bug=433852
> > ), though without po4a support, then I was asked that it should be a
> > debhelper program instead. After that I got feedback that it shouldn't
> > build and install in the same script (from irc).
> >
>
> OK, now i see that you already know my CDBS class (since you derive you
> first work on it).
>
> I am really not sure it should be a debhelper script, since it will make
> debhelper depends on docbook-xml... Which is not good in my mind.
>
> Maybe you could split the thing as this :
> * define a debian/XXX.docbookxmlmanpages file, it contains all
>   the toplevel xml file to install (firt column) and the generated manpage
>   (optional, second column). If the generated manpage is not defined, it
>   is assumed that it will be generated in the same directory of the
>   source XML and using the name you can guess out of the XML file (just
>   as you do in your debhelper script)
> * the CDBS class will use the debian/*.docbookxmlmanpages as an input to
>   guess what file to generate
> * the debhelper script will use the debian/*.docbookxmlmanpages as an
>   input to install the generated manpage.
>
> People who don't want to use the CDBS class, can generate the manpage by
> another way and still use everything (except the CDBS class).
>
> People who want to use the CDBS class, just have to write the manpage
> ;-)
>
> If i am missing something, let me know. In particular, i don't have
> followed the IRC talk about this (maybe you can send me a quick
> summary).
>
> If you are interested in providing a full support of docbook XML
> manpage, just tell me and i will give you a copy of my DARCS repository
> so we can work on a good solution (before proposing to integrate it into
> debhelper/cdbs).
>
> Regards
> Sylvain Le Gall
>
> Regards,
> Sylvain Le Gall
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>

A thing to remember is that one xml file can result in multiple man
pages, that's why I'm using libxml to grab all the manpages from the
xml file, in the cdbs version to know what to remove, and in the
debhelper version to know what file to install.

-- 
/Carl Fürstenberg <[EMAIL PROTECTED]>

Re: proposed release goal: DEBIAN/md5sums for all packages

[Stefano Zacchiroli]

On Fri, Aug 17, 2007 at 12:35:30PM +0200, Romain Francoise wrote:
> For the record, the list of binary packages without md5sums

Can you please upload this to people.debian.org or somewhere, and maybe
keep it periodically updated?  I guess it would be useful for the sake
of deciding what to do.

> (give or take a few that python-debian doesn't know how to parse):

Are you using the "debian_bundle.debfile" module for that?

I would be happy to receive in a bug report about what it fails to
parse.

More generally I'm also interested in some feedback if you tried it on
the whole archive, since we haven't yet had a lot of large use case
report about it.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: proposed release goal: DEBIAN/md5sums for all packages

[Romain Francoise]

Stefano Zacchiroli <[EMAIL PROTECTED]> writes:

> Can you please upload this to people.debian.org or somewhere, and maybe
> keep it periodically updated?  I guess it would be useful for the sake
> of deciding what to do.

No problem, will do.

> Are you using the "debian_bundle.debfile" module for that?
> I would be happy to receive in a bug report about what it fails to
> parse.

Yep, it was sitting in my outbox and I've just sent it:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438486

> More generally I'm also interested in some feedback if you tried
> it on the whole archive, since we haven't yet had a lot of large
> use case report about it.

It's great, and surprisingly fast.  It scans the mirror (sid, all
sections, amd64+all) in about 25 seconds on my desktop machine.

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debhelper - docbookxml manpages

[Daniel Leidert]

Am Freitag, den 17.08.2007, 12:11 +0200 schrieb Carl Fürstenberg:
> On 8/17/07, Sylvain Le Gall <[EMAIL PROTECTED]> wrote:

[..]
> > Maybe you could split the thing as this :
> > * define a debian/XXX.docbookxmlmanpages file, it contains all
> >   the toplevel xml file to install (firt column) and the generated manpage
> >   (optional, second column).

When you use a make-snippet, you could also define the manpages to
create and write a rule, howto create e.g. .1 from .1.xml. In make:

.SUFFIXES: .xml
.xml:
xsltproc ... $< ...

> >   If the generated manpage is not defined, it
> >   is assumed that it will be generated in the same directory of the
> >   source XML and using the name you can guess out of the XML file (just
> >   as you do in your debhelper script)
> > * the CDBS class will use the debian/*.docbookxmlmanpages as an input to
> >   guess what file to generate

See above.

> > * the debhelper script will use the debian/*.docbookxmlmanpages as an
> >   input to install the generated manpage.

Here you could use the option to create a manifest file and then simply
grep the contents of this file. I do it this way to not bother the user
with another file to maintain. See my solution at:
http://debian.wgdd.de/temp/dbxsl/dbxsl/debian/contrib/dh_db-man.make. My
idea was to automatically update a file (and the user could set this
file to package.manpages, so the file is automatically created).

> > People who don't want to use the CDBS class, can generate the manpage by
> > another way and still use everything (except the CDBS class).
> >
> > People who want to use the CDBS class, just have to write the manpage
> > ;-)
> >
> > If i am missing something, let me know. In particular, i don't have
> > followed the IRC talk about this (maybe you can send me a quick
> > summary).
> >
> > If you are interested in providing a full support of docbook XML
> > manpage, just tell me and i will give you a copy of my DARCS repository
> > so we can work on a good solution (before proposing to integrate it into
> > debhelper/cdbs).
>
> A thing to remember is that one xml file can result in multiple man
> pages, that's why I'm using libxml to grab all the manpages from the
> xml file,

This is not necessary. Check the man.output.manifest.enabled parameter
of docbook-xsl. The created file contains the names and paths (the
latter if subdirs are enabled) of all created manpages. You can safely
use this this option and then check the created manifest (change the
filename of this file via the man.output.manifest.filename parameter).

> in the cdbs version to know what to remove, and in the
> debhelper version to know what file to install.

See above.

Regards, Daniel

Re: proposed release goal: DEBIAN/md5sums for all packages

[Romain Francoise]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

> There's also a number of packages packaged without using
> debhelper.

Yep, that's what prompted me to look into this, I recently added
md5sums to rcs which doesn't use debhelper.

For the record, the list of binary packages without md5sums (give or
take a few that python-debian doesn't know how to parse):



Dale Scheetz (Dwarf #1) <[EMAIL PROTECTED]>
   spider

Adam Cécile (Le_Vert) <[EMAIL PROTECTED]>
   audacious-plugins-dev

Danai SAE-HAN <[EMAIL PROTECTED]>
   cjk-latex
   latex-cjk-all

Clint Adams <[EMAIL PROTECTED]>
   bogofilter
   zsh-dbg
   zsh-dev

Cosimo Alfarano <[EMAIL PROTECTED]>
   pyg

Bill Allombert <[EMAIL PROTECTED]>
   flwm

Hakan Ardo <[EMAIL PROTECTED]>
   xfaces

Ben Armstrong <[EMAIL PROTECTED]>
   junior-arcade
   junior-art
   junior-doc
   junior-games-card
   junior-games-gl
   junior-games-net
   junior-games-sim
   junior-games-text
   junior-gnome
   junior-internet
   junior-kde
   junior-math
   junior-programming
   junior-puzzle
   junior-sound
   junior-system
   junior-toys
   junior-typing
   junior-writing
   subproject-howto
   xpilot-client-common
   xpilot-client-nas
   xpilot-client-nosound
   xpilot-client-rplay
   xpilot-server

Ernesto Nadir Crespo Avila <[EMAIL PROTECTED]>
   flowscan
   nitpic
   xwhois

Alan Bain <[EMAIL PROTECTED]>
   f2c
   libf2c2
   libf2c2-dev
   nec
   ratfor
   rbootd
   xnecview

Mark Baker <[EMAIL PROTECTED]>
   inform-docs

Mark Baker <[EMAIL PROTECTED]>
   chimera2

Roland Bauerschmidt <[EMAIL PROTECTED]>
   colormake

Christoph Baumann <[EMAIL PROTECTED]>
   pop3browser

Daniel Baumann <[EMAIL PROTECTED]>
   lib32ncurses5
   lib32ncurses5-dev
   libncurses5
   libncurses5-dbg
   libncurses5-dev
   libncursesw5
   libncursesw5-dbg
   libncursesw5-dev
   ncurses-base
   ncurses-bin
   ncurses-term

Edelhard Becker <[EMAIL PROTECTED]>
   vifm

Christoph Berg <[EMAIL PROTECTED]>
   sdate

Ed Boraas <[EMAIL PROTECTED]>
   anarchism

Cyril Bouthors <[EMAIL PROTECTED]>
   gnuplot

John Bovey <[EMAIL PROTECTED]>
   libnjb-doc

Goswin von Brederlow <[EMAIL PROTECTED]>
   debmirror

Jeff Breidenbach <[EMAIL PROTECTED]>
   mhonarc

Ludovic Brenta <[EMAIL PROTECTED]>
   adacontrol

Adrian Bridgett <[EMAIL PROTECTED]>
   xbill

Mark Brown <[EMAIL PROTECTED]>
   nis
   tua

Rob Browning <[EMAIL PROTECTED]>
   emacsen-common
   lockfile-progs
   stalin

Thomas Bushnell, BSG <[EMAIL PROTECTED]>
   miscfiles
   slib

Eric Van Buggenhaut <[EMAIL PROTECTED]>
   udhcpc
   udhcpd

Bruno Barrera C. <[EMAIL PROTECTED]>
   xmame-gl

Juan Cespedes <[EMAIL PROTECTED]>
   bcc
   bin86
   genromfs

Christopher Cramer <[EMAIL PROTECTED]>
   usermode

Marco d'Itri <[EMAIL PROTECTED]>
   binkd
   br2684ctl
   eciadsl
   gup
   ifcico
   ifgate
   ifmail
   inn
   innfeed
   libberkeleydb-perl
   libnet-whois-ripe-perl
   libvolume-id-dev
   libvolume-id0
   module-init-tools
   netbase
   ninpaths
   openbsd-inetd
   ppp-dev
   purity-off
   rblcheck
   tin
   udev
   update-inetd
   vacation
   whois

Debconf Developers <[EMAIL PROTECTED]>
   debconf-english

Debian Berkeley DB Maintainers <[EMAIL PROTECTED]>
   db4.2-util
   db4.3-doc
   db4.3-util
   db4.4-doc
   db4.4-util
   db4.5-doc
   db4.5-util
   db4.6-doc
   db4.6-util
   libdb-dev
   libdb4.2
   libdb4.2++-dev
   libdb4.2++c2
   libdb4.2-dev
   libdb4.2-java
   libdb4.2-java-dev
   libdb4.2-tcl
   libdb4.3
   libdb4.3++-dev
   libdb4.3++c2
   libdb4.3-dev
   libdb4.3-java
   libdb4.3-java-dev
   libdb4.3-tcl
   libdb4.4
   libdb4.4++
   libdb4.4++-dev
   libdb4.4-dev
   libdb4.4-java
   libdb4.4-java-dev
   libdb4.4-tcl
   libdb4.5
   libdb4.5++
   libdb4.5++-dev
   libdb4.5-dev
   libdb4.5-java
   libdb4.5-java-dev
   libdb4.5-java-gcj
   libdb4.5-tcl
   libdb4.6
   libdb4.6++
   libdb4.6++-dev
   libdb4.6-dbg
   libdb4.6-java
   libdb4.6-java-dev
   libdb4.6-java-gcj
   libdb4.6-tcl

Debian Edu Developers <[EMAIL PROTECTED]>
   debian-edu-archive-keyring

Debian Games Team <[EMAIL PROTECTED]>
   xtux

Debian GCC Maintainers <[EMAIL PROTECTED]>
   g++
   g++-multilib
   g77
   gcc-multilib
   gcj
   gfortran
   gfortran-multilib
   gij
   gnat
   gobjc
   gobjc++
   gobjc++-4.1-multilib
   gobjc++-4.2-multilib
   gobjc++-multilib
   gobjc-multilib
   gpc
   gpc-doc

Debian GIS Project <[EMAIL PROTECTED]>
   hdf4-tools
   libhdf4g
   libhdf4g-dev
   libhdf4g-doc

Debian Install System Team <[EMAIL PROTECTED]>
   cdebconf
   debian-installer
   installation-guide-alpha
   installation-guide-amd64
   installation-guide-arm
   installation-guide-hppa
   installation-guide-i386
   installation-guide-ia64
   installation-guide-mips
   installation-guide-mipsel
   installation-guide-powerpc
   installation-guide-s390
   installation-guide-sparc
   installation-report
   libdebconfclient0
   libdebconfclient0-dev
   os-prober
   user-setup

Debian Kernel Team <[EMAIL PROTECTED]>
   ipw3945d

Debian Mono Group <[EMAIL PROTECTED]>
   mono

Debian multimedia p

Re: proposed release goal: DEBIAN/md5sums for all packages

[Adeodato Simó]

* Romain Francoise [Fri, 17 Aug 2007 12:35:30 +0200]:

> Adeodato Simó <[EMAIL PROTECTED]>
>amarok-engines

This is a false positive. The package only ships /usr/share/doc/amarok-engines,
which is a symlink.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
If you want this to happen, do not use the word "bottom" with me again, Kirk.
-- Luke Danes


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#438484: ITP: libdata-dump-streamer-perl -- Perl module for accurately serializing a data structure as Perl code

[Alexis Sukrieh]

Package: wnpp
Severity: wishlist
Owner: Alexis Sukrieh <[EMAIL PROTECTED]>


* Package name: libdata-dump-streamer-perl
  Version : 2.03-30
  Upstream Author : Yves Orton <[EMAIL PROTECTED]>
* URL : 
http://search.cpan.org/~yves/Data-Dump-Streamer-2.03-30/lib/Data/Dump/Streamer.pm
* License : Artistic License
  Programming Lang: Perl
  Description : Perl module for accurately serializing a data structure as 
Perl code

Given a list of scalars or reference variables, writes out their contents in 
perl syntax. The references can also be objects. The contents of each variable 
is output using the least number of Perl statements as convenient, usually only 
one. Self-referential structures, closures, and objects are output correctly.

The return value can be evaled to get back an identical copy of the original 
reference structure. In some cases this may require the use of utility subs 
that Data::Dump::Streamer will optionally export.

This module is very similar in concept to the core module Data::Dumper, with 
the major differences being that this module is designed to output to a stream 
instead of constructing its output in memory (trading speed for memory), and 
that the traversal over the data structure is effectively breadth first versus 
the depth first traversal done by the others.

In fact the data structure is scanned twice, first in breadth first mode to 
perform structural analysis, and then in depth first mode to actually produce 
the output, but obeying the depth relationships of the first pass.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-vserver-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#438485: ITP: libdevel-repl-perl -- Perl module for building a modern Perl interactive shell

[Alexis Sukrieh]

Package: wnpp
Severity: wishlist
Owner: Alexis Sukrieh <[EMAIL PROTECTED]>


* Package name: libdevel-repl-perl
  Version : 1.001000
  Upstream Author : Matt S Trout <[EMAIL PROTECTED]>
* URL : 
http://search.cpan.org/~mstrout/Devel-REPL-1.001000/lib/Devel/REPL.pm
* License : Artistic licence
  Programming Lang: Perl
  Description : Perl module for building a modern Perl interactive shell

Devel::REPL is a Moose-based and very flexible module to create
Read-Evaluate-Print-Loops (REPL) in Perl.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-vserver-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#438487: ITP: liblexical-persistence-perl -- Perl module for accessing persistent data through lexical variables.

[Alexis Sukrieh]

Package: wnpp
Severity: wishlist
Owner: Alexis Sukrieh <[EMAIL PROTECTED]>


* Package name: liblexical-persistence-perl
  Version : 0.97
  Upstream Author : Rocco Caputo
* URL : 
http://search.cpan.org/~rcaputo/Lexical-Persistence-0.97/lib/Lexical/Persistence.pm
* License : Artistic Licence
  Programming Lang: Perl
  Description : Perl module for accessing persistent data through lexical 
variables.

Lexical::Persistence does a few things, all related. Note that all the
behaviors listed here are the defaults. Subclasses can override nearly
every aspect of Lexical::Persistence's behavior.

Lexical::Persistence lets your code access persistent data through
lexical variables. This example prints "some value" because the value of
$x perists in the $lp object between setter() and getter().

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-vserver-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#438488: ITP: libmoosex-getopt-perl -- Moose role for processing command line options

[Alexis Sukrieh]

Package: wnpp
Severity: wishlist
Owner: Alexis Sukrieh <[EMAIL PROTECTED]>


* Package name: libmoosex-getopt-perl
  Version : 0.05
  Upstream Author : Stevan Little <[EMAIL PROTECTED]>,
Brandon L.  Black, <[EMAIL PROTECTED]>
* URL : 
http://search.cpan.org/~stevan/MooseX-Getopt-0.05/lib/MooseX/Getopt.pm
* License : Artistic Licence
  Programming Lang: Perl
  Description : Moose role for processing command line options

This module is a role which provides an alternate constructor for creating
objects using parameters passed in from the command line.

This module attempts to DWIM as much as possible with the command line params
by introspecting your class's attributes. It will use the name of your
attribute as the command line option, and if there is a type constraint
defined, it will configure Getopt::Long to handle the option accordingly.

You can use the attribute metaclass MooseX::Getopt::Meta::Attribute to get
non-default commandline option names and aliases.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-vserver-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[gregor herrmann]

On Fri, 17 Aug 2007 12:35:30 +0200, Romain Francoise wrote:

> Debian Perl Group <[EMAIL PROTECTED]>
>libchemistry-elements-perl
>libdbd-odbc-perl
>libdigest-hmac-perl
>libmath-combinatorics-perl
>libmath-derivative-perl
>libmath-numbercruncher-perl
>libmath-spline-perl
>libole-storage-lite-perl
>libstar-parser-perl
>libtk-gbarr-perl
>libtk-histentry-perl
>libtk-splashscreen-perl

Thanks for the list, I've fixed them all in svn and Damyan has
started to review and upload them.

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian: the universal operating system - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Rigmor Gustafsson: The More I See


signature.asc
Description: Digital signature

Bug#438490: ITP: libnamespace-clean-perl -- Perl module for keeping imports and functions out of the current namespace

[Alexis Sukrieh]

Package: wnpp
Severity: wishlist
Owner: Alexis Sukrieh <[EMAIL PROTECTED]>


* Package name: libnamespace-clean-perl
  Version : 0.05
  Upstream Author : Robert 'phaylon' Sedlacek <[EMAIL PROTECTED]>
* URL 
:http://search.cpan.org/~phaylon/namespace-clean-0.05/lib/namespace/clean.pm
* License : Artistic Licence
  Programming Lang: Perl
  Description : Perl module for keeping imports and functions out of the 
current namespace

When you define a function, or import one, into a Perl package, it will
naturally also be available as a method. This does not per se cause problems,
but it can complicate subclassing and, for example, plugin classes that are
included via multiple inheritance by loading them as base classes.

The namespace::clean pragma will remove all previously declared or imported
symbols at the end of the current package's compile cycle. Functions called in
the package itself will still be bound by their name, but they won't show up as
methods on your class or instances.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-vserver-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Marc 'HE' Brockschmidt]

Lars Wirzenius <[EMAIL PROTECTED]> writes:
> pe, 2007-08-17 kello 10:07 +0200, Romain Francoise kirjoitti:
>> It seems to me that the time spent to generate it on the buildds is
>> probably insignificant compared to the total time needed to build
>> the package...  And since generating it can be done with a trivial
>> shell command, it's not a complexity issue either.
> It strikes me that if we want to make it policy, having dpkg generate
> the checksums upon creating the .deb would be the simplest and best way
> to do it. This way we wouldn't have to change packages to do it, and if
> we ever want to change the format (sha1 as well as md5?) there's only
> one place to change it.

Yes, that sounds like a good idea. It might also be interesting to not
put those into the control.tar.gz, but directly into the deb, so that it
can easily be extracted.

Marc
-- 
BOFH #73:
Daemons did it


pgpbxQEAtKlMa.pgp
Description: PGP signature

Bug#438489: ITP: libmoosex-object-pluggable-perl -- Moose role for loading and handling plugins within a Moose class

[Alexis Sukrieh]

Package: wnpp
Severity: wishlist
Owner: Alexis Sukrieh <[EMAIL PROTECTED]>


* Package name: libmoosex-object-pluggable-perl
  Version : 0.0005
  Upstream Author : Guillermo Roditi, <[EMAIL PROTECTED]>
* URL : 
http://search.cpan.org/~groditi/MooseX-Object-Pluggable-0.0005/lib/MooseX/Object/Pluggable.pm
* License : Artistic Licence
  Programming Lang: Perl
  Description : Moose role for loading and handling plugins within a Moose 
class

This module is meant to be loaded as a role from Moose-based classes it will
add five methods and four attributes to assist you with the loading and
handling of plugins and extensions for plugins.

Plugins and extensions are just Roles by a fancy name. They are loaded at
runtime on demand and are instance, not class based. This means that if you
have more than one instance of a class they can all have different plugins
loaded. This is a feature.

Plugin methods are allowed to around, before, after their consuming classes, so
it is important to watch for load order as plugins can and will overload each
other. You may also add attributes through has.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-vserver-k7
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Roland Mas]

Stefano Zacchiroli, 2007-08-17 12:43:55 +0200 :

> On Fri, Aug 17, 2007 at 12:35:30PM +0200, Romain Francoise wrote:
>> For the record, the list of binary packages without md5sums
>
> Can you please upload this to people.debian.org or somewhere, and
> maybe keep it periodically updated?  I guess it would be useful for
> the sake of deciding what to do.

  Maybe add a lintian/linda test?  Maybe add that to Lina
(http://asdfasdf.debian.net/~tar/lina/)?

Roland.
-- 
Roland Mas

Fate always wins...  At least, when people stick to the rules.
  -- in Interesting Times (Terry Pratchett)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Stefano Zacchiroli]

On Fri, Aug 17, 2007 at 01:58:14PM +0200, Marc 'HE' Brockschmidt wrote:
> Yes, that sounds like a good idea.

Agreed. But needs someone willing to patch dpkg for that: volunteers?

> It might also be interesting to not put those into the control.tar.gz,
> but directly into the deb, so that it can easily be extracted.

I don't see the point here.

dpkg-deb would probably be responsible of creating the md5sums and of
extracting them on demand. Hence, having them inside control.tar.gz or
outside it is just an implementation detail of dpkg-deb. The only thing
you gain having them outside control.tar.gz is that you can extract such
information via plain ar ...  what's for?

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Debhelper - docbookxml manpages

[Sylvain Le Gall]

On 17-08-2007, Daniel Leidert <[EMAIL PROTECTED]> wrote:
> Am Freitag, den 17.08.2007, 12:11 +0200 schrieb Carl Fürstenberg:
>> On 8/17/07, Sylvain Le Gall <[EMAIL PROTECTED]> wrote:
>
> [..]
>> > Maybe you could split the thing as this :
>> > * define a debian/XXX.docbookxmlmanpages file, it contains all
>> >   the toplevel xml file to install (firt column) and the generated manpage
>> >   (optional, second column).
>
> When you use a make-snippet, you could also define the manpages to
> create and write a rule, howto create e.g. .1 from .1.xml. In make:
>
> .SUFFIXES: .xml
> .xml:
>   xsltproc ... $< ...
>

Unfortunately, there was no real former policy concerning docbook xml
file name... Most of the docbook xml manpage are simple "XXX.xml" and
sometimes "XXX.dbk" (and XXX.1.xml and XXX.1perl.xml...). Thats the
reason why it is better, to my mind, to guess it at build time (rather
than listing all possible suffixes). But that is the way i was doing
thing before CDBS (which are after all kind of makefile snippet). 

I think CDBS/debhelper/makefile snippet can coexist. We just need to set
the thing such as building is done in CDBS/makefile (because it is the
best place to put it) and installing is done through debhelper.

> This is not necessary. Check the man.output.manifest.enabled parameter
> of docbook-xsl. The created file contains the names and paths (the
> latter if subdirs are enabled) of all created manpages. You can safely
> use this this option and then check the created manifest (change the
> filename of this file via the man.output.manifest.filename parameter).
>
>> in the cdbs version to know what to remove, and in the
>> debhelper version to know what file to install.
>

This manifest thing can be very useful. I will keep it in mind for my
next version of CDBS class.

In fact, i speak with someone at the last Debconf about building
something more clever with docbook -- not limited to manpage. So maybe
we can extend the use of the debhelper script to analyze the content of
the Docbook XML and generate a list of available options to complete a
file that will be used to do bash completion (using info provided in the
cmdsynopsys section...).

The debhelper script is a perfect place to do this ! (please comment
this statement ;-)

Regards,
Sylvain Le Gall


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Stefano Zacchiroli]

On Fri, Aug 17, 2007 at 12:56:14PM +0200, Romain Francoise wrote:
> > I would be happy to receive in a bug report about what it fails to
> > parse.
> Yep, it was sitting in my outbox and I've just sent it:
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438486

Thanks, this is now fixed in the python-debian repository. In the
meantime you can grab the new debfile.py from
http://people.debian.org/~zack/stalla/debfile.py if you want to re-run
your tests to see what happen with that 34 packages
(SPAM: or you can debcheckout python-debian of course, SCNR :-))

> It's great, and surprisingly fast.  It scans the mirror (sid, all
> sections, amd64+all) in about 25 seconds on my desktop machine.

Wow, I'm impressed by those numbers as well! Thanks for your feedback.

Cheers.

-- 
Stefano Zacchiroli -*- PhD in Computer Science ... now what?
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: proposed release goal: DEBIAN/md5sums for all packages

[Pierre Habouzit]

On Fri, Aug 17, 2007 at 11:58:14AM +, Marc 'HE' Brockschmidt wrote:
> Lars Wirzenius <[EMAIL PROTECTED]> writes:
> > pe, 2007-08-17 kello 10:07 +0200, Romain Francoise kirjoitti:
> >> It seems to me that the time spent to generate it on the buildds is
> >> probably insignificant compared to the total time needed to build
> >> the package...  And since generating it can be done with a trivial
> >> shell command, it's not a complexity issue either.
> > It strikes me that if we want to make it policy, having dpkg generate
> > the checksums upon creating the .deb would be the simplest and best way
> > to do it. This way we wouldn't have to change packages to do it, and if
> > we ever want to change the format (sha1 as well as md5?) there's only
> > one place to change it.
> 
> Yes, that sounds like a good idea. It might also be interesting to not
> put those into the control.tar.gz, but directly into the deb, so that it
> can easily be extracted.

  OTOH that sucks because it would mean that we have to rebuild the
whole archive that uses currently dh_md5sums, whereas we could just be
backward compatible.

  Other issue, md5sums files are used in /var/lib/dpkg/info/ where dpkg
puts the control.tar.gz's, and packages like debsums use it there. So we
would have to patch dpkg to also extract files that are in the .deb
into that directory as well, whereas it's already done for files in
control.tar.gz automatically. All in all, I'd say it's a pretty bad idea
for a minimal gain (control.tar.gz content is very small after all).


  But I agree that dpkg(-deb) is the place to plug this.

-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpwpvvjRGNjI.pgp
Description: PGP signature

Bug#436520: Dupe?

[Junichi Uekawa]

At Fri, 17 Aug 2007 08:24:29 +0900,
Junichi Uekawa wrote:
> 
> > > > 
> > > > Please provide information to where this bug is solved before closing
> > > > it. Reading this "resolved" bug gives me absolutely no hint on how to
> > > > fix this problem.
> > > 
> > > Is it not fixed yet for you?
> > > There was a server error.
> > 
> > I saw this today, propably using apt 0.7.3 (before todays upgrade).
> > It looks like it is working correctly in 0.7.6.
> > 
> > Which version is the bug supposed to be fixed in?
> 
> Ah sorry I mixed it up with another bug. 
> There's as bug filed against RUBY.
> 

http://dev.ctor.org/http-access2/ticket/161

and it seems to be fixed upstream.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#438501: ITP: gnome-video-arcade -- a simple xmame front-end for the GNOME Desktop Environment

[Francesco Namuri]

Package: wnpp
Severity: wishlist
Owner: Francesco Namuri <[EMAIL PROTECTED]>


  Package name: gnome-video-arcade
  Version : 0.4.2
  Upstream Author : Matthew Barnes <[EMAIL PROTECTED]>
  URL : http://sourceforge.net/projects/gva/
  License : GPL
  Programming Lang: C
  Description : a simple xmame front-end for the GNOME Desktop Environment

it's targeted towards non-technical arcade enthusiasts who just want to 
easily play classic arcade games on their desktop. Though it may be 
suitable for use in custom arcade cabinets, the project is not designed 
for that purpose.

The software is gradually maturing but is still lacking in
documentation. Some parts of the user interface still don't work,
such as the Search Results button or some of the tabs in the Properties
window.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (850, 'unstable'), (200, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-rc5-custom.1 (SMP w/1 CPU core)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Daniel Baumann]

Romain Francoise wrote:
> Daniel Baumann <[EMAIL PROTECTED]>
>lib32ncurses5
>lib32ncurses5-dev
>libncurses5
>libncurses5-dbg
>libncurses5-dev
>libncursesw5
>libncursesw5-dbg
>libncursesw5-dev
>ncurses-base
>ncurses-bin
>ncurses-term

fixed, thanks.

-- 
Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:  [EMAIL PROTECTED]
Internet:   http://people.panthera-systems.net/~daniel-baumann/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Request for ideas how to fix #297074

[Andrei Popescu]

On Tue, Aug 14, 2007 at 07:55:36PM +0100, Marcin Owsiany wrote:
 
> The only metadata available seems to be the Content-type field of the
> header in the original po file, but I can't see how to enforce it for
> the temporary file...

I'm not sure if this helps, but when I have to work with ISO-8859-2 
files on my computer (locale en_US.UTF-8) I just start vim with 
'LANG=ro_RO vim my_file'. I had no problems so far.

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


signature.asc
Description: Digital signature

Re: format not recognized

[Felipe Sateler]

Steve Langasek wrote:

> On Fri, Aug 17, 2007 at 12:41:31AM -0400, Felipe Sateler wrote:
>> I'm getting this warning when building csound:
> 
>> dpkg-shlibdeps: warning: format of 'NEEDED libcsnd.so' not recognized
> 
>> What does it mean and how can I fix it? man dpkg-shlibdeps doesn't say
>> anything, and I can objdump libcsnd.so without any trouble.
> 
>> I tried to read the source and apparently it can't parse the file because
>> it doesn't have a SONAME, but my perl knowledge is very close to zero so
>> I can't be sure (lines 197-210 of dpkg-shlibdeps).
> 
> It's not a question of being able to parse the file, it's that
> "libcsnd.so"
> is not a proper name for a shared library.  dpkg-shlibdeps is warning you
> about what appears to be a genuine bug in one of the libraries your
> package depends on.

Hm, so I have to introduce a SONAME? I will have to talk with upstream.

> 
> (Where is this from?  I find no references to libcsnd.so in the Debian
> Contents files.)
> 

It's from the new upstream version (5.06) which I'm packaging right now.


-- 

  Felipe Sateler


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: Re: Bug#436520: There is no policy on HTTP_PROXY variable, can we create one?

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> retitle 436520 There is no policy on HTTP_PROXY variable
Bug#436520: apt-listbugs: does not work with $http_proxy
Changed Bug title to `There is no policy on HTTP_PROXY variable' from 
`apt-listbugs: does not work with $http_proxy'.
(By the way, that Bug is currently marked as done.)

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Boost libraries name change (again)

[Junichi Uekawa]

Hi,

> The boost library short name has changed semantics in Debian.  Prior
> to 1.34.0-1, the short name was multi-threaded.  Now it is single
> threaded.

Thanks for the note!

I see this is a lot of effort going on to get inter-distribution
compatibility. It's great work of coordionation, thanks.


regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Russ Allbery]

Lars Wirzenius <[EMAIL PROTECTED]> writes:

> It strikes me that if we want to make it policy, having dpkg generate
> the checksums upon creating the .deb would be the simplest and best way
> to do it. This way we wouldn't have to change packages to do it, and if
> we ever want to change the format (sha1 as well as md5?) there's only
> one place to change it.

Some packages (aspell and ispell packages in particular) ship files that
they then modify in maintainer scripts and intentionally exclude them from
the md5sums file for that reason.  lintian has special code to deal with
this case.  A replacement in dpkg would either need to cope with this or
decide that those packages can no longer take that approach and have to
solve whatever problem they're solving in some other way.  (I don't know
what problem this is solving.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Russ Allbery]

Roland Mas <[EMAIL PROTECTED]> writes:

>   Maybe add a lintian/linda test?  Maybe add that to Lina
> (http://asdfasdf.debian.net/~tar/lina/)?

There's already a lintian test.  It's just only info-level because last
time I had checked there wasn't project consensus that md5sums should be
required.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#436520: There is no policy on HTTP_PROXY variable, can we create one?

[Junichi Uekawa]

Hi,

> > HTTP_PROXY, or http_proxy (and ftp_proxy) is used in many
> > applications within Debian.
> > 
> > There is a well-known remote attack using HTTP_* variables can be
> > set to arbitrary values for CGI scripts, and thus there is a need
> > for protection against that.
> 
> Is there any reason why programs which use HTTP_PROXY can't check
> GATEWAY_INTERFACE, SERVER_NAME, REQUEST_METHOD or similar and ignore
> the capitalized env variable in such a case?
> 
> [For reference, LWP ignores HTTP_PROXY for CGI_HTTP_PROXY in the
> presence of REQUEST_METHOD.]
> 
> The alternative is just to require CGIs to unset HTTP_PROXY (though
> CGI writers sometimes aren't terribly aware of these things.)

I think there also is a bit of confusion with handling of HTTP_PROXY
and http_proxy.

Looking at apache source, you can set 'HTTP_*' to arbitrary values,
and thus 'HTTP_PROXY' is a remotely modifiable variable, but
'http_proxy' is not.

That seems like the reason for some application to move into
lower-case http_proxy instead of HTTP_PROXY.

I don't quite fully understand the reasoning behind

1.  HTTP_PROXY is still used

2.  http_proxy is used and environment is checked for CGI invocation
(it should be safe, right?)


Could someone shed some light on this?

regards,
junichi
-- 
[EMAIL PROTECTED],netfort.gr.jp}   Debian Project


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Russ Allbery]

Kurt Roeckx <[EMAIL PROTECTED]> writes:
> On Fri, Aug 17, 2007 at 10:12:07AM -0700, Russ Allbery wrote:
>> Lars Wirzenius <[EMAIL PROTECTED]> writes:

>>> It strikes me that if we want to make it policy, having dpkg generate
>>> the checksums upon creating the .deb would be the simplest and best way
>>> to do it. This way we wouldn't have to change packages to do it, and if
>>> we ever want to change the format (sha1 as well as md5?) there's only
>>> one place to change it.

>> Some packages (aspell and ispell packages in particular) ship files
>> that they then modify in maintainer scripts and intentionally exclude
>> them from the md5sums file for that reason.  lintian has special code
>> to deal with this case.  A replacement in dpkg would either need to
>> cope with this or decide that those packages can no longer take that
>> approach and have to solve whatever problem they're solving in some
>> other way.  (I don't know what problem this is solving.)

> As I understand it, it's so that debsums doesn't complain about that
> files changes.

Right... I meant more what problem they had that they were solving by
installing a file in /var as part of the package and then modifying it
later.  (It always struck me as odd, but I presume they have good reasons
for doing things that way.)

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Kurt Roeckx]

On Fri, Aug 17, 2007 at 10:12:07AM -0700, Russ Allbery wrote:
> Lars Wirzenius <[EMAIL PROTECTED]> writes:
> 
> > It strikes me that if we want to make it policy, having dpkg generate
> > the checksums upon creating the .deb would be the simplest and best way
> > to do it. This way we wouldn't have to change packages to do it, and if
> > we ever want to change the format (sha1 as well as md5?) there's only
> > one place to change it.
> 
> Some packages (aspell and ispell packages in particular) ship files that
> they then modify in maintainer scripts and intentionally exclude them from
> the md5sums file for that reason.  lintian has special code to deal with
> this case.  A replacement in dpkg would either need to cope with this or
> decide that those packages can no longer take that approach and have to
> solve whatever problem they're solving in some other way.  (I don't know
> what problem this is solving.)

As I understand it, it's so that debsums doesn't complain about that
files changes.


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Kurt Roeckx]

On Fri, Aug 17, 2007 at 11:25:38AM -0700, Russ Allbery wrote:
> 
> >> Some packages (aspell and ispell packages in particular) ship files
> >> that they then modify in maintainer scripts and intentionally exclude
> >> them from the md5sums file for that reason.  lintian has special code
> >> to deal with this case.  A replacement in dpkg would either need to
> >> cope with this or decide that those packages can no longer take that
> >> approach and have to solve whatever problem they're solving in some
> >> other way.  (I don't know what problem this is solving.)
> 
> > As I understand it, it's so that debsums doesn't complain about that
> > files changes.
> 
> Right... I meant more what problem they had that they were solving by
> installing a file in /var as part of the package and then modifying it
> later.  (It always struck me as odd, but I presume they have good reasons
> for doing things that way.)

The hash file, which is architecture dependend, is created on install.
This is the only file in the package that is architecture dependend.

Anyway, there is a policy file about this in:
/usr/share/doc/dictionaries-common-dev/dsdt-policy.txt.gz


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#436520: There is no policy on HTTP_PROXY variable, can we create one?

[Don Armstrong]

On Fri, 17 Aug 2007, Mike Hommey wrote:
> On Thu, Aug 16, 2007 at 07:34:51PM -0700, Don Armstrong <[EMAIL PROTECTED]> 
> wrote:
> > On Fri, 17 Aug 2007, Junichi Uekawa wrote:
> > > HTTP_PROXY, or http_proxy (and ftp_proxy) is used in many
> > > applications within Debian.
> > > 
> > > There is a well-known remote attack using HTTP_* variables can be
> > > set to arbitrary values for CGI scripts, and thus there is a need
> > > for protection against that.
> > 
> > Is there any reason why programs which use HTTP_PROXY can't check
> > GATEWAY_INTERFACE, SERVER_NAME, REQUEST_METHOD or similar and ignore
> > the capitalized env variable in such a case?
> > 
> > [For reference, LWP ignores HTTP_PROXY for CGI_HTTP_PROXY in the
> > presence of REQUEST_METHOD.]
> > 
> > The alternative is just to require CGIs to unset HTTP_PROXY (though
> > CGI writers sometimes aren't terribly aware of these things.)
> 
> I'm not sure this would also be a terribly good idea... How about CGIs
> that need to get data from external HTTP servers which they can't access
> if not through a proxy ? (such case *do* exist)

Then they sanitize their ENV before calling the external proxying
program. The real issue is CGI programs accidentally passing
HTTP_PROXY to children.

What about the following:

Programs which do proxying should all accept http_proxy without the
need for further env. variables being set.

Programs which accept HTTP_PROXY for compatibility reasons should
deprecate such usage, and ignore HTTP_PROXY when REQUEST_METHOD or
GATEWAY_INTERFACE is set, ideally with an informative warning.


Don Armstrong

-- 
Frankly, if ignoring inane opinions and noisy people and not flaming
them to crisp is bad behaviour, I have not yet achieved a state of
nirvana.
 -- Manoj Srivastava in [EMAIL PROTECTED]

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Work-needing packages report for Aug 17, 2007

[Gunnar Wolf]

[EMAIL PROTECTED] dijo [Fri, Aug 17, 2007 at 12:26:43AM -0600]:
> The following packages have been orphaned:
> 
>mod-xinerama-for-ion (#438446), orphaned today
>  Description: Xinerama support for the Ion3 window manager
>  Installations reported by Popcon: 7

Wouldn't it be better to remove this package from the distribution?
Very few people use it, it does not have an upstream author (well,
yes, it has an upstream author who wants it dead ;-) ), and ion3
itself (although my WM of choice) is currently sitting in non-free
because of its author's... Rigidness :-/

Greetings,

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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#438570: ITP: libfilter-eof-perl -- Run a callback after a file has been compiled

[Damyan Ivanov]

Package: wnpp
Severity: wishlist
Owner: Damyan Ivanov <[EMAIL PROTECTED]>

* Package name: libfilter-eof-perl
  Version : 0.04
  Upstream Author : Robert 'phaylon' Sedlacek - "<[EMAIL PROTECTED]>"
* URL : http://www.cpan.org/authors/id/P/PH/PHAYLON/
* License : same as Perl
  Programming Lang: Perl
  Description : Run a callback after a file has been compiled

Filter::EOF utilises Perl's source filters to provide you with a
mechanism to run some code after a file using your module has been
processed.

It could also be used for appending Perl code to that file's source.
---
Filter::EOF is a dependency of namespace::clean


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Peter Samuelson]

[Lars Wirzenius]
> It strikes me that if we want to make it policy, having dpkg generate
> the checksums upon creating the .deb would be the simplest and best
> way to do it.

I'd opt for dpkg generating the checksums upon _extracting_ the .deb
file.  We already claim that the md5sums file isn't supposed to be any
kind of security thing.  Why bother to ship it?  It is redundant
information which can easily be regenerated on the user's system.

Russ's mention of packages that alter their installed files in the
postinst just seems not worth supporting.  Copy a template file
instead.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


signature.asc
Description: Digital signature

Re: proposed release goal: DEBIAN/md5sums for all packages

[Sven Mueller]

Kurt Roeckx schrieb:
> On Fri, Aug 17, 2007 at 11:25:38AM -0700, Russ Allbery wrote:
 Some packages (aspell and ispell packages in particular) ship files
 that they then modify in maintainer scripts and intentionally exclude
 them from the md5sums file for that reason. 
> 
> The hash file, which is architecture dependend, is created on install.
> This is the only file in the package that is architecture dependend.

If it is created on install, why is it in the packages filelist in the
first place? Other packages also generate (supposedly architecture
dependend) files during postinst, without shipping a placeholder in the
.deb - so what is the reason why [ia]spell does that?

Uhm, also: I couldn't find any such example in the [ia]spell packages
themselves nor in wamerican, myspell-de-de, ispell-de-de so perhaps
(some of) those packages used to do that sort of stuff, but refrain from
doing so now?

Regards,
Sven



signature.asc
Description: OpenPGP digital signature

Re: proposed release goal: DEBIAN/md5sums for all packages

[Lars Wirzenius]

pe, 2007-08-17 kello 17:05 -0500, Peter Samuelson kirjoitti:
> I'd opt for dpkg generating the checksums upon _extracting_ the .deb
> file.  We already claim that the md5sums file isn't supposed to be any
> kind of security thing.  Why bother to ship it?  It is redundant
> information which can easily be regenerated on the user's system.

That would work too, I guess. It would give more flexibility in the
choice of checksum, too. Still, it'd be dpkg doing it, not each package
separately.

-- 
When in doubt, use brute force.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Lars Wirzenius]

pe, 2007-08-17 kello 10:12 -0700, Russ Allbery kirjoitti:
> Some packages (aspell and ispell packages in particular) ship files that
> they then modify in maintainer scripts and intentionally exclude them from
> the md5sums file for that reason.  lintian has special code to deal with
> this case.  A replacement in dpkg would either need to cope with this or
> decide that those packages can no longer take that approach and have to
> solve whatever problem they're solving in some other way.  (I don't know
> what problem this is solving.)

dpkg could do its own checksum generation only if there isn't one in the
package already, or something like that. These special cases can surely
be worked around.

-- 
The difference between appealing and appalling is very small.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Anthony Towns]

On Fri, Aug 17, 2007 at 05:05:28PM -0500, Peter Samuelson wrote:
> I'd opt for dpkg generating the checksums upon _extracting_ the .deb
> file.  [...]

Where's the code for that?

Changing write_filelist_except to update a new .md5 control file ought to
be possible. You'd probably want to add a *newhash to struct filenamenode,
though, and fill it out when unpacking, but working out the hash while
unpacking (rather than running over every file to be unpacked twice)
would mean hax0ring into the fd_fd_copy() invocation in tarobject()
(archives.c), which seems tricky.

Cheers,
aj


signature.asc
Description: Digital signature

Re: proposed release goal: DEBIAN/md5sums for all packages

[Russ Allbery]

Sven Mueller <[EMAIL PROTECTED]> writes:

> If it is created on install, why is it in the packages filelist in the
> first place? Other packages also generate (supposedly architecture
> dependend) files during postinst, without shipping a placeholder in the
> .deb - so what is the reason why [ia]spell does that?
>   
> Uhm, also: I couldn't find any such example in the [ia]spell packages
> themselves nor in wamerican, myspell-de-de, ispell-de-de so perhaps
> (some of) those packages used to do that sort of stuff, but refrain from
> doing so now?

All I know about this topic is at:

http://lists.debian.org/debian-mentors/2006/10/msg00075.html
http://bugs.debian.org/324111
http://bugs.debian.org/346410
http://bugs.debian.org/374949
http://bugs.debian.org/401070

I'm happy to remove the exception again if this has changed.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Russ Allbery]

Peter Samuelson <[EMAIL PROTECTED]> writes:

> I'd opt for dpkg generating the checksums upon _extracting_ the .deb
> file.  We already claim that the md5sums file isn't supposed to be any
> kind of security thing.  Why bother to ship it?  It is redundant
> information which can easily be regenerated on the user's system.

While it's not the be-all and end-all of security, other OS vendors (Sun
in particular) have found it useful to make available a central database
of MD5 checksums of known-good versions of various binaries.  This has
proven invaluable in not a few breakins and compromises when doing
forensics.  Since we have such a database essentially for free now in the
form of the md5sums control files, I'd rather not take an approach that
gets rid of it, even if it isn't a horribly effective security measure.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Peter Samuelson]

[Russ Allbery]
> While it's not the be-all and end-all of security, other OS vendors
> (Sun in particular) have found it useful to make available a central
> database of MD5 checksums of known-good versions of various binaries.

H.  As far as being authoritative (and cryptographically secure),
we already have $MIRROR/dists/stable/main/binary-i386/Packages.bz2.

The thing is, if you're checking your system, you have to have
something to check it against.  If this is the md5sums file in
/var/lib/dpkg/info, it doesn't matter whether it's included in the
package.  But if you're using the copy from the .deb (because, say, you
don't trust your /var), it wouldn't be much harder to do 'dpkg-deb
--extract' and then md5sum the extracted directory, than to do
'dpkg-deb --control' and read DEBIAN/md5sums.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


signature.asc
Description: Digital signature

Re: format not recognized

[Steve Langasek]

On Fri, Aug 17, 2007 at 11:21:35AM -0400, Felipe Sateler wrote:

> > It's not a question of being able to parse the file, it's that
> > "libcsnd.so"
> > is not a proper name for a shared library.  dpkg-shlibdeps is warning you
> > about what appears to be a genuine bug in one of the libraries your
> > package depends on.

> Hm, so I have to introduce a SONAME? I will have to talk with upstream.

Yes, if you're going to ship a shared library in your package, it needs to
have a versioned soname.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Kurt Roeckx]

On Sat, Aug 18, 2007 at 01:27:45AM +0200, Sven Mueller wrote:
> > The hash file, which is architecture dependend, is created on install.
> > This is the only file in the package that is architecture dependend.
> 
> If it is created on install, why is it in the packages filelist in the
> first place? Other packages also generate (supposedly architecture
> dependend) files during postinst, without shipping a placeholder in the
> .deb - so what is the reason why [ia]spell does that?

I wasn't at all involved with writing this policy.  So, I'll have to
guess.

> Uhm, also: I couldn't find any such example in the [ia]spell packages
> themselves nor in wamerican, myspell-de-de, ispell-de-de so perhaps
> (some of) those packages used to do that sort of stuff, but refrain from
> doing so now?

Policy doesn't say you have to do this.  It's just one of the options.

examples are things like:
aspell-en
ipolish
aspell-pl
idutch
apsell-nl


Kurt


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Joey Hess]

Peter Samuelson wrote:
> The thing is, if you're checking your system, you have to have
> something to check it against.  If this is the md5sums file in
> /var/lib/dpkg/info, it doesn't matter whether it's included in the
> package.  But if you're using the copy from the .deb (because, say, you
> don't trust your /var), it wouldn't be much harder to do 'dpkg-deb
> --extract' and then md5sum the extracted directory, than to do
> 'dpkg-deb --control' and read DEBIAN/md5sums.

It's even easier to do:

dpkg --fsys-tarfile $deb | tar -C / -d

However, not all machines have the luxury of being able to store the
orignal .debs in /var, or of being able to redownload the same debs.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: proposed release goal: DEBIAN/md5sums for all packages

[Joey Hess]

Peter Samuelson wrote:
> I'd opt for dpkg generating the checksums upon _extracting_ the .deb
> file.

Not all debian systems have fast CPU and fast disk.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: proposed release goal: DEBIAN/md5sums for all packages

[Steinar H. Gunderson]

On Fri, Aug 17, 2007 at 08:23:38PM -0400, Joey Hess wrote:
>> I'd opt for dpkg generating the checksums upon _extracting_ the .deb
>> file.
> Not all debian systems have fast CPU and fast disk.

I could understand the fast CPU argument, but there's no good reason why
MD5ing at extraction time wouldn't be feasible, costing you zero extra disk
activity. If nothing else, the data is likely to be in the cache if you do
extract, md5, extract, md5 for each file or even for each package (depending
on the amount of RAM).

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Peter Samuelson]

[Joey Hess]
> It's even easier to do:
> 
> dpkg --fsys-tarfile $deb | tar -C / -d

Ha.  I didn't know about tar -d.  Yes, that is even better.

> However, not all machines have the luxury of being able to store the
> orignal .debs in /var, or of being able to redownload the same debs.

Indeed, but that is unrelated to the discussion of storing a md5sums
file in the .deb. (:
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


signature.asc
Description: Digital signature

Re: proposed release goal: DEBIAN/md5sums for all packages

[Sven Mueller]

Russ Allbery schrieb:
> Sven Mueller <[EMAIL PROTECTED]> writes:
> 
>> If it is created on install, why is it in the packages filelist in the
>> first place? Other packages also generate (supposedly architecture
>> dependend) files during postinst, without shipping a placeholder in the
>> .deb - so what is the reason why [ia]spell does that?
>>  
>> Uhm, also: I couldn't find any such example in the [ia]spell packages
>> themselves nor in wamerican, myspell-de-de, ispell-de-de so perhaps
>> (some of) those packages used to do that sort of stuff, but refrain from
>> doing so now?
> 
> All I know about this topic is at:
> 
> http://lists.debian.org/debian-mentors/2006/10/msg00075.html
> http://bugs.debian.org/324111
> http://bugs.debian.org/346410
> http://bugs.debian.org/374949
> http://bugs.debian.org/401070
> 
> I'm happy to remove the exception again if this has changed.
> 

In all those mails, the only justification for shipping these files in
the package - though they are changed (rebuilt?) during postinst - is
the following sentence from Brian Nelson (pyro):

> Also, not
> including these files in the .deb packages significantly complicates the
> packaging.  I really don't want to change to manangement of the files in
> maintainer scripts without a very good reason to do so.

He doesn't give any information _why_ this complicates packaging that
much, while his decision imposes additional work and complexity on
others (be it the exception in lintian and probably linda or the
difference between "dpkg -L" and the contents of the md5sums file, which
makes integrity checking a bit harder).

IMHO, packages (.deb) should only include files which are either listed
in conffiles or in md5sums.

The hash files in aspell/ispell/wordlist packages (for example*:
aspell-en, idutch) are neither conffiles nor in md5sums. They are said
to be arch-dependend and if I understand the aspell-en debian/rules
correctly, they are shipped as empty files. I don't see why they
couldn't just be created empty by the postinst before building the hash
tables. I especially don't see how that complicates packaging.

cu,
Sven

* Thanks to Kurt Roeckx for the examples

PS: I just verified that the files in question are indeed zero-length
files at least in aspell-en


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed release goal: DEBIAN/md5sums for all packages

[Manoj Srivastava]

On Fri, 17 Aug 2007 12:35:30 +0200, Romain Francoise
<[EMAIL PROTECTED]> said:  

> Manoj Srivastava <[EMAIL PROTECTED]>
>angband angband-doc c2man calc flex-old flex-old-doc
>libgraphics-colordeficiency-perl libgraphics-colornames-perl
>libgraphics-colorobject-perl libmodule-load-perl make-doc polgen
>polgen-doc selinux-doc sepolgen tla-tools wm-icons

Feh. That just goes to show how long these packages have not
 been uploaded;  since now ./debian/common defaults to generating the
 md5sum for my packages.

So, the next upload for any of these packages will automatically
 contain a md5sum file.

manoj
ps: I initially thought that the most efficient way of generating the
md3sums would be in dpkg; but  since I have been meaning to add this
into dpkg since '99 (according to my mail logs), but haven't gotten
around to doing it, it pretty much means I am not gonna be the one
to hack dpkg.
-- 
Darth Vader sleeps with a Teddywookie.
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]