Summary: | ~sys-fs/udev-171: mistake a mouse for a joystick | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | nobody <noreply> |
Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
nobody
2011-12-29 21:58:23 UTC
Do you have this problem with >=sys-fs/udev-197-r2? If you do, reopen the bug. Thanks! I won't go past 171 udev version, that is still in tree. So i cannot test with 197-r2 I suppose this one will never get fix. (In reply to comment #2) > I won't go past 171 udev version, that is still in tree. > So i cannot test with 197-r2 Bug 452556 -> The problems that blocked stabilization have been solved. Separate /usr is still supported. If you use uclibc, you can use 197-r3 and uclibc head and it is supported too. There is no reason to stick to 171 or switching to eudev other than a lot of FUD and the only thing they provide: Support for older kernels than 2.6.39. If you use higher kernel, nothing is stopping you from upgrading for test. > > I suppose this one will never get fix. You are right if you are sticking with 171 which will be removed after bug 452556 has been done. We don't have your hardware and setup to test the new version. If you don't plan on still testing it after reading this comment, you can change the status as RESOLVED, CANTFIX (or I'll do it after, depending on your reply here) It's ok don't worry, but i prefer stick to udev-171 and live with that bug. And your solve isn't one anyway, just another test to see if upstream has fix that. (In reply to comment #4) > It's ok don't worry, but i prefer stick to udev-171 and live with that bug. > > And your solve isn't one anyway, just another test to see if upstream has > fix that. To track the changes between 171 and 197 regarding the code involved with your problem would be a task requiring hours for someone not knowing the code inside out. So it's not unreasonable to ask an user to test the current at all, heck, if you had filed this to upstream bugtracking system, they would have asked you the same! 197-r3 is stable now on amd64, and soon as rest of the arch's are done, 171 will be gone. (In reply to comment #5) > To track the changes between 171 and 197 regarding the code involved with > your problem would be a task requiring hours for someone not knowing the > code inside out. So it's not unreasonable to ask an user to test the current > at all, heck, if you had filed this to upstream bugtracking system, they > would have asked you the same! I never said it was unreasonable, just that for me, it's not an option. And i know upstream would have force me to upgrade, but i didn't report this one upstream, but within my distro, as this version is still support by it. You can at least grant me that by the time when i report this one, this was the case, even you are showing me it won't go long, and i was sure upstream have already drop support for that version. Mr Suominen, you seems to make a mountain out of nothing, for a bug that i could easy workaround, and that i have agree & set cantfix myself, and already state you don't have to worry about it. If by my french->english translate, i have upset you in some way, i'm sorry. It wasn't done for that. It was just a bug report for a minor annoyance. If i upgrade udev, i will report its status (still bug or fix) with that newer version. (In reply to comment #6) > one upstream, but within my distro, as this version is still support by it. Sorry, but it's not supported anymore. > If i upgrade udev, i will report its status (still bug or fix) with that > newer version. Thanks! |