On Wed, Dec 16, 2015 at 12:35:31AM +0100, Jérôme wrote: > Mattia Rizzolo <mat...@debian.org> a écrit : > > On Tue, Dec 15, 2015 at 10:04:09AM +0100, Jérôme wrote: > > 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?
It's not really important from my POV. the gbirthday python module can really be thought as a private module, and interely installed in /usr/share/<module>. See the Debian Python Policy for more in this regard: https://www.debian.org/doc/packaging-manuals/python-policy/ch-programs.html#s-current_version_progs I figured it would be easier for me to just do that, rather than trying to separate assents (since ISTR it's not only images) from the code. > > 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? dunno: mattia@chase ~/devel/NMU/gbirthday % gbirthday ^CTraceback (most recent call last): File "/usr/bin/gbirthday", line 12, in <module> main() File "/usr/share/gbirthday/gbirthday/__init__.py", line 249, in main gtk.main() KeyboardInterrupt > > 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. The try/except structure is to make it easier to get accepted and incorporated by you upstream. I wanted to avoid doing such checks if the gbirthday module is already present. TBH, I did that following what I read on openshot main script earlier today, which was in more or less the same issue. > If you upload an experimental version, I'll give it a try. Ok, I these days I feel very lightway wrt uploading, so I just pushed that to experimental. > > > 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 Actually I screw the upload up: I uploaded, then recalled about this, hurried up to cancel the upload, but I got a mail telling me it didn't cancel anything, so meh. Anyway, I'll include it in the unstable upload. > (Note that a new version is available that gets rid of a broken > dependency.) I want to try uploading a new upstream version in a NMU, if possible :) > Don't give me too much time or I'll slack until last moment... heh > Thanks. Thank you for being involved downstream! :) -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
