Le 2015-12-16 01:23, Mattia Rizzolo a écrit :

>> 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.

Yes, absolutely. IMHO, it makes more sense to keep everything altogether
in /use/share/gbirthday.

And I can't think of any other Python program that would import
gbirthday.
 
>> 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

That's quite strange.

Expected output is an icon in the systray. I suppose if you have no
systray, you don't see anything. Perhaps any relevant output in
~/.xsessions-errors (I doubt it)?
 
> 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.

Ah, ok. I didn't think about patching upstream. Sure, why not. It may
look a bit dodgy, but it wouldn't break anything, I guess.

After all I hope the whole packaging issue will be simplified when
gbirthday switches to distutils. (I may be wrong but I'd rather stick to
this idea, as it is an incentive to do the switch.)
 
>> 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.

I don't see any binary package. You uploaded a "source package" and I
don't know what to do with it.
 
>> 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.

OK, I don't understand everything but you seem to know what you're
doing.

I noticed you removed python-evolution dependency. This is the point of
the latest upstream version, in which I removed support for evolution
(which was broken anyway).

> I want to try uploading a new upstream version in a NMU, if possible :)

I don't know what a NMU is, and neither my search engine nor wikipedia
helped.
 
>> Thanks.
> 
> Thank you for being involved downstream! :)

Well, I'm a Debian user, so I'm taking care of myself in the process. Of
course I'm glad if Debian users and Debian derivatives benefit from it.

Thank you for your help.

-- 
Jérôme

Reply via email to