| bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| * jwb is here | ||
| * nirik is here. | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
|---|---|---|
| * warren here | ||
| bpepple | Hi everybody; who's around? | |
| * tibbs here | ||
| jeremy | ||
| dgilmore is here | ||
| * bpepple waits another minute or so before starting. | ||
| * warren thinks the newpackager idea needs more development because there is too much confusion surrounding it currently. | ||
| warren will continue to work on clarifying it for next week. | ||
| notting is here | ||
| bpepple | ok, let's get started. | |
| --- bpepple has changed the topic to: FESCo-Meeting -- F9 Status - all | ||
| bpepple | Have any blockers beside the gpg-import issue came up? | |
| f13 | I'm here | |
| notting | well, there's the blocker list | |
| f13 | although my laptop is kind of fubar and I'm trying to fix that. Somehow libgcc went missing | |
| notting | there is a bug where udev falls over during the install, causing partitioning to fail. it is not characterized yet, but we may have a workaround | |
| emacs still isn't fixed | ||
| * c4chris here now | ||
| notting | there's a variety of other things. do we really want to go through them one by one? | |
| jwb | no, i think we're just looking if it's going to slip more | |
| bpepple | notting: no, I was just checking to see if there was anything major blocker showing up. | |
| caillon | i think the plan is still to do a final compose later tonight | |
| notting | well, RC1 | |
| caillon | well, hopefully final compose ;) | |
| caillon | assuming it's awesome and we don't need another one ;) | |
| tibbs | So the absolute latest time for tag requests has essentially passed? | |
| jwb | no | |
| notting | if you've got a blocker fix... | |
| caillon | not quite. | |
| tibbs | It's just that people do ask, and I'd like to know just when the cutoff is so that I can answer them.[ | |
| dgilmore | tibbs: another 6 hours? | |
| jwb | tibbs, you can probably just point them to f9 updates being available for 0 day fixes | |
| caillon | well, even after RC1 if something is majorly broken, we'll still take and tag it. | |
| jwb | unless they have a fix for a blocker bug | |
| bpepple | I was just looking to see if any major problems had cropped up. If no one has anything else, we can probably move on. | |
| caillon | tibbs, if they have to ask, they probably should just go the updates-candidate route | |
| bpepple | caillon: +1 | |
| dgilmore | caillon: indeed | |
| caillon | generally real blockers are "shit, we NEED this" not "hm, i wonder if i can get this in still" | |
| notting | bpepple: define problems. things taking a long time to fix? *new* bad issues? etc? | |
| jwb | things that will cause us to slip | |
| notting | well, if fesco is ok with emacs not having the epoch... | |
| bpepple | notting: I was thinking new bad issues that could cause a slip. | |
| jwb | things that make you go hmmmm | |
| caillon | notting, didn't we resolve that last week? | |
| bpepple | notting: wasn't dgilmore going to help chip? | |
| jwb | forgive me, but i was missing last week. epoch for what? | |
| notting | caillon: we resolved that something should be done. it hasn't happened | |
| f13 | caillon: we still haven't gotten a new build with all the right epoch junk. | |
| dgilmore | bpepple: yes | |
| caillon | crimony | |
| f13 | turns out, it's needed in a number of places, and I'm not confident we'll find all the places in time | |
| particularly because the maintainer has never even heard of epoch before | ||
| dgilmore | f13: what can i do to help? | |
| f13 | dgilmore: send chip a patch? | |
| caillon | f13, well that's one good thing at least. it's a shame we have to tell him about it. | |
| f13 | make sure said patch interacts with the whole world of emacs packages | |
| caillon: not really good /after/ the final freeze. | ||
| dgilmore | f13: ok | |
| f13 | emacs packaging is fragile at best, this is why I really really didn't want to introduce epoch here. It's needlessly complicating things /more/ and in non-obvious ways | |
| caillon | f13, good being "oblivious to epoch". i wish i were oblivious to it too | |
| jwb | wait, is this the "emacs was out there for 2 days and we reverted to an older version" thing? | |
| notting | yes | |
| caillon | 5 days | |
| and yes | ||
| jwb | and we're forcing epoch for what reason (sorry again) | |
| dgilmore | f13: regardless of that. we have to. the higer release package was out there | |
| f13 | dgilmore: "have to" is rather... false. | |
| dgilmore | jwb: because emacs got reverted to an older version | |
| f13: no its not | ||
| jwb | and? | |
| f13 | you are /choosing/ to by blindly following the guidelines instead of applying a little bit of reason here | |
| warren | NOTE: We did agree to stop reverting without epoch in a FESCO vote during the last cycle. | |
| f13 | warren: within reason. | |
| jwb | was the higher version in Preview? | |
| f13 | warren: I'm almost certain that we left some provision for logic to apply instead of rubber stamping. | |
| jwb: no. | ||
| wwoods | it was released as an update post-f9pr | |
| jwb | ok wtf guys | |
| caillon | jwb, no, but anyone that yum updated would have got it | |
| f13 | jwb: preview -> final has a clean upgrade path. | |
| warren | it happened between beta and preview? | |
| wwoods | no, between preview and now | |
| f13 | warren: no, it happened /post/ preview | |
| * nirik suspects that pretty much anyone who installed PR would yum update after it... | ||
| jwb | caillon, i find that reason to be lacking in this case | |
| jeremy | f13: and it's now been there for nearly *two weeks* for people that were running the preview. who will then have their upgrade path broken to final | |
| jwb | however i'm not going to rehash the argument | |
| jeremy | f13: yes, it's painful. yes, it sucks. but pain is how learning happens. | |
| f13 | jeremy: no, it was only there for 5 days before the old one got put back, so only people who updated in those 5 days would be stuck. | |
| caillon | nirik, not necessarily so. i'd bet a lot of them were just live cds that tried it and then went back to F8 or something and are just waiting for final | |
| jeremy | <insert reference about telling people the stove is hot vs having them burn themselves on it here :-> | |
| warren | emacs isn't in any default install right? | |
| I don't have it here. | ||
| wwoods | In F10, I need someone to help me write a tester-notification applet | |
| f13 | warren: no, it's optional. | |
| wwoods | installed and enabled by default for all non-final releases | |
| notting | f13: not an old one. a different new one. | |
| wwoods | that lets us push messages to testers | |
| nirik | caillon: sure, and those wouldn't have emacs... | |
| caillon | right | |
| warren | you would only have the higher version if 1) You actually manually installed emacs 2) you updated during those 5 days | |
| f13 | notting: well sure, the build we'd like, minus epoch. | |
| caillon | that was sorta my point | |
| wwoods | since we don't have that yet... | |
| notting | f13: which apparently still has other blockers. whee! | |
| jwb | anyway, i would have been -1 on requiring the epoch, but unless we're readdressing it now it doesn't matter | |
| f13 | but whatever. It was my choice, not the maintainers. He'll happily do whatever we force him to do. | |
| tibbs | . | |
| caillon | heh | |
| tibbs | Crap. | |
| f13 | but given his inexperience with epoch, and the fragility of the emacs stack, he's really going to need a hand with this rather than a cold "go put in an epock, kthxbye" | |
| c4chris | tibbs: ? | |
| nirik | well, I was +1 on the epoch, but given nothing has happened on it, perhaps we should revisit... if we want a RC tonight. | |
| caillon | can't we just rip it out and declare vim the winner? :) | |
| tibbs | I was trying to find the meeting where FESCo agreed that it wouldn't do rollbacks like this. The "." was intended for my mail reader. | |
| jwb | caillon, yes | |
| f13 | honestly folks, I don't think we'll be spinning an "RC" tonight | |
| jwb | nor i | |
| caillon | no? | |
| ok | ||
| f13 | I'll likely spin something just to update the caches on the compose box | |
| but if we want the builds we're getting from today in the RC I'm going to wait for tomorrow | ||
| caillon | f13, that's good to know for that other thing i mailed rel-eng about. | |
| f13 | composing is /far/ easier if the content we want made it into a rawhide. | |
| notting | do we want to talk about the key stuff? | |
| f13 | notting: key stuff? packagekit ? | |
| bpepple | have we resolved the emacs issue? | |
| notting | dgilmore: were you going to help with a patch? if not, i can | |
| dgilmore | notting: i will | |
| notting: ill ping you if i need help | ||
| * caillon has a theory that all packages will eventually gain an epoch | ||
| warren | Caillon's Theorem | |
| spoleeba | caillon, im personally holding out for complex numbers so I can have an imaginary epoch | |
| notting | f13: well... there's something in PK now. but it's bad. and still somewhat broken | |
| f13 | caillon: wouldn't be so bad if epoch were more visible and less um... special? | |
| nirik | soon we will need a MetaEpoch to override Epoch. ;) | |
| f13 | nirik: superepoch | |
| notting: vunderbar. | ||
| caillon | f13, like release tree + build date? | |
| f13 | notting: what's the short and dirty? | |
| nirik | dgilmore / notting: let me know if I can assist as well with that. | |
| notting | f13: it aborts the transaction in the middle, making you close the window, refresh pk, and restart it. and it's not triggered in one of the update paths | |
| f13 | notting: *sigh* | |
| caillon | f13, EpicEpoch :) | |
| f13 | notting: yeah, that should be... fixed. | |
| warren | what was the emacs conclusion? | |
| f13 | notting: let me guess, the PK guys are throwing rocks at us for not importing the key automagically somewhere else? | |
| warren: dgilmore is sending chip a patch | ||
| notting | which brought up the suggestion of importing the keys during install... | |
| warren | f13: that does what? | |
| * dwmw2 arrives; sorry | ||
| caillon | that bumps the epoch, presumably | |
| f13 | warren: correctly applies epoch. | |
| notting: yeah, still no good story there right? | ||
| * nirik notes that anything else that requires a specific version of emacs or buildrequires it will need the epoch fix as well... we will need to identify those. | ||
| jwb | this sounds like pain | |
| c4chris | nirik: yea, makes me cringe a bit... | |
| f13 | nirik: there are... many | |
| caillon | how many? | |
| tens? hundreds? | ||
| notting | nirik: most of those requires are automatic. also, they wouldn't need rebuilt right now | |
| f13 | which makes one wonder, why is this a good decision to do /now/ when the new emacs is coming in short time, but we'll be forced to live with epoch for ever? | |
| nirik | I don't see that many... | |
| f13 | nirik: many was like 10~ | |
| notting | f13: because the new emacs isn't even a prerelease, so why the hell would that be coming soon anyways? | |
| f13 | notting: that's what chip told me | |
| bpepple | caillon: I thought we identified something like 12 packages. | |
| f13 | notting: or maybe I misunderstood him. | |
| nirik | emacs has a very slow release cycle I thought... although it has new maintainer(s) now. | |
| f13 | but whatever, I'll stop dropping hate bombs and move on. | |
| notting | emacs 23 is the 'future' release | |
| caillon | except now it's in the past since you forgot the epoch :P | |
| f13 | notting: so who's going to bend, installer folks in pre-importing whatever keys they can find, or PK in doing the prompt/import correctly? | |
| warren | it was in rawhide 5 days after preview, it requires rebuilding 12+ other packages, maybe it isn't worth doing. | |
| notting | f13: i expect stalemate! | |
| wwoods | we *have* stalemate | |
| warren | What is the argument against pre-importing? | |
| nirik | pre-importing seems like a loss... since there also will be 3rd party repos... | |
| jwb | then FESCo needs to make a declaration | |
| notting | warren: doesn't require rebuilding anything yet, as all the dependencies will currently be correctly satisfied | |
| f13 | warren: feel free to try and push that though FESCo. | |
| dgilmore | f13: i expect that PK gets slapped into shape | |
| f13 | dgilmore: in 11 hours? | |
| wwoods | We have a (terrible but functioning) UI for importing keys | |
| in PK | ||
| dgilmore | f13: i can dream | |
| notting | wwoods: it isn't functioning yet | |
| f13 | wwoods: yet notting says it's broken still. | |
| * warren tries to make that UI pop up... | ||
| wwoods | requiring all users to go through that UI is almost cruel | |
| partially functioning? | ||
| * nirik would much rather PK be beaten into working... any chance of that? are they trying to get it working? or pushing for the pre-import instead? | ||
| wwoods | nirik: it's a planned feature for PK 0.2.x, due sometime later in May | |
| caillon | nirik, both. | |
| warren | threaten to go back to pup/pirut if they don't bend | |
| wwoods | we only need it for F9 because we're not (and have never) importing the key during install | |
| notting | wwoods: which is a much shorter patch, fwiw | |
| wwoods | importing the key during install? | |
| absolutely | ||
| jwb | then why is that bad? | |
| wwoods | far more sensible in my opinion - import one key and this problem goes away unless you install with third-party repos | |
| and then you have to see the ugly dialog | ||
| bpepple | wwoods: seems reasonable. | |
| nirik | ugly dialog in PK? or ? | |
| notting | i know jeremy didn't like the idea in the past. jeremy? | |
| wwoods | also it allows us to push out a fixed PK with a much more sensible dialog | |
| without forcing people to go through the ugly UI | ||
| nirik: in PK | ||
| tibbs | Plus, we can fix the ugly dialog but what's in the installer will be frozen forever. | |
| wwoods | I have a screencast | |
| tibbs: exactly | ||
| caillon | nirik, yes, but the fact that anything ever asks the user to import a key is ugly, too. | |
| tibbs | SO we need to decide on fixing the installer, like, now. | |
| wwoods | http://wwoods.fedorapeople.org/screenshots/key-import-fun.ogv | |
| f13 | I seem to remember that one of the problems was discovering which key and where to import. | |
| (during install) | ||
| jeremy | right | |
| on every single install path | ||
| and "wtf does it mean for upgrades" | ||
| wwoods | there's one other possiblity | |
| do it in a firstboot module | ||
| warren | PK needs to handle key importing for arbitrary keys defined in /etc/yum.repos.d | |
| jeremy | with the added little wrinkle of the installer team basically being down to having laptops to work on right now | |
| notting | jeremy: upgrades is 'you don't' | |
| warren | it is an incomplete solution to expect the installer to pre-import | |
| notting | jeremy: want the patch? | |
| wwoods | warren: yes, that's the planned feature | |
| you don't need key import on upgrade - they should already be there | ||
| f13 | wwoods: until we change the key on y our | |
| tibbs | If you install from F8 media and then upgrade, the keys won't be there. | |
| f13 | you | |
| jeremy | notting: I feel *very* uncomfortable with shoving that significant of a change into the installer at the last minute | |
| jwb | jeremy, what does the laptops thing have to do with this? | |
| wwoods | obviously the tools need to be able to import keys | |
| f13 | which we may when we get the signing server. | |
| wwoods | nobody is debating that | |
| jeremy | jwb: significantly impedes the ability to test | |
| notting | jeremy: http://fpaste.org/paste/1985 . if it fails.... you get what you have now | |
| warren | gah, PK can't handle installing i386 of a package if the x86_64 is already installed. That is stupid. | |
| jeremy | jwb: the westford office is moving tomorrow and so everything is packed up | |
| f13 | warren: you sure that's PK failing and not the rpm having conflicts? | |
| warren | oh | |
| jeremy | notting: uhhh, and auto-import things like the beta key? | |
| wwoods | but: typical PKI setups start with at least one trusted key. and I can find no real justification for not trusting our own key(s) by default. | |
| notting | jeremy: see... HAAACK | |
| wwoods | Yeah I think you only want /etc/pki/rpm-gpg/RPM-GPG-KEY | |
| f13 | wwoods: I don't think anybody argues that. The real problem is discovering /which/ key is the /right/ key in a non fedora-specific way | |
| caillon | wwoods, agreed | |
| notting | wwoods: you do not want to hardcode a file name | |
| wwoods | check the key ID for a specific RPM and import that one? | |
| jeremy | notting: see "NOT COMFORTABLE" ;-) | |
| warren | "Do you want to import key 4F2A6FD2 from fedora for celestia?" | |
| No Yes | ||
| jeremy | wwoods: umm, key id mapping to file name is basically impossible | |
| nirik | so I guess I would say see if the PK guys can fix this today... ? if not, move to HAAAAACK? | |
| notting | jeremy: 'keys installed by packages in your install set' is a better metric than 'hardcode a specific file' | |
| warren | what is wrong with this? | |
| jwb | wait... | |
| caillon | warren, only everything! | |
| wwoods | UI atrocity aside - it halts the transaction and you have to restart it manually | |
| warren | ah | |
| nirik | wwoods: can that be easily fixed? like today? | |
| wwoods | which will suck for all those people installing F9 in a few weeks when there's 50-100 updates | |
| notting | and it's only wired up on some of the install paths | |
| warren | any UI we fix today wont be translated | |
| wwoods | nirik: it is not an easy fix. | |
| jeremy | notting: also, doesn't fix livecds. although I guess that could be hacked with the live image config | |
| notting | jeremy: cut & paste! :P | |
| jeremy | notting: but seriously, when we get to changing multiple places to work around a deficiency, it kind of spells Doing It Wrong (tm) | |
| wwoods | there is no escaping the Wrongness here | |
| f13 | I seem to recall pirut/pup/yum all handling this fine... | |
| bpepple | wwoods: agreed. | |
| wwoods | the question is whether that UI is more wrong than figuring out all the places to import the keys | |
| and which keys to import | ||
| f13: yep. hughsie didn't realize that we don't trust our own keys by default | ||
| he just assumed we did. | ||
| until.. this past weekend | ||
| tibbs | I'm still watching that screencast. Honestly from what I've seen, if we can't fix this we need to slip the release. We can't let things go out that way. | |
| warren | I'm afraid I agree. | |
| dgilmore | wwoods: he should know to ask never assume | |
| warren | this is rather embarassing | |
| wwoods | that screencast is somewhat contrived - normal users will only have to import one key on their first update | |
| but it illustrates the problem. | ||
| notting | jeremy: obviously anaconda needs to use actual repos, not make them up on the fly. hm. | |
| wwoods | dgilmore: yes, he should. unfortunately he didn't and now we are boned. | |
| spoleeba | wwoods, i think a lot of 'normal' people include livna pretty early into an install..but ive no metrics on that | |
| wwoods | unless we slip the release again we don't have time to do this right | |
| jeremy | notting: slowly getting there... | |
| dgilmore | wwoods: is he in the boston area? | |
| f13 | no | |
| UK | ||
| which means his day is nearly done already | ||
| dgilmore | crap i cant go stand over his shoulder | |
| wwoods | we can ping him, I had asked him to be available late(ish) today/friday/monday in case this stuff came up | |
| * dwmw2 can go stand over his shoulder :) | ||
| f13 | I'm dragging him into here | |
| nirik | dgilmore: we can chip in for a plane ticket for you. ;) | |
| f13 | I bring you hughsie-afk | |
| caillon | Richard! | |
| dgilmore | dwmw2: please do | |
| warren | he's afk | |
| hughsie-afk | i'm sortof afk | |
| * dwmw2 bows to f13, the master of the summoning dance | ||
| hughsie-afk | i'm setting up HW | |
| f13 | hughsie-afk: we've been discussing (to death) the current problem with key imports | |
| f13 | hughsie-afk: and the general consensus is that what's in rawhide right now isn't accepable for the release so we'd slip the release for something better. | |
| hughsie-afk | f13: ohh wow | |
| nirik | but ideally something could be fixed up fast to make it acceptable. ;) | |
| warren | The UI is embarrassing as is, and halting the transaction is very user unfriendly. | |
| hughsie-afk | f13: i only hacked in support (about 5 hours work) for the release | |
| 0.2.0 (which has better key import dialogs etc) is only about a week from release | ||
| f13 | hughsie-afk: right, I think we understand that, but unfortunately, we're asking for more :/ | |
| f13 | or we're going to slip the release to somehow pre-import the key somewhere | |
| warren | But even if the UI were improved is something so centrally used acceptable without translations? | |
| hughsie-afk | f13: well, PK has to restart the transaction - it's the way it's designed | |
| f13 | which.... yikes. | |
| warren: translations can come very quickly after release | ||
| hughsie-afk | f13: the real problem is that fedora does not trust it's own GPG keys, which is JUST BROKEN | |
| caillon | f13, which i think is the right decision in the long run (pre-importing our key) | |
| warren | Didn't we establish that pre-import really isn't a solution because it doesn't handle arbitrary other keys? | |
| tibbs | restarting the transaction would be OK; saying that things are finished when it didn't install any updates is the problem (at least as I see it). | |
| warren | f13: "after release" is exactly when people will never see it since they need to import keys before they update. | |
| hughsie-afk | warren: sure, but the installing livna stuff is easy as you do the key import on the first install | |
| not eh first update | ||
| f13 | hughsie-afk: whether or not it's broken, that's just the way it is (since you know, we have no control over the media mirrors or folks that hand out media, so the trust is just not there right now) | |
| * nirik nods at tibbs | ||
| dgilmore | hughsie-afk: its up to the user to trust them not us | |
| hughsie-afk | dgilmore: we ship them on the CD | |
| wwoods | if we import the default keys that UI won't come up unless you enable a 3rd-party repo | |
| f13 | warren: We suck again. Untranslated but working is a far sight better than translated and broken. | |
| hughsie-afk | dgilmore: if a user is running an untrusted CD then the gpg signing is a pointless activilty | |
| wwoods | and even then, it'll be ugly just for that window of a couple of weeks | |
| hughsie-afk | i'll repeat: not signing the fedora and fedora-updates key is JUST BROKEN | |
| f13 | hughsie-afk: arguing about auto-import at this point is futile. It won't get fixed in the next 11 hours. | |
| * abadger1999 nods at wwoods | ||
| hughsie-afk | f13: i can't release 0.2.0 in the next few hours - it's had zero QA | |
| f13 | hughsie-afk: the past 20 minutes have been discussions about the difficulties of picking the /right/ key to autoimport through /all/ of the anaconda install/update paths. | |
| notting | f13: bah. you'll always get the right key. you'll just get a few extras | |
| dgilmore | hughsie-afk: the user should make a concious decision to import the key. | |
| hughsie-afk | what about importing /etc/pki/fedora* ? | |
| dgilmore: NO | ||
| wwoods | hughsie-afk: that's what notting's patch does | |
| hughsie-afk | dgilmore: what's the point? | |
| notting | f13: we can 'fix' that by not shipping keys that don't belong to the repos in fedora-release | |
| dgilmore | hughsie-afk: so that you can verify manually the keys are correct | |
| tibbs | Yeah, asking the user is just another dialog they don't know how to answer, so they'll click yes. | |
| hughsie-afk | dgilmore: do you agree to "RANDOM NUMBER THAT NOBODY CHECKS"? | |
| dgilmore | hughsie-afk: if you so choose | |
| notting | f13: actually, why *do* we do that? | |
| f13 | notting: we only ship the Fedora keys | |
| I thought | ||
| wwoods | if we only ship the Fedora keys, what's the objection to importing them? | |
| hughsie-afk | tibbs: totally, it's a waste of time | |
| f13 | oh bother, looks like I forgot to cull some of them. | |
| jwb | hughsie-afk, i check it | |
| warren | A simple solution to the "break transaction" problem might be to offer to import keys BEFORE you choose packages. | |
| f13 | wwoods: you suddenly trust the beta key and there is no stop from installing beta stuff? | |
| notting | warren: the data isn't there then | |
| f13 | wwoods: which, I'm campaigning to remove the sillyness of mulitple keys anyway | |
| hughsie-afk | ubunutu doesn't ask the user "do you trust ubuntu?" and then ask the user "do you trust ubuntu-updates?" | |
| f13 | notting: the data is in the yum repo files no? | |
| tibbs | Can we do something trivial like hack the firstboot initscript to import the keys once when it runs? | |
| notting | f13: yum repos aren't in the installer. at least, not like that | |
| f13 | notting: I do believe 'before you choose packages' was a PackageKit level thing | |
| hughsie-afk | tibbs: sure, that would work | |
| notting | i'd much rather do the installer rather than assume firstboot gets run | |
| wwoods | a firstboot module could import all key required by the installed repo files, but that only works for people who run firstboot | |
| warren | notting: what data specifically? | |
| hughsie-afk | dgilmore: furthermore, when you are selecting packages in anaconda, you don't have gpg checks. security game over if you don't trust the media. | |
| f13 | hughsie-afk: here's the thing, I don't really think anybody is arguing against importing keys by default. What we're arguing is wiring that up at the 11th hour and having little to no testing of it. | |
| notting | warren: the repodata does not have info on what packages are signed by what) | |
| hughsie-afk | f13: what's the alternative? | |
| warren | notting: it does know about .repo files and keys defined in there | |
| notting | f13: *cough* written and tested (once) | |
| warren | notting: if key defined that is not already imported? | |
| wwoods | f13: but the alternative is.. wiring up PK UI at the 11th hour and having little-to-no-testing | |
| tibbs | I'm just trying to come up with the simplest method for doing this that doesn't involve something we can't possibly fix after release. | |
| f13 | hughsie-afk: the alternative is getting you notting and jeremy in thunderdome so that a solution is found. | |
| hughsie-afk: I'm just the release guy trying to get a release out, and I've got a stonewall happening. | ||
| jwb | tibbs, the simplest method is to just tell people to run yum update manual after install to have it import the keys | |
| f13 | wwoods: or reverting to pup, which seems to have working code for this. | |
| wwoods | jwb: augh god | |
| we will get so many bug reports | ||
| nirik | jwb: or just have no updates. ;) <--- joke | |
| tibbs | Are either of those actually acceptable? I don't know; I never run any of this fancy gui package management stuff. | |
| spoleeba | nirik, that's more likely | |
| nirik, the people who know how tofile bugreports..will go to cmdline and run yum and fix it | ||
| f13 | spoleeba: wrong | |
| hughsie-afk | f13: does pup ask you three gpg questions on update? | |
| spoleeba | nirik, the people who dont file...wont be getting updates..and we wont know about them | |
| wwoods | hughsie-afk: it does | |
| f13 | spoleeba: every time I accidentally have something unsinged hit rawhide, the slew of bug reports is enormous. | |
| wwoods | hughsie-afk: but it doesn't restart the transaction | |
| f13 | hughsie-afk: if it has to, yes. | |
| hughsie-afk | wwoods: so the user doesn't get updates until he agrees to something to with GPG? | |
| nirik | a) hack PK more at the 11th hour, b) hack anaconda at the 11th hour, c) slip release for a or b to happen? any other alternatives? | |
| wwoods | hughsie-afk: yep | |
| f13 | hughsie-afk: and it doesn't restart the transaction either. | |
| spoleeba | f13, oh you'll get bugreports.. im just saying lack of updates will be more likely across the userbase | |
| wwoods | but seriously.. reverting to pup? now? isn't that what I was arguing we should stick with at Beta time? | |
| spoleeba | f13, from a percentage basis | |
| caillon | nirik, d) LA LA LA LA NOTHING TO SEE HERE | |
| tibbs | nirik: Hack something else to import the keys at boot. | |
| wwoods | it's far too late for me to enjoy any "toldja so" after so many weeks telling people PackageKit was the Only Possible Choice and the Decision Had Been Made | |
| f13 | wwoods: well, I'm just not exactly happy at getting our hands forced on a feature we're not ready to create (auto imported keys) | |
| hughsie-afk | i really don't see why keys can't be imported in anaconda or firstboot - problem solved | |
| tibbs | Look, I don't care if it's firstboot or some other package we cook up and put in @base. Hell, put it in rc.sysinit for all I care. | |
| f13 | hughsie-afk: convince jeremy | |
| * jeremy knows the end result here. we're going to end up taking the anaconda hack (.. because that's what we always bloody do) and I'm going to be bloody annoyed baout it | ||
| hughsie-afk | tibbs: totally | |
| jeremy | let's just move on and get something useful done today | |
| but this better be fixed in PackageKit for f10. because the hack will not live anywhere but the branch and I will not bring it back. | ||
| wwoods | If we have to take an 11th-hour hack, I prefer the one that's transparent to the user | |
| jeremy: I think we can agree to that | ||
| hughsie-afk | can sombody please answer me straight: why does fedora not trust it's own updates? | |
| jwb | hughsie-afk, we don't trust mirrors | |
| :) | ||
| jeremy | hughsie-afk: where do you get the key from? the fingerprint *does* matter and people do check it | |
| spoleeba | jeremy, i'll put it on my list of things to beat people up about early for f10 | |
| notting | jeremy: what's the hack about it? that it's importing keys, or that it's doing it via the shotgun method? | |
| hughsie-afk | jeremy: the key is in /etc/pki/ | |
| notting | jeremy: also, you want to do it in livecd install or livecd creation? | |
| jeremy | hughsie-afk: which came from where exactly? | |
| nirik | probibly should be livecd creation. | |
| hughsie-afk | jeremy: the cd media | |
| f13 | hughsie-afk: which came from where exactly? | |
| nirik | since people will run PK on their persistant live boot... ? | |
| hughsie-afk | jeremy: if you don't trust the media, then you've got bigger problems than not importing the correct key | |
| spoleeba | nirik, with the persistence layer for liveusb..we'd need it at creation right? | |
| jeremy | hughsie-afk: welcome to the larger world where NOT EVERYONE INSTALLS FROM CDS | |
| spoleeba | nirik, does the persistance layer let you..install things? | |
| jwb | jeremy, no kidding | |
| * abadger1999 agrees with hughsie -- if you can't trust the media you're installing from, you're already screwed. | ||
| nirik | spoleeba: yes, and yes | |
| jeremy | but you know, it's easier to ignore things about the world that you don't like | |
| but not getting into that discussion | ||
| I have better things to do than getting into this pissing match | ||
| f13 | jeremy: clearly we need to sha1 and gpgsign the boot.iso and kernel images, and post them somewhere to utterly confuse all users with tonns of checksums and gpg signs and such. | |
| jwb | crap, have to leave for real life meeting | |
| hughsie-afk | jeremy: it's not a pissing match. this is about security through obscurity | |
| I have a meeting too. | ||
| jwb | i'm +1 for the anaconda hack, as much as it sucks | |
| notting | jeremy: put it this way. you're not losing any security you haven't already lost by blindly trusting what you just installed like we do now | |
| caillon | what's to stop a rogue install source from simply hardcoding "Do you want to import $GOODKEY for Fedora? [y] n and then manually running rpm --import whatever | |
| * warren realized that livecd-creator doesn't check gpg sigs either... | ||
| hughsie-afk | I'm sorry, but can somebody please make a decision and then tell me what they want me to do. thanks. | |
| jeremy | notting: we should probably do it in the livecd config because if the idea is to avoid making people deal with shit ui, we should make sure they don't have to deal with shit ui when using the livecd | |
| caillon | the question is meaningless because if someone really wants to put crap on your computer ,they will with or without the question. | |
| f13 | hughsie-afk: it looks as if we're going to auto-import in anaconda for F9. Cannot state that will be the same for F10 | |
| caillon: then why do we sign teh packages in the first place? | ||
| notting | hughsie-afk: well, there are still bits that need fixed (getting it wired in right for right click->install updates, for instance). and resetting the state would be nice | |
| wwoods | but by F10 PK will have proper GPG key importing UI/code | |
| spoleeba | caillon, i have an rpm repository which actually relies on a fake Fedora key | |
| warren | pre-live image creation or during live runtime? | |
| f13 | 'cause without signing them live gets really easy for me. | |
| hughsie-afk | notting: i can fix that in an hour if you want | |
| jeremy | warren: in the image config | |
| notting: and really, since this is an f9-branch-only-hack, I'm going to hard code just the fedora and updates keys. to make it all the more clear that it's wrong | ||
| caillon | f13, because it gives people something to feel good about? | |
| wwoods | I thought there was only one 'fedora' key? | |
| f13 | wwoods: fedora, and fedora-rawhide | |
| er, fedora and rawhide. We re-use rawhide for udpates-testing | ||
| notting | jeremy: what-ever makes you feel better about it. after all, it's anaconda's fault that you can't do it right :P | |
| warren | Is that our decision then? | |
| nirik | ok, so anaconda and livecd-tools get hacked for now... ? | |
| wwoods | ah. now it all makes sense. Not sure why I can't keep the keys straight in my head | |
| bpepple | warren: I believe so. | |
| notting | f13: wait, not fedora-test? | |
| wwoods | the anaconda/livecd-tools hacks are F9-only, and can (should) be removed for F10 | |
| if they ever hit the F10 branch at all | ||
| bpepple | alright, is there anything else we need to discuss regarding F9? | |
| warren | we're out of time | |
| bpepple | warren: agreed. unless there is anything else pressing we should wrap up. | |
| * wwoods supposed to be in another meeting | ||
| f13 | Fedora Project <fedora@redhat.com> | |
| Fedora Project (Test Software) <rawhide@redhat.com> | ||
| jwb | bpepple, sponsors | |
| f13 | Those are the two keys, for maximum confusion. | |
| jwb | anyone have any new sponsor nominations? | |
| you have 30 seconds | ||
| notting | f13: right. the rawhide key is different ;) | |
| f13 | huh? | |
| caillon | someone self-nominated on the list | |
| i forget who | ||
| tibbs | deleroy. | |
| caillon | +1 | |
| f13 | notting: I don't understand that statement. | |
| tibbs | Denis Leroy, new FPC member. | |
| +1 | ||
| jwb | +1 | |
| notting | f13: that is RPM-GPG-KEY-fedora-test. RPM-GPG-KEY-fedora-rawhide is different. | |
| +1 | ||
| nirik | +1 for deleroy | |
| f13 | notting: we don't use fedora-rawhide. | |
| tibbs | I mean, if we can't trust the FPC to know packaging, then.... | |
| warren | +1 | |
| f13 | notting: but we /do/ use rawhide@redhat.com | |
| c4chris | +1 | |
| f13 | notting: the naming of them... came before me. | |
| jwb | that's 7. delroy is a sponsor | |
| oh wait | ||
| damn, only 6 | ||
| oh, no 7 | ||
| * jwb has trouble counting and talking at the same time | ||
| jeremy | +1 for deleroy | |
| caillon | no 8 | |
| bpepple | didn't we decide long ago that sponsors need to be announced on the list, and then the following week we vote on them? | |
| jwb | ok. delroy is a sponsor | |
| spstarr_work | wwoods: ugh, and here I am building a new DVD...I can just wait til the new Anaconda hits koji... | |
| jwb | bpepple, to be honest i've no idea | |
| bpepple | jwb: http://fedoraproject.org/wiki/Extras/Schedule/NewSponsors | |
| that's why I told delroy to either have him or me send the anouncement. I never heard back from him. | ||
| nirik | in the past we mailed current sponsors for they opinions as well... | |
| jwb | ok, we're over time and apparently this needs more discussion | |
| tibbs | Does the cvsextras-sponsors list/alias still exist? | |
| jwb | yes | |
| or i thought it did | ||
| tibbs | Who will send the notice there? | |
| I volunteer to do so unless, of course, someone else wishes to. | ||
| bpepple | I told him I would, if he would provide me with a link to examples of his work. Never heard back from him. | |
| tibbs | Hmm. | |
| Perhaps he wasn't serious or perhaps he's just been busy. | ||
| bpepple | https://www.redhat.com/archives/fedora-devel-list/2008-April/msg02403.html | |
| c4chris | k, let's sit on it and see what happens | |
| tibbs | c4chris: I had wanted to ask you about the status report scripts. | |
| c4chris | tibbs: sure, when the meeting is over ? | |
| tibbs | Yeah, just wanted to get that out there in case you signed off. | |
| bpepple | c4chris: It's pretty much over. | |
| c4chris | bpepple: just say the word :) | |
| bpepple | word. | |
| * 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 | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!