Bug#1057881: Please drop Felix from Uploaders

2023-12-09 Thread Felix Lechner
Package: nullmailer
Severity: wishlist

Hi David,

Please remove my name from the list of Uploaders at your convenience.  I
switched to OpenSMTPd and am not a good contributor anymore.  Thanks!

Kind regards
Felix



Bug#1057340: Please drop Felix from Uploaders

2023-12-03 Thread Felix Lechner
Package: wolfssl
Severity: wishlist
X-Debbugs-CC: Bastian Germann 

Hi Bastian,

Please replace my name with yours in the Uploaders field when you get a
chance. I do not have time to help maintain wolfSSL at the moment since
my wife had a baby. Thanks!

Kind regards
Felix



Bug#1040002: Drop Felix from Uploaders

2023-06-30 Thread Felix Lechner
Package: nullmailer
Severity: wishlist

Hi David,

I have not used nullmailer in a little while, and I do not plan to
work on the package in the near future.

Please remove my email address from the Uploaders field at your leisure. Thanks!

Kind regards
Felix

P.S. The proposed change alone did not seem to justify an upload.



Bug#1023697: wolfSSL 5.5.4 uploaded

2022-12-27 Thread Felix Lechner
Hi,

> there is considerable interest in using WolfSSL

I uploaded version 5.5.4-1, which was released last week, to the archive.

Kind regards
Felix Lechner



Bug#1023697: Keep out of testing

2022-12-08 Thread Felix Lechner
Hi,

On Fri, Nov 25, 2022 at 4:27 AM Bastian Germann  wrote:
>
> It would be great to address the CVEs with patches on 4.6.0+p1-0+deb11u1.

A proposed update for the 11.6 point release of bullseye, which is
scheduled for next weekend, was filed with the release team. [1] They
were also contacted for guidance via IRC.

Kind regards
Felix Lechner

[1] https://bugs.debian.org/1025789

cc: Security Team



Bug#1025789: bullseye-pu: wolfssl/4.6.0+p1-0+deb11u1_4.6.0+p1-0+deb11u2.debdiff

2022-12-08 Thread Felix Lechner
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-CC: sirkilam...@msn.com

Hi,

The wolfssl upstream released three patches for the version in Debian
stable specifically in order to address the following three
vulnerabilities present in bullseye:

- CVE-2022-42961, scored by NVD as "5.3 medium" [1]
- CVE-2022-39173, scored by NVD as "7.5 high" [2]
- CVE-2022-42905, scored by NVD as "9.1 critical" [3]

All three vulnerabilities are being tracked by DSA. [4] They were
already fixed in unstable.

There is no separate bug for the stable package.

Given the increased popularity of the package [5] and the severity of
the vulnerabilities, it seemed prudent to offer users of Debian stable
an update.

This bug was filed with a view toward the upcoming point release 11.6
for bullseye, which is scheduled for December 17. The freeze starts
this weekend.
The proposed upload has not seen a lot of testing.

Following devref 5.5.1 [7] a source debdiff was attached.

Please let me know if the version number is right and if you need any
more information, or whether I may upload the package. Thanks!

Kind regards,
Felix Lechner

