16:01:39 <kparal> #startmeeting f20beta-blocker-review-6
16:01:39 <zodbot> Meeting started Wed Oct 30 16:01:39 2013 UTC.  The chair is kparal. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:39 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:01:46 <pschindl> kparal: yes, but next week :)
16:01:48 <kparal> #meetingname f20beta-blocker-review-6
16:01:48 <zodbot> The meeting name has been set to 'f20beta-blocker-review-6'
16:01:53 <kparal> #topic Roll Call
16:01:59 * roshi is here
16:02:01 * pschindl is here
16:02:02 <kparal> who's here for the fun?
16:02:11 * tflink is present
16:02:19 * cmurf is here and inadequately caffeinated
16:02:28 * satellit listening
16:03:10 <penguin42> kparal: Me!
16:03:43 <kparal> anyone wants to be a secretary?
16:03:49 <pschindl> And who is here for blocker bug meeting? :)
16:03:59 <roshi> I can
16:04:02 <tflink> pschindl: the difference being?
16:04:03 <kparal> roshi: thanks
16:04:14 <cmurf> i was here for more coffee, guess i'm in the wrong place
16:04:14 <kparal> #chair pschindl roshi tflink
16:04:14 <zodbot> Current chairs: kparal pschindl roshi tflink
16:04:27 * roshi hands cmurf some fresh coffee
16:04:29 <kparal> ok, we have some people, let's go
16:04:33 <kparal> #topic Introduction
16:04:33 <kparal> Why are we here?
16:04:33 <kparal> #info Our purpose in this meeting is to review proposed blocker and nice-to-have bugs and decide whether to accept them, and to monitor the progress of fixing existing accepted blocker and nice-to-have bugs.
16:04:33 <kparal> #info We'll be following the process outlined at:
16:04:33 <kparal> #link https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
16:04:34 <kparal> #info The bugs up for review today are available at:
16:04:36 <kparal> #link http://qa.fedoraproject.org/blockerbugs/current
16:04:38 <kparal> #info The criteria for release blocking bugs can be found at:
16:04:40 <kparal> #link https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria
16:04:42 <kparal> #link https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria
16:04:44 <kparal> #link https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria
16:04:53 <kparal> today we have:
16:04:55 <kparal> #info 2 Proposed Blockers
16:04:55 <kparal> #info 15 Accepted Blockers
16:04:56 <kparal> #info 0 Proposed Freeze Exceptions
16:04:58 <kparal> #info 14 Accepted Freeze Exceptions
16:05:06 <kparal> I like the Proposed part
16:05:12 <kparal> not so much the Accepted part
16:05:24 <kparal> can we start with the proposed blockers?
16:05:32 <tflink> works for me
16:05:38 <roshi> sounds good
16:05:48 * kparal asking anaconda guys to come
16:06:01 <kparal> #topic (1022810) error detecting raid1 thin pool layout
16:06:01 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1022810
16:06:02 <kparal> #info Proposed Blocker, python-blivet, NEW
16:06:23 <tflink> considering how upset they were after the last blocker meeting, probably not a bad idea
16:06:37 <kparal> tflink: can you tell me the details?
16:07:21 <tflink> kparal: not much to say other than what adam summarized
16:07:32 * kparal probably missed that
16:08:14 <roshi> tl:dr is: We voted blocker without some key information
16:08:30 <kparal> ok, I see
16:08:36 <cmurf> so this bug is interesting in that it's not LVM on md raid, but it's LVM (integrated) raid, and thinp on that
16:08:56 <tflink> I didn't know you could do raid in lvm
16:09:00 <cmurf> yes
16:09:04 <cmurf> it's f'n cool
16:09:07 <kparal> cmurf: can you explain what's lvm integrated raid?
16:09:14 <cmurf> each LV can have it's own raid level
16:09:20 <penguin42> it's been there for a long time
16:09:33 <cmurf> it uses the md code, but it has it's own commands, you don't use mdadm
16:09:33 <kparal> I had no idea
16:09:46 * roshi didn't know either
16:10:11 <cmurf> anyway, i agree with the later statements in the bug
16:10:32 <cmurf> i think it's too broad to take all things LVM without some advance game plan
16:11:09 <kparal> dlehman: I understand you don't want to support any possible LVM layout. is it possible to at least ensure anaconda would not crash?
16:11:21 <tflink> yeah, seems a bit obscure for taking as blocker for beta
16:11:24 <roshi> I'm -1 blocker since anaconda isn't tripping over itself or crashing because of something it made
16:11:50 <dlehman> kparal: what should we do if not crash?
16:12:04 <kparal> dlehman: for example you could say "this is not supported layout"
16:12:24 <cmurf> right, crash sounds bad but it's sort of a default, but to have different behavior means coding exception behavior
16:12:38 <kparal> i.e. does the new proposal mean that crashing is OK, or that crashing is blocker but anaconda can reject to install onto some particular layout?
16:12:46 <dlehman> and then what? exit? or try to provide some way to use the rest of the system? what about the rest of the vg? each of these takes more man-hours and generates more bugs than the last.
16:13:28 <kparal> dlehman: actually displaying a proper message with Quit button would definitely be friendlier, yes
16:13:50 <tflink> so a better question is whether it'd be reasonable to do so
16:14:08 <dlehman> that approach is obviously the simplest. then we can have arguments in bugs and on list about why the fascist installer does not support $EVERYTHING
16:14:21 <cmurf> haha
16:14:24 <roshi> lol
16:14:45 * penguin42 can see that I'd expect to be able to install on a precreated LV however that LV was wired, IMHO the problem here is that lvchange -a y  tries to do something dumb
16:14:47 <kparal> comment 18 speaks about having a list of supported lvm configurations. so what happens in the other cases, is crashing considered ok?
16:15:05 <kparal> (for blocker bug evaluation)
16:15:34 <dlehman> that hasn't been decided
16:16:06 <dlehman> a fatal error dialog would certainly be acceptable to me
16:16:42 <kparal> ok. if we want to re-consider this now, we should have an idea whether we want to accept crashes on uncommon configurations. but that decision can probably wait until Beta is released
16:16:44 <tflink> dlehman: so you'd be ok with us taking this as a blocker under the "don't crash" criterion with the understanding that an error message is the expected fix?
16:16:50 <kparal> I guess that would be a Final criterion
16:17:05 <dlehman> but how long til everyone agrees that the the installer should "at least" allow users to install as long as they don't use the a) offending vg or b) the disk containing the offending vg
16:17:34 <dlehman> seriously. I give it max two weeks after beta goes out.
16:18:17 <kparal> I'm not sure I get it
16:18:28 <tflink> that's grey area, I think
16:18:37 <kparal> I would be fine with documenting this particular bug as CommonBugs for Beta
16:18:52 <kparal> and adjust the criterion before Final
16:18:56 <cmurf> this was my argument against crash bugs always being beta blocking
16:18:57 <tflink> but I'm not against setting some more restrictions on the partitioning criteria
16:19:09 <cmurf> when we have a final criteria that says corruption is tacitly OK as long as it's documented
16:19:24 <cmurf> so it's like… the installer can't crash but if we document corruption that's alright
16:19:41 <cmurf> and yet more and more stuff keeps getting piled onto the installer
16:19:44 <tflink> that's a good point
16:19:45 <cmurf> and last minute
16:19:50 <cmurf> like all this thinp stuff
16:20:30 <cmurf> which btw is also bad ass, but it wasn't working at all for rawhide or alpha, or even really after freeze
16:20:37 <roshi> wait, FOSS has scope creep?
16:20:45 <roshi> </sarcasm> :D
16:20:45 <cmurf> 8-)
16:20:48 <cmurf> OK
16:21:19 <cmurf> so anyway i think the come to jesus talk is to be more realistic about the criteria that's really the only way out is to make THEM more complex and carve out an exception
16:22:04 <kparal> so what's your opinion on blockerness?
16:22:08 <cmurf> 01
16:22:09 <tflink> there is the "reasonable-ness" clause in the criteria
16:22:09 <cmurf> -1
16:22:20 <cmurf> and i realize that's inconsistent with the criteria
16:23:00 <cmurf> the critera says no crashing even if the layout is invalid
16:23:01 <tflink> if we don't block over graphics adapters not working when they're not common enough, I don't see why we can't do the same for disk layouts
16:23:11 <kparal> tflink: what's the clause?
16:23:33 <cmurf> i think our best way out is the conditional blocker
16:23:50 <cmurf> even though i don't like that it permits open endedness
16:23:52 <kparal> oh, I see. "There may be times where a requirement is unmet only in a particular configuration..."
16:23:58 <penguin42> What's the installer supposed to do if LVM failed for some reason like no room, or an unavailable disk - because this looks like it should fail the same way
16:24:26 <tflink> penguin42: not sure that's the same thing, though. this is an obscure lvm configuration
16:24:30 <cmurf> tflink: because only the installer gets dinged with no crashing even if the layout is invalid
16:25:18 <penguin42> tflink: Well it is, but IMHO this is actually lvchange misbehaving, so what should happen if lvchange errored for some other reason - should the installer crash or display a dialog telling you it broke?
16:25:24 <cmurf> i'm hearing this bug is a max 2 week fix AFTER beta goes out
16:25:34 <tflink> so that "no crashing" criterion is somehow stronger than the "must boot to gdm" criterion?
16:26:17 <tflink> cmurf: I think that was predicting that there would be complaints about how anaconda should handle things differently within 2 weeks of release
16:26:33 <kparal> proposed #agreed 1022810 - RejectedBlocker - The crash occurs in a very special use case when a special kind of LVM is used. It is not possible to create this LVM layout in anaconda itself, it must be pre-created in advance using other tools. We believe this is not serious enough violation to block Beta.
16:26:42 <dlehman> tflink is correct
16:27:10 <tflink> ack
16:27:15 <cmurf> ack
16:27:30 <dlehman> "fixing" blivet to be able to do a reasonable job of handling stuff it cannot understand and never crashing under such circumstances is a lot longer timeline than 2-4 weeks
16:27:47 <dlehman> not to mention the existing work queue
16:27:55 <tflink> penguin42: I don't know enough about lvchange to say whether it's misbehaving or not in this case, to be honest
16:28:23 <roshi> ack
16:28:31 <kparal> #agreed 1022810 - RejectedBlocker - The crash occurs in a very special use case when a special kind of LVM is used. It is not possible to create this LVM layout in anaconda itself, it must be pre-created in advance using other tools. We believe this is not serious enough violation to block Beta.
16:28:40 <kparal> #topic (1023767) shim update to 0.5 fails to boot
16:28:40 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1023767
16:28:40 <kparal> #info Proposed Blocker, shim, NEW
16:28:49 <penguin42> tflink: I've used it for a while but don't know enough, but for a long time 'lvchange -a y' has been the normal whateveryone expects to start everything up, anyway next bug
16:29:36 <tflink> penguin42: sure, I know what the command is supposed to do, but I have no idea what changes when md-lvm-on-thinp gets involved
16:29:52 <tflink> +1
16:30:01 <kparal> +1
16:30:08 <cmurf> +1
16:30:12 <cmurf> ceremonial blocker
16:30:34 <tflink> it'd be interesting to find out why the test machines weren't failing but most people's machines are
16:30:44 <cmurf> so we realize that there was a sister bug that we accepted as freeze exception and that's how this bug came into existence
16:30:51 <cmurf> sorta
16:31:13 <tflink> yeah, but shim bugs are difficult to test without a TC
16:31:18 <cmurf> they are
16:31:27 <kparal> proposed #agreed 1023767 - AcceptedBlocker - This violates Beta criterion "The installer must run when launched normally from the release-blocking images." for UEFI boot. Either fixing this or reverting to previous build is necessary.
16:31:29 <nirik> odd... 0.5 works fine here with rawhide.
16:31:34 <tflink> not sure we need a blocker since it'll just be pulled back out
16:31:42 <cmurf> my case is 0.5 works on HDD daily
16:31:48 <cmurf> and on a dd'd usb install stick
16:31:51 <kparal> tflink: I also wasn't sure of the correct procedure
16:31:54 <cmurf> but fails with litd install stick
16:32:01 <cmurf> so figure that weirdness out
16:32:28 <tflink> all this brou-ha-ha was over one USB method not working?
16:32:29 <kparal> tflink: I guess I'll remove the blocker flag when the build is pulled out of the new compose
16:32:49 <kparal> ack/nack/patch?
16:33:01 <roshi> +1 (retroactively)
16:33:01 <tflink> kparal: or wait for the next review meeting, which'll be tomorrow :)
16:33:04 <roshi> ack
16:33:08 <tflink> ack
16:33:13 <kparal> ack
16:33:14 <cmurf> tflink i'm uncertain that's always the case
16:33:16 <tflink> well, hold on a sec
16:33:17 <cmurf> ack
16:33:23 * kparal waiting
16:33:24 <cmurf> indeed
16:33:40 <tflink> do we know if this is generally working for everything other than litd?
16:33:47 <cmurf> tflink no
16:33:51 <cmurf> we actually don't know the scope
16:33:55 <cmurf> at least i don't
16:33:56 <pschindl> ack
16:33:59 <kparal> tflink: it's broken with dd for sure
16:34:05 <cmurf> no it's not
16:34:08 <cmurf> it's working for me with dd
16:34:11 <cmurf> not with litd
16:34:19 * nirik suspects it's some hardware not others?
16:34:20 <cmurf> so it looks like we're mixed
16:34:21 <kparal> pschindl: what methods were broken?
16:34:32 <cmurf> it looks like it's firmware specific
16:34:42 <pschindl> I tried it with dd, litd and lc and nothing worked
16:34:51 <cmurf> what's lc
16:34:57 <kparal> liveusb-creator
16:34:58 <pschindl> liveusb-creator
16:34:59 <cmurf> ahh
16:35:00 <tflink> pschindl: on the same asus that's been a UEFI problem?
16:35:11 <kparal> tflink: this time on our new SB machine
16:35:16 <kparal> MSI
16:35:17 <pschindl> tflink: Yes. And on Mac
16:35:17 * nirik hasn't tried tc6, but I could if it would help
16:35:28 <kparal> pschindl: you tried all 3 machines?
16:35:47 <tflink> yeah, I'll do the same. wish i would have when I re-installed last night but I was under the impression it was 100% busted and more testing wasn't needed
16:35:57 <pschindl> kparal: I tried the asus I have near me and we both tried mac
16:36:01 <kparal> I think it's busted enough
16:36:10 <kparal> pschindl: I believe we tried MSI as well
16:36:20 <tflink> yeah, it needs to be fixed, but was wondering if there were other avenues for a fix
16:36:24 <cmurf> Three model year EFI Macs here boot TC6 dd'd to a USB stick, and also boot off their own working install update to shim 0.5. Only litd USB fails with shim 0.5.
16:36:28 <pschindl> kparal: I don't thing so
16:36:33 <pschindl> *think
16:36:36 <kparal> cmurf: we have Mac Mini
16:36:49 <cmurf> kparal: and the mini does not boot the dd'd stick?
16:36:55 <kparal> cmurf: no
16:37:03 <cmurf> kparal: do you know the model?
16:37:04 <kparal> TC5 yes, TC6 no
16:37:09 <kparal> cmurf: not right now
16:37:28 <cmurf> i have model years 2008, 2011, 2012
16:37:48 <cmurf> they are macbooks but the mini is close to a laptop board
16:38:03 <cmurf> in any case, it looks like this is firmware specific
16:38:10 <kparal> do we need further discussion? does somebody change the vote?
16:38:16 <cmurf> yes i'm a -1 blocker
16:38:22 <tflink> nope, no change here
16:38:25 <cmurf> i'm not going to block on something i don't understand
16:38:26 <tflink> re-ack
16:39:02 <roshi> if it's a firmware specific thing then -1
16:39:04 <kparal> cmurf: it affects a lot of UEFI hw, but not all. I think it affects enough hw to block
16:39:15 * roshi was under the same impression as tflink that it was all broke
16:39:30 <tflink> yeah, i think it breaks more hw than it fixes
16:39:31 <kparal> Adam's Asus is broke as well
16:39:37 <kparal> it's not a single hw problem
16:39:53 <cmurf> so the asus case is litd and dd?
16:40:08 <kparal> cmurf: that's a different Asus
16:40:37 <kparal> from what I hear, at least 50% of UEFI hw can't boot
16:40:43 <tflink> but 2 asus boards with different arches (amd vs intel)
16:40:55 <kparal> tflink: correct
16:40:56 <cmurf> boot off internal HDD/SSD?
16:41:05 <kparal> cmurf: all USB
16:41:06 <cmurf> after getting shim 0.5 from updates-testing?
16:41:14 <cmurf> oops nevermind, it never made it to ut
16:41:19 <kparal> cmurf: I'm talking about TC6 the whole time
16:41:42 <cmurf> and that's dd as well as litd?
16:41:50 <kparal> in our cases, yes
16:42:01 <cmurf> ok well then i'm back to +1
16:42:18 <cmurf> with ack
16:42:19 <roshi> I'm booting UEFI with shim 0.5-1 and having no issues
16:42:30 <tflink> i feel like we're going around in circles
16:42:34 <cmurf> roshi: so am i, but not litd
16:42:49 <roshi> so this affects a bunch of h/w then?
16:42:54 <cmurf> appears to
16:42:58 <roshi> tflink ++
16:43:03 <kparal> roshi: please try TC6 on USB instead
16:43:13 <tflink> needs more testing but current state is not acceptable and therefore +1 blocker
16:43:18 <roshi> I'm +1 if it affects a lot of h/w
16:43:22 <roshi> so, +1
16:43:23 <roshi> and ack
16:43:37 <roshi> kparal: I'll give it a try
16:43:40 <kparal> ok, I see all acks
16:43:55 <roshi> all acks after we understood it?
16:43:58 <roshi> lol
16:44:12 <kparal> proposed #agreed 1023767 - AcceptedBlocker - This violates Beta criterion "The installer must run when launched normally from the release-blocking images." for UEFI boot for a lot of different hardware. Either fixing this or reverting to previous build is necessary.
16:44:19 <kparal> I rephrased it a bit
16:44:41 <tflink> ack
16:44:44 <cmurf> ack
16:44:50 <roshi> ack
16:44:51 <kparal> #agreed 1023767 - AcceptedBlocker - This violates Beta criterion "The installer must run when launched normally from the release-blocking images." for UEFI boot for a lot of different hardware. Either fixing this or reverting to previous build is necessary.
16:45:11 <kparal> ok, that's all of proposed bugs!
16:45:22 <kparal> #topic Accepted Blockers
16:45:25 <kparal> onto Accepted Blockers?
16:45:39 <tflink> yep, no proposed FE
16:45:50 <kparal> #topic (1012504) FSError: filesystem already exists
16:45:50 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1012504
16:45:51 <kparal> #info Accepted Blocker, anaconda, MODIFIED
16:46:36 <kparal> should we move this to verified?
16:46:45 <cmurf> yes
16:47:01 * kparal adjusted that
16:47:07 <kparal> #info this is verified
16:47:15 * kparal moving on
16:47:28 <kparal> #topic (1021890) Removing thin LV results in exception
16:47:28 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1021890
16:47:28 <kparal> #info Accepted Blocker, anaconda, MODIFIED
16:47:46 <roshi> 1023767 violates alpha criterion, for the record
16:47:50 <roshi> not beta
16:48:08 <kparal> roshi: thanks, please adjust
16:48:08 <cmurf> it does?
16:48:24 <roshi> I am :)
16:48:25 <cmurf> oh yes
16:48:26 <roshi> https://fedoraproject.org/wiki/Fedora_20_Alpha_Release_Criteria#Installer_must_run
16:48:30 <cmurf> nvm
16:48:42 <kparal> this should also go to verified
16:48:46 <cmurf> yes
16:48:50 <kparal> two people confirmed
16:48:55 <kparal> #info this is verified
16:48:59 * kparal moving on
16:49:23 * kparal skipping verified bugs
16:49:29 <kparal> #topic (1008633) ValueError: invalid target size request
16:49:29 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1008633
16:49:29 <kparal> #info Accepted Blocker, anaconda, MODIFIED
16:50:37 <cmurf> i just did windows NTFS resizing in guided and custom paths for the TC6 matrix and it worked
16:50:41 <kparal> #info this needs testing, can be tested with Live by updating anaconda from koji
16:50:44 <cmurf> i also did an ext4 resize
16:50:57 <cmurf> so this is working with 20.25.4-1
16:51:10 <kparal> cmurf: please comment into bugzilla, thanks. could you also try the reproducer from comment 12?
16:51:52 <cmurf> yes
16:51:55 <kparal> thanks
16:52:08 * kparal moving on
16:52:13 <cmurf> if it works should i set it to verified?
16:52:19 <kparal> cmurf: please do
16:52:24 <cmurf> ok
16:52:30 <kparal> #topic (1022206) ValueError: new btrfs subvols require a parent volume
16:52:30 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1022206
16:52:30 <kparal> #info Accepted Blocker, anaconda, ON_QA
16:53:09 <kparal> #info this needs testing, can be tested with Live by updating anaconda from koji
16:53:22 <cmurf> or just use TC6
16:53:34 <kparal> is anaconda-20.25.4-1.fc20 on TC6?
16:53:39 <cmurf> yes
16:53:42 <kparal> ah, ok
16:53:52 <kparal> #undo
16:53:52 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x36d0d650>
16:54:02 <kparal> #info this needs testing, can be tested with Beta TC6
16:54:23 * kparal moving on
16:54:35 <kparal> #topic (1021258) requires user manually create biosboot when using guided partitioning
16:54:35 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1021258
16:54:35 <kparal> #info Accepted Blocker, anaconda, MODIFIED
16:55:04 <cmurf> can be set to verified i think
16:55:17 <kparal> cmurf: thanks for testing
16:55:21 <kparal> #info this is verified
16:55:35 * kparal moving on
16:55:44 <kparal> #topic (1021507) DeviceCreateError: ("Can't have overlapping partitions.", 'sda3')
16:55:45 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1021507
16:55:45 <kparal> #info Accepted Blocker, anaconda, NEW
16:56:06 <cmurf> this is confusing because libreport sent me to this bug, and then we considered it the blocker
16:56:23 <cmurf> but then dlehman clarified my bug is different
16:56:48 <cmurf> i think we voted on the basis of it being the bug as i described it, and i haven't been able to reproduce the originally reported bug
16:57:13 <dlehman> right. libreport apparently only uses the backtrace and the exception class -- not the exception message/string
16:58:07 <kparal> dlehman: do we know how to trigger the original bug report and it's cause?
16:58:46 <tflink> or if our original understanding of the bug was correct?
16:59:00 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=1021507#c22
17:00:04 <cmurf> propose transfering blocker from 1021507 to 1024076
17:00:16 <cmurf> 1024076 appears to be fixed
17:01:12 <kparal> from what I read, I also get the idea that the blocker should be moved to 1024076
17:01:21 <dlehman> agreed
17:01:23 <cmurf> yes
17:01:40 <cmurf> but then from the fix in 1024076 i get 1024144 which i did not propose as a blocker
17:01:45 <cmurf> i don't know if i should have
17:02:32 <dlehman> tflink: yes, as is indicated by the title of the newly-separated bug, the problem is that checking for new lv name uniqueness is broken for thin lvs
17:02:39 <kparal> #info Beta Blocker will be moved to 1024076. there were two issues reported at once.
17:02:57 <tflink> dlehman: yeah, i hadn't seen the new bug yet. thanks
17:03:09 <kparal> roshi: will you handle the move?
17:03:21 * roshi was just going to ask
17:03:25 <cmurf> dlehman by broken, is it broken in lvm or in blivet?
17:03:51 <roshi> so, remove the blocker from 1021507, annotate it, and then mark 1024076 as a blocker?
17:03:52 <kparal> #info 1024076 seems to be fixed, but it created bug 1024144
17:04:06 <kparal> roshi: yes
17:04:06 <tflink> roshi: yeah
17:04:18 <cmurf> 1024144 has the same error but different has as 1013586 which is a final blocker
17:04:19 <dlehman> cmurf: blivet
17:04:23 <roshi> ok, just making sure I know what's going on :)
17:04:32 <cmurf> has=(abrt) hash
17:04:55 <cmurf> so it's possible 1024144 is a final blocker candidate
17:05:47 <kparal> cmurf: does 1024144 happen every time?
17:05:51 <kparal> with thinp
17:06:40 <cmurf> yes
17:06:42 <cmurf> well twice anyway
17:07:01 <kparal> we should probably discuss 1024144 for blocker-ness
17:07:24 <cmurf> how about i propose it
17:07:29 <cmurf> and then test it
17:07:49 <cmurf> we discuss final blockers after beta ships right?
17:07:59 <cmurf> or after beta go rather
17:08:22 <kparal> well, does anyone think 1024144 should be Beta blocker?
17:08:41 <kparal> #topic (1024144)  SizeNotPositiveError: spec= param must be >=0
17:08:46 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1024144
17:09:17 <kparal> from what I understand, this happens always if I want to re-use existing thinp layout?
17:09:48 <tflink> that's what it sounds like to me
17:09:49 <cmurf> well that's sort of it, it might be size related
17:09:54 <kparal> (with fix for 1024076 included)
17:10:18 <cmurf> i'm spacing out at the moment if i'm asking for more space in the thinpool or not
17:10:32 <cmurf> what's confusing about thinp is that the UI doesn't show how much space I have left
17:10:38 <cmurf> it says essentially no space
17:10:53 <cmurf> I delete one virtualsize LV and i still see no space
17:11:19 <kparal> hmm, maybe thinp could have been an experimental feature for F20? ah, well
17:11:28 <kparal> I'm not here to decide that
17:11:31 <cmurf> so the confusing thing about thinp LV is there's a new thing called a pool but it manifests as a variant of an LV
17:11:37 <kparal> dlehman: any thoughts about 1024076?
17:11:48 <cmurf> so you create virtualsize LVs from thinpool LVs which come from VGs.
17:12:11 <kparal> cmurf: more layers of abstraction is always good
17:12:20 <kparal> thanks for intro
17:12:55 <cmurf> kparal: altthough we seem to be running out of terms to refer to the abstractions :-/ and the UI isn't really ready for this
17:13:57 * dlehman looks
17:14:32 <cmurf> 1024076 is fixed with the updates.img
17:15:06 <cmurf> but transient bug 1024144 sometimes occurs - uncertain if updates.img is related to it though
17:15:29 <kparal> cmurf: we would leave 1024076 in modified/on_qa until it's available in a new compose, then verify again
17:15:34 <cmurf> fine
17:15:54 <cmurf> i prefer to test things with updates.imgs once the fix is integrated anyway
17:16:16 <dlehman> cmurf: so you played with a pool outside the installer. did you set it to overcommit the backing storage?
17:16:27 <cmurf> i did not play withthe pool outside the installer
17:16:34 <cmurf> no
17:16:35 <dlehman> hmm
17:17:41 <cmurf> ok i need to retest this
17:17:54 <cmurf> either i deleted home or root, in which case the pool has at least 25G free space
17:18:06 <cmurf> or i did not delete anything, created a new root which overcommitted the pool
17:18:35 <cmurf> so i need to at least some up with better reproduce steps for this
17:18:44 <kparal> ok, can we leave 1024144 undecided for the moment, and cmurf will propose it for a blocker if he checks that this happens in common situations (no external manipulation with pools)?
17:18:49 <cmurf> yes
17:19:07 <kparal> #info we will leave 1024144 undecided for the moment, and cmurf will propose it for a blocker if he checks that this happens in common situations (no external manipulation with pools)
17:19:32 <tflink> I'm not sure that overcommit on thinp is release blocking for beta, though
17:19:47 <tflink> if it ends up being the cause of the bug
17:19:54 <cmurf> right
17:20:08 <tflink> but we can cross that bridge if/when we get there
17:20:16 <cmurf> but also the UI doesn't show the pool size
17:20:18 <kparal> right, if that happens, please propose for Beta or Final and we will discuss
17:20:37 <kparal> cmurf: that's probably best to have a separate issue
17:20:45 <cmurf> yes
17:20:57 * kparal moving on if no one objects
17:21:14 <cmurf> noobjection
17:21:22 <kparal> #topic (1010495) Apple Mac EFI: you have not created a bootloader stage1 target device
17:21:22 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1010495
17:21:22 <kparal> #info Accepted Blocker, anaconda, POST
17:21:36 <cmurf> i need to test based on bcl's last comment
17:22:01 <cmurf> if updating to blivet 23.2-1 i'll set verified
17:22:07 <bcl> this will be in the next builds tonight.
17:22:32 <bcl> (note that the updates.img includes everything you need)
17:23:04 <tflink> cmurf: it'd be best to wait for the new anaconda build
17:23:07 <kparal> #info this can be tested with updates.img or with the next compose
17:23:09 <cmurf> got it
17:23:24 * kparal moving on
17:23:25 <cmurf> it does work, i just wasn't ready to commit with begin installation on baremetal
17:23:42 <kparal> #topic (1016959) ValueError: Cannot remove non-leaf device 'btrfs.14'
17:23:42 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1016959
17:23:42 <kparal> #info Accepted Blocker, anaconda, ASSIGNED
17:23:49 <cmurf> oh god
17:24:47 <cmurf> ok we can argue this is a corner case
17:25:22 <cmurf> give me a moment to summarize this
17:26:40 <cmurf> basically with btrfs with an fstab that does not use subvol= or subvolid= the installer crashes
17:26:42 <kparal> do we want to re-evaluate this issue to be a corner case that's hardly fully fixable in the remaining time before Beta?
17:26:54 <cmurf> basically yes
17:27:21 <kparal> cmurf: is that the default state after default btrfs install?
17:27:27 <cmurf> no
17:27:27 <kparal> (referring to fstab)
17:27:46 <cmurf> anaconda creates subvolumes for any user created mountpoint and creates an fstab with subvol= option
17:28:10 <kparal> so you need to manually edit fstab before running another install, right? to trigger this
17:28:16 <cmurf> correct
17:28:42 <cmurf> an fstab with btrfs volume without mount options
17:29:06 <kparal> do you think this is a Final blocker, or even too corner-casy for Final?
17:29:25 <cmurf> i don't know i think the btrfs stuff needs a conversation as i mentioned last week
17:29:55 <kparal> ok. other thoughts?
17:29:57 <tflink> that does sound a bit corner-casey for beta
17:30:04 * kparal agrees
17:30:09 <tflink> commonbugs, but not blocker
17:30:20 <cmurf> yes
17:30:41 <cmurf> so lift the betablock, commonbugs it - i'll write up a common bugs proposal explanation
17:31:16 <cmurf> and i'll repropose for finalblock if for no other reason than to motivate our btrfs come to jesus talk
17:32:08 <kparal> proposed #agreed 1016959 - RejectedBlocker - After receiving more details about this bug, we consider this to be a corner case situation that should not block Beta. We will document this in CommonBugs. Please repropose for Final if you think it should block it.
17:32:22 <cmurf> ack
17:32:25 <tflink> ack
17:32:31 <roshi> ack
17:32:32 <kparal> ack
17:32:37 <kparal> #agreed 1016959 - RejectedBlocker - After receiving more details about this bug, we consider this to be a corner case situation that should not block Beta. We will document this in CommonBugs. Please repropose for Final if you think it should block it.
17:32:41 * kparal moving on
17:32:49 <kparal> #topic (1000891) DVD is oversized (larger than 4.7 GB)
17:32:49 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1000891
17:32:49 <kparal> #info Accepted Blocker, distribution, MODIFIED
17:33:23 <cmurf> doh
17:33:28 <tflink> I asked dgilmore about this the other day
17:34:12 <tflink> he's still trying to get ahold of the pungi patch which should fix the issue
17:34:46 <cmurf> 200MB over
17:34:48 <kparal> #info this is waiting for releng to patch pungi and use it for new compose
17:34:49 <cmurf> ~
17:35:08 * kparal moving on
17:35:16 <kparal> #topic (1023250) home LV missing from /dev/mapper after install to BIOS RAID set
17:35:16 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1023250
17:35:16 <kparal> #info Accepted Blocker, lvm2, MODIFIED
17:36:12 <kparal> #info this was tested today, found another bug, fixed again
17:36:55 <kparal> #info this needs to be tested again
17:37:07 <kparal> I'll ask mkrizek tomorrow
17:37:12 * kparal moving on
17:37:25 <kparal> #topic (1023556) Blivet.copy does not update parted disk refs for partitions on hidden disks
17:37:25 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1023556
17:37:25 <kparal> #info Accepted Blocker, python-blivet, ASSIGNED
17:38:23 <cmurf> dlehman status of 1023556?
17:41:21 <bcl> it will be in the next build
17:41:47 <kparal> great, thanks
17:41:53 <kparal> #the fix should be in the next build
17:41:56 <kparal> #undo
17:41:56 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x2901f5d0>
17:42:06 <kparal> #the fix should be in the next blivet build
17:42:25 * kparal moving on
17:42:32 <kparal> #topic (1023657) repoclosure failure on 20 Beta TC6 DVDs (sugar-write)
17:42:32 <kparal> #link https://bugzilla.redhat.com/show_bug.cgi?id=1023657
17:42:32 <kparal> #info Accepted Blocker, sugar-write, ON_QA
17:43:28 <kparal> #info this should be fixed in the next compose
17:43:42 <kparal> and that's all!
17:43:57 <kparal> #topic Open Floor
17:44:00 <tflink> sweet!
17:44:02 <kparal> anything else we need to cover?
17:44:25 <tflink> kparal: did you guys have sb enabled when you were hitting problems with tc6/shim-0.5?
17:44:25 <kparal> do you want to go through some of the Accepted Freeze Exceptions?
17:44:34 <kparal> tflink: no, SB was disabled
17:44:51 <cmurf> and macs don't have SB
17:44:59 <kparal> we can try with SB on
17:45:01 <tflink> I wonder if that's the problem here - I just got it to boot as litd and dd on a sb-enabled system
17:45:18 * tflink will try with his desktop after the meeting - it doesn't have sb enabled
17:45:34 <cmurf> sounds good
17:45:37 <kparal> #action pschindl to try TC6 boot on SecureBoot enabled machine
17:45:45 * cmurf is hungry and needs coffee
17:45:48 <kparal> pschindl: sorry ;)
17:46:17 <tflink> I suppose I could just disable sb on my thinkpad, too
17:46:20 <tflink> that'd be faster
17:46:23 <cmurf> yes
17:46:24 <cmurf> try it
17:46:29 <cmurf> i want to know
17:46:33 <cmurf> i'm on pins and needles
17:46:55 <cmurf> tell me on qa
17:46:58 <cmurf> are we done?
17:47:09 <roshi> that's hunger and no caffiene cmurf
17:47:29 <tflink> nope, it boots fine without sb
17:47:29 * cmurf is about to pass out
17:47:39 <cmurf> great
17:47:50 <cmurf> so it's really firmwary specific
17:47:59 <tflink> sounds like
17:48:07 <cmurf> that's icky
17:48:19 <kparal> I guess we will need to create a list of firmware+boot method results
17:48:31 <kparal> unless mjg already knows what is broken
17:48:46 <cmurf> yes he knows more than he lets on haha
17:49:29 <kparal> the fuse it shrinking...
17:49:32 <cmurf> fini?
17:49:32 <kparal> *is
17:49:45 <kparal> thanks everyone for coming
17:49:49 <kparal> #endmeeting