20:36:16 <ennael> #startmeeting
20:36:16 <Inigo_Montoya> Meeting started Tue Mar 25 20:36:16 2014 UTC.  The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:36:16 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:36:26 <ennael> #chair coling anaselli
20:36:26 <Inigo_Montoya> Current chairs: anaselli coling ennael
20:36:51 <ennael> ok this meeting is not really a packager meeting but a meeting dedicated to drakx* developments
20:37:02 <ennael> as a quick introduction of the pb
20:37:23 <ennael> our strong point is in these tools to help people manage easily their system
20:37:37 <ennael> and we can see it in all reviews including the one for Mageia 4
20:38:07 <ennael> the thing is these tools need some love on technical side (maintain and evolution) but also on design side
20:38:39 <ennael> so what we need is to create a pool of dev guys to take care of it and get some more people involved
20:38:54 <ennael> at the moment we have a git repository for it
20:39:16 <ennael> and... that's nearly all :) (adding documentation for users)
20:39:34 <anaselli> and for further developers ;)
20:39:40 <ennael> so what we need is to create a real dev project
20:40:03 <ennael> with documentation but also advertisement
20:40:29 <ennael> and as we are in the middle of spec discussion we need also to think about a roadmap for coming releases
20:40:39 <ennael> did I forget something ? :)
20:41:08 <coling> Seems to cover the background quite well.
20:41:12 <coling> :)
20:41:18 <anaselli> yes
20:41:46 <ennael> ok :)
20:42:08 <ennael> so we have the "historic" devs: tv, pterjan, blino mainly
20:42:20 <ennael> and new comers : coling, anaselli, pasmatt
20:42:29 <ennael> and maybe some more later :)
20:42:51 <ennael> so in term of tools to work on all this do we need something more
20:42:59 <ennael> we spoke about code review some weeks ago
20:43:50 <philippem> hi just to say that I'm listening but working on the Python readline bug in Cauldron
20:45:36 <coling> Well, from my perspective, I've really done very little with the drakx code over the years. My main motivation is to fix things I've broken (e.g. systemd support in drakxservices+installer, polkit support etc.). I tend not to use the tools much in my daily use, but I do appreciate them. That said, I've got a reasonable high-level overview of how various similar systems work - e.g. all the tools in the GNOME desktop that m
20:45:42 <coling> irror some of the features of our tools.
20:46:06 <coling> And it's from this technical POV that I based my "review" of some of the tools.
20:46:31 <coling> anaselli and pasmatt have done most (all?) of the work on the UI side of things.
20:46:39 <ennael> can you remind us the link here ?
20:46:58 <coling> https://wiki.mageia.org/en/Feature:InstallerAndDrakXReview
20:46:59 <coling> and
20:47:05 <coling> https://wiki.mageia.org/en/Feature:UiAbstraction4mcc
20:47:21 <coling> Now from a public perception perspective, the UI is likely to be more interesting than "how it works behind the scenes".
20:47:41 <ennael> sure
20:48:01 <coling> But there might be more developer interest if the code was using nice interfaces rather than lots of conf-file parsing/writing magic and "shelling out" to tools etc.
20:48:04 <ennael> when I speak about communication it's for users but also devs as any other upstream project
20:48:41 <coling> So I guess I'd still like to see both parts move ahead.
20:49:14 <coling> But I'm really not sure who would be interested in the backend parts. I certainly won't have much time to look at all of it, and some things do have impact on our installer too.
20:49:22 <coling> e.g. like adding users etc.
20:49:58 <coling> So I think we need to make some decisions about the structure of the installer and whether or not it needs to include everything it currently does.
20:50:00 <ennael> well it's also a way to show the dev effort in mageia project
20:50:13 <coling> Some reviews of MGA4 have been slightly critical of the "aging" installer.
20:50:39 <Oro_Valley> I certainly agree it needs a facelift
20:50:43 <ennael> the thing is some configuration tools are duplicated
20:50:50 <coling> I think it's slightly more than a facelift.
20:50:52 <ennael> in installer different from drakxtools
20:50:59 <coling> I think competing/similar projects are going down the route of a simpler installer combined with a "first time wizard" type thing.
20:51:35 <coling> This approach would allow for the classic installer and live installer to be more similar than they are now.
20:51:37 <ennael> coling: well it seems some distribution are leting down such post install wizard
20:51:51 <ennael> suse for example for next version
20:52:10 <coling> leting down? Do you mean not doing it?
20:52:17 <coling> Or pushing it?
20:52:21 <ennael> yep at the moment install is in 2 parts
20:52:27 <ennael> install, reboot and wizard
20:52:38 <ennael> they are working on a one shot install
20:52:40 <anaselli> suse has all in YCP based on libyui or old libyast
20:52:49 <anaselli> all in ruby iiuc
20:52:54 <ennael> yep
20:52:57 <anaselli> also into installer
20:52:59 <ennael> they are migrating all in ruby
20:53:00 <Oro_Valley> install, reboot and wizard has certainly one advantage
20:53:39 <Oro_Valley> you don't need to complete everything just then to find out it doesn't rebbot
20:54:08 <ennael> well imho we should not have "it will not reboot" in mind :)
20:54:15 <coling> The thing is some DE's are also trying to go down the first-time-wizard route - e.g. GNOME has such a system. If we want to offer users a "pure $DE" experience then we should defer to the DE if appropriate (whther it be GNOME, Plasma or whatever)
20:54:37 <coling> Or we could just say "NAK" to such things and always do our own.
20:54:50 <ennael> coling: and what happen for the DE which does not provide it
20:55:07 <coling> ennael, well, that's where "our" version comes in.
20:55:10 <anaselli> ennael: was quicker than me in asking that :)
20:55:17 <ennael> :)
20:55:33 <coling> For me this is very similar to the whole user management, service management, date time control etc stuf.
20:55:40 <anaselli> so coling we should do something anyway
20:55:46 <coling> GNOME and KDE and others have their own, integrated versions.
20:55:59 <coling> Our tools don't really get much of a look in there.
20:56:11 <coling> But I would very much like them to use the same backends whenever possible.
20:56:32 <coling> (which is the essence of what I was trying to suggest in the review page)
20:57:09 <coling> anaselli, well, I would say that if we remove e.g. user creation from the installer, then we should replace it with something to create a user on first boot.
20:57:35 <coling> But if I select a GNOME install and GNOME offers a first boot user creation wizard, we should defer to that, and not inject our own.
20:57:45 <coling> Likewise if KDE/Plasma offered such a thing.
20:57:47 <Oro_Valley> +1
20:58:49 <anaselli> i won't say i don't agree... but so what is the difference between mageia and any other distro that install kde/gnome DE?
20:58:59 <Oro_Valley> diskdrake is another one, why not using GParted
20:59:22 <DavidWHodgins> gparted doesn't create mount points, or update fstab
20:59:35 <coling> Ultimately, the fact is that the DE situation these days is waaaay better than back when our tools were the best thing since sliced bread. The *need* for many of our tools has definitely diminished as a result, and they become more useful on lighter weight DEs that do not include such functionality out of the box.
20:59:47 <pasmatt> coling: then we should start our own user creation tool for all the other wm/de that don't provide those functionalities
20:59:54 <ennael> diskdrake is maybe on of the best tool to manage fs and partitions imho
20:59:58 <anaselli> Oro_Valley: has GParted QT/KDE interface?
20:59:59 <ennael> easy to use
21:00:21 <coling> pasmatt, indeed. I mean if I want to manage users under GNOME, I'll just use the GNOME tools for that (it's built in).
21:00:42 <coling> pasmatt, but if I'm under LXDE, then I would use drakuser.
21:01:15 <anaselli> ennael: and one of the tools people like since mandrake...
21:01:22 <DavidWHodgins> gparted also does not handle lvm logical volumes.
21:01:32 <pasmatt> at the price we lose a uniform look&feel
21:01:43 <coling> pasmatt, and as noted in the wiki page, I'd like to see drakuser use accountservice DBus interfaces for this capability (same as the GNOME tools) so both options are just frontends to the same functionality, and drakuser ceases to be something that just shells out to usermod and friends.
21:02:03 <coling> pasmatt, What do you mean we lose a uniform look&feel?
21:02:56 <pasmatt> drakuser appears the same way within every de/wm
21:02:58 <coling> pasmatt, for the avoidance of doubt, I wouldn't suggest that if you launch drakconf that clicking on "users" would launch the gnome tool.
21:03:05 <anaselli> coling: i think we always found where tools are
21:03:32 <anaselli> and we find them there, if we look for something we can have a look at mcc...
21:04:31 <anaselli> if you know Gnome u can find tools well, maybe as well as if you know kde, but I'm not sure i can find all in kde control panel
21:04:39 <coling> pasmatt, right, I see what you mean, but there is an equally good counter argument there, that if you are in a DE that has taken the time and effort to implement the same functionality, with the UI guidelines of the DE in mind, and we effectively try to replace that with our tools, we also lose the uniform look&feel (but in this case it's the DE's look&feel)
21:04:56 <Oro_Valley> anaselli: we don't even have kde/QT installed when we partition the disk
21:05:27 <anaselli> and that's why we need a drakx review ;)
21:05:31 <coling> pasmatt, and ultimately there should be nothing stopping people using drak* under $DE, but it's likely not the first port of call.
21:06:20 <anaselli> coling: install apart, what do you prevent to use other tools under Gnome/KDE now?
21:06:20 <ennael> ok so this discussion just show imho that we do not have defined goals for now
21:06:30 <ennael> a,d this should be the very first step
21:06:38 <anaselli> ennael: well i think i have some
21:06:52 <coling> So ultimately, as there are now blessed system interfaces for tweaking a lot of the configuration, (users, locale, keyboard, date+time etc) we should use these whenever possible and thus not end up writing weird configuriations that other frontends do not understand.
21:06:53 <anaselli> 1) review our tools
21:06:58 <pasmatt> coling: you're right, it's a matter of pov :)
21:07:51 <anaselli> better using libyui to get qt/gtk and ncurses implementation in one shot
21:08:22 <anaselli> 2) split tool code in two parts whenever possible let's call them
21:08:29 <anaselli> frontend and backend
21:08:47 <coling> So I think overall "goal" of drak* is to be a "DE agnostic, compressive set of utility to configure and manage your system". Overlaps with DE provided utilities is expected and where possible share the same backend code/interfaces.
21:08:51 <anaselli> just to distinguish GUI from low level configuration tool acces
21:10:01 <anaselli> coling: yes (iiuc)
21:10:37 <coling> So I guess the next questions should be how do we get there and how do we get more people interested?
21:11:03 <coling> I would suggest that for the tools that allow it, anaselli and pasmatt could start creating topic/yui branches in git.
21:11:22 <coling> This might help tv interested in reviewing the changes.
21:11:44 <coling> Assuming this is technically viable?
21:11:50 <anaselli> coling: what do you mean by creating topic/yui branches in git.
21:11:54 <anaselli> ?
21:11:58 <ennael> I'd like to see a first long term roadmap with comprehensive and short step so that we can manage it in a usable way for Mageia 5
21:12:21 <pasmatt> coling: agreed for the same backend, not sure how we can overlap the de tools
21:13:27 <pasmatt> anyway I suppose we'll find a way :)
21:13:47 <coling> pasmatt, don't worry about the DE tools too much. Ultimately they will continue to exist and we don't replace them in any way, but we do probably want to replace the backend bits in e.g. drakuser with appropriate calls to accountservice, but that can be done on top of the yui branch.
21:13:58 <anaselli> ennael: the problem in having a roadmap is that i cannot work on this all day long, and since we are only pasmatt and me, there cannot be a deadline
21:14:14 <anaselli> but i think i can give a possible way to
21:14:41 <pasmatt> coling: I'm all for it, I'm all for dbus&co ;-)
21:14:42 <anaselli> e.g. the standalone tools can be ported (for the most)
21:14:51 <coling> anaselli, regarding the git repos, our branch naming strategy allows "topic/fooo" (and "user/anaselli/fooo" branches) for this work, it would make sense to rebase your changes on current git master and push these changes as topic/yui branch.
21:15:07 <coling> ennael, yes, a roadmap would be good.
21:15:10 <anaselli> and can be run and tested without touching nowadays drakx stuff
21:15:41 <coling> ennael, so the question is how far can we get for MGA5.
21:15:52 <ennael> yep
21:16:07 <coling> anaselli, pasmatt do you think a UI conversion of all tools is acheivable for MGA5? If there were more contributors?
21:16:33 <anaselli> coling: the only real fork is libyui-bindings
21:16:48 <coling> I think the backend changes (at least for the ones I identified) would also be possible, but not sure who would do it all! I certainly can't do it all.
21:17:01 <pasmatt> coling: I'm stuck with rpmdragora (humble port of rpmdrake) :)
21:17:07 <anaselli> other ones are just a little forward since i'm the bug fixer
21:17:35 <coling> anaselli, so the libyui-bindings is a fork of the upstream ones right now?
21:17:48 <anaselli> coling: yes i think is doable,
21:17:59 <pasmatt> the smaller tools are easy to port to yui, three of them were already ported by anaselli and me
21:18:10 <anaselli> just because gets also yui-mga plugins, yes coling
21:18:28 <anaselli> but there is a public branch for that called mageia
21:18:34 <coling> anaselli, how forked is it? Is there scope to merge upstream?
21:19:09 <anaselli> coling: nope because i added our file in yui.i for swig
21:19:15 <anaselli> to avoid a new pacakge
21:19:21 <coling> pasmatt, as I kept finding when adding polkit stuff, lots of tools seem to suddently appear whenever you make a change - some I didn't know existed :D
21:19:41 <anaselli> coling: is only that
21:19:49 <coling> anaselli, OK, I don't really know the tech here so don't really know what that means.
21:19:57 <coling> But if it's OK for us to maintain the I guess it's fine!
21:20:22 <anaselli> coling: let's say i included into the officila bindings also our widget extension
21:20:31 <anaselli> by scanning our files
21:21:30 <coling> OK, so that seems OK to me. ennael have you had any opportunity to talk to tv about these changes?
21:22:09 <anaselli> coling: the branch has been done to avoid a lifetime patch... or to build a new package (but that could be change in future) I'm open to discuss :)
21:23:03 <coling> anaselli, it might be nicer to do like we do with initscripts. We ship the fedora sources, but have a big patch for our changes applied (and generated from git)
21:23:05 <DavidWHodgins> One change I'd like to see in mcc. It only shows icons for installed tools. I think it should have a section added with icons for  not installed tools, that can be clicked on, to install those tools. As is, a lot of drakx tools are unlikely to be known about.
21:23:19 <coling> But I don't know the details so wouldn't like to comment.
21:23:27 <anaselli> coling: if think we should have a rebase on our git for my branch i'm fine... just talk later for tech aspects ;)
21:23:38 <coling> anaselli, sure.
21:24:14 <anaselli> coling: it can be done, using a patch i mean, not that hard
21:24:24 <pasmatt> ennael coling while porting stuff like drakservice or drakhost it's somehow "easy", we face a few difficulties when dealing with urpm/gurpm perl modules
21:25:44 <pasmatt> I'll ask much more questions to the mailing list in the next few days :)
21:27:37 <coling> OK, so if we assume the next steps for the UI stuff is to get branches created for the relevant tools and ensure all the needed deps are packaged up nicely in cauldron.
21:27:52 <coling> I guess we also need to have consensus on the backend changes and installer changes.
21:28:05 <coling> If we can agree on the plan we can write a road map.
21:28:22 <ennael> that's why rather mailing zillions of questions the best thing would be to write a global proposal
21:29:05 <coling> I think a global proposal is a good idea, but it needs a "champion" to get it written.
21:29:39 <coling> The problem here is reaching consensus. None of us talking here are really the current maintainers so it makes it very difficult!
21:30:08 <neoclust> coling: thierry should be here to talk about this i think  ( if i understand of what it talks )
21:31:05 <anaselli> so my question is, should we go on as if it were a game and maybe one day we will have something, or there is interested people who can help and than we can plan something also by knowing who can do what?
21:31:07 <ennael> pterjan and blino also
21:31:16 <neoclust> ennael: yes :)
21:31:18 <coling> Well he has replied on the ML, but sadly seems to suggest "enhancing" what we have, but that's a very vague term. Using the same backends as other frontends and having a UI layer that works nicely on curses, Gtk and Qt seems like a good enhancement to me!
21:32:37 <coling> But I suspect that's not what he means!
21:32:53 <anaselli> i see all of them, is a hard work really
21:32:55 <pasmatt> neoclust: definitely :)
21:32:57 <anaselli> coling: :D
21:34:10 <coling> So yeah, if I cannot convince TV that the backend bits are a good idea, I'm certainly not prepared to step up and push it - I just don't have the time even if I think it's technically the correct approach!
21:34:13 <anaselli> but they also understand that when we ask why something works like that or this, and nobody answers...
21:35:22 <coling> Yeah anaselli! It's important to know who to speak to when questions go unanswered.
21:36:16 <anaselli> coling: i think that is  a mined fileld
21:37:21 <anaselli> because if you do something... people call you soon... but if you ask before doing it... than no one is interested but i maybe wrong
21:37:50 <coling> I think that's basically the state we find ourselves in.
21:38:14 <coling> A phrase that sort of fits here is: "It's easier to beg for forgiveness than it is to ask for permission"
21:38:19 <anaselli> anyway i think we can have parallel tools for the coling joy if no one is interested, but i hope that is not the definetely answer :)
21:38:39 <pasmatt> coling: :)
21:39:08 <anaselli> coling: :)
21:39:29 <anaselli> Solbu:  ennael what do you suggest?
21:39:29 <coling> But that's one of the reasons I'd like to see a topic/yui branch against the tools in our git.
21:39:55 <coling> It's the "action" part. It's exposes the work more definitively than it is now.
21:40:11 <coling> Because it's "upstream" (even if it is in a branch).
21:40:39 <neoclust> coling: yes a branch is nice
21:40:54 <coling> So perhaps I should speak to anaselli and pasmatt about the best way to push that forward? That's a good short term goal at least
21:41:23 <anaselli> coling: for the yui libraries and plugins you mean?
21:41:42 <coling> Well, all of it, but I'm thinking mainly the changes to drakuser and drakxservices etc.
21:41:56 <anaselli> coling: but they are in already :)
21:42:06 <coling> Oh are they?
21:42:17 <anaselli> http://gitweb.mageia.org/software/adminpanel/
21:42:18 <[mbot> [ adminpanel - Next Generation Mageia Administration Panel ]
21:42:29 <coling> anaselli, I don't see them here: http://gitweb.mageia.org/software/userdrake/
21:42:30 <[mbot> [ userdrake - Mageia User and Group Management GUI ]
21:43:05 <coling> anaselli, Oh so the adminpanel repo is a full and complete re-implementation with no history?
21:43:12 <anaselli> http://gitweb.mageia.org/software/adminpanel/tree/lib/AdminPanel/Module/Users.pm
21:43:13 <[mbot> [ adminpanel - Next Generation Mageia Administration Panel ]
21:43:46 <anaselli> coling: yes it's re-implemeted because we didn't want to hurt any feelings....
21:43:52 <coling> Ahh OK.
21:44:07 * coling had it in his head you had various branches of the existing bits and made the changes in branches.
21:44:11 <anaselli> and because our mandr* stuff was not so eas to touch
21:44:32 <coling> Right, so as a rewrite I can see it being a "harder sell"!
21:44:59 <anaselli> coling: userdrake is gtk based
21:45:27 <pasmatt> coling: you mean branching yui-mga inside our git?
21:45:28 <anaselli> i can branch it and remove gtk and set yui
21:45:42 <pasmatt> oh network delay, I missed something :-/
21:45:48 <anaselli> but i already cleaned that code (not all reallly)
21:46:28 <coling> pasmatt, no I was meaning branching userdrak to a topic/yui branch but that was just my initial (wrong) assumption about how you guys had been workign (as I've only really followed it from a high level not at a code level)
21:46:53 <pasmatt> fine, there was some network pb by my side, sorry
21:46:56 <anaselli> pasmatt: that can be done, but i think is a double work
21:47:00 <anaselli> for me
21:47:19 <anaselli> not pasmatt i meant coling :D
21:48:30 <anaselli> coling: just a question how can you think to split backend and frontend by branching userdrake?
21:48:55 <coling> anaselli, yeah I'm not sure that my suggestion is really sensible looking at the code.
21:48:59 <anaselli> because atm userdrake is a monolitic file or almost
21:49:15 <anaselli> while i'm doing that already
21:49:18 <coling> anaselli, simply do the work in a branch before merging it.
21:49:37 <coling> anaselli, but as said, I'm not sure this is sensible now.
21:49:43 <anaselli> i just need to share USER (libuser perl wrapper)
21:50:32 <anaselli> well if you can have more people to help... i could do it :)
21:50:44 <coling> anaselli, because I assumed you had created the user part of adminpanel as a (private) branch of userdrake but this was a bad assumption on my part
21:50:47 <pasmatt> damn it :-/
21:51:02 <pasmatt> sorry guys, network pbs :-/
21:51:05 <coling> pasmatt, you didn't miss anything :)
21:51:16 <Kharec> 'evening all
21:51:34 <anaselli> coling: moduels can be separated so yes it can be done... but hows about another module? :D
21:51:47 <pasmatt> coling: adminpanel design allows pre-existing "modules" to be executed without no real yui-integration
21:51:51 <anaselli> so that we don't touch what i have already ported atm?
21:52:29 <Kharec> coling: sorry, I didn't saw that you are the maintainer of redis... I just sent it in Cauldron, I was testing it since a few hourss on my laptop....
21:52:31 <coling> anaselli, well, like I said I'm not really sure my previous suggestion above was sensible considering the history in AdminPanel now.
21:52:59 <coling> Kharec, don't worry about it, feel free to push updates etc. I don't really use it yet (long term plan!)
21:53:14 <Kharec> coling: oh thanks :)
21:53:26 <Kharec> I use it at work, it's pretty funny.
21:54:16 <anaselli> i feel confused :( i maybe too tired
21:54:22 <coling> anaselli, Anyway, as it's quite separate as you say I think getting packages out there and easily installable should be a good goal. The fact it doens't conflict is a bonus here!
21:54:36 <coling> anaselli, basically ignore anything I said about branches!
21:54:51 <coling> anaselli, it was a suggest based on bad assumptions on my part.
21:55:54 <anaselli> coling: atm adminpanel (except rpmdragora that is not completed yet) is managed like cpan based perl code
21:56:02 <anaselli> or at least i tried to :)
21:56:12 <coling> anaselli, FWIW, I think for other modules not yet ported, it makes sense to do it as a branch of existing repositories (for no other reason than being a progression/iteration of existing things rather than a "rewrite" and thus it's politically easier to "sell")
21:56:39 * pasmatt feels guilty for rpmdragora
21:56:48 <coling> Don't feel guilty :)
21:56:51 <anaselli> coling: disk drake is under drakxtool
21:57:16 <anaselli> so a branch would mean not to port only drakxtool
21:57:36 <anaselli> i missed something in this... technically speacking
21:58:04 * anaselli say sorry for his English...
21:58:25 <coling> anaselli, so if you wanted to port that you'd have to start a topic/yui branch of drakxtool and slowly move the code around in the branch.
21:58:41 <coling> anaselli, but drakxtools is very complex as it's basically the installer.
21:59:04 <anaselli> coling: that's why i ported some standalone modules
21:59:10 <anaselli> but alone
21:59:22 <coling> But even if you rip those parts out and only keep diskdrak, it still keeps all the git history which for something like diskdrake is very important.
21:59:28 <anaselli> drakxnet and userdrake could have been
22:00:35 <coling> (I spent a very long time getting all the git repositories with the combined history working because development history is really valuable - and some I even redid for TV recently because e.g. perl_checker was split out from other repos in the past and he really wanted the history all together!)
22:01:34 <anaselli> coling: i see really
22:01:48 <anaselli> what i can't get is how i can branch a file
22:02:43 <anaselli> or all drakx
22:02:58 <anaselli> considering that most are not for standalone
22:03:03 <coling> anaselli, yeah drakxtools and userdrake bits could have been developed in their repos as branches, but I suspect ultimately the diff from beginning to end would be pretty much a full rewrite anyway :D
22:03:25 <coling> anaselli, don't branch a file, you branch a whole repo and you just happen to change a file.
22:03:47 <coling> anaselli, but for drakxtools it would certainly be difficult!
22:04:05 <anaselli> coling: thanks i wanted you there :)
22:05:11 <anaselli> coling: at the very first time we had a branch for it, to try to use interactive and qt implementation
22:05:27 <pasmatt> yep
22:05:29 <anaselli> pasmatt: and I spent almost six months for a try
22:05:43 <pasmatt> anaselli: we spent, pls :D
22:05:46 <anaselli> *without helps*
22:06:02 <coling> Yeah and to be honest, nothing I'm saying hear really matters!
22:06:16 <anaselli> no coling we need you :D
22:06:24 <anaselli> do not leave :p
22:06:28 <coling> (I mean not technically - it's just politically easier :D)
22:06:36 <pasmatt> :)
22:06:50 <coling> Because it's no longer a "rewrite" as such (even tho' that's effectively what it is)
22:06:56 <anaselli> coling: yes our project is since two years
22:07:02 <coling> Indeed.
22:07:11 <anaselli> and that we could do during nights
22:07:19 <anaselli> and starting from scratch
22:07:25 <coling> Anyway, I don't think my talk of branches is really all that productive (or for that matter really matters much!)
22:07:27 <anaselli> no documentations, no help etc
22:08:02 <anaselli> coling: if someone you know is interested we wil port all the log in somwhere :)
22:08:07 <coling> anaselli, I know how hard it must have been (my own adventures to fix up various bits of drakx* are much the same)
22:09:06 <coling> anaselli, if it becomes important, I can work git magic to make it work, but I really think I've taken the discussion on tangent that's not really useful!!
22:09:12 <anaselli> user drake has some bugs i told in bugzilla and mailing list... i removed into spanale User module
22:09:48 <ovitters> there is a lot of freedesktop.org stuff you might be able to rely on
22:09:50 <anaselli> coling: maybe in past
22:09:58 <ovitters> accountsservice, systemd stuff, etc
22:10:05 <coling> ovitters, yup, that's basically what I've already written.
22:10:15 <anaselli> ovitters: not all in perl though
22:10:26 <ovitters> coling: don't make it obvious I don't read
22:10:28 <coling> anaselli, they are dbus services.
22:10:29 <anaselli> perl was onother choice to get helped
22:10:34 <coling> ovitters https://wiki.mageia.org/en/Feature:InstallerAndDrakXReview
22:11:06 <anaselli> coling: yes if someone helps with the backends we can use it
22:11:11 <ovitters> did you also look at gnome-initial-setup ?
22:11:13 <coling> anaselli, the language is basically irrelevent for such f.d.o stuff - they are pretty much universally exposed as dbus services.
22:11:34 <coling> ovitters, yup, mentioned that above too :) Short recap:
22:11:52 <ovitters> someone asked me why I didn't package it.. but that's because IMO there is too much overlap and there should be some thought into all of this
22:12:19 <coling> ovitters, basically I was saying we should maybe rip out user creation stuff from installer and instead defer to a fist boot wizard. If you choose a DE with it's own first-boot thing our version should not be used in favour of it.
22:12:21 <anaselli> i'd prefer coling thogh to avoid open a soket and send raw data hardcoded
22:12:42 <coling> anaselli, not sure what you mean?
22:12:47 <anaselli> i'd prefer to use a frontend that hides that and leaving upstream to fix bug
22:13:08 <pasmatt> coling: it referes to some USER module, am I right anaselli?
22:13:08 <anaselli> using a class to access dbus is better than accessing directly
22:13:49 <coling> pasmatt, I think the USER perl module would be dropped and replaced with DBus calls to accountservice instead.
22:13:58 <coling> s/woudl/should/
22:14:01 <anaselli> i had a look at the user confuguration tool you suggested for gnome
22:14:15 <anaselli> accountservice yse
22:14:44 <anaselli> it has /usr/sbin/adduser hardocoded
22:14:48 <coling> anaselli, Oh yes, you should use the appropriate DBus APIs!! I'd never suggest reimplementing dbus protocols and marshalling etc!
22:15:11 <anaselli> i seem that something USER does is not in accountservice
22:15:50 <coling> anaselli, perhaps yes, but the questions there would be: 1) are they important things we need, or 2) can we implement them in accountservice and push upstream?
22:16:09 <anaselli> coling: does accountservice list all the users?
22:16:09 <pasmatt> I see no problems as long as we are able to interface those tools (our, gnome, kde, etc) to dbus
22:16:37 <ovitters> accountservice is for non-system userids
22:16:38 <coling> pasmatt, yeah, DBus is the defacto IPC
22:16:40 <ovitters> AFAIK
22:17:05 <anaselli> ahah as well as the kde one if recall correctly
22:17:48 <anaselli> coling: the idea is to leave all the USER access here http://gitweb.mageia.org/software/adminpanel/tree/lib/AdminPanel/Shared/Users.pm
22:17:49 <[mbot> [ adminpanel - Next Generation Mageia Administration Panel ]
22:17:49 <coling> anaselli, KDE uses DBus.... there was DCOP but many of the people involved with DCOP were involved with DBus too. DBus today is a given and there is no point discussing IPCs here.
22:18:46 <anaselli> coling: but we should take a decision and maybe provide a pseudo roadmap
22:18:47 <pasmatt> coling: as I said I think we have to go for dbus -absolutely- but I also think we have greater issues working on tools that cannot "talk" to dbus, like rpmdragora :)
22:18:56 <pasmatt> at least for what I know
22:19:03 * anaselli start falling asleep :D
22:19:09 * coling too :)
22:19:26 <anaselli> coling: i see this atm as possible
22:19:55 <anaselli> porting as much as possible by spliiting GUI by low level access
22:20:30 <anaselli> if possible remove mandriva stuff with dbus, cpan or any other standard thing
22:20:42 <anaselli> do not touch the installer
22:20:42 <coling> pasmatt, so I don't really know what rpmdragora is so cannot really comment, but long term I'd rather see any tools relating to package installation go via DBus too, perhaps using e.g. PackageKit (which is basically a DBus API), so the same principles stand even if it's nowhere near practical :)
22:21:05 <coling> anaselli, I think that's fair.
22:21:15 <coling> anaselli, I mean, that all seems sensible.
22:21:28 <coling> dbus is definitely preferred.
22:21:30 <anaselli> ah i think you scared :D
22:21:39 <anaselli> so you can help us there?
22:21:51 <coling> *especially* if there is privilege escalation needed.
22:22:12 <coling> (as this is the best way to achive that cleanly - privileged backend, unpriviled frontend)
22:23:44 <coling> As for help I can give, I'm not sure how much time I can realistically commit to it! I guess from the UI perspective, I would suggest you worry more about the UI and less bout the backend stuff - only if you're basically rewriting bits anyway would you look at the backend bits.
22:24:29 <anaselli> so let's summarize...
22:24:43 <anaselli> no one is interested, but users
22:24:50 <coling> But I know that my plate is already overloaded with all the things I want to do. I can definitely help with specific (and please do poke me with specific questions and don't give up - keep poking me :D)
22:25:09 <anaselli> no one wnat to change, but three people with very low free time
22:25:18 <pasmatt> :-/
22:25:32 <coling> Well, I wouldn't say "no one is interested" but there is certainly a problem with the amoutn of time people can commit.
22:25:43 <coling> I'm interested in many things that I have no hope of doing anything about.
22:25:45 <anaselli> who could speak neither partecipated to the meeting, just shot a mail
22:26:12 <anaselli> coling: indeed i said three people :)
22:26:37 <pasmatt> coling anaselli so, what about the roadmap? :)
22:26:49 <anaselli> ennael: fallen asleep too :)
22:27:05 <ennael> trying to follow the discussion :)
22:27:11 <coling> So I guess the best approach is to keep plugging away at things. Make a nice project that will ultimately replace things in an installed system.
22:27:27 <coling> (i.e. a drakx-standalone v2)
22:27:35 <anaselli> from my perspective i see i can go on porting tools. In a short time period
22:27:39 <coling> I'm not sure we can realistically change too much in the installer.
22:27:50 <anaselli> i think we can have a package to test with something
22:27:57 <coling> So things will likely split along installer vs. installed systems.
22:28:36 <anaselli> coling: suse has ported all their stuff now on installer
22:28:40 <coling> And eventually I'd (personally) like to see a much simplified installer with lots of stuff simply removed. And if it's no longer needed for standalone (as adminpanel replaces that) then it can just die.
22:28:43 <anaselli> by usin YCP
22:29:02 * coling has no idea waht YCP is.
22:29:25 <anaselli> http://doc.opensuse.org/projects/YaST/SLES11/tdg/Book-YCPLanguage.html
22:29:26 <[mbot> [ The YaST Programming Language - YCP ]
22:29:55 * anaselli is not from suse :D
22:30:13 * coling is unlikey to read that if I'm honest!
22:30:14 * anaselli is just in touch with their community for yui
22:30:19 <ennael> mmm
22:30:24 <ennael> home language by suse ?
22:31:36 <ennael> if so I'm afraid it may not be a good choice
22:31:37 <anaselli> it's a language that compiled produces code for you bindings
22:31:49 <anaselli> or better yast-bindings yet
22:32:05 <coling> So basically vala?
22:32:08 <anaselli> i ahven't understood where libyui is atm in their system
22:32:15 <anaselli> ruby coling
22:32:15 <ennael> I was in a suse conf last week and they said they were rewriting all yast
22:32:18 <coling> Anyway, I don't think it really matters.
22:32:21 <pasmatt> ennael: we are not talking of using ycp :)
22:32:23 <ennael> and drop that home made language
22:32:25 <ennael> ok
22:33:05 <coling> We can decide what we want (although decisions are hard to reach!)
22:33:06 <ennael> well guys... this discussion can take days... and I will not stay days here :)
22:33:07 <anaselli> it's all in ruby iiuc but on YUI or something in between the old library and the new
22:33:21 <anaselli> ennael: me neither ;)
22:33:27 <coling> :)
22:34:11 <anaselli> i tried to give an idea, but i don't think i will be followed by much people...
22:34:28 <coling> But anyway, yeah I think the only realistic plan would be to carry on with AdminPanel until it's a viable replacement for drakx-standalone stuff (and drakconf) at which point we could basically stop shipping drakx stuff in an installed system.
22:34:33 <anaselli> are you asking to me if i want to desist?
22:35:18 <anaselli> coling: i will go on, and as a packager i will provide my own upstream panel :p
22:35:34 <coling> anaselli, I think that makes sense.
22:35:36 <anaselli> but i do really need help to have something soon
22:36:17 <coling> anaselli, I will certainly try to help as best I can if you can ask specific questions.
22:36:38 <coling> And I will try and help specifically with services and logging parts.
22:36:40 <anaselli> coling: i will
22:37:01 <anaselli> concerning service and log backends for instance
22:37:04 <pasmatt> anaselli: here I am, as it was before and - I fear - as it will be in future :)
22:37:06 <coling> Once there are basic packages and I managed to get my system back to cauldron (still on MGA4)
22:37:34 * anaselli is in 3 yet,,,
22:37:51 <coling> anaselli, pasmatt as far as getting more people involved, we should try and leverage existing communities to get more interest.
22:38:32 <coling> e.g. if the logging and service mgmt bits can be cleaned up, we can maybe see if we can post on G+ systemd page and mailing list to try and drum up interest.
22:38:34 <anaselli> coling: where about?
22:38:41 <coling> But it has to be easy to install.
22:38:49 <coling> Especially fro non-mga distros.
22:39:03 <pasmatt> let's see :)
22:39:06 <coling> So once that is possible, this may be where we can try and get more people.
22:39:09 <anaselli> coling: to do that we need to remove mandr* stuff first ;)
22:39:11 <coling> (It's worth a shot anyway!)
22:39:17 <coling> anaselli, perhaps yeah.
22:39:32 <coling> Anyway just a suggestion.
22:39:43 <coling> And I can help to push it there when the time is right.
22:39:57 <anaselli> ok let's close the meeting what do you think?
22:40:01 <anaselli> coling: sure
22:40:10 <coling> anaselli, yeah I think so.
22:40:12 <anaselli> you will hear me
22:40:27 <coling> I'm sure :)
22:40:28 <anaselli> a lot, :P
22:40:32 <coling> Haha!
22:41:09 <coling> OK, so ....
22:41:12 <coling> #endmeeting