Bug#1068024: revert to version that does not contain changes by bad actor

[Ivan Shmakov]

> On 2024-03-30, Guillem Jover wrote:
> On Sat, 2024-03-30 at 00:48:34 +, Stephan Verbücheln wrote:

 >> Subject: Re: Bug#1068024: Or remove xz altogether?

 >> Maybe the people who criticized xz back in the day for being an amateur
 >> project implementing a defective file format were right all along?

 >> https://www.nongnu.org/lzip/xz_inadequate.html

 > *Sigh*, the current situation is bad enough, and has nothing to do
 > with the xz format or design, or the FUD and propaganda from that
 > link.  Please drop it…

While I wouldn’t have brought it up myself, nor the arguably
provocative Subject: change (reverted), as it’s indeed only
tangentially related to the issue at hand (which apparently
have resulted from the absense of good faith developers
volunteering to maintain this project – and in a word of
defense, the design quality of a software project /does/
influence both the amount of maintenance work and, other
things being equal, the desire to get involved), the comment
above got me curious: which parts of the document linked are
‘FUD and propaganda’?  Because I’ve just glanced it over and
I don’t find any obvious examples.

Granted, I’m not an expert in the field of compression and
coding, per se, and can’t readily speak on the validity of
most of the arguments given there, those at least appear
plausible.  Some arguments I find obvious, such as, e. g.:

 ADD> A well-known property of CRCs is their ability to detect burst
 ADD> errors up to the size of the CRC itself.  Using a CRC larger
 ADD> than the dataword is an error because a CRC just as large as
 ADD> the dataword equally detects all errors while it produces
 ADD> a lower number of false positives.

If there’s a reasonable rebuttal to the points raised in that
document, I believe that a pointer to it would be appropriate
for this discussion.  Other than that, I’m not going to go on
this tangent any further here.  I’ll be monitoring a handful
of Internet fora for that, though (news:alt.os.linux.debian,
news:comp.misc, irc://irc.efnet.org/%23coders, etc.)

-- 
FSF associate member #7257  np. Moonsong — Shane Jackman

Bug#1056147: midge possibly contains non-DFSG-free examples

[Ivan Shmakov]

Control: tag -1 patch

I have now uploaded a possible repackaged .orig.tar.bz2:

http://users.am-1.org/~ivan/src/sfn.2xNKGoveuNoRGASEQosuADUES3vYQfQmWVeMuitdtLI.tar.bz2

It was produced with the following shell command (where 39
blocks starting with 180 cover the entirety of midge-0.2.41
/examples/covers/ directory in the Tar file.)

$ (zcat | (dd count=180 ; dd count=39 > /dev/null ; dd) | bzip2 -4c) \
  < midge_0.2.41.orig.tar.gz > midge_0.2.41+dfsg1.orig.tar.bz2 

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1056146: xsok possibly contains non-DFSG-free data files

[Ivan Shmakov]

Source: xsok
Version: 1.02-19
Severity: serious
Justification: possible DFSG violation

[Please do not Cc: me, as I’m “on the list,” so to say, and
I prefer to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem
to be a way to make it point to the report being filed.]

The xsok debian/copyright file seems to suggest that xsok
was created solely by Michael Bischoff:

$ tar --xz -xO -- debian/copyright < xsok_1.02-19.debian.tar.xz 
This is Debian GNU/Linux's prepackaged version of xsok.
xsok was written by Michael Bischoff .

The upstream source was downloaded from
ftp://ftp.io.com/pub/mirror/FreeBSD/ports/distfiles/xsok-1.02-src.tar.gz

The current Debian maintainer is Peter Samuelson .
Much of the packaging work was done by previous Debian maintainers
Sven Rudolph and Joel Rosdahl.

Copyright (c) 1994 by Michael Bischoff (m...@mo.math.nat.tu-bs.de)

[GNU GPL 2+ notice follows.]

There’re two issues with this.  First, xsok includes
doc/cyberbox.doc, authored by Doug Beeferman (I presume
lib/Cyberbox/ files are also derivatives rather than
original xsok work.)  The .doc file (quoted below) appears
to allow verbatim redistribution of the respective game,
but there’s no indication that ‘modifications and derived
works’ are allowed (as DFSG requires) as well:

S O R T A F R E E W A R E   N O T I C E

This game can be distributed freely and played free of charge.  If you like
it, however, I wouldn't mind a small donation for the effort I put into
writing the program and (ughh!) in making the levels.  I say "ughh!" because
making the levels was by far the more time-consuming of the two projects.

Neither is there any such indication on http://dougb.com/ .
(I intend to contact the author of Cyberbox shortly to comment
on this issue and (or) possibly re-release at least the
portions of xsok derived from the original game in DFSG-
compliant fashion.)

Worse still, the ‘screens’ (= maps, levels) included in
lib/Sokoban/ appear to mostly come from the original,
proprietary version(s) of Soko-Ban.  Consider, e. g.:

http://web.archive.org/web/2023/https://www.mobygames.com/game/1715/soko-ban/

http://web.archive.org/web/20230407165659im_/https://cdn.mobygames.com/8e54fc3c-bee0-11ed-9c42-02420a000140.webp
http://web.archive.org/web/20230407165658im_/https://cdn.mobygames.com/0b7522d4-c204-11ed-ab6b-02420a000194.webp

The first Soko-Ban screen, identical to lib/Sokoban/screen.01 .

http://web.archive.org/web/20230407165658im_/https://cdn.mobygames.com/058c7f98-ab6b-11ed-aaf5-02420a00019c.webp

The second Soko-Ban screen, identical to lib/Sokoban/screen.02 .

Moreover, taking a look at an earlier curses-based implementation
of the game from [1], which (according to its README.v2, as
quoted below) borrows screens from ‘the PC-version’, we find
out that likely /all/ levels from 1 to 50 inclusive are taken
from other software, while several other levels (86‒88) are
derived from the same.

I’m not aware of any evidence to suggest that the original
Soko-Ban might be out of copyright or ever released as free
software, from whence I conclude it’s likely proprietary,
including the level designs.

The first thing I have to say is that I don't have the sources for SOKOBAN
under MS-DOS. I believe that this program is copyrighted. I took only the
idea and the screens of the PC-version.

[1] http://ibiblio.org/pub/linux/games/strategy/sokoban-src.tar.gz

bash$ diff -dbuF^\; -- \
  <((tar -zxOv --wildcards -- \*/screen.\?   < sokoban-src.tar.gz ; \
 tar -zxOv --wildcards -- \*/screen.\?\? < sokoban-src.tar.gz) \
2>&1 | sed -e "s,^sokoban.*\\.,;LEVEL ,;") \
  share/games/xsok/Sokoban.def | head -n23 
--- /dev/fd/63
+++ share/games/xsok/Sokoban.def2019-01-05 12:10:54 +
@@ -1,3 +1,14 @@
+;WALLS
+12 f f   ff  0   standard floor
+.   13 f f   ff  4   target field
+#0 0 00  0   walls
+
+;OBJECTS
+@0   f   0101   2011 0 player
+$1   f   0100 02  1000 heavy box
+
+;MAXLEVEL 88
+;ATOP *$.
 ;LEVEL 1
 #
 #   #
@@ -759,3 +770,521 @@ ;LEVEL 50
   #  ###   ## #
   #  #  ###
     ##
+;LEVEL 51
+#

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1056147: midge possibly contains non-DFSG-free examples

[Ivan Shmakov]

Source: midge
Version: 0.2.41-4
Severity: serious
Justification: possible DFSG violation

[Please do not Cc: me, as I’m “on the list,” so to say, and
I prefer to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem
to be a way to make it point to the report being filed.]

The source currently contains a number of covers/*.mg files
that are, so far as I can tell, derivatives of songs for
which there’re no indication of being out of copyright or
ever released under a DFSG-compliant license.  In particular,
a cursory look at Wikipedia articles (below) do not seem to
mention anything related to possible free culture status of
the songs transcribed in paranoid.mg & wish_you_were_here.mg.

http://en.wikipedia.org/wiki/Paranoid_(Black_Sabbath_album)
http://en.wikipedia.org/wiki/Wish_You_Were_Here_(Pink_Floyd_song)

I believe the source needs to be repackaged so to exclude
the examples/covers/ directory entirely.

-- 
FSF associate member #7257  np. The Last Refugee — Roger Waters

Bug#1030682: new version available

[Ivan Shmakov]

Package: edbrowse
Version: 3.7.7-5
Severity: wishlist

[Please do not Cc: me, as I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem
to be a way to make it point to the report being filed.]

The latest version of Edbrowse currently tagged in the upstream
Git repository is apparently v3.8.6.  Could the Debian package
please be updated?

Are there other issues aside of the lack of a Debian QuickJS
package?  It seems to be rather straightforward to build, at
least on a GNU/Linux system, and given it’s in pkgsrc [1] as
well, I’d venture to guess it’s fairly portable in general.

[1] http://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/lang/quickjs/

(I suppose I can do the initial packaging, but not sure I’d
be willing to maintain it.  And even if I would, I’d need a
sponsor still.)

TYC.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1030681: man1/Xvnc symlink should be man1/Xvnc.1.gz

[Ivan Shmakov]

Package: tightvncserver
Version: 1:1.3.10-6
Severity: minor
Tags: patch

[Please do not Cc: me, as I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem
to be a way to make it point to the report being filed.]

Running the following command on a recent testing install
reveals a misnamed man1/Xvnc symlink:

$ find /usr/share/man -xdev -not -type d \
  -regextype egrep -not -regex ".*/man([1-8])/[^/]*\\.\\1[a-z]*\\.gz" -ls 
   759686  0 lrwxrwxrwx   1 root root   27 Oct 15  2021
 /usr/share/man/man1/Xvnc -> /etc/alternatives/Xvnc.1.gz
$ 

This is apparently due to how update-alternatives(1) is
invoked from .postinst:

16-update-alternatives --install \
17- $BIN/XvncXvnc$BIN/Xtightvnc 70 \
18- --slave \
19: $MAN/XvncXvnc.1.gz   $MAN/Xtightvnc.1.gz

Compare with the invocation for the vncpasswd manual page:

20-update-alternatives --install \
21-$BIN/vncpasswd  vncpasswd$BIN/tightvncpasswd 70 \
22---slave \
23-$MAN/vncpasswd.1.gz vncpasswd.1.gz   $MAN/tightvncpasswd.1.gz

AIUI, at least the former line in debian/tightvncserver.postinst
needs to be updated to use $MAN/Xvnc.1.gz in place of $MAN/Xvnc.

I don’t seem to see in update-alternatives(1) whether it will
automatically remove the older symlink upon the updated
--install call above.  If not, I presume the symlink will need
to be removed in .postinst explicitly:

## This was a misnamed symlink created by older versions of the package
rm -f -- "$MAN"/Xvnc

Also while we’re at it, I’d like to suggest for all the variable
substitutions in the code to be quoted like "$MAN" above.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1009698: marked as done (util-linux: more is less like more and more like less now :-))

[Ivan Shmakov]

>>>>> On 2023-01-07 12:37:03 +0100, Chris Hofstaedtler wrote:
>>>>> Ivan Shmakov  [230107 10:39]:

[…]

 >> My understanding is that the Debian BTS exists for the benefit
 >> of Debian users at large, not just the developers and maintainers;
 >> and in particular serves to inform the users of the issues they
 >> can run into upon upgrade.  (And if that’s somehow not the case,
 >> I’d kindly suggest that an alternative BTS is created for that
 >> purpose.)

 > This is not my understanding of the Debian BTS.  Indeed, if the bug
 > tracker produces a long list of "bugs" that are unactionable to me,
 > then it is not serving any useful purpose to me.

 > The end effect is one that can be seen for most high-usage packages:
 > actually relevant bugs are forgotten by the maintainers, put into
 > the same bucket as all the other, not-so-relevant entries
 > (not-really-"bugs").

The web interface lists wontfix bugs separately to other reports;
see, e. g., http://bugs.debian.org/src:tightvnc .  If you have
suggestions on how that list can be improved, I’d be willing to
look into the code (sometime within the next few months) and
propose a patch.  (I’m not familiar with any other Debian BTS
UIs, so won’t be able to help with those, though.)

 > I want to stress that this report is not a "bug" at all: just
 > new, different behaviour.

The change that Debian users have found problematic.

[…]

 > In this case, I specially love that for three quarters of a year
 > nothing has happened - after my suggestion of talking to upstream,
 > just silence.

 > Once I close the report, people show up with useful info and
 > also with opinions on how I should run the BTS for a package I
 > maintain.

I don’t have vested interest in how more(1) behaves as I don’t
use it myself.  (Though I still help other users with it, as well
as with a bunch of other Debian tools, from time to time.)

That said, I’m still following the util-linux Debian BTS reports
(somewhat loosely, admittedly), as, quite obviously, I /do/ rely
on the package rather heavily.

In this case, what provoked my response is specifically how
Debian BTS is used, which is something I’m also invested in.

We’re all volunteers here (and this also means that we can’t run
the BTS like a corporation would IMO), so I can’t in any way
‘force’ my understanding on anyone, but I’d still think explaining
my point from time to time would be of some value to the project.

There wouldn’t be much improvement should we all keep our
suggestions to ourselves, no?

[…]

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1009698: marked as done (util-linux: more is less like more and more like less now :-))

[Ivan Shmakov]

> Chris Hofstaedtler  wrote:

 > Subject: no additional feedback

 > Closing for lack of anything actionable.

JFTR, the workaround for this issue is to put -e either to the
command line, or to the MORE environment variable’s value.
It seems like in Bullseye, more(1) ignores unrecognized options,
so that should work for ~/.profile (or any other file used to
initialize user’s environment) shared across Debian releases.

I believe that the correct course of action is not to close the
report, as the problem still exists, is still reproducible, and
still affects, or can affect, Debian users; but rather to downgrade
to wishlist and tag as wontfix.

At the very least, that would help avoid duplicate reports of this
same issue.  (As to actionability, I understand the unwillingness
to deviate from upstream, but I’d argue that such a deviation /is/
nevertheless an ‘action’ that /can/ be performed by a maintainer.)

My understanding is that the Debian BTS exists for the benefit
of Debian users at large, not just the developers and maintainers;
and in particular serves to inform the users of the issues they
can run into upon upgrade.  (And if that’s somehow not the case,
I’d kindly suggest that an alternative BTS is created for that
purpose.)

TYC.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1025769: HTTP::Server::Simple vs. support for Unix domain sockets

[Ivan Shmakov]

>>>>> On 2022-12-09 02:11:07 +0100, gregor herrmann wrote:
>>>>> On Thu, 08 Dec 2022 20:07:38 +, Ivan Shmakov wrote:

 >> Attempting to implement Unix domain socket support by subclassing
 >> HTTP::Server::Simple uncovered several issues with the latter,
 >> which I’m going to describe in this report.  (Feel free to clone
 >> it and address them separately as you see fit.)

 > Thanks for your bug report.

 > I’m afraid to say that it mostly is not actionable from the
 > Debian packaging side.  What you propose, in my understanding,
 > are massive changes to the code, and that’s not what we are
 > going to do on our own in Debian, but something which needs
 > to be discussed with upstream and needs to happen there.

Not all of the changes I propose are what I’d call ‘massive.’
To summarize:

(peer_identify): New method, split off
(_process_request): this one.  Fixed: only call sockaddr_in on the
remote address if its family is AF_INET (was: whenever the family
is not AF_INET6.)

(listener_handle): New method, allowing for per-instance listener
sockets (was: using a single HTTPDaemon filehandle.)

(restart): Fixed: supply $^X as an indirect object to exec if $0
is not executable (was: using $0 unconditionally.)

(setup): Fixed: use (same as above) for peeraddr example value (was:
suggesting that peername can be a hostname while peeraddr cannot.)
Mention explicitly in the prose that both peername and peeraddr are
currently the same string value representing the remote IPv6 or IPv4
address, and that the code never attempts (potentially time-consuming)
reverse DNS calls.

Of the above, the first change is the most important for my
use case, and even if implemented only partially:

(_process_request): Fixed: only call sockaddr_in on the remote
address if its family is AF_INET (was: whenever the family
is not AF_INET6.)

it would still be helpful.

The second change is the most invasive.  And the rest seem
straightforward bugfixes, with the exec one being one-liner.

 > I can forward your ideas upstream

I’d appreciate that.

 > but it might be easier if you do it yourself as this will
 > potentially require discussion:
 > https://github.com/bestpractical/http-server-simple

I have no Github account (and I’d rather keep it that way.)

I have a CPAN account, though, so I can report the issues
to the CPAN RT instance [1], if the upstream monitor that.

[1] http://rt.cpan.org/Public/Dist/Display.html?Name=HTTP-Server-Simple

 >> So far as I can tell, it’s perfectly possible to subclass and
 >> use HTTP::Server::Simple without libcgi-pm-perl, except perhaps
 >> with Net::Server (I’m not familiar with the latter and won’t
 >> claim understanding of what the run method does in the case
 >> net_server is supplied.)

 >> The Recommends: relation seems like a better fit in this case:

 > That’s something relevant for packaging; but I’m not so sure about
 > your conclusion.  After looking around a bit I think I can say
 > that lib/HTTP/Server/Simple/CGI.pm needs CGI.pm; libcgi-pm-perl
 > needs to be in Build-Depends-Indep, otherwise the tests fails
 > (which was not your point); moving libcgi-pm-perl from Depends to
 > Recommends does not break autopkgtests so it would be ok at first
 > sight, the question is if we want to ensure an always working
 > HTTP::Server::Simple::CGI.  In the end I guess a Recommends would
 > be arguable but it’s not that clear-cut IMO …

IME it rarely is.

The caveat here is that all the packages that depend on
libhttp-server-simple-perl /and/ use HTTP::Server::Simple::CGI
would need to be updated to depend on libcgi-pm-perl as well.

Another alternative is to put HTTP::Server::Simple::CGI into
its own binary package, with the dependencies declared as
follows:

Package: libhttp-server-simple-perl
Depends: perl:any
Recommends: libhttp-server-simple-cgi-perl

Package: libhttp-server-simple-cgi-perl
Depends: libcgi-pm-perl, libhttp-server-simple-perl

It doesn’t avoid the need to check and possibly update all
of the depending packages, though.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1025769: HTTP::Server::Simple vs. support for Unix domain sockets

[Ivan Shmakov]

Package: libhttp-server-simple-perl
Version: 0.52-2
Severity: minor

[Please do not Cc: me, as I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem
to be a way to make it point to the report being filed.]

In true multiuser setups, it’s much easier to control access
to Unix domain sockets than to INET6 and INET ones: for the
first, chmod(1) and chacl(1) can be used, while the second
is likely to require configuring nftables or iptables as root.

Attempting to implement Unix domain socket support by
subclassing HTTP::Server::Simple uncovered several issues
with the latter, which I’m going to describe in this report.
(Feel free to clone it and address them separately as you
see fit.)


As an aside, note that both Apache mod_proxy (as of 2.4.7)
and Lighttpd mod_proxy provide support for passing HTTP
traffic to a Unix domain socket; consider, e. g.:

## Lighttpd
$HTTP["url"] =~ "^/(example)(/|$)" {
  proxy.server  = ("" => (("host" => "/where/is/%1.socket")))
}

## From http://httpd.apache.org/docs/2.4/mod/mod_proxy.html

  # Unix sockets require 2.4.7 or later
  SetHandler  "proxy:unix:/path/to/app.sock|fcgi://localhost/"


Making HTTP requests via a Unix socket is supported by
curl(1) as well, e. g.:

$ curl --unix-socket ~/my.server.socket http://-/foo 


The first issue is that while most of the HTTP::Server::Simple
functionality is implemented as separate methods, easy to
override in a subclass, calls to sockaddr_in6 and sockaddr_in
are hardcoded into _process_request:

421 my $remote_sockaddr = getpeername( $self->stdio_handle );
422 my $family = sockaddr_family($remote_sockaddr);
423 
424 my ( $iport, $iaddr ) = $remote_sockaddr 
425 ? ( ($family == AF_INET6) ? 
sockaddr_in6($remote_sockaddr)
426   : 
sockaddr_in($remote_sockaddr) )
427 : (undef,undef);

I believe that this code should be split off into a separate
method (or at least the sockaddr_in call should be explicitly
guarded as sockaddr_in6 already is), like:

sub peer_identify
{
my ($self, $peer) = @_;
my $remote_sockaddr = getpeername( $self->stdio_handle );
my $family = sockaddr_family($remote_sockaddr);

my ( $iport, $iaddr )
= ( ($family == AF_INET6) ? sockaddr_in6 ($remote_sockaddr)
($family == AF_INET)  ? sockaddr_in  ($remote_sockaddr)
: (undef, undef) );
...
return ("peername" => ..., "peeraddr" => ..., "peerport" => ...);
}

This is critical to my UNIX subclass [1], as the (currently
unguarded) call to sockaddr_in on a Unix name results in an
exception, which I worked-around by overriding
Socket::unpack_sockaddr_in with a function that returns undef
if the original function throws an exception on the value
passed while unpack_sockaddr_un doesn’t (see [1].)

[1] http://am-1.org/~ivan/src/iroca-2022/lib/HTTP/Server/Simple/UNIX.pm
[2] http://am-1.org/~ivan/src/iroca-2022/test/53-un-serv.perl


Another issue is that the documentation suggests that
peername and peeraddr may be different values (presumably
the former would be an IP resolved into a hostname via rDNS,
while the latter is the address in the numeric form):

563   ITEM/METHOD   Set toExample
…
570   port Received Port 80, 8080
571   peername Remote name   "200.2.4.5", "foo.com"
572   peeraddr Remote address"200.2.4.5", "::1"
573   peerport Remote port   42424
574   localnameLocal interface   "localhost", "myhost.com"

This is not the case the way _process_request is currently
implemented:

447 my ( $file, $query_string )
448 = ( $request_uri =~ /([^?]*)(?:\?(.*))?/s );# split at ?
449 
450 $self->setup(
…
458 peername => $peeraddr,
459 peeraddr => $peeraddr,
460 peerport => $iport,
461 );

And before that, $peeraddr is obtained from Socket::getnameinfo:

429 my $loopback = ($family == AF_INET6) ? "::1" : "127.0.0.1";
430 my $peeraddr = $loopback;
431 if ($iaddr) {
432 my ($host_err,$addr, undef) = 
Socket::getnameinfo($remote_sockaddr,Socket::NI_NUMERICHOST);
433 warn ($host_err) if $host_err;
434 $peeraddr = $addr || $loopback;
435 }

AIUI, the end result is that /both/ peername and peeraddr will
be the numeric IP address (thanks to the Socket::NI_NUMERICHOST
flag used.)

This behavior (which involves no rDNS lookups) I find
 

Bug#1025751: manpages.d.o pages have json-ld objects double-encoded as strings

[Ivan Shmakov]

Package: manpages.debian.org
Severity: minor

[Please do not Cc: me, as I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

While I’m not sure if it perhaps /is/ an accepted practice,
I’d venture to guess that the way manpages.debian.org encodes
JSON-LD objects as strings /and then/ encodes the resulting
strings as JSON strings /yet again,/ is going to confuse some
of the processing tools out there.

Consider, e. g. (split for readability):


"{\"@context\":\"http://schema.org\",\"@type\":\"BreadcrumbList\";,
\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,
\"item\":{\"@type\":\"Thing\",\"@id\":\"/contents-unstable.html\",
\"name\":\"unstable\"}},{\"@type\":\"ListItem\",\"position\":2,
\"item\":{\"@type\":\"Thing\",\"@id\":\"/unstable/acl/index.html\",
\"name\":\"acl\"}},{\"@type\":\"ListItem\",\"position\":3,
\"item\":{\"@type\":\"Thing\",\"@id\":\"\",\"name\":\"getfacl(1)\"}}]}"


— https://manpages.debian.org/unstable/acl/getfacl.1.en.html

Versus, say, https://en.wikipedia.org/wiki/JSON-LD (which
I presume is the correct usage):

