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