13:59:46 <rdieter> #startmeeting kde-sig -- https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2010-03-09 13:59:47 <zodbot> Meeting started Tue Mar 9 13:59:46 2010 UTC. The chair is rdieter. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:59:49 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:00:04 <rdieter> #chair Kevin_Kofler than SMParrish jreznik 14:00:05 <zodbot> Current chairs: Kevin_Kofler SMParrish jreznik rdieter than 14:00:08 <rdieter> #meetingname kde-sig 14:00:09 <zodbot> The meeting name has been set to 'kde-sig' 14:00:15 <rdieter> #topic roll call 14:00:19 <rdieter> who's present today ? 14:00:28 <Kevin_Kofler> Present. 14:01:07 * than is present 14:02:34 <rdieter> jreznik, ltinkl : ping 14:02:46 * ltinkl just arrived 14:02:52 <jreznik> here 14:03:19 <rdieter> #topic kde-4.4.1 update status 14:03:38 <rdieter> k, looks like we've got 4.4.1 in updates-testing now (as well as kde-testing). 14:03:58 <rdieter> so far so good 14:04:11 <Kevin_Kofler> Looks like no complaints so far. 14:04:31 <Kevin_Kofler> I think we can go stable soon. 14:04:43 <ltinkl> I'm definitely going to test as soon as they arrive 14:04:48 <jreznik> it's working quite well - seems much more stable for me than 4.4.0 (no abrt at all) 14:05:06 <rdieter> I agree, also note in parallel I put out a kde-settings update to enable nepomuk (but not strigi indexing) 14:05:12 <Kevin_Kofler> So, do you want me to hit "push to stable" right away? 14:05:28 <rdieter> wait at least a few more days... :) 14:05:29 <Kevin_Kofler> Or should we wait for at least a week of testing? 14:05:36 <than> Kevin_Kofler: not yet 14:05:41 <rdieter> let's shoot for early next week 14:06:09 <jreznik> next meeting please 14:06:11 <than> Kevin_Kofler: we should wait for a week of testing 14:06:24 <jreznik> I'm testing it on three computers, behaves very well 14:06:26 <Kevin_Kofler> If I hit "push to stable" on Sunday so that it gets pushed next Monday, is that OK? 14:06:44 <Kevin_Kofler> (assuming no negative feedback coming in in the meantime) 14:06:51 * SMParrish late but here 14:06:58 <rdieter> SMParrish: hi :) 14:07:51 <rdieter> Kevin_Kofler: how about waiting until then, and getting say 3 +1's from our informal steering committee folks 14:08:23 <rdieter> f13 stuff perhaps could go earlier though. 14:08:25 <ltinkl> let's informally vote at the next meeting 14:08:36 <than> Kevin_Kofler: let wait for next meeting 14:08:50 <Kevin_Kofler> Next meeting means waiting for more than a week of testing though. 14:09:10 <rdieter> ok, a ocuple more days won't hurt. (it'll be at least a week + 1 day) 14:09:24 <rdieter> should we treat f13 any different or the same ? 14:09:40 <Kevin_Kofler> But this fixes some regressions in 4.4.0, it's a bugfix-only release and there are no complaints so far. 14:09:48 <jreznik> it's already in kde-redhat for really impatient users... 14:09:49 <Kevin_Kofler> Why does this need 8+ days of testing? 14:10:17 <rdieter> Kevin_Kofler: because it's big that's all. waiting a few more days gives us the luxery of rolling in other fixes in the meantime as well 14:10:23 <SMParrish> Since alpha just came out today I would say push it out to F13 now, and give F12 & F11 a weeks testing 14:10:30 <rdieter> for example, the kdebindings/mono thing 14:11:16 * thomasj_ is here as well 14:11:21 <Kevin_Kofler> Good point there, but on the other hand rolling in more stuff can cause new problems. 14:11:24 <rdieter> I would tend to agree with SMParrish, anyone else ? 14:11:39 <Kevin_Kofler> Pushing what works to stable and queueing extra stuff later might be safer. 14:11:40 <jreznik> SMParrish: +1 14:12:04 <jreznik> Kevin_Kofler: mono wouldn't cause problems - but I'd like to see it in next push too 14:12:26 <jreznik> (as no one is using mono I hope at all) 14:12:34 <than> SMParrish: +1 14:12:41 <jreznik> but you're right - do not touch this stuff in this push 14:12:41 <ltinkl> plus one 14:13:32 <jreznik> maybe we can have quick "go" meeting earlier in case of no problems arrives but for now it's safer to wait one week 14:13:43 <rdieter> consider us agreed then, we'll do f13 asap, the others wait until next meeting to decide. 14:14:02 <Kevin_Kofler> If it's stable enough for the frozen F13, why is it not stable enough for updates? 14:14:24 <rdieter> #agreed will push 4.4.1 stable soon for f13, f11/f12 decision postponed until next meeting 14:14:49 <jreznik> Kevin_Kofler: it's after alpha, we are not going to ship it soon in F13 again so we have not so pressure to fix possible problems 14:15:01 <ltinkl> Kevin_Kofler: it's good enough for alpha release of F13? :) 14:15:02 <rdieter> F13 is out there for *testing* purposes 14:15:03 <Kevin_Kofler> The Alpha is set to update from the dist-f13 repos. 14:15:04 <Southern_Gentlem> Kevin_Kofler, you have more people to affect if you break f11-f12 at this point 14:15:10 <SMParrish> Kevin_Kofler: very few people will be running f13 atm, and those who do are expecting issues and will report them. F12 and F11 expect and want stabilty 14:15:53 <Southern_Gentlem> people running the alpha will be running it mainly in vm 14:16:06 <thomasj_> +1 Southern_Gentlem 14:16:19 <thomasj_> If KDE breaks this time, they will hang us higher 14:16:24 <Kevin_Kofler> The F13 update is now queued for stable. 14:16:36 <Kevin_Kofler> thomasj_: The point is that 4.4.1 actually fixes some of the breakage from 4.4.0. 14:16:45 <rdieter> ok, anything else, or can we move on? 14:16:52 <Kevin_Kofler> What about rdieter's kde-settings update? 14:16:54 <thomasj_> Kevin_Kofler, i know, but you know what hell is going on at the list right now. 14:16:56 <Kevin_Kofler> When can that go stable? 14:17:19 <Kevin_Kofler> I'd say ASAP, I've been running with Nepomuk enabled since right after I upgraded to 4.4.0, no issues. 14:17:20 <rdieter> oh, ok, sure comments there wrt to enabling nepomuk ? 14:17:39 <ltinkl> no problems with nepomuk here, it actually works :) 14:17:50 <thomasj_> Enabling nepomuk, disabled strigi: +1 14:18:00 <rdieter> just looked, it hasn't actually been pushed into -testing yet, looks like I queue'd it too late for yesterday's push 14:18:07 * thomasj_ tends to forget he has no voting right.. sorry 14:18:10 * ltinkl even has strigi on 14:18:35 <jreznik> ltinkl: problem is with disabled nepomuk, not running one :) 14:18:38 <rdieter> thomasj_: we're not formally voting on anything anyway, doing it that way to express opinions is perfectly ok. 14:18:54 <thomasj_> ltinkl, me too, but i fear a bunch of emails about the resource uasge of strigi if it's enabled out of the blue. 14:19:07 <ltinkl> thomasj_: yup 14:19:21 <Kevin_Kofler> We shouldn't enable Strigi in an update. 14:19:21 <rdieter> since this update hasn't hit testing yet, how about waiting then. give it at least 2-3 days in -testing, then we'll see. 14:20:01 <rdieter> to be clear,this update does *not* enable strigi indexing. :) 14:20:08 <rdieter> only nepomuk 14:20:11 <thomasj_> :) 14:20:23 <Kevin_Kofler> You had already queued this to testing earlier, why have you unqueued it (and then requeued it too late for the push)? :-( 14:20:38 <Kevin_Kofler> We had already agreed on #fedora-kde that it should be done. 14:20:57 <rdieter> I meant to submit it only for pending before, bodhi queue'd it anyway (maybe my error), so I undid it 14:21:15 <Kevin_Kofler> But why? We already agreed on it, it should have hit testing ASAP! 14:21:26 <rdieter> Kevin_Kofler: really? I'd been looking around for +1's, and no one was around. 14:21:39 <rdieter> only you, I, and jreznik at the time, iirc. 14:21:40 <Kevin_Kofler> All those who were around agreed. ;-) 14:21:57 <Kevin_Kofler> And that's already almost a formal majority (just one +1 missing). ;-) 14:22:08 <rdieter> well, anyway, doesn't matter now. 14:22:10 <Kevin_Kofler> FWIW, now we also have ltinkl agreeing, so that's +4. 14:22:37 <Kevin_Kofler> Users are being plagued by those annoying dialogs and have been complaining about it and we're sitting on the fix. :-( 14:22:59 <Kevin_Kofler> FWIW, I'd have queued the update directly to stable right upon making it. 14:23:29 <rdieter> I didn't feel comfortable doing that before I had 4 +1's, that's all 14:23:50 <rdieter> ok, so, Kevin_Kofler's proposing we fast-track this, anyone like/dislike that? 14:24:18 * thomasj_ likes it to fix the nepomuk anoying 14:24:36 <Kevin_Kofler> I guess at this point it's not going to matter all that much. 14:24:57 <Kevin_Kofler> We can let it go through testing and hit push to stable right after the testing push. 14:25:32 <jreznik> for this issue I'm for fast track - hopefully it should be safe 14:25:52 <ltinkl> +1, fast 14:26:24 <SMParrish> +1 no harm pushing it out 14:27:03 <than> than: it's fine with me 14:27:13 <rdieter> alright, the people have spoken, will do. (I was torn +0) 14:27:45 <rdieter> #agreed will queue kde-settings update to enable nepomuk for stable 14:28:10 <rdieter> #topic default cursor theme, https://bugzilla.redhat.com/show_bug.cgi?id=571039 14:28:42 <rdieter> I'd tend to go for consistency here, and ask libXcursor to just use dmz-aa everywhere 14:29:03 <Kevin_Kofler> I think the GNOME folks want plain dmz, not dmz-aa. 14:29:35 <jreznik> plain dmz theme icons are a little bigger 14:30:01 <Kevin_Kofler> FWIW, wouldn't the best solution be to remove that "default" hack from libXcursor entirely? 14:30:03 <jreznik> but still usable, oxygen is no way 14:30:05 <ltinkl> is there any preview, how they look like? 14:30:15 <jreznik> ltinkl: there's link 14:30:21 <Kevin_Kofler> GNOME doesn't use it anymore, and KDE only uses it because we set it in kde-settings. 14:30:27 <Kevin_Kofler> We could set an actual theme directly there. 14:30:28 <rdieter> http://jimmac.musichall.cz/themes.php?skin=7 14:30:29 <jreznik> ltinkl: http://jimmac.musichall.cz/themes.php?skin=7 14:30:41 <rdieter> jinx! 14:30:49 <jreznik> Kevin_Kofler: yes 14:30:57 <Kevin_Kofler> The solution in libXcursor is poor because it's missing a Requires, but adding that Requires would make the library depend on a particular theme for no good reason. 14:31:17 <thomasj_> dmz-aa looks nice. 14:31:21 <rdieter> Kevin_Kofler: no good reason, other than to make the default/expected theme work? 14:31:24 <ltinkl> I prefer plain dmz 14:31:49 <SMParrish> I prefer dmz-aa 14:31:54 <rdieter> Kevin_Kofler: of course, that could be made soft via just installing it via comps 14:31:57 <Kevin_Kofler> What's wrong with Bluecurve? 14:32:29 <than> rdieter: will dmz be used in gnome? 14:32:30 <rdieter> nothing's wrong with it per-se. 14:32:36 <rdieter> than: looks that way 14:32:37 <jreznik> than: probably yes 14:33:04 <jreznik> Kevin_Kofler: dmz is little more consistent... nothing wrong with bluecurve... 14:33:06 <than> i will say we should use dmz too 14:33:23 <than> jreznik: +1 14:33:50 <rdieter> bluecurve is a bit smaller than dmz, if that matters any 14:34:07 <ltinkl> I wouldn't say we should, I also like oxygen 14:34:09 <thomasj_> dmz looks old. But hey.. 14:34:12 <jreznik> rdieter: yes, it's that's why I visually prefer dmz-aa 14:34:12 <nucleo> now even if set dmz-aa in systemsettings there is in kdm old KDE2 cursor theme 14:34:28 <Kevin_Kofler> I'd have an easier time getting used to dmz-aa, it looks more like Bluecurve, dmz is white, so completely different. 14:34:31 <rdieter> jreznik: I was talking about pkg size, but that's true too. :) 14:34:34 <jreznik> ltinkl: oxygen too gamish :) for starcraft maybe 14:34:42 <Kevin_Kofler> But most likely I'll be switching to Bluecurve manually anyway. :-) 14:34:44 <jreznik> rdieter: ah ;-) 14:34:50 <Kevin_Kofler> So don't bother designing for me. ^^ 14:35:08 <jreznik> Kevin_Kofler: yes, dmz-aa is more bluecurve like 14:35:11 <rdieter> nucleo: systemsettings is per-user, but fixing this globally will make kdm work too 14:35:38 <jreznik> what I liked on bluecurve it was nice set of black and white cursors... not so consistent but better usability 14:35:40 <nucleo> rdieter: so, it will be fixed globally? 14:35:53 <rdieter> nucleo: yes 14:36:15 <Kevin_Kofler> Interestingly, in the Bluecurve cursor theme, the default pointer looks close to dmz-aa, the pointed index looks close to dmz. 14:37:07 <Kevin_Kofler> The bluecurve-cursor-theme is not all black or all white, but mixed. 14:37:45 <rdieter> ok, so for now, any objections if I comment in the aforementioned bug, to work towards making this consitent distro wide, and commit to using dmz (for now)? 14:37:58 <nucleo> like white cursor on links 14:38:09 * Kevin_Kofler still thinks Bluecurve is better. :-) 14:38:17 <ltinkl> rdieter: go 14:38:22 <SMParrish> rdieter: no objections here 14:38:33 <Kevin_Kofler> Why do we need to change to something different, just because it's not Bluecurve? 14:38:36 <thomasj_> It needs to be fixed, so better dmz than nothing 14:38:55 <Kevin_Kofler> thomasj_: IMHO, "nothing" is the best option for libXcursor. 14:39:01 <thomasj_> heh 14:39:04 <Kevin_Kofler> We should just set the theme to an actual theme name in kde-settings. 14:39:08 <Kevin_Kofler> Not "default". 14:39:41 <Kevin_Kofler> That "default" theme was there because old versions of GNOME needed it. 14:39:51 <Kevin_Kofler> And we set theme=default because it was there, I guess. 14:39:55 <rdieter> ok, let's put it another way, what's the point of even having a 'default' if it's not used anywhere? 14:40:52 <jreznik> nucleo: me too... that's my complain... I'd like to have dmz + dmz-aa together 14:40:54 <Kevin_Kofler> That "default" hack also leads to having the default theme listed twice in System Settings, once as "default" and once under its actual name. 14:41:08 <rdieter> may as well just get rid of it? 14:41:35 <rdieter> Kevin_Kofler: I don't see it listed twice ? 14:41:47 <rdieter> in icon themes or cursor theme? 14:42:15 * rdieter looked in both, no dups 14:42:16 <Kevin_Kofler> I guess KDE has added a blacklist for "default" to work around this. 14:42:22 <Kevin_Kofler> It used to be listed twice in the past. 14:42:26 <rdieter> ok 14:42:37 <Kevin_Kofler> So that particular issue seems not to be there. 14:43:03 <jreznik> nucleo: maybe we can ask for dmz remix - dmz for main cursor and dmz-aa for links etc... 14:43:04 <Kevin_Kofler> Hmmm, wait, I think it's actually GNOME's tools which love listing it twice because they don't understand "default" anymore. But that's not our problem. :-p 14:43:19 <rdieter> let's move on, looks like we've got semi-agreement here. 14:43:26 <rdieter> #topic roadmap/timeline to removing hal dependencies from kde? 14:43:29 <rdieter> ltinkl: ? 14:43:38 <Kevin_Kofler> I haven't fired up gnome-control-center for a long time now, as I don't run gnome-settings-daemon within KDE anymore (and KDE is all I use). 14:43:41 <rdieter> Some background: In particular, mjg59 is suggesting removing storage support in hal to save huge amounts of power... 14:43:43 <jreznik> rdieter: what's semiagreement? :D stay with bluecurve? 14:43:50 <ltinkl> I wouldn't be optimistic about removing HAL 14:43:57 <ltinkl> I looked at the current state of udisks... it's simply not sufficient for Solid needs 14:44:00 <rdieter> jreznik: most folks ack'd my idea to use dmz already 14:44:18 <Kevin_Kofler> ltinkl: The limitations are a "feature", it seems. :-( 14:44:24 <jreznik> rdieter: so can I reply to Matthias we'd like to use it too? 14:44:26 <Kevin_Kofler> They decided to save power by simply removing all polling. 14:44:29 <nucleo> jreznik: thet that remix will replace dmz or dmz-aa or all of them will be installed? 14:44:39 <Kevin_Kofler> So goodbye to handling the CD player's eject key in software. 14:44:48 <Kevin_Kofler> Also goodbye to autodetecting inserted floppies. 14:44:48 <ltinkl> it doesn't provide features as read/write speeds for CD/DVD burners, type of media in CD/DVD readers 14:44:50 <rdieter> ltinkl: As I suggested yesterday, let's come up with a laundry-list of missing features that kde/solid needs 14:44:55 <ltinkl> lots of stuff would break in KDE 14:45:06 <Kevin_Kofler> (Floppy drives don't support autorun in hardware.) 14:45:15 <rdieter> stuff it in the wiki somewhere, and list those as blockers for hal removal. 14:45:27 <ltinkl> ejecting disks wouldn't work from the "Recently mounted" applet etc. 14:45:33 <rdieter> so we can point to that when the inevitable questions about deprecating hal come up again 14:45:37 <jreznik> Kevin_Kofler: list sounds good for me - to have something to say stop - do not remove hal w/o replacement 14:45:57 <Kevin_Kofler> jreznik: The thing is, they won't see those as arguments. 14:45:58 <rdieter> hal is not going to be removed 14:46:04 <Kevin_Kofler> Because they say polling just has to go away. 14:46:05 <rdieter> no one is suggesting that... yet 14:46:09 <ltinkl> ok if I collect a list of missing funtionality in terms what Solid needs (somewhere in wiki)? 14:46:10 <than> Kevin_Kofler: it's good arguments 14:46:16 <rdieter> ltinkl: yes, please. 14:46:30 <ltinkl> ok 14:46:30 <Kevin_Kofler> rdieter: But storage functionality is essential and they want to remove it. 14:46:42 <than> ltinkl: could you please create a list? 14:46:43 <jreznik> ltinkl: you're the one who knows it best ;-) 14:46:44 <rdieter> Kevin_Kofler: they won't if we still need it,that's the point 14:46:44 <Kevin_Kofler> They're also looking into making it enabled only under KDE somehow, not sure what that'll mean. 14:47:10 * thomasj_ has to leave.. Doctors appointment.. 14:47:11 <Kevin_Kofler> It might lead to KDE apps in GNOME and/or added to the GNOME spin being badly broken. 14:47:12 <rdieter> Kevin_Kofler: I'm not sure either 14:47:25 <rdieter> thomasj_: take care 14:47:30 <thomasj_> thanks 14:47:34 <ltinkl> there are imho only 2 solutions, implement the missing functionality in udisks ourselves (unlikely), or maintain HAL 14:47:49 <rdieter> ltinkl: likely some combination of both, sooner or later 14:48:13 <Kevin_Kofler> rdieter: I'm not so positive, given how they've arbitrarily removed stuff under us in the past. :-/ 14:48:17 <Kevin_Kofler> We may have to fight for it. 14:48:23 <ltinkl> I don't think udisks developers will let us implement stuff like polling if they are against it 14:48:36 <Kevin_Kofler> They're already refusing to support power management governor switching. 14:48:46 <jreznik> ltinkl: implement it directly in solid next to udisk? 14:48:48 <ltinkl> yup, the list is quite _long_ 14:48:54 <rdieter> Kevin_Kofler: look, they asked us, and we're providing feedback to what we need. that's all well and good, and nothing to complain about (yet). 14:48:57 <jreznik> reimplement all in solid? 14:49:03 <jreznik> and do not use udisk at all 14:49:08 <ltinkl> the problem is that Solid doesn't support "multi backend" approach 14:49:16 <ltinkl> you have to select exactly one, at compilation time 14:49:19 <Kevin_Kofler> ltinkl: That's planned for 4.5 or 4.6. 14:49:31 <Kevin_Kofler> And u* backends are also being worked on as part of that. 14:49:36 <ltinkl> Kevin_Kofler: yup I noticed some plans for it, 4.5 probably 14:49:41 <Kevin_Kofler> I think we're rushing things by trying to shoehorn that stuff into 4.4. 14:49:49 <jreznik> ltinkl: you can implement unimplemented stuff in udisk backend... it's hacky but... 14:49:56 <ltinkl> Kevin_Kofler: indeed, I don't think we have to rush this in 14:50:20 <jreznik> ltinkl, Kevin_Kofler: we still should be more involved in upstream development here 14:50:26 <Kevin_Kofler> We could have a kded4 module doing polling, but the problem is, udisks is also going to change things around to support non-polling which we may not want. 14:50:27 <ltinkl> imho it's more important to point out what we need to be on par with HAL backend 14:50:54 <Kevin_Kofler> E.g. they just want to let the CD player's eject key eject stuff directly (i.e. no longer lock it) instead of unmounting cleanly. 14:50:59 <rdieter> ltinkl: indeed, that's the primary exercize here 14:51:21 <Kevin_Kofler> So we'd also have to relock it if udisks unlocks it, not just install a kded4 module to handle polling. 14:51:34 <Kevin_Kofler> Plus, the polling probably needs a privileged part, which kded4 is not designed for. 14:51:36 <rdieter> udisks folks need also to be aware of kde's needs, and if they expect kde to use it, they need to compromise a bit too 14:51:48 <Kevin_Kofler> rdieter: I think polling is not debatable. 14:52:02 <Kevin_Kofler> They consider it a waste of power and think desktops need to live without it. 14:52:28 <rdieter> right, if we/kde/solid consider that a deal-breaker, then we need to communicate that 14:52:45 <jreznik> rdieter: upstream should be more involved 14:52:59 <jreznik> it's problem with kde upstream - really very reactive and not proactive 14:53:00 <rdieter> *foo* should be more involved. 14:53:50 <Kevin_Kofler> Another issue is that stuff constantly changes, often in cycles. 14:53:56 <rdieter> ltinkl: any other hal-related solid dependencies that we should be worrying about? 14:54:10 <Kevin_Kofler> E.g. X input settings were in xorg.conf, then they moved to HAL, and now they moved back to xorg.conf(.d). 14:54:45 <Kevin_Kofler> Sure, progress is made, but the place stuff is implemented in often rotates in cycles. 14:54:46 <ltinkl> rdieter: don't think so, other than what Kevin mentioned, udisks is not really stable API and ABI wise 14:55:13 <rdieter> ltinkl: ok, document that too, while making your list. 14:55:54 <Kevin_Kofler> Some new cool thing like HAL is introduced, everything moves to getting handled by HAL, and suddenly HAL is deprecated and everything moves away from HAL. 14:56:01 <Kevin_Kofler> And often back to where it originally was. 14:56:25 <rdieter> #action ltinkl to document a list of udisk missing features, that block our removal of hal dependencies from kde/solid 14:56:50 <rdieter> Kevin_Kofler: indeed 14:57:25 <rdieter> #topic open floor 14:57:35 <rdieter> about out of time for today, any last thoughts? 14:57:35 <Kevin_Kofler> For example, handling device permissions for the local ("console") user is a PITA, the way to do it has changed at least 5 times. 14:57:46 <Kevin_Kofler> I've been through all of them with my CalcForge packages. 14:59:40 <rdieter> ltinkl: I know you're probably very busy already, but would you be able/interested in helping comaintain hal in fedora? 15:00:15 <ltinkl> rdieter: I can try :) no idea how much work it is 15:00:19 <rdieter> I've offered the help already, and I think it would be wise to have one of our own helping more closely there 15:00:37 <rdieter> ltinkl: at first, I'd assume very little work. 15:01:01 <ltinkl> rdieter: from what I've heard, there will be no more development in HAL, only 1 or 2 maintenance releases 15:01:02 <rdieter> but I'd like to have someone at least helping keep an eye on things there, to help with kde-specific features, issues there 15:01:16 <rdieter> that's fine. 15:01:32 <Kevin_Kofler> Maybe someone should actually fork HAL? 15:01:47 <Kevin_Kofler> Or at least add patches like the LVM patch somebody supposedly wrote? 15:01:56 <rdieter> hal fork = DeviceKit, PowerKit, *foo*Kit 15:02:11 <Kevin_Kofler> They're not forks, they're rewrites. 15:02:39 <jreznik> Kevin_Kofler: rewrites that was rewrited because old one sucked and new ones sucks much more :( 15:02:40 <rdieter> no need to fork, if you want stuff to happen, work to get it upstream. 15:02:58 <rdieter> unless upstream rejects it I guess... 15:03:05 <rdieter> anyway, out of time now. thanks everyone. 15:03:07 <jreznik> or write solid backend from scratch - no udisks, hal 15:03:13 <rdieter> #endmeeting