=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== bregma is now known as bregma|away
=== henrix_ is now known as henrix
=== Ursinha-afk is now known as Ursinha
[10:21] <cjwatson> I've changed queue's default behaviour to exact-match, now that bug 33700 is fixed; ubuntu-archive-tools r679.
[10:21] <ubot2`> Launchpad bug 33700 in Launchpad itself "could queue filters match source as well as binaries?" [Low,Fix released] https://launchpad.net/bugs/33700
[10:29] <Laney> Please someone look at releasing glib2.0 into q-updates to deal with banshee uninstallability there
[10:32] <cjwatson> Laney: seems reasonable - done.  At some point in the near future could you please remember to check on bug 1044322?
[10:32] <ubot2`> Launchpad bug 1044322 in GLib "indicator-messages-service crashed with assert in g_menu_exporter_name_vanished()" [Critical,Fix released] https://launchpad.net/bugs/1044322
[10:32] <cjwatson> We should get clearer data once it's in -updates, and if it isn't improving then we'll need to reopen that bug
[10:34] <Laney> Yeah. I'll keep a tab open. Thanks.
[10:37] <Laney> I suppose it's encouraging that neither the -proposed or raring versions of indicator-messages see the crash
[10:37] <Laney> as those users will likely have new enough glib installed
=== bregma|away is now known as bregma
=== yofel_ is now known as yofel
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== doko_ is now known as doko
[17:12] <mterry> infinity, I just uploaded a new compiz to precise-proposed.  I was hoping to get it in before end of week/end of year to enable more testing and hopefully get it into 12.04.2
[17:13] <mterry> infinity, this is the one that enables unredirect for non-intel/nouveau machines
[17:54] <cjwatson> Has anyone done any kind of verification of current precise images on non-SB?
[17:54] <cjwatson> Just wondering if we might be able to release this mess before the shutdown
[17:57] <xnox> cjwatson: jenkins is green =)
[17:57] <xnox> (but that simply does fully presseded desktop/server cds)
[18:01] <xnox> from 21st of November there were no reports submitted on iso tracker.
[18:02] <xnox> (against precise daily testing milestone)
[18:02] <infinity> cjwatson: How much of the snag still needs verification and promotion?  I haven't looked in a while.
[18:03] <infinity> Hrm, lots...
[18:04] <infinity> shim, grub-installer, base-installer, debian-installer, ubiquity, ubuntu-defaults-builder, livecd-rootfs...
[18:05] <cjwatson> Yeah, but nearly all of that is that one bug :-)
[18:06] <cjwatson> Possibly not absolutely all
[18:06]  * xnox should retest ubiquity kernel-headers bug.
[18:33] <infinity> cjwatson: If any of the bits from the Big Bug of Doom can start moving along, we should probably just do this piecemeal instead of one big mess.
[18:33] <infinity> cjwatson: Since tracking verification for 20 packages in one bug is lollerskatingly difficult.
[18:35] <slangasek> infinity: I don't think there's any useful piecemeal verification to be done; the bug is "SB support" and that requires the whole set
[18:36] <infinity> slangasek: Well, we've done piecemeal verification to keep the kernel moving along, for instance.  If we know that shim now works as we want it, that could promote, etc.
[18:36] <infinity> slangasek: But sure, I'm happy with a couple of people telling me "this set of 7 packages now looks good go".
[18:38] <slangasek> well, since shim itself only comes into play once the installer+grub bits land, I'd say that can be promoted, yeah
[18:38] <stgraber> slangasek: still hoping to get a fix for the AMI/Lenovo unsigned kernel bug for 12.04.2?
[18:39] <slangasek> stgraber: yes; the initial promotion shouldn't block on this though
[18:39] <slangasek> especially since I have di^W bisect gnu-efi
[18:39] <infinity> slangasek: Yes, that was sort of my point, was verifying in dependent layers, until we get to the top (d-i/ubiquity/livecd-rootfs) and call it done.
[18:39] <stgraber> right, we can always stack another SRU on top of it once we get a fix (and push to 12.10 too)
[18:41] <xnox> what about chinese image failing to build?
[18:42] <xnox>  linux-signed-generic-lts-quantal : Depends: linux-signed-image-generic-lts-quantal but it is not going to be installed
[18:42] <slangasek> infinity: except the only two independent layers are "this SB-only stuff that's a no-op until integrated (shim*)" and "everything else" :)
[18:43] <infinity> slangasek: Fair enough.
[18:43] <infinity> xnox: Hrm?
[18:43] <xnox> infinity: ubuntu desktop chinese is failing to build for a while now, with that error. Yet regular image builds fine.
[18:44] <infinity> I see no reason that should fail...
[18:44] <infinity> Just tested here, nothing's in universe, etc...
[18:45]  * xnox does wonder where am I getting these fail emails from. 1 sec.
[18:46] <infinity> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntu-zh_CN/20121219/livecd-20121219-amd64.out
[18:46] <infinity> It's definitely broken.  But... Why? :/
[18:49] <stgraber> I can reproduce the failure on a standard 12.04 system when installing linux-signed-generic-lts-quantal
[18:49] <stgraber>  linux-signed-image-3.5.0-21-generic : Depends: sbsigntool but it is not installable
[18:49] <infinity> Oh, I had -proposed enabled in my test.
[18:49] <infinity> Which the livefs builds do too..
[18:50] <infinity> But maybe zh_CN doesn't.
[18:50] <stgraber> right, sbsigntool is only in -proposed
[18:50] <infinity> That, I can fix.
[18:51] <xnox> infinity: http://paste.ubuntu.com/1450535/ looks odd. (diff of the two logs) chinese image is not doing UEFI thing at all?!
[18:51] <stgraber> xnox: correct. The defaults-builder image lack EFI
[18:52] <stgraber> I believe I filed a bug for that
[18:52] <stgraber> https://bugs.launchpad.net/ubuntu/+source/ubuntu-defaults-builder/+bug/1068156
[18:52] <ubot2`> Launchpad bug 1068156 in ubuntu-defaults-builder (Ubuntu Raring) "Images built using ubuntu-defaults-builder lack EFI support." [High,Triaged]
[18:53] <xnox> and is that targeted for 12.04.2 SB enablment or not?
[18:53] <stgraber> would first need to fix in raring :)
[18:53] <infinity> Is the ubuntu-defaults-builder in precise-proposed not meant to fix this?
[18:53] <xnox> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1075181 lists as ubuntu-defaults-builder "release in raring & committed in precise"
[18:53] <ubot2`> Launchpad bug 1075181 in ubuntu-defaults-builder (Ubuntu Precise) "Backport UEFI Secure Boot support for Ubuntu 12.04.2" [High,Fix committed]
=== henrix is now known as henrix_
[18:55] <stgraber> infinity: my interpretation of the changelog is that this fixes the vmlinuz case, but it won't create the EFI directory or setup the shim and all those things
[18:55] <stgraber> infinity: so in short, no
[18:56] <infinity> Hrm.  This systems like a larger failure in u-d-b. :/
[18:56] <infinity> Given that it's meant to be for customisation the official build process, not replacing it. :P
[18:56] <infinity> s/the/of the/
[18:58] <xnox> "Nov 23 13:03:19 *	cjwatson enables -proposed for precise builds" infinity should chinese images be build with proposed as well then?
[19:01] <infinity> A bit more needs to be done than that.
[19:02] <infinity> The Chinese image isn't getting the LTS kernel on the image at all (well, until we try to install -signed-, but that's not when we want it)
[19:04] <infinity> Oh, wait, no.  I lied.  There it is.
[19:04] <infinity> Yeah, just promoting some of this stuff should magically fix the Chinese image build, though it still might not actually DTRT, according to stgraber.
[19:05] <cjwatson> xnox,infinity: I tried to reproduce the zh_CN failure locally, and couldn't.  I'm hoping having stuff promoted will improve matters, indeed.
[19:06] <infinity> cjwatson: It just comes down to not being built against proposed, AFAICT.
[19:06] <cjwatson> We should definitely improve u-d-b for all this, but I don't think it needs to block this bug
[19:06] <cjwatson> infinity: I couldn't reproduce it locally even given that. :-(
[19:07] <cjwatson> (I mentioned all this a few days ago, maybe last week ...)
[19:08] <infinity> http://paste.ubuntu.com/1450588/
[19:08] <xnox> cjwatson: is SB on the chinese image required or desired feature?
[19:08] <infinity> cjwatson: ^-- Pretty easy to reproduce.
[19:08] <cjwatson> xnox: desired
[19:09] <cjwatson> xnox: we shipped 12.10 without it
[19:09] <cjwatson> xnox: the required goal for 12.04.2 is equivalent support to 12.10
[19:09] <infinity> If we're happy with sbsigntool, let me release that.
[19:09] <cjwatson> anything more is gravy
[19:09] <xnox> =)))) Hmm.... gravy
[19:10]  * xnox should have dinner =)
[19:10] <infinity> cjwatson: Are you satisfied that the current sbsigntool is doing vaguely sbsigny things?
[19:11] <infinity> cjwatson: I'll push that one out now and have one less thing to worry about as we untangle this.
[19:12] <cjwatson> infinity: yeah
[19:12] <infinity> slangasek: Same question for shim/shim-signed?
[19:13] <cjwatson> if you're looking for an order to do things in, the original upload order was fairly reasonable
[19:13] <slangasek> infinity: yes
[19:13] <cjwatson> there was a non-obvious thing where bits of build system had to go earlier than you might think, iirc
[19:14] <infinity> cjwatson: Right now, I'm just picking off things that don't obviously activate without other bits.
[19:14] <infinity> cjwatson: But over the next day or two, the goal should just be to release them all, if we're ready for that.
[21:23] <jbicha> infinity: could you look at promoting the mesa-utils binary for bug 914631?
[21:23] <ubot2`> Launchpad bug 914631 in gnome-control-center "[mir] mesa-demos" [Undecided,New] https://launchpad.net/bugs/914631
[21:26] <infinity> jbicha: Was there a reason no one ever responded to Bryce's comment on that bug? :/
[21:30] <jbicha> you mean about not needing mesa-utils to look up driver info? I think the lack of response was that no one wanted to write that patch
[21:33] <infinity> I suspect the code to do what he suggests would be shorter than the core required to fork and parse output from glxinfo, and would also be faster.
[21:33] <infinity> s/core/code/
[21:39] <infinity> jbicha: But, whatever.  If no one's willing to do it without the fork, I'm not going to second-guess mterry's MIR.
[21:42]  * mterry looks up
[21:43] <mterry> infinity, I think the problem is that the code required to fork and parse output from glxinfo is already written
[21:43] <mterry> infinity, so while bryce's suggestion is a good one, it's just unmanned work
[21:43] <infinity> mterry: Well, yes.  "Code already written" hasn't ever stood in the way of us considering it objectionable before. :P
[21:43] <RAOF> infinity: Also, you *want* to fork and spit out some info, because proprietary drivers are hateful.
[21:43] <mterry> infinity, :)
[21:44] <mterry> That's a fair point.  glxinfo does have a lot of crashers due to drivers being awful
[21:45] <infinity> If querying "what driver am I using" crashes, that seems fundamentally broken.  But okay.
[21:46] <RAOF> infinity: Exactly that query crashes if you've installed fglrx but are not using it.
[21:46] <infinity> RAOF: Special.
[21:46] <RAOF> (Because proprietary drivers replace libGL, which is where you call, and their libGL isn't a mastery of failsafe error handling)
[21:47] <infinity> Anyhow, like I said, I won't second-guess this, once gnome-control-center is actually built, I'll promote mesa-whatever.
[21:47] <infinity> RAOF: Well, I'd question why this query is happening in libGL.  Isn't there a more fundamental Xish way of saying "this is my video driver"?
[21:47] <RAOF> Actually, no.
[21:47] <infinity> RAOF: There's certainly enough vomit in the logs to indicate that something knows what drivers are in play.
[21:48] <RAOF> And they're not after the video driver; they're after the OpenGL renderer.
[21:48] <infinity> I guess none of that is actually exported to a public interface?
[21:48] <RAOF> It is; glGetString(GL_RENDERER)
[21:48] <infinity> RAOF: No, they're after the "video", if the dialog is to be believed.
[21:49] <infinity> I think that dialog will even happily display VESA drivers, if you're using one (via parsing the X log, oh my)
[21:49] <RAOF> We're talking about the System Details?Overview, right?
[21:49] <infinity> Yeah.
[21:50] <infinity> I mean, I know that it *is* displaying the GL renderer.
[21:50] <infinity> But that's not the same as saying that's what they actually want to be displaying.
[21:50] <RAOF> Right.
[21:50] <RAOF> They could indeed do something different; there's surely some byzantine way involving looking up the PCIID database.
[21:51] <RAOF> But X doesn't help you at all there.
[21:51] <RAOF> xf86-video-intel knows that it's running on an Intel? Sandybridge Mobile, but there's no mechanism to export that anywhere.
[21:51] <RAOF> Except the GL renderer string :)
[21:52] <infinity> Fair enough.  Seems like a bit of a design flaw, but I'm okay with "no, this just plain can't be done".
[21:53] <RAOF> Noone's ever really felt the need to add that protocol; and people *are* mostly interested in the 3d driver anyway.
[21:53] <jbicha> I filed https://bugzilla.gnome.org/show_bug.cgi?id=690527
[21:53] <ubot2`> Gnome bug 690527 in Other Preferences "Don't call 'glxinfo -l' to show the graphics card info" [Normal,Unconfirmed]
[21:53] <infinity> Has anyone ever noticed a bizarre bug where window contents only refresh when you move the window?
[22:09] <RAOF> Sounds like damage problems.
[22:12] <slangasek> always a downer when damage is broken