On Sat, Jun 05, 2010 at 12:55:32AM -0400, Alexandre Quessy wrote:
I just thought about an issue that makes my package 33% unusable. :) The MIDI streaming feature (which would be provided by the new midistream package) relies on either python-portmidi or python-pygame
= 1.9.1. Those two packages are not in Debian yet!

Actually, python-pygame 1.9.1 is in Ubuntu Lucid, but not in Debian
Sid. I have been trying to contact the maintainer, and later answered
to a bug about this. See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544347 ... Maybe it
is too late before the the release of Squeeze? There might be quite a
few packages that depend on python-pygame. I also have an other
package - toonloop 1.2.8 - that needs python-pygame, for its V4L2
video input feature and the MIDI feature.

For the MIDI feature, which is our main interest for scenic, an other
package could provide it. It's python-portmidi. I packaged it, but did
not contribute it yet, since the original author thought it would be
nice to send it upstream, but it's taking time. It's not there yet:
http://sourceforge.net/apps/trac/portmedia/browser/portmidi/trunk (4
months with no activity) My changes to the upstream along with my
packaging files are at http://bitbucket.org/aalex/pyportmidi/wiki/Home

So, either we ask the maintainers of the pygame package to update it,
or we package python-portmidi. I think that merging the pyportmidi
code with portmidi0 would take too much time and effort for now.
(before Squeeze) Anyways, the python-portmidi should be a separate
package from portmidi0, so ... should fill a ITP and package it now?

Note that the scenic application can still run, it's only that the
MIDI features will be disabled.

Lower that package relation to suggests, and document the benefit of installing that suggestion (without explaining the reason it is only suggested, that is development-grade info IMO) in both long description (i.e. in debian/control) and in a debian/README.Debian file (which CDBS then automagically includes in the binary packages).

And try post to bug#544347 again - cc'ing menucci who seem to have somewhat taken over maintainership and perhaps haven't noticed that old bug.

A valuable place for extracting such info is this: http://packages.qa.debian.org/p/pygame.html

2010/6/4 Jonas Smedegaard <d...@jones.dk>:

Maybe it would be nice to also create the scenic-doc package, to separate the doc from the Python code. (though both are architecture: all)

Certainly - if there is documentation of a reasonable amount then it should be in a separate binary package.

For now, the docbook documentation (viewable with yelp) are in an unusual location. (/usr/share/scenic/docbook) It should probably go to /usr/share/gnome/help/scenic/C/scenic.xml like all gnome docs. Our docbook doc is made of several XML files and images, though, and we have two manuals...

I am not very familiar with yelp, but seems to me that if the project is not otherwise tied specifically to Gnome and if yelp supports reading from non-gnome directories, then you shouldn't jump through hoops to install the documentation Gnome-style, but instead jump through hoops to get yelp to recognize it. More importantly you should register with doc-base (which might be all that is needed for yelp integration too?).

The easiest way would be to create 3 *.install files. The quick benefit to this, is that we will have a few packages that are architecture-independant, namely the two Python-only binary packages: scenic and midistream. That totally makes sense.

Yes, that seems sensible (from reading it alone - I must admit that I have not yet tried compiling the project and looking at the results).

It's rather complex to actually use it to its fullest - it needs two
computers - but the GUI should work right away. For the command-line
lovers, the "advanced" tutorials in the "User manual" under the "Help"
menu are a good intro to the "milhouse" command-line tool.

Well, my excuses currently is a) I have too little time (developing and setting up sms service in the field for an experimental theater group), and b) I cannot do clean-room package compilations due to a major part of my laptop being readonly (heating problem caused a power outage during a partition resize - all data seems fine but I cannot know for sure, and every time I try fsck'ing that heating problem strikes again).

In other words: my trouble is unrelated to the code quality :-)

I am looking for an example of doing this... (which uses cdbs and the autotools, if possible) Got any?


That one also demonstrates quite well IMO how a large amount of package dependencies are easier to track indirectly declared in debian/rules, as they they can be grouped and comments added as needed.

This is very interesting and am I looking forward to learn more about this. I will make some tests soon.

I am happy to hear that you are interested in those features. They are some of my newest additions to CDBS :-)

 - Jonas

 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Attachment: signature.asc
Description: Digital signature

pkg-multimedia-maintainers mailing list

Reply via email to