20:02:26 <bconoboy> #startmeeting Fedora ARM weekly status meeting
20:02:26 <zodbot> Meeting started Wed Jul 10 20:02:26 2013 UTC.  The chair is bconoboy. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:02:37 <bconoboy> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore dmarlin masta j_dulaney msalter ahs3 agreene jcapik ddd
20:02:37 <zodbot> Current chairs: agreene ahs3 bconoboy ctyler ddd dgilmore dmarlin j_dulaney jcapik jonmasters masta msalter pbrobinson pwhalen
20:02:52 <jcapik> .fas jcapik
20:02:52 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:02:56 <bconoboy> .fas blc@
20:02:57 <zodbot> bconoboy: blc '' <blc@redhat.com>
20:03:04 * nirik is around, has some stuff for open floor or whatever.
20:03:16 <bconoboy> We didn't have any actions from last week (canceled meeting), so straight on to #1
20:03:19 <handsome_pirate> .fas jdulaney
20:03:20 <zodbot> handsome_pirate: jdulaney 'John Dulaney' <j_dulaney@live.com>
20:03:25 <bconoboy> #topic 1) Problem packages
20:03:33 * masta is here
20:03:39 <bconoboy> dgilmore: have anything?
20:05:01 <bconoboy> #info per arm@lists.fp.o, llvm needs love
20:05:30 <handsome_pirate> bconoboy:  Didn't see that one
20:05:47 <handsome_pirate> bconoboy:  I'll look into it
20:05:49 <bconoboy> handsome_pirate: It's been an issue for more than a year
20:05:56 <handsome_pirate> bconoboy:  Ah
20:05:58 <bconoboy> handsome_pirate: Need a pointer?
20:06:03 <handsome_pirate> bconoboy:  Sure
20:06:07 <bconoboy> Sec...
20:07:18 <bconoboy> Hmmm I don't have a pointer handy where I thought I did.  Does somebody else?
20:08:23 <handsome_pirate> bconoboy: Ping me later, maybe?  jdulaney@fp.o
20:08:28 <bconoboy> Will do
20:08:46 <bconoboy> #link Ghostscript broken on arm in both f20 and f19: https://bugzilla.redhat.com/show_bug.cgi?id=979681
20:09:33 <bconoboy> afaik that's it- anybody have anything else?
20:10:00 <bconoboy> Okay, let's move on
20:10:03 <bconoboy> #topic 2) Kernel Status Update
20:10:27 <bconoboy> Looking for kyle...
20:10:38 <handsome_pirate> From the exynos5 end, there's all sorts of goodies that looke like they'll be in 3.11
20:10:56 <handsome_pirate> Such as working wifi, usb3, hdmi, audio over hdmi ...
20:11:04 <bconoboy> handsome_pirate: Is that for chromebook?  Or arndale as well?
20:11:14 <handsome_pirate> Both
20:11:21 <handsome_pirate> Same Soc
20:11:37 <bconoboy> handsome_pirate: Anything not in 3.11 that we need?
20:11:50 <handsome_pirate> Don't know yet
20:12:06 <bconoboy> #info kernel 3.11 will have wifi, usb3, hdmi, audio over hdmi support on exynos5 (Arndale&Samsung Chromebook)
20:12:08 <handsome_pirate> I've been following the patches, but I'm not 100% as to what Linus is pulling
20:12:20 <bconoboy> kylem: Any fedora kernel updates?
20:12:44 <kylem> no -- peter beat me to setting the config options for 3.11-git2
20:12:53 <kylem> i've gone through them and everything looks good
20:13:16 <kylem> i'm doing a quick pass of the latest stuff today, but doesn't look like there's anything missing.
20:13:48 <bconoboy> #info As of 3.11-git2 the config options look sane for ARM
20:14:18 <kylem> we've been working on merging things where appropriate into a generic config-arm-generic that will be common between 32 and 64 bit
20:14:21 <bconoboy> kylem: Do you know which platforms are supported in 3.11 that aren't in, say, F19 GA?
20:14:34 <handsome_pirate> kylem:  Do you have just the config somewhere, so I don't have to download the entire srpm?
20:14:50 <bconoboy> #info kylem/pbrobinson are working on merging arm32 and aarch64 common configs into config-arm-generic
20:15:00 <kylem> bconoboy, not offhand
20:15:04 <kylem> handsome_pirate, sure, gimme two squeaks.
20:15:11 <handsome_pirate> Cool
20:15:22 <bconoboy> kylem: Okay, it'd be cool to know next week what's new in 3.11
20:15:35 <handsome_pirate> bconoboy:  By then we should have an rc
20:15:47 <kylem> bconoboy, i'll make a note to get a list
20:16:16 <bconoboy> #action kylem to create a list of new supported platforms in 3.11
20:16:45 <bconoboy> Can somebody ban danielbruno while he sorts his irc client out?
20:17:23 <kylem> bleh, fedorapeople doesn't seem to be working over ipv6.
20:17:35 <kylem> handsome_pirate, http://kyle.fedorapeople.org/kernel-3.11.0-armv7hl-lpae.config
20:17:42 <kylem> (and non-lpae in the same place)
20:17:47 <bconoboy> #link Latest 3.11 kernel config http://kyle.fedorapeople.org/kernel-3.11.0-armv7hl-lpae.config
20:18:12 <bconoboy> anything else for kernel updates?
20:18:18 <nirik> odd. it's working here.
20:18:29 <kylem> nirik, i blame red hat IT then. ;-)
20:18:36 <kylem> scp -4 did the trick.
20:18:48 <bconoboy> #topic 3) Aarch64 - Status Update, problem packages
20:19:18 <handsome_pirate> kylem:  THanks much
20:19:22 <bconoboy> We're still making good progress- 11000+ packages of the 13600 are complete
20:19:33 <bconoboy> #info 11000+ of 13600 packages are now built
20:19:35 <kylem> handsome_pirate, np
20:19:48 <bconoboy> We are completely off stage3 now- only stage4 is necessary for builds
20:19:56 <bconoboy> #info stage3 has been retired- stage4 is self sufficient
20:20:08 <handsome_pirate> Noice
20:20:22 <nirik> cool.
20:20:24 * handsome_pirate assumes that llvm is borked on aarch64 as well
20:20:34 <bconoboy> Top blockers today at ghc, java, and kdelibs (4)
20:20:46 <bconoboy> #topic Top blockers: ghc, java, kdelibs (4)
20:20:50 <bconoboy> #undo
20:20:50 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x148e2a90>
20:21:08 <bconoboy> #info Top blockers: ghc, java, kdelibs (4)
20:21:18 <msalter_> l<handsome_pirate>: ook at the llvm build logs. there were some test failures, but I don't know how serious they are
20:21:38 <bconoboy> It might be the case that llvm in stage4 is fully functional
20:21:51 <bconoboy> The issue we have on arm32 is, as far as I know, not an issue on aarch64.
20:21:59 <handsome_pirate> bconoboy:  I've been poking upstream ghc some more, they're working on it
20:22:33 <handsome_pirate> bconoboy:  I ask about the llvm on aarch64 because that's what they're going to be using
20:22:48 <bconoboy> handsome_pirate: The latest 3.3 version is built and in stage 4
20:22:57 <handsome_pirate> Okay
20:23:00 <bconoboy> #info ghc has been blocked on llvm, which is available in stage 4
20:23:08 * handsome_pirate will let ghc upstream know
20:23:17 * shisatum is here. Is also late in saying so.
20:23:20 <bconoboy> #action handsome_pirate Is talking to ghc upstream
20:23:47 <handsome_pirate> On my end, I can't do aarch64 too much anymore since the emulator doesn't run on arm (irony)
20:23:48 * nirik notes primary has a 3.3rc in it... dunno if there were any changes after that rc to final that would help
20:23:52 <bconoboy> java is basically openjdk- in theory it can be built today, we just haven't done it.  I think jonmasters was going to get that setup.
20:24:19 <bconoboy> #action jonmasters to get details for building openjdk to fulfill java dependency
20:25:20 <bconoboy> kdelibs-4 isn't getting queued due to missing pkgconfig() dependencies
20:25:35 <bconoboy> Error: No Package found for pkgconfig(QtWebKit)
20:25:35 <bconoboy> Error: No Package found for pkgconfig(dbusmenu-qt)
20:25:36 <bconoboy> ...
20:25:47 <bconoboy> Are these legit?
20:26:51 <msalter_> yes
20:27:01 <msalter_> qtwebkit isn;t built
20:27:47 <msalter_> I have a patch (along lines of the other half-dozen webkit instances in fc19)
20:28:36 <msalter_> but something wrong in the qt make sys I think. It keeps trying to build with jit even though it shouldn't
20:28:37 <bconoboy> msalter: Does that mean you're unraveling this dependency?
20:29:23 <msalter_> someone more familiar with qt make system would probably be better. I haven't looked at it in the last week.
20:29:28 <handsome_pirate> kylem:  #fedora-arm right quick?
20:29:33 <jonmasters> .fas jonmasters
20:29:34 <zodbot> jonmasters: jcm 'Jon Masters' <jonathan@jonmasters.org>
20:29:44 * pbrobinson apols for being late
20:29:54 <dmarlin> .fas dmarlin
20:29:55 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:29:55 <bconoboy> #info Somebody with qt-expertise would be beneficial to get kdelibs-4 deps built
20:30:24 <bconoboy> jonmasters: Hey, we're talking aarch64.  What's up with openjdk?
20:30:55 <jonmasters> I'll get an update from Andrew Johnson in the morning
20:31:01 <jonmasters> (thanks for the reminder)
20:31:24 <bconoboy> msalter (or anybody else): Any other updates for aarch64?
20:31:41 <handsome_pirate> jonmasters:  While you're here, I could use access to aarch64 some time next week
20:31:41 <jonmasters> (aside: Xen and KVM merged for 3.11)
20:31:47 <bconoboy> nirik: Are the VMs all set?
20:31:53 <bconoboy> (for koji)
20:32:13 <nirik> bconoboy: yeah. ;) They are all setup, I asked dgilmore to look at finishing setup/config and such.
20:32:17 <jonmasters> handsome_pirate: er, I know you're using a Chromebook, but your best bet is to find someone with an x86_64 laptop and run the model
20:32:33 <shisatum> I have one.
20:32:40 <bconoboy> #info Koji VMs for aarch64 builders are setup (Thanks Nirik!)
20:32:42 <shisatum> An Acer.
20:32:43 <nirik> so, hopefully next steps are koji setup, db setup, and getting access to builders, which I can help sort out.
20:32:49 <handsome_pirate> jonmasters:  I don't have working x86 h/w any more
20:33:02 <bconoboy> #action dgilmore to setup koji hub&db for aarch64
20:33:06 * shisatum Does
20:33:12 <handsome_pirate> shisatum:  The model won't run under Windows
20:33:35 <bconoboy> Okay, let's move on
20:33:40 <bconoboy> #topic 4) F20 PA Promotion
20:33:46 <jonmasters> handsome_pirate: that's unfortunate, but I don't have a good answer
20:34:02 <pbrobinson> there's two main issues at the moment
20:34:23 <bconoboy> jonmasters/handsome_pirate: please take it out of meeting
20:34:25 <pbrobinson> lack of stack-protection support in glibc for both 32/64
20:34:38 <bconoboy> Let's stick with 32 bit for now
20:34:38 <pbrobinson> llvm/clang issues
20:34:44 <jonmasters> pbrobinson: which Marcus Shawcroft tells me is supposed to be working and he is checking on within the next few hours
20:34:53 <jonmasters> (stack protector)
20:35:07 <pbrobinson> jonmasters: it's not upstream in glibc, will it land for 2.18?
20:35:35 <masta> I thought gcc had stack protection?
20:35:54 <nirik> side question: our builders now are fedora 18 (with release kernel I think). Would moving to f19 + newer kernel help any with build times?
20:36:05 <mjg59> masta: Support code is required in gcc, glibc and the kernel
20:36:08 <pbrobinson> masta: yes but without the glibc bits it's apparently a shell... see https://lists.fedoraproject.org/pipermail/devel/2013-July/185065.html
20:36:27 <bconoboy> #link Proposal posted on devel-list by Jaroslav Reznik on Tuesday https://lists.fedoraproject.org/pipermail/devel/2013-July/184962.html
20:36:42 <pbrobinson> mjg59: we have kernel and gcc. Apparently only x86/sh/arm have kernel support afaict
20:37:14 <bconoboy> #info Numerous issues raised on list:
20:37:16 <masta> ah! ok so I've seen some stack protection stuff for the kernel, but yeah I feel silly now.. this is for glibc
20:37:21 <mjg59> It's also concerning that the kernel code claims that all tasks will have the same stack cookie on ARM, which makes it effectively pointless
20:37:47 <bconoboy> #info 1: llvm still broken, causing llvmpipe to fail, removing 3d graphics support and no gnome desktop
20:38:12 <bconoboy> #info 2: stackprotector support in glibc questionable
20:38:34 <mjg59> So: I know that I've seemed very negative about the state of the ARM port. That's not really my intention, and I don't want to seem like I'm projecting stop energy
20:38:35 <bconoboy> nirik: Updating them to f19 will not help build times
20:38:44 * handsome_pirate notes that an arm guy doing full time qa would be useful
20:38:47 <pbrobinson> with compilation of llvm with no optimisation it looks like llvm is executing incorrect instructions but need someone with more time/knowledge to look closer
20:38:58 <nirik> bconoboy: ok, just an idle thought. ;)
20:39:07 <pbrobinson> mjg59: well you appear to mask your intentions really bloody well
20:39:18 <mjg59> But there's a lot of optimism about the state of the port from within the team (and understandably so), and I don't want the project to make decisions purely based on the optimism of of people who are invested in the outcome
20:39:21 <bconoboy> #info 3: Delta between build times is still being raised.  This is a particular problem for eclipse and other java-using packages since openjdk is less optimized
20:39:29 <handsome_pirate> pbrobinson:  I've already volunteered to poke llvm
20:39:47 <mjg59> What would help a *lot* (and which I've asked about a couple of times) is the known set of differences between x86 and ARM functionality
20:39:54 <pbrobinson> mjg59: so pessimism it is then?
20:40:05 <mjg59> Not only missing packages, but packages built with a reduced function set
20:40:26 * jonmasters is with pbrobinson on this. mjg59 has made his position abundantly clear on the list
20:40:33 <bconoboy> mjg59: That is every engineering manager's dream.  It doesn't exist.
20:40:39 <mjg59> Without that there's no way to make a rational decision about whether the feature set that ARM provides is close enough to x86 for us to actually call something Fedora
20:40:51 <jonmasters> anyway, as to llvmpipe, I feel that it is not a blocker. And we should raise that in the broader context of whether ARM can be a PA without GNOME as a desktop requirement
20:40:58 <mjg59> And I *want* ARM to be part of Fedora, but I want Fedora to actually mean somethin
20:40:59 <bconoboy> mjg59: The fact is every time this comes up somebody is going to raise their pet issue.  This is why we asked for concrete requirements a year ago.
20:41:08 <pbrobinson> mjg59: how do you propose we quantify that, things like stack protection wasn't bought up with the last discussion and it wasn't until a bug in grubby that it was actually discovered according to pjones
20:41:29 <mjg59> bconoboy: I know. I wrote most of those requirements. At the moment I don't feel like you're really meeting them.
20:41:50 <pbrobinson> mjg59: so it would be useful if you gave positive feedback and direction rather than just providing what we've not done and negativity
20:41:54 <jonmasters> for stack protection, I'm informed it's supposed to work. If it is not, we'll dig into it. What we can't do is have someone find some corner case and bikeshed on it. There will always be something. I can find things wrong with x86 and request it be demoted, but that doesn't help either
20:42:23 * handsome_pirate notes that ARM will need to fit in with the wider QA process if ARM goes primary
20:42:26 <jonmasters> #info stack protection is supposed to be working (according to ARM's tools team). We are looking into that.
20:42:59 <jonmasters> #info llvmpipe has a crash issue in the binary, which can be dug into. Suggestion is to raise whether GNOME desktop really has to be a blocker for PA
20:43:07 <mjg59> probinson: I think you've all done a great job to get ARM into the state it's in. I've said so several times.
20:43:15 <bconoboy> mjg59: Can't go with feelings- there has to be a path and a compass to determine if we're on it.
20:43:40 <mjg59> bconoboy: Sure, and the path is convincing the stakeholders (fesco, qa, rel-eng and so on) that you're appropriate as a PA
20:43:48 <handsome_pirate> mjg59:  How about this:  How is ARM not meeting the criteria?
20:43:48 <pbrobinson> mjg59: we've been working to cover all bases and increase parity and believe me we're not just focused on packages but it's not like there's a perfect list of ever single feature in every component of fedora that we can cross check and tick off
20:44:08 <pbrobinson> mjg59: said so.... no where public I've seen
20:44:23 <mjg59> pbrobinson: I'm aware of that. But there clearly are known cases of functional differences (see earler discussion about the JIT in qtwebkit)
20:44:34 * jonmasters has discussed the notion (with Matthew Miller, Robyn, and others) of changing requirements as necessary. After all, ARM is a very popular architecture, with many different (equally valid) use cases for the Fedora userbase. It doesn't have to exactly smell like x86.
20:45:04 <handsome_pirate> pbrobinson:  I've shared my observations on the QA side; and at the end of F19 cycle the process was being roughly followed
20:45:04 <mjg59> pbrobinson: Final paragraph of the promotion criteria
20:45:05 <pbrobinson> mjg59: what discussion.... the arm64 discussion?
20:45:24 <pbrobinson> mjg59: that was in reference to qt jit
20:45:33 <mjg59> pbrobinson: Oh, sorry, misinterpreted it
20:46:10 <pbrobinson> mjg59: Nokia did a lot of work on qt and it's my understanding it's completely feature parity
20:46:13 <pbrobinson> on arm 32
20:46:25 <pbrobinson> and arm64 isn't part of this proposal
20:46:54 <jonmasters> If we're going for feature parity as a requirement, I suggest "an architecture I can't use to toast my bread" as a requirement
20:47:09 <mjg59> pbrobinson: Sure, that was clearly a bad example. But this kind of thing should be tracked.
20:47:18 <bconoboy> Which packages have jits that are ported to arm is a silly discussion.  There are going to be differences in packages.  It's just a fact.  And unless we have an equal number of arm maintainers to x86 maintainers we aren't going to be fully informed.
20:47:22 <masta> lol jonmasters
20:47:55 <pbrobinson> mjg59: it's impossible to get 100% feature comparability because by definition the architectures are different....
20:48:08 <mjg59> pbrobinson: I'm aware of that, and so obviously there are going to be differences
20:48:22 <mjg59> pbrobinson: But without an idea of what those differences are, how is anybody supposed to make a decision?
20:48:23 <bconoboy> mjg59: Excluding desktop feature parity, do you have specific concerns about promoting ARM to primary?
20:48:36 <pbrobinson> mjg59: and ultimately if you're going to require 100% from promotion time we may as well give up and go home now
20:49:10 <mjg59> bconoboy: I'm concerned that the Fedora ARM team is unable to say whether or not arm32 supports stack-protector
20:49:10 <jonmasters> bconoboy: and we'll never get an equal number of maintainers if ARM is a second-class citizen until it has an equal number...chicken and egg
20:49:45 <pbrobinson> I have concerns about the stack-protector.... that was something that was missed even by mainline in the last conversation.... apparently according to jonmasters it might be close to solved though
20:49:51 <bconoboy> mjg59: We've been looking into it and expect to have a complete answer tomorrow morning.  Half the team is traveling this week and the issue was only raised yesterday.
20:49:56 <mjg59> bconoboy: You need that kind of level of expertise, otherwise who's going to fix this when it breaks?
20:50:35 <jonmasters> mjg59: we do have expertise, but there's a difference between a feature that is turned on and it being unintentionally broken in the implementation
20:50:40 <bconoboy> mjg59: We have an arm gcc maintainer, we have an arm kernel maintainer, we have an arm glibc maintainer.  I don't see an issue other than travel conflicts due to linaro connect and gcc cauldron.
20:51:08 <pbrobinson> and an oversight
20:51:14 <jonmasters> indeed
20:51:42 * jonmasters raised the stack protector issue within 12 hours of it being raised on the list
20:51:46 <jonmasters> it's being looked at, we don't offer a 4 hour SLA
20:51:47 <pbrobinson> ultimately the llvm issue has been on our radar to fix but it's not been a high enough priority
20:51:55 <bconoboy> mjg59: So, other than the stack protection issue, do you have other non-desktop concerns?
20:51:58 <mjg59> But obviously, I'm not a blocker
20:52:28 <pbrobinson> mjg59: you're not a blocker? to what in particular?
20:52:28 <bconoboy> mjg59: You're the worst case scenario :-)  If we have you onboard otherwise it's a good indicator.
20:53:25 <mjg59> bconoboy: Specifically? No. But given that I don't have any way to find out what the functional differences between ARM and x86 are, it's difficult toi say.
20:53:55 <pbrobinson> mjg59: so how are we expected to other than when people raise them and we test them?
20:54:00 <pbrobinson> if you don't know
20:54:35 <mjg59> pbrobinson: I'm expecting that a porting team be familiar with the packages they're porting
20:54:43 <handsome_pirate> mjg59:  At least in my case, my concerns are pretty specific
20:55:09 <handsome_pirate> And, they're being worked on as a result
20:55:09 <mjg59> pbrobinson: If a package builds on ARM but has functionality disabled in order to achieve that, it should be noted somewhere
20:55:32 <pbrobinson> mjg59: every issue that is raised we deal with as and when possible but there's a whole lot of functionality that is very hard to test across 13,500 packages that can be used in ways that any porting team couldn't imagine
20:55:48 <pbrobinson> mjg59: yes, and we are noting it
20:55:48 <bconoboy> mjg59: Most packages we haven't touched, they just build and they just work.  If the maintainer did that without the ARM team's input, how would we know?
20:56:09 <mjg59> pbrobinson: Ok! Where are you noting it?
20:56:37 <pbrobinson> mjg59: things like libseccomp we've been working upstream with and when it lands upstream we enable it downstream or work with the package maintainers to do so
20:56:44 <pbrobinson> mjg59: in the wiki and bugziller
20:56:49 <pbrobinson> bugzilla
20:57:18 <mjg59> pbrobinson: Is there a tracker bug for those issues?
20:57:37 <jonmasters> there is an ARM Tracker
20:57:55 <pbrobinson> mjg59: for example ada and pascal aren't currently supported but we don't see them as a blocker as they're corner case but we're working on them as time permits
20:57:56 <bconoboy> #info FYI, ARM BZs are tracked in the 'ARMTracker' alias
20:58:28 <pbrobinson> mjg59: ARMTracker is the alias in BZ.... it's been widely publicised on the lists/irc channel and even hits google
20:58:35 <mjg59> All I'm asking for is the ability for everyone who has to make a decision about whether ARM has met the PA requirements to be able to see what the known delta between x86 and ARM is
20:58:45 <bconoboy> Hey folks, we're running out of time
20:58:56 <mjg59> Actually pointing me at the wiki and a tracker bug for that purpose would have avoided this conversation entirely :)
20:59:16 <pbrobinson> mjg59: well why didn't you bloody well ask for it in the first place :-)
20:59:34 <mjg59> pbrobinson: I did. Nobody replied.
20:59:54 <pbrobinson> mjg59: really.... I only read your rant about llvm
21:00:10 <pbrobinson> mjg59: and yes that ticket is in BZ
21:00:39 <bconoboy> So what is the plan for the F20 ARM promotion discussion?
21:00:48 <mjg59> pbrobinson: http://www.spinics.net/lists/fedora-devel/msg184220.html
21:00:52 <nirik> https://bugzilla.redhat.com/showdependencytree.cgi?id=245418&hide_resolved=1
21:00:55 <bconoboy> Now that mjg59 is informed and completely on board :-)
21:01:32 <pbrobinson> mjg59: thanks
21:01:34 <bconoboy> #link Currently open armtracker bugs: https://bugzilla.redhat.com/showdependencytree.cgi?id=245418&hide_resolved=1
21:02:12 <bconoboy> I guess we'll just keep working through the thread.
21:02:40 <bconoboy> Anybody have anything to add on f20 promotion?
21:02:45 <pbrobinson> we'll ensure we go through it to make sure it's up to date and that all bugs are filed as a blocker against it
21:03:01 <bconoboy> #topic 5) Open Floor
21:03:07 <bconoboy> nirik, did you have something?
21:03:21 <nirik> oh, yeah, just a quick thing.
21:03:26 <mjg59> pbrobinson: Thanks, that's really appreciated
21:03:35 <nirik> so, I was looking at setting up some SOC's as packager test resources...
21:03:42 <mjg59> pbrobinson: Facts are the best arguments about anything I might say :)
21:03:57 <pbrobinson> mjg59: I like facts :)
21:04:13 <nirik> I'm not sure how best to work out logistics yet to get packagers access. Would it be enough to have some and a group we add packagers too that are interested in using them?
21:04:21 <nirik> or would it be better if it was all packagers from the start?
21:04:46 <nirik> or do folks think it's not useful really?
21:04:55 <pbrobinson> nirik: what's the implications to fedora infra. I seem to remember there was some legal or security issue in the past?
21:04:57 <bconoboy> nirik: This is remote access to arm builders?
21:05:18 <nirik> not builders, but 2 SOC's in phx2 yeah.
21:05:37 <nirik> there's security issues, as someone who logged into one of those could be on the same net as the builders. ;(
21:05:48 <nirik> which I don't like at all... even though they wouldn't have any way to access them.
21:06:00 <pbrobinson> nirik: maybe we could setup a separate FAS group "arm-testers" or something and people can request access?
21:06:12 <nirik> yeah, that was one thought to keep it smaller than 'all packagers'
21:06:34 <nirik> we already have arm-qa ones setup like that.
21:06:50 <nirik> https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
21:06:50 <bconoboy> nirik: just 2?  will the count go up if demand justifies it?  A separate net would be better...
21:07:10 <nirik> well, not sure what the demand is. ;) yes, we could do more.
21:07:16 <nirik> I did 4 for qa.
21:07:21 <jonmasters> (aside, I just took a look at the stack protector kernel-side code again. It would indeed be nice if the stack canary could vary on SMP, but that's not a blocker to using the feature)
21:07:23 <nirik> we could also just reuse those for packagers too.
21:07:34 <pbrobinson> personally I would restrict access. the fact is in the last 2 years the non RHers that have requested access to actually do it is few
21:07:37 * jonmasters will poke Marcus and the ARM tools team some more tomorrow
21:07:58 <nirik> yeah, I run test machines for packagers here at my house too... and they get very little use.
21:08:14 <nirik> but I can see with arm maintainers may want to compile/test faster than scratch builds.
21:08:30 <nirik> we don't need to decide this now, just throwing out options.
21:08:41 <handsome_pirate> bconoboy:  Well, we need to talk about qa process
21:08:41 <handsome_pirate> bconoboy:  The end of F19 was close, but not quite there
21:08:41 <handsome_pirate> bconoboy:  Part of that hinges around which desktops are taken as blocker for arm
21:08:41 <handsome_pirate> bconoboy: Did you get any of my last?
21:08:43 <jonmasters> I don't really see the need to provide access any more - ARM hardware is inexpensive and we have occasionally helped the one or two people who can't afford it to get something
21:09:05 <bconoboy> handsome_pirate: You just sent a huge volume of text- was that for arm32 promotion?
21:09:23 <nirik> well, packagers may want to help, but may not want to buy arm hardware.
21:09:32 <bconoboy> #info  nirik is looking into adding limited external access to arm hosts - contact with your feedback
21:09:43 <nirik> I also have a smartbook here I can setup as a test machine (again), but I don't know what current smartbook support is like. ;)
21:09:57 <jonmasters> nirik: worth looking into, but a nice to have I think
21:10:26 <pbrobinson> nirik: did you see my koji maintenance query?
21:10:50 <bconoboy> nirik: I think that'd be a great service to provide if you can work out the security issues.  quad core server class hosts are way nicer to work with than vexpress
21:10:53 <pbrobinson> nirik: the smartbook upstream kernel support was dropped so not good
21:11:11 <nirik> pbrobinson: yeah, it shouldn't affect arm at all. ;)
21:11:37 * nirik wishes we could vlan or parcel out SOC's better on the chassis, but oh well.
21:12:05 <jonmasters> nirik: we ought to be able to do that
21:12:16 <bconoboy> let's take that back to #fedora-arm
21:12:20 <bconoboy> does anybody else have anything for the open floor?
21:12:22 <jonmasters> ok
21:12:34 <nirik> if we could do that, I could seperate out some SOC's for testing/qa that would be a seperate net from the builders, which would make me happy.
21:12:43 * nirik doesn't have anything more.
21:13:05 <bconoboy> #link Linaro Connect is taking place this week- check out the latest at http://www.linaro.org/connect
21:13:15 <jonmasters> nirik: we can at least ask Calxeda about changing the fabric topology if you're not using all 4 10Gbit SFPs such that e.g. one is a deficated subset of nodes
21:13:33 <bconoboy> Last chance...
21:13:39 <bconoboy> Okay, thanks everybody
21:13:40 <nirik> sure, I'd love to hear options. :)
21:13:42 <bconoboy> #endmeeting