| --- jds2001 has changed the topic to: FESCo meeting -- init | ||
| jds2001 | FESCo meeting ping -- bpepple, dgilmore, dwmw2, jwb, notting, nirik, sharkcz, jds2001, j-rod | |
|---|---|---|
| * nirik is here. | ||
| jwb is here | ||
| j-rod is back in the saddle | ||
| sharkcz is here | ||
| dwmw2 | fish | |
| jds2001 | sorry for the time confusion | |
| * dgilmore is here | ||
| jds2001 | DST should be abolished. | |
| --- jds2001 has changed the topic to: FESCo meeting - agenda at https://fedorahosted.org/fesco/report/9 - tickets | ||
| dwmw2 | we should build a big dome over 95.8% of the world and abolish timezones completely. | |
| jds2001 | let's get started.... | |
| dwmw2: :) | ||
| why 95.8%? | ||
| dwmw2 | 23/24 | |
| jds2001 | oh, im a little slow :) | |
| jds2001 | .fesco 57 | |
| zodbot | jds2001: #57 (Make stronger policy/guideline that ABI/API/soname breakage should always be announced fedora-devel-announce (not f-d-l)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/57 | |
| dwmw2 | how much does this actually help, in practice? | |
| jds2001 | likely none. | |
| dwmw2 | don't we already get automated warnings when deps break anyway? | |
| jds2001 | and im not sure that it's in the charter of f-d-a to mention day-to-day stuff | |
| yeah | ||
| dwmw2 | I don't see the point in this, then | |
| jwb | dwmw2, perhaps preventing the breaks is what it's targeting | |
| dwmw2 | if it was mailing the maintainers of the affected packages, maybe | |
| j-rod | yeah, I'm kind of of the mind that shouting louder doesn't really help anything | |
| dwmw2 | but they'll get mailed anyway once you break it :) | |
| j-rod | having a heads up that something is going to break is nice tho | |
| i.e., advance notice instead of ex post facto | ||
| dwmw2 | in the good old days, the person breaking it would just rebuild the affected packages... | |
| jds2001 | yeah, that already happens on f-devel. | |
| * notting is here for the moment, but may need to drop out | ||
| dwmw2 | advance notice is nice; I'm not sure we (FESCo) need to get bureaucratic about it | |
| jds2001 | dwmw2: they still can, if they're in provenpackager | |
| yeah | ||
| dgilmore | i suggest we come up with a easy way to detect things that will break so they can be fixed by the person breaking them | |
| j-rod | my f-d and f-d-a mail all goes to the same folder anyway, so I care not | |
| notting | dgilmore: repoquery -q --whatrequires <yourpackage> --alldeps | |
| dwmw2 | dgilmore: don't we already have that? | |
| jwb | 'make what-will-break' | |
| dwmw2 | maybe there could be an immediate mail to the affected package owners, as soon as the 'breakage' hits rawhide/ | |
| dgilmore | notting: sure. i guess ill add a im-gonna-break-shit wrapper to fedora-packager | |
| jds2001 | that would be cool. | |
| notting | dgilmore: you could fancy it up by iterating over the library provides of the package, so it doesn't catch things that require /bin/<whatever> from the package | |
| j-rod | ooh, could it be a cvs pre-commit hook so we can slow down cvs even further? :) | |
| j-rod | (usage of cvs, that is) | |
| jds2001 | so as for this proposal, I'm -1. | |
| dwmw2 | -1 | |
| dgilmore | notting: yeah | |
| dwmw2 | there are better ways to deal with this | |
| dgilmore | -1 for the proposal | |
| notting | -1. f-d-l (or mailing those affected directly) is fine with me | |
| sharkcz | I agree, -1 | |
| jwb | 0. there's obviously a problem with how it is today, but i'm not sure this is the solution | |
| * nirik is also 0. I think this could add noise to the announce list. | ||
| j-rod | -0.5 | |
| jds2001 | i see five -1's, two 0's, and one -0.5 :) | |
| so we've declined this proposal. Other ways of finding breakage are better. | ||
| jds2001 | .fesco 67 | |
| zodbot | jds2001: #67 (How to deal with Requires.privates in pkg-config) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/67 | |
| jds2001 | I'm not entirely sure if we've already covered this one or not. | |
| or if it's even our ball of wax, or is it FPC fodder? | ||
| nirik | .whoowns pkg-config | |
| zodbot | nirik: No such package exists. | |
| nirik | .whoowns pkgconfig | |
| zodbot | nirik: mclasen | |
| abadger1999 | Anything about telling the pkgconfig maintainer what to do would be FESCo. | |
| abadger1999 | anything about how to deal with the way pkgconfig works would be FPC | |
| jds2001 | OK, I misunderstood the ticket I guess. | |
| dgilmore | is it really a problem? | |
| dwmw2 | we discourage static libraries. Presumably we shouldn't be caring too much about the behaviour of pkgconfig --static | |
| nirik | some of this would be moot due to the mass rebuild wouldn't it? | |
| dwmw2 | so we should probably restore the patch we had before. | |
| nirik | ie, maintainers already fixed things to work with the current config. | |
| jds2001 | yeah, this is old. | |
| * nirik dislikes fesco butting in and telling the maintainer what to do. Perhaps they have good reasons for it? | ||
| nirik | mclasen: can you take a look at https://fedorahosted.org/fesco/ticket/67 and see what you think? | |
| dwmw2 | I'd certainly not like to make a decision without ... oh, there he is :) | |
| jds2001 | reporter is listed as bpepple, not sure if he's the "real | |
| jds2001 | " complainant or opened it for somebody | |
| mclasen | nirik: I first reverted the patch we carried in rawhide, since people complained that the Fedora pkgconfig didn't match upstream | |
| then I reverted it in F10 and F9 since other people complained that rawhide didn't match the released distros | ||
| there's no way to make everyone happy here, I fear | ||
| j-rod | I'm all for matching upstream. | |
| mclasen | I will not reintroduce the patch in rawhide, in any case | |
| and bringing it back in F9 and F10 may only muddy the waters further | ||
| mclasen | since some packages have already been fixed to build with the current (upstream) behaviour... | |
| jds2001 | and asking folks to fix it for F9 and F10 when they update isn't that much. | |
| j-rod | +1 for matching upstream. if it needs to be changed somehow, push the change upstream. | |
| * nirik nods at j-rod and mclasen | ||
| j-rod | less patches is moar gooder | |
| jds2001 | indeed | |
| notting | j-rod: so, you're saying no change from what we currently have/ | |
| * mclasen notes that he only added the patch very reluctantly in the first place (after prodding upstream for months about it) | ||
| jds2001 | right. | |
| jds2001 | so i guess the proposal is to keep everything as we have it now. | |
| +1 to that. | ||
| dwmw2 | +1 | |
| dgilmore | +1 | |
| sharkcz | +1 | |
| notting | +1 | |
| j-rod | +1 | |
| nirik | +1 | |
| * mclasen goes to feed the guinea pigs | ||
| nirik | sorry to bug you mclasen, and thanks for the input. ;) | |
| jds2001 | i see seven +1's, so pkgconfig will stay matching upstream. | |
| thx mclasen :) | ||
| jds2001 | .fesco 79 | |
| zodbot | jds2001: #79 (Lenient hash check for noarch subpackages) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/79 | |
| jds2001 | did we already cover this in the past? | |
| nirik | nope. | |
| abadger1999 | nope | |
| jds2001 | ok | |
| * jds2001 is not insane then :) | ||
| jds2001 | well, maybe I am, but that's for another time :) | |
| dgilmore | -1 to this | |
| jwb | why | |
| dgilmore | there are way to many corner cases that could cause a build to be failed. | |
| nirik | It could cause more failures, but shouldn't we fix those cases? | |
| dgilmore | its not something that we can do for builds that are noacrh only | |
| jds2001 | im not exactly sure how this would be implemented in practice. Build once on ppc, and once on x86 for anything with a noarch subpackage and rpmdiff the subpackages? Seems to increase builder load to me, unless I'm completely dense. | |
| dgilmore | jds2001: this is noarch subpackages only | |
| abadger1999 | There are corner cases. But my thinking is that falsely keeping something from being noarched is better than letting it be noarched incorrectly. | |
| jds2001 | dgilmore: right, but how do you get the target of the rpmdiff? | |
| dgilmore | jds2001: i guess i dont understand your question | |
| dgilmore | jds2001: noarch subpackages are built on every arch | |
| jds2001 | oh, right :) | |
| * jds2001 is assuredly dense. | ||
| jds2001 faceplants | ||
| notting | so, this is applying stringency to noarch subpackages that we don't actually apply to noarch packages? | |
| dgilmore | right | |
| notting | that seems conceptually fishy to me | |
| j-rod | applying it to both would require that fully noarch packages be built on more than one arch tho | |
| instead of building only on the first available builder | ||
| nirik | which would add build load. | |
| jds2001 | j-rod: right, and that's where i was originally going. | |
| dgilmore | notting: right. thats part of why i object to making things stricter | |
| notting | right, but if we're trying to prevent noarch packages accidentally being archful... we should be checking both | |
| j-rod | what's the current algo to decide which build of the noarch sub-package gets into all the trees? | |
| (or does each arch tree take its own?) | ||
| * mclasen would like to be able to declare a doc package noarch, even if it contains arch-dependent things due to insufficiencies of gtk-doc... | ||
| abadger1999 | notting: I think so too but I don't have a way to tie that into koji yet :-) | |
| OTOH, noarch subpackages are a bit riskier. | ||
| for instance, people have been wanting to make header files noarch. | ||
| j-rod | yeah, fail. | |
| (at least for the kernel...) | ||
| notting | abadger1999: seems like excess complication for not much benefit | |
| j-rod | I kinda figure people will not be dumb, and if a problem crops up, a bug will get filed, and it'll get fixed | |
| abadger1999 | notting: Well.. currently we're doing more checks against noarch subpackages... we just happen to turn off the hash check | |
| j-rod | of course, figuring people will not be dumb is probably dumb | |
| abadger1999 | So there's no extra steps in the big picture... we're allowing the script to run more things. | |
| abadger1999 | mclasen: That's actually an interesting thing. I found a noarch package that was broken in documentation containing arch-specific things manually... but this check would not catch it. | |
| j-rod | so now why is this a fesco thing and not a packaging committee thing? | |
| abadger1999 | mclasen: Assuming that the doc was properly marked %doc. | |
| mbonnet | dgilmore and I agree that what we have now is decent in terms of leniency, and anything else will cause too many false positives | |
| abadger1999 | j-rod: This is fesco because it affects checks that the build system would do. | |
| notting | mbonnet: can you answer j-rod's question about where the noarch subpackage that gets stored by koji comes from? first build to finish? other? | |
| abadger1999 | If it fails here, FPC will have to decide what to allow in terms of noarch subpackages and whether reviewers need to check it. | |
| And how reviewers would check it. | ||
| mbonnet | I suggest the way to deal with this more completely is for someone to do post-build checks and file bugs. It should be outside the build system. | |
| j-rod | abadger1999: ok, gotcha, thank you for the clarification | |
| abadger1999 | racor thought FPC might want to say headers are not allowed to be noarch, for instance. | |
| mbonnet | notting: basically first-built | |
| abadger1999 | I'd rather a build check so that most headers could be noarch. | |
| mbonnet: Show me concrete false positives. | ||
| mbonnet | abadger1999: we have | |
| j-rod | mbonnet: so in that case... what gets into koji really isn't any different than what goes in for pure noarch packages right now | |
| mbonnet | .pyc/pyo's for instance | |
| abadger1999 | mbonnet: No, you haven't given me a single package that fails. | |
| abadger1999 | mbonnet: pyc, pyo does not fail the current check. | |
| j-rod | first free arch builds noarch packages, first finished build wins the noarch sub-package race | |
| abadger1999 | And also, only a few pyc, pyo will fail. | |
| mbonnet | abadger1999: that's because you whitelist it, which I think isn't a scalable solution | |
| abadger1999 | if htey happen to have a very large constant in them. | |
| mbonnet | j-rod: correct | |
| abadger1999 | mbonnet: A whitelist is exactly what I'm asking for. | |
| Things that are different between builds on different arches and are not known to be good need examining. | ||
| mbonnet | abadger1999: and I'm saying that's exactly what I don't want to do, because we'd need a koji outage everytime we need to update the whitelist, which I think is unacceptable. | |
| abadger1999 | Whitelisting things that we know are good is safer. | |
| mbonnet: I asked whether you import rpmdiff. Do you? | ||
| dwmw2 | hm, must go get inhalers for wenchlet, lest she die over the weekend; sorry. | |
| abadger1999 | Or so you invoke it as a script? | |
| mbonnet | abadger1999: as a script, but that's not the point | |
| j-rod | in my mind, this seems a bit pointless unless we're also looking at all the pure noarch packages for the same sort of issues -- there are a lot more of those, and they're often more critical content then what people are presumably putting into noarch sub-packages (like docs) | |
| mbonnet | j-rod: +1 | |
| abadger1999 | docs are whitelisted by checking if they're marked %doc. | |
| mbonnet | also, problems like archful headers being marked noarch will be found *very* quickly by subsequent builds/testing | |
| abadger1999 | But I don't want to have packagers and reviewers having to manually check header files. | |
| j-rod | packagers would willfully have to change headers into a noarch sub-package right now. presumably, they'll actually inspect the content they're moving to see that they aren't doing something they shouldn't. | |
| notting | j-rod: +1 | |
| jds2001 | abadger1999: how do you get around that? | |
| abadger1999 | mbonnet: Really? if I have #define 64bittype long long, won't that be 64 bit on both 32 and 64 bit? | |
| mbonnet | abadger1999: if so, how is that not noarch? | |
| jds2001 | abadger1999: header files are header files - md5 is the same. Doesn't mean they'll work on that arch, but the hash would be teh same. | |
| abadger1999 | mbonnet: So if build 1 takes the noarch package from a 64 bit build, things start failing, build 2 takes it from the 32 bit build, things mysteriously start working again | |
| j-rod | except when they aren't the same... :) | |
| j-rod | (in reply to 'header files are header files') | |
| mbonnet | abadger1999: I'm not saying there aren't cases or archful header files, I'm saying it's not the job of the buildsys to detect them. | |
| Rathann | abadger1999: long long could be 128bit on x86_64. if you want 64bit type, just use int64_t | |
| j-rod | can those checks be simply run in informative mode? | |
| abadger1999 | And I'm saying it's too much of a chore to stick it onto a reviewer. | |
| j-rod | i.e., have it trigger sending a notice to the packager? | |
| mbonnet | j-rod: not really, koji has no way of "warning" someone, other than failing the build | |
| * mclasen keeps his archful headers below /usr/lib/glib-2.0 anyway... | ||
| j-rod | ah, ok. | |
| abadger1999 | jds2001: headers are not always the same. There are headers that are rewritten depending on the arch they're built on | |
| mclasen: You're doing it right. | ||
| notting_ | abadger1999: right, what i'm saying is there really that much benefit to drilling down to that level for noarch subpackages? | |
| abadger1999 | notting_: I think there is. But it's before FESCo because there's a difference of opinion :-) | |
| abadger1999 | We're potentially producing broken packages to optimize space. | |
| nirik | ideally, for both noarch packages and subpackages we would keep all the builds from all the arches and run them thru the autoqa thing to detect this. | |
| </pieinthesky> | ||
| notting | abadger1999: no, that's what i mean - why bother with noarch header packages? just leave them archful | |
| abadger1999 | and we can have a check that gives us most of the benefits of that optimization with just some corner cases failing. | |
| dgilmore | abadger1999: right. headers are quite often arch specific | |
| abadger1999 | notting: That's fine. I can introduce that into FPC if this fails in FESCo. | |
| mbonnet | abadger1999: and when we find out they're broken, we'll fix them. This is the same reason we don't run full test suites in the buildsys. | |
| abadger1999 | notting: This just seems like the better way to go *to me* | |
| abadger1999 | and FESCo is the place for that to be decided. | |
| abadger1999 | mbonnet: We do run full test suites in the buildsys. | |
| notting | abadger1999: i guess it's the other consequence, a pile of 1000 devel packages that all consist of a single .so symlink, that strikes me as wasteful | |
| jds2001 | so where are folks on this? | |
| abadger1999 | mbonnet: We don't run exterior test suites if that's what you mean. | |
| nirik | abadger1999: now that they are (hopefully) more noarch subpackages would it be possible to run it on the pool of them and see how many corner cases we have? or too hard? | |
| * mclasen wonders how many headers subpackages we have anyway | ||
| abadger1999 | nirik: I could... are they still listed on that page? | |
| mclasen: I saw one when I tested... it came through fine. | ||
| * nirik isn't sure. | ||
| jds2001 | we've got a lot more to cover today, and it sorta seems we're going in circles here. | |
| 0 to this. | ||
| notting | -1, on the premise that we should check all noarch subpkgs | |
| s/subpkgs/packages/ | ||
| jds2001 | anyone else? | |
| jwb | +-g | |
| -1, with notting's comment | ||
| nirik | I agree, but I kinda like it for catching things that should be caught... I'd like to see how much breakage we would see tho. | |
| abadger1999 | In the previous test, there was only one false positive. | |
| sharkcz | -1 also with notting's comment | |
| j-rod | -1, what notting said | |
| jds2001 | i see four -1's and one 0, so we've declined this proposal on the basis that if we do this, we should find a way to check *all* noarch packages. | |
| dwmw2 | hm, I see I didn't miss much... | |
| jds2001 | .fesco 89 | |
| zodbot | jds2001: #89 (Select Fedora representative for LSB) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/89 | |
| jds2001 | dwmw2: nope :) | |
| sharkcz: what's this all about? | ||
| dgilmore | jds2001: so ive attended the last two lsb meeetings | |
| jds2001 | ok | |
| so this is done? | ||
| notting | is this the point where we all shout "not it"? | |
| sharkcz | bpepple will know more details and dgilmore volunteered | |
| j-rod | NOT IT | |
| notting | not it! :) | |
| nirik | dgilmore: anything of use in those meetings? | |
| sharkcz | we just wanted to have dgilmore's delegation formalized | |
| notting | +1 to dgilmore, then | |
| jds2001 | +1 to dgilmore being fedora's lsb rep. | |
| sharkcz | +1 | |
| jwb | +1 | |
| nirik | +1 | |
| dgilmore | so far there has not been alot | |
| jds2001 | awesome, so dgilmore is confirmed as the lsb rep. Congrats or condolences, whichever is appropriate :) | |
| dgilmore | mostly talk about a summit they have coming up | |
| abadger1999 | (Appologizes for intel driver crash) | |
| dgilmore | and some discuccion on adding motif to lsb | |
| jds2001: thanks | ||
| j-rod | +1 for not me. I mean, for dgilmore. | |
| jds2001 | .fesco 96 | |
| zodbot | jds2001: #96 (Document "Rawhide cannot go backwards" rule) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/96 | |
| notting | dgilmore: heh, if they do that, fedora can't ever be lsb compliant | |
| jwb | ah, backwards | |
| so f13 brought this up a couple weeks ago | ||
| dgilmore | notting: thats what i said | |
| jwb | in that FESCo had declared that we don't revert epoch or release increases in rawhide | |
| jwb | as that would cause people to have to manually work around package stuff | |
| nirik | I think we stick it on http://fedoraproject.org/wiki/Package_maintainer_policy and be done with it. | |
| jwb | and essentially make that package go backwards | |
| jds2001 | right, this seems like common sense. | |
| nirik: +1 | ||
| notting | +1 | |
| jwb | awesome, i'll stop summarizing | |
| +! | ||
| er, 1 | ||
| sharkcz | +1 | |
| dgilmore | nirik: i agree | |
| j-rod | +1, "duh" | |
| jwb | in general though, we need to get better at documenting the rules we make | |
| jds2001 | i see five +1's, so we'll add that to the maintainer policy | |
| j-rod | although... what happens if a package has to get untagged? new build reverting the change rather than going back to the prior package? | |
| jwb | j-rod, what? | |
| jds2001 | jwb: agreed, I put the provenpackager stuff up. | |
| j-rod | "we're past freeze, this new build got in somehow, but it breaks the world" | |
| jds2001 | j-rod: if it's not made it in a compose, just untag. If it has, new build. | |
| jwb | right | |
| j-rod | okey dokey | |
| nirik | yeah, if it's not been in a compose untag is still ok... | |
| jwb | which is interesting around freeze time :) | |
| nirik | and we should feel free to override the rule if there is a critical enough reason. | |
| jwb | so who is going to write this up? | |
| * jwb will try | ||
| jds2001 thought he heard nirik volunteer :) | ||
| jwb | or if nirik wants to, i'd be happy to review :) | |
| nirik | no no, that was jwb. ;) | |
| jwb | ok, i will | |
| jds2001 | lol | |
| nirik | I'd be happy to review too... | |
| jwb | k | |
| jds2001 | .fesco 99 | |
| zodbot | jds2001: #99 (Review FPC items) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/99 | |
| jds2001 | so we've got explict requires again - https://fedoraproject.org/wiki/PackagingDrafts/ExplicitRequires | |
| wwoods | (parental advisory) | |
| jds2001 | hehe | |
| notting | i thought we approved that last week? | |
| jds2001 | +1 to ExplicitRequires | |
| did we? | ||
| * jds2001 missed half the meeting | ||
| notting | see http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20090306 | |
| jds2001 | if so, moving right along :) | |
| jds2001 | .fesco 108 | |
| zodbot | jds2001: #108 (Would be good if there was an acl for "let all packagers edit this package" in pkgdb) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/108 | |
| j-rod | +1 | |
| jds2001: there was a second item there... | ||
| in the fpc list | ||
| troublesome source urls | ||
| jds2001 | yeah. i figured both were approved last week, were they not? | |
| j-rod | or did we already cover that too? (I don't remember it) | |
| jds2001 | yeah, it's listed as approved. | |
| j-rod | oh. so we did. | |
| nirik | I thought we did approve them both. | |
| * j-rod must have not been paying close enough attention... | ||
| jds2001 | halfline: you around? | |
| halfline | yes | |
| nirik | mmcgrath: you around? | |
| mmcgrath | nirik: word up? | |
| jds2001 | this is halfline's proposal to include a checkbox in pkgdb to allow all packagers to commit to a package | |
| i.e. not just provenpackager and maintainer. | ||
| nirik | so my take on this: we shouldn't change anything on this just now and we should get someone (or someones) to do up a threat assessment. | |
| mmcgrath: you offered at one point, were you serious? or just part of a discussion? | ||
| halfline | should probably get tibbs in here, no? | |
| jds2001 | tibbs|h: ping | |
| mmcgrath | what did I offfer? | |
| * mmcgrath is missing some context or something | ||
| jds2001 | mmcgrath: 18:16 < jds2001> this is halfline's proposal to include a checkbox in pkgdb to allow all packagers to commit to a package | |
| nirik | mmcgrath: to write up a threat assessment... but perhaps I am full of it, and it was not you. Let me look again. | |
| mmcgrath | I don't think it was me but it's something we've discussed before. | |
| I haven't looked that closely at it but I'd say this. | ||
| dwmw2 | I see no reason why we should forbid package maintainers from choosing to allow this | |
| mmcgrath | I tend to agree. I think being open is good, especially since someone in packager could just attack their own package anyway. | |
| jds2001 | dwmw2: i just fear that in time we'll end up right back where we started. | |
| * dgilmore is ok with having people allow packager to commit to there packages if they want. they do need to understand that means every packager can touch there package. including those just sponsored | ||
| mmcgrath | The initial threat comes from someone opening up a more popular package and attacking it. | |
| nirik | I am very tired of us changing things around. I would like someone or group of someones to write up a real model that explains the threats and how to protect from them and what cost. Then, I would like to change everything one last time based on that model. | |
| * notting agrees with nirik | ||
| dwmw2 | jds2001: I'm not sure we end up back where we started | |
| nirik | the reason this was removed in this specific case was that sponsors then don't like sponsoring people. | |
| dwmw2 | this doesn't affect the 'want more people to allow provenpacker, so want fewer provenpackagers' dance. | |
| notting | nirik: i'm sure moving to git fixes this | |
| nirik | notting: well, that might fix the cvs commit mail issue. ;) | |
| dwmw2 | nirik: oh, I hadn't heard that one., That's... strange. | |
| nirik | dwmw2: so, if I sponsor someone now they get their own package only. If we allow this then they get their own package and all the ones that set this. | |
| dwmw2 | nirik: that is the deliberate choice of the owners of those packages | |
| nirik | dwmw2: but it affects everyone who uses the distro. | |
| jwb | so does that package | |
| dwmw2 | mostly those with tinfoil hats :) | |
| jwb | that the person initially owns | |
| dwmw2 | this is also true | |
| jwb | rpm runs as root, right? | |
| mmcgrath | nirik: I'll volunteer to do a threat assessment. | |
| notting | jwb: rather hard to have it work otherwise | |
| halfline | i guess the thing is we need to make it clear it's not the sponsor's duty (or burden) to be a whipping boy when the person he sponsors makes mistakes | |
| mmcgrath | Specifically who is my audience? Who am I writing this to? | |
| nirik | I'm not opposed to doing away will all acls personally. I am very opposed to making partial changes all the time. We need a threat model so we can say 'this isn't worth protecting against' or this is solved with this measure easily. | |
| jwb | notting, right. so all it takes is a single package with %post rm -rf / | |
| jds2001 | halfline: but it is their duty. | |
| nirik | mmcgrath: awesome. Well, I would say end users of fedora? | |
| mmcgrath | nirik: you sure you don't want me to write it to FESCo? | |
| jwb | nirik, isn't the audience the packagers? | |
| dgilmore | halfline: we explicitly state that it is there place to do that | |
| jwb | s/there/their | |
| halfline | jds2001: well i'd say that's wrong. i mean the sponsor should be there to show the ropes and explain the process, but he can't be held strictly accountable for the actions of someone else | |
| nirik | well, the end goal here is to provide a secure and as bug free os right? they don't care how we do it... clearly we need maintainers to maintain packages and update things | |
| jwb | accountable for someone else's actions is different | |
| halfline | we should hold people accountable for their actions, not the actions of others | |
| jwb | sponsors are mentors. mentors should be watching for things | |
| jds2001 | right, but who holds them accountable? | |
| jwb | that doesn't mean they can prevent malicious intent | |
| jds2001, who watches the watchmen? | ||
| nirik | but you are right, we need to take into account maintainers too, as they want to be able to do their job as easily as possible. | |
| mmcgrath: so, perhaps it's from several views. ;( | ||
| mmcgrath | nirik: but who's actually going to read the assesment and make changes based off it? | |
| jds2001 | jwb: we do (i.e. we are responsible for sponsor oversight) | |
| nirik | mmcgrath: fesco. | |
| jds2001 | and sponsors are responsible for their sponsorees | |
| mmcgrath | K, and you want me to focus just on CVS access? Or also buildsys and on to distribution? | |
| halfline | i'd say maintainers should be responsible for their packages | |
| and if a maintainer opens up a package | ||
| mmcgrath | me assumes distribution is out of scope. | |
| halfline | it's that maintainers responsibility to watch the package | |
| not the sponsor's responsibility to watch the package | ||
| notting | jwb: i haven't watched them, yet | |
| jwb | notting, heh. saw it last night. was good | |
| halfline | if everyone agrees with me, then we should make sure hte sponsorship guidelines are clear | |
| jwb | have you read the sponsorship guidelines? | |
| halfline | so that tibbs|h et al won't feel pressured by the 'packager' change | |
| yes | ||
| jwb | is there something unclear about them? | |
| nirik | mmcgrath: I think distribution would be out of scope... depending on the line between that and buildsys. | |
| mmcgrath | nirik: k, I'll get to work. | |
| halfline | jwb: well i was saying above that i think their wrong | |
| nirik | mmcgrath: I think that would be great... although I seem to be the only one saying that, so you might see if fesco really wants you to move forward on this first... | |
| jwb | people are having there/they're/their problems today :) | |
| jds2001 | nirik: i do, can't make a decision without being informed. | |
| mmcgrath | so should we +1 -1? Anyone want me to write up a threat assessment to the current model? | |
| * j-rod needs advil and coke, back in a few... | ||
| jwb | mmcgrath, + | |
| 1 | ||
| jds2001 | +1 | |
| j-rod | +1 | |
| sharkcz | +1 | |
| nirik | +1 and I'm happy to provide info or feedback. | |
| jwb | though i still claim it only takes one package to screw stuff up | |
| halfline | guidelines are here fwiw: http://fedoraproject.org/wiki/Package_sponsor_responsibities | |
| nirik | jwb: sure. But on what % of installed machines? and when is the problem detected? | |
| notting | +1 to mmcgrath writing a threat assessment | |
| halfline | and the guideline that I think should be fleshed out more is: "Sponsors also are responsible for fixing mistakes made by their sponsored maintainers if they are unable to do so." | |
| jwb | nirik, good point | |
| halfline | remember any package can obsoletes/provides any other | |
| so from a "security threat" point of view | ||
| sharkcz | there is an area for autoqa to check for at least some malicious actions in packages | |
| halfline | having access to one package is enough to take over | |
| dwmw2 | obsoletes: kernel :) | |
| nirik | to a point. | |
| if you do that then builds might start failing, or if you do it in release it might be seen at push time, etc. | ||
| jds2001 | so let's table this until mmcgrath comes back with a threat assessment. | |
| halfline | sure | |
| just want to make sure we don't forget about the sponsorship guidelines when we consider this issue | ||
| nirik | I think we could solve a lot of the threats or mitigate them, but we should do it all at once, not bandaid. | |
| halfline | also would be good to make sure tibbs is around the next time this is discussed | |
| nirik | halfline: what do you want that guideline above changed to? | |
| jds2001 | sure., I'll cc him on the ticket | |
| halfline | nirik: well there should be an emphasis on the packager fixing his own mistakes. it's sort of weakly implied in the statement | |
| nirik | well, I thought that was covered in 'if they are unable', but sure... | |
| halfline | the only time a sponsor should be held responsible for cleaning up the mess is if the packager isn't competent enough to do it | |
| it's wording thing mainly | ||
| jds2001 | halfline: either incompetent or unwilling | |
| halfline | and there should probably be something in their about how it's not the sponsor's job to watch every commit the pacakger makes to every random module | |
| nirik | or doesn't respond, or asks their sponsor to do it because they don't understand, or when it's serious and they are not able to do it in a timely manner, etc. | |
| jds2001 | the latter obviously being more of a problem. | |
| halfline | jds2001: if they're unwilling to fix the mistakes they make | |
| then they need to have their access revoked | ||
| i basically think the tone of the paragraph should be hinted toward the sponsor being a facilitator | ||
| not a watchdog | ||
| nirik | halfline: yeah, I'd be happy to change wording if you think it needs it... can you draft something? | |
| halfline | or a drill sergeant type thing | |
| nirik: sure, i can come up with draft for you guys to chew on | ||
| i think that was tibbs biggest complaint, was he was worried it would add a lot of undo burden on sponsors | ||
| and i think that was just because we're not messaging what a sponsors responsibilities are quite right | ||
| jds2001 | that page also looks a little out-of-date | |
| abadger1999 | halfline: Well... I think it is a change. | |
| In the past we have said that a sponsor is quite responsible for their sponsorees. | ||
| halfline | abadger1999: sure, i'm just saying it was fuzzy before and leaning toward a direction i think was wrong | |
| abadger1999 | No problem. | |
| Change that's more concrete is good :-) | ||
| nirik | I think sponsors should be mentors/facilitators... but if there is a problem with someone people can ask them to talk to their sponsoree/fix issues/etc. | |
| jds2001 | so shall we move on? | |
| * nirik nods. | ||
| jds2001 | .fesco 21 | |
| zodbot | jds2001: #21 (ext4 default filesystem) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/21 | |
| jds2001 | we said we'd revisit this one. Beta readiness meeting is on Tuesday, I'd like to take this opportunity to get a gauge on where we' | |
| we're at. | ||
| sandeen | yes? | |
| jwb | aside from KDE being dumb and freaking people out, i think we're in good shape | |
| jds2001 | awesome :) | |
| nirik | so, hows ext4 looking sandeen ? | |
| as default that is. | ||
| sandeen | on fedora or on ubuntu? :) I haven't had many bug reports about it .... | |
| i've found & fixed a couple bugs since alpha; the only one reported in fedora was the livecd creation problem AFAIK | ||
| jds2001 | cool, so I'd say we're good to go? | |
| sandeen | and I did put in the paranoid flush-on-close-if-truncated-and-on-rename to try to plug the holes for some of these apps that don't fsync | |
| it seems like it | ||
| assuming people really have been using ext4 in alpha :) | ||
| nirik | the alpha live media was ext3, so we didn't get as much coverage there. | |
| sandeen | true, I dunno how many people use that to install | |
| jds2001 | lots i'd imagine. | |
| sandeen | I didn't get grub to grok ext4 in the end, btw, but I'm not too hung up about that | |
| nirik | so /boot will be ext3? | |
| sandeen | yeah | |
| it's usually separate anyway due to lvm | ||
| * sandeen is used to a separate boot anyway so .... | ||
| jds2001 | yeah, not a biggie | |
| sandeen | hm, it'd be nice if smolts somehow kept track of if the systems were installed via livecd or via normal install | |
| jds2001 | i assume it will grok ext4 in F12? | |
| sandeen | jds2001, I have a patch for it but haven't tested it yet TBH. grub wasn't building in fedora for a while ... not a great excuse but just didn't get it tested | |
| jwb | is it really important either way? | |
| sandeen | if you don't use lvm it might be nice to not *require* a separate /boot | |
| but *shrug* | ||
| jds2001 | not really, just curiousity really. | |
| jwb | everyone seems to be all forgone on btrfs being in for f12 anyway | |
| ;) | ||
| jds2001 | :) | |
| sandeen | I don't think ext4 is *bulletproof* at this point but people seem to be surviving just fine :) | |
| my only concern is the bugs reported outside fedora; I hope that this doesn't mean it didn't actually get much use in alpha | ||
| jwb | that's ok. we're looking for enterprise, not military | |
| sandeen | but, those are getting fixed too. :) | |
| drago01 | sandeen: kill the flex_group printk | |
| jwb | (poor joke) | |
| drago01 | ;) | |
| sandeen | drago01, oh, yeah | |
| ted did send a patch for that, too | ||
| * sandeen will do that today | ||
| j-rod | I've pretty thoroughly beat the crud out of ext4 from an end-user point of view | |
| no issues here anytime lately | ||
| jds2001 | cool. Anything else folks wanna bring up for the beta readiness meeting? | |
| * jds2001 has nothing really, wondering what other folks have. | ||
| jds2001 assumes that means nothing :) | ||
| jds2001 | we have one more item, the CC repo | |
| wanna push that to next week, or do we wanna discuss that now? | ||
| abadger1999 | sandeen: What will the default setting for ext4 be WRT the safety vs performance of delayed alloc? | |
| Just asking what our mount options will default to. | ||
| sandeen | they'll be default | |
| all this hubbub... the same window was in ext3, but smaller | ||
| abadger1999 | <nod> | |
| sandeen | I know that does matter in the end ... | |
| so, I think we should leave delalloc on, but there are also these fsync patches added | ||
| they will probably get cleaned up before .30; but worst-case for beta is that they are a little heavy-handed | ||
| I'd rather be a bit slower and safer than run out of town on a rail by kde users ;) | ||
| abadger1999 | thanks | |
| notting | sandeen: do they print out which apps need fixed? :) | |
| sandeen | (the patches essentially sync the file on close if it has been truncated to 0, or if it is renamed over an existing file) | |
| notting, I prefer the fs to not be a nanny | ||
| we could pop up a window saying "an application has requested a close without fsyncing. are you sure? [y/n/wtf]" | ||
| notting, in all seriousness I don't think we can know. it's the apps job to know if its data needs to be persistent at that point | ||
| * nirik needs to go soon. | ||
| jwb | sandeen, complete with shifting sysfs paths for the kernel events? | |
| drago01 | sandeen: can we have a -o idontcareaboutbrokenapps mount option? | |
| jwb | drago01, no... | |
| sandeen | -ETOOMANYKNOBS | |
| I hope to make the fsyncing a bit less heavyweight so that if some other fsync handles it in the normal course of the file's life (if, say we come across some ap that actually does it...) it'll clear the sync-on-close flag | ||
| ... this is how xfs does it | ||
| jds2001 | alright, shall we put a fork in this meeeting and delay the CC repo to next week? | |
| we'll cover it first next week j-rod :) | ||
| j-rod | worksforme | |
| dwmw2 | I thought we were trying for three hours... | |
| jds2001 | hehe | |
| * jds2001 ends the meeting in 15 | ||
| mejla just wants to remind that voting on his membership in the provenpackager group has been deferred to today's meeting to be able to get input from sponsors...will be delayed too? | ||
| jds2001 | oops, yeah we're pretty much out of time :) | |
| mejla: can you file a trac ticket so I don't forget? | ||
| * jds2001 is a forgetful person | ||
| mejla | jds2001: ok...I'll request membership in fas again, right? | |
| jds2001 | yeah, that'd work too. | |
| mejla | jds2001: (I've been added and again removed by you last time, so there is now no request) | |
| jds2001 | right, sorry about that. | |
| * jds2001 got click-happy :) | ||
| sharkcz | mejla: you can create the ticket at https://fedorahosted.org/fesco/ | |
| jds2001 | i owe a few sponsor nominations still. | |
| mejla | sharkcz, jds2001: shall I *both* file the ticket and re-request? | |
| jds2001 | just filing the ticket would do. | |
| I can manually add you after it's approved. | ||
| mejla | jds2001: ok | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!