date:20220410

https://bugzilla.redhat.com/show_bug.cgi?id=2073893

Avinash Hanwate  changed:

   What|Removed |Added

 Depends On||2073895





Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2073895
[Bug 2073895] CVE-2022-22624 webkit2gtk3: webkit2: use after free issue
[fedora-all]
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073893
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2073893] CVE-2022-22624 webkit2: use after free issue

https://bugzilla.redhat.com/show_bug.cgi?id=2073893



--- Comment #1 from Avinash Hanwate  ---
Created webkit2gtk3 tracking bugs for this issue:

Affects: fedora-all [bug 2073895]


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073893
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2073893] CVE-2022-22624 webkit2: use after free issue

https://bugzilla.redhat.com/show_bug.cgi?id=2073893

Avinash Hanwate  changed:

   What|Removed |Added

 Blocks||2073891




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073893
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Test-Announce] 2022-04-11 @ 16:00 UTC - Fedora 36 Blocker Review Meeting

2022-04-10 Thread Geoffrey Marr

# F36 Blocker Review meeting
# Date: 2022-04-11
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.libera.chat

Hey testers! We have 7 proposed Final blockers and 2 proposed Final freeze
exception issues to review, so let's have a review meeting on Monday. We
also have Go/No-Go coming up on 14 April, so let's take time to review the
accepted blocker list.

If you have time, you can take a look at the proposed or
accepted blockers before the meeting -  the full lists can be found
here: https://qa.fedoraproject.org/blockerbugs/ .

Remember, you can also now vote on bugs outside of review meetings! If
you look at the bug list in the blockerbugs app, you'll see links
labeled "Vote!" next to all proposed blockers and freeze exceptions.
Those links take you to tickets where you can vote.
https://pagure.io/fedora-qa/blocker-review has instructions on how
exactly you do it. We usually go through the tickets shortly before the
meeting and apply any clear votes, so the meeting will just cover bugs
where there wasn't a clear outcome in the ticket voting yet. **THIS
MEANS IF YOU VOTE NOW, THE MEETING WILL BE SHORTER!**

We'll be evaluating these bugs to see if they violate any of the
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F36 can be found on the
wiki [0].

For more information about the Blocker and Freeze exception process,
check out these links:
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out
the SOP on the wiki:
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting

See you at the meeting!


Geoff Marr
IRC: coremodule

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria
___
test-announce mailing list -- test-annou...@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-annou...@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2073893] CVE-2022-22624 webkit2: use after free issue

https://bugzilla.redhat.com/show_bug.cgi?id=2073893

Avinash Hanwate  changed:

   What|Removed |Added

 CC||alekc...@googlemail.com,
   ||erik-fed...@vanpienbroek.nl
   ||,
   ||extras-orphan@fedoraproject
   ||.org, gw...@protonmail.com,
   ||igor.ra...@gmail.com,
   ||ivazquez...@gmail.com,
   ||jgrul...@redhat.com,
   ||jrez...@redhat.com,
   ||kde-sig@lists.fedoraproject
   ||.org,
   ||ke...@tigcc.ticalc.org,
   ||manisan...@gmail.com,
   ||m...@dvratil.cz,
   ||mikedep...@gmail.com,
   ||mtas...@tbz.t-com.ne.jp,
   ||nott...@splat.cc,
   ||patr...@club-linux.ch,
   ||perl-devel@lists.fedoraproj
   ||ect.org, rdie...@gmail.com,
   ||rjo...@redhat.com,
   ||rust-sig@lists.fedoraprojec
   ||t.org, t...@redhat.com,
   ||walt...@redhat.com,
   ||zebo...@gmail.com




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073893
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Sun, Apr 10, 2022 at 11:06 PM Gary Buhrmaster
 wrote:
>
> On Sun, Apr 10, 2022 at 1:27 PM Neal Gompa  wrote:
>
> > Windows 11 *does not matter* here.
>
> (Windows) Desktop as a Service (DaaS)[0] may
> change that faster than some expect (or faster
> than some hope).  There is a large push by
> some orgs to move services off premise
> into the cloud (for a number of stated reasons
> including zero trust and WfH scenarios).
>
> And while I have zero plans to give up my
> linux systems in favor of cloud desktops,
> and some of the push for DaaS may be
> more hype than real, I do agree that there
> are valid use cases, and that is going to
> push some to support UEFI in the future.
>

The economics of Windows in the cloud is not great unless you're on
Azure, where Microsoft can give itself preferential pricing. And most
people that use Fedora in the Cloud aren't using Azure (or AWS or GCP
for that matter).


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Gary Buhrmaster

On Sun, Apr 10, 2022 at 1:27 PM Neal Gompa  wrote:

> Windows 11 *does not matter* here.

(Windows) Desktop as a Service (DaaS)[0] may
change that faster than some expect (or faster
than some hope).  There is a large push by
some orgs to move services off premise
into the cloud (for a number of stated reasons
including zero trust and WfH scenarios).

And while I have zero plans to give up my
linux systems in favor of cloud desktops,
and some of the push for DaaS may be
more hype than real, I do agree that there
are valid use cases, and that is going to
push some to support UEFI in the future.

Gary

[0] And certain SaaS application solutions.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Wine MinGW system libraries

2022-04-10 Thread Zebediah Figura


Hello all,

Since this conversation several months ago I've been working with the 
Wine maintainer on implementing a solution upstream that is compatible 
with our requirements and the pretty much universal desire by packagers 
to avoid system library imports. I believe I've found a solution that 
will work for now for everyone, although it has raised some questions 
about standardization of MinGW packages—see the "Open Questions" section 
of this mail for more details.


== Summary of upstream progress ==

Currently Wine bundles the source of several libraries. At the same 
time, as was discussed we've implemented a system upstream by which 
external shared libraries can be linked to and loaded (while keeping 
them in a separate "namespace" so that they don't conflict with 
identically named application DLLs.) There are still some concerns on 
the Wine side that this will break applications in subtle ways, but 
unfortunately there has been almost no testing of this feature yet.


The libraries which we import are as follows:

* libFAudio
* libgsm
* libjpeg
* jxrlib
* liblcms2
* libmpg123
* libpng
* libtiff
* libvkd3d
* libxml2
* libxslt
* zlib

This list is probably going to remain stable. Despite what was discussed 
earlier I do *not* forsee us importing libOSMesa. An import of 
libfreetype or libgnutls is also unlikely at this point.


We currently do *not* support external static linking. The basic reason 
for this is that Wine builds against its own CRT rather than MinGW's, 
and we cannot safely statically link to a module built with a different CRT.


== Technical details ==

This is somewhat redundant for Fedora, since it's been brought to my 
attention that you've already started using external dependencies. But 
since we have little documentation about the current state, for the sake 
of completeness I'll try to be exhaustive here.


In order to use system shared libraries, Wine needs to know where to 
find them at runtime. This is done with a configure argument:


configure --with-system-dllpath=/first/directory/:/second/directory/

Note that this may need to include the location of libgcc_s and other 
dependencies, which is usually in a different location.


