Bug#873446: conky: Conky segfaults on some multicore systems when $cpugraph, $cpubar, etc are used
Package: conky
Version: 1.10.6-1.1bds
Severity: important
Tags: patch
This patch corrects a segfault (and general instability) associated with
CPU monitoring $cpugraph, $cpubar, and related load monitoring
directives that occurred when the kernel reports a non-sequential list
of CPU indices on an SMP system.
This is a new bug that arrived with the 'stretch' version of conky.
For example, "/sys/devices/system/cpu/present" for my AMD FX(tm)-6350
Six-Core Processor reports "0,3-7" (stock debian kernel 4.9.0-3-amd64 ).
I assume that chip is really an 8-core die with two cores disabled...
Presumably you could also get "0,3-4,6", and other combos too.
This bug and patch has also been reported upstream:
https://github.com/brndnmtthws/conky/pull/416
This may be the same problem reported in Bug #863144: "conky: seqfaults"
-- Brad
-- System Information:
Debian Release: 9.1
APT prefers stable
APT policy: (900, 'stable'), (80, 'unstable'), (60, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.9.0-3-amd64 (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages conky depends on:
ii conky-all 1.10.6-1
conky recommends no packages.
conky suggests no packages.
-- no debconf information
From d3065426868cdf63ccbbaf6afd917de64403ae49 Mon Sep 17 00:00:00 2001
From: Brad Sawatzky <brad+deb...@swatter.net>
Date: Sun, 27 Aug 2017 16:10:48 -0400
Subject: [PATCH] Fix segfault when kernel reports non-sequential SMP CPU
indices
- For an AMD FX(tm)-6350 Six-Core Processor the file '/sys/.../present'
reports "0,3-7". I assume that chip is really an 8-core die with two
cores disabled... Presumably you could also get "0,3-4,6", and other
combos too...
---
src/linux.cc | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/src/linux.cc b/src/linux.cc
index 664ddf5e..5ebed315 100644
--- a/src/linux.cc
+++ b/src/linux.cc
@@ -801,8 +801,11 @@ void get_cpu_count(void)
{
FILE *stat_fp;
static int rep = 0;
- int highest_cpu_index;
char buf[256];
+ char *str1, *str2, *token, *subtoken;
+ char *saveptr1, *saveptr2;
+ int subtoken1=-1;
+ int subtoken2=-1;
if (info.cpu_usage) {
return;
@@ -819,11 +822,30 @@ void get_cpu_count(void)
break;
}
- if (sscanf(buf, "%*d-%d", _cpu_index) == 1) {
- info.cpu_count = highest_cpu_index;
+ // Do some parsing here to handle skipped cpu numbers. For example,
+ // for an AMD FX(tm)-6350 Six-Core Processor /sys/.../present reports
+ // "0,3-7". I assume that chip is really an 8-core die with two cores
+ // disabled... Presumably you could also get "0,3-4,6", and other
+ // combos too...
+ for (str1 = buf; ; str1 = NULL) {
+ token = strtok_r(str1, ",", );
+ if (token == NULL) break;
+ ++info.cpu_count;
+
+ subtoken1=-1;
+ subtoken2=-1;
+ for (str2 = token; ; str2 = NULL) {
+subtoken = strtok_r(str2, "-", );
+if (subtoken == NULL) break;
+if(subtoken1 < 0)
+ subtoken1=atoi(subtoken);
+else
+ subtoken2=atoi(subtoken);
+ }
+ if(subtoken2 > 0)
+info.cpu_count += subtoken2 - subtoken1;
}
}
- ++info.cpu_count;
info.cpu_usage = (float*)malloc((info.cpu_count + 1) * sizeof(float));
fclose(stat_fp);
@@ -896,7 +918,7 @@ int update_stat(void)
} else if (strncmp(buf, "cpu", 3) == 0) {
double delta;
if (isdigit(buf[3])) {
-idx = atoi([3]) + 1;
+idx++; //just increment here since the CPU index can skip numbers
} else {
idx = 0;
}
--
2.11.0
Bug#787111: googlecl: Broken software - Google no longer supports OAuth 1.0
Package: googlecl Version: 0.9.13-2 Severity: grave Justification: renders package unusable Package needs to be updated to use OAuth 2.0... -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages googlecl depends on: ii python2.7.9-1 ii python-gdata 2.0.18+dfsg1-2 pn python:anynone googlecl recommends no packages. googlecl 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#504928: Does not honour /lib/firmware/KERNELRELEASE directory layout
Package: udev Version: 0.125-7 Followup-For: Bug #504928 This bug just bit me on upgraded my laptop to Lenny (snd-maestro3.ko). It sounded like Marco was going to roll out a fixed version at the end of December 2008. Is there a problem with the proposed addition of /lib/firmware/`/bin/uname -r` to the FIRMWARE_DIRS list in hotplug.functions? (Or did the update get delayed because RL got in the way?) -- Brad -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507473: recoll 1.11.0 needs versioned build-dep on libxapian
Package: recoll Version: 1.9.0-1 Severity: serious Justification: no longer builds from source I was backporting recoll 1.11.0 from sid to etch and found that I needed to upgrade libxapian to 1.0.7-4 (from backports) to have it build successfully. Version 0.9.9-1 does not have the 'xapian/sorter.h' header file (probably among other incompatibilities). debian/control should have a versioned dependency for libxapian/libxapian-dev added. I see reportbug sets the severity to 'serious' for 'does-not-build'. Given that this is just a backporting issue, I doubt it's that important. Feel free to downgrade the bug if it matters. Here's the build error with libxapian13 v0.9.9-1 installed: g++ -M -g -O2 -I. -I../aspell -I../bincimapmime -I../common -I../index -I../internfile -I../rcldb -I../unac -I../utils -I/usr/local/include -g -O2 -Wall -Wno-unused -I/usr/include -DRECOLL_DATADIR=\/usr/share/recoll\ -DLIBDIR=\/usr/lib\ -DHAVE_CONFIG_H -D_GNU_SOURCE ../rcldb/rclquery.cpp rclquery.dep ../rcldb/rclquery.cpp:11:27: error: xapian/sorter.h: No such file or directory make[2]: *** [rclquery.dep.stamp] Error 1 -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#505661: kernel-package 11.0011 needs build-dep on po4a 0.31-1
Package: kernel-package Version: 10.067 Followup-For: Bug #505661 Version 11.0011 of kernel-package needs a build-dep added for po4a 0.31-1. (Based on a cursory look through po4a's changelog, that looks like the first version to correctly support the --previous flag.) FWIW, its possible to install the current unstable version of po4a (0.34-2) under etch. That allowed me to successfully backport kernel-package 11.0011. -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487475: xsane: Control/menu selection problem with epson backends via net driver [patch]
On Fri, 25 Jul 2008, Julien BLACHE wrote: Glad you narrowed it down. I've been on vacation the last couple of weeks and had to put it on hold. Bad: - I think your patch may be the best option to fix this issue... - ... but I'm afraid it may be leaking memory [ . . . ] Could you rework your patch to free the memory you're allocating when the option menu is rebuilt? With that done, I can apply it to XSane. Yeah, it will leak a few ten's of bytes every time that menu is constructed... I couldn't see a simple workaround but I'll take another look and see if I can rework the patch. Thanks for your work. -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487475: xsane: Control/menu selection problem with epson backends via net driver [patch]
On Thu, 10 Jul 2008, Julien BLACHE wrote: Brad Sawatzky [EMAIL PROTECTED] wrote: What is the intent of duplicating s-opt into s-local_opt? If it is to provide a stable local version of the scanner descriptors then shouldn't Per the SANE standard, the descriptors have to remain available at the same location until the device is closed. If it wasn't the case, it'd be a major pain for the frontends to keep track of the options. (it could be done with more API calls, though, but that's added complexity for no benefit) the .constraint union (*string_list, *word_list, or *range) be duplicated as well? Nope. Whenever that changes, the backend instructs the frontend to reload the options. The constraints can and do change depending on what options you set. Also the type of constraint can change (resolution list vs. free resolution). Right. So isn't the problem that the menu is storing a pointer to a memory that is subsequently free()'d, not the data itself? Why is the str_list[] array of pointers in xsane-front-gtk.c:xsane_option_menu_new() assumed to be stable for the Source options? The underlying bug is either: a) The menu is being generated with its .label member pointing at memory that is subsequently free()'d. That makes the memory referenced by menu.label subject volatile. - FIX: Create and store a stable version of the menu.label string. This can be done either in the s-local_opt structure (which would be a pain to implement), or make a copy at the time the menu is created per my initial patch. - NOTE: It looks like this is exactly what is done for the resolution menu created by xsane_resolution_widget_new() (using strdup to make local copies of the resolution strings for use in menu[].label). - OR - b) The pointer in the menu.label for the active source menu (in this case) is not being kept current. - FIX: Recreate/update the gtk menu and do a panel_rebuild every time the net backend changes the NON-local opt array (since that is the memory referenced by the pointer stored in menu.label. -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487475: xsane: Control/menu selection problem with epson backends via net driver [patch]
On Thu, 10 Jul 2008, Julien BLACHE wrote: Brad Sawatzky [EMAIL PROTECTED] wrote: b) The pointer in the menu.label for the active source menu (in this case) is not being kept current. - FIX: Recreate/update the gtk menu and do a panel_rebuild every time the net backend changes the NON-local opt array (since that is the memory referenced by the pointer stored in menu.label. The panel should be rebuilt every time the backend asks for the options to be reloaded. A look at the XSane sources suggests that it's being done, but it looks like there's a corner case somewhere. I guess I wasn't clear. Right now, no matter when the panel is built, the Source menu will contain references to memory that can and will be deallocated as sanei_ communicates over the network. The data in those references are not stored in any local copy of the opt list. AFAICT, the fact that the Source menu for other backends work at all over the netowrk is simply due to good fortune. The Resolution menu is already treated differently and stores local copies of the data which is why it works while Source doesn't. As far as I could see, the info output parameter is checked and honoured for every SET_VALUE call. As I cannot reproduce the problem with the hardware I own, I can't debug this further. I understand. I've been looking for some insight into the code -- without knowing what the code is supposed to do, I don't know how to fix it. The problem I've described occurs for all backends accessed over the net. The epson/epkowa backend just makes it visible to the user. [ from earlier message ] What is the intent of duplicating s-opt into s-local_opt? If it is to provide a stable local version of the scanner descriptors then shouldn't Per the SANE standard, the descriptors have to remain available at the same location until the device is closed. If it wasn't the case, it'd be a major pain for the frontends to keep track of the options. (it could be done with more API calls, though, but that's added complexity for no benefit) Then the net backend is breaking the SANE standard. s-local_opt.desc[] is not a complete copy of the descriptors since memcpy merely duplicates the pointer to the .constraint union member, but not the underlying data (option (a) in the previous message). PS: I worry I'm spamming bugs.debian.org with these details. If I should be communicating directly with upstream please tell what is the best way to do that and I'll stop hassling you :-) Thanks for you work, -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487475: xsane: Control/menu selection problem with epson backends via net driver [patch]
On Sun, 22 Jun 2008, Julien BLACHE wrote: [ . . . ] Anything in the option descriptor can change after the backend tells the frontend to reload the options, and I think that's what you're seeing with gdb when the net backend refreshes the option descriptors. But the memory allocated by sanei_wire for the option descriptors and their content should not get overwritten unless there's been a call to sane_get_option_descriptor(). The code flow looks roughly like this: frontend calls sane_get_option_descriptor() for first option net backend loads option descriptors (fetch_options()) frontend calls sane_get_option_descriptor() a few more times to load all options frontend sets an option value by calling sane_control_option() net backend forwards to underlying backend underlying backend replies with info containing SANE_INFO_RELOAD_OPTIONS net backends marks local copy as invalid, forwards to frontend frontend calls sane_get_option_descriptor() for first option net backend loads option descriptors (fetch_options()) frontend calls sane_get_option_descriptor() a few more times to reload all the options I've been trying to understand the net backend code this evening. I see where fetch_options() iterates over the option list and makes a local copy in net.c: memcpy (s-local_opt.desc[option_number], s-opt.desc[option_number], sizeof (SANE_Option_Descriptor)); However, this memcpy does not duplicate the .constraint member of the associated SANE_Option_Descriptor. It copies the pointer stored in the opt.desc structure but not the underlying data. The sanei_w_* code still confuses me a bit, but doesn't fetch_options() clear s-opt right near the top of the function? I'm looking at sanei_w_set_dir (s-hw-wire, WIRE_FREE); s-hw-wire.status = 0; sanei_w_option_descriptor_array (s-hw-wire, s-opt); Drilling into this last function we get to sanei_w_array() where the memory associated with s-opt[] gets free()'d. Now the pointer that was stored in menu_item[0].label = s-local_opt.desc[44].string_list[0] = s-opt.desc[44].string_list[0] but that memory just been deallocated. The menu will still work correctly if that memory is left untouched, or if s-opt happens to be restored exactly as it was when the menu was initially constructed. (And if it's the latter, why bother making the local copy in the first place?) What is the intent of duplicating s-opt into s-local_opt? If it is to provide a stable local version of the scanner descriptors then shouldn't the .constraint union (*string_list, *word_list, or *range) be duplicated as well? -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487475: xsane: Control/menu selection problem with epson backends via net driver [patch]
On Wed, 25 Jun 2008, Julien BLACHE wrote: Brad Sawatzky [EMAIL PROTECTED] wrote: Up to that point, you're seeing the preferences loading code setting options in a loop, resetting the options each time a reload is called for by the backend, except for the options that caused a reload. In that code, XSane is not yet taking memory references, and options are reloaded properly, so we mostly don't care about what's happening at that stage. (but ...) I set a memory watchpoint after the xsane Source menu had been built. The memory location for the watchpoint is the pointer that was stored in the label field of the gtk_menu structure. So the menu structure used in the final GUI is constructed with menu.label referencing a string in a buffer that is overwritten by all kinds of different data many times after that point. That can't be right, can it? Now the GUI is initialized and ready to go. I set a breakpoint on By the time we get to this point _three_ seperate gtk_menu structures have been created for the Source options. The first gtk_menu structure is the one used as the Source pop-up menu in the main xsane window. This structure contains the original .label reference mentioned which points to a memory location that has since been overwritten many, many times. (I don't know where the other two gtk_menu 'Source' menus are used in the GUI, if anywhere. Their .label fields point to different, but equally volatile, memory locations.) What's interesting is what happens in and around xsane_panel_build(), that effectively builds the options panels. Can you confirm that the issue happens only the first time you try to set the option? There is memory churn at the menu.label reference every time any scanner option is selected until something happens and that particular block of memory becomes stable. I haven't been able to work out what particular combination of GUI manipulation fixes (or masks) the problem. It's not 100% reproducible. Sometimes it works after selecting something else once, sometimes it takes several attempts. I'm wondering if there is a race in the code somewhere that causes the net backend to allocate a new buffer under some circumstance, leaving the old original sitting idle... I'll try your other suggestions as soon as I get the chance. (RL is intruding at the moment. Hopefully this weekend.) -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487462: libsane-extras: Add support full for Epson 4490 scanner
On Mon, 30 Jun 2008, Olaf Meeuwissen wrote: brad sawatzky [EMAIL PROTECTED] writes: [ . . . ] Are there technical reasons why the above patches shouldn't be applied? The fact that these features will be fixed/supported in a future iscan release is great, but it shouldn't preclude their inclusion in the sane package now. As in damage the hardware? Probably not. Your patches for Julien's epkowa backend are against code from iscan-2.10. Julien has not upgraded to the sources for iscan-2.11 yet. That very understandable because it will break support for all models that need an interpreter (except the GT-X770 / Perfection V500). Once AVASYS releases fixed interpreters, all Julien should have to do is upgrade to the latest epkowa backend sources. Julien is free to decide whether he'll include your patches in his sane-backends-extras for the time being and rip them out again when upgrading to iscan-2.11 or later. But I don't quite see a need to include them in the AVASYS iscan sources. Ahh, now I understand. Thanks for the info. Obviously, I'd like to seem them applied to the current sane package so I don't have to maintain my own patch-set :-) I'll be happy to work with Julien/whomever to rework the patch when 2.11 gets merged. -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487462: libsane-extras: Add support full for Epson 4490 scanner
I took the liberty of CC'ing Carl in this message in case he's interested. Carl, you can find the rest of the thread at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=487462 On Fri, 27 Jun 2008, Olaf Meeuwissen wrote: I'm definitely not in favour of applying the epson4490-fixup.patch. As for the 16bit patches from Carl, I already mentioned[1] that I'd look at that. [1] http://lists.alioth.debian.org/pipermail/sane-devel/2008-June/022157.html Thanks for link. I have a question about this comment though: Thanks for the patches. I'll take a look and see what, if, when and in what form things will make it into the epkowa backend. Please note that from iscan's (somewhat myopic) point of view, 16-bit support is not required. All scans, except bi-level, are done with 8-bit. That means that any 16-bit support that makes it in will be pretty much untested. Without published specs, a lot of open source code is guess and check. Is there a specific technical problem with Carl's 16-bit patch that we can improve? Here is the scoop on the epson4490-fixup.patch: | - Added 4800 dpi resolution which is suppported but not reported by the |scanner. This will be automatically fixed when we release a new version of the plugin to work with iscan-2.11.0 and later. | - Re-enabled 400 dpi resolution. There was no comment as to why it had [ . . ] That resolution was disabled to get ADF to work. Sorry for not adding a comment. | - Fixed an off by one error in the original filter_resolution() function. The array has the size in its first element (see the last line of the patch), as per requirement for SANE_CONSTRAINT_WORD_LIST. Instead of fixing an off by one error, you introduce one. I don't think so... but the confusion is understandable. s-hw-resolution_list[] has the length in element 0, but s-hw-res_list[]does not. The length of s-hw-res_list[] is stored in s-hw-res_list_size. The for() loop was iterating over s-hw-res_list[]. | - Enabled resolutions 300 dpi. This makes for _much_ faster preview [ . . . ] This will also be automatically fixed with a new version of the plugin for iscan-2.11.0 and later. WHEN will this new plugin be released? Honestly, I don't know (it not my call) but given how things are at the moment it will not be anytime real soon now. I hope we can get an updated version out sometime in autumn. Are there technical reasons why the above patches shouldn't be applied? The fact that these features will be fixed/supported in a future iscan release is great, but it shouldn't preclude their inclusion in the sane package now. -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487475: xsane: Control/menu selection problem with epson backends via net driver [patch]
On Sun, 22 Jun 2008, Julien BLACHE wrote: However I am a bit doubtful as to the origin of the bug. I'd expect the problem would manifest itself with other backends too. Yeah, I had though so too... AFAICT the opt pointer that xsane used was directed into a generic buffer that sanei_* used for its net traffic. In some circumstances the buffer would get 'refilled' with the same opt structure prior to menu_list[].label getting dereferenced so the right data would be at that location and everything would just work. However, if you use gdb to break on writes to the memory location stored during the initial menu_items[i].label = str_list[i]; line (in the unpatched xsane-front-gtk.c:xsane_option_menu_new() function) you should find that it gets overwritten regularly as data are transferred through the net backend. I'll admit to getting a little lost in the sanei_* calls that do the dirty work though... -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487475: xsane: Control/menu selection problem with epson backends via net driver [patch]
OK, here's a summarized gdb session. Sorry about the length, I hope it's useful... I set a breakpoint on xsane_option_menu_new() and wait for my menu-item of interest (the source menu which should eventually contain Flatbed and Transparency Unit) to trigger. When the Flatbed menu item is created I set a watchpoint on the memory pointed to by menu_list[].label (0xa57550): (gdb) x/s 0xa57550 0xa57550: Flatbed I then set a breakpoint on sane_control_option() and watch it get called on several more option items with act=SANE_ACTION_GET_VALUE. The last couple of calls are: sane_control_option (h=0x9b5ec0, opt=0, act=SANE_ACTION_GET_VALUE sane_control_option (h=0x9b5ec0, opt=2, act=SANE_ACTION_SET_VALUE Right after this the memory watch point gets triggered and the original label string gets stomped: (gdb) x/s 0xa57550 0xa57550: Àt¥ Here's a truncated backtrace: #0 0x7fbc25b08e09 in _int_free () from /lib/libc.so.6 #1 0x7fbc25b091ee in free () from /lib/libc.so.6 #2 0x7fbc246ef680 in sanei_w_array (w=0x979978, len_ptr=0x7fff30bcee24, v=0xa57530, w_element=0x7fbc246ee440 bin_w_byte, element_size=1) at sanei_wire.c:181 #3 0x7fbc246ee357 in bin_w_string (w=0x979978, v=0xa574c0) at sanei_codec_bin.c:87 #4 0x7fbc246ef66d in sanei_w_array (w=0x979978, len_ptr=0x7fff30bceea4, v=0xa574a0, w_element=0x7fbc246ee310 bin_w_string, element_size=8) at sanei_wire.c:178 #5 0x7fbc246ef91e in sanei_w_option_descriptor (w=0x979978, v=0xa57470) at sanei_wire.c:535 #6 0x7fbc246ef30f in sanei_w_ptr (w=0x979978, v=0xa561e0, w_value=0x7fbc246ef7c0 sanei_w_option_descriptor, value_size=56) at sanei_wire.c:263 #7 0x7fbc246ef431 in sanei_w_option_descriptor_ptr (w=0x979978, v=0xa561e0) at sanei_wire.c:546 #8 0x7fbc246ef66d in sanei_w_array (w=0x979978, len_ptr=0x9f03f0, v=0x9f03f8, w_element=0x7fbc246ef3f0 sanei_w_option_descriptor_ptr, element_size=8) at sanei_wire.c:178 #9 0x7fbc246ebd1b in fetch_options (s=0x9f03e0) at net.c:479 #10 0x7fbc246ec2b3 in sane_net_get_option_descriptor (handle=0x9f03e0, option=1) at net.c:1301 At this point the memory at 0xa57550 gets zeroed via memset, overwritten with a different piece of the opt descriptor structure(*), zeroed, overwritten with 'Flatbed' again, stomped again with some non-string data, zeroed with memset, overwritten with another piece of the opt descriptor structure (a different one than (*)), stomped with some non-string data, ... etc. Eventually the memory activity started by the first sane_control_option(.. ,act=SANE_ACTION_SET_VALUE, ..) finishes. and the next break is at sane_control_option (h=0x9b5ec0, opt=19, act=SANE_ACTION_SET_VALUE The original menu_list[].label now points to this string: (gdb) x/s 0xa57550 0xa57550:Transparency Unit 'Flatbed' is now stored at location 0xa57530. Next, sane_control_option(opt= , act=SANE_ACTION_SET_VALUE, ..) is called with several different opt values until it's called with opt=OPT_EQU_GROUP and the memory stomping begins anew. When the memory stabilizes this time menu_list[].label (0xa57550) points to 'Flatbed' again. However, xsane_option_menu_new() gets called again for the Flatbed option (second time): xsane_option_menu_new (parent=0xaad540, str_list=0xa57530, val=0xad8c50 Flatbed Note the updated str_list pointer is 0xa57530 (was 0xa57550 on the original call). Shortly after this menu item is (re-)created, the data at 0xa57530 get walked over as above and is left pointing to garbage. Curiously, 0xa57550 is stable and still points to 'Flatbed'. xsane_option_menu_new() gets called yet again for the Flatbed option (third time): xsane_option_menu_new (parent=0xaad540, str_list=0xa57530, val=0xad8c50 Flatbed At this point 0xa57530 is garbage, 0xa57550 is still 'Flatbed'. Now the GUI is initialized and ready to go. I set a breakpoint on xsane_option_menu_callback() and change the scanner source menu option from Flatbed to Flatbed to trigger the breakpoint. While stepping through xsane_option_menu_callback() I get to this line: opt = xsane_get_option_descriptor() and the memory watchpoint triggers. At this point neither 0xa57530 nor 0xa57550 contain 'Flatbed' anymore (just NULLs or non-ascii bytes). Memory churns again and by the time xsane_get_option_descriptor() exits 0xa57530 and 0xa57550 both point to data from a different part of the option descriptor and neither contains the correct Flatbed string that should be associated with the gtk menu_item. Curiously the menu_list[].label value in the callback for the Flatbed menu item is still 0xa57550, the pointer from the very first call of xsane_option_menu_new(). I have no idea what the other two xsane_option_menu_new(.., Flatbed, ...) calls were for... Are there other Source menus buried elsewhere in the GUI? Anyway, the menu callback results in a request being passed to the epkowa backend to change the source to Sharpness (in this instance) since that
Bug#487475: xsane: Control/menu selection problem with epson backends via net driver [patch]
Package: xsane Version: 0.995-3 Severity: normal Tags: patch The problem occurs in xsane when accessing an epson/epkowa driver through the network backend. Trying to change options like binary/gray/color, resolutions, etc., in xsane results in a dialog box with 'Failed to set value of option mode: invalid argument'. Playing with various controls for a while (and dismissing the errors) eventually results in the problem fixing itself, after which xsane behaves normally. There are no problems when accessing the same driver directly (ie. xsane + epson backend on the same host). Please note that this is the same bug referenced here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=307088 It was reassigned from xsane to libsane by Julien quite some time ago. From what I found, I think it really is a bug in xsane. (xsane assumes a memory structure is static but this is not guaranteed when the network backend is used.) Here's what I discovered. A patch that fixes (or is at least an effective work-around) is attached. The xsane frontend talks to the local net backend. The net backend communicates with the real (epson) backend over the network and builds a local copy of an opt structure describing the scanner. xsane then constructs its menus by walking this structure and creating gtk_menu objects with label strings stored as direct pointers into the opt structure. Unfortunately, while the opt structure is built once and is then stable on the remote (epson, epkowa, whatever) backend, that memory space is NOT stable with the net backend. The pointer returned by the 'opt = xsane_get_option_descriptor()' call in xsane.c seems to point to a general purpose memory buffer used by the sanei_* network routines used by the net backend. The end result is that it is a bit of a crap-shoot whether menu_items[].label (a pointer into the opt structure) still points to the same string as it did when the menu was created. Since the label string is used to request changes to the epson backend configuration by name, the change request only works if the memory hasn't been overwritten by something else. The patch fixes this problem by making a copy of the option name and setting menu_items[].label to point to the new string (removing xsane's dependence on a volatile memory structure). See the patch for additional comments. -- Brad -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (900, 'stable'), (80, 'unstable'), (60, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.25.6 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xsane depends on: ii libatk1.0-01.12.4-3 The ATK accessibility toolkit ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libcairo2 1.2.4-4.1+etch1 The Cairo 2D vector graphics libra ii libfontconfig1 2.4.2-1.2 generic font configuration library ii libgimp2.0 2.2.13-1etch4 Libraries necessary to Run the GIM ii libglib2.0-0 2.12.4-2 The GLib library of C routines ii libgtk2.0-02.8.20-7 The GTK+ graphical user interface ii libieee1284-3 0.2.10-4 cross-platform library for paralle ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii liblcms1 1.15-1Color management library ii libpango1.0-0 1.14.8-5 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-1PNG library - runtime ii libsane1.0.18-5 API library for scanners ii libtiff4 3.8.2-7 Tag Image File Format (TIFF) libra ii libusb-0.1-4 2:0.1.12-5userspace USB programming library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxcursor11.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-5 X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-5 X11 RandR extension library ii libxrender11:0.9.1-3 X Rendering Extension client libra ii xsane-common 0.995-3 featureful graphical frontend for ii zlib1g 1:1.2.3-13compression library - runtime -- no debconf information diff -Bburp -x '*.o' -x '*.swp' xsane-0.995/src/xsane-front-gtk.c xsane-0.995.patched/src/xsane-front-gtk.c --- xsane-0.995/src/xsane-front-gtk.c 2007-05-17 09:35:06.0 -0400 +++ xsane-0.995.patched/src/xsane-front-gtk.c 2008-06-01 02:15:51.0 -0400 @@ -1024,6 +1033,10 @@ void xsane_option_menu_new(GtkWidget *pa } menu_items = malloc((num_items +
Bug#483998: quiteinsane: Doesn't honor Short Resolution List option
Package: quiteinsane Version: 0.10-14 Severity: normal Epkowa and other Epson scanner backends report a 'Short Resolution list' option. Quiteinsane displays the option in its 'Advanced Settings' but does not update the 'Scan resolution' list when it is checked. -- Brad -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (900, 'stable'), (80, 'unstable'), (60, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.25.3 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages quiteinsane depends on: ii gocr 0.41-1A command line OCR ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libice61:1.0.1-2 X11 Inter-Client Exchange library ii libieee1284-3 0.2.10-4 cross-platform library for paralle ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libpng12-0 1.2.15~beta5-1PNG library - runtime ii libqt3-mt 3:3.3.7-4etch1Qt GUI Library (Threaded runtime v ii libsane1.0.18-5 API library for scanners ii libsm6 1:1.0.1-3 X11 Session Management library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libtiff4 3.8.2-7 Tag Image File Format (TIFF) libra ii libusb-0.1-4 2:0.1.12-5userspace USB programming library ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii zlib1g 1:1.2.3-13compression library - runtime quiteinsane recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#191781: libsane: Valgrind errors in epson backend
I ran valgrind against the epson.c backend from 1.0.19~cvs20070505-2 and can confirm that the errors in get_identity_information() are fixed. -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359797: libsane: udev rules file broken
On Sun, 22 Apr 2007, Julien BLACHE wrote: Brad Sawatzky [EMAIL PROTECTED] wrote: [ ... ] Is it possible for the autoprobed scanner device to be indeterminate? The I'm not sure what you mean here, could you elaborate ? See below. CX6600 is a multifunction printer/scanner unit with built-in card reader so many different devices are created when it's plugged in -- could there be some weird race condition? Arrgh. There's only one node created under /dev/bus/usb unfortunately, that's a real problem with multifunction devices and the current permissions scheme - it's hard to share the printer between CUPS and SANE. This is what was in the back of my mind. I'm not sure how libsane identifies the correct scanner device in /dev/. If the scanner can be accessed through more than one device ( ie. /dev/bus/usb/00X/00Y, and /dev/usbdevX.Y_epZZ) then the device libsane picks would depend on which device it tries first and was able to open. If CUPS grabbed the /dev/bus/usb/ device first, would libsane keep searching and eventually try the /dev/usbdevX.Y* devices? Of course, this assumes that a) libsane walks /dev looking for scanner devices, and b) the usbdevX.Y* devices can actually be used to control the scanner despite having different major/minor numbers than the nodes in /dev/bus/usb/... Exposing the endpoints individually as it's done now could help solve that, I'd need to check why this was introduced and what the plans are on the libusb side. -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359797: libsane: udev rules file broken
On Sat, 21 Apr 2007, Julien BLACHE wrote: Brad Sawatzky [EMAIL PROTECTED] wrote: Changing the line to SUBSYSTEM!=usb_endpoint, GOTO=libsane_rules_end allows the rule to match and fixes the problem for me. I assume that this is a change in how kernel 2.6.20.7 reports this device? I've attached a udevinfo dump for the curious. OK, looks like udev changed again... gotta love this. Can you unplug your scanner, run udevmonitor (as root), plug it in and send me the output ? Alright. Now I'm confused... The scanner now works correctly with the original rule: SUBSYSTEM!=usb_device, GOTO=libsane_rules_end and not with the 'usb_endpoint' rule... I don't understand what's changed. When I last debugged this I got the scanner to work using % chgrp scanner /dev/usbdev3.4_ep* where /dev/usbdev3.4_ep* are the devices generated by udev for the scanner. (With the original rule they are created with user:group = root:root.) If I changed the group back to 'root' then saned would fail. This was tested several times. The modified 'usb_endpoint' rule allowed those devices to be created with the scanner group and the problem was fixed -- I thought. Now I try it this afternoon and it no longer works. Examination with 'lsof' showed saned was trying to open /dev/bus/usb/003/004 and failed. The 'usb_endpoint' version of the rule doesn't match for that node so it was created with the 'root' group and saned failed with a permission error. Changing the udev rule back to the original version (SUBSYSTEM!=usb_device) causes udev to create the /dev/bus/usb/003/004 node with group 'scanner' (and the /dev/usbdev3.4_ep* devices with group 'root'). saned apparently doesn't care about the /dev/usbdev3.4_ep* devs (now?) so it works... Unfortunately I didn't run lsof in my earlier debugging effort so I guess don't know for certain what device was ultimately being opened at that time. The original rule continues to work after several unplug/plugin cycles and a reboot. At the moment I have to assume I screwed up my earlier analysis and the original rule is correct. Is it possible for the autoprobed scanner device to be indeterminate? The CX6600 is a multifunction printer/scanner unit with built-in card reader so many different devices are created when it's plugged in -- could there be some weird race condition? Arrgh. Feel free to close the bug. If it happens again I'll do some more thorough tests. FWIW, I've attached the udevmonitor output you requested. It probably isn't very interesting anymore. -- Brad --- ## udevmonitor output for Epson CX6600 under kernel 2.6.20.7 ## --- udevmonitor prints the received event from the kernel [UEVENT] and the event which udev sends out after rule processing [UDEV] UEVENT[1177190375.848031] add@/devices/pci:00/:00:09.2/usb3/3-4 UEVENT[1177190375.848123] add@/class/usb_endpoint/usbdev3.6_ep00 UEVENT[1177190375.848608] add@/devices/pci:00/:00:09.2/usb3/3-4/3-4:1.0 UEVENT[1177190375.849082] add@/class/usb_endpoint/usbdev3.6_ep01 UEVENT[1177190375.849103] add@/class/usb_endpoint/usbdev3.6_ep82 UEVENT[1177190375.849114] add@/devices/pci:00/:00:09.2/usb3/3-4/3-4:1.1 UEVENT[1177190375.849480] add@/class/usb_endpoint/usbdev3.6_ep04 UEVENT[1177190375.849496] add@/class/usb_endpoint/usbdev3.6_ep85 UDEV [1177190375.856662] add@/devices/pci:00/:00:09.2/usb3/3-4 UDEV [1177190375.868321] add@/class/usb_endpoint/usbdev3.6_ep00 UDEV [1177190375.880210] add@/class/usb_endpoint/usbdev3.6_ep01 UDEV [1177190375.892093] add@/class/usb_endpoint/usbdev3.6_ep82 UDEV [1177190375.907295] add@/devices/pci:00/:00:09.2/usb3/3-4/3-4:1.0 UDEV [1177190375.911890] add@/devices/pci:00/:00:09.2/usb3/3-4/3-4:1.1 UDEV [1177190375.920133] add@/class/usb_endpoint/usbdev3.6_ep04 UDEV [1177190375.923739] add@/class/usb_endpoint/usbdev3.6_ep85 UEVENT[1177190380.847810] add@/class/usb/lp0 UEVENT[1177190380.847864] remove@/class/usb_endpoint/usbdev3.6_ep04 UEVENT[1177190380.847876] remove@/class/usb_endpoint/usbdev3.6_ep85 UEVENT[1177190380.848139] add@/devices/pci:00/:00:09.2/usb3/3-4/3-4:1.2 UEVENT[1177190380.848154] add@/class/scsi_host/host2 UEVENT[1177190380.848164] add@/class/usb_endpoint/usbdev3.6_ep07 UEVENT[1177190380.848174] add@/class/usb_endpoint/usbdev3.6_ep88 UEVENT[1177190380.848184] add@/class/usb_device/usbdev3.6 UDEV [1177190380.867483] remove@/class/usb_endpoint/usbdev3.6_ep04 UDEV [1177190380.868897] remove@/class/usb_endpoint/usbdev3.6_ep85 UDEV [1177190380.870578] add@/devices/pci:00/:00:09.2/usb3/3-4/3-4:1.2 UDEV [1177190380.908789] add@/class/usb/lp0 UDEV [1177190380.929759] add@/class/usb_endpoint/usbdev3.6_ep07 UDEV [1177190380.938513] add@/class/usb_endpoint/usbdev3.6_ep88 UDEV [1177190380.940261] add@/class/scsi_host/host2 UDEV [1177190381.007999] add@/class/usb_device/usbdev3.6 UEVENT[1177190385.849832] add@/devices/pci:00/:00:09.2/usb3/3-4/3-4:1.2/host2/target2:0:0/2:0
Bug#359797: libsane: udev rules file broken
Package: libsane
Version: 1.0.18-6
Followup-For: Bug #359797
The patch suggested by Henrique causes libsane.rules to fail to match my
scanner (an Epson CX6600). The problem is that udev sees a subsystem class
of usb_endpoint not usb_device so the following line causes the bulk of
libsane.rules to be skipped:
SUBSYSTEM!=usb_device, GOTO=libsane_rules_end
Changing the line to
SUBSYSTEM!=usb_endpoint, GOTO=libsane_rules_end
allows the rule to match and fixes the problem for me.
I assume that this is a change in how kernel 2.6.20.7 reports this device?
I've attached a udevinfo dump for the curious.
-- Brad
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable'), (80, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20.7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages libsane depends on:
ii adduser 3.102Add and remove users and groups
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libgphoto2-22.2.1-16 gphoto2 digital camera library
ii libgphoto2-port02.2.1-16 gphoto2 digital camera port librar
ii libieee1284-3 0.2.10-4 cross-platform library for paralle
ii libjpeg62 6b-13The Independent JPEG Group's JPEG
ii libtiff43.8.2-7 Tag Image File Format (TIFF) libra
ii libusb-0.1-42:0.1.12-5 userspace USB programming library
ii makedev 2.3.1-83 creates device files in /dev
Versions of packages libsane recommends:
ii module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo
ii sane-utils1.0.18-5 API library for scanners -- utilit
ii udev 0.105-4/dev/ and hotplug management daemo
-- no debconf information
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device '/class/usb_endpoint/usbdev3.3_ep01':
KERNEL==usbdev3.3_ep01
SUBSYSTEM==usb_endpoint
DRIVER==
ATTR{direction}==out
ATTR{type}==Bulk
ATTR{interval}==0ms
ATTR{wMaxPacketSize}==0200
ATTR{bInterval}==00
ATTR{bmAttributes}==02
ATTR{bEndpointAddress}==01
ATTR{bLength}==07
ATTR{dev}==254:9
looking at parent device '/devices/pci:00/:00:09.2/usb3/3-4/3-4:1.0':
KERNELS==3-4:1.0
SUBSYSTEMS==usb
DRIVERS==
ATTRS{interface}==EPSON Scanner
ATTRS{modalias}==usb:v04B8p0813d0100dc00dsc00dp00icFFiscFFipFF
ATTRS{bInterfaceProtocol}==ff
ATTRS{bInterfaceSubClass}==ff
ATTRS{bInterfaceClass}==ff
ATTRS{bNumEndpoints}==02
ATTRS{bAlternateSetting}== 0
ATTRS{bInterfaceNumber}==00
looking at parent device '/devices/pci:00/:00:09.2/usb3/3-4':
KERNELS==3-4
SUBSYSTEMS==usb
DRIVERS==usb
ATTRS{serial}==HD0140406010327180
ATTRS{product}==USB2.0 MFP_Hi-Speed_
ATTRS{manufacturer}==EPSON
ATTRS{maxchild}==0
ATTRS{version}== 2.00
ATTRS{devnum}==3
ATTRS{speed}==480
ATTRS{bMaxPacketSize0}==64
ATTRS{bNumConfigurations}==1
ATTRS{bDeviceProtocol}==00
ATTRS{bDeviceSubClass}==00
ATTRS{bDeviceClass}==00
ATTRS{bcdDevice}==0100
ATTRS{idProduct}==0813
ATTRS{idVendor}==04b8
ATTRS{bMaxPower}== 2mA
ATTRS{bmAttributes}==c0
ATTRS{bConfigurationValue}==1
ATTRS{bNumInterfaces}== 3
ATTRS{configuration}==USB2.0 MFP_Hi-Speed_
looking at parent device '/devices/pci:00/:00:09.2/usb3':
KERNELS==usb3
SUBSYSTEMS==usb
DRIVERS==usb
ATTRS{serial}==:00:09.2
ATTRS{product}==EHCI Host Controller
ATTRS{manufacturer}==Linux 2.6.20.7 ehci_hcd
ATTRS{maxchild}==5
ATTRS{version}== 2.00
ATTRS{devnum}==1
ATTRS{speed}==480
ATTRS{bMaxPacketSize0}==64
ATTRS{bNumConfigurations}==1
ATTRS{bDeviceProtocol}==01
ATTRS{bDeviceSubClass}==00
ATTRS{bDeviceClass}==09
ATTRS{bcdDevice}==0206
ATTRS{idProduct}==
ATTRS{idVendor}==
ATTRS{bMaxPower}== 0mA
ATTRS{bmAttributes}==e0
ATTRS{bConfigurationValue}==1
ATTRS{bNumInterfaces}== 1
ATTRS{configuration}==
looking at parent device '/devices/pci:00/:00:09.2':
KERNELS==:00:09.2
SUBSYSTEMS==pci
DRIVERS==ehci_hcd
ATTRS{msi_bus}==
ATTRS{broken_parity_status}==0
ATTRS{enable}==1
ATTRS{modalias}==pci:v1033d00E0sv0E55sd2928bc0Csc03i20
ATTRS{local_cpus}==1
ATTRS{irq}==11
ATTRS{class}==0x0c0320
ATTRS{subsystem_device}==0x2928
ATTRS{subsystem_vendor}==0x0e55
ATTRS{device}==0x00e0
ATTRS{vendor}==0x1033
looking at parent device
Bug#419349: libsane: Incorrect udev rule for Epson CX6600
Package: libsane
Version: 1.0.18-6
Severity: normal
Tags: patch
The Epson CX6600 does not share the same idProduct as the CX6400 so the
udev rule that is supposed to match the Epson CX6600 fails.
The information reported by my CX6600 is
idVendor 0x04b8
idProduct 0x0813
The attached patch adds a new line in libsane.rules for the CX6600.
-- Brad
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable'), (80, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20.7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages libsane depends on:
ii adduser 3.102Add and remove users and groups
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libgphoto2-22.2.1-16 gphoto2 digital camera library
ii libgphoto2-port02.2.1-16 gphoto2 digital camera port librar
ii libieee1284-3 0.2.10-4 cross-platform library for paralle
ii libjpeg62 6b-13The Independent JPEG Group's JPEG
ii libtiff43.8.2-7 Tag Image File Format (TIFF) libra
ii libusb-0.1-42:0.1.12-5 userspace USB programming library
ii makedev 2.3.1-83 creates device files in /dev
Versions of packages libsane recommends:
ii module-init-tools 3.3-pre4-2 tools for managing Linux kernel mo
ii sane-utils1.0.18-5 API library for scanners -- utilit
ii udev 0.105-4/dev/ and hotplug management daemo
-- no debconf information
--- libsane.rules.orig 2007-04-15 02:53:30.0 -0400
+++ libsane.rules 2007-04-15 02:54:34.0 -0400
@@ -434,8 +433,10 @@
SYSFS{idVendor}==04b8, SYSFS{idProduct}==0801, MODE=664, GROUP=scanner
# Epson CX-3200
SYSFS{idVendor}==04b8, SYSFS{idProduct}==0802, MODE=664, GROUP=scanner
-# Epson CX-6400 | Epson CX-6600
+# Epson CX-6400
SYSFS{idVendor}==04b8, SYSFS{idProduct}==0805, MODE=664, GROUP=scanner
+# Epson CX-6600
+SYSFS{idVendor}==04b8, SYSFS{idProduct}==0813, MODE=664, GROUP=scanner
# Epson RX-600
SYSFS{idVendor}==04b8, SYSFS{idProduct}==0806, MODE=664, GROUP=scanner
# Epson RX-500
Bug#418212: libpam-opie: Missing mandatory call to opieverify() after opiechallenge()
Package: libpam-opie
Version: 0.21-8
Severity: normal
Tags: patch
According to the preamble to opiechallenge() in the libopie source you
MUST call opieverify() to clear the lock and any internal state even if
the challenge fails. This is not done in libpam-opie.
The attached patch fixes this coding error and removes the '-Wtraditional'
compilation flag that was generating spurious ISO C style warnings with
recent versions of gcc.
I found that the missing opieverify() problem was first identified by Matt
Johnston in the (otherwise unrelated) wishlist bug #237814.
-- Brad
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (1000, 'testing'), (80, 'unstable'), (60, 'experimental')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.19.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages libpam-opie depends on:
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libpam0g0.79-4 Pluggable Authentication Modules l
Versions of packages libpam-opie recommends:
hi opie-server 2.32-10.2 OPIE programs for maintaining an O
-- no debconf information
Common subdirectories: libpam-opie-0.21/debian and libpam-opie-0.21-9/debian
Only in libpam-opie-0.21-9/: dynamic
Only in libpam-opie-0.21-9/: install-stamp
diff -uBb libpam-opie-0.21/Makefile libpam-opie-0.21-9/Makefile
--- libpam-opie-0.21/Makefile 2007-04-07 21:33:31.0 -0400
+++ libpam-opie-0.21-9/Makefile 2007-04-07 21:27:17.0 -0400
@@ -25,7 +25,7 @@
export CC=gcc
export CFLAGS=-O2 -Dlinux -DLINUX_PAM \
-ansi -D_POSIX_SOURCE -Wall -Wwrite-strings \
- -Wpointer-arith -Wcast-qual -Wcast-align -Wtraditional \
+ -Wpointer-arith -Wcast-qual -Wcast-align \
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Winline \
-Wshadow -pedantic -fPIC
export MKDIR=mkdir -p
diff -uBb libpam-opie-0.21/pam_opie.c libpam-opie-0.21-9/pam_opie.c
--- libpam-opie-0.21/pam_opie.c 2007-04-07 21:33:31.0 -0400
+++ libpam-opie-0.21-9/pam_opie.c 2007-04-07 21:27:26.0 -0400
@@ -29,6 +29,7 @@
#define PAM_SM_AUTH
#include security/pam_modules.h
#include stdlib.h
+#include string.h
#include opie.h
int converse(pam_handle_t*, int, struct pam_message**, struct pam_response**);
@@ -95,6 +96,7 @@
retval = opiechallenge(opie, principal, challenge);
if (principal != NULL) free(principal);
if ((retval 0) || (retval 1)) {
+ opieverify(opie, NULL); /* Must always call opieverify before returning */
return PAM_AUTHINFO_UNAVAIL;
}
knownuser = (retval == 0) ? 1 : 0;
@@ -106,8 +108,10 @@
msg[0].msg = challenge;
resp = NULL;
retval = converse(pamh, 1, pmsg, resp);
- if (retval != PAM_SUCCESS)
+ if (retval != PAM_SUCCESS) {
+ opieverify(opie, NULL); /* Must always call opieverify before returning */
return retval;
+ }
tok = xstrdup(resp[0].resp);
if (resp != NULL) free(resp);
pam_set_item(pamh, PAM_AUTHTOK, tok);
Bug#414015: accessfile.c not used in libpam-opie (but still exists in libopie.a)
Package: libpam-opie Version: 0.21-8 Followup-For: Bug #414015 'libopie/accessfile.c' is not compiled into the pam module so this bug does not apply here. The clean target in debian/rules actually does 'rm -rf libopie' before building libpam_opie.so. Strange packaging decision. Note that this /would/ be a bug in one of the other packages derived from opie source (ie. libopie-dev, opie-client, opie-server) except AFAICT none of them actually include anything that depends on that function (ie. opieftpd, opielogin, opiesu). I'll reassign this bug to the parent opie source package. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (1000, 'testing'), (80, 'unstable'), (60, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages libpam-opie depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libpam0g0.79-4 Pluggable Authentication Modules l Versions of packages libpam-opie recommends: ii opie-server 2.32-10.2 OPIE programs for maintaining an O -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417595: elog: init script shell variables should be sanitized
Package: elog Version: 2.6.3+r1764-1 Severity: minor Many of the shell variables used in /etc/ini.d/elog are neither unset, nor initialized to safe/reasonable defaults. At best this is not very robust and could lead to unintended consequences. I'd recommend creating '/etc/default/elog' with the following line to explicitly clear variables used in elogd's argument list: unset PIDFILE CONFFILE LOGBOOKDIR RESOURCEDIR PORT HOST VERBOSE -- Brad -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (1000, 'testing'), (80, 'unstable'), (60, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages elog depends on: ii adduser 3.102Add and remove users and groups ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries elog recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409577: ibam: Fix for APM charge status problem
*** Please type your report below this line *** The chargeStatus flag was being extracted from the APM batteryStatus field instead of the batteryFlag field. The two fields have virtually the same structure and the first 4 bits _should_ report the same information, but they do not. My bios reports an APM version of 1.2 whereas the ibam source suggests the APM version field is Usually 1.0 or 1.1, so I guess this could be a change in the APM spec for v1.2... However, since the OP reported that this problem began recently on his machine I assume that it is a change/regression in the kernel support (unless he updated his bios). Unfortunately I haven't run anything but kernel 2.6.18 on this machine so I can't tell you when/if the kernel behavior changed. The attached patch changes the test to use the batteryFlag field. This should be completely backwards compatible, even if the kernel support did change. (Unless it was broken the other way around before?) -- Brad -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (1000, 'testing'), (80, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages ibam depends on: ii debconf [debconf-2.0] 1.5.13 Debian configuration management sy ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-21 GCC support library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ibam recommends no packages. -- no debconf information --- ibam-0.4/ibam.inl 2005-11-12 05:36:58.0 -0500 +++ ibam-0.4-fixed/ibam.inl 2007-03-30 15:33:31.0 -0400 @@ -133,7 +133,7 @@ in c d; // 0x in c d; batteryFlag=(c'9'?c-'a'+10:c-'0')*16+(d'9'?d-'a'+10:d-'0'); - chargeStatus = (batteryStatus8)!=0; + chargeStatus = (batteryFlag8)!=0; in remainingBatteryPercent c; // % string minsec; in remainingBatteryLifeSeconds minsec;
Bug#410958: [Pkg-xfce-devel] Bug#410958: xfce4-panel: Unnecessary dependency on 'mousepad'?
On Wed, 14 Feb 2007, Yves-Alexis Perez wrote: On mer, 2007-02-14 at 16:18 -0500, Brad Sawatzky wrote: Can the dependence on 'mousepad' (see description below) be removed? It seems odd that a panel manager would actually require a graphical text editor... Well, the dependency (you may already know this, but...) is required because the default panel includes a launcher wich runs mousepad. Without mousepad installed it will throw an error, and there is no simple way to be sure that it's installed otherwise, and there is no alternatives for graphical text editors. Hmm, that's unfortunate. I see the rationale, but I guess my vote would be to drop the default launcher. That's driven by principle, more than anything else (mousepad *is* quite lightweight/small). Having a graphical text editor bundled pulled in by a general-purpose launcher just rings my bloat-alarms :-) Feel free to reassign this as 'Wishlist' if you think dropping the default launcher (and associated dependency) is a bad plan. (BTW, thanks for your work on maintaining this package (and the others). It's much appreciated.) -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410958: xfce4-panel: Unnecessary dependency on 'mousepad'?
Package: xfce4-panel Version: 4.3.99.2-2 Severity: minor Can the dependence on 'mousepad' (see description below) be removed? It seems odd that a panel manager would actually require a graphical text editor... Package: mousepad Description: simple Xfce oriented text editor Mousepad is a graphical text editor for Xfce based on Leafpad. -- Brad -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (80, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19.2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages xfce4-panel depends on: ii libatk1.0-0 1.12.4-1 The ATK accessibility toolkit ii libc6 2.3.6.ds1-11 GNU C Library: Shared libraries ii libcairo2 1.2.4-4The Cairo 2D vector graphics libra ii libexo-0.3-0 0.3.1.12rc2-1 Library with extensions for Xfce ii libfontconfig12.4.2-1generic font configuration library ii libfreetype6 2.2.1-5FreeType 2 font engine, shared lib ii libglib2.0-0 2.12.4-2 The GLib library of C routines ii libgtk2.0-0 2.8.20-5 The GTK+ graphical user interface ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libpango1.0-0 1.14.8-4 Layout and rendering of internatio ii libpng12-01.2.15~beta5-1 PNG library - runtime ii libsm61:1.0.1-3 X11 Session Management library ii libstartup-notification0 0.8-2 library for program launch feedbac ii libx11-6 2:1.0.3-5 X11 client-side library ii libxcursor1 1.1.7-4X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxfce4mcs-client3 4.3.99.2-1 Client library for Xfce4 configure ii libxfce4mcs-manager3 4.3.99.2-1 Manager library for Xfce4 configur ii libxfce4util4 4.3.99.2-1 Utility functions library for Xfce ii libxfcegui4-4 4.3.99.2-1 Basic GUI C functions for Xfce4 ii libxfixes31:4.0.1-5 X11 miscellaneous 'fixes' extensio ii libxi61:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1X11 Xinerama extension library ii libxrandr22:1.1.0.2-5X11 RandR extension library ii libxrender1 1:0.9.1-3 X Rendering Extension client libra pi mousepad 0.2.8-1simple Xfce oriented text editor ii zlib1g1:1.2.3-13 compression library - runtime xfce4-panel recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407331: firestarter: Update non-routable table to allow 89.0.0.0/8
Package: firestarter Version: 1.0.3-1.3 Severity: normal The 89.0.0.0/8 net block appears to have been assigned and should be removed from the '/etc/firestarter/non-routables' table. (I only noticed this because there appears to be an ntp server on the debian ntp round-robin in that netblock.) -- Brad -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (80, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.28 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages firestarter depends on: ii gconf2 2.16.0-3 GNOME configuration database syste ii gksu2.0.0-1 graphical frontend to su ii iptables1.3.6.0debian1-5 administration tools for packet fi ii libart-2.0-22.3.17-1 Library of functions for 2D graphi ii libatk1.0-0 1.12.4-1 The ATK accessibility toolkit ii libaudiofile0 0.2.6-6 Open-source version of SGI's audio ii libavahi-client30.6.15-2 Avahi client library ii libavahi-common30.6.15-2 Avahi common library ii libavahi-glib1 0.6.15-2 Avahi glib integration library ii libbonobo2-02.14.0-3 Bonobo CORBA interfaces library ii libbonoboui2-0 2.14.0-5 The Bonobo UI library ii libc6 2.3.6.ds1-8 GNU C Library: Shared libraries ii libcairo2 1.2.4-4 The Cairo 2D vector graphics libra ii libdbus-1-3 1.0.2-1 simple interprocess messaging syst ii libesd-alsa0 [libesd0] 0.2.36-3 Enlightened Sound Daemon (ALSA) - ii libfontconfig1 2.4.1-2 generic font configuration library ii libfreetype62.2.1-5 FreeType 2 font engine, shared lib ii libgconf2-4 2.16.0-3 GNOME configuration database syste ii libgcrypt11 1.2.3-2 LGPL Crypto library - runtime libr ii libglade2-0 1:2.6.0-4library to load .glade files at ru ii libglib2.0-02.12.4-2 The GLib library of C routines ii libgnome-keyring0 0.6.0-3 GNOME keyring services library ii libgnome2-0 2.16.0-2 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomeui-02.14.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.14.2-4 GNOME virtual file-system (runtime ii libgnutls13 1.4.4-3 the GNU TLS library - runtime libr ii libgpg-error0 1.4-1library for common error values an ii libgtk2.0-0 2.8.20-3 The GTK+ graphical user interface ii libice6 1:1.0.1-2X11 Inter-Client Exchange library ii libjpeg62 6b-13The Independent JPEG Group's JPEG ii liborbit2 1:2.14.3-0.1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.14.8-4 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-1 PNG library - runtime ii libpopt01.10-3 lib for parsing cmdline parameters ii libsm6 1:1.0.1-3X11 Session Management library ii libtasn1-3 0.3.6-2 Manage ASN.1 structures (runtime) ii libx11-62:1.0.3-4X11 client-side library ii libxcursor1 1.1.7-4 X cursor management library ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-5X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-4X11 Input extension library ii libxinerama11:1.0.1-4.1 X11 Xinerama extension library ii libxml2 2.6.27.dfsg-1GNOME XML library ii libxrandr2 2:1.1.0.2-5 X11 RandR extension library ii libxrender1 1:0.9.1-3X Rendering Extension client libra ii zlib1g 1:1.2.3-13 compression library - runtime firestarter recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386227: [Pkg-spca5xx-devel] Bug#386227: spca5xx-source: Compile failure with kernel 2.6.18
On Tue, 17 Oct 2006, Kel Modderman wrote: On Tuesday 17 October 2006 05:23, Moritz Muehlenhoff wrote: severity 386227 grave thanks Package: spca5xx-source Version: 20060501-1 Severity: important Tags: patch [ . . . ] spca5xx-source has been integrated in linux-modules-extra-2.6. I suppose it should be removed entirely? Yes, it should. linux-modules-extra-2.6 appears to be sort of a meta-package -- it depends on the '*-source' packages being available for the modules it wants to build. I just took a look at the source package for linux-modules-extra-2.6 (2.6.18-1) unstable (5 Oct 2006) and the control file lists a depend on spca5xx-source. I don't think you want to remove spca5xx-source. (Or did I misunderstand what you meant?) -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386227: spca5xx-source: Compile failure with kernel 2.6.18
Package: spca5xx-source Version: 20060501-1 Severity: important Tags: patch Some v4l header information got shuffled around in kernel 2.6.18. The attached patch updates spca5xx.h to include media/v4l2-common.h. Seems to work after that. You may want to check to see if the v4l changes came in during 2.6.17 and update the patch accordingly. -- Brad -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (80, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-rc5 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages spca5xx-source depends on: ii bzip2 1.0.3-3high-quality block-sorting file co ii debhelper 5.0.37.3 helper programs for debian/rules ii module-assistant 0.10.6 tool to make module package creati spca5xx-source recommends no packages. -- no debconf information --- spca5xx/drivers/usb/spca5xx.h 2006-05-08 07:01:40.0 -0400 +++ spca5xx.new/drivers/usb/spca5xx.h 2006-09-05 13:42:26.0 -0400 @@ -14,6 +14,10 @@ #include linux/usb.h #include linux/version.h +#if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,18) +#include media/v4l2-common.h +#endif + #if LINUX_VERSION_CODE = KERNEL_VERSION(2,4,20) LINUX_VERSION_CODE KERNEL_VERSION(2,5,0) #define urb_t struct urb
Bug#386229: shfs-source: Build failure with kernel 2.6.18
Package: shfs-source
Version: 0.35-6
Severity: important
Tags: patch
The module source fails to build with kernel 2.6.18 due to a change in the
get_sb_nodev() calling arguments. The attached patch updates inode.c with
the minor change.
NOTE: The patch doesn't have any kernel-version ifdefs... Sorry about
that, I don't know what version of the kernel introduced the change...
-- Brad
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing'), (80, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-rc5
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages shfs-source depends on:
ii bzip2 1.0.3-3high-quality block-sorting file co
ii debconf 1.5.3 Debian configuration management sy
ii debhelper 5.0.37.3 helper programs for debian/rules
ii module-assistant 0.10.6 tool to make module package creati
Versions of packages shfs-source recommends:
ii shfs-utils0.35-6 (secure) SHell File System mount p
-- no debconf information
--- inode.c 2006-04-14 17:55:49.0 -0400
+++ ../../../inode.c 2006-09-05 00:35:59.0 -0400
@@ -343,9 +343,9 @@
static struct super_block *
shfs_get_sb(struct file_system_type *fs_type,
- int flags, const char *dev_name, void *data)
+ int flags, const char *dev_name, void *data, struct vfsmount *mnt)
{
- return get_sb_nodev(fs_type, flags, data, shfs_read_super);
+ return get_sb_nodev(fs_type, flags, data, shfs_read_super, mnt);
}
static struct file_system_type sh_fs_type = {
Bug#381520: python-apt: Simple rebuild of package fixes segfault
Package: python-apt Followup-For: Bug #381520 Just stumbled across this bug while configuring my new AMD64 machine. Using several of the 'wajig' commands will trigger the segfault in TAgFileFree() as Devin reported. (wajig is another debian package that written in python that integrates many of the apt-foo functions.) For example, these will both trigger the segfault in the python-apt module currently on the mirrors: wajig show python wajig changelog python Simply rebuilding the module with a current debian/etch environment appears to have fixed the problem. The version of gcc used in my rebuild was '4:4.1.1-5' -- Brad -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (80, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-rc5 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages python-apt depends on: ii apt [libapt-pkg-libc6.3-6-3. 0.6.45 Advanced front-end for dpkg ii apt-utils [libapt-inst-libc6 0.6.45 APT utility programs ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-11 GCC support library ii libstdc++6 4.1.1-11The GNU Standard C++ Library v3 ii python 2.4.3-11An interactive high-level object-o ii python-central 0.5.5 register and build utility for Pyt python-apt recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381520: python-apt: Simple rebuild of package fixes segfault
Package: python-apt Followup-For: Bug #381520 Just stumbled across this bug while configuring my new AMD64 machine. Using several of the 'wajig' commands will trigger the segfault in TAgFileFree() as Devin reported. (wajig is another debian package that written in python that integrates many of the apt-foo functions.) For example, these will both trigger the segfault in the python-apt module currently on the mirrors: wajig show python wajig changelog python Simply rebuilding the module with a current debian/etch environment appears to have fixed the problem. The version of gcc used in my rebuild was '4:4.1.1-5' -- Brad -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (80, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-rc5 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages python-apt depends on: ii apt [libapt-pkg-libc6.3-6-3. 0.6.45 Advanced front-end for dpkg ii apt-utils [libapt-inst-libc6 0.6.45 APT utility programs ii libc62.3.6.ds1-4 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-11 GCC support library ii libstdc++6 4.1.1-11The GNU Standard C++ Library v3 ii python 2.4.3-11An interactive high-level object-o ii python-central 0.5.5 register and build utility for Pyt python-apt recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347860: [Pkg-spca5xx-devel] Bug#347860: spca5xx-source: make-kpkg module_image build fails (with kernel 2.6.14.6)
On Fri, 13 Jan 2006, Kel Modderman wrote: michel Xhaard wrote: Le Vendredi 13 Janvier 2006 05:35, Brad Sawatzky a écrit : Strange my original spca5xx-20051212 include linux/version.h on top of the spca50x.h file ? #ifdef __KERNEL__ #include asm/uaccess.h #include linux/videodev.h #include linux/smp_lock.h #include linux/usb.h #include linux/version.h Are you sure you are using the right source code ? Precisely what I was going to ask. Otavio submitted that same patch to Michel quite a few realeses ago, and spca5xx.h certainly includes linux/version as far as I can see. Please double check you have removed any previous spca5xx source from /usr/src/modules and unpacked the latest spca5xx source tarball. Ah hell, that was exactly the problem. How embarrassing... Sorry for wasting your time. Please close the bug, compiling the _current_ source works quite nicely with 2.6.14.x. -- Brad -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347860: spca5xx-source: make-kpkg module_image build fails (with kernel 2.6.14.6)
Package: spca5xx-source
Version: 20051212-1
Severity: important
Tags: patch
The spca5xx module fails to build through the make-kpkg system with kernel
2.6.14.6 (obtained from kernel.org).
The build process works from the /usr/src/linux-2.6.12.3/ directory with
all the same tools. I presume the new kernel removed an 'include
linux/version.h' out of one of the kernel header files that is included
in '/usr/src/modules/spca5xx/drivers/usb/spcadecoder.h'.
The attached patch simply adds an explicit 'include linux/version.h' to
'spcadecoder.h' which appears to solve the problem.
-- Brad
--- Build log below ---
[EMAIL PROTECTED] 1062% fakeroot make-kpkg --added-modules spca5xx
modules_image
exec debian/rules DEBIAN_REVISION=gcc3.4 KPKG_SELECTED_MODULES=spca5xx
modules_image
== making .config because of ==
test -f .config || test ! -f .config.save || \
cp -pf .config.save .config
test -f .config || test ! -f .config || \
cp -pf .config .config
test -f .config || test ! -f ./debian/config || \
cp -pf ./debian/config .config
test -f .config || (echo *** Need a config file .config false)
for module in /usr/src/modules/spca5xx ; do \
if test -d $module; then\
(cd $module; \
if ./debian/rules KVERS=2.6.14.6 KSRC=/usr/src/linux-2.6.14.6
\
KMAINT=Brad Sawatzky KEMAIL=[EMAIL PROTECTED]
\
KPKG_DEST_DIR=/usr/src/linux-2.6.14.6/.. \
KPKG_MAINTAINER=Brad Sawatzky\
KPKG_EXTRAV_ARG=\
ARCH=i386 \
KDREV=gcc3.4 kdist_image; then\
echo Module $module processed fine;\
else \
echo Module $module failed.; \
if [ X != X ]; then \
echo Perhaps $module does not understand --rootcmd?; \
echo If you see messages that indicate that it is not; \
echo in fact being built as root, please file a bug ; \
echo against $module.; \
fi; \
echo Hit return to Continue; \
read ans;\
fi; \
);\
else \
echo Module $module does not exist; \
echo Hit return to Continue?; \
fi; \
done
make[1]: Entering directory `/usr/src/modules/spca5xx'
/usr/bin/make -w -f debian/rules kdist_clean kdist_config binary-modules
make[2]: Entering directory `/usr/src/modules/spca5xx'
dh_testdir
dh_testroot
dh_clean
/usr/bin/make -C /usr/src/modules/spca5xx clean
make[3]: Entering directory `/usr/src/modules/spca5xx'
rm -r -f drivers/usb/*.o drivers/usb/.spcadecoder.o.cmd \
drivers/usb/.spca5xx.o.cmd *.o *.ko *.mod.* .[a-z]* core *.i
make[3]: Leaving directory `/usr/src/modules/spca5xx'
/usr/bin/gcc-3.4
for templ in ; do \
cp $templ `echo $templ | sed -e 's/_KVERS_/2.6.14.6/g'` ; \
done
for templ in `ls debian/*.modules.in` ; do \
test -e ${templ%.modules.in}.backup || cp ${templ%.modules.in}
${templ%.modules.in}.backup 2/dev/null || true; \
sed -e 's/##KVERS##/2.6.14.6/g ;s/#KVERS#/2.6.14.6/g ; s/_KVERS_/2.6.14.6/g
; s/##KDREV##/gcc3.4/g ; s/#KDREV#/gcc3.4/g ; s/_KDREV_/gcc3.4/g' $templ
${templ%.modules.in}; \
done
dh_testroot
dh_clean -k
# Build the module
/usr/bin/make -C /usr/src/modules/spca5xx KERNEL_VERSION=2.6.14.6
KERNELDIR=/usr/src/linux-2.6.14.6
make[3]: Entering directory `/usr/src/modules/spca5xx'
Building SPCA5XX driver for 2.5/2.6 kernel.
Remember: you must have read/write access to your kernel source tree.
/usr/bin/make -C /usr/src/linux-2.6.14.6 SUBDIRS=/usr/src/modules/spca5xx
modules
make[4]: Entering directory `/usr/src/linux-2.6.14.6'
CC [M] /usr/src/modules/spca5xx/drivers/usb/spca5xx.o
In file included from /usr/src/modules/spca5xx/drivers/usb/spca5xx.c:763:
/usr/src/modules/spca5xx/drivers/usb/mr97311.h: In function `pcam_start':
/usr/src/modules/spca5xx/drivers/usb/mr97311.h:391: warning: ISO C90 forbids
mixed declarations and code
CC [M] /usr/src/modules/spca5xx/drivers/usb/spcadecoder.o
In file included from /usr/src/modules/spca5xx/drivers/usb/spcadecoder.h:5,
from /usr/src/modules/spca5xx/drivers
Bug#324220: repeatedly segfaults when xmms connects to immsd
Package: imms
Version: 2.0.3-2
Severity: grave
Tags: patch,sid
Justification: renders package unusable
immsd will repeatedly segfault as soon as XMMS connects to its socket. The
underlying problem is a bug (feature?) with initstate_r() from
libc6(2.3.5). See also a
href=http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323811;Bug
323811/a.
While this is definitely a libc6 bug, there is an easy workaround that
allows imms to work until libc is fixed. See attached patch (which is
technically for 2.1.1 but should apply to any 2.x source).
-- Brad
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12.3
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages imms depends on:
ii fftw3 3.0.1-13 library for computing Fast Fourier
ii libc6 2.3.5-4 GNU C Library: Shared libraries an
ii libgcc1 1:4.0.1-5GCC support library
ii libglib1.2 1.2.10-10The GLib library of C routines
ii libglib2.0-02.8.0-1 The GLib library of C routines
ii libgtk1.2 1.2.10-17The GIMP Toolkit set of widgets fo
ii libpcre35.0-1.1 Perl 5 Compatible Regular Expressi
ii libsqlite3-03.2.2-3 SQLite 3 shared library
ii libstdc++6 4.0.1-5 The GNU Standard C++ Library v3
ii libtag1c2 1.3.1-1.1TagLib Audio Meta-Data Library
ii libx11-66.8.2.dfsg.1-5 X Window System protocol client li
ii libxext66.8.2.dfsg.1-5 X Window System miscellaneous exte
ii libxi6 6.8.2.dfsg.1-5 X Window System Input extension li
ii libxss1 6.8.2.dfsg.1-5 X Screen Saver client-side library
ii xlibs 6.8.2.dfsg.1-5 X Window System client libraries m
ii xmms1.2.10+cvs20050209-2 Versatile X audio player that look
ii zlib1g 1:1.2.3-3compression library - runtime
Versions of packages imms recommends:
ii sox 12.17.7-3 A universal sound sample translato
pn sqlitenone (no description available)
ii sqlite3 3.2.2-3A command line interface for SQLit
-- no debconf information
--- imms-2.1.1.orig/immscore/utils.cc
+++ imms-2.1.1/immscore/utils.cc
@@ -25,6 +25,7 @@
static bool initialized = false;
if (!initialized)
{
+rand_data.state = (int32_t*)rand_state;
initstate_r(time(0), rand_state, sizeof(rand_state), rand_data);
initialized = true;
}
