On my Debian Buster system, dig fails to work with ;; This program requires DiG version 2.1 or newer, which I cannot find. Checking on this, I saw that the "ver" call in line 109 doesn't output a version number anymore. So I changed that to dig -v. Next, sed was unable to extract a meaningful version number from what dig -v provided, so I changed the sed statement in the same line accordingly. The following replacement for line 109 works for me. ver=`dig -v 2>&1 | grep DiG | head -1 | sed -e 's/^DiG \([0-9.]\+\).*$/\1/'` My changes might introduce non-backwards compatible changes, though.
Hi Patrik, Florian, apparently it's either only broken in buster, or it's not always broken. As it's too late to fix this for the upcoming release of bullseye in two weeks, I mark this bug as bullseye-ignore (Release Team member hat on). If the package is broken in buster only, that may be fixed via a point release update. Paul paul@mulciber ~ $ dlint debian.org WARNING: tempfile is deprecated; consider using mktemp instead. WARNING: tempfile is deprecated; consider using mktemp instead. WARNING: tempfile is deprecated; consider using mktemp instead. WARNING: tempfile is deprecated; consider using mktemp instead. WARNING: tempfile is deprecated; consider using mktemp instead. WARNING: tempfile is deprecated; consider using mktemp instead. WARNING: tempfile is deprecated; consider using mktemp instead. WARNING: tempfile is deprecated; consider using mktemp instead. ;; dlint version 1.4.0, Copyright (C) 1998 Paul A. Balyoz <pab@domtools.com> ;; Dlint comes with ABSOLUTELY NO WARRANTY. ;; This is free software, and you are welcome to redistribute it ;; under certain conditions. Type 'man dlint' for details. ;; command line: /usr/bin/dlint debian.org ;; flags: normal-domain recursive. ;; using dig version 9.16.15 ;; run starting: di 3 aug 2021 19:58:00 CEST ;; ============================================================ ;; Now linting debian.org ;; Checking serial numbers per nameserver ;; 2021080326 sec1.rcode0.net. ;; 2021080326 nsp.dnsnode.net. ;; 2021080326 sec2.rcode0.net. ;; 2021080326 dns4.easydns.info. ;; All nameservers agree on the serial number. ;; Now caching whole zone (this could take a minute) ;; trying nameserver dns4.easydns.info. ERROR: no A records found. ;; no subzones found below debian.org, so no recursion will take place. ;; ============================================================ ;; dlint of debian.org run ending with errors. ;; run ending: di 3 aug 2021 19:58:01 CEST
Control: severity -1 important Control: tags -1 + unreproducible I can't reproduce this in a Debian buster chroot. Could you investigate more closely why it fails on your system? The command there still works for me in buster: $ dig localhost any | grep DiG | head -1 | sed -e 's/.*DiG \([0-9.]*\).*/\1/' 9.11.5 This seems like a much more correct way to check the version, so it should be used instead anyway. I also have 1:9.11.5.P4+dfsg-5.1+deb10u5.
Hello Paul, sorry for letting you wait for so long. Had a lot of other, more important duties at hand. Meanwhile I'm at Bullseye, and the issue persists. I'm using a .digrc to minimize output for my "ordinary" user: +ret=2 +noauthority +noadditional +noquestion +nostats +nocmd For root (with no .digrc), the stock command still works. Yes, unless you make dig less talkative with +nocmd. Thanks for confirming my opinion. :wq! PoC
Control: tags -1 - unreproducible + confirmed patch After copying your dig config I can now reproduce the error. That looks like the cause of this problem indeed. This only shows up in the non-default configuration, removing the non-default option works around the issue and users have an easy change they can apply to fix the issue while keeping the non-default option. Consequently I think that important is the right severity and that the bug should not cause removal of dlint from Debian testing (bookworm). I hope the dlint maintainer (CCed) can fix this, but they don't seem to be very active in Debian. There is also no upstream for the package. So the bug isn't likely to get fixed any time soon. If you have time to maintain the package, salvaging it might be the best way forward. Otherwise please apply the fix locally for now.