Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-12-09 Thread Gianfranco Costamagna
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi

> sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' package.symbols | c++filt >
> package.symbols.new

this was intended with an additional
mv package.symbols.new package.symbols

(I didn't find a quick way to replace them inline)

> Thanks for building, but it seems that it did not work. I do not
> know why… For me the target "override_dh_auto_configure" works on
> different architectures. Is it normal that I'm unable to create a
> s390x environment on pbuilder-dist?

it isn't normal, but somewhen apt/aptitude/pbuilder/qemu becomes
broken, and you can't use them anymore...
(too many layers of virtualization here :p)

I hope somebody will fix them in the future, anyway...

Built in new queue, thanks for the nice contribution
to Debian!

Note: I removed the "debian/liblastfm*.new", because it was useless in
the context.

I also tried to mv the .new in the original and correct location, but
the build failed with a gensybols error.

so I just removed it and signed
If you have a better solution for the c++filt issue let me see and
I'll upload again!

cheers,

G.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWaDvhAAoJEPNPCXROn13ZsbwP/RL7hpEhAgeAKB8HUr+C5qWv
2BlTbb5lsL/p4EeBzHmAxFobutJ44biCN9wX/IooUt5PeVFIbzE9Eu+PYOgi7lCJ
C0fcsFkypqernmpU86Cmlo0RiM3wIDW3rpsunaS22SMWWFz05Kp7+3qyh9bopw3S
Dhh+7XHprc4Qj0Q95F/XW+oyhjSpCyi9BR5cxzj/VJb+ENrChwA3opfrg18WIKgh
osbENEoiM/OIDk5qjg7idzMvLe3dmi7MJbf9dyUrQUhhJ3kb54GrXe3VsMvZG4XP
tamoMTokSv0mbqSAWwAObc9VHRB1n3RyJRRNWQz70BZIZBMt7S4mGqOO+4Pc5RbZ
M13R9w4g1y90q26WSQjcAwka+hWC73WF1ZAETigz63zga9vgl4Lygpl0hOTeMknR
kbokZCu70lC74lAc+mmDVanVY646OvOUFaCi/Z8qjIDJ7Q9Vb03lSnTaLxH585oT
Df4VLzJlJt8zhAN36wEqz7GG+8qyk0L7MrR66vfQ8AE+upP7uAe+e/AF+ILRbVUI
dTNkPSnhzevWfqct6NRABUrB5gdGZsvlc/mFulokY6F8s4qTkYjmUl5jq06EwxVV
sCeQQxO+uenxExnTvTZzNX3ZFobbD6Cqv+f9bvWqXI3y58814O9Q3AOGrjXYs7md
N6/vpzrqCvSQMiau9MXU
=ICtI
-END PGP SIGNATURE-



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-12-09 Thread Stefan Ahlers
Hi,

Thanks for signing and uploading!

> Note: I removed the "debian/liblastfm*.new", because it was useless in
> the context.
> 
> I also tried to mv the .new in the original and correct location, but
> the build failed with a gensybols error.
> 
> so I just removed it and signed


This was my mistake, I forgot to delete the *.new file. I had integrate
the new symbols into the symbol files. And so the symbol files should be
correct, except the symbols for powerpc and ppc64. It look like there is
a problem with the "(optional=templinst|arch=powerpc ppc64)" symbols.

They were also included in the previews version of the package. The
previous maintainer uses "optional"-symbols but I can not finde a
documentation about this feature.  Shell I remove them and reupload the
corrected package as liblastfm/1.0.9-2?

Stefan



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-12-09 Thread Gianfranco Costamagna
Hi i don't see any problem here
https://buildd.debian.org/status/package.php?p=liblastfm=unstable
But if you have a fixed package feel free to ping me and i'll have a look(I'm 
not a symbols - savvy man)
Cheers,
G
Sent from Yahoo Mail on Android
 
 
  On Wed, 9 Dec, 2015 at 21:09, Stefan Ahlers wrote:   
Hi,

Thanks for signing and uploading!

