From Fedora Project Wiki
Attendees
- adamw (204)
- tflink (146)
- dan408_ (97)
- jreznik (75)
- nirik (55)
- brunowolff (8)
- akshayvyas (8)
- kparal (7)
- zodbot (6)
- mkrizek (3)
- herlo (2)
- satellit_e (1)
- jwb (1)
Agenda
- Previous meeting follow-up
- Fedora 18 Beta status / mini blocker review
- Open floor
Previous meeting follow-up
Fedora 18 Beta mini blocker/NTH review
- #876789 was rejected as a blocker due to not affecting all testers, accepted NTH
- #875278 was skipped as already addressed
- #877623 was left undetermined until further data could be obtained
- #877567 was accepted as a blocker for preventing compose
- #877576 was accepted as NTH as a significant translation issue
- #874753 was rejected as NTH as fixable post-release
- #876922 was accepted as NTH pending some pre-flight testing
Fedora 18 Beta status
- There were two unaddressed blockers, #876655 and #877567
- Current fedup status was unclear, minimum acceptable functionality had not yet been solidly defined
- We were still missing builds for fedup-dracut and lorax
- #877567 was under intensive investigation, it would be possible to 'fix' it one way or the other
- RC was essentially blocked on fedup
Open floor
- jreznik was asked if ON_DEV status was used actively in Fedora: group generally agreed it was not and had no objections to dropping it
- Go/no-go meeting scheduled for 2012-11-22 (Thanksgiving in U.S.) despite the holiday, as we did not expect to be ready by Wednesday
Action items
- tflink to continue to evaluate fedup status and propose significant bugs for blocker status
IRC Log
| adamw | #startmeeting Fedora QA meeting | 16:02 |
|---|---|---|
| zodbot | Meeting started Mon Nov 19 16:02:59 2012 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:02 |
| zodbot | Useful Commands: #action #agreed #halp #info #idea #link #topic. | 16:02 |
| adamw | #meetingname fedora-qa | 16:03 |
| zodbot | The meeting name has been set to 'fedora-qa' | 16:03 |
| adamw | #topic roll call | 16:03 |
| adamw | morning folks, how're we diddling? | 16:03 |
| * tflink is here | 16:03 | |
| * mkrizek is here | 16:03 | |
| * satellit_e listening | 16:03 | |
| tflink | adamw: as long as you didn't ask who/what :-D | 16:03 |
| jreznik | me is here and there | 16:03 |
| * nirik is lurking | 16:03 | |
| * kparal around | 16:03 | |
| adamw | tflink: your diddlin' time is your own | 16:04 |
| * akshayvyas listening | 16:04 | |
| akshayvyas | what | 16:04 |
| akshayvyas | sorry | 16:04 |
| akshayvyas | i am here | 16:04 |
| * dan408_ is somewhat here | 16:04 | |
| adamw | big group | 16:05 |
| * adamw invokes more chairs | 16:05 | |
| * tflink runs | 16:05 | |
| * dan408_ throws chair at tflink | 16:05 | |
| tflink | too late, I already ran :) | 16:06 |
| adamw | wow, he's psychic | 16:06 |
| adamw | alrighty | 16:06 |
| * tflink hides in case of another chair | 16:06 | |
| adamw | #topic previous meeting follow-up | 16:06 |
| adamw | and dan ballmer, quit it ;) | 16:06 |
| dan408_ | ballmer?!?! | 16:06 |
| dan408_ | wtf! | 16:06 |
| adamw | hey, you start throwing chairs, you get called ballmer | 16:07 |
| tflink | you never saw the video of him throwing a chair? | 16:07 |
| dan408_ | no | 16:07 |
| dan408_ | links or gtfo | 16:07 |
| * adamw wonders if they switched out all the furniture in his office for bits made out of foam and stuck to the floor before they released win8 | 16:07 | |
| adamw | i don't think there's video of the Chair Incident is there? | 16:07 |
| adamw | it was really just hearsay. there's video of the Monkey Dance. | 16:07 |
| jreznik | chair incident? | 16:07 |
| tflink | the googles will know | 16:07 |
| adamw | oh ballmer, such a reliable source of humour | 16:07 |
| dan408_ | i guess he must be a distant cousin.. i threw a chair at rbergeron in another meeting | 16:07 |
| adamw | well now we know who we SHOULD have sent to the secure boot negotiations... | 16:08 |
| adamw | dan408: http://www.theregister.co.uk/2005/09/05/chair_chucking/ | 16:08 |
| dan408_ | oh i would throw a lot more than a chair at ballmer | 16:08 |
| adamw | alrighty! | 16:08 |
| adamw | i left 'previous meeting follow-up' on the agenda though i think there were no action items from the last meeting | 16:09 |
| dan408_ | wow okay | 16:09 |
| adamw | anything to follow up on that wasn't action'ed? | 16:09 |
| tflink | has the partitioning stuff been done? | 16:09 |
| jreznik | adamw: lol (for that chair article!) | 16:09 |
| * tflink doesn't remember off hand | 16:09 | |
| adamw | tflink: the criteria? no. please stop remembering i'm supposed to be doing that. :) | 16:10 |
| dan408_ | adamw: dont know if this was brought to your attention but there is bug with systemd | 16:10 |
| dan408_ | let me see if i can find it | 16:10 |
| adamw | dan408: we'll get to f18 in a minute | 16:10 |
| dan408_ | oh ok | 16:10 |
| adamw | tflink: i was attempting to quietly slip that one off the agenda, curse you | 16:10 |
| dan408_ | LOL | 16:11 |
| adamw | so anything apart from my deep and ongoing shame to discuss at this point? :P | 16:11 |
| tflink | for followup? Nothing I can think of, no | 16:11 |
| adamw | alrighty, moving on | 16:12 |
| * tflink still needs to finish test cases etc. for fedup but that's never been an action item | 16:12 | |
| tflink | in a meeting | 16:12 |
| adamw | #topic Fedora 18 Beta status / mini blocker review | 16:12 |
| adamw | shall we knock off the blocker review first? | 16:12 |
| * jreznik is ok with that | 16:12 | |
| akshayvyas | sure | 16:13 |
| adamw | #chair tflink | 16:13 |
| zodbot | Current chairs: adamw tflink | 16:13 |
| adamw | you ready to roll? | 16:13 |
| tflink | up for review today, we have: | 16:14 |
| tflink | #info 4 Proposed Blockers | 16:14 |
| tflink | #info 3 Proposed NTH | 16:14 |
| tflink | #topic (876789) FormatDestroyError: error wiping old signatures from /dev/md/Volume0_0p2: 1 | 16:14 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=876789 | 16:14 |
| tflink | #info Proposed Blocker, anaconda, NEW | 16:14 |
| adamw | so this is the latest bug in my odyssey of an attempt to try and get a working Intel fw RAID-1 install | 16:15 |
| tflink | workaround: don't use raid? | 16:15 |
| tflink | :) | 16:15 |
| jreznik | adamw: well, I spent the morning with Jes - he was able to install on intel raid... | 16:15 |
| adamw | well, schyeah | 16:15 |
| adamw | yeah i was just about to note that | 16:16 |
| adamw | if Jes is able to do an install now, we might call this fixed-enough-for-beta | 16:16 |
| nirik | tflink: don't use fakeraid anyhow. ;) | 16:16 |
| * tflink just finished a smoke build with this anaconda | 16:16 | |
| adamw | jreznik: and thanks for that | 16:16 |
| dan408_ | move it to a f19 NTH | 16:16 |
| tflink | there is no raid like fakeraid ... | 16:16 |
| jreznik | adamw: follow the sun policy to rule all the bugs out :D as our GSS does :) | 16:17 |
| adamw | jreznik: as long as you can find one person it works for, it's fine? :) | 16:17 |
| nirik | so whats the difference between his setup and adamw's? | 16:17 |
| adamw | nirik: no idea | 16:17 |
| jwb | it works? | 16:17 |
| jreznik | nirik: that's the question | 16:17 |
| adamw | ba-dum tish | 16:17 |
| adamw | jwb will be appearing all week, tip your server | 16:18 |
| dan408_ | omg | 16:18 |
| jreznik | in adam's case, wipefs -a /dev/md/Volume0_0 is called, in Jes case wipefs -a /dev/md/IMSM00_0p3 | 16:18 |
| nirik | huh. might be firmware version? | 16:18 |
| adamw | eh? no, that's not right. | 16:18 |
| adamw | in my case it's /dev/md/Volume0_0p2 | 16:19 |
| adamw | which is effectively more or less the same thing, just my array is called Volume0 and Jes' is IMSM00 . | 16:19 |
| adamw | that's just a function of the RAID BIOS. mine lets me change the name if I want. I could call it RAIDSUCKS and have RAIDSUCKS_0p2... | 16:19 |
| nirik | whats the beta critera? all raid ? | 16:20 |
| jreznik | in log, I see Volume0_0 | 16:20 |
| adamw | 19:16:48,018 INFO program: Running... wipefs -a /dev/md/Volume0_0p2 | 16:20 |
| adamw | 19:16:48,026 ERR program: wipefs: error: /dev/md/Volume0_0p2: probing initialization failed: Device or resource busy | 16:20 |
| adamw | that's my log. | 16:20 |
| jreznik | ah, both | 16:20 |
| jreznik | and it fails on the second, ok | 16:20 |
| * jreznik just got confused... | 16:20 | |
| dan408_ | could just be a bug in the package itself | 16:20 |
| tflink | nirik: it's written as all RAID but in practice, we don't block for everything | 16:20 |
| nirik | "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot" | 16:21 |
| adamw | well, it's written thus: "The installer must be able to create and install to software, hardware or BIOS RAID-0, RAID-1 or RAID-5 partitions for anything except /boot " | 16:21 |
| adamw | yeah | 16:21 |
| adamw | historically we've interpreted that 'capable' quite generously | 16:21 |
| adamw | pretty much 'as long as it works for someone it's okay' | 16:21 |
| nirik | yeah. | 16:21 |
| jreznik | at least we have a report, someone is able to do the install... so we do not know why it does not work for adamw and if it's only adamw's issue (and how many people do want to install on intel hw raid?) | 16:21 |
| tflink | it would be nice to have more than 2 data points, though | 16:21 |
| adamw | sigh. 'able', not 'capable'. /me goes back to bed | 16:21 |
| nirik | I'd be ok with punting this to NTH given that it worked for another person and failing more datapoints. | 16:21 |
| adamw | jreznik: it's probably one of the most common forms of RAID, but i'm with nirik - NTH for now | 16:22 |
| jreznik | ok | 16:22 |
| dan408_ | adamw: i can do a test again at work for you today if you want | 16:22 |
| akshayvyas | NTH for final?? | 16:22 |
| adamw | jreznik: the fact it's not trying to do /dev/IMSM00_0 for jes to me suggests that maybe he did an install without wiping the entire array? did he install alongside something else? | 16:22 |
| adamw | akshayvyas: no, it'd be NTH for beta. | 16:23 |
| nirik | no, NTH for beta | 16:23 |
| * nirik has lag today. :) | 16:23 | |
| adamw | dan408: yeah that'd probably be neat | 16:23 |
| adamw | thanks | 16:23 |
| nirik | ie, if a fix falls from the sky we can look at pulling it in, or... not. | 16:23 |
| adamw | dan408: just grab tc9 and try installing to RAID-1 (or hell, RAID-5 or whatever) | 16:23 |
| tflink | the working install was with TC9? | 16:23 |
| * jreznik is pinging Jes | 16:23 | |
| dan408_ | adamw: right but software raid | 16:24 |
| dan408_ | not hardware | 16:24 |
| dan408_ | right? | 16:24 |
| adamw | dan408: intel firmware | 16:24 |
| adamw | if you have it | 16:24 |
| dan408_ | um | 16:24 |
| adamw | actual pure linux softraid seems okay here, i tested that | 16:24 |
| dan408_ | the hardware raid i tested was Dell SAS 6/ir | 16:24 |
| dan408_ | finding intel raid will be tough | 16:24 |
| adamw | no problem then | 16:25 |
| adamw | so is anyone against -1 blocker / +1 nth? | 16:25 |
| dan408_ | no | 16:25 |
| jreznik | well, I'm +1 nth | 16:25 |
| dan408_ | -1 blocker | 16:25 |
| akshayvyas | +1 nth | 16:25 |
| tflink | the only thing I can think of is to wait until wednesday to demote from blocker | 16:25 |
| dan408_ | hardware raid is tested and it works | 16:25 |
| brunowolff | If this is tied to specific hardware, don't we want to consider how common this hardware is? | 16:25 |
| brunowolff | Perhaps relative to other fakeraid hardware people might be using. | 16:25 |
| dan408_ | brunowolff: extremely uncommon | 16:25 |
| adamw | er, that might be overstating it | 16:26 |
| dan408_ | okay | 16:26 |
| adamw | if you have raid on your motherboard these days it's likely intel | 16:26 |
| dan408_ | somewhat uncommon | 16:26 |
| dan408_ | wrong | 16:26 |
| tflink | AFAIK, this is the most common BIOS raid right now or one of the more common ones anyways | 16:26 |
| adamw | but right now, we don't know how many work and how many don't. | 16:26 |
| dan408_ | all Dell servers use Dell raid | 16:26 |
| tflink | dan408_: most of my machines have some form of intel BIOS raid, I don't see how it's uncommon | 16:26 |
| adamw | dan408: sorry, i was thinking consumer hw, you might be right about server. | 16:26 |
| tflink | for desktops, not servers | 16:26 |
| dan408_ | so you'd have to have an intel made motherboard with raid | 16:26 |
| dan408_ | yeah | 16:27 |
| dan408_ | desktops | 16:27 |
| adamw | dan408: not intel made, just pretty much any consumer board for intel | 16:27 |
| dan408_ | and how many people install to hardware raid on an intel desktop? | 16:27 |
| adamw | mine's Asus. | 16:27 |
| tflink | dan408_: a mobo w/ intel chipset and SB, not just intel made | 16:27 |
| dan408_ | right | 16:27 |
| adamw | we have no idea, really. smolt doesn't track that. | 16:27 |
| dan408_ | that's what i just said | 16:27 |
| dan408_ | im telling you it's very uncommon | 16:27 |
| dan408_ | and it's an intel problem | 16:27 |
| dan408_ | -1 blocker +1 nth | 16:28 |
| tflink | dan408_: all of my recent intel machines have intel bios RAID, how is that uncommon | 16:28 |
| brunowolff | But since fakeraid is supposed to work, we might really want to know what fraction of fakeraid setups fail rather than what fraction of desktop users are affected. | 16:28 |
| tflink | the only one that doesn't is a 10 year old P4 box | 16:28 |
| adamw | guys, we're nearly at 30 mins already | 16:28 |
| dan408_ | tflink: and how often do you use it | 16:28 |
| tflink | sorry | 16:28 |
| adamw | if no-one wants to make this a blocker, let's just move on | 16:28 |
| tflink | are we rejecting blocker? | 16:29 |
| adamw | brunowolff: right, but we just don't have data for that, is the problem - not many people are set up to test it | 16:29 |
| dan408_ | ^which means it's an uncommon setup | 16:29 |
| adamw | brunowolff: right now we have one pass one fail, so it's 50/50 =) | 16:29 |
| adamw | dan408: well not necessarily, because if you're using it _in production_, you'd need two spare drives and the willingness to fiddle about disconnecting them in order to _test_ it. which is what i have to do and it drives me nuts., | 16:29 |
| brunowolff | My inclination is NTH and not blocker without a better idea of the impact on fakeraid testing. | 16:30 |
| dan408_ | if you're using it in "production" you're using a server | 16:30 |
| adamw | but anyway, we're just kicking the can now. | 16:30 |
| * tflink will try to get a test done today | 16:30 | |
| dan408_ | if you're using a server you're most likely not using intel raid | 16:30 |
| adamw | dan408: i mean, if you're using it for your everyday usage | 16:30 |
| dan408_ | okay | 16:30 |
| dan408_ | let's move on | 16:30 |
| adamw | yeah, i don't see anyone voting anything but +NTH -blocker. | 16:30 |
| tflink | I'm wondering about doing it today but yeah | 16:31 |
| adamw | we can always revisit. | 16:31 |
| jreznik | yep | 16:31 |
| adamw | fwiw, i know dlehman was leaning in that direction too. | 16:31 |
| jreznik | ok, proposal! | 16:31 |
| tflink | proposed #agreed 876789 - RejectedBlocker - This doesn't seem to affect all intel FWRAID installs and thus, not severe enough to be a blocker. If it turns out to be more severe, please repropose | 16:32 |
| dan408_ | +1 | 16:32 |
| akshayvyas | ack | 16:32 |
| adamw | patch acceptednth | 16:32 |
| brunowolff | ack | 16:32 |
| dan408_ | ack | 16:32 |
| nirik | ack | 16:32 |
| jreznik | patch, see adamw | 16:32 |
| tflink | adamw: it's already accepted NTH | 16:32 |
| adamw | oh, it is? | 16:32 |
| adamw | i don't see that. | 16:33 |
| tflink | damn it, I'm looking at the wrong bug somehow | 16:33 |
| jreznik | tflink: on, it isn't | 16:33 |
| adamw | heh. | 16:33 |
| jreznik | s/on/no :) | 16:33 |
| * dan408_ throws a chair at adamw | 16:34 | |
| tflink | proposed #agreed 876789 - RejectedBlocker, AcceptedNTH - This doesn't seem to affect all intel FWRAID installs and thus, not severe enough to be a blocker. If it turns out to be more severe, please repropose as a blocker. Accepted as NTH because it can't be fixed with an update and is currently affecting 50% of intel FWRAID installs. | 16:34 |
| * adamw catches chair, throws it back | 16:34 | |
| adamw | ack | 16:34 |
| jreznik | ack | 16:34 |
| adamw | heh, '50%' :) | 16:34 |
| tflink | 1 of 2 is 50% | 16:34 |
| adamw | technically true! | 16:35 |
| tflink | proposed #agreed 876789 - RejectedBlocker, AcceptedNTH - This doesn't seem to affect all intel FWRAID installs and thus, not severe enough to be a blocker. If it turns out to be more severe, please repropose as a blocker. Accepted as NTH because it can't be fixed with an update and is currently affecting 50% of reported intel FWRAID installs. | 16:35 |
| brunowolff | ack | 16:35 |
| jreznik | all two intel hw raid users :) | 16:35 |
| tflink | #agreed 876789 - RejectedBlocker, AcceptedNTH - This doesn't seem to affect all intel FWRAID installs and thus, not severe enough to be a blocker. If it turns out to be more severe, please repropose as a blocker. Accepted as NTH because it can't be fixed with an update and is currently affecting 50% of reported intel FWRAID installs. | 16:35 |
| dan408_ | sigh | 16:35 |
| tflink | #topic (875278) AttributeError: 'NoneType' object has no attribute 'type' | 16:35 |
| adamw | jreznik: testers. | 16:35 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=875278 | 16:35 |
| tflink | #info Proposed Blocker, anaconda, ON_QA | 16:35 |
| jreznik | adamw: developer and tester :) | 16:35 |
| dan408_ | this is fixed i believe | 16:36 |
| kparal | already accepted as NTH, do we need to discuss blocker atm? | 16:37 |
| tflink | we could skip it for now, sure | 16:37 |
| tflink | any other thoughts? | 16:38 |
| dan408_ | skip | 16:38 |
| adamw | yeah, since it's nth and the fix is in the new anaconda build, just move on | 16:38 |
| tflink | #info this has been accepted as NTH and a fix is in the most recent anaconda build - skipping review for today | 16:39 |
| tflink | #topic (877623) fedup does not seem to verify the update source | 16:39 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=877623 | 16:39 |
| tflink | #info Proposed Blocker, fedup, NEW | 16:39 |
| tflink | I didn' | 16:39 |
| tflink | t realize this was proposed as a blocker | 16:39 |
| adamw | surprise! | 16:39 |
| * tflink isn't sure it's valid, much less a blocker | 16:39 | |
| adamw | not checking signatures is kinda bad. | 16:40 |
| adamw | we only accept that for the DVD installer on the basis that the DVD as a whole is signed. | 16:40 |
| nirik | the only way I could see this being a blocking is a pretty broad reading of "The upgraded system must meet all release criteria." | 16:40 |
| dan408_ | it's fedup with signatures | 16:40 |
| adamw | nirik: heh, i hereby award you a black belt in criteria judo | 16:40 |
| dan408_ | /fedup joke of the day | 16:40 |
| * adamw wipes away tear | 16:40 | |
| adamw | he's grown...so much | 16:40 |
| tflink | who ever said it isn't checking signatures? | 16:41 |
| dan408_ | hahaha | 16:41 |
| nirik | :) | 16:41 |
| adamw | "Also the code does not show any sign of proper cryptographic verification of updates." | 16:41 |
| nirik | tflink: the code did. ;) | 16:41 |
| tflink | that's the assertion, sure | 16:41 |
| tflink | I don't buy it, though | 16:41 |
| * tflink has seen the code | 16:41 | |
| adamw | well yeah. i'm taking the face of the report. | 16:41 |
| nirik | # TODO check signatures of downloaded packages | 16:41 |
| adamw | if you or will said 'no, you're wrong, it DOES check signatures and here's the code', it'd be pretty much a non-issue. | 16:41 |
| tflink | I can double check or we can ask will but I'm pretty sure that yum checks the sha256 in the background before downloading stuff | 16:41 |
| nirik | https://github.com/wgwoods/fedup/blob/master/fedup/download.py | 16:41 |
| jreznik | wwoods: ping, are you around? | 16:42 |
| adamw | this might be a case for our newly-minted final criterion, since this is clearly a security issue. | 16:42 |
| tflink | yeah, it is checking | 16:42 |
| nirik | tflink: oh? where? | 16:42 |
| tflink | line 223 | 16:42 |
| tflink | urlgrab is checking transparently | 16:42 |
| nirik | those are the images? not the packages? | 16:43 |
| * nirik re-reads the bug, perhaps I misunderstood which it was about | 16:43 | |
| tflink | yeah, those are the initramfs and vmlinuz | 16:43 |
| adamw | the report is about checking the *packages*, i believe. | 16:43 |
| tflink | I thought it was about the images | 16:44 |
| adamw | "Therefore it seems that it is prone to man-in-the-middle attacks or maybe allows to install packages from compromised mirrors without any verification" | 16:44 |
| tflink | since the complaint is about my side repo | 16:44 |
| nirik | I think they are kinda mixing the two... | 16:44 |
| tflink | doesn't yum do checksums by default? | 16:44 |
| adamw | yeah, i don't think it's a great report, but it seems kinda the case that if it's not checking signatures of packages before installing them, that's bad. there's a reason we sign them and yum checks the signatures. | 16:44 |
| adamw | yum checks GPG signatures by default, but i've no idea if that happens in fedup. | 16:45 |
| tflink | fedup uses yum | 16:45 |
| nirik | I think it is checking the size or something, but not the gpg sig for sure. | 16:45 |
| tflink | punt for more info? | 16:45 |
| adamw | yeah, i was gonna say that. | 16:45 |
| adamw | 1) ask till to clarify exactly what he thinks ought to be signed/checked, 2) ask will what is being signed/checked. | 16:45 |
| jreznik | so called tillwill bug :) | 16:46 |
| tflink | proposed #agreed 877623 - This needs more investigation before deciding on blocker status - what does the reporter think should be signed? Are the packages installed during upgrade checked before install? | 16:46 |
| nirik | sure, ack | 16:46 |
| jreznik | ack | 16:46 |
| tflink | anyone else? | 16:47 |
| adamw | ack | 16:48 |
| tflink | #agreed 877623 - This needs more investigation before deciding on blocker status - what does the reporter think should be signed? Are the packages installed during upgrade checked before install? | 16:48 |
| tflink | #topic (877567) Very weird bug gzip decompression bug in "recent" libxml2 versions | 16:48 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=877567 | 16:48 |
| tflink | #info Proposed Blocker, libxml2, ASSIGNED | 16:48 |
| tflink | +1 blocker | 16:49 |
| tflink | since it messes with releng processes | 16:49 |
| nirik | yeah, it's a weird one. | 16:50 |
| nirik | +1 blocker here too. | 16:50 |
| jreznik | another one from adamw in the bug | 16:50 |
| * nirik spent much of friday with geppetto doing the heavy lifting tracking this one down. | 16:50 | |
| jreznik | and sure, it's +1 blocker | 16:51 |
| jreznik | nirik: with DV we came with that ugly hack - not checking CRC/len but ... | 16:51 |
| adamw | yeah, seems an obv +1. | 16:51 |
| nirik | also, it only seems to happen on that repo, so when we push something more to stable it might change... | 16:51 |
| tflink | proposed #agreed 877567 - AcceptedBlocker - This prevents F18 composes and literally blocks release - therefore it is accepted as a blocker for F18 beta. | 16:51 |
| nirik | ack | 16:52 |
| kparal | ack | 16:52 |
| mkrizek | ack | 16:52 |
| tflink | #agreed 877567 - AcceptedBlocker - This prevents F18 composes and literally blocks release - therefore it is accepted as a blocker for F18 beta. | 16:52 |
| tflink | #topic (877576) Dutch translation for anaconda is Polish | 16:52 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=877576 | 16:52 |
| tflink | #info Proposed NTH, anaconda, NEW | 16:52 |
| jreznik | nirik: well, so is this reproducible? or just broken for this one? | 16:52 |
| nirik | yes, it's happening every day right now, preventing branched from composing. | 16:53 |
| tflink | wow, this has been mixed up since january 2011? | 16:53 |
| adamw | haha. dutch, polish, what's the difference amirite? | 16:53 |
| kparal | we're in the NTH ones now | 16:53 |
| tflink | dutch, polish ... it's all greek to me :) | 16:53 |
| adamw | eh, there's only 3, we may as well power through em | 16:54 |
| adamw | +1 nth | 16:54 |
| tflink | +1 nth | 16:54 |
| jreznik | +1 nth | 16:54 |
| kparal | +1 nth | 16:54 |
| tflink | proposed #agreed 877576 - AcceptedNTH - This is not fixable with an update and makes it harder to install using dutch localization. A tested fix would be accepted after freeze. | 16:54 |
| adamw | ack | 16:55 |
| jreznik | ack | 16:55 |
| mkrizek | ack | 16:56 |
| tflink | #agreed 877576 - AcceptedNTH - This is not fixable with an update and makes it harder to install using dutch localization. A tested fix would be accepted after freeze. | 16:56 |
| adamw | 874753 has already been discussed and stalemate, so do the gnome one? | 16:57 |
| tflink | either way, I think there is enough info in 874753 to break stalemate | 16:57 |
| adamw | okay. | 16:57 |
| tflink | #topic (874753) Can't change keyboard layout in GDM by default | 16:58 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=874753 | 16:58 |
| tflink | #info Proposed NTH, control-center, NEW | 16:58 |
| adamw | -1 for me. this is basically working as intended. it may not be a great design, but we shouldn't twiddle with it as nth. | 16:58 |
| kparal | -1 | 16:59 |
| tflink | proposed #agreed 874573 - RejectedNTH - This only affects keymaps added post-install and while it is inconvenient, could be fixed with an update. | 16:59 |
| tflink | -1 | 16:59 |
| adamw | ack | 16:59 |
| kparal | ack | 16:59 |
| jreznik | ack | 16:59 |
| dan408_ | ack | 16:59 |
| adamw | oh yeah, that too. | 16:59 |
| nirik | ack | 16:59 |
| tflink | #agreed 874573 - RejectedNTH - This only affects keymaps added post-install and while it is inconvenient, could be fixed with an update. | 16:59 |
| tflink | #topic (876922) GNOME 3.6.2 as NTH for F18 Beta | 16:59 |
| tflink | #link https://bugzilla.redhat.com/show_bug.cgi?id=876922 | 16:59 |
| tflink | #info Proposed NTH, distribution, NEW | 16:59 |
| dan408_ | +1 | 17:00 |
| tflink | oy, not so sure about this one | 17:00 |
| adamw | what karma do we have? | 17:00 |
| tflink | when was it submitted for testing? | 17:01 |
| * nirik was just going to check that | 17:01 | |
| adamw | 11-14 | 17:01 |
| jreznik | it could be huge... | 17:01 |
| adamw | has +5 karma, only one -1 which was a bogus report | 17:01 |
| nirik | it has +5 karma | 17:01 |
| nirik | yeah | 17:01 |
| tflink | one day of testing? | 17:01 |
| adamw | eh? | 17:01 |
| adamw | five days | 17:01 |
| tflink | nevermind | 17:01 |
| * adamw hands tflink a calendar | 17:01 | |
| tflink | I can't count this morning, apparently | 17:01 |
| adamw | we could do smoke builds to check for dependency issues etc | 17:02 |
| adamw | i vote +1 contingent on we do test DVD and live first to make sure compose works and is dep complete | 17:02 |
| adamw | if that looks okay, go ahead with pulling to main | 17:02 |
| * nirik is ok with that too. | 17:02 | |
| dan408_ | offtopic: there is an issue with gnome/systemd that i am thinking of proposing as NTH | 17:02 |
| adamw | it's a bugfix release | 17:02 |
| nirik | we should do so asap tho, so we could pull it in the rc1 | 17:03 |
| adamw | yeah, we could do that today. i can do a live, tflink can do a dvd. | 17:03 |
| adamw | i wouldn't want to take a .0 at this point =) but gnome bugfix releases have a strong track record. | 17:03 |
| herlo | don't want to interrupt, but if you are here for the FAmSCo meeting right now, we are meeting in #fedora-meeting-2. | 17:03 |
| adamw | sorry herlo, we're nearly done | 17:03 |
| herlo | adamw: no worries, we're moved | 17:03 |
| jreznik | if testing would go ok, I'm ok too, a little bit scared from this one but... | 17:03 |
| tflink | proposed #agreed 876922 - This will be accepted as NTH pending a test of Lives and DVD with the new GNOME builds. If there are no apparent issues, this would be taken past freeze. | 17:04 |
| adamw | ack | 17:04 |
| dan408_ | ack | 17:04 |
| brunowolff | ack | 17:04 |
| nirik | ack | 17:04 |
| tflink | #agreed 876922 - This will be accepted as NTH pending a test of Lives and DVD with the new GNOME builds. If there are no apparent issues, this would be taken past freeze. | 17:04 |
| tflink | OK, that's all of the proposed blocker/nth bugs on my list | 17:05 |
| adamw | ok | 17:05 |
| adamw | thanks tflink | 17:05 |
| adamw | #topic Fedora 18 Beta status | 17:05 |
| jreznik | tflink: any news on fedup? I don't see packages, neither reply from wwoods (are you around) to mail email... | 17:06 |
| adamw | so on general status...we now have two unaddressed blockers by my count | 17:06 |
| adamw | 876655 lorax NEW Lorax does not support building initramfs for fedup | 17:06 |
| adamw | and the libxml2 bug, though that one seems to be getting heavy attention | 17:06 |
| adamw | #info two unaddressed blockers, 876655 and 877567 | 17:07 |
| tflink | jreznik: I'm trying to get that figured out today - I'm a bit confused myself | 17:07 |
| tflink | there were EFI issues at one point but I guess those might have been addressed | 17:07 |
| tflink | I was still seeing issues with the logs being written to disk but I'm building everything from scratch again this morning and will be re-testing | 17:08 |
| * nirik hopes for fixes for those and beta in the can before the long weekend. | 17:08 | |
| * dan408_ sees no mention of systemd at all here | 17:08 | |
| adamw | dan408: what's the systemd problem? | 17:09 |
| dan408_ | .bug 869998 | 17:09 |
| zodbot | dan408_: Bug 869998 systemd-logind integration broke "Suspend when closing lid" policy - https://bugzilla.redhat.com/show_bug.cgi?id=869998 | 17:09 |
| dan408_ | please advise. im going to add this to blocker or NTH unless someone tells me otherwise | 17:10 |
| adamw | okay? that doesn't exactly seem urgent. | 17:10 |
| adamw | why the hell would it be a blocker? | 17:10 |
| tflink | I don't think this qualifies as NTH or blocker | 17:10 |
| dan408_ | it is | 17:10 |
| adamw | it's about suspending a laptop with external monitor attached. | 17:10 |
| tflink | it can be fixed with an update | 17:10 |
| adamw | and yeah. | 17:10 |
| dan408_ | final NTH? | 17:10 |
| adamw | we don't block beta for suspend _not working_, never mind desktop niceties. =) | 17:10 |
| tflink | I'd probably be -1 NTH on this for final, too | 17:10 |
| dan408_ | well i think there's a bigger issue than "Desktop niceties" | 17:11 |
| dan408_ | but okay | 17:11 |
| adamw | that'd be the appropriate place to propose it though, yeah. | 17:11 |
| adamw | seems like something that'll just get fixed normally, though. | 17:11 |
| dan408_ | what is the bug for final nth? | 17:11 |
| tflink | dan408_: if it turns out to be more severe, that's fine. we're not saying that there is no way this could ever block release or get pulled in past freeze | 17:11 |
| adamw | F18-accepted | 17:11 |
| dan408_ | k | 17:11 |
| tflink | 752665 | 17:12 |
| dan408_ | done | 17:12 |
| dan408_ | thanks | 17:12 |
| tflink | oy, i just saw the final blocker list | 17:12 |
| * tflink is scared - checks to see if he has enough PTO to disappear for the rest of F18 | 17:12 | |
| tflink | anyhow, beta status | 17:13 |
| adamw | so outside of fedup we look fairly solid | 17:13 |
| jreznik | yep, fedup scares me... | 17:13 |
| adamw | bcl says wwoods is 'alive and kicking' but apparently not responding to irc pings... | 17:13 |
| tflink | at some point, we need to figure out what we're willing to tolerate for beta | 17:14 |
| jreznik | adamw, tflink: could you please keep pinging him overnight (our overnight) | 17:14 |
| adamw | we'll try | 17:14 |
| jreznik | tflink: but are upgrades what we can tolerate or y*u*m? | 17:14 |
| adamw | tflink: well i mean i thought we were quantifying that via the blocker list. | 17:15 |
| * nirik suspects he will answer when he can... ping -f can be anoying. | 17:15 | |
| adamw | so far as i'm concerned we tolerate anything that's not on the blocker list. | 17:15 |
| tflink | are no logs from upgrade a blocker? | 17:15 |
| tflink | what about no output from the upgrade process during upgrade? | 17:15 |
| adamw | nirik: trying to roll a release that's a month and a half late without much response from the maintainer of the thing which is delaying it is also annoying :) | 17:15 |
| nirik | sure. | 17:16 |
| jreznik | nirik: yep but at least status would be great, like... | 17:16 |
| * tflink is a bit fuzzy on what the minimum functionality is | 17:16 | |
| nirik | tflink: I'd say no, as long as it works. ;) | 17:16 |
| adamw | it's not well defined, really. | 17:16 |
| adamw | i'd say logs not a problem, output maybe | 17:16 |
| tflink | nirik: define works | 17:16 |
| tflink | :-D | 17:16 |
| adamw | at least just a screen saying U CAN HAZ UPGRADE JUST WAIT would be nice. | 17:16 |
| nirik | tflink: shall I quote the beta critera line? ;) But sure... | 17:17 |
| tflink | I'm going to go through the current fixes today and see where we are | 17:17 |
| adamw | #info current fedup status not terribly clear, minimum acceptable functionality has not yet been solidly defined | 17:17 |
| jreznik | tflink: thanks | 17:17 |
| tflink | at the very least, we're still missing builds for fedup-dracut and lorax | 17:17 |
| jreznik | that's the main concern... | 17:18 |
| tflink | the last I heard, will was working on altering lorax such that plymouth showed the correct theme | 17:18 |
| adamw | #info at the very least, we're still missing builds for fedup-dracut and lorax | 17:18 |
| tflink | but that was sometime friday afternoon | 17:18 |
| * jreznik is not sure it makes sense to waste time with theming... at least in the current state | 17:18 | |
| tflink | and I don't pretend to know about everything he's working on :) | 17:18 |
| nirik | so, lorax, libxml2 and fedup-dracut possibly... | 17:18 |
| nirik | then we might be able to make a rc1. whee. | 17:18 |
| tflink | there was some systemd in there, too according to one of the bug reports | 17:19 |
| adamw | jreznik: i think 'theme' is closely related to 'status display' when it comes to plymouth. | 17:19 |
| jreznik | adamw: ok | 17:19 |
| tflink | eh, plymouth/systemd/something seems to be stomping on the status output either way | 17:19 |
| jreznik | tflink: bz? | 17:19 |
| tflink | jreznik: https://bugzilla.redhat.com/show_bug.cgi?id=873144 | 17:20 |
| jreznik | thx | 17:20 |
| jreznik | nirik: for libxml2 - could be an option for relengs to use DV's patch (no CRC/len) check? | 17:21 |
| adamw | tflink: for things like this that are 'define minimum acceptable functionality' things we should probably put them on the blocker list | 17:22 |
| nirik | jreznik: that was a patch to createrepo? or ? /me looks | 17:22 |
| tflink | adamw: ok, I'll propose the ones I know of to get the conversation started | 17:22 |
| jreznik | nirik: libxml2 | 17:22 |
| tflink | and file a new one for EFI if that doesn't work for me :-/ | 17:23 |
| nirik | jreznik: composes are done in a mock chroot. So, we would need to patch and push libxml2 to stable? | 17:23 |
| jreznik | nirik: it's at least dirty and ugly workaround... | 17:23 |
| jreznik | the footer is not generated properly | 17:23 |
| adamw | okay, so i think we have a broad picture of where we are | 17:24 |
| adamw | any other pressing f18 business before we move on? | 17:25 |
| tflink | making it work? | 17:25 |
| nirik | jreznik: sure, if nothing else we could do that if libxml2 maintainer is ok with dropping that for not until it can get fixed. | 17:25 |
| adamw | tflink: out of scope of the qa meeting I fear :) | 17:25 |
| jreznik | nirik: DV is ok with that | 17:25 |
| tflink | adamw: awww, I was hoping someone had a magic wand or a really big stick to beat F18 into submission :-D | 17:26 |
| nirik | jreznik: ok then... can you have him push a libxml2 update for f18 for that? and we can upkarma it and pass it to stable. | 17:26 |
| adamw | #info 877567 under intensive investigation, it will be possible to 'fix' it one way or the other | 17:26 |
| adamw | #action tflink to continue to evaluate fedup status and propose significant bugs for blocker status | 17:26 |
| adamw | #info RC is now essentially blocked on fedup | 17:26 |
| adamw | moving on! | 17:26 |
| adamw | #topic Open floor | 17:26 |
| adamw | anyone have anything for open floor? | 17:27 |
| jreznik | nirik: he's sleeping now - so one option is I use my provenpackager foo :) | 17:27 |
| nirik | jreznik: sure, if you like/can. ;) | 17:27 |
| jreznik | adamw: I have one topic for open floor (or two) | 17:27 |
| adamw | jreznik: gimme a summary line? | 17:27 |
| jreznik | adamw: I was asked if we are using ON_DEV in Fedora as the plan is to get rid of this bz status | 17:28 |
| adamw | #topic Open floor - ON_DEV status in Fedora | 17:28 |
| adamw | i believe the answer is 'no'. | 17:28 |
| jreznik | looking on (seems to be oudated) https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#ON_DEV it's optional now | 17:28 |
| tflink | yeah, I don't think I've seen it used much | 17:28 |
| brunowolff | Is the createrepo issue with the Fedora 18 release composes the same as the libxml2 problem? | 17:28 |
| adamw | jreznik: that's not really outdated. at least insofar as no-one has proposed any kind of official workflow change that is not reflected in it. | 17:29 |
| adamw | in practice, everyone uses their own damn workflow anyway. | 17:29 |
| adamw | jwb: kernel team doesn't use ON_DEV does it? | 17:29 |
| nirik | brunowolff: yes | 17:29 |
| adamw | https://bugzilla.redhat.com/buglist.cgi?list_id=842356&classification=Fedora&query_format=advanced&bug_status=ON_DEV&product=Fedora indicates that, recently, tfujiwara and dan are the only ones using it. | 17:30 |
| jreznik | adamw: so, sorry not outdated but with nearly no triaging done... (as that offical triage) | 17:30 |
| adamw | dan408: would you be terribly sad to see ON_DEV die? | 17:30 |
| jreznik | adamw: the main idea behind is that nearly all other products got rid of it and it's confusing state now (out of workflow) | 17:30 |
| adamw | jreznik: i've never really seen it used as a matter of course in fedora. i'd just check in with Dan and fujiwara if they're okay with losing it and if they're okay with it, it's fine, i think. | 17:31 |
| adamw | #info ON_DEV very rarely used, apparently only by dan408 and tfujiwar lately. | 17:32 |
| jreznik | adamw: ok, I can ask them - as we define it as optional and for package review it was misused (it's not defined in package review process) | 17:32 |
| adamw | propose #agreed QA as a group has no objection to dropping ON_DEV status | 17:32 |
| adamw | that ok with everyone? | 17:32 |
| tflink | ack | 17:32 |
| * jreznik is not QA but does not think it's really blocking thing for us (from qa, eng pov) | 17:33 | |
| tflink | looks like we lost everyone else ) | 17:33 |
| * jreznik is still here | 17:33 | |
| adamw | eh, good enough for government work. | 17:33 |
| adamw | #agreed QA as a group has no objection to dropping ON_DEV status | 17:33 |
| jreznik | thanks | 17:33 |
| jreznik | I'll ask dan408_ and tfujiwar | 17:33 |
| adamw | next topic? | 17:33 |
| tflink | you should have asked for any objections instead of acks :) | 17:34 |
| jreznik | adamw: next one - go/no-go - according to current status and thanksgiving day in the us on Thursday... not sure right now | 17:34 |
| jreznik | we already somehow discussed it last week... | 17:34 |
| * nirik is fine with most anytime. | 17:35 | |
| nirik | note that there will be a lists.fedoraproject.org outage early on the 22nd. | 17:35 |
| jreznik | Thursday means one more day if fedup moves but also it does not make sense to shoot US people to knee... | 17:35 |
| adamw | #topic Open floor - go/no-go date | 17:36 |
| dan408_ | new years eve! | 17:36 |
| adamw | personally i don't care about thursday as we got thanksgiving out of the way last month :) | 17:36 |
| adamw | dan408: heh, sounds like the most realistic proposal | 17:36 |
| dan408_ | i was 100% serious too | 17:36 |
| dan408_ | ok 75% | 17:36 |
| * tflink doesn't much care, personally | 17:36 | |
| adamw | given the status of fedup i think we might have trouble making it by wed, but that's just an educated guess | 17:36 |
| adamw | just feels like the wed/thu distinction could actually matter this week | 17:37 |
| tflink | that wouldn't surprise me | 17:37 |
| tflink | I' | 17:37 |
| tflink | I'd be nervous about taking the lorax build w/o more testing | 17:37 |
| dan408_ | can we please unfreeze beta? | 17:37 |
| jreznik | adamw: ok, then Thursday if tflink and nirik will be around... /me really does not know how thanksgiving day looks like :) | 17:37 |
| adamw | dan408: that's not happening. | 17:38 |
| tflink | I'd rather not be around since thursday and friday are US holidays | 17:38 |
| adamw | i'll be around thu | 17:38 |
| adamw | we really only need one person from qa for go/no-go itself as the decision is programmatic | 17:38 |
| dan408_ | k | 17:39 |
| dan408_ | ill be happy to type no go on thursday for you adamw | 17:39 |
| jreznik | the main thing is - if we would be able to find some devs - mostly anaconda ones... but at least I can ask Brno Anaconda guys to be around | 17:39 |
| dan408_ | oh | 17:40 |
| dan408_ | btw i missed the last topic | 17:40 |
| dan408_ | I object to getting rid of on_dev | 17:40 |
| adamw | #info Thursday is thanksgiving in the U.S., but we may need the extra day (wed vs. thu) to have a chance at being ready | 17:40 |
| dan408_ | rename it to pending_upstream or something | 17:40 |
| adamw | dan408: ok, talk with jreznik about it | 17:40 |
| dan408_ | yep | 17:40 |
| dan408_ | just stating it publically | 17:41 |
| adamw | fair enough | 17:41 |
| adamw | #info dan408 is against dropping ON_DEV | 17:41 |
| tflink | I don't know if it matters, but friday is also a holiday for most of the US | 17:41 |
| tflink | well, not a holiday but generally grouped in with thanksgiving | 17:41 |
| dan408_ | thank you adamw | 17:41 |
| nirik | there is a UPSTREAM already. | 17:43 |
| tflink | anything else about this topic? | 17:45 |
| jreznik | well, I'll schedule it to Thursday as we really need that day and if adamw is going to be around, we need nirik to push the button and he seems to be at least available to do this... | 17:45 |
| adamw | i think not, leave it to jreznik to schedule | 17:45 |
| adamw | ok thanks | 17:46 |
| adamw | any more topics?> | 17:46 |
| adamw | #topic Open floor | 17:46 |
| dan408_ | nirik: that is for closed bugs;. | 17:46 |
| nirik | dan408_: right. | 17:46 |
| dan408_ | and used for something completely different than ON_DEV | 17:47 |
| nirik | so you want something for 'upstream is working on this, and we will pull it/fix it when they are done, so it's in progress' ? | 17:47 |
| dan408_ | yes please | 17:47 |
| * nirik just uses ASSIGNED | 17:48 | |
| jreznik | or keyword is (probably) cheap... | 17:48 |
| dan408_ | .bug 868472 | 17:48 |
| zodbot | dan408_: Bug 868472 [abrt] mate-file-manager-1.4.0-12.fc18: handle_error: Process /usr/bin/caja was killed by signal 5 (SIGTRAP) - https://bugzilla.redhat.com/show_bug.cgi?id=868472 | 17:49 |
| adamw | that wasn't really what ON_DEV was for anyway, but hey. | 17:49 |
| dan408_ | ON_DEV was usefull for this bug | 17:49 |
| dan408_ | and when you are sorting through 68 bugs in your my bugs | 17:49 |
| jreznik | using ON_DEV is abusing of initial intention of this status and nobody would understand it at all... | 17:49 |
| dan408_ | on_dev provided a good distinction between stuff i need to work on and stuff that i can't do anything about right now | 17:49 |
| adamw | can we end this now? :) | 17:52 |
| dan408_ | please | 17:53 |
| * dan408_ is off to work | 17:53 | |
| jreznik | well, I think we agreed with dan408_ in PM that he's ok with getting rid of ON_DEV, keyword seems to be a way how to track it for him... | 17:53 |
| dan408_ | thanks jreznik | 17:53 |
| jreznik | dan408_: thanks too! | 17:53 |
| adamw | ok, setting fuse for X minutes | 17:53 |
| jreznik | adamw: do you need a ticket for ON_DEV or meeting agreement is ok for you? | 17:54 |
| jreznik | and it also means action item to fix the workflow page | 17:54 |
| adamw | jreznik: can you just do an ML post? | 17:54 |
| dan408_ | let's track it with a ticket | 17:55 |
| dan408_ | jreznik can do it ;) | 17:55 |
| dan408_ | i will switch all my bugs from on_Dev to assigned | 17:55 |
| dan408_ | bbl | 17:56 |
| adamw | #endmeeting | 17:57 |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!