Bug#1040036: yajl: CVE-2017-16516 CVE-2022-24795
On 07/01/23 04:03 AM, Tobias Frost wrote: > Source: yajl > Severity: important > Tags: security upstream > X-Debbugs-Cc: Debian Security Team > > After preparing the LTS upload of yajl I've seen the following issues in > the upstream github issue tracker: > > CVE-2017-16516 [1] portential buffer overread: A JSON file can cause denial of > service. > > CVE-2022-24795 [2] potential integer overflow which can lead to subsequent > heap > memory corruption when dealing with large (~2GB) input > > The upstream issue tracker also indicates that there might be other > vulnerabilies > (without CVEs or unknown CVEs), but I did not investiage further: > https://github.com/lloyd/yajl/issues/206 (double free) > https://github.com/lloyd/yajl/issues/204 (Uninitialized memory reads and > out-of-bound) > > It seems that the code is unmaintained upstream. It might be a good idea to > evaluate > if any of the forks are more active and whether Debian should move there. > > Cheers, > -- > tobi > > [1] https://github.com/lloyd/yajl/issues/248 > Potential fix: > https://github.com/brianmario/yajl-ruby/commit/a8ca8f476655adaa187eedc60bdc770fff3c51ce > > [2] https://github.com/lloyd/yajl/issues/239 > Potential fix (howver the use of abort() can cause issues.) > https://github.com/lloyd/yajl/pull/240 Hello, I've something nearly ready for upload, but it would be good to get a second pair of eyes on it: https://github.com/jstamp/yajl/commits/master CVE-2017-16516 looks fixed with the patch that you linked to. CVE-2022-24795 looks fixed with https://github.com/lloyd/yajl/pull/240 As you said, pull 240's use of abort() can cause problems of its own, but if I understand the discussion right, there aren't other options without a significant rewrite to yajl. The other two potential fixes also use abort() or assert(): https://github.com/robohack/yajl/commit/7d8adb408842a2d19e6a48fccf2725feb333937a https://github.com/robohack/yajl/commit/166b384aec1cf304859d69f03e42c3ab85c34858 https://github.com/lloyd/yajl/pull/242/commits/d3a528c788ba9e531fab91db41d3a833c54da325 You also mentioned the following issues: https://github.com/lloyd/yajl/issues/204 https://github.com/lloyd/yajl/issues/206 I can reproduce the reporter's errors in valgrind using yajl's json_reformat in version 1.0.12, but all appeared well when I tested with version 2.1.0. Those issues only seem to affect 1.x The same applied to issue 205: https://github.com/lloyd/yajl/issues/205 If all this looks sensible to you, I'll head over to mentors for a sponsor. John
Bug#1040044: yajl: Move to better maintained fork
On 07/01/23 09:33 AM, Bastien Roucariès wrote: > Dear Maintainer, > > yajl upstream seems to be dead > > Could you please move to https://github.com/openEuler-BaseService/yajl > > Thanks > > rouca Thanks. I've been looking into this a bit today. OpenEuler-BaseService did invite others to join their project: https://github.com/lloyd/yajl/issues/243 However, I'm not seeing much activity there. Their most recent commit was over a year ago, and the differences between their fork and current upstream amount to a few small patches. The fork below seems more actively developed, and the committer seems active in current upstream's issue reports, but a lot of work seems focused on moving to BSDMake: https://github.com/robohack/yajl There are a lot of forks, each doing their own thing. But unless one really takes the lead, I'm not sure what benefit there would be in switching upstreams. Am I missing something? John Stamp
Bug#1040039: yajl: diff for NMU version 2.1.0-3.1
On 07/01/23 05:54 AM, Tobias Frost wrote: > Dear maintainer, > > I've prepared an NMU for yajl (versioned as 2.1.0-3.1) and > uploaded it to DELAYED/10. Please feel free to tell me if I > should delay it longer. > > Regards. Please don't delay. This package has been off my radar for a long time, so this is greatly appreciated. Between this, #1040036, and #1040044 I've a lot to sort out. John
Bug#859054: libpam-ssh: Please migrate to openssl1.1 in buster
On 05/22/18 08:52 PM, Jerome BENOIT wrote:
> Hello,
>
>
>
> On 22/05/18 23:52, Moritz Muehlenhoff wrote:
> > Hi Jerome,
> >
> > On Fri, Oct 13, 2017 at 07:05:26PM +0400, Jerome BENOIT wrote:
> >> Dear Sebastian, thanks for your warning.
> >>
> >> The amount of change might be too heavy for me.
> >> Second, pam_ssh seems no more maintained.
> >>
> >> I have just contacted the upstream maintainer.
> >
> > Did you get a reply?
>
> No.
>
> I will have a look if time permit.
> And, of course, any patch is welcome.
>
> Cheers,
> Jerome
OpenSUSE has an OpenSSL 1.1 patch in their package:
https://build.opensuse.org/package/view_file/openSUSE:Factory/pam_ssh/pam_ssh-openssl11.patch
Changelog here:
https://build.opensuse.org/request/show/547009
I'm attaching the patch. It will try to modify `configure' which isn't
in Debian's source tarball, but if you remove that bit, it applies
cleanly. It seems to work OK on my locally-built package.
John
===
Index: pam_ssh-2.1/cipher.c
===
--- pam_ssh-2.1.orig/cipher.c 2015-05-03 13:30:39.0 +0200
+++ pam_ssh-2.1/cipher.c 2017-11-30 15:31:05.770390639 +0100
@@ -326,26 +326,26 @@ cipher_init(struct sshcipher_ctx *cc, co
return SSH_ERR_INVALID_ARGUMENT;
#else
type = (*cipher->evptype)();
- EVP_CIPHER_CTX_init(>evp);
- if (EVP_CipherInit(>evp, type, NULL, (u_char *)iv,
+ cc->evp = EVP_CIPHER_CTX_new();
+ if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv,
(do_encrypt == CIPHER_ENCRYPT)) == 0) {
ret = SSH_ERR_LIBCRYPTO_ERROR;
goto bad;
}
if (cipher_authlen(cipher) &&
- !EVP_CIPHER_CTX_ctrl(>evp, EVP_CTRL_GCM_SET_IV_FIXED,
+ !EVP_CIPHER_CTX_ctrl(cc->evp, EVP_CTRL_GCM_SET_IV_FIXED,
-1, (u_char *)iv)) {
ret = SSH_ERR_LIBCRYPTO_ERROR;
goto bad;
}
- klen = EVP_CIPHER_CTX_key_length(>evp);
+ klen = EVP_CIPHER_CTX_key_length(cc->evp);
if (klen > 0 && keylen != (u_int)klen) {
- if (EVP_CIPHER_CTX_set_key_length(>evp, keylen) == 0) {
+ if (EVP_CIPHER_CTX_set_key_length(cc->evp, keylen) == 0) {
ret = SSH_ERR_LIBCRYPTO_ERROR;
goto bad;
}
}
- if (EVP_CipherInit(>evp, NULL, (u_char *)key, NULL, -1) == 0) {
+ if (EVP_CipherInit(cc->evp, NULL, (u_char *)key, NULL, -1) == 0) {
ret = SSH_ERR_LIBCRYPTO_ERROR;
goto bad;
}
@@ -358,14 +358,14 @@ cipher_init(struct sshcipher_ctx *cc, co
ret = SSH_ERR_ALLOC_FAIL;
goto bad;
}
- ret = EVP_Cipher(>evp, discard, junk, cipher->discard_len);
+ ret = EVP_Cipher(cc->evp, discard, junk, cipher->discard_len);
explicit_bzero(discard, cipher->discard_len);
free(junk);
free(discard);
if (ret != 1) {
ret = SSH_ERR_LIBCRYPTO_ERROR;
bad:
- EVP_CIPHER_CTX_cleanup(>evp);
+ EVP_CIPHER_CTX_cleanup(cc->evp);
return ret;
}
}
@@ -412,33 +412,33 @@ cipher_crypt(struct sshcipher_ctx *cc, u
if (authlen != cipher_authlen(cc->cipher))
return SSH_ERR_INVALID_ARGUMENT;
/* increment IV */
- if (!EVP_CIPHER_CTX_ctrl(>evp, EVP_CTRL_GCM_IV_GEN,
+ if (!EVP_CIPHER_CTX_ctrl(cc->evp, EVP_CTRL_GCM_IV_GEN,
1, lastiv))
return SSH_ERR_LIBCRYPTO_ERROR;
/* set tag on decyption */
if (!cc->encrypt &&
- !EVP_CIPHER_CTX_ctrl(>evp, EVP_CTRL_GCM_SET_TAG,
+ !EVP_CIPHER_CTX_ctrl(cc->evp, EVP_CTRL_GCM_SET_TAG,
authlen, (u_char *)src + aadlen + len))
return SSH_ERR_LIBCRYPTO_ERROR;
}
if (aadlen) {
if (authlen &&
- EVP_Cipher(>evp, NULL, (u_char *)src, aadlen) < 0)
+ EVP_Cipher(cc->evp, NULL, (u_char *)src, aadlen) < 0)
return SSH_ERR_LIBCRYPTO_ERROR;
memcpy(dest, src, aadlen);
}
if (len % cc->cipher->block_size)
return SSH_ERR_INVALID_ARGUMENT;
- if (EVP_Cipher(>evp, dest + aadlen, (u_char *)src + aadlen,
+ if (EVP_Cipher(cc->evp, dest + aadlen, (u_char *)src + aadlen,
len) < 0)
return SSH_ERR_LIBCRYPTO_ERROR;
if (authlen) {
/* compute tag (on encrypt) or verify tag (on decrypt) */
- if (EVP_Cipher(>evp, NULL, NULL, 0) < 0)
+ if (EVP_Cipher(cc->evp, NULL, NULL, 0) < 0)
return cc->encrypt ?
SSH_ERR_LIBCRYPTO_ERROR : SSH_ERR_MAC_INVALID;
if (cc->encrypt &&
- !EVP_CIPHER_CTX_ctrl(>evp, EVP_CTRL_GCM_GET_TAG,
+ !EVP_CIPHER_CTX_ctrl(cc->evp, EVP_CTRL_GCM_GET_TAG,
authlen, dest + aadlen + len))
return SSH_ERR_LIBCRYPTO_ERROR;
}
@@ -471,7 +471,7 @@ cipher_cleanup(struct sshcipher_ctx *cc)
else if ((cc->cipher->flags & CFLAG_AESCTR) != 0)
explicit_bzero(>ac_ctx, sizeof(cc->ac_ctx));
#ifdef WITH_OPENSSL
- else if (EVP_CIPHER_CTX_cleanup(>evp) == 0)
+ else if (EVP_CIPHER_CTX_cleanup(cc->evp) == 0)
return SSH_ERR_LIBCRYPTO_ERROR;
#endif
return 0;
@@ -518,7 +518,7 @@ cipher_get_keyiv_len(const struct sshcip
ivlen = 0;
#ifdef WITH_OPENSSL
else
- ivlen = EVP_CIPHER_CTX_iv_length(>evp);
+ ivlen = EVP_CIPHER_CTX_iv_length(cc->evp);
#endif /* WITH_OPENSSL */
return (ivlen);
}
@@ -544,7 +544,7 @@
Bug#910118: RFS: yajl/2.1.0-3
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "yajl" Package name: yajl Version : 2.1.0-3 Upstream Author : Lloyd Hilaiel URL : https://github.com/lloyd/yajl License : ISC Section : libs It builds those binary packages: libyajl-dev - Yet Another JSON Library - development files libyajl-doc - Yet Another JSON Library - library documentation libyajl2 - Yet Another JSON Library yajl-tools - Yet Another JSON Library - tools To access further information about this package, please visit the following URL: https://mentors.debian.net/package/yajl Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/y/yajl/yajl_2.1.0-3.dsc More information about yajl can be obtained from https://github.com/lloyd/yajl Changes since the last upload: [ Jelmer Vernooij ] * Use secure URI in Vcs control header. * Use secure copyright file specification URI. [ John Stamp ] * Bump debhelper compat to 11. - Remove unneeded --parallel argument in debian/rules. * Transition to automatic debug packages. * Bump Standards-Version to 4.2.1 - Add Rules-Requires-Root field, and set it to "no". Regards, John Stamp
Bug#824204: libyajl-dev: Static linking doesn't work
Hi George, It looks like it's just a problem with the link order of the sample command that you provided. Can you confirm that this works? gcc -o p parse_config.c -lyajl_s John
Bug#805081: Please update liblastfm to 1.0.9
On Mon, Nov 16, 2015 at 03:04:44AM PST, Stefan Ahlers wrote: > 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 upgrade to that version, and then have that source package > > build both the Qt4 and Qt5 binaries. It's doable, but you'd need to do > > more by hand in debian/rules. > Of course, I will not drop the Qt4 support. My idea is to create two > separate packages. One package called "liblastfm" is Qt4 based and the > other package "liblastfm5" is Qt5 based. And so it is very easy to > handle the debian files. > > My current Qt5 package (http://mentors.debian.net/package/liblastfm5) is > patched for coinstallation. And so it is possible to install both > package on the same system without a collision. > > Would you be interested in taking over maintenance? > Yes, I'm interested but I'm not a debian maintainer yet. I'm only a > maintainer for the ubuntu PPA of tomahawk and I started my work on > debian directly only a few weeks ago. And so I need a sponsoring for > uploading at the moment. > > I could take over maintenance, update the Qt4 version of liblastfm and > uploading it to mentors.debian.net, if you wish. > > Stefan 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). But yes, please take over maintenance of liblastfm. It'd be good to have it in the hands of someone who feels more invested in the package. John
Bug#805081: Please update liblastfm to 1.0.9
Hi, 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 upgrade to that version, and then have that source package build both the Qt4 and Qt5 binaries. It's doable, but you'd need to do more by hand in debian/rules. It's been a while since this package mattered much to me. Would you be interested in taking over maintenance? John
Bug#794493: Annual ping for John Stamp
Package: debian-maintainers Severity: normal This is my annual ping as a Debian Maintainer. I am still actively maintaining packages. Regards, John Stamp signature.asc Description: Digital signature
Bug#760318: override: yajl:libs/optional
Package: ftp.debian.org Severity: normal Hello, Please change the override for yajl to optional. See #759151 for more info. John Stamp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759151: RFS: yajl/2.1.0-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package yajl Package name: yajl Version : 2.1.0-2 Upstream Author : Lloyd Hilaiel m...@lloyd.io URL : http://lloyd.github.com/yajl/ License : ISC Section : libs It builds those binary packages: libyajl-dev - Yet Another JSON Library - development files libyajl-doc - Yet Another JSON Library - library documentation libyajl2 - Yet Another JSON Library libyajl2-dbg - Yet Another JSON Library - debugging symbols yajl-tools - Yet Another JSON Library - tools To access further information about this package, please visit the following URL: http://mentors.debian.net/package/yajl Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/y/yajl/yajl_2.1.0-2.dsc More information about yajl can be obtained from http://lloyd.github.io/yajl/ Changes since the last upload: * Change priority to optional (Closes: #758958) Regards, John Stamp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759086: Annual ping for John Stamp
Package: debian-maintainers Severity: normal This is my annual ping as a Debian Maintainer. I am still actively maintaining packages. Regards, John Stamp signature.asc Description: Digital signature
Bug#746319: RM: lastfm -- ROM; obsolete, dead upstream
Package: ftp.debian.org Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Please remove lastfm from sid. It primarily acts as a client for Last.fm's music streaming service. However, the company discontinued streaming as of April 28: http://www.last.fm/announcements/subscriptions2014 This makes the package obsolete. And since it has not seen any upstream activity for the last 3.5 years while they tried to develop a new client, it should be considered dead as well. Regards, John Stamp -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJTXuGJAAoJEBwB9EPJyTxayjQP/2ccETVFUwk9VACTI/YgQoOq gvhbywzuDY7OQ/Le1YDHQpaZfNZpQwauISibyz10QfSZxgua/Gtsv4rk+dc52r05 xuxueBwF/BoIyXZUToIbcTMU2YLdZh/YuskNIxr3uM/RM4z8qqZ8riPmGTmHESzK +sT/MxBCLzAeVT9hJDhydxKETQ2sVu9NBmhL96nYKFjyiFmx6b5BAn1RRld4hd+k 7kguR/Gqyoql5oZr38qX6FdjL/z6Nb6J9efeLHeiEKLQ+TYn5/088rfSrEyhBqsP fv5dG9YsM0gAMTep9Ur1Bzq4Pg40OEP7O2fV6bTicpMyDXC2dHPDc3cCkjrCj3pD lsjSeGTDe0Z2TswZvUKh8bkma0GFfkZvb68YCFpHU9h4zwKsKvym6go7ivLIqoXk Fhl5jlik8ugfPWEx4miEU2CxMerAXzRptxNGEr//fbtLiGRJ1XbGkTC0hfRlmCs0 W8N8opbP5v1TbnMqoA1yWENvFEFdq43aLYToCgSI9NYWZHPclCGBItUqhyYihiF6 xyR1FaK4wUpMXfqOdYA8PKue/xEB8rCVAMU40QgbE4XJ5zSGvNY8UJdAbDVwhoA5 d4P5M2AVg0TntVof498H3ZCOKSC6txOl7foTfO2wI2GBzuD0fk/LQxh+LjzsuUjt ilCYgLzYC87URlgaqACV =36rY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#721785: Annual ping for John Stamp
Package: debian-maintainers Severity: normal This is my annual ping. I am still maintaining my packages in Debian. Regards, John Stamp signature.asc Description: Digital signature
Bug#712082: libyajl2: i386 lib installed in /usr/lib/i486-linux-gnu, should be i386-linux-gnu
tags 712082 pending thanks I see what happened. I screwed up the multiarch tuple when configuring cmake. I'll have a fixed package uploaded to mentors by tonight. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#702357: yajl: support for multiarch based cross compile
Thank you! My tentative plan is to wait until after the freeze. Or did you really need it in experimental before then? John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699752: lastfm: Update package please
Don't worry; I'm working on getting it packaged. The package, however, will most likely be named lastfm-scrobbler. See the ITP here: #537200. Among other things, I need to put in a good bit of work to create a dfsg clean tarball. But there's no way that this will get into wheezy. The new scrobbler is a completely new codebase, and Last.fm is still shaking the bugs out of it. I wouldn't want such an untested version in a stable release, and if I asked the release team for an exception, they'd yell at me for wasting their time. John On Mon, Feb 04, 2013 at 02:56:32PM +, Peter Tynan wrote: Package: lastfm Version: 1:1.5.4.27091+dfsg1-1 Severity: wishlist Dear Maintainer, Could you please think about updating this package to the latest release (and if possible obtain an exemption from the Wheezy freeze). At the time of writing the current upstream release is 2.1.30 Peter Tynan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697900: Pre-Approval for yajl 2.0.4-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hello,
I would like to upload yajl 2.0.4-3 to fix #697380. The proposed diff
is attached.
The package is already built with multiarch support, but I forgot to add
the Multi-Arch field for libyajl2. Is this OK given the current unblock
policy?
John Stamp
diff --git a/debian/changelog b/debian/changelog
index 86e5ca3..7514f2d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+yajl (2.0.4-3) unstable; urgency=low
+
+ * Add missing Multi-Arch field for libyajl2 (Closes: #697380)
+
+ -- John Stamp jst...@users.sourceforge.net Thu, 10 Jan 2013 16:44:23 -0800
+
yajl (2.0.4-2) unstable; urgency=low
* Upload to unstable.
diff --git a/debian/control b/debian/control
index eb841c8..13d213a 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Vcs-Git: git://github.com/jstamp/yajl.git
Package: libyajl2
Architecture: any
+Multi-Arch: same
Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Yet Another JSON Library
Bug#696175: lastfm: add MPRIS2 support
It won't happen with this version of the client. It's pretty much been in maintenance mode since about 2009. However, upstream is working on a new version here: https://github.com/lastfm/lastfm-desktop While their main focus is Win/Mac, they do support Linux. They're also friendly and open to pull requests. If you're not willing to add the feature yourself, I'll put it on my TODO list, but it may take longer :) John On Mon, Dec 17, 2012 at 04:52:15PM +0100, Martin Dosch wrote: Package: lastfm Version: 1:1.5.4.27091+dfsg1-1 Severity: wishlist Dear Maintainer, please consider adding MPRIS2 support to lastfm. It would be much more comfortable if it could be controlled by the great media player indicator plugin for gnome shell. Best regards Martin -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (900, 'testing'), (600, 'unstable'), (550, 'experimental'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lastfm depends on: ii gconf2 3.2.5-1+build1 ii libasound2 1.0.25-4 ii libc6 2.13-37 ii libgcc1 1:4.7.2-4 ii libgpod40.8.2-7 ii libmad0 0.15.1b-7 ii libqt4-network 4:4.8.2+dfsg-5 ii libqt4-sql 4:4.8.2+dfsg-5 ii libqt4-xml 4:4.8.2+dfsg-5 ii libqtcore4 4:4.8.2+dfsg-5 ii libqtgui4 4:4.8.2+dfsg-5 ii libstdc++6 4.7.2-4 ii libx11-62:1.5.0-1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages lastfm recommends: ii elinks [www-browser] 0.12~pre5-9 ii iceweasel [www-browser] 17.0.1-1 ii libqt4-sql-sqlite4:4.8.2+dfsg-5 ii w3m [www-browser]0.5.3-8 lastfm suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691294: phonon-backend-vlc: Segfaults on program close; fixed in upstream a8cda824
Package: phonon-backend-vlc Version: 0.6.0-1 Severity: normal Hi, I've been testing the Last.fm scrobbling client located here: https://github.com/lastfm/lastfm-desktop But if I use phonon's vlc backend, the client consistently segfaults on exit. The relevant snippet from valgrind has this: ==9018== Invalid read of size 8 ==9018==at 0x26653959: QListPhonon::VLC::SinkNode*::removeAll(Phonon::VLC::SinkNode* const) (qlist.h:725) ==9018==by 0x26653332: Phonon::VLC::MediaObject::removeSink(Phonon::VLC::SinkNode*) (mediaobject.cpp:737) ==9018==by 0x26654C00: Phonon::VLC::SinkNode::disconnectFromMediaObject(Phonon::VLC::MediaObject*) (sinknode.cpp:66) ==9018==by 0x266391DB: Phonon::VLC::AudioOutput::~AudioOutput() (audiooutput.cpp:44) ==9018==by 0x26639218: Phonon::VLC::AudioOutput::~AudioOutput() (audiooutput.cpp:46) ==9018==by 0x7DE1433: Phonon::MediaNodePrivate::deleteBackendObject() (medianode.cpp:81) ==9018==by 0x7DCDCEF: Phonon::FactoryPrivate::~FactoryPrivate() (factory.cpp:236) ==9018==by 0x7DCDFD8: Phonon::FactoryPrivate::~FactoryPrivate() (factory.cpp:246) ==9018==by 0x988BEA7: qt_call_post_routines() (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.2) ==9018==by 0x88FC57D: QApplication::~QApplication() (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.2) ==9018==by 0x429F28: main (main.cpp:97) ==9018== Address 0x2526d5c8 is 168 bytes inside a block of size 208 free'd ==9018==at 0x4C279DC: operator delete(void*) (vg_replace_malloc.c:457) ==9018==by 0x7DE1433: Phonon::MediaNodePrivate::deleteBackendObject() (medianode.cpp:81) ==9018==by 0x7DCDCEF: Phonon::FactoryPrivate::~FactoryPrivate() (factory.cpp:236) ==9018==by 0x7DCDFD8: Phonon::FactoryPrivate::~FactoryPrivate() (factory.cpp:246) ==9018==by 0x988BEA7: qt_call_post_routines() (in /usr/lib/x86_64-linux-gnu/libQtCore.so.4.8.2) ==9018==by 0x88FC57D: QApplication::~QApplication() (in /usr/lib/x86_64-linux-gnu/libQtGui.so.4.8.2) ==9018==by 0x429F28: main (main.cpp:97) The following upstream commit fixes it by guarding a pointer. No more segfaults :) https://projects.kde.org/projects/kdesupport/phonon/phonon-vlc/repository/revisions/a8cda824ae8a81059c75e97d8a82d571ba84e459/diff.diff Regards, John Stamp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685032: debian-maintainers: Annual ping for John Stamp
Package: debian-maintainers Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, This is my annual ping. Regards, John Stamp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJQLDYeAAoJEBwB9EPJyTxaGDMP+wfFfLYr7WHVoPetgD0aimcV hgl0csWpgdJ2GtNXfFudEPK27r+V2Ru2USZ2zPvb+3HjmFR8yjK5S0GS1Ad3lGTf shE/HXAVCTBmId8MDxILtWlhMUxuafwZQaVNcq/4uU4VS17j3g5BQdZlKOWcBoGr 6ZED/ZVhA+c7ekJGJrfIoWWBMNAA6NJmXSHGSJpR4KauNI7cnNFbagZMkCAg7pMf Cfyyz/hfc5ko7WkHNRCWe0OeDXTtaps6NzVcImNt54pH73Yoy1phpAczTJPBSIiL mQ4MYTV04Ug85tjN5V0AIYTXOdHszZmQpT3KeI7qtp/UJeF1kxmEH6U5iOf51s80 TWqdijhXb5Jy4W+ds7iXUB7HomGym/qzHVpJpLW0rsR7NqjHerw601mrS7hgsDG4 Abu/Q9SXlT3JTdXhEpMP+HdfhMUxHa58ftciXTEc7rMJ+C8ZC78JFHp3k9qOPofX VsxIc009NhzmMlNGMGaO6FI83n97+C2Fv+8TZM7dcNW2k6FncE1GYZzlYwXsKaZP Ekk13F9/aXDqfqCkEBYeF5691OIuCI7l0ABj98o1q+2XigSsQNCVfGwQKaS5OgSK LjCLcGuda/bHLWNLs+2LORIgroQLco8HtlNcIT9DHQeaXC39MwwmDdlWJmeUwwlm JE/vlI0Wk6SvA9nSkt/z =U5UX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684757: lastfm: Add support for X multimedia keys
On Mon, Aug 13, 2012 at 10:09:50AM -0500, Gunnar Wolf wrote: Most X-enabled multimedia players grab and react to the multimedia keys found in many keyboards nowadays (I'd find XF86AudioPlay, XF86AudioStop, XF86AudioNext, XF86AudioLowerVolume, XF86AudioRaiseVolume XF86AudioMute as relevant to Last.FM's regular operation). It would be great if they were also available in Last.FM! Yes, that would be nice. It won't happen with this version of the client though. For the last couple of years upstream has only been doing minimal maintenance to keep it working. Fortunately, they're working again on the next major overhaul of their client. I'll put in a request for the feature, and if I get a chance I'll see if I can offer them a patch. Cheers, John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684956: cmake-data: Doesn't install to multiarch libdir when CMAKE_SYSTEM_NAME != Linux
Package: cmake-data
Version: 2.8.9~rc3-1
Severity: normal
Tags: patch
liblastfm 1.0.1 in experimental failed to build packages on kfreebsd and
hurd because of the following error:
dh_install: liblastfm-dev missing files (usr/lib/*/lib*.so), aborting
It looks like the problem is in
/usr/share/cmake-2.8/Modules/GNUInstallDirs.cmake
Starting at line 81, you'll see that cmake automatically appends the
library architecture to CMAKE_INSTALL_LIBDIR, but only when
CMAKE_SYSTEM_NAME matches Linux. The attached patch also checks for
the kFreeBSD and GNU system names.
diff --git a/Modules/GNUInstallDirs.cmake b/Modules/GNUInstallDirs.cmake
index 0302e4b..4dc2d68 100644
--- a/Modules/GNUInstallDirs.cmake
+++ b/Modules/GNUInstallDirs.cmake
@@ -78,7 +78,7 @@ if(NOT DEFINED CMAKE_INSTALL_LIBDIR)
# For Debian with multiarch, use 'lib/${CMAKE_LIBRARY_ARCHITECTURE}' if
# CMAKE_LIBRARY_ARCHITECTURE is set (which contains e.g. i386-linux-gnu
# See http://wiki.debian.org/Multiarch
- if(CMAKE_SYSTEM_NAME MATCHES Linux
+ if((CMAKE_SYSTEM_NAME MATCHES Linux|kFreeBSD OR CMAKE_SYSTEM_NAME STREQUAL GNU)
AND NOT CMAKE_CROSSCOMPILING)
if (EXISTS /etc/debian_version) # is this a debian system ?
if(CMAKE_LIBRARY_ARCHITECTURE)
Bug#682037: unblock: liblastfm/0.4.0~git20090710-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package liblastfm This fixes RC bug #676104. The debdiff was discussed in this thread: http://lists.debian.org/debian-release/2012/07/msg00693.html unblock liblastfm/0.4.0~git20090710-2 Regards, John Stamp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680141: This seems fine to upload
On Thu, Jul 05, 2012 at 05:10:20PM -0400, Asheesh Laroia wrote: John Stamp, can you clear the debdiff with the release team in an email to debian-release? Just email them the debdiff and ask if that would be okay, and if they say yes, I will upload this. (If you already have a sponsor lined up, then that's fine, too.) Thanks! Thanks. Will do. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680141: RFS: liblastfm/0.4.0~git20090710-2 [RC]
On Wed, Jul 04, 2012 at 02:03:57PM -0400, Asheesh Laroia wrote: I'm concerned by the following lintian warnings on mentors, which I can reproduce locally: W: liblastfm-fingerprint0: hardening-no-fortify-functions usr/lib/x86_64-linux-gnu/liblastfm_fingerprint.so.0.4.0 W: liblastfm0: hardening-no-fortify-functions usr/lib/x86_64-linux-gnu/liblastfm.so.0.4.0 Other than that, this seems reasonable so far! Yes, those warnings concern me too. The build uses -O2 -D_FORTIFY_SOURCE=2, but running hardening-check --verbose on each of the libraries shows this: /usr/lib/x86_64-linux-gnu/liblastfm.so.0.4.0: Position Independent Executable: no, regular shared library (ignored) Stack protected: yes Fortify Source functions: no, only unprotected functions found! unprotected: strncpy unprotected: fread Read-only relocations: yes Immediate binding: no, not found! /usr/lib/x86_64-linux-gnu/liblastfm_fingerprint.so.0.4.0: Position Independent Executable: no, regular shared library (ignored) Stack protected: yes Fortify Source functions: no, only unprotected functions found! unprotected: memset unprotected: memmove unprotected: memcpy Read-only relocations: yes Immediate binding: no, not found! I don't know which of these--if any--are false positives. Any help would be appreciated. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680141: RFS: liblastfm/0.4.0~git20090710-2 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package liblastfm * Package name: liblastfm Version : 0.4.0~git20090710-2 Upstream Author : Last.fm Ltd. cli...@last.fm * URL : http://mxcl.github.com/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-fingerprint0 - Last.fm fingerprinting library liblastfm0 - Last.fm web services library 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_0.4.0~git20090710-2.dsc Changes since the last upload: liblastfm (0.4.0~git20090710-2) unstable; urgency=medium * Fix compilation with ruby = 1.9.2 (Closes: #676104) * Use source format 3.0 (quilt) * Update the *.install files to accommodate multiarch * Update to dh 9 to take advantage of hardening build flags * Add missing misc:Depends and misc:Pre-Depends * Fix lintian warnings description-synopsis-starts-with-article * Bump Standards-Version to 3.9.3. * Update debian/copyright format to version 1.0 Regards, John Stamp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#680141: RFS: liblastfm/0.4.0~git20090710-2 [RC]
Yes, you're right. Thank you. An updated version is now on mentors. On Tue, Jul 03, 2012 at 11:42:28PM +0100, Jonathan McCrohan wrote: Hi John, On 03/07/12 22:52, John Stamp wrote: * URL : http://mxcl.github.com/liblastfm/ This URL leads to a 404. This URL is also listed in the debian/copyright file. It was probably correct at one stage, but github have probably changed the link format since the last liblastfm upload. I assume it should be http://github.com/mxcl/liblastfm/ instead. Jon -- 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/4ff37554.7050...@gmail.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657266: transition: yajl
On Thu, Jan 26, 2012 at 08:43:46PM +0100, Julien Cristau wrote: Sounds fine to me. collectd is currently RC-buggy, but it's also not in testing, so shouldn't be a blocker. Feel free to go ahead. Cheers, Julien OK. It's uploaded. Thanks, John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657266: transition: yajl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition yajl 2.0.4 is currently in experimental, and I hope to upload it to unstable. This includes a soname bump: libyajl1 - libyajl2 The following source packages will need a binNMU: collectd i3-wm libvirt raptor2 This will FTBFS: mudlet - bug #653880 (patch included) When I have your OK, I'll upload to unstable. Regards, John Stamp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653880: mudlet: Transition to yajl = 2.0 will cause FTBFS
On Tue, Jan 03, 2012 at 07:20:16PM +1100, Craig Small wrote: On Sat, Dec 31, 2011 at 02:02:52PM -0800, John Stamp wrote: Yajl version 2.0.4 will soon be uploaded to unstable. It will cause mudlet to FTBFS because of API changes. I've attached a patch based on the information in mudlet's COMPILE documentation. Unfortunately it doesn't make the package binNMUable, so it will need to be applied after the transition. Hello John, Does this mean I should try this once yajl2 comes along? If so, can you send an email to this bug once it is in? I cannot see it there yet. - Craig Yes, this is just an advance notice. I'll update the bug report once yajl2 reaches unstable. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#653879: collectd: Transition to yajl = 2.0 will cause FTBFS
Package: collectd
Severity: normal
Tags: patch
Hi,
Yajl version 2.0.4 will soon be uploaded to unstable. It will cause
collectd to FTBFS because of API changes.
I've attached a patch adapted from upstream commit
5ec7a37c81d6f64f35b1f35e2f0e3157e83f2718. It allows support for either
the v1 or v2 API.
Please let me know if you have concerns.
Regards,
John Stamp
#! /bin/sh /usr/share/dpatch/dpatch-run
## yajl2_api.dpatch by John Stamp jst...@users.sourceforge.net
##
## DP: Add support for libyajl v2 API
## DP:
## DP: This is based on upstream git commit
## DP: 5ec7a37c81d6f64f35b1f35e2f0e3157e83f2718
@DPATCH@
--- a/configure
+++ b/configure
@@ -22499,6 +22499,18 @@
done
+ for ac_header in yajl/yajl_version.h
+do :
+ ac_fn_c_check_header_mongrel $LINENO yajl/yajl_version.h ac_cv_header_yajl_yajl_version_h $ac_includes_default
+if test x$ac_cv_header_yajl_yajl_version_h = xyes; then :
+ cat confdefs.h _ACEOF
+#define HAVE_YAJL_YAJL_VERSION_H 1
+_ACEOF
+
+fi
+
+done
+
CPPFLAGS=$SAVE_CPPFLAGS
fi
--- a/configure.in
+++ b/configure.in
@@ -3609,6 +3609,7 @@
CPPFLAGS=$CPPFLAGS $with_libyajl_cppflags
AC_CHECK_HEADERS(yajl/yajl_parse.h, [with_libyajl=yes], [with_libyajl=no (yajl/yajl_parse.h not found)])
+ AC_CHECK_HEADERS(yajl/yajl_version.h)
CPPFLAGS=$SAVE_CPPFLAGS
fi
--- a/src/config.h.in
+++ b/src/config.h.in
@@ -1212,6 +1212,9 @@
/* Define to 1 if you have the yajl/yajl_parse.h header file. */
#undef HAVE_YAJL_YAJL_PARSE_H
+/* Define to 1 if you have the yajl/yajl_version.h header file. */
+#undef HAVE_YAJL_YAJL_VERSION_H
+
/* Define to 1 if the system has the type `_Bool'. */
#undef HAVE__BOOL
--- a/src/curl_json.c
+++ b/src/curl_json.c
@@ -29,6 +29,13 @@
#include curl/curl.h
#include yajl/yajl_parse.h
+#if HAVE_YAJL_YAJL_VERSION_H
+# include yajl/yajl_version.h
+#endif
+
+#if defined(YAJL_MAJOR) (YAJL_MAJOR 1)
+# define HAVE_YAJL_V2 1
+#endif
#define CJ_DEFAULT_HOST localhost
#define CJ_KEY_MAGIC 0x43484b59UL /* CHKY */
@@ -77,6 +84,12 @@
};
typedef struct cj_s cj_t; /* }}} */
+#if HAVE_YAJL_V2
+typedef size_t yajl_len_t;
+#else
+typedef unsigned int yajl_len_t;
+#endif
+
static int cj_read (user_data_t *ud);
static int cj_curl_perform (cj_t *db, CURL *curl);
static void cj_submit (cj_t *db, cj_key_t *key, value_t *value);
@@ -100,11 +113,17 @@
status = yajl_parse(db-yajl, (unsigned char *)buf, len);
if (status == yajl_status_ok)
{
+#if HAVE_YAJL_V2
+status = yajl_complete_parse(db-yajl);
+#else
status = yajl_parse_complete(db-yajl);
+#endif
return (len);
}
+#if !HAVE_YAJL_V2
else if (status == yajl_status_insufficient_data)
return (len);
+#endif
if (status != yajl_status_ok)
{
@@ -130,7 +149,11 @@
}
/* yajl callbacks */
+#if HAVE_YAJL_V2
+static int cj_cb_integer (void *ctx, long long val)
+#else
static int cj_cb_integer (void *ctx, long val)
+#endif
{
cj_t *db = (cj_t *)ctx;
cj_key_t *key = db-state[db-depth].key;
@@ -185,7 +208,7 @@
}
static int cj_cb_map_key (void *ctx, const unsigned char *val,
-unsigned int len)
+yajl_len_t len)
{
cj_t *db = (cj_t *)ctx;
c_avl_tree_t *tree;
@@ -213,7 +236,7 @@
}
static int cj_cb_string (void *ctx, const unsigned char *val,
- unsigned int len)
+yajl_len_t len)
{
cj_t *db = (cj_t *)ctx;
c_avl_tree_t *tree;
@@ -762,7 +785,13 @@
char *url;
yajl_handle yprev = db-yajl;
- db-yajl = yajl_alloc (ycallbacks, NULL, NULL, (void *)db);
+ db-yajl = yajl_alloc (ycallbacks,
+#if HAVE_YAJL_V2
+ /* alloc funcs = */ NULL,
+#else
+ /* alloc funcs = */ NULL, NULL,
+#endif
+ /* context = */ (void *)db);
if (db-yajl == NULL)
{
ERROR (curl_json plugin: yajl_alloc failed.);
Bug#653880: mudlet: Transition to yajl = 2.0 will cause FTBFS
Package: mudlet
Severity: normal
Tags: patch
Hi,
Yajl version 2.0.4 will soon be uploaded to unstable. It will cause
mudlet to FTBFS because of API changes.
I've attached a patch based on the information in mudlet's COMPILE
documentation. Unfortunately it doesn't make the package binNMUable, so
it will need to be applied after the transition.
Please let me know if you have concerns.
Regards,
John Stamp
Description: Compile using yajl = 2.0
Author: John Stamp jst...@users.sourceforge.net
Last-Update: 2011-12-20
--- a/src/TLuaInterpreter.cpp
+++ b/src/TLuaInterpreter.cpp
@@ -41,7 +41,7 @@
//#ifdef Q_OS_WIN32
//#include lua_yajl.c
//#else
-#include lua_yajl1.c
+#include lua_yajl.c
//#endif
extern C
--- a/src/src.pro
+++ b/src/src.pro
@@ -110,7 +110,7 @@
dlgMapper.cpp \
TRoom.cpp \
TMap.cpp \
-lua_yajl1.c \
+lua_yajl.c \
TBuffer.cpp \
irc/src/ircbuffer.cpp \
irc/src/irc.cpp \
--- a/src/lua_yajl.c
+++ b/src/lua_yajl.c
@@ -590,7 +590,7 @@
} else if ( num == -HUGE_VAL ) {
str = -1e+666;
len = 7;
-} else if ( _isnan(num) ) {
+} else if ( isnan(num) ) {
str = -0;
len = 2;
} else {
Bug#634176: Ping?
You're right. I'm very sorry about that. I will get 2.0.3 uploaded this week. John Stamp On Sat, Dec 17, 2011 at 12:32:44AM +, Michael Stapelberg wrote: Hi, It’s been a few month and you have not replied. Do you need any help with packaging the new version? Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627366: debian-maintainers: Annual ping for John Stamp
Package: debian-maintainers Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is my annual ping as a Debian Maintainer. I am still actively maintaining packages; please keep my key in the keyring. Regards, John Stamp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3V4nIACgkQbU7/TZgP4USoBACeM3IpCt5eA1+vhWkueuPEbVh/ dRcAn0gsAJU6h3/h9tGx/C3lBoY1ULZJ =qrlz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537200: lastfm-desktop: restoring ITP
retitle 537200 ITP: lastfm-desktop -- The official Last.fm desktop application suite owner 537200 ! thanks I spoke with upstream. They are finally expecting to release in the next month or two. I still intend to package it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598664: unblock: lastfm/1:1.5.4.26862+dfsg-5
On Sun, Oct 03, 2010 at 04:01:11PM +0200, Julien Cristau wrote:
On Thu, Sep 30, 2010 at 14:47:46 -0700, John Stamp wrote:
Please unblock package lastfm
It contains a security relevant bugfix: CVE-2010-3362 (#598294)
It also contains a bunch of other unrelated changes, not documented in
the changelog.
Cheers,
Julien
Yikes. I'm sorry about that. I backed out the undocumented patches and
uploaded -6, which now only adds the fix for CVE-2010-3362.
The diff from the version in testing is below:
diff --git a/debian/changelog b/debian/changelog
index 4ee2479..47f5048 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+lastfm (1:1.5.4.26862+dfsg-6) unstable; urgency=high
+
+ * Back out the undocumented changes that sneaked in with -5. We only want
+the fix for CVE-2010-3362.
+
+ -- John Stamp jst...@users.sourceforge.net Mon, 04 Oct 2010 13:23:01 -0700
+
+lastfm (1:1.5.4.26862+dfsg-5) unstable; urgency=high
+
+ * Fix CVE-2010-3362: insecure library loading (Closes: #598294)
+
+ -- John Stamp jst...@users.sourceforge.net Thu, 30 Sep 2010 14:03:23 -0700
+
lastfm (1:1.5.4.26862+dfsg-4) unstable; urgency=low
* Bump Standards-Version to 3.9.1. No changes needed.
diff --git a/debian/package-files/bin/lastfm b/debian/package-files/bin/lastfm
index 34a2487..aef3654 100755
--- a/debian/package-files/bin/lastfm
+++ b/debian/package-files/bin/lastfm
@@ -1,5 +1,5 @@
#!/bin/sh
RUNDIR=/usr/lib/lastfm
-export LD_LIBRARY_PATH=${RUNDIR}:${LD_LIBRARY_PATH}
+export LD_LIBRARY_PATH=${RUNDIR}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
exec ${RUNDIR}/last.fm $@
Regards,
John Stamp
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598664: unblock: lastfm/1:1.5.4.26862+dfsg-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package lastfm It contains a security relevant bugfix: CVE-2010-3362 (#598294) unblock lastfm/1:1.5.4.26862+dfsg-5 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581212: debian-maintainers: Annual ping for John Stamp
Package: debian-maintainers Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's my annual ping. I'm still maintaining packages and would like to keep my key in the DM keyring. Regards, John Stamp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkvpioQACgkQbU7/TZgP4URDXQCfRytnLAwWE/DqDCaWutc+pA4V hCcAoMdQVUepcgvTg5JggIhBDz+SH81y =6V8N -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569739: lastfm: pulseaudio support would be nice
On Tue, Feb 16, 2010 at 05:16:17PM +0100, Wouter van Heyst wrote: Interesting, are there snapshots available? last.fm/download only mentions the old client. Current development is happening on github: http://github.com/jonocole/lastfm-desktop These days, jonocole's and eartle's are the forks to watch. I believe that Jono will be managing releases. Right, but with the development speed, when will that be? I'm going to have a peek at how hard implementing this would be tonight, who knows :) I really don't know. My guess is: Long after you get fed up and implement something yourself ;) They once hoped for a release in May 2009, I filed an ITP in July (#537200), but a lot of staff churn significantly slowed things down. Development has picked up recently, but the radio player doesn't look suitable for regular use yet. Doh! I just remembered: the current client includes a portaudio plugin for OSX. Also a long while ago I added multi-sound.diff to the msk branch of my repository: git://git.mehercule.net/lastfm.git It's rather klunky, but it was the best I could do at the time without changing things all over the place. Basically, it gives you support for drop-in audio plugins. I just pushed a commit that will get the portaudio plugin compiling on linux. Care to give it a shot? quilt push the patches up through multi-sound, then ./configure; make; bin/last.fm.sh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216210804.ga13...@panurge.localnet
Bug#569739: lastfm: pulseaudio support would be nice
I'm not sure when that will happen. Upstream hasn't released a new version of the client in nearly a year. They've instead been working on a totally new client from a different codebase, but progress has been slower than anyone expected. The good news is that it will rely on phonon, so it should eventually give you the flexibility that you want. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216042146.ga28...@panurge.localnet
Bug#553229: yajl: watch file is wrong
tags 553229 pending thanks It's fixed in VCS. I'll try to get an update uploaded soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547777: kfreebsd-kernel-headers: Missing semicolon in 009_inetutils.diff
Package: kfreebsd-kernel-headers
Version: 0.41
Severity: important
Tags: patch
It prevents compilation for apps that include net/if_var.h
Small update attached.
Index: debian/patches/009_inetutils.diff
===
--- debian/patches/009_inetutils.diff (revision 2793)
+++ debian/patches/009_inetutils.diff (working copy)
@@ -55,7 +55,7 @@
-#define ifa_broadaddr ifa_dstaddr /* broadcast address interface */
+ union
+ {
-+ struct sockaddr *ifu_broadaddr /* broadcast address interface */
++ struct sockaddr *ifu_broadaddr; /* broadcast address interface */
+ struct sockaddr *ifu_dstaddr; /* other end of p-to-p link */
+ } ifa_ifu;
+/* These very same macros are defined by ifaddrs.h for `struct ifaddrs'.
Bug#544721: yajl-tools: Statically linked against libyajl1
Good point. I'll take care of that soon. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544223: argyll uses embedded yajl
On Sunday 30 August 2009 04:35:43 am Roland Mas wrote: I'm less enthusiastic about that part. I did replace the embedded and patched libusb, but the local patches weren't adding functionality. In this case, you're removing functionality from argyll even though it appears not to be used currently. Since I try to stick to upstream as much as I can, I'd rather not go this way. I'd much prefer the patch to be included in yajl, preferably upstream. Yeah, I thought you might not like that--partly why I made a point to mention the change. When I get a chance, I'll look more closely at what argyll did to yajl and see if Lloyd is interested in applying it upstream. Cheers, John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544223: argyll uses embedded yajl
Package: argyll
Version: 1.0.4-1
Severity: normal
Tags: patch
Argyll embeds an old version of yajl (0.3.0) in its source code. Now
that yajl is in Debian, I'm attaching a patch that lets it compile
against the system yajl instead.
Note: Argyll modified yajl's API so argyll's jcnf can save comments.
But from what I can see, ucmm/ucmm.c is the only file that uses jcnf,
and it doesn't take advantage of that feature. So even though the patch
comments out a bit of argyll's code, it shouldn't affect its
functionality.
Regards,
John Stamp
--- a/jcnf/Makefile.am
+++ b/jcnf/Makefile.am
@@ -2,15 +2,13 @@
include $(top_srcdir)/Makefile.shared
-SUBDIRS = yajl
-
privatelib_LTLIBRARIES = libjcnf.la
privatelibdir = $(pkglibdir)
libjcnf_la_SOURCES = jcnf.h jcnf.c
-libjcnf_la_LIBADD = yajl/libyajl.la
+libjcnf_la_LIBADD = -lyajl
-LDADD = ./libjcnf.la yajl/libyajl.la
+LDADD = ./libjcnf.la -lyajl
check_PROGRAMS = test
--- a/jcnf/jcnf.c
+++ b/jcnf/jcnf.c
@@ -42,9 +42,9 @@
#include string.h
#include math.h
-#include yajl/yajl_common.h
-#include yajl/yajl_gen.h
-#include yajl/yajl_parse.h
+#include yajl/yajl_common.h
+#include yajl/yajl_gen.h
+#include yajl/yajl_parse.h
#include jcnf.h
@@ -955,9 +955,10 @@
}
}
+ /*
if (p-keys[i]-comment != NULL) {
yajl_gen_cpp_comment(g, p-keys[i]-comment, strlen(p-keys[i]-comment));
- }
+ }*/
#ifdef NEVER
yajl_gen_map_open(g);
--- a/spectro/Makefile.am
+++ b/spectro/Makefile.am
@@ -22,10 +22,10 @@
../numlib/libargyllnum.la ./libinst.la ../libargyll.la
LDADD = ./libinsttypes.la ./libdisp.la ./libinst.la ../ucmm/libucmm.la \
- ../jcnf/libjcnf.la ../jcnf/yajl/libyajl.la ../xicc/libxicc.la \
+ ../jcnf/libjcnf.la ../xicc/libxicc.la \
../xicc/libxcolorants.la $(ICC_LIBS) ../cgats/libcgats.la \
../rspl/librspl.la ../gamut/libgamut.la ../target/libtarget.la \
- ../plot/libplot.la ../numlib/libargyllnum.la $(X_LIBS) -lusb
+ ../plot/libplot.la ../numlib/libargyllnum.la $(X_LIBS) -lusb -lyajl
bin_PROGRAMS = synthcal dispwin dispread dispcal fakeread synthread \
chartread spotread spec2cie average spyd2en
Bug#537199: ITP: yajl -- Yet Another JSON Library
Package: wnpp Severity: wishlist Owner: John Stamp jst...@users.sourceforge.net * Package name: yajl Version : 1.0.5 Upstream Author : Lloyd Hilaiel ll...@hilaiel.com * URL : http://lloyd.github.com/yajl/ * License : BSD Programming Lang: C Description : Yet Another JSON Library A small, fast library for parsing JavaScript Object Notation (JSON) data streams. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537200: ITP: lastfm-desktop -- The official Last.fm desktop application suite
Package: wnpp Severity: wishlist Owner: John Stamp jst...@users.sourceforge.net * Package name: lastfm-desktop Version : 0+git20090709 Upstream Author : Jono Cole j...@last.fm Doug Mansell d...@last.fm Max Howell m...@methylblue.com * URL : http://github.com/jonocole/lastfm-desktop/ * License : GPL3+ Programming Lang: C++ Description : The official Last.fm desktop application suite Last.fm's collection of applications for streaming and scrobbling music. I'm planning to package this once it gets to a releasable state, which will hopefully be soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524948: liblastfm
On Saturday 30 May 2009 08:35:13 am Modestas Vainius wrote: Hello, On 2009 m. April 21 d., Tuesday 05:55:53 you wrote: I've been packaging the lastfm package for a while now. Today Max from Last.fm emailed me about the liblastfm package that they just released. I think that version 2.0 of the Last.fm client will depend on it, and as you're probably aware, Amarok = 2.1.1 might too. So how is packaging going? 2.1.1 is coming closer. Packaging is near ready. The problem was that just as I was going to upload 0.2.1-1, upstream made a number of changes which made it better to wait for 0.3.0. 0.3.0 is now released, and I plan to upload this week. Git repository here if you'd like a peek: http://github.com/jstamp/liblastfm -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527143: debian-maintainers: Annual ping for John Stamp
Package: debian-maintainers Version: 1.57 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please consider this my annual ping as required here: http://wiki.debian.org/Maintainers#Annualping I am still actively working on the lastfm package and will soon be maintaining a few more packages--though they won't immediately have DMUA status. Regards, John Stamp -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoAn5sACgkQbU7/TZgP4UQQ5QCgtyYTVJwnHNP5E3wc3sjj9gsD dXAAn2daCFDNtp58fKP2h19vVRW562eL =Z1uX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524948: ITP: liblastfm -- Last.fm web services library
Package: wnpp Severity: wishlist Owner: John Stamp jst...@users.sourceforge.net * Package name: liblastfm Version : 0.2.1 Upstream Author : Max Howell m...@last.fm * URL : http://github.com/mxcl/liblastfm/tree/master * License : GPL2+ Programming Lang: C++ Description : Last.fm web services library liblastfm is Last.fm's library for using their web services such as scrobbling, fingerprinting tracks, and requesting audio streams. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#524584: lastfm_1:1.5.1.31879.dfsg-2(mips/unstable): FTBFS on mips
There are only a few minor changes between -1 and -2, and mips successfully completed a bin-NMU of -1+b2 on March 11. Here's the relevant snippet from the build of -1+b2: /usr/bin/uic-qt4 confirmdialog.ui -o ../../build/ui_confirmdialog.h g++ -c -pipe -g -O2 -g -Wall -O2 -w -D_REENTRANT -fPIC -DNBREAKPAD -DLINUX -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I. -I../libUnicorn -I../../src -I../../build -I../../build/Moose/release -I../../build -o ../../build/Moose/release/confirmdialog.o confirmdialog.cpp And the same section just before the errors that you cited for -2: /usr/bin/uic-qt4 confirmdialog.ui -o ../../../../ui_confirmdialog.h g++ -c -pipe -g -O2 -g -Wall -O2 -w -D_REENTRANT -fPIC -DNBREAKPAD -DLINUX -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I/src/libMoose -I/src/libUnicorn -I/src -I/build -I../../../../Moose/release -I/build -o ../../../../Moose/release/confirmdialog.o confirmdialog.cpp As you can see, a number of include and destination paths are broken. e.g.: -I/src/libMoose -I/src/libUnicorn -I/src -I/build I suspect the problem is related to lastfm's definitions.pro.inc, where it defines: ROOT_DIR = $$system( pwd ) and proceeds from there: BIN_DIR = $$ROOT_DIR/bin DESTDIR = $$BIN_DIR [...] INCLUDEPATH += $$ROOT_DIR/src/libMoose $$ROOT_DIR/src/libUnicorn [...] Any idea why this now a problem? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516412: knemo: Depends on kicker, kicker going away
FYI: A new version compatible with kde4 was just released on kde-apps. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506814: phonon 4.2.0-2 can cause Qt widget problems
Package: phonon Version: 4:4.2.0-2 Severity: normal It looks like the fix for #498573 created another bug. Compile Qt's musicplayer: http://doc.trolltech.com/4.4/phonon-musicplayer.html Install KDE4, but run musicplayer in a non-KDE environment. The player will be able to find the Phonon plugins, but it will also use KDE's oxygen style, KDE's file dialog, and the menu and toolbar text will be invisible. You can still click on the areas though. I downgraded to 4.2.0-1 and was able to duplicate this by adding /usr/lib/kde4/plugins to QT_PLUGIN_PATH. So it looks like Qt needs to be more selective about which plugins it has access to when it's running in a non-KDE environment. I tried Vincent's suggestion about a symlink just for phonon_backend. That gets me audio and Qt's normal widget behavior. John Stamp -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (400, 'testing'), (200, 'unstable'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-10 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages phonon depends on: ii libphonon44:4.2.0-2 Phonon multimedia framework for Qt ii phonon-backend-gstreamer [pho 4:4.2.0-2 Phonon GStreamer 0.10.x backend ii phonon-backend-xine [phonon-b 4:4.1.3-1 Phonon Xine 1.1.x backend phonon recommends no packages. Versions of packages phonon suggests: pn phonon-backend-mplayernone (no description available) pn phonon-backend-vlcnone (no description available) ii phonon-backend-xine 4:4.1.3-1 Phonon Xine 1.1.x backend -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#506814: phonon 4.2.0-2 can cause Qt widget problems
On Monday 24 November 2008 04:15:56 pm Modestas Vainius wrote: Hello, antradienis 25 Lapkritis 2008, John Stamp rašė: backend ii phonon-backend-xine [phonon-b 4:4.1.3-1 Phonon Xine 1.1.x backend phonon-backend-xine comes from KDE. Please remove it and try again. Try using GStreamer backend instread which the only official Phonon 4.2.0 backend we ship. I removed phonon-backend-xine. Only the GStreamer backend is installed. I see the same problem: KDE dialogs, invisible text, etc. To be more specific about how I tested: I created a clean test account to ensure there weren't any lingering config files, started an xfce4 session, and ran Qt's musicplayer example in an xterm. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#498573: libqt4-dev: Please, enable Phonon support
On Sunday 26 October 2008 10:01:38 am Sune Vuorela wrote: On Friday 24 October 2008 16:01:47 Felix Homann wrote: Hi, thank you Sune for your reply. I'm very sorry I didn't answer earlier. I've tried again building the musicplayer example from the Qt4 examples. It builds but it doesn't work. I'm getting error messages of this kind: Phonon::createPath: Cannot connect Phonon::MediaObject(no objectName) to Phonon::AudioOutput(no objectName). WARNING: bool Phonon::FactoryPrivate::createBackend() phonon backend plugin could not be loaded Unfortunately, the example isn't build in qt4-demos either. What's wrong? which phonon backends do you have installed ? /Sune About the phonon backend error, see the discussion here: http://bugs.archlinux.org/task/11070 Sune, I don't know if you'd consider this a problem with the Qt or phonon packages, but it seems that by default Qt applications look for the phonon plugins under /usr/lib/qt4/plugins/. However, Debian installs them under /usr/lib/kde4/plugins/. startkde takes care of that by setting the QT_PLUGIN_PATH environment var. Something in there also causes ~/.config/Trolltech.conf to update the 4.4\libraryPath entry. Unfortunately, there's two problems with this: 1. If a person hasn't run a KDE4 session at least once, Qt doesn't know where to find phonon's plugins. 2. For some reason the 4.4\libraryPath entry is getting flooded with repetitions. A new pair appears each time a KDE4 session starts. John Stamp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495701: Fonts are unreadable when playing music
On Tuesday 19 August 2008 12:56:01 pm Juhapekka Tolvanen wrote: When this software plays music, it shows inoframtion about the song and its artist. All that information is show in way too tiny fonts and I can not find a way to rectify situation. I have a resolution of 1600x1200 in my monitor. I suggest Debian-packagers modifies source file so that fonts become bigger. But it would be btter, if there was some setting for changing font size. Unfortunately, just changing the font size won't help. If you try it, you will just see large text that's cropped and unreadable. To fix this, we would not only have to change how the font sizes are calculated, but rewrite how the metadata window lays out its content. This requires some pretty invasive changes that would be very difficult to keep in sync when upstream releases a new version. So... Hi Max! Do you folks plan to give MetaDataWidget, SideBarView, etc. the ability to adjust their layouts relative to the user's default font size? John Stamp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491212: Argus Server in testing
Package: argus-server Severity: serious Version: 1:2.0.6.fixes.1-14.1 The problem is that libpcap0.8-dev moved a header which breaks compilation, but the package still gets created because of #258832. Patch attached. John Stamp --- argus-2.0.6.fixes.1.orig/common/gencode.c +++ argus-2.0.6.fixes.1/common/gencode.c @@ -59,7 +59,7 @@ #include stdlib.h #include syslog.h -#include net/bpf.h +#include pcap-bpf.h #include argus_out.h #include argus_filter.h
Bug#476998: Patch to fix 476998
On Sunday 27 April 2008, Kumar Appaiah wrote: tags 476998 + patch thanks Hi! Please find attached a patch to fix this bug by including zlib1g-dev. HTH. Kumar Thanks for providing the patch! I took care of this a few days ago...just waiting for my sponsor to upload. I'll update the tags. Cheers, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476998: Patch to fix 476998
On Sunday 27 April 2008, Kumar Appaiah wrote: On Sun, Apr 27, 2008 at 08:28:27AM -0700, John Stamp wrote: Hi! Please find attached a patch to fix this bug by including zlib1g-dev. HTH. Kumar Thanks for providing the patch! I took care of this a few days ago...just waiting for my sponsor to upload. I'll update the tags. Henceforth, PLEASE tag bugs as patches to save effort and CPU cycles for others. This holds especially for RC bugs. Thank you. Kumar Definitely. I am very sorry to have caused the wasted effort. John Stamp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432718: Bugs #432718 #375620
package lastfm tags 375620 wishlist tags 432718 wishlist block 375620 by 432718 thanks I'm tagging these as wishlist. Upstream has supported only ALSA since late 2006, so this is actually a feature request that would force some significant design changes. I heard that upstream may start using Phonon for sound playback. If they do, that should fix both problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463031: lastfm: lately does more buffering than playing
On Wednesday 06 February 2008, Eddy Petrișor wrote: It is interesting that 1:1.1.3.0-1 works, because last.fm did indeed change the protocol. The old protocol delivers all of a station's songs as a single stream. The current protocol streams each song individually (i.e. there is a new HTTP GET request for each song). It's not a recent change though. That happened with 1:1.3.0.58-1 back in June 2007! I must have changed the client around that date (I remember using last-exit for a while), then I came back to lastfm somewhere around November or maybe earlier, but I didn't have these issues. I have discovered and installed shellfm sometime around the end of Novemeber, but I remember having interruption issues with it. I *think* wasn't experiencing issues with lastfm while I was with shellfm (it resulted in some weird alsa errors - i thought shellfm was broken). I think that last-exit also uses the old protocol, so that's probably why it doesn't give you buffering problems: neither last-exit nor 1.1.3.0 send a new request on each new song. Shell-fm in testing/unstable uses the new protocol. Do you have buffering problems when you use that? (Check Last.fm's conf file for a I was, last time I checked. Maybe it takes too much to open a new connection? Maybe lastfm closes the stream after buffering, instead of keeping the connection open, so it takes time to reopen again the stream? Using the current protocol, whenever the client wants to play a new song it requests it from play.last.fm. The host returns an HTTP 302 which points to a stream server in a pool. The client then connects to the stream server and starts playing. As you might then expect, you get a different server for each song, and the server closes the connection when the song is done. (If it makes a difference, the current protocol's streamers reply with HTTP/1.1) This is partly why I suspect the servers or network problems and why I think that wireshark or some other traffic analyzer might help us diagnose this. Is there a way to preemptively start the buffering when the buffer reaches a certain threshold (maybe modify that somehow)? Would you mind explaining this a bit? I'm not quite sure what you mean. Here's how it currently works: The stream server sends a burst of data at the beginning to quickly fill the client's buffer and then sends a steady 16.9KB/s stream. The client's auto-managed buffer starts at 16KB and gradually increases whenever it gets completely emptied. But generally you only have a couple seconds of mp3 data buffered at time. What change are you proposing? Buffering one song while it plays another? Is it possible to request the usage of the old protocol in the current version? As for the old protocol, I don't think there will be much luck requesting it. I'm in the U.S., and I can't even get last-exit or client version 1.1.3.0 to play anymore. Amarok streams last.fm stations but it can't skip. Maybe support for the old protocol varies from location to location? I really don't know. But see below... url to use.) If so, then I suspect a problem between your box and their servers. Maybe wireshark could shed some light on this. If not, then... I think it would be interesting to see if I can preemptively ask for buffering. I am confused... Me too. In spite of all things, if each song is in a different stream, wouldn't that mean, even in worse case scenario, that there shouldn't be any interruptions during one same song or, at worst, the buffer fill ratio would tend to reach 0, but would be filled back again immediately? Thus my confusion. I assume that you don't have other network problems, so I don't know why it fails to deliver a mere 16.9KB/s stream. Still confused. P.S.: I'll try to find out if I can detect/deduce the date when I installed shellfm (but I doubt it with the log rotation of aptitude and me using noatime). I'd personally be interested in whether or not wireshark shows anything interesting. From all that you tell me it looks like whenever you use the current protocol's servers, songs don't stream, they dribble. But if a traffic analyzer tells you nothing, then we still haven't ruled out much. It is one of the frustrating things about streaming clients. There are many places where things can go wrong. We really need to isolate the problem if we can: 1. Are you getting a 16.9KB/s stream when the client has buffering problems? 2. Does the client have problems on a different computer in the same network? 3. Do you have fewer problems if your laptop streams lastfm on another network: at work, at a café, at a friend's house, etc? What if you commandeer your friend's computer and stream from that? 4. Do certain times of the day seem worse than others? 5. Do you see a pattern of bad behavior with particular servers? 6. Can you think of any other
Bug#463031: lastfm: lately does more buffering than playing
On Monday 04 February 2008, Eddy Petrișor wrote: Currently I am listening (trying to) to Lu_beck's Radio Station. I am 995 sure the songs can be identified from the log (snapshot made after listening one sone and a little from the second) ;-) . Thanks for the log file. That second song shows that it took a while (3 seconds) for your buffer to initially fill up enough to play, then it emptied a couple of times in the first 6 seconds. Wow. That does look bad. Ok, I went back to that version, then even further, now I have ended up using the ancient 1:1.1.3.0-1 which doesn't stop in an annoying fashion. It plays without interrupts. Maybe there was a protocol change recently? It is interesting that 1:1.1.3.0-1 works, because last.fm did indeed change the protocol. The old protocol delivers all of a station's songs as a single stream. The current protocol streams each song individually (i.e. there is a new HTTP GET request for each song). It's not a recent change though. That happened with 1:1.3.0.58-1 back in June 2007! I think that last-exit also uses the old protocol, so that's probably why it doesn't give you buffering problems: neither last-exit nor 1.1.3.0 send a new request on each new song. Shell-fm in testing/unstable uses the new protocol. Do you have buffering problems when you use that? (Check Last.fm's conf file for a url to use.) If so, then I suspect a problem between your box and their servers. Maybe wireshark could shed some light on this. If not, then... I am confused... Me too. John
Bug#463031: lastfm: lately does more buffering than playing
On Friday 01 February 2008, Eddy Petrișor wrote: No problems with last-exit; I forgot to say in my original report. Well that stinks. I was hoping to blame it all on the servers. :( When you are streaming a song click Help | Diagnostics. Does anything look interesting just before the buffering starts? Also, would you mind sending me ~/.local/share/Last.fm/Last.fm.log? Let me know a few songs that suffered from the buffering problems so I can focus a bit. Note: The log may contain your username and password hash, so you may wish to edit for privacy. Finally, you said that things were fine in early December. 1.4.1.57486 made it to unstable on 12/30. So I take it that the last known working version was 1.3.2.14. Does downgrading stop the buffering problem? http://snapshot.debian.net/archive/2007/12/29/debian/pool/main/l/lastfm/
Bug#463031: lastfm: lately does more buffering than playing
Hello-- I doubt that the buffering issue is a problem with the client itself. It's more likely a problem on the server end. I wonder, do you still have problems if you use a different last.fm client? i.e.: amarok | last-exit | lastfmproxy | shell-fm | zomg... Would you mind trying one of those for a few days and reporting the results? Cheers, John P.S. This also sounds like your complaint, but there are no answers yet: http://www.last.fm/forum/34905/_/372737 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455073: lastfm: libraries location
OK. I spoke with upstream. They are aware of the SONAME version problem and appear interested in fixing it. And while they don't currently consider libLastFmTools and the newly-introduced libMoose to be useful for other packages, they do plan to make them useful in the future. Given that, I think the most sensible course is to leave the package as it is, avoid RPATH, and let upstream bump the SONAME version. When the libraries become useful for other packages, I can split them out and create the relevant -devs. If that sounds sensible to you, I'll call it settled for now and leave the bug open as a reminder. Cheers, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454614: (no subject)
On Friday 07 December 2007, Luca Falavigna wrote: Invoking gtk-update-icon-cache solves the issue in GNOME, probably using dh_icons in rules could fix this as well. Thank you. Yes I suspect adding dh_icons would take care of that. But right now I'm not sure how this fits with the overall plan to support icon caches in Debian.[0] This affects more than just lastfm. For instance, I imagine you could file a similar bug against every KDE package.[1] And since lastfm uses cdbs, I'd first like to see how the cdbs maintainers handle this. They currently have a problem with it.[2] So for now, I'm going to gather more information and wait to see how this shakes out. Cheers, John [0] http://lists.debian.org/debian-release/2007/07/msg00107.html [1] Though to me this seems more like a GNOME problem if it can't gracefully show an uncached icon. [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432851 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455073: lastfm: libraries location
On Saturday 08 December 2007, Leo costela Antunes wrote: The package currently places libLastFmTools.so.1 into /usr/lib. Is this library useful for other packages, even if currently no one links to it? Is it stable enough for that? If it isn't, perhaps upstream's SONAME's wrong and you could ask them to remove it, just for information's sake. This has been nagging me ever since I read this thread: http://lists.debian.org/debian-devel/2007/09/msg00889.html And I've been thinking about it more since 1.4.0 was released. The library isn't very useful for other applications; it's for lastfm and its bundled plugins: /usr/lib/lastfm/services/*. Also, upstream kept the same SONAME version for 1.4.0, but it's incompatible. So no, I wouldn't call that stable. Of course, lintian will complain if I remove the SONAME E: sharedobject-in-library-directory-not-actually-a-shlib So perhaps it would be best to use RPATH and make it a private library in /usr/lib/lastfm. I'd appreciate any further enlightenment. It would be great to get this resolved before I upload 1.4.0. Cheers, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455073: lastfm: libraries location
On Saturday 08 December 2007, Leo costela Antunes wrote: Just to be extra polite I'd ask upstream if they want people to be able to use this lib. Perhaps they haven't really thought about it! :-) This could be enough nudging to make them either bump the SONAME for the next release or include it with the other libs in the lastfm subdir. Good point! Since I'm talking with them about 3 or 4 other things I might as well mention this. ;) Regardless of what upstream says, it shouldn't be too hard (but I haven't looked at the code) to patch the build system to move the lib to /usr/lib/lastfm. Since the executable already has RPATH set for the other libraries that are there, only moving it should be enough to clear things up. No hard at all. I'm playing with it right now. OTOH, if upstream decides to stabilize this lib (perhaps opening up way for people to contribute some third-party plugins), splitting the package should also be fairly easy. As a last idea: depending on which plugins (built-in or otherwise) are available, it could be worthwhile to split the package even if the lib is unstable, since then you could also split the plugins into separate packages to reduce the dependencies on people with specific needs. But if it only has some 2 or 3 basic built-in plugins which are all needed, this point is moot (but so is the point in having plugins! :-) ). Cheers It's moot. They're plugins in name only. I think that one day, eventually, sometime in future, they plan to make these real plugins, but for now each is necessary for the client's function. A while ago I sent them a patch that could allow 3rd parties to write their own output plugins--OSS, JACK, PortAudio, etc.--but upstream's priorities have been elsewhere. Now that I look at it again, the patch could use a little more work. Anyway, I'll contact upstream and decide once I hear back from them. Cheers, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454614: Icon is not displayed properly
Thanks for letting me know. I tried with KDE 3.5.8 and Xfce 4.4.1, and I see no problem with the icon. What desktop environment are you using? The key Icon=lastfm should check for the lastfm icons in the hicolor icon theme. They are included in the Debian and Ubuntu packages, so I wonder why you see no icon. As for the other changes to the .desktop file: I removed the deprecated Encoding key. Thanks for pointing that out! It will appear in the next upload which will arrive after upstream releases 1.4.0. The desktop specification lets the Exec key point to the full path or just the executable name, so I don't see a problem there. Is there a reason why you prefer the latter? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452709: does not stop searching for radio stations
Were you able to use the client on that machine before? When you tried the other machines, did you test with an account that could not play music? It worked? If it still looks like it's isolated to that one machine, do this: Delete ~/.local/share/Last.fm/container.log on the machine that has connection problems. Try to play music with the client, then send me the new (gzipped) container.log. Note: container.log contains personal info like your account name and password hash, so you may wish to edit that before you send the log. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439795: amarok: While using LastFM skip and ban not having any effect
On Tuesday 28 August 2007, Johannes Feuser wrote: Installing 1.4.7-1 from unstable does unfortunately not change the problem. It's a known problem: http://bugs.kde.org/show_bug.cgi?id=149597 Incidentally, a similar bug was filed against lastfm a few weeks ago, but it only affects versions 1:1.3.x http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438445 John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438445: lastfm: can't skip or ban tracks
Sorry about the delay. And thanks for letting me know about this. Yes, I think it does have something to do with the protocol change introduced in v1.3. Even 1:1.1.3.0-4 is unable to skip, and that's only from 3 months ago. I'm guessing that they recently decided to chuck compatibility with older players. So the fix for etch: 1:1.3.0.58-1~bpo40+1 is now on backports.org. I'll keep it updated as newer versions migrate to testing. Cheers, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432718: lastfm: Doesn't support OSS anymore
package lastfm tags 432718 +patch thanks I attached a patch that lets the client choose from multiple sound systems. Currently users can choose between ALSA and OSS. It works well on my system. Reinhard Tartler doesn't get sound output while using the OSS plugin, but he says it could be a local problem. The patch was sent upstream on 7/15/07. It's pretty significant and modifies some core parts of the client, so I'm waiting to hear what they want to do about it before it goes in the Debian archive. If anyone wants to offer bug fixes or improvements, I'd be happy to hear them. Cheers, John 50_multi-sound.diff.gz Description: GNU Zip compressed data
Bug#435128: lastfm: stops responding while playing
Hi. I haven't seen this myself, though about a week ago a friend reported that the UI froze a couple of times. Since you experience it frequently, we might be able to find what's causing it. apt-get install libqt4-dev libasound2-dev quilt Review and run the attached script. It will compile and run lastfm with a lot of debug info. Once you start having problems, see if you can close the client normally so we can get gprof info. After the client closes, edit ~/lastfm-debug/lastfm-output.log to hide your username and password hash. You may also wish to edit container.log; it only contains your username. gzip ~/lastfm-debug/*.log and send them to me. Maybe valgrind might give some interesting info? I don't know. Finally, have you noticed any patterns? For instance, does it happen more frequently if scrobbling is active, or if the stream is frequently interrupted? lastfm-debug.sh Description: application/shellscript
Bug#432718: lastfm: Doesn't support OSS anymore
Yes, lastfm used to support both alsa and oss on Linux. Then in July 2006 they released a new version of the client. From that point on, the client was hardcoded to only use alsa. This was not a problem for you because 1.1.90 was a much older version of the client (pre July 2006). It was only last week that a new version finally entered testing. I think upstream hopes to again support multiple audio systems on Linux, but I don't think it's a high priority for them right now. However, I'm working on a patch that will again let you choose between alsa and oss. It's mostly working. I just need to clean it up a bit and do some more testing. I'll let you know once I have something. Cheers, John Stamp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#432232: lastfm: Uses wrong language to interact with user
You are right. The first time lastfm runs it checks for a locale, but it doesn't check LC_MESSAGES. A patch will fix this soon. However, after that first run lastfm stores its language setting in ~/.config/Last.fm/Last.fm.conf. If you want to change it later, you need to go in Tools | Options | Account | Language and set it manually. Cheers, John Stamp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431819: lastfm: wants exclusive access to the sound card
In 1.1.90 lastfm used to use RtAudio, but it was causing too many problems. Beginning with 1:1.1.3.0, I replaced it with AlsaAudio, which is based on the xmms alsa plugin and includes support for the default device. Upstream adopted AlsaAudio, and started using it in 1.3. In the soundcard config, the default device should be right at the top of the list. For instance, in Tools | Options | Radio | Soundcard I see: HDA NVidia: Default Device (default:0) -- the default device HDA NVidia: AD198x Analog (hw:0,0) HDA NVidia: AD198x Digital (hw:0,1) What devices do you see? If you see Default Device select it, Apply, then restart lastfm. Does that fix it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431819: lastfm: wants exclusive access to the sound card
On Thursday 05 July 2007, Tanu Kaskinen wrote: I think that's as much information as I can come up with right now. OK, thanks for testing that out with a couple of different setups. It gives me a pretty good idea of what's going on. I'll look into it. Cheers, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431773: libqt4-dev: Missing mkspec files on hppa
Package: libqt4-dev Version: 4.3.0-2 Severity: important On hppa, the symlink /usr/share/qt4/mkspecs/default points to a nonexistent linux-g++ directory. This can prevent other packages from building on hppa if they rely on qmake project files. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431322: libqt4-gui: Segfaults in some cases when showing tooltips
Package: libqt4-gui Version: 4.3.0-2 Severity: normal Using Qt 4.3.0-2, run lastfm 1.3.0.58. When a song is playing, hover the mouse over a link in the main window (e.g. song title, artist, album). The program will segfault when it attempts to show a tooltip. This was not a problem in 4.3.0-1. I can work around it by changing lastfm's draglabel.cpp:563 from this: QToolTip::showText( helpEvent-globalPos(), m_items[index].m_tooltip ); to this: QToolTip::showText( helpEvent-globalPos(), m_items[index].m_tooltip, this ); So it looks like showText now crashes when QWidget* w = 0. I attached a backtrace. The reference to qtooltip.cpp:370 points to a line added by 00_0178-transparency-window-types. Cheers, John -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20-3.amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libqt4-gui depends on: ii fontconfig 2.4.2-1.2generic font configuration library ii libaudio2 1.9-2The Network Audio System (NAS). (s ii libc6 2.5-11 GNU C Library: Shared libraries ii libfontconfig1 2.4.2-1.2generic font configuration library ii libfreetype62.2.1-6 FreeType 2 font engine, shared lib ii libgcc1 1:4.2-20070627-1 GCC support library ii libgl1-mesa-glx [libgl1 6.5.2-5 A free implementation of the OpenG ii libglib2.0-02.12.12-1The GLib library of C routines ii libglu1-mesa [libglu1] 6.5.2-5 The OpenGL utility library (GLU) ii libice6 1:1.0.3-2X11 Inter-Client Exchange library ii libjpeg62 6b-13The Independent JPEG Group's JPEG ii libmng1 1.0.9-1 Multiple-image Network Graphics li ii libpng12-0 1.2.15~beta5-2 PNG library - runtime ii libqt4-core 4.3.0-2 Qt 4 core non-GUI functionality ru ii libsm6 2:1.0.3-1X11 Session Management library ii libstdc++6 4.2-20070627-1 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1:1.1.8-2X cursor management library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxrandr2 2:1.2.1-1X11 RandR extension library ii libxrender1 1:0.9.2-1X Rendering Extension client libra ii libxt6 1:1.0.5-3X11 toolkit intrinsics library ii zlib1g 1:1.2.3.3.dfsg-3 compression library - runtime Versions of packages libqt4-gui recommends: ii qt4-qtconfig 4.3.0-2Qt 4 configuration tool -- no debconf information Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46965083988992 (LWP 23832)] 0x2ab6e312523a in QObject::parent (this=0x0) at ../../include/QtCore/../../src/corelib/kernel/qobject.h:213 213 ../../include/QtCore/../../src/corelib/kernel/qobject.h: No such file or directory. in ../../include/QtCore/../../src/corelib/kernel/qobject.h Current language: auto; currently c++ (gdb) where #0 0x2ab6e312523a in QObject::parent (this=0x0) at ../../include/QtCore/../../src/corelib/kernel/qobject.h:213 #1 0x2ab6e313196b in QWidget::parentWidget (this=0x0) at ../../include/QtGui/../../src/gui/kernel/qwidget.h:949 #2 0x2ab6e316ad4f in QWidget::window (this=0x0) at kernel/qwidget.cpp:3340 #3 0x2ab6e3161fc7 in QWidget::topLevelWidget (this=0x0) at ../../include/QtGui/../../src/gui/kernel/qwidget.h:287 #4 0x2ab6e3161b19 in QToolTip::showText ([EMAIL PROTECTED], [EMAIL PROTECTED], w=0x0, [EMAIL PROTECTED]) at kernel/qtooltip.cpp:370 #5 0x2ab6e3161c1c in QToolTip::showText ([EMAIL PROTECTED], [EMAIL PROTECTED], w=0x0) at kernel/qtooltip.cpp:397 #6 0x2ab6e2846b10 in DragLabel::event () from /usr/lib/libLastFmTools.so.1 #7 0x2ab6e31285f5 in QApplicationPrivate::notify_helper (this=0x742880, receiver=0x886590, e=0x7fffc84abb40) at kernel/qapplication.cpp:3538 #8 0x2ab6e3129f15 in QApplication::notify (this=0x7fffc84ac8e0, receiver=0x886590, e=0x7fffc84abb40) at kernel/qapplication.cpp:3381 #9 0x2ab6e3e128ba in QCoreApplication::notifyInternal (this=0x7fffc84ac8e0, receiver=0x886590, event=0x7fffc84abb40) at kernel/qcoreapplication.cpp:509 #10 0x2ab6e3125911 in QCoreApplication::sendEvent (receiver=0x886590, event=0x7fffc84abb40) at
Bug#430907: libqt4-gui: Artifacts in system tray icons
Package: libqt4-gui Version: 4.3.0-2 Severity: normal After I upgraded to Qt 4.3.0-2 I noticed artifacts in the system tray icon for lastfm. They were not there in 4.3.0-1. It has something to do with 00_0182-argb-visuals-default.dpatch. Backing that out gets rid of the artifacts. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20-3.amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libqt4-gui depends on: ii fontconfig 2.4.2-1.2generic font configuration library ii libaudio2 1.9-2The Network Audio System (NAS). (s ii libc6 2.5-11 GNU C Library: Shared libraries ii libfontconfig1 2.4.2-1.2generic font configuration library ii libfreetype62.2.1-6 FreeType 2 font engine, shared lib ii libgcc1 1:4.2-20070609-1 GCC support library ii libgl1-mesa-glx [libgl1 6.5.2-5 A free implementation of the OpenG ii libglib2.0-02.12.12-1The GLib library of C routines ii libglu1-mesa [libglu1] 6.5.2-5 The OpenGL utility library (GLU) ii libice6 1:1.0.3-2X11 Inter-Client Exchange library ii libjpeg62 6b-13The Independent JPEG Group's JPEG ii libmng1 1.0.9-1 Multiple-image Network Graphics li ii libpng12-0 1.2.15~beta5-2 PNG library - runtime ii libqt4-core 4.3.0-2 Qt 4 core non-GUI functionality ru ii libsm6 2:1.0.3-1X11 Session Management library ii libstdc++6 4.2-20070609-1 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1:1.1.8-2X cursor management library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxrandr2 2:1.2.1-1X11 RandR extension library ii libxrender1 1:0.9.2-1X Rendering Extension client libra ii libxt6 1:1.0.5-3X11 toolkit intrinsics library ii zlib1g 1:1.2.3.3.dfsg-2 compression library - runtime Versions of packages libqt4-gui recommends: ii qt4-qtconfig 4.3.0-2Qt 4 configuration tool -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#430907: libqt4-gui: Artifacts in system tray icons
Actually this is creating artifacts in several places. Using lastfm again, if I shorten the window height and scroll the main window or sidebar up and down, artifacts will appear everywhere inside the widget. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429786: lastfm: segfaults on exit
I recently noticed occasional segfaults too, but I haven't had time to track them down yet. However, upstream should be releasing 1.3 real soon now. It behaves much better: layout errors gone, no segfaults on exit. Regards, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426955: I can only hear terrible noise instead of music
Strange. I haven't heard of that happening before, but then I saw this in one of the forums today: http://www.last.fm/forum/34905/_/288262 There are a few more bits of info I'd like: If you downgrade to 1.1.90-4 that fixes the problem? Upgrading to 1:1.1.3.0-3 plays static again? What card/device does the client report in Tools | Options | Radio? Please attach ~/.lastfm/playback.log and ~/.lastfm/transcode.log? Cheers, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399698: lastfm: width of window not adjustable(song title not fully visible)
On Tuesday 21 November 2006, Kevin Mark wrote: Hi, the window does not display the full title of the song. I'd like to be able to read the full song title. So can you either make the window resize to show the title, make the font adjustable, or maybe make a tooltip with the full title. This is fixed in the latest version in unstable: 1.1.3.0 Also is there anyway to make the album image any bigger? 'X%' box to make it bigger? Cheers, Kev The album images are now larger than before, but fixed at 137x137. Let me know if this takes care of the problem, or if you'd still like to keep the bug open for the sake of the image size. Cheers, John Stamp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369301: lastfm: External player problems and possible policy violation
Regarding svn and the license: Upstream has the source available on their downloads page: http://www.last.fm/download/ And their public svn repository contains the source for released versions of the newer client. It is currently here: svn://svn.audioscrobbler.net/client/Audioscrobbler/tags The LICENSE/COPYING confusion that you talked about is cleared up. It's pretty clearly GPL and GPL-compatible to me. Regarding the bug when playing to an external player: Upstream 'fixed' it by getting rid of that feature. Lastfm no longer supports external players; it now only supports ALSA output. As you said, the best alternative for playing to an external player is lastfmproxy. It's now in testing/unstable. Cheers, John Stamp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382206: mc crash when pressing F5,F6
I have the same problem. If mc starts with the right panel as the Info panel, pressing F5 or F6 causes a segfault. When it crashes, valgrind reports the following: Invalid read of size 4 in file_mask_dialog (filegui.c:948) Testing for the existence of right_panel fixes the segfault for me, so it looks like it may be a problem in 60_recode.patch. Fix attached. Best, John 61_nosegfault.patch.gz Description: GNU Zip compressed data
Bug#382206: mc crash when pressing F5,F6
Oops. It looks like I sent an incomplete fix. There is a similar problem with left_panel if mc starts up with the view reversed (Info left, Listing right). This revised patch should take care of both. John 61_nosegfault.patch.gz Description: GNU Zip compressed data
Bug#372258: kwalletmanager does not appear in kde system tray
It looks like bugs 372564 and 372258 are both related to this change: http://websvn.kde.org/branches/KDE/3.5/kdeutils/kwallet/kwalletmanager.cpp?rev=545035view=rev John Stamp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#372564: kwalletmanager very often crashes at KDE Logout
It looks like a problem with a patch in Debian's kdeutils branch update
(r548145).
Under certain circumstances, kwalletmanager exits and deletes _dcopRef
before it's actually been created. We just need to create _dcopRef
earlier. I've attached a slight modification to the patch that seems to
fix it for me.
John
--- kwallet/kwalletmanager.cpp
+++ kwallet/kwalletmanager.cpp
@@ -55,22 +55,31 @@
_shuttingDown = false;
KConfig cfg(kwalletrc); // not sure why this setting isn't in kwalletmanagerrc...
KConfigGroup walletConfigGroup(cfg, Wallet);
+ _dcopRef = new DCOPRef(kded, kwalletd);
if (walletConfigGroup.readBoolEntry(Launch Manager, true)) {
_tray = new KSystemTray(this, kwalletmanager tray);
_tray-setPixmap(loadSystemTrayIcon(wallet_closed));
QToolTip::add(_tray, i18n(KDE Wallet: No wallets open.));
- connect(_tray,SIGNAL(quitSelected()),SLOT(shuttingDown()));
+ connect(_tray, SIGNAL(quitSelected()), SLOT(shuttingDown()));
QStringList wl = KWallet::Wallet::walletList();
+ bool isOpen = false;
for (QStringList::Iterator it = wl.begin(); it != wl.end(); ++it) {
if (KWallet::Wallet::isOpen(*it)) {
_tray-setPixmap(loadSystemTrayIcon(wallet_open));
QToolTip::remove(_tray);
QToolTip::add(_tray, i18n(KDE Wallet: A wallet is open.));
+isOpen = true;
break;
}
}
+ if (!isOpen kapp-isRestored()) {
+ delete _tray;
+ _tray = 0L;
+ kapp-exit();
+ return;
+ }
} else {
- _tray = 0;
+ _tray = 0L;
}
_iconView = new KWalletIconView(this, kwalletmanager icon view);
@@ -81,7 +90,6 @@
setCentralWidget(_iconView);
_iconView-setMinimumSize(320, 200);
- _dcopRef = new DCOPRef(kded, kwalletd);
_dcopRef-dcopClient()-setNotifications(true);
connect(_dcopRef-dcopClient(),
SIGNAL(applicationRemoved(const QCString)),
Bug#372564: kwalletmanager very often crashes at KDE Logout
Duh. Well that was a dumb way for me to submit a new patch.
How about this instead? Drop 14_kwalletmanager.diff in debian/patches and
recompile.
John
diff -urN kdeutils-3.5.3.orig/kwallet/kwalletmanager.cpp kdeutils-3.5.3/kwallet/kwalletmanager.cpp
--- kdeutils-3.5.3.orig/kwallet/kwalletmanager.cpp 2006-06-13 14:00:19.0 -0700
+++ kdeutils-3.5.3/kwallet/kwalletmanager.cpp 2006-06-13 14:01:05.0 -0700
@@ -55,6 +55,7 @@
_shuttingDown = false;
KConfig cfg(kwalletrc); // not sure why this setting isn't in kwalletmanagerrc...
KConfigGroup walletConfigGroup(cfg, Wallet);
+ _dcopRef = new DCOPRef(kded, kwalletd);
if (walletConfigGroup.readBoolEntry(Launch Manager, true)) {
_tray = new KSystemTray(this, kwalletmanager tray);
_tray-setPixmap(loadSystemTrayIcon(wallet_closed));
@@ -89,7 +90,6 @@
setCentralWidget(_iconView);
_iconView-setMinimumSize(320, 200);
- _dcopRef = new DCOPRef(kded, kwalletd);
_dcopRef-dcopClient()-setNotifications(true);
connect(_dcopRef-dcopClient(),
SIGNAL(applicationRemoved(const QCString)),
Bug#364789: amarok: Amarok 1.4 beta3 needs latest libgpod cvs
Package: amarok Version: 1.4-beta3c-1 Severity: normal Starting with 1.4 beta 3, my iPod Photo would no longer work with Amarok. Instead, a console debug message would say: Media device: device type detection failed, assuming iPod shuffle Apparently, this is because Amarok changed ipodmediadevice.cpp to rely on the most recent cvs of libgpod. Building Amarok with libgpod cvs fixes the problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327118: amarok: Amarok 1.3.1 fails to play live365 streams
On Tuesday 20 September 2005 06:45 pm, Adeodato Simó wrote: I can't reproduce this with amarok 1.3.1-2 and the XINE engine. The culprit is KDE svn revision 450956. I've attached a patch that reverts the relevant bits. Unpatched amarok 1.3.2 will not play the stream at: http://www.davidbyrne.com/radio/ The patched version has no problem. John Stamp live365-fix.diff.gz Description: GNU Zip compressed data
Bug#329484: kdesktop: Please add KDE Improvements patch for rounded edges on desktop icons
Package: kdesktop Version: 4:3.4.2-3 Severity: minor Tags: patch kdelibs already uses the KDE Improvements patch that creates rounded edges in Icon View. A similar patch is also available for desktop icons. I've attached the relevant patch. John Stamp -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (199, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-6 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Versions of packages kdesktop depends on: ii kdebase-bin 4:3.4.2-3 core binaries for the KDE base mod ii kdelibs4c24:3.4.2-4 core libraries for all KDE applica ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libaudio2 1.7-3 The Network Audio System (NAS). (s ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libfontconfig12.3.2-1generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.1-2 GCC support library ii libglu1-xorg [libglu1]6.8.2.dfsg.1-7 Mesa OpenGL utility library [X.Org ii libice6 6.8.2.dfsg.1-7 Inter-Client Exchange library ii libidn11 0.5.18-1 GNU libidn library, implementation ii libjpeg62 6b-10 The Independent JPEG Group's JPEG ii libkonq4 4:3.4.2-3 core libraries for Konqueror ii libpng12-01.2.8rel-1 PNG library - runtime ii libqt3-mt 3:3.3.5-1 Qt GUI Library (Threaded runtime v ii libsm66.8.2.dfsg.1-7 X Window System Session Management ii libstdc++64.0.1-2The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-7 X Window System protocol client li ii libxcursor1 1.1.3-1X cursor management library ii libxext6 6.8.2.dfsg.1-7 X Window System miscellaneous exte ii libxft2 2.1.7-1FreeType-based font drawing librar ii libxi66.8.2.dfsg.1-7 X Window System Input extension li ii libxinerama1 6.8.2.dfsg.1-7 X Window System multi-head display ii libxrandr26.8.2.dfsg.1-7 X Window System Resize, Rotate and ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxss1 6.8.2.dfsg.1-7 X Screen Saver client-side library ii libxt66.8.2.dfsg.1-7 X Toolkit Intrinsics ii libxxf86misc1 6.8.2.dfsg.1-7 X miscellaneous extensions library ii xlibmesa-gl [libgl1] 6.8.2.dfsg.1-7 Mesa 3D graphics library [X.Org] ii xlibs 6.8.2.dfsg.1-7 X Window System client libraries m ii zlib1g1:1.2.3-4 compression library - runtime Versions of packages kdesktop recommends: ii eject 2.0.13deb-13 ejects CDs and operates CD-Changer -- no debconf information kdebase_desktop_roundedge-icons.diff.gz Description: Binary data
Bug#327118: amarok: Amarok 1.3.1 fails to play live365 streams
On Tuesday 20 September 2005 06:45 pm, Adeodato Simó wrote: I can't reproduce this with amarok 1.3.1-2 and the XINE engine. Hmmm... That is odd. erika.net seems to work for me now. However Radio David Byrne is still having this trouble. http://www.davidbyrne.com/radio/ Specific instructions: 1. click to play the stream at the address above. 2. save the shoutcast playlist file. It will default to play.pls 3. drop playlist on app. xmms will play music; amarok 1.3.1-2 will play an error message As before, amarok 1.3.0 has no problem playing the stream. If you still can't reproduce this, then I apologize for the trouble. John Stamp
Bug#327118: amarok: Amarok 1.3.1 fails to play live365 streams
Package: amarok Version: 1.3.1-2 Severity: normal Amarok 1.3.0 was able to play live365 streams such as http://erika.net/erika.pls However 1.3.1 plays an audio error message: ding 8502: problem detected with your login session. Please verify that you are logged in properly, and try listening again. I tried using xine and gstreamer engines. Both had the same problem. Downgrading to 1.3.0 lets me play the stream again. John Stamp -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (500, 'stable'), (400, 'testing'), (200, 'unstable'), (199, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-6 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Versions of packages amarok depends on: ii amarok-arts [amarok-engin 1.3.1-2aRts engine for the amaroK audio p ii amarok-gstreamer [amarok- 1.3.1-2GStreamer engine for the amaroK au ii amarok-xine [amarok-engin 1.3.1-2xine engine for the amaroK audio p ii kdelibs4c24:3.4.2-3 core libraries for all KDE applica ii libaudio2 1.7-2 The Network Audio System (NAS). (s ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libfontconfig12.3.2-1generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.1-2 GCC support library ii libice6 6.8.2.dfsg.1-6 Inter-Client Exchange library ii libmysqlclient14 4.1.13a-3 mysql database client library ii libpng12-01.2.8rel-1 PNG library - runtime ii libpq48.0.3-7PostgreSQL C client library ii libqt3-mt 3:3.3.4-7 Qt GUI Library (Threaded runtime v ii libsm66.8.2.dfsg.1-6 X Window System Session Management ii libstdc++64.0.1-2The GNU Standard C++ Library v3 ii libtag1c2 1.3.1-1.1 TagLib Audio Meta-Data Library ii libtunepimp2c20.3.0-8MusicBrainz tagging library and si ii libx11-6 6.8.2.dfsg.1-6 X Window System protocol client li ii libxcursor1 1.1.3-1X cursor management library ii libxext6 6.8.2.dfsg.1-6 X Window System miscellaneous exte ii libxft2 2.1.7-1FreeType-based font drawing librar ii libxinerama1 6.8.2.dfsg.1-6 X Window System multi-head display ii libxrandr26.8.2.dfsg.1-6 X Window System Resize, Rotate and ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt66.8.2.dfsg.1-6 X Toolkit Intrinsics ii xlibmesa-gl [libgl1] 6.8.2.dfsg.1-6 Mesa 3D graphics library [X.Org] ii xlibs 6.8.2.dfsg.1-6 X Window System client libraries m ii zlib1g1:1.2.3-4 compression library - runtime Versions of packages amarok recommends: ii kdemultimedia-kio-plugins 4:3.4.2-2 enables the browsing of audio CDs -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310004: unison: Assertion failed error when syncing some files
Package: unison Version: 2.10.2-2 Severity: important Tags: patch If the properties of a file changed on one host and its content changed on another, then trying to synchronize the files will result in the following error: Uncaught exception File /tmp/buildd/unison-2.10.2/transport.ml, line 21, characters 6-12: Assertion failed This is fixed in current beta version 2.12.0. I've attached a small patch from it which I think will take care of the problem. John Stamp -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (400, 'testing'), (200, 'unstable'), (199, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11-5 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages unison depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an -- no debconf information unison-assertion-fix.diff.gz Description: Binary data
Bug#300115: USB support for manufacturers other than MGE
Package: nut-usb Version: 2.0.1-2.1 Followup-For: Bug #300115 I've attached the lsusb and newhidups output for an APC Back-UPS ES 500. Let me know if you'd like further info. John Stamp -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (400, 'testing'), (200, 'unstable'), (199, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11-3 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages nut-usb depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libusb-0.1-42:0.1.10a-6 userspace USB programming library ii libusb-dev 2:0.1.10a-6 userspace USB programming library ii nut 2.0.1-2.1The core system of the nut - Netwo -- no debconf information lsusb-output.txt.gz Description: Binary data newhidups-output.txt.gz Description: Binary data
Bug#299755: Multiple fixes for kuake
Package: kuake Version: 0.3-12 Severity: normal Tags: patch I've made some minor patches to my copy of kuake that you might find useful. The patch does several things: * Don't reimplement windowActivationChange. It minimizes kuake far too often (when new app opens, when a tray app closes, etc.) Probably fixes bug #298970 * Don't open resize dialog on starup when using a custom kuake size. Fixes bug #299685 * Setting custom size changes kuake the *first* time it's set * Make it a KUniqueApplication * Workaround formatting problems for fortunes. * Set kuake so initial state is always minimized. * Add an eventsrc file (lifted from konsole) so we get notifications. * Let kuake restore old active window when the toggle button is pushed -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (400, 'testing'), (200, 'unstable'), (199, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.11ac3 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kuake depends on: ii kdelibs4 4:3.3.2-4.1 KDE core libraries ii libart-2.0-2 2.3.17-1Library of functions for 2D graphi ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libfam0c102 2.7.0-6 client library to control the FAM ii libgcc1 1:3.4.3-6 GCC support library ii libice6 4.3.0.dfsg.1-12.0.1 Inter-Client Exchange library ii libidn11 0.5.13-1.0 GNU libidn library, implementation ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libqt3c102-mt3:3.3.3-8.1 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0.dfsg.1-12.0.1 X Window System Session Management ii libstdc++5 1:3.3.5-8 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-12.0.1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-12.0.1 X Window System miscellaneous exte ii libxrender1 0.8.3-7 X Rendering Extension client libra ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-3 compression library - runtime -- no debconf information kuake-0.3-fix.diff.gz Description: Binary data
