Bug#579110: acpid: fails to power off system on suspend to ram/disk
Package: acpid Version: 1:2.0.3-1 Severity: important Tags: sid After upgrading to 2.0.4 the system doesn't power off after suspending to RAM / disk. I.e. it looks like like it's suspending as normal but at the point when the screen normally goes blank and the system fans / disks power off, the system remains powered on. In this state the system is pretty much dead, so I have to press the reset or the power button before I can reboot the machine. Downgrading only this package to 2.0.3 fixes the problem for me. Further observations: * Suspend to disk never worked for me so far (acpid 2.0.3) (the system would suspend and power off, it also resumes as expected up to the point where I would expect to get control back; instead I'm stuck watching at a sleeping Penguin). If I suspend now (acpid 2.0.4) this behaviour doesn't change with the difference that I have to manually power off the suspended machine. I.e. after manually powering off and rebooting the same kernel, the system is indeed resuming from disk but I'm still stuck with the sleeping penguin. So apparently it's only the 'switch off' command that's not issued (or accepted) anymore. * The mainboard is an MSI 785GM-E51. s2ram identifies my machine as: " This machine can be identified by: sys_vendor = "MICRO-STAR INTERNATIONAL CO.,LTD" sys_product = "MS-7596" sys_version = "1.0" bios_version = "V2.5" " * Downgrading the BIOS to V2.4 doesn't fix this. * I'm using the nvidia proprietary graphics driver (Version 190.53-4). * I have the vmware player installed (Version 3.0.1 build-227600) * All the rest is what I'd regard a pretty stock debian sid. If this isn't enough information, please let me know. /Andreas -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-myamd64 (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 Versions of packages acpid depends on: ii libc62.10.2-7Embedded GNU C Library: Shared lib ii lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip ii module-init-tools3.12~pre2-3 tools for managing Linux kernel mo Versions of packages acpid recommends: ii acpi-support-base 0.133-2scripts for handling base ACPI eve acpid 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#579110: [Pkg-acpi-devel] Bug#579110: acpid: fails to power off system on suspend to ram/disk
Umm, now this is embarassing. Before submiting the bug I reproduced both the bad and the good behaviour but now it turns out I can't reproduce it anymore. Please close it and forget that I even opened it. Sorry. Best, Andreas On Sun, Apr 25, 2010 at 15:28, Michael Meskes wrote: > On Sun, Apr 25, 2010 at 02:14:39PM +0200, Andreas Schneider wrote: >> After upgrading to 2.0.4 the system doesn't power off after suspending to >> RAM / >> disk. I.e. it looks like like it's suspending as normal but at the point when > > How do you suspend? > >> Downgrading only this package to 2.0.3 fixes the problem for me. > > This surprises me. Are you sure this is the only difference? From what you're > describing I cannot see how it's acpid related at all. > > Btw. here are the changes between 2.0.3 and 2.0.4: > > - Replaced all the mandb code in the makefile with a comment. (Makefile) > - Revamped logging. (acpid.c event.c inotify_handler.c input_layer.c > netlink.c proc.c sock.c) > - Removed CR's (\r) from files. (Changelog connection_list.c sock.c) > - Cleaned up the samples directory a bit. Also added powerbtn samples taken > from Debian. (samples/*) > - Removed the %changelog token from the top of the Changelog. This appears > to be a Red Hat-ism. > > Hardly anything that can produce the described problem. > >> If this isn't enough information, please let me know. > > You know that acpid only listens to some interfaces for acpi events and then > executes script accordingly? The functionality you describe is located in the > kernel, I cannot see how acpid has any influence. Could you please check that > you have the same set of modules installed when testing with 2.0.3 and 2.0.4? > > michael > -- > Michael Meskes > Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) > Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org > ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org > VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559964: lomoco: udev rules are out of date and hence do not function
On Tuesday 08 December 2009 11:41:24 Thibaut VARENE wrote:
> I'm considering orphaning lomoco.
>
If you want to update the packages, patches are attached. Well lomoco in this
state is finished. You just have to deal with the udev crap. New mice have to
be configured differently and I couldn't reverse engineer the protocol
completely yet. There is still a bit missing to identify cordless mice.
-- andreas
Index: lomoco-1.0/src/lomoco.c
===
--- lomoco-1.0.orig/src/lomoco.c
+++ lomoco-1.0/src/lomoco.c
@@ -42,6 +42,7 @@ mouse_t mice [] = {
{0xc012, "MouseMan Dual Optical", "M-BL63B", 0, 1, 0, 0, 0},
{0xc01d, "MX510 Optical Mouse","M-BS81A", 0, 1, 1, 1, 0},
{0xc01e, "MX518 Optical Mouse","M-BS81A", 0, 1, 1, 0, 0},
+ {0xc051, "MX518 Optical Mouse-2", "M-BS81A", 0, 1, 1, 0, 0},
{0xc024, "MX300 Optical Mouse","M-BP82", 0, 1, 0, 0, 0},
{0xc01b, "MX310 Optical Mouse","M-BP86", 0, 1, 0, 0, 0},
{0xc025, "MX500 Optical Mouse","M-BP81A", 0, 1, 1, 1, 0},
Index: udev/toudev.awk
===
--- udev/toudev.awk.orig
+++ udev/toudev.awk
@@ -3,13 +3,15 @@ BEGIN {
FS = ","
print "ACTION != \"add\", GOTO=\"lomoco_end\""
print "SUBSYSTEM != \"usb\", GOTO=\"lomoco_end\""
- print "SYSFS{idVendor} != \"046d\", GOTO=\"lomoco_end\""
+ print "ENV{DEVTYPE} != \"usb_device\", GOTO=\"lomoco_end\""
+ print "ATTR{idVendor} != \"046d\", GOTO=\"lomoco_end\""
+
print ""
}
$1 ~ /0xc[a-f0-9][a-f0-9][a-f0-9]/ {
print "# " substr($3, index($3, "\"")) ", " $2
-print "SYSFS{idProduct}==\"" substr($1, index($1, "x")+1) \
+print "ATTR{idProduct}==\"" substr($1, index($1, "x")+1) \
"\", RUN=\"lomoco\""
}
tohal.awk
Description: application/awk
signature.asc
Description: This is a digitally signed message part.
Bug#582461: libssh config files
Thanks for reporting this bug and helping to find and understand it! Could you provide your /etc/ssh/ssh_config and ~/.ssh/config file that we could try to reproduce it on our system. If possible it would be nice to have a strace log. If you're using kio_sftp you find some information how to create it at: http://techbase.kde.org/Development/Tutorials/Debugging/Debugging_IOSlaves#Attaching_gdb_to_an_io- slave Instead of attaching gdb you have to attach strace with: strace -tt -T -o libssh.log -p -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#582461: libssh config files
On Thursday 27 May 2010 23:50:01 Yannick Roehlly wrote:
> Hi Andreas,
Hi Yannick,
> My system config file is the standard Debian one. Except for the commented
> lines, the configuration is this one:
>
> Host *
> SendEnv LANG LC_*
> HashKnownHosts yes
> GSSAPIAuthentication yes
> GSSAPIDelegateCredentials no
>
> My local (in home dir) configuration file only overrides HashKnownHosts to
> no and sets some host specific stuff like X11 forwarding, usernames or
> full hostnames (for aliases).
I don't think they cause the problem.
> I'm not at ease posting some security related traces on a public place (but
> I'm surely over paranoid). If we can't find the problem, I'll send one to
> you directly.
That would be great. I still wonder what is creating these strange
directories. It would be great if you could try to these problems. There
should be a mkdir() in the strace.
> Nevertheless, I've done some more testing tonight and it was weird because
> sometimes the known_hosts file is found, sometimes not; sometimes the
> identity file is found, sometimes not ("sometimes" a very helpful word
> indeed).
>
> I've manage to catch both case on log and when it fails, I have :
>
> access("SSH_DIR/id_rsa", R_OK) = -1 ENOENT (No such file or directory)
I've fixed this. I will ask bigon if he could create packages with the fix for
you for testing.
Cheers,
-- andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679577: reproducible; makes driver ver 302 unusable for me
same here. According to the PTS, it appears as if version 302.17-3 is about to be migrated to testing. If this is the case, then this would mean that weezy is unusable for me. Some extra info: I can ssh into the machine and stop the display manager. That way I don't have to reboot, but the usefulness of this workaround is of course very limited. After reboot this is in Xorg.0.log.old: ... [ 1062.639] (II) Open ACPI successful (/var/run/acpid.socket) [ 3266.187] (II) Open ACPI successful (/var/run/acpid.socket) [ 3266.298] (II) NVIDIA(0): Setting mode "DFP-0:nvidia-auto-select" [ 3269.936] [mi] EQ overflowing. Additional events will be discarded until existing events are processed. [ 3269.936] [ 3269.936] Backtrace: [ 3269.957] 0: /usr/bin/X (xorg_backtrace+0x36) [0x7fd4aa216796] [ 3269.957] 1: /usr/bin/X (mieqEnqueue+0x26b) [0x7fd4aa1f7a5b] [ 3269.957] 2: /usr/bin/X (0x7fd4aa098000+0x66a02) [0x7fd4aa0fea02] [ 3269.957] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fd4a2121000+0x55d8) [0x7fd4a21265d8] [ 3269.957] 4: /usr/bin/X (0x7fd4aa098000+0x8d697) [0x7fd4aa125697] [ 3269.957] 5: /usr/bin/X (0x7fd4aa098000+0xb1898) [0x7fd4aa149898] [ 3269.957] 6: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd4a93c+0xf030) [0x7fd4a93cf030] [ 3269.957] 7: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x878fd) [0x7fd4a2c8e8fd] [ 3269.957] 8: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x89235) [0x7fd4a2c90235] [ 3269.957] 9: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x104bb2) [0x7fd4a2d0bbb2] [ 3269.957] 10: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x521d97) [0x7fd4a3128d97] [ 3269.957] 11: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x5217f5) [0x7fd4a31287f5] [ 3269.957] 12: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x52199d) [0x7fd4a312899d] [ 3269.957] 13: /usr/bin/X (0x7fd4aa098000+0x11384d) [0x7fd4aa1ab84d] [ 3269.957] 14: /usr/bin/X (0x7fd4aa098000+0x4eedb) [0x7fd4aa0e6edb] [ 3269.957] 15: /usr/bin/X (0x7fd4aa098000+0x52e41) [0x7fd4aa0eae41] [ 3269.957] 16: /usr/bin/X (0x7fd4aa098000+0x41ed5) [0x7fd4aa0d9ed5] [ 3269.957] 17: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7fd4a80eaead] [ 3269.957] 18: /usr/bin/X (0x7fd4aa098000+0x421ad) [0x7fd4aa0da1ad] [ 3269.957] [ 3269.957] [mi] These backtraces from mieqEnqueue may point to a culprit higher up the stack. [ 3269.957] [mi] mieq is *NOT* the cause. It is a victim. [ 3279.851] [mi] EQ overflow continuing. 100 events have been dropped. [ 3279.851] [ 3279.851] Backtrace: [ 3279.851] 0: /usr/bin/X (xorg_backtrace+0x36) [0x7fd4aa216796] [ 3279.851] 1: /usr/bin/X (0x7fd4aa098000+0x66a02) [0x7fd4aa0fea02] [ 3279.851] 2: /usr/bin/X (xf86PostKeyboardEvent+0x4b) [0x7fd4aa1356db] [ 3279.851] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7fd4a2121000+0x5620) [0x7fd4a2126620] [ 3279.851] 4: /usr/bin/X (0x7fd4aa098000+0x8d697) [0x7fd4aa125697] [ 3279.851] 5: /usr/bin/X (0x7fd4aa098000+0xb1898) [0x7fd4aa149898] [ 3279.851] 6: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fd4a93c+0xf030) [0x7fd4a93cf030] [ 3279.851] 7: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x878fd) [0x7fd4a2c8e8fd] [ 3279.851] 8: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x89235) [0x7fd4a2c90235] [ 3279.851] 9: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x104bb2) [0x7fd4a2d0bbb2] [ 3279.851] 10: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x521d97) [0x7fd4a3128d97] [ 3279.851] 11: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x5217f5) [0x7fd4a31287f5] [ 3279.851] 12: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7fd4a2c07000+0x52199d) [0x7fd4a312899d] [ 3279.851] 13: /usr/bin/X (0x7fd4aa098000+0x11384d) [0x7fd4aa1ab84d] [ 3279.851] 14: /usr/bin/X (0x7fd4aa098000+0x4eedb) [0x7fd4aa0e6edb] [ 3279.851] 15: /usr/bin/X (0x7fd4aa098000+0x52e41) [0x7fd4aa0eae41] [ 3279.851] 16: /usr/bin/X (0x7fd4aa098000+0x41ed5) [0x7fd4aa0d9ed5] [ 3279.851] 17: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7fd4a80eaead] [ 3279.851] 18: /usr/bin/X (0x7fd4aa098000+0x421ad) [0x7fd4aa0da1ad] [ 3279.851] Best, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#940925: freerdp2-x11: Option /gfx or /gfx-264:AVC444 crash when used with /sound Option
Package: freerdp2-x11 Version: 2.0.0~git20190204.1.2693389a+dfsg1-1 Severity: important Tags: patch Dear Maintainer, This problem is solved on the latest nighty build https://github.com/FreeRDP/FreeRDP/wiki/Compilation -> ln -s packaging/deb/freerdp-nightly debian dpkg-buildpackage -- System Information: Debian Release: 10.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-6-amd64 (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages freerdp2-x11 depends on: ii libc6 2.28-10 ii libfreerdp-client2-2 2.0.0~git20190204.1.2693389a+dfsg1-1 ii libfreerdp2-2 2.0.0~git20190204.1.2693389a+dfsg1-1 ii libwinpr2-2 2.0.0~git20190204.1.2693389a+dfsg1-1 ii libx11-6 2:1.6.7-1 ii libxcursor1 1:1.1.15-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes31:5.0.3-1 ii libxi62:1.7.9-1 ii libxinerama1 2:1.1.4-2 ii libxrandr22:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxv12:1.0.11-1 freerdp2-x11 recommends no packages. freerdp2-x11 suggests no packages. -- no debconf information
Bug#993051: avahi-daemon CPU usage increases over time
I have the exact same problem for quite some time already (certainly 6 months, likely more), using Debian sid. I'm surprised that this bug report is the only mention of the issue I could find on the net. It's reproducible every time I switch on my printer, but it takes quite some hours, in the order of a few days, before it turns into a significant problem. Running `sudo avahi-daemon -k` kills the process and a new one is started, which behaves well until I switch on my printer. It looks like Ryan already did what I was planning to do, i.e. debug through the daemon and do some Monte Carlo profiling. If there is anything I can do to help triage the problem, please let me know. For now I can only share details of my home setup that may or may not be helpful: the printer is an HP Deskjet-3630; DNS is handled by a FritzBox! but I believe the issue also showed up while I was using my home grown dnsmasq server. Best, Andreas
Bug#1013259: samba-libs: Possible policy violation (now with unnecessary soname bump libndr.so.2 => libndr.so.3)
On Tuesday, 1 November 2022 11:21:55 CET Michael Tokarev wrote: > 01.11.2022 13:14, Ralph Boehme wrote: > > On 11/1/22 09:15, Michael Tokarev via samba-technical wrote: > >> Control: tag -1 + upstream > >> > >> Original context was at http://bugs.debian.org/1013259 , but whole > >> thing *now* has is about completely unnecessary soname bump of libndr > >> in 4.17 due to debugging refinements. > > > > to me this looks like a packaging bug. > > It indeed is, I fixed it already. > > The question remains though: why the .3 bump happened in the first > place, due to a change just in a debug helper routine, which was > trivial to avoid (like I've shown in the patches just posted to > the list). libndr is not a stable API it can change any time! The only stable APIs in Samba are: libtalloc libtevent libtdb libsmbclient libwbclient libnetapi Andreas -- Andreas Schneider a...@samba.org Samba Team www.samba.org GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
Bug#1013259: samba-libs: Possible policy violation (now with unnecessary soname bump libndr.so.2 => libndr.so.3)
On Tuesday, 1 November 2022 11:21:55 CET Michael Tokarev via samba-technical wrote: > 01.11.2022 13:14, Ralph Boehme wrote: > > On 11/1/22 09:15, Michael Tokarev via samba-technical wrote: > >> Control: tag -1 + upstream > >> > >> Original context was at http://bugs.debian.org/1013259 , but whole > >> thing *now* has is about completely unnecessary soname bump of libndr > >> in 4.17 due to debugging refinements. > > > > to me this looks like a packaging bug. > > It indeed is, I fixed it already. See https://src.fedoraproject.org/rpms/samba/blob/rawhide/f/samba.spec#_148 -- Andreas Schneider a...@samba.org Samba Team www.samba.org GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
Bug#909652: RFP: abimap -- A helper for library maintainers to use symbol versioning
Package: wnpp Severity: wishlist This script allows to generate and update symbol version linker scripts which adds version information to the exported symbols. The script is intended to be integrated as part of a shared library build to check for changes in the set of exported symbols and update the symbol version linker script accordingly. URL: https://github.com/ansasaki/abimap License: MIT -- Andreas Schneider a...@samba.org Samba Team www.samba.org GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
Bug#785492: digikam: fails to detect Nikon D7000 after upgrade
Package: digikam Version: 4:4.4.0-1.1+b1 Severity: important Hello, after upgrading digikam to 4:4.4.0-1.1+b1 (from 4:4.4.0-1.1) it doesn't detect my Nikon D7000 anymore. This is the output on the commandline after the starting digikam and connecting the camera via USB for both versions: " $ digikam Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QString) Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QString) digikam(14730)/digikam (core) Digikam::DigikamApp::checkSolidCamera: Solid returns unsupported driver handle for gphoto2 digikam(14730)/digikam (core) Digikam::DigikamApp::checkSolidCamera: Solid returns unsupported driver handle for gphoto2 " Now when I click "Import" -> "Cameras" -> "D7000" the old version opens the import window and echoes this: " digikam(14730)/digikam (core) Digikam::ImportStackedView::syncSelection: one or both of the models are null?! from: Digikam::ImportIconView(0x3e16b10) to: Digikam::ImportThumbnailBar(0x3e4cdd0) " which seems to be ok, whereas the new version does not open the window and echoes this: " digikam(11276)/digikam (core): Failed to detect camera with GPhoto2 from Solid information " The downgrade to the working version involves downgrading digikam, digikam- private-libs, and kipi-plugins to version 4:4.4.0-1.1 and installing the dependency libgphoto2-port10 (version 2.5.4-1.1+b2). Best, Andreas -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages digikam depends on: ii digikam-data 4:4.4.0-1.1 ii digikam-private-libs 4:4.4.0-1.1+b1 ii kde-runtime 4:4.14.2-2 ii libc6 2.19-18 ii libgcc1 1:5.1.1-5 ii libkdcraw23 4:4.14.0-1 ii libkdecore5 4:4.14.2-5 ii libkdeui5 4:4.14.2-5 ii libkexiv2-11 4:4.14.2-1 ii libkhtml5 4:4.14.2-5 ii libkio5 4:4.14.2-5 ii libkipi11 4:4.13.3-1 ii libknotifyconfig4 4:4.14.2-5 ii libkparts44:4.14.2-5 ii libopencv-core2.4 2.4.9.1+dfsg-1+b1 ii libopencv-imgproc2.4 2.4.9.1+dfsg-1+b1 ii libphonon44:4.8.0-5 ii libqt4-dbus 4:4.8.6+git155-g716fbae+dfsg-2 ii libqt4-sql4:4.8.6+git155-g716fbae+dfsg-2 ii libqt4-sql-sqlite 4:4.8.6+git155-g716fbae+dfsg-2 ii libqt4-xml4:4.8.6+git155-g716fbae+dfsg-2 ii libqtcore44:4.8.6+git155-g716fbae+dfsg-2 ii libqtgui4 4:4.8.6+git155-g716fbae+dfsg-2 ii libsolid4 4:4.14.2-5 ii libstdc++65.1.1-5 ii libthreadweaver4 4:4.14.2-5 ii perl 5.20.2-6 ii phonon4:4.8.0-5 Versions of packages digikam recommends: ii chromium [www-browser] 42.0.2311.135-2 ii iceweasel [www-browser] 38.0-1 ii kipi-plugins 4:4.4.0-1.1+b1 ii konqueror [www-browser] 4:4.14.2-1 ii mplayerthumbs4:4.14.0-1 ii w3m [www-browser]0.5.3-21 Versions of packages digikam suggests: pn digikam-doc ii systemsettings 4:4.11.13-2 -- 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#785492: digikam: fails to detect Nikon D7000 after upgrade
Package: digikam Followup-For: Bug #785492 Reply by the OP: updating to the hot-off-the-press version 4:4.4.0-1.1+b2 fixes this bug. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.0.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages digikam depends on: ii digikam-data 4:4.4.0-1.1 ii digikam-private-libs 4:4.4.0-1.1+b2 ii kde-runtime 4:4.14.2-2 ii libc6 2.19-18 ii libgcc1 1:5.1.1-6 ii libgphoto2-6 2.5.7-5 ii libgphoto2-port12 2.5.7-5 ii libkdcraw23 4:4.14.0-1 ii libkdecore5 4:4.14.2-5 ii libkdeui5 4:4.14.2-5 ii libkexiv2-11 4:4.14.2-1 ii libkhtml5 4:4.14.2-5 ii libkio5 4:4.14.2-5 ii libkipi11 4:4.13.3-1 ii libknotifyconfig4 4:4.14.2-5 ii libkparts44:4.14.2-5 ii libopencv-core2.4 2.4.9.1+dfsg-1.1 ii libopencv-imgproc2.4 2.4.9.1+dfsg-1.1 ii libphonon44:4.8.0-5 ii libqt4-dbus 4:4.8.6+git155-g716fbae+dfsg-2 ii libqt4-sql4:4.8.6+git155-g716fbae+dfsg-2 ii libqt4-sql-sqlite 4:4.8.6+git155-g716fbae+dfsg-2 ii libqt4-xml4:4.8.6+git155-g716fbae+dfsg-2 ii libqtcore44:4.8.6+git155-g716fbae+dfsg-2 ii libqtgui4 4:4.8.6+git155-g716fbae+dfsg-2 ii libsolid4 4:4.14.2-5 ii libstdc++65.1.1-6 ii libthreadweaver4 4:4.14.2-5 ii perl 5.20.2-6 ii phonon4:4.8.0-5 Versions of packages digikam recommends: ii chromium [www-browser] 42.0.2311.135-2 ii iceweasel [www-browser] 38.0.1-1 ii kipi-plugins 4:4.4.0-1.1+b2 ii konqueror [www-browser] 4:4.14.2-1 ii mplayerthumbs4:4.14.0-1 ii w3m [www-browser]0.5.3-21 Versions of packages digikam suggests: pn digikam-doc ii systemsettings 4:4.11.13-2 -- 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#821178: resolved
Hi, I tried the new digikam 5 that just hit unstable and the problem doesn't show up there anymore. -> feel free to close this bug. Andreas
Bug#821178: further info
Hello maintainers, Here is some further information regarding the root cause of the problem (courtesy of Matthias Popp): it looks like libgphoto2 didn't make it into the dependencies, which in turn seems to be due to a problem with libusb-1.0.0 which isn't found (or rather recognized) during the build process. Hth, Andreas
Bug#821178: digikam: fails to detect Nikon D7000 after upgrade (again)
Package: digikam Version: 4:4.14.0-4+b1 Severity: important Hello, after upgrading from 4.14.0-3 to 4.14.0-4 digikam isn't able to import from my camera (Nikon D7000) anymore. This is the same issue as I had previously (reported as bug #785492) back then with version 4:4.4.0-1.1+b1 and that disappeared with version 4:4.4.0-1.1+b2. The symptom is that I can click on "Import" -> "Cameras" -> "NIKON NIKON DSC D7000 (auto-detected)" but it doesn't open the import window. What the new version prints to stdout (or stderr; didn't check) is " digikam(4565)/digikam (core): Failed to detect camera with GPhoto2 from Solid information " This works after a downgrade to version 4.14.0-3 of digikam, digikam-data, digikam-private-libs, kipi-plugins, kipi-plugins-common. Best, Andreas -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages digikam depends on: ii digikam-data4:4.14.0-4 ii digikam-private-libs4:4.14.0-4+b1 ii kde-runtime 4:15.08.3-1+b1 ii libc6 2.22-6 ii libgcc1 1:5.3.1-14 ii libkdcraw23 4:15.08.0-1+b1 ii libkdecore5 4:4.14.14-1+b2 ii libkdeui5 4:4.14.14-1+b2 ii libkexiv2-114:15.04.3-1 ii libkhtml5 4:4.14.14-1+b2 ii libkio5 4:4.14.14-1+b2 ii libkipi11 4:15.08.3-1 ii libknotifyconfig4 4:4.14.14-1+b2 ii libkparts4 4:4.14.14-1+b2 ii libopencv-core2.4v5 2.4.9.1+dfsg-1.5 ii libopencv-imgproc2.4v5 2.4.9.1+dfsg-1.5 ii libphonon4 4:4.8.3-2 ii libqt4-dbus 4:4.8.7+dfsg-6+b1 ii libqt4-sql 4:4.8.7+dfsg-6+b1 ii libqt4-sql-sqlite 4:4.8.7+dfsg-6+b1 ii libqt4-xml 4:4.8.7+dfsg-6+b1 ii libqtcore4 4:4.8.7+dfsg-6+b1 ii libqtgui4 4:4.8.7+dfsg-6+b1 ii libsolid4 4:4.14.14-1+b2 ii libstdc++6 5.3.1-14 ii libthreadweaver44:4.14.14-1+b2 ii perl5.22.1-9 ii phonon 4:4.8.3-2 Versions of packages digikam recommends: ii chromium [www-browser] 50.0.2661.75-1 ii firefox [www-browser] 45.0.2-1 ii google-chrome-stable [www-browser] 50.0.2661.75-1 ii kipi-plugins4:4.14.0-4+b1 ii konqueror [www-browser] 4:15.08.3-1 ii mplayerthumbs 4:15.08.3-1 ii w3m [www-browser] 0.5.3-27 Versions of packages digikam suggests: pn digikam-doc ii systemsettings 4:5.4.3-1 -- no debconf information
Bug#842094: digikam: libgphoto2 support missing
Package: digikam Version: 4:5.2.0-2 Severity: important Dear Maintainer, digikam can't access my camera anymore, after upgrading to version 5.2.0-2. The reason is that libgphoto2 support is missing in that version whereas it was available in 5.1.0-2. This, or a similar problem, had occured a number of times before (#785492 and #821178) and disappeared subsequently. Comparing the build logs for 5.1.0-2: https://buildd.debian.org/status/fetch.php?pkg=digikam&arch=amd64&ver=4%3A5.1.0-2&stamp=1471129203 and 5.2.0-2: https://buildd.debian.org/status/fetch.php?pkg=digikam&arch=amd64&ver=4%3A5.2.0-2&stamp=1477261520 yields: 5.1: [...] -- libgphoto2 execurables check... -- Found gphoto2: -lgphoto2_port;-lgphoto2 -lgphoto2_port -lm -- libgphoto2 found: TRUE -- Found LibUSB1: /usr/lib/x86_64-linux-gnu/libusb-1.0.so -- LibUSB1_FOUND= TRUE -- LibUSB1_INCLUDE_DIRS = /usr/include/libusb-1.0 -- LibUSB1_LIBRARIES= /usr/lib/x86_64-linux-gnu/libusb-1.0.so -- libusb1 found: TRUE -- Libgphoto2 and libusb1 have been found. -- libgphoto2 API version >= 2.5 -- libgphoto2 API version found: 2.5.10 [...] -- libgphoto2 found. YES (optional) [...] 5.2: [...] -- Found gphoto2: /usr/lib/x86_64-linux-gnu/libgphoto2.so;/usr/lib/x86_64 -linux-gnu/libgphoto2_port.so -- libgphoto2 found: TRUE -- Found LibUSB1: /usr/lib/x86_64-linux-gnu/libusb-1.0.so -- LibUSB1_FOUND= TRUE -- LibUSB1_INCLUDE_DIRS = /usr/include/libusb-1.0 -- LibUSB1_LIBRARIES= /usr/lib/x86_64-linux-gnu/libusb-1.0.so -- libusb1 found: TRUE -- Libgphoto2 and libusb1 have been found. -- Command gphoto2 not found. Cannot identify GPhoto2 API version. [...] -- libgphoto2 found. NO (optional) -- digiKam will be compiled without GPhoto2 camera drivers support. -- Please install the libgphoto2 (version >= 2.4.0) development package. -- [...] I hope that helps. Best regards, Andreas -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages digikam depends on: ii digikam-data 4:5.2.0-2 ii digikam-private-libs 4:5.2.0-2 ii libc6 2.24-5 ii libgcc1 1:6.2.0-9 ii libkf5configcore5 5.27.0-1 ii libkf5coreaddons5 5.27.0-1 ii libkf5filemetadata3 5.27.0-1 ii libkf5i18n5 5.27.0-2 ii libqt5core5a 5.6.1+dfsg-3+b1 ii libqt5gui55.6.1+dfsg-3+b1 ii libqt5sql55.6.1+dfsg-3+b1 ii libqt5sql5-mysql 5.6.1+dfsg-3+b1 ii libqt5sql5-sqlite 5.6.1+dfsg-3+b1 ii libqt5widgets55.6.1+dfsg-3+b1 ii libstdc++66.2.0-9 pn perl:any Versions of packages digikam recommends: ii chromium [www-browser] 53.0.2785.143-1 ii ffmpegthumbs4:16.08.0-1 ii firefox [www-browser] 49.0-4 ii google-chrome-stable [www-browser] 54.0.2840.71-1 ii konqueror [www-browser] 4:16.08.2-1 ii w3m [www-browser] 0.5.3-31 Versions of packages digikam suggests: pn digikam-doc ii systemsettings 4:5.8.2-1 -- no debconf information
Bug#838560: aptitude: "aptitude -u" hangs indefinitely at "Loading cache" if an APT repo results in a 404 (maybe APT 1.3 related)
Hi, I ran into the same symptom - aptitude stuck at "Loading cache" after `aptitude -u` - after I had added the line deb http://snapshot.debian.org/archive/debian/20160924/ sid main non-free contrib into sources.list. What revealed the root cause in my case was running `apt-get update`, which produced the error message: E: Release file for http://snapshot.debian.org/archive/debian/20160924/dists/sid/InRelease is expired (invalid since 1d 21h 41min 22s). Updates for this repository will not be applied. This is known behavior and running aptitude as `aptitude -o Acquire::Check-Valid-Until=false -u` suppresses the error and aptitude works as normal. What seems to be common between your setup and mine is that an error during the update of the package lists isn't handled (anymore; this worked previously) and that causes trouble later. hth, Andreas
Bug#359744: udev.lomoco needs update for Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is the /etc/sysconfig/logitech_mouse file, you need it to set the variables... -- andreas Thibaut VARENE wrote: > tags 359744 confirmed > severity 359744 normal > thanks > > It seems I was a little too confident when packaging lomoco's update, > the udev files have changed more than I thought. > > I'm sorry about that and will fix asap. I'm tagging this "normal", as > this bug doesn't prevent anyone from using lomoco to configure their > mouse. It's just the "automated" part which is not working. > > I'm clueless about what /etc/default/lomoco (aka > /etc/sysconfig/logitech_mouse) is supposed to contain, upstream > doesn't ship one in the tarball, hence me CC'ing upstream for help on > that topic. > > HTH > > T-Bone > > On 3/28/06, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: >> Package: lomoco >> Version: 1.0beta1+1.0-2 >> Severity: important >> >> udev.lomoco cannot use anything in /etc/sysconfig, that doesn't exist in >> Debian. Place whatever is needed in /etc/default/lomoco (and not >> "logitech_mouse"). >> >> You need to ship a default /etc/default/lomoco, btw. >> - -- http://www.linux-gamers.net - your online gaming resource -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEKXg8f94+j/M+P8YRAmgZAJ98X9uvby7yek9E2+YRJeN8wRQj0ACggmRE Py1lMDufX0WJb/HgjFMHyGk= =faF+ -END PGP SIGNATURE- #!/bin/sh ## Path:Hardware/Mouse ## Description: Logitech Mouse Tuning ## Type:list(800,400,1200,1600) ## Default: # # Define which resolution should be used # LOGITECH_MOUSE_RESOLUTION= ## Type:yesno ## Default: # # Whether to disable SmartScroll/Cruise Control. Defaults to yes if not set. # LOGITECH_MOUSE_DISABLE_CC=
Bug#741060: confirm: bash: Update to 4.3-2 breaks files' tab-completion
Bug report 741060 is duplicated by 741262. There is also a pointer to a fix in the bash-completion package in Ubuntu, which restores the expected behavior. Guessing wildly, I would also assume that 740780 relates to the same problem. Andreas
Bug#712482: task-xfce-desktop recommends unavailable package xfprint4
Package: task-xfce-desktop Version: 3.16 Severity: normal The task xfce-desktop recommends xfprint4. This package is not available anymore (except for m68k) since it has been removed from unstable. Quote: "Bug#710041: Removed package(s) from unstable". Therefore please drop the recommendation. /Andreas -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-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 Versions of packages task-xfce-desktop depends on: ii lightdm 1.6.0-3 ii task-desktop 3.16 ii tasksel 3.16 ii xfce4 4.10.1 Versions of packages task-xfce-desktop recommends: ii dbus-x111.6.12-1 pn evince-gtk ii gstreamer0.10-alsa 0.10.36-1.1 ii hunspell-en-us 20070829-6 ii hyphen-en-us2.8.6-2 ii iceweasel 17.0.6esr-1 ii libreoffice 1:4.0.3-3 pn libreoffice-gcj ii libreoffice-gtk 1:4.0.3-3 ii libreoffice-help-en-us 1:4.0.3-3 ii mousepad0.3.0-2 ii mythes-en-us1:3.3.0-4 ii network-manager-gnome 0.9.8.2-1 ii orage 4.8.4-2 ii quodlibet 2.4-1 ii synaptic0.80.2 ii system-config-printer 1.4.1-3 ii tango-icon-theme0.8.90-5 ii vlc 2.0.7-1 ii xfce4-goodies 4.10 ii xfce4-mixer 4.10.0-2 ii xfce4-power-manager 1.2.0-2 ii xfce4-terminal 0.6.2-1 ii xfprint44.6.1-3 ii xsane 0.998-5 task-xfce-desktop 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#712483: gnome-orca: recommends obsolete package gnome-mag
Package: gnome-orca Version: 3.4.2-2 Severity: normal gnome-orca recommends gnome-mag which is unavailable (except on m68k) since it has been obsoleted. Quote: "Bug#707203: Removed package(s) from unstable". Please fix the recommendation. The cited bug report suggests that gnome-shell supersedes gnome-mag, so maybe the recommendation should point to gnome-shell. Thanks, /Andreas -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-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 Versions of packages gnome-orca depends on: ii gir1.2-gtk-3.0 3.8.2-1 ii gir1.2-pango-1.0 1.32.5-5+b1 ii gir1.2-wnck-3.03.4.5-1 ii python 2.7.5-2 ii python-brlapi 4.5-2 ii python-cairo 1.8.8-1+b2 ii python-dbus1.2.0-2 ii python-gi 3.8.2-1 ii python-louis 2.5.2-2 ii python-pyatspi22.9.2+dfsg-1 ii python-speechd 0.7.1-6.2 ii python-support 1.0.15 ii python-xdg 0.19-5 ii speech-dispatcher 0.7.1-6.2 Versions of packages gnome-orca recommends: ii gnome-mag 1:0.16.3-1 ii wget 1.14-2 ii xbrlapi4.5-2 gnome-orca 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#689858: gnome: Dependency on xul-ext-adblock-plus is uncalled for
Could this dependency please be dropped? I understand that "metapackages are not a supermarket" but having gnome depend on adblock-plus seems like a violation of the debian package policy which states: "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." This is clearly not the case. "The Recommends field should list packages that would be found together with this one in all but unusual installations." which also isn't the case. Even "Suggests" doesn't seem warranted in my perspective. Thanks, Andreas
Bug#751372: closed by Luca Bruno (Bug#751372: fixed in openocd 0.8.0-2)
Hi, @ o-d@l.s.n: This is in reference to my bugreport against the Debian openocd package #751372 @ Paul: apologies for not getting back to you earlier. I didn't realize you had replied. Using the new package 0.8.0-2 doesn't work either. The messages are different, though: " $ openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg -s /usr/share/openocd/scripts Open On-Chip Debugger 0.8.0 (2014-08-17-10:29) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html WARNING! This file was not tested with real interface, it is based on code in ft2232.c. Please report your experience with this file to openocd-devel mailing list, so it could be marked as working or fixed. Info : only one transport option; autoselect 'jtag' trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst adapter_nsrst_delay: 200 jtag_ntrst_delay: 200 dcc downloads are enabled Warn : use 'feroceon.cpu' as target identifier, not '0' sheevaplug_load_uboot Error: no device found Error: unable to open ftdi device with vid 9e88, pid 9e8f, description 'SheevaPlug JTAGKey FT2232D' and serial '*' in procedure 'init' " Any further insights greatly appreciated. Let me know when I can be of assistance. Best, Andreas On Sun, Aug 17, 2014 at 12:21 PM, Debian Bug Tracking System < ow...@bugs.debian.org> wrote: > This is an automatic notification regarding your Bug report > which was filed against the openocd package: > > #751372: openocd: connecting to SheevaPlug broken in 0.8 > > It has been closed by Luca Bruno . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Luca Bruno < > lu...@debian.org> by > replying to this email. > > > -- > 751372: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751372 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems > > > -- Forwarded message -- > From: Luca Bruno > To: 751372-cl...@bugs.debian.org > Cc: > Date: Sun, 17 Aug 2014 10:19:04 + > Subject: Bug#751372: fixed in openocd 0.8.0-2 > Source: openocd > Source-Version: 0.8.0-2 > > We believe that the bug you reported is fixed in the latest version of > openocd, which is due to be installed in the Debian FTP archive. > > A summary of the changes between this version and the previous one is > attached. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 751...@bugs.debian.org, > and the maintainer will reopen the bug report if appropriate. > > Debian distribution maintenance software > pp. > Luca Bruno (supplier of updated openocd package) > > (This message was generated automatically at their request; if you > believe that there is a problem with it please contact the archive > administrators by mailing ftpmas...@ftp-master.debian.org) > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Format: 1.8 > Date: Sun, 17 Aug 2014 11:42:14 +0200 > Source: openocd > Binary: openocd > Architecture: source > Version: 0.8.0-2 > Distribution: unstable > Urgency: medium > Maintainer: Uwe Hermann > Changed-By: Luca Bruno > Description: > openocd- Open on-chip JTAG debug solution for ARM and MIPS systems > Closes: 751372 > Changes: > openocd (0.8.0-2) unstable; urgency=medium > . >* tcl/board: fix all the remaining boards that were sourcing > ft2232 configs (Closes: #751372) > Checksums-Sha1: > a80cff1116ba7c39e13e13cd64df3df8513dca2a 1264 openocd_0.8.0-2.dsc > 4d15e7eda62f9d88422af252aecc9a80d8f373c2 11396 > openocd_0.8.0-2.debian.tar.xz > Checksums-Sha256: > 4bcfaaf12ffd013f68148a50333b102561a6e2c3b169dda45b46a44b 1264 > openocd_0.8.0-2.dsc > 5dc4786bfcd223dc39d88fdd9ba23da3ce623ec49c7a2f865ed71f4c4c35aed8 11396 > openocd_0.8.0-2.debian.tar.xz > Files: > e9af58f6d1253487df3d1698a5cfb9d6 1264 embedded extra openocd_0.8.0-2.dsc > 8b43b95b79c1ea10485426a459b0fc60 11396 embedded extra > openocd_0.8.0-2.debian.tar.xz > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iEYEARECAAYFAlPwfD4ACgkQRqobajv7n7OfDwCfeDwDpMuDWfKg3vOCFsuehoRF > +PkAnigl6aQWTCZyueoLIUeT74bPRPLs > =zWYp > -END PGP SIGNATURE- > > -- Forwarded message -- > From: Andreas Schneider > To: Debian Bug Tracking System > Cc: > Date: Thu, 12 Jun 2014 10:20:16 +0200 > Subject: openocd: connecting to SheevaPlug broken in 0.8 > Package: openocd > Version: 0.8.0-1 > Severity: normal > > Dear Maintainer, > > connecti
Bug#751372: closed by Luca Bruno (Bug#751372: fixed in openocd 0.8.0-2)
Thanks Paul. Still no luck, but it looks like it's getting closer: " $ openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg -s /usr/share/openocd/scripts Open On-Chip Debugger 0.8.0 (2014-08-17-10:29) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst adapter_nsrst_delay: 200 jtag_ntrst_delay: 200 dcc downloads are enabled Warn : use 'feroceon.cpu' as target identifier, not '0' sheevaplug_load_uboot Error: An adapter speed is not selected in the init script. Insert a call to adapter_khz or jtag_rclk to proceed. in procedure 'init' " The programmer in me suspects that another trivial change is required, unfortunately I don't speak OpenOCD. Andreas
Bug#751372: closed by Luca Bruno (Bug#751372: fixed in openocd 0.8.0-2)
Hi, On Wed, Aug 20, 2014 at 9:26 AM, Paul Fertser wrote: > > In fact running openocd is much easier: > > openocd -f board/sheevaplug.cfg > > thanks for that hint. I've been using the longer commandline since this was verbatim how The Internet told me it should work when my plug was bricked. And since it did in fact work that way with 0.7 and I was more in panic mode (the plug is my internet gateway and general purpose home server) and not exactly ready for learning new things I've never bothered to investigate what part of the commandline was actually needed to get openocd running. > (no need for full path and -s). You should be able to get it running > with > openocd -f board/sheevaplug.cfg -c "adapter_khz 100" > > If you have a reasonable explanation of what the default adapter freq > should be, I can add it to the config. > > 0.7 tells that: " [...] sheevaplug_load_uboot Info : clock speed 2000 kHz Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part: 0x0a02, ver: 0x2) Info : Embedded ICE version 0 Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit ^C " so 2000 kHz is probably what should go into the config. > HTH > Yes, it did. Many thanks for your support! Andreas
Bug#751372: openocd: connecting to SheevaPlug broken in 0.8
Package: openocd Version: 0.8.0-1 Severity: normal Dear Maintainer, connecting to a SheevaPlug doesn't work anymore as of version 0.8. I.e. the command `openocd -f /usr/share/openocd/scripts/board/sheevaplug.cfg -s /usr/share/openocd/scripts` fails with the error message " Error: The specified debug interface was not found (ft2232) The following debug interfaces are available: 1: parport 2: dummy 3: ftdi 4: usb_blaster 5: amt_jtagaccel 6: gw16012 7: usbprog 8: jlink 9: vsllink 10: rlink 11: ulink 12: arm-jtag-ew 13: buspirate 14: remote_bitbang 15: hla 16: osbdm 17: opendous 18: aice 19: cmsis-dap Runtime Error: /usr/share/openocd/scripts/interface/sheevaplug.cfg:7: in procedure 'script' at file "embedded:startup.tcl", line 58 at file "/usr/share/openocd/scripts/board/sheevaplug.cfg", line 3 in procedure 'interface' called at file "/usr/share/openocd/scripts/interface/sheevaplug.cfg", line 7 " With 0.7 the connection works: " Info : only one transport option; autoselect 'jtag' adapter speed: 2000 kHz trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst adapter_nsrst_delay: 200 jtag_ntrst_delay: 200 dcc downloads are enabled Warn : use 'feroceon.cpu' as target identifier, not '0' sheevaplug_load_uboot Info : clock speed 2000 kHz Info : JTAG tap: feroceon.cpu tap/device found: 0x20a023d3 (mfg: 0x1e9, part: 0x0a02, ver: 0x2) Info : Embedded ICE version 0 Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit " Apparently the interface ft2232 has been removed with version 0.8. Naively replacing ft2232 with ftdi in /usr/share/openocd/scripts/interface/sheevaplug.cfg doesn't quite do the trick: "ft2232_layout sheevaplug" doesn't have an ftdi-equivalent and simply omitting it results in errors: " Info : only one transport option; autoselect 'jtag' adapter speed: 2000 kHz trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst adapter_nsrst_delay: 200 jtag_ntrst_delay: 200 dcc downloads are enabled Warn : use 'feroceon.cpu' as target identifier, not '0' sheevaplug_load_uboot Info : clock speed 2000 kHz Error: JTAG scan chain interrogation failed: all zeroes Error: Check JTAG interface, timings, target power, etc. Error: Trying to use configured scan chain anyway... Error: feroceon.cpu: IR capture error; saw 0x00 not 0x01 Warn : Bypassing JTAG setup events due to errors Info : Embedded ICE version 0 Info : feroceon.cpu: hardware has 1 breakpoint/watchpoint unit Error: unexpected Feroceon EICE version signature " Any help greatly appreciated. Please let me know when I can be of assistance. Best, Andreas -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-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 Versions of packages openocd depends on: ii libc6 2.19-1 ii libhidapi-hidraw0 0.8.0~rc1+git20140201.3a66d4e+dfsg-3 ii libusb-0.1-4 2:0.1.12-23.3 ii libusb-1.0-0 2:1.0.18-2 openocd recommends no packages. openocd 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#771509: gnome shouldn't recommend xul-ext-adblock-plus
Hi, many thanks for your speedy reply! > > are still valid. The most important one to me continues to be that a desktop > > environment and this browser extension have absolutely nothing to do with each > > other. > > The âgnomeâ metapackage defines what is installed on a desktop or laptop > with the GNOME selection. So it has everything to do with installing > what is required to properly use the machine. The policy regarding "Recommends" says: " This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations. " and from that perspective I still think my point is very valid: An installation of gnome without adblock-plus is not exactly unusual. Now I'm not aware of a comparable guideline for metapackages and if one existed it would likely be not worded as strongly. But even going with your "required to properly use the machine" I can't see why an adblocker would fall into this camp. I am using exclusively using Debian on all my computers with different DEs since a number of years and I never felt like one of them was not properly usable without an adblocker. > > Users who think they want an adblocker should conciously decide to install it > > and not having it sneaked into their install by a recommends. > > This particular package is certainly worth discussing, and the > dependency is not set in stone. But you donât have to use deliberately > confrontational words such as âsneaked intoâ to make your point. The > contents of the default installation is public. Whoops! I am deeply sorry if you found my wording offending or confrontational! I felt that the package was "sneaked into" my install when I did a habitual dist-upgrade and while reviewing the list of packages to be newly installed I ran across adblock-plus. Looks like my recent overdose of reading confrontational emails on d-d@l.d.o lowered my rudeness filter but that can't be an excuse. Sincerest apologies. I don't understand what you mean with the "contents of the default installation is public". > > Somewhat off-topic and more on the more philosophical front: "the internet" is > > largely paid for by ads and if you don't like how ads are used by some websites > > then you are free to not visit them. > > Letâs get real: âthe internetâ is not usable without an ad blocker, and > it has gotten much worse in the two years that passed since the last > time we had this discussion. Well, and this is where I respectfully disagree. If someone feels offended by the use of ads on websites he visits then he has a number of options to choose from: either he refrains from visiting them, or he bears it, or he installs an adblocker. > I agree that it should be the userâs choice, but the idea was to avoid > the extra action of installing the extension. > Maybe we could ship it disabled by default if it is possible. Honestly that doesn't sound like it's an easy fix. Plus it confuses those who deliberately want the extension installed and see that it's not working despite being installed. Best, Andreas
Bug#771509: gnome shouldn't recommend xul-ext-adblock-plus
Package: gnome Version: 1:3.14+1 Severity: normal Dear Maintainer, the introduction of "recommends xul-ext-adblock-plus" is uncalled for. This has already been discussed in quite some length in #689858 (merged with #71 and #721516) where a number of reasons for that have been given. Some of them were due to this beeing a "depends" back then, but all other reasons are still valid. The most important one to me continues to be that a desktop environment and this browser extension have absolutely nothing to do with each other. Except that for both a browser is definitely helpful. So if anything then iceweasel should maybe suggest its extensions. But also note that gnome is the only reverse dependency of adblock-plus, which imho speaks for itself. Users who think they want an adblocker should conciously decide to install it and not having it sneaked into their install by a recommends. Somewhat off-topic and more on the more philosophical front: "the internet" is largely paid for by ads and if you don't like how ads are used by some websites then you are free to not visit them. This "recommends" causes most users of gnome (the ones who do not cherry-pick their recommends) to not pay for some of the traffic, and thereby the cost, that they are causing. This even led some site owners launching campaigns agains adblockers. Like this one (in German) : http://www.spiegel.de/dienste/spiegel-online-schalten-sie-den-adblocker-bitte- ab-a-888158.html . Ok, this not been specific to gnome. :) Thank you, Andreas -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 Versions of packages gnome depends on: ii alacarte 3.11.91-2 ii avahi-daemon 0.6.31-4+b1 ii cheese 3.14.1-2 ii cups-pk-helper 0.2.5-2+b1 ii desktop-base 7.0.3 ii evolution3.12.7-1 ii evolution-plugins3.12.7-1 ii file-roller 3.14.1-1 ii gedit3.14.0-2 ii gedit-plugins3.14.0-2 ii gimp 2.8.14-1+b1 ii gitg 0.2.7-3 ii gnome-color-manager 3.14.1-1 ii gnome-core 1:3.14+1 ii gnome-documents 3.14.1-1 ii gnome-games 1:3.14+1 ii gnome-logs 3.14.2-1 ii gnome-maps 3.14.1.2-1 ii gnome-music 3.14.1-1 ii gnome-nettool3.8.1-1 ii gnome-orca 3.14.0-2 ii gnome-photos 3.14.0-1 ii gnome-shell-extensions 3.14.1-1 ii gnome-sound-recorder 3.14.0.1-1 ii gnome-tweak-tool 3.14.0-1 ii gstreamer1.0-libav 1.4.4-2 ii gstreamer1.0-plugins-ugly1.4.4-2 ii hamster-applet 2.91.3+git20120514.b9fec3e1-1 ii inkscape 0.48.5-3 ii libgtk2-perl 2:1.2492-3 ii libreoffice-calc 1:4.3.3-1 ii libreoffice-gnome1:4.3.3-1 ii libreoffice-impress 1:4.3.3-1 ii libreoffice-writer 1:4.3.3-1 ii nautilus-sendto 3.8.2-1 ii network-manager-gnome0.9.10.0-2 ii polari 3.14.1-1 ii rhythmbox3.1-1 ii rhythmbox-plugin-cdrecorder 3.1-1 ii rhythmbox-plugins3.1-1 ii rygel0.24.1-1 ii rygel-playbin0.24.1-1 ii seahorse 3.14.0-1 ii shotwell 0.20.1-1 ii simple-scan 3.15.1-1 ii sound-juicer 3.14.0-1+b1 ii telepathy-gabble 0.18.3-1+b1 ii telepathy-rakia 0.8.0-3 ii telepathy-salut 0.8.1-4 ii tomboy 1.14.1-3 ii totem3.14.0-2 ii totem-plugins3.14.0-2 ii tracker-gui 1.2.4-1 ii transmission-gtk 2.84-0.1+b1 ii vinagre 3.14.1-1 ii xdg-user-dirs-gtk0.10-1 Versions of packages gnome recommends: pn browser-plugin-gnash ii gdebi 0.9.5.5+nmu1 ii gnome-software3.14.2-1 ii telepathy-idle0.2.0-2 Versions of packages gnome suggests: pn dia-gnome pn gnome-boxes pn gnucash pn iceweasel-l10n-all ii libreoffice-evolution 1:4.3.3-1 pn planner pn xul-ext-adblock-plus pn xul-ext-gnome-keyring Versions of packages gnome-core depends on: ii adwaita-icon-theme 3.14.0-2 ii at-spi2-core2.14.0-1 ii baobab 3.14.1-1 ii brasero 3.11.4-
Bug#395261: lomoco: does not notice failure to set resolution
Peter Samuelson wrote: > Package: lomoco > Version: 1.0beta1+1.0-4 > > The -m, -h, -g flags do not work with mice that don't support those > resolutions, but there is no indication of failure: > > $ lomoco -m > 001.003: 046d:c00e Wheel Mouse Optical (M-BJ58) Caps: RES > Resolution set to 1200 cpi > > $ lomoco -i > 001.003: 046d:c00e Wheel Mouse Optical (M-BJ58) Caps: RES > Resolution (RES): 400 cpi > USB Mouse Polling Interval: 10ms > > It would be useful for -m/-h/-g to query the mouse after setting the > resolution, to see whether it succeeded. There is much more which should be done and we need a rewrite. Currently I'm trying to get informations about the new mice which use the second HID device for configuration. I wasn't able to reverse engineer the protocol. I want to create a library liblomoco and a commandline tool lomoco. So you can use liblomoco in other projects, KDE for example) > > A related wishlist item: lomoco -i should tell me what resolutions are > supported on each of my mice. I don't know if this can be done by > querying the mouse, or if a hard-coded lookup table should be used. > But in any case, I'd appreciate "Caps: RES 800 1200" or whatever, > instead of just "Caps: RES". This could be done with a new structure which defines the hightest and lowest resolution and the steps between them. MX510: low: 400 high: 800 step: 400 G5: low: 400 high: 2000 step: 50 There is no check what mouse is connected to a receiver. Often Logitech uses a receiver for different mice and this is a problem of the current lomoco. We don't detect it. I know there are no updates and it looks like the project is dead but I want to support the new mice with the new version too. I hope to get in contact with Logitech soon. -- andreas -- http://www.linux-gamers.net - your online gaming resource signature.asc Description: OpenPGP digital signature
Bug#401482: gdb: Failed to read a valid object file image from memory
I hope I can help to shed some light on this issue: There was a discussion on some Ubuntu forum where it was pointed out that this is actually a bug in the 2.6.18 (and newer) kernel: https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.20/+bug/74691 I quickly tested this on a machine where I have a 2.6.18 and a 2.6.17 kernel installed and can confirm that this message doesn't show up with 2.6.17 (2.6.17-2-686 actually). Daniel: Could you please re-route this bug to linux-source-2.6.18 (or the relevant package) if you think my conclusions are right? A recipe to reproduce this problem is: (using a 2.6.18 kernel) * compile a simple program (like hello world): 'gcc -o hello -g hello.c' * open the program in gdb: 'gdb ./hello' * 'break main' * 'run' Now gdb will output: "Starting program: ./hello Failed to read a valid object file image from memory." Note: This allows to debug the program; however single stepping causes gdb to jump pseudo-randomly from one line to another. Also breakpoints are sometimes set somewhere else than expected. If further information is required, I'd be more than happy to provide it. Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414097: lomoco: Please support MX Revolution
Julien Goodwin wrote: > Package: lomoco > Version: 1.0beta1+1.0-5 > Severity: wishlist > Hi Julien, > Please add support for the Logitech MX Revolution. Ideally with the ability > to disable the clutch switch and gain back the third mouse button. > this is not possible cause the MX Revolution uses like the G series a second HID device for the configuration. It isn't possible to support this with the current code. We need a complete rewrite. I will start working on a library after I finished my diploma thesis. The other problem is, I don't have a MX Revolution. > Thanks, > Julien -- andreas > > -- System Information: > Debian Release: 4.0 > APT prefers testing > APT policy: (500, 'testing') > Architecture: i386 (i686) > Shell: /bin/sh linked to /bin/bash > Kernel: Linux 2.6.18-3-686 > Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1) > > Versions of packages lomoco depends on: > ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries > ii libusb-0.1-42:0.1.12-5 userspace USB programming library > > Versions of packages lomoco recommends: > ii udev 0.105-2/dev/ and hotplug management > daemo > > -- no debconf information > > -- http://www.linux-gamers.net - your online gaming resource signature.asc Description: OpenPGP digital signature
