media-gfx/sane-backends-1.0.19-r1 causes scanner on Epson cx4100 to report as "in use" by usbfs. Personally solved by masking this package, and rolling back to version 1.0.18-r6 which previously worked for me. I actually tried to solve this by rebuilding my entire system and world against a sanitised current GCC and kernel, but that didn't work. I did a genlop -t sane-backends and noticed that I updated from 1.0.18 to 1.0.19 at the time the problem occurred, so I rolled back and the problem was solved. Reproducible: Always 1.0.19 appears to have been unmasked too early. Please re-mask this and we can all go back to 1.0.18-r6 and stop banging our heads together. At least my office didn't need additional heating while I rebuilt my entire gentoo world.
(In reply to comment #0) > media-gfx/sane-backends-1.0.19-r1 causes scanner on Epson cx4100 to report as > "in use" by usbfs. Personally solved by masking this package, and rolling back > to version 1.0.18-r6 which previously worked for me. [...] > 1.0.19 appears to have been unmasked too early. Please re-mask this and we can > all go back to 1.0.18-r6 and stop banging our heads together. Who is "we all"? 1.0.19 was unmasked after four months in ~arch did not show any problems. It includes quite a lot of bugfixes and includes several new backends. Sorry, but currently I don't see any "banging our heads together" and masking this version would worsen the situation for far more people than those who are affected by the newly introduced bugs. I have reason to assume that there are people out there who use other kinds of scanner than you and who also would like to have a working device, sorry. > At least my office didn't need additional heating while I rebuilt my entire > gentoo world. I am sorry to hear that you had so much unnecessary work, but I don't see how this is related to the question which sane-backends version should be considered the most useful right now.
(In reply to comment #1) > (In reply to comment #0) > > media-gfx/sane-backends-1.0.19-r1 causes scanner on Epson cx4100 to report as > > "in use" by usbfs. Personally solved by masking this package, and rolling back > > to version 1.0.18-r6 which previously worked for me. > [...] > > 1.0.19 appears to have been unmasked too early. Please re-mask this and we can > > all go back to 1.0.18-r6 and stop banging our heads together. > > Who is "we all"? This is not isolated. Users of the epson cx4100, cx4200, cx3700 et al are reporting "in use" problems with the backend they need in this revision. "We all". > and masking this version would worsen the situation for far more people than those who are affected by the newly introduced bugs. I understand, I didn't realise Ioverstated the case. It appears to only be with this backend - not the whole release. What I don't understand is why this revision was unmasked when the backend for these devices is causing problems that render the device unusable. > I have reason to assume that there are people out there who use other kinds of > scanner than you and who also would like to have a working device, sorry. I understand. Can't just the relevent backend be rolled back? What can be done?
(In reply to comment #2) [...] > What I don't understand is why this revision was unmasked when the backend for > these devices is causing problems that render the device unusable. Because it was marked for testing for several months and nobody who used ~arch noticed the problem. And, AFAIR, there are unusable/hardly usable backends in .18 which work in .19. Looks like you can't make everybody happy. > I understand. Can't just the relevent backend be rolled back? What can be done? Last time I checked the bugtracker of the SANE project I did not find anything that looked like this problem. Perhaps they are not aware of it? Would you like to report it there? If no, perhaps I should next week.
Update: Maybe no need to report this, I just checked sane-cvs and found a few changes that might fix the problem. Not sure, though. Please try -r2 when it hits the mirrors.
(In reply to comment #4) > Update: Maybe no need to report this, I just checked sane-cvs and found a few > changes that might fix the problem. Not sure, though. Please try -r2 when it > hits the mirrors. Galen? Could you try it?
(In reply to comment #5) > (In reply to comment #4) > > Update: Maybe no need to report this, I just checked sane-cvs and found a few > > changes that might fix the problem. Not sure, though. Please try -r2 when it > > hits the mirrors. > > Galen? Could you try it? > I unmasked the r2 today and found that it does indeed solve the problem. Many thanks for your suggestion. This has been an interesting experience for a number of reasons. Just for my own interest, why has this happened? An unmasked package that disables a previously-working driver, and then a masked package that again operates. Feel free to mark this as fixed if one can do so for a still-masked package (r2), although the problem still exists for the revision in question (r1) and has not been fixed in that revision. I would do it myself,but I am unsure of protocol.
(In reply to comment #6) [...] > I unmasked the r2 today and found that it does indeed solve the problem. Fine. > Many thanks for your suggestion. This has been an interesting experience for a > number of reasons. > > Just for my own interest, why has this happened? An unmasked package that > disables a previously-working driver, and then a masked package that again > operates. .19 has been in ~arch for testing since the beginning of February. Nobody reported your problem until July. After a few minor other problems which were fixed in April, I waited until June (no significant problems were reported in this time) until I requested to put this from ~arch to arch. This is when you noticed the problem. It simply looks like no user who uses ~arch sane-backends needs the epson2 backend. If someone does, he did not report the problem. So why is -r2 still in ~arch? See http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1#doc_chap4_sect4 for why. > Feel free to mark this as fixed if one can do so for a still-masked package > (r2), although the problem still exists for the revision in question (r1) and > has not been fixed in that revision. [...] I prefer to do a revision bump for almost everything but compilation fixes if the binaries differ from the previous version.
(In reply to comment #7) > (In reply to comment #6) > > > > Just for my own interest, why has this happened? An unmasked package that > > disables a previously-working driver, and then a masked package that again > > operates. > .19 has been in ~arch for testing since the beginning of February. Nobody > reported your problem until July. After a few minor other problems which were > fixed in April, I waited until June (no significant problems were reported in > this time) until I requested to put this from ~arch to arch. This is when you > noticed the problem. It simply looks like no user who uses ~arch sane-backends > needs the epson2 backend. If someone does, he did not report the problem. Thanks for your reply, but I really guess I was asking why there were all these changes in the first place? In short, why would something that works in the .16 be altered so that it became broken in the .19-r1 (somehow without the patcher realising it), and then why would someone fix that problem for the .19-r2 when, as you pointed out, nobody seemingly knew it was broken?
(In reply to comment #8) [...] > Thanks for your reply, but I really guess I was asking why there were all these > changes in the first place? I am not sure which detail level you expect from my answer. I offer a few options: - low detail: Because some sane developer worked on the driver and these changes were included in the 1.0.19 release. - medium detail: Some developer wanted to improve the driver and introduced new problems without noticing them on the hardware he had for testing. - high detail: You can see the complete source and history for the epson2.c file on https://alioth.debian.org/plugins/scmcvs/cvsweb.php/sane-backends/backend/epson2.c?cvsroot=sane > In short, why would something that works in the .16 be altered so that it > became broken in the .19-r1 (somehow without the patcher realising it), See above. And I guess you mean .18, not .16? > and then why would someone fix that problem for the .19-r2 when, as you pointed > out, nobody seemingly knew it was broken? A sane developer named Alessandro Zummo knew of the problem (no idea if he noticed by himself or if someone told him) and committed a fix to sane-CVS in April. After you reported this problem for Gentoo I checked the CVS logs and found his change which seemed related to your problem (though his description "fixed attach() error path." does not immediately ring a bell with me). I created a patch for this fix, applied it to sane-backends 1.0.19 and called the result "sane-backends-1.0.19-r2". Maybe it is a misunderstanding on my side, but I have the impression that you do not sufficiently distinguish between releases upstream (the SANE project) which releases new versions quite infrequently and the Gentoo revisions of an ebuild for a package (which can include patches for certain problems, like yours). Does this answer your questions or did I miss the point?
(In reply to comment #9) > (In reply to comment #8) > [...] > > Thanks for your reply, but I really guess I was asking why there were all these > > changes in the first place? > > I am not sure which detail level you expect from my answer. > I offer a few options: > - low detail: Because some sane developer worked on the driver and these > changes were included in the 1.0.19 release. > - medium detail: Some developer wanted to improve the driver and introduced new > problems without noticing them on the hardware he had for testing. This is the part that gets me. Some "improvements" that make the driver entirely non-functional, and this not being noticed seems a bit odd. > - high detail: You can see the complete source and history for the epson2.c > file on > https://alioth.debian.org/plugins/scmcvs/cvsweb.php/sane-backends/backend/epson2.c?cvsroot=sane Thanks > See above. And I guess you mean .18, not .16? yes > After you reported this problem for Gentoo I checked the CVS logs and found his > change which seemed related to your problem (though his description "fixed > attach() error path." does not immediately ring a bell with me). I created a > patch for this fix, applied it to sane-backends 1.0.19 and called the result > "sane-backends-1.0.19-r2". And that was very much appreciated, as is this clarification. > Maybe it is a misunderstanding on my side, but I have the impression that you > do not sufficiently distinguish between releases upstream (the SANE project) > which releases new versions quite infrequently and the Gentoo revisions of an > ebuild for a package (which can include patches for certain problems, like > yours). No, I get all that. It's just odd, considering all the layers involved, that a fully non-functioning driver got so far and into an unmasked package. > Does this answer your questions or did I miss the point? > No, that's fine. I still don't really understand how the problem got so far, but I will chalk it up to experience. Many thanks.
