Bug#1134471: RFS: ruby-chef-utils/19.2.12-0.1 [RC] -- Basic utility functions for Core Chef Infra development

On Fri, May 29, 2026 at 03:11:48PM +0000, Norwid Behrnd wrote:
> Hello Tobi
> 
> Thank you for joining the thread.
> 
> > NMUs should be minimal [1], every fix needs to target (a reported)
> > bug.
> 
> If you recommend to split the current results, to address one issue
> per one NMU at a time, a sequence plausible to me could be

That's not what I've said ;-)
NMUs can fix multiple issues, but there are requirments to the issues
to be fixed. Please read up on NMUs in the developers reference.i [1]

One key is that any issue to be fixed needs a *filed* bug. No filed bug,
no fix in an NMU.

NMUs should be minimal, they don't aim to produce a perfect package but
to fix actual (severe) problems in a pacakge.

[1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-maintainer-uploads-nmus

> 1) let debian/salsa-ci.yml work to completion.  For a reason unknown
> to me, Lucas Nussbaum initiated such a run (September 6, 2025) which
> however was cancelled.  This was about 4 months after the last upload
> from the blessed repository on salsa to debian.
> 
> 2) set d/watch back into action (bug 1127665), perhaps 2b) an update
> to current syntax Version 5.

It has a bug, so it can be fixed. However, it is not a very important
bug, and when in doubt shouldn' be fixed. As the dev-ref says:
 "How confident are you about your changes? Please remember the
 Hippocratic Oath: "Above all, do no harm." It is better to leave a
 package with an open grave bug than applying a non-functional patch, or
 one that hides the bug instead of resolving it. If you are not 100% sure
 of what you did, it might be a good idea to seek advice from others.
 Remember that if you break something in your NMU, many people will be
 very unhappy about it."

> 3) address that ruby-chef-utils doesn't faithfully build from source
> (bug 1123467).

This is a prime candidate for an NMU, fixing an RC bug.

> 
> 4) an upstream update which equally accounts for current policies
> (d/watch version=4 -> Version: 5, etc).

(This is usually out of scope for an NMU.)

> Surely I could revise the upload, or set up an additional clone of
> `ruby-chef-utils` in my salsa profile; upload to the mentors page
> would await passing manual acceptance though intermediate steps would
> be marked as not passing the current policy.  I do not know if this
> wanted; let me know if there is a better way (first time if ever NMU).

I recommend to limit yourself to release-critical bugs for NMUs,
especially if you're not having the experience yet to judge what is
acceptable in Debian and what maybe not.

> > Have you checked whether the new upstream version breaks reverse
> > depdendencies?
> 
> No I did not specifically look into this.  Since the upload by
> 2026-04-20 passed both the checks of lintian in a local instance (then
> Debian 13/testing) as well within reason the ones on the mentors page,
> I presumed there would be no grave break.  I discounted yellow
> indicators (like d/watch) to "tests on the mentors.net are not yet
> updated to the current policy".  Test results collected then may be
> different to ones of today, and an incomplete analysis.
> 
> > 
> > NMUs needs to be announced to the package maintainer, you'll find
> > nmudiff(1) handy for this task. (just tweak the text of nmudiff to
> > point to this RFS.)
> 
> I recognize this as an error on my side, I did not file an additional
> NMU bug.   Because <https://tracker.debian.org/pkg/ruby-chef-utils>
> mentions Priate Praveen as the package's main uploader, I however
> reached out for him on salsa -- prior to starting the work.  About a
> month later, I informed him about my RFS for the NMU.  Because the
> blessed repository is within the name space of the Debian Ruby Team, I
> presumed either Pirate Praveen, or another member of the Ruby Team
> would have a look on this when time is suitable for him / another team
> member, at
> <https://salsa.debian.org/ruby-team/ruby-chef-utils/-/merge_requests/2>
> So far, no reply from this side however I'll check into nmudiff you
> recommend.
> 
> Since "you can invite, but not force the volunteers" (Andreas Tille,
> at a packaging workshop at CLT 2026) and given the history of bug
> 1123467 I left my results for feedback by others and possible
> continuation (by me, or by others) on the mentors page.
> 
> Best regards, Norwid
>