Separately, for each argument, we need to know the compiler and linker 
flags used to find the library. This also can be done with configure 
arguments, much like for native libraries:


configure GSM_PE_CFLAGS="-Iwhatever" GSM_PE_LIBS="-Lwhatever -lgsm"

If MinGW pkg-config is present, and --with-system-dllpath is specified, 
Wine will automatically use it to detect the compiler and linker flags 
for all of the above packages supporting pkg-config, which in particular 
excludes libgsm and jxrlib. Thus in practice it should not be necessary 
to hand-code most CFLAGS and LIBS variables.


== Open Question(s) ==

Currently it's necessary to use a configure argument to specify where to 
find the runtime path. This is fine for distributions, which is where 
most people are going to be getting Wine anyway. It's a bit unfortunate 
for anyone self-compiling Wine, though, and it'd be nice if there was 
some way to avoid it. Unfortunately, there are two things standing in 
our way.


The first problem is that the location of runtime DLLs varies wildly 
between distributions, and there's no common independent way to detect 
it. We could potentially hardcode a few "guesses" at the runtime path 
into Wine's configure script, but that brings us to the second problem: 
there's no way to verify the presence of runtime DLLs. We *are* the 
loader and lower-level APIs and would have to bootstrap ourselves first, 
and this is pretty much infeasible.


Hence "standardize the location of runtime DLLs across distributions" 
isn't really a feasible solution either, as nice as it would be—we have 
no way to know whether a distribution is post-standardization or not.


Rather, I think the best solution is to have some tool which, if present 
or successful, lists one or more directories where libraries can be 
found. I'm not sure what the most sensible thing here is:


* pkg-config would be an obvious tool to extend, but would presumably 
require modifying .pc files for all relevant packages upstream. The 
location also seems to be consistent across all packages within each 
distribution I was able to test, so there probably isn't much point in 
making it package-specific. [For the packages we care about, cmake and 
libtool both put things in /bin by default, and zlib apparently has no 
built-in cross-compilation support.]


* Introducing an analogue of ld.so.conf seems like a good idea. It would 
allow for per-package extra directories if that ever becomes necessary, 
and is relatively easy to parse, although ideally it would be even 
easier than that (i.e. if someone other than Wine could deal with the 
"include" part, that would be great).


ἔρρωσθε,
Zeb
___
devel mailing list -- devel@lists.fedoraproject.org

Re: Dropping wine from ARM

2022-04-10 Thread Zebediah Figura


On 3/30/22 09:49, Neal Gompa wrote:

On Wed, Mar 30, 2022 at 10:44 AM NightStrike  wrote:




On Wed, Mar 30, 2022, 08:34 Michael Cronenworth  wrote:


Hi,

Fedora currently ships Wine 7.3 released February 25th, 2022.

Wine 7.4, released March 11th, started to require a 'llvm-mingw' compiler for 
ARM64
builds. Fedora ships the 'mingw-w64' gcc-based MinGW environment and does not 
ship
the 'llvm' MinGW environment. Unlike the WineMono package, which bundles a
'llvm-mingw' compiler (that is removed and mingw-w64 is used), the Wine package 
does
not bundle one and does not allow for an alternative compiler.

I will need to drop ARM from Wine in order to continue shipping new updates. I 
do
not have the bandwidth to package the llvm-mingw compiler toolchain, nor do I 
have
the time right now to discuss this with upstream.



That is an unfortunate decision on the part of wine. Gcc is a very robust 
compiler.



I'm not surprised, honestly. I suspect the primary motivation for
Clang is that Microsoft contributed support for PDB to LLVM, but
nobody brought it into GCC as far as I know. That said, we don't have
any debug infrastructure for PDB, only DWARF (which is what GCC uses
in Fedora).


This is a bit of a late response, so apologies for that.

I believe we don't actually require LLVM per se (despite the configure 
error), but we do require MinGW cross-compilation. The reason for this, 
briefly, is that the overhead of supporting builds without a MinGW 
cross-compiler is growing too high. It is likely that in the future we 
will require MinGW for all architectures, although I cannot say how far 
in the future.


I don't know if the aarch64-w64-mingw32 target is supported for gcc, but 
if not, that is probably why the configure message is phrased like that. 
If it is, there's probably no reason for the message to specifically 
mention LLVM.


We do support PDB debug information (and it may work better than DWARF 
on the whole, but don't quote me on that), but we don't require it to 
build wine.


ἔρρωσθε,
Zeb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Sun, Apr 10, 2022 at 7:08 PM Gabriel Ramirez  wrote:
>
> On 4/10/22 16:10, Neal Gompa wrote:
> > On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski
> >  wrote:
> >> On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
> >> [...]
> >>> Probably it isn't a problem for some users, but I'm still having bad
> >>> experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
> >>> system that works fine with UEFI. And my parents' laptop was purchased
> >>> 2 years ago and the UEFI firmware does not allow to boot anything
> >>> other than Windows on UEFI mode (regardless of turning secure boot on
> >>> or off) and I have to switch to BIOS mode to make Fedora work there.
> >>> So in this situation, I think it's way too aggressive to accept the
> >>> change - this will probably drive away some potential new users with
> >>> decent laptop like my parents'.
> >> Have you tried renaming your Fedora boot entry to "Windows Boot
> >> Manager"? I have one Sony laptop that boots only the boot entry with
> >> that exact name.
> >>
> > I wonder if this would work with one of my old machines too. I've
> > never thought to rename the boot entry in the firmware before...
> >
> >
>
> about "Windows Boot Manager" efi entry required to boot:
> https://mjg59.dreamwidth.org/20187.html
>
> the above happens too with the lenovo thinkcentre m91

From the blog post:
> For now, if you want to run Fedora[2] on these systems you're probably best 
> off changing the firmware to perform a legacy boot.

*sigh*


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2073858] New: perl-CPAN-FindDependencies-3.11 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2073858

Bug ID: 2073858
   Summary: perl-CPAN-FindDependencies-3.11 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-CPAN-FindDependencies
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: cicku...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 3.11
Current version/release in rawhide: 3.10-2.fc36
URL: http://search.cpan.org/dist/CPAN-FindDependencies/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2729/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073858
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Gabriel Ramirez


On 4/10/22 16:10, Neal Gompa wrote:

On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski
 wrote:

On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
[...]

Probably it isn't a problem for some users, but I'm still having bad
experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
system that works fine with UEFI. And my parents' laptop was purchased
2 years ago and the UEFI firmware does not allow to boot anything
other than Windows on UEFI mode (regardless of turning secure boot on
or off) and I have to switch to BIOS mode to make Fedora work there.
So in this situation, I think it's way too aggressive to accept the
change - this will probably drive away some potential new users with
decent laptop like my parents'.

Have you tried renaming your Fedora boot entry to "Windows Boot
Manager"? I have one Sony laptop that boots only the boot entry with
that exact name.


I wonder if this would work with one of my old machines too. I've
never thought to rename the boot entry in the firmware before...




about "Windows Boot Manager" efi entry required to boot: 
https://mjg59.dreamwidth.org/20187.html


