[10:40] Maaz: tell kbmonkey enjoy: http://www.linuxandlife.com/2011/12/8-text-based-applications-in-linux.html [10:40] nuvolari: Sure, I'll tell kbmonkey on freenode [13:13] nuvolari: nice list [18:03] hi all! [18:03] hiya superfly octoquad and others [18:03] hi Kilos, octoquad [18:04] looks like neil either forgot his lappy in ahab land or is taking a break from pc's [18:04] nuvolari, is als ok daar seun [18:05] ? [18:05] Maaz, coffee on [18:05] * Maaz flips the salt-timer [18:09] Coffee's ready for Kilos! [18:09] Maaz, ty [18:09] Enjoy Kilos [18:37] YaawwN [18:55] heh, cant use compiz with gnome3 [18:59] these "absa" notifications are starting to get annoying [19:01] zeref: Gnome3 or Gnome Shell? [19:02] oops [19:02] the shell [19:06] night guys. sleep tight [19:06] good luck tomorrow superfly [19:06] be thinking of you [19:06] thanks Kilos [19:07] zeref: Gnome Shell doesn't use compiz, it uses clutter [19:43] superfly: any progress with your packgae? [19:47] tumbleweed: nope, just been reading documentation and stuff [19:47] But I think I do see the differences in the packages - well, at least in the rules files [20:11] tumbleweed: in your opinion, should I upgrade the package format, or rather just fix up the existing package? or are they one and the same thing? ;-) [20:12] superfly: IIRC your package was pretty straight-forward, so not that much work, either way [20:12] Maybe for now fix it up, and then look at upgrading it later? [20:12] personally I'm not a CDBS fan, and prefer not to bring new packages into the archive, using it [20:12] but that's not rejection material [20:18] tumbleweed: is there a way we can do what we do in the Makefile without CDBS? [20:18] * tumbleweed tries to find suprefly's code again [20:19] found it [20:20] * superfly goes back to see the beets package [20:20] s/see/look at/ [20:21] * tumbleweed has a quick go at reworking it in debhelper [20:22] tumbleweed: can you pastebin me what you're doing please? so that I have a better understanding of what is going on [20:43] superfly: why are you installing the python bits in a different way to everything else? [20:44] tumbleweed: not too sure... I just followed cocooncrash's lead :-) [20:44] normally one uses a Makfile for everything or setup.py for everything [20:44] (the makefile is allow to call setup.py) [20:45] well, because this is a PyQt4 application, it needs to do a few things that Qt4 apps do, but it also needs to be installed like a Python app [20:45] ok, but you can make your setup.py do whatever you want, it could handle the qt translation stuff [20:45] I looked at the "eric" package (the PyQt4 IDE) and it was extra complicated [20:46] right now to install it, you have to run both setup.py install and make install [20:46] yeah, I figured as much [20:46] usually in that situation, one makes the makefile call setup.py for you [20:46] yeah, I was thinking that would be the way to do it [20:47] general tip: whenever you are writing a series of ;-separated commands (such as a loop) in a makefile, put a set -e; in front of it [20:47] otherwise you'll miss failures [20:48] yeah, I read that in the documentation, but thanks for reminding me [20:49] you don't need pyversions an dpycompat [20:52] superfly: here's a really quick pass http://paste.debian.net/148367/ [20:53] that's dh instead of CDBS, and dh_python2 instead of pysupport [20:53] next, I'll try and move it out of the sysetm python-path, it doesn't need to be importable for everyone [20:55] oh, you need to include the licence statement (not the complete licence, that can be referred to in /usr/share/common-licences) in debian/copyright [20:55] right. that's easy enough to do [20:56] and the format of that file has changed a little since you last use dit [20:56] http://dep.debian.net/deps/dep5/ [20:56] btw, dh_python2 can generate the dependencies from requires in the setup.py, if you want [20:58] tumbleweed: it's cool, at this stage we know the dependencies, and they vary slightly from distro to distro, so I think making them manual might be less hassle in the long run [20:59] yeah, same with ibid [20:59] it makes more sense to go the requires route if you are dealing with python people rather than distro people [21:02] python-sqlite... you know python contains sqlite these days, right? [21:03] tumbleweed: yes, but the python-sqlite package is for SQLite 2.8, which the old Windows version of OpenLP uses, so it's there so that people can import from it [21:03] the new version (i.e. this version we're packaging) uses SQLite 3, which is part of Python :-) [21:04] right, you probably only need to Recommend or Suggest it then [21:04] (recommends are installed by default, for almost everyone) [21:04] OK [21:04] yeah, it's only used in 2 or 3 places in the code, and even there it's a conditional import, as it were [21:05] if it's not there, the code doesn't fall over [21:05] ah, right, yes, it shouldn't crash without it [21:05] bonus points if it says "you need ... for this to work" [21:06] oh, the debian packaging includes the makefil [21:06] * tumbleweed simplifies further [21:07] http://paste.debian.net/148368/ <- install to a private location [21:08] tumbleweed: well, it says something of the sort :-) [21:14] superfly: http://paste.debian.net/148377/ [21:14] got rid of the Makefile, it wasn't doing anything *that* useful, and moved those bits into debian/rules [21:17] the "using two build systems on after another" thing works great in CDBS, but not so well in dh... [21:40] is everyone here based in Sa? [21:43] mostly [21:44] I miss home [21:44] I miss the African Mornings [22:00] tumbleweed: ping [22:03] yup [22:05] tumbleweed: how old is debhelper v7 ? [22:06] Maaz: rmadison debhelper [22:06] tumbleweed: *blink* [22:06] pish [22:06] it was in lenny, lucid, and hardy-backports [22:07] OTOH, dh_python2 is pretty new. It's only in squeeze, maverick and later [22:08] actually, I'm using debhelper 7.0.50 which wasn't in lenny or hardy-backports (but I think I have a local hardy backport of it somewhere) [22:08] and lenny has a 8.0.0 backport [22:08] We currently use Launchpad's PPA service to build packages for 10.04, and I'm just wondering if I need to keep our current package for the PPA, and this "new" one for Debian [22:09] dh_python2 was supposed to be backported to lucid. Just nobody has doen it yet [22:10] the packages it produces have less moving parts (more reliable), and are faster to install / remove [22:19] tumbleweed: OK, thanks for all of this... I had to do a little manual patching, because one or two small things changed in the package since you last looked at it [22:19] I think everything is fine [22:20] superfly: can you post it somewhere and I'll have a look? [22:21] uh, sure, I'll just commit it and push it up to LP quickly [22:23] tumbleweed: http://bazaar.launchpad.net/~raoul-snyman/openlp/debian-package/files/head:/resources/debian/debian/ [22:25] superfly: looking... [22:25] (oh, btw, I did notice a fair number of lintian warnings and errors that should still be dealt with) [22:27] * superfly makes a note of that [22:28] * tumbleweed likes new packages to be lintian-clean [22:28] then they can stay lintian-clean [22:28] tumbleweed: how do I build this package on my local machine? [22:28] Oh, I'm all for lintian-clean :-) [22:33] superfly: so, it's not entirely trivial because of your odd layout [22:33] normally, it's just "debuild -uc -us" (-uc -us meaning don't both signing) [22:33] or bzr bd -- -uc -us for a bzr branch [22:35] easiest option here is: bzr export ../openlp-1.9.7 [22:35] cd ../openlp-1.9.7 [22:35] ln -s resources/debian/debian . [22:35] debuild -uc -us [22:36] let me give that a go then [22:36] err and then that'll break because your package has changed from the .orig.tar.gz [22:36] so you may want to temporarly change debian/source/format to 3.0 (native) [22:36] OK [22:37] (keeping your packaging in your main branch, in an unusual subdir, is something tools are not going to like you for) [22:38] what should I do instead, keeping in mind that we have build or packaging systems for mulitple platforms [22:38] don't bother too much about keeping your packaging in the branch up to date [22:38] rather have something workable there [22:38] but keep the packaging for the version in the archive separately [22:39] currently I keep the stuff in bzr up-to-date, and then when an update comes through, I copy it over to a specific location on my VPS, which submits the nightly builds for us [22:40] you don't use launchpad's built-in daily builds? [22:40] no, I think we started this before Launchpad started their built-in daily builds [22:41] also, in practice, daily-build packaging teends to have different needs to in-debian packaging [22:42] tumbleweed: yep, that's why I decided to rather separate them now [22:42] I moved that stuff out to another directory [22:43] superfly: "either version 2 of the licence." ? [22:43] heh [22:44] lemme fix that :-) [22:45] if you meant "or later", change the licence to GPL-2+ [22:46] no, I meant GPL2 only [22:46] Just trying to double-check the text [22:50] superfly: lintian says [22:50] P: openlp source: source-contains-prebuilt-windows-binary resources/windows/psvince.dll [22:50] P: openlp source: unknown-copyright-format-uri http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ [22:50] OK, the first one I know, but the resources directory should not be packaged [22:51] the second one I'll have to double-check the format [22:52] superfly: the package just contains everything that's in the .orig.tar.gz (i.e. everything you release as your source tarball) [22:52] if that's necessary for your windows builds, you may want to find an alternative, or a way to build it (I don't know what it is) [22:53] right [22:53] I'll check how the orig.tar.gz is built [22:54] of course, we can also construct a separate source tarball for Debian (and debian packages often have to do this, to remove nasty stuff), but that's non-ideal [22:54] *packagers [22:57] well, that stuff shouldn't be in the nightly builds either, so I should really work on how to eliminate it in any case [22:59] oh, whoops, those were only the source package lintian warnings. I let you off lightly :) [22:59] Thanks for all your help tumbleweed. I need to get to bed, a long day ahead of me tomorrow! [22:59] you'll also hit: [22:59] P: openlp: no-upstream-changelog [22:59] W: openlp: embedded-javascript-library usr/share/openlp/openlp/plugins/remotes/html/jquery.js [22:59] W: openlp: binary-without-manpage usr/bin/openlp [23:00] (don't woryr about no-upstream-changelog, if you don't have it, you don't have it) [23:00] np, night.