Bug#827616: RFS: libjreen/1.2.0-2 - bugfix
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for a update of my package "jreen" to fix the bug (https://bugs.debian.org/827585). * Package name: jreen Version : 1.2.0-2 Upstream Author : Ruslan Nigmatullin <euroeles...@yandex.ru> * URL : https://github.com/euroelessar/jreen * License : GPL-2+ Section : libs It builds those binary packages: libjreen-dbg - Jabber/XMPP library (Qt 4) - debugging libjreen-dev - Jabber/XMPP library (Qt 4) - development libjreen-qt5-1 - Jabber/XMPP library implemented in Qt5/C++ libjreen-qt5-dbg - Jabber/XMPP library (Qt 5) - debugging libjreen-qt5-dev - Jabber/XMPP library (Qt 5) - development libjreen1 - Jabber/XMPP library implemented in Qt4/C++ To access further information about this package, please visit the following URL: https://mentors.debian.net/package/jreen Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/j/jreen/jreen_1.2.0-2.dsc Regards, Stefan Ahlers (https://launchpad.net/~justin-time)
Bug#807763: Looking for help to solve licence and third-party issues of the tomahawk-player package
Hey, > Hi again, it doesn't build on clean environment > http://debomatic-amd64.debian.net/distribution#unstable/tomahawk-player/0.8.4-1/buildlog I'm confused, on a Ubuntu 16.04 clean environment everything works fine with multiarch support but on debian sid it does not work. (https://launchpadlibrarian.net/240678247/tomahawk-player_0.8.4+dfsg1-0ubuntu1~xenial1_amd64.build) Is there a different in multiarch support? > licensecheck * -r > shows some stuff not mentioned in changelog. debian/copyright corrected. Should be complete now. > all the thirdparty stuff has different licenses, and should be > packaged separately (if possible, or useful outside this package). Most of them it is not useful. I had discussed this problematic with the developers. > ./src/tomahawk/sourcetree/items/LovedTracksItem.h: *the Free > Software Foundation; either version 2 of the License, or > ./src/tomahawk/sourcetree/items/InboxItem.h: * the Free Software > Foundation, either version 3 of the License, or > > even inside src there are different licenses. The developers say that this files are a bunch of code from a co-developer. > ./data/js/cryptojs/sha384.js:code.google.com/p/crypto-js/wiki/License > (and many more from cryptojs) Crypto-js is removed now. > data/fonts/*.ttf <--- please use system Roboto fonts, not any embedded > version. Is removed. > so, please think with upstream about removing all the external libs, > and package them separately (many of them should already be in debian) Please take a look on one of my old mails in this bug reports there is a statement to the external libs. The most java script files are removed now and tomahawk is using the system roboto font. Kind regards, Stefan Ahlers
Bug#807763: Looking for help to solve licence and third-party issues of the tomahawk-player package
Hi, jreen is accepted, now. Could you review the tomahawk-player package again? I know, there is much more work needs tobedone. It would be great, if you could check my answers of the first review and points out what I have to do next, which thirdparty code I have to pack separately and which code has to be removed because of the dfsg. Kind regards, Stefan Ahlers Am 18.01.2016 um 14:56 schrieb Gianfranco Costamagna: > please ping me when the jreen is accepted, I'll go in a new review spin. > BTW, are clementine images the same as the tomahawk-player has? > so in this case if clementine is accepted and in Debian I think the images > are DFSG. > please point to the sources, and look if the copyright shows them. > http://metadata.ftp-master.debian.org/changelogs/main/c/clementine/unstable_copyright > > We might even end up in an RC bug against clementine :)
Bug#807763: Looking for help to solve licence and third-party issues of the tomahawk-player package
Hi, > please ping me when the jreen is accepted, I'll go in a new review spin. Ok, I'll do it. > please point to the sources, and look if the copyright shows them. > http://metadata.ftp-master.debian.org/changelogs/main/c/clementine/unstable_copyright Tomahawk and clementine uses the company logos for the provided services/resolvers. On both software, the logos are necessary to show the music streaming source. This is a requirement to use this services. I discussed the problematic with the developers of tomahawk but they think it is not a good idea to replace them because the company only allows the use of their services if there is the company branding. It would be more critical to replace them with self-made-ones than to ship the logos. For example in the clementine sources: * clementine-1.2.3+git1354-gdaddbde+dfsg/data/icons/svg/spotify.svg * clementine-1.2.3+git1354-gdaddbde+dfsg/data/providers/soundcloud.png * clementine-1.2.3+git1354-gdaddbde+dfsg/data/providers/itunes.png * clementine-1.2.3+git1354-gdaddbde+dfsg/data/providers/echonest.png There are many more company branding in /data/providers but there is no comment in the copyright file. I think this is a very important issue. Stefan
libjreen in NEW queue
Dear mentors, my package libjreen was uploaded to the NEW queue on 09.Dec 2015. Until now the package is waiting there. Is this quite normal or is something wrong with this package? I'm asking because I want to work on the tomahawk-player package but without this dependency, I'm unable to continue. Best regards, Stefan Ahlers
Bug#807763: Looking for help to solve licence and third-party issues of the tomahawk-player package
Dear mentors, after the first review of my draft of the tomahawk-player package, I discussed the problem with the developers of the player and I commented all point of the review. Unfortunately, I didn't get any further response and so I really do not know what to do next. Because of this circumstance, I ask you to help me to solve the licence and third-party issues. I want to bring tomahawk-player to debian but at the moment, I do not know how. Kind regards, Stefan Ahlers
Bug#807763: RFS: tomahawk-player/0.8.4-1 [ITP]
Hi, here is the rest of the list. > data/www/js/html5shim.js Will be removed, because it's not necessary for the linux build. > data/www/css/font-awesome.css > data/www/css/bootstrap.css > data/www/css/animate.css This files are necessary for the integrated webserver of tomahawk. If I'm searching for this files in the debian sources I found a multiple times this files integrated in a project. > data/js/cryptojs/ > data/js/cryptojs-core.js cryptojs will be removed in the next release. Using the debian package for this release. > data/fonts/ Replace it with the debian package. Regards, Stefan Ahlers
Bug#807763: RFS: tomahawk-player/0.8.4-1 [ITP]
Hi, > I'm assuming the GMail, itunes, echonest, beats, soundcloud, spotify > and maybe playdar logos are not under a free license. I understand the problem and I discuss it with the upstream maintainer. But for the most of the companies they do not like to replace their logos if you are using their services. And so I think it is better to provide the freely distributable logos. For example the clementine debian package do it in the same way. Kind regards, Stefan Ahlers
Bug#807763: RFS: tomahawk-player/0.8.4-1 [ITP]
Hi, thank you for your review! > I would suggest removing the whole thirdparty/ directory (using > Files-Excluded in debian/copyright and repacksuffix in debian/watch) > and packaging each dependency separately. Same goes for the other > embedded copies in these files, some of them are already packaged, > others are not. I asked upstream about the thirdparty/ directory and here is the response: SPMediaKeyTap: It is only necessary for MAC. I have removed it. kdsingleapplicationguard: Will maybe be replaced with qtsingleapplication in the next release. I think it is better to package qtsingleapplication for the next tomahawk release. libportfwd: it's written in tomahawk and maintained there, the external one might or might not be updated at all. And so I would not pack this in a extra package, but miniupnp is a external dependency, now. libqnetwm: It's only used for tomahawk Qt4 and will be obsolete in the next release because tomahawk changes to Qt5. I would not pack this in a extra package. qt-certificate-addon: The source is not available and the project seems dead. And so I'm unable to replace it with a external package. qxt: I would not use a external package, because of the following statement of the libqtx developers: "Qxt will likely not work with newer Qt versions due to usage of internal api. We recommend that you pick out the parts you want instead of using the entire libqxt." I will continue checking the rest of your points soon. Kind regards, Stefan Ahlers
Bug#807763: RFS: tomahawk-player/0.8.4-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "tomahawk-player" * Package name: tomahawk-player Version : 0.8.4-1 Upstream Author : Christian Muehlhaeuser <mue...@tomahawk-player.org> * URL : http://tomahawk-player.org * License : GPL-3+ Section : libs It builds those binary packages: libtomahawk - Core libraries for tomahawk libtomahawk-dev - Core libraries for tomahawk – development files tomahawk - Multi source music player tomahawk-dbg - Multi source music player - debugging symbols To access further information about this package, please visit the following URL: http://mentors.debian.net/package/tomahawk-player Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/tomahawk-player/tomahawk-player_0.8.4-1.dsc At the moment there is only one missing dependence libjreen, which is waiting in the "new"-queue. Because of the complexity of the software and the package, I decide to ask for a revision now. I have some questions about the package. How can I handle the lintian error message "source-is-missing"? I'm unable to find the source code of this JavaScript files in the internet. Do I have to cleanup the source code and remove all windows/mac related files? Kind Regards, Stefan Ahlers
Bug#806301: RFS: libechonest/2.3.1-0.1 [NMU] -- library for communicating with The Echo Nest platform
Hi, thank you for your help. I'd checked different methods for the symbol files and I think I found a good one. I'm using the options "(arch-bits=32) (arch-bits=64)" to separate them. Thank you for your hint! This should work for all builds, which were failed to build. But I have two questions for now. Which version scheme shell I use? libechonest/2.3.1-0.2 or libechonest/2.3.1-1? Furthermore it seems someone dislike the using of transitional package (see #807507). What should I do? Deleting the transitional package or not? Stefan
Bug#806301: RFS: libechonest/2.3.1-0.1 [NMU] -- library for communicating with The Echo Nest platform
Hi, > it is fine 0.2 to keep it similar to before > true story, please delete it and upload on mentors! ok, done! Stefan
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#806301: RFS: libechonest/2.3.1-0.1 [NMU] -- library for communicating with The Echo Nest platform
Hi, > Built, don't forget next time to put a link to where the original maintainer > acked the upload, and also you can consider using -1 as Debian revision, and maybe add a > "Team Upload" (dch --team), if the maintainer is aware of the changes Thank you for signing and uploding! I read the article about "Non-maintainer upload" (https://wiki.debian.org/NonMaintainerUpload) and I thought it is correct to use -0.1. > Now Stefan as soon as the package is accepted you will need to fix the build failures (if any), and ask for a rebuild binNMU of the reverse dependencies I asked for a rebuild (#807509). I hope this is the correct way. It looks like some 64bit-based builds failed (https://buildd.debian.org/status/package.php?p=libechonest) because of incorrect symbol files. There are six symbols, which are different on 32bit and 64bit platforms. What is the best way of writing the symbol files? One file for every architecture or is there a way to combine this in one or two symbol files? Kind regards, Stefan Ahlers
Bug#806301: RFS: libechonest/2.3.1-0.1 [NMU] -- library for communicating with The Echo Nest platform
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libechonest" * Package name: libechonest Version : 2.3.1-0.1 Upstream Author : [fill in name and email of upstream] * URL : https://projects.kde.org/projects/playground/libs/libechonest * License : GPL-2.0+ Section : libs It builds those binary packages: libechonest-dbg - Qt4 library for The Echo Nest platform - debug files libechonest-dev - Qt4 library for The Echo Nest platform - development files libechonest2.1 - transitional dummy package libechonest2.3 - Qt4 library for communicating with The Echo Nest platform libechonest5-2.3 - Qt5 library for communicating with The Echo Nest platform libechonest5-dbg - Qt5 library for The Echo Nest platform - debug files libechonest5-dev - Qt5 library for The Echo Nest platform - development files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libechonest Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libe/libechonest/libechonest_2.3.1-0.1.dsc Changes since the last upload: * Non-maintainer upload. * New Upstream Release (Closes: #766594) * Better multiarch support * Start Qt5 support * Fix installation of pkgconfig files (Closes: #794811) This is a Non Maintainer Upload (NMU), which is allowed by the actual maintainer, Thomas Pierson. Because of the version change, all packages which depend on libechonest have to be rebuild against libechonest2.3. This affects clementine (https://tracker.debian.org/pkg/clementine). Regards, Stefan Ahlers
Bug#806301: RFS: libechonest/2.3.1-0.1 [NMU] -- library for communicating with The Echo Nest platform
Hi, I've rebuilt clementine against libechonest2.3 locally. Everything works fine for me. No changes are needed on the clementine package. Regards, Stefan Ahlers
Bug#804169: RFS: libjreen/1.2.0-1
Hi, I've updated libjreen. Now it uses the new jdns package. For finding it correctly, I had to patch the CMakeList.txt file. I also extend the package to build Qt5 based packages, too. I really do not know what's happened with the QA informations on http://mentors.debian.net/package/libjreen The watch file exists and the compatibility level is set. What's wrong? 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]
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, > 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, > 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#804801: RFS: libjdns/2.0.3-1 [ITP]
Hi, thank you again for your review! > 1) changelog: urgency=low would be preferred for a new package Done. > 2) control: > libqjdns-qt5-2, can't it be called libqjdns2-qt5 maybe? I know the name is not so nice, but I used the named lintian claimed out. > So I guess you can remove the "libjdns2" dependency because it should be > taken care of in shlibs:Depends(please check the built package, inside > DEBIAN/control file) Oh sorry, this is a relict of the divided package. Fixed. > 3) debian/rules: it looks really nice, maybe I would override the clean > target to remove the build directories. Done. > 4) if possible I would ask you to use MIT, the same as upstream (that way > everybody might be able to forward patches from you > without asking to relicense them) Yes, of course! I forgot the incompatibility between MIT and GPL-3+. > 5) you ship usr/bin/jdns as part of libqjdns-qt4 package, but ldd shows that > links qt5 stuff. > ldd jdns |grep Qt5 -i > libqjdns-qt5.so.2 => not found > libQt5Network.so.5 => not found > libQt5Core.so.5 => /usr/lib/i386-linux-gnu/sse2/libQt5Core.so.5 (0xf723) > > > so please choose: move in the qt5 package, move in the base package (maybe > dropping the qt stuff), or fix it somewhat else. > > this "problem" makes the qt4 package drag all the qt5 dependencies. I've fixed it by using the cmake option "-DBUILD_JDNS_TOOL=OFF" for the Qt5 build. And so only the Qt4 version will be build in a separate package called "jdns". > oh and please convert your package to multiarch (needs investigation and a > probable trivial change) > https://wiki.debian.org/Multiarch/Implementation > (be careful about usr/bin) Converted and tested. Only usr/bin/jdns is a problem and so I decided to separate the test program into another package. > lintian: > X: libqjdns-qt5-2: application-in-library-section libs usr/bin/jdns > W: libqjdns-qt5-2: binary-without-manpage usr/bin/jdns (help2man is a good > starting point) I've created and added a manpage based on the /usr/bin/jdns output. It's not the best, but I hope it's ok. > $ codespell --quiet-level=3 > ./CMakeLists.txt:91: prefered ==> preferred The codespell error only occurrs in the CMakeList and so it is not important for a normal users. Kindly Regards, Stefan
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 <micha...@last.fm> * 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
Bug#804801: RFS: libjdns/2.0.3-1 [ITP]
Hi! > according to dsc file: > d0da8d9af9e94f2e4de2943abb49ef7a72fb4fed 67767 libjdns-qt5_2.0.3.orig.tar.bz2 > d0da8d9af9e94f2e4de2943abb49ef7a72fb4fed 67767 libjdns_2.0.3.orig.tar.bz2 > > please don't create two src:libjdns* packages, but use only one to build the > two qt flavours. > (not sure if I already answered somewhere in another mail, but this should > make easier to work > on the package) Thank you for your hint. I tried to adjust the debian/rules. I've uploaded the package. Could you please review this package again? Regards, Stefan Ahlers
Misconfiguration of the bugs #804801 and #804802
Hello, because of the implementation of the Qt5 builds into the Qt4 package of libjdns, I have delete the obsolete libjdns-qt5 package on mentors.debian.net. Unfortunately some other person has closed the merged libjdns-qt5 ITP bugreport (#804802) and also the correct bugreport for the new Qt4/5 package libjdns. I'm unfamiliar with the bug report and it looks like I create more problem with the report than solving than. And so could someone please reopen and repair my bugreport #804801? Sorry for the circumstances. Kindly regards, Stefan Ahlers
Best practice to create a Qt4 and a Qt5 version of the same source.
Hello, I want to create Qt5 builds of some libraries. For example "liblastfm" (Qt4) and "liblastfm5" (Qt5). Is it allow to create a separate package for Qt5 or do I have to modify the Qt4 package? If I have to modify the Qt4 package, how can do it? Best regards, Stefan Ahlers
Bug#804802: RFS: libjdns-qt5/2.0.3-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libjdns-qt5" * Package name: libjdns-qt5 Version : 2.0.3-1 Upstream Author : Justin Karneges <jus...@affinix.com> * URL : http://delta.affinix.com/jdns/ * License : MIT Section : libs It builds those binary packages: libqjdns-qt5-2 - Simple DNS queries library - Qt5 wrapper libqjdns-qt5-dbg - Simple DNS queries library - debugging symbols libqjdns-qt5-dev - Simple DNS queries library Qt5 wrapper - development files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libjdns-qt5 Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libj/libjdns-qt5/libjdns-qt5_2.0.3-1.dsc This package contains qjdns build against Qt5. It depends on libjdns1 and libjdns-dev (provided by the qt4 package) because libjdns files do not depends on Qt. Regards, Stefan Ahlers
Bug#804801: RFS: libjdns/2.0.3-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libjdns" * Package name: libjdns Version : 2.0.3-1 Upstream Author : Justin Karneges <jus...@affinix.com> * URL : http://delta.affinix.com/jdns/ * License : MIT Section : libs It builds those binary packages: libjdns-dbg - Simple DNS queries library - debugging symbols libjdns-dev - Simple DNS queries library - development files libjdns2 - Simple DNS queries library libqjdns-qt4-2 - Simple DNS queries library - QT4 wrapper libqjdns-qt4-dev - Simple DNS queries library QT4 wrapper - development files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libjdns Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libj/libjdns/libjdns_2.0.3-1.dsc This package is necessary to build libjreen. Regards, Stefan Ahlers
Bug#804169: libjdns blocks libjreen
block 804169 by 804275 thanks Hi, libjreen is now blocked by libjdns. I've uploaded libjdns to mentors.debian.net. * Package name: libjdns Version : 2.0.3-1 Upstream Author : Justin Karneges <jus...@affinix.com> * URL : http://delta.affinix.com/jdns/ * License : MIT Section : libs It builds those binary packages: libjdns-dbg - Simple DNS queries library - debugging symbols libjdns-dev - Simple DNS queries library - development files libjdns2 - Simple DNS queries library libqjdns-dev - Simple DNS queries library QT4 wrapper - development files libqjdns-qt4-2 - Simple DNS queries library - QT4 wrapper To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libjdns Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libj/libjdns/libjdns_2.0.3-1.dsc It would be very nice, if the package could be reviewed to unblock libjreen. The package structure is inspirited by the fedora package https://apps.fedoraproject.org/packages/jdns Regards, Stefan Ahlers
Bug#804169: RFS: libjreen/1.2.0-1
Am 06.11.2015 um 13:24 schrieb Gianfranco Costamagna:
Hi,
> yes, but let assume one of the libraries above have a security bug.
> you will need to do a source only upload, instead of just fixing the
> library and rebuild the affected packages (assuming there will be one
> day more packages using the above libraries you can always ship them
> as source only libraries, e.g.
> https://packages.qa.debian.org/w/websocketpp.html (unless the
> libraries are strictly internal and makes no sense outside this
> particular project)
I understand the problem. I've taken a look into the cmake file and I
found out that libjreen does not use "icesupport" automatically.
→ option(JREEN_USE_IRISICE "Use ICE from IRIS" OFF)
On the other side libjreen is looking for a external JDNS. And so it
would be really better to create a libjdns package for debian, or?
> I know, but you are Debian-patching an upstream issue. you are
> workarounding it, not fixing (even if it works). I would appreciate a
> proper fix and a patch sent upstream (in the meanwhile you can of
> course use this solution, It came in my mind, but I didn't suggest it
> because I don't think it is the best way)
Please correct me if I'm wrong, but I do not agree in your opinion
because other distributions uses another way of multiarch support.
For example openSUSE, they uses the path "/usr/lib64/libjreen.so.1". And
so I think it is impossible to upstream a patch, which changes
"DESTINATION lib${LIB_SUFFIX}" into "DESTINATION lib/${LIB_SUFFIX}"
because this would break the support for the other distributions.
I really do not know how to fix it to make it work for all
distributions. Any ideas?
> well, you can send patches upstream, it is fine by me to avoid debian
> patches as long as the mistakes are in the code and not seen by normal
> users (I can also accept a mistake in some obscure code that is mostly
> unreachable, but I would bother about sending bugs upstream and fix in
> a later release) cheers, G.
I've sent the the codespelling patch to upstream.
The cppcheck errors is only a "Uninitialized variable: c". I think this
is not critical.
Most of the "$ grep -riE 'fixme|todo|hack|xxx' ." errors occurs on
icesupport and this is unused. The rest is not critical, too.
Same on licensecheck. It does not affect this package.
Cheers,
Stefan
Bug#804169: RFS: libjreen/1.2.0-1
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "libjreen" * Package name: libjreen Version : 1.2.0-1 Upstream Author : Ruslan Nigmatullin <euroeles...@yandex.ru> * URL : https://github.com/euroelessar/jreen * License : GPL-2+ Section : libs It builds those binary packages: libjreen-dbg - Qt XMPP library - debugging symbols libjreen-dev - Qt XMPP library - development files libjreen1 - Qt XMPP library To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libjreen Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libj/libjreen/libjreen_1.2.0-1.dsc I'm the maintainer of the tomahawk PPA (https://launchpad.net/~tomahawk) and I want do bring tomahawk into debian but it's blocked by libjreen. This package based on the package of the ubuntu sources but I've added multiarch support. (http://packages.ubuntu.com/search?suite=default=all=any=names=libjreen) Regards, Stefan Ahlers (https://launchpad.net/~justin-time)
Bug#804169: RFS: libjreen/1.2.0-1
Hi, thanks for your fast reply! 1) done 2) done 3) Sorry, I do not understand how to pack the 3rdparty libraries separately. The libraries are not compiled and Jreen only needs them for compile itself and they are not shipped in the package afterwards. 4) done – I've change your suggestion a bit to avoid patching cmake by using a "/" before "$(DEB_HOST_MULTIARCH)" → dh_auto_configure -- -DLIB_SUFFIX=/$(DEB_HOST_MULTIARCH) It works! 5) The file ./alttoolbar_rb3compat.py: does not exists in the source. It looks like you mix me up with someone else, maybe the maintainer of the "rhythmbox-plugin-alternative-toolbar"? Ok, I've checked up the spelling and code errors and I can confirm them, but I'm not the developer of jreen. Do I have to patch this mistakes as maintainer, too? Most of the errors occurs at the 3rdparty tool "icesupport". Regards, Stefan Ahlers
