20:00:52 <pwhalen> #startmeeting Fedora ARM weekly status meeting
20:00:52 <zodbot> Meeting started Wed Jun 19 20:00:52 2013 UTC.  The chair is pwhalen. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:52 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:52 <pwhalen> #chair pwhalen jonmasters bconoboy ctyler pbrobinson dgilmore dmarlin masta j_dulaney msalter ahs3 agreene jcapik ddd
20:00:52 <zodbot> Current chairs: agreene ahs3 bconoboy ctyler ddd dgilmore dmarlin j_dulaney jcapik jonmasters masta msalter pbrobinson pwhalen
20:00:58 <ctyler> .fas chris@tylers.info
20:00:59 <zodbot> ctyler: ctyler 'Chris Tyler' <chris@tylers.info>
20:01:04 <dgilmore> hola
20:01:06 <dmarlin> .fas dmarlin
20:01:07 <zodbot> dmarlin: dmarlin 'David A. Marlin' <dmarlin@redhat.com>
20:01:13 <pwhalen> .fas pwhalen
20:01:14 <zodbot> pwhalen: pwhalen 'Paul Whalen' <pwhalen@redhat.com>
20:01:17 <nirik> .hellomynameis kevin
20:01:23 <jcapik> .fas jcapik
20:01:25 * handsome_pirate waves
20:01:25 <zodbot> nirik: kevin 'Kevin Fenzi' <kevin@scrye.com>
20:01:25 <bconoboy> .fas blc@
20:01:28 <zodbot> jcapik: jcapik 'Jaromír Cápík' <jcapik@redhat.com>
20:01:31 <zodbot> bconoboy: blc '' <blc@redhat.com>
20:02:50 <pwhalen> #topic 0) Status of ACTION items from our previous meeting
20:03:04 <pwhalen> #link http://meetbot.fedoraproject.org/fedora-meeting-1/2013-06-05/fedora-meeting-1.2013-06-05-20.00.html
20:03:09 <pwhalen> no action items
20:03:11 <jonmasters> .fas jonmasters
20:03:11 <zodbot> jonmasters: jcm 'Jon Masters' <jonathan@jonmasters.org>
20:03:18 <pwhalen> #topic 1) Problem packages
20:04:33 <bconoboy> anyone?
20:04:38 <pwhalen> we had eclipse from our last meeting, looks to be built now
20:04:55 <bconoboy> dgilmore mentioned something the other day... mozjs?
20:05:05 <dgilmore> bconoboy: i dealt with it
20:05:11 <dgilmore> spoke with the maintainer
20:05:23 <bconoboy> it's fixed and all blocked builds are complete?
20:05:24 <dgilmore> he felt the failing test is bogus so its disabled
20:05:30 <dgilmore> bconoboy: yes
20:05:52 <bconoboy> cool.  So nothing is unbuilt for f19 that are are concerned about?
20:06:03 <pwhalen> other one from the last meeting was systemtap
20:06:27 <dgilmore> afaik its broken still
20:06:35 <pwhalen> #info systemtap-2.3-0.51.ge15a40c.fc20 FTBFS on ARM
20:06:42 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=969656
20:06:48 <jonmasters> is it all systemtap 2.3?
20:07:40 * pbrobinson is here!!!!
20:07:41 <bconoboy> pbrobinson: any failed packages to mention?
20:07:48 <pbrobinson> systemtap on rawhode
20:07:54 <bconoboy> got that
20:07:56 <dgilmore> jonmasters: yes
20:07:57 <bconoboy> anything else?
20:08:05 <pbrobinson> eclipse is fixed! WOO!
20:08:36 <jonmasters> that systemtap issue looks like something wrong with texlive
20:08:37 <pwhalen> nice
20:08:38 <pbrobinson> and there's nothing else I'm aware of but this week has been close to hell so I've paid less attention that usual
20:08:45 <pbrobinson> jonmasters: correct
20:09:29 <jonmasters> pwhalen: is there a bug on systemtap?
20:09:36 <pwhalen> jonmasters, yes
20:09:38 <pbrobinson> yes
20:09:38 <jonmasters> ok
20:09:43 <pwhalen> https://bugzilla.redhat.com/show_bug.cgi?id=969656
20:09:51 <pwhalen> its in the logs too
20:09:56 <pbrobinson> thx
20:10:13 <pwhalen> moving on?
20:10:17 <bconoboy> y
20:10:19 <jonmasters> y
20:10:25 <pwhalen> #topic 2) Kernel Status Update
20:10:44 * masta is here
20:10:46 <masta> sry late
20:10:46 <pbrobinson> so I think we're not in a bad state on either 3.10 or 3.9 at the moment
20:10:57 <pbrobinson> I've still  awaiting lpae feedback
20:10:58 <bconoboy> you might even say we're in a good state
20:11:02 <pwhalen> agreed
20:11:03 <bconoboy> lpae feedback from who?
20:11:08 <pbrobinson> I'm even! fuck you brain
20:11:22 <handsome_pirate> bconoboy: Me, likely
20:11:23 <pbrobinson> masta and
20:11:28 <masta> is this lpae on exynos?
20:11:32 <handsome_pirate> Aye
20:11:35 <pbrobinson> handsome_pirate: who are you?
20:11:40 <jonmasters> John Dulaney
20:11:44 <pbrobinson> ah
20:11:49 <bconoboy> aka, the dread pirate roberts
20:11:51 <masta> I think that was booting, basic support
20:12:01 <bconoboy> booting on chromebook... or arndale?
20:12:08 <handsome_pirate> Chromebook
20:12:13 <pbrobinson> masta: I think I'm dead.... but I suspect not ;-)
20:12:26 <bconoboy> this is 3.10?
20:12:28 * masta admits he has not booted  it yet
20:12:28 * handsome_pirate admits to not spending much time on Chromebook of late, been working on QA stuff
20:12:39 <pbrobinson> bconoboy: both...
20:14:03 <masta> hope to solder uart wires to my chromebook someday to help test lpae better
20:14:06 <pbrobinson> any way that's it for kernel. I think 3.9.x is pretty much good to go and all focus is now on 3.10
20:14:18 <pwhalen> #topic 3a) Aarch64 Status Update, problem packages
20:14:45 <jonmasters> qt4 is getting some special attention
20:15:09 <pbrobinson> 3.10 isn't in a bad state for current SoC and hopefully we'll start to test wider. The big missing one for both is mvebu and I'm hoping jonmasters has a little bit more bandwidth now summit is done
20:15:21 <pwhalen> #link https://fedoraproject.org/wiki/Architectures/ARM/AArch64/Stage4_Problem_Packages
20:15:30 <jonmasters> pbrobinson: I do - this weekend I will get a good mvebu update
20:15:38 <pbrobinson> so I saw the link for the packages that needed to be upstreamed
20:15:45 <pbrobinson> this week is horrific
20:15:47 <bconoboy> aarch64: We've queued up a bunch of f19 updates, about 600 in total
20:15:50 <jonmasters> pbrobinson: speaking of which, I'll bring you that mvebu in time for July 6th
20:15:54 * masta will try to find time to try 3.10 on the mira
20:16:02 <bconoboy> msalter got gcc to finish in stage4, which has unlocked a bunch of things
20:16:10 <bconoboy> (due to gcj being available)
20:16:10 <pbrobinson> but next week I should have a little bit more bandwidth to help push most of them upstream
20:16:24 <pbrobinson> jonmasters: cool!
20:16:25 <bconoboy> qt and java-devel are the biggest blockers now
20:16:40 <jonmasters> Java I'm talking to Linaro about right now
20:17:03 <bconoboy> infact most of the remaining stage3 dependencies are due to a lack of them
20:17:41 <handsome_pirate> ghc is waiting on llvm
20:17:45 <jcapik> some of the failues are directly related to the incomplete instructions in the aarch64 bugs
20:17:47 <bconoboy> I think we're pretty close to being able to retire stage3
20:17:52 <bconoboy> jcapik?
20:17:54 <jonmasters> it's unclear if Linaro have Zero on Java 7
20:17:59 <jonmasters> I think it might be 8
20:18:03 <jonmasters> I'll update
20:18:10 <pbrobinson> handsome_pirate: there's a new version of ghc landing in rawhide soon
20:18:22 * jonmasters would like to move to Koji with aarch64 soon
20:18:23 <jcapik> bconoboy: in some cases the maintainers simply put autoreconf -vif in the spec file without checking if it does the job
20:18:35 <pbrobinson> jonmasters: I think it's 8
20:18:48 <jcapik> bconoboy: it seems that all avr-* packages fail to build because of that
20:19:00 <handsome_pirate> pbrobinson:  New version doesn't support llvm as backend yet, that's next version
20:19:13 <jonmasters> pbrobinson: indeed, Andy Johnson says 8 but I'm trying to find out if that's where it will end or if he can be persuaded on 7
20:19:19 <bconoboy> jcapik: first I've heard of avr issues..
20:19:30 <jcapik> bconoboy: I'm fixing the packages right now
20:19:41 <jonmasters> (Andy Johnson is Linaro Java lead, working with their other Java guy Ed Neville and our two Java folks)
20:19:45 <bconoboy> there only seem to be 4
20:19:45 <jcapik> bconoboy: and I expect more issues like that
20:20:06 <bconoboy> pwhalen: is moving to koji a different topic?
20:20:12 <pbrobinson> jonmasters: pm btw
20:20:16 <pwhalen> next subtopic, we can go to it now
20:20:17 <jcapik> bconoboy: we need to investigate reasons why autoreconf -vif doesn't rewrite the config.* files in some cases
20:20:33 <pbrobinson> pwhalen: yep, I think so
20:20:36 <pwhalen> #topic 3b) Aarch64 - Moving to Koji
20:21:07 <bconoboy> 2 weeks ago we discussed starting to migrate to koji from arm-temp
20:21:10 <bconoboy> dgilmore: any update?
20:22:31 <bconoboy> dgilmore?
20:22:35 <pwhalen> he may be busy with something else, should we carry on and come back to this?
20:22:40 <jonmasters> sure
20:22:40 <dgilmore> bconoboy: not even looked at it
20:22:49 <dgilmore> bconoboy: no cycles right now for it
20:22:56 <bconoboy> dgilmore: when do you think you will?
20:23:08 <dgilmore> bconoboy: late july at earliest
20:23:14 <jonmasters> another option is us setting up a Koji in HSV
20:23:23 <pbrobinson> I think we need to wait post f19 release
20:23:24 <handsome_pirate> HSV?
20:23:28 <dgilmore> jonmasters: so long as its public
20:23:30 <handsome_pirate> +1 waiting
20:23:33 <pbrobinson> and I don't think that's a major issue
20:23:42 <bconoboy> dgilmore: I can't put stuff in HSV in public, it's all firewalled
20:23:42 <handsome_pirate> Too many eggs in the fire right now
20:23:59 <dgilmore> bconoboy: then we cant put a koji there
20:24:09 <bconoboy> dgilmore: Can you give somebody else in RH access to the koji hub to do the setup?
20:24:13 <jonmasters> bconoboy: we could setup a VM somewhere with enough disk (I know arm-temp doesn't have enough)
20:24:18 <pbrobinson> bconoboy: so we wait then.... it's only a few weeks
20:24:18 <ctyler> +1, if it's not a public koji it's not a Fedora koji
20:24:33 <jonmasters> we can also wait
20:24:40 <ctyler> Post-F19 is not long
20:24:47 <pbrobinson> exactly
20:24:49 <bconoboy> pbrobinson: late july is 6 weeks
20:25:02 <bconoboy> We haven't built a single f20 package yet for aarch64.
20:25:09 <dgilmore> bconoboy: nirik may have cycles to install the vm and get thing started
20:25:29 <dgilmore> bconoboy: no its not
20:25:32 <bconoboy> I'm quite concerned about our bootstrap falling behind and having to resolve dependencies
20:25:34 <nirik> hum? /me reads up
20:25:34 <dgilmore> bconoboy: its more like 4 weeks
20:25:50 <bconoboy> er, re-resolve dependencies, that is
20:26:06 <nirik> so, this is adding to the existing hub? or installing a new hub just for this?
20:26:07 <bconoboy> Once f19 wraps up there is going to be big f20 churn.
20:26:10 <jonmasters> bconoboy: another option is we do for F20 what has been done for F19, pulling packages in manually into arm-temp
20:26:11 <bconoboy> nirik: new hub
20:26:12 <pbrobinson> bconoboy: it's a month to the 19th July and I call that late.... lets not split hairs
20:26:13 <dgilmore> nirik: we talked about setting up a vm on the box in phx that arm koji is on
20:26:21 <dgilmore> nirik: to build aarch64 while bootstrapping
20:26:29 <nirik> yeah, we can. What builders?
20:26:45 <jonmasters> nirik: 50+ RH virtual machines
20:26:49 <nirik> ok.
20:26:55 <dgilmore> nirik: there is a ton of emulated ones in westford
20:26:57 <bconoboy> just need some firewall magic
20:27:00 <nirik> I can possibly setup the vm, sure.
20:27:12 <jonmasters> nirik: only thing needed then is a s390-style proxy setup in Westford
20:27:12 <nirik> no promises for immediately, but I can add it to my list.
20:27:39 <jonmasters> or maybe you can leverage the existing one, I dunno
20:27:46 <bconoboy> #action nirik to add an aarch64 koji hub VM on the existing arm koji server
20:27:55 <nirik> will have to investigate. I don't know how thats seutp currently
20:27:55 <ctyler> It would be good to have it well into building by Flock, we could sprint on problem packages that week
20:28:01 <jonmasters> nirik: ok
20:28:26 <bconoboy> nirik: we can setup the squid proxy, just need help getting the vm and hub up
20:28:43 <bconoboy> (the proxy will live inside rh, not at phx)
20:28:46 <nirik> bconoboy: ok. I can work on it. I assume a db vm as well right?
20:28:52 * jonmasters hopes there's enough storage for /mnt/koji lying around, but I assume so
20:28:57 <jonmasters> nirik: yes
20:29:10 <jonmasters> nirik: unless it can all go in one
20:29:12 <bconoboy> storage, that' a good question
20:29:23 <jonmasters> bconoboy: I think dgilmore had said there was capacity
20:29:29 <nirik> it's better to have db and hub seperate I think.
20:29:32 <jonmasters> ok
20:29:35 <nirik> I think so, /me checks.
20:29:43 <bconoboy> nirik: believe they're on the same vm now for arm32
20:30:02 <jonmasters> even though it'll be slow and painful having aarch64.koji.fp.o will be a net-win
20:30:19 <nirik> bconoboy: nope, 2 seperate ones. on the same virthost. ;)
20:30:20 <jonmasters> then when there is hardware it'll be a drop-in
20:30:26 <nirik> how much /mnt/koji space do you see needing?
20:30:30 <bconoboy> nirik: Ah, right- so we're asking for 2 new virt hosts I guess
20:30:41 <jonmasters> a few TB?
20:31:02 <nirik> the virthost has 2ish free... we could also just put it on netapp I guess.
20:31:03 <bconoboy> nirik: We're using about 120GB right now... 300-500 should work through the end of the year
20:31:04 <jonmasters> for some reason my brain is thinking of 300GB min
20:31:10 <dgilmore> jonmasters: doesnt need 1t
20:31:13 <nirik> ok, thats easy...
20:31:25 <jonmasters> dgilmore: ok, so that 300GB number in my head is more realistic?
20:31:42 <jonmasters> ok, so 300-500GB then
20:31:59 <dgilmore> its only until we get physical build hardware. and move to arm.koji.fp.o
20:32:04 <nirik> yeah, 500 shouldn't be a problem, could do that on the vmhost even.
20:32:14 <dgilmore> nirik: that was my thought
20:32:34 <bconoboy> nirik: should we ping you on this next wednesday?
20:32:41 <nirik> sure. will let me work on ansibleizing koji hub/db config too. :)
20:32:48 <nirik> sure, I can give an update then...
20:32:53 <bconoboy> there ya go, perfect excuse
20:33:03 <bconoboy> next?
20:33:13 <jonmasters> I have something
20:33:37 <jonmasters> so on hardware, there are two things I would like to vaguely mention without too much specifics yet
20:34:03 <jonmasters> 1). There is a plan taking shape for getting builder hardware. I can't share any more info, but just so folks know we do have this moving
20:34:12 <handsome_pirate> Yay
20:34:43 <jonmasters> 2). Last week the existence of the Applied Micro X-C1 board became public. There is an arrangement wherein it will ship with a Fedora Remix. We'll get working on that "soon". An update to follow.
20:35:05 <jonmasters> that's what I wanted to add
20:35:26 <pwhalen> cool, any comments/questions before we move on?
20:35:40 <handsome_pirate> Can I play with one :)
20:35:51 <jonmasters> :)
20:35:57 <pwhalen> #topic 4a) F19 GA - TC5 testing
20:36:08 <pwhalen> #link http://armpkgs.fedoraproject.org/mash/stage/19-TC5/Images/armhfp/
20:36:08 <bconoboy> are we there yet?
20:36:40 * handsome_pirate notes that earlier the bug with setting root password was voted a freeze exception
20:36:51 <pbrobinson> bconoboy: mainline isn't so by definition....
20:36:57 <pwhalen> initial-setup-graphical worked, changes were saved, however the mate image end up at multi-user
20:37:07 <pbrobinson> what blockers do we have for ARM
20:37:18 <pbrobinson> as in not mainline blockers but ours
20:37:20 <handsome_pirate> initial setup bug is what I refer to
20:37:31 <pwhalen> #info F19 ARM Blocker
20:37:36 <pwhalen> #link https://bugzilla.redhat.com/show_bug.cgi?id=901850
20:37:55 <pwhalen> there should be fixes for both initial-setup bugs
20:38:02 <dgilmore> pwhalen: what do you mean by multi-user?
20:38:13 <pwhalen> text login
20:38:15 <masta> pwhalen: I think the multi-user and gui targetes are setup in a ks %post snip... that is interesting, I'll try to see if the links are right before first boot and then look again after
20:38:56 <handsome_pirate> As far as I know, only one of the initial setup bugs was set as a freeze exception
20:39:01 <pwhalen> symlink is right
20:39:05 <bconoboy> pwhalen: did default.target get set to multi-user?
20:39:21 * handsome_pirate notes that fixes don't make it into images if they do not go through the blocker bug process
20:39:34 <pwhalen> bconoboy, its set to graphical
20:39:42 <dgilmore> masta: pwhalen: if initial-setup ran graphically i suspect that lightdm wasnt installed
20:39:53 <bconoboy> so initial-setup did the right thing, but the image comes up multi-user? Is that just on the first boot, or on all boots?
20:40:02 <pwhalen> bconoboy, all
20:40:07 <masta> https://git.fedorahosted.org/cgit/spin-kickstarts.git/tree/fedora-arm-mate.ks
20:40:10 <masta> line 8
20:40:20 <bconoboy> how are graphics being tested if the images come up to a tty login prompt?
20:40:59 <handsome_pirate> startx?
20:41:29 <handsome_pirate> .bug 970719
20:41:32 <zodbot> handsome_pirate: Bug 970719 initial-setup-text.service causes endless lvm messages to the console - https://bugzilla.redhat.com/show_bug.cgi?id=970719
20:41:33 <pwhalen> bconoboy, this was specifically the mate image, both. previous tc booted to graphical fine
20:41:42 <handsome_pirate> That is the one I refer to above
20:42:28 <bconoboy> pwhalen: Okay, so it's a mate issue?
20:42:39 <masta> probably
20:42:44 <dgilmore> looks like no desktop manager is installed
20:42:47 <pwhalen> other issue I have found so far on TC5 is the minimal image does not run initial-setup-text, result is the endless spam seen previously, and fixed in the latest version I believe, needs testing
20:42:55 <dgilmore> on the mate image
20:43:11 <masta> glad to see folks trying out the mate image
20:43:21 <dgilmore> there will likely be a TC6 request tonight
20:43:50 <masta> ok so we can try the xfce to poke the bug
20:43:53 <jonmasters> dgilmore: thanks
20:44:01 <jonmasters> (with the anaconda command line fix?)
20:44:47 <bconoboy> I need to update a-b-c to use fedora-compliant boot arguments
20:45:34 <dgilmore> jonmasters: ?
20:45:43 <pwhalen> bconoboy, thanks
20:45:58 <handsome_pirate> Well, I need to go
20:46:08 * handsome_pirate has a job interview shortly ... with Red Hat
20:46:17 <dgilmore> good luck
20:46:26 <handsome_pirate> Thanks
20:46:40 <pwhalen> I think the initial-setup bugs should be closed now and will confirm today. the abc and rootfs-resize are nice to have
20:46:46 <pbrobinson> good luck
20:47:01 <pwhalen> has anyone come across anything else not included there?
20:47:51 <bconoboy> I'm just wondering if we have an official plan for preparing omap/vexpress images to be more useful out of the box, or easier to deploy anyway.
20:48:26 <pwhalen> funny you should ask.. fossjon?
20:48:39 <dgilmore> bconoboy: fossjon was working on something for omap, though he seems to be getting distracted by trying to do too much
20:48:54 <fossjon> I've been trying to make an easy to use installer/customizer for special cases like omap
20:49:14 <fossjon> I posted a demo video on youtube to show some example usage: http://www.youtube.com/watch?v=mnVSwW8nroo
20:49:17 <masta> is this something that places the right MLO and u-boot.img in place?
20:49:45 <pwhalen> masta, yes
20:49:46 <bconoboy> fossjon: Does it handle omap at this point?
20:49:47 <fossjon> yes masta , it should be able to copy over the mlo first from the uboot folder, sync and then copy the rest of the files over
20:50:04 <fossjon> i haven't implemented the copying code yet but thats the last easy part
20:50:11 <fossjon> ive been mainly working on the interface
20:50:34 <fossjon> someone made mention of the possible use cases which I would need to know, how/when this would be used and where
20:50:59 <dgilmore> it actually doesnt matter if the MLO is first or not
20:51:00 <masta> ok so the mlo, u-boot.img, and I guess the .dtb needs to be setup too?
20:51:02 <bconoboy> dgilmore: Assuming it does what we need, what would you think of adding this script to uboot-tools?
20:51:09 <fossjon> for example, only on x86 boxes to sd cards or on ARM devices them selves onto hdd's, etc...
20:51:15 <dgilmore> i think the issue is fragmentation
20:51:27 <dgilmore> bconoboy: uboot-tools is the wrong place
20:51:52 <dgilmore> bconoboy: there is a package called fedora-arm-installer thats used to setup pi sdcards
20:51:56 <dgilmore> it should go there
20:52:08 <bconoboy> Is there? Cool.
20:52:14 <bconoboy> Can we get a freeze exception for it?
20:52:31 <bconoboy> It'd be really nice to have the tool in the f19 base install for x86
20:52:37 <bconoboy> er, not base install, but available
20:52:49 <pwhalen> thats fossjons package too, sure he can add it
20:52:51 <ctyler> bconoboy: if it's just "available" it can be a launch-day update
20:52:52 <fossjon> yeah dgilmore i made that installer too mainly for the rasp pi images but it could use any image file
20:52:53 <dgilmore> bconoboy: probably not
20:53:01 <dgilmore> but we wouldwant it in all fedora
20:53:04 <dgilmore> s
20:53:16 <fossjon> it doesn't support xz files though
20:53:23 <ctyler> ...yet :-)
20:53:30 <fossjon> :)
20:53:56 <bconoboy> Okay, quick recap:
20:54:07 <fossjon> the problem is windows cant read from the ext partitions so i cant copy over the files if its run on windows systems
20:54:17 <bconoboy> fossjon is writing a tool that does or will do what is needed for f19 omap/vexpress images
20:54:20 <fossjon> for omap for example
20:54:54 <bconoboy> The tool could be added to the fedora-arm-installer package
20:55:22 <bconoboy> Assuming we don't want to break freeze, we could still have it as a 0 day update... and in f18 as well, no?
20:56:13 <fossjon> I could try to add it into the installer package as an addon for Fedora usage
20:56:29 <fossjon> as a separate script that could be run
20:57:06 <jcapik> fossjon: for windows we can always share the files separately
20:57:22 <jcapik> fossjon: and let the windows users do the magic manually
20:57:42 <fossjon> yeah its possible
20:58:01 <pwhalen> we're coming up on the hour, anything else left to discuss for f19?
20:58:12 <dgilmore> test
20:58:23 <dgilmore> get the matrixes completed
20:58:58 <bconoboy> pointer to the matrix again?
20:59:18 <pwhalen> please do!
20:59:32 <pwhalen> #link https://fedoraproject.org/wiki/Category:Fedora_19_ARM_TC5
20:59:59 <pwhalen> I've just started, so please assist.
21:00:20 <bconoboy> if folks other than pwhalen would help with the desktops that would be good
21:00:55 <pwhalen> #topic 5) Open Floor
21:01:03 <pwhalen> anything else?
21:01:08 <nirik> I have one item real quick...
21:01:10 <nirik> https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
21:01:20 <nirik> I setup some test machines a bit ago.
21:01:36 <pwhalen> thanks nirik, I did mean to mention it as well
21:01:47 <nirik> Access is via the arm-qa fas group. I was thinking of perhaps adding some packager/developer ones too? or just expanding those to also include packagers?
21:02:06 <nirik> They are all currently running f18, but I can redo some with f19 pretty easy.
21:02:11 <bconoboy> #link Accessing ARM hardware for QA: https://fedoraproject.org/wiki/Architectures/ARM/qa-machines
21:02:27 <nirik> so, if anyone wants adjustments or changes in that setup, please let me know.
21:03:10 <nirik> or thoughts on packager access... different machines? just added there?
21:03:35 <pwhalen> thanks for setting that up
21:03:37 <bconoboy> #info contact nirik if you would like to see changes made
21:03:49 <nirik> hopefully it will be of help
21:03:54 <dgilmore> nirik: not sure whats best
21:04:12 <nirik> I think some packager access could help in them fixing bugs...
21:04:20 <nirik> dunno if that would step on toes of people testing.
21:04:29 <dgilmore> yeah
21:04:32 <dgilmore> not sure
21:05:31 <pwhalen> ok, anything else?
21:05:39 <nirik> perhaps I will just setup 2 more for packagers. easy enough to do.
21:05:41 <pbrobinson> nirik: from experience of dealing with it up to now I'm not sure it would make much of a difference
21:05:51 <nirik> ok.
21:06:05 <pwhalen> #endmeeting