[00:03] kwwii: bug 286677, FYI [00:03] Launchpad bug 286677 in human-theme "[regression 0.28.3] /usr/share/themes/Human/gtk-2.0/gtkrc:273: Unable to locate image file in pixmap_path: "panel_bg.png"" [Medium,New] https://launchpad.net/bugs/286677 [00:04] (might not be as high as Medium, I don't know if it has other consequences) [00:06] cjwatson: dooh, another stupid mistake [00:07] cjwatson: easy to fix, silly to make, I made the source package from the wrong dir [00:07] cjwatson: fixed first thing tomorrow [00:07] and I am kicking myself in the butt for not noticing [00:07] kwwii: thanks [00:08] kwwii: might not make RC at this point, what's the consequence of that? [00:08] we could probably slip it into final if the change is really easily reviewable [00:08] cjwatson: if it causes a noticeable error somewhere it is worth fixing [00:08] oh, I agree [00:09] and the fix is really easy, just remove the crap I added trying to work around the panel background stuff [00:09] I was just wondering if it would cause the desktop to visibly explode or anything [00:09] I know exactly what I did, I just made the source package from the wrong dir [00:09] really, really dumb on my part [00:09] mkdir empty && cd empty && dh_make? ;-) [00:10] anyway, bed [00:10] superm1: ~/WHAT? [00:10] cjwatson: well, I did change things after that change...more like re-applying the changes I added today to the bzr repo and making new source packages [00:11] this really makes me sorry for the work pitti did including it...he trusted me (I did not notice any problems but my system is so messed up in the meantime I doubt it notices anything) [00:11] I hope he is has as much patience as I do time to make mistakes [00:12] cjwatson: thanks very much for noticing this and bringing it to my attention [00:12] I will fix it asap [00:20] cjwatson: here is a new source package which fixes my (stupid) mistake: [00:20] http://sinecera.de/human-theme_0.28.4_source.changes [00:22] kwwii: A debdiff with the changes would help a lot [00:24] StevenK: the only difference is that I removed one definition of the panel bg (which I also forgot to add to bzr and therefor the problem) [00:25] I can recreate the old stuff (already changed it locally and added it to bzr) [00:25] if it is really important [00:26] I'll take care of this first thing tomorrow [00:26] in fact, I noticed I made the same mistake twcie [00:26] twice [00:27] ignore that url, I will fix it tomorrow and include a debdiff [00:27] sorry for the wasted time [00:31] lamont, ah sorry :) ~/.asoundrc [00:31] ta [00:32] slangasek, i'm not convinced debian/shlibs.local will resolve this, as indicated by: http://paste.ubuntu.com/60304/plain/ [00:33] ah, superm1 [00:34] ugh [00:34] * NCommander twichs [00:35] * NCommander checks the libstdc++ source package [00:35] well it provides the appropriate shlibs [00:35] but it's in universe and wont be available at package build time [00:35] so debian/shlibs.local was hopefully going to work around as necessary [00:36] superm1, why do you need such an old libstdc++ ? [00:37] i dont, but AMD seems to think their library does [00:37] gotta work around their mess unfortunately [00:37] Is this a multiverse package we're talking about? [00:37] it's multiverse, but should be in restricted [00:37] I assume no source [00:37] once this is sorted out, the source package will be restricted [00:37] and the binary will be multiverse [00:38] yeah no source :( [00:38] (why is it in multiverse?) [00:38] Argh [00:38] What is it specifically? [00:38] graphics driver and some acceleration libraries [00:38] Oh [00:38] More ick [00:38] the driver will be in restricted, the libraries in multiverse [00:39] If its just premade binaries, why does it need to build depend, you can explicately set the depends if shlibs can't find it for some reason [00:39] or is it half source available, half no-source? [00:40] StevenK: the debdiff does not offer anything..the only change is two lines in two gtkrc's [00:40] ^- superm1 [00:41] NCommander, well it doesn't need build depends, but the shlibs should be checked dynamically because they can change release to release [00:41] NCommander, (and actually have in the past) [00:41] but i'm not sure why shlibs.local isn't overriding like it should be in this case [00:42] Simply build-dep on the non-dev package [00:42] That will get the .shlib file installed from libstdc++3, but prevent gcc 3.3 from being pulled in [00:43] Its probably the sanest solution of the bunch [00:43] NCommander, well the problem is that all of gcc-3.3 is in universe [00:44] OH! [00:44] The restricted package is the one tha thas the issue [00:44] The only sane thing you can do is to promote libstdc++3 by itself. If the driver depends on it, I don't think you can work around that [00:45] well the idea was that the "source" package would live in restricted, and its binary graphics driver would too. this library would be in multiverse and thus allowing libstdc++5 to be in universe still [00:46] StevenK, cjwatson: debdiff is apparently supposed to be run on the dsc files? I tried it with the debs but that spits out nothing [00:46] superm1, *twich* [00:48] NCommander, yeah. but this shlib-deps problem aside, it'd be a "functional" solution [00:48] StevenK, cjwatson: whereas the debdiff for the dsc files is this: http://sinecera.de/human_theme.debdiff [00:48] which shows the necessary changes [00:48] superm1: tjaalton reviewed it; I think it needs tested/validated first to make sure it does indeed fix the issue [00:48] Can a package from main/restricted create binaries in universe/multiverse? [00:48] superm1, thats against Debian policy for instance ... [00:48] superm1: if you could test it and report that it does solve the issue, that would help [00:49] (well, main/non-free, you can do main/contrib) [00:49] bryce, would you mind pushing it to a PPA? [00:49] superm1: there was a small alteration timo suggested, to make it only pick -vesa on non-ppc, etc. that should be easy enough to add [00:49] NCommander, well slangasek said that would be okay to do. [00:50] NCommander, and actually i know of a package i already touch that does something like that [00:50] NCommander, the lirc source package is in main, and has a library in main. it has a few binary packages in universe however [00:50] point taken [00:51] NCommander: If any binary is in Main, the source needs to be in Main, but unneeded binaries can and should be in Universe. [00:51] NCommander, so these points aside, that error i posted, do you see anything blatant that stands out about what's wrong with that method of working around this? [00:51] NCommander: See the Sendmail package for an example. [00:51] superm1, give me a minute [00:52] I normall have issues groking shlibs files in general [00:52] * NCommander whacks superm1 [00:52] wait [00:52] * NCommander unwhacks [00:56] StevenK: is that debdiff good enough? (/me is just learning deb packaging, it is an honest question) [01:04] NCommander, so perplexing eh? [01:05] superm1, what happens when you add -v to dpkg-shlibsdeps? [01:05] http://paste.ubuntu.com/60316/ [01:05] Uh [01:06] * NCommander figured it out and promptly smacks superm1 [01:06] shlibs.local requires the library to be installed [01:06] gah. [01:06] It won't work if libstdc++5 isn't installed [01:06] well that's counterproductive then [01:07] shlibs.local is designed to solve a very specific problem :-) [01:07] NCommander, okay well then I think the only solution is to hardcode the shlib dependencies, and -xlibAMD when running dpkg-shlibdeps [01:07] agreed? [01:45] superm1: -Ldebian/shlibs.local should be unnecessary and may be confusing it [01:46] slangasek, i added that because it wasn't working [01:46] slangasek, but it's the same behavior without it there [01:47] superm1: hmm. ok, then it's failing because it wants to find the library first before honoring the shlibs; grr, I don't think it did that before buxy rewrote it [01:47] slangasek, well in any case, this library only has two shlibdeps anyhow, libc6 and libstdc++5. will just have to watch in the future if that changes [01:48] ok [01:48] i caught another problem with ia32-libs similar by messing with this though, so it was a good exercise [01:48] i'll push it up [01:48] sounds good [01:48] anyone know why the manpages-posix-dev package is in multiverse? <- cjwatson ? [01:50] kirkland: it's in non-free in Debian and probably wasn't revisited? [01:50] slangasek: yeah, hasn't been touched in ~3 years [01:51] okay, it's not hurting anything ... just dealing with some wonkiness for the manpage repository [02:56] lool: Did you see there's a gedit-plugins upload pending? Is it one we want? [04:32] If I want to send a patch of GNU screen to Ubuntu official package, what should I do? (just porting new function from FreeBSD) [04:42] rascov, https://wiki.ubuntu.com/Bugs/HowToFix might be a good place to start. [04:44] rascov: also, #ubuntu-motu (cfr topic) ;) [04:45] persia Chipzz: thanks :) [04:48] rascov: though the changelog mentions CVS head was merged at Jun 02, 2008 [04:49] dunnow how recent that new function is [04:52] In Ubuntu, is there a person like port maintainer or commiter in FreeBSD ? [04:55] rascov: In Ubuntu it's mostly done on a team basis rather than specific people for specific packages. [04:59] Should I contact the team if I wish to add a new function ? [04:59] rascov: Generally the best thing is to file a bug against the package with your patch. [05:03] Hey, has nvidia-glx-96 been updated to actually work with Xserver 1.5? [05:05] It seems jockey is recommending nvidia-glx-96 to someone, and I thought we'd stopped doing that on the basis that it won't work. [05:09] ScottK: I see, thanks [05:15] superm1, bryce: also, the patch should be verified to not force vesa when not using an xorg.conf [05:15] In fact, why are the nvidia-glx-{96,78} in the archives at all? [05:16] Are we hoping nvidia will release a drivers that support 7.4 and we can push them in? [05:18] "they are working on it" [05:18] or something like that [05:19] correct quote would be; aaronp: "I'm working on it" [05:19] but who knows when that happens [05:21] Indeed. What do we _do_ about this? [05:22] * tjaalton twiddles thumbs [05:22] There are currently two large packages in the archives which do nothing but break 3d. [05:22] I think they are waiting there for an SRU [05:25] RAOF: xserver-xorg-video-radeonhd isn't one of those packages is it? [05:26] just like fglrx was going to wait for an SRU if it ever came [05:26] ScottK: No; that can only break 3d for people with ATI cards; nvidia-glx breaks it for _everyone_ :P [05:26] Ah. [05:27] And that driver also has the advantage of a possibility of working. [05:27] Because there was a user, who I generally consider reliable, who reported 1.2.3 working with 3D [05:28] I don't know if our mesa is new enough for that, but I believe the very latest radeonhd _ [05:28] + mesa + drm _does_ do 3d. [05:41] radeon/radeonhd for r5xx has had 3d since mesa-7.1, and we have 7.2 [05:49] good morning [05:52] tjaalton: Really? Cool. You learn something new everyday :) [05:53] And forget it just as quickly, sadly. [05:58] doko: do you haven an idea about this: [05:58] Setting up five-a-day (0.58~hardy1) ... [05:58] pycentral: pycentral pkginstall: not overwriting local files [05:58] pycentral pkginstall: not overwriting local files [06:25] dholbach: "not overwriting local files" is a hint [06:28] StevenK: maco was having these problems in #ubuntu-bugs [06:28] five-a-day is trying to install files that already exist [06:30] StevenK: it was an upgrade :) [06:31] Hum [06:51] Argh, libcamel in NBS again? [07:20] kees: ping? [07:22] StevenK: upload the reverse-deps and we can make it go away? :) [07:24] kees: please let me know (via email.. i guess you are deeply asleep) if you need patches for CVE-2008-4192, CVE-2008-4579 and CVE-2008-4580 [07:25] kees: the fixes upstream are extremely simple but i just don't have time to look into all the packages in Ubuntu [07:28] slangasek: Plotting to === thekorn_ is now known as thekorn [07:48] Good morning [07:48] <\sh> moins pitti :) === tkamppeter_ is now known as tkamppeter [07:48] Morning pitti [07:49] morning [07:49] ScottK: I have no idea about gedit-plugins; I saw some discussion around it on #ubuntu-desktop yesterday [07:51] ScottK: http://paste.ubuntu.com/60403/ [07:51] Now you know as much as I do [07:53] pitti: Could you be tempted to approve my linux-lpia upload? :-) [07:55] kirkland: ok, I'll reply in the bug [08:01] kirkland: done [08:01] StevenK: why doesn't linux-lpia simply depend on linux-firmware instead of shipping a copy? [08:01] isn't that exactly what it does? [08:01] pitti: It does [08:02] pitti: sorry, just accepted linux-lpia-meta [08:02] StevenK: ah, then the changelog is confusing [08:02] slangasek: no problem, I was just curious about what it actually does [08:02] It meant the binary packages linux-lpia{,compat} [08:03] * StevenK looks at the NBS list for libcamel [08:03] StevenK: you mean you moved the dependency to another package? [08:03] pitti: It moved from linux-lpia to linux-image-lpia, to mirror what linux-meta does [08:04] StevenK: right, that makes sense [08:05] lool: libvisual-plugins pulls in jack, that needs to be dropped when moving it to main [08:06] if someone could sponsor an upload for bug 286829 I'd be grateful [08:06] Launchpad bug 286829 in ubuntu-docs "Please update ubuntu-docs from bzr" [High,New] https://launchpad.net/bugs/286829 [08:06] kwwii: no problem; well, I didn't upload it completely blindly, I built, installed, and restarted my session, and it still looked okay :) [08:07] kwwii: anyway, you need to tell me what this bug is actually all about; to me, it just looks like if someone used the temporarily broken package with the wrong file name "Darkroom", he'd get that on upgrade [08:07] pitti: Ok [08:07] kwwii: looking at your new package now [08:08] StevenK: libcamel NBS> eww GNOME 2.24.1 [08:08] pitti: Yes. [08:09] StevenK: libtotem-parser is part of gnome, so seb128 will do that himself [08:09] it's already done [08:09] but we should do that evolution-jescs thing [08:09] slangasek: oh, great [08:09] * StevenK removes totem from his list [08:10] My no-change rebuild of evolution-jescs builds [08:11] Just waiting for mail-notification and I can upload them [08:11] though it was done a bit later than the rest of the stuff in main, so there was an intervening CD run that's oversized because it has two copies of libcamel on it :-P [08:11] Hah [08:12] kwwii: I added (LP: #286677) to the changelog, please do in bzr, too; before I upload this, can you please explain why the bg_pixmap definition was introduced, and why removing it is the right thing? [08:13] slangasek: how tight is CD space at the moment? the recent build i did of the new version of ubuntu-docs is 1.7MB bigger than the version in the archive [08:15] slangasek: if that's a problem, we'd have to look at reducing the package [08:15] pitti, slangasek: Both my no-change rebuilds build locally, uploading them. [08:17] mdke: we have approximately zero space for new stuff - why are the docs so much bigger suddenly? === viviersf{gone} is now known as viviersf [08:17] slangasek: basically, ubuntu-docs ships translations which are 40% translated or more, that means that in the import of translations I did from Rosetta, people have made a lot of progress on translation [08:17] slangasek: we can try adjusting the figure of 40% upwards in order to reduce the package [08:18] mdke: and they're not shipped in separate binary packages? [08:18] slangasek: no, it's all in ubuntu-docs [08:18] mdke: what this comes down to is that in order to find you 1.7MB of free space on the CDs for the doc translations, I would have to drop langpacks [08:19] that doesn't sound like a winning trade to me [08:19] pitti: How can I debug why CK run in Xsession.d doesn't set DISPLAY or active? [08:19] slangasek: I guess we should try and see how big ubuntu-docs works out with shipping translations which are 50% complete, rather than 40% [08:20] reallistically, a 40% complete documentation pretty much requires the reader to understand English anyway.. [08:20] yes, I wouldn't have a problem with going up, even to 60% [08:20] I thought for that reason we set the bar to like 70% earlier? [08:20] but yeah, I'm fine with adjusting it to min(sanity,cd space) [08:21] it's always been 40% in previous releases, mainly to encourage translations, but if there is an issue with disk space, it makes sense to increase it [08:21] StevenK: is $DISPLAY actually set in 90consolekit? [08:21] slangasek: unfortunately, ubuntu-docs takes about an hour to build and I have to go to work, but I will leave it running a couple of test builds at 50, 60, and 70% [08:22] pitti: Lemme check [08:24] slangasek, pitti: I guess I'll drop the request for sponsoring until that further investigation is done [08:25] pitti: Yes, it is set [08:25] pitti: As in, stuffing a echo "$DISPLAY" > /tmp/foo in 90consolekit results in :0 [08:27] morning people [08:56] james_w: the CK fix sounds like an excellent SRU candidate [08:56] StevenK: hm; then I'm afraid this needs a gdb session [08:57] StevenK: let me try it here with the Xsession.d script [08:57] pitti: if it's not RC material then I agree. [08:57] pitti: Bug 285054 updated [08:57] Launchpad bug 285054 in Ubuntu Intrepid "Can't mount USB keys in xinit sessions" [High,Incomplete] https://launchpad.net/bugs/285054 [08:57] james_w: we could upload it right after RC, too [08:58] hey james_w pitti [08:58] * pitti hugs seb128, great GNOME marathon yesterday! [08:58] * seb128 hugs pitti, thanks [08:59] StevenK: a-haa! XDG_SESSION_COOKIE is already set [08:59] pitti: that's your call. I would appreciate review and testing, as I'm not completely confident [08:59] pitti: we still have some slots for non-CD updates today? [08:59] hey seb128 [08:59] great work on .1 :-) [08:59] seb128: -> slangasek; but since most of main is on the DVD, the answer might be "no" [08:59] ah DVD [08:59] pitti: Right [08:59] pitti: Now to figure out why it's set [09:00] yes, those big evil fat CD things [09:00] slangasek: hey [09:00] * slangasek waves [09:00] so I'm not clear what we should do from now [09:00] StevenK: how do you start X? [09:00] pitti: Via startx [09:01] StevenK: from an init script? [09:01] pitti: I'm pretty sure it's the xinit support i'm pointing at in the bug report [09:01] pitti: An upstart script [09:01] StevenK: Check out xinit from git and see whether they merged support for CK [09:01] it should be reverted from xinit, it can not work from there [09:01] StevenK: the only other thing that creates sessions I'm aware of is libpam-ck-connector [09:01] slangasek: will some updates be accepted after rc and should we work on SRUing now? [09:01] lool: yes, I agree; wasn't aware of that [09:02] but there shouldn't be a PAM session in upstart scripts or init scripts, so that wouldn't be it [09:02] I commented as such in the upstream bug, but I bet they merged the patch nevertheless [09:02] slangasek: the new pidgin (changelog on http://developer.pidgin.im/wiki/ChangeLog) for example [09:02] seb128: some will be accepted after RC, to be sure; including the bits of GNOME that haven't made it through yet [09:02] pitti: Actually we use "su" [09:02] slangasek: ok thanks [09:02] lool: ! [09:02] So there might be a pam session [09:02] lool: that uses PAM [09:02] Maybe we want to use su - -l [09:03] No [09:03] pitti: is pam-ck the default nowadays? [09:03] lool: yes [09:04] ohh [09:04] that's probably the issue then [09:04] /etc/pam.d/common-session [09:04] sessionoptionalpam_ck_connector.so nox11 [09:04] eww, seems weechat doesn't like tabs [09:04] Then we can simply clear the CK session when launching startx; env ignore or seomthing [09:05] StevenK: Try with env -u XDG_SESSION_COOKIE in the upstart job [09:05] lool: that would be a working hack, I just wonder why ck-connector should be made more clever [09:05] lool: Geh? In which bit? [09:05] pitti: Hmm what we would need is for the Xsession.d script to check whether there's a running CK session and provision the DISPLAY info in it [09:06] Instead of just considering presence/abscence of a running session [09:06] right [09:06] since we're going to start a new one for a different tty [09:06] StevenK: /etc/event.d/session; use env -u XDB... between su and startx [09:08] Hm. That didn't seem to help, and I still have XDG_SESSION_COOKIE in the env dump [09:08] * StevenK forcibly restarts the job [09:12] lool: "env -u XDG_SESSION_COOKIE; startx -- -br" doesn't look to help [09:13] StevenK: Without ; [09:14] That seems to give me a session that sets x11-display [09:14] StevenK: is it active? [09:15] Yes [09:15] * StevenK checks if he can mount a USB key [09:16] I can! \o/ [09:16] pitti: Does that hack not make you ill? [09:18] StevenK: It's not exactly aesthetically pleasing, but *shrug*, if it works :) [09:19] StevenK: my preferred solution would be to fix 90consolekit to call ck-launch-session if there's an existing cookie which does not belong to an X11 one [09:19] but mapping cookies to sessions isn't possible as normal user [09:20] so we'd need some proper support for this in CK itself [09:20] james_w: ah, that CK test case works tremendously well [09:21] pitti: Sure, so this is a last-minute OMG-it-works-ship-it hack [09:22] StevenK: absolutely fine for me [09:28] StevenK: Hmm where do you say you get this? in mid? [09:28] StevenK: it's not supposed to pull libpam-ck-connector [09:28] It's derived from minimal, not desktop-common [09:28] lool: Yes [09:28] StevenK: Is this a recent install, or an upgraded system? [09:28] lool: This is the most recent daily [09:29] I think it's worth fixing it for systems with libpam-ck-connector (like mine, I use startx!) [09:29] libpam-ck-connector is installed [09:29] StevenK: Weird, any rdeps? [09:29] Oh consolekit [09:29] Yup [09:30] We probably shouldn't fiddle with that [09:30] Well I seriously think we don't need it in mid/mobile [09:31] But that's not a fix, and it's late to drop it in this cycle anyway [09:31] StevenK, lool: FWIW, I'm fine to drop the Recommends: libpam-ck-connector from consolekit [09:31] pitti: I think it should be downgraded in next cycle [09:31] As to allow us not to pull it [09:32] lool: *-desktop pulls it in already anyway [09:32] Yup [09:32] lool: depends; if we upload james_w's patch soon, we can as well drop it [09:32] pitti: what's the patch? bug #? [09:33] lool: bug 269651 [09:33] Launchpad bug 269651 in consolekit "console-kit-daemon crashed with SIGSEGV in g_str_hash()" [High,In progress] https://launchpad.net/bugs/269651 [09:37] Nice one [09:50] pitti: Could you be convinced to accept ubuntu-mid-default-settings and contacts in unapproved? [10:06] StevenK: done [10:09] pitti: Danke [10:11] pitti: hey, I'm having second thoughts about not installing the wacom.fdi by default.. people seem to be more upset about not being able to use their stylus OOTB than making it more complicated to get the full functionality working (eraser/cursor etc). So reverting the change would fix bug 282203, ok to upload? [10:11] Launchpad bug 282203 in wacom-tools "Wacom tablet hotplug is no longer enabled by default" [Wishlist,Triaged] https://launchpad.net/bugs/282203 [10:20] StevenK: please close bug 285054 manually, it didn't have a package attached [10:20] Launchpad bug 285054 in Ubuntu Intrepid "Can't mount USB keys in xinit sessions" [High,Incomplete] https://launchpad.net/bugs/285054 [10:21] tjaalton: you can upload, but I can't accept it right now; this needs to wait until after RC [10:21] tjaalton: also, I'm not sure whther this kind of change is appropriate now; we had the current setup for quite a while, so changing it now might introduce other regressinos? [10:22] * pitti actually likes the term "regressino" as a "small regression" [10:22] pitti: it was changed since beta [10:23] pitti: also, bug 261977 is reviewed and fix committed [10:23] Launchpad bug 261977 in dell "nv is chosen even if it doesn't support the card" [Undecided,Confirmed] https://launchpad.net/bugs/261977 [10:23] but post-RC is fine [10:24] tjaalton: ok, ok; worth discussing then, can you please upload and subscribe ubuntu-release? [10:24] tjaalton: 261977> nice, thanks; will go in post-RC, too [10:25] pitti: sure, will do [10:29] pitti, abogani asked me if http://paste.ubuntu.com/60432/ would be an acceptable debian/copyright for l-r-m-rt. WOuld you accept that, or do you want something more traditional? [10:30] persia: ah, it has the madwifi license/copyright now, good; WDYM with "more traditional"? [10:31] persia: the ltmodem copyright isn't entirely clear, but then again our main l-r-m isn't either [10:31] so, good enough for me [10:31] pitti, I can't find any license reading the source for ltmodem. In good news, AnAnt is finalising a dkmx+modass compatible multiverse package to let us drop that for jaunty. [10:32] Thanks. I'll upload. For reference "more traditional" would be something following http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html [10:33] persia: ah, ok; let's not be too fussy about it [10:34] uploaded. [10:51] mvo: does the screensaver now actually work for you? I just get a black screen [10:54] pitti: it did in my tests, let me double check [10:57] pitti: what screensaver is checked in your screensaver preferences? [10:57] pitti: what card/driver? [10:57] mvo: "Weltraum" [10:57] mvo: 945GM/intel [10:58] mvo: in the screensaver prefs, the preview works fine, but ctrl+alt+l or gnome-screensaver-command -a just give me a black screen [10:58] mvo: it doesn't immediately return any more, so the "does not activate" part is indeed fixed === asac__ is now known as asac [11:15] pitti: I just tested on my nvidia system and it seems to be ok. but I'm upgrading my intel system as we speak [11:28] pitti: Sure, closing [11:30] pitti: hm, seems to work for my intel system, strange [11:30] pitti: I keep a open eye on the bugreports [11:32] mvo: ok, thanks for testing [11:35] pitti: could you please run "gnome-screensaver --debug --no-daemon" and sent me the output ? that might give me a clue [11:35] (you probably have to kill the running one fist) [11:36] mvo: http://paste.ubuntu.com/60453/ is after killing, starting in debugging, and gnome-screensaver-command -a [11:37] mvo: oh, maybe it's because my original CK session was ruined (I did some CK debugging and killed it several times) [11:38] mvo: I'll try it again with a good session in a bit [11:40] pitti: thanks! the line "[gs_job_start] gs-job.c:446 (12:35:58): No command set for job." looks a bit supicious [11:40] pitti: that looks like for some reason g-s-s thinks that it does not need to start a screensaver (or can not?) [11:45] where has the bluetooth services control gone? [11:46] the new bluetooth preferences from bluez 1.8 is missing the services tab [11:46] and there's no discoverable way to enable file transfers now [11:47] alex-weej, Which flavour? [11:47] 8.10 [11:47] alex-weej, Flavour, not release. [11:47] Ubuntu [11:47] e.g. Mythbuntu, Xubuntu [11:47] Ubuntu Original, Organic, Full Fat [11:49] alex-weej: I see that too [11:49] Oh. RIght. I suspect that's bug #283064. [11:49] Launchpad bug 283064 in gnome-bluetooth "intrepid: bluetooth can not receive files" [Undecided,New] https://launchpad.net/bugs/283064 [11:49] persia: but also things like i can't set up input devices or anything [11:50] alex-weej, That's surprising. Try clicking the bluetooth applet : it should open the device wizard. [11:51] i have already "set up" the weejPhone [11:51] so it doesn't show up in the list [11:52] setting it up again just says it was successfulyl set up [11:52] no way to configure anything [11:52] as an input device, audio device, network device [11:52] What are you trying to configure? [11:52] anything. like an input device. [11:52] Ah, it is supposed to auto-detect that from the capabilities available. If your device supports multiple capabilities, and it doesn't work, file a bug. [11:53] hm, i can start the remote control on my device and use it fine [11:54] it just seems weird that there is no way to configure any of this [11:54] it's all-or-nothing [11:56] It's supposed to just work. === LucidFox_ is now known as LucidFox [13:00] * StevenK selectively empties [13:00]