[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1120709: marked as done (RFS: super/3.30.3-2.2 [NMU] [RC] -- Execute commands setuid root)

Your message dated Sun, 16 Nov 2025 15:25:00 +0100
with message-id <aRnevJEzsIVqmadG@isildor2.loewenhoehle.ip>
and subject line Re: Bug#1120709: RFS: super/3.30.3-2.2 [NMU] [RC] -- Execute commands setuid root
has caused the Debian Bug report #1120709,
regarding RFS: super/3.30.3-2.2 [NMU] [RC] -- Execute commands setuid root
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
1120709: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120709
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "super":

 * Package name     : super
   Version          : 3.30.3-2.2
   Upstream contact : will@ucolick.org
 * URL              : http://ftp.ucolick.org/pub/users/will/
 * License          : GPL-1+ or Artistic, BSD-4-clause
 * Vcs              : https://salsa.debian.org/debian/super/
   Section          : admin

The source builds the following binary packages:

  super - Execute commands setuid root

To access further information about this package, please visit the following URL:

  https://mentors.debian.net/package/super/

Alternatively, you can download the package with 'dget' using this command:

  dget -x https://mentors.debian.net/debian/pool/main/s/super/super_3.30.3-2.2.dsc

Changes since the last upload:

 super (3.30.3-2.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * d/control:
     + wrap-and-sort -ast
     + remove ancient dependency versioning
     + add Build-Depends: libcrypt-dev (Closes: #1106914)
   * d/lintian-overrides: fix broken/redundant overrides

The corresponding commit for this proposed upload is available at
https://salsa.debian.org/debian/super/-/merge_requests/2 for
fast-forwarding.

Thanks,
-- 
  Andrew Bower

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message --- 
Hi Andrew,

thanks for the update, I've uploaded the package to DELAYED/2.
I've sent the NMU-diff to #1106914.

Thanks for your contribution to Debian!

On Sun, Nov 16, 2025 at 09:49:33AM +0000, Andrew Bower wrote:
> Control: tags -1 - moreinfo
> 
> Hi Andreas and Tobi,
> 
> Thanks for the reviews! I have made the requested changes.
> 
> On Sat, Nov 15, 2025 at 01:13:25PM +0100, Andreas Metzler wrote:
> > Doing a sponsored NMU for a bug like 1106914 which requires a
> > single-word-addition is terribly inefficient, the sponsee's contribution
> > just does not save any work,
> 
> Yes, it is inefficient for both parties.
> 

Well. NMUs are targeted fixes and often very short, and this is by
design. Sometimes they just a single line, like in his case and this is
competly OK, especially for a sponsored NMUsd. Sorry, if that come
accross wrongly, the uploaded changes, targeting only #1106914, was
great to be sponsored, the diff archive <-> your changes is concise,
easy to grasp and therefore reviewed in seconds.

The inefficency just kicks in if unrelated changes are mixed in,
especially if those changes - like the wrap-and-sort - does just
uncesseraly inflates the observed differences and this makes it harder
to review the changes.

Those changes would be OK, even expected, if this would have been a
maintainer upload, but for a NMU they are, well, unsuitable.

NMU - as said - are designed to be targeted and short and the scope of an
NMU is orthogonal whether this is an RFS or an upload by an project
member.

Now to some little neat trick:
Your lintian / versioned dependencies changes *could* be acceptable for
a NMU. The dev-ref says that you need fix bug. It does not say you
cannot file bugs before the NMU. So, if there is no bug, file one and
reference the bug in d/changelog.  The bug can have additional
information why the changes will fixes the issue. This way the
maintainer, sponsor or other interested party have a reference where to
look for further information and to engage in a discussion -- even
before the NMU has started. So, if there would be a (severity minor) bug
"obsolete lintian overrides" I'd have thought "OK, this is within the
NMU scope. This is probably not going to DELAYED/2 then, but
DELAYED/15." but would have uploaded 

-- 
tobi

> I am more than happy for someone to ignore/close my RFS and simply
> upload the fix themselves unattributed. I will be satisfied knowing that
> I prompted the action and my own sanity checks contributed to risk
> reduction.
>
> On Sat, Nov 15, 2025 at 04:13:01PM +0100, Tobias Frost wrote:
> [...]
> > as Andreas already wrote, these changes are inappropiate for a NMU,
> > please consult the developers-reference on this topic for details.
> > 
> > Specifically everything that does not close filed bugs or is just
> > cosmetics is not appropiate.
> 
> I am not entirely convinced this characterisation fits the changes I
> have now dropped:
> 
> > >    * d/lintian-overrides: fix broken/redundant overrides
> 
> The broken lintian overrides are a pure function of the passage of time.
> No one is going to contest the mechanical fixes. I had to check the
> lintian errors in case there was a regression or something important,
> doubled in number due to the incorrect overrides being reported. Fixing
> these now reduces the tax on future contributors and reviewers so they
> don't need to redo my work reviewing them all over again, each time. It
> is a good value fix and in scope for an NMU by my reading of the
> developers' reference. I have moved them to a separate merge request for
> the maintainer to look at when he has a chance.
> 
> (That said, I did miss something in the initial version of this fix, so
> something good came out of the rework!)
> 
> > >      + remove ancient dependency versioning
> 
> This is also a function of the passage of time. Specifically 2001 and
> 2003. Ancient package relationships are flagged in maintscripts and by
> package reviewers I have observed. This improves SnR, therefore
> improving the possibility of spotting other issues.
> 
> > >      + wrap-and-sort -ast
> 
> FWIW I wasn't sure about this, mostly because the changelog makes it
> sound more intrusive and frivolous than it is. The best time to convert
> inline lists into multi-line form with trailing commas to support
> composability and reviewability of git commits is previously. The second
> best time is in a commit preceding new changes to the lists to mitigate
> the increased technical debt.
> 
> > Please revert this changes and then reupload a new package to
> > mentors. 
> > Remove the moreinfo tag when ready.
> 
> All done, thanks!

--- End Message ---
Reply to: