Re: Bug#610014: /usr/bin/pdftops: pdftops doesn't rotate landscape pages

2014-05-24 Thread Pino Toscano 

Source: poppler
Source-Version: 0.26.0-1

On 2013-12-05 21:24, Didier 'OdyX' Raboud wrote:

Control: affects -1 src:cups-filters

Le vendredi, 14 janvier 2011, 21.05:30 Emil a écrit :
A landscape PDF was produced and then printed with lpr. The print 
was

incorect because it was not rotated. I'm using magicfilter on my
system for printing (this is not relevant though) and my printer
filter calls pdftops and then the PostScript file is passed to
ghostscript for printing.

If I add the paper parameter to pdftops like this
"0 %PDF fpipe /usr/bin/pdftops -paper A4 $FILE -"
then the printing is correct and the created PS file is properly
marked/rotated

This bug also affects printing from xpdf but there is no workaround
for xpdf because xpdf uses common libraries with pdftops and when it
sends the file to the printer it is already converted to PS and
setting the psPaperSize to A4 in /etc/xpdf/xpdfrc has no effect.

This bug appeared in the last 3-4 months, before that both pdftops 
and

xpdf were printing properly.


As Till mentionned on the debian-printing list [0], there is a patch
available on the upstream bug tracker that addresses this bug [1].

Please backport it to poppler so that the workaround in cups-filters 
can

be dropped.

[0] http://lists.debian.org/debian-printing/2013/12/msg5.html
[1] https://bugs.freedesktop.org/show_bug.cgi?id=72312


All the patches in fdo#72312 have been reviewed, improved, rewritten,
tested, and pushed in the past development serie 0.25.x, and they are
part of Poppler 0.25.2.

Thus, closing with the first Poppler release uploaded to Debian
(that is 0.26.0, the new stable serie).

I have no idea yet about having Poppler 0.26.x in unstable/testing
(it mostly depends on Inkscape compiling with it), but I will try to
have it in Jessie.

(A backport is not feasible, since the patches break API/ABI of
libpoppler.)

Thanks,
--
Pino Toscano


--
To UNSUBSCRIBE, email to debian-printing-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/0cac8ccbc3b6ee285e50e7b309234...@pino.toscano.name

Bug#751196: cups-filters: please enable parallel building

2014-06-10 Thread Pino Toscano 
Source: cups-filters
Version: 1.0.54-1
Severity: normal
Tags: patch

Hi,

cups-filters seems to build fine with multiple build jobs when building.
Thus, my suggestion is to enable the parallel build (with the
--parallel option of dh) to speed up the compilation when requested
(see also Policy §4.9.1).

