[14:58] <eagles0513875> hey guys
[14:59] <eagles0513875> im setting up an ubuntu-mt channel how do i register it with you guys
[15:00] <nalioth> for malta, right?
[15:00] <eagles0513875> yep
[15:00] <eagles0513875> we have a wiki as well
[15:00] <eagles0513875> i can get you the link for it
[15:00] <eagles0513875> and also on launchpad
[15:01] <nalioth> please :)
[15:01] <eagles0513875>  https://wiki.ubuntu.com/MaltaTeam
[15:01] <eagles0513875> im on that list as well
[15:05] <eagles0513875> nalioth: is everything ok
[15:05] <nalioth> what do you do for the malta team, eagles0513875 ?
[15:05] <eagles0513875> me the linuxmalta.tk i provide kubuntu related support
[15:06] <nalioth> does the team want you to run the channel?
[15:06] <eagles0513875> nalioth: hope in ubuntu-mt channel there is the sean person who setup that pg u can talk to him on there if u like
[15:09] <eagles0513875> nalioth: to answer your question yes they do want me to set it up
[15:09] <LjL> https://wiki.ubuntu.com/IrcTeam/Coordination https://wiki.ubuntu.com/IrcTeam/CreatingChannels <- useful and important pointers
[15:09] <eagles0513875> ty LjL
[15:10] <eagles0513875> nalioth: is that a good to go to setup the channel?
[15:12] <LjL> eagles0513875: if the team owner is ok with that, you can setup the channel
[15:12] <eagles0513875> ok LjL
[15:18] <eagles0513875> nalioth: how do i get the ubotu into the channel
[15:18] <LjL> i'm afraid you don't, at the time being
[15:18] <LjL> the bot is overloaded
[15:18] <LjL> you can however create your own if you can host it
[15:18] <LjL> !botclone
[15:19] <nalioth> i just put ubot3 in there
[15:19] <eagles0513875> nalioth: ty
[15:19] <eagles0513875> nalioth: can i rename it
[15:19] <LjL> you can also request a locobot logging bot to admin at ubuntu hyphen eu dot org
[15:20] <nalioth> eagles0513875: you can make your own bot ( see ljl's link above )
[15:20] <eagles0513875> the 2nd one
[15:20] <eagles0513875> nm
[15:23] <[NikO]> what kind of feature you need on the bot ?
[15:25] <eagles0513875> nalioth: how do i correct this  [482] # You need to be a channel operator to do that when i run /MODE #ChannelName -mi command
[15:25] <eagles0513875> [NikO]: not sure yet but just in case i come up with a brilliant idea for a bot lol
[15:26] <eagles0513875> nalioth: its funny cuz im the one who created the channel
[15:26] <LjL> eagles0513875, you surely do need to be a channel operator to change modes
[15:26] <LjL>  /msg nickserv help
[15:26] <nalioth> eagles0513875: use the correct channel name?
[15:26] <LjL> err
[15:26] <LjL> i meant /msg chanserv help
[15:26] <eagles0513875> LjL: ya
[15:28] <eagles0513875> nalioth: welcome back to our channel same to u PriceChild
[21:51] <Pici> tell Altairs about wine
[21:51] <Pici> er
[21:52] <Pici> This isn't my ubottu window
[21:52] <Nafallo> Pici: you are right :-)


[08:20] <Unit193> topyli: You pinged out after I replied, di dyou see it?
[08:22] <topyli> Unit193: just looked it up at irclogs.ubuntu.com
[08:23] <topyli> i may be remembering this wrong then
[08:27] <topyli> indeed i see no logs for -ot. i wonder how we made any decisions back then when trolls complained about their bans in -ot. probably our own logs then. anyway, good health to you all!
[08:27] <Unit193> Toodles!
[09:28] <Flannel> -ot was never publicly logged.  Bantracker had logs/notes/etc, so we'd use those.
[20:08] <el> or we'd ask for trusted people's personal logs (usually other ops)


[14:42] <mbruzek> rick_h_: ping
[15:39] <rick_h_> mbruzek: quick pong
[15:40] <mbruzek> rick_h_: can jujucharms.com point at github bundles yet?
[15:41] <rick_h_> mbruzek: talk about it in germany?
[15:41] <mbruzek> rick_h_:  I will not be there.
[15:41] <rick_h_> mbruzek: ah, ok sorry thought you were.
[15:41] <mbruzek> I am guessing the answer is no
[15:42] <mbruzek> I want to know current abilities
[22:27] <lazyPower> rick_h_: ping
[22:28] <lazyPower> i know its close (if not after) EOD for you. can you peek at an ingest for me though? I've been waiting about an hour for some updates to a namespaced charm that haven't made it to the store yet :| it passes proof
[22:28] <lazyPower> thats all that required right? being /trunk, having valid metadata, and passing proof?


[11:30] <mitya57> teward, just list both as copyright holders
[13:29] <teward> mitya57: answered in -devel many hours ago, but thanks for the answer.  (Debian policy manual gave me that answer xD)


[09:32] <rbalint> ddstreet, yes, the plan is merging 242 from Debian instead of cherry-picking more changes
[11:54] <ddstreet> rbalint ah ok, well i'll just sru and leave eoan as is then
[12:37] <ddstreet> rbalint you mind if i push systemd to eoan to fix the FTBFS in the meantime, until it's updated to 242?
[14:08] <coreycb> sil2100: hi, did you happen to get a chance to look at those RM bugs?
[14:13] <sil2100> coreycb: sorry, got preempted last time and then forgot, picking them up now
[14:22] <coreycb> sil2100: no problem, thanks so much
[15:04] <sil2100> coreycb: ok, so I processed as many removals from the list as possible - I could not act on 2 of the bugs because the packages still had 'valid' reverse-dependencies
[15:04] <sil2100> Left some comments there
[15:05] <coreycb> sil2100: thanks i'll take a look
[15:30] <rbalint> ddstreet, feel free but i'd rather drop it from proposed since issues keep popping up due to missing patches for gcc9
[15:37] <ddstreet> rbalint the FTBFS is an upstream bug, the testcase overflows the stack, i'll fix it upstream first but it's trivial to fix in eoan as well
[15:38] <ddstreet> but, i can just leave eoan alone...just means nobody can build systemd for eoan until 242 is merged (and hopefully, it will build then)
[15:40] <rbalint> ddstreet, feel free to push the fix to eoan, too, i may not finish the merge today
[15:41] <rbalint> ddstreet, my point was that it may not be the last issue to fix before it can migrate
[15:41] <ddstreet> rbalint if you're merging todayish, i'll just stay out of your way
[15:43] <rbalint> ddstreet, i start today, but i think it will take a few iteration to polish it, so if you are fairly certain that this update gets it to release, (like built in on all arches and autopkgtest passes) then it is worth a shot
[15:44] <rbalint> ddstreet, santa_ also reported an issue, thus it is not only a testcase fix that's missing
[16:12] <santa_> ddstreet: FYI the issue I have seen is that _sometimes_ the systemd from proposed hangs on "systemctl start network-online.target". the autopkgtest LXD backend relies on this command, so it makes autopkgtest hang. I have inspected systemd's git and there's a number of changes in the part I believe is involved in the hang
[16:13] <santa_> rbalint: btw, whenever you have a package ready to test feel free to ping me and I will test as soon as I can
[16:18] <roaksoax> ir
[17:34] <ddstreet> santa_ have you opened a lp or upstream bug, and/or have dbg logs of it happening?
[17:35] <ddstreet> if you are confident it's already fixed upstream tho, probably easiest to just retest after the merge to 242
[17:39] <santa_> ddstreet: I'm not confident it's fixed upstream but the code involved changed
[17:40] <santa_> let me see if I can find a build log with the thing happening
[17:46] <santa_> http://tritemio-groomlake.duckdns.org/logs/knewstuff_5.60.0-0ubuntu1%2btritemio9_amd64-2019-07-19T21%3a16%3a10Z
[17:47] <santa_> ddstreet: ↑ just search "network-online.target" there
[18:01] <ddstreet> santa_ well network-online.target will definitely block for more than 60 seconds if it's having trouble actually setting up the nw
[18:01] <ddstreet> you sure that's not the problem?
[18:11] <santa_> ddstreet: when that happened I got into the cointainer and if I recall correclty, the thing was blocked ad-infinitum, even after the network was actually up
[18:11] <ddstreet> ah, well yeah that's bad then
[18:12] <ddstreet> santa_ did you happen to notice, in the container, and dbus errors?  i've seen 'lost' dbus messages that cause waiting systemd processes to never finish, in some autopkgtests https://github.com/systemd/systemd/issues/12932
[18:13] <ddstreet> you may need to turn on debug though, at least for dbus
[18:13] <ddstreet> hopefully the 242 merge will fix it, though :)
[18:16] <santa_> ddstreet: interesting. nope, I didn't check dbus thing. iirc I just checked the journal but I didn't see any ugly thing
[18:17] <santa_> in any case if the 242 merge doesn't fix it I would be glad to re-check with your help
[18:17] <santa_> I'm just a plain user wrt systemd XD
[21:13] <rbasak> Skuggen: mysql-8.0 FTBFS. Looks like some openssl changes since the PPA build. Please could you take a look?
[21:13] <rbasak> I don't know if it would be better to patch or bump to the latest microrelease if there's a fix upstream.
[21:13] <rbasak> If it's not difficult I think cherry-picking a patch would be less disruptive, and we can update later? What do you think?


