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
pgpgRanjMLqA_.pgp
Description: PGP signature
