16:05:38 <roshi> #startmeeting F21-blocker-review
16:05:38 <zodbot> Meeting started Wed Oct 29 16:05:38 2014 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:38 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:05:38 <roshi> #meetingname F21-blocker-review
16:05:38 <zodbot> The meeting name has been set to 'f21-blocker-review'
16:05:38 <roshi> #topic Roll Call
16:05:47 * kparal is here
16:05:47 <roshi> who's around for a quick blocker meeting?
16:06:13 * pwhalen is here
16:06:21 * pschindl is here
16:06:29 * tflink is lurking
16:06:35 * satellit listening
16:06:44 <roshi> chair kparal pwhalen pschindl tflink satellit adamw danofsatx
16:06:55 <kparal> missing #
16:06:59 <roshi> #chair kparal pwhalen pschindl tflink satellit adamw danofsatx
16:06:59 <zodbot> Current chairs: adamw danofsatx kparal pschindl pwhalen roshi satellit tflink
16:07:00 <danofsatx> present and accounted for
16:07:03 <roshi> aha!
16:07:05 <adamw> ahoyhoy
16:07:37 <roshi> #topic (1135024) can't press Begin Installation button because of low screen resolution 1024 x 600
16:07:39 * randomuser hides behind tflink
16:07:40 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1135024
16:07:43 <roshi> #info Proposed Blocker, anaconda, POST
16:07:46 <danofsatx> +1
16:07:46 <roshi> this is the one blocker we have to go over
16:08:01 <roshi> it's doesn't actually violate the criteria though
16:08:10 <roshi> the installation *can* complete
16:08:27 * roshi speaks from personal experience - not data in the bug
16:08:31 <danofsatx> but the *user* - especially a noob - can't complete the installation.
16:09:06 <adamw> -1. prior to this point installer team has always said lower resolutions aren't supported and objecting to us blocking on this kind of thing
16:09:21 <adamw> danofsatx: yes, you can, it's only really bad on custom part. which a noob shouldn't be hitting most of the time.
16:09:23 <roshi> yeah
16:09:31 <roshi> -1 from me as well
16:09:35 * randomuser is -1 fwiw, this is a known and documented shortcoming
16:09:42 <danofsatx> I hit it after visiting software selection spoke.
16:09:53 <roshi> also, text, vnc works
16:10:05 <adamw> if they want to change that, fine, but a couple of days after we already slipped beta and just in time to produce another slip isn't really the time, and it's as much a feature addition as a bugfix since it was previously expressly unsupported
16:10:19 <adamw> danofsatx: hum, thought i checked that one. at what res?
16:10:49 <danofsatx> default Vmware vSphere 5.5u2 resolution of 640x480.
16:10:50 <kparal> I saw the same problem with vnc and custom part. but since you can easily resize it, it's not a big deal
16:10:56 <roshi> really low resolution has a variety of quirks
16:11:02 <kparal> -1
16:11:09 <danofsatx> might be 800x600, I can't tell.
16:11:09 <pschindl> -1 from me too
16:11:19 <satellit> is there a workarround?  -1
16:11:26 <pwhalen> -1, document
16:11:33 <roshi> use text based install
16:11:36 <kparal> or vnc
16:11:44 <pschindl> You can get this low resolution with nomodeset too.
16:11:55 <kparal> that's actually a good remark
16:11:57 <kparal> ^^
16:11:59 <adamw> satellit: vnc, text install, get a bigger monitor...:P for hidpi systems you could force hidpi mode off, i guess. it'd be useful to know if this affects non-live cases
16:12:05 <adamw> i'm suspecting it may now
16:12:08 <adamw> may not*
16:12:15 <adamw> pschindl: nomodeset should usually give 1024x768, i think
16:12:24 <danofsatx> https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_Graphical
16:12:25 <kparal> adamw: we have one machine which doesn't
16:12:35 <kparal> for some reason
16:12:46 <kparal> but at least 2 other machines do
16:13:42 <adamw> danofsatx: sure. this is a conditional violation of that criterion, the condition being you have a really low-res screen (or an awkward hidpi screen or nomodeset and a crappy video BIOS, whatever)
16:13:54 <roshi> proposed #agreed - 1135024 - RejectedBlocker - Low resolution is a known and documented shortcoming which we have no blocked on in the past.
16:14:02 <adamw> we've always previously considered that condition not sufficiently severe to make the bug a blocker, and now doesn't seem the time to change that.
16:14:04 <roshi> proposed #agreed - 1135024 - RejectedBlocker - Low resolution is a known and documented shortcoming which we have not blocked on in the past.
16:14:08 <adamw> ack
16:14:09 <kparal> roshi: *not
16:14:12 <kparal> ack
16:14:19 <roshi> I changed it in the second one :)
16:14:24 <kparal> now I see it :)
16:14:31 <pschindl> ack
16:14:37 <satellit> ack
16:14:43 <roshi> #agreed - 1135024 - RejectedBlocker - Low resolution is a known and documented shortcoming which we have not blocked on in the past.
16:15:07 <kparal> I'd like to point out 1099299
16:15:11 <roshi> that's it for proposed blockers
16:15:15 <kparal> which was reopened by pschindl and lbrabec
16:15:32 <roshi> #topic (1099299) fedup fails to upgrade F20 to F21 or later - infinite loop when starting udev
16:15:34 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1099299
16:15:37 <roshi> #info Accepted Blocker, systemd, ASSIGNED
16:15:54 <kparal> it's possible that the fix from RC1 didn't make it into RC2
16:16:19 <kparal> but both saw the problem
16:16:25 <kparal> lbrabec even on his own production machine
16:16:48 <pschindl> I tried it twice in virtual machine
16:17:02 <kparal> pschindl: I just realized we could have tried with RC1 upgrade.img
16:17:51 <pschindl> kparal: I didn't know about this bug. I should look for it.
16:18:02 <kparal> I have a copy of pschindl's VM, so I can try it, but I don't know how long it will take to download all the packages
16:18:34 <adamw> um
16:18:38 <adamw> the comment seems to be lacking in specifics
16:18:48 <adamw> did lukas use the RC2 --instrepo ?
16:18:57 <adamw> using development/21 is likely not sufficient
16:19:04 <nirik> see last comment just added.
16:19:12 <nirik> looks like the f20 systemd needs an update.
16:19:28 <adamw> well
16:19:32 <adamw> we had that go-round earlier in the bug
16:20:11 * nirik is just noting that a systemd maintainer added a comment to that effect. They could be mistaken. ;)
16:20:18 <kparal> adamw: he used --instrepo with dl.fp.o and RC2 dir
16:20:21 <adamw> yes, they could. it happens...
16:20:24 <adamw> kparal: ok, thanks
16:20:25 <kparal> it should be in the fedup.log
16:20:31 <adamw> nirik: i was thinking of the stuff around https://bugzilla.redhat.com/show_bug.cgi?id=1099299#c32
16:20:43 <nirik> he's in #fedora-devel, want me to invite him here?
16:21:44 <kparal> how come it worked for me with RC1?
16:21:47 <adamw> sure.
16:21:56 <adamw> yeah, worked for me too
16:22:08 <adamw> the 'failed to switch root' in the logs seems significant
16:23:18 <adamw> anyhow, i guess this is a blocker if it needs fixing in the f21 images :/ if not it can be a 'special blocker'
16:24:27 <roshi> well, it's already accepted, so no need to vote on it
16:26:06 <kparal> I'll try to reproduce with RC2 first, then RC1 upgrade.img
16:27:06 <adamw> it seems like there was an encrypted volume in this one, from the log
16:27:07 <adamw> s
16:28:06 <pschindl> I tried it without encrypted volumes. I had default f20 installation, fully updated with newest fedup.
16:28:07 <kparal> pschindl's one was not encrypted, right peter?
16:28:21 <kparal> newest from f20 updates, that is
16:28:43 <adamw> hm
16:28:43 <adamw> it'
16:28:56 <pschindl> yes. Newest from f20 repositories (without updates-testing probably).
16:28:57 <adamw> it's possible we got hit by the unfortunate overlap between stable push/mash and compose
16:29:07 <adamw> i wish i could see the fedup-dracut version clearly from that photo
16:29:29 <adamw> fedup-dracut was pushed stable yesterday, I think. yesterday's stable push may not have made the compose, but the packages that were pushed stable seem to have been cleared out of bleed
16:29:41 <adamw> let me see if i can trace it indirectly
16:29:45 <kparal> adamw: fedup-dracut fc20 or fc21?
16:29:52 <adamw> kparal: f21.
16:29:57 <adamw> wwoods: hi, thanks for stopping in
16:30:08 <kparal> shouldn't that be included in that upgrade.img?
16:30:15 <adamw> wwoods: people seem to be hitting https://bugzilla.redhat.com/show_bug.cgi?id=1099299 again in RC2 - but note i've just come up with a theory it got the old fedup-dracut and i'm checking on that
16:30:24 <adamw> kparal: see my theory above.
16:30:37 <kparal> ah, got it
16:30:40 <wwoods> yeah, depends on what you're using for --instrepo
16:30:46 <adamw> btw, if someone could be testing RC1 and RC2 at present it'd help
16:30:47 <wwoods> and what packages were in that compose
16:31:02 <adamw> wwoods: i suspect it may have missed the packages that got pushed stable yesterday :/ i'
16:31:06 <adamw> i'm looking into that atm
16:31:50 <wwoods> also, fedup log is pretty useless for the actual upgrade process. need upgrade.log and/or journal info
16:32:02 <wwoods> except there's some goofy bugs about logging so that's not going well ATM
16:32:05 <adamw> yeah, i think i like my theory.
16:32:05 <kparal> wwoods: yeah, but because of the bug, we couldn't gather it
16:32:11 <adamw> check the Beta RC2 tree:
16:32:13 <adamw> https://dl.fedoraproject.org/pub/alt/stage/21_Beta_RC2/Server/x86_64/os/Packages/s/
16:32:14 <adamw> note:
16:32:19 <adamw> systemd-215-19.fc21.x86_64.rpm
16:32:24 * jreznik is here, sorry for being late - as every Wed, stuffed with meetings
16:32:34 <adamw> we pulled 216-5 into RC1, and it was in yesterday's stable push
16:32:54 <wwoods> I'm putting together a fedup-0.9.0-rc1 build for Beta which should fix some of that
16:32:56 <adamw> i should've remembered to explicitly note on the compose request to check that recent stable pushes got included :( i usually do, but missed it for RC2
16:33:17 <adamw> so i'm gonna say we've probably got a bad compose with RC2, we need to re-do it
16:33:26 <kparal> and re-test it, nooooo
16:33:36 <wwoods> hilarious. so, yes, if you don't include the bugfix, the bug will not be fixed
16:34:01 <roshi> well, then I say we file the request now
16:34:25 <adamw> roshi: i'm just double-checking the theory, but i'm pretty sure i'm right.
16:34:33 <adamw> wwoods: yeah, nothing for you here, sorry. thanks for dropping in
16:34:48 <roshi> it makes sense
16:35:33 * nirik nods. seems right.
16:35:42 <wwoods> adamw: np - also you might consider using fedup git to run yr upgrade, should fix logging so everything goes to the on-disk journal
16:36:07 <wwoods> actually I guess you might already be doing that 'cuz 0.8.x doesn't have --product?
16:36:10 <adamw> wwoods: thanks for the tip, i keep meaning to do a build of the current git and check it fixes the other bugs but ENOTIME :/
16:36:25 <adamw> not me, at least, don't know about the others
16:36:38 <adamw> i just did my test with 0.8 to check the fedup-dracut fix, because we have a bit more time for the others
16:36:40 <kparal> wwoods: we need to check the same version that's going be available on Beta release day. are you planning to do a new fedup update today?
16:36:44 <nirik> so, what else besides this bug would be affected? can we reuse results from most of the rest?
16:36:48 <wwoods> kparal: yes
16:36:51 <kparal> ok, great
16:37:28 <roshi> I don't see why we couldn't use current results
16:37:34 <wwoods> should fix https://bugzilla.redhat.com/show_bug.cgi?id=1038413 and https://bugzilla.redhat.com/show_bug.cgi?id=1153816 (and possibly others)
16:38:28 <kparal> it depends, if systemd changes, some of the results might be invalid. most of them, actually
16:38:51 <kparal> but there's just a slim chance, nothing could go wrong, right?
16:39:02 <roshi> chase that thought :)
16:39:05 <jreznik> sure, nothing
16:39:40 <adamw> nirik: quite a lot else is affected unfortunately
16:39:55 <roshi> well, can't say I didn't try :p
16:40:03 <adamw> livecd-tools, fedup-dracut, selinux-policy, and systemd
16:40:07 <kparal> I think at least some of the anaconda test cases we can transfer, like kickstarts, partitioning and stuff. unless some of their libraries changed as well
16:40:23 <nirik> yeah. ;(
16:40:27 <adamw> still, those were all in RC1. i'd say the combination of RC1 and RC2 results are *fairly* transferable to RC2.1/RC3 so long as we test as much as we can and verify the fixes for all blockers
16:40:49 <adamw> kparal: anaconda was actually in the packages pushed stable yesterday, but fortunately we listed an even newer build for RC2 so it's OK.
16:41:03 <kparal> great
16:41:38 * satellit_e 21.48.13-1 on lives here
16:44:22 <kparal> I can confirm this bug with RC2 instrepo and pschindl's VM
16:44:29 <nirik> so, rc3 request in asap, test away. ;)
16:44:33 <kparal> now trying with RC1
16:44:51 <danofsatx> dammit, I just finished Server RC2 testing....
16:45:23 <kparal> RC1 instrepo works great
16:45:34 <kparal> so maybe we don't even need systemd update in F20
16:46:05 <adamw> kparal: yeah, it's just because RC2 got the old systemd.
16:46:06 <kparal> someone might tell Zbigniew, if you know his nick
16:46:11 <adamw> i'll update things
16:46:18 <kparal> ok
16:46:36 <adamw> so it looks like the only affected packages are systemd, initscripts and dracut. selinux-policy got a newer build in RC2, like anaconda, so it's effectively uneffected :)
16:47:05 <adamw> obviously systemd being affected means the impact is quite big, but at least RC1 had the newer version, so we *have* tested it.
16:47:12 <adamw> danofsatx: sorry :(
16:50:34 <roshi> so what's the best course of action from this point?
16:50:57 <roshi> pause testing until the new compose? only test certain things?
16:53:13 <kparal> I think it's quite safe to test kickstarts and stuff
16:53:38 <kparal> even desktop in general
16:53:42 <adamw> it can't *hurt* to do tests, but we're gonna want to do as much rc3 testing as we can manage
16:53:50 <kparal> even though some of the functions like user handling is tied to systemd
16:54:01 <tflink> as a side note, we have no AMIs for beta RC2
16:54:05 * satellit_e lives?
16:54:06 <adamw> so if it'd help anyone to take a nap or whatever, go do it :) and we don't need czech people wasting their evenings testing rc2 i don't think
16:54:16 <adamw> satellit: the lives have old systemd too.
16:54:22 <satellit_e> k
16:54:41 <adamw> i'm gonna send a note to the lists explaining the siutation
16:54:47 <roshi> sounds like a plan
16:55:23 <adamw> see, this kind of thing is why i always want the post-slip compose done *on Monday* not *Tuesday night* :(
16:55:35 <roshi> I hear you
16:56:34 <danofsatx> server updated to systemd.x86_64 0:216-5.fc21. I'm not clear on what the issue is....
16:57:09 <danofsatx> oh, duh....this is a fedup error. nm, back to my hole....
16:58:31 <roshi> clear to endmeeting?
16:58:39 <roshi> #topic Open Floor
16:59:10 <tflink> I may have another blocker to propose
16:59:12 <danofsatx> I think I will have a common bug to add to server once I complete testing
17:00:04 <roshi> which bug tflink?
17:00:09 <tflink> roshi: no ec2 amis
17:00:35 <roshi> it's a manual process at this point, I think
17:00:43 <tflink> yeah, it sounds like a blocker to me, trying to get details ATM :'(
17:00:45 <tflink> roshi: still a blocker
17:01:01 <roshi> at beta?
17:01:14 <tflink> at alpha
17:01:25 <tflink> http://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#Release-blocking_images_must_boot
17:02:08 <roshi> oh
17:02:37 <adamw> danofsatx: the older systemd will be included in upgrade.img as it was built as part of the RC2 compose process - that's why RC2 has the bug
17:03:03 <danofsatx> yeah, I get it now
17:03:07 <adamw> tflink: well, that doesn't strictly say they have to exist ;)
17:03:07 <roshi> that's pretty much an autoblocker then
17:03:17 * adamw may be criteria judo-ing a step too far
17:03:21 * danofsatx is multitasking between a Uni test, F21 Test, and this meeting
17:03:37 <roshi> I thought "booting on" and "being uploaded to
17:03:43 <roshi> " were different criteria
17:03:56 <tflink> what component is responsible for cloud images?
17:04:43 <roshi> I filed my cloud blocker against distribution
17:04:53 <roshi> fedimg, I guess
17:08:20 <tflink> https://bugzilla.redhat.com/show_bug.cgi?id=1158592
17:09:17 <adamw> i guess we need to know if we need changes to the package set to cause an AMI to be generated, or if it's just compose process issues
17:09:58 <tflink> AFAIK, it can be done by hand if needed
17:10:17 <roshi> yeah, you'd have to create the AMI yourself
17:10:38 <roshi> I don't know if under the current criteria them not being uploaded is a violation of the criteria
17:10:49 <roshi> if they can't boot, then sure
17:11:26 <adamw> i'm happy to say we block beta on actually having AMIs, I guess
17:11:37 <adamw> it's just a question of what exactly needs to happen for them to come into being
17:11:44 <roshi> yeah, I think we want another criteria for it
17:11:53 <tflink> roshi: that's pushing it a bit far, I think
17:12:11 <tflink> claiming "it boots" when there is no public ami, I mean
17:12:13 <roshi> because I image we're going to want "Image uploaded in Docker  Registry, Openstack thing, and foo, and bar..." going forward
17:12:23 <roshi> I don't know if it boots or not
17:12:31 <roshi> but I haven't tried to make an AMI
17:12:45 <roshi> which is the moral equivalent to burning an image to a USB stick, IMO
17:13:13 <tflink> my point was that, in my mind, 'bootable on ec2' implies bootable through the normal process which is not "upload your own AMI"
17:13:32 <roshi> right - I think we need another criteria
17:13:44 <roshi> for the other images on the other services as well to clearly mark that out
17:13:44 <tflink> or modify the existing one to say "public image bootable on ec2"
17:13:59 <roshi> since I think it can be argued that them not being there isn't a violation
17:14:32 <roshi> I'm in agreement in the spirit of the blocker :)
17:14:48 <tflink> it sounds like oddshocks is going to manually upload RC3
17:15:07 <roshi> yeah, that's how they've gotten there in teh past
17:15:12 <roshi> manual upload process
17:15:32 <roshi> his fedimg is supposed to automate it, but he's still working on bits for it, aiui
17:16:02 <roshi> I would really want to block on not having images uploaded to the right services
17:16:21 <roshi> but with a criteria that could be argued, I can see more fudge room on that than I like
17:16:24 <roshi> is all I was saying
17:18:56 <roshi> .bug 1158592
17:18:58 <zodbot> roshi: Bug 1158592 Fedora 21 Beta AMIs are Missing - https://bugzilla.redhat.com/1158592
17:19:00 <roshi> votes?
17:19:08 <roshi> +1 blocker from me
17:19:26 <tflink> sorry, got pulled into fesco meeting
17:19:29 <tflink> +1 blocker
17:19:31 * roshi will work on a draft criteria for "images must be uploaded" at alpha
17:19:35 <roshi> np
17:19:36 <adamw> +1 for public AMIs, sure. i'm assuming it doesn't prevent the RC3 compose going ahead.
17:20:04 <roshi> I don't see why it would, we'll just do it manually for RC3 again
17:20:10 <danofsatx> +1
17:20:24 <jreznik_> +1, just let's make sure it's done
17:20:53 <tflink> I think that at this point, we might as well wait for RC3 to upload them
17:21:01 <tflink> one region is fine for TC/RC images
17:21:05 <roshi> proposed #agreed - 1158592 - AcceptedBlocker - This is a violation of the "Images must boot" alpha criterion. Images have to be available in order to boot.
17:21:21 <roshi> I'll make sure things get uploaded for RC3
17:26:13 <roshi> ack/nack/patch?
17:26:38 <kparal> ack
17:27:13 <danofsatx> ack
17:27:43 <jreznik_> ack
17:28:20 <roshi> #agreed - 1158592 - AcceptedBlocker - This is a violation of the "Images must boot" alpha criterion. Images have to be available in order to boot.
17:28:28 <roshi> anyone have anything else for this meeting?
17:29:59 <tflink> nothing from me
17:31:05 <kparal> no
17:31:15 * roshi sets the fuse
17:32:05 <roshi> 3...
17:32:21 <roshi> 2...
17:32:36 <danofsatx> kerplowie
17:33:03 <roshi> yup, about right
17:33:10 <roshi> thanks for coming folks!
17:33:14 <roshi> #endmeeting