Le Tue, 15 Dec 2015 13:30:36 +0000, Mattia Rizzolo <mat...@debian.org> a écrit :
> On Tue, Dec 15, 2015 at 10:04:09AM +0100, Jérôme wrote: > > Hi. > > Hi Jérôme! > Please note that nor me nor anybody else but the maintainer receive > emails from bug reports unless they have subscribed through the PTS or > to that specific bug. So if you want to get the attention of somebody > in cases like this would be better if you keep the in Cc or such. Actually, I didn't mean to ping anybody. I was rather writing this for the record, for anyone looking for this and ending up on the bugtracker. > Yeah, this bug is mostly about deprecating a debian tool (pysupport) > in favour of another (dh-python, or better, dh_python2 in this case). This is pretty much all I had understood. > I uploaded dozens of packages in the last 4 days removing it, but I'm > stuck at gbirthday because it insists at installing images in sitelib, > which used to be /usr/share/pyshared/gbirthday/ with pysupport, but > now we're migrating off that directory and going to > /usr/lib/python2.7/dist-packages, where images are not really welcome. OK, this is concrete. > So, given that this is actually an application and not a python module > or such. > > To do so, I'd like to upload what I attached as debdiff. > In particoular I'm adding a patch to let it load from > /usr/share/gbirthday. Alright. I have no educated opinion about this choice. Do you want to put all gbirthday in /usr/share/gbirthday ? Or only the images, while the code would be in /usr/lib/python2.7/dist-packages? > Happens that the program doesn't load here, no > UI appears; since this is the same behaviour I have with the package > already in the archive that's not a regression, You mean package gbirthday from stable/testing does not work for you? I guess this should be investigated. You should probably file a bug. Maybe also try GitHub version (no need to install, executing from the repo is fine). Missing dependency? Any console output? > but given that > uploading such untested changes would be too bad, I'd like to ask you > what do you think of the patch attached as 'patch'. Well, the patch looks fine. It worked on my machine. I don't really see the need for the try clause. I mean if gbirthday is installed in /usr/share/gbirthday, it is bound to fail, isn't it? And the code in the except clause will be executed everytime. If you upload an experimental version, I'll give it a try. > > For the record, gbirthday has moved to GitHub: > > https://github.com/Jerome-github/gbirthday/. I should update the > > watch file (this seems feasible to me, but there is no need to do > > it as long as there is no new release). > > I would update it, but I don't know which kind of filenames you'll > use, since there is no release already made there. Ah. I didn't notice I had not uploaded the tags... There you go: https://github.com/Jerome-github/gbirthday/releases (Note that a new version is available that gets rid of a broken dependency.) > [...] > > - Unless somebody comes in, gbirthday won't evolve as it is and will > > probably be out of Stretch or the next Debian release due to > > dependencies deprecation. I'm happy if I'm wrong. > > Not with *this* deprecation ;) Alright. Good to know. > > - I hope to get a Qt version packageable for Stretch. Help welcome, > > of course. > > Stretch will still release with python2, even if we definitely would > like to remove it for buster. Yep, I read that. Don't give me too much time or I'll slack until last moment... Thanks. -- Jérôme
