19:10:15 <ennael> #startmeeting 19:10:15 <Inigo_Montoya> Meeting started Tue Jun 20 19:10:15 2017 UTC. The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:10:15 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic. 19:10:31 <ennael> ok so here is a meeting dedicated to Mageia 6 19:10:53 <DavidWHodgins> http://madb.mageia.org/tools/blockers 19:10:59 <[mbot`> [ Mageia App Db - Current Blockers ] 19:11:47 <DavidWHodgins> bug 19103 - I'm not sure if that's fixed or not. May require new iso images when it is. 19:12:07 <ennael> new kernel just synced on build host 19:12:34 <Pharaoh_Atem> tmb: \o 19:12:42 <tmb> hi all 19:12:58 <filip_> hi tmb. nice to see you 19:12:59 <DavidWHodgins> bug 19691 - Could be treated as an errata item, as the defualt is to have pulseaudio enabled 19:13:05 <DavidWHodgins> HiYa tmb 19:13:07 <wilcal> I'd like to add that as we go though this list we identify those bugs that can really be worked after release vs those that really hold up release 19:13:19 <stormi> hi 19:14:01 <DavidWHodgins> The main ones that can't be fixed after release either prevent usage of live isos in live mode, or prevent installing and then getting updates 19:14:17 <DavidWHodgins> Those are the only ones that should be considered blockers 19:14:34 <wilcal> I agree but there is also the frequency that they occur 19:14:44 <DavidWHodgins> Or really make Mageia look bad. :-) 19:15:01 <wilcal> Yup 19:15:14 <filip_> DavidWHodgins: is there such thing? 19:15:24 <wilcal> 21082 I put on here today as it occurs but does not prevent install 19:15:43 <wilcal> I'm thinking it can be fixed after release 19:16:08 <DavidWHodgins> For bug 21063, plasma getting black screen on boot, I think should be an errata item with "Don't use plasma on really old hardware" 19:16:16 <wilcal> There's also some ugly Plasma things that are probably upstream 19:16:23 <DavidWHodgins> filip_: Rare, but possible 19:16:48 <wilcal> yes but does it happen enough to prevent release 19:17:29 <filip_> does QA team try Neon also to see if Plasma bugs are upstream? 19:17:41 <wilcal> I did two installs today in prep for this meeting. One on real hardware and one Vbox 19:18:08 <DavidWHodgins> filip_: Not that I know of. I don't, and no one else has mentioned it. 19:18:27 <wilcal> both installs were 100% successful. the vbox exhibited 21082 19:18:50 <wilcal> occasionally 19:19:26 <DavidWHodgins> bug 21107 - change in rpm checksums from md5 to sha should not be a blocker. It just requires a lot of care when upgrading from Mageia 5 19:20:04 <wilcal> I agree David 19:20:24 <wilcal> Can you change the status of that one please 19:20:26 <marja> DavidWHodgins: the example was wrong, it also applies to normal packages 19:20:32 <marja> wilcal: I don't agree, yet 19:20:53 <marja> that bug isn't only about 32 + 64 bit devel packages 19:21:01 <marja> but also about other packages 19:21:30 <DavidWHodgins> Most of which have already been fixed, or we'd be seeing a lot more problems in our upgrade tests 19:22:10 <wilcal> IMO M5 -> M6 upgrade issues are hotly debated 19:22:13 <filip_> DavidWHodgins: Plasma 5.8 as User LTS Edition: https://files.kde.org/neon/images/neon-userltsedition/current/ 19:22:14 <[mbot`> [ Index of /neon/images/neon-userltsedition/current ] 19:22:17 <marja> DavidWHodgins: ok, if you're sure upgrading is fine in general, then I'm ok with downgrading 19:22:25 <wilcal> Should it be an errata thing? 19:22:40 <marja> downgrading priority 19:22:51 <marja> wilcal: I wouldn't know how to woraround it 19:22:52 <wilcal> Caution on M5 KDE - M6 Plasma 19:23:00 <DavidWHodgins> Yes, with a caution that it may impact upgrading 19:23:05 <marja> wilcal: ah, that's a different one 19:23:18 <DavidWHodgins> wilcal: Any m5 to m6. It's not just plasma 19:23:25 <wilcal> A very complex system may not be successful 19:24:07 <wilcal> M5.1 Xfce up-to-date > 19:24:22 <wilcal> -> M6 Xfce is successful here 19:26:51 <DavidWHodgins> bug 21081 (black screen on live iso boot) is very annoying. Intermittent bugs are hard to reproduce, or confirm fixed when they are. I think that should be an errata item with the suggestion to reboot 19:27:41 <wilcal> I am agreeing with David 19:27:54 <marja> ok 19:28:04 <DavidWHodgins> Change it from blocker to for errata :-) 19:29:08 <DavidWHodgins> bug 19196 (buttons not visible), I haven't looked at. I haven't seen the problem myself in my tests 19:29:44 <DavidWHodgins> Same with hidden buttons in bug 20624 19:29:50 <wilcal> Not enough occurance to be a blocker IMO 19:29:52 <Pharaoh_Atem> I haven't observed either myself 19:30:03 <wilcal> https://bugs.mageia.org/show_bug.cgi?id=19691 19:30:05 <[mbot`> [ 19691 phonon defaults to Pulse backend even if PulseAudio is disabled ] 19:30:09 <lebarhon> I had the problem, it is fixed now 19:30:11 <wilcal> what you say on this one David? 19:30:37 <wilcal> 37 days without activity 19:30:39 <DavidWHodgins> pulseaudio is enabled by default, so that should not be a blocker 19:30:59 <Pharaoh_Atem> that can be fixed as errata 19:31:08 <Pharaoh_Atem> since we use Pulse by default 19:31:11 <wilcal> KInda the same thing I found with my copy vs link on Plasma desktop icons 19:31:29 <DavidWHodgins> It only affects installs where the user chooses to change the sound target 19:33:05 <wilcal> https://bugs.mageia.org/show_bug.cgi?id=20905 19:33:07 <[mbot`> [ 20905 Draklive: "Remove unneeded software" remove libreoffice ] 19:33:15 <wilcal> status??? 19:33:16 <DavidWHodgins> Errata 19:33:40 <DavidWHodgins> In my opinion 19:34:12 <wilcal> It's been done I see 19:34:34 <filip_> we make "Remove unneeded software" to accessible to newcomers 19:34:40 <DavidWHodgins> So change from blocker to in_errata 19:34:47 <DavidWHodgins> s /to/too/ 19:34:57 <lebarhon> I agree with filip 19:35:04 <DavidWHodgins> I agree, it would be better to default to not removing 19:35:16 <wilcal> https://bugs.mageia.org/show_bug.cgi?id=21109 19:35:18 <[mbot`> [ 21109 repodata.old.* dirs in each repo dir need to be purged ] 19:35:20 <wilcal> and 19:35:24 <wilcal> https://bugs.mageia.org/show_bug.cgi?id=21110 19:35:26 <[mbot`> [ 21110 rpm-md repodata missing for most armv7hl repos ] 19:35:45 <Pharaoh_Atem> the former is technically not "release blocking" in the sense it hurts anyone 19:35:47 <wilcal> These do not prevent a clean install 19:35:53 <Pharaoh_Atem> the latter breaks arm stuff 19:36:09 <DavidWHodgins> I don't think either of those should be blockers. They don't affect install or usage on i586 or x86_64. arm is still experimental 19:36:19 <wilcal> Agreed 19:36:38 <wilcal> We're knock'em out David :-)) 19:36:41 <DavidWHodgins> We don't have arm iso images 19:36:51 <Pharaoh_Atem> no, but we are supposed to have disk images for release 19:36:57 <filip_> unfortunate for arm ;) 19:37:03 <wilcal> Not gonna make it 19:37:33 <DavidWHodgins> While it would be nice it arm was working, not having it working shouldn't block the i586 and x86_64 release 19:37:44 <DavidWHodgins> The arm disk images could be released later 19:37:47 <Pharaoh_Atem> sure 19:37:51 <filip_> DavidWHodgins: indeed but we can mark it unsupported? 19:37:59 <Pharaoh_Atem> but we don't have a nice granularity like that in bugzilla :) 19:38:13 <DavidWHodgins> It's currently marked experimental where it is described 19:38:38 <DavidWHodgins> As far as I know, no one on the qa team has any arm hardware to test with 19:38:50 <Pharaoh_Atem> not even Raspberry Pi? 19:39:00 <DavidWHodgins> Not that I know of 19:39:32 <wilcal> I have 3 Pi's here, two the latest and one previous version 19:39:45 <Pharaoh_Atem> the Pi is the primary target of the ARM ports 19:39:51 <wilcal> I am ready when they are 19:40:00 <wilcal> I would expect so 19:40:39 <DavidWHodgins> Perhaps we could include in the release announcment that arm release is being delayed 19:41:00 <Pharaoh_Atem> sure 19:41:18 <filip_> that would be fair as arm as a feature is in the wiki for some time already 19:41:41 <wilcal> so take 21110 off the blocker list 19:42:42 <filip_> yeah. releasing i586 and x86_64 should be our priority 19:43:02 <DavidWHodgins> Yes. We should have new tags for arm release blockers, seperate from normal release blockers 19:43:09 <wilcal> So all this cuts the list down considerably 19:43:28 <Pharaoh_Atem> we should have a concept of secondary arches 19:43:29 <filip_> stormi: any comments on BZ tags? 19:43:31 <Pharaoh_Atem> like Fedora does 19:43:49 <Pharaoh_Atem> secondary arches do not necessarily release the same time as primary arches 19:44:07 <Pharaoh_Atem> (though nowadays, in Fedora, they do, but they are still not release-gating) 19:44:26 <filip_> Pharaoh_Atem: are they equally supported? 19:44:37 <DavidWHodgins> Just out of curiosity, what's the main difference between armv5 and armv7? 19:44:37 <Pharaoh_Atem> as of Fedora 25, yes 19:44:57 <Pharaoh_Atem> DavidWHodgins: armv5tl is the base arm32 arch that all ARM hardware supports these days 19:45:14 <Pharaoh_Atem> it's a soft-float arch that is broadly compatible with various microcontrollers and whatnot 19:45:31 <Pharaoh_Atem> it's commonly used in things like secondary CPU chips for server IPMI, etc. 19:45:43 <Pharaoh_Atem> armv7hl is the most common arm32 arch used today 19:45:46 <DavidWHodgins> So similar to pre math copresser systems 19:45:50 <Pharaoh_Atem> yeah 19:45:57 <Pharaoh_Atem> but it's a full CPU and can do things 19:46:00 <DavidWHodgins> Yuck. :-) 19:46:16 <Pharaoh_Atem> armv5tl lacks hardware support for floating point math 19:46:29 <Pharaoh_Atem> it's done through emulation through fun tricks with bit shifting :D 19:46:42 <wilcal> gracious 19:46:47 <Pharaoh_Atem> armv7hl is a newer arch, and really the end of the line for 32-bit arm 19:47:00 <Pharaoh_Atem> it's the arch used in nearly all ARM single board computers made before 2016 19:47:09 <Pharaoh_Atem> (and after 2014) 19:47:14 <DavidWHodgins> So armv5 is 32 big and armv7 is 64 bit with math support? 19:47:21 <Pharaoh_Atem> no 19:47:25 <Pharaoh_Atem> no 64-bit in armv7 19:47:31 <Pharaoh_Atem> armv8 introduces 64-bit 19:47:41 <Pharaoh_Atem> that's coming for Mageia 7, I believe 19:47:50 <DavidWHodgins> So just the math support between v5 and v7 19:47:52 <Pharaoh_Atem> it's known as AArch64 19:48:01 <Pharaoh_Atem> there's also some other instructions that have been added 19:48:11 <Pharaoh_Atem> think of like how i386 -> i486 -> i586 -> i686 19:48:21 <DavidWHodgins> Ok. Gotcha. Thanks 19:49:28 <DavidWHodgins> For bug 18669, appdata for installers other then urpmi, what's happening? 19:49:41 <Pharaoh_Atem> really, there's only one thing that needs to happen 19:49:56 <Pharaoh_Atem> someone needs to run the appstream-builder to generate the metadata and append it 19:50:13 <Pharaoh_Atem> without this information, GNOME Software (the mandatory software manager+updater for GNOME) just doesn't work 19:50:36 <DavidWHodgins> tmb: Can you arrange to get that done, or get another sysadmin to do it? 19:50:45 <Pharaoh_Atem> Plasma Discover, one of the PackageKit frontends for Plasma, needs it too 19:50:54 <DavidWHodgins> Pharaoh_Atem: Is the repodata on the iso images? 19:50:57 <Pharaoh_Atem> no 19:51:04 <Pharaoh_Atem> at least I don't think so? 19:51:10 <Pharaoh_Atem> I don't know how we generate install ISOs 19:51:15 <Pharaoh_Atem> but I don't think so, not for Mageia 6 19:51:18 <wilcal> generated after the install? 19:51:27 <Pharaoh_Atem> it's appended to the online repodata 19:51:37 <DavidWHodgins> If it doesn't affect the iso images, than it shouldn't be a release blocker 19:51:39 <Pharaoh_Atem> so it's part of the repodata fetched by PackageKit 19:52:02 <Pharaoh_Atem> DavidWHodgins: I made it one because reviewers have already been dinging us during the development releases about broken GNOME Software and Plasma Discover 19:52:13 <Pharaoh_Atem> it's a pretty broken out of the box experience 19:52:34 <ennael> repodata . 19:52:35 <ennael> ? 19:52:41 <Pharaoh_Atem> repository metadata 19:52:43 <tmb> no it isn't on isos as urpmi is still our supported default package manager wich does not need it 19:52:51 <DavidWHodgins> So it should be very high priority, but shouldn't be a blocker 19:53:08 <wilcal> fix after release? 19:53:24 <DavidWHodgins> fix asap, but not hold release due to it 19:53:26 <Pharaoh_Atem> I mean, building release ISOs has no particular requirement on appstream right now 19:53:43 <tmb> but I'll try to get to it after I fix up wiki 19:53:45 <wilcal> That's another one off the blocker list 19:53:50 <Pharaoh_Atem> tmb: thanks 19:54:01 <Pharaoh_Atem> if you need any assist on figuring out the appstream-builder stuff, please let me know 19:54:20 <wilcal> Is there anything here preventing us releasing the final final isos? 19:54:50 <Pharaoh_Atem> I don't think so 19:55:17 <DavidWHodgins> The new kernel has just been synced to the build directory. I think we should have one more set of iso images, which will be expected to be the release version 19:55:23 <wilcal> so lets do that 19:55:28 <wilcal> I again agree with David 19:55:36 <tmb> so... do we flip mageia-release switch ? 19:55:44 <wilcal> Hey!!!! We're pretty in sync today David :-)) 19:55:48 <DavidWHodgins> :-) 19:55:48 <Pharaoh_Atem> if we're going to do that, mageia-repos needs to be flipped too 19:56:17 <wilcal> isos by mid next week or sooner? 19:56:17 <DavidWHodgins> tmb: I'd hold off on that till the images have gone through basic testing to ensure no problems creep in during iso building 19:56:28 <wilcal> agreed one more look see 19:56:53 <Pharaoh_Atem> it'll be nice to have a fresh Mageia 6 release to go to London with :D 19:57:09 <wilcal> What's your London Date? 19:57:17 <Pharaoh_Atem> I'm flying out this Saturday 19:57:32 <Pharaoh_Atem> I'll be in London for a week 19:57:35 <DavidWHodgins> I'm assuming that by "flipping release switch", that would put the iso images into the release directory rather than the cauldron directory 19:57:46 <tmb> Just one note... when we flip mageia-release switch we will stop freeze pushes also to not get newer packages in /release than what is on isos 19:58:01 <Pharaoh_Atem> DavidWHodgins: actually mageia-release and mageia-repos need to be rebuilt to %mkrel 1 and set %am_i_cauldron to 0 19:58:18 <Pharaoh_Atem> that changes the configuration for the two to declare as a release tree 19:58:26 <DavidWHodgins> Ah. Force new packages to updates rather than release dir. If that's all it does, then yes 19:58:35 <filip_> there's one thing not really a high priority but still important: currently there's no way to update/upload PDF and EPUB doc files which also includes install manual. 19:59:15 <filip_> https://www.mageia.org/doc/ 19:59:16 <[mbot`> [ Mageia Documentation ] 19:59:30 <tmb> and then several drakx-installer* packages need to be rebuilt to pick up release status 19:59:51 <DavidWHodgins> tmb: Probably best to announce first on dev mailing list, and see if there are any last minute updates worth including 20:00:01 <wilcal> create the final final isos, give us till mid next week then flip the switch on like the 29th? 20:00:24 <wilcal> out the door by end of month 20:00:47 <DavidWHodgins> I think flip the switch as soon as the build repo is synced. That way any updates created while testing the iso images will be in the updates repo. 20:00:49 <tmb> wilcal, we need to flip the switch before building "final final" isos 20:00:51 <filip_> good that sounds nice 20:01:06 <wilcal> so one more review isos 20:01:07 <DavidWHodgins> Or just before starting the sync of the build repos 20:01:43 <tmb> filip_, what do you need 20:01:46 <Pharaoh_Atem> I think we should go ahead and flip it now 20:02:02 <wilcal> present isos are a little stale 20:02:06 <filip_> tmb: you did an marcom ftp access in the past 20:02:25 <DavidWHodgins> So "flip switch, sync repos, generate new iso images, test iso images for obvious build problems, and if ok release" 20:02:33 <ennael> I would go for building another set of isos before final one 20:02:48 <wilcal> i agree with ennael 20:04:01 <DavidWHodgins> I'm expecting this next set to be the final. What updates are we waiting for before final? 20:04:27 <tmb> filip_, I wonder... should we use git instead, or do you need ftp ? 20:04:32 <Pharaoh_Atem> DavidWHodgins: yep 20:04:34 <wilcal> I got to say that this little old Dell Laptop really loves M6 x86_64 Plasma big time 20:04:34 <ennael> in fact next set would be the one for last tests 20:04:43 <ennael> then final one is just mageia release update 20:05:02 <filip_> tmb: as long we can DL files it doesn't really matter 20:05:03 <DavidWHodgins> Yes, and copying the tested iso images to the release dir 20:05:26 <ennael> also do we have a proper left background for classical installer 20:05:36 <filip_> tmb: s/we/general public/ 20:05:38 <tmb> filip_, I was thinking using git would give us revision control that ftp does not have 20:06:00 <DavidWHodgins> ennael: Didn't notice. :-) I'll test again after the meeting to check 20:06:08 <filip_> tmb: but the space is in hundreds of MB 20:06:50 <DavidWHodgins> So can we agree with "flip switch, sync repos, generate new iso images, test iso images for obvious build problems, and if ok release"? 20:07:04 * Pharaoh_Atem gives a thumbs up 20:07:05 <wilcal> Agreed 20:07:11 <Schultz> I guess I should get the release announcement started then, its looking promising 20:07:20 <Pharaoh_Atem> I've also nearly got my DNF 2.0 blog ready 20:07:22 <wilcal> IT'S COMING TO AN END YIPPEEEE 20:07:35 <Pharaoh_Atem> it's almost exactly two years since I started working on DNF for Mageia 20:07:55 <DavidWHodgins> Assuming everything goes well, let's plan on confirming release in next weeks council meeting. 20:07:56 <wilcal> It's way better then M5.1 20:08:27 <Pharaoh_Atem> then we can focus on Mageia 7 20:08:30 <wilcal> By month end for sure 20:08:32 <Pharaoh_Atem> and how we'll change the world! 20:08:52 <filip_> tmb: if space is not an issue we already have atelier git space. so only git -> mirrors step is necessary I guess? 20:09:04 <DavidWHodgins> be right back 20:11:25 <tmb> filip_, We could try that for now. just let me know what git path needs to be exported to mirror tree 20:12:58 <filip_> tmb: so I just build somewhat future-proof git structure and email you privately? 20:13:12 <tmb> filip_, yes 20:14:09 <DavidWHodgins> back 20:14:30 <DavidWHodgins> Anything else to discuss? 20:14:32 <filip_> tmb: mga5 has currently 274 MB, mga4 242MB. mga6 will probably have even more. 20:14:54 <Pharaoh_Atem> filip_: what is this for? 20:14:58 <DavidWHodgins> mga4 is eol, so shouldn't that be removed? 20:15:12 <filip_> Pharaoh_Atem: PDF and EPUB doc files 20:15:15 <Pharaoh_Atem> ah 20:15:38 <filip_> DavidWHodgins: indeed. I guess we don't need to git it ;) 20:15:48 <ennael> DavidWHodgins: so when shall we rebuild new isos ? 20:15:50 <tmb> filip_, you only need to do mga6 at this point... the others are already on mirrors 20:15:53 <Pharaoh_Atem> keep in mind that with binary files, unless you have a lookaside or git-lfs, it'll make everything slow :( 20:15:58 <filip_> tmb: true 20:15:59 <Pharaoh_Atem> and huge 20:16:19 <DavidWHodgins> ennael: As soon as the switch is flipped to stop new packages being built in the release directories 20:16:48 <DavidWHodgins> And then any changes synced to the build repo 20:16:50 <Pharaoh_Atem> tmb, ennael: should I go ahead and commit mageia-repos switch flip? 20:17:04 <ennael> we need to check stage2 background 20:17:49 <DavidWHodgins> Checking now ... 20:18:15 <ennael> yep it's rc one 20:18:36 <DavidWHodgins> Yep. That needs to be fixed before flipping switch 20:19:13 <ennael> looking for a proper image but I think I don't have it here 20:23:01 <Schultz> Which is the image, I should have it somewhere 20:24:05 <ennael> that would be great 20:24:52 <Schultz> Is it the tall thin image on the left of the installer? 20:25:01 <DavidWHodgins> Schultz: Yes 20:25:17 <DavidWHodgins> It currently has Mageia 6 rc 20:25:27 <DavidWHodgins> The rc needs to be removed 20:26:14 <marja> DavidWHodgins: so we have those 4 release blockers left, correct? http://madb.mageia.org/tools/blockers or did I remove too many or too few? 20:26:19 <Schultz> Ok, I have the gimp file for mga5, will make one for 6 now 20:26:20 <[mbot`> [ Mageia App Db - Current Blockers ] 20:27:15 <wilcal> Big change from when we started today 20:27:22 <DavidWHodgins> Argh. Yes. I'm getting too impatient. 20:27:34 <wilcal> Good job everyone 20:27:57 <wilcal> This thing should be out the door by end of month 20:28:12 <DavidWHodgins> So we need those 4 fixed, and then start with flipping the switch etc. 20:28:36 <wilcal> where will the new isos for review land 20:29:09 <ennael> Schultz: can you push it in git repository ? 20:29:11 <filip_> should we conclude the meeting? 20:29:15 <wilcal> yes 20:29:46 <wilcal> david tell us/qc where these final isos for review are 20:29:49 <Schultz> ennael: no, I have svn access, no git, no idea why 20:31:01 <Schultz> ennael: https://drive.google.com/file/d/0B35tx4Q9SNELdG9abXhVQ3JjNEE/view?usp=sharing 20:31:02 <[mbot`> [ left-background.png - Google Drive ] 20:31:08 <Schultz> That look ok? 20:31:53 <ennael> yep 20:31:59 <DavidWHodgins> ennael: Drop the rc from the directory and file names for next iso images? 20:32:47 <DavidWHodgins> Or one more rc iso to when those 4 blocker bugs fixed? 20:34:03 <Schultz> ennael: great, would be nice to get all of these files onto the artwork git, no idea how many duplicates there are, but I know that myself and Remi keep distinct versions of pretty much everything. So if there is someone with git foo that can work out whats broken it would be great 20:34:30 <ennael> its in drakx repository 20:35:54 <Schultz> the .xcf as well? 20:36:45 <marja> Schultz: is there a bug report about git access not working for you? 20:37:24 <Schultz> marja: nope, always got Remi to push everything and the sysadmins had bigger fish to fry. Will check it again and file if needed 20:37:54 <marja> Schultz: thanks... the amount of sysadmins should increase rapidly :-) 20:38:19 <Schultz> marja, well, as long as I'm not one of them thats all great :) 20:38:32 <marja> lol 20:39:24 <Schultz> if they want me to actually build the hardware, that might work, but no promises 20:39:41 <marja> :-) 20:40:03 <DavidWHodgins> So for Mageia 6, we have 4 blocker bugs. When those are fixed, flip the relase switch, sync repos, build iso images (with correct image), test, and if ok release 20:40:13 <DavidWHodgins> Shall we close the meeting? 20:40:17 <wilcal> Please 20:40:23 <ennael> ok 20:40:43 <wilcal> bye all 20:40:52 <ennael> #endmeeting