I was stumbling over this today too… but a look at the code shows that
the log output is confusing.
On Wed, Jul 03, 2019 at 09:52:29AM +0200, martin f krafft wrote:
> Wed Jul 3 09:40:55 2019 [DEBUG] output filename created:
> /home/ssd/madduck/PDF/stdin___madduck_PDF.pdf
Here, the output
Quoting "intrigeri", who wrote on 2019-09-18 at 08:42 Uhr +0200:
Martin, could you please confirm this fixes the problem for you?
Thanks for looking into this. Unfortunately, adding /home/ssd to
HOMEDIRS and reloading apparmor didn't have the desired effect. I
was also not aware of actually
Control: tag -1 + moreinfo
Hi,
Brian Potkin:
> I wonder whether apparmor is involved? The journal is a place to look.
Indeed. It looks like Martin's $HOME directory is /home/ssd/madduck,
which is not covered by AppArmor's default @{HOME} tunable ("variable").
I suspect Martin will thus see
On Sat 06 Jul 2019 at 12:29:18 +0300, Martin-Éric Racine wrote:
> I made further tests on Stretch. My current packages:
>
> $ dpkg -l | grep -e ghostscript -e cups-pdf | awk '{print $2, $3}'
> ghostscript 9.26a~dfsg-0+deb9u3
> printer-driver-cups-pdf 2.6.1-22
>
> Test 1: print an UTF-8 text
I made further tests on Stretch. My current packages:
$ dpkg -l | grep -e ghostscript -e cups-pdf | awk '{print $2, $3}'
ghostscript 9.26a~dfsg-0+deb9u3
printer-driver-cups-pdf 2.6.1-22
Test 1: print an UTF-8 text file from Gedit. Works.
Test 2: print an ODF document from LibreOffice. Works.
ke 3. heinäk. 2019 klo 14.51 martin f krafft (madd...@debian.org) kirjoitti:
>
> I straced gs run directly (as user "nobody"), as well as gs run from
> cupsd. After replacing all hex addresses with 0xdeadbeef, the two
> traces are nigh identical, except cupsd seems to close FDs 0–2, so
> that when
I straced gs run directly (as user "nobody"), as well as gs run from
cupsd. After replacing all hex addresses with 0xdeadbeef, the two
traces are nigh identical, except cupsd seems to close FDs 0–2, so
that when run from cupsd, the first FD used is 0, whereas it's 3
otherwise.
Apart from
Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 14:13 Uhr +0300:
I just tried on my stable host. This used to work until a few weeks
ago, but it no longer does.
Can you reproduce the problem?
CUPS-PDF has not been updated, but Ghostscript has received
security updates twice in
ke 3. heinäk. 2019 klo 14.08 martin f krafft (madd...@debian.org) kirjoitti:
>
> Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 13:06 Uhr +0300:
> >My best guess is that you bumped into a symptom of upgrading from
> >cups-pdf 2 to cups-pdf 3. The back-end has changed and maintainer
>
Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 13:06 Uhr +0300:
My best guess is that you bumped into a symptom of upgrading from
cups-pdf 2 to cups-pdf 3. The back-end has changed and maintainer
scripts make no attempt to upgrade the backend used by any existing
PDF queue. If you
ke 3. heinäk. 2019 klo 12.40 martin f krafft (madd...@debian.org) kirjoitti:
>
> Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 11:18 Uhr +0300:
> >Is the host where this fails running a cups-pdf that was upgraded from
> >previous
> >releases?
>
> Yes, just like the other host too.
Quoting "Martin-Éric Racine", who wrote on 2019-07-03 at 11:18 Uhr +0300:
Is the host where this fails running a cups-pdf that was upgraded from previous
releases?
Yes, just like the other host too. These are ancient systems,
probably pre-sarge ;)
--
.''`. martin f. krafft @martinkrafft
Hey Martin,
Thanks for this bug report.
Is the host where this fails running a cups-pdf that was upgraded from
previous releases?
Martin-Éric
ke 3. heinäk. 2019 klo 11.09 martin f krafft (madd...@debian.org) kirjoitti:
> Package: printer-driver-cups-pdf
> Version: 3.0.1-5
> Severity: normal
Package: printer-driver-cups-pdf
Version: 3.0.1-5
Severity: normal
The PDF driver is failing to write the output PDFs. For example, a
command like
echo foo | lp -d PDF
yields the following DEBUG output in the log:
Wed Jul 3 09:40:55 2019 [DEBUG] *** Final Configuration ***
Wed Jul 3
14 matches
Mail list logo