Re: [GTALUG] question re: bug filing

[Dhaval Giani via talk]

On Wed, Feb 17, 2021 at 6:52 PM o1bigtenor via talk  wrote:
>
> On Wed, Feb 17, 2021 at 7:28 PM Lennart Sorensen via talk
>  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.
>

Try harder.  Hugh suggested https://www.debian.org/Bugs/Reporting .
Opening that page,

How to report a bug in Debian using email (and advanced usage of reportbug)

followed by

Sending the bug report via e-mail

Nowhere does it say you can only use reportbug. Yes, they prefer bugs
reported through that, but you can always email bugs.

> 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.

Just to remind you here, this is free software. The source code is
available to you to satisfy your paranoia.

> 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.
>

Engage the debian community, and describe your problem. Let them
figure out where the issue is. Respect the person at the other end and
remember, they are doing you a favour. And that you are not entitled
to that support. If you take this attitude there, I am very sure you
will just get ignored. If that is not possible, pay someone to fix it
for you. Of course, there is the other option of using some other
software (proprietary because it would meet your requirements better,
and you have paid for support). No one is forcing you to use Debian
(or free software for that matter).

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[Dhaval Giani via talk]

On Wed, Feb 17, 2021 at 6:35 PM o1bigtenor  wrote:
>
> > Dhaval
> On Wed, Feb 17, 2021 at 5:14 PM Dhaval Giani  wrote:
> >
> > On Wed, Feb 17, 2021 at 3:09 PM o1bigtenor via talk  wrote:
> > >
> > > On Wed, Feb 17, 2021 at 2:17 PM D. Hugh Redelmeier via talk
> > >  wrote:
> > > >
> > > > | From: D. Hugh Redelmeier via talk 
> > > >
> > > > | Each distro has its own way of reporting bugs
> > > >
> > > > I forgot to mention: google a lot first.  There may be others with the
> > > > same problem and perhaps even a solution.
> > >
> > > 1. You're still using google for a search engine - - - - - wow - - - - can
> > > I introduce you to Duckduckgo? So far, at least, they're not not 
> > > harvesting
> > > your data and all your searches.
> > > 2. A multi-gpu and multi-monitor system on LInux is considered very 
> > > extreme
> > > fringe. Almost all the upper level coders seem to find that more than one
> > > gpu is no fun so they run maybe 2 monitors. Its not the same thing when 
> > > you
> > > get to multi-gpu AND multi-monitor. Those with serious technical expertise
> > > just don't seem to run this kind of stuff.
> > >
> > > The gamers, well they're into monitor latency and not into screen real 
> > > estate,
> > > what used to be called the power user - - - - in (and on) LInux is 
> > > considered
> > > not worth wasting time on - - - so finding expertise - - - - -
> > > incredibly difficult.
> > >
> >
> > If it is worth your time, maybe you can develop the expertise. We
> > welcome you to contribute to the community.
> >
> Haven't found any interest - - - - in fact mostly the opposite.
>

No you misunderstand. Clearly you, o1bigternor, have the interest. So
go develop the skill and write code for the bugs/issues you are
hitting. You know almost every open source contribution starts with
scratching your own itch. And if you don't want to do that, pay
someone enough money so they take care of your itch.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[Dhaval Giani via talk]

On Wed, Feb 17, 2021 at 6:34 PM o1bigtenor  wrote:
>
> On Wed, Feb 17, 2021 at 5:13 PM Dhaval Giani  wrote:
> >
> > On Wed, Feb 17, 2021 at 3:04 PM o1bigtenor via talk  wrote:
> > >
> > > On Wed, Feb 17, 2021 at 12:53 PM D. Hugh Redelmeier via talk
> > >  wrote:
> > > >
> > > > | From: o1bigtenor via talk 
> > > >
> > > > | Kernel 5.4.0-4 was the last kernel where I didn't find my second
> > > > | graphics card not able to move out of sleep.
> > > >
> > > > Each distro has its own way of reporting bugs.  Here's an unofficial
> > > > description of the debian process (untested by me -- I don't use
> > > > debian):
>
> > 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.
> >
> There are a lot of these 'official' volunteers that are working day jobs that
> strangely are very very like their volunteer interests.
>

That still doesn't explain why you feel entitled to free support.
Someone is paying them to do specific things in the distro. The fact
that the interests align is just a happy coincidence. I am sure if you
were to provide enough incentive, someone's interests will align with
yours.

