Re: F33 WS ISO checksum
On 10/28/20 11:21 AM, pmkel...@frontier.com wrote: I'm guessing that those extra lines are data needed by a process that sha256sum calls (perhaps gpg), but sha256sum doesn't use them directly. Otherwise I have no idea what their purpose is. Those lines have nothing to do with sha256sum. They are for *you* to verify that the checksums were provided by Fedora and haven't been modified. ___ 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, 2020-10-28 at 17:21 -0400, Ben Cotton wrote: > I don't blame you one bit here. Part of the issue with this policy is > enforcement. We have to trust maintainers to submit updates that will > meet it (and we should trust our maintainers!), but it can be hard to > tell until it's already in the compose. (In some cases, it's obvious, > but not all). The policy is good guidance, but I don't think it can > reasonably be an enforcement mechanism. The policy I proposed (as an > idea, mind you, not an endorsement) would provide a very heavy-handed > enforcement. > > It also takes the undue burden off of Adam to audit every FE. Many > times, the FE is approved before the fix is available, so it's hard > for voters to weigh in on whether or not the fix is reasonably-sized. One of my trademark nitpick-y process things here: technically speaking, FE status attaches to the *bug*, not the *fix*. A bug having FE status *allows* us to pull a fix for it through the freeze. It does not *require* us to do so. There is a kind of best-judgment filter applied at the push request stage: whoever's doing the push request (so, usually me again :>) can just choose to leave an update out. Whoever's *doing* the push (so, usually mboddu) can also question any item in it, and sometimes we talk them over before I send the request. This bit of the process is a bit 'hidden' because it really only involves two people, but it is pretty much there by design. There are other ways an update that is marked as fixing an FE can get left out, of course. It needs to be submitted for stable to be eligible for the stable push (though not for a candidate compose); negative karma can prevent that. There is a bit of fuzz here in that when the proposed fix for an FE is *already available* or at least roughly envisaged, that can feed into the process of reviewing it. This is, viewed very technically, a process violation, but humans being humans, we do it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://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
Re: [PROPOSAL] No FEs X hours before Go/No Meeting
On Wed, Oct 28, 2020 at 3:48 PM Adam Williamson wrote: > > On Wed, 2020-10-28 at 12:29 -0400, Ben Cotton wrote: > > In yesterday's F33 emergency brake meeting[1], one of the issues that > > came up is the short window for testing all of the different IoT > > hardware. One way to reduce that effort (by extending the window) is > > reducing the change set in the days before an RC. I don't know if it > > would have helped in this particular case, as the kernel update that > > caused some of the problems had security fixes, so we may have left it > > in anyway. But the general idea is if we don't allow FEs all the way > > up to the RC compose, we reduce the number of things that could break. > > > > I don't know if I personally endorse this proposal or not, but in the > > interests of open discussion, I am proposing a change to the freeze > > exception process: > > > > > Updates with an accepted Freeze Exceptions will not be included less than > > > X hours before the scheduled start of the Go/No-Go Meeting. > > > > I left the time unspecified for now, because we should figure out if > > we like the general concept before we decide on the specific deadline. > > I was thinking something like 72 hours (3 days), which would put the > > deadline at 1700 UTC Monday. > > > > For simplicity's sake, I'm only sending this to the QA list now. If we > > have a general consensus on it being a good thing, we should > > distribute it more broadly before we adopt it. > > I don't think I agree with this Big o'l same. > There is actually a policy that updates to fix blocker and FE issues > should include the minimal change necessary to fix the bug. We (mainly > I) have gotten progressively laxer about enforcing that in the last few > years, to the point where I rarely actually bother with it at all > except in super egregious cases. This is because we've kinda got a > better track record of updates not breaking stuff, and we have much > better test coverage than we used to. > I don't blame you one bit here. Part of the issue with this policy is enforcement. We have to trust maintainers to submit updates that will meet it (and we should trust our maintainers!), but it can be hard to tell until it's already in the compose. (In some cases, it's obvious, but not all). The policy is good guidance, but I don't think it can reasonably be an enforcement mechanism. The policy I proposed (as an idea, mind you, not an endorsement) would provide a very heavy-handed enforcement. It also takes the undue burden off of Adam to audit every FE. Many times, the FE is approved before the fix is available, so it's hard for voters to weigh in on whether or not the fix is reasonably-sized. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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: F33 WS ISO checksum
On Wed, Oct 28, 2020 at 12:22 PM pmkel...@frontier.com wrote: > > > > On 10/28/20 11:44, Ankur Sinha wrote: > > On Wed, Oct 28, 2020 11:21:07 -0400, pmkel...@frontier.com wrote: > >> Are you saying that the warning message about the 19 lines is a don't care > >> or is their a problem with the way the checksum file is made? Does this > >> mean > >> that the OK message that comes first is in error? > > > > I guess you could call it a "don't care". That isn't completely accurate > > though---sha256sum cares about all lines in the file, but if it they > > don't fit the format it can understand it skips them and tells the > > user. The format is explained in the man page: `man sha256sum`. It finds > > the one line it does understand, uses it to verify the ISO and prints > > "OK". > > > > This is all expected. So, there is nothing wrong with the CHECKSUM file, > > and there's nothing wrong with the output. > > > > Try the GPG related steps listed here. Those are what the PGP signature > > in the CHECKSUM file is for. > > https://getfedora.org/en/security/ > > > > I'm guessing that those extra lines are data needed by a process that > sha256sum calls (perhaps gpg), but sha256sum doesn't use them directly. > Otherwise I have no idea what their purpose is. Step 2 at the above URL: Now, verify that the CHECKSUM file is valid: -- 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
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
Re: [PROPOSAL] No FEs X hours before Go/No Meeting
On Wed, 2020-10-28 at 12:29 -0400, Ben Cotton wrote: > In yesterday's F33 emergency brake meeting[1], one of the issues that > came up is the short window for testing all of the different IoT > hardware. One way to reduce that effort (by extending the window) is > reducing the change set in the days before an RC. I don't know if it > would have helped in this particular case, as the kernel update that > caused some of the problems had security fixes, so we may have left it > in anyway. But the general idea is if we don't allow FEs all the way > up to the RC compose, we reduce the number of things that could break. > > I don't know if I personally endorse this proposal or not, but in the > interests of open discussion, I am proposing a change to the freeze > exception process: > > > Updates with an accepted Freeze Exceptions will not be included less than X > > hours before the scheduled start of the Go/No-Go Meeting. > > I left the time unspecified for now, because we should figure out if > we like the general concept before we decide on the specific deadline. > I was thinking something like 72 hours (3 days), which would put the > deadline at 1700 UTC Monday. > > For simplicity's sake, I'm only sending this to the QA list now. If we > have a general consensus on it being a good thing, we should > distribute it more broadly before we adopt it. I don't think I agree with this, but I *do* think I handled this badly in the specific case we're referring to. So, what happened here is: * We had an accepted FE bug for a Bluetooth CVE (security) issue: https://bugzilla.redhat.com/show_bug.cgi?id=1888439 * A kernel update marked as fixing that bug was submitted on 2020-10-15 and submitted for stable later the same day. I submitted a stable push request including that update the next day, and it was pushed. 2020-10- 16 was exactly a week before the Final Go/No-Go meeting, so this update was in stable for a week before Go/No-Go: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ce117eff51 https://pagure.io/releng/issue/9725#comment-696530 * The kernel update first appeared in a compose validation event on 2020-10-19, only four days before Go/No-Go, because there was no nightly validation event between 2020-10-16 and RC 1.2, which was built on 2020-10-19. * The update did not just fix the Bluetooth CVE: it was actually an *entire kernel patch version update*, from 5.8.14 to 5.8.15. There is actually a policy that updates to fix blocker and FE issues should include the minimal change necessary to fix the bug. We (mainly I) have gotten progressively laxer about enforcing that in the last few years, to the point where I rarely actually bother with it at all except in super egregious cases. This is because we've kinda got a better track record of updates not breaking stuff, and we have much better test coverage than we used to. However, that was obviously the problem in this case. We (mainly I) pulled in what was actually a fairly big change (new kernel release) quite late in the process when we could have insisted on a smaller change (just the CVE fix patch on top of 5.8.14), didn't include it in a candidate compose until even later in the process, and didn't flag it up as a significant change that needed testing. That's on me and I apologize for it. (For the record, I didn't consciously consider this and decide it wasn't a big deal; I actually just kinda blew through the stable push request quickly, I don't recall why, and didn't *notice* we were pulling in an entire kernel release bump. Obviously, part of that is the above note that I've been getting generally laxer about checking this; a few years back I used to rigorously check how much change was in every single proposed blocker/FE update, nowadays I kinda...don't.) So I don't think we really need a new rule here, we (mainly I) just need to go back to being more careful about the policy we already have. What should have happened here is I should have noticed we had an entire kernel version update proposed as the fix for an FE and talked to the kernel team about it. We could then either have decided to pull in the update, but make sure it was properly tested, including flagging it up to the ARM folks and making sure we had time to test it across the important ARM platforms; or we could have decided to not pull in 5.8.15 and instead do 5.8.14 with a patch for the CVE. All of that is what *should have happened under the current rules*, and I just whiffed it. Again I'm sorry for that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://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
Re: F33 WS ISO checksum
On 10/28/20 11:44, Ankur Sinha wrote: On Wed, Oct 28, 2020 11:21:07 -0400, pmkel...@frontier.com wrote: Are you saying that the warning message about the 19 lines is a don't care or is their a problem with the way the checksum file is made? Does this mean that the OK message that comes first is in error? I guess you could call it a "don't care". That isn't completely accurate though---sha256sum cares about all lines in the file, but if it they don't fit the format it can understand it skips them and tells the user. The format is explained in the man page: `man sha256sum`. It finds the one line it does understand, uses it to verify the ISO and prints "OK". This is all expected. So, there is nothing wrong with the CHECKSUM file, and there's nothing wrong with the output. Try the GPG related steps listed here. Those are what the PGP signature in the CHECKSUM file is for. https://getfedora.org/en/security/ I'm guessing that those extra lines are data needed by a process that sha256sum calls (perhaps gpg), but sha256sum doesn't use them directly. Otherwise I have no idea what their purpose is. Have a Great Day! Pat (tablepc) ___ 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 10:31 AM Ben Cotton wrote: > > In yesterday's F33 emergency brake meeting[1], one of the issues that > came up is the short window for testing all of the different IoT > hardware. One way to reduce that effort (by extending the window) is > reducing the change set in the days before an RC. I don't know if it > would have helped in this particular case, as the kernel update that > caused some of the problems had security fixes, so we may have left it > in anyway. But the general idea is if we don't allow FEs all the way > up to the RC compose, we reduce the number of things that could break. > > I don't know if I personally endorse this proposal or not, but in the > interests of open discussion, I am proposing a change to the freeze > exception process: > > > Updates with an accepted Freeze Exceptions will not be included less than X > > hours before the scheduled start of the Go/No-Go Meeting. I pretty much already take this position the week before the go/no-go, and then turn into pretty much a hard ass once we slip. There has to be a very compelling reason to grant a freeze exception. The kernel is difficult because stable updates can bring important fixes as well as regressions, and that's just the way it is. The only way around it is for Fedora's kernel to take an older stable kernel and cherry pick some fixes, which will work for some things and not others. Are we able to allow different kernel versions for different archs? What about different media? Or do they all get the same kernel version? Pretty sure it's the latter which makes this harder. -- 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
Re: F33 WS ISO checksum
On Wed, 28 Oct 2020 11:21:07 -0400, pmkel...@frontier.com wrote: > Are you saying that the warning message about the 19 lines is a don't > care or is their a problem with the way the checksum file is made? Does > this mean that the OK message that comes first is in error? Just display the checksum file and see. It's a text file, which only contains a single line recognized by the checksum tool, and it is that line that matters. You may also run "sha256sum -w -c ..." on that file to enable more verbose warnings about the lines the tools doesn't recognize. ___ 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
Fedora-IoT-33-20201028.0 compose check report
No missing expected images. Failed openQA tests: 1/16 (x86_64) New failures (same test not failed in Fedora-IoT-33-20201020.0): ID: 708917 Test: x86_64 IoT-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/708917 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-33-20201020.0): ID: 708905 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/708905 Passed openQA tests: 14/16 (x86_64) Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default_upload: Mount /run contents changed to 156.3760807% of previous size 2 services(s) added since previous compose: systemd-repart.service, zram-swap.service 2 services(s) removed since previous compose: parsec.service, systemd-resolved.service System load changed from 0.21 to 0.08 Previous test data: https://openqa.fedoraproject.org/tests/702689#downloads Current test data: https://openqa.fedoraproject.org/tests/708906#downloads Installed system changes in test x86_64 IoT-dvd_ostree-iso install_default@uefi: Mount /run contents changed to 156.5201729% of previous size 3 services(s) added since previous compose: dbxtool.service, systemd-repart.service, zram-swap.service 2 services(s) removed since previous compose: parsec.service, systemd-resolved.service Previous test data: https://openqa.fedoraproject.org/tests/702691#downloads Current test data: https://openqa.fedoraproject.org/tests/708908#downloads -- 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
[PROPOSAL] No FEs X hours before Go/No Meeting
In yesterday's F33 emergency brake meeting[1], one of the issues that came up is the short window for testing all of the different IoT hardware. One way to reduce that effort (by extending the window) is reducing the change set in the days before an RC. I don't know if it would have helped in this particular case, as the kernel update that caused some of the problems had security fixes, so we may have left it in anyway. But the general idea is if we don't allow FEs all the way up to the RC compose, we reduce the number of things that could break. I don't know if I personally endorse this proposal or not, but in the interests of open discussion, I am proposing a change to the freeze exception process: > Updates with an accepted Freeze Exceptions will not be included less than X > hours before the scheduled start of the Go/No-Go Meeting. I left the time unspecified for now, because we should figure out if we like the general concept before we decide on the specific deadline. I was thinking something like 72 hours (3 days), which would put the deadline at 1700 UTC Monday. For simplicity's sake, I'm only sending this to the QA list now. If we have a general consensus on it being a good thing, we should distribute it more broadly before we adopt it. [1] https://meetbot.fedoraproject.org/fedora-meeting-2/2020-10-27/emergency-brakes-on-f33-release.2020-10-27-13.41.html -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ 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: F33 keyboard problems
no idea regarding CINNAMON. under Genome: - Settings => "Region & Languages" => "Input Source" => "+" - delete the US keyboard - logoff/-on ? ? ___ 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: F33 WS ISO checksum
On Wed, Oct 28, 2020 11:21:07 -0400, pmkel...@frontier.com wrote: > Are you saying that the warning message about the 19 lines is a don't care > or is their a problem with the way the checksum file is made? Does this mean > that the OK message that comes first is in error? I guess you could call it a "don't care". That isn't completely accurate though---sha256sum cares about all lines in the file, but if it they don't fit the format it can understand it skips them and tells the user. The format is explained in the man page: `man sha256sum`. It finds the one line it does understand, uses it to verify the ISO and prints "OK". This is all expected. So, there is nothing wrong with the CHECKSUM file, and there's nothing wrong with the output. Try the GPG related steps listed here. Those are what the PGP signature in the CHECKSUM file is for. https://getfedora.org/en/security/ -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ 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: F33 WS ISO checksum
On 10/28/20 11:07, Ankur Sinha wrote: On Wed, Oct 28, 2020 10:55:28 -0400, pmkel...@frontier.com wrote: On 10/28/20 10:16, Ankur Sinha wrote: I think sha256sum is pointing out the 19 lines related to the PGP Signature in the CHECKSUM file, which it can't understand. https://getfedora.org/static/checksums/Fedora-Workstation-33-1.2-x86_64-CHECKSUM Perhaps the CHECKSUM files were not previously signed. Thanks for your reply. The checksum file you sent gives the same OK and Warning results as above; Yes, it also includes the 19 lines for the PGP signature, which sha256sum doesn't understand. So, this is expected. Are you saying that the warning message about the 19 lines is a don't care or is their a problem with the way the checksum file is made? Does this mean that the OK message that comes first is in error? Have a Great Day! Pat (tablepc) ___ 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: F33 WS ISO checksum
On Wed, Oct 28, 2020 10:55:28 -0400, pmkel...@frontier.com wrote: > On 10/28/20 10:16, Ankur Sinha wrote: > > > > > I think sha256sum is pointing out the 19 lines related to the PGP > > Signature in the CHECKSUM file, which it can't understand. > > > > https://getfedora.org/static/checksums/Fedora-Workstation-33-1.2-x86_64-CHECKSUM > > > > Perhaps the CHECKSUM files were not previously signed. > > > > > > Thanks for your reply. The checksum file you sent gives the same OK and > Warning results as above; Yes, it also includes the 19 lines for the PGP signature, which sha256sum doesn't understand. So, this is expected. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ 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: F33 WS ISO checksum
On 10/28/20 10:16, Ankur Sinha wrote: On Wed, Oct 28, 2020 09:32:51 -0400, pmkel...@frontier.com wrote: I wanted a fresh copy of the F33 ISO to use for the PCs I maintain. I went to the getfedora.org site. and downloaded the ISO and CHECKSUM files for F33 Workstation. When I run: sha256sum -c Fedora-Workstation-live-33-1;2-x86_64-CHECKSUM I get: Fedora-Workstation-live-x86_64-33-1.2.iso: OK But right under that I get: she256sum: WARNING: 19 lines are improperly formatted I went back to koji and downloaded the files for 1.2 that I originally got for testing 1.2. When I ran the check sum I got the same warning, but I did not get the worning when I originally downloaded 1.2 for testing. What's up? Is their a new bug in sha256sum -c? I think sha256sum is pointing out the 19 lines related to the PGP Signature in the CHECKSUM file, which it can't understand. https://getfedora.org/static/checksums/Fedora-Workstation-33-1.2-x86_64-CHECKSUM Perhaps the CHECKSUM files were not previously signed. Thanks for your reply. The checksum file you sent gives the same OK and Warning results as above; Have a Great Day! Pat (tablepc) ___ 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: F33 WS ISO checksum
On Wed, Oct 28, 2020 09:32:51 -0400, pmkel...@frontier.com wrote: > I wanted a fresh copy of the F33 ISO to use for the PCs I maintain. I went > to the getfedora.org site. and downloaded the ISO and CHECKSUM files for F33 > Workstation. > > When I run: > > sha256sum -c Fedora-Workstation-live-33-1;2-x86_64-CHECKSUM > > I get: > > Fedora-Workstation-live-x86_64-33-1.2.iso: OK > > But right under that I get: > she256sum: WARNING: 19 lines are improperly formatted > > I went back to koji and downloaded the files for 1.2 that I originally got > for testing 1.2. When I ran the check sum I got the same warning, but I did > not get the worning when I originally downloaded 1.2 for testing. > > What's up? Is their a new bug in sha256sum -c? I think sha256sum is pointing out the 19 lines related to the PGP Signature in the CHECKSUM file, which it can't understand. https://getfedora.org/static/checksums/Fedora-Workstation-33-1.2-x86_64-CHECKSUM Perhaps the CHECKSUM files were not previously signed. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ 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
F33 WS ISO checksum
I wanted a fresh copy of the F33 ISO to use for the PCs I maintain. I went to the getfedora.org site. and downloaded the ISO and CHECKSUM files for F33 Workstation. When I run: sha256sum -c Fedora-Workstation-live-33-1;2-x86_64-CHECKSUM I get: Fedora-Workstation-live-x86_64-33-1.2.iso: OK But right under that I get: she256sum: WARNING: 19 lines are improperly formatted I went back to koji and downloaded the files for 1.2 that I originally got for testing 1.2. When I ran the check sum I got the same warning, but I did not get the worning when I originally downloaded 1.2 for testing. What's up? Is their a new bug in sha256sum -c? Have a Great Day! Pat ___ 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
Fedora-Rawhide-20201028.n.0 compose check report
Missing expected images: Xfce raw-xz armhfp Compose FAILS proposed Rawhide gating check! 7 of 43 required tests failed, 1 result missing openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 35/181 (x86_64) New failures (same test not failed in Fedora-Rawhide-20201027.n.0): ID: 708557 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/708557 ID: 708558 Test: x86_64 Server-dvd-iso install_vncconnect_server URL: https://openqa.fedoraproject.org/tests/708558 ID: 708559 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/708559 ID: 708560 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/708560 ID: 708561 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/708561 ID: 708568 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/708568 ID: 708575 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/708575 ID: 708578 Test: x86_64 Server-dvd-iso server_role_deploy_database_server **GATING** URL: https://openqa.fedoraproject.org/tests/708578 ID: 708584 Test: x86_64 Server-dvd-iso server_database_client **GATING** URL: https://openqa.fedoraproject.org/tests/708584 ID: 708601 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/708601 ID: 708603 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/708603 ID: 708673 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/708673 ID: 708676 Test: x86_64 universal install_blivet_resize_lvm URL: https://openqa.fedoraproject.org/tests/708676 ID: 708684 Test: x86_64 universal install_resize_lvm URL: https://openqa.fedoraproject.org/tests/708684 ID: 708697 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/708697 ID: 708716 Test: x86_64 universal install_pxeboot URL: https://openqa.fedoraproject.org/tests/708716 ID: 708717 Test: x86_64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/708717 ID: 708735 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/708735 Old failures (same test failed in Fedora-Rawhide-20201027.n.0): ID: 708582 Test: x86_64 Server-dvd-iso server_cockpit_default **GATING** URL: https://openqa.fedoraproject.org/tests/708582 ID: 708586 Test: x86_64 Server-dvd-iso server_freeipa_replication_master URL: https://openqa.fedoraproject.org/tests/708586 ID: 708590 Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING** URL: https://openqa.fedoraproject.org/tests/708590 ID: 708591 Test: x86_64 Server-dvd-iso server_freeipa_replication_replica URL: https://openqa.fedoraproject.org/tests/708591 ID: 708592 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart **GATING** URL: https://openqa.fedoraproject.org/tests/708592 ID: 708594 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/708594 ID: 708615 Test: x86_64 Workstation-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/708615 ID: 708621 Test: x86_64 KDE-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/708621 ID: 708632 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/708632 ID: 708633 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/708633 ID: 708634 Test: x86_64 KDE-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/708634 ID: 708638 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/708638 ID: 708666 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/708666 ID: 708687 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/708687 ID: 708701 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/708701 ID: 708709 Test: x86_64 universal upgrade_realmd_client URL: https://openqa.fedoraproject.org/tests/708709 ID: 708728 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/708728 Soft failed openQA tests: 3/181 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Rawhide-20201027.n.0): ID: 708576 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/708576 ID: 708616 Test: x86_64 Workstation-live-iso desktop_printing URL: https://op
Fedora rawhide compose report: 20201028.n.0 changes
OLD: Fedora-Rawhide-20201027.n.0 NEW: Fedora-Rawhide-20201028.n.0 = SUMMARY = Added images:67 Dropped images: 0 Added packages: 6 Dropped packages:0 Upgraded packages: 150 Downgraded packages: 0 Size of added packages: 3.92 MiB Size of dropped packages:0 B Size of upgraded packages: 4.62 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 51.62 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20201028.n.0.iso Image: Everything boot x86_64 Path: Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-Rawhide-20201028.n.0.iso Image: Server raw-xz armhfp Path: Server/armhfp/images/Fedora-Server-Rawhide-20201028.n.0.armhfp.raw.xz Image: Server_Appliance raw-xz armhfp Path: Server/armhfp/images/Fedora-Server-armhfp-Rawhide-20201028.n.0-sda.raw.xz Image: Server dvd aarch64 Path: Server/aarch64/iso/Fedora-Server-dvd-aarch64-Rawhide-20201028.n.0.iso Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20201028.n.0.ppc64le.tar.xz Image: Mate raw-xz armhfp Path: Spins/armhfp/images/Fedora-Mate-armhfp-Rawhide-20201028.n.0-sda.raw.xz Image: Everything boot armhfp Path: Everything/armhfp/iso/Fedora-Everything-netinst-armhfp-Rawhide-20201028.n.0.iso Image: Silverblue dvd-ostree aarch64 Path: Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20201028.n.0.iso Image: Python_Classroom vagrant-libvirt x86_64 Path: Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-Rawhide-20201028.n.0.x86_64.vagrant-libvirt.box Image: KDE live x86_64 Path: Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20201028.n.0.iso Image: Server boot aarch64 Path: Server/aarch64/iso/Fedora-Server-netinst-aarch64-Rawhide-20201028.n.0.iso Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20201028.n.0.iso Image: LXDE live x86_64 Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20201028.n.0.iso Image: Python_Classroom raw-xz armhfp Path: Labs/armhfp/images/Fedora-Python-Classroom-armhfp-Rawhide-20201028.n.0-sda.raw.xz Image: Cloud_Base qcow2 s390x Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20201028.n.0.s390x.qcow2 Image: Workstation live x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20201028.n.0.iso Image: Games live x86_64 Path: Labs/x86_64/iso/Fedora-Games-Live-x86_64-Rawhide-20201028.n.0.iso Image: Workstation_Appliance raw-xz armhfp Path: Workstation/armhfp/images/Fedora-Workstation-armhfp-Rawhide-20201028.n.0-sda.raw.xz Image: Cloud_Base tar-gz x86_64 Path: Cloud/x86_64/images/Fedora-Cloud-Base-GCP-Rawhide-20201028.n.0.x86_64.tar.gz Image: Server dvd x86_64 Path: Server/x86_64/iso/Fedora-Server-dvd-x86_64-Rawhide-20201028.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20201028.n.0.s390x.tar.xz Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20201028.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20201028.n.0.iso Image: Server dvd s390x Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20201028.n.0.iso Image: Container_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Base-Rawhide-20201028.n.0.aarch64.tar.xz Image: Server dvd armhfp Path: Server/armhfp/iso/Fedora-Server-dvd-armhfp-Rawhide-20201028.n.0.iso Image: Minimal raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Minimal-Rawhide-20201028.n.0.aarch64.raw.xz Image: Xfce live x86_64 Path: Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-Rawhide-20201028.n.0.iso Image: Server boot s390x Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20201028.n.0.iso Image: Everything boot ppc64le Path: Everything/ppc64le/iso/Fedora-Everything-netinst-ppc64le-Rawhide-20201028.n.0.iso Image: Server boot armhfp Path: Server/armhfp/iso/Fedora-Server-netinst-armhfp-Rawhide-20201028.n.0.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20201028.n.0.iso Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20201028.n.0-sda.raw.xz Image: Cloud_Base qcow2 aarch64 Path: Cloud/aarch64/images/Fedora-Cloud-Base-Rawhide-20201028.n.0.aarch64.qcow2 Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20201028.n.0.aarch64.tar.xz Image: Container_Base docker x86_64 Path: Container/x86_64/images/Fedora-Container-Base-Rawhide-20201028.n.0.x86_64.tar.xz Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20201028.n.0.iso Image: Container_Base docker s390x Path: Container/s390x/images/Fedora-Container-Base-Rawhide-20201028.n.0.s390x.tar.xz Image: Container_Base docker armhfp Path: Container/armhfp/images
Fedora-Cloud-31-20201028.0 compose check report
No missing expected images. Passed openQA tests: 7/7 (x86_64) -- 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
F33 keyboard problems
Hi guys, I upgraded almost successfully from F32 to F33, using dnf. Before the upgrade action, my Keyboard was German, with no deadkeys as option, in all Fedora versions. But now, each time I logout and relogin, my keyboard is reset to an STD US keyboard. Is this a known issue? I am running as desktop a CINNAMON desktop. How can I get rid from this problem? KInd regards Joachim Backes -- Fedora release 33 (Thirty Three) Kernel-5.9.1-300.fc33.x86_64 Joachim Backes https://www-user.rhrk.uni-kl.de/~backes/ ___ 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
Fedora-Cloud-33-20201028.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-33-20201027.0): ID: 708386 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/708386 Passed openQA tests: 6/7 (x86_64) -- 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
