On Wed, Jun 19, 2024 at 11:02:57AM GMT, Andrea Bolognani wrote:
> 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
ng
for this rebase, since 2.06 can't do UEFI boot on the architecture.
It's one of the last missing pieces before we can start producing
disk images that mostly work out of the box. Right now a few
additional steps[1] are necessary.
Thanks!
[1] https://fedoraproject.org/wiki/Architectures/RISC-V/I
On Wed, Jun 12, 2024 at 04:58:57PM GMT, David Abdurachmanov wrote:
> On Mon, Jun 10, 2024 at 5:53 PM Andrea Bolognani wrote:
> > On Wed, May 29, 2024 at 02:56:01PM GMT, Kevin Fenzi wrote:
> > > yeah, I've seen this pattern before, but it's not a great way
o file the bug? We wouldn't want this
to slip through the cracks.
Thanks!
--
Andrea Bolognani / Red Hat / Virtualization
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedo
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
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'
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'
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.
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
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
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
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
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 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
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
/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
17 matches
Mail list logo