jplesnik merged a pull-request against the project: `perl-Bit-Vector` that you
are following.
Merged pull-request:
``
Tests
``
https://src.fedoraproject.org/rpms/perl-Bit-Vector/pull-request/2
___
perl-devel mailing list --
https://bugzilla.redhat.com/show_bug.cgi?id=2155733
Bug ID: 2155733
Summary: perl-Data-Printer-1.001000 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Data-Printer
Keywords: FutureFeature,
On 12/21/22 21:08, Neal Gompa wrote:
> On Wed, Dec 21, 2022 at 4:49 PM Ben Cotton wrote:
>>
>> https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients
>>
>> This document represents a proposed Change. As part of the Changes
>> process, proposals are publicly announced in order
https://bugzilla.redhat.com/show_bug.cgi?id=2155727
--- Comment #2 from Upstream Release Monitoring
---
the-new-hotness/release-monitoring.org's scratch build of
perl-Perl-Critic-1.146-1.fc36.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=95609124
--
You
https://bugzilla.redhat.com/show_bug.cgi?id=2155727
--- Comment #1 from Upstream Release Monitoring
---
Created attachment 1934073
--> https://bugzilla.redhat.com/attachment.cgi?id=1934073=edit
Update to 1.146 (#2155727)
--
You are receiving this mail because:
You are on the CC list for
https://bugzilla.redhat.com/show_bug.cgi?id=2155727
Bug ID: 2155727
Summary: perl-Perl-Critic-1.146 is available
Product: Fedora
Version: rawhide
Status: NEW
Component: perl-Perl-Critic
Keywords: FutureFeature, Triaged
On Wed, Dec 21, 2022 at 09:15:10PM -0700, Orion Poplawski wrote:
> I've been using an old review_pr.py script produced by the Fedora
> Stewardship SIG to rebuild the depedencies of a package in COPR to test
> changes/updates to packages. It's been incredibly useful. However, it
> seems that the
I've been using an old review_pr.py script produced by the Fedora
Stewardship SIG to rebuild the depedencies of a package in COPR to test
changes/updates to packages. It's been incredibly useful. However, it
seems that the github repo has disappeared.
Is there anything else out there in use
Welcome Hussein!
On Wed, 21 Dec 2022 at 01:23, Sandro Mani wrote:
> Hi
>
> I'd like to mentor Hussein (FAS: blinxen) in learning to become a
> packager. He is a work colleague of mine. In particular, he's helping me
> getting libimagequant updated, which some time ago was ported to rust.
> As
On Wed, Dec 21, 2022 at 4:49 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This
The following Fedora EPEL 8 Security updates need testing:
Age URL
5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5d08436b7d
davix-0.8.3-1.el8
5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-49c3f833e1
libptytty-2.0-2.el8 rxvt-unicode-9.30-3.el8
1
https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora
https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora
On Tue, 13 Dec 2022 19:09:48 +0100
Dan Horák wrote:
> On Tue, 13 Dec 2022 09:56:40 -0800
> Troy Dawson wrote:
>
> > Packages do not automatically get transferred over from epel7 to a newer
> > epel. People have to request them.
> > Nobody has requested it for epel9.
> >
From the point of view of the workstation experience (with a laptop),
I see no discussion on how this may impact hibernation. Currently, I
have secure boot disabled essentially because I want my laptop to
automatically hibernate (and recover from that state) whenever it is
suspended for a number
On Di, 20.12.22 17:11, Neal Gompa (ngomp...@gmail.com) wrote:
> > SecureBoot may not be to your liking but is what is installed on 99% of
> > modern hardware sold, so it is a good idea to first show you can
> > support it. Then if you have interested you can propose "something
> > better".
>
> We
To answer the first question about 'domain decomposition'.. I don't
think it is something that 'most' or 'many' customers deal with.
Fair enough, but for HPC scientific applications it is definitely a
go-to functionality.
In that case, the usual method is 'build it yourself' or 'work with
On Di, 20.12.22 21:32, Neal Gompa (ngomp...@gmail.com) wrote:
> As someone whose day job involves working with teams who develop both
> Windows and Linux drivers (and in the past, even macOS drivers!), I
> can categorically say that Windows driver engineering processes are
> way friendlier than
On Di, 20.12.22 11:28, Neal Gompa (ngomp...@gmail.com) wrote:
> I think UKIs are fundamentally flawed and are an idea that came out of
> a group that doesn't really interact with real users enough to
> understand how much of a problem they actually are.
I presume this is supposed to be a comment
On Wed, 21 Dec 2022 at 12:32, Mark Olesen wrote:
> Yup, scotch doesn't seem to be in CBR either.
> Doesn't even seem to be a metis library anymore either. This all seems
> to be a bit odd - how do people manage domain decomposition without
> metis, or scotch (and ptscotch)? Or is it expected
In my case, I have Network Manager config files included in my initrd
and bootargs to bring up the network so that I get automatic disk
decryption while on my home network, and prompted for a password when
I am not at home. I think this a reasonable enough use case it should
be considered in the
On Mi, 21.12.22 12:38, Neal Gompa (ngomp...@gmail.com) wrote:
> > sd-boot implements boot counting by stashing the counter inside the
> > UKI (or bootspec type #1 conf file) file name, so that the counter is
> > impossible to ever get lost, pile up or so.
>
> Because the ESP is intended to be
Gerd Hoffmann wrote:
> On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> > And if you chose your HW carefully you may even be able to register
> > your own public keys, generate and sign your own built UKIs and re-
> > enable SecureBoot after that... your choice!
>
> And when your
Gerd Hoffmann wrote:
> On Tue, Dec 20, 2022 at 08:42:14PM +0100, Björn Persson wrote:
> > > Switching the whole distro over to unified kernels quickly is not
> > > realistic though. Too many features are depending on the current
> > > workflow with a host-specific initrd (and host-specific kernel
On Mi, 21.12.22 12:35, Neal Gompa (ngomp...@gmail.com) wrote:
> > And similar for server/embedded stuff. If fedora wants to be deployed
> > in such worlds, it's kinda nice if we can automatically recover from
> > hosed updates.
>
> None of those things require us to write data to /boot. Even in
On Wed, 2022-12-21 at 18:31 +0100, Mark Olesen via devel wrote:
> Yup, scotch doesn't seem to be in CBR either.
> Doesn't even seem to be a metis library anymore either. This all
> seems
> to be a bit odd - how do people manage domain decomposition without
> metis, or scotch (and ptscotch)? Or
On Wed, Dec 21, 2022 at 01:32:10PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote:
> [...]
> > Let me put together a few points to sum this up:
> >
> > 1) DNF name is well established, keep the DNF name (and forget about YUM).
> >
> > 2)
On Tue, Dec 20, 2022 at 11:28:48AM -0500, Neal Gompa wrote:
> On Tue, Dec 20, 2022 at 10:22 AM Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
> I think UKIs are fundamentally flawed and are an idea that came out of
> a group that doesn't really
On Wed, Dec 21, 2022 at 12:33 PM Lennart Poettering
wrote:
>
> On Mi, 21.12.22 07:40, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > And journaling actually is more a problem than a solution due to
> > > firmware (or grub) filesystem drivers often not having full support for
> > > the journal.
On Wed, Dec 21, 2022 at 12:29 PM Lennart Poettering
wrote:
>
> On Mi, 21.12.22 12:21, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > > > > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > > > > is used for the same functional pupose as the ESP, which is
> > > > > already going to
On Mi, 21.12.22 07:40, Neal Gompa (ngomp...@gmail.com) wrote:
> > And journaling actually is more a problem than a solution due to
> > firmware (or grub) filesystem drivers often not having full support for
> > the journal. Luckily this is rarely a problem in practice because /boot
> > is rarely
Yup, scotch doesn't seem to be in CBR either.
Doesn't even seem to be a metis library anymore either. This all seems
to be a bit odd - how do people manage domain decomposition without
metis, or scotch (and ptscotch)? Or is it expected that we should be
rolling this thirdparty software into
On Mi, 21.12.22 12:21, Neal Gompa (ngomp...@gmail.com) wrote:
> > > > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > > > is used for the same functional pupose as the ESP, which is
> > > > already going to use FAT.
> > >
> > > Doesn't support links, lournaling and ACLs.
> >
> >
On Wed, 2022-12-21 at 12:11 -0500, Stephen Smoogen wrote:
>
>
> On Wed, 21 Dec 2022 at 12:03, Sérgio Basto wrote:
> > On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote:
> > > Checking my copr log, it seems that centos-stream-8 (and epel-8)
> > has
> > > this:
> > >
> > >
On Wed, Dec 21, 2022 at 12:15 PM Lennart Poettering
wrote:
>
> On Mi, 21.12.22 12:53, Fedora Development ML (devel@lists.fedoraproject.org)
> wrote:
>
> > On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > > is used for the same
On 12/21/22 12:17, Lennart Poettering wrote:
> On Mi, 21.12.22 12:12, Demi Marie Obenour (demioben...@gmail.com) wrote:
>
>>> At least for the systemd stuff, we carefully made sure that our access
>>> patterns to the ESP both from sd-boot/sd-stub and from userspace are
>>> by default as minimal
On Mi, 21.12.22 14:00, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> > And journaling actually is more a problem than a solution due to
> > firmware (or grub) filesystem drivers often not having full support for
> > the journal. Luckily this is rarely a problem in practice
On Mi, 21.12.22 12:12, Demi Marie Obenour (demioben...@gmail.com) wrote:
> > At least for the systemd stuff, we carefully made sure that our access
> > patterns to the ESP both from sd-boot/sd-stub and from userspace are
> > by default as minimal and robust as we can make them, to minimize
> >
On Mi, 21.12.22 12:53, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > is used for the same functional pupose as the ESP, which is
> > already going to use FAT.
>
>
On 12/21/22 12:00, Lennart Poettering wrote:
> On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote:
>
>> For the general case we need some other option. Could be just stick to
>> grub2 for those cases (we'll continue to need grub2 anyway for bios boot
>> and ppc64le). Or drop an ext4
On Wed, 21 Dec 2022 at 12:03, Sérgio Basto wrote:
> On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote:
> > Checking my copr log, it seems that centos-stream-8 (and epel-8) has
> > this:
> >
> > ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools
> > scotch-devel
On 12/20/22 16:34, Simo Sorce wrote:
> On Tue, 2022-12-20 at 14:56 -0500, Demi Marie Obenour wrote:
>> How do you plan to handle system recovery? For VMs this is much
>> less of a concern, but on bare metal there needs to be a way for
>> a local, authenticated administrator to obtain a root shell
Hi Simo,
On Fri, 14 Oct 2022 18:28:01 +0200,
Simo Sorce wrote:
> At this time, as far as I know, there is no OpenPGP work of any kind on
> supporting PQC algorithms. Furthermore the way we use signatures in RPM
> really has no resemblance to the scenarios OpenPGP was built for.
>
> So we should
On Mi, 21.12.22 06:27, Neal Gompa (ngomp...@gmail.com) wrote:
> On Wed, Dec 21, 2022 at 6:23 AM Vitaly Zaitsev via devel
> wrote:
> >
> > On 20/12/2022 19:56, Chris Murphy wrote:
> > > Great. The gotcha though is this in effect requires a change in the file
> > > system currently mounted at
On Mi, 21.12.22 12:22, Fedora Development ML (devel@lists.fedoraproject.org)
wrote:
> On 20/12/2022 19:56, Chris Murphy wrote: > Great. The gotcha though
> is this in effect requires a change in the file system currently
> mounted at /boot, which is ext4. And ext4 isn't supported by sd-boot
> or
On Wed, 2022-12-21 at 17:58 +0100, Mark Olesen via devel wrote:
> Checking my copr log, it seems that centos-stream-8 (and epel-8) has
> this:
>
> ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools
> scotch-devel x86_64 6.0.5-3.el8 powertools
>
> I was mistaken about it
On Mi, 21.12.22 10:03, Gerd Hoffmann (kra...@redhat.com) wrote:
> For the general case we need some other option. Could be just stick to
> grub2 for those cases (we'll continue to need grub2 anyway for bios boot
> and ppc64le). Or drop an ext4 driver to /boot/efi/EFI/systemd/drivers,
> for
Checking my copr log, it seems that centos-stream-8 (and epel-8) has this:
ptscotch-openmpi-devel x86_64 6.0.5-3.el8 powertools
scotch-devel x86_64 6.0.5-3.el8 powertools
I was mistaken about it working with epel-9. It also fails to load
there. So I guess my question has now
On Mi, 21.12.22 10:16, Chris Adams (li...@cmadams.net) wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and
On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and
On Di, 20.12.22 13:56, Chris Murphy (li...@colorremedies.com) wrote:
> > * Better secure boot support (specifically the initrd is covered by
> > the signature).
>
> We need to solve the glaring hole that is the initrd. There's no
> question about it. I can't really assess if this feature is the
On Wed, Dec 21, 2022 at 10:16:58AM -0600, Chris Adams wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> > Without an initrd we immediately have the following limitations:
> > - all kernel modules needed to mount root must be compiled in
> > - all that code is always loaded and
On Wed, 21 Dec 2022 at 11:05, Michael J Gruber
wrote:
> > The devel package are not included in CentOS repositories unless
> requested
>
> Yes, but Mark reports that his package builds "with EPEL, but not with
> CentOS". As for as I know, we have the following in copr:
>
> chroot "epel 9" has
On Di, 20.12.22 20:42, Björn Persson (Bjorn@rombobjörn.se) wrote:
> The root filesystem is also relevant for troubleshooting, when I take a
> storage device out of a broken computer and connect it to another
> computer to inspect it. Suddenly there are two "discoverable" root
> partitions, and
Once upon a time, Zbigniew Jędrzejewski-Szmek said:
> Without an initrd we immediately have the following limitations:
> - all kernel modules needed to mount root must be compiled in
> - all that code is always loaded and remains in unswappable memory
> - root= syntax is limited to what the
> The devel package are not included in CentOS repositories unless requested
Yes, but Mark reports that his package builds "with EPEL, but not with CentOS".
As for as I know, we have the following in copr:
chroot "epel 9" has base RHEL9 and repos base+AppStream+CRB+Extras+EPEL
chroot "centos
On Tue, Dec 20, 2022 at 07:22:34PM +, Daniel P. Berrangé wrote:
> On Tue, Dec 20, 2022 at 01:56:57PM -0500, Chris Murphy wrote:
> > Or if we could do enough strict standardization in
> > the boot chain with a possibly larger kernel to avoid
> > needing an initrd, i.e. get to sysroot mount
Dne 21. 12. 22 v 16:14 Mark Olesen via devel napsal(a):
I'm using copr for https://copr.fedorainfracloud.org/coprs/openfoam/openfoam/ and now finally also enabled for
building on epel9 and centos-stream-9 (both x86_64).
With the centos-stream-9 I get these messages:
Updating Subscription
On Wed, 21 Dec 2022 14:47:38 +
Sérgio Basto wrote:
> Hi,
>
> Dependencies on glib1 and gtk1 are only bubblemon manedit xconvers ,
> I propose retire it on F38, it's one less burden that we have .
As I've always said when this has come up before, I'll be happy to
retire glib1 and gtk+1
I'm using copr for
https://copr.fedorainfracloud.org/coprs/openfoam/openfoam/ and now
finally also enabled for building on epel9 and centos-stream-9 (both
x86_64).
With the centos-stream-9 I get these messages:
Updating Subscription Management repositories.
Unable to read consumer identity
fpc (the Free Pascal Compiler) also ships with units for developing stuff
with gtk1 - so should we retire gtk+, we'll probably want to patch fpc
so said units are not shipped.
A.FI.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Hi
I built qwt-6.2.0 two days ago but missed the fact that the Provides
changed from to libqwt-qt5.so.6() to libqwt-qt5.so.6.2(). I'll proceed
with rebuilding the following packages to fix the resulting broken
dependencies:
COPASI
gazebo
gnuradio
qgis
qsstv
Apologies for the disruption.
Hi,
Dependencies on glib1 and gtk1 are only bubblemon manedit xconvers , I
propose retire it on F38, it's one less burden that we have .
After start working on GConf2 and after maybe gtk2
Best regards,
--
Sérgio M. B.
___
devel mailing list --
jplesnik opened a new pull-request against the project: `perl-Bit-Vector` that
you are following:
``
Tests
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Bit-Vector/pull-request/2
___
perl-devel mailing list --
Hi
I'll be updating to leptonica-1.83.0, which brings a soname bump. I'll
perform the build in the side tag f38-build-side-61349, rebuilding also
the following dependencies:
mupdf
python-PyMuPDF
tesseract
zathura-pdf-mupdf
Thanks
Sandro
___
https://bugzilla.redhat.com/show_bug.cgi?id=2155545
Richard Shaw changed:
What|Removed |Added
Blocks||2120957
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=2155539
Richard Shaw changed:
What|Removed |Added
Blocks||2120957
Referenced Bugs:
* Miro Hrončok:
> On 21. 12. 22 11:02, Florian Weimer wrote:
>> Is there a lightweight tool to take the repository generated by
>> %autosetup -S, with some new commits on to top, and turn that into a
>> spec file update? That is, generated the new patches, and make a
>> conservative change to
On Wed, Dec 21, 2022 at 12:53:05PM +0100, Vitaly Zaitsev via devel wrote:
> On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > is used for the same functional pupose as the ESP, which is
> > already going to use FAT.
>
> Doesn't
https://bugzilla.redhat.com/show_bug.cgi?id=2155545
Bug ID: 2155545
Summary: Branch and build perl-Net-FTP-RetrHandle for EPEL 9
Product: Fedora EPEL
Version: epel9
Status: NEW
Component: perl-Net-FTP-RetrHandle
Assignee:
https://bugzilla.redhat.com/show_bug.cgi?id=2155539
Bug ID: 2155539
Summary: Branch and build perl-Net-FTP-AutoReconnect for EPEL 9
Product: Fedora EPEL
Version: epel9
Status: NEW
Component: perl-Net-FTP-AutoReconnect
https://bugzilla.redhat.com/show_bug.cgi?id=2155345
Jitka Plesnikova changed:
What|Removed |Added
Doc Type|--- |If docs needed, set a value
On 21/12/2022 13:17, Gerd Hoffmann wrote:
Is that something you need in /boot?
Yes.
And journaling actually is more a problem than a solution due to
firmware (or grub) filesystem drivers often not having full support for
the journal. Luckily this is rarely a problem in practice because
On Wed, Dec 21, 2022 at 7:17 AM Gerd Hoffmann wrote:
>
> On Wed, Dec 21, 2022 at 12:53:05PM +0100, Vitaly Zaitsev via devel wrote:
> > On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > > is used for the same functional pupose as
On Wed, Dec 21, 2022 at 6:48 AM Fabio Valentini wrote:
>
> On Wed, Dec 21, 2022 at 11:02 AM Florian Weimer wrote:
> >
> > Is there a lightweight tool to take the repository generated by
> > %autosetup -S, with some new commits on to top, and turn that into a
> > spec file update? That is,
On Wednesday, 21 December 2022 at 12:31, Vít Ondruch wrote:
[...]
> Let me put together a few points to sum this up:
>
> 1) DNF name is well established, keep the DNF name (and forget about YUM).
>
> 2) Keep the compatibility on reasonable level. 100% compatibility is myth
> (even between the
On Wed, Dec 21, 2022 at 12:53:05PM +0100, Vitaly Zaitsev via devel wrote:
> On 21/12/2022 12:38, Daniel P. Berrangé wrote:
> > Why shouldn't FAT be used for /boot. In an EFI world, /boot
> > is used for the same functional pupose as the ESP, which is
> > already going to use FAT.
>
> Doesn't
On Mon, 2022-12-19 at 19:45 +, Smith, Stewart via devel wrote:
>
> > On Dec 19, 2022, at 7:43 AM, Miro Hrončok
> > wrote:
> >
> > The following packages are orphaned and will be retired when they
> > are orphaned for six weeks, unless someone adopts them. If you know
> > for sure
> > that
On 21/12/2022 12:38, Daniel P. Berrangé wrote:
Why shouldn't FAT be used for /boot. In an EFI world, /boot
is used for the same functional pupose as the ESP, which is
already going to use FAT.
Doesn't support links, lournaling and ACLs.
Everyone can do whatever they want with the files, and
On Wed, Dec 21, 2022 at 11:02 AM Florian Weimer wrote:
>
> Is there a lightweight tool to take the repository generated by
> %autosetup -S, with some new commits on to top, and turn that into a
> spec file update? That is, generated the new patches, and make a
> conservative change to the spec
On 21. 12. 22 11:02, Florian Weimer wrote:
Is there a lightweight tool to take the repository generated by
%autosetup -S, with some new commits on to top, and turn that into a
spec file update? That is, generated the new patches, and make a
conservative change to the spec file?
We have this
On Wed, Dec 21, 2022 at 12:22:25PM +0100, Vitaly Zaitsev via devel wrote:
> On 20/12/2022 19:56, Chris Murphy wrote:
> > Great. The gotcha though is this in effect requires a change in the file
> > system currently mounted at /boot, which is ext4. And ext4 isn't supported
> > by sd-boot or UEFI
On 21/12/2022 12:27, Neal Gompa wrote:
We should not endeavor to create more problems by putting more
stuff in the ESP.
These drivers must be located in firmware-readable location, i.e. ESP.
No matter what boot manager we use, we
should not be required to give that up. We already have
Dne 21. 12. 22 v 11:40 Jaroslav Mracek napsal(a):
I am really sorry, but could we start the discussion from beginning? We use
many personal opinion but we provide very limited set of facts.
I will try to summary some facts related to the naming topic.
We developed a new software management
On Wed, Dec 21, 2022 at 6:23 AM Vitaly Zaitsev via devel
wrote:
>
> On 20/12/2022 19:56, Chris Murphy wrote:
> > Great. The gotcha though is this in effect requires a change in the file
> > system currently mounted at /boot, which is ext4. And ext4 isn't supported
> > by sd-boot or UEFI
On 20/12/2022 19:56, Chris Murphy wrote:
Great. The gotcha though is this in effect requires a change in the file system
currently mounted at /boot, which is ext4. And ext4 isn't supported by sd-boot
or UEFI firmware. So if you're going to support sd-boot, the installer needs to
be aware that
On 21. 12. 22 5:44, Carl George wrote:
I would prefer using the incompat process [0] to upgrade epel9's
python-tox to version 4, and introducing a python-tox3 compat package.
We could use the same naming scheme in Fedora if it makes any sense to
keep tox 3 around there for some period of time.
I am really sorry, but could we start the discussion from beginning? We use
many personal opinion but we provide very limited set of facts.
I will try to summary some facts related to the naming topic.
We developed a new software management tool to replace DNF, MICRODNF, DNF
libraries and
On Tue, Dec 20, 2022 at 08:42:14PM +0100, Björn Persson wrote:
> > Main motivation for this move is to make the distro more robust and more
> > secure.
>
> Improving security would be great, but it must be done in a way that
> allows the sysadmin to configure and repair the system and authorize
mspacek merged a pull-request against the project: `perl-Test-POE-Server-TCP`
that you are following.
Merged pull-request:
``
Package tests and update license to SPDX format
``
https://src.fedoraproject.org/rpms/perl-Test-POE-Server-TCP/pull-request/1
Hi,
> But why start doing UKI without first fixing the need of host specific
> initrd and commandline.
We are trying to tackle that in parallel. At least when generating
virtual machine images we can temporarily workaround that with short
%post scripts in kickstart files.
> I am sure even
On Tue, Dec 20, 2022 at 05:11:57PM -0500, Neal Gompa wrote:
> On Tue, Dec 20, 2022, 4:27 PM Simo Sorce wrote:
>
> > On Tue, 2022-12-20 at 14:29 -0500, Neal Gompa wrote:
> > > Yeah, I seriously doubt this. Linux's model for supporting
> > > confidential computing is not user-friendly, so I expect
On Tue, Dec 20, 2022 at 02:29:22PM -0500, Neal Gompa wrote:
> On Tue, Dec 20, 2022 at 2:02 PM Daniel P. Berrangé
> wrote:
> > > In the Fedora case, things are simpler right up until we hit graphics
> > > drivers. This is also a problem for VMs too, because GPU passthrough
> > > is a common case
On Tue, Dec 20, 2022 at 04:31:20PM -0500, Simo Sorce wrote:
> On Tue, 2022-12-20 at 20:42 +0100, Björn Persson wrote:
> > I note that taking away the kernel command line is indeed a clearly
> > stated goal, which will limit Fedora to simple, appliance-like uses.
>
> And if you chose your HW
Is there a lightweight tool to take the repository generated by
%autosetup -S, with some new commits on to top, and turn that into a
spec file update? That is, generated the new patches, and make a
conservative change to the spec file?
Thanks,
Florian
On Tue, Dec 20, 2022 at 08:42:14PM +0100, Björn Persson wrote:
> > Main motivation for this move is to make the distro more robust and more
> > secure.
>
> Improving security would be great, but it must be done in a way that
> allows the sysadmin to configure and repair the system and authorize
On Wed, Dec 21, 2022 at 03:31:10AM +0100, Kevin Kofler via devel wrote:
> PS (adding to my previous reply):
>
> Daniel P. Berrangé wrote:
> > The immediate need for UKIs is indeed related to SecureBoot and
> > TPMs. These are a core technology foundation of the confidential
> > virtual machine
On Tue, Dec 20, 2022 at 02:56:41PM -0500, Demi Marie Obenour wrote:
> On 12/20/22 10:22, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Unified_Kernel_Support_Phase_1
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly
mspacek opened a new pull-request against the project:
`perl-Test-POE-Server-TCP` that you are following:
``
Package tests and update license to SPDX format
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Test-POE-Server-TCP/pull-request/1
Hi,
> * Enhance parted/libparted to support arbitrary GUIDs and enhance blivet to
> understand the full listing of GUIDs? Or
parted is done, blivet still todo.
https://bugzilla.redhat.com/show_bug.cgi?id=1075288#c7
> the CLI tool seems not to support it but maybe fdisk does.
sfdisk supports
1 - 100 of 111 matches
Mail list logo
