Processed: Re: Bug#890361: lintian: handling of new source override location possibly buggy

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 890361 + pending
Bug #890361 [lintian] lintian: handling of new source override location 
possibly buggy
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
890361: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890361
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#890361: lintian: handling of new source override location possibly buggy

[Chris Lamb]

tags 890361 + pending
thanks

Hi Thorsten,

> sorry, I don’t even have a testcase. I only noticed it during
> looking at the source, trying to figure out whether a symlink
> in the new position was good enough.

:)

> >  +last if $file;

Applied here:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=b8bea4b6ba77319314045e738fa2df35d099ee0b

Many thanks :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#890361: lintian: handling of new source override location possibly buggy

[Thorsten Glaser]

Hi Chris,

>I think you're right. Here's one patch - can you quickly test it works
>for you?

sorry, I don’t even have a testcase. I only noticed it during
looking at the source, trying to figure out whether a symlink
in the new position was good enough.

>  +last if $file;

But this is probably it, yes.

>… but, just for giggles, here's another silly one:

That looks also good ;-)

>Compat level 5 (!).

Well, 5 was the standard/minimum for a long time,
and I don’t use the newer features anyway (not those
visible to the user; those in the background, such
as using gzip’s -n option, are, of course, used),
so I’d just use compat 5 and get whatever version
the target distro had with whatever of its fixes.

>(What's wrong with the  debhelper versions in
>backports, out of interest?)

I try to keep backports dependencies out if possible.

I also maintain, in my own (public) repo and in the
private one of my employer, backports much far back
than oldoldstable, for those who are still running
such systems or chroots someplace. This started out
with back to etch (but, back then, lenny was stable,
so it was not that much of a, well, stretch (no pun
intended)), but eventually we discovered a sarge sy‐
stem somewhere at the workplace, so I targetted that
with a handful of packages until we could upgrade it
(it’s long gone, thankfully, but it’s no effort to
keep what I already *have* working in the old versions,
working in those; though I don’t create new backports
to such old versions). It’s also a portability exercise…

bye,
//mirabilos
-- 
13:22⎜«neurodamage» mira, what's up man? I have a CVS question for you in #cvs
13:22⎜«neurodamage» since you're so good w. it │ «neurodamage:#cvs» i love you
17:14⎜ Thanks big help you are :-)mira|nwt: ty again
18:36⎜«ThunderChicken:#cvs» mirabilos FTW!  23:03⎜«mithraic:#cvs» aaah. thanks

Processed: Re: Bug#890361: lintian: handling of new source override location possibly buggy

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 890361 + patch
Bug #890361 [lintian] lintian: handling of new source override location 
possibly buggy
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
890361: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890361
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#890361: lintian: handling of new source override location possibly buggy

[Chris Lamb]

tags 890361 + patch
thanks

Hey Thorsten!

> I’m fairly sure the code around lines 56-62 of
> /usr/share/lintian/collection/override-file
> does NOT prefer the first (cf. line 44ff.)
> but the last override file found.

I think you're right. Here's one patch - can you quickly test it works
for you?

  diff --git a/collection/override-file b/collection/override-file
  index 04c43fc6d..70ad1fb35 100755
  --- a/collection/override-file
  +++ b/collection/override-file
  @@ -59,6 +59,7 @@ sub collect {
   } elsif (-f "$override.gz") {
   $file = "$override.gz";
   }
  +last if $file;
   }
   

… but, just for giggles, here's another silly one:

  diff --git a/collection/override-file b/collection/override-file
  index 04c43fc6d..b6bad50a5 100755
  --- a/collection/override-file
  +++ b/collection/override-file
  @@ -41,14 +41,14 @@ sub collect {
   unlink("$dir/override");
   }
   
  -# Pick the first of these files that exists.  Prefer
  +# Pick the last of these files that exists.  Prefer
   # source/lintian-overrides to source.lintian-overrides for source
   # packages.
   my (@overrides, $file);
   if ($type eq 'source') {
   @overrides = (
  -"$dir/unpacked/debian/source/lintian-overrides",
   "$dir/unpacked/debian/source.lintian-overrides"
  +"$dir/unpacked/debian/source/lintian-overrides",
   );
   } else {
   @overrides = ("$dir/unpacked/usr/share/lintian/overrides/$pkg");


> I’m a tad annoyed at such incompatible changes,
> but also (not scope of this bugreport) having to
> jump to the latest debhelper version when 5 is
> enough for me.

Compat level 5 (!).  (What's wrong with the  debhelper versions in
backports, out of interest?)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#890361: lintian: handling of new source override location possibly buggy

[Thorsten Glaser]

Package: lintian
Version: 2.5.74
Severity: minor

I’m fairly sure the code around lines 56-62 of
/usr/share/lintian/collection/override-file
does NOT prefer the first (cf. line 44ff.)
but the last override file found.

I think there’s a break missing in lines 58 and 60.
(Or, well, the Perl equivalent; I don’t speak Perl.)

It’s also a bit unfortunate that, if I have both
(one being a symlink to the other), I still have¹
to override that the old location is used. I prefer
my packages backportable with ease, which is why
I’m a tad annoyed at such incompatible changes,
but also (not scope of this bugreport) having to
jump to the latest debhelper version when 5 is
enough for me.

① live example: git clone \
https://evolvis.org/anonscm/git/alioth/jupp.git
  (dump http transport, so may take a minute)

-- System Information:
Debian Release: buster/sid
  APT prefers unreleased
  APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils  2.30-4
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1
ii  dpkg  1.19.0.5
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdigest-sha-perl6.01-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-4+b1
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.1-1
ii  patchutils0.3.4-2
ii  perl  5.26.1-4+b1
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information