20:00:19 #startmeeting 20:00:19 Meeting started Wed Oct 10 20:00:19 2012 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:19 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:19 #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore 20:00:19 Current chairs: bconoboy ctyler dgilmore jonmasters pbrobinson pwhalen 20:00:30 * masta waves 20:00:31 .fas pwhalen 20:00:33 .fas dmarlin 20:00:34 pwhalen: pwhalen 'Paul Whalen' 20:00:36 dmarlin: dmarlin 'David A. Marlin' 20:00:41 .fas Robert Scheck 20:00:42 rsc: robert 'Robert Scheck' 20:01:13 .fas revident 20:01:15 revident: srsullivan 'Scott Sullivan' 20:01:23 .fas blc@ 20:01:23 bconoboy: blc '' 20:01:57 * ahs3 pays attention... 20:02:09 * pbrobinson waves 20:02:19 hola 20:02:23 #topic 1) F18/19 Build status - problem packages 20:02:41 .fas jcapik 20:02:42 jcapik: jcapik 'Jaromír Cápík' 20:03:12 pbrobinson, not sure if theres anything to discuss here? 20:03:16 a few minor ones higher up the stack. Eclipse is being worked upon. Nothing of major interest. 20:03:26 Why is F19 so far behind? 20:03:27 I'm working more on the kernel 20:04:15 the kernel seems to be *the* problem package lately :( 20:04:34 bconoboy: it's not compared to a week or so ago. It's around 1400 now, it was up around 2000 so we're coming down but the reason it's taking so long is because koji is really slooooow while the raid rebuild is happening and that is still going on 20:04:49 masta: lately??? it always is :-P 20:05:04 bconoboy: the raid rebuild looks like it will go for another week 20:05:10 a week!? 20:05:12 its majorly slowing down everything 20:05:18 yes 20:05:26 how big is this array? 20:05:38 it's glacial 20:05:43 why? 20:06:02 did somebody forget to bump up the dev.raid.speed_limit_min sysctl? 20:06:03 would the raid rebuild go faster if koji-shadow were acquiesced? 20:06:04 it's a weird configuration and isn't an enterprise platform? 20:06:13 what does big mean in GB or TB and is it SW or HW raid? 20:06:48 rsc: its a weird setup ~3tb 20:06:50 TB and SW, but ultimately it's not the only considerations 20:06:50 can anybody at seneca comment on this? 20:07:08 thereis a raid0 of ssds thats setup with a raid1 to a real dis 20:07:10 disk 20:07:22 dgilmore: define weird? And why is it a SW raid? 20:07:32 the sata disk was added back in and the raid1 sync is taking a long long time 20:07:58 rsc: i just explained how its setup 20:08:32 dgilmore: why can't we use a bunch of huge disks + a powerful HW raid? 20:08:46 so it's a raid 0+1 20:09:02 So it's filesystem(raid1(raid0(ssd1,2,3,4),(spinnydisk))) 20:09:27 there is no reason this should take more than 2 days 20:09:48 bconoboy: its been going for a week 20:09:59 and has about 1 week more to go 20:10:02 did someone forget to change the BIOS to AHCI mode for the SATA? 20:10:05 rsc: basically it's historical and the reason is of no real significance and it's been discussed no end over the last couple of years 20:10:42 pbrobinson: okay. Means somebody needs to donate new HW? 20:10:53 masta: it's balanced 0+1 with reads coming from the SSD for speed but using the HDD for resilience 20:11:19 okay, let's continue this one at the end of the meeting 20:11:20 so for another week we will live with slow mode 20:11:28 nothing we can do about this 20:11:46 #topic 2) Uboot on OMAP - status update (2012.07, 2012.10) 20:12:00 masta: correct 20:12:10 it works! sorry about the misleading reports, all is fine when using the correct MLO 20:12:17 pwhalen: ok 20:12:25 #info OMAP is now working 20:12:46 nope, but we're mostly keeping up with f18 and I'm now running two rawhide koji-shadow instances and we're slowly catching up so it's not all bad, it's just the reason we're not as fast as we'd like and why there's issues with mashing and hence syncing out the latest updates to mirrors as the mash is high IO 20:13:09 not sure if there was anything else to add here. Perhaps some information on our wiki about how users would upgrade uboot as you have to do it manually, and replacing the MLO is required 20:13:09 pwhalen: please point to the test matrix showing the uboot and kernel version on which rootfs 20:13:45 For F18 won't we be providing an updated mlo/uboot for omap targets? 20:13:47 dmarlin, sounds like your referring to the device tree testing I've done 20:14:02 pwhalen: no, just for the uboot on omap 20:14:15 no such matrix 20:14:16 pwhalen: what combination is known to work 20:14:36 pwhalen: did you test with dt? 20:14:36 (tested, functional boot and usb network) 20:14:42 dmarlin, you need to use the MLO packed with that specific version of uboot 20:14:59 dgilmore, I did, no change there 20:15:30 I've tested 2012.07, 2012.10 uboots, both working 20:16:07 pwhalen: with which kernel? 20:16:07 * masta notes omapdrm is working again for hdmi/dvi. wifi needs to be tested, it was broken durring 3.4/3.5 on panda. 20:16:50 dmarlin, 3.6.0-3 20:16:55 pwhalen: thanks 20:17:37 move on? 20:17:40 I'm making an f18 image that includes uboot-panda-2012.07-0.2.rc1.fc18.armv7hl and kernel-omap-3.6.0-3.fc18.armv7hl 20:17:46 so I believe we should be using 12.10 rc as we should be releasing F18 with 12.10 final and a 3.6.x kernel 20:17:56 dmarlin: that uboot is not the latest stable uboot 20:18:12 dgilmore: it's what we have in the repo 20:18:19 dgilmore: and that's what I use 20:18:21 dgilmore: the latest isn't on the mirrrors yet I don't think. It might be in updates-testing though 20:18:35 arm-koji latest-pkg f18 uboot-tools 20:18:35 Build Tag Built by 20:18:38 ---------------------------------------- -------------------- ---------------- 20:18:40 dmarlin: we should be turning on updates-testing for an alpha release 20:18:41 uboot-tools-2012.07-1.fc18 f18 pbrobinson 20:18:52 dmarlin: its is not what should be in the repo 20:19:03 if it is thats due to the io issues in koji 20:19:14 exactly 20:19:49 dgilmore: http://alt.fedoraproject.org/pub/fedora-secondary/development/18/armhfp/os/Packages/u/ 20:20:03 pbrobinson: yeah that tree is a week old 20:20:59 dgilmore: exactly, so while 12.07 final should be there it's not because the tree on the mirrors is a week old :) 20:21:24 but it is in updates-testing. 20:21:45 dmarlin: turn on t he updates-testing repo and you'll get the right uboot 20:22:09 proposal: can we agree that for image creation we use update-testing? 20:22:30 got my +1 20:22:49 can we expect more broken images if we do? 20:22:56 (things untested) 20:23:03 masta: -1 20:23:03 for alpha releases I have no issues with using updates-testing 20:23:11 its not whats done on primary 20:23:33 but we have a process to pull builds in into a side repo on primary 20:23:40 we should pull the correct uboot in 20:24:15 so aligning to primary has more weight over pragmatic things like adding the testing repo?? 20:24:34 yes, but to at least get some images out even for testing in the short term until we can mash and actually push to mirrors I see no problem with it. call it alpha TC1 or something 20:24:49 as a test compose add updates-testing 20:24:55 but not a RC compose 20:25:06 masta: if it fails testing on primary, do we really want it in our images? 20:25:15 fair enough 20:25:18 call it alpha+updates-testing-TC1-may-kill-your-cat even 20:25:35 pbrobinson: :) 20:25:50 dmarlin: there's a lot of differences between here and primary at the moment 20:26:19 I'll take back my vote and go +0 in light of being able to test compose 20:26:23 and the package set isn't even the same as mainline alpha so the point is some what mute at this particular point in time 20:27:37 anyone have differing opinions? or all agreed? 20:27:43 pbrobinson: we do have a f18-Alpha tag thats pretty close to primary alpha 20:28:34 but im ok with whats stable today being used for alpha, lets do a TC with updates-testing enabled, then a RC when we get a completed f18 branched mash 20:28:48 dgilmore: but there's core things in there like the kernel that break that so it's still a mute point 20:29:02 dgilmore, +1 20:29:23 dgilmore: +1 20:29:36 dgilmore: +1 20:29:46 dgilmore: +1 20:29:46 and ultimately it's also a package set in the past so I don't see much point in doing massive testing against something that is old and in the past and hence not that relevant as to where we need to be aiming which is beta 20:29:48 +1 20:29:58 so this goes back to waitting a week for the repo to get happy, right? 20:30:05 pbrobinson: right 20:30:06 #info We'll use the current source base for f18arm alpha rather than the source base of primary alpha 20:30:09 #agreed release f18 alpha TC with updatse-testing enabled 20:30:17 masta: hopefully not a week 20:30:28 masta: no, if we include updates-testing while we get the mash in order it allows us to move forward 20:30:52 we can get some good testing from a TC 20:31:05 #topic 3) Reverting the Highbank alignment patch 20:31:43 I think we have upstream agreement this is the best approach in the short term while a real solution is worked out 20:31:54 so this is going into mainline later, we are doing this in in our kernel? 20:32:52 reverting the patch in our kernel, is my understanding... jonmasters ? 20:33:21 can somebody tell me like I'm five, what is the impact of this? 20:34:12 masta: a recent patch exposed a latent bug (missalignment)... this patch reverts it until the bug can be fixed 20:34:14 dmarlin: what upstream agreement, no one has managed to point me to that discussion so I can see the agreement 20:35:05 masta: me too because I don't yet see any discussion about it and what the problem is, just a non upstreamed patch thrown at me and being told to apply it. 20:35:20 pbrobinson: I think you were cc'd on several emails showing buy-in from the parties involved 20:35:51 I need to see the upstream discussion so I can reference it rather than a random "Yes, this is the agreement of upstream I promise" 20:36:21 looks like jcm is posting to g+ durring this meeting, can somebody bump him out of band to join the discussion? 20:36:32 pbrobinson: I think you're saying you need to be able to reference a public discussion so third parties can look and see? 20:36:34 dmarlin: a closed email with responses from just you and jon is not an upstream discussion with buy in from the mainline kernel maintainers 20:37:13 bconoboy: exactly 20:37:22 oh wait, is this the IPv6 thing? 20:37:23 bconoboy: yes, a public mailing list discussion, that's what I mean by upstream mailing list referenced discussions 20:38:52 preetty sure jonmasters is on his way to the airport 20:39:09 perhaps somebody who has been on this private email thread would ask the others to take it public? 20:39:53 bconoboy: sure, I'll follow up 20:40:29 #info dmarlin to ask kernel maintainers to publicly support reverting a patch that is causing issues 20:40:33 #unfo 20:40:35 #undo 20:40:35 Removing item from minutes: 20:40:41 #action dmarlin to ask kernel maintainers to publicly support reverting a patch that is causing issues 20:40:45 bconoboy: the indications from jonmasters is that the discussion has happened, I haven't seen it, I have no idea which of the dozen kernel mailing lists it could have occurred on to even begin to search if I had the time to actually troll the lists 20:41:11 I think the mailing list item may have been posted in channel on Friday 20:41:18 pbrobinson: Right- once we have a pointer for you and there is public consensus, we're all set from your standpoint though, yes? 20:41:51 would be nice to write the link to whatever list in the comment for this revert... so we can know WTF 20:42:18 just saying 20:42:31 bconoboy: yes 20:42:55 pwhalen: do you have a link to that? 20:43:00 * dmarlin does not have that log 20:43:05 #info Once public consensus is to revert patch, pbrobinson will pull it in 20:43:20 bconoboy: like with the sata patch which I pulled from mainline once it was there I don't have a problem with it 20:43:23 no, scrollback doesnt go that far, looked back 20:43:27 bconoboy: define "public consensus" 20:43:34 even just an upstream commit reverting it is fine 20:43:41 well it's better than nothing 20:44:02 alright, next.. 20:44:05 #topic 4) Device tree testing 20:44:11 something showing its the upstream direction 20:44:30 #link http://fedoraproject.org/wiki/Architectures/ARM/Quality_Assurance/Device_Tree_testing#Fedora_18 20:45:14 theres the results of my testing so far, very interested to see what happens in 3.7. So far only vexpress has been booted successfully 20:45:15 so vexpress works? 20:45:26 so device tree versus vendor provided u-boot : fight! 20:45:31 bconoboy, it does, but just including the dtb 20:45:39 masta: no 20:45:42 s/but/by/ 20:45:44 pwhalen: You mean appending the dtb to the image? 20:46:15 no, by just passing it to qemu. 20:46:41 I have not tried appending yet, on any platform 20:46:42 oh, as a flag. got it. 20:46:51 I tried appending it on my trimslice. No go. 20:46:57 pwhalen: do we know if the kernel does anything with device tree on vexpress? 20:47:09 I believe the new trimslice uboot does the 3rd load addr thing, was hoping to setup a test doing that. 20:47:20 (actually uses it) 20:47:26 I tried the new uboot with dgilmore's trimslice dtb. Also fails. 20:47:29 when pbrobinson built 3.6 he mentioned enabling some bits specifically for vexpress 20:47:40 Fails appended. Fails loaded separately and passed as a parameter. The system does not boot at all. 20:47:55 this was with 3.6.0-1 20:47:59 pwhalen: I've enabled a lot of DT stuff all over, not just vexpress. 20:48:02 Are we sure that dtb support is built into the kernels? 20:48:23 pwhalen: have you tested device tree on panda with the matching MLO and uboot as yet? 20:48:25 pbrobinson, okay, you specifically were interested in vexpress though. 20:48:31 Last week we thought MMC support was built in and it wasn't, so I'm wondering if it's the same thing here. 20:48:41 pwhalen: I'm interested in all of them ;-) 20:48:44 pbrobinson, I did, no change when using the correct combo of MLO and uboot 20:49:07 * pbrobinson is looking for a page he has about DT on panda for reference 20:49:54 http://www.digipedia.pl/usenet/thread/19013/27691/ 20:50:21 it says we need this: 20:50:21 + select USE_OF 20:50:21 + select ARM_APPENDED_DTB 20:50:21 + select ARM_ATAG_DTB_COMPAT 20:50:21 + select PROC_DEVICETREE 20:50:41 which I've enabled on the omap kernels (in fact in all arm kernels) 20:50:58 but that might be a reasonable start for others to look at as well 20:51:10 dgilmore, mentioned that dt was default on omap as well 20:52:00 pwhalen: yes the kernel enables both DT and board file support when you enable a SOC 20:52:22 there was not specific SOC DT config options 20:52:49 (Sorry about the late appearance. The team had some Seneca business we had to deal with) 20:52:52 pbrobinson: How recently were those options turned on? 20:53:07 pbrobinson: nice link 20:53:24 (I just checked the config for the 3.6.1-1 tegra kernel and those options are indeed turned on) 20:53:57 bconoboy: when I cross checked most of them had been there for a while. They were all most definitely in the 3.6 final 20:54:32 Okay, I'll double check with this version. 20:54:46 so that's one of the better "DT for dummies" I've managed to find to date, most of the DT stuff is for kernel developers, not end users 20:55:56 * masta will spend the next week hacking DT on panda/trimslice 20:56:14 masta++ 20:56:31 CONFIG_MACH_TEGRA_DT=y, CONFIG_MACH_OMAP_DT=y are missing from the configs in boot, yet they appear in the fedora configs. 20:56:58 those look important 20:57:37 * pbrobinson will check the generation/inheritance for that tehn 20:57:39 then 20:58:10 #action pbrobinson to check kernel config to ensure all necessary _DT options are turned on 20:58:41 pbrobinson, thank 20:58:45 thanks 20:58:57 #topic 5) Raspberry Pi status update 20:59:08 pbrobinson: thanks in advance for checking on those DT options 20:59:11 [dennis@adria kernel (f18)]$ grep -r CONFIG_MACH_OMAP_DT kernel-3.6.fc18/linux-3.6.0-3.fc18.x86_64/ 20:59:15 [dennis@adria kernel (f18)]$ 20:59:49 We're fixing up some issues in a couple of the educational packages we're shipping in the remix 21:00:25 frojoe: Is there going to be a final f17 remix? 21:00:28 And we're gearing up for release very soon. I don't have word on what the consensus is 21:00:30 Frojoe: ETA? I'm seriously getting sick of A) lack of updates B) being asked when it's going to be released 21:01:15 Frojoe: release early, release often :) 21:01:16 pbrobinson: indeed, open communications are a must 21:01:19 Frojoe: this week? Month? before F-18 mainline? This year? I've been hearing "soon" for a long time 21:01:39 As I said, I'm out of the loop when it comes to that decision. Before the end of the month to be sure 21:01:53 frojoe: whose decision is it? 21:01:56 Frojoe: so who is in the loop? 21:02:02 and why aren't they here? 21:02:19 I think it is Ctyler who has final say 21:02:20 Frojoe: there needs to be posted a list of release blockers, and frequent updates on them, i.e. daily 21:02:43 sorry to push but this is getting very embarrassing. There's been no updates to the list and F-17 has been stable for a long time now 21:02:56 Alright. I will pass that on to the team. I want to get this thing out the door sooner rather than later 21:03:06 Frojoe: :) 21:03:32 The one thing I can say for sure is that we want it out the door before FSOSS on the 25th I believe 21:03:37 Frojoe: all the armv6hl work should now be happening on f18 or even rawhide, release f17 on armv5tel and move on 21:03:46 ok, we're past the hour and have another item to discuss, is there any other update? 21:03:57 nope 21:03:58 pbrobinson, fossjon is working hard on v6 stuff 21:04:02 I will get him to email the list 21:04:06 pwhalen: plz move ahead 21:04:20 Frojoe, is that f18 v6 or f17? 21:04:57 #topic 6) Discussion on dropping Kirkwood support 21:05:07 From what I understand, we're working on a v6 f17 package set 21:05:19 We have another koji set up to koji-shadow ours for f18 packages 21:05:32 heated on the list, but bconoboy's last email summed it up well I think 21:05:36 pwhalen: i think that as arm moves primary armv5tel should stay secondary 21:05:40 Frojoe, thanks 21:05:54 dgilmore, +1 21:06:04 dgilmore: +1 21:06:08 does anybody here want to keep on with armv5tel maintenance? 21:06:19 pwhalen: once I clarified with jonmasters he confirmed that in the short term he was talking about support blocking a release if it doesn't work for alpha etc for the F-18 release 21:06:24 dgilmore: +1 21:06:37 I confirmed with him that kirkwood had never blocked the relase 21:06:42 poor little armv5tel :] 21:06:59 bconoboy: never want to troubleshoot glibc atomics again, mind numbing 21:07:09 so for F-18 lets leave it at that for the moment, and leave discussions about Primary support for later 21:07:13 dgilmore: I don't agree it should be part of primary push, rather it should be part of moving to PHX, which may happen before primary push. 21:07:34 bconoboy: we are not moving anything to PHX 21:07:47 pardon? 21:07:50 bconoboy: koji will stay where it is. 21:07:54 bconoboy: we don't even have hardware yet so it's a mute discussion at the moment 21:08:09 pbrobinson: now that is true 21:08:10 bconoboy: we will add builders in phx to primary koji as part of the move to primary 21:08:32 lets keep on topic please, we're over time 21:08:33 bconoboy: thats been my plan all along 21:08:47 right, revisit this one later 21:08:52 but yes there is little to nothing to discuss right now 21:09:11 dgilmore: exactly so why are you still doing so ;-) 21:09:19 pbrobinson: i stopped 21:09:51 I would like to keep kirkwood around, but that is out of self interest and I'll admit I don't have the skill set for the package maintenance folks are highlighting. 21:10:05 right, so for F-18 kirkwood won't block release as was the case in F-17 (which I believe was just omap and vexpress, maybe tegra that where classed as "supported" ) 21:10:27 pbrobinson: indeed 21:10:39 so we'll keep the kirkwood kernel but it will need community testing and assistance regarding kernel support 21:11:00 yes 21:11:02 pbrobinson, right, to date its been hard to get kirkwood tested 21:11:32 so if people want to keep kirkwood around they need to step up to prove how much they love it 21:11:33 leave this one on the list? 21:11:55 rather than just lip service on the list 21:11:56 We have a ton of guruplugs that are collecting dust now. We could maybe devote a couple to kirkwood stuff. 21:11:57 pwhalen: maybe just to check if people have stepped up to help 21:12:01 * revident has been trying to crack that, but it's a spare time project and is not yet there 21:12:42 #topic 7) Your topic here 21:13:14 * dgilmore just wants to say ill see whoever is at fudcon on the weekend 21:13:22 we've gone late, and its even later for others.. 21:13:33 revident: my time on ARM is my own time and I don't have kirkwood devices nor the time or interest if I had them so people that have them and want them supported need to at least test them 21:13:43 post midnight here 21:13:47 night all 21:13:48 one item is a VFAD, once we produce a test image, then we'll send something out on the list as to when we should do it 21:13:55 night pb 21:14:05 pwhalen: Think we'll be ready by friday? 21:14:15 g'night pbr 21:14:22 bconoboy, possible, will be testing images tonight, so we should know tomorrow where we stand 21:14:34 friday sounds reasonable, dmarlin ? 21:14:47 pwhalen: if the test images all check out 21:15:02 * dgilmore needs to go afk also 21:15:04 adios 21:15:08 these are the test images with updates-testing? 21:15:17 c.u. 21:15:25 dgilmore: good night 21:15:31 pwhalen: Friday might be too ambitious. Let's see where we are tomorrow. 21:15:42 masta: no, just what's in development 21:15:50 masta: they were created before this meeting 21:16:01 masta: we just need to verify them 21:16:02 dmarlin: count on me to help 21:16:03 okay, I'll email the list with the plan tomorrow 21:16:13 thanks pwhalen 21:16:22 anything else folks? 21:16:36 #endmeeting