est/1301
>
> Reviews welcome ;)
FWIW, changes look reasonable to me.
I still intend to extract the libvirt macros, make them more generic,
polish them and submit the result to systemd upstream. I just haven't
been able to carve time to do that yet, but it's reasonably high on
my TODO
/240729.html
--
Andrea Bolognani / Red Hat / Virtualization
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code
ow
applying everything in one go. I actually don't think that we would
want that to happen anyway: in the case of libvirt, for example, we
need presets for virtqemud.socket to be applied before presets for
virtqemud.service, because virtqemud.socket is disabled as per the
On Thu, Jul 20, 2023 at 02:01:37PM -0700, Kevin Fenzi wrote:
> On Thu, Jul 20, 2023 at 07:40:08AM -0700, Andrea Bolognani wrote:
> > The problem is that Fedora 39 and RHEL 9.3 are fast approaching and,
> > if we don't do anything about this issue before then, a subset of
> > l
On Wed, Jul 26, 2023 at 07:15:42AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jul 25, 2023 at 10:45:30AM -0400, Andrea Bolognani wrote:
> > On Tue, Jul 25, 2023 at 10:51:04AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > I think it'd be more effiecient to go with
On Fri, Jul 21, 2023 at 08:20:21AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Jul 20, 2023 at 07:40:08AM -0700, Andrea Bolognani wrote:
> > Now, since this is clearly not a libvirt-specific issue, I believe
> > this approach should be adopted across Fedora by way
th changing their
structs in ABI-incompatible ways on account of the fact that users
are not supposed to be accessing them directly anyway, perhaps they
could fully commit to this idea by moving struct definitions to the
.c files and leaving just the typedefs in the .h files? That's how
ot
4-linux-gnu.conf
/usr/local/lib/riscv64-linux-gnu
/lib/riscv64-linux-gnu
/usr/lib/riscv64-linux-gnu
This matches what Debian does on all architectures, that is, install
libraries under fully arch-qualified paths. If Debian doesn't stray
from its usual practices for RISC-V, I'm not convinced that Fe
h -mabi=lp64d wouldn't be able
to load libraries built with -mabi=lp64dv and vice versa.
If that's correct, then we can't simply have a single "riscv64"
architecture: instead, we need to call what we have today
riscv64_lp64d, and be ready for riscv64_lp64dv as well as whatever
comes next.
e the size of
> > jmp_buf, and then you have a new ABI even if use of the vector features
> > is optional.
>
> Arguably bumping the baseline should *also* be a new architecture
> because it's a total compatibility break.
No, you're just cutting off support for hardware that doesn'
On Wed, Apr 24, 2024 at 09:01:51AM -0400, Neal Gompa wrote:
> On Wed, Apr 24, 2024 at 8:35 AM Andrea Bolognani wrote:
> > On Wed, Apr 24, 2024 at 07:43:08AM -0400, Neal Gompa wrote:
> > > On Wed, Apr 24, 2024 at 7:16 AM Florian Weimer wrote:
> > > > > Wouldn'
c
lists, before the second coffee of the day has kicked in :)
--
Andrea Bolognani / Red Hat / Virtualization
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code o
gle side tag to fix this.
Shouldn't the symlink point in the opposite direction anyway?
/usr/lib64/lp64d is the actual canonical path, /usr/lib64 is just for
compatibility.
Though apparently (see elsewhere in the thread) Gentoo does it this
way too, so maybe there's something I'm missing that makes t
13 matches
Mail list logo
