RFS: libplist (Adopted, updated package)

[Julien Lavergne]

Dear mentors,

I am looking for a sponsor for the new version 0.16-1
of package "libplist". It was orphaned and I would like to take over its
maintenance. The ITA bug is
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548594

libplist is the first package of the libiphone stack, providing access
and synchronization with Ipod and Iphone devices.

It builds these binary packages:
libplist++-dev - Library for handling Apple binary and XML property lists
libplist++0 - Library for handling Apple binary and XML property lists
libplist-dbg - Library for handling Apple binary and XML property lists
libplist-dev - Library for handling Apple binary and XML property lists
libplist-utils - Apple property list converter
libplist0  - Library for handling Apple binary and XML property lists
python-plist - Library for handling Apple binary and XML property lists

The package appears to be lintian clean.

The upload would fix these bugs: 530590, 548594

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/l/libplist
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/l/libplist/libplist_0.16-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Julien Lavergne


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Bremner-4]

Julien Lavergne wrote:

>Dear mentors,

>I am looking for a sponsor for the new version 0.16-1
>of package "libplist". It was orphaned and I would like to take over its
>maintenance. The ITA bug is
>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548594

>libplist is the first package of the libiphone stack, providing access
>and synchronization with Ipod and Iphone devices.

>It builds these binary packages:
>libplist++-dev - Library for handling Apple binary and XML property lists
>libplist++0 - Library for handling Apple binary and XML property lists
>libplist-dbg - Library for handling Apple binary and XML property lists
>libplist-dev - Library for handling Apple binary and XML property lists
>libplist-utils - Apple property list converter
>libplist0  - Library for handling Apple binary and XML property lists
>python-plist - Library for handling Apple binary and XML property lists

>The package appears to be lintian clean.

