Re: Unable to install locally built rpms
On Wed, Mar 01, 2023 at 07:39:14PM -0600, John Morris wrote: > few years old while autistically screeching "but it is INSECRE!" Be I have been traveling and just got to this thread. This comment is entirely inappropriate -- and not in any case constructive or helpful. Please don't. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Future of Test Cases and their Management in Fedora QA
On Wed, Jun 22, 2022 at 08:57:04AM -0600, Tim Flink wrote: > > 3. Continue Using WikiTCMS > > > Advantages: > - Doesn't require any changes to how we're doing things > - Is very flexible - can do pretty much whatever we want to without a ton of > code > - Doesn't require much maintenance or custom code beyond wikitcms > > Disadvantages: > - More difficult to analyze data contained in the wiki > - Only one person can report results in a given matrix at a time > - QA is the only group still using the Fedora wiki From a user perspective, I discovered the QA test matrix pages long before I realized that they weren't actually meant to be used as wiki pages, and that they were actually managed by a tool. It's easy to mess things up. And the tool is somewhat klunky if you're not used to it. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: changes to "default application functionality" release criteria
On Wed, May 04, 2022 at 05:47:33PM -0700, Adam Williamson wrote: > > So, um, maybe this is another place we could talk with GNOME upstream. > > Could we have those upstream tests run on Rawhide? > > > > Also: where does GNOME _expect_ the human-based QA to happen? Especially > > for the applications, it's going to be hard to automate thoroughly. > > Maybe we can figure out something better there too. > > So the answer to both those questions is, AIUI, kinda the same: GNOME > wants the testing run on GNOME OS. > > https://os.gnome.org/ > > which is (supposed to be, I don't know how closely it meets the goal > ATM) a nightly live GNOME image with the latest versions of everything > in it. > > Testing that is much more useful to upstream than testing Rawhide, > because we certainly aren't updating all the bits of GNOME in Rawhide > nightly. But if it's not built on Fedora (I don't think it is), it may > well have differences in theme and font configuration that might make > Fedora's openQA needles not match, which is the problem I'm concerned > about with sharing the tests. Could we (GNOME and Fedora in collaboration) set up something where they _are_ updating everything on top of Rawhide nightly? If not instead of GNOME OS, at least alongside it? That seems like it would: 1) Give a better practical test environment for GNOME folks 2) Make the needles match 3) Maybe make it so developers can fix their own needle-breaking problems? 4) Help everything get tested earlier -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: changes to "default application functionality" release criteria
On Tue, May 03, 2022 at 09:20:35PM -0700, Adam Williamson wrote: > We could look at what it would take to upstream the app tests we have > already for Fedora. What I'm afraid of is that we'd wind up finding > some subtle difference in theme or font rendering meant we'd have to > duplicate all the needles, and re-do them all twice every time freetype > or cantarell sneezes... So, um, maybe this is another place we could talk with GNOME upstream. Could we have those upstream tests run on Rawhide? Also: where does GNOME _expect_ the human-based QA to happen? Especially for the applications, it's going to be hard to automate thoroughly. Maybe we can figure out something better there too. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: changes to "default application functionality" release criteria
ibution validation testing is not *for* finding bugs like this. > > The reason we're all instinctively feeling that something is Not Right > here is that something *is* Not Right, but the big thing that's Not > Right is the upstream GNOME release process. It's not (IMHO) any part > of the Fedora process - there are things we could tighten up there, but > I see those as subsidiary problems. > > It's Not Right that GNOME can ship a 42.0 release containing entirely > broken applications. That should not be happening. It's not something > we should have to design our Fedora distribution validation testing > process to fix. So, yeah, I think there's something to do this. There were a lot of last-minute-feeling kinds of changes not just to applications but also with, like the dark-mode desktop background stuff. Shouldn't it be rare that we're discovering general "this doesn't work" issues _that aren't Fedora Linux specific_ in Fedora QA? Also, I think some of the time-tension (from the start of this message) stems from an assumption that isn't working out: "this app might be rough at beta, but will more polished by the time we're doing final validation, because upstream is working on that". Maybe this is something we can bring to GUADEC to work together to improve. (Virtual at the end of July.) > The criterion and the test case were written with the unspoken, but > IMHO reasonable, assumption that in general we could trust desktops to > provide us with more-or-less-working software. They were never written > with the intent of finding this kind of bug. The scenario I was > envisioning when we wrote them was "oh, we accidentally packaged a > broken development version of app X" or "we're still including random > third-party app Y in the Workstation edition but it's not been > maintained for years and doesn't work any more, let's throw it out". I > was never envisaging having to deal with "GNOME shipped us completely > broken applications in a stable release". I don't think our goal should > be to design a release validation process that deals with that, because > *that shouldn't happen*. This all makes sense. I still think my suggestion might help even then, for the same reason I gave to Kamil: it flips the default pressure, moves it away from QA, away from the threat of stopping the whole train and motivation-through-guilt. > > 5. Okay, and... bigger: we should aim for more approaches which let us > >decouple as much as possible from the Release. (My grand hope is that we > >can release every deliverable on its own schedule, but I also understand > >the _highly aspirational_ nature of that idea. But...) What if we could > >just easily ship GNOME Photos from GNOME 41 until a fix is found in the > >updated one? > > I mean, we maybe could. I dunno if we tried that yet. There's not > necessarily anything in the current rules/policies that precludes this, > AFAIR. For small things, it might just be a matter of shipping an old RPM. Maybe with the dreaded Epoch. But in a lot of cases it probably means we are gonna need a bigger [container]. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: changes to "default application functionality" release criteria
still believe in!) was to make sure there was a
QA team representative on every working group, and presumably that person
would be connected with both the WG and the team on decisions like this.
> So unless they really want all this responsibility, perhaps it could work
> the way around - accepted blockers could be waived by the decision of the
> relevant team. It's their product after all. Of course, there should be
> some systematic approach, so that we don't waste much time discussing
> blockers which are then getting waived. And if there are many waivers in a
> certain area, the related criteria should be adjusted to reflect that. But
> in general, I think this approach could work fine.
There are two reasons I like this the direction I proposed ('fail open'
rather than 'fail safe').
First, it moves the decision earlier; right now, waiving a blocker is very
late in the process — that means if it's not waived, it's definitely too
late to do anything about it. (Which might particularly be an issue if the
people who could implement a fix assume that it will be waived.)
More crucially, it moves the default _pressure_ from "this will ruin the
schedule from everyone else so you better fix it" to "oh no! there's a bug
in our Edition and we should fix it before the release is out".
> > 5. Okay, and... bigger: we should aim for more approaches which let us
> >decouple as much as possible from the Release. (My grand hope is that we
> >can release every deliverable on its own schedule, but I also understand
> >the _highly aspirational_ nature of that idea. But...) What if we could
> >just easily ship GNOME Photos from GNOME 41 until a fix is found in the
> >updated one?
>
> The answer could be Flatpak. And honestly in our criteria there's nothing
> preventing Workstation WG doing just that right now. But technically we're
> not ready yet, I guess. If this can be done with RPMs as well, let's go
> ahead. Ubuntu does that all the time.
I don't think we can easily do it at the rpm-alone level. Too much is
integrated. [Mumbles something incomprehensible about modularity, stares
into distance.] But I think Flatpak is definitely worth exploring to help
here (plus OCI/Podman containers for non-desktop apps).
> After reading all these proposed changes, I have to ask - what is the main
> motive for proposing them? Is it to release F36 already? Is it to prevent
> future Fedoras from delaying as much as F36? We used to be OK with release
> slips. Is desktop importance lower than before? Is it the frustration from
> finding trivial bugs in trivial apps so close to the final release?
> Something else?
In order: too late for that; yes; I know, and it was bad; absolutely not;
yes; and: generally looking at how to improve things both the Edition teams
(particularly desktop, obviously), QA, the release as a whole including
other Editions and spins impacted, and users.
> Because depending on what we want to achieve, perhaps there is a better
> way. With the current proposed changes, I believe that the end result would
> be less-delayed Fedora with more broken desktop apps. The reason for
> introducing the basic functionality criterion in the past was, iirc, a bad
> PR we were given in reviews when desktop apps often broke quickly after the
> reviewer tried to use them. It seems we'd be heading back in that direction
> with this proposal.
>
> Instead of shipping broken apps, what if we had a conversation about which
> is better - shipping broken apps or not shipping those apps at all? And I
> mean this question honestly. Is it better to ship something we *know* it's
Do you mean disable the app so it isn't included in the repo? (If so, what
does that do to people who upgrade?) Or at least hidden from Software?
It makes sense to scope the release critera to "on the media", because we
have to draw a line somewhere. But shuffling things across the line by
moving them from the default install doesn't _really_ improve quality from a
user perspective. I don't have Photos installed on this system, but if I
type "photo" in the GNOME Shell search, I'm given the suggestion to install
it.
> in a broken state, and hopefully issue an update later, or is it better to
> yank it from the default install (provided it's not crucial for the
> desktop)? Or delay the release? I'd start with defining our priorities in
> this way. Is it unthinkable to have a plan like "apps from group X can only
> delay the release for at most Y weeks, otherwise we'll not ship them by
> default"? It would also make us re-evaluate whether we really need to ship
> everything we currently have, including unmaintained apps without any
> developers, or half-baked apps with just a slight community maintenance,
> etc. I don't
Proposal: changes to "default application functionality" release criteria
Time to talk about https://www.fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality again! Lots of desktop-app-related blockers this time around, and last time too. I think we're hitting a symptom-of-our-success problem here: increasing popularity and reviews noting how polished everything is makes us very much want to build on that. So I understand why this is here, including the expanded "all installed applications" Workstation criteria. But I think we might be using the wrong tool for some of this polish, and I think we also need to give ourselves some escape hatches. By way of concrete example, the Photos application is meant to be a photo organizer, so "album picker duplicates fields, preventing photo organization" https://bugzilla.redhat.com/show_bug.cgi?id=2081291 is easy to classify as failing the basic functionality test currently. But, it's really painful for that to be blocking the release. So, ideas for discussion: 1. I know we have had GNOME Test days, but this stuff didn't come up. Presumably, it would have if someone had happened to look at GNOME Photos. Can we formally go through https://www.fedoraproject.org/wiki/QA:Testcase_desktop_app_basic and https://www.fedoraproject.org/wiki/QA:Testcase_desktop_app_basic_others much, much earlier (probably when the GNOME pre-release is available), either as part of a test day or some other formal thing? Or is there something else going on here that I'm not looking closely enough to see? (Same for KDE and any other theoretical release-blocking desktops!) 2. "Basic functionality" seems scoped too broadly currently. I propose, for the release criteria, we change this to: A) "the app doesn't crash on launch", and B) "the app's behavior does not seem immediately embarrassing with a few minutes of playing around with it". As a barometer for "embarrasing", you can imagine me trying to explain the issue to a tech reporter, and weigh how awkward I will feel saying "this is fine" vs. how I will feel explaining that we delayed the whole release for that same issue. 3. Problems found which are not regressions should not be blockers. We're just hurting ourselves when we make this our forcing function to get something fixed. Some of these could be Prioritized Bugs, but I don't want to overload that too much. I propose that the teams responsible for blocking desktop deliverables keep their own prioritized lists of this kind of problem that the team agrees should be fixed for a good user experience. Not just add to the general queues of bugs or tickets, but specific lists of "application experience issues". These lists, of course, could include problems which also don't qualify for point #2 but which seem important. Like the Photos app issues. (This could also extend to "desktop experience issues" rather than just "application". Or for that matter there could be a similar mechanism for non-desktop blocking deliverables.) I could be convinced either way on having these in the teams' issue trackers in pagure or whereever _or_ having it as more targets in the blockerbugs app. I tend towards the latter: I think it might help with the problem where blockers feel like the only obvious way to bugs tracked and fixed. But either way, there should be lists! 4. Desktop application problems discovered during at the last minute should not be blockers. If the problem is really going to impact a lot of people, it should have been discovered in the beta. (Exception for _new_ regressions, of course.) By the time we're in final freeze, this ends up being hero work for everyone. I don't know how to phrase this in a way that doesn't make Adam sad with me, but maybe something like: Desktop application blockers discovered during the final freeze are automatically waived unless the relevant Spin or Edition team decides otherwise. That lets us still block if something is really bad and just happened to slip through. 5. Okay, and... bigger: we should aim for more approaches which let us decouple as much as possible from the Release. (My grand hope is that we can release every deliverable on its own schedule, but I also understand the _highly aspirational_ nature of that idea. But...) What if we could just easily ship GNOME Photos from GNOME 41 until a fix is found in the updated one? -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines Lis
Re: Proposal: Explicitly allow Council to waive Edition self-identification
On Mon, Mar 14, 2022 at 04:46:00PM -0700, Adam Williamson wrote: > I feel pretty strongly the opposite on that one. Ben pre-empted me on > IRC by already suggesting this approach (which I'm fine with), but > before he had sketched out the specific approach, I was going to > specifically suggest *NOT* giving Council (or anybody else) a "this > isn't a blocker" rubber stamp. To me there's a big difference between a > "this is a blocker" button and a "this isn't a blocker" button. The > temptation to overuse the latter just to get releases done on time > would, I think, be entirely too great. Very possibly! I would certainly feel the temptation. This is why I said that it's good for me to listen to those of y'all who are good at process. :) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: Explicitly allow Council to waive Edition self-identification
On Fri, Mar 11, 2022 at 12:45:05PM -0800, Adam Williamson wrote: > I'm +1 to this; it makes sense for me that Council should be able to > veto/waive blocker decisions in this specific context, I just wanted > there to be a proper mechanism for it. This seems like a reasonable way > to achieve that. First, I want to (in complete non-ironic sincerity) express appreciation to all of y'all process-oriented folks who make sure this stuff stays on track. Continuing from https://pagure.io/Fedora-Council/tickets/issue/389#comment-785815... I suppose as an engineering collaboration (releng, devel, qa...) it may have been better for us to direct this at all of those teams, or maybe FESCo. FESCo has a "make this a blocker" button... I kind of feel an itch for a generalized "sometimes stuff comes up" lever that goes the _other_ direction, rather than a very specific carve-out. We wouldn't be here if I (well, the Council, but I'll go ahead and say specifically _me_) had made sure we'd done the proper followup around Cloud "de-editioning" several years ago, and I don't think there's likely to be a case where this new policy is actually ever used again — if there is, that'd signal another failure. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: is an accidentally reverted Fedora feature/change a blocker?
On Sat, Dec 18, 2021 at 10:49:53AM -0800, Adam Williamson wrote: > > This makes sense to me. It might also make sense for big changes to also > > include proposed updates to the validation criteria, just as modern software > > development expects new features to come with tests for those features. > > We do this, but only for *functional* requirements, which I think is > correct. I don't want us to be pinning software versions and what > specific implementation of a given function "must be" used in the > release criteria, in general, because it seems like a terrible > mechanism for it, and one that really wouldn't scale. Okay, fair enough — and I'm definitely not wanting to add _more_ automatic blockers. :) But it does seem like we should have _some_ set of automated testing that's linked to intentional, acccepted changes. Nano-as-default in Fedora Server is another one. Maybe even something where "getting the test hooked up" is the next step for the change owner after the change is accepted. Is there a way where change owners could plug into some of our existing automated testing to do that? -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: is an accidentally reverted Fedora feature/change a blocker?
On Sat, Dec 18, 2021 at 09:09:17AM -0800, Adam Williamson wrote: > However, I think there'd be a solid case for FESCo to take anything > like this as a blocker, and procedurally that makes more sense too - > Changes are under FESCo's remit. So if a case like this is caught > before release, I'd say file a FESCo ticket asking them to consider it > as a blocker. This makes sense to me. It might also make sense for big changes to also include proposed updates to the validation criteria, just as modern software development expects new features to come with tests for those features. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Common Issues on Ask Fedora -- experiment now public
On Tue, Dec 14, 2021 at 03:52:18PM -0800, Adam Williamson wrote: > Thanks for the work on that, Matthew. I'm on PTO from tomorrow until > the new year, so my feedback will probably have to wait for then, > sorry! Oh, no problem. Please enjoy your PTO, and do not think of bugs, common or otherwise. :) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Common Issues on Ask Fedora -- experiment now public
We've transferred all of the entries from the F35 common bugs wiki page to the new process at https://ask.fedoraproject.org/c/common-issues/common-issues-proposed/141/ (well, a few of them are still in the proposed category, but we're working on them). QA team, your feedback very appreciated here! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
On Mon, Nov 29, 2021 at 06:29:37PM -, Marius Schwarz wrote: > I suggest just to post Booting related Bugs on the Web and implement a > "F.H.B." tool ( Frequently Hit Bugs ) > in the Distro. > > You may ask "Why?" > > If the system boots, but i.e. it's a network problem occurs, a local > Bugs-and-theire-Solutions List would help to solve it fast. Maybe. I'm assuming that at this point most people with a computer also have another device (a phone, at least) with internet access. > How do we get this? > > It does not need to be fancy, a simple onepage Website presented in the > Defaultbrowser would be enough. But how does the content get there? > This also gives a good connectivity to "Ask Fedora" as that content is > already HTML. > > The script that creates this, just needs to stich some HTML headers > together and combines selected Bugs & Solutions into the page. Simple > approach. Simple Solution. What is it stitching it _from_? How does it get into the install media? How do we update it? What if it's a problem discovered after we go "gold"? Do we pull back the release? -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
[Test-Announce] Help test (and contribute to) new experimental Common Issues section on Ask Fedora
Short background: a little while ago, I proposed that we move CommonBugs from the wiki to a special section of Ask Fedora. Details here: https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/NE6IKJMLKUK2BB4HGBQTALXKJFKVKTR7/ Over the Thanksgiving holiday, I hacked up some starting ideas, and am now ready for other people to help. I'm looking for a) People who are interested in helping figure out how this new system should work, and possibly helping document and code. b) People who are interested in helping maintain the posts as part of the Common Issues Triage Team, which I imagine existing as a sub-group of Fedora QA. I'd like to _lighten_ the work for the QA team members who are currently maintaining the wiki. c) Those current folks for input and hopefully also a & b going forward. d) Someone to help me put my prototype bot script into production. e) People who are entirely skeptical of this whole idea, because I'd like to (at best) try and convince you or (failing that) at least include your perspective. If you fit any of these categories, please join me at https://ask.fedoraproject.org/t/new-common-issues-process-trial-next-steps/18781 Thanks! -- Matthew Miller Fedora Project Leader ___ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
On Thu, Nov 18, 2021 at 07:38:26PM -0500, Matthew Miller wrote: > * More laziness for me (not needing to do steps 1 or 2 of the list above) Well, forget laziness. I made a script[1] that does these things. And a bunch of other stuff, some of which is only partly done, but I think well enough along to invite others to look. Please see https://ask.fedoraproject.org/t/new-common-issues-process-trial-next-steps/18781 for the next phase of the experiment here, and let me know what you think (and if anyone is interested in helping)! [1] https://pagure.io/issuebot/blob/main/f/issuebot.py -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
On Thu, Nov 18, 2021 at 07:38:26PM -0500, Matthew Miller wrote: > * As I understand the semantics now, "CommonBugs" keyword means "maybe > common bug?" and "CommonBugs + properly-formatted URL in the whiteboard > field" means "actually common bug". Which is... kind of arcane. It seems > like "is issue in Proposed category or the accepted one" is a lot more > obvious. Addendum: I did the query for proposed common bugs http://bit.ly/fedora-commonbugs-proposed and while there are definitely good-faith proposals there, there also seem to be at least _some_ cases where someone has a bug that is important and urgent to them and therefore they have set a bunch of random keywords because they can. If we instead make the entry-point on Ask, we at least have some opportunity to present the basic concept. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
On Mon, Nov 08, 2021 at 08:54:04AM -0800, Adam Williamson wrote: > > 1. The new process needs to make sure that Bugzilla entries with CommonBugs > >keyword are triaged in a timely manner. > > 2. When proposed Common Issues* are accepted, the whiteboard field in > >Bugzilla is updated. > > 3. All accepted entries need to follow a consistent format, ideally using > >some form of templating. > > 4. We need templates to deal with special cases like those which require > >installer images, or where a workaround is needed even when an update is > >available. > > 5. Entries need to be updated with instructions when a candidate fix is > >available. > > 6. And further updated when a fix is released. > > 7. We figure out something to do about archiving at EOL time. (Although this > >doesn't necessarily need to be in place until... F38. Could be part of a > >general plan to archive older topics on Ask Fedora.) > > 8. We have new documentation covering the new procedures. > > 9. We have tooling in place and/or people commited to cover all of the > >above. > > 10. More automation would be lovely, but at least we don't want it _less_ > >automated than the current state. > > > > Does that cover it? What did I miss. > > That's more or less it, except that it doesn't cover how update- > commonbugs helps a *lot* with points 5 and 6. Doing that manually is a > drag. What I'm thinking it would do for 5 and 6 is: * For each topic in the Common Issues (including Proposed) category that isn't marked as solved, * check periodically for bodhi updates (I think by looking for the Fedora Update System messages in bugzilla?), * and if those updates were posted after the last such reply, * post a reply to the topic with (filled-in) boilerplate appropriate to the candidate or expected fix state (and possibly other metadata from the topic itself). (This bot would have permissions to reply in the Common Issues category, as would QA team members.) I _think_ we would rely on humans to mark the issues as definitely "solved". Okay, hmmm, before I go further with this, let me check something: Package updates aside, how important is it for this process to be bugzilla-driven at the start? Or, in bugzilla at all? Is it: - "migration requirement for with least possible change and annoyance", or - "bugzilla adds an important tracking element", or - "since these issues are _bugs_, bugzilla is inherent to the whole concept" - something else? ? If we made the process for "nominate a bug" be "post in the Proposed Common Issues category" rather than "add CommonBugs to the bugzilla keyword field", what would we lose? Advantages would be: * More laziness for me (not needing to do steps 1 or 2 of the list above) (probably would still want automation to help with 5 and 6 though). This is non-trivial laziness, as 2 at least requires _writing_ to bugzilla, while 5 and 6 could just read. * As I understand the semantics now, "CommonBugs" keyword means "maybe common bug?" and "CommonBugs + properly-formatted URL in the whiteboard field" means "actually common bug". Which is... kind of arcane. It seems like "is issue in Proposed category or the accepted one" is a lot more obvious. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
On Sat, Nov 13, 2021 at 07:41:53PM -0500, Matthew Miller wrote: > I created a test topic to play aruond with what this would look like. Take a > look: > > https://ask.fedoraproject.org/t/no-sound-after-upgrade-to-fedora-linux-35/18243 > > In most cases, I think the solution part will be concise enough that it > should be entirely displayed within the solution box in the first post. The > main problem I see is that "code" formatting is lost in the solution quote. The more I think about it, the more I think that we should leave "solution" for the state when the issue is actually resolved, and put work-arounds and other helpful information the top post. Then, when a release goes EOL, we should (programmatically) mark all of the Common Issues topics related to a release as Archived. I guess probably also any still-pending Proposed ones. Possibly also move these to an Archived Common Issues topic, but I'm not sure about that. Anyway. Enough for today. I'll post about this on Ask next week sometime :) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
> > As I'm reviewing some of the previous wiki pages now, I actually am kind of > > inclined to think that it's better to have stronger problem/solution > > separation. But I could be convinced either way. > > I feel a bit like wasting the reader's time to let them first read through > a question, and then follow a link to a marked solution. I know this is how > it would look if it was a regular question-answer topic in the forum. But > the wiki style provides a more efficient and readable way to learn about > high-profile issues (straight to the point, exact), and going to a forum > style would be a downgrade. I created a test topic to play aruond with what this would look like. Take a look: https://ask.fedoraproject.org/t/no-sound-after-upgrade-to-fedora-linux-35/18243 In most cases, I think the solution part will be concise enough that it should be entirely displayed within the solution box in the first post. The main problem I see is that "code" formatting is lost in the solution quote. > So in order to provide good readable descriptions to our users > (solution-style), they would either need to be written in this style also > in Proposed Common Issues, or rewritten into a new topic. So the actual > "why is X broken? - have you tried Y? - and what about Z?" discussion would > occur probably elsewhere, in some generic Ask category, and once properly > discovered, somebody would rewrite it into a solution-style topic into > Proposed Common Issues, where we would verify it and promote it (move it) > into Common Issues if it's good enough. Does it make sense, am I imagining > it correctly? Yeah. As I'm imagining it, we'd allow replies in the Proposed Common Issues topics, but they'd be limited to discussion about the text of the problem, whether it should be promoted, etc. If someone replies about the bug itself, we can move the reply (easily done) to a new or existing topic. Then, when we promote the topic, we'd hide any remaining replies. (Still there for history but regular users wouldn't see them.) > What about changes to topic titles, do they change the URL? (That would be > very inconvenient, perhaps even a deal-breaker). The "real" identifier is a number. The above link works as * https://ask.fedoraproject.org/t/no-sound-after-upgrade-to-fedora-linux-35/18243 but also * https://ask.fedoraproject.org/t/18243 or * https://ask.fedoraproject.org/t/something-else-altogether/18243 It _also_ works as * https://ask.fedoraproject.org/t/no-sound-after-upgrade-to-fedora-linux-35 without the number, but... our tools obviously should avoid that. > > There is a setting "Make new topics wikis by default" which we would > > enable for these categories. It doesn't make the post ownerless, though. > > I think we could set these expectations reasonably in the description of > > the category. > > > > That might work. I think it also implies that you'll not simply take some > topic from a general Ask category and tag it into Proposed Common Issues, > because that wouldn't convert it into wiki style, wouldn't be in a > solution-style text, and also the topic authors might be negatively > surprised. True. > So, we'll need a way to tag interesting topics in general categories as > "look, this might be a frequent and important bug", and then a set of > volunteers who sift them and convert selected ones into Proposed Common > Issues, and then QA goes through those and promotes some of them into > Common Issues. Ugh, is it too complex? I think the "tag" process and "convert into proposed" can be combined. Basically all you'd do is reply-as-linked-topic from the proposed topic and put your reply in the Proposed Common Issues category. Then that's what QA (including, in my mind, new volunteers from Ask) would consider to promote. > Just to be clear, I'm still not convinced this is a good idea :-) But why > not try it. Perhaps we'll then come up with some mixture of both > approaches, or at least realize some shortcomings. Yes, thanks. I'm also not sure it's the _best_ way, but I think it _might_ be better. We can see! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
On Tue, Nov 09, 2021 at 02:38:59PM +0100, Kamil Paral wrote:
> 1. In the Proposed Common Issues category, how are the topics intended to
> look like? Will the initial topic description be a question ("my sound is
> broken, how do I fix it?") and then somebody will provide a solution which
> will get marked as such, or will the initial topic description be already a
> solution (i.e. a similar text to what is currently on the CommonBugs wiki)?
I think the topic titles will be the same as with Common Bugs now, like
"Configured repositories in Discover jump around in the list" or "Clipboard
is not shared with KDE virtual machines".
The site name, "Ask Fedora", makes me _want_ to force them into the form of
a question just... to make it all nice... but in practice most topic tiles
are in the form of a problem summary already. ("Closing the laptop lid does
not turn off the screen", "2-finger scroll occasionally disabled".) So I
think that keeping to the current title format is good.
I can go either way on whether the first post in the topic should also
provide the solution, or whether we should used the answer-solution format.
As I'm reviewing some of the previous wiki pages now, I actually am kind of
inclined to think that it's better to have stronger problem/solution
separation. But I could be convinced either way.
> 2. In the Common Issues category, will the topics look the same as in 1)
> (we'll simply re-tag them there), or differently? (e.g. a question-style in
> Proposed, a solution-style in actual Common Issues).
I was thinking just move them, yeah.
> 3. Can we easily move a topic (or add a tag to it) into the Proposed Common
> Issues category, when it is currently in a completely different one? And
> similarly, we can easily move out a topic from Proposed Common Issues to
> some generic "Ask" category?
Yes to both. And URLs for topics do not include the category, so moving them
will not break any existing external links.
> 4. The solution text often needs maintenance. Some clarifications, newly
> discovered workarounds, etc. If the original solution text was created by a
> community member, is it expected that we'll simply edit his/her post? Or
> what do we do? On wiki, it is owner-less, which avoids the problem
> "somebody edited my post, and it's still displayed under my name, but those
> aren't my words, and I don't like it".
There is a setting "Make new topics wikis by default" which we would enable
for these categories. It doesn't make the post ownerless, though. I think we
could set these expectations reasonably in the description of the category.
And if someone at some point really doesn't want their name attached, we can
always move the Solved check.
> I'm sure I'll have more questions after I think about it a bit more :-)
Sure. :)
> Overall, I don't have strong opinions on the proposal. A wiki is easier for
> us, but otoh more community involvement would definitely be nice. We could
> try a different approach as an experiment. If we do, it might be good to
> start it right away, so that some initial problems are resolved before the
> F36 cycle runs in full swing.
That does seem like a good idea. Maybe not quite _right away_, but soon.
Would you suggest duplicating the F35 Common Bugs, or making some _possible_
F36 ones based on Rawhide issues?
--
Matthew Miller
Fedora Project Leader
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Perpetual Fedora
On Mon, Nov 08, 2021 at 11:38:27PM +, Rick Marshall wrote: > At times we can be managing several hundred desktops. They get > installed over time and with a script that makes sure they > auto-update packages and reboot if there is a kernel update. For > systems that can't be allowed to reboot we get an email advising us. > All of that is good. Okay, this is a tangent, but: have you considered using `dnf offline-update` on the systems where a reboot is okay? That minimizes the chances of problems from updates happening underneath something that expected them to not change. And back off the tangent: if you did that, the version upgrade is usually just a matter of using `dnf system-upgrade` instead, once or twice a year. > I guess what I was really thinking about was a version free > repository. Similar to the no_arch repository. > > This would be for application developers etc who don't need to rely > on distribution version. It could even apply to kernels. I guess I don't get how this would help. It isn't the _number_ that causes incompatibility, but rather accumulated underlying changes. A rolling/perpetual version still has those changes, but unpredictably. > As a package developer my biggest issue has always been keeping > enough versions of Fedora and RH on machines to create versions of > the product. A single release will always need 3-6 OS packages. I'm > not sure this is either productive or efficient. I can't do anything about different versions of RHEL, although there are possible solutions here which generalize. Rather than targetting multiple releases, build against RHEL UBI* and distribute your application as a container image (or Flatpak, if it's a desktop application). Or, if that doesn't work for you, you could just say that you only support the latest Fedora release? I think it's _nicer_ to provide users with options, but that's always a possibility. I'd love to say "we can offer a stable API that doesn't change for years", but... well, that's expensive to do, which is why there is RHEL. :) > PS really appreciate the work you guys do. On behalf of everyone, thanks! * https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
On Mon, Nov 08, 2021 at 08:54:04AM -0800, Adam Williamson wrote: > That's more or less it, except that it doesn't cover how update- > commonbugs helps a *lot* with points 5 and 6. Doing that manually is a > drag. Ack. I will restate with greater emphasis there. > > Definitely have people _interested_. I'll see about _committed_. :) > > Yeah, see, this is a fairly significant distinction. ;) Honestly, if > people are crazy enough for this and you can get to the point where > there's a system that will work and just give Kamil and I the user's > guide, that would be fine too. I just don't want to get stuck in a bind > at F36 Beta time where someone's decided moving common bugs would be a > great idea but we have to figure out how to actually do that as we go > along. Fair! > > Adam, would you be _interested_ in helping update the scripts and creating > > automation, if you had work time to do it? What would the tradeoffs be? > > The prospect doesn't exactly fill me with excitement, honestly, but if > nobody else wants to do it yet this is still somehow super desirable, > maybe. The tradeoffs would be with all the other stuff I have to do in > the pre-F36 Beta time, like proposing criteria changes, updating the > openQA packages to recent snapshots, adapting the openQA resultsdb > reporting code to handle authentication, making openQA job scheduling > handle Bodhi 're-trigger requests' messages once they're fixed, writing > new tests for openQA (we have a backlog of test request tickets some of > which are over a year old), finally getting somewhere with > releasestream... Okay. Let me see if I can find someone who does feel like this fills them with excitement. Because, yeah, that's a lot. :) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Perpetual Fedora
On Mon, Nov 08, 2021 at 03:11:55AM +, Rick Marshall wrote:
> I'm trying to understand why we have to have Fedora versions.
>
> Fedora is a my favourite Linux however the version upgrade is
> problematic when managing large numbers of machines. I have my
> reasons for using it in production as a desktop, but not as a
> server.
>
> Why do we have versions instead of constant updates as happens
> within a version?
We try to concentrate large, planned changes on the release boundaries.
Hopefully that means that we can make the user-impact of those changes
smooth, but it does mean that they tend to be all concentrated at one time.
However... the way we do things lets you choose when you want to absorb that
change.
You can see the changeset in advance:
https://fedoraproject.org/wiki/Releases/35/ChangeSet
https://fedoraproject.org/wiki/Releases/36/ChangeSet
and plan around that, as well as look out for common problems at
https://fedoraproject.org/wiki/Common_F35_bugs
.
If we did a perpetual ("rolling") release, there would be the same amount of
change, but you'd get it sporadically -- maybe some Thursday morning
suddenly becomes a lot of work.
And, of course, if we just had one supported release, you'd be stuck with
needing to do upgrades in April/October, on our schedule. But, we
intentially have two supported releases, with 7 months of overlap. That way,
you can schedule when you want to do the bigger updates — including deciding
to entirely skip a release if you like.
Like all Linux distros, we're always absorbing a lot of change coming from
thousands of upstream projects. We (Fedora) think this approach is the best
one for delivering that change to users in a polished, friendly way (on
desktops _and_ servers). In the past few years, we've put extra work into
making sure the upgrade process is painless — _usually_ not much different
from a really large regular update.
What are the problems you are encountering with managing this on large
numbers of machines? (What is the value of "large" in your case?) Do you
deploy with golden images, via pxe and kickstart, or by some other method?
Do you use ansible or some other config management tool?
> Happy to ask elsewhere if this is the wrong place.
This probably isn't the best place, because it's not really a test / QA
decision. FESCo is the governing body for the overall release schedule
(which is then implemented and managed by the Program Manager).
--
Matthew Miller
Fedora Project Leader
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
On Sat, Nov 06, 2021 at 11:55:39PM -0700, Adam Williamson wrote: > * Acknowledged and had a definite plan to replace the existing tooling > and practices at least at the same level as currently. Okay, cool. Can you help me better define the "at the same level" benchmark? My stab at things that needed to make sure the new way meshes with the current process: 1. The new process needs to make sure that Bugzilla entries with CommonBugs keyword are triaged in a timely manner. 2. When proposed Common Issues* are accepted, the whiteboard field in Bugzilla is updated. 3. All accepted entries need to follow a consistent format, ideally using some form of templating. 4. We need templates to deal with special cases like those which require installer images, or where a workaround is needed even when an update is available. 5. Entries need to be updated with instructions when a candidate fix is available. 6. And further updated when a fix is released. 7. We figure out something to do about archiving at EOL time. (Although this doesn't necessarily need to be in place until... F38. Could be part of a general plan to archive older topics on Ask Fedora.) 8. We have new documentation covering the new procedures. 9. We have tooling in place and/or people commited to cover all of the above. 10. More automation would be lovely, but at least we don't want it _less_ automated than the current state. Does that cover it? What did I miss. > * Came with people attached who are definitely committed to working on > the implementation and all the work of writing issues, wrangling > replies, tagging things, aging things out... Definitely have people _interested_. I'll see about _committed_. :) I'm not proposing we do this until we hit the appropriate time in the F36 schedule, so I guess ~ beta freeze. That gives some time to line things up. Adam, would you be _interested_ in helping update the scripts and creating automation, if you had work time to do it? What would the tradeoffs be? Also: although this isn't a change to Fedora Linux... maybe I should run this through the Changes process? * Bikeshedding tangent: I prefer "Common Issues" to "Common Bugs", because it's broader and there's less potential for conflict between different possible technical and less-technical definitions of "bug". Like, I'm seeing some people On The Internet say, with apparent straight faces, that "bugs" are found during the testing phase and that once it's in production, it's a "defect" not a "bug". -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
ature https://meta.discourse.org/t/discourse-canned-replies/48296 to insert text in consistent way. It does not have a variable-substitution feature, though, so one would have to manually put the right ADVISORY in the right places. And rather than the cleverness in the updates_testing macro for the "noupdate" case, we'd probably just use different canned replies. I'm thinking we'd use the "Add Staff Color" feature to highlight "official" replies, and also mark the answer as the "Solution" once the update is released (which would look similar to for example https://ask.fedoraproject.org/t/discover-is-always-asking-for-reboot/17888). Or, we could edit these things into the first post in the topic. (Canned replies are available there too, despite "replies" in the feature name.) (There exist other Discourse plugins that could do more, or we could even write our own, but I'd like to stay away from that.) > and, perhaps least obviously but most *usefully*, there's a fairly > capable script I use for actually maintaining the pages: > > https://pagure.io/fedora-qa/qa-misc/blob/master/f/commonbugs-update > > this processes the page for a given release, parses it one issue at a > time, and detects whether the issue is now addressed by an update, and > lets you modify the page appropriately (adding the right template and > moving the issue to the 'resolved' section if it's stable) if so. It > saves a lot of tedious work doing this manually. Of course, this is a double-edged blade, because it also significantly increases the esoterica of the whole thing, and also makes me more scared than I already am of editing the wiki page for fear of breaking your script. BUT that said, if we get to the situation where you're on board with this as at least an experiment, and I can make the case for the value of your time directed to this, Discourse has an API https://docs.discourse.org/ that the script could be ported to, and maybe even made to run automatically and more frequently. (Or have it message bus triggered, whenever a bug with the "CommonBugs" keyword is updated?) That script could handle the "ADVISORY" substitution issue, too, right? That is, fill out the full expanded text, rather than a template. It could construct the initial post in the "Proposed Common Issues" category if someone tags a bug in the right way, and move it to the top-level if the bug is updated to "graduate" it. Or, the process could go the other way around, with the script updating bugzilla metadata based on the post in Discourse. (But I am getting ahead of things here, clearly.) > I suppose the other way I'd support this change is if someone else was > volunteering to take over all the work of writing and maintaining these > pages. But only if they were going to do it at least as well as Kamil > and I do. Yes, absolutely. My goal is to make it better not worse, and overall less work shared among more people. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Proposal: Migrate “Common Bugs” from the wiki to Ask Fedora
Background -- Every release since possibly the dawn of time (or, at least, [Fedora Core 5][1]), we make a [Common Bugs page][2] on the wiki. This is where we document things that we judge not to be blockers but are concerned many people might run into on upgrade or first install of a new Fedora Linux release — or, would-be blockers we decide we have to waive because we don’t have time or resources to fix. Or, just common issues that crop after the release. Problem --- This time around, based on my anecdotal impression from social media, Ask Fedora questions, and even comments on the release announcement, [No sound after upgrade][3] appears to be the … winner. Lots of people are hitting this. This leads me to several observations: - The given solution works for most people, but clearly many are not seeing it. - We have no way of telling how many people *did* find a solution and therefore say nothing. - For that matter, we have no really good way of telling if there’s actually a *different* issue more people are affected by, but just less loud about. - The bug linked from the Common Bugs page gets cluttered up with: - People for whom the workaround didn’t work and resulting discussion - Reports of similar issues which are not, in fact, that issue. - Alternate suggestions which may or may not be good advice. Proposal --- I suggest that for the Fedora Linux 36 release, we move to an Ask Fedora–based replacement for this wiki page. Now, to put my cards on the table here: - I don’t *actually* hate the wiki, but I do think we shouldn’t be sending unwitting end-users there. - I *do* love Discourse. There. I said it. - And, I love Ask Fedora in particular. It’s a community success. Specifics - We’d create a new top-level category, “Common Issues”. Posting directly in the category would not be allowed. Instead, there would be a *subcategory*, “Proposed Common Issues”. New topics in “Proposed Common Issues” would use the template feature, prompting for the necessarily information and keeping the format consistent. Unfortunately, there are no macros to do the fancy things the current wiki process uses, which I will freely admit is a drawback. Each topic would be tagged with the release that it corresponds to (and, ideally other tags, like the installation / upgrade / workstation / etc. sections on the wiki — we could make that mandatory or just by convention). Members of the QA team (based on group membership, automatically once [Does `sso overrides groups` work with Oauth2? - sso - Discourse Meta][4] is fixed upstream) and possibly other volunteers will be marked as category moderators, and so can promote topics to the higher-level “Common Issues” after vetting them. And, we’d turn on voting, and ask people to vote for issues that they have also experienced. Not scientific, but gives a measure that we don’t have now. Advantages -- - More visible to end users. (I think, at least.) - Directly linked to where we’re telling people to go for help, and where people are talking about their problems. - Gives a place to comment on and discuss the problem *other* than cluttering the bug in bugzilla. - Right now, *Lots* of people on Ask coming in with new questions about the no-sound-on-upgrade issue. Even if they don’t find it and avoid needing to ask, we can easily merge those into the main topic. - Conversely, when a person has a *different* issue, it’s easy to split that into its own help thread. - And we can moderate and organize response in general to make sure people are seeing the most helpful advice and not getting misdirected. - Right now, the release-cycle QA process is the primary source of Common Bugs. But… maybe we’re missing things that users are finding? - Discourse’s notify-by-mail feature is nicer than following wiki page changes by mail. - Moves us towards Ask Fedora as a first-top issue triage center, reducing Bugzilla load for maintainers *and* reducing end-user frustration with unmet expectations about Bugzilla response. Disadvantages - - No fancy formatting macros - New thing for QA team folks to take on and I know there’s already a lot - Other? Discussion? --- I’m posting this both [Ask][5] and here on the Fedora Test mailing list. Discuss where you feel most comfortable and I’ll try to link the results. [1]: https://fedoraproject.org/wiki/Common_FC5_bugs [2]: https://fedoraproject.org/wiki/Common_F35_bugs [3]: https://fedoraproject.org/wiki/Common_F35_bugs#No_sound_after_upgrade [4]: https://meta.discourse.org/t/does-sso-overrides-groups-work-with-oauth2/175606 [5]: https://ask.fedoraproject.org/t/proposal-migrate-common-bugs-from-the-wiki-to-ask-fedora/17794?u=mattdm -- Matthew Miller Fedora Project Leader ___ test mailing list -- test
Re: [External]Firmware updates not being applied?
On Wed, Jul 28, 2021 at 09:52:12AM -0400, Matthew Miller wrote: > Ah, well that's unfortunate, and almost certainly what I'm seeing. Thanks! (And yes, this was it.) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [External]Firmware updates not being applied?
On Wed, Jul 28, 2021 at 02:01:53AM +, Mark Pearson wrote: > Do you have secure boot enabled? Yes I do -- on both the ThinkPad and the ThinkStation. > There's currently an issue with shim that is preventing fwupdx64.efi working > properly when SB is enabled. > I know they're working on it - but workaround for now is to disable SB. Ah, well that's unfortunate, and almost certainly what I'm seeing. Thanks! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Firmware updates not being applied?
On my F34 system, the latest Lenovo firmware updates don't seem to apply. Reboot happens, but the firmware update process doesn't. Is anyone else seeing this? I don't have anything complicated — no dual boot, and I haven't messed with anything related to booting or EFI, and this _was_ working initially. How do I further diagnose and fix? From `sudo fwupdmgr get-history`: 20U9CTO1WW │ [...] ├─Embedded Controller: │ │ Device ID: 0b3db288d2c013fcac57525c52aa6dc2c9934157 │ │ Previous version: 0.1.6 │ │ Update State: Success │ │ Last modified: 2020-11-09 18:37 │ │ GUID: 1ebe8ad3-3d40-4178-92ce-bbb3d0906332 │ │ Device Flags: • Internal device │ │ • Updatable │ │ • System requires external power source │ │ • Supported on remote server │ │ • Needs a reboot after installation │ │ • Device is usable for the duration of the update │ │ │ └─ThinkPad X1 Carbon Gen 8 /X1 Yoga Gen 5 Embedded Controller Update: │ New version: 0.1.08 │ Remote ID:lvfs │ Summary: Lenovo ThinkPad X1 Carbon Gen 8 /X1 Yoga Gen 5 Embedded Controller Firmware │ License: Proprietary │ Size: 767.1 kB │ Created: 2020-09-22 │ Urgency: High │ Vendor: Lenovo Ltd. │ Description: │ Lenovo ThinkPad X1 Carbon Gen 8 /X1 Yoga Gen 5 Embedded Controller Firmware │ │ Fixed an issue where ThinkVision T24m-10 monitor might not connected properly. │ ├─Intel Management Engine: │ │ Device ID: f84b617c1c8e86d5a85e12fd7c530ac38897b081 │ │ Previous version: 224.45.1389 │ │ Update State: Failed │ │ Update Error: failed to run update on reboot │ │ Last modified: 2021-07-27 15:21 │ │ GUID: 216e4407-43ff-4b84-9929-a1807761b1a0 │ │ Device Flags: • Internal device │ │ • Updatable │ │ • System requires external power source │ │ • Supported on remote server │ │ • Needs a reboot after installation │ │ • Device is usable for the duration of the update │ │ │ └─ThinkPad X1 Carbon Gen 8 /X1 Yoga Gen 5 Consumer ME Update: │ New version: 225.53.1649 │ Remote ID:lvfs │ Summary: Lenovo ThinkPad X1 Carbon Gen 8 /X1 Yoga Gen 5 Consumer ME Firmware │ License: Proprietary │ Size: 3.4 MB │ Created: 2021-04-23 │ Urgency: High │ Details: https://pcsupport.lenovo.com/de/en/search?query=N2WRN11W │ Vendor: Lenovo Ltd. │ Flags:is-upgrade │ Description: │ Lenovo ThinkPad X1CarbonGen8 X1YogaGen5 Corporate MEFirmware.This stable release fixes the following issues *14.0 Intel ThinkPad Platform Update Version 14.1.53.1649 to Fixed intel security issue. │ └─System Firmware: │ Device ID: 6f1acb499f6e604cfd7563f33d04f26ecdd07138 │ Previous version: 0.1.15 │ Update State: Failed │ Update Error: failed to run update on reboot │ Last modified: 2021-07-27 15:21 │ GUID: 31245a58-b272-4776-9398-3df5e8b532db │ Device Flags: • Internal device │ • Updatable │ • System requires external power source │ • Supported on remote server │ • Needs a reboot after installation │ • Cryptographic hash verification is available │ • Device is usable for the duration of the update │ └─ThinkPad X1 Carbon Gen 8 /X1 Yoga Gen 5 System Update: New version: 0.1.17 Remote ID:lvfs Summary: Lenovo ThinkPad X1 Carbon Gen 8 /X1 Yoga Gen 5 System Firmware License: Proprietary Size: 25.0 MB Created: 2020-07-01 Vendor: Lenovo Ltd. Flags:is-upgrade Description: Lenovo ThinkPad X1 Carbon Gen 8 /X1 Yoga Gen 5 System Firmware Version 1.17 The computer will be restarted automatically after updating BIOS completely . Do NOT turn off your computer or remove the AC adaptor while update is in progress. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam
Re: Priority test request: jpegxl (F34)
On Wed, Jun 16, 2021 at 09:46:06AM -0700, Adam Williamson wrote: > aom was recently updated in F34 and Rawhide (the update for F33 is > pending), and the new version of libaom depends on jpegxl-libs...which, > it turns out, recommends a gimp plugin. Which means if you have libaom > installed - and it seems to be part of default KDE and GNOME installs - > updating to the new aom version will wind up pulling in GIMP, if you > don't already have it installed, and GIMP pulls in Python 2.x and GTK+ > 2.x if you don't have those installed. That's a lot of unwanted > packages. I suppose the intention here is so that someone who installs the library for this format gets it automatically working in Gimp. Maybe some of the new-fangled rich dependencies would be be better than a "Recommends". -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: PipeWire issues with <= 0.3.24
On Mon, Apr 19, 2021 at 02:22:38PM -, Garrett LeSage wrote: > Could we make this a blocker, so that this newer version (0.3.15) will be > included in the release? You can nominate this as a blocker or freeze exception -- https://qa.fedoraproject.org/blockerbugs/propose_bug is the interface for doing this. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora Linux 34 Final blocker status update #4
On Thu, Apr 15, 2021 at 04:57:46PM +0200, Luna Jernberg wrote: > Delayed another week: > https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/thread/2UHYXZ6LDWEQ2EUEL3QUMV753JKEAUXZ/ To be clear, this isn't a "delay". Not yet at least. :) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F34, pipewire and orca (screen reader)
On Thu, Apr 15, 2021 at 08:54:55AM -0500, Michael Catanzaro wrote: > Yes, that is not a regression, at least not a recent one. The live > anaconda is simply not accessible at all. I noticed this for the > first time last year. It's a shame. This seems like something worth making a priority for F35. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Basic criterion proposal: g-i-s shouldn't take 2 minutes to launch
On Wed, Apr 14, 2021 at 02:13:31PM -0500, Brandon Nielsen wrote: > Does that make this[0] a blocker candidate? > [0] - https://bugzilla.redhat.com/show_bug.cgi?id=1943683 Looks like it to me. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self-introduction: TheEvilSkeleton
On Sat, Apr 03, 2021 at 10:37:33AM -0400, Neal Gompa wrote: > > If anything, I think it's a lot less common than it used to be. > When I started getting involved in Fedora in 2005, I didn't use my > real name either. I started using my real name a couple of years > afterward when I got comfortable with it. I've seen trends go back and > forth on this over the past 15 years. Agreed. In any case, when people show up in our community, let's welcome them, please, rather than starting off negative. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: some Fedora 34 feedback
On Sun, Mar 28, 2021 at 11:41:03PM -0400, u9000 (Nine) wrote: > > Never mind. I am retarded. > We all make mistakes :-) And along those lines... let's avoid using this word to refer to ourselves or anyone when we make mistakes. It's been used to disparage non-neurotypical people and those with learning difficulties or intellectual disabilities for far too long... there are other ways to say "oops". -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self-introduction: TheEvilSkeleton
On Sun, Mar 28, 2021 at 03:24:38PM +0200, Michael Schwendt wrote: > Where does this come from that people introduce themselves with > pseudonyms, aliases, usernames but no real name? If anything, I think it's a lot less common than it used to be. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self-introduction: TheEvilSkeleton
On Sat, Mar 27, 2021 at 12:15:13PM -0400, TheEvilSkeleton wrote: > as I can so I can contribute back what I've learned. I mostly > contribute to documentation, since it's one of the places where free > and open source software (FOSS) falls behind, but also because it's > where I am very good at. I also experiment; I play around a lot with > distributions, containers, VMs and more, hence me trying out many > Linux distributions in the past. I often break stuff because, well, > I play around things a lot and I'm very experimental. Hi and welcome! You may also want to take a look at the Fedora Docs team, and perhaps Fedora Magazine. > On a more personal note, I'm a 19 year old "student". I'm quoting > "student", since I stopped attending to classes because I couldn't > concentrate anymore due to stress and heavy pressure from college > because of COVID. Instead of doing nothing during the time, I > decided to join QA to contribute more to FOSS and collaborating with > people around the world, and be part of the Year of the Linux It takes some strength to know when you need a break, and it's great you've found this to be a productive and fulfilling place to put your effort. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: newbie question - Fedora 34
On Tue, Mar 23, 2021 at 11:04:36AM -0500, David wrote: > or are the current Beta versions just "test-Betas" ?? or "rc-Betas" for > in-house use only ? It is released. You should see an official email on the announcements list: https://lists.fedoraproject.org/archives/list/annou...@lists.fedoraproject.org/ and a post on Fedora Magazine: https://fedoramagazine.org/announcing-the-release-of-fedora-34-beta/ > Seems confusing. Why not do an public Alpha release, or at least a quite > Alpha release ? I'm not sure how this would reduce confusion. In the past, we did Alpha releases, but we generally found that the usage of them was quite low compared to the amount of effort it takes to produce and test them as release artifacts. Instead, we decided to put efforts towards making Rawhide continuously be at the quality level we previously expected for Alpha releases. > Linux users who have never used Fedora or have little experience with > Fedora need a better explanation as to what is so exciting about the 34 > release. Phoronix is only covering the highlights, but a few YouTubers are > explaining it, but they only do it in a virtual-machine for a very brief > install review. This really gets out of the scope of testing and into Mindshare, so I've CC'd that list. In addition to the Beta announcement, we also run Magazine articles like https://fedoramagazine.org/fedora-34-feature-focus-updated-activities-overview/, More would always be welcome, of course. > In my opinion, a good review would be to install on hardware and show > actual real-world work being done with Fedora 34, such as a drawing in > FreeCAD, and how the system differs from Manjaro Gnome 40, Gnome OS, Ubuntu > 20.10, etc. Yes, that would be great. I don't think we're going to do a comparative review as an official Fedora Project release — better to stand on our own merits and let others do the comparing — but I do always love to see videos and articles like this (at least, when some thought has been put into it rather than just being a listicle). -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Self-Introduction: Brady Pratt
On Tue, Mar 16, 2021 at 07:08:58AM -0500, Brady Pratt wrote: > My name is Brady Pratt, I'm newly working on a QE team within Red Hat and > want to get more involved with the Fedora community. I've been running > Linux full time for around 5 years now, my experience is mostly within the > Arch ecosystem so I am excited to branch out. Awesome -- welcome! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: External monitor via USB-C hub no longer works with F34
On Mon, Mar 08, 2021 at 02:00:23PM -0600, Richard Shaw wrote: > Have you tried running a F33 kernel? Good suggestion, and check out this weirdness: I booted into the last F33 kernel I had, and it still didn't work. Then I unplugged and re-plugged the USB-C connection, *which I had done before*, and the monitor appeared. Then, I rebooted back into the F34 kernel _and everything stayed working_. So that's weird. > Worst case you can downgrade because you made a btrfs snapshot first, > right? ;) No, no, I like to commit. :) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
External monitor via USB-C hub no longer works with F34
I have an Anker USB-C hub which also has HDMI out. (This one: https://www.anker.com/products/variant/usb-c-hub,-7in1-usb-c-adapter/A83460A1) This "Just Worked™" when I plugged it in with F33. I updated my laptop to Fedora Workstation 34 today, and discovered that the monitor no longer is recognized. If I move to the laptop's own HDMI port, it works, but the USB-C one no longer shows up. Any ideas what changed? -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Need help with btrfs.
On Wed, Mar 03, 2021 at 05:40:19PM -0800, Samuel Sieb wrote: > There are a few different types of full-disk backup, but if it's > file-based and the atimes are modified, that's the intent of the > backup process. The atimes are used to determine which files to > backup. A scrub is not a backup and shouldn't modify the atimes. I can't imagine why you would use atime instead of ctime for backups. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Need help with btrfs.
On Wed, Mar 03, 2021 at 12:13:33PM -0800, Samuel Sieb wrote: > It depends on how the scrubbing works. I would have expected it to > be reading data at the filesystem level, not actually opening and > reading every file. That seems like a really bad thing to me, > resetting the atimes on every file. I mean full-disk backup utilities do it all the time. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Need help with btrfs.
On Wed, Mar 03, 2021 at 04:57:28PM -0700, Chris Murphy wrote: > It works at the block level. A block is read, checksum calculated and > compared to the previously recorded checksum for the block. It doesn't > know what it's reading, not even whether it's compressed or not. It > just becomes a stream of blocks without respect to the file or > subvolume. If there's a mismatch, then it does a lookup to find out > the owner: what subvolume/snapshot and filename/inode, what offset, > and so on - which is then how it figures out where the good copy is > (if any) and does self-healing. It pretty much runs at device max read > capability. So given this, even with atimes there's only a write in the case where there's a mismatch, right? -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Need help with btrfs.
On Wed, Mar 03, 2021 at 11:56:58AM -0600, Richard Shaw wrote: > From what I can tell scrubbing only reads data and compares to the stored > checksum. Why would that wear out a SSD? If you have atimes enabled, reading a file also makes a metadata write. But I don't think it's that big a deal on modern drives. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: when to btrfs scrub, was: Need help with btrfs.
On Thu, Feb 25, 2021 at 09:25:04AM -0500, pmkel...@frontier.com wrote: > Scrub gives no indication that it's running other than the PID. Nor > does it indicate when it's complete; so I had to monitor the PID to > know when it was done. Then I had to run: > > sudo btrfs scrub status -dR /mnt > > to find the results. Do you know if anyone has some code that runs > scrub and gets the status and reports it after scrub is complete? Well, you get `BTRFS info (device nvme0n1p3): scrub: finished on devid 1 with status: 0` in the logs. So these things could be completely separate; one timer that runs the scrub, and one that looks for success or errors in the logs. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Need help with btrfs.
On Tue, Feb 23, 2021 at 10:18:13AM -0500, Neal Gompa wrote: > > > sudo btrfs scrub start /mnt > > It's kind of unfortunate that we also have a command (in the distro since > > 2007) called just "scrub" which will destroy al of your data. :-/ > > Not going to lie, it took three tries to read this to understand what > was being said here. :) Sorry, just... don't accidentally leave "btrfs" out of the above command. :) > We *do* have btrfsmaintenance[1] which provides what you're asking > for. However, we don't install it by default or have presets set up > for the timers. There were arguments for and against shipping and > enabling them by default[2]. Ah, thanks. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Need help with btrfs.
On Mon, Feb 22, 2021 at 02:58:00PM -0700, Chris Murphy wrote: > We should find out if there's more widespread corruption. The basic > command to scrub that particular Btrfs file system is: > > sudo btrfs scrub start /mnt It's kind of unfortunate that we also have a command (in the distro since 2007) called just "scrub" which will destroy al of your data. :-/ Anyway... do we have a timer which does this automatically on Fedora Linux systems, or are there plans to add one? Upstream wiki https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-scrub says "The user is supposed to run it manually or via a periodic system service. The recommended period is a month but could be less." -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Introduction to Test
On Sun, Feb 14, 2021 at 03:09:21PM -0500, Hugh Campbell via test wrote: > I’m looking forward to helping the Fedora team currently with QA/Testing > needs and in other areas as necessary. I’ve been an active Linux user since > 2001 and have used Fedora since Core 1 release. Outside of some > organizations requirements to use an enterprise Linux distribution such as > RHEL/CentOS for workstations (and a brief period of using Debian/Ubuntu as > a change of pace), Fedora has been my primary day-to-day driver for all my > systems at home and at work. Awesome! One other area you might find interesting and where your expertise would by welcome is the Fedora Security Team. This effort has been ... quiescent ... recently and there seems like there might be some energy around restarting it. If you're interested in that, it could certainly use your help! https://lists.fedoraproject.org/archives/list/security-t...@lists.fedoraproject.org/message/CN76VU6IWCHXN5ZLQFHGIL65DRCXA3F7/ -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
so.... how solid is the f34 branch at branch time?
Last few releases, I've aggressively updated my systems to the branch very shortly after branching, and I have (mostly) not regretted it. If I do that with F34 this week... how's it looking? -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: [External] Re: Respins for OEM preloads
On Tue, Jan 26, 2021 at 05:41:13PM -0500, Mohan Boddu wrote: > The image has been synced to > https://dl.fedoraproject.org/pub/alt/official-respins/ and the future > images will be available in the same location. If in case you need to > provide the image to your users, they can verify the image by the signed > checksum available in the above link as well. Hey Mohan, I notice the CHECKSUM file here is not readable. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rawhide (F34) Workstation drop 0128
On Thu, Feb 04, 2021 at 02:17:42PM -0700, Chris Murphy wrote: > worse than the cure. My concern are databases and VMs that don't shutdown > in time, including whether they will (or should) have a mechanism to > inhibit the reboot until they do properly shutdown. But so far there's not > much concern about this by anyone else :D and we'll just have to see if it > all works out in the end. I think giving them a chance is good, but really any software that you might run on a laptop or desktop needs to be robust against losing power or the system crashing at any moment. Clean shutdown is nice but can't be relied on. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rawhide (F34) Workstation drop 0128
On Mon, Feb 01, 2021 at 05:00:51PM -0500, pmkel...@frontier.com wrote: > This was done on my test machine: This was an attempted bare metal > install on a Lenovo M83 desktop with an i5-4570 CPU. The ISO was > check summed and passed Then the ISO was loaded to a thumb drive > using Media Writer. This was also successful. Does that same ISO work to boot a VM? -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Respins for OEM preloads
On Tue, Jan 19, 2021 at 09:20:54AM -0800, Adam Williamson wrote: > we do. If it's just a once-per-cycle thing, we could maybe just have > releng manually fire a post-release compose with a live image profile > in it, and I can manually schedule openQA tests for that compose. I actually have an unrelated use-case: we're getting some higher-end USB sticks for swag and I'd love to also put an updated image on those. If we can use the same one, that'd be super-extra bonus. It'd be kind of nice to wait for 5.8.10 to exit updates-testing but I'm not sure how that works with Mark's timeline. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Respins for OEM preloads
On Tue, Jan 19, 2021 at 11:12:29AM -0500, Neal Gompa wrote: > Is there a reason we can't make option 4 to be: officially create OEM > images and create an OEM preload guide? I don't personally know how > preloads work, even though I'm trying to figure out how to improve > "preloaded Fedora" experience over the next couple of cycles for > Fedora KDE. > > It might also make sense to make either monthly or quarterly > full recomposes with updates for downstreams with all the artifacts, > similar to how Microsoft used to do "rollup images" to support OEM > preloads. We totally _could_, if someone is willing to add that commitment to their workload. Depending on the scope (x86_64 Workstation only, say) it isn't *gigantic* but it's not like it's trivial. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Respins for OEM preloads
A large computer vendor with whom we have a friendly relationship would like to update the image they're shipping on their systems so that 1) new users don't have quite so many updates immediately and 2) auiu newer kernel helps with some upcoming things *vague vague handwavy vague*. I can think of four possibilities: 1. Sure, use the live-respins! 2. The live-respins are unofficial, but we have run [this specific workstation iso] through our standard validation tests and we recommend it for your use. 3. Use the netinstall and choose "apply updates" (or whatever that option is called) when making your distribution image. 4. Uh, sorry, we got nothin'. In all cases, they will run through their own internal testing and validation. And, because of calendar things, they'd really love an answer before the 26th of this month, which I know is short notice. Of the above, I think #2 is the best, but requires someone other than me to do significant work. So, I'm raising it here. :) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Rawhide F34 observation
On Wed, Jan 13, 2021 at 09:51:50AM -0500, pmkel...@frontier.com wrote: > While testing Rawhide F34 I have observed that the gnome-tweaks > application is missing the Extensions, Top Bar, and Workspaces > setting windows. Is this a bug of omission or are these settings > being removed or added to GCC? I don't see them in GCC. I expect that this is related to the upcoming GNOME redesign which affects these things. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: gate stable release critical path updates on openQA test results
On Thu, Jan 07, 2021 at 09:25:44AM -0800, Adam Williamson wrote: > So here's an idea I was thinking about over the RH shutdown: I propose > we gate stable release critical path updates on the openQA tests. YES. > But recently I was editing the Fedora greenwave config and realized > there's actually a simple solution: Bodhi can just make *different > greenwave queries* for critpath and non-critpath updates. We can have > alternate greenwave "decision contexts" for critpath and non-critpath > updates, and have the critpath one require passes for the openQA tests. > That solves the problem neatly, AFAICS. Nice! > I've been monitoring the update test results ever since we started > doing update testing, and I check *every* update test failure. > Sometimes there's a test system issue or a non-bug change that makes > the tests fail, and when that happens, I fix the problem and re-run the > tests. Where the failure is a real bug, I investigate it and file a > report to the appropriate place, then add a comment on the update > explaining the issue, usually with negative karma. So we've been doing > something similar to "gating" for years, just implemented manually :) Yeah, that's not a _great_ use of your time. Let's make the computer do it! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: criteria clarification: change HTTP to HTTP(S) and drop FTP in select criteria
On Tue, Jan 05, 2021 at 09:09:46AM +0100, Kamil Paral wrote: > I'd like to keep HTTP required to be working. Because of the stubbornness > with which some applications (like browsers) reject self-signed > certificates, some local use cases (including debugging and development) > are unnecessarily difficult. If you think HTTP(S) is unclear, I can reword > it as "HTTP and HTTPS". Is that better? I can live with that, but let's revisit in five years. :) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: criteria clarification: change HTTP to HTTP(S) and drop FTP in select criteria
On Mon, Jan 04, 2021 at 02:40:58PM +0100, Kamil Paral wrote: > To: "...must be able to use HTTP(S) repositories as package sources..." Let's drop the (S) and make it just HTTPS. With the parenthesis, I'm unclear if it means "http or https, whichever works" or "both http and https". And in 2021+, if there's a weird case where https works but plain http does not, the answer should be to fix it so http isn't needed. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: [Test Week] Fedora Kernel 5.10
On Sun, Jan 03, 2021 at 08:46:33PM +0100, Alessio wrote: > What about that story related to the drop in the Btrfs performances in > Kernel 5.10? Is it still true? Can we perform some specific test? Looks like a fix is on the way: https://marc.info/?l=linux-btrfs=160883350502962=2 It would be interesting to see if the performance regression is caught with `sudo ./runtests.sh -t performance` as part of the standard test day tests. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Do Fedora only keep latest package on repo? How to get verbose/debug output of dnf history
On Thu, Dec 31, 2020 at 12:20:35PM -0500, James Cassell wrote: > To make downgrade work, you can install the fedora-repos-archive package > and pass --enablerepo=fedora-archive when you attempt the downgrade/undo. Huh. Learn something every day. Thanks :) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Do Fedora only keep latest package on repo? How to get verbose/debug output of dnf history
On Thu, Dec 31, 2020 at 10:15:27AM +0800, Robbi Nespu wrote: > Do fedora only keep latest package version on repository? Yes, generally. You can get older packages from Koji, our build system, either by browsing the web interface https://koji.fedoraproject.org/koji/packageinfo?packageID=19055 or by using the `koji download-build` command. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: FC 34, broken glibc
On Fri, Dec 11, 2020 at 03:24:14PM +, George R Goffe wrote: > I have a fc31 live system booted and am looking for a statically linked > bash because chroot fails... no libgc. Sigh... The commands rpm and the > others rpm might run during an (re)install would probably need to be > statically linked in as well. You might be able to install busybox and get that to be helpful. But I don't think we have a statically-linked RPM anymore. Personally, I'd rsync /home to a backup device and reinstall the whole thing. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: FC 34, broken glibc
On Thu, Dec 10, 2020 at 08:55:11PM +, George R Goffe via test wrote: > Thanks VERY MUCH to everyone who helped with this. And thanks for undertaking the adventure of running Rawhide. :) We're looking at turning on some of the gating infrastructure we have in place but dormant to make it a little safer to do so in the future. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Release cadence and Editions [was Re: Fedora 34 Change: Make Fedora CoreOS a Fedora Edition (System-Wide Change)]
On Wed, Dec 02, 2020 at 12:15:21PM -0800, Adam Williamson wrote: > with quite a lot of consequences. It has consequences, for instance, > for our most important forms of communication to the wider world: how > do we pivot from this simple story that "Fedora is a (set of) > product(s) that come(s) out every six months, look out for our big > Fedora XX Release Announcements!" to "Fedora is that, but it's ALSO > this other thing that has three streams which release every two weeks > and roll over according to some completely other schedule"? And so on. I think some of this is helped by not thinking of Fedora as the OS itself, just like Red Hat isn't RHEL and RHEL isn't Red Hat. I mean, it doesn't solve any of your problems :) but it's a start towards getting people to think about it differently. I think this reads a lot more simply: Fedora is a project that has a set of deliverables that have traditionally been released every six months. We now have some deliverables that follow a different schedule. We're moving to a model where our main underlying software repository updates on the traditional six-month cadence, our various products will come with their own release announcements. Fedora Workstation, which is our most popular desktop offering, will stay on the familiar April/October release cadence. Silverblue, IoT, and CoreOS are examples of other Fedora operating system flavors that follow a rolling-release model instead. Our KDE Plasma Desktop follows the upstream KDE releases, which happen every four months, using the most-current Fedora software base at that time. [This last statement is obviously not true, but I'd like it to be a possiblity.] On the other hand, our Fedora School OS flavor [also not real] updates only once a year, at the end of May, so that school IT teams can deploy over the summer and not worry about upgrades until the next summer. Obviously there's some hard work to make that into a reality. But that's what I'd like to get to and it's basically what the Council decided we'd like a couple of years ago. (See below.) Right now, most of the press we get is around Fedora Workstation no matter what we do. (I have tried very hard to get press folks to talk about Fedora Server, Atomic, CoreOS, IoT, KDE and Xfce, SoaS, etc., etc., and I'm lucky if I get a line or two in an article.) If we want press around other offerings — desktop, or other use cases — it'll actually be _better_ to split them off so they're not overshadowed. > Good question! getfedora.org uses the concept, but doesn't define it. > So the authoritative source, I guess, is still > https://fedoraproject.org/wiki/Editions , which says "Fedora Editions > are curated sets of packages, guidelines and configuration, and > artifacts built from those pieces, that address a specific, targeted > use-case. The Editions are the primary Fedora outputs that most Fedora > users are encouraged to use and directed towards through the download > site." The latest official definition is in https://docs.fedoraproject.org/en-US/council/policy/guiding-policy/#_what_does_this_mean, which says: "Some solutions are the premier showcases that we call Editions; these are used in the gating tests for our releases." I'm not super-set on that, though, and would be open to some further evolution. For example, "gating tests for our releases" should probably be "for the twice-yearly Fedora rpm repository major-version releases" or something.¹ And, I think some element of this still is the key thing: we shouldn't do the general-repo release if it's not possible for the next release of an Edition to be based on it. This document is where we also said "Teams are free to define elements of their Solutions, such as intent, deliverables, and release cadence."² > Rawhide isn't an edition, which I think should be clear from the > definitions above. Rawhide is sort of the primordial soup from which > Editions and all else eventually emerges, I guess. :P I am totally up for renaming it to Fedora Primordial Soup. :) ... 1. I'm also open to having more or fewer things that are Editions, and finding new and better ways to let teams promote their not-labeled-as-edition outputs. 2. Put "release cadence" in bold for the purposes of this message. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: [PROPOSAL] No FEs X hours before Go/No Meeting
On Wed, Oct 28, 2020 at 12:46:55PM -0700, Adam Williamson wrote: > (mainly I) While I appreciate all of this taking-of-responsiblity and stuff, let's focus on the process. There are plenty of places where anyone can make decisions (or fail to consider something) and then in retrospect it was obviously the problem. Better to improve the process for the next time than to worry exactly who gets to have their name on whatever went wrong. Even if that improvement is "make sure to follow this existing rule" rather than the new one proposed. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
proposal: remove "opportunity to carry out other desirable work" from the Exceptional Cases considerations in the blocker bug SOP
In https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases, there is a list of factors we may consider when dealing with last minute or difficult to resolve blockers. One item on the list is: * Whether delaying the release may give us an opportunity to carry out other desirable work I would like to remove this from the list, and perhaps go so far as to include it as something we _shouldn't_ consider. There is always an infinite amount of desirable work, and it's tempting to push the schedule just to get one more thing in. But! Admiral Ackbar meme gif! that temptation is a trap! Any such additional work increases the risk of further delay, and actually pushes off getting all the other work that *did* make the release from getting to users. If something isn't ready, there is always the next release, and often there is the possibility of providing whatever other desirable work via an update -- or through an alternate module stream after the the release. What do you think? Reasonable? Thanks! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Self-introduction: Eric Lopez
On Wed, Oct 21, 2020 at 10:36:57AM -0600, Eric Lopez wrote: > I am interested in joining the QA team for Fedora. I would love to > contribute to my favorite operating system. Welcome Eric! We'd love to have your help and considerable expertise! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: a newbie question about Rawhide
On Thu, Oct 08, 2020 at 08:01:15PM -0500, David wrote: > I am excited to report that my Rawhide install finally borked, and now > I am faced with either trying to learn how to fix it, or starting over from > scratch. I love this attitude! > I had been away from my computer for about 24 hours, and my last memory > was that I shut it down before I left. The motel maids might have > inadvertently unplugged it in order to vacuum. I do not think I have any > automatic updates set up. Auto-applying updates on shutdown is now the default unless you uncheck it. So that's possibly what happened. > The problem appears to be simple. GDM is not working right. It displays my > full name instead of my username, and there is no place to click after I > type in the password. It does not recognize my password in GDM. Showing your full name is expected behavior if you have a full name configured in your passwd file. Can you hit enter? > In System Recovery, I can get to root, but I do not know how to fix things > there. Is that the same as the tty or is the system-recovery terminal a > different way of accessing the ways to fix it. If you can log in as root, my first approach woudl be to hit ctrl-alt-f6 to bring up a text terminal and 1. See if you can log in as yourself, and 2. If that doesn't work, log in as root, use the `passwd username` command to reset your password, and try step 1 again If that doesn't work, look in the log with journalctl -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Self-introduction: Siddharth Barhate
On Mon, Oct 05, 2020 at 12:10:34AM +0530, Siddharth Barhate wrote: > Hello everyone, > I am Siddharth Barhate from Pune, India. I am a linux enthusiast and have > been using linux for 3+ years. I am a Final Year Engineering student and > professionally working as DevOps Intern. I joined the Fedora project with > the purpose of "Giving back to the community". That's great! Welcome to Fedora! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Results from install of old drop of WS
On Mon, Jul 20, 2020 at 04:16:52PM -0400, pmkel...@frontier.com wrote: > Anyway from the discussion, I am under the impression that btrfs > uses compression by default for user's data files. If I am right > will there be a way to turn that off? It's still being discussed. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal to adjust final criterion for backgrounds
On Thu, Apr 16, 2020 at 12:30:07PM -0400, Neal Gompa wrote: > Well, you could check based on EVR of fedora-release. Stable release > is always has Release field bumped to 1, and unstable is below 1. True -- as long as people don't get the idea that this means that release candidates are final. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal to adjust final criterion for backgrounds
On Thu, Apr 16, 2020 at 08:18:27AM -0700, Adam Williamson wrote: > It kinda harks back to a time where we had more custom artwork, I think > - like boot splashes and stuff? I don't totally remember, but that was > basically it, at the time artwork was more than 'just' the desktop > background. These days it's really pretty much that... Yeah, boot splashes, and custom login theme. I don't know if this has been mentioned (thread parachute drop wheee!) but the plan going forward for the wallpaper is to land the next release's background in Rawhide right after the branch -- so, a Fedora 34 wallpaper should land mid-August. I love the idea of updating the logo extension to indicate Rawhide. It'd be nice for it also to indicate beta but I don't know how it could magically do that without without problematic gymnastics (or having it check something online, which has its own problems). -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: several Rawhide questions
On Tue, Apr 14, 2020 at 02:14:03AM -0500, David wrote: > Is it correct to say Rawhide updated today from version 33-0.3 to > 33-0.4, and what does that mean ? Rawhide is unversioned, so that's not correct. The fedora-release package version just indicates what OS # it will become. The package release # (in this case the 0.4) just indicates changes in the fedora-release package itself. It isn't meant to indicate anything about the distro as a whole. You can see these changes https://src.fedoraproject.org/rpms/fedora-release/commits/master. > I have only one gtk2 package on my system and it seems to be > related to the anaconda installer. > gtk2 version 2.24.32-7.fc32 > Is this package for those users not installing Gnome ? It's for whatever uses it. > Will it hurt to delete gtk2 if I am using the Gnome DE, or does > GIMP and other things need it ? I am using flatpaks for most > of my additional software. Well, try `sudo dnf remove gtk2` (and don't say yes) and you'll get a list of everything that would go away without it. On my system, it's a lot of packages I use (firefox, inkscape). > I assume the reason, that the backgrounds keep updating > in Rawhide ( yet remain identical to version 32 ), is simply due > to lack of man/woman-power. Right ? Basically. The plan going forward is to update the version in Rawhide shortly after the branch happens, so after F33 branches off in August (https://fedorapeople.org/groups/schedule/f-33/f-33-key-tasks.html), and Rawhide becomes future F34, we'll actually have the future F34 wallpaper in Rawhide. -- Matthew Miller Fedora Project Leader Not the Pope ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: How do we keep an eye on the CompNeuro Lab image's status?
On Thu, Feb 13, 2020 at 12:27:30PM -0800, Adam Williamson wrote: > > Sorry, very noob question: how would the NeuroFedora SIG keep up with > > the status of the CompNeuro Lab image? Could someone point me to the > > docs please, I wasn't able to find them on the wiki. > > > > I found it on Koji and realised that the image wasn't created because > > of some dependency errors, but it'll be nice if we can check on it > > regularly to ensure it keeps building. > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=41480869 > > You can follow tickets in failed-composes: > > https://pagure.io/releng/failed-composes/issues This gave me an idea. I found (thanks, Mohan!) the script that files these tickets -- it's https://pagure.io/releng/compose-tracker/. Mohan says that he has a plan to make it actually directly notify maintainers of failed composes (there's a ticket for it, even -- https://pagure.io/releng/compose-tracker/issue/4), but that's not done yet. In the meantime, you could do one of two things: 1. 'Watch' the issues in the failed-composes repo and then filter the resulting emails (procmail or whatever) to highlight what you care about 2. Clone and modify the script so instead of filing an issue there, it files one in the SIG's tracker, and only on a compose failure for the spin you care about. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Git forge requirements discussion
On Thu, Jan 23, 2020 at 04:02:42PM +0100, Kamil Paral wrote: > I don't think we have some very special requirements. For the planned > blocker review async discussion, we need API to be able to add comments and > edit the ticket description, ideally also adjust ticket tags, milestones or > some other properties. We need a webhook support to get notified of changes > or access to a message bus. Nothing unusual I think. Or, of course, native > support for voting/polls (ideally multiple per a single ticket) would be > even better :-) Can you put the voting/polls idea in the form of a user story? -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Self-introduction: Magnus Glantz
On Wed, Nov 13, 2019 at 12:02:03AM +0100, Magnus Glantz wrote: > I'm Magnus and I'm new here in the QA group. Swedish guy who's been > working with Linux/Open Source since about 2001. For a day job, I work > as a solution architect at Red Hat in the nordics with focus on RHEL > and things RHEL related, such as automation, containers, various > compute platforms, development, etc. > > I think I can help with triaging a bug or two, joining test days, > maybe improving some test cases and such. > > I'm setup with a Fedora account, BZ account and some will to help out :-) That's awesome -- welcome! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Stream
On Tue, Nov 12, 2019 at 10:32:05AM -0500, pmkel...@frontier.com wrote: > As time passes, my curiosity has grown concerning the realignment of > Redhat, Fedora, and CentOS. That seems good. But I'm not sure this is the right mailing list for it, unless you specifically mean in the context of testing and QA. > The article in Fedora Magazine didn't seem very definitive; > especially after RHEL 9. The article commentary seemed upbeat and > good. So I'm guessing all long time participants who are very > knowledgeable understand more details. I wrote the article, and I think I put most of what I know at a high level into it. I can provide more if you have specific questions. > Does anyone know if there is anything available or coming that will > help us who aren't so knowledgeable understand? I assume you also saw https://wiki.centos.org/Manuals/ReleaseNotes/CentOSStream? If not, does that help? If you did and it didn't help, what is missing? -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
[Test-Announce] Re: Fedora 31 Final is GO
On Thu, Oct 24, 2019 at 11:40:22AM -0400, Ben Cotton wrote: > For more information please check the Go/No-Go meeting minutes [2] or logs > [3]. > Thank you to everyone who has worked on this release and getting it out on > time. Yes! Special thinks to everyone who worked extra hard to make sure we ship a high quality release on time. It really does make a big difference to our users and to our reputation. -- Matthew Miller Fedora Project Leader ___ test-announce mailing list -- test-announce@lists.fedoraproject.org To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test-announce@lists.fedoraproject.org
Re: Dash to Dock
On Wed, Oct 02, 2019 at 03:56:20PM -0400, Matthew Miller wrote: >git checkout gnome-3.32 Sorry, this one shuld be git checkout master because there's not a released version that supports 3.34 yet. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Dash to Dock
On Wed, Oct 02, 2019 at 01:27:12PM -0600, Lawrence E Graves wrote: > When I go to gnome-tweaks and try to install it after doing what you > previously told me to do. It says error loading. Okay, let's try a few more things. All command-line -- sorry. Note that none of this is to be done as root or with sudo First: disable the extension (just to be sure): gnome-shell-extension-tool -d dash-to-d...@micxgx.gmail.com Now, we're going to remove the installed version. Be careful with this because it's an "rm -rf" command and a typo could delete something you don't mean. rm -rf ~/.local/share/gnome-shell/extensions/dash-to-d...@micxgx.gmail.com/ Now, we'll go back and reinstall the extension. We're going to do this from your Downloads directory just as a temporary working space. cd ~/Downloads rm -rf dash-to-dock git clone https://github.com/micheleg/dash-to-dock.git cd dash-to-dock git checkout gnome-3.32 make make install And then we'll re-enable from the command line: gnome-shell-extension-tool -e dash-to-d...@micxgx.gmail.com -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Dash to Dock
On Wed, Oct 02, 2019 at 12:21:55PM -0600, Lawrence E Graves wrote: > This is the results: ImportError: No JS module > 'dash-to-d...@micxgx.gmail.com' found in search path At what point do you get that error? -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Dash to Dock
On Wed, Oct 02, 2019 at 11:41:11AM -0600, Lawrence E Graves wrote: > >>trying to create, and it isn't empty, so it isn't going to overwrite it. > >>Just remove that directory and it should work. > >Note that this should be done in a code working space or temporary > >directory, not under ~/.local/share/gnome-shell/extensions. > > > >Assuming that you're in ~/code/ or whatever, it may be that you've simply > >already checked out dash-to-dock previously. In that case, simply change > >into that directory and do: > > > > git checkout master > > git pull > > make > > make install > > > This sounds good but I do not understand tech language, sorry. It needs to > be explain to me in good old fashion english. (getting to be a lost > language, smile) Type these commands exactly in order: cd dash-to-dock git checkout master git pull make make install Then, log out and log in again. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Dash to Dock
On Wed, Oct 02, 2019 at 10:03:28AM -0700, stan via test wrote: > > > git clone https://github.com/micheleg/dash-to-dock.git > > > fatal: destination path 'dash-to-dock' already exists and is not an > > > empty directory. > > This is the results of that. I have tried that several times and it > > doesn't work. > I think the error is saying that you already have the directory it is > trying to create, and it isn't empty, so it isn't going to overwrite it. > Just remove that directory and it should work. Note that this should be done in a code working space or temporary directory, not under ~/.local/share/gnome-shell/extensions. Assuming that you're in ~/code/ or whatever, it may be that you've simply already checked out dash-to-dock previously. In that case, simply change into that directory and do: git checkout master git pull make make install -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Dash to Dock
On Tue, Oct 01, 2019 at 02:43:53PM -0600, Lawrence E Graves wrote: > I am having a problem with "dash to dock in the extensions in Fedora > 31. It says there is a error in loading. Yeah, I don't think it's updated officially to be compatible with new GNOME. Follow instructions here: https://micheleg.github.io/dash-to-dock/download.html#installfromsource and it should work. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Self Introduction
On Sat, Sep 07, 2019 at 03:43:55PM -, SriramaKumar Vishnubhotla wrote: > Hello everyone! (*tips fedora*) > I'm alphaCar. Very glad to join the community :) > I'm a student with quite a modest experience with linux. I love linux and the > people working behind it. I'm hoping to submit bugs et al and hopefully learn > more of linux. Working more efficiently with linux helps a lot with > programming too, so I'm hoping this would help with my career too :) > Thanks a lot for reading this, nice to meet you all! Welcome to Fedora! Nice to have you here! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposing new release criteria
On Thu, Aug 29, 2019 at 11:45:44AM -0400, Dusty Mabe wrote: > Certainly anywhere where podman is shipped on media. Does podman ship in the > server DVD? yes [1] > It looks like workstation also ships it if I'm reading the logs [2] correctly. Yeah, it's needed for Toolbox, which is a vital feature for Silverblue but also one we want to encourage on general Workstation as well. Pretty sure it's also required for IoT. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Introduction
On Wed, Jul 31, 2019 at 06:36:01PM -0400, D L wrote: > My name is Danny Lee and I’m a recent adopter of Silverblue and am a big > fan. I’m also a long time unix/Linux user (starting around 1993), but > never taking it beyond a basic level. I have recently started to pick up > javascript and Ruby to strengthen my web development background. Also I’m > also interested in cloud computing, containerization, flatpack software; > QA is also an area that always fascinated me because I love to push all > the buttons and try all the switches. And I believe I’m pretty good at > describing what I’m seeing and what is going right (or wrong). I’m looking > to learn more about the QA process and how it works in an open source > project and am hoping I can make a contribution in time and effort. Thanks > for the opportunity and I I look forward to speaking/writing and learning > from you all. Hi Danny Lee, and welcome! Since Silverblue is a new thing, we definitely need an influx of new testers, so your involvement is very welcome! -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: proposal: drop optical media from release criteria
On Mon, Jul 08, 2019 at 09:02:12AM -0700, Adam Williamson wrote: > > Yes. In the midst of a home move, so I'll try to get to this ... soonish. If > > I don't, and you remember before I do, pleaes remind me :) > Ahoy Matt, this is your reminder :) After I get through all these flock talks! :) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Silverblue question
On Tue, Mar 05, 2019 at 05:24:03PM -0500, pmkel...@frontier.com wrote: > Is the intent that Silverblue will replace Workstation someday? That's the hope of that project, yes. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Drop most optional packages from Server DVD
On Mon, Feb 18, 2019 at 02:02:34PM -0500, Stephen John Smoogen wrote: > Then we are back to what Lukas brought up. What is the Server going to > have on it? I think the items he had were the ones most likely needed > out of the box: [...] > Otherwise we are back to 'nothing' as making more sense because > clearly they can get those from the internet and we don't need to ship > them. Package set isn't the only distinguishing thing, though. We also have install defaults (xfs vs ext4, for example) and presets for enabled services. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Drop most optional packages from Server DVD
On Mon, Feb 18, 2019 at 05:48:15PM +0100, Lukas Ruzicka wrote: > > servers also need security and bug fixes. > If so and local repository is always needed ... why keep a server spin > then? Why not install from Everything netinst? Lots of people use Fedora in a server context. If we don't have a server-focused deliverable, it's really easy for overall project decisions to lean too far towards desktop use cases and not provide a balanced venue. (See historical discussions on value of LVM in Fedora, for example.) -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Drop most optional packages from Server DVD
On Mon, Feb 18, 2019 at 11:43:46AM +0100, Lukas Ruzicka wrote: > Yes, I agree with the proposal. I also agree that most servers will be > connected to the Internet, however, I can think of some use cases where > Internet connection is not wanted and an intranet is sufficient, such as: In this case, I would expect that intranet to have a local mirror. Intranet servers also need security and bug fixes. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Proposal: Drop most optional packages from Server DVD
On Fri, Feb 15, 2019 at 10:49:00AM -0500, Stephen Gallagher wrote: > So I'd like to propose that we get rid of nearly the entirety of the > section from comps.xml[1][2] and variants-fedora.xml[3]. > The result will be a far smaller install DVD, less space wasted on the > mirrors (both for the DVD and the install tree) and very little > difference in user experience. +1 -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: RFC: DNF proposed Change submitted to FESCo
On Thu, Feb 14, 2019 at 08:25:42AM -0800, Adam Williamson wrote: > > [1] https://pagure.io/fesco/issue/2088 > > [2] https://fedoraproject.org/wiki/Changes/DNF_Default_Best > Personally I think I'm fine with this. (Though I might suggest that ' > --nobest' instead be called '--skip-broken' or at least have it as an > alias, since AFAICS this change makes DNF behave the way yum used to, > and --skip-broken was the name of yum's equivalent to "--nobest"...) That makes a lot of sense, yes. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Fedora infrastructure
On Wed, Jan 30, 2019 at 01:33:48PM -0500, pmkel...@frontier.com wrote: > applications or for fedora infrastructure. To use Pull Requests you > have to get set up with GitHub and clone the fedora stuff on your > PC. Then you pick something to work on. When you're at a point where > you what to at least get some comments on what you've done, you > submit a Pull Request. If I have this wrong or incomplete please > point me to where I should read more. That's essentially right, although the workflow is not limited to GitHub. It's also used by Pagure (used by Fedora at https://pagure.io and https://src.fedoraproject.org) and GitLab (used for example by upstream GNOME). > Then I got curious about infrastructure; so I started reading about > fedora infrastructure. From what I've read the infrastructure term > is used to refer to the servers, networks, and websites that all the > fedora teams use to accomplish their fedora related work. I also > thought this might include the various build, compose, test > procedures, and test software used, but that wasn't clear to me. If > I have this wrong or incomplete please point me to where I should > read more. This is basically right too, although in Fedora it's complicated because historically some bits of this were owned by Infrastructure and others by Release Engineering. We're working on consolidating that all into one team. > Then I read some about Tickets. From what I read, Tickets are the > vehicle used for report infrastructure bugs, problems or suggestions > for enhancement. From the e'mails I have seen on this list they also > seem to be used by teams to act as reminders for team members to do > things. To write or edit a Ticket Pagure seems to be used. I browsed > the projects in Pagure and you really need to know exactly which > project to use before you go there. If I have this wrong or > incomplete please point me to where I should read more. Yes, this is right too. Sorry -- it's a big project and so it's hard to avoid there being lots of different parts. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
Re: Spins testing and vanishing?
On Wed, Dec 05, 2018 at 11:23:25AM -0500, pmkel...@frontier.com wrote: > Today I see news that KDE is likely to fall off the Fedora table. I Red Hat isn't supporting KDE in some future RHEL versions. But they *already* don't support Xfce or SOAS or the other desktops you mention. This has no effect on Fedora. > I have a question, if I may: I have seen SoaS listed as Live and as > Live/Install. I down loaded it from the Fedora site. and I bought a > copy from OSDisk. They were both Live only. Does anyone know if > there is an install version? The Fedora live versions in general also come with an Install option (usually as an application). It's been awhile since I looked at SOAS but I imagine that's the case there too. -- Matthew Miller Fedora Project Leader ___ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org
