Processed: Re: Following advice of cute-field tag for X-DhRuby-Root breaks build
Processing control commands: > clone -1 -2 Bug #977322 [lintian] Following advice of cute-field tag for X-DhRuby-Root breaks build Bug 977322 cloned as bug 1064462 > retitle -2 gem2deb: Case sensitive handling of d/control Bug #1064462 [lintian] Following advice of cute-field tag for X-DhRuby-Root breaks build Changed Bug title to 'gem2deb: Case sensitive handling of d/control' from 'Following advice of cute-field tag for X-DhRuby-Root breaks build'. > reassign -2 gem2deb Bug #1064462 [lintian] gem2deb: Case sensitive handling of d/control Bug reassigned from package 'lintian' to 'gem2deb'. No longer marked as found in versions lintian/2.104.0 and lintian/2.110.0. Ignoring request to alter fixed versions of bug #1064462 to the same values previously set -- 1064462: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064462 977322: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977322 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#977322: Following advice of cute-field tag for X-DhRuby-Root breaks build
Control: clone -1 -2 Control: retitle -2 gem2deb: Case sensitive handling of d/control Control: reassign -2 gem2deb On Sun, 13 Dec 2020 15:27:20 -0800 Russ Allbery wrote: Package: lintian Version: 2.104.0 Severity: normal Lintian now emits the following pedantic tag for packages using X-DhRuby-Root: P: remctl source: cute-field debian/control@ruby-remctl X-DhRuby-Root vs X-Dhruby-Root N: P: cute-field N: N: The named field uses a free-style form of capitalization, which is N: permitted by policy. The alternative offered is probably a more common N: variant in the archive. N: N: Refer to Debian Policy Manual section 5.1 (Syntax of control files) N: for details. N: N: Severity: pedantic N: N: Check: fields/style However, following this advice breaks the Ruby package tooling. The build products are not copied into the package correctly and the resulting package is empty. Apparently the Ruby package tooling requires that specific capitalization. This is with gem2deb 1.4. [...] Hi On one end, I do not think `lintian` decides the canonical case / spelling of a field. In that sense, I feel this bug is valid. On the flip side, gem2deb does not follow the deb822 if field name case matters. The format is defined as case-insensitive. """ Field names are not case-sensitive, but it is usual to capitalize the field names using mixed case as shown below. Field values are case-sensitive unless the description of the field says otherwise. """ Cloned and reassigned accordingly. Best regards, Niels
Bug#901631: Bug#901507: lintian: warn if dh-* sequence is in B-D-Arch or B-D-Indep but not Build-Depends
On Wed, 21 Feb 2024 at 21:55:08 +0100, Niels Thykier wrote: > On Mon, 18 Jun 2018 12:16:55 +0100 Simon McVittie wrote: > > I hadn't intended that you'd add this mechanism for packages that > > ship debhelper addons alongside other content, just the ones that have > > little or no purpose other than their debhelper addons, like most/all > > of the dh-$addon family, and maybe some of the pkg-$team-tools family. > > Some dh add-ons can be in ``Build-Depends-Indep`` now and is used to support > cross-building in some cases. I do not remember when the feature was added > though, so it might not have been possible at the time this was filed. If I remember correctly, the reason I opened the bug is that while doing unrelated bug-fixing I was seeing a significant number of source packages that failed to `debian/rules clean` if you install only the Build-Depends. The typical scenario was that a source package that only builds Architecture: all binaries would have debhelper or a sequence addon that runs during clean (like gnome-pkg-tools) in its Build-Depends-Indep. At the time I opened this bug, I think the only way to activate a sequence addon was like `dh $@ --with gnome`, which is difficult to set up to happen conditionally for some but not all builds. I think the whole dh-sequence-foo mechanism was added since then, and is a big improvement. Yes, if an addon is activated via dh-sequence-foo (for example "Build-Depends(|-Arch|-Indep): dh-sequence-gnome"), then it can be in Build-Depends-Indep, and it will just not be activated during -B builds. For some addons this is normal, and for some addons this will mean it doesn't work as intended - it depends what the addon does. But, either way, that isn't going to break the ability to `debian/rules clean` without the addon. So I think it would make sense for the the dh-sequence-foo names to be excluded from any check that is intended to be a solution for this bug. smcv