the above happens too with the lenovo thinkcentre m91
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: GNOME Online Accounts "Fedora" - Pre-authentication failed

2022-04-10 Thread Demi Marie Obenour

On 4/8/22 13:28, Björn Persson wrote:
> Michael Catanzaro wrote:
>> On Thu, Apr 7 2022 at 12:30:42 PM -0400, Stephen Gallagher 
>>  wrote:
>>> Well, it *could* grow an interface to some of the password wallet
>>> services that support TOTP or HOTP codes (like Bitwarden, Lastpass,
>>> 1password, etc.) and configure it to query that service and append the
>>> code to the password. It doesn't help if you want/need a physical
>>> token, though.  
>>
>> Good idea. Of course we'd probably want to use GNOME Keyring for this 
>> (which does not currently support third-party services, but could in 
>> the future). I suppose gnome-online-accounts would only need to store 
>> the TOTP/HOTP seed and some config data.
> 
> This sounds like you would store the password and the TOTP seed
> together in the same keyring. That's rather pointless. If you store two
> secrets together, then they are effectively a single secret, and the
> TOTP just adds an unnecessary step to the authentication protocol. It's
> better to generate a long random key for your "password", store that in
> your keyring, and not bother with TOTP.
> 
> Two-factor authentication is when you have two secrets stored in two
> different storage media, for example one in Gnome Keyring and the
> other in a Yubikey.
> 
> If the keyring is encrypted with a master passphrase, then that's also
> two-factor authentication. The encrypted key stored in the keyring is
> one factor, and the master passphrase stored in the user's brain is the
> other factor. In that case a TOTP seed stored in a Yubikey becomes a
> third factor.

That is basically what I do.  I use full disk encryption, which means
that the entire drive (not just the keyring) is encrypted.  That is one
factor, and the keyring is the other.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
> [...]
> > Probably it isn't a problem for some users, but I'm still having bad
> > experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
> > system that works fine with UEFI. And my parents' laptop was purchased
> > 2 years ago and the UEFI firmware does not allow to boot anything
> > other than Windows on UEFI mode (regardless of turning secure boot on
> > or off) and I have to switch to BIOS mode to make Fedora work there.
> > So in this situation, I think it's way too aggressive to accept the
> > change - this will probably drive away some potential new users with
> > decent laptop like my parents'.
>
> Have you tried renaming your Fedora boot entry to "Windows Boot
> Manager"? I have one Sony laptop that boots only the boot entry with
> that exact name.
>

I wonder if this would work with one of my old machines too. I've
never thought to rename the boot entry in the firmware before...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Dominik 'Rathann' Mierzejewski

On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
[...]
> Probably it isn't a problem for some users, but I'm still having bad
> experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
> system that works fine with UEFI. And my parents' laptop was purchased
> 2 years ago and the UEFI firmware does not allow to boot anything
> other than Windows on UEFI mode (regardless of turning secure boot on
> or off) and I have to switch to BIOS mode to make Fedora work there.
> So in this situation, I think it's way too aggressive to accept the
> change - this will probably drive away some potential new users with
> decent laptop like my parents'.

Have you tried renaming your Fedora boot entry to "Windows Boot
Manager"? I have one Sony laptop that boots only the boot entry with
that exact name.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Dominik 'Rathann' Mierzejewski

On Friday, 08 April 2022 at 19:14, Brian C. Lane wrote:
[...]
> So like I said yesterday, I'll look into switching to use grub2 for
> Fedora 37, assuming grub2 continues to support BIOS.

Thank you very much! From my side, I've found another BIOS-only machine
in my junkyard and I'm willing to put both up for testing any changes
and maybe even help write some code if time permits.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Dominik 'Rathann' Mierzejewski

On Friday, 08 April 2022 at 13:41, Vitaly Zaitsev via devel wrote:
> On 08/04/2022 09:54, Dominik 'Rathann' Mierzejewski wrote:
> > I already did. Isn't that what I wrote?
> 
> Can you post their answer?

Yes:
```
On VPS, we do not provide images with UEFI enabled.
```

They support UEFI on their Public Cloud instances, but the same
configuration as my current VPS seems to be twice as expensive.

I've asked them to clarify if they have any plans to enable UEFI for
their VPS instances.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Apr 07, 2022 at 10:43:02AM +0200, Lennart Poettering wrote:
> On Mi, 06.04.22 07:33, Neal Gompa (ngomp...@gmail.com) wrote:
> > Irrespective of this change, I would flat-out oppose moving to
> > sd-boot. In any case, you can't use sd-boot for live media.
> >
> > If we were going to move to pure EFI boot manager, I'd rather use one
> > that has a decent user experience and not a barebones crappy one.
> 
> OK, I'll bite.
> 
> What are you missing in sd-boot, specifically?
> 
> Also, why would a boot menu need a particularly fancy user experience?
> It's a boot manager, not a web browser.

"barebones crappy one" is pretty strong. I'm too am interested in
hearing what is so wrong with the sd-boot experience.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Zbigniew Jędrzejewski-Szmek

On Sun, Apr 10, 2022 at 10:27:25AM -0400, Neal Gompa wrote:
> And we can take incremental steps to get there, even now:
> 
> 1. Switch Anaconda to default to GPT even on BIOS setups
> 2. Drop syslinux and use GRUB everywhere
> 3. Configure new installations to always do hybrid boot installations
> 4. Develop documentation and/or tooling to do MBR->GPT conversions and
> reconfigure for hybrid boot for existing systems
> 
> These are all reasonably achievable things we can do. And that gives
> us time to work our relationships with our stakeholders to prepare
> them for the day legacy BIOS support is gone from the entire Red Hat
> family of distributions. It also gives room for improving the UEFI
> experience so it's *at least* as good as the BIOS one, if not better.
> Right now, it's not. And it needs to be in order to maintain the
> momentum we have now where Fedora Linux adoption is growing by leaps
> and bounds over the last couple of years.

This is a very concrete actionable and achievable proposal. /me likes.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Nikolay Nikolov



On 4/10/22 16:27, Neal Gompa wrote:

On Sat, Apr 9, 2022 at 10:51 PM Gary Buhrmaster
 wrote:

On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa  wrote:


Moving past the Big Three(tm), the actual
cloud providers that matter from a Fedora context are the smaller
outfits that principally serve Linux users. These are companies like
DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
graciously do offer Fedora Linux in their platforms. All of their
virtualization platforms are BIOS only right now, and getting them to
switch requires them to uplift their platforms to support UEFI in the
first place.

They may only support Linux users today, but if
they want to grow (and while it is possible to
survive as a niche service, many see growth
as the way to increased revenue/profits (go
big or go home)), they are going to get pushed
(perhaps kicking and screaming) to support
UEFI as at least an alternative moving forward
as some of their customers are going to prefer
using a single provider, and Windows 11
requires UEFI(*)(**), and it would be a shame
if only the big players were eligible for hosting
such services(***).

Many of these comments seem to be about
the date, not the end state (UEFI)(),
just like 32-bit x86 and armv7.  No one wants
their personal ox gored, but there will come
a time when it will be time to let old systems
go.

