[01:16] <plainas> I'm having troubles making a module available to python through a deb package
[01:17] <plainas> wouldwhat would I put on my setup.py if i want to add a module to my system
[01:17] <plainas> ?
[01:30] <psusi> g_signal_new() takes a class_offset argument that seems to be the offset to a function pointer within the class.  Is this function pointer the class internal handler for the signal that is invoked whether or not any other classes connect to the signal?
[01:33] <chrisccoulson> psusi, yes
[01:33] <chrisccoulson> and that can be overridden by subclasses too
[01:33] <psusi> chrisccoulson, so what if that pointer is never initialized?  shouldn't it at least be set to null in the class _init function?
[01:54] <arand> If I want to supply a .png file for a menu icon, should I also supply an .xpm version, and how do I specify things in the .desktop and .menu files then? can I install both and
[01:55] <arand> ... specify just the name in .desktop and specifically the .xpm file in .menu?
[02:10] <Pici> 2!fort
[02:10] <Pici> oops
[04:23] <fabrice_sp> slangasek, sorry for the delay: got distracted. Working on it now. By the way, I found that libwmf-dev has the same issue, so it needs a rebuild too (and a patch to empty dependency_libs line in .la)
[04:24] <slangasek> fabrice_sp: ok, no worries :)
[06:08] <fabrice_sp> slangasek, in case you're still free,  bug 737340
[06:08] <fabrice_sp> I've subscribed sponsors, so it can also follow the normal workflow :-)
[07:38] <slangasek> fabrice_sp: LGTM; making one change to the changelog comment (it's not true that all reverse-deps need to be rebuilt for the multiarch change, only those that have bad .la files) and uploading
[07:57] <slangasek> fabrice_sp: uploaded, and forwarded to Debian, thanks :)
[08:14] <dholbach> good morning
[08:38] <iulian> Morning dholbach.
[08:55] <dholbach> hey iulian
[10:18] <\sh> siretart:  bug #724452 just fix by colin 27 mins ago :) (thx cjwatson)
[10:30] <cjwatson> \sh,siretart: well, I think so.  it's not the sort of thing I can test easily, but switching that dependency around seemed like a no-brainer
[10:43] <\sh> cjwatson: I'll take a look next week with an fai installation running on natty
[10:45] <arand> I want to supply a .png for my menu icon in a package, and I currently only have a .desktop file used for the menu, but should a .menu item also be used for compatibility reasons, would I then use 2 icons?
[11:18] <Laney> tumbleweed, bdrung: Do you think it would be reasonable to get u-d-t to use the new credentials_file stuff?
[11:18] <mok0> arand: AFAIK you only need a desktop entry
[11:18] <Laney> I'm importing lpapicache from a script which I've got running from a cronjob and would ideally like it to not randomly fail...
[11:19] <mok0> Laney: indeed :-)
[11:19] <bdrung> Laney: doesn't launchpadlib handle this stuff?
[11:20] <Laney> you need to pass credentials_file to login_with to bypass the gnome-keyring stuff
[11:20] <bdrung> i like to use gnome-keyring
[11:21] <Laney> it doesn't make sense for cronjobs
[11:22] <bdrung> Laney: and there is no easy way to bypass gnome-keyring otherwise?
[11:22] <Laney> apparently you can uninstall python-gnomekeyring
[11:22] <Laney> anyway I'd be happy with optional API support for this
[11:22] <Laney> or an env var or something
[11:23] <bdrung> env var sounds good. that could be implemented directly in launchpadlib
[11:26] <Laney> filing, will see what they say
[11:47] <mok0> Hm, if I do ls -a |sort I get dot-files sorted after their second character. How do I switch off that behaviour??
[12:16] <siretart> \sh: cjwatson: thanks! but this still won't unbreak it as it will AFAIUI still try to edit /etc/inittab, which doesn't exist anmore in ubuntu
[12:19] <cjwatson> siretart: not as far as I can see.  it only appears to do that if sysvinit is installed.
[12:20] <cjwatson> the bit of code you're talking about is guarded by if [ ! -e /var/lib/dpkg/info/sysvinit.list ] ...; then return; fi
[12:20] <cjwatson> not to mention testing for /var/lib/live/config/sysvinit which I assume is in live-config-sysvinit not live-config-upstart
[12:34] <tumbleweed> Laney, bdrung: uninstalling python-gnomekeyring is very much a workaround. The problem is that python-keyring needs to support this kind of thing better
[12:34] <tumbleweed> it supports the use of an unencrypted(?) keyring without gnome / kde keyyrings, but only just
[15:05] <EvilPhoenix> is there still a possibility of submitting something for review for the natty repos, or did they freeze adding additional packages to the repos?
[15:08] <geser> EvilPhoenix: no new packages for natty as we are in FeatureFreeze
[15:08] <EvilPhoenix> geser:  any possibility of submitting something for future inclusion?
[15:08] <EvilPhoenix> or maybe submitting something for the lucid or maverick repos?
[15:11] <ScottK> EvilPhoenix: If it's a package you're really interested in, you might try to get it into Debian and then it will automatically be in the next Ubuntu release.
[15:12] <EvilPhoenix> ScottK:  yeah, Debian's packaging thing is evil, because everything's packaged for Ubuntu (from what I hear, Ubuntu packages aren't backwards-compatible with Debian's packages)
[15:12] <EvilPhoenix> ScottK:  also, where would I start if i wanted to get it into debian?
[15:12] <ScottK> EvilPhoenix: We're a derivative of Debian, so this is what you'd expect.
[15:12] <EvilPhoenix> indeed
[15:12] <ScottK> EvilPhoenix: Start at mentors.debian.net.
[15:15] <geser> btw is the ApplicationReviewBoard running? didn't follow it
[15:22] <ScottK> It is.  I believe they actually accepted one package.
[15:24] <Laney> check extras.ubuntu.com
[16:05] <acarpine> Hi omniscient people! I'm fixing several .desktop files of several packages
[16:05] <acarpine> I believe I should submit my changes to the upstream projects, but what's the right process to do it?
[16:05] <acarpine> 1) File a new bug in Ubuntu 2) Send a patch there 3) Forward the patch to debian
[16:06] <acarpine> or 1) File a new bug in Debian 2) Send a patch there
[16:07] <acarpine> and the wait the automatic sync to have the bug fixed in Ubuntu...
[16:10] <ScottK> It depends on the severity of the issue.  If it's minor, I'd do the latter.  Filing bugs upstream is good too.
[16:12] <acarpine> It's abs a minor bug
[16:12] <acarpine> ScottK: so i will use the second path
[16:12] <ScottK> OK. Good luck.
[16:13] <acarpine> ScottK: tks ScottK! just another question...please
[16:14] <ScottK> !ask | acarpine
[16:14] <acarpine> changing the changelog file for a patch that I will send to Debian
[16:15] <acarpine> I should use the unstable version in the first line
[16:15] <ScottK> I wouldn't provide a changelog, just the .desktop patch and an explanation why it's needed.
[16:15] <ScottK> If you do provide one, yes.
[16:15] <ScottK> Also revision should be -Y, not Xubuntu1.
[16:15] <acarpine> so debdiff is sufficient?
[16:16] <ScottK> Debdiff has the changelog in it, so make it an appropriate one, but yes.
[16:16] <acarpine> ok ScottK really tks for your help! :)
[16:16] <ScottK> You're welcome.
[18:15] <hakermania> micahg: Hello :) How is it going with Wallch after all :) ?
[18:47] <micahg> hakermania: sorry, will try to look this weekend
[19:04] <fta> micahg, i see you touched bugzilla. we have 3.6.3.0-2 in natty, but two months ago, upstream released 3.6.4 as a serious security upgrade
[19:08] <ScottK> fta: Is it just the security fix?
[19:08] <fta> ScottK, http://www.bugzilla.org/releases/3.6.4/release-notes.html
[19:09] <ScottK> fta: Do we have a new enough Perl CDI module?
[19:09] <ScottK> CDI/CGI
[19:13] <fta> it needs 3.51
[19:13] <fta> !info libcgi-pm-perl
[19:13] <fta> !info libcgi-pm-perl natty
[19:14] <fta> seems ok
[19:14] <fta> but bad for maverick
[19:22] <micahg> fta: well, I don't think I can get to it this weekend, but will try to keep on my radar, hopefully someone else can take care of it though
[19:23] <fta> micahg, initially, i wanted bugzilla 4 but it doesn't seem to be packaged yet
[19:29] <micahg> fta: 3.6.4 isn't either ;)
[19:31] <hakermania> micahg: Not a personal problem, but it should have been looked 3 weeks now, and we are anxious to see the result :D
[20:07] <kim0> Hi folks, I'm trying to package a new package (my first time) and facing some (I'd guess easy) problems .. Would someone have time to take a look
[20:09] <mok0> kim0: go
[20:09] <kim0> mok0: thanks :)
[20:09] <kim0> The pkg I'm trying is http://ms-sys.sourceforge.net/
[20:09] <kim0> it's trivially small
[20:09] <kim0> let me paste my rules file
[20:10] <kim0> http://paste.ubuntu.com/582237/
[20:11] <kim0> For some reason .. it tries to install to /usr/local and gets a permission denied → install: cannot create regular file `/usr/local/bin/ms-sys': Permission denied
[20:14] <kim0> inside the chroot .. PREFIX=/usr make install  .. works
[20:17] <mok0> kim0: your should set prefix=/usr
[20:18] <kim0> where should that go
[20:18] <mok0> kim0: in the install section, try just "make --prefix=/usr
[20:19] <mok0> kim0: and instead of PREFIX=/usr, use DESTDIR=$CURDIR/debian/tmp
[20:19] <kim0> I want a diff :)
[20:20] <mok0> kim0: but in fact I think "make install" is enough
[20:20] <kim0> well but it's not right
[20:20] <mok0> kim0: also, get rid of dh_clean
[20:21] <mok0> kim0: are you teaching me, or am I teaching you?
[20:21] <kim0> no you are
[20:21] <mok0> kim0: you can get rid of dh_installdirs unless you have a debian/dirs file
[20:22] <mok0> kim0: still talking about the install: target
[20:22] <kim0> ok deleting those 2 lines
[20:22] <kim0> and PREFIX="/usr" $(MAKE) prefix=$(CURDIR)/debian/$(package)/usr
[20:22] <kim0> should be
[20:22] <mok0> make install
[20:22] <kim0> just make install ?
[20:22] <mok0> yes
[20:23] <kim0> what was prefix=$CURDIR... trying to do
[20:23] <mok0> kim0:  that application is built in the build: target
[20:24] <mok0> kim0: but you deleted everything again by using dh_clean
[20:24] <kim0> oh wth
[20:24] <kim0> that template was generated for me by some tool .. so wouldn't think it'd be that broken
[20:24] <kim0> ok now retrying
[20:26] <kim0> guess google buzz would be good for this kind of thing .. having tracked history
[20:27] <mok0> kim0: you template assumes that the makefile is generated by GNU autotools, but it's not
[20:27] <kim0> I see
[20:27] <kim0> I edited the rules file and re-ran pbuilder
[20:28] <kim0> is that not enough for the changes to take effect
[20:28] <mok0> kim0: if you look in the apps makefile, you will se that it hardwires /usr/local
[20:28] <kim0> if its not defined yes
[20:28] <mok0> kim0: right
[20:30] <kim0> mok0: do I have to re-run debuild after editing rules ?
[20:30] <mok0> kim0: no
[20:30] <kim0> hmm .. I thought it was still running the old rules
[20:30] <mok0> mok0: just run fakeroot debian/rules clean
[20:30] <mok0> kim0: I mean :-)
[20:31] <kim0> I reran debuild .. this time the new rules are applied .. but still has errors
[20:31] <kim0> want the output log ?
[20:31] <mok0> kim0: wait up
[20:31] <mok0> kim0: in the install: target, use:
[20:32] <kim0> Well here it is anyway :) http://paste.ubuntu.com/582242/
[20:32] <mok0> PREFIX=$CURDIR/debian/tmp/usr make install
[20:32] <kim0> ok
[20:33] <mok0> kim0: DESTDIR instead of PREFIX; sorry
[20:34] <kim0> np
[20:34] <kim0> mok0: http://paste.ubuntu.com/582244/
[20:34] <mok0> kim0: handcrafted makefiles are always a problem
[20:35] <mok0> kim0: sometimes you need to rewrite them to get them to do things right
[20:35] <kim0> yeah I understand
[20:35] <mok0> kim0: yeah, try that
[20:35] <kim0> pbuilder crunching
[20:36] <mok0> kim0: it's gonna put manpages the wrong place if it works
[20:36] <kim0> it broke bec NEWS didn't exist
[20:37] <kim0> I deleted its name from rules
[20:37] <kim0> about to retry
[20:37] <mok0> kim0: ok
[20:38] <kim0> gah changelog is camelcase
[20:38] <kim0> correcting .. retrying
[20:38] <kim0> mok0: is the correct one, camelcase, or lowercase
[20:39] <kim0> for changelog
[20:39] <mok0> kim0: debian/changelog, lower case
[20:39] <kim0> ok
[20:39] <mok0> upstreams changelog, you never know
[20:39] <kim0> crunching
[20:42] <kim0> do I have to tear down pbuilder setup everytime :)
[20:42] <kim0> it's kinda slow
[20:42] <kim0> oh .. think it worked
[20:42] <mok0> kim0: yay
[20:43] <kim0> warning: Depends field of package ms-sys: unknown substitution variable ${shlibs:Depends}
[20:44] <mok0> kim0: probably there are no shared libs in the package
[20:44] <kim0> where is the resulting package
[20:45] <mok0> kim0: in pbuilders build area, probably in /var/cahce
[20:45] <mok0> cacje
[20:45] <mok0> chache
[20:45] <mok0> cache
[20:45] <mok0> damn
[20:45] <mok0> sdfa
[20:46] <kim0> :D
[20:46] <kim0> hehe
[20:46] <kim0> found it
[20:46] <kim0> lovely
[20:46] <mok0> kim0: run lintian on the .deb
[20:47] <kim0> mok0: a few questions please .. what's make target binary-arch
[20:47] <Rhonda> kim0: For building arch-dependent parts of the package
[20:47] <kim0> thnx
[20:47] <Rhonda> Erm, not building but creating the actual .deb packages
[20:48] <kim0> and what's the level of intelligence in dh_installdocs -a
[20:48] <kim0> how does it know what's "docs" ?
[20:48] <mok0> kim0: it has some standard things it looks for
[20:48] <mok0> kim0: man dh_installdocs
[20:49] <kim0> so upstream has files like FAQ and CONTRIBUTORS
[20:49] <kim0> have those been picked up
[20:49] <Rhonda> you put it into debian/docs (or debian/$packagename.docs)
[20:51] <mok0> kim0: you can use less to look at the content of a .deb file
[20:51] <mok0> kim0: if you have  LESSOPEN=| /usr/bin/lesspipe %s
[20:51] <kim0> mok0: why would I want that
[20:52] <mok0> kim0: to see what files it contains
[20:52] <kim0> mok0: lintian says .. long description is too long
[20:52] <kim0> is it 80 chars
[20:53] <mok0> kim0: hm, something is wrong
[20:54] <kim0> ?
[20:54] <kim0> W: ms-sys: extended-description-line-too-long
[20:54] <kim0> mok0: that's normal right
[20:56] <mok0> kim0: the Description line should be less than 80
[20:56] <kim0> ok
[20:56] <mok0> kim0: lintian -i will give you more info
[20:58] <kim0> mok0: copyright file has    Source: <url://example.com>
[20:58] <kim0> should that be upstream url ?
[20:58] <mok0> kim0: yes
[20:59] <mok0> kim0:  see http://dep.debian.net/deps/dep5/
[21:00] <kim0> mok0: should I worry about new-package-should-close-itp-bug
[21:00] <mok0> kim, not right now
[21:00] <kim0> cool
[21:00] <kim0> rebuilding to make lintian happy
[21:02] <kim0> mok0: lol .. the deb only contains /usr/share/doc
[21:03] <mok0> heh
[21:04] <mok0> kim0: lets rewind a bit
[21:04]  * kim0 nods
[21:04] <mok0> kim0: you can build the package in place, i.e. without pbuilder
[21:05] <mok0> fakeroot debian/rules build
[21:05] <mok0> fakeroot debian/rules install
[21:05] <kim0> hmm the commands I used were
[21:05] <kim0> debuild -S -kxxxx
[21:05] <kim0> sudo pbuilder build ../ms-sys*.dsc
[21:06] <kim0> is that completely different
[21:06] <mok0> kim0: yes, because we want to see what goes on during the build
[21:07] <kim0> ok the build is done
[21:08] <kim0> mok0: http://paste.ubuntu.com/582259/
[21:08] <mok0> kim0: look in debian/tmp, the tree should be there
[21:08] <mok0> kim0: ah
[21:08] <mok0> kim0: lots of probems
[21:08] <kim0> :)
[21:08] <mok0> problems
[21:08] <kim0> expected
[21:09] <mok0> for example mkdir -p /tmp/ms-sys-2.2.1/debian/tmp/usr/usr/local/share/locale/sv/LC_MESSAGES
[21:09] <mok0> ".../usr/usr/local/..." ??
[21:09] <mok0> :-)
[21:09] <kim0> yeah
[21:10] <mok0> kim0: somethings wrong with the env variables passed to the makefile
[21:10] <mok0> kim0: it should be: ..../debian/tmp/usr/....
[21:11] <kim0> not sure where the double usr comes from
[21:11] <kim0> I'll delete one usr
[21:11] <kim0> :)
[21:12] <kim0> mok0: it still installs to /usr/local right
[21:13] <kim0> install -D -m 644 mo/sv.mo /tmp/ms-sys-2.2.1/debian/tmp//usr/local/share/locale/sv/LC_MESSAGES/ms-sys.mo
[21:13] <mok0> kim0: yeah that's wrong
[21:14] <mok0> kim0: you have PREFIX=/usr ??
[21:14] <kim0> wasnt in the fakeroot .. added it .. seems to work
[21:15] <kim0> I mean it's in the file .. but wasn't on the command line
[21:16] <mok0> kim0: you might need it on the make install line too
[21:16] <kim0> DESTDIR=$(CURDIR)/debian/tmp/ $(MAKE) install
[21:16] <mok0> PREFIX=/usr DESTDIR=... make install
[21:16] <kim0> that's what it currently is
[21:16] <kim0> yeah
[21:16] <kim0> another thing .. the resulting deb doesn't have the binary still
[21:17] <mok0> kim0: let's deal with that when the build is correct
[21:17] <kim0> ok
[21:17] <mok0> kim0: the easiest at this stage is to build using fakeroot debian/rules install
[21:18] <mok0> and then check to see what's in debian/tmp
[21:18] <mok0> kim0: all files should be in their right places in that tree
[21:19] <mok0> kim0: then you use <packagename>.install to stuff them into the package
[21:19] <kim0> well the binary is there
[21:19] <kim0> under debian/tmp/
[21:20] <mok0> kim0: debian/tmp/usr/bin/ ?
[21:20] <kim0> debian/tmp/usr/bin/ms-sys
[21:20] <mok0> kim0: then you need a line in <pkgname>.install
[21:20] <kim0> is that normal or workaround
[21:20] <mok0> debian/tmp/usr/bin
[21:21] <mok0> kim0: normal
[21:21] <mok0> kim0: you need a line "dh_install" in the binary-arch target
[21:21] <kim0> echo 'debian/tmp/usr/bin' > debian/ms-sys.install
[21:21] <kim0> correct ?
[21:21] <mok0> yes
[21:23] <mok0> kim0: use dh_installman to install man page
[21:24] <kim0> the man page is installed
[21:24] <kim0> without needing that
[21:24] <mok0> kim0: ok, good
[21:24] <kim0> I guess it looks good
[21:25] <kim0> mok0: I've setup a ppa .. is it easy to push that there
[21:26] <mok0> mok0: yes, use dput
[21:26] <mok0> kim0: on the changes file
[21:27] <mok0> kim0: but first make sure it builds again with your pbuilder
[21:27] <kim0> I need dh_installman :)
[21:27] <kim0> putting and retrying
[21:28] <mok0> kim0: there are a bunch of dh_install* helpers for installing various things
[21:28] <kim0> why didn't the tool enable those
[21:28] <mok0> kim0: and they generally use <packagename>.* files
[21:29] <mok0> kim0: don't know, what tool?
[21:29] <kim0> well can't remember .. that was a week ago :)
[21:29] <kim0> any way
[21:29] <kim0> ms-sys: binary-without-manpage usr/bin/ms-sys
[21:29] <kim0> it's not picking up the man page
[21:29] <kim0> so I need a pkgname.* file
[21:30] <mok0> kim0: probably because it's in the wrong place
[21:30] <mok0> kim0: it should go in /usr/share/man/man1
[21:30] <kim0> install -D -m 644 man/ms-sys.1 /tmp/ms-sys-2.2.1/debian/tmp/usr/man/man1/ms-sys.1
[21:30] <mok0> yup that's wrong
[21:31] <mok0> kim0: it comes from upstreams makefile
[21:31] <kim0> yeah
[21:31] <mok0> I think MAN=share/man will do it
[21:31] <mok0> kim0: before make
[21:31] <mok0> kim0: like PREFIX et al
[21:32] <mok0> errr no it wont
[21:32] <kim0> MANDIR = $(PREFIX)/man
[21:32] <kim0> this is where we patch it ? :)
[21:33] <mok0> kim0: I think you need to edit the makefile to achieve it
[21:33] <kim0> can I do that
[21:33] <mok0> kim0: or, shove files around in rues
[21:33] <mok0> rules
[21:33] <kim0> mv ?
[21:33] <kim0> that sounds better
[21:33] <mok0> kim0: yes mv it from the wrong place to the right place
[21:34] <mok0> kim0: you might be able to do that in the ms-sys.manpages file
[21:34] <kim0> hmm
[21:34] <kim0> how do I know more
[21:35] <kim0> man the dh
[21:35] <mok0> put debian/tmp/usr/man/man1/... in there
.manpages just needs to locate the man pages. The script dh_installman determines from the file names where they need to go
[21:37]  * kim0 nods
[21:38] <kim0> so fakeroot .. builds whatever crap upstream wants .. then pkgname.* shuffles them around the way ubuntu wants them
[21:38] <mok0> kim0: you need to go through all parts of the debian/tmp tree to make sure everything you need comes into the pacakge
[21:38] <kim0> lovely .. built and lintian is happy
[21:38] <mok0> kim0: yes
[21:38] <mok0> kim0: pbuilder also uses fakeroot
[21:39] <mok0> kim0: only in a mystery build directory somewhere
[21:39] <kim0> hehe
[21:39] <kim0> mo file not picked up
[21:39] <kim0> debian/tmp/usr/share/locale/sv/LC_MESSAGES/ms-sys.mo
[21:40] <mok0> kim0: ugh
[21:40] <kim0> correct location ?
[21:41] <mok0> kim0: yes, you can use *.install
[21:41] <mok0> kim0: same one you used to install the binary
[21:41] <kim0> so mo files don't have a special file ?\
[21:42] <kim0> why is that
[21:42] <mok0> kim0: programmer lazyness I guess :-)
[21:42] <mok0> kim0: Most likely it doesn't need special treatment
[21:42] <kim0> I guess a better question
[21:43] <kim0> yeah .. why did manpages require a special file
[21:43] <mok0> kim0: because that script implements all the debian rules for manpages
[21:43] <kim0> mok0: mo was picked up
[21:43] <kim0> lovely
[21:43] <kim0> I feel in control :D
[21:44] <mok0> kim0: you're the man!
[21:44] <kim0> mok0: YOU are :)
[21:44] <kim0> I really really wanna put it in a ppa :)
[21:44] <mok0> kim0: high 5
[21:44] <kim0> 5
[21:44] <kim0> dput *.changes ?
[21:44] <kim0> just that
[21:44] <mok0> kim0: no, you need your ppa adress
[21:44] <mok0> kim0: can't remember the syntax
[21:45] <mok0> kim0: its documented on LP
[21:45] <kim0> dput ppa:kim0/ppa <source.changes>
[21:45] <kim0> yeah it is
[21:45] <kim0> trying
[21:46] <kim0> woot! it actually worked first time :)
[21:46] <mok0> \o/
[21:46] <kim0> woohoo
[21:46] <kim0> mok0: Thanks a zillion
[21:46] <mok0> kim0: np
[21:47] <mok0> kim0: enjoy your package
[21:47] <kim0> does it take time to reflect on web UI https://launchpad.net/~kim0/+archive/ppa
[21:47] <mok0> kim0: yeah
[21:47] <mok0> kim0: 10 mins or so
[21:47] <kim0> the decent thing to do later, is trying to get it into universe right
[21:48] <mok0> kim0: you can try...
[21:48] <kim0> yeah
[21:48] <mok0> kim0: we have a system called REVU for that
[21:49] <mok0> kim0: but it requires you come here and pester people for reviews
[21:49] <kim0> hehe
[21:49] <mok0> kim0: there's a long queue of packages there
[21:49] <kim0> mok0: shouldn't those reviews be part of patch pilot
[21:50] <kim0> or is that a different story
[21:50] <mok0> kim0: I don't thing we're there yet for new packages
[21:50] <mok0> and REVU is actually a pretty good tool
[21:50] <mok0> well gotta go
[21:51] <mok0> See you