Check if library has debug symbols

[Mathieu Malaterre]

Hi there,

  I am trying to compile tulip (*) for debugging with:

$ export DEB_BUILD_OPTIONS='noopt debug nostrip'
$ apt-get source tulip
$ cd tulip-3.1.2
$ dpkg-buildpackage

After installation, here is what objdump reveals (**). Does this means:
1. I did not export DEB_BUILD_OPTIONS ?
2. There is an issue in debian/rule for tulip that does not properly
generate debug symbols ?

Thanks,
-- 
Mathieu

(*)
http://packages.qa.debian.org/t/tulip.html

(**)
$ objdump -h /usr/lib/libtulip-3.1.so

/usr/lib/libtulip-3.1.so: file format elf64-x86-64

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .note.gnu.build-id 0024  0190  0190
0190  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .hash 5b10  01b8  01b8  01b8  2**3
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .gnu.hash 681c  5cc8  5cc8  5cc8  2**3
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .dynsym   000161b8  c4e8  c4e8  c4e8  2**3
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .dynstr   000354b5  000226a0  000226a0  000226a0  2**0
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .gnu.version  1d7a  00057b56  00057b56  00057b56  2**1
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  6 .gnu.version_r 00a0  000598d0  000598d0  000598d0  2**3
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  7 .rela.dyn 00013ce0  00059970  00059970  00059970  2**3
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  8 .rela.plt 7fc8  0006d650  0006d650  0006d650  2**3
  CONTENTS, ALLOC, LOAD, READONLY, DATA
  9 .init 0018  00075618  00075618  00075618  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
 10 .plt  5540  00075630  00075630  00075630  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
 11 .text 00142b38  0007ab70  0007ab70  0007ab70  2**4
  CONTENTS, ALLOC, LOAD, READONLY, CODE
 12 .fini 000e  001bd6a8  001bd6a8  001bd6a8  2**2
  CONTENTS, ALLOC, LOAD, READONLY, CODE
 13 .rodata   faa0  001bd6c0  001bd6c0  001bd6c0  2**5
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 14 .eh_frame_hdr 59fc  001cd160  001cd160  001cd160  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 15 .eh_frame 0001afdc  001d2b60  001d2b60  001d2b60  2**3
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 16 .gcc_except_table df6a  001edb3c  001edb3c
001edb3c  2**2
  CONTENTS, ALLOC, LOAD, READONLY, DATA
 17 .ctors0228  003fc000  003fc000  001fc000  2**3
  CONTENTS, ALLOC, LOAD, DATA
 18 .dtors0010  003fc228  003fc228  001fc228  2**3
  CONTENTS, ALLOC, LOAD, DATA
 19 .jcr  0008  003fc238  003fc238  001fc238  2**3
  CONTENTS, ALLOC, LOAD, DATA
 20 .data.rel.ro  78c8  003fc240  003fc240  001fc240  2**5
  CONTENTS, ALLOC, LOAD, DATA
 21 .dynamic  01e0  00403b08  00403b08  00203b08  2**3
  CONTENTS, ALLOC, LOAD, DATA
 22 .got  0958  00403ce8  00403ce8  00203ce8  2**3
  CONTENTS, ALLOC, LOAD, DATA
 23 .got.plt  2ab0  00404640  00404640  00204640  2**3
  CONTENTS, ALLOC, LOAD, DATA
 24 .data 0018  004070f0  004070f0  002070f0  2**3
  CONTENTS, ALLOC, LOAD, DATA
 25 .bss  0500  00407120  00407120  00207108  2**5
  ALLOC
 26 .comment  001c      00207108  2**0
  CONTENTS, READONLY


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

Re: Bug#559774: ITP: modem-cmd -- send arbitrary AT commands to your modem

[Bernd Zeimetz]

Robert Millan wrote:
> On Mon, Dec 07, 2009 at 02:14:52AM +, Ben Hutchings wrote:
>> On Mon, 2009-12-07 at 01:43 +0100, Robert Millan wrote:
>>> Package: wnpp
>>> Severity: wishlist
>>> Owner: Robert Millan 
>>>
>>> * Package name: modem-cmd
>>>   Version : 0.0.1
>>>   Upstream Author : me
>>> * URL : none yet, debian-native
>> Why should this be Debian-specific?
> 
> I don't know.  Should it?

No, it should not.
I assume other distributions support modems, too - so its clearly not Debian
specific.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


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

Re: New Menu category Applictions/Multimedia

[Josselin Mouette]