> Note: I removed the "debian/liblastfm*.new", because it was useless in
> the context.
> 
> I also tried to mv the .new in the original and correct location, but
> the build failed with a gensybols error.
> 
> so I just removed it and signed


This was my mistake, I forgot to delete the *.new file. I had integrate
the new symbols into the symbol files. And so the symbol files should be
correct, except the symbols for powerpc and ppc64. It look like there is
a problem with the "(optional=templinst|arch=powerpc ppc64)" symbols.

They were also included in the previews version of the package. The
previous maintainer uses "optional"-symbols but I can not finde a
documentation about this feature.  Shell I remove them and reupload the
corrected package as liblastfm/1.0.9-2?

Stefan
  


Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-20 Thread Stefan Ahlers
Hi,

I've uploaded a new version to mentors.debian.net
> sure, I built for the last missing archs:
> http://debomatic-powerpc.debian.net/distribution#unstable/liblastfm/1.0.9-1/buildlog
> http://debomatic-s390x.debian.net/distribution#unstable/liblastfm/1.0.9-1/buildlog

Thanks for building, but it seems that it did not work. I do not know
why… For me the target "override_dh_auto_configure" works on different
architectures. Is it normal that I'm unable to create a s390x
environment on pbuilder-dist? 

> I would prefer however a patch, in any case seems that you need to manually
> check that file at each update, and with some magic sed you might even strip 
> useful
> lines in a future upload.

OK, I'm using a patch now. I hope this is a better solution. Btw, I've
added the upstream/metadata file.

Stefan



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-19 Thread Gianfranco Costamagna
Hi Stefan,

>yes, the question actually is why one is liblastfm1 and the other 
>liblastfm5-1(I mean the -1, but it isn't a real problem I guess) 
>On Qt4 build the library so-name is liblastfm.so.1 and the package
>   scheme is:  → liblastfm1
>For the Qt5 build the name is liblastfm5.so.1 and the scheme is now 
>- → liblastfm5-1
>I think this happens because the name ends with a number and so lintian wants 
>to have a seperator between name and version.
>
>Shell I change the package name to liblastfm-qt5-1 and ignore the
>   lintian warning?



nope, it is nice that way

I wasn't unsure about who changed the version scheme :)

>Oh cool, I'm using pbuilder-dist, too. To create packages easier for
>   different ubuntu and debian versions. I thought you know a better
>   solution than using pbuilder-dist + QEMU.


I use debomatic, but it is based on sbuild+qemu, so I don't have any better 
solution
(well, I can use porterboxes as DD, but seems an overkill for a new package and 

time consuming)
>Ok, I've tested the build under arm64, armel, armhf, mipsel, mips.
>   And only a few optional symbols on liblastfm-fingerprint5-1.symbol
>   were obsolete. I've uploaded a new version to mentors.debian.net 


wonderful

>Could you please build the package for me and check if the symbols
>   are ok, or not?



sure, I built for the last missing archs:
http://debomatic-powerpc.debian.net/distribution#unstable/liblastfm/1.0.9-1/buildlog
http://debomatic-s390x.debian.net/distribution#unstable/liblastfm/1.0.9-1/buildlog

BTW I don't like stuff like this
sed -e '15,60d' -i README.md

because they make the package impossible to rebuild.

In order to make it easier to maintain I would suggest you:
dpkg-source --commit and extract as a patch
cp README.md debian
sed -e '15,60d' -i debian/README.md
and change
debian/liblastfm5-dev.docs:README.md
to
debian/liblastfm5-dev.docs:debian/README.md

and
echo "debian/README.md" >> debian/clean

this way you can rebuild it.

I would prefer however a patch, in any case seems that you need to manually
check that file at each update, and with some magic sed you might even strip 
useful
lines in a future upload.

let me know how do you feel about this last point and I'll do some final checks 
and hopefully
upload.

(the builds are going slow, I hope they wont crash or whatever)

cheers,

G.



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-19 Thread Stefan Ahlers
Paul Wise wrotes:
> If the wiki page isn't clear enough, try the examples:
> https://wiki.debian.org/UpstreamMetadata#Examples 

Sorry my question was wrong. In which case I should add
UpstreamMetadatas into the package? Is it a "nice to have" feature or in
some cases necessary? For me it looks like a connection between the
package and a academic article or paper. Do I have to look for academic
articles, which deal with the liblastfm package?

In the last day, there were much of new informations about debian
packaging for me and I have to sort them and at the moment I do not know
how to handle UpstreamMetadata in general. I hope you can understand my
problem.

Thank you Paul and Gianfranco for all the tips and hints and that you
spend your time for all my questions.

Kind regards,
 Stefan



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-19 Thread Gianfranco Costamagna
Hi,


>Fixed! I've set up a new repository.



wonderful
>Oha, this is great. Now the symbols are human readable.


:)