"We" (and when I say "we", I understand that
is mostly not me), are going to have to
continue to document (and fix, where "we"
have the knowledge) the areas that need
improvement for UEFI booting and runtime.


Windows is a niche in the server space, rather than the default. And
Microsoft didn't even remove the server exception to continue using
BIOS until last year from the Windows platform qualification
documentation. It's *definitely* going to be a while, especially with
Windows Server 2019 being supported until the end of the decade.
Just tested installing Windows Server 2019 in a QEMU virtual machine on 
a 40 GB virtual hard disk and 2 GB RAM. It formatted the disk as MBR and 
installed just fine, no warnings, no deprecations, no nothing. 
Mainstream support for Windows Server 2019 ends in January 9, 2024, 
extended support lasts until January 9, 2029.

Windows 11 *does not matter* here. Windows Server is what matters
here, and there are no announced Windows Server versions following the
Windows 11 platform requirements.
I agree. IMO, Windows 11 is only good for home desktop use (and for that 
purpose, Windows 10 is just as good, there are only cosmetic differences 
in the UI), it is irrelevant for servers, because of the artificial 
restrictions that Microsoft puts on their desktop operating systems 
(limited number of connections, limited number of websites you can host 
in IIS, etc.) in order to boost their Windows Server sales. Ironically, 
due to this fact, Windows Server works better as a desktop, than Windows 
10 or 11 as a server. At work we use Windows Server for web development 
in Visual Studio, because it just works better, e.g. you can deploy 
multiple web sites on your machine, etc. :)





--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-36-20220410.n.0 compose check report

No missing expected images.

Failed openQA tests: 16/161 (aarch64), 6/229 (x86_64)

New failures (same test not failed in Fedora-36-20220409.n.0):

ID: 1219385 Test: aarch64 Server-dvd-iso support_server@uefi
URL: https://openqa.fedoraproject.org/tests/1219385
ID: 1219399 Test: aarch64 Server-dvd-iso install_blivet_lvm_ext4@uefi
URL: https://openqa.fedoraproject.org/tests/1219399
ID: 1219414 Test: aarch64 Server-dvd-iso install_updates_nfs@uefi
URL: https://openqa.fedoraproject.org/tests/1219414
ID: 1219453 Test: aarch64 Workstation-raw_xz-raw.xz desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1219453
ID: 1219529 Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/1219529
ID: 1219586 Test: aarch64 universal install_european_language@uefi
URL: https://openqa.fedoraproject.org/tests/1219586
ID: 1219594 Test: aarch64 universal install_mirrorlist_graphical@uefi
URL: https://openqa.fedoraproject.org/tests/1219594
ID: 1219598 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1219598
ID: 1219622 Test: aarch64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/1219622

Old failures (same test failed in Fedora-36-20220409.n.0):

ID: 1219305 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1219305
ID: 1219340 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1219340
ID: 1219438 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1219438
ID: 1219439 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1219439
ID: 1219441 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1219441
ID: 1219448 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1219448
ID: 1219472 Test: x86_64 Workstation-upgrade apps_startstop
URL: https://openqa.fedoraproject.org/tests/1219472
ID: 1219475 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1219475
ID: 1219490 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1219490
ID: 1219494 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1219494
ID: 1219496 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1219496
ID: 1219560 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1219560
ID: 1219619 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1219619

Soft failed openQA tests: 10/229 (x86_64), 5/161 (aarch64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-36-20220409.n.0):

ID: 1219323 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1219323
ID: 1219415 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1219415

Old soft failures (same test soft failed in Fedora-36-20220409.n.0):

ID: 1219308 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1219308
ID: 1219312 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1219312
ID: 1219333 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1219333
ID: 1219350 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1219350
ID: 1219355 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1219355
ID: 1219357 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1219357
ID: 1219358 Test: x86_64 Silverblue-dvd_ostree-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1219358
ID: 1219364 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1219364
ID: 1219454 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1219454
ID: 1219458 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1219458
ID: 1219466 Test: x86_64 Workstation-upgrade desktop_browser
URL: https://openqa.fedoraproject.org/tests/1219466
ID: 1219488 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1219488
ID: 1219501 Test: aarch64 Workstation-upgrade eog@uefi
URL: https://openqa.fedoraproject.org/tests/1219501

Passed openQA tests: 213/229 (x86_64), 140/161 (aarch64)

New passes (same

Re: boinc-client build failure on non x86 architectures F>35

2022-04-10 Thread Kevin Kofler via devel

Mamoru TASAKA wrote:
> Possible solution is to check if compiler (target) supports -msse3 and
> -mavx first, and it they are not supported, don't pass them to CPPFLAGS on
> AC_CHECK_DECL

It shall be noted that unconditionally compiling with these flags on x86_64 
will make the program fail to run on any CPU not supporting these vector 
instruction sets and is hence a violation of Fedora policies.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20220410.n.0 compose check report

Missing expected images:

Minimal raw-xz armhfp

Compose PASSES proposed Rawhide gating check!
All required tests passed

Failed openQA tests: 10/231 (x86_64), 20/161 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20220408.n.2):

ID: 1218926 Test: x86_64 Workstation-live-iso desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1218926
ID: 1218954 Test: x86_64 Silverblue-dvd_ostree-iso anaconda_help
URL: https://openqa.fedoraproject.org/tests/1218954
ID: 1218991 Test: aarch64 Server-dvd-iso install_btrfs_preserve_home@uefi
URL: https://openqa.fedoraproject.org/tests/1218991
ID: 1219017 Test: aarch64 Server-dvd-iso install_vncconnect_client@uefi
URL: https://openqa.fedoraproject.org/tests/1219017
ID: 1219028 Test: aarch64 Server-dvd-iso install_vncconnect_server@uefi
URL: https://openqa.fedoraproject.org/tests/1219028
ID: 1219079 Test: x86_64 Workstation-upgrade desktop_printing
URL: https://openqa.fedoraproject.org/tests/1219079
ID: 1219100 Test: aarch64 Workstation-upgrade evince@uefi
URL: https://openqa.fedoraproject.org/tests/1219100
ID: 1219191 Test: aarch64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/1219191
ID: 1219207 Test: aarch64 universal install_arabic_language@uefi
URL: https://openqa.fedoraproject.org/tests/1219207

Old failures (same test failed in Fedora-Rawhide-20220408.n.2):