{"@context":"https:\/\/schema.org","@type":"Article","name":"JSON-LD",
"url":"https:\/\/en.wikipedia.org\/wiki\/JSON-LD",
"sameAs":"http:\/\/www.wikidata.org\/entity\/Q6108942",
"mainEntity":"http:\/\/www.wikidata.org\/entity\/Q6108942",
"author":{"@type":"Organization",
"name":"Contributors to Wikimedia projects"},
"publisher":{"@type":"Organization","name":"Wikimedia Foundation, Inc.",
"logo":{"@type":"ImageObject",
"url":"https:\/\/www.wikimedia.org\/static\/images\/wmf-hor-googpub.png"}},
"datePublished":"2011-12-30T17:43:17Z",
"dateModified":"2022-11-15T22:34:49Z",
"headline":"a method of encoding Linked Data using JSON"}

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1022851: xorriso: -clone across sessions copies, not clones

[Ivan Shmakov]

Package: xorriso
Version: 1.5.4-4
Control: found -1 1.5.0-1
Control: found -1 1.5.2-1

When -clone is used on a file that belongs to the loaded
session, its contents get /copied/ to the new one (with the
location of the original one updated to match the copy);
while when used on a file /within/ the current session, the
resulting file (as expected) appears to share the extent
with the original one.

I believe that when it comes to rearranging data on ECMA 119
filesystems, it is as important for -clone /not/ to copy the
affected files’ contents as it is for, say, -move.

Consider, for instance, the following shell code.

#!/bin/sh

set -e
set -x
set -C -u

## NB: an arbitrary value, but must be larger than first session size
session_offset=256

f=$(mktemp -- /tmp/hello.X)
printf %s\\n "Hello, world!" >| "$f"

g=$(mktemp -- /tmp/iso.X)
xorriso -padding 0 -uid 0 -gid 0 \
-outdev stdio:/dev/fd/5 5>| "$g" \
-pathspecs on -add /hello/hello.world="$f" -- \
-clone /hello/hello.world /hello/hello.withn

h=$(mktemp -- /tmp/iso.X)
xorriso -padding 0 -uid 0 -gid 0 \
-indev  stdio:/dev/fd/4 4< "$g" \
-grow-blindly "$session_offset" \
-outdev stdio:/dev/fd/5 5>| "$h" \
-clone /hello/hello.world /hello/hello.clone
dd bs=2048 seek="$session_offset" conv=notrunc of="$g" < "$h"

isoinfo -l -i /dev/stdin < "$g"
isoinfo -l -T "$session_offset" -i /dev/stdin < "$g"

The resulting sessions are as follows.

+ isoinfo -l -i /dev/stdin

Directory listing of /
d-   0002048 Oct 26 2022 [ 18 02]  . 
d-   0002048 Oct 26 2022 [ 18 02]  .. 
d-   0002048 Oct 26 2022 [ 20 02]  HELLO 

Directory listing of /HELLO/
d-   0002048 Oct 26 2022 [ 20 02]  . 
d-   0002048 Oct 26 2022 [ 18 02]  .. 
--   000  14 Oct 26 2022 [ 33 00]  
HELLO.WITHN;1 
--   000  14 Oct 26 2022 [ 33 00]  
HELLO.WORLD;1 
+ isoinfo -l -T 256 -i /dev/stdin

Directory listing of /
d-   0002048 Oct 26 2022 [274 02]  . 
d-   0002048 Oct 26 2022 [274 02]  .. 
d-   0002048 Oct 26 2022 [276 02]  HELLO 

Directory listing of /HELLO/
d-   0002048 Oct 26 2022 [276 02]  . 
d-   0002048 Oct 26 2022 [274 02]  .. 
--   000  14 Oct 26 2022 [280 00]  
HELLO.CLONE;1 
--   000  14 Oct 26 2022 [280 00]  
HELLO.WITHN;1 
--   000  14 Oct 26 2022 [280 00]  
HELLO.WORLD;1 

Note that all three entries moved from LBA 33 to LBA 280.

Using two months old versions from Git (libburn 19545142,
libisoburn 3318fa47 and libisofs c6cb7dfa; the few changes
since these revisions made to the latter two don’t seem to
be relevant to the issue) gives the same result.

Omitting the -grow-blindly option (and using -dev stdio:"$h"
instead) doesn’t seem to change this behavior, either.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1016653: gm(1): improve targa (.tga) orientation bits support

[Ivan Shmakov]

Control: retitle -1 gm(1): improve targa (.tga) orientation bits support 

> Bob Friesenhahn writes:

 > However, I believe that this bug report is incorrect.

After reading [1] (and trying both ImageMagick and
GraphicsMagick on the samples*/ provided therein), I guess
my suggestions would be as follows.

 1. GraphicsMagick .tga reader should support all the
combinations of the orientation bits, not just the default
   ‘bottom left’; (I gather that’s something already in Git?)

 2. It should be possible to specify orientation explicitly
both when reading .tga files (my understanding is that files
produced by buggy .tga writers that get these wrong are not
uncommon in the wild) and when writing them (for the benefit
of legacy readers that only implement a specific orientation;
a quick look into LDPCXTGA’s ldtga.cpp has confirmed that it
ignores all the .tga metadata but width and height fields and
assumes the non-default TopLeft orientation.)

I haven’t checked the source, but it seems that at least
-orient is ignored by the GraphicsMagick .tga writer.

 3. I’d think the documentation should feature -auto-orient
more prominently in the examples.

(I’ve retitled the bug report accordingly.)

TYC.

[1] http://gitlab.com/illwieckz/produce-reference-tga

 > What has actually happened is that ImageMagick changed what it 
 > returns and more recent ImageMagick also changed what it does
 > when it displays an image.

It sounds like the behavior of ImageMagick’s display(1)
was reversed exactly twice, which should’ve resulted in the
original behavior being restored, at least so long as the
user is concerned.  What am I missing here?

 > GraphicsMagick always returns an image in the common normal form
 > (TopLeft).  ImageMagick changed so that it returns an image in
 > the same form as the file, but it sets an orientation option so
 > that the user needs to use -auto-orient to see a correct image.

Seems to be the case for .tga images, indeed.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1018240: Xtightvnc(1): support arbitrary stdio in -inetd, not just socket-based

[Ivan Shmakov]

Package: tightvncserver
Version: 1:1.3.10-5+b1
Severity: wishlist
Control: found -1 1:1.3.10-3

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

Xtightvnc(1) concludes with:

Probably, the best way to secure Xvnc server is to allow only
loopback connections from the server machine (the -localhost option)
and to use SSH tunneling for remote access to the Xvnc server.

However, it’s arguably even more secure to either use a Unix
socket accessible by only the intended user(s) (note that
OpenSSH supports Unix to Unix, TCP to Unix, and Unix to TCP
socket forwarding; see the -L option in ssh(1)); or a pair
of pipes, such as rsync(1) uses (by essentially invoking
$ ssh -- REMOTE rsync --server to access the remote.)

Moreover, certain lightweight SSH2 servers, such as
tinysshd(8), omit support for forwarding altogether, which
doesn’t inconvenience tools such as rsync(1) in the least,
but which makes the advice above impossible to follow.

Unfortunately, the obvious candidate for such usage, the
-inetd option, doesn’t quite support it.  The cause is
twofold.  On the one hand, Xtightvnc -inetd still assumes
that the communication is done via a TCP socket, uses
setsockopt(2) on the file descriptor, and exits when that
fails.  On the other, contrary to the documentation,

  -inetd
  Xvnc is launched by inetd.  This option causes Xvnc to redirect
  network input/output to stdin/stdout.

the current implementation uses not stdin and stdout, but rather
‘stdin’ only, for both input and output.  Which isn’t a problem
when the server is started from inetd(8) proper, as in that case
both stdin and stdout point to the same socket; but /is/ a
problem in the proposed usage, where stdin and stdout are two
separate pipes (incoming and outgoing, respectively.)

Xvnc/programs/Xserver/hw/vnc/init.c
361-   close stderr.  OsInit() will redirect stderr logging to an
362-   appropriate log file or /dev/null if that doesn't work. */
363-
364:dup2(0,3);
365-inetdSock = 3;
366-close(2);
367-

Xvnc/programs/Xserver/hw/vnc/sockets.c
101-
102:if (setsockopt(inetdSock, IPPROTO_TCP, TCP_NODELAY,
103-   (char *), sizeof(one)) < 0) {
104:rfbLogPerror("setsockopt");
105-exit(1);
106-}
107-

(So far as I can tell only a single use of setsockopt(2)
in the file is relevant to the problem being described.)

As such, my suggestions would be as follows.

 1. The setsockopt(2) failure in rfbInitSockets () is
downgraded to a warning (from a fatal error.)  This
alone should be sufficient for running Xtightvnc(1)
on a Unix socket via inetd(8), which is already more
secure than a localhost-bound TCP port.

 2. In place of inetdSock, the code should use separate
inetdIn and inetdOut file descriptors, so that it’s
possible to use a pair of pipes in place of a socket.

It’s also possible to work around the problem at hand by
using socat(1) and strace(1) as follows.

#!/bin/sh
### tightvnc-ssh-pipe.sh
## Example Xtightvnc tunneling via SSH pipes.

## Connect with:
##   $ xvncviewer localhost::12345 

LOCAL_PORT=12345
REMOTE=remote.example.net

## .
exec socat TCP4-LISTEN:"$LOCAL_PORT",bind=localhost \
EXEC:"ssh -t -- ${REMOTE} \
  set -C -e -u -- ; stty raw -echo ; exec 3<> /dev/tty ; \
  strace -o /tmp/debug.\"$(date +%s.%N)\" -ft -s95 \
  -e trace=dup2 -e trace=setsockopt \
  -e inject=setsockopt\\:retval=0\\:when=4 \
  -e inject=dup2\\:retval=3\\:when=1 \
  -- Xtightvnc \\:99 -auth \"\$HOME\"/.Xauthority \
 -geometry 1280x$((1024 - 2 * 24)) -depth 24 \
 -dontdisconnect -nevershared -inetd",pty

### tightvnc-ssh-pipe.sh ends here

Here, ssh -t, together with the socat(1) ,pty option, forces
pseudo-tty allocation on the remote side; exec 3<> /dev/tty
redirects file descriptor 3 (which is the number inetdSock
is set to) to the pty thus allocated; -e inject=dup2:retval=3
:when=1 turns the dup2(2) call in init.c into a no-op; and
-e inject=setsockopt:retval=0:when=4 does the same to the
setsockopt(2) call in sockets.c.

Also, while we’re at it, note that Xtightvnc above ignores the
:99 option and binds to /tmp/.X11-unix/X1, as if :1 were given.

It should be noted that the use of pipes, or actually -inetd
/ inetd.conf(5) ‘nowait’, means that the failure of the
underlying connection invariably leads to the termination
of the associated 

Bug#1018239: live-boot: please add support for subroot= option

[Ivan Shmakov]

Package: live-boot
Version: 1:20220505
Severity: wishlist
Tags: patch
Control: found -1 1:20190614

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

SquashFS support for file-level deduplication makes it more
space-efficient to have several distinct Debian installs on
a single SquashFS image, rather than have one image per
install (as per the following syslinux.cfg example snippet.)

LABEL bookworm-2022-08-20
...
APPEND ... boot=live toram=6300e90c.squashfs ...

LABEL bookworm-2022-08-24
...
APPEND ... boot=live toram=6305aa79.squashfs ...

This in turn can be used for tracking testing / unstable,
or for having an image with conflicting packages installed
(even though only one of any given set of such will be
usable for a given boot.)

Moreover, this allows for the SquashFS in question to be
updated incrementally, rather than written anew each time,
which is more friendly to flash-based storage devices; and
also allows for booting into an earlier install should there
be issues with the latest one.

I hereby suggest that a subroot= option is implemented, to
point to a subdirectory on the underlying read-only image to
be used in place of its root; like, Syslinux-wise:

LABEL bookworm-2022-08-24
...
APPEND ... boot=live toram=bookworm.squashfs subroot=x6305aa79 ...

The overlay will then use lowerdir=/run/live/rootfs/bookworm
.squashfs/x6305aa79 in place of /run/live/rootfs/bookworm
.squashfs .

FWIW, I’m using this feature for all my ‘live’ images for
a couple of years now, but my configurations are somewhat
similar, so I can’t claim that I’ve tested it extensively.

Also, while we’re at it, I’ve followed the surrounding
code’s style and used:

   subroot=*) ROOTINFIX="${_PARAMETER#subroot=}" ...
   union=*)   UNIONTYPE="${_PARAMETER#union=}" ...

But it sure is less redundant (and thus less error-prone)
to use instead:

   subroot=*) ROOTINFIX="${_PARAMETER#*=}" ...
   union=*)   UNIONTYPE="${_PARAMETER#*=}" ...

Note that in the latter case there’s only one place the
option name needs to be changed (or aliases added), if
ever need arises.

-- 
FSF associate member #7257  http://am-1.org/~ivan/
--- lib/live/boot/.9990-overlay.sh.~2022-08-23~	2022-05-05 10:16:56 +
+++ lib/live/boot/9990-overlay.sh	2022-08-23 22:45:09 +
@@ -83,7 +83,7 @@ setup_unionfs ()
 			if [ -d "${image}" ]
 			then
 # it is a plain directory: do nothing
-rootfslist="${image} ${rootfslist}"
+rootfslist="${image}${ROOTINFIX:+/$ROOTINFIX} ${rootfslist}"
 			elif [ -f "${image}" ]
 			then
 if losetup --help 2>&1 | grep -q -- "-r\b"
@@ -106,7 +106,7 @@ setup_unionfs ()
 esac
 
 mpoint=$(trim_path "${croot}/${imagename}")
-rootfslist="${mpoint} ${rootfslist}"
+rootfslist="${mpoint}${ROOTINFIX:+/$ROOTINFIX} ${rootfslist}"
 mount_options=""
 
 # Setup dm-verity support if a device has it supported
@@ -188,9 +188,9 @@ setup_unionfs ()
 		log_begin_msg "Mounting \"${image_directory}\" on \"${croot}/filesystem\""
 		mount -t $(get_fstype "${image_directory}") -o ro,noatime "${image_directory}" "${croot}/filesystem" || \
 			panic "Can not mount ${image_directory} on ${croot}/filesystem" && \
-			rootfslist="${croot}/filesystem ${rootfslist}"
+			rootfslist="${croot}/filesystem${ROOTINFIX:+/$ROOTINFIX} ${rootfslist}"
 		# probably broken:
-		mount -o bind ${croot}/filesystem $mountpoint
+		mount -o bind "${croot}/filesystem${ROOTINFIX:+/$ROOTINFIX}" "$mountpoint"
 		log_end_msg
 	fi
 
--- lib/live/boot/.9990-cmdline-old.~2022-08-23~	2022-05-05 10:16:56 +
+++ lib/live/boot/9990-cmdline-old	2022-08-23 22:45:10 +
@@ -257,6 +257,11 @@ Cmdline_old ()
 export ROOT
 ;;
 
+			subroot=*)
+ROOTINFIX="${_PARAMETER#subroot=}"
+export ROOTINFIX
+;;
+
 			union=*)
 UNIONTYPE="${_PARAMETER#union=}"
 export UNIONTYPE

Bug#1018238: gm(1): please add Linux framebuffer (/dev/fb0) support

[Ivan Shmakov]

Package: graphicsmagick
Version: 1.4+really1.3.38-1
Severity: wishlist
Control: found -1 1.4+really1.3.36+hg16481-2
Control: found -1 1.4+really1.3.35-1~deb10u2

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

It is currently possible to use $ gm convert command to show
images by writing them directly into Linux framebuffer, provided
that the /dev/fb0 device file permissions are set appropriately.

For instance, on my system, the command could be:

$ gm convert -resize 1280x1024 -gravity center -extent 1280x1024 \
  -depth 8 -recolor "0 0 1 0, 0 1 0 0, 1 0 0 0, 0 0 0 1" \
  IMAGEFILE\[0] rgba:/dev/fb0 

Similarly, it’s possible to take screenshots, though the
only way to do so that I was able to figure out requires
a simple byte order conversion helper, like:

