fedora-meeting
LOGS

21:00:46 <kanarip> #startmeeting Spins SIG
21:01:17 <brunowolff> I am here, but just got back from vacation a few hours ago.
21:01:36 <kanarip> ohw, how wonderful
21:01:38 <brunowolff> So I am about a week behind knowing what's going on.
21:01:44 <kanarip> was it a good vacation? ;-)
21:01:55 * nirik is here
21:02:03 <brunowolff> Yes. I run a Titan tournament at the WBC.
21:02:42 * kanarip wonders if maximillion ever posted that issue he wanted to talk about to the mailing list
21:02:56 <maxamillion> hello
21:03:03 <kanarip> hey maxamillion, just in time ;-)
21:03:16 <maxamillion> kanarip: nirik reminded me :)
21:03:25 <kanarip> shall we go to today's first topic?
21:03:27 * maxamillion is horrible with this stuff, I need to add these to my google calendar
21:03:33 <kanarip> #topic "part /" etc
21:03:47 <kanarip> #link https://bugzilla.redhat.com/show_bug.cgi?id=516338
21:03:48 <buggbot> Bug 516338: medium, low, ---, clumens, NEW, "A partition with the mountpoint %s has already been defined"
21:04:17 <kanarip> #link https://bugzilla.redhat.com/show_bug.cgi?id=516338
21:04:21 <kanarip> hmm
21:04:22 <buggbot> Bug 516338: medium, low, ---, clumens, NEW, "A partition with the mountpoint %s has already been defined"
21:04:23 <nirik> yeah, this is basically preventing any of the dvd sized spins from composing.
21:04:31 <kanarip> #link http://lists.fedoraproject.org/pipermail/fedora-spins/2009-August/000725.html
21:04:36 <kanarip> that's the one I meant
21:04:38 <brunowolff> I filed a dup of that before I went on vacation.
21:05:16 <kanarip> in the mailing list thread, i'm suggesting to let all CD sized media go with livecd-tool's default
21:05:29 <kanarip> that is now 4096 MB, but that is easily adjusted
21:05:43 <kanarip> just so that other spins can provide "part / --size=whatever"
21:06:44 <kanarip> does anyone have any other ideas?
21:07:18 <brunowolff> Has anyone heard from Chris as to whether this is a bug that will be fixed or a change that will require accommedation?
21:07:20 <nirik> so thats a workaround for this issue?
21:07:38 <kanarip> nirik, yes, that's a workaround
21:07:49 <kanarip> brunowolff, we've not contacted chris other then through the bugzilla
21:08:36 <kanarip> i think the workaround is pretty acceptable actually
21:08:51 * kanarip invites clumens here
21:11:18 <kanarip> clumens is not coming in here
21:11:40 <kanarip> so, what do we think?
21:11:48 <nirik> no worries. Lets go with the workaround for now, and revisit if the bug is updated.
21:12:13 <brunowolff> For now I would like to see a modified base ks checked in and spin-kickstarts updated.
21:12:51 <kanarip> ok
21:13:26 <kanarip> #agreed go with the workaround proposed by kanarip and remove part / from fedora-livecd-base.ks (submit patch to livecd to match the current default)
21:13:33 <brunowolff> It would still be nice to have a way to override the size so that you can include other kickstarts in custom ks files,
21:13:47 <kanarip> yeah, i agree
21:13:59 <kanarip> that's what i suggested pykickstart should do instead of bailing out
21:14:00 <brunowolff> but I think even if that is the way things are at release, it won't be a big problem.
21:14:08 <kanarip> "take whatever has been defined latest"
21:14:58 <kanarip> maxamillion, you wanted to ask/say something last meeting, isn't that right?
21:17:58 <maxamillion> kanarip: sorry
21:18:03 <maxamillion> was afk for $dayjob
21:18:47 <maxamillion> http://securityremix.org/ <--- we're planning to go Remix for F12 because I dropped the ball on getting it in for review in time and will be shooting for F13 for official inclusion
21:19:53 <maxamillion> also, this one just came up today .... the Drakut stuff is pushing the xfce image over size by about 30M ... is there any way we can work around that as a group .... is anyone else running into this issue?
21:20:01 <maxamillion> (nirik pointed this out to me today)
21:20:05 <nirik> yeah.
21:20:25 <nirik> We may want to look at a way to nuke the initrd-generic or otherwise workaround it for the live spins.
21:22:18 <nirik> perhaps bring up on the list, or talk with kernel folks?
21:23:02 <kanarip> uh, what's the initrd-generic?
21:23:20 <nirik> dracut makes a initrd-generic that has basically all modules in it
21:23:29 <nirik> it's about 21MB on x86_64 at least
21:23:41 <pjones> one might argue that it's too generic and has too many modules in it.
21:24:35 <nirik> yeah, and loosing 21MB for the 700MB livecd to it is no fun
21:24:36 <kanarip> so what's the deal with dracut? i'm not familiar with dracut
21:25:09 <nirik> its the new shiny mkinitrd
21:25:18 <pjones> kanarip: mkinitrd is showing its age in a big way, and the consensus was that we'd rather have something that used normal system tools instead of did everything itself.
21:25:36 <pjones> That thing is dracut, but there's been some scope creep as well.
21:25:38 <kanarip> right it did ring a bell ;-)
21:26:08 <kanarip> ok so what's the solution here, nuke initrd-way-too-generic from the livecd filesystem?
21:26:26 <maxamillion> would that cause any adverse effects?
21:26:44 <kanarip> (side-step) clumens says just now making these errors warnings is fine with him
21:27:20 <kanarip> maxamillion, not if there is no grub.conf/whatever.foo entry to boot with the initrd-generic, i guess
21:28:08 <pjones> kanarip: somebody earlier (wwoods?) had the idea that maybe it's worth making the livecd use stuff from the initrd, instead of nuking it.  I think more input from people who work on the livecd is needed.
21:28:35 <kanarip> hold on... i'm getting confused here
21:28:56 <pjones> wwoods: that's your cue.
21:28:59 <kanarip> does dracut only do a too generic initrd, or does it do a initrd-generic on top of a "normal" initrd?
21:29:13 <ajax> pjones: use what stuff?
21:29:23 <pjones> ajax: the things that are packed into the generic initrd
21:29:32 <pjones> that is to say, save space by keeping only the one copy.
21:29:44 <pjones> specifically kernel modules, but possibly also e.g. udev
21:30:01 <ajax> that seems entirely logical, since we have to lay down the world anyway as long as we suffer the delusion that the livecd is a good install method.
21:30:43 <kanarip> wow, are you saying i'm not alone in my opinion that the livecd generally sucks as an install method?
21:30:43 <maxamillion> so then does the fedora-live-base.ks need to be edited accordingly? is it pulling the extra space because packages with the same functionality are being pulled in? ... or am I missing something?
21:31:10 <ajax> kanarip: i think you're in quite good company.
21:31:16 <kanarip> maxamillion, i think it's a little more complex then that
21:31:26 <maxamillion> I think the liveCD install is perfect, I can install from scratch in 5 minutes ... what's not to like?
21:31:32 <pjones> I think the livecd is terrible as an install media, personally.
21:31:37 <maxamillion> why?
21:31:41 <pjones> (and... for justabout everything else except a demo, really.)
21:31:53 <pjones> maxamillion: because there's no way to avoid a duplication of effort, as a start.
21:31:53 <mcepl> pjones: Preach It Brother!!!
21:32:13 <kanarip> i think we're saying "let's get to a point where the running system has available from the initrd what otherwise would have been on the filesystem too" is that right?
21:32:38 <maxamillion> pjones: elaborate on this duplication of effort please, I'm honestly not familiar
21:33:34 <pjones> maxamillion: it means another install method.  that means duplication in: 1) making it work in the first place, 2) test cases, 3) testing, 4) added difficulty of debugging, 5) more bugzilla triage.
21:34:27 <kanarip> either way when you have the kickstart to compose the live media, you have the kickstart to do an unattended install
21:35:07 <pjones> Also, given the restrictions people like to place on it (see the endless debate on fitting it onto a CD), the ability to install a full distro is severely compromised.
21:35:14 <kanarip> with the unattended install though you can make consideration A and B while installing, whereas deploying from any sort of live media will grow you pains when you scale up
21:35:31 <ajax> for pretty much any definition of "full"
21:35:56 <maxamillion> kanarip: which is a great thought process large scale, but I run fedora on 3 machines ... I don't need a "deployment infrastructure"
21:36:26 <kanarip> maxamillion, then you also don't need to prep a livecd to deploy what you need/want/expect/customize/foo/bar/baz/whatever
21:36:54 <kanarip> and you also don't need any timesavings by using a filesystem dump from media to hard drive as opposed to installing RPMs
21:37:08 <maxamillion> kanarip: no, but its nice to have what I need/want/expect/customize/foo/bar/baz/whatever installed on a usb stick in my pocket for use anywhere, anytime
21:37:38 <kanarip> maxamillion, revisor --make-my-system-live is a plugin
21:37:48 <pjones> maxamillion: sure, but that only works if you don't want/expect very much of the OS.
21:38:06 <kanarip> either way, while i love getting side-tracked generally, i would like to stick to our original agenda somewhat
21:38:14 <pjones> fair enough.
21:38:31 <kanarip> so, wrt. dracut, does dracut only do a too generic initrd, or does it do a initrd-generic on top of a "normal" initrd?
21:38:54 <pjones> well, it's standalone, if that's what you're asking.
21:38:56 <maxamillion> the Xfce Spin liveCD has everything on it that I use on a daily basis ... I think the only thing I add is screen and htop
21:38:56 <kanarip> just to avoid that uncomforting level of confusion on my end ;-)
21:39:16 <pjones> I'm not sure how well adapted it is to use for a livecd's initrd.
21:39:25 <kanarip> pjones, it's 1 initrd.img it does, not a initrd.img + initrd-generic.img?
21:39:43 <kanarip> and that 1 initrd.img is way too large and way too generic is that what we're saying?
21:39:56 <pjones> right.  It's not something generic you layer on top of something else.  It's just an initrd that's supposed to work for most systems.
21:40:17 <pjones> That's what I'm saying.  It'd probably be better for you to form your own opinion than just take my word for it ;)
21:40:20 <kanarip> wow, that's a pretty large initrd.img ;-)
21:40:38 <pjones> Well, it has 20+ megabytes of kernel modules in it, so,...
21:40:44 * kanarip wonders how well that  initrd is going to work on lowmem systems
21:40:53 <ajax> badly!
21:40:56 <kanarip> anyway, what's our options there?
21:41:00 <pjones> no, it'll probably be fine for that.
21:41:10 <pjones> /boot size is more a concern than memory size, really.
21:41:23 <pjones> (I mean, assuming we're not talking about memory sizes below our stated minimums.)
21:41:28 <kanarip> ah, ok, that's fair enough
21:41:29 <pjones> the whole thing gets evicted during boot.
21:41:48 <pjones> except for kernel modules that actually got loaded, that is.
21:42:16 <kanarip> so, our options are...
21:42:21 * kanarip reads back...
21:42:36 * pjones isn't sure what the actual question was.
21:42:50 <kanarip> to lose the initrd.img copy on the / filesystem?
21:42:58 <kanarip> by nuking it?
21:43:40 <kanarip> that might be a problem for the anaconda --liveinst, but a workaround is available by copying it from cdrom:///isolinux/initrd0.img if i'm not mistaken
21:44:07 <ajax> or by just rebuilding the initrd after liveinst.
21:44:22 <pjones> yeah, we could nuke it from live images and rebuild after liveinst.
21:44:30 <pjones> that should work.
21:44:40 <kanarip> ok
21:45:40 <nirik> yeah, so that needs support in livecd-tools?
21:45:45 <kanarip> what kind of trouble would that be for anaconda --liveinst? pre- or post-beta kinda trouble?
21:45:58 <kanarip> nirik, in livecd-tools, yes
21:46:03 <kanarip> the nuking is the easy part
21:46:27 <kanarip> but it requires the change in anaconda --liveinst before it can go into livecd
21:46:34 <kanarip> *livecd-tools
21:46:50 <kanarip> so i was looking that the anaconda --liveinst trouble-level first ;-)
21:47:27 <kanarip> anybody willing to sink their teeth into anaconda and come up with/submit a patch?
21:47:41 <kanarip> or just log the bug and see what happens?
21:48:29 <ajax> isn't it just %post in the kickstart?
21:48:35 <ajax> at any rate, i'll fall on that sword.
21:48:57 <pjones> (also: most of us anaconda hackers think hacking on the live CD stuff is a waste of time...)
21:49:02 <kanarip> %post in kickstart for the nuking, preferably a function in livecd-tools itself, but that's on the composing end
21:49:32 <kanarip> pjones, bingo ;-)
21:50:11 <kanarip> ok, so i need some level of consensus here...
21:50:29 <kanarip> can we agree to let this slide until someone like me finds enough time to submit a patch to anaconda then, maybe?
21:50:46 <nirik> given that dracut got disabled again for alpha, I think so.
21:50:58 <pjones> yes.
21:51:15 <kanarip> ok, agreed then
21:52:07 <kanarip> #agreed dracut oversized way too generic initrd issue is being dealt with by someone who finds enough time in the near future to work on the problem
21:52:11 <kanarip> there you go
21:53:24 <kanarip> i'm through my agenda
21:53:33 <kanarip> nirik, wanna say something about spins1's status?
21:53:40 <nirik> sure...
21:53:57 <nirik> I have a script thats running ok now. I need to add some more output to it so it can note when things fail or are oversized.
21:54:18 <nirik> once thats done, it needs to get puppetized, then we should be good to run it for each rawhide.
21:55:00 <biertie_laptop> hmm, I guess i'm a bit to late for the meeting? I'm a bed sick, and I fell asleep on the couch :o
21:55:06 <nirik> we should have space on alt for weekly isos.
21:55:42 <kanarip> alright
21:56:12 <kanarip> and it's still sysadmin-spin that is going to be responsible/in control/has access/foo/bar/baz?
21:56:49 <nirik> yeah.
21:57:00 <nirik> well, for spin1...
21:57:49 <nirik> so, hopefully that will be running soon...
21:57:52 <kanarip> yeah
21:57:54 <kanarip> awesome
21:58:04 <nirik> what day should I be using for the weekly upload? friday? monday?
21:58:28 <kanarip> well, i suppose it would be most ideal if maintainers had the spin available and downloaded just before the weekend
21:58:40 <kanarip> that makes sense so they can spend some time during the weekend testing, no?
21:59:16 <nirik> yeah, except in some cases for test days...
21:59:29 <nirik> oh, I talked with KDE and desktop folks... they are fine with us doing those as well.
21:59:29 <kanarip> it takes me about 10 hours to compose one version, and one architecture of all spins in rawhide, so assuming it takes another 12 to download, i'd start on thursday
21:59:34 <kanarip> does that make sense?
22:00:52 <nirik> yep. Can do that and we can adjust.
22:01:25 <kanarip> if you start on thursday just 2-3 hours before midnight UTC, people have a chance to spend friday downloading, and weekends testing
22:01:46 <kanarip> (people that get up at 6-7am UTC, that is)
22:02:11 <kanarip> hmm, come to think of it, that's 8-9am my time, which might be just a tad late
22:03:56 <kanarip> ok, so yeah, we can adjust later
22:04:17 <kanarip> let's see how it goes and stuff
22:04:23 * nirik nods
22:04:27 <kanarip> anything else anyone?
22:05:13 <biertie> kanarip: sorry I wasn't here, but is there something I have to do?
22:05:31 <kanarip> we've spared you this time around biertie
22:05:33 <kanarip> ;-)
22:05:46 * kanarip is going to end the meeting in 5
22:06:04 <biertie> I'm looking forward to next time then :p
22:06:45 * kanarip is going to end the meeting in 4
22:06:46 <kanarip> 3
22:06:47 <kanarip> 2
22:06:47 <kanarip> 1
22:06:51 <kanarip> #endmeeting