20:25:18 <ennael> #startmeeting 20:25:18 <Inigo_Montoya> Meeting started Tue Dec 19 20:25:18 2017 UTC. The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:25:18 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic. 20:25:29 <ennael> #chair tmb marja 20:25:29 <Inigo_Montoya> Current chairs: ennael marja tmb 20:25:48 <ennael> let's go :) 20:26:12 <ennael> #topic distrib-coffee is down 20:26:20 <Son_Goku> there's not a lot we can do about this 20:26:26 <wilcal> :-( 20:26:31 <Son_Goku> did we remove it from the mirrorlist entries? 20:26:32 <ennael> so last news are work in progress 20:26:40 <ennael> tmb: ? 20:26:45 <Son_Goku> it's already been blacklisted from the DNF mirrorlist for a while now, but I don't know about urpmi 20:27:08 <wilcal> mirrors.kernel.org seems to continue to be working 20:27:16 <ennael> what about official announcement ? 20:27:23 <ennael> at least to explain the current situation 20:27:38 <ennael> maybe it's done and I missed it 20:27:42 <tmb> I haven't heard any status from nanar since the mailing by marja 20:28:10 <tmb> I guess we should do a blog post ... 20:28:24 <ennael> yep 20:28:42 <marja> I get errors when doing "rsync -a --list-only" on distrib-coffee 20:28:44 <tmb> I've mailed mirrors-announce to ask them to switch mirrors, but since we have no control over that... 20:29:38 <ennael> #action work on a short blog post to explain the current situation 20:30:04 <marja> it was already mentioned here https://blog.mageia.org/en/2017/12/17/weekly-roundup-2017-week-50/ 20:30:05 <[mbot> [ Weekly roundup 2017 – Week 50 | Mageia Blog (English) ] 20:30:06 <filip> Trish already mentioned it in Weekly roundup 50 20:30:13 <marja> but the title doesn't show it 20:30:46 <tmb> bad thing with d-c is thar the initial re-sync should have been without exposing mageia rsync target as it now wiped several secondary mirrors.. so d-c gets hammered too 20:31:04 <marja> yeah :-( 20:32:21 <tmb> speaking of mirrors btw... we had a downstream mirror admin asking if we should start dropping obsolete releases from our mirror tree, or atleast move them to an "archive" that can be excluded 20:32:52 <Son_Goku> we have enough releases to start doing that, I guess 20:33:05 <filip> +1 20:33:29 <marja> that would be good, but should be announced, too (so mirrors can move them without deleting and redownloading the moved releases) 20:33:57 <marja> (if we choose to have an archive) 20:34:43 <tmb> I was thinking of maybe doing atleast something like supported -1 on tree, so while mga5 is supported, the ones on the mirrors would be 4, 5, 6, cauldron 20:34:56 <Son_Goku> makes sense 20:34:59 <marja> yep 20:35:01 <Son_Goku> that lets people safely do upgrades 20:35:05 <tmb> se when mga5 gets eol, we drop mga 4 20:35:23 <marja> yes 20:35:35 <Son_Goku> ideally, with mirrorbrain, people wouldn't notice when they move 20:35:37 <tmb> drop = move to archive 20:35:49 <Son_Goku> because download redirection would transparently point them to the right place 20:35:57 <Son_Goku> this is how it works in Fedora and openSUSE 20:36:06 <marja> ok 20:37:12 <schultz> supported -1 seems sensible to me 20:38:00 <Son_Goku> I think we could probably be more aggressive once we have the mirrorbrain stuff up, but for now it's perfectly sensible 20:38:23 <Son_Goku> we also should encourage the development of registered mirrors that offer the archived content, too 20:40:13 <filip> I guess now is a practical window to change mirror structure 20:42:20 <tmb> ok, I'll think about it a little and post on sysadm list about my suggested changes to see if the others have some objections / suggestions 20:42:35 <Son_Goku> coolness 20:42:37 <marja> tmb: thx 20:42:41 <filip> sounds great 20:43:42 <tmb> I just have to survive 2 more days of dayjob$ before I get xmas vacation and can do some mga stuff again 20:43:47 <Son_Goku> yay 20:44:16 <Son_Goku> then maybe we can have that chat about stuff longer than ~30-45 min 20:44:25 <tmb> yep 20:44:54 <marja> Akien: do you want to wait whether tv replies in your thread about dnf/urpm? Tbh, my impression of the replies is that we can't avoid to go for both 20:45:32 <tmb> anything else on mirror stuff ? 20:45:41 <marja> tmb: not here 20:45:46 <filip> +1 20:45:52 <Son_Goku> tmb: I think we're good on mirror stuff, I'll wait a couple of days before poking about mirrorbrain :) 20:46:05 <tmb> :) 20:46:23 <tmb> so next topic... 20:46:23 <filip> I'll adopt DL pages for mirrorbrain if/when ;) 20:46:27 <Son_Goku> :D 20:48:05 <tmb> #topic dnf ... to be or not ... 20:48:14 <ennael> :) 20:48:21 * Son_Goku sighs 20:48:53 <filip> I have a feeling that we're 50/50 at this ;) 20:49:32 <schultz> Similar, it seemed like people were almost unwilling to give a full endorsment to either without seeing more than is available now 20:50:35 <tmb> So... after trying to read pro/con in the discussion about this... 20:51:27 <tmb> I've also got a response from tv about his plans about URPM & co... 20:51:43 <marja> ah 20:53:15 <tmb> basically he wants to extend URPM to support all new features... but it's a long road and since he has 2 young ones he dont have all the time he would like to have 20:53:52 <ennael> (children are distro killers ;) ) 20:54:13 <Son_Goku> tmb: he mentioned that to me a couple months back as well 20:54:32 <marja> but there was at least one person in the thread who offered to help 20:54:42 <Son_Goku> I had an email from him about what he'd "like" to do, which included transitioning urpm to rpm-md 20:55:27 <Son_Goku> but it's quite a lot of work to essentially do what happened to yum to urpm 20:57:54 <tmb> so with that in mind... I suggest to start working on proper dnf integration but keep away from breaking URPM chain at any point for now... so the urpmi shims could be prefixed something like "dnf-urpmi" and so on so people can easily test to see if they can replace urpm* command line... 20:58:43 <Son_Goku> tmb: that's been my plan from the beginning 20:58:45 <tmb> branch drakx git to be able to see if we can replace urpmi with dnf... 20:59:03 <Son_Goku> if you look at https://gitlab.com/mdklinux/dnf-urpm/, that's how the commands are done now 20:59:05 <[mbot> [ Sign in · GitLab ] 20:59:25 <marja> Son_Goku: thx for that 21:00:42 <marja> sorry, I need to leave 21:00:48 <marja> good night all 21:00:48 <Son_Goku> I generally also like the idea of branching drakx and other tools and deliberately focusing on porting to dnf there 21:01:36 <Son_Goku> however, after looking at some of tools' code, I'm not sure it'll be easy to modularize the backend 21:01:38 <Son_Goku> it might by my unfamiliarity with Perl speaking, though ;) 21:01:39 <filip> all that sounds like a safest option to move 21:01:53 <Son_Goku> as I mentioned in the email thread, even the DNF transition path requires Perl programmers ;) 21:02:30 <Son_Goku> I'm going to try to start picking up Perl to be able to help with this, but I really hope we can have some Perlish folks help Angelo and myself 21:03:40 <Son_Goku> w.r.t. to the package build system, do we want to try for a deployment of koji or just swap iurt for mock in youri? 21:04:24 <Son_Goku> I had been working on code to plug koji into our existing workflows: https://gitlab.com/mdklinux/mgapkg-koji 21:04:25 <[mbot> [ MDK Linux / mgapkg-koji · GitLab ] 21:04:39 <Son_Goku> but I still need to actually get a test koji spun up and finalize the implementation 21:05:06 <Son_Goku> the new versions of koji in Cauldron provide Python 3 APIs too 21:05:09 <Son_Goku> so mgarepo can interface with it 21:05:56 <tmb> and if we can get dnf integration to work atleast as good as current URPM... really do a final go/no-go when people have tested it and if/when people are happy, do the switch.... but if it's not good enough for mga7 in ~3 months (since mga7 is estimated to land in ~5 months) postpone the final switch to mga8... 21:06:22 <Son_Goku> again, I have no problem with that either 21:06:44 <Son_Goku> I don't know how it's going to get done in 3 months, but only way to find out is to try 21:07:53 <tmb> yeah, the "3 months" might be too tight but since I think it's important to goet a new release out next spring to keep the momentu... 21:09:15 <tmb> but if we after 3 months see "we need ~2 weeks extra or so" we can maybe adjust... but basically nothing much happends in the distro during june-August... so we cant extend too long... 21:10:02 <Son_Goku> well, at least I can count on ignatenkobrain to help us with moving to DNF across our stack 21:10:28 <Son_Goku> hopefully other people will help too 21:11:46 <schultz> I would hope that once this has started and people see progress, either more support or more help will appear. 21:12:08 <schultz> Getting started now seems sensible, otherwise we will be in this exact position come mga8 21:12:27 <Son_Goku> yep 21:12:30 <tmb> I know I'd prefer to keep URPM since it's a huge part of our legacy, but realistically with current status I have to accept that dnf might be the better path in the long run... in order to support new rpm features I see as important enough to try to get in the distro 21:12:53 <Son_Goku> ironically, infrastructure is probably going to be easier than most other parts of the distribution to move over ;) 21:13:39 <Son_Goku> tmb: as I've said to others, I appreciate the Mageia/Mandriva legacy, but I believe this will make Mageia even better going forward 21:14:09 <Son_Goku> tmb: on the plus side, we don't need the fakever-fakerel hack in kernel packages anymore with DNF :) 21:14:20 <Son_Goku> multiversioned packages are properly supported in DNF 21:15:35 <tmb> Son_Goku, we used to have code in urpmi for it too, but since people can install with rpm directly, we decided to do protect them at all cost... hence the fake* 21:15:43 <Son_Goku> ah 21:16:00 <Son_Goku> iirc, rpm handles multiversioned packages properly directly now, too 21:16:29 <Son_Goku> it's been a long time since I've been forced to go to "rpm -ivh" :) 21:18:22 <Son_Goku> in any case, I look forward to working with every team as we begin our transition to DNF 21:18:38 <Son_Goku> tmb, hopefully in a couple of days, we can have an extended chat about all the things 21:19:17 <tmb> So, any objections... or are you/we ready to work on / show that dnf is the way forward (or not) 21:19:51 <Son_Goku> I'm ready.. ish... I'm a bit sick at the moment, but yeah :D 21:20:33 <filip> I think that this is the way to go. at least to move ;). 21:20:37 <Son_Goku> I'm excited, and I know that anaselli will be too 21:21:40 <schultz> Yep, it will be great to get it started and to see where it goes, I'm sure that there will be many big discussions to come once this start to move 21:22:33 <ennael> great to see an agreement here 21:22:36 <ennael> congrats 21:22:59 <Son_Goku> it's been a long two years to get to this point 21:23:06 <Son_Goku> hopefully it won't take that long to get to the next :) 21:23:57 <Son_Goku> tmb, ennael: can we have a final agreed marker here for this? 21:24:12 <Son_Goku> then we can move on to the next topic 21:25:17 <ennael> well at least to complete specs for mageia 7 and a short mail on dev ML 21:26:10 <filip> Son_Goku, you mean #agreed? 21:26:14 <Son_Goku> filip: yeah 21:26:25 <Son_Goku> forgot what it was :P 21:26:38 <Son_Goku> I don't ever really lead meetings, so I don't know them ;) 21:27:13 <ennael> ok what would be the next topic ? 21:27:45 <Son_Goku> good question? 21:28:04 <Son_Goku> basically the approval on the DNF feature means all the features related to it can be reviewed 21:28:20 <Son_Goku> they've been skipped in the past because of being tied with that feature 21:29:34 * Son_Goku just realized he didn't fill in the list of approved features from the last meeting 21:34:32 * Son_Goku just filled those in 21:34:47 <filip> driiin driiin 21:35:35 <Son_Goku> basically, the only features left on the review docket are the koji deployment and installer porting features 21:36:02 <Son_Goku> which I think the installer porting feature has basically been requested to be part of the DNF feature, so it's approved with it 21:36:43 <Son_Goku> I listed the koji deployment as a "requirement" of the dnf feature, but strictly speaking, the only actual requirement is to get us to use dnf for resolving deps in buildroots for building packages 21:37:02 <Son_Goku> that can also be done with mock and youri 21:37:06 <Son_Goku> or even modifying iurt to use dnf 21:37:55 <Son_Goku> but I think Koji offers us benefits that are worth having 21:38:33 <ennael> can we close the meeting for tonight? 21:38:36 <Son_Goku> sure 21:38:38 <Son_Goku> if you want to 21:39:07 <ennael> in fact falling asleep and still fighting with mageia bitcoin account 21:39:18 <Son_Goku> but someone needs to put a summary action / agreed thing about dnf item 21:39:22 <Son_Goku> then the meeting can be closed out 21:39:33 <Son_Goku> it's a pain to scroll through the logs to figure out what happened ;) 21:39:45 <filip> +1 21:41:00 <wilcal> bye all 21:41:05 <ennael> #action get dnf integration to work atleast as good as current URPM and take a final decision by then when tested in a wider way 21:41:09 <ennael> ok? 21:41:39 <filip> I think we #agreed. 21:41:59 <ennael> #action decision to be taken in 3 months 21:42:39 <schultz> Sounds great, really nice to have that wrapped up 21:42:53 <ennael> ok :) 21:43:05 <ennael> sleep well then and see you soon 21:43:11 <ennael> #endmeeting