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