20:11:17 <ennael> #startmeeting
20:11:17 <Inigo_Montoya> Meeting started Mon Mar 23 20:11:17 2015 UTC.  The chair is ennael. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:11:17 <Inigo_Montoya> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:11:40 <DavidWHodgins> Just syncing the latest classical installer iso images here.
20:11:46 <ennael> ok yet another meeting about mageia 5 :)
20:12:08 <DavidWHodgins> MrsB: reported on the mailing list, that gnome is still failing on her system with the "Oh no" message.
20:12:33 <wilcal> On the installed version i think
20:12:45 <wilcal> I tried the live-cd this morning and it was ok
20:12:52 <DavidWHodgins> diskdrake still doesn't handle existing gpt efi partitions when selecting "use existing partitions".
20:12:59 <ennael> wait wait
20:13:06 <ennael> once at a time :)
20:13:48 <ennael> so just to start with a positive point, progress have been done last week :)
20:14:02 <ennael> we have a sheet to follow all release critical bugs
20:14:12 <ennael> and Akien made an amazing job on it :)
20:15:37 <ennael> https://bugs.mageia.org/show_bug.cgi?id=15486
20:15:39 <[mbot> [ Bug 15486 Upgrade from Mga4 does not update vmlinuz or initrd.img symlinks and new initrd still has Mga4 plymouth ]
20:15:53 <ennael> tmb: did you have time this we on that one ?
20:17:18 <ennael> ok let see later if tmb is around :)
20:17:58 <ennael> #15389 has beend fixed
20:18:05 <ennael> Os-prober mixes UUID when several Mageia are installed.
20:19:13 <ennael> https://bugs.mageia.org/show_bug.cgi?id=15350
20:19:15 <[mbot> [ Bug 15350 Upgrade failed mga4 to mga5 when adding online media to DVD - 195 transactions failed ]
20:19:30 <ennael> still pênding I will post there to relaunch tests
20:19:34 <ennael> debug is in progress
20:20:04 <ennael> https://bugs.mageia.org/show_bug.cgi?id=14520
20:20:06 <[mbot> [ Bug 14520 Outdated ldconfig cache resulting in "Oh no! Something has gone wrong" in GNOME (liveDVD with xdriver=...) ]
20:20:35 <ennael> wilcal: is it that one you were talking about ?
20:21:05 <wilcal> yes the live media Gnome Live-CD was fine
20:21:17 <wilcal> the iso release a couple days ago
20:21:23 <wilcal> I did not get to installing it
20:21:36 <ennael> so it works on live mode but not installed one
20:21:39 <Akien> tmb said he borrowed some hardware to have a look at it
20:21:57 <Akien> If coling is around and has an opinion about the bug, we could use it too :)
20:22:16 <ennael> coling: leave your dog alone we need your light :)
20:22:28 <wilcal> tried an gnome install using the boot.iso file this morning and that booted to a blank screen
20:22:47 <wilcal> kde was fine with the same boot.iso file
20:23:02 <wilcal> maybe some connection there
20:23:02 <ennael> so gnome issue on every lkind of install?
20:23:09 <wilcal> seems
20:23:13 <wilcal> kde is golden
20:24:13 <ennael> damned
20:24:16 <tmb> I have hw that reproduces it nicely... it seems to happend only on old amd/ati hw where we switch from proprietary driver to the free one
20:25:13 <tmb> I'm testing different ways of fixing it, but its time consuming
20:25:14 <wilcal> all my testing today was in Vbox
20:25:41 <Luigi12_work> ennael: it's National Puppy Day
20:26:01 <tmb> as for happening only on gnome and not on kde, that's because gnome relies more heavily on working opengl...
20:27:43 <ennael> ok that one needs more debigug
20:27:49 <ennael> argh
20:27:49 <ennael> debug
20:28:01 <wilcal> Ya and also a real release blocker
20:28:31 <ennael> we know it :)
20:29:21 <ennael> #13687 has been closed
20:29:31 <ennael> GDM fails on first boot, but succeeds when then doing "systemctl restart prefdm.service" (or a plain reboot)
20:30:30 <ennael> #12316 will be reworked for Mageia 6
20:30:40 <ennael> as it needs intrusive dev and time in installer
20:30:59 <Luigi12_work> wait
20:31:10 <Luigi12_work> bug 13687 comment 40 seems to say the bug was still valid
20:31:30 <Luigi12_work> was that confirmed to be inaccurate?
20:32:05 <ennael> "the issue for which is was reopened is a dup of bug 15468."
20:32:08 <ennael> Akien: ?
20:32:24 <Luigi12_work> but comment 40 seems to be confirming the original bug
20:32:43 <Luigi12_work> oh actually it's unclear
20:32:51 <Luigi12_work> I don't know if he meant Oops as in fail whale, or Oops as it doesn't work
20:33:05 <Luigi12_work> fail whale is indeed 15468
20:33:39 <Luigi12_work> sorry that just occurred to me.  I guess you can ignore it.  Someone can speak up if the original issue is still valid.
20:34:23 <Akien> Back
20:34:41 <Luigi12_work> we can move on :o)
20:34:55 <ennael> Akien: want to comment that one?
20:35:08 <Akien> Actually bug 13687 was another bug, and the issue for which I reopened it was reported by MrsB in bug 15468
20:35:24 <Akien> So I prefered to close again the old bug, so that we focus on the new (better) report
20:35:30 <Luigi12_work> 13687 was the one where it didn't work the first time, but did after restarting the service or rebooting
20:35:39 <Akien> Yep
20:35:43 <Luigi12_work> 15468 is fail whale, an unrelated issue
20:36:16 <Luigi12_work> the comment 40 said didn't work the first time but did after reboot, but he said "Oops."  Just not sure if that meant fail whale or just that it didn't work
20:36:26 <Luigi12_work> but anyway, he or someone can speak up if the old bug is still there
20:36:52 <Akien> Luigi12_work: But as per Claire's comment 13 on 15468 "After rebooting again Gnome starts OK, so this is probably a duplicate."
20:37:01 <Luigi12_work> ooh ok
20:37:01 <Akien> That's wy we close 13687 as a dup
20:37:09 <Luigi12_work> different bugs with a similar symptom
20:37:10 <Akien> *why
20:37:40 <Akien> IMO it's the same bug, but we'll see once 15468 gets fixed :-)
20:37:54 <Luigi12_work> I don't think 13687 had anything to do with fail whales
20:38:06 <Luigi12_work> those didn't start get mentioned until very later comments and seemed to be an unrelated issue
20:38:31 <Akien> Luigi12_work: It has from comment 30 onward
20:38:45 <Luigi12_work> people were mixing two issues in the same bug report
20:38:51 <Luigi12_work> which is why I commented in it
20:38:52 <Akien> That's when I reopened the bug that had been solved, but the symptoms I describe are actually bug 15468
20:39:01 <Luigi12_work> ok
20:39:06 <Akien> That's why I close again the old bug
20:39:08 <Luigi12_work> moving on then, sorry for the noise
20:39:10 <Akien> *closed
20:39:23 <Akien> Np, it's better when it's clearer :-)
20:41:05 <ennael> #10077 is also postponed to mageia 6
20:41:12 <ennael> live installs do not ask for network configuration
20:41:33 <Luigi12_work> yeah that's a minor issue
20:42:11 <ennael> https://bugs.mageia.org/show_bug.cgi?id=15253
20:42:13 <[mbot> [ Bug 15253 5b3: Display corruption once the cursor moves (64bit is KO, 32bit is OK) with 16bpp & 24bpp (OK with 15bpp) ]
20:42:15 <ennael> another tricky one
20:43:06 <Akien> I think wally_ ran into it and worked around it with some kernel parameters
20:43:17 <Luigi12_work> is this one related to libx86 or is it from something else?
20:45:48 <Akien> MrsB does say that it would be 64bit-only
20:46:16 <Luigi12_work> wally was saying his issue was I think
20:46:54 <wally_> hi and yeah, it only happened with x86_64 installer
20:47:15 <wally_> no problems with i586
20:48:43 <ennael> so to be investigated;..
20:49:14 <ennael> https://bugs.mageia.org/show_bug.cgi?id=13829
20:49:16 <[mbot> [ Bug 13829 Hardware detection tool: 'kernel modules' makes a mess of the GUI and hdt stops working ]
20:50:04 <ennael> I'd like to decrease priority. modules list has been disabled when pb occurs
20:50:23 <Luigi12_work> that's fair
20:50:27 <ennael> it's not really fixed as there are still pb for some configurations
20:50:37 <ennael> but at least it's not messed anymore
20:50:50 <Luigi12_work> this is one of those "doctor, it hurts when I do this"  "doctor: then don't do that" bugs
20:51:09 <ennael> if we have a fix before release then great otherwise it will be for mageia 6 for install media
20:51:35 <wilcal> How can we mark that on the release blockers listing
20:52:04 <ennael> we will add it to mageia 6
20:52:08 <ennael> Akien:
20:52:14 <ennael> Akien created a tracker for it
20:53:38 <Akien> Yep, https://bugs.mageia.org/show_bug.cgi?id=15527
20:53:40 <[mbot> [ Bug 15527 [Tracker] Mageia 6 release critical ]
20:54:13 <ennael> https://bugs.mageia.org/show_bug.cgi?id=15235
20:54:15 <[mbot> [ Bug 15235 Unable to boot, from Live media or after install ]
20:54:22 <ennael> we need some feedback here
20:54:25 <Akien> It's more of a todo-list than release critical bugs, but this tracker will normally evolve to be the real release critical tracker when we near the mga6 release
20:56:04 <Akien> It looks like Alan doesn't have access to RC isos, so he can't do further testing
20:57:29 <ennael> ah maybe we can manage this
20:57:38 <ennael> so that we can have a quick status
20:57:51 <ennael> as he is the only one working on that one
20:58:11 <Akien> Yep I'll get in touch with him to get him in the iso testers list
20:58:19 <Akien> He's from atelier
20:58:54 <ennael> thanks
20:58:55 <ennael> https://bugs.mageia.org/show_bug.cgi?id=12305
20:58:57 <[mbot> [ Bug 12305 System crashed after upgrading from Mga3 to Cauldron. Stops after splash screen with message, /dev/resume does not exist. ]
20:59:31 <wilcal> Is this really a valid bug
20:59:39 <Luigi12_work> yes
20:59:42 <wilcal> M3 is not supported
20:59:47 <Luigi12_work> ignore that part
21:00:08 <Luigi12_work> I gave a better description of what that bug's about on the mailing list
21:00:20 <Luigi12_work> https://ml.mageia.org/l/arc/dev/2015-03/msg00504.html
21:00:21 <[mbot> [ dev - Developement discussion list - arc_protect ]
21:00:24 <Luigi12_work> it's the second bug listed
21:01:21 <Luigi12_work> or as I said on the blockers spreadsheet "dracut needs to be fixed to not fail the boot when failing to find swap partition; installer should ensure consistent/correct UUID usage in bootloader, fstab, dracut configs"
21:02:06 <Luigi12_work> I had this same problem when installing mga4 on my new computer last year.  Good thing I know what the heck I'm doing.  This is a serious bug.  dracut needs to stop the insanity already.
21:02:14 <Akien> So that's a treat for coling I guess? :)
21:02:23 <Luigi12_work> if he has time, hopefully
21:03:10 <ennael> ok
21:03:29 <Luigi12_work> of course the installer part wouldn't be his, or would it?  I dunno.
21:05:17 <wally_> 2
21:05:22 <wally_> oopsie
21:06:07 <ennael> https://bugs.mageia.org/show_bug.cgi?id=15374
21:06:09 <[mbot> [ Bug 15374 btrfs / and /home on sda7 and sda8 correctly forces grub2 but is unable to install it ]
21:07:42 <ennael> so we are very near release
21:08:02 <ennael> either we have someone able to enforce this or this will have to be documented
21:08:20 <ennael> I will try to ping pterjan on that one
21:08:46 <ennael> he is able to work on it. But if no time I'm afraid this will have to be fixed in mageia6
21:09:55 <Luigi12_work> yeah I guess btrfs is still considered experimental at this point
21:10:23 <ennael> https://bugs.mageia.org/show_bug.cgi?id=13894
21:10:25 <[mbot> [ Bug 13894 When installing, showing package details, scrollbar does not work as expected ]
21:10:34 <tmb> btrfs = Buggier Than ReiserFS :)
21:10:38 <ennael> :)
21:10:39 * tmb hides
21:10:42 <ennael> thanks tmb :)
21:10:57 <ennael> about that bug we had a first fix included for the current isos
21:10:58 <Akien> This one should be resolved, just needs confirmation I guess
21:11:09 <ennael> yep but do we have it in isos?
21:11:12 <Luigi12_work> tmb: nice!
21:11:14 <Akien> Ah good question
21:11:16 <ennael> I guess it's the old one
21:11:18 <ennael> not sure
21:11:29 <ennael> but it can be checked using boot.iso
21:12:08 <tmb> yeah, we only have the first revision on the isos
21:12:09 <Akien> The better fix is in 16.70
21:12:17 <ennael> yep
21:13:41 <ennael> ok so just need to be confirmed
21:13:42 <Akien> But yes if the fix is confirmed in boot.iso, we can close the bug IMO
21:13:51 <ennael> ok
21:13:56 <ennael> volunteer to test it?
21:14:05 <coling> Luigi12_work, Akien so the dracut thing above is our own patch. Just remove it and kill the file.
21:14:40 <coling> Luigi12_work, this will break resume from hibernation when swap is on raid or LVM (thats why the patch exists) but it's of lesser importance I guess.
21:14:59 <coling> (i.e. remove the patch and kill the /etc/dracut.conf.d/ file snippet it writes.
21:14:59 <Luigi12_work> much much much lesser
21:15:30 <coling> Well, the people reporting those bugs were annoyed, but meh. I don't have enough time to care about them just now.
21:15:57 <Luigi12_work> minor annoyance vs. the worst regression I've seen in 16 years...yeah I'll take the former :o)
21:16:39 <coling> Luigi12_work, well, this has been there since mga 2 or 3 so surprised it's taken so long to get that annoyed....
21:17:00 <coling> Anyway, I think there may not be any patch, just the config file.
21:17:34 <Luigi12_work> no people have been plenty annoyed with it for quite a while (myself included), although me maybe moreso since I ran into it first hand last year, but now we want to fix it finally :o)
21:18:13 <Luigi12_work> not sure how refusing to boot fixes resuming from swap on RAID or LVM though
21:19:35 <leuhmanu> we are on rc, such change are a little big no ?
21:19:41 <Luigi12_work> no
21:20:05 <coling> Luigi12_work, well refusing to boot when the swap partition that you hibernated to with critical documents unsaved seems pretty reasonable to me!
21:20:14 <coling> Luigi12_work, but there are always other perspectives.
21:20:31 <Luigi12_work> that doesn't fix anything
21:20:36 <Luigi12_work> or maybe I'm missing something
21:20:44 <coling> Luigi12_work, but it doesn't destroy your unsaved data either.
21:20:50 <Luigi12_work> leuhmanu: also the part about having the installer make sure UUIDs are correct/consistent surely isn't controversial
21:21:15 <coling> Luigi12_work, this http://pastebin.com/NpREZfHa that shoudl remove the feature. To be fair there should be a better way of doing it backed into dracut anyway.
21:21:20 <Luigi12_work> coling: sure it does.  If you can't resume, you've lost anyway
21:21:39 <coling> Luigi12_work, not if there is some (ultimately non-fatal) problem with e.g. your raid setup.
21:21:41 <Luigi12_work> unless you mean the failure to find the swap is fixable somehow without losing its contents
21:21:47 <Luigi12_work> oic
21:22:26 <Luigi12_work> I guess the failure is less likely with LVM than (sw) RAID
21:22:31 <coling> Then you are left with a system whereby you can fix the problem, and then resume and save your data, but being honest, I'm arguing as the devils advocate here... this is super unlikely!!
21:22:40 * Luigi12_work isn't quite sure why people use sw RAID tbh, sounds like a recipe for disaster
21:22:46 * coling nods
21:22:51 <wilcal> it is
21:22:59 <DavidWHodgins> Luigi12_work: It's for compatibility with windows.
21:23:11 <Luigi12_work> ?  Windows can use a hw RAID just fine
21:23:19 <wilcal> RAID should be invisible to the OS
21:23:24 <Luigi12_work> exactly
21:23:26 * coling has always used software raid TBH.
21:23:38 * ennael put some beers and tea for these guys :)
21:23:39 <coling> Seems to have worked fine for me
21:23:53 <coling> But meh, I don't do anything too complex
21:23:59 <Luigi12_work> coling: but you're smarter than 99.9% of the population
21:24:14 * coling doesn't feel like it with his lack of sleep in the last week!
21:24:21 <tmb> well, software raid (mdadm) is faster than many  hw raid controllers theese days thanks to a lot of CPU power
21:24:25 <Luigi12_work> you're more able to deal with the extra complication and extra risks from the extra layer of indirection
21:24:49 <coling> Anyway, feel free to use the above patch on dracut as that should nuke the file where we write the swap device stuff to the file.
21:25:00 <coling> It should solve the problem.
21:25:11 <Luigi12_work> I'll buy that there are some optimizations that the OS can do if it knows about the underlying RAID, I'm not saying it has no advantages
21:25:23 <Luigi12_work> I do know that if I used it, I'd for sure have regular backups, because I'd be scared to death :D
21:25:25 <Stormi> (and raid controllers are a SPOF, hi :))
21:26:01 <Luigi12_work> coling: thanks
21:26:14 <ennael> so final status?
21:26:20 <DavidWHodgins> ennael: scrolling of details looks ok with boot-nonfree.iso
21:26:21 * ennael is a bit lost :)
21:26:33 <ennael> DavidWHodgins: great thanks !
21:26:40 <ennael> Akien: you can close it then :)
21:26:40 <Luigi12_work> ennael: status is apply colin's patch to dracut, but the installer ideally should be addressed too (but that can be delayed if need be)
21:26:57 <ennael> Luigi12_work: want to handle this?
21:27:08 <Luigi12_work> ennael: sure
21:27:42 <ennael> thanks
21:27:53 <DavidWHodgins> ennael: Spoke too soon. It worked well at first, then stopped scrolling.
21:28:09 * ennael cries
21:28:47 <Akien> DavidWHodgins: It should scroll if you're at the bottom, and not scroll if you're someplace else (so that you can scroll back in history to read what happened)
21:29:33 <DavidWHodgins> It scrolls for a while, then stops. Have to move the slider back to the bottom, to get it to start again, then it stops again, after a few lines.
21:29:50 <Luigi12_work> oh that means it doesn't work at all
21:30:00 <Luigi12_work> well he did say the number in the patch might need some fiddling
21:30:14 <Luigi12_work> so probably better to stick with his original patch for now, unless we can find the gtk+ commit that caused this and revert it
21:30:26 <Luigi12_work> which the discussion did seem to identify the commit, so we could go that route
21:30:35 <Luigi12_work> otherwise we can go with the original patch for now and play with it more after Cauldron reopens
21:30:41 <ennael> so the one included in current isos
21:30:42 <DavidWHodgins> It appears to scroll x+1/2 lines, then stops, with x varying in number. If it scrolls a complete line, it's ok, but when it shows half a line, it then stops.
21:31:19 <ennael> DavidWHodgins: did you test the last iso ?
21:31:32 <ennael> (first version of the patch)
21:32:25 <DavidWHodgins> I'm testing the cauldron/x86_64/install/images/boot-nonfree.iso dated March 20th.
21:32:53 <DavidWHodgins> I didn't test the prior iso
21:33:38 <ennael> if you can have a look that would be great
21:34:05 <DavidWHodgins> Hmm. Not sure where to get the prior iso image.
21:34:33 <tmb> DavidWHodgins, she means the -rc isos on rabbit
21:34:54 <tmb> DavidWHodgins, they have the first revision of the fix
21:34:54 <ennael> yep it uses 16.69 version for stage2
21:35:17 <ennael> if it's better then we will revert more recent patch
21:35:20 <DavidWHodgins> I'll try the x86_64 dvd from rabbit.
21:35:28 <ennael> ok thanks
21:35:54 <ennael> https://bugs.mageia.org/show_bug.cgi?id=13679
21:35:56 <[mbot> [ Bug 13679 Diskdrake shows no partitions for sda (initially) when custom partitioning in 5alpha1 i586 live installer ]
21:36:01 <ennael> also to be tested with last isos
21:36:05 <ennael> it should be fixed
21:37:11 <ennael> https://bugs.mageia.org/show_bug.cgi?id=3910
21:37:13 <[mbot> [ Bug 3910 ACPI Screen blanking works, unblanking does not in DrakX (Dell Inspiron E1405) ]
21:38:39 <DavidWHodgins> So far, the x86_64 dvd iso image is scrolling ok. I'll let it run for a while, and see if it stops.
21:39:14 <tmb> well, the "fix" for  3910 is simple... dont close the lid during install :)
21:39:18 <Luigi12_work> LOL
21:39:29 <DavidWHodgins> ☺
21:39:30 <Luigi12_work> well at the least vbetool *needs* to be fixed
21:39:41 <Luigi12_work> the rest can be dealt with later, as it's workaroundable and has been there for years now
21:40:05 <ennael> can you add this on bug report?
21:40:08 <wilcal> yup
21:40:16 <Luigi12_work> should already be apparent
21:41:08 <tmb> yeah, the vbetool needs more love...
21:41:16 <DavidWHodgins> ennael: Scrolling is fine with x86_64 dvd iso. Canceling the install now, to check the partitions in the i586 live custom partitioning.
21:41:28 <ennael> DavidWHodgins: ok thanks
21:43:48 <DavidWHodgins> Ouch. With kde live x86_64 dvd iso image, the dvd is being ignored , and it's booting from the hard disk (under virtualbox)
21:44:05 <ennael> https://bugs.mageia.org/show_bug.cgi?id=15468
21:44:08 <[mbot> [ Bug 15468 5RC: Gnome Live install "Oops something has gone wrong" ("Gjs-WARNING **: JS ERROR: Error: Argument 'string' (type utf8) may not be null") ]
21:44:28 <ennael> Akien: did you follow that one ?
21:44:53 <Akien> Gnome's legendary fail whale - an attempt at a modern BSOD
21:45:17 <Akien> "we found an issue and we won't give you more info about it"
21:45:28 <ennael> :)
21:45:30 <Akien> I did not follow it closely no
21:46:35 <Luigi12_work> it is a BSOD - Blubbery Screen of Death
21:47:01 <Akien> That's the main (maybe only?) show stopper for the RC though
21:47:29 <Luigi12_work> oh I thought we were doing a real RC
21:48:22 <Akien> I guess we need to deploy the complete task force on this one :)
21:48:40 <ennael> then how do we proceed ?
21:48:48 <Akien> If we can fix it, basically the RC would be ready IMO
21:49:04 <Luigi12_work> why?
21:49:48 <Akien> Luigi12_work: Because we're making good progress overall, we're close to something quite good, but a fail whale on the first boost will be very bad for reviews IMO
21:50:01 <Luigi12_work> and the other blockers are bad too
21:50:09 <Luigi12_work> I don't see why this is more special and the other are less so
21:50:10 <DavidWHodgins> ennael: https://bugs.mageia.org/show_bug.cgi?id=13679 is fixed
21:50:12 <[mbot> [ Bug 13679 Diskdrake shows no partitions for sda (initially) when custom partitioning in 5alpha1 i586 live installer ]
21:50:18 <ennael> great
21:50:49 <Akien> Luigi12_work: Well as you want, I just wanted to outline that I find this one pretty annoying.
21:50:50 <DavidWHodgins> Did find a new problem in that the live kde x86_64 dvd iso will not boot under vb in efi mode.
21:52:12 <Akien> I also confirm the fix for 13679, just booted the boot-nonfree.iso
21:52:22 <Luigi12_work> Akien: others feel the exact same about other bugs
21:52:51 <Luigi12_work> the package set has been good enough for an RC for a month probably, just the installer needed some more fixes IMO
21:53:12 <Akien> Luigi12_work: Yeah... But still we need to prioritize our work
21:53:20 <Luigi12_work> I guess the Live had some issues too, I'm not familiar with those
21:54:00 <Akien> I've started putting non-critical release_blockers to the Mageia 6 tracker because I know we won't be able to fix 30 release blockers just like that
21:54:24 <wilcal> Good strategy Akien
21:54:34 <Akien> And in the ones that are left, there are showstoppers, and there are minor issues that we still really want fixed
21:54:56 <wilcal> By next week we should be down to the real Release Blockers
21:55:01 <lebarhon> what about 15449 and 15472? - EFI problems
21:55:19 <Akien> But if we were to release with the scrollbar broken, honestly I don't think that would be really bad. If we release with a GNOME that fails because it likes too, that's a bit more annoying.
21:55:36 <Luigi12_work> the scrollbar issue gave a really bad impression of the installer
21:55:52 <Luigi12_work> it'd be really bad to have such issues two releases in a row (mga4 installer had a lot of UI issues also due to gtk+3)
21:56:05 <Luigi12_work> most people know by now that GNOME likes to show fail whales
21:56:23 <Luigi12_work> most people don't even use GNOME anyway
21:56:30 <Akien> Ok this is going nowhere :)
21:56:33 <Akien> On to the EFI bugs
21:56:47 <Luigi12_work> we skipped over 13866 earlier
21:57:32 <Luigi12_work> and we mistook 14520 for 15468 when we discussed it earlier
21:57:44 <Luigi12_work> iirc
21:58:05 <Luigi12_work> unless we skipped it too
21:58:44 <Akien> About 13866, there isn't much progress. I proposed to disable the onscreen keyboard as a (bad) workaround, but I don't know how to do it
21:59:00 <Akien> Looked at some gnome packages, I couldn't find how to patch this out
21:59:26 <Luigi12_work> hmm, yeah I think it's the most reasonable workaround, and that can be fixed later if we do that, so it's not that bad
21:59:32 <Luigi12_work> but yeah I'm not familiar with the code either
21:59:32 <Akien> The bug itself could be fixed post-release, but we need to find a workaround for the release
21:59:40 <Luigi12_work> agreed
21:59:58 <Akien> We did skip 14520 indeed
22:00:07 <Luigi12_work> and actually I think we're at the end of the blocker list as far as what still needs to be discussed, other than 14520 which we skipped
22:00:57 <Akien> ennael commented about this one "tmb is on it having some hw to reproduce it (only on old amd/ati hw where we switch from proprietary driver to the free one)"
22:01:10 <Luigi12_work> ooh ok
22:01:23 <Luigi12_work> I guess that's it then
22:01:29 <Akien> (not here, on our bug tracking speadsheet)
22:01:35 <Luigi12_work> ahh ok
22:01:37 <Akien> Did we discuss the EFI issues lebarhon mentioned?
22:01:51 <Luigi12_work> no but they're not on our list either :o)
22:01:57 <DavidWHodgins> tmb: Hate to add a new problem, but the live iso images will not boot under vb in efi mode now.
22:02:12 <DavidWHodgins> It's skipping the dvd, and trying to boot from the hard drive.
22:02:28 <wilcal> I didn't have enough time to test that this morning David. thanks
22:02:30 <DavidWHodgins> The classical iso image I'm trying right now is ok.
22:03:02 <tmb> yeo, I'm currently using an affected system so I should be able to find and fix the ldconfig issue
22:03:05 <Akien> Luigi12_work: True. I'll have a look and see if they should be made blockers
22:03:11 <Akien> tmb: Great :-)
22:03:13 <wilcal> do we expect the new CI's to efi install in VBox
22:03:40 <DavidWHodgins> wilcal: Trying it right now. Install is in progress.
22:04:05 <wilcal> so it got past the initial parition stages?
22:04:26 <DavidWHodgins> wilcal: Yes. Just finished install, at user management now.
22:04:32 <tmb> DavidWHodgins, well, they boot in vbox efi mode here ...
22:04:52 <wilcal> that's really good news. So the CI can EFI install into a blank drive.
22:05:09 <DavidWHodgins> tmb: Is there already a uefi install in the vb guest (that's planned on being replaced)?
22:05:21 <lebarhon> Did you try in dual boot with Win ?
22:05:44 <tmb> I have 2 systems that are dualbooting with windows 8.1
22:06:04 <lebarhon> I can't have it working at home
22:06:14 <lebarhon> only manually
22:07:45 <tmb> DavidWHodgins, works both on a newly created vm and on an old one
22:08:21 <tmb> lebarhon, what kind of hw ?
22:08:42 <lebarhon> Intel Pentium
22:08:56 <tmb> lebarhon, and what works ? efi booting linux or windows ?
22:09:25 <lebarhon> no one, Mageia breaks windows
22:09:47 <lebarhon> Mageia can't create right partitions
22:10:08 <lebarhon> and don't detect the ESP
22:10:14 <tmb> lebarhon, ah, I used manual partitioning
22:10:29 <lebarhon> I agree, manually it works
22:10:47 <lebarhon> but "Use free space on Windows partition" doesn't
22:10:51 <tmb> and ESP detection is still broken as noted in my info when I released round 3
22:11:24 <lebarhon> Once the installer used the main NTFS partition as the ESP
22:12:09 <lebarhon> Resizing Windows partition doesn't work either
22:12:14 <tmb> heh, it thought it was a better use for it :)
22:12:43 <lebarhon> Must we give up the automatic installation ?
22:12:49 <lebarhon> tmb: :)
22:14:19 <tmb> well, enabling efi support has shown that installer has a lot of assumptions regarding mbr, wich is now not true when we have gpt ...
22:16:55 <tmb> And I usually tell people to do resizing in windows, to have windows keep track of its own changes... :)
22:17:29 <lebarhon> Resizing Windows with Gparted works fine
22:18:01 <lebarhon> May be we should prepare the documentation this way ?
22:18:56 <tmb> hm, iirc we are using libgparted to do the resizing so it should behave the same way :/
22:19:22 <lebarhon> well, not
22:20:04 <Akien> Should we end this already-long meeting (and maybe continue the discussion off-meeting)?
22:20:25 <Stormi> you haven't reached midnight yet
22:20:33 * ennael slaps Stormi
22:20:33 <wilcal> Lots of thinking to do on UEFI
22:20:40 <lebarhon> What is the policy about EFI ?
22:21:44 <wilcal> Maybe we have reached the point where we can successfully install EFI to a blank drive
22:22:17 <lebarhon> Anyone buying a computer has Windws 8.1 on it with EFI. If he can’t install Mageia, he goes elsewhere !
22:22:30 <tmb> efi works on blank drive and with manual partitioning, its the automatic bits that need some fixing
22:22:38 <wilcal> tmb will the boot.iso's install efi?
22:22:54 <tmb> wilcal, every x86_64 iso will
22:23:38 <DavidWHodgins> tmb: Is the dual supposed to? (Haven't tried it yet).
22:23:44 <ennael> not for now
22:23:53 <ennael> we could try
22:24:04 <tmb> ah, no. we dont add efi stub on that one yet
22:24:22 * tmb forgot about that one
22:24:35 <ennael> I will try to build one including EFI
22:24:39 <wilcal> And according to David efi now works in Vbox
22:24:59 <wilcal> that would be serious progress on this
22:25:00 <lebarhon> I confirm
22:25:13 <lebarhon> with the same limitations
22:25:21 <wilcal> I propose a fall back position that efi only installs to blank drives
22:25:29 <DavidWHodgins> wilcal: The classical installer iso images are, not the live, under vb, for me.
22:25:43 <tmb> ennael, it wont work with the current DVD-efi tarball... you have different paths on the dual than on the DVD
22:25:55 <wilcal> Drives populated with Win would move to M6
22:26:10 <wilcal> hard choice but gets M5 out the door
22:26:14 <Akien> wilcal: That would phase out 95% of the users
22:26:19 <ennael> tmb: indeed. did forget that...
22:26:43 <wilcal> choices over the next weeks
22:27:07 <tmb> ennael, I can create a new one for the dual, but that will have to wait until tomorrow
22:27:39 <DavidWHodgins> tmb: I don't think we should try adding efi support to the dual, this late.
22:27:40 <ennael> no worry that is not an emergency
22:27:55 <ennael> agree the bug list is long enough
22:28:51 <DavidWHodgins> I keep finding new ones. Just did a kde x86_64 dvd install. On first boot after install, no panel. After reboot, the panel is there.
22:28:58 <tmb> DavidWHodgins, well, it's the same stuff that boots every other efi iso, its just altered search path for the additional "/x86_64/" bit
22:29:19 <ennael> ok can we end meeting for tonight ?
22:29:28 <DavidWHodgins> It just seems that every small change, creates new bugs.
22:29:35 <wilcal> Plenty to work on
22:29:38 <wilcal> good meeting
22:29:44 <DavidWHodgins> Yes, let's end it for now.
22:29:54 <tmb> yeah, lets end it ... I need to sleep
22:29:58 <ennael> thanks for your time tonight
22:30:12 <ennael> thanks for attending and go for testing :)
22:30:16 <ennael> #endmeeting