[00:00] Awsoonn, no... you have to call it, no matter what patch system you use (I think it applies for every). [00:00] how / when should it be called? [00:00] which patch system you use? [00:01] I'm trying to make a change to apt [00:01] so, I don't know [00:02] 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] Awsoonn, ^ [00:03] There is also a 'what-patch' script that you can run to figure out the patch system that is being used [00:03] nhandler, that's useful :) [00:04] greg sees neither [00:04] grep** [00:04] Awsoonn, try with nhandler's advice... [00:05] nhandler: what package is what-patch part of? [00:05] Awsoonn: ubuntu-dev-tools [00:08] $ what-patch rules [00:08] unknown patch system [00:09] Just type 'what-patch' [00:09] I didi [00:09] but it says "unknown patch system" [00:10] That is strange. [00:10] 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] I thought so at first too, but it kinda makes sence [00:11] the patches dir is empty and it is at version ubuntu3 [00:11] maybe you can check with mvo. Seems like he does a lot of maintenance in apt. [00:11] of cource, when he gets around... [00:12] :) [00:13] 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] 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] norsetto: the problem is not building nvidia-cg-toolkit, it's installing it :) [00:14] 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] smagoun: I don't sleep much, but you've caught me :) I presume you've already checked your shlibs and symbols files? [00:15] persia, I think norsetto left a while ago... [00:16] Jazzva: quite possibly :) [00:16] 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] Then you publish a package from that other branch... [00:17] That would be basic way... [00:18] 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] I hope I wasn't too much confusing :) [00:21] Awsoonn, take a look at 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] I think I get in *slow nod* or at least I'm starting to :) [00:24] That's great :) [00:24] bzr is cool once you get used to it :) [00:25] anyway, I'm off now. Good luck with that patch :). [00:29] anyone knows which python package provides gksu module ? [02:19] Heya gang [02:29] Heya [02:29] Hi cody-somerville [02:29] Heya bddebian [02:29] Hi ScottK-laptop [02:30] wow [02:31] Lots of polotiks today [02:31] polotiks? Where? [02:46] NCommander> Congratulations on codeblocks's acceptance! [02:47] Thank you :-) [02:47] LucidFox, you made it possible ;-) [02:47] It feels to finally get that into the archive [02:47] (any reason you gave up trying to package it?) [02:48] pfft. [02:48] something wrong cody-somerville? [02:49] * cody-somerville clearly invested no time in helping get CodeBlocks into the archive :P [02:49] heya [02:49] cody-somerville: Well, you didn't upload a candidate to REVU, did you? [02:49] NCommander> He has a point :) [02:49] * NCommander kisses cody's feet and worships him :-P [02:50] * cody-somerville struts. [02:50] Thank you, thank you. [02:50] NCommander, Good work :) [02:50] Modest, aren't we :-P [02:50] Thank you ;-) [02:50] I also tackled a great evil [02:50] CDBS multibuilds [02:50] Ewwww [02:50] Ewww [02:50] And this one came with extra evil [02:50] Ewwww [02:50] Python modules built with configure scripts! [02:51] I scared him off === Majost__ is now known as Majost [04:23] * NCommander laughs evilly === nhandler is now known as nhandler_AFK [04:34] when pbuilder is done, where does the output go? [04:34] Awsoonn, /var/cache/pbuilder/results [04:34] where you've set it to go. [04:34] Or something like that [04:34] usually, ^ [04:35] -s [04:35] * NCommander hacks on REVU to remove the requirement of asking an admin to keysync [04:36] :D thank [04:36] s [04:42] emgent@amnistia:~$ sudo chroot /home/emgent/.chroots/intrepid/ /bin/bash [04:42] [sudo] password for emgent: [04:42] root@amnistia:/# apt-get [04:42] bash: apt-get: command not found [04:42] root@amnistia:/# [04:42] nice! :-) [04:42] emgent: What about dpkg? [04:43] dpkg is in. === asac_ is now known as asac [04:44] StevenK: http://pastebin.ubuntu.com/30187/ [05:03] Bug #224460 [05:03] Launchpad bug 224460 in apt "apt-cache shows misleading dependency information" [Medium,Confirmed] https://launchpad.net/bugs/224460 [05:04] should apt-cache show conflicts under dependantcies? or is this a new feature being requested? [06:37] 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] jmarsden: only add intrepid deb-src [06:38] That's what I was thinking about... it's safe to do that? Cool :-) [06:38] There aren't inherent dangers of adding the repos, but what you do with it [06:38] jmarsden: If you're looking to backport stuff, see !prevu [06:41] 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] 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] kees: around? Did you get my mail? [07:11] white: It's 11pm where kees is. [07:16] hey StevenK [07:16] * StevenK waves [07:16] StevenK, mind taking a look at a blueprint and weighing in on it? [07:16] NCommander: Maybe later. [07:17] StevenK, busy I take it? [07:17] Distracted by $WORK and would rather not context switch [07:18] * RAOF likes the _distracted_ by work aspect. [07:20] lol [07:20] RAOF, how about you? [07:21] I could be persuaded to stop hitting myself with autofoo and do something else. [07:21] * Hobbsee hits RAOF with a brick [07:22] https://blueprints.edge.launchpad.net/revu/+spec/revu2 - my plans for the next revision of REVU ;-) [07:22] Hobbsee: Thank you. Just what I was after :) [07:22] hehe [07:22] * NCommander thanks Hobbsee [07:22] you're welcome :) [07:23] * NCommander is working out how to determine which key generated a signature on an upload [07:23] 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] (I also have the public keys) [07:24] er, what? [07:24] If I have a signed changes [07:24] What's the easiest way to see what key, assuming I have the public key, signed the changes? [07:24] 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] gpg --verify [07:24] Hobbsee, yeah [07:25] I just need to abuse that somehow to assiocate each upload with the LP login now [07:26] NCommander: Looks like a substantial revu improvement. You probably want to add a "run lintian against built packages" thing there, too. [07:26] RAOF, I was already going to do it [07:26] Once I can work out how to abuse gpg --verify in the way Ineed it to, we're in business [07:28] is anyone in here knowledgeable about framebuffer issues? [07:28] snadge, try ubuntu-devel [07:29] 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] 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] Key fingerprint = DB10 7BC2 1687 426E 7AC8 BB23 09F0 7408 C87F FC2F [07:31] NCommander: ^ [07:31] StevenK, you are in awesome in ways I can't describe :-) [07:32] NCommander: I'd suggest you don't plug that directly into REVU, but parse out the data you need :-) [07:33] 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] StevenK, doesn't appear to work for me, but you gave me an idea [07:36] NCommander: How doesn't it work? [07:36] 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] mcasadevall@blacksteel:~/tmp$ [07:36] NCommander: Run the bit in the $() first [07:36] NCommander: It should print out the key id [07:37] ID: Command not found [07:37] What did you run that time? :-) [07:38] Well, now I get this [07:38] mcasadevall@blacksteel:~/tmp$ gpg --verify codeblocks_8.02-0ubuntu1_source.changes 2>&1 | head -n 1 | cut -d\ -f14 [07:38] ID [07:38] mcasadevall@blacksteel:~/tmp$ gpg --verify codeblocks_8.02-0ubuntu1_source.changes [07:38] gpg: Signature made Thu 24 Jul 2008 05:40:54 AM EDT using DSA key ID 9DA2DA9B [07:38] So I know that is a valid signature [07:38] Ah. [07:38] Change that 14 to 15 [07:38] Your gpg --verify output is different to mine [07:38] That did the trick [07:38] Ew though [07:39] Having that be variable going to make scripting it a PITA [07:39] Actually, it doesn't. [07:39] and I doubt I could regex it [07:39] In Python, split it on whitespace and grab the last field [07:39] and then run fingerprint [07:39] BRILLIANT! [07:39] Right [07:39] You are awesome StevenK ;-) [07:41] * NCommander looks up how to use subprocess to get the stdio [07:42] pipe = os.popen('%s 2>/dev/null' % command) [07:42] output = pipe.read() [07:42] exitstat = pipe.close() [07:43] NCommander: ^ [07:44] I always used subprocess, but that works [07:45] Or foo = subprocess.Popen(blahblah, stdin=subprocess.PIPE) [07:45] input = foo.stdin.read() [07:45] subprocess ftw! [07:46] Don't I want stdout? [07:46] what does -sa do wrt debuild -S -sa [07:46] <\sh> moins [07:46] Awsoonn, includes the original source ball under all conditions [07:47] Thank you [07:48] NCommander: Sorry, yes, of course. [07:49] soren, obviously its not liking subprocess.PIPE [07:53] NCommander: How is that obvious? [07:55] 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] Unless ... [07:55] Oh [07:55] THat's lame [07:55] GPG prints on stderr [07:55] Right. [07:55] It sends your data to stdout and "the other stuff" to stderr. [07:55] * NCommander rolls his eyes [07:55] I didn't notice this was for gpg. [07:55] Wish that was documented better [07:56] yeah [07:56] Well, now I got the output in a variable [07:56] I just need an easy way to get the key ID [08:00] soren, well, thats pretty :-P [08:00] http://paste.ubuntu.com/30218/ [08:01] <\sh> argl..bug spam [08:01] bug spam? [08:02] 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] soren, I use DSA keys, so that isn't the best way to grab it [08:02] (I get verified DSA key ID) [08:02] NCommander: [line.split(' ')[-1] for line in input.split('\n') if 'gpg: Signature made' in line][0] [08:03] Yup, that works too :) [08:03] * soren <3 python [08:03] soren, I think my method is a little cleare [08:03] *cleaner [08:03] Its just a single split :-P [08:04] 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] :-P [08:05] Ok, you win [08:09] * NCommander works out how to glue the fingerprint back together [08:09] I have it in two variables like this [08:09] mcasadevall@blacksteel:~/tmp$ ./test.py [08:09] 869F DEB4 91C4 5F60 C767 [08:09] E62E A5B9 5304 9DA2 DA9B [08:11] ''.join(vara.split(' ') + varb.split(' ')) [08:11] Those aren't lists, those are actual strings [08:12] Er... Yes. [08:12] That's why I split them. [08:13] ok, just making sure ;-) [08:13] >>> a = '869F DEB4 91C4 5F60 C767' [08:13] >>> b = 'E62E A5B9 5304 9DA2 DA9B' [08:13] >>> ''.join(a.split(' ') + b.split(' ')) [08:13] '869FDEB491C45F60C767E62EA5B953049DA2DA9B' [08:15] Nice :-) [08:15] * NCommander is still somewhat of a python newbie [08:16] How do I get the total number of elements in a list, its not ntuples(), which I use for DB queries [08:17] See http://docs.python.org/tut/node5.html#SECTION005140000000000000000 (use the len function) [08:17] NCommander: why don't you use gpg --with-fingerprint --verify and grabs the "Primary key fingerprint" from the output? [08:17] geser, cause I didn't know that existed ;-) [08:21] NCommander: Did you look at http://py-gnupg.sourceforge.net/ -- might be overkill, might help... a GPG interface module... [08:23] http://paste.ubuntu.com/30221/ - can someone figure out what I'm doing wrong? [08:23] (its likely something very stupid) [08:27] NCommander: Heh :) [08:27] Last line: [08:27] * NCommander is stumped on the join [08:27] I keep get method not found [08:28] soren, http://paste.ubuntu.com/30224/ - here's the low fat version [08:28] - fingerprint.join(fingerprint_part1.split(" ") + fingerprint_part2.split(" ")) [08:28] + fingerprint = fingerprint.join(fingerprint_part1.split(" ") + fingerprint_part2.split(" ")) [08:29] wooohoo [08:29] It works [08:29] Expect I got a newline at the end [08:29] Right. [08:30] There [08:30] Now I got it working [08:30] You split on "Key fingerprint", so each of the parts might contain a linefeed. Linefeeds are not special in that context. [08:30] http://paste.ubuntu.com/30225/ - ;-) [08:30] I got it [08:30] Thank you soren [08:30] np :) [08:31] I'm amazed at how awesome python is [08:38] NCommander: a little bit shorter: http://paste.ubuntu.com/30226/ [08:39] geser, awesome [08:55] Good morning. [09:21] hello, I am looking to do a few backports for hardy, i've already backported subversion 1.5 [09:22] would it be worth contributing back the builds? [09:24] morning everyone [09:24] Hi huats [09:26] morning geser [09:28] incorrect: File a bug, describe the changes you did, probably add a debdiff. [09:49] hey murrayc_ [09:49] sorry to bother [09:49] hi geser [09:50] I send you an email to have your opinion on the gnome-lirc-properties update :) [09:50] can we talk about that a bit ? [09:55] Hi slytherin [09:56] geser: are you free? need sponsorship for two packages. One is fix for FTBFS and other is upstream version update. [10:02] slytherin: not really, are both in the u-u-s queue? I'll try to look at the queue later today [10:03] geser: yes both of them are [10:18] huats: I was investigating. I will reply now. [10:18] murrayc_: oh ok :) [10:18] murrayc_: thanks :) [10:19] murrayc_: take your time ... there is no rush... [10:19] but it is true that your feedback will be much appreciated [10:22] slytherin> fop has hit the archive! [10:22] 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] (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] is it being planned for official hardy-backports, or are you juest testing? [10:50] 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] Sikon: Of course the fix was ridiculously simple. We were just looking at wrong places. [10:52] \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] \sh, i agree fully, which is why i run my ppa for mono packages ;) [10:53] \sh, not that my packages every fail to be great & justwork, of course... [11:09] nhandler_AFK: ping [11:13] Can anyone comment on bug 223466. I guess archive admin need to be subscribed instead of u-u-s. [11:13] Launchpad bug 223466 in xmms-openspc "Remove xmms-openspc from repository" [Undecided,Confirmed] https://launchpad.net/bugs/223466 === nhandler_AFK is now known as nhandler [12:03] Hi slytherin [12:07] 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] 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] murrayc_: I just look at your bug [12:15] (I mean at your answer) [12:16] would you agree if I update the package to the 0.27 release [12:16] waiting the lirc update ? [12:17] 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] huats: Sounds good. Thanks. [12:44] murrayc_: ok [12:45] I'll do that [12:45] thanks for requesting the 0.84 btw === nhandler is now known as nhandler_AFK [13:05] hi all [13:05] someone can review my package? http://revu.tauware.de/details.py?package=umit === RainCT_ is now known as RainCT [13:22] Hey guys, could someone review my package? http://revu.ubuntuwire.com/details.py?package=posterazor [13:23] It's built in my PPA: https://launchpad.net/~drebellion/+archive [13:25] does the revu mailinglist work? [13:28] tbutter, which mailing list? [13:28] NCommander: http://lists.ubuntuwire.com/listinfo/motu-reviewers [13:29] it has no new messages since 12.7., but it seems there are new comments and uploads on revu [13:29] it appears to work just fine [13:29] (and in my local REVU installation, sending email works) [13:30] this seems to be the latest post in the archive: http://lists.ubuntuwire.com/pipermail/motu-reviewers/2008-July/000979.html [13:31] http://revu.tauware.de/details.py?package=origami <- that package has comments from today and an upload yesterday === ember_ is now known as ember [13:31] i did not receive any mail since 12.7. either [13:32] tbutter, strange, I'll kick to admins to look into it [13:32] tbutter, if you could, please file a bug on LP [13:32] 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] StevenK, what bugs to you encounter? LP is still loads better then SourceFrak [13:34] tbutter, care to look at this spec https://blueprints.edge.launchpad.net/revu/+spec/revu2 and make suggestions? [13:35] NCommander: Check your tab completion. [13:35] what tab completion? [13:35] NCommander: The problem is its getting worse, not better. [13:35] ScottK/StevenK [13:35] Oh, whoops >.<; [13:35] * NCommander drinks caffiene [13:35] Sorry, I've been dealing with openid braindeadness [13:35] And parsing RDF documents [13:36] My mind is more fried then usual [13:36] NCommander: https://bugs.launchpad.net/revu/+bug/251816 [13:36] Launchpad bug 251816 in revu "no mails to motu-reviewers" [Undecided,New] [13:37] ScottK, you work for canonical, you can steal their red stapler and hold it hostage until they fix LP :-P [13:37] NCommander: No, I'm not a Canonical employee. [13:37] wow [13:37] I'm more gone then I realized [13:38] brb, super-sized caffiene [13:38] NCommander: My fix would be revert to the U/I they had a year and a half ago. [13:38] ScottK, you mean before the green one? [13:38] Needless to say, the developers of the current U/I aren't real excited about that kind of feedback. [13:39] I"m reminded the first time sourceforge changed its scheme [13:39] However, when I point out specific aspects of the way the curren U/I sucks, they accept that. [13:39] I keep getting told I'll get used to it and it keeps not happening. [13:39] Great [13:39] firefox committed suidice [13:40] So I'm thinking if I dedicate a month or two to nothing but pointing out specific crappage, it might get somewhere. [13:40] The last stable update seems to have broken it [13:40] Yup, firefox is broken [13:41] ScottK, I think I like the current UI over the green one [13:42] NCommander, firefox isn't broken -.- [13:43] DRebellion, its working now, but I had to restart X on the other machine before it started working [13:44] http://ubuntuforums.org/showthread.php?t=869249 - that's not good [13:45] It's actually ubuntuforums.org/* that is b0rken [13:45] maybe not [13:46] I think they are on the recieving end of a slashdotting [13:46] firefox is screwing me around, maybe it is broken [13:46] no, i get a database error on the mythbuntu sub forum.. [13:46] NCommander: the whole thing with borked Linux info is pretty standard for BIOSs. [13:46] * ScottK is kidding. [13:46] NCommander: The kernel doesn't actually pay a blind bit of notice to it. [13:47] 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] ScottK: oh, strike! [13:47] ScottK: and where's your resignation mail? [13:48] Sent it to the ML. [13:48] 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] ah yes, here it is. [13:48] * Hobbsee actually *quits* said team. [13:49] NCommander: I find it really confusing to manage stuff and I really can't deal with it. [13:49] ScottK, which list did it go to? [13:49] MOTU ML. [13:49] Gotta run. [13:49] Isn't there a MOTU-LP liaison to represent the MOTU voice? [13:50] I don't think I'm subscribed to that one >.<; [13:50] and i think you wnated "I give in" [13:50] Laney: yeah, but it hasn't been overly successful to date. [13:50] Hobbsee, can you CC that message to sonicmctails@gmail.com? (its not in the archives yet AFAIK) [13:50] it is [13:50] https://lists.ubuntu.com/archives/ubuntu-motu/2008-July/004273.html [13:50] Weird, it didn't pop up for me [13:50] * laga finds mailman archives unusable [13:51] NCommander: you probably needed to scroll down. [13:51] * NCommander shrugs [13:51] I just use google with mailman most of the time [13:51] * NCommander is currently working out a UI update for REVU [13:51] Hobbsee: Oh, perhaps the position needs to be given some structure then [13:51] Anyway, must dash [13:52] cya Laney [13:52] * Laney waves [13:52] 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] 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] Hobbsee, that's more what I meant [13:55] 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] you can? [13:55] Hobbsee, Yeah, actually found out about it coding OpenID [13:55] It was referenced in a bug reort [13:55] *report [13:55] heh [13:56] Go to your home page, then Edit Details [13:56] Second entry [13:56] 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] heh [13:57] I find LP works great for some things [13:57] LIke merging, and blueprints work great [13:57] i find blueprints horrible [13:57] And the bug tracker wreaks something fierce [13:58] mostly it looks like it's fire and forget. stuff is then written out in the wiki [13:58] laga, I don't bother with specifications, I just abuse the whiteboard [13:58] https://blueprints.edge.launchpad.net/revu/+spec/revu2 - having a nice dependency tree with branch assiocations just does it for me :-) [13:59] okay, that does look nice :) [13:59] laga, yeah [13:59] 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] NCommander: indeed, it's certainly got some nice stuff. [14:00] Bugzilla great for developers, but sucks for average users [14:01] 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] Unless Soyuez is controlled via LP [14:01] NCommander: subscribing multiple people, waiting for pages to load. [14:01] soyuz is controlled via LP, but doesn't usually break [14:01] well, not in that area, anyway [14:01]