20:00:10 <pwhalen>#startmeeting Fedora ARM weekly status meeting20: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 dgilmore20: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 * mastawaves20: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 meeting20:01:46 <pwhalen>#link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-03-27/fedora-meeting-1.2013-03-27-20.00.html20:02:10 * nirikis 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.o20: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_dulaneywaves20:04:40 <bconoboy> next?
20:04:48 <pwhalen>#topic 1) Problem Packages20: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-RedCloth20: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 investigation20: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 * jonmasterswonders 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 at20: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 reports20: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-RedCloth20: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 1920: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 * mastahas mk802 and the board from fudcon... gooseberry or whatever... is happy to test any time20: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_dulaneyalso has a gooseberry from FUDCon, but hasn't tried an upstream kernel on it20: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_dulaneywill give it a shot this evening, however20: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 * jonmasterslooked at the sunxi code earlier and it looked like it wanted to be multiplatform20: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 devices20: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>#undo20: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_dulaneythinks unified images may be something to go on the list for next time20: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 * dmarlinlikes multi-platform kernel, bootz, and one boot.scr to rule them all20: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_dulaneycan attest to installing bum kernels20: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_dulaneywill figure out how to break it20: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 * jonmastersagrees - Dennis has good ideas, agreed, bit of both20: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 supported20:42:31 <bconoboy>#info send all feedback to bconoboy or the arm list20: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 creation20: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 * mastawill drop everything and help here20: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_dulaneywonders if, absolutelly worse case, we can use yum20:48:52 <masta>nirik: LMC
20:49:05 * niriknotes primary is not using lmc20: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 * nirikwishes 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 * dmarlinjust wants one that works20: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_dulaneywill bring it up at next FESCo meeting20: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_dulaneyfiles a ticket to that end right now20: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 strategy20: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_dulaneytries to creat a non-iso with livecd-creator20:57:49 <bconoboy>dgilmore: By stay put do you mean stay on lmc?
20:57:51 * j_dulaneyhas only created isos with it20: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 creation21:08:54 <bconoboy>#info backup plan is to port arm support into appliance-creator21:09:36 <bconoboy> we set with this topic for now?
21:10:09 <pwhalen>#topic 5) Open Floor21: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_dulaneyhas a couple of quick notes, as well21: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 f1921: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