Re: LLVM Packaging Ideas for Fedora 41

On Saturday 27 April 2024 05:34:29 BST Tom Stellard wrote: > Hi, > > * Build compat packages (e.g. llvm18) as early as possible. When we package > a new major release of llvm, we create a compat package so that packages > that aren't compatible with the new version can still use the old version.

Re: Switching XZ for ZSTD?

On Thursday, 4 April 2024 17:20:25 BST Arnie T via devel wrote: > Hello Stephen, > > > How a decision to drop xz for some other compression library for software > > would be a fairly slow process. First a person who is willing to do the > > work would come up with a proposal on why it should be

Re: Mounting USB Storage devices with "sync" option ?

On Friday, 2 February 2024 21:47:00 GMT Dominique Martinet wrote: > So I think Florian is correct in that barriers won't be issued on > these disks, and if they internally have such a cache it'd probably be > unsafe... > > Now does the disk itself know that it's in such an enclosure and >

Re: Mounting USB Storage devices with "sync" option ?

On Wednesday, 31 January 2024 06:43:00 GMT Abyss Ether via devel wrote: > I created a simple PoC udev rule to mount USB Storage devices with the "sync > option. Available here : > https://github.com/larina3315/personal-stuff/blob/main/linux/10-usb-storage > .rules > Currently, USB Storage devices

Re: Adding Passim as a Fedora 40 feature?

On Monday, 28 August 2023 22:07:50 BST Richard Hughes wrote: > On Mon, 28 Aug 2023 at 21:50, Simo Sorce wrote: > > > It could be improved by using TOFU, so that the window of impersonation > > is small, but requires clients to cache an association and then has > > weird failure modes to be dealt

Re: musings on rust packaging [was Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)]

On Wednesday, 30 November 2022 17:47:16 GMT Fabio Valentini wrote: > On Wed, Nov 30, 2022 at 6:21 PM Daniel Alley wrote: > > I feel like there is insufficient recognition of the extent to which C > > libraries do "bundling". Not "bundling" in the sense of vendoring a > > whole library, but in

Re: Potential kTLS issue with TLS-PSK, GnuTLS + Rawhide - how to debug it?

On Friday, 25 November 2022 13:57:26 GMT Richard W.M. Jones wrote: > Turns out this is fixed in upstream gnutls (not the version in > Rawhide). The commit which fixes it is: > > commit 67843b3a8e28e4c74296caea2d1019065c87afb3 > Author: Frantisek Krenzelok > Date: Mon Sep 5 13:05:17 2022 +0200

Re: Building two conflicting binaries from the same source

On Tuesday, 8 November 2022 09:43:40 GMT Richard W.M. Jones wrote: > On Fri, Nov 04, 2022 at 01:44:41PM +0100, Petr Menšík wrote: > > > If there are binaries with different build results, I think some > > code should be refactored out of the binary itself. The common parts > > can remain, but

Re: OpenSSL and ECC patents (was Re: Mesa in F37- vaapi support disabled for h264/h265/vc1)

> On 29 Sep 2022, at 21:37, drago01 wrote: > > > > On Wednesday, September 28, 2022, Clemens Lang > wrote: > Hi, > > Michael J Gruber mailto:m...@fedoraproject.org>> > wrote: > > Understanding is helped greatly by communication, though. Legal answers > such as

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

> On 29 Sep 2022, at 12:52, Tommy Nguyen wrote: > > > >> On Sep 29, 2022, at 7:36 AM, Kevin Kofler via devel >> wrote: >> >> Neal Gompa wrote: >>> Unfortunately, we have to be very careful to not provide a complete >>> codepath to these codecs to avoid legal risks. >> >> Considering that

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

> On 28 Sep 2022, at 19:40, Neal Gompa wrote: > > On Wed, Sep 28, 2022 at 7:48 PM Simon Farnsworth via devel > mailto:devel@lists.fedoraproject.org>> wrote: >> >>> On 28 Sep 2022, at 14:27, Neal Gompa wrote: >>> >>> On Wed, Sep 28, 2022 at 3

Re: Mesa in F37- vaapi support disabled for h264/h265/vc1

> On 28 Sep 2022, at 14:27, Neal Gompa wrote: > > On Wed, Sep 28, 2022 at 3:22 PM Ian Pilcher wrote: >> >> On 9/28/22 03:50, Tommy Nguyen wrote: >>> This change will only affect AMD, as the intel non-free drivers do not >>> depend on the changes. It is also unclear how this would affect

Re: Suggestion: Use a unified kernel image by default in the future.

On Thursday, 7 July 2022 19:37:16 BST Sharpened Blade via devel wrote: > If it is really compromised, then you have to assume anything the vm sends > you is fake. As far as the owner of guest knows, there could not even a a > real vm, only a ssh shell that looks like it. > In a real situation,

Re: Suggestion: Use a unified kernel image by default in the future.

On Tuesday, 5 July 2022 17:26:40 BST Sharpened Blade via devel wrote: > How can you know if this interface is not emulated, and you never talk to > the real cpu The TDX white papers address how this is meant to work - it's based around the same "measurement" concept as TPM measured boot (see

Re: Fedora 37: Add kernel parameters that help prevent local exploits

On Saturday, 21 May 2022 19:31:59 BST Glorious Hellosway via devel wrote: > For `slab_nomerge`, it can lead to very slight increase of kernel memory. > `init_on_alloc=1` has a almost no performance impact, it is under 1% and is > usually within standard error, but there is bug with zfs that can

Re: Fedora 37: Add kernel parameters that help prevent local exploits

On Thursday, 19 May 2022 04:15:16 BST Hellosway Here via devel wrote: > Add `slab_nomerge init_on_alloc=1 init_on_free=1 page_alloc.shuffle=1 pti=on > randomize_kstack_offset=on vsyscall=none ` as default kernel command line > arguments. This can help prevent local exploits by making it harder to

Re: F37 proposal: Build all JDKs in Fedora against in-tree libraries and with static stdc++lib (System-Wide Change proposal)

On Wednesday, 18 May 2022 15:41:17 BST Vitaly Zaitsev via devel wrote: > On 18/05/2022 13:47, Dominik 'Rathann' Mierzejewski wrote: > > > Then call it "incorrect". Saying it's a lie implies intent to mislead, > > while there obviously was none. > > > Saying "lie" means "not true". > In

Re: F36 Change: DIGLIM (System-Wide Change proposal)

On Sunday, 26 December 2021 11:25:21 GMT Roberto Sassu via devel wrote: > > From: Dan Čermák [mailto:dan.cer...@cgc-instruments.com] > > Sent: Sunday, December 26, 2021 7:10 AM > > Ben Cotton writes: > > > > *snip* > > > == Upgrade/compatibility impact == > > > The user should ensure that