mbox series

[bug#76960,sysadmin-team,0/8] Update spdlog.

Message ID cover.1741724364.git.code@greghogan.com
Headers
Series Update spdlog. |

Message

Greg Hogan March 11, 2025, 8:34 p.m. UTC 
  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.

 gnu/packages/logging.scm   | 17 +++++++++++++++--
 gnu/packages/messaging.scm |  4 ++--
 gnu/packages/qt.scm        |  2 +-
 gnu/packages/radio.scm     |  2 +-
 gnu/packages/upnp.scm      |  2 +-
 gnu/packages/wm.scm        |  2 +-
 6 files changed, 21 insertions(+), 8 deletions(-)


base-commit: 3bf7a0e8c431abfcba51806ee2a3eea9e0865472

Comments

Maxim Cournoyer March 12, 2025, 12:51 p.m. UTC | #1 
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!
Greg Hogan March 16, 2025, 4:44 p.m. UTC | #2 
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
Greg Hogan March 16, 2025, 5:16 p.m. UTC | #3 
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.
Sharlatan Hellseher March 16, 2025, 8:42 p.m. UTC | #4 
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
Greg Hogan March 18, 2025, 5 p.m. UTC | #5 
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
Maxim Cournoyer March 20, 2025, 3 a.m. UTC | #6 
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.