[00:07] git 4b42448a2388d40f257774fbffdccaea87bd0347 in xserver dropped it [00:07] xserver: remove RAC/resource handling code. [00:07] [00:07] This changes the ABI, but since the video ABI is at 6 already [00:07] it should be fine. [00:07] [00:08] driver changes are in the pipeline after this. [00:08] [00:08] Signed-off-by: Dave Airlie [00:09] there isn't an explanation why... maybe redhat is doing it just to make your life harder asac ;-) [00:11] bryceh: have a link to that commit? [00:11] want to check the driver changes landed afterwards [00:11] so i might figure how to port this ;) [00:11] e.g. would like to see "driver changes are in the pipeline after this." [00:13] asac, I'm just looking in the git tree on my hd, but you should be able to locate the commit via cgit.freedesktop.org [00:14] asac, http://lists.freedesktop.org/archives/xorg-announce/2009-September/001008.html [00:14] ok checking [00:14] thanks [00:14] some adjacent commti messages: [00:14] dix/resource: fix use after free in resource code with DRI [00:14] pci: add support for pci is boot vga call. [00:14] xserver: remove RAC/resource handling code. [00:14] sbus: fixup for rac removal [00:14] ddx: fix xf86Config.a generation [00:14] parser: make libxf86config_internal.la not installed. [00:16] asac, http://lists.freedesktop.org/archives/xorg-devel/2009-July/001527.html [00:18] asac, rationale appears that the pci rework stuff had broken this anyway a few releases back, and since there were no complaints about that they decided to remove the code entirely [00:21] http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=21a621c297ac71c65c239ea960c38706e718b91c [00:21] one example ;) [00:21] that doesnt do much ;) [00:21] +#ifndef XSERVER_LIBPCIACCESS [00:21] * asac needs to find some driver that made more extensive ues of it [00:22] what version are we at? [00:24] ok i think i got the idea === robbiew is now known as robbiew_ [00:30] bryceh: is there a good template package to use to package up a driver? [00:30] video [00:33] asac, I usually start from the -intel driver. It tends to be the best maintained [00:34] it's got a lot of extraneous stuff that might not be necessary for an arbitrary driver [00:34] the -vesa driver is useful for comparison there, as it is more minimalist [00:37] kk [00:37] will check those out [00:37] just want to ensure stuff gets installed in right place for now ;) [00:37] and then pray :-P [00:37] * bryceh nods [00:44] Hi. Where do I register my vote for PLEASE PLEASE PUT THE WINDOW BUTTONS BACK ? Thanks :-) [00:45] gconf-schema ? :P [00:45] maxb, not here [00:46] Well yes, I realise moaning about it on IRC is unproductive, but this seems about the right place to know where, if anywhere, a useful tally is being kept [00:49] maxb, this channel is for the developers who are putting together the distro [00:49] try #ayatana maybe [00:49] ok [00:50] maxb, you are welcome to hang out here, but we just trust the design team to do their job, and we do ours ;) [04:15] RAOF, the libu1 mono bindings are staying in universe for now [04:15] but he plans to finish the banshee store plugin for lucid [04:15] kenvandine: Sweet. Given banshee itself is in universe, I wouldn't expect anything more. [04:17] he tested the bindings by writing a store in 10 lines of C# :) [04:19] Hurray for good bindings and powerful languages :) [04:20] I wonder if I should spend a week doing development on this netbook. I'd be much, much more likely to care about performance. [06:20] Good morning [06:23] didrocks: you rock! http://people.canonical.com/~scott/daily-bootcharts/20100310-max-netbook.png [06:23] didrocks: the bg cache finally works \o/ [06:28] you cats gonna make your 10s goal? === Amaranth_ is now known as Amaranth [07:04] desrt: getting there [07:04] pretty sweet [07:04] 15s is already a very huge improvement [07:04] won't go unnoticed by the press :p [07:05] desrt: regular desktop is at 16.5, mostly because of compiz [07:05] desrt: if you enable metacity, it's probably more like 14 [07:05] either way, a marked improvement from the days of 40 [07:05] desrt: but that's only on this atom processor; ogra's laptop boots in 8 :) [07:05] absolutely, yes [07:08] pretty cool stuff [07:08] btw: i hope you come to my 3 security-related sessions :) [07:08] desrt: I will! the umask thing, and such, right? [07:08] ya [07:08] they just got marked for uds-m the other day [07:09] which i think is all that's needed to get into the schedule? [07:09] for now, yes [07:19] "ureadahead terminated with status 5" [07:20] that happens on the uni computers I'm working on, and it slows down the boot considerably :/ === thekorn_ is now known as thekorn [07:32] well, running fsck every time probably kills it.. [07:32] happens on my laptop as well [07:36] or does ureadahead rely on having /var on the same fs as root? [07:38] good morning [07:38] * didrocks hugs pitti [07:38] bonjour didrocks [08:50] good morning there [08:50] * seb128 wonders what this guy is doing tagging and untagging tons of bugs [08:52] good morning seb128 [08:52] seb128: I'm working on file-roller and gnome-screensaver [08:52] didrocks, ok thanks [08:53] I'm trying to not touch packages out of the pitivi update I did this morning [08:53] ok :) [08:53] I need to review and milestone bugs [08:53] so we know what to work on next [08:53] seb128: good luck on triaging those :) [08:53] thanks [08:54] bonjour seb128 [08:54] hey pitti [08:54] seb128: looks like a buggy auto-triaging script from the kernel team [08:54] how are you today? [08:55] I'm great, thanks! [08:55] pitti, yeah, that was my though too now after reading some of those ;-) [08:55] a little stressed, since there's still so much to do for beta-1, but that's fairly normal [08:55] I feel less stressed this week [08:55] now that dx delivered features on time and the artwork landed [08:56] but still pretty busy indeed ;-) [08:56] pitti, can we chat for a few seconds about gdmsetup and login sound? [08:56] pitti, our issue there is to set settings for an another user [08:57] pitti, do you think it would be acceptable to have a small binary setuid gdm write this only gconf key installed? [08:57] pitti, then we wouldn't have to deal with priviledges changes in gdmsetup [08:57] seb128: why couldn't this be set through d-bus by the gdm-binary server, like all the other settings? [08:57] because it's not a server setting [08:58] gdm.conf is written by the server and in etc [08:58] but greeters settings are gdm's gconf database [08:58] the greeter is a graphical ui running as gdm user [08:58] right [08:59] seb128: but gdm still has a session dbus running, etc. [08:59] so couldn't the server just do the gconf call as "gdm"? [08:59] seb128: with a suid gdm binary, everyone could change server settings without any authentication [09:00] hum, maybe for the server writting in gconf [09:00] > everyone could change server settings without any authentication [09:00] no [09:00] the binary would only be writting this 1 gconf key [09:00] and server settings are not in gconf [09:00] they are in gdm.conf in etc [09:00] the only settings in gconf are the gui ones [09:00] ie theme, sound effects [09:01] nothing concerning security or the server [09:01] seb128: so you think it wouldn't be feasible to call gconftool (perhaps with --direct) from gdm-binary for that? [09:01] we really have 2 different components there [09:01] pitti, I didn't think about that before, but it should [09:02] pitti, I bounced you an email from robert_ancell [09:02] seb128: obviously we should avoid linking gdm-binary against libgconf, but a mere g_spawn_async seems rather harmless? [09:03] pitti, we were discussing about that small hackish way [09:03] * pitti reads [09:03] but we though about putting it in a small wrapper [09:03] not in gdm server itself [09:04] but I don't see any reason why it could be done in the server [09:04] setuid for scripts doesn't work, right (by their nature) [09:05] seb128: with that, the gdm-binary d-bus interface could just grow a new SetGconfOption() method, then we can reuse that for other settings in the future? [09:05] well I really wanted to do that in an elegant way [09:06] rather than calling g_spaw sudo -u gconftool [09:06] but right [09:06] seteuid(gdm); g_spawn_async(); seteuid(0), but yes [09:06] seb128: another alternative: just add LoginSound to custom.conf, and if it's not there, use gconf? would that work? [09:07] I'm not sure whether the simple-greeter reads custom.conf [09:07] or just the gdm-binary [09:07] I don't think the greater does no [09:07] ok [09:07] thanks for the suggestion [09:07] I will have a look to add the method in the server rather than a wrapper [09:08] seb128: could the server just write the updated gconf file directly? [09:08] we already ship gconf xml files in packages, after all (which isn't any better architecture wise) [09:08] would be a bit tricky to get right [09:08] /var/lib/gdm/.gconf.defaults/%gconf-tree.xml [09:08] the config can contain any tweak [09:09] we have to detect if this key is already set [09:09] yes, true [09:09] and change the right part of the xml [09:09] gconftool --direct sounds like the least evil method to me so far, I think [09:11] pitti, well, we write to an user config, not to the system one, I'm not even sure we need --direct [09:11] seb128: usually there's no gconfd running for gdm [09:11] seb128: I guess it wouldn't terribly hurt to launch one (dbus-daemon is running, after all) [09:12] seb128: --direct would break if you have a running session (with gdmsetup) and a running greeter in another X, of course [09:13] I hate the current gdm gconf use [09:13] it's se annoying [09:14] we also have a bug about user changes being overwritten on upgrade [09:14] ah, because we ship the verbatim .xml file, indeed [09:15] seb128: that's actually an issue -- it would revert the gdmsetup login sound change as well [09:15] but we use a different directory [09:15] so perhaps we do need a new gconf search path after all [09:15] oh, we do? [09:15] /var/lib/gdm/.gconf.defaults [09:15] we write there [09:15] not in .gconf [09:16] and we have a /var/lib/gdm/.gconf.path [09:16] "# distribution default values [09:16] xml:readwrite:$(HOME)/.gconf.defaults [09:16] " [09:16] I bet it needs to be readonly [09:16] ah, good [09:16] I will check on that [09:16] the readwrite might make user wants to land there too [09:16] rather than in .gconf [09:16] yes, rw sounds dangerous for files shipped in .debs [09:17] wants -> changes [09:19] aloha [09:20] hey czajkowski [09:20] good morning everyone [09:21] hey chrisccoulson! [09:21] how are you? [09:21] seb128 - yeah, good thanks. how are you? [09:21] seb128: do you sleep or what timezone are you in! [09:22] czajkowski, I do sleep and I'm in Europe [09:22] chrisccoulson, good, thanks! [09:22] czajkowski, I don't sleep enough some days though ;-) [09:22] hey chrisccoulson, czajkowski [09:22] hey didrocks [09:22] seb128: oh I'm the same! [09:22] didrocks: morning [09:23] today I'm on implementation and someone has added new code to the system and broken a lot of stuff on me >:( [09:23] chrisccoulson, I still get g-s-d crashing on boot :-( [09:24] chrisccoulson, it's a different bug than the libgnomekbd one [09:24] seb128 - oh, that's not good. only with the keyboard indicator? [09:24] the crash I get seems similar to bug #522639 [09:24] Launchpad bug 522639 in gnome-desktop "gnome-settings-daemon crashed with SIGSEGV in gnome_bg_draw()" [Medium,Triaged] https://launchpad.net/bugs/522639 [09:25] oh, you're not using nautilus to draw the desktop? [09:25] I do I think [09:25] at least it's running and I get the nautilus context menu and icons there [09:26] that's strange :-/ [09:26] #2 0x00f8d515 in draw_color_area (bg=, dest=0x658, [09:26] rect=0x2d1) at gnome-bg.c:759 [09:26] No locals. [09:26] #3 0x00f91044 in draw_color_each_monitor (bg=0x821e800, dest=0x81b8b98, [09:27] ...... [09:27] #6 0x07af2209 in ?? () [09:27] from /usr/lib/gnome-settings-daemon-2.0/libbackground.so [09:27] indeed [09:27] could it be a race on autologin? [09:27] hey chrisccoulson [09:27] hey pitti [09:27] it sucks that g-s-d crash on any of its .so crash [09:27] seb128 - yeah, possibly. i don't normally use autologin. that might be why i've not seen it [09:27] it means it's not very robust with bugs in random libs [09:28] like libgnomekbd [09:28] or libxklavier [09:28] or whatever you don't always care about but takes themes, etc down [09:28] yeah, it's a bit of a pain sometimes [09:28] pitti, oh, thanks for fixing that glib unit bug [09:29] chrisccoulson: IIRC, the check of nautilus is done at the beginning of gnome_bg_draw() function in g-s-d plugin. Weird that it continues… [09:30] (draw_background() function in g-s-d) [09:31] yeah, i'm a bit confused by that [09:37] pitti - do you know how gnome-power-manager is meant to deal with brightness keys that control the brightness in hardware? [09:37] i notice that my brightness keys change the brightness in multiple steps [09:37] chrisccoulson: it should just read the current brightness and do the notification bubble, but not actually change the brightness [09:37] and if i stop gnome-power-manager, i can still control the brightness, but just in lesser increments [09:38] ah, it's actually changing the brightness here too [09:38] i wasn't sure how that was all meant to work though, but it sounds like gnome-power-manager is doing the wrong thing then [09:39] chrisccoulson: is your's using hal? [09:39] pitti - no, mines using xrandr [09:40] chrisccoulson: hm, I don't actually know whether there's a brightness_in_hardware counterpart for this [09:41] ah, ok. so that could be a limitation of the xrandr interface then [09:41] chrisccoulson: it might be related to /sys/module/video/parameters/brightness_switch_enabled [09:42] but I'm not sure whether that's actually relevant for xrandr [09:42] ah, if i set that to "N", then it stops the hardware control [09:42] only a small subset of hardware supports doing brightness via xrandr at the moment afaik [09:43] and gnome-power-manager is doing small increments now [09:43] if that's the file which indicates that, then perhaps g-p-m should check that one [09:43] bryceh: right [09:43] yeah, i'll chat with hughsie and see what he thinks too [10:14] what does rhythmbox build-depend on xulrunner-dev for? [10:14] there doesn't seem to be any binary dependencies [10:19] chrisccoulson: perhaps in the past one of the music stores used that to display web sites? [10:19] pitti - yeah, i'm not sure. i'm trying a build now without the dependency [10:19] i can't see any check for it in configure.ac either [10:20] so, that might be an easy transition ;) [10:23] chrisccoulson, pitti: mind talking about services-admin once again? ;-) [10:29] milanbv, i might struggle to find the time to talk about it this morning ;) [10:29] chrisccoulson: depends on what you plan to do [10:30] chrisccoulson, pitti: rhythmbox, it is,was for the some firefox plugins for i [10:30] if you just want to reenable services-admin, it should take only a few minutes [10:30] no need to make a release specially for that [10:31] else it might be worth discussing longer :-) [10:32] milanbv: what do you currently do with init.d scripts? what with upstart scripts? [10:32] and how do we make sure that the user can't disable vital system services? [10:32] pitti: we support init.d scripts just as before, and ignore upstart jobs [10:32] seb128 - librhythmbox-itms-detection-plugin.so? [10:32] chrisccoulson, I guess so [10:32] the only change is that we hide dummy init.d scripts that link to upstart jobs [10:33] milanbv: does that filter out init.d scripts which symlinks ot /lib/init/upstart-job? [10:33] and we hide vital services using a list that I've just updated [10:33] ah, good [10:33] pitti: yes [10:34] chrisccoulson, it seems to not be required for a while though [10:34] chrisccoulson, it's probably a leftover [10:34] chrisccoulson, reading git log [10:34] seb128 - it's still being built [10:34] well but it doesn't require xul apparently [10:35] yeah, that makes sense. it built fine without it anyway ;) [10:35] the build-depends is a leftover [10:35] cool, i will remove that then [10:35] thanks [10:35] brb [10:37] re [10:37] rodrigo__, tomboy 1.1.4 is in lucid already since yesterday [10:38] chrisccoulson, let me know if you need sponsoring for something btw [10:38] chrisccoulson, you should really apply for main uploads ;-) [10:38] seb128 - thanks [10:38] yeah, i will apply soon :) [10:39] seb128, ah, cool! === rodrigo__ is now known as rodrigo_ [11:02] mvo on vacation? [11:02] hmm [11:04] hi seb128, I've noticed that the Evolution desktop entry does not load translations, even if they are present in the .mo files and the X-Ubuntu-Gettext-Domain field is correct on the .desktop file. Any idea what this could be? [11:04] Also, I notice on http://pastebin.ubuntu.com/392424/ that there are now [Compose Shortcut Group] and [Contacts Shortcut Group] sections with Name fields. It's the 10_desktop_shortcuts.patch. Can these be made translatable? [11:05] dpm, what entry? [11:05] the indicator one or the menu one? [11:05] dunno about 10_desktop_shortcuts.patch check with kenvandine and ted [11:07] seb128, the menu one. ok, for the rest I'll check with them [11:07] dpm, is the title translation in your langpack? [11:08] yes [11:08] the domain is correct in the .desktop file, and the translations are in the .mo file [11:09] I've just noticed this recently, it used to be translated some days ago [11:09] is it correct in /usr/share/applications/desktop*cache? [11:09] let me check... [11:10] I guess it's again a gnome-menus cache issue [11:10] it might not like the recent dx addtions to the desktop entry [11:11] in /usr/share/applications/desktop*cache the entry is in English [11:11] can you open a bug on gnome-menus? [11:11] sure [11:12] dpm: assign it to me, please [11:12] ok, thanks seb128 and pitti :) [11:21] ok, it's bug 535650 [11:21] Launchpad bug 535650 in gnome-menus "Evolution desktop entry does not load translations" [Undecided,New] https://launchpad.net/bugs/535650 [11:21] dpm, pitti: it's probably a desktop-file-utils issue rather [11:21] * pitti -> lunch [11:21] pitti, enjoy [11:22] dpm, thanks [11:22] no worries, I'll open a new task, then [11:22] dpm, don't [11:23] dpm, one task is enough, pitti will reassign if required [11:23] ah, oops [11:23] dpm, when the task is wrong the way is to change it, not to add a new one [11:23] dpm, otherwise you keep mail spamming people subscribing the the wrong task which is still there [11:23] I see, sorry about that. [11:23] np [11:23] it's only a detail [11:23] let the bug as it is now [11:24] we will pick it from there [11:24] thanks seb128, it's good to know that for the future [11:44] pitti: do you know why the keyboard layout goes back to en-us when I vt switch? [11:44] tseliot, is that a new issue? [11:44] seb128: no, I don't think so. It's been there for a while [11:44] ok good === pedro__ is now known as pedro_ [11:45] just checking is what not due to the patch I uploaded yesterday [11:45] no, definitely it wasn't caused by anything uploaded today [11:46] ok thanks [11:46] * seb128 lunch [11:49] seb128: whats the status of the last upload gnome batch? [11:49] something is out of sync for ur for > 24h ;) [11:49] wonder if you had some build failures or something in your inbox [11:50] ok ogra said it should be fine in 1h [11:50] ;) [11:51] it built [11:51] its just the publisher being behind on arch: any [12:04] asac, we are pretty much done with updates [12:04] asac, well there is still a new gtk coming today most likely though [12:05] ok [12:05] can you upload that EOD= [12:06] ? [12:06] ogra needs to fix somthing he can only test ;) [12:06] with consistent archive [12:07] asac, ok [12:07] I will upload tomorrow rather if you want [12:07] we are not in an hurry [12:07] let me know when you are done with your testing [12:07] seb128: its better to have it built over night than over da [12:07] seb128, well, i only need the ubuntu-netbook task installable to debug an apt hang [12:07] y [12:08] so tonight would be great ;) [12:08] yeah, EOD would help [12:08] ok, works for me [12:08] i wont work tonight :) [12:08] cool ;) === MacSlow is now known as MacSlow|lunch [12:34] right, me -> lunch [12:37] pitti - you didn't update bzr when you uploaded gnome-python-extras ;) [12:41] chrisccoulson: is there a bzr? [12:41] oh, argh [12:42] there is [12:42] chrisccoulson: I'll fix it, sorry [12:42] pitti - no worries, i'm fixing it now [12:42] chrisccoulson: ok, thanks [12:42] i'd already pushed some new changes, and tried to upload [12:42] and i got a rejection ;) [12:42] tseliot: oh, it does? in X you mean? [12:42] tseliot: or on the VTs? [12:43] pitti: using the VTs [12:43] it works well in X [12:44] Ctrl+Alt+F1 gets me to tty1 with a US layout [12:44] * tseliot -> lunch [12:45] tseliot: that sounds related to the plymouth code which replaced loadkeys.sh [12:46] tseliot: do you get it when you purge plymouth? === pts is now known as pths [12:54] WOW , first time _ever_ i'v seen seb128 comment on a blog :) [12:55] or maybe its because i dont read blog comments often ;p [12:58] vish, it's because I've been asked to put my comment there :p [12:58] hehe ;) === MacSlow|lunch is now known as MacSlow [13:06] What was the technical decision to stick with the old xf86-video-intel driver in a LTS? [13:07] vs the one where they've fixed a lot of bugs and done a lot of work on which was recently released? Lack of testing bandwidth? [13:07] SEJeff_work: is there a newer version than 2.9.1? [13:08] Yes, 2.10 [13:09] 2.10 removes userspace modesetting and the giant bunch of code that goes with it. [13:09] SEJeff_work: ah, bryceh just reenabled UMS in the last upload, since apparently KMS still causes problems in some setups [13:10] pitti, But that means we get the driver from last September which is 6 months old already. Thats a decade in oss development :/ [13:11] I don't know more about the plans, sorry [13:11] thanks [13:11] SEJeff_work: tjaalton and bryceh might have an opinion/existing plan, though [13:13] SEJeff_work: https://lists.ubuntu.com/archives/ubuntu-x/2010-March/000822.html [13:14] tjaalton, Right, but it seems like you'll be rebasing any fixes. Not so great from a LTS perspective even with 25 kernel devs on the 2 kernel teams: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=8ae0e44e42db645abe6d385f561260d2ae4a1960 [13:14] thanks tjaalton [13:15] most of the fixes will be to the drm code anyway [13:15] Hopefully so. Lucid is looking great so far [13:18] seb128: should I tag somehow bugs related to the change of tooltip background in new theme? [13:18] kklimonda, no, is there that many of those? [13:18] kklimonda, I only know about vino and rhythmbox so far [13:19]