[00:28] <savvas> how do people contribute to builds for other architectures, the ones in http://ports.ubuntu.com ? with pbuilder?
[00:30] <ScottK> You don't.
[00:30] <ScottK> We only do source uploads.
[00:30] <ScottK> All the builds get autobuilt.
[00:30] <ScottK> If something isn't building, figure out why and submit a fix is the thing to do.
[00:32] <savvas> ScottK: well i'm attempting to backport the newest smc actually for lpia architecture in my PPA, it didn't have a -dev package, which results in an error: http://launchpadlibrarian.net/21887176/buildlog_ubuntu-gutsy-lpia.cegui-mk2_0.5.0-2ubuntu1_FAILEDTOBUILD.txt.gz
[00:32] <savvas> and.. quite frankly I don't know how to "decode" that yet :)
[00:33] <savvas> (I need the libcegui-mk2-dev created by that source package)
[00:34] <savvas> I wonder if it would work if I grab a newer version
[00:34]  * savvas tests
[00:47] <directhex> lpia you can build on any i386 or amd64 machine
[00:47] <directhex> it's just a tweaked i386
[01:11] <savvas> directhex: thanks, didn't know that :)
[02:59] <anakron> HI all
[02:59] <anakron> What means lpia?
[02:59] <anakron> sorry if it is too noob
[03:00] <ScottK> Low Power Intel Architecture.  It's an i386 variant for low power machines like netbooks.
[03:00] <anakron> ok thanks
[03:00] <anakron> :)
[03:04] <anakron> someone knows why are not any motu helping in mentoring? junior mentoring
[03:04] <anakron> mm
[03:04] <anakron> i will say it better
[03:05] <anakron> why a junior mentoring request must stay frozen, waiting for someone that will accept it?
[03:07] <ScottK> Some of us think it's better to just ask for help here instead of having a dedicated mentor.
[03:07] <ScottK> You get a better variety of advice and get to know the community better.
[03:07] <anakron> yes
[03:07] <anakron> that's true
[03:08] <ScottK> So if you have questions, feel free to ask.
[03:08] <anakron> ok thanks
[03:08] <anakron> scott, if i only know some basics things of python and only do patches for desktop files
[03:09] <anakron> which must be my next step?
[03:10] <ScottK> I find it best to work on things that bother you.  Better motivation that way.
[03:10] <anakron> mm
[03:11] <anakron> interesting
[03:11] <anakron> its like a vengueance
[03:11] <ScottK> Yes.
[03:12] <ScottK> If you have some Python, https://bugs.launchpad.net/~pythonistas/+packagebugs is a list of Python based packages and their bug counts.   You might see if you can figure out one of those.
[03:13] <anakron> launchpad it's amazing :)
[03:28] <ScottK> anakron: If I accept you into that team you'll get the bugmail for all those packages.  Are you up for that?
[03:28] <anakron> :) yes
[03:28] <anakron> there are some easy bugs that can be fixed so fast
[03:29] <anakron> and the other...will be part of my training
[03:30] <ScottK> anakron: Done.
[03:35] <anakron> ill try to solved one of catfish
[03:35] <ScottK> When you do attach the patch to the bug and subscribe ubuntu-universe-sponsors to the bug.
[03:36] <ScottK> Then a sponsor will review it for upload.
[03:36] <anakron> ok
[03:41] <savvas> anakron: catfish has a bug?
[03:41] <anakron> https://bugs.launchpad.net/ubuntu/+source/catfish/+bug/283953
[03:42] <anakron> i was trying to find it XD
[03:42]  * savvas looks :P
[03:42] <savvas> hey wait a sec
[03:43] <savvas> anakron: check the version for this
[03:43] <anakron> ok
[03:43] <savvas> I asked for the new catfish to be included in ubuntu jaunty
[03:43] <anakron> it's in 8.10
[03:44] <anakron> it on jaunty too
[03:44] <savvas> nope
[03:44] <savvas> 0.3-2 is not 0.3.2-1 :)
[03:45] <savvas> I know, I almost made the same error :p
[03:45] <savvas> http://packages.ubuntu.com/search?keywords=catfish
[03:45] <anakron> im using 0.3.2-1
[03:45] <savvas> and the bug is still there?
[03:45] <anakron> yes
[03:46] <savvas> darn
[03:46] <savvas> go go go :)
[03:46] <savvas> and.. thanks for helping :)
[03:47] <anakron> its not a real bug
[03:47] <anakron> we need only to change the default folder to search
[03:47] <anakron> to a most used location, like home
[03:47] <anakron> that's all
[03:48] <savvas> hey, simple stuff is what makes it perfect
[03:48] <anakron> :) im not saying anything different
[03:48] <anakron> its fast and useful
[03:48] <anakron> but, im new on it and... i get confused
[03:48] <anakron> but im still fighting
[04:08] <anakron> avvas?
[04:08] <anakron> savvas?
[04:08] <anakron> you are a medical student?
[04:19] <savvas> yes anakron :)
[04:19] <anakron> nice, im pharmaceutical student
[04:19] <savvas> the other more relevant attribute I have is that I am a computer hobbyist hehe
[04:19] <anakron> me too
[04:20] <savvas> well, welcome to the beginners gang, I'm one as well :)
[04:20] <anakron> :) but your karma says that you are old here
[04:21] <anakron> :)
[04:21] <savvas> glad to have someone that knows what Oxcarbazepine is hehe
[04:22] <savvas> ah that's answering questions, closing/filing bugs
[04:22] <anakron> :O nice
[04:23] <anakron> im interested in packaging and python, but i cant find the right function in catfish
[04:23] <anakron> xD
[04:23] <savvas> (Don't ask, I was digging up some pharm books two days ago :P)
[04:23] <savvas> hold a sec, I'm editing a bug report
[04:25] <anakron> how you look for you home folder??
[04:26] <anakron> /home/~/
[04:26] <anakron> how is the right path?
[04:26] <Amaranth> anakron: ~
[04:26] <anakron> i found it savvas, its too simple, ill solve it tommorrow
[04:26] <Amaranth> anakron: $HOME
[04:27] <anakron> other way?
[04:28] <anakron> its not working in this way
[04:28] <savvas> anakron: either ~ or $HOME without anything in front
[04:28] <anakron> ok
[04:29] <savvas> test it: echo $HOME
[04:29] <anakron> does not work
[04:30] <anakron> i can set it to /home/anakron
[04:30] <anakron> but now for any user folder
[04:30] <savvas> ah wait, in python?
[04:30] <anakron> yes
[04:30] <Amaranth> there is actually a program that will read /etc/passwd and tell you
[04:31] <anakron> it was set like path='~'
[04:31] <anakron> imust go away, see you tommorow
[04:31] <savvas> homedir = os.path.expanduser('~')
[04:31] <savvas> meh
[04:31] <savvas> http://snipplr.com/view/7354/home-directory-crossos/
[07:24] <iulian> G'morning.
[07:47] <didrocks> morning o/
[09:54] <savvas> does anyone have a link or can paste me the proper format of GPLv2 notification in a file header of an upstream source?
[09:57] <iulian> savvas: file:///usr/share/common-licenses/GPL-2 and scroll down to "How to Apply These Terms to Your New Programs"
[09:59] <savvas> oh
[09:59] <savvas> I thought it wasn't there, thanks iulian :)
[10:36] <__Ali__> is there an option to assign DEB_DH_INSTALL_ARGS for a specific lib?
[10:36] <__Ali__> anything like DEB_DH_INSTALL_ARGS_libfoo?
[10:37] <__Ali__> the documentation is really poor
[10:38] <soren> __Ali__: No.
[10:38] <__Ali__> soren, how do you set the args for each lib then?
[10:38] <soren> You don't.
[10:38] <soren> Apparantly.
[10:38] <directhex> can;t you just pass that to dh_install manually in your install rule?
[10:39] <soren> What are you trying to do?
[10:39] <directhex> although what args would you even give dh_install?
[10:39] <__Ali__> just trying to copy different files for libfoo and linfoo-dev
[10:39] <__Ali__> libfoo-dev *
[10:39] <directhex> so use different .install files?
[10:39] <__Ali__> using cdbs
[10:40] <__Ali__> it took me a day to find out that opensuse build service does not work with .install files
[10:40] <directhex> that's odd. those are processed by dh_install, not by anything wlse
[10:40] <__Ali__> there must be a way without .install files
[10:41] <soren> __Ali__: How could it not work? dh_install looks for debian/<package name>.install. Are they using a broken debhelper?
[10:41] <__Ali__> soren, well it doesnt work
[10:41] <soren> __Ali__: Of course there's a way. debian/rules is just a Makefile. Yo ucan do whatever you want.
[10:41] <directhex> soren, AFAIK no, they use pretty normal chroots
[10:41] <slytherin> __Ali__: you can use install/libfoo and install/libfoo-dev targets in debian rules
[10:42] <__Ali__> soren, i'm just trying to be concise within csbd, what's the right way of doing it in cdbs framework?
[10:42]  * directhex still reckons PEBCAK, not an OBS issue with .install
[10:42] <soren> __Ali__: The right way is to create multiple .install files.
[10:42] <__Ali__> slytherin, no higher level commands with cdbs?
[10:42] <soren> __Ali__: I somehow doubt thye've managed to break that.
[10:43] <directhex> soren, so do i, i've built 100-install-file packages on there
[10:43] <__Ali__> there is DEB_INSTALL_DIRS_libfoo
[10:43] <slytherin> __Ali__: there might be. I am not aware of them.
[10:43] <__Ali__> why there shouldnt be DEB_DH_INSTALL_ARGS_libfoo
[10:43] <soren> __Ali__: What do you mean "higher level commands"?
[10:44] <soren> __Ali__: If anything, you sound like you want lower level.
[10:44] <directhex> indeed
[10:44] <__Ali__> soren i mean setting cdbs vars wich hides lower level commands
[10:44] <soren> __Ali__: Because noone has needed it. Because dh_install handles that sort of stuff by using multiple .install files.
[10:44] <directhex> cdbs isn't really meant for that though is it? dh7 is a better bet for simple-but-hackable
[10:45] <__Ali__> look at this http://74.125.77.132/search?q=cache:BtnedmhHfisJ:dev.blankonlinux.or.id/changeset/lontara%25252Ffirefox,7%3Fformat%3Ddiff%26new%3Dlontara%252Ffirefox,7+DEB_DH_INSTALL_ARGs_&hl=en&ct=clnk&cd=1&gl=uk
[10:45] <soren> Can we please stop this useless discussion and replace it with one where you say exactly what you've done, explain what you expect to happen, and what happens instead.
[10:45] <soren> ?
[10:45] <__Ali__> there is a $(DEB_DH_INSTALL_ARGS_$(cdbs_curpkg))
[10:46] <__Ali__> i'm going to give DEB_DH_INSTALL_ARGS_libfoo a try, it might be defined
[10:46] <soren> It's not.
[10:46] <__Ali__> i told you what exactly i've done and what exactly i'm trying to do
[10:47] <soren> Ok, sorry, I missed it htne.
[10:47] <__Ali__> opensuse bs does not see .install files
[10:47] <soren> Can you repeat?
[10:47] <soren> So you claim.
[10:47] <soren> I need to see evidence.
[10:47] <__Ali__> i'm trying to create a .rules file which works for different packages with cdbs
[10:47] <directhex> i call shenanigans, because i explicitly have used OBS with .install files
[10:47] <soren> ...because i think you're just doing it wrong, and it seems like a much better approach to fix *that* rather than bastardisin cdbs.
[10:47] <__Ali__> and i thought cdbs may work for different packages and without .install files
[10:48] <__Ali__> soren, you think too much!
[10:49] <__Ali__> it's as simple as i described
[10:49] <soren> Ok, I'll stop.
[10:49] <directhex> https://build.opensuse.org/package/show?package=Mono&project=home%3Aoerc - every one of those debs is made by a .install file
[10:49] <directhex> look at how many they are, all packagey and debish
[10:49] <__Ali__> directhex, where are the install files?
[10:49] <broonie> __Ali__: not using .install files would break rather a lot of packages.
[10:50] <soren> __Ali__: It's really simple, really. Unless you explain *how* it's broken, it's kind of hard to know what it is we're trying to work around and how to fix it.
[10:50] <directhex> __Ali__, in the source package. where else?
[10:51] <__Ali__> soren, i get empty debians, no so's are copied while they are given in .install files, the only way i could get them copied was by using DEB_DH_INSTALL_ARGS which only works for 1 lib
[10:51] <directhex> link to the OBS project?
[10:51] <soren> __Ali__: Look... I can't use "hey, I'm doing /something/ and it's not working, even though it works for eveyone else, so I want to do everything completely differently".
[10:52] <__Ali__> directhex, i see, the opensuse guys are not really experts with debs, as they admit, the official deb guid says upload rules, control etc directly, didnt say it should be in the compressed source
[10:53] <directhex> __Ali__, their debian documentation is poor. i just go with what works
[10:53] <directhex> and what works for me is a workflow where i don't trigger a rebuild on every commit
[10:53] <directhex> i.e. just uploading, dput style, whenever i want things building
[10:54] <__Ali__> directhex, i've been keep looking for a good deb example on obs, thanks for the link, the search engine is not good
[10:54] <soren> __Ali__: So unless you show me your source package, I'm just going to not believe that it doesn't work. And hence, there's nothing to fix.
[10:55] <__Ali__> soren, i think i'm going to try directhex's advice on putting things in the compressed source, that should give me a more standard env for deb packaging on obs
[10:56] <soren> OBS sounds like a horrbile, horrible place.
[10:56] <directhex> soren, it's not great, but unlike launchpad, understands a world with more than one distro
[10:57] <__Ali__> it's actually a great service with nice performance and generous hosting
[10:58] <__Ali__> they have been asking people with deb experience to help them, so it's not their fault if there deb part is not great
[10:59] <directhex> did they fix not parsing build-depends-indep? that was a blocker for me
[11:00] <__Ali__> didrocks, where in the source dir are the .install files?
[11:01] <directhex> .install files live in debian/, along with all packaging-related material
[11:02] <__Ali__> mono_1.9.1+dfsg.orig.tar.gz? is this the right file?
[11:02] <directhex> ehm... how much debian packaging experience do you have?
[11:02] <directhex> a debian source package is split into three files. that one is the orig, i.e. the upstream source code
[11:03] <directhex> everying done by the packager goes into the diff.gz
[11:05] <__Ali__> directhex, i thought i was doing something different, i have the same structure then, i have diff too, and everything in my debian/ is in diff too, why the heck it doesnt work then!
[11:06] <soren> We can only guess.
[11:06] <soren> ...since you still haven't shown us anything.
[11:07] <directhex> soren, this way is more fun!
[11:12] <__Ali__> directhex, why does uploading those files in debian/ also work?
[11:13] <directhex> hm?
[11:13] <__Ali__> there are 4 files that trigger rebuild:
[11:13] <__Ali__> changelog, rules, control and dsc
[11:13] <__Ali__> these files already exist in diff
[11:14] <__Ali__> mayb diff is extracted first and then those 4 files are overwritten
[11:14] <__Ali__> it probably ignored .install files
[11:14] <directhex> dsc does not exist in the diff
[11:15] <__Ali__> but the other 3 do
[11:15] <directhex> yes
[11:21] <__Ali__> directhex, is it necessary to use DEB_INSTALL_DIRS_libfoo := usr/lib/MyLib if i have usr/lib/MyLib in .install?
[11:22] <directhex> __Ali__, i have no idea. i only touch cdbs junk when wearing a hazmat suit
[11:23] <__Ali__> directhex, i was adviced to use cdbs in this channel because it's supposed to be more convenient :)
[11:23] <directhex> it has a... ehm... popular following
[11:23] <__Ali__> but the documentation is really bad
[11:23] <directhex> essentially it's fine as long as you never ever want to do anything different to the norm
[11:24] <__Ali__> the authors didnt know cmake very well
[11:24] <__Ali__> i have to unset some of the cmake vars they set
[11:29] <__Ali__> directhex, dh_install manual says:
[11:29] <__Ali__> Files named debian/package.install list the files to install into each package and the directory they should be installed to. The format is a set of lines, where each line lists a file or files to install, and at the end of the line tells the directory it should be installed in.
[11:29] <__Ali__> but this part: 'and at the end of the line tells the directory it should be installed in.', is not very clear to me
[11:30] <__Ali__> all .install files have only the source files, they dont set the target?
[11:30] <directhex> __Ali__, ehm, sometimes you want to rewrite the target location
[11:31] <__Ali__> directhex, ehm, so if you dont set the target, it's assumed to be the same as the source, ehm, why the manual, ehm, doesnt say that?
[11:32] <directhex> compare http://svn.debian.org/wsvn/pkg-mono/mono-basic/trunk/debian/libmono-microsoft-visualbasic8.0-cil.install?op=file&rev=0&sc=0 and http://svn.debian.org/wsvn/pkg-cli-apps/packages/ndoc/trunk/debian/libndoc1.3-cil.install?op=file&rev=0&sc=0
[11:32] <ScottK> __Ali__: Note directhex said cdbs is poorly documented ...
[11:33]  * directhex orders a mouse & bloo-ray drive
[11:33] <__Ali__> ScottK, i said that :) and dh_install is not cdbs is it?
[11:33] <StevenK> It is well documented -- it's just the documetation is the source code
[11:33] <StevenK> dh_install is debhelper
[11:33] <ScottK> __Ali__: Right.  Sorry,  just woke up
[11:34] <__Ali__> yes the manual is in the source code
[11:44] <__Ali__> directhex, do u also get errors on obs with Checksums-Sha in your desc?
[11:45] <directhex> hm? no
[11:46] <__Ali__> i get checksome error with those fields being in dsc
[11:46] <directhex> perhaps because the sums of your diff and/or orig don't match?
[11:47] <__Ali__> i simply run debuild -S and upload?
[11:48] <directhex> yes
[11:55] <maxb> cdbs not well documented? /usr/share/doc/cdbs/cdbs-doc.html is rather thorough
[11:57] <__Ali__> maxb, it doesnt explain the vars defnied by cdbs
[12:00] <savvas> firefox /usr/share/doc/cdbs/cdbs-doc.html
[12:00] <savvas> oops
[12:00] <savvas> wrong terminal :P
[12:03] <savvas> __Ali__: grep -i '^#' /usr/share/cdbs/1/rules/debhelper.mk
[12:04] <savvas> the comments in the rules have the info you need
[12:04] <savvas> but you're always welcome to provide your own manpage :)
[12:04] <directhex> sounds much nicer than just using dh7. yes sireee
[12:04] <savvas> or html whatever :P
[12:05] <savvas> directhex: what do you mean?
[12:06] <directhex> cdbs is 10% automagic, and 90% trying to hack around the automagics. dh7 minimal rules are rather easier to massage when the need arises, leading to a somewhat more balanced experience
[12:10] <__Ali__> savvas, thanks i normally use google codesearch
[12:16] <savvas> directhex: do you have a link to an introduction/tutorial to debhelper 7?
[12:16] <savvas> ah wait, I think I'm already using it :P
[12:17] <directhex> http://paste.debian.net/27457/ is a dh7 rules file with dpatch for patching
[12:17] <directhex> http://paste.debian.net/27459/ without dpatch
[12:17] <savvas> #
[12:17] <savvas> %:
[12:17] <savvas> #
[12:17] <savvas> dh $@
[12:18] <savvas> oops sorry
[12:18] <savvas> this means go through every dh_* command?
[12:43] <__Ali__> any example of configuring a file in  /etc/ld.so.conf.d/ for deb packaging?
[12:43] <maxb> "Configuring" ?
[12:44] <__Ali__> adding?
[12:44] <maxb> Just do it?
[12:45] <__Ali__> no fancy commands in cdbs?
[12:46] <maxb> It's a simple installation of a file
[12:46] <maxb> man dh_install, perhaps
[12:47] <__Ali__> so i can simply put a line in .install file?
[12:48] <__Ali__> and is there a conventional path for storing the source foo.conf file? or just in debian/ ?
[12:48] <isaac> just in debian is ok
[12:49] <__Ali__> ok, thanks
[12:49] <isaac> if there are loads of files feel free to create a directory
[12:49] <isaac> but if there is only one or two
[12:49] <isaac> it's ok to have them there
[12:54] <__Ali__> is it safe to delete the generated *.ex files by dh_make? all of them are optional right?
[12:59] <maxb> __Ali__: .ex == example
[12:59] <__Ali__> maxb, yes, but they are all optional features right?
[12:59] <maxb> yes
[13:03] <fransman> savvas: are you around ?
[13:06] <fransman> I just wanna say ... thank you for working on bug #319204
[13:09] <savvas> fransman: sure, no problem :)
[13:10] <__Ali__> where is the right place to call ldconfig in rules?
[13:10] <savvas> fransman: the problem is that the package isn't tested, as I've never run the application
[13:10] <fransman> but that's ok
[13:11] <directhex> __Ali__, postinst
[13:11] <fransman> this kind of things are going step by step
[13:11] <__Ali__> directhex, what about uninstallation?
[13:11] <directhex> __Ali__, postrm
[13:11] <savvas> fransman: the only problem is that it requires someone to tag the flumotion at debian as with the tag patch
[13:11] <savvas> because for some reason control@bugs.debian.org doesn't like me
[13:12] <fransman> doesn't like me ? is it a he or a she?
[13:12] <__Ali__> directhex, doesnt dh take care of this? dh_makeshlibs?
[13:13] <savvas> fransman: it should be an "it", but I've contacted the webmaster of the bugs, no reply yet :P
[13:13] <maxb> Yes, dh does.
[13:13] <__Ali__> maxb, there is no need to bother about ldconfig then?
[13:13] <directhex> __Ali__, take care of what specifically? dh things are run at COMPILE time. you need to run ldconfig at PACKAGE INSTALL time
[13:14] <__Ali__> isnt dh_makeshlibs called at package installation time?
[13:14] <directhex> nothing in debian/rules is called at package installation time
[13:14] <savvas> it creates something in postinst while building the package
[13:14] <directhex> certainly not a dh script to gather soname versions
[13:14] <maxb> No, dh_makeshlibs is not called at install time. However, various debhelper commands will make additions to your provided post/pre/inst/rm
[13:15] <__Ali__> what are all those dh_* in the log then?
[13:15] <maxb> There aren't any at package install time
[13:15] <fransman> savvas: can you contact the packages maintainer ? at http://packages.qa.debian.org/f/flumotion.html
[13:16] <savvas> fransman: I have, it's loic-m here in the channel - they are aware of the fix :)
[13:16] <__Ali__> dh_makeshlibs is a debhelper program that automatically scans for shared
[13:16] <__Ali__> libraries, and generates a shlibs file for the libraries it finds.
[13:16] <__Ali__> It also adds a call to ldconfig in the postinst and postrm scripts (in
[13:16] <__Ali__> V3 mode and above only) to any packages which it finds shared libraries in.
[13:17] <__Ali__> so it takes care of postinst?
[13:17] <maxb> That's what you just said
[13:17] <Laney> savvas: That's lool, not loic-m
[13:18] <savvas> woops
[13:18] <__Ali__> maxb, yes, but directhex objected :)
[13:19] <savvas> wait, let me check
[13:19] <fransman> Laney: thanks
[13:19] <directhex> i objected to you saying dh_makeshlibs was run at install time
[13:19] <savvas> irclogs/Freenode/lool.log:23:46:25<savvas> all done! http://bazaar.launchpad.net/~medigeek/+junk/flumotion/files
[13:20] <maxb> s/you need to run ldconfig at PACKAGE INSTALL time/you need to let debhelper arrange for ldconfig to be run at PACKAGE INSTALL time/
[13:20] <savvas> wheow, I contacted the right person
[13:20] <__Ali__> dh_makeshlibs takes care of calling ldconfig at install time
[13:20] <Laney> hoorah
[13:20] <jpds> ScottK: Any update on what to do with bug #321713 ?
[13:20] <ScottK> I haven't looked at it recently.  Let me try an do that.
[13:22] <__Ali__> maxb, does it make sense to change debian/dirs to debian/libfoo.dirs and debian/libfoo-dev.dirs to create dirs for different libs?
[13:23] <maxb> In any multi-binary package I would recommend always using qualified names for all debhelper files like dirs
[13:24] <__Ali__> if you use files for directory creation, how do you specify which package needs which dirs?
[13:30] <savvas> __Ali__: I think this is what you need: http://paste.ubuntu.com/112774/
[13:31] <savvas> I'm not sure though
[13:32] <__Ali__> savvas, thanks, but i dont understand maxb's recommendation regarding this
[13:33] <maxb> You asked a question, I basically said "Yes"
[13:33] <maxb> !dirs
[13:33] <maxb> oops
[13:33] <maxb> Wrong factoid
[13:33] <maxb> Anyway, the point is that you almost never need to use dirs
[13:34] <maxb> Only if you need to install _empty_ directories, usually
[13:34] <__Ali__> how do you create dirs then?
[13:34] <__Ali__> do they get created automatically?
[13:34] <maxb> debhelper itself will certainly create them automatically
[13:35] <__Ali__> good
[13:37] <__Ali__> maxb, so if we have something like: dh_install -plibfoo --sourcedir=debian/tmp, then simply adding '../foo.conf etc/ld.so.conf.d' in foo.install is enough?
[13:37] <__Ali__> no need to create etc/ld.so.conf.d? (even in in debian/tmp/)?
[13:38] <__Ali__> sorry, debian/foo.conf doesn't need to be copied to debian/tmp/
[13:38] <directhex> -plibfoo implies libfoo.install
[13:39] <savvas> __Ali__: it would be easier to show us what you have so far and on which package you're working on :)
[13:39] <__Ali__> savvas, sorry it's still local
[13:40] <savvas> no problem, but foos and moes can be confusing
[13:40] <__Ali__> osb has to install the whole vm for each build takes ages
[13:40] <directhex> that's normal
[13:40] <directhex> it's needed to ensure a clean build environment
[13:40] <directhex> launchpad does the same
[13:40] <directhex> and you should do the same when testing locally
[13:42] <__Ali__> directhex, its very very local, without osc build, it takes ages to build the whole lib
[13:46] <savvas> __Ali__: yes, but if you use dpatch for example, it will complain about leftover files if it's not cleaned properly :)
[13:48] <__Ali__> savvas, i prefer to rebuild the whole world every time, saves a lot of hassle, hopefully compilers will be 'real time' sometime before we all die
[13:48] <__Ali__> (by hardware improvements, of course)
[13:50] <oojah> __Ali__: Whether OBS/launchpad take ages to build it isn't the issue really - I guess that people just want to look at your debian directory and the orig.tar.gz.
[13:52] <__Ali__> oojah, sure, here you go: http://tinylink.com/?zBsW4GrEo2
[14:18] <directhex> binary package name should include soname
[14:22] <oojah> I've got a source tar that doesn't have license information in any of the source files, and hence little copyright information. Is there any point even starting to package it, or should I try to persuade upstream to make changes?
[14:34] <Laney> oojah: Sadly it's unlikely to be accepted without clear licensing info
[14:34] <Laney> but upstreams usually want their programs in distros so I'd imagine they would be receptive
[14:37] <hyperair> Laney: keyword being "usually"
[14:37] <dolanor> Hello
[14:37] <oojah> Laney: That was my understanding, thanks.
[14:37] <pochu> oojah: does it have a LICENSE file in the tarball?
[14:37] <hyperair> dolanor: hi.
[14:38] <oojah> pochu: I think so. I'm at work at the moment suffering from a bad case of "can't be arsed" :)
[14:38] <dolanor> The package I uploaded needs 1 more advocate :) http://revu.ubuntuwire.com/details.py?package=fsniper , please have a look any super REVUers :p
[14:40] <pochu> oojah: then it might be ok, but of course having the copyright and license information in the source files is much better
[14:50] <slytherin> is it really required to have license headers in source files. Does all-or-none approach work if there is a LICENSE file?
[14:50] <dixonionthedemon> oiy
[14:50] <dixonionthedemon> so i have a question
[14:50] <dixonionthedemon> anyone know how to get SL to work with ubuntu?
[14:50] <dixonionthedemon> 8.10
[14:50] <dolanor> sl ?
[14:50] <RainCT> dixonionthedemon: SL = Second Life?
[14:50] <directhex> silverlight or second life?
[14:51] <slytherin> dixonionthedemon: what is SL?
[14:51] <dixonionthedemon> second life
[14:51] <dolanor> Supa Lounge, fo course
[14:51] <dixonionthedemon> ^_^
[14:51] <RainCT> there is a repository somewhere
[14:51] <dixonionthedemon> i was reading up on the ubuntu forums, but the codes make no sence
[14:52] <dixonionthedemon> they just wont work
[14:52] <slytherin> isn't second life client open source?
[14:52] <dixonionthedemon> i have the terminal open right now
[14:52] <dixonionthedemon> yea
[14:52] <dixonionthedemon> prety sure
[14:52] <slytherin> then why isn't there a ubuntu package for it yet. :-)
[14:52] <RainCT> slytherin: too many updates
[14:52] <RainCT> afaik
[14:52] <dixonionthedemon> i downloaded the linux beta
[14:53] <dixonionthedemon> one fer linux
[14:53] <dixonionthedemon> i just... cant get it to install
[14:53] <dixonionthedemon> nor run for that matter
[14:53] <dixonionthedemon> i was up al last night typing in codes to get skype to work, the calling out part and fixed that
[14:54] <dixonionthedemon> it works now
[14:54] <RainCT> slytherin: btw, if you get it into the repos sabdfl will like you (http://www.markshuttleworth.com/archives/128) :P
[14:55] <RainCT> dixonionthedemon: here you have a package: http://www.getdeb.net/app.php?name=Second+Life
[14:55] <dixonionthedemon> leme se if that works
[14:55] <dixonionthedemon> ty
[14:56] <mok0> RainCT: where is common.py?
[14:56] <RainCT> dixonionthedemon: You're welcome. Ah, and next time better go to #ubuntu for support (this is a development channel)
[14:56] <dixonionthedemon> o
[14:56] <dixonionthedemon> ok
[14:56] <dixonionthedemon> couldnt remember that
[14:56] <dixonionthedemon> lol
[14:56] <RainCT> mok0: includes/
[14:56] <slytherin> RainCT: nah, my hand is full right now. :-)
[14:57] <mok0> RainCT: I've set up revu locally
[14:57] <__Ali__> dixonionthedemon, does skype work now? that audio problem with intrepid, is it gone?
[14:57] <dixonionthedemon> yea
[14:58] <dixonionthedemon> got it working last night :D
[14:58] <mok0> iRainCT: It can't find common
[14:58]  * RainCT will try it next week (when he's 18 :D), if it's great enough I *might* have a look at packaging it
[14:58] <RainCT> mok0: includes/common.py
[14:58] <mok0> RainCT: I see it
[14:58] <dixonionthedemon> ty SL is installing now :D
[14:58] <dixonionthedemon> aight thanks fer all yer help
[14:58] <dixonionthedemon> talk to yall l8rs
[14:58] <mok0> RainCT: but it wont accept "from common import *"
[14:59] <RainCT> uh.. his keyboard broke
[14:59] <mok0> RainCT: is there a way to set the search path?
[14:59] <RainCT> mok0: just to be sure, is there a common.pyc in scripts/?
[14:59] <mok0> no
[15:00] <RainCT> mok0: have you copied and modified htaccess.tmpl to .htaccess?
[15:00] <RainCT> especially this line:   PythonPath "sys.path + ['/srv/revu-production/scripts/', '/srv/revu-production/includes/']"
[15:00] <mok0> RainCT: bingo ;-)
[15:01] <RainCT> :)
[15:02] <oojah> pochu: Ok, thanks. The package needs patching to work properly anyway, so it might be worth talking to upstream first anyway.
[15:03] <RainCT> mok0: I'm afk for one hour.. If you have some question, just ask and I'll answer it later. (Or NCommander may also be able to help)
[15:03] <pochu> oojah: I think it's always a good idea to contact upstream when you're packaging something. Even to just say hi ;)
[15:03] <NCommander> RainCT, hrm?
[15:04] <mok0> RainCT: OK, thank you!
[15:04] <oojah> pochu: True, true, I had intended to do so anyway - I'll just have patches for them now :)
[15:04] <RainCT> NCommander: don't worry, mok0 is just being creative looking for new ways to break REVU *g*
[15:05] <NCommander> -_-;;;;
[15:16] <__Ali__> i'm trying to pack a wrapper for itk, which is somehow similar to vtk, so we have 1 source file which generates multiple binaries called python-itk, itk-java, etc
[15:16] <__Ali__> what makes each lib different is determined by cmake config
[15:17] <__Ali__> how is it possible to do this in .rules?
[15:20] <bddebian> Heya gang
[15:22] <pochu> hola bddebian
[15:23] <bddebian> Hello pochu
[15:23] <khashayar> Dear revuers, there are two packages on revu that we (the studio team) really would like to get into the archives before the freeze. Can anyone revu, please: http://revu.ubuntuwire.com/details.py?package=pencil and http://revu.ubuntuwire.com/details.py?package=rtirq. Thanks
[15:32] <mok0> khashayar: I'l ltake a look
[15:33] <mok0> khashayar: what about chibitracker? Are you interested in that? It's been sitting forever waiting for someone to take care of the package
[15:33] <khashayar> mok0: Thanks :-)
[15:33] <khashayar> I'll take a look at chibitracker.
[15:33] <mok0> khashayar: there was a lot of hype about it some time ago
[15:34] <iulian> Hiya bddebian.
[15:35] <khashayar> mok0: Looks nice. I'll take a closer look at it tomorrow. (Too much things going on right now :-p)
[15:35] <khashayar> s/much/many
[15:35] <mok0> khashayar: sure
[15:36] <bddebian> Hi iulian
[15:37] <khashayar> I've noticed that jack does not build with celt support, although it depends on celt. Further investigation revealed that jack needs celt >=0.5 (the version in the archives is 0.4). I fixed that locally, but /usr/lib/pkg-config/celt.pc is reads version 0.4.0. Where might the root of this be?
[15:38] <khashayar> (If anyone's interested in updating celt: LP 324289 with diff attached)
[15:43] <DktrKranz> ScottK: I've identified some packages we must have in before FF. I'm going to file bugs for them, so we can discuss in tomorrow's meeting.
[15:44] <DktrKranz> s/packages/package updates/
[15:45] <surfaz82> Hi!, I have a question
[15:45] <surfaz82> in this diff.gz file
[15:45] <surfaz82> http://archive.ubuntu.com/ubuntu/pool/universe/a/amule/amule_2.2.3-1.diff.gz
[15:45] <surfaz82> in debian/control
[15:45] <surfaz82> there is two "##"
[15:46] <pochu> what do you mean?
[15:46] <surfaz82> between quilt, and libcrypto++-dev,
[15:47] <surfaz82> I use pbuilder to resolve dependencies but, pbuilder give me a error with that ##
[15:48] <surfaz82> Does anyone know what are those two characters in the Build-Depends?
[15:48] <surfaz82> hi?
[15:48] <maxb> I would call them a bug
[15:49] <pochu> or a comment
[15:49] <surfaz82> but pbuilder give me a error...
[15:49] <maxb> I've not noticed anything in policy permitting comments inside wrapped fields
[15:50] <pochu> did you notice anything forbidding them? ;)
[15:50] <surfaz82> I think Pbuilder considered ##  as a dependencie
[15:50] <surfaz82> sorry for my bad English :(
[15:51] <maxb> pochu: Seriously, is there any provision for comments inside debian/control at all?
[15:51] <lidaobing> maxb, conside debian/README.source
[15:52] <maxb> lidaobing: see scrollback, we're not discussing how to do it, we're discussing whether an existing one is valid
[15:52] <lidaobing> maxb, sorry, :-)
[15:54] <pochu> maxb: probably not, but the Debian and Ubuntu buildds built it fine so it may well be a pbuilder bug rather than an amule one
[15:55] <pochu> maxb: and I think comments are allowed in debian/control. Not sure whether they are in the middle of a wrapped field though
[15:55] <maxb> The word "comment" doesn't even occur in the control-files chapter of policy
[15:55] <maxb> So even if the buildds got it right, it's still amule's bug
[15:56] <surfaz82> Ubuntu builds packages in a diferente way than pbuilder?
[15:57] <surfaz82> I mean to resolve dependencies
[15:57] <maxb> yes
[15:58] <surfaz82> Then So it is probably a problem of pbuilder
[15:58] <maxb> no
[15:59] <surfaz82> and then...?
[16:00] <pochu> maxb: right, I can't find it in the policy either
[16:00] <pochu> I thought I had read about that
[16:00] <pochu> surfaz82: might be in amule instead
[16:00] <pochu> I'll poke the maintainer for the next upload, I know him
[16:01] <maxb> The entertaining ambiguity here is... does the "##" cause the following dependency to be omitted or not
[16:02] <pochu> I'd say they cause what is following them until the next line break to be ignored
[16:02] <pochu> just guessing though :)
[16:02] <surfaz82> Well, another question. If a program has an incomplete translation will allow a patch?. I ask this because it is likely that this program does not publish a new version and the end user would be incomplete translation for a long time.
[16:04] <surfaz82> pochu, you are Ubuntu mantainer of aMule?
[16:04] <pochu> surfaz82: we are in sync with Debian
[16:04] <pochu> I used to care for it, yes
[16:07] <jdong> *cringe* ext4 just blew up in my face
[16:08] <Vest> hello there
[16:10] <Vest> can anybody help me with this? http://revu.ubuntuwire.com/details.py?package=gnome-quod
[16:12] <piratenaapje> Vest: You mean with the lintian warnings?
[16:12] <piratenaapje> Vest: Oops, not lintian :p
[16:12] <Vest> no :) Lintian was yesterday
[16:12] <Vest> the first question is: The Maintainer     field is invalid. It has to contain an @ubuntu.com address (usually the     Ubuntu MOTU Team's). The packager can leave his/her name as     XSBC-Original-Maintainer.
[16:12] <piratenaapje> Vest: The warnings being displayed I meant
[16:13] <ohe> hi all .. i had upload a package (gammapage) to revu..
[16:13] <piratenaapje> Vest: debian/control should have a field Maintainer with "Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>" as value
[16:13] <ohe> what's append next?
[16:14] <ohe> what's happens next /// sorry
[16:14] <piratenaapje> Vest: You can put the original maintainer in XSBC-Original-Maintainer
[16:14] <Vest> piratenaapje: I'm not sure I can get @ubuntu.com e-mail
[16:14] <jdong> heh and this is probably why we don't use experimental filesystems....
[16:14] <jdong> ext4 totally blew itself up
[16:14] <piratenaapje> Vest: You don't need to, just put "Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>" as value (no quotes :p)
[16:15] <Vest> piratenaapje: can you explain, why? because, at the moment I'm not a MOTU Developer, so who will get any messages for that application
[16:17] <piratenaapje> Vest: I guess cause they are the ones uploading it, not really sure
[16:17] <__Ali__> isn't it possible to have source and package names to be different in .control?
[16:18] <piratenaapje> Vest: You can still put your own email-adress in XSBC-Original-Maintainer
[16:24] <mok0> Vest: once the package is in Launchpad, you can subscribe to it
[16:25] <mok0> Vest: In fact, we expect that uploaders maintain &  care for their packages
[16:25] <piratenaapje> Vest: Is there a launchpad bug that requests packaging for the program you are trying to package?
[16:26] <piratenaapje> Vest: If not, report a [needs-packaging] bug in launchpad
[16:27] <piratenaapje> Vest: And then put a line stating: "Initial ubuntu release. (LP: #xxxxxx)" in debian/changelog
[16:27] <Vest> piratenaapje: no-no, this package doesn't exists
[16:27] <piratenaapje> Vest: Then file the bug yourself
[16:28] <Vest> yes, but the first thing is try to publish my own package to repos
[16:28] <joaopinto> Vest, the first thing you need to do is read https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[16:29] <joaopinto> without following those steps you will not be able to get it into the official repositories
[16:30] <Vest> joaopinto: yes, I've readed many faqs, but when I start to upload package to revu, I have some misunderstandings, which I ask there ^)
[16:31] <joaopinto> Vest, you need to read it more carefully, you are expected to create the LP bug before uploading it to review
[16:32] <piratenaapje> Vest: You should file a needs-packaging bug when you package something new, as stated in the link jaoapinto just gave you
[16:32] <joaopinto> since on the changelog (which is part of your REVU upload) must contain the LP bug you are trying to close
[16:33] <Vest> joaopinto: can you explain, why is this called a bug? does my program have any bugs before any uploads? :)
[16:33] <RainCT> xD
[16:34] <RainCT> Vest: it's a "workflow bug".. just so that other people know that someone is working on that package
[16:34] <Vest> hm... :)
[16:34] <joaopinto> some bug reports are just action items
[16:37] <piratenaapje> mok0: When you have time, could you take another look at http://revu.ubuntuwire.com/details.py?package=grnotify again? You previously advocated it, but I had to make some changes to fix the problems another MOTU found.
[16:38] <mok0> piratenaapje: In 10 minutes or so
[16:38] <piratenaapje> mok0: Awesome, thanks :)
[16:46] <mok0> piratenaapje: why is the release -0ubuntu2 ?
[16:46] <piratenaapje> mok0: So I could upload to my ppa
[16:47] <piratenaapje> mok0: It rejects if I try to upload something again with the same version
[16:47] <mok0> piratenaapje: you should append ~ppa1 to your PPA versions
[16:48] <piratenaapje> mok0: Ah ok, didn't think of that
[16:48] <loic-m> For your ppa, piratenaapje, you can also use jaunty/intrepid/hardy instead of ppa like 0ubuntu1~intrepid1, ect
[16:48] <mok0> piratenaapje: it hasn't been uploaded to ubuntu before?
[16:49] <piratenaapje> mok0: Nope
[16:49] <mok0> piratenaapje: ok, I will change it to 0ubuntu1 and upload
[16:49] <piratenaapje> mok0: Yay thanks, my first package in ubuntu :)
[16:50] <mok0> piratenaapje: time to celebrate!
[16:50]  * mok0 toasts in a virtual beer
[16:50] <piratenaapje> :D
[16:50]  * hyperair gets drunk from the smell
[16:52] <mok0> grnotify out of the way. *Phew*
[16:53] <piratenaapje> Hmm I don't get notification emails, that's weird
[16:53] <hyperair> piratenaapje: i had issues with that once too
[16:54] <hyperair> piratenaapje: make sure you're not subscribed twice
[16:54] <hyperair> piratenaapje: in my case, i think it was because i subscribed to the package, and also set in my preferences to receive notifications for all packages =\
[16:54] <piratenaapje> Subscribed to e-mail notifications for:  Own packages, grnotify
[16:54] <piratenaapje> hyperair: Same here
[16:55] <hyperair> yeah
[16:55] <hyperair> exactly
[17:11] <henrik-hw0> superm1, online?
[17:12] <superm1> hi henrik-hw0 yeah i saw your ping over the weekend, i should be able to look at the updated packages sometime today
[17:14] <henrik-hw0> i'll leave the connection should there be any issues.
[17:15] <henrik-hw0> s/connection/connection open/
[17:15] <Tonio_> rgreening, Riddell: pnm upoaded
[17:17] <rgreening> kool. ty Tonio_
[17:23] <^Spear> Hi
[17:24] <^Spear> Is anyone able to package  http://raop-play.sourceforge.net/ ?
[17:29] <Chris`> ^Spear's request is being looked at
[17:29] <^Spear> thanks :)
[17:38] <xnox> Hey all =D There is one package that I'm working on to update. The current tarballs in Ubuntu/Debian as well as the new upstream release and their svn repo all have ~200 files with copyright and licensing information missing
[17:39] <xnox> There is a top level license saying it's GPL 2
[17:39] <xnox> is this ok?
[17:39] <xnox> Cause I believe it's a release blocker. Other people think it's fine
[17:40] <pochu> why is it a release blocker?
[17:40] <Chris`> pochu: Archive admins may ask who owns this file
[17:40] <xnox> well what if it turns out those files are not GPL, or their authors were not properly recognised nor given copyright
[17:41] <pochu> is the package in the archive already?
[17:41] <xnox> The strangest thing is that ~ 100 other files _do_ have licensing and copyright headers.
[17:41] <xnox> yes it is in the archive already
[17:41] <xnox> source package sword
[17:42] <maxb> Are upstream going to do anything about it?
[17:42] <xnox> I've filed a ticket in their bug tracker and I have heard nothing back.
[17:42] <pochu> so if it's in the archive, archive admins consider it's ok (assuming it was that way when it was uploaded)
[17:43] <xnox> it was tarball inside tarball and i think that could have slipped by
[17:43] <pochu> I bet they check those too
[17:44] <xnox> right, ok. I will try to follow up on this issue with upstream though. It makes me feel uneasy.
[17:46] <pochu> maybe ask in #ubuntu-devel
[18:22] <iefremov_work> Hi all! Can anybody qualified answer my question: how do I update already archived package (upstream version change)? compiled binaries are not accepted yet.
[18:24] <hyperair> iefremov_work: what dyou mean?
[18:25] <loic-m> iefremov_work has the package been accepted in the repositories? What was the reason for archiving?
[18:26] <iefremov_work> hyperair: 1) some days ago i uploaded a package to REVU 2) it has been advocated twice and archived 3) it was built on palmer (i386) yellow (amd64) 4) now i want to update the package since there is new upstream version
[18:27] <hyperair> iefremov_work: file a needs-upgrade bug, attach a debdiff, subscribe ubuntu-universe-sponsors
[18:27] <loic-m> indeed
[18:27] <maxb> See wiki.ubuntu.com/SponsorshipProcess for reference
[18:27] <hyperair> if you're impatient, come here and bug every MOTU you can find to sponsor your debdiff =P
[18:27] <loic-m> iefremov_work: https://wiki.ubuntu.com/PackagingGuide/Complete#Recipe:%20Updating%20An%20Ubuntu%20Package
[18:28] <superm1> henrik-hw0, did have a question.  why don't you just refer to linux-headers-generic | linux-headers in your depends?
[18:28] <superm1> henrik-hw0, that way you dont have to update it at every new ubuntu release that includes new kernels
[18:28] <iefremov_work> hyperair, maxb and loic-m: Thanks!
[18:28] <loic-m> hyperair: does that work?
[18:28] <hyperair> loic-m: what?
[18:29] <loic-m> hyperair: bug MOTU
[18:29] <hyperair> loic-m: bugging every single MOTU you can come across? yeah sure it does. especially if you ask the one who advocated your REVU package
[18:29] <superm1> henrik-hw0, also, does the initramfs actually need to be updated? is this driver included in it if you do update it?
[18:29] <loic-m> hyperair: I need to upgrade my bugging 5k|llZ
[18:29] <hyperair> it works better than sitting around staring at the bug and watching it rot until upstream releases another package and you release yet another debdiff and so on
[18:29] <hyperair> loic-m: lol
[18:30] <loic-m> hyperair: some MOTU are going to love you pretty soon
[18:30] <superm1> henrik-hw0, and does it need to be put in /etc/modules?  Shouldn't it be loaded automatically my udev?
[18:30] <henrik-hw0> superm1: i suppose i could simplify the kernel headers dependencies. i just thought i'd be thorough.
[18:30] <hyperair> loic-m: is that sarcasm i hear?
[18:30] <henrik-hw0> does kernel-headers depend on the other kernel header packages?
[18:30] <superm1> henrik-hw0, yeah I understand the desire to be thorough, i just think you might shoot yourself in the foot with it because i know the kernels change often enough
[18:31] <loic-m> hyperair: just the (sad/funny) reality ;)
[18:31] <hyperair> loic-m: heh lol
[18:31] <loic-m> hyperair: just depends which side of the poke stick you are ;)
[18:31] <superm1> henrik-hw0, debian policy says you have to do a real package or a virtual package
[18:31] <superm1> henrik-hw0, which is why i said "linux-headers-generic | linux-headers"
[18:32] <hyperair> loic-m: =p
[18:32] <hyperair> loic-m: i wonder
[18:33] <hyperair> maybe i should apply for mentorship
[18:33] <hyperair> hmmm
[18:34] <iefremov_work> hyperir and loic-m: i see you are really experienced guys. Another question: AFAIU the package will be the part of Jaunty distro. Will it be possible to update it during the 'feature freeze' or any other release phases? There will be new major upstream version in the begining of March.
[18:34] <henrik-hw0> superm1: i'll have to run some tests on the module loading. it should be possible to autoload it AFAIK.
[18:34] <Laney> hyperair: Do you really find sponsorship takes that long?
[18:34] <hyperair> Laney: but of course.
[18:35] <jpds> iefremov_work: No, you'll need an exception to get it through.
[18:35] <hyperair> Laney: i've got a few bugs that's been sitting around collecting dust
[18:35] <hyperair> Laney: SRU stuff
[18:35] <superm1> henrik-hw0, yeah it's best not to touch /etc/modules from maintainer scripts.
[18:35] <Laney> SRU is a bit different as it blocks on a small number of people
[18:35] <Laney> general sponsorship is relatively swift I've found
[18:36] <Laney> certainly no need to poke people on IRC (which has the potential to annoy)
[18:36] <iefremov_work> jpds: and when it will be possible to update the package again?
[18:36] <superm1> henrik-hw0, i'll add these comments to the REVU so they're not lost
[18:36] <jpds> iefremov_work: After release.
[18:36] <iefremov_work> then the package will be in 'updates' repository, right?
[18:37] <jpds> iefremov_work: No, that's for important bug-fixes only.
[18:37] <hyperair> Laney: well come to think of it, with the exception of SRU bugs... i haven't handled many other bugs. the FTBFS bugs sure went fast though
[18:37] <henrik-hw0> superm1: good. did you have a change too look at libmirage and cdemu-daemon?
[18:37] <loic-m> Laney: we were mosty loking, but if you've got spare time I can afford having my bugs disposed of now ;)
[18:37] <Laney> did you subscribe motu-sru?
[18:37] <jpds> iefremov_work: The package will only get new versions uploaded at jaunty+1 after feature freeze.
[18:37] <hyperair> Laney: yeah i did
[18:37] <hyperair> Laney: for the main ones i subscribed ubuntu-sru
[18:38] <Laney> loic-m: No, I can't sponsor. And please don't ping unless it's been an inordinate amount of time (> 2 weeks or so)
[18:38] <loic-m> Laney: although I remember an SRU taking more than one month after having been decided/advocated
[18:38] <hyperair> currently i'm waiting on two main ubuntu-sru ones
[18:38] <hyperair> gnome-keyring and evolution-data-server
[18:38] <Laney> same for SRUs
[18:38] <loic-m> Laney: I don't ping for that. i just hope it gets processed before FF
[18:38] <Laney> loic-m: If you uploaded the diff before then it's fine
[18:39] <iefremov_work> jpds: still can't understand: if i update the package after release, will it be possible to user to 'apt-get' it?
[18:39] <hyperair> Laney: >2 weeks is inordinate? i've waited for months on end for some
[18:39]  * hyperair sighs
[18:39] <Laney> yes
[18:39] <loic-m> Laney: that's good to know
[18:39] <Laney> ideally it should be a FIFO queue, but I suppose people pick out things they want to sponsor
[18:39] <hyperair> Laney: there was one banshee bug which took over 3 weeks, and even then it got attention after a considerable amount of pinging
[18:39] <Laney> sync requests get disposed of very quickly
[18:39] <superm1> henrik-hw0, no i haven't looked at those.  i'll see if i get some more time this afternoon
[18:40] <Laney> hyperair: I don't know what you're doing different to me then - not really had this problem
[18:40] <hyperair> Laney: yeah i noticed. uswsusp's "sync" request has been sitting there since feisty though. it's more of a merge. maybe i'll tackle it and submit a debdiff
[18:41] <hyperair> Laney: pick the hard packages or the small insignificant packages and nobody pays attention =\
[18:41] <Laney> hyperair: huh? The sponsors aren't even subscribed to that
[18:41] <hyperair> Laney: uh what?
[18:41] <iefremov_work> hyperair: another question: if i update the package after release, will it be possible for user to 'apt-get' the updated package?
[18:41] <Laney> uswsusp
[18:42] <hyperair> Laney: ah right. well i didn't file it. i happened to stumble across it because cwillu was trying to figure out how to get uswsusp to work with usplash
[18:42] <jpds> iefremov_work: apt-get as in install the one in the archives? Yes.
[18:42] <hyperair> iefremov_work: depends how long after
[18:42] <Laney> well I don't know why you bring that up as an example of sponsorship delays
[18:42] <henrik-hw0> loic-m: if you ask me there should be designated mini-MOTUs who do some of the initial reviewing of the packages before things start to get serious. it would save a lot of time. :/
[18:43] <fabrice_sp> iefremov_work, to have a package updated in -update, you need to have serious reason for that (like serious bugs in previous version)
[18:43] <maxb> iefremov_work: For a critical bugfix you the released version, you'd follow the SRU process. For a new upstream version, you'd have to first get it into the current development release and then seek a backport according to the backports process
[18:43] <hyperair> iefremov_work: but if the user is on the current devel release, they'll definitely be able to
[18:43] <fabrice_sp> iefremov_work, or just upload it to your ppa
[18:43] <Laney> henrik-hw0: If you ask *me* people should become very familiar with packaging before they attempt to package something new so that these things aren't even an issue
[18:43] <loic-m> henrik-hw0: it's for the translation. AFAIU nobody really manage/coordinates translation for universe packages
[18:44] <hyperair> Laney: there are a few others as well, but i can't remember. probably my judgement is skewed by the fact that most of the bugs i mess around with are SRUs
[18:44] <iefremov_work> ok, thanks
[18:44] <loic-m> henrik-hw0: i'm more like considering you're "upstream" since those kind of packages are dealt with upstream
[18:45] <loic-m> henrik-hw0: and for Debian AFAIR it's the packager job to get/request translations, even though they should have a mailing list
[18:46] <Laney> hyperair: Bring it up on the ML, maybe they'll bring more people on board
[18:46] <hyperair> ML eh
[18:46] <hyperair> Laney: which ones
[18:46] <Laney> ubuntu-devel?
[18:47] <hyperair> that's for stuff in main right? what about stuff in universe
[18:47] <Laney> ubuntu-motu
[18:47] <hyperair> oh there's a list by that name eh
[18:47] <Laney> but I guess most people will be subscribed to -devel anyway
[18:47]  * hyperair searches for a link to subscribe
[18:47] <henrik-hw0> loic-m: It's almost always a good idea to get upstream to merge your stuff.
[18:48] <loic-m> henrik-hw0: I'm talking about your package, gcdemu, a string in the .po file ;)
[18:51] <loic-m> henrik-hw0: I do file bug upstream for my translations/desktop files on packages I modify. However, you're gcdemu maintainer ;)
[19:12] <khashayar> If I file an update request bug on launchpad with a diff.gz, do I assign myself to it and set it to "in progress"?
[19:16] <asomething> khashayar: no, if it is ready to be sponsored, it should be confirmed with no assignee and *-sponsors subscribed
[19:17] <asomething> khashayar: only leave it in-progress if you are still working on it
[19:18] <khashayar> asomething: Well, it's just a request for a new upstream version. I've built it and tested it, and there's a diff.gz attached. I don't think there's more to do. Should I just set the status to in progress?
[19:18] <loic-m> khashayar: once you've uploaded the diff.gz and checked the package works in Jaunty, > Confirmed
[19:19] <loic-m> khashayar: if the package is in universe, subscribe ubuntu-universe-sponsor once it's confirmed
[19:20] <khashayar> loic-m: "status confirmed", subscribe sponsor and no change to "assigned to". Correct?
[19:20] <loic-m> khashayar: if it's in main, subscrive ubuntu sponsors for main
[19:20] <khashayar> loic-m: Got it. Thanks!
[19:20] <loic-m> khashayar: yes. Assigned to > noone
[19:21] <loic-m> khashayar: don't forget to try if it installs and work ok in Jaunty, and say so in the bug
[19:21] <khashayar> loic-m: Will do.
[19:22] <loic-m> khashayar: always try the package in Jaunty before submitting the diff.gz and confirming/subscribing uus / usm
[19:22] <khashayar> loic-m: I've actually already done that. But it's really just minimal testing.
[19:41] <mrooney> anyone know why REVU says my package http://revu.ubuntuwire.com/details.py?package=wxbanker doesn't close a bug on LP?
[19:41] <mrooney> It seems to in the changelog
[19:42] <loic-m> mrooney: isn't the syntax (LP# number) ?
[19:43] <loic-m> mrooney: not 100% sure, but (Closes: #297289) is Debian syntax
[19:44] <mrooney> loic-m: debian syntax is wrong?
[19:44] <fabrice_sp> mrooney, it's LP: #number
[19:44] <mrooney> man I can't believe how hard it is to package things :[ I have been trying to do this for two months
[19:45] <mrooney> fabrice_sp: hm okay, I can change that
[19:46] <mrooney> Should I be trying to get a package in debian instead of ubuntu directly?
[19:48] <Vest> mrooney: at the present I'm working about uploading my package to ubuntu too :)
[19:48] <loic-m> mrooney: no it's just that for closed bugs, AFAIR Debian != Ubuntu
[19:48] <Vest> not so long as you do.... but enough :)
[19:48] <mrooney> Vest: yeah, I have only been able to get one review in 2 months of asking every few days
[19:49] <Vest> mrooney, tell me how? :)
[19:49] <mrooney> Maybe I am missing a step or something
[19:49] <loic-m> mrooney: you can either do both at the same time, or wait till your package is accepted in Ubuntu before you submit it to Debian
[19:49] <mrooney> loic-m: ahh okay, but you would recommend going to ubuntu directly in some way?
[19:49] <mrooney> at or before
[19:50] <Vest> I've submited a bug: https://bugs.launchpad.net/ubuntu/+bug/324440 (of my new application), and now succefully uploaded my package to REVU http://revu.ubuntuwire.com/details.py?package=gnome-quod, and I don't know what should I do
[19:50] <mrooney> Vest: I think you wait for king MOTUs to review it :)
[19:50] <mrooney> *kind
[19:50] <mrooney> but I guess king also works
[19:50] <loic-m> mrooney: i don't really recommend anything. I'm not sure what is best, depends on your prefered tools (Debian use something else than REVU)
[19:50] <Vest> I thought "king" :-D
[19:51] <asomething> mrooney: I'd normally say go to Debian first then sync to Ubuntu, but with Debian in freeze if you want to see it in Jaunty, straight to ubuntu would probably be the way to go right now
[19:51] <Vest> mrooney, can I look at your package for comparence?
[19:52] <Vest> asomething: I want to see my package in jaunty too :)
[19:52] <mrooney> Vest: sure. it's wxbanker (on revu). I am not sure how it will compare, mine is a cdbs python packaging
[19:52] <khashayar> I have fixed two small problems in jack-audio-connection-kit, one of which depends on LP 324289 being solved. The debdiff I have for jack fixes both of the problems, but they are indeed seperate bugs. Do I file two bug reports and upload the same debdiff to both of them?
[19:52] <Vest> mrooney: thanks, I'm going to take a look right now
[19:52] <mrooney> asomething: okay, I would love to see it there :) I'll probably post on planet.ubuntu.com once I feel good about and that might get a review or two
[19:53] <Vest> ooo, ubottu said about my package here? :)
[19:53] <surfaz82> pochu, if you have time, could you do this request?
[19:53] <surfaz82> https://bugs.launchpad.net/ubuntu/+source/amule/+bug/324458
[19:53] <Vest> is it a bot
[19:53] <mrooney> asomething: is it okay not to have a diff against the source? ie can I throw the debian/ in my version control while I am working on it? is that confusing or do motus just look at the actual files and not the diff
[19:55] <asomething> mrooney: you probably want to create a separate packaging branch
[19:55] <asomething> ~/wxbanker and ~/wxbanker/ubuntu
[19:56] <asomething> at least that's how I work
[20:00] <mrooney> asomething: okay cool, so now I've added that in bazaar, do I just tarball the export up as the orig or do I need to actually make a release
[20:03] <asomething> mrooney: well as you're upstream it's up to you, if you don't do a release then you debian rev number should show the revision from trunk like: 0.4.0.2+bzr92-0ubuntu1 or 0.4.0.3~bzr92-0ubuntu1
[20:04] <mrooney> okay, I don't want to confuse users by having a new release for trivial (to them) packaging compliance changes
[20:04] <mrooney> so I'll use revs for now and then make a 0.4.0.3 or whatever that is the actual complete packaging and upload that, or something
[20:07] <mrooney> asomething: but that workflow is right in that case? commit changes, tarball the bzr export as the orig, and debuild and dput?
[20:08] <mrooney> all this is a little overwhelming as this is my first packaging attempt :)
[20:10] <asomething> i usually just copy the debian folder from my packaging branch and use the pristine upstream tarball to make sure I don't carry over any un-need things
[20:12] <bdrung> from where can i checkout ubuntu packages in bzr?
[20:14] <Laney> bdrung: bzr branch lp:ubuntu/jaunty/package
[20:14] <Laney> afaik
[20:14] <Laney> try this post by james_w: http://jameswestby.net/weblog/ubuntu/07-fixing-an-ubuntu-bug-with-bazaar.html
[20:15] <asomething>  <bdrung> http://package-import.ubuntu.com/
[20:15] <bdrung> thx
[20:15] <Laney> oh, heh
[20:16] <Laney> I missed a part of that post
[20:16] <Laney> "how it will work in a short while when launchpad hosts the branches and all the bits are in place"
[20:16] <Laney> still, neat stuff, even if learning a new toolset scares me somewhat
[20:20] <fabrice_sp> Some MOTU to sponsor a sync request (Bug #324471) ?
[20:20] <Laney> fabrice_sp: Why is this too important to wait for u-u-s to get to it?
[20:21] <fabrice_sp> Laney, we are not close of Feature Freeze?
[20:21] <Laney> 17 day
[20:21] <Laney> s
[20:21] <fabrice_sp> ooohhh
[20:21] <Laney> and even then, sponsorship asked for before FF will still be allowed
[20:22] <fabrice_sp> Laney, for Intrepid, I missed a sync before FF and had to justified it afterwards, with a FFE..
[20:22] <RainCT_> (OT, if someone knows how to workaround bug 163156 please tell me :P)
[20:22] <fabrice_sp> but we still have time
[20:23] <Laney> fabrice_sp: you filed it before ff?
[20:23] <fabrice_sp> Laney, yes
[20:23] <fabrice_sp> it was for a library
[20:23] <Laney> I remember people working to clear the queue, so that's very odd
[20:25] <fabrice_sp> Laney, Bug #242572
[20:25] <mrooney> james_w: could you ping me when you are around? I want to use fancy bzr packaging and was hoping you could point me at doing it correctly
[20:25] <fabrice_sp> so sorry for being so paranoid :-)
[20:59] <mrooney> phew, okay, if anyone wouldn't mind giving me a sanity check / review of http://revu.ubuntuwire.com/details.py?package=wxbanker, I've just uploaded a new version
[20:59] <mrooney> maybe it is good to go!
[21:00] <mrooney> I would appreciate it EVER so much
[21:01] <pochu> surfaz82: I've told the Debian maintainer about it. thanks
[21:02] <surfaz82> ok
[21:03] <surfaz82> pochu, then I close request?
[21:04] <pochu> surfaz82: yes, you can
[21:10] <mok0> mrooney: why is the package arch dependent, when it's not?
[21:11] <mrooney> mok0: a mistake, is probably why!
[21:11] <mrooney> mok0: what did I do that makes it arch dependent?
[21:11] <mok0> mrooney: when you put Architecture: any in control
[21:12] <mok0> mrooney: you want all, not any
[21:12] <mrooney> ahh
[21:12] <mrooney> I thought any means one build will work on all of them
[21:12] <mok0> mrooney: subtle, huh?
[21:12] <mrooney> and all means to build separately for each
[21:12] <mok0> mrooney: any =  it will be built on all of them
[21:13] <mok0> mrooney: all = it will be built on 1
[21:14] <mrooney> mok0: ahh okay, let me fix that. does it look fine otherwise?
[21:14] <mrooney> thanks btw :)
[21:14] <mok0> mrooney: I have some other comments
[21:14] <mok0> looks ok
[21:15] <mrooney> mok0: oh okay, what are the other comments
[21:15] <mok0> mrooney: I'll leave them in the comment field on revu, it's easier that way
[21:16] <mok0> mrooney: Ready in ~10 minutes
[21:16] <mrooney> mok0: thanks so much :)
[22:03] <RainCT> «since already some time I'm noticing some rivalry between GNOMe and KDE suers, like those against beatles and rolling stones... or windows vs common sense»   LOL
[22:08] <ScottK> I don't feel any sense of rivalry.  I just don't understand why anyone would use Gnome.
[22:08] <RainCT> heh
[22:08] <Chris`> Nor do I understand why people evangelize KDE!
[22:09]  * ScottK wasn't evangelizing.  Feel free to use what you want.
[22:10] <Laney> ScottK: How low quality and dangerous are the kubuntu-experimental PPAs?
[22:10] <Laney> those words make me wary about even installing them
[22:10] <ScottK> That's their point.
[22:11] <ScottK> Currently not so bad as they have KDE 4.2.0 in them.
[22:11] <ScottK> They are a pretty direct backport of what's in Jaunty.
[22:11] <RainCT> Laney: here they are unusable :(
[22:11] <ScottK> RainCT: What happened?
[22:12] <RainCT> ScottK: I don't really remember the details now, but the graphics are mad.. moving a plasma widget, a window or whatever sometimes hangs for a while and stuff like that
[22:12] <RainCT> (also, I couldn't find how to get a 2 screens setup, but that's probably just me being silly)
[22:12] <ScottK> That may be the Compiz Xorg hack that I blogged about last wekk.
[22:13] <ScottK> Dual screen setup is quite doable.  I know people that have them.
[22:14] <RainCT> ScottK: and that problem is fixed by now?
[22:14] <ScottK> We have a 'fixed' xorg-xserver in that PPA now.  Of course if you worry about compiz performance, you may not want it.
[22:14] <pochu> I wished the UWN was less poluted
[22:15] <ScottK> RainCT: Here's the gory details http://www.kitterman.org/ScottK/2009/01/bug_254468_momentary_video_gar.html
[22:16] <Hobbsee> pochu: poluted?
[22:16] <RainCT> ScottK: is it the one from your PPA?
[22:16] <RainCT> xorg-server - 2:1.5.2-2ubuntu3.00~ppa1
[22:17] <ScottK> Yes.  Same onr.
[22:17] <ScottK> one even
[22:17] <pochu> Hobbsee: err, bloated
[22:17] <RainCT> ScottK: I have it installed then. Didn't notice any slowdown
[22:17] <ScottK> Ah.  Good to know.
[22:17] <Hobbsee> pochu: ahhh
[22:19] <Laney> What do I need to install to get kde4.2 from that PPA? Will just kubuntu-desktop do it?
[22:19] <ScottK> Should.
[22:19]  * ScottK looks at JontheEchidna.
[22:19] <RainCT> (My graphics card isn't bad, though... Perhaps other people may notice a different)
[22:21] <Laney> ScottK: Worked
[22:21]  * Laney takes the plunge
[22:21] <ScottK> Great.
[22:23] <JontheEchidna> Yeah, kubuntu-desktop
[22:23] <RainCT> ok, let me try KDE again.. /me switches session
[22:26] <Hobbsee> mok0: wouldn't the launchpad 3.0 plan have been done months ago?
[22:27] <RainCT> ScottK: Uhm... Seems like it works fine now.
[22:27] <ScottK> Great.
[22:28] <RainCT> And I absolutelly love the look and feel... If GTK applications wouldn't look that awful I might even switch to it :P
[22:28] <Hobbsee> mok0: more to the point, is there any indication anything will get done with the feedback/liason, or are you guys going to be wasting your time, for what sounds to be a good thing, but is bikeshedding?
[22:29] <RainCT> (Random comments: networkmanager-kde is ugly, and the folder plasma thingie doesn't recognize .desktop files and shows their extension.. :P)
[22:30] <JontheEchidna> we should be getting a sexy kde4 replacement for networkmanager-kde for jaunty
[22:31] <JontheEchidna> the current one is the barely-working kde3 version
[22:32] <ScottK> As long as the KDE4 one barely works as well and the KDE3 one, I'll be happy.
[22:33] <RainCT> dual screen is still not working.. system-settings only shows one screen, and using nvidia-settings (which I use on GNOME) one screen works but half of the other one is black XD
[22:33] <RainCT> and I've lost transparency
[22:33] <JontheEchidna> yeah, but at least kwin doesn't crash anymore
[22:33] <JontheEchidna> :P
[22:35] <directhex> wake me when n-m *really* supports static ip :/
[22:37]  * JontheEchidna just sets up eth0 in /etc/network/interfaces and removes n-m from his system
[22:38]  * Laney cannot cope with change
[22:38] <directhex> JontheEchidna, well, yeah. sadly, that's the only option
[22:39] <RainCT> directhex: here n-m works fine :P
[22:39] <directhex> Laney, you can't override the "auto eth0" default n-m connection. delete it, convert it to static, make a different connection default, doesn't matter. on next boot, "auto eth0" will be the connection it uses, i.e. dhcp
[22:40] <RainCT> Ah, that may also happen here. I have WLAN by default so I don't really know
[22:40] <Laney> I meant KDE :(
[22:41]  * pochu hopes his mail to -motu doesn't sound bad
[22:43] <directhex> pochu, do you call them all poop-faced smellypants?
[22:44] <mrooney> mok0: thanks for the comments! why am I not the correct maintainer in Ubuntu?
[22:45]  * ScottK hands mrooney https://wiki.ubuntu.com/DebianMaintainerField - I think that explains it.
[22:46] <mrooney> ScottK: but I am upstream and downstream
[22:46] <ScottK> So the policy may not be relevant in your case.
[22:47] <ScottK> But generally we want the team to be the maintainer and you are original maintainer.
[22:47] <ScottK> Is that a problem?
[22:47] <mrooney> ScottK: I don't really what that implies, I guess
[22:48] <mrooney> I would think MOTU would welcome and chance to not be the maintainer of another package :)
[22:50] <zMoo> hello
[22:50] <pochu> mrooney: we usually welcome people getting their packages into Debian so we can just sync :)
[22:50] <ScottK> As a practical matter it doesn't make a lot of difference as we tend to feel responsible anyway.
[22:50] <ScottK> +1 to what pochu said.
[22:50] <mrooney> :|
[22:50] <mrooney> every time I come in here I get told to do a different thing than the last time, haha
[22:50] <ScottK> mrooney: If you're involved enough in Ubuntu to become a member, then you get an @ubuntu.com address and it's no problem.
[22:50] <mrooney> ScottK: I am!
[22:51] <ScottK> Did you use your @ubuntu.com address as maintainer?
[22:51] <mrooney> ScottK: yes
[22:51] <zMoo> a new upstream package is available for the package swac-get. I've created a bug on the lauchpad and attached a new source package for jaunty. Is it the right procedure?
[22:51] <zMoo> https://bugs.launchpad.net/ubuntu/+source/swac-get/+bug/324561
[22:51] <ScottK> mrooney: Sorry I didn't look at the package.  That should be fine then.
[22:52] <mrooney> ScottK: okay, thanks :)
[22:52] <RainCT> mrooney: and REVU complains even if it's @ubuntu.com?
[22:53] <mrooney> RainCT: no, I just got a comment to change it
[22:53] <RainCT> ah ok
[22:53] <mrooney> also how important are manpages? it isn't a requirement in main so is it a problem to have the initial package without one?
[22:54] <mrooney> I assume it would go in universe?
[22:54] <RainCT> mrooney: manpages are great, please include them :P
[22:54] <mrooney> RainCT: tell that to mozilla :)
[22:54] <directhex> manpages are not Free enough. info pages plz!
[22:54]  * directhex hides
[22:55] <RainCT> mrooney: yeah, if I had to decide all packages would need manpages to enter main :P
[22:55] <RainCT> there are a lot of core applications who lack one :/
[22:55] <mrooney> I know, I have to use google to figure out how to edit my firefox profiles every time :[
[22:56] <Hobbsee> ?
[22:56] <Hobbsee> mrooney: you clearly don't use zsh.  Fix it.
[22:57] <Hobbsee> mrooney: firefox -<tab>.
[22:57] <Hobbsee> (assuming the tab completion stuff has been turned on, etc)
[22:57] <RainCT> well, I'm off.. Good night
[22:58] <Hobbsee> ;)
[22:58] <ScottK> mrooney: Generally I won't advocate a package that is missing them as there is zero incentive for people to add them later.
[22:59] <Hobbsee> ScottK: sure there is.  when those who aren't zsh users need to keep googling, then they might provide a patch :P
[22:59] <mrooney> ScottK: but if the requirements are too high then less people can get over the hump of getting a package in ubuntu
[22:59] <ScottK> True, but the leverage on the person who wants it in the archive kind of goes away.
[23:00] <ScottK> mrooney: True, but I tend to think we have 'enough' and so stuff that wants in does need to meet a certain standard.
[23:14] <mrooney> ScottK: yes, I suppose that makes sense. I am just trying to make it easier for people to use my package by getting it into the archives. I guess having a manpage would help that further though :)
[23:14] <mrooney> however having a PPA seems 10x easier for me and about equally as easy for people
[23:15] <mrooney> so that seems like an alright approach initially I guess
[23:17] <ScottK> Note that I'm not super picky about how comprehensive they are as long as they point at where to find more information.
[23:18] <Hobbsee> pochu: come to think of it, i'd actually argue that PPAs are both not so useful to MOTUs (although it certainly has been for some groups, like kde), but has actually done a disservice as well, with all the extra support.
[23:19] <mrooney> ScottK: I think I am just feeling stuck because every review I get says "here are some issues: x x x other than that it looks good!" and then the next review by someone else will point out three NEW things to do. It feels like I am never getting anywhere. Every time I fix things there are more things to fix instead of just a consensus on what actually needs to be done.
[23:20] <mrooney> But...I'll take a look at a manpage!
[23:20] <ScottK> mrooney: I can understand the frustration.
[23:20] <ScottK> mrooney: Although some of the comments can be, um, excessively detail oriented, I think in general it helps get better packages.
[23:21] <mrooney> ScottK: I am sure it isn't so bad after the first time. There are just SO many things to learn at first about packaging.
[23:21] <ScottK> Yep.
[23:21] <mrooney> Watching people like kirkland throw together packages in a few minutes gives me hope :)
[23:22] <ScottK> Hobbsee: Although I find PPAs useful for some thing (ubuntu-clamav PPA is one), I think in general they are a negative.
[23:22] <ScottK> I can do a package for a new Python module in about an hour.
[23:22] <ScottK> But I've done quite a few.
[23:23] <rockstar> ScottK, is that with or without setup.py already in there?
[23:23] <ScottK> With.
[23:23] <ScottK> Without takes longer.
[23:23] <ScottK> How much longer varies by the complexity.
[23:27] <mrooney> Is there any sweet manpage maker application? I thought I heard of one a bit ago.
[23:27] <ScottK> There are a number of them.
[23:27] <ScottK> Depends on what you like for an input format.
[23:28] <mrooney> ScottK: hmm, manual? haha I don't know what sort of inputs would be available
[23:29] <ScottK> docbook2man and pod2man are two I've used.
[23:29] <ScottK> Mostly I grab a man page and edit the nroff.
[23:29] <mrooney> there is a python option parser, I wonder if you can use that and then create a manpage from it
[23:30] <Laney> there's help2man, but I don't know how well that works
[23:36] <mrooney> I think I'll just try the template for now :)
[23:36] <Laney> see what help2man <binary> does, maybe it'll work
[23:41] <mrooney> debuild warns that it is making rules executable every time, should I just chmod a+x it myself in VC?