Report forwarded
to guix-patches@gnu.org: bug#76960; Package guix-patches.
(Tue, 11 Mar 2025 20:36:02 GMT) (full text, mbox, link).
Acknowledgement sent
to Greg Hogan <code@greghogan.com>:
New bug report received and forwarded. Copy sent to guix-patches@gnu.org.
(Tue, 11 Mar 2025 20:36:02 GMT) (full text, mbox, link).
Hi Greg,
Greg Hogan <code@greghogan.com> writes:
> All dependent packages build except rxcpp, which is broken on master.
>
> Greg Hogan (8):
> gnu: spdlog: Update to 1.15.1.
> gnu: Add spdlog-1.13.
> gnu: gerbera: Pin spdlog.
> gnu: gr-satellites: Pin spdlog.
> gnu: kddockwidgets: Pin spdlog.
> gnu: mtxclient: Pin spdlog.
> gnu: nheko: Pin spdlog.
> gnu: waybar: Pin spdlog.
We usually keep one change per patch, but in cases where we know that
there is breakage and how to fix it, it's nicer to combine the changes
in one atomic commit to ensure all the packages remain working on any
give commit (could be useful while travelling with 'guix time-machine'
for example).
Could you squash the series and submit as v2? Thanks!
--
Thanks,
Maxim
Information forwarded
to guix-patches@gnu.org: bug#76960; Package guix-patches.
(Sun, 16 Mar 2025 16:45:02 GMT) (full text, mbox, link).
On Wed, Mar 12, 2025 at 8:52 AM Maxim Cournoyer
<maxim.cournoyer@gmail.com> wrote:
>
> Hi Greg,
>
> Greg Hogan <code@greghogan.com> writes:
>
> > All dependent packages build except rxcpp, which is broken on master.
> >
> > Greg Hogan (8):
> > gnu: spdlog: Update to 1.15.1.
> > gnu: Add spdlog-1.13.
> > gnu: gerbera: Pin spdlog.
> > gnu: gr-satellites: Pin spdlog.
> > gnu: kddockwidgets: Pin spdlog.
> > gnu: mtxclient: Pin spdlog.
> > gnu: nheko: Pin spdlog.
> > gnu: waybar: Pin spdlog.
>
> We usually keep one change per patch, but in cases where we know that
> there is breakage and how to fix it, it's nicer to combine the changes
> in one atomic commit to ensure all the packages remain working on any
> give commit (could be useful while travelling with 'guix time-machine'
> for example).
>
> Could you squash the series and submit as v2? Thanks!
>
> --
> Thanks,
> Maxim
Maxim,
Thank you for the recommendation. I can certainly see this as two
multi-package patches:
1) updating a package while leaving the old version pinned (spdlog)
2) the same trivial update to multiple packages (the six dependent packages)
And this would simplify the commit logs and reduce the mailing list
traffic. But it doesn't seem practical to squash all updates into the
original breaking commit. When updating glibc or gcc the core-packages
team fixes hundreds of packages, and the kde and gnome updates
similarly make changes across dozens of packages. More useful than
random hopping with time-machine would be scheduled releases (or
marking the span or end of each patchset with the patch ID).
Greg
Information forwarded
to sharlatanus@gmail.com, guix-patches@gnu.org: bug#76960; Package guix-patches.
(Sun, 16 Mar 2025 17:15:01 GMT) (full text, mbox, link).
On Sun, Mar 16, 2025 at 12:44 PM Greg Hogan <code@greghogan.com> wrote:
>
> On Wed, Mar 12, 2025 at 8:52 AM Maxim Cournoyer
> <maxim.cournoyer@gmail.com> wrote:
> >
> > Hi Greg,
> >
> > Greg Hogan <code@greghogan.com> writes:
> >
> > > All dependent packages build except rxcpp, which is broken on master.
> > >
> > > Greg Hogan (8):
> > > gnu: spdlog: Update to 1.15.1.
> > > gnu: Add spdlog-1.13.
> > > gnu: gerbera: Pin spdlog.
> > > gnu: gr-satellites: Pin spdlog.
> > > gnu: kddockwidgets: Pin spdlog.
> > > gnu: mtxclient: Pin spdlog.
> > > gnu: nheko: Pin spdlog.
> > > gnu: waybar: Pin spdlog.
> >
> > We usually keep one change per patch, but in cases where we know that
> > there is breakage and how to fix it, it's nicer to combine the changes
> > in one atomic commit to ensure all the packages remain working on any
> > give commit (could be useful while travelling with 'guix time-machine'
> > for example).
> >
> > Could you squash the series and submit as v2? Thanks!
> >
> > --
> > Thanks,
> > Maxim
>
> Maxim,
>
> Thank you for the recommendation. I can certainly see this as two
> multi-package patches:
> 1) updating a package while leaving the old version pinned (spdlog)
> 2) the same trivial update to multiple packages (the six dependent packages)
>
> And this would simplify the commit logs and reduce the mailing list
> traffic. But it doesn't seem practical to squash all updates into the
> original breaking commit. When updating glibc or gcc the core-packages
> team fixes hundreds of packages, and the kde and gnome updates
> similarly make changes across dozens of packages. More useful than
> random hopping with time-machine would be scheduled releases (or
> marking the span or end of each patchset with the patch ID).
>
> Greg
And immediately after sending a v2 I realized that I forgot to add the
v2 tag to the subject-prefix.
Information forwarded
to guix-patches@gnu.org: bug#76960; Package guix-patches.
(Sun, 16 Mar 2025 20:43:04 GMT) (full text, mbox, link).
Hi Greg,
Just a question of interest (not a review as the patches look quite
trivial), why we need to pin lower version of spdlog? Is there any
option to try to refresh dependent packages if it helps keep away from
lower version?
--
Thanks,
Oleg
On Sun, Mar 16, 2025 at 4:42 PM Sharlatan Hellseher
<sharlatanus@gmail.com> wrote:
>
> Hi Greg,
>
> Just a question of interest (not a review as the patches look quite
> trivial), why we need to pin lower version of spdlog? Is there any
> option to try to refresh dependent packages if it helps keep away from
> lower version?
>
> --
> Thanks,
> Oleg
Hi Oleg,
None of the pinned variants are propagated inputs so we should not
have any issues with this.
As to updating the dependent packages, I think it best to leave that
to other patchsets. Every change can lead to additional changes, down
the rabbit hole.
Greg
Information forwarded
to guix-patches@gnu.org: bug#76960; Package guix-patches.
(Thu, 20 Mar 2025 03:02:02 GMT) (full text, mbox, link).
Hi,
Greg Hogan <code@greghogan.com> writes:
> On Sun, Mar 16, 2025 at 4:42 PM Sharlatan Hellseher
> <sharlatanus@gmail.com> wrote:
>>
>> Hi Greg,
>>
>> Just a question of interest (not a review as the patches look quite
>> trivial), why we need to pin lower version of spdlog? Is there any
>> option to try to refresh dependent packages if it helps keep away from
>> lower version?
>>
>> --
>> Thanks,
>> Oleg
>
> Hi Oleg,
>
> None of the pinned variants are propagated inputs so we should not
> have any issues with this.
>
> As to updating the dependent packages, I think it best to leave that
> to other patchsets. Every change can lead to additional changes, down
> the rabbit hole.
I agree with both of you; ideally we wouldn't introduce pinned packages
unless really necessary; Greg, perhaps you could try a quick refresh of
the few dependents and see if updating them is a lot of efforts or
trivial. If it's trivial, away goes the pinning, if it isn't (or
perhaps these packages do not have a new release fixing this upstream
yet), than the pin is justified.
--
Thanks,
Maxim
Information forwarded
to maxim.cournoyer@gmail.com, z572@z572.online, iyzsong@envs.net, guix-patches@gnu.org: bug#76960; Package guix-patches.
(Thu, 20 Mar 2025 17:20:02 GMT) (full text, mbox, link).
Of the packages which did not build with the updated spdlog and therefore
needed to be pinned:
* kddockwidgets has now been updated
* mtxclient, nheko, waybar are already at the latest upstream version
* gerbera 2.5.0 fails due to the updated spdlog
* gr-satellites 5.7.0 tests fail due to an issue with Python imports
Greg Hogan (3):
gnu: spdlog: Update to 1.15.1.
gnu: Pin spdlog.
gnu: kddockwidgets: Update to 2.2.1.
gnu/packages/logging.scm | 17 +++++++++++++++--
gnu/packages/messaging.scm | 4 ++--
gnu/packages/qt.scm | 4 ++--
gnu/packages/radio.scm | 2 +-
gnu/packages/upnp.scm | 2 +-
gnu/packages/wm.scm | 2 +-
6 files changed, 22 insertions(+), 9 deletions(-)
base-commit: 18f956467a7e3e35e21a9b5616025bf33f307ad7
--
2.49.0
Information forwarded
to sharlatanus@gmail.com, guix-patches@gnu.org: bug#76960; Package guix-patches.
(Thu, 20 Mar 2025 17:20:02 GMT) (full text, mbox, link).
Hi Greg,
Greg Hogan <code@greghogan.com> writes:
> * gnu/packages/qt.scm (kddockwidgets): Update to 2.2.1.
This series LGTM, but I'd push this update first, and squash the two
other spdlog commits together, so that the impacted packages build fine
on all commits.
Feel free to push after reworking the commits that way.
--
Thanks,
Maxim
Information forwarded
to guix-patches@gnu.org: bug#76960; Package guix-patches.
(Fri, 21 Mar 2025 14:37:03 GMT) (full text, mbox, link).
On Fri, Mar 21, 2025 at 9:18 AM Maxim Cournoyer
<maxim.cournoyer@gmail.com> wrote:
>
> Hi Greg,
>
> Greg Hogan <code@greghogan.com> writes:
>
> > * gnu/packages/qt.scm (kddockwidgets): Update to 2.2.1.
>
> This series LGTM, but I'd push this update first, and squash the two
> other spdlog commits together, so that the impacted packages build fine
> on all commits.
>
> Feel free to push after reworking the commits that way.
>
> --
> Thanks,
> Maxim
I will do this because I defer to your experience and expertise, and
also I do not particularly care about this pair of patches, but no one
will have tested the updated kddockwidgets against the old version of
spdlog (albeit this is much better than the known breakage in the
other order). I just do not see this preference being generally
applied elsewhere. We struggle to keep Guix mostly buildable, much
less after every commit. We should make releases rather than squashed
commits as points of stability.
Reply sent
to Greg Hogan <code@greghogan.com>:
You have taken responsibility.
(Fri, 21 Mar 2025 19:48:02 GMT) (full text, mbox, link).
Notification sent
to Greg Hogan <code@greghogan.com>:
bug acknowledged by developer.
(Fri, 21 Mar 2025 19:48:02 GMT) (full text, mbox, link).
On Thu, Mar 20, 2025 at 1:19 PM Greg Hogan <code@greghogan.com> wrote:
>
> Of the packages which did not build with the updated spdlog and therefore
> needed to be pinned:
> * kddockwidgets has now been updated
> * mtxclient, nheko, waybar are already at the latest upstream version
> * gerbera 2.5.0 fails due to the updated spdlog
> * gr-satellites 5.7.0 tests fail due to an issue with Python imports
>
> Greg Hogan (3):
> gnu: spdlog: Update to 1.15.1.
> gnu: Pin spdlog.
> gnu: kddockwidgets: Update to 2.2.1.
>
> gnu/packages/logging.scm | 17 +++++++++++++++--
> gnu/packages/messaging.scm | 4 ++--
> gnu/packages/qt.scm | 4 ++--
> gnu/packages/radio.scm | 2 +-
> gnu/packages/upnp.scm | 2 +-
> gnu/packages/wm.scm | 2 +-
> 6 files changed, 22 insertions(+), 9 deletions(-)
>
>
> base-commit: 18f956467a7e3e35e21a9b5616025bf33f307ad7
> --
> 2.49.0
Pushed as b7f8c13503e48943e4d7684e19f1817d74be15de^..6fbb2f11d2ac08d816b5f087103698319f806430.
Information forwarded
to guix-patches@gnu.org: bug#76960; Package guix-patches.
(Sat, 22 Mar 2025 10:37:02 GMT) (full text, mbox, link).
Hi Greg,
Greg Hogan <code@greghogan.com> writes:
> On Fri, Mar 21, 2025 at 9:18 AM Maxim Cournoyer
> <maxim.cournoyer@gmail.com> wrote:
>>
>> Hi Greg,
>>
>> Greg Hogan <code@greghogan.com> writes:
>>
>> > * gnu/packages/qt.scm (kddockwidgets): Update to 2.2.1.
>>
>> This series LGTM, but I'd push this update first, and squash the two
>> other spdlog commits together, so that the impacted packages build fine
>> on all commits.
>>
>> Feel free to push after reworking the commits that way.
>>
>> --
>> Thanks,
>> Maxim
>
> I will do this because I defer to your experience and expertise, and
> also I do not particularly care about this pair of patches, but no one
> will have tested the updated kddockwidgets against the old version of
> spdlog (albeit this is much better than the known breakage in the
> other order). I just do not see this preference being generally
> applied elsewhere.
Thanks. I think it became a bit more of a concern post 'guix
time-machine'.
> We struggle to keep Guix mostly buildable, much
> less after every commit. We should make releases rather than squashed
> commits as points of stability.
I somewhat disagree on this; releases will typically invest efforts in
testing the release artifacts such as graphical installer, the
installation script, the sample VM image, etc. but won't/can't be a
guarantee that the complete package collections has been QA'd.
So it's still very valuable and needed to have good self-QA hygiene on
our own individual commits. Package test suites go a long way to
provide some guarantee that it should work; system tests can be another
one, or simply validating a binary runs correctly.
--
Thanks,
Maxim
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.