$ (perl -e 'use common::sense; binmode (STDIN); binmode (STDOUT);
local $/ = \(4 * 1280); while () {
s/(.)(.)(.)./$3$2$1\377/g; print ($_); }' \
   < /dev/fb0 \
   | gm convert -size 1280x1024 -depth 8 rgba:- SCREENSHOT.png) 

The obvious inconvenience here is that the framebuffer data
format (-size, -depth, but in general also the layout and
such things as the use of indexed color instead of RGB(A))
vary from system to system, depending on the hardware and
its boot- (e. g., I use video=VGA-1:1280x1024-24 on my system)
and run-time (as could be set with fbset(1), at least on
some arm64 machines) configuration.

I therefore suggest that a new ‘Linux framebuffer’ image
format is implemented in GraphicsMagick that would use the
FBIOGET_FSCREENINFO ioctl [1] to figure out the framebuffer
resolution and format before reading (writing) image data
from (to) it; like:

$ gm convert imagefile linuxfb:/dev/fb0 
$ gm convert linuxfb:/dev/fb0 screenshot.png 
$ 

[1] http://kernel.org/doc/html/latest/fb/api.html

Better still if it’d be possible to select a portion of
framebuffer for reading (without reading the whole framebuffer
first), or to put the image into a given position on screen
when writing.  While this won’t turn gm(1) into a fully-featured
framebuffer image viewer, for what we have fbi(1) already,
arguably it would be rather a convenient feature to use from
scripts.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1016657: enable ipv6 and math options (and more?); harmonize README.*

[Ivan Shmakov]

Source: jimtcl
Version: 0.81+dfsg0-2
Severity: minor
Control: found -1 0.77+dfsg0-3

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

[Using Severity: minor chiefly due to the inclusion of the
README.* discrepancy in this report; feel free to clone and
address the issues separately.]

It’s customary for packages to be built for Debian with all
possible options enabled; or, alternatively, for there to be
separate ‘fully-featured’ and ‘low-footprint’ packages (such
as vim-nox vs. vim vs. vim-tiny; or exim4-daemon-heavy vs.
exim4-daemon-light; etc.)

Assuming there’d be no negative implications for Jim users
in Debian (such as openocd) in doing so, I request that ipv6
and math options are enabled for Debian Jim packages; which,
I presume, could be achieved by adding --ipv6 and --math to
the second dh_auto_configure invocation in debian/rules:

24  
25  override_dh_auto_configure: autosetup/jimsh0.c
26  dh_auto_configure --builddirectory=static/
27  dh_auto_configure -- --shared
28  

Currently both options are evidently disabled:

$ jimsh -e "socket -ipv6 stream.server  " 
ipv6 not supported
$ jimsh -e "expr { sin (1) } " 
syntax error in expression: " sin (1) "
$ 

It’d be nice to have UTF-8 support enabled as well (--utf8),
but I’m less certain that it won’t interfere with current Jim
users in Debian.

$ jimsh -e 'string length "\u2012" ' 
3
$ tclsh8.6 <(printf %s\\n 'puts [ string length "\u2012" ] ') 
1 
$ 

Overall, I’d think that /also/ having Jim packages built with
the --full configure option (which is to say, with support
for sqlite3, zlib and others) could come handy to some of us.
So far as I can tell, it’d involve making separate jimsh-full,
libjim-full and libjim-full-dev packages, which seems somewhat
unreasonable.

That, however, reminds me that there’s currently a discrepancy
between the README.* files installed by the package and the
features actually enabled at build time.  Namely, the jimsh
package includes the README.sqlite.gz and README.utf-8.gz
files, which correspond to features that are disabled and
unavailable to Debian jimsh package users.  Conversely, the
package /does not/ include README.namespaces, despite the
respective feature being enabled (by default.)  Hence I also
request that this discrepancy be rectified.

TIA.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1016656: colcrt(1) produces broken (off-by-one?) output

[Ivan Shmakov]

Package: bsdextrautils
Version: 2.38-4
Severity: minor
Control: found -1 2.36.1-8+deb11u1

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

The colcrt(1) version from bsdextrautils produces output
that does match neither the version from Debian Buster
(bsdmainutils) nor, say, the version from NetBSD.

Expected behavior (Buster, NetBSD 9; GNU Sed):

$ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt 
Hello
-
Hello
$ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt - 
Hello
Hello
$ 

Observed behavior:

$ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt 
H e l l o
 - - - - -
HHeeoo
$ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" | colcrt - 
H e l l o
HHeeoo
$ 

As a workaround, $ ul -t dumb can be used in place of
$ colcrt -:

$ printf %s\\n Hello | sed -e "h; s/./&\\x8&/g; x; s/./&\\x8_/g; G;" \
  | ul -t dumb 
Hello
Hello
$ 

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1016653: gm(1): targa (.tga) files are read and written upside-down

[Ivan Shmakov]

Package: graphicsmagick
Version: 1.4+really1.3.38-1
Severity: minor
Control: found -1 1.4+really1.3.36+hg16481-2
Control: found -1 1.4+really1.3.35-1~deb10u2

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

While graphicsmagick claims to support ‘Truevision Targa’
format, its implementation is apparently slightly defective
in that the images are read and written with their vertical
axis reversed.  Consider, for instance, SHAPES.TGA from [1]:
it’s shown with the gray (#9c9c9c) ‘floor’ at the bottom of
the image by both LDPCXTGA.EXE and ImageMagick’s display(1),
yet $ gm display SHAPES.TGA shows the floor at the /top/ of
the image instead.

[1] http://archive.org/download/simtelnet_bu_mirror_2013_04
/simtelnet.bu.mirror.2013.04.zip/simtelnet%2Fmsdos%2Fgraphics
%2Fldpcxtga.zip (URI split for readability.)

The same applies to images produced with $ gm convert.

The obvious workaround is to use -flip, like:

$ gm display -flip SHAPES.TGA 
$ gm convert input.file -flip output.tga 

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1010098: xorriso: please allow -cut-out directly from block devices

[Ivan Shmakov]

> On 2022-04-26, Thomas Schmitt wrote:
> TS == Thomas Schmitt wrote:

 TS> So if we exclude S_IFSOCK, S_IFLNK, S_IFDIR, S_IFIFO there
 TS> remain only S_IFREG, S_IFBLK, S_IFCHR with the latter on Linux
 TS> behaving like S_IFREG with 0 bytes of content.  (As said on
 TS> FreeBSD it could be a lseekable disk device.)

I’m not familiar with FreeBSD, but at least on NetBSD block
devices are paired with character devices used for ‘raw’
access; for example, the first GPT partition may end up
being /dev/dk0 (block) and /dev/rdk0 (character); a logical
volume could be /dev/vgfoo/lvbar (block) and /dev/vgfoo/rlvbar
(character); etc.

On Linux-based systems, such a device can apparently be
created with raw(8), but it’s not something I recall ever
needing to use.

http://manpages.debian.org/bullseye/raw.8

 > I decided to regard a device with 0 lseekable size as not
 > suitable for -cut_out.

An alternative would be to check if it’s possible to seek to
specified positions rather than to the end of file; e. g.:

$ strace -e trace=lseek -- dd skip=5 count=7 < /dev/zero > /dev/null 
lseek(0, 0, SEEK_CUR)   = 0
lseek(0, 2560, SEEK_CUR)= 0
7+0 records in
7+0 records out
3584 bytes (3.6 kB, 3.5 KiB) copied, 0.00119932 s, 3.0 MB/s
+++ exited with 0 +++
$ 

Can’t say I can readily suggest a good use case for such a
feature, though.  Should one need to add a zero-filled file
of arbitrary size to the resulting filesystem (such as to
reserve space for a possible future dd(1) there), such
a (regular) file can easily be created with truncate(1)
(though it can be argued that -cut-out /dev/zero is a tad
clearer solution.)

 > The test for suitable type rejects S_ISDIR, S_ISLNK, S_ISFIFO,
 > and S_ISSOCK.  So if an operating system offers non-POSIX types,
 > it will be possible to test whether they are elsewise suitable.

 > Please give the code a thorough test, especially with weird
 > -cut_out arguments.

This looks like a job for a test suite.  I gather there’s
none as of yet?

Meanwhile, I’ve noticed that the files created via -cut-out
inherit the permissions and m-time of the original file.
The former might be reasonable, but the latter doesn’t seem
to make much sense, at least for device files (whose m-times
tend to have no relation to their content proper.)

Worse still, if the target file is created in a yet-nonexistent
directory, the directory created inherits the permissions
of the source file as well (only adding +x where there’s r.)
I’d rather expect for missing directories to be created as
if with -mkdir.

Thoughts?

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1010098: xorriso: please allow -cut-out directly from block devices

[Ivan Shmakov]

>>>>> On 2022-04-24, Thomas Schmitt wrote:
>>>>> Ivan Shmakov wrote:

 >> I’m filing this bug against versions from oldstable and stable,
 >> for that’s so far the only Debian packages’ versions I’ve tested
 >> for this issue.

 > As it is about an upstream wish:

 > The newest easily compilable and then usable version would be
 >   http://www.gnu.org/software/xorriso/xorriso-1.5.5.tar.gz

Not under http://ftp.gnu.org/gnu/xorriso/ , though?

 > It can be compiled without much dependencies and then used without
 > installation. See "Compilation, First Glimpse, Installation" in
 >   https://www.gnu.org/software/xorriso/README_xorriso_devel

 > Said that, and now with my upstream hat on, i expect no difference
 > to versions 1.5.0 or 1.5.4 in respect to command -cut_out.

It’d seem that I’ve missed an important detail or two in my
original message.  The patch suggested was against the following
Git revisions of the libisofs and libisoburn:

commit da00291519ad22c5bfa79c93ffeb04219bab0d7e
Author: Thomas Schmitt 
AuthorDate: 2022-04-23 09:32:44 +0200
Commit: Thomas Schmitt 
CommitDate: 2022-04-23 09:32:44 +0200

Let the original isohybrid GPT obey system_area() option bit 17:
GPT writable

commit 0ef65a783765dbde79242ac41d5b9f2a495de1ec
Author: Thomas Schmitt 
AuthorDate: 2022-04-23 14:09:30 +0200
Commit: Thomas Schmitt 
CommitDate: 2022-04-23 14:09:30 +0200

Updated change log and web page

I’d frankly be surprised to learn that a proper release,
such as 1.5.5, has features which a recent revision from
Git master branch lacks.

 > So there is no need to get xorriso-1.5.5.tar.gz unless you want
 > to test a patch proposed by me.

I’ll be checking the master branch from time to time, and hope
to test the patch and report the results once it lands there.

TIA.

 > I downloaded your 114.xorriso-1.diff and will study it for the
 > goal of enabling -cut_out for more file types.

 > I already see that it makes changes about fsrc_open(), which is a
 > central facility of libisofs.  This means it will last several days
 > of study and pondering until i would be convinced of any change.

The patch was intended, first and foremost, as a proof of
concept; I hope I’ve identified /where/ the code needs to be
changed, but I’m not going to claim familiarity with all the
code paths involved, and as such cannot readily suggest
/what/ changes are needed.  As it is, I fully expect for the
things to break.

 > Also i need to check whether your diff interferes with the
 > ability to backup a block device file as itself and not as bearer
 > of its content:

 >   rm test.iso
 >   xorriso -outdev test.iso -map /dev/sr0 /sr0 -commit -lsdl /sr0 --

 > should produce even with a loaded BD_RE medium of 23 GiB a small ISO and
 > report a block device file in it

 >   brw-rw1 024   11,0 Apr 24 14:15 '/sr0'

FWIW, as a user, I’d expect an additional -follow option for
this feature, such as:

  *seekable*  If enabled, any non-regular seekable file (such as a
block device) would be stored on image as a regular one with the
contents taken from the original.  The default is to store special
files as-is.  (See also the -cut_out option.)

In the implementation, I’d rather see it not testing the
file type specifically, aside of S_ISREG, S_ISDIR and S_ISLNK,
but rather whether lseek (, 0, SEEK_END) gives a sane result,
thus allowing for transparent support of novel or non-standard
(platform-specific) file types.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1010098: xorriso: please allow -cut-out directly from block devices

[Ivan Shmakov]

Package: xorriso
Version: 1.5.0-1
Severity: wishlist
Control: found -1 1.5.2-1

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the report being filed.]

I’m filing this bug against versions from oldstable and
stable, for that’s so far the only Debian packages’ versions
I’ve tested for this issue.  Regardless, given that the
behavior is the same for a recent Git revision, and that
there doesn’t seem to be any relevant Debian-specific
patches under [1], it stands to reason that the requested
feature is not available in Debian testing and Sid, either.

[1] http://sources.debian.org/src/libisoburn/1.5.4-2/debian/patches/

It would be handy to be able to use xorriso(1) to backup
(portions) of block devices to optical media; yet it doesn’t
seem to be supported.  E. g., on Buster:

bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
  -cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m \
  -find / -exec lsdl -- -commit 
xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project.

Drive current: -dev 'stdio:/tmp/cd4973.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data,  XXXm free
xorriso : FAILURE : -cut_out: Unsupported file type (block_device) with 
'/dev/vgjubca-bk-i/lvepeci-x626512db' : No such file or directory
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
bash$ 

On Bullseye:

bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
  -cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m \
  -find / -exec lsdl -- -commit 
xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project.

Drive current: -dev 'stdio:/tmp/cd1415.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data,  XXXm free
xorriso : FAILURE : -cut_out: Unsupported file type (block_device) with 
'/dev/vgjubca-bk-i/lvepeci-x626512db' : No such file or directory
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
bash$ 

The problem is due to /both/ libisoburn (to a lesser degree)
and libisofs relying on struct stat .st_size field (and the
respective S_ISREG check.)

I’ve made a very crude patch (MIMEd) that replaces the
st_size checks for non-regular files with checks against the
size reported by lseek (, 0, SEEK_END), if available; and in
some cases forgoes the check for non-regular files altogether.

Consider, e. g.:

bash$ xorriso -dev stdio:/tmp/cd"$RANDOM".image -follow link \
  -cut-out /dev/vgjubca-bk-i/lvepeci-x626512db 37M 13M lvxxx_37m+13m 
-find / -exec lsdl -- -commit 
xorriso 1.5.5 : RockRidge filesystem manipulator, libburnia project.

Drive current: -dev 'stdio:/tmp/cd14597.image'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data,  XXXm free
drwxr-xr-x1 00   0 Apr 24 10:16 '/'
-rw-rw1 0613631488 Apr 10 10:58 '/lvxxx_37m+13m'
xorriso : UPDATE : Writing:   3985s   58.2%   fifo   0%  buf  50%
ISO image produced: 6679 sectors
Written to medium : 6848 sectors at LBA 32
Writing to 'stdio:/tmp/cd14597.image' completed successfully.

xorriso : NOTE : Re-assessing -outdev 'stdio:/tmp/cd14597.image'
xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE :   1 nodes read in 1 seconds
Drive current: -dev 'stdio:/tmp/cd14597.image'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Media summary: 1 session, 6679 data blocks, 13.0m data,  XXXm free
Volume id: 'ISOIMAGE'
bash$ 

Checking if the intended data was indeed written to the image
with icat(1):

bash$ /usr/bin/time -- cmp -n 13M -i 37M:0 -- \
  /dev/vgjubca-bk-i/lvepeci-x626512db \
  <(icat /tmp/cd14597.image 1) 
0.01user 0.04system 0:00.18elapsed 29%CPU (0avgtext+0avgdata 1088maxresident)k
27112inputs+0outputs (0major+95minor)pagefaults 0swaps
bash$ 

-- 
FSF associate member #7257  http://am-1.org/~ivan/
--- ./libisofs-da002915/libisofs/stream.c.~1~	2022-04-23 07:32:44 +
+++ ./libisofs-da002915/libisofs/stream.c	2022-04-24 08:39:06.352583604 +
@@ -34,11 +34,27 @@
 ino_t cut_out_serial_id = (ino_t)1;
 
 static
+off_t fsrc_lseek_end_off(IsoFileSource *src)
+{
+/** For non-regular files, we check seekability
+and obtain SEEK_END position to use as size */
+off_t end, old, reset;
+old = iso_file_source_lseek (src, 0, 1);
+if (old < 0) { return -1; }
+end = iso_file_source_lseek (src, 0, 2);
+if (end < 0) { return -1; }
+reset = 

Bug#1004583: overwriting {,src}pkgcache.bin on near-every APT call strains flash

[Ivan Shmakov]

>>>>> On 2022-02-01 12:27:50 +0100, Julian Andres Klode wrote:

 > Control: reopen -1

I know there’re different approaches to this, but I believe that
a report shouldn’t be closed so long as it describes a behavior
that’s a. reproducible and b. known to affect at least some users.

At the very least, keeping the report open will help prevent
others from reporting the same issue over and over again.

For the cases where the developer finds the existing behavior
infeasible to alter, Debian BTS provides the ‘wontfix’ tag.

 > On Sun, Jan 30, 2022 at 07:10:34PM +, Ivan Shmakov wrote:

 >> A proper solution would be to move to some file format that
 >> allows in-place updates, such as Berkeley DB or SQLite.

 > No it would not be.  The best we can do, and maybe should do
 > is move pkgcache.bin to /run.

 > In-place updates means _a lot_ of things can go wrong.  Like you
 > forget to delete packages that are no longer in the repository.

While I’m by no means familiar with the code base, this problem
does not sound insurmountable.  Moreover, this is something
I personally would be interested in working on.

 > There’s also no way to change this in any case, the database
 > format is an integral part of the public API, it would take
 > decade(s) to switch to anything else.

I wasn’t aware of this (though it does make sense, given the
availability of alternative interfaces to APT functions.)

Where this format, and its intended use, are documented?

 > Unfortunately I only thought about moving pkgcache.bin to
 > /run directly after sending the close email, but I think
 > that might be a reasonable compromise to discuss, and if
 > we support $XDG_RUNTIME_DIR/apt/pkgcache.bin as well, then
 > that would even get us caching for non-root users.

I can’t say I readily see the utility of that, at least by itself.

Sure, I’ve used apt-get as a non-root user to download lists
and packages to copy to systems where the network connectivity
was poor (or non-existent), but I had to point Dir::Cache and
Dir::State::Lists to locations writable by that same user
to achieve my goals, not just pkgcache.bin.

 > How to move that file out of /var/cache/apt is going to be
 > a tricky question, as that location is to some extend part
 > of the API as well - people might set Dir::Cache to /tmp/apt
 > and expect pkgcache.bin to end up in /tmp/apt.

The APT configuration language doesn’t seem to provide
a straightforward solution for invalidating a default
for one option when another one is set by the user, indeed.

Given that the current behavior is, AFAIK, problematic only in
two cases (a. /var/cache/apt resides on an SD card; and
b. block-level backups are used for the filesystem containing
said directory; which is, incidentally, how I initially became
aware of this behavior), both of which seem relatively rare,
I think the best approach would be to either let the user
decide (such as via debconf), or at least inform them of the
potential problem.

Furthermore, as installing Debian on an SD card (or similar
flash-based device not rated for the amount of writing the
updating of pkgcache.bin might take) doesn’t seem common outside
of ARM-based SBCs, it may make sense to restrict the fix,
whichever that might be, to ARM (arm64, armhf, armel)
architectures.

More directly, the fix can be applied if it can be detected with
a degree of reliability at .postinst time that pkgcache.bin
might end up on an SD card.  (The necessary info is mostly
there, see lsblk(8) output for instance, though I know of no
straightforward way to map a file to the stack of devices
it resides on.  Presumably we can consider placing pkgcache.bin
under /run if we find something like mmcblk* while traversing
the stack upwards from the device that holds the filesystem.)

 > With regards to srcpkgcache.bin, which represents the available
 > packages, but no installed packages (pkgcache.bin is built from
 > it by adding the dpkg status file in-place, in-memory, and then
 > writing it back out), I think having that around after a reboot
 > is what we want such that you don’t need to rebuild the entire
 > cache each boot.

FWIW, I mainly use Debian on Socket AM2-class hardware (which
is to say, about 12 years old), and IME it takes something like
20 seconds to rebuild the cache.  As such, I wouldn’t myself be
much concerned with rebuilding the cache from scratch.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1004583: overwriting {,src}pkgcache.bin on near-every APT call strains flash

[Ivan Shmakov]

Package: apt
Version: 2.3.14
Severity: minor
Control: found -1 1.8.2.3

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.
I’d have set up Mail-Followup-To:, but there doesn’t seem to
be a way to make it point to the bug being filed.]

As of this writing, pkgcache.bin and srcpkgcache.bin files for
an APT instance configured for testing / Sid are 61 MiB combined.

The way those caches are updated is by writing a new version
into a temporary file and then calling rename(2) to atomically
replace the old version with the new.  As such, every time the
caches are updated, some 61 MiB gets written to the filesystem

While it could be argued that such an amount written makes
no measurable impact on HDDs, and rather marginally affects
the lifetime of contemporary SSDs, it’s not uncommon to start
Debian from a micro-SD card on single-board computers, where
write cycles may be considerably more limited.

Similarly, when filesystems-level snapshots are supported
(Btrfs, Nilfs, etc.), the issue described prevents space (and
bandwidth, when snapshots are transferred with btrfs-send(8) /
btrfs-receive(8)) savings by getting in the way of the
filesystem’s copy-on-write behavior.

(FWIW, apt is by no means the only package with such an issue:
dpkg’s status file is updated the same way, and so is the
templates.dat file debconf uses by default; yet dpkg/status is
smaller, and debconf can be configured to use Driver: PackageDir,
also lowering the impact.  Outside of the Debian infrastructure,
tor caches are also ill-suited for write-limited media.)

Consider, for example, the following chroot environment with a
freshly installed Debian Bookworm (--arch=amd64 --variant=minbase
and a couple of packages on top of that):

chroot# apt-get update 
Hit:1 http://cdn-fastly.deb.debian.org/debian bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security/updates 
InRelease
Reading package lists...
chroot# 

Now, let’s try to install some lightweight packages, checking
the ‘lifetime writes’ meter before and after the apt-get call:

base# mount -o remount,ro -- /dev/vgfoo/lvchild-z61f590 \
  && dumpe2fs -- /dev/vgfoo/lvchild-z61f590 | grep -E -- ^Lifetime 
Lifetime writes:  5418 MB
base# 

chroot# apt-get install -- jpeginfo 
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  libjpeg62-turbo
The following NEW packages will be installed:
  jpeginfo libjpeg62-turbo
0 upgraded, 2 newly installed, 0 to remove and 5 not upgraded.
Need to get 0 B/177 kB of archives.
After this operation, 725 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
debconf: delaying package configuration, since apt-utils is not installed
E: Can not write log (Is /dev/pts mounted?) - posix_openpt (19: No such device)
Selecting previously unselected package libjpeg62-turbo:amd64.
(Reading database ... 6737 files and directories currently installed.)
Preparing to unpack .../libjpeg62-turbo_1%3a2.1.2-1_amd64.deb ...
Unpacking libjpeg62-turbo:amd64 (1:2.1.2-1) ...
Selecting previously unselected package jpeginfo.
Preparing to unpack .../jpeginfo_1.6.1-1_amd64.deb ...
Unpacking jpeginfo (1.6.1-1) ...
Setting up libjpeg62-turbo:amd64 (1:2.1.2-1) ...
Setting up jpeginfo (1.6.1-1) ...
Processing triggers for libc-bin (2.33-3) ...
chroot# 

base# mount -o remount,ro -- /dev/vgfoo/lvchild-z61f590 \
  && dumpe2fs -- /dev/vgfoo/lvchild-z61f590 | grep -E -- ^Lifetime 
Lifetime writes:  5740 MB
base# 

By the looks of it, installing 725 KiB worth of Debian packages
resulted in some 322 MiB getting written to the filesystem,
for which I’m inclined to think that APT cache update behavior
is in no small part responsible.  (I suppose running apt-get
under strace would allow for a more accurate estimate.)

For instance, largest recently changed files on the FS right
after the # apt-get install call were (note that the .deb files
to be installed were obtained earlier, and also that
/var/cache/apt/archives was on a separate FS anyway):

chroot# find / -xdev -cmin -4 -printf %k\\t%p\\n | sort -srn 
31568   /var/cache/apt/pkgcache.bin
31548   /var/cache/apt/srcpkgcache.bin
580 /usr/lib/x86_64-linux-gnu/libjpeg.so.62.3.0
88  /var/lib/dpkg/status-old
88  /var/lib/dpkg/status
52  /var/log/dpkg.log
40  /usr/share/doc/libjpeg62-turbo/copyright

A proper solution would be to move to some file format that
allows in-place updates, such as Berkeley DB or SQLite.

As a work-around, it’s possible to move the 

Bug#904572: move x11-utils to Suggests

[Ivan Shmakov]

> On 2018-07-25 10:27:15 +0200, Harald Dunkel wrote:

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.]

> Harald Dunkel  writes:

 > Package: xterm
 > Version: 333-1

 > xterm recommends x11-utils.  Assuming the default configuration, this
 > brings in a huge list of packages unrelated to xterm's main purpose:
 > Running a shell or another cli program.  Sample:

[…]

 > The following additional packages will be installed:
 >libdrm-amdgpu1 libdrm-intel1 libdrm-nouveau2 libdrm-radeon1
 >libfontenc1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa
 >libllvm3.9 libpciaccess0 libtxc-dxtn-s2tc libxcb-glx0
 >libxcb-shape0 libxtst6 libxv1 libxxf86dga1 libxxf86vm1 x11-utils
 >xbitmaps

[…]

 > If I manually omit x11-utils, then installing xterm uses just about
 > 2 MByte.

Note that it’s also possible to configure apt_preferences(5)
to avoid installation of unwanted packages (regardless of them
being recommended.)  E. g. (though in this case it’s likely
libgl1-mesa-dri that rather should be avoided, see below):

$ cat < /etc/apt/preferences.d/55-no-x11-utils.pref 
Explanation: The x11-utils package is not welcome on this system.
Package:
 x11-utils
Pin: release c=main
Pin-Priority: -42

$ 

[…]

What’s going on here is that x11-utils contains, among others,
the /usr/bin/xdriinfo program, which is linked against libGL.
As such, the binary package automatically gets Depends: libgl1,
which is in turn dependent on libglx0 ← libglx-mesa0 ←
libgl1-mesa-dri, the last of which is itself large enough, and
also brings in a whole world of dependencies, as I’ve noted
in http://bugs.debian.org/960133 .

There’re several ways to resolve the issue, one of which is
indeed to move luit into a package of its own, though I can’t
say I’m particularly fond of practices that lead to the
expansion of the Packages files, as well as /var/lib/dpkg/.

FWIW, I haven’t noticed any ill effects due to the workaround
described in #960133 on Buster, but haven’t yet tested it
on Bullseye.  Given that DRI modules are more often than not
useless without appropriate proprietary GPU software,
downgrading dependency on libgl1-mesa-dri to Recommends:
makes every sense to me.

Perhaps we should try to find and merge all such bugs together
and record ‘affects’ accordingly, to give the issue a tad more
attention and better cooperation / coordination?  Thoughts?

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#880499: apt-cache rdepends outputs too many dependencies

[Ivan Shmakov]

Control: tags -1 moreinfo
Control: severity -1 minor

> Tom  writes:

[Please do not Cc: me, for I’m “on the list,” so to say, and
I try to reserve my inbox for private communication only.]

 > I try to find all reverse dependencies of a certain package.  I’m
 > only interested in “Depends” relations, no Recommends, Suggests, etc.
 > So, for instance, for the aptitude package, I do:

 >  $ apt-cache rdepends "aptitude" --installed \
 >--no-pre-depends \

As an aside, I’m going to question whether omitting Pre-Depends:
is really what you’re looking for, as Pre-Depends: is essentially
a stronger / specialized form of Depends:.  For instance, Debian
Policy Manual states [1]:

  Pre-Depends

This field is like Depends, except that it also forces dpkg to
complete installation of the packages named before even starting the
installation of the package which declares the pre-dependency […]
 
  [1] http://debian.org/doc/debian-policy/ch-relationships.html

 >--no-suggests --no-recommends --no-conflicts --no-breaks \
 >--no-replaces --no-enhances 

Also note that at some point apt-cache acquired the --important
option, which seems effectively the same as the above [2]
(though the man page somehow does not mention rdepends here):

  -i, --important

Print only important dependencies; for use with unmet and depends.
Causes only Depends and Pre-Depends relations to be printed.
Configuration Item: APT::Cache::Important.

  [2] http://manpages.debian.org/unstable/apt/apt-cache.8.en.html

 > aptitude
 > Reverse Depends:
 > aptitude:i386
 > aptitude:i386
 > aptitude:i386
 > aptitude:i386
 > aptitude:i386

 > But there are no reverse dependencies on aptitude, as reported be
 > aptitude:

 > i aptitude

 > [… some lines skipped …]

 > --\ Packages which depend on aptitude (23)
 > --\ Depends (5)
 > p aptitude-robot 1.5.1-1

[…]

What I see above is actually exactly the opposite: the apt-cache
call reports the aptitude:i386 package several times over, but
/no/ (installed, due to the --install option) packages dependent
on it, while aptitude reports a number of (non-installed,
presumably) dependencies, such as aptitude-robot.

Were there dependent packages satisfying the criteria given,
the output would contain something like:

Reverse Depends:
  aptitude-robot
aptitude:amd64

The output may be a tad confusing (and likely worth fixing),
but that’s pretty much the only issue I can discern here.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#242510: screen: spins when pasting

[Ivan Shmakov]

Control: found -1 4.6.2-3+deb10u1
Control: found -1 4.8.0-6

> On 2004-04-06 22:31:43 -0400, Allan Wind wrote:

 > Package: screen
 > Version: 4.0.2-3
 > Severity: normal

 > I have been seeing an issue for a while, where screen appears to be
 > going into a busy loop when pasting data into vim.  Not exactly sure
 > how to reproduce this, but something along these lines seem to always
 > work when the data is important (but I cannot reproduce it consistently):

[…]

 > When it works, it takes ~3 sec paste the 10k lines on my box, and when
 > you hit the issue I never seen it terminate.

I was able to reproduce it with both 4.6.2-3+deb10u1 and 4.8.0-6;
it seems, however, that an important part is to signal Screen
while it sends the data down to the application; such as with:

1. $ seq 1 0x10 | fmt -w78 > /tmp/screen-exchange .

2. $ screen ; then load the file with C-a < .

3. $ vim.tiny ; start pasting the data there with C-a ] .

4. Press ^C while Screen is still sending the data.

5. Screen appears to enter an infinite loop: 100% CPU
   utilization, no syscalls seen via strace(1), etc.

Given that this bug effectively results in the loss of a given
Screen session, possibly with all the (‘unsaved’) data therein,
I believe it deserves a higher Severity: .