Le mardi 08 décembre 2009 à 08:29 +0800, Paul Wise a écrit : 
> LXDE is a new desktop I guess the maintainers have not yet had time to
> add support for the Debian menu (see #517190 for more). Here is a
> thread about it too:
> 
> http://lists.debian.org/debian-devel/2009/02/thrd2.html#00809

Since LXDE uses the freedesktop.org standard, adding support for the
Debian menu should be trivial with menu-xdg.

Whether this is useful, however, is left as an exercise for the reader.

-- 
 .''`.  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: Bug#559761: ITP: release -- provides information about the current releases

[Jon Dowland]

On Mon, Dec 07, 2009 at 09:03:07AM +0100, Frank Lin PIAT wrote:
> See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the
> information for bo/rex/buzz. Anyone ?

 has
the information and a citation for buzz but not rex or bo.
Actually the citation isn't appropriate for buzz's support
either.


-- 
Jon Dowland


signature.asc
Description: Digital signature

Re: New Menu category Applictions/Multimedia

[Andreas Marschke]

> Personally I think we should have gotten rid of the Debian menu years
> ago, I don't think my opinion is shared by many people in Debian
> though.
> 

It is truely kind of doubled effort to have the debian menu extra to the actual 
menu. The question is who will step forward and propose the removal?

We can make a new thread for this.


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

Re: Bug#559802: CVE-2009-3736 local privilege escalation

[Michael Gilbert]

On Tue, 8 Dec 2009 03:13:06 +1100, Steffen Joeris wrote:
> > > > The following CVE (Common Vulnerabilities & Exposures) id was
> > > > published for libtool.  I have determined that this package embeds a
> > > > vulnerable copy of the libtool source code.  However, since this is a
> > > > mass bug filing (due to so many packages embedding libtool), I have not
> > > > had time to determine whether the vulnerable code is actually present
> > > > in any of the binary packages. Please determine whether this is the
> > > > case. If the package is not affected, please feel free to close the bug
> > > > with a message containing the details of what you did to check.
> > > >
> > > > CVE-2009-3736[0]:
> > > > | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b,
> > > > | attempts to open a .la file in the current working directory, which
> > > > | allows local users to gain privileges via a Trojan horse file.
> > > >
> > > > Note that this problem also affects etch and lenny, so if your package
> > > > is affected, please coordinate with the security team to release the
> > > > DSA for the affected packages.
>
> Is this different to all these python modules that include the working 
> directory? When I had a quick look it smelled like these once, in which case 
> none of the packages probably deserves a DSA and they can all be fixed 
> through 
> s-p-u/o-s-p-u (and can be urgency 'slow'), but I thought I'd ask first in 
> case 
> I misunderstood the issue.

So, as i interpret the issue, the difference here is that libtool will
load any and all .la and .a file available on the LD_LOAD_LIBRARY path;
whereas python will load modules in the current directory only if they
are specifically called from the script. 

I have just recently realized that LD_LOAD_LIBRARY has a relatively
safe default that does not include the current working directory.
Given this fact, I believe that the impact is rather limited (only
users that have modified that LD_LOAD_LIBRARY path are affected; and
i'm sure there are those who have done this, but it is a minor subset
of all debian users).

Hence, I think that for any package embedding libtool, updates should
be pushed in stable-proposed-updates, rather than DSAs.  As for libtool
itself, it may still make sense to issue a DSA.

If there is concurrence on this assessment, I will send a message along
these lines to all of the bugs that I submitted.

Mike


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

Bug#560043: ITP: libnfo -- an NFO file parser/writer library

[Davide Cavalca]

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

--- Please fill out the fields below. ---

   Package name: libnfo
Version: 1.0.0
Upstream Author: Benjamin Zores 
URL: http://libnfo.geexbox.org
License: LGPL v2 or later
Description: an NFO file parser/writer library

libNFO is a small library to parse and write NFO files. NFO files are used 
to store metadata information on many multimedia files.

The NFO format is used by both Enna and XBMC Media Center. See
http://xbmc.org/wiki/?title=Import_-_Export_Library
for a format definition.



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

Re: New Menu category Applictions/Multimedia

[Darren Salt]

I demand that Andreas Marschke may or may not have written...

>> Personally I think we should have gotten rid of the Debian menu years
>> ago, I don't think my opinion is shared by many people in Debian though. 

> It is truly kind of doubled effort to have the debian menu extra to the
> actual menu. The question is who will step forward and propose the removal?

Not me, given that I use, and plan to continue using, it...

-- 
| Darren Salt| linux at youmustbejoking | nr. Ashington, | Doon
| using Debian GNU/Linux | or ds,demon,co,uk| Northumberland | Army
| + http://wiki.debian.org/DebianEeePC/

The good news: Micro$oft to be broken up. The bad news: into only two pieces.


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

Re: Check if library has debug symbols

[Michael Banck]

On Tue, Dec 08, 2009 at 11:35:17AM +0100, Mathieu Malaterre wrote:
> Hi there,
> 
>   I am trying to compile tulip (*) for debugging with:
> 
> $ export DEB_BUILD_OPTIONS='noopt debug nostrip'
> $ apt-get source tulip
> $ cd tulip-3.1.2
> $ dpkg-buildpackage
> 
> After installation, here is what objdump reveals (**). Does this means:
> 1. I did not export DEB_BUILD_OPTIONS ?
> 2. There is an issue in debian/rule for tulip that does not properly
> generate debug symbols ?

DEB_BUILD_OPTIONS=nostrip etc. is an optional feature as far as I know,
it is not guaranteed to work.  You need to inspect debian/rules and
possibly modify it yourself if there is no support for it currently.


Michael


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

Bug#560047: ITP: libvalhalla -- a tiny media scanner library

[Davide Cavalca]

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

--- Please fill out the fields below. ---

   Package name: libvalhalla
Version: 1.0.0
Upstream Author: Mathieu Schroeter, Benjamin Zores
URL: http://libvalhalla.geexbox.org
License: LGPL v2.1 or later
Description: a tiny media scanner library

libvalhalla is a scanner and parser library for audio/video files based
on SQLite and FFmpeg/libavformat.

Media files are retrieved in paths defined by the user and metadata are
saved in a database. It provides a very simple API and it can use
several parsers concurrently to speed up on a multi-core/cpu system.



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

Re: Bug#559802: CVE-2009-3736 local privilege escalation

[Steffen Joeris]

On Tue, 8 Dec 2009 04:23:41 pm Michael Gilbert wrote:
> On Tue, 8 Dec 2009 03:13:06 +1100, Steffen Joeris wrote:
> > > > > The following CVE (Common Vulnerabilities & Exposures) id was
> > > > > published for libtool.  I have determined that this package embeds
> > > > > a vulnerable copy of the libtool source code.  However, since this
> > > > > is a mass bug filing (due to so many packages embedding libtool), I
> > > > > have not had time to determine whether the vulnerable code is
> > > > > actually present in any of the binary packages. Please determine
> > > > > whether this is the case. If the package is not affected, please
> > > > > feel free to close the bug with a message containing the details of
> > > > > what you did to check.
> > > > >
> > > > > CVE-2009-3736[0]:
> > > > > | ltdl.c in libltdl in GNU Libtool 1.5.x, and 2.2.6 before 2.2.6b,
> > > > > | attempts to open a .la file in the current working directory,
> > > > > | which allows local users to gain privileges via a Trojan horse
> > > > > | file.
> > > > >
> > > > > Note that this problem also affects etch and lenny, so if your
> > > > > package is affected, please coordinate with the security team to
> > > > > release the DSA for the affected packages.
> >
> > Is this different to all these python modules that include the working
> > directory? When I had a quick look it smelled like these once, in which
> > case none of the packages probably deserves a DSA and they can all be
> > fixed through s-p-u/o-s-p-u (and can be urgency 'slow'), but I thought
> > I'd ask first in case I misunderstood the issue.
> 
> So, as i interpret the issue, the difference here is that libtool will
> load any and all .la and .a file available on the LD_LOAD_LIBRARY path;
> whereas python will load modules in the current directory only if they
> are specifically called from the script.
> 
> I have just recently realized that LD_LOAD_LIBRARY has a relatively
> safe default that does not include the current working directory.
> Given this fact, I believe that the impact is rather limited (only
> users that have modified that LD_LOAD_LIBRARY path are affected; and
> i'm sure there are those who have done this, but it is a minor subset
> of all debian users).
> 
> Hence, I think that for any package embedding libtool, updates should
> be pushed in stable-proposed-updates, rather than DSAs.  As for libtool
> itself, it may still make sense to issue a DSA.
> 
> If there is concurrence on this assessment, I will send a message along
> these lines to all of the bugs that I submitted.
Please do so, if the packages have an embedded code copy and do not link 
against libtool.

Cheers
Steffen


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

Bug#560048: ITP: libplayer -- a multimedia A/V abstraction layer API

[Davide Cavalca]

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

--- Please fill out the fields below. ---

   Package name: libplayer
Version: 1.0.0
Upstream Author: Benjamin Zores, Mathieu Schroeter
URL: http://libplayer.geexbox.org
License: LGPL v2.1 or later
Description: a multimedia A/V abstraction layer API

libplayer is a multimedia A/V abstraction layer API.
.
libplayer provides a generic A/V API that relies on various multimedia
player for Linux systems. It currently supports MPlayer and xine. Its
main goal is to provide an unique API that player frontends can use to
control any kind of multimedia player underneath.



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

Can quilt delete files?

[Thomas Koch]

Hi,

I'm triing to package a little java library, which contains its own .jar and 
some pregenerated docs. These files should be regenerated on build time. So 
I'd like to have them removed by diff.gz
Trying to generate an appropriate quilt patch failed. The only thing I came up 
with, was a patch that contains the whole content of the removed files with - 
before every line.
Anybody more clever then me?

I know that dpatch allows the execution of shell scripts. This would be ideal. 
I'd just do find . -name "*.jar" -exec rm {} \;

But also a patch which contains just the names of the files to be removed and 
not the whole content would suffice.

Thanks,

Thomas Koch, http://www.koch.ro


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

Re: Can quilt delete files?

[Benjamin Drung]

Am Dienstag, den 08.12.2009, 16:56 +0100 schrieb Thomas Koch:
> Hi,
> 
> I'm triing to package a little java library, which contains its own .jar and 
> some pregenerated docs. These files should be regenerated on build time. So 
> I'd like to have them removed by diff.gz
> Trying to generate an appropriate quilt patch failed. The only thing I came 
> up 
> with, was a patch that contains the whole content of the removed files with - 
> before every line.
> Anybody more clever then me?
> 
> I know that dpatch allows the execution of shell scripts. This would be 
> ideal. 
> I'd just do find . -name "*.jar" -exec rm {} \;
> 
> But also a patch which contains just the names of the files to be removed and 
> not the whole content would suffice.

Putting 'find . -name "*.jar" -delete' in you clean rule should do the
same job for you.

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: Can quilt delete files?

[Mehdi Dogguy]

Thomas Koch wrote:
> Hi,
> 
> I'm triing to package a little java library, which contains its own .jar and 
> some pregenerated docs. These files should be regenerated on build time. So 
> I'd like to have them removed by diff.gz
> Trying to generate an appropriate quilt patch failed. The only thing I came 
> up 
> with, was a patch that contains the whole content of the removed files with - 
> before every line.
> Anybody more clever then me?
> 

What about repackaging?

(I assume you are subscribed to the list)

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


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

Re: Can quilt delete files?

[Mehdi Dogguy]

Benjamin Drung wrote:
> 
> Putting 'find . -name "*.jar" -delete' in you clean rule should do the
> same job for you.
> 

The *.jar files should not be present in the tarball.

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


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

Re: Can quilt delete files?

[Daniel Leidert]

Am Dienstag, den 08.12.2009, 17:31 +0100 schrieb Mehdi Dogguy:
> Thomas Koch wrote:
> > Hi,
> > 
> > I'm triing to package a little java library, which contains its own .jar 
> > and 
> > some pregenerated docs. These files should be regenerated on build time. So 
> > I'd like to have them removed by diff.gz
> > Trying to generate an appropriate quilt patch failed. The only thing I came 
> > up 
> > with, was a patch that contains the whole content of the removed files with 
> > - 
> > before every line.
> > Anybody more clever then me?
> > 
> 
> What about repackaging?

Alternatively:

build:
find . -name "*.jar" -exec rename 's/$/.orig/' "{}" ";"

clean:
find . -name "*.jar.orig" -exec rename 's/\.orig$//' "{}" ";"

IMO this is ok as long as these jars can be rebuilt during build.

Regards, Daniel


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

Re: Can quilt delete files?

[Thomas Koch]

> Benjamin Drung wrote:
> > Putting 'find . -name "*.jar" -delete' in you clean rule should do the
> > same job for you.
> 
> The *.jar files should not be present in the tarball.

As long as the jar file is the one created by the sourcecode in the tarball, I 
don't see a reason, that it needs to be removed and thus the upstream tarball 
repackaged.
If the upstream tarball contains dependency jars (as mostly) then we need to 
repackage.

Putting the deletion in the clean target could be an option, but I really hate 
to modify my source tree that much while packaging.

So no way to do it with quilt?

Thomas Koch, http://www.koch.ro


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

Re: Can quilt delete files?

[Matthew Johnson]

On Tue Dec 08 17:42, Thomas Koch wrote:
> As long as the jar file is the one created by the sourcecode in the tarball, 
> I 
> don't see a reason, that it needs to be removed and thus the upstream tarball 
> repackaged.

No, but it is an option still.

> Putting the deletion in the clean target could be an option, but I really 
> hate 
> to modify my source tree that much while packaging.

Why do you think there's a difference between this and at patch time.

> So no way to do it with quilt?

There's definitely no way to do it with quilt.

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Can quilt delete files?

[Matthew Johnson]

On Tue Dec 08 16:56, Thomas Koch wrote:
> Trying to generate an appropriate quilt patch failed. The only thing I came 
> up 
> with, was a patch that contains the whole content of the removed files with - 
> before every line.
> Anybody more clever then me?

No, you can't do it like that. Generally the source package is repacked
to remove these first and that tarball is uploaded as the orig.tar.gz.
Many Java packages need to be repacked from .zip anyway, so that's not a
big deal. If you do this is customary to append a '.ds' or similar
suffix to the upstream version.

> I know that dpatch allows the execution of shell scripts. This would be 
> ideal. 
> I'd just do find . -name "*.jar" -exec rm {} \;

You could do this, although if you are going down this route, just doing
it in the clean: target is probably sufficient. In any case they are
still shipped in the upstream tarball and dpkg-source ignores missing
files when creating the diff.gz

Matt

-- 
Matthew Johnson


signature.asc
Description: Digital signature

Re: Can quilt delete files?

[Mehdi Dogguy]

Thomas Koch wrote:
> 
> As long as the jar file is the one created by the sourcecode in the tarball, 
> I 
> don't see a reason, that it needs to be removed and thus the upstream tarball 
> repackaged.

Right. I missed that from your initial post.

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


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

Re: Check if library has debug symbols

[Andreas Metzler]

Michael Banck  wrote:
> On Tue, Dec 08, 2009 at 11:35:17AM +0100, Mathieu Malaterre wrote:
>>   I am trying to compile tulip (*) for debugging with:

>> $ export DEB_BUILD_OPTIONS='noopt debug nostrip'
>> $ apt-get source tulip
>> $ cd tulip-3.1.2
>> $ dpkg-buildpackage

>> After installation, here is what objdump reveals (**).

Comparing the package size to the official package and using file(1)
is a simple way to check.

> Does this means:
>> 1. I did not export DEB_BUILD_OPTIONS ?
>> 2. There is an issue in debian/rule for tulip that does not properly
>> generate debug symbols ?

> DEB_BUILD_OPTIONS=nostrip etc. is an optional feature as far as I know,
> it is not guaranteed to work.  You need to inspect debian/rules and
> possibly modify it yourself if there is no support for it currently.

Hello,

that is not *completely* true nowadays. dpkg-buildpackage seems to
evaluate DEB_BUILD_OPTIONS and sets CFLAGS to '-g -O0' instead of '-g
-O2' if noopt is specified. Also dh_strip checks respects nostrip.

Therefore DEB_BUILD_OPTIONS='noopt nostrip' often has a good chance of
working, unless debian/rules overwites CFLAGS.  (I have never heard
about DEB_BUILD_OPTIONS=debug and it is not listed in policy.)

In tulip's case afaict the mechanism I described should work, I just
got a FTBFS due to 527215 in combination with switching to gcc-4.4.
cu andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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

Re: Check if library has debug symbols

[Cyril Brulebois]

Michael Banck  (08/12/2009):
> DEB_BUILD_OPTIONS=nostrip etc. is an optional feature as far as I
> know, it is not guaranteed to work.  You need to inspect
> debian/rules and possibly modify it yourself if there is no support
> for it currently.

FWIW: dh_strip DTRT when DEB_BUILD_OPTIONS contains nostrip (see its
manpage). One usually has to inspect both:
 - debian/rules to see whether configure/make flags are triggering a
   “normal” or a “debug” build (see cmake's Release, RelWithDebInfo,
Debug types for CMAKE_BUILD_TYPE, for example).
 - upstream build system. Some are doing stripping unconditionally, so
   you'd have to apply a patch to either get rid of stripping, or to
   make it conditional.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Can quilt delete files?

[Damien Raude-Morvan]

On Tue, 8 Dec 2009 16:56:05 +0100, Thomas Koch  wrote:
> Hi,

Hi Thomas,

> I'm triing to package a little java library, which contains its own .jar
> and some pregenerated docs. These files should be regenerated on build
time.
> So I'd like to have them removed by diff.gz

As a general guideline, generated files should be stripped from "original"
source tarballs.
If you choose to keep them in orig.tar.{gz,bz2}, it's complicated for
others people (FTP Masters, reviewers, ...)
to ensure there is not binary blob or non-free stuff inside your package.

Cheers,
-- 
Damien - Debian Developper
http://wiki.debian.org/DamienRaudeMorvan


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

Re: New Menu category Applictions/Multimedia

[Manoj Srivastava]

On Tue, Dec 08 2009, Andreas Marschke wrote:

>> Personally I think we should have gotten rid of the Debian menu years
>> ago, I don't think my opinion is shared by many people in Debian
>> though.
>> 
>
> It is truely kind of doubled effort to have the debian menu extra to
> the actual menu. The question is who will step forward and propose the
> removal?

Whoever does the work to implement the replacement menu
 infrastructure in all the places that the Debian menu is
 implemented. And also helps flush out all the entries missing from the
 xdg menu which are in the Debian one.

> We can make a new thread for this.

manoj
-- 
There are new messages.
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

Retiring from Debian

[Kevin B. McCarty]

Hi all,

I am retiring from Debian due to a probably-permanent lack of time for
Debian work.  While having a new baby last month certainly didn't help
with this, it did force me to admit it to myself ;-)

My official packages are all orphaned as per Developers Ref. 3.7 &
5.9.4.  Regarding unofficial packages or my people.debian.org/~kmccarty/
web pages, anyone who wants to take them over, please contact Axel
Naumann  for Geant4, or me for anything else.

After my Debian email forwarding expires I will be reachable at
kmcca...@gmail.com .

With best wishes to the project,

-- 
Kevin B. McCarty 
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751



signature.asc
Description: OpenPGP digital signature

Bug#560088: ITP: python-portio -- low level port I/O for Linux

[Dmitrijs Ledkovs]

Package: wnpp
Severity: wishlist
Owner: Dmitrijs Ledkovs 

* Package name: python-portio
  Version : 0.4
  Upstream Author : Fabrizio Pollastri 
* URL : http://portio.inrim.it/
* License : GPL-3+
  Programming Lang: Python, C
  Description : low level port I/O for Linux

Wrapper for the port I/O macros like outb, inb and other provided by the C
library on Linux x86 platforms.



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

Key signing

[Nicolas]

Hi all,

I search for a Debian Member to sign my gpg key.
I work in Paris. I live in Seine-et-Marne (77).

Thanks in advance.

Nicolas

Re: New Menu category Applictions/Multimedia

[Russ Allbery]

Manoj Srivastava  writes:

> Whoever does the work to implement the replacement menu
>  infrastructure in all the places that the Debian menu is
>  implemented. And also helps flush out all the entries missing from the
>  xdg menu which are in the Debian one.

I think this would be excellent work for someone to do, to mention.  But
it is a fair amount of work, since it probably (at least in the short run)
requires writing a converter that writes Debian menu files based on XDG
desktop files for those packages that implement the Debian menu (such as
fvwm).  Either that, or teaching those packages how to read desktop files,
but I suspect generating menu files would be easier.

-- 
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: Key signing

[Patrick Matthäi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nicolas schrieb:
> Hi all,
> 
> I search for a Debian Member to sign my gpg key.
> I work in Paris. I live in Seine-et-Marne (77).
> 
> Thanks in advance.
> 
> Nicolas

Have you already looked here [0]?


[0]: https://nm.debian.org/gpg_offer.php

- --
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

E-Mail: pmatth...@debian.org
patr...@linux-dev.org

Comment:
Always if we think we are right,
we were maybe wrong.
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAksevnAACgkQ2XA5inpabMfF7ACeJxhqpCpci7V4uOAmiieHFx9H
wiAAn3DS4f3TYd6NCMGEejm+54I2oMrP
=NrYy
-END PGP SIGNATURE-


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

Re: Key signing

[Mehdi Dogguy]

Nicolas wrote:
> Hi all,
> 
> I search for a Debian Member to sign my gpg key.
> I work in Paris. I live in Seine-et-Marne (77).
> 

See https://nm.debian.org/gpg_offer.php#FR

-- 
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/


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

Re: Key signing

[Simon Paillard]

Hi,

On Tue, Dec 08, 2009 at 09:57:56PM +0100, Nicolas wrote:
> I search for a Debian Member to sign my gpg key.
> I work in Paris. I live in Seine-et-Marne (77).
(France)

You should have a look at https://nm.debian.org/gpg_offer.php

http://lists.debian.org/debian-devel-french/ and #debian-devel-fr might
help as well.

-- 
Simon Paillard


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

Re: Key signing

[Nicolas]

Thanks.
I have a look at that list but I think strange to "spam" people for
requiring a signing key. No ? Is it the right process ?

Nicolas

2009/12/8 Simon Paillard 

> Hi,
>
> On Tue, Dec 08, 2009 at 09:57:56PM +0100, Nicolas wrote:
> > I search for a Debian Member to sign my gpg key.
> > I work in Paris. I live in Seine-et-Marne (77).
> (France)
>
> You should have a look at https://nm.debian.org/gpg_offer.php
>
> http://lists.debian.org/debian-devel-french/ and #debian-devel-fr might
> help as well.
>
> --
> Simon Paillard
>

Re: Key signing

[Cyril Brulebois]

Nicolas  (08/12/2009):
> I have a look at that list but I think strange to "spam" people for
> requiring a signing key.

You're currently spamming -devel.

> No ? Is it the right process ?

People volunteered those bits of information. Guess why.

Mraw,
KiBi.


signature.asc
Description: Digital signature

O: libmtp8 -- Media Transfer Protocol (MTP) library

[Savvas Radevic]

Package: libmtp8
Severity: normal

http://packages.qa.debian.org/libm/libmtp.html

Due to my real life problems and my limited free time, I want to set
the libmtp package as orphan. I don't know if I have done it right, I
followed the instructions at: http://www.debian.org/devel/wnpp/

The package maintainer has already retired from maintaining libmtp and
frankly I believe that this package is too important to rely on my
newbie packaging skills. :)

Can someone please set the package as orphan? I really don't know how
to do that, since I don't have internet at home.

Notes:
1. There is a new version of libmtp:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543533
2. There is unfinished packaging due to dangling symlinks. The whole
story is written in debian/README.Source:
http://git.debian.org/?p=collab-maint/libmtp.git;a=blob_plain;f=debian/README.Source


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

O: libmtp8 -- Media Transfer Protocol (MTP) library

[Savvas Radevic]

Package: libmtp8
Severity: normal

Due to my real life problems and my limited free time, I want to set
the libmtp package as orphan. I don't know if I have done it right, I
followed the instructions at: http://www.debian.org/devel/wnpp/

The package maintainer has already retired from maintaining libmtp and
frankly I believe that this package is too important to rely on my
newbie packaging skills. :)

Notes:
1. There is a new version of libmtp:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543533
2. There is unfinished packaging due to dangling symlinks. The whole
story is written in debian/README.Source:
http://git.debian.org/?p=collab-maint/libmtp.git;a=blob_plain;f=debian/README.Source


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

Bug#560102: ITP: libattica -- a Qt library that implements the Open Collaboration Services API

[Thibaut GRIDEL]

Package: wnpp
Severity: wishlist
Owner: Thibaut Gridel 

* Package name: libattica
  Version : 0.1.1
  Upstream Author : Eckhart Wörner , Frederik Gladhorn 
, Cornelius Schumacher 
* URL : ftp://ftp.kde.org/pub/kde/stable/attica
* License : LGPL2
  Programming Lang: C++
  Description : a Qt library that implements the Open Collaboration 
Services API

Attica is a Qt library that implements the Open Collaboration Services
API version 1.4.
The REST API is defined here:
 http://www.freedesktop.org/wiki/Specifications/open-collaboration-services

It grants easy access to the services such as querying information about
persons and contents.





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

Re: Bug#560088: ITP: python-portio -- low level port I/O for Linux

[brian m. carlson]

On Tue, Dec 08, 2009 at 08:23:15PM +, Dmitrijs Ledkovs wrote:
> * Package name: python-portio
>   Version : 0.4
>   Upstream Author : Fabrizio Pollastri 
> * URL : http://portio.inrim.it/
> * License : GPL-3+
>   Programming Lang: Python, C
>   Description : low level port I/O for Linux
> 
> Wrapper for the port I/O macros like outb, inb and other provided by the C
> library on Linux x86 platforms.

Honestly, this doesn't sound like something that should be encouraged.
inb and outb are the source of much incompatibility between
architectures, and any package depending on this one will be (likely
permanently) stuck to i386.

Is there something that you want to package that depends on this?

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Bug#560088: ITP: python-portio -- low level port I/O for Linux

[Ben Hutchings]

On Tue, 2009-12-08 at 22:37 +, brian m. carlson wrote:
> On Tue, Dec 08, 2009 at 08:23:15PM +, Dmitrijs Ledkovs wrote:
> > * Package name: python-portio
> >   Version : 0.4
> >   Upstream Author : Fabrizio Pollastri 
> > * URL : http://portio.inrim.it/
> > * License : GPL-3+
> >   Programming Lang: Python, C
> >   Description : low level port I/O for Linux
> > 
> > Wrapper for the port I/O macros like outb, inb and other provided by the C
> > library on Linux x86 platforms.
> 
> Honestly, this doesn't sound like something that should be encouraged.
> inb and outb are the source of much incompatibility between
> architectures, and any package depending on this one will be (likely
> permanently) stuck to i386.

They're not really the source of much incompatibility, because people
rarely try to use them!

I have written a module like this myself for testing some new hardware.
On top of the low-level I/O, I defined classes for PCI devices and
register sets, and then wrote test cases using them.  It was a lot
easier to write those test cases in Python than it would have been in C.

> Is there something that you want to package that depends on this?

I do hope not; this should never be used in production.  But it may yet
be useful in hardware development.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky


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

Re: Bug#560088: ITP: python-portio -- low level port I/O for Linux

[Dmitrijs Ledkovs]

2009/12/8 Ben Hutchings :
> I do hope not; this should never be used in production.  But it may yet
> be useful in hardware development.
>
> Ben.
>

I'm working on a parallel LCD interface with my custom PCB and I
wanted interactive way to use parallel port. Found this decided to
package it for myself and anyone else.

Should my packaging be changed to i386 & amd64 only?

-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


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

Re: Bug#559761: ITP: release -- provides information about the current releases

[Benjamin Drung]

Am Montag, den 07.12.2009, 09:03 +0100 schrieb Frank Lin PIAT:
> On Mon, 2009-12-07 at 00:14 +0100, Benjamin Drung wrote:
> > 
> > * Package name: release
> 
> The tool isn't about releasing, but about to querying the release. Also,
> it's about distribution release (not package...). May be a name like
> {get|query}-distr[o]?-release... or something completely different like
> "supported-distro" would be more explicit.

Yes, the name is a bit to generic. Any other suggestions for the name?
On the mailing list I found 'release-info'. On my list are now:

* release-info
* distro-release-info
* distro-releases

Any preferred name or suggestions?

Should i rename the scripts, too?

> >   Description : provides information about the current releases
> > 
> >  This package contains information about all releases of Debian and Ubuntu. 
> > The
> >  release script will give you the codename for e.g. the latest stable 
> > release of
> >  your distribution.
> 
> There was some discussions about a similar tool & issues:
>  http://lists.debian.org/debian-devel/2007/05/msg01138.html
> and to query Debian point release.
>  http://lists.debian.org/debian-devel/2007/12/msg00742.html

The topic of these discussions were slightly different. The release
packages does not know anything about the running release. It only needs
a date (and up-to-date data) for calculating the result.

> >  To get information about a specific distribution there are
> >  the debian-release and the ubuntu-release scripts.
> 
> I suppose you mean that there will be different back-end script.
> (I suppose that you don't mean that each program will have to implement
> a select/case algorithm?)

Yes, there are different back-end scripts. Due to different release
models the both scripts use different algorithms. The distro data are
stored in cvs files (like a table) and then I throw a little bit of
Python on it. Subtracting the command line parsing only 60 lines of code
are required.

> > It's based on the idea posted on the ubuntu-devel-discuss mailing list
> > [1]. Comments, suggestions and feature requests are highly welcome.
> > 
> > For Debian I need some informations: Until when were following
> > releases supported: buzz, rex, bo, hamm, slink, and potato?
> 
> See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the
> information for bo/rex/buzz. Anyone ?

I found that page, too. The wikipedia page of Debian did not contain
more information.

> AFAIK, Debian have never supported more than two stable distributions
> (stable + old-stable), therefore, you can assume that a distribution end
> of life is "lower than" distribution N+2 release.

I used this algorithm to calculate the support dates until we find
something more precise.

-- 
Benjamin Drung
Ubuntu Developer (www.ubuntu.com) | Debian Maintainer (www.debian.org)


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Re: New Menu category Applictions/Multimedia

[Josselin Mouette]

Le mardi 08 décembre 2009 à 11:30 -0600, Manoj Srivastava a écrit : 
> Whoever does the work to implement the replacement menu
>  infrastructure in all the places that the Debian menu is
>  implemented. And also helps flush out all the entries missing from the
>  xdg menu which are in the Debian one.

Adding all these entries (most of which have nothing to do in a menu) in
the XDG menu also implies proper tagging, which is a huge job if we want
to do it correctly.

There are already several entries which have absolutely nothing to do
here, see #552221 for an example. Given the total lack of cooperation
from some maintainers, the only solution might be to eventually
implement a blacklist to ignore these broken entries.

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: Bug#559761: ITP: release -- provides information about the current releases

[Paul Wise]

On Wed, Dec 9, 2009 at 8:07 AM, Benjamin Drung  wrote:
> Am Montag, den 07.12.2009, 09:03 +0100 schrieb Frank Lin PIAT:
>> On Mon, 2009-12-07 at 00:14 +0100, Benjamin Drung wrote:
>> > For Debian I need some informations: Until when were following
>> > releases supported: buzz, rex, bo, hamm, slink, and potato?
>>
>> See http://wiki.debian.org/DebianReleases but I didn't/couldn't find the
>> information for bo/rex/buzz. Anyone ?
>
> I found that page, too. The wikipedia page of Debian did not contain
> more information.

Try the debian-history package or its maintainer.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: Bug#559761: ITP: release -- provides information about the current releases

[Stefano Zacchiroli]

On Wed, Dec 09, 2009 at 01:07:59AM +0100, Benjamin Drung wrote:
> Yes, the name is a bit to generic. Any other suggestions for the name?
> On the mailing list I found 'release-info'. On my list are now:
> 
> * release-info

That sound appropriate to me.

> Should i rename the scripts, too?

I don't know the current name, but having the scripts more or less in
sync with the package name minimizes user surprises and also reduces the
likelihood of file conflicts with other packages.

My 0.02€,
Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Bug#560088: ITP: python-portio -- low level port I/O for Linux

[Ron Johnson]

On 2009-12-08 17:42, Dmitrijs Ledkovs wrote:

2009/12/8 Ben Hutchings :

I do hope not; this should never be used in production.  But it may yet
be useful in hardware development.

Ben.



I'm working on a parallel LCD interface with my custom PCB and I
wanted interactive way to use parallel port. Found this decided to
package it for myself and anyone else.

Should my packaging be changed to i386 & amd64 only?



If libc provides these functions on every platform, then I'd say, 
"no"!  OTOH, you might want to add to the Long Description a 
disclaimer mentioning possible cross-platform compatibility issues.


--
scientia addo vereor


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

Re: cupt, the APT competitor

[Ron Johnson]

On 2009-09-28 14:28, Free Ekanayaka wrote:

Hi,

|--==> On Tue, 22 Sep 2009 12:52:14 +0300, "Eugene V. Lyubimkin" 
 said:

  EVL> This mail is to inform that Debian APT suite now has a competitor named 
Cupt [1].

For the ones who don't know it, I'd like to point out that there is at
least one other competitor/companion/replacement of APT:

http://labix.org/smart

Smart has been developed since several years now and it is in
Debian. The code base is rather stable and actively maintained, and
beside dpkg it has supports for other packaging backends like rpm and
slack. It has a GUI too.



Besides the GUI, how is this superior to wajig?

--
scientia addo vereor


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