13:00:40 <hhorak1> #startmeeting Env and Stacks (2015-03-26)
13:00:40 <zodbot> Meeting started Thu Mar 26 13:00:40 2015 UTC.  The chair is hhorak1. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:45 <hhorak1> #meetingname env-and-stacks
13:00:45 <zodbot> The meeting name has been set to 'env-and-stacks'
13:00:55 <hhorak> #chair bkabrda hhorak juhp ncoghlan vpavlin sicampbell walters ttomecek phracek
13:01:01 <hhorak> #topic init process
13:01:18 <hhorak> hello, is here anybody after my late announcement?
13:01:37 <bkabrda> hhorak: I'm here :)
13:01:39 * hhorak ashamed
13:01:51 <phracek> hi
13:01:53 <hhorak> bkabrda: cau
13:02:01 <bkabrda> hey everyone
13:04:39 <hhorak> #topic follow-up: Dockerfiles recommended tips / dockerfile_lint
13:05:25 * hhorak feels ashamed that not much happened since the last meeting about this, hopefully I have more to say the next week
13:06:06 <hhorak> phracek: you said you had some difficulties with running dockerfile_lint on openshift?
13:06:40 <phracek> hhorak: yes. I have created a Cartridge on OpenShift from GitHub as was mentioned two weeks ago
13:07:20 <phracek> I have installed Node.JS application but How can run it so that it is going to be available for everyone?
13:07:48 <phracek> The OpenShift name is http://docker-phracek.rhcloud.com/
13:07:55 <phracek> #link http://docker-phracek.rhcloud.com/
13:09:01 <hhorak> phracek: maybe thrcka could help you, he's experience with nodejs at least, maybe even with openshift
13:09:19 <phracek> hhorak: ok, I will contact him.
13:09:45 <vpavlin> hhorak: Hello:)
13:09:59 <hhorak> vpavlin: hi, already boring?
13:10:15 <vpavlin> hhorak: That was "Hey, I'm here" hello:)
13:10:36 <hhorak> vpavlin: I know, I just wasn't expect you today :)
13:11:16 <vpavlin> hhorak: My local meeting hasn't started yet so..:)
13:12:05 <hhorak> vpavlin: one question for you right away... do you happen to know what is the status of systemd in docker containers? if it is usable in fedora to start services?
13:12:46 <vpavlin> hhorak: I have written it down here: http://vpavlin.eu/2015/02/fedora-docker-and-systemd/
13:12:50 <hhorak> vpavlin: lnykryn said there are still some hacks needed, because docker haven't accepted some patches.. so just worndering if you have some up2date news..
13:13:01 <hhorak> vpavlin: thanks
13:13:10 <hhorak> #link http://vpavlin.eu/2015/02/fedora-docker-and-systemd/
13:13:30 <vpavlin> You need some workarounds, but we could add a fedora-systemd base image which would contain these hacks
13:14:02 <vpavlin> And if you want to run systemd in your container, you'd just use that as a base
13:15:00 <hhorak> vpavlin: so, in other words, we should advice to use this as base in fedora right now?
13:15:14 <vpavlin> I have the Dockerfile on Github and image in Docker Hub..and I could talk to Scott to add it to Fedora-Dockerfiles
13:15:24 <vpavlin> well..no if you don't want to run systemd..
13:15:50 <hhorak> vpavlin: sure, i meant for services where it would make sense
13:15:54 <vpavlin> yes
13:16:17 <hhorak> vpavlin: ok, noted.. will be one of the first recommendations...
13:16:43 <hhorak> anyone else something for dockahfiles?
13:19:14 <phracek> hhorak: no currently
13:19:22 <hhorak> #topic follow-up: Playground repo revisiting
13:20:21 <phracek> hhorak: PyCharm application was selected as a proof package for playing with Playground repo and COPR
13:20:26 <hhorak> we didn't find all answers about how the playground should look like from users' PoV, plus there has been the proposal of read-only metadata
13:20:51 <hhorak> #link https://lists.fedoraproject.org/pipermail/devel/2015-March/209093.html
13:21:09 <phracek> hhorak: sgallagh and sticker already ask me for adding metadata to PyCharm so that COPR can work with them.
13:21:22 <phracek> hugsie and other colleagues were informed.
13:22:28 <phracek> For more information see #fedora-workstation archive
13:23:03 <hhorak> phracek: I'm not sure I follow -- just shortly -- how is copr connected to pycharm?
13:23:08 <phracek> But msuchy told that COPR is prepared and all should work.
13:23:19 <phracek> PyCharm is build up in COPR.
13:23:41 <phracek> Pycharm did not proveded appdata for metadata and hugsie would like to test it.
13:24:14 <phracek> But as msuchy have told COPR is already prepared for it.
13:24:37 <phracek> That's all.
13:24:42 <hhorak> phracek: ah, it is about the application metadata about coprs...
13:25:26 <phracek> yeah. Hugsie wanted an application with application metadata.
13:26:17 <hhorak> phracek: ok.. so the goal is the particular copr (say copr for pycharm) would provide application metadata gathered from packages in the copr repository, right?
13:27:32 <phracek> hhorak: COPR has to/should provide a metadata for Gnome Software Center.
13:27:47 <phracek> hhorak: yes.
13:28:22 <hhorak> phracek: I see.. but there is still the cli part -- dnf.. for that we could think of the "Disabled Repositories Support" as a solution..
13:28:56 <bkabrda> I'm not sure I have anything valuable to add to the metadata part of this discussion, but I think that we should primarily focus on "big decisions", such as one big repo vs more smaller repos, etc...
13:30:53 <hhorak> bkabrda: I agree, I just wanted to highlight the idea with disabled repos, since it may help in the regard of "big repo vs. more smaller" as well... but also might not..
13:31:00 <walters> has there been any discussion of security updates for playground?
13:31:30 <hhorak> bkabrda: I don't think we've paid much attention to it so far
13:31:42 <hhorak> walters: that was meant for you :)
13:31:49 <hhorak> bkabrda: ^
13:32:15 <bkabrda> walters: I think we need to figure out what the playground will look like first and then we can discuss security updates... :)
13:32:34 <hhorak> walters: do you think one solution may be better to address security updates?
13:34:02 <walters> i don't know
13:35:12 <bkabrda> hhorak: I think security updates will be doable somehow in  both cases; we should decide what we want first and then discuss security concerns
13:35:35 <phracek> Here is the link from #fedora-workstation discussion
13:35:36 <phracek> #link https://sgallagh.fedorapeople.org/2015-03-24.080115-0400EDT.html
13:36:46 <walters> a concern i have with COPR for this is that it does not itself provide a mechanism for multiple people to coordinate
13:36:53 <walters> i.e. no dist-git
13:37:15 <walters> now you can find the last built .src.rpm, explode it, and change it, then re-upload but that's fairly fragile
13:37:30 <bkabrda> walters: I think I saw a mail from copr developers that they're working on a dist-git from copr. let me try to find it...
13:37:31 <hhorak> walters: msuchy was working on that as well, not sure what is the current status...
13:37:36 <walters> anyways this is solvable
13:39:04 <bkabrda> hmm, I can't seem to find that mail right now
13:39:14 <hhorak> so, about the "one big repo vs. more smaller", imho it always comes down to the question whether we allow to conflict coprs between each and with main repos.. from my PoV conflicting with main repos is desirable (offer newer versions for example), so conflicting coprs between each other should be allowed as well (we may offer not only one newer version)
13:40:19 <bkabrda> hhorak: another POV is that playground should be kind of "EPEL", which I think langdon was trying to push and I have to admit I'm starting to like that idea. for many conflicting repos, we already have copr itself
13:40:26 <hhorak> #action hhorak to ask copr developers them about what is the current status of dist-git for copr
13:41:22 <hhorak> bkabrda: valid point, so that would mean playground would only be for packages that are not in fedora main yet.. or never will be..
13:43:00 <bkabrda> hhorak: yes; but the problem is: how are the copr repos merged into the playground? what about conflicts during merging? where does playground live? etc...
13:45:18 <bkabrda> and I admit that I don't have answer to these questions right now, but I just want to point them out
13:47:42 <hhorak> bkabrda: so a very simple answer would be: not doing one repo, just install one file with many coprs enabled... and let dnf to solve conflicts..
13:48:19 <hhorak> bkabrda: I remember we talked about this solution and don't remember if we found some big issues with this..
13:48:51 <bkabrda> hhorak: but that's dangerous on user's side - e.g. what happens when copr A has newer version of package than copr B and user installs package from copr B?
13:49:26 * ttomecek totally forgot about the env & stacks meeting. Late hello.
13:49:30 <bkabrda> hhorak: I guess in the end this is about the side that has to deal with dependency/conflict problems - either us (one big repo) or user (multiple small repos)
13:50:50 <bkabrda> hhorak: on our side, I think we can do automated checks for most (all?) of this stuff somehow (it'd cost some work, of course); users will just be doomed
13:52:14 <hhorak> bkabrda: in other words you say it's rather our work than users'
13:52:47 <bkabrda> hhorak: yes
13:54:20 <hhorak> bkabrda: sounds fine to me, we can always change it, the important now is to choose one way and implement something :)
13:54:34 <bkabrda> I mean this should be about providing a good user experience, right? if users enable two different small repos and things start to conflict/update each other, then unexpected things will start happenning. there is however a question whether copr is the right tool to solve the "one big repo approach"
13:54:36 <hhorak> *something sane
13:56:54 <hhorak> bkabrda: I think it is, it actually makes sense to me to have some integration support in copr itself, something like copr merge feature -- creating copr from several others...
13:58:17 <hhorak> since right now if you want to create a copr based on another one, you have to manually enable all coprs to make it work.. that seems to be fragile and inconvenient for copr users.
13:58:24 <bkabrda> hhorak: that sounds reasonable, but we'd also need to be able to let the packagers of to-be-merged repos know when they introduce a conflict. and that should be ASAP, not at the point when we're actually merging the repos
13:58:58 <hhorak> bkabrda: I hear need of CI for copr?
13:59:28 <bkabrda> hhorak: well not in the traditional sense. we'd need a tool that'd automatically detect rpm conflicts between the repos-to-be-merged
14:00:43 <bkabrda> and that could get ugly really quick :)
14:01:12 <hhorak> bkabrda: what you mean by ugly?
14:01:54 <bkabrda> hhorak: damn complicated :)
14:03:10 <hhorak> bkabrda: might be, I'd vote for let's try it and we'll see :)
14:03:16 <bkabrda> either way, my proposal would be to go with one big repo
14:04:42 <bkabrda> I'm afraid I'll need to get going for today
14:05:27 <hhorak> bkabrda: I think we moved a bit today, but still we should write up some more concrete proposal with concrete user scenario
14:06:05 <hhorak> ^ any volunteer for that? :)
14:06:07 <bkabrda> hhorak: agreed. I think I feel a finger pointing my way in your sentence... ;)
14:06:25 <hhorak> bkabrda: not at all.... unless you want :)
14:07:06 <bkabrda> hhorak: ATM I can't promise anything because my job is really taking too much...
14:07:10 <hhorak> some base is already there....
14:07:12 <hhorak> #link https://fedoraproject.org/wiki/Changes/Playground_repository
14:07:16 <hhorak> #link https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29
14:07:40 <hhorak> bkabrda: so I won't write a specific name there today :)
14:07:46 <bkabrda> hhorak: ok, thanks :)
14:07:57 <hhorak> #info playground should be kind of "EPEL", for packages that are not or never will be in main fedora; for many conflicting repos, we already have copr itself -- so the "one big repo" seems to be the prefered way before the
14:07:57 <hhorak> #info we'd also need to be able to let the packagers of to-be-merged repos know when they introduce a conflict (a tool that'd automatically detect rpm conflicts between the repos-to-be-merged)
14:07:57 <hhorak> #action volunteer should write up some more concrete proposal with concrete user scenario
14:08:06 <bkabrda> either way, I really need to get going today, so bye everyone
14:08:12 <hhorak> bkabrda:
14:08:17 <hhorak> bkabrda: bye
14:08:22 <hhorak> mstuchli: you had something on your mind?
14:08:49 <hhorak> (sorry it took longer than I thought to get there)
14:08:55 <mstuchli> hhorak: No problem :)
14:08:58 <mstuchli> Correct
14:09:33 <mstuchli> I'm working on the User Level Package Management for python thingy
14:09:47 <hhorak> #topic User Level Package Management for python
14:09:53 <mstuchli> As described
14:09:57 <mstuchli> #link https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement
14:10:03 <mstuchli> And
14:10:09 <mstuchli> #link https://fedoraproject.org/wiki/UserLevelPackageManagement-Python
14:10:45 <mstuchli> Our current status is that we're waiting for devpi upstream to ack our RFE which we'll need
14:10:51 <mstuchli> #link https://bitbucket.org/hpk42/devpi/issue/198/whitelisting-packages-that-can-be-mirrored
14:11:22 <mstuchli> But I in particular would like to ask you, if you could perhaps suggest how to improve the UserLevelPackageManagement-Python
14:11:32 <mstuchli> guidelines
14:12:08 <mstuchli> This is my first time writing a guideline like this and I very much appreciate any concrete input as to what to add
14:14:36 <hhorak> mstuchli: great, thanks for info.. so what about setting it as action item (to look at the guidelines) and consult some ideas to improve it on ML or the next meeting?
14:14:52 <mstuchli> hhorak: OK, that sounds good to me
14:15:47 <hhorak> #action everyone to look at https://fedoraproject.org/wiki/UserLevelPackageManagement-Python and propose improvements on ML or next meeting
14:16:48 <hhorak> #topic open floor
14:16:59 <hhorak> anyone has anything else to discuss today?
14:17:33 <phracek> hhorak: no
14:17:56 <sicampbell> nope
14:19:14 <hhorak> then thanks everybody!
14:19:17 <hhorak> #endmeeting
14:20:09 <hhorak1> #endmeeting