20:00:47 #startmeeting 20:00:47 Meeting started Wed Jun 20 20:00:47 2012 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:47 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:47 #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore 20:00:47 Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen 20:00:50 * jonmasters is in 20:00:55 * maxam is in 20:00:56 * pwhalen is here 20:01:01 hi hi 20:01:03 .fas pwhalen 20:01:03 pwhalen: pwhalen 'Paul Whalen' 20:01:09 .fas maxam 20:01:09 maxam: maxamaxim '' - maxamillion 'Adam Miller' 20:01:30 .fas blc@ 20:01:31 bconoboy: blc '' 20:01:32 thats not right :) 20:01:43 * masta looks in 20:01:46 * Frojoe is here 20:02:04 .fas dmarlin 20:02:05 dmarlin: dmarlin 'David A. Marlin' 20:02:22 #topic 1) Cleaning up the wiki - moving dated items to an archive section. - refreshing where needed 20:02:46 .fas jcm 20:02:46 jonmasters: jcmoore 'Curt Moore' - jcmartin 'James C Martin' - jcmoralesc 'Juan Morales' - nagarajcm 'Nagaraj' - jcmontero 'Juan Carlos Montero' - jcmannam 'MANNAM JAYACHAND' - jcmex '' - jcmcderacg 'James McDermott' - jmasters 'Jon Masters' (1 more message) 20:03:01 lol wow 20:03:07 way to out do us 20:03:11 :) 20:03:32 maxam and I have been adding how to sections for each of hardware/qemu images, but there that needs to be refreshed 20:03:34 pwhalen: Love the per-board pages you've been setting up, would like to see more 20:03:41 bconoboy: +1 20:03:49 qemu will be posted shortly as well 20:03:51 they're awesome, as is the kirkwood one maxam did! 20:04:05 we also need to clean up dated material. Is there a standard procedure for deprecating old pages? 20:04:07 thank you! thank you! 20:04:21 #info https://fedoraproject.org/wiki/Architectures/ARM 20:04:34 what I love? These look exactly like I had in my mind when I described what I wanted...Paul is a mind reader :) 20:04:51 .fas jcapik 20:04:51 jcapik: jcapik 'Jaromír Cápík' 20:04:55 that page is awesome 20:05:16 pwhalen: however, perhaps more highlighting on the info download box top right 20:05:28 Perhaps we should just go through all the pages that are irrelevant, delete the content, and include a pointer to the main page? 20:05:35 pwhalen: perhaps put it in a box? (if the wiki markup can handle that) 20:05:48 nice work pwhalen 20:05:48 bconoboy: just unlink defunct pages 20:05:52 bconoboy, I was thinking exactly that, a link for all archived content 20:05:54 jonmasters: We need a better icon for it, didn't find one when looking at fedora artwork 20:06:10 ah ok 20:06:30 jonmasters: Can you unlink defunct pages? I'm thinking about search results, etc. 20:06:40 I've found that people often skip those 'highlighted' boxes, so something more attention grabbing would be great 20:06:51 Even if we stop pointing to them, we still need to update them to point elsewhere 20:06:57 bconoboy: oh, good point 20:07:24 * djdelorie is here 20:07:48 If there is some standard Depricated logo we can put on top of these old pages that would be a great start. 20:08:11 Basically have a big attention getting "Don't read this unless you're an archaeologist" and a pointer to the main page 20:08:24 suggest also moving older releases off the main page, less choice, less confusion - ie F13 20:08:58 we should have the last stable version then the latest version then a beta version 20:09:03 like they do with freebsd links 20:09:04 copy old contents to new pages (named accordingly) and then adding a catagoru called Archive maybe? 20:09:15 3 tables with each boards image 20:09:16 pwhalen: I like that idea. Perhaps the thing to do is have only F17 on the main page, then a Release Legacy page for everything that is outside Fedora support window. 20:09:39 let's just put a message at the top of the page. I think there's a macro for it 20:10:04 most wikis have markup to mark a page as such, I'm pretty sure ours does, but I don't know what it is 20:10:27 #idea Only list currently supported Fedora releases on the main ARM page 20:10:29 something like this possibly http://www.freebsd.org/where.html 20:10:37 pwhalen: once we have BZs for every open issue, let's make the "Known Issues" be links to those BZs 20:10:48 jonmasters, agreed 20:11:16 #idea Make a BZ for each known F17 issue, link to the BZ on the GA release page 20:11:50 http://fedoraproject.org/wiki/Architectures/ARM/CrossToolchain <- not sure if that stop the page from appearing in searches 20:12:49 pwhalen: That's almost what I had in mind, would like there to be a stronger link to the main page 20:14:36 I've seen the depreciated wiki mark up somewhere, I'll keep looking for it.. 20:14:43 We can track it down later 20:14:49 was there anything else we want added it to the main page? 20:14:51 Does anybody object to us removing old content? 20:14:59 so im just ignored eh? 20:15:09 :))))))))))) 20:15:36 fossjon: not sure following what freebsd is doing is quite the thing fedora arm should do since we want to be following in the steps of primary 20:16:05 anything we wanted to talk about re:our wiki? 20:16:14 hey folks, would it be possible to host hte kernel configs for the boards are supporting on the wiki... to suppliment the page about building the ARM kernel? 20:16:35 or a link to where to find the configs? 20:16:45 bconoboy: note, on removing content, edits are preserved so if a page is marked deprecated (preferred by me) then the old stuff is still there anyway 20:16:52 masta: Ah, that's a good question because it begs the question: Shoudl we have a page about building kernels? I'm thinking this is legacy info. 20:16:55 bconoboy: even if you wipe out the content on a page, old edits are still there 20:17:26 bconoboy: agree, it is legacy 20:17:30 I think building a kernel is generally like building any Fedora kernel, nice to get to that (and how uImages work, etc.) but not as big a priority as the getting started stuff 20:17:37 jonmasters: Right, I don't want to kill the content forever, I just want a couple hoops to be in the way of getting to it so people are sure to understand it's dated material. 20:17:40 jonmasters, do those come up in searches? 20:18:54 #topic 2) On to F18 - How do we be more like PA? - Focus on Anaconda, livemedia-creator - linker path 20:19:07 linker path changes are in rawhide 20:19:10 The one thing that might be nice to add is how to take your own kernel and use the Fedora 17 rootfs tarball with it. 20:19:12 pwhalen: not on the wiki, in Google probably but I think it handles that 20:19:22 pwhalen: I think Google knows about wikis, etc. 20:19:57 Okay, topic 2... 20:20:00 right, dmarlin has been looking at installer stuff and I think will get to Anaconda/Lorax some more in F18 in a bit 20:20:29 Linker path: We should take care of this right away. What is our plan? 20:20:39 bconoboy: agreed, and that is exactly what i am wanting to do :-) 20:21:00 bconoboy: re: your own kernel and use rootfs image 20:21:49 masta: if you document the steps you take on the wiki that would be a good start 20:21:56 bconoboy: the linker path change is in F18 20:21:56 jonmasters: linker path? 20:22:11 bconoboy: so you mean about F17 cleanup? 20:22:13 jonmasters: To what extent? Does gcc use it? 20:22:23 note: bootstrapping requires the symlink, else the ld-linux.so path on disk doesn't match the ld-linux.so path in the binaries 20:22:29 in F17 20:22:37 bconoboy: would "how to take your own kernel and use the Fedora 17 rootfs tarball" be on a per-board basis, since creating the u-boot images, partitioning, bootloader, ect. are still pretty board specific 20:22:37 bconoboy: dgilmore got it in, pwhalen did a readelf for me and said it looked like it was there 20:22:44 Do executables generated during a rawhide build use it? 20:22:51 bconoboy: yes 20:23:16 Do executables generated in f17 still work? 20:23:35 in my F17 bootstrap stuff, glibc installs ld-linux-armhf.so.3 20:23:45 dmarlin: I think one page on the generic ARM kernel build stuff (like what a uImage is) and then links on the per-board pages under "Developer" around kernel specifics 20:23:57 I probably don't have the gcc magic to change the strings yet, a symlink ld-linux.so.3 -> ld-linux-armhf.so.3 makes everything work 20:23:58 rpm -qp --requires armhfp/uboot-tools-2012.04.01-2.fc18.armv7hl.rpm |grep ld 20:24:01 ld-linux-armhf.so.3 20:24:03 ld-linux-armhf.so.3(GLIBC_2.4) 20:24:12 great 20:24:16 note for the record, djdelorie is talking about something else, which is useful but let's make sure we're clear it's not about this issue 20:24:23 * djdelorie is talking about F17 20:24:25 So, we want to backport this into F17, yes? 20:24:34 bconoboy: no 20:24:37 yes and no 20:24:44 it would be nice, but I think we should focus on F18 20:24:50 but I'm running the stage 1/2 bootstrap scripts, so might not exactly match the specs 20:25:03 let's not just screw with F17 for the moment - give it a week or two to settle down then let's think about it 20:25:09 jonmasters: What part yes vs what part no? 20:25:18 ~/wg 20 20:25:21 :( 20:25:44 bconoboy: I think we keep moving with F18 and then we come back to it. Leave it as a meeting topic each week for now 20:26:19 jonmasters: Er, what's the point in that? If we aren't going to make any progress on it this week why would next be different? 20:26:33 either we're punting for 6 months or we aren't. 20:26:43 i think we can look at it in a month 20:26:48 I don't think it's binary 20:26:51 I agree with dgilmore 20:26:51 * djdelorie wonders if people building FSF gcc/glibc on F17 will run into problems... 20:27:03 what happens in a month? 20:27:19 ...but at least the fix is a simple symlink if they do 20:27:20 bconoboy: decide if we pull it in or not 20:27:21 we've calmed down on people downloading and installing F17 20:27:33 djdelorie: its not as simple as a symlink 20:27:36 I'd rather not run the risk of breaking something the day after the release 20:27:49 if it were just a symlink, ok, but it also requires a linker patch 20:27:49 dgilmore: it was for me 20:27:53 dgilmore: No, I mean what metric is it taht needs a month's time to measure? 20:28:04 djdelorie: it was for you because you're bootstrapping from scratch 20:28:41 bconoboy: if we do it today, we run the risk of breaking F17 as people are downloading it, the day after we released. If we wait a month for horrible stories from F18, or good stories, and for things to calm down, that is better 20:28:50 yes, and the linker defaulted to the wrong loader, a symlink made the default loader available. Anyone buidling from FSF may have the same problem 20:28:51 bconoboy: demand from users. some rawhide testing to ensure no fall out 20:29:09 dgilmore: +1 20:29:18 dgilmore: So you're proposing that we revisit this question in 4 weeks? 20:29:21 yes 20:29:24 yes 20:29:38 And in 4 weeks, if it hasn't casued problems in F18, we will pull it in? 20:29:45 if it makes sense then 20:29:53 with a final decision then to either leave f17 as is for its life or make the change 20:30:00 dgilmore: +1 again :) 20:30:19 jonmasters: You're sounding like fesco. What would make it make sense? Either there are concrete plans or we're just kicking a can down the road. 20:31:01 IE, why would it make sense i n4 weeks, or not make sense in 4 weeks? 20:31:13 would the symlink be handled by the alternatives symlink thing? 20:31:26 masta: it's a glibc patch that's at issue 20:32:00 bconoboy: ? in my case glibc has the "new" name, it's the linker that's behind 20:32:03 its 3 patches to glibc 20:32:29 unless the dynstring inside each elf binary comes from glibc? 20:32:40 bconoboy: I'm not trying to sound like FESCo. I'm saying that I absolutely object to doing it today, right after the release. It sounds like a reasonable thing to do in an F17 update if our tools guys are comfortable, but stuff can happen in a month so I think we should discuss it then, not decide now arbitrarily that we will or will not take some action in one month 20:32:42 djdelorie: The glibc in F17 GA is from F17 GA, you're probably using an update 20:32:48 2 of which are upstream and one is a hack to allow things to continue to work 20:33:13 glibc-2.15-37.fc17.src.rpm 20:33:19 I lean toward doing it in one month from now, if things haven't blown up in the meantime 20:33:45 I agree on "decide later" regardless of my other ramblings here about it ;-) 20:33:47 What I"m looking for is in 4 weeks, if the patch has caused no trouble, we decide today to pull it in then. If it has caused trouble, we reevaluate. 20:33:56 #idea Punt on the linker path update for one month. If things haven't blown up in the interim in F18, plan on an F17 update with the tested changes. 20:34:09 bconoboy: funny, I was just writing that :) 20:34:25 jonmasters: Okay, works for me. 20:34:40 cool 20:34:41 djdelorie: the 2 patches to change the linker path were in fedora glibc for a bit but they did not get activated 20:34:57 what are the risks of this stuff in a month, are the rewards worth the risks? 20:35:04 more to the point, this stuff already blew up for Ubuntu once, let's just be sure it's ok :) 20:35:06 djdelorie: i believe if you rebuild glibc from release with newer gcc it will change 20:35:18 all the patches have been removed from glibc 20:35:28 gcc-4.7.0-5.fc17.src.rpm 20:35:31 * jonmasters suggests the next topic 20:35:37 yep 20:35:38 I'm building F17 GA's gcc and glibc 20:35:45 other things to be more like PA, we should take to email 20:35:46 #topic 3) F18 build status - problem packages? 20:35:54 pwhalen: wait 20:36:19 pwhalen: we did not discus livemedia-creator or anaconda 20:36:25 #undo 20:36:25 Removing item from minutes: 20:36:43 dgilmore: er, I noted that dmarlin is going to look at this 20:37:11 the patches for lorax should go into upstream today or tomorrow 20:37:13 dgilmore and I have been looking at it 20:37:19 I think we know the course for that. David has code for F17 that isn't ready for upstream quite yet, but we can rework things in F18 20:37:37 jonmasters: shut up please 20:38:50 anaconda is in a place where the existing patches you can get a working install only by using a kickstart as there is currently no u-boot support in the anaconda patches at all 20:39:08 ive started working on adding u-boot support 20:39:57 so right now u-boot steps in the %pre/%post sections ? 20:40:02 ok, question. What is the intended support target for Anaconda installs in F18? To me, it's not every platform if you're talking of non-ks installs 20:40:15 there is going to need to be some livemedia-creator work to fix a few issues that have been notice when run in non virt install mode. 20:40:23 masta: yes 20:40:31 guidance from fesco is that anywhere kickstart can be sensibly used it must be used 20:40:36 jonmasters: anaconda is used by lorax in livemedia-creator, so some bits of it will be used 20:40:51 jonmasters: just to created images 20:40:52 er s/kickstart/anaconda/ 20:40:54 dmarlin: sure, but I think dgilmore is talking about non-ks regular installs 20:41:05 jonmasters: all platforms will have anaconda support 20:41:10 * dmarlin thought it was all installs 20:41:32 all *supported* platforms 20:41:45 jonmasters: we should be able to do a anaconda install on any of the targets and have it work 20:41:56 dgilmore: that's not quite what I was asking. Are we seriously intending to have a fullblown Anaconda running on a PandaBoard? 20:42:01 assuming we have display/mouse/keyboard supported 20:42:06 "Where technically possible, all supported hardware targets must be capable of installation using Anaconda. Exceptions are limited to highly resource constrained devices or hardware which provides no means for install and target media to be simultaneously accessible. " 20:42:09 djdelorie: not needed 20:42:24 To me that means anything but a raspberry pi. 20:42:41 jonmasters: the code will be there to support a panda board install. 20:42:46 what is "anaconda" then, if it's not kickstart and there's no display? 20:43:04 jonmasters: but to have it realistically work you would only be able to network boot the installer 20:43:05 ok, that's interesting. I was thinking sure highbank, maybe TS (because it comes with lots of storage options including an SSD) but the usual mode for e.g. a Panda is to just create an SD Card 20:43:10 Or at very least anything with more than 1 attached storage device 20:43:15 we are talking text mode anaconda, right? We are supporting boards with limited memory 20:43:26 djdelorie: a VNC based install for example 20:43:39 djdelorie: you can do minimal install with default setup via serial console, and there is always vnc for installing interactively 20:43:50 * djdelorie thinks we need to be careful how we define "installation using anaconda" then 20:44:06 djdelorie: that was my point. Let's define what targets are doing what 20:44:37 jonmasters: i dont expect that many people would actually do a pandaboard install. but you could. simplest way will be a image onto a sdcard 20:44:52 dgilmore: that's fair enough, it's just not quite what I expected 20:44:55 dgilmore: What's this about sending patches upstream today/tomorrow? 20:45:04 bconoboy: for Lorax 20:45:10 jonmasters: well to make image creation work, anaconda has to work 20:45:29 jonmasters: if we test and support it is another thing 20:45:34 dgilmore: ah, sorry, my question was more around what the supported/tested options would be. 20:45:39 dgilmore: ah, yea, exactly 20:45:52 bconoboy: lorax patches got acked upstream, they just need to pull it in now 20:46:09 just a reminder that we have local test versions of anaconda and lorax available, for those interested in seeing what we're talking about: 20:46:11 http://fedoraproject.org/wiki/Architectures/ARM/Installer 20:46:37 this is tested on trimslice and highbank 20:46:46 assistance to help with testing and writing arm support in anaconda is very welcome 20:46:52 dgilmore is working on getting it to build a panda image 20:47:59 I should try out an Efika install :) 20:48:12 jonmasters: should work 20:48:14 an iMX would be a fun install target 20:48:15 (OMAP is tricky due to the MLO/u-boot requirements) 20:48:38 omap is the oddest of the platforms 20:48:52 dgilmore likes a challenge. :) 20:49:07 #idea The goal is to have Anaconda support every platform (in part because it's needed for making images), the level of support will be at least kickstart, but interactive/VNC installs should work too (though may not be tested) 20:49:40 is that the right summary? 20:49:53 what im doing is making a 20mb vfat partition at the start putting MLO and u-boot.img on it and writing a uEnv.txt file that will load a kernel and initrd from the ext3 /boot partition 20:49:59 +1 20:50:08 jonmasters: yes 20:50:20 dgilmore: did you manage to figure out something with MLO making fat16 partitions? 20:50:27 jonmasters: +1 20:50:39 jonmasters: well im looking at two options there 20:50:50 jonmasters: do we have a plan for transitioning nightly images to use livemedia-creator? 20:51:15 one is to make anaconda ensure that the partition is fat32 the other is changing the checking in the MLO 20:51:17 I suggest F18 images be based on livemedia-creator. 20:51:31 Then we can let F17 image creation taper down to nilll. 20:51:35 bconoboy: they will be 20:51:44 dgilmore: Sounds like a plan ;-) 20:51:57 * dgilmore notes for primary installer, lives etc are not made until branching 20:52:10 for rawhide that is 20:52:16 rawhide is never installable 20:52:22 that may change 20:52:40 dgilmore: Are you saying you wouldn't want to make a "nightly" sort of F18 image prior to branching? 20:52:42 we have a shortish time frame to make sure everything works 20:52:56 or just advising what the standard is? 20:52:59 bconoboy: I think the problem is that it would almost certainly not work 20:53:02 bconoboy: saying we dont for primary so its not necessary for arm 20:53:20 * jonmasters has done many a rawhide install, it's luck of the draw 20:53:23 we should be testing the tooling as its worked on 20:53:39 making nightlies with the tooling is a good test 20:53:41 bconoboy: what im saying is we have a deadline of branching to make it work 20:53:47 okay 20:53:55 so what are you proposing we do? 20:54:21 bconoboy: that people help with developing and testing the tooling 20:54:45 dgilmore: Is there a wiki page for doing so? 20:54:47 bconoboy: if that be that once we are sure its working we start making nightlies for testing so be it 20:54:59 http://fedoraproject.org/wiki/Architectures/ARM/Installer 20:55:17 and the list or irc 20:55:42 #info http://fedoraproject.org/wiki/Architectures/ARM/Installer 20:55:51 #link http://fedoraproject.org/wiki/Architectures/ARM/Installer 20:55:58 tnx 20:56:34 dgilmore: I think there will be a lot of interest in trying out the installer path so if we can make it relatively easy to get started that will help get feedback 20:56:41 #info We have a deadline of F-18 branching to ensure that anaconda is in a functional state and that we can use livemedia-creator to make images. 20:57:08 when is F18 branching...checking schedule 20:57:33 http://fedoraproject.org/wiki/Releases/18/Schedule 20:57:41 Aug 7 20:57:47 #info anyone wishing to help work on anaconda, lorax, pungi, and release engineering tools welcome. please communicate via arm@lists.fedoraproject.org 20:58:14 #info Fedora 18 branching is 7th August 2012 20:58:18 So we have 6 weeks 20:58:29 #idea let's run over the 1 hour notional time for this meeting, don't think anyone needs #fedora-meeting-1 20:58:41 jonmasters: sure 20:58:42 bconoboy: it would seem so 20:59:10 dgilmore: ready for next topic? 20:59:11 * dgilmore needs to add livemedia-creator support to koji before then also 20:59:12 safe to move on? 20:59:16 pwhalen: yep 20:59:23 #topic 3) F18 build status - problem packages? 20:59:41 On packages, I'll have an openmpi atomics fix next week (if not before, focused on Summit right now) 20:59:57 There's 1000+ msising builds. Who knows why? 21:00:04 jonmasters: we often run over ... wouldn't it be a good idea to make a permanent reservation for 1.5 hours? 21:00:04 there will be a mass rebuild in a few week 21:00:06 weeks 21:00:10 jcapik: sure 21:00:29 dgilmore: Is it ftbfs on a dep that's killing us? 21:00:45 bconoboy: im currently not 100% sure 21:00:56 If we're doing a mass rebuild we need to get our builders in top shape. 21:01:06 bconoboy: yes, and yes 21:01:26 Uh, we'll come on to that in a few 21:01:27 bconoboy: note however we do not need to move builders off F15 21:01:40 I think in the absence of pbrobinson we're not going to have much to talk about wrt problem packages. 21:01:41 do we want to petition FESCO to be more strict with FTBFS packages in PA ? 21:01:42 #link https://fedorahosted.org/rel-eng/ticket/5222 21:01:50 #info request for mass rebuild 21:01:51 jonmasters: sh. 21:02:39 proposed start of mass rebuild is 30th July 2012 21:02:53 jonmasters: I think we need to do something to stabilize our F15 builders... still encounter regular failures 21:03:01 If we start july 30 we won't be done before F18 branches. 21:03:30 koji-1.7.0 is not supported on fedora 15 though it should work fine 21:03:37 So it's really important that our arm specific changes are in before July 30, not before aug 7 21:04:01 the koji update does have all the necessary arm support patches in 21:04:03 pwhalen: Whatever next topic is planned, can we move to F17 Koji builders? 21:04:10 jcapik: I updated the meeting schedule, this room is now reserved for 2 hours 21:04:28 jonmasters: good :] 21:04:35 #topic 4) Upgrading builders to F17 21:04:48 bconoboy: for features needing mass rebuild like linker yes 21:04:54 bconoboy: I think it would be nice to at least set up a couple of "test" builders using our F17 GA 21:04:57 bconoboy: others can come in later 21:05:01 F17 Builders: I'm for it. 21:05:13 When we last talked about it we resolved the following: 21:05:17 1. Wait for F17 GA 21:05:28 2. Prepare a test set of builders and see how they fare. 21:05:30 dmarlin: +1 21:05:41 We've passed #1, which leads us to #2. 21:05:43 bconoboy: yea, as long as it's tested with a small number, it's ok 21:06:13 one panda v7hl, one trimslice v7hl, and ? 21:06:20 We can do it with RH machines, or Seneca machines, either way is fine 21:06:26 we should have some v5tel in there 21:06:28 please more than 1. 21:06:40 panda v5tel? 21:06:52 I'd suggest we ahve at least 2 of each class of system and each ABI move to F17. 21:07:05 so 4 pandas, 4 trimslices, etc 21:07:12 ... subject to availability. 21:07:16 cool 21:07:22 bconoboy: that's about all of them. :-/ 21:07:29 :D 21:07:32 (in hsv) 21:07:40 bconoboy: 1 of each to test we dont have huge numbers of any of them 21:07:43 dmarlin: That's okay, seneca has their whole build farm still at F15. 21:08:05 dgilmore: You get bad data from 1 of each. If there is an issue you can't tell if it's the board or the OS. 21:08:14 how do we test these? probably not on live builds (in case there are incompatibilities) 21:09:00 dgilmore: is there a way to setup a special koji channel for testing? 21:09:15 jonmasters: +1 21:09:15 jonmasters: we could but its a lot of work 21:09:19 dgilmore: then somehow at build time (other than the channel config rules) make a scratch build go to a particular channel? 21:09:39 oh, I feared as much :) 21:09:55 Is anybody really expecting some collossal problem? You just watch tbe build logs (including koji log) for errors. 21:10:14 * dmarlin always expects collossal problems 21:10:14 bconoboy: +1 - I think that's easiest and hopefully giant problems are obvious quickly 21:10:31 when we moved primary from rhel5 to rhel6 i just rebuilt a few builders and put them in the mix 21:10:34 (that's why a small number of boards means not everything breaks) 21:10:41 It's not like we're going to deploy all 2x2x2x2 configs at once. You start one system. Then watch. Then another. and watch. 21:10:49 sure +1 21:11:18 +1 21:11:33 Everything is happening in a chroot. All we're really testing is whether the kernel is stable, the out of root rpm works, and if the koji rpms have the right patches in them (We needed custom on the f15 builders) 21:11:57 bconoboy: the patches are all in 1.7.0 21:12:01 ok, we can start the test in hsv with a trimslice, since we can build the image using livemedia-creator now. 21:12:06 bconoboy: you, sir, make a good point 21:12:20 dmarlin: that's an awesome idea 21:12:25 bconoboy: and that mock sets up things sanely 21:12:27 Okay, so, livemedia-creator images? 21:12:44 I was going to suggest the F17 GA but I'm completely flexible 21:12:45 if that one works well, after a few days we can add another and so on 21:13:04 dgilmore: comments? ^^^ 21:13:22 1 armv5tel, 1 armv7hl on day 1 and I'm +1 21:13:25 bconoboy: we have two options, ga and yum install what we need, or make images just for builders 21:13:54 dmarlin: im all for testing livemedia-creator images 21:14:03 dgilmore: Either is fine IMO. The only issue is if we have builders that don't have livemedia-creator support we'll have to wing it. 21:14:37 livemedia-creator has that positive dog food aspect to it. 21:14:38 it would be cool if they were livemedia-creator images 21:14:40 bconoboy: we need to write kickstarts for them all anyway 21:14:42 bconoboy: +1 21:14:54 good excuse to make sure that its done and works 21:15:00 yes 21:15:00 dgilmore: +1 21:15:37 sounds like a plan 21:16:05 log it and move on? 21:16:14 +1 21:16:16 who is doing what? 21:16:42 I will create the image (with input from dgilmore on the ks packages) and set it up in hsv 21:16:43 i guess dmarlin and I will work on the kickstarts and image creation 21:17:19 bconoboy: I'll need a victim builder (trimslice to repurpose) 21:17:44 #agreed dmarlin and dgilmore will create f17 koji builder images with livemedia-creator and do a limited deployment to test building packages in koji with f17 21:17:57 dmarlin: sure, we'll pick some systems 21:18:05 thanks 21:18:20 pwhalen: next! 21:18:20 #topic 5) Your topic here 21:18:42 Red Hat Summit 21:18:58 ? 21:19:12 ...is next week. We've got a few things planned. Suggestions for boards to have available on the Fedora stand? 21:19:27 pandaboard- show off xfce 21:19:36 rpi, if you can obtainium. 21:19:37 do we have F17 on rpi yet? 21:20:02 bconoboy: I may ask my neighbor if I get chance if we can beg and borrow one for a day or two 21:20:18 +1 on pandaboard w/xfce 21:20:34 * jcapik is still waiting for his own rpi :/ 21:20:34 so for that, I'll need to have a monitor. I have one, but we'll need to take it over 21:20:35 trimslice- neat metal box 21:20:54 jonmasters: I think there might be one available, we'll have to ask 21:20:55 bconoboy: IF we have a GUI 21:20:57 wish we had working framebuffer on smartbook and trimslice 21:21:25 smartbook would be good, just wave hands about what fedora release is on it 21:21:29 bconoboy: yea. In any case, I should hook up one of my Pandas to a display sooner or later - I do everything on the serial right now :) 21:21:59 jonmasters: ga kernel read the edid data just fine on one of my monitors 21:22:08 and i got 1440x900 21:22:14 dgilmore: well, we can also sell the TS as a wonderful little home server box :) 21:22:16 tested that libreoffice worked also 21:22:17 Panda by far is the most usable for a show, full desktop, very responsive 21:22:42 pwhalen: yea, agreed 21:22:55 pwhalen: plus it's the Fedora way to reward upstream and TI have done a good job 21:23:07 jonmasters: +1 21:23:20 ok, so we'll have omapdrm stuff, cool 21:23:29 anything else we should have there or do, or? 21:23:56 probably a beaglebone since you have plans there anyway. 21:23:59 pwhalen: just the resolution issue is still there 21:24:11 bconoboy will be here on Monday, so we can stage stuff at my apt on Mon/Tue and make sure it's all set 21:24:13 jonmasters: not strictly fedora, but how is OLPC? 21:24:26 dmarlin: Peter Robinson is bringing one of the tablets 21:24:33 cool 21:24:34 some xo-1.75s would be good 21:24:36 yea 21:24:44 yea, I can bring an XO 1.75 21:25:14 I'm not planning to bolt stuff down, we just hope we don't lose too much 21:25:31 Is anybody here besides jonmasters and myself going to be at the summit? 21:25:35 bconoboy: I guess we should check on making sure we have enough outlets of power. Worst case we just need a multi-way extension cord 21:26:12 jonmasters: The important thing is that if the convention center loses power, your demo can go on. 21:26:21 ;) 21:26:42 yea, I'm gonna do a pretty silly demo. Let's not spoil the surprise here, but it's going to be very fun 21:27:18 Any other topics? 21:27:23 I'd in general like to think about marketing or other events we should find funding for people to attend, so it's not just us RHers who go to these things 21:27:40 my RPi shipped yesterday :-) 21:27:50 For example, Chris was going to have some t-shirts made at some point, it'd be good to get that figured out, and perhaps some standard "kit" for people to take to shows 21:28:09 djdelorie: lucky boy :] 21:28:17 djdelorie: if you came down here to meet me and bconoboy for a drink/dinner, we could steal your rPi for demos and promise to return it 21:28:20 * masta is going to summit 21:28:25 masta: cool 21:28:40 right, like you'd give back an *arm* board :-) 21:28:50 Let's table the marketing/show discussion perhaps but pwhalen can you note this down for future? 21:29:02 pwhalen: I'd like to discuss ways to drive adoption/grow the community, etc. 21:29:28 jonmasters, noted and agreed. Hoping the wiki helps that, raspi as well 21:30:00 we have a raspi meet up here in toronto next week, would be nice to have someone there with Fedora stuff 21:30:02 pwhalen: I think so - let's build on that. I can justify a little funds for people to go to an event or two, and maybe give away a few rPis eventually, etc. 21:30:26 pwhalen: yea 21:31:07 anything else? 21:31:41 #endmeeting