15:13:00 <pknirsch> #startmeeting Fedora Base Design Working Group (2014-07-11)
15:13:00 <zodbot> Meeting started Fri Jul 11 15:13:00 2014 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:13:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:13:05 <pknirsch> bop
15:13:15 <pknirsch> #meetingname  Fedora Base Design Working Group
15:13:15 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:13:25 <moben> (which can be found here https://github.com/moben/buildreq-check if someone wants to take a look, but I'll need to clean it up some more ;) )
15:13:31 <pknirsch> #chair dgilmore, haraldh, jreznik, masta
15:13:31 <zodbot> Current chairs: dgilmore haraldh jreznik masta pknirsch
15:13:53 * pknirsch will paste the start of the meeting later on
15:13:56 <vpavlin> moben: Good to see somebody will do the real work in this area:)
15:14:07 <pknirsch> #topic Introduction of Benedikt Morbach, intern working on buildreq reduction (and potential other stuff if time permits ;))
15:14:15 * pknirsch nods
15:14:41 <haraldh> just for the log:
15:14:43 <haraldh> <moben> My name is Benedikt and when I'm not pknirsch's new intern I study maths and computer science in Chemnitz, Germany
15:14:43 <pknirsch> just FYI moben, vpavlin has been working on minimal Docker images, and getting the requirements reduced is one key part of being able to do that
15:14:51 <haraldh> <moben> (which I intend to finish later this year)
15:14:54 <haraldh> <moben> In my spare time, I'm also a packager at Exherbo Linux, a source based distro with a package format similar to Gentoo's (though we are not derived from Gentoo, strictly speaking)
15:15:00 <haraldh> <moben> Since joining rh, I've read quite a few packaging guidelines, did some informal reviews and wrote a little script to check for unneeded buildrequires
15:15:23 <moben> thanks haraldh :)
15:15:26 <vpavlin> moben: Yes, I guess we will be in touch regarding this
15:16:15 * msekleta interested in approach taken, has to look at script in detail
15:16:19 <moben> vpavlin: you can reach me here on freenode pretty much any time of the day, or as bmorbach@rh
15:16:26 <haraldh> btw, do we have a tool, which given a package set, will reduce it to a minimal package set? meaning, the rest is pulled in via deps?
15:16:27 <pknirsch> Ok, great, thanks for the info moben. And maybe we can convert you to be a Fedorian ;)
15:16:42 <jreznik> pknirsch: +1
15:16:45 <pknirsch> :)
15:17:46 <pknirsch> haraldh: hm, basically a dep graph reduction tool? don't think we do yet.
15:18:00 <haraldh> would be nice to have
15:18:02 <pknirsch> but it's a very interesting idea
15:18:03 <pknirsch> yea
15:18:11 * pknirsch eyes moben :)))))
15:18:32 <haraldh> also, "show-installed" could be improved
15:19:05 <pknirsch> jup, but thats more of a yum/dnf issue and a rework of how installs are being tracked. and iirc ffesti was looking into that lately
15:19:13 <haraldh> or, "show-installed" could be extended to do just what I requested
15:19:15 <moben> pknirsch: heh. I'll take a look
15:19:31 <pknirsch> moben: excellent. :) feel free to ask holes into me or haraldh :)
15:19:59 <pknirsch> alright, lets move on though, only got 40 minutes left!
15:20:11 <pknirsch> #topic Talk with Michal Sekletar as candidate for WG
15:20:18 <moben> pknirsch: iirc dnf already tracks explicitely installed vs. just deps
15:20:30 <pknirsch> moben: ah, good to know :)
15:21:05 <pknirsch> Alright, so msekleta has stepped up to be a replacement for Bill or Josh, and i think he's here with us today, right?
15:21:29 <msekleta> msekleta, hello everyone
15:21:38 <pknirsch> hello msekleta !
15:21:44 <haraldh> msekleta, hey unknown stranger :)
15:22:00 <msekleta> haraldh, :)
15:22:15 <pknirsch> So in case people haven't read your introduction, can you tell us a bit about what you do and what you'd like to achieve in Base? :)
15:22:24 <msekleta> pknirsch, sure
15:23:15 <msekleta> My name is Michal Sekletar and I am with Red Hat for almost three years now. I work in Server-Experience team in "Plumbers" group.
15:23:46 <msekleta> I am maintainer on some networking related packages in Fedora and RHEL and I also help with maintaining systemd in RHEL
15:25:29 <msekleta> I'd like to help to integrate docker and systemd in Fedora as part of my initiatives in WG
15:25:50 <mattdm> msekleta: cool :)
15:25:56 <pknirsch> ace!
15:26:03 <msekleta> We (lnykryn, vpavlin and me) did some work on RHEL front so I want to make sure Fedora is not left behind
15:26:13 <pknirsch> mhm
15:26:48 <mattdm> msekleta: +1000  yes let's do things in the right order :)
15:27:21 <pknirsch> I definitely agree thats a very important goal. And imho Base is pretty much spot on, together with mattdm and his Cloud WG, but i strongly believe the collaboration will work fine. :)
15:27:24 <msekleta> mattdm, that is my goal too
15:28:40 <pknirsch> And from what i recall Server expressed some interest for Docker support as well
15:28:56 <jreznik_q102> and env and stacks too
15:29:00 <pknirsch> right
15:29:10 <jreznik_q102> vpavlin is here too
15:29:14 <pknirsch> Lets make Docker awesomer!
15:29:23 <mattdm> and possibly workstation -- see recent blog posts on docker for application containers
15:29:23 <pknirsch> aye
15:29:30 <pknirsch> oh!
15:29:32 <mattdm> (desktop application sandboxing)
15:29:39 <pknirsch> great to see they want to use Docker for that too.
15:29:43 <pknirsch> then it's a perfect match
15:29:53 <mattdm> pknirsch: details are still hazy :)
15:29:57 <pknirsch> hehe :)
15:30:17 <vpavlin> mattdm: I've already used it to run MonoDevelop and even M$ Office (don't beat me!
15:30:42 <pknirsch> Any questions for msekleta from anyone? haraldh, dgilmore, masta, jreznik_q102 ?
15:30:56 <msekleta> I forgot to mention, that of course, I want to help with whatever else is on WG's plate
15:31:00 <haraldh> pknirsch, he is in my team.. no questions from my side :)
15:31:07 <pknirsch> haraldh: nerf!
15:31:09 <pknirsch> :)
15:31:37 <masta> I'd like to see a conservative approach to docker, it is good stuff... but there has been worries about their use of go-lang or whatever and how that relates to secondary architectures.
15:32:33 <masta> but anyhoo...
15:32:48 <pknirsch> IBM has already expressed interest to get it all working on ppc64 masta, and thanks to mattdm they are now on the right track :)
15:32:54 <mattdm> masta definitely a "but anyhoo", but I think the long-term plan will be gcc-go
15:33:04 <vpavlin> masta: well, I see a problem in conservative approach - I we don't do it, someone else will and we migh stay behind:)
15:33:44 <pknirsch> We just need to get IBM then to help. How is ARM looking regarding go-lang?
15:34:11 <dgilmore> sorry distracted with branching tasks
15:34:14 <pknirsch> and agree mattdm, gcc-go would be very nice to get working.
15:34:52 <dgilmore> I think docker belongs in the server and cloud working groups more so than base, but not opposed to having it in base
15:35:30 <mattdm> I have some other things I'd like to discuss so let's not decide that now :)
15:35:38 <dgilmore> right no docker upstream supports x86_64 only and seems to have some major design flaws in the regsitry as to dealing with arches, i.e. they dont
15:35:38 <msekleta> I want to emphasize that I want to make sure that WG's packages play nice with docker and nspwan and other container solutions. So question of docker supporting whatever arch is not important to me that much.
15:35:47 <mattdm> (i meannot re msekleta; totally other topics.)
15:36:44 <dgilmore> anyway, making sure fedora plays nice will all is important
15:36:50 * pknirsch nods
15:36:55 <masta> msekleta: any experience with secondary architectures?  I'm asking because the Base WG has to strike a balance between awesome new features, and the broader view of of the whole distro, including other architectures. .
15:37:54 <msekleta> masta, not really except running Raspberry Pi at home. I guess that doesn't count really :)
15:38:52 <masta> fair enough =)
15:39:24 <pknirsch> We should be able to assist msekleta with folks, getting 2 more people into the secondary team soonish. :)
15:39:43 <msekleta> of course I do builds for ppc and s390 when working on RHEL
15:40:06 <pknirsch> mhm
15:40:55 * mattdm afk for 5 minutes
15:40:57 <pknirsch> So lets do a quick vote about msekleta becoming a member then.
15:41:13 <pknirsch> #vote Vote for msekleta becoming a member of the Base WG
15:41:23 <jreznik_q102> +1
15:42:39 <masta> I'm undecided so +0
15:43:22 * jreznik_q102 knows msekletar personally, so he knows who he votes for
15:43:53 <pknirsch> :)
15:43:57 <pknirsch> +1
15:44:24 <pknirsch> dgilmore, haraldh?
15:44:31 <haraldh> +1
15:44:35 <dgilmore> +1
15:44:44 <pknirsch> thats a clear winner :)
15:45:15 <vpavlin> msekleta: congrats
15:45:19 <msekleta> thanks everyone
15:45:22 <pknirsch> congratulations msekleta :)
15:45:26 <pknirsch> and welcome in the WG!
15:45:36 * pknirsch can't remember how to record voting results
15:45:41 <pknirsch> anyone knows ?
15:46:39 <masta> congrats msekleta =)
15:46:52 <pknirsch> ah
15:46:53 <vpavlin> # agreed ?
15:46:59 <masta> pknirsch: maybe # agree
15:47:01 <pknirsch> yep, just found it
15:47:08 <msekleta> masta, thanks
15:47:26 <pknirsch> #agreed Vote for msekleta as WG member (+4:1:-0) accepted
15:47:55 <pknirsch> now lets quickly go over to topic 3 for today and then open the floor (i think mattdm had a few items)
15:48:10 <pknirsch> #topic Vaclav Pavlin presenting minimal Docker image for Fedora (133MB)
15:48:16 <pknirsch> vpavlin, your show :)
15:48:36 <vpavlin> Ok, so...everything important can be found http://vpavlin.fedorapeople.org/fedora-base-image/
15:48:38 <jreznik_q102> what about other seats? I hope vpavlin would be interested in ;-)
15:48:49 <pknirsch> hm, good point jreznik_q102
15:50:15 <vpavlin> If you check the ks file http://vpavlin.fedorapeople.org/fedora-base-image/container-fedora-small-20.ks you can see we were able to get rid of languages other then EN
15:50:28 <vpavlin> it's here: %packages --excludedocs --instLangs=en
15:50:36 <pknirsch> nice :)
15:50:44 <pknirsch> how many packages are in the image in the end?
15:50:50 <vpavlin> and then few lines foloowing the LANG="en_US"
15:51:10 <vpavlin> 114 if I don't use fakesystemd
15:51:16 <vpavlin> 112 if I use fakesystemd
15:51:18 <pknirsch> impressive!
15:51:20 <masta> vpavlin: so this is the output of docker stuff?
15:51:37 <vpavlin> Review reqquest for fakesystemd is here https://bugzilla.redhat.com/show_bug.cgi?id=1118740
15:51:51 <vpavlin> masta: What do you mean?
15:52:07 <vpavlin> the *.tar.gz file?
15:52:48 <vpavlin> http://vpavlin.fedorapeople.org/fedora-base-image/vpavlin-fedora-20.tar.gz is docker image which can be loaded with docker load -i vpavlin-fedora-20.tar.gz
15:53:14 <masta> right
15:53:25 <vpavlin> I haven't pushed the image to registry yet so to test it, you need to download the tar file and load it to docker
15:54:06 <pknirsch> Do you have a small README or wiki that describes how to do that? or is it dead easy and already described in docker readmes or howtos?
15:54:22 <masta> cool, so I'll checkout the fakesystemd... we for sure don't want all that kruft in a minimal image
15:54:35 <vpavlin> This is for F20, Rawhide is a bit bigger and contains more packages because I wasn't able to get rid of firewalld and it's dependencies - this is still under investigation
15:54:41 <masta> not sure kruft is the right word
15:54:53 <pknirsch> imho it is, masta :)
15:55:04 <vpavlin> pknirsch: I don't but will create one
15:55:30 <pknirsch> thanks vpavlin. just to lower the hurdle to test it
15:55:37 <vpavlin> pknirsch: sure
15:55:57 <pknirsch> cool :)
15:56:05 <pknirsch> any other questions for vpavlin ?
15:56:40 <vpavlin> there is this bug mattdm filed https://bugzilla.redhat.com/show_bug.cgi?id=1004976 which seems to be solved but I am still not able to build an image with firewalld --disable option
15:57:53 <masta> vpavlin: want anyone here to attempt to reproduce? is that .ks file enough to get started?
15:57:57 <vpavlin> Regarding building images I use appliance-tools and hope to have docker image building capabilities integrated to koji soon
15:58:21 <dgilmore> vpavlin: we have docker support underway
15:58:25 <masta> vpavlin: nice
15:58:27 <dgilmore> it will be using anaconda
15:58:46 <vpavlin> masta: Yes, you just need mattdm's script...
15:58:46 <mattdm> vpavlin please coordinate with imcleod and jgreguske on this
15:58:51 * vpavlin tries to find the link
15:59:09 <dgilmore> vpavlin: going forward we will not be using appliance-tools for image building
15:59:18 <vpavlin> mattdm, dgilmore: Yes, I follow the discussions
15:59:35 <mattdm> vpavlin: okay cool. just making sure.
15:59:58 <vpavlin> #link https://git.fedorahosted.org/cgit/cloud-kickstarts.git/tree/container/buildcontainers.sh
16:00:25 <vpavlin> mattdm:  sure
16:01:07 <mattdm> vpavlin  I think maybe the firewalld thing is fixed in anaconda but not in appliance-tools. (example of one reason why we wanted to consolidate tools....)
16:01:40 <vpavlin> mattdm: Yeah, I guess so
16:01:57 <masta> vpavlin: thanks, bookmarked.
16:02:29 <vpavlin> mattdm: I could use simple yum install and maybe make the image even smaller, but I wanted to build it at least similarly as it will be in koji
16:02:57 <masta> mattdm: I think your hunch on firewalld is highly likely
16:03:15 <vpavlin> How does the build of "official" Fedora  image work?
16:03:20 * mattdm doesn't care as long as it's in koji and meets releng requirements _and_ has a commitment to ongoing upstream support
16:03:25 <vpavlin> Or who is responsible for building and pushing it?
16:03:40 <dgilmore> vpavlin: what do you mean by that?
16:03:42 <mattdm> vpavlin for docker? work in progress. lsm5 and dgilmore are working on it.
16:03:53 <masta> vpavlin: dgilmore and myself are on rel-eng, we do them... we have documentation we can share.
16:04:31 <vpavlin> dgilmore: I mean we have some official image - I was just interested how that is built and if there is some automation
16:04:56 <vpavlin> like if we rebuild rawhide nightly or so
16:05:02 <pknirsch> maybe vpavlin could work with dgilmore and masta on that and helping there?
16:05:22 <masta> pknirsch: absolutely
16:05:26 <vpavlin> Sure
16:05:26 <mattdm> vpavlin plan is to build it in koji with support jgreguske is adding, and then it'll get pushed to github for inclusion in stackbrew
16:05:42 <pknirsch> sweet :)
16:05:52 <vpavlin> mattdm: ok
16:06:09 <mattdm> and legal has given the okay for this btw, so we're basically down to "doing the stuff to make it actually go"
16:06:17 <pknirsch> :)
16:06:30 <vpavlin> mattdm: by the way do you have any plans for layered images in CloudWG? We are looking at them in Env&Stacks as well
16:06:51 <dgilmore> vpavlin: for docker today we do not have any official image
16:06:55 <dgilmore> we are working on it
16:06:57 <mattdm> vpavlin: not for f21. we're looking to env & stacks for that I think
16:07:35 <mattdm> but, until we see a user need / push, our _primary_ output will be the official base image, plus the "fedora-dockerfiles" package....
16:08:01 <mattdm> ... and we will use docker's automatic build feature to build layered images in _docker's_ infrastructure
16:08:03 <vpavlin> dgilmore: This one seems to be official a bit https://registry.hub.docker.com/_/fedora/ (well, it says semi..)
16:08:35 <mattdm> vpavlin yeah that's what we're working on fixing. don't look at it too hard :)
16:08:42 <vpavlin> mattdm: Ah, this is the first time I hear about "docker's automatic build feature"
16:08:51 <mattdm> vpavlin: they call it "trusted builds"
16:09:13 <mattdm> or they used to
16:09:19 <mattdm> "trusted" was a silly name
16:09:21 <mattdm> https://docs.docker.com/docker-hub/builds/
16:09:26 <masta> vpavlin: hopefully we have official docker images soon. (actual)
16:09:28 <dgilmore> vpavlin: its not offical at all
16:09:51 <vpavlin> masta, dgilmore: ok
16:09:53 * mattdm has to go in ten minutes... would like to at least bring up my other things :)
16:10:03 <pknirsch> sure
16:10:09 <pknirsch> so lets quickly move to open floor
16:10:15 <pknirsch> #topic Open Floor
16:10:15 * haraldh has to go now... sorry
16:10:21 <masta> bye haraldh
16:10:26 <pknirsch> and thanks vpavlin for the update on Docker and the great discussion
16:10:31 <pknirsch> cya haraldh !
16:10:34 <mattdm> yes thanks. there's more on this for later :)
16:10:41 <pknirsch> aye
16:10:41 <vpavlin> My pleasure
16:10:49 <mattdm> so here's my three things. or let's call it two things, the first of which has two parts. :)
16:11:19 <mattdm> 1a. Identifying different Fedora products -- fedora-release-* contents and /etc/os-release
16:11:49 <mattdm> 1b. having tools like yum and dnf talk to mirror manager in a way which lets us count product installs
16:11:54 <mattdm> and
16:12:07 <mattdm> 2. a "generic fedora" netinstall
16:12:31 <mattdm> for 1a, dgilmore, sgallagh, and I have had some discussion and there was some talk on the fedora-devel mailing list
16:12:43 <mattdm> but I think it's probably good to solve as a base design thing
16:12:49 <mattdm> dgilmore has some ideas for approaches
16:13:07 * sgallagh appears. *foop*
16:13:24 <mattdm> lennart suggested using ID in /etc/os-release and setting ID_LIKE to fedora, but that is a bigger distinction than I think we should make
16:13:48 <mattdm> it is still fedora, just with different flavor. we want SUB_ID or ID_FLAVOR or something.
16:14:01 <dgilmore> mattdm: 1b should be somewhat easy, add a $product to the url in the repos, we just need to make sure that yuma nd dnf can provide the value based on a config, like they get releasever
16:14:41 <dgilmore> mattdm: I really want the product definition to be in a seperate snippet file
16:14:46 <mattdm> additionally, /etc/os-release can of course only be owned by one package. that probably means moving it from fedora-release to fedora-release-*
16:14:59 <dgilmore> ideally in /etc/os-release.d/
16:15:08 <mattdm> and, I agree with dgilmore that a snippet is ideal, but then that makes /etc/os-release need to be generated
16:15:35 <dgilmore> mattdm: well /etc/os-release would be the base
16:15:39 <mattdm> I have to go so let me list the other background before I run off and then we can solve the details later. or y'all can while I'm gone :)
16:15:44 <dgilmore> and teh snippet the product on top of it
16:16:13 <mattdm> so for 1b, as dennis says, this is probably easy, but we need people to do any possible yum, dnf, and mirrormanager code changes and testing.
16:16:39 <pknirsch> have you talked with the rpm/yum guys yet mattdm?
16:16:40 <msekleta> dgilmore, I am not sure snippet is way to go. Introducing snippet make it sound like stuff is subject to user configuration, but it is not.
16:16:45 <mattdm> pknirsch: nope!
16:16:47 <pknirsch> resp. are the bzs open for those changes?
16:16:53 <pknirsch> :)
16:16:55 <mattdm> well, slightly with gepetto
16:16:59 <pknirsch> mhm
16:17:01 <vpavlin> How does the snippet makes our life easier? You probably don't want to change your os-release by dropping more snippets there, or do you?
16:17:18 <mattdm> wait let me describe item #2 quick :)
16:17:22 <msekleta> vpavlin, exactly my point
16:17:46 <dgilmore> vpavlin: it means we do not have to fork fedora-release for every product
16:17:50 <mattdm> 2. basically, it would be nice to have a spin (if not some other category of deliverable) which is just a generic, non-productized netinstall
16:18:02 <mattdm> no one seems to be looking at this
16:18:15 <vpavlin> dgilmore: But you would need the package containing the snippet anyway
16:18:19 <masta> ID_VARIANT
16:18:30 <dgilmore> mattdm: we had talked about doing a minimal tree in the basewg for anaconda testing
16:18:38 <mattdm> the workstation wg notes that they feel like it's kind of pushed on them (as desktop was the traditional "default install") but they don't really want it\
16:18:46 <mattdm> dgilmore: yeah, and also that
16:18:54 * vpavlin types really slowly with "exoskeleton" on his middle finger
16:19:00 <mattdm> server wg is doing a minimal netinstall, but it willb e productized
16:19:00 <dgilmore> vpavlin: the other way to do it would be to sed values in in %post. which is error prone
16:19:51 <mattdm> also, it seems like it is unlikely to be a huge qa burden (he says, cavalierly) because if minimal netinstall doesn't work it's unlikely anything *bigger* will
16:19:59 <mattdm> so those are my things. got to go.
16:20:01 <vpavlin> dgilmore: This smells like dynamic configuration, although os-release should be probably configure statically..
16:20:03 <mattdm> thanks yall
16:20:09 <pknirsch> thanks mattdm !
16:20:09 <dgilmore> mattdm: every product has to have an install tree. its the nature of the beast.
16:20:19 <mattdm> please solve all of my problems before I return
16:20:21 <mattdm> :)
16:20:26 <pknirsch> ha, as if :)
16:20:28 <dgilmore> mattdm: and world hunger?
16:20:29 * mattdm vanishes in a whisp of smoke
16:21:47 <masta> I think we need to tell workstation they are going to have an install tree, and it's not being forced on them. It just is.
16:22:15 <masta> facts persist despite not believing in them, kinda thing
16:22:34 <dgilmore> vpavlin: its flexible configuration
16:22:48 <pknirsch> Sure, but they could market their product with less emphasis on the install tree, thats really up to them.
16:23:01 <pknirsch> (or no emphasis ;))
16:23:01 <dgilmore> masta: ive already told them that it is and gave them valid use cases why they want it
16:23:10 <dgilmore> pknirsch: sure
16:23:24 <pknirsch> but it's still going to exist as masta and dgilmore said :)
16:23:40 <dgilmore> ennabling developers to pxe install development workstations is very important for office type situations
16:24:59 <pknirsch> jup
16:25:01 <vpavlin> dgilmore: You can change the name but you can't change the nature of it:) What I like about os-release is that it's consistent. When we start to generate it somehow or add snippets to it it might bring problems...maybe..some day...you know...hm
16:25:33 <pknirsch> vpavlin: but on the other hand it'll allow us and the release to be, well, flexible :)
16:26:21 <dgilmore> vpavlin: the issue I have is that if we need to have 4 or more different versions of it for 1 or 2 lines of change we have to split to different source rpms
16:26:34 <dgilmore> which makes changes of copy paste erros higher
16:26:53 <dgilmore> chances
16:27:32 <dgilmore> vpavlin: if rpm had a way to have the differnet sub packages have different versions of the same file, I would agree with you
16:27:34 <msekleta> dgilmore, iirc someone suggested on the list that it should even move to /usr/lib/os-release because it is vendor provided static file and not something configurable
16:27:50 <vpavlin> Are we sure there won't be more then 1 or 2 lines of change?
16:28:08 <dgilmore> msekleta: perhaps. then we could drop in product specific snippets in /usr/lib/os-release.d/
16:28:13 <dgilmore> vpavlin: yes
16:28:49 <vpavlin> ok then, no more objections to flexible way
16:29:32 * vpavlin realizes this is fun and he should maybe sign up for the seat:D
16:29:47 * moben also has to leave
16:29:48 <dgilmore> vpavlin: PRETTY_NAME="Fedora 21 (Twenty One)" is probably the only line that could change today to include the Product
16:29:49 <pknirsch> :)))
16:30:02 <moben> It was nice meeting you all, have a nice weekend :)
16:30:04 <pknirsch> cya moben ! and have a fantastic weekend!
16:30:10 <dgilmore> and  add a Product line taht yum/dnf can use to pass onto mirrormanager
16:30:14 <msekleta> moben, see you
16:30:21 <dgilmore> thanks moben have a great weekend yourself
16:30:35 <vpavlin> dgilmore: by the way I should bring the default.preset file to the table again...
16:30:57 <msekleta> vpavlin, wanted to post just that
16:31:01 <msekleta> vpavlin, please do
16:31:07 <vpavlin> The discussion on fedora-devel died without any result, iirc
16:31:29 <dgilmore> vpavlin: as i understand it we will be shipping different default.preset for each product. But as I understand it they can be dropped in as snippets
16:31:44 <vpavlin> dgilmore: yes and yes
16:32:04 <dgilmore> vpavlin: which makes it simple from a packaging perspective
16:32:25 <vpavlin> dgilmore: It does, but we need a package which will contain it
16:32:31 <dgilmore> vpavlin: fedora-release
16:32:40 <vpavlin> For all products?
16:32:41 <msekleta> vpavlin, yes fedora-release srpm
16:32:45 <dgilmore> vpavlin: yes
16:33:08 <msekleta> vpavlin, each product will have different version as Source: in that srpm
16:33:10 <dgilmore> vpavlin: each product has its own sub-package
16:33:18 <dgilmore> msekleta: no it wont
16:33:34 <dgilmore> msekleta: there will be only one source
16:33:50 <vpavlin> dgilmore: Ah, sub-package..sure..it will work for snippets, but not for os-rerlase, got it
16:34:27 <msekleta> dgilmore, so each subpackage will have snippet?
16:35:12 <msekleta> dgilmore, which will install as a customization on default.preset. Is that correct?
16:39:21 <vpavlin> Looks like the meeting died...or my IRC did..
16:40:03 <pknirsch> it's branch day today for rel-eng, so i suspect dgilmore is busy with that atm :)
16:40:42 <vpavlin> pknirsch: sure..what do you think about jreznik's suggestion that I should sign up for the seat?
16:40:57 <pknirsch> definitely! i think we got at least one more spot :)
16:41:19 <vpavlin> I am already part of Env&Stack WG so I am not sure if that's not against some policy to be in two WGs:)
16:41:35 <pknirsch> and together with msekleta, masta, dgilmore and mattdm i'm certain that would be awesome for Docker
16:41:42 <pknirsch> well
16:42:29 <pknirsch> I personally don't think it would be an issue. In contrast, i think if you'd be on both you could act as a binding to Env & Stacks with Base
16:43:40 <vpavlin> Ok, then - I'll reply to your email on fedora-devel
16:44:05 <dgilmore> msekleta: right
16:44:23 <dgilmore> sorry i keep getting distracted checking on wherethings are at
16:45:48 <pknirsch> alright, but lets wrap it up here, already late for europe folks.
16:46:15 * vpavlin is afraid to come home this late...
16:46:26 <pknirsch> we can continue on #fedora-devel or via mailinglist, but lets bring collect topics then for next week. I'd certainly revisit the stuff mattdm brought up, too
16:46:29 <pknirsch> he :)
16:46:46 <pknirsch> thanks everyone for joining today and have a great weekend. and good luck vpavlin :)
16:46:52 <pknirsch> #endmeeting