[00:16] doko_: since you did the merge of directfb, and deliberately re-enabled the build-dep on libts-dev, does that mean you're approving this as an MIR? :) [00:31] soren: is bug #196850 fixed in intrepid, or is it still just "Committed" somewhere? [00:31] Launchpad bug 196850 in virt-manager "vm cannot access cd-rom unless run as root" [Medium,Fix committed] https://launchpad.net/bugs/196850 [00:57] pitti: do you happen to recall why you marked bug #229499 as 'fix committed' for intrepid? [00:57] Launchpad bug 229499 in linux "Latency regression with real time kernel and dynamic ticks feature" [Medium,Fix committed] https://launchpad.net/bugs/229499 [01:34] jelmer: so, er, is there really no better way to tell the difference between a directory and a file in svn than trying to get a list of files within it? [01:34] jelmer: (I say, having had to nuke my cache of the pkg-samba repo and now watching the wheels spin again while it repopulates) [01:35] maybe there is a better way, and you're using it in the newer version of bzr-svn, and I'm just annoying you with my questions :) [01:36] moin === nenolod_ is now known as nenolod [02:28] zul: grmbl; there's a new samba 3.2.0-4 that'll need merged, brown-paper bag bug in -3 [02:29] slangasek: yep saw the commit Ill do it first thing tomorrow when I get downtown [02:29] zul: ok, cheers === philwyett_ is now known as philwyett [04:34] hi all, I am wondering if there are some helpful souls here that might mentor me in fixing a simple bug [04:35] bug 250681 is simple enough, I apt-get source irssi [04:35] Launchpad bug 250681 in irssi "first run help link outdated" [Undecided,In progress] https://launchpad.net/bugs/250681 [04:35] found the string that needs changing [04:36] changed it, but now what should I do? I think I need to make a deb diff or something right? [04:37] * Awsoonn wants to learn the ropes [04:38] when I got the source, it came with a diff.gz; do I need to apply that to the source first? So many questions for you guys === asac_ is now known as asac [04:41] Awsoonn, try #ubuntu-motu, they can point you to the right docs and info [04:41] ogra: TY [05:17] slangasek, god you were right about that debian maintainer for libsmbios [05:17] slangasek, would you mind chiming in on debian bug 491795? [05:18] superm1: hrm, I thought I was careful to say very little that I could be right about ;) [05:18] superm1: Error: Could not parse data returned by Debian bugtracker: global name 'ls' is not defined (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491795;mbox=yes) [05:18] slangasek, well just hard headed about things [05:19] along the lines of "its not broke yet in debian because we havent switched to a newer libtool, and this is the way it should be done" [05:31] superm1: I think I'm lacking the necessary patience to deal with that tonight; maybe tomorrow... === beuno_ is now known as beuno === beuno_ is now known as beuno [06:45] slangasek: re bug 196850: It certainly should be fix released. Thanks for the pointer. [06:45] Launchpad bug 196850 in virt-manager "vm cannot access cd-rom unless run as root" [Medium,Fix committed] https://launchpad.net/bugs/196850 [07:15] Good morning [07:16] slangasek: I thought if the fix was available for hardy, it could be uploaded to intrepid, too; nothing particular beyond that [07:17] pitti: Mind casting your eye over https://bugs.edge.launchpad.net/ubuntu/+source/policykit/+bug/250619 ? [07:17] Launchpad bug 250619 in policykit "[intrepid] policykit pulls in policykit-gnome due to Recommends" [Undecided,In progress] === tkamppeter_ is now known as tkamppeter [07:20] StevenK: I totally agree to that [07:22] StevenK: please upload if you want, otherwise I'll do it later (I have to leave for a bit) [07:22] pitti: Happy to upload the patch, just wanted you to check it first. === greeneggsnospam is now known as jsgotangco [08:05] pitti: around? === halex_ is now known as halex === doko_ is now known as doko [08:56] mvo: I have added you as a Subscriber for the bug 249850 ... is that ok? :) [08:56] Launchpad bug 249850 in synaptic "Synaptic Freez up after installing Packages" [Undecided,New] https://launchpad.net/bugs/249850 [09:26] hi nxvl [09:26] where is scott when you need him ;-) [09:27] hey guys [09:27] how is life in Ubuntu land? [09:27] * pitti hugs fabbione [09:27] Padre! [09:27] * fabbione hugs pitti [09:27] hey fabbione, good! [09:27] very intrepid [09:27] seb128: hey Mr. Gnome :) [09:27] pitti: ehehe [09:29] * fabbione grrrrs at linux-libc-dev === chand_ is now known as chand [09:35] superm1: does hal need a fix in bug 189814? [09:35] Launchpad bug 189814 in libsmbios "HAL lockups/crashes on Dell D-series Latitudes w/ BIOS password" [Medium,In progress] https://launchpad.net/bugs/189814 [09:40] bryce, tjaalton: WDYT about http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=66fb253082ea42179180303393e48846208987fa ? I think that makes sense, although it was reverted again upstream [09:56] mvo: please ping me when you want to solve the problem with Update Manager and the NVIDIA drivers in Intrepid. There's a Python module ready for this. [09:59] tseliot: lets do it now, where can I see the python module? do we have a bugnumber or something as a reference? [10:00] mvo: install nvidia-common from this PPA: https://launchpad.net/~lrm-intrepid/+archive [10:00] * tseliot looks for the bugreport [10:03] mvo: maybe this one: https://bugs.edge.launchpad.net/ubuntu/+source/update-manager/+bug/249329 [10:03] Launchpad bug 249329 in update-manager "Intrepid dist-upgrade fails - 'nvidia-glx' is marked for removal but it's in the removal blacklist" [High,Triaged] [10:03] tseliot: NvidiaDetector ? [10:04] mvo: yes [10:05] mvo: it detects drivers with an old name scheme (e.g. nvidia-glx, -new, etc.), does hardware detection and returns the name of the driver to install [10:06] tseliot: ok, so the old names go away complettely? [10:06] mvo: yes, there are only nvidia-glx-177, nvidia-glx-173, nvidia-glx-96, nvidia-glx-71 [10:07] tseliot: ok, excellent [10:07] mvo: you might have to change your blacklist too [10:07] tseliot: I start with removing the old names from the removal blacklist [10:08] tseliot: is there any package level (via transitional packages or anything like this) transition going on for the hardy->intrepid upgrade? [10:08] tseliot: I'll try and adapt the jockey nvidia handler for the new packages today/tomorrow [10:09] pitti: great, let me know if you need help with Jockey [10:09] tseliot: the -modalias packages have the package names now? If so, then this should be straightforward (takes some programming, though) [10:10] mvo: no, since supported hardware has changed too much. This is why we rely on both the Debconf warning in nvidia-common and on Update Manager to select and install the right driver for the card. [10:10] pitti: yes, they do [10:13] mvo: if you read here: http://albertomilone.com/wordpress/?p=212 where it says "How does nvidia-common work?" you will see how the Debconf check will work if users decide to dist-upgrade from the command line instead of using Update Manager [10:13] tseliot: ok. when do you think will nvidia-common arrive in the archive? I need to build-dep on it than because the release-upgrader will have to ship a copy of the dection code [10:14] mvo: I don't have upload privileges. I think nvidia-common is ready though [10:14] pitti: thoughts on this? [10:15] its a new package so it has to go through pitti review anyway :) (or mathiases) [10:15] tseliot: last time I looked at it it was fairly ok (see my email response); I didn't test it personlly , though [10:15] but since this is blocking both of you now, I'll review/upload/NEW it right now [10:15] tseliot: lrm-intrepid PPA? [10:15] pitti: yes, it's there [10:16] Show files nvidia-common - 0.1-0ubuntu12 ? [10:16] tseliot: hm, I guess I can just check it out of bzr somewhere? [10:17] pitti: you can get the latest (ubuntu12). I haven't set up a bzr branch yet [10:17] ok, fine [10:18] tseliot: hm, the diff.gz has patches, how weird :) [10:18] tseliot: I guess it should be pretty much a native package for now [10:18] tseliot: can I give you some review comments right here, or do you want an email? [10:18] mvo: it will be sufficient to make an object of the NvidiaDetection class without any parameter. This should return either None (if no compatible driver can be found) or the name of the appropriate package [10:19] pitti: maybe an email would be better. Thanks [10:22] tseliot: I just looked at it, does it require stuff in /usr/share/jockey/modaliases/ that is not yet in intrepid? for me that dir does not contain a lot (but my intrepid is not fully up-to-date) [10:22] mvo: if you install nvidia-common and its dependencies (which are currently in multiverse in Intrepid) then it will be ok [10:22] tseliot: basicly I need to ship those files that are required in update-manager as well, because the upgrader can not relie on stuff from intrepid package, it needs to ship the data on its own [10:23] is this the right channel to look for ubuntu packaging advice/support? [10:23] mvo: can't we ship those 3 small packages with the CD (when they are moved to main)? [10:24] jmunro, #ubuntu-moty is probably a better place [10:24] ops, motu [10:24] mvo: nvidia-{177|173|96|71}-modaliases are very small [10:24] thanks joaopinto [10:24] tseliot: when the upgrader runs, its runs on hardy (ether net or cd) - its fine to have the three files included if they are small, that is no issue. [10:25] mvo: but the modaliases will change every time the drivers are updated [10:25] slangasek: hey, could you have a look to bug #235560 and tell me if you think that's a samba issue? [10:25] Launchpad bug 235560 in nautilus "Connect to smb server by name doesn't work, but by IP address does" [Medium,New] https://launchpad.net/bugs/235560 [10:26] mvo: furthermore, as pitti said, the lists of the supported hardware may be different on 32 and 64bit [10:26] ^ I don't know whether this is actually ture [10:26] true [10:27] tseliot: oh, they are not arch=all ..... hmmm [10:27] or was just a red herring from our hackish way to extract the vendor/model lists from the X driver binaries [10:27] pitti: we can't control what NVIDIA and AMD do ;) [10:29] tseliot: could you check if the lists are the same? if they are, then I have a lot less problems, if they are not, than I need to ponder about this problem a bit more [10:29] * tseliot checks the modalias files [10:31] tseliot: thanks [10:33] mvo: for nvidia-glx-173 the files are identical [10:33] tseliot, mvo: package reviewed, I mailed you [10:33] I wouldn't like to upload it right now, but after fixing the list it should be good [10:34] should not take more than an hour to fix it up [10:34] pitti: great, I'll have a look at it as soon as it arrives [10:34] * pitti hugs tseliot for his outstanding owrk [10:34] * tseliot blushes [10:34] tseliot: I'm just a little more picky about this, since it will go into main [10:35] (well, I'd list the bugs for any universe package, too, but for NEWing I mean) [10:35] pitti: feel free to be as picky as you like with me ;) [10:35] pitti: I'll make sure the package is suitable for inclusion in main [10:38] * pitti chuckles about the new LP UI -- "bragging rights" [10:38] tseliot, pitti: will the modaliases packages move to restricted at some point (instead of multiverse)? [10:38] mvo: the modaliases are identical for 177 too. Ok, there is no difference between 64 and 32 bit in the modaliases [10:38] mvo: yes, absolutely [10:38] mvo: the drivers themselves, too [10:39] mvo: I need the modalias lists as jockey Recommends: as well [10:39] tseliot: excellent, thanks for confirming [10:42] how often will the nvidia drivers be updated after the intrepid release (in -updates)? if that is going to happen very infrequently I will just build-dep on the modaliases files in update-manager and copy them into the release-upgrader tarball. if it does happen a lot, then a more flexible aproach is needed === ln-_ is now known as ln- [10:43] mvo: updates will be done as backports from Intrepid+1 to Intrepid therefore there shouldn't be problems with Update Manager [10:44] mvo: we won't do SRUs as we're doing for Hardy in multiverse [10:44] tseliot: ok, I go with the build-dep approach then [10:44] mvo: ok [10:46] tseliot: oh, we won't? I thought we'd at least add new driver versions post-release, much similar to what the -envy packages do in hardy right now? [10:47] mvo: can the upgrader download the files from somewhere else prior to starting the upgrade? doesn't it already download a blob? [10:47] pitti: with -envy there's a certain amount of risk but you still have the packages in the lrm. In intrepid we should still have something stable which doesn't change, I guess. [10:47] tseliot: I agree, but adding newer versions (e. g. as intrepid+1 -> intrepid backports) should be ok? [10:48] pitti: and maybe the backports will keep happy the ones who want the latest driver [10:48] like, nvidia-192 backported to intrepid [10:48] pitti: ah, adding a completely new package, you mean. I wouldn't know [10:49] pitti: if you think that using -updates is better, I'm with you on this [10:49] -backports or -updates doesn't matter much, as long as jockey/envy can pick it up [10:50] pitti: they don't matter much to me since I'm going to make the packages anyway ;) [10:50] pitti: sure, it could do that too, it will just add more waiting and more stress the mirrors. downloading stuff is fragile in release times, the mirrors are all very loaded. if it has no (or hardly none) disadvantages I would rather want to have it included [10:51] mvo: *nod* [10:51] I was just curious [10:55] mvo: another thing. Maybe reinstalling libgl1-mesa-glx and xserver-xorg-core (before doing the dist-upgrade) could help if users made use of the NVIDIA installer from NVIDIA's website. See this problem which I solved: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-177/+bug/250486 [10:55] Launchpad bug 250486 in nvidia-graphics-drivers-177 "package nvidia-glx-177 None [modified: /var/lib/dpkg/info/nvidia-glx-177.list] failed to install/upgrade: trying to overwrite `/usr/lib/xorg/modules/extensions/libglx.so', which is also in package xserver-xorg-core" [Undecided,Invalid] [10:56] tseliot: could you please make the nvidia-common stuff available via bzr? I would like to make some (small) modification to it to make it easier for me to embed it [10:57] mvo: sure [11:00] what is the reason that we have 4 modaliases package? would it be possible to have them in a sinle package? or have a meta-package that depends on all available ones so that in the future I don't need to manually update the build-depends on them? [11:01] tricky [11:02] mvo, tseliot: what about adding all of them to nvidia-common? [11:02] sounds good to me [11:02] that makes sense anyway, and then you can just b-dep on n-common [11:02] hm, hang on [11:02] can we b-dep on them in the first place? they'll be in restricted [11:03] main -> restricted dependencies -> evil [11:03] mvo: 4 modaliases packages are made when the 4 drivers are built [11:03] * mvo nods [11:04] pitti,mvo: I'm afraid I don't understand your suggestion [11:04] packages in main can only depend and b-dep on main packages [11:04] its not terrible important, it would just be nice. as long as someone reminds me when new modaliases packages become available to update the build-depends in update-manager [11:05] mvo: but that doesn't work either way [11:05] if we want to do that at all, then the least evil thing (IMHO) we can do is to have the -modalias packages in main and the rest in restricted [11:05] 'source in restricted' and 'one binary of it in main' is against the common practice, too, but less evil than b-depending on restricted packages [11:05] cjwatson: WDYT? [11:07] pitti: meh, right [11:08] pitti: (I'm off sick today, but happened to be looking) we already do that with linux-meta [11:09] cjwatson: the plague? [11:09] it's not without problems, but can be done with care [11:09] mvo: aye [11:09] cjwatson: get well! it hit me fully with >39°C over the weekend [11:10] I think I had the worst of it last night, but will be sleeping the rest off today [11:10] canonical has reinstated the distro plague? [11:10] cjwatson: oh, sorry for bothering; get well soon! [11:10] or rather, distro sprint plague. [11:11] anybody around having a clue about libtool who could look to the error on http://paste.ubuntu.com/29259? [11:11] it hit Pedro, then Michael, then Colin; noone else so far, AFAICS [11:12] that's gnome-system-monitor which doesn't want to build using libtool2, not sure what to change though [11:13] mvo: my bazaar branch is here. NOTE: it doesn't contain the correction which pitti suggested and the branch has not been scanned yet [11:13] seb128: it's C++ and doesn't have a AC_PROG_CXX before the libtool macros? [11:13] mvo: https://launchpad.net/nvidia-common [11:14] Mithrandir: I did add [11:14] " [11:14] AC_PROG_CXX [11:14] AC_PROG_LIBTOOL" [11:14] Mithrandir: but that makes no difference [11:14] seb128: and reran aclocal and auto*? [11:14] libtoolize -c -f && autoconf && aclocal [11:14] that's the wrong order; aclocal; automake; autoconf [11:14] s/;/:/ [11:15] is automake required there? [11:15] hm, no, it shouldn't be. [11:15] maybe just autoreconf -f? [11:15] anyway, aclocal before autoconf [11:16] it gives http://paste.ubuntu.com/29261/ now [11:17] seb128: missing AC_PROG_CC? [11:17] jcristau: is AC_PROG_CC required if I'm already using AC_PROG_CXX? [11:18] seb128: if you want to build c stuff, not just c++, i'd say yes [11:19] doesn't seem to make a difference [11:19] I hate autotools ;-) [11:22] seb128: this is libtool's way of loving you back. [11:26] tseliot: please check bzr+ssh://bazaar.launchpad.net/%7Emvo/nvidia-common/mvo/ for some smallish additions [11:27] order> use autoreconf [11:30] cjwatson: doesn't make a difference, I think the configure.in needs some other changes [11:30] where is scott? ;-) [11:31] ups, in fact no, autoreconf -v -f works [11:31] cjwatson: thanks [11:31] mvo: ok, thanks. It looks good and you also corrected a typo. [11:32] seb128: get in the queue, I mailed Scott about a new (different) libtool problem yesterday ;-) === hunger_t is now known as hunger [11:34] tseliot: how is the interface supposed to be used? I call selectDriver() to get the one that I am supposed to use? and getDriver() to see what is currently installed (and should be removed)? [11:35] tseliot: thanks for reviewing my changes [11:35] hello, I'm trying to figure out how I can make glxinfo not to display "client glx vendor string: SGI". I'm trying to benefit of Adobe Flash 9 hardware acceleration in full screen. [11:35] mvo: just create an object and see what it returns (without calling any method) [11:35] from the Adobe Flash linux team: the Flash Player requires that the client glx vendor string be something besides "SGI". Official drivers from, e.g., ATI and Nvidia hopefully do not have "SGI" in this field (check the 'glxinfo' command, for this string and for the extensions listed above) [11:35] these guys must be smoking weird stuff. [11:35] patch mesa ;) [11:36] installing propietary drivers from ati (or from the restricted drivers in xubuntu), I still get SGI [11:37] AlexCONRAD: if you file a bugreport on launchpad I'll have a look at it later [11:37] here's Adobe's blog regarding this issue: http://blogs.adobe.com/penguin.swf/2008/05/flash_uses_the_gpu.html [11:38] mvo: if doing so seems weird to you I can change it [11:40] tseliot: I would prefer something that I call from within python, maybe a @property like driverpkg or drivername ? [11:41] tseliot: it looks like "selectDriver()" does that, correct? [11:41] mvo: yes, that's what you need [11:44] tseliot: I'm doing a bug report right now. Should I provide a specific package? [11:45] AlexCONRAD: linux-restricted-modules [11:45] ok [11:45] can someone recommend a log rotation tool? like logrotate, but less broken (eg runs more then once each day) [11:47] tseliot: ok, I think then I have all the bits in place now in the code, the outstanding issue is only "main"<->"restirected" barrier [11:49] mvo: ok, I'll apply your corrections (and pitti's) and push them into my branch soon [11:49] mvo: I think I'll move the -modalias packages to main [11:50] mvo, tseliot: so I think that nvidia-common should depen: on the modalias packages, and u-m should b-dep on n-common; ok with you? [11:50] * pitti cnat tpye toady [11:50] pitti: that sounds excellent [11:50] pitti: ok [11:52] * mvo hugs pitti and tseliot [11:52] * pitti bounces [11:52] * tseliot hugs pitti and mvo [11:55] tseliot: I also need a way to figure out if a old nvidia driver was installed before the upgrade (I don't want to transition people without the binary driver to a binary driver on pgrades). I will just use the oldPackages list for this in getDrivers, does that sound reasonable? [11:57] mvo: what do you mean? If a driver with an old scheme was installed, selectDriver() will return None. Maybe I'm missing the point [11:59] tseliot: oh? maybe I haven't got the interface yet :) on upgrade from hardy->intrepid I want to know a) is a nvidia binary driver installed. if so, then I want to install a new nvidia driver with the new naming schema [12:00] tseliot: it looks like "printSelection" is doing that, correct? [12:01] it's amazing how much work you guys put into supporting those broken drivers [12:02] mvo: getDrivers() returns True if an old driver was installed [12:03] jcristau: I'm convinced that our users should have the best experience with Ubuntu even though this is not extremely easy with proprietary drivers [12:04] mvo: printSelection() is thought only to interact with bash/debconf [12:04] regarding upstart - will upstart be used more widely in intrepid? eg in mysql and other stuff in main? [12:06] jcristau: true [12:07] (by amazing i mean sad) [12:08] jcristau: why sad? oO ... lol thats good not sad [12:08] jcristau: too many people need them. :-/ [12:08] tseliot: could you please merge again from my tree? this gives me access to oldPackages and then I can check the install status in my code slightly more efficiently [12:08] Mithrandir: like me :D [12:09] Wubbbi: you're happy you need crappy non-free drivers? [12:09] Mithrandir: sometimes i wonder if the same amount of work put into improving free drivers wouldn't be a better use of everyone's time [12:09] I mean if where is a Free Nvidia driver, which can 3D like the Nvidia one, I will use the free. But now The Nvidia Driver is simpy the best ^^ [12:10] jcristau: long-term I'm fairly sure it'd be, but short term less so. [12:10] jcristau: it'd be nice if 8.10 could ship nouveau though.. [12:10] it's bloody stable for me. [12:10] would anyone have time to try out my first pre-alpha-test version of my guest session script? (http://people.ubuntu.com/~pitti/tmp/guest-session.py, run with sudo) [12:10] Mithrandir: no I'm not happy. But I need it. [12:10] mvo: sorry if it sounds noobish but having always worked by myself I don't know how to merge branches in bzr [12:11] I also hate OpenOffice, but I need it for work :( [12:11] tseliot: no problem, just run "bzr merge bzr+ssh://bazaar.launchpad.net/~mvo/nvidia-common/mvo/" [12:11] I Like Koffice or Goffice more [12:11] tseliot, mvo: s/bzr+ssh/http/ [12:12] actually, just "lp:~mvo/nvidia-common/mvo" should do [12:13] bryce, tjaalton: I heard some rumours that the X server sends out a signal of some kind once it's started up and clients can connect to it; do you know details about that? [12:14] mvo: ok, merged. pitti: yes, using http did the trick [12:14] tseliot: (explanation: bzr+ssh:// is write access, and you can't write to a branch owned by mvo) [12:15] pitti: ah, ok, it makes sense now. Thanks [12:16] you can use bzr+ssh: for read access too nowadays [12:16] cjwatson: doing so gave me this error: Permission denied (publickey). [12:16] bzr: ERROR: Connection closed: please check connectivity and permissions (and try -Dhpss if further diagnosis is required) [12:16] $ bzr get bzr+ssh://bazaar.launchpad.net/~mvo/nvidia-common/mvo/ [12:16] Branched 4 revision(s). [12:16] tseliot: great, you bzr pushed as well? I will do some final testing after lunch and then I think the branch is ready [12:17] cjwatson: oh, neat [12:17] cjwatson: so I guess "lp:" is nothing more than a string subst for bzr+ssh://code.launchpad.net/ nowadays [12:17] pitti: the server looks if the sigusr1 handler is set to sig_ign when it starts. if so, it sends sigusr1 to its parent after init [12:18] mvo: pushed now [12:18] tseliot: that suggests that you don't have ssh configured to use your LP username when sshing to bazaar.launchpad.net. bzr+ssh://albertomilone@bazaar... would have done it [12:18] jcristau: nice, thanks! [12:18] tseliot: but it's easier to put this in ~/.ssh/config and then you can forget about it for ever more: [12:18] Host bazaar.launchpad.net [12:18] User albertomilone [12:19] cjwatson: thanks a lot :-) [12:20] tseliot: thanks, I have it now [12:21] pitti,mvo: I'm going to have a break for lunch now, therefore, unless you've got something urgent to tell me, I'll go now [12:25] * tseliot >> lunch [12:28] moin [12:28] tseliot: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/250792 [12:28] Launchpad bug 250792 in linux-restricted-modules "Adobe Flash hardware acceleration support (GPU)" [Undecided,New] [12:29] tseliot: could you please merge again from my branch when you come back? [12:34] * mvo -> lunch [13:49] seb128: do you have a minute to give a test to my guest session script? [13:51] pitti: yes [13:51] seb128: http://people.ubuntu.com/~pitti/tmp/guest-session.py [13:51] seb128: just running it from your normal session through sudo should work [13:52] it starts the guest session, and as soon as you leave it, it returns back to your's [13:52] it doesn't lock screen yet or anything, just barely sets it up [13:52] PolicyKit, mounting, network-manager etc. should work already [13:53] pitti: is that likely to crash my xsession? [13:53] seb128: no, your own should be fine [13:53] it's possible that the guest session crashes, though [13:53] alright, trying [13:59] re [13:59] I knew it would crash my box :-p [14:00] hum, brb [14:00] re [14:00] seb128: ugh, sorry for that; any idea when/how? [14:01] I would tend to blame VT switch [14:01] seb128: oh, compiz? [14:01] what did you see so far? it just crashed immediately? [14:02] so it loged me in the guest session after some seconds [14:02] the session is usable [14:02] switching user doesn't work though, can't find Xauthority [14:03] the sound card is not available [14:03] and it froze when I tried to log out [14:03] in the guest session? [14:04] the script outputs some debug info, but I guess you didn't see that any more [14:04] it also leaves a debug log in /tmp/guest_* [14:04] .Xauthority? weird, that file should be there; without it, you can't even start the session [14:05] seb128: does a normal gdmflexiserver work for you? [14:05] pitti: tried to use the fusa to switch to your normal user? [14:05] seb128: no, I didn't try that yet; sec, doing [14:06] pitti: "work" in which way? do you mean "does it crash your box on logout too"? [14:08] seb128: fusa doesn't work for me either, thanks for pointing out [14:09] seb128: well, yes; "work" in the sense of "starts a new session, session runs normally, and you can stop it, and switch" [14:09] mvo: merged and pushed again [14:11] pitti: let me switch IRC to my laptop [14:12] * tseliot shuts down his computer. A storm is coming [14:14] pitti: alright, the box crashes the same way when closing a gdmflexiserver session [14:15] bash question, what does the @ mean at the start of this? @if [ ! -x "$(DH_SAMEVERSIONDEPS)" ]; then chmod a+x "$(DH_SAMEVERSIONDEPS)"; fi; [14:15] Riddell: is that Make? [14:15] sounds like a make question [14:16] pitti: yes [14:16] Riddell: That's Make. "Don't echo the line before running it" [14:16] doesn't sound too important then, thanks. [14:17] seb128: I see; maybe you can try disabling compiz? [14:17] (did you get compiz in the guest?) [14:18] you think it's due to compiz? I'm not sure now but I don't think compiz works out of the first session, xorg limitation [14:19] no I didn't anyway, that's intrepid and gnome-session doesn't default to compiz [14:20] ah, ok [14:20] hm, no idea then, I'm afraid [14:21] if it happens even with gdmflexiserver, it's beyond my current knowledge :( [14:22] the syslog has a general protection error in wacom_drv.so and then the restart [14:22] and I couldn't ssh to the box after the crash either so it seems linux didn't like it [14:24] hm... current daily gives me read errors from the iso when simulating in faumachine... has anyone observed this on a real box? [14:26] I'm back [14:28] AlexCONRAD: what's the bugreport which you filed? [14:28] tseliot: let me find it again [14:28] tseliot: https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules/+bug/250792 [14:28] Launchpad bug 250792 in linux-restricted-modules "Adobe Flash hardware acceleration support (GPU)" [Undecided,New] [14:34] AlexCONRAD: ok, thanks [14:37] pitti, yes it does [14:37] both hal and libsmbios === mdomsch is now known as mdomsch_YOW [14:40] re [14:40] tseliot: I finished my changes in a bzr branch of update-manager now, please prod me when the new nvidia-common is available in the archive, I merge the changes into mainline then. thanks for your work on this! [14:40] seb128: ok, thanks for testing so far! [14:41] * pitti hugs seb128, sorry for the trouble [14:41] mvo: thanks to you ;) [14:41] mvo: I'll ping you as soon as it's done [14:42] * seb128 hugs pitti, you're welcome [14:42] pitti: I'll try on my laptop a bit later, but I'm building gtk+ now and don't want to crash the box [14:43] grr, cdbs has gained a new dependency in universe [14:43] seb128: right, by any means [14:43] Riddell: hm? it didn't change for a long time? [14:43] Depends: debhelper (>= 5.0.30), fdupes, intltool [14:43] looks fine to me... [14:44] pitti: build dependency [14:44] dvipdfmx [14:44] needed by texlive-xetex [14:45] right, that; there's a MIR for it [14:48] Mail In Rebate? [14:48] Main Inclusion Request [14:49] Monk In Rage [14:51] zul: could you merge samba 3.2.0-4 from debian ? It's an important fixe [14:51] mathiaz: you mean like https://lists.ubuntu.com/archives/intrepid-changes/2008-July/003931.html? [14:51] mathiaz, you should really subscribe to intrepid-changes [14:52] well - I'm just processing my inbox in chronological order [14:56] mathiaz: already done [14:57] zul: are you subscribed to the pkg-samba-maint mailing list ? [14:58] mathiaz: yep and slangasek told me last night as well [15:02] superm1: did you send the libsmbios patch upstream somewhere? [15:02] pitti, yeah its in upstream git already [15:02] i listed the link on the bug report [15:03] mebrown will be doing a libsmbios release in the next week to two weeks, so i'll submit the hal patch upstream once there is a new libsmbios "release" for hal to depend on [15:03] superm1: ah, great; I'm uploading it now [15:03] pitti, great thanks [15:03] you might consider if you can cross pocket copy, i've already got them built on the ppa [15:03] i wasnt sure if you could cross pocket copy to proposed from a ppa though [15:04] * pitti runs the missing update-maintainer first [15:05] superm1: I'd rather not, component handling sucks with copy-package from a PPA [15:05] pitti, ah okay [15:05] * soren kicks the useless rc.local prompt on initscripts upgrades [15:07] soren: bug 246550 [15:07] Launchpad bug 246550 in sysvinit "Prompts to merge unmodified conffile /etc/rc.local on upgrade to intrepid" [Undecided,In progress] https://launchpad.net/bugs/246550 [15:07] I know. [15:07] * soren is testing a patch for it. [15:08] Whuh.... Is apt-get not installed by debootstrap in Intrepid anymore? [15:08] that would be weird [15:08] It would, wouldn't it? [15:09] Maybe it's my mk-sbuild-chroot script that's misbehaving. :/ [15:09] soren, try to rerun /finish.sh in the schroot then perhaps [15:10] * soren can't spot apt in debootstrap's output.. [15:10] superm1: finish.sh installs additional packages /using/ apt-get :) [15:10] oh right :) [15:11] Task: minimal, minimal [15:11] Looks like fun :) [15:27] seb128: hum, that certainly could be a samba issue, but it's not one that I've encountered; that's kind of an opaque error message, in any case [15:27] Oh, apt is no longer build-essential. [15:28] Is that intentional? [15:28] seb128: any chance they're running the aborted hardy-proposed version of gvfs? [15:30] slangasek: did you read the current comment on the bug? and they could, but there is a new upstream version available in hardy-proposed for some time now so that's not really likely [15:31] grrr new libtool [15:31]