20:00:42 <pwhalen> #startmeeting Fedora ARM weekly status meeting 20:00:42 <zodbot> Meeting started Wed Sep 11 20:00:42 2013 UTC. The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:43 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore dmarlin masta handsome_pirate msalter ahs3 agreene jcapik ddd 20:00:43 <zodbot> Current chairs: agreene ahs3 bconoboy ctyler ddd dgilmore dmarlin handsome_pirate jcapik jonmasters masta msalter pbrobinson pwhalen 20:00:50 <pwhalen> .fas pwhalen 20:00:50 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com> 20:00:52 <bconoboy> .fas blc@ 20:00:53 <zodbot> bconoboy: blc '' <blc@redhat.com> 20:00:58 <dmarlin_away> .fas dmarlin 20:00:59 <masta> howdy 20:00:59 <zodbot> dmarlin_away: dmarlin 'David A. Marlin' <dmarlin@redhat.com> 20:01:01 <pwhalen> afternoon folks 20:01:39 <jcapik> .fas jcapik 20:01:39 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com> 20:01:46 <ahs3> .fas ahs3 20:01:47 <zodbot> ahs3: ahs3 'Al Stone' <ahs3@redhat.com> 20:02:46 <pwhalen> lets get started 20:02:49 <pwhalen> #topic 1) Kernel Status Update 20:03:23 * jwb pays attention for a bit 20:03:57 <hrw> hi 20:04:07 <kylem> so... things are looking better. 20:04:23 <kylem> trimslice is working again. unfortunately we've had a regression with vexpress/qemu. 20:04:47 <kylem> between 3.10.0-3 and 3.10.0-300... which means the culprit right now is the beaglebone black enablement patches. 20:04:57 <kylem> i'm working on that now. 20:04:58 <jwb> er, 3.11? 20:05:02 <kylem> yea, 3.11 20:05:23 <jwb> so the -300 build was done explicitly for BBB, rigth? 20:05:29 <kylem> given BBB doesn't have network, i don't know whether we should revert those for alpha, if they indeed do break vexpress 20:05:53 <dgilmore> jwb: BBB and trimslice pcie 20:05:55 <kylem> no, -300 was done to fix trimslice (CONFIG_PCIEPORT) the BBB stuff was just a sideeffect. 20:06:12 <dgilmore> what kylem said 20:06:15 <jwb> ah, ok. so the people that gave it karma... what was it tested on? 20:06:27 <jwb> i thought qemu was basically the only Alpha blocker "hw" 20:06:30 <dgilmore> trimslice 20:06:39 <pwhalen> #info kernel-3.11.0-300.fc20 - trimslice PCIe fixed, regression on vexpress 20:06:58 <pwhalen> jwb tested on trimslice, highbank, beaglebone 20:07:12 <jwb> did anyone test it on qemu? 20:07:23 <bconoboy> qemu was rejected as an alpha blocker because it wasn't real hardware- the determination was highbank + 1 common board (like trimslice) 20:07:42 <kylem> i'd suggest we test a revert of the BBB patches and if that fixes it, until we get networking or USB sorted. 20:08:03 <jwb> bconoboy, ah, i see. i missed that change. was that recent? 20:08:50 <bconoboy> jwb: last week, I think 20:09:06 <bconoboy> kylem: works for me 20:09:18 <jwb> kylem, so a revert would be good to test, but to get it in Alpha would require a bug that gets exception status 20:09:19 <pwhalen> this was discussed last week at the QA and FESCo meeting, highbank+1 hw platform 20:09:35 <jwb> and if qemu isn't a blocker, i don't see how it would get into Alpha at this point 20:09:44 <kylem> then that's fine with me. 20:09:49 <hrw> jwb: so revert, test outside of repo and once it works upload to repo? 20:09:57 <jwb> hrw, it doesn't work like that 20:09:59 <kylem> qemu needs you to fish the kernel+initrd out anyway, since we don't have u-boot there. 20:10:09 <kylem> so there's not really a problem using a post-alpha kernel for it. 20:10:17 <kylem> aside from defeating the purpose of testing alpha directl. 20:10:24 <bconoboy> jwb: suffice it to say, this is probably a post-alpha release targetted discussion 20:10:44 <jwb> bconoboy, sure. i was unaware the targets had changed within a week 20:11:01 <jwb> i do have another question/topic on this for later though 20:11:07 <jwb> but i don't want to hold up your meeting 20:11:07 <bconoboy> ok 20:11:27 <hrw> jwb: that's ~what I would do. out-of-repo changes + local tests and once get it working - upload. for me it sounds like normal change workflow 20:11:46 <pwhalen> any other kernel woes to discuss? 20:11:46 <kylem> ok. so that sounds like: no revert for now, but to test one. not worry about vexpress for alpha? 20:11:51 <jwb> hrw, our repos don't work like that 20:11:57 <jwb> hrw, in freeze mode 20:12:17 <bconoboy> kylem: y, think so 20:12:22 <hrw> jwb: ok, s/upload/get Freeze exception and upload/ 20:12:27 <kylem> sounds good to me. 20:12:57 <jwb> hrw, we can come back to this later. as i already said, i doubt you'd get FE 20:13:00 <hrw> sure 20:13:02 <pwhalen> #topic 2a) Aarch64 - Status Update 20:13:30 <bconoboy> Current status: 12077/13606 built 20:13:44 <bconoboy> New successes have slowed to a trickle 20:14:03 <bconoboy> hrw is working on qt, which will unlock kde, and a few hundred other packages will fall out from that 20:14:18 <bconoboy> everything else will come from fixing failures in f19, or simply moving on to f20 where fixes might already be in place. 20:14:28 <pwhalen> the queue was empty this morning when I checked on the builders, anything to requeue? 20:14:53 <kylem> pwhalen, handsome_pirate was mentioning one package earlier on #fedora-arm. 20:14:53 <bconoboy> If we requeued all the failures we'd probably get a few more successes since some dependencies have filled in 20:15:12 <bconoboy> Overall though, that's just fighting for scraps. We really need to move to F20. 20:15:34 <hrw> bconoboy: exactly. requeue of f19 would be waste of time 20:15:36 <pwhalen> bconoboy, it looked like about half the builders were idle-ish this morning 20:15:57 <bconoboy> The only new packages getting queued are those from f19 updates 20:16:21 <bconoboy> but if the same package gets updated, that doesn't increase my package success count since it was already built previously. 20:16:42 <pwhalen> if we're talking f20, we'll move to the next topic, koji.. 20:16:47 <bconoboy> :-) 20:16:49 <pwhalen> #topic 2b) Aarch64 - Koji 20:16:53 <bconoboy> nirik: ping 20:19:03 <bconoboy> ping dgilmore? 20:19:16 <dgilmore> bconoboy: 20:20:41 <bconoboy> ? 20:21:41 <bconoboy> sorry, network died at "<dgilmore> bconoboy:" 20:21:55 <hrw> I have a fix for lua ;D 20:21:58 <pwhalen> thats all we got as well 20:21:59 <dgilmore> bconoboy: i don't have anything to add 20:22:10 <bconoboy> ok 20:22:37 <pwhalen> ok, we'll come back if nirik is around 20:22:50 <pwhalen> #topic 3) Fedora 20 Alpha RC1 20:22:50 <pwhalen> #link https://dl.fedoraproject.org/pub/alt/stage/20-Alpha-RC1/Images/armhfp/ 20:22:53 <hrw> msalter was faster 20:23:37 <pwhalen> #info RC1 images have been posted, please help test, add findings to the wiki, file bugs 20:23:37 <bconoboy> I'm testing RC1 on my trimslice now to see what happens with konquerer 20:23:43 <pwhalen> bconoboy, thanks! 20:24:29 <bconoboy> Guys, if you have a supported device, please test RC1. Thusfar pwhalen has been doing just about all the testing. Needs a group effort. 20:24:29 <pwhalen> I sent a list of bugs to the list last night, ideally if you could test to see if those have been fixed 20:24:45 <bconoboy> #info Please test RC1 if you have a supported device 20:25:38 <bconoboy> I'd be interested to know how beaglebone black does with an ethernet or wifi dongle 20:26:01 <kylem> bconoboy, i don't think usb is expected to work right now. 20:26:06 <pwhalen> no usb 20:26:11 <kylem> so... no networking period. : 20:26:12 <kylem> :/ 20:26:13 <bconoboy> oh, lame. well, that answers that 20:26:35 <bconoboy> beagleboard xm? :-) 20:26:36 <hrw> kylem: sdio wifi then ;D 20:27:20 <bconoboy> moving on? 20:27:25 <pwhalen> i dont know who has the bbxm myself.. sure 20:27:38 <pwhalen> #topic 4) Weekly Status Meeting 20:27:47 <hrw> pwhalen: I only have original bb (b7 and c3) 20:28:02 <dgilmore> hrw: i think mine is a b6 20:28:07 <bconoboy> hrw: might work 20:28:19 <dgilmore> it worked last i tested 20:28:28 <bconoboy> Back to topic... 20:28:44 <pwhalen> with arm moving into PA and many of issues now being dealt with in blocker bug meetings, qa meetings.. and with varying schedules, does it make sense to have a weekly arm meeting? 20:28:47 <dgilmore> bconoboy: which is ? 20:29:10 <pwhalen> should it be changed to bi weekly? or? 20:29:15 <dgilmore> pwhalen: maybe fortnightly 20:29:51 <pwhalen> I'd be okay with that myself if it makes sense, other thoughts? 20:30:14 <bconoboy> If we drop this one I'd like us regulars to commit to attending at least one of the others that takes place for PA 20:30:14 <hrw> I can't comment - it is my second meeting 20:30:53 <masta> I'd kinda like to keep the meeting 20:31:02 <masta> but I mostly lurk 20:31:08 * nirik is back now... 20:31:18 <jcapik> we still have aarch64 :) 20:31:29 <bconoboy> the thing that concerns me is that by maintaining the arm meeting we're holding ourselves separate from main fedora 20:32:01 <jcapik> the meeting can take just minutes 20:32:05 <masta> well jcapik makes a good point that aarch64 will still be a secondary arch 20:32:06 <jcapik> 30 20:32:11 <bconoboy> we do have aarch64, but it's very early days there 20:32:23 <dgilmore> I think we still need a somewhat regular meeting for planning Features and enhancements, working on defining how things should work. seeing how well we can test and support new platforms etc 20:32:39 <jwb> bconoboy, i think that's a good concern to have! however, arm seems to be a rather... unstable world at the moment and the other meetings aren't necessarily the venue to discuss all that 20:32:55 <bconoboy> sounds like fortnightly might be the best option 20:33:07 <jwb> bconoboy, i do think more integration with the other meetings from ARM people is great 20:33:18 <pwhalen> we can always come back to this if we find its not working 20:33:25 <dgilmore> we do need to integrate better 20:33:32 <jcapik> lets do that the way we did it in the past ..... if we have not enough stuff to be discussed, the meeting can be cancelled 20:33:41 <dgilmore> but we also need our own plans and roadmaps 20:34:03 <ahs3> so almost like a SIG or something... 20:34:36 <kylem> i prefer my schedule to be predictable... so it'd be nice to know well in advance if i'm needed. 20:34:37 <dgilmore> ahs3: yes ARM SIG 20:35:55 <pwhalen> should we vote here? I see some differing opinions 20:36:22 <dgilmore> pwhalen: sure 20:36:59 <pwhalen> #proposed Move the weekly ARM status meeting to biweekly 20:37:11 <pwhalen> +1 20:37:16 <dmarlin> +1 20:37:32 <bconoboy> +1 20:37:38 <masta> +0 20:37:59 <dgilmore> +1 20:38:09 <hrw> +0 20:38:19 <ahs3> +1 20:38:33 <jcapik> it seems it's decided already 20:38:45 <bconoboy> we can still add or subtract meetings as needed 20:38:59 <pwhalen> agreed 20:39:15 <bconoboy> So, next week on or off? 20:39:32 <pwhalen> #agreed Fedora ARM Weekly status meeting moving to a biweekly schedule, to be re-evaluated as needed. 20:39:53 <dgilmore> pwhalen: next meeting in two weeks 20:40:16 <pwhalen> #info next Fedora ARM meeting - 2013-09-25 20:40:35 <pwhalen> sound good? 20:40:43 <dgilmore> si 20:40:46 <pwhalen> #topic 5) Open Floor 20:40:49 <jcapik> ano 20:40:53 <kylem> so. 20:40:55 <hrw> fine for me 20:40:58 <pwhalen> :) 20:41:05 <dgilmore> kylem: ? 20:41:10 <pwhalen> jwb, you had something for open floor I believe 20:41:12 <kylem> binutils wasn't generating hardfloat flags in the elf flags for libraries/binaries for a while 20:41:19 <jwb> pwhalen, i'll go after kylem 20:41:22 <pwhalen> sorry, thanks 20:41:22 <dgilmore> kylem: uggh 20:41:43 <kylem> i've fixed binutils... but it means ldconfig is going to complain on upgrades if there's libraries without the flag set. 20:41:44 <masta> kylem: sounds bad 20:41:52 <dgilmore> kylem: do we know whats effected? and do we need a mass build to fix? 20:42:01 <kylem> i don't *think* there's any cases where we haven't hardcoded hardfloat. 20:42:10 <kylem> so we shouldn't have actual link problems because o fit. 20:42:24 <dgilmore> ok, so just noise 20:42:30 <kylem> not sure what we want to do here. 20:42:32 <kylem> yeah. 20:42:38 <jwb> upgrades from what? f19? 20:42:41 <kylem> yes. 20:42:49 <kylem> f19 has the flags set, f20 didn't until recently 20:43:02 <jwb> how long is "a while"? 20:43:14 <kylem> binutils-2.23.88.0.1-13.fc20 20:43:19 <kylem> anything built with binutils before that 20:43:33 <dgilmore> kylem: when did it break? 20:43:41 <bconoboy> regular, verbose warnings are pretty annoying. can we disable until the next mass rebuild? 20:43:56 <kylem> bconoboy, i don't believe we're planning one for f20 at the moment 20:44:09 <bconoboy> yeah, I'm thinking f21 20:44:13 <kylem> dgilmore, sec. 20:44:13 <dgilmore> next mass rebuild would be f21 or later 20:44:29 <jwb> does ARM adhere to the upgrade criteria for release? 20:44:42 <kylem> commit 7a3406881d88013bcd6a9fdede74c8933058be17 20:44:42 <kylem> Author: Nick Clifton <nickc@redhat.com> 20:44:42 <kylem> Date: Thu Apr 25 16:28:02 2013 +0100 20:44:42 <kylem> Switch over to basing sources on the official FSF binutils releases. 20:44:51 <kylem> it broke around then. 20:44:58 <kylem> so everything in the mass rebuild is missing the flags. 20:45:02 <jwb> that's a lot of packages. 20:45:19 <kylem> i'm pretty sure it'll just be a ldconfig whinge on every library upgrade 20:45:37 <bconoboy> that is a lot of whinging 20:46:17 <kylem> sure is. :/ 20:46:36 <kylem> heh. 20:47:00 <kylem> i could add a hack to ldconfig to not warn if it was the float flag missing. 20:47:08 <kylem> and revert it later. 20:47:11 <dgilmore> jwb: we do need to support upgrades. I know f17 to f18 we didnt 20:47:16 <kylem> if the tools guys didn't murder me brutally. 20:47:16 <bconoboy> should probably consult with jakub or carlos 20:47:44 <kylem> indeed. 20:47:55 <bconoboy> kylem: if you file a BZ for the issue we can have carlos work with us to form a plan 20:48:11 <kylem> will do. 20:48:29 <bconoboy> tnx 20:49:02 <bconoboy> kylem: that it? 20:49:09 <kylem> from me, yeah 20:49:28 * nirik has a short aarch64 koji update... (after jwb is done) 20:49:29 <bconoboy> #info ldconfig will be showing warnings in f20 due to binutils bug, bz to be filed and glibc dev consulted 20:49:47 <bconoboy> jwb? 20:50:59 <jcapik> nirik: :] ? 20:51:16 <jwb> i wanted to talk about kernel patches briefly 20:51:33 <dgilmore> jwb: okay 20:51:50 <jwb> i realize new shiny hardware is fun and i'm sure the patches being added are tested on the devices they're added for. however, they're starting to cause pain now 20:52:13 <jwb> in rawhide, they're a pain because it's constantly rebasing. and tbh, is anyone here testing rawhide kernels? 20:52:26 <pwhalen> jwb, yes 20:52:29 <jwb> now with F20, the BBB patches are starting to look like they've broken qeme 20:52:32 <jwb> er, qemu 20:52:35 <dgilmore> jwb: i test rawhide kernels at times 20:52:57 <jwb> but 20:53:20 <jwb> the overall issue here is that i don't even get a heads up before they're slammed in there. they just show up in git without any communication 20:53:42 <jwb> and they are often stuff taht isn't headed upstream until linux-next-next 20:53:49 <jwb> so we have to carry and rebase them 20:53:55 <jwb> that can't continue 20:54:07 <bconoboy> jwb: what do you propose? 20:54:17 <jwb> post the patches to the kernel list like everyone else 20:54:26 <jwb> with what you've tested it on, and what the upstream status is 20:54:31 <jwb> or file a bug 20:54:48 <dgilmore> thats reasonable 20:55:01 <masta> maybe we need some kind of continous integrated testing system... patches go in... all the arm boards reboot with that kernel. 20:55:01 <jwb> in the past, this wasn't as big of an issue because i could just ignore ARM as long as it prepped ok 20:55:18 <hrw> masta: lava farm? 20:55:23 <masta> hrw: exactly 20:55:26 <jwb> but now with ARM holding up builds everywhere, it needs to improve 20:56:01 <hrw> jwb: +1 20:56:14 <jwb> if it doesn't improve, i'll have to resort to reverting 20:56:35 <masta> posting patches to the list seems good 20:56:52 <dmarlin> jwb: how is this to be implemented/enforced? 20:56:59 <dmarlin> jwb: just posted as policy? 20:57:10 <jwb> dmarlin, um... i just said i'd revert 20:57:16 <jwb> pretty sure that's enforcment 20:57:19 <kylem> given there's only 3 people who can do kernel builds, i assume he'll revert it before he builds. ;-) 20:57:37 <dgilmore> kylem: there is 5 people i think but yeah 20:57:54 <jwb> this doesn't need to be a huge big process. this needs to be simple maintainer courtesy and actual cooperation 20:58:10 <dgilmore> jwb: which is totally reasonable 20:58:13 <dmarlin> so just an 'understanding' within the goupd of 5 20:58:16 <dmarlin> group 20:58:19 <jwb> so if you don't want to email a list, open a bug and post links. i don't care. just don't slam out-of-tree patches into the kernel with no heads up at all 20:58:27 <masta> ok so we propose patches to the list, test, test... test.. ACK, commit? 20:58:28 <jwb> dmarlin, no, 5 people can build. many can commit 20:58:38 <jwb> and i don't want to limit committers 20:59:05 <dmarlin> jwb: ok, then will there be a published policy, or guidline, or how will people all know? 20:59:06 <hrw> masta: propose patches, reply with boot status 20:59:17 * jwb sighs 20:59:41 <jwb> dmarlin, that's why i'm discussing this now? 21:00:03 <jwb> i'm sure i'll have to politely remind people occassionally 21:00:10 <dmarlin> ok 21:00:12 <jwb> also, it's just common decency 21:00:19 <bconoboy> jwb: are all the parties you're concerned about here? IE, please send a private note to any guilty party. 21:00:47 <jwb> sure 21:00:50 <masta> jwb: I'm sry we have caused you some grief... we will improve, thanks for letting us know 21:01:24 <jwb> like i said, i'm not trying to make a big deal about this. in the past, it was fine because it only broke you guys 21:01:34 <jwb> but now you got what you asked for, and it breaks more than just you now :) 21:01:37 <jwb> welcome to PA 21:01:58 <pwhalen> :) 21:02:01 <hrw> ;) 21:02:04 <pwhalen> anything else for open floor? 21:02:07 <jwb> ok, i need to run. thanks for listening 21:02:11 <pwhalen> thanks jwb 21:02:16 <hrw> nirik wanted something 21:02:16 <bconoboy> nirik? 21:02:18 <masta> I think nirik has something 21:02:19 <nirik> so, I have been working some on ansible playbooks for aarch64 koji. I'll likely commit what I have so far soon and see if I can bring it up. There's a bug in the postgresql db permissions thing in ansible, so I might do permissions and such manually for now. As soon as the base thing is up I will likely bug others to help setup tags/targets/etc and get it talking to builders. 21:02:48 <bconoboy> #agreed ARM Kernel patch submitters are asked to send the patches they apply to the mailing list prior to checkin, including their tested status. 21:02:48 <hrw> cool 21:03:11 <bconoboy> nirik: great! that a this week timeframe thing? 21:03:21 <nirik> bconoboy: I hope so, barring fires. 21:03:40 * bconoboy set aside his arsonist ways... for now. 21:03:51 <nirik> :) 21:04:20 <nirik> thats all... ;) 21:04:33 <bconoboy> #info Nirik making progress on aarch64 koji server setup. May be ready for testing this week, barring distractions 21:04:41 <nirik> (well, I have a beagleboneblack I'd like to run rawhide on, but thats another subject. ;) 21:04:52 <bconoboy> it'll run today, if you don't need a network connection... 21:05:26 <nirik> net would be nice, but perhaps I can get by with just usb? 21:05:34 <hrw> I do wonder how many patches does Koen Kooi from Angstrom uses to get BBB with 3.12 (if he went there already) 21:05:39 <pwhalen> no usb :( 21:05:49 <nirik> oh well, it will get there. ;) 21:05:58 <bconoboy> hopefully in time for beta 21:06:00 <pwhalen> hey, it boots :) 21:06:28 <pwhalen> last call for open floor 21:06:52 <pwhalen> remember, two weeks until we meet again 21:07:16 <pwhalen> #endmeeting