SIGs/Desktop/Meeting-20071017

Present

 * MatthiasClasen
 * DavidZeuthen
 * RayStrode
 * Will Woods
 * Colin Walters
 * Lennart Poettering
 * Adam Jackson
 * JesseKeating

Log
Oct 17 14:00:43 	ok, is it time for a desktop sig meeting ? Oct 17 14:02:10 	sorry that I didn't have time to send out an agenda Oct 17 14:04:06 	do we have things to discuss today ? Oct 17 14:05:26 	I think f8 is frozen already right? Oct 17 14:05:34 	pretty much Oct 17 14:06:34 	I didn't see an announcement yet, but the 16th was supposed to be the freeze date Oct 17 14:06:52 	so perhaps next meeting we should start talking about f9 features? Oct 17 14:07:00 	I mean, it's a bit premature perhaps to do it now Oct 17 14:07:09 *	davidz, for one, would like to prepare and think about it Oct 17 14:07:30 	no, I think it is fine Oct 17 14:07:38 	I had that on the agenda for last week, actually Oct 17 14:07:44 	but we didn't get around to it Oct 17 14:08:37 	so.. next week or this week? Oct 17 14:08:43 *	davidz a bit confused, sorry Oct 17 14:08:51 	I'm fine starting such a discussion today Oct 17 14:09:01 	given that there is no other topic right now... Oct 17 14:09:11 	so Oct 17 14:09:17 	maybe IRC isn't the best forum Oct 17 14:09:30 	maybe asking contributors on the list to send proposals to the list... would be better? Oct 17 14:09:50 	well, do we have any F8 blockers? Oct 17 14:10:07 	if so, those should still get fixed, or demoted even after today, yea? Oct 17 14:10:15 	sure Oct 17 14:10:17 *	davidz all done with f8 blockers Oct 17 14:10:40 	the freeze means that from now on, you are not supposed to build stuff unless it fixes a blocker or serious issue Oct 17 14:10:56 	and I believe rel-eng will start selectively tagging things Oct 17 14:11:02 	ie you need to ask for it to be moved Oct 17 14:11:10 	f13: is that right ? Oct 17 14:13:15 	halfline: do you want to discuss any f8 blocker bugs here, or should we start to fantasize about f9 ? Oct 17 14:15:37 	davidz: I'd hope that we have a feature proposal/brainstorming phase for f9 on the lists as soon as f8 goes out Oct 17 14:15:55 	but of course, we all have our own agendas already... Oct 17 14:17:09 	let's fantasize Oct 17 14:17:32 *	walters_ feels like he walked in on something Oct 17 14:17:35 	so one thing i did was get gdm branched early for F9 Oct 17 14:17:48 	i'd like to build development snapshots of gdm Oct 17 14:18:01 	we will need fork dbus-glib though and update it as well Oct 17 14:18:11 	since the new gdm requires a newer version of dbus-glib than we ship Oct 17 14:18:23 	davidz: is there any reason we didn't update dbus-glib in the F8 cycle? Oct 17 14:18:33 	just sheer amount of rebuilds Oct 17 14:18:34 	does it change so names? Oct 17 14:18:39 	thats what kept me from doing it after test2 Oct 17 14:19:06 	halfline: feel free to update it Oct 17 14:19:13 	halfline: unless there's .so name breakage Oct 17 14:19:18 	the we have to coordinate the transition Oct 17 14:19:27 	right Oct 17 14:19:28 	s/the/then Oct 17 14:19:35 	i wouldn't mind forking that package early Oct 17 14:19:42 	but if there are 50 packages that depend on it Oct 17 14:19:46 	i don't really want to fork all of them Oct 17 14:19:50 	when I was looking after test2, I found ~50 packages that depend on it Oct 17 14:19:57 	okay Oct 17 14:20:02 	so probably not a good idea then Oct 17 14:20:03 	well Oct 17 14:20:09 	actually maybe it doesn't matter Oct 17 14:20:16 	of course, most of them probably don't really depend on it Oct 17 14:20:29 	we won't be getting f9 composes for some time Oct 17 14:20:52 	so until we do start getting them, it doesn't really matter if the so name breaks, yea? Oct 17 14:21:23 	it won't break anyone's yum update i mean. it may break people's machines that are testing the new gdm Oct 17 14:21:34 	no, it won't break peoples machines Oct 17 14:21:45 	unless they are testing the new gdm Oct 17 14:21:52 	right Oct 17 14:22:03 	I think doing the fork is probably fine Oct 17 14:22:04 	so it might be worth doing anyway Oct 17 14:22:27 	okay i'll look into it Oct 17 14:22:41 	you can send out a heads-up to -devel list Oct 17 14:22:50 	yea sounds like a good idea Oct 17 14:23:09 	then people can fork their packages at their own speed Oct 17 14:23:14 	alternatively, i could see why the new gdm needs the new dbus-glib and patch it so that it doesn't need it Oct 17 14:23:26 	that would be an option, too Oct 17 14:23:34 	worked for packagekit Oct 17 14:23:49 	so new dbus-glib changes soname? Oct 17 14:23:52 	ah good, that might be the nicer option Oct 17 14:23:53 	is that a fact? Oct 17 14:23:58 	i don't think we know Oct 17 14:24:02 	know one's checked. Oct 17 14:24:04 	it's your package :-) Oct 17 14:24:13 	s/know/no/ Oct 17 14:24:15 	well Oct 17 14:24:19 	if there's no soname changes Oct 17 14:24:22 	then ... Oct 17 14:24:25 	we just update it Oct 17 14:24:38 	you mean for f8? Oct 17 14:24:41 	no, for f9 Oct 17 14:24:42 	most of the desktop-oriented stuff on the blocker list relates to keyring handling and NM Oct 17 14:24:52 	bit late in the game to update for f8 I think Oct 17 14:25:00 	yea Oct 17 14:25:22 *	davidz curses fd.o gitweb Oct 17 14:25:25 	it's so bloody slow Oct 17 14:25:50 *	davidz checks out the source instead Oct 17 14:25:57 	i think we're good Oct 17 14:26:16 	oh, and media keys (e.g. thinkpad_acpi stuff, bug 321421 - but that's a complicated one) Oct 17 14:26:25 	LT_* are the same in the configure Oct 17 14:26:25 	for both Oct 17 14:26:29 	halfline, mclasen: there's an soname bump Oct 17 14:26:40 	hm, why? Oct 17 14:26:50 	just because... Oct 17 14:26:50 	err Oct 17 14:27:05 	davidz: there is? Oct 17 14:27:16 	are we looking at the same source trees? Oct 17 14:27:35 	hmmmm Oct 17 14:27:40 	anyway, lets not get bogged down in that soname issue Oct 17 14:27:41 	changed on 2007-02-13 Oct 17 14:27:50 	what are the improvements that we expect out of the new gdm ? Oct 17 14:28:05 	actually, we should probably start to fill a wiki page with that information... Oct 17 14:28:10 	to make poelstra happy Oct 17 14:28:44 	well, it's completely different Oct 17 14:28:48 	right now it's very raw Oct 17 14:29:01 	needs a lot of work just to get some parity with what were' currently shipping Oct 17 14:29:07 	halfline: no, I'm confused - will report back on the soname thing on #fedora-desktop later Oct 17 14:29:14 	davidz: ok Oct 17 14:29:29 	one thing it will offer is more of a session before you login Oct 17 14:29:43 	things like gnome-power-manager will be available at the login screen Oct 17 14:29:52 	so you can see your battery usage and suspend Oct 17 14:30:09 	the greeter is completely differnt Oct 17 14:30:14 	so existing themes probably won't work Oct 17 14:30:26 	unless we take some steps to make them work Oct 17 14:30:53 	there is also this idea of a factory greeter, which needs some investigation Oct 17 14:30:58 	the way that it works is, it's always present Oct 17 14:31:07 	and then the theory goes, anytime you need to lock the screen Oct 17 14:31:11 	we jump back to it Oct 17 14:31:14 	or fast user switch Oct 17 14:31:54 	well Oct 17 14:31:57 	we can't let gdm stay Oct 17 14:32:01 	until X is fixed Oct 17 14:32:09 	remember only one server can do DRI etc. Oct 17 14:32:18 	but I think we want g-p-m and n-m to run in gdm Oct 17 14:32:20 	as features Oct 17 14:32:36 	along with another feature in both g-p-m and n-m being a "Make these settings default" button Oct 17 14:32:40 	in their preferences dialog Oct 17 14:32:43 	I can look at the latter Oct 17 14:32:54 	right the factory is just an idea at this point Oct 17 14:32:58 	it's not even on by default right now Oct 17 14:33:04 	it's just PolicyKit and writing a small "copy gconf keys from user directory to system-wide location" thing Oct 17 14:33:08 	another thing Oct 17 14:33:14 	is that we want to introduce another layer in gconf Oct 17 14:33:26 	to do the "copy gconf keys from user directory to system-wide location" feature Oct 17 14:33:29 	anyho Oct 17 14:33:49 	so "introduce another layer into gconf" should be abother feature Oct 17 14:33:57 	now Oct 17 14:34:04 	that's at least three features that relates to gdm Oct 17 14:34:10 	thats a mini-feature, if anything Oct 17 14:34:10 	(which is fine; I'm just counting) Oct 17 14:34:29 	it would be cool if someone would go through all laptop drivers and add the required dmi modalias lines to them Oct 17 14:34:31 	mclasen: maybe! but it may require spec file changes across the entire distro Oct 17 14:34:42 	davidz: I think we can do without that Oct 17 14:34:53 	unless you want to be all fhs-correct and move the defaults to /usr/share Oct 17 14:35:11 	mclasen: that would be nice... it's still a pretty important thing to get right so should be tracked as a feature such as to not fall through the cracks (like it kinda did for f8) Oct 17 14:35:34 	another thing is graphical boot Oct 17 14:35:51 	we need to kick rhgb in the shins until it falls on its face Oct 17 14:36:07 	i mean, we need to retire rhgb Oct 17 14:36:22 	mezcalero: definitely worth adding as a feature too Oct 17 14:36:32 	(totally my random opinion, but i don't feel rhgb has a lot of value until we also fix the ~10 seconds of kernel developers saying "Hi Mom!" too) Oct 17 14:36:36 	i don't know where we stand wrt to drm mode setting though? Oct 17 14:36:52 	we need the X hackers to comment on that Oct 17 14:36:58 	ajax, krh, arlied and so on Oct 17 14:37:09 	given ajax is the only one in the room Oct 17 14:37:14 	ajax: speak up! Oct 17 14:37:17 	and could we please get rid of sendmail? Oct 17 14:37:19 	do what now? Oct 17 14:37:30 	ajax: you said you weren't going to speak for a month! Oct 17 14:37:30 	tell us where we are on drm mode setting Oct 17 14:37:47 	davidz: no, i said i need no one to speak to _me_ for a month. subtle difference! Oct 17 14:37:54 	ajax: aha! Oct 17 14:38:02 	halfline: uh. probably working for intel and radeon for F9? Oct 17 14:38:10 	cool, good enough Oct 17 14:38:16 	more than i was expecting in fact Oct 17 14:38:21 	so do we say "only graphical boot for intel, radeon"? Fine with me fwiw Oct 17 14:38:28 	yup Oct 17 14:38:41 	and everyone else we can say "8 second speed up during boot" Oct 17 14:38:53 	(and we'll quietly whisper the reason is because we dropped rhgb) Oct 17 14:39:39 	not having graphical boot on nv might be unpopular but whatever. Oct 17 14:40:00 	walters_: so the rhgb-replacement I started on actually gets a graphical boot up way earlier than rhgb. it starts even before the initial ram disk runs through Oct 17 14:40:10 	halfline: nice Oct 17 14:40:15 	other things; 1. I want to replace pam_console entirely - most of the work been done for f8 and there's consensus for what to do for f9; and 2. I want to PolicyKit-ify a few more apps.. maybe even replace userhelper with a small helper that uses PolicyKit to determine whether it's fine to launch a given (X11) app as root - such as to centralize how privileges are managed. Am also talking to other things (s-c-printer for one) in the Oct 17 14:40:15 	 distro using PolicyKit Oct 17 14:40:16 	also, when i say radeon, i mean <=r400, which is not exactly the top-end kit anymore Oct 17 14:40:41 	s/using/about using/ Oct 17 14:40:42 	getting r500 and r600 modesetting kernel-side is... possibly a much bigger challenge Oct 17 14:41:00 	ajax: even with amd's newfound docs? Oct 17 14:41:14 	yes. Oct 17 14:41:14 	davidz: how do we handle the dbus/consolekit chicken and egg problem? Oct 17 14:41:20 *	mezcalero wants fsck from nautilus Oct 17 14:41:25 	halfline: the dbus came first. Oct 17 14:41:27 	spot: i really don't want to talk about how much of a disaster that is right now. Oct 17 14:41:35 *	mezcalero and automatic fsck on dirty unmount for usb sticks Oct 17 14:41:36 	i have two drivers and neither one works Oct 17 14:41:36 *	spot backs away slowly Oct 17 14:41:41 	meaning dbus needs to know how has console, and consolekit uses dbus Oct 17 14:41:55 	halfline: really though, i think dbus should stop being in the business of fine-grained message control Oct 17 14:41:55 	and i'm supposed to wedge that into the kernel too! SIGN ME UP Oct 17 14:42:00 	halfline: shouldn't be a problem; let's discuss offline Oct 17 14:42:01 	anyway Oct 17 14:42:04 *	ajax retreats Oct 17 14:42:17 	halfline: any apps which have at_console=true in the policy config should instead take all messages and talk to policy kit on their own for permissions probably Oct 17 14:42:27 	ajax: look out, you're about to fall into that box of DRUGS! Oct 17 14:42:50 	okay, walters_ you want to join in on the conversation davidz and I are going to have offline? Oct 17 14:43:00 	halfline: sure Oct 17 14:43:12 	halfline: one thing I'm looking at is replacing "at_console" in dbus with "requires_polkit_privilege" - e.g. also teching the bus daemon about PolicyKit Oct 17 14:43:42 	davidz: okay, that's a little nicer, more fine grained policy control Oct 17 14:43:47 	still policykit uses dbus too :-) Oct 17 14:43:58 	no, that's in a convenience library Oct 17 14:44:07 	libpolkit does not use D-Bus. At all Oct 17 14:44:07 	ah okay Oct 17 14:44:13 	perfect Oct 17 14:44:36 	we may still need to get ConsoleKit to write out /var/run/console/* for backward compat Oct 17 14:44:37 	also.. I plan to make ConsoleKit maintain /var/run/console too Oct 17 14:44:40 	for backwards compat Oct 17 14:44:42 	jinks Oct 17 14:44:44 	wow Oct 17 14:44:46 	scary Oct 17 14:44:52 	Sorry, Ive been in another meething. Oct 17 14:45:23 	halfline: I did half of it http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=commit;h=b2be103bd606291319dc312f07d1f3fcbfdf634c Oct 17 14:45:37 	mclasen: to answer your question, yes, as of tonight the freeze is on and builds for fedora 8 release will have to go through releng to get into the final release. Oct 17 14:46:34 	f13: cool Oct 17 14:46:53 	was there any releng type questions? Oct 17 14:48:02 	f13: no, you pretty much answered them Oct 17 14:48:22 	f13: earlier on we had a fesco type question about feature proposals/brainstorming for f9 Oct 17 14:50:03 	ok, more f9 plans: mezcalero is going to continue his work on making PA kick ass in F9 Oct 17 14:50:21 	for F9 the topic will be better desktop integration Oct 17 14:50:29 	awesome Oct 17 14:50:30 	ie make volume control not suck Oct 17 14:50:55 	clean up the sound capplet, maybe Oct 17 14:50:58 	i know clarkbw was doing some mock ups on ways the volume control could be improved Oct 17 14:51:07 	btw, someone sent me a screenshot of the vista volume control Oct 17 14:51:11 	that is good; we need those mockups Oct 17 14:51:14 	mezcalero: clarkbw ? Oct 17 14:51:15 	mezcalero: yeah, was just about to mention that Oct 17 14:51:21 	mezcalero: it was on p.g.o IIRC Oct 17 14:51:28 	i am not sure who did Oct 17 14:51:30 	looked good Oct 17 14:51:36 	i guess i could check me inbox Oct 17 14:51:39 	it was jdahlin talking about vista volume control Oct 17 14:51:45 	on pgo Oct 17 14:51:46 	yeah Oct 17 14:52:04 	it's basically a pavucontrol with a sane ui Oct 17 14:52:07 	and clarkbw was showing vista screenshots here in the grotto yesterday Oct 17 14:52:22 	he linked this http://msdn2.microsoft.com/en-us/library/Aa511278.Sound08(en-us,MSDN.10).png Oct 17 14:52:30 	and they are doing vertical volume controls and just show the text on top Oct 17 14:52:40 	which is probably fine as long as you only want to show the appname Oct 17 14:52:42 	I'm not so sure about that Oct 17 14:52:57 	I guess we'll have to try if vertical works with text Oct 17 14:53:23 	yay, vertical text Oct 17 14:53:31 	nah Oct 17 14:53:37 	vertical text - that's so KDE Oct 17 14:53:43 	I meant if vertical sliders work with horizontal text Oct 17 14:54:01 	and apparently vista includes a peak meter for each stream Oct 17 14:54:06 	or at least for each device Oct 17 14:57:34 	mezcalero: we should probably start to write down the volume control plans on the wiki, too Oct 17 14:57:43 	once clarkbw hands over those mockups... Oct 17 14:58:12 	some novel people wanted to do som UI work too Oct 17 14:59:36 	s/novel/nivell Oct 17 14:59:39 	s/novel/novell Oct 17 14:59:40 	bah Oct 17 14:59:55 	my own personal f9 feature is the intlclock stuff that has already landed in the panel Oct 17 15:00:04 	mclasen: oddly enough we were just talking about that in another meeting. Oct 17 15:00:31 	I apologize for the fact that the intlclock in the current f9 package is pretty crashy Oct 17 15:00:35 	mclasen: I think a relevent comment otmake is that Features can be proposed at any time for F9, FESCo most likely won't start review/acceptance until after Nov 8th. Oct 17 15:00:44 	need to spend some time debugging it next weekend Oct 17 15:01:15 	f13: I was mostly wondering if fesco will send out a plea for f9 ideas/features/proposals Oct 17 15:01:49 	or if that will be self-organizing Oct 17 15:02:15 	also, we should probably send out pointers to the things we have already started to spec out on the wiki at some point Oct 17 15:02:28 	to invite comments from the broader public Oct 17 15:02:31 	mclasen: FESCo and/or poelcat will be sending out the request for features stuff. Oct 17 15:02:40 	ok, cool then Oct 17 15:02:55 	mclasen: we're really looking to poelcat to drive it, making use of resources as he deems necessary Oct 17 15:03:25 	ok Oct 17 15:03:27 	i'd personally buy the person who implements a sane fsck dbus service for usage in nautilus with support for the "dirty" shutdown flag of fat an ice cream Oct 17 15:03:45 	i.e. have an usb stick automatically fscked Oct 17 15:03:52 	with a nice gui progress bar Oct 17 15:03:55 	if it is plugged in Oct 17 15:04:07 	but wasn't unmounted properly before Oct 17 15:04:11 	http://www.geocities.com/thestarman3/DOS/DirtyShutdownFlag.html Oct 17 15:04:33 	yeah, just mounting read-only is rather rude. Oct 17 15:04:47 	'course it doesn't help with fsck.hfsplus segfaults on x86_64 :/ Oct 17 15:07:26 	do we have other F9 features in the pipeline that are worth talking about today ? Oct 17 15:07:38 	I know that hadess is looking to work on thinkfinger integration Oct 17 15:08:09 	well we've already run over an hour now Oct 17 15:08:13 	mclasen: hmm.. how does hadess work on that fit with Ben Konrath's work? Oct 17 15:08:42 	i think it weould be cool if we made a fake fingerprint on screen based on the fingerprint data Oct 17 15:09:06 	even if it's not the real fingerprint, but a generated one that's unique for the given data Oct 17 15:09:11 	halfline: fingerprint data is probably not available from libthinkfinger Oct 17 15:09:14 	davidz: I'd hope that it ties nicely together Oct 17 15:09:33 	I've already mentioned fingerprint enrollment as a thing to add to the dialog to ben Oct 17 15:09:34 	davidz: i don't know anything about the implementation really, but i just think it would be neat Oct 17 15:09:36 	mclasen: I think it's probably the same feature... Oct 17 15:09:44 	and I've asked clarkbw for some design input on that Oct 17 15:09:47 	but he probably forgot Oct 17 15:10:19 	halfline: just for fun! http://blog.fubar.dk/?p=35 Oct 17 15:10:24 	halfline: (not thinkfinger) Oct 17 15:10:42 	halfline: you are right, we should close for today Oct 17 15:11:15 	davidz: cool Oct 17 16:04:59 *	clarkbw realizes he missed the whole meeting... Oct 17 16:08:25 	mclasen: http://www.gnome.org/~clarkbw/designs/volume%20control/vista/ Oct 17 16:08:38 	for the screenshots of vista we looked at yesterday