27 June 2012 Trinity Meeting

meeting.log

[11:00] <@[wcm]> == everything below here will be logged (11:00 AM EST) ==
[11:00] <MutantTurkey> morning folks
[11:01] <@Xu_R> o/
[11:01] <MutantTurkey> I see it's the usual packed house >_>
[11:01] <@Xu_R> <_< more people would be nice...
[11:01] == schreiberstein [~schreiber@p57BCE34B.dip.t-dialin.net] has joined #trinity-desktop-meeting
[11:02] == SlavekB [~slavek@mail.axis.cz] has joined #trinity-desktop-meeting
[11:02] == samelian [~same@89.114.234.9] has joined #trinity-desktop-meeting
[11:02] <MutantTurkey> Xu_R: just gotta remind em
[11:02] <eliddell> Heh, and here I thought his comment had conjured them up. ;)
[11:02] <@Xu_R> I bumped the email yesterday :/ hopefully people show up :P
[11:04] <samelian> Xu_R: next time please use GMT time :)
[11:04] <samelian> I can't remeber your timezone :)
[11:04] <MutantTurkey> really should use UTC right?
[11:04] <@Xu_R> samelian: yup, sorry, was a spur of the moment email... it's 1600 GMT ;P (too late)
[11:04] <MutantTurkey> start at 11:10 ok?
[11:05] <samelian> well, is very good hour for me
[11:05] <Z_God> yeah same here, had to look up it was UTC-5 (added it to the etherpad then)
[11:05] <samelian> there is 18:05
[11:05] <@Xu_R> MutantTurkey: kk
[11:05] <@Xu_R> ah, ok. I tried to find a good time for everyone
[11:05] == kb9vqf [~kb9vqf@edge.pearsoncomputing.net] has joined #trinity-desktop-meeting
[11:05] == mode/#trinity-desktop-meeting [+o kb9vqf] by ChanServ
[11:06] <@kb9vqf> Hello all
[11:06] <@Xu_R> kb9vqf: long time no see :)
[11:06] <@kb9vqf> :)
[11:06] <MutantTurkey> the white wizard approaches
[11:06] <schreiberstein> ^^
[11:06] <@Xu_R> indeed, he does
[11:06] <@kb9vqf> I figured I should check in on this little thing I am in charge of ;-)
[11:07] <@Xu_R> ;)
[11:07] <MutantTurkey> good turnout - though we are missing our prime bug tester Darrell
[11:07] <@Xu_R> and David as well
[11:07] == Xu_R changed the topic of #trinity-desktop-meeting to: http://trinity.etherpad.trinitydesktop.org/48
[11:07] <@kb9vqf> speaking of bugs, has everyone seen the (old) news on the TDE front page?
[11:08] <MutantTurkey> he's posted to the ArchLinux list looking for package hosting - hopefully that means he is almost complete
[11:08] <MutantTurkey> kb9vqf: did you just post that?
[11:08] <@Xu_R> The etherpad is in the topic
[11:08] <@kb9vqf> nope, look at the date
[11:08] <MutantTurkey> seems that I missed that update
[11:08] <@Xu_R> saw that already :P
[11:09] <MutantTurkey> If i do say so, the website works pretty damned nice
[11:09] <@Xu_R> indeed it does.
[11:09] <@kb9vqf> Darrell also recently updated the About page
[11:10] <MutantTurkey> do we have an FAQ yet?
[11:10] <@kb9vqf> Only on the Etherpad IIRC
[11:10] <MutantTurkey> my bugzilla-foo is reporting that over 213 bugs have been marked resolved since the release of 3.5.13
[11:11] <@Xu_R> ok, I'm starting the meeting right now then. Remember, we have no meetbot, so make sure to mark important items on the etherpad
[11:11] <@kb9vqf> Bugs are a major issue still
[11:11] <@Xu_R> and I'll grab the logs from webchat ([wcm])
[11:11] <@kb9vqf> but yes, good progress has been made
[11:12] <@kb9vqf> The reason I referenced the TDE home page is for the link in that news item--it brings up a report on bug status for all of TDE
[11:12] <@Xu_R> I'm going to go straight down the etherpad list. Stop me if there needs to be any discussion.
[11:12] <MutantTurkey> kb9vqf: I think regular updates are important on the homepage, to keep people clued' in
[11:12] <@Xu_R> ah, I see the link. *notes on etherpad*
[11:13] <@Xu_R> (that's a long link >.>)
[11:13] <@Xu_R> Ok. First topic: Qt->TQt conversion.
[11:14] <@Xu_R> See if there are any 3rd party packages impacted by this change (see relevant mailing list thread)
[11:14] <@Xu_R> Bringing some apps into the tree because of TQt3?
[11:15] <@Xu_R> Brainstorming how to identify and handle apps that need Qt3
[11:15] <@Xu_R> Any comments so far?
[11:15] <MutantTurkey> is this even relevant? as long as everyone has Qt3 installed for those 3rd party applications - there shouldn't be a problem right?
[11:16] <@kb9vqf> Right
[11:16] <Z_God> I wonder how non-TQt Qt3 applications look and integrate in TQt-Trinity
[11:16] <MutantTurkey> they should be the same
[11:16] <MutantTurkey> afaik?
[11:16] <@kb9vqf> AFAIK they would only have native Qt3 themes available
[11:17] <eliddell> Thing we might have to watch for is API break between last Nokia QT3 and 3.3.8d
[11:17] <MutantTurkey> but it would be the same even if you linked it against TQt3
[11:17] <@kb9vqf> The major deal breaker here seems to be QCad; when was the last release of QCad for Qt3?
[11:17] <@kb9vqf> i.e. was it already abandoned?
[11:17] <MutantTurkey> last release was 2012, but I think that is Qt4
[11:17] <Z_God> as for Qt3 apps, I still use Twinkle here
[11:18] <@kb9vqf> In that case someone should contact them and see if they have dropped all Qt3 support
[11:18] <@kb9vqf> Personally I expect the third-party Qt3 app issue to go away in the next few years
[11:18] <eliddell> Listed release for qcad in kde-sunset is 2.0.5
[11:18] <MutantTurkey> kb9vqf: because no-one will maintain it?
[11:18] <@kb9vqf> pretty much
[11:19] <@kb9vqf> or that there will be an equivalent Qt4 app available by that time
[11:19] <@kb9vqf> I initiated TQt3 to solve major problems with keeping Qt3 and Qt4 on the same system
[11:19] <@kb9vqf> so far that has worked very well
[11:19] <@kb9vqf> IMHO more effort should go into polishing the Qt3-->Qt4 theme engine
[11:20] <@kb9vqf> that way Qt4 apps will look and act native on TDE
[11:20] <@kb9vqf> (as much as possible anyway!)
[11:21] <Z_God> otherwise they could just be compiled against TQt I suppose
[11:21] <@kb9vqf> There is some porting required (essentially just renaming headers and object names)
[11:22] <Z_God> is there a guide for that?
[11:22] <@kb9vqf> other than that, yes, they could just be built against TQt3
[11:22] <Z_God> Qt3->TQt3 porting guide or smth like that?
[11:22] <@kb9vqf> There are some scripts in GIT, but they are probably out of date
[11:22] <Z_God> there should be a webpage with step by step info imo
[11:22] <@Xu_R> it should essentially be putting t in front of most names asnd headers, right?
[11:22] <@kb9vqf> The guidelines are: All QObject, QWidget, (Q objects) need to become TQObject, TQWidget, etc.
[11:23] <@kb9vqf> tqt.h should be included from the command line for gcc
[11:23] <@kb9vqf> and yes, static qt variables are now tqt_* instead of qt_*
[11:23] <@kb9vqf> Fairly simple, but tedious to get 100% right
[11:23] <@kb9vqf> I do agree with Z_God, a web page should be put up with this information
[11:24] <@kb9vqf> Much of it can be extracted from tqt.h
[11:24] <@Xu_R> I've noted that on the Etherpad for now. It needs to be moved to the wiki.
[11:24] <@kb9vqf> yes
[11:26] <@Xu_R> ok. anything else before I keep moving down the list?
[11:26] <@kb9vqf> any questions about TQt3
[11:26] <@kb9vqf> ?
[11:27] <@kb9vqf> if not go ahead to the next topic :)
[11:28] <@Xu_R> ok... Discuss whether an install can be made with a base OS and TDE without any underlying apps pulling in Qt4..
[11:28] <@Xu_R> ^ we may want to skip this for now and come back for it later...
[11:28] <@kb9vqf> Xu_R: It is of course theoretically possible
[11:28] <@kb9vqf> the LiveCDs would do this for example
[11:29] <@Xu_R> It's all packaging in the end :)
[11:29] <@kb9vqf> right
[11:29] <@kb9vqf> the quality of the packaging, specifically
[11:29] <@Xu_R> yup.
[11:29] <@Xu_R> ok. 3.5.13.1 progress (Slavek's backporting work :D)
[11:30] <@Xu_R> SlavekB: Status update on how your PPA is going?
[11:30] <SlavekB> Ok, I'm ready.
[11:30] <@Xu_R> Go ahead. :)
[11:31] <SlavekB> Most of the patches I have already incorporated into the v3.5.13-sru branch.
[11:32] <@Xu_R> great! :D
[11:32] <SlavekB> Still working on the latest packages for which are the "Fix inadvertent" TQ "changes" or "GCC 4.7 fixes."
[11:33] <MutantTurkey> is this going to be a real release?
[11:33] <@kb9vqf> That is my intention
[11:33] <MutantTurkey> ok awesome
[11:33] <@kb9vqf> I'm just waiting for all the bugs to be worked out :)
[11:33] <@Xu_R> http://trinity.etherpad.trinitydesktop.org/16 etherpad for the SRU
[11:33] <MutantTurkey> SlavekB: what bugs are we waiting on?
[11:33] <Z_God> are there bugs?
[11:33] <@Xu_R> SlavekB: are there still problems, even on gcc 4.7.1?
[11:33] <@kb9vqf> Every now and again I hear reports of regressions from the mailing lists
[11:34] <Z_God> but that's about the nightlies mostly I suppose
[11:34] <SlavekB> I have no where to test 4.7.x
[11:34] <@kb9vqf> 3.5.13 won't build on 4.7.1
[11:34] <@kb9vqf> or any gcc >= 4.7.x
[11:34] <SlavekB> So, incorporate patches. :)
[11:34] <Z_God> or use an older compiler for the release
[11:34] <@kb9vqf> Z_God is right
[11:34] <@Xu_R> oic.
[11:34] <@Xu_R> yes, then force an older compiler for now.
[11:34] <@kb9vqf> too much patching and we risk introducing bugs again
[11:35] <@kb9vqf> R14 is where the build problems are being addressed
[11:35] <@Xu_R> ok
[11:35] <SlavekB> In any case - all the packages I have also tested on Precise.
[11:35] <Z_God> will there be mention of this release as R13.1 or smth somewhere as well or just 3.5.13.1?
[11:35] <MutantTurkey> will 3.5.13.1 have a precise release?
[11:35] <MutantTurkey> because people have been asking
[11:35] <SlavekB> Yes, I plan to prepare it.
[11:36] * kb9vqf doesn't know how well that will work, as 3.5.13 won't build on Precise due to many system library changes
[11:36] <@kb9vqf> But you can definitely try :-)
[11:36] <Z_God> 3.5.13 oneiric installs with some hacks on precise
[11:36] <MutantTurkey> 6 months is too short of a cycle.
[11:37] <@kb9vqf> My thoughts exacrl
[11:37] <@kb9vqf> *exactly
[11:37] <@Xu_R> kb9vqf: I haven't kept up with what Ubuntu's done; what system library changes? :/
[11:37] <MutantTurkey> instead of focusing on improving and stabilizing the current release they focus on the next one...
[11:37] <SlavekB> All packages mentioned on SRU etherpad I have already tested on Precise.
[11:37] <@kb9vqf> Good!
[11:37] <@kb9vqf> I had run into problems with the stock 3.5.13 builds on Precise
[11:37] <@kb9vqf> looks like you fixed them
[11:37] <Z_God> what would be needed for a live-cd with precise & trinity?
[11:37] <SlavekB> I have a few fixes for build-deps
[11:38] <Z_God> it would be the new LTS ubuntu with trinity, I'd really like to see that
[11:38] <@kb9vqf> I have an automated CD builder mostly developed here, but I am waiting for the newest LibreOffice release with TDE support (3.6)
[11:38] <MutantTurkey> me too - i intend to upgrade when support is available
[11:38] <@kb9vqf> MutantTurkey: If you look at our past releases we seem to have settled on a ~1 year release cycle
[11:38] <MutantTurkey> kb9vqf: that is in it's 2nd beta correct?
[11:38] <MutantTurkey> kb9vqf: that seems more sane
[11:38] <Z_God> kb9vqf: great! that'll be fantastic
[11:39] <@kb9vqf> Honestly I haven't kept up to date with the release schedule of LO, but when 3.6 hits Debian Wheezy I can build a LiveCD.
[11:39] <MutantTurkey> kb9vqf: we want to support 12.04 for as long as it's supported right?
[11:39] <@kb9vqf> Yes
[11:39] <MutantTurkey> though as long as slackware is around we will be supporting stuff in the dark ages :p
[11:39] <@kb9vqf> Note that we still support Lucid
[11:39] <@kb9vqf> and it is many years old now
[11:39] <MutantTurkey> right
[11:39] <Z_God> but still supported
[11:39] <Z_God> I still install lucid with trinity now on new boxes...
[11:40] <@kb9vqf> I am seeing very little incentive to upgrade past Natty due to GTK  3.0
[11:40] <MutantTurkey> what is the trouble with that?
[11:40] <@kb9vqf> Ugly as all get out
[11:40] <MutantTurkey> I mean other than the obvious pita of dealing with it.
[11:40] <@kb9vqf> yes, that
[11:40] <@kb9vqf> :-)
[11:40] <MutantTurkey> do we do a gtk3 theme engine and picker?
[11:41] <@kb9vqf> No one has developed either of those for any toolkit
[11:41] <MutantTurkey> the problem is we need a better way to do this than preloading kgtk.so
[11:41] <@kb9vqf> i.e. Qt4 doesn't have it either
[11:41] <MutantTurkey> kde seems to have just written native gtk themes that match the KDE4 default theme.
[11:41] <Z_God> I think the focus should be on Qt4 theming for the R14 release
[11:41] <@kb9vqf> GTK3.0 has something like three working themes and one of those is Oxygen
[11:41] <@kb9vqf> Z_God is correct
[11:41] <Z_God> and GTK3 maybe for a later release
[11:41] <@kb9vqf> Dunno...GTK3 is a mess
[11:42] <MutantTurkey> yep
[11:42] <@kb9vqf> I won't do it, but if someone wanted to I would welcome the effort ;-)
[11:42] <MutantTurkey> kb9vqf: is it worth mentioning qt5?
[11:42] <@kb9vqf> I know about Qt5
[11:42] <@Xu_R> I think we can deal with GTK3 later. Qt (any version) is what we should stay with.
[11:42] <MutantTurkey> i know about it too... do we have any course of action for it?
[11:42] <@Xu_R> Qt5... I should hope it's not as much a change as Qt3->Qt4 was.
[11:43] <@kb9vqf> If Nokia goes fully to QML (i.e. dumps widgets entirely) then TQt3, Qt4, and GTK 2/3 will be the only plaforms for developing native desktop applications
[11:43] <@kb9vqf> Scary, huh?
[11:43] <Z_God> is Qt still done by Nokia?
[11:43] * kb9vqf refuses to program complex desktop apps in....javascript
[11:43] <Z_God> I think they sold parts and sacked loads of people
[11:43] <MutantTurkey> I totally agreee wit hthat.
[11:44] <@Xu_R> kb9vqf: I still find QML + JS ridiculous... but what can you do >.<
[11:44] <MutantTurkey> with 'that
[11:44] <@kb9vqf> Not use it?
[11:44] <@kb9vqf> :)
[11:44] <@Xu_R> true ;)
[11:44] <@kb9vqf> Z_God brings up a good point; Qt is now its own project loosely tied to Nokia
[11:44] <MutantTurkey> kb9vqf: you can still hard code it though right?
[11:44] <@kb9vqf> As of now, yes
[11:44] <Z_God> I don't know if more people could communicate with Qt devs from here
[11:44] <@kb9vqf> Qt6 may not
[11:44] <Z_God> I added some on G+ they seem friendly
[11:44] <MutantTurkey> Z_God: well looks can be misleading
[11:45] <Z_God> so far they were also polite when I pointed out a problem
[11:45] <@kb9vqf> As long as they keep QWidget and friends we can theoretically use Qt4 for smaller applications and theme it
[11:45] <Z_God> although minor
[11:45] <Z_God> problem^
[11:45] <MutantTurkey> and is there any course of action for network-manager? (sorry while were are talkin about deprecated items)
[11:45] <MutantTurkey> nm seems to have gone the way of the crapper with its quality
[11:45] <@kb9vqf> If they go fully to QML then we will have at least three incompatible toolkits with different theming :-/
[11:45] <@Xu_R> :/
[11:45] <@kb9vqf> nm stinks right now
[11:46] <MutantTurkey> wicd works well!
[11:46] <Z_God> nm-applet works fine here, it's just GTK3
[11:46] <@kb9vqf> nm-applet won't even show its tray icon unless you run Unity
[11:46] <samelian> MutantTurkey: i plan to make a NM client from scratch
[11:46] <MutantTurkey> kb9vqf: yeah what the heck is that?
[11:46] <MutantTurkey> samelian: really?
[11:46] <samelian> when I will done with polkit
[11:46] <samelian> yes
[11:46] <MutantTurkey> okers
[11:46] <MutantTurkey> okay'
[11:46] <@kb9vqf> cool.  Will you use a UI similar to knetworkmanager?
[11:47] <@kb9vqf> (many users here loved the old knetworkmanager UI)
[11:47] <samelian> not sure yet, I found the KNM a little unfriendly
[11:47] <samelian> well, we can discuss this
[11:47] <@kb9vqf> Its power was in the two-clicks-to-connect idea
[11:47] <Z_God> kb9vqf: I wish I could track Qt5 development, but I really do not have enough technical knowledge, it would be good if there would be more interaction though from the Trinity side
[11:47] <@kb9vqf> The wizards were not so good
[11:47] <samelian> I want to made something more controllable
[11:48] <MutantTurkey> something with good vpn support would be nice
[11:48] <samelian> sure, I intent to implement completely support
[11:48] <@kb9vqf> Z_God: I am still a bit unhappy with Qt >= 4; last I checked they were STILL shipping bugs in the latest Qt4 release.  At this point release that is inexcusable.
[11:48] <samelian> I will follow closely the NM APO
[11:48] <samelian> API
[11:48] <@kb9vqf> be warned it will probably change again...
[11:49] <Z_God> kb9vqf: are the bugs reported in their tracker or are the kind of considered features?
[11:49] <Z_God> they*
[11:49] <@kb9vqf> I was waiting to do something similar until NM hit 1.0
[11:49] <@kb9vqf> but if you want to do it please go ahead :-)
[11:49] <Z_God> the Qt devs hang out on IRC, they don't mind discussing things it seems
[11:50] <@kb9vqf> Z_God: I haven't used Qt4 in some time, but the bugs I am referring to are in their bugtracker, as those developers affected by them complain loudly about them ;-)
[11:50] <@kb9vqf> I don't think I was clear though
[11:50] <Z_God> kb9vqf: ok, but do you think you could somehow steer Qt5 development a bit or at least somehow research could be put into it?
[11:50] <@kb9vqf> The major problem I have with Qt4 is that it releases very, very quickly
[11:51] <MutantTurkey> kb9vqf: what is the status of with Qt4 and trinity?
[11:51] <Z_God> it seems it'll be important to have good knowledge on Qt5 in any case either because it will somehow be useful or to be able to explain why not
[11:51] <@kb9vqf> Z_God: Possibly.  Honestly, I don't have much time, but if they at least keep the widget class framework Qt5 will still be usable
[11:51] <@Xu_R> we have theming between TQt3 and Qt4 now, correct?
[11:51] <@kb9vqf> Xu_R: This ties in with my previous comment about Qt4's fast release cycle
[11:52] <@kb9vqf> Theming worked on Qt 4.7, but gives foolishly large widgets on Qt 4.8
[11:52] <Z_God> kb9vqf: yeah, I understand time is the issue, I will see of I can ask them about this in particular
[11:52] <@kb9vqf> I haven't had a chance to see what changed from 4.7 to 4.8 ye
[11:52] <@kb9vqf> *yet
[11:52] <@kb9vqf> Z_God: I know they are really trying to push QML as the Next Best Thing
[11:52] <Z_God> I think Qt5 will be relatively similar to Qt4 regarding applications and porting source
[11:53] <@kb9vqf> Yes, they stated that
[11:53] <Z_God> they mainly want to change the back-end I understand to be able to use newer GPUs properly
[11:53] <@kb9vqf> the question is, if you are not using QML, will you still get any attention in the bugtracker?
[11:53] <@Xu_R> :/
[11:53] <@kb9vqf> we saw this with KDE4
[11:53] <Z_God> I don't know how it will compare to Qt3 regarding speed on such systems for example
[11:54] <@kb9vqf> Z_God: It will probably be faster, but remember that the toolkit was trimmed down to do this
[11:54] <Z_God> I can imagine GPU acceleration may be critical for certain things on newer devices
[11:54] <MutantTurkey> it won't be faster
[11:54] <@kb9vqf> I personally get nervous about relying on a GPU
[11:54] <samelian> kb9vqf: I don't understand why you insist to mix Qt3 with Qt4
[11:54] <MutantTurkey> why do you need a crazy GPU do draw basic widgets?
[11:54] <MutantTurkey> samelian: hasn't that been answered to death?
[11:55] <@Xu_R> o_o GPU for that.. that doesn't make sense at all.
[11:55] <samelian> yeah, forget it :)
[11:55] <@kb9vqf> samelian: Like it or not Qt4 is here to stay on Linux.  We need to do what we can to not step all over each others toes
[11:55] <Z_God> MutantTurkey: because your CPU sucks, eat more battery, etc.
[11:55] <samelian> well, there are a lot gui toolkits, but we don't care about they
[11:55] <@kb9vqf> Very few people have any idea of how to make a GPU though.
[11:55] <samelian> Qt4 is not the successor of Qt3, is something completely different
[11:56] <@kb9vqf> It seems to be going against the FOSS mindset somewhat to rely on a black box that almost no one can recreate
[11:56] <@kb9vqf> just my $0.02
[11:56] * kb9vqf notes that Linux runs on fully open CPU hardware
[11:56] * kb9vqf also notes that there is no open GPU anywhere
[11:57] <@Xu_R> :/
[11:57] <@kb9vqf> Seems we have taken nVidia's generosity a bit too far... :-)
[11:57] <Z_God> makes sense, it would be good to have articles on this on the trinity site
[11:57] <MutantTurkey> we do have open intel drivers and such
[11:57] <@kb9vqf> Drivers, yes.  Hardware, no
[11:57] <MutantTurkey> right
[11:57] <@kb9vqf> Show me even a basic GPU in an FPGA that can run Qt4/5 and I'll shut up :-)
[11:58] <@kb9vqf> s/GPU/open GPU/
[11:58] <@kb9vqf> Anyway, I think we are fairly off topic at this point
[11:58] <Z_God> yes, this could make Trinity a critical part of a free system
[11:58] <samelian> instead to waste our time with Qt4, would be much useful to add glib event loop support to Qt3
[11:58] <@kb9vqf> glib?  why?
[11:59] <samelian> for example, my last conflict with creator of polkit :)
[11:59] <@kb9vqf> do you have a patch for it?
[11:59] <@kb9vqf> if so I would consider adding it
[11:59] <@kb9vqf> I assume that this only allows compatibility with glib, and does not make Qt3 *rely on* glib?
[11:59] <samelian> nope, I this moment I'm trying to write a polkit client using pure dbus calls
[11:59] <samelian> but is very hard
[11:59] <samelian> because is poor documented
[11:59] == SlavekB [~slavek@mail.axis.cz] has quit [Read error: Connection reset by peer]
[11:59] <@kb9vqf> right
[12:00] * kb9vqf hates DBUS
[12:00] <samelian> and David won't to support this effort
[12:00] <@kb9vqf> the idea was OK, but the implementation stinks
[12:00] <samelian> also, qt3 dbus binding is really sux
[12:00] * kb9vqf knows
[12:00] <samelian> a lot small but sever bugs
[12:00] <@kb9vqf> are they in our bug tracker?
[12:00] <@kb9vqf> I can't fix what I don't know about :-)
[12:01] <samelian> nope, I made patches in my kde3 fork
[12:01] == SlavekB [~slavek@mail.axis.cz] has joined #trinity-desktop-meeting
[12:01] <@kb9vqf> we should incorporate those patches
[12:01] <@kb9vqf> can you send a link?
[12:01] <samelian> sure, I will prepare a list
[12:01] <@kb9vqf> thanks!
[12:02] <samelian> some bugs affect my udisks2 backend, and a new discovered one affect polkit client
[12:02] <@kb9vqf> samelian: So this doesn't get lost in the development process, can you file a BLOCKER bug on the bug tracker with the patches attached?
[12:02] <samelian> well, I think is not a blocker actually, because trinity do not use udisks2
[12:03] <@kb9vqf> No, but I am using Blocker to tag things that block the next release (R14), and I want the bugs fixed
[12:03] <samelian> maybe will be a blocker when my polkit agent will be integrated into trinity
[12:03] <samelian> aha, ok then
[12:03] <@kb9vqf> Interestingly enough we seem to be working on some of the same things, but with two completely different approaches
[12:03] <@kb9vqf> this is a good thinkg
[12:03] <@kb9vqf> *thing
[12:03] <samelian> of course :)
[12:04] <@Xu_R> open approaches are good
[12:04] <samelian> as I said on ML, is better two solutions than none
[12:04] <@kb9vqf> right
[12:05] <SlavekB> Can I have some notes for 3.5.13.1?
[12:05] <SlavekB> (I've been away a while...)
[12:05] <samelian> my intent is to modernize kde3 to support latest technologies
[12:06] <@Xu_R> SlavekB: you don't have to ask, just state outright what you want to do with 3.5.13.1 :)
[12:06] <samelian> I think with systemd we will be able to control the OS directly from KDE3/Trinity
[12:06] <samelian> like system services, etc
[12:06] <MutantTurkey> sigh systemd sucks
[12:06] <MutantTurkey> not all systems use it
[12:06] <samelian> well...
[12:06] <@kb9vqf> samelian: This is my intent as well, but I am approaching it from a much lower level
[12:06] <@Xu_R> samelian: how do you interact with systemd? dbus?
[12:07] <MutantTurkey> trinity cannot depend on something that only a few systems use
[12:07] <samelian> Xu_R: I do not interact with systemd yet
[12:07] <MutantTurkey> good old initscripts have worked for almost 40 years.... and suddendly they're not enough?
[12:07] <@Xu_R> samelian: ah, ok.
[12:07] <SlavekB> A couple of errors to solution:
[12:07] <SlavekB> MutantTurkey yesterday reported a problem in Oneiric
[12:07] <SlavekB> kdm_greet hangs on reboot/shutdown from kdm - see bug 1068
[12:07] <@kb9vqf> MutantTurkey: Well, upstart has decreased boot times and increased reliability, so I think it was a good idea
[12:07] <samelian> MutantTurkey: the idea behind systemd is to parallelize the startup
[12:08] <samelian> i think systemd support the old init scripts too
[12:08] <@kb9vqf> The major issue I have with many of these newer technologies is that the API is almost constantly changing, and also that they do not provide C bindings, instead exposing undocumented DBUS interfaces
[12:09] <samelian> well, I like dbus actually
[12:09] <@Xu_R> SlavekB: I marked that on the Etherpad :)
[12:09] <samelian> because is toolkit agnostic
[12:09] <SlavekB> language files in kaffeine - see bug 858 => perhaps related to this: Switch application language does not work at all
[12:09] <samelian> and permit asyncrounous operations
[12:09] <@kb9vqf> Well, I don't care for it personally
[12:09] <@kb9vqf> too bulky
[12:09] <@Xu_R> noted that bug.
[12:09] <@kb9vqf> every time I sit down and say "I want to use DBUS in this application" I regret it several days later
[12:09] <SlavekB> big problems with kgtk-qt3 - with LD_PRELOAD in startkde
[12:10] <samelian> is a little to hard to handle dbus errors, but it's ok so far
[12:10] <SlavekB> Xu_R: Thanks, I see it :)
[12:10] <@Xu_R> just wondering... is that kgtk hack bascially dead with gtk3 now?
[12:10] <@kb9vqf> yes
[12:10] <Z_God> SlavekB: maybe it would be good to disable the GTK intregration stuff is this prevents issues with for instance precise
[12:10] <MutantTurkey> completely
[12:10] <Z_God> better something ugly than broken
[12:11] <MutantTurkey> yeah
[12:11] <MutantTurkey> users can still pick regular gtk themes
[12:11] <MutantTurkey> so
[12:11] <MutantTurkey> not ap roble mthere
[12:11] <@kb9vqf> I would suggest detecting gtk == 2 and only enabling integration for that version
[12:11] <MutantTurkey> not a problem there.
[12:12] <eliddell> What would detection do to a system with both GTK2 and GTK3?
[12:12] <@kb9vqf> OK, detect GTK3 and disable integration
[12:13] <SlavekB> I would like to blow LD_PRELOAD from starttde / startkde.
[12:13] <samelian> kb9vqf: trinity's kdm is patched for consolekit support?
[12:13] <@kb9vqf> samelian: No idea
[12:13] <samelian> aha
[12:13] <samelian> I found a patch in fedora 9
[12:13] <@kb9vqf> My point is that some folks like myself will stay on GTK 2 systems purely for the integation
[12:13] <samelian> and seems ok
[12:13] <@kb9vqf> what does this do for TDE?
[12:14] <samelian> for example, will working polkit agent
[12:14] <@kb9vqf> OK, this is a good object lesson
[12:14] <@kb9vqf> Nice new technology, right?  Just add support and get new features?
[12:14] <@kb9vqf> Oops, deprecated: http://www.google.com/url?sa=t&rct=j&q=consolekit&source=web&cd=1&ved=0CFMQFjAA&url=http%3A%2F%2Fwww.freedesktop.org%2Fwiki%2FSoftware%2FConsoleKit%2F&ei=UzHrT-vrHaby2QW0-r2gAQ&usg=AFQjCNH3CKzsvsrlmkkojWygFRbErtLkXQ&cad=rja
[12:15] <@kb9vqf> Sorry, www.freedesktop.org/wiki/Software/ConsoleKit/
[12:15] <samelian> yes, I know
[12:15] <@Xu_R> consolekit was deprecated and replaced with... systemd, right? >_>
[12:15] <@kb9vqf> Linux is only hurting itself this way
[12:15] <samelian> but I think the same API will be implemented in systemd
[12:15] <eliddell> And systemd is never going to be universal.
[12:15] <SlavekB> it would be good to have a package pinentry-qt / pinentry-tqt.
[12:15] <@kb9vqf> By the time someone implements support for something it is deprecated and thrown out
[12:16] <@kb9vqf>  /rant
[12:16] <MutantTurkey> sigh it is true
[12:16] <@Xu_R> It does seem that way... >.>
[12:16] <samelian> well, we need to live with this :)
[12:16] <@Xu_R> /sigh
[12:16] <eliddell> Alas...
[12:16] <MutantTurkey> so the solution is to stop dealing with abstract crap
[12:16] <@kb9vqf> samelian: But who pays for it?
[12:16] <MutantTurkey> kernel doesn't change so easily
[12:16] <@kb9vqf> Software development is not free
[12:16] <samelian> developers, of course :)
[12:16] <MutantTurkey> deal as directly as possible
[12:17] <@kb9vqf> MutantTurkey is right IMHO
[12:17] <@kb9vqf> that's why I took the approach I did regarding the HAL replacement
[12:17] <MutantTurkey> and the thing is - every one of these tools uses the kernel in the end
[12:17] <MutantTurkey> other than dbus lol
[12:17] <@kb9vqf> and I will probably do something similar for network management
[12:17] <MutantTurkey> if we can do directly - do directly
[12:18] <MutantTurkey> don't do easy, do right!
[12:18] <samelian> but what about authorizations?
[12:18] <@kb9vqf> I have also found tools that directly access procfs to be much faster than those using DBUS
[12:18] <SlavekB> For Precise is available only pinentry-gtk and pinentry-qt4 - neither is a good choice to Trinity.
[12:18] <@kb9vqf> samelian: I would say to use the standard Linux permissions
[12:18] <samelian> these days is not enough, IMHO
[12:18] <@kb9vqf> if anything the run-as-root master daemon model introduces security holes
[12:18] <samelian> we need more granular policies
[12:19] <@kb9vqf> yes, but that should be done at the kernel level
[12:19] <@kb9vqf> not in userspace
[12:19] <@kb9vqf> e.g. extended ACLs in procfs
[12:19] <MutantTurkey> this i what I have been saying
[12:19] <@kb9vqf> anyway, as I said before we are working on two different approaches--time will tell which one is better/more maintainable
[12:20] <samelian> sure
[12:20] <@kb9vqf> it may be that both work just fine :-)
[12:20] <MutantTurkey> which one gets deprecated faster...
[12:20] <@kb9vqf> basically :-)
[12:20] <@Xu_R> ^
[12:20] <@kb9vqf> but that is winning the lotto with Linux these days
[12:20] <@kb9vqf> Torvalds could have a bad cup of coffee and get rid of procfs tomorrow
[12:20] <@kb9vqf> who knows ;-)
[12:20] <samelian> haha
[12:21] <SlavekB> One more note for 3.5.13.1: how about patch "Fix mimetype detection is Incorrect, some files appear as Unknown"?
[12:21] <@kb9vqf> I think the general consensus was that increasing the buffer size helps somewhat, but TDE should really use the mime detection library from the system
[12:22] <@kb9vqf> That has not yet been done
[12:22] <SlavekB> And wait for it, or incorporate this patch into the 3.5.13?
[12:23] <SlavekB> Or leave it as it is?
[12:23] <@kb9vqf> Leave as-is
[12:23] <SlavekB> Ok.
[12:23] <@kb9vqf> I don't know how much of a rewrite is neeed to use the system library
[12:24] <SlavekB> Also, I do not know.
[12:24] <samelian> well, seems that this meeting do not follow the topics :)
[12:24] <@kb9vqf> not at all
[12:24] <@Xu_R> XD
[12:24] <@kb9vqf> let's get back on track... :-)
[12:24] * kb9vqf will be back shortly
[12:24] <@Xu_R> we're still kinda on topic, tbh
[12:25] <@Xu_R> 3.5.13.1... last thoughts anyone?
[12:25] <MutantTurkey> hip hip!
[12:25] <MutantTurkey> hooray
[12:25] <Z_God> mention R13.1 maybe
[12:25] <@Xu_R> but wouldn't we have to code that into Trinity?
[12:25] <Z_God> to clear certain confusion in advance for the next release
[12:25] <@kb9vqf> No renaming 3.5.13.x to R13 in this SRU
[12:25] <@kb9vqf> That will introduce problems
[12:25] <Z_God> I mean just a mention in the notes
[12:26] <SlavekB> What to do: Switch application language does not work at all?
[12:26] <@kb9vqf> OK :-)
[12:26] <@kb9vqf> Bug number?
[12:26] <Z_God> or maybe R13.0.1
[12:26] <Z_God> I don't know
[12:26] <SlavekB> Sorry, I must just write it :(
[12:26] <@kb9vqf> Z_God: How about "3.5.13.1 [R13.0.1 in the new TDE version scheme]"
[12:27] <@Xu_R> *R13.1
[12:27] <Z_God> kb9vqf: yep, exactly
[12:27] <@kb9vqf> Yes, Xu_R is right
[12:27] <Z_God> but maybe a decision needs to be made which digit is reserved for what in the version number
[12:27] <@kb9vqf> this is a major point release
[12:27] <Z_God> ok
[12:27] <SlavekB> Previously, we have agreed on naming 3.5.13.1
[12:27] <@kb9vqf> the 'z' field in the Rx.y.z scheme is a patch level, implying no ABI breakage
[12:28] <@kb9vqf> SlavekB: Yes
[12:28] <@kb9vqf> That is what we will use
[12:28] <@Xu_R> officially, it is still 3.5.13.1, as this release still uses the old version system.
[12:28] <@kb9vqf> Z_God is just saying that we should mention what the equivalent version is in the new scheme
[12:28] <@kb9vqf> (in the release notes)
[12:28] <@Xu_R> ah, ok. that would be good as a transition for when we annouce R14.
[12:29] <SlavekB> In the new scheme I would see it as R13.0.1.
[12:29] <@kb9vqf> Why?
[12:29] <@kb9vqf> Is the ABI 100% compatible with 3.5.13?
[12:29] <SlavekB> Yes.
[12:29] <@kb9vqf> Oh, ok
[12:30] <@kb9vqf> then yes, R13.0.1 is correct
[12:30] <MutantTurkey> R14 R15 R16 each one represents what was to represent a single point release from 3.5.X
[12:30] <MutantTurkey> so 3.5.14 would be R14 and R15 would be 3.5.15
[12:30] <MutantTurkey> so wouldn't just R13.1 imply a minor version bump?
[12:30] <@kb9vqf> Right, major revisions of the software.  That implies heavy ABI and API changes
[12:30] <MutantTurkey> isn't that what an SRU is/
[12:30] <MutantTurkey> ?
[12:30] <MutantTurkey> a minor version
[12:30] <@kb9vqf> I don't know
[12:31] <@kb9vqf> we need to set some rules on this I guess
[12:31] <SlavekB> I understand the "sru" as a "patch" version.
[12:31] <@Xu_R> is it just MAJOR.MINOR or is it MAJOR.MINOR.PATCH?
[12:31] <@kb9vqf> The latter
[12:31] <@Xu_R> then it's 13.0.1
[12:31] <@kb9vqf> SlavekB: You have not introduced any new functionality, correct?
[12:32] <SlavekB> Correct.
[12:32] <@kb9vqf> Then 13.0.1 would seem to be most appropriate
[12:32] <@Xu_R> then it is indeed a patch.
[12:32] <SlavekB> If anything, the little things.
[12:32] <@kb9vqf> Honestly I don't see us incrementing the Minor version very often
[12:32] <@kb9vqf> but I am leaving it there in case we end up not releasing a major verison for an extended period of time
[12:32] <@Xu_R> ok
[12:33] <@kb9vqf> the Minor version would be bumped if the ABI breaks or if new functionality was added
[12:33] <Z_God> there have been patch releases in KDE3 history with minor features added
[12:33] <SlavekB> So for the R14 I would prepare R14.0.1 ;)
[12:33] <@kb9vqf> the Major version gets bumped only when significant development work has gone into TDE, the API, ABI have changed, and new features have been added
[12:33] <@kb9vqf> SlavekB: Correct
[12:34] <MutantTurkey> someone write that down...
[12:34] <@Xu_R> noted.
[12:34] <Z_God> they were fully backwards & forwards compatible though, I think it happened in the 3.5 serie
[12:34] <@Xu_R> on etherpad.
[12:34] <@kb9vqf> We decided not to restrict the project with that kind of compatibility
[12:34] <SlavekB> MutantTurkey: What about the issue that you reported yesterday?
[12:34] <MutantTurkey> kdesktop is not functioning properly.
[12:34] * kb9vqf will be back a bit later
[12:34] <MutantTurkey> i have not tested it in a new user though
[12:35] <MutantTurkey> kb9vqf: you should drop by more often...
[12:35] <Z_God> kb9vqf: just saying that because you wrote "or if new functionality was added"
[12:35] <@Xu_R> ok. 3.5.13.1 discussion finished? We'll be moving onto R14 discussion.
[12:35] <@kb9vqf> Z_God: Well, bumping the minor version indicates that the ABI might be broken, it does not guarantee it
[12:35] <SlavekB> Well - I'll try to create there a test machine with Oneiric.
[12:36] <Z_God> kb9vqf: ok :)
[12:36] <SlavekB> Still perhaps: How do I name the package?
[12:37] <SlavekB> I still hold the original name 3.5.13 with my ax_number_
[12:37] <@Xu_R> SlavekB: will that upgrade cleanly to original name with 3.5.13.1?
[12:38] <SlavekB> original names contain svn revision number
[12:39] <SlavekB> For example: kdebase 3.5.13-0debian9+r1261450+pr19~squeeze
[12:39] <@Xu_R> oh... :/ yikes... what's higher than that in debian version logic?
[12:39] <SlavekB> now they have: 3.5.13-0debian9+r1261450+pr19~squeeze+ax16
[12:39] <@Xu_R> w/o the revision... maybe include the git has somehow?
[12:40] * Xu_R has no suggestion - he thinks debian versions are really weird
[12:41] <@kb9vqf> SlavekB: Try 3.5.13-1debian*
[12:41] <SlavekB> So I wanted to know whether the new name can be simply 3.5.13.1-buildnumber~squezee
[12:41] <@kb9vqf> Introducing the point might cause a problem
[12:41] <SlavekB> kb9vqf: 3.5.13. >1
[12:41] * kb9vqf seems to remember a way that you could test the "greater than" logic from the command line
[12:42] <@kb9vqf> If I remember correctly, for this to work '.' would need to be greather than '-'
[12:43] <SlavekB> I'll try it.
[12:43] <@kb9vqf> I think this is the command: dpkg --compare-versions "version1" gt "version2"
[12:44] <SlavekB> And what about those: r1261450+pr19 ?
[12:45] <@kb9vqf> you will need to incrememnt the 3.5.13-x portion
[12:46] <@kb9vqf> so 3.5.13-1-ubuntu-4-foobar would become 3.5.13-2-ubuntu-0-newstring
[12:46] <@kb9vqf> anyway, we should probably continue with the meeting topics
[12:46] <@kb9vqf> Xu_R: Next topic?
[12:46] <@Xu_R> R14 Release Goals/Progress (Going Forward)
[12:47] <@kb9vqf> Bugs, bugs, bugs
[12:47] <@Xu_R> gcc 4.7.1 seems to have fixed many bugs we had with 4.7.0
[12:47] <@kb9vqf> I want to see most of the Critical bugs and all of the Blocker bugs fixed before R14 is released
[12:47] <@Xu_R> we need a list of packages that are building good post-rename
[12:47] <@kb9vqf> AFAIK all are building
[12:47] <@Xu_R> ok
[12:47] <@kb9vqf> the build failures on the list are unrelated to the rename
[12:48] <@kb9vqf> I have successfully built everything in the nightly builds
[12:48] <@kb9vqf> so we're close, but the bugtracker does need some attention still
[12:48] <@Xu_R> outstanding images/branding?
[12:48] <@kb9vqf> Darrell would know
[12:48] <@kb9vqf> that won't block release though
[12:48] <@Xu_R> that won't.
[12:49] <@kb9vqf> well, actually it might, but I think most of the problems have been fixed
[12:49] <@kb9vqf> besides, changes to images can be committed at the eleventh hour
[12:49] <@kb9vqf> i.e. they won't break builds
[12:49] <eliddell> We hope. ;)
[12:49] <@kb9vqf> hehe
[12:49] <@kb9vqf> If they do something is VERY wrong
[12:49] <@Xu_R> categorization of menu, svg artifact rendering strangeness
[12:50] <@Xu_R> Upstream Chanages with TDE impact? (aka, udev, hal, udisks2, etc)
[12:50] <@kb9vqf> I added some notes
[12:50] <eliddell> I need a copy of the SVG file that was demonstrating the artefact to trace that further.
[12:50] <@kb9vqf> Basically, we know HAL is on its last legs now
[12:50] <@kb9vqf> udev should exist with the same API (i.e. minimal impact)
[12:50] <@kb9vqf> udisks2 we don't rely on, but samelian will be affected by this
[12:51] <@Xu_R> ok
[12:51] <@kb9vqf> A priority should be to ship a hal-free TDE with R14.0
[12:51] <SlavekB> By the way, package koffice-i18n-trinity is missing. And so k3b-i18n-trinity.
[12:51] <@kb9vqf> in the nightly builds?  I know :-)
[12:51] <@kb9vqf> We NEED people to test the HAL-free versions of TDE from GIT
[12:51] <SlavekB> No - have never been.
[12:52] <@kb9vqf> oh, ok
[12:52] <@kb9vqf> SlavekB: File a Blocker bug report on this please, with the location of the latest i18n files for those applications
[12:53] <SlavekB> kb9vqf: Ok
[12:53] <@kb9vqf> Because of recently reported rapid HAL degredation we will need to ship a HAL-free TDE with R14.0
[12:53] <@kb9vqf> This puts some pressure on the new code in GIT
[12:53] <@kb9vqf> and it needs to be tested/fixed
[12:54] <@Xu_R> which brings us to the next topic... how are we going to do a testing period?
[12:54] <@kb9vqf> One month minimum
[12:54] <@kb9vqf> It will be announced
[12:54] <@Xu_R> will there be a freeze and a rally for bugs?
[12:54] <@kb9vqf> Rally for bugs first, then freeze for testing
[12:54] <@Xu_R> ok
[12:54] <@kb9vqf> At least I think that makes sense :-)
[12:55] <@kb9vqf> Would anyone be willing to have a bug day soon?
[12:55] <@kb9vqf> I want to see those critical bugs squashed
[12:55] <@kb9vqf> (at least a majority of them)
[12:55] * kb9vqf listens to the crickets chirping in the channel
[12:55] <@Xu_R> I've got a TDE VM that I can test with.
[12:55] <@Xu_R> :P
[12:56] * Xu_R chirps
[12:56] <@kb9vqf> anyone else?
[12:56] <@kb9vqf> TDE can't release until those bugs are dealt with, and it will take some time for me to do so my myself
[12:56] <@Xu_R> :/
[12:57] <@Xu_R> we should also try to get more people on IRC
[12:57] <@Xu_R> (I mean, look at our meeting right now >.>)
[12:57] <@kb9vqf> I count 24 idling on the main #trinity-desktop channel right now
[12:57] <@Xu_R> hm... and usually not that many active.
[12:58] <@kb9vqf> OK, bugs will have to be handled by me
[12:58] <@kb9vqf> Release may be pushed to Winter 2012, but that's not such a bad thing I guess
[12:58] <@kb9vqf> (I am factoring in a sizable Q/A period)
[12:58] <@Xu_R> ok
[12:59] * kb9vqf notes that means Quality Assurance, not Questions and Answers ;-)
[12:59] <@Xu_R> I know ;)
[12:59] <@kb9vqf> Next topic I guess
[13:00] <schreiberstein> I don't want to disturb your talk, but I can do some beta testing on wheezy if you like. Maybe it'll help to find some bugs or to test if everything works correctly without hal.
[13:00] <@kb9vqf> schreiberstein: That would be helpful
[13:00] <@Xu_R> ok... last topic... final thoughts, future milesotnes, kudos, etc?
[13:01] <@kb9vqf> schreiberstein: You would need to compile tdebase with TDE HW library support enabled, can you do this?
[13:01] * Xu_R has another meeting now, so he will not be as active on this now
[13:01] <@kb9vqf> schreiberstein: Also remember to install kpowersave-nohal-trinity instead of kpowersave-trinity ;-)
[13:02] <@kb9vqf> Regarding the last topic, we have already hit some milestones
[13:02] <SlavekB> Due to planned release of TDE and Wheezy I did not intend to prepare 3.5.15.1 for Wheezy.
[13:02] <@kb9vqf> Good idea
[13:02] <@kb9vqf> We now have a base toolkit (TQt3) that doesn't collide with Qt4 or future Qt versions
[13:02] <schreiberstein> kb9vqf: i never compiled tee or kde3 + i never built packages on debian. But i know about the build process and i know something about linux from scratch.
[13:02] <schreiberstein> *tde
[13:02] <@kb9vqf> schreiberstein: All you have to do is pull the tdebase sources with 'apt-get source tdebase-trinity'
[13:03] <@kb9vqf> then modify debian/rules with the required CMake flag
[13:03] <@kb9vqf> then 'dpkg-buildpackage -rfakeroot'
[13:03] <@kb9vqf> you will see a bunch of new .deb files when the build is done
[13:03] <@kb9vqf> install those :-)
[13:03] <@kb9vqf> oh, and before you do this, you may want to 'apt-get build-dep tdebase-trinity'
[13:04] <schreiberstein> ah ok. so the hal-free trinity is in nightly build deb-src?
[13:04] <@kb9vqf> The flag is -DWITH_TDEHWLIB="ON"
[13:04] <@kb9vqf> schreiberstein: Yes
[13:04] <schreiberstein> nice.. ok I'll try
[13:04] <@kb9vqf> be aware that it won't work unless your user has r/w access to certain files in procfs
[13:05] <@kb9vqf> so if it fails, try running it with tdesudo for testing
[13:05] <@kb9vqf> I haven't figured out the best way to set the permissions in procfs yet
[13:06] <schreiberstein> couldn't one simply do a chmod -R 777 /proc ? or is it different from /dev in that way?
[13:06] <@kb9vqf> You probably could, but that would be a Bad Idea
[13:06] <SlavekB> very bad idea
[13:06] <@kb9vqf> Unless of course you want random people snooping through your machine's RAM ;-)
[13:06] <@kb9vqf> You would want to set permissions for the specific device nodes that kpowersave needs
[13:06] <schreiberstein> it's a test machine anyway ;-)
[13:07] <@kb9vqf> Things like the backlight
[13:07] <@kb9vqf> and the CPU governers
[13:07] <samelian> to handle permissions maybe is better idea to use suided helpers
[13:07] <@kb9vqf> *governors
[13:07] <@kb9vqf> samelian: Possibly--I had considered suiding the entire kpowersave application
[13:07] <samelian> hmm, I think this is bad idea
[13:07] <@kb9vqf> but much better would be to use groups
[13:08] <@kb9vqf> samelian: Me too ;-)
[13:08] <@kb9vqf> schreiberstein: For testing just run kpowersave with tdesudo
[13:08] <@kb9vqf> We'll keep working on a good way to grant kpowersave access to the backlight and such
[13:08] <samelian> my idea is to write some daemons controlled via dbus
[13:09] <@kb9vqf> Obviously this got pushed up due to HAL failing
[13:09] <samelian> and the permissions will be handled by polkit
[13:09] <@kb9vqf> samelian: I would rather keep access controls in the kernel
[13:09] <schreiberstein> shall i do this on a real machine or inside a vm? because of the powermanagement
[13:09] <@kb9vqf> schreiberstein: If you have a laptop use that
[13:09] <@kb9vqf> Otherwise we also need testers for the removable device support
[13:10] <@kb9vqf> A real machine would be best, just so that I can get a good cross section of real-world hardware tested
[13:10] <schreiberstein> i don't have one.. but my 2nd pc is an amd machinee featuring an athlon x2 6000.
[13:10] <@kb9vqf> samelian: Correct me if I'm wrong, but can't udev set permissions for procfs on device plug?
[13:11] <samelian> not sure, I think it is possible
[13:11] <@kb9vqf> I would envision there being base system groups as there are already (audio, video, etc.), and the administrator simply granting access to the hardware by adding users to those groups
[13:11] <@kb9vqf> It would also prevent some random user from, for example, suspending the machine.
[13:11] <samelian> this is pretty sux, because you need to logout/login
[13:12] <samelian> to apply new permissions, I mean
[13:13] <@kb9vqf> Well, in my mind it's better than having a daemon suid root that can introduce new attack vectors
[13:13] <@kb9vqf> In my experience as well (with HAL) that daemon introduces a single point of failure
[13:14] <@kb9vqf> if it goes down, everything that relied on it in all sessions goes down as well
[13:14] <samelian> I think this is not a big issue
[13:15] <@kb9vqf> Besides, there are ways around having to log in/out
[13:15] <@kb9vqf> http://superuser.com/questions/134406/linux-refreshing-groups-without-having-to-re-login
[13:15] <@kb9vqf> samelian: In my experience it became a big issue
[13:15] <samelian> if udisks2 is killer for example, systemd will respawn it
[13:15] <samelian> killed*
[13:15] <@kb9vqf> What if it locks up?
[13:15] <samelian> unlikely
[13:15] <@kb9vqf> hehe
[13:15] <@kb9vqf> I'd argue with that
[13:16] <@kb9vqf> we should probably just continue parallel development in this area
[13:16] <@kb9vqf> the users can decide which method they would rather use
[13:16] <samelian> yes, to check the possibilities
[13:17] <@kb9vqf> I just remember many embarrassing moments when HAL froze on multi-user systems
[13:17] <@kb9vqf> Not fun
[13:17] <samelian> the HAL is a giant :)
[13:18] <@kb9vqf> Or when Network Manager failed to properly handle multiple users
[13:18] <@kb9vqf> Personally I think the root daemon is a hack
[13:18] <@kb9vqf> and that the real problem should be fixed in the kernel
[13:18] <@kb9vqf> e.g. add real-time permissions updating
[13:19] <@kb9vqf> Xu_R: I think this pretty much concludes the meeting
[13:19] <@kb9vqf> Thank you all for coming
[13:19] <@Xu_R> it does.
[13:19] <@Xu_R> Thanks all!
[13:20] == samelian [~same@89.114.234.9] has left #trinity-desktop-meeting ["Leaving"]
[13:20] == Xu_R changed the topic of #trinity-desktop-meeting to: done - http://trinity.etherpad.trinitydesktop.org/48
[13:21] == kb9vqf [~kb9vqf@edge.pearsoncomputing.net] has left #trinity-desktop-meeting ["Konversation terminated!"]
[13:21] == SlavekB [~slavek@mail.axis.cz] has left #trinity-desktop-meeting ["Kopete 0.12.5 : http://kopete.kde.org"]
[13:22] == eliddell [~eliddell@d24-235-195-164.home1.cgocable.net] has left #trinity-desktop-meeting []