>liblastfm1 is build against Qt4 and liblastfm5-1 is build against Qt5.
>I've adopt the names of lintian.


yes, the question actually is why one is liblastfm1 and the other 
liblastfm5-1(I mean the -1, but it isn't a real problem I guess)

>There was a missing dependence in debian/control. Fixed!
>
>How can I fix the symbol files now? Is there a way to setup a local
>build farm for each architecture?



I can do the builds for you, just tell me whenever you are ready.

if you want you can do something like
pbuilder-dist sid ARCH create
and
pbuilder-dist sid ARCH build file.dsc

ARCH can be almost everything, armhf armel arm64 i386 amd64 s390x and many more

(they use qemu to virtualize, so you might have qemu-related failures)

let me know when you are ready (to test or to check again the package)

cheers,

G.



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-19 Thread Paul Wise
On Thu, 2015-11-19 at 12:05 +0100, Stefan Ahlers wrote:

> In which case I should add UpstreamMetadatas into the package?

Whenever there is an upstream where you can fill in any of the fields
listed on the UpstreamMetadata wiki page.

> Is it a "nice to have" feature or in some cases necessary?

It is always a "nice to have", I think I said at the start of my review
that all the things I wrote were in the "nice to have" category.

> For me it looks like a connection between the package and a academic
> article or paper. Do I have to look for academic articles, which deal
> with the liblastfm package?

Academic articles are one aspect of upstream metadata and are only a
possibility because the UpstreamMetadata proposal originated in the
Debian Science (or Debian Med, I forget) team and references are very
useful for those teams. If no academic articles have been published
about a package, then there will be none to add to the upstream
metadata file. Same for donations or other upstream metadata.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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


Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-19 Thread Stefan Ahlers
Hi,


> yes, the question actually is why one is liblastfm1 and the other
> liblastfm5-1(I mean the -1, but it isn't a real problem I guess) 

On Qt4 build the library so-name is liblastfm.so.1 and the package
scheme is: ** → liblastfm1
For the Qt5 build the name is liblastfm5.so.1 and the scheme is now
*- *→ liblastfm5-1
I think this happens because the name ends with a number and so lintian
wants to have a seperator between name and version.

Shell I change the package name to liblastfm-qt5-1 and ignore the
lintian warning?

> I can do the builds for you, just tell me whenever you are ready.
>
> if you want you can do something like
> pbuilder-dist sid ARCH create
> and
> pbuilder-dist sid ARCH build file.dsc
>

Oh cool, I'm using pbuilder-dist, too. To create packages easier for
different ubuntu and debian versions. I thought you know a better
solution than using pbuilder-dist + QEMU.

Ok, I've tested the build under arm64, armel, armhf, mipsel, mips. And
only a few optional symbols on liblastfm-fingerprint5-1.symbol were
obsolete. I've uploaded a new version to mentors.debian.net

Could you please build the package for me and check if the symbols are
ok, or not?

Cheers,
 Stefan


Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-18 Thread Stefan Ahlers
Hi,

I tried to fix most of the points. I replaced my patch with a applied
upstream patch. One of the symbol files had a wrong file name. This
should be fixed, too.

I'm not sure what I have to add for upstream metadatas and I do not know
what to do with the output of

flawfinder -Q -c .


Please let me know what I should do next.

Kindly regards,
Stefan Ahlers



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-18 Thread Gianfranco Costamagna
Hi,


>I tried to fix most of the points. I replaced my patch with a applied
>upstream patch. One of the symbol files had a wrong file name. This
>should be fixed, too.
lets see :)

1) VCS-* they should point to Debian packaging, not to upstream packaging
(this is done in copyright)