Thanks,
-- 
Pino
--- a/debian/rules
+++ b/debian/rules
@@ -5,7 +5,7 @@ derives_from_ubuntu := $(shell (dpkg-ven
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
 %:
-	dh $@ --with autoreconf,systemd
+	dh $@ --parallel --with autoreconf,systemd
 
 override_dh_auto_configure:
 	dh_auto_configure -- \

Bug#867561: gksu, kdesu, etc dependencies not really needed

2017-12-30 Thread Pino Toscano 
tag 867561 + patch
thanks

Hi,

according to:
- base/password.py, __get_password_utils_ui
- installer/core_install.py, check_passwd_util
all the bits that use kdesu, kdesudo, gnomesu, and gksu are commented,
so the dependencies can be removed altogether.  Even because, looking
at them we have:
- gksu: deprecated, broken, #867236
- kdebase-bin & kdebase-runtime: transitional since Wheezy
  (oldoldstable)
- kde-runtime: it does not contain the "kdesu" binary in $PATH anymore
- kdesudo: deprecated, dropped, #875107
- ktsuss: dropped more than 6 years ago, #622270

Patch attached for this.

Thanks.
-- 
Pino Toscano--- a/debian/control
+++ b/debian/control
@@ -122,7 +122,6 @@ Description: HP Printers PostScript Desc
 Package: hplip-gui
 Architecture: all
 Depends: default-dbus-session-bus | dbus-session-bus,
- gksu | kdebase-bin (<< 4:4.4.0-1) | kde-runtime | kdebase-runtime | kdesudo | ktsuss,
  hplip (>= ${source:Version}),
  python3-dbus.mainloop.pyqt5,
  python3-pyqt5,


signature.asc
Description: This is a digitally signed message part.

Bug#947824: hplip: switch to libusb-1.0 on hurd

2019-12-31 Thread Pino Toscano 
Source: hplip
Version: 3.19.12+dfsg0-1
Severity: minor
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

hplip requires libusb-1.0, although on Hurd libusb-dev is still
required; attached there is a simple patch to switch any non-kfreebsd
platform to libusb-1.0.

Note: even with this change, hplip still will not compile on Hurd:
the code sort of assumes that either the system is Linux or macOS...

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -20,8 +20,7 @@ Build-Depends: autoconf,
libssl-dev,
libtool,
libudev-dev [linux-any],
-   libusb-1.0-0-dev [linux-any],
-   libusb-dev [!linux-any !kfreebsd-any],
+   libusb-1.0-0-dev [!kfreebsd-any],
libusb2-dev [kfreebsd-any],
patch,
policykit-1,

Re: Bug#977754: evince does not display EPS or PS files anymore and shows "Loading..." forever

2020-12-22 Thread Pino Toscano 
reassign 975387 libgs9 ghostscript/9.53.0~dfsg-1
retitle 975387 wrong size check for display_callback_v2_s struct
severity 975387 serious
forwarded 975387 https://bugs.ghostscript.com/show_bug.cgi?id=703301
tag 975387 + patch
merge 975387 975574

thanks

In data lunedì 21 dicembre 2020 18:23:12 CET, Simon McVittie ha scritto:
> > On my side, rebuilding libspectre1 solved this on my system.
> 
> If a simple rebuild with no source changes fixes the symptoms of a bug,
> that might indicate an unintended ABI break in libgs9, or perhaps a bug
> in the old libgs9 headers (but fixed in the new headers) in code that
> gets inlined into libspectre at compile time.

Both of them are issues in ghostscript anyway.

The rebuild, while "easy as it seems", does not consider an important
fact. From what I see, libgs got new APIs in 9.53.0, and libspectre
does not (optionally) use any of them. This means that a rebuild most
probably would not cause libspectre to require the newer ghostscript,
migrating instantly to testing. Considering that what we have here
smells like a behaviour change, this means making libspectre unusable
for the users of testing, and I do not find this acceptable.

I checked the changes between ghostscript 9.52.1 and 9.53.3, and I found
one thing: gs 9.53.0 reworks a bit the display device stuff, adding a
v3 device_callback struct, and keeping the support for what is now v2:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=eed3bad23510e59278bdaa5f7d0ab01fc1a1c21b;hp=04e937862eaa7e66bb9a87109874112cd354bf6f
display_callback is actually used in libspectre, see spectre-device.c.
Because it relies on DISPLAY_VERSION_MAJOR/DISPLAY_VERSION_MINOR, this
explains why it works after a rebuild, as it will use the
device_callback v3. This also shows that a rebuild is a no-no, as it
will get in the situation I described earlier (i.e. stop working with
ghostscript in testing).
There is actually code in ghostscript to support the old device_callback
(v2, as built in libspectre during the last built), as it can be see in
devices/gdevdsp.c, function display_check_structure:

static int display_check_structure(gx_device_display *ddev)
[...]
else if (ddev->callback->size == sizeof(struct display_callback_v2_s)) {
/* V2 structure with added display_separation callback */
if (ddev->callback->size != sizeof(display_callback))
return_error(gs_error_rangecheck);
[...]

Considering that:
- sizeof(struct display_callback_v2_s) != sizeof(display_callback);
  the addition to new stuff to display_callback was the reason for the
  new struct in the first place, so of course the two structs do not
  have the same size
- the last libspectre build uses display_callback v2, so the check:
  ddev->callback->size == sizeof(struct display_callback_v2_s)
  is true
then the check "ddev->callback->size != sizeof(display_callback)" will
be always false! Indeed, tried a simple patch to drop this, and evince
shows again PS files without rebuilding libspectre.
I submitted this as ghostscript bug:
https://bugs.ghostscript.com/show_bug.cgi?id=703301

Because of this, I'm reassigning 977754/975387 to ghostscript, merging
also 975574 to them, and setting the proper metadata. I'm also attaching
a copy of the patch I submitted upstream.

Thanks,
-- 
Pino Toscanodiff --git a/devices/gdevdsp.c b/devices/gdevdsp.c
index 0a66a0278..52087f8d6 100644
--- a/devices/gdevdsp.c
+++ b/devices/gdevdsp.c
@@ -1430,9 +1430,6 @@ static int display_check_structure(gx_device_display *ddev)
 }
 else if (ddev->callback->size == sizeof(struct display_callback_v2_s)) {
 /* V2 structure with added display_separation callback */
-if (ddev->callback->size != sizeof(display_callback))
-return_error(gs_error_rangecheck);
-
 if (ddev->callback->version_major != DISPLAY_VERSION_MAJOR_V2)
 return_error(gs_error_rangecheck);
 


signature.asc
Description: This is a digitally signed message part.

Bug#977754: evince does not display EPS or PS files anymore and shows "Loading..." forever

2021-01-02 Thread Pino Toscano 
In data domenica 27 dicembre 2020 03:53:01 CET, Jonas Smedegaard ha scritto:
> Version: 9.53.3~dfsg-6
> 
> Quoting Pino Toscano (2020-12-22 10:08:12)
> > In data lunedì 21 dicembre 2020 18:23:12 CET, Simon McVittie ha scritto:
> > > > On my side, rebuilding libspectre1 solved this on my system.
> > > 
> > > If a simple rebuild with no source changes fixes the symptoms of a 
> > > bug, that might indicate an unintended ABI break in libgs9, or 
> > > perhaps a bug in the old libgs9 headers (but fixed in the new 
> > > headers) in code that gets inlined into libspectre at compile time.
> > 
> > Both of them are issues in ghostscript anyway.
> 
> This was fixed in Ghostscript since release 9.53.3~dfsg-6 - I just 
> forgot to mention it in changelog (that will be corrected in next 
> release).

Oh nice, I did not notice it. I can confirm that using
- libgs9 9.53.3~dfsg-6
- libspectre1 0.2.9-1
- evince 3.38.0-3
there are no problems opening PS files in evince.

Thanks!
-- 
Pino Toscano

signature.asc
Description: This is a digitally signed message part.

Bug#663902: ghostscript: FTBFS on hurd-i386: extra gs_realloc in symbols file

2012-03-14 Thread Pino Toscano 
Package: src:ghostscript
Version: 8.70~dfsg-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hi,

as shown on [1], ghostscript fails to build on GNU/Hurd, because of a symbol
specified in the symbols file which is not compiled on GNU/Hurd.
The reason is basically the implementation of the gs_realloc() function: in
base/malloc_.h there is:
[...]
/* (At least some versions of) Linux don't have a working realloc */
#ifdef linux
#  define malloc__need_realloc
void *gs_realloc(void *, size_t, size_t);

#else
#  define gs_realloc(ptr, old_size, new_size) realloc(ptr, new_size)
#endif
[...]

which means gs_realloc() is a proper function only on Linux.
The proposed solution is to slightly change the symbol files, introducing a new
file with common Linux-only symbols, including it on Linux-only archs.
Tested, appears working on GNU/Hurd (obviously), and on current Squeeze.

[1] 
http://buildd.debian-ports.org/fetch.php?pkg=ghostscript&arch=hurd-i386&ver=8.70~dfsg-2&stamp=1251071245&file=log&as=raw

-- 
Pino Toscano
Index: ghostscript-8.70~dfsg/debian/libgs8.symbols.alpha
===
--- ghostscript-8.70~dfsg.orig/debian/libgs8.symbols.alpha	2009-09-10 15:30:50.0 +0200
+++ ghostscript-8.70~dfsg/debian/libgs8.symbols.alpha	2009-09-10 15:31:18.0 +0200
@@ -1,2 +1,3 @@
 #include "symbols.common"
+#include "symbols.common_linux"
 #include "symbols.common_le"
Index: ghostscript-8.70~dfsg/debian/libgs8.symbols.amd64
===
--- ghostscript-8.70~dfsg.orig/debian/libgs8.symbols.amd64	2009-09-10 15:30:50.0 +0200
+++ ghostscript-8.70~dfsg/debian/libgs8.symbols.amd64	2009-09-10 15:31:21.0 +0200
@@ -1,2 +1,3 @@
 #include "symbols.common"
+#include "symbols.common_linux"
 #include "symbols.common_le"
Index: ghostscript-8.70~dfsg/debian/libgs8.symbols.arm
===
--- ghostscript-8.70~dfsg.orig/debian/libgs8.symbols.arm	2009-09-10 15:30:50.0 +0200
+++ ghostscript-8.70~dfsg/debian/libgs8.symbols.arm	2009-09-10 15:31:30.0 +0200
@@ -1,3 +1,4 @@
 #include "symbols.common"
+#include "symbols.common_linux"
 #include "symbols.common_32bit"
 #include "symbols.common_le"
Index: ghostscript-8.70~dfsg/debian/libgs8.symbols.armel
===
--- ghostscript-8.70~dfsg.orig/debian/libgs8.symbols.armel	2009-09-10 15:30:51.0 +0200
+++ ghostscript-8.70~dfsg/debian/libgs8.symbols.armel	2009-09-10 15:31:34.0 +0200
@@ -1,3 +1,4 @@
 #include "symbols.common"
+#include "symbols.common_linux"
 #include "symbols.common_32bit"
 #include "symbols.common_le"
Index: ghostscript-8.70~dfsg/debian/libgs8.symbols.hppa
===
--- ghostscript-8.70~dfsg.orig/debian/libgs8.symbols.hppa	2009-09-10 15:30:51.0 +0200
+++ ghostscript-8.70~dfsg/debian/libgs8.symbols.hppa	2009-09-10 15:31:38.0 +0200
@@ -1,2 +1,3 @@
 #include "symbols.common"
+#include "symbols.common_linux"
 #include "symbols.common_32bit"
Index: ghostscript-8.70~dfsg/debian/libgs8.symbols.i386
===
--- ghostscript-8.70~dfsg.orig/debian/libgs8.symbols.i386	2009-09-10 15:30:52.0 +0200
+++ ghostscript-8.70~dfsg/debian/libgs8.symbols.i386	2009-09-10 15:31:45.0 +0200
@@ -1,3 +1,4 @@
 #include "symbols.common"
+#include "symbols.common_linux"
 #include "symbols.common_32bit"
 #include "symbols.common_le"
Index: ghostscript-8.70~dfsg/debian/libgs8.symbols.ia64
===
--- ghostscript-8.70~dfsg.orig/debian/libgs8.symbols.ia64	2009-09-10 15:30:53.0 +0200
+++ ghostscript-8.70~dfsg/debian/libgs8.symbols.ia64	2009-09-10 15:31:48.0 +0200
@@ -1,2 +1,3 @@
 #include "symbols.common"
+#include "symbols.common_linux"
 #include "symbols.common_le"
Index: ghostscript-8.70~dfsg/debian/libgs8.symbols.m68k
===
--- ghostscript-8.70~dfsg.orig/debian/libgs8.symbols.m68k	2009-09-10 15:30:53.0 +0200
+++ ghostscript-8.70~dfsg/debian/libgs8.symbols.m68k	2009-09-10 15:31:50.0 +0200
@@ -1,2 +1,3 @@
 #include "symbols.common"
+#include "symbols.common_linux"
 #include "symbols.common_32bit"
Index: ghostscript-8.70~dfsg/debian/libgs8.symbols.mips
===
--- ghostscript-8.70~dfsg.orig/debian/libgs8.symbols.m

Bug#666544: hplip: please migrate to kde-runtime

2012-03-31 Thread Pino Toscano 
Source: hplip
Version: 3.12.2-1
Severity: wishlist
Tags: patch

Hi,

since KDE SC 4.7, the kdebase-runtime source and binary have been
renamed to kde-runtime, and kdebase-runtime is now a transitional
metapackage.
Could you please add kde-runtime as alternative in the dependencies
of hplip-gui? Attached there is a patch for it.

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -76,7 +76,7 @@ Package: hplip-gui
 Architecture: all
 Depends: ${misc:Depends}, hplip (>= ${hplip:source:Version}), dbus-x11, 
  ${python:Depends}, python-qt4, python-qt4-dbus, 
- gksu | kdebase-bin (<< 4:4.4.0-1) | kdebase-runtime | kdesudo | ktsuss
+ gksu | kdebase-bin (<< 4:4.4.0-1) | kde-runtime | kdebase-runtime | kdesudo | ktsuss
 Recommends: xsane | simple-scan | skanlite, python-notify
 Description: HP Linux Printing and Imaging - GUI utilities (Qt-based)
  This package contains utilities with graphical user interface (GUI) for