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
| From: o1bigtenor via talk <talk@gtalug.org> | 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): <https://itsfoss.com/bug-report-debian/> Here's official documentation: <https://www.debian.org/Bugs/Reporting> | 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.
| From: D. Hugh Redelmeier via talk <talk@gtalug.org> | 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.
On Wed, Feb 17, 2021 at 2:17 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: D. Hugh Redelmeier via talk <talk@gtalug.org>
| 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
On Wed, Feb 17, 2021 at 3:09 PM o1bigtenor via talk <talk@gtalug.org> wrote:
On Wed, Feb 17, 2021 at 2:17 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: D. Hugh Redelmeier via talk <talk@gtalug.org>
| 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
Dhaval On Wed, Feb 17, 2021 at 5:14 PM Dhaval Giani <dhaval.giani@gmail.com> wrote:
On Wed, Feb 17, 2021 at 3:09 PM o1bigtenor via talk <talk@gtalug.org> wrote:
On Wed, Feb 17, 2021 at 2:17 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: D. Hugh Redelmeier via talk <talk@gtalug.org>
| 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
On Wed, Feb 17, 2021 at 6:35 PM o1bigtenor <o1bigtenor@gmail.com> wrote:
Dhaval On Wed, Feb 17, 2021 at 5:14 PM Dhaval Giani <dhaval.giani@gmail.com> wrote:
On Wed, Feb 17, 2021 at 3:09 PM o1bigtenor via talk <talk@gtalug.org> wrote:
On Wed, Feb 17, 2021 at 2:17 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: D. Hugh Redelmeier via talk <talk@gtalug.org>
| 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
On Wed, Feb 17, 2021 at 12:53 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: o1bigtenor via talk <talk@gtalug.org>
| 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):
<https://itsfoss.com/bug-report-debian/>
Here's official documentation:
Hmmmmmmm - - - 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.
Hmmmmmm - - - - that really isn't good news. Oh well sounds like same old same old! Thanks for the ideas and suggestions! Regards
On Wed, Feb 17, 2021 at 3:04 PM o1bigtenor via talk <talk@gtalug.org> wrote:
On Wed, Feb 17, 2021 at 12:53 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: o1bigtenor via talk <talk@gtalug.org>
| 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):
<https://itsfoss.com/bug-report-debian/>
Here's official documentation:
Hmmmmmmm - - - 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
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
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 znoteer@mailbox.org
On Wed, Feb 17, 2021 at 7:28 PM Lennart Sorensen via talk <talk@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
On Wed, Feb 17, 2021 at 6:52 PM o1bigtenor via talk <talk@gtalug.org> wrote:
On Wed, Feb 17, 2021 at 7:28 PM Lennart Sorensen via talk <talk@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.
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
Several others have responded. I've tried to not overlap. | From: o1bigtenor via talk <talk@gtalug.org> | On Wed, Feb 17, 2021 at 12:53 PM D. Hugh Redelmeier via talk | <talk@gtalug.org> wrote: | The kernel report has things at 5.4.99 already. What does that mean? Generally speaking, you can have many versions of the kernel installed and at boot time choose which to boot. Simple heuristic: boot the latest one that works. Bonus: you can "bisect" your problem. That means: test a sequence of kernels to find out when the problem showed up. As the word "bisect" suggests, if the sequence is long, you can simply do a binary search in that sequence so that instead on expecting to do N/2 test boots, you can find the point using about log-base-2(N) boots. debian probably has a repo with a large sequence of kernels, many of which you have never tried. Bisecting in this set would narrow the focus even further. You can do an even finer job by bisecting on the kernel.org git tree. git even has a "bisect" command to help. You should then be able to tell exactly which kernel patch introduced your problem. The above assumes - the bug is a single one - the bug is in the kernel - the bug came from upstream In your investigation, you might discover that one or more of these assumptions is wrong. Does this sound like a lot of work? Maybe. Who is best to do this: you. After all, you have the system that manifests the problem. But there is a shortcut you should try first: has someone else hit this already? If so, have they solved it? (Very often it is hard to tell if two sets of symptoms are manifestations of the bug.) | > 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. | | Hmmmmmm - - - - that really isn't good news. | | Oh well sounds like same old same old! To get help, you really have to answer questions. You didn't. What do you mean by "same old same old" here? I do know what the phrase normally means. | From: o1bigtenor via talk <talk@gtalug.org> | 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. I am using "google" as a generic verb. I use Duckduckgo. I'm not confident that it will save me. | 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. I'm a programmer. I find multiple monitors no longer very useful I just use UltraHD monitors and they fill my field of view. On my latest toy, I can drive three UltraHD monitors. But I don't. I do have three UltraHD monitors around me, visible from my chair (but I have to rotate). Ergonomics are very personal. But that doesn't mean that each of us knows what's best for our self. I often report to this list what works for me. | what used to be called the power user - - - - in (and on) LInux is considered | not worth wasting time on - - - so finding expertise - - - - - | incredibly difficult. I don't think that this is true. | From: o1bigtenor via talk <talk@gtalug.org> | There are a lot of these 'official' volunteers that are working day jobs that | strangely are very very like their volunteer interests. This sounds like a veiled accusation. Please spell it out or withdraw it. | 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. 1. you need to improve your problem reports 2. you need realistic expectations. 3. useful information may not be organized the way you understand the problem Of course open source helps: it lets anybody solve a problem. | 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. I don't like the word coder, at least when applied to me. I'm a programmer. (Other's liked the term "Systems Analyst", but I don't.) When I started out, we didn't even have screens. | 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 . . . . .) If you had an idea, I assume that you'd have solved the problem. "Have you checked if the computer is plugged in?" When helping someone, you really need to double-check all the basics. | From: o1bigtenor via talk <talk@gtalug.org> | On Wed, Feb 17, 2021 at 5:14 PM Dhaval Giani <dhaval.giani@gmail.com> wrote: | > 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. debian project is very welcoming of help. Little pockets might have pathologies -- I don't know. But I doubt that's what you've hit. It is easy to jump in and alienate a group. Your postings here have done just that. You should have noticed this. Don't do that if you expect help or sympathy. It's not constructive. It is possible to recover. | From: o1bigtenor via talk <talk@gtalug.org> | 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. I understand that. That policy is unworkable with modern software and hardware. If you are adamant, you must go back to perhaps the 8-bit era. - all modern processors have secret software running all the time that is invisible to the owner. For example, it was discovered a few years ago that every Intel x86 processor has a Minix system embedded inside running on a supervisory processor that is not in the architecture. - all modern OSes are too big to comprehend, even if you have the source. - all modern software has more contributors than you can vet. - all modern hardware surely has bugs that allow security violations. Every year a bunch are reported -- how many are unreported? We are standing on the shoulders of giants (and a lot of ordinary folks). If we don't trust them, we need to go out naked into the wild. A simple trust / don't trust model won't work. | - - - 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. Computers are good at automating tasks. Surely you could automate "setting up the things the way you want them". | 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. Learn to work constructively with the debian community. It's a marvel. I say that as (mostly) an outsider.
On Wed, Feb 17, 2021 at 5:13 PM Dhaval Giani <dhaval.giani@gmail.com> wrote:
On Wed, Feb 17, 2021 at 3:04 PM o1bigtenor via talk <talk@gtalug.org> wrote:
On Wed, Feb 17, 2021 at 12:53 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: o1bigtenor via talk <talk@gtalug.org>
| 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 a y 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
On Wed, Feb 17, 2021 at 6:34 PM o1bigtenor <o1bigtenor@gmail.com> wrote:
On Wed, Feb 17, 2021 at 5:13 PM Dhaval Giani <dhaval.giani@gmail.com> wrote:
On Wed, Feb 17, 2021 at 3:04 PM o1bigtenor via talk <talk@gtalug.org> wrote:
On Wed, Feb 17, 2021 at 12:53 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
| From: o1bigtenor via talk <talk@gtalug.org>
| 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 a y 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
participants (5)
-
D. Hugh Redelmeier -
Dhaval Giani -
lsorense＠csclub.uwaterloo.ca -
o1bigtenor -
Znoteer