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