[00:00] <Jazzva> Awsoonn, no... you have to call it, no matter what patch system you use (I think it applies for every).
[00:00] <Awsoonn> how / when should it be called?
[00:00] <Jazzva> which patch system you use?
[00:01] <Awsoonn> I'm trying to make a change to apt
[00:01] <Awsoonn> so, I don't know
[00:02] <Jazzva> take a look at debian/rules. Do they include dpatch.make or quilt.make (I think that's the name of the file) at the beginning?
[00:02] <Jazzva> Awsoonn, ^
[00:03] <nhandler> There is also a 'what-patch' script that you can run to figure out the patch system that is being used
[00:03] <Jazzva> nhandler, that's useful :)
[00:04] <Awsoonn> greg sees neither
[00:04] <Awsoonn> grep**
[00:04] <Jazzva> Awsoonn, try with nhandler's advice...
[00:05] <Awsoonn> nhandler: what package is what-patch part of?
[00:05] <nhandler> Awsoonn: ubuntu-dev-tools
[00:08] <Awsoonn> $ what-patch rules
[00:08] <Awsoonn> unknown patch system
[00:09] <nhandler> Just type 'what-patch'
[00:09] <Awsoonn> I didi
[00:09] <Awsoonn> but it says "unknown patch system"
[00:10] <nhandler> That is strange.
[00:10] <Jazzva> Awsoonn, not sure about this... I noticed that it's maintained in bzr too. It might be that patches are applied directly to the source.
[00:10] <Awsoonn> I thought so at first too, but it kinda makes sence
[00:11] <Awsoonn> the patches dir is empty and it is at version ubuntu3
[00:11] <Jazzva> maybe you can check with mvo. Seems like he does a lot of maintenance in apt.
[00:11] <Jazzva> of cource, when he gets around...
[00:12] <Awsoonn> :)
[00:13] <crimsun_> keep in mind that because apt is a native source package, it wouldn't really make sense to have a patch system in place.
[00:13] <persia> slytherin: I think we don't want transition bugs anymore, but I don't think we have a good plan for an alternative yet.
[00:13] <persia> norsetto: the problem is not building nvidia-cg-toolkit, it's installing it :)
[00:14] <Awsoonn> jazzva: I will to then but now wy curiosity is showing... I know nothing abou bzr really, how does using bzr keep patchs away?
[00:14] <persia> smagoun: I don't sleep much, but you've caught me :)  I presume you've already checked your shlibs and symbols files?
[00:15] <Jazzva> persia, I think norsetto left a while ago...
[00:16] <persia> Jazzva: quite possibly :)
[00:16] <Jazzva> Awsoonn, you keep at least two branches. One is with clean upstream source. The other branch is then created from that upstream, and changes are applied directly to it.
[00:17] <Jazzva> Then you publish a package from that other branch...
[00:17] <Jazzva> That would be basic way...
[00:18] <Jazzva> If there are other contributors to the package, they branch from that other branch with changes (which name usually ends in "ubuntu"), apply their changes, push it to their branch, and then ask for merge with ubuntu branch
[00:19] <Jazzva> I hope I wasn't too much confusing :)
[00:21] <Jazzva> Awsoonn, take a look at <https://code.edge.launchpad.net/app-install-data-ubuntu> for example. Imagine app-install-data-ubuntu is not a native package. If it wasn't, we would have "upstream" branch there too. Maintainer would apply needed changes to "ubuntu" branch. My contributions are in ubuntu.mozilla-extensions branch, which is branched from ubuntu, and then merged back to it... It's simple, actually :)
[00:23] <Awsoonn> I think I get in *slow nod* or at least I'm starting to :)
[00:24] <Jazzva> That's great :)
[00:24] <Jazzva> bzr is cool once you get used to it :)
[00:25] <Jazzva> anyway, I'm off now. Good luck with that patch :).
[00:29] <tacone> anyone knows which python package provides gksu module ?
[02:19] <bddebian> Heya gang
[02:29] <cody-somerville> Heya
[02:29] <bddebian> Hi cody-somerville
[02:29] <ScottK-laptop> Heya bddebian
[02:29] <bddebian> Hi ScottK-laptop
[02:30] <cody-somerville> wow
[02:31] <cody-somerville> Lots of polotiks today
[02:31] <bddebian> polotiks? Where?
[02:46] <LucidFox> NCommander> Congratulations on codeblocks's acceptance!
[02:47] <NCommander> Thank you :-)
[02:47] <NCommander> LucidFox, you made it possible ;-)
[02:47] <NCommander> It feels to finally get that into the archive
[02:47] <NCommander> (any reason you gave up trying to package it?)
[02:48] <cody-somerville> pfft.
[02:48] <NCommander> something wrong cody-somerville?
[02:49]  * cody-somerville clearly invested no time in helping get CodeBlocks into the archive :P
[02:49] <emgent> heya
[02:49] <persia> cody-somerville: Well, you didn't upload a candidate to REVU, did you?
[02:49] <LucidFox> NCommander> He has a point :)
[02:49]  * NCommander kisses cody's feet and worships him :-P
[02:50]  * cody-somerville struts.
[02:50] <cody-somerville> Thank you, thank you.
[02:50] <cody-somerville> NCommander, Good work :)
[02:50] <NCommander> Modest, aren't we :-P
[02:50] <NCommander> Thank you ;-)
[02:50] <NCommander> I also tackled a great evil
[02:50] <NCommander> CDBS multibuilds
[02:50] <NCommander> Ewwww
[02:50] <cody-somerville> Ewww
[02:50] <NCommander> And this one came with extra evil
[02:50] <cody-somerville> Ewwww
[02:50] <NCommander> Python modules built with configure scripts!
[02:51] <NCommander> I scared him off
[04:23]  * NCommander laughs evilly
[04:34] <Awsoonn> when pbuilder is done, where does the output go?
[04:34] <NCommander> Awsoonn, /var/cache/pbuilder/results
[04:34] <Hobbsee> where you've set it to go.
[04:34] <NCommander> Or something like that
[04:34] <Hobbsee> usually, ^
[04:35] <Hobbsee> -s
[04:35]  * NCommander hacks on REVU to remove the requirement of asking an admin to keysync
[04:36] <Awsoonn> :D thank
[04:36] <Awsoonn> s
[04:42] <emgent> emgent@amnistia:~$ sudo chroot /home/emgent/.chroots/intrepid/ /bin/bash
[04:42] <emgent> [sudo] password for emgent:
[04:42] <emgent> root@amnistia:/# apt-get
[04:42] <emgent> bash: apt-get: command not found
[04:42] <emgent> root@amnistia:/#
[04:42] <emgent> nice! :-)
[04:42] <StevenK> emgent: What about dpkg?
[04:43] <emgent> dpkg is in.
[04:44] <emgent> StevenK: http://pastebin.ubuntu.com/30187/
[05:03] <Awsoonn> Bug #224460
[05:04] <Awsoonn> should apt-cache show conflicts under dependantcies? or is this a new feature being requested?
[06:37] <jmarsden> Is there a "recommended" way to set things up so that when I do apt-get source I get sources from Intrepid, but when I apt-get install I get Hardy binary debs?  Are there any dangers involved in doing this?
[06:37] <Flannel> jmarsden: only add intrepid deb-src
[06:38] <jmarsden> That's what I was thinking about... it's safe to do that?  Cool :-)
[06:38] <Flannel> There aren't inherent dangers of adding the repos, but what you do with it
[06:38] <Flannel> jmarsden: If you're looking to backport stuff, see !prevu
[06:41] <jmarsden> No, I just tend to do apt-get source ready to do a bug fix, and end up creating a debdiff against an "old" source version!
[07:01] <snadge> i dont suppose anyone here happens to know how to get ubuntu to output to xen's graphics console when running as a domU?
[07:09] <white> kees: around? Did you get my mail?
[07:11] <StevenK> white: It's 11pm where kees is.
[07:16] <NCommander> hey StevenK
[07:16]  * StevenK waves
[07:16] <NCommander> StevenK, mind taking a look at a blueprint and weighing in on it?
[07:16] <StevenK> NCommander: Maybe later.
[07:17] <NCommander> StevenK, busy I take it?
[07:17] <StevenK> Distracted by $WORK and would rather not context switch
[07:18]  * RAOF likes the _distracted_ by work aspect.
[07:20] <NCommander> lol
[07:20] <NCommander> RAOF, how about you?
[07:21] <RAOF> I could be persuaded to stop hitting myself with autofoo and do something else.
[07:21]  * Hobbsee hits RAOF with a brick
[07:22] <NCommander> https://blueprints.edge.launchpad.net/revu/+spec/revu2 - my plans for the next revision of REVU ;-)
[07:22] <RAOF> Hobbsee: Thank you.  Just what I was after :)
[07:22] <Hobbsee> hehe
[07:22]  * NCommander thanks Hobbsee 
[07:22] <Hobbsee> you're welcome :)
[07:23]  * NCommander is working out how to determine which key generated a signature on an upload 
[07:23] <NCommander> I have the GPG fingerprint, and I have the LP username for every fingerprint, I just need to figure out how to determine the former from the signatures
[07:24] <NCommander> (I also have the public keys)
[07:24] <Hobbsee> er, what?
[07:24] <NCommander> If I have a signed changes
[07:24] <NCommander> What's the easiest way to see what key, assuming I have the public key, signed the changes?
[07:24] <Hobbsee> so, you've got the gpg ID, and the LP username, yet you don't know how to get the ID of whoever signed the changes?
[07:24] <Hobbsee> gpg --verify <changes file>
[07:24] <NCommander> Hobbsee, yeah
[07:25] <NCommander> I just need to abuse that somehow to assiocate each upload with the LP login now
[07:26] <RAOF> NCommander: Looks like a substantial revu improvement.  You probably want to add a "run lintian against built packages" thing there, too.
[07:26] <NCommander> RAOF, I was already going to do it
[07:26] <NCommander> Once I can work out how to abuse gpg --verify in the way Ineed it to, we're in business
[07:28] <snadge> is anyone in here knowledgeable about framebuffer issues?
[07:28] <NCommander> snadge, try ubuntu-devel
[07:29] <snadge> or specifically whether ubuntu's xen kernel.. is able to output to the frame buffer as well as the xen virtual console
[07:29]  * NCommander can't figure out how to get GPG to spit up the fingerprint of the key used to sign the signature
[07:30] <StevenK> steven@liquified:~/canonical/icedtea-gcjwebplugin% gpg --fingerprint $(gpg --verify icedtea-gcjwebplugin_1.0-1ubuntu2_source.changes 2>&1 | head -n 1 | cut -d\  -f14) 2>&1 | grep Key
[07:30] <StevenK>       Key fingerprint = DB10 7BC2 1687 426E 7AC8  BB23 09F0 7408 C87F FC2F
[07:31] <StevenK> NCommander: ^
[07:31] <NCommander> StevenK, you are in awesome in ways I can't describe :-)
[07:32] <StevenK> NCommander: I'd suggest you don't plug that directly into REVU, but parse out the data you need :-)
[07:33] <NCommander> StevenK, Well, yeah, I just need to get the individual fingerprints; the list of fingerprints can simply be generated into a static file everytime the keyrings are updated
[07:35] <NCommander> StevenK, doesn't appear to work for me, but you gave me an idea
[07:36] <StevenK> NCommander: How doesn't it work?
[07:36] <NCommander> mcasadevall@blacksteel:~/tmp$ gpg --fingerprint $(gpg --verify codeblocks_8.02-0ubuntu1_source.changes 2>&1 | head -n 1 | cut -d\  -f14) 2>&1 | grep Key
[07:36] <NCommander> mcasadevall@blacksteel:~/tmp$
[07:36] <StevenK> NCommander: Run the bit in the $() first
[07:36] <StevenK> NCommander: It should print out the key id
[07:37] <NCommander> ID: Command not found
[07:37] <StevenK> What did you run that time? :-)
[07:38] <NCommander> Well, now I get this
[07:38] <NCommander> mcasadevall@blacksteel:~/tmp$ gpg --verify codeblocks_8.02-0ubuntu1_source.changes 2>&1 | head -n 1 | cut -d\  -f14
[07:38] <NCommander> ID
[07:38] <NCommander> mcasadevall@blacksteel:~/tmp$ gpg --verify codeblocks_8.02-0ubuntu1_source.changes
[07:38] <NCommander> gpg: Signature made Thu 24 Jul 2008 05:40:54 AM EDT using DSA key ID 9DA2DA9B
[07:38] <NCommander> So I know that is a valid signature
[07:38] <StevenK> Ah.
[07:38] <StevenK> Change that 14 to 15
[07:38] <StevenK> Your gpg --verify output is different to mine
[07:38] <NCommander> That did the trick
[07:38] <NCommander> Ew though
[07:39] <NCommander> Having that be variable going to make scripting it a PITA
[07:39] <StevenK> Actually, it doesn't.
[07:39] <NCommander> and I doubt I could regex it
[07:39] <StevenK> In Python, split it on whitespace and grab the last field
[07:39] <NCommander> and then run fingerprint
[07:39] <NCommander> BRILLIANT!
[07:39] <StevenK> Right
[07:39] <NCommander> You are awesome StevenK ;-)
[07:41]  * NCommander looks up how to use subprocess to get the stdio
[07:42] <StevenK>     pipe = os.popen('%s 2>/dev/null' % command)
[07:42] <StevenK>     output = pipe.read()
[07:42] <StevenK>     exitstat = pipe.close()
[07:43] <StevenK> NCommander: ^
[07:44] <NCommander> I always used subprocess, but that works
[07:45] <soren> Or foo = subprocess.Popen(blahblah, stdin=subprocess.PIPE)
[07:45] <soren> input = foo.stdin.read()
[07:45] <soren> subprocess ftw!
[07:46] <NCommander> Don't I want stdout?
[07:46] <Awsoonn> what does -sa do wrt debuild -S -sa
[07:46] <\sh> moins
[07:46] <NCommander> Awsoonn, includes the original source ball under all conditions
[07:47] <Awsoonn> Thank you
[07:48] <soren> NCommander: Sorry, yes, of course.
[07:49] <NCommander> soren, obviously its not liking subprocess.PIPE
[07:53] <soren> NCommander: How is that obvious?
[07:55] <NCommander> soren, no, it didn't like it cause I did something stupid, but its still outputting on the console, and not in my pipe
[07:55] <NCommander> Unless ...
[07:55] <NCommander> Oh
[07:55] <NCommander> THat's lame
[07:55] <NCommander> GPG prints on stderr
[07:55] <soren> Right.
[07:55] <soren> It sends your data to stdout and "the other stuff" to stderr.
[07:55]  * NCommander rolls his eyes
[07:55] <soren> I didn't notice this was for gpg.
[07:55] <NCommander> Wish that was documented better
[07:56] <NCommander> yeah
[07:56] <NCommander> Well, now I got the output in a variable
[07:56] <NCommander> I just need an easy way to get the key ID
[08:00] <NCommander> soren, well, thats pretty :-P
[08:00] <NCommander> http://paste.ubuntu.com/30218/
[08:01] <\sh> argl..bug spam
[08:01] <NCommander> bug spam?
[08:02] <soren> NCommander: [line.split(' ')[-1] for line in input.split('\n') if 'using RSA key' in line][0]
[08:02] <\sh> many edgy tasks are set to won't fix and this generates a lot of mail at least in my inbox
[08:02] <NCommander> soren, I use DSA keys, so that isn't the best way to grab it
[08:02] <NCommander> (I get verified DSA key ID)
[08:02] <soren> NCommander: [line.split(' ')[-1] for line in input.split('\n') if 'gpg: Signature made' in line][0]
[08:03] <soren> Yup, that works too :)
[08:03]  * soren <3 python
[08:03] <NCommander> soren, I think my method is a little cleare
[08:03] <NCommander> *cleaner
[08:03] <NCommander> Its just a single split :-P
[08:04] <soren> Sure. It just only works if gpg keeps outputting the lines in that particular order and if it doesn't add extra words to the line :)
[08:05] <NCommander> :-P
[08:05] <NCommander> Ok, you win
[08:09]  * NCommander works out how to glue the fingerprint back together
[08:09] <NCommander> I have it in two variables like this
[08:09] <NCommander> mcasadevall@blacksteel:~/tmp$ ./test.py
[08:09] <NCommander> 869F DEB4 91C4 5F60 C767
[08:09] <NCommander> E62E A5B9 5304 9DA2 DA9B
[08:11] <soren> ''.join(vara.split(' ') + varb.split(' '))
[08:11] <NCommander> Those aren't lists, those are actual strings
[08:12] <soren> Er... Yes.
[08:12] <soren> That's why I split them.
[08:13] <NCommander> ok, just making sure ;-)
[08:13] <soren> >>> a = '869F DEB4 91C4 5F60 C767'
[08:13] <soren> >>> b = 'E62E A5B9 5304 9DA2 DA9B'
[08:13] <soren> >>> ''.join(a.split(' ') + b.split(' '))
[08:13] <soren> '869FDEB491C45F60C767E62EA5B953049DA2DA9B'
[08:15] <NCommander> Nice :-)
[08:15]  * NCommander is still somewhat of a python newbie
[08:16] <NCommander> How do I get the total number of elements in a list, its not ntuples(), which I use for DB queries
[08:17] <jmarsden> See http://docs.python.org/tut/node5.html#SECTION005140000000000000000  (use the len function)
[08:17] <geser> NCommander: why don't you use gpg --with-fingerprint --verify and grabs the "Primary key fingerprint" from the output?
[08:17] <NCommander> geser, cause I didn't know that existed ;-)
[08:21] <jmarsden> NCommander: Did you look at http://py-gnupg.sourceforge.net/ -- might be overkill, might help... a GPG interface module...
[08:23] <NCommander> http://paste.ubuntu.com/30221/ - can someone figure out what I'm doing wrong?
[08:23] <NCommander> (its likely something very stupid)
[08:27] <soren> NCommander: Heh :)
[08:27] <soren> Last line:
[08:27]  * NCommander is stumped on the join
[08:27] <NCommander> I keep get method not found
[08:28] <NCommander> soren, http://paste.ubuntu.com/30224/ - here's the low fat version
[08:28] <soren> -	fingerprint.join(fingerprint_part1.split(" ") + fingerprint_part2.split(" "))
[08:28] <soren> +	fingerprint = fingerprint.join(fingerprint_part1.split(" ") + fingerprint_part2.split(" "))
[08:29] <NCommander> wooohoo
[08:29] <NCommander> It works
[08:29] <NCommander> Expect I got a newline at the end
[08:29] <soren> Right.
[08:30] <NCommander> There
[08:30] <NCommander> Now I got it working
[08:30] <soren> You split on "Key fingerprint", so each of the parts might contain a linefeed. Linefeeds are not special in that context.
[08:30] <NCommander> http://paste.ubuntu.com/30225/ - ;-)
[08:30] <NCommander> I got it
[08:30] <NCommander> Thank you soren
[08:30] <soren> np :)
[08:31] <NCommander> I'm amazed at how awesome python is
[08:38] <geser> NCommander: a little bit shorter: http://paste.ubuntu.com/30226/
[08:39] <NCommander> geser, awesome
[08:55] <Iulian> Good morning.
[09:21] <incorrect> hello, I am looking to do a few backports for hardy,  i've already backported subversion 1.5
[09:22] <incorrect> would it be worth contributing back the builds?
[09:24] <huats> morning everyone
[09:24] <geser> Hi huats
[09:26] <huats> morning geser
[09:28] <slytherin> incorrect: File a bug, describe the changes you did, probably add a debdiff.
[09:49] <huats> hey murrayc_
[09:49] <huats> sorry to bother
[09:49] <slytherin> hi geser
[09:50] <huats> I send you an email to have your opinion on the gnome-lirc-properties update :)
[09:50] <huats> can we talk about that a bit ?
[09:55] <geser> Hi slytherin
[09:56] <slytherin> geser: are you free? need sponsorship for two packages. One is fix for FTBFS and other is upstream version update.
[10:02] <geser> slytherin: not really, are both in the u-u-s queue? I'll try to look at the queue later today
[10:03] <slytherin> geser: yes both of them are
[10:18] <murrayc_> huats: I was investigating. I will reply now.
[10:18] <huats> murrayc_: oh ok :)
[10:18] <huats> murrayc_: thanks :)
[10:19] <huats> murrayc_: take your time ... there is no rush...
[10:19] <huats> but it is true that your feedback will be much appreciated
[10:22] <Sikon> slytherin> fop has hit the archive!
[10:22] <Sikon> Thanks for your help in making this possible, I've credited you in my post that should soon appear on planet.ubuntu.com
[10:23] <Sikon> (that is, slytherin for fop)
[10:37] <\sh> emgent: just backported moin 1.7 to hardy...and installed it...following the migration plan it's quite easy to upgrade
[10:46] <directhex> is it being planned for official hardy-backports, or are you juest testing?
[10:50] <slytherin> Sikon: :-D
[10:50] <\sh> directhex: just testing
[10:50] <\sh> directhex: I'll upload to my ppa and then others can test too :)
[10:51] <slytherin> Sikon: Of course the fix was ridiculously simple. We were just looking at wrong places.
[10:52] <directhex> \sh, if it requires manual intervention, IMHO it should not get into hardy-backports. a stable dist shouldn't get sudden breakage from running an update
[10:52] <\sh> directhex: that's what I'm thinking....the upgrade path breaks totally...
[10:53] <\sh> directhex: but for people who like to have 1.7 instead of old school 1.5 I think we should make it available through a ppa
[10:53] <directhex> \sh, i agree fully, which is why i run my ppa for mono packages ;)
[10:53] <directhex> \sh, not that my packages every fail to be great & justwork, of course...
[11:09] <slytherin> nhandler_AFK: ping
[11:13] <slytherin> Can anyone comment on bug 223466. I guess archive admin need to be subscribed instead of u-u-s.
[12:03] <nhandler> Hi slytherin
[12:07] <slytherin> nhandler: added a comment on groovy bug you filed. Let me know if you have any comments/suggestions.
[12:09]  * slytherin will be back
[12:10] <nhandler> slytherin: I understand what you are suggesting, but that would involve significant changes to the source code. I don't think those changes should be made in Ubuntu. Instead, they should probably be made upstream.
[12:15] <huats> murrayc_: I just look at your bug
[12:15] <huats> (I mean at your answer)
[12:16] <huats> would you agree if I update the package to the 0.27 release
[12:16] <huats> waiting the lirc update ?
[12:17] <huats> because it might gives a chance to get the 0.27 in hardy... while I am not confident to get the 0.84 lirc in hardy for some time...
[12:35] <murrayc_> huats: Sounds good. Thanks.
[12:44] <huats> murrayc_: ok
[12:45] <huats> I'll do that
[12:45] <huats> thanks for requesting the 0.84 btw
[13:05] <k0p> hi all
[13:05] <k0p> someone can review my package? http://revu.tauware.de/details.py?package=umit
[13:22] <DRebellion> Hey guys, could someone review my package? http://revu.ubuntuwire.com/details.py?package=posterazor
[13:23] <DRebellion> It's built in my PPA: https://launchpad.net/~drebellion/+archive
[13:25] <tbutter> does the revu mailinglist work?
[13:28] <NCommander> tbutter, which mailing list?
[13:28] <tbutter> NCommander: http://lists.ubuntuwire.com/listinfo/motu-reviewers
[13:29] <tbutter> it has no new messages since 12.7., but it seems there are new comments and uploads on revu
[13:29] <NCommander> it appears to work just fine
[13:29] <NCommander> (and in my local REVU installation, sending email works)
[13:30] <tbutter> this seems to be the latest post in the archive: http://lists.ubuntuwire.com/pipermail/motu-reviewers/2008-July/000979.html
[13:31] <tbutter> http://revu.tauware.de/details.py?package=origami  <- that package has comments from today and an upload yesterday
[13:31] <tbutter> i did not receive any mail since 12.7. either
[13:32] <NCommander> tbutter, strange, I'll kick to admins to look into it
[13:32] <NCommander> tbutter, if you could, please file a bug on LP
[13:32] <NCommander> yet
[13:33]  * NCommander hacks away on REVU
[13:33]  * ScottK seriously considers stopping work on Ubuntu development for a month and devoting the time to reporting Launchpad bugs.
[13:33]  * NCommander would use that month to create a free LP
[13:34] <NCommander> StevenK, what bugs to you encounter? LP is still loads better then SourceFrak
[13:34] <NCommander> tbutter, care to look at this spec https://blueprints.edge.launchpad.net/revu/+spec/revu2 and make suggestions?
[13:35] <ScottK> NCommander: Check your tab completion.
[13:35] <NCommander> what tab completion?
[13:35] <ScottK> NCommander: The problem is its getting worse, not better.
[13:35] <ScottK> ScottK/StevenK
[13:35] <NCommander> Oh, whoops >.<;
[13:35]  * NCommander drinks caffiene
[13:35] <NCommander> Sorry, I've been dealing with openid braindeadness
[13:35] <NCommander> And parsing RDF documents
[13:36] <NCommander> My mind is more fried then usual
[13:36] <tbutter> NCommander: https://bugs.launchpad.net/revu/+bug/251816
[13:37] <NCommander> ScottK, you work for canonical, you can steal their red stapler and hold it hostage until they fix LP :-P
[13:37] <ScottK> NCommander: No, I'm not a Canonical employee.
[13:37] <NCommander> wow
[13:37] <NCommander> I'm more gone then I realized
[13:38] <NCommander> brb, super-sized caffiene
[13:38] <ScottK> NCommander: My fix would be revert to the U/I they had a year and a half ago.
[13:38] <NCommander> ScottK, you mean before the green one?
[13:38] <ScottK> Needless to say, the developers of the current U/I aren't real excited about that kind of feedback.
[13:39] <NCommander> I"m reminded the first time sourceforge changed its scheme
[13:39] <ScottK> However, when I point out specific aspects of the way the curren U/I sucks, they accept that.
[13:39] <ScottK> I keep getting told I'll get used to it and it keeps not happening.
[13:39] <NCommander> Great
[13:39] <NCommander> firefox committed suidice
[13:40] <ScottK> So I'm thinking if I dedicate a month or two to nothing but pointing out specific crappage, it might get somewhere.
[13:40] <NCommander> The last stable update seems to have broken it
[13:40] <NCommander> Yup, firefox is broken
[13:41] <NCommander> ScottK, I think I like the current UI over the green one
[13:42] <DRebellion> NCommander, firefox isn't broken -.-
[13:43] <NCommander> DRebellion, its working now, but I had to restart X on the other machine before it started working
[13:44] <NCommander> http://ubuntuforums.org/showthread.php?t=869249 - that's not good
[13:45] <DRebellion> It's actually ubuntuforums.org/* that is b0rken
[13:45] <DRebellion> maybe not
[13:46] <NCommander> I think they are on the recieving end of a slashdotting
[13:46] <DRebellion> firefox is screwing me around, maybe it is broken
[13:46] <laga> no, i get a database error on the mythbuntu sub forum..
[13:46] <broonie> NCommander: the whole thing with borked Linux info is pretty standard for BIOSs.
[13:46]  * ScottK is kidding.
[13:46] <broonie> NCommander: The kernel doesn't actually pay a blind bit of notice to it.
[13:47] <DRebellion> http://linux.slashdot.org/linux/08/07/25/1150218.shtml
[13:47]  * ScottK just quit motu-sru because the job is to hard with Launchpad.
[13:47] <Hobbsee> ScottK: oh, strike!
[13:47] <Hobbsee> ScottK: and where's your resignation mail?
[13:48] <ScottK> Sent it to the ML.
[13:48] <NCommander> ScottK, O_o; how is it fighting you in this respect outside of the bug tracker which doesn't seem to have changed much between releases
[13:48] <Hobbsee> ah yes, here it is.
[13:48]  * Hobbsee actually *quits* said team.
[13:49] <ScottK> NCommander: I find it really confusing to manage stuff and I really can't deal with it.
[13:49] <NCommander> ScottK, which list did it go to?
[13:49] <ScottK> MOTU ML.
[13:49] <ScottK> Gotta run.
[13:49] <Laney> Isn't there a MOTU-LP liaison to represent the MOTU voice?
[13:50] <NCommander> I don't think I'm subscribed to that one >.<;
[13:50] <Hobbsee> and i think you wnated "I give in"
[13:50] <Hobbsee> Laney: yeah, but it hasn't been overly successful to date.
[13:50] <NCommander> Hobbsee, can you CC that message to sonicmctails@gmail.com? (its not in the archives yet AFAIK)
[13:50] <laga> it is
[13:50] <laga> https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004273.html
[13:50] <NCommander> Weird, it didn't pop up for me
[13:50]  * laga finds mailman archives unusable
[13:51] <laga> NCommander: you probably needed to scroll down.
[13:51]  * NCommander shrugs
[13:51] <NCommander> I just use google with mailman most of the time
[13:51]  * NCommander is currently working out a UI update for REVU
[13:51] <Laney> Hobbsee: Oh, perhaps the position needs to be given some structure then
[13:51] <Laney> Anyway, must dash
[13:52] <NCommander> cya Laney
[13:52]  * Laney waves
[13:52] <Hobbsee> Laney: i'm not sure that was the problem
[13:53]  * NCommander personally won't care if they changed the skin weekly if they gave you an option to set a skin and stay with it
[13:54] <Hobbsee> NCommander: it's not so much the skin - that could be ignored.  it's that the menu options keep moving around, and information gets obscured or removed, for the good of projects, but with no care about distributions.
[13:54] <NCommander> Hobbsee, that's more what I meant
[13:55] <NCommander> I used LP for my personal projects so I'm not badly effected, but I just found out you can change your nickname cause it was hidden, even though I had an LP account for over a year
[13:55] <Hobbsee> you can?
[13:55] <NCommander> Hobbsee, Yeah, actually found out about it coding OpenID
[13:55] <NCommander> It was referenced in a bug reort
[13:55] <NCommander> *report
[13:55] <Hobbsee> heh
[13:56] <NCommander> Go to your home page, then Edit Details
[13:56] <NCommander> Second entry
[13:56] <broonie> It took me donkeys years to discover that I'd had an autogenerated account created which was why I couldn't nab broonie :(
[13:56]  * NCommander also just found out that Hobbsee is a women
[13:57] <Hobbsee> heh
[13:57] <NCommander> I find LP works great for some things
[13:57] <NCommander> LIke merging, and blueprints work great
[13:57] <laga> i find blueprints horrible
[13:57] <NCommander> And the bug tracker wreaks something fierce
[13:58] <laga> mostly it looks like it's fire and forget. stuff is then written out in the wiki
[13:58] <NCommander> laga, I don't bother with specifications, I just abuse the whiteboard
[13:58] <NCommander> https://blueprints.edge.launchpad.net/revu/+spec/revu2 - having a nice dependency tree with branch assiocations just does it for me :-)
[13:59] <laga> okay, that does look nice :)
[13:59] <NCommander> laga, yeah
[13:59] <NCommander> I've never saw a good planning tool that could do it beside Bugzilla, and Bugzilla's UI wants me to burn my eyes out
[14:00] <Hobbsee> NCommander: indeed, it's certainly got some nice stuff.
[14:00] <NCommander> Bugzilla great for developers, but sucks for average users
[14:01] <NCommander> Hobbsee, maybe you can enlighten me, I thought doing an SRU was a bug report, a wiki page, and a lot of talking on the lists; I don't get how Launchpad slowing this down
[14:01] <NCommander> Unless Soyuez is controlled via LP
[14:01] <Hobbsee> NCommander: subscribing multiple people, waiting for pages to load.
[14:01] <Hobbsee> soyuz is controlled via LP, but doesn't usually break
[14:01] <Hobbsee> well, not in that area, anyway
[14:01] <NCommander> Hobbsee, strange, I find the wiki usually very slow, but LP to zip along in comparsion
[14:02] <Hobbsee> lucky you :)
[14:02] <NCommander> I do use edge.launchpad.net though
[14:02] <Hobbsee> both are pretty slow here, but launchpad is the slowest website that i ever load here
[14:02] <NCommander> Not the regular LP
[14:02] <NCommander> There are times when edge crawls, and I have to kick it down to normal LP though
[14:02] <Hobbsee> i don't see much difference
[14:03] <NCommander> Who knows
[14:03]  * DktrKranz looks at http://packages.debian.org/sid/i386/lib3ds-dev/filelist, is it legal?
[14:03] <NCommander> Hobbsee, still, you deal with LP a lot more then most people. Your a buildd and archive admin
[14:03] <DktrKranz> shared library provided in -dev packages, weird...
[14:04] <NCommander> Hobbsee, although I'm told dak, despite naming commands after its authors ex-girlfriends, might still be worse then Souyz
[14:04] <Hobbsee> NCommander: this is true.  the queues are often very slow, as very few people actually use them, so no one's really optimised them much
[14:04] <Hobbsee> NCommander: i've not looked into dak much
[14:04] <NCommander> DktrKranz, if you want to see a magicial packaging, go look at dak
[14:04] <Hobbsee> and re buildd admin, buildd.py is very useful.
[14:04] <NCommander> Hobbsee, heh. I run five buildds for Debian
[14:04] <NCommander> I know the "fun" they can be
[14:04] <NCommander> Especially when all five chroots decided to die at once >.<;
[14:05] <broonie> NCommander: The dak names are just famous people, not exes (and they died a few years ago anyway).
[14:05] <NCommander> Oh, well
[14:05] <NCommander> I removed from my brain most of the braindamage that was caused by dak
[14:05]  * NCommander still has "found" memories of getting Britney just to do something beside segfaulting
[14:05] <NCommander> *fond
[14:06] <DktrKranz> NCommander: dak is somehow special ;)
[14:06] <NCommander> dak is somehow painful
[14:06] <NCommander> I told one of the archive admins that Debian is powered by tooth picks, duct tape, and a hell of a lot of luck
[14:06] <NCommander> I was told that was understating it ._.;
[14:06] <broonie> britney is something else, it's not part of dak at all.
[14:07] <NCommander> broonie, I consider it part of dak just because they go hand in hand if you want to run your own Debian
[14:07] <Hobbsee> NCommander: i don't have chroot access - i don't work for canonical.
[14:07]  * NCommander looks at his dak folder
[14:07] <broonie> Well, only if you want the automated testing propagation stuff (and then it's got hooks into the BTS too).
[14:07] <NCommander> Hobbsee, consider yourself fortunate :-)
[14:07] <Hobbsee> so i don't get *quite* that much fun
[14:07] <NCommander> Hobbsee, then again, I'm building an autobuilder network for REVU
[14:07] <NCommander> That's just asking for pain
[14:08] <Hobbsee> indeed.
[14:08] <NCommander> Once you have an apt-get source archive, you really just need wanna-build and quinn-diff
[14:08] <DktrKranz> NCommander: autobuilder network using dak? isn't it too much complex for such a task?
[14:08] <NCommander> DktrKranz, no, I'm not going to use dak for REVU :-P
[14:08] <NCommander> DktrKranz, we needed a testing archive for m68k
[14:08] <DktrKranz> aaaah ;)
[14:09] <NCommander> So I meddled with britney, and somehow ended up running dak to generate some of the data files
[14:09] <DktrKranz> NCommander: please, *please*, don't use wanna-build :)
[14:09] <NCommander> I just want to kill sbuild
[14:09] <NCommander> That program is the vein of my existance
[14:09] <NCommander> If I could get buildd to use pbuilder, life would be MUCH nicer
[14:10] <NCommander> and I don't need to worry about chroots getting managed so easily
[14:10] <NCommander> DktrKranz, I take it you have experience with the Debian autobuilder network?
[14:10] <DktrKranz> NCommander: well... if you need a simple automated build server, you can try debomatic (/me mode reclame on)
[14:11] <NCommander> DktrKranz, we need multiarch support. At least amd64/i386/lpia, and a way to signal to autobuilders to abort a build in progress
[14:11] <DktrKranz> multiarch == crossbuild (or similar)   ?
[14:11] <NCommander> multiple architectures
[14:11] <NCommander> I'd like an autobuilder for each Ubuntu arch
[14:11] <DktrKranz> so, one builder per arch
[14:11] <NCommander> I got spare hardware for i386, powerpc, and lpia
[14:12] <NCommander> DktrKranz, yeah
[14:12] <NCommander> I might be able to get an AMD64 box beside my laptop, which means I just need some poor sap, er, some brave user to run sparc and hppa
[14:12] <DktrKranz> good luck!
[14:13] <NCommander> Well, once we have apt-get source archives
[14:13] <NCommander> THe rest is extremely straightforward
[14:13]  * NCommander has done it all for m68k; and even built the entire etch distro on an autobuilder
[14:13] <NCommander> I would just like a good way to make buildd use pbuilder vs. sbuild
[14:13] <DktrKranz> NCommander: it's you who manage m68k on Debian?
[14:13] <NCommander> One of those guys
[14:14] <NCommander> I'm the one that got GCC 4.3 to stop freaking out on gnu99 packages
[14:14] <NCommander> (it was an ugly hack which I am NOT proud of, but it does work)
[14:14] <DktrKranz> will it get official for lenny?
[14:14] <NCommander> DktrKranz, doubt it
[14:14] <NCommander> We're vetoed as a release arch without a more modern glibc
[14:15] <DktrKranz> ah...
[14:15] <NCommander> Freescale is working to port the necessary kernel and compiler support we need (we need NPTL support)
[14:15] <NCommander> We're looking at lenny+1
[14:15] <directhex> isn't a modern libc a reasonable request?
[14:15] <NCommander> We have 22 autobuilders which is enough to allow us to build sid :-)
[14:16] <DktrKranz> 22? for m68k? whoa!
[14:16] <broonie> NCommander: IIRC there's also pushback on the number of autobuilders...
[14:16] <soren> That allows you to keep up?
[14:16] <NCommander> Brings new meaning to the words cluster computing
[14:16] <NCommander> broonie, we have an exception to that
[14:16] <directhex> NCommander, it does?
[14:16] <NCommander> directhex, we're still sligtly below 90%, but we're keeping up
[14:16] <NCommander> eight autobuilders are out at the moment
[14:16] <NCommander> My four, and Michael's four
[14:17] <directhex> NCommander, add a high performance interconnect and we'll talk about clustering >8\/
[14:17] <NCommander> I'm advocate for Ubuntu m68k
[14:18] <NCommander> ^_^
[14:18] <directhex> i'm peeved about ubuntu ps3
[14:18] <NCommander> directhex, ?
[14:18] <directhex> NCommander, no hardy.
[14:18] <NCommander> directhex, if you want Ubuntu PS3 Hardy, we can compile it; we have the techology
[14:19] <directhex> NCommander, won't run though
[14:19] <NCommander> (I'm quite serious, I have the spare PPC hardware to rebuild the archive in three weeks)
[14:19] <directhex> lots of critical issues. mostly kernel related
[14:19] <NCommander> directhex, backport the kernel, and make an unoffical release; Ubuntu PPC isn't an offical arch anyway
[14:19] <NCommander> ;-)
[14:20] <NCommander> directhex, if your seriously interested in creating a Hardy/Intrepid Ubuntu PS3 release, I'll help
[14:20] <NCommander> (I don't have a PS3, but I can be talked into buying)
[14:20] <directhex> NCommander, i'm... confused by the general state of ps3 linux. it's a big opening for a first-class distro - and the unified hardware testing somewhat easier than it could be
[14:20] <NCommander> directhex, are you a PS3 Ubuntu developer?
[14:21] <bddebian> Heya gang
[14:21] <NCommander> directhex, or know people who ar?
[14:21] <NCommander> morning bddebian
[14:21] <bddebian> Hello NCommander
[14:22] <NCommander> bddebian, you just missed the m68k autobuilder network ;-)
[14:22] <NCommander> directhex, you have a PS3 I take it?
[14:22] <directhex> NCommander, no, i'm a highly critical tech reporter
[14:22] <bddebian> NCommander: Aw, shucks :)
[14:24] <NCommander> directhex, sorry, I meant worked on PS3 dev
[14:24]  * NCommander is running slow this morning
[14:26] <NCommander> directhex, yeah, thats a nasty set of bugs
[14:27] <directhex> NCommander, i have professional curiosity around the cell as an arch (and ps3 as a cheap entry point to it), and a linux fanboy interest in seeing the ps3 turned into a first-class personal computer through the power of a decent distro (with the usual 'no games on linux' argument killed by the fact that, well, it's a ps3)
[14:27] <NCommander> directhex, nice ;-)
[14:27]  * nxvl is starting to think that NCommander is an AI bot
[14:28] <nxvl> NCommander: did you sleep sometime?
[14:28] <directhex> NCommander, i have no great interest in working on ps3 ubuntu as a project, due to lack of time
[14:28] <NCommander> nxvl, what's sleep()?
[14:28]  * NCommander reinflates the air matress
[14:28] <nxvl> ok confirmed
[14:28] <nxvl> he's a bot
[14:28]  * NCommander slaps nxvl 
[14:28] <norsetto> nxvl: neah, crack is just cheap in NY
[14:29] <nxvl> norsetto: you don't want to ask how cheap is here
[14:29] <norsetto> lol
[14:29] <NCommander> norsetto, I live in Rocheser, not NYC
[14:29] <norsetto> nxvl: I guess you don't beat Colombia though
[14:29]  * NCommander needs some breakfast
[14:30] <NCommander> Hobbsee, out of curosity, what it buildd.py?
[14:30] <jpds> NCommander: people.ubuntu.com/~pitt/scripts/buildd.py
[14:30] <jpds> pitti*
[14:31] <broonie> directhex: PS3 Linux doesn't get access to the nice gaming bits.
[14:31] <NCommander> I think this is one of the few times Debian wins
[14:31] <NCommander> Buildds are managed by email
[14:31] <directhex> broonie, so reboot it, and TADA!
[14:31] <NCommander> broonie, high definition nethack FTW
[14:32] <broonie> NCommander: It's what I feel it's always been missind.
[14:32] <broonie> NCommander: Someone did actually do an OpenGL nethack.
[14:32] <directhex> broonie, reboot to "gameos" for games, run linux otherwise. a hell of a lot more pretty for £300 than you'd get with a windows intel machine
[14:32]  * NCommander still hasn't ascended ;.;
[14:33] <NCommander> directhex, er, its a PS3, what good games are there?
[14:33] <directhex> or as a mythfrontend?
[14:33]  * NCommander dives for cover
[14:33] <directhex> NCommander, bah, stop pointing out the flaw in the plan :'(
[14:33] <bddebian> There are about 5,000 variations of nethack aren't there?
[14:33]  * broonie has been considering the Myth front end but the PS3 is *really* noisy.
[14:33] <directhex> broonie, not compared to the xbox it isn't
[14:34] <directhex> tends to get noisy under load though, that much is true. currently i think the mac mini is the ultimate mythfrontend
[14:34] <broonie> directhex: "Better than living next to a runway!"
[14:34] <nxvl> norsetto: i won't bet
[14:34] <directhex> broonie, i live close to a train line, and there's major building work going on in my estate ;)
[14:34] <nxvl> norsetto: same jungle, almost same narcos
[14:36] <nxvl> gone to work
[14:39] <huats> norsetto hey
[14:39] <huats> how are you ?
[14:39] <huats> norsetto !!!
[14:39] <huats> :)
[14:39]  * NCommander wishs though he was an LP buildd admin :-P
[14:39] <norsetto> hi huats
[14:40] <Hobbsee> NCommander: good luck...
[14:40] <Hobbsee> NCommander: try getting a job at canonical.
[14:40] <NCommander> Hobbsee, how'd you get the job?
[14:40] <Hobbsee> mmm....lots of fighting and prodding and poking
[14:40] <NCommander> Hobbsee, well, I just like pain, that's how I got roped into running buildds
[14:40] <NCommander> Hobbsee, Who'd you torture into submission?
[14:41]  * Hobbsee tries to remember
[14:41] <Hobbsee> tollef, mark, colin, and a few other people, iirc.
[14:41] <Hobbsee> mark was the main one
[14:41] <NCommander> why'd you want the job?
[14:41] <Hobbsee> it was interesting?
[14:41] <NCommander> Hobbsee, good reason ;-)
[14:41] <Hobbsee> and i was doing various RM stuff at the time anyway
[14:41] <NCommander> Same reason I fixed GCC 4.3 for m68k
[14:41] <NCommander> RM?
[14:41] <NCommander> Release Management?
[14:42] <Hobbsee> so it made sense to have multiple positions of power
[14:42] <Hobbsee> yes
[14:42] <NCommander> Hobbsee, ah, more fun. I dunno how Souyz is, but working with dak tells me that job is a pain
[14:43] <Hobbsee> heh, yes
[14:43] <NCommander> Hobbsee, if there is ever an opening, and if I ever become a core dev, tell me :-P
[14:43]  * NCommander is smacked around
[14:45] <NCommander> Hobbsee, Launchpad fascinates me, just because it seems to do things better then the original tools, but then I hear from you that it isn't the case
[14:46] <Hobbsee> NCommander: i don't see the internals of the code.  i'm just at it's mercy, more or less.
[14:46] <Hobbsee> i've not really used the original tools, so can't compare.
[14:46] <NCommander> Hobbsee, no, I know that, but still, being able to do so much is awesome
[14:46] <Hobbsee> i can really only compare the way it does work, to the way i wish it worked.
[14:47] <broonie> Half the aggro with LP seems to be moving target thing.
[14:47] <NCommander> Hobbsee, well, to put it in perspective. buildds are controlled via email. dak just uses a weird command syntax
[14:47] <NCommander> But its constant
[14:47] <NCommander> (maybe in daks case TOO constant)
[14:47] <broonie> And very few people ever actually interact with dak directly.
[14:48] <sistpoty|work> hi folks
[14:50] <bddebian> Heya sistpoty|work
[14:50] <sistpoty|work> hi bddebian
[14:50] <NCommander> hey sistpoty|work
[14:50] <sistpoty|work> hi NCommander
[14:50] <NCommander> sistpoty|work, when you get a moment, my openid changes are looking for merging :-P (I linked uploads to GPG keys vs email, and write the account merger)
[14:50] <NCommander> sistpoty|work, and got rid of the need for revu-uploaders and key syncing
[14:51] <sistpoty|work> NCommander: how did you get rid of revu-uploaders? (as in, do we have the possibilty then to blacklist s.o.?)
[14:52] <NCommander> sistpoty|work, keys are imported on the fly on login
[14:52] <NCommander> sistpoty|work, and they're only imported if new keys are needed for importation
[14:52]  * NCommander had a little too much fun with rdflib last night
[14:52] <sistpoty|work> NCommander: so you check with revu-uploaders on the fly?
[14:53] <NCommander> sistpoty|work, no, it queries the individual account
[14:53] <NCommander> SO its extremely fast, even if its importing keys
[14:53] <sistpoty|work> NCommander: does it then check if the account is in revu-uploaders?
[14:54] <NCommander> sistpoty|work, no, but it won't be hard to implement that
[14:54] <sistpoty|work> NCommander: that would be cool (as I'd like to keep the possibility to easily blacklist s.o., just in case)
[14:55] <sistpoty|work> NCommander: I hope it's not too big of a wish, since I guess indirect group memberships might make it more difficult (not too sure what data you get from lp there)
[14:55] <NCommander> sistpoty|work, well, we get the LP username, we could just ban them locally in REVU
[14:55] <sistpoty|work> NCommander: and sorry, can look at the merge only after I got home
[14:55] <NCommander> (add a new permission group: BANNED!)
[14:56] <sistpoty|work> NCommander: I guess that would work as well :)
[14:57] <NCommander> sistpoty|work, personally, just getting rid of the need to sync keys was worth the effort and braindeadness of rdflib
[14:57] <sistpoty|work> heh
[14:59] <NCommander> sistpoty|work, we also have an account merger, and a blueprint for revu2
[14:59] <NCommander> And my favorite: a "REVU is ugly" bug :-P
[14:59] <sistpoty|work> *g*
[14:59] <NCommander> sistpoty|work, be afraid: https://blueprints.edge.launchpad.net/revu/+spec/revu2
[15:00] <DRebellion> Hey guys, could someone review my package? http://revu.ubuntuwire.com/details.py?package=posterazor
[15:00] <DRebellion> It's built in my PPA: https://launchpad.net/~drebellion/+archive
[15:58] <joaopinto> The correct version for a new package not available on Debian is upstream_version-0ubuntu1 ?
[16:00] <warp10> Hi all!
[16:00] <joaopinto> knock knock :P
[16:01] <bddebian> joaopinto: Yes
[16:01] <directhex> joaopinto, spot on
[16:01] <tuxmaniac> warp10: hello
[16:02] <warp10> heya tuxmaniac!
[16:02] <tuxmaniac> bddebian: hello LTNS again :-)
[16:02] <joaopinto> so it is safe to ignore dpkg-source: warning: Version number suggests Ubuntu changes, but there is no XSBC-Original-Maintainer field ?
[16:02] <bddebian> Heh, heya tuxmaniac
[16:03] <tuxmaniac> joaopinto: its safe but you would want to include a XSBC-O-M fiel in your control file
[16:03] <tuxmaniac> it will contain the packager/maintainer name and email
[16:04] <joaopinto> ok, I assume that should be me :P
[16:09] <joaopinto> is anyeone familiar with the Free Art License ?
[16:09] <joaopinto> I am working on a package for which the art is distributed under the FAL, where could I check if the license is acceptable for an universe package ?
[16:12] <joaopinto> fails to compile with the newer g++
[16:12] <sistpoty|work> joaopinto: http://www.gnu.org/licenses/license-list.html might give some clue
[16:13] <joaopinto> grr, it's GPL incompatible, but the software is distributed under GPL and the art with this FAL
[16:14] <joaopinto> what should I do ? Contact the author ?
[16:16] <sistpoty|work> joaopinto: or ask on #ubuntu-devel for clarification (the gnu list gives only a rough overview, and is not always what archive admins make from it)
[16:16] <joaopinto> ok, anyway I need to be sure it builds first :|
[16:18] <joaopinto> any g++ expert to show me what is wrong with "static Sound *fromFile (const std::string &fileName);" ? the newer g++ produces the error pasted above
[16:19] <sistpoty|work> joaopinto: I can find any pasted errors :P
[16:19] <joaopinto> oh, I didn't paste the error, error: expected unqualified-id before '&' token
[16:19] <joaopinto> hum, maybe I need some header file for std::string
[16:20] <sistpoty|work> joaopinto: that would be <string>
[16:20] <joaopinto> let's try before dpatch it
[16:23] <NCommander> Is there anyone here who can run a few tests for me?
[16:23] <NCommander> (I need someone to see if they can log into my local revu installation)
[16:23] <joaopinto> sistpoty|work, it fixed it, thanks
[16:23] <sistpoty|work> np
[16:24] <DRebellion> NCommander, sure.
[16:24] <RainCT> If an application has a license in Japanese and includes an English translation, is it enough to copy the English one into debian/copyright?)
[16:24] <NCommander> DRebellion, http://nemesisnetworks.com/revu-openid
[16:24] <NCommander> First tell me if that loads
[16:25] <NCommander> (if it hasn't by now, that is not a good sign)
[16:25] <DRebellion> =/
[16:25] <NCommander> ok
[16:25] <NCommander> So its an apache issue I think
[16:25] <DRebellion> "Connecting to nemesisnetworks.com..."
[16:25] <NCommander> Yeah
[16:25] <NCommander> Ok
[16:25] <NCommander> At least its not my code
[16:26] <joaopinto> lintian complained about old config.sub, config.guess, it is ok to replace those on the orig.tar.gz or should I create a dpatch for those files refresh ?
[16:26] <NCommander> DRebellion, try it now
[16:26] <NCommander> I just restarted apache
[16:27] <DRebellion> NCommander, nope.
[16:27] <DRebellion> nmap says: 80/tcp filtered http
[16:27] <NCommander> Ok
[16:27] <NCommander> Well
[16:27] <NCommander> That's beautiful
[16:27] <RainCT> btw, are there some other docs on how to package a library other than the Debian Library Packaging guide (other=shorter ;))
[16:28] <RainCT> ?
[16:28] <NCommander> other machines on my network can't access it
[16:28] <NCommander> So its an apache issue
[16:28] <DRebellion> NCommander, perhaps firewall settings? Port 80 should be open, not filtered.
[16:29] <NCommander> DRebellion, I can't even telnet to it from the router
[16:29] <NCommander> Or other machines
[16:29] <NCommander> THe firewall says its right
[16:29] <NCommander> DRebellion, try http://69.207.147.100
[16:29] <DRebellion> It works!
[16:30] <NCommander> crap
[16:30] <NCommander> THe domain moved
[16:30] <NCommander> Or my IP
[16:30]  * NCommander updates his DNS records
[16:30] <NCommander> That explains the timeouts
[16:30] <DRebellion> nemesisnetworks.com points:
[16:30] <DRebellion> nemesisnetworks.com.	1483	IN	A	66.67.48.151
[16:30] <NCommander> yup
[16:30] <NCommander> THat's it
[16:30] <NCommander> Static IPs my ass
[16:30] <DRebellion> hehe, you using dyndns?
[16:31] <NCommander> No
[16:31] <NCommander> Google Apps
[16:31] <NCommander> Needed mail hosting
[16:31] <DRebellion> ah right
[16:31] <sistpoty|work> joaopinto: you should never mangle the .orig.tar.gz (unless it contains non-free bits)
[16:31] <sistpoty|work> joaopinto: however .diff.gz is a quite good patch system imo ;)
[16:32] <joaopinto> well, I always worked with diff.gz, but today I got into the dpatch mood, since it is easy to integrate with cdbs
[16:32] <NCommander> DRebellion, ok, I updated the record
[16:32] <NCommander> Want to try it?
[16:33] <NCommander> (http://nemesisnetworks.com)
[16:33] <DRebellion> not working i'm afraid
[16:33] <NCommander> Not suprising
[16:33] <NCommander> Someone new care to try it? (who doesn't have my domain name cached)
[16:35] <NCommander> DRebellion, ok, well, now its fixed so once the DNS resolved
[16:35] <NCommander> *resolves
[16:35] <DRebellion> NCommander, my router is still giving me the old one -.-
[16:36] <NCommander> Its fine
[16:36] <NCommander> Now that I tracked down the issue
[16:36] <NCommander> I thank you for your contribution to REVU Development ;-)
[16:36] <DRebellion> ;)
[16:36]  * NCommander canned line
[16:37] <NCommander> DRebellion, if you actually would like to work on REVU development, I personally want to make it a little less ugly
[16:37]  * RainCT feels ignored :P
[16:37]  * NCommander doesn't hear anything from RainCT 
[16:37] <DRebellion> RainCT, now you know how me and my package feels ;)
[16:37] <RainCT> heh
[16:37] <NCommander> Hrm, must have been my imagination
[16:37] <NCommander> RainCT, http://nemesisnetworks.com/revu-openid
[16:38] <NCommander> Now not requiring revu-uploaders
[16:38] <NCommander> (or key syncing)
[16:38] <RainCT> NCommander: works :)
[16:38] <NCommander> woo
[16:38] <NCommander> Its so sexy ;-)
[16:38] <NCommander> RainCT, your keys just got synced to revu-openid ;-)
[16:38] <NCommander> It did it during login
[16:38] <RainCT> NCommander: "assiocated" has a typo, twice, in the merge page
[16:39] <NCommander> fixed
[16:39] <NCommander> I thank you for your contribution to REVU Development ;-)
[16:40] <RainCT> lol
[16:41] <NCommander>   10 |    4 | 284E9B2808EDE02D45A41DCC1D3D2D200EADC245
[16:41] <NCommander> There's your GPG key in the database
[16:42] <DRebellion> Come on, there must be someone who can spare a little bit of time to review my package? http://revu.ubuntuwire.com/details.py?package=posterazor
[16:42] <NCommander> RainCT, how do I query the keyring to see all keys
[16:42] <NCommander> gpg --keyring ./trustdb.gpg, right?
[16:43] <DRebellion> You don't even have to test build it! https://launchpad.net/~drebellion/+archive
[16:43]  * RainCT has no idea about keys :)
[16:43] <NCommander> hrm
[16:43] <NCommander> I can't figure out if your key actually got imported
[16:43] <RainCT> NCommander: perhaps you will find how to do it in some of the scritps
[16:43] <NCommander> your a great help :-P
[16:43] <RainCT> I know :P
[16:46]  * RainCT is looking for a multi-binary package with a lib and using cdbs
[16:46] <bddebian> Sounds evil
[16:48] <RainCT> bddebian: yep, but it's to get a great feature :)
[16:48] <RainCT> although I'm not sure if it's great enough to be worth packaging two evil applications and writting some scripts..
[17:01] <DRebellion> NCommander, what sort of REVU dev work did you have in mind?
[17:01] <NCommander> I'd like to redo the HTML and make the interface more modern
[17:02] <DRebellion> hmm, I've never coded html
[17:02] <DRebellion> NCommander, looks like my router has finally updated the dns, time to check out the so-called ugly interface
[17:02] <NCommander> DRebellion, its the same as the regular REVU ;-)
[17:03] <DRebellion> ah right
[17:03] <NCommander> I would like to make more similar to the lists you see on Launchpad
[17:03] <DRebellion> s'not that bad
[17:03] <NCommander> SMaller fonts
[17:03] <NCommander> Less brown
[17:03] <DRebellion> ok, now I think about it, the fonts could be a bit smaller
[17:05] <NCommander> Well, THAT's pretty
[17:05] <NCommander> GPG's output is in Apache's error log
[17:05] <NCommander> (because GPG prints on stderr)
[17:15] <RainCT> Archive admins won't get angry if I don't list the authors in debian/copyright (the policy says listing the authors is a "should"), or? (I don't feel comfortable listing them as there is no authors list and I can only guess grepping names out from the source files)
[17:19] <k0p> hi all
[17:20] <k0p> someone can review my package? http://revu.tauware.de/details.py?package=umit
[17:24] <DktrKranz> k0p: XB-Python-Version: current is already in binary stanza, you can omit from source stanza, you already have XS-Python-Version there
[17:27] <DRebellion> Could someone review my package? http://revu.ubuntuwire.com/details.py?package=posterazor Thanks :)
[17:27] <LucidFox> Why is ACCEPTED so large currently?
[17:28] <DRebellion> It's built in my PPA: https://launchpad.net/~drebellion/+archive
[17:28] <DktrKranz> LucidFox: I noticed Soyuz won't move packages from pending to published, that could be the cause
[17:29] <LucidFox> DktrKranz> Seems so
[17:30] <DktrKranz> LucidFox: maybe asking to archive admins or cprov might help
[17:42] <k0p> DktrKranz, so omit xs-python-version?
[17:42] <k0p> delete this line?
[17:43] <DktrKranz> k0p: XB-Python-Version, the one below XS-Python-Version
[17:43]  * sistpoty|work heads home... cya
[17:45] <k0p> DktrKranz, done. deleted XB-Python-Version
[17:46] <k0p> DktrKranz, what do you think about rest?
[17:47] <DktrKranz> k0p: I just gave a very quick look, not a full review, no major errors so far, but I need to check licensing carefully (even if I think it's good)
[17:47] <huats> norsetto: regarding the example pb
[17:47] <k0p> DktrKranz, sure.
[17:47] <huats> would it be acceptable that I install the file using dh_install and not dh_installexamples ?
[17:48] <norsetto> huats: good try, but nope :-)
[17:48] <huats> :)
[17:48] <DktrKranz> k0p: I won't be at home this eve (maybe only very late), if you ping me tomorrow, I can have a full review :)
[17:48] <huats> norsetto: 2 things happen
[17:48] <huats> the first each file of more than 4.5 K is gz by dh_installexamples
[17:48] <k0p> DktrKranz, really? :D thanks
[17:49] <k0p> DktrKranz, belive me, I'll ping :)
[17:49] <DktrKranz> ;)
[17:49] <norsetto> huats: thats normal and its policy
[17:50] <huats> which means that in order to use the example (it is 1 single example that fall into say 20 files) you need to gunzip all of them
[17:50] <huats> so the solution might be to use dh_installexamples
[17:50] <huats> to move most of them
[17:50] <huats> and then to compress the one too small to be compressed...
[17:51] <huats> (since gz file do not provoques a warning by lintian)
[17:51] <norsetto> huats: note that you should not run the examples from /usr/share thats just an holding space, so its fine if they are compressed and only uncompressed when needed
[17:51] <huats> ok
[17:52] <huats> won't it be better to create a tar of the whole example dir
[17:52] <huats> and then to give that tar to dh_installexamples ?
[17:52] <huats> that would ease the use of the example
[17:52] <norsetto> huats: hmmm but why would lintian be complaining?
[17:53] <huats> it is complaing :)
[17:53] <norsetto> huats: can you show me your rules and the lintian output ?
[17:53] <DktrKranz> k0p: just a quick question: why python, python (>= 2.5) | python-pysqlite2   ?
[17:54] <RainCT> DktrKranz: because sqlite is in the standard python libs since version 2.5
[17:54] <huats> norsetto: sure
[17:55] <DktrKranz> RainCT: ah, thanks ;(
[17:55] <k0p> DktrKranz, hmm
[17:55] <DktrKranz> erm.... I mean ";)"
[17:55] <k0p> yeap
[17:56] <k0p> RainCT hi :)
[17:56]  * RainCT greets k0p :)
[17:57] <huats> norsetto: http://pastebin.org/57038
[17:57] <huats> and
[17:58] <huats> http://pastebin.org/57040
[17:58] <k0p> DktrKranz, I upload little fix that you said me about XB-Python-Versions
[17:59] <DktrKranz> ok
[17:59] <norsetto> huats: what has this to do with the zipping !?
[18:00] <huats> all the files we you have a lintian warning
[18:00] <huats> are unzipped files
[18:00] <huats> all the others (which are zipped)
[18:00] <huats> do not provide a warning
[18:01] <norsetto> huats: but the warning is about them having the executable bit set and not being executable
[18:03] <norsetto> huats: instead of having demos in examples, why not directly all the content of it?
[18:04] <huats> norsetto: I haven't understood your sentence (the content of it)
[18:05] <norsetto> huats: you are installing the whole demos dir in /usr/share/doc/libtktreectrl/examples/
[18:06] <norsetto> huats: it would be better to have /usr/share/doc/libtktreectrl/examples/pics etc.
[18:06] <RainCT> If an application comes with some additional binaries and scripts which would be useful to have in /usr/bin, but some of the names are very generic, what do you recommend me to do with them? Prefix them with the name of the package (and if so, all of them or only those with a generic name)?
[18:07] <huats> norsetto: what would it change ?
[18:07] <huats> (well I see the thing to remove the demo dir)
[18:07] <norsetto> huats: that having exaples/demos only its silly
[18:07] <huats> but what would it change for my pb :)
[18:08] <huats> I mean
[18:08] <huats> I'll try rght now...
[18:08] <norsetto> huats: its nothing to do with your "problem", is an additional comment
[18:09] <huats> norsetto: oh ok :)
[18:09] <huats> thanks for the comment :)
[18:09] <norsetto> huats: my pleasure :-)
[18:09] <huats> (btw I lead 4-3 with today)
[18:09] <huats> :P
[18:09] <RainCT> huats: you can fix the problem from the warning with a simple chmod -x, btw
[18:09] <huats> RainCT I was about to do so...
[18:10] <huats> thanks
[18:10] <norsetto> huats: nope, its 3-4, and thats because you are sleeping ...
[18:10] <huats> the thing is that I feel a bit unease to have some file named *.tcl and some other *.tcl.gz in the same dir while they were all *.tcl
[18:11] <norsetto> huats: get used to it then ...
[18:11] <huats> :)
[18:11] <huats> I am :)
[18:11] <huats> it is just that I was looking for "another" solution
[18:11] <huats> :)
[18:11] <huats> (that I haven't found)
[18:13] <norsetto> huats: whats the difference with when you install files in /usr/share/package/doc ?
[18:13] <huats> norsetto: what do you mean ?
[18:14] <RainCT> huats: what's about an examples.gz?
[18:14] <RainCT> *.tar.gz
[18:14] <norsetto> huats: I mean, this is exactly the same behaviour for dh_installdocs, why is that not giving you problems?
[18:14] <huats> i know
[18:14] <huats> it sounds silly...
[18:14] <huats> but it is OK now
[18:14] <huats> :)
[18:20] <huats> norsetto: I really need to go now...
[18:20] <huats> but I'll send you an emailthis WE telling you I have done the new upload :)
[18:20] <norsetto> huats: ok :-)
[18:20] <norsetto> huats: have a nice WE!
[18:20] <huats> thanks for your help luke and cesare
[18:20] <huats> thanks !
[18:20] <huats> I will (going to géraldine's parents...)
[18:20] <huats> :)
[18:21] <norsetto> huats: luke?
[18:21] <norsetto> huats: skywalker?
[18:21] <norsetto> huats: ok, don't eat too much foie gras then :-)
[18:21] <huats> why did I think that it was TheMuso who told me for the chmod...
[18:21] <huats> and it was RainCT :)
[18:21] <huats> I won't
[18:22] <huats> remember I am on diet  :)
[18:22] <huats> bye
[18:22] <norsetto> huats: ah, I forgot it ;-)
[18:22] <huats> I haven't
[18:22] <huats> a:(
[18:22] <huats> :(
[18:23] <joaopinto> can someone check if my GPG key is synchronized in REVU ?
[18:32] <RainCT> joaopinto: it is
[18:32] <joaopinto> ok tks
[18:33] <joaopinto> revu sends a result email right ?
[18:33] <RainCT> no
[18:33] <joaopinto> ouch
[18:33] <RainCT> (mentors.debian.org does, but REVU not)
[18:42] <Iulian> It's .net
[18:44] <directhex> someone rang?
[18:44] <directhex> oh, wait. /me returns to the monocave
[18:48] <joaopinto> should a coverfinder app go into sound&video or graphics ?
[18:50] <slytherin> joaopinto: cover finder for what?
[18:50] <joaopinto> cd cover finder
[18:50] <joaopinto> CD
[18:50] <joaopinto> for audio CDs
[18:50] <slytherin> joaopinto: I guess that should be sound and video
[18:50] <joaopinto> ok
[18:51] <joaopinto> can someone review http://revu.ubuntuwire.com/details.py?package=coverfinder ?
[18:52] <RainCT> does someone know why it may be that I get this?    /usr/bin/install: no s’ha pogut crear el fitxer ordinari «/usr/bin/dfa_determinize»: Permission denied
[18:53] <RainCT> (building a cdbs package with autotools.mk)
[18:53] <slytherin> RainCT: Can you please translate it?
[18:53] <RainCT> slytherin: couldn't create file
[18:53] <tuxmaniac> whats the standard version used? 3.8 ?
[18:54] <RainCT> tuxmaniac: yep, 3.8.0
[18:54] <slytherin> tuxmaniac: 3.8.0
[18:54] <joaopinto> RainCT, the install is attempting to install into the system bin dir instead of the debian/target ?
[18:54] <slytherin> RainCT: what joaopinto said
[18:54] <RainCT> that what I think, but I don't see why it should be do that :S
[18:55] <joaopinto> probably the Makefile does not honor DESTDIR
[18:56] <RainCT> that it calls ./configure with --prefix=usr/ is normal (first I thought that's the problem but I've just seen lots of build logs looking like that), or?
[18:56] <slytherin> RainCT: paste your rules file somewhere
[18:56] <joaopinto> RainCT, that is for the configure, and it is fine, your problem is with the install rule
[18:57] <joaopinto> if you are using the defaults, it should call make install DESTDIR=$(CURDIR)/debian/package
[18:58] <RainCT> it hasn't got anything special.. http://paste.ubuntu.com/30337/plain (I've tried adding "DEB_MAKE_INSTALL_TARGET  := install DESTDIR=$(CURDIR)/debian/tmp/" but that didn't help)
[18:59] <directhex> joaopinto, what's the source of the data?
[18:59] <slytherin> RainCT: Is it a new package, do you have files like debian/install. What does that file contain?
[18:59] <emgent> heya
[18:59] <joaopinto> directhex, sorry ? which source of which data ?
[18:59] <RainCT> slytherin: no, I haven't any of those yet
[18:59] <directhex> joaopinto, where does coverfinder get covers from?
[18:59] <joaopinto> directhex, amazon
[19:00] <joaopinto> "This is a tool to find cover images via the Amazon Web Services API and to"
[19:00] <directhex> joaopinto, check the AWS terms & conditions. iirc there are issues with them
[19:02] <joaopinto> ops, wasted work :\
[19:02] <joaopinto> can someone nuke the package from revu :P ?
[19:04] <slytherin> directhex: but gcstar also retrives artwork from amazon
[19:05] <joaopinto> wait, i was reading the amazon page conditions of use
[19:05] <joaopinto> I can't find any conditions of use for the API
[19:07] <directhex> http://www.amazon.com/E-Commerce-Service-AWS-home-page/b/ref=sc_fe_c_0_15763381_1?ie=UTF8&node=12738641&no=15763381&me=A36L942TSJ2AJA
[19:07] <tuxmaniac> can I use dpatch for a package that uses cdbs? I mean the rules file doesnt contain the build-stamp etc
[19:07] <joaopinto> http://bibwild.wordpress.com/2008/03/19/think-you-can-use-amazon-api-for-library-service-book-covers/
[19:07] <directhex> "You may use the data in the Amazon Associates Web Service as long as it's used primarily to drive traffic back to Amazon's web sites or sales of Amazon products and services. "
[19:07] <RainCT> tuxmaniac: yes. there's a dpatch.mk
[19:07] <joaopinto> tuxmaniac, yes you can, is quite easy, you just need to include the dpatch makefile
[19:08] <RainCT> (/usr/share/cdbs/1/rules/dpatch.mk)
[19:08] <directhex> yes, i know, AWS is lovely, but the license sucks
[19:08] <tuxmaniac> and then I do as usual creating the patches directory and 00list etc right?
[19:08] <tuxmaniac> no other change required?
[19:08] <RainCT> tuxmaniac: right
[19:08] <tuxmaniac> in the rules I mean
[19:08] <tuxmaniac> RainCT: thanks
[19:11] <slytherin> tuxmaniac: why not use cdbs simple patchsys?
[19:12] <tuxmaniac> slytherin: I am used to dpatch. hence. But I will look into what you are telling
[19:13] <slytherin> tuxmaniac: simple patch sys is even simpler
[19:14] <RainCT> joaopinto: you were right, "make install" doesn't recognize DESTDIR, but "make install prefix=..." works
[19:15] <RainCT> joaopinto: do you know how I can get cdbs to use prefix instead of DESTDIR or how to fix the makefile?
[19:15] <joaopinto> so you just need to override the DEB_*INSTALL* var
[19:15] <RainCT> ah ok
[19:15] <joaopinto> or you fix the makefile and provide the patch upstream
[19:15] <RainCT> DEB_MAKE_INSTALL_TARGET  := install prefix=$(CURDIR)/debian/tmp/    -  like this?
[19:15] <joaopinto> yes, that should work
[19:16] <RainCT> thanks
[19:29] <RainCT> (yep, worked now)
[19:32] <DRebellion> Could someone review my package? http://revu.ubuntuwire.com/details.py?package=posterazor Thanks :)
[19:32] <DRebellion> It's built in my PPA: https://launchpad.net/~drebellion/+archive
[19:34] <slytherin> DRebellion: There is no use asking for review everyday
[19:34] <DRebellion> slytherin, how comes?
[19:34] <slytherin> DRebellion: people get annoyed by this.
[19:35] <DRebellion> slytherin, that's fair.
[19:35] <DRebellion> slytherin, how do any of the packages get reviewed anyway?
[19:35] <nhandler> DRebellion, They get reviewed when a MOTU finds time to review them
[19:36] <slytherin> DRebellion: You mean on revu. The MOTU team members do it. Of course anyone is now allowed to review a package. But only MOTU members can advocate a package.
[19:38] <DRebellion> hmm... okay, i'll lay off the spamming for a while
[19:57] <tuxmaniac> how long does it take normally for a revu upload to reflect on the website? Has it got increased of late?
[19:58] <joaopinto> mine took 5 minutes
[19:58] <tuxmaniac> its up now. :-)
[19:59] <tuxmaniac> if someone can review and pass on http://revu.tauware.de/details.py?package=gresistor it will be nice. A very small package it is
[20:12] <nhandler> Could someone here help me add a patch system to a package? Or could someone at least point me to some documentation about adding a patch system?
[20:16] <tuxmaniac> nhandler: dpatch? http://www.tuxmaniac.com/blog/2008/01/25/dpatch-just-superb-a-short-how-to/
[20:19] <jpds> nhandler: If you are using CDBS, I suggest using simple-patchsys.mk
[20:20] <slytherin> nhandler: are you working on groovy?
[20:21] <tuxmaniac> slytherin: did you assign the electric bug to Universe sponsors?
[20:21] <tuxmaniac> or is it not required?
[20:22] <slytherin> tuxmaniac: I subscribed them. No need to assign. I talked with geser and persia yesterday but no one was free for a review.
[20:23] <tuxmaniac> slytherin: and I have packaged gresistor for bug 251919. I update the bug report with the diff and subscribe them?
[20:24] <slytherin> tuxmaniac: Is it a new package? If yes the add link to revu page of the package in the bug.
[20:24] <nhandler> No slytherin, I'm working on a different patch. It doesn't matter what patch system I use
[20:24] <tuxmaniac> yes doing it.
[20:25] <slytherin> nhandler: Ok. Do you have any concerns about the comment I added on groovy bug?
[20:26] <nhandler> slytherin: I don't think your suggested changes should be applied in Ubuntu. I think it would be better if they were applied upstream.
[20:27] <slytherin> nhandler: are including libs in upstream tarball? Then I guess they should either be stripped in .orig.tar.gz or be cleaned in clean target. If they are getting copied in build process then patch the build.xml to not do it.
[20:29] <nhandler> jpds: Do you by any chance have a guide on how to add a cdbs patch system to a package?
[20:29] <nhandler> slytherin: I'll have to take a closer look at the package. Chances are I won't get to it until after the weekend. If you want to prepare a patch before then, feel free.
[20:30] <jpds> nhandler: Add: "include /usr/share/cdbs/1/rules/simple-patchsys.mk" to debian/rules.
[20:30] <nhandler> Is that it?
[20:30] <jpds> nhandler: And place the patches in debian/patches/
[20:30] <slytherin> nhandler: will see
[20:30] <jpds> nhandler: Yes. Simple huh? :-)
[20:30] <nhandler> Wow, it really is easy jpds :)
[20:32] <joaopinto> does patchsys provides some helper script like dpatch-edit ?
[20:32] <slytherin> nhandler: https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[20:32] <slytherin> joaopinto: it is part of cdbs, try command cdbs-edit-patch
[20:32] <slytherin> of course with a patch name
[20:32] <nhandler> slytherin, I've seen that. But it doesn't show you how to add a patch system. It only shows you how to add patches
[20:33] <slytherin> nhandler: you are right, time to edit the page
[20:34] <slytherin> nhandler: we both overlooked. For simple-patchsys the page has instructions.
[20:36] <nhandler> You are correct slytherin. ;)
[20:36] <norsetto_> treat cdbs-edit-patch with veneration
[20:37] <SWAT> is it possible to get the REVU keyring synced? I just uploaded my (new) gpg-key and want to upload 3 packages for review
[20:38] <jpds> SWAT: Sec.
[20:39] <jpds> SWAT: revu-key scripts running. I shall tell you when it's done.
[20:40] <nhandler> What are the "include /usr/share/cdbs/1/rules/debhelper.mk" and "include /usr/share/cdbs/1/class/makefile.mk" lines for in debian/rules?
[20:41] <jpds> nhandler: They add commands from CDBS to build the packages.
[20:42] <nhandler> jpds: Do I need to include them in the rules file?
[20:42] <slytherin> nhandler: you get a set of predefined commands and variables in those files.
[20:42] <SWAT> jpds: thanks
[20:42] <cody-somerville> Meeting in 18-20 minutes :)
[20:43] <slytherin> nhandler: debhelper.mk you will need always. Not sure about makefile.mk
[20:43] <norsetto> nhandler: those are makefiles that will be included in your rules, check them out, its quite informative to see whats in there
[20:46] <jpds> SWAT: All done. Upload at will.
[20:48] <joaopinto> can someone review http://revu.ubuntuwire.com/details.py?package=amoebax  (game) ? Thanks
[20:49] <joaopinto> and one question about revu, once the package is accepted, does the comments get archived but available for future reference ?
[20:49] <SWAT> jpds: merci!
[20:49] <jpds> SWAT: De rien!
[20:51] <nhandler> I'm getting this error when I try to use cdbs-edit-patch to create a patch with the new patch system: "debian/rules:43: *** target file `clean' has both : and :: entries.  Stop."
[20:52] <jpds> nhandler: I think you have to change the "clean:" rule in rules so it has two "::".
[20:52] <slytherin> nhandler: or the reverse of what jpds said
[20:53] <nhandler> That did it jpds. Hopefully, I will be able to get the patch added now ;)
[20:54] <jpds> Good.
[20:54] <norsetto> devfil_: can you use a more customary name for the patch in bug 251925 ?
[20:55] <devfil_> norsetto: ubuntu_toolchain_FTBFS is ok?
[20:55] <norsetto> devfil_: but the patch is just adding flags for the O_CREAT
[20:56] <devfil_> norsetto: yes, but the FTBFS is caused by D_FORTIFY_SOURCE=2 flag enabled in intrepid
[20:57] <norsetto> devfil_: btw, S_IWUSR is repeated twice and I'm not sure we need S_IRGRP|S_IROTH
[20:57] <sistpoty> re
[20:57] <devfil_> norsetto: I've take it from the same code
[20:57] <devfil_> norsetto: ok, I'm going to fix it properly
[20:58] <nhandler> Just out of curiosity, is anyone working on finishing this wiki page: https://wiki.ubuntu.com/README.sourceHowTo
[20:58] <persia> MOTU Meeting in 2 minutes in #ubuntu-meeting
[20:59] <devfil_> norsetto: I've also done another patch to fix a FTBFS, can you take a look at it?
[20:59] <norsetto> devfil_: not now, but don't worry, it will come under the radar ;-)
[20:59] <devfil_> norsetto: ok :)
[21:03] <slytherin> nhandler: FYI ... groovy is not actually bundling jars. It is just adding symlinks to them.
[21:03] <nhandler> Thanks for the information slytherin
[21:07] <RainCT> what's wrong with this (watch file)?  http://sourceforge.jp/projects/julius/files/ http://sourceforge.jp/projects/julius/downloads/(?:[0-9]+)/julius-(.*)\.tar\.gz
[21:09] <slytherin> RainCT: have you tried running uscan?
[21:09] <devfil_> norsetto: can you unsubscribe u-u-s from the bug? I need at least 2 hours to build it again
[21:09] <norsetto> devfil_: I can't
[21:09] <RainCT> slytherin: yep, uscan --verbose. it doesn't find anything
[21:09] <joaopinto> do we get an email when someone posts a comment on REVU ?
[21:09] <nhandler> I don't think so joaopinto
[21:10] <slytherin> RainCT: A simpler patter would be this - http://sf.net/medit/mooedit-(.*)\.tar\.bz2
[21:10] <RainCT> joaopinto: right now not (it may be implemented in the near future, though)
[21:10] <joaopinto> uff, it is kind of frustrating to work with REVU
[21:10] <RainCT> slytherin: that doesn't seem to work with sourceforge.jp
[21:10] <geser> slytherin: re your question about bug 223466: just like sync requests, requests for removal need to be ACKed by a motu too.
[21:10] <joaopinto> can the review be performed on LP instead of REVU ? since we need a bug nr in the first place ?
[21:11] <RainCT> joaopinto: NCommander is doing some great work which should make it better (like switching to OpenID with Launchpad for login, obsoleting the revu-uploaders group, import from PPA, etc.)
[21:11] <nhandler> joaopinto, You are meant to open a needs-packaging bug at the very beginning. But once the package gets uploaded to revu, all discussion is meant to occur there
[21:11] <slytherin> geser: hmm, I have one removal request up my sleeve. :-)
[21:12] <joaopinto> why not moving the entire process to LP instead ?
[21:12] <slytherin> How do I calculate rdepends?
[21:12] <geser> apt-cache rdepends
[21:13] <joaopinto> what is the advantage of using REVU over LP ?
[21:13] <geser> and for rbuilddepends you can use the reverse-build-depends script from ubuntu-dev-tools
[21:13] <slytherin> geser: yes, that I am already using
[21:13] <slytherin> joaopinto: I don't think the way our reviews work, LP can handle that.
[21:14] <NCommander> slytherin, no, its a known problem that while PPAs are awesome, Soyuz isn't really suited for handling reviewing and such
[21:14] <slytherin> NCommander: yes that is what I meant
[21:15] <joaopinto> what is so specific with the review process ? the advocates count ?
[21:16]  * NCommander sighs
[21:16] <Laney> Packages go through multiple iterations of reviewing
[21:17] <joaopinto> you mean multiple comments ? I don't see any specific iteration status on REVU
[21:17] <NCommander> joaopinto, go look at a package, then see each version is listed in chronological order
[21:17] <Laney> (with comments to a particular version)
[21:18] <joaopinto> how does that differ from LP with comments with diffs attachments ?
[21:23] <joaopinto> is it acceptable to send a review request to the MOTU ML or those should be kept on IRC ?
[21:26] <slytherin> joaopinto: it should acceptable but I do not recommend it. We will suddenly get flooded with revu requests.
[21:28] <RainCT> slytherin: (about the watch file.... the links doesn't start with "http://source.." (but directly "/projects/julius"), thats why it failed -.-)
[21:28] <slytherin> :-)
[21:29] <mocha> hello, any motu's here that can talk about Alsa?
[21:29] <mocha> I wanted to know if Alsa 1.0.17 can get backported to Hardy
[21:30] <joaopinto> well, it's my second time trying to upload a package into Ubuntu, I will try with the ML, I noticed you don't like to see repeated requests here (neither I like to repeat)
[21:30] <mocha> anyone?
[21:31] <mocha> the reason I bring this up is because Alsa 1.0.17 fixes a lot of bugs with Intel HDA such as mixer settings and low volume issues
[21:32] <mocha> I will probably install it manually but don't really like to do that with critical system files, modules, etc
[21:32] <laga> mocha: try #ubuntu-devel
[21:32] <laga> mocha: motu isn't really responsible for kernel stuff
[21:32] <mocha> I was just there, they told me to come here!
[21:32] <jpds> laga: Err, I told him to come here ;-)
[21:32] <laga> haha.
[21:33] <mocha> heh
[21:33] <jpds> laga: Due to backports being more motu stuff.
[21:33] <laga> there is a linux-backports-modules packages.
[21:33] <mocha> should I just file a bug report then?
[21:33] <slytherin> geser: if you got time for an ack, bug 251973
[21:33] <laga> linux-backports-modules-hardy - like this package. but i never used them
[21:33] <jpds> mocha: at bugs.launchpad.net/hardy-backports .
[21:34] <mocha> okay, I think I'll do that then, thanks
[21:34] <slytherin> jpds: backports is not motu stuff. there is separate team for backports
[21:35] <mocha> slytherin: whom?
[21:35] <jpds> slytherin: I know. But I think -motu would be a better place for it than -devel.
[21:36] <slytherin> jpds: still no. alsa is core package. May be the bug fixes he is specifying will land in -updates. So -devel is right channel for discussion.
[21:36] <slytherin> mocha: I don't know the members. Better discuss this first in -devel if it is possible to get these fixes in -updates
[21:36] <mocha> well I could go back there then and see if anyone has any pointers
[21:45] <nhandler> The include lines that I added to debian/rules for cdbs are preventing me from building the package. I get this error "cp: cannot stat `./usr/include/skstream-0.3/skstream/sasproto.h': No such file or directory         dh_install: command returned error code 256"
[21:50] <jpds> nhandler: http://paste.ubuntu.com/30384/
[21:52]  * NCommander bitches about how some women hit my car
[21:55] <directhex> badly?
[21:59]  * slytherin leaves for some sleep
[22:04] <nhandler> jpds: The package I am adding the cdbs patch system to is skstream. It contains the libskstream-0.3-dev package (It also has the sasproto.h file). So I am a little unclear why adding the include lines to debian/rules would stop it from building.
[22:13] <RainCT> debian/rules:13: *** missing separator.  Stop.    what does that mean?
[22:14] <NCommander> RainCT, means you got spaces instead of tabs usually
[22:14] <RainCT> NCommander: no, I've tabs (but tried with 4 and with 1 spaces, too)
[22:16] <RainCT> ok, yea it were spaces, now it works
[22:17] <RainCT> but it should have had tabs on the first try.. strange
[22:17] <RainCT> NCommander: thanks
[23:10] <nellery> warp10, ping
[23:11] <warp10> nellery: pong
[23:12] <nellery> warp10, hi, you commented on the reports I submitted patches for
[23:12] <nellery> and told me to report them to Debian
[23:12] <nellery> do I keep the maintainer as ubuntu-motu?
[23:12] <warp10> nellery: please, no: that's an ubuntu-specific change
[23:13] <nellery> alright
[23:13] <Laney> nellery: You generally just submit parts of your ubuntu debdiff.
[23:13] <warp10> nellery: they just need the patch itself, without changelog modifcations too
[23:13] <nellery> warp10, I see
[23:13] <Laney> There's a submittodebian tool in (I believe) ubuntu-dev-tools which helps when reporting changes to Debian.
[23:14] <nellery> Will you able able to review it to make sure it's all good?
[23:14] <Laney> yep
[23:14] <nellery> thanks!
[23:15] <warp10> nellery: remember to regularly check the bug status on debian: if they are not fixed in a reasonable time, feel free to resubscribe u-u-s. :)
[23:15] <nellery> warp10, alright... I submit this to launchpad.net/debian?
[23:16] <warp10> nellery: no: bugs.debian.org
[23:16] <nellery> warp10, ah, ok
[23:17] <warp10> nellery: Debian BTS is very different from launchpad and uses emails to manage bugs.
[23:17] <warp10> nellery:  you may want to check https://wiki.ubuntu.com/Bugs/ReportingToDebian and https://wiki.ubuntu.com/Bugs/Debian/Usertagging too
[23:17] <directhex> which isn't neccessarily evil, it's just different
[23:18] <directhex> control@bugs is a nice interface if you're used to dealling with a lot of mail
[23:18] <nellery> so once I've made the changes to the debian/control file
[23:18] <nellery> how do I make the patch?
[23:20] <warp10> nellery: diff -ur file.old file.new > patch
[23:21] <directhex> yay for diff
[23:21] <nellery> warp10, what should file.old/new be replaced with?
[23:22] <nellery> the directory?
[23:23] <warp10> nellery: the directory, or just the control file, depending on what you need to diff. In this case, comparing debian/control should be enough
[23:25] <warp10> nellery: sorry, I have to go. If you have more question, please ask, someone will help you. :)
[23:26] <nellery> warp10, alright, thanks very much for your help!
[23:26] <warp10> nellery: my pleasure, and thank you for your contribution!
[23:26] <warp10> 'night all!
[23:37] <nellery> Laney, here's the patch
[23:37] <nellery> http://paste.ubuntu.com/30417/
[23:37] <nhandler> I am trying to add a cdbs patch system to the skstream package. I added the required include lines to debian/rules. But now, when I go to build the package, I get this error "cp: cannot stat `./usr/include/skstream-0.3/skstream/sasproto.h': No such file or directory         dh_install: command returned error code 256" Does anyone know how to fix this?
[23:39] <Laney> nellery: I think you might need to make it from one directory up
[23:39] <Laney> (so that the file name in the patch is debian/control instead of just control)
[23:39] <nellery> Laney, I see
[23:40] <Laney> but other than that, looks good
[23:40] <nellery> do I need to create a second control file to compare it with?
[23:41] <Laney> Just do what you did to make the first patch
[23:41] <Laney> (of course, the submittodebian script would do this for you ;)
[23:41] <Laney> nhandler: That package doesn't seem to use cdbs. I'm not sure you can use simple-patchsys in this case
[23:42] <nhandler> Laney: The package currently has no patch system. I am attempting to add one
[23:42] <Laney> nhandler: Yes, but I think that simple-patchsys requires the package to use cdbs in the first place, which this one doesn't
[23:43] <Laney> So I'd try another one (my preference is quilt)
[23:44] <nhandler> When I asked about adding a patch system earlier, jpds said I could just add the include lines to debian/rules, and I would be fine
[23:44] <nhandler> Laney: I have no preference about what patch system I use. I just need some docs about _how_ to add it
[23:45] <Laney> nhandler: http://pkg-perl.alioth.debian.org/howto/quilt.html#3__integrating_within_package_build_process
[23:45] <Laney> This is a good page on quilt
[23:45] <Laney> Make sure to build-dep on quilt
[23:47] <nhandler> I still wish I knew why the other patch system wouldn't work
[23:48] <Laney> I already told you
[23:48] <Laney> and so did jpds earlier
[23:49] <Laney> 25/07 20:19:09 <jpds> nhandler: If you are using CDBS, I suggest using simple-patchsys.mk
[23:49]  * nhandler is tired
[23:51]  * jpds hugs nhandler and Laney.
[23:52] <jpds> nhandler: Got it to work?
[23:52]  * RainCT wonders if there's a "how to request package removal" document on the wiki
[23:53] <nhandler> jpds: Not yet. I'm going to try quilt
[23:53] <jpds> RainCT: File a bug on LP and subscribe the ubuntu-archive team, giving a reason why the package should be removed.
[23:53] <RainCT> jpds: I know :)
[23:54] <RainCT> ah yes, it's on https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive
[23:54] <jpds> nhandler: What was the problem with simple-patchsys?
[23:55] <RainCT> I was just wondering because I reminded of the guy who got angry on the mailing list because his app was synced from Debian :P
[23:56] <jpds> nhandler: Can you pastebin your debian/rules file?
[23:56] <Laney> I'm a bit concerned that his first thought was to use licensing to stop us from using it
[23:57] <nhandler> jpds: Give me one second. I want to try one thing first
[23:58] <nhandler> It worked! I had to remove this line "include /usr/share/cdbs/1/rules/debhelper.mk"
[23:59] <jpds> Does the binary still build?
[23:59] <nhandler> Yes. The binary builds.