--- Topic for #fedora-meeting is Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule
Topic for #fedora-meeting set by SmootherFrOgZ at Thu Apr 16 16:36:19 2009
nirik has changed the topic to: FESCo meeting - Init process
nirikFESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod
* bpepple is here.
* sharkcz is here
j-rodhere for a teensy bit
* jds2001 here-ish.
dgilmore is here
jds2001 asked nirik to chair this because I have $DAYJOB commitments.
nirikok, we have a pretty small adjenda, so lets get to it and hopefully finish early. ;)
--- nirik has changed the topic to: FESCo meeting - Threat Assessment
dgilmorethere is part of it that is incorrect
nirikso we have a threat assesment. Should it be made public? if so how?
* jds2001 is all about transparency.
nottingsorry, a bit late today
j-rodI see no reason not to make it public
nirikno worries.
nottingso, how do we review it in this meeting sanely w/o making it public?
* bpepple doesn't have any issue with making it public either.
jds2001no, the review is whether to make it public :)
dgilmoreI think we should fix the issues with it before making it public.
Just to make sure that the information is correct
bpeppledgilmore: sounds reasonable to me.
nirikyou mean edit it to be accurate, not fix all the issues it raises?
dgilmorenirik: correct
nirikok, fine with me... dgilmore: did you want to make changes and send a diff out then we publish it next week?
or does anyone want to not publish it?
dgilmorenirik: sure i can do that
* sharkcz agrees with making it public
nottingyeah, i don't see why not
dwmw2definitely public
nirikok, sounds good. shall we move on then?
bpepplemove on...
--- nirik has changed the topic to: FESCo meeting - FPC items
nirik.fesco 136
zodbotnirik: #136 (FPC report - 2009-04-14) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/136
nirikshall we take these one at a time?
* jwb is here now
nirikwordpress plugins?
nottinglooks reasonable, i am not a subject area expert. +1
bpepple+1, looks reasonable to me also.
nirik+1 here, looks fine.
jds2001+1, sorry im late :)
nirikok, no objections there
Guidelines for conflicts: https://fedoraproject.org/wiki/Common_package_names_packaging_guideline_draft
* nirik thinks this looks common sense, but ok.
jwbyeah, what you said
so i guess i'll go +1
nirikok, no objection there, approved.
alternatives guidelines: https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives
nottingthey didn't like my shorter version, so +1
jwbthey're going to drop the list of 'need fixing' from the draft, right?
jwband file bugs on them...
spot, tibbs?
nirik+1 here. I hope we can get some env-modules guidelines setup and switch things that make sense to them.
jwbtibbs, https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives
niriknotting: what was your shorter one?
nottingnirik: "don't."
jwbthe list of need fixing packages will get removed and bugs will be filed right?
niriknotting: yeah. ;( Sadly for some things there is no better solution currently.
tibbsThose package lists at the bottom shouldn't be there.
jwbtibbs, ok
nirik, anyway +1
nirikI also assume this won't be a F11 blocker to fix those packages? since this is so late in the cycle?
tibbsI thought there were going to be taken out, but I guess not.
I think cleaning up for F12 would be a nice goal; doing that for F11 would be insane especially given that things are working as they are.
nirikok, no objections, so this is approved.
tibbs|h tibbs
bpeppletibbs: agreed.
--- nirik has changed the topic to: FESCo meeting - Features
nirikok, so moving on to some features.
nirik.fesco 64
zodbotnirik: #64 (liblvm - https://fedoraproject.org/wiki/Features/liblvm) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/64
nirikwe had questions on this didn't we? is the feature owner around by any chance?
jds2001yeah, my agenda was very tardy
* bpepple didn't even see the agenda.
* jds2001 has been sequestered in a conf rm for $DAYJOB for the last 3 days :(
nottingthere's nothing on the discussion page w.r.t. questions
nirikwell, my question was if this was going to require a bunch more anaconda changes... and if it's a feature we should be noting to users (since they will never see it)
I can add those to the talk page...
unless folks want to vote on it this week?
bpepplehow about add those to the feature pages, so the owner has a chance to respond.
since they probably weren't aware we were going to discuss it today.
nirikcan do.
we have also today:
nirik.fesco 133
zodbotnirik: #133 (Dracut - https://fedoraproject.org/wiki/Features/Dracut) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/133
nirikI think here we were wanting to check and make sure kernel folks were on board with it...
jwbjeremy, ping...
dgilmorei thought we rejected liblvm
+1 to dracut for F-12
jwbdavej, we're talking about dracut for F-12... still the plan?
davejtalk to harald, he's running with it now
j-rodand I gotta run
davejI handed it off to him a few weeks back
jwbdavej, h\h?
davej, are you following it at all ?
j-rodwon't be here next week, but will try to weigh in via email if need be
jwbi'm just curious if the upstream project is anywhere close to being usable...
* nirik is fine with it, +1... but it should land as soon as it's usable... because it should get lots of testing.
nottingwhat he said. +1 to the idea, but that's going to need a bunch of testing
davejjwb: afaik, it still doesn't support root-on-raid, or root-on-network but otherwise it should be in good shape
davejoh, and still doesn't support resume from hibernate
nirikroot-on-raid could be a big one. (at least for me, I have at least one box setup that way)
jeremyjwb: pong
bpepple+1 with lots of testing.
jwbjeremy, talking about dracut.  i think you dished to davej who now has dished to harald
nirikanyhow, I'm sure it will have issues, but if we end up happier than nash/mkinitrd it's all good.
jwbjeremy, anything you want to add about having it as a F12 feature?
jeremyI'm not sure what "approving as a feature" really means anymore... is it something that work is being done on with the idea of landing for f12?  yes.  is it a good idea?  yes.  is it to a state where we know if it's going to be go vs no go?  no.
jwbthe first two are enough
at least at this point
dgilmorenirik: most of my boxes have root on raid
nirikit can still be pulled before f12 feature freeze... this is mostly just 'is the idea ok' and 'is someone working on it'
sharkcz+1 from me
jwbnirik, erm... i think for this we'd want it pulled before Beta
* nirik notes we are at +6 now.
er 1
dgilmorejeremy: the idea is to get the features we want landing in F-12
nirikok, +7, so it passes.
ok, now I guess we should look at the f11 features that are not at 100%?
bpepplenirik: I think only gcc isn't at 100%
* nirik looks for the dashboard.
ok, why is gcc at 70%?
bpepplenirik: I don't think the dashboard is correct.  check poelcat's last e-mail.
it was sent about 20 minutes ago.
nottingpossibly b/c gcc-4.4 is only at the rc stage
nirikit seems up to date... gcc shows as only thing thats not 100%
also, there are still a list of packages that failed the mass rebuild.
jwbnotting, really?
dgilmoregcc 4.4.0 rc1  landed this week
jwboh, right
sorry, was thinking of the branching fiasco
nirikso, I guess we should just bump it to 100 and note that it might not be final in the feature page?
or add an epoch and go back to the old version and mass rebuild everything again? :)
* nirik kids
bpepplenirik: yeah, that would be fun. ;)
nirikso I think the only thing to do is bump to 100% and note that it could be rc1 that ships with f11, not the final.
unless the final is expected sooner than soon.
* notting digs up a list of packages still being inherity
poelcat thinks we need info from jakub :)
nottingerm, inherited
sharkczI think only jakub can give the answers
nirikthat seems to be hard to get sometimes... ;(
nottingabout 40 packages or so
poelcatthe page hasn't been updated by him since first created in january
* poelcat is pinging some other people that might be able to give status too
niriknotting: so perhaps we should block those in f12 and make someone fix them in the next cycle (or get them dead.packaged)
nottingnirik: http://fpaste.org/paste/9400
* dgilmore has most of the sparc spefic packages rebuilt
nirikflex seems important.
dgilmoreredhat-lsb i think should be a simple fix
* dgilmore will look ta it
nottingwhat's disturbing is the number of those whose *last* rebuild was likely someone who didn't own the package either
nirikanyhow, so where are we here? waiting on info on gcc? I don't think we have anything else on the agenda...
bpepplenirik: I think we need more info on gcc.
nirikok, should we try and get that via email or something and close out the meeting now?
nottingare there any actions we would take with more info?
* nirik can't think of anything except what he proposed above.
bpepplenotting: I think we're just looking for info to make the feature page accurately represent what we're going to ship.
nottingfair enough.
poelcatbpepple: correct
nirikI guess if it's known that final will be out very soon and be shipped with f11, we could note that, if not, we could note which rc is going to ship
nirikso, can someone contact the feature owner for more info on this?
nottingsure, done
nirikcool. thanks.
--- nirik has changed the topic to: FESCo meeting - Open Floor
nirikdoes anyone have anything else they would like to bring up?
bpepplejds2001: if you don't have time to send out the agenda next, contact me and I'll send it out on thursday for you.
jwbdoes anyone object to signing repodata?
there's a rel-eng ticket open for it, but i figured i would ask here too
nirikjwb: so that would land in rawhide here soonly?
jwbprobably not rawhide
because we don't sign packages in rawhide either
would be for release and updates
f13, notting: though we might be able to do it for rawhide, since it's only one file...
nirikyeah...so after we have a f11 repo/updates
jwbnirik, well, we are thinking about doing f10 as well
* notting doesn't like the pain, but as long as it's not his pain
nirikthats pretty close to release time to be testing with it. ;)
f13jwb: who's going to get up at 4am to sign repodata?
nirikf13: yeah, signing server?
jwbf13, don't you stay up that late these days anyway?
f13jwb: not usually
jwbnirik, signing server is not an answer.  it doesn't automate signing
it just makes it safer
f13nirik: not functional yet, and I don't think it has an automation mode yet
jwbf13, was a joke
nirikok, fair enough.
ok, anything else on this topic? or any others?
jds2001bpepple: horribly sorry.
we started generating them for rawhide, and we've run into issues
skvidalnotting: you just need more ram, clearly
bpeppleno problem, it just would be guests to the meetings a chance to show up is all.  ;)  If your short on time drop me a line on weds or thurs morning on I'll do it.
niriknotting: hopefully it can get solved? I guess if not we can always not do presto again.
nottingright now, attempting to generate delta rpms for kernel debuginfo packages brings the box to its knees, eventually getting OOM killed
while we can hack it not to generate drpms for debuginfo, it's very likely that any builds of kdelibs will do the same thing
jwbkdelibs is that big?
skvidallots of files
nottingkdelibs-apidocs is
similarly there are game data packages of a problematic size
jwbwhat is the magical size?
nottingmaking a deltarpm currently takes 2-3x the uncompressed package size, in RAM
jwband that can't be fixed?
nottingthe compose box has 6G of memory, and is doing things in parallel
nottingjwb: jdieter says it's unlikely to be a quick/easy fix
jwband swap (while horribly slow) doesn't help the OOM?
nottingit might, if we added obscene amounts.
jwbmaybe not, depending on things
nottingnote that delta-ing one kernel debuginfo package took ~2.5 hours of cpu time befoore it was killed
jwbok, so i think from a time perspective we should not be doing that anyway
nirikcould we blacklist based on size? (granted that sucks as you want those big packages to have deltas)
nottingso, deltas also add a non-trivial amount of time to the compose process
jwbbut it doesn't solve the problem
nottingnirik: it would need to be done in createrepo, which i don't know that skvidal wants to do
skvidalI can do that
I'm fine w/doing that, in fact
but my question is
clearly we'd want deltas for that when small amounts of things change
nirikbut that would be a stopgap until the underlying issue was fixed.
nottingskvidal: oo.o is only ~250MB uncompresed, that's doable
skvidalnirik: nod
nottingbut it does seem weird to explicitly not do deltas for things where they may help the most :/
skvidalnotting: so do you want me to add a 'if size > foo abort' option?
niriknotting: whats the magic size thats bad? just size, or is it # of files?
skvidalI can do it right now
hell, I could put in a patch to let you set the size
nottingnirik: size, afaik
skvidalnotting: do you want me to do that?
nirikin any case, shall we close out the fesco meeting and continue this discussion over in devel? or is there action fesco needs to take here?
bpepplenirik: +1
cassmodiahJust a little bit of advertising for the open floor discussion: https://fedorahosted.org/fesco/ticket/134 what do you think about this?
nottingwell, it's a feature that's arrived *very* late
skvidalnotting: to be fair - the feature has been done for a while
nottingskvidal: but it was never integrated
nirikyeah, it's landed very late... but oh well.
skvidalnotting: not for a lack of trying. I brought it up a ton of times
nirikIt should be easy to abort to not doing it, right?
bpepplecassmodiah: I pretty much agree with what abadger1999 wrote.
nottingskvidal: true.
nottingi just want confirmation from the rest of fesco that they still want to pursue this for f11
skvidalnotting: it only came to head b/c the test day came up
niriknotting: I would still like to see it if at all possible.
skvidalsize-restricted drpms is better than not at all
nottingok, so we can move this to -devel
rscbpepple: regarding #134, would splitting out into zsync-zlib as zlibzsync.so.* also be okay?
nirikrsc: thats the forked zlib? why would splitting it help?
rscnirik: because of the obvious security reasons?
nirik: whenever static linking comes up, I'm told, that I should use dynamic linking, because it's better in kind of security issues
nirikI don't think there is that much advantage there... it shouldnt be shipping the forked zlib at all.
rscnirik: We also could use a plain zlib + the forking patch if that makes it better
* nirik hasn't read the entire ticket, so I am not up to speed on the details.
nirikwhats the forking patch?
rscnirik: well, the one function of code difference between zlib and forked zlib.
nirikI think using the system one is a much better idea if that can be done with a small patch.
anyone else want to chime in here? or should we close meeting and discuss next week?
* nirik wonders if everyone else wandered off.
nirikthanks for coming everyone.
nottingi would prefer they use the system one. but yeah, i think we can close
--- nirik has changed the topic to: Channel is used by various Fedora groups and committees for their regular meetings | Note that meetings often get logged | For questions about using Fedora please ask in #fedora | See http://fedoraproject.org/wiki/Communicate/FedoraMeetingChannel for meeting schedule
* nirik notes people can chime in on that ticket anytime....
rscnirik: as far as I got zsync upstream, they won't rewrite that (you know the phrase "patches are cheerfully accepted"?) themself
nirikrsc: yeah. I think using the system one for now at least is the way to go.
abadger1999rsc, cassmodiah: Have either of you talked to rsync upstream yet?
* abadger1999 notes he has to run in about ten minutes.
rscnirik: building against system zlib actually fails because of missing functionality, the fork has
cassmodiahabadger1999 me not, because i haven't the skill to talk with them about this issue
abadger1999cassmodiah: :-(  that's really where this belongs.  they're putting everyone in a bind because there's at least three projects I know of that they're affecting.
cassmodiah: Could be four if pysync links to libz directly... but I'm guessing it uses the python bindings instead.
cassmodiah, rsc: And neither of you have looked at how pysync does things either?
abadger1999Or librsync, for that matter
rscabadger1999: well, from what I read, pysnc uses librsync.
cassmodiahi will take a look in this
abadger1999rsc: It has a pure python implementation and a librsync wrapper.
rscabadger1999: I'm not really able to understand how librsync is actually doing that
abadger1999If you aren't able to do the porting then that direction would be something to bring up with the zsync maintainer -- Hey, librsync and pysync manage to do without the modified libz, why can't we?
(As opposed to the rsync guys where the question is -- There's several other implementations of the rsync protocol and they'd all like to use the rsync version of libz, how about you guys start releasing it separately?)

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