(Could #524304 be possibly related?)

As a workaround, some applications may be salvaged with
reptyr(1); like:

1. Find out the PID of the ‘broken’ session:

$ pgrep --full -u"$(id -u)" -- ^SCREEN\\b 
1234
$ 

   (It’s possible to $ kill -STOP the process here so that it no
longer consumes CPU cycles.)

2. Find out the PIDs of the programs running under:

$ pstree -Apl -- 1234 
screen(1234)-+-vim(2468)
 `-lynx(5678)

3. Move said programs to another Screen session:

$ screen -t vim 10 reptyr -V -- 2468 
$ screen -t lynx 11 reptyr -V -- 5678 

4. Once all the programs are recovered, terminate their original
   Screen instance:

$ kill -- 1234 

   (If the process was stopped before, as suggested above, also
resume it with $ kill -CONT , so it can process the signal
sent and terminate.)

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#981288: /usr/bin/jacal: references build-time dir; vicinity lacks a /; bashism

[Ivan Shmakov]

Package: jacal
Version: 1c7-1

The /usr/bin/jacal script provided by the current jacal package
fails to set SCHEME_LIBRARY_PATH and JACALDIR correctly:

#! /bin/sh
SCHEME_LIBRARY_PATH=/usr/share/slib
export SCHEME_LIBRARY_PATH
JACALDIR=/build/jacal-PHwb3U/jacal-1c7/debian/jacal/usr/lib/jacal/
VERSION=1c7

Specifically, SCHEME_LIBRARY_PATH (library-vicinity) is expected
to be a prefix (i. e., contain a trailing /), not directory name;
and JACALDIR somehow contains build-time prefix (in place of
a run-time one.)

Also, while we’re at it, I think that the script should make it
possible for the user to override either or both of the variables.
That is, I’d rather have it start with:

#! /bin/sh
: "${SCHEME_LIBRARY_PATH:=/usr/share/slib/}"
export SCHEME_LIBRARY_PATH
: "${JACALDIR:=/usr/lib/jacal/}"
VERSION=1c7

(Which is not without its downsides, but is otherwise consistent
with how, say, shells allow for PATH to be overridden arbitrarily.)

FTR, the built-time directory name capture is somehow despite
debian/rules [1] containing:

# These are from upstream's install target, turned into correctness.

debian/jacal/usr/bin/jacal:
-mkdir -p $$(dirname $@)
echo '#! /bin/bash'  > $@
echo JACALDIR=/usr/lib/jacal/   >> $@
echo VERSION=$(version) >> $@
cat jacal.sh>> $@
chmod +x $@

[1] http://sources.debian.org/data/main/j/jacal/1c7-1/debian/rules

-- 
FSF associate member #7257  http://am-1.org/

Bug#690849: downgrade fontconfig-config dependencies on fonts to Recommends:

[Ivan Shmakov]

>>>>> On 2012-11-11 03:30:58 +0700, Ivan Shmakov wrote:

[…]

 > It took longer than I expected, but I can confirm that neither
 > extract(1), nor pdftotext(1) (both depending on libpoppler19 and thus
 > fontconfig-config) require fonts to operate.  (I presume that GNUnet
 > “non-GUI” processes don't use fonts, either.)

FTR, I believe that GNUnet documentation at one point explicitly
recommended that separate binary packages are provided by
distributions, so that, for instance, the core server(s) would
/not/ depend on libextract (and thus libpoppler and libfontconfig.)

So far this recommendation isn’t implemented in Debian.

[…]

 > To stress it out: due to the libpoppler19 ← libfontconfig1
 > dependency, the latter may become a requirement on systems deployed
 > to deal with PDF files (as in: search engine indexing.)  Given that
 > such a system may itself reside on a “virtual”, resource-limited
 > (as in: a couple of GiB's of filesystem space) server, it may be
 > entirely reasonable to try to save every MiB of the available FS space.

 > That being said, ttf-bitstream-vera takes less than a MiB (as per
 > Installed-Size:), so this issue could certainly be deferred until
 > Wheezy is released.  (And then perhaps the considerations above would
 > no longer be of much importance.)

These days, my primary concern is the amount of code installed
on my systems, as that contributes heavily to their respective
‘attack surfaces’.  With ttf-bitstream-vera being a pure data
package, which apparently knew no security issues (and none I’d
personally expect), I have no qualms about having it installed
on those of my systems where more comprehensive font packages
aren’t needed.

As such, and unless some further work is planned on this issue,
I suggest it be tagged wontfix.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#550308: [xedit] missing deps on xbitmaps

[Ivan Shmakov]

Control: fixed -1 7.7~1

> On 2011-10-06 12:42:01 +0200, Ralf Jung wrote:

 > Actually, x11-apps currently recommends xbitmap, which does not exist
 > and is probably a typo of xbitmaps.

Per Debian changelog, this was fixed in 7.7~1.  I don’t seem
to see what else could be done for this issue, and thus suggest
to close this bug.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#746732: x11-apps: unable to edit with bitmap

[Ivan Shmakov]

Control: notfound -1 7.7+7

> On 2014-05-03 01:56:09 +0200, Frédéric Baldit wrote:

 > Package: x11-apps
 > Version: 7.5+5
 > Severity: normal

 > bitmap seems to work, but clicking the bitamp to edit/create an image
 > doesn’t work.

 > Found bug #429345 with same symptoms, but I was unable to fix the
 > problem (tried to reinstall x11-apps package).  I have another PC
 > with debian testing running and the problem is the same.

I don’t seem to be able to reproduce this problem with either
7.7+7 (Buster, with *customization: -color) or 7.7+8 (Bullseye,
without).  My guess is that it got fixed somewhere along the way
(say, with the introduction of bitmap 1.0.8 in 7.7+5.)

I suppose this bug can now be closed.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#959027: swi-prolog-nox: compiler and runtime execution shipped in same package

[Ivan Shmakov]

> On 2020-05-04 14:54:15 +0500, Lev Lamberov wrote:

 > I can upload swi-prolog with these changes right after it is processed
 > in NEW.  Anyway I should add Breaks and Replaces to make updating from
 > older versions smooth.

While we’re at it, could you please consider also downgrading
swi-prolog-core-packages’ dependency on libjs-jquery to
Recommends:?  As far as I can tell, it’s only used by the
integrated HTTP server, and even then it’s only served to
clients, not actually executed by the Prolog system itself.

TIA.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#960145: Description: is misleading with regards to jwm having few dependencies

[Ivan Shmakov]

Package: jwm
Version: 2.3.6-1
Severity: wishlist

The package Description: currently (2.3.7-3) reads:

 JWM is a window manager for the X11 Window System. JWM is written in C
 and uses only Xlib and (optionally) the shape extension and libXpm. […]

However, as of 2.3.6-1 (stretch), the jwm Debian package is
built with SVG support, which adds considerably to its footprint.

I actually have two requests regarding this situation:

 a. could the description of the package please be fixed to
mention that

 This JWM package is built with support for the full suite of supported
 image formats, including JPEG, PNG, SVG and XPM; as well as Xinerama
 and Xrender extensions, and FreeType-based font rendering.

 b. an alternative jwm-tiny package is provided with the minimal
set of dependencies (in the spirit of vim-tiny.)

TIA.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#960133: downgrade dependencies on libgl1-mesa-dri to Recommends:

[Ivan Shmakov]

Package: libglx-mesa0
Version: 18.3.6-2+deb10u1
Control: found -1 19.3.3-1
Severity: wishlist

So far as I can tell, the usage of the DRI modules provided by
libgl1-mesa-dri by libglx-mesa0 is either optional or dependent
on the context.  At the very least, circumventing these
dependencies produces no apparent ill effects with the packages
transitionally dependent on libglx-mesa0, such as x11-utils,
xvfb (via libgl1), and so on.

Given that the libgl1-mesa-dri package brings in some 60‒70 MB
of Installed-Size: due to libllvm alone – and also on headless
systems which cannot possibly benefit from having DRI modules
available – could the dependency on libgl1-mesa-dri please be
downgraded to Recommends:?


Background

I’m concerned with, specifically, the amount of runnable code in
the (base) system – and its implications on security.  I assume
that /not/ having some package installed is ought to be the
ultimate guarantee that no security flaw in said package is going
to affect a given system.  Hence is my interest in minimalistic
Debian installs.

As a workaround, I’ve installed an otherwise empty Provides:
libgl1-mesa-dri package [1], produced with nope.sh [2], like:

$ fakeroot -- nope  libgl1-mesa-dri 

[1] http://am-1.org/~ivan/dist/no-libgl1-mesa-dri_0.1_all.deb
[2] http://am-1.org/~ivan/src/nope.sh

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#960130: downgrade dependencies on libnl to Recommends:

[Ivan Shmakov]

Package: quota
Version: 4.04-2+deb10u1
Severity: wishlist

[I’ve checked that this bug affects 4.05-1 as well.  Due to a
separate problem, already AFAICT fixed upstream, the workaround
suggested below does /not/ work for the version in testing.]

The (versioned) dependencies on libnl-3-200, libnl-genl-3-200
currently specified by the quota package are only relevant to
the single quota_nld binary.  As circumventing these dependencies
produces no apparent ill effects when using the rest of the
package, could they please be downgraded to Recommends:?  (Note
that per the CTTE decision recorded in Debian Bug#119517, slight
breakage due to missing Recommends: is considered acceptable.)

Alternatively, could the binary in question please be moved off
to a separate binary package?

TIA.


Background

I’m concerned with, specifically, the amount of runnable code in
the (base) system – and its implications on security.  I assume
that /not/ having some package installed is ought to be the
ultimate guarantee that no security flaw in said package is going
to affect a given system.  Hence is my interest in minimalistic
Debian installs.

As a workaround, I’ve installed two otherwise empty packages that
specify versioned Provides: on libnl-3-200 and libnl-genl-3-200,
both (= 3.2.7), respectively [1‒2].  The packages were produced
with nope.sh [3], like:

$ fakeroot -- nope  libnl-3-200=3.2.7 ; \
  fakeroot -- nope  libnl-genl-3-200=3.2.7 

[1] http://am-1.org/~ivan/dist/no-libnl-3-200_0.1_all.deb
[2] http://am-1.org/~ivan/dist/no-libnl-genl-3-200_0.1_all.deb
[3] http://am-1.org/~ivan/src/nope.sh

Note that in 4.05-1, /all/ the binaries are made to link with
/all/ the libraries, thus making the workaround above unsuitable.
This upstream bug has since been fixed:

commit 00d61f21bfa3ccf40826ce22de12cfeeab8a40a5
Author: Dmitry V. Levin 
AuthorDate: 2019-04-01 02:23:59 +0300
Commit: Jan Kara 
CommitDate: 2019-04-01 17:11:11 +0200

Revert "configure.ac: fix pkg_check_modules calls"

CFLAGS and LIBS are variables that users are entitled to modify in order
to compile the package, so do not tamper with CFLAGS and LIBS.

COM_ERR_CFLAGS, EXT2FS_CFLAGS, DBUS_CFLAGS, LIBNL3_CFLAGS, TIRPC_CFLAGS,
COMM_ERR_LIBS, EXT2FS_LIBS, DBUS_LIBS, LIBNL3_LIBS, and TIRPC_LIBS
should be used directly where appropriate and apparently they already
are.

This reverts commit b54d97d677481287faa5d6b98c92f41c1af3.

Signed-off-by: Dmitry V. Levin 
Signed-off-by: Jan Kara 

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#923801: RFP: iceweasel-uxp -- Firefox XUL (pre-Quantum) fork from Hyperbola

[Ivan Shmakov]

Package:  wnpp
Severity: wishlist

Please package Iceweasel-UXP, a Firefox fork maintained as part
of the Hyperbola distribution [1].

[1] https://wiki.hyperbola.info/doku.php?id=en:project:iceweasel-uxp

I suppose that begs for an explanation, now doesn’t it?

While I’m not in position to judge on the pro’s and cons. of
various extension interfaces contemporary full-weight browsers
implement (I’ve contemplated writing a rather trivial Firefox
extension several years ago, and was never able to figure out
why they seem to demand a whole directory structure for what’s
ought to be a few dozen LoC), I note that several Firefox
extensions that I’ve used pretty much died out as the result of
the transition from XUL to the newer WebExtensions API.  E. g.:

• xul-ext-classic-theme-restorer – the author has claimed that
  it cannot be implemented as a WebExtension and suggested that
  userChrome.js is modified instead (say, [2]); unless I be
  mistaken, this requires restarting Firefox for the edits to
  take effect, which makes customization far more cumbersome
  that it used to be, and that (IMO) it has any right to be;

• xul-ext-certificatepatrol – likewise, but no alternative
  suggested [3];

• xul-ext-zotero – has been replaced by the zotero-standalone
  package.

Of course, there’re several other free XUL (UXP) browsers [4],
such as Pale Moon (RFP Bug#780379.)  Unfortunately, its
upstream’s insistence on embedding a number of libraries (with
browser-specific patches applied to them) will likely make it a
major headache to the Debian Security Team.  I suppose Basilisk
(by the same team) also has some of this problem.

To conclude, as a long-time user of GNU Emacs, I believe that
having a full-weight browser that offers Emacs-class extensibility
will be beneficial to Debian users.  So far as I can tell,
Iceweasel-UXP is the closest option to this goal there is.

[2] 
https://web.archive.org/web/20171226180650/https://addons.mozilla.org/en-US/firefox/addon/classicthemerestorer/
[3] http://patrol.psyced.org/
[4] http://thereisonlyxul.org/

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#768939: startpar: obsolete conffiles /etc/init/startpar-bridge.conf

[Ivan Shmakov]

> Dmitry Bogatov  writes:

 >> /etc/init/startpar-bridge.conf aab4f8aed4d4803ba1f6d97f6b1152da
 >> obsolete

 >> Please use the dpkg-maintscript-helper support provided by
 >> dh_installdeb to remove these obsolete conffiles on upgrade.

 > I believe following patch would solve issue.  I published it at
 > https://salsa.debian.org/debian/startpar at branch `bug-768939'.
 > Opinions?

[…]

 > +++ b/debian/startpar.postinst
 > @@ -0,0 +1,3 @@
 > +#!/bin/sh -eu
 > +#DEBHELPER#
 > +dpkg-maintscript-helper rm_conffile /etc/init/startpar-bridge.conf 
 > 0.61~beta-1~ startpar -- "$@"

[…]

I’m not going to claim I’m that familiar with Debian packaging
practices, but wouldn’t .postinst alone be enough?  .postrm
isn’t going to do anything if .postinst has already removed the
file, and there seem to be nothing to warrant a .preinst, either.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#913638: Please, Depends: info-browser | info

[Ivan Shmakov]

> Sébastien Villemot  writes:
> Le mardi 13 novembre 2018 à 10:50 +, Barak A. Pearlmutter a écrit :

 >> Package: octave-doc: Version: 4.4.1-2

 >> The octave-doc “Depends: info” have an ”| info-browser”, which is
 >> provided by info but also by GNU Emacs.

 > The “info-browser” alternative has been dropped on purpose.  See
 > #543914 for the background.

To quote:

 TW> Switching to infobrowser is not possible.  Octave uses some
 TW> switches specific to info (and maybe other info browsers):

 TW> octave:1> info_program("/usr/bin/pinfo")
 TW> octave:2> doc root
 TW> Przemek's Info Viewer v0.6.9
 TW> /usr/bin/pinfo: unrecognized option '--directory'
 TW> /usr/bin/pinfo: unrecognized option '--index-search'

I’d like to point out that GNU Emacs comes with an ‘inferior-octave’
mode, and it’s entirely reasonable that those who do use it will
also rely on Emacs’ own M-x info reader in place of the Octave’s
own ‘doc’ command – which I believe will not work when called from
within inferior-octave anyway.

However, given that an arbitrary ‘info-browser’ can not, in fact,
be substituted for ‘info’ proper, I suggest that the dependency
on ‘info’ is downgraded to Recommends:, as opposed to a
“non-working” alternative being added to it.  (“The Recommends
field should list packages that would be found together with
this one in all but unusual installations.” — Policy 7.2.)

That parts of the package (or, as in this case, – a different,
even if related, package) break when a Recommends: dependency is
not installed is, to the best of my knowledge, deemed permissible;
see the TC ruling in Bug#119517, for instance; to quote:

  IJ> 1. It is generally bad for programs to fail due to run-time
  IJ>linkage failures, in most cases.  There may however be other
  IJ>tradeoffs involved that make this a reasonable choice.

  IJ> 2. In this particular case, splitting the package introduces a
  IJ>level of administration and other overhead which outweighs the
  IJ>minor ugliness of the run-time linker error message.

Also, ‘info-browser’ should probably be mentioned in Suggests: –
as an alternative to www-browser and pdf-viewer.

TYC.

-- 
FSF associate member #7257  np. Wonderland — Tren

Bug#827395: [privacy] not as 'secure by default'

[Ivan Shmakov]

> Narcis Garcia  writes:

 > Note: trek.eu.org link provided by Trek is not working.

I’ve just checked and [1] does work for me.  (Note though that
‘www’ has to be there.)  An archived copy [2] is also available.

[1] http://www.trek.eu.org/text/firefox-tuning.html
[2] 
https://web.archive.org/web/20170411151300/http://www.trek.eu.org/text/firefox-tuning.html

 > Why a non-private browsing?  User activity should be assumed as
 > private by default.

Or at least there should be an easier (and more prominently
presented) way for the user to opt out.

 > Proposed defaults:

 > browser.newtabpage.directory.ping = ""
 > browser.newtabpage.directory.source = ""

Personally, I’ve disabled all the ‘safebrowsing’, ‘update’, and
similar options I could find.  Also, just to be sure, I’ve
uniformly replaced nearly every single URI in prefs.js like:

user_pref("browser.safebrowsing.provider.mozilla.updateURL", 
"http://browser.safebrowsing.provider.mozilla.updateurl.unwanted.nowhere.invalid/;);

Now I can refer to my HTTP proxy logs for the possible attempts
to disclose my use of Firefox to third parties (like my ISP,
employer, and whatever the entity it tries to connect to.)

Which seem to be surprisingly few (and the last one below is due
to xul-ext-noscript, not Firefox proper):

browser.newtabpage.directory.source
browser.safebrowsing.provider.mozilla.updateurl
browser.search.geoip.url
extensions.blocklist.url
noscript.abe.wanipcheckurl

Can at least the ‘safebrowsing’ one please be fixed to respect
the whatever ‘browser.safebrowsing.*.enabled = false’ setting
applicable?  Can there be also options to cleanly disable the
‘newtabpage.directory’ and ‘search.geoip’ functions as well?

TIA.

 > captivedetect.canonicalURL = ""
 > app.update.url = ""
 > browser.safebrowsing.downloads.remote.url = ""

[…]

 > browser.safebrowsing.reportPhishURL = ""
 > browser.search.geoSpecificDefaults.url = ""
 > browser.search.geoip.url = ""

I think it should also include browser.search.suggest.enabled =
false, which appears rather important as “search suggestions”
result in even the partial input being communicated to a remote
party.  (Which may even be a genuinely sensitive information –
like one’s password – by the way of pure accident.)

It’s basically Firefox’ very own remote keyboard logger!

 > browser.tabs.crashReporting.sendReport = false
 > datareporting.healthreport.service.enabled = false
 > datareporting.healthreport.uploadEnabled = false
 > datareporting.policy.dataSubmissionEnabled = false
 > security.ssl.errorReporting.enabled = false
 > security.ssl.errorReporting.url = ""
 > security.ssl.errorReporting.automatic = ""
 > browser.startup.homepage = "https://start.duckduckgo.com/;

I believe it should rather be about:blank, file:/, or something
like that – not requiring any network access whatsoever.

 > devtools.gcli.imgurUploadURL = ""

[…]

 > devtools.webide.templatesURL = ""
 > experiments.manifest.uri = ""
 > geo.wifi.uri = ""
 > identity.mobilepromo.android = ""
 > identity.mobilepromo.ios = ""
 > security.ssl.errorReporting.url = ""
 > toolkit.telemetry.server = ""
 > webextensions.storage.sync.enabled = false

-- 
FSF associate member #7257  http://am-1.org/~ivan/7D17 4A59 6A21 3D97 6DDB

Bug#832730: reassign 832730 to open-infrastructure-system-boot

[Ivan Shmakov]

> Raphaël Hertzog  writes:

 > reassign 832730 open-infrastructure-system-boot thanks

Isn’t the bug now fixed there?

I’m unsure of what difference there’s supposed to be between
live-boot and open-infrastructure-system-boot, but just in case
anyone’s interested, it was easy to port the option’s support
from the latter to the former.

(Perhaps a clone of this bug should be made for the other
package?)

-- 
FSF associate member #7257  http://am-1.org/~ivan/7D17 4A59 6A21 3D97 6DDB
--- lib/live/boot/-9990-cmdline-old.~2017-08-04~	2017-08-03 09:44:03.156091782 +
+++ lib/live/boot/9990-cmdline-old	2017-08-04 07:17:55.647244608 +
@@ -100,6 +100,11 @@
 export LIVE_MEDIA
 ;;
 
+			live-media-mount-opts=*)
+LIVE_MEDIA_MOUNT_OPTS="${_PARAMETER#*=}"
+export LIVE_MEDIA_MOUNT_OPTS
+;;
+
 			live-media-encryption=*|encryption=*)
 LIVE_MEDIA_ENCRYPTION="${_PARAMETER#*=}"
 export LIVE_MEDIA_ENCRYPTION
--- lib/live/boot/-9990-misc-helpers.sh.~2017-08-04~	2017-08-03 09:43:55.115584744 +
+++ lib/live/boot/9990-misc-helpers.sh	2017-08-04 06:53:25.799726442 +
@@ -98,6 +98,7 @@
 	sysdev="${1}"
 	devname="${2}"
 	skip_uuid_check="${3}"
+	mount_opts="${LIVE_MEDIA_MOUNT_OPTS:-ro,noatime}"
 
 	# support for fromiso=.../isofrom=
 	if [ -n "$FROMISO" ]
@@ -195,7 +196,7 @@
 	then
 		devuid=$(blkid -o value -s UUID "$devname")
 		[ -n "$devuid" ] && grep -qs "\<$devuid\>" /var/lib/live/boot/devices-already-tried-to-mount && continue
-		mount -t ${fstype} -o ro,noatime "${devname}" ${mountpoint} || continue
+		mount -t ${fstype} -o "${mount_opts}" "${devname}" ${mountpoint} || continue
 		[ -n "$devuid" ] && echo "$devuid" >> /var/lib/live/boot/devices-already-tried-to-mount
 
 		if [ -n "${FINDISO}" ]
@@ -204,10 +205,10 @@
 			then
 umount ${mountpoint}
 mkdir -p /live/findiso
-mount -t ${fstype} -o ro,noatime "${devname}" /live/findiso
+mount -t ${fstype} -o "${mount_opts}" "${devname}" /live/findiso
 loopdevname=$(setup_loop "/live/findiso/${FINDISO}" "loop" "/sys/block/loop*" 0 "")
 devname="${loopdevname}"
-mount -t iso9660 -o ro,noatime "${devname}" ${mountpoint}
+mount -t iso9660 -o "${mount_opts}" "${devname}" ${mountpoint}
 			else
 umount ${mountpoint}
 			fi

Bug#868453: xorg log flooded by dbus messages

[Ivan Shmakov]

>>>>> Ivan Shmakov <i...@siamics.net> writes:
>>>>> Trek <tre...@inbox.ru> writes:

 >> Version: 2:1.16.4-1+deb8u1+b1

 >> with the latest update, the dbus dependency is gone and the error
 >> message is no more printed to the log

 > I’m observing the same issue on Stretch (2:1.19.2-1+deb9u1.)

[…]

Any progress on this one?

(I guess it’s the same bug as [1], reported over a year ago.)

[1] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1562610
Bug #1562610 “/var/log/Xorg.0.log gets flooded with “(EE) dbus-…” 

Curiously, while the Debian changelog indicates that
libdbus-1-dev became a build dependency back in 2:1.3.99.0-1
(2007), I don’t recall ever observing this specific issue.

Sure, it’s only 191 octets every 10 seconds, but in a month,
that easily becomes over 40 MiB:

