On Sun, Jan 16, 2022 at 5:05 PM Chris Adams wrote:
>
> Once upon a time, Ben Cotton said:
> > == Benefit to Fedora ==
> >
> > * The RPM database primarily describes the state of `/usr`. Storing
> > the databases in `/usr` will more easily facilitate OS rollback,
> > without affecting `/var`.
>
>
On Sun, Jan 16, 2022 at 9:36 PM Chris Adams wrote:
>
> Once upon a time, Chris Murphy said:
> > If you value Fedora having a snapshot and rollback scheme of some
> > kind, it's useful and beneficial. If you don't, then the change is
> > neutral because it has not a single technical downside pres
Once upon a time, Chris Murphy said:
> If you value Fedora having a snapshot and rollback scheme of some
> kind, it's useful and beneficial. If you don't, then the change is
> neutral because it has not a single technical downside presented so
> far - just emotive ones.
It's only beneficial for
On Sun, Jan 16, 2022 at 4:34 PM Peter Boy wrote:
>
>
>
> > Am 17.01.2022 um 00:09 schrieb Neal Gompa :
> >
> > On Fri, Jan 14, 2022 at 5:51 PM Fabio Valentini
> > wrote:
> >>
> >> ….
> >
> > openSUSE originally did the move because standard openSUSE has a
> > snapshot+rollback scheme and trackin
On Sun, Jan 16, 2022 at 3:59 PM Peter Boy wrote:
>
>
>
> > Am 14.01.2022 um 23:51 schrieb Fabio Valentini :
> >
> >
> > Wait, I thought this change was about making the path consistent
> > within Fedora variants?
>
> The question still is whether this is actually useful and beneficial.
If you val
welcome Jun, It's very nice to have talk with you!
___
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-of-co
Once upon a time, Neal Gompa said:
> On Sun, Jan 16, 2022 at 6:47 PM Chris Adams wrote:
> > Once upon a time, Neal Gompa said:
> > > It benefits LVM-based OS snapshotting equally well. However, the
> > > tooling for LVM snapshots are under-developed, so it's not used so
> > > much for this.
> >
Once upon a time, Ben Cotton said:
> == Benefit to Fedora ==
>
> * The RPM database primarily describes the state of `/usr`. Storing
> the databases in `/usr` will more easily facilitate OS rollback,
> without affecting `/var`.
Rolling back to the start... this statement is only marginally true.
On Sun, Jan 16, 2022 at 6:47 PM Chris Adams wrote:
>
> Once upon a time, Neal Gompa said:
> > It benefits LVM-based OS snapshotting equally well. However, the
> > tooling for LVM snapshots are under-developed, so it's not used so
> > much for this.
>
> How? Since the standard install uses a sing
Once upon a time, Neal Gompa said:
> It benefits LVM-based OS snapshotting equally well. However, the
> tooling for LVM snapshots are under-developed, so it's not used so
> much for this.
How? Since the standard install uses a single root filesystem that
includes /usr and /var, I can't see any b
On Mon, Jan 17, 2022 at 10:35 AM Iñaki Ucar wrote:
> On Mon, 17 Jan 2022 at 00:21, Nathan Scott wrote:
> > On Mon, Jan 17, 2022 at 7:05 AM Kevin Fenzi wrote:
> > >
> > > Greetings.
> > >
> > > We currently have hiredis-0.13.3-16 in rawhide, I'd like to upgrade to
> > > 1.0.2, which includes a so
On Mon, 17 Jan 2022 at 00:21, Nathan Scott wrote:
>
> Hi Kevin,
>
> On Mon, Jan 17, 2022 at 7:05 AM Kevin Fenzi wrote:
> >
> > Greetings.
> >
> > We currently have hiredis-0.13.3-16 in rawhide, I'd like to upgrade to
> > 1.0.2, which includes a soname bump.
>
> I think upstream may have reverted
> Am 17.01.2022 um 00:09 schrieb Neal Gompa :
>
> On Fri, Jan 14, 2022 at 5:51 PM Fabio Valentini wrote:
>>
>> ….
>
> openSUSE originally did the move because standard openSUSE has a
> snapshot+rollback scheme and tracking the rpmdb is straightforward in
> /usr with all the other system state
Hi Kevin,
On Mon, Jan 17, 2022 at 7:05 AM Kevin Fenzi wrote:
>
> Greetings.
>
> We currently have hiredis-0.13.3-16 in rawhide, I'd like to upgrade to
> 1.0.2, which includes a soname bump.
I think upstream may have reverted this change FWIW ...
https://github.com/redis/hiredis/issues/990
cheer
On Sun, Jan 16, 2022 at 5:59 PM Peter Boy wrote:
>
>
>
> > Am 14.01.2022 um 23:51 schrieb Fabio Valentini :
> >
> >
> > Wait, I thought this change was about making the path consistent
> > within Fedora variants?
>
> The question still is whether this is actually useful and beneficial.
>
> All the
On Fri, Jan 14, 2022 at 5:51 PM Fabio Valentini wrote:
>
> On Fri, Jan 14, 2022 at 7:16 PM Colin Walters wrote:
> >
> >
> >
> > On Thu, Jan 13, 2022, at 6:05 PM, Fabio Valentini wrote:
> >
> > > The path "/usr/lib/sysimage/rpm" does look very out-of-place in
> > > non-image-based systems, so *if*
> Am 14.01.2022 um 23:51 schrieb Fabio Valentini :
>
>
> Wait, I thought this change was about making the path consistent
> within Fedora variants?
The question still is whether this is actually useful and beneficial.
All the arguments for this move that I have read so far explain benefits
r
Thank you for your hard work :)!
Thanks to the wlroots0.14 compat package, nothing broke :D!
cage's master branch is already on 0.15, so, hopefully, there will be a
release using it soon :)!
Le 16/01/2022 à 23:20, Aleksei Bavshin a écrit :
On 1/11/22 21:29, Aleksei Bavshin wrote:
Greetings,
On Fri, Jan 14, 2022 at 3:51 PM Fabio Valentini wrote:
>
> On Fri, Jan 14, 2022 at 7:16 PM Colin Walters wrote:
> >
> >
> >
> > On Thu, Jan 13, 2022, at 6:05 PM, Fabio Valentini wrote:
> >
> > > The path "/usr/lib/sysimage/rpm" does look very out-of-place in
> > > non-image-based systems, so *if*
Dear Garry,
Welcome to Fedora! The Bridge Hand Generator looks really
interesting. I've been meaning to learn Bridge; now I'll be able to
have computer-assistance for at least the dealing aspect!
Best wishes,
Sebastian
___
devel mailing list -- devel@l
On 1/11/22 21:29, Aleksei Bavshin wrote:
Greetings,
By the end of this week I'm planning to update wlroots in rawhide to
0.15 (libwlroots.so.10) and sway to the latest release candidate.
No breakages are expected as wlroots0.14 compatibility package will be
introduced in the same side-tag.
Just thought I would share that (finally) we have completed upgrades on
the koji hubs and builders.
The hubs have been upgraded to Fedora 35 and
the latest koji version (1.17.1).
Builder hypervisors have been upgraded to RHEL8.5 and the latest
advanced virt stack. Builders have been upgraded/reim
Greetings.
We currently have hiredis-0.13.3-16 in rawhide, I'd like to upgrade to
1.0.2, which includes a soname bump.
I plan to make a side tag and build dependent packages the next few
days.
I've rebuilt everything in a copr:
https://copr.fedorainfracloud.org/coprs/kevin/hiredis/builds/
The
On Fri, Jan 14, 2022 at 04:07:08PM +0100, Dan Horák wrote:
> > Another important thing I wanted to say is that we'd like to switch
> > ppc64le from the numerically problematic IBM extended long double to
> > IEEE 754 quad long double. This is an ABI change. Some libraries
> > are already built so
Ceph fails with gcc-12 too.
scratch build at
https://koji.fedoraproject.org/koji/taskinfo?taskID=81280838
upstream ceph bug at https://tracker.ceph.com/issues/53896
--
Kaleb
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
I tried recompiling qemu and it fails with an odd error in the RCU
torture test. Bug submitted upstream here:
https://gitlab.com/qemu-project/qemu/-/issues/823
... but since GCC 12 is the only big thing that has changed since we
just rebuilt qemu, could that be a reason?
https://gitlab.com/qem
Hi all,
I’ve had a review of the retry tool at
https://bugzilla.redhat.com/show_bug.cgi?id=2017119, but I need help with a
sponsor.
Happy to try review some other packages in return, but will need a bit of hand
holding.
Regards,
Graham
—
___
devel m
On Thu, Jan 13, 2022, at 1:48 PM, Kevin Fenzi wrote:
>
>
> Perhaps the Fedora CoreOS folks would have some thoughts?
I can't speak for the whole team, but a few points. First, the FCOS build
tooling in https://github.com/coreos/coreos-assembler is designed to run as a
standard container. In
Hi,
Jiri Konecny writes:
> Dne 07. 01. 22 v 21:54 Major Hayden napsal(a):
>> On 1/7/22 14:46, Jiri Konecny wrote:
>>> I would like to do here a bit of brainstorming and ask if there is an
>>> existing solution to this problem. To explain my problem,
>>> recently I found more and more apps likes
On Sun, Jan 16, 2022 at 8:43 AM Josh Boyer wrote:
>
>
>
> On Sat, Jan 15, 2022, 6:57 PM Kevin Fenzi wrote:
>>
>> On Thu, Jan 13, 2022 at 02:14:19PM -0500, Neal Gompa wrote:
>> >
>> > One of the things that has recently happened in the Koji space is the
>> > addition of a kiwi-build task to build
Hi Mattia,
Mattia Verga via devel writes:
> In this [1] rpmautospec bug it is claimed that a clean EVR upgrade
> between Fedora releases is no more required.
Afaik this should be correct, as dnf system-upgrade uses distro-sync
nowadays and will perform the upgrade correctly even if that implies
On Sat, Jan 15, 2022, 6:57 PM Kevin Fenzi wrote:
> On Thu, Jan 13, 2022 at 02:14:19PM -0500, Neal Gompa wrote:
> >
> > One of the things that has recently happened in the Koji space is the
> > addition of a kiwi-build task to build images using the KIWI tool[1].
> >
> > KIWI supports building all
In this [1] rpmautospec bug it is claimed that a clean EVR upgrade
between Fedora releases is no more required.
However Packaging Guidelines [2] [3] implies that is actually still
required.
What's the current status? Can a package have a higher NVR in a stable
release than in Rawhide?
Mattia
[1
On 15/01/2022 19:40, Ben Beasley wrote:
To clarify, this is affecting the
https://src.fedoraproject.org/rpms/json package and (since it is a
header-only library) some or all of the many packages that use it.
nheko package:
/builddir/build/BUILD/nheko-0.9.1/src/Cache.cpp:4530:34: error:
ambig
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-34-20220115.0):
ID: 1105564 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
On Sat, Jan 15, 2022 at 01:50:19PM -0700, Martin Sebor wrote:
> Having said that, checking and handling possible truncation before
> calling snprintf() is doing double the work. I would suggest to get
> rid of the check and instead handle the truncation after it happens.
> This is both simpler and
No missing expected images.
Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)
Old soft failures (same test soft failed in Fedora-Cloud-35-20220115.0):
ID: 1105548 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://op
37 matches
Mail list logo