> When I was beating my head against the wall for over 2 months when I
> first set up this system the amount of information available or offered to
> me was close enough to zero so as to make it a moot point for open source
> support.
> In the years since I've found that most coder types really don't get into
> screen real estate - - - - in fact some serious programmers were still using
> 19" monitors (within the last year) where I had moved to a 1600x1200 crt
> some 20 years ago.
> Horses for courses except I've far too often found my screen real estate
> far too confining when I'm working on something complicated. All of what
> I've found only reinforces the point that what I'm doing is w   ay
> out there!
>

If you are the one user, why do you expect a project to spend
thousands of hours ensuring something is not broken for you?
Especially since you claim, it is very different from what "most coder
types" use/do. Again, all I am hearing is entitlement, and honestly if
I were the maintainer of that project, I would point out that no one
is forcing you to use my project, and no one is stopping you from  (or
paying someone to) contributing code to the project to take care of
your use case. If there is something out there that is better, use it.

> > 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?
> >
> Interesting - - - - the one thing that you don't mention and that I think
> might be the case here is that the actual bug may be a specific confluence
> of things. So even with a complete listing of all of what you have - - - - the
> actual problem still isn't visible. I spent a few hours reading through files
> in /var/log/  and haven't been able to find anything. Which is why I was
> asking for assistance in where to ask. (The assumption seems to be
> that I don't have any idea - - - - and maybe I don't . . . .   .)
>

No. The assumption here is you are expecting free support on your
terms. We have pointed out multiple ways, pointed out the falsehoods
in your statements. Again, all the steps I listed in my earlier note
are what just about any maintainer is going to ask you to do before
even thinking about your problem. Once we know you are on the latest,
and the issue you have is not fixed, then we try fixing it. Because
let's be real, if it is already fixed, why should I fix it again?
Again, you are NOT going to get support on your terms. If you want it
that way, pay someone and then you get that right (and maybe even then
not).

Dhaval

> Regards
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[o1bigtenor via talk]

On Wed, Feb 17, 2021 at 7:28 PM Lennart Sorensen via talk
 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
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[o1bigtenor via talk]

> Dhaval
On Wed, Feb 17, 2021 at 5:14 PM Dhaval Giani  wrote:
>
> On Wed, Feb 17, 2021 at 3:09 PM o1bigtenor via talk  wrote:
> >
> > On Wed, Feb 17, 2021 at 2:17 PM D. Hugh Redelmeier via talk
> >  wrote:
> > >
> > > | From: D. Hugh Redelmeier via talk 
> > >
> > > | Each distro has its own way of reporting bugs
> > >
> > > I forgot to mention: google a lot first.  There may be others with the
> > > same problem and perhaps even a solution.
> >
> > 1. You're still using google for a search engine - - - - - wow - - - - can
> > I introduce you to Duckduckgo? So far, at least, they're not not harvesting
> > your data and all your searches.
> > 2. A multi-gpu and multi-monitor system on LInux is considered very extreme
> > fringe. Almost all the upper level coders seem to find that more than one
> > gpu is no fun so they run maybe 2 monitors. Its not the same thing when you
> > get to multi-gpu AND multi-monitor. Those with serious technical expertise
> > just don't seem to run this kind of stuff.
> >
> > The gamers, well they're into monitor latency and not into screen real 
> > estate,
> > what used to be called the power user - - - - in (and on) LInux is 
> > considered
> > not worth wasting time on - - - so finding expertise - - - - -
> > incredibly difficult.
> >
>
> If it is worth your time, maybe you can develop the expertise. We
> welcome you to contribute to the community.
>
Haven't found any interest - - - - in fact mostly the opposite.

Regards
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[o1bigtenor via talk]

On Wed, Feb 17, 2021 at 5:13 PM Dhaval Giani  wrote:
>
> On Wed, Feb 17, 2021 at 3:04 PM o1bigtenor via talk  wrote:
> >
> > On Wed, Feb 17, 2021 at 12:53 PM D. Hugh Redelmeier via talk
> >  wrote:
> > >
> > > | From: o1bigtenor via talk 
> > >
> > > | Kernel 5.4.0-4 was the last kernel where I didn't find my second
> > > | graphics card not able to move out of sleep.
> > >
> > > Each distro has its own way of reporting bugs.  Here's an unofficial
> > > description of the debian process (untested by me -- I don't use
> > > debian):

> 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.
>
There are a lot of these 'official' volunteers that are working day jobs that
strangely are very very like their volunteer interests.

When I was beating my head against the wall for over 2 months when I
first set up this system the amount of information available or offered to
me was close enough to zero so as to make it a moot point for open source
support.
In the years since I've found that most coder types really don't get into
screen real estate - - - - in fact some serious programmers were still using
19" monitors (within the last year) where I had moved to a 1600x1200 crt
some 20 years ago.
Horses for courses except I've far too often found my screen real estate
far too confining when I'm working on something complicated. All of what
I've found only reinforces the point that what I'm doing is w   ay
out there!

