On 2013-05-16 09:47, Simon McVittie wrote: > Please use a Subject line that summarizes the subject of the email.
ACK > On 16/05/13 07:00, Christian Kastner wrote: >> Would it be possible to include [a fix for libdbus-related >> thread-safety problems in colord] in the next Wheezy point >> release (7.0.1)? > > I suspect the necessary changes to be rather too large for a stable > update, given that the changelog describes it as a "rewrite". However, a > necessary first step would be for people who reliably get this crash to > confirm that 0.1.31 actually fixes it. I will try to confirm this over the weekend, but I too doubt that a rewrite will be accepted into a point release. > It looks as though a less intrusive fix for wheezy might be to drop the > "full" SANE plugin and instead backport the udev-based cd-plugin-scanner > module added by commit ebf3e961, which can detect local scanners but not > networked ones: > > +# If we should use SANE to add scanner and camera devices. > +# > +# If SANE support is installed then this will allow colord to manage > +# all scanners that SANE can detect, including remote scanners. > +# > +# If this is disabled then colord will only detect locally connected > +# scanners. > > Another possibility for a "lightweight" workaround would be to set > UseSANE to false in the default configuration file, which would result > in colour correction for screens and printers but not scanners. > > I haven't had any response to the upstream libsane bug I opened querying > some code used by colord-sane that uses threads but does not look > thread-safe > (<https://alioth.debian.org/tracker/index.php?func=detail&aid=313921&group_id=30186&atid=410366>). > > Adding a call to dbus_threads_init_default() early in colord-sane's > main() can't hurt, either. I can't really add anything constructive to that. I don't even know how much this affects scanning (if at all). All I know is that colord is pulled in because some printing-related packages recommend it (interestingly, there is no dependency from xsane or sane-utils). >> I'd categorize a process that segfaults at boot with a severity >> of at least "important" > > I would say that depends what that process does, and what effect the > crash has. If a process crashes in the forest where nobody can hear it, > did it make a sound? :-) But is it really not heard by anyone? Definitely not by me (see above), beyond the syslog message. Strictly speaking, though, the package professes to provide a certain service, so if that services crashes at boot with no method of recovery, I'd say that fits the severity requirement of "a bug which has a major effect on the usability of a package". But that's splitting hairs. As I said, I'll try to test 0.1.31 over the weekend, and I'm willing to test any other proposed fixes. Thanks, Christian -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
