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 <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: >>> 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@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
