20:00:28 #startmeeting 20:00:28 Meeting started Wed Jun 6 20:00:28 2012 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:28 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:28 #chair pwhalen jonmasters bconoboy ctyler pbrobinson 20:00:28 Current chairs: bconoboy ctyler jonmasters pbrobinson pwhalen 20:00:34 .fas jcapik 20:00:35 jcapik: jcapik 'Jaromír Cápík' 20:00:39 * pwhalen pwhalen is here 20:00:43 * ctyler here 20:00:44 .fas blc 20:00:44 bconoboy: blckspder 'Antoni Sousa' - blc '' 20:00:54 .fas ctyler 20:00:55 ctyler: ctyler2621 'Christopher Tyler' - ctyler 'Chris Tyler' 20:01:08 2nd one ^ 20:01:17 .fas delorie 20:01:18 djdelorie: djdelorie 'DJ Delorie' 20:01:33 .fas pwhalen 20:01:33 pwhalen: pwhalen 'Paul Whalen' 20:02:23 #topic 1) F17 GA - What will be included? Items in our images not included in Fedora RPMS (grubby patches, re-sizer) - Identify known kernel issues prior to GA 20:03:18 * Frojoe is here 20:03:22 I'd like F17 GA to look like the beta, but include panda and highbank images- at a minimum. 20:03:38 (er, also include) 20:03:42 * maxam is here 20:04:30 There are two things in the F17 beta images that are not packaged in RPM format: 20:05:01 1. There are some changes to grubby that handle the uImage load addresses that aren't known to stock grubby 20:05:01 What pieces are in the images that are not packaged? 20:05:21 2. The rootfs resizer script and its systemd file are not in a package. 20:05:49 Are the patches for (1) acceptable to the packager? 20:06:40 They haven't been submitted, but are simple enough: They add a variable one can define in /etc/sysconfig/uboot to specifically set the load address. 20:07:59 What about uboot/xloader/MLO/...? 20:08:14 the uboot and MLO for beagle and panda come from fedora packages. no issues. 20:08:57 and the one on the Trimslice is on a flash chip 20:09:06 I can just submit the grubby patch. It's the resizer patch I'm concerned about. 20:09:13 we could package the resizer script 20:09:17 since it's not a patch, it's a standalone package 20:09:29 Why is packaging that an issue? 20:09:36 Sounds straightforward (?) 20:09:39 it's almost something that should be added as a feature to dracut 20:09:39 Because it's a hack 20:09:47 or firstboot 20:10:16 "echo thisthattheother | fdisk" just isn't something I'd like to stamp legitimacy on 20:10:24 well you really need to do it before the rootfs is mounted so dracut in the initrd is the obvious plave 20:11:20 if it were done in initrd that'd mean we could repartition and resize during the same boot, that'd be great 20:11:24 Well, that could be rewritten as a python script that calls parted 20:11:49 ctyler: have somebody handy who can do that? 20:12:00 bconoboy: probably :-) 20:12:08 so maybe we need to file a RFE bug against dracut to see if they could add the functionality (like the usrmove plugin) 20:12:27 Do we need to get this into dracut in F17? 20:12:31 Or save that for F18? 20:12:44 well lets get the bug filed, I think F-18 is fine 20:13:02 Meanwhile, for F17, what do we want to do? 20:13:10 So for F17, use the kludgey bash script, or whip something up in python? 20:13:39 Shortest path is to package the bash script, especially if we're discarding it in due course. 20:13:41 package or no package? 20:13:43 yes, I think the kludgey script should do, its not great but then it's hardly the worst issue 20:13:47 Definitely package. 20:14:07 are we packaging up the entire build scripts as well then? 20:14:19 There shouldn't be any non-package files in a running image. 20:14:30 package: submit for review, or simply carry as bits-of-shame? 20:15:08 bconoboy: I think that (a) all of the files in an image need to be from packages (b) those all need to be genuine Fedora packages. 20:15:13 So, reviewed. 20:15:19 gross. okay. 20:15:58 Question about the build scripts is interesting, I think it would be best to have them packaged, but don't see that as a blocker. What do y'all think? 20:16:25 maybe this has been discussed, but is there a reason we cannot just create one sdcard/mmc image for each platform that does not need to be resized for the official release? 20:16:44 that would avoid the whole issue 20:16:47 ctyler: what do guidelines say? 20:16:50 dmarlin: +1 20:17:01 I think we're going to throw them away for f-18 so have them published as a tar ball and move on 20:17:10 they're already published as a tarball 20:17:23 except that we want people to use the published images, and it's most useful if they'll work with various card sizes 20:17:36 just make them "known small enough" and leave them that way 20:17:51 djdelorie: +1 20:18:09 Would the resizer script really pass review, though? It's ugly. 20:18:19 And it deletes partitions. 20:18:29 bconoboy: It's the packaging that gets reviewed, not the script :-S 20:19:16 the package, once installed, will upon the next reboot delete you / partition, then recreate it the way it thinks is best. I think a reviewer might take issue with that. 20:19:43 I guess it could be done to not turn on by default. 20:19:52 But there are basic sanity checks in there, right? 20:20:26 it deletes the partition described by the root= parameter passed on the kernel command line 20:20:33 (and recreates, of course) 20:20:38 Maybe it's on by default but you need to "touch /.autoresize" or something to kick it off - though I'd prefer it Just Work. 20:20:48 it won't work correctly with efi partitions. 20:21:12 bconoboy: any checks for "last partition and on SD" or similar? 20:21:14 bconoboy: can you use parted move feature? 20:21:27 we're not supporting efi on f-17 on ARM are we? 20:21:35 ctyler: nothing like that 20:21:47 pbrobinson: eventually 20:21:49 pbrobinson: No, but if it's being submitted for review it's going ot be available for any arch, right? 20:22:03 bconoboy: no, it can be ifarch'd 20:22:06 pbrobinson: Or are you thinking this would be exclusivearch? 20:22:17 the question is if any ARM hardware supports EFI 20:22:17 exclusivearch'd rather 20:22:32 expect it will in due course, but not on SDs 20:22:35 there is efi for beagleboard and vexpress 20:22:44 dgilmore: good to know 20:22:54 (Can you do a noarch exclusivearch?) 20:23:01 but afaict not widely used at all 20:23:24 bconoboy: you can. people will question the need 20:23:49 bconoboy: i think there was some simmiliar work done for ec2 images in the past 20:24:04 dgilmore: AFAIK EFI is not very popular 20:24:21 dgilmore: it doesn't bring any benefits 20:24:29 dgilmore: and it's too complicated 20:24:37 If we're going to shoot for this functionality and dracut why not have fixed image sizes and handle this in an update? 20:24:47 I think we ignore it on ARM for the F-17 release. We need to be reasonable, we already have a set of devices we plan to support. 20:25:24 because fixed images aren't that useful -- either you're hitting your head on not-much-space-free or you're writing a zillion zeros to SD needlessly 20:25:51 bconoboy: yes, and either advise people to resize using the device they create the image with or post boot. I always do before hand because I add swap and other bits 20:26:21 ctyler: do a small image and people can resize, it allows them space to add swap 20:26:36 or a separate /home or whatever 20:27:50 guys 20:27:51 * ctyler strongly prefers resize, but prefers getting to GA even more 20:27:55 just an idea 20:27:59 * bconoboy also prefers getting to GA more 20:28:17 we're xzcating the images to the SD 20:28:20 but 20:28:42 maybe we could create an install script, that could prepare the SD card 20:28:57 and then unpack the files there 20:29:34 the script could contain a binary blob holding the archive 20:29:49 a dd you can do anywhere, though - even on Windows 20:29:58 if you *have* to 20:30:10 ctyler: Do you have time to package and submit for review the resizer? I love the functionality, just lack the time to carry through on it 20:30:31 I think it's a bit late to start reinventing the wheel again this late in the process. We have working images the only issue at hand is if/when/how we resize them 20:30:34 windows do have unix tools too 20:30:52 bconoboy: As a bash script in the current form, maybe with a couple lines of sanity check? Sure. 20:31:12 ctyler: the bash script is already in good shape, it's the packaging I don't have time for 20:31:15 but you're right 20:31:19 it would be more difficult 20:31:37 is there a means of disabling it, maybe allowing someone to pass a kernel option? 20:31:58 bconoboy: Sure, should be pretty trivial; will get it into review tomorrow. 20:32:04 pbrobinson: it's just a systemd service 20:32:15 Okay, I propose the following: 20:32:39 yes, but at the top of the bash script you can check the kernel cmd line and exit if it contains something 20:32:40 We go forward without the resizer unless it is accepted for review 20:32:43 pbrobinson: It could pick up a string in /proc/cmdline and disable itself; that might be a good safety net. 20:32:54 ctyler: exactly 20:33:24 pbrobinson: any favorites for the disable string? "noresize"? 20:33:37 so that people that want something other than one big partition have an option to disable 20:33:55 pbrobinson: Assuming they catch the bootup in time 20:34:11 pbrobinson: it could also watch for /.noresize and disable on that too 20:34:13 ctyler: yep or noresizer (or what ever the script is called) 20:34:22 noresizefs ? 20:34:34 a grep for 'noresize' catches all of those ;-) 20:34:55 noresize is too generic 20:35:05 ctyler: yep, just wanted to make sure it won't conflict with some other keyword 20:35:20 I'll check the list. 20:35:32 so something like noarmresize or something less generic 20:35:42 #action ctyler will update and package the automatic filesystem resize script 20:36:04 pleasedontresizethelastfilesystemonthesdcardonthisherearmsystempleasepleaseprettyplease 20:36:11 LOL 20:36:17 #action bconoboy will submit the grubby uImage patch 20:36:27 and who's gonna do the review? 20:36:53 jcapik: for that one, the grubby maintainer 20:36:54 post it to the list and the first person who has the time 20:36:55 does the grubby patch need the grubby maintainer to look at it or can a proven packager handle this? 20:37:10 best for the maint 20:37:16 bconoboy: we should send it to pjones 20:37:23 okay, will do 20:37:27 no ... i mean the resizer script 20:37:32 bconoboy: I would prefer the grubby maintainer to review because that can break a lot 20:37:43 including ever other arch 20:37:43 sure thing 20:37:58 it's a new package, right? 20:38:06 resizer: new package 20:38:22 jcapik: any reviewer could, including pretty much anyone here 20:38:27 if so, then it needs to be reviewed ..... I can do that 20:38:33 to speed things up 20:38:34 sold! 20:38:43 Jumping back to the topic at hand: What's going into F17 ARM GA? 20:38:51 rpm's only, got that 20:38:58 what we had in beta, yes 20:39:11 #action ctyler to package resizer script and get into review 20:39:12 panda: Omap is fixed- we'll include that. X support? 20:39:14 everything tagged into f17 20:39:16 #action jcapik to review 20:39:30 we now have a decent mainline kernel for all arches, we need people to test but from what I've seen 3.4.1-1 is likely our kernel 20:39:33 how about the panda kernel? 20:39:44 any news 20:39:44 bconoboy: need some more testing on the kernel and ill move it into f17 20:39:52 jcapik: 3.4.1-1 fixes that 20:40:03 pbrobinson: great great great 20:40:06 Does the current highbank kernel work? 20:40:16 jcapik: boots and runs x just fine using omapdrm and the newly added xorg-x11-drv-omap driver 20:40:17 We're going to need a 3.4.1-2 for highbank 20:40:30 ctyler: qemu yes real hardware no 20:40:42 So it was suggested we include highbank in GA, do we block on that or ship after? 20:40:47 pbrobinson: are the following issues resolved? 20:40:47 - device-tree on OMAP 20:40:47 - usb reset on trimslice 20:40:47 - auditd issue 20:40:49 highbank has never been on the HW list and it's not widely available, I don't see why we should block the release for that 20:41:13 Wouldn't propose blocking in highbank but I'd like to include it if we can 20:41:17 dmarlin: we're not supporting DeviceTree in F-17, all the rest are resolved 20:41:33 bconoboy: So let's ship it as soon after as possible 20:41:48 if we have a working kernel for Pandas, then we could have X images for panda 20:41:54 ctyler: We can turn around a 3.4.1-2 in less than a day 20:42:07 And it's going to be several days before the linker path issue is fully fixed. 20:42:12 jcapik: yes, we even have an omapdrm driver for X too 20:42:35 So, For F17 GA: Panda support with a minimal rootfs, also with an XFCE? 20:42:41 * ctyler forgot linker path issue, ugg. 20:42:49 (I'd like to get rid of the x-minimal images, they don't seem to be a useful middle ground) 20:42:59 bconoboy: I definitely want Xfce :] 20:43:30 I think we do both 20:43:32 im not sure that the linker path is a blocker 20:43:51 I see the linker path as a blocker 20:43:52 jcapik: do you know how to do "yum install @xfce-desktop" :-D 20:44:16 pbrobinson: yum groupinstall xfce 20:44:28 pbrobinson: if i remember correctly 20:44:33 I don't see it as a blocker, it's a possible large break very late in the process and I don't think it's in gcc yet either 20:44:36 bconoboy: show me where in the release criteria it falls 20:44:40 jcapik: both work 20:45:30 pbrobinson, dgilmore: no one in Fedora would really care if we shipped without the linker patches, but it would be roundly criticized in the ARM community (e.g., cross-distro list, etc) 20:45:31 dgilmore: The whole point of changing linker path was to get it done *before* people went live GA releases. IF F17 goes out with the old linker path we are going back on a cross-distro agreement. 20:46:02 ctyler: are they even all upstream yet, is it already in opensuse and debian and ubuntu? 20:46:14 bconoboy: we never agreed to it before ga we just agreed to do it 20:46:16 pbrobinson: preinstalled could be faster in case of SD cards 20:46:27 it's in the current or next release of all of them (Debian and Ubuntu for sure) 20:46:30 it can be fixed in an update and doesnt prevent install 20:46:37 or booting after install 20:46:42 "or next release" 20:46:57 we're going to catch massive flaming flack if we ship GA without it 20:47:07 so it will be in F-18. I think it's a large change with risk too late in the game where we need to get F-17 out the door 20:47:20 ctyler: flack from who? 20:47:26 ctyler: from who? 20:47:29 the neighbours cat? 20:47:42 flack from the greater ARM community. 20:47:50 them ^ 20:48:14 why? It wasn't in Ubuntu, and it's going to be in "their next releases" so it will be in our next release too. 20:48:48 *it doesn't really matter* because it only *really* affects precompiled commercial software that's supposed to be cross-distro, but it does matter in terms of perception 20:49:01 do we have the patches in glibc and gcc? Have they been widely tested? The answer is NO. That is what rawhide is for. Get the changes into rawhide next week and we can say they're in 20:49:04 I'm not sure waiting to do something until ubuntu has gotten around to it is a good metric 20:49:07 they've asked repeatedly, even on our list, for us to get this into GA 20:49:19 so we can get it into rawhide tomorrow 20:49:40 and once it's baked in there it can always be pulled back 20:49:40 ctyler: no they havnt 20:49:54 ctyler: jonmasters brought up that he would like it 20:49:59 I've seen posts about it on the cross distro but never on arm@fedora 20:50:07 and there was a response from one person saying it would be great 20:50:17 they did not ask us to make sure it was in 20:50:19 but it's not been repeated, it's mostly about if it's upstream yet 20:51:01 pbrobinson: the code is in glibc today. there is a small bug causing it to not activate. it's being worked on now. 20:51:02 I mean are the patches even in the Linaro monthly releases yet? 20:51:28 could have sworn I saw a post on our list 20:51:31 bconoboy: exactly, it was in there for weeks and no one noticed. 20:51:56 and do we have gcc patches yet? I've not seen them and I check most of the PR codes in the gcc new builds 20:51:59 pbrobinson: our own lack of diligence is not exactly thrilling. 20:52:51 which is exactly why I don't want it raced in at the last minute and breaking what is looking to be a good release 20:53:32 Steve McIntyre (linaro) replied to the discussion on arm@fedora urging us to include this as a release blocker 20:53:41 We've talked about it for months on the cross-distro list 20:53:47 bconoboy: why can't we get this into rawhide and test it there and look at rolling it back once tested as an update? 20:54:00 we'll lose a boatload of cred in the cross-distro space if we ship without 20:54:30 http://lists.fedoraproject.org/pipermail/arm/2012-May/003374.html 20:54:35 If we don't follow through on this, it won't be because The Other Guys Didn't Ask Nicely. 20:54:39 I don't give a hoot about what the Linaro guys on cross-distro think, I'm sorry if you won't all be so cool at the next Linaro Connect 20:55:14 bconoboy: its ok to get it in as an update 20:55:20 no one has answered my question why it can't land in rawhide first and be tested there!?! 20:55:23 pbrobinson: Basically, I see us blocking on this as a leadership move: The whoel reason we care about having this path is so we don't fragment the arm space. 20:55:51 it's a bloody sym link 20:56:02 pbrobinson: If we ship F17 without the patch, we have to issue an update later. When ISVs go to develop software that needs to run for years they'll want the distirbution that is cross compatible. It won't be us. 20:56:27 It is a symlink, that's why it's trivial to block on, because we can fix it easily. We just haven't yet. 20:56:38 bconoboy: today its no distro afaik 20:56:39 Very little risk, even this late 20:56:44 and if you care so greatly about it why weren't you pushing it weeks ago, as you've all said it's been available for weeks and no one could give a shit about it until now 20:56:54 jcm also requested this (http://lists.fedoraproject.org/pipermail/arm/2012-May/003353.html) 20:57:08 that is "weeks ago" 20:57:14 jcm requested it but no one has done the work 20:57:25 we thought the work had been done 20:57:33 the patch went upstream, we pulled it in 20:57:50 if jcm felt so strongly about it he would have got the patches and bothered the appropriate owners and actually tested it 20:58:17 bconoboy: it was pulled in on glibc but is there a patch in gcc yet? 20:58:25 how about we strike a middle ground: Let's make it a 1 week blocker. If it isn't completely solved in 1 week, we ship without. 20:58:28 and the patch on glibc wasn't even tested 20:59:01 the patch was brought in by the glibc maintainer who doesn't have arm hardware. 20:59:10 I'd prefer that we take this to the list rather than decide here. This is a Big Deal to some. 20:59:17 bconoboy so if it lands 5 minutes before the week is up we ship with zero testing? You've got to be bloody kidding 20:59:50 ctyler: why? So it can be discussed behind closed doors? 21:00:06 pbrobinson: Srsly? The list is "closed doors"?! 21:00:23 bconoboy: but it wasn't tested by the ARM guys with ARM hardware who do care about it 21:00:26 It's a bigger group than the half-dozen of us talking here. 21:00:42 pbrobinson: If 1 week is too long I'm open to other suggestions... jsut give us some way to get F17 to use this patch. 21:00:53 ctyler: I didn't see "list" I just saw discuss elsewhere 21:01:29 bconoboy: as you and ctyler have rightly pointed out we've had weeks to do this and the people who care didn't 21:01:48 the people who care thought it was already done, man. 21:02:10 I even went as far as explicitly building the glibc at the time and giving a heads up on the irc channel and still people didn't bother to test 21:02:25 but didn't test to make sure it works 21:03:17 bconoboy: you still haven't acked whether the patch is in our gcc yet 21:03:30 not aware of current gcc status. 21:03:35 I think perhaps we take this to the list to discuss further? We are at the hour and do have a couple other items to discuss, shall we move on? 21:03:46 +1 21:03:48 +1 to move on 21:04:03 +1 21:04:04 +1 21:04:09 #topic 2) F17 Updates - status - shadowing updates 21:04:17 so I propose this 1) the people who care post the details of the _EXACT_ status to the list of all components and what work is remaining to be done 21:04:54 pbrobinson: Will do 21:05:07 2) if it's not all in and built by Monday morning (lets say 12:00 GMT) it slips else we test and review between then and Wednesday 21:05:31 that means that the gcc needs to be building by close of play friday night 21:05:37 pbrobinson: -1 # You can propose that on the list. 21:06:28 ctyler: can we at least agree on point 1) as at the moment the people who care don't even know what the status of the feature is 21:06:47 +1 on (1) 21:06:56 I agree with point 1 and will follow up with the responsible parties. 21:07:36 #action bconoboy to follow up on list with linker name status (incl. gcc, glibc), discussion to continue there 21:08:19 I mean I've put in 100s of hours on this release and I spent half my 4 day weekend ensuring we have the kernel fixed because I cared that we ship the release and get on status yet people can't even do basic research as to the status of this 21:08:38 * djdelorie thought we moved on to the next topic... 21:08:47 and this is the first time it has been bought up as a release blocker 21:09:01 pbrobinson: Noted, and I also really want to see us hit GA asap. 21:09:01 are we currently shadowing f17-updates or are the updates getting pulled in while shadowing f18? 21:09:16 pwhalen: updates are shadowed 21:09:21 and going out daily 21:09:36 are they showing up in the usual mirrors so "yum update" just works? 21:09:41 i have noticed the images have gpgchecking and updates disabled 21:09:53 pwhalen: dgilmore reported we had 100% coverage on updates as of the weekend 21:09:56 djdelorie: yes as long as you fix the repo files 21:10:13 pbrobinson, missed that, thanks 21:10:26 what's to fix? Just enabling them? 21:10:42 djdelorie: yes 21:10:45 mine has enabled=1 and gpgcheck=1 but I'm not running one of bconoboy's images 21:10:56 djdelorie: and enabling gog checking on the fedora repo 21:11:04 gpg 21:13:06 I didn't have that, fixed :-) My 2.6.42 kernel is still occasionally changing the rootfs to read-only. Do we know if my usb-on-3.x bug was fixed? 21:13:36 djdelorie: can we take that to the arm channel and move on with the meeting 21:13:45 statistics: {'older': 1, 'local_only': 0, 'remote_only': 90, 'same': 708, 'newer': 0, 'total_missing_builds': 1} 21:13:54 thats f17-updates right now 21:14:12 is there a new kernel in updates? /me wonders if we need to document how to deal with a kernel update 21:14:28 dgilmore: does that mean we're 1 behind? 21:14:37 djdelorie: there is the proposed ga kernel in updates-testing 21:14:38 dgilmore, wow, awesome - so in great shape 21:14:48 pbrobinson: means we skipped a build 21:14:56 dgilmore: which version? 21:15:08 3.4.1-1 21:15:19 newer remote: local: opus-0.9.10-1.fc17 remote: opus-0.9.14-1.fc17 with 1 build(s) missing 21:15:49 some of the 90 remote only need top be built some are exlcuded 21:16:11 i need to teach koji-compare to ignore excludearch packages 21:16:39 and koji-shadow :-D 21:17:03 aside: we need to make sure all the pre-GA images get deleted at some point, once we have GA images 21:17:08 pbrobinson: its supposed to be 21:17:47 #topic 3) F17 Raspberry Pi Remix - status update 21:18:14 just did "yum update" and it's pulling kernel from fedora, not updates or updates-testing. Other things *are* coming in from updates and updates-testing 21:18:21 dgilmore: it's not, it submits builds that then FAIL because of no supported arches 21:18:41 pbrobinson: that means the list is not right 21:18:41 or do I need to switch from kernel-tegra to kernel-something-else ? 21:19:04 djdelorie: rpm -qa|grep kernel 21:19:08 djdelorie: not sure if that kernel is in the repos yet, if it made it to today's compose it might still be mirroring 21:19:13 djdelorie: but in #fedora-arm 21:19:40 pbrobinson: lets make sure that the list we have is current 21:19:57 Raspi update: Linaro Connect killed my productivity last week, I'm hoping to sort the kernel-firmware stuff by Friday and get a test Remix image out, with a polished image about a week later. 21:20:15 djdelorie: all the details of the kernel are on #fedora-arm can we take random user update queries there 21:20:21 hopefully the rest of us will start getting RPis soon ;-) 21:20:52 I really want to match or beat the "Debian" image for boot speed, boot memory usage, and web browsing. 21:20:58 but anyway, "yum update" did pull packages from updates and updates testing, so that works :-) 21:21:21 ctyler: is there an update on what's happening with the vouchers? 21:21:55 also is there an update of getting a more Fedora compiled kernel even if it's still using their source? 21:22:07 pbrobinson: The Uptons (my contacts) were on vacation, last update before that was that they were "almost ready". I'll ping again now that they're back. 21:22:38 pbrobinson: I've merged the Fedora and Raspi configs, but their patches aren't upstreamed and they're stuck at 3.1.9 for now :-( 21:22:51 Upstreaming will be ugly. 21:22:55 ctyler: Debian has SysV, right? 21:23:09 OK, it seems its becoming a bit political because people don't know what's happening 21:23:10 jcapik: Upstart maybe? Not sure. 21:23:44 have we gotten any requests for remixes for other platforms? There's news of other sub-$100 arm computers... 21:24:03 ctyler: not worried too much about upstreaming, I know of people working on that. The kernel doesn't have a lot of standard fedora features such as netconsole and vlans and people are complaining 21:24:06 pbrobinson: yeah. I want to get this right performance-wise but need to ship soon. 21:24:52 pbrobinson: I have a config with ipv6, cgroups, etc. all enabled and it works well with most of the Fedora stuff 21:25:00 I had a number of Debian users from the office switch over from the Debian build for those sorts of things only to discover we didn't have them either 21:25:43 and also what's happening with the Fedora images shipping. We were suppose to be the default but it seems at the moment we're not even mentioned on their site 21:26:13 indeed it looks bad for fedora in raspberry pi land 21:26:21 like we are not involved or interested 21:26:50 There were a lot of reports of issues with the F14 remix, they pulled us for now. That's why I really don't want to ship a premature F17 remix. 21:27:11 Who has boards? 21:27:23 ctyler: none of us 21:27:24 * djdelorie is still waiting 21:27:26 * lmacken seeing some stability issues with the latest f17 nightly on his rasp 21:27:30 From all the initial good initiative and press that we had it seems to have gone in reverse and I see people complaining on twitter, IRC, google+ and other places. Not ideal! 21:27:46 ctyler: jskarvad do 21:27:46 ctyler: we just get a lot of people dropping in #fedora-arm asking for help 21:27:58 yeah, and it will increase fast 21:28:19 lmacken: I'd like to know what you're seeing 21:28:22 and it doesn't help that people are getting them before those of us supposed working on it 21:28:27 Jun 6 17:07:04 fedora-arm kernel: [ 2736.178115] glhanoi: page allocation failure: order:3, mode:0x4020 21:28:30 ctyler: but none of the fedora developers have a board 21:28:38 I can ask jskarvad to help here 21:28:40 lots of these too: Jun 6 17:06:47 fedora-arm kernel: [ 2718.817751] WARN::hc_xfer_timeout:1740: hc_xfer_timeout: timeout on channel 1 21:28:42 and the worst is that there's been no status updates posted anywhere people can find out 21:28:45 Jun 6 17:06:56 fedora-arm kernel: [ 2728.311655] mmc0: note - long write sync 740000ns - 7495 its. 21:28:50 Also, there are apparently a few small differences between the beta and alpha boards, which I can't test yet. 21:28:59 lmacken: this isn't a technical meeting 21:29:33 ctyler: the f17 nightly is currently using all f14 rpms. If you have a partial set of f17 to go with I'd be happy to introduce them. 21:29:44 ctyler: we really need thouse that we gave vouchers to to get their boards 21:29:59 So I'll post to the Raspi community, we'll have a test image on Friday (or Monday, worst case), and try to get the final out next week depending on feedback. 21:30:10 ctyler: can we at least get f17 built binaries so we can ensure it's all gcc 4.7 built 21:30:12 dgilmore: I agree, it's been frustrating trying to get the foundation to cough them up. 21:30:38 a repo somewhere would be ideal so people that are testing can get new binaries for testing as you fix things. 21:31:50 pbrobinson: ok - though I'd almost rather people grab new images for now 21:32:01 ctyler: there needs to be more communication 21:32:02 ctyler: I'm not sure why, a whole lot of the other developers seemed to have them posted directly to them, why weren't at least seneca on that list 21:32:33 pbrobinson: sorry, not following you there 21:32:38 ? 21:32:49 ctyler: but the currently nightly images have f14 binaries so that's not working, why can't there be a repo of binaries. I'm aware there's an issue with source, not asking for that 21:33:01 ctyler: developers in other distro communitiies seemed to have recieved boards 21:33:09 why havent we 21:34:04 dgilmore: I don't know. I do know some other communities have been grumbling about not getting boards too though. 21:34:11 ctyler: other distros and kernel devs were sent release boards directly along side media by the foundation, why weren't Seneca as developers sent boards as well so it could be tested? Was it an oversight somewhere? 21:34:39 We have one alpha board, that's all. I've asked repeatedly for more or later boards, but haven't received them. 21:35:07 #action ctyler to post to the Raspi community with a status report, test image by next week Monday 21:35:15 Otoh, my personal order with Element14 was supposed to have shipped yesterday, though UPS doesn't acknowledge the trackiing number. 21:35:19 OK, so there's an issue there somewhere. Can you follow up with an update to the list now they're back 21:35:29 Will do. 21:35:35 #topic 4) Device tree - should Fedora be providing it? 21:35:43 we're not done 21:36:10 ctyler: what is the time frame to get new F-17 binaries for testing? Either in an image or repo or both? 21:36:24 preferably both 21:36:40 pbrobinson: As I said, I'm aiming for EOW. 21:36:55 excellent, I look forward to the mail to the list 21:37:19 4) if it works, then yes 21:37:27 pwhalen: now for #4 21:37:31 jcapik: no 21:37:47 fedora should not be providing device tree blobs 21:37:55 why not? 21:38:01 the manufacturers of the hardware should be 21:38:09 should not be, in the ideal sense? Or should not be, in the technical-todays-status sense? 21:38:10 at the moment device tree isn't to a state that it's complete and working yet, there's still a lot of support missing from various components of the kernel 21:38:12 but they change with different kernels. 21:38:37 So the news from the arm soc maintainer last week was that all new submits to that tree are expected to use DT. The manufacturers should be providing DT files but aren't, and the nodes are changing as drivers are finalized. 21:38:42 We should be providing them for now. 21:38:51 bconoboy: no they don't, ultimately the vendors should be passing a devicetree with all their hardware to the kernel on boot 21:39:12 pbrobinson: yes they do :-S 21:39:13 do we provide them in an RPM, or a per-board web page, or in images, or how? 21:39:34 djdelorie: currently we don't at all. the question is: should we? 21:39:39 ctyler: as of the 3.5 SoC merge the status update was that not all bits were there, maybe that's all new submissions but there's a lot of other bits that still need updating 21:39:45 currently there's no way to set a permanent MAC address on Pandas ... 21:39:45 we shouldnt 21:40:08 jcapik: and you currently cant do it via dt either 21:40:14 We shouldn't have to, but there is a reason to do so. Is the reason good enough? 21:40:15 "ideal vs practical" is not an easy argument 21:40:24 the patches dont apply because we never sent them upstream 21:40:29 so the kernels come with dtb that can be appended to the end of the kernel but as yet that doesn't provide us anything over what we have at the moment 21:40:33 dgilmore: there's no reasonable alternative. DT is coming whether we want it or not, and the board suppliers aren't/can't provide the blobs, so we need to. 21:40:41 we dont have a framework to make them either 21:40:49 we still can't boot a kernel with support for different vendor SoCs 21:40:49 dgilmore: yup ... but that means DT doesn't work 21:40:51 ctyler: no we dont 21:41:02 considering the time perhaps we should table this one for next week. 21:41:03 dgilmore: and in that case I'm saying NO :] 21:41:13 dgilmore: you keep saying that, but the alternative (eventually) is "Fedora doesn't work on my board" 21:41:22 bconboy: at the moment it doesn't provide us any major advantage 21:41:34 I thought the trimslice frame buffer needed DT ? 21:41:47 djdelorie: it does 21:41:50 dgilmore: I would rather see a kernel patch for permanent MAC 21:41:59 ctyler: we know DT is coming whether we like it or no but at the moment it's still not complete 21:42:00 jcapik: patches accepted 21:42:28 djdelorie: uboot on the trimslice doesnt support dt. 21:42:47 djdelorie: and it needs a file that i have no idea how we can even provide 21:42:52 djdelorie: at the moment it's neither ideal or practical. 21:42:57 djdelorie: that defines some edid data 21:43:14 I'm thinking from the users standpoint. "why doesn't my monitor work?" is an obvious and appropriate question 21:43:21 I believe that DT will be usable in the F-18 timeframe but at the moment it's not 21:43:44 yup ... it's still unusable 21:43:51 djdelorie: device tree won't fix your monitor if there's no support for it in the drivers 21:44:04 the only platform that can show a desktop is qemu, and that's embarrasing. 21:44:26 pbrobinson: it's upstream, we just don't have that kernel yet, but it won't work anyway without DT 21:44:27 djdelorie: for example none of the genesi stuff has monitor / lcd support. DT won't fix that. Same with tegra 21:44:49 djdelorie: omap is working now also 21:44:56 ah, good 21:44:57 djdelorie: SOME of it is upstream, there's still whole bits of the kernel that don't support it yet 21:45:23 djdelorie: as of 3.4.1-1 your monitor will work without device tree 21:45:32 trimslice? 21:45:36 djdelorie: no 21:45:45 nope, there's no patches upstream yet 21:46:04 and that's nothing to do with DT, there's no KMS driver upstream yet 21:46:05 the patches for tegradrm have been sent as a rfc 21:46:39 There will be more and more drivers that transition to DT 21:47:05 there will be 21:47:11 ctyler: yes, which is why I said it should be usable in F-18 timeframe and believe me I'm watching kernel closely for that 21:47:51 Folks, we're at +75% on our time, and I know at least one of us has to attend their own b-day party tonight (not me!)... should we wrap? 21:47:58 but at the moment none of the devices we support have a full upstream device tree support. I think the first full support should land for 3.6 or maybe 3.7 so at that point we can start to test 21:48:03 pbrobinson/dgilmore: In the event that DT does something useful, do you have a threshold at which point you would accept fedora providing dt blobs instead of relying on a mfr? 21:48:34 bconoboy: as soon as it works I'll happily start to test it 21:48:51 but until we know it's upstream there is no point 21:48:54 bconoboy: how do we make the dtb files? 21:49:04 dgilmore: the kernel makefile 21:49:05 dgilmore: Believe you can generate them from the kernel 21:49:07 bconoboy: some of them are user configurable 21:49:12 I've seen test branches from Linaro but the changes there are massive and we'll never carry them 21:49:24 bconoboy: we have no framework today to do that 21:49:42 ultimately they'll need to be included in the mainline kernel 21:50:22 there's already partial bits there but we need the manufacturers to deal with it in their bootloader and we know what response we get to that from the likes of TrimSlice 21:50:30 I think this will be clearly needed in the f18 timeframe. 21:50:38 I see this as being like uboot- some vendors build it in and when they do there is no reason to bring our own. Otherwise.... 21:50:47 we'll likely see Panda/Beagle patches go into uboot at which point for those devices it will be easy 21:51:33 ctyler: I don't think we can say that until it's upstream, or do you have a dozen kernel developers on hand to produce that 21:51:44 There are few separate issues, like where the dtb's are coming from, and whether the dtb is appended to the kernel or the uBoot is one that can pass a discrete dt blob to the kernel. 21:52:12 pbrobinson: from the conversations last week with the arm soc guy, it looks like its coming fast 21:52:15 I honestly would love to hope and I believe we'll see a mostly complete implementation upstream in the F-18 timeframe and if we do we'll support it 21:52:45 ctyler: maybe in their own branches while drinking their own coolaid or the Linaro fork everything first coolaid 21:52:46 this issue is clearly too muddy to be resolved right now 21:52:58 so lets revisit this at a future meeting? 21:53:04 bconoboy: exactly 21:53:09 #topic 5) your topic here 21:53:10 actually, they pointed to highbank drivers as an example of dtb done well, iirc 21:53:47 ultimately once I see it land upstream I will start to play because it interests me because i want less than 10 million separate kernels :-D 21:53:47 * ctyler proposed #endmeeting 21:53:49 /topic that took a while 21:54:03 ctyler +1 21:54:04 anything else before we wrap? 21:54:09 nope 21:54:12 +1 21:54:16 pbrobinson: separate zImage and DT are related but separate issues 21:54:16 #endmeeting