[00:15] RAOF, SRU bug #1037483 looks ripe for pushing out for nvidia-current-updates [00:15] Launchpad bug 1037483 in nvidia-settings (Ubuntu Precise) "[SRU] Needs NVIDIA driver 304.43 [HW-Certification blocker]" [Medium,In progress] https://launchpad.net/bugs/1037483 [08:08] morning [08:16] mlankhorst: "morning" man :) [08:37] bryceh/RAOF: Any objections if I nuke a bunch of renamed mesa/xorg packages from the stack and let those fall back to the old unrenamed packages? [08:38] libosmesa6, xnest, xdmx, xephyr [08:38] xfbdev [08:39] libglu1 (now a separate package, so I didn't see a reason not to keep the old one from mesa 8 instead) [08:39] if you say xvfb next yeah [08:39] yeah [08:40] libglu1 should be easy? [08:40] mesa 9 no longer packages it [08:42] installed precise on my laptop next to quantal.. time to fix the intel pageflip issue there [08:43] damn 101_copy-fb.patch not being the same as upstream, thats the only thing stopping it from being easy :) [08:43] and osmesa6 might get a soname bump in r to osmesa8, so we could keep it unrenamed [08:44] yeah likely so [08:44] hell you could probably keep it as osmesa.so.6, not 100% sure though [08:44] that's what we do now [08:44] Sarvatt: either way it's something that's going to give more pain to rename than to keep the old version [08:45] my ubuntu was installed as lynx and then upgraded until i reach quantal ... (i think someday i should make an clean install again ..) [08:45] its only bumped to 8 because fedora/suse bumped to 8 and rebuilt everything against that afaik [08:46] but hey its whiskey o'clock here [08:47] yeah but unless there is a reason to upgrade osmesa i feel like we should just keep the current binary [08:47] havent heard anyone complain we kept it 6 all throughout 7.xx [08:48] and 8.0.x [08:48] it hasn't changed [08:48] the only thing you should need to upgrade from mesa is the dri drivers, really [08:48] and egl in the future :/ [08:48] but I'm hoping at that point that nvidia dev has his proposal for a stable libGL in [08:54] is libgl1-mesa-dri-experimental still used? seems to be empty [08:55] it is [08:55] someone wanted to have i915g there [08:55] ~/nfs/xorg/mesa/debian$ find libgl1-mesa-dri-experimental |grep i915 [08:55] ~/nfs/xorg/mesa/debian$ [08:55] it's not there _now_ :) [08:56] ok can just kill it off for the renamed stack, then [08:57] yep [09:31] are the udeb files used anywhere in ubuntu? [09:31] installer [09:32] so you need them for .2 [09:32] ok [09:33] i dont think any x related udebs are used no [09:33] oh right [09:33] heh [09:33] forgot [09:34] :p [09:39] Yeah, we don't use X11 in debian-installer. You're good :) [09:39] shrug I'll leave it for now, it would be more work to remove udeb generation [09:42] changing one line in debian/rules is easy, but why do it if its not breaking anything :P [09:42] Sarvatt: it's the testing that's hard [10:07] hm tempted to append originalname-lts and xorg-renamed-package, so simply having a package conflict on xorg-renamed-package would be enough to kill all renamed packages, and i wouldn't need to repeatedly sru the original xorg-server every time a new version is released [10:07] to each provides* [10:08] and in case of conflicts/replaces, add originalname-lts to conflicts/replaces too [10:08] hm that part is not needed i think [10:20] give an example with real package names :) [10:21] provides: xxv-intel, xxv-intel-lts, xorg-renamed-package, xorg-renamed-package-lts-quantal [10:22] oh, virtual packages you mean? [10:22] yeah [10:24] it's just because xnest and such have a versioned depends on xserver-common, which could be replaced with xserver-common >= currentversion | xserver-common-lts [10:24] eww [10:25] jcristau: well it was never going to be nice, anyway [10:25] and if it helps upstream is going to stay untouched :) [10:26] would it be possible to build xserver-common from the xorg-server-lts-foo without renaming it? [10:27] hmm probably [10:27] then people who don't use lts-quantal would upgrade xserver-common automatically to it.. [10:27] or 'package withheld' [10:28] yeah that's the problem, and that the manpage for Xserver(1) might change :) [10:30] well if people want to keep that package unrenamed it shouldn't be hard to keep it like that.. [10:30] * mlankhorst doesn't care either way [10:30] mlankhorst: considering the contents of that package, upgrading it shouldn't be a big deal, hopefully [10:31] ok leaving it unrenamed it is, then [10:31] * mlankhorst hopes launchpad won't bork on that [10:31] just an idea anyway... [10:32] should be easy to change back [10:32] if needed [10:32] * mlankhorst adds a rename entry for xserver-common to xserver-common :P [10:32] the only "risk" is if it's confusing to see options for Xserver that the current installed version doesn't have [10:33] is protocol.txt backward compatible? [10:34] seems that is being parsed at least.. [10:34] iirc it's read by the selinux stuff [10:34] or xace anyway [10:34] dri2 was the last thing added to it in 2009 [10:34] *latest [10:35] yeah eamon kind of vanished [10:35] tjaalton: dri2.5 coming up though.. [10:35] and then this didn't get updated [10:35] but ok if it won't break I don't care [10:44] now how do I get this building again [11:28] dh_install: dri/usr/include/GL/osmesa.h exists in debian/tmp but is not installed to anywhere [11:28] bjsnider, i am curious did you look into updating libva while there are some newer releases [11:28] argh why would that get installed with --disable-osmesa [11:28] >:( [11:29] building current mesa from quantal? [11:34] yeah renamed [11:34] killing off osmesa is.. fun [11:36] hopefully fixed now [11:36] oh right [11:38] mlankhorst: remember me? :) [11:38] I changed from xubuntu to default ubuntu a while ago, and my X hasn't crashed ever since [11:39] and now you are back because your x is crashing again? [11:39] well, actually it has hanged a few times, but nothing similar to the old behavior of crashing twice a day [11:39] Hanmac: no, just to report that things are not so bad :) [11:41] * Hanmac knows what is bad ... currently i need to reboot more than five times each day because something breaks my output [11:47] ok mesa builds [11:59] # Make sure Xvfb at least starts up [11:59] PATH=debian/tmp/main/usr/bin/:/bin:/usr/bin \ [11:59] debian/tmp/main/usr/bin/xvfb-run -s "-screen 0 1280x1024x24 -nolisten tcp -noreset" true [12:00] xvfb-run: error: Xvfb failed to start [12:00] haha [13:36] hum, would it be too bold to replace -intel's 101_copy-fb.patch with the commit from upstream, for precise [13:36] would help in backporting the pageflip fixes [13:38] ricotz, in x-updates? i thought about it [13:51] bjsnider, i thought more about debian, if i have seen this right, you were involved there [13:52] and the git repo seems messed up and abandoned :\ [13:52] oh, i didn't know that [13:52] i will check into it [13:52] alright [13:59] ricotz you are looking like an expert can you look at my bug, maybe you can find the culpit? #1060987 [14:03] Hanmac: I've told you enough that upstream needs to respond, we don't know what's wrong and can't help you :/ [14:03] asking someone else will just give you the same answer twice [14:04] ricotz, btw you can put the latest clutter-gst and totem in the ppa. i built them here and installed them and they work fine [14:25] bjsnider, at least clutter-gst-2.0 is suppose to land in quantal, yeah totem should be updated there [14:26] assuming you meant the gnome3 ppa ;) [14:26] of course [14:28] oops, wonder if that's why xserver broke, probably best not to have xserver-common conflict with itself [14:28] Hanmac, i mentioned it already i don't have an amd gpu here so can't test it -- and yes, most part of the driver is located in the kernel which makes it a possible source of the problem [14:29] so i am forced to sit on this vulcano until i buy newer hardware ? :'( [14:29] mlankhorst, regarding nvidia hopefully this gets fixed, not that i care about unity, but maybe if 310 is out 304 gets an update too [14:32] Hanmac, you can go for testing kernel 3.7 and hope it makes a difference -- http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ [14:34] and of course #radeon [14:35] * mlankhorst notes that a package conflicting with itself has interesting effects on apt [14:35] "not that i care about unity" hahaha rock n roll [14:38] the 3.7 (3.6 daily) did not help yet, but i may have differnt errors (currently i load the newest daily) [14:41] mlankhorst, no objections here. I was wondering if those were sufficiently client-ish that they could be omitted, so good. [14:42] bryceh: yeah i seemed to have broken something though, even with hints it no longer did the upgrade correctly. I'm testing if it was because I made xserver-common conflict with itself. [14:47] or at least i was taught that if you could prove 1=0 then you cna do all kinds of fun things that defy logics :) [14:52] mlankhorst, I think I derived that answer on more than a couple final exams in college... [14:53] hehe :P [15:51] Provides: xorg-input-abi-, xorg-renamed-package, xorg-renamed-package-lts-quantal, xorg-video-abi-, xserver-xorg-core [15:51] figures.. [15:54] so how does the intel backport work on precise? I've tried the old version with the upstream copy-fb patch but it fails to start [15:55] assuming it conflicts with plymouth, or maybe needs something else backported? [16:02] I didn't look at it yet [16:05] hmm [16:06] actually failsafe does start, lightdm doesnt' [16:06] for some reason I have no abi any more [16:07] oh heh, of course [16:07] failsafe uses vesa [16:07] duh [16:08] and looks like it just needs the compat commit [16:08] excellent [16:08] accidentally killed all calls [16:15] oh yes, just needed to change pScreen to match the old api [16:15] so now I should have all the pageflip backports for precise [16:15] oh that [16:16] plus the do-copy-fb commit [16:16] backported [16:18] well xorg-server backport fixed again, was a bit overzealous with sed [16:47] multilib is fun and breaking things in a new way I fear :/ [16:51] flip_test passes [16:53] hum, or maybe not [16:53] both versions fail the same way [16:59] or maybe it's testing plain kms [17:39] hm this thing hates me.. :/ [17:39] * mlankhorst wonders if it's easier to rename libglapi [17:42] or maybe I'm just hitting a bug in apt.. [17:46] seems like it.. 32-bits libglapi-mesa-lts-quantal is unpacked, then it tells dpkg to extract 32-bits and 64-bits libgl1-mesa-glx-lts-quantal, it misses 64-bits libglapi-mesa-lts-quantal and things go boom [17:57] blegh eod even if i started late :P === yofel_ is now known as yofel [18:32] hey guys, I've posted status summary of where we are with bugs across all the X packages. I doubt I'll have time to look into those things (maybe some nvidia bugs), but wanted to highlight the problem areas in case you want to tend to some of them. the xserver crashes in particular could use some attention. [19:07] tjaalton, you took a shot at packaging gstreamer-vaapi i see [19:07] bjsnider: some time ago [19:07] http://anonscm.debian.org/gitweb/?p=users/tjaalton-guest/gstreamer-vaapi.git;a=summary [19:07] haven't touched it since [19:07] does it build? [19:07] new release happened today i guess [19:07] someone touched it on quantal I think [19:07] so I guess it builds [19:25] sigh, where to upload -intel for precise.. all the ppa's have a newer version already :) [19:25] let's just use proposed then.. [19:29] or maybe not, now the patch fails to apply.. wtf [19:30] heh, pebkac [19:56] ok pushed -intel to precise-proposed, with a detailed test case on the bug.. [19:56] time for EOD [20:03] heh, that email didn't take long to hit phoronix. must be a slow news day [20:20] bryceh: probably :P [20:21] although i did gain some insight in the making of phoronix on xdc2012 [20:21] oh? [20:21] seems tons of beer is involved in making news! [20:24] and some of the articles are really jus ttrolling after all [20:29] mlankhorst, did michael admit that?