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