Dne 14. 04. 22 v 2:49 Kevin Kofler via devel napsal(a):
Germano Massullo wrote:
This problem was caused because I had misinterpreted official Red Hat
configuration [2].
The documentation was written with interactive use in mind, not for
scripting or packaging. The "scl enable" tool is very
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-20220413.0):
ID: 1224980 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL:
On Thu, Apr 14, 2022 at 10:01:30AM +0200, Ralf Corsépius wrote:
>
>
> Am 13.04.22 um 20:05 schrieb David Cantrell:
>
> > The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work
> > in
> > Fedora.
>
> I do not agree with this statement. Like previous "Legacy SIGs" this is a
https://bugzilla.redhat.com/show_bug.cgi?id=2066621
Petr Pisar changed:
What|Removed |Added
Assignee|u...@uwog.net |pnem...@redhat.com
https://bugzilla.redhat.com/show_bug.cgi?id=2066621
Petr Pisar changed:
What|Removed |Added
Status|NEW |ON_QA
Fixed In Version|
On 13/04/2022 23:11, Matthew Miller wrote:
It'd be cool to see if we can make a bios-to-uefi thing like Clover work.
I don't think it's possible because the MBR -> GPT conversion will
destroy all partitions on the original drive.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
No, I wanted just the first message to reach both, because I am
subscribed to both lists. Interested people can search archives of the
other list. I expected those lists have very likely disjoint members not
able to write to both.
Feel free to remove epel-devel from further responses here to
On 14.4.2022 02:23, Demi Marie Obenour wrote:
On 4/13/22 17:11, Jóhann B. Guðmundsson wrote:
On 13.4.2022 08:04, David Bold wrote:
It seems I must be missing something? Why should we not care about a
significant number of our users, just because other OSs have more users?
Could you explain
Am 13.04.22 um 20:05 schrieb David Cantrell:
The Legacy BIOS SIG is a good proposal to handle this sort of ongoing work in
Fedora.
I do not agree with this statement. Like previous "Legacy SIGs" this is
a red herring to obfuscate RHATs lack of disinterest with topics, which
do not match
https://bugzilla.redhat.com/show_bug.cgi?id=2071593
Fedora Update System changed:
What|Removed |Added
Status|NEW |MODIFIED
--- Comment #1 from
Hi,
Neal Gompa wrote:
> The binary RPM for grub's BIOS boot code is grub2-pc (and
> grub2-pc-modules), not grub2. But "grub2-pc" is not particularly
> descriptive as a source package name, so grub2-bios makes sense for
> the source package name if we need to split it.
May i propose
On Wed, Apr 13, 2022 at 4:30 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:
> Neal Gompa wrote:
> > dnf, microdnf
>
> Doesn't the change page say the Python DNF will go away?
>
This question will be addressed in a separate change proposal. Fedora 39
can be taken as a primary
On 4/12/22 13:54, Ben Cotton wrote:
== Detailed Description ==
The new major Microdnf will provide huge improvements and in some
cases better behavior then DNF. In the future, the new Microdnf will
replace DNF. The new Microdnf will be accompanied by a new library
(`libdnf5`) and a new DNF
https://bugzilla.redhat.com/show_bug.cgi?id=2075210
--- Comment #1 from Fedora Update System ---
FEDORA-2022-4e37a8c4f8 has been submitted as an update to Fedora 36.
https://bodhi.fedoraproject.org/updates/FEDORA-2022-4e37a8c4f8
--
You are receiving this mail because:
You are on the CC list
101 - 114 of 114 matches
Mail list logo