2) symbols:
sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' package.symbols | c++filt > 
package.symbols.new

and look to the "new" file :)
(you might have many build failures and need to fix the symbols file on various 
architecture, but

this needs to be done in a later step)

3) question: why one library is called liblastfm1_1.0.9-1_amd64.deb and the 
other is called liblastfm5-1_1.0.9-1_amd64.deb



(this shouldn't be a real issue, just I'm wondering if it is a lintian complain)

4) lintian: 
X: liblastfm5-dev: package-contains-broken-symlink 
usr/lib/x86_64-linux-gnu/liblastfm_fingerprint5.so liblastfm_fingerprint5.so.1

cheers,

G.



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-18 Thread Stefan Ahlers
Hi,
> 1) VCS-* they should point to Debian packaging, not to upstream packaging
> (this is done in copyright)
Fixed! I've set up a new repository.
> 2) symbols:
> sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' package.symbols | c++filt > 
> package.symbols.new
>
> and look to the "new" file :)
> (you might have many build failures and need to fix the symbols file on 
> various architecture, but
>
> this needs to be done in a later step)
Oha, this is great. Now the symbols are human readable.
> 3) question: why one library is called liblastfm1_1.0.9-1_amd64.deb and the 
> other is called liblastfm5-1_1.0.9-1_amd64.deb
liblastfm1 is build against Qt4 and liblastfm5-1 is build against Qt5.
I've adopt the names of lintian.
> 4) lintian: 
> X: liblastfm5-dev: package-contains-broken-symlink 
> usr/lib/x86_64-linux-gnu/liblastfm_fingerprint5.so liblastfm_fingerprint5.so.1
There was a missing dependence in debian/control. Fixed!

How can I fix the symbol files now? Is there a way to setup a local
build farm for each architecture?

Stefan



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-18 Thread Gianfranco Costamagna
Control: owner -1 !
Control: tags -1 moreinfo

Hi Stefan



(some issues of libjdns also apply here, and Pabs review is correct, so please 
check them before)

in additions:
please consider moving priority to optional
https://www.debian.org/doc/debian-policy/ch-archive.html#s-priorities


the other stuff LGTM :)

cheers,

G.



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-18 Thread Paul Wise
On Wed, Nov 18, 2015 at 12:58 AM, Stefan Ahlers wrote:

> I am looking for a sponsor for my package "liblastfm"

I don't intend to sponsor this package, but here is a review:

There don't appear to be any blockers.

These things would be nice to fix:

Please put DEP-3 a header on the patch.

http://dep.debian.net/deps/dep3/

I wonder what upstream has to say about the patch since it breaks
compatibility with them.

README.md contains build/install instructions, which are not useful to
binary package users. I would strip that out with sed during the build
process or ask upstream to move it to README.install.

Please add some upstream metadata: https://wiki.debian.org/UpstreamMetadata

When I set DPKG_GENSYMBOLS_CHECK_LEVEL=4, the build fails because
there are many more symbols exported than present in the symbols
files.

The package FTBFS when built twice in a row, the second build fails
because the build/ dir isn't removed by `debian/rules clean`.

Automatic checks:

build

src/Xspf.cpp:118:5: warning: 'void lastfm::Xspf::expired()' is
deprecated [-Wdeprecated-declarations]
src/Xspf.cpp:118:13: warning: 'void lastfm::Xspf::expired()' is
deprecated [-Wdeprecated-declarations]
build/qt4/so/src/moc_RadioTuner.cpp:67:35: warning: 'void
lastfm::RadioTuner::onXspfExpired()' is deprecated
[-Wdeprecated-declarations]
build/qt4/so/src/moc_Xspf.cpp:52:29: warning: 'void
lastfm::Xspf::expired()' is deprecated [-Wdeprecated-declarations]
build/qt4/so/src/moc_Xspf.cpp:53:31: warning: 'void
lastfm::Xspf::onExpired()' is deprecated [-Wdeprecated-declarations]

