Hi folks! I'm proposing we cancel the QA meeting tomorrow. It's a
vacation day for Red Hat in Canada and Czechia so quite a few folks
would be missing, and we're mostly focused on F36 Final right now
anyway; there will be a blocker review meeting on Tuesday.
If you're aware of anything it would be
# F36 Blocker Review meeting
# Date: 2022-04-19 (**TUESDAY**)
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.libera.chat
Hi folks! We have 3 proposed Final blockers and 4 proposed Final freeze
exception issues to review, so let's have a review meeting on *Tuesday*.
I'm scheduling it f
- Dell XPS 15 L502X 8GB RAM (BIOS only) CD-R physical media
It would be very nice to run /sbin/dmidecode, which is on the .iso,
and report the "BIOS Information" section, such as:
=
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.5 present.
70 structures occupying 2511 bytes.
Table
I also get the prompts, they seem to be related to when there are multiple
users logged in on the same system.
Best regards
Andreas
Den sön 17 apr. 2022 kl 06:05 skrev Otto Urpelainen :
> Mark Bidewell kirjoitti 16.4.2022 klo 16.23:
> > I hope this is the right mailing list since this is about F
Thanks for the detailed explanation—which I didn’t have time to supply myself,
but fully agree with—and the good advice to re-use the xfontsel keychain file.
It’s even better when the key can come from a source with some nonzero (if
imperfect) level of trust, like upstream’s HTTPS server, or an
Ben Beasley wrote:
> It doesn’t really matter what the file is called. Personally, I would rename
> it to oclock.gpg and add a brief spec file comment explaining where it came
> from.
I agree. It's important to document where the key came from, and the
filename by itself would just be confusing.
It doesn’t really matter what the file is called. Personally, I would rename it
to oclock.gpg and add a brief spec file comment explaining where it came from.
On Sun, Apr 17, 2022, at 12:19 PM, Globe Trotter via devel wrote:
> Btw, I assume that i should call it xfontsel.gpg, or should I rename i
Btw, I assume that i should call it xfontsel.gpg, or should I rename it too?
Thanks!
On Sunday, April 17, 2022, 10:50:37 AM CDT, Globe Trotter via devel
wrote:
Thanks very much! I will do this today.
On Sunday, April 17, 2022, 09:12:15 AM CDT, Björn Persson
wrote:
Ben Bea
No missing expected images.
Failed openQA tests: 8/229 (x86_64), 21/161 (aarch64)
New failures (same test not failed in Fedora-36-20220416.n.0):
ID: 1228749 Test: x86_64 Workstation-live-iso desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1228749
ID: 1228758 Test: x8
Thanks very much! I will do this today.
On Sunday, April 17, 2022, 09:12:15 AM CDT, Björn Persson
wrote:
Ben Beasley wrote:
> Please see
> https://src.fedoraproject.org/rpms/xfontsel/blob/a38f5a42fa7bc59378527cf05dabe29523675613/f/xfontsel.spec#_10
> for an example from the same grou
Ben Beasley wrote:
> Please see
> https://src.fedoraproject.org/rpms/xfontsel/blob/a38f5a42fa7bc59378527cf05dabe29523675613/f/xfontsel.spec#_10
> for an example from the same group of X11 programs.
What's described there is known as TOFU – trust on first use. Ben
looked up which key made the sig
Hey all,
I've orphaned mustache-d[1]. It currently FTBFS[2], but I don't know
of anything using it anymore (appstream-generator no longer uses it).
If someone wants it, feel free to take it.
[1]: https://src.fedoraproject.org/rpms/mustache-d
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=20467
We have specific issues during an Fedora upgrade.
In past, it was issue with rdma-core [1] during upgrade to F34. Nowadays, for
upgrade to F36, we have an issue with lilv [2]
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1919864
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2052588
Both i
OLD: Fedora-36-20220416.n.0
NEW: Fedora-36-20220417.n.0
= SUMMARY =
Added images:4
Dropped images: 2
Added packages: 0
Dropped packages:2
Upgraded packages: 4
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:24.92 MiB
Size of
Hello, Brian.
On Thursday, 14 April 2022 at 01:52, Brian C. Lane wrote:
> A huge thanks to Thomas Schmitt for posting xorrisofs arguments :)
>
> Here is a lorax PR switching to grub2 for BIOS and changing the layout
> of the iso as described in his post:
>
> https://github.com/weldr/lorax/pull/1
On Sunday, April 17, 2022, 05:26:52 AM CDT, Maxwell G via devel
wrote:
> Apr 16, 2022 8:01:27 PM Globe Trotter via devel
> :
>> Source1: %{source0}.sig
> Does this still fail if you use the full path? It looks like `%{source0}`
> isn't getting expanded properly.
Yes, indeed,
No missing expected images.
Failed openQA tests: 1/15 (aarch64)
Old failures (same test failed in Fedora-IoT-36-20220413.0):
ID: 1228654 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1228654
Passed openQA tests: 14/15 (aarch64), 15/15 (x86_64)
Apr 16, 2022 8:01:27 PM Globe Trotter via devel :
> Source1: %{source0}.sig
Does this still fail if you use the full path? It looks like `%{source0}` isn't
getting expanded properly.
Thanks,
--
Maxwell G
Pronouns: He/Him/His
gotmax@e.email
___
deve
Announcing the creation of a new nightly release validation test event
for Fedora-IoT 36 RC 20220417.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_pl
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-20220416.0):
ID: 1228625 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
Missing expected images:
Iot dvd aarch64
Iot dvd x86_64
Failed openQA tests: 2/15 (aarch64)
ID: 1228437 Test: aarch64 IoT-dvd_ostree-iso iot_clevis@uefi
URL: https://openqa.fedoraproject.org/tests/1228437
ID: 1228450 Test: aarch64 IoT-dvd_ostree-iso release_identification@uefi
URL: https
21 matches
Mail list logo
