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 <d...@jones.dk>:
> On Wed, Jun 02, 2010 at 10:52:23PM -0400, Alexandre Quessy wrote:
>> 2010/6/2 Jonas Smedegaard <d...@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:
>> 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
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
> (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:
...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)
> -----END PGP SIGNATURE-----
> pkg-multimedia-maintainers mailing list
pkg-multimedia-maintainers mailing list