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.
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
* warren here
bpeppleHi everybody; who's around?
* tibbs here
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
bpeppleok, let's get started.
--- bpepple has changed the topic to: FESCo-Meeting -- F9 Status - all
bpeppleHave any blockers beside the gpg-import issue came up?
f13I'm here
nottingwell, there's the blocker list
f13although my laptop is kind of fubar and I'm trying to fix that.  Somehow libgcc went missing
nottingthere 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
nottingthere's a variety of other things. do we really want to go through them one by one?
jwbno, i think we're just looking if it's going to slip more
bpepplenotting: no, I was just checking to see if there was anything major blocker showing up.
cailloni think the plan is still to do a final compose later tonight
nottingwell, RC1
caillonwell, hopefully final compose ;)
caillonassuming it's awesome and we don't need another one ;)
tibbsSo the absolute latest time for tag requests has essentially passed?
nottingif you've got a blocker fix...
caillonnot quite.
tibbsIt's just that people do ask, and I'd like to know just when the cutoff is so that I can answer them.[
dgilmoretibbs: another 6 hours?
jwbtibbs, you can probably just point them to f9 updates being available for 0 day fixes
caillonwell, even after RC1 if something is majorly broken, we'll still take and tag it.
jwbunless they have a fix for a blocker bug
bpeppleI was just looking to see if any major problems had cropped up.  If no one has anything else, we can probably move on.
caillontibbs, if they have to ask, they probably should just go the updates-candidate route
bpepplecaillon: +1
dgilmorecaillon: indeed
caillongenerally real blockers are "shit, we NEED this" not "hm, i wonder if i can get this in still"
nottingbpepple: define problems. things taking a long time to fix? *new* bad issues? etc?
jwbthings that will cause us to slip
nottingwell, if fesco is ok with emacs not having the epoch...
bpepplenotting: I was thinking new bad issues that could cause a slip.
jwbthings that make you go hmmmm
caillonnotting, didn't we resolve that last week?
bpepplenotting: wasn't dgilmore going to help chip?
jwbforgive me, but i was missing last week.  epoch for what?
nottingcaillon: we resolved that something should be done. it hasn't happened
f13caillon: we still haven't gotten a new build with all the right epoch junk.
dgilmorebpepple: yes
f13turns 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
dgilmoref13: what can i do to help?
f13dgilmore: send chip a patch?
caillonf13, well that's one good thing at least.  it's a shame we have to tell him about it.
f13make sure said patch interacts with the whole world of emacs packages
caillon: not really good /after/ the final freeze.
dgilmoref13: ok
f13emacs 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
caillonf13, good being "oblivious to epoch".  i wish i were oblivious to it too
jwbwait, is this the "emacs was out there for 2 days and we reverted to an older version" thing?
caillon5 days
and yes
jwband we're forcing epoch for what reason (sorry again)
dgilmoref13: regardless of that.  we have to.  the higer release package was out there
f13dgilmore: "have to" is rather... false.
dgilmorejwb: because emacs got reverted to an older version
f13: no its not
f13you are /choosing/ to by blindly following the guidelines instead of applying a little bit of reason here
warrenNOTE: We did agree to stop reverting without epoch in a FESCO vote during the last cycle.
f13warren: within reason.
jwbwas the higher version in Preview?
f13warren: I'm almost certain that we left some provision for logic to apply instead of rubber stamping.
jwb: no.
wwoodsit was released as an update post-f9pr
jwbok wtf guys
caillonjwb, no, but anyone that yum updated would have got it
f13jwb: preview -> final has a clean upgrade path.
warrenit happened between beta and preview?
wwoodsno, between preview and now
f13warren: no, it happened /post/ preview
* nirik suspects that pretty much anyone who installed PR would yum update after it...
jwbcaillon, i find that reason to be lacking in this case
jeremyf13: 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
jwbhowever i'm not going to rehash the argument
jeremyf13: yes, it's painful.  yes, it sucks.  but pain is how learning happens.
f13jeremy: 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.
caillonnirik, 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 :->
warrenemacs isn't in any default install right?
I don't have it here.
wwoodsIn F10, I need someone to help me write a tester-notification applet
f13warren: no, it's optional.
wwoodsinstalled and enabled by default for all non-final releases
nottingf13: not an old one. a different new one.
wwoodsthat lets us push messages to testers
nirikcaillon: sure, and those wouldn't have emacs...
warrenyou would only have the higher version if 1) You actually manually installed emacs 2) you updated during those 5 days
f13notting: well sure, the build we'd like, minus epoch.
caillonthat was sorta my point
wwoodssince we don't have that yet...
nottingf13: which apparently still has other blockers. whee!
jwbanyway, i would have been -1 on requiring the epoch, but unless we're readdressing it now it doesn't matter
f13but whatever.  It was my choice, not the maintainers.  He'll happily do whatever we force him to do.
f13but 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"
c4christibbs: ?
nirikwell, I was +1 on the epoch, but given nothing has happened on it, perhaps we should revisit... if we want a RC tonight.
cailloncan't we just rip it out and declare vim the winner?  :)
tibbsI was trying to find the meeting where FESCo agreed that it wouldn't do rollbacks like this.  The "." was intended for my mail reader.
jwbcaillon, yes
f13honestly folks, I don't think we'll be spinning an "RC" tonight
jwbnor i
f13I'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
caillonf13, that's good to know for that other thing i mailed rel-eng about.
f13composing is /far/ easier if the content we want made it into a rawhide.
nottingdo we want to talk about the key stuff?
f13notting: key stuff?  packagekit ?
bpepplehave we resolved the emacs issue?
nottingdgilmore: were you going to help with a patch? if not, i can
dgilmorenotting: i will
notting: ill ping you if i need help
* caillon has a theory that all packages will eventually gain an epoch
warrenCaillon's Theorem
spoleebacaillon, im personally holding out for complex numbers so I can have an imaginary epoch
nottingf13: well... there's something in PK now. but it's bad. and still somewhat broken
f13caillon: wouldn't be so bad if epoch were more visible and less um... special?
niriksoon we will need a MetaEpoch to override Epoch. ;)
f13nirik: superepoch
notting: vunderbar.
caillonf13, like release tree + build date?
f13notting: what's the short and dirty?
nirikdgilmore / notting: let me know if I can assist as well with that.
nottingf13: 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
f13notting: *sigh*
caillonf13, EpicEpoch :)
f13notting: yeah, that should be... fixed.
warrenwhat was the emacs conclusion?
f13notting: 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
nottingwhich brought up the suggestion of importing the keys during install...
warrenf13: that does what?
* dwmw2 arrives; sorry
caillonthat bumps the epoch, presumably
f13warren: 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.
jwbthis sounds like pain
c4chrisnirik: yea, makes me cringe a bit...
f13nirik: there are... many
caillonhow many?
tens? hundreds?
nottingnirik: most of those requires are automatic. also, they wouldn't need rebuilt right now
f13which 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?
nirikI don't see that many...
f13nirik: many was like 10~
nottingf13: because the new emacs isn't even a prerelease, so why the hell would that be coming soon anyways?
f13notting: that's what chip told me
bpepplecaillon: I thought we identified something like 12 packages.
f13notting: or maybe I misunderstood him.
nirikemacs has a very slow release cycle I thought... although it has new maintainer(s) now.
f13but whatever, I'll stop dropping hate bombs and move on.
nottingemacs 23 is the 'future' release
caillonexcept now it's in the past since you forgot the epoch :P
f13notting: so who's going to bend, installer folks in pre-importing whatever keys they can find, or PK in doing the prompt/import correctly?
warrenit was in rawhide 5 days after preview, it requires rebuilding 12+ other packages, maybe it isn't worth doing.
nottingf13: i expect stalemate!
wwoodswe *have* stalemate
warrenWhat is the argument against pre-importing?
nirikpre-importing seems like a loss... since there also will be 3rd party repos...
jwbthen FESCo needs to make a declaration
nottingwarren: doesn't require rebuilding anything yet, as all the dependencies will currently be correctly satisfied
f13warren: feel free to try and push that though FESCo.
dgilmoref13: i expect that PK gets slapped into shape
f13dgilmore: in 11 hours?
wwoodsWe have a (terrible but functioning) UI for importing keys
in PK
dgilmoref13: i can dream
nottingwwoods: it isn't functioning yet
f13wwoods: yet notting says it's broken still.
* warren tries to make that UI pop up...
wwoodsrequiring 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?
wwoodsnirik: it's a planned feature for PK 0.2.x, due sometime later in May
caillonnirik, both.
warrenthreaten to go back to pup/pirut if they don't bend
wwoodswe only need it for F9 because we're not (and have never) importing the key during install
nottingwwoods: which is a much shorter patch, fwiw
wwoodsimporting the key during install?
jwbthen why is that bad?
wwoodsfar 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
bpepplewwoods: seems reasonable.
nirikugly dialog in PK? or ?
nottingi know jeremy didn't like the idea in the past. jeremy?
wwoodsalso 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
tibbsPlus, we can fix the ugly dialog but what's in the installer will be frozen forever.
wwoodsI have a screencast
tibbs: exactly
caillonnirik, yes, but the fact that anything ever asks the user to import a key is ugly, too.
tibbsSO we need to decide on fixing the installer, like, now.
f13I seem to remember that one of the problems was discovering which key and where to import.
(during install)
on every single install path
and "wtf does it mean for upgrades"
wwoodsthere's one other possiblity
do it in a firstboot module
warrenPK needs to handle key importing for arbitrary keys defined in /etc/yum.repos.d
jeremywith the added little wrinkle of the installer team basically being down to having laptops to work on right now
nottingjeremy: upgrades is 'you don't'
warrenit is an incomplete solution to expect the installer to pre-import
nottingjeremy: want the patch?
wwoodswarren: yes, that's the planned feature
you don't need key import on upgrade - they should already be there
f13wwoods: until we change the key on y our
tibbsIf you install from F8 media and then upgrade, the keys won't be there.
jeremynotting: I feel *very* uncomfortable with shoving that significant of a change into the installer at the last minute
jwbjeremy, what does the laptops thing have to do with this?
wwoodsobviously the tools need to be able to import keys
f13which we may when we get the signing server.
wwoodsnobody is debating that
jeremyjwb: significantly impedes the ability to test
nottingjeremy: http://fpaste.org/paste/1985  . if it fails.... you get what you have now
warrengah, PK can't handle installing i386 of a package if the x86_64 is already installed.  That is stupid.
jeremyjwb: the westford office is moving tomorrow and so everything is packed up
f13warren: you sure that's PK failing and not the rpm having conflicts?
jeremynotting: uhhh, and auto-import things like the beta key?
wwoodsbut: 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.
nottingjeremy: see... HAAACK
wwoodsYeah I think you only want /etc/pki/rpm-gpg/RPM-GPG-KEY
f13wwoods: I don't think anybody argues that.  The real problem is discovering /which/ key is the /right/ key in a non fedora-specific way
caillonwwoods, agreed
nottingwwoods: you do not want to hardcode a file name
wwoodscheck the key ID for a specific RPM and import that one?
jeremynotting: see "NOT COMFORTABLE" ;-)
warren"Do you want to import key 4F2A6FD2 from fedora for celestia?"
No Yes
jeremywwoods: umm, key id mapping to file name is basically impossible
nirikso I guess I would say see if the PK guys can fix this today... ? if not, move to HAAAAACK?
nottingjeremy: 'keys installed by packages in your install set' is a better metric than 'hardcode a specific file'
warrenwhat is wrong with this?
caillonwarren, only everything!
wwoodsUI atrocity aside - it halts the transaction and you have to restart it manually
nirikwwoods: can that be easily fixed? like today?
wwoodswhich will suck for all those people installing F9 in a few weeks when there's 50-100 updates
nottingand it's only wired up on some of the install paths
warrenany UI we fix today wont be translated
wwoodsnirik: it is not an easy fix.
jeremynotting: also, doesn't fix livecds.  although I guess that could be hacked with the live image config
nottingjeremy: cut & paste! :P
jeremynotting: but seriously, when we get to changing multiple places to work around a deficiency, it kind of spells Doing It Wrong (tm)
wwoodsthere is no escaping the Wrongness here
f13I seem to recall pirut/pup/yum all handling this fine...
bpepplewwoods: agreed.
wwoodsthe 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
tibbsI'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.
warrenI'm afraid I agree.
dgilmorewwoods: he should know to ask never assume
warrenthis is rather embarassing
wwoodsthat screencast is somewhat contrived - normal users will only have to import one key on their first update
but it illustrates the problem.
nottingjeremy: obviously anaconda needs to use actual repos, not make them up on the fly. hm.
wwoodsdgilmore: yes, he should. unfortunately he didn't and now we are boned.
spoleebawwoods, i think a lot of 'normal' people include livna pretty early into an install..but ive no metrics on that
wwoodsunless we slip the release again we don't have time to do this right
jeremynotting: slowly getting there...
dgilmorewwoods: is he in the boston area?
which means his day is nearly done already
dgilmorecrap  i cant go stand over his shoulder
wwoodswe 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 :)
f13I'm dragging him into here
nirikdgilmore: we can chip in for a plane ticket for you. ;)
f13I bring you hughsie-afk
dgilmoredwmw2: please do
warrenhe's afk
hughsie-afki'm sortof afk
* dwmw2 bows to f13, the master of the summoning dance
hughsie-afki'm setting up HW
f13hughsie-afk: we've been discussing (to death) the current problem with key imports
f13hughsie-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-afkf13: ohh wow
nirikbut ideally something could be fixed up fast to make it acceptable. ;)
warrenThe UI is embarrassing as is, and halting the transaction is very user unfriendly.
hughsie-afkf13: 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
f13hughsie-afk: right, I think we understand that, but unfortunately, we're asking for more :/
f13or we're going to slip the release to somehow pre-import the key somewhere
warrenBut even if the UI were improved is something so centrally used acceptable without translations?
hughsie-afkf13: well, PK has to restart the transaction - it's the way it's designed
f13which....  yikes.
warren: translations can come very quickly after release
hughsie-afkf13: the real problem is that fedora does not trust it's own GPG keys, which is JUST BROKEN
caillonf13, which i think is the right decision in the long run (pre-importing our key)
warrenDidn't we establish that pre-import really isn't a solution because it doesn't handle arbitrary other keys?
tibbsrestarting 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).
warrenf13: "after release" is exactly when people will never see it since they need to import keys before they update.
hughsie-afkwarren: sure, but the installing livna stuff is easy as you do the key import on the first install
not eh first update
f13hughsie-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
dgilmorehughsie-afk: its up to the user to trust them not us
hughsie-afkdgilmore: we ship them on the CD
wwoodsif we import the default keys that UI won't come up unless you enable a 3rd-party repo
f13warren: We suck again.  Untranslated but working is a far sight better than translated and broken.
hughsie-afkdgilmore: if a user is running an untrusted CD then the gpg signing is a pointless activilty
wwoodsand even then, it'll be ugly just for that window of a couple of weeks
hughsie-afki'll repeat: not signing the fedora and fedora-updates key is JUST BROKEN
f13hughsie-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-afkf13: i can't release 0.2.0 in the next few hours - it's had zero QA
f13hughsie-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.
nottingf13: bah. you'll always get the right key. you'll just get a few extras
dgilmorehughsie-afk: the user should make a concious decision to import the key.
hughsie-afkwhat about importing /etc/pki/fedora* ?
dgilmore: NO
wwoodshughsie-afk: that's what notting's patch does
hughsie-afkdgilmore: what's the point?
nottingf13: we can 'fix' that by not shipping keys that don't belong to the repos in fedora-release
dgilmorehughsie-afk: so that you can verify manually the keys are correct
tibbsYeah, asking the user is just another dialog they don't know how to answer, so they'll click yes.
hughsie-afkdgilmore: do you agree to "RANDOM NUMBER THAT NOBODY CHECKS"?
dgilmorehughsie-afk: if you so choose
nottingf13: actually, why *do* we do that?
f13notting: we only ship the Fedora keys
I thought
wwoodsif we only ship the Fedora keys, what's the objection to importing them?
hughsie-afktibbs: totally, it's a waste of time
f13oh bother, looks like I forgot to cull some of them.
jwbhughsie-afk, i check it
warrenA simple solution to the "break transaction" problem might be to offer to import keys BEFORE you choose packages.
f13wwoods: you suddenly trust the beta key and there is no stop from installing beta stuff?
nottingwarren: the data isn't there then
f13wwoods: which, I'm campaigning to remove the sillyness of mulitple keys anyway
hughsie-afkubunutu doesn't ask the user "do you trust ubuntu?" and then ask the user "do you trust ubuntu-updates?"
f13notting: the data is in the yum repo files no?
tibbsCan we do something trivial like hack the firstboot initscript to  import the keys once when it runs?
nottingf13: yum repos aren't in the installer. at least, not like that
f13notting: I do believe 'before you choose packages' was a PackageKit level thing
hughsie-afktibbs: sure, that would work
nottingi'd much rather do the installer rather than assume firstboot gets run
wwoodsa firstboot module could import all key required by the installed repo files, but that only works for people who run firstboot
warrennotting: what data specifically?
hughsie-afkdgilmore: furthermore, when you are selecting packages in anaconda, you don't have gpg checks. security game over if you don't trust the media.
f13hughsie-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.
nottingwarren: the repodata does not have info on what packages are signed by what)
hughsie-afkf13: what's the alternative?
warrennotting: it does know about .repo files and keys defined in there
nottingf13: *cough* written and tested (once)
warrennotting: if key defined that is not already imported?
wwoodsf13: but the alternative is.. wiring up PK UI at the 11th hour and having little-to-no-testing
tibbsI'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.
f13hughsie-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.
jwbtibbs, the simplest method is to just tell people to run yum update manual after install to have it import the keys
f13wwoods: or reverting to pup, which seems to have working code for this.
wwoodsjwb: augh god
we will get so many bug reports
nirikjwb: or just have no updates. ;) <--- joke
tibbsAre either of those actually acceptable?  I don't know; I never run any of this fancy gui package management stuff.
spoleebanirik, that's more likely
nirik, the people who know how tofile bugreports..will go to cmdline and run yum and fix it
f13spoleeba: wrong
hughsie-afkf13: does pup ask you three gpg questions on update?
spoleebanirik, the people who dont file...wont be getting updates..and we wont know about them
wwoodshughsie-afk: it does
f13spoleeba: every time I accidentally have something unsinged hit rawhide, the slew of bug reports is enormous.
wwoodshughsie-afk: but it doesn't restart the transaction
f13hughsie-afk: if it has to, yes.
hughsie-afkwwoods: so the user doesn't get updates until he agrees to something to with GPG?
nirika) 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?
wwoodshughsie-afk: yep
f13hughsie-afk: and it doesn't restart the transaction either.
spoleebaf13, oh you'll get bugreports.. im just saying lack of updates will be more likely across the userbase
wwoodsbut seriously.. reverting to pup? now? isn't that what I was arguing we should stick with at Beta time?
spoleebaf13, from a percentage basis
caillonnirik, d) LA LA LA LA NOTHING TO SEE HERE
tibbsnirik: Hack something else to import the keys at boot.
wwoodsit'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
f13wwoods: 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-afki really don't see why keys can't be imported in anaconda or firstboot - problem solved
tibbsLook, 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.
f13hughsie-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-afktibbs: totally
jeremylet'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.
wwoodsIf 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-afkcan sombody please answer me straight: why does fedora not trust it's own updates?
jwbhughsie-afk, we don't trust mirrors
jeremyhughsie-afk: where do you get the key from?  the fingerprint *does* matter and people do check it
spoleebajeremy, i'll put it on my list of things to beat people up about early for f10
nottingjeremy: what's the hack about it? that it's importing keys, or that it's doing it via the shotgun method?
hughsie-afkjeremy: the key is in /etc/pki/
nottingjeremy: also, you want to do it in livecd install or livecd creation?
jeremyhughsie-afk: which came from where exactly?
nirikprobibly should be livecd creation.
hughsie-afkjeremy: the cd media
f13hughsie-afk: which came from where exactly?
niriksince people will run PK on their persistant live boot... ?
hughsie-afkjeremy: if you don't trust the media, then you've got bigger problems than not importing the correct key
spoleebanirik, with the persistence layer for liveusb..we'd need it at creation right?
jeremyhughsie-afk: welcome to the larger world where NOT EVERYONE INSTALLS FROM CDS
spoleebanirik, does the persistance layer let you..install things?
jwbjeremy, no kidding
* abadger1999 agrees with hughsie -- if you can't trust the media you're installing from, you're already screwed.
nirikspoleeba: yes, and yes
jeremybut 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
f13jeremy: 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.
jwbcrap, have to leave for real life meeting
hughsie-afkjeremy: it's not a pissing match. this is about security through obscurity
I have a meeting too.
jwbi'm +1 for the anaconda hack, as much as it sucks
nottingjeremy: 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
caillonwhat'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-afkI'm sorry, but can somebody please make a decision and then tell me what they want me to do. thanks.
jeremynotting: 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
caillonthe question is meaningless because if someone really wants to put crap on your computer ,they will with or without the question.
f13hughsie-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?
nottinghughsie-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
wwoodsbut by F10 PK will have proper GPG key importing UI/code
spoleebacaillon, i have an rpm repository which actually relies on a fake Fedora key
warrenpre-live image creation or during live runtime?
f13'cause without signing them live gets really easy for me.
hughsie-afknotting: i can fix that in an hour if you want
jeremywarren: 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
caillonf13, because it gives people something to feel good about?
wwoodsI thought there was only one 'fedora' key?
f13wwoods: fedora, and fedora-rawhide
er, fedora and rawhide. We re-use rawhide for udpates-testing
nottingjeremy: what-ever makes you feel better about it. after all, it's anaconda's fault that you can't do it right :P
warrenIs that our decision then?
nirikok, so anaconda and livecd-tools get hacked for now... ?
wwoodsah. now it all makes sense. Not sure why I can't keep the keys straight in my head
bpepplewarren: I believe so.
nottingf13: wait, not fedora-test?
wwoodsthe anaconda/livecd-tools hacks are F9-only, and can (should) be removed for F10
if they ever hit the F10 branch at all
bpepplealright, is there anything else we need to discuss regarding F9?
warrenwe're out of time
bpepplewarren: agreed. unless there is anything else pressing we should wrap up.
* wwoods supposed to be in another meeting
f13Fedora Project <fedora@redhat.com>
Fedora Project (Test Software) <rawhide@redhat.com>
jwbbpepple, sponsors
f13Those are the two keys, for maximum confusion.
jwbanyone have any new sponsor nominations?
you have 30 seconds
nottingf13: right. the rawhide key is different ;)
caillonsomeone self-nominated on the list
i forget who
f13notting: I don't understand that statement.
tibbsDenis Leroy, new FPC member.
nottingf13: that is RPM-GPG-KEY-fedora-test. RPM-GPG-KEY-fedora-rawhide is different.
nirik+1 for deleroy
f13notting: we don't use fedora-rawhide.
tibbsI mean, if we can't trust the FPC to know packaging, then....
f13notting: but we /do/ use rawhide@redhat.com
f13notting: the naming of them... came before me.
jwbthat'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
caillonno 8
bpeppledidn't we decide long ago that sponsors need to be announced on the list, and then the following week we vote on them?
jwbok.  delroy is a sponsor
spstarr_workwwoods: ugh, and here I am building a new DVD...I can just wait til the new Anaconda hits koji...
jwbbpepple, to be honest i've no idea
bpepplejwb: 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.
nirikin the past we mailed current sponsors for they opinions as well...
jwbok, we're over time and apparently this needs more discussion
tibbsDoes the cvsextras-sponsors list/alias still exist?
or i thought it did
tibbsWho will send the notice there?
I volunteer to do so unless, of course, someone else wishes to.
bpeppleI told him I would, if he would provide me with a link to examples of his work.  Never heard back from him.
Perhaps he wasn't serious or perhaps he's just been busy.
c4chrisk, let's sit on it and see what happens
tibbsc4chris: I had wanted to ask you about the status report scripts.
c4christibbs: sure, when the meeting is over ?
tibbsYeah, just wanted to get that out there in case you signed off.
bpepplec4chris: It's pretty much over.
c4chrisbpepple: just say the 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!