bpeppletopic FESCo meeting -- Init process
--- bpepple has changed the topic to: FESCo meeting -- Init process
hughsiecan somebody please ping me when you need me, thanks.
bpeppleFESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod
Hi everybody; who's around?
hughsie: will do.
* nirik is heree.
sharkcz here
nirikhere even
* dgilmore needs to leave in 20 minutes
deepthotDave W here for liblvm
* j-rod here
* bpepple waits another couple of minutes before starting.
bpepplealright, I see six FESCo members so we can probably get started.
.fesco 64
zodbotbpepple: #64 (liblvm - https://fedoraproject.org/wiki/Features/liblvm) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/64
bpeppledeepthot: since your here we might as well start with your feature.
bpeppleanyone have any questions for deepthot
+1 to liblvm feature.
nirikno real questions here... looks nice. +1
j-rod+1, no questions here either
bpeppleok, I see five '+1', and no objections, so we've approved the liblvm feature.
bpeppleif there are no questions, we can move on.
bpepple.fesco 28
zodbotbpepple: #28 (Stronger Hashes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/28
bpepplemitr: ping.
* mitr is here
bpepplehere's a link to the feature page: https://fedoraproject.org/wiki/Features/StrongerHashes
bpeppleok, so this feature won't allow upgrades from F9, correct?
mitrLast week we discussed the possibilities for making (yum upgrade) from F-9 work, and deferred to hear directly from Panu.
mitrPanu couldn't come tonight, here's his reply:
|Updating F9 rpm to 4.6.0 would be a completely irresponsible deed (just
the kind of thing people are complaining on fedora-devel whenever the
"updates" subject comes up). It has a wildly incompatible API and various
other incompatibilities that will break existing setups. People can be
expected to deal with such things when upgrading to a new distribution
version but not in an update to what is supposed to be a stable release.
Backporting the series of ~30 patches that make up the strong hash support
mitrto the very different codebase of 4.4.2.x is technically possible but
painful work that touches a lot of deep internals and has some API/ABI
implications too IIRC.
Going through the very non-trivial amount of work that either of the above
requires and risking the (relative ;) stability of rpm of an released
distro version, for an unsupported upgrade path, is just madness IMO. If
mitrFESCo *really* wants it, they need to find somebody else to maintain the
mitrF9 rpm.
Putting the hashes aside for a moment... the Big Issue here is the
mitrhorrible burden that preupgrade "support" brings: if preupgrade is
supposed to work across any Fedora N+2 version upgrade, it means that
*any* new rpm capabilities can only ever be deployed with a 1.5-2 year
delay (for some things backporting is feasible, for other things might be
mitrimpossible). That starts making even RHEL fast-moving in comparison.
* nirik notes this isn't about preupgrade... it should work, right? it's yum updates?
mitrPreupgrade works.
nirikbecause the f9 rpm can't grok the f11 rpms with 256hash to upgrade to them
bpepplemitr: what if we bump this feature to F12.  We wouldn't run into this upgrade problem then.
j-rodbpepple: no, because f10's rpm groks 256-bit hashes
bpepplej-rod: ah, ok.
mitrbpepple: The other parts (repodata, RPM signatures), ... are independently useful.
nirikyeah, how about moving the rpm part to f12...
but keeping the rest.
mitrIf the upgrade problem is a blocker, I'd propose moving only the filedigests part.
nottingmitr: which bit specifically is incompatible? filedigests? gpg sigs? both? neither?
mitrnotting: AFAIK filedigests only.  (RHEL5 handles signatures, so F-9 should as well)
j-rodI'm still not entirely sure why we can't just make f9 users do a two-stage upgrade if they want to go from f9 to f11 :)
* notting notes that we used to update the rpm library version in stable releases occasionally
j-rodf9 -> f9 + f10's rpm -> f11
nirikj-rod: we could. It's going to confuse/annoy/anger some people, but perhaps it's worth it.
the failure I assume would be that f9 rpm won't do anything with the f11 packages right? it doesn't mess up and partly install them or something?
j-rodsimply having to upgrade at all to keep getting updates annoys some people, so meh
mitrnirik: the new rpms have a rpmlib() dependency, so the transaction aborts before touching the disk.
nirikmitr: excellent.
* nirik is not really heavily leaning either way... a) deffer the filedigests only or b) just make people do f9->f10 if they are going that path...
nottingi would prefer a clean upgrade path for f9. but given that preupgrade will still work.... +1
nirikmitr: how hard is it to just not do the filedigests by default? just a default?
bpepple+1, I'm not terrible thrilled about the upgrade path, but if we clearly explain the steps to handle it, I can live with it.
mitrnirik: What do you mean exactly?
nirik: There's a rpm macro that determines at build time what hash will be used for filedigests.
notting(back in 5)
nirikmitr: just wondering if it requires patches being backed out or anything... yeah, macro is what I was hoping/expecting.
nirikI guess +1, but we should update the yumupdatefaq page now with info about this. ;)
sharkcz+1 with a release note about the "2 step" for "yum update" and confirmation it really works
mitrsharkcz: I have tested it, it works.
bpeppleok, I see four '+1'. dgilmore, j-rod?
sharkczmitr: thanks
j-rodsorry, wasn't quite clear what we were voting +1 for...
2-step upgrade from f9 -> f11 +1
bpepplej-rod: right.
alright, that's five '+1', so we've approved the StrongerHashes feature.
mitrThanks :)
bpepplemitr: thanks for taking the time to answer our questions.
bpepplealright, moving on....
nirikthanks mitr
bpepple.fesco 58
zodbotbpepple: #58 (AutoFontsAndMimeInstaller - http://tinyurl.com/cqjvaa) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/58
bpepplehughsie: ping.
hughsiebpepple: thanks
slick stuff
bpepplehughsie: are we going to time the rebuild with the gcc & architecture rebuild?
sharkczhughsie: the codecs installer is tied to gstreamer?
hughsiebpepple: well, for the desktop file data it just works now, a global rebuild wil make that bit just work
hughsiesharkcz: yes, but it's prefixed with gstreamer0.10()
bpepplehughsie: ok.
hughsiethe font stuff is still being worked on by behdad
bpeppledgilmore: what's your concern?
hughsieit sort of works now, but behdad is making it rock harder
sharkczhughsie: ok
mclasen_hughsie: are you sure behdad is still working on it ? afaik, he's gone for the next week
so better check with him
dgilmorebpepple: that too many peopel will not do the 2 steps
hughsiemclasen_: i sent email this morning to you, behdad and nim-nim
bpeppledgilmore: oh, is this about the stronger hashes feature?
hughsienim-nim: seems to think behdad is making this better
dgilmorebpepple: yeah sorry
* dgilmore is distracted today. and needs to run in a couple of minutes
bpeppledgilmore: np.  I thought your vote was about the hughsie's feature.
nirikdgilmore: it's only yum updates, and it won't break them, just not allow them to update...
notting+1 on fonts&mime&stuff
nirikhughsie: so what does the dialog look like if it can't find something?
bpepple+1 to fonts installer feature.
hughsienirik: it says "can't find foo" and the more info button takes you to the fedora wiki page
nirikwhich wiki page?
hughsiei'll see if i can find a screenshot
nirik+1 in any case, just curious.
hughsienirik: cat /etc/PackageKit/Vendor.conf | grep Url
depends on the distro
(i've got an upstream link)
bpeppleok, I see five '+1' to the font installer feature, so we've approved it.
hughsiesomebody patched the F10 rpm
hughsiebpepple: great, thanks
bpepple: that's the desktop file feature too, right?
hughsieaka: https://fedoraproject.org/w/uploads/3/30/Gpk-client-mime-type.png
nirikhttps://fedoraproject.org/wiki/PackageKit_Items_Not_Found in the f10 version at least.
bpepplehughsie: correct.
hughsie: thanks for taking the time to answer our questions.
hughsieno problem at all
bpeppleok, if there are no other questions, we can move on.
.fesco 59
zodbotbpepple: #59 (ControlGroupsKernel - https://fedoraproject.org/wiki/Features/ControlGroupsKernel) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/59
bpeppledidn't we push this so we could talk to the feature owner?
nirikyeah, I don't see anything on the talk page tho.
j-rodno, that was the tools portion
sharkczbpepple: there is now kernel and tools part
bpepplesince we sent out the schedule so late, most likely the owner wasn't aware it was on today's schedule.
j-rodthere's also a ControlGroupTools
er, ControlGroupsTools
bpepplej-rod: ah, ok.
nirikwhy do we need seperate features ? shouldn't it just be one? ControlGroups?
j-rodwas kinda wondering that myself
sharkczdifferent teams are working on those parts ...
j-rodand what exactly isn't done? says 75%, but also says everything listed there is already in F10
j-roder, not quite all
nirikhow about we table again, ask them to try and merge into one feature and update status?
j-rodyeah, really feels like a single feature, not two separate ones
nirikeven if it's seperate teams, they need to coordinate anyhow, why not just share a feature. ;)
bpeppleI'm fine with seeing if the owners think it makes sense to combine them into a single feature page.
j-rodyep. and obviously, if we booted the kernel side as a feature, we couldn't realistically approve the tools side
bpeppleso, any object to seeing if these two features can be merged into one?
j-rodnope, do it
bpeppledone.  moving on......
.fesco 62
zodbotbpepple: #62 (NouveauAsDefault - https://fedoraproject.org/wiki/Features/NouveauAsDefault) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/62
* j-rod has a gf6200 that doesn't work at ALL w/nv, works great w/nouveau --> approve feature
nirik+1, we can always yank it if it's breaking too much...
notting0 on the premise that i have a nvidia card that works fine with nv and dies horribly with nouveau :)
hughsie(as an aside, the nouveau guys are very quick at fixing up regressions)
sharkcz+1, I had gf6600 that worked with nouveau, but not with the blob :-)
hughsie(and if we want KMS, we can't do it with nv)
nirikif we are doing this, we should change it asap, so we can get them bugs to fix. ;)
j-rodkms and compiz and whatnot
hughsiej-rod: not compiz yet
j-rodno, not yet, but eventually
mclasen_nirik: no point in switching before its good enough
j-rodi.e., never going to happen w/nv, actually has a chance w/nouveau
mclasen_that just frustrates testers and generates needless bugs
nirikmclasen_: how do we know without switching?
hughsiemclasen_: my feeling is that we're getting 0.0001% of the new users switching to nouveau
as it means creaitng a xorg.cong
mclasen_yeah, if we want it in f11, i certainly needs to be switched before beta
hughsiemclasen_: if we switch early then we can put instructions in the release docs about how to switch back to nv, and ask people to file bugs
nottingso, this seems to be a change that would leave fedora (for better or worse) very much alone
hughsienotting: yes, but we have a nouveau developer working at red hat...
j-rodI'd wager most *buntu people using nvidia cards use the blob anyhow. :)
hughsiej-rod: and i would agree with you
bpepplej-rod: yeah, I would guess so also.
hughsieand then they fill up launchpad with random crashes
j-rodso someone send notting a nouveau developer to fix his card, then maybe we can get his +1 too...
nottingj-rod: bug's been open nearly two years :/
bpepple+1, but we need to really give this some serious QA since this has the potential to affect a lot of folks.
j-rodhrm. suck.
nottingin any case, i see 4  '+1' and 1 '0'... other votes?
sharkczprobably not as dgilmore is away now
j-rodcan't we also selectively punt just problematic classes of cards back to nv?
nottingj-rod: that gets messy in the x server for the non-xorg.conf case
j-rodthough I suppose its entirely possible cards w/the same device IDs go bonk due to vendor-specific implementation details
bpeppleok, I don't see a majority vote, so maybe we punt this to next week when we have more folks here.
* nirik nods
j-rodnotting: isn't it all device id based?
* mclasen_ will try to lure some x people here next week then
nottingwell, i'll switch my vote to +1. but i'm nervous about it being good enough
bpepplenotting: yeah, I'm nervous also.
j-rodlikewise, but there's a solid contingency
nottingj-rod: by way of a big nasty case statement, yes
bpepplebut anyway with notting's vote that gives us five '+1', so the nouveau feature has been approved.
j-rodnotting: ew.
notting(also nervous about the bus factor)
j-rod"bus factor" == pci-e vs. agp vs. pci or ______ ?
nottingno. 'number of people that have to be hit by a bus to incapacitate the featre'
bpeppleok, anything else about the nouveau feature?
j-rodjust that we suggest this one needs to be tested HARD
bpepplej-rod: strongly agree.
bpeppleok, moving on then,
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleI believe that was everything on today's schedule.
anyone have anything else they want to talk about?
* bpepple gets ready to start the countdown clock if no one speaks up.
nottingf13: where do we stand on scheduling the rebuild?
are all required rebuild-affecting features approved?
bpepplenotting: I believe all the features that needed a rebuild have been approved.
nirikdid we want to look at the qa request?
nirik.fesco 47
zodbotnirik: #47 (Documented QA Team Scope) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/47
bpepplenirik: I don't think anyone from qa is around.
nirikah, then not. ;)
bpepplelooks like f13 isn't around.  Are there any other questions?
nottingwell, does fesco have any objections to the mass rebuild starting next week, if releng wants to do so?
* notting looks at the schedule for beta....
bpeppleI've got no objections to giving releng the authority to starting rebuilds.
* nirik doesn't.
f13that exiI'm around
I was deep in wiki editing.
nirikthis is going to be 100% right? since we need the new rpm hashes even for noarch?
f13notting: that's correct
bpepplenirik: I believe that is correct.
f13this would be a 100% rebuild
what I don't know yet is
A) are gcc folks ready for the rebuild
B) is rpm ready for the larger hashes
C) is rpm ready for the fonts provides
bpepplehmm, a lot of ducks to get in order there.
f13D) are there any other things that would benifit from the full rebuild that aren't in place yet?
nirikare we going to do any change to the /i386/ in the repo paths? or leave it...
f13oh right
E) archful builds, which may require koji changes
nottingnirik: leave it
nirikok, fine by me... might confuse some people, but not a big deal.
nottingnirik: after all, it's not like we really support i386 now
mbonnetf13: I don't think we have support for larger hashes in Koji yet
f13mbonnet: koji needs changes for the larger rpm hashes?
not the gpg key stuff yet, just the rpm hashes themselves?
mbonnetf13: yes
f13oh dear.
what's the ETA on that?
mbonnetf13: I believe it does, let me check
j-rodkoji bits link against rpm libs...
mbonnetj-rod: yes, but we record the payload hash in the database
and right now we're pulling out rpm.RPMTAG_SIGMD5
j-rod(half-question, half-statement there... :)
mbonnetI assume that'll change to RPMTAG_SIGSHA256 or something?
f13mbonnet: good question for the rpm folks
mbonnet: is the koji changes required tracked on the StrongerHashes feature page?
mbonnetf13: not sure, there's a ticket about it in Koji trac
f13: https://fedorahosted.org/koji/ticket/119
nottingcrap, i thought this was already handled
mbonnet: what happens if the wrong hash is recorded?
j-rodiirc, it wouldn't be the wrong hash, it'd be no hash
mbonnetnotting: well, I'm going to assume that if we're using sha256, then either RPMTAG_SIGMD5 is no longer defined (AttributeError) or will return null (database error) and we'll be unable to import any new packages
f13that would be bad.
So it looks like we're held up on a new koji deployment, and then landing some of the above stuff.
and the clock is ticking, loudly
considering that a full rebuild is going to stuff the buildsystem up for probably a week
bpepplef13: how much of a window do we have to get this stuff done.
mitrmbonnet: The tag is still used, but the strings are larger.
mbonnetmitr: so SIGTAG_MD5 will now return sha256 hashes?
mitrmbonnet: https://fedoraproject.org/wiki/RPM_file_format_changes_to_support_SHA-256
f13bpepple: beta freeze is 3.5 weeks away
mitrI've heard on a conf call that the koji plan is to simply stop tracking the hashes - they are only ever used to display them in the web interface.
f13feature freeze is 2.5 weeks away
bpepplehmm, that's going to be pretty tight.
f13the rebuilds should be done by feature freeze, to give time to clean up bugs before beta freeze
so rebuilds really need to start in the next 2 weeks
mitrRemoving the code that adds the hashes to the database "should be" a very small change.
f13mitr: yeah, but there are a ton of other koji changes in flight right now
dgilmore: when is the koji outage ?
bpepplef13: I think dgilmore had to step away.
mbonnetmitr: we also check the payload hash when importing rpms
mitrmbonnet: Hash of all packaged files, or some hash from the signature header?
mbonnetmitr: we're not longer storing file hashes,  but we still store SIGTAG_MD5 (which I thought was a hash of the payload, unaffected by signing)
mitrmbonnet: SIGTAG_MD5 doesn't change.
f13while an interesting debate, koji /will/ need changes for teh larger gpg keys
and we'll need that prior to beta
mbonnetmitr: ok, maybe this isn't a problem then.  Though I was also told that we need to fix the way we grab signatures.
f13mbonnet: you need to fix the way you grab gpg signatures
mitrmbonnet: yes, before beta - not before mass rebuild.
mbonnetf13: I'll work with mikem to make sure these changes are in the next Koji release (Feb. 28)
nirikkoji update/outage is planned for the 21st.
mbonnetoh, is it 21st
f1321st or 28th?
nottingor 14th? :)
nirikFeb 12 13:12:15 <dgilmore>      it will happen on the 21st and last ~48 hours
f13I think we'll need some koji changes, maybe just configuration, to handle the building of everything .i586
nirikthats what I have in my logs from the infrastructure meeting the other day.
mbonnetf13: isn't that a redhat-rpm-config change?
f13: I think we'll still have i386 as the arch for the tasks, they'll just produce i586 packages
f13mbonnet: ok, wasn't sure about that
lots of things in the air, I don't have it all in my head :/
bpeppleyeah, this rebuild is covering a lot of things.
ok, so is there anything else to discuss in regard to the upcoming rebuild?
nottingso, if we are tied to the feb. 21st date, that means we have a week to get everything in order
f13I'd say we'd start the builds on the 23rd
give the koji guys a couple days to shake out the new release issues
(and I don't really want to work that weekend)
nottingf13: does this mean this discussion  and the plan should be items 1 through 23 for the monday meeting?
mbonnetf13: when is the beta (larger sigs)?
f13mbonnet: beta freeze is 3.5 weeks away
March 10
nottingf13: so, that gives us one week to get the mass rebuild done before feature freeze?
and a week from feature freeze to fix bugs for beta freeze
bpepplef13: is that realistic?
f13unless we aren't dependant upon new koji for the mass rebuld
if we don't need new koji, we can start the rebuilds even earlier, depending on the other requirements.
to recap, I need to know:
A) When GCC is ready
B) When rpm is ready
C) When/if Koji is ready
nottingA is done
f13and then I will break the system to its knees with background builds
notting: no, they wanted it to sit in rawhide for a while before they were ready for a mass rebuild.
notting(modulo any bugs, but we'll never know that)
f13(unless you just confirmed with jakub today)
nottingno, i didn't
mitrB rpm is ready, the macro must be put in redhat-rpm-config (or elsewhere?)
mbonnetmitr: is B) for larger hashes or i586-everywhere?
f13I guess B is for both
nottingf13: hm, maybe table this for the releng meeting?
mitrOh - larger hashes are ready.  I don't know anything about i586
f13notting: isn't it FESCo who needs to coordinate all these features?
mbonnetf13: I think we need to verify the i586-everywhere config changes, maybe in a separate tag
nottingf13: all three features have been approved
f13ugh, fine I guess releng will have to pick up the ball
nottingf13: if you like, i can keep swapping my fesco and releng hat back and forth during the meeting
f13fine by me
nottingrealistically, it will be the same people talking either way :/
and monday gives us a chance to demand people show up :)
f13I'll send a mail out to fedora-devel-list about it today
mentioning that it'll be discussed at the releng meeting
nottingf13: want me to follow up with explicit invites to various people?
f13sure, why not
f13I think we've probably beaten this topic to death
bpepplef13: yeah.
ok, anything else, or should we wrap up for the day?
bpepplealright, than....
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End
Thanks, everyone!
bpepplef13: something else?
f13I'm probably too late to mention that Automated QA stuff will be coming on line very shortly
bpepplef13: cool.
nirikoh, who was supposed to be doing the summary for this meeting?
f13informative only
bpepplenirik: dgilmore, but I'll do it.
nirikbpepple: thanks.
f13we're waiting on a PHX resource from infrastructure, but may start generating things on a test box elsewhere before that happens
f13the Fedora QA meetings will have regular reports about the autoqa efforts, and https://fedoraproject.org/wiki/Automated_QA_Testing_Project
bpepplef13: cool.  I'll put a note in my meeting summary.

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!