Bug#935720: Bug#874901: [GLE-devel] Probable fix for qgle seg faults with latest ghostscript versions

[Francesco Poli]

On Wed, 11 Sep 2019 21:01:42 +0200 Christian T. Steigies wrote:

> On Sat, Sep 07, 2019 at 06:48:17PM +0200, Francesco Poli wrote:
> > On Tue, 3 Sep 2019 23:55:22 +0200 Francesco Poli wrote:
> > 
> > > On Sun, 1 Sep 2019 23:27:17 +0200 Christian T. Steigies wrote:
> > [...]
> > > > The libgs search bug is fixed for amd64, but not for other architectures.
> > > 
> > > You're right, I hadn't noticed!
> > [...]
> > 
> > Anyway, while searching for a good fix for the libgs search bug, you
> > could upload a Debian revision fixing the other two bugs, so that, at
> > least, the package is not auto-removed from Debian testing...
> 
> No, I disagree.

You are the maintainer of the package, so it's your call.
But, to be honest, I do not see your point.

I mean: the package currently in testing and unstable has three open
bugs, one of which is serious. The package risks being auto-removed
from testing, because of the serious bug.

You have a fix ready for the serious bug and a fix ready for one of the
other two bugs. The third bug (the libgs search bug) is still waiting
for an optimal fix.

Personally, I would upload a new Debian revision with the patches that
fix the serious bug and the other bug, and with no modification at all
related to the third bug.

Then, once a proper fix for the third bug is available, I would perform
a second upload.

This way, the package would avoid the auto-removal and would see its
bugs fixed, although in two steps.
And there would be no regressions, as far as I can tell.

[...]
> I'd just like to get it done right, and not upload something
> when I know that it is broken.

Please note that the package is already broken...
You would upload a package with two issues fixed out of three, without
any worsening with respect to the third issue.
So why not?

> 
> Right now I see three possible "fixes" for the libgs problem:
[...]
> - fix the code, link to libgs during the build, as is done with all the
>   other libraries qgle depends on. I do not understand why libgs is treated
>   differently, there may be a reason, I just don't know. I think Laurence is
>   working on that, but maybe somebody else working on gle can comment.

I think this is probably the best strategy, but, as I said, let's hear
what upstream developers have to say on this.


In the meanwhile, I would like to suggest once more that you upload the
fixes for the serious bug (Qt5 porting) and for the other bug (qgle
segfault)!

Just my 2 ¢ ...



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
..................................................... Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20190913/d99cf970/attachment-0004.sig>