Bug#951394: pstoedit fails with findfont error with gs 9.26
Package: ghostscript, pstoedit Version: 9.26a~dfsg-0+deb9u6, 3.70-3+b2 Tags: upstream Control: fixed -1 + 9.50~dfsg-5 Hi. Dear maintainers of ghsotscript and pstoedit, Debian buster is affected by this bug: https://sourceforge.net/p/pstoedit/support-requests/4/ I'm afraid I don't understand the details. It appears that DELAYBIND is now deprecated with upstream. Everything works in bullseye. It is broken in stretch. Perhaps surprisingly, the pstoedit -nb option does not help. I am filing this bug here mostly to help other users of pstoedit on Debian. #880650 seems related but not identical. Maybe it would be worth considering a backport of ghostscript 9.50 to buster ? Steps to reproduce: $ cat <<'END' >test.ps %! /NimbusMonoPS-Bold findfont 50 scalefont setfont 100 100 moveto (C) show zealot:play> PS1='$ ' END $ pstoedit -f dump test.ps dump.ou pstoedit: version 3.70 / DLL interface 108 (built: Oct 11 2016 - release build - g++ 6.2.1 20161215 - 64-bit) : Copyright (C) 1993 - 2014 Wolfgang Glunz Error: /undefined in /findfont Operand stack: NimbusMonoPS-Bold Execution stack: %interp_exit .runexec2 --nostringval-- .findfontop --nostringval-- 2 %stopped_push --nostringval-- .findfontop .findfontop false 1 %stopped_push 2044 1 3 %oparray_pop 2043 1 3 %oparray_pop 2024 1 3 %oparray_pop 1884 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- .findfontop --nostringval-- 2 %stopped_push --nostringval-- 2044 1 3 %oparray_pop 2043 1 3 %oparray_pop 2024 1 3 %oparray_pop 1884 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- .findfontop --nostringval-- 2 %stopped_push --nostringval-- .findfontop 1975 1 3 %oparray_pop Dictionary stack: --dict:970/1684(ro)(G)-- --dict:0/20(G)-- --dict:321/450(L)-- Current allocation mode is local Current file position is 31 GPL Ghostscript 9.26: Unrecoverable error, exit code 1 PostScript/PDF Interpreter finished. Return status 256 executed command : /usr/bin/gs -q -dDELAYBIND -dWRITESYSTEMDICT -dNODISPLAY -dNOEPS "/tmp/psinZUL0CV" The interpreter seems to have failed, cannot proceed ! $ -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: CUPS GPL → Apache license change, how to proceed?
(Adding d-legal)
Didier 'OdyX' Raboud writes ("CUPS GPL → Apache license change, how to
proceed?"):
> tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to
> "Apache-2.0"; how should the license incompatibilities be enforced?
This reply is going to be annoying, I fear:
> Some questions at this point (Some for FTP Masters, CC'ed):
> - Does Debian hold the view that Apache-2.0 and GPL-2.0-only dynamic linking
> is unacceptable for Debian main? In both directions?
I think the answer is "yes, we think that is unacceptable".
ftpmaster seem rarely to reply to these kind of questions. If you
actually want the answer, I suggest you:
- search for existing cases and see if they got REJECTed or ACCEPTted
- upload and see
:-/
> - Can CUPS link against GPL-2-only code?
> - Can GPL-2-only code link against CUPS?
I don't understand how these are different to the previous question.
> - Whose reponsibility is it to check for these incompatibilities, and make
> sure they are not shipped in Debian?
I think (and this is my personal opinion) that a licence
incompatibility is a bug in the depending package, and it is the
responsibility of the depending package maintainer.
> - What tools should I be using to identify which of these will be
> undistributable constructs?
I'm not aware of any useful tools and I hope someone else will be
able to help.
> Aka: how, given a list of source
> packages, can I determine which are GPL-2-only in the codepaths that
> link against CUPS? - What fields could I / should I use in src:cups
> to enforce these? I was initially thinking of setting versionless
> Breaks: in each src:cups' library against the identified GPL-2-only
> culprits, then mass-filing bugs against these, promising to add
> version constraints when/if the licensing issue gets lifted. Does
> that sound like a good way forward?
I guess. It seems like a lot of work, and the cups transition would
be blocked.
You might instead consider simply filing bugs against the
dependencies, and setting a deadline by which they will be escalated
to RC. You will want to discuss this with the release team.
Good luck.
Ian.
Bug#843324: libc recently more aggressive about pthread locks in stable ?
Ian Jackson writes ("libc recently more aggressive about pthread locks in
stable ?"):
> I have just been debugging a ghostscript segfault on jessie amd64.
...
> I recently encountered what seems to be a similar bug in ogg123 in
> stable. #842796.
>
> Has something changed in jessie's libc recently ? I find it difficult
> to imagine that these bugs would have been missed earlier during the
> life of jessie.
>
> I will try to make a patch to fix ghostscript, or at least file a
> proper bug. But, if there was a libc change, would it be possible to
> revert it or make some kind of workaround ?
FYI, the ghostscript bug, with patch for jessie, is #843324.
sid's ghostscript is fine and I think stretch's is too.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#843324: ghostscript crashes on some machines, much of the time
return SEM_ERROR_CODE(scode);
}
int
gp_monitor_leave(gp_monitor * mona)
{
pthread_mutex_t * const mon = (pthread_mutex_t *)mona;
-int scode;
+int scode = 0;
-scode = pthread_mutex_unlock(mon);
-((gp_pthread_recursive_t *)mona)->self_id = 0; /* Not valid unless
mutex is locked */
+#ifdef GS_RECURSIVE_MUTEXATTR
+scode = pthread_mutex_lock(mon);
+#else
+if (pthread_equal(pthread_self(),((gp_pthread_recursive_t
*)mona)->self_id)) {
+ if ((--((gp_pthread_recursive_t *)mona)->lcount) == 0) {
+ scode = pthread_mutex_unlock(mon);
+ ((gp_pthread_recursive_t *)mona)->self_id = 0; /* Not valid
unless mutex is locked */
+
+ }
+}
+else {
+scode = -1 /* should be EPERM */;
+}
+#endif
return SEM_ERROR_CODE(scode);
}
--
2.1.4
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
