[UPLOADED] Re: RFS: gtkpod (updated package)

2011-05-23 Thread Michael Biebl 
Am 06.05.2011 18:30, schrieb Matteo F. Vescovi:
> Dear mentors,
> 
> I am looking for a sponsor for the new version 2.0.1-1
> of my package "gtkpod".
> 
> This is the last upstream release of a package already in Debian.
> 
> It builds these binary packages:
> gtkpod- manage songs and playlists on an Apple iPod
> gtkpod-data   - architecture-independent files for gtkpod
> libgtkpod-dev - main library for the gtkpod package, development kit
> libgtkpod1- main library for the gtkpod package, shared library
> 
> The package appears to be lintian clean.
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/g/gtkpod
> - Source repository: deb-src http://mentors.debian.net/debian unstable
> main contrib non-free
> - dget
> http://mentors.debian.net/debian/pool/main/g/gtkpod/gtkpod_2.0.1-1.dsc
> 
> I'm also working on the copyright file to make it DEP-5 compliant.
> Maybe I'll update it on the next upload.

I've sponsored the upload.


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



signature.asc
Description: OpenPGP digital signature

Re: RFS: gtkpod (updated package)

2011-05-19 Thread Michael Biebl 
Hi Matteo!

Am 06.05.2011 18:30, schrieb Matteo F. Vescovi:
> Dear mentors,
> 
> I am looking for a sponsor for the new version 2.0.1-1
> of my package "gtkpod".

I don't own or use an iPod bug I'm willing to sponsor your updated gtkpod
package, as I'd like to see #613168 fixed

There are a few issues I noticed, that you should fix before I can make the 
upload:

- chrpath
The package builds fine without the chrpath mangling. So please remove the
chrpath calls from debian/rules, the chrpath b-dep from debian/control and the
reference from README.Debian

- package split
  + usr/lib/pkgconfig belongs into libgtkpod-dev
  + usr/lib/libgtkpod.a belongs into libgtkpod-dev (or can be dropped
altogether. static linking is not very common anymore these days)
  + the plugins in /usr/lib/gtkpod belong into gtkpod, only install the so
