19:07:08 <Akien> #startmeeting
19:07:08 <Inigo_Montoya> Meeting started Tue Sep 19 19:07:08 2017 UTC.  The chair is Akien. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:07:08 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:07:08 <ignatenkobrain> shall we start from dnf stuff ? =)
19:07:41 <Akien> #chair ennael marja tmb stormi DavidWHodgins
19:07:41 <Inigo_Montoya> Current chairs: Akien DavidWHodgins ennael marja stormi tmb
19:08:12 <Akien> So the topic of the day is to review the proposed features for Mageia 7: https://wiki.mageia.org/en/Category:ProposedFeatureMageia7
19:08:47 <Akien> Two weeks ago we had planned to take this meeting to review *and* approve them, but giving the number of the controversial nature of some of them, I think we should just have pre-review
19:09:03 <Akien> Several of those were filed only recently and still haven't been debated much on the MLs and IRC
19:09:13 <DavidWHodgins> Agreed. Too many are too recent to have been reviewed yet
19:09:25 <Akien> The dev team will likely organize a couple meetings to review them more in depth
19:09:48 <wilcal> QA has had a 2-week spirited discussion
19:10:00 <Akien> But if you agree I think we can still quickly go through them and gather some initial feedback, to quickstart the process
19:10:05 <Akien> *kickstart :D
19:10:11 <DavidWHodgins> Mostly about Mageia 5 to 6 upgrade problems
19:10:20 <wilcal> Agreed
19:10:24 <DavidWHodgins> Akien: Agreed
19:10:49 <wilcal> I've collected a list of what was discussed not necessarly decided upon
19:10:51 <Akien> Let's make a quick topic on the QA post mortem then maybe?
19:11:05 <Akien> Then we'll move on to the features
19:11:07 <DavidWHodgins> Ok
19:11:25 <Akien> #topic QA's Mageia 6 post mortem
19:11:29 <wilcal> Can I post my list now?
19:11:35 <DavidWHodgins> Main problem is https://bugs.mageia.org/showdependencytree.cgi?id=21340&hide_resolved=1
19:11:36 <wilcal> It's a good one
19:11:37 <[mbot> [ Dependency tree for Bug 21340 ]
19:12:01 <DavidWHodgins> Until we get those closed, upgrading using mgaapplet is still disabled
19:12:06 <Akien> wilcal: sure
19:12:11 <DavidWHodgins> wilcal: Go ahead
19:12:19 <wilcal> * Plasma was not a mature technology at the time of the M6 development launch.
19:12:21 <wilcal> * Yes or no. Drop DVD isos for 64-bit platforms.
19:12:22 <wilcal> * Decide & agree what is to be new or changed in M7.
19:12:24 <wilcal> * Implement these changes *before* starting any generic testing.
19:12:25 <wilcal> * Our stand on 32-bit. Keep for M7 only?
19:12:27 <wilcal> * The forseen ISO set [presume keep the 6 we have].
19:12:28 <wilcal> * Allow the Classic to grow to 4.7Gb (need 8Gb USB). Won't fit on a DVD disc.
19:12:30 <wilcal> * Cease to support* (= test) DVD booting on 64-bit ISOs/platforms
19:12:31 <wilcal> * Fewer public pre-releases (Alpha, Beta, RC).
19:12:33 <wilcal> * Do not publish a pre-release schedule.
19:12:34 <wilcal> * Decide on MCC or its new replacement.
19:12:36 <wilcal> * Decide on NetworkManager v drakwhatsit.
19:12:37 <wilcal> * consider making the size of the classic installation iso's smaller. 4.7GB DVD
19:12:39 <wilcal> propose isos be something less then 4.7GB. Maybe not fit on a 4GB USB stick but
19:12:40 <wilcal> for sure on a 8GB usb stick, The iso will be slightly too big for a 4GB stick,
19:12:42 <wilcal> but still small enough for a dvd
19:12:43 <wilcal> Very spirited on if we should have isos for DVD discs
19:13:33 <wilcal> I don't think we came to a consensus on any of these
19:13:47 <wilcal> Very strong feeling all ways
19:13:55 <DavidWHodgins> The plasma one, I see no point in discussing. That's not something we could possible of had any control over.
19:14:36 <Pharaoh_Atem> I don't know if there's anything we could have done there
19:14:38 <DavidWHodgins> The list wilcal just posted was originated by Lewis. I do not agree with some of them
19:14:47 <Akien> Dropping ISOs for 64-bit sounds a bit weird. Most Linux users run 64-bit.
19:15:01 <wilcal> I think it should be looked at as a guide post on new technologies we don't fully understand
19:15:07 <Pharaoh_Atem> and I would think it'd make sense to make more iterative public ISOs, rather than less of them
19:15:09 <wilcal> And I agree with David
19:15:30 <DavidWHodgins> What lewis was suggesting, was dropping testing of 64 bit iso images on real dvd drives, and only testing them from usb sticks
19:15:35 <Pharaoh_Atem> ah
19:15:35 <ennael> I'm sorry I cannot understand this discussion too many people speaking at the same time :)
19:15:41 <DavidWHodgins> I do not agree with this
19:16:06 <Pharaoh_Atem> umm, wouldn't 4.7GB still fit on a DVD?
19:16:09 <Pharaoh_Atem> that's a single-layer DVD
19:16:11 <wilcal> Should M7 be the last to support 32-bit?
19:16:23 <marja> wilcal: no
19:16:41 <DavidWHodgins> Pharaoh_Atem: Yes. That's the limit we had before we dropped it to fit on a 4GB usb stick for bug 11446
19:16:44 <[mbot> Bug: ["consider making the size of the classic installation iso's smaller", 'REOPENED', 'Anne Nicolas'] https://bugs.mageia.org/show_bug.cgi?id=11446
19:17:03 <tmb> well isos nooed to be tested that they actually boot from optical drive... the rest of the installer is tested regardless of how you boot
19:17:11 <Akien> ennael has a point, we won't manage to discuss this big list all at once :)
19:17:19 <ennael> :)
19:17:27 <Pharaoh_Atem> meh
19:17:30 <wilcal> So many issues to think about
19:17:34 <Akien> Let's maybe move the discussion on this feedback to the ML, where we can make inline answers and give our opinion about each point, otherwise this will drag on for a loooon time :)
19:17:43 <marja> +1
19:17:51 <Akien> And let's start reviewing the feature proposals one by one, that should be clearer :)
19:17:53 <ennael> and maybe not enough different point of view of users
19:17:57 <DavidWHodgins> I'll post that list to the council ml, with my opinion on each
19:17:59 <ennael> using ML will help
19:18:03 <wilcal> I agree Akien
19:18:09 <wilcal> Go for it David
19:18:15 <ennael> what about organizing a big survey in community
19:18:21 <ennael> about DVD vs USB key
19:18:23 <ennael> 32, 64
19:18:37 <wilcal> An issue for the discussion forum?
19:18:42 <ennael> a way to communicate and make good decisions
19:18:48 <ennael> not only
19:18:50 <Akien> That's a good idea yeah, we could make a framapoll or someting
19:18:53 <Akien> *something
19:19:01 <ennael> forums, ML,blog
19:19:10 <ennael> just need to propose a link to the survey
19:19:13 <DavidWHodgins> I think the list is something we, as council should decide on. Taking it to a wider audience will likely just slow things down, in my opinion
19:19:24 <tmb> well, we simply still need isos as some "new-ish" hw have buggy bioses that does not properly boot from usb
19:19:28 <ennael> it gives some feedbacks
19:19:39 <Akien> She doesn't mean that list, but ask people about their usage
19:19:44 <DavidWHodgins> tmb: Agreed
19:20:02 <Akien> What ISO do they use, what type of support medium, what DE, etc.
19:20:15 <ennael> it does not mean we will follow the result :)
19:20:26 <ennael> just have a better view of what is used and how
19:20:28 <Akien> Just to get a better image of what the community actually uses to help with our discussions
19:20:29 <DavidWHodgins> That particular item on that list is something I said I would not bring to the council, for that reason
19:20:37 <marja> this was interesting, too https://ml.mageia.org/l/arc/qa-discuss/2017-09/msg00086.html
19:20:39 <[mbot> [ qa-discuss - Discussions about QA tasks and requests - arc_protect ]
19:21:27 <marja> DavidWHodgins: btw, thanks for having shared that :-)
19:22:29 <Akien> I don't want the meeting to drag on too much so I propose two things:
19:22:46 <DavidWHodgins> So let's leave the rest of the discussion about the qa topics to the ml, and move on to the next topic
19:22:49 <Akien> - wilcal posts his summary of the QA feedback on the council ML, so that we can discuss the points which warrant it
19:23:17 <marja> Akien: I'd rather have DavidWHodgins post it with his comments (saves one mail)
19:23:26 <DavidWHodgins> I'll do it
19:23:30 <Akien> - we prepare a poll to get some usage info from our users, to help us define our objectives (we can discuss what the poll should contain on the ML, then publish it on forums, blog, etc.)
19:23:34 <Akien> marja: that works too :)
19:23:46 <wilcal> sounds like a plan
19:24:05 <Akien> #action DavidWHodgins posts summary of QA's feedback and ideas for Mageia 7
19:24:08 <DavidWHodgins> #action DavidWHodgins to post qa list for review to the council ml
19:24:16 <Akien> #action Akien starts a thread on the ML to prepare a poll asking users for usage feedback
19:24:16 <DavidWHodgins> #undo
19:24:16 <Inigo_Montoya> Removing item from minutes: <MeetBot.items.Action object at 0xf66327ec>
19:24:43 <marja> which one got undone, now?
19:24:44 <Akien> #topic Initial review of proposed features
19:24:59 <Akien> We'll see :D
19:25:14 <Akien> #link https://wiki.mageia.org/en/Category:ProposedFeatureMageia7
19:25:42 <Akien> I guess we should go alphabetically?
19:26:12 <Pharaoh_Atem> best way to go :)
19:26:19 <Akien> 31 proposals, we should not take more than 2 min on each in average if we want some sleep ;)
19:26:48 <Akien> So let's start and go fast. I guess at this stage we can mostly give a quick gut feeling whether this is doable, too fantasist, needs more discussion, etc.
19:27:00 <Akien> https://wiki.mageia.org/en/Feature:ARM_Port
19:27:21 <Akien> That's the Mageia 6 page, needs updating with new objectives for Mageia 7
19:27:47 <Akien> We still need pterjan and blino to give an update on making ISOs, etc., we now have built packages but otherwise it's kind of in a limbo
19:28:12 <ignatenkobrain> Pharaoh_Atem: Akien so ping me when you will come to dnf / koji / any-other-topic I might be interested in 🙂Neal definitely knows those
19:28:30 <Akien> Igor Gnatenko: sure
19:28:57 <Akien> #action Akien pings blino and pterjan regarding ARM status and objectives for Mageia 7 (+ ISOs for Mageia 6?)
19:29:01 <Akien> next
19:29:08 <Akien> https://wiki.mageia.org/en/Feature:Centralize_Mageia_branding
19:29:18 <Pharaoh_Atem> ah, the first of my features :)
19:29:46 <Akien> That's a good idea, I had also taken down some notes about this. Neal has a ton of features, but I think we can find a new owner for that one if need be (schultz maybe)
19:31:00 <Pharaoh_Atem> I really hope people who know better can take on some of them
19:31:04 <Pharaoh_Atem> I'm not superman
19:31:45 <Pharaoh_Atem> but most of these things were things that came up during Mageia 6 development that we decided to push to Mageia 7
19:31:49 <Akien> I think it should be quite consensual as long as we manage to define exactly what we want to refactor
19:31:49 <Pharaoh_Atem> so now it's just formalized-ish
19:31:52 <Pharaoh_Atem> yeah
19:32:09 <DavidWHodgins> No objection from me
19:32:12 <Akien> I'm ready to help with this too :)
19:32:26 <Pharaoh_Atem> thankfully, things like release notes and stuff is already in mageia-release, so we're halfway there :)
19:32:29 <Akien> Next one
19:32:30 <Akien> https://wiki.mageia.org/en/Feature:Eliminate_legacy_RPM_macros
19:32:38 <Pharaoh_Atem> another one :)
19:32:57 <DavidWHodgins> That one is entirely up to packagers, in my opinion. Should be decided by them.
19:33:07 <Akien> This one has started already and was discussed on the dev ML, basically it's pre-approved
19:33:14 <Pharaoh_Atem> :)
19:33:22 <Pharaoh_Atem> the effort began in Mageia 5 :)
19:33:22 <Akien> So it's just formalized in a way that will help us keep track of the work and fill the release notes :p
19:33:36 <Pharaoh_Atem> Yep
19:33:47 <Akien> So next one
19:33:49 <Akien> https://wiki.mageia.org/en/Feature:Eliminate_prefdm
19:34:02 <Pharaoh_Atem> this is one that neoclust really wanted to happen last year
19:34:19 <marja> and Colin before last year
19:34:24 <DavidWHodgins> My understanding is that prefdm is needed when changing video cards. How will that be handled without it?
19:34:31 <tmb> yeah, prefdm needs to die... but it takes some work
19:34:32 <Pharaoh_Atem> prefdm doesn't handle that at all
19:34:36 <Pharaoh_Atem> I filed the bug for it, and I think it's basically going to happen because we don't want another death spiral bug like last year
19:34:45 <Akien> It's a good one to have formalized as a feature IMO, that should help organize the work to actually get rid of it.
19:34:51 <Pharaoh_Atem> all prefdm does is tell which display manager is started at boot
19:34:58 <Pharaoh_Atem> the rest of it is handled by the DM itself
19:35:25 <DavidWHodgins> Ah. Right. If kdm fails, falls back to another dm.
19:35:37 <Akien> Approval-wise I think it won't be an issue, the harder part will be to find developers to work on it... But I think it's an important one and many want to remove it, so it should be doable
19:35:38 <Pharaoh_Atem> that part doesn't even work right now
19:35:50 <Akien> As mentioned, neoclust would likely help too
19:35:57 <Pharaoh_Atem> neoclust and I already know how to rip it out
19:36:05 <Pharaoh_Atem> the remaining bit is making drakdm aware of presets
19:36:14 <Pharaoh_Atem> or at least how to switch DMs
19:36:16 <Akien> Perfect :)
19:36:17 <tmb> and making sure upgrades work
19:36:25 <marja> that too
19:36:31 <Pharaoh_Atem> yeah, that shouldn't be terrible, but it is an important point
19:36:40 <Akien> Heh, that's gonna be fun :D
19:36:47 <Pharaoh_Atem> upgrades always are :P
19:37:01 <Akien> Pharaoh_Atem: the upgrade point might be worth mentioning on the wiki page
19:37:07 <Pharaoh_Atem> I can add that now
19:37:18 <Akien> Perfect
19:37:35 <Akien> Otherwise I think we're all fine with the change
19:37:39 <Akien> https://wiki.mageia.org/en/Feature:HostnameConfiguration
19:37:45 <Pharaoh_Atem> done
19:38:12 <Pharaoh_Atem> yay, one that's not me :)
19:38:31 <marja> Akien: elimination isn't a feature... what about using "Changes" instead of "Features", as Neal proposed?
19:38:37 <Akien> That one is mainly a usability issue for DrakX, as the feature already exists
19:38:56 <Pharaoh_Atem> oh god, a Feature to propose Changing Features to Changes
19:39:00 <Pharaoh_Atem> I didn't want to go there
19:39:08 <marja> Pharaoh_Atem: lol
19:39:24 <Akien> marja: Sure, I don't mind either way. For me it's the same, it's just a formal way to document something that will be worked on.
19:39:41 <Akien> Whether we want to call the result a feature, a change or a bug, doesn't matter much :p
19:39:44 <Pharaoh_Atem> haha
19:39:49 <marja> :-)
19:40:01 <Pharaoh_Atem> the hostname thing would be nice, it bites me often that I can't do that
19:40:24 <Pharaoh_Atem> what's worse is some fool overwrote localhost on the network to point to some hypervisor
19:40:29 <Akien> Yeah, it's already possible to configure the hostname but it happens during configuration of the network connection, and it's not very obvious
19:40:30 <Pharaoh_Atem> so that doesn't even work correctly :/
19:40:44 <Pharaoh_Atem> but that's a me problem
19:40:46 <marja> manahost works, though :-)
19:40:51 <Pharaoh_Atem> manahost is nice :)
19:40:58 <Akien> Having a DrakX window during install that lets you pick your hostname would be more user-friendly
19:41:23 <Pharaoh_Atem> brb, getting some water
19:41:24 <tmb> hostname change needs to be more visible, yes... it's basically moving the entry field from network to maybe "create users" page
19:41:29 <Pharaoh_Atem> next three features aren't mine anyway :)
19:41:46 <DavidWHodgins> Network hiccup here.
19:42:03 <Akien> So it's a good feature IMO, should also be relatively easy to implement once we agree on the design.
19:42:18 <Akien> (just checked manahost, it's pretty cool indeed :))
19:42:22 <DavidWHodgins> Yes, the machine should be given a name other then localhost, which may or may not be the same as the hostname on a nic
19:43:18 <Akien> The user who proposed the feature is not a dev though, so we need to find someone who can take charge of it
19:43:35 <Akien> (not necessarily implement it all, but organize the work around it)
19:43:49 <marja> ask LpSolit maybe?
19:44:02 <Akien> #action Akien looks for a volunteer dev to lead the work on https://wiki.mageia.org/en/Feature:HostnameConfiguration
19:44:07 <ignatenkobrain> btw, Fedora has default `localhost.localdomain` and it doesn't force you to change it
19:44:08 <ignatenkobrain> although you can
19:44:11 <Akien> marja: Yeah that's a potential designated volunteer :p
19:44:49 <marja> :-)
19:44:59 <Akien> Igor Gnatenko: Yeah it's the same on Mageia currently; but that feature proposal is about it being a bit too hidden, and many users end up not changing it while they might want to
19:45:27 <Akien> (and then not really know how to change it after the install)
19:45:28 <ignatenkobrain> it's hidden in anaconda as well... under network settings which no one opens..
19:45:41 <Akien> Hehe ok, same as DrakX :D
19:46:02 <Pharaoh_Atem> it's rather annoying, actually
19:46:07 <Akien> Next proposal:
19:46:08 <Akien> https://wiki.mageia.org/en/Feature:Hybrid_Graphics
19:46:08 <DavidWHodgins> Moving it to the screen where the first user is added, seems logical to me
19:46:47 <marja> Akien: nice, already 3 volunteers (including you)
19:46:51 <Akien> I filed that proposal today, and I already know that Giuseppe and Martin would likely be able to help me work on it
19:47:04 <Akien> And I guess we'll annoy tmb a few times too :p
19:47:10 <marja> :-)
19:47:15 <Pharaoh_Atem> I'm sure anaselli and I could look at seeing how to get that into manatools
19:47:24 <DavidWHodgins> We'll need volunteers with that hardware, to help testing it
19:47:53 <Pharaoh_Atem> ah, we probably need to move to glvnd for this too
19:48:06 <Pharaoh_Atem> a lot of stuff to make this less brittle would require libglvnd
19:48:08 <Akien> stormi and I have such hardware at least, and I think a few other devs
19:48:10 <DavidWHodgins> What's glvnd?
19:48:10 <Akien> So we'll do the testing
19:48:23 <Pharaoh_Atem> The GL Vendor-Neutral Dispatch library
19:48:46 <DavidWHodgins> Ok
19:48:47 <marja> I have an optimus, too (even if I disabled the discrete card in the BIOS)
19:48:48 <Pharaoh_Atem> it lets you load multiple GL libraries from different vendors, match them to harder, and dispatch GL calls to the correct GPU based on that
19:48:59 <Pharaoh_Atem> s/harder/hardware/
19:49:29 <Pharaoh_Atem> Fedora implemented this recently, and openSUSE flipped the switch a month ago, I think?
19:49:57 <Pharaoh_Atem> it also means that nvidia->nouveau fallbacks are possible
19:50:00 <Pharaoh_Atem> in limited circumstances
19:50:02 <Akien> So yeah this feature will need some research to be fleshed out a bit, but basically we should at least prevent users with such hardware from misconfiguring their Mageia with XFdrake
19:50:09 <Akien> (which happens quite often currently)
19:50:21 <marja> yeah :-/
19:50:26 <Akien> And ideally we'd also provide a nice integration and solutions for such users to benefit from their setup
19:50:31 <Pharaoh_Atem> Yep
19:50:32 <tmb> only nvidia-current supports glvnd, not nvidia340 and nvidia304
19:51:23 <tmb> so we have some hiccups switching to it but we could atleast try...
19:51:42 <Akien> Sounds like fun :)
19:51:49 <marja> lol
19:52:01 <Pharaoh_Atem> I might actually buy an nvidia card (blech) for this if I can scrounge up a box
19:52:02 <Akien> That's definitely a feature for which work should start early, we don't want to have to mess with this at beta/RC stage..
19:52:19 <DavidWHodgins> Do any hybrid graphics systems use nvidia340 or 304?
19:52:29 <Akien> I'll likely organize a meeting with interested devs to brainstorm and share existing knowledge to see how to do it
19:52:56 <Pharaoh_Atem> cool
19:53:11 <Pharaoh_Atem> for the sake of time, I think we could call this approved, with further details being worked out later?
19:53:12 <Akien> Some Optimus laptops use nvidia340, I'm not sure about 304.
19:53:20 <Akien> +1
19:53:28 <Akien> https://wiki.mageia.org/en/Feature:Improve_mageiatools_documentation
19:53:58 <Pharaoh_Atem> this is less of a feature/change and more of a thing we should just be doing in general
19:54:04 <Pharaoh_Atem> but in principle, I see nothing wrong with it
19:54:11 <Pharaoh_Atem> however, there's nothing actionable?
19:54:28 <Pharaoh_Atem> so what would be approved?
19:54:50 <Pharaoh_Atem> ah, that reminds me...
19:54:53 <Akien> Well it's basically approved I think, it goes without saying that more docs would be good
19:54:58 * Pharaoh_Atem makes a note to bug for manatools.mageia.org
19:55:02 <DavidWHodgins> Agreed
19:55:07 <Akien> Writing them will also be a good way for new contributors to get familiar with the code
19:55:35 <Akien> Ideally we'd have the infra to use a Pull Request workflow for that... but that's another feature proposal :p
19:55:45 <Akien> https://wiki.mageia.org/en/Feature:Installed_systems_to_be_self-identifying
19:55:56 <Pharaoh_Atem> umm
19:56:19 <Pharaoh_Atem> so in principle, I see nothing wrong with it, but doesn't this mean that there's no such thing as a reproducible image?
19:56:43 <DavidWHodgins> That would indicate how the system was installed (which iso/mirror, etc.), with history added for upgrades (iso/mgapplet, etc.)
19:57:28 <DavidWHodgins> Limited usefulness though, due to cloning of systems, etc., so may not be worth the effort
19:57:35 <Pharaoh_Atem> I'm surprisingly not comfortable with this feature
19:57:45 <Akien> So that would mean changes to ISO building to hardcode some build-related data + changes to DrakX to parse them, add installation-related info and dump that into /etc/wheredoicomefrom :)
19:58:14 <Akien> On the principle it sounds good, but yeah I think it might be too much work for little gain
19:58:29 <Pharaoh_Atem> there's also relatively easy ways to make this better without doing this
19:58:30 <DavidWHodgins> Agreed. I'm not in favour of this one myself.
19:58:34 <marja> indeed, I think it's too much work
19:58:37 <tmb> It's useful for QA, and draklive already can do it. And bcd can be updated for classical isos
19:59:00 <Pharaoh_Atem> tmb: I'm not doubting the possibility :)
19:59:03 <marja> tmb: can bcd be updated to do it automatically?
19:59:18 <DavidWHodgins> It's really only useful for qa during iso testing. I don't think it's worth it to spend time adding this.
19:59:23 <marja> tmb: so that the iso builder doesn't have to remember to do it?
19:59:39 <tmb> marja, yep. it's basically dropping one extra text file on iso tree before generation of iso
19:59:44 <Pharaoh_Atem> honestly, I'd just probably write the filename of the ISO with a datestamp
19:59:50 <marja> tmb: in that case, I'm for it
20:00:06 <DavidWHodgins> We currently use the DATE.txt file from the iso dir, to id which iso is being used
20:00:17 <marja> because iso testers do get confused sometimes
20:00:23 <wilcal> can the md5sum be put in there?
20:00:39 <Pharaoh_Atem> the image isn't made yet
20:00:46 <Pharaoh_Atem> how do you checksum something that doesn't exist yet
20:00:52 <ennael> I can build isos in 2 steps and so add a file in the root directory
20:00:57 <wilcal> ah
20:01:00 <Akien> Yeah we can't put any sum
20:01:15 <marja> DavidWHodgins: well, I've seen testers *think* they used a certain iso, while grepping for DrakX version in report.bug proved that it was an older iso
20:01:27 <tmb> Pharaoh_Atem, for iso QA it's best iso does not change name as that screws rsnc
20:01:29 <DavidWHodgins> True. Mistakes appen
20:01:31 <tmb> *rsync
20:01:31 <wilcal> I've always kinda wanted to know where a specific Vbox client came from
20:01:37 <Akien> I think Lewis' proposal mostly orginates from the fact that we used to have DATE.txt outdated for some builds
20:01:41 <Pharaoh_Atem> tmb: hmm
20:01:56 <Pharaoh_Atem> I guess, if you're trying to just pull and update
20:02:08 <DavidWHodgins> Akien: Correct. It's production must be automated
20:02:30 <Akien> If we can ensure that building ISOs always updates the DATE.txt info properly and makes it reliable, it should solve most issues.
20:02:34 <Pharaoh_Atem> yeah
20:02:39 <DavidWHodgins> Not a step in a manual procedure that can be overlooked
20:03:01 <Akien> If having only DATE.txt is a bit confusing, we could also have a BUILD.txt with a build number, so that testers know wwhat round they're testing
20:03:36 <DavidWHodgins> Sure. Anything that is unique for a given iso name
20:03:50 <tmb> the good point of adding info on isos is that when you move the iso and forget the DATE.txt, you still know what iso
20:04:38 <tmb> and when checking vms if that info is transferred to installed system, reporting a bug ie easier as you can check "this vm was installed from ..."
20:05:02 <tmb> So I do understand the problem Lewis wants to solve
20:05:22 <ennael> problem is to deploy that file on installed system
20:05:28 <ennael> as its not packaged
20:05:39 <Akien> It could also be nice for bugsquad to be able to ask bug reporters to paste the contents of e.g. /etc/install-info
20:05:49 <tmb> ennael, drakx can do it during finalizing install
20:05:55 <ennael> ok
20:05:55 <Akien> Or it could be dumped in /root like debug files
20:06:07 <Akien> But /etc is likely better
20:06:59 <Akien> So I think we agree that something can be done; either at the build folder level with better infos about the build number/date, or directly in the ISOs and then installed on the system
20:07:06 <wilcal> IMO we're not going to get through all of these today
20:07:23 <Akien> Will need some further discussion to define exactly what we want and how to do it, but let's move on
20:07:40 <Akien> Yes, let's do half of them maybe
20:07:50 <wilcal> Good plan Akien
20:07:55 <Akien> https://wiki.mageia.org/en/Feature:Langpack_Installation_with_Rich_Dependencies
20:08:31 <DavidWHodgins> That one depends on moving from urpmi to dnf as default, I think
20:09:02 <Pharaoh_Atem> nope
20:09:03 <Pharaoh_Atem> it doesn't
20:09:15 <tmb> or if we extend urpmi to handle rich deps
20:09:52 <tmb> currently drakx has logic to install lang packs according to locales at install time
20:10:28 <Pharaoh_Atem> Supplements is the tag that would be used
20:10:32 <Pharaoh_Atem> it's the reverse Recommends
20:10:37 <Pharaoh_Atem> urpmi would completely ignore it
20:10:49 <tmb> for now...
20:10:51 <Pharaoh_Atem> yes
20:10:57 <Pharaoh_Atem> until it is extended, supported, etc.
20:11:08 <Pharaoh_Atem> so this feature *does not* require killing urpmi
20:11:17 <DavidWHodgins> Ok
20:11:53 <Pharaoh_Atem> however, the Supplements tag and rich deps needs to be allowed by the build system
20:12:01 <marja> tmb: it's a pity the drakx logic doesn't work when updating packages
20:12:03 <Pharaoh_Atem> which currently blocks it as invalid content
20:12:05 <Akien> Well it sounds good to me if it doesn't complicate the packaging too much
20:12:16 <Pharaoh_Atem> Akien: it's a dead-simple addition :)
20:12:21 <Pharaoh_Atem> one liner, even
20:12:36 <tmb> marja, I didn't say drakx was perfect :)
20:12:41 <DavidWHodgins> No objection to the feature from me then.
20:12:41 <marja> tmb: :-)
20:12:53 <Akien> And yeah, regarding urpmi and the buildsystem, I hope that we can have improvements that also make this feature work for it
20:13:11 <Akien> But those are other topics :)
20:13:15 <Pharaoh_Atem> yes indeed
20:13:22 <Akien> https://wiki.mageia.org/en/Feature:Make_our_tools_standard
20:13:28 <Pharaoh_Atem> I don't get this one
20:14:12 <Akien> It sounds to me like neoclust is asking for manatools :D
20:14:20 <Pharaoh_Atem> yeah
20:14:46 <tmb> I guess it's about replacing "open-coded" stuff in drakx with upstream perl-* functions where possible...
20:15:06 <DavidWHodgins> Let's mark that one as more info needed, and move on
20:15:13 <tmb> it's actually something tv does from time to time when he has time for cleanups
20:15:41 <Akien> Ah right, I remember some discussions with LpSolit who found that several "home made" functions would be better replaces by established modules
20:16:04 <tmb> yep
20:16:10 <Akien> So yeah, that's a good idea, though it's also strongly linked to the discussions regarding the future of drakxtools vs manatools which we won't be able to avoid forever :)
20:16:15 <marja> He does have some stuff here http://search.cpan.org/~tvignaud/
20:16:17 <[mbot> [ Thierry Vignaud - search.cpan.org ]
20:16:41 <marja> s/He/tv/
20:16:42 <Akien> And definitely won't be able to discuss in depth tonight, so let's keep that one for a dev meeting
20:16:53 <Akien> https://wiki.mageia.org/en/Feature:ManaToolsAsDefault
20:16:56 <Akien> Well, talking about the devil :p
20:16:57 <Pharaoh_Atem> haha
20:17:14 <DavidWHodgins> That's a big one. Replacing mcc.
20:17:50 <marja> It's getting complicated, ManaTools had at least 3 tools that MCC doesn't have
20:18:04 <marja> but MCC has a lot of tools that aren't in ManaTools
20:18:04 <Pharaoh_Atem> and it's going to get more as anaselli and I and others write them
20:18:23 <marja> Pharaoh_Atem: nice!
20:18:25 <Pharaoh_Atem> one of the things we've been working on is a framework to make it easy to write new modules to plug into the framework
20:18:39 <Pharaoh_Atem> so new people can easily port things from MCC to ManaTools or write completely new ones
20:19:06 <Pharaoh_Atem> python-manatools is now a thing, for example: https://github.com/manatools/python-manatools
20:19:07 <[mbot> [ GitHub - manatools/python-manatools: A python framework to build ManaTools application ]
20:19:12 <DavidWHodgins> WIll require a lot of changes to the installers, too?
20:19:14 <tmb> well, switching to manatools also might also cause us to kill of current installer...
20:19:32 <Pharaoh_Atem> well, manatools is independent of the installer
20:19:50 * marja isn't ready to lose traditional installer
20:19:57 <Akien> Yes, but the installer is dependent of drakxtools.
20:19:58 <DavidWHodgins> Doesn't the installer currently share a lot of code with mcc?
20:19:58 <Pharaoh_Atem> but this is more about making it front and center and promoted and focused on
20:20:02 <tmb> well, drakx that you will be replacing is also the installer...
20:20:26 <Pharaoh_Atem> I think anaselli has some ideas about adapting drakxinstall to manatools
20:20:32 <marja> DavidWHodgins: yea, really a lot
20:20:32 <Pharaoh_Atem> having a manainstall, as it were ;)
20:21:03 <marja> Pharaoh_Atem: drakx-installer-stage2, too?
20:21:05 <Pharaoh_Atem> but as we've kept putting this off, that discussion and strategy has never happened
20:21:20 <tmb> so if tv decides to give up on that if we switch will cause that to have to be handled
20:21:21 <Pharaoh_Atem> marja: that's just an aspect of drakxinstall
20:21:42 <DavidWHodgins> My opinion, is go for it, but be ready to fall back quickly, if needed.
20:21:45 <Pharaoh_Atem> sure
20:22:23 <Akien> The problem is that we shouldn't have developers waste their time working on something if in the end we tell them it's not feasible
20:22:36 <Akien> So we'd need a kind of feasibility study regarding using manatools for the installer
20:23:01 <Akien> And then convince tv to help us work on the new codebase to make it happen :)
20:23:05 <Pharaoh_Atem> I mean, the fallback is just to delay the feature to Mageia 8
20:23:20 <Pharaoh_Atem> I think it's more critical that this is accepted as a thing we want to move toward
20:23:25 <tmb> yeah, we need to go either way to focus our efforts
20:23:30 <Pharaoh_Atem> because anaselli has been getting rather discouraged lately
20:23:31 <Akien> ManaTools is starting to have some good arguments, as it's no longer just "let's reimplement drakx", but it has some improvements.
20:23:40 <Pharaoh_Atem> and frankly, so have I about this... :/
20:24:10 <Akien> Pharaoh_Atem: That's why I'd like to get tv on board, and for that we'd need to be able to assess what's left to do to fully switch to manatools
20:24:48 <Pharaoh_Atem> and having parity on GTK+, Qt, and ncurses has been damn nice
20:24:53 <wilcal> Can a release have both tools MCC & manatools
20:24:58 <Pharaoh_Atem> yes
20:25:01 <DavidWHodgins> If the installers are going to be changed to use mana tools instead of mcc, that has to start now, in my opinion
20:25:10 <Akien> Well Mageia 5 and Mageia 6 have both :)
20:25:11 <filip> what about making a choice in MageiaWelcome (or some other option) user can choose either drak or mana
20:25:16 <DavidWHodgins> Pharaoh_Atem: For mcc, yes, for t he installers, I don't see how.
20:25:38 <DavidWHodgins> Having both would complicate things too much in my opinion.
20:25:46 <Pharaoh_Atem> well, the ncurses and a suggested GUI is useful for live media vs classic
20:25:57 <Akien> We can give choice, but you need to keep in mind that it's a complex code base, and maintaining both in parallel is quite hard
20:26:12 <Akien> Of all the fixes done to drakxtools during Mageia 6 development, how many were propagated in manatools code?
20:26:19 <Pharaoh_Atem> almost none
20:26:28 <Pharaoh_Atem> no one bothered to help with manatools at all besides myself
20:26:36 <Pharaoh_Atem> and I was helping him with dnfdragora
20:26:41 <Akien> And the other way around, if we make the manatools the default as config tool, but keep DrakX as installer, how do we sync fixed between the two?
20:26:56 <Pharaoh_Atem> the current impression is that people don't care about manatools
20:26:58 <Pharaoh_Atem> so no one bothers
20:27:06 <Pharaoh_Atem> my expectation is that if the feature were approved, that would change
20:27:23 <Pharaoh_Atem> and things would actually be synced with the expectation that we'd have a path to a singular manatools based system
20:27:36 <marja> wasn't manatools (as additional, not as default) approved long ago?
20:27:39 <Pharaoh_Atem> yes
20:27:42 <DavidWHodgins> I'm in favour of saying go ahead, as long as it's recognized that the installers must be updated too.
20:27:43 <Pharaoh_Atem> back in Mageia 4, I think
20:27:56 <Akien> Yes, but in order to approve that feature we need a migration plan, a feasibility assessment, something tangible that says "we can do it without heading in the wall".
20:28:19 <Pharaoh_Atem> to get that, we need some kind of commitment to the manatools project
20:28:22 <wilcal> Another KDE -> Plasma transition?
20:28:25 <Akien> Because syncing manatools with 3 years of drakxtools development already won't be trivial, and there's still a lot of work needed if we want to be able to rebase the installer on them
20:28:25 <Pharaoh_Atem> one person alone does a project not make
20:28:29 <marja> wilcal: yes, like that
20:28:39 <Akien> We're turning in circles here
20:28:52 <wilcal> next issue
20:29:03 <DavidWHodgins> wilcal: Not yet.
20:29:04 <Akien> I'm saying that to get any kind of commitment, we need more info, and you're saying that to get more info, we need more commitment.
20:29:07 <Akien> So things won't change.
20:29:26 <DavidWHodgins> All in favour of making a commitment to move to manatools?
20:29:33 <Pharaoh_Atem> Akien: we need someone to say, this is serious, we need to at least investigate and determine the path forward
20:29:41 <Pharaoh_Atem> whether it happens in Mageia 7 or Mageia 8 is beside the point
20:30:01 <Akien> Well we've been saying that for years already. Nobody ever said it's not serious.
20:30:02 <wilcal> I'm not in favor of another KDE -> Plasma transistion in M7 maybe M8
20:30:10 <Akien> But we're talking about our installer here.
20:30:23 <Akien> Yes, we can decide today to replace MCC with Manatools, no problem.
20:30:24 <filip> the question is also how long we can maintain drak tools
20:30:35 <wilcal> A hidden another year in the development cycle?
20:30:41 <Akien> But we can't possibly have a different backend for the installer and for the drakxtools, that's asking for bugs.
20:30:58 <marja> filip: LpSolit started helping with drakx
20:31:20 <Akien> An alternative is to ditch the installer, and keep only the manatools as configuration utility...
20:31:27 <filip> marja: great. but the time question remains
20:31:54 <tmb> and martinw is also fixing some...
20:32:06 <marja> filip: but we need more developers in both cases, when we keep DrakX, but also when we move on to Manatools as default
20:32:07 <filip> Akien: that seems like a plan for mga7
20:32:11 <marja> tmb: indeed
20:32:32 <tmb> filip, same goes for manatools... if no more people want to work on manatools it has the exact same problem...
20:32:49 <Pharaoh_Atem> we already have a few more developers for at least one of the manatools
20:32:52 <filip> tmb: good point
20:33:06 <Pharaoh_Atem> dnfdragora has four contributors, two from Fedora
20:33:13 <marja> nice
20:33:14 <Pharaoh_Atem> along with Angelo and myself
20:33:18 <Akien> So for me what we really lack as information now is: How feasible is it to make our installer use Manatools?
20:33:32 <tmb> switching a couple of devs for another couple of devs is not helping
20:33:40 <filip> indeed
20:33:47 <tmb> Pharaoh_Atem, so thats one tool... what about the rest...
20:33:58 <Akien> Well I don't want to switch, I'd want us to merge
20:34:33 <tmb> isnt manatools mostly python ?
20:34:41 <Pharaoh_Atem> manatools is mostly Perl
20:34:45 <marja> tmb: no, they started in Perl
20:34:45 <Akien> No, mostly perl
20:34:47 <Pharaoh_Atem> dnfdragora and the new manalog will be Python
20:35:13 <marja> tmb: and isodumper (also in manatools) is Python
20:35:17 <Pharaoh_Atem> ah, yes, that too
20:35:22 <tmb> ah, seems that solves part of the "merging hopes" then
20:35:32 <Akien> Yeah
20:36:07 <marja> and we do already have some Python in MCC (s-c-p), don't we?
20:36:08 <Pharaoh_Atem> our hope is that python-manatools will make it easier for new people to come in and make tools for manatools
20:36:11 <Pharaoh_Atem> marja: we do
20:36:25 <Pharaoh_Atem> and I upstreamed the change to s-c-p that allows integrating into MCC or ManaTools
20:36:27 <Akien> The main question is: how much work to bring manatools to drakx's state, and will tv be motivated to help with the new code base?
20:36:54 <marja> or the other way around
20:37:18 <filip> Akien: we need to ask them
20:38:12 <tmb> yep, because either way we go, we might end up with unhappy devs...
20:38:17 <Akien> So yeah, I guess we can try to organize a meeting with manatools and drakx devs, and see what happens
20:38:35 <marja> +1
20:38:45 <Pharaoh_Atem> as long as it gets us somewhere, I'm okay with this
20:39:01 * Pharaoh_Atem is fighting for anaselli, who could not be here
20:39:09 <Akien> It's going to be funky to organize a meeting where tv can come :p
20:39:19 <Pharaoh_Atem> that's going to be annoying
20:39:29 <Pharaoh_Atem> he never comes to meetings anyway
20:39:40 <Pharaoh_Atem> I don't even bother with rpmstack@ meetings because talking to myself is pointless
20:39:55 <Akien> #action A meeting should be organized with DrakX and Manatools devs to assess what we can/want to do
20:40:33 <tmb> Yeah, we shold try to list pro/con (or missing /present features) for drakx and manatools to get some idea of the workload
20:40:56 <Akien> +1
20:41:01 <filip> yeah. essential feedback is missing so it's hard to decide
20:41:19 <DavidWHodgins> With #1 con being rewriting the installers to use manatools
20:41:19 <Pharaoh_Atem> absolutely
20:41:35 <marja> Maybe invite some old DrakX devs, too... we seem to often forget that tv didn't write all of that code, and that he is just as unfamiliar with parts of it as anyone else
20:41:39 <Pharaoh_Atem> well, pro/con is a bit divisive
20:41:50 <Pharaoh_Atem> but a tally is needed anyway
20:41:56 <Pharaoh_Atem> we need to do a gap analysis :P
20:41:59 <DavidWHodgins> s /con/concern/
20:42:57 <Akien> Alright, should we quickly do a couple last features and call it a day?
20:43:02 <tmb> Pharaoh_Atem, yeah, that's why I tried to explain it better with missing/present stuff
20:43:31 <Pharaoh_Atem> oh hai ximion
20:43:42 <Akien> https://wiki.mageia.org/en/Feature:Migrate_to_Dist-Git
20:43:44 <Pharaoh_Atem> in case no one knows, ximion is the AppStream upstream dev
20:43:59 <tmb> For installer some have suggested switching to Calamares, but that's another debate :)
20:44:04 <Akien> Hi ximion :)
20:45:04 <Pharaoh_Atem> tmb: I have calamares packaged for Mageia if we wanted to go that road
20:45:12 <Pharaoh_Atem> I've sorta held it back for the moment due to other things
20:46:05 <ximion> hey ‎Akien‎ :)
20:46:19 <tmb> so, do we talk about more features, or...
20:46:46 <ximion> if there are any questions, I'll likely have to answer them later (but in any case, Neal will be faster I think ^^)
20:46:55 * ximion needs to run, back in 40min
20:48:15 <Akien> I posted https://wiki.mageia.org/en/Feature:Migrate_to_Dist-Git above but it went unnoticed :)
20:48:28 <marja> oops
20:48:34 <tmb> Ah
20:49:08 <tmb> well I dont think anyone is against switching package repo to git
20:49:20 <DavidWHodgins> That feature should be decided in a packagers meeting, I think.
20:49:29 <Akien> So basically that's our not-yet-finished svn2git migration for spec files + using the system designed by Fedora to avoid us having to design our own
20:49:31 <tmb> as it has been discussed several times
20:49:33 <Pharaoh_Atem> well, I just filed it because we have a bug for it
20:49:37 <Pharaoh_Atem> and it's easier to see
20:49:44 <Pharaoh_Atem> infra and packagers approved it a while back
20:49:48 <Pharaoh_Atem> we just haven't done it yet :)
20:50:07 <Akien> Yeah, I think it's consensual, but we'll need to organize a meeting with devs and sysadmins to see how to do it
20:50:08 <marja> Augier was working on moving svn pkgs to git, but he got stuck
20:50:22 <Pharaoh_Atem> and I'm working on packaging the distgit and pagure packages
20:50:40 <tmb> if we hold of for ~1 month, we only need to convert mga6 and cauldron
20:50:51 <Pharaoh_Atem> we don't want to keep historical data?
20:51:00 <Akien> The only question which was still open last time we discussed it is whether we want to use GitLab or Pagure to handle our packages - but since Fedora is developing their own infra around Pagure, it might make our life easier to go this way too.
20:51:08 <marja> tmb: well, if upgrading 5->6 works, then
20:51:17 <tmb> tell people to look in svn for older stuff
20:51:20 <Pharaoh_Atem> that, and GitLab is like ~200 deps
20:51:30 <Pharaoh_Atem> probably more if I go down the nodejs rabbithole
20:51:40 <Akien> Yeah
20:51:56 <Pharaoh_Atem> Pagure is ~5 missing deps
20:52:11 <Akien> But anyway, that's indeed something to discuss in a dedicated meeting (again! so many meetings to organize :D)
20:52:28 <tmb> marja, why wouln't upgrade 5-> 6 work ?
20:52:40 <Akien> Same for the next feature proposal: https://wiki.mageia.org/en/Feature:Migrate_to_Koji
20:52:57 <Akien> I propose to just skip it as it also needs a lot of discussion with devs and sysadmins, and this is likely not the place nor time
20:53:14 <Akien> But otherwise, Koji is a great buildsystem and could really be awesome to deploy for Mageia :D
20:53:20 <Pharaoh_Atem> LIVE BUILD LOGS!
20:53:28 <tmb> And why koji, why not obs or others ?
20:53:30 <Pharaoh_Atem> and also building ISOs
20:53:33 <Akien> I propose to finish with this one:
20:53:33 <Akien> https://wiki.mageia.org/en/Feature:Migrate_to_MirrorBrain
20:53:38 <marja> tmb: upgrading with mgaapplet has been disabled, because when upgrading KDE to Plasma, the screen goes black (or something like that)
20:53:43 <ennael> (merge mageia to fedora ? ;) )
20:53:47 <tmb> and live build logs adds more traffic /load on infra
20:53:54 <Pharaoh_Atem> tmb: so... OBS has the annoying issue of requiring Ruby on Rails
20:54:06 <Pharaoh_Atem> and also, I can't get it working on a non-SUSE system
20:54:14 <Pharaoh_Atem> and I've been trying for two years
20:54:27 <ennael> again this should be discussed later with proper people
20:54:53 <Pharaoh_Atem> and as for mirrorbrain, tmb is proper people
20:55:02 <Pharaoh_Atem> he has this mostly done-ish, I believe?
20:55:35 <tmb> yep, I should probably find some time to polish and document it
20:55:51 <Pharaoh_Atem> so this is a feature just to say it's a thing :)
20:55:54 <Pharaoh_Atem> easiest feature ever
20:55:58 <ennael> leaving very soon tomorrow. Good night all
20:56:11 <ennael> s/soon/early/
20:56:32 <filip> good night ennael
20:56:37 <DavidWHodgins> Let's wrap it up there. Either have another meeting later this week, or leave the rest till next week.
20:56:45 <wilcal> I agree David
20:56:53 <wilcal> next week
20:57:24 <marja> DavidWHodgins: am I wrong about 5->6 upgrading with mgaapplet still being disabled?
20:57:39 <filip> tmb: regarding mga5->6: https://bugs.mageia.org/showdependencytree.cgi?id=21340&hide_resolved=1
20:57:40 <[mbot> [ Dependency tree for Bug 21340 ]
20:57:47 <DavidWHodgins> marja: You are correct. That was the first thing I posted about in this meeting.
20:57:58 <tmb> I wont be available for meeting next week, I'll be on (pre-)Kernel Recipes and so will some others
20:58:10 <marja> DavidWHodgins: thx
20:58:15 <marja> tmb: enjoy!
20:58:21 <DavidWHodgins> I'll post a msg to the dev ml, reminding packagers that these bugs need to be fixed, and assigned to qa asap.
20:58:32 <wilcal> not critical next week. in 2-weeks
20:58:37 <Akien> tmb: Nice!
20:58:42 <marja> DavidWHodgins: thx
20:59:00 <tmb> Well the "Dropbox Segfault" cant possibly be a blocker by any measure
20:59:18 <Akien> They're not all blockers no
20:59:18 <filip> indeed ;)
20:59:28 <Akien> Nvidia loop and KDE black screen are though
20:59:57 <DavidWHodgins> tmb: Akien Agreed. I'll remove the blocker tag from that one.
21:00:04 <marja> ennael: good night
21:00:08 <tmb> I think I saw tv committed fixes for mageiaupdate going blank
21:00:51 <DavidWHodgins> Yes, but either not packaged, or not assigned to qa yet.
21:00:53 <Akien> DavidWHodgins: Well it's not a list of blockers
21:00:58 <Akien> It's just a list of upgrade issues
21:01:07 <tmb> but I'm not sure anyone has looked on if we can handle nVidia crash properly yet
21:01:13 <Akien> So it's valid in that tracker, it just means that we don't need to fix all bugs before we can reenable upgrades
21:01:49 <Akien> tmb: I think Martin had done some work, but was lacking feedback/approval for his proposals
21:02:25 <Akien> So, good night everyone :)
21:02:26 <tmb> Iäll bookmark that tracker and will see if I can get some time to review
21:02:33 <Akien> Tons of work in the coming days to organize the dev team...
21:02:46 <filip> thx Akien
21:02:47 <marja> tmb: thx
21:02:49 <Akien> #endmeeting