[12:29] <AndyP> ScottK: want me to subscribe this bug to u-u-s?
[12:30] <AndyP> or vice versa
[12:30] <ScottK> Did you fix it?
[12:30] <AndyP> yes
[12:30] <ScottK> OK.  Why is it linked to a Debian bug?
[12:31] <AndyP> it started out as a ftbfs bug so i could track its progress while i was figuring it out myself
[12:31] <ScottK> I see.
[12:31] <ScottK> OK.
[12:31] <ScottK> Well it's acked to the archive, so no need for UUS.
[12:31] <ScottK> Thanks.
[12:31] <AndyP> no, thank _you_ :)
[12:56] <ScottK> What is the canonical tool for editing docbook files and getting valid XML back out of the editor?
[01:00] <RainCT> good night
[01:12] <ryanakca> can a core dev please review http://groupware.kubuntu.co.uk/openssl_0.9.8e-5ubuntu2.debdiff ?
[01:13] <ScottK> ryanakca: #ubuntu-devel might be better for that...
[01:15] <ScottK> ryanakca: Why do you have changes outside the debian dir in that diff?
[01:29] <Jazzva> Should gnome-panel applet provide a menu and a desktop file :/?
[01:34] <persia> Jazzva: Depends on the applet.  Generally not: usually these are added with "Add to Panel", rather than being launched directly.  They should register in the panel, and remain until removed.
[01:35] <Jazzva> persia: Thanks... Any link where I can find a bit more about applets and where they install?
[01:36] <persia> Jazzva: I don't know of a link, but the deskbar-applet might be a reasonable example.
[01:36] <Jazzva> Ok, thanks... I'll take a look
[01:37] <ScottK> High there persia.
[01:37] <ScottK> Hi even
[01:38] <persia> ScottK: Hello.
[01:40] <ryanakca> ScottK: because I included a patch.
[01:40] <ryanakca> ScottK: gramatical errors in s_client.c
[01:41] <ScottK> ryanakca: I mean outside the patch.
[01:41] <ryanakca> Ah, add quilt to control, update changelog, and add the quilt 'include' line to rules
[01:42] <ryanakca> umm. wait.
[01:42] <ryanakca> ... why did it change the Makefile...
[01:42] <ryanakca> -PLATFORM=debian-amd64
[01:42] <ryanakca> +PLATFORM=debian-i386
[01:46] <ryanakca> ScottK: It has to do with debuild... http://pastebin.ca/644917 .
[01:54] <ScottK> Generally, I would just edit that stuff out of the debdiff.
[01:54] <persia> filterdiff and editdiff are handy tools for that.
[02:13] <geser> persia: ardour should finally build now on Ubuntu
[02:13] <persia> geser: Cool.  Thanks for chasing that.  I've been a bit distracted the past few weeks :)
[02:21] <jrib> should mozilla-mplayer conflict totem-mozilla?  Because there's not *easy* way to choose a default player for firefox to use that I know of
[02:25] <persia> jrib: Probably not.  Conflicts: is more important when there is a shared file, or a shared port that would make it unreasonable to install both.  In this case, it's just a matter of a missing preference interface.
[02:25] <jrib> yeah, I agree a preference interface is a better solution
[02:41] <ryanakca> persia: thanks
[02:51] <ryanakca> How do you apply/test debdiffs?
[02:56] <persia> ryanakca: patch -p1 < ../foo.debdiff
[02:59] <ryanakca> persia: ah, thanks :)
[03:19] <jmg> who was it here that was working on lirc support for umc?
[03:37] <ScottK> Any suggestions on docbook editors?
[03:41] <Burgundavia> ScottK: gedit, emacs, vi
[03:41] <Burgundavia> there not good ones, trust me
[03:42] <Burgundavia> there are no, rather
[03:42] <ScottK> OK.
[03:42] <ScottK> Urgh.
[03:42] <ScottK> How about docbook validation tools?
[03:42] <Burgundavia> for that, you need ot talk to mdke`
[03:42] <ScottK> OK.
[03:43] <ScottK> I've got a package with the man pages in docbook and they are failing on the conversion and I can't figure why.
[03:43] <ScottK> Ugh.
[03:43] <ScottK> Thanks though. 
[03:43] <ScottK> Even bad news is better than not knowing.
[03:43] <Jazzva> ScottK: Dunno if this helps, but I found this: You will need other packages in order to edit (psgml), validate (opensp, libxml2) or format (docbook-xsl, docbook-dsssl) DocBook documents.
[03:44] <Jazzva> with aptitude show docbook-xml
[03:49] <ScottK> Jazzva: Thanks.  I'll look into it.
[03:49] <Jazzva> ScottK: No prob...
[05:56] <RAOF> ScottK: When you say "failing on conversion", do you mean that docbook2x is segfaulting when you try to build?
[05:56] <ScottK> No I mean the docbook file is failing validation and the build fails.
[05:57] <RAOF> Oh.  Not the strange problem I had, then.
[05:57] <ScottK> The thing is, even the unmodified file fails.
[05:57] <ScottK> I just installed the package, grabbed the nroff version, edited and installed that.
[05:59] <ScottK> It's a sad situation when I can honestly say dealing with nroff was easier.
[06:02] <nixternal> ScottK: what docbook file? remember, i am a docbook junky
[06:02] <ScottK> I did not know that.
[06:02] <ScottK> It's the man pages for klamav
[06:02] <nixternal> hehe, I only write all of the Kubuntu docs and a lot of the KDE 4 docs, plus KHelpCenter love
[06:03] <ScottK> I knew you did the docs, but I didn't know you used docbook.
[06:03] <nixternal> xsltproc, docbook-xsl, docbook-xml?
[06:04] <nixternal> actually, failing validation is something different
[06:04] <ScottK> Any chance you'd have time to apt-get source klamav and run docbook2x-man klamav.1.docbook?
[06:04] <nixternal> is there a link so I can look at the docs and provide a fix for you?
[06:04] <nixternal> heh
[06:04] <ScottK> If you don't want to download the source, I can pastebin the file for you.
[06:04] <nixternal> you already said what I should do
[06:04] <ScottK> It's short.
[06:04] <nixternal> I will get the source, so I can validate it with my xml validator
[06:05] <nixternal> i.e. kate and friends :)
[06:05] <ScottK> Cool.
[06:05] <nixternal> 0.41-0ubuntu4 is the version?
[06:05] <ScottK> Yes
[06:06] <ScottK> I'm packaging 0.41.1-0ubuntu1 right now.
[06:06] <nixternal> doc/en/index.docbook your issue?
[06:06] <nixternal> hrmm, if it isn't validating and causing the build to crash, then how did 0.41-0ubuntu4 build? did you cheat it?
[06:06] <ScottK> This is the first time I've touched a docbook file in my life.  I can spell XML, but only barely.
[06:06] <nixternal> haha
[06:06] <ScottK> I didn't do it.
[06:07] <ScottK> It looks like the man pages haven't been touched in two years.
[06:07] <ScottK> I assume they validated two years ago and something changed in the toolset.
[06:07] <nixternal> well the docbook files in the version I have are fine
[06:08] <nixternal> paste the validation error if you can
[06:08] <ScottK> Sure.
[06:08] <nixternal> it is failing locally and not on the build server is it?
[06:09] <ScottK> Yes.
[06:09] <ScottK> I haven't uploaded yet.
[06:09] <nixternal> k
[06:10] <nixternal> ahh, I am willing to bet it is <refnamediv>
[06:11] <ScottK> http://paste.ubuntu-nl.org/32448/
[06:11] <nixternal> grr Tonio_ :)
[06:12] <nixternal> ok, there has got to be something different in your docbook then there is in mine
[06:12] <ScottK> Hmm
[06:12] <nixternal> hrmm
[06:12] <nixternal> interesting...I can build the version I have just fine
[06:13] <nixternal> just copy klamav.1.docbook to pastebin
[06:14] <ScottK> Well something is up because I got a clean one from the 41 source and it didn't error.
[06:15] <nixternal> good deal
[06:15] <ScottK> I'm getting the modified one for you now.
[06:16] <ScottK> http://paste.ubuntu-nl.org/32450/
[06:17] <ScottK> nixternal: ^^
[06:17] <nixternal> got it
[06:17] <nixternal> OK..it does it here too
[06:17] <ScottK> And I think I see what it is now.
[06:18] <ScottK> I am a muppet

[06:18] <nixternal> on line 66, do </para>
[06:19] <ScottK> That's the muppet line.
[06:19] <nixternal> yup
[06:19] <nixternal> and then it works like a charm
[06:19] <ScottK> I stared and stared at that and didn't see it.
[06:19] <ScottK> Looked at it in the pastebin and BAM it lept out at me.
[06:19] <nixternal> hehe, validation errors are erroneous anyways
[06:20] <ScottK> One related question...
[06:20] <ScottK> In pbuilder it whines it can't get the dtd.
[06:20] <ScottK> Is that going to be a problem on the buildds?
[06:21] <nixternal> nope, it is going to do it there as well
[06:21] <nixternal> buildds do not have internet connections, so they can't grab DTD info
[06:21] <nixternal> they still build though
[06:21] <ScottK> OK.
[06:22] <ScottK> http://paste.ubuntu-nl.org/32451/ is the pbuilder error
[06:23] <nixternal> that is weird
[06:23] <nixternal> I don't get those with my pbuilder
[06:23] <nixternal> but you will see those in the buildds
[06:24] <ScottK> I checked and the page with the dtd is in fact there.
[06:24] <nixternal> hehe, it better be there, otherwise the doc server would die tonight
[06:24] <ScottK> Just checking all the options.
[06:24] <ScottK> So I don't need to sweat that?
[06:25] <nixternal> not in buildds you don't...pbuilder I am a little weary with though
[06:26] <ScottK> Well I just lit off the new klamav version on my laptop and it didn't catch on fire.  That's something.
[06:26] <nixternal> lol
[09:53] <jussi01> morning everyone
[09:54] <RAOF> Evening jussi01
[09:54] <RAOF> Want to check out a nearly complete xgl package? :)
[09:56] <jussi01> RAOF: hmmm, I dont use xgl... but ill have a look...
[09:57] <RAOF> jussi01: 
[09:57] <RAOF> jussi01: code.launchpad.net/~raof/xserver-xgl/ubuntu-raof
[10:01] <jussi01> cant grab it yet as imupdating and no bzr on my system, in a little while...
[10:06] <jussi01> RAOF: grabbing it now...
[10:17] <jussi01> RAOF: i have it now...
[12:01] <RainCT> good morning
[12:01] <norsetto> morning
[12:48] <amachu_> hi guys
[12:49] <amachu_> am amachu from ubuntu tamil team
[12:49] <amachu_> interested to contribute to the KDE team of MOTU
[12:50] <elkbuntu> hmmm.. no mjg in here to worship
[12:54] <amachu_> elkbuntu: means?
[12:54] <elkbuntu> amachu_, http://mjg59.livejournal.com/77440.html
[12:56] <amachu_> can he help me on this?
[12:57] <geser> amachu_: the KDE people hang around in #kubuntu-devel
[12:57] <amachu_> okie...
[12:57] <elkbuntu> amachu_, no, but we now have someone with authority publicly saying automatix is capable of blowing up the world, listing over 2 dozen reasons why it's bad
[12:57] <amachu_> :-)
[12:58] <amachu_> i am looking for a motu mentor 
[12:58] <amachu_> :-)
[12:58] <amachu_> in kubuntu basically
[01:08] <Nightrose> amachu_: you should come to #kubuntu-devel and ask there - but on weekends it is very quit there - maybe you can try during the week
[01:09] <amachu_> Nightrose: okie 
[01:09] <amachu_> thank you
[01:10] <coNP> Some MOTU please review magyarispell (Hungarian spell checker) on REVU http://revu.tauware.de/details.py?upid=6330
[01:35] <StevenK> persia!
[01:36] <persia> StevenK!
[01:38] <Fujitsu> Hi Hobbsee.
[01:40] <Hobbsee> heya Fujitsu, how's it going?
[01:40] <StevenK> Fujitsu: Yes, that's a good read.
[01:41] <Hobbsee> wow, nice review of automatix!
[01:41] <StevenK> "You people suck, here is why you do"
[01:41] <elkbuntu> yep
[01:42] <StevenK> In other news, gtk2hs sucks, too.
[01:42] <Fujitsu> Hobbsee: Not altogether bad! Better since reading mjg59's post, though.
[01:44] <Hobbsee> hehe, yeah
[01:56] <RainCT> Can someone merge ~rainct/ubuntu-dev-tools/dev into ~ubuntu-dev/ubuntu-dev-tools/trunk please?
[01:58] <TheMuso> RainCT: What changes have you made?
[01:59] <TheMuso> And have you made sure you have the latest trunk changes?
[02:00] <Kmos> http://revu.tauware.de/details.py?upid=6327 -> can someone check this one ?
[02:03] <Kmos> it fix the builds at ubuntu
[02:03] <Kmos> it's not building the package
[02:05] <Kmos> http://launchpadlibrarian.net/7567284/buildlog_ubuntu-gutsy-i386.stfl_0.8-2_FAILEDTOBUILD.txt.gz
[02:07] <RainCT> TheMuso: yes it's the latest (downloaded yesterday and merged this morning with your commit)
[02:07] <TheMuso> Ok.
[02:07] <TheMuso> RainCT: Ok, I'll merge now.
[02:08] <persia> Kmos: I'm now a little confused.  What do you want examined?  Why 0.8-2 doesn't build?  Whether 0.15-1ubuntu1 should be uploaded?
[02:08] <RainCT> ok, thanks
[02:10] <Kmos> persia: 0.8-2 and others vesions.. like the newest one on debian can't be synced, because debian/rules is bugged
[02:11] <Kmos> so i've prepared the package to got it uploaded
[02:11] <persia> Kmos: Ah.  It FTBFS for me :)
[02:11] <Kmos> it doesn't build on i386, amd64, sparc, nothing on ubuntu
[02:11] <Kmos> i've also sent a patch to the maintainer..
[02:11] <Kmos> to fix it in next versions
[02:11] <persia> Kmos: Your new package FTBFS for me as well.
[02:12] <RainCT> TheMuso: Changes are: Finish the README, unify all script headers, improve what-patch and check-symbols, rewrite suspicious-source
[02:12] <Kmos> changelog: 
[02:12] <Kmos>   * Fixed debian/rules with CFLAGS not placed correctly. Thanks to Adam
[02:12] <Kmos>     Conrad. Now it builds fine in all archs.
[02:12] <Kmos> :)
[02:12] <TheMuso> RainCT: Yeah saw that, changes are going up now.
[02:12] <persia> Kmos: That's what it says in the changelog.  Still, FTBFS here.
[02:12] <Kmos> persia :-)
[02:13] <coNP> MOTUs: please review magyarispell (Hungarian spell checker) on REVU http://revu.tauware.de/details.py?upid=6330
[02:13] <Kmos> persia: you can approve it ?
[02:13] <Kmos> !ftbfs
[02:13] <ubotu> Sorry, I don't know anything about ftbfs - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[02:13] <persia> coNP: You've outstanding lintian/linda errors for that upload.  You'd do best to address those first :)
[02:14] <Kmos> it should appear
[02:14] <persia> Kmos: Yes, but I won't because it cannot be built locally for me.
[02:14] <Kmos> http://en.wikipedia.org/wiki/FTBFS
[02:14] <coNP> persia: REVU lintian errors, none @ my home
[02:14] <coNP> persia: but I try to fix them
[02:14] <Kmos> persia: why not ?
[02:14] <coNP> However it is quite bad that you run lintian, correct errors, upload package... and get errors again :(
[02:14] <Kmos> persia: not with a machine with pbuilder? =)
[02:15] <persia> Kmos: True, but the buildds and I run sbuild.
[02:15] <persia> coNP: I'll take a deeper look then.
[02:15] <Kmos> persia: it builds fine with pbuilder
[02:15] <coNP> persia: okay, sorry. But in general we should consider using the same version of lintian on REVU.
[02:16] <persia> Kmos: Yes, but it doesn't build here, which is as close as I've been able to construct to the actual buildds, so I have no confidence that it will build there.
[02:16] <Kmos> persia: what's the error?
[02:16] <persia> Kmos: http://revu.tauware.de/details.py?upid=6327
[02:17] <Kmos> ok
[02:18] <Kmos> persia: what command do you use to build it?
[02:18] <persia> Kmos: sbuild -A -d gutsy stfl_0.15-1ubuntu1.dsc
[02:18] <Kmos> thx
[02:20] <Kmos> persia: mailto not set ?
[02:21] <persia> Kmos: Could I please have a little more context for that?
[02:21] <Kmos> kmos@bash:~/packages/stfl$ sbuild -A -d gutsy stfl_0.15-1ubuntu1.dsc
[02:21] <Kmos> mailto not set
[02:23] <persia> Kmos: Ah.  You probably need to configure it :)  I recommend https://help.ubuntu.com/community/SbuildLVMHowto
[02:23] <Kmos> thanks
[02:24] <coNP> persia: fixed. Only NMU and unknown distro is what lintian complains about now.
[02:24] <persia> coNP: Excellent.  I'll take a fresh look now.  Thanks.
[02:24] <coNP> Thank *you* :)
[02:28] <Kmos> persia: can you tell someone else to try it.. i'll not try with sbuild, too much work when I've pbuilder that worked always fine and after in buildds
[02:29] <persia> Kmos: I'm not anyone else's manager.  You could ask someone else.
[02:32] <Kmos> coNP: can you test it ? =)
[02:32] <Kmos> http://revu.tauware.de/details.py?upid=6327
[02:32] <persia> coNP: Looks OK to me, with one additional minor point.  On the other hand, you'll need core-dev sponsorship for upload.
[02:33] <coNP> persia: Hmm. You are right. I have overlooked this. :)
[02:33] <coNP> Thanks for reviewing, I try to fix the minor point and look for someone at -devel.
[02:34] <persia> coNP: Good luck.  Also, the build output is entirely in magyar nyelv.  If that's a locale adjustment, it might do well with a patch.  If it's just upstream being lazy, no need to change anything.
[02:35] <coNP> It is upstream. It is Hungarian spell checker, I think it is not a problem.
[02:35] <coNP> "Hungarian".l18n(hu_HU) = "magyar nyelv"
[02:36] <Kmos> oh god :)
[02:36] <persia> coNP: Not really a problem then :)  I just feared that there might have been a local locale adjustment in the code somewhere.
[02:41] <coNP> Kmos: pbuilder is fine, sbuild cannot be installed for now, Hash Sum mismatch. Sorry
[02:41] <Kmos> persia: i think it's really a problem in sbuild
[02:41] <Kmos> coNP: very thank you
[02:41] <persia> Kmos: Perhaps, but the buildds run sbuild, so you may encounter it there as well.
[02:41] <TheMuso> coNP: Whats the package
[02:41] <coNP> Kmos: you should check with sbuild, once you can install it
[02:42] <coNP> TheMuso: which package? :)
[02:42] <TheMuso> I have a sbuild setup.
[02:42] <Kmos> TheMuso: http://revu.tauware.de/details.py?upid=6327
[02:42] <coNP> Oh, it is Kmos's problem. ^^
[02:42] <TheMuso> oh ok
[02:42] <coNP> TheMuso: persia has already checked, I don't think it is worth running it if you don't plan to try to fix it as well.
[02:43] <TheMuso> ok
[02:44] <Kmos> :(
[02:44] <persia> Actually, running it on !amd64 might be a good test.  The specific compiler error I encountered might be architecture-related.
[02:45] <TheMuso> Well I have i386 her.
[02:45] <TheMuso> here
[02:45] <Kmos> me too
[02:45] <coNP> Then it might be not pbuilder/sbuilder but i386 / x64 related.
[02:45] <TheMuso> I doubt very much that it is a pbuilder/sbuild issue.
[02:48] <Kmos> persia: you've amd64 ?
[02:49] <persia> Kmos: Yes.
[02:55] <Kmos> https://launchpad.net/~serpentine-dev/ -> python coders, this project needs your help.
[02:55] <Kmos> so how can I fix it, if I don't have amd64?
[02:58] <coNP> As usual: buy a new computer :)
[02:58] <Kmos> hehe
[02:58] <Kmos> i've a laptop core2duo but with i386 also
[02:58] <Kmos> with gutsy
[02:58] <persia> Kmos: You should be able to fix it with -fPIC.
[02:59] <Kmos> persia: it has -fPIC on the start of debian/rules
[02:59] <Kmos> that the problem also at i386
[02:59] <Kmos> and it's fixed now, with help from infinity
[02:59] <Kmos> CFLAGS += -fPIC
[03:00] <persia> Kmos: The FTBFS I am reporting is the lack of -fPIC.  The problem with 0.8-2 is that the syntax of the makefile is not correct.
[03:00] <Kmos> http://revu.tauware.de/revu1-incoming/stfl-0708031345/stfl-0.15/debian/rules
[03:00] <coNP> Can some core-dev review / sponsor my magyarispell REVU upload (http://revu.tauware.de/details.py?upid=6332), please?
[03:02] <persia> Kmos: I see that.  Perhaps it's not getting exported cleanly?
[03:07] <tsmithe> hi - could someone upload ubuntustudio-sounds from revu again, this time fixing a licensing quibble (as the diff at http://revu.tauware.de/diff.py?upid1=5990&upid2=6292 will show) - the revu page is at http://revu.tauware.de/details.py?upid=6292
[03:08] <TheMuso> tsmithe: Are you sure this is ok to go in this time?
[03:09] <tsmithe> thanks
[03:10] <tsmithe> TheMuso, hehe yes. or at least it fixes the last issue pitti had with it
[03:10] <tsmithe> he didn't point out any others
[03:10] <TheMuso> Ok.
[03:10] <TheMuso> I'll upload again.
[03:11] <tsmithe> thanks
[03:13] <_MMA_> tsmithe: So you talked to pitti and found out what he meant by "stanza"?
[03:14] <tsmithe> well, it was in the rejection e-mail from him; it just took some time for it to come down the rather small hotel pipeline
[03:14] <_MMA_> k
[03:21] <Kmos> anyone here knows how to run a pbuilder amd64 on my i386 arch machine ?
[03:22] <Fujitsu> Kmos: -ENOTSUPPORTED
[03:23] <Fujitsu> i386 can't run amd64 code.
[03:23] <persia> Fujitsu: amd64 hardware, i386 distro.  Not even in a chroot?
[03:23] <StevenK> Surely it depends if the processor can do long mode.
[03:24] <Fujitsu> i386 machine...
[03:24] <StevenK> Kmos: Try adding --debootstrapopts --arch amd64 . I run on amd64 natively, so it's definetly a possibility that the 32 bit kernel running won't be able to deal with 64 bit pointers being thrown around.
[03:25] <Fujitsu> Um, yeah, i386 kernel will *not* like that.
[03:25] <StevenK> Your processor might not want to enable long mode from protected, either.
[03:26] <Kmos> hmm
[03:27] <Kmos> and i've a core2duo (64-bit) laptop with ubuntu gutsy i386 installed
[03:27] <Kmos> there i can try the --debootstrapopts --arch amd64
[03:27] <Kmos> it should work
[03:27] <StevenK> It probbably won't, but try it anyway.
[03:28] <Kmos> so i'll have a big problem
[03:28] <Kmos> http://revu.tauware.de/details.py?upid=6327
[03:28] <Kmos> i need to fix this.. persia can't run it on amd64
[03:28] <Kmos> i386 is fixed
[03:29] <StevenK> Install a small amd64 install?
[03:29] <persia> Kmos: If nothing else, you could try a dual-boot, if you can get 5GB or so free on a disk.
[03:29] <Fujitsu> 5GB!?
[03:30] <Kmos> persia: i can even kill my gutsy and download a amd64 version =)
[03:30] <Kmos> and upgrade this feisty to gutsy :D
[03:30] <persia> Fujitsu: Sure.  I've yet to find a package I can't build in a 5GB environment, with only base and build-essential installed.
[03:30] <Kmos> so i'll have two gutsy's with i386 and amd64 for testing 
[03:30] <Kmos> =)
[03:30] <Fujitsu> Or even just install an amd64 kernel and modules?
[03:30] <Fujitsu> persia: 5GB is rather overkill.
[03:31] <persia> Fujitsu: Depends on the package, I guess.  Perhaps I'll try a smaller slice size.  What do you use?
[03:31] <coNP> I should only use the "requestsync" script if I am a MOTU, right?
[03:31] <Hobbsee> coNP: you can use it with -s
[03:31] <persia> coNP: If you're running the gutsy version, there's a -s option for non-MOTUs.
[03:31] <Fujitsu> If I were in Kmos' position I would probably give it 2-3GiB... 5GiB for a full desktop environment, perhaps.
[03:32] <coNP> Thanks Hobbsee :)
[03:33] <TheMuso> tsmithe: ubuntustudio-sounds uploaded... hopefully for the last time.
[03:33] <tsmithe> yes - thanks :)
[03:33] <tsmithe> (i hope so too)
[03:34] <persia> Fujitsu: Hmm..  5GB does a full desktop, but I just assumed I might need that for some of the builds.  I'll try something smaller: perhaps I can squeeze another release in.  Thanks.
[03:35] <Fujitsu> Some huge things might need more, but I've not run out of space.
[03:36] <TheMuso> With another 5GB spare at least on the LVM partition.
[03:45] <persia> TheMuso: 6333 FTBFS for me.  Are you sure about debian/install?
[03:45] <TheMuso> persia: I'll have a look.
[03:45] <TheMuso> oh of course.
[03:48] <persia> TheMuso: Also, it looks like there's an extra i in the postrm
[03:48] <TheMuso> ugh just uploaded to revu again. Let me check.
[03:48] <geser> persia, TheMuso: ardour is now in binary NEW
[03:49] <TheMuso> geser: I saw.
[03:49] <TheMuso> Thanks heaps.
[03:49] <persia> geser: Thanks a lot.  With that and ubuntustudio-default-settings, I think we have all the pieces.
[03:50] <TheMuso> persia: Going up to revu again...
[03:50] <TheMuso> Ok should show up soon.
[03:56] <persia> TheMuso: lintian reports gconftool-used-in-maintainer-script.
[03:56] <TheMuso> persia: Well its a schema file. I just copied what is done in other apckages such as gnome-panel.
[03:57] <TheMuso> I'll need to look further into that then...
[03:59] <persia> TheMuso: It's only informational.  lintian suggests gconf-schemas or update-gconf-defaults instead.
[03:59] <TheMuso> Right
[04:00] <TheMuso> persia: gnome-panel-data does the same thing, so I am not concerned.
[04:01] <persia> TheMuso: OK.  I'll let it go for now, but I still don't think it's good (and don't like it for gnome-panel-data either).
[04:01] <persia> TheMuso: 6335 advocated.  Have fun.
[04:01] <TheMuso> persia: Well take that up with seb128
[04:02] <persia> TheMuso: Yeah, I know.  Still :)
[04:02] <TheMuso> persia: Thanks
[04:49] <Hobbsee> yay, sanity prevails!
[05:00] <coNP> What is the standard way to ask for a main sponsor? 
[05:00] <coNP> (I cannot subscribe u-m-s for REVU)
[05:09] <vil> -join 3cairo
[05:09] <vil> oops
[05:32] <ScottK> Good $TIME_OF_DAY all.
[06:06] <siretart> coNP: there is a launchpad group for that
[06:22] <mohammad> Hello, how should a beta version of a package be named? would someone please guide me?
[06:25] <ScottK> Hello mohammad.
[06:26] <ScottK> It looks like you are getting close with Zekr.
[06:26] <ScottK> What's the package name/version going to be one it's released?
[06:27] <mohammad> it is not for the Ubuntu repositories. anyway: zekr/0.6.0 beta2 
[06:31] <mohammad> ScottK ^
[06:31] <ScottK> For a Debian/Ubuntu package I would number that 0.6.0~0beta2 because ~ comes before - in the Debian version numbering order.
[06:32] <ScottK> The the release would be 0.6.0-0ubuntu1 for Ubuntu or 0.6.0-1 for Debian.
[06:33] <ScottK> mohammad: On another note, did you understand the comments on the copyright issues with the zekr-extras package?
[06:36] <mohammad> ScottK: I will split the package as emmet.hikory asked with another name. we are still working on the copyright issues.
[06:38] <mohammad> ScottK: and how shoud I name the src directory? zekr-0.6.0 or zekr-0.6.0+beta2 ?
[06:40] <mohammad> or  zekr-0.6.0~beta2
[06:41] <ScottK> mohammad: Do you want to be able to have people have multiple versions installed side by side or have a smooth upgrade path to the final release?
[06:43] <ScottK> Actually, nevermind.
[06:43] <ScottK> I'd do  zekr-0.6.0+beta2.
[06:45] <mohammad> ScottK: smooth upgrade path to the final release
[06:45] <ScottK> I thought it over, and you do want the package dir to be unique for each release (beta or not).
[06:45] <ScottK> Same thing with the tarball.
[06:46] <lamont> mohammad: zekr-0.6.0~beta2 unless the release is going to be 0.6.1
[06:47] <Nafallo> | uniq :-)
[06:47] <lamont> ~ comes before NULL
[06:47] <lamont> - separates parts
[06:47] <lamont> ScottK: ^^
[06:47] <ScottK> Hi there lamont.
[06:47] <ScottK> Didn't notice you hanging out here.
[06:48] <lamont> mohammad: and when you unpack the source with dpkg-source -x, it'll be zekr-${UPSTREAMVERS}
[06:48] <lamont> no matter what you called it in orig.tar.gz
[06:48] <lamont> ScottK: generally I don't
[06:48] <lamont> and then sometimes I do.
[06:48] <ScottK> Well there is where all the fun it.
[06:48] <lamont> most recent excuse for being here was dumping a list of bashism-in-rules packages on the channel...
[06:48] <ScottK> Packaging new crack whenever we feel like it.
[06:48] <lamont> and all the traffic is here too.. :-)
[06:49] <lamont> .... since march 26
[06:49] <ScottK> Well we could definitely use more help from experienced maintainers like you with reviewing new packages and helping people learn to help out.
[06:50] <lamont> I have been known to do that from time to time
[06:50] <ScottK> mohammad: I would listen to lamont.  He is very knowledgeable.
[06:50] <ScottK> Cool.
[06:51] <lamont> ScottK: so to beat a dead horse...  1.0~beta1 is less than 1.0 is less than 1.0-1
[06:51] <mohammad> thank you lamont and ScottK :)
[06:51] <lamont> OTOH, in about 3 minutes, I get to go put goopy stuff on a roof.
[06:51] <ScottK> Yeah.  How's the temperature outside?
[06:52] <lamont> 86.4
[06:52] <ScottK> But it's a dry heat.
[06:52] <lamont> it spreads much better the hotter it gets.
[06:52] <lamont> not that dry of heat...  not that wet either... maybe I'll sling weather and get the RH.  maybe I won't
[06:53] <ScottK> I'm currently trying to figure out by clamav-freshclam ignores the system clamav version if different version is installed for the user even it's run as Root.
[06:54] <ScottK> And it's the system freshclam that's running.
[06:54] <lamont> (it's very convenient that alpha < beta < rc...)
[06:55] <Nafallo> ...rc > final ;-)
[06:55] <lamont> Nafallo: not if you use ~alpha, ~beta, and ~rcN
[06:55] <Nafallo> :-)
[06:55] <lamont> and s/final//
[06:56] <Nafallo> I know
[06:56] <ScottK> lamont: How many times have you recompiled your kernel today?
[06:57] <lamont> ScottK: the uploaded source from last night finally started building about 9:30.  it's about done
[06:57] <lamont> given that it failed last time because the kernel build scriptage doesn't tolerate old kernel builds of the same upstream version in the parent directory, I think there's hope for it
[06:58] <ScottK> That being ~ an hour and a half ago where you are?
[06:58] <lamont> yeah
[06:58] <lamont> kernel build time is ~ 2 hours on hppa
[06:59] <ScottK> I think there have been 3 kernel updates now since I last rebooted my Gutsy system.   I think I'll do that and see how it goes.
[06:59] <lamont> and it's now to the point where it died last time....
[06:59] <lamont> it's mostly been lpia stuff
[07:13] <nixternal> ScottK: the kernel updates will destroy your system
[07:14] <ScottK> nixternal: Will it catch on fire?  I want to watch...
[07:14] <nixternal> sure
[07:14] <ScottK> lamont: If lpia stuff is breaking your hppa kernel build, that just sounds ... wrong.
[07:16] <nixternal> i am typing this from the new kde keyboard....who wants to do the MIR for it? ScottK it even does irssi tab complete and wikies ;)
[07:16] <nixternal> 12
[07:16] <lamont> ScottK: lpia and hppa stuff
[07:16] <ScottK> nixternal: Have you done an MIR before?
[07:16] <ScottK> lamont: Oh.
[07:16] <lamont> and it's not breaking my build
[07:16] <lamont> my build started out broken
[07:16] <nixternal> ScottK: yes
[07:17] <nixternal> I just upgraded kvkbd to 0.4..so now it is resizable, and has a num pad layer which is nice
[07:17] <ScottK> Maybe coNP wants to learn how to do a MIR?
[07:17] <nixternal> it could definitely use a better systray icon
[07:18] <nixternal> well, I am going to wait for his next update before I do the MIR, or mentor someone on doing one
[07:18] <nixternal> I want to get the macros in first before the MIR
[07:18] <ScottK> Get all the crack in while you can still upload it.
[08:03] <coNP> ScottK: what is a MIR?
[08:06] <coNP> nixternal: what is a MIR?
[08:07] <coNP> Mir (Russian:  peace) was a Soviet (and later Russian) orbital station.
[08:07] <coNP> I guess it is a main-inclusion-request.
[08:07] <nixternal> lol, yes, Main Inclusion Request :)
[08:07] <ScottK> Mail In Rebate
[08:09] <nixternal> haha
[08:09] <nixternal> that too I guess
[08:25] <AndyP> hm sam hocevar wants to make debian/copyright machine-interpretable
[08:26] <ScottK> Why?
[08:27] <AndyP> to spot incompatibilities easier, i think
[08:27] <AndyP> http://wiki.debian.org/Proposals/CopyrightFormat
[08:39] <coNP> Interesting.
[08:44] <sommer> ScottK: what's happenin
[08:44] <ScottK> Seems reasonable, but will require patience.
[08:45] <ScottK> sommer: Trying to figure out why clamav freshclam gets the local clamav version wrong if you have one installed for the system and one for the user.
[08:45] <ScottK> That and package Klamav 0.41.1.
[08:45] <sommer> I filed a bug #130405 with a debdiff for python-clamav using 0.91.1.
[08:45] <ubotu> Launchpad bug 130405 in dapper-backports "python-clamv backport for clamav-0.91.1" [Undecided,New]  https://launchpad.net/bugs/130405
[08:46] <ScottK> sommer: Maybe you'd like to help coNP out with getting some lighttpd security fixes packaged.
[08:46] <sommer> sure, I've used lighttpd a little.
[08:47] <ScottK> Perfect.
[08:47] <sommer> I did have a question about python-clamav.  The version in dapper uses a cl_scanbuff function that is no longer in libclamav.
[08:47] <sommer> they recommend using pyclamd instead.
[08:47] <ScottK> I saw that.
[08:47] <sommer> is there a package for pyclamd?
[08:47] <sommer> do we need to package it for dapper?
[08:48] <sommer> I guess I'm a little fuzzy on if that falls under "new" functionality.
[08:48] <ScottK> It doesn't exist in Ubuntu.
[08:48] <ScottK> Backporting new packages is no problem at all.
[08:48] <sommer> ah...I guess that answers that.
[08:49] <ScottK> There's no regression risk.
[08:49] <ScottK> Python packages are pretty easy, maybe you could find it and package it.
[08:49] <sommer> sure I'll take a crack at it.  
[08:50] <ScottK> Ping me for a review when it's ready.
[08:50] <sommer> should that be packaged for gutsy first?  since it's new.
[08:50] <ScottK> Yes.
[08:50] <ScottK> Once it's in Gutsy, a backport should be no problem, just be mindful of version dependencies in Dapper when you package it.
[08:51] <sommer> great...I'll need to read up on packing before attempting, but I should have something sometime this week.
[08:55] <nixternal> I kind of like that Copyright proposal
[08:58] <ScottK> I do too, but I think he underestimates the scope.
[08:59] <ScottK> It's only useful for standard licenses.  
[08:59] <ScottK> First step would be to add more licenses to the system.
[08:59] <ScottK> As a long term idea, I think it's a good one.
[09:02] <coNP> ScottK, sommer so you think you want to backport instead of a security release?
[09:08] <sommer> coNP: can you catch me up on what you're working on?
[09:10] <coNP> I was told if I wanted to do some security update.
[09:10] <coNP> I wanted but I am neither familiar with security updates nor with lighttpd
[09:11] <coNP> So I am in the starting phase, not really knowing what and how to do
[09:11] <ScottK> coNP: No, security update.
[09:11] <ScottK> Well sommer uses lighttpd, so maybe you can work together on it.
[09:11] <coNP> Yes. That would be cool.
[09:11] <coNP> I should have chosen a package I am familiar with. For my first security one.
[09:12] <nixternal> security updates can be fairly easy at times...how I go about doing it is cherry picking the svn repo of where the security fix is located...and then I find the code they added to fix the security issue, and then get to creating some patches
[09:12] <coNP> The problem is I'll only have time for this from tuesday on...
[09:13] <ScottK> nixternal: coNP already found the code, it's just a question of packaging it.
[09:13] <ScottK> https://wiki.ubuntu.com/SecurityUpdateProcedures
[09:13] <nixternal> ahhh
[09:13] <coNP> Oh, the packaging part is quite easy.
[09:13] <nixternal> hehe, the smaller the debdiff, the better
[09:13] <coNP> Then I must have mistunderstood some parts
[09:13] <ScottK> OK.  Let's review...
[09:13] <nixternal> otherwise keescook will hunt you down..and you don't want that :)
[09:13] <ScottK> Where are we on this coNP?
[09:14] <coNP> I tend to over-complicate things in my head.
[09:14] <coNP> I have some links from where I can get the patches.
[09:15] <sommer> if you package it up I'd be glad test it.
[09:16] <ScottK> sommer: Which releases are you running?
[09:17] <sommer> I've got access to machines running dapper, feisty, and gutsy tribe2.
[09:18] <sommer> I mean tribe3.
[09:19] <coNP> Wow.
[09:19] <ScottK> sommer: First thing I think we should do is get the SRU for lighttpd in Dapper out.
[09:19] <coNP> So I start with dapper.
[09:20] <ScottK> sommer: Would you please have a look at https://bugs.launchpad.net/ubuntu/+source/lighttpd/+bug/68401, install the dapper-proposed version and then say in the bug if it works?
[09:20] <ubotu> Launchpad bug 68401 in lighttpd "Cannot remove the lighttpd pkg from Edgy Eft" [Medium,Fix committed]  
[09:20] <ScottK> If we can get that out, then that's one less version to patch.
[09:20] <sommer> sure
[09:20] <ScottK> coNP: I'd suggest start with Feisty while we get the Dapper SRU published.
[09:21] <coNP> Okay. I think once we discussed that
[09:25] <coNP> Some core-dev please-please mentor me magyarispell Hungarian spell checker (http://revu.tauware.de/details.py?upid=6332)
[09:26] <ScottK> coNP: Is that a new package or an update to a package?
[09:26] <coNP> Update magyarispell
[09:27] <coNP> Persia has already reviewed it, but it is in main.
[09:27] <ScottK> Right.  I'd suggest ask in #ubuntu-devel.  I don't see any core-devs active here right now.
[09:27] <ScottK> !weekend of course though.
[09:28] <ScottK> I don't know what the Main process is.
[09:28] <ScottK> I'd just ask on #ubuntu-devel on Monday.
[09:29] <coNP> Siretart said LP has a group for that but I have to file a bug to assign a REVU upload.
[09:29] <coNP> So I'll better wait. :)
[09:33] <sommer> just tried the proposed lighttpd package on dapper and it worked fine for me.  
[09:38] <coNP> Sorry I have to go now. If I can find the links during the weekend I might try to finish.
[09:38] <coNP> If not, next week.
[09:38] <coNP> Bye everyone
[09:42] <DarkSun88> Hi all
[09:42] <ScottK> sommer: Thanks.
[09:44] <sommer> no problem
[09:45] <ScottK> I just marked it MOTU verification done, so now the archive admins will publish it.
[10:05] <blueyed> I want to update a package (kleansweep), but the upstream source is tar.bz2 and .orig.tar.bz2 does not seem to get recognized by debuild. Should I repack the original source?
[10:05] <fdoving> bunzip2 and gzip -9 the .tar
[10:13] <norsetto> blueyed: in case you need a reference: https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball
[10:18] <blueyed> Thanks, fdoving and norsetto: I've now used bunzip2 kleansweep-0.2.9.orig.tar.bz2 -c | gzip -9 -c > kleansweep-0.2.9.orig.tar.gz - ok?
[10:19] <blueyed> The wiki says there should be a get-orig-source entry in debian/rules, which is not there yet. Should I add it?
[10:21] <blueyed> However, the upstream download link is: http://www.kde-apps.org/content/download.php?content=28631&id=1 - therefor already a watch file would not work.
[10:21] <ScottK> blueyed: It's not required.
[10:21] <norsetto> blueyed: one or the other, not both
[10:24] <blueyed> I can't do any of it easily, can I? Because the filename for get-orig-source would change and I had to parse it from the wget response. And "watch" does not work, because it seems to need a page where it can search for links to releases.
[10:34] <norsetto> blueyed: if you look at INSTALL you will see that upstream always uses bz2, and tonio changed it to gz (ok, it could also have mentioned it in the changelog.....)
[10:39] <blueyed> norsetto: I cannot find a reference to "we always use bz2" in INSTALL. However, I've now converted it also to gz and it works.
[10:41] <Daviey> Hey.. anybody seen imbrandon for a while?
[10:41] <ScottK> Only briefly.
[10:44] <norsetto> blueyed: in INSTALL upstream gives instructions on how to unpack the tarball.....
[10:45] <ScottK> sommer: The Dapper lighttpd update has been published in dapper-updates by the archive.  Once it builds, you should get it as .3.
[10:45] <ScottK> Thanks for helpingout.
[10:46] <blueyed> norsetto: "tar xjvf admin/scons-mini.tar.bz2"? anyway. No problem anymore :)
[10:48] <sommer> cool...anytime.
[10:54] <rainct> is there any manpage editor beside manedit and gmanedit?
[10:55] <ScottK> sommer:  That means for the Security update we only have 3 fixes to do, not 4.
[10:55] <ScottK> rainct: I usually use KATE.
[10:56] <rainct> ScottK: but kate is just a normal text editor, or?
[10:56] <ScottK> But then I'm odd in that I prefer raw nroff to having to learn a new tool.
[10:57] <rainct> well I guess the best is just write it as docbook
[10:57] <norsetto> ScottK: you just show your age.....
[10:58] <ScottK> Yeah, well I am ancient and all that.
[11:01] <norsetto> blueyed: bug 130421 -> you should upload the package to REVU not attach a debdiff, its a new upstream version 
[11:01] <ubotu> Launchpad bug 130421 in kleansweep "New upstream version 0.2.9" [Undecided,New]  https://launchpad.net/bugs/130421
[11:04] <blueyed> norsetto: I've though revu is for new packages, not new versions?!
[11:06] <norsetto> blueyed: since its not a merge/sync, it is a new package to all effect (just look at the size of that debdiff)
[11:07] <norsetto> blueyed: look at it this way: there is a new orig.tar.gz
[11:07] <ScottK> blueyed: If it's a new Debian revision, use a debdiff.
[11:07] <ScottK> If it's a new upstream with a new tarball, then REVU.
[11:08] <blueyed> This package is not in debian, it's ubuntu only. Ok, I'll then add it to REVU.
[11:08] <ScottK> And then provide a URL in the bug.
[11:09] <blueyed> Ok. Someone should now re-sync the REVU uploaders keyring :)
[11:15] <ScottK> Don't see any admins around, maybe they are reading the channel quietly.
[11:19] <blueyed> Now dpkg-source fails: http://pastebin.com/d20c6494d - any idea what's wrong?
[11:20] <blueyed> Seems to be related to that I've build the package from there and "clean" is not really cleaning.
[11:22] <blueyed> yes. I've added rm -f po/*.gmo to the clean target.
[11:28] <rainct> hm.. I'm thinking since some days that perhaps I could try to write a book (well, rather a document, don't think it would get that extensive) in Catalan about getting involved with ubuntu (introduction to Launchpad, different ways to contribute to ubuntu, some words about the Catalan LoCo and then focus on MOTU, explaining how it works, the basics of packaging, and some examples and explaining particular tasks and a how to get further into it, and
[11:30] <ScottK> rainct: I understand that one of the existing English Ubuntu books is available under a Free license, maybe you could start with translating some of that.
[11:31] <desertc> rainct: what a nice idea.  there are books on so many other hobbies, why shouldn't contributing to a linux distros get their a book.  maybe just an extensive webpage
[11:31] <ScottK> blueyed: This is also why you should always build your binaries in a pbuilder/sbuilder/chroot, etc.
[11:31] <ScottK> If you build in your regular environment, you never know for sure if you have a clean source at the end of the process or not.
[11:32] <ScottK> Not to mention the fun that comes when you mess up your debian/rules and install something in /etc instead of debian/packagname/etc.
[12:06] <kingnothing> can anyone point me in the direction of the code for the window list applet on the panel?
[12:10] <geser> it's in /usr/lib/gnome-panel/libwnck-applet.so from gnome-panel
[12:11] <kingnothing> thanks