Hi Felix,
> The index files seem to be inspired by the 't' option in tar. My sense
> is that we need more encoding rather than less to preserve the meaning
> of whitespace, and especially newlines, in those files.
Sure thing. I guess unless we moved these to a "NUL"-terminated format
but that's
Russ Allbery wrote:;
> >> The name of the files and directories installed by binary packages
> >> outside the system PATH must be encoded in UTF-8 and should be
> >> restricted to ASCII when it is possible to do so.
I ACK all the other comments here, just to add that whilst I would
On Mon, Jul 8, 2019 at 2:35 PM Russ Allbery wrote:
>
> I see that what you're
> trying to do is get the data deep enough into Lintian so that you can
> issue appropriate tags, and the problem is with the data representation in
> advance of tag processing, for which this isn't super-relevant.
The
Felix Lechner writes:
> On Mon, Jul 8, 2019 at 12:50 PM Russ Allbery wrote:
>> The name of the files and directories installed by binary packages
>> outside the system PATH must be encoded in UTF-8 and should be
>> restricted to ASCII when it is possible to do so.
> And that reads
Hi Russ,
On Mon, Jul 8, 2019 at 12:50 PM Russ Allbery wrote:
>
> Policy 10.10:
Thank you for the pointer to policy.
> The name of the files installed by binary packages in the system PATH
> (namely /bin, /sbin, /usr/bin, /usr/sbin and /usr/games) must be
> encoded in ASCII.
That
Hi Chris,
On Mon, Jul 8, 2019 at 12:42 PM Chris Lamb wrote:
>
> Do we need any of these techniques? Can we decree that the index files
> are escaped or unescaped (I'd be +1 on the latter, mind)
The index files seem to be inspired by the 't' option in tar. My sense
is that we need more encoding
Felix Lechner writes:
> Since filenames are arbitrary byte sequences that serve as valid
> identifiers in the file system, I am not sure it makes sense to impose
> UTF-8 validation in Lintian.
Policy 10.10:
The name of the files installed by binary packages in the system PATH
(namely
Hi Felix,
> After a cursory review of filename handling in Lintian's index files I
> can think of three possible solutions:
>
> 1. Use String::Escape in both directions to make sure the
> transformation is reversible. (It currently isn't.)
> 2. Use Base64 to encode file names in the index.
> 3.
On Sun, Jul 7, 2019 at 7:33 AM Chris Lamb wrote:
>
After a cursory review of filename handling in Lintian's index files I
can think of three possible solutions:
1. Use String::Escape in both directions to make sure the
transformation is reversible. (It currently isn't.)
2. Use Base64 to encode
Hi Felix,
[…]
> > … but this is clearly hacking around the problem and is likely
> > incomplete. Storing the newline literally in the internal structure
> > breaks other things that I can't immediately see/fix.
>
> I agree. I rewrote the collections using IO::Async (coming once buster
> is out)
Hi Chris,
On Sat, Jul 6, 2019 at 7:21 PM Chris Lamb wrote:
>
> The following "fixes" it:
>
> diff --git a/collection/md5sums b/collection/md5sums
> index 970eb0656..e8006ab10 100755
> --- a/collection/md5sums
> +++ b/collection/md5sums
> @@ -53,7 +53,8 @@ sub collect {
>
> foreach my $file
Chris Lamb wrote:
> However, I can reproduce with your previously attached .deb:
>
> $ lintian ~/Downloads/newline_1_all.deb 2>&1 | head -n2
> md5sum: 'usr/share/newline/\n/etc/issue': No such file or directory
> command failed with error code 123 at
>
Hi Jakub,
> Newlines in filenames make Lintian very unhappy:
[..]
Curiously, I can't seem to reproduce this when rebuilding the .deb
from your Git repository and dpkg 1.19.7:
$ dpkg-buildpackage --version | head -n1
Debian dpkg-buildpackage version 1.19.7.
$ dpkg-buildpackage -uc
Package: lintian
Version: 2.15.0
Severity: minor
Newlines in filenames make Lintian very unhappy:
$ lintian newline_1_all.deb
md5sum: 'usr/share/newline/\n/etc/issue': No such file or directory
command failed with error code 123 at /usr/share/perl5/Lintian/Command.pm
line 344.
14 matches
Mail list logo
