=== medberry is now known as med_away
[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?
=== Philip6 is now known as Philip5
[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
=== statik_ is now known as statik
[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] <ubottu> Launchpad bug 737340 in exiv2 (Ubuntu) "Exiv2 has to be rebuilt after libexpat got 'multi-arched'" [Undecided,Confirmed] https://launchpad.net/bugs/737340
[06:08] <fabrice_sp> I've subscribed sponsors, so it can also follow the normal workflow :-)
=== Amaranth__ is now known as Amaranth
[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
=== ogra is now known as Guest78603
=== Guest78603 is now known as ogra_
[10:18] <\sh> siretart:  bug #724452 just fix by colin 27 mins ago :) (thx cjwatson)
[10:18] <ubottu> Launchpad bug 724452 in live-boot (Ubuntu Natty) "live-initramfs is uninstallable in natty" [Critical,Fix released] https://launchpad.net/bugs/724452
[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?
=== debfx_ is now known as debfx
[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
=== ogra_ is now known as ogra
[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.
=== arand_ is now known as arand
[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] <ubottu> acarpine: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
[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.
=== evilvish is now known as vish
[18:15] <hakermania> micahg: Hello :) How is it going with Wallch after all :) ?
=== emma is now known as em
[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
=== paultag_ is now known as paultag
[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] <ubottu> libcgi-pm-perl (source: libcgi-pm-perl): module for Common Gateway Interface applications. In component universe, is optional. Version 3.49-1 (maverick), package size 220 kB, installed size 616 kB
[19:13] <fta> !info libcgi-pm-perl natty
[19:13] <ubottu> libcgi-pm-perl (source: libcgi-pm-perl): module for Common Gateway Interface applications. In component universe, is optional. Version 3.51-1 (natty), package size 202 kB, installed size 600 kB
[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
=== Lutin is now known as Guest41153
[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
=== Guest41153 is now known as Lutin
[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
=== ogra is now known as Guest95250
[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
[21:36] <mok0> <packagename>.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
=== Guest95250 is now known as ogra