files, i.e the line in gtkpod.install should be /usr/lib/gtkpod/*.so

- symbols file
  + The symbols file should only contain the symbols of libgtkpod and not  the
plugins. See above about moving the plugins into gtkpod.
  + The symbol version should not contain the debian revision, unless the
symbols was added by a debian specific patch. i.e. instead of 2.0.1-1~ use 2.0.1

- README.source
The reference to quilt is obsolete as you use dpkg source v3 (quilt) and can be
removed.

- changelog
  + Please close #613168 in the changelog (adding a short description)
  + 2.0.0-1 was never uploaded to unstable. So either set the upload target to
UNRELEASED or merge the 2.0.0-1 changelog into 2.0.1-1. I'd prefer the latter.
  + You don't need to close both #623237 and #621910, as those bugs have been
merged, so closing one is sufficient
  + The "* New maintainer release (Closes: #621910)"  changelog is a bit
misleading. I'd suggest something like the following

  * New upstream release. (Closes: #578714)
  * New maintainer. (Closes: #621910)

- upstream tarball
the md5sum of the upstream tarball and your orig.tar.gz do not match.
de20c3958c6726a209bc4b0579c4ec52  gtkpod_2.0.1.orig.tar.gz
8b12e9f990701c71c60a45193b3eeef4  gtkpod-2.0.1.tar.gz

Please use the pristine upstream tarball (without repacking). If you need to
repack the upstream tarball, then this needs to be added to README.source

- copyright
The copyright file seems to have some outdated references.


Please ping me as soon as you have an updated package.

Michael


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



signature.asc
Description: OpenPGP digital signature

Re: RFS: gtkpod (updated package)

2011-05-09 Thread Matteo F. Vescovi 
On 09/05/2011 12:12, Etienne Millon wrote:
> On Mon, May 09, 2011 at 11:17:38AM +0200, Matteo F. Vescovi wrote:
>>>   - debian/rules :
>>> - why do you remove RPATHs from executables and binary ? It's stated 
>>> briefly
>>>   in NEWS.debian, but the reason is not there.
>>
>> Without this hack, it doesn't compile and build. I'll add a line about
>> it in NEWS.Debian (or README.Debian?).
> 
> Eventually README.Debian as it does not concern end-users.

OK. Added.

>>> - as libgtkpod.la is new, no reverse dependencies should depend on its
>>>   existence. It should be safe not to install it[1].
>>
>> OK, gonna remove it. However I asked in IRC channel and they told me how
>> to blank the dependency_libs field and keep the rest of the file, for
>> compatibility.
> 
> Actually there is no need to be compatible as nothing depends on it
> ATM :)

OK. Removed.

>>> - the "README.debian" is not necessary.
>>
>> Really? OK.
> 
> I mean the line in debian/changelog : it adds nothing because relevant
> information is already in README.debian.

I initially misread... and understood the meaning once I've opened the
changelog ;-) Now I remember that I added that line because in former
package there wasn't that file while I thought it could be important
adding my changes there... and that was a way to let people know I also
created it. Issue resolved. Thanks.

Now I've updated almost all the steps you had an observation on.
Thanks a lot for your review. It has been really helpful.

Hope to find a sponsor, sooner or later ;-)

Cheers.

mfv


-- 
Ing. Matteo F. Vescovi

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dc7c090.8000...@revese.it

Re: RFS: gtkpod (updated package)

2011-05-09 Thread Etienne Millon 
On Mon, May 09, 2011 at 11:17:38AM +0200, Matteo F. Vescovi wrote:
> >   - debian/rules :
> > - why do you remove RPATHs from executables and binary ? It's stated 
> > briefly
> >   in NEWS.debian, but the reason is not there.
> 
> Without this hack, it doesn't compile and build. I'll add a line about
> it in NEWS.Debian (or README.Debian?).

Eventually README.Debian as it does not concern end-users.
 
> > - as libgtkpod.la is new, no reverse dependencies should depend on its
> >   existence. It should be safe not to install it[1].
> 
> OK, gonna remove it. However I asked in IRC channel and they told me how
> to blank the dependency_libs field and keep the rest of the file, for
> compatibility.

Actually there is no need to be compatible as nothing depends on it
ATM :)

> > - the "README.debian" is not necessary.
> 
> Really? OK.

I mean the line in debian/changelog : it adds nothing because relevant
information is already in README.debian.

-- 
Etienne Millon


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110509101220.gb5...@john.ssi.corp

Re: RFS: gtkpod (updated package)

2011-05-09 Thread Matteo F. Vescovi 
On 09/05/2011 10:53, Etienne Millon wrote:
> Hello,

Hi!

> As the usual disclaimer says, please not that I am not a DD and so, I can not
> sponsor this package. However here is my review of gtkpod_2.0.0-1 (md5sum of 
> dsc
> in case it changed : c9d4216c068873d3939f310de582c671).
> 
>   - it builds in a clean chroot. However dpkg-shlibdeps complains about 
> unneeded
> shared libraries.

I already asked upstream for adding the --as-needed flag in linking
phase. No reply for now.

>   - debian/copyright makes references to nonexistent or moved files. For 
> example
> wavfile.{c,h} now live in plugins/filetype_wav, and there are no md5.{c,h}
> file. This is a blocker, you should clarify which copyright applies to 
> which
> file.

I'm working on it now. I'd like to make it DEP-5 compliant.

>   - debian/rules :
> - why do you remove RPATHs from executables and binary ? It's stated 
> briefly
>   in NEWS.debian, but the reason is not there.

Without this hack, it doesn't compile and build. I'll add a line about
it in NEWS.Debian (or README.Debian?).

> - as libgtkpod.la is new, no reverse dependencies should depend on its
>   existence. It should be safe not to install it[1].

OK, gonna remove it. However I asked in IRC channel and they told me how
to blank the dependency_libs field and keep the rest of the file, for
compatibility.

>   - debian/patches : please consider using the DEP-3 format[2].

OK.

>   - debian/changelog :
> - as your ITA bug has been merged with the O bug, closing one should close
>   the other one.

Perfect. I'll remove the latter.

> - technically, your patch system is not quilt, but the "3.0 (quilt)" 
> format.
>   "quilt" refers to quilt used manually against sources, or with dh --with
>   quilt.

OK. I'll remove the sentence about it.

> - the "README.debian" is not necessary.

Really? OK.

>   - lintian : clean upto -I. -E shows one warning : X: libgtkpod1:
> shlib-calls-exit usr/lib/gtkpod/libsorttab_display.so It's mostly 
> processes
> exiting after fork(), and arguments processing. In the latter case, you
> might convince upstream to do that outside the library.

I'll try. Thanks.

> Thanks for contributing to Debian !
> 
> [1] http://wiki.debian.org/ReleaseGoals/LAFileRemoval
> [2] http://dep.debian.net/deps/dep3/

mfv


-- 
Ing. Matteo F. Vescovi

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dc7b132.8010...@revese.it

Re: RFS: gtkpod (updated package)

2011-05-09 Thread Etienne Millon 
Hello,

As the usual disclaimer says, please not that I am not a DD and so, I can not
sponsor this package. However here is my review of gtkpod_2.0.0-1 (md5sum of dsc
in case it changed : c9d4216c068873d3939f310de582c671).

  - it builds in a clean chroot. However dpkg-shlibdeps complains about unneeded
shared libraries.
  - debian/copyright makes references to nonexistent or moved files. For example
wavfile.{c,h} now live in plugins/filetype_wav, and there are no md5.{c,h}
file. This is a blocker, you should clarify which copyright applies to which
file.
  - debian/rules :
- why do you remove RPATHs from executables and binary ? It's stated briefly
  in NEWS.debian, but the reason is not there.
- as libgtkpod.la is new, no reverse dependencies should depend on its
  existence. It should be safe not to install it[1].
  - debian/patches : please consider using the DEP-3 format[2].
  - debian/changelog :
- as your ITA bug has been merged with the O bug, closing one should close
  the other one.
- technically, your patch system is not quilt, but the "3.0 (quilt)" format.
  "quilt" refers to quilt used manually against sources, or with dh --with
  quilt.
- the "README.debian" is not necessary.
  - lintian : clean upto -I. -E shows one warning : X: libgtkpod1:
shlib-calls-exit usr/lib/gtkpod/libsorttab_display.so It's mostly processes
exiting after fork(), and arguments processing. In the latter case, you
might convince upstream to do that outside the library.

Thanks for contributing to Debian !

[1] http://wiki.debian.org/ReleaseGoals/LAFileRemoval
[2] http://dep.debian.net/deps/dep3/
-- 
Etienne Millon


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110509085329.ga5...@john.ssi.corp

Re: RFS: gtkpod (updated package)

2011-05-07 Thread Matteo F. Vescovi 
On 06/05/2011 18:30, Matteo F. Vescovi wrote:
> Dear mentors,
> 
> I am looking for a sponsor for the new version 2.0.1-1
> of my package "gtkpod".
>
> [...]

Removed. It was too early. Maybe too much unstable.
I re-uploaded the stable release.
Sorry for the noise.

mfv


-- 
debian/rules!

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dc50ada.10...@revese.it

Re: RFS: gtkpod (updated package)

2011-05-06 Thread Matteo F. Vescovi 
On 03/05/2011 19:17, Maia Kozheva wrote:
> For what it's worth, upstream maintains a PPA for Ubuntu that does include a 
> libgtkpod-dev package for 2.0.0.

OK, thanks for the info.


--
Ing. Matteo F. Vescovi

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dc3c77f.40...@revese.it

Re: RFS: gtkpod (updated package)

2011-05-03 Thread Maia Kozheva 
For what it's worth, upstream maintains a PPA for Ubuntu that does include a 
libgtkpod-dev package for 2.0.0.


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

Re: RFS: gtkpod (updated package)

2011-05-03 Thread Etienne Millon 
Well, the joys of sid :)

I'll review this package after the transition is done.

> > [about libgtkpod-dev]
> Because I've never thought it could be used by any other software, since
> it was part of a specific source package.

It is quite common to distribute the whole software (client, library,
headers) as a single tarball (and so, a single source package).

-- 
Etienne Millon


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110503112254.ge3...@john.ssi.corp

Re: RFS: gtkpod (updated package)

2011-05-02 Thread Matteo F. Vescovi 
On 02/05/2011 17:14, Michael Biebl wrote:
> Am 02.05.2011 16:49, schrieb Matteo F. Vescovi:
>>
>> So I have only one alternative :-) And doesn't sound easy, at least for
>> me ;-) But I'll give me a try... maybe I could even succeed :-)
>>
> 
> The right way to go about this is to find out if there 3rd party packages 
> using
> this library, you need to talk to upstream about that to actually find out 
> what
> this library is supposed to do.

OK.

> I looked more closely and the package builds a proper system library including
> header files and a pkg-config file. So it is clearly intended as being used by
> others software and should be packaged as such. But please get a confirmation
> for that.

OK.

> Why did you say that there will never be a libgtkpod-dev package?

Because I've never thought it could be used by any other software, since
it was part of a specific source package.
Give me the time to ask to the upstream plus a working sid box back and
I'll be very happy to complete my work ;-)

> Michael

Matteo

-- 
Ing. Matteo F. Vescovi

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbecf22.9040...@revese.it

Re: RFS: gtkpod (updated package)

2011-05-02 Thread Michael Biebl 
Am 02.05.2011 16:49, schrieb Matteo F. Vescovi:
> 
> So I have only one alternative :-) And doesn't sound easy, at least for
> me ;-) But I'll give me a try... maybe I could even succeed :-)
> 

The right way to go about this is to find out if there 3rd party packages using
this library, you need to talk to upstream about that to actually find out what
this library is supposed to do.

I looked more closely and the package builds a proper system library including
header files and a pkg-config file. So it is clearly intended as being used by
others software and should be packaged as such. But please get a confirmation
for that.

Why did you say that there will never be a libgtkpod-dev package?

Michael

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



signature.asc
Description: OpenPGP digital signature

Re: RFS: gtkpod (updated package)

2011-05-02 Thread Matteo F. Vescovi 
Ciao Arno,

On 02/05/2011 16:23, Arno Töll wrote:
> Hi Matteo,
> 
> On 02.05.2011 15:55, Matteo F. Vescovi wrote:
>> Yes, but no reply at present time. I asked them for info concerning who
>> should be the maintainer (me?) and the uploader (now the Frank orphaned
>> the package) to modify debian/control file accordingly. 
> 
> That information is not related to upstream. This is a pure Debian
> internal matter. If you took over the package by adopting it, you /are/
> the maintainer. Since there is an Alioth project for you already you may
> want to set the pkg-gtkpkd list as maintainer and yourself as uploader
> instead.

Sorry, I misread; I meant I wrote to the pkg-gtkpod-devel team.
I wrote to the upstream mailing list only once to get some info about
how to manage configure flags regarding GTK and GDK.

>> Never thought
>> the split of the library could be an issue; it has been suggested by the
>> guys in #debian-mentors to resolv a lintian warning.
>> Once they'll knock on my door, I'll ask them even about this.
>> Thank you for the advice.
> 
> It wasn't me in particular to suggest you this, however I somewhat
> followed your progress: Your problem is, you can't (read: should not)
> install libraries into a system wide location (e.g. /usr/lib/) from a
> binary package whose name is not lib. If you do nonetheless
> lintian will croak and the DD which is interested to sponsor you will
> ask you to change this.
> 
> You have two alternatives:
> 
> * Provide libfoo as you did and install to a system wide location, but
> if you do the library must be useful for /other/ packages than yours too
> and you should include a -dev package providing headers and .so symlinks
> which allows other people to link against your package. I don't think
> your library falls in this category.
> * Install the library to a program local location, e.g /usr/lib/gtkpod
> and ship it in the main package. If you prefer this way, you probably
> have to tweak Makefile and/or library search paths on link time a bit,
> if upstream does not support this by default. Don't consider setting
> rpath though.

So I have only one alternative :-) And doesn't sound easy, at least for
me ;-) But I'll give me a try... maybe I could even succeed :-)

Thanks for your constant help.

mfv


-- 
Ing. Matteo F. Vescovi

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbec490.3050...@revese.it

Re: RFS: gtkpod (updated package)

2011-05-02 Thread Arno Töll 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Matteo,

On 02.05.2011 15:55, Matteo F. Vescovi wrote:
> Yes, but no reply at present time. I asked them for info concerning who
> should be the maintainer (me?) and the uploader (now the Frank orphaned
> the package) to modify debian/control file accordingly. 

That information is not related to upstream. This is a pure Debian
internal matter. If you took over the package by adopting it, you /are/
the maintainer. Since there is an Alioth project for you already you may
want to set the pkg-gtkpkd list as maintainer and yourself as uploader
instead.

> Never thought
> the split of the library could be an issue; it has been suggested by the
> guys in #debian-mentors to resolv a lintian warning.
> Once they'll knock on my door, I'll ask them even about this.
> Thank you for the advice.

It wasn't me in particular to suggest you this, however I somewhat
followed your progress: Your problem is, you can't (read: should not)
install libraries into a system wide location (e.g. /usr/lib/) from a
binary package whose name is not lib. If you do nonetheless
lintian will croak and the DD which is interested to sponsor you will
ask you to change this.

You have two alternatives:

* Provide libfoo as you did and install to a system wide location, but
if you do the library must be useful for /other/ packages than yours too
and you should include a -dev package providing headers and .so symlinks
which allows other people to link against your package. I don't think
your library falls in this category.
* Install the library to a program local location, e.g /usr/lib/gtkpod
and ship it in the main package. If you prefer this way, you probably
have to tweak Makefile and/or library search paths on link time a bit,
if upstream does not support this by default. Don't consider setting
rpath though.


- -- 
with kind regards,
Arno Töll
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNvr5DAAoJEMcrUe6dgPNtFmwQAJhQTViUx+m3OZFOxjr668w2
56zk+b0psbJ9t36p+P2zX1tywdcmLTTYA+nwet812cBlcbbE545Pn0D7m+vTmJ7D
4wuW38vr2PGkcL4JuNZ7VX8Tw7dbu8HrCDCawsAScmhkCNVaHVIIYubdozFmVIxe
RQ/tAlyBXQ/HYLn+0vSPRKEwDVNEa9TyH/S9oVM3hIct/p4jf3iC1PPpUVqUp2fc
fNlyRAIuj/bKUjEazipr+Ul/z4Bd5hzcUtNtGizL9RIwpplZZTvA9HQSI3NsszpK
Ea8O80L0xsOcr17pYyUCZ6lMOBRPZ72v0/fihUVaRGHIIjRc4+YYaz9qTUnmx/S1
1XDHEdojPD9GkK0dtu0TE+j+fPBUcTm/gIyerLkeewhPUy9eqFaNSL2l1sOJkicS
5xkQsjC3xnRcOr9iE6DhkGcuLGwjM+aA8aRgtra5s7bwHK4/VRGvSesQXtA5KW59
b4FK99iWF2MfYqwqwDmEtUG82jLMTJY96LWHH2EB3Bms+/nq0rkfdygrDgPY8kYs
gC2rm+2UybYFFPJW7KUunttbbJUG7bAOOsmqfKGtVbftoO/Q86i/C/3pPzMJ9HBX
/YcEfPQ8+gZjZlwLtJ1Bk4dvNtsO7tcFcKpDszsIGNvCbpKI09oQZJ1rBd4il9oo
9MlWONEppJTjhkZLd/l7
=JEs2
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbebe44.7060...@toell.net

Re: RFS: gtkpod (updated package)

2011-05-02 Thread Matteo F. Vescovi 
On 02/05/2011 15:27, Michael Biebl wrote:
> Bad timing I guess. The perl 5.12 transition just started yesterday.
> Will probably need a couple of days until this is sorted out.

:-( I'll eagerly wait.

> That said, while looking at your package briefly, I noticed that you
> split the library into a separate package libgtkpod1.
> Yet there is no corresponding libgtkpod-dev package.

And there'll never be, I guess ;-)

> If the library is meant to be used by other packages (is there one?),
> then you'd need to include the dev package. If the library is only used
> internally, then it should either be linked statically into gtkpod or
> moved to /usr/lib/gtkpod.

It's used only internally; once I'll have a working sid box again, I'll
re-build the package moving the lib to /usr/lib/gtkpod. Thanks for the hint.

> Have you consulted upstream about this?

Yes, but no reply at present time. I asked them for info concerning who
should be the maintainer (me?) and the uploader (now the Frank orphaned
the package) to modify debian/control file accordingly. Never thought
the split of the library could be an issue; it has been suggested by the
guys in #debian-mentors to resolv a lintian warning.
Once they'll knock on my door, I'll ask them even about this.
Thank you for the advice.

> Michael

Matteo


-- 
Ing. Matteo F. Vescovi

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbeb7eb.7050...@revese.it

Re: RFS: gtkpod (updated package)

2011-05-02 Thread Michael Biebl 
Am 02.05.2011 10:04, schrieb Matteo F. Vescovi:
> On 02/05/2011 09:40, Etienne Millon wrote:
>> Hello,
>>
>> Your package fails to build from source in an up-to-date sid chroot.
>> Please see the attached build log.
>>
>> I did not investigate further but something seems wrong with your
>> perl-related build-deps.
> 
> It seems to be a sid-related problem... an upgrade to latest completely
> removed almost all perl modules... lintian included. That's not fine.

Bad timing I guess. The perl 5.12 transition just started yesterday.
Will probably need a couple of days until this is sorted out.

That said, while looking at your package briefly, I noticed that you
split the library into a separate package libgtkpod1.
Yet there is no corresponding libgtkpod-dev package.

If the library is meant to be used by other packages (is there one?),
then you'd need to include the dev package. If the library is only used
internally, then it should either be linked statically into gtkpod or
moved to /usr/lib/gtkpod.

Have you consulted upstream about this?

Michael

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



signature.asc
Description: OpenPGP digital signature

Re: RFS: gtkpod (updated package)

2011-05-02 Thread Matteo F. Vescovi 
On 02/05/2011 09:40, Etienne Millon wrote:
> Hello,
> 
> Your package fails to build from source in an up-to-date sid chroot.
> Please see the attached build log.
> 
> I did not investigate further but something seems wrong with your
> perl-related build-deps.

It seems to be a sid-related problem... an upgrade to latest completely
removed almost all perl modules... lintian included. That's not fine.

> Cheers,

Cheers.


-- 
Ing. Matteo F. Vescovi

-- 
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dbe6580.8060...@revese.it

Re: RFS: gtkpod (updated package)

2011-05-02 Thread Etienne Millon 
On Sun, May 01, 2011 at 11:46:47PM +0200, Matteo F. Vescovi wrote:
> I am looking for a sponsor for the new version 2.0.0-1
> of my package "gtkpod".

Hello,

Your package fails to build from source in an up-to-date sid chroot.
Please see the attached build log.

I did not investigate further but something seems wrong with your
perl-related build-deps.

Cheers,

-- 
Etienne Millon
I: Running in no-targz mode
I: using fakeroot in build.
I: Current time: Mon May  2 09:16:52 CEST 2011
I: pbuilder-time-stamp: 1304320612
I: copying local configuration
I: mounting /proc filesystem
I: mounting /dev/pts filesystem
I: Mounting /var/cache/pbuilder/ccache
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Setting up ccache
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: i386
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 8), autoconf, automake, autotools-dev, chrpath, flex, 
gettext, git-core, gtk-doc-tools, libglib2.0-dev, libgtk2.0-dev, libglade2-dev, 
libid3tag0-dev, libanjuta-dev, libgpod-dev (>= 0.8.0), libgdl-1-dev, 
pkg-config, python-support
dpkg-deb: building package `pbuilder-satisfydepends-dummy' in 
`/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously deselected package pbuilder-satisfydepends-dummy.
(Reading database ... 11929 files and directories currently installed.)
Unpacking pbuilder-satisfydepends-dummy (from 
.../pbuilder-satisfydepends-dummy.deb) ...
dpkg: pbuilder-satisfydepends-dummy: dependency problems, but configuring 
anyway as you requested:
 pbuilder-satisfydepends-dummy depends on debhelper (>= 8); however:
  Package debhelper is not installed.
 pbuilder-satisfydepends-dummy depends on autoconf; however:
  Package autoconf is not installed.
 pbuilder-satisfydepends-dummy depends on automake; however:
  Package automake is not installed.
 pbuilder-satisfydepends-dummy depends on autotools-dev; however:
  Package autotools-dev is not installed.
 pbuilder-satisfydepends-dummy depends on chrpath; however:
  Package chrpath is not installed.
 pbuilder-satisfydepends-dummy depends on flex; however:
  Package flex is not installed.
 pbuilder-satisfydepends-dummy depends on gettext; however:
  Package gettext is not installed.
 pbuilder-satisfydepends-dummy depends on git-core; however:
  Package git-core is not installed.
 pbuilder-satisfydepends-dummy depends on gtk-doc-tools; however:
  Package gtk-doc-tools is not installed.
 pbuilder-satisfydepends-dummy depends on libglib2.0-dev; however:
  Package libglib2.0-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libgtk2.0-dev; however:
  Package libgtk2.0-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libglade2-dev; however:
  Package libglade2-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libid3tag0-dev; however:
  Package libid3tag0-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libanjuta-dev; however:
  Package libanjuta-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libgpod-dev (>= 0.8.0); however:
  Package libgpod-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libgdl-1-dev; however:
  Package libgdl-1-dev is not installed.
 pbuilder-satisfydepends-dummy depends on pkg-config; however:
  Package pkg-config is not installed.
 pbuilder-satisfydepends-dummy depends on python-support; however:
  Package python-support is not installed.
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
Reading package lists...
Building dependency tree...
Reading state information...
Initializing package states...
Writing extended state information...
The following NEW packages will be installed:
  adduser{a} anjuta-common{a} autoconf{a} automake{a} autopoint{a} 
  autotools-dev{a} bsdmainutils{a} ca-certificates{a} chrpath{a} dbus{a} 
  dbus-x11{a} debhelper{a} docbook{a} docbook-dsssl{a} docbook-to-man{a} 
  docbook-xml{a} docbook-xsl{a} file{a} flex{a} fontconfig{a} 
  fontconfig-config{a} gconf2{a} gconf2-common{a} gettext{a} 
  gettext-base{a} gir1.2-atk-1.0{a} gir1.2-freedesktop{a} 
  gir1.2-gdkpixbuf-2.0{a} gir1.2-glib-2.0{a} gir1.2-pango-1.0{a} git{a} 
  git-core{a} git-man{a} gnome-common{a} groff-base{a} gtk-doc-tools{a} 
  highlight{a} highlight-common{a} html2text{a} intltool{a} 
  intltool-debian{a} jade{a} libanjuta-dev{a} libanjuta0{a} libatk1.0-0{a} 
  libatk1.0-data{a} libatk1.0-dev{a} libavahi-client3{a} 
  libavahi-common-data{a} libavahi-common3{a} libcairo-gobject2{a} 
  libcairo-script-interpreter2{a} libcairo2{a} libcairo2-dev{a} 
  libcroco3{a} libcups2{a} libcurl3-gnutls{a} libdatrie1{a} libdbus-1-3{a}