ID: 1218911 Test: x86_64 Workstation-live-iso desktop_printing
URL: https://openqa.fedoraproject.org/tests/1218911
ID: 1218912 Test: x86_64 Workstation-live-iso gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1218912
ID: 1218950 Test: x86_64 KDE-live-iso desktop_login
URL: https://openqa.fedoraproject.org/tests/1218950
ID: 1218997 Test: aarch64 Server-dvd-iso 
server_role_deploy_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1218997
ID: 1219000 Test: aarch64 Server-dvd-iso server_realmd_join_kickstart@uefi
URL: https://openqa.fedoraproject.org/tests/1219000
ID: 1219011 Test: aarch64 Server-dvd-iso 
install_repository_hd_variation@uefi
URL: https://openqa.fedoraproject.org/tests/1219011
ID: 1219012 Test: aarch64 Server-dvd-iso mediakit_repoclosure@uefi
URL: https://openqa.fedoraproject.org/tests/1219012
ID: 1219024 Test: aarch64 Server-dvd-iso server_cockpit_basic@uefi
URL: https://openqa.fedoraproject.org/tests/1219024
ID: 1219032 Test: aarch64 Server-dvd-iso realmd_join_cockpit@uefi
URL: https://openqa.fedoraproject.org/tests/1219032
ID: 1219047 Test: aarch64 Workstation-raw_xz-raw.xz desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1219047
ID: 1219048 Test: aarch64 Workstation-raw_xz-raw.xz gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1219048
ID: 1219050 Test: aarch64 Workstation-raw_xz-raw.xz 
desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1219050
ID: 1219083 Test: x86_64 Workstation-upgrade desktop_printing_builtin
URL: https://openqa.fedoraproject.org/tests/1219083
ID: 1219084 Test: x86_64 Workstation-upgrade gnome_text_editor
URL: https://openqa.fedoraproject.org/tests/1219084
ID: 1219089 Test: x86_64 Workstation-upgrade desktop_fprint
URL: https://openqa.fedoraproject.org/tests/1219089
ID: 1219097 Test: aarch64 Workstation-upgrade desktop_browser@uefi
URL: https://openqa.fedoraproject.org/tests/1219097
ID: 1219099 Test: aarch64 Workstation-upgrade desktop_printing@uefi
URL: https://openqa.fedoraproject.org/tests/1219099
ID: 1219103 Test: aarch64 Workstation-upgrade gnome_text_editor@uefi
URL: https://openqa.fedoraproject.org/tests/1219103
ID: 1219105 Test: aarch64 Workstation-upgrade desktop_printing_builtin@uefi
URL: https://openqa.fedoraproject.org/tests/1219105
ID: 1219169 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/1219169
ID: 1219228 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1219228

Soft failed openQA tests: 5/161 (aarch64), 12/231 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20220408.n.2):

ID: 1219224 Test: aarch64 universal upgrade_2_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1219224

Old soft failures (same test soft failed in Fedora-Rawhide-20220408.n.2):

ID: 1218915 Test: x86_64 Workstation-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1218915
ID: 1218919 Test: x86_64 Workstation-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1218919
ID: 1218930 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1218930
ID: 1218940 Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/1218940
ID: 1218947 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1218947

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Fri, Apr 8, 2022 at 2:23 PM Robbie Harwood  wrote:
>
> Michel Alexandre Salim  writes:
>
> > - as I stated, there are offers to help with getting syslinux replaced
> >   with GRUB. what I've not stated originally is Chris Murphy brought up
> >   protective MBR and switching all new installs to inst.gpt, which let
> >   us future proof new installations for when we do kill off legacy BIOS.
> >
> > What people who want to help needs, though, is some sense that our
> > contributions are welcome.
>
> (If you're looking for me to comment on proposals to change live media
> generation and installs, I can't really do that - that's Brian's and
> Jiri's areas of expertise.)
>
> > - Neal pointed out he has been working on addressing this for a while,
> >   and have not put up a Change Proposal because he thought it was
> >   premature
>
> While Neal's contributions are as welcome as anyone else's, Neal is not
> a maintainer of (or regular contributor to) bootloader packages and it
> would be very strange for Neal to propose such a change without
> discussing it with us first.  That said, if there was suggestion of such
> a proposal, I have missed it (which is very possible given the size of
> the thread at this point).
>

Alright, I'll bite. I am within my rights to propose any Change I want
for Fedora Cloud, which I help steward with David Duncan.

For Fedora Cloud, we've been discussing what we want to support going
forward. I added hybrid boot support[1] in Fedora Linux 35
specifically so that we can start working on adding Fedora Cloud to
Azure, who prefers UEFI for its Hyper-V VMs[2], but also supports
legacy BIOS. We decided to not propose a Change to deprecate BIOS
support yet specifically because we needed to have conversations with
the various VPSes that people *actually use Fedora* on before we do
that[3]. I was completely thrown by this Change proposal because it
threatens to poison the conversations that Fedora Cloud wants to have
with its actual stakeholders for a less acrimonious transition.

As an aside, I examined the state of all release blocking Fedora
deliverables, and something I noticed is that only the Workstation WG
has Red Hatters actively engaged in it. That means that this Change
comes with absolutely no understanding of the state of the world in
Fedora across the various WGs and SIGs that deliver release-blocking
artifacts. That in itself isn't necessarily a problem, but the fact
that none of you are listening to us (David Duncan and myself for
Cloud and KDE, Chris Murphy for Cloud and Workstation, and Peter Boy
for Server) when we tell you this is too early is extremely tone-deaf.

None of us want to keep supporting BIOS forever, but we all have
*real-world experience* saying that we can't do this yet. We're trying
to find a way to meet halfway to simplify legacy BIOS support, but
you're not listening to us. We've also been trying to tell you that
there are *real problems* with Fedora's UEFI support that need fixing
before we can cut off BIOS support, but you're not listening to us.

This thread has, at the time of my writing this post, has 269 posts
across 62 individuals. It is the most active thread we've had since
the switch to nano by default. However, unlike that change, almost
every single respondent has brought up feedback in this discussion
saying that we're not ready and providing examples of why we're not
ready. However, you're *not listening*.

I understand you want to drop BIOS support before Fedora Linux 40 is
branched into RHEL 10. Obviously you could drop it in RHEL 10 even if
Fedora doesn't, but it'd be better to drop it in Fedora first and make
sure everything is flushed out. I would be fine with us doing that if
there was some expectation that the UEFI experience in Fedora Linux
was going to improve to resolve the issues people have *now* by the
time we get there.

And we can take incremental steps to get there, even now:

1. Switch Anaconda to default to GPT even on BIOS setups
2. Drop syslinux and use GRUB everywhere
3. Configure new installations to always do hybrid boot installations
4. Develop documentation and/or tooling to do MBR->GPT conversions and
reconfigure for hybrid boot for existing systems

These are all reasonably achievable things we can do. And that gives
us time to work our relationships with our stakeholders to prepare
them for the day legacy BIOS support is gone from the entire Red Hat
family of distributions. It also gives room for improving the UEFI
experience so it's *at least* as good as the BIOS one, if not better.
Right now, it's not. And it needs to be in order to maintain the
momentum we have now where Fedora Linux adoption is growing by leaps
and bounds over the last couple of years.

[1]: https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot
[2]: https://pagure.io/cloud-sig/issue/309
[3]: https://pagure.io/cloud-sig/issue/345

--
真実はいつも一つ！/ Always, there's only one truth!
___
devel

[Bug 2073800] perl-Config-General-2.65 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2073800



--- Comment #5 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Config-General-2.65-1.fc34.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=85442183


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073800
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2073800] perl-Config-General-2.65 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2073800

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Config-General-2.64 is |perl-Config-General-2.65 is
   |available   |available



--- Comment #3 from Upstream Release Monitoring 
 ---
