Hello again!

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.

(more text below...)

2010/6/4 Jonas Smedegaard <d...@jones.dk>:
> On Fri, Jun 04, 2010 at 04:57:40PM -0400, Alexandre Quessy wrote:
>>
>> Hello Jonas,
>>
>> So I have set up a Debian sid box. That will help. :)
>
> Good!
>
>
>> 2010/6/4 Jonas Smedegaard <d...@jones.dk>:
>>>
>>> On Thu, Jun 03, 2010 at 11:59:18AM -0400, Alexandre Quessy wrote:
>>>
>>>> Done. I will have to add your license to the copyright of some of the
>>>> Debian packaging.
>>>
>>> What I do is maintain packaging licensing in debian/rules.  And I
>>> (ideally, when not too lazy) do not add licensing info of others but instead
>>> request them to add it themselves. ;-)
>>>
>>
>> Oops! I added your name to debian/copyright. Please edit it or remove it
>> if it's not the way you like.
>
> No problem.  I only tried to aim at a best practice. :-)
>
>
>>>>> It does seem, however, from a quick glance, that some parts of the
>>>>> project is not arch-limited.  It might be a good idea to split packaging 
>>>>> to
>>>>> provide most possible to all archs.
>>>>>
>>>>
>>>> That would be nice, but it's probably going to be difficult. The
>>>> jack-info, dc-ctl and midistream utilities could be packages separately, 
>>>> and
>>>> should be useful for the multimedia-loving masses. Since scenic relies on
>>>> milhouse, they could be packaged together. Again, I am a close-to-beginner
>>>> in packaging, so I am not sure where to start, especially that the current
>>>> build process is unified and using a single autotools configure.ac script.
>>>> It would imply splitting it upstream, no?
>>>
>>> Packaging typically goes like this:
>>>
>>>  1. Prepare
>>>  2. configure
>>>  3. build
>>>  4. install
>>>  5. reinstall into package area
>>>  6. tune packaging
>>>
>>> Here, steps 2-4 is done by autotools, and 5-6 is done by debhelper.
>>>
>>> So splitting into multiple packages is (more or less) a simple matter of
>>> adding more binary packages in debian/control and hinting in
>>> debian/*.install which autotools-installed parts each of them should
>>> contain.
>>>
>>
>> Ok, so in this case, let's say we brake it into 3 packages:
>>
>> * scenic (contains the Python app, the documentation, the glade data,
>> and the icon, etc.)
>> * scenic-utils (dc-ctl, firereset, jack-info and milhouse
>>  executables. Man pages and some shared libraries)
>> * midistream (python app and man page)
>>

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)

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

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

>
>> I am looking for an example of doing this... (which uses cdbs and the
>> autotools, if possible) Got any?
>
> sugar-0.88
>
> 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.

Later,
Alex

>
>  - Jonas
>
> --
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCgAGBQJMCYEZAAoJECx8MUbBoAEhKXAP/2q8119/HgJP2BD856hY+P2l
> wQWaq+sQrG5E7jZX+n9TWu/uB/p8dYdp3LZ57a6LDD7r/ogjEi69tcXV6hpanyYr
> 4+zE+DGPp1dj+wgOPmJWOUrhqR/Qcvm/MDiRBHUt2M/XX5iPkDR1NIpSjgoZJEAP
> WqOam84408ni0gKTKH5SDvHJqU9P5cuT5zMKi5Au8oKE+wcnW/2UXmKwFiNvLITQ
> SfTZ/0ECF2JozdF9j+mp+Q78QnU/zyTkj2keElN980lubp++WmFeBg52Xfn0P7Lf
> SeBbddZ24hYKA8duJb1cuKrmswmsIkglYNlguep+8JYi41NZ2eZRCI2lmylJZ9Pd
> YwLgVXnRUwvMgIorRIfiSFnfEhU3PTjMyGPSa88VfmDxJWTIH14MeV6oqhSlmU5t
> 6gO3oP9jX2P85TeKNXvg3xqL6yPf+hner+UGuFh0idKvjRpmq1H7FCnbJ60lb/y+
> ugyC0fRwVG4E3y6OhQ70GTQvVmQLgZMxB8RV3vM+IlNgZxEP4u+VLxcil8Ks2ERh
> zni8ApChFsL17buk6anBPUwSzF1s6UJiT/TQ0lfcgd8hS9BiteKpVPkd6lwqL8aB
> dgSB8pyYn6tUoFgNNWldwvtAXatnTxUioJJzTGlbcj/D/6qDNO+wJsKDvDG4mUDo
> WjN/P76euTwVEy16XxVR
> =dUhs
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers@lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
>
>



-- 
Alexandre Quessy
http://alexandre.quessy.net/

_______________________________________________
pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers

Reply via email to