fedora-meeting-1
LOGS
20:00:28 <pwhalen> #startmeeting
20:00:28 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:28 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson
20:00:28 <zodbot> Current chairs: bconoboy ctyler jonmasters pbrobinson pwhalen
20:00:34 <jcapik> .fas jcapik
20:00:35 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:00:39 * pwhalen pwhalen is here
20:00:43 * ctyler here
20:00:44 <bconoboy> .fas blc
20:00:44 <zodbot> bconoboy: blckspder 'Antoni Sousa' <blckspder@gmail.com> - blc '' <blc@redhat.com>
20:00:54 <ctyler> .fas ctyler
20:00:55 <zodbot> ctyler: ctyler2621 'Christopher Tyler' <chris@mowisp.com> - ctyler 'Chris Tyler' <chris@tylers.info>
20:01:08 <ctyler> 2nd one ^
20:01:17 <djdelorie> .fas delorie
20:01:18 <zodbot> djdelorie: djdelorie 'DJ Delorie' <dj@redhat.com>
20:01:33 <pwhalen> .fas pwhalen
20:01:33 <zodbot> pwhalen: pwhalen 'Paul Whalen' <paul.whalen@senecac.on.ca>
20:02:23 <pwhalen> #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 <bconoboy> I'd like F17 GA to look like the beta, but include panda and highbank images- at a minimum.
20:03:38 <bconoboy> (er, also include)
20:03:42 * maxam is here
20:04:30 <bconoboy> There are two things in the F17 beta images that are not packaged in RPM format:
20:05:01 <bconoboy> 1. There are some changes to grubby that handle the uImage load addresses that aren't known to stock grubby
20:05:01 <ctyler> What pieces are in the images that are not packaged?
20:05:21 <bconoboy> 2. The rootfs resizer script and its systemd file are not in a package.
20:05:49 <ctyler> Are the patches for (1) acceptable to the packager?
20:06:40 <bconoboy> 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 <ctyler> What about uboot/xloader/MLO/...?
20:08:14 <bconoboy> the uboot and MLO for beagle and panda come from fedora packages. no issues.
20:08:57 <pbrobinson> and the one on the Trimslice is on a flash chip
20:09:06 <bconoboy> I can just submit the grubby patch.  It's the resizer patch I'm concerned about.
20:09:13 <pwhalen> we could package the resizer script
20:09:17 <bconoboy> since it's not a patch, it's a standalone package
20:09:29 <ctyler> Why is packaging that an issue?
20:09:36 <ctyler> Sounds straightforward (?)
20:09:39 <pbrobinson> it's almost something that should be added as a feature to dracut
20:09:39 <bconoboy> Because it's a hack
20:09:47 <djdelorie> or firstboot
20:10:16 <bconoboy> "echo thisthattheother | fdisk" just isn't something I'd like to stamp legitimacy on
20:10:24 <pbrobinson> well you really need to do it before the rootfs is mounted so dracut in the initrd is the obvious plave
20:11:20 <bconoboy> 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 <ctyler> Well, that could be rewritten as a python script that calls parted
20:11:49 <bconoboy> ctyler: have somebody handy who can do that?
20:12:00 <ctyler> bconoboy: probably :-)
20:12:08 <pbrobinson> 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 <ctyler> Do we need to get this into dracut in F17?
20:12:31 <ctyler> Or save that for F18?
20:12:44 <pbrobinson> well lets get the bug filed, I think F-18 is fine
20:13:02 <bconoboy> Meanwhile, for F17, what do we want to do?
20:13:10 <ctyler> So for F17, use the kludgey bash script, or whip something up in python?
20:13:39 <ctyler> Shortest path is to package the bash script, especially if we're discarding it in due course.
20:13:41 <bconoboy> package or no package?
20:13:43 <pbrobinson> yes, I think the kludgey script should do, its not great but then it's hardly the worst issue
20:13:47 <ctyler> Definitely package.
20:14:07 <pbrobinson> are we packaging up the entire build scripts as well then?
20:14:19 <ctyler> There shouldn't be any non-package files in a running image.
20:14:30 <bconoboy> package: submit for review, or simply carry as bits-of-shame?
20:15:08 <ctyler> 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 <ctyler> So, reviewed.
20:15:19 <bconoboy> gross. okay.
20:15:58 <ctyler> 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 <dmarlin> 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 <dmarlin> that would avoid the whole issue
20:16:47 <jcapik> ctyler: what do guidelines say?
20:16:50 <bconoboy> dmarlin: +1
20:17:01 <pbrobinson> 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 <bconoboy> they're already published as a tarball
20:17:23 <ctyler> 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 <djdelorie> just make them "known small enough" and leave them that way
20:17:51 <dmarlin> djdelorie: +1
20:18:09 <bconoboy> Would the resizer script really pass review, though?  It's ugly.
20:18:19 <bconoboy> And it deletes partitions.
20:18:29 <ctyler> bconoboy: It's the packaging that gets reviewed, not the script :-S
20:19:16 <bconoboy> 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 <bconoboy> I guess it could be done to not turn on by default.
20:19:52 <ctyler> But there are basic sanity checks in there, right?
20:20:26 <bconoboy> it deletes the partition described by the root= parameter passed on the kernel command line
20:20:33 <bconoboy> (and recreates, of course)
20:20:38 <ctyler> 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 <bconoboy> it won't work correctly with efi partitions.
20:21:12 <ctyler> bconoboy: any checks for "last partition and on SD" or similar?
20:21:14 <dgilmore> bconoboy: can you use parted move feature?
20:21:27 <pbrobinson> we're not supporting efi on f-17 on ARM are we?
20:21:35 <bconoboy> ctyler: nothing like that
20:21:47 <dgilmore> pbrobinson: eventually
20:21:49 <bconoboy> pbrobinson: No, but if it's being submitted for review it's going ot be available for any arch, right?
20:22:03 <ctyler> bconoboy: no, it can be ifarch'd
20:22:06 <bconoboy> pbrobinson: Or are you thinking this would be exclusivearch?
20:22:17 <jcapik> the question is if any ARM hardware supports EFI
20:22:17 <ctyler> exclusivearch'd rather
20:22:32 <ctyler> expect it will in due course, but not on SDs
20:22:35 <dgilmore> there is efi for beagleboard and vexpress
20:22:44 <jcapik> dgilmore: good to know
20:22:54 <bconoboy> (Can you do a noarch exclusivearch?)
20:23:01 <dgilmore> but afaict not widely used at all
20:23:24 <dgilmore> bconoboy: you can. people will question the need
20:23:49 <dgilmore> bconoboy: i think there was some simmiliar work done for ec2 images in the past
20:24:04 <jcapik> dgilmore: AFAIK EFI is not very popular
20:24:21 <jcapik> dgilmore: it doesn't bring any benefits
20:24:29 <jcapik> dgilmore: and it's too complicated
20:24:37 <bconoboy> 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 <pbrobinson> 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 <ctyler> 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 <pbrobinson> 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 <pbrobinson> ctyler: do a small image and people can resize, it allows them space to add swap
20:26:36 <pbrobinson> or a separate /home or whatever
20:27:50 <jcapik> guys
20:27:51 * ctyler strongly prefers resize, but prefers getting to GA even more
20:27:55 <jcapik> just an idea
20:27:59 * bconoboy also prefers getting to GA more
20:28:17 <jcapik> we're xzcating the images to the SD
20:28:20 <jcapik> but
20:28:42 <jcapik> maybe we could create an install script, that could prepare the SD card
20:28:57 <jcapik> and then unpack the files there
20:29:34 <jcapik> the script could contain a binary blob holding the archive
20:29:49 <ctyler> a dd you can do anywhere, though - even on Windows
20:29:58 <ctyler> if you *have* to
20:30:10 <bconoboy> 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 <pbrobinson> 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 <jcapik> windows do have unix tools too
20:30:52 <ctyler> bconoboy: As a bash script in the current form, maybe with a couple lines of sanity check? Sure.
20:31:12 <bconoboy> ctyler: the bash script is already in good shape, it's the packaging I don't have time for
20:31:15 <jcapik> but you're right
20:31:19 <jcapik> it would be more difficult
20:31:37 <pbrobinson> is there a means of disabling it, maybe allowing someone to pass a kernel option?
20:31:58 <ctyler> bconoboy: Sure, should be pretty trivial; will get it into review tomorrow.
20:32:04 <bconoboy> pbrobinson: it's just a systemd service
20:32:15 <bconoboy> Okay, I propose the following:
20:32:39 <pbrobinson> 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 <bconoboy> We go forward without the resizer unless it is accepted for review
20:32:43 <ctyler> pbrobinson: It could pick up a string in /proc/cmdline and disable itself; that might be a good safety net.
20:32:54 <pbrobinson> ctyler: exactly
20:33:24 <ctyler> pbrobinson: any favorites for the disable string? "noresize"?
20:33:37 <pbrobinson> so that people that want something other than one big partition have an option to disable
20:33:55 <bconoboy> pbrobinson: Assuming they catch the bootup in time
20:34:11 <ctyler> pbrobinson: it could also watch for /.noresize and disable on that too
20:34:13 <pbrobinson> ctyler: yep or noresizer (or what ever the script is called)
20:34:22 <jcapik> noresizefs ?
20:34:34 <ctyler> a grep for 'noresize' catches all of those ;-)
20:34:55 <jcapik> noresize is too generic
20:35:05 <pbrobinson> ctyler: yep, just wanted to make sure it won't conflict with some other keyword
20:35:20 <ctyler> I'll check the list.
20:35:32 <pbrobinson> so something like noarmresize or something less generic
20:35:42 <bconoboy> #action ctyler will update and package the automatic filesystem resize script
20:36:04 <ctyler> pleasedontresizethelastfilesystemonthesdcardonthisherearmsystempleasepleaseprettyplease
20:36:11 <pbrobinson> LOL
20:36:17 <bconoboy> #action bconoboy will submit the grubby uImage patch
20:36:27 <jcapik> and who's gonna do the review?
20:36:53 <ctyler> jcapik: for that one, the grubby maintainer
20:36:54 <pbrobinson> post it to the list and the first person who has the time
20:36:55 <bconoboy> does the grubby patch need the grubby maintainer to look at it or can a proven packager handle this?
20:37:10 <ctyler> best for the maint
20:37:16 <dgilmore> bconoboy: we should send it to pjones
20:37:23 <bconoboy> okay, will do
20:37:27 <jcapik> no ... i mean the resizer script
20:37:32 <pbrobinson> bconoboy: I would prefer the grubby maintainer to review because that can break a lot
20:37:43 <pbrobinson> including ever other arch
20:37:43 <bconoboy> sure thing
20:37:58 <jcapik> it's a new package, right?
20:38:06 <bconoboy> resizer: new package
20:38:22 <ctyler> jcapik: any reviewer could, including pretty much anyone here
20:38:27 <jcapik> if so, then it needs to be reviewed ..... I can do that
20:38:33 <jcapik> to speed things up
20:38:34 <ctyler> sold!
20:38:43 <bconoboy> Jumping back to the topic at hand: What's going into F17 ARM GA?
20:38:51 <bconoboy> rpm's only, got that
20:38:58 <bconoboy> what we had in beta, yes
20:39:11 <ctyler> #action ctyler to package resizer script and get into review
20:39:12 <bconoboy> panda: Omap is fixed- we'll include that.  X support?
20:39:14 <dgilmore> everything tagged into f17
20:39:16 <ctyler> #action jcapik to review
20:39:30 <pbrobinson> 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 <jcapik> how about the panda kernel?
20:39:44 <jcapik> any news
20:39:44 <dgilmore> bconoboy: need some more testing on the kernel and ill move it into f17
20:39:52 <pbrobinson> jcapik: 3.4.1-1 fixes that
20:40:03 <jcapik> pbrobinson: great great great
20:40:06 <ctyler> Does the current highbank kernel work?
20:40:16 <dgilmore> jcapik: boots and runs x just fine using omapdrm and the newly added xorg-x11-drv-omap driver
20:40:17 <bconoboy> We're going to need a 3.4.1-2 for highbank
20:40:30 <dgilmore> ctyler: qemu yes real hardware no
20:40:42 <ctyler> So it was suggested we include highbank in GA, do we block on that or ship after?
20:40:47 <dmarlin> pbrobinson: are the following issues resolved?
20:40:47 <dmarlin> - device-tree on OMAP
20:40:47 <dmarlin> - usb reset on trimslice
20:40:47 <dmarlin> - auditd issue
20:40:49 <pbrobinson> 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 <bconoboy> Wouldn't propose blocking in highbank but I'd like to include it if we can
20:41:17 <pbrobinson> dmarlin: we're not supporting DeviceTree in F-17, all the rest are resolved
20:41:33 <ctyler> bconoboy: So let's ship it as soon after as possible
20:41:48 <jcapik> if we have a working kernel for Pandas, then we could have X images for panda
20:41:54 <bconoboy> ctyler: We can turn around a 3.4.1-2 in less than a day
20:42:07 <bconoboy> And it's going to be several days before the linker path issue is fully fixed.
20:42:12 <pbrobinson> jcapik: yes, we even have an omapdrm driver for X too
20:42:35 <bconoboy> 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 <bconoboy> (I'd like to get rid of the x-minimal images, they don't seem to be a useful middle ground)
20:42:59 <jcapik> bconoboy: I definitely want Xfce :]
20:43:30 <pbrobinson> I think we do both
20:43:32 <dgilmore> im not sure that the linker path is a blocker
20:43:51 <bconoboy> I see the linker path as a blocker
20:43:52 <pbrobinson> jcapik: do you know how to do "yum install @xfce-desktop" :-D
20:44:16 <jcapik> pbrobinson: yum groupinstall xfce
20:44:28 <jcapik> pbrobinson: if i remember correctly
20:44:33 <pbrobinson> 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 <dgilmore> bconoboy: show me where in the release criteria it falls
20:44:40 <pbrobinson> jcapik: both work
20:45:30 <ctyler> 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 <bconoboy> 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 <pbrobinson> ctyler: are they even all upstream yet, is it already in opensuse and debian and ubuntu?
20:46:14 <dgilmore> bconoboy: we never agreed to it before ga we just agreed to do it
20:46:16 <jcapik> pbrobinson: preinstalled could be faster in case of SD cards
20:46:27 <ctyler> it's in the current or next release of all of them (Debian and Ubuntu for sure)
20:46:30 <dgilmore> it can be fixed in an update and doesnt prevent install
20:46:37 <dgilmore> or booting after install
20:46:42 <pbrobinson> "or next release"
20:46:57 <ctyler> we're going to catch massive flaming flack if we ship GA without it
20:47:07 <pbrobinson> 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 <pbrobinson> ctyler: flack from who?
20:47:26 <dgilmore> ctyler: from who?
20:47:29 <pbrobinson> the neighbours cat?
20:47:42 <bconoboy> flack from the greater ARM community.
20:47:50 <ctyler> them ^
20:48:14 <pbrobinson> 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 <ctyler> *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 <pbrobinson> 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 <bconoboy> I'm not sure waiting to do something until ubuntu has gotten around to it is a good metric
20:49:07 <ctyler> they've asked repeatedly, even on our list, for us to get this into GA
20:49:19 <pbrobinson> so we can get it into rawhide tomorrow
20:49:40 <pbrobinson> and once it's baked in there it can always be pulled back
20:49:40 <dgilmore> ctyler: no they havnt
20:49:54 <dgilmore> ctyler: jonmasters brought up that he would like it
20:49:59 <pbrobinson> I've seen posts about it on the cross distro but never on arm@fedora
20:50:07 <dgilmore> and there was a response from one person saying it would be great
20:50:17 <dgilmore> they did not ask us to make sure it was in
20:50:19 <pbrobinson> but it's not been repeated, it's mostly about if it's upstream yet
20:51:01 <bconoboy> 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 <pbrobinson> I mean are the patches even in the Linaro monthly releases yet?
20:51:28 <ctyler> could have sworn I saw a post on our list
20:51:31 <pbrobinson> bconoboy: exactly, it was in there for weeks and no one noticed.
20:51:56 <pbrobinson> 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 <bconoboy> pbrobinson: our own lack of diligence is not exactly thrilling.
20:52:51 <pbrobinson> 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 <bconoboy> Steve McIntyre (linaro) replied to the discussion on arm@fedora urging us to include this as a release blocker
20:53:41 <bconoboy> We've talked about it for months on the cross-distro list
20:53:47 <pbrobinson> 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 <ctyler> we'll lose a boatload of cred in the cross-distro space if we ship without
20:54:30 <ctyler> http://lists.fedoraproject.org/pipermail/arm/2012-May/003374.html
20:54:35 <bconoboy> If we don't follow through on this, it won't be because The Other Guys Didn't Ask Nicely.
20:54:39 <pbrobinson> 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 <dgilmore> bconoboy: its ok to get it in as an update
20:55:20 <pbrobinson> no one has answered my question why it can't land in rawhide first and be tested there!?!
20:55:23 <bconoboy> 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 <pbrobinson> it's a bloody sym link
20:56:02 <bconoboy> 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 <bconoboy> 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 <dgilmore> bconoboy: today its no distro afaik
20:56:39 <bconoboy> Very little risk, even this late
20:56:44 <pbrobinson> 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 <ctyler> jcm also requested this (http://lists.fedoraproject.org/pipermail/arm/2012-May/003353.html)
20:57:08 <ctyler> that is "weeks ago"
20:57:14 <pbrobinson> jcm requested it but no one has done the work
20:57:25 <bconoboy> we thought the work had been done
20:57:33 <bconoboy> the patch went upstream, we pulled it in
20:57:50 <pbrobinson> 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 <pbrobinson> bconoboy: it was pulled in on glibc but is there a patch in gcc yet?
20:58:25 <bconoboy> 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 <pbrobinson> and the patch on glibc wasn't even tested
20:59:01 <bconoboy> the patch was brought in by the glibc maintainer who doesn't have arm hardware.
20:59:10 <ctyler> I'd prefer that we take this to the list rather than decide here. This is a Big Deal to some.
20:59:17 <pbrobinson> 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 <pbrobinson> ctyler: why? So it can be discussed behind closed doors?
21:00:06 <ctyler> pbrobinson: Srsly? The list is "closed doors"?!
21:00:23 <pbrobinson> bconoboy: but it wasn't tested by the ARM guys with ARM hardware who do care about it
21:00:26 <ctyler> It's a bigger group than the half-dozen of us talking here.
21:00:42 <bconoboy> 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 <pbrobinson> ctyler: I didn't see "list" I just saw discuss elsewhere
21:01:29 <pbrobinson> 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 <bconoboy> the people who care thought it was already done, man.
21:02:10 <pbrobinson> 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 <pbrobinson> but didn't test to make sure it works
21:03:17 <pbrobinson> bconoboy: you still haven't acked whether the patch is in our gcc yet
21:03:30 <bconoboy> not aware of current gcc status.
21:03:35 <pwhalen> 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 <bconoboy> +1
21:03:48 <djdelorie> +1 to move on
21:04:03 <jcapik> +1
21:04:04 <ctyler> +1
21:04:09 <pwhalen> #topic 2) F17 Updates - status - shadowing updates
21:04:17 <pbrobinson> 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 <bconoboy> pbrobinson: Will do
21:05:07 <pbrobinson> 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 <pbrobinson> that means that the gcc needs to be building by close of play friday night
21:05:37 <ctyler> pbrobinson: -1 # You can propose that on the list.
21:06:28 <pbrobinson> 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 <ctyler> +1 on (1)
21:06:56 <bconoboy> I agree with point 1 and will follow up with the responsible parties.
21:07:36 <ctyler> #action bconoboy to follow up on list with linker name status (incl. gcc, glibc), discussion to continue there
21:08:19 <pbrobinson> 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 <pbrobinson> and this is the first time it has been bought up as a release blocker
21:09:01 <ctyler> pbrobinson: Noted, and I also really want to see us hit GA asap.
21:09:01 <pwhalen> are we currently shadowing f17-updates or are the updates getting pulled in while shadowing f18?
21:09:16 <dgilmore> pwhalen: updates are shadowed
21:09:21 <dgilmore> and going out daily
21:09:36 <djdelorie> are they showing up in the usual mirrors so "yum update" just works?
21:09:41 <dgilmore> i have noticed the images have gpgchecking and updates disabled
21:09:53 <pbrobinson> pwhalen: dgilmore reported we had 100% coverage on updates as of the weekend
21:09:56 <dgilmore> djdelorie: yes as long as you fix the repo files
21:10:13 <pwhalen> pbrobinson, missed that, thanks
21:10:26 <djdelorie> what's to fix?  Just enabling them?
21:10:42 <dgilmore> djdelorie: yes
21:10:45 <djdelorie> mine has enabled=1 and gpgcheck=1 but I'm not running one of bconoboy's images
21:10:56 <dgilmore> djdelorie: and enabling gog checking on the fedora repo
21:11:04 <dgilmore> gpg
21:13:06 <djdelorie> 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 <pbrobinson> djdelorie: can we take that to the arm channel and move on with the meeting
21:13:45 <dgilmore> statistics: {'older': 1, 'local_only': 0, 'remote_only': 90, 'same': 708, 'newer': 0, 'total_missing_builds': 1}
21:13:54 <dgilmore> thats f17-updates right now
21:14:12 <djdelorie> is there a new kernel in updates?  /me wonders if we need to document how to deal with a kernel update
21:14:28 <pbrobinson> dgilmore: does that mean we're 1 behind?
21:14:37 <dgilmore> djdelorie: there is the proposed ga kernel in updates-testing
21:14:38 <pwhalen> dgilmore, wow, awesome - so in great shape
21:14:48 <ctyler> pbrobinson: means we skipped a build
21:14:56 <djdelorie> dgilmore: which version?
21:15:08 <pbrobinson> 3.4.1-1
21:15:19 <dgilmore> newer remote: local: opus-0.9.10-1.fc17 remote: opus-0.9.14-1.fc17 with 1 build(s) missing
21:15:49 <dgilmore> some of the 90 remote only need top be built some are exlcuded
21:16:11 <dgilmore> i need to teach koji-compare to ignore excludearch packages
21:16:39 <pbrobinson> and koji-shadow :-D
21:17:03 <djdelorie> aside: we need to make sure all the pre-GA images get deleted at some point, once we have GA images
21:17:08 <dgilmore> pbrobinson: its supposed to be
21:17:47 <pwhalen> #topic 3) F17 Raspberry Pi Remix - status update
21:18:14 <djdelorie> 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 <pbrobinson> dgilmore: it's not, it submits builds that then FAIL because of no supported arches
21:18:41 <dgilmore> pbrobinson: that means the list is not right
21:18:41 <djdelorie> or do I need to switch from kernel-tegra to kernel-something-else ?
21:19:04 <dgilmore> djdelorie: rpm -qa|grep kernel
21:19:08 <pbrobinson> 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 <dgilmore> djdelorie: but in #fedora-arm
21:19:40 <dgilmore> pbrobinson: lets make sure that the list we have is current
21:19:57 <ctyler> 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 <pbrobinson> djdelorie: all the details of the kernel are on #fedora-arm can we take random user update queries there
21:20:21 <djdelorie> hopefully the rest of us will start getting RPis soon ;-)
21:20:52 <ctyler> I really want to match or beat the "Debian" image for boot speed, boot memory usage, and web browsing.
21:20:58 <djdelorie> but anyway, "yum update" did pull packages from updates and updates testing, so that works :-)
21:21:21 <pbrobinson> ctyler: is there an update on what's happening with the vouchers?
21:21:55 <pbrobinson> also is there an update of getting a more Fedora compiled kernel even if it's still using their source?
21:22:07 <ctyler> 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 <ctyler> 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 <ctyler> Upstreaming will be ugly.
21:22:55 <jcapik> ctyler: Debian has SysV, right?
21:23:09 <pbrobinson> OK, it seems its becoming a bit political because people don't know what's happening
21:23:10 <ctyler> jcapik: Upstart maybe? Not sure.
21:23:44 <djdelorie> have we gotten any requests for remixes for other platforms?  There's news of other sub-$100 arm computers...
21:24:03 <pbrobinson> 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 <ctyler> pbrobinson: yeah. I want to get this right performance-wise but need to ship soon.
21:24:52 <ctyler> pbrobinson: I have a config with ipv6, cgroups, etc. all enabled and it works well with most of the Fedora stuff
21:25:00 <pbrobinson> 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 <pbrobinson> 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 <dgilmore> indeed it looks bad for fedora in raspberry pi land
21:26:21 <dgilmore> like we are not involved or interested
21:26:50 <ctyler> 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 <ctyler> Who has boards?
21:27:23 <dgilmore> 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 <pbrobinson> 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 <jcapik> ctyler: jskarvad do
21:27:46 <dgilmore> ctyler: we just get a lot of people dropping in #fedora-arm asking for help
21:27:58 <ctyler> yeah, and it will increase fast
21:28:19 <ctyler> lmacken: I'd like to know what you're seeing
21:28:22 <pbrobinson> and it doesn't help that people are getting them before those of us supposed working on it
21:28:27 <lmacken> Jun  6 17:07:04 fedora-arm kernel: [ 2736.178115] glhanoi: page allocation failure: order:3, mode:0x4020
21:28:30 <dgilmore> ctyler: but none of the fedora developers have a board
21:28:38 <jcapik> I can ask jskarvad to help here
21:28:40 <lmacken> 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 <pbrobinson> and the worst is that there's been no status updates posted anywhere people can find out
21:28:45 <lmacken> Jun  6 17:06:56 fedora-arm kernel: [ 2728.311655] mmc0: note - long write sync 740000ns - 7495 its.
21:28:50 <ctyler> Also, there are apparently a few small differences between the beta and alpha boards, which I can't test yet.
21:28:59 <pbrobinson> lmacken: this isn't a technical meeting
21:29:33 <bconoboy> 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 <dgilmore> ctyler: we really need thouse that we gave vouchers to to get their boards
21:29:59 <ctyler> 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 <pbrobinson> ctyler: can we at least get f17 built binaries so we can ensure it's all gcc 4.7 built
21:30:12 <ctyler> dgilmore: I agree, it's been frustrating trying to get the foundation to cough them up.
21:30:38 <pbrobinson> a repo somewhere would be ideal so people that are testing can get new binaries for testing as you fix things.
21:31:50 <ctyler> pbrobinson: ok - though I'd almost rather people grab new images for now
21:32:01 <dgilmore> ctyler: there needs to be more communication
21:32:02 <pbrobinson> 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 <ctyler> pbrobinson: sorry, not following you there
21:32:38 <ctyler> ?
21:32:49 <pbrobinson> 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 <dgilmore> ctyler: developers in other distro communitiies seemed to have recieved boards
21:33:09 <dgilmore> why havent we
21:34:04 <ctyler> dgilmore: I don't know. I do know some other communities have been grumbling about not getting boards too though.
21:34:11 <pbrobinson> 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 <ctyler> 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 <pwhalen> #action ctyler to post to the Raspi community with a status report, test image by next week Monday
21:35:15 <ctyler> Otoh, my personal order with Element14 was supposed to have shipped yesterday, though UPS doesn't acknowledge the trackiing number.
21:35:19 <pbrobinson> 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 <ctyler> Will do.
21:35:35 <pwhalen> #topic 4) Device tree - should Fedora be providing it?
21:35:43 <pbrobinson> we're not done
21:36:10 <pbrobinson> 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 <dgilmore> preferably both
21:36:40 <ctyler> pbrobinson: As I said, I'm aiming for EOW.
21:36:55 <pbrobinson> excellent, I look forward to the mail to the list
21:37:19 <jcapik> 4) if it works, then yes
21:37:27 <pbrobinson> pwhalen: now for #4
21:37:31 <dgilmore> jcapik: no
21:37:47 <dgilmore> fedora should not be providing device tree blobs
21:37:55 <bconoboy> why not?
21:38:01 <dgilmore> the manufacturers of the hardware should be
21:38:09 <djdelorie> should not be, in the ideal sense?  Or should not be, in the technical-todays-status sense?
21:38:10 <pbrobinson> 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 <bconoboy> but they change with different kernels.
21:38:37 <ctyler> 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 <ctyler> We should be providing them for now.
21:38:51 <pbrobinson> 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 <ctyler> pbrobinson: yes they do :-S
21:39:13 <djdelorie> do we provide them in an RPM, or a per-board web page, or in images, or how?
21:39:34 <bconoboy> djdelorie: currently we don't at all. the question is: should we?
21:39:39 <pbrobinson> 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 <jcapik> currently there's no way to set a permanent MAC address on Pandas ...
21:39:45 <dgilmore> we shouldnt
21:40:08 <dgilmore> jcapik: and you currently cant do it via dt either
21:40:14 <bconoboy> We shouldn't have to, but there is a reason to do so.  Is the reason good enough?
21:40:15 <djdelorie> "ideal vs practical" is not an easy argument
21:40:24 <dgilmore> the patches dont apply because we never sent them upstream
21:40:29 <pbrobinson> 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 <ctyler> 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 <dgilmore> we dont have a framework to make them either
21:40:49 <pbrobinson> we still can't boot a kernel with support for different vendor SoCs
21:40:49 <jcapik> dgilmore: yup ... but that means DT doesn't work
21:40:51 <dgilmore> ctyler: no we dont
21:41:02 <bconoboy> considering the time perhaps we should table this one for next week.
21:41:03 <jcapik> dgilmore: and in that case I'm saying NO :]
21:41:13 <djdelorie> dgilmore: you keep saying that, but the alternative (eventually) is "Fedora doesn't work on my board"
21:41:22 <pbrobinson> bconboy: at the moment it doesn't provide us any major advantage
21:41:34 <djdelorie> I thought the trimslice frame buffer needed DT ?
21:41:47 <dgilmore> djdelorie: it does
21:41:50 <jcapik> dgilmore: I would rather see a kernel patch for permanent MAC
21:41:59 <pbrobinson> ctyler: we know DT is coming whether we like it or no but at the moment it's still not complete
21:42:00 <dgilmore> jcapik: patches accepted
21:42:28 <dgilmore> djdelorie: uboot on the trimslice doesnt support dt.
21:42:47 <dgilmore> djdelorie: and it needs a file that i have no idea how we can even provide
21:42:52 <pbrobinson> djdelorie: at the moment it's neither ideal or practical.
21:42:57 <dgilmore> djdelorie: that defines some edid data
21:43:14 <djdelorie> I'm thinking from the users standpoint.  "why doesn't my monitor work?" is an obvious and appropriate question
21:43:21 <pbrobinson> I believe that DT will be usable in the F-18 timeframe but at the moment it's not
21:43:44 <jcapik> yup ... it's still unusable
21:43:51 <pbrobinson> djdelorie: device tree won't fix your monitor if there's no support for it in the drivers
21:44:04 <djdelorie> the only platform that can show a desktop is qemu, and that's embarrasing.
21:44:26 <djdelorie> pbrobinson: it's upstream, we just don't have that kernel yet, but it won't work anyway without DT
21:44:27 <pbrobinson> djdelorie: for example none of the genesi stuff has monitor / lcd support. DT won't fix that. Same with tegra
21:44:49 <dgilmore> djdelorie: omap is working now also
21:44:56 <djdelorie> ah, good
21:44:57 <pbrobinson> djdelorie: SOME of it is upstream, there's still whole bits of the kernel that don't support it yet
21:45:23 <pbrobinson> djdelorie: as of 3.4.1-1 your monitor will work without device tree
21:45:32 <djdelorie> trimslice?
21:45:36 <dgilmore> djdelorie: no
21:45:45 <pbrobinson> nope, there's no patches upstream yet
21:46:04 <pbrobinson> and that's nothing to do with DT, there's no KMS driver upstream yet
21:46:05 <dgilmore> the patches for tegradrm have been sent as a rfc
21:46:39 <ctyler> There will be more and more drivers that transition to DT
21:47:05 <dgilmore> there will be
21:47:11 <pbrobinson> 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 <ctyler> 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 <pbrobinson> 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 <bconoboy> 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 <pbrobinson> bconoboy: as soon as it works I'll happily start to test it
21:48:51 <pbrobinson> but until we know it's upstream there is no point
21:48:54 <dgilmore> bconoboy: how do we make the dtb files?
21:49:04 <ctyler> dgilmore: the kernel makefile
21:49:05 <bconoboy> dgilmore: Believe you can generate them from the kernel
21:49:07 <dgilmore> bconoboy: some of them are user configurable
21:49:12 <pbrobinson> I've seen test branches from Linaro but the changes there are massive and we'll never carry them
21:49:24 <dgilmore> bconoboy: we have no framework today to do that
21:49:42 <pbrobinson> ultimately they'll need to be included in the mainline kernel
21:50:22 <pbrobinson> 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 <ctyler> I think this will be clearly needed in the f18 timeframe.
21:50:38 <bconoboy> 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 <pbrobinson> we'll likely see Panda/Beagle patches go into uboot at which point for those devices it will be easy
21:51:33 <pbrobinson> 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 <ctyler> 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 <ctyler> pbrobinson: from the conversations last week with the arm soc guy, it looks like its coming fast
21:52:15 <pbrobinson> 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 <pbrobinson> ctyler: maybe in their own branches while drinking their own coolaid or the Linaro fork everything first coolaid
21:52:46 <bconoboy> this issue is clearly too muddy to be resolved right now
21:52:58 <pwhalen> so lets revisit this at a future meeting?
21:53:04 <pbrobinson> bconoboy: exactly
21:53:09 <pwhalen> #topic 5) your topic here
21:53:10 <ctyler> actually, they pointed to highbank drivers as an example of dtb done well, iirc
21:53:47 <pbrobinson> 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 <bconoboy> /topic that took a while
21:54:03 <bconoboy> ctyler +1
21:54:04 <pwhalen> anything else before we wrap?
21:54:09 <pbrobinson> nope
21:54:12 <jcapik> +1
21:54:16 <ctyler> pbrobinson: separate zImage and DT are related but separate issues
21:54:16 <pwhalen> #endmeeting