Fwd: RFS: Scenic 0.6.0 - Telepresence software for live performances and installations

Thu Jun 3 15:59:18 UTC 2010

Hello!
Some updates, since I'm currently working on this...

I have to fix the make clean upstream. There are still *.pyc files not
cleaned. (fixed) Some files are removed from the dist target. (It will
be effective in the next upstream release, which is 0.5.12)
There are "_trial_temp" and ".libs" directories which will be cleaned
up as well.

2010/6/3 Jonas Smedegaard <dr at jones.dk>:
> On Wed, Jun 02, 2010 at 10:52:23PM -0400, Alexandre Quessy wrote:
>>
>> 2010/6/2 Jonas Smedegaard <dr at jones.dk>:
>>>
>>> After a nice meal I now have some comments on your packaging:
>>>
>>> First of all: Please package using git-buildpackage and upload to the
>>> pkg-multimedia repository - more info here:
>>> http://wiki.debian.org/DebianMultimedia/DevelopPackaging
>>>
>>
>> Done. Everything seems to be OK, as far as I know.
>
> Looks ok to me too.  You should probably add a debian/gbp.conf file to
> ensure pristine-tar is used in the future too.  See e.g. morituri package
> for an example of that.
>

Done. I will have to add your license to the copyright of some of the
Debian packaging.
Actually, git-buildpackage doesn't work anymore with this. I removed
it locally... I am missing some point on how to use pristine-tar. It
needs the upstream tarball in the parent directory, or so... working
on this.

> (it is not that morituri is the most excellent package out there, I just
> picked one that is tiny and has little unusual stuff - I generally seek to
> evolve all packagings that I am invovled in into examples for others to
> reuse, so tell me if you want an example of some specific quirk and I'll try
> find a package demonstrating it!).
>

[removed some replied-to text...]

>
> On a related note, I see that you bumped to debhelper 7.  Beware that this
> might provide no benefits over debhelper 6, and may make it more difficult
> to backport, if you happen to care about that.
>

I decreased it to version 6. I am not sure that backporting will ever
be possible, since Scenic (milhouse) relies on recent versions of
GStreamer plugins. We'll see. :)

>
>>> The binary package is arch: any, but the configure.ac checks for
>>> linux/videodev2.h which I suspect means that the package will only
>>> succesfully compile on Linux architectures.  If correct, then the best would
>>> probably be to fix it upstream to avoid Linux-specific parts when on
>>> non-linux archs, or alternatively to tighten to package only on Linux archs.
>>>
>>
>> Well, for now, Scenic relies heavily on the GNU/Linux kernel. (For the
>> dc1394 module and V4L2) Should we put something like uclinux-*?
>
> I don't know what you mean by uclinux-*.

`dpkg-architecture -L` lists me a whole lot of uclinux-something:
uclinux-armel
uclinux-i386
uclinux-ia64
uclinux-alpha
uclinux-amd64
uclinux-armeb
uclinux-arm
uclinux-avr32
uclinux-hppa
uclinux-m32r
uclinux-m68k
uclinux-mips
uclinux-mipsel
uclinux-powerpc
uclinux-ppc64
uclinux-s390
uclinux-s390x
uclinux-sh3
uclinux-sh3eb
uclinux-sh4
uclinux-sh4eb
uclinux-sparc
...that might be the list I am looking for.

>
> What is common to do is to replace "any" in "Architecture: any" with all
> known-to-work Debian targets that is supported by the project.
>
> I dislike such hardcoded lists, however, and prefer to instead
> semi-automatically resolve it, either through dependent package (see e.g.
> calf for an example of that) or using type-handling (can't find an example
> of that right now).
>
> 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?

>
>>> Either json or simplejson is used upstream.  Are you aware that those
>>> implementations are not fully interchangeable (one of them - I forgot which
>>> - do not follow JSON specs!), and they might be slow too?  The Sugar project
>>> switched to python-cjson for these reasons.
>>>
>>
>> Ok. Being the main upstream author for the Python in Scenic, I will
>> try check if switching to python-cjson is seemless. Note that in the
>> Python code, I check if the "json" module is the same as the former
>> "simplejson" module. Simplejson is part of the standard Python library
>> as "json" since Python 2.6. I could depend on either python >= 2.6 or
>> python-simplejson. See http://docs.python.org/library/json.html ... I
>> don't know why Python named the module the same name as the former
>> json module.... but replaced it by a new - different one.
>
> I am no expert in the area.  Tell me if you would find it useful that I try
> dig out the relevant ML thread at the Sugar project.
>

Wouldn't it be simpler to depend on python (>= 2.6) |
python-simplejson ? If not, I'll try with cjson.

>
>> Thanks a lot for you help!!
>
> As Harry Tuttle says in the movie "Brazil":
>>
>> Listen, kid, we're all in it together.
>
> :-)
>
>> I will get back to you when I will work more on this tomorrow and the days
>> after. This is very appreciated.
>
> Looking forward to that!
>
>
>  - 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)
>
> iQIcBAEBCgAGBQJMB4KvAAoJECx8MUbBoAEh3kgP+wWYeleSgos2Jh0xnMsRBiuT
> YT056iRNr4sxlGRHQq/fc0QHjU0hnvLGSLLxPOmJZ+Wa8cjpxgvBKNF6Ez8P4Er7
> 5tVJhkw5eECvc6Yr2R2hDGo/UtU0uCq8eG+63W5bwAJ0+BxBQNgqHc2hqoKvyUo8
> Fm7TuDxp1Y0043fC0NmUOrFNHUmrTgYXC9dnf/dBad7LMzvA69yvuaYJ3i6Fi07O
> YTEW9YNJgChSnvpBV0i3KV3lkVJie++6JKG/TJ7BHEUdX2tXtPPuNUn1+mWKLy9l
> r8+eK8vEb+gvKX5IZU3CRCfcYAE5LUxxiqpu7sU/QbLEdEHkqbIUzmlmxDSmxXKc
> RwcNk1H6D911YoKggT2vBvYTilBfsVUFm32zz/wHixb1qv0MEbg0EmJkM25KGQIN
> Yk94TASWILi1PFOnGx1Ev57ZpBwIIHAgFxvlR92ZSZX7grxeXkiIIPgXX40cjj6C
> GFDX4hbeA5MapGLXdtQOGJYtmsIPIiU3LcZX+Ve/uEVRiLA/LuBVOBs6zXt5Otdy
> 77658VwwjvKboOxKSmA538TyVUCMUjDVdC0uorgXX3yh9+LW+fDn6Tb7E6bqosAs
> pQMn9lCdGrLduTZqdcxbIuuE1NpozRHPK+JB0HNHjeG3hOooSPk7zNn5UTD1RRYy
> /FDXA/1Zy9Yjvz3AH7t+
> =AJT+
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintainers at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
>
>

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