Bug#669132: libgpod4 and libgpod4-nogtk lack packages with debugging information
Package: libgpod4 Version: 0.8.2-6 Both libgpod4 and libgpod4-nogtk packages have no debugging packages in Debian repositories, which makes debugging crashes related to libgpod impossible for Debian users. I'm an Amarok developer working on iPod support and we've faced multiple users with crashes and useless backtraces, see [1] and [2]. [1] https://bugs.kde.org/show_bug.cgi?id=287426 [2] https://bugs.launchpad.net/ubuntu/+source/libgpod/+bug/898002 Cheers, Matěj Laitl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658538: Further explanation
Hello, to explain further, in order for libgpod to be able to actually write valid iPod database on all new models, it needs to know its model, firewire id and sometimes more. This information is automatically extracted thanks to udev hook from libgpod-common and written to iPod/iPod_Control/Device/SysInfoExtended every time iPod is plugged in. I'm an Amarok developer working on iPod support and we've faces several users who found their iPod unusable because of missing SysInfoExtended file. For more information please see [1]. [1] http://gtkpod.git.sourceforge.net/git/gitweb.cgi?p=gtkpod/libgpod;a=blob;f=README.overview Regards, Matěj Laitl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658538: Further explanation
On 4. 2. 2012 Chow Loong Jin wrote:
Considering libgpod4-nogtk (and presumably the gtk one as well) are, as you
mentioned, practically useless without the -common package, do you think
libgpod-common should be bumped up to Depends for both packages instead?
Yes, that would be best from my point of view. libgpod can be successfully
used without libgpod-common _only_ under special circumstances, namely with:
* iPods older than like 3 years
* iPods that were previously connected to a PC that has libgpod-common
installed.
With a couple of additional downsides:
* while older iPods can work, users loose auto-detection of iPod model
* AFAIK libgpod developers assume that the package is never broken into -lib
and -common
This would crate circular dependency between libgpod4{,-nogtk} and libgpod-
common, but I think this is okay as they come from the same source package.
libgpod-common itself is pretty small (28974 on Ubuntu), so it should be
pretty harmless to move it to Depends in my opinion.
Indeed.
Matěj
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658538: Further explanation
On 4. 2. 2012 Chow Loong Jin wrote:
Sounds like Depends would be the right choice here...
This would crate circular dependency between libgpod4{,-nogtk} and
libgpod-
common, but I think this is okay as they come from the same source
package.
...But this sounds like a real problem. It's not okay for circular
dependencies to happen even if they're from the same source package[1].
Perhaps we'll have to just go with Recommends.
Thanks for spotting this before I made the upload.
[...]
[1] http://lists.debian.org/debian-devel/2005/06/msg02111.html (#5 under
Why?)
I see. Unfortunately, #1 under How? in [1] cannot be applied as some
executables from libgpod-common actually link libgpod:
strohel@edgy ~ $ ldd /lib/udev/ipod-set-info /usr/bin/ipod-read-sysinfo-
extended | grep gpod
libgpod.so.4 = /usr/lib64/libgpod.so.4 (0x7f198d192000)
libgpod.so.4 = /usr/lib64/libgpod.so.4 (0x7fb3aa949000)
How strong is the Recommends dependency? E.g. when an an ordinary user
installs amarok from her favourite gui/cli, which then pulls libgpod, will it
pull libgpod-common if it were Recommended by libgpod?
If so, this kind of dependency would be fine.
Disclaimer: I'm not a Debian user (I'm rather a Gentoo guy) so I have nearly
no knowledge of .deb packaging system, nonetheless I enjoy such cross-distro
knowledge sharing.
Matěj
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#464191: Sound broken with linux-image-2.6.24-1-686
On Thursday 07 of February 2008 08:09:24 Mikko Nurminen wrote: Package alsa-firmware-loaders doesn't seem to handle a module for these chips. This is not the right package, the right one is just alsa-firmware, which is evidently not packaged in Debian. You can get it from the alsa project, e.g.: ftp://ftp.alsa-project.org/pub/firmware/ Please note that this package does not contain the module, only firmware, which is needed by the in-kernel module. (The firmware needs to be installed somewhere where the kernel finds it, usually something like this: /lib/firmware/ess/maestro3_assp_kernel.fw /lib/firmware/ess/maestro3_assp_minisrc.fw) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464191: Sound broken with linux-image-2.6.24-1-686
Hi, while I'm not a Debian user, I think I am able to point you at the potentional root of this problem. I saw following line your dmesg: Maestro3: probe of :00:0d.0 failed with error -2 The cause is probably the missing firmware for your card. The firmware can be either embedded into the kernel or distributed alone, depending on the CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL kernel config option. See following lines from kernel's sound/pci/maestro3.c: 61 #ifndef CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL 62 MODULE_FIRMWARE(ess/maestro3_assp_kernel.fw); 63 MODULE_FIRMWARE(ess/maestro3_assp_minisrc.fw); 64 #endif So in order for this card to work, you need either package with firmware (alsa-firmware usually) or CONFIG_SND_MAESTRO3_FIRMWARE_IN_KERNEL option enabled. I guess Debian switched this option from yes to no between kernel versions. Regards, Matěj Laitl