-rw-r--r-- 1 root root 44581359 Oct  3 13:33 /var/log/Xorg.1.0.log 
14757  4672 tty11Ssl+ 355988 32540 Wed Sep  6 10:20:46 2017 /usr/lib/xorg…

As a workaround, I was able to use the simplistic Perl server
MIMEd that accepts connections on the socket, receives a single
“message,” and closes the connection.  As it seems, it’s enough
for the library to consider it a “success” and stop complaining.

-- 
FSF associate member #7257  http://am-1.org/~ivan/7D17 4A59 6A21 3D97 6DDB
#!/usr/bin/perl
### nodbus.perl  -*- Perl -*-
## Listen on the D-Bus socket; accept, discard, and close.

### Ivan Shmakov, 2017

## To the extent possible under law, the author(s) have dedicated
## all copyright and related and neighboring rights to this software
## to the public domain worldwide.  This software is distributed
## without any warranty.

## You should have received a copy of the CC0 Public Domain Dedication
## along with this software.  If not, see
## <http://creativecommons.org/publicdomain/zero/1.0/>.

### Code:

use common::sense;
use English qw (-no_match_vars);

require Socket;

my $socket_filename
= ($ARGV[0] // "/run/dbus/system_bus_socket");
socket (SERVER, ::AF_UNIX, ::SOCK_STREAM, ::PF_UNSPEC)
and bind (SERVER, Socket::sockaddr_un ($socket_filename))
or die ("Server: ", $!);

listen (SERVER, 5)
or die ("listen: ", $!);

$SIG{"CHLD"}
= "IGNORE";

while (accept (CLIENT, SERVER)) {
my $pid
	= fork ();
die ("fork: ", $!)
	unless (defined ($pid));
if ($pid == 0) {
	binmode (CLIENT);

	my $s;
	recv (CLIENT, $s, 65536, 0)
	or die ("recv: ", $!);

	exit (0);
}

close (CLIENT);
}

### nodbus.perl ends here

Bug#868453: xorg log flooded by dbus messages

[Ivan Shmakov]

Control: reopen -1
Control: found -1 2:1.19.2-1+deb9u1

> Trek  writes:

 > Version: 2:1.16.4-1+deb8u1+b1

 > with the latest update, the dbus dependency is gone and the error
 > message is no more printed to the log

 > thank you!

I’m observing the same issue on Stretch (2:1.19.2-1+deb9u1.)

I guess that the fix for Debian Bug#867492 (per DSA-3905-1)
affected Stretch just as well.  Could this please be rectified?

TIA.

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Bug#872361: mpg123 misparses IPv6 address + port in http_proxy

[Ivan Shmakov]

> Thomas Orgis  writes:

 > I prepared fixes for both bug 872362 and 872361 for an upcoming
 > mpg123 version 1.25.7.  A preliminary release tarball is available
 > via

 > https://mpg123.org/test/mpg123-1.25.7.tar.bz2

[…]

 > Ivan, can you test your two issues with the preliminary release and
 > give feedback before I make it official?

The IPv6 http_proxy= handling seems to be the other way around
now; for instance:

$ http_proxy=http://ip6-localhost:9993/ \
  LD_LIBRARY_PATH=src/libout123/.libs ./src/mpg123 \
  -- http://stream.chipbit.net:8000/autodj.m3u 
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.25.7; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes
HTTP request failed: 404 Not Found
main: [src/mpg123.c:686] error: Access to http resource 
http://stream.chipbit.net:8000/autodj.m3u failed.
$ http_proxy=http://\[::1\]:9993/ \
  LD_LIBRARY_PATH=src/libout123/.libs ./src/mpg123 \
  -- http://stream.chipbit.net:8000/autodj.m3u 
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.25.7; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes

Directory: http://stream.chipbit.net:8000/

Terminal control enabled, press 'h' for listing of keys and functions.

Playing MPEG stream 1 of 1: autodj.m3u ...
ICY-NAME: ChipBit
ICY-URL: http://chipbit.net

MPEG 1.0 L III cbr128 44100 j-s

ICY-META: StreamTitle='General Offensive, Mrsonic699 - Insert Cartridge 
[Prelude]';
...

(Note that there's also an HTTP server on TCP port 80, which is
not configured as a proxy.)

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Bug#873919: make dpkg-buildpackage default locale UTF-8

[Ivan Shmakov]

> Hans-Christoph Steiner  writes:

 > Package: dpkg-dev

 > More and more packages are adding unicode files

I assume you mean “UTF-8 filenames” here (per below), right?

 > as unicode support has become more reliable and available.

What are the use cases for such filenames?

FWIW, I more than just occasionally use Debian in environments
with fonts lacking good (as in: ≥ 90%) Unicode, or even BMP,
coverage.  (Specifically, I’m for the most part interested in
Latin-1, -3, and Cyrillic characters only.)

Do you suggest that there’re filenames in Debian packages that
cannot be rendered in such environments?  If so, that’d
certainly be a nuisance for me.

 > The package building process is not guaranteed to happen in a unicode
 > locale since the Debian default locale is LC_ALL=C, which is ASCII
 > not UTF-8.  Reading UTF-8 filenames when the system is using ASCII
 > causes errors (Python makes them very visible, for example).

[…]

-- 
FSF associate member #7257  np. Fear of the Dark — Iron Maiden  B6A0 230E 334A

Bug#872466: downgrade fbi dependency on ghostscript to Recommends:

[Ivan Shmakov]

Package:  fbi
Version:  2.10-2+b3

As I understand it, the only reason fbi Depends: on ghostscript
is to allow for viewing PDF (and PostScript) files ($ fbgs?),
and the lack of ghostscript does not affect users interested in
any of the other supported formats (PNG, JPEG, etc.) in any way.

I’ve been able to successfully and to no apparent ill effects
circumvent this dependency by installing first an otherwise
empty package that Provides: ghostscript, saving about 30 MiB of
filesystem space (in a somewhat tight already environment) as
the result.

Please thus downgrade the fbi dependency on ghostscript to
Recommends:.

(If needed, and if it’s not the case already, I may try to come
up with a patch so that invoking $ fbgs without ghostscript
available will result in an error message suggesting that the
user should install the ghostscript package to use fbgs.)

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Bug#872361: mpg123 misparses IPv6 address + port in http_proxy

[Ivan Shmakov]

Package:  mpg123
Version:  1.23.8-1+b1

It appears that mpg123(1) fails to notice the :PORT suffix when
parsing an http_proxy value that contains an IPv6 address.

Consider, e. g.:

$ http_proxy=http://\[::1\]:8080/ \
  strace -o "$(mktemp -- /tmp/strace.)" -- \
  mpg123 --test -- http://stream.chipbit.net:8000/autodj.m3u 
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
version 1.23.8; written and copyright by Michael Hipp and others
free software (LGPL) without any warranty but with best wishes
HTTP request failed: 404 Not Found
main: [src/mpg123.c:709] error: Access to http resource 
http://stream.chipbit.net:8000/autodj.m3u failed.
$ 

The strace(1) output reveals that mpg123(1) tries to connect to
the default HTTP port (80), not the one specified (8080):

connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::1", 
_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0

Also to note is that using an (IPv6-only) name (as shown below)
in place of the IPv6 address does not cause the issue.

$ http_proxy=http://ip6-localhost:8080/ \
  mpg123 --test -- http://stream.chipbit.net:8000/autodj.m3u 

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Bug#872362: mpg123 disables cursor unconditionally on ttys

[Ivan Shmakov]

Package:  mpg123
Version:  1.23.8-1+b1
Severity: wishlist

After upgrading to the version in Stretch, mpg123(1) appears to
make the terminal cursor invisible by issuing a ‘civis’ (as in:
$ tput civis) control sequence to a tty, which goes against my
preferences.

Moreover, mpg123(1) does not seem to consult Terminfo for the
terminal-specific sequence, probably using a hardcoded one
instead – which prevents an obvious workaround from working:

$ TERM=dumb mpg123 -- audio.mp3 
(Cursor becomes invisible even though Terminfo lists no civis
sequence for TERM=dumb, per $ infocmp -- dumb.)

The --no-control option has no effect on this behavior, either.

A workaround that does work is to pipe mpg123(1) standard output
and error devices via cat(1), like:

$ mpg123 -- audio.mp3 2>&1 | cat 

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Bug#866307: Play it safe: comment out SIGKILL (-9) in default and.priorities(5)

[Ivan Shmakov]

Package:  and
Version:  1.2.2-4.1+b2

It does not seem like a good idea to have and(8) send SIGKILL
to /any/ processes by default – not even to ones named ‘gcc’ and
which run for 20 minutes.

Thus, I believe that the respective lines in the default
and.priorities(5) file should be commented out.

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Bug#866246: jdupes -B fails to fully deduplicate large (> 16 MiB) files

[Ivan Shmakov]

Package:  jdupes
Version:  1.7-2
Severity: minor

As currently implemented, jdupes(1) invokes FIDEDUPERANGE once
for each set of files found to be duplicates.  However, per
documentation (say, [1]), there can be a filesystem-specific
limit in place on how large a data span can be handled in a
single call to FIDEDUPERANGE.  Per strace(1) output, this limit
appears to indeed be 16 MiB for Btrfs on Debian Stretch.

An obvious solution is to get the maximum of the bytes_deduped
values returned by the call and invoke it again, advancing
src_offset and dest_offset values by that maximum, possibly
repeating these steps until the whole file length is covered.

AFAICT, this issue is not solved as of recent Git (a32de0db,
2017-06-07.)

[1] http://man7.org/linux/man-pages/man2/ioctl_fideduperange.2.html

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Bug#859890: savelog(8): -D documentation does not match the actual effect

[Ivan Shmakov]

Package:  debianutils
Version:  4.8.1
Severity: minor
Tags: patch

As currently implemented, the -D option does not match its
documentation.  Specifically, savelog(8) reads:

-D dateformat
override date format, in the form of [MMDDhhmm[[CC]YY][.ss]]

While in fact -D argument is passed to date(1) ‘+’ (see below),
and as such follows (a superset of) the strftime(3) format.

$ nl -ba < savelog 
…
87  DOT_Z=".gz"
88  DATUM=`date +%Y%m%d%H%M%S`
89  
…
   153  d) datum=1 ;;
   154  D) DATUM=$(date +$OPTARG) ;;
   155  t) touch=1 ;;

On a related note, while savelog has some extraneous quoting in
assignments (a="$b" is no different to a=$b), the lack of double
quotes around $OPTARG above means trouble.

Please thus consider the patches MIMEd.

  * savelog.8: Refer to date(1) for -D option format.  closes: #XXX.
  * savelog: Fix missing quotes around -D option argument.

-- 
FSF associate member #7257  np. На дальней станции сойду — Гражданская Оборона
--- a/savelog.8
+++ b/savelog.8
@@ -135,8 +135,13 @@
 use standard date for rolling
 .TP
 .B "\-D dateformat"
-override date format, in the form of
-.I [MMDDhhmm[[CC]YY][.ss]]
+override date format, in the form accepted by
+.BR date (1)
+(default:
+.BR "%Y%m%d%H%M%S" ","
+provided
+.B -d
+is used)
 .TP
 .B \-r
 use
--- a/savelog
+++ b/savelog
@@ -151,7 +151,7 @@ while getopts m:u:g:c:r:CdD:tlphjJ123456789x:nq opt ; do
 	r) rolldir="$OPTARG" ;;
 	C) forceclean=1 ;;
 	d) datum=1 ;;
-	D) DATUM=$(date +$OPTARG) ;;
+	D) DATUM=$(date +"$OPTARG") ;;
 	t) touch=1 ;;
 	j) COMPRESS="bzip2"; COMPRESS_OPTS="-f"; COMPRESS_STRENGTH_DEF="-9"; DOT_Z=".bz2" ;;
 	J) COMPRESS="xz"; COMPRESS_OPTS="-f"; COMPRESS_STRENGTH_DEF=""; DOT_Z=".xz" ;;

Bug#859749: groupmems(8): non-localized manual page unavaliable

[Ivan Shmakov]

Package: passwd
Version: 1:4.4-4
Tags:patch

As it seems, when /usr/sbin/groupmems was added to the package
this January, the /usr/share/man/man8/groupmems.8.gz
(non-localized) manual page somehow didn’t make it into
debian/passwd.install.

Please thus consider the patch MIMEd.

PS.  I guess that the file /does/ get built, albeit I didn’t actually
check it.

-- 
FSF associate member #7257  np. Montsegur — Iron Maiden3013 B6A0 230E 334A
--- debian/passwd.install~	3b66774757144d375672775dc5197a463e3938c1
+++ debian/passwd.install
@@ -66,6 +66,7 @@
 usr/share/man/man8/groupadd.8
 usr/share/man/man8/groupdel.8
 usr/share/man/man8/groupmod.8
+usr/share/man/man8/groupmems.8
 usr/share/man/man8/grpck.8
 usr/share/man/man8/grpconv.8
 usr/share/man/man8/grpunconv.8
shadow (1:4.4-2) unstable; urgency=medium

…

  [ Christian Perrier ]
  * Fix typos in login.pam (thanks to Jakub Wilk for reporting)
