Bug#990451: [EXT]Re: Bug#990451: (no subject)
David Kalnischkies wrote on 3/13/24 2:28 AM: > What would this achieve; what is the use case? The use case is when a repo has too many versions of a software on it. I'd only be interested in seeing the details for the Installed and Candidate versions, so even my initial --versions suggestion is not good enough for that. > I literally see no point in having 'policy' limited to a single > version (and which one?) given its usually used to show which versions > are available from where, how the pin values are for those and which > one is considered the candidate as a result of that. Maybe just the candidate version? Who knows? Chances are someone would find it useful. > Uhm… beside that the --no-all-versions flag switches the display from > "display all versions" to "display the candidate version only" in e.g. > 'show' (and one or the other is the default in apt-cache vs. apt), so > the equivalent would be more like '1' … and '0' would display nothing? Precisely, for those of us looking for a little more zen in our lives. > How would --versions=3 behave through: Assuming I have 5 different > versions available in the sources, which of these are displayed and > which are not… regardless of the choice, this seems rather unintuitive > to discover without many paragraphs of documentation that basically > duplicates the code in prose text. Now is this 5 repos with 1 version each, or 2 repos with 2 versions plus 1 repo with 1 version, or 1 repo with 5 versions, or 3 repos with 1 version plus 1 repo with 2 versions, or 1 repo with 1 version plus 1 repo with 4 versions? Will --versions apply on a per-repo basis or globally? We could go down a list of priorities until the number of desired versions has been reached, that could include: Installed, Candidate, Candidate-1, Installed+1, Installed-1, Candidate-2, Installed+2, Installed-2, et cetera, et cetera > Again, what would this achieve and what is the use case for this? Likely the same or similar reasons --no-all-versions already exists, for one to limit the clutter and undesirable information on our screens, et cetera, et cetera. > Sidenote: If a specific task has no people interested in working on it, There're categories for such tasks such as "closed" or "wontfix" et cetera, et cetera, none of which apply to this request as of yet. > Either create a compelling new task referencing related ones Such was of course considered but this path was chosen in our infinite wisdom. We're sure you'd've complained either way, saying it's a duplicate and how kilobytes of bandwidth and storage were wasted, right? Et cetera, et cetera. > or much better yet do work on it yourself. Our time is quite limited and you're blessed to have received this much of it already. > Its open source after all and nothing will ever get done if everyone > hopes someone else will do it. It is? -squints- Our Gods! You're right, all this time wasted sharing our ideas for improvements when we could've just done it ourselves, silly us! Why are there even mailing lists? Decades of work, lost! The travesty! Just think where we could be by now, et cetera, et cetera... Fax mentis incendium gloriæ culpum et cetera, et cetera... Memor bis punitor delicatum! > Best regards You sure?
Bug#990451: (no subject)
I concur and also request `--no-all-versions` apply to `apt-cache policy` command as well. Perhaps, instead, a new option with argument `--versions=N` could be implemented, allowing a limited number of versions to be returned, with `--versions=0` or `--versions=none` being the equivalent of `--no-all-versions`.
Bug#1029594: Fails to authenticate mit o365
On Sun, 5 Feb 2023 23:36:38 +0100 Carsten Schoenert wrote: > I don't understand what you want from me. Well, I think it was clear in my messages but it seems you like to gloss over everything and reduce it all to nothing. For one you can stop stating things as if they are facts when you have no evidence to support them, that's a general rule for anything in life. > Did you use stable for your daily work as Debian is suggesting? I don't > think so. Would you be affected by this issue if you use stable? No! Fortunately I was never affected by it because, by the time apt was running, the bug was classified with a proper severity level that Nicola had set. Had you reduced the severity like you had been advocating for, then I and many others would have been affected by this issue. > Does your emails help preventing others? Also here I don't think so. I think countering incorrect information posted and voicing my support for certain severity levels is helpful. It was certainly more helpful than your message here which is just attacking me and reducing everything I wrote to nothing. I understand you don't like any disagreements, but that happens in life when we make incorrect statements and decisions. > you still do nothing more than complaining > how bad the situation is. Sorry you think there was nothing more than complaining, but that is due more to your attitude than the reality. Lighten up!
Bug#1029594: Fails to authenticate mit o365
Carsten Schoenert wrote on 2/5/23 3:39 AM: > If you need your laptop or your workstation for mission critical > things than Debian unstable/sid isn't the right choice. If you do so > then you will need some knowledge to handle situations like happen > now.I'm not. The broken package has been released to testing already. In an ideal world I would have two separate computers but not everyone has ideal situations. testing release is good for my situation and have now added notifications of important bugs for apt-listbugs config as well, so thank you for mentioning that. However, that's not the default for users. > Debian doesn't have any really resilient statistics as such > statistics bases on completely free choice. Debian doesn't collect > data from users without any confirmation. Then why are you making assumptions on who the majority of users are? Such assertions require evidence, such as statistics. > Most users of Thunderbird are not using M$ products or at least only > using a small set of features of Exchange or Outlook.com. Again, how do you know this? guts or feelings are not valid sources of statistics. >> Further, the actual bug in mozilla is #1814536 (OAuth2 authentication >> | 102.7.1. | Linux - fails) - still Open. This is an even broader >> than just o365 as Google uses OAuth2 as well, etc. That bug was >> reported here in Debian as grave under #1030112 but you closed it as >> a duplicate of this bug. That was perhaps mistaken. > No, it was not. > Having dozen of issues open that are about the same problem is really > not helpful to handle the issue. Okay then, as long as you are certain. > I don't really understand your problem. What is the problem here? I'm just voicing my support for keeping the severity at serious while you keep insisting it should merely be important. > Even right now the the broken package will not migrate to testing. Why do you think that? How do you determine such? Is your system configured correct? It is literally listed in testing on packages.debian.org and available to be upgraded from 102.6. > But it will > also trigger a remove of the version in testing. What do we win? Maybe less bug reports? You seem to like that ;) I'm sure we all do. > My GMail account is working with the current version in testing means > to me that Google doesn't has changed something on their side. > Obviously only MS has changed something. Okay then, that's good. Maybe the report on Mozilla is wrong then, I don't know, I am just putting out there what I've found. > So finally again as written in other answers: If you need to use > Thunderbird in a critical environment you shouldn't use unstable/sid and again as I've said and as you should know, I/we are not, Thunderbird 102.7.1 has already been released to testing. > as long you don't know how to handle the potential breakage of > packages. Debian is providing a stable release for productive use, if > you need newer version of software you can add the backport suite. Most of us should already know that. I too just want to help others not have to spend time fixing things that can be prevented with a good severity label. I have a system with stable, backports, testing, experimental, unstable, and snapshots repos working fine, for now... ;)
Bug#1029594: Fails to authenticate mit o365
On Wed, 1 Feb 2023 19:50:15 -0300 Carsten Schoenert wrote: > Am Wed, Feb 01, 2023 at 03:24:14PM + schrieb Nicola Chiapolini: > > Control: severity -1 serious > > Hi Carsten > > I am increasing the severity again. This bit me today. > > I rely on apt-listbugs to protect me from such problems and with the default settings "normal" is not sufficient to trigger listbugs. > > Yesterday, #1030112 triggered listbugs, so today I was happy to see that the problem is fixed and upgraded. So I try to help others... > > (Since the only reason I use Thunderbird in the first place is to access o365, this bug might even be considered grave ;-) > > I'm considering this issue is normaly just of severity important. Frankly, I'm glad it was increased to serious because otherwise listbugs wouldn't have let me stop it, then I have to spend more time figuring out why I suddenly can't retrieve my e-mail and tracking down a solution, downgrading packages, etc. There is only so much time in the day and so much coffee I can drink. ;-) We use O365 at the University and I have enough issues maintaining our Linux systems there. ;-) Last thing I need is problems with workstation to get in the way of my work. > Quoting https://www.debian.org/Bugs/Developer.en.html > important > a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone > And that's what this issue is about, most of the users can use > Thunderbird without problems. Do you have statistics for that? What is "most"? I'm pretty sure many Universities and other large organizations across the world are using Office however, if it's anything like our University, "most" of those users are using Windows version of Outlook or Outlook Online. Still, I could not be sure what "most" Thunderbird users are using. Further, the actual bug in mozilla is #1814536 (OAuth2 authentication | 102.7.1. | Linux - fails) - still Open. This is an even broader than just o365 as Google uses OAuth2 as well, etc. That bug was reported here in Debian as grave under #1030112 but you closed it as a duplicate of this bug. That was perhaps mistaken. > serious > is a severe violation of Debian policy (roughly, it violates a "must" or "required" directive), > or, in the package maintainer's or release manager's opinion, makes the package unsuitable for release. I don't have the time to currently review the 609 instances of "must" or "required" in the policy, but I believe this makes the package unsuitable for release. > grave > makes the package in question unusable or mostly so, or causes data loss, > or introduces a security hole allowing access to the accounts of users who use the package. I think #1030112 should be reopened and/or merged with this bug, with the title being updated to reflect broader issue with OAuth2. As the bug is much broader than is implied here, severity should be maintained at a minimum of serious. Since many these days are using Gmail as their only e-mail then could even be argued that thunderbird is now unusable or mostly so, therefore severity of grave is not out of the question either. Best Regards, Chandler
