=== inetpro_ is now known as inetpro [18:32] bryceh: ok failsafe X not working is because of xdiagnose [18:32] aka downgrading to xdiagnose 1.6 from oneiric makes failsafe work again [18:32] erf. oh? [18:32] weird. [18:32] ok thanks [18:32] change the init scripts? [18:32] had to be [18:33] I'll have to review. I did do some cleanups [18:33] i'm going through it all now, just tested the downgrade to be sure and that was it [18:36] bryceh: the explicit vt7 [18:36] ah [18:37] thats the only thing remotely different [18:37] http://paste.ubuntu.com/891040/ [18:37] testing that out now [18:37] yeah and that could do it [18:37] wonder why I added it? [18:41] bryceh: yep that works, failsafe X is on vt2 [18:41] alright thanks [18:41] I *think* I might have added that to address some other problem... digging... [18:42] aha [18:42] Force vt7 when launching Failsafe-X. [18:42] [18:42] In testing on Precise, it appears when lightdm doesn't start, X will [18:42] choose to start on vt1 by default, which ain't gonna work. [18:44] alright, so I'll re-test this on my hardware and upload new xdiagnose today or tomorrow === yofel_ is now known as yofel [20:11] evening [22:55] RAOF, ping [22:55] cnd: Pong. [22:55] RAOF, so I just pushed the xorg-gtest stuff [22:55] a couple minor fixes and changes from a review from stephen [22:55] * FernandoMiguel runs [22:55] Cool. [22:55] RAOF, the question now is do we try to push it into precise? [22:55] ahhaha [22:55] there's a dependency on xorg-macros 1.17 [22:56] Hm. [22:56] we either need to update in precise [22:56] or remove it [22:56] If it weren't for that, I'd unreservedly say yes. [22:56] RAOF, we could also distro patch out the need for xorg-macros 1.17 [22:56] cnd, what needs it? [22:56] or just FFE xutils-dev, its already in debian and is very low risk [22:57] bryceh, it depends on xorg-macros for proper distcheck [22:57] it doesn't affect the real meat and potatoes of xorg-gtest [22:57] The only real concern with the new xorg-macros would be build failures, right? [22:58] yeah [22:58] there's near 0 concerns though [22:58] let me double check that statement :) [22:58] yeah and there are none, i've built just about everything against the new macros, it's just excessively chatty with warnings now but not that big a deal :P [22:59] Sarvatt, what version of the macros do we have in ubuntu? [22:59] 1.15.something [22:59] xutils-dev version doesn't match the upstream macros version [22:59] hmmm... [22:59] I don't know much about what has changed from 1.15 to 1.16.2... [22:59] 7.7~1 has 1.17 in it [23:00] Sarvatt, why is it ~1? [23:00] 1.16 was mostly excessively verbose warnings by default :) [23:00] because 7.7 katamari isn't released [23:00] but the warnings were cut back some in 1.16.2 [23:00] oh, it's the katamari version [23:00] yeah [23:01] RAOF, bryceh, Sarvatt: would we be updating to the 7.7 katamari for precise anyways? [23:01] I don't know what the release schedule is [23:01] "X11R7.7 development is underway for release in the first half of 2012." [23:02] I don't think we'd bother? [23:02] http://www.x.org/wiki/Releases/7.7 [23:02] nope its too late, most of the katamari releases weren't important though, things like 3 build system changes only for lots of the new lib releases [23:02] that page is way out of date though :) [23:02] ok [23:02] we usually don't bother [23:03] fwiw, pulling in the new xorg-macros 1.17 is fine with me [23:04] as pointed out above, is likely very low risk. If it helps xorg-gtest, great. [23:04] or xserver 1.12 video abi changes only (that we arent shipping) for lots of the video drivers [23:04] I'm also happy to pull in xorg-macros 1.17. We should do a test-rebuild of everything, though. [23:05] RAOF: could we get that done before the beta 2 freeze on thursday? [23:05] cnd: Oh, I'd do a post-hoc test rebuild. [23:05] historically the final katamari release has tended to come either after we release or well into when we're hard frozen. [23:05] RAOF, ok [23:05] cnd: Upload now, rebuild later :). We don't expect any problems. [23:06] Sarvatt, do you think we should add xorg-macros into the current xutils-dev, or just sync 7.7~1 from debian? [23:07] what has changed between 7.6+6 to 7.7~1? [23:07] oh, we're up to 7.6+10 now :) [23:07] cnd: whichever you feel more comfortable with, i dont think it'd be good to go out of sync with xutils-dev versions though since the only thing useful out of it is macros [23:07] Sarvatt, I don't really know much about the xorg package [23:08] http://anonscm.debian.org/gitweb/?p=pkg-xorg/app/xutils-dev.git [23:08] so I need some guidance :) [23:08] Sarvatt, oh, it's not even ~1 anymore [23:08] it's -1 [23:08] can't risk breaking imake! [23:08] wait, nm [23:08] the tag is wrong [23:09] ok, so it seems like the best course of action is to sync from debian unstable [23:09] at least it's not from experimental :) [23:09] xutils-dev is just utils for building the X packages, so as long as raof's rebuild goes fine, that's really all we need it for. I'd just sync the debian package. Keep it simple. [23:09] guess you cant ~ in the tag [23:09] last question is: do we need to file an FFe for it? [23:10] ostensibly, it's just to fix a big bug in xorg-gtest :) [23:10] I think so, yes. [23:10] it can't hurt [23:10] but it does seem like it would be good to have an FFe for the xorg package [23:10] yep requestsync -d unstable -e xutils-dev [23:11] good channel to communicate the whyfor of needing to rebuild the X archive [23:11] I'll file an ffe for it [23:13] Explanation of FeatureFreeze exception: [23:13] util-macros 1.17.0 is needed for an updated xorg-gtest which is used for [23:13] unit testing X. The changes in this package are very low impact, util-macros [23:13] is required by most X packages and the only major change that is non-opt-in [23:13] is increasing the verbosity of GCC warnings during the builds. [23:14] that sound ok? i'll just hit submit if someone with upload privileges can ack it [23:14] sounds good to me [23:14] Yup. [23:14] maybe mention, "To be 100% safe, we will also trigger a rebuild of all potentially affected packages in the X stack." [23:15] https://bugs.launchpad.net/bugs/959791 [23:15] Launchpad bug 959791 in xutils-dev (Ubuntu) "FFe: Sync xutils-dev 1:7.7~1 (main) from Debian unstable (main)" [Wishlist,New] [23:15] oh, +" and follow up on any issues that arise." [23:15] k editing it [23:17] Sarvatt, I was in the middle of filing it, but I'm glad you're taking it :) [23:17] if anything, it will keep ScottK off my back for perceptions of too many FFe requests made by the touch team :) [23:19] RAOF, do you know a release team member who would be able to review it right away? [23:19] some of the FFes can sit for a few days, and I don't want to leave this for after beta 2 freeze [23:19] maybe ping slangasek? [23:20] ok [23:22] hey [23:22] does anyone here have experience with fglrx? [23:22] Sarvatt, ack'd [23:23] bryceh: thanks a ton for that, was just about to ask [23:23] cnd: sorry for stepping on toes, had it all done before seeing ya say you would do it and figured it'd save time :P [23:23] Sarvatt, np :) [23:23] have been planning on filing that for the past week [23:24] I'm surprised someone else was willing to file an FFe :) [23:24] bryceh, if you clicked the "this affects me too" button, I think it's the wrong thing to do for an FFe [23:24] the janitor bot moves it to confirmed [23:24] ah [23:24] and the process documentation says it needs to be in the new state [23:25] the release team has probably realized that by now [23:25] cnd: hmm [23:25] but I don't like leaving things to chance [23:25] so when i file bugs with requestsync without upload permission, its in a new state and a core-dev has to ack it by setting it confirmed [23:26] Sarvatt, that's a different process from FFes I think [23:26] but i guess this ones different because its in the FFe stage, after THAT got acked it'd unsubscribe release team and they'd subscribe sponsors and go through that [23:26] https://wiki.ubuntu.com/FreezeExceptionProcess#General_Instructions [23:27] it says if it's not in the new state, the release team may not see it [23:27] I *think* the release team moves it to confirmed [23:27] in which case, their reports may not show a bug that has already been moved to confirmed [23:27] sounds right [23:36] eruditehermit: http://paste.ubuntu.com/891499/ [23:37] Sarvatt, what does that do? [23:39] just add your switcheroo stuff you want to do to it on resume to disable the gpu [23:39] Sarvatt, hmm, I already have a script that does that [23:39] Sarvatt, the issue is that it causes my system to be unresponsive for 20 seconds [23:39] ah gotcha, no clue about that :( [23:39] and the fans start whirring uncontrollably during this time [23:40] this is annoying when it happens in public [23:40] lol [23:40] ideally, switcheroo would save the state before suspend [23:40] or not report incorrect state [23:44] Sarvatt, also my fglrx works with hybrid gfx, but when I want to switch back to intel, it doesn't switch where it looks for libGL [23:47] is there an updated ubuntu package version that works with hybrid? [23:47] you mentioned someone was working on that? [23:50] I have absolutely no clue at all on the status of it outside of tseliot saying he was working on those scripts not long ago, he's the maintainer of it and its about 2 am his time now so cant ask