| --- 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 | ||
| nirik | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod | |
|---|---|---|
| * bpepple is here. | ||
| * sharkcz is here | ||
| dwmw2 | fish | |
| j-rod | here for a teensy bit | |
| * jds2001 here-ish. | ||
| dgilmore is here | ||
| jds2001 asked nirik to chair this because I have $DAYJOB commitments. | ||
| nirik | ok, 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 | ||
| dgilmore | there is part of it that is incorrect | |
| nirik | so we have a threat assesment. Should it be made public? if so how? | |
| * jds2001 is all about transparency. | ||
| notting | sorry, a bit late today | |
| j-rod | I see no reason not to make it public | |
| nirik | no worries. | |
| notting | so, 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. | ||
| jds2001 | no, the review is whether to make it public :) | |
| dgilmore | I think we should fix the issues with it before making it public. | |
| Just to make sure that the information is correct | ||
| bpepple | dgilmore: sounds reasonable to me. | |
| nirik | you mean edit it to be accurate, not fix all the issues it raises? | |
| dgilmore | nirik: correct | |
| nirik | ok, 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? | ||
| dgilmore | nirik: sure i can do that | |
| * sharkcz agrees with making it public | ||
| notting | yeah, i don't see why not | |
| dwmw2 | definitely public | |
| nirik | ok, sounds good. shall we move on then? | |
| bpepple | move on... | |
| --- nirik has changed the topic to: FESCo meeting - FPC items | ||
| nirik | .fesco 136 | |
| zodbot | nirik: #136 (FPC report - 2009-04-14) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/136 | |
| nirik | shall we take these one at a time? | |
| * jwb is here now | ||
| nirik | wordpress plugins? | |
| notting | looks reasonable, i am not a subject area expert. +1 | |
| bpepple | +1, looks reasonable to me also. | |
| nirik | +1 here, looks fine. | |
| sharkcz | +1 | |
| jwb | +1 | |
| dgilmore | +1 | |
| jds2001 | +1, sorry im late :) | |
| dwmw2 | +1 | |
| nirik | ok, no objections there | |
| Guidelines for conflicts: https://fedoraproject.org/wiki/Common_package_names_packaging_guideline_draft | ||
| dgilmore | +1 | |
| jds2001 | +1 | |
| sharkcz | +1 | |
| notting | +1 | |
| j-rod | +1 | |
| bpepple | +1 | |
| jwb | 0 | |
| * nirik thinks this looks common sense, but ok. | ||
| nirik | +1 | |
| jwb | yeah, what you said | |
| so i guess i'll go +1 | ||
| nirik | ok, no objection there, approved. | |
| alternatives guidelines: https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives | ||
| dgilmore | +1 | |
| notting | they didn't like my shorter version, so +1 | |
| dwmw2 | +1 | |
| sharkcz | +1 | |
| bpepple | +1 | |
| jwb | they're going to drop the list of 'need fixing' from the draft, right? | |
| j-rod | +1 | |
| jwb | and file bugs on them... | |
| spot, tibbs? | ||
| tibbs | Hmm? | |
| nirik | +1 here. I hope we can get some env-modules guidelines setup and switch things that make sense to them. | |
| jwb | tibbs, https://fedoraproject.org/wiki/PackagingDrafts/UsingAlternatives | |
| nirik | notting: what was your shorter one? | |
| notting | nirik: "don't." | |
| jwb | the list of need fixing packages will get removed and bugs will be filed right? | |
| nirik | notting: yeah. ;( Sadly for some things there is no better solution currently. | |
| tibbs | Those package lists at the bottom shouldn't be there. | |
| jwb | tibbs, ok | |
| nirik, anyway +1 | ||
| nirik | I also assume this won't be a F11 blocker to fix those packages? since this is so late in the cycle? | |
| jds2001 | +1 | |
| tibbs | I 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. | ||
| nirik | ok, no objections, so this is approved. | |
| tibbs|h tibbs | ||
| bpepple | tibbs: agreed. | |
| --- nirik has changed the topic to: FESCo meeting - Features | ||
| nirik | ok, so moving on to some features. | |
| nirik | .fesco 64 | |
| zodbot | nirik: #64 (liblvm - https://fedoraproject.org/wiki/Features/liblvm) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/64 | |
| nirik | we had questions on this didn't we? is the feature owner around by any chance? | |
| jds2001 | yeah, 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 :( | ||
| notting | there's nothing on the discussion page w.r.t. questions | |
| nirik | well, 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) | |
| s/question/questions/ | ||
| I can add those to the talk page... | ||
| unless folks want to vote on it this week? | ||
| bpepple | how 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. | ||
| nirik | can do. | |
| we have also today: | ||
| nirik | .fesco 133 | |
| zodbot | nirik: #133 (Dracut - https://fedoraproject.org/wiki/Features/Dracut) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/133 | |
| nirik | I think here we were wanting to check and make sure kernel folks were on board with it... | |
| jwb | jeremy, ping... | |
| dgilmore | i thought we rejected liblvm | |
| +1 to dracut for F-12 | ||
| jwb | davej, we're talking about dracut for F-12... still the plan? | |
| j-rod | +1 | |
| davej | talk to harald, he's running with it now | |
| j-rod | and I gotta run | |
| davej | I handed it off to him a few weeks back | |
| j-rod | won' | |
| jwb | davej, h\h? | |
| davej | yeah | |
| jwb | sigh | |
| davej, are you following it at all ? | ||
| j-rod | won't be here next week, but will try to weigh in via email if need be | |
| jwb | i'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. | ||
| notting | what he said. +1 to the idea, but that's going to need a bunch of testing | |
| davej | jwb: afaik, it still doesn't support root-on-raid, or root-on-network but otherwise it should be in good shape | |
| jwb | ok | |
| davej | oh, and still doesn't support resume from hibernate | |
| nirik | root-on-raid could be a big one. (at least for me, I have at least one box setup that way) | |
| jeremy | jwb: pong | |
| bpepple | +1 with lots of testing. | |
| jwb | jeremy, talking about dracut. i think you dished to davej who now has dished to harald | |
| jeremy | yes | |
| nirik | anyhow, I'm sure it will have issues, but if we end up happier than nash/mkinitrd it's all good. | |
| jwb | jeremy, anything you want to add about having it as a F12 feature? | |
| jeremy | I'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. | |
| jwb | the first two are enough | |
| at least at this point | ||
| dgilmore | nirik: most of my boxes have root on raid | |
| nirik | it 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 | |
| jwb | nirik, erm... i think for this we'd want it pulled before Beta | |
| oh | ||
| duh | ||
| * nirik notes we are at +6 now. | ||
| jwb | +! | |
| er 1 | ||
| dgilmore | jeremy: the idea is to get the features we want landing in F-12 | |
| nirik | ok, +7, so it passes. | |
| ok, now I guess we should look at the f11 features that are not at 100%? | ||
| bpepple | nirik: I think only gcc isn't at 100% | |
| * nirik looks for the dashboard. | ||
| nirik | https://fedoraproject.org/wiki/Releases/11/FeatureList | |
| ok, why is gcc at 70%? | ||
| bpepple | nirik: I don't think the dashboard is correct. check poelcat's last e-mail. | |
| it was sent about 20 minutes ago. | ||
| notting | possibly b/c gcc-4.4 is only at the rc stage | |
| nirik | it 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. | ||
| jwb | notting, really? | |
| dgilmore | gcc 4.4.0 rc1 landed this week | |
| jwb | oh, right | |
| sorry, was thinking of the branching fiasco | ||
| nirik | so, 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 | ||
| bpepple | nirik: yeah, that would be fun. ;) | |
| nirik | so 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 :) | ||
| notting | erm, inherited | |
| sharkcz | I think only jakub can give the answers | |
| nirik | that seems to be hard to get sometimes... ;( | |
| notting | about 40 packages or so | |
| poelcat | the 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 | ||
| nirik | notting: so perhaps we should block those in f12 and make someone fix them in the next cycle (or get them dead.packaged) | |
| notting | nirik: http://fpaste.org/paste/9400 | |
| * dgilmore has most of the sparc spefic packages rebuilt | ||
| nirik | flex seems important. | |
| dgilmore | redhat-lsb i think should be a simple fix | |
| * dgilmore will look ta it | ||
| notting | what's disturbing is the number of those whose *last* rebuild was likely someone who didn't own the package either | |
| dgilmore | right | |
| nirik | anyhow, so where are we here? waiting on info on gcc? I don't think we have anything else on the agenda... | |
| bpepple | nirik: I think we need more info on gcc. | |
| nirik | ok, should we try and get that via email or something and close out the meeting now? | |
| notting | are there any actions we would take with more info? | |
| * nirik can't think of anything except what he proposed above. | ||
| bpepple | notting: I think we're just looking for info to make the feature page accurately represent what we're going to ship. | |
| notting | fair enough. | |
| poelcat | bpepple: correct | |
| nirik | I 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 | |
| nirik | so, can someone contact the feature owner for more info on this? | |
| notting | sure, done | |
| nirik | cool. thanks. | |
| --- nirik has changed the topic to: FESCo meeting - Open Floor | ||
| nirik | does anyone have anything else they would like to bring up? | |
| bpepple | jds2001: if you don't have time to send out the agenda next, contact me and I'll send it out on thursday for you. | |
| jwb | does anyone object to signing repodata? | |
| there's a rel-eng ticket open for it, but i figured i would ask here too | ||
| nirik | jwb: so that would land in rawhide here soonly? | |
| jwb | probably 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... | ||
| nirik | yeah...so after we have a f11 repo/updates | |
| notting | oof | |
| jwb | nirik, well, we are thinking about doing f10 as well | |
| * notting doesn't like the pain, but as long as it's not his pain | ||
| nirik | thats pretty close to release time to be testing with it. ;) | |
| f13 | jwb: who's going to get up at 4am to sign repodata? | |
| nirik | f13: yeah, signing server? | |
| jwb | f13, don't you stay up that late these days anyway? | |
| f13 | jwb: not usually | |
| jwb | nirik, signing server is not an answer. it doesn't automate signing | |
| it just makes it safer | ||
| f13 | nirik: not functional yet, and I don't think it has an automation mode yet | |
| jwb | f13, was a joke | |
| nirik | ok, fair enough. | |
| ok, anything else on this topic? or any others? | ||
| jds2001 | bpepple: horribly sorry. | |
| notting | deltarpms | |
| we started generating them for rawhide, and we've run into issues | ||
| cassmodiah | ? | |
| skvidal | notting: you just need more ram, clearly | |
| :) | ||
| notting | clearly. | |
| bpepple | no 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. | |
| nirik | notting: hopefully it can get solved? I guess if not we can always not do presto again. | |
| notting | right 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 | ||
| jwb | kdelibs is that big? | |
| skvidal | lots of files | |
| notting | kdelibs-apidocs is | |
| similarly there are game data packages of a problematic size | ||
| jwb | what is the magical size? | |
| notting | making a deltarpm currently takes 2-3x the uncompressed package size, in RAM | |
| jwb | and that can't be fixed? | |
| notting | the compose box has 6G of memory, and is doing things in parallel | |
| notting | jwb: jdieter says it's unlikely to be a quick/easy fix | |
| jwb | and swap (while horribly slow) doesn't help the OOM? | |
| notting | it might, if we added obscene amounts. | |
| jwb | maybe not, depending on things | |
| notting | note that delta-ing one kernel debuginfo package took ~2.5 hours of cpu time befoore it was killed | |
| jwb | ok, so i think from a time perspective we should not be doing that anyway | |
| nirik | could we blacklist based on size? (granted that sucks as you want those big packages to have deltas) | |
| notting | so, deltas also add a non-trivial amount of time to the compose process | |
| jwb | but it doesn't solve the problem | |
| notting | nirik: it would need to be done in createrepo, which i don't know that skvidal wants to do | |
| skvidal | I can do that | |
| I'm fine w/doing that, in fact | ||
| but my question is | ||
| Openoffice | ||
| clearly we'd want deltas for that when small amounts of things change | ||
| nirik | but that would be a stopgap until the underlying issue was fixed. | |
| notting | skvidal: oo.o is only ~250MB uncompresed, that's doable | |
| skvidal | nirik: nod | |
| notting | but it does seem weird to explicitly not do deltas for things where they may help the most :/ | |
| skvidal | notting: so do you want me to add a 'if size > foo abort' option? | |
| nirik | notting: whats the magic size thats bad? just size, or is it # of files? | |
| skvidal | I can do it right now | |
| hell, I could put in a patch to let you set the size | ||
| notting | nirik: size, afaik | |
| skvidal | notting: do you want me to do that? | |
| nirik | in 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? | |
| bpepple | nirik: +1 | |
| cassmodiah | Just a little bit of advertising for the open floor discussion: https://fedorahosted.org/fesco/ticket/134 what do you think about this? | |
| notting | well, it's a feature that's arrived *very* late | |
| skvidal | notting: to be fair - the feature has been done for a while | |
| notting | skvidal: but it was never integrated | |
| nirik | yeah, it's landed very late... but oh well. | |
| skvidal | notting: not for a lack of trying. I brought it up a ton of times | |
| nirik | It should be easy to abort to not doing it, right? | |
| bpepple | cassmodiah: I pretty much agree with what abadger1999 wrote. | |
| notting | skvidal: true. | |
| notting | i just want confirmation from the rest of fesco that they still want to pursue this for f11 | |
| skvidal | notting: it only came to head b/c the test day came up | |
| nirik | notting: I would still like to see it if at all possible. | |
| skvidal | size-restricted drpms is better than not at all | |
| notting | ok, so we can move this to -devel | |
| rsc | bpepple: regarding #134, would splitting out into zsync-zlib as zlibzsync.so.* also be okay? | |
| nirik | rsc: thats the forked zlib? why would splitting it help? | |
| rsc | nirik: 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 | ||
| nirik | I don't think there is that much advantage there... it shouldnt be shipping the forked zlib at all. | |
| rsc | nirik: 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. | ||
| nirik | whats the forking patch? | |
| rsc | nirik: well, the one function of code difference between zlib and forked zlib. | |
| nirik | I 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. | ||
| jwb | CLOSE | |
| sharkcz | +1 | |
| nirik | thanks for coming everyone. | |
| notting | i 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.... | ||
| rsc | nirik: as far as I got zsync upstream, they won't rewrite that (you know the phrase "patches are cheerfully accepted"?) themself | |
| nirik | rsc: yeah. I think using the system one for now at least is the way to go. | |
| abadger1999 | rsc, cassmodiah: Have either of you talked to rsync upstream yet? | |
| * abadger1999 notes he has to run in about ten minutes. | ||
| rsc | nirik: building against system zlib actually fails because of missing functionality, the fork has | |
| cassmodiah | abadger1999 me not, because i haven't the skill to talk with them about this issue | |
| abadger1999 | cassmodiah: :-( 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? | ||
| cassmodiah | mmmh | |
| abadger1999 | Or librsync, for that matter | |
| rsc | abadger1999: well, from what I read, pysnc uses librsync. | |
| cassmodiah | i will take a look in this | |
| abadger1999 | rsc: It has a pure python implementation and a librsync wrapper. | |
| rsc | abadger1999: I'm not really able to understand how librsync is actually doing that | |
| abadger1999 | k | |
| abadger1999 | If 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!