Bug#905866: uscan: prefers watch files from a random dir over debian/watch

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#905866: uscan: prefers watch files from a random dir over debian/watch

Adam Borowski-3
Package: devscripts
Version: 2.18.3
Severity: normal

Hi!
If the upstream source includes some bad debian packaging, it's likely
there'll be a watch file somewhere, usually bogus and/or stale.
For this reason, source format 3.0 deletes /debian/ from inside the
tarball -- and if the upstream packaging lives in a non-standard places,
that's harmless as no tool has bogus ideas like searching elsewhere.
Other than uscan, that is.

If there's a bad watch file, let's say source/debian/watch, uscan will
randomly (based on filesystem order?) prefer that over debian/watch.

Source format 3.0 (quilt) doesn't allow deleting files sanely: it ignores
deletions, assuming that the clean target will delete them before build.
This works for anything that calls debian/rules targets, but not for uscan.
Thus, I'd need to repack the .orig tarball just to workaround this.

This is similar to #895982 (uscan looking for debian/changelog in VCS) dirs.

What's even the purpose of search for watch and changelog in places other
than debian/ ?


Meow.
-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBCHANGE_RELEASE_HEURISTIC=log
DEBSIGN_KEYID=FD9CE2D8D7754B78AB279BBD2C3B436FEAC68101
DSCVERIFY_KEYRINGS="~/.gnupg/pubring.gpg"

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-rc7-debug-00037-gda205b923a99 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Reply | Threaded
Open this post in threaded view
|

Bug#905866: either skip deep search, or put /debian/ first

Adam Borowski-3
> If there's a bad watch file, let's say source/debian/watch, uscan will
> randomly (based on filesystem order?) prefer that over debian/watch.

Solutions:
* (preferred): drop the deep search feature
* check for /debian/watch first

--
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal [Mt3:16-17]
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs [Mt14:17-20, Mt15:34-37]
⠈⠳⣄⠀⠀⠀⠀ • use glitches to walk on water [Mt14:25-26]

Reply | Threaded
Open this post in threaded view
|

Bug#905866: uscan: prefers watch files from a random dir over debian/watch

Xavier Guimard-3
In reply to this post by Adam Borowski-3
Hi,

could you give me an example ?

Cheers,
Xavier

Reply | Threaded
Open this post in threaded view
|

Bug#905866: uscan: prefers watch files from a random dir over debian/watch

Daniel Schepler-6
In reply to this post by Adam Borowski-3
I find the recursive search feature useful for when I have a large
collection of unpacked source packages in $HOME/src/debian, then I can
"cd ~/src/debian; uscan --report" to check for updates to any of those
source packages.

As for an example I've run into:
https://ftp.gnu.org/gnu/ncurses/ncurses-6.1.tar.gz contains several
invalid debian/watch files which trigger error messages in the
multiple-package uscan run until I manually delete them.
--
Daniel Schepler

Reply | Threaded
Open this post in threaded view
|

Bug#905866: uscan: prefers watch files from a random dir over debian/watch

Adam Borowski-3
On Thu, Apr 11, 2019 at 10:40:54AM -0700, Daniel Schepler wrote:
> I find the recursive search feature useful for when I have a large
> collection of unpacked source packages in $HOME/src/debian, then I can
> "cd ~/src/debian; uscan --report" to check for updates to any of those
> source packages.
>
> As for an example I've run into:
> https://ftp.gnu.org/gnu/ncurses/ncurses-6.1.tar.gz contains several
> invalid debian/watch files which trigger error messages in the
> multiple-package uscan run until I manually delete them.

Hmm, I'm not sure which side you're arguing for then.  The former sounds
as if you prefer recursive search, while the latter says why it's bad.

My issue with it is that:
* there's no easy way to get rid of a bogus watch file (would need to
  repack the upstream tarball)
* our official tools (such as the QA tracker) can't cope with known-bad
  output

Even the use case you mention would work better with a shell one-liner
such as:
    for x in */debian/watch;do uscan --report "${x%/debian/watch}";done
which won't fall into the bad watch files.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
⠈⠳⣄⠀⠀⠀⠀