Bug#805393: Subject: RFS: liblastfm/1.0.9-1 [ITA]
-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]
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]
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 Ahlerswrote: 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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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