16:11:55 <itchka> #startmeeting
16:11:55 <chwido> Woof! Let's start the meeting. It's Wed Feb  1 16:11:55 2017 UTC. The chair is itchka. Information about me at https://wiki.openmandriva.org/en/Chwido.
16:11:55 <chwido> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:11:55 <chwido> You should add extra chair(s) just in case, with #chair nick.
16:11:55 <chwido> Have a good meeting, don't bark too much!
16:12:04 <bero> chwido: woof! woof!
16:12:10 <itchka> #chair bero
16:12:10 <chwido> Current chairs: bero itchka
16:12:17 <itchka> #item 1
16:12:40 <fedya> +
16:12:54 <itchka> #topic Items that need to be included in the new om-control-center
16:14:50 <itchka> So in the front screen we have software, hardware, networks, system and security
16:15:15 <itchka> Lets start with hardware shall we
16:16:21 <itchka> At the moment we have video card, printer, dvb devices and UPS
16:16:40 <bero> It may make sense to add kinfocenter or something similar to it so users can see what was detected
16:16:44 <itchka> What do we need to add to that.
16:17:18 <bero> also, can anyone test the dvb and ups stuff? I don't have the hardware and the tools are suspected of being broken by default (because they're from drakx, meaning they probably haven't been touched since 2009 or so)
16:19:18 <itchka> OK I can't. Perhaps we should  put out a request over the mailing lists.
16:20:12 <itchka> bero I just looked at kinfocenter..it's not very user friendly....
16:21:30 <itchka> For example the PCI devices are not identified by function jsut by PCI buss number.
16:24:38 <itchka> There is a vague description but for the ordinary users surely Graphics Card, USB Hub etc type descriptions woul be more helpful
16:27:25 <itchka> I don't see  Scanner.  Mouse, trackpad and keyboard?
16:28:38 <bero> yes, should add those
16:28:44 <bero> I didn't modify the list of what's there
16:36:42 <Pharaoh_Atem> we've also had a parallel development of a replacement toolset called manatools
16:36:44 <Pharaoh_Atem> in Mageia
16:37:11 <Pharaoh_Atem> it might be interesting to come together and collaborate on making the mcc replacement
16:37:30 <Pharaoh_Atem> https://github.com/manatools
16:38:00 <itchka> Power cut in the house
16:38:16 <Pharaoh_Atem> the main manatools are still written in Perl, but moving to Python (if more people are interested in helping with the development) is something we're interested in
16:38:40 <Pharaoh_Atem> our DNF frontend for manatools, dnfdragora, is written in Python
16:38:52 <bero> Pharaoh_Atem: agreed...but we'd really like to get rid of the perl+gtk mess. The new bits I've started are based on om-welcome (which is essentially shell scripts spewing HTML, not exactly my favorite technology, but easy for designers to work with...)
16:39:12 <Pharaoh_Atem> we're using libyui to have Qt+GTK+ncurses UIs "for free"
16:39:26 <bero> dnfdragora certainly is interesting...
16:39:27 <Pharaoh_Atem> and we've made extensions to libyui to add extra widgets
16:39:58 <Pharaoh_Atem> anaselli and I are interested in moving the rest of the codebase to Python base using libyui (like we did for libyui), but it's a lot of work and my time is stretched thin
16:40:11 <Pharaoh_Atem> more contributors helping us move forward for both of us would be highly welcome
16:40:41 <Pharaoh_Atem> bero: dnfdragora is also going to be adopted by the upcoming LXQt spin from Fedora
16:41:46 <Pharaoh_Atem> the goal of manatools is to provide easy to use frontends for the common stack of things that are used by modern distributions these days
16:44:45 <Pharaoh_Atem> bero: the eventual goal was to use the framework built out of manatools to rebuild the drakx installer
16:45:13 <Pharaoh_Atem> though that may not be something we'll do anymore
16:45:58 <Blackcrack> humm.. sorry if i loggin in .. Manatools was developer out of a disscussion from there.. ;) something like Draktools .. like i reminde me :)
16:46:11 <Blackcrack> (inbly as info ;) )
16:46:21 <Blackcrack> err: only.
16:46:38 <Pharaoh_Atem> it's intended to replace drakxtools
16:46:48 <Pharaoh_Atem> it's been available as a preview in Mageia for a little while now
16:48:21 <Pharaoh_Atem> we've been primarily talking about manatools development in #mageia-dev, but I don't see why we couldn't set up a dedicated channel if there's interest
16:48:29 <Blackcrack> so should Draktools more update and should give extra plugins .. because Draktools was the first Configuration-Centre behind linuxconf..
16:48:57 <Blackcrack> ohy, (r-only mode again ;) )
16:49:18 <Pharaoh_Atem> well, the idea behind manatools is that it's a complete rewrite of drakxtools
16:49:30 <Pharaoh_Atem> instead of being bound to GTK+, it uses libyui, among other things
16:50:05 <Pharaoh_Atem> bero: oh, and I managed to upstream the s-c-p embedded window patch from long ago Mandriva in the latest version of system-config-printer
16:50:06 <itchka> bero you seemed to favour c++ for all this stuff though rather than a scripting language.
16:50:28 <Pharaoh_Atem> manatools also does not mandate everything has to be written in one language
16:50:34 <Pharaoh_Atem> so things *could* be written in other languages
16:51:05 <bero> I'm ok with either, but I always prefer C++ over dynamically typed languages (they're just too error prone)
16:51:16 <Pharaoh_Atem> most of our community would favor rewriting into Python simply because of broader knowledge and ease of maintenence
16:51:20 <bero> Where I really think script languages are a problem is basic system recovery tools
16:51:39 <Pharaoh_Atem> but C++ isn't out of the question if we have people who know C++
16:51:54 <OnlyHuman> why not C ?
16:52:13 <bero> e.g. having urpmi/dnf/... written in a script language makes it hard to impossible to recover from a situation where $SCRIPT_LANGUAGE_OF_CHOICE is broken (e.g. due to an interrupted update)
16:52:29 <bero> OnlyHuman: C is great for system level stuff, but really really sucks for writing UIs
16:53:45 <OnlyHuman> bero: oh, just got impression is was better than C for many things, (not that I know any coding) :P
16:56:21 <Pharaoh_Atem> bero: there is work on moving more of DNF into C
16:56:33 <Pharaoh_Atem> and there's a microdnf, too: https://github.com/rpm-software-management/microdnf
16:56:40 <Pharaoh_Atem> though it's not quite ready to be general purpose yet
16:56:48 <Pharaoh_Atem> it could be evolved enough to be a failover tool
16:57:53 <OnlyHuman> that sounds promising
16:57:58 <Pharaoh_Atem> the goal is to make DNF merely a python frontend for the libdnf C library
16:58:05 <Pharaoh_Atem> and we're gradually moving in that direction
16:58:30 <OnlyHuman> sounds even better then
16:58:32 <Pharaoh_Atem> but, it's just one of those things that takes time to do, unfortunately
16:58:41 <itchka> dnf ready for prime time yet?
16:59:14 <Pharaoh_Atem> I haven't checked on the progress done by the Intel guy and Jeff on dnf for rpm5, so I don't know
16:59:14 <OnlyHuman> maybe proyvind could be assigned that task
16:59:47 <bero> itchka: dnf on rpm4 is certainly ready for primetime -- probably needs a bit more work on rpm5
16:59:58 <Pharaoh_Atem> ^
17:00:04 <Pharaoh_Atem> dnf works very well with rpm.org rpm
17:00:12 <bero> speaking of which: [00:08:50] <jbj> what would help is an OMA ROADMAP that isn’t just “deal with POK patches” (which I have dealt with as best I can, most are insufficiently interesting to other users of RPM5 (like Distepoch)
17:00:26 <OnlyHuman> seems ok on fedora
17:00:33 <Pharaoh_Atem> works great on Mageia :)
17:00:37 <bero> So I think jbj is open to having some work on that pushed his way
17:00:48 <Blackcrack> (because he have experience, no metter if he *beep* or *beep* or *beep* this sch*beep* , but Per have experiance , *beep* *bg* )
17:00:56 <Pharaoh_Atem> wow
17:01:03 <Pharaoh_Atem> much curse... many hates
17:01:04 <Blackcrack> *lol*
17:01:44 <Blackcrack> so, i mus go, drive to job .. see you, but take Per as developer, what ever he say ever on *beep* *;)
17:02:19 <fedya> btw, yes what's about replacing urpmi with dnf
17:02:29 <fedya> Pharaoh_Atem mageia already did it?
17:02:39 <OnlyHuman> he certainly has some valuable skills
17:02:52 <Pharaoh_Atem> we have both in parallel for mga6
17:02:56 <Pharaoh_Atem> mga7 will have it removed, most likely
17:03:06 <itchka> What are the advantages and possible disadvantages
17:03:08 <Pharaoh_Atem> we already have tasks queued to gut perl-URPM and move everything to use libdnf
17:03:36 <OnlyHuman> looking forward to remastering mageia :)
17:03:49 <Pharaoh_Atem> fedya, bero, itchka: see as an example: https://bugs.mageia.org/show_bug.cgi?id=20131
17:04:06 <Pharaoh_Atem> I also plan to ship dnfdragora in Mageia as part of Mageia 6's manatools preview
17:04:31 <Pharaoh_Atem> Thierry has already agreed to work on migrating our installer to libdnf
17:04:37 <Pharaoh_Atem> after mga6 is out
17:04:59 <Pharaoh_Atem> and I'm working on figuring out our buildsystem migration path for mga7 Cauldron onward
17:05:24 <Pharaoh_Atem> also, as maintainer of livecd-tools and appliance-tools upstream, I'm working on making Mageia variants of them for Mageia 6
17:05:41 <Pharaoh_Atem> though we will likely also port our existing tools to use DNF somehow
17:07:09 <Pharaoh_Atem> mls has already ported the relevant perl-URPM solver logic to libsolv, and I've enabled it in DNF
17:07:19 <Pharaoh_Atem> so kernel package and locale package selection/sorting works
17:08:26 <itchka> So the funtionality of perl-URPM is now all incorporated in libsolv?
17:09:38 <Pharaoh_Atem> well, the mdv-specific solver logic is
17:09:52 <Pharaoh_Atem> perl-URPM's solver process is not, because it doesn't make sense in libsolv
17:10:04 <Pharaoh_Atem> libsolv has a (imho) better solver
17:10:19 <Pharaoh_Atem> but yes, it handles things like mdv-style kernel package flavors well
17:10:54 <Pharaoh_Atem> though I expect that we in Mageia will transition to multiversion kernel packaging as soon as urpmi is removed
17:11:46 <jbj> Pharaoh_Atem: urpmi parallel downoads? splitting into sub-transactions? those are not simple to replace. arguably useless too.
17:12:09 <Pharaoh_Atem> parallel downloads of packages, I think we already do
17:12:21 <jbj> parallel with installs
17:12:31 <Pharaoh_Atem> ah, no, we don't do that
17:12:42 <Pharaoh_Atem> we download everything first and then install
17:12:44 <jbj> parallel downloads only is just worker threads
17:13:09 <Pharaoh_Atem> the subtransaction thing has bitten me a few times in urpmi, so I'm not sure I particularly like it
17:13:14 <jbj> sub-transactions requires incremental dep-solving
17:13:28 <Pharaoh_Atem> that might not be possible
17:13:35 <Pharaoh_Atem> libsolv is "full solution solver"
17:13:51 <Pharaoh_Atem> something to talk to mls about, I guess
17:14:53 <jbj> bitten here too … meanwhile its mostly fine. and there is a solution with a callback in rpmtsCheck to add to a transaction after (late) depsolving.
17:15:28 <Pharaoh_Atem> yeah, but perl-URPM doesn't use it :/
17:15:35 <Pharaoh_Atem> so things get a little funky at times
17:15:39 <jbj> similar could be done in libsolv to what rpm5 does in rpmtsCheck
17:15:49 <Pharaoh_Atem> or, if you're unlikely like me, you get a broken chroot build :(
17:17:01 <jbj> the 2 features I mention have been roadblocks to replacing perl-urpmi in the past.
17:17:39 <Pharaoh_Atem> I haven't had that particular experience in Mageia so far
17:17:55 <Pharaoh_Atem> people have been generally enthusiastic about it
17:18:43 <jbj> I’m happy for mga ;-)
17:18:51 <Pharaoh_Atem> thanks
17:18:57 <Pharaoh_Atem> it's been a hard battle
17:19:06 <OnlyHuman> someone send chwido  to fetch itchka back
17:19:25 <Pharaoh_Atem> but I'm very pleased with the results so far, because the integration has been going smoothly and people are noticing that we exist :)
17:19:41 <Pharaoh_Atem> and I've gotten people to consider supporting Mageia properly for their software because of it
17:19:52 <Pharaoh_Atem> it's amazing what has happened over the last year and half of integration work
17:20:32 <jbj> still: if tghe call back can add additional prerequisites to the install transaction, depsolving can be done in one pass and incrementally
17:21:02 <Pharaoh_Atem> I know libsolv has a callback mechanism for re-solving, but I'm not sure it can be used in this manner
17:21:37 <Pharaoh_Atem> it's used to allow frontend tools (like zypper and dnf) to query the user to ask how to solve a problem
17:21:46 <Pharaoh_Atem> but I *think* it can be used in the manner you describe, too
17:21:59 <jbj> no depsolver I am aware of can do one pass incremental install transaction construction. poky/yocto does using rpmtsCheck.
17:22:31 <Pharaoh_Atem> you're probably right in this regard
17:22:36 <Pharaoh_Atem> again, I'm *really not sure*
17:23:26 <jbj> dialog with user is bad UI. so you’re in the middle of a multi-hour thousand+ package upgrade and the app wants to play 20 questions? bad ui, true for dpkg as well as urpmi
17:23:34 <Pharaoh_Atem> yes
17:23:46 <Pharaoh_Atem> dnf does not currently implement that callback support
17:23:56 <Pharaoh_Atem> instead, it autosolves and picks a solution, or throws an error and quits
17:24:02 <itchka> another power outage
17:24:05 <bero> probably worth adding at some point
17:24:33 <jbj> hehe yes we need more power outages in dnf ;-)
17:24:39 <Pharaoh_Atem> there's a couple of RFEs related to it, so if someone wants to take that up, it can be done
17:24:51 <Pharaoh_Atem> but anyway...
17:25:20 <itchka> 'fraid I missed a chunk of this
17:25:23 <jbj> key management dialog is another bad ui
17:25:59 <jbj> EULA ditto
17:26:45 <Pharaoh_Atem> we don't have eula thing
17:26:55 <Pharaoh_Atem> key mgmt, well, I assume you're talking about key verify
17:27:37 <jbj> the point is that dialogue while installing is usually the wrong approach
17:28:49 <itchka> but perhaps the intention was to reduce user boredom.
17:30:00 <jbj> the other, rather more obscure point, is that breaking up a monolithic install transaction into smaller stand-alone blocks permits installer to be parallelized
17:30:43 <itchka> This has big advantages when building isos..
17:30:51 <Pharaoh_Atem> that usually breaks things like transaction history, though
17:31:07 <Pharaoh_Atem> right now, transaction history is 1:1 to user action
17:31:38 <jbj> itchka: progress bars are more bad ui: bored users are waiting even iwith eye candy. faster parallel installs reduce wait time.
17:31:43 <Pharaoh_Atem> and breaking the transactions up also makes things slower in practice
17:31:50 <Pharaoh_Atem> largely due to massive numbers of scriptlets
17:31:58 <Pharaoh_Atem> and transaction scriptlets get run over and over
17:32:00 <Pharaoh_Atem> rather than one time
17:33:08 <Pharaoh_Atem> anyway, brb
17:33:12 <jbj> Pharaoh_Atem: what is transaction history to you? rpm transactions? one can have nested transactions, the other solution is concurrent sub-transactions. bioth have history afaict
17:36:34 <itchka> I don't see how it can be slower waiting for everything to download before installing
17:37:53 <itchka> Anyways we should get back to the point we were actually discussing and that is the items that need to go in the various categories of the new om-control-center.
17:39:14 <jbj> itchka: downloading while installing is faster than downloading and then installing. meanwhile downloads are tithing to the network gods. parallel installs is the holy grail for depsolvers
17:39:30 <jbj> but yes OT
17:39:49 <cc^mint> Hello!
17:40:55 <itchka> Then the Holy Grail is what we should seek :)
17:41:01 <itchka> cc^mint: Hi
17:42:17 <cc^mint> itchka! :-)
17:42:53 <itchka> For om-control-center/hardware we need to add scanner, mouse/trackpad and keyboard
17:43:10 <itchka> Lets look at the Network section next.
17:43:39 <Pharaoh_Atem> back
17:45:01 <itchka> In here we have "Configure the Network, Add network hosts, Change the hostname/set dns, Configure internet sharing, configure a proxy, Configure a VPN
17:45:12 <itchka> What do we need to add here?
17:47:58 <itchka> Looks pretty complete to me
17:48:29 <itchka> We have sub-categories "Network Sharing"
17:49:12 <itchka> Which contains the nfs and samba setup entries
17:50:53 <itchka> bero: Do you think we ought to put in sshfs sharing that works pretty well for me.
17:59:22 <rugyada> hi
17:59:34 <itchka> rugyada: Hi
17:59:46 <rugyada> among all those tools, what is surely working/not working ? there is anything currently useless?
17:59:57 <rugyada> guess we have to check, in general:
18:00:08 <rugyada> 1. what is working -> what must or may be replaced by a better tool,
18:00:18 <rugyada> 2. what is not working -> which tool we have for replacement,
18:00:28 <rugyada> 3. what is useless -> delete,
18:00:34 <itchka> Quite a few don't work that is why it's imn contrib at the moment.
18:00:35 <rugyada> (if any)
18:00:45 <rugyada> 4. what we need to add.
18:00:49 <rugyada> .
18:01:19 <itchka> rugyada: We are currently discussing what we need to add.
18:01:25 <rugyada> ah, ok :)
18:02:35 <rugyada> the hw detection tool ?
18:03:11 <itchka> It was mentioned that we should include the kinfo tool
18:03:23 <rugyada> not sure if it's actually useful yet :)
18:03:32 <rugyada> kinfocenter?
18:03:47 <itchka> yes
18:03:56 <rugyada> ok, good
18:06:06 <rugyada> iirc we have to replace the network management, right?
18:06:21 <itchka> It's not perfect personally I think it would be tough to get to grips with as a beginner especially given that so much stuff is obsfucated now in Windoze that users are I suspect less and less au fait with the devices in their machines.
18:06:51 <itchka> I think if you try it you will find that it has already been replaced.
18:07:21 <rugyada> great :) no, I did not try
18:08:16 <rugyada> there could be kind of inxi output for hw detection / list / ??
18:10:24 <rugyada> is bero, who is doing the work afaik, here?
18:12:54 <itchka> Sorry another power cut..there's something wrong with our rcd trip
18:13:12 <rugyada> itchka: also the firewall stuff is launching the correct tool, right?
18:13:31 <rugyada> [1/2/2017 19:08] <rugyada> there could be kind of inxi output for hw detection / list / ??
18:13:32 <rugyada> [1/2/2017 19:10] <rugyada> is bero, who is doing the work afaik, here?
18:14:06 <itchka> bero: was here but he may have gone to walk the dogs
18:14:16 <rugyada> ok
18:14:37 <rugyada> wished to know also his opinion :)
18:15:18 <itchka> No goubt he will return.
18:15:57 <itchka> What do you think about pushing sshfs as local filesharing protocol?
18:17:22 <rugyada> I'm not expert of that stuff.
18:18:07 <rugyada> I can tell nothing about :)
18:19:11 <rugyada> what about the sound configuration?
18:19:16 <itchka> It's easier to set up and use than NFSand it's encrypted
18:20:03 <rugyada> no doubt - but I don't deal that stuff...
18:22:03 <rugyada> btw unless I'm missing something obvious I don't see any tool for sound
18:22:07 <itchka> We were dealing with networks at the moment but as far as sound is concerned most of the tools for that are incorporated in the kde desktop tools under multi media.
18:23:01 <itchka> The sound tool on MCC was more of a debugging tool than a setup tool.
18:23:43 <rugyada> uhm. and for any other DE? supposing we'll build LXQt-only?
18:24:20 <rugyada> we have any DE independent tool?
18:24:30 <rugyada> just asking :)
18:27:03 <rugyada> itchka:  (sure, we are trying to get rid of not working old tools)
18:29:59 <itchka> As far as I know there is no independant tool for configuring pulse audio and there are issues with sound in Lx3 which means the existing configuration tools are not doing what they should we do need to look at this.
18:31:07 <itchka> So we will add 'sound server' to the harware list
18:31:14 <rugyada> we do need to look at this. yes.
18:31:33 <rugyada> yes, as a remind.
18:32:32 <rugyada> sorry, I'm jumping here and here :) just I'm trying to compare mcc vs. om-control-center
18:32:52 <rugyada> here and there* :P
18:35:14 <itchka> Well I think there are several things we need to add to the "Network" section.
18:35:45 <itchka> 1 Under "Network Sharing"  sshfs shares
18:38:24 <itchka> 2 Under "Network Servers"  Mail Server and Docker builder
18:39:46 <itchka> In fact I'm wondering whether we can use docker images to deploy all the servers as self-contained units. fedya WDYT
18:42:47 <rugyada> Software > "Update of OpenMandriva Lx" doesn't like the root password, it requires the user's password :/
18:42:58 <rugyada> grrrrrrrrr
18:46:00 <itchka> Yes there's some inconsistancy with that.
18:47:38 <rugyada> more if you see that Add and remove sf opens with root password. actually all the others...
18:48:34 <rugyada> my user is just user :)
18:49:06 <rugyada> and is allowed to update the system. cool :))
18:49:40 <itchka> The first user on the system has sudo priviledges
18:49:57 <itchka> It's been kije that for a good while now.
18:50:13 <rugyada> maybe this one is run by mean of sudo
18:50:21 <rugyada> not su.
18:51:21 <rugyada> itchka: as said, all the other tool need root pw
18:52:12 <rugyada> so there is something different in the command, I think.
18:52:12 <itchka> I don't know but I think the pam system is still not working quite right if you look at the journal there are quite a few messages from it.
18:53:03 <rugyada> pam? something to do with admin privileges?
18:53:28 <itchka> Yes
18:53:39 * rugyada ignorant :)
18:53:54 <itchka> but I have no idea how it works
18:55:12 <itchka> One thing I have noticed id that the toll called to add and manipulate usewr accounts has no group managment included so that will have to be fixed.
18:55:30 <rugyada> by sense, I can only imagine that the command triggered is different as the outcome is different.
18:56:33 <rugyada> anyway I won't go deep into something I don't know at all..
18:57:00 <itchka> an example is urpmi which is called by a wrapper which always requires root so it bypasses the pam system.
19:06:56 <rugyada> itchka:  imho we need to get a beta version of om-cc, and to call testers and users to test and give feedbacks
19:10:15 <rugyada> itchka: I changed again some icons and got it a bit more nice :) still need of further little adjustments.
19:22:54 <itchka> I keep getting power cut here. Since there's few people about I think we will call it a day for the meeting
19:26:41 <itchka> #action Next meeting resume discussion of om-contol-center content.
19:27:57 <OnlyHuman> thats trouble with living in a third world country
19:28:21 <ashledombos> ciao
19:31:53 <rugyada> ashledombos: ciao :D
19:36:25 <rugyada> I think itchka should endmeeting, while his connection is still alive :)
19:37:11 <itchka> #action Next meeting resume discussion on om-control-center content
19:37:19 <itchka> #endmeeting