=== knome_ is now known as knome
[01:22]  * slangasek glares at the 'binutils' build dependency on gnu-efi in unstable
[01:32] <slangasek> cjwatson: new shim requires newer gnu-efi; seems reasonable to me to update gnu-efi as part of the secureboot work, do you agree?
[01:32] <slangasek> (revdeps: kexec-tools, refit, efilinux, elilo)
=== NCommander is now known as Guest38487
=== Ursinha is now known as Ursinha-afk
[06:15] <ScottK> infinity: Did you fix the build-dep on a thing in backports problem?  ^^^ opendmarc on precise needs a package that is only in backports and it found it, so at least for the totally missing case it works currently.
[06:22] <infinity> ScottK: I fixed nothing.
[06:22] <ScottK> OK.
[06:22] <infinity> ScottK: Since the last time it came up, people were still arguing that the proposed hack was incorrect.
[06:22] <ScottK> Then either it's magically fixed itself of it's only a problem if the package is present, but in insufficient version in the release.
[06:23] <ScottK> I thought I'd argued micahg off of disagreeing.
[06:23] <infinity> My guess is that apt doesn't respect NotAutomatic if the package only exists in a NotAutomatic source.
[06:24] <infinity> (It ends up being the same as specifying package=version or package/suite)
[06:25] <infinity> And that's the "correct" answer, which would be to have the resolver know that it only exists in the correct version in either 'version' or 'suite' and call apt appropriately.
[06:25] <infinity> I wonder if that wouldn't actually be as awful to hack together in the old sbuild as I originally thought.
[06:26] <ScottK> I'm in favor of a fix, whichever way you choose to pursue it.
[06:34] <infinity> Hrm, or I could cheat and not completely rewrite the resolver.
[06:34] <infinity> Do the normal install, then version check, and for the packages that fail the version check, see if a new version is available and explictly install it.
[06:34] <infinity> ScottK: Do you have an example of something in backports that's in dep-wait, so I can test this?
[06:35] <ScottK> No.  I haven't seen one recently.
[06:35] <infinity> Hrm.  I thought we had a few that have been in limbo for ages, hence the bug.
[06:35] <ScottK> maybe tumbleweed knows of one?
[06:36] <ScottK> I do remember one, but not what the package was and it was awhile ago.
[06:37] <infinity> Hrm.  There was a natty one referenced in the bug, that's not helpful.
[06:38] <infinity> Oh well, I can fake it by making hello build-dep on a library version from backports.
[06:49] <ScottK> infinity: Thanks for looking into it.
[06:56] <tumbleweed> ScottK, infinity https://bugs.launchpad.net/launchpad/+bug/888665 refers to teeworls in natty
[06:56] <ubot2`> Launchpad bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [Critical,Triaged]
[06:56] <tumbleweed> oh you said that
=== fabo_ is now known as fabo
=== doko_ is now known as doko
[08:52] <cjwatson> slangasek: gnu-efi> sure, if it's just new api
=== henrix_ is now known as henrix
=== NCommander is now known as Guest97545
=== Ursinha-afk is now known as Ursinha
=== yofel_ is now known as yofel
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[14:47] <ScottK> FYI, dh_python3 ABI tagging of .so files seems to be broken in raring ATM.  I gave barry and doko a ping.  See sip4 in raring-proposed (it's blocked, so no danger that misbuilt package will migrate) and /usr/lib/python3/sip.so.
[14:47]  * ScottK unfortunately does not have time to investigate.
[14:52] <Laney> The 'only in backports' case has always worked
=== bdrung_ is now known as bdrung
[15:04] <ScottK> Laney: Thanks.
[15:04] <Laney> np. As I understand it it's because the resolver essentially does 'apt-get install <build-deps-without-versions>' and then dies if some of the versions aren't what it wants to see. In the only-in-backports case there's only one candidate so the apt-get gives you the right package.
[15:37] <stgraber> slangasek: alright, let's see if I can load my custom SB keys, then run a locally signed shim :)
[15:40] <stgraber> slangasek: looks like it worked, my firmware now refuses to boot something signed by Microsoft, so just need to check that it boots something I sign myself
[15:41] <stgraber> then I can test your new shim
[15:48] <micahg> ScottK: I was outvoted and stopped arguing, so it's not me :)
[15:53] <hggdh> micahg: BTW, https://plus.google.com/106424184070033940581/posts/S1uEPABfA6i
[16:20] <stgraber> slangasek: alright, just booted my machine from a self signed shim. I also tried the one in ubuntu:shim but it apparently won't boot at all. Building failed while building the MokManager but I ignored it as shim.efi was there, though maybe it wasn't actually ready to be used
[16:44] <stgraber> slangasek: so I managed to build the new shim completely now (had to locally build pesign), though still no change, the new shim only gets me a blank screen
[17:48] <slangasek> stgraber: hmm, ok.  I'll dig into it here and see what's going on
[17:59] <stgraber> slangasek: I've been building the shim with: make EFI_PATH=/usr/lib VENDOR_CERT_FILE=debian/canonical-uefi-ca.der
[17:59] <stgraber> slangasek: then used sbsign to sign it with my local key. The sbsign call I know is fine as that's the same I used to sign the current shim from the archive and this one boots fine
[18:00] <slangasek> stgraber: right, that all seems reasonable.  But you say it boots to a blank scren?
[18:00] <slangasek> scren
[18:00] <slangasek> eeeee
[18:01] <stgraber> slangasek: right, when I run it, all I get is a blank screen, then after maybe 5-10 minutes, the system reboots
[18:02] <stgraber> slangasek: so I'm fairly sure the signature is correct, otherwise the firmware would have complained (similar to what it does now when I try to boot the MS signed binary). So something wrong is going on in the shim
[18:03] <stgraber> slangasek: one thought I had was that it was somehow unable to find the grub binary, but I clearly see the grubx64.efi string in the shim binary, so that's probably not the issue
[18:04] <slangasek> stgraber: yep.  don't worry about it for now, I'll work on it here
[18:05] <stgraber> ok, back to looking at network bugs then :)
[18:06] <slangasek> stgraber: allow me to jump bug #1090002 to the front of the queue ;)
[18:06] <ubot2`> Launchpad bug 1090002 in linux (Ubuntu) "biosdevname gives name of device as rename7 in Quantal" [Medium,Confirmed] https://launchpad.net/bugs/1090002
[18:08] <stgraber> slangasek: I'll at least leave a comment. The only system where I was reproducing the issue was my main router and I trashed it for something better yesterday ;)
[18:09] <stgraber> though it wasn't anything fancy, just a 1.6Ghz atom with two realtek NIC and Ubuntu 12.04, so maybe running the same kind of network config on a very slow VM will trigger the bug too
[18:10] <stgraber> (that machine had one bond with around 15 VLANs, at least as many bridges and a bunch of tun devices, so maybe simply creating a ton of interfaces at boot time triggers it ;))
[18:11] <slangasek> stgraber: I've assigned the bug to you, we need to get it fixed and you're the one in the best position to reproduce it even if your previous repro environment is gone; so yeah, even if you can't work on it right now, please follow up
[19:15] <bdmurray> slangasek: wackamole in lucid can be removed
[19:17] <infinity> bdmurray: I'll remove it, if you update the bug.
[19:18] <infinity> Actually, I guess I can do that.
[19:19] <infinity> bdmurray: Done.
[19:23] <slangasek> cjwatson: well, the new gnu-efi package also includes build system changes which I don't trust (I had to fiddle to get the i386 build to properly pass -m64).  so I guess I'll be cherry picking.
[20:16] <hggdh> infinity: what should be done with bug 1089157? Take the package from raring-proposed?
[20:16] <ubot2`> Launchpad bug 1089157 in bcmwl (Ubuntu) "bcmwl 6.20.155.1+bdcom-0ubuntu1 causes kernel panic on boot" [High,Confirmed] https://launchpad.net/bugs/1089157
=== NCommander is now known as Guest66193
[20:20] <infinity> hggdh: Removing it from proposed doesn't do much good, it needs to be reverted or fixed.
[20:21] <infinity> hggdh: Do we have any way to investigate it first?
[20:23] <hggdh> infinity: I am not sure how to check more on it. Seems to affect some (or all) of Broadcom users
[20:24] <ScottK> That would explain why my netbook stopped working.
[20:24] <infinity> Oh look, a tester.
[20:26] <ScottK> Sure.  But not today.
[20:27] <infinity> hggdh: Anyhow, I'm on vacation until January (my activity in #-kernel is all in your head), so you might want to hunt down someone else to do the testing and potential revert.
[20:27]  * hggdh juts down a note to really stop hearing voices in own's head
[20:29] <hggdh> infinity: anyway, only my production laptop has the bloody Broadcom card, so no, I cannot test it myself. But, hopefully, ScottK can check on it later
[20:29] <infinity> Your production laptop doesn't run raring?
[20:30] <ScottK> Mine certainly doesn't.
[20:30] <infinity> Wimp. :)
[20:30] <hggdh> infinity: it does. And I downgraded bcmwl after having the laptop bricked
[20:31] <infinity> You and I have slightly different definitions of "brick".
[20:31] <hggdh> heh. For me, a brick is a system that does nothing (or does the very wrong things) when booted on.
[20:42] <bdmurray> I did the verification for two of the three apport bugs in quantal -proposed.  Is it okay if I do the SRU release it too?
=== ev_ is now known as ev
=== micahg_ is now known as micahg
=== henrix is now known as henrix_
=== henrix_ is now known as henrix
[22:26] <ScottK> bdmurray: AFAIK, yes.
=== henrix is now known as henrix_
=== iulian is now known as Guest6605