Bug#998888: X-device: BadDrawable (invalid Pixmap or Window parameter)
Quoting Florian Lindemann (2021-11-30 10:36:53) > thank you for applying the patch that quickly, unfortunately it's not > fixing the issue, since my original patch was different, please have a > look at https://bugs.ghostscript.com/show_bug.cgi?id=704709 Ah, right. I'll fix this right away - thanks for reporting! - 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#1000710: ghostscript: Fails to convert EPS file using -sDEVICE=pngalpha
Quoting Hilmar Preuße (2021-11-29 10:48:30) > Am 27.11.2021 um 16:25 teilte Hilmar Preusse mit: > > Hi all, > > > Since gs 9.54 the conversion of some eps files does not work for > > at least one output devices. This came to my attention b/c the > > test suite of asymptote fails to run for at least one file. > > > I got the information that the issue has been solved in master: > > https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=d9d8db23e862707795e76ea8f8cdcf7434b2df65 > > I can confirm that the file in question now converts correctly. Great! Thanks for all your help with this, Hilmar! - 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#1000710: ghostscript: Fails to convert EPS file using -sDEVICE=pngalpha
Quoting Hilmar Preusse (2021-11-27 21:06:10) > Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=704737 > > On 27.11.21 Jonas Smedegaard (jo...@jones.dk) wrote: > > Hi, > > > Packaging changes is unlikely to affect this, so it is therefore > > better to report it upstream. I can do that, but better if you do > > this as you are in a better position to answer eventual followup > > questions related to asymptote as producer for that sample EPS > > file. > > > > Upstream bugtracker is here: https://bugs.ghostscript.com/ > > > Funny: I have already an account there. Submitted. Excellent. Thanks! - 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#1000710: ghostscript: Fails to convert EPS file using -sDEVICE=pngalpha
Hi Hilmar, Quoting Hilmar Preusse (2021-11-27 16:25:19) > Since gs 9.54 the conversion of some eps files does not work for at > least one output devices. This came to my attention b/c the test suite > of asymptote fails to run for at least one file. > > The sample test file is attached. Here are two command lines, the > first fails, the second not. Hence I'd assume it to be valid EPS code. > > gs -dBATCH -dNOPAUSE -sDEVICE=pngalpha -sOutputFile=a.png hatch_.eps > gs -dBATCH -dNOPAUSE -sDEVICE=png16 -sOutputFile=a.png hatch_.eps > > Not sure, why pngalpha is affected; I tested a view variants of png, > they seem to work fine. Thanks for reporting this issue! Packaging changes is unlikely to affect this, so it is therefore better to report it upstream. I can do that, but better if you do this as you are in a better position to answer eventual followup questions related to asymptote as producer for that sample EPS file. Upstream bugtracker is here: https://bugs.ghostscript.com/ Kind regards, - 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#998888: X-device: BadDrawable (invalid Pixmap or Window parameter)
Hi Florian, Quoting Florian Lindemann (2021-11-09 15:02:43) > I attached a simple patch that checks if the pixmap is created by > ghostview (xdev->ghostview is set) and only frees it if that's not the > case. Thanks - also for the detailed explanation. Since this is an issue in Ghostscript itself (not its packaging) and you are more knowledgeable than me, could you please report this upstream at the Ghostsript issue tracker yourself? https://bugs.ghostscript.com/ Kind regards, - 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#995392: ghostscript: ps2pdf trashes some characters
Quoting Vincent Lefevre (2021-11-04 16:49:34) > On 2021-11-03 18:06:50 +0100, Jonas Smedegaard wrote: > > Quoting Vincent Lefevre (2021-11-03 14:29:26) > > > This Debian bug actually covers several similar Ghostscript bugs. > > > > Please track each bug separately. Otherwise it is not possible to > > reliably track which bug affects which packaging releases. > > Done: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998458 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998461 > > I'm going to do tests against various ghostscript versions to see > which ones are affected (I've currently only tested the experimental > version ghostscript/9.55.0~~rc1~dfsg-1 for these bug reports). Thanks! -- * 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#995392: ghostscript: ps2pdf trashes some characters
Quoting Vincent Lefevre (2021-11-03 14:29:26) > This Debian bug actually covers several similar Ghostscript bugs. Please track each bug separately. Otherwise it is not possible to reliably track which bug affects which packaging releases. - 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#995392: ghostscript: ps2pdf trashes some characters
Control: severity -1 normal Quoting Vincent Lefevre (2021-09-30 16:53:01) > Package: ghostscript > Version: 9.54.0~dfsg-5 > Severity: grave > Justification: causes non-serious data loss > > The ps2pdf trashes some characters, making text non-searchable and > partly unreadable via pdftotext (even though the glyph appears to > be OK). There was no such issue in the recent past. I agree with Ken Sharp¹ that this issue is not grave for the ghostscript package as a whole - regardless of how important that feature of ghostscript is for your usecase. - Jonas ¹ https://bugs.ghostscript.com/show_bug.cgi?id=704478#c8 -- * 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#995392: ghostscript: ps2pdf trashes some characters
Quoting Vincent Lefevre (2021-10-01 15:53:38) > On 2021-10-01 14:31:57 +0200, Vincent Lefevre wrote: > > On 2021-10-01 14:26:02 +0200, Vincent Lefevre wrote: > > > On 2021-10-01 14:17:53 +0200, Vincent Lefevre wrote: > > > > In my archives, I can see that the issue occurred with > > > > ghostscript 9.26a~dfsg-0+deb9u1, but 9.27~dfsg-2+deb10u4 isn't > > > > affected on my second testcase. > > > > > > The following PDF file (on which I got the issue with ghostscript > > > 9.26a~dfsg-0+deb9u1) may be a useful testcase: > > > > > > https://hal.archives-ouvertes.fr/hal-02001080v1/document > > > > On this testcase, the issue is actually reproducible with > > ghostscript 9.27~dfsg-2+deb10u4! > > It seems that the issue partly comes from pdflatex: On an old file for > which ps2pdf was correct with ghostscript 9.53.3~dfsg-4, it is now > incorrect still with ghostscript 9.53.3~dfsg-4. But if I regenerate > the intermediate PDF file on an old Debian machine and transfer it to > my current machine, ps2pdf is correct with ghostscript 9.53.3~dfsg-4 > and with ghostscript 9.53.3~dfsg-7 (stable), and also with ghostscript > 9.54.0~dfsg-5. Are you sure you mean 9.53.3~dfsg-7, not 9.53.3~dfsg-7+deb11u1? Some upstream changes was backported for -7 and other changes was introduced by -7+deb11u1: https://tracker.debian.org/media/packages/g/ghostscript/changelog-9.53.3dfsg-7deb11u1 Possibly related to the recent changes to Ghostscripts SAFER: https://www.ghostscript.com/doc/9.55.0/Use.htm#Safer Perhaps recent pdflatex was adapted to handle the change to SAFER, and in doing so became dependent on recent Ghostscript (and perhaps that was then not reflected in packaging of pdflatex)? - 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#995392: ghostscript: ps2pdf trashes some characters
Quoting Vincent Lefevre (2021-09-30 18:28:51) > On 2021-09-30 17:18:46 +0200, Jonas Smedegaard wrote: > > This seems an upstream bug, and it would be helpful if you report it > > upstream as well. Their bugtracker is at https://bugs.ghostscript.com/ > > OK. I'll do it tonight (I could also try to find the cause). Great. Thanks! Also, you could test against the newer pre-release in experimental. - 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#995392: ghostscript: ps2pdf trashes some characters
Hi Vincent, Quoting Vincent Lefevre (2021-09-30 16:53:01) > The ps2pdf trashes some characters, making text non-searchable and > partly unreadable via pdftotext (even though the glyph appears to be > OK). There was no such issue in the recent past. Thanks for reporting this! This seems an upstream bug, and it would be helpful if you report it upstream as well. Their bugtracker is at https://bugs.ghostscript.com/ Kind regards, - 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#994270: another possible fix
Quoting Roderich Schupp (2021-09-15 12:22:55)
> > mark /usr/share/ghostscript/* as not-installed,
> > which is clearly bogus but seems the only (simple) way
> > to ignore only for arch-dependent builds;
>
>
> Another way to fix this is to use ${env:GS_DOT_VERSION} in
> libgs9-common.install
> (since you're already using debhelper-compat 13), see patch below.
> Note that dh_install for libgs9-common - even for a build=any - generates a
> file
> debian/.debhelper/generated/libgs9-common/installed-by-dh_install, but it only
> contains stuff gleaned from libgs9-common.install, not the explicit
> arguments given to dh_install.
> This is probably a debhelper bug.
Thanks, Roderich - that is indeed a more elegant approach!
- 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#994011: ghostscript: CVE-2021-3781
Hi Salvatore, Quoting Salvatore Bonaccorso (2021-09-09 19:20:08) > The following vulnerability was published for ghostscript. > > CVE-2021-3781[0]. I have prepared a package fixing this issue, available at https://salsa.debian.org/printing-team/ghostscript/-/tree/debian/bullseye Please tell how I should proceed with it - or feel free to proceed yourself from here. - 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#992889: /usr/sbin/update-gsfontmap: overly complicated
Hi наб, Quoting наб (2021-08-24 18:58:36) > The current approach that update-gsfontmap takes is very complicated, > to no apparent end, since all it achieves is concatenating all the > files; please consider the attached patch, which applies to every > version since 7e78b19759ab1e47a3636ffd5c922c536e6cad37 (November of > 2018) Your assesment is quite likely correct: that script hasn't been touched since ancient times where more complex font registration scripts were used in Debian (something called DeFoMa). Thanks for looking into this! Seems your patch is missing, however... - 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#425405: Not a bug
Hi Jonathan, Quoting Jonathan Nieder (2021-06-04 04:27:16) > Jonas Smedegaard wrote: > > I agree that this is unlikely a bug in Ghostscript. > > > > The test PDF provided by Jonathan Nieder _is_ searchable with Evince > > 3.38.2-1. > > > > If same file was not searchable with Evince available in January > > 2011, then the issue might be the encoding of the strings in the > > PDF, or it might be something else that confused that older release > > of Evince. > > > > But that test file was produced by LibreOffice. I would expect that > > a file generated by cups-pdf would instead have cups-pdf as creator > > in the metadata. > > > > I therefore suspect that the test PDF file should be ignored for > > this issue, and that the originally reported issue is a different > > one: > [...] > > For the record: If you suspect that an issue is in Ghostscript then > > please provide the ghostscript command that causes this issue - > > without that the only possible action is to tag it as unreproducible > > and close it, which is not really helpful. > > This response is puzzling. The example that I produced was a simple > postscript file and then a ps2pdf command that invokes ghostscript to > produce this issue. I don't understand why you're insisting > simultaneously that I should have > > - used cups-pdf instead of using ghostscript directly > - used ghostscript directly instead of using a larger pipeline that > invokes it > > since I don't see how those are possible to do at the same time. That last paragraph above was targeted others than you, Jonathan, and I agree: _Either_ investigate as cups-pdf issue _or_ as ghostscript issue. Let me try clarify by rephrasing the sentence I suspect caused confusion: If anyone still suspect that an issue is in Ghostscript then please provide the ghostscript command that causes it, like Jonathan did. Sorry for my ambiguity, and thanks for pointing it out, - 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#425405: Not a bug
Control: reassign -1 printer-driver-cups-pdf Control: unarchive 847462 Control: forcemerge -1 847462 Quoting alex (2021-06-03 09:36:51) > How Ghostscript can guess what Unicode code points > correspond to the characters in the sample PS file? > The PS file gives no clues at all. > > Modern programs can search the attached PDF file by > assuming that encoding is ASCII of some standard encoding > similar to ASCII.. > > IMHO it is not a bug. At least it is not a Ghostscript bug. I agree that this is unlikely a bug in Ghostscript. The test PDF provided by Jonathan Nieder _is_ searchable with Evince 3.38.2-1. If same file was not searchable with Evince available in January 2011, then the issue might be the encoding of the strings in the PDF, or it might be something else that confused that older release of Evince. But that test file was produced by LibreOffice. I would expect that a file generated by cups-pdf would instead have cups-pdf as creator in the metadata. I therefore suspect that the test PDF file should be ignored for this issue, and that the originally reported issue is a different one: Ghostscript primarily renders a "painting" and secondarily preserves as metadata high-level information like strings of text and color spaces. One way metadata is lost is if CUPS filters use Postsript as intermediary format. That was the case in the past but the default should nowadays use PDF as intermediary format. Another way that metadata is "lost" is if it was not really there in the first place - e.g. because it was dropped before being handed to Ghostscript. For the record: If you suspect that an issue is in Ghostscript then please provide the ghostscript command that causes this issue - without that the only possible action is to tag it as unreproducible and close it, which is not really helpful. This issue is highly likely a duplicate of 847462 - thus merging. - 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#987566: ghostscript: PDF Interpreter error on armel
Quoting Guilhem Bonnefille (2021-04-28 23:05:16) > Le mer. 28 avr. 2021 à 09:24, Jonas Smedegaard a > écrit : > > > > A key piece is missing, however: Please provide a sample file which > > - like you describe - succeeds to be processed by Ghostscript on > > i686 and armel/stretch but fails on armel/buster. > > Here it is (attached). Thanks! > > Would also be helpful if you could check that same file can be > > succesfully parsed by other PostScript parsers - e.g. Evince, xpdf, > > and (if you have access to that) Adobe applications. > > Yes it is. The *funny* part is that this file is generated by gs > itself as it is a step in the processing of the CUPS PDF pipeline: the > file is the output from *topdf (here, pstopdf). Ghostscript might not fully _generate_ but only _adapt_ PostScript data, e.g. e.g. identify and (re)wrap EPS and TrueType objects that might be broken internally. > Do you think it is possible to imagine a backport? The newest version > of ghostscript (in testing) is working even on armel. Debian might officially fix this issue, and release to stretch the same as now with a minimal patch. Obviously that requires figuring out what the actual cause of the issue is, and produce a working patch. You might try "backporting" as you suggest - i.e. recompiling a newer package in a buster or stretch environment. You might try persuade someone in Debian to issue a semi-official backport at https://backports.debian.org/ A 3rd option (or 4th, depending on how you count) is to try grab an intermediary release that might work with buster or stretch, from https://snapshot.debian.org/ - doing that and reporting back here which versions work and which doesn't would also be helpful in narrowing down what might be the cause for the issue. > My hardware is quite exotic and only Debian stable is supported (for > kernel). But I was able to test with a debian chroot. > > I'm starting to evaluate the rebuild of a more recent version of the > package, by myself, but I'm not so comfortable with Debian packaging > tools and I don't know where to start from (debuild, or pdebuild, or > cowbuild) in order to keep my system clear enough. If you are comfortable using irc, you might try ask questions about build environment in the #packaging channel on OFTC.net Kind regards, - 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#987566: ghostscript: PDF Interpreter error on armel
Control: severity -1 normal Hi Guilhem, Quoting Guilhem Bonnefille (2021-04-25 20:52:16) > Package: ghostscript > Version: 9.27~dfsg-2+deb10u4 > Severity: grave > Justification: renders package unusable > > Dear Maintainer, > > Initialy, I found the bug by updating from Debian stretch to buster > (10.9): the printer was working on stretch but no more on buster. The > device was running on armel. I did tests on i686 and it works. > > After investigation, I was able to identify the « smallest » error context. > The following command: > > gs -dPDFDEBUG -dPARANOIDSAFER -dNOPAUSE -dNOINTERPOLATE -dNOMEDIAATTRS > -dShowAcroForm -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=jpeg > -sMediaType=Automatic -sOutputType=0 -r600x600 -dMediaPosition=7 > -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=841 -dcupsMediaType=-1 > -dcupsBitsPerColor=8 -dcupsColorOrder=0 -dcupsColorSpace=17 -dcupsInteger0=26 > -scupsPageSizeName=A4 -I/usr/share/cups/fonts -c '< 9.00 9.00 9.00] /Margins[0 0]>>setpagedevice' -f -_ < > /tmp/ades.cups-pdf >/dev/null > > Produces error messages on armel but not on i686: > > 8.3 0 0 8.3 0 0 cm > BT > Error reading a content stream. The page may be incomplete. >Output may be incorrect. > Error: Form stream has unbalanced q/Q operators (too many q's) >Output may be incorrect. > Q > Q > Error: File did not complete the page properly and may be damaged. >Output may be incorrect. > %Resolving: [1 0] > > The input is obtained from hp-setup print test page (PS) converted to > cups-pdf with cupsfilter, which certainly means that gs is not able to > read a PDF it generates. Thanks for the bugreport - the details provided is much appreciated! A key piece is missing, however: Please provide a sample file which - like you describe - succeeds to be processed by Ghostscript on i686 and armel/stretch but fails on armel/buster. Would also be helpful if you could check that same file can be succesfully parsed by other PostScript parsers - e.g. Evince, xpdf, and (if you have access to that) Adobe applications. I am lowering severity: That field reflects the package as a whole not the specific issue reported, and I don't consider this issue so severe that Debian would be better off without Ghostscript if it cannot be solved. Don't worry - it is common to mistake the scope of the severity field :-) Kind regards, - 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#977754: evince does not display EPS or PS files anymore and shows "Loading..." forever
Quoting Pino Toscano (2021-01-03 01:43:04) > 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 for the confirmation! Happy new (gregorian) year, - 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#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault
Control: severity -1 important Quoting Paul Gevers (2020-12-04 22:14:44) > On Fri, 23 Oct 2020 12:07:27 +0200 Jonas Smedegaard wrote: > > > Of course, I'm biased since I'm the maintainer of doc-rfc, but I think > > > it's a fair assesment. > > > > For the record it is not a PDF file but a (quite large and allegedly) > > PostScript file that causes Ghostscript to segfault. > > doc-rfc got a new upload and removed the offending file. So, there's no > no autopkgtest regression reported anymore. Unless you think this > segfault case is severe enough (I could really see that point) I also > like ghostscript to just migrate. It's your call. If you want > ghostscript to migrate, just lower this bug's severity. > > > I do agree that Ghostscript shouldn't segfault. > > Indeed. Agreed: lowering to important. - 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
Re: Contact possibility for Odyx/Didier
Quoting Helge Kreutzmann (2020-12-02 19:54:52) > Hello Jonas, > On Wed, Dec 02, 2020 at 06:57:29PM +0100, Jonas Smedegaard wrote: > > Quoting Jonas Smedegaard (2020-12-02 18:49:29) > > > Quoting Helge Kreutzmann (2020-12-02 18:32:41) > > > > I apologize, I'm aware of the basics of git but somehow I cannot reach > > > > that branch: > > > > $ LC_ALL=C git checkout -b debian-master origin/debian/main > > > > > > Above would checkout debian/main (not debian/master > > > > > > try this: > > > > > > LC_ALL=C git checkout -b debian-master origin/debian/master > > > > Arrgh - there was nothing wrong with your command, sorry for the > > confusion. > > > > Try this to refresh what is available at the remote side: > > > > git fetch > > > > and then this to checkout the new HEAD named the same locally: > > > > git checkout debian/main > > But I cannot push: > $ LC_ALL=C git push > Enumerating objects: 13, done. > Counting objects: 100% (13/13), done. > Delta compression using up to 4 threads > Compressing objects: 100% (7/7), done. > Writing objects: 100% (7/7), 1.18 KiB | 603.00 KiB/s, done. > Total 7 (delta 5), reused 0 (delta 0), pack-reused 0 > remote: GitLab: You are not allowed to push code to protected branches on > this project. > To salsa.debian.org:printing-team/cups.git > ! [remote rejected] debian/main -> debian/main (pre-receive hook > declined) > error: failed to push some refs to 'salsa.debian.org:printing-team/cups.git' > > Is there some additional configuration you or I need to perform? Looks like (as the error message says) you are not permitted to push directly to that branch. I don't know if that is intentional: Let's wait for Didier... - 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
Re: Contact possibility for Odyx/Didier
Quoting Jonas Smedegaard (2020-12-02 18:49:29) > Quoting Helge Kreutzmann (2020-12-02 18:32:41) > > I apologize, I'm aware of the basics of git but somehow I cannot reach > > that branch: > > $ LC_ALL=C git checkout -b debian-master origin/debian/main > > Above would checkout debian/main (not debian/master > > try this: > > LC_ALL=C git checkout -b debian-master origin/debian/master Arrgh - there was nothing wrong with your command, sorry for the confusion. Try this to refresh what is available at the remote side: git fetch and then this to checkout the new HEAD named the same locally: git checkout debian/main Or alternatively, if you get lost, make a fresh clone: git clone https://salsa.debian.org/printing-team/cups.git - 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
Re: Contact possibility for Odyx/Didier
Quoting Helge Kreutzmann (2020-12-02 18:32:41) > I apologize, I'm aware of the basics of git but somehow I cannot reach > that branch: > $ LC_ALL=C git checkout -b debian-master origin/debian/main Above would checkout debian/main (not debian/master try this: LC_ALL=C git checkout -b debian-master origin/debian/master NB! Normally on Debian lists it is expected that participants in conversations are all subscribed, and it is considered best practice to _not_ cc individuals. I made an exception here and in previous post of mine, because I am unsure if you are subscribed - but please don't add others that are :-) - 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
Re: Contact possibility for Odyx/Didier
Quoting Helge Kreutzmann (2020-12-01 19:06:22) > sorry for "spamming" the list. You're welcome to use the list for purposes like this. > I'm involved in parts of the CUPS stack and wanted to contact Odyx > (Didier). However, my e-mail is rejected by his MTA: > me+deb...@odyx.org > host mail.flosstools.org [185.15.229.223] > SMTP error from remote mail server after pipelined end of data: > 554 5.7.1 Spam message rejected > > Could you provide me an alternative way to reach him? Or could you > ask him to recheck his spam filters? If you don't mind your conversation being public, then you are welcome to do the conversation here (which I guess Didier is subscribed to). Otherwise, searching for "didier" at https://db.debian.org/ provides https://odyx.org/ which redirects to https://blog.odyx.org/ and also provides IRC nickname OdyX which you can try reach at the OFTC.net IRC network (if you are into that sort of thing). Also, since I guess Dider is subscribed, he might share other ways to reach him (and now that I have quoted your post, there is a higher chance he will actually receive that content). Hope that helps, - 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#972896: libgs9-common: please relax the dependency on fonts-urw-base35
Quoting Fabian Greffrath (2020-10-26 12:10:06) > Am 2020-10-26 11:01, schrieb Jonas Smedegaard: > > Your signalling that you think I am an idiot does not help here. > > I absolutely do not think you are an idiot! Quite the contrary, I > assume you to be a very intelligent person, thus I wonder why you ask > me to repeat my arguments over and over again. I did not ask you to repeat but to elaborate - i.e. explain more detailed. - 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#972896: libgs9-common: please relax the dependency on fonts-urw-base35
Quoting Fabian Greffrath (2020-10-26 10:13:41) > Am 2020-10-26 09:56, schrieb Jonas Smedegaard: > > You cannot mean to sugges that ghostscript should violate Debian > > Policy by ignoring the integrity of symlinks, so it must be > > something else. Please elaborate what you have in mind. > > *Sigh!* Your signalling that you think I am an idiot does not help here. Please keep such provocations to yourself! > Please reconsider letting unrelated packages migrate to testing by not > applying an upper bound to their version number in your package's > dependencies. Which "unrelated packages" are you referring to? If you mean to imply that fonts-urw-base35 is unrelated to ghostscript, then please elaborate, because I fail to understand both that detail and what it means to your sentence above. > Please expect other package maintainers to behave well and not change > file paths which would break your package but require not much more > than a trivial rebuild. Thanks! I have no ill expectations of package maintainers here. Instead, I am unaware that font packages are required to keep file paths as-is - generally the ABI for fonts is their registered names not their paths. That said, I see now that I am overly cautious (about promises font _packages_ need to keep - again I *do* expect package *maintainers* to behave well, and I dislike your asuming differently of me) and distrust not only file names but also file content. I will have ghostscript tell dh_linktree to relax its checks to only be concerned about paths (not content), which should lead to somewhat relaxed versioning of dependency for future migrations. - 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#972896: libgs9-common: please relax the dependency on fonts-urw-base35
Quoting Fabian Greffrath (2020-10-26 09:38:58) > Am 2020-10-25 22:48, schrieb Jonas Smedegaard: > > It seems to me that the concrete delay is caused by ghostscript in > > _testing_ having tight dependency on the font, and that it therefore > > cannot be solved by an upload to unstable - only by ghostscript > > migrating to testing (or ghostscript getting kicked out of testing). > > That said, relaxing the dependency would avoid similar delays in the > > future. > > Indeed, it is the ghostscript package in testing that blocks the > migration of the font package due to its strict dependencies which limit > the font package's version number to an upper bound. Both packages are > currently forced to migrate in lockstep. > > > The reason for the tight dependency is to ensure the integrity of the > > symlinking between the font package and Ghostscript. It is resolved by > > dh_linktree which explains it like this in its man page: > > I see. But by applying this measure you prevent the usual case, i.e. > packages migrating independently, in order to avoid the very uncommon > and unexpected case, i.e. file locations getting out of sync. Please > reconsider. Reconsider what, more specifically? You cannot mean to sugges that ghostscript should violate Debian Policy by ignoring the integrity of symlinks, so it must be something else. Please elaborate what you have in mind. - 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#972896: libgs9-common: please relax the dependency on fonts-urw-base35
Quoting Fabian Greffrath (2020-10-25 21:58:30) > the fonts-urw-base35 is currently stuck in unstable and not allowed to > migrate to testing because the ghostscript package currently suffers > from a completely unrelated RC bug. This is because the libgs9-common > package has an overly strict dependecy on fonts-urw-base35: > > Depends: fonts-urw-base35 (<< 20170801.1.0~), fonts-urw-base35 (>= 20170801.1) > > Thus, the font package is punished for a bug in ghostscript that's not > even related to the font at all. Please relax the dependency to just > the "fonts-urw-base35 (>= 20170801.1)" part so that newer versions of > the font than the one the ghostscript package was built with are > allowed to migrate to testing. It seems to me that the concrete delay is caused by ghostscript in _testing_ having tight dependency on the font, and that it therefore cannot be solved by an upload to unstable - only by ghostscript migrating to testing (or ghostscript getting kicked out of testing). That said, relaxing the dependency would avoid similar delays in the future. Regardless of what exactly is fixed when, I am not convinced that it is wise to relax the dependency: The reason for the tight dependency is to ensure the integrity of the symlinking between the font package and Ghostscript. It is resolved by dh_linktree which explains it like this in its man page: > Since symlink trees are created statically at build-time, they are not > very future-proof and have a risk to miss some files introduced by a > newer version of the package providing the file tree which is > duplicated. That's why the generated dependencies generally ensure > that the same upstream version be used at run-time than at build-time. Sorry, I do understand how it is frustrating for the font to be held ransom by another package like this. - 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#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault
Control: tags -1 confirmed Quoting Iustin Pop (2020-10-23 00:02:11) > On 2020-10-10 13:34:16, Bernhard Übelacker wrote: > > Dear Maintainer, > > tried to have a look at this one, found the segfault [1], > > and can point to the place where the pointer gets overwritten [2]. > > Unfortunately Valgrind or ASAN gave me not more details. > > Thanks for this information. To me, this is clearly a bug in > ghostscript, which is just incidentally triggered by a PDF shipped by > doc-rfc. It could be just as well a PDF downloaded from the internet > :/ > > As such, I think it is correct that this is a serious bug on > ghostscript, but not in doc-rfc, so I will mark it not found in that > package. > > Of course, I'm biased since I'm the maintainer of doc-rfc, but I think > it's a fair assesment. For the record it is not a PDF file but a (quite large and allegedly) PostScript file that causes Ghostscript to segfault. I do agree that Ghostscript shouldn't segfault. I am unaware if the Postscript file is flawed, but that would be a different bug. - 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#970878: ghostscript breaks doc-rfc autopkgtest: segmentation fault
Quoting Paul Gevers (2020-09-24 21:31:38) > https://ci.debian.net/data/autopkgtest/testing/amd64/d/doc-rfc/7163820/log.gz > autopkgtest [06:12:23]: test pspdf-parsing: [--- > Tests that all files are parseable by p*t*xt, > in order to suport dhelp integration. > - testing rfc1119.ps.gz > - testing rfc1124.ps.gz > - testing rfc1125.ps.gz > - testing rfc1128.ps.gz > - testing rfc1129.ps.gz > - testing rfc1131.ps.gz > - testing rfc1142.ps.gz > - testing rfc1144.ps.gz > - testing rfc1147.ps.gz > - testing rfc1168.ps.gz > - testing rfc1195.ps.gz > - testing rfc12.ps.gz > - testing rfc1237.ps.gz > - testing rfc1241.ps.gz > - testing rfc1245.ps.gz > - testing rfc1246.ps.gz > - testing rfc1247.ps.gz > Segmentation fault > autopkgtest [07:25:45]: test pspdf-parsing: ---] Seems the error can be reduced to this: apt install doc-rfc-old-std zcat /usr/share/doc/RFC/links/rfc1247.ps.gz | ps2txt > /dev/null - 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#970448: libgs9-common: gnome metapackage in uninstallable because of broken dependencies in libgs9-common
Hi Jonathan, Quoting Jonathan Marsaud (2020-09-16 16:14:19) > Trying to install gnome metapackage on a fresh Sid installation. > Returning an unmed dependencies: > libgs9-common: Depend: fonts-urw-base35 (< 20170801.1.0~) but 20200910-1 must > be installed > Recommends: fonts-droid-fallback but can't be installed > libgs9-common must depend of the latest version of fonts-urw-base35 > available in Sid if possible: 20200910-1. This issue should be solved shortly by a binNMU (see bug#970491). Thanks for reporting! - 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#961909: ghostscript: PDFA_def.ps references srgb.icc with relative path
Hi Josch, Quoting Johannes 'josch' Schauer (2020-05-31 11:48:01) > using /usr/share/ghostscript/9.27/lib/PDFA_def.ps I can convert a PDF > into PDF/A-1b like so: > > $ env --chdir=/usr/share/color/icc/ghostscript/ gs -dBATCH -dNOPAUSE \ > > -dSAFEGR -dPDFA=1 -sProcessColorModel=DeviceRGB > -dPDFACompatibilityPolicy=1 > > -sDEVICE=pdfwrite -sOutputFile=/tmp/out.pdf \ > > /usr/share/ghostscript/9.27/lib/PDFA_def.ps \ > > in.pdf > > Using "env --chdir" as well as using an absolute path for OutputFile is > necessary because PDFA_def.ps references srgb.icc with a relative path > in /usr/share/color/icc/ghostscript/ -- this means that unless the > command is executed in /usr/share/color/icc/ghostscript/, PDFA_def.ps is > useless and must be edited to contain the right absolute path to > srgb.icc. > > I propose to either: > > - move PDFA_def.ps to /usr/share/doc/*/examples because it's a file >that cannot be used immediately but has to be edited first > > - patch PDFA_def.ps to include the full path to >/usr/share/color/icc/ghostscript/srgb.icc so that it can be used from >any directory Good catch! Indeed libgs9 ships with a few files arguably usable only as examples: /usr/share/ghostscript/9.27/lib/PDFA_def.ps /usr/share/ghostscript/9.27/lib/PDFX_def.ps The files document both inline and in VectorDevices.htm that they should be edited before use. I am hesitant to moving or patching those files, though, because (as you demonstrate above) it _is_ possible with some path juggling to use those files as-is, and both upstream and consuming code might rely on the files. Even if never used for anything as examples, I see no harm in leaving the files where they are just to be on the safe side. More sensible to me would be to symlink the files to .../doc/libgs9/examples to advertise them as usable as such. How do you think about my alternative approach? Kind regards, - 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#952674: New version 0.18 released
Quoting Mathieu Malaterre (2020-02-27 12:55:33) > Source: jbig2dec > Version: 0.18 > > Version 0.18 has been released on 2020/02/11. What makes you conclude the above? Homepage https://jbig2dec.com/ lists 0.17. > Until the issue with the git tag is resolved, here is it: > > http://git.ghostscript.com/?p=jbig2dec.git;a=commitdiff;h=7e45faa81deadc4a3b4419a9e76a17782e8034f4 Yes, I am aware that 0.18 is being prepared, but not that it is final. Previously when I've requested formal release tracking and release tarballs, I was told that releases are done in relation to Ghostscript releases. - 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
Re: Syncing Ghostscript with Ubuntu
Quoting Till Kamppeter (2020-02-07 22:14:56) > On 07/02/2020 21:45, Jonas Smedegaard wrote: > > Also, I just now notice that you did not file this as a bugreport. > > Please use the bugtracker in the future, as that helps track isses > > most efficiently. > > As you are not accepting my little change anyway, do I really need to > post a bug report about that? No no - sorry that was unclear: I just mean for future reference. :-) > But thanks for the info anyway. You're welcome! - 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
Re: Syncing Ghostscript with Ubuntu
Quoting Till Kamppeter (2020-02-07 20:11:37) > On 07/02/2020 20:02, Jonas Smedegaard wrote: > > > > Are you sure the issue with ppc64 still apply? I ask because > > apparently it builds fine on Debian: > > https://buildd.debian.org/status/package.php?p=ghostscript > > > > For me it actually happened that gcc got stuck on one file when > running with -O3 on ppc64el. See the linked bug report. Therefore I > checked and found out that Ubuntu's Ghostscript package had the > exception rule. > > My suspect is now that Debian compiles with -O2 by default, Ubuntu > with -O3, meaning that the problem will not occur on Debian. Ah, I understand it now: Debian indeed compiles with -O2 by default. > So I would be grateful if you could adopt the exception rule, simply > for smooth syncing. I will not maintain packaging code purely for working around deviations in derivatives of Debian. Sorry, I understand that it would simplify your work, but I will not be burdenened by derived work not passed upstream to Debian. Also, I just now notice that you did not file this as a bugreport. Please use the bugtracker in the future, as that helps track isses most efficiently. Kind regards, - 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
Re: Syncing Ghostscript with Ubuntu
Hi Till, Quoting Till Kamppeter (2020-02-07 19:49:40) > I am syncing most printing-related packages between Debian and Ubuntu > to reduce packaging work. [ details snipped] > Now, 9 years after this MIR got posted and 7 years after my first > comment (when I looked into syncing Ghostscript for the first time) > finally theupstream developers fulfilled our security requirements and > the MIR passed, libopenjpeg2 moved into Main and I was able to sync > Ghostscript. > > So now we have 9.50~dfsg-5 in Ubuntu. I am happy for you that your delta has been reduced. > But unfortunately, I overlooked another Ubuntu delta. The Ubuntu > Ghostscript has some extra lines in debian/rules to make Ghostscript > build with -O2 instead of -O3 on ppc64el as (at least on Ubuntu) gcc > gets stuck on one file: Are you sure the issue with ppc64 still apply? I ask because apparently it builds fine on Debian: https://buildd.debian.org/status/package.php?p=ghostscript - 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?
[ 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#941580: closed by Jonas Smedegaard (Bug#941864: fixed in ghostscript 9.50~dfsg-5)
Quoting Agustin Martin (2019-12-02 11:17:04) > On Wed, Nov 27, 2019 at 07:39:05PM +, Debian Bug Tracking System wrote: > > Source: ghostscript > > Source-Version: 9.50~dfsg-5 > > > > We believe that the bug you reported is fixed in the latest version of > > ghostscript, which is due to be installed in the Debian FTP archive. > > > > ghostscript (9.50~dfsg-5) unstable; urgency=medium > > . > >* add patch cherry-picked upstream > > to add 'omitEOD' flag to RLE compressor and use for PXL; > > closes: bug#941864, > > Thanks, Jonas, > > Fix is working well here. Good to know - thanks for the confirmation. ...and sorry for my lack of response in the process :-/ - 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#941074: ghostscript: ps2pdf SAFER and transparency interference
Control: tags -1 wontfix Quoting Markus Demleitner (2019-09-24 11:36:09) > ps2pdf14 as delivered in buster will only produce PDF transparency > when run with -dNOSAFER. This deviates from previous releases (I'm > quite sure about jessie), when transparency was produced without > further configuration. Although I *might* see some relationship to > accepting pdfmarks, the connection between SAFER and transparent > colours frankly strikes me as just a little non-intuitive (but that > may be because I don't know what's going on when producing > transparency in PDFs). > > Because of this, I'd suggest that if turning off PDF transparency > without -dNOSAFER is intentional, that should be documented in the > NEWS, even more so as I couldn't make out that fact in the upstream > Use.htm that the current 9.28~~rc1~dfsg-1 NEWS item refers to. > Perhaps that particular item could be amended with saying something > like "Note that that has some rather unexpected consequences (e.g., > PDF transparency is now lost without -dNOSAFER)." At https://bugs.ghostscript.com/show_bug.cgi?id=701624#c1 upstream explains that the operators to apply transparency is non-standard when applied to Postscript code. Upstream has since relaxed to permit these non-standard operators in SAFER mode, a change which is (not certain but) likely to appear in next upstream release: http://git.ghostscript.com/?p=ghostpdl.git;h=d1eac80 I prefer to not mess with this security-related code to try cherry-pick for older relases, and therefore flag this bug as wontfix. Thanks for reporting, - 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#940586: ghostscript: Please add gpcl in addition to gs
Quoting Patrik Schindler (2019-09-17 16:46:48) > Please add gpcl as package to Debian, probably as backport available > for oder releases, too. Building gpcl with the debian-directory from > ghostscript yields file overlaps, because of files both programs use. > Diversions could be a solution. > > Maybe it could be a better idea to split gs into ghostscript-common > and ghostscript-gs-bin and ghostscript-gpcl-bin to prevent unnecessary > disk space allocation through duplicate files. Thanks, your proposed approach is in line with my own thinking here. I am a bit puzzled, however, why you file a sparate bugreport instead of following up on bug#855219. Would you agree that it makes sense to merge #855219 into this one? Oh, and btw: Any progress on your OS/400 project? Kind regards, - 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#901446: inkscape: Bug fix latex rendering
Version: 9.24~~rc2~dfsg-1 Quoting Marc-Olivier Buob (2018-06-13 14:58:49) > With the current version of inkscape, when using Extensions > > Rendering > Latex... the latex rendering does not work. This is believed solved with ghostscript packaging release 9.24~~rc2~dfsg-1. Thanks for reporting this bug! - 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
Re: Bug#940127: ghostscript makes c2esp autopkgtest timeout
Control: severity -1 important Quoting Jonas Smedegaard (2019-11-14 14:28:35) > @Didier: Since you reassigned this to (only) ghostscript, would you > please consider re-reassigning to (only) c2esp instead? > > Reason I ask is that ghostscript is now security-buggy in testing > since a month, seemingly blocked only by this issue. If reassigning > does not seem sensible, then how about lowering severity (maybe only > temporarily)? Lowering severity to prioritize general security over use with c2esp. - 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
Re: Bug#940127: ghostscript makes c2esp autopkgtest timeout
Quoting Didier 'OdyX' Raboud (2019-09-22 15:30:53) > Le dimanche, 22 septembre 2019, 13.25:19 h CEST Brian Potkin a écrit : > > On Sat 21 Sep 2019 at 17:39:20 +0200, Didier 'OdyX' Raboud wrote: > > > Le samedi, 21 septembre 2019, 16.24:30 h CEST Brian Potkin a écrit : > > > > > There's clearly a regression in ghostscript 9.28 that started > > > > > segfaulting > > > > > in the c2esp filter chain. But I can't manage to reproduce it outside > > > > > of > > > > > the "cups + c2esp + cups-filters (gstoraster) + ghostscript" > > > > > environment. > > > > > > > > > > Brian; Till: any idea? > > > > > > > > No ideas from me really. I too get gstoraster stopping when attempting > > > > to print /usr/share/cups/data/form_russian.pdf; but the same is true for > > > > form_english.pdf. > > > > > > Ah, sorry; I formulated my inquiry weakly. Let me try again: > > > > > > Do you have a hint on how to reproduce the failing ghostscript call (or > > > the > > > gstoraster call) directly, without using CUPS in the middle? > > > > Would this do? > > > > cat /usr/share/cups/data/form_russian.pdf | gs -dQUIET -dPARANOIDSAFER > > -dNOPAUSE -dBATCH -dNOINTERPOLATE -dNOMEDIAATTRS -dShowAcroForm > > -sstdout=%stderr -sOutputFile=%stdout -sDEVICE=cups -r600x600 > > -dDEVICEWIDTHPOINTS=595 -dDEVICEHEIGHTPOINTS=842 -dcupsBitsPerColor=8 > > -dcupsColorOrder=0 -dcupsColorSpace=4 -scupsPageSizeName=A4 > > -I/usr/share/cups/fonts -c '< > 3.00] /Margins[00]>>setpagedevice' -f -_ > out.ras > > The problem is… This doesn't segfault. :-( This bugreport seems to only really describe broken behaviour of c2esp. Yes, it smells quite strongly of being _caused_ by some bug in ghostscript, but when only proven breakable in an environment created inside of c2esp, it seems more sensible to me that this bugreport is tied to c2esp rather than ghostscript. @Didier: Since you reassigned this to (only) ghostscript, would you please consider re-reassigning to (only) c2esp instead? Reason I ask is that ghostscript is now security-buggy in testing since a month, seemingly blocked only by this issue. If reassigning does not seem sensible, then how about lowering severity (maybe only temporarily)? - 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#941580: Printer don't work properly with ghostscript 2.27
[ re-sending with ASCII headers to please Debian mailservers ] Hi Michael, Quoting Michael Schütz (2019-10-09 12:56:52) > I had a similar issue. After upgrading to 'buster' my printer doesn't > work. After downgrade ghostscript, libgs9 and libgs9-common to version > from oldstable (ghostscript 9.26) everything is running as usual. Please file a separate bugreport with the details of your encounter. Prefarably file the bugreport against the printer driver you use. Similarly looking bugs can have different causes, and specifically in the area of recent Ghostscript changes the causes was likely _triggered_ by changes in Ghostscript (tightening of previously insecure processing) which needs to be _fixes_ in various different packages where that code is being passed to Ghostscript. Kind regards, - 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#941074: ghostscript: ps2pdf SAFER and transparency interference
Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=701624 [ replying via bugreport ] Quoting Markus Demleitner (2019-09-24 13:16:33) > Hi Jonas, > > On Tue, Sep 24, 2019 at 12:21:15PM +0200, Jonas Smedegaard wrote: > > Above minimal code is processed by LaTeX, not Ghostscript directly. > > > > Please provide a (minimal, preferrably) example of date and commands > > directly involving Ghostscript. > > The postscript code produced above is a bit unwieldy in comparison > to the TeX source, but hand-crafting a minimal piece of postscript > is... unattractive to me at this point. > > So, I'm attaching the dvips-produced postscript and, in case that's > not coming through, I'll keep > http://www.tfiu.de/transparent-things.ps while this bug is open. > > To reproduce the bug, run > > ps2pdf14 transparent-things.ps > > (no transparency in transparent-things.pdf) and > > ps2pdf14 -dNOSAFER transparent-things.ps > > (transparency in transparent-things.pdf). Thanks - that's qite useful: I have now passed this report upstream. - 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#941074: ghostscript: ps2pdf SAFER and transparency interference
Hi Markus,
Quoting Markus Demleitner (2019-09-24 11:36:09)
> ps2pdf14 as delivered in buster will only produce PDF transparency
> when run with -dNOSAFER. This deviates from previous releases (I'm
> quite sure about jessie), when transparency was produced without
> further configuration. Although I *might* see some relationship to
> accepting pdfmarks, the connection between SAFER and transparent
> colours frankly strikes me as just a little non-intuitive (but that
> may be because I don't know what's going on when producing
> transparency in PDFs).
>
> Because of this, I'd suggest that if turning off PDF transparency
> without -dNOSAFER is intentional, that should be documented in the
> NEWS, even more so as I couldn't make out that fact in the upstream
> Use.htm that the current 9.28~~rc1~dfsg-1 NEWS item refers to.
> Perhaps that particular item could be amended with saying something
> like "Note that that has some rather unexpected consequences (e.g.,
> PDF transparency is now lost without -dNOSAFER)."
>
> Here's my minimal working example:
>
> With the LaTeX document
>
> \documentclass{article}
> \usepackage{pstricks}
> \begin{document}
>
> \psframebox*[linecolor=white,fillcolor=red,fillstyle=solid,
> opacity=0.85,framesep=4mm]{abc}
> \vskip -9mm
> \psframebox*[fillcolor=white, opacity=0.5,strokeopacity=0.5,
> fillstyle=solid,framesep=4mm,linewidth=3pt,linecolor=black]{abc}
>
> \end{document}
>
> in a.tex, run
>
> latex a;dvips a;ps2pdf a.ps
>
> and the second white box obscures most of the red box in the background
> (i.e., pstricks opacity is ignored). Run
>
> latex a;dvips a;ps2pdf -dNOSAFER a.ps
>
> and the two boxes blend as expected.
Thanks for reporting this issue.
Above minimal code is processed by LaTeX, not Ghostscript directly.
Please provide a (minimal, preferrably) example of date and commands
directly involving Ghostscript.
- 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#940605: Bug#940632: nmu: mupdf_1.15.0+ds1-1+b1
Quoting Julien Cristau (2019-09-19 12:07:16) > Control: tag -1 + patch > > On Wed, Sep 18, 2019 at 12:01:04PM +0200, Julien Cristau wrote: > > Control: severity 940605 serious > > Control: retitle 940605 jbig2dec: ABI breakage without SONAME and package > > name change > > > > On Wed, Sep 18, 2019 at 08:22:49AM +0200, Jonas Smedegaard wrote: > > > Package: release.debian.org > > > Severity: normal > > > User: release.debian@packages.debian.org > > > Usertags: binnmu > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA512 > > > > > > Hi release team, > > > > > > Due to libjbig2dec0 upstream API being unstable, and a new release of > > > libjbig2dec0 introduced a new symbol, mupdf needs a bunNMU to catch up. > > > libjbig2dec0 tracks symbols changes, so a simple rebuild should properly > > > tighten dependency to only the new API. > > > > > > Please rebuild mupdf against libjbig2dec0 0.16+20190905-2 to bump its > > > dependency on libjbig2dec0. > > > > > NAK. jbig2dec's symbols file diff includes this gem: > > > > - jbig2_ctx_new@Base 0.11 > > > > This is broken. It means jbig2_ctx_new, previously part of the ABI > > surface, is no longer exported. That needs to be fixed, either by > > bringing it back or by bumping SONAME and library package name. > > > The former seems easier. Thanks - also for your earlier clear explanation for the rejection. My skills include reverting the upstream change but not comprehending the concequences of such revert. Help in the form of a patch would be tremendously appreciated. - 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
Re: Ghostscript issue with fonts
[ sent again - avoiding 8bit in mail header confusing Debian server ] Hi Clark, Quoting Clark Knøsen (2019-08-13 18:45:33) > There seems to be an issue with the fonts which cause some PDF's to be > unreadable after processing them with Ghostscript.. > > I don't know where to report this? > > Please see this bug report at Ghostscript and what the developers > say.. > > https://bugs.ghostscript.com/show_bug.cgi?id=701417 As you wrote yourself in upstream bugreport the package you installed is "ghostscript" - that's a suitable package to file your bugreport against. More info on reporting bugs in Debian here: https://www.debian.org/Bugs/Reporting NB: I maintain the ghostscript package and am danish, so if the issue you have is tied to danish characters specifically, then you can assume in your bugreport that I know the difference between german double-S and danish o-slash :-) Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Bug#613912: closed by Jonas Smedegaard (Bug#613912: fixed in ghostscript 9.27~dfsg-3)
Quoting Fabian Greffrath (2019-07-24 16:29:39) > Am Mittwoch, den 24.07.2019, 16:12 + schrieb Debian Bug Tracking > System: > > #613912: ghostscript ships its own fonts in libgs9-common, > > additionally depends on gsfonts > > Cool, thanks! You're welcome. Thanks for 8 years of patience :-) - 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#932897: libgs9-common: Require fonts-urw-base35 and get rid of font duplication that way
Hi Julian, Quoting Julian Wollrath (2019-07-24 09:55:14) > libgs9-common provides the base 35 fonts in > /usr/share/ghostscript/9.27/Resource/Font/ while these fonts are also > packaged in fonts-urw-base-35. So it would make sense to depend on > fonts-urw-base35 instead and replace the fonts in > /usr/share/ghostscript/9.27/Resource/Font/ with symlinks to the fonts > from fonts-urw-base35, e.g.: replace > /usr/share/ghostscript/9.27/Resource/Font/C059-BdIta by a link > to /usr/share/fonts/type1/urw-base35/C059-BdIta.t1 Thaks for the reminder: This issue is already tracked as ancient bug#613912 but I appreciate your bringing it up again (and no problem that you missed that earlier bugreport). Looking into fixing this now, while waiting for my laundry to finish here at Debconf in Critiba, Brazil... :-) - 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
Re: How will it go on with CUPS
Hi Till, Quoting Till Kamppeter (2019-07-08 11:34:29) > now after Debian being released unstable will soon get unfrozen. When > will this exactly happen and which versions of CUPS will we see in > unstable then? 2.2.11 and/or 2.2.12? Or 2.3.x? Note that Apple did not > settle on the license problem of 2.3.x yet. Debian unstable is no longer frozen, and anyway not unstable but testing was frozen. Your question is therefore not tied to release cycle but only to choice of the CUPS maintainers. Current status is (as usual) https://tracker.debian.org/pkg/cups - 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#927429: Is ghostscript/9.27~dfsg-2 not going to testing?
Hi Hideki-san, [adding bugreport as recipient] Quoting Hideki Yamane (2019-05-23 03:18:01) > Hi again, > > Is ghostscript/9.27~dfsg-2 not going to testing? > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927429 > > It seems that it should be in there. Yes, agreed. I am lousy at dealing with release team. Help much appreciated. - 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#927429: ghostscript: incorrect bbox is produced in pdfcrop
control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=700988 Quoting Kenshi Muto (2019-04-20 00:32:33) > On Sat, 20 Apr 2019 01:18:50 +0900, > Jonas Smedegaard wrote: > > Can you pass this upstream? Otherwise I will do that. > > Well, it's hard for me to follow upstream discussion... > I'd like to ask you to send, I really appreciate it :) Perfectly fine - I've passed it upstream now. :-) Thanks again for reporting this, - 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#927429: ghostscript: incorrect bbox is produced in pdfcrop
Quoting Kenshi Muto (2019-04-19 16:44:24) > On Fri, 19 Apr 2019 23:35:35 +0900, > Jonas Smedegaard wrote: > > > $ pdfcrop -hires -verbose o.pdf > > > > That is the pdfcrop command. Would be quite helpful of you can isolate > > and provide here the embedded gs command. > > Sure, pdfcrop uses bbox device. > Here it is. > > [stretch] > $ gs -sDEVICE=bbox -dBATCH -dNOPAUSE o.pdf > GPL Ghostscript 9.26 (2018-11-20) > Copyright (C) 2018 Artifex Software, Inc. All rights reserved. > This software comes with NO WARRANTY: see the file PUBLIC for details. > Processing pages 1 through 1. > Page 1 > %%BoundingBox: 153 716 159 722 > %%HiResBoundingBox: 153.323995 716.777978 158.759995 721.277978 > > [buster] > $ gs -sDEVICE=bbox -dBATCH -dNOPAUSE o.pdf > GPL Ghostscript 9.27 (2019-04-04) > Copyright (C) 2018 Artifex Software, Inc. All rights reserved. > This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY: > see the file COPYING for details. > Processing pages 1 through 1. > Page 1 > %%BoundingBox: 148 713 153 717 > %%HiResBoundingBox: 148.283995 713.195978 152.855995 716.975978 Thanks! Indeed this seems broken. Can you pass this upstream? Otherwise I will do that. - 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#927429: ghostscript: incorrect bbox is produced in pdfcrop
Hi Kenshi-san, Quoting Kenshi Muto (2019-04-19 16:15:22) > I noticed pdfcrop (texlive-extra-utils) produced misadjusted PDF since Buster. > pdfcrop calls gs internally to get bbox, but gs seems return incorrect > information. > > Attached file: > - o.pdf : original PDF (compiled from upLaTeX on Buster) > - o-crop-stretch.pdf : cropped PDF from Stretch (correct) > - o-crop-buster.pdf : cropped PDF from Buster (incorrect) > > [on Stretch, ghostscript 9.26a~dfsg-0+deb9u1] > --- > $ pdfcrop -hires -verbose o.pdf That is the pdfcrop command. Would be quite helpful of you can isolate and provide here the embedded gs command. Thanks for the bugreport, - 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#926836: libgs9 and libgs9-common 9.27~dfsg-1 break printing: 'Printer State:' is 'Idle - Filter failed'
control: reassign -1 cups-filters control: forcemerge 926576 -1 Quoting Rob Oosterling (2019-04-11 09:28:16) > After upgrading to said version, printing stops working (Brother HL-1430). > > Error message: 'Printer State:' is 'Idle - Filter failed'. > > From Cups error log: > > GPL Ghostscript 9.27: Unrecoverable error, exit code 1 > Process is dying with \"Unable to determine number of pages, page count: -1 > \", exit stat 3 > > > Reverting to version libgs9_9.26a~dfsg-2_amd64 and > libgs9-common_9.26a~dfsg-2_all resolved the issue. cups-filters is ultimately to blame for this: It relied on undocumented pseudo-postscript calls recently removed from Ghostscript because they turned out to cause security issues. The bug should be fixed in a recent update to cups-filters. Thanks for reporting. Next time you file a bugreport, it helps if you try check for existing bugs first, including bugs that "affects" the package you intend to file a bug against. Regards, - 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#926789: ghostscript: unrecoverable error -> cups: no print, return "Filter failed"
control: forcemerge 926789 926576 Quoting Antonio (2019-04-11 08:25:15) > It looks like the same type of error. However, I can confirm that > upgrading to cups 1.21.6-5 the problem is solved. Thanks for confirming. Now merged. - 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#926787: ghostscript: "filter failed"
control: forcemerge 926576 926787 Quoting James Van Zandt (2019-04-11 03:13:39) > Yes, this is the same as #926576. You may merge them. Ok. Done now. Seems cups-filters was fixed already at least in unstable. - 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#926789: ghostscript: unrecoverable error -> cups: no print, return "Filter failed"
Quoting Antonio (2019-04-10 14:06:37) > the version *9.27~dfsg-1* of ghostscript packages returns an error and > cups can no longer print documents. Thanks for reporting this issue! Please check if this is the already reported bug https://bugs.debian.org/926576 - 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#926787: "filter failed" in CUPS, error log says "Unable to determine number of pages"
Quoting James Van Zandt (2019-04-10 13:08:52) > Most print jobs fail with "filter failed". Only acroreader is able to > print PDF files. Thanks for reporting this issue! Please check if this is the already reported bug https://bugs.debian.org/926576 - 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#913120: cups-filters: please favor graphicsmagick-imagemagick-compat over imagemagick
Source: cups-filters Version: 1.21.3-2 Severity: important Tags: security -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Graphicsmagick is a drop-in replacement for imagemagick which - apart from being faster and lighter - also claims that it "suffers from fewer security issues and exploits" - which seems to correspond with the amount of issues reported at https://security-tracker.debian.org/tracker/source-package/imagemagick and https://security-tracker.debian.org/tracker/source-package/graphicsmagick Please list graphicsmagick-imagemagick-compat as favored over imagemagick to have the former installed by default on new systems. - Jonas -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlvil9YACgkQLHwxRsGg ASFjWBAAohF5VcTgx3Jl8GJpwKXAqXKnbTF3QEHB5f6hTS0uyDGSZ1/jboej/NxN LZA+8NQrDuu1p3bWcBq8EQ/nybktol6CtimkfqD+kDObuOfsGGCD61drQwlfBj7W WYM9CCnM9CE+6SDLc+M2PvRubQuFH1DkpGV1wDCmnHfRgGPbVtkPM9/epfkMNMbW yCnV7rKyZD1TnRW354PfSrpl5RTijS93iU98/zAKuBlPbgQchUgZaePmcpJOhwto 3a1sIsyaPzMyymktlv4eZ1aBv1CNDv7UiDPCO/3Qozp83TcwY3UNs5D8hAk11Zjf zLwY+ZBCWuGEtrDGbIsxeac5OhIZZZn02B7Vh41KPXq3WOKIx+DIui1YJTHV0eek B7LA31wZ/2tMzBqOtJrfMUJOkjmthxpVZWIcqVdCA9fIYNiTi6IaiNJmOrYxSOYp SAp0V+t8MtRLc733XG3O+mg98CzSIqog6zJI5uxTpftD9dfGe4mMDVILc6krsGin agN4Nq5fCUSGWv28pvgIDy6MnBusb2Amho4nQQ9ny0kYjgaDK7dEPixMbAmBpdyI iTq4jrw5TpDlC5mMI2wy+tIGvyo/DF45C3DOlLTGyTWDghZqEk9E36QYo2AxfUXc seRByTLQlju9G5HHI5EVm1mBDvNZ9li/kBBaekubcKkkAgnEWlw= =cM4p -END PGP SIGNATURE-
Bug#911522: ghostscript: FTBFS on amd64, i386
Quoting Ivo De Decker (2018-10-21 14:28:37) > On 10/21/18 1:06 PM, Samuel Thibault wrote: > > Jonas Smedegaard, le dim. 21 oct. 2018 12:56:02 +0200, a ecrit: > >> I am clueless why that happens. Not sure, but I suspect it is a > >> spurious error happening occationally and if so that a workaround > >> is to simply request a binNMU. > >> > >> Help dearly appreciated either requesting a binNMU (by someone > >> understanding the - to me - strange language to do that), > > > > I have done so (actually it's a buildd give-back, binNMU is when you > > rebuild a new binary version of an existing package) > > It builds now. Closing! Thanks to both of you for helpingswiftly! - 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#911522: ghostscript: FTBFS on amd64, i386
Control: tags -1 help Hi Ivo, Quoting Ivo De Decker (2018-10-21 12:08:43) > The latest version of ghostscript in unstable fails on amd64, i386: > > https://buildd.debian.org/status/package.php?p=ghostscript Thanks for reporting! I am clueless why that happens. Not sure, but I suspect it is a spurious error happening occationally and if so that a workaround is to simply request a binNMU. Help dearly appreciated either requesting a binNMU (by someone understanding the - to me - strange language to do that), or better yet to identify the cause of the underlying failure and provide a patch. - 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#910303: Xdvi stoped showing emedded EPS figures after updating ghostscript
Control: tag -1 patch Control: forwarded -1 http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=19ebb5f Quoting Serguei DACHIAN (2018-10-04 19:30:46) > I don't know how to make the problem appear directly with Ghostscript, > but here is a typycal output from xdvi: [...] > After googling a bit, I find out that exactly the same problem already > appeared (approximately at the same time, in September) in ubuntu and > the solutions are more or less known, cf. > https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/1793742 > > Hope this helps, and thank you once more. That looks helpful indeed. @Moritz, it seems the stable update need the referenced patch. Can you please include that? And thanks a lot for handling those many CVEs! - 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#910303: Xdvi stoped showing emedded EPS figures after updating ghostscript
Hi Serguei, Quoting Serguei DACHIAN (2018-10-04 18:06:46) > Xdvi stoped showing emedded EPS figures after updating ghostscript (as > well as ghostscript-x, libgs9 and libgs9-common) from > 9.20~dfsg-3.2+deb9u2 to 9.20~dfsg-3.2+deb9u4. Subsequent upgrading to > 9.20~dfsg-3.2+deb9u5 did not solve the problem. Reverting back to > 9.20~dfsg-3.2+deb9u2 makes everething work again. Thanks for reporting! I am not familiar with xdvi, so would appreciate some help isolating tests using Ghostscript directly. Does it emit some warnings or errors? It seems "xdvi -debug 32" provides valuable details. Can you try isolate and share an example file directly passed to Ghostscript which renders wrongly, and the Ghostscript command that is being called? Thanks, - 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#910274: ghostscript: ps2pdf removes links from PDF files
Quoting Vincent Lefevre (2018-10-04 14:44:08) > On 2018-10-04 13:34:20 +0200, Jonas Smedegaard wrote: > > Quoting Vincent Lefevre (2018-10-04 13:03:52) > > > I could test that this bug is reproducible with upstream's > > > version. > > > > Thanks for reporting, also upstream. > > > > Upstream bugreport was closed with an explanation that it is > > intended behaviour i.e. that changed behaviour is progress, not a > > regression. > > OK, but then, this was not the same bug. I've reopened my bug upstream > with the following comments: > > In bug 699830, the user was using gs directly. Here, I'm using ps2pdf, > which is described as a conversion tool: > > Convert PostScript to PDF using ghostscript > > (actually, the description is a bit incorrect since it can take PDF > files in input, not just PostScript files). > > As a conversion tool, it should neither lose information, nor assume > anything about what will be done with the PDF file. Thus > -dPrinted=false should be passed to gs by the ps2pdfwr script. > > If this is not intended to be a conversion tool, the description > should be fixed. Ah, good point! Let's see how upstream reacts to that. Thanks again! - 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#908937: ghostscript breaks ocrmypdf autopkgtest
Control: reassign 908937 ocrmypdf Quoting Paul Gevers (2018-09-16 11:25:47) > ginggs already noted this: > > this patch fixes 1 of the 3 failing tests > https://github.com/jbarlow83/OCRmyPDF/commit/517b385fe5cb2195023100a807e6f18dc7e6faea#diff-b61a6d542f9036550ba9c401c80f00ef At http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=e997c68 linked from above the change is described as a deliberate change in Ghostscript, so reassigning this to ocrmypdf. - 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#895320: ps2pdf crashes
Quoting Jonas Smedegaard (2018-09-14 22:33:14) > A new release of ghostscript is now in experimental. > > Could you please help test if that succeeds? Didn't help. But neither do downgrading to 9.22~dfsg-2.1 in unstable since 2018-04-20. Seems the cause of this is somewhere else than ghostscript. texlive, perhaps? - 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#907493: ghostscript breaks cups autopkgtest: test times out
Quoting Paul Gevers (2018-09-15 07:41:54) > On 14-09-18 22:26, Jonas Smedegaard wrote: > > Another release of Ghostscript is now in experimental. Can someone > > please test if those autopkgtests still fail? > > 9.25~dfsg-1~exp1 passed the cups test. > > https://ci.debian.net/data/autopkgtest/testing/amd64/c/cups/994233/log.gz Great! I'll make a release for unstable now. Thanks for all the help to everyone involved! - 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#895320: ps2pdf crashes
A new release of ghostscript is now in experimental. Could you please help test if that succeeds? - 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#907493: ghostscript breaks cups autopkgtest: test times out
Quoting Jonas Smedegaard (2018-08-31 01:25:24) > Quoting Paul Gevers (2018-08-29 20:24:49) > > Control: tags -1 moreinfo > > > > Hi, > > > > On 29-08-18 20:20, Jonas Smedegaard wrote: > > > Thanks - that is indeed helpful, but provides only the _cups_ commands. > > > > > > Inside those are some Ghostscript command (and some data) which I would > > > need to check if/what fails with Ghostscript. > > > > Both of them are "ELF 64-bit LSB shared object" so it would help if the > > cups maintainers could help here. > > Do the freshly released experimental Ghostscript release help anything? Another release of Ghostscript is now in experimental. Can someone please test if those autopkgtests still fail? - 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#907493: Timeout in autopkgtest also in Ubuntu Cosmic with Ghostscript 9.24
Quoting Till Kamppeter (2018-09-14 14:52:28) > On Ubuntu the timeouts in the CUPS autopkgtest do not happen any more > with Ghostscript 9.25 which got released yesterday and is highly > recommended by upstream to fix the regressions in 9.24. Thanks Till, quite helpful! I am working on Ghostscript 9.25, expecting a release later today. - 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#907493: ghostscript breaks cups autopkgtest: test times out
Quoting Jonas Smedegaard (2018-08-31 15:43:28) > Quoting Didier 'OdyX' Raboud (2018-08-31 15:36:09) > > Le vendredi, 31 août 2018, 01.25:24 h CEST Jonas Smedegaard a écrit : > > > Do the freshly released experimental Ghostscript release help anything? > > > > It doesn't seem to, unfortunately. :-( > > > > To reproduce the issue; just run this as root: > > /usr/share/cups/test-drivers > > > > Surprisingly; it will fail when testing the _second_ printer, always. > > Also, it doesn't seem to get fixed with the ghostscript from testing. > > > > There's something fishy here, but I can't say with certainty that it's > > ghostscript's fault :-( > > Uhm, if the ghostscript in _testing_ causes that test to fail, then this > bug should *not* block the ghostscript in unstable to enter testing!!! Let me try again - I see that my previous message could easily be perceived as aggressive: Not intended at all. Sorry! Thanks, Odyx, for checking against the various versions of Ghostscript. Currently¹ I cannot (easily) setup a CUPS testing environment, so would appreciate if someone else can confirm if the version now in testing _also_ causes this same failure - and if so then please help ensure that this issue does not block the security fix now in unstable to enter testing. - Jonas ¹ I am at MMMfest, a week long festival near Paris. -- * 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#907493: ghostscript breaks cups autopkgtest: test times out
Quoting Didier 'OdyX' Raboud (2018-08-31 15:36:09) > Le vendredi, 31 août 2018, 01.25:24 h CEST Jonas Smedegaard a écrit : > > Do the freshly released experimental Ghostscript release help anything? > > It doesn't seem to, unfortunately. :-( > > To reproduce the issue; just run this as root: > /usr/share/cups/test-drivers > > Surprisingly; it will fail when testing the _second_ printer, always. > Also, it doesn't seem to get fixed with the ghostscript from testing. > > There's something fishy here, but I can't say with certainty that it's > ghostscript's fault :-( Uhm, if the ghostscript in _testing_ causes that test to fail, then this bug should *not* block the ghostscript in unstable to enter testing!!! - 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#907493: ghostscript breaks cups autopkgtest: test times out
Quoting Paul Gevers (2018-08-29 20:24:49) > Control: tags -1 moreinfo > > Hi, > > On 29-08-18 20:20, Jonas Smedegaard wrote: > > Thanks - that is indeed helpful, but provides only the _cups_ commands. > > > > Inside those are some Ghostscript command (and some data) which I would > > need to check if/what fails with Ghostscript. > > Both of them are "ELF 64-bit LSB shared object" so it would help if the > cups maintainers could help here. Do the freshly released experimental Ghostscript release help anything? - 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#907493: ghostscript breaks cups autopkgtest: test times out
Quoting Paul Gevers (2018-08-29 19:58:37) > Control: tags -1 - moreinfo > > On Wed, 29 Aug 2018 09:41:37 +0200 Jonas Smedegaard wrote: > > It would be most helpful if someone could dig out from that convoluted > > ci-in-cups test the actual ghostscript command causing cups to hang. > > Looking here: > https://sources.debian.org/src/cups/2.2.8-5/debian/tests/cups/ > > it runs: > /usr/share/cups/test-drivers > > As the log ends with: > * Driver drv:///sample.drv/dymo.ppd > - Create test printer: done. > - Print test job with /usr/share/cups/data/topsecret.pdf: > > I guess it successfully runs this command > /usr/sbin/lpadmin -p $DUMMY_PRINTER_NAME -E -m $driver -v > file:///dev/null > and fails with this command: > rid=$(/usr/bin/lp -d $DUMMY_PRINTER_NAME $file | sed -e > 's/^.*request id is \(.*\) (.*)$/\1/g') > > where > DUMMY_PRINTER_NAME=test-printer0 > driver=drv:///sample.drv/dymo.ppd > file=/usr/share/cups/data/topsecret.pdf > > Is that enough for you to continue? Thanks - that is indeed helpful, but provides only the _cups_ commands. Inside those are some Ghostscript command (and some data) which I would need to check if/what fails with Ghostscript. - 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#907493: ghostscript breaks cups autopkgtest: test times out
Control: tags -1 + moreinfo Quoting Graham Inggs (2018-08-29 00:56:49) > Control: severity -1 serious > Control: found -1 ghostscript/9.22~dfsg-3 > > Hi Jonas > > I'm bumping the severity of this bug to prevent ghostscript from > migrating until the cups autopkgtest regression has been investigated. Thanks for reporting, Paul, and for blocking, Graham. It would be most helpful if someone could dig out from that convoluted ci-in-cups test the actual ghostscript command causing cups to hang. - 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#907332: ghostscript has a new code execution issue, even when used with -dSAFER
Quoting Salvatore Bonaccorso (2018-08-26 21:55:14)
> Hi,
>
> On Sun, Aug 26, 2018 at 06:08:58PM +0100, Nicolas Braud-Santoni wrote:
> > Tavis Ormandy disclosed a new ghoscript security issue, leading directly to
> > code
> > execution: http://openwall.com/lists/oss-security/2018/08/21/2
>
> There are actually several issues, see the whole thread. For now since
> you filled this bug will track all those with this bug entry. Proper
> evaluation though is still pending (and Moritz is taking care of
> strech, adding this note to dsa-needed file ("needs some research on
> issues found by Tavis").
>
> See
>
> https://www.kb.cert.org/vuls/id/332928
>
> the current set of fixes:
>
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=b575e1ec
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8e9ce501
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=241d9111
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c432131c
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=e01e77a3
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=0edd3d6c
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a054156d
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=0d390118
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=c3476dde
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=b326a716
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=78911a01
> http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=5516c614
Also http://git.ghostscript.com/?p=ghostpdl.git;h=0b6cd19
- 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
Re: [alioth deprecation] Please remove your unused and/or migrated repositories
Excerpts from Didier 'OdyX' Raboud's message of april 27, 2018 4:45 pm: Le vendredi, 27 avril 2018, 08.55:43 h CEST Alexander Wirt a écrit : please remove your old, unused repos on alioth, so that we don't have to archive them. FYI; I removed all the repositories from /git/printing but jbig2dec for which I had no rights. jbig2dec removed now as well. They should all be on Salsa now (and I kept a backup). Great! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private pgpTS7ytb4qed.pgp Description: PGP signature
Bug#860869: ghostscript: diff for NMU version 9.22~dfsg-2.1
Excerpts from Salvatore Bonaccorso's message of april 20, 2018 6:49 pm: Control: tags 860869 + patch Control: tags 860869 + pending Control: tags 896069 + pending Dear maintainer, I've prepared an NMU for ghostscript (versioned as 9.22~dfsg-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Great, Thanks a lot! You need not delay it at all - please feel free to drop the delay. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private pgp0WiaWCni2W.pgp Description: PGP signature
Re: hp-plugin and hp-setup with 3.17.20+repack0-5
Quoting Brian Potkin (2018-03-18 19:00:20) > During the management of bug #891810 this exchange took place between > Jonas Smedegaard and Didier 'OdyX' Raboud: > > Le dimanche, 4 mars 2018, 13.54:27 h CET Jonas Smedegaard a écrit : > > > Is PolicyKit _required_ for _all_ uses of hplip? > >> Good question. I'll admit I was put off my the (exhausting) 'systemd' >> argument, and hadn't checked what exactly was done with PolicyKit. > >> My reading is that PolicyKit is used to grant privilege to run > `hp-plugin` for >> plugin download, thereby avoiding the need for sudo. > >> So no, definitely not _required_. > > I thought that is the function of Policykit in hplip too so put it to > the test yesterday. stretch (base system only) was installed, upgraded > to unstable and then hplip (without its recommended packages) was > installed. 'hp-plugin -i' runs to completion after asking for and being > provided with the root/superuser password. There is no difference in the > outcome when policykit-1 is on the system. > > Maybe policykit-1 is used elsewhere with hplip (the GUI parts?) but I > did not look at this extensively. What I did do was use 'hp-setup -i' > without policykit-1 for a USB connected MFP. That gave > > error: No device selected/specified or that supports this functionality > > and journalctl indicated that permission to access the USB bus had been > denied. Easily solved (as it is when sane-find-scanner gives a negative > outcome) by installing libpam-systemd. (Or, interestingly, putting the > user in the scanner group). > > The small amount I did indicates that having policykit-1 as only a > Recommends: has not impacted unfavourably on the hplip package. Thanks for sharing those details. From what you quoted above, it seems that Didier already hinted that (likely) the need for systemd was "for plugin download". - 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
Re: Multifunction laser printer with free scanner drivers?
Quoting Brian Potkin (2018-03-16 13:09:31) > On Fri 16 Mar 2018 at 11:15:49 +0100, Narcis Garcia wrote: > > > Brother drivers seem to be GPL: https://tinyurl.com/y7e2bpws > > The licence includes the section: > > Further, Brother shall have no liability to disclose and/or distribute > the source code of the Software to User. In no case shall the above > license by Brother to modify, alter, translate or otherwise prepare > derivative works of the Software be construed as Brother's implied > agreement or undertakings to disclose and/or distribute the source code > of the Software. Thanks for noticing. Would you mind filing a bugreport against licensecheck to get it to detect that oddity? I might get around to implement it in any case, but a bigreport helps me not forget, and gives you the credit you deserve :-) - 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
Re: Multifunction laser printer with free scanner drivers?
Quoting Narcis Garcia (2018-03-16 11:15:49) > Brother drivers seem to be GPL: [commercial tracking URL stripped] Beware that some free Brother _drivers_ require non-free _filters_. - 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#891810: hplip not installable without systemd
Quoting Didier 'OdyX' Raboud (2018-03-04 15:44:12) > Le dimanche, 4 mars 2018, 13.54:27 h CET Jonas Smedegaard a écrit : > > Is PolicyKit _required_ for _all_ uses of hplip? > > Good question. I'll admit I was put off my the (exhausting) 'systemd' > argument, and hadn't checked what exactly was done with PolicyKit. Perfectly understandable. I admired how long you kept calm! > > Otherwise I believe hplip should only recommend policykit: The > > purpose of "Recommends" is to permit "exotic" uses, which I believe > > this is - unless hplip *cannot* work *at* *all* wothout PolicyKit in > > place. > > We don't agree on what constitutes "exotic" use of hplip. Oh well… I > suspect a Recommends is good enough. I'll upload that demotion later > today. Thanks. > Just don't expect that demotion to withhold too many "I can't run > hp-plugin" bugs. :) I suspect such bugs can be closed with a simple "Please install policykit (and no, avoiding recommendations is no bug in this package)" message, but let's see if it comes to that :-) - 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#891810: hplip not installable without systemd
Quoting Didier 'OdyX' Raboud (2018-03-04 11:36:21) > Le dimanche, 4 mars 2018, 01.10:33 h CET Juliusz Chroboczek a écrit : > > > > I most respectfully disagree -- I should be able to install the > > > > hpps binary without installing systemd. [...] > > This can be achieved in many ways, including splitting the package, > > or replacing a Depends with a Recommends somewhere. Please be so > > kind as to think about it rather than try to kick me out. > > I thought about it, and my definitive answer is no. PolicyKit is > important for software like hplip, and it needs the 'systemd' package. > Point. Is PolicyKit _required_ for _all_ uses of hplip? Otherwise I believe hplip should only recommend policykit: The purpose of "Recommends" is to permit "exotic" uses, which I believe this is - unless hplip *cannot* work *at* *all* wothout PolicyKit in place. - 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#886224: printer-driver-cups-pdf: Virtual pdf printer error: no output and config problem
Hi Brian and Rudolf, Quoting Brian Potkin (2018-01-07 15:16:46) > On Sun 07 Jan 2018 at 14:13:57 +0100, Rudolf Polzer wrote: > > This is my /etc/apt/sources.list, I am updating three or four times a year: > > > > deb http://ftp.uni-erlangen.de/debian/ stretch main > > deb-src http://ftp.uni-erlangen.de/debian/ stretch main > > deb http://ftp.uni-erlangen.de/debian/ stable main > > deb-src http://ftp.uni-erlangen.de/debian/ stable main > > stretch and stable are the the same distribution at present. The second > two lines are duplicates of the first two. (In year or so, stable will > be buster). [...] > > # I need this line for scilab: > > deb http://ftp.uni-erlangen.de/debian/ sid main > > I've never mixed stable and unstable sources, so do not know what the > consequences could be. Someone? A system consisting purely of packages from a single(!) Debian suite is what we call a Debian system. A system involving packages not only from a a single Debian suite, but including just a single package from elsewhere - whether or not a Debian origin! - is a mess. Possibly a nice and useful mess, but a mess. We welcome our users of Debian to report issues with using our work - arguably also when using single package in a mess. Messy systems are far more difficult to debug however, and package maintainers may want to prioritize issues reproducible on proper Debian systems (and some outright dismiss issues on messy systems). Therefore make sure to always mention immediately in bugreports when dealing with a messy system, to help minimize time wasted on making false assumption e.g. about dependency chains and reproducability. - 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
Re: UPDATE REQUEST : 'Ghostscript' package 9.22 for STRETCH
[dropping individuals from Cc] Hi Clément, Quoting Clovis Development Team (2017-12-22 14:19:20) > We have errors using ghostscript 9.20 with Debian Stretch (we don't have > errors with last release ghostscript 9.22). > > *Could you update the ghostscript package > (https://packages.debian.org/stretch/ghostscript > <https://packages.debian.org/stretch/ghostscript>) for Debian Stretch ? * Please file bugreports for each of the errors you experience: <https://www.debian.org/Bugs/Reporting> We cannot promise to fix all bugs. Particularly for Debian releases that has stabilized, we generally consider only security-related bugs. ...but in any case, it helps to track bugs: Even if not formally fixed then those bugreports may also serve to discuss eventual workarounds. Kind regards, - 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
Re: Wheezy update of jbig2dec?
Quoting Thorsten Alteholz (2017-04-28 19:53:02) > The Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of jbig2dec: > https://security-tracker.debian.org/tracker/CVE-2017-7885 > https://security-tracker.debian.org/tracker/CVE-2017-7975 > https://security-tracker.debian.org/tracker/CVE-2017-7976 > > Would you like to take care of this yourself? [...] > If you don't want to take care of this update, it's not a problem, we > will do our best with your package. Just let us know whether you would > like to review and/or test the updated package before it gets > released. I have no plan to work on this for the Debian LTS derivative of Debian, so please feel free to go ahead with it. Regards, - 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
Re: Wheezy update of ghostscript?
Hi Chris, Quoting Chris Lamb (2017-04-05 22:57:19) > The Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of ghostscript: > https://security-tracker.debian.org/tracker/source-package/ghostscript > > Would you like to take care of this yourself? I have no plans to maintin Ghostscript for the LTS derivative of Debian. Please do go ahead with that, and thanks for the nicely laid out options. Feel free to ask if there's anything in the packaging you find peculiar - I've tried my best to keep the package easy backportable - by my use of CDBS is not considered "easy" by all, so - feel free to ask :-) - 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#858350: ghostscript: CVE-2017-7207
Hi Salvatore, Quoting Salvatore Bonaccorso (2017-03-23 21:25:33) > Thanks for fixing CVE-2017-7207 in unstable. Can you ask as well > release team for an unblock, so that the fix goes to stretch? Yes, I will try... > Btw, there was a wrong bug closer for this bug (using the upstream bug > number instead), thus closed this one manually. Ah, that's what happened. I did notice your closing the bug I believed to already be closed. Sorry for that! - 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#855219: ghostscript: Please add gspcl
Quoting Patrik Schindler (2017-02-23 18:24:02) > Am 23.02.2017 um 17:49 schrieb Jonas Smedegaard <jo...@jones.dk>: >> [re-adding bugreport and setting same as reply-to] > > I did that intentionally but I’m also okay with having some smirky > remarks publicly accessible. Sorry for not asking bfore publishing your post! >> Licensing issue is different - quoting from ghostpdl/pcl/LICENSE: >> >>> The set of truetype fonts in the urwfonts directory are necessary >>> for the PCL/XL interpreter to function properly but they ARE NOT >>> FREE SOFTWARE and are NOT distributed under the GNU GPL. They can >>> instead be redistributed under the AFPL licence which bars >>> commercial use. >> >> Seems (but need closer inspection) that the fonts are free except for >> commercial use and therefore permitted in Debian non-free. > > So I may look forward for a gpcl package for unstable in a not all to > far future? Yes. ...and if at some point in time you realize that "not all too far" have different meaning for me than for you, then feel free to ping this bugreport - or roll up your sleeves and join the packaging effort! - 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#823100: ghostscript: includes two files claimed to be under a non-free Unicode license
Hi Francesco, Quoting Francesco Poli (wintermute) (2016-04-30 21:32:26) > I noticed that two files included in the ghostscript source package > are documented in the debian/copyright file as distributed under the > terms of a non-free Unicode license. > > The two files are: > > Files: base/ConvertUTF.c >base/ConvertUTF.h > Copyright: 2001-2004, Unicode, Inc > License: Unicode [...] > At the very least, this license does not grant any permission to > modify the files (thus failing DFSG#3). Moreover, the license grant > seems to attempt to restrict use to "products supporting the Unicode > Standard" (thus failing DFSG#6). > See also https://lists.debian.org/debian-legal/2015/12/msg0.html > where an FTP Assitant confirmed that files which restrict "use to only > that of implementing a standard" are not fit for Debian main. > > Therefore, the two files under discussion appear to be non-free. Seems you are right. > However, this issue could possibly be easy to solve. > If Unicode Inc has published new versions of the two files in > more recent times, the updated versions should be under the > current unicode.org public license, as explained in > http://www.unicode.org/copyright.html#Exhibit1 > > Please check whether newer versions of those files are released > in one of the Unicode web site areas mentioned in the cited Exhibit1. > The newer versions could perhaps be used as replacements for the > non-free ones. Unfortunately, upstream seems to have _dropped_ the code due to being buggy and unmaintained since 2004, according to http://unicode.org/forum/viewtopic.php?f=9=90 - summarized at http://stackoverflow.com/questions/2685004/why-does-unicode-org-no-longer-offer-a-reference-utf-8-16-32-converter Above forum discussion mentions only version numbers (up to 1.4 and a possible alpha of 1.5), the year I found by looking at latest available snapshot of the code at archive.org and the timestamps of that page: https://web.archive.org/web/20081228105917/http://www.unicode.org/Public/PROGRAMS/CVTUTF/ This gets worse: Seems many more packages embed this code: https://codesearch.debian.net/search?q=ConversionResult+ConvertUTF8toUTF16 I have reported this upstream. Will register at the secure-testing team as a case of Embedded Code Copy as well. - 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
Re: Bug#770266: libgs9: please convert to multiarch
i Till (and others), Quoting Till Kamppeter (2016-09-17 00:50:45) > I have now re-applied multi-arch to Ubuntu's Ghostscript package which > is nearly identical to Debian's current Ghostscript package. So I > attach the debdiff and hope with this you will easily able to add > multi-arch functionality to Debian's Ghostscript package. > > I am very grateful if you apply this so that I can keep the delta > between Debian's and Ubuntu's Ghostscript packages low. Thanks for the suggested patch. I am worried, however, about the following phrase at https://wiki.debian.org/Multiarch/Implementation: > If your -dev package contains headers which vary across architectures > then it cannot be marked as Multi-Arch: same until a policy decision > is made about architecture-dependant headers and the toolchain is > updated. Did you test that the multi-arch packages work in a multi-arch environment? Looking at the symbols file, it seems headers do vary. - 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
Re: cups-filters 1.11.1 released!
[moving conversation back to public list] Quoting Till Kamppeter (2016-08-22 19:13:49) > On 08/22/2016 01:01 PM, Didier 'OdyX' Raboud wrote: > > Le jeudi, 18 août 2016, 02.26:58 h CEST Till Kamppeter a écrit : > >> I have released cups-filters 1.11.1 now, with the following changes: > > > > ACK, thanks. > > > >> - pdftops: Added support for MuPDF as PDF renderer. MuPDF can > >>be selected by the "pdftops-renderer=mupdf" option. > > > >> - Build system: Allow building cups-filters without Poppler > >>(--disable-poppler in ./configure command line) This skips > >>the build of pdftoraster, bannertopdf, pdftoijs, and > >>pdftoopvp and the installation of these filters and their > >>auxiliary files. With this cups-filters can be easily > >>installed on mobile/appliance systems with MuPDF as the only > >>PDF interpreter. > >> - mupdftoraster: Added filter to support MuPDF as PDF > >>interpreter. MuPDF is a lightweight PDF interpreter > >>especially interesting for mobile systems and > >>appliances. Thanks to Pranjal Bhor for contributing this as > >>part of his Google Summer of Code project. > > > > I don't understand the way you have reflected this in the Debian packaging, > > especially in the "cups-filters" vs "cups-filters-core-drivers" separation. > > > > My understanding has always been that cups-filters-core-drivers would > > contain > > the small set of tools for minimal footprint; and that cups-filters would > > contain (and pull) all the bells and whistles. > > > > Why is it then that mupdftoraster is gone to cups-filters; while pdftoraster > > (poppler) goes to cups-filters-core-drivers ? This seems counter-intuitive > > for > > me; shouldn't we have a very minimal cups-filters-core-drivers (with small > > tools and minimal footprint), and a bigger cups-filters? > > > > In any case, in the Ubuntu package, MuPDF (aka /usr/bin/mutool, in mupdf- > > tools' package) isn't pulled through Depends/Recommends, at all, so the > > filter > > will be buggy and/or non-functional. > > > > It'd also be great to have autopkgtests for these independent packages, so > > as > > to maintain their "API" somewhat clear (and stable). > > > > I quickly put up the new source for Ubuntu's Feature Freeze without > really changing the cups-filters-core-drivers which used to use Poppler > as this was on Ubuntu's phone all the time for PDF screen display. > > Now my new idea for packaging is the following: As there are three PDF > renderers, Ghostscript, Poppler, and MuPDF I suggest to add three binary > packages: > > cups-filters-ghostscript > cups-filters-poppler > cups-filters-mupdf > > Each contains all filters (and auxiliary files like PPDs) which need the > appropriate renderer and also the corresponding *.convs file. Each > package depends on the appropriate renderer's executable (gs, pdftops, > mutool). > > cups-filters-core-drivers has then an OR dependency on the three: > > Depends: cups-filters-mupdf | cups-filters-poppler | > cups-filters-ghostscript > > So the minimum installation pulls in the support for one renderer, so it > works if one of the renderers is installed. With the order shown above > it would also pull in MuPDF if no renderer is installed. > > So small-footprint systems could be done either MuPDF-based or > Poppler-based (even Ghostscript-based, but is this then still > small-footprint?). Sounds good with package name clearly indicating which renderer is used. In isolation it sounds sensible to use ORed list, but how does it fit into the larger picture? Will minimal implementation then always be default, also for larger systems? - 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#799916: libjbig2dec0 is not Multi-Arch compatible
Quoting Yuriy M. Kaminskiy (2016-05-16 18:31:50) > On 16.05.2016 19:24, Jonas Smedegaard wrote: >> Quoting Yuriy M. Kaminskiy (2016-05-16 17:17:04) >>> Patch (against 0.13-1) attached. >> >> I believe your patch is flawed, however: the arch-specific jbig2dec >> package should not be marked "foreign" as it is unusable by foreign >> architectures. > > It *is* usable, of course. It is multi-arch, not crossbuild-arch (or > something), user is supposed to be able to run foreign arch binary on > their system (either natively, or via qemu-user). > E.g. I can use jbig2dec:amd64 on primary-arch i386 (or reverse) > perfectly fine. And if other package depends on jbig2dec binary, it > can use native or (any of) foreign binary equally fine. See > https://wiki.debian.org/Multiarch/Implementation That wiki page is what I consulted, and I am not convinced: The passage I found¹ talks about flagging packages where "one copy of this package, of any architecture, is sufficient to satisfy the needs of the runtime library package of every architecture" - and exemplifies with -data packages. I do not recognize -tools style packages as fitting that description. Please try harder to convince me (and no: stating "of course" is *not* helpful, quite the contrary). - Jonas ¹ https://wiki.debian.org/Multiarch/Implementation#Multi-Arch:_foreign_support_packages -- * 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#799916: libjbig2dec0 is not Multi-Arch compatible
Hi Yuriy, Quoting Yuriy M. Kaminskiy (2016-05-16 17:17:04) > Patch (against 0.13-1) attached. Thanks! I believe your patch is flawed, however: the arch-specific jbig2dec package should not be marked "foreign" as it is unusable by foreign architectures. - 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#818662: ghostscript: segfault generating png on s390x ; breaks sketch build
Quoting David Bremner (2016-03-19 20:52:11) > Jonas Smedegaard <d...@jones.dk> writes: >> Quoting David Bremner (2016-03-19 12:43:27) >>> The attached example causes gs to segfault >>> >>> gs -dEPSCrop -sDEVICE=png256 -sOutputFile=foo.png ex000.eps >>> >>> This is part of the sketch documentation, so this breaks the sketch >>> build on s390x >> >> Thanksfor reporting! >> >> Could you try test if the newer ghostscript in experimental still >> fails? > It seems like version in experimental works OK on this example (and > actually all the examples in the sketch build). Good. > Any chance of an upload to unstable? I prefer waiting till the final release, which I beleive should emerge within a week, or possibly two. Please do ping me if you are loosing patience - then I will release what I got. - 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#818662: ghostscript: segfault generating png on s390x ; breaks sketch build
Hi David, Quoting David Bremner (2016-03-19 12:43:27) > The attached example causes gs to segfault > > gs -dEPSCrop -sDEVICE=png256 -sOutputFile=foo.png ex000.eps > > This is part of the sketch documentation, so this breaks the sketch > build on s390x Thanksfor reporting! Could you try test if the newer ghostscript in experimental still fails? - 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
Re: Processed: reopening 404017
Hi Dider,
Quoting Debian Bug Tracking System (2016-03-13 22:00:06)
> Processing commands for cont...@bugs.debian.org:
>
> > reopen 404017
> Bug #404017 {Done: willy.gl...@bsvbernmuri.ch} [ghostscript] "New driver:
> Glassjet"
> Bug reopened
Please elaborate: Why did you reopen this old bug? Any changes
upstream?
Regards,
- 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
