Hi, On Fri, Jun 05, 2009 at 07:17:15PM +0200, Martin Preuss wrote: > First you state that you didn't even look at the source,
Yes, when reporting bugs to Debian, I should not be required to check the source. For upstream this may be required (although I don't think this would be a good idea), but Debian bug reports are only reports, and they need not be solutions. > but still in the next sentence you make assumptions about how the > software works/doesn't work. And last but not least you call the > software buggy... I see a bug in its behaviour, indeed. Note that I was talking about the package, not only the upstream software. > What are you trying to achieve by such a mail?? Take it easy! The hint about the probable implementation was intended to help, so that it would be easier to fix the problem. > As a matter of fact the daemon *does* have a main loop which uses > select() and which *can* be interrupted after a few seconds to scan > for new devices or the disconnection of existing devices. If setup > correctly the daemon even only looks for new devices upon receiption > of a signal (which can be generated by udev). So you are saying that my assumption that the select loop did not have an infinite timeout (in the Debian setup) was in fact correct. I don't see a problem with pointing in the right direction in a bug report... > So next time you are having issues with upstream you might want to > consider just asking for an explanation first... I didn't report the issue upstream. I reported it to Debian. The Debian maintainer, who does know the source, can then see if the issue is real, and whether it's in the packaging or in upstream. If it's in the setup, as you say, then that means it's in the packaging. Upstream doesn't need to ever hear about it. Unless of course upstream is subscribed to receive Debian bug reports. This is a good idea, but please don't treat them the same way as upstream bug reports. For Debian bug reports, the reporter expects the package maintainer to make the report more useful before sending it upstream (if that should be done at all). In this case, for example, the maintainer didn't send the report upstream, because the problem was appearently solved in the development version (I'm running Lenny here). Note that my problem is not that I have a program which is useful for me which doesn't work exactly as expected. I have a program which I'm not using that needs my attention or else my system's performance will suffer. I consider this a severe problem. I don't really have a problem when (incorrect) dependencies result in some extra software being installed (although that should be fixed as well, of course). But I don't want to be forced to spend time on configuring packages that I don't actually care about. I'm not saying the software isn't useful; it looks good as far as I can see. But I'm not using it, and I don't want to be bothered with configuring things I'm not using. Anyway, thank you for your reply. Next time, I'll try to be more clear about what I mean. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://a82-93-13-222.adsl.xs4all.nl/e-mail.html
signature.asc
Description: Digital signature
