10:00 -!- jeremy changed the topic of #anaconda to: Anaconda Feature Discussion
10:00 < msivak> let the show begin :)
10:01 < jeremy> pjones, dcantrell:  you there?
10:01 < dcantrell> jeremy: I'm here
10:03 < jeremy> okay, let's get started I guess
10:03 < pjones> yo
10:03 < pjones> it is raining like mad outside.
10:04 < jeremy> no kidding
10:04 < jeremy> anyway -- so the idea here is to sit down and figure out the various things that we want to work on over the next six-ish months (as well as perhaps some things for beyond that window)
10:04 < jeremy> as well as figuring out who's going to lead up the work and try to figure out some at least vague idea of when we want things to land 
10:04 < jeremy> so that we can avoid everything trying to land at the same time
10:05 < dcantrell> should we do this roundtable style?
10:05 < jeremy> dcantrell: that's probably the best way
10:06 < jeremy> I've got my list of things, but figure we can start with someone else and then hopefully by the time I go, my list will be short or non-existent ;)
10:06 < jgranados> lets do it alphabetical style:) 
10:06 < jgranados> clumens ?
10:07 < jeremy> works for me!  clumens, you're up!
10:07 < clumens> okay!  here are things i'd like to work on in the next release or two, in no particular order.
10:07 < clumens> (or at least be involved with)
10:08 < clumens> - remove the duplication between instdata and ksdata, by using pykickstart as the instdata where appropriate
10:08 -!- elliot_ [n=elliot@rdu-nat.rpath.com] has joined #anaconda
10:08 < clumens> - rework that disaster of network configuration in loader, preferably before the next rhel release
10:09 < clumens> - either move installation source config out of loader, or seriously look at using/adapting a library to do the fetching for us
10:09 -!- elliot_ is now known as elliot
10:09 < clumens> - get rid of install methods
10:09 < f13> that last one sounds interesting
10:09 < pjones> jeremy just lost power, apparently.
10:10 < clumens> - do something about text mode (either kill it entirely, turn it into something more q-and-a oriented, whatever)
10:10 < clumens> oh good.
10:10 < pjones> I don't think we can kill it, as much as I'd like to.
10:10 < notting> clumens: two questions: how does network config in loader interact with system-NM? moving source config out of loader -> stage2 -> no small stage1 for tftp?
10:11 -!- jeremybb [n=Katzj@m765e36d0.tmodns.net] has joined #anaconda
10:11 < pjones> (now that I've been dumb enough to say that, we should get a list out before we start killing items)
10:11 < jeremybb> And my power just went out
10:11 -!- atodorov [i=alexx@nat/redhat/x-6b19ed2c18dad688] has joined #anaconda
10:11 < clumens> jeremybb: i can PM you what i said
10:11 < elliot> clumens: i'm all for killing text mode as long as there a still a fallback from gui mode
10:11 < notting> elliot: vnc?
10:11 < pjones> elliot: vnc?
10:11 < jlaska> clumens: re: network loader ... is that all the flags lovin' ?
10:11 < jeremybb> This is the irc client from my phone so slow to type
10:12 < clumens> jlaska: you know it
10:12 < jlaska> know and love it :D
10:12 < elliot> notting, pjones: what about cases where the x server doesn't start
10:12 < clumens> notting: i don't think we've come up with answers to either of those yet, but i'm open to bright ideas
10:12 < pjones> (apparently we have customers who say vnc is not a tenable solution, though I'm not sure I *believe* in them)
10:12 < elliot> or there is no networking
10:12 < pjones> elliot: fallback to vnc is still possible
10:12 < jlaska> clumens: can you explain more on the " - get rid of install methods" ?
10:12 < pjones> if there's no networking, that's harder, but... really, how much do we want to be in the business of working around x bugs?
10:13 < dcantrell> the enterprise customers do not like "use VNC" as an answer, which is ok.  but newt is crap on serial console, which is what they want anyway
10:13 < clumens> like i said, perhaps something q-and-a oriented.  i dunno.  point is, we give existing text mode no love at all and it supports a subset of the things anaconda can actually do.
10:13 < dcantrell> I would like for newt and textw to be replaced with something more q-and-a oriented, like clumens said
10:13 < notting> clumens: isn't that the case already?
10:13 < clumens> jlaska: the idea there being we move more of the stuff in harddrive.py, urlinstall.py, etc. into yum and use its code where appropriate.
10:14 < elliot> clumens: q and a sounds good to me
10:14 < pjones> jlaska: dunno if it's precisely what he meant, but they should all be the same codepath, and changes in behavior should be determined by something akin to comps, not hardcoding each one
10:14 < f13> notting: that's what he's saying.  It's not likely to change.
10:14 < jlaska> clumens: pjones: ah thanks ... so the externals are same/similar ... but the underlying mechanism uses existing commong code (yum?)
10:14 < pjones> annnnnyway, we should stick with making a list right now, and discuss them as a phase 2 in a little while.
10:14 < clumens> jeremy and i discussed killing release notes the other day as well.
10:15 < clumens> which is part of the install method stuff, oddly enough
10:15 < f13> clumens: so if we kill relnotes frominstaller, and given that they've been killed from the start page, we wouldn't even have to package them anymore right?
10:15 < jgranados> clumens : + for killing release notes.  don't see the point in installer.
10:15 < msivak> elliot: how do we incorporate it into the existing anaconda.intf system? the text mode now is at least simmilar in concept to graphical install, but q/a system is a little bit more different
10:16 < jeremybb> Not that different really
10:16 < elliot> msivak: it is already there, just needs more work
10:16 < clumens> think of Q&A mode as deprecating text mode :)
10:17 < jgranados> clumens : would q&a mode mean use of fdisk, (for example)?
10:18 < pjones> f13: the text ought to still wind up in /usr/share/docs someplace, I'd hope...
10:18 < jeremybb> Death to fdisk :)
10:18 < elliot> msivak: this would probably build off of cmdline.py and implement an intf compatible interface
10:18 < f13> pjones: who looks there though, if we don't link to it from anything?
10:18 < pjones> jeremybb: we really should write the parted fdisk writer
10:19 < pjones> f13: I'd expect a link from the firefox start page as well
10:19 < clumens> pjones: i believe that's on dcantrell's TODO
10:19 < elliot> jgranados: fdisk is the past, parted is the future :)
10:19 < f13> pjones: the link from the FF start page goes to the live content, since we're using start.fedoraproject.org now.
10:19 < f13> bypassing the on-disk content, which is often outdated anyway
10:19 < clumens> jgranados: it'd either drop you into parted or similar menu system, or ask you to enter ks partitioning strings (eeeew)
10:19 < pjones> f13: yeah... so that ought to give you a link to the release notes for your current version ;)
10:20 < clumens> okay let's not get mired down in the details too much for now.  who would like to get their crazy ideas out there next?
10:20 < elliot> clumens: i'm for a menu system rather than kickstart strings
10:20 < f13> pjones: I think it does, just the live on teh web ones.
10:20 < pjones> f13: that's fine.
10:20 < notting> clumens: if going by order ... -> dcantrell?
10:20 < pjones> f13: I still think we should keep it in /usr/share/docs though
10:20 < f13> clumens: sadly I think one day I need to take over the scripts/ stuff from you.
10:20 < pjones> f13: anyway, that's details.
10:20 < f13> pjones: indeed.
10:20 < clumens> f13: agreed, and you are welcome to them.
10:20 < f13> clumens: I jsut don't want them.
10:21 < clumens> f13: kill them and rewrite.  i don't think anyone will be broken up about that.
10:21 < elliot> f13: maybe in something other than shell :)
10:21 < pjones> elliot: I'm not sure that'll make them better, though at the moment they're in really painful shell
10:22 < jgranados> f13 : if you decide to venture into the scripts rewriting thing, id be willing to help.
10:22 < pjones> they sort of grew backwards.
10:22 -!- dcantrell_ [i=dcantrel@nat/redhat/x-2ca68431c9078430] has joined #anaconda
10:22 < elliot> pjones: yea
10:22 < clumens> dcantrell_: you're up.
10:22 -!- mull [n=agrimm@rdu-nat.rpath.com] has joined #anaconda
10:22 < dcantrell_> of course right when the VPN falls over
10:23 < dcantrell_> ok, so my list is short because most of my ideas overlap with other ideas that have been said or will be said
10:23 < jeremybb> Could be worse. Could be your power
10:23 < dcantrell_> 1) anaconda and related components need to relicense as GPLv2+.  I need this in order to upgrade parted and pyparted.  mkinitrd, and whatever else is using that stuff.
10:24 < dcantrell_> 2) a lot of the backend partitioning code will be in the new pyparted, so I would like that to be gutted and updated to use the new pyparted as much as possible.
10:24 < jeremybb> Anaconda is now in the clear for it, we just need to go through the updating boiler plate pain
10:25 < jeremybb> What sort of time frame are you expecting with the new pyparted stuff?
10:25 < dcantrell_> 3) as clumens stated, deprecate textw in favor of a non-ncurses non-whatever text mode Q&A type interface.  my vision of that is we are basically providing the same next/back UI in text mode but with simple question prompts.  but clumens has already brought this up
10:25 -!- jeremy [i=katzj@freenode/unconfirmed/jeremy] has quit [Read error: 110 (Connection timed out)]
10:25 < clumens> yeah sorry, i took one of your answers
10:26 < dcantrell_> jeremy: new pyparted will come in stages.  first stage is reimplementing the existing API with it all marked as deprecated.  then moving anaconda to using the new API.  at this point it's looking like days for the new pyparted with the old API will be ready
10:26 < jlaska> dcantrell_: my only worry there is legacy support ... which isn't as important for fedora ... but required for some funkier archs (ia64,s390x) or serial console attached systems
10:26 < dcantrell_> jeremy: that's sort of the most important thing to me right now
10:26 < jlaska> dcantrell_: clumens: so as long as we keep some cmdline style mode ... works for me :)
10:27 < dcantrell_> jlaska: but a non-newt non-ncurses interface is actually better on those goofy systems
10:27 < jlaska> definitely
10:27 < dcantrell_> ok, last one
10:27 < jeremybb> It just seems like a massive overhaul of partitioning is a bigger than f9 project
10:27 < dcantrell_> 4) entirely removing netpostconfig in stage2, force NetworkManager on.  no more post network interface configuration
10:27 < jeremybb> And should probably be largely driven by working outside of anaconda and then dropping something in
10:28 < jlaska> can network details be added as a firstboot dialog?
10:28 < dcantrell_> jeremybb: it is, that's why I wanted to approach it more cautiously.  providing the old pyparted API is key there.
10:28 < f13> jlaska: I'd really like to see firstboot die.
10:28 < notting> jlaska: well, there would need to be *something* to enter settings for the NM system daemon
10:28 < jeremybb> I think how we handle the NM transistion is still somewhat TBD
10:28 < f13> but alas that probably won't happen.
10:28 < elliot> dcantrell_: what about distros that use anaconda and don't ship network manager?
10:28 < f13> if nto die, get shorter, rather than longer.
10:29 < jlaska> systems with 13 NICs ... NICs on different vlans (ipv4 vs ipv6) ... dhcp and static 
10:29 < jeremybb> Elliot: no time like the present ;)
10:29 < pjones> jlaska: >13 nics we should already support
10:29 < elliot> jeremybb: not going to happen :)
10:29 < dcantrell_> elliot: we should give the user the option of starting NM or writing out what network info was collected.  that only works for network installs now, I guess.
10:29 < jlaska> pjones: but does NM?
10:29 < pjones> jlaska: vlans would be nice, though
10:30 < pjones> jlaska: I don't know why not, but if it doesn't, it's a bug fix, not a feature
10:30 < pjones> jlaska: (though what it _does_ with all those nics may still be an open question ;)
10:30 < clumens> f13: we've pretty much decided firstboot can't die, but shorter is the plan.
10:30 < jlaska> firstboot is easily disabled for those who don't need it
10:31 < jeremybb> I don't know that "do you want NM is ever a resonanle question to ask
10:31 < dcantrell_> for systems with tens, dozens, hundreds of NICs, are they really going to use the point and click anaconda UI to configure them?  maybe an ex-Windows admin would
10:31 < pjones> jeremybb: I don't think it is
10:31  * elliot already dropped firstboot except for the bits that anaconda requires
10:31 < f13> yeah, I just don't like the attitude of a other people suggesting we "fix" thigns by shoving another firstboot screen in people's faces.
10:31 < pjones> jeremybb: the fact that it's a question basically reflects situations where NM is broken and needs fixed.
10:31 < f13> jlaska: I'm not accusing you of doing this.
10:31 < jeremybb> Right
10:31 < jlaska> f13 :)
10:32 < jlaska> f13: just trying to suggest a way to keep the feature, but lighten the code on the anaconda side
10:32 -!- stew_ [n=cleepdar@207.58.190.216] has joined #anaconda
10:32 < f13> nod
10:32 < notting> it may be that the NM system settings reads the same lame config files. in which case anaconda doesn't need to do anything
10:32 < dcantrell_> so if we want NM to take over entirely, we basically have a lot of work to do in NM
10:33 < jeremybb> Elliot: I suspect that the outcome for you guys not doing NM will be a need for you to have some other settings write out code and more will end up being set up post install with whatever tools you provide
10:33 < jeremybb> Dcantrell: have you talked with dcbw yet?
10:34 < notting> ssp is doing the system settings daemon, as well
10:34 < dcantrell_> jeremybb: for some reason he never talks to me.  ever.  in the office
10:34 < elliot> jeremybb: yea, basically I just care about there being configuration for the first interface so that people can get to the management console on an appliance in the case where there is no dhcp
10:34 < dcantrell_> jeremybb: he will talk to you and other people, but he just stares at me
10:35 < jeremybb> I'll poke him later or tomorrow then
10:35 -!- dcantrell [i=dcantrel@nat/redhat/x-3ff6994fd0086f03] has quit [Read error: 110 (Connection timed out)]
10:35 < dcantrell_> hey, I didn't quit
10:36 < elliot> jeremybb: how does nm configuration work when there is no X?
10:36 < jeremybb> System config daemon should be landing very soon
10:37 < jlaska> jeremybb: is that the work I read recently that also provides static IP support?
10:37 < jeremybb> Yes
10:37 < jlaska> cool
10:37 < elliot> jeremybb: I take it that will have some cli interface?
10:37 < elliot> s/interface//
10:38 < jeremybb> To set up? Probably. 
10:38 < notting> (veering waaay off topic) nm needs to talk to a daemon of some sort for settings. it will not be directly proddable via command line.
10:38 < mull> elliot: cli is not as important as a usable python API
10:38 < elliot> jeremybb: yea
10:38 < jeremybb> I haven't actually looked at the code yet
10:38 < elliot> jeremybb: just trying to think how initscripts will hook into it
10:38 < elliot> jeremybb: unless you guys are dropping initscripts in favor of something else
10:39 < jeremybb> But as the plan for f9 is NM by default, we have to make sure anaconda is following along
10:39 < jeremybb> Anyway... Obviously needs some discussion once we have more implementation details
10:40 < dcantrell_> so those were the only 4 items I had on my list
10:40 < dcantrell_> next up... dlehman?
10:40 < dlehman> I only have one, and it's borrowed/stolen from jeremy
10:40 < dlehman> encrypted filesystem support
10:41 < dlehman> just LUKS/dm-crypt to begin with
10:41 < jeremybb> This one would be good to land sooner rather than later
10:41 < dlehman> gonna post a set of patches to the list today
10:42 < jeremybb> And I know dave already has the start of code so that should be doable
10:42 < jeremybb> Cool!
10:42 < dlehman> (although currently there is no handling/discovery of existing encrypted devices)
10:43 < jeremybb> Fine for a starting point
10:44 < dlehman> that's all for me
10:44 < dlehman> elliot?
10:44 < elliot> I like clumens' idea of dropping the newt interface in favor of something more q-a
10:44 < pjones> dlehman: does your patch have initrd code?
10:44 < jeremybb> Any chance we might get the conary backend patches to merge?
10:45 < elliot> jeremybb: yea, also have a tar based backend
10:45 < dlehman> pjones: no support for /boot or / yet
10:45 < pjones> dlehman: /boot is out of the question, / is something we'll need eventually.
10:45 < elliot> jeremybb: just need to generate/clean up the patches
10:45 < notting> dlehman: also, may want to talk to karsten/harald/pknirsch
10:45 < dlehman> pjones: initscripts and mkinitrd are next once we have basic working installer bits
10:46 < pjones> dlehman: yep
10:46 < elliot> jeremybb: I also have a different package selection interface, not sure if that should go upstream
10:46 < f13> dlehman: with encrypted fs and such, does this mean we should go back to suggesting a /home partition by default?
10:46 < notting> dlehman: as they have various patches and ideas here
10:46 < clumens> f13: hooray, that question!
10:46 < dlehman> notting: ok, will do.
10:47 < pjones> f13: no, we should encrypt the PVs VolGroup00 is on when you select encryption, and just have everything except /boot encrypted
10:47 < jeremybb> The problem with separate home is how do you split size wise
10:47 < elliot> I am currently working on switching booty to use a bootloader config templating thing that hpa wrote
10:47 < dlehman> f13: I haven't considered the ramifications WRT "default" partitioning
10:47 < elliot> at least for x86
10:47 < pjones> elliot: I'd be interested in seeing those patches
10:47 < dcantrell_> jeremybb: we should suggest a 640k /home always
10:47 < elliot> pjones: i'll send them your way when I get done
10:47 < f13> jeremybb: oh I know there are tonns of problems with having /home split off :/
10:47 < pjones> works in progress might be nice too ;)
10:47 < elliot> pjones: probably early next week
10:47 < f13> jeremybb: none of them easy.
10:48 < elliot> fwiw, we are switching to extlinux for our next major release
10:48 < jeremybb> Next - Joel?
10:49 < jlaska> do we have decent tools (tui/gui) support for resizing yet?  I would see that assisting in the /home debate
10:49 < jgranados> ok.  msivak is kinda gone :) so I'll talk about his points as well.
10:49 < clumens> jlaska: wait for it...
10:49 < dcantrell_> since we're using git now, maybe we could make an rpath branch in the repo and then we could pilfer the branch periodically and put things in master
10:49 < jlaska> ;)
10:49 < clumens> that'll be coming up when jeremy starts talking
10:50 < elliot> dcantrell_: that would be alright with me
10:50 < elliot> :)
10:50 < jgranados> One of the thing that martin wanted met o mention is the possibility of having or bettering the backend data structure in anaconda.
10:50 < jeremybb> I'd rather just get the changes in rather than floating off to the side forever
10:50 < jgranados> just have one central data structure and use that throughout the whole install.
10:50 < jlaska> jeremybb: pjones: clumens: dcantrell_ : how do you want to organize the "free-for-all" discussion portion?
10:50 < clumens> jgranados: that goes in with what i was saying about using ksdata instead of instdata
10:51 < pjones> jlaska: wait until we get there ;)
10:51 < jeremybb> That ties in with Chris's instdata and kickstart stuff
10:51 < jlaska> heh ... true :)
10:51 < jgranados> clumens : of course.  but up until now Its just an idea for me and msivak has not given me any more info. 
10:51 < pjones> jgranados: use for what exactly?  I'd like a main loop ;)
10:51 < pjones> (and a pony!)
10:52 < elliot> i'd like to see the backend data types defined better
10:52 < jgranados> pjones : I can do the pony.  dont know about the main loop though.
10:52 < jgranados> elliot : + thats, part of my point.  create/better.
10:52 < jgranados> that msivaks dragon. :)
10:53 < jgranados> I would like to work on the partitioning process backend.
10:53 < jgranados> not the pyparted stuff
10:53 < jgranados> the structure for representing the partitions, lvm, raid, free space ....
10:53 < pjones> partitioning UI is one of the things I was going to bring up
10:54 < jgranados> have some very good ideas. but want to get some code done before I show any one :)
10:54 < pjones> (and to make it sane, the backend needs a major overhaul)
10:54 < jeremybb> The idea though is we push more of that down
10:54 < pjones> yeah.  move a lot of the special casing into parted bindings to start with.
10:54 -!- esandeen [n=sandeen@sandeen.net] has joined #anaconda
10:54 < pjones> I don't think liblvm is going to land soon enough for f9, which is too bad because I'd really like it for RHEL 6 :/
10:54 < dcantrell_> pjones: which is what I'm working on
10:55 < pjones> dcantrell_: nod
10:55 < clumens> clearly we're going to have to coordinate partitioning ideas since it seems everyone has some of those
10:55 < jgranados> pjones , jeremybb : I think the same, but I was thinking more of a modular representation that allows anyone to just connect their "strange Filesystem thingi" to anaconda.
10:55 < jeremybb> So I think the key for any big partitioning overhaul is to start it outside of anaconda
10:55 < clumens> jeremybb: yeah
10:56 < jgranados> jeremybb : totally agree.
10:56 < jeremybb> Show it working eg from a live cd and then we connect it up in anaconda
10:56 < clumens> (which gets us into the thing that davidz was either working on or talking about)
10:56 < clumens> there i said it
10:56 < jeremybb> Much like we did with yum and the rest of the packaging stuff
10:57 < jeremybb> And I think its worth some time being spent. I also think its a two release cycle type of project
10:57 < jgranados> ok, thats what our points were.
10:57 < jgranados> jeremybb ?
10:58  * notting wonders at what point with server -> iscsi and laptop -> single disk that partitioning becomes irrelevant
10:58 < pjones> jeremybb: yeah, first we need a library that can do the things anaconda needs.
10:58 < jeremybb> (having done the last replace the partitioning code push. And there's more for it to do now)
10:58 < pjones> notting: depends.  do we keep pretending dual booting is worth supporting?
10:58 < clumens> agreed to more and more libraries and external projects.
10:59 < jeremybb> Peter - I'd argue that we need to look at what we're trying to enable before writing libraries
10:59 < pjones> jeremybb: I'd not disagree with that.
10:59 < pjones> hince "the things anaconda needs".
10:59 < clumens> well now that we're all in violent agreement...
10:59 < pjones> (might be worth seeing what others need as well ;)
11:00 < jeremybb> Notting - more multi disk laptops coming out. And lots of people still want on box storage
11:00 < notting> jeremybb: yeah, but just a lot of effort for something people do only once
11:00 < jeremybb> Anyway I think it may make sense to do a follow up on big partitioning overhails
11:00 < pjones> we also need to handle things like "plug in your usb disk to save a traceback" better than we do now
11:01 < jeremybb> Notting: the installer in a nut shell is lots of time on things done once
11:01 < clumens> pjones: all i need is the detecting new USB disks and that's done.
11:01 < notting> who's next?
11:01 < dcantrell_> nasrat?  :)
11:02 < nasrat> dcantrell_: nothing to see here
11:02 < pjones> clumens: yeah.
11:03 < dcantrell_> pjones: go
11:03 < jgranados> pjones : any work on liblvm at all?
11:03 < jeremybb> My big ticket things which we haven't been through
11:03 < jlaska> nasrat: greetings!
11:03 < jeremybb> Or peter can go
11:03 < pjones> you can go first, since we're being alphabetical.
11:04 < pjones> (ish)
11:04 < jeremybb> One thing I'd like to see improve is rescue mode
11:04 < f13> as in make it clearer that you can use it to install, or just making it more useful as a rescue tool?
11:04 < jeremybb> Which we can then call first aid kit (thanks to peter)
11:05 < jeremybb> Useful as a tool
11:05 < jeremybb> I'd actually like if Joel and msivak could own that
11:05 < dcantrell_> you mean FirstAidKit
11:05 < jgranados> jeremybb : yep, I remember, the automated recovery thing.
11:05 < jgranados> right.
11:06 < jeremybb> Yes, I'm just typing on my phone
11:06 < jgranados> to execute rescue and for it to automatically got and fix your system:)
11:06 < jlaska> what sort of functions do we typically use rescue mode for (disk probing, bootloader corrupt)
11:06 < jlaska> wondering if there is a pattern that might help how to organize the data presented in FirstAidKit
11:06 < jeremybb> And have a list of common tasks etc
11:07 < f13> this sounds like something that /will/ effect the compose process
11:07 < jeremybb> I have a little more typed up but can't get to it now 
11:07 < jgranados> and the tasks could appear in the boot loader, or something.
11:07 < jeremybb> No it should be under the covers of the compose entirely
11:07 < jgranados> I'm for it,  i'd have to ask msivak  what he thinks. :)
11:07 < esandeen> jlaska, root fs repair too
11:08 < jlaska> are these tasks something like firstboot-tui style questions? (poor choice of app name ... but just for an example)
11:08 < jlaska> esandeen: good call
11:08 < f13> jeremybb: beyond adding more packages to the tree for the compose...?
11:08 < pjones> jlaska: retrieving broken initrds from the broken install? :/
11:08 < jgranados> jeremybb : yep.  like `linux rescue NAME`
11:08 < jeremybb> There are some little things like finishing up the preupgrade stuff and looking at using libblkid instead of our stuff
11:09 < jeremybb> James - that's what I had in mind
11:09 < pjones> rescue mode might also be the place to put tools for doing things like (as a random example) figuring out that you've got two lvm VGs named "VolGroup00" and renaming one of them /sanely/,
11:09 < pjones> .
11:10 < pjones> jeremybb: yeah, a lot of isys's fs detection stuff should be ripped out entirely in favor of libblkid
11:10 < esandeen> +1
11:10 < clumens> jeremybb: don't forget your other big partitioning one
11:10 < esandeen> it'd be nice to have a lot less hard-coded fs stuff
11:10 < jlaska> jeremybb: tui/gui ... might this just be a collection for system-config-* tools? ... or more specific applications?
11:11 < jeremybb> Also if we can make the pieces available from the live cd that would be good to
11:11 < jeremybb> The two bigger things are ripping out kudzu
11:11 < pjones> esandeen: it'd be an interesting experiment to drive the filesystem creation code from some sort of template rather than from individual code for each FS type.
11:11 < jeremybb> And seeing what we can do for resizing partitions
11:11 < jlaska> jeremybb: what bugs you about the current rescue mode?
11:11 < esandeen> pjones, yes.  though there are special ways to do things like label, I guess.. I don't think there's common infrastructure for everything anaconda has to do
11:12 -!- nasrat [n=nasrat@91.84.17.49] has quit ["Leaving"]
11:12 < pjones> jeremybb: the thing about resizing is that 90% of the utility is only applicable to ntfs and hfs+
11:12 < clumens> pjones: livecd + resizing ntfs = hooray!
11:12 < jeremybb> James - drop to shell only helps experts
11:12 < pjones> esandeen: yeah, but generally it's all of the form of "run this string with these format specifiers"
11:12 < esandeen> pjones, true
11:12 < jeremybb> We have the ntfs bits in fedora
11:13 < pjones> yeah.  just wanting to get into the log that that's what we need to focus on.
11:13 < esandeen> pjones, yes, it'd be nice if there were an easy way to toss in new filesystem support, with a foo.ko and a template of how to mkfs/mount/whatnot the new thingy.  like a driver disk for filesystems
11:13 < pjones> esandeen: exactly what I was thinking.
11:13 < esandeen> F9 on btrfs, whee :)
11:13 < jeremybb> I've started a hack to see how feasible resize is. Should know more in a week or three
11:13 < pjones> esandeen: which means relaxing some of the rules within anaconda ("can't use this for /boot", etc.)
11:14 < esandeen> pjones, true.  though the template can say "grub_ok=no" or whatever
11:14 < pjones> esandeen: well, there's also a "on this arch, /boot really does have to be this fs type..." problem there.
11:14 < pjones> esandeen: so it can't just be a free-for-all
11:14 < jgranados> pjones , esandeen : that would be one of the objective of what I was commenting on earlier.
11:14 < jeremybb> We could easily split into a filesystems dir and let you drop in new ones that way
11:15 < elliot> pjones: also with extlinux, there is with this bootloader /boot must be this fs
11:16 < jgranados> I think the template should address restrictions also :)
11:16 < jgranados> add this fs but dont use on /boot.
11:16 < jeremybb> We're off in the weeds again
11:16 < clumens> that's a two stroke penalty
11:16 < esandeen> OTOH - how critical is it that we be able to toss in all these new filesystems.... is this an oft-requested feature?  I know I want to test ext4 installs, but....
11:17 < clumens> so who else has ideas to present?
11:17 < clumens> scruffy?  katrina?  zanthar?
11:17 < jlaska> can we drop rescue mode entirely in favor of the just the liveCD?
11:17 < jeremybb> Its not that common; its an occasional thing and it always ends up being a few at a time
11:17 < pjones> I still have a list ;)
11:17 < clumens> pjones: out with it!
11:17 < jeremybb> James - no. Longer answer when I can type
11:17 < pjones> ok, so
11:18 < jlaska> jeremybb: roger ... thx
11:18 < pjones> 1) EDD needs a rework, it's at too low of a level right now and needs the data exposed to higher level code
11:18 < pjones> 2) still need to figure out the right way to do things like multipath, which sucks
11:19 < pjones> 3) (not just anaconda but pertinent because of FirstAidKit) dmraid rebuilds/recovery?
11:19 -!- dcantrell_ [i=dcantrel@nat/redhat/x-2ca68431c9078430] has quit ["Leaving"]
11:19 < esandeen> I came here as an fs weennie, but as a user:  I'd like to see a simpler/guided way to set up a VNC install, not cryptic boot-time commandline stuff
11:19 < pjones> 4) we still have plenty of widgets that need gladification
11:19 < clumens> pjones: YES
11:20 < jgranados> esandeen : whats so difficult about vnc vncpassword= vncconnect= ?
11:20 < pjones> 5) for fuck's sake, dispatch.py is still totally unreadable.
11:20 < pjones>   (a main loop might help that situation some)
11:20 < esandeen> jgranados, if you know it exists, it's not so hard.  but then what's so cryptic about dropping to a shell and running mkfs?
11:20 < esandeen> yet there is a nice clicky interface instead, for that, because it's easier/more intuitive
11:20 < pjones> jgranados: if nothing else, it needs maintenance in the loader and in the proper installer, and anything with two sets of code winds up breaking more than things with one.
11:21 < jeremybb> We give you an easy way to do vnc if x fails
11:21 < pjones> 6) moving lvm stuff into parted would be nice, but I don't think we'll get liblvm on time unless we devote somebody to it full time :/
11:22 < esandeen> *shrug* when I want to do a vnc install, I always have to start with google, i all I'm saying :)
11:22 < jgranados> pjones : Im for liblvm
11:22 < jeremybb> Doing more is more questions in the loader (would rather not) or bootloader fun
11:22 < pjones> jgranados: we're basically dependent on the storage group's schedule on that one, at least so far.  I need to do more followup there.
11:23 < pjones> 7) efi support on x86 (but I might have that knocked out soon)
11:23 < jgranados> pjones : do you know if mbroz has to do anything with it.
11:23 < pjones> jgranados: I'm not sure what the status is currently at all.
11:23 < jgranados> pjones : he is in the office (Brno) and I can maybe work with him.
11:23 < jgranados> pjones : ill look into it:)
11:24 < pjones> jgranados: last I heard the plan was still "use the design pjones wrote in a half-hour email rant because he was pissed off at getting blocker bugs filed because of crappy lvm tools", so... who knows ;)
11:25 < pjones> hrm.  I think those 7 are my list, but maybe I'll come up with something else in a few.
11:25 < pjones> well, 8) lots of code could really stand to be more modularized.  We should use subdirs a lot more.
11:25 < clumens> and now we have the power to do that.
11:26 < pjones> in a way, we ought to consider bringing booty back into anaconda, but as a subdir.
11:26 < jgranados> im for pjones' 8),  I give it a bit +.
11:26 < jgranados> s/bit/big
11:26 < pjones> they have intimate knowledge of each other no matter what :/
11:26  * elliot is all for bringing booty back into anaconda
11:26 < jeremybb> We only split booty out so something post-install could use it. But that never matrialized
11:27 < pjones> yeah.
11:27 < elliot> up2date used it iirc
11:27 < jeremybb> So we can bring it back easily enough
11:27 < clumens> i'm all for it.
11:27 < f13> could still build it as a subpackage if ou wanted something external to use it
11:27 < f13> but keep it in the same scm
11:27 < pjones> f13: exactly.
11:27 < f13> but you all know that already (:
11:27 < clumens> clumens@exeter:~/src/anaconda$ repoquery -q --whatrequires booty
11:27 < clumens> anaconda-0:11.3.0.50-2.i386
11:28 < pjones> getting rid of gptsync would be nice, but that basically ties in with #7 (though we're only doing efi64 support in my #7 right /now/, so they are separate)
11:28 < pjones> ok, who's next in line?
11:28 < jeremybb> So the next thing is breaking things down into who has the ball, when its going to land etc
11:29 < jeremybb> But we can do that via mail probably
11:29 < clumens> this is only a quick man-decade of work, huh?
11:29  * f13 raises his hand
11:29 < jeremybb> I can take Chris's log and then create some pages for us to work from on things
11:29 < clumens> jeremybb: i also kept notes of the main points, too
11:29 < clumens> f13: go!
11:30 < f13> It looks like everything mentioned here today pretty much avoids scripts/ all together
11:30 < jeremybb> Yes Jesse?
11:30 < f13> and if that's the case, maybe this would be a good time to focus on rewriting that stuff or splitting it out
11:30 < f13> if nobody else is going to be making changes there.
11:30 < f13> I seriously doubt I could have it done by F9, but it could be in progress, and target before the next RHEL
11:30 < dlehman> f13: the fs encryption will minimally modify package/file/module lists but that's all
11:30 < pjones> f13: scripts should totally go someplace else ;)
11:30 < jeremybb> Honestly? I think what's there mostly works and its not worth spending a lot of time on it this time around
11:31 < f13> jeremybb: it's the mostly that bugs me.
11:31 < pjones> f13: F9 basically is the RHEL6 branch point :/
11:31 < f13> jeremybb: especially when we get weird ass errors like I've gotten the past week in rawhide, but nobody has a clue whats going on.
11:31 < f13> debugging the compose process is pretty painful
11:31 < jeremybb> I'm not going to say don't look at it, but things like the signing server and the like are more pressing needs
11:31 < f13> but, if you want to keep it, by all means.
11:32 < f13> jeremybb: sure
11:33 < jgranados> I have a question that is been eating at me for some days :)
11:34 < jgranados> what do people feel about xml ks files?
11:34 < f13> Part of the rescue mode stuff, I'd like to come up with a better name for that iso to make it more clear it can be used to install from
11:34  * jgranados prepares to be beaten :)
11:34 < f13> particularly for installing against mutliple different trees
11:34 < pjones> jgranados: waste of time *and* annoying.
11:34 < atodorov> jgranados: %post in xml will look ugly if many characters escaped
11:34 < pjones> jgranados: if we support them, we wind up having to support *both* formats, which gets ugly quickly
11:34 < f13> jgranados: I don't necessarily see the point, unless clumens wants to use it.  The rest of us should be using pykickstart for everything and then we don't care about the format.
11:35 < pjones> (also, xml is the devil.)
11:35 < jeremybb> Jesse - that's less rescue mode, more method removal stuff that Chris is going to work on ;)
11:35 < f13> jeremybb: ok.
11:35 < jeremybb> Kickstart being writable by hand is a huge plus accurding to customers
11:35 < jeremybb> So just say no to xml
11:35 < pjones> jeremybb: not so much "huge plus" as "absolute requirement", I think.
11:36 < elliot> at the least must be human parsable 
11:37 < clumens> yeah i'm not really a fan of it
11:37 < clumens> okay so what's the next step in this massive list of ideas?
11:37 < atodorov> lettme go for stage2 features
11:37 < jeremybb> I'll do some collation and then send to the list
11:38 < clumens> jeremybb: alright.  then we need to think about priorities.
11:38 < jeremybb> Hopefully later today or tomorrow
11:38 < jgranados> any comments about git stuff?
11:38 < jgranados> I dont have any, but was wondering.
11:38 < jeremybb> Yep. But we've probably gone on about as long as we should today
11:38 < jgranados> ok, so, anaconda-devel for git comments.
11:39 < atodorov> jeremybb, clumens: Dotail support in Anaconda?
11:39 < atodorov> s/Dotail/Dogtail
11:39 < clumens> yeah maybe i should hand those bugs over to someone who's going to run with them.
11:40 < pjones> atodorov: yeah, could definitely be useful.  sortof goes along with gladification of more widgets.
11:40 < atodorov> pjones: agree
11:41 < atodorov> pjones: we can use Dogtail to build on top of it. e.g. Screen magnifier, narrator, etc,  anything that has to do with accessible installs (and testting the GUI)
11:42 < esandeen> ooh how about zeroconf discovery of install servers? :)
11:43 < atodorov> esandeen: merge that with the mirrors feature discussed on anaconda-devel ?
11:43 < esandeen> atodorov, guess I missed that discussion... I'll go look
11:44 < esandeen> though zeroconf is no good with routers in between I think
11:44 < jlaska> esandeen: snake supports avahi notification
11:46 < esandeen> jlaska, what is snake?  (sorry, now I'm just an interloper here)
11:46 < jlaska> esandeen: https://hosted.fedoraproject.org/projects/snake  - something we're trying to get off the ground to assist with installation testing
11:47 < jeremybb> Ok. I'm going to head somewhere with power now I think
11:47 < jlaska> jeremybb: any thoughts on --stage2url=  support for anaconda?
11:47 < jeremybb> Tied in with one of Chris's things
11:47 < jlaska> jeremybb: /me will read the log ... I detached for a moment on this end
11:47 < jlaska> jeremybb: thx
11:48 -!- ragnark [n=ragnark@stine.vestdata.no] has joined #anaconda
11:48 < clumens> one of my things?  heh, i don't have all that many things.
11:49 < jeremybb> Don't worry, I can give you a few more
11:49 < esandeen> I'm just thinking of the annoyances I have when doing installs in the lab; we have a local http install source, but typing the name/ip and path is always tedious.  I'd love to have zeroconf-discovered install sources to choose from
11:50 < notting> esandeen: that pretty much requires the moving of install sources out of hte loader directly
11:50 < jlaska> esandeen: that's a use case that snake models now ... SNAKE (smart network automated kickstart env) allows you to point to installable mirrors (http, ftp, nfs (soon)) ... and from the client easily select a tree+kickstart to install from
11:51 < esandeen> jlaska, that sounds cool, I'll have to give it a shot