[12:03] *** f13 sets the channel topic to "Fedora Release Engineering Meeting - Roll Call".
[12:03] ping: notting jeremy wwoods lmacken poelcat warren jwb rdieter spot
[12:03] * wwoods here
[12:03] * notting is here
[12:03] * poelcat here
[12:04] here
[12:04] * warren here
[12:05] * jwb not here
[12:06] * spot is here
[12:06] alright, lets kick this pig
[12:06] *** f13 sets the channel topic to "Fedora releng - F8/9 Updates".
[12:07] we've got updates pushed to a new location for 8 and 9 (testing too), and we're doing testing with the updated fedora-release for transition and newer PackageKit builds to handle the key iimport
[12:07] http://kojipkgs.fedoraproject.org/packages/fedora-release/8/6.transition/noarch/fedora-release-8-6.transition.noarch.rpm
[12:07] how are things working *outside* of pk?
[12:07] http://kojipkgs.fedoraproject.org/packages/fedora-release/9/4.transition/noarch/fedora-release-9-4.transition.noarch.rpm
[12:07] we're running into some potential issues with PackageKit and discussing those with hughsie
[12:07] notting: pirut is untested IIRC, and yum just works
[12:07] yum confirmed on both F8 and F9. pirut untested.
[12:08] ppc untested
[12:08] f13: what was the "PK falling over" issue you ran into?
[12:08] warren: I tried to uncheck 200+ updates
[12:08] individually
[12:09] f13: hmm, that might be a separate bug
[12:09] I'm testing on ppc64 right now, it's perfectly happy
[12:09] yay
[12:09] warren: it is, and not a blocker.
[12:09] warren: I didn't know about the right click -> uncheck all option
[12:09] f13, please ping me when you get to open forum
[12:09] so I'm re-installing F9 and trying from the start again.
[12:10] the only thing I'm concerned about at this point is that the update logic in F9 GAs PK works so that you get the new backend next time you try to do updates.
[12:10] it worked for me from 2.3.x
[12:11] I'm also concerned that the current PackageKit-0.2.5 no longer shows the PK icon in the tray after you relog
[12:11] doesn't appear after a reboot either
[12:11] users might be confused if they no lnoger see notification
[12:11] AFAICT it doesn't work at all
[12:11] do we have our 'what is going on, and how to fix it if things go horribly wrong' FQ?
[12:11] (that's FAQ, sorry)
[12:11] notting: not as of yet IIRC.
[12:12] notting: well, assuming hughsie fixes these two issues, then there shouldn't be any common case of things going wrong.
[12:12] well
[12:12] notting: simply "Update once, then update again"
[12:12] doesn't mean we shouldn't document how to manually import the keys, etc
[12:12] there is always the "in case of PK fire, use yum from the command line"
[12:12] notting: +1
[12:12] I agree that we should have "if all else fails, here is how to do it manually"
[12:13] 'smart and apt are left as exercises for the reader'
[12:13] notting: I dunno about manual import, it should sufficient to say "Use yum" which will do it with great certainty.
[12:13] *cough*
[12:13] notting: really don't want to confuse the announcement with lots of complicated things that wont matter to almost anyone
[12:14] warren: thats why they don't go in the announcement, they go in the FAQ
[12:14] the announcement just leads to the FAQ
[12:14] ok
[12:15] I strongly believe that we cannot release this with the current PackageKit-0.2.5
[12:15] unacceptable to have the tray icon gone
[12:16] sure it could be fixed later, but how will those users know it is available?
[12:17] well, I'm wanting to hear back from hughsie on this first, but I don't want to continue dragging things out when our non PK users could be up and going /now/.
[12:18] I think it would be irresponsible to push something that's known to be broken in an visible (and confusing) way without at least getting a first-glance opinion from hughsie
[12:18] wwoods: sure, which is why I want to hear back from hughsie first.
[12:20] right
[12:20] he's on the phone now, he'll get to us when he's done.
[12:20] * nirik has pinged hughsie on gimpnet... he's on the phone, but will try and hop over in a bit.
[12:21] OK, aside from PK, does everyone understand the next steps?
[12:21] anything further on updates before we move on? Updates will be a constant item we're working on for the next few days
[12:21] warren: outline them for us?
[12:21] 1) Build final fedora-release packages for F8 and F9. This appears to
[12:21] be identical to the packages I built previously for testing, since no
[12:21] errors were discovered.
[12:21] 2) Sign this new fedora-release, PackageKit and gnome-packagekit with
[12:21] oldkey.
[12:21] 3) Erase everything in oldrepo updates for F8. Put new fedora-release
[12:21] there and createrepo.
[12:21] 4) Erase everything in oldrepo updates for F9. Put new fedora-release,
[12:21] PackageKit and gnome-packagekit there and createrepo.
[12:21] 5) Erase oldrepo contents of F8 and F9 updates-testing and create empty
[12:21] metadata there.
[12:21] 6) Send out announcement.
[12:22] 7) Push to mirrors.
[12:22] #1 is done
[12:22] releases and Everything is left alone for now.
[12:22] 0) make the faq/announcement and get it reviewed and looking ok?
[12:22] well, that's #6
[12:22] but yes
[12:23] oh, also don't forget unique
[12:23] how about sending out announce today referencing this list and our progress so people know how things are going and where we are at?
[12:24] https://fedoraproject.org/wiki/New_Signing_Key and https://fedoraproject.org/wiki/Enabling_new_signing_key exist now, FYI.
[12:24] poelcat: we really have to know the status of the things we push before sending out the announcement
[12:24] the announcement must be succinct and not confusing
[12:25] If hughsie can fix PK, then the announcement is pretty much just "Update, then update again", fingerprints of the new keys and links to the FAQ.
[12:26] warren: he's asking for a status announcement, not /the/ announcement
[12:26] If hughsie can't fix PK in time, then the announcement has to mention "oh btw, this is broken, and no we don't have a fix for it yet, and it wont tell you when a fix is available."
[12:26] warren: akin to what I did on Fridayish
[12:26] oh
[12:26] poelcat: I can do that.
[12:27] cool :)
[12:27] * poelcat thinks/hopes this will help people remain patient
[12:28] f13: should we point people at the fedora-release packages and say "please test this, although packagekit is known broken"
[12:28] it's not *that* broken
[12:28] f13: perhaps fedora-devel-announce can be pointed it, while fedora-announce-list not.
[12:28] wwoods: the key import part is broken
[12:28] the icon doesn't appear. you can still list updates, apply them, etc.
[12:28] oh original f9
[12:29] f13: still nobody has tested pirut
[12:30] warren: I"d rather not on a announcement that goes to fedora-announce-list
[12:30] warren: you can re-post to fedora-devel-list or fedora-test-list
[12:30] f13: that's what I said
[12:30] f13: fedora-devel-announce only
[12:30] meh, make another mail.
[12:31] warren: nitpick: do we really need the .transition in the fedora-release Release? It looks...non-standard.
[12:31] mbonnet: bikeshedding
[12:31] warren: user experience
[12:31] mbonnet: doesn't hurt, and it actually is less confusing to know exactly what state the user is in
[12:31] mbonnet: this actually is only a transitional package. soon later we will push the final into newrepo.
[12:32] yeah, it'll get replaced with a standard n-v-r in the new updates location
[12:32] warren: *shrug* Just saying, as an otherwise clueless user, seeing a package named like that might raise questions.
[12:33] but I don't really care that much
[12:33] f13: well, I was thinking to name the next one 9-5.newkey to again be explicitly clear. because otherwise 9-2 and 9-5, at a glance you don't know which key you have, and that is pretty important.
[12:33] are others really against this?
[12:33] again this is bikeshedding.
[12:34] anything else on updates?
[12:35] oh yes
[12:35] So do we have agreement on how we will handle the key revoking?
[12:35] We didn't exactly ask Panu to add that hack to rpm yet.
[12:35] I haven't focused on that, due to wanting to get phase1 actually working
[12:35] ok
[12:35] let's revisit this
[12:35] next
[12:36] next meeting perhaps
[12:36] I'd rather discuss it once phase1 is done
[12:37] ok, moving on.
[12:37] *** f13 sets the channel topic to "Fedora releng - F10 Beta".
[12:37] after the previous schedule adjustments, we were supposed to freeze tomorrow (well late late tonight)
[12:38] but we were also supposed to have a working rawhide for the past week+
[12:38] that didn't happen, so I've put the question out there as to wether the freeze should happen either
[12:38] what were the things preventing working rawhide?
[12:39] broken libxml2, broken package tickling a broken createrepo, anaconda being broken via NetworkManager
[12:39] build problems, then mishaps using NM in stage1
[12:40] so for a few of the days we had no rawhide, a few of them we had rawhide, no images, but repodata for packages, then we had rawhide, repodata, images but not working, and today we actually have somewhat working images.
[12:40] there has definitely been progress
[12:40] yes we have progressed quite a bit, and now we are at.. square one
[12:40] we need a few days of square oe
[12:41] one
[12:41] that's my thought as well, but we have Thanksgiving to consider
[12:41] hughsie!
[12:42] sorry for the delay guys, been sorting out family stuff
[12:42] hughsie: that's OK
[12:42] lets put the beta talk aside for a moment
[12:43] okay, what's the problem?
[12:43] hughsie: so, it's been noticed that the panel icon seems to go away and not come back with 0.2.5-1
[12:43] is the process running?
[12:43] it doesn't seem to come back to indicate that there are updates availabl.e
[12:43] hughsie: yes
[12:43] gpk-update-icon that is
[12:43] hughsie: upgrade to 0.2.5-1 and relog or reboot, tray icon is forever gone
[12:43] gpk-update-icon --verbose says?
[12:43] hughsie: yes running
[12:43] can someone pastebin th eoutput pls, i'm running my laptop on my lap in a living room
[12:44] hughsie: output with the running pkg-update-icon or after I kill it?
[12:44] unable to locate theme engine nodoka.. cannot register existing type 'LibGBus'.. assertion 'initialization_value' != 0 failed
[12:44] ooops
[12:44] g_object_new: assertion `G_TYPE_IS_OBJECT (object type)' failed
[12:44] warren: killall gpk-update-icon && gpk-update-icon --verbose
[12:45] http://fpaste.org/paste/5838 (without killing it)
[12:45] http://fpaste.org/paste/5839 (after killing it)
[12:46] urgh, i see the problem, but i dont know why it's worked before
[12:46] libpackagekit uses LibGBus, as does gpk-update-icon
[12:47] and as we strip any of the non pk- prefixes from the library i figured we shoul dbe okay
[12:47] but LIBGBus must be part of the internal private ABI
[12:47] as it's registered in the type system
[12:48] warren: just on 0.2.5 ot 0.2.4 as well?
[12:50] hughsie: I think I only tested 0.2.5
[12:50] hughsie: actually, I saw icons in 0.2.4
[12:50] right, so something changed
[12:50] let me check
[12:51] bingo
[12:51] commit aae0eb74e9bd527fa6e0e73579bf77b1ba83b291
[12:51] Author: Richard Hughes
[12:51] Date: Wed Aug 6 12:40:45 2008 +0100
[12:51] bugfix: link in a local copy of gbus now we are compiling libpackagekit with -export-dynamic
[12:51] want a new rpm to try?
[12:51] please
[12:52] *sigh*
[12:52] anyone installing a fresh F8? we really need to test pirut as well.
[12:52] my test is halted at downloading file lists, probably because I'm connected to a slow ass mirror.
[12:52] is there any way to force PK to move to the next mirror?
[12:52] warren: f8 gold? or any f8?
[12:53] nirik: we should really test both on all archs, but I highy doubt it is broken
[12:53] * nirik powers on a x86_64 f8 guest he had laying around.
[12:54] PK still doesn't tell you when you should restart.. or are we just lacking metadata for that?
[12:54] f13: no, yum should timeout, right?
[12:54] wwoods: on rawhide yes
[12:54] no, on F9
[12:54] hughsie: depending on how you're using yum, it could take a long time to timeout, but if it's a slow mirror, it's getting data, just extremely slowly
[12:54] like a bit a minute
[12:55] hmm, there's not a lot pk can do in that situation
[12:55] we just rely on yum to DTRT
[12:56] warren: whats the link to that transitional fedora-release?
[12:56] hughsie: yum allows you to ^c while downloading and that triggers a mirror switch
[12:56] f13: about to build new rpm
[12:56] f13: send the signal by hand to the backend?
[12:56] since you can see the rate you're getting and make a decision.
[12:57] notting: what would be the signal?
[12:57] is someone planning a test kernel-xen rpm with the "x86_64 dom0 is working" patch set from a few days ago?
[12:57] * nirik got it.
[12:58] LetoTo1: not really sure what that has to do with the rel-eng meeting
[12:58] LetoTo1: wrong chan.
[12:58] oops
[12:58] f13: sigint
[12:58] sorry
[12:58] notting: ah, I'm just not sure how to send that via pkcon
[13:00] f13: kill -INT
[13:00] http://kojipkgs.fedoraproject.org/packages/fedora-release/8/6.transition/noarch/
[13:00] http://kojipkgs.fedoraproject.org/packages/fedora-release/9/4.transition/noarch/
[13:00] * nirik runs pruit
[13:00] f13: hughsie: do we have to worry about the old backend running after upgrade, or is that part well tested?
[13:01] warren: 0.2.x to 0.2.y is well tested
[13:01] warren: I'd like hughsie to give me a test to verify, but it seems to be working
[13:01] 0.1.x to y is less well tested (worked for me just now)
[13:01] how long ago was 0.1.x?
[13:02] the F9 gold release
[13:02] very quickly became 0.2.x
[13:02] * wwoods installs F8 x86_64.. for funtimes
[13:03] ok
[13:03] if we're confident about the backend part
[13:06] notting: yeah, that didn't help.
[13:06] warren, f13: http://koji.fedoraproject.org/koji/taskinfo?taskID=813930
[13:06] that should be a-ok
[13:07] apologies for the balls-up, things are a bit frantic here at the moment
[13:07] understandable.
[13:07] we'll keep testing with that, should be fine.
[13:07] thanks dude
[13:07] I still can't do a complete good test because I'm handed a barely functional mirror and there is no way I can find to make PK move to a different mirror
[13:07] if you need to grab me, ping me with email and i'll try and jump on
[13:08] f13: you can do killall packagekitd if you like
[13:08] * nirik waits for the download to finish here... pile of packages.
[13:08] hughsie: I wanted to test without killing the daemon
[13:08] i usually end up disabling the mirror and using fedora directly as the mirror bits seem, well, interesting
[13:09] oh here it goes
[13:09] pirut asked for the new key, imported and appears to be running the transaction now. All looks ok from what I can see.
[13:12] i have to go visit some family, but i'll be back in a hour or so
[13:12] success.
[13:12] hughsie: ok, cheers.
[13:13] alright, lets move back to beta talk.
[13:13] * nirik sees the update boom on the NetworkManager thing.
[13:13] nirik: F8 update?
[13:13] yeah, using pirut.
[13:14] on x86_64.
[13:14] is hte NM thing described somewhere?
[13:14] yeah, let me find the bug. It's a multiarch thing.
[13:15] how bad was todays rawhide?
[13:15] it's fine.
[13:15] it installs and everything.
[13:17] oh wait. maybe it doesn't?
[13:17] it starts anaconda, anyway
[13:18] is there any sane way to slip less than a wee?
[13:18] week?
[13:19] notting: yes, I was just getting to that
[13:20] notting: we could freeze on Thursday instead of Tuesday, and keep everything else the same
[13:20] essentially it gives developers a couple more days of free builds before we lock things down.
[13:21] which, given the timing of things, is probably the best choice right now
[13:21] +1 to Thursday
[13:21] wfm
[13:22] btw, about the translators issues
[13:22] humm... can't find the bug now. ;( Perhaps I should file a new one.
[13:22] do we like the suggested idea (who was it?) to accept any builds after the freeze for a few days with only translation fixes?
[13:23] nirik: so NM multilib in F8 repo is broken?
[13:23] warren: are they really necessary for beta?
[13:23] warren: don't we have a rather large period between beta and final freeze when translation updates can be built?
[13:23] give me this: http://www.scrye.com/pastebin/109
[13:23] f13: I'm not exactly sure how it works normally
[13:23]