17:00:01 <nirik> #startmeeting FESCO (2009-11-13)
17:00:01 <zodbot> Meeting started Fri Nov 13 17:00:01 2009 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:09 <nirik> #chair dgilmore dwmw2  notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler
17:00:09 <zodbot> Current chairs: Kevin_Kofler dgilmore dwmw2 j-rod jds2001 nirik notting sharkcz skvidal
17:00:15 <nirik> #meetingname fesco
17:00:15 <zodbot> The meeting name has been set to 'fesco'
17:00:18 <Kevin_Kofler> Present.
17:00:21 <nirik> Who all is around?
17:00:22 <skvidal> wwoods: it's not a cup of tea when the tea:bourbon ratio is very small
17:00:24 * sharkcz is here
17:00:33 <skvidal> wwoods: it's a cup of bourbon with tea in it
17:00:34 * skvidal is here
17:00:43 * jlaska lurking
17:00:51 * dmalcolm is here (re https://fedoraproject.org/wiki/Features/Python3F13 )
17:01:38 * nirik waits to see if we have quorum
17:01:40 * thomasj lurking
17:02:43 * j-rod here
17:03:07 <skvidal> we have 5, don't we?
17:03:19 <nirik> now we do. ;)
17:03:30 <nirik> ok, lets go ahead and get started...
17:03:47 <nirik> #topic ticket 263 - Sponsorship request: hubbitus
17:03:53 <nirik> .fesco 263
17:03:54 <zodbot> nirik: #263 (Sponsorship request: hubbitus) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/263
17:03:58 * Oxf13 is lurking
17:04:10 <nirik> We got negative feedback from other sponsors here.
17:04:27 <Kevin_Kofler> Yeah...
17:04:34 <Kevin_Kofler> -1, feedback overwhelmingly negative.
17:04:42 <Kevin_Kofler> In fact I haven't heard any positive feedback.
17:04:48 <nirik> I personally am also -1 for now. I would say that they should try and get more experence and be more positive and see us again down the road.
17:05:33 <sharkcz> -1
17:05:50 <j-rod> -1, based on sponsor list feedback
17:06:17 * skvidal goes with the crowd -1
17:06:41 <nirik> #agreed ticket 263 is rejected for now.
17:06:54 <nirik> #topic ticket 268 - Proven packager request - Daniel Drake
17:06:59 <nirik> .fesco 268
17:07:00 <zodbot> nirik: #268 (Proven packager request - Daniel Drake) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/268
17:07:29 <Kevin_Kofler> +1, feedback was all positive here.
17:07:36 <nirik> There was some positive feedback here from sponsors.
17:07:39 <j-rod> don't recall any negative feedback, reason for it makes sense
17:07:41 <j-rod> +1
17:07:52 <sharkcz> +1
17:07:54 <skvidal> +1
17:08:00 <nirik> +1 from me as well. I haven't interacted with them personally, but I trust those who have provided feedback.
17:08:13 <nirik> #agreed ticket 268 is approved.
17:08:34 <nirik> #topic ticket 269 - Request to approve mether a sponsor for package maintainers
17:08:42 <nirik> .fesco 269
17:08:43 <zodbot> nirik: #269 (Request to approve me a sponsor for package maintainers) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/269
17:09:00 <Kevin_Kofler> "me" = Rahul Sundaram here.
17:09:28 <nirik> There was some mixed feedback here. Some positive some negative.
17:09:37 <Kevin_Kofler> Yeah, that's a tough one, feedback was disputed.
17:09:51 <j-rod> seemed there were a number of concerns over suspect package reviews
17:10:16 <nirik> I am going to say -1 for now, and ask that he do some more reviews and take care to be more detailed in his reviewing...
17:10:16 <j-rod> or at least, none of them showed proof of a total grasp of the guidelines
17:10:28 <nirik> and come back in a while with those new one.
17:10:41 <j-rod> I'm inclined to ask for some more complete reviews first as well
17:10:45 <skvidal> nirik: I think I'm inclined to agree with you
17:10:46 * sharkcz agress with nirik
17:10:48 <skvidal> -1 for now
17:11:01 <Kevin_Kofler> -1, agreeing with nirik as well.
17:11:08 <sharkcz> -1
17:11:24 <nirik> #agreed ticket 269 is rejected for now, please do some more detailed reviews and come back in a while.
17:11:33 * dgilmore is here
17:11:39 <nirik> #topic ticket 270 - FESCO topic proposal - preupgrade and F-12
17:11:42 <Kevin_Kofler> It's clear that he's trying to be helpful, but some accountability is needed, reviews ought to be more verbose than just "APPROVED".
17:11:43 <nirik> .fesco 270
17:11:44 <zodbot> nirik: #270 (FESCO topic proposal - preupgrade and F-12) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/270
17:11:54 <jlaska> hey that's me
17:12:04 <nirik> take it away jlaska. ;)
17:12:14 <skvidal> new pk disabling preupgrade was submitted this morning wasn't it?
17:12:15 <Kevin_Kofler> So this is a horrible mess we've painted ourselves into. :-(
17:12:18 <nirik> Kevin_Kofler: agreed. Such reviews are always suspect.
17:12:26 <jlaska> nirik: wwoods is the master of the details here
17:12:44 <jlaska> I think the things we need some guidance/review on here is a short-term and a long-term plan
17:12:47 <Kevin_Kofler> Can we tweak preupgrade to:
17:12:52 <Kevin_Kofler> 1. remove all non-running kernels and
17:12:53 <wwoods> ahem
17:12:58 <Kevin_Kofler> 2. tune2fs the reserved space to 0?
17:13:02 <wwoods> hold your commentary for a moment, please
17:13:03 <Kevin_Kofler> That ought to be enough for F12.
17:13:12 <skvidal> Kevin_Kofler: let wwoods talk
17:13:15 <jlaska> let's start with stating what we're here for
17:13:18 <jlaska> wwoods: take it away
17:13:18 * nirik waits until the scope of this problem is made clear.
17:13:19 <wwoods> yeah thanks.
17:13:35 <wwoods> first, let's summarize the problem and the proposed solution for F12 release
17:13:47 <wwoods> and later we can talk about short-term workarounds and long-term fixes
17:14:14 <dgilmore> could we put install.img in /tmp
17:14:23 <wwoods> no.
17:14:31 <dgilmore> why
17:14:32 <wwoods> can I please explain?
17:14:40 <jlaska> dgilmore: can you hold up for a bit?
17:14:52 <jlaska> dgilmore: we can come back to thatstuff once we've stated the problem space
17:14:59 <dgilmore> jlaska: sure
17:15:11 <wwoods> I've been working on this for weeks and you'll have to just trust that I understand the problem and possible solutions fairly well
17:15:28 <wwoods> if I miss anything, bring it up afterward.
17:15:47 <wwoods> SO. the problem. the default partitioning scheme uses a 200MB /boot partition which is not on LVM.
17:15:59 <wwoods> after filesystem overhead, GRUB, etc. there's 183MB available.
17:16:21 <wwoods> in previous versions of Fedora the installer images used about 150MB of space, and each kernel took <=8MB.
17:16:46 <wwoods> the reason we use /boot for these things is that both GRUB and anaconda's first stage (initrd) lack the ability to read LVM
17:17:11 <wwoods> so the installer kernel+initrd+stage2 (install.img) all need to be on something that isn't LVM.
17:17:28 <wwoods> therefore /boot is the only place that's guaranteed to be readable by anaconda's initrd.
17:18:24 <wwoods> in Fedora 12 the installer images and the installed kernel take ~168MB
17:19:14 <wwoods> a typical user's /boot partition is going to have 3 sets of kernel images
17:19:33 <wwoods> (because yum.conf sets installonly_limit=3)
17:20:03 <wwoods> so the default user will have 183 - 3x8 ~= 159MB free on /boot.
17:20:13 <wwoods> you'll note that the new installer is too big for that.
17:20:30 <wwoods> which means preupgrade will fail for the normal use case.
17:20:52 <nirik> fail in this case means it will pop up a 'I don't have enough space, exiting' ?
17:21:35 <wwoods> actually in this case we're right on the line where we have enough room for install.img - which is the only disk space test we currently have in preupgrade 1.1.2
17:22:08 <wwoods> so it happily lets you reboot into anaconda, which tells you you need another 26MB on /boot and exits.
17:22:22 <dgilmore> to boot you only need the kernel and initrd, you can put stage 2 in /tmp and the initrd can setup lvm and access /tmp to get to stage 2
17:22:38 <wwoods> dgilmore: initrd can't read /tmp.
17:22:40 <wwoods> anaconda initrd doesn't understand LVM.
17:23:05 <dgilmore> wwoods: i guess its probably too late now to fix it but that should be fixed
17:23:11 <wwoods> yes, but that's a long-term solution
17:23:17 <wwoods> F12 images are frozen so there's nothing we can do about that right now.
17:23:19 <dgilmore> wwoods: most of my boxes have only 100mb /boot
17:23:21 <wwoods> we'll talk about long-term solutions later
17:23:30 <nirik> how hard would it be to change the space check to look for more room, and exit/prod the user to remove an old kernel?
17:23:35 <Oxf13> dgilmore: anaconda team isn't interested in the piles of C code it would take to get initrd to read things like LVM, raid, encryption, etc...
17:23:38 <wwoods> dgilmore: happily your case will hit the existing disk-space check and offer to download install.img over the internet
17:23:52 <Kevin_Kofler> wwoods: Could we point preupgrade to a different image, like initrd-preupgrade.img or something?
17:24:28 <dgilmore> Oxf13: thats a failing there then. i guess
17:24:36 <skvidal> Kevin_Kofler: the testing alone would kill us
17:24:55 <wwoods> *anyway* the point is: preupgrade isn't going to work for basically anyone with the default partition layout
17:25:01 <wwoods> unless they perform some manual workarounds.
17:25:06 <Oxf13> dgilmore: not really, getting all that shit right in loader is really really painful.  There is a reason all that stuff was moved out to stage2 and python
17:25:07 <jlaska> there are definitely lots of ideas on how to make this better for the next round when time is on our side
17:25:20 <nirik> could we push a yum update that changes the default installonly limit down to 2?
17:25:32 <dgilmore> Oxf13: i guess
17:25:34 <skvidal> nirik: it won't REMOVE kernels ad-hoc
17:25:46 <nirik> skvidal: yeah, so only when a new one comes... so thats fail.
17:25:47 <Kevin_Kofler> And 2 is too much still.
17:25:55 <wwoods> the proposed solution is: a) push an update to stop F10/F11 packagekit from starting preupgrade, b) document the workarounds so people comfortable with thatcan run preupgrade manually
17:26:00 <skvidal> Kevin_Kofler: we're not going below 2 :)
17:26:05 <Kevin_Kofler> That's the whole issue.
17:26:12 <muep_> could the preupgrade tool just offer to remove both the kernels which aren't being run
17:26:15 <muep_> ?
17:26:18 <Kevin_Kofler> We need to remove all non-running kernels at preupgrade time.
17:26:25 <jlaska> muep_: that's going to be one of the documented workarounds
17:26:29 <Kevin_Kofler> muep_: It should not "offer" it, it should just DO it.
17:26:35 <wwoods> also changing installonly_limit doesn't change the amount of available space on /boot, which doesn't fix the current problem, so again: that's a long-term solution that should be discussed later.
17:26:39 <jlaska> muep_: but there are no plans to write+test that code before tuesday
17:26:53 <Kevin_Kofler> Then it'd hopefully just work (unless we need more space still).
17:27:17 <jrb> wwoods: are you going to be able to modify preupgrade so that it will catch that situation anyway?
17:27:33 <wwoods> jrb: which situation?
17:27:36 <nirik> wwoods: ok, if we do that proposed plan now, is there going to be a update later where it gets re-enabled in packagekit?
17:27:39 <Kevin_Kofler> Want me to try to write the code to zap the old kernels?
17:27:55 <Kevin_Kofler> I'm not really familiar with the Yum API though, I'd have to learn it as I code.
17:27:57 <wwoods> so there's really three phases to this plan: 1) disable preupgrade-launcher, but document workarounds so people can do it manually
17:28:03 <skvidal> Kevin_Kofler: removing the old kernels is not difficult - it is however not what the use asked for
17:28:08 <skvidal> let's let wwoods go on
17:28:15 <wwoods> 2) attempt to script the workarounds into preupgrade and push updates that re-enable the preupgrade launcher
17:28:21 <Kevin_Kofler> skvidal: Anaconda will remove ALL the kernels from the old Fedora release anyway.
17:28:30 <wwoods> 3) try to keep this from happening in F13 and future releases
17:28:38 <wwoods> we're disussing phase 1.
17:28:47 <wwoods> anyone have a problem with phase 1 as stated?
17:28:47 <jrb> wwoods: er, the lack of space in /boot
17:28:58 * jrb lets wwoods go on
17:29:08 <skvidal> wwoods: I am +1 to phase 1
17:29:19 <wwoods> hughsie has already built a package that disables that capability and I have code in preupgrade git that (more) correctly detects when you have insufficient space in /boot to *complete* the upgrade
17:29:25 <jlaska> skvidal: sounds like a bumper sticker :)
17:29:27 <Kevin_Kofler> I guess I'm OK with it too, but I think we should do 2 ASAP.
17:29:30 <dgilmore> wwoods: i think at this point its all we can do.
17:29:35 <wwoods> let's call that preupgrade 1.1.3
17:29:37 <Kevin_Kofler> And I wonder whether we couldn't just go straight to 2.
17:29:45 <jlaska> Kevin_Kofler: who is "we" ?
17:30:05 <cebbert> something that might help in the long run would be a way to remove older kernels after newer ones have been proven to boot successfully
17:30:05 <Oxf13> phase 1 is a good backup in case phase 2 runs into snags
17:30:10 <Kevin_Kofler> As I wrote, I'm willing to help coding, though I'm not a yum expert by any means (in fact I have zero experience with those APIs).
17:30:34 <nirik> I am +1 to phase 1. We don't have time for more.
17:30:43 <wwoods> Kevin_Kofler: not sure who this "we" is but I have a feeling it's going to take more than 2 business days to design, implement, build, test, and push out an update that does stuff like editing filesystems and safely removing kernel packages
17:30:46 <sharkcz> +1 to phase 1
17:30:48 <nirik> wwoods / jlaska: I assume you would document on the wiki? common bugs? or ?
17:30:54 <jlaska> nirik: you got it
17:31:09 <jrb> wwoods: are you going to need help getting this done?
17:31:10 <jwb> fwiw, the pk update is already queued
17:31:11 <jlaska> nirik: I've got the issues with the appropriate keywords so that either myself, or adamw will have that in the wiki come tuesday
17:31:34 <Kevin_Kofler> wwoods: I guess you're just more careful with these things than me.
17:31:42 <nirik> would it also be worth updating preupgrade to point to that (or a generic location) when first run?
17:32:03 <wwoods> Kevin_Kofler: well, yeah, I like to be careful with code that runs by default on every user's machine that offers to remove the kernel and/or modify the /boot filesystem.
17:32:11 <Kevin_Kofler> I was thinking, have me or some other volunteer write (without much "designing", just do it!) and build the code over the weekend, push it directly to stable on Monday.
17:32:14 <wwoods> maybe I'm just a crazy QA guy but I want more than a couple hours to test that.
17:32:27 <wwoods> no.
17:32:29 <jlaska> nirik: wwoods was debating having a link for additional guidance when there is insufficient space in /boot
17:32:30 <Oxf13> Kevin_Kofler: that sounds like a fantastic way to fuck everybody over.
17:32:56 <wwoods> look - people who are comfortable removing kernel packages or running 'tune2fs' themselves can do so, and run preupgrade manually
17:33:03 <wwoods> nothing in this plan prevents that. in fact we're encouraging it.
17:33:06 <nirik> jlaska: yeah, a generic: http://fedoraproject.org/wiki/Preupgrade page with a pointer to any known issues that it points to might be good.
17:33:08 <jwb> i'll be a dick and say i'll just refuse to push that if that is how it goes down.  now you can blame me and move on to real solutions
17:33:14 <wwoods> so preupgrade still works for everyone who knows about it and wants to run it.l
17:33:27 <jlaska> nirik: nice, I was thinking the same ... with a #REDIRECT if needed to point to the right content
17:33:27 <Kevin_Kofler> Well, +1 to the 3-phase plan then.
17:33:29 <wwoods> for everyone *else* we should maybe *test* the solutions before we push them out.
17:33:43 <Kevin_Kofler> I'd like phase 2 to be done ASAP though as there's no real alternative for upgrades.
17:33:58 <Kevin_Kofler> DVD upgrades suck as they don't include online repos, especially updates.
17:33:59 <wwoods> yes, we all want bugs to be fixed as quickly as possible.
17:34:09 <wwoods> but no quicker.
17:34:25 <nirik> so for phase 3, how can we test this earler moving forward? it needs a lot of release parts in place doesn't it?
17:34:38 <wwoods> nirik: actually, not really
17:34:39 <Kevin_Kofler> We've had tons of trouble with those (remember the "yum broken after DVD upgrade to F11" common issue?).
17:34:45 <jlaska> nirik: well ... the interesting thing there is we started to test this in F-12
17:34:45 <wwoods> we can test preupgrades to Rawhide
17:34:55 <nirik> true.
17:35:01 <skvidal> wwoods: a quick questio
17:35:02 <skvidal> n
17:35:04 <wwoods> and (jlaska might know better) I'm pretty sure we started getting reports of this several weeks ago
17:35:16 <jlaska> nirik: what bit us was that leading up to (and including) F-12-Beta ... the images were sized so that we were on the good side of the /boot size calculation
17:35:31 <jlaska> nirik: it also pointed out an incorrect assumption in our test case
17:35:36 <skvidal> right now - if you have < 100MB free on /boot - then we fallback to just getting the initrd and kernel and making you have a wired network connection and download the stage2 then, right?
17:35:39 <jlaska> nirik: we were installing F-11 + updates using anaconda
17:35:40 <j-rod> what changed in the images?
17:35:46 <skvidal> j-rod: dracut
17:35:51 <j-rod> oh. right. that.
17:35:51 <jlaska> which left only 1 kernel installed when we wouldw test preupgrade
17:35:53 <wwoods> yeah we're riiiight on the edge and we just pushed over it sometime after Beta
17:35:58 <nirik> jlaska: ah ha.
17:36:07 <jlaska> nirik: so that will be adjusted in our test case
17:36:09 <skvidal> wwoods: see my question above - is that correct?
17:36:10 * jlaska goes to file a ticket
17:36:21 <wwoods> skvidal: yes, that's right
17:36:23 <nirik> so, potential phase N: could we just not have a seperate boot someday? :)
17:36:27 <jlaska> #link https://fedoraproject.org/wiki/QA:Testcase_Preupgrade
17:36:43 <wwoods> nirik: that's a possible phase 3 solution, yes
17:36:49 <skvidal> so could we increase that number so that we just add a requirement of a wired network connection for use of preupgrade AT ALL?
17:36:50 <wwoods> one of my favorites. but hold that thought a bit.
17:36:56 <nirik> anyhow, anything more we need to discuss here? did we have enough votes to approve this plan?
17:36:57 <Oxf13> nirik: grub would have to learn about encryption, lvm, dmraid, mdraid other than mirrors, ....
17:37:06 <nirik> Oxf13: or we would have to stop using lvm.
17:37:06 <wwoods> skvidal: yeah - technically the test right now checks for enough space to download install.img
17:37:08 <dgilmore> nirik: likely with grub2
17:37:15 <dgilmore> nirik: since it understands lvm
17:37:26 <wwoods> we could definitely change that to (install.img + 30MB for ananconda to install the kernel)
17:37:27 <Oxf13> nirik: what about the rest of those technologies we support for / ?
17:37:36 <wwoods> and if that test fails, you have to use http to fetch stage2
17:37:54 <skvidal> wwoods: I guess I'm just thinking that telling the user 'you can upgrade but you need to be tethered' is not really terrible considering that it's not their machine is going to useful during the update anyway :)
17:37:54 <nirik> Oxf13: true. anyhow, thats down the road.
17:38:05 <wwoods> the stage2-http-fetch code could use a bit of polish - right now it just uses whatever the first mirror is in your mirrorlist
17:38:08 <nirik> I think I see 4 +1's... j-rod ?
17:38:09 <wwoods> I'm pretty sure that could be improved
17:38:28 <dgilmore> nirik: i was a +1
17:38:30 <wwoods> skvidal: but, yes, that's not the worst user experience
17:38:46 <j-rod> +1, do it
17:38:47 <nirik> dgilmore: sorry, missed your +1. ok.
17:38:47 <skvidal> wwoods: yes, it is not
17:38:53 <wwoods> so yeah that's a proposed phase2 solution: more stringent check on /boot and use http if that fails
17:39:01 <nirik> #agreed preupgrade plan is approved.
17:39:04 <wwoods> another stage2 solution is: offer to run tune2fs and/or remove kernel packages
17:39:21 <wwoods> that one is much scarier.
17:39:35 <Kevin_Kofler> But it's much nicer to the user.
17:39:47 <wwoods> and much harder on the developer and tester.
17:39:50 <Kevin_Kofler> It supports complicated network setups, not just basic wired.
17:39:54 <wwoods> and preupgrade has no dedicated developer.
17:40:10 <nirik> ok, shall we move on to some f13 features?
17:40:22 <thomasj> You guys should ask Sho_ and his experience with preupgrade. He had to remove the running kernel to get enough space, after "you 0 MB more free space".
17:40:26 <nirik> wwoods / jlaska: thanks for bringing this up and explaining the cases so well.
17:40:33 <thomasj> *you need..
17:40:41 <wwoods> thomasj: yeah, tune2fs -r0 would have fixed that
17:40:46 <wwoods> or downloading install.img over http
17:40:46 <Kevin_Kofler> thomasj: Yeah, I think you need to both remove the non-running kernels AND tune2fs the reserved space to 0.
17:40:51 <wwoods> it sucks bad.
17:40:51 <thomasj> wwoods, oh ok, thanks
17:40:53 <jlaska> nirik: anytime ... thanks to wwoods for doing the hard work to identify the issue
17:41:29 <nirik> can you guys let me know when you have the page up? I suspect we will be getting a pile of people hitting things related to this in #fedora soon...
17:41:50 <jlaska> nirik: will do
17:42:06 <nirik> #topic ticket 41 - SystemTap Static Probes - https://fedoraproject.org/wiki/Features/SystemtapStaticProbes
17:42:10 <nirik> .fesco 41
17:42:11 <zodbot> nirik: #41 (SystemTap Static Probes - https://fedoraproject.org/wiki/Features/SystemtapStaticProbes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/41
17:42:11 <Kevin_Kofler> One thing I'm worried about with the phase 1 solution: what if people don't do their updates until after the F12 release?
17:42:26 <Kevin_Kofler> Will they get nagged about the preupgrade once they fire up gnome-packagekit?
17:42:43 <Kevin_Kofler> (Not sure how KPackageKit behaves there, I think it doesn't do preupgrade at all at this point.)
17:42:47 <skvidal> Kevin_Kofler: yes - and there's nothing we can do about that
17:42:53 <wwoods> actually, no
17:43:09 <skvidal> wwoods: they could get pushed to rawhide :(
17:43:26 <wwoods> IIRC packagekit checks for new releases by reading a file on-disk that's provided by preupgrade
17:43:34 <dgilmore> they would have to have pre-upgrade already installed? or is there something special in pk
17:43:37 <wwoods> so as long as we don't mention F12 in that file (or remove the file completely)
17:43:42 <wwoods> pk will not offer an upgrade
17:44:22 <wwoods> also, Kevin_Kofler / jrb: if we're going to offer to do scary things to the user's filesystem I think the "you need space on /boot" dialog needs some careful thought
17:44:46 <wwoods> and I can probably use some help/feedback on that
17:44:52 <Kevin_Kofler> I'd just do it silently.
17:44:58 <skvidal> Kevin_Kofler: hell no
17:45:03 <wwoods> yeah, no.
17:45:07 <wwoods> very, very no.
17:45:11 <Kevin_Kofler> People asked to upgrade their system, whatever is needed for that to happen needs to happen.
17:45:19 <skvidal> HELL no
17:45:25 <Kevin_Kofler> Anaconda doesn't ask "do you want me to do X" at each step either?
17:45:31 <Kevin_Kofler> s/?/./
17:45:36 <Oxf13> Kevin_Kofler: it does on the destructive step
17:45:38 <j-rod> what happens if the installer bombs for some reason, and no install happens?
17:45:38 <nirik> #topic back to preupgrade talk
17:45:45 <wwoods> More reasonable would be to offer the choices: [Check again], [Download install.img from the internet after reboot], or.. [Advanced]
17:45:46 <j-rod> now they have no kernel
17:45:51 <j-rod> BAD IDEA
17:46:00 <Oxf13> Anaconda asks you just before it actually starts fucking iwth your disks
17:46:03 <wwoods> where [Advanced] will give a dialog with a BIG FAT WARNING and buttons to unreserve space and/or remove old kernel packages
17:46:05 <nirik> is this discussion useful?
17:46:08 <Kevin_Kofler> Oxf13: On upgrades, it deletes all the kernels from the previous release without even asking.
17:46:09 <Oxf13> and any time it would do something destructive to your disks it prompts you
17:46:19 <Kevin_Kofler> After the upgrade, you have only the new one.
17:46:21 <nirik> we already agreed to the proposal.
17:46:23 <Oxf13> Kevin_Kofler: /after/ it's done all the checking ot make sure it can fit everything and proceed
17:46:37 <j-rod> anyhow, systemtap
17:46:39 <Oxf13> it doesn't do it just to see if it'll then get enough space
17:46:41 <nirik> discussions on how to do phase2 should go to fedora-devel? or a bug/ticket about how best to do that? or ?
17:46:44 <j-rod> +1 again, maybe it'll make it this time
17:46:44 <jwb> i suggest you take implementation details to #fedora-devel
17:47:04 <wwoods> agreed.
17:47:12 <nirik> #topic ticket 41 - SystemTap Static Probes - https://fedoraproject.org/wiki/Features/SystemtapStaticProbes
17:47:17 <nirik> .fesco 41
17:47:18 <zodbot> nirik: #41 (SystemTap Static Probes - https://fedoraproject.org/wiki/Features/SystemtapStaticProbes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/41
17:48:00 <nirik> so, this was pushed out from previous releases... trying to recall why.
17:48:15 <skvidal> incomplete docs?
17:49:20 <sharkcz> not upstreamed iirc
17:49:27 <Kevin_Kofler> It was pushed out because it didn't get implemented in time.
17:49:30 <nirik> looks like it wasn't done in time.
17:49:38 <nirik> yeah, and they reduced scope this time too
17:49:46 <nirik> https://fedoraproject.org/w/index.php?title=Features/SystemtapStaticProbes&diff=113907&oldid=99276
17:49:46 <Kevin_Kofler> So +1 to this feature for F13, hopefully this time it'll get done!
17:49:57 <nirik> yeah, +1 here too. Hope it's done in time.
17:50:06 <sharkcz> +1
17:50:37 <skvidal> +1
17:51:18 <nirik> #agreed SystemTap Static Probes feature is approved for F13
17:51:36 <nirik> #topic ticket 260 - SIP Witch Domain Telephony - https://fedoraproject.org/wiki/Features/SIP_Witch_Domain_Telephony
17:51:38 <nirik> .fesco 260
17:51:39 <zodbot> nirik: #260 (SIP Witch Domain Telephony - https://fedoraproject.org/wiki/Features/SIP_Witch_Domain_Telephony) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/260
17:51:51 <nirik> this is coming back after we asked for more docs, etc.
17:52:26 <nirik> they added a bunch of text to the feature page.
17:53:20 <nirik> I'm +1 to this feature... it seems like a nice idea to me.
17:53:49 <Kevin_Kofler> +1 here too, anything that can help displace Skype is a good thing!
17:53:56 <skvidal> +1
17:54:00 <sharkcz> +1
17:54:45 <j-rod> -1
17:54:47 <j-rod> er, sorry
17:54:49 <j-rod> +1
17:55:00 <nirik> #agreed the SIP Witch Domain Telephony Feature is approved for F13.
17:55:18 <j-rod> there may be another skype replacement soon as well...
17:55:22 <nirik> #topic ticket 271 - Automatic Print Driver installation - https://fedoraproject.org/wiki/Features/AutomaticPrintDriverInstallation
17:55:26 <nirik> .fesco 271
17:55:27 <zodbot> nirik: #271 (Automatic Print Driver installation - https://fedoraproject.org/wiki/Features/AutomaticPrintDriverInstallation) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/271
17:55:42 * j-rod points to story about google reportedly buying gizmo5
17:56:05 <j-rod> automatic printer driver install sounds like a plan to me
17:56:06 <j-rod> +1
17:56:23 <Kevin_Kofler> Question #1 there: will this work in KDE?
17:56:25 <sharkcz> +1 as I always wanted to have such feature
17:56:51 <skvidal> +1
17:57:14 <nirik> +1 here. I would hope it would work in any DE...
17:57:21 <j-rod> Kevin_Kofler: it looks to be PK-based, just like the firmware stuff, more or less
17:57:25 <j-rod> so I don't see why it wouldn't
17:57:38 <nirik> and the fonts stuff
17:57:41 <Kevin_Kofler> Because KPK doesn't implement the required interfaces? At least it used not to.
17:57:42 <nirik> and the multimedia stuff
17:57:56 <Kevin_Kofler> I know all the other auto-install stuff definitely doesn't work in KDE in F10.
17:58:06 <Kevin_Kofler> Nor F11 AFAIK, not sure about F12.
17:58:28 <nirik> Kevin_Kofler: really? ;( thats anoying... so kpackagekit needs to add support for that? is there anything in progress for that?
17:58:55 <Kevin_Kofler> I'm afraid I don't know.
17:59:23 <j-rod> sounds like KPK's problem then
17:59:29 <nirik> well, something we should check up on...
17:59:37 <nirik> but I still think this is a good idea.
17:59:40 <j-rod> fix it for fonts and firmware, and it should work for this too
17:59:53 <j-rod> so I don't think its current state has any impact on this feature being accepted or not
18:00:02 <Kevin_Kofler> Another thing is: we also have system-config-printer-kde in KDE.
18:00:25 <j-rod> and?
18:00:26 <Kevin_Kofler> So if the stuff is implemented in the system-config-printer GTK+ UI, it also won't work in KDE even if KPK is fixed.
18:00:34 <Kevin_Kofler> At least not until we get it into KDE.
18:00:44 <Kevin_Kofler> Into s-c-p-kde, that is.
18:00:59 <nirik> so those are made from seperate packages?
18:01:09 <j-rod> what's wrong with just running s-c-p? is it solely because its gtk+ instead of qt?
18:01:11 <Kevin_Kofler> Yes, s-c-p-kde is part of KDE upstream now.
18:01:13 <nirik> s/packages/srpms/?
18:01:15 <Kevin_Kofler> They share a common backend.
18:01:35 <nirik> yeah, I would hope that each frontend would keep up with the backend adding things...
18:01:49 <dgilmore> +1 for automated printer driver installer
18:02:00 <j-rod> tha'ts 5
18:02:20 <nirik> #agreed Automatic Print Driver installation feature is approved for F13
18:02:34 <Kevin_Kofler> +1 too, but IMHO if it only works in GNOME, that needs to be clearly documented.
18:02:35 <nirik> #topic ticket 272 - Intellij IDEA - https://fedoraproject.org/wiki/Features/IntelliJ_IDEA
18:02:52 <nirik> Kevin_Kofler: agreed. Can you add somethign to the talk page there or ping the maintainer?
18:02:58 <nirik> .fesco 272
18:02:59 <zodbot> nirik: #272 (Intellij IDEA - https://fedoraproject.org/wiki/Features/IntelliJ_IDEA) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/272
18:03:05 <Kevin_Kofler> nirik: Will do.
18:03:07 <sharkcz> if I read it correctly then driver installation is triggered by pluging in the USB cable from the printer
18:03:35 <nirik> sharkcz: yeah.
18:03:38 <dgilmore> not sure that IntelliJ IDEA is really a feature.  though i think we may have advertised netbeans when we added it
18:04:11 <Kevin_Kofler> It's a new package, sure, now is it notable enough to warrant a feature page? That's the question to ask.
18:04:27 <Kevin_Kofler> We don't put up feature pages for every single new package, but we do for important ones.
18:04:48 <nirik> it takes a group of packages to add this, so it's more work than just adding a new package.
18:04:50 <sharkcz> even new version of netbeans was advertised as feature ...
18:04:59 * nirik doesn't know how popular this ide is...
18:05:22 <nirik> 19.832% complete. Thats accuracy. ;)
18:05:27 <tibbs> If this is to be a feature, can I ask if they have reviewers lined up for those package, and if they could somehow indicate which reviews are required for this feature to move forward?
18:05:38 <skvidal> tibbs: good question
18:05:59 <Kevin_Kofler> And will developers (the target userbase for this feature) care?
18:06:13 <j-rod> never heard of this thing before myself
18:06:15 <dgilmore> is this something that will get us new users?
18:06:18 <Kevin_Kofler> Eclipse and Netbeans are well-known, but I had not heard of this IntelliJ IDEA thing before.
18:07:16 <j-rod> not clear from the feature page where this comes from...
18:07:35 <Kevin_Kofler> Well, from IntelliJ.
18:07:45 <j-rod> jetbrains, actually
18:08:06 <tibbs> They really have run out of good names.
18:08:09 <Kevin_Kofler> Yeah, just looked it up.
18:08:14 <Kevin_Kofler> http://www.jetbrains.com/idea/
18:08:31 <Kevin_Kofler> What is being packaged is the "Community Edition", there are also proprietary commercial ones.
18:08:37 <sharkcz> I pinged the owner on fedora-cs channel ...
18:08:47 <nirik> so, how about we defer this, ask the feature owner: how popular is this, should it really be a feature, and are reviewers lined up and/or review bugs marked as part of a feature.
18:09:00 <j-rod> I'm... yeah, still not sure this is entirely Feature-worthy
18:09:33 <j-rod> seems like nothing more than a relatively obscure new package, not a Feature
18:09:50 <tibbs> BTW, it's sufficient to have all of the tickets block F13-Idea-Feature or something.  Just so we can find them and know what's left to review.
18:10:01 <skvidal> so let's ask them that
18:10:06 <skvidal> why is this a feature
18:10:12 <dgilmore> i cant see what license the community edition is under
18:10:19 <nirik> ok, would someone like to take that action item? ;)
18:10:24 <Kevin_Kofler> Their site doesn't talk about the community edition even existing.
18:10:24 <tibbs> I really don't want it to come down to the wire and have the package review process blamed for hosing a feature because we didn't know what packages needed reviewing.
18:10:44 <dgilmore> http://www.jetbrains.com/idea/buy/buy.jsp#openSource seems to indicate that its for open source developers only
18:10:55 <Kevin_Kofler> That's not Free Software.
18:11:11 <Kevin_Kofler> So if that's what they're packaging, it's not acceptable for Fedora in the first place.
18:11:35 <Kevin_Kofler> But there seems to be a Free version.
18:11:50 <tibbs> "To apply for this free license"
18:11:53 <tibbs> Sounds troublesome.
18:11:54 <Kevin_Kofler> I just found an article in German mentioning that it's "becoming open source".
18:12:05 <dgilmore> http://www.jetbrains.com/idea/nextversion/free_java_ide.html
18:12:15 <Kevin_Kofler> http://www.jetbrains.com/company/press/pr_151009.html
18:12:41 <Kevin_Kofler> That's the Press Release they linked to in that article.
18:12:43 <dgilmore> so its only recently open sourced
18:13:11 <j-rod> I'm starting to see ways to spin it as a Feature...
18:13:35 <j-rod> "helping a formerly proprietary-ony company see the light"
18:13:43 <j-rod> or get to the light
18:13:46 <j-rod> or whatever
18:14:06 <j-rod> with the correct angle on this, I think I'm +1 to it as a Feature
18:14:16 <skvidal> I still want more info
18:14:20 <sharkcz> I would defer to next week and invite the owner
18:14:24 <skvidal> -1 until questions are answered
18:14:27 <skvidal> sharkcz: yes
18:14:36 <j-rod> deferred, NEEDINFO worksforme
18:14:43 <Kevin_Kofler> defer +1
18:14:48 <dgilmore> more info would be helpful
18:14:53 <dgilmore> +1 defer
18:15:03 <nirik> yeah, defer would be fine with me.
18:15:34 <nirik> #agreed the Intellij IDEA Feature is deffered until next week for more info from the feature owner.
18:15:51 <nirik> #topic ticket 273 - Python 3 F13 - https://fedoraproject.org/wiki/Features/Python3F13
18:15:54 <nirik> .fesco 273
18:15:55 <zodbot> nirik: #273 (Python 3 F13 - https://fedoraproject.org/wiki/Features/Python3F13) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/273
18:16:04 * dmalcolm is lurking btw
18:16:48 <nirik> I think a lot of work has gone into how best to do this...
18:16:49 <Kevin_Kofler> +1, why didn't we do this earlier?
18:16:58 <j-rod> having talked to dmalcolm in person about this already, +1
18:17:03 <Kevin_Kofler> Parallel installation is going to be the only solution there.
18:17:06 <sharkcz> +1
18:17:18 <skvidal> +1
18:17:27 <nirik> I'm +1... we should be leading along and trying to get things moving to the new version. ;)
18:17:31 <dmalcolm> BTW there are a few areas I see as controversial:
18:17:44 <dmalcolm> - shared specfile vs split specfile
18:18:05 <dmalcolm> i.e. is it ok to add a %with_python3 boolean to a specfile
18:18:24 <dmalcolm> to emit a python3-foo subpackage
18:18:26 <Kevin_Kofler> IMHO, if upstream releases dual-use tarballs, they should be built as subpackages of a single specfile.
18:18:31 <j-rod> any plans for something along the lines of /etc/alternatives, so people could actually make python3 their default python?
18:18:37 <Kevin_Kofler> I.e. use the "build twice" trick, not conditionals.
18:18:50 <Kevin_Kofler> If they're separate tarballs, they should also be packaged separately.
18:18:51 <skvidal> j-rod: wow, no
18:19:04 <skvidal> j-rod: I think will cause explosions
18:19:08 <dgilmore> dmalcolm: how do you plan to handle the python modules we ship for py 2.6?
18:19:08 <j-rod> yeah, probably :)
18:19:10 <dmalcolm> j-rod: you can use --define "__python /usr/bin/python3" on the rpmbuild command-line
18:19:26 <dmalcolm> j-rod: setting /usr/bin/python to python 3 is insane at this point in time
18:19:34 <dmalcolm> (and GvR has said so!)
18:19:47 <dmalcolm> (paraphrasing)
18:19:49 <j-rod> dmalcolm: I mean more like "when I run python on the cli, I get python3. when a script is run, it uses python3"
18:19:51 <nirik> I think there are still details for packaging comittee to work out...
18:20:04 <dgilmore> nirik: right
18:20:10 <dgilmore> im +1 on the idea of it
18:20:11 <j-rod> i.e., exactly like what you said is insane. :)
18:20:27 <dgilmore> but i would like to how we plan to look after python modules
18:20:39 <dmalcolm> https://fedoraproject.org/wiki/PackagingDrafts/Python3
18:21:03 <dmalcolm> https://fedoraproject.org/wiki/PackagingDrafts/Python3#Python_modules_for_non-standard_runtimes in fact
18:21:09 <j-rod> I was thinking more in a developer sense, I think... Rip out python2.x, see what really does explode, start fixing. :)
18:21:37 <j-rod> devs can do that by hand tho, so nm.
18:21:40 <dmalcolm> (you'll break yum, for starters)
18:21:54 <j-rod> what, is yum important?
18:21:59 <j-rod> :)
18:22:19 <skvidal> real users install with rpm2cpio
18:22:27 <j-rod> oh hell yeah
18:22:29 <dgilmore> i think we should wait for packaging guidelines before we look at this feature
18:22:30 <nirik> anyhow, we have enought to pass this, unless we want to discuss details more?
18:22:47 * skvidal +1's again
18:22:57 <j-rod> eh, I think we can approve it, contingent on their being fleshed out packaging guidelines
18:22:57 <dmalcolm> areas I see as controversial (i) packaging guidelines (ii) marketability as a feature
18:23:10 <j-rod> I don't think ii is controversion
18:23:15 <j-rod> *sial
18:23:16 <skvidal> I think 'python3, yay' is a feature
18:23:33 <dgilmore> i is the big issue
18:23:45 <dmalcolm> re marketability: the other leading distros already ship py3k, so we're somewhat behind the curve.  The way to get ahead is to ship a useful stack of extra modules on top which AFAIK no-one else is doing yet
18:23:51 <dgilmore> in principle python3 is a great addition.
18:23:57 <nirik> I think we can approve the feature and approve the guidelines later... if they can't come up with guidelines we could revisit the feature, or push it off.
18:24:15 <abadger1999> dmalcolm: Note -- I added some comments to the page yesterday.  Just to flesh it out, point out places where there's options.
18:24:21 <j-rod> +1 here still
18:24:32 <nirik> +1 here still as well.
18:24:51 <skvidal> still +1
18:24:53 * dmalcolm would appreciate guidance on how to proceed with the packaging guidelines.  I'm feeling my way here
18:24:54 <sharkcz> stll +1
18:25:27 <Kevin_Kofler> nirik: Agreed.
18:25:38 <dgilmore> +1 contingient on packaging guidelines
18:25:58 <abadger1999> dmalcolm: You going to fudcon?
18:25:59 <nirik> #agreed Python 3 F13 feature is approved for F13
18:26:01 <dmalcolm> yes
18:26:05 <abadger1999> on the bus?
18:26:06 <nirik> #topic Open Floor
18:26:08 <dmalcolm> abadger1999: yes
18:26:13 <nirik> Anyone have anything for open floor?
18:26:17 <abadger1999> Cool.  Let's discuss there.
18:26:21 <dmalcolm> abadger1999: thanks
18:26:29 <oget> hey I'm here
18:26:46 <oget> (about the pulseaudio in fluidsynth thingy)
18:26:59 <nirik> oget: ah, yeah, I guess that didn't get marked for meeting.
18:27:28 <nirik> oget: so where do we stand there? we need the maintainer to enable pulse, and/or someone to agree to handle pulse bugs and they can?
18:27:43 <Kevin_Kofler> So the news is that Lennart chimed in and also asked for the PA backend to be enabled.
18:28:13 <Kevin_Kofler> So the "even Lennart doesn't want it" argument is not valid either. ;-)
18:28:33 <nirik> .whoowns fluidsynth
18:28:33 <zodbot> nirik: green
18:28:42 <oget> he didn't ask for it. he actually said it is dickishness not to enable it
18:28:44 <nirik> so, has green been missing on all this? are they still active?
18:29:03 <oget> green is quite inactive recently.
18:29:20 <nirik> oget / Kevin_Kofler: can we avoid making this go back to a pulse discussion. We agreed that it should be enabled, it's just a matter of who will and who will handle the bugs, no?
18:29:21 <oget> but you can try hard to summon him
18:29:23 <Kevin_Kofler> oget: (re Lennart) That basically amounts to the same. ;-) And I'd have to agree with him.
18:29:42 <nirik> Kevin_Kofler: would you be willing to handle bugs on that package related to pulse?
18:30:19 <nirik> green appears to be a rh folk... anyone have any way to contact them on this off hand quickly?
18:30:28 <Kevin_Kofler> Well, what's your definition of "handle" there?
18:30:51 <oget> I explained "handle" quite well in the ticket a few times
18:30:57 <Kevin_Kofler> I'd say the best solution there is to ask the bugs to just be reported upstream, upstream is active.
18:31:04 <nirik> triage, fix it if it's packaging related, ask upstream for fixes if it's a problem there?
18:31:35 <Kevin_Kofler> Sure, I can do that.
18:31:49 <Kevin_Kofler> It's not that I expect a massive flood of bugs. ;-)
18:31:49 <nirik> great. Is that acceptable to everyone?
18:32:29 <skvidal> works for me
18:32:31 <Kevin_Kofler> If it's really that broken, we can always consider disabling it again.
18:32:41 <Kevin_Kofler> ("that broken" as in "massive flood of bugs")
18:32:56 <oget> I'm fine with that. But I will not do the commit. I don't want to be the source of disarray.
18:32:57 * nirik is sorry this has dragged on as much as it has... lets try and all move on. ;)
18:33:15 <nirik> any other Open Floor items?
18:33:54 <nirik> Kevin_Kofler: any news on ticket 225?
18:33:57 <nirik> .fesco 225
18:33:59 <zodbot> nirik: #225 (Bugzilla 484855 - Mediawiki Fedora-only patch) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/225
18:34:30 <Kevin_Kofler> Nope. I forgot about it again, bad me. :-(
18:35:06 <nirik> no worries. you might also talk with smooge. He maintains in epel and is going to update the version there because the current version has security issues... not sure if he is going to change packaging or not at the same time.
18:35:24 <nirik> ok, if nothing else comes up will close the meeting here in a few.
18:36:08 <smooge> no changes unless it doesnt work in EL4/EL5
18:36:34 <nirik> ok.
18:36:42 <nirik> thanks for coming everyone.
18:36:43 <Oxf13> just an FYI, rawhide will be F13 content tomorrow
18:36:46 <Oxf13> (and no images)
18:36:49 <abadger1999> smooge: Define doesn't work :-)
18:36:53 <nirik> Oxf13: if it composes. ;)
18:37:11 <nirik> #endmeeting