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 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
On Wed, Dec 21, 2022 at 03:06:26AM +0100, Kevin Kofler via devel wrote:
> Daniel P. Berrangé wrote:
> > That is not correct. There are a number of benefits of UKIs.
> >
> > The most critical is that the initrd content and cmdline is
> > covered by the SecureBoot signature.
>
> From an end user
On 20/12/2022 23:11, Neal Gompa wrote:
We have supported Secure Boot for over a decade now. In that timeframe,
literally nobody did anything to make all the workflows you talk about
easier and friendlier.
Microsoft wants to limit[1] the use of non-Windows operating systems on
new hardware:
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
On 20/12/2022 22:27, Simo Sorce 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".
Secure Boot with shim and the use of a
On 21/12/2022 03:32, Neal Gompa 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 Linux ones, precisely because
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 21/12/2022 03:03, Kevin Kofler via devel wrote:
IIRC, the reason that Fedora does not use graphical GRUB by default is that
it at least used to break the NVidia proprietary driver.
It works fine on modern NVIDIA driver releases.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
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
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 20/12/2022 16:22, Ben Cotton wrote:
The goal is to move away from initrd images being generated on the
installed machine. They are generated while building the kernel
package instead, then shipped as part of a unified kernel image.
+1.
* Add proper systemd-boot support to installers.
Hi,
> 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 realize that
> this Change is only about VMs, but since it explicitly talks about it
> being
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
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 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
* 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
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 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 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 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 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 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 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 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 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
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
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 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 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 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 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 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 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 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
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
___
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
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
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
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 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
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: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 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:
> > >
> > >
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 --
> 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 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, 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 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 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 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
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.
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
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 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 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 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
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
> >
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
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
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
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 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/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, 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 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.
> >
> >
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 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 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
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
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
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
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
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 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
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 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 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
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
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 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 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 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
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 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
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
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.
> >
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
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
mspacek opened a new pull-request against the project: `perl-Lucy` that you are
following:
``
Update license to SPDX format
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Lucy/pull-request/1
___
perl-devel mailing list --
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
mspacek opened a new pull-request against the project: `perl-Tk-Text-SuperText`
that you are following:
``
Update license to SPDX format
``
To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Tk-Text-SuperText/pull-request/1
___
mspacek merged a pull-request against the project: `perl-Lucy` that you are
following.
Merged pull-request:
``
Update license to SPDX format
``
https://src.fedoraproject.org/rpms/perl-Lucy/pull-request/1
___
perl-devel mailing list --
mspacek merged a pull-request against the project: `perl-Tk-Text-SuperText`
that you are following.
Merged pull-request:
``
Update license to SPDX format
``
https://src.fedoraproject.org/rpms/perl-Tk-Text-SuperText/pull-request/1
___
perl-devel
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.
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:
1 - 100 of 111 matches
Mail list logo