Latest upstream release: 2.65
Current version/release in rawhide: 2.63-17.fc36
URL: http://search.cpan.org/dist/Config-General/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2714/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073800
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2073800] perl-Config-General-2.65 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2073800



--- Comment #4 from Upstream Release Monitoring 
 ---
Created attachment 1871662
  --> https://bugzilla.redhat.com/attachment.cgi?id=1871662=edit
Update to 2.65 (#2073800)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073800
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: boinc-client build failure on non x86 architectures F>35

2022-04-10 Thread Germano Massullo

Thank you very much Mamoru! Why don't you submit your patch to upstream 
repository, so you get the credit? We will need to patch such thing 
upstream anyways!

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Sat, Apr 9, 2022 at 10:51 PM Gary Buhrmaster
 wrote:
>
> On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa  wrote:
>
> > Moving past the Big Three(tm), the actual
> > cloud providers that matter from a Fedora context are the smaller
> > outfits that principally serve Linux users. These are companies like
> > DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
> > graciously do offer Fedora Linux in their platforms. All of their
> > virtualization platforms are BIOS only right now, and getting them to
> > switch requires them to uplift their platforms to support UEFI in the
> > first place.
>
> They may only support Linux users today, but if
> they want to grow (and while it is possible to
> survive as a niche service, many see growth
> as the way to increased revenue/profits (go
> big or go home)), they are going to get pushed
> (perhaps kicking and screaming) to support
> UEFI as at least an alternative moving forward
> as some of their customers are going to prefer
> using a single provider, and Windows 11
> requires UEFI(*)(**), and it would be a shame
> if only the big players were eligible for hosting
> such services(***).
>
> Many of these comments seem to be about
> the date, not the end state (UEFI)(),
> just like 32-bit x86 and armv7.  No one wants
> their personal ox gored, but there will come
> a time when it will be time to let old systems
> go.
>
> "We" (and when I say "we", I understand that
> is mostly not me), are going to have to
> continue to document (and fix, where "we"
> have the knowledge) the areas that need
> improvement for UEFI booting and runtime.
>

Windows is a niche in the server space, rather than the default. And
Microsoft didn't even remove the server exception to continue using
BIOS until last year from the Windows platform qualification
documentation. It's *definitely* going to be a while, especially with
Windows Server 2019 being supported until the end of the decade.

Windows 11 *does not matter* here. Windows Server is what matters
here, and there are no announced Windows Server versions following the
Windows 11 platform requirements.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Thomas Schmitt

Hi,

Nikolay Nikolov wrote:
> I imagine it is like those polyglot programs, that are simultaneously valid
> in several totally different programming languages:

Yep. A boot-everywhere ISO for x86 is quite like that.
Every firmware variant can see in it what it expects.


> Actually, I have already invested in a Blu-ray burner, I just haven't
> purchased any BD-R or BD-RE install media, so I haven't even tested the
> Blu-ray burning :)

Then it's about time. :))
I propose to backup a few GiB of your favorite data by xorriso and update
that backup daily until the medium is full. See in
  https://www.gnu.org/software/xorriso/
the example
  "The following command performs incremental backup."

(I apologize to the list for this off-topic advertising of my program.)


Have a nice day :)

Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Nikolay Nikolov



On 4/10/22 05:50, Gary Buhrmaster wrote:

On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa  wrote:


Moving past the Big Three(tm), the actual
cloud providers that matter from a Fedora context are the smaller
outfits that principally serve Linux users. These are companies like
DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
graciously do offer Fedora Linux in their platforms. All of their
virtualization platforms are BIOS only right now, and getting them to
switch requires them to uplift their platforms to support UEFI in the
first place.

They may only support Linux users today, but if
they want to grow (and while it is possible to
survive as a niche service, many see growth
as the way to increased revenue/profits (go
big or go home)), they are going to get pushed
(perhaps kicking and screaming) to support
UEFI as at least an alternative moving forward
as some of their customers are going to prefer
using a single provider, and Windows 11
requires UEFI(*)(**), and it would be a shame
if only the big players were eligible for hosting
such services(***).

