| === 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 | ||
| 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:21 |
| Laney | Please someone look at releasing glib2.0 into q-updates to deal with banshee uninstallability there | 10:29 |
| 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:32 |
| Laney | Yeah. I'll keep a tab open. Thanks. | 10:34 |
| 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 | 10:37 |
| === 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 | ||
| 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:12 |
| mterry | infinity, this is the one that enables unredirect for non-intel/nouveau machines | 17:13 |
| 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:54 |
| xnox | cjwatson: jenkins is green =) | 17:57 |
| xnox | (but that simply does fully presseded desktop/server cds) | 17:57 |
| xnox | from 21st of November there were no reports submitted on iso tracker. | 18:01 |
| 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:02 |
| infinity | Hrm, lots... | 18:03 |
| infinity | shim, grub-installer, base-installer, debian-installer, ubiquity, ubuntu-defaults-builder, livecd-rootfs... | 18:04 |
| cjwatson | Yeah, but nearly all of that is that one bug :-) | 18:05 |
| cjwatson | Possibly not absolutely all | 18:06 |
| * xnox should retest ubiquity kernel-headers bug. | 18:06 | |
| 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:33 |
| 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:35 |
| 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:36 |
| 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:38 |
| 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:39 |
| xnox | what about chinese image failing to build? | 18:41 |
| 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:42 |
| 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:43 |
| infinity | I see no reason that should fail... | 18:44 |
| infinity | Just tested here, nothing's in universe, etc... | 18:44 |
| * xnox does wonder where am I getting these fail emails from. 1 sec. | 18:45 | |
| 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:46 |
| 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:49 |
| infinity | But maybe zh_CN doesn't. | 18:50 |
| stgraber | right, sbsigntool is only in -proposed | 18:50 |
| infinity | That, I can fix. | 18:50 |
| 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:51 |
| 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:52 |
| 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] | 18:53 |
| === henrix is now known as henrix_ | ||
| 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:55 |
| 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:56 |
| xnox | "Nov 23 13:03:19 *cjwatson enables -proposed for precise builds" infinity should chinese images be build with proposed as well then? | 18:58 |
| infinity | A bit more needs to be done than that. | 19:01 |
| 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:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| cjwatson | (I mentioned all this a few days ago, maybe last week ...) | 19:07 |
| 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:08 |
| 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:09 |
| * xnox should have dinner =) | 19:10 | |
| infinity | cjwatson: Are you satisfied that the current sbsigntool is doing vaguely sbsigny things? | 19:10 |
| infinity | cjwatson: I'll push that one out now and have one less thing to worry about as we untangle this. | 19:11 |
| cjwatson | infinity: yeah | 19:12 |
| infinity | slangasek: Same question for shim/shim-signed? | 19:12 |
| 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:13 |
| 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. | 19:14 |
| 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:23 |
| infinity | jbicha: Was there a reason no one ever responded to Bryce's comment on that bug? :/ | 21:26 |
| 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:30 |
| 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:33 |
| 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:39 |
| * mterry looks up | 21:42 | |
| 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:43 |
| mterry | That's a fair point. glxinfo does have a lot of crashers due to drivers being awful | 21:44 |
| infinity | If querying "what driver am I using" crashes, that seems fundamentally broken. But okay. | 21:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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? | 21:53 |
| RAOF | Sounds like damage problems. | 22:09 |
| slangasek | always a downer when damage is broken | 22:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!