Bug#912768: hplip-data: hp-toolbox fsck
On Mon 05 Nov 2018 at 21:41:58 +0100, Cristian Ionescu-Idbohrn wrote: > On Mon, 5 Nov 2018, Brian Potkin wrote: > > On Sun 04 Nov 2018 at 23:21:14 +, Brian Potkin wrote: > > > > > avahi-deamon is essential; there were no instructions to uninstall it. > > > Without it you will be unable to detect the DNS-SD broadcasts of the > > > printer/scanner device. Put it back. > > > > Please forget about this, it is nonsense. > > Right. I'll say that much. I don't intend to follow the avahi track. > > I just wish the bugs are fixed in 3.18.10+dfsg0-1, specially when > patches are readily available. Just like other distributions (ubuntu, > mint, arch, fedora, and so on do already) do. So, please patch. The > little I digged in upstream bug DB, reported bugs (those that concern > me) seem to be buried, although solutions exist :( > > 3.17.10+repack0-5 (in testing) is working for me as expected (with a > minimally patched models.dat). The downgraded to 3.17.10+repack0-5 in > unstable (with the same patch) is also usable, but not working as > well. I see this kind of messages in the syslog (in unstable): > > hp-toolbox(UI)[1127]: warning: Supplies information not available for this > device. > /hpfax: [1292]: error: Failed to create/var/spool/cups/tmp/.hplip > xpraforwarder: '/usr/lib/cups/backend/xpraforwarder' > python3: io/hpmud/hpmud.c 246: invalid channel_open state, current > io_mode=raw/uni service=HP-MESSAGE > hp:/net/HP_ColorLaserJet_MFP_M278-M281?ip=192.168.x.y > hpcups[3963]: prnt/hpcups/Hbpl1.cpp 52: Hbpl1 constructor : m_szLanguage = > HBPL1 > hp[7978]: prnt/backend/hp.c 919: ERROR: null print job total=0 > > and others. > > The hplip* packages are highly rated in popcon (~40%). So, that shows > the importance of stabilizing the hplip* packages. It would be useful to have what happens with scanimage -d "hpaio:/net/HP_ColorLaserJet_MFP_M278-M281?ip=192.168.x.y" > out.pnm for 3.18.10+dfsg0-1. Does the scanner work? Do you get out.pnm? Cheers, Brian.
Bug#912768: hplip-data: hp-toolbox fsck
On Mon, 5 Nov 2018, Brian Potkin wrote: > On Sun 04 Nov 2018 at 23:21:14 +, Brian Potkin wrote: > > > avahi-deamon is essential; there were no instructions to uninstall it. > > Without it you will be unable to detect the DNS-SD broadcasts of the > > printer/scanner device. Put it back. > > Please forget about this, it is nonsense. Right. I'll say that much. I don't intend to follow the avahi track. I just wish the bugs are fixed in 3.18.10+dfsg0-1, specially when patches are readily available. Just like other distributions (ubuntu, mint, arch, fedora, and so on do already) do. So, please patch. The little I digged in upstream bug DB, reported bugs (those that concern me) seem to be buried, although solutions exist :( 3.17.10+repack0-5 (in testing) is working for me as expected (with a minimally patched models.dat). The downgraded to 3.17.10+repack0-5 in unstable (with the same patch) is also usable, but not working as well. I see this kind of messages in the syslog (in unstable): hp-toolbox(UI)[1127]: warning: Supplies information not available for this device. /hpfax: [1292]: error: Failed to create/var/spool/cups/tmp/.hplip xpraforwarder: '/usr/lib/cups/backend/xpraforwarder' python3: io/hpmud/hpmud.c 246: invalid channel_open state, current io_mode=raw/uni service=HP-MESSAGE hp:/net/HP_ColorLaserJet_MFP_M278-M281?ip=192.168.x.y hpcups[3963]: prnt/hpcups/Hbpl1.cpp 52: Hbpl1 constructor : m_szLanguage = HBPL1 hp[7978]: prnt/backend/hp.c 919: ERROR: null print job total=0 and others. The hplip* packages are highly rated in popcon (~40%). So, that shows the importance of stabilizing the hplip* packages. -- cii
Bug#912768: hplip-data: hp-toolbox fsck
On Sun 04 Nov 2018 at 23:21:14 +, Brian Potkin wrote: > avahi-deamon is essential; there were no instructions to uninstall it. > Without it you will be unable to detect the DNS-SD broadcasts of the > printer/scanner device. Put it back. Please forget about this, it is nonsense. Cheers, Brian.
Bug#912993: printer-driver-cups-pdf: creates wrong filename using short title
Package: printer-driver-cups-pdf Version: 3.0.1-5 Severity: normal Dear Maintainer, using the cups-pdf printer with a short document title (< 32 chars) results in faulty generated filename. This don't affect titles >= 32 chars. example: lp -d PDF -t short INPUT.pdf result: a generated PDF file named "short__rtin_PDF.pdf" (in this case, file name seems to be the target path (/home/martin/PDF) with first characters replaced by the title in some magically appeared brackets) expected: a generated PDF file named "short.pdf" in /home/martin/PDF/ some logging: [DEBUG] now extracting postscript code [DEBUG] found title in ps code: (short) rtin/PDF Mon Nov 5 16:49:30 2018 [DEBUG] found end of postscript code: %%EOF [DEBUG] all data written to spoolfile: /var/spool/cups-pdf/SPOOL/cups2pdf-10959 [DEBUG] trying to use PS title: (short) rtin/PDF [STATUS] ***Experimental Option: DecodeHexStrings [DEBUG] checking for hex strings: (short) rtin/PDF [DEBUG] not a hex string, has no start marker: (short) rtin/PDF [DEBUG] calling alternate_replace_string [DEBUG] removing alternate special characters from title: (short) rtin/PDF [DEBUG] removing leading _ from title: _short__rtin_PDF [DEBUG] title successfully retrieved: short__rtin_PDF [DEBUG] input data read from stdin [DEBUG] output filename created: /home/martin/PDF/short__rtin_PDF.pdf [DEBUG] ghostscript commandline built: /usr/bin/gs -q -dCompatibilityLevel=1.2 -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite -sOutputFile="/home/martin/PDF/short__rtin_PDF.pdf" -dAutoRotatePages=/PageByPage -dAutoFilterColorImages=false -dColorImageFilter=/FlateEncode -dPDFSETTINGS=/prepress -c .setpdfwrite -f /var/spool/cups-pdf/SPOOL/cups2pdf-10959 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages printer-driver-cups-pdf depends on: ii cups2.2.8-5 ii cups-client 2.2.8-5 ii ghostscript 9.25~dfsg-4 ii libc6 2.27-6 ii libcups22.2.8-5 ii libpaper-utils 1.1.24+nmu5 printer-driver-cups-pdf recommends no packages. Versions of packages printer-driver-cups-pdf suggests: ii system-config-printer 1.5.11-3 -- no debconf information
Re: Wireless scan
On Mon 05 Nov 2018 at 22:29:36 +0900, Ioan Stan wrote: > Thank you, I’ll then give it a try. Does Debian have drivers for HP > all-in-one, or it also depends on the model? For most, yes. This list might help: https://developers.hp.com/hp-linux-imaging-and-printing/supported_devices/index Those which are not listed but which have AirPrint are also probably supported. https://wiki.debian.org/DriverlessPrinting -- Brian.
Re: Wireless scan
Thank you, I’ll then give it a try. Does Debian have drivers for HP all-in-one, or it also depends on the model? Ioan > On Nov 5, 2018, at 22:02, Brian Potkin wrote: > > On Mon 05 Nov 2018 at 21:41:54 +0900, Ioan Stan wrote: > >> It is Brother DCP-J963N > > You will have to see what drivers Brother (Japan) offer. > > -- > Brian. >
Re: Wireless scan
On Mon 05 Nov 2018 at 21:41:54 +0900, Ioan Stan wrote: > It is Brother DCP-J963N You will have to see what drivers Brother (Japan) offer. -- Brian.
Re: Wireless scan
It is Brother DCP-J963N Thank you, ioan > On Nov 5, 2018, at 21:37, Brian Potkin wrote: > > On Mon 05 Nov 2018 at 20:48:46 +0900, Ioan Stan wrote: > >> Hi all, >> >> I’ve got a Brothers all-in-one wireless scanner. Is there a way toi >> use from Debian GNOME? > > What model is it? > > -- > Brian. >
Re: Wireless scan
On Mon 05 Nov 2018 at 20:48:46 +0900, Ioan Stan wrote: > Hi all, > > I’ve got a Brothers all-in-one wireless scanner. Is there a way toi > use from Debian GNOME? What model is it? -- Brian.
Wireless scan
Hi all, I’ve got a Brothers all-in-one wireless scanner. Is there a way to use from Debian GNOME? Many thanks, ioan
