20:40:25 <malo_> #startmeeting
20:40:25 <Inigo_Montoya> Meeting started Tue Feb 11 20:40:25 2014 UTC.  The chair is malo_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:40:25 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:40:37 <malo_> Good morning everyone!
20:40:48 <coling> "morning" to you too :)
20:41:15 <malo_> #topic Who's new?
20:41:54 <malo_> Since this is the first meeting post mga4, and since we haven't had a meeting in a while, maybe we have new participants
20:41:55 <sander85> don't be so shy!
20:42:04 <doktor5000> \o/
20:42:13 <diogenese> :)
20:42:25 * doktor5000 gets popcorn
20:42:26 * tmb is feeling ancient :)
20:42:30 <sander85> :)
20:42:37 * coling is working on a greybeard
20:43:04 <Akien> I'm not that new, but new with submit rights :)
20:43:07 <malo_> all right, no one, or people are just shy :-)
20:43:16 <malo_> Akien: welcome to the team \o/
20:43:27 <Akien> I've started breaking cauldron, but it's hard!
20:43:34 <Stormi> I can show you
20:43:56 * coling hasn't updated to cauldron yet so you're all safe from my interference for a little while :)
20:44:35 <malo_> We'll wait a week or two before discussing how to break cauldron for mga5
20:44:47 <malo_> Ok, First topic of the night
20:44:57 * sander85 just got his pid eins working, so it's a bit easier to play with cauldron on cli now that mga4 supports systemd-nspawn :)
20:45:04 <malo_> #topic Mageia 4 Postmortem
20:45:32 <malo_> As usual, we have a wiki page https://wiki.mageia.org/en/Mageia4_Postmortem
20:45:57 <malo_> This is still empty
20:46:03 <coling> :)
20:46:11 <coling> So it was "perfect" then. Next topic ;)
20:46:37 <tmb> :)
20:46:38 <diogenese> :)
20:46:44 <sander85> i can see few lines there :)
20:46:58 <malo_> So it's time to think about the aspects that went well and the ones that didn't
20:47:35 <sander85> major features came too late.. again :)
20:47:37 <tmb> nothing went well, and the rest can be improved... next... :)
20:47:51 <pterjan> build fixes happened very late :(
20:48:00 <coling> Well, I guess one thing that went well was that we were able to provide new desktops, thanks to some new packagers.
20:48:01 <pterjan> like java stack was broken
20:48:14 <coling> But on the flip side, this meant more QA work.
20:48:26 <malo_> Before starting to fill that page, maybe we should do the postmortem of the postmortem of mageia 3
20:48:30 <pterjan> and java stack migration to new way of building was cancelled
20:48:30 <Kharec> hi all
20:48:34 <Kharec> sorry for the late
20:48:40 <malo_> For ref: https://wiki.mageia.org/en/Mageia3_Postmortem
20:49:25 <Kharec> thanks malo_
20:49:50 <malo_> the post mortem of the postmortem of mageia 3 is that only AL13N had something to say :-)
20:51:15 <malo_> But the three points for mga3 were: choice of isos, release schedule/freeze/features, critical knowledge
20:51:33 <malo_> I think we're still quite happy with the isos, right?
20:51:39 <sander85> yes!
20:51:49 <Kharec> yes Latte
20:51:52 <tmb> no... they are non-booting on older hw :(
20:52:03 <sander85> yeah, that's true
20:52:06 <coling> Ouch. Is that due to syslinux?
20:52:14 <tmb> syslinux issue... we might have to think of re-release
20:52:23 <malo_> tmb: :-(
20:52:24 <Kharec> Sorry, I have no old hw. I sell it :/
20:52:39 <Kharec> tmb: outch
20:52:52 <malo_> tmb: but it's not the number of isos that is a problem
20:52:55 <Kharec> tmb: what do you call "old hw" ?
20:52:58 <tmb> it's a syslinux vs ahci... with a possible suggested fix
20:53:19 <tmb> but we need to build a test iso to confirm it
20:53:46 <coling> Can we just try with boot.iso?
20:54:05 <sander85> tmb: and there is no workaround? nor other media that boots?
20:54:07 <tmb> iirc it's more of a 32bit issue around 2004 +/- some years
20:54:16 <sander85> afaik booting from usb worked
20:54:23 <sander85> but old hw might not support it
20:55:08 <tmb> yep thats the problem..
20:55:43 <tmb> I will try to merge the suggested fix and post a boot.iso tomorrow on the bug that tracks the issue
20:55:48 <malo_> for reference https://bugs.mageia.org/show_bug.cgi?id=12549
20:55:51 <[mbot> [ Bug 12549 Can not install Mageia from DVD, but good from USB flash ]
20:56:03 <malo_> it's the first thing in the errata
20:56:40 <coling> But in terms of iso selection/quantity (which is really the question), were things OK?
20:57:13 <malo_> coling: I think there is consensus, although QA should have a big say in this.
20:57:18 <coling> e.g. is the Dual really needed these days?
20:57:21 <Luigi12_work> other than the fact that there's probably still too many so the QA team was run ragged testing
20:57:53 <malo_> Luigi12_work: it's also because isos were produced much more frequently
20:58:10 <Luigi12_work> yes, there were more rounds of testing too than for previous releases
20:58:31 <malo_> It'd be interesting to have some stats on iso downloads to know if some are never used (like the Dual).
20:58:49 <Luigi12_work> yeah I don't see the purpose of the dual, but some keep arguing for keeping it
20:59:01 <sander85> dual is least downloaded
20:59:08 <sander85> at least when i check torrent stats
20:59:55 <tmb> torrent stats: http://terasaur.org/item/downloads/mageia-4/6703
20:59:57 <[mbot> [ Mageia 4 - torrent list ]
21:00:10 <sander85> and english only CDs are not that popular
21:00:11 <Luigi12_work> maybe for mga5 if the weekly ISO idea is started around alpha time, it could help get issues found sooner and maybe less testing rounds would be needed for the alpha/beta/rc releases
21:01:10 <tmb> well, testing rounds depends on what QA finds and requests too...
21:01:32 <sander85> yeah
21:01:54 <tmb> since we want "good enough" to release, wich gets more critical the closer to the release we get
21:01:54 <Luigi12_work> yeah, just saying if things are found and fixed before real testing rounds begin...maybe wishful thinking
21:01:56 <coling> I know I could have found some of the problems sooner, but that's just a discipline issue on my part.
21:02:20 <Luigi12_work> yeah I started testing later in the cycle than I have the past two, busier at work
21:02:38 <malo_> Let's organise our thoughts a bit
21:02:54 <coling> For me I wasn't hacking as much on installer stuff so didn't do as much install testing.
21:03:09 <malo_> In the release process, we had features time, then version freeze period, then release freeze period.
21:03:11 <sander85> maybe track release critical bugs earlier and try to solve theme as much as possible and asap
21:03:22 <tmb> yeah thats also a problem with a fixed release time we tried this time around... when people work on spare time $life and $dayjob can screw it up
21:03:26 <sander85> not to wait until freeze
21:04:24 <coling> Yeah I think the deadline was too strict really! I mean, it was good to get it out for a major event, but it had plenty drawbacks (all the pressure, so much testing and no CD's ready on stand etc.)
21:04:41 <tmb> and neither version or release freeze didn't really work this time either :/
21:04:42 <sander85> and maybe 9 months is not enough time
21:04:48 <coling> As we do this for fun, I think we should avoid such fixed deadlines for a while while (i.e. until we forget!)
21:04:48 <Luigi12_work> yeah a fixed release time is tough.  We all made a hard push to meet it, and definitely were a lot more productive in the last couple of months before release than we were for mga3, but still we end up with a mga4 that will probably need a re-issue
21:05:25 * doktor5000 things again about "It's done when it's done" attitude :)
21:05:45 <doktor5000> s/things/thinks/
21:06:00 <Stormi> I agree with fixed date. Errata (another point to add to the post mortem) were not ready at all
21:06:10 <malo_> We also need to remember that mga3 was released very late, and I don't have the impression that the quality of mga3 is better than mga4
21:06:28 <sander85> imho the software nowadays is much more stable than it was few years ago, so we can live longer with the same release
21:06:35 <tmb> but yes, it was nice to see people were able to pull hard to try and make it happend... anyway .... a good lesson learned
21:07:44 <malo_> If we follow a 9 months schedule, it would place the release around November.
21:07:51 <sander85> especially now that we have backports too and LO is already pushed into testing
21:08:35 <malo_> sander85: we'll talk about this later.
21:08:36 <Luigi12_work> the hard thing about longer than 9 months is it increases the amount of time that only one release is supported
21:09:01 <malo_> Luigi12_work: is it a hard thing, QA likes it :-)
21:09:02 <Luigi12_work> it's hard to support something for two release cycles because support any software longer than 18 months gets extremely difficult I've learned
21:09:27 <Luigi12_work> malo_: yes but it means users are forced to stick with an unsupported release if one release doesn't work for them for some reason
21:09:39 <malo_> Yes.
21:09:40 <Luigi12_work> so 9 months is a good goal, even if we don't hit it dead on
21:09:54 <coling> Yeah, in terms of the freeze points tmb mentioned, I would personally vote for (if we get packages over to git) we explore and early branch approach for mga5 where cauldron remains open while we stabilise mga5. Some mar argue that this may reduce focus, but I think some people just switch off during freeze and even if they are not working on mga5 stuff they are at least more engaged. Plus we can likely test a bit more fle
21:10:00 <coling> xibly in this scenario.
21:10:03 <Luigi12_work> also, we might want to pay attention to the fact that Fedora and OpenSuSE both plan their next release for late this year
21:10:17 <coling> I also hope to be able to build more infra around this to make the process easier to manage.
21:10:28 <malo_> Luigi12_work: why would that impact us?
21:11:02 <Luigi12_work> malo_: being more in sync with them helps us for support purposes, so having our release near to slightly after theirs is helpful
21:11:06 <doktor5000> yep Luigi12_work, Fedora is broken anyways and Suse sucks :P
21:11:13 <Luigi12_work> ouch
21:11:18 * doktor5000 hides
21:11:18 <malo_> Luigi12_work: true.
21:11:45 <malo_> Ok. We do not have to reach conclusions tonight on anything.
21:11:55 * pterjan guilty of not getting people to fix broken builds until very late
21:11:57 <sander85> just discussing :)
21:12:06 <Luigi12_work> pterjan: not your fault
21:12:14 <tmb> yeah, and we get the "oohh new shiny" for us at the same time as fedora and opensuse too so people will remember us during xmas holidays :)
21:12:35 <malo_> But the 9 months schedule seems ok. The isos seem ok (except maybe dual, and some bugs). What about the number of alphas/betas
21:12:36 <malo_> ?
21:12:38 <Luigi12_work> yes, this "ooh new shiny" seems important to some users :o)
21:12:45 <pterjan> Luigi12_work:  well it is, I know that most people won't do it by themselves :)
21:12:59 <sander85> we could use more betas
21:13:02 <Stormi> Like I proposed in the mailing list, I'd like us to make a big event of first beta, almost like a new release, to try and get lots of testers and really put us in a polishing mood
21:13:08 <Luigi12_work> pterjan: well having the autobuild thing almost always available has helped a lot I think
21:13:09 <malo_> pterjan: your building bot was amazingly useful
21:13:14 <sander85> if we don't have to release on specific date
21:13:17 <doktor5000> malo_: for clarification, will postmortem meeting be separate, or should it be this meeting?
21:13:31 <malo_> doktor5000: this meeting is the kickstart of postmortem
21:13:32 <coling> Let's just call it RC then. The name matters for getting testers :)
21:13:34 <Stormi> and have RCs be reals RCs
21:13:38 <Stormi> RC is too late
21:13:47 <pterjan> well RC is supposed to be late
21:13:50 <Luigi12_work> doktor5000: the guts are already ripped out and strewn about, we might as well discuss them :o)
21:13:51 <Stormi> but it depends on the schedule, yes that's just names
21:13:52 <pterjan> it is supposed to be the final :)
21:13:55 <malo_> Stormi: we say that at every release :-)
21:14:15 <tmb> well we can do what linus did for linux, drop alpha/betas and start on RC1
21:14:15 <sander85> we can do RCs as LO does :P
21:14:27 <malo_> tmb: that's an idea.
21:14:27 <Stormi> what's different in my proposal is the special focus we could put on it, like a real release
21:14:29 <sander85> yeah, linux does that too
21:14:34 * coling nods
21:14:46 <pterjan> tmb: but he no longer accepts merges then :)
21:15:00 <pterjan> only fixes
21:15:14 <doktor5000> pterjan: we could benefit from that stance too
21:15:19 <Stormi> that's great from a QA point of view, pterjan :)
21:15:20 <coling> It's just "marketing" for us really :)
21:15:22 <tmb> pterjan, well, that would get us a debian release then :)
21:15:27 <sander85> 2 alphas, 1 beta and then RCs til we are ready :)
21:15:30 <Stormi> but it tends to put most packagers in sleeping mode
21:15:44 <Stormi> we need coling's gameification for bugfixes
21:16:01 <Luigi12_work> yeah it'd probably work better for bugfixes than QA :o)
21:16:10 <sander85> yeah, it's somewhat true, funda was pretty much missing during freeze :P
21:16:13 <coling> Ha! Well that's (in part) going to be based on fedmsg ...
21:16:14 <malo_> Ok guys, let's take a step back
21:16:33 <malo_> we can spend the night renaming alphas and betas and not progress
21:16:53 <malo_> BTW I forgot to say that this is the kickstart of the postmortem process
21:17:02 <malo_> it's going to take a month
21:17:18 <malo_> and we cannot just decide everything in the packager meeting
21:17:21 <tmb> and all teams will do their own post-mortem
21:17:28 <malo_> tmb: exactly
21:17:56 <tmb> then we'll try to sum it all up in a council meeting
21:18:00 <malo_> So the council will in a month take the best ideas from all teams, and take all the constraints and decide.
21:18:17 <Stormi> a lot was said today already, would be nice to have someone to being to note that in the wiki
21:18:23 <Stormi> begin*
21:18:33 <sander85> i hope they decide better than debians tc :)
21:18:39 <coling> :)
21:18:39 <Luigi12_work> sander85: LOL
21:18:46 <malo_> #action Stormi is going to put the ideas discussed today in the wiki
21:19:00 <malo_> Stormi: thanks for volunteering
21:19:02 <Stormi> ok, when the list of updates is empty
21:19:09 <Stormi> that's my only condition
21:19:11 <Stormi> easy
21:19:12 <Stormi> :)
21:19:25 <malo_> Let's go to the next topic then
21:20:02 <malo_> #topic Helping QA
21:20:18 <malo_> QA has done an amazing job for this release
21:20:28 <malo_> We can all agree and thank them a lot
21:20:37 <sander85> indeed
21:20:39 <Luigi12_work> indeed
21:20:43 <tmb> yep
21:20:53 <Stormi> indeed (can say, I wasn't there until late)
21:21:08 <malo_> And since the release, they have to handle the backlog of security updates+new updates for mga3+new updates for mga4+ backports
21:21:21 <malo_> in short, we are killing them
21:21:27 <Luigi12_work> literally in some cases
21:21:28 <coling> Yes! QA deserve medals!
21:21:39 * pterjan will probably create some more updates tonight, but one of them will be trivial to test, just install!
21:21:59 <malo_> Since we need them alive for the next release, we have to help more
21:22:04 <sander85> pterjan: p11-kit? :)
21:22:08 <tmb> Well, better than medals would be helping QA out.... how about we all try to clean QA queue by the end of the week
21:22:16 <Luigi12_work> well, find more help, one way or another
21:22:28 * coling has been fixing one of them this evening.
21:22:30 <malo_> I think this would be a good idea.
21:22:33 <pterjan> sander85: dkms-ipt_NETFLOW first :)
21:22:39 <sander85> ok :)
21:22:43 <doktor5000> tmb: sounds good, and we all should stick more to https://wiki.mageia.org/en/Example_update_advisory_announcement and the QA needs
21:23:20 <pterjan> one problem with helping with qa is that a lot are for mageia 3 or 3 +4
21:23:28 <malo_> pterjan: yes.
21:23:38 <Luigi12_work> yeah, good advisories help, as do good detailed testing procedures (you can help with that even if you didn't package the update)
21:23:40 <malo_> Reminder: http://mageia.madb.org/tools/updates is the list of candidates
21:23:41 <Stormi> we at QA test a lot in VMs when we don't have the system
21:23:44 <[mbot> [ Mageia App Db - Current Update candidates ]
21:24:02 <Stormi> it's quickly up from a liveDVD
21:24:21 <malo_> pterjan: but as provider of update, you certainly tested it before, right? ;-)
21:24:22 <Stormi> but testing takes time, true
21:24:25 <Luigi12_work> or a network install for those that have their own local rsynced repositories
21:25:02 <malo_> So do we agree to help QA clear the queue by Sunday?
21:25:27 <pterjan> no one has anything planned on Friday evening I guess
21:25:35 <Luigi12_work> it's definitely on my todo list, but we also need more *users* to help
21:25:39 <coling> Yeah, I'll spend whatever time I have on QA related stuff.
21:25:39 <malo_> And not add any non-essential update
21:25:41 <Luigi12_work> forum and blog posts would be nice
21:25:52 <tmb> just a note, if you start testing one update, add a note on the BR so we dont duplicate work
21:25:57 <Luigi12_work> malo_: most updates are not non-essential
21:26:07 <Luigi12_work> malo_: in fact, only backports are clearly non-essential
21:26:13 <neoclust> re
21:26:15 <malo_> Luigi12_work: yes.
21:26:18 <Stormi> Luigi12_work: well, I can see a lot that could wait for a week
21:26:31 <Stormi> but if you can submit updates + clear the queue that's the best
21:26:33 <pterjan> Luigi12_work: well I was about to add a non-essential one :)
21:26:34 <Luigi12_work> Stormi: well if it can't be tested for a week because others take priority, that's fine
21:26:43 <Stormi> because otherwise the list will become full again on monday
21:26:48 <Akien> But yeah try to at least help an update get validated when you submit one
21:26:54 <sander85> yeah, i don't think we should hold packagers back from fixing things
21:27:02 <neoclust> how to prevent to build debug packages ?
21:27:04 <sander85> we can use lower priority
21:27:10 <Akien> It's just depressing to see the updates list stay still or grow even though you're trying hard to validate updates.
21:27:14 <Luigi12_work> sander85: indeed, and it's insulting to even suggest it
21:27:17 <Stormi> Akien: +1
21:27:28 <Stormi> you really have to think of the impact on QA's mood
21:27:37 <Stormi> but the best way is helping
21:27:38 <Luigi12_work> Akien: yes I understand the stress factor
21:27:45 <Stormi> not retaining updates
21:27:51 <Luigi12_work> one thing that's great about our QA people is the sense of responsibility they have about this
21:27:58 <malo_> sander85: of course not. It's just courtesy to also think about QA
21:27:59 <Luigi12_work> but it's not helping their stress levels.  They really need more people helping.
21:28:01 <neoclust> Akien: tomorow i do a test on mga4 updates
21:28:05 <neoclust> Akien: like i did for mate ones
21:28:15 <Akien> neoclust: You did great indeed, thanks :)
21:28:17 <Luigi12_work> we shouldn't have three people that feel like they're personally responsible for testing every single update
21:28:32 <malo_> #action Packagers will help validate current updates to clear the queue quickly
21:28:39 <neoclust> Akien: just image that i had to install / test mate
21:28:40 <neoclust> me
21:28:42 <neoclust> :)
21:29:01 <Stormi> I feel that QA team really grew since Mageia started, but not every member is committed fulltime
21:29:01 <malo_> However, in the long run, we need to help QA more.
21:29:03 <Luigi12_work> I hope packagers help as much as they can, but I understand they're also very busy.  I don't think they're the lowest hanging fruit for additional help here.
21:29:10 <neoclust> malo_: yes if one person test this helps a lot and doe not take a lot of time
21:29:11 <Stormi> most of QA relies on MrsB and Dave
21:29:22 <sander85> quite a few requests are missing procedure.. that's where packagers can help a lot
21:29:28 <Stormi> but right now Dave can't help much and MrsB is exhausted
21:29:50 <neoclust> Stormi: they have to take some rest, we can help during this time :)
21:29:57 <malo_> Notably some of use still do not follow the procedure https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29
21:29:59 <Akien> sander85: +1
21:30:11 <Akien> I'm not a hacker, so most of the time I just follow procedures
21:30:24 <malo_> and forget to add the advisory or list of SRPMS or testing procedure
21:30:34 <sander85> security fix is one thing but bugfixes should have procedure.. can't be that hard to write
21:30:59 <Stormi> a related issue you're already aware of is most security updates come from Luigi12_work
21:31:10 <Stormi> and he can't know every package
21:31:15 <Stormi> so he can't provide procedures
21:31:16 <malo_> #action packager will re-read https://wiki.mageia.org/en/Updates_policy#Maintainer_.28or_any_interested_packager.29
21:31:21 <Akien> I feel that clearing the updates backlog before the end of the week would be a nice "thankyou" for MrsB and Dave (and the other dedicated QA members who made Mageia 4 possible)
21:31:24 <Luigi12_work> although I've received more help with these lately than I ever have before, so thank you so much to those that have helped with security updates
21:31:26 <Stormi> and we can't require that from him
21:31:34 <Luigi12_work> but yes, I can't write testing procedures for most of them
21:31:56 <Luigi12_work> so even if I do the packaging work for an update, other packagers can provide testing procedures, it'd be helpful :o)
21:32:19 <Stormi> and testing procedures can be very simple
21:32:25 <Stormi> we just test basic features usually
21:32:45 <Stormi> QA doesn't ensure there's no regression, it checks there is no
21:32:47 <Luigi12_work> yes, basic operation testing to catch obvious regressions
21:32:49 <Stormi> *obvious* regression
21:32:53 <malo_> However, I have the feeling that with 2 releases and backports, QA needs either to grow, or packager need to become more systematically involved
21:33:03 <Luigi12_work> also, if you happen to understand a CVE better than I do and know how to reproduce it, tips on that are helpful too
21:33:28 <Luigi12_work> malo_: indeed, we cannot put additional burden on the QA team with backports, I agree wholeheartedly
21:33:49 <Luigi12_work> part of the deal that's been decided on backports is that packagers *can* help testing those packages.  I would think *must* would be better.
21:33:54 <Akien> malo_: The QA policy is not to test backports until the updates are cleared
21:34:01 <Luigi12_work> (as in the packager that built the update)
21:34:10 <coling> I'm hoping that we can add better infra to deal with updates etc., but it's a fairly long term project.
21:34:16 <malo_> Akien: sounds sensible
21:34:18 <Stormi> one of my old ideas never implemented is to allow each user to register as a tester for specific packages and get direct notifications when a new update candidate can use testing (but it's not guaranteed to work)
21:34:24 <Luigi12_work> Akien: well anyone can test any update candidate at any time if they want to, be it update or backport
21:34:25 <Akien> But some testers can't resist the urge to test shiny backports instead of daunting security updates for some obscure web app :p
21:34:37 <Luigi12_work> but the dedicated QA team members will obviously prioritize regular updates over backports
21:34:57 <Luigi12_work> Stormi: I really like your idea though
21:35:07 <malo_> Ok guys. I think we all agree to help more QA
21:35:25 <malo_> Now is the time to do it rather than keep talking about it.
21:35:30 <coling> Stormi, Yeah, that's something I'd hope to be to do eventually.
21:35:33 <malo_> Next topic?
21:35:42 <coling> Stormi, we can chat later if you like?
21:35:46 <coling> (maybe tomorrow)
21:35:46 <Stormi> coling: yes
21:36:11 <malo_> #topic Backports
21:36:22 <Luigi12_work> no more until the updates are cleared :o)
21:36:30 <malo_> So finally backports are opened thanks to tmb
21:36:50 <sander85> \o/
21:37:04 <malo_> But, as we've seen, please do not submit much until QA can breathe again
21:37:05 <sander85> but should we maybe skip that topic as we have so many updates?
21:37:11 <malo_> sander85: no
21:37:14 <sander85> ok
21:37:31 <malo_> There was one question which was raised on the ml
21:37:41 <malo_> THe question of upgrade with backports
21:37:48 * sander85 hides :)
21:38:09 <Luigi12_work> I was surprised we even opened it for mga3, I wasn't expecting that
21:38:17 <malo_> for reference: https://wiki.mageia.org/en/Backports_policy
21:38:52 <malo_> THere is nothing about constraints in versions
21:39:17 <malo_> So the current policy will in general not allow upgrade to newer release
21:39:35 <Luigi12_work> not necessarily
21:39:45 <Luigi12_work> there shouldn't really be version constraints
21:40:01 <Luigi12_work> and if we cut off backports for mgax when mga(x+1) releases, there's no issue
21:40:10 <Stormi> there's one
21:40:10 <Luigi12_work> but if we're going to keep both open, then some packages won't be updated on upgrade
21:40:18 <Luigi12_work> whether it causes any issues depends on the package
21:40:21 <malo_> Luigi12_work: yes
21:40:29 <Stormi> backports are supported, if you can't backport the newer version, you have to patch
21:40:37 <Stormi> that's extra work for packagers, isn't it?
21:40:54 <Luigi12_work> yeah that's a difficult question
21:41:03 <Akien> tv proposed something which sounded like mga5 > mga4 whatever the version is, i.e. the */backports are replaced by */release packages IIUC.
21:41:12 <tmb> well, backports are supposed to be leaf packages so the breakage should not be big
21:41:21 <Luigi12_work> right
21:41:25 <malo_> tmb: neoclust wanted to backport KDE
21:41:32 <Luigi12_work> Akien: that sounds good in theory, in practice I worry about it
21:41:35 <malo_> tmb: not very leafy
21:41:40 <tmb> malo_, yeah, that's called mga5 :)
21:42:13 <Luigi12_work> in general I don't think we should be backporting entire DEs
21:42:18 <Akien> Luigi12_work: yes, just reverting a bunch of backports (potentially not leaf packages) to prior versions might be hazardous
21:42:22 <Stormi> for leafy packages, I think upgrade issues shouldn't be a problem, I think we should at the same time try + test upgrades if possible automatically
21:42:23 <Luigi12_work> for KDE 4.12, I understand the desire specifically this time
21:42:31 <sander85> Luigi12_work: +1
21:43:11 <Stormi> I'd prefer it as updates and mega-tested actually
21:43:15 <Akien> Technically we could backport non-leaf packages to mga4, provided the version is higher in Cauldron
21:43:17 <Akien> But not to mga3
21:43:18 <Stormi> to not have 2 different versions
21:43:19 <malo_> So one policy is that we only have backports for mga(x) but not mga(x-1), then at each release we version freeze backports for mga(x-1).
21:43:24 <sander85> i have problems with 4.11 and 4.12 might fix some problems but it's too risky and will kill QA
21:43:25 <Luigi12_work> Stormi: yes I actually agree
21:43:34 <Luigi12_work> but sander85 has a good point too
21:44:01 <Stormi> neoclust said he can find testers for KDE
21:44:01 <Akien> I would be in for testing a mega kde update
21:44:05 <Luigi12_work> malo_: I think the freeze idea is the only logical thing
21:44:10 <Akien> When there is absolutely no qa backlog :)
21:44:18 <Stormi> and I think for such an update testers can be found
21:44:22 <Luigi12_work> if you're so obsessed with having the newest stuff that you want backports, you should upgrade to the newest release anyway
21:44:22 <sander85> Stormi: and later? we are short in bugsquad too
21:44:26 <Stormi> and we don't need to rush
21:44:41 <Stormi> truth is 9 month is not long
21:44:42 <neoclust> Stormi: for ?
21:44:43 <sander85> every time you have to ask, whick kde you have
21:44:45 <malo_> sander85: we are short in every team
21:44:47 <neoclust> :)
21:44:55 <sander85> is it backported or not
21:44:59 <Luigi12_work> sander85: no kidding, the activity in bugzilla this month has been insane
21:45:21 <sander85> Luigi12_work: yeah, i know :)
21:45:24 <malo_> So, is there a consensus on this?
21:45:28 <AL13N> i imagine this is what most distro's go through
21:45:30 <Stormi> neoclust: I was answering to "it will kill QA if in updates" (well that's how I understood sander85)
21:45:55 <Akien> Luigi12_work: We could do both: a not too stict policy for mga(n) (n+1 being cauldron), and a stricter policy (only the leafiest of leaf packages) for mga(n-1)
21:45:58 <sander85> i say we stick with the policy :)
21:46:10 <Luigi12_work> Akien: maybe but that seems confusing
21:46:12 <malo_> Would a condition like: a software is considered leaf if it is not in any iso
21:46:21 <Akien> Luigi12_work: Yeah it could be
21:46:29 <Luigi12_work> malo_: no, some libraries are not on any ISO
21:46:35 <neoclust> Stormi: kde 4.11.5 will come soon
21:46:36 <neoclust> ;)
21:46:38 <Stormi> malo_: you just killed tv's libreoffice backport
21:46:45 <malo_> work to say which packages can be backported and which go in updates
21:46:45 <Stormi> neoclust: soon is impossible :)
21:47:02 <neoclust> Stormi: don't say this or i start the script now :)
21:47:18 <neoclust> malo_: having libreoffice in backport would be a big +
21:47:20 <Stormi> I say like sander85, stick to the policy, leaf(y) packages shouldn't break upgrades, and if unsure we can test that
21:47:32 <Luigi12_work> malo_: updates if there's a reason why you're providing the update and backports if there is no real reason other ooh new shiny higher numbers
21:47:37 <Luigi12_work> :o)
21:47:48 <sander85> we have to think what the backports mean in longer term
21:47:56 <sander85> LO is mostly ok
21:48:00 <neoclust> Luigi12_work: libreoffice provide so many fixes, etc
21:48:05 <sander85> it won't break rest of the system
21:48:10 <sander85> DE is another topic
21:48:13 <AL13N> fixes or features...
21:48:15 <tmb> as the policy also states... we will revisit it in ~6 months
21:48:38 <tmb> to see how it works when we actaully start using it
21:48:38 <neoclust> AL13N: both
21:49:05 <sander85> you can uninstall LO and install from stable again.. with DE it won't be that easy
21:49:11 <sander85> at least not for normal user
21:49:25 <sander85> it's way way too big for backport
21:49:52 <AL13N> it's just as big for update
21:50:11 <malo_> We'll probably have to add to release notes and installer maybe that if some backports were installed, network should be present during upgrade
21:50:19 <malo_> for next release
21:50:28 <Stormi> malo_: and detect it
21:50:30 <Luigi12_work> malo_: sure, but it doesn't help that much
21:50:44 <Luigi12_work> unless you enable the backports media, which will update all of the backports, even ones you don't want
21:50:56 <sander85> AL13N: update is minor version change, backport isn't
21:50:56 <Luigi12_work> unless we get some logic to only pull from backports that which you already have installed from backports
21:51:05 <malo_> Stormi: hard to detect
21:51:06 <tmb> AL13N, yes, but then we dont need to support 3.11 anymore if we have pushed 3.12 through /updates
21:51:16 <Stormi> malo_: versions higher than what the DVD has
21:51:20 <Stormi> malo_: not that hard
21:51:25 <malo_> Luigi12_work: right. Damn cherry-picking
21:51:44 <neoclust> sander85: as KDE is frozen a lot kdelibs from kde 4.11 is the same as in kde 4.12 so no need to revert :)
21:51:46 <AL13N> tmb: sander85: i'm just saying that size isn't the issue for backports
21:51:47 <tmb> well, not so hard to detect.... I guess we can add "bp" or something in release tag as we do for nonfree and tainted
21:52:01 <malo_> Stormi: normally the DVD of the next version should always be higher than backports of previous versions
21:52:21 <Stormi> malo_: only at release time
21:52:25 <Stormi> not 4 month later
21:52:36 <Luigi12_work> or forever if we close backports for the old release when the new one comes out
21:52:39 <Luigi12_work> in which case it's not an issue
21:52:47 <Stormi> but we come back to how to maintain them
21:52:52 <Stormi> if security issues arise or bugs
21:53:12 <Luigi12_work> well the security team will not be tracking security issues for backports
21:53:12 <malo_> Stormi: they are maintained like other packages, but with less QA
21:53:13 <AL13N> if backports have updates, the previous backports is no longer support
21:53:16 <Akien> tmb: I think this was discussed... years ago ;) and I thought it would be pretty safe
21:53:23 <Luigi12_work> that is solely the responsibility of the packagers who do the backports in the first place
21:53:28 <sander85> security issue means that QA has to test that too
21:53:32 <Stormi> if, say, LO is in higher version on my system than what the DVD has. Will it fail? I supect it will just leave it alone.
21:53:34 <Akien> tmb: Have a "bp" tag to help discriminate backports from release packages
21:54:18 <AL13N> afaics, nothing changes, backports is still the lowest priority in QA and when mgarepo is fixed, it'll be finally really possible, and i can't see much backports getting through, unless they bring in QA testers themselves
21:54:23 <malo_> Ok. Probably we can just try a bit with the current policy.
21:54:27 <sander85> if we keep 9 months release cycle then we shouldn't backport too much..
21:54:36 <AL13N> as tmb said, we'll revisit in 6 months
21:54:41 <malo_> I would only suggest that we do not backport anything to mga3 for now.
21:54:46 <Luigi12_work> malo_: agreed
21:54:52 <sander85> malo_: +1
21:55:03 <AL13N> ok
21:55:06 <Stormi> that won't help detecting upgrade issues
21:55:14 <Stormi> how will you decide better in 6 month?
21:55:14 <Akien> malo_: Even with %{version}-%{release} lower than in mga4? :)
21:55:23 <Luigi12_work> Stormi: we can backport a newer null package to test that :o)
21:55:51 <AL13N> why not bump cauldron rel when backport bumps?
21:56:05 <Akien> AL13N: Because there's mga4 between mga3 and cauldron
21:56:11 <sander85> yeah..
21:56:14 <Stormi> back to my question: can backports of leaf packages or groups of packages (LO and specific deps) actually break upgrade, and if so, how?
21:56:14 <malo_> By next release, we can see if it causes many upgrade problems or not, and change policy
21:56:21 <Luigi12_work> and because Funda likes rebuilding things without bumping the rel :o)
21:56:32 <Akien> Stormi: define leaf package...
21:56:59 <tmb> Akien, "null" \o/
21:57:03 <Stormi> Akien: leaf package is required by no package, leaf group is coherent as whole and no package requires any of those
21:57:07 <Akien> It will be hard to enforce such a policy if we have no precise definition for that
21:57:20 <AL13N> well, if we don't do backports on mga3 and mga4 has backporst and mga5 is released, we can bump mga5 so that it's bigger than mga4 backports
21:57:31 <Akien> Stormi: That makes sense. Then we need a mgaleaf tool :)
21:57:38 <malo_> Stormi: suppose new LO is compiled against old library, which then gets upgraded, but not LO.
21:57:41 <Akien> Or actually an extension to madb
21:57:48 <sander85> AL13N: that's what the policy says
21:57:56 <Luigi12_work> AL13N: I believe part of the policy is that no backport can ever be higher EVR than what's in Cauldron
21:57:57 * tmb wonders if the libs pushed along with LO will play nice
21:57:57 <sander85> current problem is mga3
21:58:03 <malo_> tmb: me too
21:58:23 <sander85> afaik tv tested them
21:58:30 <AL13N> sander85: "malo_: I would only suggest that we do not backport anything to mga3 for now."
21:58:40 <Stormi> me too, that's why the LO backport will be scrutinized, deps and all
21:58:46 <tmb> not to mention we need to check if "cherry-pick" actually works on it
21:58:55 <Stormi> tmb: too
21:59:03 <Stormi> planned, but tools would help
21:59:08 <malo_> #action we do not backport anything to mga3 for now
21:59:12 <Akien> tmb: For now cherry-pick is hard, because MageiaUpdate's GUI is broken
21:59:19 <AL13N> this might be stupid, but if deps is a problem, we could compile all backports statically
21:59:21 * AL13N hides
21:59:41 <sander85> /o\
21:59:47 <sander85> next topic?
21:59:48 <malo_> #action when QA queue is empty we test a lot how LO as backport plays in mga4
21:59:55 <Akien> I still have to look if there's already a BR about it. When you try to check/uncheck boxes in MageiaUpdate, you end up with something totally irrational
22:00:06 <malo_> And then we look to see how that goes.
22:00:10 <Akien> (when sorting by version at last), but that's off-topic
22:00:14 <malo_> sander85: ok.
22:00:21 <malo_> Next topic
22:00:26 <malo_> It's late :-)
22:00:28 <Luigi12_work> AL13N: actually you reminded me of something MandrakeSoft implemented back in the day, it was a way of backporting things with all their deps together such that it didn't impact the system, I forget the name
22:00:34 <Stormi> Akien: you mean deps are not tight enough, maybe, not MageiaUpdate is broken
22:00:38 <malo_> #topic mentoring
22:00:48 <Akien> Stormi: no no clearly it's MageiaUpdate
22:01:00 <malo_> We have a new apprentice: Alex
22:01:08 <malo_> From Russia
22:01:09 <Luigi12_work> he's very active
22:01:28 <Luigi12_work> backporting packags and fixes from his 3rd party repo
22:01:29 <AL13N> should he also do some QA?
22:01:41 <Stormi> he did some for bugs he reported
22:01:45 <AL13N> nice
22:01:46 <Luigi12_work> AL13N: I think that's part of the mentoring process in general
22:01:48 <malo_> He's quite good and will help coordinate with a lot of our Russian community
22:02:01 <malo_> So that is great
22:02:06 <AL13N> who's mentoring?
22:02:13 <Luigi12_work> Stormi mostly
22:02:17 <leuhmanu> ( Akien: https://bugs.mageia.org/show_bug.cgi?id=5770 ? )
22:02:21 <[mbot> [ Bug 5770 Visually deselected packages installs anyway (suggested packages) ]
22:02:29 <malo_> We had Akien who graduated as mentioned earlier
22:02:40 <Stormi> and I will probably need help (in fact people are helping already)
22:02:48 <AL13N> malo_: will you be doing some of those webcasts?
22:03:03 <malo_> We have a queue of people https://wiki.mageia.org/en/Becoming_a_Mageia_Packager#Packaging_apprentice_candidates waiting for mentors
22:03:09 <Stormi> he's probably more versed in packaging than myself... My advantage is I know Mageia from inside and that's what I'm trying to "teach"
22:03:21 <malo_> Some of them might not be interested anymore
22:03:27 <AL13N> :-(
22:03:55 <Luigi12_work> yes we've been losing mentoring candidates since I started with Mageia two years ago
22:03:55 <malo_> but some are possibly just lurking around
22:04:00 <AL13N> this reminds me, at FOSDEM, there was a wolfSSL guy who wanted this into Mageia. might want to help packaging this himself
22:04:05 <malo_> Luigi12_work: that's normal
22:04:36 <malo_> So, if you feel like mentoring, please contact some of the guys there
22:04:51 <Luigi12_work> and feel free to lurk in #mageia-mentoring and help answer questions
22:05:06 <malo_> and if someone comes on IRC or -dev, please hook them quickly :-)
22:05:13 <malo_> We need more packagers
22:05:18 <Luigi12_work> indeed
22:05:20 <AL13N> malo_: maybe we could have a "last date contacted" entry in the table as well
22:05:33 <AL13N> malo_: do we direct them to you?
22:05:56 <malo_> Last thing I wanted to say is that if you have currently an apprentice, don't hesitate to graduate them if they have been here a while
22:06:21 <malo_> being a packager is not an exam in RPM spec linguo and policy knowledge
22:06:30 <neoclust> really ? :)
22:06:30 <malo_> it's mainly about trust
22:07:00 <malo_> can we trust someone to commit and not break cauldron too much
22:07:08 <Luigi12_work> and following Mageia policies
22:07:28 <Akien> We really need someone to mentor david_david :-P
22:07:38 <Akien> I could do it but he's more experienced than I am... :)
22:07:46 <Luigi12_work> I'd do it, but that'd be too many David's
22:08:00 <malo_> It didn't work well with his pervious mentor
22:08:07 <Luigi12_work> :o(
22:08:10 <malo_> Any volunteer to help david_david is welcome
22:08:26 <Luigi12_work> he's French IIRC?
22:08:32 <malo_> yep
22:08:33 <Akien> Stormi: Do you want to co-mentor david_david with me?
22:08:39 <Akien> There's not much work to do I think :)
22:08:51 <Stormi> you mentor him and we all help :)
22:08:59 <Akien> Ok
22:09:02 <Luigi12_work> he's an experienced Mageian, he helped QA in early 2012 and late 2011 I think
22:09:12 <Akien> And early 2014 :)
22:09:22 <Stormi> He's the David from MLO?
22:09:26 <Akien> Yep
22:09:29 <malo_> AL13N: for your questions, you can direct them to me, or to the table, or start mentoring them on the spot :-)
22:09:37 <Stormi> so his tasks will be to redirect contributers to us :)
22:09:38 <david_david> hi
22:09:42 <david_david> they talk about me
22:09:46 <malo_> AL13N: I can't make mentors magically appear :-)
22:09:47 <david_david> thank you
22:09:49 <malo_> david_david: hey
22:09:54 <Luigi12_work> david_david: hello :o)
22:09:54 <Akien> Now we need to mentor someone from blogdrake :-D
22:10:19 <malo_> david_david: we were trying to find you a new mentor.
22:10:28 <david_david> Luigi12_work: I help Qa team since mga1 :)
22:10:45 <malo_> Ok it's late. We should stop the meeting soon.
22:10:46 <Luigi12_work> yep, I remember
22:10:48 <david_david> malo_: good idea
22:10:59 <Luigi12_work> any more topics?
22:11:14 <malo_> david_david: let me introduce you to Akien, your new mentor
22:11:28 <neoclust> :)
22:11:30 <sander85> Luigi12_work: i can just mention one
22:11:35 <malo_> Luigi12_work: I skipped arm, since it's late and not urgent
22:11:42 <neoclust> malo_: not urgent ?
22:11:49 <neoclust> malo_: we need to speak about it
22:11:50 <coling> Yeah
22:11:54 <Akien> I feel like a post-doc teaching ph.d students :-D
22:11:56 <david_david> malo_: ok for me, nothing to report
22:11:57 <neoclust> malo_: see my mail on sysadmin ML
22:11:59 <Luigi12_work> yeah, talk too much about ARM and Umeaboy will appear
22:12:00 <coling> Just wait until cool small x86 boards appear...
22:12:02 <coling> :)
22:12:03 <sander85> i'm planning another report :P
22:12:26 <neoclust> coling: you saw my mail on sysadmin ML ?
22:12:28 <Stormi> Akien: so have I while mentoring all my apprentices (only 2 graduated though)
22:12:50 <coling> neoclust, not yet.
22:13:08 <malo_> Ok, since you are full of energy tonight
22:13:14 <Stormi> let's clear the list!
22:13:15 <malo_> #topic arm
22:13:32 <Luigi12_work> mine's asleep
22:13:40 * AL13N watches tumbleweed pass by
22:13:40 <malo_> neoclust: your turn :-)
22:14:54 <neoclust> malo_: i wanted to list what we lack, what changes needs to be done on the BS, etc
22:15:07 <neoclust> rtp: can help us at least to list all this
22:15:10 <neoclust> blino: too i think
22:15:11 <sander85> do we know what we lack?
22:15:18 <neoclust> as they did such things in mdv
22:15:21 <coling> neoclust, ahh yeah I did see that mail, but I've not got much opinion on it.
22:15:37 <malo_> neoclust's email: https://ml.mageia.org/l/arc/sysadmin-discuss/2014-02/msg00010.html
22:15:37 <neoclust> sander85: if we don't know we have to work on it
22:16:01 <coling> neoclust, FWIW, fedora used to use fedmsg to trigger arm builds before they promoted it to a first class arch.
22:16:09 <malo_> neoclust: I don't have much opinion either
22:16:14 <sander85> neoclust: i agree
22:16:24 <sander85> but it's getting really late here
22:16:26 <coling> neoclust, so I suspect we can also utilise this same technique when the time comes.
22:16:34 <neoclust> coling: i think to start and as we don't have a big ARM farm, we need do this yes
22:16:39 <sander85> and i'm not sure if rtp or blino are around
22:16:46 <malo_> neoclust: maybe this can be discussed in sysadm team first, and with people that have access to rtp
22:16:55 <neoclust> coling: can't we do a blog post to ask for arm machines if some company wants to help :)
22:17:01 <[mbot> [ sysadmin-discuss - Sysadmin team discussions - arc_protect ]
22:17:10 <coling> neoclust, I'm sure we could.
22:17:13 <malo_> neoclust: feel free :-)
22:17:13 <tmb> well, at fosdem rtp told he has iurt building stuff but it takes time... but we neeed to start mirroring it so we share workload
22:17:22 <neoclust> [mbot: you are late, you were at the pub ?
22:17:33 <AL13N> :)
22:17:34 <sander85> yeah, mirror would be a start
22:17:37 <neoclust> tmb: yes he did a huge work on it
22:18:06 <malo_> neoclust: without saying a word about it publicly though ...
22:18:09 <tmb> but one thing for arm that _every_ developer can help with
22:19:00 <tmb> as arm are slow builds, _please_ ensure you have proper versioned deps so we get the order right the firt time and not by trial / error
22:19:03 <sander85> if rtp has iurt running then he has done all the bootstrapping part.. and we wouldn't have to do that again
22:19:17 <tmb> *first time...*
22:19:46 <AL13N> tmb: can you give example? and what kind of things to look for?
22:20:08 <malo_> neoclust: can you collect the information from the people who know? And then report in the meeting next week, or by an email to -dev?
22:20:09 <neoclust> AL13N: make sure you don't enable valgrind as build deps for ex :)
22:20:18 <neoclust> malo_: i will try :)
22:20:52 <AL13N> this is about buildrequires, right? and wrt versioning, you mean if you know that an older version doesn't work to put the version requirement on it?
22:20:55 <malo_> #action neoclust will investigate rumours about iurt running for arm and report
22:21:06 <tmb> AL13N, well, if you know a package need a specific version of a lib or something to get it to build, add that to buildrequires so we can sort the order of builds according to deps
22:21:48 <tmb> otherwise if the arm chroot have an older version of same lib, it will try to build and will fail... and we have lost a lot of time on it
22:21:56 <Luigi12_work> one thing one can do is compare with other distros, if they indicate a newer BR version, ours is *probably* outdated
22:22:31 <AL13N> maybe a check could be added for this? to check.mageia.org ?
22:22:32 <neoclust> tmb: maybe i tell idiotic things, but some distro does cross compile. What about this ?
22:22:40 <neoclust> tmb: this is better with real hardware ?
22:23:04 <neoclust> malo_: can you look to do a blog post for arm machines if companies wants to help us ?
22:23:05 <tmb> an other thing ... rtp used to patch a lot of packages, but maintainers simply disable them on upgrades without asking so it would fail on next build again
22:23:28 <Luigi12_work> I dunno about putting out a call for machines until we have a more solid plan of what to do with them
22:23:30 <AL13N> neoclust: iinm rtp once told me that cross compile is not always exactly right, like address padding and such
22:23:47 <malo_> neoclust: I know nothing about arm, but I encourage you to propose one
22:23:57 <neoclust> tmb: malo_ i don't know better :þ
22:24:03 <AL13N> about machines, we'd need a place to put them as well
22:24:04 <pterjan> compilation isnot the main problem
22:24:17 <pterjan> (configure, tests, ...)
22:24:21 <Luigi12_work> tmb: I've heard that, but never seen a real example of it
22:24:33 <tmb> neoclust, well, as rtp once pointed out real hw triggers more "bugs" than qemu or cross-compile... but we could do the first round in quemu to flush out "easier problems"
22:25:06 <neoclust> pterjan: what do you mean ?
22:25:13 <Luigi12_work> is qemu any faster than real arm hardware?
22:25:41 <Luigi12_work> just curious.  It would be more reproducible of course
22:25:44 <tmb> and then the next problem with arm... wich sub-arches do we build for ...
22:25:46 <pterjan> neoclust: that configure scripts execute things to make choices
22:26:07 <neoclust> tmb: good question :)
22:26:13 <Luigi12_work> let's ask Umeaboy
22:26:15 <pterjan> I would vote to build for arm64, that will force to have more powerful hardware /o\
22:26:22 <malo_> Luigi12_work: :-)
22:26:58 <tmb> pterjan, yeah, I actually plan to mail both amd, nvidia and dell about "hw donation" :)
22:27:08 <Luigi12_work> nice :D
22:27:35 <AL13N> well, currently, there's a v5 iinm, so a v7hf would be nice and then a v8 64bit
22:27:57 <tmb> amd has a nice development platform landing in ~3-6 months
22:27:58 <pterjan> https://wiki.debian.org/Arm64Port#Hardware.2C_emulators_and_models
22:27:59 <AL13N> otoh, there's still people requesting raspPI
22:28:32 <sander85> is arm our last topic? don't get me wrong, i'm interested but the clock is showing some weird numbers (00:28) time for bed i guess :/
22:28:55 <Luigi12_work> sander85: did you say there was one last topic you wanted?
22:28:59 <neoclust> sander85: set you clock to my tz :)
22:29:38 <tmb> yeah, we could also star a wiki page of what hw people (=interested developers) have
22:29:41 <Luigi12_work> good night :o)
22:29:54 <malo_> Ok guys it's late :-)
22:30:20 <malo_> neoclust: please investigate with sysadm
22:30:24 <neoclust> malo_: ok
22:30:30 <tmb> lets ping rtp for a status update, and I'll look into mirroring out whatever we have :)
22:30:31 <malo_> we'll discuss it next week
22:30:36 <malo_> tmb: great
22:30:41 <neoclust> tmb: perfect :)
22:30:42 <malo_> Time to sleep
22:30:43 <AL13N> tmb: https://wiki.mageia.org/en/MageiaOnARM
22:30:44 <sander85> Luigi12_work: it can wait :) i'm planning some kind of activity report (next to deps report) to weed out inactive maintainers and make nobody "maintain" more packages..
22:30:54 <malo_> Thanks all
22:30:58 <malo_> #endmeeting