Processed: tagging 942055
Processing commands for cont...@bugs.debian.org: > tags 942055 + confirmed Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Added tag(s) confirmed. > thanks Stopping processing here. Please contact me if you need assistance. -- 942055: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942055 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#950690: marked as done (cups-filters: Printing fails with an error about Grayscale/monochrome conversion)
Your message dated Wed, 5 Feb 2020 23:06:49 + with message-id <05022020230145.b8d518645...@desktop.copernicus.org.uk> and subject line Re: Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion has caused the Debian Bug report #950690, regarding cups-filters: Printing fails with an error about Grayscale/monochrome conversion to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 950690: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950690 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: cups-filters Version: 1.27.0-2 Severity: important Hi, since “some” time (few weeks maybe, I guess the 1.27.0 upload), I can't print on my Brother HL-5250DN network printer (which was working just fine earlier). The printer is laser monochrome, and I always was able to print color and monochrome stuff, conversion was happening just fine. Now, when I try to print, nothing happens and I guess an error in the logs about: W [04/Feb/2020:21:28:45 +0100] [Job 570] Grayscale/monochrome printing requested for this job but Poppler is not able to convert to grayscale/monochrome PostScript. W [04/Feb/2020:21:28:45 +0100] [Job 570] Use \"pdftops-renderer\" option (see README file) to use Ghostscript or MuPDF for the PDF -> PostScript conversion. First, it's really not obvious from the log *which* README this is about, and I had to dig a little before finding it was the one from cups-filters. Then, I tried to set pdftops-renderer-default to various options (gs, pdftocairo) using: lpadmin -p printer -o pdftops-renderer-default= but it didn't work. With: - gs: nothing prints, but nothing happens in the logs - pdftocairo: same error message than without any option - pdftops: same error With mupdf it does send something to the printer but the results shows: ERROR NAME; undefined COMMAND; ° OPERAND STACK; and in the logs I get: W [04/Feb/2020:21:34:29 +0100] [Job 573] Level 3 PostScript not supported by mutool. Downgrading to 1.26.2 from testing seems to fix the problem (I still have the log entry, though, it seems, so maybe it's unrelated). Regards, -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (450, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cups-filters depends on: ii bc 1.07.1-2+b2 ii cups-filters-core-drivers 1.27.0-2 ii ghostscript9.50~dfsg-5 ii libc6 2.29-9 ii libcups2 2.3.1-4 ii libcupsfilters11.27.0-2 ii libfontconfig1 2.13.1-2+b1 ii libfontembed1 1.27.0-2 ii libgcc-s1 [libgcc1]10-20200202-1 ii libgcc11:9.2.1-25 ii libqpdf26 9.1.1-1 ii libstdc++6 10-20200202-1 ii poppler-utils 0.71.0-6 Versions of packages cups-filters recommends: ii colord 1.4.4-1 ii liblouis-bin 3.12.0-3 ii liblouisutdml-bin 2.8.0-3 Versions of packages cups-filters suggests: pn antiword pn docx2txt pn foomatic-db-compressed-ppds | foomatic-db ii imagemagick8:6.9.10.23+dfsg-2.1+b2 ii imagemagick-6.q16 [imagemagick]8:6.9.10.23+dfsg-2.1+b2 -- Configuration Files: /etc/modules-load.d/cups-filters.conf changed: -- no debconf information --- End Message --- --- Begin Message --- On Wed 05 Feb 2020 at 20:14:27 +0100, Yves-Alexis Perez wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Wed, 2020-02-05 at 19:32 +0100, Till Kamppeter wrote: > > Probably the best is to try to print without using PostScript. When > > creating a print queue and selecting your printer's make, model, and > > driver manually, have a look at PCL 6/XL (pxlmono) or PCL 5e > > (ljet4/ljet4d/hpcups/hpijs) options. > > So, I'm even more confused. I've upgraded again cups-filters (to 1.27.0-2) in > order to do a comparison check, and tried to print, and it did work (with the > Brother PPD, unchanged). If I understand you correctly, you are now printing successfully. In that case we now have nothing to take action on. Consequently, I will close the report. Thank
Re: Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
On 05/02/2020 20:14, Yves-Alexis Perez wrote: So, I'm even more confused. I've upgraded again cups-filters (to 1.27.0-2) in order to do a comparison check, and tried to print, and it did work (with the Brother PPD, unchanged). This looks strange, there is no change in the pdftops filter which could have changed something before the last release. Or try running the command driverless This doesn't return anything. My printer is on the network but I don't think it advertises itself using Bonjour/zeroconf, so I'm unsure if it'd be enough for that to find it. driverless printing is a rather new property in network printers. It started some years ago with AirPrint to make iPhones be able to print when connecting to the local network via the WLAN of the router. Generally printers advertised to print from phones support at least one form of driverless printing, AirPrint in most cases. Typically the network printers launched in the last 5 years do driverless but your printer can be older. "driverless" lists all IPP printers which support driverless printing. Till
Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
I have tried it also and with the command line cupsfilter -p ../HL5250DN.ppd -i text/plain -m application/vnd.cups-postscript -e ~/.bashrc > out.ps 2>log I got valid PostScript output with a PJL header. Note that I had to specify both input and output MIME types. Probably in the cases whenthe printer does not print CUPS sends valid PJL and PostScript but some PostScript interpreter bug in the printer prevents it from printing. You can try to send the PostScript output of the command line above to your printer without further filtering, either do lp -d -o raw out.ps or nc -w1 9100 < out.ps Please try. Till
Re: Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 2020-02-05 at 19:32 +0100, Till Kamppeter wrote: > Probably the best is to try to print without using PostScript. When > creating a print queue and selecting your printer's make, model, and > driver manually, have a look at PCL 6/XL (pxlmono) or PCL 5e > (ljet4/ljet4d/hpcups/hpijs) options. So, I'm even more confused. I've upgraded again cups-filters (to 1.27.0-2) in order to do a comparison check, and tried to print, and it did work (with the Brother PPD, unchanged). > > Or try running the command > > driverless This doesn't return anything. My printer is on the network but I don't think it advertises itself using Bonjour/zeroconf, so I'm unsure if it'd be enough for that to find it. - -- Yves-Alexis -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl47FBMACgkQ3rYcyPpX RFtdsAf8D6wygO1CWSEe/xm1ZS5EkItg8zU4w69VvGmx/oeGAhd1KszecD2NwCkn 1SauiLt/POdnpCHCaiFpgzkHqmsXEW4IMg6rUxSawkLUnEgSeRW+UQT052VlNCWY S9WvJxzoDDDQWjIUAX0oGy6fSDc9J61092S+TEBKwREtqifo2SdsBJ1DK0O9lOZp LGY8RAdrJgL/XoIZnh30yJMTXqTG3KTuUMolTWBQeqQ0QR0VcQxhPVFZijcO8+5S 5PU8njwahwPXU7taZDCVcOtekboxMU8vSNJf9Gk7gkOxFEioMdSqaCLWCb3UGZyv u83o2BbBxdtgY6g/BzRJCbh/39J2wA== =wKgw -END PGP SIGNATURE-
Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
On Wed 05 Feb 2020 at 20:05:27 +0100, Yves-Alexis Perez wrote: > On Wed, 2020-02-05 at 17:19 +, Brian Potkin wrote: > > > Not really sure, but I don't think so. I mean, I'm using the PPD file > > > from cups Debian packages, not anything from Brother. > > > > As root, what do you get for > > > > grep "*NickName" /etc/cups/ppd/ > > *NickName: "Brother HL-5250DN BR-Script3" > > The ppd is Copyright(C) 2005 Brother Industries, Ltd. so even if I have it > from Debian, it still comes from Brother. It is basically the same as the one I have from Brother. > > Do you know the package name? > > Not really, but I's the one cups (either the web interface or system-config- > printer) shows me when using make & model. We'll let that go. It is something for me to sort out. > > > > I did test how filtering went with it > > > > and a file or two. I got no errors, but did get the warnings you > > > > got. Then again, I do not have the printer to print the output > > > > file to. > > > > > > Not entirely sure what is your workflow here, but with some details > > > maybe I can try to reproduce what you did and see if something goes out > > > of the printer? > > > > Later, certainly. I'd like to test with your PPD first. > > Attached. Thanks. I used it (as root) with cupsfilter -p /etc/cups/ppd/ -m printer/foo -e /etc/nsswitch > out.ps 2>log There aren't any errors in the log. Regards, Brian.
Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
On Wed, 2020-02-05 at 17:19 +, Brian Potkin wrote:
> > Not really sure, but I don't think so. I mean, I'm using the PPD file
> > from cups Debian packages, not anything from Brother.
>
> As root, what do you get for
>
> grep "*NickName" /etc/cups/ppd/
*NickName: "Brother HL-5250DN BR-Script3"
The ppd is Copyright(C) 2005 Brother Industries, Ltd. so even if I have it
from Debian, it still comes from Brother.
>
> Do you know the package name?
Not really, but I's the one cups (either the web interface or system-config-
printer) shows me when using make & model.
>
> > > I did test how filtering went with it
> > > and a file or two. I got no errors, but did get the warnings you
> > > got. Then again, I do not have the printer to print the output
> > > file to.
> >
> > Not entirely sure what is your workflow here, but with some details
> > maybe I can try to reproduce what you did and see if something goes out
> > of the printer?
>
> Later, certainly. I'd like to test with your PPD first.
Attached.
>
> Open a new issue referring to #169 and referencing the Debian report.
I saw your other mail so I'm postponing that. I'll also check the steps from
Till
Regards,
--
Yves-Alexis
*PPD-Adobe: "4.3"
*% This program is free software; you can redistribute it and/or modify it
*% under the terms of the GNU General Public License as published by the Free
*% Software Foundation; either version 2 of the License, or (at your option)
*% any later version.
*%
*% This program is distributed in the hope that it will be useful, but WITHOUT
*% ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
*% FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
*% more details.
*%
*% You should have received a copy of the GNU General Public License along with
*% this program; if not, write to the Free Software Foundation, Inc., 59 Temple
*% Place, Suite 330, Boston, MA 02111-1307 USA
*%
*%
*% Copyright(C) 2005 Brother Industries, Ltd.
*% "Brother HL-5250DN BR-Script3"
*%
*% General Information Keywords
*FormatVersion: "4.3"
*FileVersion: "1.03"
*LanguageEncoding: ISOLatin1
*LanguageVersion: English
*Manufacturer: "Brother"
*PCFileName: "BR5250_2.PPD"
*Product: "(Brother HL-5250DN series)"
*PSVersion: "(3010.106) 5"
*ShortNickName: "Brother HL-5250DN BR-Script3"
*ModelName: "Brother HL-5250DN BR-Script3"
*NickName: "Brother HL-5250DN BR-Script3"
*1284DeviceID: "MFG:Brother;MDL:HL-5250DN series;CMD:PJL,PCL,PCLXL,POSTSCRIPT;"
*% Basic Device Capabilities =
*LanguageLevel: "3"
*TTRasterizer: Type42
*ColorDevice: False
*DefaultColorSpace: Gray
*FileSystem: True
*?FileSystem:"
save
/devname (%disk0%) def
/ret false def
0 1 7{
devname exch 48 add 5 exch put
devname devstatus {
0 ne {/ret true def}if
pop pop pop pop pop pop pop
}if
}for
ret {(True)}{(False)} ifelse = flush
restore
"
*End
*Throughput: "28"
*FreeVM: "605"
*% Emulations and Protocols ==
*Protocols: PJL TBCP
*SuggestedJobTimeout: "0"
*SuggestedWaitTimeout: "300"
*PrintPSErrors: True
*% PostScript Patches ==
*%*JobPatchFile 1: "statusdict/setusbbinary known{statusdict begin true
setusbbinary end}if"
*% JCL Features ==
*JCLBegin: "<1B>%-12345X@PJL JOB<0A>"
*JCLToPSInterpreter: "@PJL ENTER LANGUAGE = POSTSCRIPT <0A>"
*JCLEnd: "<1B>%-12345X@PJL EOJ <0A><1B>%-12345X"
*% Installable Options ===
*OpenGroup: InstallableOptions/Options Installed
*OpenUI *OptionTrays/Number of Input Trays: PickOne
*DefaultOptionTrays: 1Trays
*OptionTrays 1Trays/ 1: ""
*OptionTrays 2Trays/ 2: ""
*OptionTrays 3Trays/ 3: ""
*?OptionTrays:"
save
<>setpagedevice currentpagedevice/BRFeeder get
2 eq{(3Trays)}{
<>setpagedevice currentpagedevice/BRFeeder get
1 eq{(2Trays)}{(1Trays)}ifelse
}ifelse
= flush
restore
"
*End
*CloseUI: *OptionTrays
*CloseGroup: InstallableOptions
*UIConstraints: *OptionTrays 1Trays *InputSlot Tray2
*UIConstraints: *InputSlot Tray2 *OptionTrays 1Trays
*UIConstraints: *OptionTrays 1Trays *InputSlot Tray3
*UIConstraints: *InputSlot Tray3 *OptionTrays 1Trays
*UIConstraints: *OptionTrays 2Trays *InputSlot Tray3
*UIConstraints: *InputSlot Tray3 *OptionTrays 2Trays
*% Media Selection ==
*OpenUI *PageSize: PickOne
*OrderDependency: 30 AnySetup *PageSize
*DefaultPageSize: A4
*PageSize Letter/Letter: "<< /PageSize [612 792] /ImagingBBox null >>
setpagedevice"
*PageSize Legal/Legal: "<< /PageSize [612 1008] /ImagingBBox null >>
setpagedevice"
*PageSize Executive/Executive: "<< /PageSize [522 756] /ImagingBBox null >>
setpagedevice"
*PageSize A4/A4: "<< /PageSize [595 842] /ImagingBBox null
Re: Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
The warning about not being able to convert color input into grayscale is principally no problem for you, as monochrome PostScript printers can receive color input without any problems, they convert the input by themselves. What this warning tells to me is that you upgraded from a cups-filters version from before the fix of this issue https://github.com/OpenPrinting/cups-filters/issues/169 PS Level 1 forced for grayscale PDF rendering with Poppler/Cairo to one afterwards. Without the fix of this issue your printer had most probably received PostScript Level 1 and happily printed it. Now it is receiving PostScript Level 2. Brother PostScript printers are known to have many bugs in their PostScript interpreters and therefore we have already a big bunch of workarounds in our pdftops filter. Probably the best is to try to print without using PostScript. When creating a print queue and selecting your printer's make, model, and driver manually, have a look at PCL 6/XL (pxlmono) or PCL 5e (ljet4/ljet4d/hpcups/hpijs) options. Or try running the command driverless If it lists a URI (Unified Resource Identifier) for your printer (contains your printers host name, IP, or make/model), try to set up your printer with lpadmin -p Printers -E -v URI -m everywhere replacing URI by your printer's URI from the "driverless" output. Does this work? Till
Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
On Wed 05 Feb 2020 at 17:19:31 +, Brian Potkin wrote: > Open a new issue referring to #169 and referencing the Debian report. Sorry; I should have suggested leaving doing this until we both have had the opportunity to test the filtering system. Regards, Brian.
Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
On Wed 05 Feb 2020 at 17:18:28 +0100, Yves-Alexis Perez wrote: > On Wed, Feb 05, 2020 at 03:29:22PM +, Brian Potkin wrote: > > Your issue seems connected with > > > > https://github.com/OpenPrinting/cups-filters/issues/169 > > > > and its associated bugs. > > When looking at the warning message in the logs I stumbled on that bug, > but didn't really find it really informative (especially since it's > closed while I still have the bug). I think using gs as the renderer is regarded as the fix but, TBH, I got a little lost when I started looking at the bugs linked from #169. > > I take it you are using the PostScript > > PPD provided by Brother. > > Not really sure, but I don't think so. I mean, I'm using the PPD file > from cups Debian packages, not anything from Brother. As root, what do you get for grep "*NickName" /etc/cups/ppd/ Do you know the package name? > > I did test how filtering went with it > > and a file or two. I got no errors, but did get the warnings you > > got. Then again, I do not have the printer to print the output > > file to. > > Not entirely sure what is your workflow here, but with some details > maybe I can try to reproduce what you did and see if something goes out > of the printer? Later, certainly. I'd like to test with your PPD first. > > I am not sure I really understand all that is involved here, so, > > because you are able to provide first-hand experience, suggest > > you forward the issue upstream. > > Just to be sure: do you mean opening a new issue on upstream github, or > just commenting on the issue linked above? Open a new issue referring to #169 and referencing the Debian report. Regards, Brian.
Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
On Wed, Feb 05, 2020 at 03:29:22PM +, Brian Potkin wrote: > Your issue seems connected with > > https://github.com/OpenPrinting/cups-filters/issues/169 > > and its associated bugs. When looking at the warning message in the logs I stumbled on that bug, but didn't really find it really informative (especially since it's closed while I still have the bug). > I take it you are using the PostScript > PPD provided by Brother. Not really sure, but I don't think so. I mean, I'm using the PPD file from cups Debian packages, not anything from Brother. > I did test how filtering went with it > and a file or two. I got no errors, but did get the warnings you > got. Then again, I do not have the printer to print the output > file to. Not entirely sure what is your workflow here, but with some details maybe I can try to reproduce what you did and see if something goes out of the printer? > > I am not sure I really understand all that is involved here, so, > because you are able to provide first-hand experience, suggest > you forward the issue upstream. Just to be sure: do you mean opening a new issue on upstream github, or just commenting on the issue linked above? Regards, -- Yves-Alexis
Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
tags 950690 upstream thanks On Tue 04 Feb 2020 at 21:42:03 +0100, Yves-Alexis Perez wrote: > Package: cups-filters > Version: 1.27.0-2 > Severity: important > > Hi, > > since “some” time (few weeks maybe, I guess the 1.27.0 upload), I can't > print on my Brother HL-5250DN network printer (which was working just > fine earlier). > > The printer is laser monochrome, and I always was able to print color > and monochrome stuff, conversion was happening just fine. > > Now, when I try to print, nothing happens and I guess an error in the > logs about: > > W [04/Feb/2020:21:28:45 +0100] [Job 570] Grayscale/monochrome printing > requested for this job but Poppler is not able to convert to > grayscale/monochrome PostScript. > W [04/Feb/2020:21:28:45 +0100] [Job 570] Use \"pdftops-renderer\" option > (see README file) to use Ghostscript or MuPDF for the PDF -> PostScript > conversion. > > First, it's really not obvious from the log *which* README this is > about, and I had to dig a little before finding it was the one from > cups-filters. > > Then, I tried to set pdftops-renderer-default to various options (gs, > pdftocairo) using: > > lpadmin -p printer -o pdftops-renderer-default= > > but it didn't work. > > With: > > - gs: nothing prints, but nothing happens in the logs > - pdftocairo: same error message than without any option > - pdftops: same error > > With mupdf it does send something to the printer but the results shows: > > ERROR NAME; > undefined > COMMAND; > ° > OPERAND STACK; > > and in the logs I get: > > W [04/Feb/2020:21:34:29 +0100] [Job 573] Level 3 PostScript not > supported by mutool. > > Downgrading to 1.26.2 from testing seems to fix the problem (I still > have the log entry, though, it seems, so maybe it's unrelated). Thank you for your report, Yves-Alexis. Your issue seems connected with https://github.com/OpenPrinting/cups-filters/issues/169 and its associated bugs. I take it you are using the PostScript PPD provided by Brother. I did test how filtering went with it and a file or two. I got no errors, but did get the warnings you got. Then again, I do not have the printer to print the output file to. I am not sure I really understand all that is involved here, so, because you are able to provide first-hand experience, suggest you forward the issue upstream. Regards, Brian.
Processed: Re: Bug#950690: cups-filters: Printing fails with an error about Grayscale/monochrome conversion
Processing commands for cont...@bugs.debian.org: > tags 950690 upstream Bug #950690 [cups-filters] cups-filters: Printing fails with an error about Grayscale/monochrome conversion Added tag(s) upstream. > thanks Stopping processing here. Please contact me if you need assistance. -- 950690: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950690 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#950669: cups-browsed: segfault at 0 ip 00000000f79ffb5b sp 00000000fffd3828 error 4 in libc-2.29.so
Dixi quod… > A core dump would probably have been helpful… hmm… I’ll start > it again with ulimit -c unlimited and see if I can’t get one, > iff it dumps one _and_ I figure out where. Today, cups-browsed simply isn’t running (according to “ps ax”), but I don’t have a segfault in dmesg or ANYTHING about it in syslog and can’t find a coredump either. I did: --- /etc/init.d/cups-browsed +++ /etc/init.d/cups-browsed @@ … @@ case "$1" in start) log_begin_msg "Starting $DESC: $NAME" mkdir -p `dirname "$PIDFILE"` +ulimit -c unlimited start-stop-daemon --start --oknodo --background $SSD_OPTIONS --exec $DAEMON log_end_msg $? ;; bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg ** Mit der tarent Academy bieten wir auch Trainings und Schulungen in den Bereichen Softwareentwicklung, Agiles Arbeiten und Zukunftstechnologien an. Besuchen Sie uns auf www.tarent.de/academy. Wir freuen uns auf Ihren Kontakt. **
Processed: Re: Bug#942055: ghostscript in buster partly broken on armel?
Processing control commands: > reassign -1 ghostscript Bug #942055 [cups-filters] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Bug reassigned from package 'cups-filters' to 'ghostscript'. Ignoring request to alter found versions of bug #942055 to the same values previously set Ignoring request to alter fixed versions of bug #942055 to the same values previously set > fixed -1 9.26a~dfsg-0+deb9u6 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as fixed in versions ghostscript/9.26a~dfsg-0+deb9u6. > fixed -1 9.26a~dfsg-0+deb9u1 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as fixed in versions ghostscript/9.26a~dfsg-0+deb9u1. > fixed -1 9.25~dfsg-0+deb9u1 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as fixed in versions ghostscript/9.25~dfsg-0+deb9u1. > found -1 9.27~dfsg-3.1 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as found in versions ghostscript/9.27~dfsg-3.1. > found -1 9.27~dfsg-3 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as found in versions ghostscript/9.27~dfsg-3. > found -1 9.27~dfsg-2+deb10u3 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as found in versions ghostscript/9.27~dfsg-2+deb10u3. > found -1 9.27~dfsg-2+deb10u1 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as found in versions ghostscript/9.27~dfsg-2+deb10u1. > found -1 9.26a~dfsg-2 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as found in versions ghostscript/9.26a~dfsg-2. > found -1 9.26a~dfsg-1 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as found in versions ghostscript/9.26a~dfsg-1. > fixed -1 9.26a~dfsg-0+deb9u5 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as fixed in versions ghostscript/9.26a~dfsg-0+deb9u5. > found -1 9.26~dfsg-2 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as found in versions ghostscript/9.26~dfsg-2. > found -1 9.26~dfsg-1 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as found in versions ghostscript/9.26~dfsg-1. > found -1 9.25~dfsg-7 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as found in versions ghostscript/9.25~dfsg-7. > found -1 9.25~dfsg-2 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as found in versions ghostscript/9.25~dfsg-2. > found -1 9.24~~rc2~dfsg-1 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as found in versions ghostscript/9.24~~rc2~dfsg-1. > fixed -1 9.22~dfsg-1 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as fixed in versions ghostscript/9.22~dfsg-1. > fixed -1 9.21~dfsg-1 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as fixed in versions ghostscript/9.21~dfsg-1. > fixed -1 9.20~dfsg-3.2 Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Marked as fixed in versions ghostscript/9.20~dfsg-3.2. -- 942055: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942055 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#942055: ghostscript in buster partly broken on armel?
[ sent again to please Debian MTAs rejecting 8bit headers ] control: tag -1 wontfix Quoting Bernhard Übelacker (2020-02-04 20:13:41) > Control: fixed -1 9.26a~dfsg-0+deb9u6 > Control: fixed -1 9.26a~dfsg-0+deb9u1 > Control: fixed -1 9.25~dfsg-0+deb9u1 > Control: found -1 9.27~dfsg-3.1 > Control: found -1 9.27~dfsg-3 > Control: found -1 9.26a~dfsg-2 > Control: found -1 9.26a~dfsg-1 > Control: found -1 9.26~dfsg-2 > Control: found -1 9.26~dfsg-1 > Control: found -1 9.25~dfsg-7 > Control: found -1 9.25~dfsg-2 > Control: found -1 9.24~~rc2~dfsg-1 > Control: fixed -1 9.22~dfsg-1 > Control: fixed -1 9.21~dfsg-1 > Control: fixed -1 9.20~dfsg-3.2 > > > Hello, > tried to get a little further. > > The last version from sid that did not show this error > was 9.22~dfsg-1. All other good version seem to be created > as security updates, where I cannot find the build logs. Most notable change between 9.22 and 9.24 - and also applied to various degree in security updates - was a security fix affecting interpretation of Postscript code. Yes, it broke existing working code, but (as I understand it) only existing _insecurely_ working code. The change is highly unlikely to get reverted: Instead, reverse dependencies of Ghostscript need to apply fixes to tighten their code to avoid those Postscript routines identified as being insecure and therefore no longer permitted (or if certain that security is ensured in other ways then explicitly disable the safety measures). Please do not reassign these bugs to Ghostscript, even though provable that they are "fixed" by downgrading Ghostscript. The fix needs to be applied at the consumer end. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#942055: ghostscript in buster partly broken on armel?
control: reassign -1 ghostscript Control: fixed -1 9.26a~dfsg-0+deb9u6 Control: fixed -1 9.26a~dfsg-0+deb9u1 Control: fixed -1 9.25~dfsg-0+deb9u1 Control: found -1 9.27~dfsg-3.1 Control: found -1 9.27~dfsg-3 control: found -1 9.27~dfsg-2+deb10u3 control: found -1 9.27~dfsg-2+deb10u1 Control: found -1 9.26a~dfsg-2 Control: found -1 9.26a~dfsg-1 control: fixed -1 9.26a~dfsg-0+deb9u5 Control: found -1 9.26~dfsg-2 Control: found -1 9.26~dfsg-1 Control: found -1 9.25~dfsg-7 Control: found -1 9.25~dfsg-2 Control: found -1 9.24~~rc2~dfsg-1 Control: fixed -1 9.22~dfsg-1 Control: fixed -1 9.21~dfsg-1 Control: fixed -1 9.20~dfsg-3.2 [ sent again to please Debian MTAs rejecting 8bit headers ] Hi Bernhard, Quoting Bernhard Übelacker (2020-02-05 15:06:02) > Am 05.02.20 um 11:02 schrieb Jonas Smedegaard: > > Hi Alexander, > > > > Quoting Alexander Reichle-Schmehl (2020-02-05 08:45:05) > >> Am 2020-02-04 22:09, schrieb Jonas Smedegaard: > >> > >>> Most notable change between 9.22 and 9.24 - and also applied to > >>> various degree in security updates - was a security fix affecting > >>> interpretation of Postscript code. > >> > >> Maybe a stupid question, but does that fix work? I'm just wondering, > >> if the firx triggers a problem on one arm but not on amd64, is it > >> working? > > > > Fair question. > > > > Ghostscript is (mainly) a Postscript interpreter. > > > > To investigate if the cause for this issue is a) Ghostscript > > _interpreting_ differently on arm than on amd64, or a tool further back > > in the chain _producing_ different code for Ghostscript to interpret, it > > seems to me that we need someone to isolate the actual code fed into > > Ghostscript. > > > > I maintain the Ghostscript package, but am not skilled in the various > > tools using Ghostscript. It seems more sensible to me to first > > investigate toolchain problems further back in the chain, where (I > > assume) it is better known how to isolate the data forwarded down the > > chain. > > > I guess this is what I did in previous message 33 ? Ohh, indeed! Great details and smells strongly of the bug being in Ghostscript. I am hereby re-re-re-assigning and reviving versions... (weird - I received your later emails fine but that one crucial message is not in by mailsystem - I must've simply hit the wrong key when processing it, sorry!) > There I attached file foomatic-9RyCd0 which is fed by cups into > ghostscript. Yes, got it. Thanks! > I have put the ghostscript command line parameter also in message 33. Yes. Got it. Will try on an armel box I got... > I continued testing and a package "9.25~dfsg-7" compiled in an > unstable chroot as of date 2017-12-07 produces a working package. But > a package "9.25~dfsg-7" built inside a unstable chroot as of date > 2018-01-01 crashes in gx_filter_edgebuffer, like current version in > buster 9.27~dfsg-2+deb10u3 with "-dDEBUG" set. > > Therefore I guess this could be related to the switch from gcc-7 > 7.2.0-16 to gcc-7 7.2.0-18 in that time frame. (The -18 raised the > baseline to armv5te.) That would at least explain why the stretch > stable update packages do not show the problem (e.g. > 9.26a~dfsg-0+deb9u6), as they should be built with stretch's gcc-6. > > But without pointing to an exact instruction or function I cannot > prove it. So are there any hints how to further debug ghostscript in > that regard? Might be helpful if you could provide the stdout and stderr outputs of _only_ running the Ghostscript command - executed on amd64 and armel for easy comparison. Also might be helpful to do the same passing additional option -dTTFDEBUG (as that seems to show more detail in the aread where it seems to fail). ...or if some of above is already covered in your previously provided debugging.txt then if you could help point exactly where... I say "might" above because really this is more geeky than I can handle myself, so I am just guessing what upstream might find helpful - in other words: it would be even more helpful if (above more narrow test still fails then) you would file this directly as a bugreport upstream at https://bugs.ghostscript.com/ as it sounds like you would be better at guiding them than I am. Kind regards, and sorry for missing that crucial previous post, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#942055: ghostscript in buster partly broken on armel?
Hello Jonas, thanks for taking time for this bug. Am 05.02.20 um 11:02 schrieb Jonas Smedegaard: > Hi Alexander, > > Quoting Alexander Reichle-Schmehl (2020-02-05 08:45:05) >> Am 2020-02-04 22:09, schrieb Jonas Smedegaard: >> >>> Most notable change between 9.22 and 9.24 - and also applied to >>> various degree in security updates - was a security fix affecting >>> interpretation of Postscript code. >> >> Maybe a stupid question, but does that fix work? I'm just wondering, >> if the firx triggers a problem on one arm but not on amd64, is it >> working? > > Fair question. > > Ghostscript is (mainly) a Postscript interpreter. > > To investigate if the cause for this issue is a) Ghostscript > _interpreting_ differently on arm than on amd64, or a tool further back > in the chain _producing_ different code for Ghostscript to interpret, it > seems to me that we need someone to isolate the actual code fed into > Ghostscript. > > I maintain the Ghostscript package, but am not skilled in the various > tools using Ghostscript. It seems more sensible to me to first > investigate toolchain problems further back in the chain, where (I > assume) it is better known how to isolate the data forwarded down the > chain. I guess this is what I did in previous message 33 ? There I attached file foomatic-9RyCd0 which is fed by cups into ghostscript. I have put the ghostscript command line parameter also in message 33. This file, seems to be just a PDF, is interpreted by ghostscript at amd64 without issue. But gives the message "Can't handle format 4" at an armv5tel/armel (real hardware, QNAP, Feroceon 88FR131). And even worse it might manifests just on armv5tel/armel, in my qemu armv7/armel VM it works without problems too. Therefore I guess you are right and this is not an issue of ghostscript, but could be compiler related. I continued testing and a package "9.25~dfsg-7" compiled in an unstable chroot as of date 2017-12-07 produces a working package. But a package "9.25~dfsg-7" built inside a unstable chroot as of date 2018-01-01 crashes in gx_filter_edgebuffer, like current version in buster 9.27~dfsg-2+deb10u3 with "-dDEBUG" set. Therefore I guess this could be related to the switch from gcc-7 7.2.0-16 to gcc-7 7.2.0-18 in that time frame. (The -18 raised the baseline to armv5te.) That would at least explain why the stretch stable update packages do not show the problem (e.g. 9.26a~dfsg-0+deb9u6), as they should be built with stretch's gcc-6. But without pointing to an exact instruction or function I cannot prove it. So are there any hints how to further debug ghostscript in that regard? Kind regards, Bernhard
Processed: Re: Bug#942055: ghostscript in buster partly broken on armel?
Processing commands for cont...@bugs.debian.org: > reassign 942055 cups-filters Bug #942055 [ghostscript] cups-filters: Fails to print on Brother HL-2035 (foomatic/kl1250) with ghostscript 9.27~dfsg-2+deb10u2 armel Bug reassigned from package 'ghostscript' to 'cups-filters'. No longer marked as found in versions ghostscript/9.26a~dfsg-2, ghostscript/9.26~dfsg-1, ghostscript/9.27~dfsg-2+deb10u3, ghostscript/9.25~dfsg-2, ghostscript/9.26a~dfsg-1, ghostscript/9.24~~rc2~dfsg-1, ghostscript/9.27~dfsg-3.1, ghostscript/9.26~dfsg-2, ghostscript/9.25~dfsg-7, ghostscript/9.27~dfsg-3, and ghostscript/9.27~dfsg-2+deb10u1. No longer marked as fixed in versions ghostscript/9.26a~dfsg-0+deb9u1, ghostscript/9.25~dfsg-0+deb9u1, ghostscript/9.26a~dfsg-0+deb9u6, ghostscript/9.20~dfsg-3.2, ghostscript/9.22~dfsg-1, and ghostscript/9.21~dfsg-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 942055: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942055 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#942055: ghostscript in buster partly broken on armel?
reassign 942055 cups-filters thanks Hi Jonas! * Jonas Smedegaard [200205 11:02]: > > I'm open for suggestion on how to continue next, but have honestly. If > > I should fill a bug against an other package, please let me know which > > one, as I have no idea, how these parts are interacting with each > > other. > > Seems to me that this bugreport was initially filed against > cups-filters, and then reassigned to ghostscript by you. > > My suggestion is simply to revert that reassignment. Seems ressonable, thanks for the hint and your work! Best regards, Alexander
Re: Printing packaging rework 2020
+1 from me, too. Make it Debian-first. We at Ubuntu will sync the Debian package, as we do with most printing-related packages currently. Till On 05/02/2020 07:44, Didier 'OdyX' Raboud wrote: By all means, please do it, but please make it Debian-first. I'd be very happy to review and upload your wosk to Debian! Le February 5, 2020 6:26:49 AM UTC, Alexander Pevzner a écrit : On 2/5/20 12:07 AM, Till Kamppeter wrote: Someone needs to package ipp-usb. I think I can do it on Ubuntu (which should not be very different from Debian)