This package fails to build from source for me in a sid pbuilder
chroot.  If I apply the obvious patch (take the output below, and kill
most of -1's) it builds, but I'm not too sure about the MISSING
entries. If symbols really went away then an SONAME bump is in order.

,----
| dh_makeshlibs
| dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below
| dpkg-gensymbols: warning: some symbols disappeared in the symbols file: see diff output below
| dpkg-gensymbols: warning: debian/libplist++0/DEBIAN/symbols doesn't match completely debian/libplist++0.symbols
| --- debian/libplist++0.symbols (libplist++0 i386)
| +++ dpkg-gensymbolsvo1Rfn 2009-11-21 12:45:56.000000000 +0000
| @@ -126,15 +126,18 @@
|   _ZN5PList7BooleanaSERS0_@Base 0.16
|   _ZN5PList7Integer5CloneEv@Base 0.16
|   _ZN5PList7Integer8GetValueEv@Base 0.16
| - _ZN5PList7Integer8SetValueEm@Base 0.16
| +#MISSING: 0.16-1# _ZN5PList7Integer8SetValueEm@Base 0.16
| + _ZN5PList7Integer8SetValueEy@Base 0.16-1
|   _ZN5PList7IntegerC1EPNS_4NodeE@Base 0.16
|   _ZN5PList7IntegerC1EPvPNS_4NodeE@Base 0.16
|   _ZN5PList7IntegerC1ERS0_@Base 0.16
| - _ZN5PList7IntegerC1Em@Base 0.16
| +#MISSING: 0.16-1# _ZN5PList7IntegerC1Em@Base 0.16
| + _ZN5PList7IntegerC1Ey@Base 0.16-1
|   _ZN5PList7IntegerC2EPNS_4NodeE@Base 0.16
|   _ZN5PList7IntegerC2EPvPNS_4NodeE@Base 0.16
|   _ZN5PList7IntegerC2ERS0_@Base 0.16
| - _ZN5PList7IntegerC2Em@Base 0.16
| +#MISSING: 0.16-1# _ZN5PList7IntegerC2Em@Base 0.16
| + _ZN5PList7IntegerC2Ey@Base 0.16-1
|   _ZN5PList7IntegerD0Ev@Base 0.16
|   _ZN5PList7IntegerD1Ev@Base 0.16
|   _ZN5PList7IntegerD2Ev@Base 0.16
| dh_makeshlibs: dpkg-gensymbols -plibplist++0 -Idebian/libplist++0.symbols -Pdebian/libplist++0 returned exit code 1
| make: *** [binary-arch] Error 2
| dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
`----



--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Bremner-4]

Sorry for the bizzare spam-like From on that last message. Experimental mail setup gone wild...

d




--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Julien Lavergne]

Hi,

Yes, strangely, the symbols are different if the package is build on
i386 or on amd64.
I removed the symbols file until I find why there is such behavior. The
actual version on mentors should build fine now.

Regards,
Julien Lavergne

Le samedi 21 novembre 2009 à 09:09 -0400, Julien Lavergne a écrit :

> Julien Lavergne wrote:
>
> >Dear mentors,
>
> >I am looking for a sponsor for the new version 0.16-1
> >of package "libplist". It was orphaned and I would like to take over its
> >maintenance. The ITA bug is
> >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548594
>
> >libplist is the first package of the libiphone stack, providing access
> >and synchronization with Ipod and Iphone devices.
>
> >It builds these binary packages:
> >libplist++-dev - Library for handling Apple binary and XML property lists
> >libplist++0 - Library for handling Apple binary and XML property lists
> >libplist-dbg - Library for handling Apple binary and XML property lists
> >libplist-dev - Library for handling Apple binary and XML property lists
> >libplist-utils - Apple property list converter
> >libplist0  - Library for handling Apple binary and XML property lists
> >python-plist - Library for handling Apple binary and XML property lists
>
> >The package appears to be lintian clean.
>
> This package fails to build from source for me in a sid pbuilder
> chroot.  If I apply the obvious patch (take the output below, and kill
> most of -1's) it builds, but I'm not too sure about the MISSING
> entries. If symbols really went away then an SONAME bump is in order.
>
> ,----
> | dh_makeshlibs
> | dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below
> | dpkg-gensymbols: warning: some symbols disappeared in the symbols file: see diff output below
> | dpkg-gensymbols: warning: debian/libplist++0/DEBIAN/symbols doesn't match completely debian/libplist++0.symbols
> | --- debian/libplist++0.symbols (libplist++0 i386)
> | +++ dpkg-gensymbolsvo1Rfn 2009-11-21 12:45:56.000000000 +0000
> | @@ -126,15 +126,18 @@
> |   _ZN5PList7BooleanaSERS0_@Base 0.16
> |   _ZN5PList7Integer5CloneEv@Base 0.16
> |   _ZN5PList7Integer8GetValueEv@Base 0.16
> | - _ZN5PList7Integer8SetValueEm@Base 0.16
> | +#MISSING: 0.16-1# _ZN5PList7Integer8SetValueEm@Base 0.16
> | + _ZN5PList7Integer8SetValueEy@Base 0.16-1
> |   _ZN5PList7IntegerC1EPNS_4NodeE@Base 0.16
> |   _ZN5PList7IntegerC1EPvPNS_4NodeE@Base 0.16
> |   _ZN5PList7IntegerC1ERS0_@Base 0.16
> | - _ZN5PList7IntegerC1Em@Base 0.16
> | +#MISSING: 0.16-1# _ZN5PList7IntegerC1Em@Base 0.16
> | + _ZN5PList7IntegerC1Ey@Base 0.16-1
> |   _ZN5PList7IntegerC2EPNS_4NodeE@Base 0.16
> |   _ZN5PList7IntegerC2EPvPNS_4NodeE@Base 0.16
> |   _ZN5PList7IntegerC2ERS0_@Base 0.16
> | - _ZN5PList7IntegerC2Em@Base 0.16
> | +#MISSING: 0.16-1# _ZN5PList7IntegerC2Em@Base 0.16
> | + _ZN5PList7IntegerC2Ey@Base 0.16-1
> |   _ZN5PList7IntegerD0Ev@Base 0.16
> |   _ZN5PList7IntegerD1Ev@Base 0.16
> |   _ZN5PList7IntegerD2Ev@Base 0.16
> | dh_makeshlibs: dpkg-gensymbols -plibplist++0 -Idebian/libplist++0.symbols -Pdebian/libplist++0 returned exit code 1
> | make: *** [binary-arch] Error 2
> | dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
> `----
>
>

--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[bradsmith-2]

On Wed, 25 Nov 2009 18:10:59 +0100
Julien Lavergne <julien.lavergne@...> wrote:

> Hi,
>
> Yes, strangely, the symbols are different if the package is build on
> i386 or on amd64.
> I removed the symbols file until I find why there is such behavior. The
> actual version on mentors should build fine now.

C++ symbols always differ between arches. You either need specific symbols
for every arch, or you will need to drop them altogether.

Regards,
Bradley Smith


--
Bradley Smith                                     brad@...
Debian GNU/Linux Developer                         bradsmith@...
GPG: 0xC718D347       D201 7274 2FE1 A92A C45C EFAB 8F70 629A C718 D347

[gege2061]

Hello,

I would like improve the debian package of Val(a)IDE
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547665).

I have already fixed lintian errors and several warnings in the
development version, but some warning persist:

W: valide-common: image-file-in-usr-lib
usr/lib/valide/plugins/file-browser/file-browser.png
W: valide-common: image-file-in-usr-lib
usr/lib/valide/plugins/opened-documents/opened-documents.png
W: valide-common: image-file-in-usr-lib
usr/lib/valide/plugins/symbol/symbol-browser.png
W: valide-common: extra-license-file usr/share/valide/COPYING
W: valide: non-dev-pkg-with-shlib-symlink usr/lib/libvalide-0.0.so.0.7.0
usr/lib/libvalide-0.0.so
W: valide: package-name-doesnt-match-sonames libvalide-0.0-0

