[00:01] bdmurray, aha, awesome [00:02] bryceh: its not a good solution but something to get the data right now [00:02] bdmurray, do you think this issue is important enough to put in for alpha-2? [00:03] bryceh: I forget it doesn't block bug reporting for X right? [00:03] bdmurray, not that I know [00:03] actually it might for some cases [00:05] bdmurray, I take it you're alluding to say, "Dummy, people being unable to report bugs kinda undermines the whole idea of having an alpha release" [00:06] bryceh: well more like "If it prevents getting useful data then yes its important for A2" [00:06] bryceh: or if it makes people goto +filebug instead of using ubuntu-bug ;-) [00:08] bdmurray, how's this look: [00:08] if os.path.lexists('/usr/lib/nux/unity_support_test'): [00:08] try: [00:08] ust = command_output_quiet([ [00:08] '/usr/lib/nux/unity_support_test', '-p']) [00:08] ust = ust.replace('\x1b','').replace('[0;38;48m','').replace('[1;32;48m','') [00:08] report['UnitySupportTest'] = ust [00:08] except AssertionError: [00:08] report['UnitySupportTest'] = 'FAILED TO RUN' [00:09] testing it without the work around - I can still report a bug [00:10] but that looks fine to me [00:10] alrighty [00:16] bdmurray, uploaded [00:16] might be too late for alpha-2 but we'll see [00:17] have you thought about moving the hook to a "smaller" package at all? [00:21] the xorg package is actually quite small [00:21] but yeah I've thought of maybe moving this apport hook and the intel gpu hook (and maybe the old bulletproof-x bits) out into a separate package [00:22] -ENOTIME ;-) [00:22] if nothing else, doing so would help to minimize our diff against the debian upstream packages. [00:22] but I think there might also be some potential for shared code between the three scripts [00:25] I thought the 'Unsupported Ubuntu Release' bit would be good in apport proper [00:26] bdmurray, thanks yeah I think so too [00:27] there is some logic for figuring out what kind of regression the bug is, which I think might be a bit better than what's in the kernel apport hook as it has less user prompting [00:28] feel free to cherrypick. [00:28] I eventually plan to try submitting some of it back to apport, if/when we ever get caught up on the X bugs [00:34] RAOF, I'm losing steam as EOD approaches but have hammered the tip off of Spikey McSpike - http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/totals-natty-workqueue.svg [00:35] RAOF, if you get a chance today could you look at bugs #707236 and #710961 - two corruption regression bugs [00:35] Launchpad bug 707236 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "corruption in xchat-gnome window (affects: 3) (heat: 26)" [High,Confirmed] https://launchpad.net/bugs/707236 [00:35] Launchpad bug 710961 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack (affects: 2) (heat: 14)" [Undecided,New] https://launchpad.net/bugs/710961 [00:35] Certainly. [00:35] thanks, I'm going to try focusing on forwarding the new bugs and patches upstream tomorrow. [00:36] if there's any you already have an inkling about please put a comment on them - here's a report that might be easier to work from: http://blumonc/Arsenal/Reports/ubuntu-x-swat/workqueue-natty.html [00:37] blumonc? [00:37] dah [00:37] http://www.bryceharrington.org/Arsenal/Reports/ubuntu-x-swat/workqueue-natty.html [00:38] if there's any you want to look into yourself, assign yourself and I'll skip upstreaming them for now [00:38] Ok. [00:40] the couple tagged iso-testing and pcert are also probably high priorities for us [02:22] Ok, I think I'm closing in on bug #707236. Interested parties should try reverting 1ba983034 from xserver-xorg-video-intel. :) [02:22] Launchpad bug 707236 in xserver-xorg-video-intel (Ubuntu Natty) (and 2 other projects) "corruption in xchat-gnome window (affects: 3) (heat: 26)" [High,Confirmed] https://launchpad.net/bugs/707236 [03:09] RAOF: Yeah, that looks likely [03:10] Well, not only likely, but reverting it fixes emacs for me. [03:10] * Amaranth kicks qwest [03:10] I may not be able to test for a while, internet is like dialup with slightly better ping right now [03:11] Yay. [03:12] Anyway, I'm working out whether that commit was always broken, or is interacting with the damage updates in Xserver 1.10 [03:16] yay it sped up, building now [03:21] test [03:21] hrm, need a long line first [03:21] test again [03:21] yay [03:21] RAOF: Confirmed, that fixes the problem [03:21] Amaranth: Nifty. [03:21] hmm, got an apport report for memcheck-amd64 [03:21] that's scary [03:24] odd that regular xchat didn't have the problem, I guess they've gotten out of sync [03:25] Maybe. Emacs has a similar problem. [03:25] It's probably only things which draw in specific ways. [04:01] Hm, no. [04:01] Looks like that commit is just broken. [04:43] Amaranth, i have been trying to tell you that xchat is better [04:44] bjsnider: Oh no, I used it for a couple hours to see if it had gotten better [04:44] It's ugly [04:44] what? [04:45] It doesn't sort networks alphabetically, uses colors instead of icons to represent incoming messages, you have to show the user list to see the lag stats, and I always had to right click a URL to open it [04:46] wow [04:46] all of the things you just mentioned would irritate me in reverse [04:47] i find the colors better for incoming messages than the icons in xchat-gnome [04:47] i don't want every stray click opening a url [04:47] the networks don't have to be sorted at all [04:48] i thought your original objection to it was that it didn't have support for any gnome themes and so forth. [07:09] bjsnider: Not themes, integration (using gconf, HIG, etc) [07:19] stupid question. is it possible to have a task started in an ssh session continue after that session ends? [07:22] LLStarks: Not really on-topic in here, but look at nohup's man page. [08:48] bryceh, hello! [08:49] ara, hi [08:50] bryceh, we got a similar bug about xorg crashing for intel during ubiquity installation [08:50] https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/708744 [08:50] Launchpad bug 708744 in xorg (Ubuntu) "Xorg segfaults during installation process (affects: 1) (heat: 10)" [High,Triaged] [08:50] we opened a new one, but it seems to be quite similar to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/705078 [08:50] Launchpad bug 705078 in xserver-xorg-video-intel (Ubuntu) "Xorg crashed with SIGSEGV in pixman_image_set_has_client_clip() (affects: 9) (dups: 2) (heat: 64)" [High,Fix released] [08:52] ara, what I think would help would be to gather a full backtrace [08:52] ara, I can look into it more tomorrow; it's late for me [08:52] bryceh, sure, good night! [08:52] ara, probably what I should do is figure out how to reproduce it on my own hardware [08:53] ara, any tips on how to reproduce it could probably help [08:53] ara, ultimately I suspect that the crashes are symptomatic of a deeper issue at work, which remains mysterious [08:54] ara, I'm also somewhat wondering if it may be a peculiarity of the testing environment, because I've not seen similar reports from ordinary users installing normally [08:54] bryceh, no idea, for us it always happens (using a preseeded installation over the network) [08:54] it makes me wonder if this is dependent on some characteristic of how these tests are being installed [08:55] bug https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/706117 contains the preseed file [08:55] Launchpad bug 706117 in ubiquity (Ubuntu) "Installation fails using preseed file and network install (affects: 1) (heat: 10)" [Undecided,New] [08:55] it may help you trying to reproduce it [08:56] bryceh, hey, thanks for the dx reports [08:56] bryceh, thanks for sending the email to the list as well [08:57] ara, unfortunately I don't know how to make use of "preseed files" - if you can explain further on the bug report it might help me [08:57] seb128, heya, yep glad they're of use [08:58] bryceh, sure, will do [08:59] bryceh, do you think having a summary of natty tasks would be useful as well? [08:59] it's a bit similar to the milestoned list [09:05] seb128, you mean bug tasks targeted to a particular release, yeah I think that could be of use [09:07] seb128, I don't have that hooked up yet though [09:07] bryceh, right, I wanted the milestone list to build a list of things we (desktop or contributor) should work on if they want to help unity [09:07] but I figure that "bugs that would be nice to fix for natty" are either milestoned or have a natty task [09:07] seb128, could you file a bug against arsenal requesting this? It can be done but might take a bit before I get to it. [09:07] so we might still miss the ones without a milestone [09:08] bryceh, ok, will do [09:08] seb128, yeah agreed [09:08] the workaround would be milestone all the bugs we are about for beta or natty [09:08] are->care [09:08] I've been lucky with xorg to not have so many bugs (yet) to need to filter on that, but for unity I can see that would be quite handy [09:09] seb128, btw with the 'workqueue' report, a technique for managing it is to be very aggressive at setting bugs to Incomplete. Since the report excludes bugs waiting on responses, that can help keep the report useful. [09:10] plus it has the pleasant side effect of making reporters feel they're getting quick responses ;-) [09:17] night (dead tired) [09:20] bryceh, right, thanks for the hint, 'night! [13:52] hey guys, anyone minds if I upload http://paste.ubuntu.com/561936/ ? (xserverxorg-video-intel) [13:55] mvo: pretty sure it's ok [17:33] Hi! I am using the xorg-edgers PPA. For r600 the classic driver is the default for GL, although when running GLES2 apps the gallium driver is used. [17:35] The problem is that when forcing gallium (ForceGallium="true" in xorg.conf) GLES2 apps now complain with "libEGL warning: DRI2: could not open (No such file or directory)" [17:36] GLES2 apps run fine with gallium when not forcing it in xorg.conf [17:36] Any ideas? [17:37] EGL_DRIVER=egl_gallium yourapp work? [17:38] there has been a bunch of changes for the egl stuff recently in 7.11 and i haven't had time to fix it all up [17:39] Sarvatt: http://paste.ubuntu.com/562094/ [17:40] it uses the softpipe, while when not forcing gallium it correctly uses the hardware driver [17:41] its because we're renaming the dri2 driver name for the forcegallium thing [17:42] (to r600g) [17:42] natty mesa doesn't work either right? [17:43] Sarvatt: haven't checked, I was following the +gallium PPA before and now switched to the main xorg-edgers one [17:52] hmm, looking at it I'm not sure how to fix that [17:55] alf_: to work around it you could just drop forcegallium and make /usr/lib/dri/r600_dri.so the gallium version [17:58] RAOF, another funky upgrade blockage - https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/712640 [17:58] Launchpad bug 712640 in xorg-server (Ubuntu) "package xserver-xorg-core 2:1.9.0.902-1ubuntu4 failed to install/upgrade: ErrorMessage: installing xserver-xorg-core would break existing software (affects: 1) (heat: 6)" [Undecided,New] [18:05] How much of wayland's dependencies made it into alpha 2? Should a pre-BGRA version build and work, but not the latest with BGRA? [18:05] And is it appropriate for me to ask here? [18:07] Darxus, some deps didn't make it; I've been waiting on cairo in particular which is still tbd [18:08] Thanks. [18:08] it was my goal to have it all in by alpha-2 but just didn't have time, too many other priorities [18:09] I understand. [18:11] I appreciate that it's on your list. And I'll care more when wayland is actually usable :) [18:12] that'll take a while [18:14] jcristau: Yup. [18:44] Sarvatt: Yes, I think I'll do that and keep the old version around to use it with LIBGL_DRIVERS_PATH if needed [18:44] Sarvatt: though it complicates upgrading as I have to do this everytime I upgrade :( [18:44] yeah :( [18:45] I'm not sure how to fix it properly, it's broken in natty too from what I can see [18:45] need to make the r600 gallium driver accept a r600g dri driver name too [18:47] Sarvatt: was the idea of having an r600_dri symlink to either r600c or r600g considered as a solution to gallium vs mesa selection? [18:48] I mean gallium vs classic [18:50] yeah it was but no one wanted to implement all the extra complexity in the mesa packages and you lose the ability to have automatic fallbacks to the other driver if you switch to UMS for example [18:51] that option is starting to grow on me though :) [18:52] what about just shipping one driver? [18:53] and if you want ums, then tough, you don't get 3d. [18:53] next cycle [18:53] k [19:50] howdy! seems that X upgrade from maverick barfs majorly. [19:51] everything correctly depends upon video driver 9, but dpkg refuses to deconfigure older drivers during the upgrade, because it would break them [19:54] seems that we need to remove xserver-xorg-video-v4l before we do anything else [22:00] Woot! Intel corruption fixed. [22:00] RAOF: where? :) [22:01] Upstream, and cherry-picked by mvo. [22:04] nice [22:04] already in natty? [22:53] yep [23:22] bryceh: xorg package hook has CompositorRunning and CompisitorRunning keys in it [23:23] heh [23:25] also I'm not sure report[compiz_version] gets set anywhere [23:25] fixed the misspelling [23:26] yeah that should just be 'compiz_version', darn