17:00:25 <trishnag> #startmeeting fedora_atomic_wg
17:00:25 <zodbot> Meeting started Wed Feb  8 17:00:25 2017 UTC.  The chair is trishnag. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:25 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:25 <zodbot> The meeting name has been set to 'fedora_atomic_wg'
17:00:35 <bowlofeggs> .hello bowlofeggs
17:00:36 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <randy@electronsweatshop.com>
17:00:55 <trishnag> #topic Roll Call
17:01:03 <maxamillion> .hello maxamillion
17:01:04 <zodbot> maxamillion: maxamillion 'Adam Miller' <maxamillion@gmail.com>
17:01:04 <jbrooks> .fas jasonbrooks
17:01:06 <dustymabe> .hello dustymabe
17:01:07 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <JBROOKS@REDHAT.COM>
17:01:07 <trishnag> .hello trishnag
17:01:10 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dustymabe@redhat.com>
17:01:12 <kushal> .hellomynameis kushal
17:01:13 <zodbot> trishnag: trishnag 'Trishna Guha' <trishnaguha17@gmail.com>
17:01:16 <zodbot> kushal: kushal 'Kushal Das' <mail@kushaldas.in>
17:01:44 * tflink is lurking
17:01:57 <trishnag> #chair bowlofeggs maxamillion jbrooks dustymabe kushal tflink walters
17:01:57 <zodbot> Current chairs: bowlofeggs dustymabe jbrooks kushal maxamillion tflink trishnag walters
17:02:23 <miabbott> .hello miabbott
17:02:24 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
17:02:35 <trishnag> #chair miabbott
17:02:35 <zodbot> Current chairs: bowlofeggs dustymabe jbrooks kushal maxamillion miabbott tflink trishnag walters
17:02:41 <rtnpro> .fas rtnpro
17:02:41 <zodbot> rtnpro: rtnpro 'Ratnadeep Debnath' <rtnpro@gmail.com>
17:02:44 <scollier> .hello scollier
17:02:45 <zodbot> scollier: scollier 'Scott Collier' <emailscottcollier@gmail.com>
17:02:58 <trishnag> #chair rtnpro scollier
17:02:58 <zodbot> Current chairs: bowlofeggs dustymabe jbrooks kushal maxamillion miabbott rtnpro scollier tflink trishnag walters
17:04:14 <walters> do we have an agenda for today?
17:04:33 <roshi> .hello roshi
17:04:34 <zodbot> roshi: roshi 'Mike Ruckman' <mruckman@redhat.com>
17:04:46 <trishnag> walters: We usually follow the meeting items in https://pagure.io/atomic-wg/issues
17:04:54 <trishnag> #chair roshi
17:04:54 <zodbot> Current chairs: bowlofeggs dustymabe jbrooks kushal maxamillion miabbott roshi rtnpro scollier tflink trishnag walters
17:05:05 <trishnag> #topic Action items from last meeting
17:05:30 <trishnag> will skip the action items by jberkus since he is not here.
17:05:40 <dustymabe> yeah and then we also allow anyone to bring forward any items they like
17:06:12 <trishnag> yeah
17:06:16 <trishnag> * ACTION: jbrooks still to update compose your own tree doc
17:06:26 <jbrooks> http://www.projectatomic.io/docs/compose-your-own-tree/
17:06:28 <jbrooks> that's it
17:06:29 <roshi> yaym I have a chair :)
17:07:06 <trishnag> jbrooks: nice!
17:07:09 <trishnag> * ACTION: more testing on docker-storage-setup patches jbrooks dustymabe jberkus
17:07:36 <dustymabe> trishnag: so they decided to rework the patches
17:07:43 <dustymabe> and go a different way
17:08:45 <trishnag> dustymabe: okay.
17:08:47 <dustymabe> i think the new PR got merged
17:08:58 <trishnag> dustymabe: Can we have link to that?
17:09:01 <dustymabe> so basically this work got "held up" but now we can try to test the new patches
17:09:16 <trishnag> It would be useful to link the url.
17:09:40 <dustymabe> let me find it
17:09:44 <trishnag> Sure!
17:10:13 <dustymabe> I think this is it: https://github.com/projectatomic/docker-storage-setup/pull/181
17:10:32 <trishnag> #link https://github.com/projectatomic/docker-storage-setup/pull/181
17:10:35 <trishnag> Thanks dustymabe
17:11:12 <trishnag> No more Action items left from last meeting.
17:11:54 <trishnag> I have something to say.
17:12:26 <dustymabe> go for it
17:12:43 <trishnag> I am working on https://github.com/trishnaguha/build-atomic-host . If someone wants check it out...Feel free to open issues/PR. The aim is convert it all to playbooks and automate all.
17:13:33 <jbrooks> I saw this on twitter, I'll give it a runthrough
17:13:56 <trishnag> jbrooks: Awesome! Looking for more eyes :-).
17:14:21 <miabbott> trishnag: is this based off of jlebon's workshop?
17:14:30 <tflink> is that intended to become the new way for building atomic images in fedora?
17:14:41 <roshi> so, I didn't know if we as a group wanted to come up with a ansible-best-practices guide for our tests and whatnot
17:14:43 <trishnag> miabbott: Yes that idea came to me after I tried his workshop.
17:14:48 <roshi> since we'll be producing a lot of playbooks
17:14:49 <miabbott> trishnag: awesome
17:14:58 <dustymabe> tflink: I don't think so
17:15:51 <trishnag> tflink: Nope. I am just going for automate it *all*.
17:15:52 <tflink> what is the goal of this project, then? won't it produce things which are different from the officially released bits?
17:16:00 <walters> i'd like at some point to have a more "all in one" high level experience as a single docker image that contains a webserver/jenkins/etc that you can pull down and run in a kube/openshift cluster
17:16:08 <jbrooks> Is there a link to jlebon's workshop?
17:16:12 <tflink> trishnag: I don't understand "automate it all" - what is "it"?
17:16:29 <trishnag> jbrooks: yes http://jlebon.com/devconf/slides.pdf
17:16:41 <maxamillion> walters: what's the goal there? doesn't openshift have built-in jenkins magic?
17:16:53 <dustymabe> walters: can you write down your requirements for that "all in one" experience?
17:17:07 <dustymabe> and post them somewhere? maybe in an atomic-wg issue?
17:17:27 <jbrooks> trishnag, this script you use, is that how he builds the images? It's different from how centos and fedora do it
17:17:36 <jbrooks> I mean the qcow script
17:17:43 <trishnag> tflink: well I mean the whole process that I don't want to do manually.
17:18:06 <walters> dustymabe, start container, web UI has a few questions for what the tree name is, what packages you want to add, and watches for input and auto-recomposes
17:18:29 <trishnag> jbrooks: I am looking forward to convert that shell script to playbook. and include all the playbooks in one single playbook.
17:18:48 <walters> so this type of ansible setup would be part of a jenkins job or whatever in this model
17:18:53 <jbrooks> trishnag, I think it'd be worthwhile to converge on the toolchain for this
17:19:13 <dustymabe> jbrooks: yeah, i agree with you on that
17:19:35 <trishnag> jbrooks: I didn't get you.
17:19:50 <tflink> it seems to me that building images differently from how releng (fedora, centos, wherever) is doing things could lead to bugs that are difficult if not impossible to reproduce in one of the environments
17:20:01 <tflink> not that it shouldn't be done, just voicing a concern
17:20:08 <jbrooks> trishnag, You're building the qcow in one way, centos does it in another, and fedora does it in a third
17:20:23 <dustymabe> jbrooks: does centos not use imagefactor?
17:20:25 <jbrooks> I've been meaning to make centos adopt what fedora's using
17:20:54 <trishnag> jbrooks: hmm. I agree as well.
17:21:03 <jbrooks> rpm-ostree-toolbox, which does call on imagefactory
17:21:04 <kushal> jbrooks, +1 to that :)
17:21:28 <jbrooks> is what centos uses
17:22:21 <dustymabe> cool
17:22:40 <trishnag> okay Let's move to the meeting items. We can have this discussion in the channel later.
17:23:23 <trishnag> #topic Syncing released Fedora container images to Docker Hub https://pagure.io/atomic-wg/issue/202
17:23:41 <dustymabe> maxamillion: ^^
17:23:48 <maxamillion> o/
17:23:52 <maxamillion> info in the ticket
17:24:15 <dustymabe> same namespace sounds reasonable - do we care at all about versioning?
17:24:28 <maxamillion> basically, if we want to keep the namespace there needs to be a hand-off of credentials to either Fedora RelEng or Infra and I don't know who has them
17:24:39 <dustymabe> i.e. fedora 25 version of a container image vs fedora 24 version of a container image?
17:24:40 <miabbott> dustymabe: you can just version with tags, no?
17:24:52 <maxamillion> we have a whole naming scheme
17:24:54 <scollier> maxamillion, credentials for the docker hub acct?
17:24:57 <maxamillion> scollier: yes
17:25:00 <scollier> maxamillion, i do
17:25:12 <maxamillion> I documented the naming scheme and asked for feedback, there was like a 3 week long thread about this
17:25:17 <maxamillion> what do you mean "versioning"?
17:25:46 <dustymabe> maxamillion: ignore me
17:25:51 <dustymabe> you've got it all handled
17:26:37 <maxamillion> dustymabe: we can bring that back up if you like
17:27:00 <maxamillion> dustymabe: there was coordination with the modularity folks and factory 2.0 though so if we re-open that can of worms then we need to rope everyone back in
17:27:23 <dustymabe> nope. i'm good with it
17:27:39 <maxamillion> dustymabe: let me make sure it's all documented on the wiki properly
17:27:53 <scollier> maxamillion, i'll connect with you later on handing over the creds
17:28:05 <maxamillion> dustymabe: yeah -> https://fedoraproject.org/wiki/Container:Guidelines#Registry_Layout
17:28:16 <dustymabe> maxamillion: does this solve the "we can't release containers yet" problem?
17:29:03 <maxamillion> dustymabe: it does not, but we actually can release containers as of yesterday, we just can't do it fully automated yet ... I'm working on having that done in the next day or two (was hoping to have it done before this meeting, but reality slapped me in the face)
17:29:17 <maxamillion> dustymabe: we can release containers, we just can't sync them to the hub yet
17:29:24 <dustymabe> k
17:29:31 <dustymabe> because we don't have creds?
17:30:00 <maxamillion> dustymabe: right, we also need to write the code to do it because docker hub auth is weird
17:30:04 <maxamillion> dustymabe: https://paste.fedoraproject.org/551182/48657498/
17:30:43 <kushal> maxamillion, btw, do we have ways to handle docker images for other arch (aarch64)?
17:31:19 <maxamillion> dustymabe: also, that catalog manifest is partially wrong because I need to clean some of that up due to a bug that was pushing images to the wrong registry ... but that's known
17:31:31 <dustymabe> k
17:32:05 <maxamillion> kushal: not one implemented yet, but there is a plan in place and the upstream OSBS dev team has started working on it ... we're probably 6 months out from alt-arch container builds in koji
17:32:18 <dustymabe> btw are people about to make "epel containers" with our current setup?
17:32:23 <dustymabe> there was somebody today that asked about this
17:32:28 <kushal> maxamillion, Okay, thanks.
17:32:45 <maxamillion> kushal: there's a big 40-ish page design doc if you'd like to view it, I can forward it to you
17:33:53 <maxamillion> dustymabe: not currently in scope, nobody asked for it ... that gets murky though because the FROM line in the Dockerfile would then need to point to a RHEL image and I don't even want to think about that kind of licensing stuff
17:34:12 <kushal> maxamillion, thanks, send me that when you have time :)
17:34:41 <kushal> maxamillion, there was a question asked by the rkt devels about the aarch64 Fedora images, now I have an answer :)
17:34:42 <maxamillion> kushal: inbound
17:34:47 <kushal> maxamillion, Thank you :)
17:34:51 <maxamillion> kushal: certainly
17:34:52 <dustymabe> maxamillion: well not rhel, but centos, but let's table for later
17:34:58 <dustymabe> next topic?
17:35:03 <maxamillion> dustymabe: nope, EPEL doesn't build against CentOS in koji
17:35:14 <maxamillion> dustymabe: I think there's a policy against it actually
17:35:37 <maxamillion> dustymabe: because of some areas where there are ABI inconsistencies and it can cause bugs (it's super rare, but there have been cases in the past)
17:35:46 <dustymabe> i mean creating a layered container that is based on centos but installs epel packages
17:36:14 <maxamillion> dustymabe: that's a lot of grey area, let's table
17:36:20 <dustymabe> yes
17:36:27 <trishnag> okay
17:36:30 <maxamillion> all of this is *way* outside the scope of the ticket currently being discussed :)
17:36:44 <trishnag> next topic :)
17:36:44 <kushal> :)
17:36:49 <trishnag> #topic Planning for the first Atomic VFAD https://pagure.io/atomic-wg/issue/201
17:36:50 <maxamillion> trishnag: +1
17:36:59 <jbrooks> dustymabe, there's a centos build service, as well
17:37:14 <trishnag> maxamillion: ^^
17:37:56 <maxamillion> for this topic, I was basically going to formally writeup the workflow I sent to the mailing list and then create a bunch of tickets for the VFAD around bring the various Fedora-Dockerfile images into DistGit and suggest tomorrow be the first VFAD (as per the original workflow proposal)
17:38:15 <maxamillion> also, should I write that up to the atomic-wg pagure README or should I put it in the wiki somewhere?
17:38:28 <trishnag> maxamillion: +1
17:38:48 <maxamillion> and if I do the atomic-wg README, what format do people want? markdown, sphinx reStructuredText, or asciidoc ?
17:38:53 <trishnag> We can put it on atomic-wg README
17:39:02 <trishnag> May be markdown.
17:39:15 <kushal> markdown
17:39:22 <kushal> README is for simple things.
17:39:24 <roshi> I like markdown since I rarely render things before I try to read them :p
17:39:29 <maxamillion> I prefer reST but don't care enough if others prefer something else
17:39:30 <kushal> Markdown is better for that.
17:39:47 <maxamillion> alright, looks like markdown is the winner
17:39:49 <kushal> maxamillion, I prefer reST for real big documentation :)
17:39:57 <maxamillion> kushal: I prefer reST for *everything* ;)
17:40:14 * tflink is also in the reST for everything camp but I'm in the peanut gallery here
17:40:21 * roshi is really agnostic
17:40:25 <kushal> maxamillion, that is cool :)
17:40:32 <roshi> I wouldn't take issue with either really
17:40:36 <maxamillion> I'll write up the workflow in the README.md and send a pull request, I will also spend some of the afternoon gettin tickets filed according to that workflow under a milestone and we'll have a VFAD tomorrow
17:40:39 * kushal does presentations in reST.
17:40:51 <trishnag> Awesome!
17:40:57 <maxamillion> kushal: oh yeah? what tool?
17:41:16 <kushal> maxamillion, will tell you in the other channel (outside of meeting).
17:41:20 <maxamillion> kushal: +1
17:41:29 <trishnag> kushal: :)
17:41:34 <trishnag> #topic Planning for interim container releases: To rebuild or not rebuild? https://pagure.io/atomic-wg/issue/200
17:41:38 <dgilmore> maxamillion: dustymabe: we do have a policy of building against RHEL
17:41:47 <maxamillion> dgilmore: +1 thanks
17:42:13 <dustymabe> yes. but i will point out that that's not what I was talking about
17:42:28 <dustymabe> wasn't talking about building epel rpms at all
17:42:39 <jbrooks> But the base image?
17:42:46 <maxamillion> alright, so this ticket is kind of long winded, but the idea here is that the automated rebuild code just isn't ready yet because it keeps getting bumped in priority so we either need to write something in the mean time that will automatically rebuild all container images with updated RPM content before we release or be alright with telling maintainers that they need to do that
17:42:59 <maxamillion> jbrooks: what?
17:43:02 <jbrooks> sorry
17:43:28 <jbrooks> I'm +1 to rebuilding the images automatically to pick up new pkgs
17:43:36 <dustymabe> hmm
17:43:43 <dustymabe> could it be a two pronged approach?
17:43:58 <dustymabe> like automatically rebuild, but then make it go through testing before release?
17:44:09 <maxamillion> dustymabe: absolutely
17:44:14 <jbrooks> in addition to koji?
17:44:19 <jbrooks> I mean bodhi
17:44:20 <maxamillion> dustymabe: however, we need to get the testing stuff in place
17:44:39 <maxamillion> jbrooks: automated tests, this won't be a human-gating system
17:44:41 <dustymabe> oh yeah? why not just do what we do for bodhi now?
17:44:48 <maxamillion> noooooope
17:44:49 <roshi> docker container testing stuff?
17:44:52 <jbrooks> maxamillion, OK, automation is fine
17:44:56 <roshi> what system tests the docker containers?
17:45:08 <maxamillion> bodhi handling non-RPM content is like 6-months to a years worth of work
17:45:18 * roshi wasn't aware of anything for that
17:45:21 <trishnag> dustymabe: AFAIK bodhi won't support that for now
17:45:23 <maxamillion> that whole system assumes that the one true release artifact is RPMs
17:45:25 <jbrooks> I was prepared to expect that if the RPMs worked, the container should work
17:45:34 <maxamillion> roshi: tflink wrote it, it's in staging iirc
17:45:38 <jbrooks> And to test that case when I give karma in bodhi
17:45:52 <dustymabe> ok
17:45:52 <dgilmore> afaik the container testing is supposed to happen in taskotron
17:46:00 <roshi> I'll talk to tflink then :)
17:46:08 <tflink> it's just shell scripts, honestly
17:46:12 <dgilmore> wiring up container testing to provide rpm feedback and help push things through the queue would be awesome
17:46:19 <maxamillion> jbrooks: that's not always true though ... "the part itself working doesn't inherently mean the sum of parts will work together"
17:46:24 <tflink> we never got a coherant answer on how to test containers in an abstractable fashion
17:46:34 <maxamillion> tflink: shell scripts :)
17:46:37 * roshi is still getting up to speed on what all is happening
17:46:41 <maxamillion> tflink: containers are the wild west
17:46:45 * roshi continues to drink from the firehose
17:46:50 <maxamillion> roshi: nothing, we're just making it up as we go
17:46:54 <jbrooks> Sure, stuff breaks, we fix it ;)
17:47:19 <maxamillion> jbrooks: right, but how do gate that before it goes out the door?
17:48:07 <tflink> maxamillion: you're always obsessing over the details ...
17:48:10 <jbrooks> More testing is cool, if we can manage it -- we could always test everything more
17:48:10 * tflink ducks
17:48:17 <jbrooks> And never ship :)
17:48:18 <kushal> jbrooks, +1 to that.
17:48:19 <dgilmore> tflink: thats probably my fault
17:48:20 <kushal> :)
17:48:41 <maxamillion> basically my short-term plan is this .... automatically rebuild (re docker build, not rebuild rpms) all known container images, then release them
17:48:51 <tflink> dgilmore: there were implicit <sarcasm></sarcasm> on that
17:48:59 <jbrooks> Sounds good
17:49:01 <maxamillion> we'll introduce the automated test component as soon as we have tests in place
17:49:12 <maxamillion> which will actually be pretty easy thanks to the magic of fedmsg
17:49:27 <maxamillion> this whole thing is wired together around fedmsg at the moment
17:50:24 <trishnag> We can move to the next ticket now.
17:50:27 <maxamillion> +1
17:50:28 <dgilmore> tflink: :P I know but its still likely my fault. I keep beating maxamillion over the head, details details details
17:50:36 <trishnag> #topic Future of Fedora Dockerfiles https://pagure.io/atomic-wg/issue/180
17:50:37 <maxamillion> dgilmore: <3
17:50:57 <maxamillion> I think this ticket is more or less answered with the VFAD activities that are planned
17:50:58 <trishnag> I think we can remove *meeting* tag from this ticket
17:51:03 <scollier> this is what i was going to add: https://github.com/scollier/Fedora-Dockerfiles/tree/readme-update
17:51:15 <scollier> somethign like that to direct people to the layered image build service
17:51:22 <maxamillion> scollier: +1
17:51:22 <scollier> and drop the cloud mailing list for questions
17:51:33 <dustymabe> scollier: +1
17:51:37 <scollier> k
17:51:44 <scollier> i'll add that to any remaining PRs as well.
17:51:44 <scollier> thanks
17:51:52 <dustymabe> also, we should discuss what to do with our existing fedora images in docker hub?
17:51:58 <trishnag> scollier: Perfect :).
17:52:58 <jbrooks> dustymabe, get them into the build service, I'd say
17:53:11 <dustymabe> jbrooks: yeah, at least for the popular ones
17:53:18 <trishnag> jbrooks: +1
17:54:21 <jbrooks> there's only like 16, it looks like
17:54:28 <maxamillion> dustymabe: that's actually a good point because the docker hub stuff isn't really going to be able to follow our registry naming convention
17:55:02 <maxamillion> can we get a list of the ones we want to migrate over tomorrow? that way I'm not making tickets for work to be done for things that nobody really cares about? :)
17:55:08 <dustymabe> https://hub.docker.com/u/fedora/?page=1
17:55:34 <kushal> I hope we will get tests written for each of the containers separately.
17:55:48 <maxamillion> kushal: that's the hope/plan
17:56:03 <kushal> maxamillion, :)
17:56:07 <maxamillion> tflink: are the TestGit (naming?) changes in place so we can at least start throwing tests somewhere?
17:56:27 <maxamillion> tflink: also, I owe you testing in stage, I'll do that today
17:56:32 <tflink> maxamillion: I'm writing that up as we speak
17:56:37 <maxamillion> tflink: you're the best
17:56:43 <trishnag> Let's discuss this on the channel after the meeting as we do not have much time :).
17:56:46 <maxamillion> +1
17:56:52 <maxamillion> alright, next ticket
17:56:54 <trishnag> #topic Ship fedora-motd in F24 atomic image https://pagure.io/atomic-wg/issue/160
17:57:12 <trishnag> rtnpro: ^^
17:57:36 * dustymabe has a few items for open floor
17:57:57 <trishnag> Not sure if rtnpro is around.
17:58:02 <trishnag> #topic design, deploy and document Fedora OpenShift Playground (FOSP) https://pagure.io/atomic-wg/issue/153
17:58:39 <trishnag> Let's move to open floor.
17:59:01 <trishnag> scollier: You can update the ticket :)
17:59:06 <trishnag> #topic Open Floor
17:59:13 <trishnag> dustymabe: There you go.
17:59:24 <kushal> trishnag, :)
17:59:25 <tflink> I don't know if this has been dealt with already but has there been movement to make the atomic host image(s) release blocking for Fedora?
17:59:46 <dustymabe> so 1 - we are making some changes in releng that make it so that users will only get an "updated" ostree whenever we do a release
17:59:47 <tflink> last I heard, that process hadn't been started but I could easily be wrong on that
18:00:10 <kushal> tflink, We can in next release, but Atomic images are following a different release cycle all together.
18:00:15 <walters> just a quick note, the next releases of ostree and rpm-ostree are going to be larger; ostree is going to gain an optional libcurl backend, and we're starting to (optionally) use Rust a little bit.  rpm-ostree's core is a lot more powerful now
18:00:31 <kushal> walters, yay to that :)
18:00:45 <kushal> walters, great to hear the Rust part :)
18:01:14 <dustymabe> 2 - i had a chat with matt and steven from the server wg
18:01:16 <walters> a bit more info in https://github.com/ostreedev/ostree/pull/656 - if it goes well i may look at doing some in rpm-ostree too
18:01:21 <mattdm> larger in the code sense, or in the "it's now a 2.7gb binary!" sense?
18:01:28 <maxamillion> walters: plans to rewrite everything in rust?
18:01:35 <dustymabe> we are going to leave the cloud base image along for the f26 release
18:01:40 <tflink> kushal: it's hard for QA to justify focusing on atomic over other things when it's not release blocking. I understand what you're saying but there needs to at least be some conversation around how all that is going to be handled if/as atomic host becomes more important
18:01:41 <walters> maxamillion, the great thing is, it can be incremental
18:01:46 <maxamillion> walters: because that'd be super cool :)
18:01:51 <maxamillion> walters: +1
18:01:56 <walters> so it doesn't have to, and won't be everythign
18:02:04 <dustymabe> it will remain like it has been in the past. I'm thinking about making another issue tracker for cloud base image issues
18:02:14 <walters> i had some worries about alternative architectures but it looks like that's in pretty good shape
18:02:19 <maxamillion> walters: +1
18:02:21 <maxamillion> cool :)
18:02:28 <kushal> tflink, correct, that is why I said we can do it in future.
18:02:47 <dgilmore> speaking of Alternative Architectures
18:02:54 <kushal> walters, Now firefox is dependent Rust, so that will help in the alternative archs.
18:02:58 <trishnag> dustymabe: Sounds good.
18:02:59 <kushal> * dependent on
18:03:01 <dustymabe> looks like open floor turned into a free for all
18:03:07 <dgilmore> I wanted to see if there was interest in adding some for atomic host in f26/f27
18:03:32 <maxamillion> dustymabe: basically
18:03:35 <dustymabe> dgilmore: i believe peter did a talk on this :) - I believe there is interest
18:03:38 <maxamillion> dgilmore: +1
18:03:48 <trishnag> dustymabe: Would you like to move this conversation to our main channel?
18:03:55 <kushal> dgilmore, yes, for aarch64 :)
18:03:55 <dgilmore> if so a change should get filed
18:03:55 <trishnag> We are running out of time :)
18:04:03 <dgilmore> and we can work on the config side
18:04:05 <maxamillion> dgilmore: +1
18:04:08 <kushal> But first we need to be able to use our pine64 :)
18:04:28 <trishnag> 5
18:04:30 <trishnag> 4
18:04:36 <trishnag> 3
18:04:36 <trishnag> 2
18:04:36 <trishnag> 1
18:04:39 <trishnag> #endmeeting