Fedora-Cloud-33-20211109.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20211108.0): ID: 1057767 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1057767 ID: 1057774 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1057774 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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: new criterion proposal: Graphical package managers
On Mon, Nov 8, 2021 at 11:39 AM Kamil Paral wrote: > > On Mon, Nov 8, 2021 at 4:28 PM Chris Murphy wrote: >> >> https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality >> >> "Basic functionality means that the app must at least be broadly >> capable of its most basic expected operations, and that it must not >> crash without user intervention or with only basic user intervention." >> >> a. I take "basic functionality" as a compound noun, equivalent to >> "fundamental purpose". >> b. If the package manager has a reproducible crash, it's a blocker. >> I'm having difficulty parsing the double negative above. Does it means >> "it may crash with non-basic user intervention"? > > > Yes, I believe it says that. > >> >> I have no idea how to >> categorize basic and non-basic interventions. > > > With much difficulty, that's why we're having this thread :-) > >> >> >> Insofar as this applies to GNOME Software and KDE Discover, anything a >> GUI application lets a user do, is in the course of achieving its >> fundamental purpose. I'd say any bug that is not a cosmetic bug is a >> release blocking bug for these components, when the problem is >> experienced on a release blocking desktops. > > > "anything a GUI application lets a user do" is a potential trap. You can > submit app ratings in gnome-software, and I'm quite sure we don't want to > block the release on that. That's why I proposed an exact list. When installing, removing, or updating software? If I click an install button, the selected app should be installed or it's a blocking bug. Same for removal, same for updating. If it lets you click install for multiple programs in sequence, they should all be successfully installed. If that's not possible, then don't let users queue up multiple programs for installation. I agree that if it crashes when submitting app ratings, I'd consider it cosmetic. -- Chris Murphy ___ 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: Persistence through Sleep for Mounted LUKS Encrypted USB devices
On Sat, Nov 6, 2021 at 1:00 PM Onyeibo wrote: > > Greetings, > > My laptop enters a sleep state when I close the lid (monitor). That is > normal. > > However, if I mounted a LUKS-encrypted device connected via a USB port, > the session breaks when the machine wakes. Is that still normal? BASH > tells me that the mount point is engaged, whereas the device has been > relabelled (from /dev/sdc to /dev/sdd or something else). The "lsblk" > command indicates that the device is not mounted anymore. Of course, > that disrupts any process accessing the USB storage device when I close > the lid. > > The troubling part is that the mount point stays busy as though it is > mounted. Trying to umount is futile (umount: /mnt/usb: target is > busy.). How do I break out of this? I still ask, Is this the design, > or should I be reporting a bug? > > Regards > Onyeibo > > -- > uname -a: > > 5.15.0-0.rc6.47.fc36.x86_64 #1 SMP Mon Oct 18 17:11:29 UTC 2021 x86_64 > x86_64 x86_64 GNU/Linux It's a good question. I know that /dev device nodes are not reliable between boots. But between suspend (s2idle or S3) modes it should be? But that's a question for kernel developers, and I guess the place to start this is on the linux-usb@ list and see if /dev is supposed to be consistent through suspend-to-ram. -- Chris Murphy ___ 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
Thank you for your response Matthew.
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.
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.
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'll try to take the discussion to FESCo.
PS really appreciate the work you guys do.
On 9/11/21 07:21, Matthew Miller wrote:
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).
--
*Rick Marshall*
Zenucom - where it all started
Unibase - database and language
Uniquote - ERP
LinkedIn
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
Fedora-IoT-36-20211108.0 compose check report
Missing expected images: Iot dvd aarch64 Iot dvd x86_64 Failed openQA tests: 3/16 (x86_64), 2/15 (aarch64) New failures (same test not failed in Fedora-IoT-36-20211027.0): ID: 1056905 Test: x86_64 IoT-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1056905 ID: 1056906 Test: aarch64 IoT-dvd_ostree-iso install_default_upload@uefi URL: https://openqa.fedoraproject.org/tests/1056906 ID: 1056920 Test: x86_64 IoT-dvd_ostree-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/1056920 Old failures (same test failed in Fedora-IoT-36-20211027.0): ID: 1056875 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1056875 ID: 1056895 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1056895 Skipped non-gating openQA tests: 26 of 31 -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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] Fedora-IoT 36 RC 20211108.0 nightly compose nominated for testing
Announcing the creation of a new nightly release validation test event for Fedora-IoT 36 RC 20211108.0. Please help run some tests for this nightly compose if you have time. For more information on nightly release validation testing, see: https://fedoraproject.org/wiki/QA:Release_validation_test_plan Test coverage information for the current release can be seen at: https://openqa.fedoraproject.org/testcase_stats/36iot You can see all results, find testing instructions and image download locations, and enter results on the Summary page: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_36_RC_20211108.0_Summary The individual test result pages are: https://fedoraproject.org/wiki/Test_Results:Fedora-IoT_36_RC_20211108.0_General Thank you for testing! -- Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer ___ 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 Sun, 2021-11-07 at 15:46 -0500, Matthew Miller wrote: > 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. 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. > > > > * 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_. :) 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. > > 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? 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... > > Also: although this isn't a change to Fedora Linux... maybe I should run > this through the Changes process? Hmm, I dunno if that'd help or just add bureaucracy, really. > > > * 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". I don't really care a lot. I think the purpose of the page is pretty clear with either title, including the current one. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net ___ 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: new criterion proposal: Graphical package managers
On Mon, Nov 8, 2021 at 4:28 PM Chris Murphy wrote: > > https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality > > "Basic functionality means that the app must at least be broadly > capable of its most basic expected operations, and that it must not > crash without user intervention or with only basic user intervention." > > a. I take "basic functionality" as a compound noun, equivalent to > "fundamental purpose". > b. If the package manager has a reproducible crash, it's a blocker. > I'm having difficulty parsing the double negative above. Does it means > "it may crash with non-basic user intervention"? Yes, I believe it says that. > I have no idea how to > categorize basic and non-basic interventions. > With much difficulty, that's why we're having this thread :-) > > Insofar as this applies to GNOME Software and KDE Discover, anything a > GUI application lets a user do, is in the course of achieving its > fundamental purpose. I'd say any bug that is not a cosmetic bug is a > release blocking bug for these components, when the problem is > experienced on a release blocking desktops. > "anything a GUI application lets a user do" is a potential trap. You can submit app ratings in gnome-software, and I'm quite sure we don't want to block the release on that. That's why I proposed an exact list. ___ 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: new criterion proposal: Graphical package managers
On Mon, Nov 8, 2021 at 3:26 PM Frantisek Zatloukal wrote: > > >> "dnf install foo; dnf install bar" >> > > This is equivalent to: > > 1. Open Graphical package manager > 2. Install foo > 3. Close Graphical package manager > 4. Open Graphical package manager > 5. Install bar > 6. Close Graphical package manager > Or perhaps I could counter this with: gnome-software = bash (running the whole time), dnf = packagekit (performing one operation at a time). And then I'd use some even more absurd and nonsensical analogy :-) Let's... not continue in this fruitless comparison. My original purpose was to compare the tools focusing on the end result, and of course assuming they are used in the manner in which they are *intended* to be used. Which, for a CLI tool, is obviously a CLI-based approach, and for a GUI tool, a GUI-based approach (which includes interactivity and concurrency, if it allows it, as is usual for GUIs). > > >> >> And I'm going to go down the rabbit hole even more. How is scheduling >> another install different from e.g. listing installed packages or available >> updates? If the user starts installation of package A, and then switches to >> the Installed or Updates tab in gnome-software (which executes a >> *concurrent* packagekit operation), and then the whole thing breaks, do we >> also say "you naughty human being, you shouldn't have clicked that, even if >> we allowed you to" and not block on it? >> > > I don't do this, I've never seen anyone (with or without a technical > background) do this. All the users I've seen do is to wait until something > finishes and then switch to other tabs/sections, etc. Again, I am not > saying this isn't happening, all I am saying it's not blocker material, in > my opinion. > OK. I disagree that the deciding factor here should be "I don't think people use it often". I think it should be a combination of "how often people do it" and "what impact it has if it breaks". We don't know how often people do it, we only have personal experience, and we clearly won't agree on that. Perhaps we can agree at least that it's not something esoteric that would only a couple of power users know about (perhaps like "dnf shell"). But the second part is more important for me here. With a package manager, the impact can be serious system damage. That overrides the "people might not use it often" part, at least for me. Let's see what others think. ___ 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: new criterion proposal: Graphical package managers
On Mon, Nov 8, 2021 at 10:50 AM John Mellor wrote: > > On 2021-11-08 9:31 a.m., Neal Gompa wrote: > > On Mon, Nov 8, 2021 at 9:25 AM Frantisek Zatloukal > > wrote: > >> On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral wrote: > >>> "dnf install foo bar" > >> This is a single operation, comparable to having multiple packages > >> installed via graphical package manager, not scheduling multiple > >> operations at once. It would be the same If a graphical package manager > >> offered to select multiple packages/applications and then start the > >> transaction. > >> > >> "dnf install foo; dnf install bar" > >> This is equivalent to: > >> 1. Open Graphical package manager > >> 2. Install foo > >> 3. Close Graphical package manager > >> 4. Open Graphical package manager > >> 5. Install bar > >> 6. Close Graphical package manager > >> > >> dnfdragora supports doing install + upgrade + removal in the same > >> transaction. This is equivalent to using "dnf shell" to construct a > >> transaction in the CLI. > >> > >> It is technically possible to do this with PackageKit too, but neither > >> Discover nor Software expose this as far as I know. > > Did I miss something in this thread? Given that the current Gnome > graphical package manager requires a full and expensive reboot in > between every install for virtually every package for mostly-defective > reasons, how would you actually install two packages sequentially like > that? Are you suggesting that the current and IMHO > poorly-thought-through package manager be finally replaced? If so, > hoorah!!! > No. We are not suggesting it. I am merely explaining what's possible. Note that Discover *does* let you turn off offline updates if you wish, though we default to offline updates. Even with online updates, Discover and Software do not let you select multiple actions before executing it. > I'm all for stealing the code from tracer or the Ubuntu installer to > identify what needs restarting, and maybe putting out a flag to prevent > bug submissions while the running packages are not up-to-date. I > believe that would completely eliminate the mandatory reboots, and allow > the package manager to move forward properly. We will *not* change the default back to online updates for Discover or Software. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: new criterion proposal: Graphical package managers
On 2021-11-08 9:31 a.m., Neal Gompa wrote: On Mon, Nov 8, 2021 at 9:25 AM Frantisek Zatloukal wrote: On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral wrote: "dnf install foo bar" This is a single operation, comparable to having multiple packages installed via graphical package manager, not scheduling multiple operations at once. It would be the same If a graphical package manager offered to select multiple packages/applications and then start the transaction. "dnf install foo; dnf install bar" This is equivalent to: 1. Open Graphical package manager 2. Install foo 3. Close Graphical package manager 4. Open Graphical package manager 5. Install bar 6. Close Graphical package manager dnfdragora supports doing install + upgrade + removal in the same transaction. This is equivalent to using "dnf shell" to construct a transaction in the CLI. It is technically possible to do this with PackageKit too, but neither Discover nor Software expose this as far as I know. Did I miss something in this thread? Given that the current Gnome graphical package manager requires a full and expensive reboot in between every install for virtually every package for mostly-defective reasons, how would you actually install two packages sequentially like that? Are you suggesting that the current and IMHO poorly-thought-through package manager be finally replaced? If so, hoorah!!! I'm all for stealing the code from tracer or the Ubuntu installer to identify what needs restarting, and maybe putting out a flag to prevent bug submissions while the running packages are not up-to-date. I believe that would completely eliminate the mandatory reboots, and allow the package manager to move forward properly. ___ 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: new criterion proposal: Graphical package managers
https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Default_application_functionality "Basic functionality means that the app must at least be broadly capable of its most basic expected operations, and that it must not crash without user intervention or with only basic user intervention." a. I take "basic functionality" as a compound noun, equivalent to "fundamental purpose". b. If the package manager has a reproducible crash, it's a blocker. I'm having difficulty parsing the double negative above. Does it means "it may crash with non-basic user intervention"? I have no idea how to categorize basic and non-basic interventions. Insofar as this applies to GNOME Software and KDE Discover, anything a GUI application lets a user do, is in the course of achieving its fundamental purpose. I'd say any bug that is not a cosmetic bug is a release blocking bug for these components, when the problem is experienced on a release blocking desktops. I'd be OK distinguishing between two categories: bugs with a documented workaround are OK for beta; but only cosmetic bugs are OK for final. Also, a suitable error message indicating that a requested action can't be completed, along with a hint for an alternative course of action, requires a high burden to make the error a blocker bug (not impossible but it's a higher bar than just silently failing, crashing, or leaving the system in some disfunctional in between state). If some offered functionality doesn't work, fix it or rip it out. -- Chris Murphy ___ 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
Fedora-Rawhide-20211108.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 24 of 43 required tests failed, 17 results missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 67/141 (aarch64), 108/206 (x86_64) New failures (same test not failed in Fedora-Rawhide-20211107.n.0): ID: 1056297 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1056297 ID: 1056580 Test: aarch64 Server-dvd-iso install_blivet_btrfs_preserve_home_uefi@uefi URL: https://openqa.fedoraproject.org/tests/1056580 Old failures (same test failed in Fedora-Rawhide-20211107.n.0): ID: 1056099 Test: x86_64 Server-dvd-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1056099 ID: 1056102 Test: x86_64 Server-dvd-iso install_repository_hd_variation URL: https://openqa.fedoraproject.org/tests/1056102 ID: 1056142 Test: x86_64 Everything-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/1056142 ID: 1056144 Test: x86_64 Everything-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/1056144 ID: 1056145 Test: x86_64 Workstation-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1056145 ID: 1056153 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1056153 ID: 1056169 Test: x86_64 KDE-live-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1056169 ID: 1056171 Test: x86_64 KDE-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/1056171 ID: 1056191 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help URL: https://openqa.fedoraproject.org/tests/1056191 ID: 1056229 Test: aarch64 Server-dvd-iso anaconda_help@uefi URL: https://openqa.fedoraproject.org/tests/1056229 ID: 1056310 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1056310 ID: 1056311 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1056311 ID: 1056314 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1056314 ID: 1056328 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/1056328 ID: 1056354 Test: x86_64 universal upgrade_desktop_64bit URL: https://openqa.fedoraproject.org/tests/1056354 ID: 1056355 Test: x86_64 universal upgrade_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/1056355 ID: 1056363 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/1056363 ID: 1056366 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/1056366 ID: 1056378 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/1056378 ID: 1056381 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/1056381 ID: 1056383 Test: aarch64 universal upgrade_2_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1056383 ID: 1056385 Test: aarch64 universal upgrade_2_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1056385 ID: 1056405 Test: aarch64 universal upgrade_server_domain_controller@uefi URL: https://openqa.fedoraproject.org/tests/1056405 ID: 1056410 Test: aarch64 universal upgrade_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1056410 ID: 1056418 Test: aarch64 universal upgrade_desktop_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1056418 ID: 1056420 Test: aarch64 universal upgrade_2_desktop_encrypted_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1056420 ID: 1056430 Test: aarch64 universal upgrade_desktop_encrypted_64bit@uefi URL: https://openqa.fedoraproject.org/tests/1056430 ID: 1056431 Test: aarch64 universal upgrade_2_realmd_client@uefi URL: https://openqa.fedoraproject.org/tests/1056431 ID: 1056432 Test: x86_64 Everything-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1056432 ID: 1056433 Test: x86_64 Server-boot-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1056433 ID: 1056434 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1056434 ID: 1056435 Test: aarch64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/1056435 ID: 1056436 Test: x86_64 KDE-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1056436 ID: 1056437 Test: x86_64 Server-dvd-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/1056437 ID: 1056438 Test: x86_64 Server-dvd-iso install_standard_partition_ext4@uefi URL: https://openqa.fedoraproject.org/tests/1056438 ID: 1056439 Test: aarch64 universal
Re: new criterion proposal: Graphical package managers
On Mon, Nov 8, 2021 at 9:25 AM Frantisek Zatloukal wrote: > > > > On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral wrote: >> >> "dnf install foo bar" > > > This is a single operation, comparable to having multiple packages installed > via graphical package manager, not scheduling multiple operations at once. It > would be the same If a graphical package manager offered to select multiple > packages/applications and then start the transaction. > >> >> "dnf install foo; dnf install bar" > > > This is equivalent to: > > 1. Open Graphical package manager > 2. Install foo > 3. Close Graphical package manager > 4. Open Graphical package manager > 5. Install bar > 6. Close Graphical package manager > dnfdragora supports doing install + upgrade + removal in the same transaction. This is equivalent to using "dnf shell" to construct a transaction in the CLI. It is technically possible to do this with PackageKit too, but neither Discover nor Software expose this as far as I know. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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: new criterion proposal: Graphical package managers
On Mon, Nov 8, 2021 at 3:05 PM Kamil Paral wrote: > "dnf install foo bar" > This is a single operation, comparable to having multiple packages installed via graphical package manager, not scheduling multiple operations at once. It would be the same If a graphical package manager offered to select multiple packages/applications and then start the transaction. > "dnf install foo; dnf install bar" > This is equivalent to: 1. Open Graphical package manager 2. Install foo 3. Close Graphical package manager 4. Open Graphical package manager 5. Install bar 6. Close Graphical package manager > It depends on what your definition of an operation is. But in both cases, > I don't see a functional difference between these and a user clicking on > the Install button for foo and bar in the graphical package manager. > > Doing a single installation, waiting for it to finish, then doing another >> is something you can do with dnf and something that I'd block on with >> graphical package managers. >> > > And yet you voted for a RejectedBlocker just a few weeks back: > https://pagure.io/fedora-qa/blocker-review/issue/560 > dnf exits after transaction finish, so it's equivalent to a workaround that was possible for that blocker proposal. Also, I might've added that I'd block on this once we agree on proper criterions ;) > > If you changed your mind, great :-) > > >> Scheduling multiple tasks without waiting for them to finish one by one >> is something that I am against blocking on. >> > > What purpose does it make to punish users for something they can't know? > They don't know that they should wait for the first operation to finish, > and only then click on the next button. This way they are safer, because > they are within the path we block on (if we used your definition). So why > do we even allow them, *tempt them* to be able to click a different button > in the meantime? Shouldn't we push on developers to prevent simultaneous > button clicking? > Are users doing this? I don't think so, you think they do. We don't have any data we can use to say which way it is used. Nothing prevents you from testing this path and reporting bugs and working with the devs on solving it, even if it isn't a blocking path. > > And I'm going to go down the rabbit hole even more. How is scheduling > another install different from e.g. listing installed packages or available > updates? If the user starts installation of package A, and then switches to > the Installed or Updates tab in gnome-software (which executes a > *concurrent* packagekit operation), and then the whole thing breaks, do we > also say "you naughty human being, you shouldn't have clicked that, even if > we allowed you to" and not block on it? > I don't do this, I've never seen anyone (with or without a technical background) do this. All the users I've seen do is to wait until something finishes and then switch to other tabs/sections, etc. Again, I am not saying this isn't happening, all I am saying it's not blocker material, in my opinion. -- Best regards / S pozdravem, František Zatloukal Quality Engineer Red Hat ___ 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: new criterion proposal: Graphical package managers
On Thu, Nov 4, 2021 at 3:02 PM Frantisek Zatloukal wrote: > On Thu, Nov 4, 2021, 11:40 Kamil Paral wrote: > >> I'm not sure if you understood it correctly (or if I even expressed it >> correctly). The operations are of course executed sequentially, always >> (that's how our package managers work). But they can be *scheduled* >> concurrently, i.e. you can install GIMP, and before it is downloaded and >> installed, you can also schedule installation of Inkscape. I think this is >> not an unusual use case, to schedule several operations at once. E.g. I >> just installed a new system and want to install my favorite applications. >> Or I decided that I want to play a different game, so I hit Install on >> OpenArena and also click Remove on SuperTuxKart. >> >> Is this really what you are against, or have you understood it >> differently? I can try to phrase it better. >> > > Yeah I understood it correctly. I am not saying it's not a valid use case, > just that I don't think that it's a common enough use case to be made > blocking. > I replied to Ben regarding this, please read that response, thanks. > > See my response above. Imagine that we'd ensure only the first dnf >> operation works correctly, but any later one can blow up. Why would we want >> to allow that with a graphical package manager? >> > > You can't schedule multiple dnf operations at once. > "dnf install foo bar" "dnf install foo; dnf install bar" It depends on what your definition of an operation is. But in both cases, I don't see a functional difference between these and a user clicking on the Install button for foo and bar in the graphical package manager. Doing a single installation, waiting for it to finish, then doing another > is something you can do with dnf and something that I'd block on with > graphical package managers. > And yet you voted for a RejectedBlocker just a few weeks back: https://pagure.io/fedora-qa/blocker-review/issue/560 If you changed your mind, great :-) > Scheduling multiple tasks without waiting for them to finish one by one is > something that I am against blocking on. > What purpose does it make to punish users for something they can't know? They don't know that they should wait for the first operation to finish, and only then click on the next button. This way they are safer, because they are within the path we block on (if we used your definition). So why do we even allow them, *tempt them* to be able to click a different button in the meantime? Shouldn't we push on developers to prevent simultaneous button clicking? And I'm going to go down the rabbit hole even more. How is scheduling another install different from e.g. listing installed packages or available updates? If the user starts installation of package A, and then switches to the Installed or Updates tab in gnome-software (which executes a *concurrent* packagekit operation), and then the whole thing breaks, do we also say "you naughty human being, you shouldn't have clicked that, even if we allowed you to" and not block on it? I'm making fun of it a little. But overall, graphical apps are (and supposed to be) interactive, which demands a different approach in certain areas. In a file manager, would you also argue that the user must not click anything until a file operation is finished? In picture viewer, that a photo can't be advanced until the current one if fully loaded? In a web browser, that a tab can't be switched until the webpage is fully loaded? You'll say "but that's much more common". Yes, perhaps. But at the same time, a package manager working correctly is probably the most important one of all of that. So it's not just about the common paths (many of our criteria aren't). ___ 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: new criterion proposal: Graphical package managers
On Thu, Nov 4, 2021 at 2:19 PM Ben Cotton wrote: > On Thu, Nov 4, 2021 at 6:12 AM Kamil Paral wrote: > > > > "Multiple operations" is one of the reasons for proposing this > criterion. In this release, and previous releases, we often had a bug that > you can install a package, but then you can't remove it. But if you > restarted the package manager, or your session, then it worked. And people > said "well, both install and remove work, you just can't use them together, > so... it's fine according to the criteria!". That's why I list it > explicitly as blocking Final. I don't think it's fine. > > > I guess my question comes down to is this something The Average User™ > does, or is it just something that Kamil does because he's really good > at QA? If it's the former, then I'm in favor of your proposal. > > > Another scenario could be when you hit Install on app A, and before it > is done, you hit install on app B. Imagine if the first operation would get > stopped abruptly. The same argument could be used as above (which is a real > argument, not a made-up one). Again, that's why I mention it explicitly. > > > I see that as being a different case from the above, and I would > definitely support blocking on that behavior. The only thing that > should abruptly stop a transaction is the user hitting a cancel > button. So while I'm still unclear about the first part, I'm totally > on board with this part. > I find it hard to draw the line somewhere between all these cases. So aborting a previous operation is not ok, but not even starting a second operation is ok? Installing and removing the same package is not blocking? What about installing two different packages, would that block? What about installing A and removing B? I don't honestly think it's a good idea to dig into the million of sub-cases here. Just imagine we're not talking about the package manager but a file manager instead. If you could either create a file, or remove a file, but you couldn't create the file, or you couldn't remove 2 different either sequentially or together, that would clearly be a blocker (I hope). It would be quite obvious that this is a basic functionality. So why isn't this a basic functionality for the package manager? And why do we have (it seems) a different quality bar for dnf vs graphical package managers? I don't think these bugs would be waived for dnf. I can't speak for the mythical average user, but yes, I believe performing multiple operations in a single session is quite common. Like installing 2 different applications. Or to provide a real-world example, my father likes to play some chess. And so he searches gnome-software for "chess", installs the first app in the result list. He doesn't like it much, so he removes it and installs the second one. I really don't buy that this is not a common enough scenario (replying to Frantisek here as well). Actually, the fact that gnome-software has been so broken in the past, forced my father to learn some dnf commands. Last week, a non-IT colleague in the office asked me "what the magical command to update the system was, once more?" because gnome-software was stuck again. I personally don't use gnome-software on my home computer, ever. One reason is that I prefer to be in control and see all the text output of dnf, but the second reason is that I don't trust it enough. And I don't think it's ok. I consider gnome-software and PackageKit (it's hard to separate the two and point fingers exactly) to be one of the biggest problems in Fedora Workstation. They are *very* unreliable for the end user, and their problems are extremely hard to debug and almost impossible to reproduce for power users like us. If we don't attempt to improve the situation, it won't. And if we keep saying that it's ok to not be able to install and remove a package in the same session, then I believe Fedora is only suitable for people who don't rely on these tools, like you, or me, or probably most people in this discussion. But not for others. (To be clear, I don't want to belittle all the work that gnome-software/packagekit developers have done in the past. Especially this cycle, we squashed many gnome-software related bugs, and Milan, the main developer, has been very helpful and active. I'm just stating the fact that graphical package management is unfortunately what I see as the most unreliable part of our desktop). > > >> We should clarify this to something like "list software installed from > >> managed repositories". The wording probably needs help, but the idea > > What about: > > * list locally-installed software coming from the official Fedora > repositories > > ? > Well, I think we'd want it to work for other repositories too (like > Flathub, rpmfusion, etc). But there's a case for keeping the criterion > limited to just the official repos because if something fails because > a third-party repo does something weird, that's out of our control. So > I guess this wording works if only to
Fedora rawhide compose report: 20211108.n.0 changes
OLD: Fedora-Rawhide-20211107.n.0 NEW: Fedora-Rawhide-20211108.n.0 = SUMMARY = Added images:0 Dropped images: 0 Added packages: 0 Dropped packages:1 Upgraded packages: 86 Downgraded packages: 0 Size of added packages: 0 B Size of dropped packages:5.82 MiB Size of upgraded packages: 2.90 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 7.08 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = = ADDED PACKAGES = = DROPPED PACKAGES = Package: feedreader-2.11.0-4.fc35 Summary: RSS desktop client RPMs:feedreader Size:5.82 MiB = UPGRADED PACKAGES = Package: antlr4-project-4.9.3-1.fc36 Old package: antlr4-project-4.9.2-3.fc35 Summary: Parser generator (ANother Tool for Language Recognition) RPMs: antlr4 antlr4-cpp-runtime antlr4-cpp-runtime-devel antlr4-doc antlr4-maven-plugin antlr4-runtime antlr4-runtime-test-annotation-processors antlr4-runtime-test-annotations golang-antlr4-runtime-devel nodejs-antlr4 python3-antlr4-runtime swift-antlr4-runtime Size: 9.18 MiB Size change: 786.32 KiB Changelog: * Sun Nov 07 2021 Jerry James - 4.9.3-1 - Version 4.9.3 - Drop upstreamed -unicode-properties and -utf8cpp patches Package: bluez-5.62-2.fc36 Old package: bluez-5.62-1.fc36 Summary: Bluetooth utilities RPMs: bluez bluez-cups bluez-deprecated bluez-hid2hci bluez-libs bluez-libs-devel bluez-mesh bluez-obexd Size: 10.79 MiB Size change: 12.00 KiB Changelog: * Sun Nov 07 2021 Adam Williamson - 5.62-2 - Revert an upstream change to fix problems with Logitech MX mice (#2019970) Package: bpython-0.22-1.fc36 Old package: bpython-0.21-3.fc35 Summary: Fancy curses interface to the Python interactive interpreter RPMs: python3-bpython python3-bpython-urwid Size: 343.21 KiB Size change: 10.02 KiB Changelog: * Sun Nov 07 2021 Terje Rosten - 0.22.0-1 - 0.22.0 Package: calc-2.14.0.6-1.fc36 Old package: calc-2.14.0.3-1.fc36 Summary: Arbitrary precision arithmetic system and calculator RPMs: calc calc-devel calc-libs calc-stdrc Size: 5.57 MiB Size change: 5.74 KiB Changelog: * Sun Nov 07 2021 Matthew Miller 2.14.0.6-1 - update to 2.14.0.6 experimental release Package: clamav-0.103.4-1.fc36 Old package: clamav-0.103.3-9.fc36 Summary: End-user tools for the Clam Antivirus scanner RPMs: clamav clamav-data clamav-devel clamav-filesystem clamav-lib clamav-milter clamav-update clamd Size: 233.53 MiB Size change: 9.51 MiB Changelog: * Sun Nov 07 2021 S??rgio Basto - 0.103.4-1 - Update to 0.103.4 Package: collectd-5.12.0-12.fc36 Old package: collectd-5.12.0-11.fc36 Summary: Statistics collection daemon for filling RRD files RPMs: collectd collectd-amqp collectd-amqp1 collectd-apache collectd-ascent collectd-bind collectd-ceph collectd-chrony collectd-curl collectd-curl_json collectd-curl_xml collectd-dbi collectd-disk collectd-dns collectd-drbd collectd-email collectd-generic-jmx collectd-gps collectd-hugepages collectd-infiniband collectd-ipmi collectd-iptables collectd-ipvs collectd-java collectd-log_logstash collectd-lua collectd-mcelog collectd-mdevents collectd-memcachec collectd-modbus collectd-mysql collectd-netlink collectd-nginx collectd-notify_desktop collectd-notify_email collectd-nut collectd-onewire collectd-openldap collectd-ovs_events collectd-ovs_stats collectd-pinba collectd-ping collectd-postgresql collectd-python collectd-redis collectd-rrdcached collectd-rrdtool collectd-sensors collectd-smart collectd-snmp collectd-snmp_agent collectd-synproxy collectd-utils collectd-varnish collectd-virt collectd-web collectd-write_http collectd-write_kafka collectd-write_mongodb collectd-write_prometheus collectd-write_redis collectd-write_riemann collectd-write_sensu collectd-write_syslog collectd-write_tsdb collectd-xencpu collectd-zookeeper libcollectdclient libcollectdclient-devel perl-Collectd Size: 10.76 MiB Size change: 30.62 KiB Changelog: * Sun Nov 07 2021 Bj??rn Esser - 5.12.0-12 - Rebuild (riemann-c-client) Package: community-mysql-8.0.27-2.fc36 Old package: community-mysql-8.0.27-1.fc36 Summary: MySQL client programs and shared libraries RPMs: community-mysql community-mysql-common community-mysql-devel community-mysql-errmsg community-mysql-libs community-mysql-server community-mysql-test Size: 1.17 GiB Size change: -97.68 KiB Changelog: * Sun Nov 07 2021 Mamoru TASAKA - 8.0.27-2 - rebuild for new protobuf Package: coolreader-3.2.59-1.fc36 Old package: coolreader-3.2.54-2.fc35 Summary: Cross platform open source e-book reader RPMs: coolreader Size: 12.98 MiB Size change: 1.03 MiB Changelog: * Sun Nov 07 2021 Andy Mender - 3.2.59-1 - Bump version to 3.2.59 - Add new build
Fedora-IoT-35-20211108.0 compose check report
No missing expected images. Failed openQA tests: 1/15 (aarch64) Old failures (same test failed in Fedora-IoT-35-20211101.0): ID: 1055901 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi URL: https://openqa.fedoraproject.org/tests/1055901 Soft failed openQA tests: 1/16 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-IoT-35-20211101.0): ID: 1055881 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/1055881 Passed openQA tests: 15/16 (x86_64), 14/15 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
Fedora-Cloud-34-20211108.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-34-20211107.0): ID: 1055871 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1055871 ID: 1055872 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1055872 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
Fedora-Cloud-35-20211108.0 compose check report
No missing expected images. Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-35-20211107.0): ID: 1055854 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/1055854 ID: 1055855 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi URL: https://openqa.fedoraproject.org/tests/1055855 Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ 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
