[02:09] <TheMuso> @pilot in
[02:11] <micahg> @pilot out
[05:43] <micahg> TheMuso: -v please when sponsoring merges, thanks :)
[05:50] <TheMuso> micahg: oh whoops! Thanks, one tends to foget when working with bzr branches.
[05:50] <TheMuso> forget
[05:51] <TheMuso> And since I've been working with other packages, I get on a bit of a muscle memory role and its doubly forgotten.
[06:06] <TheMuso> @pilot out
[06:32] <dholbach> good morning
[07:53] <diwic> If I'm preparing an SRU (for PulseAudio, a package in main) and want it to go into 12.04.1, what are my deadlines?
[07:56] <RAOF> diwic: I think the answer might be “a week or so ago”
[07:56] <RAOF> diwic: You'll get a more authoritative answer in #ubuntu-release
[07:57] <diwic> RAOF, ok, I'll just go with a regular SRU then and let it take the time it takes
[07:57] <RAOF> Do ask in #ubuntu-release; I've been away for a couple of weeks, so might not be up to speed.
[07:57] <diwic> it's not critical or anything, just figured that if there was a deadline around now, I could just as well adjust to it.
[07:58] <RAOF> Fair enough.
[07:59] <diwic> RAOF, looking at the release schedule for 12.04 you're probably right.
[08:35] <christoffer> Does anyone know the reason for the upcoming UDS to finish on thursday instead of friday?
[08:36] <diwic> christoffer, money, I would assume
[08:37] <christoffer> yea probably, just wanted to make sure that it is not a typo.
[08:37] <diwic> christoffer, i e, less days is cheaper, if we don't need the full week
[08:37] <UndiFineD> christoffer, there is actually a 5th day planned , as you can see on the schedule of the location
[08:38] <UndiFineD> but just not for ubuntu
[08:38] <christoffer> Linaro has another day
[08:39] <christoffer> UndiFineD, which schedule?
[08:42] <UndiFineD> http://www.bellacenter.dk/da-DK/visitordk/Kalender/Event-2/Linaro-Connect-Europe-2012.aspx?Action=1&PID=57
[09:01] <christoffer> UndiFineD, so I suppose you only stay an extra day (the friday) if you're interested in the Linaro discussions.
[09:06] <xnox> UndiFineD: christoffer: it's linaro demo friday only-ish http://connect.linaro.org/events/event/lce12-copenhagen/#socializing
[09:07] <christoffer> xnox, aha, thank you
[09:09] <gotwig> hey there, where can I get help with packaging my app that I ported from python2 to python3 to get it ubuntu 12.10 ready?
[09:13] <gotwig> got the channel...
[12:24] <jamespage> doko, have you had a chance to look at openjdk-7 priorities/updates yet?
[12:24] <jamespage> I'd quite like todo another rebuild test but want to ensure that java 7 always gets used...
[13:01] <ev> mpt: we have a total. 1,664,679 unique users in the past 90 days.
[13:02] <ev> *systems
[13:02] <mpt> \o/
[13:03] <seb128> ev, is that the total of users who reported an issue?
[13:03] <mpt> The number of machines that sent an error report.
[13:05] <seb128> mpt, great
[13:05] <seb128> ev, mpt: does it mean we have updated stats on the number of issues reported by user as well?
[13:06] <ev> seb128: not sure what you mean
[13:06] <mpt> ev, that was the one-off calculation, right?
[13:07] <ev> mpt, seb128: so using the formula suggested in that email thread, it would be 82118/166479 or 0.49326
[13:07] <mpt> Next step is to do the calculation every day
[13:07] <ev> where 82118 is the number of error reports received yesterday (since today isn't finished yet)
[13:07] <ev> yes, that will be easy
[13:07] <mpt> 0.49. Well, that's much better than 1.4, at least. :-)
[13:08] <seb128> ev, so it means users who report issues report 0.49 ones a day?
[13:08] <ev> seb128: as best we can approximate. Obviously we'd have a much better number if we were getting pings from systems that were not reporting issues.
[13:09] <seb128> ev, that's not taking into account the 90% drop in report that happened in june though right?
[13:09] <ev> 90% drop?
[13:09] <seb128> ev, the curves all dropping to 10% of their value issue I pointed
[13:10] <seb128> on 17/06/12? need to check the date
[13:10] <ev> we've fairly consistently received about 80k errors per day. I know the issue you mention, but I don't yet think it's tied to the total number of errors we receive
[13:10] <seb128> well 10% is an approximate
[13:10] <seb128> well, what is tied to then?
[13:11] <seb128> it seemed like we started receiving a lot less issues from one day to the next one
[13:11] <ev> I'm not sure yet
[13:11] <ev> not all the graphs have that form, mind
[13:11] <seb128> that's still pretty disturbing to me, I'm not sure what to think about it
[13:11] <seb128> not all, but from what I saw most do
[13:11] <ev> sure - I'd like to get to the bottom of it
[13:12] <ev> but there's no use speculating until we have sufficient data
[13:14] <seb128> ev, right, at the same time I'm not sure the 0.49 number is to be trusted either
[13:14] <dobey> what do the colors mean?
[13:15] <seb128> dobey, what colors?
[13:15] <ev> seb128: oh? why?
[13:15] <dobey> seb128: the colors for the packages/vesrions/bugs on errors.u.c
[13:15] <seb128> ev, because we don't know how much we miss by the "stop after 3 reports" and we don't know what that drop in numbers that happened at some point of time mean as well
[13:16] <seb128> dobey, greyed lines are issues with a fix uploaded
[13:16] <ev> dobey: red is a work in progress, but it's meant to indicate a possible regression
[13:16] <seb128> dobey, red colored "last seen" are potential regressions or unfixed issues
[13:16] <seb128> dobey, blue numbers are bugs you visited I think
[13:16] <Laney> how do you get the graph to show you a different timeframe?
[13:16] <Laney> to see this dip
[13:16] <seb128> Laney, click on any report
[13:17] <seb128> on the signature column
[13:17] <dobey> hmm
[13:17] <Laney> bah, it's painful to "back" through openid auth
[13:17] <ev> Laney: I'm fixing that today
[13:17] <seb128> yeah, middle click :p
[13:17] <seb128> Laney, the jockey one in second is a typical example
[13:18] <ev> Laney: most-way done through a branch that uses django-openid-auth instead of the apache module, so it will cache logins
[13:18] <seb128> curve goes steadly increasing until 05/17/12 (increasing number of people installing the LTS)
[13:18] <dobey> weird
[13:18] <seb128> then it drops and flats
[13:18] <seb128> there are lot of bugs with a similar graph
[13:19] <Laney> well, could it be that clients only report the same problem once?
[13:19] <Laney> so everyone got the bug, reported it and then didn't again
[13:19] <seb128> Laney, well it means our rate of new users is stangely flat or linear then
[13:20] <Laney> it could be skewed by the graph's y axis being so large
[13:20] <Laney> anyway, that's just rank speculation that i should probably refrain from making :P
[13:20] <dobey> it seems to also conflate the precise/quantal reports :(
[13:21] <seb128> dobey, you can select the distro serie at the top of the page
[13:21] <seb128> there is a combo
[13:21] <seb128> dobey, or you mean individual reports?
[13:21] <seb128> dobey, the individual reports have by version stats
[13:21] <dobey> seb128: i mean, there are reports that only show up under 12.04 there, but the 'last seen' version is from quantal not precise
[13:21] <seb128> dobey, click on the report, you have a table of instances by version
[13:23] <dobey> seb128: well nice. it doesn't even list the 'last seen' version there :)
[13:23] <seb128> Laney, well anyway the "stop reporting after n instance" would explain it was going up in a regular pace for a while then dropped and dropped on the same day for all the reports showing that shape
[13:23] <seb128> dobey, well it lists all the versions in a table, the last seen is the most right
[13:23] <dobey> seb128: yes but on the main page the version is 'last seen' column isn't list on the specific page at all
[13:24] <seb128> dobey, well, you have the same info on the specific page, just in a expended version in a table
[13:24] <dobey> seb128: so presumably there is a bug somewhere that's causing it to show quantal version on precise, perhaps due to someone running it during an upgrade or something?
[13:24] <seb128> Laney, would->wouldn't
[13:24] <dobey> seb128: https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Fubuntuone-installer%3AGError%3Afinished%3Afunction does not show "3.0.2-0ubuntu1" which is the "last seen" version on the main page
[13:24] <seb128> dobey, I don't think 'Last seen' is a by serie info
[13:25] <seb128> hum
[13:25] <seb128> ev, ^ any idea about that? known bug?
[13:25] <seb128> ev, if "3.0.2-0ubuntu1" is the last seen version should it be in the table with a count?
[13:26] <dobey> in fact, of the 3 ubuntuone-installer reports there which list 3.0.2-0ubuntu1 as the last seen; only one of the specific report links shows it in the versions table
[13:27] <ev> seb128, dobey: the code to create the tables landed after the Last seen stuff did. It's entirely possible that you've had a small number of users reporting with 3.0.2-0ubuntu1 when the error occurred on a previous version (this is fixed in apport, but I have to look into whether those reports are still getting sent to daisy.ubuntu.com).
[13:27] <ev> for now just look for large numbers
[13:27] <seb128> ok
[13:27] <dobey> ok
[13:28]  * dobey wonders if it's possible to get those fixes into 12.04 now; they still haven't been accepted into -proposed yet :(
[13:28] <seb128> ev, btw still can't select a month view (sorry for being naggy about that)
[13:28] <seb128> dobey, what fixes?
[13:29] <ev> seb128: yeah, my initial suspicion turned out to be wrong on that one and I just haven't had time to dig into it further yet
[13:29] <ev> I am aware of it though and will make it a priority
[13:29] <seb128> ev, ok
[13:29] <seb128> thanks
[13:29] <dobey> seb128: the ubuntuone-installer and ubuntu-sso-client i uploaded to -proposed last week
[13:29] <dobey> which should fix all those issues for them on errors.ubuntu.com
[13:29] <seb128> dobey, didn't they ask you to reupload the ubuntuone-installer only with the selected fix?
[13:30] <ev> (I had thought the timeouts were occurring from us taking extra time to talk to launchpad, as that change landed at basically the same time. But our addition of a cache hasn't fixed it, so the problem may lie somewhere else.)
[13:30] <dobey> seb128: no; and i don't think u1 design will be happy about not having those fixes in as well
[13:34] <seb128> dobey, re-reading the log from thurday on #ubuntu-release you wrote
        slangasek: understandable. and pretty much 100% of the other fixes are all non functional fixes anyway
[13:34] <seb128> dobey, I though it meant you agree to reupload ubuntuone-installer only with the fix for bug 853060
[13:35] <seb128> dobey, we are 2 weeks past .1 freeze, I'm not even sure they will accept that before .1 at this point though ... maybe we should just wait and get the updates in the queue in after .1
[13:37] <dobey> seb128: i didn't read slangasek's comment as meaning to re-upload; but that he was simply expecting it to only fix the one issue (except that it wouldn't, as there at least 3 fixes in there to get rid of the errors.u.c reports)
[13:37] <dobey> and i am not sure if they will apply cleanly without the other changes :-/
[13:37] <dobey> seb128: but the sso upload is a single patch; so i wonder why it wasn't accepted into -proposed yet either? :(
[13:37] <seb128> dobey, well, there was
     dobey: as you know we're a week past the 12.04.1
[13:38] <seb128>  upload deadline and your upload includes quite a bit more than just the fix we
[13:38] <seb128> want for 12.04.1
[13:38] <seb128> dobey, but I guess talk to stgraber about those
[13:38] <dobey> well i guess it's too late now anyway :(
[13:38] <seb128> dobey, because the upload freeze was august 3rd and you uploaded on august 10th
[13:39] <seb128> dobey, so nothing uploaded after the 3 was considered if nobody asked to really get the upload in
[13:39] <dobey> well, aug 4-8 i was on holiday, and iirc the comments asking for those uploads was after the freeze date as well
[13:41] <dobey> and i've been swamped with quantal stuff too; and i wasn't really aware of the aug 3 date until this week basically :-/
[13:41] <seb128> dobey, no blame, don't worry, if we get those in updates just before .1 that's fine too
[13:41] <seb128> dobey, we are aiming at fixing the most common issues
[13:42] <seb128> the fixes will not made it all on the .1 iso but we will have updates and a .2
[13:42] <dobey> right. and the sso issue is #2 on the errors.u.c list right now
[13:42] <dobey> should i poke skaet to get it in at least?
[13:44] <Laney> I imagine processing will resume as usual after the final freeze tomorrow
[13:46] <seb128> dobey, it would be good
[13:46] <seb128> stgraber, ^
[13:47] <stgraber> dobey: I'll look at the SSO one
[13:47] <dobey> stgraber: thanks
[14:06] <sveinse> I'm having problems compiling protobuf_2.4.1-1ubntu2 on amd64 from precise. It fails with "Makefile.am:84: Libtool library used but `LIBTOOL' is undefined", yet all build deps are installed. What could this be?
[14:30] <slangasek> seb128, dobey: I wasn't asking for a reupload, I was in fact intending to review and accept... I just ran out of time on the review part, I'm afraid
[14:43] <rmk_> can anyone help with getting the core rootfs image going on an ARM target?
[14:44] <rmk_> I tried following the instructions at: https://wiki.ubuntu.com/Core and all I get is "init: Failed to create pty - disabling logging for job" and "init: Temporary process spawn error: No such file or directory"
[14:45] <rmk_> as I'm using serial on ttyS0, I've tried adding a getty entry into etc/init/ttyS0.conf, but I never get that either
[14:45] <rmk_> and var/log doesn't seem to contain anything useful
[14:53] <xnox> rmk_:  join #ubuntu-arm experts channel =)
[14:54] <xnox> failed to create pty is a known upstart bug
[14:54] <rmk_> yep, found those bugs, seems to be treated as a low priority problem
[14:55] <xnox> rmk_: not really low... there two engineers working on it. and there were 3 merges done for it.... but the bug would just not die....
[14:55] <xnox> it's a nasty bug =(
[14:56] <rmk_> how often does the core rootfs tarball get updated?
[14:57] <smartboyhw> Excuse me, what version of AbiWord will be used for 12.04.1? We are talking about this in QA
[14:58] <ogra_> rmk_, depends which one you use :)
[14:58] <ogra_> there are plenty on cdimage.ubuntu.com ... where exactly did you download it from (url)
[14:58] <rmk_> well, looking at the date on it... it doesn't get updated
[14:59] <rmk_> as I said, I followed the isntructions at https://wiki.ubuntu.com/Core, which points me to http://cdimage.ubuntu.com/ubuntu-core/releases/12.04/release/
[14:59] <rmk_> and that stuff is dated 23 April
[14:59] <ogra_> right, that doesnt get updated
[14:59] <smartboyhw> !Abiword
[15:00] <ogra_> rmk_, there are daily images produced for the current development release though
[15:00] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily/current has the latest
[15:00] <smartboyhw> ogra_: Please help with my question a dozen lines above
[15:01] <rmk_> ogra: looks like armel has been dropped
[15:01] <ogra_> smartboyhw, check launchpad ;)
[15:01] <ogra_> rmk_, yes
[15:01] <smartboyhw> Uh
[15:02] <ogra_> rmk_, in precise armel is gone (even though we still produce packages, there are no images produced for it)
[15:02] <ogra_> err
[15:02] <ogra_> s/precise/quantal/
[15:02] <smartboyhw> ogra_: What?
[15:02] <jodh> rmk_: the pty issue is fixed in quantal and scheduled for inclusion in 12.04.2.
[15:03]  * ogra_ isnt sure if it was planned to rebuild -core for .1 or .2
[15:03] <stgraber> I don't believe it's LTS so probably not
[15:03]  * stgraber checks the manifest
[15:04] <stgraber> oh, it's, for: amd64 i386 armhf
[15:04] <stgraber> https://wiki.ubuntu.com/PrecisePangolin/ReleaseManifest/12.04.1
[15:04] <ogra_> rmk_, in any case it shouldnt block you apart from spamming the console
[15:05] <rmk_> ogra_: well, I've yet to get any kind of login on it
[15:06] <ogra_> it should show a login prompt on the monitor
[15:07] <ogra_> indeed you need to add a user or set a rootpw to be able to log in
[15:09] <jodh> rmk_: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/702574/comments/7
[15:09] <rmk_> yea, well, I've created a /etc/init/ttyS0.conf to tell upstart to start a getty on there, but I get nothing
[15:10] <ogra_> did you use the right device name for your hardware ?
[15:10] <rmk_> and if I take the SD card out and mount it on a PC, then look in var/log, there's nothing in there either to suggest what it did
[15:10] <rmk_> oh yes, it's definitely ttyS0
[15:10] <ogra_> i.e. on omap its ttyO2
[15:10] <rmk_> works in lucid
[15:10] <jodh> rmk_: maybe there is an issue with your job? Try the version on the link above whilst booting with 'console=ttyS0' or similar.
[15:11] <ogra_> rmk_, lucid used a different kernel
[15:11] <rmk_> I'm using the same kernel (my own, 3.5.0-rc5+)
[15:11] <rmk_> my etc/init.d/ttyS0.conf is:
[15:11] <ogra_> well, as long as you are sure its the right devuce
[15:11] <rmk_> start on stopped rc RUNNLEVEL=[12345]
[15:12] <rmk_> stop on runlevel [!12345]
[15:12] <rmk_> respawn
[15:12] <rmk_> exec /sbin/getty -8 115200 ttyS0
[15:12] <jodh> rmk_: typo - RUNNLEVEL
[15:12] <ogra_> heh, yeah
[15:12] <rmk_> that'll teach me to blindly copy instructions of a site
[15:12] <jodh> rmk_: I'd appreciate it if you'd try the version on the link above as I'd like to be assured it works in all scenarios.
[15:14] <rmk_> jodh: good catch, fixing that gives me a login at last :)
[15:14] <rmk_> I'll try that script in a moment
[15:15] <jodh> rmk_: thansk - much appreciated.
[15:15] <jodh> rmk_: thanks even ;)
[15:15] <rmk_> typo :)
[15:15] <jodh> rmk_: touche ;)
[15:23] <rmk_> anyone know where I can find the specs for what CPUs the armhf port supports?
[15:23] <ogra_> rmk_, all ARMv7 and above
[15:24] <rmk_> yes, but there's different VFP versions
[15:24] <rmk_> I tripped over this in lucid's qt4 library package
[15:25] <ogra_> we use vfpv3-d16 iirc
[15:25] <rmk_> ok, that's fine then.
[15:26] <rmk_> so, it sounds like I should switch to armhf rather than armel?
[15:26] <ogra_> its unlikely that armel will be there after quantal was released, so yeah, that might be a clever move ;)
[15:30] <rmk_> I think I'll put the armhf into a chroot, then update it first before trying to boot it
[15:31] <rmk_> along with your tty-serial.conf script
[15:31] <ogra_> what kind of HW do you have over there ?
[15:31] <rmk_> it's one of these solid-run.com cubox things
[15:31] <ogra_> ah, cubox should work just fine
[15:31] <ogra_> we had some users around in #ubuntu-arm during precise development
[15:32] <rmk_> well, I've been working on DRM support for this thing, mainly so that TVs can be properly hotplugged etc
[15:32] <ogra_> sweet !
[15:33] <rmk_> I have it working under lucid :)
[15:33] <rmk_> or rather, the lucid which was supplied with the cubox
[15:58] <seb128> cjwatson, ev, stgraber: do you know if https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1037001 is a known issue?
[15:58] <seb128> seems like the ubiquity panel process (in ubiquity only mode) is not running under the right locale
[15:58] <seb128> the translations are there and used in live session mode
[15:59] <stgraber> seb128: I don't think it's a known issue but I can certainly see what's going on
[15:59] <stgraber> seb128: the problem is that the installer always starts in the default locale (english)
[16:00] <stgraber> then it changes to whatever the language is in the preseed or chosen in the dialog
[16:00] <seb128> I guess it's too late to fix for .1 now?
[16:00] <stgraber> ubiquity itself updates to use the right language, but the rest of the environment can't be updated
[16:00] <stgraber> I think so, because I have no idea how to solve it
[16:00] <seb128> stgraber, can you comment on the bug and maybe milestone for .2?
[16:02] <rmk_> jodh: looks like the script didn't work - I tried increasing the runlevels to include 45 as well, still didn't work
[16:04] <jodh> rmk_: could you possibly add a comment to bug 702574 with details of what you specified on the kernel command-line?
[16:07] <ogra_>         PORT=${1#/dev/}
[16:07] <ogra_>         DEVICE="/dev/$PORT"
[16:07] <ogra_> jodh, that looks wrong
[16:07] <ogra_> you dont need /dev/tty*** on the cmdline (though it wont do any harm if you set it)
[16:08] <ogra_> i guess most people will just use console=ttyXYZ,115200n8 or some such
[16:08] <rmk_> yes, that's the normal form of the console= argument to the kernel
[16:09] <ogra_> well, iirc /dev/ttyXYZ would work too
[16:09] <jodh> ogra_: I know you don't need it, but the current script requires you to specify that you want to enable an extra getty. We could have it auto-spawn based on udev of course.
[16:10] <rmk_> ogra_: I don't think the kernel strips the /dev/ off before matching against the kernel console drivers
[16:10] <ogra_> jodh, just dont match against /dev
[16:11] <rmk_> so giving it console=/dev/ttyS0,115200n8 would probably result in no kernel messages on ttyS0
[16:13] <ogra_> rmk_, oh, did you remove /etc/init/ttyS0.conf before testing the script ?
[16:13] <rmk_> yes, it was tested on a brand new armhf rootfs
[16:14] <stokachu> any patch pilots today?
[16:16] <stokachu> bdmurray: is that you today?
[16:17] <bdmurray> stokachu: yes, but I will probably postpone until tomorrow.  trying to sort out an issue with apport and errors
[16:17] <stokachu> ok
[16:17] <stokachu> ill see if another pilot is available
[16:18] <bdmurray> stokachu: bryceh usually pilots around me too
[16:19] <stokachu> i see adam gandelman and luke yelavich
[16:19] <stokachu> looking up their nicks now
[16:20] <stokachu> TheMuso, adam_g: any of you available for patch review today?
[16:21] <rmk_> ogra_: just installing some other bits to make this rootfs a little more functional and then I'll debug that script
[16:22] <ogra_> thx !
[16:22] <rmk_> I'm still seeing:
[16:22] <rmk_> init: Failed to create pty - disabling logging for job
[16:22] <rmk_> when stuff is being started tho
[16:22] <rmk_> and devpts is mounted
[16:23] <jodh> rmk_: is this with precise?
[16:23] <rmk_> yes, no initrd tho
[16:24] <jodh> rmk_: the fix isn't available for precise yet. You can boot with '--no-log' to disable job logging (and make those messages go away) if you wish.
[16:26]  * rmk_ gets vim installed so he doesn't have to use sed :)
[16:49] <zul> mterry: ping
[17:05] <mterry> zul, hi
[17:05] <zul> mterry:  i dont think the python-django-appconf testsuite dont actually wory
[17:06] <zul> work even
[17:06] <mterry> I got an error about an env var
[17:07] <mterry> zul, you think it's just a busted suite?
[17:07] <zul> mterry: i think so
[17:08] <mterry> zul, OK
[17:08] <mterry> zul, then don't worry about it I guess
[17:09] <zul> mterry: ok...i just uploaded a version to address all the issues that you raised other than the testsuite
[17:10] <mterry> zul, cool, just marked the bug fix committed then
[17:10] <zul> mterry: thanks
[17:20] <rmk_> jodh: found the bug
[17:20] <rmk_> you need:
[17:20] <rmk_>       console=*)
[17:20] <rmk_>         old_IFS="$IFS"
[17:20] <rmk_>         IFS=','
[17:20] <rmk_> ...
[17:20] <rmk_>         FLOW="$4"
[17:20] <rmk_>  
[17:20] <rmk_>         IFS="$old_IFS"
[17:21] <rmk_> so that IFS gets reset back to something sane before trying to call getty, otherwise the shell won't split the arguments
[17:21] <rmk_> (it'll try to split them around , and not white space)
[17:49] <stokachu> is anyone available to review http://pad.lv/932860
[18:47] <jcastro> slangasek: sorry I was afk, did you get the feedback from that question you wanted? it appears so
[18:48] <stokachu> also could someone approve http://pad.lv/1013211 for precise series
[18:50] <slangasek> jcastro: yeah, we've got an actual bug report with debug logs, thanks :)
[18:51] <jcastro> nice to see the errors.u.c stuff come in so handy
[18:51] <jcastro> slangasek: so like when things like that happen do bells and whistles go off somewhere?
[18:55] <slangasek> jcastro: we don't yet have it wired to bells and whistles, it's still a manual poll of the errors.u.c frontpage
[18:55] <slangasek> bells and whistles are round two :)
[18:55] <jcastro> ah, I was so hoping like an alarm woke up infinity.
[18:55] <slangasek> alarms don't wake infinity
[18:56] <jocarter> I wish I could sleep like infinity :(
[19:11] <infinity> jocarter: Alarms don't wake me because I'm generally never asleep; you don't want that.
[19:20] <TJ-> whois TJ-
[19:20] <stokachu> thats you!
[19:24] <astraljava> Well, that's silly.
[19:46] <jocarter> infinity: ah, indeed.
[19:51] <slangasek> stokachu: libgnomecanvas> approved
[19:52] <stokachu> slangasek: thanks
[19:53] <stokachu> doing rdeps testing on it now
[20:40] <stokachu> anyone available to do some multi-arch reviews?
[20:41] <stokachu> ive got http://pad.lv/932860 and http://pad.lv/1013211 that needs some attention so i can SRU for precise