[00:25] <micahg> has anyone tested blueman in xubuntu oneiric?
[00:55] <ScottL> what is blueman (obviously i haven't tested it)
[02:33] <charlie-tca> micahg: far as I know, no one has tested blueman because none of us have anything that uses bluetooth
[02:34] <GridCube> lol
[02:34] <GridCube> charlie-tca, :D good night mister
[02:34] <charlie-tca> Hello, GridCube
[02:35] <GridCube> tomorrow i think i can make some tests
[02:36] <charlie-tca> That would be great!
[02:37] <charlie-tca> We can use as many people testing as are able to test.
[02:37] <GridCube> :)
[02:37] <charlie-tca> Three or four days of installs can make you miss a lot of stuff
[02:38] <GridCube> I'm also learning how to make webformularies to save into mysql databases XD
[02:40] <GridCube> so in a couple of months my project will be on alpha :P
[02:42] <GridCube> well good night mister charlie-tca :)
[03:24] <micahg> ugh, will have to reply to him tomorrow
[06:01] <Unit193> Err... That softpedia says "Mousepad replaced Leafpad"
[06:03] <Unit193> pleia2: You done messed up ;)  Site says "Xubuntu has replaced gmd with lightdm" where it should say "Xubuntu has replaced GDM (or gdm) with (L)light(DM)dm"
[06:05] <raevol> Unit193: apologies if i am missing some sort of joke, but see: http://xubuntu.org/node/49
[06:06] <raevol> oh i see what you are saying about softpedia
[06:06] <Unit193> raevol: That's what I was checking
[06:06] <raevol> man i am always 2 steps behind here :P
[06:06] <Unit193> Na, I'm about the same. Second comment make sense?
[06:07] <raevol> are you correcting the capitalization?
[06:07] <Unit193> Not just that, gmd isn't anything afaik
[06:07] <Unit193> !info gmd
[06:08] <raevol> oooh
[06:08] <raevol> didn't catch that
[06:08] <raevol> Gnome Manager Display
[06:08] <raevol> hur hur
[06:08] <Unit193> It's a quick typo, but I think she be sleeping now :/
[06:09] <Unit193> That's about the first thing I noticed on screen, and my grammar is not the best...
[06:09] <raevol> i'm bad at cathing typos unless they're the really common kind
[06:10] <raevol> see, catching
[09:55] <Unit193> pleia2: You also need to link to the Beta1 download page, not A2 ;) ( http://cdimage.ubuntu.com/xubuntu/releases/11.10/beta-1/ )
[10:02] <Unit193> Dang I need to get this VBox working again...
[10:23] <astraljava> What's it not doing?
[15:52] <pleia2> Unit193: I didn't write the release announcement, I just published it ;)
[15:52] <pleia2> but fixed
[17:07] <Olbi> hello
[17:08] <Olbi> I have seen that Xubuntu 11.04 is downloading with update some components of Unity which isn't needed. Could we eliminate that form system?
[17:21] <astraljava> Olbi: What does "with update" mean=
[17:21] <astraljava> = == ?
[17:21] <Olbi> astraljava: today I had update thinderbird with unity integration, so strange :P
[17:22] <astraljava> Olbi: Xubuntu doesn't control individual packages, so if there's a bogus dependency, we can't do anything about it.
[17:23] <astraljava> Then it's a matter of filing bugs against that package, for removing dependencies that aren't needed exactly.
[17:25] <astraljava> On the other hand, if the integration package doesn't depend on unity, then what does it matter?
[17:25] <astraljava> It's just one cruft package.
[17:25] <astraljava> I think anyone can live with that.
[17:27] <Olbi> I only want know if there arent any other unnecessary packages :P
[17:29] <astraljava> Olbi: There's the issue with direct dependencies, and recommends. I think nowadays package managers install recommends by default, so for sure there will be unnecessary packages, for some.
[18:19] <Unit193> pleia2: You're the website person so I contacted you...
[18:20] <Unit193> astraljava: Crashes the computer when I try to open VBox
[20:44] <pleia2> knome: green light from stephanie for the splitting into different branches for theme and plugin
[21:06] <Unit193> Thanks for fixing the post :D
[21:08] <GridCube> so tests need to be updated to the test tracker or jus to the spreadsheet
[21:08] <GridCube> ?
[21:08] <GridCube> oh boy more than half of the image has changed since monday
[21:54] <Olbi|2> what is on 4 september? It is at pink color http://2tu.us/3dmh
[21:56] <GridCube> don't know
[21:59] <astraljava> Probably just the last day initialized so far. It's not a critical date for release schedule, anyhoo.
[22:01] <Olbi> 22 september is last beta :P
[22:01] <Olbi> maybe some1 do calendar for it?:P
[22:02] <Olbi> super, my xubuntu 64 bit beta1 is installing too long from LiveCD :P
[22:02] <astraljava> What does 'too long' mean?
[22:23] <GridCube> there's some troll on #xubuntu
[22:24] <GridCube> !report
[23:54] <GridCube> say that i want to propose an image to be added to the backdrop folder, what kind of propieties it should have? like licences and such?


[13:40] <yaili__> hello, can anyone give me a hand with some colour questions I have?
[14:38] <AlanBell> hi yaili__
[14:38] <yaili__> AlanBell: hi
[14:39] <AlanBell> what is up?
[14:40] <yaili__> AlanBell: I was wondering if you know if the Ubuntu orange (#dd4814) reads well on white?
[14:40] <yaili__> AlanBell: I can just run an automatic contrast checker test, but wanted to know if anyone had any complains independent from that
[14:47] <AlanBell> I have not heard specific complaints, it certainly isn't as bad as yellow on white
[14:48] <AlanBell> http://loco.ubuntu.com/teams/ is an example of using *far too much* of it
[14:49] <AlanBell> I think if used in moderation, and possible not as a body text colour then it should be OK
[14:49] <AlanBell> so bolder and bigger if possible for the orange
[14:51] <yaili__> AlanBell: I see
[14:51] <yaili__> thanks, AlanBell :)


[02:37] <kees> archive admins around?
[02:37] <kees> FAIL: ABI mismatch in lucid Updates: 33 != 32 (linux-meta <IP_ADDRESS>.39 vs linux-backports-modules-2.6.32 2.6.32-32.32)
[02:37] <kees> FAIL: ABI mismatch in lucid Updates: 33 != 32 (linux-ports-meta <IP_ADDRESS>.25 vs linux-backports-modules-2.6.32 2.6.32-32.32)
[02:37] <kees> slangasek: around to fix this? ^^
[02:37] <slangasek> kees: hrm
[02:38] <slangasek> kees: I copied all those packages over together; did I hit the publisher at the wrong time?
[02:38] <slangasek> kees: linux-backports-modules-2.6.32 | 2.6.32-33.33 | lucid-proposed | source
[02:39] <kees> slangasek: perhaps... this is why I've recommended doing everything except meta for 1 publisher cycle, then meta on the next cycle. I will re-run the check (this one was from cron)
[02:39] <kees> is there are archive-admin alias I can send email to? right now I just CC pitti on these warnings
[02:39] <slangasek> ah, I guess I may not have gotten that memo :)
[02:40] <slangasek> there's an ubuntu-archive mailing list
[02:40] <kees> okay, cool, looks like it was a publisher cycle split or something. the re-run check sees no problems.
[02:40] <slangasek> ok, good
[02:41] <kees> *whew*
[02:41] <kees> okay. thanks!
[02:42] <kees> slangasek: actually, wait... it's not in -security...
[02:42] <slangasek> is it supposed to be?
[02:42] <kees> slangasek: it should have gone to security (along with all ABI packages)
[02:43] <slangasek> ok; skaet asked me to copy it to -updates, wasn't sure what was meant to happen wrt -security
[02:43] <kees> slangasek: yes, the tracking bug (807175) shows "Security-signoff" as "Fix Released" which means "Promote-to-security" is Confirmed.
[02:43] <kees> both need to be done
[02:43] <slangasek> ok, copying
[02:43] <kees> see https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
[02:43] <kees> thanks!
[02:44] <kees> slangasek: you have now had a crash-course in kernel workflow publication. ;)
[02:44] <slangasek> so I see :)
[02:45]  * slangasek notes that the interface between this workflow and the pending-sru page leaves something to be desired
[02:46] <slangasek> copying done
[03:37]  * slangasek makes a face at d-shlibs
[04:10] <infinity> kees: There's the mailing list, there's also abusing members of ~ubuntu-archive in turn? :)
[04:11]  * persia has always been a fan of the archive-admin-of-the-day model
[04:11] <infinity> persia: That only works during work hours for said admin.
[04:11] <StevenK> Timezones tend to defeat that a bit.
[04:11] <infinity> persia: I doubt any of us want to sign up for 24h on-call.
[04:11] <infinity> Well, for 24h in a row, that is. :P
[04:11] <infinity> But we get good coverage between many of us.
[04:12] <persia> I suppose.  Most of the AAotD are generall cooperative as long as it's their day *somewhere*.
[04:12] <persia> y
[04:12] <micahg> infinity: I've never worried too much about hours when pinging the AA of the day :)
[04:12] <infinity> Often, but I wouldn't bank on it. ;)
[04:13] <persia> But asking the AAotD is better than randomly selecting someone from ~ubuntu-archive and abusing them
[04:14] <micahg> worse case, they say no, and you go find someone else
[04:14] <StevenK> I'd suggest not abusing them if you want to actually *do* something. :-)
[04:15] <lifeless> depends on the aaotd :P
[04:16] <infinity> persia: Sure, it was more of an "if the AAotD happens to be eating/sleeping/urinating" thing.
[04:16] <persia> infinity, And after checking the list, there's a significant number of listed AAotDs who don't generally do archive work during their working hours.  Not quite the majority, but getting close.
[04:16] <infinity> persia: Which some of us do. ;)
[04:16] <persia> If you want to use "us" in that context, go sign up as an AAotD :p
[04:17] <infinity> I was using "us" to refer to archive admins. :P
[04:38] <TheMuso> Can anybody clone a repo from gitorious? I am getting connection reset. Seems the website is ok though.
[04:39] <broder> TheMuso: same for me, though the http transport seems to be working
[04:39] <TheMuso> broder: Hrm right, thats certainly an option.
[04:41] <TheMuso> although that doesn't want to work with the repo I am trying to pull.
[04:41] <TheMuso> git://gitorious.org/qt-at-spi/qt-at-spi.git via http gives a fatal error.
[04:47] <TheMuso> Ah the http transport URLs are slightly different.
[05:08] <pitti> Good morning
[05:12] <ion> that.
[05:14] <pitti> cjwatson: nice! so that assumes that $PACKAGE is already apt-gettable, right? that's fair enough, I just wondered if it would be possible for testing to build it with a local deb
[05:14] <pitti> cjwatson: but I guess for that it could create a temporary file:// apt repo
[05:14] <pitti> cjwatson: but anyway, these are refinements I'm able to do :)
[05:15] <pitti> cjwatson: thanks!
[07:37] <dholbach> good morning
[09:08] <cjwatson> Daviey: mm, I don't know, commented on the bug to the effect that maybe Conflicts is too heavyweight - I'm not sure really
[09:10] <cjwatson> bdmurray: 442941 wiki> sorry, not yet, still on my to-do; I'm not sure I see how 349469 could be related to that
[09:11] <Daviey> cjwatson: thanks.
[09:12] <dholbach> @pilot in
[09:12] <cjwatson> pitti: heh, I abused --ppa a bit in my initial version for that, and created a temporary repository
[09:13] <cjwatson> pitti: it should be perfectly possible to support a local .deb; live-build supports that
[09:14] <cjwatson> pitti: I believe it works by dropping .debs into config/chroot_packages/
[09:14] <pitti> cjwatson: ah, so an extra --deb option would probably be handy
[09:15] <pitti> cjwatson: do you want to work on the script further, or do I take it from here?
[09:15] <cjwatson> boggle, that actually creates *and signs* a temporary repository with a temporary key
[09:15] <pitti> thorough :)
[09:15] <cjwatson> pitti: depends how fast you want it to happen :-)  I think I need to deal with the syslinux-themes-ubuntu packages
[09:15] <cjwatson> which is unfortunately not a five-minute job
[09:16] <pitti> cjwatson: OOI, why does that block local CD builds, but works with the official daily ones? isn't that also using live-build?
[09:16] <cjwatson> no, the official ones only use live-build for the squashfs, not for the entire iso
[09:16] <pitti> cjwatson: I think I'll need today for the remaining /run stuff, and release meeting etc., but I should have time to continue working on this stuff on monday
[09:16] <pitti> ah
[09:16] <cjwatson> how about I get this to the point where it can actually build workable images (possibly not today, I need to work on 10.04.3) and then hand it over to you?
[09:17] <pitti> so for testing it's sufficient, as I can just inspect the squashfs
[09:17] <cjwatson> right
[09:17] <pitti> cjwatson: sounds great
[09:17] <cjwatson> I did the bare minimum of making sure that it actually contained the defaults package and its dependencies
[09:17] <cjwatson> mostly I just wanted to check on the interface with you, before it gets published and set in stone
[09:17] <pitti> cjwatson: I need to implement some extra things into defaults-builder anyway for the one remaining thing in the qin spec which it doesn't support yet
[09:19] <pitti> cjwatson: your --ppa is really like "--apt-source", right? i. e. I could use it to point to a file:// mirror on an alternate CD, to avoid downloading the entire thing for each test run
[09:20] <cjwatson> well, live-build does its own caching
[09:20] <cjwatson> but yeah
[09:20] <pitti> ah, so much the better
[09:20] <cjwatson> I don't actually like the --ppa interface right now; special-casing stuff starting with 'deb' is a massive hack :)
[09:20] <cjwatson> but it was temporarily convenient
[09:21] <pitti> oh, sure; but hacking that is easy
[09:21] <cjwatson> I'd rather just support --ppa user/ppaname and have some other interface for extensions
[09:21] <pitti> *nod*
[09:21] <pitti> but it's great to have a script which does the live-build invocation right, it would have taken me quite a bit to figure that out
[09:22] <pitti> but it actually seems to be delightfully easy
[09:22] <pitti> seems all the hard work is already in livecd-rootfs
[09:29] <pitti> jhunt: hey James, how are you?
[09:32] <jhunt> pitti: hi! good thanks.
[09:33] <pitti> jhunt: part of the /run transition is the move from /dev/.initramfs/ to /run/initramfs
[09:33] <pitti> jhunt: we need a small change in upstart for this, in bug 810956
[09:34] <pitti> jhunt: we have a compatibily symlink now, so it shouldn't be broken, but it would be good if we could do the transition before the next lts
[09:34] <pitti> jhunt: it just affects one small part of the code, and is a simple string substitution
[09:35] <pitti> however, it would break stuff if you tried to backport the package to natty
[09:35] <pitti> so perhaps a more involved fix would be to check both directories and ignore /dev/.initramfs/ if it is a symlink?
[09:35]  * Riddell nudges barry into looking at https://code.launchpad.net/~jr/ubuntu-packaging-guide/fixes/+merge/67951
[09:36] <jhunt> pitti: sure, np. we could always get upstart to check for the existence of both directories and use the first it finds for safety.
[09:37] <pitti> jhunt: ah, then it should prefer /run/initramfs/, and fall back to /dev/.initramfs
[09:37] <pitti> that indeed seems to be safe
[09:37] <jhunt> pitti: sure. this whole chunk of code can of course go away once upstart has full state passing :)
[09:38] <pitti> jhunt: can you do this right in the upstream branch, or do you want me to go through the merge proposal/cherrypick steps?
[09:38] <jhunt> pitti: the upstream doesn't have this initramfs+pid file feature - it's Ubuntu-specific.
[09:38] <pitti> ah, handy
[09:40] <jhunt> pitti: I've assigned the upstart part of that bug to me and will try to look at that today/monday.
[09:40] <pitti> jhunt: thanks
[10:01] <Amoz> hi all :)
[10:08]  * Amoz hugs dholbach
[10:18] <apachelogger> cjwatson: is there going to be a germinate version that can handle kubuntu seeds branches being owned by kubuntu-dev soon?
[10:20] <cjwatson> apachelogger: why dodes germinate need to change?  you tell it where seeds live
[10:20] <cjwatson> *does
[10:20] <apachelogger> cjwatson: -S also works for bzr?
[10:21] <apachelogger> --seed-source= that is
[10:21] <cjwatson> apachelogger: yes
[10:22] <cjwatson> or you can just use the default non-bzr mirror which is the default
[10:22] <cjwatson> er, tautology, but YKWIM
[10:22] <cjwatson> the mirror at http://people.canonical.com/~ubuntu-archive/seeds/ points to kubuntu-dev for >= oneiric now
[10:23] <cjwatson> and has done for a month or so
[10:23] <apachelogger> ok, thanks :)
[10:33]  * dholbach hugs Amoz back :)
[10:33] <dholbach> Amoz, mvo uploaded your patch :)
[10:36] <mvo> thanks Amoz creating the patch
[10:36] <Amoz> dholbach, which one?
[10:41] <dupondje> Who maintains http://qa.ubuntuwire.com/ftbfs/ ?
[10:42] <dholbach> Amoz, sessioninstaller
[10:43] <dholbach> dupondje, geser and gaspa judging by the source
[10:43] <persia> dupondje, The ubuntuwire team.  I believe geser does most of the updates.
[10:47] <Amoz> dholbach, ah. speaking of bugs, I wish to find a small project (preferably C) where I can dig a little deeper than just spelling mistakes
[10:47] <Laibsch> anybody else having trouble with "sudo pbuilder-dist unstable create" on either lucid or natty?
[10:49] <Amoz> could also be python and such, just as long as I learn something about the debian eco system
[10:50] <dholbach> Amoz, you could try having a look at bugs tagged with "patch-needswork" - maybe there's a problem with an existing patch that just needs some fixing?
[10:50] <persia> Amoz, Have you looked at crash bugs?  Those tend to be small fixes most of the time, but interesting to investigate.
[10:50] <Laibsch> Amoz: are you more interested to package stuff or to code software?
[10:50]  * Laibsch winks at persia, 久しぶり
[10:52] <Amoz> Laibsch, packaging is new to me, and I'd love to learn how to package stuff. Even though I read manuals/tutorials, they rarely prepare one for the real world packaging errors =) However, I guess I'll do more good in the coding field for now
[10:52] <Amoz> persia, thanks, I will try to find some!
[10:52] <dupondje> geser: Would it eventually possible to add the newest debian version in the ftbfs page ?
[10:53] <dupondje> this way we can easly see if there is a new version in debian, which in alot of cases fixes the ftbfs
[10:53] <Laibsch> Amoz: Great.  I maintain a couple of packages and I think I lack some of the skills you seem to have.  We could learn from and help each other if you are interested to co-maintain packages.  private chat?
[10:53] <Amoz> dholbach, will investigate that too
[10:53] <dholbach> geser, do you track bugs for the ftbfs page somewhere?
[10:53] <Amoz> Laibsch, uuh, what skills do you refer to? I'm just a beginner ;)
[10:57] <Satoris> I try to upgrade from natty to oneiric alpha. The update manager starts but then fails with an error stating some packages can't be downloaded due to "403 forbidden". Should it work?
[10:58] <Laibsch> Satoris: try #ubuntu+1 channel
[10:58] <Satoris> Will do, thanks.
[10:59] <dupondje> I dunno if there is any chance of getting permissions to push a rebuild on launchpad ?
[11:00] <cjwatson> dupondje: the permissions for that are identical to upload permissions
[11:00] <dupondje> oh ok
[11:00] <cjwatson> dupondje: what package/version?
[11:00] <dupondje> https://launchpad.net/ubuntu/+source/4store/1.1.3-1ubuntu2
[11:01] <cjwatson> dupondje: so you're saying that simply retrying those builds will work now?
[11:01] <dupondje> yep
[11:01] <dupondje> just tried locally :)
[11:01] <cjwatson> dupondje: OK, retried
[11:01] <dupondje> thx
[11:01] <dupondje> going tru the ftbfs list now :)
[11:04] <cjwatson> pitti: could you have a quick look at my debian-installer upload to lucid-proposed?  skaet says we want the 2.6.32-33 kernel for 10.04.3
[11:08] <pitti> cjwatson: looks straightforward, accepted
[11:10] <geser> dholbach: not yet, I plan to try to move the code to the ubuntuwire project (after that filing bugs should be possible)
[11:11] <dholbach> geser, awesome
[11:12] <geser> dupondje: you mean to show if Debian has a newer version? code-wise it should be possible. Do you have any suggestion where to display it?
[11:14] <dupondje> geser: yea indeed, show if there is newer debian version. I would put it next to the ubuntu version?
[11:17] <persia> Maybe just have a small display indicator, which presents a link to the PTS if there is a new version?
[11:17] <persia> That page is already very information rich.
[11:17] <dupondje> or a color ?
[11:17] <dupondje> Think its just usefull to see quickly if there is newer version in debian
[11:18] <cjwatson> pitti: ta
[11:18] <persia> dupondje, Colour where: on the package name?
[11:19] <dupondje> persia: or on the PTS field ?
[11:19] <dholbach> jdstrand, were you happy with https://bugs.launchpad.net/ubuntu/+source/sox/+bug/809619?
[11:19] <persia> dupondje, Colour on the PTS field sounds reasonable.
[11:51] <dupondje> http://pastebin.ubuntu.com/644718/ => anyone has an idea ?
[12:00] <jhunt> pitti: I've got a fix for upstart+/run/initramfs in my stuff-and-nonsense ppa, but it might need a prod to get it built any time today :)
[12:01] <pitti> jhunt: a "prod"?
[12:01] <pitti> jhunt: ah, you mean PPA builders are congested?
[12:01] <jhunt> pitti: yeah :)
[12:02] <pitti> jhunt: there, that should be better
[12:03] <jhunt> pitti: I'm having some pbuilder issues over here (including a bug I just found relating to /run :) so would like to build it in the ppa.
[12:03] <jhunt> pitti: thanks
[12:03] <pitti> patch looks fine to me, thanks!
[12:27] <jdstrand> ls
[12:28] <jdstrand> dholbach: I was yes. I thought I uploaded it. apparently I forgot. let me do that now
[12:29]  * dholbach hugs jdstrand
[12:29] <mdeslaur> ls: cannot access .: No such file or directory
[12:30] <jdstrand> hehe
[12:30] <jdstrand> mdeslaur: you caught that huh? :P
[12:30] <mdeslaur> jdstrand: busted :)
[12:30] <jdstrand> :)
[12:31] <jdstrand> dholbach: while I have you. there is a work item for me: "coordinate with dholbach on developer initiatives and create a weekly or monthly list of packages 10-15"
[12:31] <jdstrand> dholbach: I worked on my other work item for developing a process to identify these
[12:32] <jdstrand> dholbach: and have decided to suggest 5 packages per week in our weekly meeting
[12:32] <dholbach> jdstrand, that sounds great
[12:32] <jdstrand> dholbach: I need to find another place besides the meeting minutes to have those
[12:33] <jdstrand> dholbach: is there somewhere that you would suggest?
[12:33] <dholbach> jdstrand, if you give me the link to them or mention them to me, I'm happy to put them into my weekly update about ubuntu development
[12:33] <dholbach> (ubuntu news, omg!ubuntu! and other places)
[12:33] <jdstrand> dholbach: cool. I think I can add them to our GettingInvolved page too
[12:34] <jdstrand> dholbach: thanks! :)
[12:34] <dholbach> sweet - just let me know and I'll include them
[12:34] <jdstrand> dholbach: expect to here from me on monday (our next meeting)
[12:34] <dholbach> excellent
[12:34] <jdstrand> actually, we can have these be 9 days.... you might here from me today again :)
[12:35] <jdstrand> s/here/hear/
[12:40] <jdstrand> dholbach: oh, one other thing, I wrote https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageSecurityUpdate and added it to https://wiki.ubuntu.com/PackagingGuide/Recipes. a) was that the type of thing you had in mind for packaging guide integration, and b) would you mind reviewing it for me?
[12:40] <dholbach> jdstrand, I'm happy to have a look at it, sure - I'll add a TODO item
[12:40] <dholbach> for the future it would be nice to get it into lp:ubuntu-packaging-guide
[12:41] <jdstrand> dholbach: ah, I was unware of that
[12:41] <jdstrand> dholbach: I might have missed it-- I looked at the Maintenance pages, but didn't see it
[12:41] <dholbach> but getting the content right is the most important thing :)
[12:41] <jdstrand> dholbach: shall I check it in now?
[12:42] <dholbach> jdstrand, it'd require a bit of reformatting (moin vs. ReStructured text)
[12:42] <jdstrand> dholbach: is moin autogenerated from the ReStructured text?
[12:43] <dholbach> no, at some stage in the future we want to retire the Wiki pages
[12:43] <jdstrand> I see
[12:43] <dholbach> http://people.canonical.com/~dholbach/packaging-guide/html/ is the current guide
[12:43] <jdstrand> well, I can check it in
[12:43] <dholbach> I think I even filed a bug for it
[12:43] <dholbach> if you don't mind doing it, I could review the MP
[12:44] <jdstrand> let's do it that way
[12:44] <dholbach> you are a hero
[12:45] <jdstrand> dholbach: heh
[12:45] <jdstrand> dholbach: so, this is what generates the pdf?
[12:46] <dholbach> html, pdf, epub and a whole lot of other things
[12:47] <jdstrand> dholbach: huh, the branch doesn't see to coincide with the pdf I downloaded yesterday
[12:48] <dholbach> oh?
[12:48] <dholbach> do you remember where you got the pdf from?
[12:48] <jdstrand> dholbach: well, yes, for example, "Welcome to the Ubuntu Packaging Guide
[12:48] <jdstrand> " is not in the introduction-to-ubuntu-development.rst
[12:48] <jdstrand> ah, it is in index.rst
[12:48] <jdstrand> ok, clearly this will take me a moment
[12:49] <dholbach> take your time
[12:49] <dholbach> thanks a lot already for getting the content together
[12:50] <jdstrand> dholbach: ok. I grepped for 'Recipes' (as is in the table of contents) and GnuPrivacyGuardHowto (which is in the 'Updating an Ubuntu Package
[12:50] <jdstrand> ' recipe), but couldn't find it
[12:50] <jdstrand> dholbach: where are the recipes?
[12:51] <dholbach> it's a different structure - let me for now just file a bug and review the wiki pages
[12:51] <jdstrand> dholbach: (sorry if I am being dense)
[12:51] <jdstrand> heh
[12:51] <dholbach> you're not, don't worry
[12:51] <jdstrand> dholbach: I'm happy to do the work :)
[12:52] <dholbach> ok - for now you could just make it a separate article and we link to it from the knowledge base and from other articles
[12:53] <jdstrand> ok, so something like 'update-package-security.rst' and then jam that into knowledge-base.rst
[12:53] <Laibsch> anybody else having trouble with "sudo pbuilder-dist sid create" on either lucid or natty? I need a Debian unstable build environment.
[12:53] <dholbach> exactly
[12:53] <jdstrand> I can do that
[12:53]  * dholbach hugs jdstrand
[12:53] <dholbach> awesome! :)
[12:53]  * jdstrand hugs dholbach
[12:53] <dholbach> alright, I'll take the dog for a walk now - let me know if there's anything else I can do
[12:55] <cyphermox> cjwatson: using libpipeline, how would I go about getting both stdout and stderr from the output of commands?
[12:56] <kenvandine> @pilot in
[13:09] <cjwatson> cyphermox: I think you need an extension to libpipeline.  Could you file a bug report describing what you need, and I'll add support for it?
[13:14] <cyphermox> cjwatson: sure, thanks
[13:29] <jibel> pitti, buxy , about bug 541595, a way I've been able to reproduce during a dist-upgrade was to modify update-mime to always exit 1 and cause a failure during a release upgrade.
[13:29] <jibel> pitti, buxy this made the trigger fail and cause the 'already installed' error
[13:30] <pitti> jibel: oh, nice
[13:30] <jibel> not a dist-upgrade, during a release upgrade
[13:30] <jibel> but that may work with a dist-upgrade too
[13:31] <pitti> shouldn't really matter; anything which triggers the dpkg error message should suffice to test the bug pattern
[13:35] <buxy> jibel: but there are other cases that will trigger this error (other than just a failing trigger)
[13:36] <buxy> Like this one recently: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/809223
[13:37] <buxy> and where there's no obvious error at all
[13:49] <pitti> buxy: hey
[13:49] <pitti> buxy: the pattern is in place, just need to find/run a local test to verify that it's working
[13:53] <buxy> pitti: I saw your mail, unfortunately I don't have one to provide you, I don't know if mvo got further since we discussed it but he had troubles reproducing it as well
[13:54] <tkamppeter> mpt, hi
[13:55] <mpt> hello tkamppeter
[13:57] <tkamppeter> mpt, I did not see anything of g-c-c starting s-c-p or parts of it. I updated the system several times this week, and now I updated again and what I get is the new g-c-c printer setup tool and no button to add a printer.
[13:59] <mpt> tkamppeter, ok, but at UDS you had a list of things that the g-c-c one didn't do.
[13:59] <mpt> tkamppeter, I don't know enough about each of them to report meaningful bugs about them, but you do. :-)
[14:00] <mvo> buxy: I have not looked into this paricular one, but apt never does dpkg -i directly, always unpack/configure. it might be that the ordering code is confused and its configuring it at the wrong spot (or too early)
[14:01] <tkamppeter> mpt, so the step of getting access to s-c-p in Oneiric is not started yet?
[14:01] <pitti> tkamppeter: still underway, yes
[14:01] <mpt> tkamppeter, my message wasn't about Oneiric. It's about 12.04 and 12.10 and so on.
[14:02] <mvo> buxy: actually this one looks like one of the apt recovery code kicked, I commented in the bug
[14:03] <tkamppeter> mpt, what you need from me now is a list of bugs to work through to make g-c-c having all features of s-c-p, so that someone can so-to-say rewrite s-c-p in C, as far as it is needed?
[14:03] <pitti> FWIW, that sounds like a step backwards to me
[14:03] <barry> pitti: ping
[14:03] <pitti> s-c-p is hardly performance critical, so the python overhead hardly matters
[14:04] <pitti> an exception is the daemon which always runs in the user session
[14:04] <pitti> hey barry; I'm talking, so I'm obviously here :)
[14:05] <buxy> mvo: what represents the grouping between Log started/Log ended ? is this not equivalent to a call to dpkg ?
[14:05] <mpt> pitti, I don't really care *how* the printer settings end up inside the System Settings window, whether that's by rewriting them or allowing Python panels or whatever else.
[14:05] <pitti> mpt: so you prefer keeping the control panel, as opposed to a unity lens?
[14:05] <barry> pitti: :)  hi!  do you have any good references for starting to learn about pygi and g object introspection?  i'm looking at bug 806574, which leads me there, and i need to learn more about it anyway.  well, *is* there any good references? ;)
[14:06] <mpt> pitti, I don't understand the question
[14:06] <mpt> What does this have to do with Unity lenses?
[14:06] <pitti> mpt: so right now we use the c-c shell, i. e. a window with all possible options
[14:06]  * brendand has the same question as barry
[14:06] <brendand> seems not well documented
[14:07] <pitti> mpt: in earlier releases we had the "System -> Preferences" menu instead; personally I preferred that, but in natty this was impractical due to the new unity
[14:07] <tkamppeter> mpt, I could report a bug for each feature, telling for what the feature is good for and how to visualize it/try it out?
[14:07] <pitti> mpt: but similar to the old menus which went into unity, the settings bits could move there as well?
[14:07] <mvo> buxy: a full operation of apt-get, this is why I'm puzzled, there is also no "commandline" information there, I wonder if its something like aptdaemon or packagekit that kicks in here actually violating some locking or something like this
[14:07] <mpt> tkamppeter, I think the g-c-c developers would find that very helpful.
[14:08] <pitti> tkamppeter: do you know what Tim thinks about this? it seems like an exceptional waste of developer time to port and bugfix s-c-p to a control center applet written in C..
[14:08] <tkamppeter> mpt, should I do these bug reports upstream or on LP?
[14:08] <mpt> tkamppeter, bugzilla.gnome.org
[14:09] <barry> brendand: indeed
[14:09] <pitti> barry: I recently wrote https://live.gnome.org/PyGObject/IntrospectionPorting which is a fairly detailled braindump
[14:09] <mpt> pitti, <mclasen_> we're actually working with twaugh to reasonable features shared between s-c-printer and the printer panel
[14:09] <barry> pitti: awesome, thanks.  i'll go digest that
[14:09] <buxy> mvo: maybe it would be useful to add which libapt user is generating the log indeed
[14:10] <tkamppeter> pitti, mpt, I am completely against rewriting the features of s-c-p in C. What I like to have is that the Python code of the s-c-p features gets something like a library or plug-in which various printer setup tools (also of KDE) can use.
[14:10]  * pitti shakes head.. that's what FOSS needs, rewriting everything that's alrady written in sensible languages in C..
[14:11] <pitti> barry: hmm, gtk_list_store_reorder() actually exists in C..
[14:11] <barry> pitti: yep, this code worked fine before the switch to pygi
[14:11] <mvo> buxy: yeah, we have a CommandLine tag for this in history.log now
[14:11] <pitti> barry: ah, there we go
[14:11] <mpt> tkamppeter, fair enough.
[14:11] <pitti> barry:
[14:11] <brendand> pitti - i've seen that, it seems the best resource available atm
[14:11] <pitti>       <method name="reorder"
[14:11] <pitti>               c:identifier="gtk_list_store_reorder"
[14:11] <pitti>               introspectable="0">
[14:12] <mpt>  So on the one hand we have language purity from developers of an OS that has ~0 users, and on the other hand practicality from an OS that does ~0 upstream development.
[14:12] <pitti> barry: so this needs to be fixed in GTK
[14:12] <barry> pitti: that was my suspicion based on something else i read.  where did you find that bit of xml?
[14:12] <brendand> if someone was a beginner to gtk completely they'd sort of need to mix that with another tutorial
[14:12] <pitti> barry: in the gir -- /usr/share/gir-1.0/Gtk-3.0.gir
[14:13] <pitti> brendand: so the fact that this part doesn't work is a bug, not a documentation issue
[14:13] <barry> pitti: thanks.  i'm sure there's a good reason why that's currently non-introspectable, but i don't know enough about this stuff yet.
[14:13] <mpt> tkamppeter, but even if that library existed, each of its features would still need to be exposed in g-c-c *somehow*.
[14:13] <brendand> pitti - sorry, i'm going off on a tangent here
[14:13] <dholbach> @pilot out
[14:14] <barry> pitti: interesting, i don't have that file
[14:14] <pitti> barry: libgtk-3-dev
[14:15] <mpt> pitti, I'm surprised you liked the old Preferences menu. :-) I regard the System Settings window as not perfect, but a massive improvement, for several reasons, including less scrolling and less closing of windows.
[14:15] <pitti> barry: my initial hunch is that it's because it passes an array of ints of unknown size
[14:15] <barry> pitti: ack.  /me apt-gets
[14:15] <pitti> mpt: I like being able to do windows + "mouse" to get to the settings I want
[14:15] <pitti> now, that already works today
[14:16] <pitti> but sometimes it's indeed useful to have a collection of all preferences
[14:16] <pitti> it's just that upstream control-center now makes this exceptionally har
[14:16] <mpt> pitti, there's no reason g-c-c can't be searchable, apart from a lack of planning
[14:16] <pitti> d
[14:16] <mpt> searchable from the Dash, I mean
[14:16] <pitti> mpt: it is
[14:17] <tkamppeter> mpt, so I will report all the features as separate upstream bugs and after that create a master bug which depends on all these bugs. In each bug I will also paste in a piece of text telling to not try to rewrite s-c-p in C or to freely invent this described functionality. I will also CC Tim Waugh and other people (tell me who) to all these bug reports to let them discuss and agree on a solution. WDYT?
[14:17] <mpt> pitti, so what do you mean by "makes this exceptionally hard"? (I'm in 11.04 right now, installed Ocelot on another partition yesterday)
[14:17] <pitti> mpt: my worries are that g-c-c has become pretty much a locked fortress now, and we aren't able to and don't want to rewrite all our configuration bits to be an upstream control center capplet in just a cycle or two
[14:18] <pitti> aside from the fact that this would be completely impractical
[14:18] <pitti> so it'll be a hack either way
[14:18] <mpt> pitti, rewriting them all in Nux and C++ would be even *less* practical!
[14:18] <pitti> mpt: c-c in 3.0/3.2 now forbids external/distro specific settings
[14:18] <pitti> mpt: ?
[14:18] <mpt> pitti, I know, I organized the UDS session about that.
[14:18] <pitti> mpt: and embedded panels pretty much require in-process code and C
[14:19] <pitti> mpt: who said we'd need to?
[14:19] <mpt> pitti, and it was Ubuntu's patch to override that which sparked the discussion about printer settings in #gnome-os this morning.
[14:19] <mpt> pitti, you did, by suggesting that they be a Unity lens.
[14:19] <pitti> I'm in favor of (1) being able to write settings bits in Python or other languages, and keep our stuff, as it also provides KDE frontends
[14:19] <mpt> yep
[14:19] <pitti> and (2) still being able to get a consoliated view of all settings apps
[14:19] <mpt> yep*2
[14:20] <pitti> but if upstream g-c- doesn't want us to add our own stuff, and we have this wonderful unity thing anyway, why not make a lens which shows all available settings things
[14:20] <pitti> pretty much like the old system -> prefs menu did
[14:20] <pitti> and get rid of the c-c shell window
[14:20] <pitti> which sticks out like a sore thumb from the session menu anyway
[14:21] <pitti> that doesn't require any reimplementation -- it's just showing all desktop files with a "Settings" category
[14:22] <mpt> pitti, because that would be punishing users (by making them open and close more windows) because of an implementation detail
[14:23] <pitti> how so?
[14:23] <tkamppeter> pitti, mpt, I also do not like to have "System Settings" in the "Off-Button" menu. As it moved to there I needed a certain time to find it and nearly reported a bug about disappeared System Settings, that about usability.
[14:23] <pitti> whether you open it through a lens or the shell, it's the same number of clicks?
[14:23] <pitti> my train station is coming up, back in ~ 30 mins
[14:24] <tkamppeter> pitti, mpt, what is a unity lens>
[14:24] <tkamppeter> ?
[14:27] <mpt> tkamppeter, it's a black overlay that covers most of the screen and presents things to search or launch
[14:27] <mpt> The things that appear if you click "Applications" or "Files & Folders" in the launcher are examples of lenses.
[14:29] <mpt> pitti, simple example. Every time you disconnect from AC power, the screen dims. You want to turn that off. You open the lens and choose "Power", but it isn't there. Eventually you figure out that it's in "Screen" instead.
[14:29] <mpt> pitti, with a lens, that would be : (1) open lens, (2) open Power, (3) close Power, (4) reopen lens, (5) open Screen, (6) close Screen.
[14:29] <mpt> pitti, with g-c-c, it's: (1) open g-c-c, (2) open Power, (3) click "All Settings", (4) open Screen, (5) close g-c-c.
[14:29] <tkamppeter> mpt, thanks. Such a thing, with a decent icon, not the standard magnifier, would make the system settings much easier to find.
[14:30] <mpt> pitti, the more settings you want to change at once, the greater the savings.
[14:31] <mpt> (It was even worse for the Preferences and Administration menus: partly because there were two of them, increasing the probability of errors, and partly because they were both submenus, increasing the cost of each error.)
[14:33] <tkamppeter> mpt, are the bug reports still needed? Or will we go away from this over-rigid System Settings on the Off button to a lens which let us continue to use any application?
[14:33] <mpt> tkamppeter, this has nothing to do with the Off button and nothing to do with lenses.
[14:34] <mpt> tkamppeter, yes, please report the bugs.
[14:34] <tkamppeter> mpt, if we switch to a lens, we should patch away the System Settings entry in the Off menu or let this entry also open the lens to avoid that users use inferior duplicates of the config tools.
[14:35] <cr3> barry: out of curiosity, have you heard about any problems importing psycopg2 on oneiric? ImportError: can't import mx.DateTime module
[14:35] <mpt> Somebody, please, give me something to bash my head against
[14:35] <cr3> barry: I'm about to try to reproduce myself, just curious beforehand
[14:36] <mpt> tkamppeter, this has nothing to do with the Off button and nothing to do with lenses.
[14:36] <pitti> mpt: actually, it's not totally unrelated to lenses
[14:36] <mpt> The g-c-c developers do not care about Unity at all, let alone lenses in particular.
[14:37] <pitti> mpt: as with a lens, we can easily have s-c-p itself instead of waiting for it to be NIHed in c-c
[14:37] <tkamppeter> mpt, I was only thinking about how in Ubuntu Linux system settings are presented the bnest way, easy to find and conserving the know-how which has made it into the tools in all the years ...
[14:38] <tkamppeter> mpt, NIHed?
[14:39] <mpt> tkamppeter, I am not involved in the design of Unity. I can explain (and just did explain) why settings shouldn't be in the Dash, but I can't guarantee they won't ever be there.
[14:40] <cjwatson> mvo: have you noticed bug 807715?
[14:42] <mvo> cjwatson: I have a look
[14:44] <tkamppeter> mpt, sorry, who is the right one to discuss with about the design decision of how System Settings tools are made available in Ubuntu?
[14:47] <Laibsch> Are all packages that FTBFS due to missing packages listed in http://qa.ubuntuwire.org/ftbfs/? I just tried to build isdnutils and oneiric is missing tcl8.3-dev
[14:49] <mpt> tkamppeter, JohnLea
[14:51] <pitti> mvo: did you see the question to you in bug 806559?
[14:51] <pitti> mvo: I started discussing this with Robert, but I'd appreciate your input which solution is better
[14:57] <mvo> pitti: sure, I have a look
[15:00] <Riddell> packaging guide reviewers:  https://code.launchpad.net/~jr/ubuntu-packaging-guide/fixes/+merge/67951 https://code.launchpad.net/~jr/ubuntu-packaging-guide/02-udd-introduction/+merge/68078 https://code.launchpad.net/~jr/ubuntu-packaging-guide/03-packaging-from-scratch/+merge/68099
[15:00] <nemo> I do wish archive.canonical.com was accessible over https...
[15:00] <nemo> Over here, I have 2 options for updating the ubuntu machines.  ftp protocol for mirrors that support, http for mirror.anl.gov that I fought to get websense whitelisted, or https.
[15:01] <nemo> unfortunately, none of those work for sun java which is only available from archive.canonical.com
[15:01] <nemo> hmmm. maybe archive.canonical.com supports ftp!
[15:01]  * nemo tests
[15:01] <nemo> nope :(
[15:02]  * nemo sighs and copies the file over manually
[15:10] <jdstrand> dholbach: ok, wrote fixing-a-bug-security.rst and proposed the merge just now
[15:12] <nemo> s/2 options/3 options/
[15:12] <dholbach> jdstrand, you rock - will have a look in a bit
[15:12] <jdstrand> dholbach: thanks! :)
[15:29] <cr3> barry: so, I can confirm there's a problem with python-psycopg2 on oneiric when importing mx.DateTime. I tried bzr branch lp:ubuntu/psycopg2; debuild; dpkg -i ../*.deb and that worked. trying pbuilder in case it builds the package differently
[15:30] <barry> cr3: interesting.  have you filed a bug yet?
[15:31] <cr3> barry: not yet, bugs.launchpad.net/ubuntu/+source/psycopg2 seemed sparse, so I'm waiting to gather more info to report
[15:35] <cr3> cyphermox: is there still a problem with pbuilder create for generating an oneiric tarball on oneiric?
[15:36] <highvoltage> 1/win 20
[15:36]  * cr3 doesn't have the patience to setup an sbuild environment :(
[15:38] <cyphermox> cr3: I haven't tried lately. like I said, I switched to using sbuild following mdeslaur's advice ;)
[15:39] <cr3> cyphermox: security > usability, I guess :)
[15:40] <cyphermox> no, it's not that. It's just as simple as pbuilder, really
[15:40] <cr3> cyphermox: have you read that wiki page? I feel asleep part of the way through :(
[15:41] <cyphermox> like I told you, don't bother with the umt script thing, just the first part of the wiki page; there's something like 2-3 files to modify/create and then you run the commands to build the chroots
[15:42] <cr3> cyphermox: can you remind me of the wiki page url again? google is returning this but this but I vaguely recall the page being different: https://help.ubuntu.com/community/SbuildLVMHowto
[15:43] <cyphermox> https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment
[15:44] <brendand> where do i find extra gobject typelibs?
[15:45] <brendand> looking for GUdev, it's not in /usr/lib/girepository-1.0
[15:45] <brendand> not sure about the package name
[15:46] <cyphermox> brendand: gir1.2-gudev-1.0 maybe
[15:46] <barry> cyphermox, cr3 i use sbuild almost exclusively too, though occasionally pbuilder.  that security team page rocks
[15:46] <dholbach> Last day of UDW (https://wiki.ubuntu.com/UbuntuDeveloperWeek) starting in 15 minutes in #ubuntu-classroom
[15:46] <brendand> cyphermox - in general is it gir1.2-*?
[15:46] <cyphermox> it is
[15:48] <cr3> barry: I'll give sbuild a try once again and I reported bug #811115 for now
[15:55] <pitti> cjwatson: ah, seems I misread the original numbers: the old ibus-pinyin didn't take 15 MB, but just 1.5; apt-get install ibus-pinyin additionally pulls in pinyin-database (14 MB), but that wasn't on the CDs
[15:56] <pitti> so moving to sunpinyin actually caused a 17 MB increase, not 4
[15:56] <barry> cr3: i'll take a look after lunch
[15:56] <cjwatson> pit	ah, wow
[15:56] <cjwatson> pitti: ^-
[15:56] <pitti> cjwatson: so I guess we'll go back to pinyin for the standard CDs if we need to retain Chinese support there, and only use sunpinyin for the Chinese Edition/check-language-support
[15:57] <cjwatson> that seems the only practical choice, from what you've said, yes
[15:57] <cjwatson> (of course note that the installer uses check-language-support ...)
[15:57] <pitti> cjwatson: it seems fine for downloading if you are online
[15:58] <pitti> but ibus-pinyin with ibus-pinyin-db-open-phrase at least provides a reasonable offline fallback
[15:58] <cr3> barry: I'm hoping to have more information or suggest a patch once I get my sbuild environment running
[16:12] <pitti> good night everyone
[16:26] <bdrung> jamespage: eclipse ping
[16:30] <SpamapS> Copyright: 1979-2007, MySQL AB
[16:30] <SpamapS> Whoa.. how long have they actually existed?! :-P
[16:33] <slangasek> SpamapS: heh
[16:33] <SpamapS> thats on a one line shell script.. :-P
[16:33] <SpamapS> one line, 684 chars long :-P
[16:34] <slangasek> clearly someone is confused about copyright :)
[16:34] <SpamapS> heh, I think maybe by now they can drop it.. 'msql2mysql.sh'
[16:37] <SpamapS> Heh.. I'm not so sure licensecheck2dep5 is helping here.. :-P
[16:38] <SpamapS> I think its accurate.. but.. a 3000+ line copyright file is probably a bit too detailed.
[16:38] <slangasek> licensecheck2dep5?
[16:38] <slangasek> where's that from?
[16:38] <SpamapS> slangasek: its in cdbs.. scheduled for appearance in devscripts at some point
[16:38] <slangasek> in cdbs!
[16:38] <broder> licensecheck2dep5> whoaaaaa
[16:39] <broder> that's awesome
[16:39] <hyperair> that thing should go into devscripts
[16:39] <slangasek> no, it clearly isn't, it should do something more sensible than generating a 3000+ line copyright file :)
[16:39] <SpamapS> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472199
[16:39] <hyperair> slangasek: it does a great job at summarizing stuff.
[16:40] <SpamapS> MySQL *is* extremely detailed in their files
[16:40] <hyperair> i usually start from licensecheck2dep5, and then trim stuff down
[16:40] <hyperair> manually
[16:40] <SpamapS> 3781 ../copyright
[16:40] <SpamapS> hyperair: I think it MIGHT be a little bit crackheaded in this case. ;)
[16:41] <slangasek> is it 3000+ lines of copyright holder names, or is it 3000+ lines of silly per-file statements because it doesn't use sensible heuristics for aggregation?
[16:41] <SpamapS> Per file
[16:41] <SpamapS> There are only 2 or 3 copyright holders.. since MySQL has a CLA
[16:41] <hyperair> SpamapS: i'd rather start from the licensecheck2dep5 output than from licensecheck's raw output
[16:42] <SpamapS> Sun, FSF, MySQL AB, Oracle, and Innobase
[16:42] <slangasek> SpamapS: right; so I consider that a significant bug in the tool
[16:42] <hyperair> CLA?
[16:42] <SpamapS> Oh and NetBSD since they embed libedit.. how lovely
[16:42] <slangasek> because it does exactly what the dep5 critics say they don't want to have to deal with on their packages :)
[16:42] <SpamapS> hyperair: Contributor Licensing Agreement.
[16:42] <hyperair> ah i see
[16:43] <SpamapS> Actually I think its simpler, they just require assignment.
[16:43] <hyperair> that's just CA
[16:43] <bdmurray> cjwatson: I'd rather not do this but I think memtest could use a source package hook refiling some bugs about grub
[16:43] <hyperair> copyright assignment, is it not?
[16:43] <hyperair> similar to canonical's
[16:43] <SpamapS> slangasek: agreed, it should be able to look at the massive chunk of files and use globbing.. and year heuristics
[16:43] <slangasek> yes
[16:44]  * SpamapS hacks a bit on it
[16:44] <slangasek> there's probably enough information there to pick a "default" copyright statement for the upstream source
[16:44] <SpamapS> slangasek: the most common gets the * .. ;)
[16:45] <slangasek> SpamapS: already?
[16:45] <slangasek> yuck
[16:45] <SpamapS> slangasek: no, I was thinking of doing that
[16:45] <slangasek> ah, yes
[16:55] <broder> how much of the variation is from differences in the exact copyright statement, as opposed to the license?
[16:55] <broder> (i.e. differences in year or something)
[16:57] <SpamapS> broder: a lot
[17:04] <kenvandine> @pilot out
[18:13] <barry> cr3: bug 811193
[18:15] <cr3> barry: noticed the email, I really like the dh_python2 for free part :)
[18:15] <barry> cr3: indeed! :)
[18:45] <vikapi> using kubuntu11.04..my rkonq is crashing quite frequently.
[19:03] <micahg> vikapi: you probably want #kubuntu
[19:07] <vikapi> micahg: thought wud report to developers.
[19:09] <micahg> vikapi: then you probably want #kubuntu-devel
[19:09] <SpamapS>   3781 ../copyright
[19:09] <SpamapS>   2567 ../new.copyright
[19:09] <SpamapS> Heh.. progress
[19:09]  * SpamapS plods on
[19:20] <bdmurray> Is there somebody who wouldn't mind sponsoring openssh for me?  I just made a change to the apport package hook.
[19:21] <bdmurray> http://people.canonical.com/~brian/tmp/openssh_5.8p1-4ubuntu2.debdiff
[19:24] <infinity> bdmurray: Sure.
[19:24] <infinity> bdmurray: Sufficiently tested and such, I hope? :)
[19:26] <sladen> bdmurray: simple un-intent?  What if statement was it originally under?
[19:26] <infinity> sladen: un-indent plus a newline!
[19:26] <infinity> (putting it outside the if)
[19:27] <sladen> infinity: yeah, wondering what the if statement was/is
[19:27] <bdmurray> there is a ui.yesno regarding sensitive info in /etc/ssh/ssh_config
[19:28] <bdmurray> and asking whether or not you want to include it
[19:28] <infinity> bdmurray: Have you tested this?
[19:28] <infinity> bdmurray: It looks to me like these lines might just exit straight out:
[19:29] <infinity>     if response == None: # user cancelled
[19:29] <infinity>         raise StopIteration
[19:29] <bdmurray> yes that's true
[19:29] <infinity> bdmurray: Which means your code will never get run.
[19:29] <bdmurray> no, if the dialog box is closed by clicking X and you don't choose yes or no that happens
[19:30] <infinity> Ahh.  Fair enough.  I don't speak apport, so wasn't sure what the dialog responses would be.
[19:30] <infinity> So, None = cancel and back out, True = include private stuff, False = include only non-private stuff?
[19:31] <bdmurray> that's correct
[19:31] <infinity> Mmkay.  Signing and uploading.
[19:32] <bdmurray> thanks
[19:56] <nigelb> tumbleweed: ping
[19:56] <tumbleweed> nigelb: hi
[19:57] <nigelb> tumbleweed: lightning talks start in 3 mins, can you join #ubuntu-classroom-backstage? :)
[20:45] <SpamapS> slangasek: well I'm down from 3781 lines to 2305 ... :)
[20:46] <slangasek> progress!
[20:46] <SpamapS> I've managed to get each "owner" line down to one.
[20:46] <SpamapS> and directories in which all files fall into the same owner are *'d ..
[20:47] <SpamapS> There's a merge operation now that needs to happen..
[20:47] <SpamapS> actually I'm not even convinced thats true..
[20:47] <SpamapS> mysql files are all single copyright holder from what I can see.
[20:49] <SpamapS> hrm.. licensecheck seems to be broken when a copyright spans multiple lines.
[20:49] <SpamapS>    Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
[20:49] <SpamapS>    Free Software Foundation, Inc.
[20:49] <SpamapS> That produces an empty copyright holder
[21:03] <cjwatson> infinity: openssh is maintained in lp:ubuntu/openssh, and the importer is having trouble with openssh at the moment.  Could you please commit the changes you sponsored there?
[21:07] <infinity> cjwatson: Can do.
[21:12] <infinity> cjwatson: Done.
[21:12] <cjwatson> ta
[21:22] <Daviey> SpamapS: Is this mysql 5.5 or the current package in Debian?
[21:28] <mikewhatever> !regression-alert
[21:31] <mikewhatever> The 2.6.32-33.70 kernel update introduced some Elantech touchpad related changes.
[21:32] <mikewhatever> Relevant bug #780588.
[21:33] <mikewhatever> The touchpad on my Dell Mini 10 is now unusable - its dimentiones are wrong, right click is jumpy, etc.
[21:59] <bryceh> mikewhatever, did you boot to the earlier kernel and verify it is the kernel update?
[22:10] <mikewhatever> quit
[23:11] <micahg> any AAs who know how to copy stuff still around?
[23:13] <slangasek> micahg: there are only two of us in Pacific Time, you could poke us by name ;)
[23:14] <micahg> slangasek: I could, but I didn't want to bother you if you we busy with something
[23:14] <slangasek> micahg: what do you have?
[23:14] <micahg> slangasek: could you please copy thunderbird from security to updates for maverick and natty only, *NO LUCID* :)
[23:14] <slangasek> ack, looking
[23:17] <slangasek> micahg: done
[23:17] <micahg> slangasek: thanks!, have a great weekend
[23:17] <slangasek> micahg: you too :)
[23:29] <SpamapS> Daviey: 5.5


