I have been wondering if questions that have the character of a bug report or lets say questions about locating, fixing or working around bugs of certain packages in certain environments are welcome to this site?

I recently posted one of those questions myself that can be found here and works as en example of what I mean.

  • 1
    Related: unix.meta.stackexchange.com/q/3565/117549
    – Jeff Schaller Mod
    Commented Aug 5, 2019 at 3:42
  • 1
    As with everything in life, it depends. I prefer Gilles take on the issue, since it requires the user to understand the problem they are facing, but not necessarily how to fix it.
    – Braiam
    Commented Aug 11, 2019 at 18:20
  • @Braiam yea, my question was a little bit like my system is not working properly, how can I fix it... this did not feel right for me, therefore I started this discussion and got plenty of aspects to take into account on these regards. Especially about posting more detailed information in the question.
    – nath
    Commented Aug 11, 2019 at 18:30

4 Answers 4


I don't see why not. Of course, this site shouldn't be used to actually report bugs. Those should be reported using whatever bug tracking system the relevant project uses, but asking for a workaround is fine.

In any case, it's often hard to know if what you're facing is a bug or a misconfigured system. Perhaps your issue with your user being logged out on suspend can be fixed by toggling a setting and isn't actually a bug.

So asking such questions seems fine to me.

  • " it's often hard to know if what you're facing is a bug or a misconfigured system" Exactly that, especially for casual users who have no idea about programming. Most of the time issues users have might be solved with simple config change, or can be explained with hardware limitations. Problem is when a user asks us to fix a bug (which not everyone can). Not a problem is when user asks us to troubleshoot or explain why behavior occurs. Even if behavior is a bug, we can post an answer saying so or if it's not reported - advise the user to report it Commented Aug 10, 2019 at 0:46

Off-topic: “When I do X, Y happens. It shouldn't. Fix it.” (Even if you happen to know that the maintainer hangs around here, this is not a bug tracker.)

Off-topic: “When I do X, Y happens. It shouldn't. How can I fix the offending program?” (This is not a programming site, and even on a programming site, this is only ok if the bug has been narrowed down to a small piece of code that is included in the question.)

Off-topic: “When I do X, Y happens. It shouldn't. Has this bug been reported yet?” (This is not a search engine. That being said, it can be hard to find where to report a bug, but chat is more appropriate if you need help there, because it isn't easily transferable to other people.)

On-topic: “When I do X, Y happens. This is surprising because I expected Z. Why does Y happen?” (And if Y turns out to be a bug, so be it.)

On-topic: “When I do X, Y happens. This is obviously a bug [e.g. because it's a crash]. Given …, how can I work around it to do Z?” (The question should of course make it obvious why “upgrade to a version with the fix” is not a valid answer.)

On-topic: “When I do X, Y happens. This is obviously a bug [e.g. because it's a crash], but I don't have enough information to make a bug report/avoid running into it. How can I find out …?” (Where answers might be thing like “look at /this/log/file” or “activate this trace mode”.)

On-topic, but do check official channels first: “What's the impact of bug B on a system where …?”

On-topic, but do check official channels first: “How does this security exploit work?” (While Stack Exchange isn't really the place for this, we've had a few great answers.)


I do not see why they would not.

First, it is hard to be sure you are facing a bug, reported or not, or another glitch involving something else (hardware, firmware, etc.). Not to mention that if it becomes clear that you are facing a bug, the community can advice and help you, to actually report the bug if it is not known, or to know that you are facing a reported one.

Second, when facing a reported bug, there are not always a solution being proposed by your distribution or, on the other side, too many "not-so-serious"/alleged solutions which could, in the worst case scenario, break your system. You can see the latter even in simple answers to simple questions on this website.

Finally, as far as I understand and I am concerned, this community is here to help users and promotes educational answers, which is, coincidentally, usually what happens where there are (serious) bugs reported to CVE website for example.

Long story short, asking such questions seems totally aligned with U&L StackExchange policy.

  • one concern I had with those questions is that they may become irrelevant over time... But maybe this is not to much of a point.
    – nath
    Commented Aug 5, 2019 at 18:05
  • 1
    Yes, it could. But, seeing how various Unixes and derivatives OS are out there (e.g. kernel versions, driver versions, bootloaders), it could be a slow decay. Furthermore, the security updates are usually not there yet or even never will be for some cases, e.g. Spectre/Meltdown. As a result, IMHO, it is not a waste of DB. ;)
    – Paradox
    Commented Aug 5, 2019 at 18:49

I think I agree with Gilles, but here is my reaction to the specific example:

Since some resent upgrades of my Debian testing/bullseye distribution, my user gets logged out while in sleep-mode (lid closed) [... name and version of desktop used, etc ...] Does anyone know how to fix this or which package is responsible for this behavior?

The version information is pretty good, thanks. You didn't give an exact package version apart from the kernel, but you're not sure which package triggered the problem anyway.

I read the question and left a comment, effectively suggesting to add certain additional information.

I think the described symptoms match a crash of gnome-shell (from sad experience). IMO there is a deficiency in this version of the question, in that it does not even show which program crashed, or that you have looked for crash information but found nothing. The problem is there could potentially be several different crashes with the same symptom during this development cycle.

Strictly speaking, I think this shows a flaw in the phrasing in this version of the question. You would legitimately like to know which package is responsible for the problem. I think the real question is how you can try to narrow down the problem, to find out more about the cause, and which package is responsible.

I think that's a useful way to understand StackExchange. I don't think it means your question is wrong. I think we should aim to engage with questions to try to reach a conclusion, not to nitpick them to death. IMO the question already shows some effort/thoughtfulness, and we're not currently in danger of being overwhelmed by such questions.

I don't think you're wrong to include the possibility that someone else already has a more detailed report, with the same symptoms as yours. On the other hand, if they saw your post then I expect they would make a comment anyway, even if you don't explicitly ask them to :-).

  • THX, really good points! this (and your comment) helps me a lot to improve the question, I'll work on it to make it a less broad question :-) Cheers
    – nath
    Commented Aug 6, 2019 at 12:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .