Bug#1005649: O: liblastfm - Last.fm fingerprinting library

for the circumstances. With kind regards, Stefan Ahlers

Bug#984114: liblastfm: diff for NMU version 1.0.9-1.2

Hi Flo, I apologize for the very long delay. Thank you for preparing an NMU. Due to my private situation I'm unable to continue maintaining this package. Therefore, where is no reason to delay the upload any longer. Cheers, Sefan Am 13.02.22 um 08:25 schrieb Florian Ernst: Dear

Bug#1005647: O: libjdns - command-line tool to test functionality

for the circumstances. With kind regards, Stefan Ahlers

Bug#1005648: O: jreen -- powerful Jabber/XMPP library

for the circumstances. With kind regards, Stefan Ahlers

Bug#827616: RFS: libjreen/1.2.0-2 - bugfix

out 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#827585: jreen: FTBFS: stanzaextension.h:31:23: fatal error: QMetaTypeId: No such file or directory

Owner: stef.ahl...@t-online.de Hi, thank you for reporting this bug. This is a known upstream bug (https://github.com/euroelessar/jreen/issues/40). I'll adopt the fedora patch to fix it. Kind regards, Stefan Ahlers

Bug#807763: Looking for help to solve licence and third-party issues of the tomahawk-player package

bs, > 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

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 c

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

Bug#807763: Looking for help to solve licence and third-party issues of the tomahawk-player package

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#805087: Please change the qt5 suffix from -qt5 to 5

Hi, the problem was a spelling mistake in the symbol file for the qt5 build. Now building and using of this package works fine. Kind regards, Stefan

Bug#805087: Please change the qt5 suffix from -qt5 to 5

Hi, I'm wrong. There is a error in the dependencies. I've built the tomahawk package successful, but I'm unable to install it because the package is looking for a dependencies called libquazip15 instead of libquazip5-1. I really do not know what's wrong, the control files of libquazip and

Bug#778768: Please install FindQuaZip.cmake

, Stefan Ahlers

Bug#805087: Please change the qt5 suffix from -qt5 to 5

Hi Andreas, I've updated the debian files and I decided to use quazip 0.7.1 and patch the CMakeLists.text files instead of using a development release. Furthermore, I was not able to install the FindQuaZip.cmake file, because it is not allowed to ship a "Find module". (lintian error:

Bug#805087: Please change the qt5 suffix from -qt5 to 5

Hi Andreas, > Either this or we use common VCS. Please tick-mark your prefered option > > [ ] I'll add you to Debian Med team and you commit to SVN > [ ] I'll add you to Debian Med team and migrate the package to Git > [ ] I move the package to collab-maint Git > [ ] I move the package

Bug#805087: Please change the qt5 suffix from -qt5 to 5

Hi Andreas, > I added the patch from SVN as quilt patch[1] and tried to trigger this > in debian/rules[2] - but the latter has no effect. It looks like there are more than one changes on the CMake file since the last release. Sorry for that confusion. > I also have no idea where to install

Bug#805087: Please change the qt5 suffix from -qt5 to 5

, Stefan Ahlers

Bug#807763: RFS: tomahawk-player/0.8.4-1 [ITP]

th the debian package. Regards, Stefan Ahlers

Bug#807763: RFS: tomahawk-player/0.8.4-1 [ITP]

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]

xternal 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 so

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

Hi, I'm a little bit confused about the sh4 build of libechonest. It failed because there appears a new symbol: (c++)"QDebug::operator<<(QByteArray const&)@Base" 2.3.1-0.3 on all architectures there is the following Symbol: (c++)"QDebug::operator<<(QString const&)@Base" 2.3.1 Why does sh4

Bug#649287: Intend to package tomahawk-player

retitle 649287 ITP: tomahawk-player -- multi-source social media player owner 649287 ! thanks Hi! After updating libechonest and packaging libjreen, which is still in the NEW-queue, it is time to package tomahawk-player! Kind regards, Stefan Ahlers

Bug#807763: RFS: tomahawk-player/0.8.4-1 [ITP]

w 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#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

