[GTALUG] question re: bug filing

o1bigtenor o1bigtenor at gmail.com
Wed Feb 17 21:51:20 EST 2021


On Wed, Feb 17, 2021 at 7:28 PM Lennart Sorensen via talk
<talk at gtalug.org> wrote:
>
> On Wed, Feb 17, 2021 at 03:12:49PM -0800, Dhaval Giani via talk wrote:
> > I also imagine you are paying the debian volunteers for their time to
> > help you with a bug you are hitting. You are joining a community, and
> > it would be great to respect the rules and processes that community
> > follows. Seriously, this is a volunteer effort people are involved in.
> >
> > FWIW, reportbug is *NOT* monitoring your system. It is just populating
> > your bug report with almost everything the maintainer would ask you up
> > first. Such as, are you on the latest package? Can you test with the
> > latest package? Has your bug already been reported? If so, can we add
> > to that report? Are you running the originally shipped package or
> > doing something custom?
>
> Yes the debian bug reporting is a script collecting info.  It can send it
> directly as an email, if email sending is configured on your system, or it
> can save it as a file you can send from an email client by yourself, and
> of course being a text file you can read what it in it before sending it.
>
Reading the 'official' Debian page on 'reportbug' really didn't even seem to
hint that sending anything in myself was possible. There were directions on
setting up this and that and the next thing and everything was supposed to
then 'just happen' (an automatic function). There was also no mention of
any limits in the 'sending'. Like does it function autonomously after the first
time, that seemed to be what was suggested - - - - but - - - - - it
really wasn't
clear.

Any tool that doesn't have clearly defined limits usually doesn't get installed
here. My trust factor in software isn't very high - - - - if it even
exists in all
honesty - - - that's called experience. In fact I have four systems - - - one
main computer and an older server - - - - don't use it much but bought it
looking forward. Then there is a test bed system for each of the first two.
There are still issues that happen because the test bed system for my main
machine isn't multi-gpu and multi-monitor so I 'have' been trying to set up
things to minimize my main system(s) being taken out because of software
but even this trialing system isn't detailed enough. Its starting to seem
like I need to have my trial system be more similar to its counterpart.
I just don't have the time to fight to get things working well after I do a
system upgrade and those issues are taking at least part of my system
down even 3 to 4 days. Kernel 5.0.5 was far worse there were times I
had to do a reboot every few hours - - - hard to get work done when you
need about 1/2 hour to set up things the way you want them and then
within a few hours you need to do it all over again.

So what do I do - - - - no clear path at this point yet except perhaps to
install kernel 5.4.99 (last time I looked at the kernel info) and then run that,
maybe I can keep that kernel and just update everything else - - - dunno.

Regards


More information about the talk mailing list