=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[03:58] <pitti> Good morning
[04:15] <pitti> stgraber: did you see that LXC's autopkgtest started failing? new kernel or so? (Operation not permitted - overlayfs: error mounting /home/lxcunpriv/.local/share/lxc/c1/rootfs)
[04:48] <infinity> pitti: That's a kernel bug, fixed in proposed.
[04:49] <pitti> ah! /me re-runs the test thene
[04:49] <pitti> yesterday it was still failing
[04:50] <pitti> ah good, http://autopkgtest.ubuntu.com/packages/l/lxc/wily/i386/ ran with -3.3 and succeeds
[04:53] <infinity> pitti: Any idea when mvo usually gets in?
[04:54] <pitti> infinity: he used to start early too (around nowish), but TBH I haven't tracked him recently
[04:57] <infinity> pitti: I thought you Germans all knew each other. :P
[04:57] <pitti> there's only some 80 million of us, how could we not :)
[04:57] <infinity> Exactly.
[05:12] <infinity> pitti: Hey look, lxc passed.  Yay.
[05:12] <pitti> \o/
[05:12] <infinity> stgraber: Ignore pitti, all resolved with the new kernel.
[05:12] <pitti> infinity: since my conversation with apw yesterday I have a WI to make LXC triggered by new kernels
[05:13] <pitti> now I know where that came from :)
[05:13] <infinity> Now I just need an apt wizard to sort out https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1479207
[05:13] <ubottu> Launchpad bug 1479207 in apt (Ubuntu Trusty) "Never-MarkAuto-Sections not working correctly" [Critical,New]
[05:14] <infinity> pitti: That could be solved by me getting around to that dpkg-source patch (oops), and us adding the kernel to lxc's test deps, I suppose.
[05:14] <infinity> pitti: It's a slight lie, but it would do the trick without extra string and glue.
[05:14] <pitti> yeah, that would be more elegant
[05:14] <pitti> it would also greatly help the DKMS case
[05:15] <infinity> pitti: Yeah, DKMS is a special beast.  Since I consider it a critical bug if a dkms *binary* package depends on kernel headers, but having those deps in the test deps would be fine.
[05:15] <infinity> Which reminds me, I need to fix an SRU to remove a header dep that accidentally got added.  Whee.
[05:17] <infinity> pitti: Do test deps use dpkg-style [arch] parsing?
[05:17] <infinity> pitti: So I can have foo [amd64], bar [powerpc]?
[05:18] <pitti> yes
[05:18] <infinity> Excellent.
[05:18]  * infinity goes to fix blktap-dkms with some violence.
[05:18] <pitti> anything that libdpkg-perl can parse/resolve
[05:19] <pitti> i. e. arches, multi-arch tags, and since recently also build profiles
[05:19] <infinity> Not sure build-profiles make sense for autopkgtest deps, but yay anyway.
[05:19] <pitti> for their build deps
[05:20] <pitti> debian bug 787093
[05:20] <ubottu> Debian bug 787093 in autopkgtest "autopkgtest: dpkg-deb chokes with build profiles in Build-Depends:" [Normal,Fixed] http://bugs.debian.org/787093
[05:23] <infinity> Err, wat?
[05:23] <infinity> pitti: Where does http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/job/wily-adt-blktap-dkms/lastBuild/ARCH=amd64,label=adt/ come from?
[05:23] <infinity> pitti: The package itself doesn't have a debian/tests
[05:23] <infinity> pitti: Manually created job, I guess?  That would explain why your new infra didn't run it, only the old one did.
[05:24] <pitti> infinity: autodep8 rather, I figure
[05:25] <pitti> infinity: we test perl, ruby, and dkms packages with a synthesized debian/tests/ from autodep8
[05:25] <pitti> infinity: but indeed the old infra didn't auto-create these either, hmm; let me look
[05:26] <pitti> infinity: ah, it did, sorry
[05:26] <pitti> there's a special hack in adt-britney for DKMS
[05:26] <pitti> right, that needs to be taught to britney
[05:26] <pitti> (I have a work item for that)
[05:27] <infinity> pitti: It's not a very special hack, that's literally the only dkms package that ran a test on the last kernel upload. :P
[05:27] <pitti> yeah, it has never been working very well :)
[05:30] <infinity> pitti: More bizarely, your new infra ran a *different* test that the old one didn't...
[05:30] <pitti> open-iscsi?
[05:30] <infinity> pitti: See excuses for linux.  Old infra: blktap/linux/glibc, New infra: open-iscsi/linux/glibc
[05:30] <infinity> pitti: Yeah.  Wut? :)
[05:30] <pitti> infinity: yeah, it seems britney's own reverse dependency map catches more things
[05:31] <infinity> Ahh.
[05:31] <infinity> Well, if it's universally catching more, that sounds good to me.
[05:31] <pitti> e. g. alternatives
[05:32] <pitti> just not sure why open-iscsi is being triggered in particular
[05:32] <pitti> oh, the udeb perhaps?
[05:33] <infinity> Could be.
[05:33] <infinity> britney likes udebs, but most home-grown revdep parsers would ignore debian-installer/* because oops.
[06:06] <infinity> pitti: Hrm.  autopkgtest results in trusty are getting dangerously close to useful.
[06:07] <pitti> eek, how can we fix that? :-)
[06:08] <infinity> pitti: Probably need to sit down and comb through current failures and smear some blame around between packages, tests, and infrastructure.
[06:08] <infinity> pitti: Or, as you're imlpying, just make everything fail again. :P
[06:12] <infinity> checking for x86_64-linux-gnu-gcc... no
[06:12] <infinity> pitti: Do the debci trusty images not have build-essential?
[06:13] <infinity> pitti: Would explain why libreoffice works in the old infra and not your shiny new one.
[06:13] <pitti> infinity: ah, they indeed don't; that was a custom hack I added to the jenkins job
[06:13]  * pitti adds WI
[06:14] <pitti> infinity: thanks for pointing out
[07:04] <dholbach> good morning
[09:06] <infinity> pitti: You ate mvo, didn't you?  That's why you weren't willing to commit to his whereabouts.
[09:06] <pitti> *munch* *munch*
[09:11] <sidi> Should -dev packages for libraries on Debian/Ubuntu contain the .so? If so, what should the original lib package contain?
[09:13] <ogra_> infinity, it is because telegram is the new email ... he only sent his "where is michael" to the team via telegram ;)
[09:13] <ogra_> (he it out for two weeks)
[09:15] <ogra_> *is
[09:20] <pitti> IMs are not a replacement for email :)
[09:22] <ogra_> pitti, and hangouts are not a replacement for IRC :P
[09:22] <pitti> correct :)
[09:22] <ogra_> (sadly not everyone thinks so )
[09:25] <infinity> ogra_: Two weeks?  Erk.  That's... Not going to end well for my point release.
[09:25]  * ogra_ checks again before telling lies
[09:26] <ogra_> yeah, back on monday 10th ... from US TZ
[09:26] <ogra_> (at a sprint then)
[09:27] <infinity> Whee.
[09:40] <pitti> rbasak: do you know, is there a PPA for juju 1.23 with systemd support?
[09:41]  * pitti would like to use juju-local again
[09:44] <rbasak> pitti: https://launchpad.net/~juju/+archive/stable
[09:44] <rbasak> pitti: 1.24.3 is there and has systemd support.
[09:44] <pitti> ah, nice!
[09:44] <pitti> OOI, what's holding it back?
[09:45] <pitti> i. e. should it not be installed yet because of known regressions or so?
[09:45] <rbasak> There are some reported regressions that they haven't confirmed yet, but I think they only affect big production use
[09:45] <rbasak> I'm pushing to get to the point where they don't release upstream unless they consider it OK to upload to Ubuntu too (including Trusty) but they're not quite at this stage yet.
[09:46] <rbasak> So right now they release with a "please don't upload to Ubuntu" caveat, which isn't great.
[09:46] <pitti> ok; I don't use juju for anything on my laptop (only from wendigo for devops), so there isn't that much to break for me :)
[09:46] <rbasak> AIUI, for juju-local then 1.24.3 is fine.
[09:46] <pitti> rbasak: I'll try that, thanks!
=== Elimin8r is now known as Elimin8er
[10:21] <seb128> doko, hey
[10:21] <seb128> doko, in which case do we need to update build-depends for the gcc transition?
[10:21] <seb128> do we need to make sure rename packages build with gcc5?
[10:22] <seb128> through some b-d
[10:22] <doko> no, assume that it's the default
[10:22] <seb128> k
[10:23] <doko> probably for Debian, but buildd admins assured me they would update the chroots when I pull the trigger
[10:23] <seb128> works for me, thanks
[10:23] <doko> the other thing which might be nice would be updated b-d's for c++ b-d's
[10:51] <pitti> Laney: FYI, I fixed packages.json, e. g. http://autopkgtest.ubuntu.com/data/status/wily/i386/packages.json
[10:52] <pitti> Laney: useful for checking for tmpfail, etc.
[10:53] <seb128> doko, I uploaded a first batch to 039 from the script, going for lunch now and going to continue after, I would appreciate if you had a look just in case there is something wrong or that you would recommend changing
[10:54] <doko> seb128, k, maybe a review before upload would be nice?
[10:54] <seb128> doko, I did review those manually before upload
[10:54] <seb128> they look fine to me, but just in case I'm forgetting something
[10:55] <doko> do you rename -dbg packages too?
[10:56] <seb128> good point, no I didn't, should we?
[10:56] <seb128> bbiab
[10:57] <doko> seb128,  gflags (2.1.2-2ubuntu1~gcc5.1ubuntu1)  -> .1.2-2ubuntu1
[10:57] <pitti> Laney: and Brandon is working on https://wiki.debian.org/debci/mockups?action=AttachFile&do=view&target=tmpfail_list.png which is much nicer :)
[10:59] <doko> seb128, google-glog (0.3.4-0ubuntu2~gcc5) -> 0.3.4-0ubuntu2
[11:00] <doko> using the ~gcc5 version for no-change uploads only
[11:03] <doko> seb128, pangomm just fails because glibmm needs a rebuild for the renamed libsigc++
[11:03] <doko> and I should get doxygen working again ...
[11:05] <Laney> pitti: nice, so e.g. "GET http://autopkgtest.ubuntu.com/data/status/wily/i386/packages.json | jq '.[] | select (.status == "tmpfail") | .package'" works
[11:05] <pitti> Laney: oh, I wasn't aware of jq, thanks
[11:08] <Laney> it's useful as a pretty printer too, if you call it as 'jq .'
=== rickspencer3_ is now known as rickspencer3
=== dpm_ is now known as dpm
=== MacSlow is now known as MacSlow|lunch
[11:50] <pitti> rbasak: hm, juju boostrap works, but juju deploy cs:rabbitmq-server creates a STOPPED juju-trusty-lxc-template which never starts, and the new "1" instance stays pending  forever
[11:50] <pitti> juju-agent-martin-local.service and juju-db-martin-local.service are running, though
[11:52] <pitti> I see a neverending stream of mongod authenticate requests (no errors, though)
[11:53] <rbasak> pitti: sorry, that's beyond me now (apart from seeting if I can reproduce and filing a bug). Try in #juju maybe?
[11:53] <pitti> rbasak: ack, will do
[11:53] <pitti> I'll give it some more time before that
[11:54] <rbasak> pitti: 1.24.4 is in rc at the moment I think. Might be worth trying that (though I was under the impression that changes did not affect juju-local). Note though that you have to tweak your configuration to run an rc though.
[11:55] <pitti> rbasak: ah, there's actually some progress; I guess bootstrapping the first container just took a while
[11:57] <rbasak> pitti: https://bugs.launchpad.net/juju-core/+bug/1478232 maybe? There has been talk about performance issues.
[11:57] <ubottu> Launchpad bug 1478232 in juju-core 1.24 "juju 1.24 poor performance" [High,Triaged]
[12:04] <pitti> doesn't sound like that, the martin-local-1 machine just never comes up (lxc-attaching, it doesn't ifup eth0)
=== _salem is now known as salem_
=== MacSlow|lunch is now known as MacSlow
[13:23] <seb128> doko, thanks for the version hint, wasn't glib rebuilt in silo 016?
[13:24] <doko> seb128, yes, but using the not renamed libsigc++
[13:24] <seb128> doko, I see, fixing it
[13:29] <tseliot> Laney: hi, do you mind if I assign my new merge request to you? It's about this previous merge request, only this time I wrote it, and it doesn't block: https://code.launchpad.net/~timchen119/unity-settings-daemon/unity-settings-daemon.1471708.trusty/+merge/264163
[13:30] <tseliot> (the new merge request is not there yet)
=== elopio_ is now known as elopio
[13:34] <seb128> doko, slangasek, why is libpinyin in the 016 ppa while it's not on https://people.debian.org/~doko/logs/gcc5-20150701/ and doesn't have c++ symbols?
[13:38] <doko> seb128, slangasek uploaded everything with a dependency on libstdc++6 which is on the touch image. but you see that it kept the dependency on libstdc++6 (>= 4.1.1), so no new symbols are introduced
[13:39] <seb128> doko, k
=== greyback__ is now known as greyback
[14:24] <doko> tjaalton, mesa ping ...
[14:25] <doko> libxatracker2 mesa-vdpau-drivers libgl1-mesa-dri needs renaming, however I know that we have a lot of dependencies on ibgl1-mesa-dri
[14:27] <caribou> Q: when doing an SRU for a debian native package, should we use quilt to change the package or modify the source directly ?
[14:27] <caribou> (ifenslave in that context)
[14:28] <rbasak> I would modify the source directly
[14:29] <rbasak> quilt would be nice but if there's no mechanism in place for that already then it seems quite invasive to put that in (whether for an SRU or just an Ubuntu delta in the dev release). But I'm not on the SRU team.
[14:35] <smoser> pitti, (or since rbasak last talked, he probably knows anyway)
[14:35] <smoser> in dep-8, can i do an upgrade test at all?
[14:36] <smoser>  install version A
[14:36] <smoser>  do something
[14:36] <smoser>  upgrade
[14:36] <smoser>  do something else (verify that my data is still present)
[14:36] <pitti> smoser: sure, your test can call apt-get or dpkg, whatever it likes
[14:36] <Laney> tseliot: request a review from me in addition to the default team please
[14:36] <pitti> smoser: the main restriction is that you need to be able to get the old version A from somewhere
[14:36] <tseliot> Laney: ok, thanks
[14:37] <smoser> pitti, right. so in the case where it is in -updates , and my new upload is in somewhere else, thats easy enough
[14:44] <doko> seb128, could you keep https://wiki.ubuntu.com/GCC5 up to date?
[14:44] <seb128> doko, yeah, I planned to do that at the end at the afternoon to avoid editing it every 5 minutes
[14:45] <doko> ok
[14:46] <doko> working on ptlib
[14:52] <tjaalton> doko: renaming why?
[14:53] <doko> tjaalton, nm, just needs a rebuild for the renamed libllvm2.6
[14:53] <tjaalton> ah
[14:54] <pitti> smoser: could you please boot wolfe-08 again? I foolishly powered this off, I thought I was still in a container on it
[14:54] <smoser> silly pitti
[14:54] <smoser> :)
[14:54] <smoser> will do
[14:54] <pitti> smoser: thanks!
[14:56] <smoser> system up, pitti
[14:56] <smoser> ok, now up.
[14:56] <pitti> smoser: I'm back in, thanks
[15:10] <tseliot> Laney: ok, I've just made two merge requests: https://code.launchpad.net/~albertomilone/unity-settings-daemon/non-blocking-touch-mapping-trusty/+merge/266249 and https://code.launchpad.net/~albertomilone/unity-settings-daemon/non-blocking-touch-mapping-wily/+merge/266248
[15:16] <Laney> tseliot: ok, thanks, will try to look soon
[15:16] <tseliot> Laney: thanks
[15:20] <Laney> tseliot: upstream bug still welcomed btw :)
[15:20] <doko> working on protobuf
[15:21] <tseliot> Laney: I mentioned that in the commit: https://bugs.launchpad.net/oem-priority/+bug/1471708
[15:21] <ubottu> Launchpad bug 1471708 in unity-settings-daemon (Ubuntu) "SRU: For skylake system, u-s-d cause a black screen when resume from S3 via Lid Close" [High,In progress]
[15:23] <Laney> tseliot: I mean at intel(?)
[15:26] <tseliot> Laney: oh, that. I'll file one. These changes really improve my touch screen mapping code from last year, so it will be good to have them regardless of when/whether the upstream bug is fixed
[15:26] <Laney> tseliot: Sure, just would be good to get to a place where it always works ;)
[15:26] <Laney> anyway, noted down to review
[15:26] <tseliot> Laney: I obviously agree ;)
=== salem_ is now known as _salem
=== _salem is now known as salem_
[17:12] <pitti> seb128, doko: what can I do tomorrow morning to help with the gcc-5 bits?
[17:13] <pitti> seb128, doko: is that "fix FTBFSes in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages"? or is there a different TODO list/tracker?
[17:13] <seb128> doko, pitti, I'm done for today/updating the wiki, those are the packages that remain on the list doko gave me yesterday
[17:13] <seb128> http://paste.ubuntu.com/11960809/
[17:13] <seb128> pitti, ^ you might look at some of those, doing renames
[17:14] <seb128> see https://wiki.ubuntu.com/GCC5
[17:14] <doko> pitti, 16 is waiting on tvoss
[17:14] <seb128> we use silo 039 for those renames to not make 016 not installable
[17:14] <pitti> ah, ok
[17:14] <doko> pitti, you could create transition trackers for the packages in the wiki page
[17:15] <pitti> infinity: trusty testbeds now install b-e, libo is now back to PASS
[17:17] <pitti> doko: ah, I've never done that, (1) do we have docs for that, and (2) is that needed for small transitions?
[17:17] <doko> Laney, ^^^
[17:18] <pitti> ok, I need to leave for basketball, I'll talk to you tomorrow morning I guess
[17:18] <doko> pitti, or else seb128 could send you his script, and you continue with the renaming
[17:19] <seb128> doko, there is only some ~10 remaining and they are a bit less standard/more complicate packages mostly, which might not work well with the script
[17:19] <doko> ok
[17:19] <seb128> I think we can do those manually
[17:19] <pitti> so would looking at the FTBFS in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+packages be a good start?
[17:20] <doko> pitti, then there is https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org
[17:20] <doko> ordered by libstdc++ dependency lvel: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790756
[17:20] <ubottu> Debian bug 790756 in release.debian.org "transition: libstdc++6 cxx11" [Normal,Open]
[17:21] <pitti> ok, I'll look at what seb128 did in 039 and look at FTBFS, or just wait until you get online tomorrow morning
[17:21]  * pitti gotta run, thanks!
[17:22] <seb128> pitti, have fun!
[17:23] <seb128> doko, pitti, I've updated https://wiki.ubuntu.com/GCC5 with the renames I did today
[17:25] <mitya57> jtaylor, can you please look at ipython autopkgtests regression? https://jenkins.qa.ubuntu.com/job/wily-adt-ipython/lastBuild/ARCH=amd64,label=adt/consoleFull
[17:25] <mitya57> it breaks some stuff like sphinx or pygments from migrating
[17:26] <doko> seb128, did you reupload pcre3?
[17:27] <doko> ahh, no
[17:40] <jtaylor> mitya57: looks like a regression in python3.5 itself
[17:41] <jtaylor> hitting a notimplemented error during a normal import
[17:43] <jtaylor> I'll try upstream ipython with 3.5 later
[17:49] <seb128> doko, oh, sorry, I did but I got a rejected email apparently, it was on your list and I didn't notice you had it uploaded
[17:50] <mitya57> jtaylor, thanks
=== athairus is now known as afkthairus
[18:40] <doko> xnox, T - 2
[19:09] <Laney> doko: make the script output them or something
[19:09] <Laney> it doesn't seem feasible to create this by hand
[19:47] <ScottK> Laney: For some reason I seem to still be getting the DMB meeting wiki page diffs even though I'm not personally subscribed to the page.  I guess there's something else I forgot to unsubscribe from.  Do you know what that might be?
[19:50] <chiluk> hey infinity, slangasek, https://bugs.launchpad.net/ubuntu/+source/targetcli/+bug/1479424  ... I'm not sure what happens when it's pretty obvious a package isn't installable.  What do you guys recommend we do?  I'm thinking remove packages from archives altogether.
[19:50] <ubottu> Launchpad bug 1479424 in targetcli (Ubuntu) "Failure to install lio-utils on fresh cloud-image" [Undecided,New]
[19:55] <ScottK> Laney: nvm.  I think I figured it out.
[19:58] <infinity> chiluk: When packages are buggy, the usual thing to do is to fix them.
[19:59] <infinity> chiluk: And given that your test case is precise, removal isn't an option anyway.
[20:00] <ari-tczew> how to force package to built with --std=c++11 ?
[20:00] <chiluk> yeah that's what I figured.
[20:00] <chiluk> infinity..  it looks like lio-utils has been deprecated upstream.. and afaik that's due to changes in newer kernels.
[20:00] <chiluk> which is part of the reason lio-utils is failing to be installable.
[20:00] <infinity> ari-tczew: CXXFLAGS += --std=c++11 ?
[20:01] <infinity> ari-tczew: Or the moral equivalent thereof for whatever build system.
[20:02] <chiluk> infinity, also lio-utils doesn't show up in popcon at all..
[20:02] <infinity> chiluk: popcon is a pretty bad way to determine if something should be removed from the archive.
[20:02] <chiluk> infinity, this package never should have gotten passed any kind of testing.
[20:02] <infinity> chiluk: Dead upstream is a better way, for sure.
[20:02] <infinity> chiluk: Also, "removed from Debian" is compelling.  You should have led with that.
[20:03] <chiluk> yeah it's deprecated in favor of targetcli which is deprecated in favor of tgt... iscsi is a steaming pile..
[20:03] <chiluk> infinity, I hadn't checked.
[20:03] <infinity> chiluk: targetcli, however, is still in Debian, so I question your linking the two together.
[20:03] <chiluk> targetcli in ubuntu has a dependency on lio-utils.
[20:03] <ari-tczew> infinity: I guess "export CXXFLAGS += --std=c++11" should works in debian/rules, right?
[20:03] <ari-tczew> or better withour export
[20:04] <infinity> chiluk: I assume that dependency you speak of isn't there in wily.
[20:04] <chiluk> infinit so maybe that dependency shouldn't be there.
[20:04] <ari-tczew> without*
[20:04] <infinity> chiluk: It's not 2012 anymore.
[20:04] <chiluk> infinity, are you saying you don't like supporting things for 5 years?
[20:05] <infinity> chiluk: I'm saying that we're not *removing* it from any stable releases, so come up with a better solution for precise.
[20:05] <infinity> chiluk: For wily, lio-utils is dropped from Debian, and we should do the same.  And targetcli doesn't depend on it.
[20:05] <chiluk> ok that's useful info.
[20:05] <chiluk> I'm still recommending that users of targetcli or lio-utils move to tgt.
[20:06] <chiluk> and i think I will leave it at that.
[20:06] <chiluk> since removal is not an option.. and it was likely deprecated because of incompatibility with the new 3.2 kernel!
[20:06] <infinity> Err.  It was already removed from wily.
[20:06] <infinity> Even better.
[20:06] <chiluk> well great.
[20:07] <chiluk> thanks infinity
[20:08] <infinity> chiluk: Anyhow, you can have your precise tasks, if someone decides to fix it properly in precise. :P
[20:36] <doko> Laney, seb is the script writer, but I assume we want at least some for the big transitions
[21:29] <doko> robert_ancell, about the gnome mm stack, please see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-039/+packages
[21:30] <doko> could you have a look at pangomm? if you decide to update to new upstream version, please do it in this ppa, and not anymore in the archive
[21:30] <doko> ohh, and the ppa has a debpendency on the landing16 ppa
[21:32] <doko> infinity, do you have an update about the ubiquity issue?
=== salem_ is now known as _salem
[21:35] <robert_ancell> doko, ok
[21:38] <infinity> doko: The cherry-pick fixed it, yes.  Should have followed up to the python bug.
[21:38] <infinity> doko: Doing that now.
[22:18] <robert_ancell> doko, I'm fixing atkmm too
[22:23] <robert_ancell> doko, I notice scim half built - it seems to be a temporary issue with the GTK+ packages. Any reason not to retry the failed builds?
[22:36] <doko> robert_ancell, mir needs a rebuild first, working on it
=== afkthairus is now known as athairus
[23:52] <mwhudson> is logging in to the wiki expected to work currently?
[23:55] <RAOF_hates_all_c> Hm. All my Ubuntu entries disappeared from my grub menu, and now Windows is holding my laptop hostage.
[23:56] <RAOF_hates_all_c> It is literally impossible for me exit Windows without disassembling my laptop and yanking the battery.
[23:57] <infinity> RAOF_hates_all_c: That seems suboptimal.
[23:58] <infinity> RAOF_hates_all_c: Can't boot to USB?
[23:58] <RAOF_hates_all_c> Can't reboot.
[23:58] <infinity> RAOF_hates_all_c: ...?
[23:58] <RAOF_hates_all_c> Windows isn't speaking to either the keyboard or the touchpad, and the power button causes it to suspend.
[23:58] <infinity> RAOF_hates_all_c: Even holding the power button for $absurdly_long_time?
[23:58] <RAOF_hates_all_c> *Before* the 5 second "oh, you really really want to turn off" threshold of the firmware kicks in.
[23:59] <infinity> RAOF_hates_all_c: Plug in a USB keyboard and see if Windows likes that one better than the builtin PS/2 device?
[23:59] <infinity> (also, wow, good job on getting windows to hate your builtin keyboard)