[00:08] <micahg> stokachu: not as much as I used to be, but if somethings needed, I can try to squeeze it in
[00:08] <stokachu> micahg: is there someone who took up that task?
[00:27] <micahg> stokachu: I think the 3 of us who are "active" do it as we have time
[04:09] <stevengottlieb> i have a question regarding my software update for 12.10
[04:09] <stevengottlieb> hello?
[04:36] <stokachu> can i get https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=gpoint approved?
[04:57] <mlankhorst> gday
[05:04] <RAOF> maaaaaaaate
[05:17] <mlankhorst> no!
[06:30] <pitti_> Good morning
[06:34] <zyga> good morning
[06:48] <mardy> kaleo: hi! I was asked to check if the SDK team had any opinion about this: https://lists.ubuntu.com/archives/ubuntu-devel/2013-March/036935.html
[06:54] <apachelogger> cjwatson: hey, if you get a chance today it would be cool if you could have a look at https://code.launchpad.net/~kubuntu-members/debian-cd/kubuntu-raring-artwork/+merge/157998
[07:06] <tjaalton> @pilot on
[07:06] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[07:07] <tjaalton> pilot in
[07:07] <tjaalton> bah
[07:07] <tjaalton> @pilot in
[07:10] <dholbach> good morning
[08:19] <cjwatson> apachelogger: you definitely want to switch to HIDDEN_TIMEOUT=2 (i.e. the same desktop image boot workflow that Ubuntu uses)?  I don't object, just wanted to double-check that
[08:19] <cjwatson> apachelogger: that's also a UI-freeze-worthy change - are there any relevant docs?
[08:28] <apachelogger> cjwatson: yes on the hidden timeout, see bug 1164854 for freeze exception
[08:30] <cjwatson> gotcha, thanks
[08:33] <cjwatson> apachelogger: it'll probably take LP a while to notice, but it's merged and deployed now, thanks
[08:33] <apachelogger> cjwatson: thank you :)
[08:51] <ev> bdmurray, pitti: have you heard many reports of reporting to Launchpad still being enabled post-release in 12.10?
[08:51] <ev> trying to find the right google terms for that :)
[08:51] <pitti> ev: no, I didn't; that might happen for people who manually re-enable it?
[08:51] <ev> very doubtful in this case - a designer in the office has it enabled on 12.10
[08:52] <ev> I'll see what else I can find
[08:52] <seb128> ev, maybe they played with the control center privacy settings (does that change apport's status?)?
[08:53] <ev> seb128: that only toggles whoopsie running
[08:53] <seb128> ok
[08:53] <seb128> apport is enabled in the /etc config ?
[08:53] <ev> maybe they've pulled in some 13.04 bits
[08:53] <ev> yeah
[08:53] <ev> in /etc/default/apport
[08:54] <seb128> ok, weird
[08:54] <seb128> dunno either then
[08:54] <seb128> ev, is it possible that they reported a bug, got asked for details and copied/pasted the command from the stock reply that tell them the command to enable apport?
[08:59] <ev> seb128, pitti: she doesn't appear to have enabled it herself or taken instruction from anyone else to do so. She's also not running anything from raring as far as she's aware. It sounds like a fairly stock system.
[08:59] <ev> I've asked to have a look at her computer again later today
[09:00] <ev> I'll see what I can dig up then
[09:00] <seb128> ok
[09:00] <pitti> ev: the precise contents of /e/d/apport would be interesting; perhaps it was modified years ago already
[09:00] <seb128> look at when the /etc file got edited and the packages installed around this time in dpkg.log maybe
[09:00] <ev> will do to both :)
[09:37] <mpt> ev, remarkable how that most common error in R is much more common in weekdays than weekends ... pre-release, I would have expected the opposite.
[09:37] <ev> :D
[09:37] <ev> I'm always encouraged when it challenges our preconceptions
[09:38] <lifeless> mpt:, ev: o/
[09:38] <ev> hi!
[09:38] <mpt> o/`
[09:45] <maxb> I've been using R for my office workstation for weeks, I just have a dual boot to Q on standby in case it all goes horribly wrong
[09:52] <mpt> ev, if we were tracking hangs by now, I get the feeling we'd be seeing a lot in update-manager
[09:53] <seb128> right
[09:54] <seb128> the computation to sort depends from an app under the app icon seems to be quite slow
[10:00] <doko> seb128, what about allowing the deprecated glib functions for the final release of 13.04 again? would save a lot of effort to fix the ftbfs now
[10:01] <seb128> Laney, pitti: ^ opinions?
[10:02] <seb128> doko, do you have specific deprecations you would like to comment/drop?
[10:02] <seb128> we can't just turn any deprecations off
[10:02] <doko> meh :-/
[10:02] <pitti> FTBFS because of packages which disable deprecated symbols, but use them?
[10:02] <seb128> pitti, yes
[10:02] <seb128> in universe
[10:03] <seb128> doko, how many of those are left?
[10:03] <seb128> should be easy enough to drop the G_DISABLE_DEPRECATED flags, but I'm not sure how many sources we are talking about there
[10:03] <pitti> I don't like changing glib itself to not mark them as deprecated, because that would be a lie
[10:03] <seb128> same here
[10:03] <doko> I didn't count, but it's every third or fourth package I'm touching
[10:03] <doko> at least the g*'s
[10:03] <seb128> how many are left on the ftbfs list?
[10:03] <doko> 520
[10:04] <seb128> hum
[10:04] <seb128> crazy
[10:04] <pitti> for "dead" software we'll keep having this problem, so at some point we need to fix (or remove) those anyway
[10:04] <seb128> right
[10:05] <seb128> I would rather trying a bit harder to "clean" those and not change glib
[10:05] <pitti> so maybe we can find some five people and a day to go through them and drop G_DISABLE_DEPRECATED
[10:05] <seb128> I can help having a look through the list and fix some
[10:05] <pitti> or remove the software if it's not even working any more, etc.
[10:06] <Laney> right, I agree
[10:06] <seb128> doko, pitti: let me try to build a list of affected sources from the build logs
[10:06] <seb128> then we can try to call for help dealing with those
[10:06] <Laney> maybe someone from +1 would help out
[10:06] <Laney> also mail the motu list
[10:06] <seb128> the 5 a days would work for me
[10:06] <pitti> ack
[10:06] <seb128> ok, let's do that
[10:06] <pitti> I can help out there, too; it should be possible to get through some 20 FTBFSes on one day
[10:09] <seb128> doko, do you know why > q on that list only failed on armhf? most of those build issues don't seem armhf specific
[10:09] <doko> seb128, see https://launchpad.net/builders
[10:10] <seb128> doko, ok, other arches didn't get to those yet
[10:10] <doko> yes :-/
[10:25] <pitti> doko: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html is still the current one, right?
[10:29] <seb128> doko, Laney, pitti: ftbfs i386 due to glib deprecations: http://paste.ubuntu.com/5694973/
[10:29] <seb128> well those are the ones that match "grep "is deprecated " *.txt | grep glib"
[10:29] <seb128> in the 229 i386 ftbfses
[10:29] <seb128> doing the same for other arches
[10:29] <pitti> seb128: ah, I was looking at some 20 packages, and so far I didn't find a single one; many are due to missing -lm, or breakage which is specific to that pacakge
[10:29] <seb128> right
[10:30] <seb128> same here
[10:30] <seb128> pitti, I did some hackish, grep on the .html, wget of the logs and "grep "is deprecated " *.txt | grep glib" on the stack of lgos
[10:30] <seb128> logs
[10:30] <pitti> seb128: I'll just take the first 20?
[10:31] <seb128> pitti, if you want, please
[10:31] <pitti> seb128: for NM tests I'm kind of blocked on reaching Dan Williams anyway, and I'm not feeling too awake today anyway
[10:31] <pitti> so this seems like the perfect job for a day with just half a brain :)
[10:31]  * seb128 hugs pitti
[10:32]  * seb128 runs the loop of wget on the ~400 armhf build issues
[10:37] <ogra_`> 400 ?
[10:38] <ogra_`> where do you see these ?
[10:38] <ogra_`> the fstbfs list doesnt have as many
[10:38] <seb128> ogra_`, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.html
[10:39] <seb128> ogra_`, universe is over 500
[10:39] <ogra_`> geez
[10:39] <ogra_`> there werent as many last week !
[10:39] <seb128> ogra_`, build was not done, there is still 3 days of build backlog on i386/amd64
[10:40] <ogra_`> yeah, who cares for these obsolete arches
[10:40] <seb128> lol
[10:41] <seb128> Laney, pitti, doko: that's the end of the list (using armhf): http://paste.ubuntu.com/5695016/
[10:41] <seb128> total is 59 glib related ftbfses
[10:41] <pitti> seb128: would you mind putting them into an etherpad?
[10:42] <pitti> easier for coordination
[10:42] <ogra_`> would be really nice if the ftbfs UI could filter builds that only fail on one arch
[10:42] <seb128> Laney, pitti: http://pad.ubuntu.com/glib-deprecated-ftbfs
[10:42] <seb128> that's the full list
[10:43] <Laney> thanks
[10:43] <Laney> i'll take some this afternoon
[10:44] <pitti> seb128: ^5s
[10:44] <seb128> thanks
[10:44] <seb128> pitti, ^5s ;-)
[10:46] <seb128> $ grep "try adding it to the linker command line" *.txt | sed 's#buildlog_ubuntu-raring-armhf.##' | sed 's#_FAILEDTOBUILD.*##' | sort | uniq  | wc -l
[10:46] <seb128> 113
[10:46] <seb128>  
[10:46] <pitti> that's mostly -lm?
[10:46] <seb128> so twice as many due to missing -l
[10:47] <seb128> pitti, 40 due to libm
[10:48] <seb128> pitti, I've added the "missing -lm" to the bottom of the pad
[10:48] <seb128> http://paste.ubuntu.com/5695026/
[10:48] <seb128> rather
[10:48] <seb128> let's not mix stuff
[10:51] <pitti> seb128: you seem to have some false positives there; easyspice is due to -lm, not due to glib
[10:52] <pitti> as we have them in your last paste, I'll just drop it from the pad
[10:52] <seb128> pitti, ups
[10:53] <mpt> seb128, thanks for the hint, I reported bug 1167277 about it
[10:54] <pitti> seb128: and e. g. ecore also only has those as warnings, not failures
[10:54] <pitti> seb128: (it fails due to 'PRIO_PROCESS' undeclared, which I can't find anywhere)
[10:54] <seb128> pitti, Laney: ok, list down to 11 ...
[10:54] <pitti> ah, nice
[10:54] <seb128> pitti, sorry, I matched warnings only before
[10:55] <seb128> those have "error: ... is deprecated ... glib..."
[10:55] <pitti> ok, so for 11 FTBFSes we shouldn't change glib, but just fix them
[10:55] <pitti> I'm fine to do those this afternoon
[10:55] <seb128> pitti, thanks
[10:55] <seb128> doko, ^ doesn't help you much though :-(
[10:56] <Laney> how come doko thought there were loads due to that then?
[10:56] <pitti> seb128: is that the first block on the pad now?
[10:56] <seb128> Laney, he crossed a few while doing fixes
[10:56] <Laney> just seeing warnings due to glib which failed for some other reason
[10:56] <mpt> ev, end of an era -- the list of bugs in Errors no longer fits one on page of a default Launchpad listing
[10:56] <seb128> pitti, yes
[10:56]  * mpt wonders if we can persuade wgrant to increase the default batch size from 75 to 100
[10:56] <pitti> seb128: did you see buzztard and cutter-testing-framework in your updated grep?
[10:56] <pitti> seb128: these were due to glib (I just uploaded fixes for those two)
[10:57] <geser> seb128: instead of greping the .html file, you can also grep the .csv file (but it only lists one log if a package fails on several archs) (http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20130329-raring.csv)
[10:57] <seb128> pitti, hum, no, the error is no "deprecated" but "unknow type" ... will add that to my grep, one min
[10:58] <pitti> seb128: I'll just take your first block then
[10:58] <seb128> buzztard_0.6.0-1
[10:58] <seb128> cutter-testing-framework_1.1.7-1.2ubuntu1
[10:58] <seb128> gnome-pie_0.5.4-1build1
[10:58] <seb128> thoggen_0.7.1-1ubuntu1
[10:58] <seb128>  
[10:59] <seb128> pitti, those are the only 4 in that case
[10:59] <pitti> ok, added those
[10:59] <seb128> pitti, danke
[11:00] <seb128> geser, thanks, I just used the file to have the list of logs to wget, that worked ... maybe next time ;-)
[11:00] <doko> pitti, language packs did arrive :-/
[11:01] <pitti> yeah, at some point we'll need an update; but they should build on i386 in about an hour, it's just updates
[11:02] <seb128> doko, those 5 had dpkg errors, you might want to retry them
[11:02] <seb128> arpack++_2.3-2
[11:02] <seb128> cairo-clock_0.3.4-2ubuntu2
[11:02] <seb128> haskell-regex-tdfa_1.1.8-2build2
[11:02] <seb128> krename_4.0.9-1build1
[11:02] <seb128> ncap_1.9.2-1build1
[11:03] <Laney> hmm, that's a release version of regex-tdfa
[11:03] <Laney> there's a newer version in proposed - did the rebuild not take that into account?
[11:03] <Laney> (not that I'm saying this version is fixed)
[11:06] <doko> Laney, no, rebuild is for the release pocket only. not interested in test rebuilds in things which we don't release. and not everything stays that long in -proposed like haskell ;p
[11:07] <seb128> Laney, could you look at the tomboy one? it seems something with the libappindicator sharp bindings, likely a libappindicator issue but you probably know better how the "find the dll" stuff works
[11:07] <zyga> barry: ping
[11:07] <Laney> seb128: yes - can you update the pad?
[11:08] <Laney> doko: well, we certainly intend to release everything in proposed ...
[11:08] <seb128> Laney, done
[11:08]  * zyga found a python3 bug?
[11:08] <ev> mpt: we can fix that :)
[11:10] <zyga> or python3/python2 bugs
[11:10] <zyga> wft
[11:12] <doko> zyga, ?
[11:13] <zyga> doko: eh, sorry, nothing
[11:13] <zyga> doko: I thought I found a python3 metaclass inhertiance regression
[11:13] <zyga> doko: but it was my fault for using type(...) vs type.__new__(mcls, ...)
[11:14] <zyga> doko: just quickly tested that on precise/raring and it works
[11:31] <ev> apw: I found the problem with getting kernel oops reports on https://errors.ubuntu.com. Fixing now.
[11:35] <Laney> seb128: I think that the problem is that libappindicator0.1-cil-dev is an arch:all package but has pkgconfig files in a multiarch directory
[11:35] <seb128> Laney, oh
[11:36] <apw> ev, nice thanks
[11:36] <Laney> ie packaging bug
[11:36] <seb128> Laney, thanks for investigating ;-)
[11:36] <Laney> should be easy to fix
[11:36] <seb128> Laney, let's make the binary arch any then?
[11:37] <cjwatson> is it architecture-dependent in any other way?  if not, better to move the .pc file to /usr/share/pkgconfig/
[11:37] <Laney> That would be weird because the library is arch:all
[11:37] <Laney> I'll move the pkgconfig file
[11:38] <seb128> that makes sense
[13:02] <barry> zyga: hi.  problem all sorted out?
[13:04] <zyga> barry: yes, my bad: type(...) != type.__new__()
[13:04] <zyga> barry: subclass did not seem to inherit metaclass
[13:04] <barry> zyga: ah.  fun stuff. :)
[13:05] <zyga> barry: not pythonic :)
[13:05] <zyga> barry: well, I learn every day
[13:08] <barry> zyga: if you ain't learnin' you ain't livin'! :)
[13:09] <zyga> barry: is that because type.__new__() somehow super-calls __new__ again while type() does not?
[13:14] <barry> zyga: well, hard to know exactly what's going on without looking at your code, but suffice to say, these are tricky corners of the language
[13:15] <zyga> barry: I have a few line example
[13:15] <barry> zyga: pastebin!
[13:16] <zyga> barry: https://gist.github.com/zyga/5354531
[13:17] <zyga> barry: basically, look at that, if you replace type.__new__() with type() - it fails
[13:31] <barry> zyga: py3 docs on __new__: http://docs.python.org/3/reference/datamodel.html?highlight=__new__#object.__new__
[13:31] <barry> but this makes sense, because three-arg type() is a constructor
[13:31]  * barry ->reboots
[14:04] <seb128> @pilot in
[14:09] <pitti> seb128: bah, I fixed two causes of FTBFS in thoggen, and now I see that it doesn't build against our current (i. e. already years old) hal, and against our current dbus
[14:09] <pitti> last build was in jaunty
[14:10] <pitti> at some point we must drop hal stuff anyway, so I'm really inclined to just remove that package; objections?
[14:10] <seb128> pitti, hal is on the ftbfs list btw ;-)
[14:10] <seb128> pitti, no objection from me
[14:11] <pitti> ah, it got removed from testing, too
[14:11] <xnox> pitti: do not remove hal !!!!
[14:11] <pitti> we should have removed it about 3 years ago, but some ancient and dead software still depends on it
[14:11] <mdeslaur> pitti: flash needs it
[14:11]  * xnox still wants Amazon Pay-to-view to work in US and Google Play Movies work in US/UK/other? and Adobe Flash DRM to work as well.
[14:12] <pitti> xnox: but for now I only want to remove thoggen
[14:12]  * mdeslaur misunderstood
[14:12]  * pitti congratulates xnox as our new hal maintainer :)
[14:12] <mdeslaur> xnox: congrats! :)
[14:13] <pitti> seriously, this stuff uses hal!?
[14:13] <pitti> does that even work still these days?
[14:13] <xnox> pitti: i'm on vacation today, so don't take me too seriously =)))))
[14:13] <mdeslaur> pitti: i think it uses hal to get the hard disk serial number for drm
[14:14] <xnox> pitti: yes, all of that $drm-crap works on top of flash which depends on hal.
[14:14] <pitti> flash certainly doesn't pull in hal
[14:14] <xnox> hmmm....
[14:14] <mdeslaur> pitti: it doesn't fail if hal isn't installed, but it disabled drm
[14:16] <tjaalton> slangasek: so, fixing lightdm isn't that easy after all, since plymouth-splash could be stopped already before lightdm is about to start (able to hit that here)
[14:17] <tjaalton> slangasek: and adding 'and (stopped plymouth or started plymouth-splash)' means the transition isn't as smooth anymore
[14:20] <pitti> doko: could you please retry gnome-pie on ARM? This error ("unknown type name 'GCancellab'
[14:20] <pitti> doko: ...) doesn't make any sense
[14:21] <pitti> sun rays/RAM corruption/etc ?
[14:21] <pitti> it builds fine on amd64, and "GCancellab" doesn't appear any where in the code
[14:21] <doko> pitti, done
[14:21] <pitti> thanks
[14:22] <pitti> doko: that's it then, all the rest of glib-induced failures uploaded
[14:22] <pitti> (and got accepted)
[14:22] <pitti> seb128: ^ FYI
[14:23] <seb128> pitti, danke
[14:23] <seb128> doko, pitti, I've fixed some of the -lm issues, will try to do some every day
[14:24] <doko> seb128, thanks!
[14:24] <seb128> yw ;-)
[14:25] <doko> tried to revert that one in binutils, but that seems to be tangled with other uploads, maybe glibc
[14:25] <seb128> doko, specifically libm or linking being pickier?
[14:27] <doko> seb128, there are other libs too, but libm and libpthread are the ones which are seen many times. there were some libgmodule-2.0 (or such) too
[14:29] <bdmurray> ev: no, but I haven't looked
[14:35]  * dholbach hugs seb128
[14:35]  * seb128 hugs dholbach back
[14:39] <slangasek> tjaalton: hmm, ok
[14:41] <Quintasan> ...
[14:42] <Quintasan> why on earth I can't login into cups admin panel with my username and password when I am in the lpadmin group?
[14:54] <ogra_> doko, looking at the ants buioldlog it seems to think it hits an ICE, do you think it makes sense to give it back at least once ?
[14:55] <doko> Please submit a full bug report,
[14:55] <doko> with preprocessed source if appropriate.
[14:55] <doko> See <file:///usr/share/doc/gcc-4.7/README.Bugs> for instructions.
[14:55] <doko> The bug is not reproducible, so it is likely a hardware or OS problem.
[14:55] <doko> it even tells you =)
[14:55] <ogra_> i know that it tells me :P
[14:56]  * ogra_ was there during that reading class back then :P
[14:56] <ogra_> doko, i'll do a local build later then to collect that
[14:57] <doko> ogra_, wait until the build finishes ...
[14:58] <ogra_> oh there is a build running ?
[14:58] <ogra_> i wish the ftbfs UI would reflect that
[14:58] <ogra_> bah, 2min old :P
[15:02] <ogra_> doko, bino looks like a rebuild candidate too (bus error while unpacking deps)
[15:02] <ogra_> doko, err, sorry that was brise
[15:03] <ogra_> (wrong row)
[15:03] <doko> given back
[15:35] <dholbach> can somebody moderate my mail on u-d-a?
[15:37] <cjwatson> dholbach: done
[15:37] <dholbach> thanks cjwatson
[15:52] <menace> are there dbg-packages for nautilus in ubuntu precise?
[15:53] <menace> if yes: in which package? there is no nautilus-dbg
[15:55] <Sarvatt> menace: https://wiki.ubuntu.com/DebuggingProgramCrash debug symbol section on there, its nautilus-dbgsym
[15:57] <seb128> @pilot out
[15:58] <seb128> menace, nautilus-dbgsym like for any other binary, you just need to enable the ddeb source
[15:58] <seb128> or Sarvatt already replied
[16:14] <menace> 1
[16:15] <Laney> 2
[16:15] <menace> sry, kvm-switch...
[16:15] <menace> :D
[16:28] <jim00234> hi
[16:32] <Laney> apachelogger: are your kdiff3 and im-config patches forwarded?
[17:41] <tjaalton> @pilot out
[18:16] <zyga> hi
[18:16] <zyga> I just got locked out of my laptop
[18:16] <zyga> raring desktop, I updated / rebooted
[18:16] <zyga> secure boot blocked my system
[18:16] <zyga> cjwatson: ^^ ?
[18:17] <zyga> I disabled secure boot, I'm now in 3.8.0-17
[18:23] <zyga> I've updated to 3.8.0.17.33
[18:23] <zyga> let's see
[18:26] <zyga> same
[18:26] <zyga> hmm
[18:26] <zyga> pitti: do you know who would be the best person to debug this?
[18:37] <infinity> slangasek: Can you remind me where the Debian bug for that WUR issue was?  I lost context somewhere in the last few days.
[18:45] <slangasek> infinity: what's 'WUR'?
[18:45] <infinity> slangasek: warn-unused-result
[18:47] <infinity> slangasek: I thought it was a samba bug, but can't find it, and now I can't find context for our conversation either, leading me to wonder if I've gone (more) insane.
[18:48] <infinity> Oh, hah.  But the last "git show" in my bash history is for 7e66ee5142deda977163d0a858c3d2883cae3f07 which happens to be the commit with the liberal application of __wur.
[18:48] <slangasek> infinity: ah right - I think it was on cifs-utils?
[18:48] <infinity> So, I don't have the bug tracker context, but I have the code.
[18:49] <infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=701422
[18:49] <infinity> slangasek: That's it, thanks.
[18:57] <mlankhorst> slangasek: runlevel is set to 2 from telinit, can plymouth-stop run because of stopped rc RUNLEVEL=2, before rc RUNLEVEL=2 is started?
[18:58] <slangasek> mlankhorst: I'm confused by the question. Are you asking whether a 'stopped rc RUNLEVEL=2' event would be seen before a 'started rc RUNLEVEL=2' event would be emitted?
[18:58] <mlankhorst> yeah
[18:58] <slangasek> it cannot
[19:01] <mlankhorst> meh something weird is happening though
[19:28] <tjaalton> I can't get --verbose work with upstart on raring
[19:28] <tjaalton> initctl log-priority still shows info
[19:29] <tjaalton> after adding the option to cmdline
[19:30] <stokachu> could i get someone to approve nominations for bug 1069570
[19:40] <slangasek> tjaalton: the kernel commandline?
[19:40] <slangasek> tjaalton: it definitely WFM
[19:47] <tjaalton> slangasek: yeah, not here :)
[19:48] <slangasek> tjaalton: ah, in fact 'initctl log-priority' shows the same for me, but I'm definitely /getting/ logging
[19:49] <tjaalton> where does it log?
[19:50] <tjaalton> upstart cookbook says 'grep init: /var/log/syslog' but nothing there
[19:55] <slangasek> tjaalton: it logs to dmesg, effectively
[19:56] <slangasek> tjaalton: and there's a bug in recent releases that I haven't pinned down which prevents this from finding its way into syslog
[19:56] <slangasek> (presumably a kernel or rsyslog bug)
[19:57] <tjaalton> slangasek: ahh, yeah dmesg has them
[20:47] <zyga_> hi
[20:47] <zyga_> I need help figuring out why my raring system stopped booting in secure mode
[20:47] <zyga_> anyone interested?
[20:48] <slangasek> zyga_: "secure mode" meaning UEFI Secure Boot, or something else?
[20:48] <zyga_> slangasek: yes
[20:48] <zyga_> sorry
[20:48] <zyga_> a bit hectic over here (real life problems piling up, almost contained now)
[20:49] <slangasek> zyga_: where does it break down?  Can you still boot older kernels?
[20:49] <zyga_> slangasek: I was on 3.8.0-5, rebooted to -17 failed to boot in secure boot mode
[20:49] <zyga_> slangasek: I tried they all seem to have failed
[20:49] <slangasek> hmm
[20:49] <zyga_> I could not access grub easily though
[20:49] <zyga_> I can now reinstall -5 and other kernels (I have a local mirror with --no-cleanup)
[20:49] <zyga_> and retest anyway you like
[20:50] <zyga_> this is a lenovo g580 system
[20:50] <zyga_> it never had secure boot issues before
[20:50] <zyga_> it works since december last year
[20:50] <slangasek> how do you mean, "could not access grub easily"?  there's the problem that holding shift doesn't work to display the grub menu, but you should still get the grub menu after any failed boot
[20:50] <zyga_> slangasek: I didn't get either
[20:50] <zyga_> slangasek: I managed to get into normal boot and edit /etc/default/grub enough to access the menu
[20:51] <slangasek> well, there was an upload of grub2 just yesterday
[20:51] <slangasek> it's possible something regressed as a result of the rebuild :/
[20:51] <zyga_> slangasek: would it affect secure boot or are those unrelated?
[20:52] <slangasek> zyga_: well grub is the bootloader, so it's relevant to secure boot
[20:52] <zyga_> slangasek: ok, I can install -17 (current) and -16 only
[20:52] <zyga_> right
[20:52] <zyga_> silly me
[20:52] <zyga_> sorry
[20:53] <zyga_> I thought we used a shim
[20:53] <slangasek> that's the first stage bootloader only
[20:53] <slangasek> (and hasn't been changed)
[20:53] <zyga_> isn't that what is actually signed?
[20:53] <zyga_> ok
[20:53] <zyga_> I'm not sure if my messages were from bios, shim or grub though
[20:53] <zyga_> what would you advise checking?
[20:54] <slangasek> can you try downgrading to grub-efi-amd64-signed 1.11+2.00-12ubuntu1 and grub-efi-amd64 2.00-13ubuntu2 ?
[20:54] <zyga_> let's see if I have it already
[20:54] <slangasek> what messages?
[20:54] <zyga_> yes, I have that
[20:54] <zyga_> slangasek: failed secure boot messages
[20:55] <slangasek> well, if you can quote me the message I can probably tell you where it's from ;)
[20:55] <zyga_> I'd have to reboot, I'll write it down the next time
[20:56] <zyga_> slangasek: ok, let me install those packages
[20:57] <zyga_> slangasek: can I just dpkg -i the relevant debs?
[20:57] <slangasek> zyga_: yes; if you do it that way, you'll need to include the matching grub-efi-amd64-bin and grub2-common packages
[20:57] <zyga_> ok
[20:58] <zyga_> can I do it via apt somehow?
[20:59] <slangasek> zyga_: IFF those versions are still in your cache
[20:59] <slangasek> (your apt cache, not the physical cache on disk)
[20:59] <zyga_> slangasek: I have that in my mirror
[20:59] <zyga_> but it's probably not in Packages
[20:59] <zyga_> anyway
[20:59] <zyga_> let's do it manually
[20:59] <slangasek> anyway, it's probably not worth figuring out how to do it with apt, you might as well just dpkg -i the 4 packages
[20:59] <zyga_> right
[20:59] <zyga_> there are also -bin packages
[20:59] <zyga_> should I get them/
[21:02] <slangasek> zyga_: grub-efi-amd64-bin, grub-efi-amd64, grub-efi-amd64-signed, grub2-common, grub-common - AFAICS that's what you need
[21:02] <zyga_> ok, let me try
[21:02] <slangasek> (I overlooked grub-common the first time, sorry)
[21:02]  * zyga_ tries to munge that into shell
[21:04] <zyga_> $ sudo dpkg -i grub2/grub-common_2.00-13ubuntu2_amd64.deb grub2/grub2-common_2.00-13ubuntu2_amd64.deb grub2-signed/grub-ef
[21:04] <zyga_> i-amd64-signed_1.11+2.00-12ubuntu1_amd64.deb grub2/grub-efi-amd64_2.00-13ubuntu2_amd64.deb grub2/grub-efi-amd64-bin_2.00-13ubuntu2_amd64.deb
[21:05] <zyga_> trying
[21:05] <zyga_> ok, installed
[21:05]  * zyga_ *had* to install mirror just to get this recovery option ;)
[21:05] <zyga_> slangasek: shall I reboot and re-enable secure boot now?
[21:05] <slangasek> zyga_: that's the thing to try
[21:05] <zyga_> ok
[21:06] <zyga_> brb
[21:10] <zyga> slangasek: it failed the same way, I took a photo
[21:10] <zyga> slangasek: let me share it
[21:11] <zyga> slangasek: https://plus.google.com/116315264177593873442/posts/9UUGFQ2cphM
[21:12] <slangasek> zyga: mmm.  Do you have the shim and shim-signed packages installed?
[21:12] <slangasek> zyga: (the answer is that these messages are from firmware)
[21:14] <zyga> yes
[21:14] <doko> stgraber, python-cffi is the new way to write python bindings
[21:14] <zyga> oh
[21:14] <zyga> no
[21:14] <zyga> I don't?
[21:14] <zyga> I have shim-signed
[21:14] <zyga> slangasek: I don't have shim
[21:14] <slangasek> zyga: ok, that should be sufficient
[21:15] <zyga> slangasek: http://paste.ubuntu.com/5696609/
[21:15] <slangasek> zyga: what's the output of 'sudo efibootmgr -v'?
[21:15] <zyga> slangasek: dpkg --get-selections
[21:15] <zyga> http://paste.ubuntu.com/5696611/
[21:16] <slangasek> zyga: md5sum /boot/efi/EFI/ubuntu/grubx64.efi ?
[21:16] <zyga> bb8cea9bb89a83aa714bd175d61cf5bc  /boot/efi/EFI/ubuntu/grubx64.efi
[21:17] <slangasek> zyga: doesn't match the shim-signed binary
[21:18] <slangasek> zyga: so, we should figure out where it does come from
[21:18] <zyga> slangasek: how did you figure that out, from this line: ?
[21:18] <zyga> Boot0001* Ubuntu	HD(1,800,2f000,947c5c3f-fa10-495c-b18d-97a7c757148f)File(\EFI\ubuntu\grubx64.efi)RC
[21:19] <slangasek> zyga: well, I mostly figured it out because I helped implement it so know what's supposed to be where ;), but yes, that line shows the path that's being booted
[21:19] <slangasek> (I wanted the efibootmgr output to confirm that the boot options themselves were configured correctly)
[21:19] <zyga> right, I meant the actual checksum
[21:19] <slangasek> zyga: I checked the shim-signed package
[21:19] <zyga> ah
[21:19] <zyga> ok
[21:19] <slangasek> zyga: you could try reinstalling shim-signed
[21:19] <zyga> ok
[21:20] <slangasek> zyga: but before you do, please make a copy of grubx64.efi
[21:20] <zyga> ouch
[21:20] <zyga> too late :/
[21:20] <slangasek> ohwell ;)
[21:20] <slangasek> zyga: order of operations fail on my part
[21:20] <slangasek> zyga: so what's the md5sum of that file on disk /now/?
[21:21] <zyga> cde67f528af411dd8d8f1b4bc643b484
[21:21] <zyga> different
[21:21]  * slangasek scratches his head
[21:21] <slangasek> that's not the md5sum I expect either ;)
[21:21] <tjaalton> slangasek: turns out the upstart logs don't have any mention of plymouth-splash, so no wonder 'started plymouth-splash' didn't work
[21:21] <zyga> cde67f528af411dd8d8f1b4bc643b484  /boot/efi/EFI/ubuntu/grubx64.efi
[21:22] <zyga> slangasek: is that the right file?
[21:22] <tjaalton> problem is I don't know what would work, so that the smooth transition is preserved
[21:22] <tjaalton> something to play with tomorrow then
[21:22] <slangasek> tjaalton: do you have plymouth in the initramfs?
[21:22] <tjaalton> slangasek: probably, using cryptsetup
[21:23] <zyga> slangasek: I can probably find the older grubx64.efi from the mirror I use
[21:23] <slangasek> tjaalton: right, that explains - no 'started' event because the service is started before upstart is
[21:23] <zyga> slangasek: and if it has the right md5sum I've pasted here, give it to you
[21:23] <slangasek> zyga: actually, sorry, I was directing you to the wrong place
[21:23] <tjaalton> slangasek: ha, ok
[21:24] <tonyyarusso> Hey everybody, I've been doing some mucking about with a script shipped with update-notifier-common (/usr/lib/update-notifier/apt_check.py).  I discovered that while it appeared to be intended to be usable as a module, it was never tweaked to actually be so.  So, I made some changes and was wondering if anyone could take a glance to see if they seem sane.  Here's the original: http://pastebin.com/102RGrjK , the new version: ...
[21:24] <tonyyarusso> ... http://pastebin.com/j7ZNVdMg , the diff of the two: http://pastebin.com/4Rmy1Hjc , and an example script using it as a module: http://pastebin.com/p808Hp9T .
[21:24] <slangasek> zyga: because apparently the system I was referencing here is also not configured for SB currently :P  How about 'sudo grub-install --uefi-secure-boot', then check if the efibootmgr output shows a different boot path?
[21:24] <zyga> k
[21:25] <zyga> huuh
[21:25] <zyga> slangasek: it _removed_ ubuntu?
[21:25] <slangasek> errr
[21:25] <zyga> slangasek: http://paste.ubuntu.com/5696643/
[21:25] <slangasek> really?
[21:25] <zyga> slangasek: as you can see
[21:25] <slangasek> that's... special
[21:26] <zyga> tonyyarusso: hi, I think this is best addressed on the ubuntu-devel@ mailing list
[21:26] <zyga> tonyyarusso: alternatively as a merge request (to trigger discussion) to the relevant project on launchpad.net
[21:26] <zyga> slangasek: am I being hacked or is this 20*13* showing its teeth
[21:26] <zyga> slangasek: and we got a borked upload with some interesting bug
[21:27] <slangasek> zyga: man, I don't know - none of these pieces have been uploaded recently, except for grub and the change there is irrelevant!
[21:27] <tonyyarusso> zyga: All righty - care to point me to a primer on how to do a merge request?  I've opened bugs before, but haven't had a solution to offer.  :)
[21:27] <slangasek> zyga: so, ah... if you run grub-install again, does the missing boot entry come /back/?
[21:27] <zyga> tonyyarusso: sure, there's a full help page on launchpad about that
[21:27] <zyga> slangasek: checking
[21:28] <stgraber> doko: is that the actual upstream recommended way of doing bindings nowadays? my understanding was that ffi was indeed quite cool to generate minimal on the fly bindings as something a bit cleaner than ctypes, but it didn't look like something that should be used for a full upstream binding
[21:28] <zyga> no
[21:28] <lifeless> stgraber: upstream for what value of upstream
[21:28] <zyga> slangasek: do I get it right that I should _not_ reboot now ;)
[21:28] <slangasek> tonyyarusso: http://developer.ubuntu.com/packaging/html/udd-intro.html + http://developer.ubuntu.com/packaging/html/fixing-a-bug.html
[21:28] <slangasek> zyga: yes, probably don't do that ;)
[21:28] <lifeless> stgraber: upstream has never recommended ctypes for bindings
[21:28] <zyga> right ;)
[21:28]  * zyga has been in such a situation once before ;)
[21:29] <slangasek> zyga: in theory you could still browse manually in the firmware and ask it to boot the Ubuntu botloader by name, but that doesn't sound fun
[21:29] <zyga> slangasek: ah
[21:29] <zyga> slangasek: so uefi shell is always around?
[21:29] <zyga> slangasek: I thought that's only in the reference impl
[21:29] <stgraber> lifeless: doko was essentially saying I should be using cffi for the LXC binding instead of my current native C extension
[21:29] <zyga> slangasek: been there, done that, should be okay if I have to
[21:29] <slangasek> zyga: not shell; it's incompatible with Win8 cert reqs to ship the shell
[21:29] <zyga> heh
[21:30] <slangasek> zyga: but your firmware menu *probably* has an option to boot a specific EFI executable by path
[21:30] <zyga> ok
[21:30] <slangasek> (this only works under Secure Boot if the binary is signed)
[21:30] <zyga> hmm, I don't recall such a menu
[21:30] <stgraber> lifeless: I know ctypes haven't been recommended by upstream and for very good reason, that's why to me cffi looked like something a bit cleaner than ctypes but not something that upstream python would recommend for a real-world binding
[21:30] <lifeless> stgraber: cffi should be equivalent, because it still invokes the compiler
[21:30] <zyga> ok
[21:30] <zyga> what shall we try next?
[21:31] <slangasek> zyga: I'm reading grub-install code right now to figure that out
[21:31] <zyga> slangasek: if the next UDS wasn't virtual I'd get you a beer for helping me :)
[21:32] <slangasek> zyga: what the heck... how about sending me the output of 'sh -x /usr/sbin/grub-install --uefi-secure-boot'?
[21:33] <zyga> slangasek: I'll set LANG= so that you can read it
[21:33] <slangasek> if you wish ;)
[21:33] <tjaalton> slangasek: a horrible hack I guess but works: 'and (started cryptdisks-enable or started plymouth-splash)' :)
[21:34] <slangasek> tjaalton: truly horrible; I think we should fix upstart instead to synthesize 'started' events for jobs started from initramfs
[21:34] <zyga> slangasek: http://pastebin.ubuntu.com/5696669/
[21:34] <slangasek> tjaalton: (there's no guarantee that plymouth in the initramfs is caused by use of cryptsetup, for one thing)
[21:34] <tjaalton> slangasek: heh, yeah. I was wondering if there was some more generic event to abuse here
[21:36] <slangasek> tjaalton: not really, we need to create one - either by fixing it in upstart, or by adding a secondary job that's 'start on startup or started plymouth-splash', checks for plymouth-splash running already, and emits an appropriate common event
[21:36] <tjaalton> slangasek: right, that could work
[21:37] <tjaalton> as an interim solution
[21:37] <slangasek> tjaalton: and by 'checks for plymouth splash running', I mean checking the output of 'status plymouth-splash'
[21:38] <doko> bah, after every reboot after a unity update my system comes up in low graphics mode
[21:40] <tjaalton> doko: most likely not related to unity, but the lovely plymouth-splash/lightdm race we have
[21:40] <doko> ahh
[21:40] <tjaalton> which is finally understood, just needs some head-scratching to fix it properly :)
[21:40] <doko> but unity sees updates more often =)
[21:41] <slangasek> zyga: 'fs_module=ext2' (line 1453) - /boot/efi is a VFAT partition, right?
[21:41] <zyga> yes
[21:41] <tjaalton> doko: pastebin Xorg.0.log from the failing boot
[21:41] <slangasek> zyga: hmm, ok
[21:44] <slangasek> zyga: so what if you run this command by hand?: efibootmgr -c -d /dev/sda -p 1 -w -L ubuntu -l \EFI\ubuntu\shimx64.efi
[21:44] <slangasek> (with appropriate quoting)
[21:44] <zyga> appropriate quoting?
[21:44] <zyga> ah
[21:44] <zyga> \ ?
[21:44] <slangasek> yah
[21:44] <zyga> EFI uses windows style path separators?
[21:44] <zyga> omg
[21:45] <zyga> slangasek: nothing
[21:45] <doko> tjaalton, hmm, $ ls -l /var/log/Xorg.*
[21:45] <doko> -rw-r--r-- 1 root root 31919 Apr 10 23:37 /var/log/Xorg.0.log
[21:45] <doko> -rw-r--r-- 1 root root 31151 Apr 10 23:36 /var/log/Xorg.0.log.old
[21:45] <doko> -rw-r--r-- 1 root root 34547 Apr 10 23:35 /var/log/Xorg.failsafe.log
[21:45] <doko> -rw-r--r-- 1 root root 34547 Apr  7 22:36 /var/log/Xorg.failsafe.log.old
[21:45] <slangasek> zyga: successful exit?
[21:45] <zyga> slangasek: as in, efibootmgr -v does not list anything new
[21:45] <zyga> no
[21:45] <zyga> slangasek: 1
[21:46] <slangasek> zyga:  -v it
[21:46] <zyga> slangasek: it dind't print anything either way
[21:46] <slangasek> man
[21:46] <slangasek> what's up with that
[21:46] <tjaalton> doko: hmm, .old is probably not useful, guess you logged out soon?
[21:46] <slangasek> zyga: are you sure /bin/efibootmgr isn't corrupt/trojaned/
[21:47] <doko> tjaalton, yes
[21:47] <zyga> slangasek: if it was, that'd be interesting
[21:47] <barry> slangasek: just to verify, the patch to bug 1078697 needs to be backported to lucid-updates, right?  i ask because the patch in raring/precise does not apply cleanly, and i want to make sure i need to adapt it before i spend too much time on backporting (a lot has changed in the code since lucid ;)
[21:47] <doko> tjaalton, will keep it the next time
[21:47] <zyga> slangasek: since I'm not in secure mode I'd have to boot from a CD to check for sure
[21:47] <zyga> slangasek: I can give you the md5sum I currently see
[21:47] <tjaalton> doko: check /var/log/Xorg.0.log next time it happens, it's probably kinda short and shows something like 'no screens'
[21:47] <zyga> ea865d9082f8aa250fc9f749e6391dbb  /bin/efibootmgr
[21:47] <doko> ok, will do
[21:48] <tjaalton> doko: in which case it's bug 982889
[21:48] <zyga> slangasek: maybe we can strace it?
[21:48] <slangasek> zyga: checksum is correct.  strace it is!
[21:48] <zyga> http://paste.ubuntu.com/5696697/
[21:49] <zyga> write(3, "B\0o\0o\0t\0000\0000\0000\0001\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2084) = -1 ENOSPC (No space left on device)
[21:49] <slangasek> barry: I'm confused, why would we need this for lucid-updates?
[21:49] <zyga> hmmm
[21:49] <zyga> that's _not_ good
[21:49] <slangasek> zyga: have you had any recent kernel panics?
[21:49] <zyga> slangasek: did I bork my EFI flash stuff
[21:49] <barry> slangasek: that's my question.  when this came up last, cjwatson said it did.  i didn't have a chance to ask him why last time ;)
[21:50] <zyga> slangasek: not that I recall but I had a few problems earlier with my wifi (bcm) module
[21:50] <slangasek> zyga: are you using the raring kernel?
[21:50] <zyga> slangasek: yes
[21:50] <zyga> Linux g580 3.8.0-17-generic #27-Ubuntu SMP Sun Apr 7 19:39:35 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[21:50] <slangasek> zyga: hmmmm, not sure how to address this then; for some context, see http://mjg59.dreamwidth.org/23554.html
[21:51] <zyga> slangasek: can I purge that space somehow?
[21:51] <slangasek> zyga: you may be able to clean it manually from the efivars filesystem, *but*, the firmware may not recognize you've done this until after you've rebooted
[21:51] <slangasek> (maybe rebooted /twice/ according to that page)
[21:52] <zyga> slangasek: is that safe?
[21:52] <zyga> slangasek: and how do I erase it, just files?
[21:52] <slangasek> and of course the thing you're trying to write to firmware right now is your bootloader entry, so :P
[21:52] <zyga> ohh
[21:52] <zyga> right
[21:52] <zyga> I have a ton of things in /sys/firmware/efi/vars
[21:53] <zyga> http://paste.ubuntu.com/5696710/
[21:53] <slangasek> zyga: none of this is safe, here there be dragons, but if you can find the right variable it should be safe to remove it since that's basically the same thing efibootmgr itself does
[21:53] <zyga> can I remove dump- variables?
[21:54] <zyga> man, I want the old bios back
[21:54] <zyga> or uboot ;)
[21:54] <slangasek> zyga: I would /guess/ those are the kernel pstore variables, yes
[21:55] <zyga> slangasek: rm -rvf dump-*
[21:55] <zyga> ?
[21:55] <slangasek> zyga: not sure
[21:55] <slangasek> zyga: note that there's a 'del_var' interface there
[21:55] <slangasek> you might need to use that
[21:55] <zyga> OMG
[21:55] <zyga> I need to get a charger
[21:55] <slangasek> or you can use /sys/firmware/efi/efivars instead
[21:55] <zyga> this day is _interesting_
[21:55] <slangasek> which is more filesystem-like
[21:56] <slangasek> rm /sys/firmware/efi/efivars/dump* ?
[21:56] <zyga> one has files, other directories
[21:56] <zyga> well, efivars has files
[21:56] <slangasek> /sys/firmware/efi/efivars is the new hotness
[21:56] <zyga> yeah
[21:56] <zyga> each dump- is full of backtraces
[21:56] <zyga> I wonder if that's safe
[21:56] <zyga> I mean
[21:56] <zyga> it's flash
[21:56] <zyga> it's going to die
[21:56] <zyga> and people get tons of that (wifi, nfs, etc)
[21:57] <slangasek> zyga: that's a question for the kernel team after we get you booting again :)
[21:58] <slangasek> zyga: in the meantime, rm the dump*, and reboot to either recovery media or (preferably) to /efi/ubuntu/shimx64.efi directly, then recover your bootloader entry with efibootmgr
[21:58] <slangasek> well, you can try efibootmgr one last time /before/ rebooting, but no guarantee that'll work
[21:58] <zyga> slangasek: ok, I need to prep some stuff
[21:58] <zyga> slangasek: yeah
[22:00] <slangasek> zyga: the good news is, the variable names encode a unix timestamp and you've been accumulating these since at least December... so unlike some other implementations, yours seems to include a proper amount of variable space... :P
[22:00] <zyga> slangasek: ok, power up
[22:00] <zyga> hehe
[22:00] <zyga> thanks lenovo
[22:00] <zyga> slangasek: let me burn raring image on a CD before we continue
[22:01] <slangasek> zyga: but be aware that filling the efi nvram is known to brick laptops in some cases (Samsung's implementation most notably), so even if we get those vars removed there's still some risk that this is going to go south on reboot
[22:02] <zyga> slangasek: well, I was about to get my refresh anyway ;)
[22:02] <zyga> (thought this laptop is brand new)
[22:02] <zyga> I wonder if that's under warranty
[22:03]  * zyga wgets current raring image
[22:03] <zyga> I guess it sucks to have the full mirror and yet wget all the iso's
[22:03] <slangasek> zyga: did the 'rm' work?
[22:03] <zyga> I didn't try
[22:03] <slangasek> ah
[22:03] <zyga> I want to burn raring DVD before I continue
[22:03] <slangasek> that part's safe enough to try, but ok
[22:04] <zyga> actually
[22:04] <zyga> I can burn the older DVD I still have in my archive
[22:04] <zyga> and then rm
[22:04] <xnox> slangasek: barry: yes, we need it for lucid _or_ for lucid in cat-ppa to deploy it where the checksums are generated.
[22:06] <chiluk> slangasek, I was just trying to verify pad.lv/1057358 , and the fix is still not showing up in the final deb.  It looks like you still have the patch too far down 00list
[22:07] <chiluk> I haven't figured out what processes 00list, and why it's so touchy... but I know it to be true.
[22:08] <slangasek> chiluk: I didn't upload it; looks like that was stgraber's upload?
[22:08] <chiluk> I don't know.
[22:11] <chiluk> slangasek, I assume you have a script that goes through and auto marks packages for needing verification.
[22:11] <chiluk> that's why I got excited.
[22:12] <slangasek> chiluk: the script is run manually by the SRU team when the package is accepted into -proposed; in this case that got missed somehow and stokachu prodded me :)
[22:12] <slangasek> but anyway, if the fix isn't working, you'll want to take that up with stgraber
[22:12] <chiluk> yeah we'd really like to get this "simple" bug off our queue.
[22:13] <slangasek> chiluk: or simply following up to the bug with that info and marking it 'verification-failed' to nudge things along
[22:13] <chiluk> already marked verification-failed
[22:14] <stokachu> chiluk: what did you break
[22:14] <stokachu> ;P
[22:14] <chiluk> wasn't me this time.
[22:14] <chiluk> although I feared it was me.
[22:15] <zyga> slangasek: burning
[22:15] <stokachu> chiluk: are you using edit-patch to make sure the previous patches are applied before doing your work?
[22:15] <zyga> slangasek: I'll remove the dump-* variables after that
[22:15] <slangasek> zyga: ok
[22:15] <zyga> slangasek: I think it's really bad that we keep no bounds on the number of those
[22:15] <zyga> slangasek: I mean, keepin one or 5 is okay
[22:15] <zyga> slangasek: keeping them till we can is crazy
[22:15] <chiluk> stokachu... it's a gotcha with isc-dhcp... where it requires certain patches to be in a certain order or it will revert them halfway through the build.
[22:15] <chiluk> basically I fixed my deb-diff..
[22:15] <stokachu> chiluk: i did a build recently and didnt see that problem
[22:15] <chiluk> but my fix didn't get pulled in.
[22:16] <chiluk> stokachu, then you were doing it wrong!
[22:16] <chiluk> my debdiff works.
[22:16] <stokachu> apparently not if the verification-faild
[22:16] <chiluk> what's in the repo has the dhcpd-ldap-apparmor.dpatch  at the end of the file where it gets reverted
[22:16] <chiluk> my debdiff is not what has been applied.
[22:17] <slangasek> zyga: that's one of the problems here, yes.  another is using precious nvram for non-fatal kernel oopses
[22:17] <slangasek> zyga: once this is all over, do you mind filing a bug on the kernel package about this?
[22:17] <zyga> slangasek: absolutely
[22:17] <chiluk> man I was really excited to get this bug out of my queues ..
[22:18] <zyga> slangasek: better yet, on ubuntu-devel@ we have a million bugs anyway
[22:18] <stokachu> chiluk: https://launchpadlibrarian.net/136643012/isc-dhcp_4.1.ESV-R4-0ubuntu5.8.precise.debdiff
[22:18] <stokachu> it add the patch at the end of 00list
[22:18] <zyga> slangasek: bot not many of them may brick machines
[22:18] <stokachu> chiluk: if you used edit-patch within the source directory it would handle all this for you
[22:18] <chiluk> I did use edit-patch... that's what screwed up in the first place.
[22:19] <zyga> slangasek: I'll copy all the dumps from that nvram to my good old hdd
[22:20] <chiluk> stokachu, from 00list  #these get reverted during the build, so put non-ldap
[22:20] <chiluk>  #patches earlier
[22:20] <stokachu> chiluk: then i dont know b/c like i said i did the process for each distro using both dpatch and quilt
[22:20] <chiluk> stokachu, you should really verify your debdiff to make sure that your patch does not get reverted.
[22:23] <zyga_> slangasek: ehh
[22:23] <stokachu> chiluk: edit-patch applys all patches and the work i did on top of that would've already had whatever ldap gets reverted
[22:23] <zyga_> slangasek: I cannot understand anything
[22:23] <zyga_> slangasek: my kernel just crashed
[22:23] <zyga_> slangasek: I tried to rsync my efi vars just in case there's something I need to restore later
[22:23] <slangasek> stokachu: the build log shows what's up, with the patch being applied at build time for the 'patched-ldap' build, followed by it being unapplied for a different build. https://launchpadlibrarian.net/132443806/buildlog_ubuntu-precise-amd64.isc-dhcp_4.1.ESV-R4-0ubuntu5.7_UPLOADING.txt.gz
[22:23] <zyga_> slangasek: then it didn't fully crash, it was just one big overlay on the framebuffer
[22:23] <zyga_> slangasek: then I rebooted it thinking that's it, the CD didn't finish burning
[22:23] <zyga_> slangasek: then it _booted_ from disk
[22:24] <slangasek> zyga_: omgwhat
[22:24] <zyga_> slangasek: but now efibootmgr -v shows Ubuntu
[22:24] <zyga_> slangasek: I have the backtrace as a photo, coming up
[22:24] <zyga_> slangasek: if this makes any sense
[22:25] <zyga_> slangasek: maybe the firmware adds the stuff from disk somehow if there are no entries at all?
[22:25] <slangasek> stokachu, chiluk: however, this behavior seems consistent with chiluk's own debdiff on the bug, so...
[22:25] <zyga_> http://paste.ubuntu.com/5696799/
[22:25] <zyga_> that's my current efi
[22:25] <slangasek> zyga_: that would be an insane thing for the firmware to do
[22:25] <chiluk> yeah as I said the current version of code didn't use my debdiff
[22:25] <zyga_> slangasek: insane + firmware == daily? right
[22:25] <chiluk> the patch I wanted is still in the wron place for 00list
[22:25] <slangasek> zyga_: do you have nvram space *now* to update with efibootmgr?
[22:26] <zyga_> let's see
[22:26] <zyga_> slangasek: nope
[22:26] <zyga_> same strace result there
[22:26] <zyga_> I didn't remove anything though
[22:26] <zyga_> this is insane
[22:26] <slangasek> right
[22:26] <slangasek> *can* you remove anything?
[22:27] <slangasek> or does it all just crash?
[22:27] <zyga_> let's try
[22:27] <lifeless> is there UEFI support for 32-bit builds ?
[22:27] <zyga_> I just did
[22:27] <slangasek> lifeless: no
[22:27] <lifeless> slangasek: what would be involved, in principle ?
[22:28] <zyga_> http://pastebin.ubuntu.com/5696808/ that's what I removed (usunięty == removed)
[22:28] <zyga_> slangasek: reboot twice now?
[22:28] <slangasek> zyga_: yep
[22:28] <zyga_> cross your fingers
[22:29] <slangasek> lifeless: grub-efi-ia32 exists, so in theory you just need boot media
[22:30] <slangasek> lifeless: as this cannot sanely done on our existing i386 boot image without compromising bootability on *other* systems, this is not something I expect to see in Ubuntu; but you can try to persuade cjwatson otherwise
[22:30] <stokachu> slangasek: is it me or is isc-dhcp using bad patching practices
[22:30] <slangasek> lifeless: (oh, there's probably installer bits that need doing as well)
[22:30] <lifeless> slangasek: I have a tablet here for experimentation, its an atom w/64 bit extensions, but a 32-bit UEFI environment
[22:30] <slangasek> stokachu: ... possibly?
[22:30] <lifeless> slangasek: and no non-UEFI boot facility [it ships w/windows 8]
[22:31] <stokachu> its just weird having to put patches above other because other patches revert code
[22:31] <slangasek> lifeless: make someone give you a 64-bit UEFI upgrade for it? :)
[22:31] <lifeless> slangasek: so I'm pondering getting enough of Ubuntu onto it to poke at touchscreen and video support.
[22:31] <slangasek> stokachu: they don't revert code; the structure of the patch file is magic and used to represent different sets of patches that are applied for different builds
[22:31] <lifeless> slangasek: if only it was that easy. I will dig up the right contacts and email them
[22:32] <tuxskar> hello, I'm using ubuntu 12.10 and I have this problem using libpcre3-dev
[22:32] <tuxskar> ~/apertium/apertium-en-es ⮀ apt-cache policy libpcre3-dev
[22:32] <tuxskar> libpcre3-dev:
[22:32] <tuxskar>   Installed: 1:8.30-5ubuntu1
[22:32] <tuxskar>   Candidate: 1:8.30-5ubuntu1
[22:32] <tuxskar>   Version table:
[22:32] <tuxskar>  *** 1:8.30-5ubuntu1 0
[22:32] <tuxskar>         500 http://es.archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages
[22:32] <tuxskar>         100 /var/lib/dpkg/status
[22:32] <zyga> slangasek: hmm
[22:32] <tuxskar> Error: pcre_compile missing )
[22:32] <zyga> slangasek: not good
[22:32] <zyga> slangasek: keyboard / mouse does not work
[22:32] <zyga> slangasek: I've plugged external usb
[22:33] <zyga> slangasek: I had this just before the issues began
[22:33] <slangasek> lifeless: so if it's for a tablet and what you really need is a preinstalled image on removable media... that's fairly doable by just creating a disk image with a properly configured vfat partition and the magic binary bits in the right directory (/efi/boot/bootia32.efi, IIRC)
[22:33] <tuxskar> any idea?
[22:33] <zyga> slangasek: also bladernr_ is experiencing that
[22:33] <zyga> bladernr_: canyou type?
[22:33] <slangasek> zyga: !
[22:33] <slangasek> zyga: at what point is it failing?
[22:33] <zyga> slangasek: it does not respond in any way
[22:33] <bladernr_> zyga: i'm fine, mine is an old issue and probably not even closely related to yours
[22:33] <zyga> bladernr_: no, it started the _same_ way
[22:33] <bladernr_> and it's very transient and re-occuring
[22:34] <bladernr_> interesting...
[22:34] <zyga> bladernr_: then I rebooted and it all went nuts
[22:34] <zyga> bladernr_: are you using efi
[22:34] <xnox> lifeless: you can use rEFIt builds of 32bit EFI, it works well enough on UEFI devices despite targetting Apple's EFI from that you can at least boot/chain boot into grub-32bit. The "install" process will be very manual though.
[22:34] <slangasek> zyga: so you get what, a firmware screen and no input?
[22:34] <lifeless> xnox: thanks
[22:34] <lifeless> slangasek: thanks
[22:34] <zyga> slangasek: no, I booted to ubuntu :)
[22:34] <slangasek> hah
[22:34] <xnox> lifeless: this is the most "current" way to bootstrap/boot into 32bit only UEFI.
[22:34] <zyga> slangasek: but keyboard / mouse is not operational
[22:34] <lifeless> I shall put some time aside in a couple weeks to give it a spin
[22:34] <bladernr_> zyga: nope... my system is too old for that
[22:34] <zyga> ok
[22:34] <slangasek> zyga: ok, I claim no responsibility for this ;)
[22:35] <zyga> slangasek: heh
[22:35] <zyga> slangasek: ok, so I don't see any efi vars
[22:35] <zyga> slangasek: shall I reboot again?
[22:35] <slangasek> if deleting efi variables broke your keyboard... then that's a whole new world of crazy
[22:35] <slangasek> zyga: you don't see *any* vars, at all?
[22:35] <slangasek> did the efivarfs fail to mount?
[22:35] <zyga> slangasek: no, I do see a few, just none of the dump-*
[22:35] <slangasek> ok
[22:36] <slangasek> zyga: I'd try running efibootmgr again
[22:36] <zyga> slangasek: they are mounted ok
[22:36] <zyga> as in -v or to add the record?
[22:36] <zyga> http://paste.ubuntu.com/5696825/
[22:36] <zyga> that -s
[22:36] <slangasek> zyga: add the record
[22:36] <zyga> I booted with partially burned raring disk
[22:36] <zyga> ok
[22:37] <zyga> slangasek: I think that worked
[22:37] <slangasek> hurray!
[22:37] <zyga> http://pastebin.ubuntu.com/5696827/
[22:38] <slangasek> two Ubuntus?
[22:38] <slangasek> -v?
[22:38] <zyga> http://paste.ubuntu.com/5696831/
[22:38] <zyga> odd
[22:39] <zyga> shim + grubx
[22:39] <zyga> is that expected?
[22:39] <slangasek> yeah, efibootmgr writes a new boot entry instead of overwriting the existing
[22:39] <slangasek> grub-install has code to handle this
[22:39] <slangasek> just wanted to see which one is which to make sure the ordering was correct - and it looks fine
[22:39] <slangasek> so I think you can reboot to SB mode now
[22:40] <zyga> ok
[22:40] <zyga> and hopefully keyboard will work ;)
[22:40] <zyga> rebooting
[22:42] <zyga> slangasek: yay, everything works
[22:42] <slangasek> zyga: so the real question is how you ended up with a wrong, non-SB boot entry in the first place
[22:42] <zyga> slangasek: so let's file a few bugs
[22:42] <slangasek> zyga: upgrade logs may or may not provide illumination on this
[22:42] <zyga> slangasek: that's interesting but unless there's a log that knows this I don't know how to find out
[22:42]  * zyga will write a $10 app that "checks if your laptop is about to brick" ;)
[22:43] <slangasek> zyga: /var/log/apt/term.log would be a start
[22:43] <zyga> it should not be translated, meh
[22:44] <zyga> http://paste.ubuntu.com/5696840/ http://paste.ubuntu.com/5696841/ and http://paste.ubuntu.com/5696842/
[22:45] <zyga> slangasek: from the second log:
[22:45] <zyga> slangasek: Rozpakowywanie pakietu systemd-shim (z .../systemd-shim_1-0ubuntu1_amd64.deb) ...
[22:45] <zyga> slangasek: should that be installed?
[22:46] <slangasek> yes, it's unrelated to the shim bootloader
[22:46] <zyga> is that a "shim systemd"?
[22:46] <zyga> ok
[22:46] <stokachu> slangasek: since isc-dhcp is already in proposed with the reverted patch issue, maybe we can use https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570/comments/41
[22:46] <slangasek> apparently grub-install isn't verbose enough about its EFI handling
[22:46] <stokachu> slangasek: to push on top of it
[22:46] <zyga> Przygotowywanie do zastąpienia pakietu shim-signed 1.1+0~20120906.bcd0a4e8-0ubuntu4 (wykorzystując .../shim-signed_1.2+0~20120906.bcd0a4e8-0ubuntu4_amd64.deb) ...
[22:46] <slangasek> ohwell
[22:46] <zyga> that's all I can see shim-related
[22:47] <stokachu> slangasek: it contains changes from previous changelog along with mine and the proper ordering of the patches
[22:47] <slangasek> zyga: oh, was shim-signed uninstalled at some point?  (since that's a new install, not an upgrade?)
[22:48] <zyga> slangasek: checking
[22:49] <zyga> slangasek: I dind't remove it myself if that's what you're asking
[22:49] <slangasek> stokachu: er, don't patch debian/ from within debian/patches
[22:49] <zyga> slangasek: what makes you think that shim-signed was uninstalled?
[22:50] <zyga> as in ever uninstalled
[22:50] <stokachu> slangasek: sorry not following what you mean
[22:50] <zyga> slangasek: I have history.log files they have timestamps and other info
[22:51] <slangasek> stokachu: the debian/patches/add-option-ignore-client-uids.dpatch there is definitely wrong, it shouldn't be patching other patches
[22:51] <slangasek> stokachu: debian/patches/add-option-ignore-client-uids.dpatch *contains* debian/patches/dhcpd-ldap-apparmor.dpatch... and patches to 00list and debian/changelog as well
[22:51] <slangasek> zyga: oh, sorry, this was a simple reinstall of the package, I was reading wrong
[22:51] <slangasek> zyga: so yeah, looks like we have nothing to explain the wrong boot entry
[22:52] <zyga> slangasek: yes, that appears to be the case
[22:52] <zyga> slangasek: so what about the entry was wrong?
[22:52] <zyga> slangasek: the checksum?
[22:52] <slangasek> zyga: it pointed to grubx64.efi instead of shimx64.efi
[22:52] <zyga> I see
[22:52] <zyga> hmm
[22:52] <slangasek> and only shimx64.efi is signed with Microsoft's key
[22:53] <chiluk> so slangasek word round town is that stgraber is awwl (with leave) who would be the next best person to talk to about getting this issue and  https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570 committed?
[22:53] <stokachu> slangasek: hah, how the..
[22:53] <slangasek> chiluk: it seems that stokachu is preparing the SRU patch
[22:53] <zyga> slangasek: so I see a few bugs: mysterious grubx64.efi installed, kernel oopses logged to precious efi nvram, no cap / rotation on debug data in nvram
[22:54] <slangasek> zyga: the grubx64.efi isn't mysterious; it's expected and required, it's the second-stage bootloader
[22:54] <zyga> slangasek: + maybe the keyboard bug but I have no way to explain that (maybe apart from efi fastboot not starting USB for some reason but without any evidence)
[22:54] <zyga> slangasek: mysterious as in in that efi config space
[22:54] <zyga> (I probably phrase that incorrectly)
[22:54] <slangasek> ah - yes, the efi boot entry was mysterious
[22:55] <zyga> slangasek: I'll write a short email to ubuntu-devel@, I'll follow up with bugs tomorrow
[22:55] <zyga> slangasek: I wonder if anyone else got affected by that
[22:55] <zyga> slangasek: and if the nvram depletion a factor
[22:58] <stokachu> chiluk: that apparmor patch why not just edit debian/apparmor-dhcpd directly?
[23:01] <chiluk> because I was still new when I wrote it at first, and I was curious about the patching system.
[23:02] <chiluk> curiousity killed the cat.'
[23:03] <YokoZar> cjwatson: I subscribed you to https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1166124  because I remember our conversation ~ the printed text on the CD sleeves being grossly unrealistic a year or two ago
[23:04] <YokoZar> cjwatson: I'm not sure if Canonical is printing CDs for 13.04 but if so please make sure they don't say 256 megs required :D
[23:04] <zyga> slangasek: I wonder if it's safe to upgrade grub2 now
[23:04] <stokachu> slangasek: https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1069570/comments/42
[23:05] <stokachu> slangasek: mind taking a peek now, i think ive addressed everything
[23:06] <stokachu> slangasek: that should cover the broken -proposed and squash another bug
[23:08] <zyga> slangasek: did we get two ubuntu entries after my crash/reboot?
[23:13] <zyga> slangasek: email sent