20:00:10 <pwhalen> #startmeeting Fedora ARM weekly status meeting
20:00:10 <zodbot> Meeting started Wed Apr  3 20:00:10 2013 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:11 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore
20:00:11 <zodbot> Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen
20:00:19 <ctyler> .fas chris@tylers.info
20:00:19 <ctyler> Howdy all!
20:00:19 <zodbot> ctyler: ctyler 'Chris Tyler' <chris@tylers.info>
20:00:19 <jcapik> .fas jcapik
20:00:21 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:00:22 <pwhalen> good afternoon all
20:00:26 <pwhalen> .fas pwhalen
20:00:26 <bconoboy> .fas blc@
20:00:26 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
20:00:29 <zodbot> bconoboy: blc '' <blc@redhat.com>
20:00:31 <dmarlin> .fas dmarlin
20:00:36 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:00:48 * masta waves
20:01:14 <masta> .fas parasense
20:01:15 <zodbot> masta: parasense 'Jon Disnard' <jdisnard@gmail.com>
20:01:46 <pwhalen> #topic 0) Status of ACTION items from our previous meeting
20:01:46 <pwhalen> #link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-03-27/fedora-meeting-1.2013-03-27-20.00.html
20:02:10 * nirik is here, has a few phx2 news items for anyone interested at whatever time you wish me to report them. ;)
20:02:16 <jonmasters> .fas jonmasters
20:02:16 <zodbot> jonmasters: jcm 'Jon Masters' <jonathan@jonmasters.org>
20:02:16 <fossjon> .fas fossjon
20:02:19 <zodbot> fossjon: fossjon 'Jon' <jonc_mailbox@yahoo.ca>
20:02:22 <pwhalen> #info -INPROGRESS- pbrobinson to post a list of leaf packages to arm@lists.fp.o
20:02:41 <pwhalen> that was our only action item, I may have missed this on the mailing list
20:03:58 <pwhalen> anything else?
20:04:20 * j_dulaney waves
20:04:40 <bconoboy> next?
20:04:48 <pwhalen> #topic 1) Problem Packages
20:05:32 <bconoboy> Anaconda we're discussing elsewhere...
20:05:39 <masta> some folks were talking about hfs over the last week
20:05:59 <bconoboy> dmarlin: Can you summarize tog-pegasus and mongodb?
20:05:59 <jonmasters> masta: yea, that's in hand elsewhere for now
20:06:28 <dmarlin> tog-pegasus - one test hangs, otherwise it builds and passes tests... still under investigation
20:06:29 <pwhalen> #info from last week tog-pegasus, mongodb, being analyzed : rubygem-RedCloth
20:06:54 <dmarlin> mongodb - pbrobinson said there was a newer version I should try, but I have not found it in a fedora build yet
20:07:05 <pwhalen> #info tog-pegasus - one test hangs, otherwise it builds and passes tests, still under investigation
20:07:09 <bconoboy> if there are any advanced python hackers around who grok multithreaded code it would be helpful fo tog-pegasus
20:08:01 <j_dulaney> bconoboy:  I can help there
20:08:14 <j_dulaney> bconoboy:  Is there a bugzilla or something listing what is going on?
20:08:17 <bconoboy> sorry, not python, c++
20:08:41 <j_dulaney> Ah
20:08:47 <jonmasters> I chatted with David about it yesterday, briefly
20:08:58 <jonmasters> I'm short on time, but de facto can assist if I get everything else done :)
20:09:06 <jonmasters> (hopefully someone else can assist!)
20:09:15 <bconoboy> anybody have other problem packages in f19?
20:10:07 <pwhalen> next?
20:10:07 <j_dulaney> bconoboy:  Still would like to check it out
20:10:35 <dmarlin> j_dulaney: I have the bits, so all help is appreciated
20:10:48 <dmarlin> j_dulaney: we can coordinate after the meeting
20:10:57 <j_dulaney> dmarlin:  Roger
20:11:10 <pwhalen> jcapik, was there any progress on rubygem-RedCloth?
20:12:14 <jcapik> pwhalen: jstribny is still trying
20:12:22 * jonmasters wonders if pwhalen might publish periodic problem package reports (other than the automated ones) calling out these things we end up discussing here so that those wanting to assist have a ready laundry list of stuff to poke at
20:12:42 <masta> +1
20:13:13 <pwhalen> jonmasters, sure, would need some co-ordination with pbrobinson as well
20:13:35 <jonmasters> yea, please followup with him on that later, thanks mna
20:13:38 <jonmasters> * man
20:13:47 <masta> it's no problem to give a package build a whirl and see what the problem is.... so a list would be great
20:14:00 <pwhalen> #action pwhalen to work with pbrobinson to publish weekly problem package reports
20:14:24 <dmarlin> is this different from the blockers in the minutes from this meeting each week?
20:14:35 <dmarlin> (the list)
20:14:47 <pwhalen> #info jstribny is still investigating rubygem-RedCloth
20:15:25 <pwhalen> next?
20:15:35 <bconoboy> +1
20:15:45 <pwhalen> dmarlin, I imagine a larger list then what we discuss here (hopefully)
20:15:52 <pwhalen> #topic 2) A10 Support in Fedora 19
20:16:16 <masta> oh did a10 land upstream?
20:16:20 <bconoboy> Is anybody using an Allwinner A10 with an upstream kernel?
20:16:43 <bconoboy> We *think* it's not quite there yet in 3.9, but would like to know if anybody has a different experience
20:16:51 <masta> last i tried it didn't work, but perhaps time for another go around
20:17:09 <ctyler> I've been hearing "not quite there" but without much qualification
20:17:44 * masta has mk802 and the board from fudcon... gooseberry or whatever... is happy to test any time
20:18:07 <bconoboy> Our proposed supported list for F19 is currently vexpress, highbank, armada-xp and beagle*/panda, which is a little skimpy.  I'd like to include A10 if the support is there.
20:18:29 <masta> a10 support would be great
20:18:38 * j_dulaney also has a gooseberry from FUDCon, but hasn't tried an upstream kernel on it
20:18:56 <masta> ok so the task is to try an upstream kernel on some boards, see if we can enable in our 3.9?
20:19:11 * j_dulaney will give it a shot this evening, however
20:19:45 <oatley> bconoboy: I'll grab a cubie and try the kernel soon
20:19:57 <bconoboy> okay, sounds like there are 3 volunteers
20:20:21 <bconoboy> this will doubtless require building the kernel too
20:20:49 <masta> I'm pessimistic, but it's worth a shot... we might ping free ellectrons to see what they say about the upstream
20:20:55 <dmarlin> bconoboy: is the a10 part of the multi-platform kernel?
20:21:23 <bconoboy> dmarlin: should be, but it would need to be configured in iiuc
20:21:51 * jonmasters looked at the sunxi code earlier and it looked like it wanted to be multiplatform
20:22:01 <masta> everything 3.8 and higher would be unified in theory ;-)
20:22:02 <jonmasters> I have a few A10 parts - when I get time, I'll poke as well
20:22:18 <jonmasters> so in theory it's fine, but perhaps some of the drivers are not fully in place yet
20:22:31 <jonmasters> the mach- directory is the proper shell that it should be now with everything in devicetree
20:22:39 <jonmasters> (at least from a quick glance earlier on)
20:24:01 <pwhalen> #action masta, j_dulaney, oatley to try upstream kernel on a10 devices
20:24:14 <pwhalen> next?
20:24:39 <pwhalen> #topic 3) Generating the 'boot.scr' for release - Gruboot? Anaconda Library?
20:24:39 <masta> A10 is nice to have, but i'd be fine with a smaller list of supported devices as we are in the odd place between DTB and without
20:24:44 <pwhalen> #undo
20:24:45 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x29921090>
20:24:51 <dgilmore> hey
20:25:17 <pwhalen> #topic 3) Generating the 'boot.scr' for release - Gruboot? Anaconda Library?
20:26:04 <bconoboy> So, we need to make boot images...
20:26:17 <bconoboy> ... and we have a unified kernel ...
20:26:20 <dgilmore> bconoboy: we do, right now we cant make images
20:26:27 <dgilmore> and we cant make install trees
20:26:33 <bconoboy> dgilmore: one thing at a time
20:26:49 <bconoboy> ... a unified kernel suggests that we could have a unified install image
20:26:57 <dgilmore> bconoboy: right
20:27:13 <bconoboy> ... but to date our boot.scr files have been very minimal
20:27:21 <dgilmore> but we need a unified way to get dtb
20:27:27 <bconoboy> ... they didn't really handle dtbs
20:28:04 <bconoboy> ... so we need a way to handle dtbs, and we would like (not need) a way to make unified images
20:28:49 * j_dulaney thinks unified images may be something to go on the list for next time
20:28:50 <bconoboy> I wrote a small script currently called gru-boot that handles this, sort of
20:29:22 <dmarlin> bconoboy: if we have the multi-platform kernel, and u-boot would support bootz, and we can use the franken-script (gruboot), then wouldn't we be 95% there?
20:29:25 <bconoboy> It could be integrated with grubby and made to work for both problems.  It needs testing, though.
20:29:35 <bconoboy> dmarlin: Yes, pretty much
20:29:48 <dmarlin> bconoboy: drawbacks to doing that?
20:29:57 <masta> edge cases
20:30:00 <bconoboy> dmarlin: I'm not sure it's the direction we want to go
20:30:11 <ctyler> because... ?
20:30:11 <dgilmore> dmarlin: no
20:30:18 <dmarlin> dgilmore: why
20:30:33 <bconoboy> I don't get to make that determination because we're a collective, so I'm looking for feedback on what we do want to do.
20:31:11 <dgilmore> dmarlin: because the script at least as i usnderstand it doesnt work that way
20:31:12 <masta> we want bootz, because that removes the load addr's right? but not  all u-boot has bootz, right?
20:31:20 * dmarlin likes multi-platform kernel, bootz, and one boot.scr to rule them all
20:31:42 <bconoboy> We want to use bootz, gru-boot can handle booting with both bootz and bootm
20:31:45 <dmarlin> masta: most do, so we need to 'encourage' the rest
20:32:21 <dmarlin> bconoboy: but bootm still requires a load address (zreladdr) which is platform specific
20:32:25 <bconoboy> gru-boot has two pieces: The side that runs on linux looks at /boot and finds all your kernels and dtbs, then stores them as environment variables in boot.scr
20:32:26 <dgilmore> ideally id prefer uefi and grub
20:32:27 <dmarlin> bconoboy: good reason not to use it
20:32:47 <dmarlin> dgilmore: ideally, I do to, but realsitically today...   :-/
20:33:01 <masta> ok, so the boot.scr that is produced by gru-boot.... what happens in there? is there any if/else things to do the right thing in the case of bootm board?
20:33:23 <bconoboy> The second portion is a boot.scr script that detects what kind of hardware the system is running on, then suggests the right kernel and dtb to load- if it figures out both it will auto load.  If it can't figure out what to do it will present a menu of kernels and dtbs to choose from.
20:33:28 <dgilmore> given what we have today id rather provide tooling that makes it really simple to deploy fedora on any arm system
20:34:04 <masta> bconoboy: that sounds nice
20:34:06 <bconoboy> You effectively get a menu in uboot that lets you pick the kernel and dtb to boot with.  This is really handy when you install a bum kernel.
20:34:23 <dmarlin> dgilmore: considering the various levels of support in the kernel  and many versions of u-boot, is that really realistic?
20:34:26 * j_dulaney can attest to installing bum kernels
20:34:29 <dgilmore> tooling that will make it trivial tomake a sdcard thats a bootable install disk for trimslice etc
20:34:46 <dgilmore> dmarlin: yes
20:34:58 <j_dulaney> dgilmore:  That would be awesome
20:34:58 <dmarlin> dgilmore: very good.  then make it so.   :)
20:35:15 <dmarlin> dgilmore: I'll be glad to test
20:35:39 <j_dulaney> +1 to testing
20:35:45 <ctyler> dgilmore: and the non-installable case?
20:35:45 * j_dulaney will figure out how to break it
20:35:55 <bconoboy> People who want to test it can download a copy at http://people.fedoraproject.org/~blc/fedora-arm/gru-boot/
20:35:57 <masta> it sounds like gru-boot will help make image creation more trivial. am I missing something? we have to maybe run a script seperate from the normal tools for now... but in long run we can put the shell script into the %post of the kickstart
20:36:27 <jonmasters> bconoboy: gru-boot tries to boot automatically as well, right?
20:36:41 <bconoboy> jonmasters: Correct
20:36:43 <dgilmore> ctyler: with the right tooling imaage configuration for deployment should be trivial
20:36:51 <jonmasters> bconoboy: once I've selected the kernel the first time, otherwise it's automatic right? And if I net boot...
20:37:13 <bconoboy> jonmasters: It's always automatic
20:37:19 <jonmasters> bconoboy: I guess if I network boot using that PXE-like extention to U-Boot then it's...yea, ok
20:37:32 <jonmasters> then I'm happy with that as a story to start with
20:37:33 <bconoboy> jonmasters: If you're net booting I don't think you load boot.scr.
20:37:51 <jonmasters> it'll be nice to have the tools Dennis is asking for, but for now, your script gets us somewhere
20:37:52 <dmarlin> bconoboy: correct
20:38:19 <dmarlin> dgilmore: when can we expect the tooling you describe?
20:38:23 <bconoboy> So, going back to the quesiton, do we want to pursue this in F19?
20:38:35 <masta> yes +1
20:38:48 <dgilmore> bconoboy: i think that having manus etc in uboot is extremely useful
20:38:51 <jonmasters> worst case we make per-system (multiplatform) images
20:38:55 <bconoboy> I think dgilmore's idea also has merit, but I would like us to do something for f19 alpha, which is soon
20:39:00 <dgilmore> bconoboy: and something we need
20:39:04 <jonmasters> bconoboy: +1
20:39:14 <dgilmore> bconoboy: i think ultimately we need a bit of both
20:39:22 * jonmasters agrees - Dennis has good ideas, agreed, bit of both
20:39:38 <bconoboy> dgilmore: y, absolutely
20:39:50 <ctyler> +1 to both, it's way too early to cast concrete.
20:39:56 <bconoboy> Okay, so let's do this
20:40:15 <dmarlin> bconoboy: so what is the plan, and who does what?
20:40:24 <bconoboy> People with supported platforms, please try gru-boot out.  I've only tested on trimslice, but it should work with omap/beaglebone, armadaxp, and highbank as well
20:40:25 <masta> bconoboy: lets test the boot.scr in some test images
20:40:47 <bconoboy> If it works, let me know.  If it doesn't work, let me konw.
20:40:51 <dmarlin> masta: we can't make f19 test images right now
20:41:10 <bconoboy> And if you want to run it on a system that I didn't just mention, send me your uboot's "printenv" output and I'll try adding detection.
20:41:18 <masta> dmarlin: we need to hook gru-boot into the %post section of the ks
20:41:22 <bconoboy> I'm currently using it with F18
20:41:48 <bconoboy> #link Magic boot.scr generator needs testing, get it at http://people.fedoraproject.org/~blc/fedora-arm/gru-boot/
20:42:14 <bconoboy> #info trimslice, highbank, armadaxp, beagle* and panda* believed to be supported
20:42:31 <bconoboy> #info send all feedback to bconoboy or the arm list
20:42:52 <jonmasters> thanks Brendan
20:43:39 <pwhalen> next?
20:43:39 <bconoboy> pwhalen: do we have an image generation topic or should we cover that now?
20:43:48 <pwhalen> #topic 4) F19 Alpha image creation
20:43:53 <pwhalen> now :)
20:43:55 <bconoboy> woot
20:44:09 <bconoboy> Status: Anaconda is broken. Live media creator is broken.  How are we going to make images?
20:44:13 <masta> ok so there was some talk about LMC and f19 not working, is that true?
20:44:23 <dmarlin> masta: true
20:44:48 <dmarlin> masta: currently, it just hangs when you try to make an image
20:44:48 <masta> ok, so does anybody have any strong objection to image creation on f18  hosts?
20:45:12 <masta> assuming image creation works on f18 hosts....
20:45:20 <dmarlin> masta: lmc on f18 is simifunctional, at best
20:45:32 <dmarlin> masta: results are not consistent
20:45:36 <jonmasters> dmarlin has reached out to someone I suggested for help debugging python
20:45:53 <dmarlin> masta: we are working on it
20:45:59 <jonmasters> if anyone has time/expertise to help debug please ping David
20:46:08 <dmarlin> yes, please
20:46:10 <j_dulaney> dmarlin:  Ping :)
20:46:17 <dmarlin> j_dulaney: thanks
20:46:23 * masta will drop everything and help here
20:46:45 <dmarlin> masta: j_dulaney we
20:46:52 <jonmasters> #info Anyone with time and expertise in debugging python wanting to help with LMC (Live Media Creator) on F19, please ping David Marlin (dmarlin)
20:47:02 <dmarlin> 'll take this up in #fedora-arm after the meeting
20:47:15 <masta> in the very worst case we can gen images on f17. best case we get f19 env working
20:47:20 <j_dulaney> dmarlin:  Roger
20:47:31 <fossjon> i could try to look at some stuff as well
20:47:32 <dmarlin> masta: that does not work... already tried... too many changes
20:47:37 <fossjon> if its not above my expertise
20:47:48 <nirik> these are live images? or install images?
20:48:09 <bconoboy> nirik: any
20:48:14 <dmarlin> nirik: disk images that we copy to scdard or internal drive
20:48:16 <nirik> ok.
20:48:29 <bconoboy> dmarlin: oh, am I wrong? can we still make anaconda installer images?
20:48:35 <nirik> pungi? livecd-creator? or too much work for them?
20:48:45 <dmarlin> bconoboy: I have not tried, but dgilmore said not on f19
20:48:50 <dmarlin> dgilmore: is that correct?
20:48:51 * j_dulaney wonders if, absolutelly worse case, we can use yum
20:48:52 <masta> nirik: LMC
20:49:05 * nirik notes primary is not using lmc
20:49:16 <jonmasters> j_dulaney: there's always a worst case for alpha but we should use the standard tools if possible
20:49:19 <fossjon> how does primary make images
20:49:20 <dmarlin> nirik: right, it is broken there as well
20:49:26 <nirik> livecd-creator, pungi
20:49:30 <jonmasters> nirik: yea, but we've been told lmc is the way of the future, etc.
20:49:53 <bconoboy> dgilmore?
20:49:57 <dmarlin> so we have not ported livecd-creator to arm (nor do we make ISO images)
20:50:21 <dgilmore> right now pungi and anaconda are not installable
20:50:26 <bconoboy> does anybody (dgilmore? nirik?) happen to know what the plan in Primary is for f19 alpha/beta/ga?
20:50:27 <fossjon> we should copy what primary does as much as possible i think
20:50:29 <nirik> there's also oz...
20:50:43 <dgilmore> bconoboy: plan as far as what
20:50:50 <dmarlin> fossjon: as do, as much as possible
20:50:54 <bconoboy> dgilmore: will the images be made with lmc or with livecd-creator?
20:50:55 <dgilmore> oz doesnt support anything but x86
20:51:09 <dgilmore> bconoboy: primary will use livecd-creator?
20:51:19 <dgilmore> at least at this point in time
20:51:25 <bconoboy> dgilmore: yes, that is my question
20:51:29 <dgilmore> and appliance-tools for images
20:51:29 * nirik wishes there wasn't all these different incompatible image creation tools. ;(
20:51:40 <dgilmore> nirik: indeed
20:51:42 <dmarlin> nirik: +1
20:51:57 <dgilmore> everyone does something different and they all think the other is wrong
20:52:08 <bconoboy> dgilmore: Okay, so what does that mean for us, should we dump lmc and move our energy into livecd-creator?
20:52:10 <nirik> yeah, it's a mess.
20:52:12 * dmarlin just wants one that works
20:52:14 <jonmasters> time and resource have gone into lmc, so unless that is not going to be in the longer term Fedora plan, I think we should stick with that
20:52:48 <bconoboy> If fedora 19 isn't going to be using lmc we shouldn't either
20:52:50 <jonmasters> who can take the action of finding out what the Fedora image creation plan *is* longer term? (or rather, reconfirming that plan)?
20:53:11 <jonmasters> bconoboy: older releases didn't either on PA if you recall, but they said they were going to move to lmc
20:53:22 <fossjon> i agree jonmasters we should aim for the same future tools primary is and not waste time perfecting old ones
20:53:26 <jonmasters> bconoboy: the right thing here, I think, is to find out what the plan is
20:53:38 <j_dulaney> jonmasters:  I can do that
20:53:41 <nirik> Last I saw, lmc wasn't going to be too viable for primary either, but I don't know if anything has changed.
20:54:03 <bconoboy> If lmc is the future in the sense that it will be stable by Fedora 25 we need to do something else now.
20:54:15 <dmarlin> bconoboy: but what?
20:54:31 <dmarlin> bconoboy: make CDs?   :-/
20:54:34 <bconoboy> dmarlin: Sounds like livecd-creator since that is what they're doing.
20:54:53 <dmarlin> bconoboy: but they boot CD/DVD media (live images)
20:55:00 <ctyler> make CDs and post-process into images (ugg)
20:55:03 <bconoboy> dmarlin: Does it not provide the features we need?
20:55:25 <dmarlin> bconoboy: not as far as I know, but I have not really investigated it fully
20:55:31 <jonmasters> let's not get into wild speculation and change course yet. Let's have j_dulaney go find out before next week what PA will be doing longer term and meanwhile we'll assume we're still on lmc
20:55:39 <dmarlin> +1
20:55:42 <dgilmore> bconoboy: its a mess and i dont know whats best
20:55:54 * j_dulaney will bring it up at next FESCo meeting
20:55:54 <fossjon> its really the ISOs that they make which can be put onto USB keys and not so much CDs
20:55:57 <bconoboy> dgilmore: Hm. Okay. We're doomed.
20:56:00 * j_dulaney files a ticket to that end right now
20:56:01 <dgilmore> bconoboy: appliance-tools would be more appropriate i think that livecd-creator
20:56:03 <jonmasters> #action j_dulaney to find out what the plan is for Primary Architecture for using Live Media Creator (LMC) vs. other tools and the longer term strategy
20:56:25 <fossjon> we should copy their ISO generation process and change it a bit for ARM
20:56:36 <dgilmore> jonmasters: no one knows what primary will be doing longer term
20:56:49 <dgilmore> jonmasters: there is efforts to move to oz
20:56:52 <dmarlin> dgilmore: that is not terribly reassuring
20:56:58 <dgilmore> but right now thats not been fruitful
20:57:02 <bconoboy> I'm really only concerned with F19 here.  Even if "the plan" is to move to lmc by F20, that plan could change
20:57:24 <dgilmore> right now until its clear what to do primary is staying put
20:57:28 <dgilmore> and arm should do the same
20:57:30 <bconoboy> The alternative seems to be using F18's lmc and dealing with the unreliability issues as best we can
20:57:34 * j_dulaney tries to creat a non-iso with livecd-creator
20:57:49 <bconoboy> dgilmore: By stay put do you mean stay on lmc?
20:57:51 * j_dulaney has only created isos with it
20:58:20 <dmarlin> j_dulaney: are you trying on an arm system?
20:58:24 <jonmasters> bconoboy: the older tools have no ARM support whatsoever
20:58:42 <dgilmore> bconoboy: yes
20:58:43 <bconoboy> jonmasters: The new tools have no support at all as they're broken everywhere
20:58:44 <jonmasters> bconoboy: I'm afraid I need to agree with Dennis here, we should default to sticking with lmc and figuring something out if possible
20:59:02 <dgilmore> j_dulaney: livecd-creator only creates isos
20:59:14 <dgilmore> j_dulaney: we use appliance-tools to make the disk images for ec2
20:59:16 <bconoboy> Okay, so stick with lmc- are we considering an f18 lmc backup plan then?
20:59:32 <dgilmore> the only tooling with any arm support at all is lmc
20:59:38 <jonmasters> the amount of work to fix one might well equal the amount to switch to the other+make it useful for ARM by post-processing the ISOs into something useful
20:59:39 <dgilmore> bconoboy: no
20:59:49 <dgilmore> bconoboy: we use f19 to create f19
20:59:54 <dgilmore> end of story
21:00:06 <j_dulaney> dmarlin:  Right now, the chromebook is not usable due to broken kernel
21:00:08 <dgilmore> we use lmc or we port appliance-tools
21:00:10 <jonmasters> dgilmore: this is true, however for alpha maybe we could reconsider that
21:00:20 <dgilmore> until suck a paoint that something else replaces them all
21:00:21 <bconoboy> well, there it is then- who is going to do this?
21:00:26 <dgilmore> jonmasters: no
21:00:32 <dgilmore> jonmasters: this is non optional
21:00:57 <jonmasters> dgilmore: well, it has been optional in the past. I understand your feelings on the matter. We'll try to get LMC fixed asap.
21:01:09 <dgilmore> jonmasters: it wasnt optiona;
21:01:12 <dgilmore> optional
21:01:22 <dgilmore> jonmasters: and ive stated over and over that fact
21:01:43 <dgilmore> i didnt make the f18 images, and i regret not doing so
21:02:04 <dgilmore> because for 1 i have no idea how they were made and 2 they are not reproducable
21:02:23 <dgilmore> jonmasters: its never been optional
21:02:25 <fossjon> dgilmore dont we publish the kickstart files so it can be reproduced?
21:02:49 <dgilmore> fossjon: ive no idea where they are because they are not upstream in spins-kickstarts
21:02:54 <dgilmore> fossjon: so no its not
21:03:08 <bconoboy> dgilmore: We can provide the kickstarts if you need them
21:03:31 <bconoboy> Anyway, that is water under the bridge
21:03:34 <dgilmore> bconoboy: right now im doing things one step at a time
21:03:43 <dgilmore> and step one is to make a install tree
21:03:51 <bconoboy> Right, so, the plan is:
21:03:52 <dgilmore> which i cant do because i cant install anaconda
21:03:54 <bconoboy> 1: Get lmc working
21:04:11 <bconoboy> 2. If lmc is unworkable, we port appliance-tools
21:04:13 <bconoboy> right?
21:04:16 <dgilmore> bconoboy: step one for lmc working is have anaconda installable
21:04:24 <dgilmore> bconoboy: sure
21:04:31 <bconoboy> dgilmore: Let's assume the anaconda issue is resolved
21:04:40 <bconoboy> I think it will be in the next day or two.
21:04:49 <dgilmore> assuming we can install anaconda
21:04:50 <jonmasters> ok, I think we know what the problem is and what needs to be done. So, shall we push forward on this plan and sync up on it in a few days?
21:04:56 <dgilmore> we then make install trees
21:05:15 <dgilmore> and we do one of two things, port appliance-tools or get lmc tow ork
21:05:17 <bconoboy> dgilmore: Will you be doing all the releng for f19 image creation, installer and sdcard images?
21:05:36 <dgilmore> bconoboy: we get the snipets for kickstarts into spins-kickstarts
21:05:50 <dgilmore> bconoboy: i will be doing all of f19
21:06:22 <bconoboy> dgilmore: Assuming somebody else handles the lmc side, is there anything you're expecting from any of us that will be needed to create f19 alpha, beta, ga?
21:06:31 <dgilmore> bconoboy: because of the past issues im not going to accept something for release ive not composed.  but people are welcome to follow at hope and help fix things
21:06:32 <bconoboy> (lmc side= fixing lmc so it works)
21:06:40 <ctyler> dgilmore: is that raptor-bus proof?
21:07:02 <dgilmore> ctyler: yes, peter will know how to do it all also
21:07:52 <dgilmore> bconoboy: we need to be able to make things, then we can test and see whats needed
21:08:02 <dgilmore> right now there is too many unknowns
21:08:08 <bconoboy> dgilmore: fair enough
21:08:20 <ctyler> spread the love and knowledge, we'll employ the same techniques here for rpfr if they're best practice
21:08:30 <bconoboy> #info live media creator will hopefully be used for f19 image creation
21:08:54 <bconoboy> #info backup plan is to port arm support into appliance-creator
21:09:36 <bconoboy> we set with this topic for now?
21:10:09 <pwhalen> #topic 5) Open Floor
21:10:23 <bconoboy> I have one
21:10:31 <bconoboy> aarch64 config.guess/config.sub bugzillas
21:10:34 <nirik> I had some phx2 notes real quick or we could do that some other time or in other channel. ;)
21:10:46 <bconoboy> Initial response rate was good but I've not seen much in the last week
21:10:53 * j_dulaney has a couple of quick notes, as well
21:10:55 <bconoboy> Is it time to press the issue again?
21:11:07 <bconoboy> Really want to see as much as possible done in f19
21:11:24 <nirik> bconoboy: perhaps you could draft a devel-announce email about it?
21:11:33 <nirik> ie, explain that it's wanted for f19, please do it?
21:11:41 <bconoboy> -announce?
21:11:52 <dgilmore> ive only had one perosn violently object
21:11:55 <j_dulaney> bconoboy:  Alpha freeze has passed
21:11:56 <jonmasters> devel-announce
21:12:06 <jonmasters> bconoboy: all developers are on that list by default
21:12:10 <bconoboy> is announce the right forum?
21:12:10 <nirik> devel-announce... maintainers are supposed to be subscribed. ;)
21:12:25 <bconoboy> Hm. Okay.
21:12:30 <jonmasters> well, you draft, we review, we decide on the venue
21:12:35 <j_dulaney> So, not too much more is likely to make it into F19 Alpha without a freeze exception, and that won't happen for aarch64
21:12:35 <bconoboy> Who wants to preview the draft?
21:12:36 <dgilmore> devel-announce should get to all maintainers
21:12:42 <dgilmore> bconoboy: yes
21:13:15 <dgilmore> nirik: what do you have?
21:13:36 <bconoboy> I will draft a message- contact me privately if you'd like to review before it goes out.
21:13:38 <nirik> just wanted to say we got all the other phx2 SOC's installed and up (aside from a few with disk issues)
21:13:39 <ctyler> j_dulaney: so they make it on devel/rawhide branch, at least there's forward progress
21:13:55 <nirik> we will be moving the ones we were using to their proper final net soon and reinstalling them.
21:14:06 <bconoboy> #action bconoboy to draft message to devel-announce requesting aarch64 config.guess/sub support go into f19
21:14:18 <dgilmore> nirik: woohoo
21:14:20 <nirik> and we have some setup to talk to primary koji doing housekeeping stuff until they are allowed to do builds. ;)
21:14:31 <bconoboy> nirik: sweet
21:14:57 <dgilmore> http://koji.fedoraproject.org/koji/hosts
21:15:03 <nirik> so, we are looking good there finally. Sorry for all the delays. ;)
21:15:03 <bconoboy> nirik: is there any way we could make arm 1.5ary- IE, builds get kicked off for arm with x86, but results for arm don't matter?
21:15:15 <nirik> not that I know of... dgilmore ?
21:15:24 <dgilmore> bconoboy: koji doesnt work like that
21:15:32 <dgilmore> its all or nothing
21:15:33 <bconoboy> dgilmore: Yes, but could it?
21:15:46 <dgilmore> bconoboy: no, that violates how koji is designed
21:15:54 <bconoboy> bummer. thanks.
21:16:06 <bconoboy> nirik: that is awesome news
21:16:13 <bconoboy> nirik: will there be scheduled downtime for koji-shadow then?
21:16:21 <j_dulaney> BTW, for those of you following along at home, FESCo #1106
21:16:30 <nirik> so, once the go ahead for primary happens, we can just flip a switch and mass rebuild. ;)
21:16:47 <nirik> bconoboy: I think it just needs to finish the current builds and we can move the builders.
21:16:57 <nirik> the new ones are in for the load.
21:17:04 <dgilmore> j_dulaney: that doesnt need to go to fesco
21:17:28 <j_dulaney> dgilmore:  I thought that was where such decisions originated
21:17:34 <dgilmore> j_dulaney: not at all
21:17:45 <j_dulaney> Oops
21:17:50 <dgilmore> j_dulaney: fesco has had zero say and input into how its been done
21:18:45 <pwhalen> we're in overtime now, anything else to add for today?
21:19:29 <pwhalen> #endmeeting