Aoife Moloney wrote:
> This change is for Fedora Linux 41, and not 411 as the typo in the heading
> suggests :)
Glad that we do not have to wait 185 years ((411-41)/2=185) for this
feature. ;-)
Kevin Kofler
--
___
devel mailing list -- devel@li
On Wed, Jun 19, 2024 at 11:58 AM Miro Hrončok wrote:
>
> On 18. 06. 24 18:46, Miroslav Suchý wrote:
> > Hi.
> >
> > I am going to do the mass change of the license from GPLv2 to GPL-2.0-only
>
> Hi.
>
> How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND
> MIT" or similar?
On 19. 06. 24 23:32, Miroslav Suchý wrote:
Dne 19. 06. 24 v 5:58 odp. Miro Hrončok napsal(a):
How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND
MIT" or similar?
Converting "GPLv2" (which could mean any number of "weaker" licenses are
hidden under the "stronger" GP
Dne 19. 06. 24 v 5:58 odp. Miro Hrončok napsal(a):
How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND
MIT" or similar?
Converting "GPLv2" (which could mean any number of "weaker" licenses are hidden under the "stronger" GPL in the old
notation) to "GPL-2.0-only" (whi
> Another option is to package the nvidia-kmod-open module into Fedora and
> sign it with Fedora key.
>
> Starting with version 555, nvidia-kmod-open will be the default option.
Fedora doesn't allow any out-of-tree modules, so that idea is a non-starter.
--
On Wed, Jun 19, 2024 at 2:55 PM Gary Buhrmaster
wrote:
> On Wed, Jun 19, 2024, 11:33 Vitaly Zaitsev via devel <
> devel@lists.fedoraproject.org> wrote:
>
> Another option is to package the nvidia-kmod-open module into Fedora and
>> sign it with Fedora key.
>>
>> Starting with version 555, nvidia-
On Wed, Jun 19, 2024, 11:33 Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:
Another option is to package the nvidia-kmod-open module into Fedora and
> sign it with Fedora key.
>
> Starting with version 555, nvidia-kmod-open will be the default option.
>
As I recall, only the defa
On Wed, Jun 19, 2024 at 8:40 PM Peter Robinson wrote:
>
> On Wed, 19 Jun 2024 at 19:13, Dominik 'Rathann' Mierzejewski
> wrote:
> >
> > On Wednesday, 19 June 2024 at 17:17, drago01 wrote:
> > > [...] at some point we need to do the cut and not being held back by old
> > > / ancient hardware forev
On Wed, Jun 19, 2024 at 08:13:39AM +0100, Richard W.M. Jones wrote:
> Jerry James discovered a code gen bug in the latest OCaml 5.2 on
> Rawhide:
>
> https://github.com/ocaml/ocaml/issues/13220
>
> Luckily this only affects ppc64le and is obvious when you hit it,
> producing an error rather than
On Wed, 19 Jun 2024 at 19:13, Dominik 'Rathann' Mierzejewski
wrote:
>
> On Wednesday, 19 June 2024 at 17:17, drago01 wrote:
> > [...] at some point we need to do the cut and not being held back by old
> > / ancient hardware forever.
>
> What do you mean by "being held back"? What's being prevented
On 19/06/2024 19:45, Jonathan Steffan wrote:
Unless the private key is off-system, anything will be able to be loaded
without much fuss.
Maybe akmods can be updated to use the private key stored in TPM 2.0 if
the system has one?
While it does *feel* better, both options effectively remove a
On Thu, 13 Jun 2024 at 13:58, Chris Adams wrote:
>
> Once upon a time, Ben Cotton said:
> > For myself, I think it's reasonable to conclude there's a non-trivial
> > amount of people using QEMU on that hardware in some fashion. Much of
> > that is probably from podman as opposed to running large
On Wednesday, 19 June 2024 at 17:17, drago01 wrote:
> [...] at some point we need to do the cut and not being held back by old
> / ancient hardware forever.
What do you mean by "being held back"? What's being prevented by not
requiring x86-64-v2 for all packages while allowing few select ones to
h
Please note that switching to x86_64-v2 does *not* give you access to
AVX2 or even AVX. It stops at SSE4.2 with POPCNT.
AVX2 means x86_64-v3, which both excludes a lot more hardware and allows
(in some cases) much more significant performance gains.
On 6/19/24 3:29 AM, Vitaly Zaitsev via deve
On Wed, Jun 19, 2024 at 11:33 AM Vitaly Zaitsev via devel <
devel@lists.fedoraproject.org> wrote:
> On 19/06/2024 17:49, Daniel P. Berrangé wrote:
> > This allows
> > any privileged process to sign any future kmods, from any source.
>
> Yes. That's why it is preferable to ship built and signed in
On 19/06/2024 17:49, Daniel P. Berrangé wrote:
This allows
any privileged process to sign any future kmods, from any source.
Yes. That's why it is preferable to ship built and signed in Koji kmod
packages, but nobody want to do this: neither Fedora nor RPM Fusion.
Without a signature, the ke
On Wed, 2024-06-19 at 17:38 +0200, Leigh Scott wrote:
> I don't see the security issue, gnome-software does require admin
> rights to install packages?
Hi,
gnome-software currently uses PackageKit to install packages. The
PackageKit has some polkit rules when to ask for the admin password
On 18. 06. 24 18:46, Miroslav Suchý wrote:
Hi.
I am going to do the mass change of the license from GPLv2 to GPL-2.0-only
Hi.
How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND
MIT" or similar?
Converting "GPLv2" (which could mean any number of "weaker" licenses a
On Wed, Jun 19, 2024 at 02:45:33PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Jun 17, 2024 at 12:44:53PM +0100, Aoife Moloney wrote:
> > What we're doing this time is using mokutil to create a key for the
> > user to self-sign the drivers. When installing the drivers, the user
> > is asked
> Once /etc/pki/akmods/certs/public_key.der is generated, it is used to sign
> any akmod-*
> package installed or updated.
>
>
> https://src.fedoraproject.org/rpms/kmodtool/c/1900f33c17ff4bc1011be4279ff...
The user (with admin rights) is free to install akmod-rootkit and kmodtool will
sign it
On Wed, Jun 19, 2024 at 12:23:51PM -0300, Emanuel Lima wrote:
> I orphaned NVML as Intel discontinued Optane (
> https://pmem.io/announcements/2023/customer-letter-march-2023/) and I'm
> having trouble finding the time to maintain the package. The question that
> remains is whether QEMU still depen
Once /etc/pki/akmods/certs/public_key.der is generated, it is used to sign any
akmod-* package installed or updated.
https://src.fedoraproject.org/rpms/kmodtool/c/1900f33c17ff4bc1011be4279ff13a7eb6a046b1?branch=rawhide
--
___
devel mailing list -- dev
I orphaned NVML as Intel discontinued Optane (
https://pmem.io/announcements/2023/customer-letter-march-2023/) and I'm
having trouble finding the time to maintain the package. The question that
remains is whether QEMU still depends on NVML or not. I got conflicting
information about that. Does anyo
On Wednesday, June 19, 2024, Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:
> On Wednesday, 19 June 2024 at 10:39, Neal Gompa wrote:
> > On Wed, Jun 19, 2024 at 9:29 AM Vitaly Zaitsev via devel
> > wrote:
> > >
> > > On 19/06/2024 09:13, Daniel P. Berrangé wrote:
> > > > If Fedor
On Mon, Jun 17, 2024 at 12:44:53PM +0100, Aoife Moloney wrote:
> What we're doing this time is using mokutil to create a key for the
> user to self-sign the drivers. When installing the drivers, the user
> is asked to provide a password for the key. On the next reboot the
> user is presented with t
On Wed, 2024-06-19 at 14:39 +0200, Daniel P. Berrangé wrote:
> the default software installation tool promoting this is a
> recommended solution to users. The latter is blessing this is a
> preferred feature of the distro.
Hi,
does there exist any other way to make the drivers work, withou
On 17/06/2024 13:44, Aoife Moloney wrote:
The goal is this change is to provide an easy way to install Nvidia
drivers in Fedora Workstation.
Someone should fix this issue first:
https://bugzilla.redhat.com/show_bug.cgi?id=2011120
It breaks offline updates.
I think the system-upgrade plugin sh
On Wed, Jun 19, 2024 at 02:30:20PM +0200, Vitaly Zaitsev via devel wrote:
> On 19/06/2024 13:10, Daniel P. Berrangé wrote:
> > Should this be a system-wide change, rather than self-contained
> > change ? While the implementation is in gnome-software, since this
> > is semi-automating enrollment of
On 19/06/2024 13:10, Daniel P. Berrangé wrote:
Should this be a system-wide change, rather than self-contained
change ? While the implementation is in gnome-software, since this
is semi-automating enrollment of a new SecureBoot MOK, with the
private key strored locally, it has security impact on
On Wednesday, 19 June 2024 at 10:39, Neal Gompa wrote:
> On Wed, Jun 19, 2024 at 9:29 AM Vitaly Zaitsev via devel
> wrote:
> >
> > On 19/06/2024 09:13, Daniel P. Berrangé wrote:
> > > If Fedora cares
> > > about optimal performance it should just declare we're going to stop
> > > being held back b
On Wed, 2024-06-19 at 13:10 +0200, Daniel P. Berrangé wrote:
> While the implementation is in gnome-software, since this
> is semi-automating enrollment of a new SecureBoot MOK, with the
> private key strored locally, it has security impact on the distro
> as a whole.
Hi,
you are right, it
On Mon, Jun 17, 2024 at 12:44:53PM +0100, Aoife Moloney wrote:
> Wiki - https://fedoraproject.org/wiki/Changes/NvidiaInstallationWithSecureboot
> Discussion Thread -
> https://discussion.fedoraproject.org/t/f41-change-proposal-nvidia-driver-installation-with-secure-boot-support-self-contained/12033
Am 13.02.24 um 18:52 schrieb Julian Sikorski:
Am 13.02.24 um 16:16 schrieb Gary Buhrmaster:
On Tue, Feb 13, 2024 at 9:52 AM Miroslav Suchý wrote:
Dne 13. 02. 24 v 9:08 Julian Sikorski napsal(a):
Could this be the reason for ccache not working?
I wonder whether it is Mock problem, Ccache is
Hi folks,
it's this time of the year, we should do some major filesystem surgery!
The preparations for
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin have been
put in place and I want to do the rebuild of filesystem.rpm rpm.rpm,
and other packages that will effectuate the merge.
What
On Tue, May 21, 2024 at 10:57:42AM GMT, Leo Sandoval wrote:
> Hi team,
>
> We (the Red Hat bootloader team) are completing the work of
> rebasing/reviewing/testing current rawhide patches, from GRUB2 2.06 to
> 2.12, so at
> some point in the near future these would land finally into rawhide. Once
On Mon, 2024-06-17 at 17:44 +0200, Leigh Scott wrote:
> I wont be re-adding the AppStream metadata into the Nvidia driver
> repo until someone files a proper request at rpmfusion.
Hi,
here you are:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=6976
If there's anything I can help with, j
On Wed, Jun 19, 2024 at 9:29 AM Vitaly Zaitsev via devel
wrote:
>
> On 19/06/2024 09:13, Daniel P. Berrangé wrote:
> > If Fedora cares
> > about optimal performance it should just declare we're going to stop
> > being held back by compat with ancient hardware and use -v2 baseline
> > for everythin
On 19/06/2024 09:13, Daniel P. Berrangé wrote:
If Fedora cares
about optimal performance it should just declare we're going to stop
being held back by compat with ancient hardware and use -v2 baseline
for everything, but obviously that's been rejected previously.
Maybe it's a good time for the
On Mon, Jun 17, 2024 at 07:37:15AM -0500, Chris Adams wrote:
> Once upon a time, Daniel P. Berrangé said:
> > I think I've convinced upstream to change their approach to make their
> > recent changes a compile-time opt-in, to allow build time choice of the
> > non-optimized code, rather than forci
Jerry James discovered a code gen bug in the latest OCaml 5.2 on
Rawhide:
https://github.com/ocaml/ocaml/issues/13220
Luckily this only affects ppc64le and is obvious when you hit it,
producing an error rather than silently miscompiling code.
Nevertheless I'm going to fix it today. Unfortunatel
40 matches
Mail list logo