(Closes: #747115)
  * Include groupmems(8) in the passwd package (Closes: #663117)
…

 -- Balint Reczey   Thu, 19 Jan 2017 18:22:49 +0100

Bug#853102: libgpgme11: downgrade gnupg2 (gnupg) dependency to Recommends:

[Ivan Shmakov]

Package:  libgpgme11
Version:  1.5.1-6
Severity: minor

[Apologies for not actually checking if the problem described is
relevant to Debian testing.]

Package: libgpgme11
[…]
Depends: gnupg2 (>> 2.0.4), […]

I believe that libgpgme11 should NOT depend on gnupg2 – in the
same way that, say, libcurl3 does not depend on Apache, nor does
libpq5 depend on the PostgreSQL server package.

Assuming that packages depending on libgpgme11 do so
in order to provide GPGME /as an option/ (and to satisfy the
respective run-time ld.so dependency; as it appears to be in the
case of Mutt; see below), I suggest downgrading the dependency
to Recommends: (with Conflicts: also added if necessary.)

Long story short, I’ve recently tried to install Mutt on a
“headless,” tty-over-SSH-only server.  To my surprise, APT found
that it depends on libgtk2.0-0!  Thankfully, no, Mutt wasn’t
upgraded to provide a GUI; the problem was in the
‘pinentry-gtk2’ package – which is required by gnupg-agent,
which is in turn required by gnupg2, and thus libgpgme11.
(JFTR, I’m aware of pinentry-curses.)

To make things weirder, Mutt doesn’t even /use/ GPGME in its
default settings (whether upstream or Debian; see below); but of
course being built with such support, the binary (or, rather,
ld.so) requires the library to run.

To quote /usr/share/doc/mutt/manual.txt.gz:

3.44. crypt_use_gpgme

Type: boolean
Default: no

This variable controls the use of the GPGME-enabled crypto backends.  If it
is set and Mutt was built with gpgme support, the gpgme code for S/MIME and
PGP will be used instead of the classic code.  Note that you need to set
this option in .muttrc; it won’t have any effect when used interactively.

And indeed, providing an otherwise empty, “fake” gnupg2 package
[1] made it possible to install and use Mutt with no obvious ill
effects (using [2] as the test file.)  For instance:

• by default, ‘gpg’ command is used (per /etc/Muttrc.d/gpg.rc)
  directly for signature checking; no GPGME calls are
  (presumably) performed, hence little (if any) chance that the
  ‘gnupg2’ absence may affect Mutt operation in any way;

• when run with -e "set crypt_use_gpgme = yes", Mutt calls
  GPGME, which appears to call the ‘gpg’ command in turn –
  the one provided by the ‘gnupg’ (1.5.1-6) package in my case;

• finally, prepending also to PATH a directory containing ‘gpg’
  and ‘gpgconf’ symlinks to /bin/false makes Mutt fail
  gracefully when trying to verify OpenPGP signatures in the
  messages.

From the above, I conclude that ‘gnupg2’ is not strictly
necessary to run Mutt (and presumably other packages built with
GPGME support), and thus per [3] (quoted below) should be
requested with Recommends: rather than Depends:.

This issue is perhaps less relevant to Debian testing, as there
GnuPG 2 finally replaced GnuPG 1.  Still, it’s possible to rely
on the ‘gpgv’ package for OpenPGP signature validation (just as
‘apt’ does), and avoid the use of the full-weight ‘gnupg’
package.  So, I would suggest using Recommends: for the
dependency there too.

[1] http://am-1.org/~ivan/dist/gnupg2_2.0.26-6+deb8u1_all.deb
SHA-256: 228ea1789f17e3a0fb81496327f76f1c95e740710dd147b005b5e8077aab1682
[2] 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430213;mbox=yes;mboxmaint=yes
[3] http://debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps

Depends

[…]

The Depends field should be used if the depended-on package is
required for the depending package to provide a significant
amount of functionality.

[…]

   Recommends

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found
together with this one in all but unusual installations.

-- 
FSF associate member #7257


signature.asc
Description: Digital signature

Bug#687781: nfs-utils updated to 1.3.4-1, please check your bug #687781

[Ivan Shmakov]

> Daniel Pocock  writes:

 > Thanks for providing a bug report for nfs-utils.
 > https://bugs.debian.org/687781

 > There are over 100 open bugs[1] in the nfs-utils package.

 > The package in Debian sid has recently been updated to v1.3.4-1.

 > The upstream changelog[2] indicates that many bugs have been fixed
 > since the version that you tried.

The suggestion I’ve made concerns the nfs-kernel-server.default
file, which is specific to Debian.  Namely:

  # If you have a port-based firewall, you might want to set up
  # a fixed port here using the --port option. For more information,
  # see rpc.mountd(8) or http://wiki.debian.org/SecuringNFS
  # To disable NFSv4 on the server, specify '--no-nfs-version 4' here
- RPCMOUNTDOPTS="--manage-gids"
+ RPCMOUNTDOPTS="--manage-gids --port=20048"

 > Can you please help reduce the number of bug reports so developers
 > can see which issues are really outstanding:

 > - if any other bug in the list[1] is a duplicate of yours, you can
 > send a “merge[3]” command to the bug server to link the bugs.

Looking for “port,” I was unable to any similar suggestions
there.

[…]

 > 1. 
 > https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=0;ordering=normal;repeatmerged=0;src=nfs-utils
 > 2. http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=shortlog
 > 3. https://www.debian.org/Bugs/server-control#merge

[…]

-- 
FSF associate member #7257  58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A

Bug#806507: union-mount-options: fails to handle ${CHROOT_UNION_OVERLAY_DIRECTORY}, etc.

[Ivan Shmakov]

Package: schroot
Version: 1.6.10-1+b1

schroot.conf(5) reads:

  union-mount-options=options

[…] Note: One can use the variables
“${CHROOT_UNION_OVERLAY_DIRECTORY}” and
“${CHROOT_UNION_UNDERLAY_DIRECTORY}” to refer to the writable
overlay session directory and read-only underlying directory which
are to form the union.

However, it looks like these (or any other, for that matter)
variables are never substituted within the code, and the value
of the ‘union-mount-options’ option is instead passed to
mount(8) “as-is”, leading to an error like:

Nov 28 06:30:49 crabs kernel: [938142.164904] aufs opt_add:714:mount[3093]: 
lookup failed ${CHROOT_UNION_OVERLAY_DIRECTORY} (-2)

As an (untested) workaround, the following code could be added
to either setup.d/10mount (do_mount_fs_union), or a file
processed prior to one.


CHROOT_UNION_MOUNT_OPTIONS=${CHROOT_UNION_MOUNT_OPTIONS//\${CHROOT_UNION_UNDERLAY_DIRECTORY\}/${CHROOT_UNION_UNDERLAY_DIRECTORY}}

CHROOT_UNION_MOUNT_OPTIONS=${CHROOT_UNION_MOUNT_OPTIONS//\${CHROOT_UNION_OVERLAY_DIRECTORY\}/${CHROOT_UNION_OVERLAY_DIRECTORY}}

(Per my reading of [1], the problem is not resolved as of the
current ‘master’.)

[1] https://github.com/codelibre-net/schroot/blob/master/etc/setup.d/10mount

-- 
FSF associate member #7257  http://am-1.org/~ivan/  … 3013 B6A0 230E 334A

Bug#790780: edisplay: possible memory leak

[Ivan Shmakov]

Package: edisplay
Version: 0.8.9-7+deb8u1

There seem to be a possible memory leak in edisplay(1).
Consider, e. g.:

$ edisplay \
upload.wikimedia.org/wikipedia/commons/2/24/Leberblümchen-Nahaufnahme.JPG \
upload.wikimedia.org/wikipedia/commons/8/87/Amanhecer_no_Hercules_--.jpg  
$ ps -o pid,stat,size,time,cmd -p $! 
  PID STAT  SIZE  TIME CMD
 2087 SLl  68724  00:00:00 edisplay storage/files/upload.wikimedia.org/wikipedi
$ 

Now, as I repeatedly hit SPC to switch between the two images,
the SIZE seem to rise indefinitely:

 2087 SLl  153984 00:00:01 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  148940 00:00:01 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  232428 00:00:02 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  233832 00:00:02 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  341172 00:00:03 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  318724 00:00:03 edisplay storage/files/upload.wikimedia.org/wikipedi
[VTs were switched sometime around this point.]
 2087 SLl  426064 00:03:38 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  390284 00:03:38 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  495016 00:03:38 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  472568 00:03:39 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  579908 00:03:39 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  557460 00:03:39 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  664800 00:03:40 edisplay storage/files/upload.wikimedia.org/wikipedi
 2087 SLl  629020 00:03:40 edisplay storage/files/upload.wikimedia.org/wikipedi

-- 
FSF associate member #7257  http://am-1.org/~ivan/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789175: gatling vs. smbclient: Incomplete multibyte sequence; SMB/CIFS broken

[Ivan Shmakov]

Package: gatling
Version: 0.13-5+b3

As it seems, SMB/CIFS support is currently broken.

Consider, e. g.:

$ grep -E -- ^\[^\#\]  /etc/default/gatling 
START_DAEMON=YES
DAEMON_OPTS=-p 8480 -v -d -s -F -U -u nobody -c /home/public -w WKGRP
DAEMON=gatling
$ smbclient -N -L ::1 
Conversion error: Incomplete multibyte sequence()
protocol negotiation failed: NT_STATUS_INVALID_PARAMETER
$ smbclient -N -L 127.0.1.2 
Conversion error: Incomplete multibyte sequence()
protocol negotiation failed: NT_STATUS_INVALID_PARAMETER
$ 

-- 
FSF associate member #7257  http://am-1.org/~ivan/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775436: ITP: xlennart -- An XBill fork but with Lennart and SystenD instead of Bill and Wingdows

[Ivan Shmakov]

 Axel Wagner m...@merovius.de writes:

[…]

  I don't think Lennart personally would care, no, but I think *we*
  should care to paint the Opensource community as better than this.

As a member of the said community, I think that, however the
presence of either of the packages in Debian paints it, –
I could live with that.

Regarding the possible enhancement of XBill to allow for using a
user-specified set of sprites (whether packaged or not), –
it certainly feels like a proper solution to me.  I guess the
package could then be enhanced to include several such “themes,”
including the “classic” one, the newly proposed one, and perhaps
a few more, depending on the availability and relevance.

  From that point of view, if there was a vote and I'd get a vote I
  would also vote against having xbill in the archive as being a poor
  taste ad-hominem attack (I mean, for crying out loud, there is an
  actually blood-spatter squashing animation in the game, even if it is
  a poor one).  In my opinion it is certainly not an argument to also
  let xlennart in.

While not a full-scale ad-hominem attack, I’d say that the two
differences I know of between the vrms operation and the
official FSF position amount to a misrepresentation at best.
Are we going to drop that package, too?

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763731: terminfo: linux (linux-basic: CP437), linux-vt entries vs. ACS support

[Ivan Shmakov]

 Thomas Dickey dic...@his.com writes:
 On Thu, Oct 02, 2014 at 08:51:32AM +, Ivan Shmakov wrote:

  Cc: 763731-submit...@bugs.debian.org

(No need to Cc: me, as I’m “on the list.”)

[…]

  As of the current version of the Terminfo database, the ‘linux’
  terminal entry implies the use of the CP437 encoding for the
  box-drawing characters and the like (also known as “alternate
  character set”, or ACS):

  This is hardly a safe assumption these days, especially taking into
  account the widespread use of UTF-8, /including/ on ttys.

  several comments.

  a) this should be merged with #515609

No objection on my part.

[…]

  d) this report does prescribe a change, but lacks the patch which is
  indicated in the flags.

The report surely /provides/ “… some other easy procedure for
fixing the bug”, as per http://www.debian.org/Bugs/Developer:

  patch

  A patch or some other easy procedure for fixing the bug is included
  in the bug logs.  If there’s a patch, but it doesn’t resolve the bug
  adequately or causes some other problems, this tag should not be
  used.

But I stand corrected, – the procedure I’ve suggested does /not/
resolve the bug, and thus this tag is indeed /not/ applicable.

Apparently, the proper “fix” for the issue is just to use the
‘linux2.6’ terminfo entry:

linux2.6|linux 2.6.x console,
rmacs=^O,

sgr=\E[0;10%?%p1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p5%t;2%;%?%p6%t;1%;m%?%p9%t\016%e\017%;,
sgr0=\E[m\017, smacs=^N, use=linux2.2,

I hereby suggest that, given that Debian currently only supports
Linux versions 2.6 or later, the ‘linux’ terminfo entry be made
synonymous to ‘linux2.6’.

  • move the current variants of the ‘acsc’, ‘smacs’, ‘rmacs’
capabilities from linux-basic to a dedicated linux-cp437 entry
(following the suit of linux-koi8, linux-koi8r, linux-lat);

… And I still think it makes sense to provide a dedicated
‘linux-cp437’ entry per the above, just in case.

[…]

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763731: terminfo: linux (linux-basic: CP437), linux-vt entries vs. ACS support

[Ivan Shmakov]

Source:   ncurses
Version:  5.9+20140913-1
Control:  affects -1  console-setup
Tags: patch
Severity: minor

As of the current version of the Terminfo database, the ‘linux’
terminal entry implies the use of the CP437 encoding for the
box-drawing characters and the like (also known as “alternate
character set”, or ACS):

$ nl -ba  misc/terminfo.src 
…
  1577  linux-basic|linux console,
  1578  am, bce, eo, mir, msgr, xenl, xon,
  1579  it#8, ncv#18, U8#1,
  1580  
acsc=+\020\,\021-\030.^Y0\333`\004a\261f\370g\361h\260i\316j\331k\277l\332m\300n\305o~p\304q\304r\304s_t\303u\264v\301w\302x\263y\363z\362{\343|\330}\234~\376,

(Read:  
acsc=+\020\,\021-\030.^Y0█`\004a▒f°g±h░i╬j┘k┐l┌m└n┼o~p─q─r─s_t├u┤v┴w┬x│y≤z≥{π|╪}£~■.
And no, that’s /not/ line noise.)

This is hardly a safe assumption these days, especially taking
into account the widespread use of UTF-8, /including/ on ttys.

(Please also note that the console-setup Debconf scripts will
assume UTF-8 mode for ttys provided that the locale is a UTF-8
one, – which, I believe, are default with D-I installs.)

There’s a separate ‘linux-vt’ entry that’s intended to be used
when the terminal encoding is not known, or non-unibyte, and
which emits ACS characters using VT100 ESC sequences instead:

  1678  # This uses graphics from VT codeset instead of from cp437.
  1679  # reason: cp437 (aka straight to font) is not functional under luit.
  1680  # from: Andrey V Lukyanov l...@long.yar.ru.
  1681  linux-vt|linux console using VT codes for graphics,
  1682  
acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz~~,
  1683  rmacs=\E(K, rmpch@, sgr@, sgr0=\E[0m\E(K\017, smacs=\E(0,
  1684  smpch@, use=linux,

Unfortunately, this entry misses the ‘enacs’ capability, so its
use doesn’t result in the proper ACS rendering, as in:

$ export TERM=linux-vt 
$ tput  enacs ; tput  smacs ; printf %s\\n lk mj ; tput  rmacs ; 
lk
mj

Expected:

┌┐
└┘

The /minimal/ solution for the issue is to fix the linux-vt
entry by adding the missing ‘enacs’ capability:

linux-vt|linux console using VT codes for graphics,
acsc=++\,\,--..00``aaffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz~~,
enacs=\E(B\E)0, rmacs=\E(K, rmpch@, sgr@, sgr0=\E[0m\E(K\017,
smacs=\E(0, smpch@, use=linux,

This could just as well be combined with explicitly passing
‘linux-vt’ to the getty(8) invocations in the default
/etc/inittab for the new GNU/Linux installations, – or similar
measures for the systems using different means to start up the
gettys.

The “proper” solution, in my opinion, is to:

• move the current variants of the ‘acsc’, ‘smacs’, ‘rmacs’
  capabilities from linux-basic to a dedicated linux-cp437 entry
  (following the suit of linux-koi8, linux-koi8r, linux-lat);

• replace them with the encoding-insensitive ‘acsc’, ‘smacs’,
  ‘rmacs’ variants from linux-vt, along with adding ‘enacs’ per
  above;

• the linux-vt entry is then to be cut down to just ‘use=linux’
  (and ‘sgr@’?), but otherwise retained for compatibility.

TIA.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763311: MTP and Moto G (ID 2)

[Ivan Shmakov]

Source:   libmtp
Version:  1.1.6-20-g1b9f164-1~bpo70+1
X-Debbugs-Cc: Cecil Westerhof ce...@decebal.nl, Michael Tokarev 
m...@tls.msk.ru

Per [1], libmtp 1.1.8-1 entered testing September, 17th.  Please
re-build it for wheezy-backports.

TIA.

[1] https://packages.qa.debian.org/libm/libmtp.html

 Cecil Westerhof ce...@decebal.nl writes:

  I have an interesting problem. Under my old OS (openSUSE) I could
  connect to my Moto G, but not to my Galaxy note.

  With Debian Wheezy (and backports) I can connect to my Galaxy Note,
  but not to my Moto G.  I get that my VID 22b8 with PID 2e82 are not
  recognised.  I should report them to the libmtp team.  But when I
  look at:

  http://sourceforge.net/p/libmtp/code/ci/HEAD/tree/src/music-players.h

  I see it defined on line 1837.  So the backport of wheezy contains an
  old libmtp.  How to get a more recent version?

In this case, it’s certainly worth filing a bug, as Debian
backports are intended to track Debian testing, and this
particular backport became out-of-date.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#762150: wget: dependencies suggestion

[Ivan Shmakov]

 westlake  westlake2...@videotron.ca writes:

  Package: wget
  Version: 1.13.4-3+deb7u1
  Severity: normal

  Since wget's description includes mentioning https perhaps
  ca-certificates should rather be a dependency than a recommendation?
  I noticed trying wget, there's no indication ca-certifcates should be
  used..  installing curl immediately solved the problem as it by
  default will install ca-certificates along with a number of other ssl
  packages.

This is a duplicate of #712540 [1], solved (in the current
development version of Debian, – BKA Jessie, or “testing”) back
last November.  See [2, 3].

[1] https://bugs.debian.org/712540
[2] https://packages.debian.org/jessie/wget
[3] 
http://metadata.ftp-master.debian.org/changelogs//main/w/wget/wget_1.15-1_changelog

  (fwiw, it's also not clear what packages are actually needed,
  ca-certificates is a recommendation but I think curl also requires
  libssl)

The ‘curl’ package Recommends: ca-certificates via its
‘libcurl3’ dependency.  As there’s no similar underlying library
for Wget, Recommends: ca-certificates was added to the ‘wget’
package directly.

(The default APT configuration is to install recommended
packages, unless the user explicitly chooses not to.)

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700500: a CyrEo fontset, please?

[Ivan Shmakov]

 Anton Zinoviev an...@lml.bas.bg writes:
 On Thu, Aug 07, 2014 at 06:57:49PM +, Ivan Shmakov wrote:

  This doesn't happen when framebuffer is used.

  Does that mean /dev/fb*, or rather the “kernel mode setting” (KMS)
  facility?

  The last time I’ve checked, – it wasn’t the case for KMS-enabled
  text VTs.  I wasn’t following this closely, though.

  All depends on the hardware mode of the videocard.  If the videocard
  is in graphic mode (i. e. the text mode is emulated by the kernel),
  then there is no color limitation.

There’s no /hardware-imposed/ limitation.  It’s still possible
that the kernel emulates this aspect of the traditional text
VTs, – which is, IIRC, what I experienced.  Again, this may have
since changed.

  On the other hand, if the videocard is in real text mode and the font
  is loaded in the videocard itself, then inevitably there is a color
  limitation.

Yes.

[…]

  That doesn’t seem like “supported” to me, as:

  • /usr is generally reserved for dpkg-maintained files; the “custom”
  ones belong to /usr/local instead;

  It is not difficult to add a support for /usr/local.  But since
  console-setup already searches for files in /etc/console-setup/ and
  supports absolute file names, I suppose this isn't really necessary.

I’d generally avoid storing such files under /etc, either, but
given that a symlink may be used instead, – it seems like a
reasonable place.  Thanks for the clarification.

  • by “custom fontsets support” I mean, specifically, that the user
  is provided a tool which locates user’s own fontsets (either in
  /etc/console-setup or somewhere under /usr/local, or perhaps passed
  via the command line) and generates the respective font files; alas,
  I don’t seem to see any such tool provided by either console-setup,
  console-setup-linux, or kbd packages.

  We shouldn't expect from the users to generate fonts.  This is an
  experienced task that should be done developers.

Why?

  It will be much more convenient if the users use fonts prepared by
  more experienced people.

FWIW, I find none of the fonts provided really convenient.
Which is why I filed this bug report in the first place.

  Now, let as think from the position of the font developer.  Do we
  require from him to prepare the fonts exactly according to the
  requirements of console-setup (codeset, fontface, fontsize)?  Well, I
  think this is too much work and the benefits – only moderate
  considering that console-setup is able to use any non-standard
  console fonts.  In fact, Debian already includes a few packages with
  non-standard console fonts (console-braille, psf-unifont, fonty-rg).
  None of these packages follows the standards of console-setup and
  there is no need for this – it is much more convenient to use a
  simple instruction FONT=... than to think in terms of codeset,
  fontface and fontsize.

To clarify, – the idea is not to force the console-setup
requirements onto a font designer, but to provide an easy way
for the user to tailor any font with more than 256 glyphs to his
or her own requirements.

Basically, instead of shipping .psf files, my suggestion is to
provide the source .bdf(s), along with the means to create – as
part of the package configuration – a .psf for any given “font
set” – either defined by Debian, or by the user him- or herself.

The resulting .psf files will then belong to /var/cache, and are
to be generated at the package configuration time.

This is not going to be much different to, say, how the
‘locales’ package currently behaves – as compared to
‘locales-all’.

One constraint worth of imposing on the user-defined font sets
is that all the 95 printable ASCII characters (U+0020 through
U+007E) are represented, – which leaves up to 161 font code
points for the user to define.  Similarly to how the font sets
are currently dealt with at the package build time, the “unused”
code points are to be assigned to miscellaneous punctuation,
such as U+00AB, U+00BB («, »), U+00B7 (·), U+2020 (†), etc.

Other than that, the logic remains virtually the same.
It’s just that .psf generation is to happen when the package is
configured, – instead (or in addition to) when it’s built.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700500: a CyrEo fontset, please?

[Ivan Shmakov]

 Anton Zinoviev an...@lml.bas.bg writes:
 On Wed, Feb 13, 2013 at 03:44:47PM +, Ivan Shmakov wrote:

[…]

  Please provide 256-glyph fonts with both Cyrillic and Esperanto
  glyphs (specifically: U+0108, U+0109, U+011C, U+011D, U+0124,
  U+0125, U+0134, U+0135, U+015C, U+015D, U+016C, U+016D.)

  One possible such fontset is MIMEd.  It is based on CyrSlav.256, and
  retains all its glyphs within the U+04xx range, adds the
  aforementioned Esperanto glyphs, U+00F7 DIVISION SIGN, while
  removing certain U+20xx (U+2013, U+2020, U+2021, U+2030, U+2039,
  U+203A) glyphs, and U+2122 TRADE MARK SIGN, arguably not all that
  valuable for Cyrillic-based typography.

  Hi and thank you for your contribution!

  I am tagging this bug report as 'wontfix' for the following reasons:

  1. The combination Cyrillic + Esperanto is supported by Uni2 and Uni3
  fontsets.

… However, these fontsets come at the price of the reduced color
capability for the text terminals.

  2. Small fontsets (256 glyphs) are for one language only.

That’s hardly the case; for instance, how do you explain that
the CyrSlav fontset includes ñ?  Is it used in any languages
that rely on the Cyrillic script?

  Users who need multilingual support should use Uni1, Uni2 or Uni3.

FWIW, I’d gladly accept a facility allowing the user to use
custom fontsets for a fix to this issue.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#700500: a CyrEo fontset, please?

[Ivan Shmakov]

 Anton Zinoviev an...@lml.bas.bg writes:
 On Thu, Aug 07, 2014 at 01:48:43PM +, Ivan Shmakov wrote:

  … However, these fontsets come at the price of the reduced color
  capability for the text terminals.

  This doesn't happen when framebuffer is used.

Does that mean /dev/fb*, or rather the “kernel mode setting”
(KMS) facility?

The last time I’ve checked, – it wasn’t the case for KMS-enabled
text VTs.  I wasn’t following this closely, though.

  With modern kernels framebuffer is more or less a requirement.

With xserver-xorg-video-vesa, – it surely isn’t.

Unfortunately, “native” X video drivers are simply not supported
for my hardware on Debian.  (Unless, of course, one considers
firmware-linux-nonfree to be part of Debian, which it’s /not./)

  2. Small fontsets (256 glyphs) are for one language only.

  That’s hardly the case; for instance, how do you explain that the
  CyrSlav fontset includes ñ?  Is it used in any languages that rely
  on the Cyrillic script?

  No, the letter ñ is not included in the CyrSlav fontset.  The symbols
  from the file useful.set are included in the generated fonts by the
  bdf2psf utility only when there are free positions.  The letter ñ is
  listed number 109 in this file.

I stand corrected.
 
  Users who need multilingual support should use Uni1, Uni2 or Uni3.

  FWIW, I’d gladly accept a facility allowing the user to use custom
  fontsets for a fix to this issue.

  Yes, custom fontsets are supported.  One only has to put the
  corresponding font in /usr/share/consolefonts and use an instruction
  like FONT=CyrEo-Terminus16.psf.gz in /etc/default/console-setup.

That doesn’t seem like “supported” to me, as:

• /usr is generally reserved for dpkg-maintained files; the
  “custom” ones belong to /usr/local instead;

• by “custom fontsets support” I mean, specifically, that the
  user is provided a tool which locates user’s own fontsets
  (either in /etc/console-setup or somewhere under /usr/local,
  or perhaps passed via the command line) and generates the
  respective font files; alas, I don’t seem to see any such tool
  provided by either console-setup, console-setup-linux, or kbd
  packages.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756950: gnugo.el should have autoload declarations in site-start.d/50gnugo.el

[Ivan Shmakov]

Package:  gnugo
Version:  3.8-7
Tags: patch

… So that it’s possible to use M-x gnugo RET right after Emacs
is started and without any special configuration in user’s own
~/.emacs.

Please thus consider the patch MIMEd.

TIA.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A
;;; 50gnugo.el — Emacs startup file for the Debian gnugo package  -*- Emacs-Lisp -*-

(if (not (file-exists-p /usr/share/emacs/site-lisp/gnugo.el))
(message Package gnugo removed but not purged.  Skipping setup.)
  ;; An autoload from /usr/share/emacs/site-lisp/gnugo.el
  (autoload 'gnugo gnugo
Run gnugo in a buffer, or resume a game in progress.
Prefix arg means skip the game-in-progress check and start a new
game straight away.

You are queried for additional command-line options (Emacs supplies
\--mode gtp --quiet\ automatically).  Here is a list of options
that gnugo.el understands and handles specially:

--boardsize num   Set the board size to use (5--19)
--color color   Choose your color ('black' or 'white')
--handicap num  Set the number of handicap stones (0--9)

If there is already a game in progress you may resume it instead of
starting a new one.  See `gnugo-board-mode' documentation for more info.
t))

;;; 50gnugo.el ends here

Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates

[Ivan Shmakov]

 Ivan Shmakov i...@siamics.net writes:

  I’ve built the patched gnutls26 (now as of 2.12.20-8+deb7u2) package
  with pbuilder and briefly tested Exim (as of 4.80-7) with the
  resulting libgnutls26, and seen no issues so far.

  The resulting packages, both source (signed) and binary (along with
  signed .changes files) are available from the following location.
  (Should you decide to use these, /please take care/ to check .dsc and
  .changes signatures against my public key, and binary packages
  against the .changes files.)

  ⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-test.list ⋯✂⋯

[…]

Just noticed that I’ve made a silly mistake in my previous
message; the correct (as in: s/-test/-misc/) sources.list.d/
file is as follows.

⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-misc.list ⋯✂⋯
deb http://am-1.org/~ivan/mini-dinstall/ 1gray-misc/$(ARCH)/
deb http://am-1.org/~ivan/mini-dinstall/ 1gray-misc/all/
deb-src http://am-1.org/~ivan/mini-dinstall/ 1gray-misc/source/
⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-misc.list ⋯✂⋯

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates

[Ivan Shmakov]

I’ve built the patched gnutls26 (now as of 2.12.20-8+deb7u2)
package with pbuilder and briefly tested Exim (as of 4.80-7)
with the resulting libgnutls26, and seen no issues so far.

The resulting packages, both source (signed) and binary (along
with signed .changes files) are available from the following
location.  (Should you decide to use these, /please take care/
to check .dsc and .changes signatures against my public key, and
binary packages against the .changes files.)

⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-test.list ⋯✂⋯
deb http://am-1.org/~ivan/mini-dinstall/ 1gray-test/$(ARCH)/
deb http://am-1.org/~ivan/mini-dinstall/ 1gray-test/all/
deb-src http://am-1.org/~ivan/mini-dinstall/ 1gray-test/source/
⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-test.list ⋯✂⋯

For the sake of completeness, the changes are also MIMEd.

-- 
FSF associate member #7257  http://boycottsystemd.org/
Public key fingerprint: 58F8 0F47 53F5 2EB2 F6A5  8916 3013 B6A0 230E 334A
diff -dru -- a/debian/changelog b/debian/changelog
--- a/debian/changelog	2014-05-31 14:28:44.0 +
+++ b/debian/changelog	2014-07-29 18:48:51.0 +
@@ -1,3 +1,13 @@
+gnutls26 (2.12.20-8+deb7u2.0+is.2) 1gray-misc; urgency=medium
+
+  * 12_no_sign_algo.diff: adapted from 1a02ec18e9e3 by Nikos
+Mavrogiannopoulos.  Closes: #737921, #740160
+  * 42_no-more-gets.diff: do not assume that gets () is declared
+by the libc; adapted from
+https://lists.gnu.org/archive/html/bug-gnulib/2012-03/msg00186.html
+
+ -- Ivan Shmakov i...@siamics.net  Tue, 29 Jul 2014 18:48:51 +
+
 gnutls26 (2.12.20-8+deb7u2) wheezy-security; urgency=high
 
   * 39_Prevent-memory-corruption.diff from upstream GIT. Fix memory corruption
Only in b/debian/patches: 12_no_sign_algo.diff
Only in b/debian/patches: 42_no-more-gets.diff
diff -dru -- a/debian/patches/series b/debian/patches/series
--- a/debian/patches/series	2014-05-31 14:27:28.0 +
+++ b/debian/patches/series	2014-07-29 18:57:21.0 +
@@ -1,3 +1,4 @@
+12_no_sign_algo.diff
 14_version_gettextcat.diff
 16_unnecessarydep.diff
 17_ignoretestsuitteerrors.diff
@@ -13,3 +14,4 @@
 37_fix_rejection-of-v1-intermedi.diff
 38_CVE-2014-0092.diff
 39_Prevent-memory-corruption.diff
+42_no-more-gets.diff
This is an adaptation of the change made in 1a02ec18e9e3 and
subsequently amended (with regards to GNUTLS_CRT_OPENPGP.)

commit 6e4e6b0aa30acc8db68fcc19a9406abcfe44ae9c
Author: Nikos Mavrogiannopoulos n...@gnutls.org
Date:   Thu Apr 21 00:21:56 2011 +0200

commit 1a02ec18e9e39f82cee7f9cff74e1f1574bac472
Author: Nikos Mavrogiannopoulos n...@gnutls.org
Date:   Wed Apr 20 19:45:20 2011 +0200

Eliminated the need for sign_algo in gnutls_pcert_st. This means
that we don't follow RFC5246 by letter, but there wasn't any other
implementation using the sign_algorithm part of the certificate
selection, and this helps reduce complexity.

diff --git a/lib/auth/cert.c b/lib/auth/cert.c
index 275e9bf..39cf8ed 100644
--- a/lib/auth_cert.c
+++ b/lib/auth_cert.c
@@ -,29 +,18 @@ _gnutls_proc_x509_server_certificate (gnutls_session_t session,
   if ((ret =
_gnutls_x509_raw_cert_to_gcert (peer_certificate_list
[j], tmp,
CERT_ONLY_EXTENSIONS))  0)
 {
   gnutls_assert ();
   goto cleanup;
 }
 
-  /* check if signature algorithm is supported */
-  ret =
-_gnutls_session_sign_algo_enabled (session,
-   peer_certificate_list
-   [j].sign_algo);
-  if (ret  0)
-{
-  gnutls_assert ();
-  goto cleanup;
-}
-
   p += len;
 }
 
 
   if ((ret =
_gnutls_copy_certificate_auth_info (info,
peer_certificate_list,
peer_certificate_list_size))  0)
 {
@@ -2092,26 +2081,18 @@ _gnutls_server_select_cert (gnutls_session_t session,
*/
   if (requested_algo == GNUTLS_PK_ANY ||
   requested_algo == cred-cert_list[i][0].subject_pk_algorithm)
 {
   /* if cert type and signature algorithm matches
*/
 	  /* *INDENT-OFF* */
 	  if (session-security_parameters.cert_type
-	  == cred-cert_list[i][0].cert_type
-	   (cred-cert_list[i][0].cert_type == GNUTLS_CRT_OPENPGP
-		  ||	/* FIXME: make this a check for certificate
-			   type capabilities */
-		  !_gnutls_version_has_selectable_sighash
-		  (gnutls_protocol_get_version (session))
-		  ||
-		  _gnutls_session_sign_algo_requested
-		  (session, cred-cert_list[i][0].sign_algo) == 0))
+ 	  == cred-cert_list[i][0].cert_type)
 	{
 	  idx = i;
 	  break;
 	}
 	  /* *INDENT-ON* */
 }
 }
 
   /* store the certificate pointer

Bug#756058: XML::Twig applies default namespace (xmlns) to attributes, too

[Ivan Shmakov]

Source:   libxml-twig-perl
Version:  1:3.44-1

As currently implemented, XML::Twig applies default namespaces
also to all the unprefixed /attributes/ in scope, which is
contrary to the specification [1]:

A default namespace declaration applies to all unprefixed element
names within its scope.  Default namespace declarations do not apply
directly to attribute names; the interpretation of unprefixed
attributes is determined by the element on which they appear.

[1] http://www.w3.org/TR/xml-names/#defaulting

Consider, for instance:

$ perl  -e 'use common::sense;
require Data::Dump;
require XML::Twig;
binmode (\*STDOUT, :encoding(utf8))
or die ();
sub dump_atts {
warn (scalar (Data::Dump::dump ($_-atts ())), \n);
## .
1;
}
my $xt
= XML::Twig-new (map_xmlns = {
  qw (https://example.com/ns ns)
  },
  twig_handlers = {
  ns:bar = \dump_atts
  })
or die ();
$xt-parse ((foo xmlns=\https://example.com/ns\;
 . bar baz=\qux\ //foo))
or die ();'
{ ns:baz = qux }
$ 

The expected output is, however:

{ baz = qux }

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756059: New XML::Twig version available

[Ivan Shmakov]

Source:   libxml-twig-perl
Version:  1:3.44-1

As per https://metacpan.org/changes/distribution/XML-Twig, the
latest released XML::Twig version is 3.48 (2014-03-30.)

Please consider updating the Debian package.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#753466: xul-ext-classic-theme-restorer: customize the new Iceweasel look

[Ivan Shmakov]

Package:  wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-mozext-maintain...@lists.alioth.debian.org

* Package name: xul-ext-classic-theme-restorer
  Version : 1.2.1
  Upstream Author : 
* URL or Web page : 
https://addons.mozilla.org/en-US/firefox/addon/classicthemerestorer/
* License : Mozilla Public License, version 2.0
  Description : Classic Theme Restorer is an add-on for Mozilla

The Australis theme now employed by Mozilla Firefox (Iceweasel)
is by no means an undisputed improvement.  Of the new features,
perhaps the most complained on are the lack of the “status bar”
(which could, however, be fixed by using xul-ext-status4evar
already in Debian) and the presence of the unremovable “menu”
button to the right of (the customizable part of) the toolbar.

As per the description, and also some Mozilla “forum” topics,
the Classic Theme Restorer addon is the way to revert (in whole
or in part) the changes brought in by Australis.

Please thus package this addon for Debian.

TIA.

-- 
FSF associate member #7257  http://boycottsystemd.org/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#735042: [bash] 0 is null (misleading test documentation)

[Ivan Shmakov]

 Jakub Wilk jw...@debian.org writes:
 * Filipus Klutiero chea...@gmail.com, 2014-01-12, 00:23:

  [I'm not the maintainer of bash.]

[I’m not the one who’s submitted this bug, either.]

  According to the part on test of bash's manpage:

  1 argument  The expression is true if and only if the argument is
  not null.

  Yet: $ test 0; echo $?  0

  0 is not null, so the expression is true, so the exit code is 0.
  What else did you expect?

Personally, I’d expect for the documentation to read “is not an
empty string” in this case instead.

-- 
FSF associate member #7257  http://boycottsystemd.org/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741870: X server crashes when running (in particular) some Tk 8.4 apps

[Ivan Shmakov]

 Julien Cristau jcris...@debian.org writes:
 On Fri, Apr 11, 2014 at 15:28:19 +, Ivan Shmakov wrote:

  While I’m not entirely sure that it’s the same bug (so feel free to
  ‘notfound’ it as necessary), I’ve just found that Wheezy’s Xorg also
  crashes when I try to start certain X applications.  Consider,
  e. g.:

  # : starting a fresh Xorg at :3 here 
  $ DISPLAY=:3.0 twm  wait $! ; 
  [5] 14099
  XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server 
  :3.0
after 106 requests (106 known processed) with 0 events remaining.
  [5]   Exit 1  DISPLAY=:3.0 twm

[…]

  Also to note is that the issue seems to be surprisingly easy to
  reproduce.

  Do you have a font server in your font path?

Indeed, I do.  And indeed, removing one from the font path as a
work-around solves the issue, thanks.

But it left me wondering if it’s planned to fix this issue
properly in Wheezy?

-- 
FSF associate member #7257  http://boycottsystemd.org/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#470936: VT switching results in scrambled colors

[Ivan Shmakov]

Control: found   470936 xserver-xorg-video-vesa/1:2.3.1-1
Control: summary 470936 VT switching vs. scrambled colors

 Ivan Shmakov i...@gray.siamics.net writes:
 Cyril Brulebois k...@debian.org writes:

[…]

  is it better in squeeze, sid, or experimental?

  The problem of scrambled colors with -depth 24 seem to be vanished by
  1:2.3.0-3, thanks.  (Though I'm more inclined to use
  xserver-xorg-video-radeonhd for it works for a long time now.)

  However, there still is a similarly-looking issue with -depth 16.

After a change of the VGA adapter (below), and now a switch to
Wheezy, I’ve found that the issue still exists, for /both/
-depth 24 and -depth 16.

Specifically, darker shades of gray (e. g., #201b1a, #332b29)
seem to turn into bright green and yellow (respectively) with
-depth 16, after VTs have been switched.

Surprisingly, however, I’ve just seen the issue appearing right
after the X server is started with -depth 24, and was /fixed/ as
soon the VTs were switched.

Any ideas on what might’ve going wrong here?

TIA.

$ lspci | grep -F -- Radeon\ HD 
04:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Caicos 
[Radeon HD 6450]

[…]

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#737679: needs to be built with libtirpc

[Ivan Shmakov]

 Arne Nordmark nordm...@mech.kth.se writes:

  It looks like this is down to autofs not handling names using only
  IPv6 addresses.  Not sure why this happens given that I would have
  expected it to just pass this directly to mount(8) but it's
  presumably doing more than that.  Not sure exactly what the cause
  is, though /usr/lib/x86_64-linux-gnu/autofs/mount_nfs.so is using
  getaddrinfo and I can't see any obvious defect with a quick glance
  over the sources.

  Autofs does some initial NFS probing of its own, as part of handling
  server replication.

JFTR, I’d rather look for some clean way of /disabling/ such
probing altogether, preferably as a per-share option.  My
NFSv4/IPv6 servers aren’t currently replicated anyway, and such
a work-around would’ve solved this problem at least for me.

[…]

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#741870: X server crashes when running (in particular) some Tk 8.4 apps

[Ivan Shmakov]

Control: found 741870 1:7.7+3~deb7u1

 Andrew Shadura andre...@debian.org writes:

  Package: xserver-xorg
  Version: 1:7.7+6
  Severity: normal

  When running hgk, a Mercurial port of gitk, with Tk 8.4 linked to
  /usr/bin/wish, the X server crashes. The crash doesn't happen if the
  X server isn't running on the active VT. It also doesn't happen with
  any other Tk version.

While I’m not entirely sure that it’s the same bug (so feel free
to ‘notfound’ it as necessary), I’ve just found that Wheezy’s
Xorg also crashes when I try to start certain X applications.
Consider, e. g.:

# : starting a fresh Xorg at :3 here 
$ DISPLAY=:3.0 twm  wait $! ; 
[5] 14099
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server :3.0
  after 106 requests (106 known processed) with 0 events remaining.
[5]   Exit 1  DISPLAY=:3.0 twm
$ 

# : starting a fresh Xorg at :3 here 
$ DISPLAY=:3.0 gv -- some.pdf  wait $! ; 
[5] 14134
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server :3.0
  after 123 requests (123 known processed) with 0 events remaining.
[5]   Exit 1  DISPLAY=:3.0 gv -- some.pdf
$ 

The server ends with just the following in the first case:

14096 Aborted Xorg :3 vt10 -config xorg.conf-vesa -depth 24

yet leaves a proper backtrace (MIMEd) in the log in the second.

Also to note is that the issue seems to be surprisingly easy to
reproduce.

-- 
FSF associate member #7257
[ 12012.763] Backtrace:
[ 12012.763] 0: Xorg (xorg_backtrace+0x36) [0x7ff37c976d16]
[ 12012.763] 1: Xorg (0x7ff37c7f8000+0x182869) [0x7ff37c97a869]
[ 12012.763] 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7ff37bb2+0xf030) 
[0x7ff37bb2f030]
[ 12012.763] 3: /usr/lib/libXfont.so.1 (FontFileListNextFontWithInfo+0x1d) 
[0x7ff37b66a51d]
[ 12012.763] 4: Xorg (doListFontsWithInfo+0x163) [0x7ff37c84b473]
[ 12012.763] 5: Xorg (ProcessWorkQueue+0x21) [0x7ff37c84f0c1]
[ 12012.763] 6: Xorg (WaitForSomething+0x62) [0x7ff37c974022]
[ 12012.763] 7: Xorg (0x7ff37c7f8000+0x52bb1) [0x7ff37c84abb1]
[ 12012.764] 8: Xorg (0x7ff37c7f8000+0x41ec5) [0x7ff37c839ec5]
[ 12012.764] 9: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) 
[0x7ff37a845ead]
[ 12012.764] 10: Xorg (0x7ff37c7f8000+0x4219d) [0x7ff37c83a19d]
[ 12012.764] 
[ 12012.764] Segmentation fault at address (nil)
[ 12012.764] 
Fatal server error:
[ 12012.764] Caught signal 11 (Segmentation fault). Server aborting

Bug#741536: line-move-visual breaks keyboard macros

[Ivan Shmakov]

Control: severity 741536 wishlist

 Harald Dunkel harald.dun...@aixigo.de writes:

  Package: emacs23
  Version: 23.4+1-4

  The new line-move-visual breaks keyboard macros based upon cursor
  down and up.  Suddenly the length of the line and the window size
  become important, even if your cursor is in column 0.

  Bad choice for a default setting.

While I tend to agree with that (and why, my ~/.emacs overrides
several changes to Emacs defaults made since 2004 or so),
I don’t think it’s feasible for Debian to deviate from upstream
in this particular case.

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732999: X11::Protocol fails to connect to X servers over IPv6

[Ivan Shmakov]

 gregor herrmann gre...@debian.org writes:
 On Mon, 23 Dec 2013 18:54:58 +, Ivan Shmakov wrote:

[…]
 
  An (untested) change is MIMEd.

  Could you please:

  - provide a proper quilt patch against our git repo patch instead of
  instructions what needs to be done where

Sure; MIMEd.

BTW, I choose to use IO::Socket::IP (which I also suggest for
adding to Recommends:) instead of IO::Socket::INET6, as the
former is expected to end up in the Perl “core”.

  - actually test the changes :)

I’ve briefly tested the change.  For instance, with 0.56-4:

$ perl zkgqj6rkxouaqmkzrhqukdem6d.perl 
Can't connect to display `violet.siamics.net:1': Invalid argument at 
/usr/share/perl5/X11/Protocol.pm line 2270.
$ 

0.56-5, no IO::Socket::IP installed:

$ perl zkgqj6rkxouaqmkzrhqukdem6d.perl 
Can't connect to display `violet.siamics.net:1': Invalid argument at 
/usr/share/perl5/X11/Protocol.pm line 2270.
$ 

0.56-5, IO::Socket::IP:

$ perl zkgqj6rkxouaqmkzrhqukdem6d.perl 
_NET_WM_WINDOW_TYPE → [a\1\0\0, 4, 32, 0]
_NET_SUPPORTING_WM_CHECK → [\16\0\xA0\0, 33, 32, 0]
_NET_WM_NAME → [Openbox, 306, 8, 0]
WM_CLASS → [, 31, 8, 0]
WM_TRANSIENT_FOR → [\2\0\0\0, 33, 32, 0]
WM_LOCALE_NAME → [C, 31, 8, 0]
…

-- 
FSF associate member #7257
Description: Use IO::Socket::IP if available (or IO::Socket::INET if not)
Author: Ivan Shmakov i...@siamics.net
Last-Update: 2014-04-11 16:34:39.461642+00:00

--- a/Protocol/Connection/INETSocket.pm
+++ b/Protocol/Connection/INETSocket.pm
@@ -17,10 +17,18 @@ use vars qw($VERSION @ISA);
 
 $VERSION = 0.01;
 
+our $SOCKET_CLASS;
+
+$SOCKET_CLASS
+= ((eval { require IO::Socket::IP })
+   ? IO::Socket::IP
+   : do { require IO::Socket::INET; IO::Socket::INET; })
+unless (defined ($SOCKET_CLASS));
+
 sub open {
 my($pkg) = shift;
 my($host, $dispnum) = @_;
-my($sock) = IO::Socket::INET-new('PeerAddr' = $host,
+my($sock) = $SOCKET_CLASS-new   ('PeerAddr' = $host,
   'PeerPort' = 6000 + $dispnum,
   'Type' = SOCK_STREAM(),
   'Proto' = tcp);
diff --git a/debian/changelog b/debian/changelog
index 0104ff6..a4ea430 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -7,7 +7,10 @@ libx11-protocol-perl (0.56-5) UNRELEASED; urgency=low
   [ gregor herrmann ]
   * Strip trailing slash from metacpan URLs.
 
- -- Salvatore Bonaccorso car...@debian.org  Sun, 06 Jan 2013 22:09:03 +0100
+  [ Ivan Shmakov ]
+  * Use IO::Socket::IP for IPv6 support if available.  Closes: #732999
+
+ -- Ivan Shmakov i...@siamics.net  Fri, 11 Apr 2014 16:40:43 +
 
 libx11-protocol-perl (0.56-4) unstable; urgency=low
 
diff --git a/debian/control b/debian/control
index 956ddc9..208e8a5 100644
--- a/debian/control
+++ b/debian/control
@@ -13,6 +13,7 @@ Homepage: https://metacpan.org/release/X11-Protocol
 Package: libx11-protocol-perl
 Architecture: all
 Depends: ${perl:Depends}, ${misc:Depends}
+Recommends: libio-socket-ip
 Description: Perl module for the X Window System Protocol, version 11
  X11::Protocol is a client-side interface to the X11 Protocol (see X(1) for
  information about X11), allowing perl programs to display windows and
diff --git a/debian/patches/series b/debian/patches/series
index 5299247..2443084 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 spelling.patch
+io-socket-ip.patch
#!/usr/bin/perl
### zkgqj6rkxouaqmkzrhqukdem6d.perl  -*- Perl -*-
## Test X11::Protocol vs. IPv6

### Ivan Shmakov, 2014

## To the extent possible under law, the author(s) have dedicated all
## copyright and related and neighboring rights to this software to the
## public domain worldwide.  This software is distributed without any
## warranty.

## You should have received a copy of the CC0 Public Domain Dedication
## along with this software.  If not, see
## http://creativecommons.org/publicdomain/zero/1.0/.

### Code:

use common::sense;
use English qw (-no_match_vars);

require Carp;
require Data::Dump;
require Encode;
require Encode::Locale;
# require IO::Socket::IP;
require X11::Protocol;

sub localize_io {
my ($wr_p) = shift ();
foreach my $f (@_) {
$f-binmode (! -t $f  ? :encoding(locale)
 : $wr_p  ? :encoding(console_out)
 :  :encoding(console_in));
}
## .
@_;
}

localize_io (0, \*STDIN);
localize_io (1, \*STDERR, \*STDOUT);

my $x
= X11::Protocol-new ();
my $w0
= $x-{root};
my ($w0_root, $w0_parent, @tlw)
= $x-req (QueryTree, $w0);
foreach my $w (@tlw) {
foreach my $atom ($x-req (ListProperties, $w)) {
my @prop
= $x-req (GetProperty, $w, $atom,
   AnyPropertyType, 0, 200, 0);
print ($x-atom_name ($atom),  → ,
   scalar (Data::Dump::dump (\@prop)),
   \n);
}
}

### zkgqj6rkxouaqmkzrhqukdem6d.perl ends here

Bug#718434: fixed in ca-certificates 20140223

[Ivan Shmakov]

 Bas Wijnen wij...@debian.org writes:
 On Thu, Mar 13, 2014 at 01:03:23PM +, Michael Shuler wrote:

  * No longer ship cacert.org certificates.  Closes: #718434, LP:
  #1258286

[…]

  Yes, I understand that CAcert's code and procedures are less secure
  than they should be.  I don't care.  First priority is to get the web
  encrypted.  Trusted certificates is secondary.  As long as browsers
  don't reasonably allow self-signed certificates, I think we should
  accept any and all certificates as trustworthy; certainly the ones
  from a community-driven CA.  (As noted, the current selection doesn't
  seem to filter for security anyway.)

There’re two issues with that.  First of all, accepting some
“random” certificates may give the users some false sense of
security.  Then, I’d like to note that a compromised CA may very
well be used to issue an “example.com” certificate /even though/
example.com may already have a valid certificate from some other
(non-compromised) CA?  And the TLS-enabled user agents generally
have no means to discern such “fake” certificate from the
“genuine” one.  That is: the security of the Web is essentially
the security of /the least secure/ CA of those one trusts.

… That being said, could someone please remind me when Debian
has itself passed a security audit for the last time?  Or,
scratch that, – when it was the last time the TLS-related Debian
binary packages were audited?  (And sorry, “related” also means
the entire GNU toolchain – GCC, etc. – since you can’t really
trust a binary produced by a compromised compiler, can you?)

TIA.

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#737921: [TLS1.2] gnutls only likes SHA1 and SHA256 certificates

[Ivan Shmakov]

Control: tags 737921 + patch

 Jan Nordholz jnordh...@sec.t-labs.tu-berlin.de writes:
 Hi Daniel,

[…]

  Have you tested this against libgnutls28?  GnuTLS 3.2.10-2 is the
  latest version in jessie and sid, and 3.2.8.1-2~bpo70+1 is in
  wheezy-backports.  I believe you'll find it resolved in this
  version.

  well, I tested against gnutls-serv, which indeed seems to work (and
  that one's linked to gnutls28).  However my original problem occurred
  with exim, and I was reluctant to recompile those packages as I don't
  know how much of the gnutls API has changed and would need fixing in
  exim.

  Good to know that the library migration will eventually take care of
  this.

AIUI, this issue affects all of those who happen to:

• use the X.509 certificates signed with the RSA-SHA512
  algorithm (such as those recently issued by CAcert.org) at
  their servers, and thus all the users of these servers;

• are, at the same time, using the latest stable Debian release.

Given that a new Debian stable isn’t to be released anytime
soon, I’d like to ask for the Debian gnutls26 package
maintainers to consider adopting a change [1] (possible patch
MIMEd) made to the GnuTLS tree back in 2011, which I believe
resolves the issue.

I’ve built the patched gnutls26 package with pbuilder and
briefly tested Exim (as of 4.80-7) with the resulting
libgnutls26, and seen no issues so far.  The resulting packages
are available from the following location (please do /not/ use
unless in testing environments, such as a KVM instance, etc.):

⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-test.list ⋯✂⋯
deb http://am-1.org/~ivan/mini-dinstall/ 1gray-test/$(ARCH)/
deb http://am-1.org/~ivan/mini-dinstall/ 1gray-test/all/
deb-src http://am-1.org/~ivan/mini-dinstall/ 1gray-test/source/
⋯✂⋯ /etc/apt/sources.list.d/99-am-1.org-1gray-test.list ⋯✂⋯

TIA.

[1] https://gitorious.org/gnutls/gnutls/commit/1a02ec18e9e39
http://git.savannah.gnu.org/cgit/gnutls.git/commit/?id=1a02ec18e9e39

PS.  The top (IOW, the comment) of the diff should read: “… (with
regards to GNUTLS_CRT_OPENPGP.)”  Sending as-is because it’s the
file I’ve actually used while building the package.

-- 
FSF associate member #7257
This is an adaptation of the change made in 1a02ec18e9e3 and
subsequently amended (with regards to 

commit 6e4e6b0aa30acc8db68fcc19a9406abcfe44ae9c
Author: Nikos Mavrogiannopoulos n...@gnutls.org
Date:   Thu Apr 21 00:21:56 2011 +0200

commit 1a02ec18e9e39f82cee7f9cff74e1f1574bac472
Author: Nikos Mavrogiannopoulos n...@gnutls.org
Date:   Wed Apr 20 19:45:20 2011 +0200

Eliminated the need for sign_algo in gnutls_pcert_st. This means
that we don't follow RFC5246 by letter, but there wasn't any other
implementation using the sign_algorithm part of the certificate
selection, and this helps reduce complexity.

diff --git a/lib/auth/cert.c b/lib/auth/cert.c
index 275e9bf..39cf8ed 100644
--- a/lib/auth_cert.c
+++ b/lib/auth_cert.c
@@ -,29 +,18 @@ _gnutls_proc_x509_server_certificate (gnutls_session_t session,
   if ((ret =
_gnutls_x509_raw_cert_to_gcert (peer_certificate_list
[j], tmp,
CERT_ONLY_EXTENSIONS))  0)
 {
   gnutls_assert ();
   goto cleanup;
 }
 
-  /* check if signature algorithm is supported */
-  ret =
-_gnutls_session_sign_algo_enabled (session,
-   peer_certificate_list
-   [j].sign_algo);
-  if (ret  0)
-{
-  gnutls_assert ();
-  goto cleanup;
-}
-
   p += len;
 }
 
 
   if ((ret =
_gnutls_copy_certificate_auth_info (info,
peer_certificate_list,
peer_certificate_list_size))  0)
 {
@@ -2092,26 +2081,18 @@ _gnutls_server_select_cert (gnutls_session_t session,
*/
   if (requested_algo == GNUTLS_PK_ANY ||
   requested_algo == cred-cert_list[i][0].subject_pk_algorithm)
 {
   /* if cert type and signature algorithm matches
*/
 	  /* *INDENT-OFF* */
 	  if (session-security_parameters.cert_type
-	  == cred-cert_list[i][0].cert_type
-	   (cred-cert_list[i][0].cert_type == GNUTLS_CRT_OPENPGP
-		  ||	/* FIXME: make this a check for certificate
-			   type capabilities */
-		  !_gnutls_version_has_selectable_sighash
-		  (gnutls_protocol_get_version (session))
-		  ||
-		  _gnutls_session_sign_algo_requested
-		  (session, cred-cert_list[i][0].sign_algo) == 0))
+ 	  == cred-cert_list[i][0].cert_type)
 	{
 	  idx = i;
 	  break;
 	}
 	  /* *INDENT-ON* */
 }
 }
 
   /* store the certificate pointer for future use, in the 

Bug#733603: moving AVR Libc manual pages under /usr/share/man/

[Ivan Shmakov]

 Hakan Ardo ha...@debian.org writes:
 On Sun, Jan 5, 2014 at 12:17 PM, Hakan Ardo ha...@debian.org wrote:
 On Fri, Jan 3, 2014 at 10:19 AM, Ivan Shmakov i...@siamics.net wrote:

[…]

  … However, I don’t seem to understand the choice of either
  location.  Isn’t it customary to use /usr/share/man for everything
  in Debian, possibly adding appropriate suffixes to the filenames,
  as in: readline.3readline.gz, TIFFsize.3tiff.gz,
  Encode::Unicode.3perl.gz, and thus, presumably, floor.3avr.gz,
  random_r.3avr.gz, etc.?

[…]

  OK, we'll rename them and move them again.

  Hi again, moving them was not trivial.  For a clean solution I had to
  patch doxygen.  I've, made an upstream pull-request:

https://github.com/doxygen/doxygen/pull/90

  Hopefully I'll propagte to debian before too long.  Otherwise we'll
  hack differently...

Deferring the fix until a fixed version of Doxygen enters Debian
doesn’t seem like all that good an idea.  Especially given that
the correct placement of the files comprising a Debian package
was conventionally (AIUI) the responsibility of debian/rules.

If necessary, the .TH or .Dt *roff command (as used by
dh_installman(1)) may be fixed (or added) with sed(1).

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733603: avr-libc: avr-man unable to work due to missing files/directories

[Ivan Shmakov]

fixed 733603 1:1.8.0-4
thanks

 Hakan Ardo ha...@debian.org writes:
 On Mon, Dec 30, 2013 at 11:40 AM, Simon Kainz wrote:

  After inspecting avr-man, i see the line:

  exec man -M /usr/share/doc/avr-libc/man $@

  But the path /usr/share/doc/avr-libc/man is not created by
  installing avr-libc nor is it by any other package.

  the manpages was moved there in version 1.8.0-4, currently in
  testing.

I’m thus marking the bug as fixed there (so it would be archived
when the current stable won’t be supported anymore.)

  In the version in stable they reside in /usr/lib/share/man/man3/

… However, I don’t seem to understand the choice of either
location.  Isn’t it customary to use /usr/share/man for
everything in Debian, possibly adding appropriate suffixes to
the filenames, as in: readline.3readline.gz, TIFFsize.3tiff.gz,
Encode::Unicode.3perl.gz, and thus, presumably, floor.3avr.gz,
random_r.3avr.gz, etc.?

Going this way, there’s no need for any MANPATH tweaking, and
even the manual page browsers that are not based on man(1) (such
as Emacs’ woman.el) will just work “out of box.”

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#733939: man page for avr-man

[Ivan Shmakov]

title 733939 man page for avr-man 
thanks

 Simon Kainz si...@familiekainz.at writes:

  Package: avr-libc
  Version: 1:1.8.0-4
  Tags: patch

  .TH AVR_MAN 1 2014-01-02
  .SH NAME
  avr-man - a man(1) replacement to access the avr-libc manual pages
  .SH SYNOPSIS
  \fB avr-man \fR [ \fIOPTION\fR ] \fIpage\fR
  .SH DESCRIPTION
  .B avr-man
  is a wrapper script for \fBman\fR(1), displaying results for the
  specified \fIpage\fR from the manual pages shipped with the
  .IR avr-libc
  package.

[…]

Well, as I’ve just commented on Bug#733603, I doubt there’s a
reason to put these manual pages into any non-standard location.

For instance, we already have puts.3.gz and puts.3tcl.gz in
/usr/share/man/man3, and I see no reason not to put AVR Libc’s
puts.3.gz as puts.3avr.gz there.

Naturally, this will obviate any need for a separate avr-man(1)
wrapper.  (Although having a manual page for it may still be
appropriate, at least so to document that there’s no need to use
it on Debian.)

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732974: binutils-arm-none-eabi: No C++ support

[Ivan Shmakov]

reassign 732974 gcc-arm-none-eabi 4.8.2-5+4
severity 732974 wishlist
merge 732974 733580
thanks

 Simon John deb...@the-jedi.co.uk writes:

  Package: binutils-arm-none-eabi
  Version: 2.23.90.20131116-1+3

It’s hardly an issue with the GNU Binutils package, but rather
with the GCC one.

  Severity: important

I don’t seem to understand the rationale behind this severity,
either?

[…]

  I've noticed that the gcc-arm-embedded Launchpad build comes with
  arm-none- eabi-g++ and arm-none-eabi-c++ and we only have
  arm-none-eabi-cpp

JFTR: the ‘cpp’ part in arm-none-eabi-cpp stands for
“C preprocessor”, and isn’t any more relevant to C++ support
than it has to C.

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#732999: X11::Protocol fails to connect to X servers over IPv6

[Ivan Shmakov]

Package: libx11-protocol-perl
Version: 0.56-4
Tags: ipv6, patch

The INETSocket.pm module, as used by X11::Protocol, does
currently rely on IO::Socket::INET, thus supporting connections
over IPv4 only.

The fix is rather straightforward: the IO::Socket::INET6 class
(which supports /both/ IPv6 /and/ IPv4) is to be checked at
run-time, and, if available, used instead of IO::Socket::INET.
(Much like the fix I’ve suggested [1] for Bug#306914.)

An (untested) change is MIMEd.

As a work-around, the software using X11::Protocol may simply
“redirect” the IO::Socket::INET-new () class constructor to
IO::Socket::INET6-new (), like:

require IO::Socket::INET;
require IO::Socket::INET6;

*IO::Socket::INET::new = sub {
my ($class, @args) = @_;
## .
IO::Socket::INET6-new (@args);
};

As a side effect, this may actually enable IPv6 support in all
the other Perl code that uses IO::Socket::INET.  (Potentially
breaking it with unexpected values of -peerhost (), etc.)

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306914#68

-- 
FSF associate member #7257
## to the top of X11/Protocol/Connection/INETSocket.pm

our $SOCKET_CLASS;

$SOCKET_CLASS
= ((eval { require IO::Socket::INET6 })
   ? IO::Socket::INET6
   : do { require IO::Socket::INET; IO::Socket::INET; })
unless (defined ($SOCKET_CLASS));

## the ‘open’ function is then to be changed as follows:

#  my($host, $dispnum) = @_;
# -my($sock) = IO::Socket::INET-new('PeerAddr' = $host,
# +my($sock) = $SOCKET_CLASS-new   ('PeerAddr' = $host,
#    'PeerPort' = 6000 + $dispnum,
#    'Type' = SOCK_STREAM(),
#    'Proto' = tcp);
#  croak Can't connect to display `$host:$dispnum': $! unless $sock;

Bug#731985: maxima Depends: on gnuplot-x11, which is not strictly necessary

[Ivan Shmakov]

Package: maxima
Version: 5.31.3-5

The current version of the ‘maxima’ package in Debian Jessie
Depends: on gnuplot-x11, which is not necessary to “provide a
significant amount of functionality.”  For instance, replacing
gnuplot-x11 with a dummy Provides: gnuplot-x11 package results
in the test suite being passed:

$ maxima --batch-lisp=testsuite.lisp 

Maxima 5.31.3 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.10 (a.k.a. GCL)
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
T
$ 

Neither the interactive sessions seem to be affected in any way
(besides, obviously, of the inability to produce plots in X.)

I therefore suggest downgrading the dependency to either
Recommends: or Suggests:, as per §7.2 of the policy:

⋯✂⋯ http://debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps ⋯✂⋯

The Depends field should be used if the depended-on package is
required for the depending package to provide a significant amount
of functionality.

⋯

The Recommends field should list packages that would be found
together with this one in all but unusual installations.

⋯✂⋯ http://debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps ⋯✂⋯

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731592: dig -x: allow querying arbitrary reverse zones

[Ivan Shmakov]

Package:  dnsutils
Version:  1:9.8.4.dfsg.P1-6+nmu3
Severity: wishlist

As currently implemented, dig(1) provides a -x convenience
option to query the reverse DNS in-addr.arpa, ip6.arpa, and
ip6.int zones.

It seems a natural extension, however, to allow querying
arbitrary “reverse” zones, such as, for instance, used by
various DNS black- and whitelists.  Consider, e. g.:

$ dig -z l2.apews.org -x 200.11.173.11 

The default query type in this case may be either A (as used in
the lists) or PTR.

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730394: Refuse to go to Fit-width when in Fullscreen-mode

[Ivan Shmakov]

forwarded 730394 http://bugs.pwmt.org/issue297
## and perhaps also:
# reopen 730394
# tag 730394 fixed-upstream
thanks

 Sebastian Ramacher sramac...@debian.org writes:
 On 2013-11-24 19:26:06, Juhapekka Tolvanen wrote:

[…]

  This is because in fullscreen mode only basic movement keys are
  mapped.  You can simply map a and s in fullscreen mode and have the
  functionality available.  Put the following two lines in
  ~/.config/zathura/zathurarc:

  map [fullscreen] a adjust_window best-fit
  map [fullscreen] s adjust_window with

I know of no sane reason for these key bindings to differ
between fullscreen and windowed modes.

Neither does the upstream, who meanwhile have fixed this bug.

 mlq and added a fullscreen mode that has the same key bindings per
 mlq default as the normal mode.  It can be toggled with F11.

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#726571: RlwrapFilter.pm should be /usr/share/perl5/App/Rlwrap/Filter.pm

[Ivan Shmakov]

 Mike Miller mtmil...@ieee.org writes:
 On Wed, Oct 16, 2013 at 18:56:33 +, Ivan Shmakov wrote:

  The conventional namespace for application-specific Perl modules is
  App::⟨package name⟩::⟨module name…⟩.

  Can you give some examples or references?

Perhaps I was a bit mistaken on this one, as CPAN seem to
generally mix module (as in: Local::Example) and distribution
(Local-Example) naming conventions.  Still, consider, e. g.:

⋯ ✂ ⋯ https://pause.perl.org/pause/query?ACTION=pause_namingmodules#App ⋯ ✂ ⋯
  App
  You can distribute applications as Perl distributions.  Typically,
  those sorts of distributions go under the App namespace, like
  App::Ack, App::Cpan, and App::Prove.  The namespace implies that
  its a ready-to-use program rather than a module.
⋯ ✂ ⋯ https://pause.perl.org/pause/query?ACTION=pause_namingmodules#App ⋯ ✂ ⋯

  I see a few but not enough that I'd call it a convention.  As opposed
  to simply $PACKAGE::$MODULE...

I’d expect the latter convention to be followed in the case of
bigger “library-first” projects (like DBD::*, for instance.)
I wouldn’t deem it appropriate to grab a top-level namespace for
less than a handful of modules.  (And the Pause’s page quoted
above seem to agree on that.)

[…]

  Therefore, my suggestion would be to move RlwrapFilter.pm from
  /usr/share/rlwrap to /usr/share/perl5/App/Rlwrap/Filter.pm, and edit
  its ‘package’ line (as well as the filters’ ‘use’ lines)
  respectively.  (In order to preserve compatibility, a “redirecting”
  .pm may be installed at the former location.)

  This will bring the module in line with the other Perl modules in
  Debian, and will allow for a Perl filter to be started with simple
  ‘use App::Rlwrap::Filter;’ instead of the current form, which
  explicitly the Perl module search path (as shown below.)

  Do you have any other reasons for wanting to make this change, some
  added functionality or benefit that would come from doing this
  reorganization?

Being unfamiliar with rlwrap(1), I’ve implemented a crude but
seemingly useful work-alike in Perl.  While I’m not planning to
release it anytime soon (now that I’ve learned that rlwrap(1)
fits my needs more than I’ve initially thought), it’s possible
that it will borrow the rlwrap’s protocol, and thus filters
based on RlwrapFilter.pm will no longer be specific to rlwrap.

Other than that, I’m somewhat concerned with the “hiding” of the
Perl modules done by Debian packages.  My guess is that some of
them could very well find certain uses unanticipated by their
respective authors.

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#518796: mktemp: does not create a temporary file if the template lacks X characters

[Ivan Shmakov]

 Olivier Mehani shtrom-deb...@ssji.net writes:

[…]

  I don’t think this bug can be confirmed anymore, but the
  documentation should be clarified.  Probably an upstream task again.

As reported, the issue reads:

 AK I type $ mktemp -t test /tmp/test so, it not create temprary file
 AK with unique name but in all *BSD systems such command will create
 AK file with template test. this may bring problems of
 AK incompatibility of shell scripts

My guess is that such an incompatibility between GNU and *BSD
mktemp(1) implementations may still be an issue, even if
Severity: wishlist.  This way or the other, such an issue is up
to the upstream to resolve, though.

FTR: mktemp(1) is not POSIX, so I’m as of yet unsure if it’s
suitable for portable Shell scripts at all.

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#728334: RFP: libtree-rb-perl: Pure-Perl implementation of red-black trees

[Ivan Shmakov]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-p...@lists.debian.org
Tags: rfp

* Package name: libtree-rb-perl
  Version : 0.54
  Upstream Author : Arun Prasaad
* URL : https://metacpan.org/release/ARUNBEAR/Tree-RB-0.54
* License : Perl (GPL-1+ or Artistic)
  Programming Lang: Perl
  Description : Pure-Perl implementation of red-black trees

This CPAN distribution is one of just a few implementations of
self-balancing search trees in Perl.  Indeed, other than this
one, I know of only Tree::AVL and Tree::RedBlack
(libtree-redblack-perl.)  And, Tree::RB is better than either!

Namely, this is the /only/ such implementation that allows for
“inexact” key matching.

Specifically, the search trees require that the keys are
elements from an ordered set.  (Contrary to the Perl hashes, for
instance.)  So, it feels rather natural to be able to request an
element whose key is “either 8, or the greatest of those
available not greater than 8.”  And this implementation provides
such a feature.

Other than that, the upstream maintainer appears to be
responsive, and the package – maintained.  (FWIW, the last
version came this September.)

TIA.  (And hope to see this one in Debian soon.)

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#692116: /usr/bin/nsupdate: nsupdate: wrongly escapes semicolons in updates

[Ivan Shmakov]

 Benoit Panizzon paniz...@woody.ch writes:

  Package: dnsutils Version: 1:9.7.3.dfsg-1~squeeze7 Severity: normal
  File: /usr/bin/nsupdate

  When someone uses DNSSEC signed zones, you don't go and edit those
  zonefiles manualy as this would break the signatures.

  So you use nsupdate to manage your zones, so bind can take care of
  correct signatures.

  Now I wanted to start using DKIM and update my zone with a TXT record
  containing the public key:

[…]

  mail._domainkey.woody.ch. 300   IN  TXT v=DKIM1\; g=*\; k=rsa\; 
  p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCoPEw05hVDRt7ogyCMkrdfIJqA2Byrf/i+c9oGhNRS1YTGohtUjaZibbcg44Tw9Sbx9OxmR+jauhGprUKTF9vXFRe4hBvFdXE1PNw/L5x8Sb9UJ8SCdKLn3tyBEKqaqEIbYy7UFeZuE6MwLn1crGyOie0xiOgyzoWMP4/9WW7/5QIDAQAB

  nsupdate is wrongly adding a \ character before all the ;
  characters.

  Is there a chance for this to be fixed in a future update?

Somehow, I belive it isn’t a bug, but rather a feature of the
‘show’ nsupdate(1) subcommand.  Consider, for instance (as of
1:9.7.3.dfsg-1~squeeze6):

 update add  a2013295._domainkey.siamics.net.86400   IN  TXT   
  k=rsa; t=s; 
 p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCwfB7heSXsla7eqbkZGy673aysYdM6BsdIt/dJEG/BC3TZmFTjPdSRZa2uceLVKfvjm1SqfXpD3a+utLrmjPQsIAvhfy2TXvzag9ggVpARFKQ6MqEQCHTYT4QplZ7Lc5jzpX+KMyyAQwTYJekoUQc3pMHXxYUpdulDfrSs4JQWOwIDAQAB
  
 show 
Outgoing update query:
;; -HEADER- opcode: UPDATE, status: NOERROR, id:  0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
a2013295._domainkey.siamics.net. 86400 IN TXT   k=rsa\; t=s\; 
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCwfB7heSXsla7eqbkZGy673aysYdM6BsdIt/dJEG/BC3TZmFTjPdSRZa2uceLVKfvjm1SqfXpD3a+utLrmjPQsIAvhfy2TXvzag9ggVpARFKQ6MqEQCHTYT4QplZ7Lc5jzpX+KMyyAQwTYJekoUQc3pMHXxYUpdulDfrSs4JQWOwIDAQAB

 

Now, despite the escaped semicolons in the ‘show’ output, as
well as the one of dig(1) (see below), the signatures appear to
pass validation performed by check-auth at verifier.port25.com.

$ dig +short txt a2013295._domainkey.siamics.net. 
k=rsa\; t=s\; 
p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCwfB7heSXsla7eqbkZGy673aysYdM6BsdIt/dJEG/BC3TZmFTjPdSRZa2uceLVKfvjm1SqfXpD3a+utLrmjPQsIAvhfy2TXvzag9ggVpARFKQ6MqEQCHTYT4QplZ7Lc5jzpX+KMyyAQwTYJekoUQc3pMHXxYUpdulDfrSs4JQWOwIDAQAB
$ 

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#236900: dnsutils: runidn man page but no script/binary

[Ivan Shmakov]

 Anand Kumria wildf...@progsoc.org writes:

  Package: dnsutils Version: 1:9.2.3-2 Severity: normal

  The dnsutils package contains the man page for runidn (which looks
  somewhat handy) but neither the script (or binary).  Please either
  include the script/binary or remove the man page.

AIUI, this issue is long time resolved.  Neither of the searches
[1–3] over stable’s, oldstable’s or testing’s Contents seem to
show any files named like that.

[1] 
http://packages.debian.org/search?searchon=contentskeywords=runidnmode=filenamesuite=stablearch=any
[2] 
http://packages.debian.org/search?searchon=contentskeywords=runidnmode=filenamesuite=oldstablearch=any
[3] 
http://packages.debian.org/search?searchon=contentskeywords=runidnmode=filenamesuite=testingarch=any

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#454075: dnsutils: abort with +nssearch +vc

[Ivan Shmakov]

 Justin Pryzby jpryzb...@quoininc.com writes:

  Package: dnsutils Version: 1:9.4.2-1

  dig +nssearch +vc google.com
  socket.c:1390: REQUIRE(socketp != ((void *)0)  *socketp == ((void *)0)) 
  failed.
  sh: line 1: 14321 Aborted dig +nssearch +vc google.com

This appears to have been fixed sometime between
1:9.7.3.dfsg-1~squeeze11 and 1:9.8.4.dfsg.P1-6+nmu3.

-- 
FSF associate member #7257


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#672808: aylet: couldn't open sound device.

[Ivan Shmakov]

severity 672808 normal
thanks

 Dmitry Semyonov linu...@gmail.com writes:

  Package: aylet Version: 0.5-3 Severity: important

  aylet is compiled to use OSS driver, and it seems OSS compatibility
  layer is not installed by default in Debian Wheezy.  As a workaround,
  one can install alsa-oss package and start aylet as follows:

  $ aoss aylet *.ay

Given that there’s such a simple workaround, I’ve taken the
liberty to lower the severity down to normal.

  Probably, there are other ways to solve the problem, but if going the
  suggested way it would be good to add alsa-oss into the list of aylet
  dependencies, and specifically mention the workaround in
  README.Debian.

However, I believe that alsa-oss should /not/ be in Depends:,
for aylet(1) can also be used on a completely mute system.
(Think of a file server performing automated .ay to .oga
conversion, for instance.)

Suggests: seems to be a safe choice, though.

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#510051: Control keys do not work when aylet is started via xargs

[Ivan Shmakov]

 Krystian Wlosek kwlo...@gmail.com writes:

  tags 510051 wontfix thanks

  Use command similar to the following to reproduce:

  echo AgentX.ay AgentX2.ay |xargs aylet

JFTR, using xargs(1) with an interactive program doesn’t seem
like a very clever idea, for with the number of passed command
arguments being sufficiently large, xargs(1) may choose to
(or even have to) invoke the command specified several times in
a row, each time giving it a portion of the arguments’ list.

The real solution to this issue would be to add support for the
conventional --files-from= option.  (And also --null.)
 
  aylet reads keys codes from standard input, stdin is connected to
  proper terminal (tty).  xargs replace this stdin by own pipe not
  connected with terminal, so aylet doesn't receive any control keys.

I’d argue that should such a condition be detected (via
isatty ()), aylet(1) should just re-open its terminal, as in:

   /* call ctermid () to get the tty filename */
   int tty_fd
 = open (tty, O_RDONLY);
   /* check for errors */
   int rv
 = dup2 (tty_fd, STDIN_FILENO);
   /* check for errors */

Given that this issue has such a trivial fix, I see no reason
not to implement it.

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#499422: listings/lstdrvrs.dtx: deficiencies in Lisp and SQL language definitions

[Ivan Shmakov]

[Bringing the issues “up-upstream,” as per the suggestion of a
Debian TeX Maintainer.]

The Debian bug tracking system has the following reports filed,
related to the Listings package you’re listed as a maintainer
of.  (I’ve checked the latest revision of lstdrvrs.dtx, which
appears to be 2013-08-26 1.5b, as available from CTAN, and they
still seem to apply.)

Could you please take a look at them, and possibly apply the
changes suggested?

[Please keep Cc: to 499422-forwar...@bugs.debian.org,
626521-forwar...@bugs.debian.org when replying, so that the
conversation will be properly recorded at the Debian BTS.]

TIA.

http://bugs.debian.org/499422

The ‘Lisp’ language is defined with ‘sensitive,% ???’, while
it’s argued that it should be ‘sensitive=false,%’ instead, as
Lisp is generally a case-insensitive language.  (Although the
dialects’ behavior may differ on this.)

http://bugs.debian.org/626521

The ‘SQL’ language’s definition lists END as a keyword, but not
BEGIN (also a valid SQL keyword, AFAIK.)  It was suggested that
the latter also be added.

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#726571: RlwrapFilter.pm should be /usr/share/perl5/App/Rlwrap/Filter.pm

[Ivan Shmakov]

Package: rlwrap
Version: 0.37-3
Severity: wishlist

The conventional namespace for application-specific Perl modules
is App::⟨package name⟩::⟨module name…⟩.  Moreover, the
conventional directory for Perl modules is /usr/share/perl5, and
indeed, – it’s already in @INC, while /usr/share/rlwrap isn’t.

Therefore, my suggestion would be to move RlwrapFilter.pm from
/usr/share/rlwrap to /usr/share/perl5/App/Rlwrap/Filter.pm, and
edit its ‘package’ line (as well as the filters’ ‘use’ lines)
respectively.  (In order to preserve compatibility, a
“redirecting” .pm may be installed at the former location.)

This will bring the module in line with the other Perl modules
in Debian, and will allow for a Perl filter to be started with
simple ‘use App::Rlwrap::Filter;’ instead of the current form,
which explicitly the Perl module search path (as shown below.)

use lib ($ENV{RLWRAP_FILTERDIR} or .);
use RlwrapFilter;

AIUI, the non-standard RLWRAP_FILTERDIR becomes completely
unnecessary after the change, but may be retained for
compatibility with the filters following the current convention.

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#726438: New GNU Forth version available

[Ivan Shmakov]

Source: gforth
Version: 0.7.0+ds2-0.1

As per http://gnu.org/s/gforth/, the latest released GNU Forth
version is 0.7.2, released 2013-02-25.

Please consider updating the Debian package.

-- 
FSF associate member #7257


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#689136: gforth: This is about to become a worse than wishlist problem

[Ivan Shmakov]

 Reuben Thomas r...@sc3d.org writes:

  Package: gforth Version: 0.7.0+ds1-7 Followup-For: Bug #689136

  Emacs 24.3 has hit sid, and therefore installing gforth on a system
  with emacs24 already installed, or vice versa, will stop working.

Worse still, Emacs 24.3 has since entered testing.  The end
result is that # dpkg --configure fails for emacs24 if gforth is
also installed.

  If a solution can't quickly be found that will work equally well
  upstream, then indeed removing the calls to byte-compile for the
  Debian forth.el seems like a good temporary solution.

Seconded.

[…]

-- 
FSF associate member #7257


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725955: xsltproc (libxslt?) HTTP requests lack User-Agent: that http://www.w3.org/ requires

[Ivan Shmakov]

Package: xsltproc
Version: 1.1.28-2

As per strace(1), xsltproc(1) (and perhaps the underlying
libxslt library itself) uses HTTP/1.0, while http://www.w3.org/
seems to require an User-Agent: HTTP/1.1 request header.

10:04:44 sendto(5, GET /TR/xhtml1/DTD/xhtml1-strict.dtd HTTP/1.0\r\nHost: 
www.w3.org\r\nAccept-Encoding: gzip\r\n\r\n, 90, 0, NULL, 0) = 90

The end result is that an attempt to load a DTD from W3 (such
as: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd) fails:

10:04:59 recvfrom(5, HTTP/1.0 500 Server Error\r\nCache-Control: 
no-cache\r\nConnection: close\r\nContent-Type: 
text/html\r\n\r\nhtmlbodyh1500 Server Err..., 4096, 0, NULL, NULL) = 185

-- 
FSF associate member #7257


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org