lintian

P: liblastfm source: debian-control-has-unusual-field-spacing line 106
I: liblastfm source: duplicate-short-description liblastfm-dev liblastfm5-dev
I: liblastfm source: duplicate-short-description liblastfm1 liblastfm5-1
I: liblastfm source: duplicate-short-description
liblastfm-fingerprint1 liblastfm-fingerprint5-1
I: liblastfm source: duplicate-long-description liblastfm-fingerprint1
liblastfm-fingerprint5-1
I: liblastfm source: duplicate-short-description liblastfm-dbg liblastfm5-dbg
P: liblastfm source: debian-watch-may-check-gpg-signature
P: liblastfm-dbg: no-upstream-changelog
P: liblastfm-fingerprint1: no-upstream-changelog
P: liblastfm-fingerprint5-1: no-upstream-changelog
P: liblastfm5-dev: no-upstream-changelog
X: liblastfm5-dev: package-contains-broken-symlink
usr/lib/x86_64-linux-gnu/liblastfm_fingerprint5.so
liblastfm_fingerprint5.so.1
I: liblastfm5-1: hardening-no-fortify-functions
usr/lib/x86_64-linux-gnu/liblastfm5.so.1.0.9
P: liblastfm5-1: no-upstream-changelog
I: liblastfm5-1: no-symbols-control-file
usr/lib/x86_64-linux-gnu/liblastfm5.so.1.0.9
I: liblastfm1: hardening-no-fortify-functions
usr/lib/x86_64-linux-gnu/liblastfm.so.1.0.9
P: liblastfm1: no-upstream-changelog
P: liblastfm-dev: no-upstream-changelog
P: liblastfm5-dbg: no-upstream-changelog

check-all-the-things

$ codespell --quiet-level=3


$ flawfinder -Q -c .


$ grep -riE 'fixme|todo|hack|xxx' .


-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-18 Thread Paul Wise
On Thu, Nov 19, 2015 at 1:06 AM, Stefan Ahlers wrote:

> I'm not sure what I have to add for upstream metadatas

If the wiki page isn't clear enough, try the examples:

https://wiki.debian.org/UpstreamMetadata#Examples

> I do not know what to do with the output of
>
> flawfinder -Q -c .

I would just point out this tool to upstream.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]

2015-11-17 Thread Stefan Ahlers
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "liblastfm"

* Package name: liblastfm
  Version : 1.0.9-1
  Upstream Author : Michael Coffey 
* URL : https://github.com/lastfm/liblastfm
* License : GPL-3+
  Section : libs

It builds those binary packages:

 liblastfm-dbg - Debugging symbols for the Last.fm web services library
 liblastfm-dev - Last.fm web services library - development files
 liblastfm-fingerprint1 - Last.fm fingerprinting library
 liblastfm-fingerprint5-1 - Last.fm fingerprinting library
 liblastfm1 - Last.fm web services library
 liblastfm5-1 - Last.fm web services library
 liblastfm5-dbg - Debugging symbols for the Last.fm web services library
 liblastfm5-dev - Last.fm web services library - development files

To access further information about this package, please visit the following 
URL:

 http://mentors.debian.net/package/liblastfm

Alternatively, one can download the package with dget using this command:

   dget -x 
http://mentors.debian.net/debian/pool/main/libl/liblastfm/liblastfm_1.0.9-1.dsc

More information about hello can be obtained from http://www.example.com.

Changes since the last upload:

* New upstream release. (Closes: #805081)
* Set myself as the new maintainer with permission of John Stamp the original 
maintainer.
* debian/rules;debian/control;debian/*5*:
  - Dual build: Qt4 & Qt5

Regards,
 Stefan Ahlers