[04:49] <Chipmadness> anyone here?
[06:20] <xnox> pitti: adt tests are feeling sad, it seems.
[06:20] <pitti> xnox: morning
[06:20] <xnox> pitti: insserv: warning: script 'S02autopkgtest' missing LSB tags and overrides
[06:20] <xnox> insserv: Service udev has to be enabled to start service nut-server
[06:20] <xnox> insserv: exiting now
[06:20] <xnox>  =))))
[06:20] <xnox> pitti: morning. =) where is autopkgtest init script comming from?! =)
[06:20] <pitti> xnox: yep, just saw; looking at mdadm now (breaking udisks2)
[06:21] <xnox> pitti: i guess autopkgtest is in $ debcheckout -a ?!
[06:21] <pitti> xnox: that's from adt-virt-qemu
[06:21] <xnox> oh, ok.
[06:21] <pitti> xnox: on my list, but the warning is less urgent
[06:21] <pitti> xnox: nut's autopkgtest show unhappyness with udev's
[06:22] <pitti> insserv: Service udev has to be enabled to start service nut-server
[06:23] <pitti> xnox: so I suppose we are missing some corresponding update-rc.d calls?
[06:25] <pitti> xnox: or rather, we need to fix bug 1312836 in debhelper and rebuild the packages
[06:27] <xnox> pitti: true.
[06:27] <pitti> xnox: ah, mdadm-raid is also just from udev.init (Provides:)
[06:29] <dholbach> good morning
[06:29] <dholbach> larsu, HAPPY BIRTHDAY! :-)
[06:30] <xnox> pitti: ok. let me upload debhelper, and then we'd rebuild systemd, check postinst is sane (and calls update-rc.d) and depends on the right version lsb-base.
[06:30] <pitti> xnox: so we already call dh_installinit -R --no-start
[06:30] <pitti> xnox: in theory that ought to craete an /etc/rcS.d/Snnudev, but it seems it doesn't; that's exactly this bug, right?
[06:34] <xnox> pitti: it doesn't, because of above bug, yes. Uploading now.
[06:34] <pitti> xnox: right, just cross-checking that I'm understanding this right
[06:35] <xnox> pitti: not bug, but intentional change in debhelper.... but yeah, now it became a bug.
[06:40] <pitti> xnox: I'm building systemd now with the change reverted locally
[06:41] <TheMuso> c
[06:47] <pitti> xnox: FYI, I added block-proposed again; even if we fix it for udev and the few others which are spotted by autopkgtests, we probably still need to rebuild a few other packages
[06:49] <xnox> pitti: ack.
[06:54] <xnox> rebuilding systemd.... slowly.....
[06:56] <pitti> xnox: my first attempt was broken, I forgot to change postinst-init-norestart too
[06:56] <pitti> now I changed them all, like in https://patches.ubuntu.com/d/debhelper/debhelper_9.20140228ubuntu2.patch
[07:01] <pitti> mvo: halp
[07:01] <mvo> pitti: holp!
[07:01] <pitti> mvo: what was the magic option to apt-get to say "force refresh through proxy"? this is totally not googleable :(
[07:01] <sarnold> pitti: Acquire::http::proxy::192.168.122.1 DIRECT;
[07:01] <pitti> sarnold: wow, I've never seen that one
[07:02] <sarnold> replace IP as needed :)
[07:02] <pitti> I rememvered something like acquire::http:blaproxybla=refresh or similar, not with IP numbers
[07:02] <sarnold> pitti: it's the only way to test packages from a local repository and still use a local caching proxy sanely. :)
[07:02] <sarnold> oh :) there might be something better then? hehe
[07:02] <mvo> pitti: oh, this is the one you are look for ? yeah, what sarnold said, but you may need -o Acquire::http::No-Cache=1 for transparent proxies
[07:02] <pitti> I mean, the proxy has broken/outdated _Packages, and I want to circumvent it / tell the proxy "refresh your files, d***it"
[07:03] <sarnold> pitti: ahhh. no idea there, sorry.
[07:03] <rbasak> sarnold: I do that sort of thing at proxy level. You can tell squid.conf to always refresh.
[07:03] <pitti> mvo: thanks; still didn't help, but I'll experiment further
[07:03] <rbasak> (only for Packages|Release etc)
[07:03] <sarnold> rbasak: that would make creating new VMs a little easier :)
[07:04] <mvo> pitti: hm, the no-cache sends a cache-control: no-cache header, so if the cache is not honoring this its … broken
[07:04] <xnox> pitti: actually, with such a change rebuilding systemd i get strange postinst.
[07:04] <pitti> sarnold: so your command wouldn't work for the transparent proxy on the canonical network supposedly?
[07:04] <xnox> pitti: http://paste.ubuntu.com/7534673/
[07:04] <rbasak> sarnold: http://paste.ubuntu.com/7534674/
[07:04] <mvo> rbasak: squid-deb-prroxy  uses that too
[07:04] <pitti> xnox: oh? it looks quite alright here; and if I ever get rid of the hash sum mismatches I could even test it..
[07:05] <pitti> xnox: ah, I get the same
[07:05] <rbasak> pitti: does that help you?
[07:05] <sarnold> rbasak: oww my eyes glaze over a bit :)
[07:05] <xnox> pitti: it should (a) only one section added by dh_installinit (b) only one call to update-rc.d with the right arguments, i believe.
[07:05] <rbasak> Just lines 28 and 29 are what matter.
[07:05] <pitti> rbasak: sorry, what is "that"?
[07:05] <rbasak> They cause squid to always check for updates to Release and Packages.
[07:06] <mvo> pitti: *cougt* there is a plan to fix the hashsum mismatches that involves rbasak :)
[07:06] <rbasak> pitti: my squid.conf in above paste
[07:06] <pitti> rbasak: (and I don't know what the canonical network uses, presumably squid?)
[07:06] <rbasak> Doing this completely prevents hash sum mismatches from propogating through a proxy.
[07:06] <pitti> rbasak: ah, I suppose it's out of my powers to fix that; I'll try the hotel network
[07:06] <pitti> brb
[07:07] <mvo> pitti: or talk to is maybe?
[07:07] <rbasak> IS also altered the way the files are packaged, so hash sum mismatches should never get cached anyway.
[07:07] <sarnold> rbasak: oh, I've already got that. I wonder why I needed the DIRECT apt-get configuration..
[07:07] <rbasak> Err...s/packaged/published/
[07:10] <pitti> xnox: I know why
[07:10] <pitti> xnox: /usr/share/debhelper/autoscripts/postinst-upstart-replace
[07:10] <pitti> xnox: that needs to go
[07:11] <pitti> xnox: for testing we can just empty the file, for the upload it shold also be dropped from dh_installinit
[07:12] <xnox> pitti: \o/ yes!
[07:12] <pitti> xnox: as in the current diff
[07:13] <pitti> mvo: hotel network also didn't help, so I suppose it's something else; I'll try a different mirror
[07:14] <sarnold> pitti: it might be worth reporting in #ubuntu-mirrors -- they can sometimes poke a refresh
[07:14] <pitti> sarnold: well, I'm still sceptical -- it happens on de.archive and archive alike
[07:15] <sarnold> pitti: oh, interesting
[07:15]  * pitti tries it.archive
[07:15] <pitti> \o/
[07:15] <pitti> ok, that and local apt-cacher-ng == ♥ again
[07:18] <pitti> xnox: my diff -u /var/lib/dpkg/info/udev.postinst /tmp/x/DEBIAN/postinst looks good now
[07:18] <pitti> xnox: where /tmp/x is dpkg-deb -R udev_204-10ubuntu6_amd64.deb /tmp/x
[07:18] <pitti> xnox: and installing that I now have /etc/rcS.d/S02udev -> ../init.d/udev and /etc/rcS.d/S03udev-finish -> ../init.d/udev-finish
[07:19] <pitti> xnox: mdadm and nut install fine
[07:19] <pitti> xnox: so this is looking good \o/
[07:19] <xnox> cool.
[07:19]  * xnox is still building
[07:20] <xnox> (my laptop is slow, i should fix my connection to my server)
[07:21] <LocutusOfBorg1> Hi, can anybody please explain why of a build failure and retry it?
[07:21] <LocutusOfBorg1> tomcat8 ---> missing libeasymock-java (>= 3.0)
[07:22] <LocutusOfBorg1> easymock --> missing libobjenesis-java
[07:22] <LocutusOfBorg1> objenesis in the archive since one month or so
[07:22] <LocutusOfBorg1> why easymock didn't find it?
[07:28] <pitti> xnox: do you understand http://paste.ubuntu.com/7534786/ ?
[07:29] <pitti> xnox: it's apparently because of the new Provides: mdadm-raid
[07:29] <pitti> xnox: ah no, due to Provides: lvm lvm2
[07:35] <xnox> pitti: i still don't like the postinst.
[07:35] <pitti> xnox: what's wrong now?
[07:35]  * rbasak agrees with LocutusOfBorg1
[07:35] <rbasak> Can someone hit the rebuild button on https://launchpad.net/ubuntu/+source/easymock/3.2+ds-2/+build/5937740 please?
[07:35] <rbasak> I can do tomcat8 but not easymock.
[07:36] <pitti> rbasak: done
[07:36] <rbasak> Thanks!
[07:39] <rbasak> LocutusOfBorg1: hmm. It failed again.
[07:39]  * rbasak looks deeper
[07:39] <pitti> rbasak: easymock is in main, libobjenesis-java in universe
[07:39] <pitti>  easymock | 2.5.2+ds-1       | utopic/universe | source
[07:39] <rbasak> Oh
[07:39] <pitti>  easymock | 3.2+ds-2         | utopic-proposed | source
[07:40] <pitti> apparently someone promoted it to main in -proposed
[07:40] <pitti> which looks odd
[07:42] <pitti> GunnarHj: copied PPA to -proposed FYI
[07:44] <LocutusOfBorg1> so rbasak pitti how can we fix this?
[07:45] <rbasak> I think an archive admin will need to untangle it
[07:46] <rbasak> Oh..pitti is one :)
[07:48] <mardy> pitti: hi! I'm trying out https://code.launchpad.net/~pitti/ubuntu-system-settings-online-accounts/py3tests/+merge/221118 on the desktop
[07:48] <xnox> pitti: meeting at the moment.
[07:49] <mardy> pitti: it works fine, but if I pass the "-v" option to autopilot3-sandbox-run, then it complains
[07:49] <mardy> (getopt: invalid option -- 'v')
[07:55] <pitti> mardy: oh, hang on, that's odd -- is that in my MP?
[07:55] <mardy> pitti: yes, in debian/tests/autopilot
[07:55] <pitti> LocutusOfBorg1, rbasak: I figure we need to find out why it was promoted to main, whether it was an error or an ongoing MIR
[07:55] <pitti> mardy: checking
[07:56] <pitti> mardy: ah, I probably mixed that up with autopilot3 -v
[07:57] <pitti> mardy: right, needs an extra -a; re-running test now
[07:58] <pitti> mardy: odd that the whole test didn't fail; that sounds like a mis-handling of exit codes, thanks for pointing out
[08:01] <pitti> xnox: found it
[08:02] <GunnarHj> pitti: Thanks! ( as regards the langpacks :) )
[08:06] <rbasak> doko: looks like moving to lua5.2-dev regressed apache2: bug 1323930
[08:06] <rbasak> Seems to me that not much supports lua5.2 yet. I think nginx was the other one. From my perspective, anyway.
[08:07] <rbasak> Googling around it looks like other distros have had this issue too.
[08:08] <pitti> mardy: branch updated, confirmed to work now
[08:08] <pitti> mardy: I'll see to fix the wrong ap3-sandbox-run exit code
[08:11] <sarnold> rbasak: I think what you're remembering is that nginx didn't support lua 5.2: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710
[08:13] <rbasak> sarnold: right
[08:13] <rbasak> So neither does apache2 AFAICT.
[08:14] <doko> rbasak, jamespage: please fix it
[08:18] <rbasak> doko: er...please don't regress packages? You want me to upload a new apache2 to build against liblua5.1-0-dev again, since that's still in main?
[08:18] <rbasak> Looking at https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710/comments/25 here - strikes me that this is the same.
[08:24] <pitti> xnox: ok, I fixed udev's dependency loop with the lvm2 error; standing by for adding a versioned debhelper build dep and uploading the fix
[08:24] <pitti> xnox: can you ping me when you are done with your meeting? I'll join you
[08:26] <LocutusOfBorg1> pitti, https://bugs.launchpad.net/ubuntu/+source/easymock/+bug/589193
[08:26] <LocutusOfBorg1> is this the reason?
[08:27] <pitti> LocutusOfBorg1: that's not a MIR; let me demote it for now, if it's needed it'll reappear in component-mismatches
[08:27] <LocutusOfBorg1> don't know what a MIR means :) sorry
[08:27] <pitti> main inclusion report
[08:27] <pitti> request
[08:27] <LocutusOfBorg1> ah ok yeah
[08:28] <pitti> done
[08:28] <sarnold> easymock has been in main from lucid-trusty, in universe in utopic...
[08:28] <pitti> needs a publisher cycle, then the build should auto-start (it's depwait)
[08:30] <LocutusOfBorg1> so the next tomcat8 will be in universe?
[08:31] <sarnold> I think that'll be the default disposition unless someone files a MIR and steps to up be a bug subscriber
[08:31] <pitti> mardy: thanks for approving; do I need to do anything, or will the landing happen magically?
[08:31] <pitti> mardy: where "magically" means "the landers will pick it up at some point" (it's not urgent of course)
[08:32] <mardy> pitti: we'll land it ourselves, soonish :-)
[08:33] <pitti> dpm: do we know that the current PPA langpack fixes that? (for -sv)
[08:33] <dpm> pitti, I don't know, let me clarify that on the e-mail and ask them to test it
[08:34] <pitti> dpm: I'll search the current .deb from the archive and ask on the bug
[08:34] <dpm> awesome, thanks pitti
[08:46] <cyphermox> xnox: bottom device is your usb dongle, top one is the integrated chip in my laptop: http://paste.ubuntu.com/7535167/
[09:09] <pitti> dpm: .. if LP wouldn't keep timing out
[09:10] <dpm> pitti, I know, I've pinged wgrant about it, but it seems it's not a trivial fix
[09:10] <wgrant> dpm, pitti: Which timeout?
[09:11] <pitti> I reloaded https://launchpad.net/~ubuntu-langpack/+archive/ppa?field.series_filter=saucy about 15 times, it seems it's finally working now
[09:12] <dpm> wgrant, it's not possible to finish any translations in LP without getting a timeout at some point
[09:12] <wgrant> dpm: Yeah, a lot of that will go away with the new DB servers in a couple of weeks, and we're actually planning on working on the stuff that *won't* be fixed later this afternoon.
[09:13] <wgrant> We haven't worked on it in a couple of years, as there are fundamental flaws in the schema which make it impossible to perform well on HDDs
[09:13] <wgrant> We'd have to spend either 9 months on reengineering rosetta from the inside out, or moving to SSDs
[09:13] <wgrant> And the new DB servers have SSDs.
[09:13] <wgrant> There are other issues on top of thse DB performance problems, but it wasn't worth spending time on them until we had a solution to the underlying DB problem.
[09:14] <wgrant> And now we do, so we're spending time this week on sorting it out.
[09:14] <wgrant> *Hopefully* most of the timeouts will be gone in a month ish.
[09:14] <pitti> dpm: ah, we never actually built saucy langpack updates, it seems
[09:14] <dpm> wgrant, that sounds great, looking forward to that, thanks for the details!
[09:14] <pitti> dpm: for swedish, any way
[09:14] <pitti> http://ppa.launchpad.net/ubuntu-langpack/ubuntu/pool/main/l/language-pack-sv/
[09:14] <dpm> wgrant, not sure you saw the ping in lp-ops, but do you have any updates re: opening the utopic translations?
[09:15] <pitti> dpm: so we need to identify the particular fix, and manually SRU the package for saucy
[09:16] <dpm> pitti, what do you mean by "identify the particular fix"? Would the last exported .po file for software-properties-gtk not include the fix already?
[09:16] <stgraber> xnox, pitti: where are we with fixing nut so we can get all those packages finally migrating from proposed?
[09:17] <wgrant> dpm: I tried to get webops time for that yesterday, but failed. I'll try again this afternoon.
[09:17] <dpm> thanks wgrant
[09:20] <shadeslayer> pitti: https://jenkins.qa.ubuntu.com/job/utopic-adt-kde4libs/ARCH=amd64,label=adt/lastBuild/console < could you tell me what the error is? I can't quite figure out what went wrong
[09:20] <shadeslayer> the hook works locally here
[09:20] <dobey> dpm: do you know when a new version of calculator will go into the image btw?
[09:21] <dpm> dobey, some time this week. I need to release all core apps to include the new translations done for the MAE image
[09:21] <dobey> dpm: great. i've been waiting for translations to show up :)
[09:23] <dpm> dobey, cool :) - btw, I noticed a side effect whereby if the .desktop file is in /usr/share, the Name is shown translated as well. You can see it in action switching to the zh_CN locale and looking at the System Settings and Media Player icons in My Apps
[09:23] <dpm> in 'es' they appear translated too
[09:24] <dobey> dpm: yes
[09:24] <dobey> dpm: those are not click packaged apps though
[09:24] <dpm> yeah, I know, I just thought I'd mention it
[09:24] <dobey> dpm: it would be nice to get the translations into the .desktop files for those too, but we are currently using the gettext domain for them (we can, because they're debs and more predictable)
[09:30] <xnox> stgraber: yes, there will be ~25 more uploads to go together.
[09:30] <xnox> stgraber: we want to rebuild those, such that they gain update-rc.d call, cause they are dependencies of other packages and insserv might break if one has those installed.
[09:31] <xnox> stgraber: (that's part of the fix for nut as well, plus 24 others....)
[09:33] <pitti> stgraber: sorry, my network hung for a while, I missed your ping; but I'm sitting next to xnox, we are doing the rebuilds
[09:42] <stgraber> pitti: ok, do we need all of them to go in at once or can we start with nut so adt is happy and we stop building broken packages in PPAs?
[09:43] <stgraber> pitti: also, where are you sitting? :)
[09:43] <pitti> stgraber: we have all 25 prepared now, but we can bump the score of nut of course
[09:43] <xnox> stgraber: we can land it as soon as debhelper & systemd rebuilds.
[09:43] <xnox> stgraber: to unbreak the world/ppas
[09:43] <pitti> stgraber: because potentially all of them can break upgrades
[09:43] <xnox> stgraber: waiting for debhelper at the moment.
[09:43] <pitti> stgraber: (in -proposed; we have a block there)
[09:44] <xnox> stgraber: we are in 3C or something.
[09:44] <pitti> stgraber: in studio 2b
[09:44] <xnox> stgraber: 2b
[09:44] <pitti> stgraber: once debhelper is published, we can upload the lot
[09:44] <ogra_> mterry, https://lists.ubuntu.com/archives/kernel-team/2014-May/043153.html ... so now the next beer is due for apw and/or rtg to fast-path this ...
[09:45] <mterry> ogra_, awesome
[09:47] <pitti> stgraber: we'll most probably need to ignore the openvswitch failure, that started failing on infinite hangs a few weeks ago
[09:50] <shadeslayer> pitti: any idea?
[09:52] <pitti> shadeslayer: about what? sorry, I missed some parts of IRC due to disconnect
[09:52] <shadeslayer> pitti: https://jenkins.qa.ubuntu.com/job/utopic-adt-kde4libs/ARCH=amd64,label=adt/lastBuild/console
[09:53] <shadeslayer> pitti: all it says is adt-run: unexpected error: test dependencies are unsatisfiable , but I don't know what it could not satisfy
[09:53] <pitti> shadeslayer: that looks like a conflict between iputils-ping and inetutils-ping?
[09:53] <dpm> pitti, not sure you saw the question earlier, you were saying you got disconnected -> <pitti> dpm: so we need to identify the particular fix, and manually SRU the package for saucy
 pitti, what do you mean by "identify the particular fix"? Would the last exported .po file for software-properties-gtk not include the fix already?
[09:53] <pitti> shadeslayer: http://paste.ubuntu.com/7535513/
[09:53] <shadeslayer> hm, true
[09:53] <shadeslayer> thanks, didn't see that
[09:53] <pitti> dpm: well, I hope; that's what my question was
[09:56] <shadeslayer> pitti: it's odd that it worked in my pbuilder
[09:58] <dpm> pitti, so I guess we'll have to scan through the deltas here to find out the one with the fix: https://translations.launchpad.net/ubuntu/saucy/+language-packs
[09:58] <dpm> let me see if I can find it...
[10:00] <dpm> pitti, ah, luckily the latest delta export includes the fix already :)
[10:04] <dpm> pitti, updated the bug with the info
[10:15] <dpm> hi GunnarHj, around?
[10:15] <GunnarHj> dpm: Yes
[10:16] <dpm> GunnarHj, hey, thanks so much for getting the langpack schedule and the workflow back in shape!
[10:16] <GunnarHj> dpm: You're welcome. It was the question from the Swedish team that made me wonder...
[10:17] <dpm> yeah, we're trying to get that sorted
[10:18] <GunnarHj> dpm: I suppose we don't need that much of organizing with respect to the releases between the LTSs.
[10:19] <dpm> GunnarHj, I think it'd still be good to plan a couple of updates, but we can keep it light
[10:19] <GunnarHj> dpm: Right.
[10:19] <dpm> GunnarHj, also, you were saying you were looking for some feedback: so everything looks perfect, the only thing I'd suggest is to do the call for testing after the uploads to -proposed have been finished, so that folks can start testing straight away.
[10:21] <GunnarHj> dpm: Yeah, actually it has already been on the main server for a while; I'm not sure about the mirrors, which is why I said "soon".
[10:21] <dpm> GunnarHj, ah, perfect
[10:22] <rbasak> infinity: around? May I have an opinion on bug 1323930 please, from the perspective of https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1262710/comments/25? Is it OK for Apache to depend on lua 5.1 also, for the same reason as nginx?
[10:22] <rbasak> doko or anyone else: ^^
[10:23] <rbasak> I've tested a fix with lua 5.1 locally - it fixes the regression.
[10:23] <rbasak> I'm also wondering about SRUing Trusty
[10:23] <infinity> rbasak: Without reading the bug, I'd say that's fine.
[10:24] <rbasak> OK, thanks.
[10:25] <infinity> rbasak: Yeah, after reading the bug, my opinion hasn't changed.  I think we need to sort out a way forward for lua between now and 16.04, but since we're supporting it in 14.04 already, that's fine for apache2 in 14.04 as well, and for the next few short-support releases, if we don't have a better solution right away.
[10:25] <infinity> rbasak: But let's no forget about this before 16.04, cause supporting lua 5.1 forever seems ungood.
[10:26] <rbasak> infinity: OK. Perhaps I should file a bug for lua 5.2 support with tasks for apache2 and nginx.
[10:26] <rbasak> I get the impression that lua 5.2 is a bit more like python 2.7->3.0 than python 2.6->2.7, IYSWIM
[10:27] <infinity> rbasak: On the C side, it certainly has some "fun" API changes, but nothing world-ending.  It just needs someone with both time and carefactor to port things.
[10:32]  * rbasak filed bug 1324062
[10:32] <rbasak> (with apache2 and nginx tasks)
[10:33] <rbasak> doko: ^^ I guess you'll want to track this?
[10:35] <doko> rbasak, jamespage: this is called +1 maintenance, so please forward this to the person in the server team doing +1 maintenance
[10:35] <doko> for now, assigned to the server team
[11:35] <seb128> dholbach, hey, can you commit your gnome-settings-daemon upload from yesterday to the vcs?
[12:35] <dholbach> seb128, urgh, ok
[12:38] <seb128> dholbach, danke
[12:42] <dholbach> seb128, done
[12:50] <seb128> dholbach, danke
[12:51] <mardy> rsalveti: hi! Does the emulator work in Utopic? I can't install it ("ubuntu-emulator-runtime:i386 : Depends: libgl1-mesa-glx:i386 but it is not going to be installed")
[12:53] <mlankhorst> mardy: so figure out what is going on there ;-) try apt-get install libgl1-mesa-glx:i386 ?
[12:55] <mardy> mlankhorst: it depends on libudev{0,1}:i386, but neither are installeble (the "0" does not exist, the "1" seems to be wanting to remove libqt5gui, and consequently half of the system)
[12:59] <mlankhorst> ugh :/
[13:00] <mlankhorst> but it needs libudev to do anything useful.. probably some multiarch issue then?
[13:00] <mlankhorst> are you running -proposed by any chance?
[13:08] <TheMuso> S/quit
[13:15] <seb128> RAOF, thanks
[13:34] <pitti> stgraber: hm, I think the openvswitch block didn't work: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lsb
[13:34] <pitti> stgraber: what's interesting there is that this shows the previous version of openvswitch (smells like another britney bug)
[13:34] <pitti> that might explain why your ignore doesn't work?
[13:36] <pitti> stgraber: that's now holding up the entire stack as it seems
[13:36] <stgraber> pitti: you should be in #ubuntu-release ;)
[13:36] <stgraber> (britney appears confused, cjwatson suggested a workaround which I know just pushed, we'll see with the next run)
[13:37] <pitti> stgraber: merci
[14:47] <wgrant> dpm: utopic translations are importing
[14:47] <dpm> \o/
[14:51] <dpm> wgrant, so what's the next step? Opening the translations in the LP UI?
[18:26] <brendand> anyone know what this really means? insserv: Service dbus has to be enabled to start service <x>
[18:26] <brendand> i've had a rough upgrade and getting that for several packages
[18:26] <brendand> lightdm
[18:26] <brendand> avahi-daemon
[18:26] <brendand> etc
[18:27] <brendand> this is probably clearer: http://paste.ubuntu.com/7538356/
[18:49] <genii> Might be missing symlink to /run from /var/run
[22:30] <LLKCKfan> Hello
[22:30] <LLKCKfan>  How can someone who is almost 30 and never had a job get one? I have been applying just to be told I am not what they are looking for (We have reviewed your application for this position and will be proceeding with other candidates at this time.) or they are not hiring.
[22:43] <genii> LLKCKfan: Please stop spamming the same stuff about not finding a job in every channel you go to. It's annoying and usually offtopic for the channels you're doing it in.