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