Are these warnings are blocking?

--
Nicolas Joseph

http://www.valaide.org


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Wise-3]

On Thu, Nov 26, 2009 at 2:39 AM, Nicolas Joseph
<gege2061@...> wrote:

> W: valide-common: image-file-in-usr-lib
> usr/lib/valide/plugins/file-browser/file-browser.png
> W: valide-common: image-file-in-usr-lib
> usr/lib/valide/plugins/opened-documents/opened-documents.png
> W: valide-common: image-file-in-usr-lib
> usr/lib/valide/plugins/symbol/symbol-browser.png

These should be installed to /usr/share instead. You might need to
patch the source to install them in the right place. See here for why:

http://lintian.debian.org/tags/image-file-in-usr-lib.html

> W: valide-common: extra-license-file usr/share/valide/COPYING

Unless the application needs it, there is no reason to install this file.

http://lintian.debian.org/tags/extra-license-file.html

> W: valide: non-dev-pkg-with-shlib-symlink usr/lib/libvalide-0.0.so.0.7.0
> usr/lib/libvalide-0.0.so
> W: valide: package-name-doesnt-match-sonames libvalide-0.0-0

I imagine these are not meant to be public libraries. If they are
supposed to be private, please work with upstream to make them private
libraries (install in a subdir of /usr/lib). If they are meant to be
public libraries, you need to read libpkg-guide and the bugs filed
against it.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[gege2061]

Thank's for your answer!

I'm the upstream, and I think I understood the litian warnings but not
their consequenses.

>> W: valide-common: image-file-in-usr-lib
>> usr/lib/valide/plugins/file-browser/file-browser.png
>> W: valide-common: image-file-in-usr-lib
>> usr/lib/valide/plugins/opened-documents/opened-documents.png
>> W: valide-common: image-file-in-usr-lib
>> usr/lib/valide/plugins/symbol/symbol-browser.png
>
> These should be installed to /usr/share instead. You might need to
> patch the source to install them in the right place. See here for why:
>
> http://lintian.debian.org/tags/image-file-in-usr-lib.html
>

If it's a critical warning, I can fix it, but I prefer to have all files
in the same directory.

>> W: valide-common: extra-license-file usr/share/valide/COPYING
>
> Unless the application needs it, there is no reason to install this
file.
>
> http://lintian.debian.org/tags/extra-license-file.html
>

Yes the application use the COPYING file for show the license in the about
dialog.

>> W: valide: non-dev-pkg-with-shlib-symlink
usr/lib/libvalide-0.0.so.0.7.0
>> usr/lib/libvalide-0.0.so
>> W: valide: package-name-doesnt-match-sonames libvalide-0.0-0
>
> I imagine these are not meant to be public libraries. If they are
> supposed to be private, please work with upstream to make them private
> libraries (install in a subdir of /usr/lib). If they are meant to be
> public libraries, you need to read libpkg-guide and the bugs filed
> against it.
>

This library is used by the core application, if it's not placed in
/usr/lib I have the classic error:

  valide: error while loading shared libraries: libvalide-0.0.so.0: cannot
open shared object file: No such file or directory

I think that the library is in the good directory (like Anjuta). Is it
reasonable to have six packages for this simple application?

--
Nicolas Joseph

http://www.valaide.org


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Julien Lavergne]

Le mercredi 25 novembre 2009 à 18:03 +0000, Bradley Smith a écrit :

> On Wed, 25 Nov 2009 18:10:59 +0100
> Julien Lavergne <julien.lavergne@...> wrote:
>
> > Hi,
> >
> > Yes, strangely, the symbols are different if the package is build on
> > i386 or on amd64.
> > I removed the symbols file until I find why there is such behavior. The
> > actual version on mentors should build fine now.
>
> C++ symbols always differ between arches. You either need specific symbols
> for every arch, or you will need to drop them altogether.

Ok, thanks for the precision.
I'll try to add at least my arch to follow symbols evolution.

Regards,
Julien



--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Paul Wise-3]

On Thu, Nov 26, 2009 at 5:47 AM, Nicolas Joseph
<gege2061@...> wrote:

>> These should be installed to /usr/share instead. You might need to
>> patch the source to install them in the right place. See here for why:
>>
>> http://lintian.debian.org/tags/image-file-in-usr-lib.html
>
> If it's a critical warning, I can fix it, but I prefer to have all files
> in the same directory.

Debian prefers FHS compliance

>>> W: valide-common: extra-license-file usr/share/valide/COPYING
>>
>> Unless the application needs it, there is no reason to install this
> file.
>>
>> http://lintian.debian.org/tags/extra-license-file.html
>>
>
> Yes the application use the COPYING file for show the license in the about
> dialog.