Many of these comments seem to be about
the date, not the end state (UEFI)(),
just like 32-bit x86 and armv7.  No one wants
their personal ox gored, but there will come
a time when it will be time to let old systems
go.
Yes, but the whole point is that it's way too early. Windows 10 still 
supports not only legacy BIOS, but also i686 (which Fedora has dropped 
support for in Fedora 31; Fedora 30 was EOL'd in May 2020) and Windows 
10 will be supported until at least October 14, 2025. For comparison, 
Fedora 36 will be EOL'd in May 2023.


"We" (and when I say "we", I understand that
is mostly not me), are going to have to
continue to document (and fix, where "we"
have the knowledge) the areas that need
improvement for UEFI booting and runtime.

Gary



(*) Technically it is possible to jump through
enough hoops to get Windows 11 to run on
BIOS only systems, but it is not supported,
and may break at any time.  Most people
prefer something that the vendor supports.


BIOS-only users can stay on Windows 10. They have very little reason to 
upgrade to Windows 11. It's mostly cosmetic changes to the UI and 
there's no major software product that requires Windows 11, but doesn't 
run on Windows 10. Adoption of new Windows versions has always been 
painstakingly slow, even after the old version is EOL'd, people continue 
to use it (I know it's a bad idea, but people do it anyway - look at how 
much time it took for people to upgrade from Windows XP, after it was 
EOL'd). But Windows 10 is still supported, so it can be used, it's not 
more dangerous than Windows 11.


So the question is, why should cloud providers care about Windows 11? 
Long term, yes, they do care, but none of their Windows users are in a 
hurry to upgrade, they are fine staying on Windows 10 until 2025, 
there's nothing in Windows 11 that makes it worth upgrading (in my 
personal opinion), especially not for server/cloud use. I must check 
this (please correct me if I'm wrong), but I think Windows Server 2019 
still supports legacy BIOS and has extended support until January 2029.




(**) Yes, some may prefer living in a
Windows-less world, but the reality is that
(especially at business scale) there are
services and applications that require
Windows today, and will likely require
Windows for a number of tomorrows.
Like I said, Windows 10 supports i686 + Legacy BIOS, as well as x86_64 + 
Legacy BIOS until at least October 14, 2025.


(***) Yes, using multiple cloud providers
is often advantageous to avoid vendor
lock-in and provider failures, but scale
(at one provider) can result in savings
(both expense, and duplication of work
supporting the different providers' services).
There is statement by a VC regarding
startups which is (essentially) everyone
should start by using AWS, and then
have a plan to move off when their
scale is sufficient (of course, many
startups never survive sufficiently long
to move off, and others simply prefer
to spend their (precious) engineering
resources in other ways).

() Yes, some hope coreboot/linuxboot
can replace UEFI (and it can in some use
cases).  But unless/until MS embraces it,
UEFI is the answer (even if one is still
discussing the question that was asked).
I believe the PC-compatible coreboot payloads are the way to go - either 
coreboot+SeaBIOS or coreboot+TianoCore. I don't know what's the state of 
TianoCore and whether it works on real hardware. I have one working 
system with coreboot+SeaBIOS (it's a Chromebook) and I'd like to be able 
to use it.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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:

[Bug 2073800] perl-Config-General-2.64 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2073800

Paul Howarth  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value



--- Comment #2 from Paul Howarth  ---
Hi Nathanael, I'm happy to handle this one if you like.
If you do it yourself, please note that the License: tag should now be
"Artistic 2.0".


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073800
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2073800] perl-Config-General-2.64 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2073800



--- Comment #1 from Upstream Release Monitoring 
 ---
Scratch build failed. Details below:

GenericError: File upload failed:
cli-build/1649593043.0537996.dTYmzmcF/perl-Config-General-2.64-1.fc34.src.rpm
Traceback:
  File
"/usr/local/lib/python3.9/site-packages/hotness/use_cases/package_scratch_build_use_case.py",
line 56, in build
result = self.builder.build(request.package, request.opts)
  File "/usr/local/lib/python3.9/site-packages/hotness/builders/koji.py", line
198, in build
output["build_id"] = self._scratch_build(session, package.name, srpm)
  File "/usr/local/lib/python3.9/site-packages/hotness/builders/koji.py", line
451, in _scratch_build
session.uploadWrapper(source, serverdir)
  File "/usr/lib/python3.9/site-packages/koji/__init__.py", line 3053, in
uploadWrapper
self.fastUpload(localfile, path, name, callback, blocksize, overwrite,
volume=volume)
  File "/usr/lib/python3.9/site-packages/koji/__init__.py", line 2988, in
fastUpload
raise GenericError("File upload failed: %s/%s" % (path, name))

If you think this issue is caused by some bug in the-new-hotness, please report
it on the-new-hotness issue tracker:
https://github.com/fedora-infra/the-new-hotness/issues


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073800
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2073800] New: perl-Config-General-2.64 is available

https://bugzilla.redhat.com/show_bug.cgi?id=2073800

Bug ID: 2073800
   Summary: perl-Config-General-2.64 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Config-General
  Keywords: FutureFeature, Triaged
  Assignee: nathan...@gnat.ca
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: lkund...@v3.sk, nathan...@gnat.ca, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 2.64
Current version/release in rawhide: 2.63-17.fc36
URL: http://search.cpan.org/dist/Config-General/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/2714/


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2073800
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora 36 compose report: 20220410.n.0 changes

2022-04-10 Thread Fedora Rawhide Report

OLD: Fedora-36-20220409.n.0
NEW: Fedora-36-20220410.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   0 B
Size of downgraded packages: 0 B

Size change of upgraded packages:   0 B
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Python_Classroom vagrant-virtualbox x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-36-20220409.n.0.x86_64.vagrant-virtualbox.box
Image: Python_Classroom vagrant-libvirt x86_64
Path: 
Labs/x86_64/images/Fedora-Python-Classroom-Vagrant-36-20220409.n.0.x86_64.vagrant-libvirt.box
Image: Container_Minimal_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Minimal-Base-36-20220409.n.0.aarch64.tar.xz

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Nikolay Nikolov

On 4/10/22 09:56, Thomas Schmitt wrote:

Hi,

Nikolay Nikolov wrote:

Maybe I should try adapting my code, so that it finds the GRUB BIOS boot
partition and loads it?

This would be a nice stunt for which we would have to find a use case.
As stated yesterday, the GRUB El Torito image contains a core.img which
serves the same purpose as a BIOS partition.
The use case I'm thinking about is not for the install image, but for
hard disk installations in legacy BIOS mode, that use the GPT partition
scheme, instead of the MBR partition scheme. In this case, with my MBR
bootloader code, you still need the extra GRUB BIOS boot partition, but
it can be moved anywhere on the disk, without breaking the bootloader.
In the case of the traditional GRUB MBR code, you would need to boot
from a rescue media and reinstall the bootloader, every time this
partition is moved (or partition tools should treat it as unmovable,
which reduces your flexibility). The disadvantage of my MBR boot code is
that it doesn't support really old systems without the INT 13h LBA
extensions. And you cannot detect in the distro installer whether the
system supports these extensions or not, so if it's installed by
default, some old systems would be rendered unbootable. In theory,
anything that supports x86_64 should support these extensions (they were
introduced in the Windows 95/98 times, when hard drives started hitting
the 8 GB mark, while x86_64 appeared much later, in 2003, at the time
hard drives were hitting 160GB-200GB as far as I can remember, and the 8
GB limit was becoming a joke), however I don't know what's the reality,
BIOSes are surprisingly buggy.

the main obstacle is
that I'm not familiar with GRUB's code and I don't know what GRUB's next
stage needs

I myself only learn about GRUB at occasions like this here.
There is a vivid community at grub-de...@gnu.org. If you have an
interesting use case they might be willing to explain things. But on the
other hand the BIOS stuff is old and Vladimir Serbinenko, who created it,
is not very busy with GRUB any more.
Yeah, I'll join that mailing list and explain the use case I have in
mind (the one that I described above).

Unfortunately, I'm not familiar with how El Torito works,

Roughly:

At 2048-byte-LBA 17 (decimal) there is the Boot Record, which points to
the El Torito Boot Catalog. The catalog contains entries, which describe
boot images. In case of Fedora Live there are three of them: One for BIOS,
and two for EFI.

The boot image for BIOS is a plain x86 program. The first EFI image is
a FAT filesystem with boot programs /EFI/BOOT/BOOT*.EFI for the intended
processor architectures (x86-32bit, x86-64bit, ARM-32bit, ... ).

The second boot image for EFI (macboot.img) is actually a HFS+ filesystem
image which should not be listed in the catalog. That's a hack by Matthew
J. Garrett to let the rather dumb ISOLINUX program isohybrid.c find the
HFS+ image and mark it by an Apple Partition Map. isohybrid.c does not
understand ISO 9660 but it knows the El Torito boot catalog.
Fedora does not use isohybrid.c any more, but rather lets libisofs under
xorriso create the Apple Partition Map, if at all. Nevertheless, xorriso
produces the same inappropriate catalog entry for EFI, which the firmware
ignores in favor of the appropriate EFI boot image.
(Who am i to change mjg's invention ?)

My knowledge about boot lures for various processors and firmwares is
compiled at

https://dev.lovelyhq.com/libburnia/libisofs/raw/branch/master/doc/boot_sectors.txt

Original specs:

El Torito:

http://web.archive.org/web/20010706014919/http://www.ibm.com/products/surepath/documents/standard/cdrom7.pdf
UEFI:
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
Legacy BIOS:
Only rumors around. Start exploring at Wikipedia. Re-use your knowledge
about BIOS booting from floppy/hard disk/USB flash drive.

Thanks for the explanation and the links. I'll check them out.

This hybrid USB stick/DVD iso image has always seemed
like black magic to me :)

It's just a matter of outmost cramming of boot lures which are barely
compatible. (The unusual block size 2048 for Apple Partition Map
gives room for GPT. Some noop-x86 code at the start of the MBR lets
it look like the first block of an Apple Partition Map. It's just weird
from the view of specs and BIOS tradition. But it works since 10 years.)

I imagine it is like those polyglot programs, that are simultaneously
valid in several totally different programming languages:

https://en.wikipedia.org/wiki/Polyglot_(computing)

AFAIK, Windows only
provides an ISO download, that is suitable for burning on optical media and
then it boots, but it doesn't work, when you "dd" it to an USB flash drive.
I think you need to use special tool, to write it to a USB stick,

You are supposed to create a FAT filesystem in a MBR partition of the
USB stick with a traditional partition type like 0x0C. Then you copy all
files

Fedora rawhide compose report: 20220410.n.0 changes

2022-04-10 Thread Fedora Rawhide Report

OLD: Fedora-Rawhide-20220408.n.2
NEW: Fedora-Rawhide-20220410.n.0

= SUMMARY =
Added images:6
Dropped images:  0
Added packages:  3
Dropped packages:0
Upgraded packages:   60
Downgraded packages: 0

Size of added packages:  768.69 KiB
Size of dropped packages:0 B
Size of upgraded packages:   8.42 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   33.58 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: i3 live x86_64
Path: Spins/x86_64/iso/Fedora-i3-Live-x86_64-Rawhide-20220410.n.0.iso
Image: Container_Base docker aarch64
Path: 
Container/aarch64/images/Fedora-Container-Base-Rawhide-20220410.n.0.aarch64.tar.xz
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20220410.n.0.s390x.tar.xz
Image: Container_Base docker ppc64le
Path: 
Container/ppc64le/images/Fedora-Container-Base-Rawhide-20220410.n.0.ppc64le.tar.xz
Image: LXQt live x86_64
Path: Spins/x86_64/iso/Fedora-LXQt-Live-x86_64-Rawhide-20220410.n.0.iso
Image: Container_Base docker x86_64
Path: 
Container/x86_64/images/Fedora-Container-Base-Rawhide-20220410.n.0.x86_64.tar.xz

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: python-google-cloud-source-context-1.2.2-3.fc37
Summary: Python Client for Google Cloud Source Context
RPMs:python3-google-cloud-source-context
Size:30.34 KiB

Package: python-matplotlib-venn-0.11.7-1.fc37
Summary: Routines for plotting area-weighted two- and three-circle venn diagrams
RPMs:python3-matplotlib-venn
Size:50.77 KiB

Package: rust-nu-utils-0.60.0-1.fc37
Summary: Nushell utility functions
RPMs:nu-utils rust-nu-utils+default-devel rust-nu-utils-devel
Size:687.58 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  NetworkManager-sstp-1:1.2.7-0.20220407git182a55b9.fc37
Old package:  NetworkManager-sstp-1:1.2.6-11.fc36
Summary:  NetworkManager VPN plugin for SSTP
RPMs: NetworkManager-sstp NetworkManager-sstp-gnome
Size: 881.95 KiB
Size change:  111.52 KiB
Changelog:
  * Thu Apr 07 2022 Marcin Zajaczkowski  - 
1:1.2.7-0.20220407git182a55b9
  - Update to 1.2.7-SNAPSHOT
  - Build gtk4 variant for Fedora 36+ (BZ #2064985)
  - Enable pppd_auth_notify_support for ppp >= 2.4.9


Package:  audacity-3.1.3-1.fc37
Old package:  audacity-3.0.2-6.fc36
Summary:  Multitrack audio editor
RPMs: audacity audacity-manual
Size: 42.73 MiB
Size change:  9.41 MiB
Changelog:
  * Sun Apr 10 2022 Ian McInerney  - 3.1.3-1
  - Update to upstream release 3.1.3
  - Remove conditionals for Fedora 33 (it is now EOL)
  - Unbundle sqlite and use the system version (rhbz: #1973455)
  - Force X11 backend in GTK to fix cursor scroll (rhbz: #2024019)
  - Fix builds when using wxWidgets 3.1.6 (rhbz: #2072823)


Package:  awscli-1.22.92-1.fc37
Old package:  awscli-1.22.91-1.fc37
Summary:  Universal Command Line Environment for AWS
RPMs: awscli
Size: 2.17 MiB
Size change:  -278 B
Changelog:
  * Fri Apr 08 2022 Gwyn Ciesla  - 1.22.92-1
  - 1.22.92


Package:  baresip-2.0.2-1.fc37
Old package:  baresip-2.0.1-1.fc37
Summary:  Modular SIP user-agent with audio and video support
RPMs: baresip baresip-aac baresip-alsa baresip-av1 baresip-codec2 
baresip-ctrl_dbus baresip-g722 baresip-g726 baresip-gsm baresip-gst 
baresip-gst_video baresip-gtk baresip-jack baresip-mpa baresip-mqtt baresip-omx 
baresip-opus baresip-plc baresip-portaudio baresip-pulse baresip-sdl 
baresip-snapshot baresip-sndfile baresip-tools baresip-v4l2 baresip-vp8 
baresip-vp9 baresip-x11
Size: 5.27 MiB
Size change:  3.16 KiB
Changelog:
  * Sat Apr 09 2022 Robert Scheck  2.0.2-1
  - Upgrade to 2.0.2 (#2073684)


Package:  ceph-2:17.1.0-0.9.175.g086c8f84.fc37
Old package:  ceph-2:17.1.0-0.7.123.g14f44febd.fc37
Summary:  User space components of the Ceph file system
RPMs: ceph ceph-base ceph-common ceph-fuse ceph-grafana-dashboards 
ceph-immutable-object-cache ceph-mds ceph-mgr ceph-mgr-cephadm 
ceph-mgr-dashboard ceph-mgr-diskprediction-local ceph-mgr-k8sevents 
ceph-mgr-modules-core ceph-mgr-rook ceph-mon ceph-osd ceph-prometheus-alerts 
ceph-radosgw ceph-resource-agents ceph-selinux ceph-test ceph-volume cephadm 
cephfs-java cephfs-mirror cephfs-shell cephfs-top libcephfs-devel libcephfs2 
libcephfs_jni-devel libcephfs_jni1 libcephsqlite libcephsqlite-devel 
librados-devel librados2 libradospp-devel libradosstriper-devel 
libradosstriper1 librbd-devel librbd1 librgw-devel librgw2 
python3-ceph-argparse python3-ceph-common python3-cephfs python3-rados 
python3-rbd python3-rgw rados-objclass-devel rbd-fuse rbd-mirror rbd-nbd
Size: 379.58 MiB
Size change:  44.08 MiB
Changelog:
  * Fri Apr 08 2022 Kaleb S. KEITHLEY  - 
2:17.1.0-0.9.175.g086c8f84
  - 17.1.0 snapshot 175


Package:  clojure-core-specs-alpha-1:0.2.62-1.fc37
Old package:  clojure-core-specs-alpha-1:0.2.56-4.fc36
Summary:  Cloj

Fedora-Cloud-34-20220410.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-20220409.0):

ID: 1218832 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1218832
ID: 1218841 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1218841

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-35-20220410.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-20220409.0):

ID: 1218816 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1218816
ID: 1218825 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1218825

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2073267] perl-Mail-DKIM-1.20220408 is available