16:00:04 <roshi> #startmeeting Bonus Blocker Review
16:00:04 <zodbot> Meeting started Mon Oct 20 16:00:04 2014 UTC.  The chair is roshi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:15 <roshi> #topic Roll Call
16:00:18 * dustymabe lurks
16:00:36 * satellit listening
16:00:47 * kparal is here
16:01:15 <roshi> #chair kparal satellit dustymabe danofsatx adamw
16:01:15 <zodbot> Current chairs: adamw danofsatx dustymabe kparal roshi satellit
16:01:21 <adamw> ahoyhoy
16:01:34 <danofsatx> still heah
16:01:53 * roshi skips the boilerplate and gets right to the blockers (which we have 6 of)
16:01:57 <jreznik> hello
16:02:07 <roshi> hey jreznik :)
16:02:08 <roshi> #topic (1154235) fedora-release now loses to generic-release when racing to provide system-release: causes non-product F21 Beta TC4 images to be generic
16:02:11 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1154235
16:02:14 <roshi> #info Proposed Blocker, fedora-release, NEW
16:02:37 <adamw> +1 blocker of course
16:02:44 <danofsatx> +1
16:02:46 <roshi> +1
16:02:52 <adamw> next compose should fix this for at least live image cases, we should probably check if others are affected
16:02:53 <jreznik> +1, this is clear blocker
16:03:06 <adamw> kalev fixed it in fedora-live-base.ks
16:03:49 <roshi> proposed #agreed - 1154235 - AcceptedBlocker - This bug is a clear violation of the Alpha Updates criteria: "The installed system must be able to download and install updates with the default console package manager."
16:04:01 <adamw> ack
16:04:32 <jreznik> ack
16:04:58 <roshi> who wants to be The Secretarializer (tm)?
16:05:36 * roshi is going to get 'secretarialize' in the dictionary someday - it'll be in spelling bees and everything
16:05:43 <kparal> I could do that, once again
16:05:52 <pwhalen> +1 this affects all arm images
16:06:00 <roshi> #agreed - 1154235 - AcceptedBlocker - This bug is a clear violation of the Alpha Updates criteria: "The installed system must be able to download and install updates with the default console package manager."
16:06:10 <roshi> thanks kparal
16:06:27 <roshi> I can do it all after the meeting if you've got places to be and things to do
16:06:42 <roshi> #topic (1153816) Fedup needs to support upgrading into a Productized Fedora 21
16:06:45 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1153816
16:06:48 <roshi> #info Proposed Blocker, fedup, MODIFIED
16:08:02 <roshi> +1
16:08:03 <kparal> roshi: I guess I have used a wrong term, it wasn't meant to sound negative :)
16:08:38 <roshi> no worries :) I wasn't sure though, figured I'd offer at least
16:08:54 <danofsatx> hmm....is this a +1 for g/ng this week, or a punt since the fix is in (according to wwoods)
16:09:31 <roshi> upgrading from F20 to F21 Product is something we need to test - so it needs to be there for the beta release IMO
16:09:43 <roshi> s/need/*need*/
16:11:03 <adamw> did we approve the proposed criterion?
16:11:18 <jreznik> that's the good question, I don't think so
16:11:22 * roshi thought so
16:11:30 <roshi> but that doesn't mean anything
16:11:47 <adamw> well, it does, but i'd say we can reasonably approve it in this meeting given the number here, if we want to
16:11:52 * adamw checks for latest wording
16:12:41 * sgallagh appear
16:12:44 <sgallagh> +s
16:13:02 <danofsatx> sgallagh: you forgot the *poof*
16:13:05 <adamw> the proposal is https://fedoraproject.org/w/index.php?title=Fedora_21_Beta_Release_Criteria_sgallagh_draft&diff=390666&oldid=390661
16:13:45 <adamw> presumably we would then adjust the wording again for F22 to be agnostic, and for F23 to say the product status must be maintained?
16:14:28 <sgallagh> danofsatx: According to Douglas Adams, that should have been *foop*
16:14:43 <danofsatx> ;)
16:15:17 <sgallagh> https://fedoraproject.org/w/index.php?title=Fedora_21_Beta_Release_Criteria_sgallagh_draft&diff=390671&oldid=390661 is actually a better comparison. I cleaned up the formatting some.
16:15:23 * satellit afk
16:15:26 <sgallagh> Yes, we would need to adjust it for F22
16:15:33 * jreznik thinks this is more exception in series - so we can approve it temporarily for transition period and then remove again
16:16:29 <sgallagh> jreznik: Well, going forward I think we'll need a criteria that the Product shouldn't change underneath you on upgrade
16:17:02 <roshi> probably
16:17:04 <adamw> and we do have the criteria pages per-release, so hey, we may as well use it
16:17:12 <roshi> wfm
16:17:16 <adamw> i'm OK with the proposal as long as we remember to revise it
16:17:20 <roshi> +1 for the proposed criteria
16:17:21 <jreznik> adamw: same here
16:17:26 <sgallagh> adamw: Ack
16:17:35 * roshi actions adamw to remember :p
16:19:57 <roshi> proposed #agreed - 1153816 - AcceptedBlocker - Updates from F20 to Productized F21 needs to work for Beta in order to satisfy the Upgrade Requirements criteria.
16:20:08 * roshi was kinda blanking on a good way to word that one
16:20:48 <jreznik> +1 to criteria change, ack to proposal
16:21:34 <sgallagh> Patch
16:22:18 <roshi> go for it sgallagh
16:22:25 <sgallagh> Upgrades from Fedora 20 to Fedora 21 requires the selection of a Product or an explicit choice to remain non-productized. This criteria must be satisfied for Beta release.
16:22:36 <roshi> ack
16:23:06 <danofsatx> ack
16:23:33 <danofsatx> for clarification, I'm acking sgallagh's
16:23:36 <kparal> ack
16:23:58 <adamw> ack
16:24:18 <roshi> #agreed - 1153816 - AcceptedBlocker - Upgrades from Fedora 20 to Fedora 21 requires the selection of a Product or an explicit choice to remain non-productized. This criteria must be satisfied for Beta release.
16:24:36 <roshi> #topic (1146580) Mislabelled /usr/sbin, /usr/bin after fedup
16:24:36 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1146580
16:24:37 <roshi> #info Proposed Blocker, fedup-dracut, ASSIGNED
16:26:03 <roshi> this is already accepted, by my count
16:26:09 <roshi> just never updated the bug
16:26:15 <kparal> +1
16:26:17 * roshi is still +1
16:27:27 <adamw> probably my fault, again
16:27:31 <adamw> .fire adamw
16:27:31 <zodbot> adamw fires adamw
16:27:49 <roshi> no worries - do we need an #agreed for this?
16:27:55 <adamw> sgallagh: do you want to go ahead and apply your criterion update btw?
16:27:55 <danofsatx> +1 (to firing adamw)
16:28:13 <sgallagh> adamw: Sure, I can do that.
16:28:20 <adamw> are we +1 blocker or +1 fe to this?
16:28:24 <adamw> seems to be a mix of votes on the bug
16:28:34 <adamw> .fire danofsatx insubordination!
16:28:34 <zodbot> adamw fires danofsatx insubordination!
16:28:49 <roshi> oh yeah, FE from me
16:29:14 <danofsatx> hey, it was a gift of free time, nothing but good intentions. I think you're the one practicing insubordination!
16:29:18 <roshi> seemed to be more of an annoyance than a catastrophic fail
16:30:13 <adamw> yeah, FE for now
16:30:24 <adamw> leave blocker status undetermined
16:30:35 <adamw> we can do a #agreed since we haven't actually discussed it at a meeting yet
16:31:02 <sgallagh> Applied.
16:31:16 <kparal> should I update the bug or not?
16:31:53 <roshi> proposed #agreed - AcceptedFreezeException - This bug would be great to get fixed for Beta. Blocker status is still undetermined, provide more information in the bug is severe breakage is found for it.
16:32:25 <adamw> kparal: yeah, update it with acceptedfe (assuming we agree)
16:32:28 <adamw> ack
16:32:34 <kparal> ack
16:32:47 <danofsatx> ack
16:32:55 <roshi> #agreed - AcceptedFreezeException - This bug would be great to get fixed for Beta. Blocker status is still undetermined, provide more information in the bug if severe breakage is found for it.
16:33:04 * roshi changed a typo in it
16:33:47 <roshi> #topic (1104682) DomU boot failure: BUG: soft lockup - CPU#0 stuck for 22s! [systemd-udevd:161]
16:33:50 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1104682
16:33:53 <roshi> #info Proposed Blocker, kernel, NEW
16:34:54 <adamw> so one person hit this, our long-term xen tester konrad didn't
16:34:58 <adamw> bit hard to know what to do
16:35:03 <adamw> anyone else set up for xen testing?
16:35:09 * roshi isn't
16:35:58 * dustymabe not for the past few years
16:38:25 <adamw> i guess we could leave it till wednesday and see if more becomes c lear
16:38:29 <adamw> it'd be great if more people could test though
16:40:02 <roshi> I just pinged in cloud to see if anyone might be set up for it
16:40:11 <roshi> we can wait til wednesday
16:40:20 <roshi> we'll just move to the next bug
16:40:26 <adamw> ok, thanks
16:40:27 <sgallagh> adamw: Is Xen support a blocking feature?
16:40:54 <adamw> sgallagh: yes, it's in the beta criteria. part of the deal is that those proposing it (i.e. konrad) help out with testing.
16:41:11 <sgallagh> Ah, never mind. I misunderstood the problem. Guest support makes sense.
16:41:41 * sgallagh parsed the subject as dom0 and got confused.
16:42:10 <adamw> ah :)
16:43:33 * roshi moves to the next bug
16:43:47 <roshi> #topic (1154138) [abrt] lorax: mkefiboot:61:macmunge:IndexError: list index out of range
16:43:50 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1154138
16:43:52 <roshi> #info Proposed Blocker, lorax, MODIFIED
16:45:34 <adamw> this one confuses me somewhat
16:47:43 <roshi> same here
16:48:37 <adamw> bcl: so in the nomination for this bug you wrote "Without this fix livecd-creator will fail when using lorax >= 21.25-1", but I'm pretty sure we did the tC4 compose with that lorax and it doesn't seem to have failed
16:48:42 <adamw> so...is there something I'm missing?
16:49:02 <adamw> in fact tc3 and tc4
16:49:04 <bcl> do you have the logs? It shouldn't have worked.
16:51:01 <adamw> they should be in koji]
16:51:19 <adamw> http://koji.fedoraproject.org/koji/taskinfo?taskID=7894351 is the tc4 kde live for e.g. (i happen to have that in my cache for other reasonss)
16:51:30 <adamw> ah
16:51:37 <adamw> and now i see mkefiboot did fail, but the compose proceeded
16:52:08 <adamw> bcl: so consequence of that will be - lives not UEFI bootable? or not mac bootable?
16:52:24 <bcl> 21.25-1.fc21
16:52:34 <bcl> no UEFI
16:52:39 <adamw> ok, obvious +1 blocker then
16:52:53 <sgallagh> Agreed. +1
16:53:07 <kparal> +1
16:53:14 <roshi> if that's the case: +1
16:53:29 <adamw> alpha criterion "Release-blocking images must boot
16:53:29 <adamw> All release-blocking images must boot in their supported configurations. "
16:53:34 <adamw> "Release-blocking images must boot from all system firmware types that are commonly found on the primary architectures. "
16:53:49 <adamw> thanks bcl
16:53:57 <dustymabe> +$.02 because that is what my +1 is worth :)
16:54:17 <roshi> proposed #agreed - 1154138 - AcceptedBlocker - This bug breaks UEFI booting which is an obvious violation of the Alpha criteria: "Release-blocking images must boot from all system firmware types that are commonly found on the primary architectures."
16:54:22 <bcl> thanks. I'll get a new one built.
16:54:26 <kparal> ack
16:54:29 <adamw> hum, i should find that person who was having a lot of trouble getting a non-UEFI-native boot and tell them to use a TC4 live image...:)
16:54:52 <adamw> ack
16:55:09 <danofsatx> sorry, damn $dayjob intervened
16:55:33 <roshi> #agreed - 1154138 - AcceptedBlocker - This bug breaks UEFI booting which is an obvious violation of the Alpha criteria: "Release-blocking images must boot from all system firmware types that are commonly found on the primary architectures."
16:55:42 <roshi> #topic (1148923) ValueError: this device's formatting cannot be modified
16:55:45 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1148923
16:55:48 <roshi> #info Proposed Blocker, python-blivet, ON_QA
16:56:57 <roshi> hrm, no update since last week (explanation, I mean)
16:57:17 <adamw> yeah, we should ask for confirmation of the fix in tc4/tc5
16:58:31 * adamw just did
16:59:07 <roshi> that's it for proposed blockers
16:59:36 <dustymabe> roshi: open floor?
16:59:36 * roshi is assuming we'll just wait on that bug and don't need an #agreed punt on it for the time being
16:59:56 <roshi> we've got some proposed FEs I presume people will want to go through
17:00:06 <dustymabe> roshi: ok I'll wait
17:00:10 <roshi> do you have time for that dustymabe or are you crunched for time?
17:00:40 <dustymabe> roshi: that's fine.. as long as it's not > 30 minutes
17:00:48 <roshi> it might be
17:01:02 <dustymabe> roshi: ok. no worries. just continue
17:01:18 <roshi> alright, onto FEs
17:01:26 <roshi> #topic (1153672) syntax
17:01:26 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1153672
17:01:26 <roshi> #info Proposed Freeze Exceptions, anaconda, POST
17:02:19 <adamw> i don't mind pulling this into a new anaconda build if we need one for something else
17:02:56 <roshi> same here
17:03:04 <kparal> the OP talks about a syntax error, but David talks about a string chance
17:03:24 <kparal> syntax error mean it should not run at all or crash
17:04:22 <adamw> not really
17:04:35 <adamw> 'syntax error' is a perfectly appropriate term in the realm of actual human languages too
17:04:41 <adamw> in fact that's where programming gets the term from :)
17:04:45 <kparal> ah
17:04:53 <adamw> though really this is a spelling mistake, not a syntax error
17:04:54 <roshi> yeah, I transliterated that in my head
17:05:51 <adamw> kparal: a link from .cz: https://ufal.mff.cuni.cz/~hana/teaching/2013wi-ling/06-Syntax.pdf ;)
17:06:27 <kparal> -    ERROR_SOURCE = N_("No installation source avaialble")
17:06:27 <kparal> +    ERROR_SOURCE = N_("No installation source available")
17:06:38 <kparal> that's the fix
17:06:53 <kparal> I don't mind putting in, but translators might object
17:06:57 <kparal> *it in
17:07:51 <kparal> is there a string freeze for Beta?
17:08:08 <roshi> is a string freeze different from a normal freeze?
17:08:22 <kparal> to answer my question, yes there is
17:08:38 <kparal> 2014-10-14   Software Translation Deadline
17:08:42 <adamw> and yes it is
17:08:49 <roshi> ah, didn't know
17:08:50 <adamw> https://fedoraproject.org/wiki/Software_String_Freeze_Policy
17:08:59 <roshi> I figured freeze was freeze
17:09:03 <adamw> it might be worth noting FE process does not grant string freeze exceptions
17:09:52 <adamw> fixing this for beta would require a milestone freeze exception *too*, but it's possible what david wanted was a string freeze exception
17:10:21 <roshi> so, -1 on policy
17:10:36 * adamw asks
17:12:09 <adamw> <davidshea> adamw: I mean yeah it would be nice to fix for beta. it's just a string change
17:12:46 <adamw> so, i don't really know? i mean, i don't have any objection to fixing this in an anaconda update for other blocker/fe fixes, i don't want to gazump the string freeze policy though.
17:14:16 <adamw> i'm fine with saying +1 from a milestone freeze perspective and a note that we're not overriding string freeze process
17:14:39 <rdieter> imo, I would hope spelling fixes do not count as "modification of existing strings" (or am I missing something?)
17:14:57 <roshi> depends on how totalitarian you are with the interpretation
17:15:11 * roshi doesn't think clear spelling errors should count
17:15:11 <kparal> who grants string freeze exceptions?
17:15:17 <roshi> localization team
17:15:33 <kparal> roshi: I think it counts, because it switches your translated sentence back to untranslated
17:15:40 <roshi> ...
17:15:42 <roshi> oh
17:15:54 <kparal> at least that's how I think gettext works
17:16:06 <kparal> might be wrong
17:16:07 <roshi> well, I would guess that it was translated as if it was spelled correctly
17:16:19 <adamw> the translations cue on the initial text
17:16:29 <adamw> if you change the initial text, the system doesn't know what translation to apply any more
17:16:59 <roshi> ok, so I think this leaves us with a -1 and a note on where to go next
17:17:03 <adamw> if there's already a translation for the string "No installation source available" - i.e. if it's used anywhere else in the code - then it would be used, otherwise all the translators have to update their translations with the new 'original' string
17:17:13 <adamw> roshi: i'm still not sure why you say that
17:17:17 <kparal> so let's give him +1 from QA POV and send him to translation team
17:17:22 <adamw> the string freeze process can't grant milestone freeze exceptions
17:17:29 <adamw> so if we say -1 this change is not going into beta
17:17:39 <roshi> ah, right
17:18:09 <adamw> it sounds like david wants to get it into beta, so it's correct that he submits it and we consider it, so long as we make it clear it also needs a string freeze exception
17:18:18 <roshi> +1 and send on, the fix getting pulled in after localization oks it
17:19:20 <roshi> proposed #agreed - 1153672 - AcceptedFreezeException - If this change gets an OK from the Localization Team, QA would be happy to get it into Beta.
17:19:24 <adamw> ack
17:19:46 <kparal> ack
17:19:57 <adamw> well, mabye don't say 'qa'
17:20:13 <adamw> blocker/FE review is officially a combination of qa/devel/releng/management, it's not just qa
17:20:26 <kparal> btw, 20 minutes discussing a typo. productivity! ;)
17:20:36 <roshi> I'll patch
17:20:50 <roshi> proposed #agreed - 1153672 - AcceptedFreezeException - If this change gets an OK from the Localization Team, it would be great to get it into Beta.
17:21:08 <adamw> ack
17:21:14 <roshi> #agreed - 1153672 - AcceptedFreezeException - If this change gets an OK from the Localization Team, it would be great to get it into Beta.
17:21:20 <roshi> #topic (1146580) Mislabelled /usr/sbin, /usr/bin after fedup
17:21:20 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1146580
17:21:20 <roshi> #info Proposed Freeze Exceptions, fedup-dracut, ASSIGNED
17:21:38 <adamw> kparal: hey, i'll have you know i'm reading crappy tech news in the background
17:21:48 <adamw> we accepted this earlier i think
17:21:52 <roshi> yeah, we did
17:21:56 <kparal> adamw: and I'm cooking dinner. so overall it's not that bad :0
17:22:06 <roshi> #topic (1154206) If online account is configured in g-i-s user creation mode, user's keyring password is broken and can never be accessed
17:22:09 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1154206
17:22:11 <roshi> #info Proposed Freeze Exceptions, gnome-initial-setup, NEW
17:22:47 <roshi> +1 FE for this
17:23:24 <roshi> +1 blocker for Final FWIW as well
17:23:26 <adamw> i proposed it, so obviously +1
17:24:29 <kparal> +1
17:24:35 <danofsatx> +1
17:24:47 <roshi> are those votes for FE or both?
17:25:01 <kparal> fe
17:25:13 <kparal> are we voting on final blocker as well?
17:25:17 <adamw> roshi: we just got a new blocker proposal, btw: https://bugzilla.redhat.com/show_bug.cgi?id=1154768
17:25:24 <adamw> we don't need to vote on final blocker for this yet...
17:25:35 <roshi> no no no - ignore the blockers behind the curtain
17:25:39 <roshi> ;)
17:26:14 <roshi> proposed #agreed - 1154206 - AccptedFreezeException - This bug really affects the usability of a system and getting a fix in for beta would help facilitate testing.
17:27:06 <adamw> ack
17:27:08 <kparal> ack
17:27:13 <danofsatx> ack
17:27:30 <roshi> #agreed - 1154206 - AccptedFreezeException - This bug really affects the usability of a system and getting a fix in for beta would help facilitate testing.
17:27:38 <roshi> #topic (1145122) Provide more debug output on errors
17:27:38 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1145122
17:27:38 <roshi> #info Proposed Freeze Exceptions, initial-setup, POST
17:28:20 <kparal> +1, logging is always good
17:29:10 <roshi> +1
17:29:10 <kparal> it will help debugging beta issues
17:29:29 <adamw> i would be tempted to deploy grumpiness and say no
17:29:42 <kparal> why?
17:29:45 <adamw> this seems like the kinda thing we invented fe process to worry about - gratuitous changes to potentially critical components
17:29:46 <kparal> can't be updated
17:29:56 <adamw> what if we accept this and it turns out it breaks i-s compeltely?
17:30:10 <adamw> we just probably delayed release to add some debug logging
17:30:13 <adamw> that seems bad
17:30:34 <kparal> otoh, the patch is ready and we have quite a few blockers still unresolved
17:30:53 <kparal> should we look how invasive the patch is?
17:31:02 <roshi> should probably check the patch
17:31:05 <kparal> let's ask mkolman, he's still available
17:31:21 <kparal> mkolman: ping
17:31:27 <roshi> moar logging shouldn't break things - but then again I used *that* word
17:31:39 <mkolman> kparal: I'm here
17:31:41 <adamw> i'd check the patch if i could *see* it
17:31:47 <adamw> "Patch that adds comprehensive syslog-based logging to Initial Setup has been posted for review.", but i see nothing on anaconda-patches
17:31:50 <kparal> mkolman: how likely is your patch to break anything?
17:31:51 <roshi> same here
17:32:00 <adamw> roshi: the thing that worries me is it's not 'moar logging', it's 'logging'.
17:32:05 <adamw> "Patch that adds comprehensive syslog-based logging to Initial Setup"
17:32:16 <kparal> mkolman: and can you give us a link for the patch?
17:32:19 <adamw> i.e. it didn't have *any* before.
17:32:32 <mkolman> adamw: https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-October/014187.html
17:32:35 <roshi> well, it returned 1 - that's a log, kinda
17:32:37 * roshi ducks
17:32:57 <adamw> ah, i was searching for initial-setup.
17:33:17 <mkolman> BTW, when looking for the patches, they usually have the bug number in the header
17:33:28 <adamw> there is no patch in that email.
17:33:41 <roshi> next message in the thread, I think
17:33:46 <adamw> oh, it's a reply with a different title, whee.
17:33:49 <mkolman> adamw: actually I always take care to include the component in the header
17:34:02 <mkolman> unless I don't - which was in this solitary case :)
17:34:23 <kparal> mkolman: so, back to "how likely"... ?
17:34:39 <mkolman> kparal: not very likely
17:34:49 <mkolman> I've tested it quite a lot
17:35:21 <roshi> not that this means anything, but the patch *looks* fine to me
17:35:30 <mkolman> and it basically just adds a new logger & bunch of calls for it
17:36:41 <kparal> it's not a completely trivial patch, something could go wrong
17:36:51 <kparal> but it also looks OK to me
17:36:59 <adamw> there are cases where a variable substition in one of the log messages could fail for e.g.
17:37:04 <mkolman> BTW, you can now also see on which line of your kickstart you have a mistake unlike the "-1" it reported before for any error :)
17:37:10 <adamw> not hugely likely, but hey
17:37:41 <adamw> guess i can be a grumpy +1, but i reserve my 'i told you so' rights
17:37:48 <adamw> has this been tested with an ARM disk image deployment at all?
17:37:51 <mkolman> well I rather wonder if Initial Setup will even get installed with all this compose shuffling :)
17:37:54 <adamw> that being the case where i-s is actually criticla
17:37:56 <kparal> the reason for accepting is that it won't be updated, so everyone installing Beta will get either this or updated version
17:38:15 * pwhalen reads scrollback
17:39:02 <kparal> there might be a problem e.g. when syslog is not available. but I guess that has to be handled similarly in anaconda logging module
17:39:22 <adamw> python should do something sane in that case.
17:39:23 <kparal> and I guess mkolman based his new module on the existing one
17:39:30 <adamw> it's not really using syslog, it's using python logging.
17:39:42 <kparal> +    def __init__(self,
17:39:43 <kparal> +                 address=('localhost', SYSLOG_UDP_PORT),
17:39:43 <kparal> +                 facility=SysLogHandler.LOG_USER,
17:39:43 <kparal> +                 tag=''):
17:39:46 <mkolman> it is a cutdown version of what Anaconda does
17:39:54 <adamw> the case i'm most worried about is if, for e.g., "section_msg = "%s on line %d" % (repr(section), section.lineno)" is invalid in some scenario for some reason
17:40:11 <mkolman> if this breaks Anaconda breaks in the same way
17:40:23 <adamw> kparal: oh, missed that bit.
17:40:59 <mkolman> adamw: that would mean pykickstart is broken
17:41:01 <kparal> btw I wouldn't count on python behaving sanely when it comes to logging, I have my share of experience with that :)
17:41:05 <adamw> hehe
17:41:37 <mkolman> kparal: actually I find the Python logging machinery quite nice & powerful
17:41:43 <adamw> i'd at least like to see someone test an arm image deployment using this i-s i guess
17:42:03 <roshi> I'm fine with punting until wednesday and we can get some testing for arm in the mean time
17:42:07 <kparal> after seeing the patch, I'm not so fast with +1, I can be swayed both ways I guess. if I had to decide that, I would still give +1 probably
17:42:10 <adamw> is there a build with it included somewhere?
17:42:21 <danofsatx> gotta run, folks, it's been fun
17:42:25 <adamw> roshi: well, wednesday is kind of late, in theory we ought to build the RC tomorrow or at least early wed
17:42:29 <roshi> later danofsatx
17:42:35 <roshi> yeah
17:42:44 <roshi> we're crunched for time anyways
17:43:05 <roshi> I'm kinda in teh same boat as kparal for this one
17:43:09 <mkolman> adamw: I guess I can make a scratch build for it ?
17:43:17 <adamw> note that we don't use anaconda on the arm disk images but we do use i-s, and anaconda's dependencies aren't *necessarily* all expressed in its spec
17:43:20 <roshi> but I guess I'd err on the side of caution
17:43:27 <adamw> mkolman: that'd help
17:43:40 <mkolman> adamw: anaconda is an IS dependency
17:44:00 <pwhalen> adamw, happy to test, initial-setup has been working okay so far
17:44:08 <pwhalen> graphical. text
17:44:12 <mkolman> adamw: it is using parts of it so Anaconda needs to be installed or it would not work at all
17:44:49 <adamw> mkolman: it's installed, yes, but i mean we don't actually *run* it as part of arm image deployment
17:44:53 <mkolman> (thats' actually the reason it was written to replace Firstboot, which was a standalone tools with huge code duplication)
17:45:08 <adamw> mkolman: so the assertion that this must work because otherwise anaconda wouldn't work doesn't hold for the case where it's actually most critical
17:46:00 <adamw> what i'm saying is it's theoretically possible this stuff works in the installer environment because of some bit that's present there which would turn out not to be present on, say, the ARM minimal disk image
17:46:10 <adamw> not that it's likely, but it's a case that's possible
17:46:36 <adamw> there is stuff pulled into the installer environment through mechanisms other than the anaconda package's deps, so you can't be assured that all the same stuff is present in both cases
17:46:53 <roshi> I guess -1, touches more than I'd like this late
17:47:00 <roshi> and we've gotten this far without the logging
17:47:36 <adamw> if mkolman does a quick scratch build and pwhalen tests an arm image with it included and it all works i'd probably be OK, but it'd be nice to see that at least
17:47:45 <roshi> yeah
17:47:57 <roshi> punt for now, vote in ticket after pwhalen tests it?
17:48:41 <adamw> sure
17:48:43 <pwhalen> wfm
17:48:50 <kparal> ok
17:49:00 <adamw> there's some time before we get an RC compose, if it looks solid enough by then and has votes it can get pulled in
17:49:00 <kparal> should I update the ticket somehow?
17:49:12 <roshi> #agreed - 1145122 - Punt until pwhalen can test a scratch build and then we'll proceed to vote in the bug.
17:49:14 <adamw> just a note explaining this, i guess?
17:49:17 <kparal> ok
17:49:34 <roshi> #action pwhalen to let us know when he's completed his testing.
17:50:03 <roshi> #topic (1152229) initial-setup specifies wiki as upstream which does not contain link to sources
17:50:06 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1152229
17:50:08 <roshi> #info Proposed Freeze Exceptions, initial-setup, POST
17:50:11 <pwhalen> just need a pointer to the scratch
17:50:33 <adamw> mkolman: can you link the scratch build from the bug when you've done it? thankjs
17:50:43 <pwhalen> many thanks
17:50:52 <kparal> mkolman: and CC pwhalen if he's not already
17:51:30 <mkolman> adamw: http://koji.fedoraproject.org/koji/taskinfo?taskID=7917128
17:51:55 <kparal> so, this is about changing url in a specfile?
17:51:55 <adamw> this really doesn't seem worth breaking freeze for. unlikely to break anything, but it's just unnecessary churn. if we're taking an i-s build for something else i don't mind if the spec file fixes this at the same time, i guess.
17:52:14 <kparal> the same opinion here
17:52:42 <roshi> yeah
17:52:48 <adamw> we can also have http://fedoraproject.org/wiki/FirstBoot link / redirect to the Initial Setup page, of course
17:53:02 * adamw really, really hates camel-cased wiki page names
17:53:40 <adamw> looks like mkolman already added a note to the FirstBoot page
17:53:49 <roshi> proposed #agreed - 1152229 - RejectedFreezeException - This isn't quite worth breaking freeze for. However, if there's another i-s build that goes through it would be fine to pull this in. It's just not worth the break on it's own.
17:53:51 <adamw> so even from the existing URL you'll have no trouble finding where you're going
17:53:56 <kparal> adamw: you don't have proper Java background, that's the reason
17:54:01 <adamw> kparal: =)
17:54:18 <adamw> unfortunately by rejecting this it'd be against the letter of the law to fix it at the same time as another FE, but hey, let's just not notice
17:54:39 <kparal> ack
17:54:59 <roshi> true - but following the letter for the sake of the letter doesn't help us at all I don't think, in this case
17:55:11 <adamw> mkolman: fwiw for something very trivial like this you can usually submarine it in alongside a real FE/blocker fix and we can sort of 'turn a blind eye', though the letter of the law says all changes must be reviewed. it's a bit hard to legislate for something like a metadata fix or spelling error in the changelog or something
17:55:17 <roshi> ConditionalFreezeException, maybe?
17:55:41 <adamw> i think that's the point where we turn into a bad parody of ourselves =)
17:55:51 <roshi> :)
17:56:05 <roshi> ack/nack/patch?
17:56:20 <adamw> Pursuant to sub-section 147a) ii) b) of the Third Amendment to the Second Revision...
17:56:22 <adamw> ack
17:56:45 * dustymabe notices it is way past lunch time
17:56:47 <roshi> #agreed - 1152229 - RejectedFreezeException - This isn't quite worth breaking freeze for. However, if there's another i-s build that goes through it would be fine to pull this in. It's just not worth the break on it's own.
17:57:00 <roshi> 2 more
17:57:04 <roshi> then that new blocker
17:57:05 <roshi> #topic (1153768) Provide more debug output on errors
17:57:05 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1153768
17:57:05 <roshi> #info Proposed Freeze Exceptions, initial-setup, NEW
17:57:20 <adamw> clone error
17:57:23 <adamw> unpropose, move on
17:57:41 <roshi> yep
17:57:49 <adamw> mkolman: be careful when cloning bugs, BZ clones *everything*, including stuff you probably don't want (like fedora blocker/FE proposals to an RH bug...)
17:57:50 <roshi> #topic (1149782) liveusb-creator creates non-booting Live USB
17:57:50 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1149782
17:57:50 <roshi> #info Proposed Freeze Exceptions, liveusb-creator, NEW
17:58:25 <mkolman> adamw: ok then - scratch build link added to the bug & pwhalen CCed
17:58:34 <roshi> thanks mkolman
17:58:42 <adamw> mkolman: thanks
17:58:55 <mkolman> adamw: np :)
17:59:22 <adamw> this is the one satellit mentioned earlier, i think
17:59:25 <adamw> it'd be good to have some more tests
18:00:12 <adamw> this is actually a blocker if it's valid/universal, all 'supported' USB writing methods are required to work for beta
18:00:19 <roshi> yeah
18:00:23 <roshi> it would be a blocker
18:00:30 <satellit> is this a case of volume ID being too long?
18:00:36 <adamw> satellit: hard to say without trying it.
18:00:39 <kparal> usually I need to recreate partition layout from scratch in order for luc to work
18:00:44 <adamw> i didn't think that should stop the image booting, but it's possiblwe.
18:00:49 <kparal> it's just broken beyond repair
18:00:54 <roshi> I'll test with TC4 after this and lunch on i386
18:01:01 * roshi always uses dd
18:01:29 <kparal> I can also test tomorrow
18:01:44 <adamw> hum, luc crashes when I click Browse, here. that's not good.
18:01:44 <kparal> or at least delegate it, I'm really good at that
18:02:02 <roshi> haha
18:04:00 <roshi> so punt and test, voting in bug?
18:04:09 <kparal> fine by me
18:04:47 <adamw> yeah, but we really *do* need to do it
18:04:52 * adamw installs luc on his f20 box
18:05:15 <roshi> I'll do it after I get back from my lunch appt, while I wait on cloud images
18:06:13 <roshi> any issues with moving on to the newly proposed blocker?
18:06:24 <mkolman> adamw, pwhalen: in case anyone wants to test, the scratch build just finished :)
18:06:43 <adamw> roshi: nope, there's a newly proposed FE from mkolman we can do after tha
18:07:45 <roshi> #topic (1154768) Systemd ignores TimeoutSec=0 in service file
18:07:48 <roshi> #link https://bugzilla.redhat.com/show_bug.cgi?id=1154768
18:08:10 <roshi> #info Proposed Blocker, systemd, NEW
18:08:52 <pwhalen> mkolman, thanks, installing
18:09:41 <adamw> this seems fairly bad, at least +1 FE
18:09:50 <roshi> so this happens if you get to g-i-s and wait 15 minutes?
18:11:47 <adamw> roshi: i-s, not g-i-s
18:11:51 <adamw> g-i-s doesn't run the same way
18:11:56 <roshi> ah
18:12:38 <adamw> not sure if it quite blocks beta as you'd have to switch away from it to another console or whatever and log in manually to do other stuff while it was running...
18:12:43 * adamw checks criteria
18:13:40 <adamw> we don't really have a criterion that'd directly cover this, it hits the 'data corruption bug' final criterion with a bit of a stretch i guess
18:13:52 <adamw> so i'm probably -1 blocker / +1 FE
18:14:12 <adamw> mkolman: unless it's easier than I realize to hit the 'start doing something else without finishing i-s' case?
18:14:46 <roshi> not that I know of
18:15:34 <adamw> mkolman: it would be nice if we could have a build of i-s with *just* the fix for this, then a subsequent build with the logging fix, so we can choose whether to include just this or both.
18:17:27 * roshi is -1 blocker for this at this point
18:17:36 <roshi> unless it's easier to hit than we think it is
18:17:48 * roshi has to depart for a lunch appt here in a couple minutes
18:19:12 <roshi> votes?
18:19:13 <adamw> any more votes so we can wrap this up?
18:19:37 <roshi> then dustymabe has something to bring up - /me will read logs when he gets back
18:20:40 <kparal> -1/+1
18:21:48 <dustymabe> done?
18:21:49 <roshi> proposed #agreed - 1154768 - RejectedBlocker AcceptedFreezeException - It isn't clear how easy this bug is to hit. Getting a fix in for Beta would be good. Please repropose with reproduction steps if it's more widespread than currently indicated.
18:22:13 <adamw> ack
18:22:48 <roshi> ack/nack/patch?
18:22:57 <roshi> dustymabe: pwhalen kparal
18:22:58 <kparal> ack
18:23:05 <roshi> #agreed - 1154768 - RejectedBlocker AcceptedFreezeException - It isn't clear how easy this bug is to hit. Getting a fix in for Beta would be good. Please repropose with reproduction steps if it's more widespread than currently indicated.
18:23:13 <roshi> alright
18:23:17 <roshi> #topic Open Floor
18:23:27 <dustymabe> hi all , this is a bit of a curve ball but I wanted to bring up https://bugzilla.redhat.com/show_bug.cgi?id=1149043
18:23:32 <roshi> adamw: can you take care of the endmeeting stuff for me?
18:23:35 <mkolman> adamw: the is no *just* this fix
18:23:39 <adamw> am I chaired?
18:23:49 <roshi> #chair adamw
18:23:49 <zodbot> Current chairs: adamw danofsatx dustymabe kparal roshi satellit
18:23:51 <mkolman> adamw: that's a systemd bug, not an IS one
18:23:51 <adamw> mkolman: hmm?
18:23:53 <roshi> I thought you were
18:23:57 <adamw> mkolman: oh, that's right:) sorry
18:24:48 <mkolman> adamw: and as for as how bad it is - it shots down after 15 minutes after boot as long as IS is running, that's it
18:25:43 <dustymabe> for BZ1149043: basically the ip command incorrectly requires name to be added to a certain command when the man page states it is optional:
18:25:49 * roshi steps out - thanks guys, have a good rest of the meeting...
18:26:30 <adamw> so basically...you're supposed to be able to do 'ip link add SOMENAME' according to the manpage, but actually you have to do 'ip link add name SOMENAME' ?
18:26:31 <mkolman> worst case during normal usage is it can shutdown while IS is executing changes
18:26:32 <dustymabe> the BZ needs to be refiled under the correct component (not RDO), but the effect is that packstack fails RDO install on fedora 21
18:26:50 <mkolman> so they might be hal applied
18:26:54 <mkolman> *half
18:26:57 <dustymabe> adamw: yes this won't work: ip link add qvb55064258-0a type veth peer name qvo55064258-0a
18:27:06 <dustymabe> this will: ip link add name qvb55064258-0a type veth peer name qvo55064258-0a
18:27:55 <dustymabe> adamw: I don't know if this is blocker material or not, but I wanted to bring it up.
18:27:56 <adamw> arguably  in that case consuming tools should be fixed to reflect the tool's *actual* behaviour and not what the docs say, but...
18:28:09 <mkolman> but I'll note that *any* unit that is oneshot & has timeout=0 is affected, not only IS
18:28:19 <dustymabe> would be nice to have packstack work on F21 without them having to work around it..
18:28:21 <adamw> mkolman: i don't think we have any other significant ones
18:28:41 <adamw> dustymabe: so i'd be better positioned to make a call if packstack and nova were more than 'oh yeah, i think i saw those in a blog post once' in my head
18:28:43 <mkolman> any idea what luks does ?
18:28:45 <dustymabe> adamw: yeah.. but there may be other things that depend on this behavior?
18:28:52 <adamw> mkolman: luks is disk encryption
18:28:58 <mkolman> probably not oneshot though
18:29:22 <mkolman> sure, but I guess it is also started from a unit ?
18:29:27 <adamw> mkolman: no, it'd run on every boot. that'd be an interesting case for someone who had some non-boot-critical encrypted disk, though, i guess.
18:29:48 <adamw> mkolman: for decrypting volumes during boot, yeah, there should be a unit somewhere
18:30:03 <adamw> dustymabe: i don't know of any, but i mean sure it's possible...
18:30:47 <dustymabe> adamw: this might not mean much but the same bug came up in ubuntu and they fixed it in the ip package.. so I figured that should probably be our approach
18:31:05 <dustymabe> maybe not blocker material.. but definitely something we want done
18:31:26 <dustymabe> adamw: all.. let me know if you want me to propose it as a blocker
18:31:55 <adamw> dustymabe: well, right now i'm tracing out to see if it's been properly sent upstream. ultimately this is for upstream ip to fix, of course.
18:32:22 <dustymabe> adamw: of course..
18:33:14 <adamw> dustymabe: http://metadata.ftp-master.debian.org/changelogs//main/i/iproute2/iproute2_3.16.0-2_changelog top entry
18:33:23 <adamw> looks like debian backported it from upstream, ubuntu cherry-picked it from debian
18:33:36 <adamw> upstream commit is
18:33:37 <adamw> https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=f1b66ff83a0babbe99fef81b3a960d7a4ce8dbc6
18:34:15 <dustymabe> adamw: got it
18:34:31 <dustymabe> is it worth us doing the same or waiting?
18:34:31 <adamw> 3.17.0 was released recently
18:35:25 <adamw> dustymabe: it seems unlikely it's a beta blocker unless something more important i don't know about is creating veth devices this way
18:35:36 <adamw> for now i'll just assign it to the appropriate package and flag the upstream fix
18:35:37 <dustymabe> adamw: cool
18:35:48 <dustymabe> adamw: I can do that if you want
18:35:54 <dustymabe> either way
18:35:59 <adamw> i've got it
18:36:04 <dustymabe> thanks for taking some time to check it out
18:37:06 * dustymabe is hungry. see you guys later
18:38:08 <adamw> npnp, cya
18:39:21 <pwhalen> mkolman, somethings not happy with that build. been sitting at 'Cleanup' for a while (20 mins?)
18:41:01 <adamw> if we have a couple of folks around there's one more FE from mkolman to review
18:41:29 <kparal> I'm still around
18:41:36 <adamw> #topic (1154755) Initial setup built-in help is broken
18:41:53 <adamw> #link https://bugzilla.redhat.com/show_bug.cgi?id=1154755
18:42:12 <adamw> #info proposed freeze exception, initial-setup, POST
18:42:36 <adamw> i'm inclined to -1 on this, same reason as the logger bug. we don't need to change this now and i really don't want to break anything more.
18:43:25 <kparal> anaconda help is also broken, afaik
18:44:04 <kparal> I'm fine with -1
18:44:23 <kparal> if the patch was really small and non-invasive, I could imagine +1 as well
18:45:01 <adamw> patch is https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-October/013885.html
18:45:43 <adamw> the help stuff was only recently added by the looks of the patch list (which explains why we didn't notice it was broken earlier :>)
18:47:16 <adamw> anyone else got a vote?
18:48:27 <kparal> the patch seems simple enough, but -1 is safer :->
18:49:12 <adamw> yeah, i just think it's fine to pull this after beta, or after 21. we don't need to be doing it week of go/no-go.
18:49:38 <adamw> luc-written USB stick boots for me, btw, but i had to re-do the part table to make luc write to it at all
18:49:51 <adamw> (seems like it won't reformat an existing stick for you)
18:50:36 <adamw> let's say we're punting on this due to insufficient votes.
18:50:58 <adamw> #info insufficient attendees remained for a counting vote on this bug, so we punt by default. votes so far were +0/-2
18:51:06 <adamw> and i think we're done, unless anyone has anything else
18:53:11 <adamw> ok, thanks for coming folks!
18:53:14 <adamw> back to testing :)
18:53:16 <adamw> #endmeeting