In that case it is appropriate to override the lintian warning. If it
is the same as a license in /usr/share/common-licenses then you might
just want to configure the software to display that instead.
Alternatively, I think many apps just show the license grant ("This
program is free software....") in the about dialog and leave the
license terms for the user to find if they want to.

>>> W: valide: non-dev-pkg-with-shlib-symlink
> usr/lib/libvalide-0.0.so.0.7.0
>>> usr/lib/libvalide-0.0.so
>>> W: valide: package-name-doesnt-match-sonames libvalide-0.0-0
>>
>> I imagine these are not meant to be public libraries. If they are
>> supposed to be private, please work with upstream to make them private
>> libraries (install in a subdir of /usr/lib). If they are meant to be
>> public libraries, you need to read libpkg-guide and the bugs filed
>> against it.
>
> This library is used by the core application, if it's not placed in
> /usr/lib I have the classic error:
>
>  valide: error while loading shared libraries: libvalide-0.0.so.0: cannot
> open shared object file: No such file or directory
>
> I think that the library is in the good directory (like Anjuta). Is it
> reasonable to have six packages for this simple application?

It appears that most of the anjuta libraries are private ones and are
not located in /usr/lib:

http://packages.debian.org/sid/amd64/anjuta/filelist

If no other applications make use of the library, it is a good idea to
make it a private library. You can do that by placing it in a
subdirectory of /usr/lib (multi-arch will make this more complex
though) and using rpath to tell the binary where to find the library.
Some more info about rpath can be found here:

http://wiki.debian.org/RpathIssue
http://lists.debian.org/debian-devel/2002/07/msg02030.html

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[gege2061]

On Thu, 26 Nov 2009 16:35:27 +0800, Paul Wise <pabs@...> wrote:
> On Thu, Nov 26, 2009 at 5:47 AM, Nicolas Joseph
> <gege2061@...> wrote:
>
>>> These should be installed to /usr/share instead. You might need to
>>> patch the source to install them in the right place. See here for why:
>>>
>>> http://lintian.debian.org/tags/image-file-in-usr-lib.html
>>
>> If it's a critical warning, I can fix it, but I prefer to have all
files

>> in the same directory.
>
> Debian prefers FHS compliance
>
>>>> W: valide-common: extra-license-file usr/share/valide/COPYING
>>>
>>> Unless the application needs it, there is no reason to install this
>> file.
>>>
>>> http://lintian.debian.org/tags/extra-license-file.html
>>>
>>
>> Yes the application use the COPYING file for show the license in the
>> about
>> dialog.
>
> In that case it is appropriate to override the lintian warning. If it
> is the same as a license in /usr/share/common-licenses then you might
> just want to configure the software to display that instead.
> Alternatively, I think many apps just show the license grant ("This
> program is free software....") in the about dialog and leave the
> license terms for the user to find if they want to.
>

Fixed in trunk.

>>>> W: valide: non-dev-pkg-with-shlib-symlink
>> usr/lib/libvalide-0.0.so.0.7.0
>>>> usr/lib/libvalide-0.0.so
>>>> W: valide: package-name-doesnt-match-sonames libvalide-0.0-0
>>>
>>> I imagine these are not meant to be public libraries. If they are
>>> supposed to be private, please work with upstream to make them private
>>> libraries (install in a subdir of /usr/lib). If they are meant to be
>>> public libraries, you need to read libpkg-guide and the bugs filed
>>> against it.
>>
>> This library is used by the core application, if it's not placed in
>> /usr/lib I have the classic error:
>>
>>  valide: error while loading shared libraries: libvalide-0.0.so.0:
>> cannot
>> open shared object file: No such file or directory
>>
>> I think that the library is in the good directory (like Anjuta). Is it
>> reasonable to have six packages for this simple application?
>
> It appears that most of the anjuta libraries are private ones and are
> not located in /usr/lib:
>
> http://packages.debian.org/sid/amd64/anjuta/filelist
>

Except the core library /usr/lib/libanjuta.so I have the same
architecture.

> If no other applications make use of the library, it is a good idea to
> make it a private library. You can do that by placing it in a
> subdirectory of /usr/lib (multi-arch will make this more complex
> though) and using rpath to tell the binary where to find the library.
> Some more info about rpath can be found here:
>
> http://wiki.debian.org/RpathIssue
> http://lists.debian.org/debian-devel/2002/07/msg02030.html
>

 - The lib is not intended to be used by anyone else. There's no -dev
   package for it, it is just a convenience lib to avoid that lots of
   related binaries contain the same code.

This point confirm my opignion: I have a -dev package for develop plugins.

I think my package is clean, I will continue to read the DD guide to you
propose it.

Thank's for your help.
--
Nicolas Joseph

http://www.valaide.org


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...