[00:32] <mwhudson> woohoooo inbox zero
[00:39] <jml> mwhudson, grats
[00:50] <lifeless> is there any chance we could get rid of the 'no new merge proposal while one is outstanding' limit of code reviews?
[00:51] <lifeless> I'm having to lie to the system at the moment
[00:53] <jml> lifeless, perhaps...
[00:54] <lifeless> so my work flow is
[00:54] <jml> lifeless, what are you trying to do?
[00:54] <lifeless> hack on a branch a lot
[00:54] <lifeless> send of bits to be reviewed when I stop
[00:54] <lifeless> like this morning, did an hour on the test suite
[00:54] <lifeless> sent it off
[00:54] <lifeless> code-reviews complained at me that there was a MP already open
[00:54] <lifeless> so I go to that MP https://code.edge.launchpad.net/~lifeless/bzr/test-speed/+merge/10720
[00:55] <lifeless> tell it its merged (its not, just approved)
[00:55] <lifeless> http://pqm.bazaar-vcs.org/ is busy merging it
[00:55] <lifeless> then send in my new mp
[00:55] <lifeless> https://code.edge.launchpad.net/~lifeless/bzr/test-speed/+merge/10775
[00:55] <jml> I see.
[00:56] <jml> sounds not entirely dissimilar to a race condition
[00:56] <lifeless> with BB we just said 'send -r -2..'
[00:58] <jml> hmm.
[00:58] <jml> putting the constraint on branches, rather than on, say, revision ids, seems to be the mistake here.
[01:00] <lifeless> I think its fluid
[01:01] <lifeless> but yes, thats part of the thing driving the issue
[01:02] <lifeless> If I were to put it as a use case, it would be: 'a cherry pick merge submission sent while an earlier submission on the same branch is active should be accepted and shown separately'
[01:02] <lifeless> hmm
[01:02] <lifeless> two scenarios actually
[01:02] <lifeless> the second is
[01:02] <lifeless> 'a merge subission sent while an earlier submission on the same branch is active adds to that (or resubmits automatically?) rather than being rejected'
[01:15] <lifeless> jml: ^ what to do with this
[01:16] <jml> lifeless, sorry, the phone rang...
[01:16] <jml> brain occupied at present :)
[01:22] <spiv> jml: yes, I agree, I mentally think of merge proposals as being for revisions not branches (as branches can change, but the diffs (and reviews!) don't automatically change with them).
[01:22] <wgrant> Diffs will start changing soon, won't they?
[01:22] <thumper> wgrant: yes
[01:22]  * mwhudson lunches
[01:22] <lifeless> spiv: the followon changes can either be an extension (fixups) or new (different change)
[01:22] <spiv> jml: and I've also wanted what I think lifeless is asking for here, to be able to file a series of merge proposals off one branch.
[01:23] <lifeless> I'd be wary of keying too closely into revision id
[01:23] <spiv> lifeless: agreed.
[01:23] <lifeless> spiv: uick call?
[01:23] <spiv> lifeless: sure
[01:24] <spiv> I'd be happy for LP to make it obvious that there are more revs since the diff was generated, for instance.
[01:24] <spiv> And for LP to make it easy to refile for the new revs.
[01:26] <binarymutant> is this the right irc channel for mailing list administration?
[01:26] <jml> it's close enough :)
[01:27] <binarymutant> jml, my loco is having problems with it's list :(
[01:27] <binarymutant> we can't access it
[01:32] <jml> what's actually happening?
[01:34] <wgrant> binarymutant: Aren't LoCo mailing lists on lists.ubuntu.com?
[01:34] <wgrant> Launchpad has nothing to do with lists.ubuntu.com.
[01:34] <binarymutant> ty for the info wgrant :)
[01:35] <wgrant> Maybe #canonical-sysadmin, but I'm not sure.
[01:35] <wgrant> Or #ubuntu-locoteams.
[01:35] <binarymutant> thank you
[02:30]  * mwhudson reappears
[02:31] <mwhudson> spm: hello
[02:31] <spm> mwhudson: heyo
[02:32] <mwhudson> spm: can i get you to run some queries?
[02:32] <spm> mwhudson: only if you use the magic word
[02:33] <mwhudson> spm: select count(*) from codeimport where git_repo_url like '%sourceforge%';
[02:33] <mwhudson> spm: please
[02:33] <spm> bzt. wrong. word is "NOW!!!!" :-)
[02:33] <mwhudson> :)
[02:50] <jml> sinzui, you around?
[02:50] <sinzui> I am
[03:47] <wgrant> Does anybody else find 3.0 text to be very squished? It's all a lot closer together and less readable than 2.0.
[03:50] <jml> wgrant, it's hard for me to say, since Firefox 3.5 seems to have different font behaviour to Firefox 3
[03:50] <jml> got a couple of URLs to compare and contrast?
[03:53] <wgrant> jml: Look at the comment at https://code.edge.launchpad.net/~wgrant/launchpad/structural-subscription-security/+merge/10776/comments/28159/+reply. But it affects non-monospaced text as well.
[03:53]  * wgrant finds a good example.
[03:56] <wgrant> (does anybody want to land that branch for me, since gary_poster's concerns are unfounded and he's gone?)
[03:57] <mwhudson> wgrant: sure
[04:01] <wgrant> mwhudson: Thanks.
[04:05] <jml> mwhudson, oh, and not having the actual failures in the buildbot failure emails :)
[04:06] <jml> kfogel, hello
[04:06] <kfogel> jml: hey
[04:06] <mwhudson> and in other news, if people could stop pushing over non lefthand parents to lp-dev-utils trunk...
[04:07] <kfogel> mwhudson: ?
[04:07] <wgrant> mwhudson: I noticed that going on in lazr.restful a lot.
[04:07] <mwhudson> kfogel: revno's of lp:lp-dev-utils are a bit useless
[04:07] <mwhudson> because people merge their branches by merging from trunk, then pushing over trunk
[04:08] <wgrant> It also results in "Merge from trunk" commits down the LHS of trunk.
[04:08] <mwhudson> right
[04:08] <kfogel> mwhudson: it's hard for most people to remain that conscious of the ins and outs of their vc system, I think.
[04:09] <jml> mwhudson, I don't recall doing that, but my sincere apologies if I did
[04:09] <mwhudson> jml: i don't think it was you
[04:25]  * mwhudson lays down the law on the mailing list
[04:27] <thumper> mwhudson: did you get the query run to see how many git imports from sourceforge we have?
[04:27] <mwhudson> thumper: yes
[04:27] <mwhudson> thumper: there were 11, i think i fixed all of them
[04:27] <thumper> mwhudson: cool
[04:27] <mwhudson> well, we had some where someone had requested the new form already
[04:34] <mwhudson> fscking bzrtools
[04:35] <jml> phew. all read.
[04:36] <jml> now I need to incorporate the "Build Branch to Archive" thread into the spec
[04:53] <mwhudson> wgrant: seeing as you were asking earlier: https://dev.launchpad.net/BuildEngineer
[04:53] <jtv> wgrant: right ho, I'm on it.
[04:54] <wgrant> jtv: Thanks.
[04:55] <jtv> wgrant: good thing we're in similar timezones!
[04:56] <wgrant> jtv: Indeed!
[04:57] <mwhudson> jtv: oh i meant to ask, have you been using staging codehosting over the last two weeks?
[04:57] <jtv> mwhudson: no
[04:57] <jtv> why?
[04:57] <jtv> (It can't be much longer than two weeks, but I'm sure it's been two)
[04:58] <mwhudson> jtv: because you were trying to use it when i left, and i was trying to fix it
[04:58] <mwhudson> wgrant: btw, do you have a commit message for https://code.edge.launchpad.net/~wgrant/launchpad/structural-subscription-security/+merge/10776? ?
[04:58] <mwhudson> (sorry got horribly distracted)
[04:59] <jtv> mwhudson: thanks for asking... there were some more problems, but those were clear from production logs so we could fix, cherrypick, and see that the problem was gone.
[04:59] <wgrant> mwhudson: I don't. Feel free to make something up, or convince me to.
[04:59] <mwhudson> jtv: the answer i was hoping for was "yes, we used staging codehosting a lot and it all worked fine"
[04:59] <jtv> wgrant: does that latest revision fix both failures?
[04:59] <jtv> mwhudson: sorry to disappoint!
[04:59] <wgrant> jtv: It does.
[05:00] <jtv> wgrant: great, I'll send it back in
[05:00] <jtv> nice little three-way series of conversations here...
[05:00] <mwhudson> wgrant: "move structural subscription security checking into the model code" ?
[05:00] <jml> mwhudson, wgrant: a thing I'd like (and might do myself), is write a simple script to make an ec2test submission given only the merge proposal URL.
[05:00] <wgrant> mwhudson: Sounds fine!
[05:00] <wgrant> jtv: Thanks.
[05:01] <wgrant> jml: That would be good.
[05:01] <wgrant> And public ec2test even better.
[05:04] <wgrant> mwhudson: Thanks for making that page public.
[05:15] <jml> mwhudson, do you want me to file bugs for any of the things I mentioned earlier re pain points?
[05:15] <mwhudson> jml: yes please
[05:25] <wgrant> jtv, mwhudson: Are both my branches happily ec2testing?
[05:25]  * jtv checks
[05:26]  * wgrant is about to vanish for a couple of hours.
[05:26] <jtv> wgrant: not detached yet, but still working
[05:26] <jml> heh "
[05:26] <jml> Moving to launchpad since lp-devel-infra project is deprecated.
[05:26] <jml> "
[05:26] <jml> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/106936
[05:26] <mup> Bug #106936: daily review mails <email> <infrastructure> <Launchpad Foundations:Confirmed> <https://launchpad.net/bugs/106936>
[05:27] <wgrant> jml: Bah. Sounds like it needs reviving.
[05:27] <mwhudson> wgrant: the one i'm doing is
[05:27] <wgrant> jtv, mwhudson: Great, thanks.
[05:27] <mwhudson> wgrant: it's not detached yet, but nearly there
[05:28] <jtv> wgrant: mine just detached
[05:28] <jtv> mwhudson: race you!
[05:30] <jml> mwhudson, I've updated the BE wiki page with links to tags, and have moved a few bugs to be b-i tagged
[05:30] <mwhudson> jml: thank you
[05:30] <jml> mwhudson, I've probably let some junk through
[05:54] <jml> mwhudson, and now I've filed a large number of b-i bugs
[05:54] <mwhudson> jml: if only you could subscribe to a tag
[05:55]  * mwhudson is reading buildbot code, please send chocolate
[05:55]  * thumper sends mwhudson chocolate
[06:29] <jtv> wgrant: Jesus loves you, but He doesn't seem to care for your branch much.  Got the same failures. Did you push?    Was some time after you pinged me though.  :(
[06:32] <wgrant> Strange.
[06:32] <jtv> I'll just try again.
[06:32] <wgrant> Thanks.
[06:34] <jtv> wgrant: ha!  That was an old email.  The new one is still running.
[06:34] <wgrant> jtv: Ahhh. That makes more sense.
[06:40] <thumper> \o/
[06:40] <thumper> finally!!!
[06:40] <thumper> got person-product active reviews working
[06:40]  * thumper goes back to the old failing pagetest
[06:46] <thumper> some reviewer is going to hate me
[06:46]  * thumper wanks the 2000 line review limit back
[06:46] <thumper> oops
[06:47] <thumper> typo
[06:47] <wgrant> hahaha.
[06:47] <thumper> damn muscle memory
[06:47] <thumper> my branch is getting bigish
[06:47]  * wgrant just got a 1400 line refactor branch down to 800ish.
[06:48] <wgrant> Meant replaying the revisions doing bzr mvs slightly differently, though :(
[06:48] <thumper> this branch fixes activereviews for people, and adds project, source package, distro source package and person product active reviews
[06:48] <wgrant> Impressive.
[06:48] <thumper> well
[06:49] <thumper> most of the new ones were pretty simple
[06:49] <thumper> most of the work is done in branch collection
[06:49] <thumper> one of jml's great ideas
[07:06] <jml> mwhudson, have you eod'd?
[07:07] <lifeless> thekorn: grats
[07:08] <lifeless> meh
[07:08] <lifeless> thumper: grats
[07:30] <mwhudson> jml: more or less
[07:30] <jml> mwhudson, ok.
[08:08] <thumper> lifeless: for
[08:08] <thumper> ?
[08:10] <lifeless> 15:48 < thumper> this branch fixes activereviews for people, and adds project, source package, distro source package and person product active reviews
[08:10] <jml> anyone here use dchroot a lot?
[08:10] <thumper> lifeless: ah, ok :)
[08:11] <jml> I have this problem where I constantly have to manually update my /etc/resolv.conf
[08:11] <jml> hmm
[08:11] <lifeless> jml: I have been known to
[08:11] <lifeless> jml: the one in the chroot?
[08:11] <jml> lifeless, right.
[08:12] <lifeless> what updates your external resolv.conf
[08:12] <lifeless> whatever that is, hook into that and write to your chroots
[08:13] <jml> NetworkManager
[08:13] <jml> hmm.
[08:20] <lifeless> jml: welcome to the house of fun
[08:20] <lifeless> la-de-la-de-da
[08:22] <jml> :)
[08:28] <adeuring> good morning
[08:29] <jml> hi
[08:31] <jml> adeuring, I've just started getting errors like these whenever I run any tests:
[08:31] <jml> There were 1 imports of names not appearing in the __all__.
[08:31] <jml> You should not import export_destructor_operation from lazr.restful.declarations:
[08:31] <jml>     canonical.launchpad.interfaces.hwdb
[08:31] <jml> adeuring, know anything about it?
[08:32] <lifeless> jml: version mismatch?
[08:32] <lifeless> jml: I'm thinking a change to lazr.restful that you don't have yet, to make that public.
[08:33] <jml> lifeless, lazr.restful is managed in buildout, and my buildout is up-to-date.
[08:34] <jml> which doesn't preclude a mismatch in some version controlled config file, of course.
[08:43] <adeuring> jml: as lifeless said: you are using an lod version of lazr.restful. I I landed a lazr.restful branch  that includes export_destrutcor_operation in __all__
[08:43] <adeuring> s/lod/old/
[08:44] <maxb> I've just seen lp-dev-utils mentioned for the first time on list. Is that something intrinsically Canonical-internal, or should it be public but isn't?
[08:47] <jml> ok, so it's _not_ in buildout
[08:47] <jml> adeuring, thanks
[08:47] <jml> maxb, it's in the process of being made public
[08:48] <jml> maxb, some stuff will be kept private
[09:16] <jml> bigjools, hi
[09:16] <bigjools> morning!
[09:16] <gmb> Morning peoples.
[09:16] <jml> gmb, good morning
[09:17] <jml> bigjools, I've got a bunch of stuff I'd like to chat with you about
[09:18] <bigjools> jml: sure thing
[09:18] <jml> bigjools, but I'm not sure I have brain left today
[09:19] <bigjools> jml: what time will you be back in your morning?
[09:19] <henninge> staging does not let me do QA ... ;(
[09:20] <henninge> it times out
[09:20] <jml> bigjools, UTC 21:30
[09:20]  * henninge is amazed what a little complaining can achieve ... ;)
[09:21] <bigjools> jml: heh, not sure *I'll* have brain left then.  Tell you what, I'll see how I feel tonight else I can get up early tomorrow
[09:22] <mrevell> Morning
[09:23]  * jml tries anyway
[09:23] <jml> I have a note that says ProductSeries.sourcepackages is buggy.
[09:23] <jml> I now want to slap myself for making notes like that.
[09:23] <bigjools> :)
[09:23]  * bigjools looks
[09:23] <jml> mrevell, g'day
[09:24] <bigjools> jml: my eyes are bleeding looking at it, and it's only 8 lines
[09:24] <jml> it's not that bad :)
[09:25] <jml> actually that reminds me.
[09:26] <jml> I have a branch that extracts out verify_acl's logic that works, modulo some easily-fixed error message differences
[09:26] <jml> there's still some more stuff I need to do on top of that, but it's a nice milestone.
[09:27] <bigjools> fab
[09:27] <jml> and it turns out that eyeblood stains wash out of carpet really easily
[09:27] <jml> bigjools, you said I should ask you on IRC why branches are associated with distro and not sourcepackage in breadcrumbs
[09:28] <bigjools> jml: indeed, and if only I could remember what I was thinking when I wrote that
[09:28] <jml> bigjools, ok. you can get back to me then :)
[09:29] <jml> bigjools, I was looking at the package navigation thread today (first time since I got back from leave) -- how's all that going?
[09:29] <bigjools> jml: somewhat underwhelmingly
[09:29] <bigjools> some pages I wanted to trash were apparently important to some people
[09:30] <jml> right, I saw you mention that you wanted to get a longer list of use-cases.
[09:31] <bigjools> right now I am going for the tactic of improving the pages we said we would and then coming back later with the removal questions
[09:31] <jml> bigjools, good plan.
[09:31] <bigjools> jml: so for the breadcrumbs, what are the relative pros and cons
[09:32] <jml> bigjools, sourcepackage is more consistent with the way product branches work
[09:33] <jml> bigjools, and it's more consistent with the code
[09:33] <jml> bigjools, but I don't find either of these to be compelling
[09:34] <gmb> Hmm.  I would have guessed "Ubuntu" -> "source in karmic" -> branch
[09:36] <bigjools> yeah
[09:36] <bigjools> one page that is under my heavy removal scrutiny is the SourcePackage page
[09:37] <jml> bigjools, currently it's Ubuntu -> 9.10 -> "hotwire" package
[09:37] <bigjools> and I don't want that to block on anything branch-related if it comes to it
[09:37] <bigjools> oh yeah there's a little debate about what to write for a distroseries title
[09:38] <bigjools> in my DSP page I use series.title.  it doesn't include the vesion, maybe it should
[09:38] <jml> bigjools, removing the SourcePackage page would probably not be a good thing for branches
[09:39] <bigjools> jml: it's a useless page :(  go look at one
[09:39] <jml> bigjools, https://code.edge.launchpad.net/ubuntu/karmic/+source/hotwire
[09:39] <bigjools> jml: how would one navigate to that page usually?
[09:40] <jml> bigjools, it's reached by the Code tab from a source package branch
[09:40] <bigjools> I wonder if I can add links to it in the new DSP page?  (example here: https://dogfood.launchpad.net/ubuntu/+source/amarok)
[09:40] <jml> bigjools, have you seen https://code.edge.launchpad.net/ubuntu/+source/hotwire
[09:41] <bigjools> yes
[09:41] <jml> good.
[09:42] <jml> bigjools, one of the rationales for linking branches to SourcePackages instead of DistributionSourcePackages was so that there'd be a relevant listing of branches in each cycle of Ubuntu development
[09:42] <jml> bigjools, maybe we can achieve this without a SourcePackage page
[09:42] <bigjools> yep
[09:42] <jml> bigjools, but it needs at least a little thought.
[09:43] <bigjools> one of the problems with the package navigation is that there's waaaay too many pages with info spread all over them
[09:44] <bigjools> it does need more thought
[09:44] <bigjools> we should get together with Curtis
[09:46] <jml> bigjools, indeed
[09:47] <bigjools> jml: coming to Europe soon?  you must be due, you haven't been here for a week :)
[09:47] <jml> bigjools, haha
[09:50]  * jml has to go now
[09:50] <jml> g'night all
[09:51] <bigjools> jml: g'night, and I think +1 for your suggestion on breadcrumbs
[09:51] <jml> cool.
[10:08] <jtv> wgrant: Jesus feels a lot better about your branch now than I thought earlier.  It's landed.
[10:08] <wgrant> jtv: Did you have some trigger for when I became unaway?
[10:09] <wgrant> Because I got that message about a second after my screen reattached.
[10:11] <jtv> wgrant: once Jesus gets involved, all bets are off.
[10:12] <jtv> (Have I pissed off enough people today yet?)
[10:12] <wgrant> jtv: Heh.
[10:12] <wgrant> jtv: Thanks for the landing.
[10:12] <bigjools> mrevell: will you be able to do this? https://bugs.edge.launchpad.net/soyuz/+bug/392239
[10:12] <mup> Bug #392239: [PPA] "Read about uploading" link doesn't go to the anchor bookmark #Uploading <ppa> <Soyuz:Triaged by matthew.revell> <https://launchpad.net/bugs/392239>
[10:13]  * mrevell looks
[10:14] <mrevell> bigjools: yes, no problem
[10:14] <bigjools> mrevell: super thanks
[10:14] <jtv> wgrant: no worries... the next task is Q/A.
[10:14] <wgrant> mwhudson: What happened to my other branch?
[10:15] <jtv> gmb, can I get you to Q/A wgrant's export-bug-nominations branch?
[10:15] <gmb> jtv: Sure; I can take a look in about half an hour if that's okay.
[10:15] <jtv> gmb: that'd be swell, thanks.
[10:17] <wgrant> jtv: We don't wait for edge?
[10:17] <jtv> wgrant: for actually performing Q/A, yes, you.  But gmb is having his first look in half an hour.
[10:18] <wgrant> jtv: OK.
[10:52] <gmb> jtv, wgrant: So, which branch is it I need to look at?
[10:52] <gmb> well, branch / commit / bug/ item on the QA page
[10:53] <jtv> gmb: lp:~wgrant/launchpad/export-bug-nominations will need QA when it shows up on edge.
[10:53] <gmb> Ok.
[10:57] <jtv> gmb: thanks.
[11:06] <deryck> Morning, all.
[11:16] <bigjools> hey deryck
[12:29] <gary_poster> wgrant: did you get someone to merge your structural-subscription-security branch?
[12:32] <wgrant> gary_poster: mwhudson started an ec2test of it several hours ago, and another of my branches started around the same time landed 2.5 hours ago, so I think something went wrong.
[12:33] <gary_poster> wgrant: ok.  yeah, I see your other one.  probably should wait for feedback to you from Michael then.
[12:34] <wgrant> gary_poster: Yep, I'll hopefully find something out tomorrow.
[12:34] <gary_poster> ok cool
[12:35] <gary_poster> I'll note that Michael tried to land the branch on the MP so anyone following along there knows we aren't ignoring you ;-)
[12:36] <wgrant> Thanks.
[12:52] <bigjools> I am going to shoot the next person who uses regular expressions in a test >:(
[12:59] <wgrant> bigjools: You just wait until you start using renormalizer to get traceback tests working on 2.5...
[15:35] <leonardr> barry, can you help me with a python problem?
[15:35] <leonardr> i'm getting a metaclass conflict even though i'm pretty sure all my classes have the same metaclass
[15:39] <leonardr> here's the code that's causing the problem
[15:39] <leonardr> https://pastebin.canonical.com/21549/
[15:39] <leonardr> i pass the result of make_configuration_superclass into make_configuration and get the error when it tries to use the superclass as a superclass of a new class
[15:39] <leonardr> but i'm using type() everywhere, and __metaclass__ = type in all affected files
[15:41]  * barry looks
[15:43] <barry> leonardr: do you have a full traceback as well as the offending code?
[15:43] <leonardr> barry, sure
[15:43] <barry> leonardr: or maybe better, a branch
[15:44] <leonardr> barry, i'll push the branch
[15:44] <leonardr> give me just a minute to clean up
[15:44] <barry> no worries, i'll be here :)
[15:45] <leonardr> actually, maybe i can just make it simpler and destroy the problem that way
[15:50] <matsubara> stub, Chex, gary_poster, rockstar, bigjools, henninge_, sinzui, intellectronica, Ursinha-afk: meeting in 10 min @ #launchpad-meeting
[15:51] <matsubara> s/meeting/LP production meeting/
[15:51] <sinzui> barry:  can you stand in for me in the LP product meeting ^
[15:52] <intellectronica> matsubara: thanks for the reminder
[15:52] <barry> matsubara, sinzui sure
[16:01] <matsubara> henninge_, meeting
[16:01] <matsubara> actually now danilos attends the production meeting, right?
[16:10] <henninge> matsubara: at least today, I am about to leave
[16:10] <matsubara> henninge, ok. danilos showed up. thanks!
[17:05] <abentley> danilos: Any idea why this would fail this way?  Is order important? http://pastebin.ubuntu.com/260413/
[17:06] <barry> leonardr: good to see you figured it out
[17:07] <danilos> abentley: it's a recent commit by jtv, I'd have to take a closer look
[17:08] <leonardr> barry, thanks for your potential help
[17:10] <barry> leonardr: i'm always potentially helpful.  sadly, the converse is often true too :)
[17:22] <danilos> abentley: can you fix the problem using assertContentEquals and that should be fine (if you are submitting something to pqm)
[17:23] <abentley> danilos: checking it now...
[17:24] <danilos> abentley: every other test works with only one so it's not a problem right now, but if this works for you, please email<EMAIL_ADDRESS>(CCing me) mentioning what you had to do, and then the two of us can figure out what's the best way forward
[17:26] <abentley> danilos: self.assertContentEquals isn't defined, and I'm not sure what you mean.
[17:27] <abentley> danilos: Found it: assertContentEqual
[17:28] <abentley> danilos: This does work for me.  I'll include it in the branch I land.
[17:29] <danilos> abentley: thanks, please do still email jtv@ and danilo@ with this; thanks and sorry for it causing a problem like this!
[18:23] <bac> hi bigjools
[18:31] <mrevell> night all
[18:35] <intellectronica> are people seeing failures in lib/lp/app/browser/tests/menu.txt ?
[18:35] <intellectronica> i just got failures from ec2 and i don't think it has anything to do with my changes
[18:36] <salgado> intellectronica, I just saw a landing that changed something there
[19:07] <bac> intellectronica: barry has a testfix branch running now
[19:08] <intellectronica> bac: cool, thanks
[19:24] <barry> beuno: ping
[19:24] <barry> intellectronica, bac that should already be landed in devel
[19:25] <beuno> barry, hi
[19:25] <barry> beuno: i have a quick u/i-ish question for you related to bug 51735
[19:25] <intellectronica> barry: it has indeed. i got the failure from a branch i sent to ec2 (number of hours it takes to run the full test suite) earlier
[19:25] <mup> Bug #51735: top level distros page could be improved <ui> <Launchpad Registry:Triaged by barry> <https://launchpad.net/bugs/51735>
[19:25] <barry> intellectronica: the joys of a long test suite
[19:26] <beuno> barry, sure, what's up?
[19:26] <barry> beuno: at the bottom of that bug report sinzui suggests changing the way the read-only asterisk is displayed, but that also (i think) subtly changes the semantics of that star
[19:26] <barry> beuno: right now the ui says about that footnote: * Read-only distribution. Can be browsed in Launchpad, but not altered or managed, and its information might be out of date.
[19:27] <barry> beuno: but with sinzui's suggested change it really means "does not use Launchpad in any way"
[19:27] <sinzui> barry: it does change it.  if you read the code, we have a hack in it
[19:27] <barry> sinzui: yep, i've seen that
[19:28]  * beuno looks at the bug
[19:48] <beuno> so, has anyone tried LP on karmic?
[19:48] <beuno> will I be shooting myself in the foot (again) if I upgrade my work laptop as well
[19:48] <beuno> ?
[19:49] <barry> beuno: not yet, though i did install karmic on a vm last night.  haven't tried building lp on it yet
[19:50] <beuno> barry, I think we don't have the deps in the PPA for karmic
[19:50] <beuno> actually, it seems we do
[19:50] <beuno> I'll bite
[21:13] <mwhudson> wgrant: that ec2test run hung, it seems :(
[21:29] <thumper> sinzui: are you around?
[21:30] <sinzui> I am
[21:30] <thumper> ok, just checking
[21:30] <thumper> 1 hour
[21:30] <sinzui> thumper: I am on vacation
[21:30] <thumper> sinzui: then why are you around?
[21:31] <sinzui> Do you want to talk about pygtk hacking?
[21:31] <thumper> sinzui: so our call is off?
[21:31] <thumper> not really
[21:31] <thumper> sorry
[21:31] <thumper> I'll grab rockstar then :)
[21:33] <rockstar> thumper, hi
[21:34] <mwhudson> gary_poster: hello
[21:34] <gary_poster> mwhudson: hiya :-)
[21:35] <mwhudson> gary_poster: so do you remember what the problem was with the force build button when you turned it on?
[21:35] <gary_poster> mwhudson: I'm pretty sure that it simply did nothing.
[21:36] <gary_poster> It *possibly* was worse than nothing--causing some kind of glitch, but I lean towards nothing.
[21:39] <mwhudson> ok
[21:39]  * mwhudson is reading buildbot source code
[21:39] <mwhudson> and as usually, i'm getting a little dizzy
[21:39] <gary_poster> heh
[21:42] <gary_poster> kfogel: did you happen to propose to flacoste that we put lp-dev-tools in the lp tree?  if not, would you mind sending a note to the list proposing that, pointing out that they use launchpadlib and we don't have anything else that uses launchpadlib in the tree right now?  I don't care personally, and like the idea of our dev tools being in the tree, so I'd like to see if anyone objects.
[21:43] <kfogel> gary_poster: will do right now
[21:43] <gary_poster> thx!
[21:48] <kfogel> gary_poster: why the nick change?
[21:48] <kfogel> gary_poster: note that the lp-dev-tools should then get whatever license the other scripts in there have.  If it's AGPLv3, then so be it.
[21:48] <gary_poster> kfogel: somebody claimed "gary" on freenode a long time ago
[21:48] <kfogel> gary_poster: oh, I didn't notice we're on freenode
[21:48] <gary_poster> I'm still gary on canonical.com
[21:49] <gary_poster> ("gary" will still ping me in my client though, just in case)
[21:50] <kfogel> barry: is 'bip' an irc client?
[21:50] <barry> kfogel: it is
[21:51] <barry> kfogel: it runs in the background and connects to multiple irc servers.  then i use erc (in emacs 'natch) to connect to localhost's irc server from bip's daemon
[21:51] <barry> kfogel: it generally works well, except for some warts in both bip and erc that have not yet been worth hacking on yet
[21:51] <kfogel> barry: someday I should watch you use ERC.
[21:52] <kfogel> I tried to use some Emacs IRC client (maybe it was erc, not sure) a while back and just wasn't happy, so went to XChat.
[21:52] <barry> kfogel: modulo warts, it's changed my life :)
[21:52] <kfogel> But I still long for Emacs editing in IRC.
[21:52] <barry> kfogel: xchat irsii etc all drove me nuts
[21:52] <kfogel> xchat does drive me nuts, yes :-)
[21:52] <barry> kfogel: erc+bip has not yet driving me nuts
[21:53] <barry> kfogel: there are two irc clients for emacs iiuc.  erc seems to work pretty well, though there are some changes i'd make if i had the swine flu
[21:53] <kfogel> beuno: ping
[21:54] <beuno> kfogel, hi
[21:54] <kfogel> beuno: privchat, one sec
[21:56] <gary_poster> maxb: I saw your reply to bug 413335.  It would be awesome to have a fuller description and an example.  Will you have a chance to do either of those soonish--like by early next week?  If so, I'll wait for you.
[21:56] <mup> Bug #413335: Figure out what to do about zope.sendmail incompatibility with Python >= 2.5.1 <python-upgrade> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/413335>
[21:58] <maxb> gary_poster: yes, I'll definitely sort it over the weekend if I don't before
[21:59] <gary_poster> maxb: awesome.  ok, thanks
[21:59] <thumper> rockstar: skype?
[22:00] <rockstar> thumper, sure.  Early 1-1 then?
[22:00] <thumper> rockstar: I actually wanted to talk to you about a review :)
[22:01] <rockstar> Are you sure you can take that much rockstar in one day?
[22:02] <barry> kfogel: btw, irc + dabbrev ftw!
[22:03] <rockstar> thumper, 2 min and I'll be ready
[22:03] <thumper> ok
[22:03] <kfogel> barry: I totally believe it
[22:05] <rockstar> thumper, ready
[22:16] <wgrant> mwhudson: Are you trying again?
[22:16] <mwhudson> wgrant: not yet
[22:16] <mwhudson> wgrant: i think i may be being hated by my router, let's get someone else to run it
[22:17] <mwhudson> thumper: can you run "~/canonical/repos/lp-dev-utils/trunk/ec2test.py --headless -s "[r=gary][ui=none] move structural subscription security checking into the model code" lp:~wgrant/launchpad/structural-subscription-security<EMAIL_ADDRESS>please?
[22:17] <thumper> mwhudson: ok
[22:19] <wgrant> Huh. Lots of people going on leave and leaving and changing position right now.
[22:19] <mwhudson> hey wouldn't it be nice if i could click force build on buildbot now
[22:19] <mwhudson> spm: there?
[22:19] <mwhudson> or mthaddon
[22:20] <mthaddon> mwhudson: 0/
[22:21] <mwhudson> mthaddon: can you edit line 267 of buildbot's master.cfg to pass allowForce=True and bounce buildbot pls?
[22:21] <mthaddon> mwhudson: what does that do?
[22:21] <mwhudson> mthaddon: it makes the force build button appear on the ui
[22:22] <mwhudson> mthaddon: which doesn't work, but i'd like to fix that, so debugging info would be useful
[22:22] <mthaddon> mwhudson: is currently: c['status'].append(html.WebStatus(http_port=8010)) # , allowForce=True))
[22:22] <mthaddon> mwhudson: so what should that be?
[22:22] <mwhudson> mthaddon: also, are the buildbot twistd.log files copied anywhere currently?
[22:23] <mthaddon> mwhudson: they aren't currently no - can you RT that?
[22:23] <mwhudson> mthaddon: c['status'].append(html.WebStatus(http_port=8010), allowForce=True)
[22:23] <mwhudson> mthaddon: sure
[22:24] <wgrant> mwhudson: Misplaced paren.
[22:24] <mwhudson> ah yes
[22:24] <mwhudson> c['status'].append(html.WebStatus(http_port=8010, allowForce=True))
[22:25] <mthaddon> mwhudson: 	exceptions.SyntaxError: invalid syntax (master.cfg, line 267)
[22:25] <mthaddon> mwhudson: nm, paste fail
[22:25] <mwhudson> :)
[22:26] <mwhudson> mthaddon: rt #35484 btw
[22:26] <mup> Bug #35484: Won't load X  <Ubuntu:Invalid by ubuntu-x-swat> <https://launchpad.net/bugs/35484>
[22:26] <mwhudson> mup: shut it
[22:26] <mthaddon> thx
[22:32] <mwhudson> mthaddon: is the patched buildbot running?
[22:32] <mthaddon> mwhudson: I've made that config change and restarted buildbot, yep
[22:32] <mwhudson> hmm
[22:33] <mwhudson> oh right
[22:33] <mwhudson> latent buildslaves appear to be disconnected the whole time
[22:33] <mwhudson> i guess we'll be needing to patch buildbot a bit then
[22:35] <mwhudson> gary_poster: is there a buildbot irc channel or anything?
[22:35] <mwhudson> ah, the obvious answer works :)
[22:35] <gary_poster> :-)
[22:36] <jml> hello all
[22:38] <spm> hey jml
[22:39] <jml> spm, hello :)
[22:39] <jml> beuno, hi
[22:39] <beuno> jml, hai
[22:40] <jml> beuno, I'm working through your email now
[22:40] <beuno> jml, it's starting to feel more like a wiki than an email   ;)
[22:41] <jml> beuno, yeah, I know.
[22:41] <jml> beuno, one more round from me :)
[22:42] <spm> mwhudson: am now. but I gather tom's assisted?
[22:42] <mwhudson> spm: yes, thanks
[22:42] <spm> cool
[22:42] <beuno> jml, give me your best shot, it's fun
[22:43] <jml> beuno, I was thinking just that -- it's quite fun :)
[22:44] <beuno> jml, I think that this is what google wave will be all about
[22:44] <beuno> real multiplayer email
[22:47] <wgrant> I think the alignment of the main branding heading is a bit strange. Would it look better if it was aligned with the LHS of the Overview button, rather than the text, I wonder?
[22:55] <rockstar> barry, do we have a standard where our pagetests now need to be restructured text?
[22:59] <barry> rockstar: yes
[23:00] <barry> rockstar: w/conversion as you go
[23:00] <rockstar> barry, thanks.
[23:12] <intellectronica> i'm getting lots of errors in test_breadcrumbs. is that a known problem?
[23:28] <jml> mwhudson, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/420198
[23:28] <mup> Bug #420198: ec2test --headless takes way too long to detach <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/420198>
[23:28] <lifeless> jml: hi
[23:28] <lifeless> jml: I'm guessing you make test bzr servers in the codehosting tests
[23:28] <lifeless> you may find http://bazaar.launchpad.net/~lifeless/bzr/test-speed/revision/4661 relevant
[23:30] <jml> lifeless, a little.
[23:30]  * jml is reminded of other
[23:30] <jml> code
[23:30] <lifeless> spiv: I wonder if ChrootServer should take a server on its setUp rather than a transport on its __init__ (we could make a server that just claims to be at an arbitrary url)
[23:30] <lifeless> spiv: that would be more consistent with other Servers
[23:33] <mwhudson> yeah, we do that sort of thing a fair bit
[23:33] <jml> lifeless, we have a function in our base TestCase that does foo.setUp(); self.addCleanup(foo.tearDown)
[23:34] <mwhudson> TestCase.installFixture woo
[23:34] <lifeless> jml: thats close to this indeed
[23:34] <jml> but I don't think we use backing servers in quite the same way
[23:34] <jml> there's also a base class called Fixture
[23:34] <lifeless> jml: this is preparation for another change that will deny all access to urls that aren't registered with the test case
[23:34] <jml> which has its own addCleanup implementation
[23:35] <lifeless> jml: so the reason I'm headsuping you and mwhudson et al
[23:35] <jml> is you're going to break our test suite?
[23:35] <lifeless> is that when you start grabbing from the post 2.0 releases, its going to be brutal
[23:35] <lifeless> assuming it gets through review
[23:36] <lifeless> I'm changing from a 'setup things so that bad code is contained' to 'contain bad code by interception'
[23:36] <lifeless> model for the test isolation code
[23:36] <lifeless> less work++
[23:36] <jml> lifeless, http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head%3A/lib/lp/codehosting/scanner/fixture.py
[23:42] <lifeless> nice
[23:42] <lifeless> uhm, might want to split the zope stuff from the support stuff
[23:42] <lifeless> just a thought
[23:44] <jml> yeah
[23:44] <jml> it's totally in the wrong place
[23:44] <jml> but it's a whole lot better than thinking about it how good it would be to have something like that :)
[23:54] <jml> man, filing all of these bugs for the build system has made me want to do something about them
[23:55] <mwhudson> oop
[23:55] <mwhudson> s