[00:28] <cjwatson> hallyn,stgraber: https://lists.gnu.org/archive/html/grub-devel/2013-03/msg00060.html (phew)
[00:28] <cjwatson> Sweetshark: Thanks
[00:29] <Sweetshark> cjwatson: np
[00:30] <hallyn> cjwatson: wow - thanks
[00:33] <cjwatson> stgraber: Uploading.  If 2.00-13ubuntu2 builds then you probably want to unblock it and retry Edubuntu amd64 image builds with it.  I think I need to go to sleep now and recover some SAN points ...
[00:35] <stgraber> cjwatson: yep. Will unblock once it's done building. Thanks!
[05:29] <pitti> Good morning
[06:19] <pitti> stgraber, infinity: I got an FFE ack for libudev1; could you please place a block on the systemd source, so that I can stage everything in -proposed, and to avoid potentially disrupting beta-1?
[06:41] <sarnold> pitti: re: logind, udevd, from systemd -- I intended to write the results of my audit tonight, but I'm tired enough now that I'm just going to go to bed.
[06:41] <pitti> sarnold: ah, thanks; I guess for the libudev part it doesn't matter much, as we already have that code in main, just from another source?
[06:41] <sarnold> pitti: however, please consider the MIR for logind, udevd, an ACK from me. I'll write it up in the morning (~nine hours from now)
[06:41] <pitti> sarnold: but for the services and logind etc. it'll be appreciated
[06:42] <pitti> sarnold: oh, nice! thanks
[06:42] <sarnold> pitti: jdstrand had asked me to give logind and udevd a look -- and that's as far as I looked. (it _is_ a big code base :)
[06:42] <sarnold> pitti: but I wanted to unblock you before going to bed, you've got a whole day to work ahead of you :)
[06:42] <pitti> sarnold: I'll do the libudev1 transition, but keep logind etc. in universe until we got your official ack plus the FFE for logind
[06:43] <sarnold> pitti: okay :) I can't speak to the FFE
[06:43] <pitti> sarnold: the logind transition won't happen today, so that won't block me; but I'm happy that the libudev1 transition is unblocked, indeed
[06:43] <sarnold> pitti: cool. :)
[07:15] <mbiebl> pitti: as we discussed, I think the important bit is what to do about 3rd party software which currently make use of different systemd subsystems
[07:15] <pitti> mbiebl: guten Morgen
[07:15] <mbiebl> but use a simple-all-or-nothing check
[07:15] <pitti> mbiebl: indeed
[07:16] <mbiebl> I think we need buy-in from upstream on that matter
[07:16] <mbiebl> othwerwise we will be distro-patching software for this forever
[07:16] <pitti> mbiebl: I'll talk to Lennart today what would be an appropriate and simple check for "systemd booted", perhaps testing somethign in /run/systemd/
[07:17] <mbiebl> pitti: Ideally with some simple to use api like sd_booted()
[07:17] <mbiebl> sd_logind() maybe, dunno
[07:17] <mbiebl> sd_journald(), ...
[07:17] <pitti> sd_booted() is kind of burned now, so indeed, maybe sd_using_logind() and sd_using_systemd()
[07:19] <dholbach> good morning
[07:22] <pitti> hey dholbach
[07:22] <dholbach> hey pitti
[07:58] <pitti> Laney: good morning; as I didn't reach infinity or stgraber any more, could you please put a block on systemd and udev? I'd like to do the libudev1 migration in -proposed
[08:04] <bkerensa> pitti: https://launchpad.net/~bkerensa/+archive/logind/  does this look good for a logind transition?
[08:05] <pitti> bkerensa: https://launchpadlibrarian.net/133702140/xfce4-power-manager_1.2.0-1ubuntu2_1.2.0-1ubuntu3bkerensa1.diff.gz looks good to me indeed, thanks!
[08:06] <pitti> bkerensa: I updated the status in the bp
[08:06] <pitti> bkerensa: nice, I wasn't aware that upstream XFCE also already supported logind
[08:23] <pitti> mbiebl: does "systemd-services" sound like an appropriate name to you, BTW? (I'd like to avoid another rename later if/when that goes into Debian)
[08:44] <mbiebl> pitti: let's discuss that on #debian-systemd
[08:50] <pitti> mbiebl: I'm in now
[09:37] <Laney> pitti: oops, I read this and then forgot
[09:37] <Laney> doing
[09:39] <Laney> done
[09:45] <pitti> Laney: sorry, temporary server/IRC fail; [10:33:51] done was about setting the block?
[09:46] <Laney> indeed!
[09:46] <pitti> Laney: cheers!
[09:46] <pitti> so libudev1, here you come; brace for impact
[09:47] <Laney> pitti: have you seen this: http://paste.ubuntu.com/5610182/ ? (first install)
[09:48] <pitti> Laney: uh, no, never; checking
[09:48] <Laney> I just did 'start systemd-logind' in another terminal and it seems to have worked
[09:48] <pitti> Laney: hm, I purged and reinstalled
[09:48] <Laney> laney@iota> sudo more /var/log/upstart/systemd-logind.log                                                                                  ~
[09:49] <Laney> mkdir: cannot create directory '/sys/fs/cgroup/systemd': No such file or directory
[09:49] <pitti> ooh
[09:49] <pitti> Laney: booted with earlier mountall?
[09:49] <pitti> Laney: it depends on current mountall now
[09:49] <Laney> if that would have been upgraded in this apt run
[09:49] <Laney> i.e. since yesterday
[09:49] <pitti> it was updated last Friday night already, did you upgrade and reboot since then?
[09:50] <Laney> ah, perhaps I didn't reboot
[09:50] <pitti> I dropped the mounting of /sys/fs/cgroup again, as mountall is now doing it
[09:51] <Laney> I did get a cgroup-lite update here which maybe kicked it
[09:52] <Laney> anyway - would that affect upgraders or is it some transient raring problem?
[09:52] <pitti> I think its postinst is slightly evil
[09:52] <pitti> as it unconditionally unmounts it; we need to fix that
[09:52] <pitti> Laney: I think it will affect upgrades, I'll put back the mount for now
[09:57] <pitti> Laney: ok, good timing; I was just about to press enter on dput :)
[09:57] <pitti> Laney: anything else which comes to your mind?
[09:57] <pitti> well, at this point it's only libudev1
[09:58] <Laney> yeah - don't think you need to hold off on the transition for this if you want to do both in parallel
[09:58] <pitti> Laney: oh, I fixed that upgrade issue now
[09:58] <pitti> $ dput systemd_198-0ubuntu1_source.changes
[09:59]  * pitti holds breath
[09:59] <pitti> I let that build and publish, and then upload my stack of 39 packages for the transition
[10:18] <chrisccoulson> pitti - transition? transition to systemd? ;)
[10:19] <pitti> chrisccoulson: my secret plot!
[10:19] <chrisccoulson> heh :)
[10:19] <pitti> chrisccoulson: not quite -- libudev0 → libudev1 for now, ConsoleKit → logind FFE is still outstanding
[11:06] <pitti> seb128: can I ask you to binNEW libudev1 (to main), and python-systemd (to universe)?
[11:06] <pitti> seb128: that'll unblock me from uploading the libudev1 transition to -proposed
[11:07] <seb128> pitti, looking
[11:14] <seb128> pitti, done
[11:16] <pitti> seb128: merci!
[13:10] <hallyn> lastlog ureadahead
[13:10] <hallyn> feh
[13:11] <hallyn> hm.  so i had to set ureadahead to manual to boot
[13:11] <hallyn> known bug?
[13:11] <hallyn> it was getting killed and then all boot would hang
[13:12] <hallyn> i was surprised how fast boot still ran by :)  i thought ureadahead was doing more for me, even on ssd
[13:19] <hallyn> whelp, guess i'm probably the only one (that or everyone else is still working aorudn broken boot :)
[13:19] <cjwatson> My boot was fine this morning FWIW
[13:20] <hallyn> thanks, that is a relief
[13:20] <hallyn> long as i just did something to hose my own system :)
[13:20] <cjwatson> Admittedly haven't rebooted since the last round of upgrades, but I don't see that much that could be relevant
[13:21] <cjwatson> Unless it's your cgroup-lite changes :)
[13:21] <hallyn> cjwatson: :)  didn't actually have those yet, nor the latest ureadahead
[13:21] <cjwatson> The latest ureadahead is still in raring-proposed anyway
[13:21] <cjwatson> So nobody should have it yet
[13:22] <hallyn> unfortunately while in my 'init=/bin/sh' boot I did echo manual > ureadahead.conf, not ureadahead.conf.override :)
[13:22] <hallyn> so i'll have to re-extract it manually to test at some point
[13:22] <cjwatson> dpkg --force-confdef
[13:22] <hallyn> neat, that's a new one
[13:22] <hallyn> for me
[13:22] <cjwatson> actually can't remember if that does it, possibly not.  If it doesn't, remove the conffile entirely and use dpkg --force-confmiss
[13:23] <cjwatson> --force-confdef might only do anything if you would normally get a conffile prompt, thinking about it
[13:23] <cjwatson> so, yeah, ignore that part
[13:23] <cjwatson> But --force-confmiss will work if you remove the file
[13:26] <hallyn> sound easier to dpkg -x and cp it back :)
[13:27] <hallyn> but now i know what to look for next time i need it
[13:59] <Industrial> I have installed git-daemon-run to run a git daemon on this computer. I have a bare repository at /home/tom/Documents/repos/utils.git. If I clone git://127.0.0.1:0418/home/tom/Documents/repos/utils.git then I get an authentication error. Did I miss a step?
[14:00] <Industrial> I cannot ask this in #git because it involves an ubuntu package and possible configuration. when i check service --status-all I don't see a git-server, but the git-server-run package is installed
[14:01] <smoser> anyone able to tell me what luser error I'm committing at https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1154599 ?
[14:01] <smoser> it seems this would be significant
[14:11] <ScottK> smoser: Do you have python2.7 installed?
[14:11] <smoser> ScottK, umm.. yes. i invoked it and showed the dpkg-query info.
[14:12] <ScottK> OK.  I was wondering because the info in the bug was python2.7-minimal.
[14:12]  * smoser is really not all here today.
[14:12] <smoser> ScottK, ah.  i just opened against /usr/bin/python2.7
[14:12] <ScottK> OK.
[14:13] <ScottK> smoser: Your script works for me.
[14:14] <ScottK> (on raring)
[14:16] <smoser> odd.
[14:27] <pitti> can anyone make sense of this rejected upload? https://launchpadlibrarian.net/134071024/upload_4366338_log.txt
[14:27] <cjwatson> Probably a librarian glitch
[14:28]  * cjwatson checks
[14:28] <pitti> from https://launchpad.net/ubuntu/+source/xbmc/2:12.0~git20130103.0959-rc3-0ubuntu1b1
[14:28] <pitti> I can just hit the retry button, but I've never seen this before
[14:30] <cjwatson> pitti: It happens now and again, but is rare
[14:30] <cjwatson> https://oops.canonical.com/?oopsid=OOPS-7fdbd9bf041fdd059ad3ed59a31dde9f is all the further info I can find
[14:30] <pitti> cjwatson: ok, thanks; I'll kindly ask it to try harder
[14:30] <cjwatson> (And isn't really any more informative)
[14:30] <cjwatson> Yeah, I'd mash retry
[14:32] <pitti> also, I may have upset http://people.canonical.com/~ubuntu-archive/testing/raring-proposed_probs.html -- I fixed that bug, but it stopped updating since
[14:32]  * pitti checks
[14:33] <pitti> uh, seems lillypilly is painfully busy right now, even ssh takes > 1 min (still not logged in)
[14:33] <pitti> I guess that's the reason
[14:35] <cjwatson>  14:35:24 up 95 days, 16:53, 10 users,  load average: 9.16, 7.24, 7.23
[14:36] <pitti> ah, you managed to ssh in? mine's still trying
[15:07] <GunnarHj> dholbach: ping
[15:07] <dholbach> GunnarHj, pong
[15:07] <GunnarHj> dholbach: Hi Daniel! Saw your UbuntuKylin work item and wondering how the im functionality is affected by UnityNext/Mir. To me the xkb and im integration in g-c-c seems to be of great significance. Maybe they are both important... Can you shed some light, or were you just connecting the teams?
[15:08] <dholbach> GunnarHj, yes, I just connected them - I'll CC you in a reply if you're interested
[15:08] <GunnarHj> dholbach: Yes, that would be great.
[15:08] <dholbach> sweet, will do
[15:26] <SpamapS> something bad happened to Google Chrome in the last 2 months.. it just.. sits there sometimes... not sure if there's a compatiblity problem with raring or what.. but.. its gone from my favorite browser to my favorite thing to kill -9
[15:45] <jcastro> SpamapS: me too
[15:45] <jcastro> it's becoming quite unstable for me
[15:48] <SpamapS> jcastro: you running google-chrome-stable I presume?
[15:48] <jcastro> yep
[15:58] <Sarvatt> jcastro, SpamapS: try disabling ppapi flash in about:plugins
[16:04] <SpamapS> bbuut... I neeeed flash
[16:05] <Sarvatt> SpamapS: use npapi flash from the distro, the ppapi one thats bundled causes hangs for me too
[16:14] <micahg> pitti: does dch -R not DTRT for  you for rebuilds?
[16:17] <SpamapS> Sarvatt: wow thats pretty obscure. Anything we can do to convince Google to do that as the default?
[16:20] <jcastro> SpamapS: I think their intent is for us to use the built in one, it just happens to be more broken than the other one.
[16:20] <Sarvatt> well theoretically we want to use that since its the only way flash gets real updates anymore on linux, but they update it pretty aggressively in chrome and it breaks all the time here :(
[16:23] <micahg> well, the NPAPI flash should continue to get updates for the life of precise
[16:23] <micahg> *security updates
[16:29] <SpamapS> jcastro: I think google's intent is to kill flash.. but.. yeah :)
[16:29] <SpamapS> jcastro: do you get problems where everything except copy/paste works ?
[16:31] <jcastro> I get this thing where it freezes up and then the tabs get misrendered and the entire thing zombies.
[16:31] <SpamapS> jcastro: yes thats what I"m getting too
[16:31] <jcastro> I just turned off the flash as Sarvatt says, I'll let you know how it works for me
[16:50] <tseliot> cjwatson, infinity: I have a fix for bug #1073062 which I have just sent to Debian. Do you thinkl I should wait for their response before including my fix in Ubuntu?
[16:53] <pitti> micahg: ah, I wasn't aware of this; I have used a pretty ancient script
[17:00] <cjwatson> tseliot: I think it'd be OK to go ahead with it in Ubuntu in the meantime, given the number of dups
[17:01] <tseliot> cjwatson: ok, I'll do it then, thanks
[17:02] <cjwatson> ta
[18:07] <lool> gema_: Is there some QA list that would be best to send the links to the notes and video?
[18:11] <gema_> lool: ubuntu-quality I think
[18:31] <lool> gema_: sent; NB: I'm not sub-ed
[18:57] <gema_> lool: ok, I don't see it, I will ask an admin to check
[18:57]  * gema_ -> EOD
[19:03] <stokachu> RAOF: i updated bug 1098186, could you finalize it at this point?
[19:03] <stokachu> for precise at least
[19:57] <dupondje> whoops, booting broken ?
[19:57] <dupondje> just updated to libudev1, and booting fails: unable to find /dev/by-uuid/*
[19:58] <melodie> hello
[19:59] <melodie> would someone have the patience to explain me newbie, what is the difference (if any) between a filesystem.manifest-remove file and a filesystem.manifest-desktop file in the casper directories of Ubuntu ISOS ?
[20:03] <slangasek> dupondje: libudev1 isn't in raring; why are you pulling from raring-proposed?
[20:03] <slangasek> pitti: ^^ problems reported with libudev1 :/
[20:04] <slangasek> melodie: I've never heard of either of these files; they both sound to me like accidental build system cruft
[20:05] <stgraber> slangasek: aren't they what's used by ubiquity to generate the "not to copy" file list?
[20:06] <slangasek> stgraber: hmm, I guess that's possible :)
[20:06] <pitti> dupondje: how did you update to libudev1? what did you install exactly?
[20:06] <slangasek> yeah, seems that .manifest-remove is used by ubiquity
[20:06] <stgraber> slangasek: right, ubiquity reads both of those files in install.py and plugininstall.py (according to a quick grep)
[20:06] <pitti> dupondje: note that our udev doesn't actually use libudev1
[20:06] <melodie> slangasek no they are used in the isos to list the packages installed, to list the packages which will be removed at the end of the install to hard drive, and the difference  of the two I said is not yet defined for me, so I am asking
[20:07] <pitti> dupondje: anyway, just driving by here; perhaps you can file a bug with teh details (please attach /var/log/dpkg.log) and subscribe me?
[20:08] <slangasek> melodie: ah, well then you officially don't get to claim to be a newbie if you already know that ;) but it sounds like stgraber may be able to explain better
[20:08] <melodie> slangasek I am a newbie learning how to build a spin with a basic version and ubuntu builder, and there is so much to learn it is huge!
[20:09] <melodie> in several versions I found the *-remove file and in some I found only the *-desktop file, so I am in a wonder
[20:10] <melodie> I'll try to extract both side to side and do a vimdiff, incase that could help (just got the idea)
[20:10] <slangasek> melodie: possibly the usage has changed over time?
[20:10] <melodie> it seems not, I have been told 12.04.2 has the *-remove file
[20:10] <melodie> I just don't know why it is different in some versions
[20:11] <stgraber> melodie: from what I see, you need either "filesystem.manifest-remove" + "filesystem.manifest" or "filesystem.manifest-desktop" + "filesystem.manifest"
[20:11] <stgraber> melodie: you don't need all three of them
[20:11] <dupondje> slangasek: raring-proposed indeed :)
[20:12] <slangasek> dupondje: yes, but why... :) raring-proposed is not meant for use by humans
[20:12] <melodie> it seems two are needed : filesystem.manifest plus one of the two others but what is the difference betweek the two others... this is my question :)
[20:12] <dupondje> pitti: seems like even /dev/sda* does not exist :s
[20:12] <melodie> stgraber where did you see it ?
[20:12] <slangasek> melodie: ubiquity/doc/README seems to explain
[20:13] <melodie> slangasek thanks! me stumble upon it
[20:13] <slangasek> dupondje: did udev not start correctly?
[20:13] <dupondje> slangasek: living on the edge .. :P
[20:13] <slangasek> dupondje: that's not an edge you're supposed to be living on. *it's not for humans.*
[20:13] <slangasek> dupondje: though in this case, perhaps we can be grateful that you hit this bug before it reached raring ;P
[20:14] <dupondje> hehe :P
[20:14] <stgraber> melodie: my understanding is that filesystem.manifest-remove is a list of package to remove, filesystem.manifest-desktop is the list of packages post-installation and filesystem.manifest is the list of everything (equivalent of filesystem.manifest-desktop + filesystem.manifest-remove)
[20:14] <stgraber> melodie: or so the code looks like. I haven't looked at ubiquity/doc/README yet :)
[20:15] <melodie> is that /usr/share/doc/ubiquity/README.gz too ?
[20:16] <stgraber> possibly. I'm looking at lp:ubiquity and it's in doc/README in there
[20:16] <dupondje> /dev/sda* seems to be missing in grub2 console, but it exists when it boots in the temp shell :s
[20:16] <melodie> ok, I'm going there and compare fast
[20:16] <melodie> to see if the zgrep shows the same
[20:18] <cjwatson> manifest-desktop was the old additive one, manifest-desktop is subtractive
[20:18] <cjwatson> er, manifest-remove is subtractive
[20:18] <cjwatson> the latter turned out to be easier to maintain, so is preferred
[20:20] <cjwatson> But you shouldn't have both, except perhaps in unofficial builds; our build system only creates one or the other
[20:21] <melodie> hi cjwatson, so having either or is ok if I understand well ?
[20:21] <cjwatson> correct.  having both is not harmful as such but is pointless.
[20:22] <cjwatson> Support for manifest-remove was added in oneiric; there's really no reason to have manifest-desktop these days.
[20:22] <Laney> hrm, I wonder what happened to my sound device
[20:22] <melodie> I end with a filesystem.manifest, and a filesystem.manifest-desktop, and I was wondering why instead of "filesystem.manifest-desktop" in the official versions there is "filesystem.manifest-remove" hence my question
[20:23] <cjwatson> I have no idea what build system you might be using that still creates manifest-desktop
[20:23] <melodie> this is Ubuntu Builder for the time being.
[20:23] <psusi> cjwatson: do you happen to know the source package responsible for the d-i script 'list-devices'?  I can't seem to find it
[20:23] <cjwatson> I have no idea what that is :)
[20:23] <cjwatson> The discussion that led to its replacement by manifest-remove is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627439
[20:23] <cjwatson> psusi: debian-installer-utils
[20:23] <melodie> thank you very much !
[20:23]  * psusi looks through that one again
[20:24] <psusi> lol... that's why I missed it.. there's separate ones for -linux, -hurd, etc that must get renamed
[20:24] <cjwatson> It's called list-devices-linux in the source package
[20:24] <melodie> and thanks also to stgraber and slangasek who tried to help me;
[20:25] <cjwatson> "Ubuntu Builder" sounds like one of those things with a name that makes it sound more official than it is ...
[20:25] <cjwatson> Which is always unfortunate
[20:34] <Laney> pitti: I just noticed two problems that went away after I ppa-purged the logind PPA (and manually removed systemd-services and other systemd packages) - brightness adjustment wouldn't do anything and I had no audio devices in PA.
[20:35] <Laney> manually removed> I guess you deleted those from the PPA?
[20:42] <dupondje> hmz :( screwed it seems. /dev/sdaX should be available in grub2 console no?
[20:42] <cjwatson> No, that's a Linux device name.
[20:43] <cjwatson> 'ls' will tell you what disks GRUB can see.  They won't be called the same thing that Linux calls them.
[21:04] <dupondje> Ok, finally able to get booted :) seems like /dev/by-uuid is created to late. If I wait some seconds in the busybox, i'm able to boot :)
[21:09] <dupondje> pitti: slangasek: ^^ could be caused by the libudev update somehow?
[21:11] <dupondje> ah well, some other things upgraded also today .. so could be some other updates
[21:25] <slangasek> dupondje: did udev itself get updated on your system?  the by-uuid creation shouldn't depend on anything outside of udev
[21:25] <slangasek> dupondje: though, are the uuids in question related to cryptsetup/lvm?
[21:25] <dupondje> nope normal disk
[21:26] <dupondje> ii  udev                                      175-0ubuntu20                                amd64        rule-based device node and kernel event manager
[21:26] <slangasek> right, then I'm really not sure why anything would have changed if it's only about a normal disk
[21:27] <lool> gema_: could you ask for *@ubuntu.com to be whitelisted?
[21:31] <dupondje> also upgraded grub2 / mountall / upstart / libdevmapper / initramfs-tools / kmod / module-init-tools
[21:31] <dupondje> alot of potential causes :)
[21:32] <slangasek> has nothing to do with grub
[21:32] <slangasek> not if it's gotten you to a kernel
[21:32] <dupondje> yea it does, just boots into a initramfs busybox
[21:36] <slangasek> dupondje: so it's certainly possible that libudev1+initramfs-tools-bin are broken somehow
[21:36] <slangasek> since wait-for-root relies on libudev1
[21:37] <dupondje> Well I can boot now :) but it may be good to get it fixed ^^
[21:37] <dupondje> :P
[21:38] <slangasek> dupondje: can you downgrade initramfs-tools-bin and reboot, see if it still happens?
[21:40] <dupondje> let me see
[21:42] <dupondje> brb
[21:46] <dupondje> slangasek: ok that works
[21:46] <slangasek> dupondje: ok.  can you please open a bug report against initramfs-tools about this?
[21:46] <dupondje> downgraded initramfs-tools & initramfs-tools-bin btw
[21:47] <slangasek> stgraber: ^^ can you please /not/ unblock systemd and friends until further notice?
[21:48] <stgraber> Laney: ^
[21:50] <dupondje> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1154813
[21:50] <Laney> wasn't planning on
[21:50] <ScottK> pitti: ^^^
[21:50] <Laney> but merci
[21:52] <ScottK> It would also, once this is sorted, make sure there's an appropriate test so we don't have to depend on humans running $DEVEL-proposed.
[21:53] <infinity> pitti: While we're on the topic of your libudev rebuilds, why did you break Ubuntu versioning tradition/policy and go with -NubuntuNb1 instead of -Nubuntu$((N+1)) ?
[21:54] <dupondje> good i'm that crazy to run raring-proposed :P
[21:58] <dupondje> bbl, slangasek: thanks for the assistance :)
[22:04] <melodie> good night
[22:05] <ScottK> jdstrand: The last chromium-browser upload for raring that you sponsored is having some rather unfortunate side effects.  See Bug #1154218.
[22:05] <ScottK> yofel: ^^^
[23:06] <bdmurray> mterry: you originally worked on bug 848605 it seems to not have been fixed as you can see in bug 1056545
[23:06] <bdmurray> mterry: I've found a testcase now and put it in the new bug if you could have a look
[23:07] <bdmurray> mterry: according to errors it seems to occur less (if at all) in raring.