#946617 dwww: runman prints empty content

Package:
dwww
Source:
dwww
Description:
Read all on-line documentation with a WWW browser
Submitter:
Chad Wallace
Date:
2020-12-21 22:24:02 UTC
Severity:
important
#946617#5
Date:
2019-12-11 23:18:42 UTC
From:
To:
Dear Maintainer,

After upgrading to buster, I failed to get any man pages showing in my
dwww output.  The <pre class="man"> tag is completely empty.

After editing dwww-convert for debugging, I found an error from man:
    man: nroff: Bad system call

Then, I found an example of that on another bug report, which led me to
add a line to dwww-convert:

...begin patch
--- dwww-convert.orig	2019-12-11 14:51:25.131093890 -0800
+++ dwww-convert	2019-12-11 15:14:02.625790098 -0800
@@ -246,6 +246,7 @@
     $dir =~ s/\/[^\/]*$//;
     chdir ("$dir/..") or die "Can't chdir!\n";
     $ENV{'MAN_KEEP_FORMATTING'} = 1;
+    $ENV{'MAN_DISABLE_SECCOMP'} = 1;
     my $IN_FH = &OpenPipe("man  -EUTF-8 -P/bin/cat  -l \"$filename\" 2>/dev/null | dwww-txt2html --man --utf8", "r");
     chdir ("/");
     while (<$IN_FH>) {
...end patch

That got it working... but I don't really know why. :-)
Hopefully this will lead you to the proper fix!

Thanks!
Chad.

#946617#10
Date:
2020-06-25 08:10:51 UTC
From:
To:
Hi,

I also observed this bug, and furthermore, also used the previously
suggested fix to correct it, i.e. adding


    $ENV{'MAN_DISABLE_SECCOMP'} = 1;

Also I think you might want to consider instead using *man2html* like
dpkg-www does, (or at least have it as an option), as I think it looks
much better in Firefox.

Thanks for a great tool!

#946617#15
Date:
2020-12-21 22:10:02 UTC
From:
To:
Chad Wallace writes:

Hi,

I cannot reproduce the issue myself, even after downgrading man-db to
2.8.5-2. The bug is almost a year old, can you still reproduce it yourself?

Anyway I am not sure if setting MAN_DISABLE_SECCOMP inside dwww would be
a good idea, as according to NEWS file in man-db sources, it would hide
issues which man-db wants to be notified about:

    * Confine most subprocesses that handle untrusted data using
      seccomp.  This mainly deals with subprocesses that perform
      encoding conversions, (de)compressors, groff programs, and a few
      other odds and ends.  groff programs use a slightly more
      permissive filter since they need to create temporary files, so
      additional path-based confinement (e.g. using AppArmor) is still
      useful.

      If this goes wrong, then MAN_DISABLE_SECCOMP=1 can be set in the
      environment to disable it, but please report any such problem as a
      bug.

I'm adding Collin for confirmation that the above is still valid, and
for a piece of advice what should I do with this bug report.


Regards,
Robert