[1] https://nvd.nist.gov/vuln/detail/CVE-2022-42961
[2] https://nvd.nist.gov/vuln/detail/CVE-2022-39173
[3] https://nvd.nist.gov/vuln/detail/CVE-2022-42905
[4] https://security-tracker.debian.org/tracker/source-package/wolfssl
[5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023697#28
[6] https://lists.debian.org/debian-release/2022/11/msg00251.html
[7] 
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions


wolfssl_4.6.0+p1-0+deb11u1.dsc_wolfssl_4.6.0+p1-0+deb11u2.dsc.debdiff.xz
Description: Binary data


Bug#1023697: Keep out of testing

2022-11-15 Thread Felix Lechner
Hi,

On Tue, Nov 8, 2022 at 12:00 PM Moritz Muehlenhoff  wrote:
>
> open security issues

I also just uploaded a backport for bullseye.

Kind regards,
Felix Lechner



Bug#1023835: wolfssl: FTBFS because of amd64-only symbols in symbols file

2022-11-10 Thread Felix Lechner
Hi,

On Thu, Nov 10, 2022 at 4:06 PM Bastian Germann  wrote:
>
> Please keep the three symbols out of the symbols file or make them optional.

Thanks. We are aware of the issue.

Unfortunately, your suggestion will likely cause a build failure on
amd64. How do you make the symbols "optional" please? Thanks!

Kind regards,
Felix Lechner



Bug#1023697: Version 5.5.3-1 is in the NEW queue

2022-11-09 Thread Felix Lechner
Hi,

FWIW, version 5.5.3-1 was accepted into the NEW queue.

Kind regards
Felix Lechner



Bug#1023697: Keep out of testing

2022-11-08 Thread Felix Lechner
Hi,

On Tue, Nov 8, 2022 at 12:00 PM Moritz Muehlenhoff  wrote:
>
> wolfssl has no active maintainer, plenty of open security issues and we 
> already
> have too many TLS libraries in our releases. Keep it out of testing. I'm going
> to file bugs against the handful of reverse deps.

Sorry, I have been out ill, but please do what you think is right.

Kind regards
Felix



Bug#1021021: Upload planned

2022-10-09 Thread Felix Lechner
Hi,

I plan to upload version 5.5.1 in the near future.

Kind regards
Felix Lechner



Bug#1010930: guix: May need CA certificates

2022-05-13 Thread Felix Lechner
Package: guix
Severity: wishlist

Hi,

I used guix on a minimal Debian 11 to cross-install the Guix System
and ran 'guix pull' before doing so. When I adapted the first file
here [1] 'guix system init' failed due to missing certificates. The
issue went away after I installed the standard certificate bundle via
'apt install ca-certificates'.

On an unrelated side note, 'info guix' showed information in Spanish
despite LC_ALL=en_US.UTF-8. That was from Debian's 'info', which I had
installed with 'apt install info'.

Thanks for bringing the great Guix package manager to Debian! I
believe it is superior to Dpkg.

Kind regards
Felix Lechner

[1] https://guix.gnu.org/manual/en/html_node/Using-the-Configuration-System.html



Bug#1010703: haskell-hashable: FTBFS on i386: unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'

2022-05-08 Thread Felix Lechner
Control: reassign -1 haskell-devscripts
Control: retitle -1 haskell-devscripts: Shell expansion breaks nested
quotes in GHC arguments
Control: affects -1 haskell-hashable

Hi,

> unrecognized 'configure' option `-D_FILE_OFFSET_BITS=64'

I believe the quotes in haskell-hashable here: [1]

DEB_SETUP_GHC_CONFIGURE_ARGS = --hsc2hs-options="$(LFS_CFLAGS)"
--gcc-options="$(LFS_CFLAGS)" --ghc-options="$(GHC_LFSFLAGS)"

are lost when the environment variable is shell-expanded in
haskell-devscripts here: [2]

# DEB_SETUP_GHC_CONFIGURE_ARGS can contain multiple arguments
# with their own quoting so run through a shell expansion
my $ghc_configure_args = run_quiet(
qw{sh -c},
'echo -n '
  . $DOUBLE_QUOTE
  . ($ENV{DEB_SETUP_GHC_CONFIGURE_ARGS} // $EMPTY)
  . $DOUBLE_QUOTE
    );

Kind regards,
Felix Lechner

[1] 
https://salsa.debian.org/haskell-team/DHG_packages/-/blob/master/p/haskell-hashable/debian/rules#L6
[2] 
https://salsa.debian.org/haskell-team/haskell-devscripts/-/blob/master/lib/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm#L597-605



Bug#1010025: ghc: Haddock fails with internal error when calculating transitive dependencies

2022-04-26 Thread Felix Lechner
Hi Scott,

On Tue, Apr 26, 2022 at 7:23 AM Scott Talbert  wrote:
>
> it's a core package and I'm new here

I'm also not the right person to merge it, but I think Debian may be
getting a new GHC version soon. Was the fix applied upstream?

Kind regards
Felix Lechner



Bug#1010025: ghc: Haddock fails with internal error when calculating transitive dependencies

2022-04-24 Thread Felix Lechner
Hi Scott,

> Warning: The documentation for the following packages are not installed. No
> links will be generated to these packages: dlist-0.8.0.8, hashable-1.3.0.0,
> transformers-compat-0.6.5

Can you please try to see if the error goes away when those
prerequisites are made available?

I believe they are in:

libghc-dlist-doc
libghc-hashable-doc
libghc-transformers-compat-doc

Thanks!

Kind regards
Felix Lechner



Bug#1009883: dh_haskell_install_ghc_registration: does not support directories

2022-04-21 Thread Felix Lechner
Hi Scott,

> It's not quite clear to me how a directory is supposed to be handled

First off, thank you for your bug reports. I recently rewrote the
Haskell tooling to allow the use of Debhelper's dh sequencer with all
features. Unfortunately, I recently started using another OS and may
not be able to iron out all the kinks in the new code.

As for this bug, I was aware that I broke the directory feature but,
like you, was also not sure right away about how to handle it
properly. The directory feature for package registrations is described
in the documentation. [1]

Kind regards
Felix Lechner

[1] 
https://downloads.haskell.org/cabal/Cabal-3.0.0.0/doc/users-guide/installing-packages.html#cmdoption-setup-register-gen-pkg-config



Bug#1009988: O: postgresql-semver -- Semantic version number type for PostgreSQL

2022-04-21 Thread Felix Lechner
Package: wnpp
Severity: normal

Hi,

This Postgres data type was used for the most recent Lintian website.

Kind regards,
Felix Lechner



Bug#1009983: O: mdadm -- Tool to administer Linux MD arrays (software RAID)

2022-04-21 Thread Felix Lechner
Package: wnpp
Severity: normal

Hi,

This is an exciting opportunity to assume maintenance of an important
package. It is now available for your adoption!

Kind regards,
Felix Lechner



Bug#1009982: O: pius -- Tools to help before and after key-signing parties

2022-04-21 Thread Felix Lechner
Package: wnpp
Severity: normal

Hi,

This package is low maintenance and now available for your adoption!

Kind regards,
Felix Lechner



Bug#1009980: O: wxedid -- Graphical editor for monitor resolution and timing data (EDID)

2022-04-21 Thread Felix Lechner
Package: wnpp
Severity: normal

Hi,

This package is low maintenance and now available for your adoption!

You can use this software when repairing your monitor's EDID. [1]

Kind regards,
Felix Lechner

[1] https://wiki.debian.org/RepairEDID



Bug#1009978: O: gammastep -- Adjust display hue to outside lighting conditions

2022-04-21 Thread Felix Lechner
Package: wnpp
Severity: normal

Hi,

This package is low maintenance and now available for your adoption!

Kind regards,
Felix Lechner



Bug#1009975: O: libgsm -- Shared libraries for GSM speech compressor

2022-04-21 Thread Felix Lechner
Package: wnpp
Severity: normal

Hi,

This package is low maintenance and now available for your adoption!

Kind regards,
Felix Lechner



Bug#999738: Sample research tag, untested

2022-04-20 Thread Felix Lechner
diff --git a/lib/Lintian/Check/Languages/Guile/DynamicLink.pm
b/lib/Lintian/Check/Languages/Guile/DynamicLink.pm
new file mode 100644
index 00..dcbd250139
--- /dev/null
+++ b/lib/Lintian/Check/Languages/Guile/DynamicLink.pm
@@ -0,0 +1,68 @@
+# languages/guile/dynamic-link -- lintian check script -*- perl -*-
+
+# Copyright © 2021 Felix Lechner
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, you can find it on the World Wide
+# Web at http://www.gnu.org/copyleft/gpl.html, or write to the Free
+# Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+# MA 02110-1301, USA.
+
+package Lintian::Check::Languages::Guile::DynamicLink;
+
+use v5.20;
+use warnings;
+use utf8;
+
+use Const::Fast;
+usa List::SomeUtils qw(uniq);
+
+use Moo;
+use namespace::clean;
+
+with 'Lintian::Check';
+
+const my $LEFT_SQUARE_BRACKET => q{[};
+const my $RIGHT_SQUARE_BRACKET => q{]};
+
+sub visit_installed_files {
+my ($self, $item) = @_;
+
+return
+  unless $item->name =~ m{ [.] scm $}x
+  || $item->interpreter eq 'guile';
+
+# slurping contents for now
+my $contents = $item->decoded_utf8;
+return
+  unless length $contents;
+
+my @libraries
+  = ($contents
+  =~ m{ [(] define \s+ \S+ \s+ [(] dynamic-link \s+ "([^"]+)"
[)] [)] }gx
+  );
+
+$self->hint('guile-dynamic-link', $_,
+$LEFT_SQUARE_BRACKET . $item->name . $RIGHT_SQUARE_BRACKET)
+  for uniq @libraries;
+
+return;
+}
+
+1;
+
+# Local Variables:
+# indent-tabs-mode: nil
+# cperl-indent-level: 4
+# End:
+# vim: syntax=perl sw=4 sts=4 sr et

diff --git a/tags/g/guile-dynamic-link.tag b/tags/g/guile-dynamic-link.tag
new file mode 100644
index 00..d1faa0b92d
--- /dev/null
+++ b/tags/g/guile-dynamic-link.tag
@@ -0,0 +1,7 @@
+Tag: guile-dynamic-link
+Severity: classification
+Check: languages/guile/dynamic-link
+Explanation: Guile tries to load this shared library via a Scheme
expression like
+ (define libglib (dynamic-link "libglib-2.0")).
+See-Also:
+ Bug#999738



Bug#1009743: haskell-devscripts: recent changes cause haskell-hspec-discover to FTBFS

2022-04-15 Thread Felix Lechner
Control: fixed -1 0.16.11

Hi Scott,

I believe you saw a temporary malfunction. The sources for
haskell-hspec-discover_2.7.1 built locally with haskell-devscripts
0.16.11 in unstable. The tail of the log is below.

The disruption was caused by an effort to make the current build
system compatible with Debhelper's dh sequencer.

Thank you for your patience!

Kind regards,
Felix Lechner

* * *

[start of build log omitted]
dh_gencontrol -phspec-discover
dpkg-gencontrol: warning: package hspec-discover: substitution
variable ${haskell:ghc-version} unused, but is defined
dh_md5sums -phspec-discover
dh_builddeb -phspec-discover
dpkg-deb: building package 'hspec-discover' in
'../hspec-discover_2.7.1-1_amd64.deb'.
 dpkg-genbuildinfo
 dpkg-genchanges  >../haskell-hspec-discover_2.7.1-1_amd64.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build .
dpkg-buildpackage: info: full upload (original source is included)
Now running lintian haskell-hspec-discover_2.7.1-1_amd64.changes ...
W: hspec-discover: hardening-no-pie usr/bin/hspec-discover
W: haskell-hspec-discover source:
missing-license-paragraph-in-dep5-copyright debian/copyright mit (line
12)
W: haskell-hspec-discover source:
missing-license-text-in-dep5-copyright debian/copyright MIT (line 14)
W: hspec-discover: no-manual-page usr/bin/hspec-discover
W: haskell-hspec-discover source: no-nmu-in-changelog
W: haskell-hspec-discover source:
source-nmu-has-incorrect-version-number 2.7.1-1
I: hspec-discover: hardening-no-bindnow usr/bin/hspec-discover
I: hspec-discover: hardening-no-fortify-functions usr/bin/hspec-discover
I: haskell-hspec-discover source: older-debian-watch-file-standard 3
I: haskell-hspec-discover source: out-of-date-standards-version 4.1.4
(released 2018-04-05) (current is 4.6.0.1)
I: hspec-discover: unused-override binary-or-shlib-defines-rpath
X: haskell-hspec-discover source: debian-watch-does-not-check-gpg-signature
P: haskell-hspec-discover source: package-uses-old-debhelper-compat-version 10
P: hspec-discover: renamed-tag binary-or-shlib-defines-rpath =>
custom-library-search-path in line 1
X: haskell-hspec-discover source: upstream-metadata-file-is-missing
Finished running lintian.



Bug#1009679: lintian: False positive for OCaml info files

2022-04-14 Thread Felix Lechner
Hi Rafael,

On Thu, Apr 14, 2022 at 2:09 AM Rafael Laboissière  wrote:
>
> See
> https://salsa.debian.org/ocaml-team/dh-ocaml/-/commit/eae9dc26

What is the purpose of those files, please? Are they used in the oCaml
Lintian check?

Kind regards
Felix Lechner



Bug#994388: dpkg currently warning about merged-usr systems

2022-04-08 Thread Felix Lechner
Hi,

On Fri, Apr 8, 2022 at 1:48 AM Wouter Verhelst  wrote:
>
> The nuclear option here is obviously to take maintenance of dpkg away
> from the dpkg maintainer unless and until he decides to follow the
> rules.

This song is for Guillem:

https://www.youtube.com/watch?v=cnoX81TC6jk

Kind regards,
Felix Lechner



Bug#1009162: cabal-debian: Description in the Source section in d/control

2022-04-07 Thread Felix Lechner
Package: cabal-debian
Severity: wishlist

Hi,

The Haskel tooling in Debian may be able to use the Description field
in the Source paragraph of d/control without the X- prefix. For the
relevant policy discussion, please see here. [1]

Lintian allows the field already. [2]

Kind regards
Felix Lechner

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998165#81
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998115#28



Bug#1008130: lintian: support/use multi-threads (currently single threaded and slow)

2022-03-22 Thread Felix Lechner
Hi Samuel,

On Tue, Mar 22, 2022 at 3:15 PM Samuel Henrique  wrote:
>
> I believe there could be noticeable performance gains from using all
> the threads available.

I share your hope and have implemented two attempts to parallelize the
~300 or so checks.

My first attempt used IO::Async but failed. That module is probably
the best one currently available, but it replaces the SIGCHLD handler.
Lintian uses dozens of other modules that call external programs via
other means. Unfortunately, those do not interact well with IO::Async,
which causes the parallel execution to freeze or otherwise experience
strange bugs.

A particularly serious problem for Lintian was the interaction with
Path::Tiny. [1]

You may be able to find some details by searching the Git log for
"Heisenbug" (capital H, please).

My current implementation uses MCE [2] which works okay, but does not
yet yield the performance gains you and I are hoping for. That is why
the experimental branch has not been merged.

As far as I can tell, the degradation relates to the serializations
Perl performs between parent and child processes. It is possible to
"close" on the in-memory file indexes as part of the fork() but it's
not enough to explain the difference. (The indexes are large and also
being transitioned to disk for unrelated reasons.) Memory usage is
higher, as well.

I may have to implement better profiling before we make significant
progress. That is because at least half the time is spent generating
the file indexes, which require a different parallelization strategy
than the checks.

One long-term plan could be to have a data interchange format between
the parent and the child processes. It would also allow checks to be
written in other programming languages, such as Haskell, but I would
seek further community input before proceeding with anything like
that.

[1] https://github.com/dagolden/Path-Tiny/issues/224
[2] https://metacpan.org/pod/MCE

> Although I don't know how feasible that is with
> lintian+perl.

Perl performs surprisingly well for an interpreted language, but I am
not sure true "threading" works well. In Lintian, we use multiple
processes, if at all. That is how I interpreted your use of the word
"threads".

> Note that I didn't go all the way to debugging lintian to confirm it's
> single-threaded

You are right. For the purposes of your analysis, Lintian uses a single process.

Thank you for your valuable suggestions!

Kind regards,
Felix Lechner



Bug#1007922: false positive spelling: substract and subtract is both correct

2022-03-18 Thread Felix Lechner
Hi Thomas,

> substract and subtract are both correct

Where did you see that word?

> "Now nonstandard and rare"

Yeah, I'm with Russ. I found "sub-S-tract" in the 1913 Webster's
Dictionary but no longer in Webster's Second from 1960. (Finally,
those dusty volumes found some use.) I have never heard, or seen, that
form of "sub-tract," but let's give others a chance to chime in.

Kind regards,
Felix Lechner



Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff updated

2022-03-17 Thread Felix Lechner
Hi,

On Thu, Mar 17, 2022 at 11:49 AM Adam D. Barratt
 wrote:
>
> In that case, it would be slightly more conventional to use "4.6.0+p1-
> 0+deb11u1"

Thank you for that advice! I will use 4.6.0+p1-0+deb11u1 instead.

> Well, you control the naming of the orig tarball, so you'd just make it
> match the package.

Without wishing to appear argumentative, I did not seem smart to have
two different tarballs in the archive under the same
wolfssl_4.6.0.orig.tar.gz name.

> Please feel free to upload.

Thanks for that too, and for your hard work on the stable releases!

Kind regards,
Felix Lechner



Bug#1007717: Native source package format with non-native version

2022-03-17 Thread Felix Lechner
Hi,

On Thu, Mar 17, 2022 at 11:57 AM Russ Allbery  wrote:
>
> source package format

While everyone is receptive to new labels, I prefer "upload format" or
"archive format". Either one helps us to distinguish the intermediate
product from any workflow objects a maintainer may have.

> single tarball as a source package format

It is also not necessary to "define" unpatched sources in the archive
by how many tarballs they have, or any tarballs at all.

In fact, I wrote a manifest utility that could one day replace tarball
signatures with per-file hashes. The latter remain useful even when
sources are repackaged, because manifests can be cryptographically
daisy-chained in a "chain of custody." Of course, they would be more
often used for patched upload formats.

Kind regards
Felix Lechner



Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff updated

2022-03-17 Thread Felix Lechner
Hi,

On Thu, Mar 17, 2022 at 10:56 AM Adam D. Barratt
 wrote:
>
> That's a non-standard version for a stable update. What version do
> upstream regard this as?

4.6.0+p1

> (The conventional version string would be 4.6.0-3+deb11u1.)

That would not match the upstream version and would lead to the wrong
orig tarball, wouldn't it?

> You don't really need to mention who performed the backport here, FWIW.

I mentioned it in part to explain the new version string.

Kind regards,
Felix Lechner



Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff updated

2022-03-16 Thread Felix Lechner
Hi,

The attached debdiff contains an updated d/changelog (plus, an excerpt below):

(1) The target release now says 'bullseye'.
(2) Pursuant to a request from the security team, the annotation
CVE-2021-37155 was added to PR 3990.

Is this ready to upload? Thanks!

Kind regards,
Felix Lechner

* * *

wolfssl (4.6.0+p1-1) bullseye; urgency=medium

  * Stable update to address the following vulnerabilities. All fixes were
backported by upstream:
- PR 3676: CVE-2021-3336
- PR 3990: CVE-2021-37155 (OCSP Match Issue)
- PR 4211: CVE-2021-38597
- PR 4629: CVE-2021-44718
- PR 4813: CVE-2022-25638
- PR 4831: CVE-2022-25640
  * Drop 58f9b6ec01f0caf89e9e4d37a8816b310005aaf1.patch, which was previously
cherry-picked from upstream.
  * Upstream updated some certificates in the test suite.

 -- Felix Lechner   Mon, 14 Mar 2022 15:45:37 -0700


wolfssl_4.6.0-3.dsc_wolfssl_4.6.0+p1-1.dsc.debdiff.xz
Description: application/xz


Bug#1007717: Native source package format with non-native version

2022-03-16 Thread Felix Lechner
Hi,

On Tue, Mar 15, 2022 at 9:33 PM Russ Allbery  wrote:
>
> We should define native and non-native
> packages in terms of version numbers, and allow both native and non-native
> packages to use single-tarball source package formats.

I co-maintaintain several Debian-internal tools, and that description
is backwards. "Native" sources are characterized by their lack of
Debian patches.

On that note, the term "native" is also not great. The words "patched"
and "unpatched" describe the relationship between sources in the
archive and their respective upstreams more accurately.

As for version strings, we need no additional restrictions. The use of
patches is declared in source format 3.0. Some folks even use Debian
revisions for unpatched sources. [1]

Most significantly, Lintian's parser is unable to deduce "nativeness"
from the version number. The native status is a required input! [2]

Please do not "define" a source's patch status via the version string.
It's what got us here in the first place. Debian version numbers are
complicated enough already. Thank you!

Kind regards,
Felix Lechner

[1] for example, https://tracker.debian.org/pkg/python3-defaults
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Changelog/Version.pm#L79-80



Bug#1007717: Native source package format with non-native version

2022-03-15 Thread Felix Lechner
Hi Ian,

On Tue, Mar 15, 2022 at 11:54 AM Ian Jackson
 wrote:
>
> I do remember this coming up
> before, but I don't seem to be able to find a record of it now.

Perhaps you were thinking about this discussion in a bug against Lintian?

Ideally I would like dpkg-source to permit source format
`3.0 (native)' packages to have a non-native version number. [1]

Kind regards,
Felix Lechner

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953554#30



Bug#554006: lintian: Warn if package ships files in /etc/cron.* without depending on cron

2022-03-14 Thread Felix Lechner
Hi,

On Mon, Mar 14, 2022 at 1:36 PM Josh Triplett  wrote:
>
> I don't think lintian should warn about this, for two reasons:

Are you saying the condition should indicate a visibility level lower
than a warning, or that the tag should not be implemented at all?
Thank you!

Kind regards,
Felix Lechner



Bug#1007261: bullseye-pu: wolfssl/4.6.0-3_4.6.0+p1-1.debdiff

2022-03-14 Thread Felix Lechner
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Hi,

The wolfssl upstream released a fixed version [1] of their library
(4.6.0) that we already have in stable. Upstream would now like to see
the fixed version in stable, if possible.

The six fixes are not large, but all of them address grave or serious CVEs.

* PR 3676: CVE-2021-3336
* PR 3990: OCSP Match Issue
* PR 4211: CVE-2021-38597
* PR 4629: CVE-2021-44718
* PR 4813: CVE-2022-25638
* PR 4831: CVE-2022-25640

They relate to wolfSSL's support for TLS 1.3, which they were the
first to implement commercially. [2] More details, including URLs, are
available below.

According to upstream, the fixed version includes no new features.

All six patches are already in version 5.2.0-2 in testing and
unstable, as well as in 5.2.0-2~bpo11+1 in bullseye-backports.

One Debian patch already addressed CVE-2021-3336. It had been
cherry-picked and was dropped with the availability of this version.

Given the issue with openssl/valgrind years ago, I asked upstream to
maintain a "stable" branch with a four-eye review by another member of
the cryptographic staff.

As their Debian distributor, I prefer not to backport fixes from Git myself.

As mentioned in the changelog, upstream also updated some certificates
in the test suite.

Following devref 5.5.1, a source debdiff was attached.

Thank you for your guidance!

Kind regards,
Felix Lechner

P.S. I used to work upstream.

[1] look for +p1, https://github.com/wolfSSL/wolfssl/releases/tag/v4.6.0-stable
[2] 
https://www.prweb.com/releases/wolfssl_announces_the_first_commercial_release_of_tls_1_3/prweb15672854.htm

* * *

Hi Felix,

No risks. The code in the affected areas hasn’t changed and has been
broken since our TLS v1.3 support was originally created.

Tomorrow morning I’ll put together a package and sign it and have
another engineer review and sign it also.

* * *

Hey Felix,

In order to update the stable v4.6.0 on Debian I’ve back-ported the
following high severity fixes to v4.6.0-stable:

* PR 3676: CVE-2021-3336
* PR 3990: OCSP Match Issue
* PR 4211: CVE-2021-38597
* PR 4629: CVE-2021-44718
* PR 4813: CVE-2022-25638
* PR 4831: CVE-2022-25640

I’ve posted a +p1 bundle and signature to the release page here:
https://github.com/wolfSSL/wolfssl/releases/tag/v4.6.0-stable

* wolfssl-4.6.0-stable+p1.tar.gz (SHA256:
3a112c1436bbd1afdb457d0a517312d03ab430c74b98f95a20a028d41440099e)
* wolfssl-4.6.0-stable+p1.tar.gz.asc

Note: The make check fails due to some expired certificates. If you
think it is important I can update those expired certs in the bundle
and re-sign re-post…

* * *

Hey Felix,

FYI: Here is the script I’ve written up to create a new official
patch. This is my take on patches that should be applied.

#!/bin/bash

# Get Release
curl -L -o wolfssl-4.6.0-stable.tar.gz
https://github.com/wolfSSL/wolfssl/archive/refs/tags/v4.6.0-stable.tar.gz
tar xzvf wolfssl-4.6.0-stable.tar.gz
cd wolfssl-4.6.0-stable

# CVE-2021-3336
curl -L -o pr3676.diff https://github.com/wolfSSL/wolfssl/pull/3676.diff
patch -p1 < pr3676.diff

# OCSP Match Issue
curl -L -o pr3990.diff https://github.com/wolfSSL/wolfssl/pull/3990.diff
patch -p1 < pr3990.diff

# CVE-2021-38597
curl -L -o pr4211.diff https://github.com/wolfSSL/wolfssl/pull/4211.diff
patch -p1 < pr4211.diff

# CVE-2021-44718
curl -L -o pr4629.diff https://github.com/wolfSSL/wolfssl/pull/4629.diff
patch -p1 < pr4629.diff

# CVE-2022-25638
curl -L -o pr4813.diff https://github.com/wolfSSL/wolfssl/pull/4813.diff
patch -p1 < pr4813.diff

# CVE-2022-25640
curl -L -o pr4831.diff https://github.com/wolfSSL/wolfssl/pull/4831.diff
patch -p1 < pr4831.diff

rm *.diff
cd ..

# Tar/GZ
tar -czvf wolfssl-4.6.0-stable-patched.tar.gz wolfssl-4.6.0-stable

# Sign
gpg --armor --default-key 5CA29677 --detach-sign
wolfssl-4.6.0-stable-patched.tar.gz
shasum -a 256 wolfssl-4.6.0-stable-patched.tar.gz


wolfssl_4.6.0-3.dsc_wolfssl_4.6.0+p1-1.dsc.debdiff.xz
Description: application/xz


Bug#1007140: please have a check for chown user.group

2022-03-11 Thread Felix Lechner
Hi,

On Fri, Mar 11, 2022 at 1:18 PM Marc Haber
 wrote:
>
> [^[:alpha:]]chown[[:space:]][^[:space:]]+\.[^[:space:]]

I cannot get that search to work properly on codesearch.d.n. Do you
have a sample from the archive, please?

Kind regards
Felix Lechner



Bug#998367: perlcritic: "Code not tidy' after perltidy

2022-03-07 Thread Felix Lechner
Hi,

On Sun, Nov 7, 2021 at 11:37 PM intrigeri  wrote:
>
> The bug lies in the interaction between these 2 tools.

Yay, the problem was solved! [1] Will you please deploy the fix with a
little bit of urgency? Lintian's pipeline has been malfunctioning for
a little while. Thanks!

Kind regards,
Felix Lechner

[1] 
https://github.com/Perl-Critic/Perl-Critic/issues/925#issuecomment-1048340859



Bug#1006866: ITP: hackage-tracker -- Haskell package version tracker

2022-03-06 Thread Felix Lechner
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-hask...@lists.debian.org
X-Debbugs-Cc: Joachim Breitner 

* Package name: hackage-tracker
  Version : 0.1.0
  Upstream Author : Felix Lechner 
* URL : https://salsa.debian.org/haskell-team/hackage-tracker
* License : AGPL-3.0-or-later
  Programming Lang: Haskell2010
  Description : Haskell package version tracker

Generates a file with information that can be used to update the
Debian versions on Hackage for each package available there. Those
versions appear in the Distribution field on Hackage.

Furthermore produces an HTML page that compares the Haskell package
versions available in Debian with those available on Hackage and
elsewhere.

The data is currently displayed at https://hackage-tracker.debian.net.

This software falls under the Haskell team's umbrella and will be
updated, managed and serviced going forward by members of the Haskell
team.



Bug#1006464: Please use "mdadm monitoring " as default MAILFROM

2022-02-28 Thread Felix Lechner
Hi,

On Fri, Feb 25, 2022 at 1:06 PM Marvin Renich  wrote:
>
> create a default From address that is useful when root's mail is being
> forwarded off the current system

We just released 4.2-2 in order to address this issue in part.

Hoping to improve the default MAILFROM value for all users we merely added the
host name for now. That value was readily available in upstream's code. The
patch has a better chance of being accepted upstream.

The /etc/mailname mechanism is specific to Debian. A later release of mdadm in
Debian may bring the MAILFROM value into compliance with Debian mail customs.

I tried to test the change but my local mail server replaces all From addresses
with meaningful values. (It was my fix for the reporter's issue.) Please let us
know if this patch does not work as expected.

Salsa is currently down. The patch is instead attached for your review.

Kind regards
Felix Lechner
Description: Add host name to default MAILFROM
 The host on which the error occurred is mentioned in the subject and also in
 the message body, but some may find it useful in the From address, as well.
Author: Felix Lechner 
Bug-Debian: https://bugs.debian.org/1006464
Forwarded: no
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/Monitor.c
+++ b/Monitor.c
@@ -440,8 +440,8 @@ static void alert(char *event, char *dev
 			if (info->mailfrom)
 fprintf(mp, "From: %s\n", info->mailfrom);
 			else
-fprintf(mp, "From: %s monitoring \n",
-	Name);
+fprintf(mp, "From: %s monitoring \n",
+	Name, hname);
 			fprintf(mp, "To: %s\n", info->mailaddr);
 			fprintf(mp, "Subject: %s event on %s:%s\n\n",
 event, dev, hname);


Bug#842549: haskell-devscripts: Dh_Haskell.sh should respect DH_VERBOSE settings

2022-02-27 Thread Felix Lechner
Hi,

> Dh_Haskell.sh doesn't respect the DH_VERBOSE settings

Dh_Haskell.sh cannot do that very well—at least not with respect to
suppressing output—because callers of the shell functions rely on
information in stdout for results. (The functions also reuse each
other.)

In a potential step forward, however, I wrote a Perl module that will
soon sidestep Dh_Haskell.sh when builds are started from dh-haskell's
dh sequencer. That Perl module will honor DH_VERBOSE.

A merge request is in the works and will be submitted when testing is complete.

Kind regards,
Felix Lechner



Bug#865640: dh-haskell: messes up substvars

2022-02-27 Thread Felix Lechner
Hi,

I am not sure this bug still exists with the rewrite of dh-haskell,
but please see below.

The dh sequencer now calls the same routines from Dh_Haskell.sh that
are also used by hlibrary.mk (both from haskell-devscripts), but under
both build systems I see the following messages for my source
'kickoff':

dpkg-gencontrol: warning: Depends field of package kickoff:
substitution variable ${haskell:Depends} used, but is not defined
dpkg-gencontrol: warning: Recommends field of package kickoff:
substitution variable ${haskell:Recommends} used, but is not defined
dpkg-gencontrol: warning: Suggests field of package kickoff:
substitution variable ${haskell:Suggests} used, but is not defined
dpkg-gencontrol: warning: Conflicts field of package kickoff:
substitution variable ${haskell:Conflicts} used, but is not defined
dpkg-gencontrol: warning: Provides field of package kickoff:
substitution variable ${haskell:Provides} used, but is not defined

There is also that one, but it may be less relevant:

dpkg-gencontrol: warning: package kickoff: substitution variable
${haskell:ghc-version} unused, but is defined

Kind regards
Felix Lechner



Bug#1006573: haskell-devscripts: CDBS module incompatible with debhelper-compat (= 10)

2022-02-27 Thread Felix Lechner
Package: haskell-devscripts
Severity: wishlist

Hi,

In my 'kickoff' sources, which use the CDBS module hlibrary.mk, the
d/compat file must be present. When I delete d/compat and instead
specify debhelper-compat (= 10) in Build-Depends, a d/compat file with
the value '5' is created. That causes follow-on issues like the one at
the bottom of this message.

This bug is merely a wishlist item in case someone plans to fix
hlibrary.mk. The issue goes away with the dh sequencer from
dh-haskell, which may be a better option for other reasons, as well.

Kind regards
Felix Lechner

* * *

➤ debclean
Cleaning in directory /lcl/lechner/lintian/kickoff
 dpkg-buildpackage --rules-target clean -rfakeroot -us -uc -ui
dpkg-buildpackage: info: source package kickoff
dpkg-buildpackage: info: source version 0.1.0
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Felix Lechner

 debian/rules clean
test -x debian/rules
rm -f debian/stamp-makefile-build debian/stamp-makefile-install
/usr/bin/make -C . CFLAGS="-g -O2
-ffile-prefix-map=/lcl/lechner/lintian/kickoff=.
-fstack-protector-strong -Wformat -Werror=format-security"
CXXFLAGS="-g -O2 -ffile-prefix-map=/lcl/lechner/lintian/kickoff=.
-fstack-protector-strong -Wformat -Werror=format-security"
CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" LDFLAGS="-Wl,-z,relro" -k
clean
make[1]: Entering directory '/lcl/lechner/lintian/kickoff'
cabal clean
make[1]: Leaving directory '/lcl/lechner/lintian/kickoff'
dh_clean
dh_clean: warning: Please specify the debhelper compat level exactly once.
dh_clean: warning:  * debian/compat requests compat 5.
dh_clean: warning:  * debian/control requests compat 10 via
"debhelper-compat (= 10)"
dh_clean: warning:
dh_clean: warning: Hint: If you just added a build-dependency on
debhelper-compat, then please remember to remove debian/compat
dh_clean: warning:
dh_clean: error: debhelper compat level specified both in
debian/compat and via build-dependency on debhelper-compat
make: *** [/usr/share/cdbs/1/rules/debhelper.mk:211: clean] Error 255
dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage --rules-target clean -rfakeroot -us -uc -ui failed



Bug#1006348: lintian: Tag improbable-bug-number-in-closes condition considers 7-digit bug numbers improbable

2022-02-23 Thread Felix Lechner
Hi,

On Wed, Feb 23, 2022 at 3:57 PM Ben Finney  wrote:
>
> const my $OUT_OF_REACH_BUG_NUMBER => 1_500_000;

Due to a new override format, which remained pending due to my
extremely critical commitment elsewhere, the change remains
unreleased.

I hope to get to Bug#1003272 tomorrow or on Friday, with a release
soon after that.

Kind regards
Felix Lechner



Bug#1005326: no-code-sections triggered on non-ELF files

2022-02-11 Thread Felix Lechner
Hi,

On Fri, Feb 11, 2022 at 12:09 PM Marc Dequènes  wrote:
>
> Could you consider improving the check?

Yes, I'd like to.

> readelf fails with "readelf: Error: Not an ELF file - it has the wrong
> magic bytes at the start"

I confirmed that Lintian's invocation produces that error for
usr/lib/dxvk/wine64-development/d3d10.dll.a in dxvk, but how can we
tell such archives apart from those that are legitimately broken?

Kind regards
Felix Lechner



Bug#1005200: lintian: prefer-uscan-symlink should to single maintainer packages at most

2022-02-08 Thread Felix Lechner
Control: forcemerge 1001458 -1

Hi,

On Tue, Feb 8, 2022 at 1:33 PM Scott Kitterman  wrote:
>
> It's not clear why this would be better

This tag was implemented at the suggestion of a very reputable fellow
contributor, but I am also not sure I understand the benefit. We may
drop the tag again.

I took the liberty to merge this bug with the bug advocating the removal.

Kind regards
Felix Lechner



Bug#1005049: lintian: incorrect leading comma in "sub oxford_enumeration"

2022-02-05 Thread Felix Lechner
Control: tags -1 + pending

Hi,

On Sat, Feb 5, 2022 at 4:39 PM Chris Lamb  wrote:
>
> The code in question is as follows:

The code for the serial comma is relatively well-tested. It is also
used on the website. On the website, you can see that a citation is
being swallowed ("social contract item 2"). [1] An empty string is
presented instead.

A look at the tag declaration confirms that an additional citation is
present but not being shown. [2] The bug is (or was) probably located
elsewhere.

More significantly, I can no longer reproduce the bug with the
development version in Git, per the output below.

May I please close this bug? Thank you!

Kind regards
Felix Lechner

[1] https://lintian.debian.org/tags/patch-not-forwarded-upstream
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/tags/p/patch-not-forwarded-upstream.tag#L12

* * *

➤ bin/lintian --info --tags patch-not-forwarded-upstream
debian/test-out/packages/checks/debian/patches/dep3/empty-forwarded-no-bug/
empty-forwarded-no-bug_1.0-1.dsc
N:
I: empty-forwarded-no-bug source: patch-not-forwarded-upstream
[debian/patches/silent.patch]
N:
N:   According to the DEP-3 headers, this patch has not been forwarded upstream.
N:
N:   Please forward the patch and try to have it included in
upstream's version control system. If the patch is not suitable for
N:   that, please mention not-needed in the Forwarded field of the patch header.
N:
N:   Please refer to social contract item 2, Coordination with
upstream developers (Section 3.1.4) in the Debian Developer's
N:   Reference, Changes to the upstream sources (Section 4.3) in the
Debian Policy Manual, and Bug#755153 for details.
N:
N:   Visibility: info
N:   Show-Always: no
N:   Check: debian/patches/dep3
N:   Renamed from: send-patch
N:



Bug#1001625: python3-script-but-no-python3-dep unoverridable

2022-01-24 Thread Felix Lechner
Hi,

On Mon, Jan 24, 2022 at 4:03 AM Marc Haber  wrote:
>
> Starting which lintian version are Deb822 overrides allowed?

The Deb822 override format has not been released.

It will be very soon, however. The implementation of file
pointers—which appear inside square brackets on terminals and as live
links on our website—has made the old override format cumbersome for
many users.

> Does all
> Debian infrastructure run appropriately recent versions of lintian so
> that a package can safely migrate to Deb822 overrides?

I cannot speak for users of Lintian, but they are generally provided
with timely backports.

Kind regards
Felix Lechner



Bug#996740: Consider having very-long-line-length-in-source-file ignore autotools files

2022-01-21 Thread Felix Lechner
Hi,

On Sun, Oct 17, 2021 at 4:40 PM Russ Allbery  wrote:
>
> That looks like exactly the right way to handle this.

The results for your screen are now live on our website. [1]

They are a showcase example for how exemptions should be granted in
Lintian. Thank you so much for suggesting them!

Kind regards,
Felix Lechner

[1] https://lintian.debian.org/screens/autotools/long-lines



Bug#1003456: Excessive memory use with large binaries

2022-01-21 Thread Felix Lechner
Hi,

So far, the most convenient way to reproduce this bug is the following
command. It exercises only a single, very simple check. [1]

bin/lintian -C linda --debug --no-override --no-tag-display-limit
../picolibc-arm-none-eabi_1.7.4-1_all.deb

Kind regards,
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Linda.pm#L32-39



Bug#1001677: Comments regarding pytest-order_1.0.0-1_amd64.changes

2022-01-16 Thread Felix Lechner
Hi Julian,

On Sun, Jan 16, 2022 at 7:01 AM Julian Gilbey  wrote:
>
> So perhaps another clause or two, something along the lines of the
> following, would be good?

Your suggestion was implemented in:


https://salsa.debian.org/lintian/lintian/-/commit/d228765ce4db8057fd0c9780b2312c0e26914434

Thank you for making Lintian better for everyone!

Kind regards
Felix Lechner



Bug#1003817: lintian: fpos for update-debian-copyright

2022-01-16 Thread Felix Lechner
Hi,

On Sun, Jan 16, 2022 at 12:30 AM Mattia Rizzolo  wrote:
>
> I guess it's taking the 2021 from the second paragraph?

The code assumes there is only one Debian paragraph [1] and issues the
tag for any with an outdated copyright. The current year (2022) in
just one of them should suffice to silence the tag altogether.

I cannot reproduce the behavior with hexchat_2.16.0-3.dsc (although
there are probably others) because it lacks the second paragraph. [2]
Are you uploading your new version to the archive? It would help me
fix the bug. Thanks!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Debian/Copyright/Dep5.pm#L644
[2] https://sources.debian.org/src/hexchat/2.16.0-3/debian/copyright/



Bug#1001677: Comments regarding pytest-order_1.0.0-1_amd64.changes

2022-01-16 Thread Felix Lechner
Hi,

On Sun, Jan 16, 2022 at 2:27 AM Julian Gilbey  wrote:
>
> *If* the consensus is that py3versions -r is wrong, then we should
> probably have a lintian check for it: py3versions -r (and variants
> such as -rv and -vr) without a corresponding X-Python3-Version field
> should give a lintian warning, and py3versions -s with an
> X-Python3-Version field should do so likewise.

For reference, here is Lintian's current code examining the use of
'py3versions' in tests. [1]

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Testsuite.pm#L289-309



Bug#1003751: In NEW queue

2022-01-15 Thread Felix Lechner
The sources were uploaded and are now in the NEW queue.



Bug#1003813: libghc-lzma-dev: static C library missing as a prerequisite

2022-01-15 Thread Felix Lechner
Package: libghc-lzma-dev
Severity: normal

Hi,

I am new to Debian's ecosystem for Haskell, so please forgive me if
this filing is perhaps not entirely justified.

When building my new package 'kickoff' [1] using sbuild in a fresh
'unstable' chroot, I received the build error below. It looks to me
like the linker could not find the static LZMA library.

I believe the library is available in the installable 'liblzma-dev'.
(Your package [2] only pulls in the shared version via liblzma5.) Are
consuming sources supposed to depend on the C library separately?

The full build log was attached to this message. Thank you for your guidance!

Kind regards
Felix Lechner

[1] https://bugs.debian.org/1003751
[2] https://packages.debian.org/sid/libghc-lzma-dev

* * *

/usr/bin/ld.gold: error: cannot find -llzma
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/lzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz/libHSlzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz.a(lzma_wrapper.o):function
hs_lzma_init_decoder: error: undefined reference to
'lzma_stream_decoder'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/lzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz/libHSlzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz.a(lzma_wrapper.o):function
hs_lzma_init_decoder: error: undefined reference to
'lzma_auto_decoder'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/lzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz/libHSlzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz.a(lzma_wrapper.o):function
hs_lzma_init_encoder: error: undefined reference to
'lzma_easy_encoder'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/lzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz/libHSlzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz.a(lzma_wrapper.o):function
hs_lzma_run: error: undefined reference to 'lzma_code'
/usr/lib/haskell-packages/ghc/lib/x86_64-linux-ghc-8.8.4/lzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz/libHSlzma-0.0.0.3-2n8nD73xk8SLYSVlgeU5jz.a(lzma_wrapper.o):function
hs_lzma_done: error: undefined reference to 'lzma_end'
collect2: error: ld returned 1 exit status
`x86_64-linux-gnu-gcc' failed in phase `Linker'. (Exit code: 1)
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:147: build-ghc-stamp] Error 1
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2


kickoff_0.1.0_amd64-2022-01-16T04:50:08Z.build.xz
Description: application/xz


Bug#1003751: ITP: kickoff -- Generalized job scheduler (with runners) for the Debian archive

2022-01-14 Thread Felix Lechner
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-lint-ma...@lists.debian.org

* Package name: kickoff
  Version : 0.1.0
  Upstream Author : Felix Lechner 
* URL : https://salsa.debian.org/lintian/kickoff
* License : GPL-3.0-or-later
  Programming Lang: Haskell2010
  Description : Generalized job scheduler (with runners) for the
Debian archive

This package provides a generalized job scheduler. It supports fully
configurable processing actions on local copies of the Debian archive.

The programs herein generate the contents of the Lintian website.

This software falls under Lintian's umbrella and will be updated,
managed and serviced by the Lintian maintainers.



Bug#1002614: no longer report source-is-missing for binary file in source

2022-01-12 Thread Felix Lechner
Hi,

On Sat, Dec 25, 2021 at 7:00 AM Shengjing Zhu  wrote:
>
> I got rejected by ftp-master

Is there a record of the rejection? Which of these excluded files [1]
did the Archive Team find in your sources? Thanks!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/zhsj/kata-containers/-/blob/debian/experimental/debian/copyright#L4-63



Bug#1003582: ITP: detagtive -- Lintian web application

2022-01-11 Thread Felix Lechner
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-lint-ma...@lists.debian.org

* Package name: detagtive
  Version : 0.1.0.0
  Upstream Author : Felix Lechner 
* URL : https://salsa.debian.org/lintian/detagtive
* License : AGPL-3.0-or-later
  Programming Lang: Haskell2010
  Description : Lintian web application

This package is for the Haskell rewrite of the Lintian website. The
code will be transferred gradually as the site is migrated.

Also ships an executable to generate the special file 'qa-list.txt',
on which several important Debian services rely (tracker.d.o among
them).

This software falls under Lintian's umbrella and will be updated,
managed and serviced by the Lintian maintainers.



Bug#1003456: Excessive memory use with large binaries

2022-01-10 Thread Felix Lechner
Hi,

On Mon, Jan 10, 2022 at 5:45 AM Ben Hutchings  wrote:
>
> lintian allocated about 23 GiB

Thanks for reporting this!

That is one of several mysterious results of what happened when I
simplified the code. It's possibly due to excessive regex usage,
although Perl usually catches that. Another possibility is an
accidental recursion in Lintian's copy of your package's file index.
Either way, I will shortly add helpful profiling information that you
will be able to examine on our website.

On the positive side, I broke Lintian's 23 original checks into 353
pieces (and counting). It makes issues much easier to monitor and
isolate.

Kind regards
Felix Lechner



Bug#1002936: lintian: False positive missing-pkg-php-tools-addon when using dh-sequence-phpcomposer

2022-01-09 Thread Felix Lechner
Hi Robin,

On Sat, Jan 1, 2022 at 7:39 AM Robin Gustafsson  wrote:
>
> Using it

Which package are you working on, please? It's probably one of the 56
sources that trigger the tag:

https://lintian.debian.org/tags/missing-pkg-php-tools-addon

We cannot investigate your report without that information. Thank you!

Kind regards
Felix Lechner



Bug#1003340: qa.debian.org: Please agree with salsa on the lintian version to use

2022-01-09 Thread Felix Lechner
Hi,

On Sun, Jan 9, 2022 at 8:51 AM Samuel Thibault  wrote:
>
> But what is "latest version"?

The latest version is the most recent commit on the 'master' branch in
our public repository. [1] We found it is the fastest way to bring bug
fixes to the community.

Bug fixes can often be verified on our website within days. [2] Our
use of the SemVer patch digit [3] is explained on each tag page. [4]
You can also have a look at this message. [5]

The name of the 'master' branch is subject to change. We already use
the more neutral 'history' in most of our other repos. [6][7][8]

Kind regards
Felix Lechner

[1] https://salsa.debian.org/lintian/lintian
[2] https://lintian.debian.org/
[3] https://semver.org/
[4] for example, https://lintian.debian.org/tags/bad-whatis-entry
[5] https://lists.debian.org/debian-lint-maint/2021/09/msg00148.html
[6] https://salsa.debian.org/lintian/detagtive
[7] https://salsa.debian.org/lintian/kickoff
[8] https://salsa.debian.org/lintian/emacs-lintian



Bug#1003340: qa.debian.org: Please agree with salsa on the lintian version to use

2022-01-09 Thread Felix Lechner
Hi,

On Sun, Jan 9, 2022 at 7:36 AM Samuel Thibault  wrote:
>
> we cannot
> write lintian overrides files that avoid red flags on both platforms.

Lintian's latest version will always be authoritative.

In addition, please note that the format for override files is changing. [1]

Please remember, however, that Lintian is not your boss. Credit for
that critical insight goes to D. Bremner—thank you!

On a side note, Salsa has more serious issues when running Lintian
jobs. [2][3][4]

Thank you for using Lintian!

Kind regards
Felix Lechner

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003272#10
[2] https://bugs.debian.org/973313
[3] https://salsa.debian.org/salsa/support/-/issues/277
[4] https://salsa.debian.org/lintian/lintian/-/merge_requests/367#note_281411



Bug#1003272: lintian: chokes on overrides with "(" but no ")"

2022-01-07 Thread Felix Lechner
Hi,

On Fri, Jan 7, 2022 at 10:18 AM Tobias Frost  wrote:
>
> FWIIW, escaping with a backslash, e.g "\(" *did* work for me earlier today...

Okay, thanks!

I just knew backslashes do not work for square brackets, which are
perhaps more common right now. There, the awkward notation [[] is
required until I implement the new override format.

Kind regards
Felix Lechner



Bug#1003272: lintian: chokes on overrides with "(" but no ")"

2022-01-07 Thread Felix Lechner
Hi,

On Fri, Jan 7, 2022 at 2:57 AM Tobias Frost  wrote:
>
> Unmatched ( in regex; marked by <-- HERE in m/( <-- HERE

That is a consequence of switching to Text::Glob for overrides. I
would suggest '[(]' and '[)]' as probable fixes (backslashes do not
work) but more changes are coming to override files.

We recently introduced 'pointed hints' which allow live links on our
website to sources.d.o and soon others. In terminal output, they are
shown as

tag annotation [file pointer]

but that format is not great for overrides.

We will likely allow globbing on the file pointer, regular expressions
on the annotation and require literal matches for the tag name. To
keep those fields separate, we may switch to a Deb822 format for
override files, but hope to provide automated tools for migration and
management similar to those we already use internally to interactively
recalibrate Lintian's test suite.

Kind regards
Felix Lechner



Bug#1003271: lintian: skip-systemd-native-flag-missing-pre-depends still relevant?

2022-01-07 Thread Felix Lechner
Hi,

On Fri, Jan 7, 2022 at 2:51 AM Tobias Frost  wrote:
>
> the description of the tag has a bug:

I just made these changes:

https://salsa.debian.org/lintian/lintian/-/commit/f5107b60f4c7bbb9762dd375e3513cf54b3bac0d

>From the commit message:

The tag combines two checks in one. First, it requires that a Pre-Depends on
was declared and, second, that the version is sufficient. The reporting party
pointed out that the version requirement is satisfied in oldstable, so the
version requirement was dropped from both the code and from the description.

The overall check that a Pre-Depends was declared, however, may still be
sensible to keep.

On the website 73 sources currently provoke the tag, but we cannot if the
declaration is missing or just does not satisfy the minimum version requirement.
Let's see how the tag performs after this change.

Thanks to Tobias Frost for bringing the matter to our attention!

Kind regards
Felix Lechner



Bug#1002461: Pending with DSA

2022-01-04 Thread Felix Lechner
Hi,

> it would be even better if lintian provided up-to-date data.

Tracker.d.o relies on a traditional batch file called qa-list.txt. [1]
In the past, I had to generate it via UDD [2] because the Lintian
database (on puny, non-DSA hardware) had too little memory to run the
self-JOIN.

Updating UDD became harder when Lintian started to update its database
dynamically, for example to illustrate bug fixes. Like tracker.d.o,
UDD uses a batch system for imports, while the Lintian website does
everything on demand. [3] It is not possible to feed partial updates
to UDD.

I finally found a benevolent donor for Lintian's database and can now
run the query, but lintian.d.o lacks the installation prerequisites.
Unfortunately, DSA has been too busy to work on it, and just told me
so last week. It might help if you could lean on them to please
process RT#8721.

At a minimum, we need ghc and cabal-install. Thanks!

Kind regards
Felix Lechner

[1] https://lintian.debian.org/static/qa-list.txt
[2] https://udd-mirror.debian.net/
[3] https://lintian.debian.org/query



Bug#1003074: libwolfssl30: wc_HashInit(h, WC_HASH_TYPE_SHA512) overflows

2022-01-03 Thread Felix Lechner
Hi Tim,

On Mon, Jan 3, 2022 at 9:09 AM Tim Rühsen  wrote:
>
> Valgrind reports a buffer overflow.

The good folks at wolfSSL cannot reproduce the error. Do you '#include
' before the others?

Either way, will you please also attach your configuration to this
report? Thanks!

Kind regards,
Felix Lechner



Bug#1002824: lintian/python3-gitlab: Please feel free to reopen

2021-12-29 Thread Felix Lechner
Hi Alex,

Please feel free to reopen this bug if your wishlist items for Lintian
need more work. Thanks!

Kind regards
Felix Lechner



Bug#1001655: Avoid hardcoding depends on specific lzip implementations

2021-12-28 Thread Felix Lechner
Hi Daniel,

On Tue, Dec 28, 2021 at 7:09 PM Daniel Baumann
 wrote:
>
> you can now safely depend on ...  "plzip | lzip-decompressor"

Great, thanks! Will that work for backports, too?

Kind regards
Felix Lechner



Bug#1002503: false reports skip-systemd-native-flag-missing-pre-depends

2021-12-23 Thread Felix Lechner
Control: reopen -1
Control: retitle -1 lintian: Clarify all tags about missing Pre-Depends

Hi Marc,

On Thu, Dec 23, 2021 at 3:57 AM Marc Haber
 wrote:
>
> No, a false bug report. Sorry.

Confusing tag descriptions are also bugs in Lintian! We strive to please all.

Note for later: This is about Depends vs Pre-Depends.

Kind regards
Felix Lechner



Bug#1002503: false reports skip-systemd-native-flag-missing-pre-depends

2021-12-23 Thread Felix Lechner
Hi Marc,

On Thu, Dec 23, 2021 at 3:57 AM Marc Haber
 wrote:
>
> Depends: [...] init-system-helpers (>= 1.54~)

The tag is asking for Pre-Depends though, isn't it? [1][2]

> ippl_1.4.14-12.2_amd64.deb

I do not see a declaration for Pre-Depends in your control file. [3]

Is Lintian too strict?

Kind regards
Felix Lechner

[1] https://lintian.debian.org/tags/skip-systemd-native-flag-missing-pre-depends
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Systemd/Native/Prerequisites.pm#L49
[3] https://tracker.debian.org/media/packages/i/ippl/control-1.4.14-12.2



Bug#1002466: emacs-lintian: Renamed the source package

2021-12-22 Thread Felix Lechner
Hi,

Pursuant to a suggestion from the Emacs maintainers (thank you!) the
source package was renamed to emacs-lintian and resubmitted to the FTP
Masters.

The path on Salsa also changed:

https://salsa.debian.org/lintian/emacs-lintian

Kind regards
Felix Lechner



Bug#1002466: ITP: elpa-lintian -- Examine Lintian packaging hints in Emacs

2021-12-22 Thread Felix Lechner
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-emac...@lists.debian.org

* Package name: elpa-lintian
  Version : 0.1
  Upstream Author : Felix Lechner 
* URL : https://salsa.debian.org/lintian/elpa-lintian
* License : GPL-3+
  Programming Lang: Lisp
  Description : Examine Lintian packaging hints in Emacs

This package provides a command to run Lintian in Emacs. The purpose
is to provide extra functionality when examining the resulting
packaging hints.

A preliminary version may be found in the Lintian source tree. [1]

Going forward, I hope to maintain the software jointly as a member of
the Lintian Maintainers Team.

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/integration/emacs/lintian.el



Bug#968758: Emacs integration for Lintian

2021-12-22 Thread Felix Lechner
Hi,

With that commit [1] Lintian now offers rudimentary Emacs integration. [2]

In the future, pointed hints may allow the user to travel directly to
the file indicated in the packaging hint.

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/commit/addd6064625a6996b76afa0bd81cdb02eacd8ce9
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/integration/emacs/lintian.el



Bug#1002296: dh-haskell: Version 0.5 is now in NEW

2021-12-21 Thread Felix Lechner
Control: tags -1 + pending

Hi,

Version 0.5 of dh-haskell was uploaded to the NEW queue. [1]

Kind regards
Felix Lechner

[1] https://ftp-master.debian.org/new/dh-haskell_0.5.html



Bug#1002296: ITP: dh-haskell -- Debhelper build system for cabal-based Haskell packages

2021-12-21 Thread Felix Lechner
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-hask...@lists.debian.org

* Package name: dh-haskell
  Version : 0.5
  Upstream Author : Felix Lechner 
* URL : https://salsa.debian.org/lechner/dh-haskell
* License : GPL-3+
  Programming Lang: Perl
  Description : Debhelper build system for cabal-based Haskell packages

Version 0.4 was dropped from unstable on 2018-11-04 at the author's
request in #912000. While the software seemed not useful then, the dh
sequencer is now the dominant build system. [1]

This version is a simple, but complete rewrite based on
/usr/share/cdbs/1/class/hlibrary.mk. It was tested with a Haskell
executable that is not in the archive, but not yet with any libraries
or documentation. Further adaptation may be required.

Going forward, I would like to maintain the software, potentially
jointly, as a prospective member of the Haskell Group!

[1] https://trends.debian.net/#build-systems



Bug#1001655: Avoid hardcoding depends on specific lzip implementations

2021-12-13 Thread Felix Lechner
Hi Daniel,

On Mon, Dec 13, 2021 at 2:00 PM Daniel Baumann
 wrote:
>
> all of them, except lzd, do implement --test.

Looking at your documentation [1] does that mean Lintian can only
offer the alternatives except lzd?

Or, is there another way to assess the actual nature or integrity of a
file named like *.lz? Thanks!

Kind regards
Felix Lechner

[1] https://sources.debian.org/src/lzip/1.22-4/debian/lzip.README.Debian/



Bug#1001625: python3-script-but-no-python3-dep unoverridable

2021-12-13 Thread Felix Lechner
Hi Marc,

On Mon, Dec 13, 2021 at 4:33 AM Marc Haber
 wrote:
>
> I wondering whether the missing leading backslash in the path is
> correct.

You probably meant a regular slash, and not a backslash. Lintian has
used such relative-looking path names since before it found me. The
only exception I know of is the hint annotation, which is usually
taken verbatim from your code. It can include leading slashes (for
conffiles, for example, which are absolute).

The path you asked about is part of a pointed hint. It includes file
information that will soon be a live link on our website. [1] Those
paths are taken straight from Lintian's in-memory copy of the file
index. [2]

[1] https://bugs.debian.org/743226
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Index.pm#L393-396

> debian/sudo-ldap.lintian-overrides:sudo-ldap: 
> python3-script-but-no-python3-dep /usr/bin/python3 
> [usr/share/apport/package-hooks/*]

Our Git version already moved past your 2.114.0 with respect to
override treatments. We now allow globbing patterns [3] using
Text::Glob. [4] Unfortunately, the square bracket I recently selected
for file pointers is cumbersome to escape. The backslash \[ does not
work, while [[] (from bash) and the question mark ? both work. You
could leave out the ending ] or use the even more awkward-looking []].
None of that is great for users.

Overrides are currently in flux. Maybe overrides should be in a more
capable format, such as Deb822. In your case, that would probably look
something like:

Tag: python3-script-but-no-python3-dep
Note: /usr/bin/python3
Pointer: usr/share/apport/package-hooks/*

Perhaps I should also add a tool for users to generate or modify
overrides interactively. I have used something similar for years in
Lintian's test suite to recalibrate tests for sweeping changes.

Kind regards
Felix Lechner

[3] 
https://salsa.debian.org/lintian/lintian/-/commit/139009d5a54225ebff4509ec37b979cb898c17fe
[4] https://metacpan.org/pod/Text::Glob



Bug#1001651: lintian: changelog-file-missing-explicit-entry: false positives with successive stable uploads

2021-12-13 Thread Felix Lechner
Control: forcemerge 941656 -1
Control: severity 941656 important

Hi,

On Mon, Dec 13, 2021 at 11:00 AM Cyril Brulebois  wrote:
>
> W: debian-installer source: changelog-file-missing-explicit-entry 
> 20210731+deb11u1 -> 20210731 (missing) -> 20210731+deb11u2

Your case from stable was already mentioned in the other bug. [1] Merging.

A better course of action might have been to retitle the bug to
describe the failure better. I did that now.

I also upgraded the priority to your requested level of 'important'.

On a side note, version parsing is one of the more complex subjects in
Debian. Thanks!

Kind regards
Felix Lechner

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941656#20



Bug#1001655: Avoid hardcoding depends on specific lzip implementations

2021-12-13 Thread Felix Lechner
Hi Daniel,

On Mon, Dec 13, 2021 at 11:36 AM Daniel Baumann
 wrote:
>
>if only decompression is used:
>'lzip | lzip-decompressor'

We only use the '--test' functionality. [1] Is that implemented by all
alternatives?

Also, do we still need to determine the proper name of the executable,
as introduced in this commit? [2] Thanks!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Files/Compressed/Lz.pm#L61
[2] 
https://salsa.debian.org/lintian/lintian/-/commit/bc64d63c4ecd293687524086b6966e30e9c48ae0



Bug#1001575: lintian: duplicate-globbing-patterns notice says "(lines $lines)"

2021-12-12 Thread Felix Lechner
Control: tags -1 + pending

Hi,

On Sun, Dec 12, 2021 at 5:09 AM Julian Gilbey  wrote:
>
> Presumably the $lines variable should have been expanded?

Thanks! We already caught it in an unreleased commit. [1]

Unfortunately, we cannot adopt the relevant Perl::Critic policy just
yet, due to unresolved issues elsewhere.

Thanks for helping to make Lintian better!

Kind regards
Felix Lechner

[1] 
https://salsa.debian.org/lintian/lintian/-/commit/87825cb0c24368a4b627b70b7b3c9feecca2157f



Bug#1001463: java-policy: Please retitle to "Java Policy for Debian"

2021-12-10 Thread Felix Lechner
Package: java-policy

Hi,

Lintian cites your manual as supporting documentation for several
tags. [1][2][3][4][5][6][7][8] Such references help users when
grasping the conditions that provoke Lintian's recommendations. In our
view, your policy [9] should be named "Java Policy for Debian."

Will you please retitle it? Thanks!

Kind regards
Felix Lechner

[1] https://lintian.debian.org/tags/bad-jar-name
[2] https://lintian.debian.org/tags/build-depends-on-an-obsolete-java-package
[3] https://lintian.debian.org/tags/jar-not-in-usr-share
[4] https://lintian.debian.org/tags/jar-contains-source
[5] https://lintian.debian.org/tags/javalib-but-no-public-jars
[6] https://lintian.debian.org/tags/missing-dep-on-jarwrapper
[7] https://lintian.debian.org/tags/executable-jar-without-main-class
[8] https://lintian.debian.org/tags/package-installs-java-bytecode
[9] https://www.debian.org/doc/packaging-manuals/java-policy/



Bug#1001458: lintian: tag prefer-uscan-symlink has bad name and may be wrong

2021-12-10 Thread Felix Lechner
Hi,

On Fri, Dec 10, 2021 at 6:28 AM Yadd  wrote:
>
> Multiple-Upstream-Tarballs package (from uscan(1) sorry ;-))

Thanks for the explanation! I'll return the favor: In Lintian, we call
them "sources with multiple orig components".

On a related note, we generally do not use "packages" to refer to
sources (our website is a notable exception). We usually eschew the
barebones moniker altogether. In Lintian, installable packages are
exactly that, and sources are sources.

As an aside, I have been accused of reinventing terminology, but it's
really helped Lintian to keep apart things that otherwise sound too
similar. In my defense, I developed a low tolerance for confusion when
trying to navigate, on a visit, Atlanta's 71 streets named
"Peachtree". [1] Just as Debian is recognized for its great packages,
peaches are a famous product of Georgia!

Kind regards
Felix Lechner

[1] https://en.wikipedia.org/wiki/Peachtree_Street#Nomenclature



Bug#1001458: lintian: tag prefer-uscan-symlink has bad name and may be wrong

2021-12-10 Thread Felix Lechner
Hi,

On Fri, Dec 10, 2021 at 5:51 AM Yadd  wrote:
>
> That's why I think this tag shoud be removed.

I think I concur—but what's a MUT, please?

Kind regards
Felix Lechner



Bug#1001399: lintian: adjust backports-upload-has-incorrect-version-number for ubuntu

2021-12-09 Thread Felix Lechner
Hi,

On Thu, Dec 9, 2021 at 8:37 AM Mattia Rizzolo  wrote:
>
> I believe we shouldn't concern
> ourselves too much with UNRELEASED (what's the current behaviour here
> anyway?)

For the majority of tags, the release is not considered but having
less concern for UNRELEASED would negatively affect the quality of
hints issued on Salsa. [1] I expect that to be the primary Lintian
platform for contributors in the future.

Kind regards
Felix Lechner

[1] sample, 
https://lechner.pages.debian.net/-/mdadm/-/jobs/2004554/artifacts/debian/output/lintian.html



Bug#1001399: lintian: adjust backports-upload-has-incorrect-version-number for ubuntu

2021-12-09 Thread Felix Lechner
Hi,

On Thu, Dec 9, 2021 at 7:24 AM Mattia Rizzolo  wrote:
>
> However, in Ubuntu we just started up again the process, and the new
> policy says to append ~bpo$UBU_VERSION.1, with $UBU_VERSION 20.04,
> 18.04, 20.10, etc.

Right now, Lintian's profiles just enable or disable tags. I am not
opposed to expanding their capabilities, but is it the right approach?

Should the version string for a Ubuntu package also be acceptable even
if Lintian ran on Debian?

Can Lintian tell the target OS without looking at the version string?
Maybe the changelog (except that would not work for UNRELEASED)?

Thanks!

Kind regards
Felix Lechner



Bug#1001247: vim-doc: Please publish Vim packaging policy on the Web

2021-12-06 Thread Felix Lechner
Package: vim-doc
Severity: wishlist

Hi,

Lintian provides references to the Vim packaging in tag descriptions.
[1] We determine the appropriate sections by scanning your HTML index
file. [2] Vim is somewhat special because your policy is not
published. (Doc-base isn't either.) All we can do, therefore, is
provide URI into a user's file system.

Unfortunately, your URL structure is significantly different between
the versions in stable and unstable. (For example, x73.html vs
x65.html; please see below for details.) The Lintian maintainers are
therefore uncertain which version to provide. The easiest way would be
for you to publish your packaging policy on the Web. Several other
teams do so. [3]

You may be eligible for the same assistance that we were offered from
the official New Maintainer's guide. [4][5] For Lintian, we ended up
publishing the manual ourselves, but we have a website. [6]

Alternatively, I could replace the Vim policy reference in the tag
shown above [1] with a more permanent link. I believe that no other
tags refer to your policy. Thank you!

Kind regards
Felix Lechner

[1] https://lintian.debian.org/tags/vim-addon-within-vim-runtime-path
[2] 
https://salsa.debian.org/lintian/lintian/-/blob/master/data/authority/vim-policy
[3] https://salsa.debian.org/lintian/lintian/-/tree/master/data/authority
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998701#15
[5] https://www.debian.org/doc/manuals/maint-guide/index.en.html
[6] https://lintian.debian.org/

* * *

If  is an underscore, that line specifies the title and URL
for the whole manual.

bullseye:

_::Debian Packaging Policy for
Vim::file:///usr/share/doc/vim/vim-policy.html/index.html
1::Vim Addon Packaging in a
Nutshell::file:///usr/share/doc/vim/vim-policy.html/index.html#nutshell
2::Vim Packaging::file:///usr/share/doc/vim/vim-policy.html/x73.html
3::Packaging of Vim Addons::file:///usr/share/doc/vim/vim-policy.html/x113.html
3.1::Addon 
Structure::file:///usr/share/doc/vim/vim-policy.html/x113.html#addon-structure
3.2::Addon 
Packages::file:///usr/share/doc/vim/vim-policy.html/x113.html#addon-packages
3.3::Registry 
Entries::file:///usr/share/doc/vim/vim-policy.html/x113.html#registry-entry
4::Tools::file:///usr/share/doc/vim/vim-policy.html/x221.html
A::Vim Registry Entry
Examples::file:///usr/share/doc/vim/vim-policy.html/a245.html

sid:

_::Debian Packaging Policy for
Vim::file:///usr/share/doc/vim/vim-policy.html/index.html
1::Vim Addon Packaging in a
Nutshell::file:///usr/share/doc/vim/vim-policy.html/index.html#nutshell
2::Vim Packaging::file:///usr/share/doc/vim/vim-policy.html/x65.html
3::Packaging of Vim Addons::file:///usr/share/doc/vim/vim-policy.html/x126.html
3.1::Addon 
Structure::file:///usr/share/doc/vim/vim-policy.html/x126.html#addon-structure
3.2::Addon 
Packages::file:///usr/share/doc/vim/vim-policy.html/x126.html#addon-packages
4::Tools::file:///usr/share/doc/vim/vim-policy.html/x166.html



Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements

2021-12-06 Thread Felix Lechner
Hi,

On Mon, Dec 6, 2021 at 12:44 PM gregor herrmann  wrote:
>
> It's already in NEW (and the other requested package as well).

Thank you for your prompt assistance!

Lintian provides backports to stable (and some users run it in even
more adventurous ways). Is it acceptable for the Lintian maintainers
to upload backports of the new packages, or would the Perl team rather
handle them via bug reports?

I would prefer if the Perl team handled backports as well, but it
would be an extra burden. Please just let me know one way or the
other. Thanks!

Kind regards
Felix Lechner



Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements

2021-12-06 Thread Felix Lechner
Hi,

On Mon, Dec 6, 2021 at 10:48 AM gregor herrmann  wrote:
>
> I have no good idea how to handle it right now.

Thank you for having a look!

For Lintian, the functionality of Sub::StrictDecl is probably enough.
I requested it separately (and you already assumed ownership). [1]
Thank you!

Kind regards,
Felix Lechner

[1] https://bugs.debian.org/1001175



Bug#998701: correct lintian documentation site

2021-12-06 Thread Felix Lechner
Hi,

On Sun, Nov 21, 2021 at 1:00 AM Osamu Aoki  wrote:
>
> Felix, what is your plan?

The Lintian manual is now published online. The URL is
https://lintian.debian.org/manua/index.html. [1]

We also provided a navigation entry on our website as well as a
redirect to the index page. Thank you!

Hope that helps!

Kind regards
Felix Lechner

[1] https://salsa.debian.org/lintian/detagtive/-/issues/13



Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements

2021-12-05 Thread Felix Lechner
Hi,

On Sun, Dec 5, 2021 at 12:08 PM gregor herrmann  wrote:
>
> (Just as a note, and that means I won't upload this tonight :))

Thank you for looking into it!

Kind regards,
Felix Lechner



Bug#1001173: Moo: Should use Depends for libclass-xsaccessor-perl (instead of Recoomends)

2021-12-05 Thread Felix Lechner
Hi,

On Sun, Dec 5, 2021 at 10:10 AM intrigeri  wrote:
>
> Would you mind asking upstream about this?

I corresponded with Moo's maintainer and others on IRC. Moo does not
have any hard prerequisites on XS modules so it can be used in places
without a compiler. The upstream decision is essentially for use cases
that do not apply here: fatpacking or building from source without a
compiler.

The consensus seemed to be that it was reasonable to have
Class::XSAccessor listed as a hard prerequisite when packaging for
Debian. Thanks!

Kind regards,
Felix Lechner



Bug#1001178: RFP: liblib-relative-perl -- In Perl scripts, Add paths relative to the current file to @INC

2021-12-05 Thread Felix Lechner
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-p...@lists.debian.org

* Package name: liblib-relative-perl
  Version : 1.000
  Upstream Author : Dan Book 
* URL : https://metacpan.org/pod/lib::relative
* License : Artistic-2.0
  Programming Lang: Perl
  Description : In Perl scripts, Add paths relative to the current
file to @INC

Adding a path to @INC to load modules from a local directory may seem
simple, but has a few common pitfalls to be aware of:

Directly adding a relative path to @INC means that any later code that
changes the current working directory will change where modules are
loaded from. This applies to the . path that used to be in @INC by
default until perl 5.26.0, or a relative path added in code like use
lib 'path/to/lib', and may be a vulnerability if such a location is
not supposed to be writable. Additionally, the commonly used FindBin
module relies on interpreter state and the path to the original script
invoked by the perl interpreter, sometimes requiring workarounds in
uncommon cases like generated or embedded code.

This module proposes a more straightforward method: take a path
relative to the current file, absolutize it, and add it to @INC.

The more straightforward name librelative-perl was already taken. [1]
Perhaps the name proposed here is better for consistency, even though
it looks awkward.

Lintian presently uses a series of tedious work-arounds to get the
same functionality.
[2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17]
Thanks!

Kind regards,
Felix Lechner

[1] https://tracker.debian.org/pkg/librelative-perl
[2] https://salsa.debian.org/lintian/lintian/-/blob/master/bin/lintian#L30-38
[3] 
https://salsa.debian.org/lintian/lintian/-/blob/master/bin/lintian-annotate-hints#L30-38
[4] 
https://salsa.debian.org/lintian/lintian/-/blob/master/bin/lintian-explain-tags#L30-38
[5] 
https://salsa.debian.org/lintian/lintian/-/blob/master/bin/spellintian#L28-37
[6] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/generate-tag-summary#L9-18
[7] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintadjust#L31-40
[8] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintdiff#L31-40
[9] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintextract#L31-39
[10] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/hintsort#L31-40
[11] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/latest-policy-version#L31-40
[12] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/refresh-data#L27-35
[13] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/refresh-locale-codes#L26-35
[14] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/refresh-manual-refs#L32-41
[15] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/runtests#L36-44
[16] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/tag-stats#L17-26
[17] 
https://salsa.debian.org/lintian/lintian/-/blob/master/private/generate-profiles#L10-18



Bug#1001176: RFP: perlimports -- Automate maintenance of Perl import statements

2021-12-05 Thread Felix Lechner
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-p...@lists.debian.org

* Package name: perlimports
  Version : 0.27
  Upstream Author : Olaf Alders 
* URL : https://metacpan.org/pod/App::perlimports
* License : Artistic
  Programming Lang: Perl
  Description : Automate maintenance of Perl import statements

This distribution provides the perlimports command line interface
(CLI), which automates the cleanup and maintenance of Perl use and
require statements. Loosely inspired by goimports, this tool aims to
be part of your linting and tidying workflow, in much the same way you
might use perltidy or perlcritic.

For a detailed discussion of the problems this tool attempts to solve,
see this "Conference in the Cloud" talk from June 2021: Where did that
Symbol Come From? [1]

Lintian would like to use the functionality to protect against missing
imports in rarely used code paths during parallel execution. [2]
Thanks!

Kind regards,
Felix Lechner

[1] https://www.youtube.com/watch?v=fKqxdTbGxYY
[2] https://lists.debian.org/debian-perl/2021/11/msg00011.html



Bug#1001175: RFP: libsub-strictdecl-perl -- Detect undeclared subroutines in Perl compilation

2021-12-05 Thread Felix Lechner
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-p...@lists.debian.org

* Package name: libsub-strictdecl-perl
  Version : 0.005
  Upstream Author : Andrew Main (Zefram) 
* URL : https://metacpan.org/pod/Sub::StrictDecl
* License : Artistic
  Programming Lang: Perl
  Description : Detect undeclared subroutines in Perl compilation

This module provides optional checking of subroutine existence at
compile time. This checking detects mistyped subroutine names and
subroutines that the programmer forgot to import. Traditionally Perl
does not detect these errors until runtime, so it is easy for errors
to lurk in rarely-executed or untested code.

Lintian would like to use the functionality to protect against missing
imports in rarely used code paths during parallel execution. [1]
Thanks!

Kind regards,
Felix Lechner

[1] https://lists.debian.org/debian-perl/2021/11/msg00011.html



Bug#1001173: Moo: Should use Depends for libclass-xsaccessor-perl (instead of Recoomends)

2021-12-05 Thread Felix Lechner
Package: libmoo-perl

Hi,

Moo performs faster when Class::XSAccessor is available [1] but
libmoo-perl only Recommends it. More important, Moo's behavior changes
when Class::XSAccessor is installed. [1]  For consistency as well as
performance, Moo should probably Depend on libclass-xsaccessor-perl.

While a new, hard prerequisite may cause some programs using Moo to
fail unexpectedly, they would at least do so consistently. It would
eliminate a transient class of bugs that depends on whether
Class::XSAccessor is present on a reporter's system—something that can
be hard to pin down when the installable is only recommended.

Lintian was affected in several ways. [2][3][4][5][6]

Sorry to report the suggestion with a two-year delay. Thank you!

Kind regards
Felix Lechner

[1] https://metacpan.org/pod/Moo#MOO-AND-CLASS::XSACCESSOR
[2] 
https://salsa.debian.org/lintian/lintian/commit/b951f0d4d83fa76286d1f4bd5836cf256038f31c
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943724#30
[4] 
https://salsa.debian.org/lintian/lintian/commit/f4c5659353198014d56810bec72225dda1dd21c8
[5] 
https://salsa.debian.org/lintian/lintian/commit/29a4d4dc6967f959f7c167a8b09e35c3610a3812
[6] 
https://salsa.debian.org/lintian/lintian/commit/15ae1403b8f455d4672990492cdb7a14929e40dc



Bug#1001164: HTML::TokeParser::Simple: Should perhaps depend on libwww-perl?

2021-12-05 Thread Felix Lechner
Package: libhtml-tokeparser-simple-perl

Hi,

The documentation indicates that the convenience constructor for a
'url' relies on LWP::Simple [1] but the installable package does not
declare libwww-perl as a prerequisite. [2] Should it?

The prerequisite HTML::Parser does not declare libwww-perl in
'Depends' either, although it 'Enhances' it. [3]

The Lintian maintainers use the described functionality to update data
files prior to release [4] but the feature is not tested in
autopkgtest. For now, we simply declared libwww-perl as a prerequisite
for Lintian. Thanks!

Kind regards
Felix Lechner

[1] https://metacpan.org/pod/HTML::TokeParser::Simple#new($source_type,-$source)
[2] https://packages.debian.org/unstable/libhtml-tokeparser-simple-perl
[3] https://packages.debian.org/sid/libhtml-parser-perl
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885438#20



Bug#1000977: lintian: bogus elf-error in debug symbols

2021-12-01 Thread Felix Lechner
Hi,

On Wed, Dec 1, 2021 at 6:03 PM Andreas Beckmann  wrote:
>
> That seems to happen with any debug symbols package ...

Do you have an opinion on the related #1000449 in binutils, please? Thanks!

I set 'affects: lintian' on that bug, but am not sure why it does not
show up locally.

Kind regards
Felix Lechner



Bug#1000631: misreports mismatched-override update-debian-copyright

2021-11-26 Thread Felix Lechner
Hi Marc,

On Thu, Nov 25, 2021 at 10:57 PM Marc Haber
 wrote:
>
> - How am I supposed to override a warning for two lines of copyright
>   with differnet years?

First off, I think this tag is malfunctioning. It should pick the most
recent copyright year of any file in ./debian (and not operate on any
'Files' stanza or on individual files). I believe that is the solution
to your other Bug#1000629.

> in a yet unpublished branch of the aide package
> (https://salsa.debian.org/debian/aide),

Would you please attach your unpublished d/copyright and d/changelog
files to this bug? I'll make them part of our test suite and resolve
the issue there. Thanks!

Kind regards
Felix Lechner



  1   2   3   4   5   6   7   8   9   10   >