+1,17 @@ +libechonest (2.3.1-0.3) unstable; urgency=low + + * Non-maintainer upload, with maintainer permission. + * Fix symbols again. + * Drop bogus libechonest2.1 (Closes: #807507) + + -- Stefan Ahlers <stef.ahl...@t-online.de> Fri, 11 Dec 2015 09:00:00 +0100 + libechonest (2.3.1-0.2) unstable;

Bug#807507: removal of libechonest2.1

Hello, > which, besides a date from the future, lacks a vital line: > * Drop bogus libechonest2.1 (Closes: #807507) > > Thus, I'm hereby closing this manually. > > 2.3.1-0.1 does break its users, but fortunately there's only one such user, > clementine. I've just requested a rebuild of it

Bug#807509: nmu: clementine_1.2.3+git1354-gdaddbde+dfsg-1

Hi, > It'd be good to get libechonest fixed: > yes, I'm working on it! Thank you for your help! Stefan

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

Hi, > anyway, I still get issues with armhf and armel, but this time they seem to > be related > to one symbols wrong copy-pasted on line 249 > _ZN8Echonest4Term9setWeightEf@Base instead of > _ZN8Echonest4Term12setFrequencyEf@Base Hmm, it looks like I'm too unconsecrated. Fixed. > and

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

Hi, first of all, thank you for your help, both of you! I also learned a lot from this experience. > e.g. a symbol was leftover in symbols file: > + _ZN8Echonest12AudioSummary12setTimestampEf@Base 2.1.0 > and was preventing amd64 and i386 builds to succeed. You are right, it seems that I have

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

Hi Adrian, thank you for your fast reply! > In any case, the common method that I have been using so far was to use > a common symbols file but specify the architecture list with "arch=amd64 > arm64" and so on. This has been supported for a long time already > and works with all currently

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#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

Bug#807507: libechonest2.1: Missing libechonest.so.2.1

But in short: transitiong from the old SONAME to the > new > SONAME is done via rebuilds of the rev deps, not via the old library package > pulling in the new one. Oh ok, now I understand it! Thank you for your hint! I'll fix it. Kindly regards, Stefan Ahlers

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

regards, Stefan Ahlers

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

Bug#807507: libechonest2.1: Missing libechonest.so.2.1

Hi, libechonest2.3.1 provides libechonest.so.2.3 and so clementine has to be rebuild against libechonest2.3, after rebuilding, clementine will work correctly. Kind regards, Stefan Ahlers

Bug#807509: nmu: clementine_1.2.3+git1354-gdaddbde+dfsg-1

"libechonest.so.2.1" changed to "libechonest.so.2.3" Please rebuild clementine against libechonest2.3 2.3.1-0.1 to bump its dependency on libechonest2.3. nmu clementine_1.2.3+git1354-gdaddbde+dfsg-1 . ANY . -m 'Rebuild against libechonest2.3 to correct dependency' Thanks. Kind regards, Stefan Ahlers

Bug#807507: libechonest2.1: Missing libechonest.so.2.1

Hi, > You need to drop libechonest2.1 from the package. An empty libechonest2.1 > depending on libechonest2.3 is wrong. libechonest2.1 is a transitional dummy package (https://wiki.debian.org/Renaming_a_Package). And so it should be correct that this package is empty. Regards, Stefan Ahlers

Bug#806301: RFS: libechonest/2.3.1-0.1 [NMU] -- library for communicating with The Echo Nest platform

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

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

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

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

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

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

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

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

Bug#804801: RFS: libjdns/2.0.3-1 [ITP]

t; 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

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

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#805081: Please update liblastfm to 1.0.9

Hi! > Hmm, I'm not sure how happy the ftp masters will be to have two exact > copies of a source tarball just to simplify debian/rules, but I guess > that's between you and them (or you and your sponsor). You are right! I have to this in one package. Thank you for your hint! > But yes, please take

Bug#805081: Please update liblastfm to 1.0.9

Hi, thank you for your reply! > This is a little complicated because Amarok and Clementine both need > liblastfm compiled with Qt4. > > It looks like the latest version 1.1.0 (as yet untagged) allows for > coinstallation of the -dev files as well. So it seems like the best way > forward is to

Bug#805077: ITP: liblastfm5 -- Last.fm web services library - Qt5 build

Package: wnpp Severity: wishlist Owner: Stefan Ahlers <stef.ahl...@t-online.de> * Package name: liblastfm5 Version : 1.0.9 Upstream Author : Michael Coffey <micha...@last.fm> * URL : http://www.last.fm/ * License : GPL-3+ Programming L

Bug#805087: Please change the qt5 suffix from -qt5 to 5

tomahawk-player (http://tomahawk-player.org) expect the libquazip5.so and they do not work with libquazip-qt5.so Kindly regards, Stefan Ahlers (https://launchpad.net/~justin-time)

Bug#805081: Please update liblastfm to 1.0.9

Package: liblastfm Version: 1.0.8-3 Severity: wishlist Dear Maintainer, please update liblastfm to 1.0.9. The new release adds Qt5 compatibility to liblastfm. Friendly regards, Stefan Ahlers

Bug#805080: Please create a Qt5 build of liblastfm

with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libl/liblastfm5/liblastfm5_1.0.9-1.dsc Friendly regards, Stefan Ahlers (https://launchpad.net/~justin-time)

Bug#766594: libechonest and libechonest-qt5 updated in Ubuntu PPA

/ubuntu/libechonest/+packages I would be very happy to work together with you to push libechonest2.3 as Qt4 and Qt5 build into the debian sources. Kindly regards, Stefan Ahlers

Bug#804275: Qt5 Version of libjdns

epends on the libjdns2 package, which is packaged in libjdns (Qt4) because it does not depends on Qt. Regards, Stefan Ahlers

Bug#804801: RFS: libjdns/2.0.3-1 [ITP]

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#804802: RFS: libjdns-qt5/2.0.3-1 [ITP]

-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#804169: libjdns blocks libjreen

get -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#804275: ITP: libjdns -- simple DNS queries library

Package: wnpp Severity: wishlist Owner: ! * Package name: libjdns Version : 2.0.3 Upstream Author : Justin Karneges * URL : http://delta.affinix.com/jdns/ * License : MIT Programming Lang: C Description : Simple

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

Bug#648668: New maintainer for libjreen

into debian to unblock tomahawk. Regards, Stefan Ahlers

Bug#804169: RFS: libjreen/1.2.0-1

y=names=libjreen) Regards, Stefan Ahlers (https://launchpad.net/~justin-time)

Bug#804169: RFS: libjreen/1.2.0-1

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

Bug#649287: tomahawk-player -- multi-source social media player

/bugreport.cgi?bug=766594) * #648668 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648668) Tomahawk does not depend on qtweetlib any longer and so it is not blocked by #700028 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700028) Kindly regards, Stefan Ahlers https://launchpad.net/~justin

Bug#766594: libechonest-dev: Update to 2.3.1 and create a Qt5 build

bechonest/+packages> Kindly regards, Stefan Ahlers