[00:00] yep. waiting for login screen to come back up [00:00] hmm, black screen [00:01] try to VT switch to a console. [00:01] ctrl+alt+f1 [00:01] If you are on linux, ctrl+alt+space ctrl+alt+f1 [00:02] i think it's ctrl-fn-command on os x, but nope, it's not switching [00:02] i'm still ssh'd in though [00:02] *ctrl-fn-command-f1 [00:03] however: [00:03] % lsmod | grep vmwgfx [00:03] vmwgfx 121226 2 [00:03] ttm 83595 1 vmwgfx [00:03] drm 275528 3 vmwgfx,ttm [00:03] [00:04] sudo service lightdm start [00:04] incase doing it from X killed it. [00:04] yep, just did that again. i hear bongos, so i do think it's restarting [00:04] Hmm [00:08] Anything interesting in Xorg.0.log? [00:09] not too much, perhaps this: [00:09] [ 1104.435] (WW) Warning, couldn't open module modesetting [00:09] [00:09] Don't think so [00:10] Is 3D enabled? [00:10] on the host? [00:10] Does it say it has 3d in Xorg.0.log [00:10] grep -i 3d /var/log/Xorg.0.log [00:10] [ 1104.440] (WW) vmware(0): Failed to initialize Gallium3D Xa. No render acceleration available. [00:10] [ 1104.440] (--) vmware(0): Direct rendering (3D) is disabled. [00:10] [ 1104.440] (II) vmware(0): No 3D acceleration. Not setting up textured video. [00:11] i definitely have Accelerate 3D Graphics turned on in settings [00:11] Ok, thats normal if you don't have 3D turned on. [00:11] Oh... hmm. [00:11] What does it say drm? [00:12] % grep -i drm /var/log/Xorg.0.log [00:12] [ 1104.412] (II) config/udev: Adding drm device (/dev/dri/card0) [00:12] [ 1104.436] (--) vmware(0): DRM driver version is 2.4.0 [00:12] [ 1104.746] (II) config/udev: Adding drm device (/dev/dri/card0) [00:12] [00:12] looks okay [00:13] what do you think about adding vmwgfx to /etc/modules and rebooting? [00:14] That might work [00:14] worth a try i guess ;) [00:14] sudo service lightdm stop [00:14] sudo killall Xorg -9 [00:14] might work as well [00:14] and then starting it again. [00:15] interesting, no Xorg process found [00:15] let's try a reboot [00:17] % grep -i 3d /var/log/Xorg.0.log [00:17] [ 8.737] (II) vmware(0): Gallium3D XA version: 1.0.0. [00:17] [ 8.737] (--) vmware(0): Direct rendering (3D) is enabled. [00:17] [00:18] and yep, the llvm-based corruption seems to be gone, as is the tiny fonts on lightdm [00:22] Prf_Jakob: i have to go eod now. i've updated bug 1039157 with what i know so far. if you have any other debugging suggestions, please comment on the bug and we can chat tomorrow. thanks! [00:22] Launchpad bug 1039157 in xserver-xorg-video-vmware (Ubuntu) "X problems in Fusion guest" [Critical,New] https://launchpad.net/bugs/1039157 [00:25] barry: ok, thanks [00:25] i'll try to figure out why its not auto loading tomorrow, from the looks of it with my old logs x-x-v-vmware actually did the modprobing before though and its not now under xserver 1.13 [00:25] Yeah, I was thinking about that. [00:27] would be nice to have it modprobed earlier in the boot though so theres a splash, adding it to /lib/udev/rules.d/78-graphics-card.rules might make that happen [00:28] oh vmwgfx doesn't have any modaliases [00:28] thats why its not auto loaded by udev? [00:29] Heh, I don't even know what a modalias is :) [00:30] modinfo i915 lists the devices it auto loads from udev for, nothing on vmwgfx even though theres 1 pci id [00:30] Ah [00:31] What does the splash use btw? [00:32] libkms, OpenGL? [00:35] if theres /dev/fb0 it uses that, theres specific backends written for each kms driver, although i think that changed in 12.10 and it uses the newer dumb ioctls. there is a libkms backend for the drm renderer that would work though thats also in 12.04 though [00:35] * Sarvatt passes the heck out, sorry to disappear suddenly :) [06:08] RAOF: busy with the baby?-) [06:09] tjaalton: Yeah; Sam's gone out for an appointment, so I'm holding the baby :) [06:09] alrighty [06:12] RAOF: ping [06:12] Pong [06:12] RAOF: you dropped the core patch and are encouraging -core to be passed, how do you pass that by default? [06:13] mlankhorst: In lightdm [06:13] mlankhorst: I should see if that's been uploaded, actually. [06:13] RAOF: wondering if the libgallium patch should actually be modified to add the gallium stuff in libdricore, if what you said that's what upstream might take [06:14] RAOF: yeah but could that be sru'd for precise somehow for next lts stack? [06:14] also, probably no reason to move libdricore out of libdir to libdir/dri [06:14] hmm need to add that to debian [06:23] mlankhorst: Hm, possibly [06:24] dvorak is poorly optimised for 1 handed typing! [06:24] use a smartphone :D [06:25] or a dumbphone with t9 [06:25] or get a carrying sling :) [06:26] or use text to speeds [06:26] it shoot laugh your ascend! [06:28] No irc on my phone :) [06:29] I can't find the baby sling, either :( [06:29] nasty name for that thing btw :) [06:30] Not for launching babies at all! [06:31] we never said that [06:31] :) [06:31] it looks like the stress of parenting is getting to you if you would think we would think about such cruel things [06:45] do you manage to sleep at nights, even? [06:48] Yeah; plenty. [06:48] Zoë's pretty good that way. [06:49] ...and xserver uploaded. [07:17] upload with one hand? [07:17] git push with the other [07:18] where's the baby then? :) [07:18] damn ;) [07:18] Up in the air. [07:18] You throw her up, type something, and then catch her. [07:24] RAOF: lucky you, I have to face the wraith of ttm maintainers :) [07:27] which I guess in a way wouldn't be too unsimilar from a crying baby at night [07:27] * mlankhorst ducks [07:33] Heh [07:45] hum, trying to build mesa with --with-llvm-shared-libs, but fails [07:45] g++ -L/usr/lib/llvm-3.1/lib -lpthread -lffi -ldl -lm lp_test_blend.o lp_test_main.o -o lp_test_blend -Wl,--start-group -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVM-3.1 -lXext -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -lXxf86vm -ldrm -lm -lpthread -ldl -Wl,--end-group [07:45] /usr/bin/ld: ../../auxiliary//libgallium.a(u_dl.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5' [07:45] bjsnider: Latest nvidia-settings 304.37 for amd64 has failed to build in X updates PPA. Looks like the archive was distributed in a slightly unclean state. Removing objects under src/libXNVCtrl/ in advance should fix the build.. [07:45] /usr/bin/ld: note: 'dlclose@@GLIBC_2.2.5' is defined in DSO /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libdl.so so try adding it to the linker command line [07:45] /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/libdl.so: could not read symbols: Invalid operation [07:46] oh, and bumping build-deps like llvm isn't nice for backports, I guess [08:49] your libdl is screwed? [08:50] either that or you forgot -ldl :) [08:51] he has -ldl there twice [08:51] ah [08:51] and ld even says it found dlclose there [09:14] dunno, fedora has a recent snapshot and they use --with-llvm-shared-libs, so wonder why it fails to build here [09:16] tjaalton: well what if you remove one of those 2 and build it manually? [09:16] mlankhorst: still the same [09:17] did you remove the first one or the second one? [09:17] tried both [09:17] doesn't the error suggest that something is wrong with libgallium.a? [09:17] static libraries are weird [09:18] I think you might need to remove the -Wl,--start-group and -Wl,--end-group and keep the last libdl [09:20] broke even harder :) [09:21] sigh [09:21] can you send me what you have? [09:22] git pull [09:22] no wait [09:22] merged master and bumped the version to 9.0~git.. [09:23] there [09:24] it was the same error with the previous snapshot [09:25] blegh needs quantal to build, give me a sec [09:26] yup [09:26] updating chroot [09:29] ok i seem to get the same error :) [09:29] good :) [09:30] g++ -L/usr/lib/llvm-3.1/lib -lpthread -lffi -ldl -lm lp_test_blend.o lp_test_main.o -o lp_test_blend -Wl,--start-group -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVM-3.1 -Wl,--end-group -lXext -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -lXxf86vm -ldrm -lm -lpthread -ldl [09:30] seems to work [09:33] but I have no idea where the start-group and end-group are inserted.. [09:33] src/gallium/Makefile.template [09:34] it should be just protecting llvmpipe and lgallium, not the rest [09:34] isn't that a ld bug? [09:35] possibly [09:37] seems Sarvatt had already reported it as https://bugassistant.libreoffice.org/show_bug.cgi?id=49504 [09:37] bugs.freedesktop.org bug 49504 in Mesa core "[Bisected] Mesa master compilation broke when built with --with-llvm-shared-libs" [Normal,Resolved: duplicate] [09:38] and duplicate bug had this attached https://bugassistant.libreoffice.org/attachment.cgi?id=65103 [09:38] so maybe just cherry pick that? [09:39] it's not in master [09:39] but if you mean cherry-pick from bugzilla then yes [09:39] yeah :) [09:40] sigh, why do I know such things are a problem even before finding the bugzilla entry :s [09:43] ok I'll add that to the debian branch [09:43] and do yet-another merge.. [09:43] :> [09:45] wish I had something to push to mesa so you'd immediately rebuild again :p [09:47] I can push to most of X now [09:47] me too, never abused it though [09:48] once had plans to break -sis, but meh [09:48] the trick is you don't want to see it as 'abuse' :) [09:48] touch something and you're the defacto maintainer [09:49] hm lets see about virtualbox then [10:00] yay [10:00] virtualbox won't even netboot despite advertising it? o.O [10:28] my screen' dpi is 138 but its always hardcoded to 96 in ubuntu. is there a way I could change that? [10:28] xrandr --dpi 138/eDP1 seems to have no effect [10:28] tjaalton: surprisingly, works here.. [10:29] mlankhorst: huh, ok [10:29] virtualbox seems to start fine [10:29] although compiz is corrupted if i try [10:29] yeah that's the bug then [10:30] but is it general llvmpipe-borkedness or something else.. [10:30] no idea [10:31] check the log :) [10:32] it's using llvmpipe at least.. [10:32] there you go [10:32] so it's fallout from dropping unity2d [10:32] so.. nothing to worry about then? [10:32] right [10:32] sry :) [10:32] but hey, now you have time to fix the libgallium.so build?-) [10:33] probably [10:33] what needs fixing? [10:33] don't know what good --with-llvm-shared-libs brought [10:33] make the patch apply and build the .so [10:33] oh that [10:33] you know that would mean the whole llvmpipe patch could be dropped, too [10:33] but it might be easier(?) to merge it in libdricore [10:33] probably so yeah [10:34] wanted to see what it did [10:34] and don't see much [10:35] will virtualbox be sru'd to precise for .2? [10:35] since the dkms module will no longer build and the xorg one needs an update [10:36] nah [10:36] vbox users can stay on .1 [10:36] i mean the stack on .1 [10:36] :/ [10:36] why not? [10:37] it's not like the "hw" needs enabling [10:37] still leaves the kernel build failure, though [10:37] wait, what? [10:37] if you enable the 3.5 kernel on precise [10:38] make it conflict [10:38] it's possible today.. [10:38] breaking the setup that is [10:38] yeah, I'll ask leann [10:39] nah, make vbox conflict with the kernels that it doesn't support [10:39] easier [10:39] conflicting with kernels is teh suck [10:39] well :) [10:39] but right i don't care enough today, I'll add a point to backports to think about it later [10:40] or sth [10:42] yeah [10:43] ok enough caring for now, I'll look at the gallium patch [10:43] great [10:44] would take more time if I tried :/ [11:00] I kind of want to ask raof about it first, i sort of understand the patch but not the reasoning behind it [11:00] sure [11:01] seems to be having some network issues [11:03] seems sort of like since it's using libgallium everywhere anyhow, it could just change libgallium.a to libgallium.so and be done with it [11:15] tjaalton: seems a variant of it was already merged though [11:15] oh? [11:16] the patch adds --enable-shared-dricore [11:17] there's the libdricore support upstream yes [11:18] oh nm it was just from my first partial apply [11:19] :) [11:28] can the entirety of libgallium.a be built shared? [11:30] no idea :) [11:41] * mlankhorst tries a automake hack [12:27] well looks a bit harder to make it shared than I thought [12:27] it's part autotools and part custom makefiles.. [12:33] yeah :/ [12:40] ok next attempt [13:46] more luck now [13:46] how much more? :) [13:46] oh as in 'almost feeling confident it links libgallium.so correctly' [13:47] cool [13:48] mlankhorst, hey [13:48] + [ubuntu-x-swat] Detect gfx hardware changes (maybe by checking the modaliases?) and inform users about the change: TODO [13:49] mlankhorst, please try to find somebody rather than a team for workitems, team assignments tend to not work, everybody waits on somebody else to pick the stuff up which often never happens :p [13:50] seb128: yeah unfortunately half of my team went to sleep or didn't wake up yet :) [13:51] fair enough ;-) [14:09] tjaalton: I think libtool leads to aggression in a natural way [14:20] yay.. builds static and shared :) [14:33] mlankhorst: virtualbox upstream requires contributions to be licensed under the MIT license. if you can agree to that posting the patch and a license statement to vbox-dev@virtualbox.org would be great. [14:35] debfx: you send it then, copyright belongs to canonical ;) [14:37] mlankhorst: huh? [14:38] I mean unless I'm mistaken since I did it as part of my work for canonical, the copyright belongs to canonical, not me personally :) [14:40] but shrug it should be fine, I'll send it [14:51] tjaalton: blegh is it really worth it building libgallium shared? [14:55] mlankhorst: ask the ones who try to keep the cd image under 700M :) [14:55] those people still exist? [14:55] that said, i'm not sure if we have more to use for quantal [14:55] not sure [14:55] shrug I think I'm close [14:56] seb128: do you know? ^ [14:56] some linking error in llvmpipe :s [14:57] tjaalton, mlankhorst: what's the issue? [14:58] is the installer image size still 700M [15:02] lets see if it's just llvmpipe breaking.. [15:04] woops, probably made all symbols invisible :) [15:14] *amused* even on his homepage ulrich drepper manages to be ulrich drepper [15:14] "If you have problems with this page it probably means you are using a junk browser. Especially the one from the monopolist. Get something better. Use Firefox or Mozilla." [15:20] mlankhorst: ok, we have enough space for mesa, so don't worry about the patch anymore. we can fix it later [15:20] stash your changes somewhere :) [15:23] mlankhorst: i promised to upload it later today, mind giving it a go on some machine if you have some to spare? since I don't know what the llvm-shared-libs actually did, testing some gallium based driver would be great [15:23] I have some radeon card to test with [15:24] but can't get to the machine until maybe 3h from now [15:32] barry: ping [15:32] Prf_Jakob: pong [15:33] Ah you are here. [15:33] yep, how's it going? [15:33] fine, haven't done anything more on the bug. [15:34] HAve a interface change for mesa that needs to be done before the stable branch is created. [15:35] Prf_Jakob: np, the workaround is getting me thru. i was thinking about changing the bug title to "vmwgfx kernel module not getting loaded by default". would that be helpful? (if not, i'll leave it as is) [15:35] tjaalton: ok [15:36] tjaalton: I can stash it, but it seems to be a pain to get it really working [15:37] bah, speaking of mesa my fix still hasn't made it in. [15:37] barry: that is the real issue. [15:38] Prf_Jakob: done [15:38] thanks [15:38] tjaalton: I can build libgallium.so just fine, it's the linking that's proving to be a pita :) [15:40] tjaalton: but what do you want me to do, test if it works on a radeon card? [15:40] Prf_Jakob: thanks for looking into this and helping me out! [15:41] np [15:43] tjaalton: hm, seems to be just swrast failing [15:45] but I'll put the changes together into something almost coherent [15:50] ok lets see if those binaries work on quantal :) [16:24] mlankhorst: yeah test the non-libgalliuminized (!) version to see it works, i believe intel is mostly fine [16:33] inte's easiest to test for me right now :p [16:49] tjaalton: not getting a desktop, weird [16:51] oh, old kernel [16:56] just some kernel panics on 3.5.0-11 I suppose, nothing really wrong :p [17:01] tjaalton: I have no idea what's wrong with the drivers but glxgears spins fine, so dno.. [17:01] it was broken before too, though [17:04] hmm, quantal works on snb for me [17:05] though the machine has 3.5.0-8 [18:01] tjaalton: yeah but it was broken before too, guessing the ddx was screwy instead [18:02] ok [18:10] uploaded xorg that adds -modesetting to video-all [18:12] yay \o/ [18:12] had it in git for some time.. [18:24] blegh, updating lts-quantal can wait [18:34] tjaalton: modesetting's in universe :( [18:35] Sarvatt: yes, informed -release that it needs to be moved to main [18:40] ogra_: is it armhf you care about for llvmpipe? [19:03] haha [19:04] mesa *.install.in totally messed up [19:07] hrm, if we're not going to get swx11 back, maybe it would be best to drop the separate 'dri' build target and have sane paths in *.install.in [19:09] tjaalton: we don't know that yet [19:10] it's useful on s390 [19:10] fedora builds it only on that arch [19:10] and nothing else, since it has no gfx hw [19:10] and for all we know there is some insane reason to keep it [19:11] if it has no graphics hardware why would you need it? o.o [19:11] fine, I'll mess with the .install files then [19:11] running apps remotely? [19:11] no idea [19:12] after quantal is released there'll be no objection from me to drop it :) [19:12] it's dropped already [19:12] in git [19:13] meant the separate dri stuff [19:13] ok [19:13] but shrug i suppose in worst case you do it now and it turns out we would have to revert that common [19:15] ok correction, fedora builds swrast on s390, no swx11 at all [19:15] I retract all my objections :) [19:16] right [19:16] I'll take the heat to revert the packaging, it isn't that hard [19:16] if it should happen [19:19] or maybe I'm just a coward and fix the install files instead [19:20] hey for stable releases it's good to be a coward :) [19:22] argh [19:22] tjaalton: i'd prefer to keep swx11. [19:23] it's still useful if you don't have glx [19:23] that's for debian, you can do what you like in U :) [19:23] in that case no point in changing the directory off [19:23] yeah I kept it there, it should build again soon [19:24] either I change the directory, or edit all install.in to copy the stuff from dri/.. to .. [19:26] dunno which makes more sens [19:26] e [19:26] whatever gives the smallest delta with debian [19:27] ok it's easier to revert the install.in [19:28] than to retest big changes to rules [19:36] :-) [19:37] * mlankhorst always favors the lazy approach [19:37] jcristau: what about the libosmesa build? I ripped those targets, but the downside is that the static libs are gone [19:39] dunno [19:42] tjaalton: libosmesa is still built right? [19:42] mlankhorst: yes, but during the dri target build [19:42] ah good :) [19:43] and since you can only build either static or dynamic libs, the static ones are now "lost" [19:44] same thing with libglut [19:44] libglu, whatever [19:44] yeah, just have no idea what libosmesa does, just know wine can use it :p [19:47] E: libgl1-mesa-dri: binary-or-shlib-defines-rpath usr/lib/x86_64-linux-gnu/dri/i915_dri.so /mnt/src/git.d.o/lib/mesa/build/dri/src/mesa/libdricore/.libs [19:47] wth [19:48] shared dricore probably [19:48] oh well, needs fixing then [19:48] less lintian errors anyway [19:48] yeah usually the autotools relink before install [19:48] getting there [19:49] but those specific ones don't autotool [19:49] need a break.. -> [20:27] tjaalton, yeah, dont bother with armel [21:31] mesa-8.0-llvmpipe-shmget.patch on fedora. probably worth checking out at some point === jibel_ is now known as jibel === RAOF_ is now known as RAOF