> 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?
>
Interesting - - - - the one thing that you don't mention and that I think
might be the case here is that the actual bug may be a specific confluence
of things. So even with a complete listing of all of what you have - - - - the
actual problem still isn't visible. I spent a few hours reading through files
in /var/log/  and haven't been able to find anything. Which is why I was
asking for assistance in where to ask. (The assumption seems to be
that I don't have any idea - - - - and maybe I don't . . . .   .)

Regards
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[Znoteer via talk]

On Wed, Feb 17, 2021 at 08:28:48PM -0500, Lennart Sorensen via talk 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.
> 

There is also a package, reportbug I think it is appropriately named, that
will greatly simplify the process of filing a bug in debian.

-- 
Znoteer
znot...@mailbox.org
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[Lennart Sorensen via talk]

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.

-- 
Len Sorensen
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[Dhaval Giani via talk]

On Wed, Feb 17, 2021 at 3:09 PM o1bigtenor via talk  wrote:
>
> On Wed, Feb 17, 2021 at 2:17 PM D. Hugh Redelmeier via talk
>  wrote:
> >
> > | From: D. Hugh Redelmeier via talk 
> >
> > | Each distro has its own way of reporting bugs
> >
> > I forgot to mention: google a lot first.  There may be others with the
> > same problem and perhaps even a solution.
>
> 1. You're still using google for a search engine - - - - - wow - - - - can
> I introduce you to Duckduckgo? So far, at least, they're not not harvesting
> your data and all your searches.
> 2. A multi-gpu and multi-monitor system on LInux is considered very extreme
> fringe. Almost all the upper level coders seem to find that more than one
> gpu is no fun so they run maybe 2 monitors. Its not the same thing when you
> get to multi-gpu AND multi-monitor. Those with serious technical expertise
> just don't seem to run this kind of stuff.
>
> The gamers, well they're into monitor latency and not into screen real estate,
> what used to be called the power user - - - - in (and on) LInux is considered
> not worth wasting time on - - - so finding expertise - - - - -
> incredibly difficult.
>

If it is worth your time, maybe you can develop the expertise. We
welcome you to contribute to the community.

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[Dhaval Giani via talk]

