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 GR
against libtiff to highlight the problematic situation David is
referring to:
https://bugzilla.redhat.com/show_bug.cgi?id=2292047
If the packages that still need libtiff.so.5 were to be retired,
addressing it would become trivial.
--
Andrea Bolognani / Red Hat / Virtualization
--
_
/2023-July/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/pr
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
> &
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 of these
needing a restart, but the task of marking them
as such still falls on the package.
For presets, we don't have a --marked option that would allow
applying everything in one go. I actually don't think that we would
want that to happen anyway: in the case of lib
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
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
ing 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 h
f.d/riscv64-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 n
hitecture? IIUC, binaries built with -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 fo
Right, changing the vector calling convention may change 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.
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'
ully pushed in a single 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 some
ils, especially those on public
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.f
had a chance to 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.fe
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
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/Architecture
keys. I don't know the complete list of people
> with this privilege, but I know nfrayer has it (CCed).
Ping.
Can we please look into getting pesign rebuilt? Ideally in f41, but
at the very least in f42.
Thanks!
--
Andrea Bolognani / Red Hat / Virtualization
--
_
On Thu, Nov 14, 2024 at 01:51:07PM -0800, Kevin Fenzi wrote:
> On Thu, Nov 14, 2024 at 03:37:49PM +0000, Andrea Bolognani wrote:
> > On Tue, Nov 12, 2024 at 02:20:32PM -0800, Kevin Fenzi wrote:
> > > I bumped the release and did a rawhide build:
> > >
> > >
On Tue, Nov 12, 2024 at 02:20:32PM -0800, Kevin Fenzi wrote:
> On Mon, Nov 11, 2024 at 04:23:16AM -0600, Andrea Bolognani wrote:
> > Can we please look into getting pesign rebuilt? Ideally in f41, but
> > at the very least in f42.
>
> I bumped the release and did a r
n under Setting simply doesn't react to being clicked.
How do I get the fork unstuck?
Thanks in advance :)
[1] https://src.fedoraproject.org/fork/abologna/rpms/anaconda
[2] https://src.fedoraproject.org/fork/kevin/rpms/anaconda
--
Andrea Bolognani / Red
It worked! Thanks a lot :)
--
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.o
end on packages that
ship the macros your spec file uses, but maybe this case is
different? Maybe we just need to rebuild some packages in some
specific order on riscv64 to sort things out?
Thank you in advance for any help you might be able to provide :)
--
Andrea Bolognani / Red Hat / Virtua
24 matches
Mail list logo
