20:10:04 <Akien> #startmeeting 20:10:04 <Inigo_Montoya> Meeting started Tue Nov 28 20:10:04 2017 UTC. The chair is Akien. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:10:04 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic. 20:10:18 <Akien> #chair Son_Goku tmb 20:10:18 <Inigo_Montoya> Current chairs: Akien Son_Goku tmb 20:10:40 <Son_Goku> #addchair Pharaoh_Atem 20:10:47 <Son_Goku> hmm 20:10:49 <Son_Goku> okay then 20:10:52 <Akien> #chair Pharaoh_Atem 20:10:52 <Inigo_Montoya> Current chairs: Akien Pharaoh_Atem Son_Goku tmb 20:10:55 <Son_Goku> ah 20:10:58 <Akien> Don't make up commands :p 20:11:02 <Son_Goku> haha 20:12:03 <Solbu> Besides, Homemade commands belong in /usr/local … :-) 20:12:32 <Son_Goku> hehe 20:12:47 <Son_Goku> #topic Mageia 7 Feature Review 20:13:04 <Akien> Links to keep open while we discuss: 20:13:09 <Akien> #link https://wiki.mageia.org/en/Category:ProposedFeatureMageia7 20:13:19 <Akien> ^ Proposed features 20:13:24 <Akien> #link https://wiki.mageia.org/en/FeatureMageia7_Review 20:13:50 <Akien> ^ Already approved features - maybe we can skip those for today and discuss them on the ML if need be, there's enough to do with the not-yet-approved ones 20:13:54 <Son_Goku> yeah 20:14:02 <Son_Goku> we were going in alphabetical order last time 20:14:11 <Son_Goku> so since the last one approved was MirrorBrain 20:14:22 <Son_Goku> that means the next one is NM 20:14:29 <DavidWHodgins> Provided we have sysadmins to do the stuff needed 20:14:39 <Son_Goku> #info Proposed feature: https://wiki.mageia.org/en/Feature:MigrateToNetworkManager 20:14:46 <Son_Goku> #info Migrate to NetworkManager 20:14:55 <Akien> Sounds good to me, let's start with NM. We can go back to the skipped ones of the start of the list if we have time 20:15:08 <Akien> (some more skipped when the council reviewed as "need packager input" :)) 20:15:12 <Son_Goku> yeah 20:15:17 <Akien> s/more/were/ 20:16:04 <DavidWHodgins> My understanding is that there are some setups that drakx networking supports that networkmanager does not 20:16:13 <Son_Goku> like what, exactly? 20:16:19 <DavidWHodgins> That I don't know 20:16:34 <mokraemer> e.g. server setups with fixed ip? 20:16:38 <Son_Goku> at this point, NetworkManager supports your basic stuff, as well as Wi-Fi, teams, bonds, bridges, taps, tuns, bluetooth, ad-hoc, etc. 20:16:56 <Son_Goku> the latest version 1.10 even supports OpenVSwitch 20:16:59 <Son_Goku> which even drakx can't do 20:17:00 <Akien> Apparently there are some use cases where drakx-net does a better job, but it's only corner cases. NM works better than drakx-net in the majority of cases from what Icould read. 20:17:17 <Akien> I would like us to keep support for both (doesn't hurt, drakx-net works), but default to NM 20:17:26 <Akien> That means integrating it properly in our tools 20:17:36 <Son_Goku> NetworkManager supports ifcfg-rh fully 20:17:48 <Akien> It shouldn't be too hard I think, but needs to be done nevertheless :) 20:17:58 <Son_Goku> so as long as we use that as our default backend, and drakxnet can support the ifcfg-rh syntax fully, then we should be in good shape 20:18:02 <DavidWHodgins> We currently ask which network manager to support. Is this just a matter of changing the default? 20:18:08 <Son_Goku> pretty much 20:18:18 <DavidWHodgins> Ok by me then 20:18:25 <Akien> Well a bit more, as our networkmanager option in the MCC actually doesn't work 20:18:27 <ankh> i've often found drakx can make a working connection and nm can't 20:18:34 <tmb> Yeah, default to NM ... we already do that for Gnome Live isos 20:18:38 <Son_Goku> iirc, there's only one small deviation between ifcfg-rh and ifcfg-mdv 20:18:48 <Son_Goku> the name of the SSID field for wifi 20:19:08 <Son_Goku> we can probably just shift that back and make drakxnet understand that 20:19:47 <DavidWHodgins> There is currently an open bug where the ssid is being incorrectly used as the device name. It can be too long causing problems. 20:19:57 <Son_Goku> eek 20:20:02 <Son_Goku> that's with drakxnet? 20:20:23 <tmb> its with "something" and shorewall chokes 20:20:26 <Son_Goku> ah 20:20:28 <Akien> Just to keep us focused, since there are many features to review and I think we don't want a 3 h meeting: I propose that as soon as we reach a consensus on whether a feature is wanted for mga6, we mark it approved and go to the next. 20:20:33 <tmb> I haven't seen it here 20:20:38 <Son_Goku> well, mga7 20:20:44 <Son_Goku> tmb: I hadn't seen that either, which is why I was a bit confused 20:20:53 <Akien> Technical discussion about the scope and how to do things is of course important, but it will take us a while so better done in a specifc meeting/ML/bugzilla/wiki 20:20:55 <Son_Goku> I think we're okay with approving this and doing the work to transition 20:21:09 <tmb> Akien, yes, lets move on 20:21:10 <DavidWHodgins> That's it. It's bug 8960 20:21:12 <[mbot> Bug: ['drakfirewall adds lines longer than IFNAMSIZ (15)-1 to /etc/shorewall/interfaces', 'NEW', 'Mageia tools maintainers'] https://bugs.mageia.org/show_bug.cgi?id=8960 20:21:16 <anaselli> ok for me 20:21:20 <Son_Goku> #agreed MigrateToNetworkManager is approved 20:21:40 <Akien> DavidWHodgins: Might be worth listing relevant issues in the feature wiki page, as reference for future work 20:21:54 <DavidWHodgins> Ok 20:21:55 <Son_Goku> next on the list... 20:22:03 <Son_Goku> #info Proposed feature: https://wiki.mageia.org/en/Feature:Move_to_new_AppStream_Directory 20:22:08 <Akien> I'll edit that feature page later to mention that drakx-net support will be kept though, to be clearer 20:22:14 <Son_Goku> #info Move to New AppStream Directory 20:22:29 <Son_Goku> this shouldn't be a particularly difficult feature 20:22:52 <Son_Goku> it's just adding /usr/share/metainfo to filesystem and making packages install their appstream files to that location 20:23:05 <Son_Goku> now that we have rpm 4.14 with the new directory recognized by the generators, it should be fine to do 20:23:14 <Akien> Fine by me, we just need to find the right procedure for such mass sed'ing in spec files :) 20:23:17 <Solbu> We could also do what we did for the usrmove, link the old location to the new. 20:23:31 <Son_Goku> I don't have a problem with that, as that could be done in filesystem 20:23:34 <tmb> and we could even add a symlink between appdata & metainfo 20:23:50 <Akien> Sounds good to me. 20:23:51 <Son_Goku> well, I think the idea is the free up the weird appdata directory back for games 20:23:53 <Son_Goku> but yeah, sure 20:24:02 <Son_Goku> we in agreement? 20:24:04 <kekePower> I'm not a fan of linking 20:24:13 <Akien> So is appdata meant to still be used? 20:24:21 <Akien> I mean /usr/share/appdata 20:24:31 <Son_Goku> oh, no, it's not supposed to be anymore 20:24:36 <Son_Goku> for appstream 20:24:41 <Son_Goku> but it'll be supported for a little while longer 20:24:44 <Son_Goku> not sure how much though 20:24:52 <tmb> ah, if its used for games too, forget the symlink 20:25:05 <Son_Goku> it *used* to be used by games a long while back 20:25:09 <Son_Goku> I don't know if they do still 20:25:13 <tmb> then lets just try to clean it up 20:25:17 <Son_Goku> okay then 20:25:27 <Son_Goku> but we're agreeing it's approved? 20:25:40 <Akien> Yeah 20:25:41 <Son_Goku> #agreed Move to new AppStream Directory is approved 20:25:44 <tmb> yep 20:25:46 <anaselli> yes 20:25:53 <kekePower> do we have an estimate of how many packages are affected? 20:25:57 <Akien> tmb: Any idea regard how to make such mass spec changes efficiently? 20:26:19 <Akien> We also need to do this for the %configure2_5x -> %configure migration, but checking out the whole SVN repo is huge :D 20:26:24 <Son_Goku> kekePower: repoquery -f /usr/share/appdata/* might tell us 20:26:48 <Son_Goku> anyway, onto the next... 20:27:07 <Son_Goku> #info Proposed feature: https://wiki.mageia.org/en/Feature:NetworkDrakToolsImprovements 20:27:09 <tmb> Akien, iirc coling had a nice way of doing svn wide change without pulling full repo... we could ping him 20:27:13 <Akien> I'll add myself to that feature btw, a big part of the affected packages are games so I can help with the transition :) 20:27:19 <Son_Goku> :) 20:27:19 <martinw> Akien: Olav has done mass changes in the past - he must know 20:27:38 <Son_Goku> #info NetworkDrakToolsImprovements 20:27:42 <martinw> unless he did it the hard way... 20:27:53 <Son_Goku> oh dear... 20:28:28 <Akien> So that one is kind of a duplicate of the NM migration one 20:28:39 <Son_Goku> yeah 20:28:42 <Son_Goku> it seems like it 20:28:53 <tmb> yeah, but but the IPv6 part is relevant 20:29:10 <tmb> iirc drakfirewall only adds ipv4 stuff 20:29:18 <Son_Goku> the only bit that's unique is getting drakx to support the full spec that nm's ifcfg-rh parser supports? 20:29:38 <Akien> Right, so let's keep it for IPv6 support in drakfirewall, and use the other one for NM support in the drakxtools 20:29:44 <Son_Goku> sure 20:29:48 <tmb> yep 20:30:07 <Son_Goku> Akien, could you refine this feature after the meeting? 20:30:08 <anaselli> and moving the relevant part on nm migration? 20:30:17 <Son_Goku> we can approve it, but the content should be updated 20:30:30 <Akien> #agreed NetworkDrakToolsImprovements overlaps with MigrateToNetworkManager, should be partly merged and then re-purposed to track the addition of IPv6 support in drakfirewall 20:30:37 <Son_Goku> excellent 20:30:41 <Akien> Yeah, will do 20:30:46 <anaselli> fine 20:31:03 <Son_Goku> on to the next... 20:31:11 <Son_Goku> #info Proposed feature: https://wiki.mageia.org/en/Feature:New_Mgarepo 20:31:17 <Son_Goku> #info New MgaRepo 20:31:24 <Son_Goku> uhh 20:31:31 <Solbu> Isn''t some of this feature done by proyvind in his git repo? 20:31:34 <Son_Goku> so this is kind of part of the dist-git feature that was already approved 20:31:38 <Son_Goku> yeah 20:31:46 <Son_Goku> and the work was done by proyvind already 20:31:55 <Son_Goku> we're just kinda unable to use it without being on git :P 20:32:09 <anaselli> nothing better than something laready done :D 20:32:12 <Son_Goku> the repsys package includes transparent svn->git checkouts too 20:32:28 <Akien> "Targeted release: Mageia 4" :p 20:32:36 <Son_Goku> merging this stuff back into mgarepo and cleaning bits up should probably be not too bad 20:32:42 <anaselli> that is common Akien :p 20:32:42 <Son_Goku> but yeah :D 20:32:51 <Solbu> Akien: Backport! :-) 20:32:54 <Son_Goku> also... boklm :D 20:33:20 <Son_Goku> anyway, I think we can safely say this is approved 20:33:23 <Son_Goku> ne? 20:33:37 <Kharec> I think so 20:33:53 <Son_Goku> #agreed New MgaRepo work is mostly done, it's approved as part of Dist-Git migration work 20:33:57 <Kharec> We'll only have to update the feature wiki page 20:33:59 <mokraemer> hope there is no problems with mass updates, as mentioned 20:34:00 <Son_Goku> on to the next 20:34:31 <Son_Goku> #info Proposed feature: https://wiki.mageia.org/en/Feature:Offer_services_from_Framasoft 20:34:39 <Son_Goku> #info Offer services from Framasoft 20:34:43 <Solbu> I have strong reservations on this one, depending on how it's implemented. 20:34:51 <DavidWHodgins> I'm not in favour of having this one in mageia welcome, or installed by default 20:34:54 <Son_Goku> this is weird 20:35:02 <Son_Goku> I have really mixed feelings about this 20:35:15 <Kharec> Me too 20:35:20 <Son_Goku> if _we_ were offering digital life services ourselves, that might be different 20:35:35 <Son_Goku> but this seems a bit bizarre 20:35:38 <Solbu> If we do this, we should also support other services. 20:35:51 <Solbu> so, I'm against it. 20:35:54 <Kharec> I don't think it will improve mageia's image in the world 20:35:56 <Akien> Well it's also a bit contrary to the goals of Framasoft themselves 20:35:58 <Son_Goku> in principle I don't think this is a good idea 20:36:00 <DavidWHodgins> Against it here, as described 20:36:01 <Kharec> And we will depend on frama 20:36:21 <Kharec> I'm against too. 20:36:23 <Akien> Their purpose is to showcase free software tools and propose a hosted solution, *so that* people host their own and be independent 20:36:54 <Akien> They definitely don't want a massive influx of new users (and for example their nextcloud framadrop is closed to registrations, reached max capacity) 20:37:00 <Son_Goku> this whole proposal doesn't make sense 20:37:05 <DavidWHodgins> I have no problem with the package being available, but not in mageia welcome 20:37:20 <Son_Goku> I think Framasoft would not appreciate it much either 20:37:30 <tmb> yeah, I dont see how we can approve this 20:37:35 <Akien> On the other hand, it could be interesting to have a portal where we list FOSS services (from Framasoft and others) 20:37:37 <Solbu> DavidWHodgins: And not installed by default. 20:37:49 <Son_Goku> Akien, if it's just describing services people can use, that's different 20:37:54 <Son_Goku> and that's not even this proposal 20:37:59 <Son_Goku> it means lawyers! 20:38:06 <Son_Goku> s/means/mentions/ 20:38:06 <DavidWHodgins> So do we agree not to approve this as a feature? 20:38:12 <Kharec> ok for me 20:38:13 <Akien> Yeah the proposal is a bit weird 20:38:14 <Son_Goku> I believe we should reject it 20:38:21 <Solbu> Yes, reject. 20:38:26 <Akien> I think all present are against it yes. 20:38:33 <martinw> Yes from me too 20:39:00 <Son_Goku> #agreed Offer services from Framasoft is rejected, as we feel this is the wrong place for this and doesn't make sense for Mageia or Framasoft 20:39:37 <Son_Goku> onto the next 20:39:45 <wilcal> I love people who make decisions :-) 20:39:46 <Son_Goku> #info Proposed feature: https://wiki.mageia.org/en/Feature:Port_installer_to_use_DNF 20:39:56 <Son_Goku> #info Port installer to use DNF 20:40:01 <Son_Goku> ... 20:40:02 <mokraemer> #link realated to https://wiki.mageia.org/en/Feature:Switch_to_DNF 20:40:13 <Son_Goku> #link related to https://wiki.mageia.org/en/Feature:Switch_to_DNF 20:40:21 <mokraemer> #link and https://wiki.mageia.org/en/Feature:Update_urpmi_to_new_rpm 20:40:27 <Son_Goku> well, that's different 20:40:56 <DavidWHodgins> New rpm and dnf are different features 20:40:56 <mokraemer> they state to use bin. feature, which is available in new rpm as well 20:41:49 <DavidWHodgins> new rpm means updating urpmi to make use of new parts of rpm packages, as I understand it 20:41:52 <Son_Goku> yeah 20:41:54 <Akien> On the principle I'm not against it, *if* tv sees it himself as an added value and worth the effort. 20:42:23 <mokraemer> i don't see much benefit in it 20:42:25 <Akien> (don't know if you're around tvignaud btw?) 20:42:32 <Son_Goku> I don't know if I could go through the arguments about this again... 20:42:46 <martinw> I'm not against it per se, but I also struggle to see what value it adds 20:43:05 <Son_Goku> the most basic aspect is that the DNF stack is actively maintained across a number of folks across different distributions 20:43:30 <Son_Goku> and I've had a great experience working with upstream to address Mageia's concerns thus far 20:43:40 <DavidWHodgins> In the last council meeting, one suggestions was to have to branches of iso images. One with urpmi and drakx tools, one with dnf and manatools 20:43:58 <anaselli> iirc live tools also Son_Goku? 20:44:00 <Akien> I don't like this idea. 20:44:09 <Akien> Way too much work to support so many different backends. 20:44:10 <Son_Goku> anaselli, yeah, I do have the livecd-tools 20:44:11 <DavidWHodgins> With the two branches being tested etc. in alternate releases 20:44:23 <martinw> We seem to be discussing more than one feature. I'm referring to tthe installer 20:44:52 <Son_Goku> in the past, I've made Mageia ISOs that are urpmi-free, but also lack an installer 20:44:56 <mokraemer> martinw:we can't switch the installer without the rest of the system. 20:44:57 <Son_Goku> using manatools and dnfdragora 20:45:01 <Akien> Yes let's focus on the installer part. 20:45:04 <DavidWHodgins> I can't see switching the installer to dnf if we don't also switch to dnf for installed systems by default 20:45:12 <anaselli> DavidWHodgins: manatools is another story... here we could talk about dnfdragora maybe 20:45:28 <Akien> DavidWHodgins: It's unrelated, it's just what tool is used to install the packages during installation. 20:45:57 <Akien> It has no influence on the users, it's just for the needs of the backend. 20:46:10 <Son_Goku> DavidWHodgins: it's entirely possible to just use urpmi in the installer itself, and then dnf on the installed system, for example 20:46:11 <mokraemer> on current systems running dnf and urpmi have different results in installation. 20:46:17 <Son_Goku> it's not an ideal situation, but it's possible 20:46:17 <DavidWHodgins> So are you saying develop a version of the installer that uses dnf, but not use that version on our iso images? 20:46:24 <Akien> So far, there is no real need for the dnf-specific features that changing the backend would bring, so I would also not focus on this. When there's a need, it can be done. 20:46:39 <Son_Goku> Akien, the only big thing is rust stuff 20:46:53 <Son_Goku> that uses rich deps and such 20:47:16 <Son_Goku> there's a few other things, but that's the only one that mandates it in a urpmi-incompatible way 20:47:35 <tmb> well, that part depends of if urpmi learns rich deps and stuff... 20:47:36 <Akien> Yeah, so given that our resources are limited, we should decide to focus on either this proposal, or enhancing perl-URPM. 20:47:56 <martinw> AFAIK, the installer doesn't run the standalone urpm* commands - it uses the underlying libraries 20:48:04 <Son_Goku> yes, and those would need to be ported to libdnf 20:48:25 <Son_Goku> which is the library that PackageKit also uses 20:48:26 <martinw> so it is independent of what commands we provide to the user 20:48:30 <Son_Goku> yees 20:48:41 <Son_Goku> for example, I've been working on a urpm CLI shim for DNF 20:48:50 <Son_Goku> so that basic urpm syntax maps to DNF commands and runs 20:49:12 <martinw> The user won't know or care what backend the installer uses 20:49:22 <Son_Goku> nope, this is basically for us 20:49:28 <mokraemer> maybe we should postpone this for mga8? 20:49:29 <martinw> which is why I'm not against it 20:49:56 <Son_Goku> mokraemer: postponing this doesn't make this easier 20:50:06 <anaselli> #link https://gitlab.com/mdklinux/dnf-urpm 20:50:07 <[mbot> [ MDK Linux / dnf-URPM · GitLab ] 20:50:58 <DavidWHodgins> Don't dnf and urpm use different data that would have to both be on the user's system? 20:51:01 <Solbu> My understanding is that dns is a yum fork. My main complaint against yum have always been that it have a tendency to update it's package cache from the configured repo, at some preset intervals. The user apparently can't prevent it. 20:51:08 <Solbu> *dnf 20:51:18 <Son_Goku> Solbu: there's a switch in DNF to prevent it 20:51:38 <Solbu> Well, it should be the default. :-) 20:51:39 <Son_Goku> and if we want to introduce a config option to make that a permanent default, we could 20:51:54 <Son_Goku> the --cacheonly (or -C) switch does what you expect 20:52:02 <Son_Goku> and in my shim, I pass that option basically all the time :P 20:52:04 <Akien> So, this (and others related) are not just "yeah why not" features, they imply a lot of work and partly overlap. I think we need to focus on what we *need*, and choose the features that address it in the best way. 20:52:11 <tmb> imho the proper way to move forward is to create new installer that uploads a differently named image in install/stage2 so we have an "easy fallback" if it does not work properly 20:52:40 <Solbu> tmb: THat is a good idea. 20:53:03 <Akien> The need here would be to support new RPM features in the installer. This can be done either via changing the backend to use DNF (this proposal), or by improving perl-URPM to support rich deps and other new features. 20:53:05 <tmb> then either teach stage1 to searcg for new image first, and if not existing, fallback to the old 20:53:14 <Akien> We need to decide for the one or the other IMO. 20:53:29 <Son_Goku> the other advantage of the DNF stack is that it makes it much easier for third parties to support us 20:53:49 <Son_Goku> I've had great luck actually getting people to support Mageia, test and build and offer packages for us, with Mageia 6 20:53:57 <Akien> Yeah but that's also out of scope of the installer part IMO. 20:53:59 <Son_Goku> sure 20:54:16 <Son_Goku> but it seems like people are talking about the meta-issue, so I brought that up 20:54:50 <martinw> Improving perl-URPM means finding someone prepared to do the work... 20:54:52 <anaselli> maybe tmb is right 20:55:19 <tmb> Akien, well, if tv decides to improve perl-URPM we wont be stopping him either :) 20:55:29 <anaselli> having a kind of fork tree can give the possibility to work and go on this feature 20:55:44 <Son_Goku> I think that's probably going to have to be the way it gets done regardless 20:55:59 <anaselli> otoh if nobody helps it never improves 20:56:12 <Son_Goku> yeah 20:56:40 <Son_Goku> one of the big reasons I pushed for DNF in Mageia 6 and got it in place was to show that we can use this installer and still have a nice magical flavor to it :) 20:56:43 <Akien> But yes, if we want a coherent directions, we have basically two scenarios (again encompassing many proposed features): 20:56:44 <Akien> 1) Keep urpm* as default, enhance perl-URPM, keep dnf as an opt-in package manager but not a core dep of Mageia. 20:56:45 <Akien> 2) Switch to DNF as default backend. For the frontend, we can keep urpmi if we want with a DNF backend to avoid a culture shock. Make the installer use the DNF backend. 20:57:33 <Son_Goku> my hope is that we can move towards number 2 20:58:03 <Akien> Both imply quite some development work. (1) means dev work on urpm*/perl-URPM; (2) means dev work on the installer (the feature we were discussing now) + maybe urpm* frontends to DNF 20:58:04 <Son_Goku> with tools like dnfdragora, most of our users that use primarily the GUI will have an intuitive way to manage software 20:58:04 <tmb> Yeah, I think we have to decide to start doing the work on redoing/updating the installer... and at some point make a status check of where we are, is it usable for mga7 or do it need to wait for mga8 20:58:07 <anaselli> perl-URPM developers here? 20:59:00 <Son_Goku> the only urpm command frontend missing at this point is urpmf and urpmq, which I just have to get a few days to sit down and figure out how to map the commands 20:59:05 <Akien> tmb: what work do you have in mind with "redoing/updating the installer"? 20:59:28 <Son_Goku> tmb: are you thinking we should rewrite the installer and pull it out of drakxtools? 20:59:43 <Akien> And your proposal to keep the current stage2 as fallback and add a new stage2 using DNF? 21:00:17 <Akien> s/And/Ah,/ 21:00:32 <Son_Goku> if we did that, then we could probably be free to yoink it out and use the manatools UI skeleton to support the different UIs 21:03:01 <anaselli> well there is a work to do there too, but a starting point into a forked installer can be of help 21:03:50 <tmb> Akien, yeah, stage1 does not care about what stage2 uses... it only downloads stage2 and hands over control... so we need a stage2 that knows how to handle rich deps in some way... if no-one work on perl-URPM the choice finalizes itself 21:04:10 <Akien> I'm wary about talk of "forking" the installer. If we want to change the package installation backend, we need to make it modular in DrakX and add a new backend - not work in a different repo and have to do bugfixes in two places 21:04:33 <martinw> Akien: Agreed! 21:04:59 <Akien> tmb: Yeah, but at the same time if work does happen on perl-URPM it's weird to start working on an alternative backend that we wouldn't use :p 21:05:22 <Akien> So we need to decide on our preferred direction (with a fallback if it's too hard/doesn't work). 21:05:48 <Solbu> It seems we need to ask on the dev list if someone is willing to work on perl-URPM. Perhaps we could defer this feature for next meeeting? 21:05:55 <Son_Goku> we've been deferring this for a while 21:06:22 <Akien> I think we can't make a final call without Thierry's input, so I propose to write an email to dev@ presenting the two scenarios I described above - and for (2) we'd go with tmb's proposal to keep a fallback 21:06:25 <Son_Goku> we've also *tried* to organize some kind of meeting too 21:06:55 <Luigi12_work> yeah we need to move forward and we can't just keep finding excuses not to. Like tmb said we don't blow away what we have until we have something else, but in the meantime we can be working on something else. 21:07:01 <Solbu> Son_Goku: Maybe, but I don't remember seing a thread on this on the dev list. 21:07:18 <Solbu> Maybe I have bad eye-sight. ;-) 21:07:24 <Luigi12_work> also you really don't want to mix urpm*/perl-URPM and dnf for installation of packages, as orphan tracking isn't synced between them 21:08:15 <Akien> Yeah, that's why I'm proposing two scenarios which are either full perl-URPM or full DNF 21:08:52 <Son_Goku> also, yay, Luigi12_work, you're here! 21:09:34 <Akien> I don't want to be blunt, but last time we decided to "start the work and see how it works out", it was when the MCC abstraction/adminpanel/manatools work was started. Years later, we still haven't reached a decision. 21:09:34 <anaselli> Akien: shouldn't that mean to have to stage2 also? 21:09:55 <Akien> So before starting heavy "PoC" work to see if it works out, I think we need to agree on our overall direction. 21:10:12 <Akien> Do we want to keep maintaining perl-URPM and do it well, or do we want to switch to DNF. 21:10:56 <Solbu> Akien: In the mail to the dev list we could set a deadline on when it need to be deciced, and if no input, the decistion is «X». 21:11:01 <Luigi12_work> only tv wants to keep maintaining perl-URPM, only he's done it for years, and we never know how long that can continue. no community of developers has formed around it. For dnf stuff, there has. Seems pretty obvious to me. 21:11:05 <Son_Goku> I'll be blunt, I don't know if we can keep maintainer perl-URPM 21:11:05 <anaselli> Akien: the direction is to change, but following a lnoger way if we are not sure to be ready for mga8 21:11:07 <Akien> I tend towards the latter, but I want a real discussion with tv (and other devs like pterjan/blino who have some URPM experience) so that we agree about it. 21:11:38 <Luigi12_work> and we may not have made a "decision" on the mana stuff yet but at least it's being worked on and a lot has been implemented. At some point we do have to allow users to see it though. 21:11:39 <Son_Goku> fwiw, I'm still trekking along on what I can do to get things going for option 2 21:11:55 <kostuek> sounds like dnf got more future and perl-URPM is dying tech, just by listening to this conversation 21:12:15 <Son_Goku> I'm also in conversations with DNF upstream about our needs in regards to the work they're doing with libdnf 21:12:37 <Son_Goku> as anaselli knows, I've attempted to include our developers in the conversation a couple of times now 21:12:40 <Akien> Solbu: Yeah I agree. 21:12:52 <Solbu> Just to be clear, I have no personal opinion on which is the good choice, as I'm not the one who have to do any of the changes. :-9 21:12:56 <Son_Goku> heh 21:13:22 <Akien> I just want us to have tv on board for the needed changes if we're going the DNF route, so I don't want to decide now without asking him for comments. 21:13:30 <Solbu> I just like how the the urpm tools work. :-) 21:13:37 <anaselli> Son_Goku: yeah and tv answered also, once 21:13:53 <Son_Goku> I'm on board with incorporating good parts of urpm behavior into the DNF stack too 21:13:56 <Akien> tmb's proposal seems a very safe way to go for the DNF backend work, but it should at least have tv's acknowledgement 21:14:08 <anaselli> iirc he wasn't really against am i wrong? 21:14:19 <Son_Goku> nah, he wasn't against it 21:14:20 <Akien> For example if tv is OK to switch to DNF provided this PoC works, then it's good. 21:14:37 <Son_Goku> he just wants it really well planned and done 21:14:50 <Son_Goku> I got the feeling he thinks I have no idea what I'm asking for :P 21:15:16 <anaselli> so woriknig on a branch is safe enough? 21:15:19 <Solbu> Son_Goku: Maybe he know what he's talking about. ;-) 21:15:25 <Son_Goku> possibly 21:15:26 <Akien> I think with tmb's proposal we start to see a good possibility for this change 21:15:31 <Son_Goku> anaselli: I think so 21:15:50 <anaselli> if also tmb helps there... 21:16:01 <tmb> I mailed tv today to get his input / plans / interests in urpmi vs dnf vs everyting .... I hoe he will respond soon-ish... 21:16:04 <Akien> We can start by making the backend modular, make sure that the perl-URPM backend still works without regression, and work on a new one. 21:16:04 <anaselli> i think we can even move faster than we think... 21:16:15 <mokraemer> but we are stuck with this topic. i don't think we get a decision now 21:16:44 <Akien> Yeah, so again my proposal is to write an email about it presenting the two scenarios I proposed above + tmb's proposal for (2) 21:16:51 <mokraemer> ack 21:16:55 <Akien> With a deadline to reach a decision as Solbu proposed 21:16:59 <Akien> (2 weeks?) 21:17:30 <Son_Goku> sounds okay to me 21:17:39 <anaselli> but 21:17:46 <DavidWHodgins> The time frame for the changes will likely have an impact on our proposed schedule for Mageia 7 21:17:59 <tmb> yeah, that sounds like a good plan... 2 weeks should be enough to respond... 21:18:00 <anaselli> we have to consider developers more than user feelings 21:18:10 <DavidWHodgins> Agreed 21:18:29 <Son_Goku> Akien, can you write the agreed statement 21:18:30 <Son_Goku> ? 21:18:31 <DavidWHodgins> Both 2 weeks, and developers feelings 21:18:33 <Akien> And I will count on you guys to keep the debate alive and constructive, I don't want to send an email and get no response and in 2 weeks we're at the same point :p 21:18:42 <Akien> Son_Goku: ok 21:19:16 <Solbu> Sure. Let the flamewar begin! :-) 21:19:22 <DavidWHodgins> :-) 21:19:33 <anaselli> fwiw i always tried to be constructive :p 21:19:35 * tmb searches for asbestos underwear 21:19:39 <Son_Goku> oh boy 21:19:48 <Son_Goku> clearly I'm in for hell :P 21:20:02 <tmb> :) 21:20:04 <anaselli> pointing to paradise :D 21:20:06 <kekePower> don't kill the messenger! 21:20:07 * DavidWHodgins to blame for sticking my nose into a packagers meeting. :-) 21:20:13 <Son_Goku> it's fine 21:20:29 <Son_Goku> I'm just becoming exhausted on going in circles 21:20:37 <Son_Goku> I hope this finally gets us somewhere 21:20:50 <Solbu> DavidWHodgins: A non-packager often see things from another perspective. 21:20:51 <Akien> #agreed A decision needs to be taken on the general direction of the project re DNF vs URPM (as backend, not frontend). New RPM features need to be supported (e.g. rich deps) and this can be done either by porting our tools to a DNF backend, or by improving perl-URPM to bring it in sync with modern features. An email will be sent to describe the two scenarios, with a decision to be taken within 2 weeks. 21:20:53 <Son_Goku> there are some other outside parties interested in this too 21:20:57 <anaselli> Son_Goku: welcome :p 21:21:25 <wilcal> Include the QA mailing list please 21:22:55 <Luigi12_work> the urpm* shims to DNF will give us the best of both worlds, it'd be exciting for our future 21:23:03 <Son_Goku> :) 21:23:04 <martinw> You need to keep emphasising that this should be transparent to the users - the urpm* commands are not going away 21:23:13 <Luigi12_work> yep, that's important 21:23:29 <Son_Goku> that's actually part of the Switch to DNF feature 21:23:38 <anaselli> u mean console user i guess.... 21:23:41 <Son_Goku> yeah 21:23:46 <mokraemer> jepp. I would prefer to have shared chaches for all users,like urpm 21:23:52 <Son_Goku> the people that drudge through the CLI 21:24:02 <martinw> Yes, but every time you mention switching to DNF, that's what people think about 21:24:07 <Akien> martinw: Yeah I think it's an important point for the transition 21:24:18 * Solbu do all his package management in the console. :-) 21:24:33 <anaselli> martinw: that's why we should consider developers and not simply users 21:24:48 <Akien> And I think that if we do choose to switch to DNF as a backend, we'll get contributors for the urpm* frontends 21:24:50 * kekePower has disabled mageia-mgaonline.desktop 21:24:55 <Son_Goku> yeah 21:25:04 <Akien> We're all lazy and want to keep using what we know, so we'll make sure it works :p 21:25:13 <Luigi12_work> yeah having the urpm* shims on RHEL would rock 21:25:23 <Luigi12_work> we can spread the joy of our wonderful commands that are better than all the others 21:25:26 <Solbu> kekePower: I always uninstall it. 21:25:30 <Akien> :D 21:25:33 <anaselli> if we use the Son_Goku work.... is py :p 21:25:37 <kekePower> :-) 21:25:46 <Luigi12_work> but yeah as long as urpm* still exists, none of this matters to the users, only developers (developers, developers, developers!) 21:25:46 <Akien> Yeah, let's take over the world with urpm* shims :D 21:25:51 <Son_Goku> heh 21:26:13 <Solbu> Luigi12_work: LOL. 21:26:22 <Son_Goku> yeah the urpm shims would work on Fedora, Mageia, and openSUSE when using DNF :) 21:26:35 <Son_Goku> and even CentOS with the new dnf/yum4 preview builds 21:26:38 <anaselli> alias urpmi='dnf'? 21:26:46 <Son_Goku> hehe not quite that simple 21:26:48 * anaselli hides 21:27:25 <anaselli> so... it should dnfdragora :D 21:27:55 <Solbu> Perhaps it's time we move on to the next feature? :-) 21:27:57 <martinw> Time to move on? 21:28:09 <Akien> Yeah 21:28:14 <anaselli> yeah i feel very tired ;) 21:28:36 <Akien> So that one was "positively received", pending general approval on the DNF/perl-URPM direction 21:28:56 <Akien> #info https://wiki.mageia.org/en/Feature:Provide_an_educationnal_mageia_flavour 21:29:08 <Akien> #info Provide an educational mageia flavour 21:29:14 <Luigi12_work> like EduMagic or MagOS or whatever that other group made before? 21:29:32 <kekePower> I think Edubuntu or whatever it is called is more than enough 21:29:36 <DavidWHodgins> If it's just a "group" that can be selected when installing packages I'm ok. If it's new iso images, I'm against. 21:29:36 <Luigi12_work> I wonder what ever happened to them 21:29:55 <Luigi12_work> yeah I mean anyone's free to make their own "spin" but it doesn't have to be an official Mageia product 21:29:55 <Akien> Well if Edubuntu is more than enough, then Ubuntu is more than enough too :p 21:29:56 <anaselli> wow i seem to recall my old task-edu package 21:30:31 <Luigi12_work> we just need proyvind's better-than-bcd tool so people can make ISOs easier/more-efficiently 21:30:39 <kekePower> Akien: Not much so, but what's the advantage of having an educational package? 21:30:40 <Akien> I think we could make sure that we have a good task-edu metapackage, and if that works well, we can consider making custom live ISOs with mklivecd 21:30:42 <Luigi12_work> assuming they want classical installer ISOs, otherwise they can use draklive 21:30:52 <Akien> kekePower: Getting Mageia installed in schools 21:31:02 <anaselli> Luigi12_work: livecd-creator? 21:31:06 <kekePower> Akien: Get 21:31:14 <kekePower> Akien: Get'em early? 21:31:23 <Akien> Yeah :o) 21:31:27 <Luigi12_work> it certainly worked for MS 21:31:35 <Akien> I started with Mandrake at university, never looked back 21:31:35 <Luigi12_work> future developers!... 21:31:54 <martinw> It's easy enough to make custom Live ISOs with draklive - and that provides an installer too 21:32:06 <Akien> A wait no, stormi was a the university and installed me Mandrake, I was still in middle school :p 21:32:23 <Luigi12_work> time flies 21:32:38 <Akien> 12 years ago, heh 21:32:57 <Luigi12_work> unfortunately I can't access mageia.org right now (broken proxy) so I can't comment on the text of the actual feature we're discussing 21:33:11 <Akien> Well there's no text :D 21:33:13 <kekePower> How can we differentiate Mageia from the other Edu distros out there? 21:33:14 <mokraemer> same for me at university, some time ago 21:33:20 <Akien> It's just "if we want to be used more, like in scools, we need to have a flavour with preinstalled softwares and web filtering configured ( dansguardian ). " 21:34:06 <DavidWHodgins> I'd expect different schools to want differnet filters selected, so don't see how this can be pre-configured as a one size fits all solution. 21:34:12 <Luigi12_work> I don't think we have dansguarding but we do have ufdbguard 21:34:16 <anaselli> DavidWHodgins: indeed 21:34:35 <Luigi12_work> if you want to use it like a parental filter, you need filter databases or a ufdb subscription 21:34:43 <Solbu> Isn't privoxy a dansguardian fork? 21:34:47 <kekePower> Is there a gui frontend for Puppy that can be used to promote changes throughout a school network? 21:34:59 <kekePower> for school sysadmins 21:35:05 <anaselli> I think a way could be to provide if someone wanted to some livecd-creator kicostarts for them 21:35:06 <tmb> meh, just filter everything but mageia.org... that'll teach them :) 21:35:15 <Solbu> Heh. 21:35:40 <anaselli> so that building a edu live should be easy 21:35:45 <Luigi12_work> right 21:35:45 <Akien> All in all, I think that more than a feature for mga7, this should be a SIG committing to work on having a good task-edu, and then work with some school contacts to see what they'd expect 21:35:57 <Akien> Then this SIG can make a live ISO for Mageia 7 21:36:10 <Luigi12_work> well, the important effort on *our* part is just making sure it's easier to make spins of Mageia 21:36:28 <Luigi12_work> so that's our ISO tooling and the packaging efforts w.r.t. branding 21:36:33 <DavidWHodgins> Or a new tool similar to draklive that's easy for instructors to configure 21:36:44 <Akien> martinw seems to say it's relatively easy 21:36:59 <Luigi12_work> if you want a "live" yeah draklive is probably relatively easy already 21:37:31 <anaselli> Luigi12_work: maybe 21:38:17 <anaselli> i wonder how many people really tried to change a configuration file to add or remove package using draklive...? 21:38:35 <tmb> we could provide updated wiki pages and some nice default configs for draklive 21:39:11 <martinw> Yes, the documentation needs an overhaul... 21:39:30 <anaselli> tmb: good start point, however i recall blino also could not help me to have a console live cd I needed... 21:39:33 <tmb> but anyway, its not a "mga7" specific topic imho... it could be done now already 21:39:48 <anaselli> agree 21:39:51 <DavidWHodgins> While there are a lot of other options to help create an edu system, this feature seems to be about creating new iso images, which I'm against. 21:40:08 <kekePower> Does Mageia have many educational packages? 21:40:13 <DavidWHodgins> s /new/additional/ 21:40:15 <anaselli> but first we need to get Pharaoh_Atem back :D 21:40:23 <tmb> DavidWHodgins, well, it depends on who will do the QA on the isos 21:40:58 <Akien> I think the Q&A on the edu ISOs would be done by the Edu SIG 21:41:05 <tmb> if a scool wants isos we could say yes we can help, but you need to do the QA (we only test they boot) 21:41:06 <Luigi12_work> if the people proposing the feature did the QA that might work 21:41:35 <Akien> Such ISOs also wouldn't need to be in pre-release testing at all 21:41:53 <Akien> They'd just be e.g. the Xfce ISO + some more packages and some less 21:42:00 <Pharaoh_Atem> I'm back 21:42:01 <Luigi12_work> I think we have more hard-core audio work packages than educational stuff currently but we have some (hmm I wonder if anyone would want to make a spin for audio stuff) 21:42:04 <Pharaoh_Atem> wifi broke so I'm back on my desk 21:42:35 <Pharaoh_Atem> Luigi12_work: incidentally, I agree w.r.t making spins easier 21:42:46 <Luigi12_work> yeah that's the important part for us 21:42:54 <Akien> Anyway, neoclust needs to flesh out his proposal before we can take a formal decision. 21:42:57 <Pharaoh_Atem> a big part of what I want to get done this cycle is make it easier for structures like SIGs to take care of their little variants of Mageia 21:43:06 <Akien> On the principle, the idea is fine, but right now this issue doesn't say much apart from "let's make an ISO" 21:43:08 <Pharaoh_Atem> but yeah, I have no idea what neoclust's proposal even means 21:43:28 <Pharaoh_Atem> it's a good idea, but there's no details or concrete plans 21:43:30 <Akien> Before making an ISOs for schools, people interested in it should check with said schools what their needs would be 21:43:47 <Akien> It makes no sense to do a lot of work on this if nobody uses it 21:43:54 <Pharaoh_Atem> yep 21:44:00 <Luigi12_work> yeah we can probably table this one until later 21:44:17 <Pharaoh_Atem> for what it's worth, such flavor spins probably could be considered non-release blocking and cycled/QA'd independently 21:44:26 <Pharaoh_Atem> this is the approach that Ubuntu and Fedora have 21:44:31 <Pharaoh_Atem> and it seems to scale well 21:44:43 <Luigi12_work> yeah, not part of the "release train" 21:44:50 <Akien> #agreed Educational spin feature needs to be fleshed out with more details about how it will be done, who will participate, who will do the Q&A, etc. 21:44:56 <Solbu> One argument against it is that schools don't like having to upgrade to the new distro every 9 months. 21:44:59 <Pharaoh_Atem> you mean QA, but yeah :) 21:45:08 <Akien> Right :D 21:45:12 <Luigi12_work> Solbu: I don't think that's relevant at all 21:45:23 <Luigi12_work> an upgrade would be deploying a new image 21:45:35 <Akien> Solbu: well we do LTS's now, no? :p 21:45:49 <Akien> Soon 3 years of mga5 :D 21:45:57 <Solbu> Akien: Heh. :-) 21:45:57 <Luigi12_work> we should go for 2 more 21:45:58 * Luigi12_work hides 21:46:06 <DavidWHodgins> lol 21:46:28 <Akien> Anyway, let's move on 21:46:35 <tmb> well, mga5 kernel will be supported for 6 years upstream so :) 21:46:37 * Solbu still have a running mdv2010.2 system, in daily use. :-) 21:46:54 <Akien> #info https://wiki.mageia.org/en/Feature:Python3_as_default 21:46:58 <Akien> #info Python3 as default 21:47:04 <Pharaoh_Atem> I have no problem with this feature 21:47:14 <Pharaoh_Atem> especially since Mageia 7 is releasing at the tail end of Python 2's life 21:47:26 <Luigi12_work> as long as that means stuff in the default install is ported to python3, that's fine. No changing /usr/bin/python, that'd be insane. 21:48:05 <Akien> Well Arch Linux changed /usr/bin/python I think 21:48:15 <Luigi12_work> we already know they're crazy 21:48:18 <Akien> But I'm not saying we should do it 21:48:21 <Solbu> Heh 21:48:23 <Luigi12_work> :o) 21:48:45 <Pharaoh_Atem> we should not change /usr/bin/python like OpenMandriva and Arch did 21:48:53 <Pharaoh_Atem> that breaks way too many assumptions 21:49:04 * Pharaoh_Atem speaks from experience on OpenMandriva 21:49:17 <kekePower> reminds me of when PHP released php3 and then when they released version 4, they went back to using .php 21:49:26 <Pharaoh_Atem> I'd rather do that *after* Python 2 is EOL 21:49:31 <Pharaoh_Atem> which would be Mageia 8 timeframe 21:49:38 <Akien> Yeah, I think we can just let /usr/bin/python RIP and continue with the convention that the binary is /usr/bin/python3 21:49:41 <Akien> Heck, the language is "python3", "python" doesn't exist :p 21:49:48 <Luigi12_work> exactly 21:49:51 <Pharaoh_Atem> well, the language is Python 3000 :D 21:49:53 <Pharaoh_Atem> but yeah 21:50:18 <Akien> Py2 is EOL in 2020, so I think making Py3 default for mga7 is good. 21:50:21 <Pharaoh_Atem> if they release an updated PEP that advises that /usr/bin/python should be Python 3, then we'll change it 21:50:26 <Akien> What does this imply concretely? 21:50:38 <Akien> - Rename all python-module to python2-module 21:50:43 <Luigi12_work> why? 21:50:48 <Pharaoh_Atem> it means that the base should not include Python 2, and that %python_provide should switch unversioned python- names to python3 packages 21:50:54 <Luigi12_work> python is python and python3 is python3 21:50:57 <Akien> - Keep all python3-module as is I guess? Make them provide python-module? 21:51:07 <Luigi12_work> no way 21:51:43 <Luigi12_work> probably the actual important things are making sure the default install is all py3 and making sure python packages have python3 builds whenever possible 21:51:48 <Pharaoh_Atem> yeah 21:52:04 <Pharaoh_Atem> sorry, I mean %python_provide switch should happen after PEP announcement about unversioned python change 21:52:08 <Luigi12_work> I know there are some packages we haven't enabled python3 builds for yet that we could 21:52:16 <Akien> And switch all python apps that can to use their python3 flavour 21:52:19 <Pharaoh_Atem> yes 21:52:19 <mokraemer> if everything is ported to python3, why keep python2 as well? 21:52:30 <Luigi12_work> because people have lots of python scripts 21:52:45 <Akien> this ^ 21:52:51 <mokraemer> and they don't work with py3? 21:52:51 <Pharaoh_Atem> removing Python 2 entirely is a decision I'd rather punt to after EOL 21:52:58 <Solbu> mokraemer: We have python packages that doesn't «speak» python3. 21:53:17 <Luigi12_work> mokraemer: python and python3 are very similar but slightly incompatible languages 21:53:20 <Pharaoh_Atem> mokraemer: py3k was an incompatible language change to fix several issues in the language 21:53:34 * Solbu is the upstream maintainer of one of the affected python packages. :-) 21:53:43 <Luigi12_work> PySolFC 21:53:55 <Solbu> … and I don't know python. ;-) 21:53:57 <Luigi12_work> you should rename it to PySolbu 21:53:58 <mokraemer> thats quite the same thing as we had between the php releases. 21:54:05 <kekePower> lol 21:54:05 <Akien> For example PyGTK+2 apps are likely all Py2 :) 21:54:10 <Pharaoh_Atem> I've been gradually pushing things I maintain or touch to Py3 21:54:32 <Akien> mokraemer: well, that's much worse than php 21:54:38 <mokraemer> ic 21:54:39 <kekePower> I know rindolf wants PySolFC ported to Py3 21:54:45 <Pharaoh_Atem> think of the php4 -> php5 transition 21:54:47 <kekePower> better 21:54:49 <Akien> Python 3 was released 9 years ago 21:54:53 <Pharaoh_Atem> that was a painful one because OO semantics changed entirely 21:55:17 <Luigi12_work> python is a victim of its own popularity 21:55:23 <Akien> And *today*, many still write Python 2 stuff by default 21:55:26 <Pharaoh_Atem> Perl has had the same problem, too 21:55:31 <Akien> Like new apps in Python 2. 21:55:38 <Pharaoh_Atem> Perl 6 has not seen the adoption that the creators hoped 21:55:39 <Luigi12_work> yep, people are still teaching Python (not Python3) classes all over the US 21:55:52 <mokraemer> i think this is a common script language problem ;-) 21:55:56 <Pharaoh_Atem> yep 21:56:12 <Akien> Well, who uses C++11 or later? :p 21:56:18 <mokraemer> me 21:56:25 <Luigi12_work> the developers at my work are just starting to 21:56:44 <martinw> me too 21:56:54 <Akien> Anyway, I think the feature can be marked as approved, we just need to better define/discuss what will be done exactly. 21:57:03 <Luigi12_work> yeah 21:57:10 <mokraemer> ok, so we have to keep py2 and add py3, but they need to be installable in parallel? 21:57:18 <Luigi12_work> they already are 21:57:38 <Akien> #agreed Python 3 as default is agreed upon, the exact changes to do needs to be better defined and discussed. 21:57:50 * tmb will have to head to bed soon-ish 21:57:57 <Pharaoh_Atem> this probably coincides with a resync of our packaging guidelines with Fedora/openSUSE 21:58:00 * Luigi12_work heads home in less than an hour 21:58:40 <Pharaoh_Atem> do you think we can cover a few more items? 21:58:54 <DavidWHodgins> Or resume tomorrow at 20utc? 21:58:59 <Pharaoh_Atem> that's an option too 21:59:01 <Solbu> The next feature looks like it could be a quick one. 21:59:08 <Luigi12_work> I think we can knock out a few more 21:59:18 <kekePower> Solbu: that's what they all say :P 21:59:22 <Pharaoh_Atem> cool, let's do it 21:59:31 <Akien> Maybe we can review this one before tmb leaves 21:59:35 <Akien> #info https://wiki.mageia.org/en/Feature:Support_rEFInd_boot_manager 21:59:49 <Luigi12_work> if someone implements I don't see why not 21:59:50 <Akien> #info Support_rEFInd_boot_manager 21:59:57 <Pharaoh_Atem> I have no problem with this particular feature 22:00:00 <Pharaoh_Atem> it's kind of neat 22:00:04 <martinw> I implemented it 3-4 years ago 22:00:10 <Luigi12_work> bam, done 22:00:11 <Pharaoh_Atem> years ago? 22:00:19 <Pharaoh_Atem> wow 22:00:21 <Pharaoh_Atem> then, okay 22:00:23 <Pharaoh_Atem> approved? 22:00:27 <tmb> yeah, approved 22:00:32 <DavidWHodgins> Only for uefi systems? 22:00:38 <Pharaoh_Atem> yes 22:00:42 <Pharaoh_Atem> it's UEFI only 22:00:43 <Akien> Good for me too :) 22:00:43 <Luigi12_work> I wonder if coling ever got gummiboot working 22:00:44 <DavidWHodgins> Ok 22:00:45 <martinw> The patches need updating, but it won't take long 22:01:05 <Pharaoh_Atem> #agreed Support rEFInd boot manager is approved 22:01:14 <Pharaoh_Atem> martinw: do you think it'd be easy to extend for sd-boot, too? 22:01:37 <martinw> What's sd-boot? 22:01:38 <mokraemer> it needs integration into the installer? 22:01:49 <Pharaoh_Atem> martinw: systemd-boot is the gummiboot successor 22:01:57 <Pharaoh_Atem> it's a uber minimal boot manager 22:02:08 <Pharaoh_Atem> used primarily for appliances and certain types of servers 22:02:16 <Pharaoh_Atem> it uses bootloader spec style configuration 22:02:29 <martinw> mokraemer: yes 22:02:31 <DavidWHodgins> Hopefully one that's installable to a partition, that only lists kernels on that partition 22:02:32 <Pharaoh_Atem> #link https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ 22:02:47 <Pharaoh_Atem> there are patches being written to make GRUB also use this style config 22:02:56 <Pharaoh_Atem> so that it's not a pain to add/remove entries anymore 22:03:36 <Pharaoh_Atem> #link https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/ 22:04:21 <martinw> Would seem quite different to rEFInd 22:04:21 <Pharaoh_Atem> anyway, it's just a thought 22:04:24 <anaselli> sorry i'm almost done... will read the meeting report later 22:04:27 <Pharaoh_Atem> don't worry too much... 22:04:28 <anaselli> bye all 22:04:30 <tmb> well, the bootloader spec should be taken out and shot, twice... and buried deep 22:04:43 <Solbu> good night anaselli. 22:05:00 <Pharaoh_Atem> ehh, anyway 22:05:07 <Pharaoh_Atem> while tmb is still here, there's one more core thingy 22:05:15 <Pharaoh_Atem> #info: Proposed feature: https://wiki.mageia.org/en/Feature:Use_GRUB2_for_booting_Live_and_Classic_Installer_ISOs 22:05:25 <Luigi12_work> yikes 22:05:26 <Pharaoh_Atem> #info Use GRUB2 for booting Live and Classic Installer ISOs 22:05:34 <Pharaoh_Atem> this is a doozy 22:05:40 * Luigi12_work stopped at "Use GRUB2 for..." 22:05:40 <Pharaoh_Atem> I'm not sure we can actually do this 22:05:52 <martinw> Why not? 22:06:15 <Pharaoh_Atem> does GRUB2 support the isohybrid boot process? 22:06:23 <martinw> I've got a branch of draklive that does it 22:06:34 <Pharaoh_Atem> well, then 22:06:45 <Pharaoh_Atem> I guess as long as no one has any objections to that, then I don't see a problem with it 22:06:50 <joeghi> Pharaoh_Atem: I was using refind and then the mga loader in cascade. A little bit long, bit in the end you can seek all the refind plugins. Works better for running MGA on macbooks. ;-) 22:07:01 <Pharaoh_Atem> ;) 22:07:19 <Akien> I'm for it, we no longer even propose to install grub-legacy so it would be more consistent to use GRUB2 also for non-UEFI installers 22:07:32 <joeghi> tmb: btw, great job on virtualbox 5.2.x. 22:07:35 <Luigi12_work> what do they use now? 22:07:52 <Pharaoh_Atem> Akien: this is about non-uefi boot 22:07:52 <martinw> It gives a consistent look and feel to the Live ISOs 22:07:54 <Pharaoh_Atem> on ISOs 22:08:00 <Pharaoh_Atem> they use isolinux with isohybrid 22:08:07 <martinw> We already use grub2 for UEFI boot, obviously 22:08:22 <Pharaoh_Atem> martinw: I'll probably need some help from you to adapt livecd-tools for this 22:08:26 <tmb> well for iso boot... I havent checked what is needed for language support in grub2 22:08:26 <martinw> so the doc team have to create two sets of screenshots 22:08:42 <martinw> I've done a PoC for language support 22:08:50 <martinw> There's a few limitations... 22:09:21 <tmb> like ? 22:09:45 <martinw> grub2 can't render some glyphs well ... mainly Indian languages 22:10:09 <Akien> Isn't it a font problem? 22:10:11 <martinw> Currently any text in the theme file can't be translated 22:10:26 <martinw> which is the 'e' to edit, 'c' for command line stuff 22:10:28 <Akien> For gfxboot we use a tailor-made font including all the glyphs we need 22:10:47 <Pharaoh_Atem> iirc, grub2 supports being built with freetype2 and using otfs/ttfs 22:10:59 <martinw> Not just a font problem. IIRC it's something to do with ligatures 22:11:04 <joeghi> martinw: refind and grub coexists, refind uses EFI/boot/bootx64.efi which can coexist with /boot/EFI/mageia/grubx64.efi 22:11:33 <martinw> The comment in the grub2 manual says help is welcome to fix this... 22:12:00 <Akien> Ouch, font shaping is *hard* 22:12:32 <martinw> Arabic and Chinese looks OK (at least to my uneducated eyes) 22:13:27 <Pharaoh_Atem> the only conflict would be if we implemented shim support 22:13:34 <Pharaoh_Atem> which atm is not a proposed thing 22:13:43 <martinw> Our custom Mageia font used in the grub2 theme doesn't have nearly enough clyphs, but presumably we could fix that 22:14:01 <martinw> At the moment grub2 just falls back to its default font 22:14:01 <Akien> Anyway, we have the same drawback for the UEFI ISOs currently, I guess? 22:14:12 <Pharaoh_Atem> yeah 22:14:18 <Pharaoh_Atem> it's not significantly worse than what we have now 22:14:24 <martinw> Yes, for uEFI there is no language support in the boot menu 22:14:33 <Pharaoh_Atem> I'm okay with this, I hope martinw will help me with making this supported in livecd-tools 22:14:36 <Pharaoh_Atem> as I have no idea :P 22:15:07 <Akien> And since BIOS is nearing EOL, the UEFI bootloader will be the most used so we can also make the change for non-UEFI, and work on improving i18n. 22:15:10 <tmb> I think we should go for switching to grub2 for now... it it works bad during iso testing we can always fall back 22:15:18 <Pharaoh_Atem> yeah 22:15:24 <Pharaoh_Atem> we should switch to grub2 across the board 22:15:34 <Pharaoh_Atem> and consider an upgrade strategy for grub legacy users 22:15:59 <mokraemer> jepp, like me ;-) 22:16:09 <martinw> Note this feature is only about the boot menus on the ISOs themselves, not the installed systems 22:16:39 <tmb> yeah, so this feature for boot menus approved.... 22:17:10 <Pharaoh_Atem> #agreed Use GRUB2 for booting Live and Classic Installer ISOs is approved as it unifies the experience between UEFI and non-UEFI systems 22:17:38 <tmb> and I will now have to say good night... and thanks for a somewhat productive meeting :) 22:17:43 <DavidWHodgins> Need something on the boot menu to indicate whether it's in uefi or bios mode though 22:17:45 <Luigi12_work> thanks tmb, good night 22:17:55 <mokraemer> n8! 22:18:05 <Akien> The two features "Switch to DNF" and "Upgrade urpmi to new rpm" were already discussed today and pending same decision, so we can skip them. 22:18:08 <Luigi12_work> how many are there left to review? 22:18:13 <Akien> Good night tmb, thanks for being around :) 22:18:14 <Solbu> God natt, tmb 22:18:27 <Akien> Luigi12_work: 4 22:18:32 <Akien> And some should be fast 22:18:37 <Luigi12_work> ok 22:18:47 <martinw> David: Yes, I've already done that :-) 22:18:54 <Akien> #info https://wiki.mageia.org/en/Feature:Review_mandriva-everytime.service 22:19:03 <Akien> #info Review mandriva-everytime.service 22:19:06 <DavidWHodgins> martinw: Thanks 22:19:09 <Akien> Oh that's mine :D 22:19:12 <Pharaoh_Atem> yep 22:19:15 <Pharaoh_Atem> you have a feature :D 22:19:25 <Luigi12_work> it probably needs to be broken down into a bunch of smaller services 22:19:26 <martinw> Admittedly at my prompting... 22:19:28 <Pharaoh_Atem> actually, I think we can kill it 22:19:43 <DavidWHodgins> I normally disable it, so removing it is fine with me. 22:19:48 <Pharaoh_Atem> splitting them out into their own timers/services is better than this weird bunched up psuedo-cron thing 22:19:57 <Luigi12_work> yeah 22:19:58 <Solbu> That one should have been renamed, to mageia-everytime. 22:20:05 <Pharaoh_Atem> and some of those are dead, too 22:20:10 <Pharaoh_Atem> like dkms_autorebuild 22:20:14 <kekePower> good night and thanks a lot for a very educational meeting 22:20:15 <Luigi12_work> well it was implemented in mandriva days, you don't really rename these things 22:20:16 <Pharaoh_Atem> this was supplanted years ago in dkms itself 22:20:19 <Akien> Yeah I think it should be split, and each subservice should be reviewed/updated 22:20:24 <Akien> (or removed) 22:20:26 * kekePower is grateful 22:20:27 <Pharaoh_Atem> yep 22:20:37 <Luigi12_work> yeah that sounds right 22:20:42 <Akien> Thanks for joining the discuss kekePower and good night 22:20:54 <Luigi12_work> approved? 22:20:55 <Pharaoh_Atem> for this feature, I think this is absolutely approved 22:20:59 <Akien> Ok, so approved. 22:21:00 <DavidWHodgins> Yes 22:21:13 <martinw> service_harddrake is the biggest problem IMO 22:21:16 <Pharaoh_Atem> #agreed Review mandriva-everytime.service is approved. Hopefully we can kill some awful legacy beasts! 22:21:33 <martinw> but we really need tmb's input on that one 22:22:02 <Akien> Yeah we'll still have to discuss what can be done, it should start with auditing what it does exactly 22:22:14 <Pharaoh_Atem> well, I'll be poking him about this anyway, as I'm rebasing initscripts now with the latest tag from Fedora 22:22:14 <martinw> He has commented in the past that the kernel now handles most H/W detection, so a lot of what service_harddrake does is redundant 22:22:23 <Pharaoh_Atem> and wrong, too, imho 22:22:28 <martinw> And it does make booting the Live ISOs awful slow 22:23:01 <Pharaoh_Atem> anyway, next feature! 22:23:13 <Akien> #link https://wiki.mageia.org/en/Feature:Simplify_method_of_updating_.iso_installer_between_releases_and_between_QA_pre-release_testing 22:23:16 <Akien> #info Simplify method of updating .iso installer between releases and between QA pre-release testing 22:23:28 <joeghi> martinw: the problem is compatibility. There are already mandrake forks which are not using that (omv, rosa), but for server point of view IMHO is pretty different. 22:23:32 <Akien> There's a wiki formatting oops on that one :) 22:23:32 <Luigi12_work> so what's the story with this feature? 22:23:42 <Pharaoh_Atem> I don't know what this says 22:23:58 <Pharaoh_Atem> everything just kind of runs over 22:24:21 <Luigi12_work> maybe something that could/should be discussed on the qa-discuss list? 22:24:25 <Pharaoh_Atem> yeah 22:24:30 <Pharaoh_Atem> this feels like something that needs more fleshing out 22:24:39 <DavidWHodgins> Agreed 22:24:56 <DavidWHodgins> I'll bring that one up on the qa list. 22:25:02 <Akien> Ok I think I understand where benmc is coming from 22:25:05 <Pharaoh_Atem> #agreed "Simplify method of updating .iso installer between releases and between QA pre-release testing" needs more fleshing out. QA will discuss this and figure out what it means for further review 22:25:36 <martinw> I think the basic problem was that ISOs kept being released to QA with out-of-date graphics, etc. 22:25:42 <DavidWHodgins> I understand it, just don't remember the details of the problems it's trying to fix 22:25:51 <Akien> It sounds like he was troubled by several times during QA testing where the branding was inconsistent, with e.g. the wrong background image on grub, a missing "beta" or "RC" name in the installer, etc. 22:25:56 <martinw> e.g. RC ISOs with a installed sidebar saying sta2 22:26:01 <Luigi12_work> and bcd problems created a lot of bad ISOs that were unnecessary 22:26:06 <Luigi12_work> a better tool would help the process 22:26:07 <martinw> s/installed/installer/ 22:26:24 <Pharaoh_Atem> let's identify the problems and figure out how to fix them 22:26:39 <martinw> Ben is very thorough about checking the small things... 22:26:49 <Pharaoh_Atem> it could be something as simple as non-"final" builds being date stamped everywhere, including in the graphics 22:26:51 <DavidWHodgins> Better than I am. :-( 22:27:01 <Pharaoh_Atem> Fedora does something similar for the nightly ISO builds 22:27:06 <Luigi12_work> Pharaoh_Atem: not a bad idea 22:27:09 <Akien> All in all this is not really an issue IMO, this usually happens on the first round of testing and we always need more than one round 22:27:14 <Pharaoh_Atem> yeah 22:27:28 <Pharaoh_Atem> anyway, I think there's only one feature left 22:27:33 <Luigi12_work> w00t 22:27:35 <Pharaoh_Atem> err, two 22:27:36 <Pharaoh_Atem> but still! 22:27:38 <Luigi12_work> darn 22:27:41 <Luigi12_work> let's go 22:27:45 <martinw> Yes, but is frustrating for QA if they report these problems, and the next round still isn't fixed 22:27:51 <Pharaoh_Atem> #info Proposed feature: https://wiki.mageia.org/en/Feature:Use_systemd_presets_for_default_services 22:27:53 <Akien> It's good that QA notifies iso builders about it, but they shouldn't make a fixation about it - a wrong grub image in a dev1 build is not a big deal :D 22:28:04 <Pharaoh_Atem> #info Use systemd presets for default services 22:28:15 <martinw> Yes, but this was still happening in the final release testing 22:28:16 <Luigi12_work> Akien: true, it's not like that kind of issue is going to bleed into the final release 22:28:40 <DavidWHodgins> Akien: The problem is that we test so many builds, we forget to check some of the things even with checklists 22:29:06 <Luigi12_work> hopefully we'll have more automated tests someday 22:29:15 <Pharaoh_Atem> Luigi12_work: I'm hopeful for that :) 22:29:35 <Pharaoh_Atem> anyway, this feature is about making it so we have a central controlled set of services that we consider being default enabled 22:29:40 <Akien> All in all this branding issue will be improved if we ditch gfxboot (one less background to change), and we should change drakx so that it writes a common string in the sidebar instead of a hardcoded image 22:29:48 <Luigi12_work> so the systemd presets, IIRC does that basically determine whether or not a service is actually enabled when you do %_post_service %{name} ? 22:29:52 <Pharaoh_Atem> yes 22:30:05 <Pharaoh_Atem> if it calls systemctl preset, that's what it does 22:30:16 <Luigi12_work> Akien: if we ditch gfxboot then I won't have to update that package anymore, that'd be nice :D 22:31:04 <Pharaoh_Atem> this basically makes it easy to constrain what services are enabled by default for flavors and stuff too 22:31:06 <Luigi12_work> Pharaoh_Atem: so are there certain services installed by default that we're trying to make disabled by default instead? Is that the purpose of this? 22:31:14 <Pharaoh_Atem> yes 22:31:30 <Luigi12_work> in most cases if you install a package with an additional service (not installed by default) I'd think you'd want it enabled, so it wouldn't really affect most packages 22:31:32 <Pharaoh_Atem> basically, we should only enable services we want enabled, and assume everything else should be disabled by default unless the sysadmin has installed his own presets 22:31:37 <Luigi12_work> which services specifically are we trying to disable? 22:32:11 <Pharaoh_Atem> since we have tools like drakservice / manaservice to let people configure services, it's easy to turn stuff on 22:32:22 <Pharaoh_Atem> the main problem is that a lot of services do weird / terrible things when not configured properly 22:32:31 <Luigi12_work> yeah but I don't want to add additional unnecessary steps that just make things harder for no benefit 22:32:55 <Pharaoh_Atem> the main benefit is that flavors can have different defaults 22:33:03 <Luigi12_work> well we usually like things to work out of the box, so configured in a reasonable manner 22:33:07 <Pharaoh_Atem> and derivatives can too, and users/sysadmins can have their own setups 22:33:11 <DavidWHodgins> How many packages would have to be changed? 22:33:17 <Pharaoh_Atem> probably not many 22:33:18 <Luigi12_work> probably none 22:33:22 <Pharaoh_Atem> only ~4 22:33:24 <Luigi12_work> just change what the macro/script does 22:33:32 <DavidWHodgins> Ah. Ok 22:33:37 <Pharaoh_Atem> rpm-helper, mageia-release, initscripts, and drakservice/manaservice 22:33:40 <Pharaoh_Atem> that's pretty much it 22:33:46 <Luigi12_work> well right, change the ones that implement it 22:33:52 <Luigi12_work> but not the ones that have the services 22:33:55 <Pharaoh_Atem> right 22:34:01 <Pharaoh_Atem> this is NOT about changing the packages 22:34:22 <Luigi12_work> I think this feature might make sense, as long as we're not making this unnecessarily difficult for no reason or making excuses for poorly configured packages 22:34:36 <Pharaoh_Atem> my main motivation is for branding and derivatives 22:34:41 <Akien> Does this mean that services which were currently enabled by default might get disabled by default? 22:34:41 <Pharaoh_Atem> and flavors 22:34:50 <Pharaoh_Atem> Akien: on fresh installs if we choose that, sure 22:34:59 <Pharaoh_Atem> but anything currently enabled DOES NOT get disabled on upgrades 22:35:12 <Pharaoh_Atem> systemd respects user choices and existing state above presets 22:35:20 <Luigi12_work> I think we'll just need to be careful about what presets we come up with 22:35:23 <Akien> Ok. Fine with me then as long as we document it well in the release notes 22:35:29 <Pharaoh_Atem> naturally 22:35:29 <Luigi12_work> yeah that too 22:35:30 <Akien> And if we have sensible presets indeed 22:35:35 <Pharaoh_Atem> that's the goal 22:35:41 <Pharaoh_Atem> just make things sensible and sane 22:35:53 <Akien> Overall it sounds good :) Currently it's a bit messy 22:35:59 <Pharaoh_Atem> yep, that's why this :) 22:36:06 <Luigi12_work> yeah it always has been messy 22:36:25 <Luigi12_work> I hated in the SysV days when we patched out the runlevels the service should be enabled in from the init script headers 22:36:41 <Luigi12_work> this presets thing is a much better way to do that 22:36:51 <Pharaoh_Atem> #agreed Use systemd presets for default services is approved. We should ensure our default service set is sane and reasonable, too! 22:36:54 <Solbu> Maybe we could also list which services are enabled by default. 22:37:15 <Pharaoh_Atem> I don't have a problem with any of that 22:37:29 <Pharaoh_Atem> this just makes it easier for not-stupid to happen with service enablement on ISOs and things 22:37:40 <Pharaoh_Atem> anyway, LAST FEATURE!!! 22:37:56 <Luigi12_work> yeah things like systemd-stupid-unnecessary-thing.service getting enabled by default when it shouldn't be 22:38:06 <Pharaoh_Atem> that's precisely what this solves 22:38:09 <Luigi12_work> like resolvd and networkd and timesyncd etc 22:38:20 <Pharaoh_Atem> I don't even know anyone using networkd... 22:38:29 <Pharaoh_Atem> so... last feature 22:38:35 <Pharaoh_Atem> #info Feature proposed: https://wiki.mageia.org/en/Feature:XfceMageiaEnhanced 22:38:43 <Pharaoh_Atem> #info XfceMageiaEnhanced 22:38:45 <Luigi12_work> what's this featuer? 22:39:06 <joeghi> Pharaoh_Atem: most of such stuff are installed by default and remains there until someone is doing an hand tuning/debloating of systemd services... 22:39:07 <Luigi12_work> whoops, don't mind my French-typo 22:39:09 <Pharaoh_Atem> I think this is in response to our Xfce4 flavor not being quite as stylish 22:39:21 <Pharaoh_Atem> as our Plasma flavor 22:39:23 <DavidWHodgins> Making the xfce desktop look more like kde/gnome after intial install 22:39:24 <martinw> Seems to be someone who wants Xfce to look like Plasma 22:39:27 <Akien> For those with a nazi proxy :P 22:39:34 <Luigi12_work> yeah :o( 22:39:34 * Akien uploaded an image: image.png (101KB) <https://matrix.org/_matrix/media/v1/download/matrix.org/zyWVycglIRANuXbHsfwXKTEb> 22:39:43 <wilcal> You guys gotta be falling asleep by now. Wow. 22:39:52 <Luigi12_work> darn I can't get to that site either 22:40:06 <Luigi12_work> well XFce is XFce and Plasma is Plasma and GNOME is GNOME 22:40:10 <Luigi12_work> they're not supposed to be the same 22:40:11 <Akien> Luigi12_work: https://pasteboard.co/GVNC5MF.png 22:40:11 <martinw> I think our Xfce fans might object 22:40:18 <Luigi12_work> XFce is supposed to be lightweight-er too 22:40:20 <Pharaoh_Atem> I think making it stylish is fine, but lets play to Xfce 22:40:24 <Pharaoh_Atem> Xfce's strengths 22:40:36 <Pharaoh_Atem> making it look like Plasma is just asking for pain 22:40:48 <wilcal> No please don't do that 22:41:11 <Luigi12_work> I think I agree with some things on there and not others 22:41:41 <Akien> Yeah, overall this feature is more like enhancement requests for xfce maintainers 22:41:44 <DavidWHodgins> It's a matter of personal preference. In my opinion, best to stick with what ever upstream defaults to. 22:41:47 <Luigi12_work> 1 panel, compositing I don't agree with. Thunderbird, classic menu, volume thingy I do 22:41:50 <Akien> Well I mean for wally_ :) 22:41:52 <Pharaoh_Atem> as-is, I'm wont to reject this 22:41:59 <Akien> I don't think we want to plasma-ify Xfce 22:42:03 <Akien> But some of the things proposed make sense 22:42:41 <Akien> Yeah, I'd reject it as a feature but forward it as a list of suggestions to wally_ 22:42:43 <DavidWHodgins> I'm also against switching to thunderbird by default on it. The xfce iso images are targetted to low end machines 22:42:46 <Pharaoh_Atem> but if it was pared back and adjusted for xfce's strengths, then I'd be okay with it 22:42:46 <Pharaoh_Atem> Xfce is not Plasma 22:43:08 <Pharaoh_Atem> well, at the end of the day, this is wally_'s baby 22:43:23 <DavidWHodgins> So reject as the proposal is currently worded? 22:43:56 <Luigi12_work> yeah 22:43:59 <Akien> Yeah, it doesn't really fit the "features" format 22:44:20 <Akien> But we don't really have a platform for such wishlists either, so it's fine that magnux77 tried it like that :) 22:44:51 <DavidWHodgins> As in, reject nicely. :-) 22:45:19 <Pharaoh_Atem> #agreed XfceMageiaEnhanced is rejected as is. Making Xfce like Plasma by default doesn't play to Xfce's strengths or target. It may be worth sending along as suggestions to the Xfce maintainer (wally) to improve the default look and feel for the Mageia Xfce flavor 22:45:20 <Luigi12_work> this reminds me of ideas.mandriva.org way back in the day 22:45:23 <Luigi12_work> not much came of that 22:45:24 <Akien> Yeah. If wally_ wants to keep it as a "review task-xfce4 for potential improvements", why not 22:46:22 <Luigi12_work> I guess we're done 22:46:36 <Solbu> Wohoo. 22:46:46 <martinw> I'm feeling overdone... 22:46:46 <DavidWHodgins> Thanks everyone. Now we have the completed list of approved features, with the exception of the urpmi/dnf stuff which is to be decided within two weeks. 22:46:51 <barjac> joeghi: Hi You about? 22:47:01 * Luigi12_work heads home 22:47:20 <DavidWHodgins> A chair available to #endmeeting? 22:47:26 <mokraemer> puh. long meeting. 22:47:45 <Akien> Thanks everyone for attending :) 22:47:50 <Akien> mokraemer: Yeah don't worry, we rarely do this :D 22:47:54 <Pharaoh_Atem> That's all folks! 22:47:57 <Akien> #endmeeting