On Wed, Feb 17, 2021 at 3:04 PM o1bigtenor via talk  wrote:
>
> On Wed, Feb 17, 2021 at 12:53 PM D. Hugh Redelmeier via talk
>  wrote:
> >
> > | From: o1bigtenor via talk 
> >
> > | Kernel 5.4.0-4 was the last kernel where I didn't find my second
> > | graphics card not able to move out of sleep.
> >
> > Each distro has its own way of reporting bugs.  Here's an unofficial
> > description of the debian process (untested by me -- I don't use
> > debian):
> >
> >   
> >
> > Here's official documentation:
> >
> >   
>
> Hmmm - - - interesting - - - - in this area Debian is sounding a lot
> like M$ - - - - "please setup this system so that we can monitor your system
>  or . . .   ." and there seems to be no other way to report bugs .
> As I don't do that for anyone  - - - - - sounds like I am going to not be on
> debian for much longer. (I'm easy - - - - you work with me - - - or
> I'm history.)

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?

Dhaval
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[o1bigtenor via talk]

On Wed, Feb 17, 2021 at 2:17 PM D. Hugh Redelmeier via talk
 wrote:
>
> | From: D. Hugh Redelmeier via talk 
>
> | Each distro has its own way of reporting bugs
>
> I forgot to mention: google a lot first.  There may be others with the
> same problem and perhaps even a solution.

1. You're still using google for a search engine - - - - - wow - - - - can
I introduce you to Duckduckgo? So far, at least, they're not not harvesting
your data and all your searches.
2. A multi-gpu and multi-monitor system on LInux is considered very extreme
fringe. Almost all the upper level coders seem to find that more than one
gpu is no fun so they run maybe 2 monitors. Its not the same thing when you
get to multi-gpu AND multi-monitor. Those with serious technical expertise
just don't seem to run this kind of stuff.

The gamers, well they're into monitor latency and not into screen real estate,
what used to be called the power user - - - - in (and on) LInux is considered
not worth wasting time on - - - so finding expertise - - - - -
incredibly difficult.

Thanks for the ideas.

Regards
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[o1bigtenor via talk]

On Wed, Feb 17, 2021 at 12:53 PM D. Hugh Redelmeier via talk
 wrote:
>
> | From: o1bigtenor via talk 
>
> | Kernel 5.4.0-4 was the last kernel where I didn't find my second
> | graphics card not able to move out of sleep.
>
> Each distro has its own way of reporting bugs.  Here's an unofficial
> description of the debian process (untested by me -- I don't use
> debian):
>
>   
>
> Here's official documentation:
>
>   

Hmmm - - - interesting - - - - in this area Debian is sounding a lot
like M$ - - - - "please setup this system so that we can monitor your system
 or . . .   ." and there seems to be no other way to report bugs .
As I don't do that for anyone  - - - - - sounds like I am going to not be on
debian for much longer. (I'm easy - - - - you work with me - - - or
I'm history.)
>
> | I did a system upgrade
> | (using apt) more than once and then one did a 'apt autoremove' where
> | the 5.4.0-4 was removed.
> | This behaviour of my second card not coming out of sleep has become
> | quite annoying - - it takes some 20 minutes to set most everything
> | back up to like it was before the forced reboot.
>
> Is the second card online at this point?
>
> I'd guess that you can re-install 5.4.0-4.

The kernel report has things at 5.4.99 already.

>
> | To me there is a confluence between the kernel, nvidia, nouveau, lxqt,
> | the browsers and likely JS (although the multitudinous nefarious
> | techniques used by various entities to try and control my computer
> | from this last section would likely be disavowed by any and all
> | involved).
>
> Are you using the proprietary nvidia driver?  If so, good luck getting
> support.  With my distro, bug reports are only dealt with if no
> proprietary drivers are loaded.  Ditto for upstream (the kernel
> bugzilla).
>
> Nouveau is not proprietary so it is OK.  But it is pathetic.

Hmm - - - - that really isn't good news.

Oh well sounds like same old same old!

Thanks for the ideas and suggestions!

Regards
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[D. Hugh Redelmeier via talk]

| From: D. Hugh Redelmeier via talk 

| Each distro has its own way of reporting bugs

I forgot to mention: google a lot first.  There may be others with the 
same problem and perhaps even a solution.
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

Re: [GTALUG] question re: bug filing

[D. Hugh Redelmeier via talk]

| From: o1bigtenor via talk 

| Kernel 5.4.0-4 was the last kernel where I didn't find my second
| graphics card not able to move out of sleep.

Each distro has its own way of reporting bugs.  Here's an unofficial
description of the debian process (untested by me -- I don't use
debian):

  

Here's official documentation:

  

| I did a system upgrade
| (using apt) more than once and then one did a 'apt autoremove' where
| the 5.4.0-4 was removed.
| This behaviour of my second card not coming out of sleep has become
| quite annoying - - it takes some 20 minutes to set most everything
| back up to like it was before the forced reboot.

Is the second card online at this point?

I'd guess that you can re-install 5.4.0-4.

| To me there is a confluence between the kernel, nvidia, nouveau, lxqt,
| the browsers and likely JS (although the multitudinous nefarious
| techniques used by various entities to try and control my computer
| from this last section would likely be disavowed by any and all
| involved).

Are you using the proprietary nvidia driver?  If so, good luck getting
support.  With my distro, bug reports are only dealt with if no
proprietary drivers are loaded.  Ditto for upstream (the kernel
bugzilla).

Nouveau is not proprietary so it is OK.  But it is pathetic.
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk

[GTALUG] question re: bug filing

[o1bigtenor via talk]

Greetings

I'm running a computer on Debian testing trying to stay somewhat
current for updates.

Setup using nouveau for my graphics running 2 graphics cards.
LXQT is my desktop 'environment' (if that's the right word??).
I'm also running Opera, Firefox LTS and Vivaldi for browsers.
Tend to have lots of windows and a plethora of tabs open.
Trying to always leave a window with the blank 'home' page to minimize
JS issues.
Running both uBlock and privacy badger trying to reduce my use
information harvesting.

Kernel 5.4.0-4 was the last kernel where I didn't find my second
graphics card not able to move out of sleep. I did a system upgrade
(using apt) more than once and then one did a 'apt autoremove' where
the 5.4.0-4 was removed.
This behaviour of my second card not coming out of sleep has become
quite annoying - - it takes some 20 minutes to set most everything
back up to like it was before the forced reboot.

So where do I complain (bug report)?

To me there is a confluence between the kernel, nvidia, nouveau, lxqt,
the browsers and likely JS (although the multitudinous nefarious
techniques used by various entities to try and control my computer
from this last section would likely be disavowed by any and all
involved).

IMO this is not the kind of behavior that should be allowed for and by
anything called stable (ie Debian is moving to a freeze looking toward
a release of a new version of 'stable').

Suggestions?

TIA
---
Post to this mailing list talk@gtalug.org
Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk