13:00:34 <mmaslano> #startmeeting Env and Stacks (2014-03-18)
13:00:34 <zodbot> Meeting started Tue Mar 18 13:00:34 2014 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:34 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:40 <mmaslano> #meetingname env-and-stacks
13:00:40 <zodbot> The meeting name has been set to 'env-and-stacks'
13:00:45 <mmaslano> #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano
13:00:45 <zodbot> Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano pkovar samkottler tjanez
13:00:50 <mmaslano> #topic init process
13:00:54 <mmaslano> hi!
13:01:00 <bkabrda> hi
13:01:33 <juhp_> hi
13:02:37 <tjanez> hi
13:04:23 * pkovar is here
13:04:34 <juhp_> softwarecollections.org looks very cool :)
13:04:49 <mmaslano> sure, lot of pink :)
13:05:19 * msuchy is here
13:05:20 <mmaslano> let's start with my homework, speaking to msuchy about signing of packages on Copr
13:05:51 <msuchy> my opinion
13:06:00 <msuchy> as copr maintainer
13:06:03 <mmaslano> msuchy: please, share your opinions on the issue :)
13:06:12 <msuchy> that would take lot of time
13:06:22 <msuchy> we would need either:
13:06:51 <msuchy> polish sigul, which would likely meen migrate that code to pgp
13:07:09 <msuchy> or use obs-signd for copr
13:07:12 <tjanez> #topic Signing of packages for the Playground repo
13:07:52 <msuchy> both option have some risc and would need some time, but both require having special dedicated machine with special network setup
13:08:22 <mmaslano> #info signing packages - hw needed and few months of work
13:08:31 <msuchy> and BTW next visit in PHX by fedora-infra is scheduled aprox. in half a year
13:09:20 <tjanez> msuchy, is there any difference between signing all COPR packages and just signing the packages headed to the Playground repo?
13:09:23 <mmaslano> #info next visit in PHX by fedora-infra is scheduled aprox. in half a year
13:10:11 <msuchy> tjanez: technically no
13:10:24 <msuchy> unless you want to sign packages in Playground manually
13:10:31 <msuchy> which can be option
13:11:09 <tjanez> msuchy, ok, thanks for clearing that up
13:11:47 <mmaslano> do we have existing tools for singing packages manually?
13:11:59 <msuchy> rpmsign
13:12:02 <tjanez> msuchy, AFAIK, Fedora packages are signed with sigul. Why is migrating to pgp not an issue there?
13:12:03 <juhp_> might be temporarily workaround at least
13:13:18 <msuchy> tjanez: I spoke about that with mitr who created sigul, and he said "it is old code, and if you will deploy it, you should migrate to pgp2" we do not touch it in koji, because it works :)
13:13:55 <tjanez> msuchy, ok, I see :)
13:14:04 <mmaslano> #info as workaround can be rpmsign used for packages heading to Playground
13:14:18 <tjanez> is obs-signd in better shape (code-wise)?
13:14:35 <mmaslano> #info sigul, mitr said "it is old code, and if you will deploy it, you should migrate to pgp2" we do not touch it in koji, because it works :)
13:14:50 <mmaslano> and how much time it would take to use obs-signd?
13:15:06 <msuchy> tjanez: it is simplier, very simplier and I would say better maintained
13:15:29 <msuchy> I would personally prefer this way
13:15:42 <bkabrda> msuchy: so just to sum it up, you're generally +1 for the idea of signing of Playground packages but the problem is that it'll take some time to implement it in copr?
13:15:57 <msuchy> yes
13:16:15 <mmaslano> msuchy: would the obs-signd be a part of copr or should it be hosted somewhere outside?
13:16:33 <tjanez> msuchy, just to be clear, obs-signd is "generic" and not tied to OBS?
13:16:48 <bkabrda> thx. well, is that a problem for us? to say that for e.g. 1 or 2 releases the Playground repo will contain unsigned packages and that we're working on that?
13:16:59 <msuchy> obs-signd is used in OBS but it is generic and can be used by Copr
13:17:12 <mmaslano> #info obs-signd is used in OBS but it is generic and can be used by Copr
13:17:25 <msuchy> so for copr it will be just another package in its deps
13:17:58 <mmaslano> msuchy: but we still need the hardware :)
13:18:33 <mmaslano> msuchy: could you specify which hw and how much work you need to do in Copr? E-mail to env-and-stacks would be fine
13:18:44 <mmaslano> it's needed for further planning ...
13:18:57 <msuchy> mmaslano: yes, but we have budget (rvokal said that the money I requested got fedora infra) so fedora infra should be able to dedicate some machine for that
13:19:05 <mmaslano> great
13:19:47 * juhp_ is slightly confused: if obs-signd becomes a copr dep does it still need new hw?
13:19:59 <juhp_> ah client side?
13:20:18 <msuchy> juhp: yes, because obs-sign need to run on separate machine for security reasons
13:20:23 <juhp_> ok
13:20:46 <mmaslano> could we move to next topic or are there more questions?
13:20:55 <msuchy> you should not be able to log there from anywhere (as said experience from Fedora security incident several years ago)
13:21:05 <tjanez> I have another technical question: if signing is done by Copr, does each COPR have a separate key or do they all share a common key? Does the Playground repository use a different key?
13:22:07 <msuchy> tjanez: obs-sign allow to have different key for each project (or user), but you are not able to specify which key will be used, obs-sign will assign it to you
13:22:20 <msuchy> and private key will never leave that signing machine
13:23:14 <msuchy> you can specify that some project will use some key, but you need to get physical acces to signing machine
13:23:47 <tjanez> msuchy, I was thinking more of a work-flow where packages in a COPR are first signed with the user key
13:24:12 <tjanez> and when they get accepted into the Playground repo they have to be signed with the Playground repo key
13:24:39 <tjanez> Is that reasonable/doable work-flow?
13:26:05 <msuchy> tjanez: yes, it is possible, but then playground repo gpg key is either genereted by signing maichine (one shot task then it stay same until revoked) or - if you e.g would sing it wiht Fedora gpg key - need to get usb stick to that machine, which in PHX need scheduling several month in advance
13:27:27 <tjanez> msuchy, thanks for the explanation. I would guess that the first scenario is OK, but I'm not a security expert
13:28:12 <tjanez> Also, we might want obs-signd generate a new key for each repo (e.g. F19, F20, F21 when branched, rawhide)
13:29:09 <msuchy> tjanez: that is possible
13:29:12 <tjanez> The public keys can be provided in the Fedora's main repo as a fedora-playground package (similar to the fedora-rawhide package)
13:30:32 <juhp_> aha
13:32:01 <tjanez> Correction, fedora-rawhide doesn't contain keys since rawhide is not signed :)
13:32:08 <tjanez> anyway, let's move on
13:32:18 <mmaslano> yeah, thanks msuchy
13:32:28 <mmaslano> next Open question?
13:32:47 <mmaslano> #topic      Do we allow conflicts with packages in the main repo?
13:33:18 * jreznik is lurking around :)
13:33:24 <bkabrda> mmaslano: I think this is sort of related to one big repo vs N small repos as explained at https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_%28draft%29#1_Big_repo_vs_multiple_small_ones
13:33:51 <bkabrda> and I'm still thinking whether it wouldn't be better to make Playground collection of small repos instead one big repo
13:34:24 <mmaslano> um we should probably decide this one by all voices on mailnig list (probably)
13:34:57 <tjanez> My take is we don't allow conflicts with packages in the main repo
13:35:17 <bkabrda> because you may have two repos that want to provide packages X and Y, but these both require Z in different version. so it becomes hard to effectively provide X and Y together in the Playground repo
13:35:19 <jreznik> bkabrda: I'm really in favour of playground being collection of small repos from the beginning
13:35:59 <juhp_> hmm repo-of-repos idea is interesting indeed
13:36:09 <tjanez> bkabrda, for that case I would say bundle or use SCLs
13:36:38 <jreznik> tjanez: but then you loose freedom of playground and it's better to stick with coprs/scls
13:36:40 <tjanez> mmaslano, we can discuss this now and have some proposal to vote on the ML
13:36:47 <mmaslano> tjanez: sure
13:37:05 * jreznik is switching to silent mode :)
13:37:06 <juhp_> but how many repos? :)
13:37:19 <bkabrda> tjanez: I don't think we should encourage people to bundle. also, we may tell that to people, but people do mistakes and what do we do when we end up with conflicts?
13:37:49 <tjanez> the way I see the Playground repo is something that complements the main repository in a co-operative way
13:37:53 <juhp_> repo-of-coprs?
13:38:01 <tjanez> so people won't be afraid to enable it
13:38:18 <bkabrda> juhp_: I'm thinking a repo of rpms, each of which contains a repofile for a single copr
13:38:25 <juhp_> right true - already I also thought we would not allow conflicts
13:38:36 <juhp_> bkabrda, yeah I see
13:39:04 <juhp_> then one would just apply "please add my copr"?
13:39:17 <tjanez> bkabrda, I'm also not for encouraging bundling that's why I would rather use SCLs to provide multiple parallely installable versions of the needed libraries
13:39:46 <bkabrda> tjanez: the problem is that SCL introduce additional complexity, which we don't want for playground
13:39:46 <tjanez> And we would also need to talk about co-maintenance
13:40:02 <juhp_> if we do allow conflicts though it is going to make the upgrade story pretty hard though
13:40:26 <bkabrda> tjanez: another problem of one big repo is that, as I've said, people will do mistakes eventually and we'll have to sort of conflicts in some way and I'm not sure we can automate this sort of stuff
13:40:35 <tjanez> bkabrda, but I think SCLs are simpler that having to manually create library27, library33, etc. packages
13:41:28 <bkabrda> tjanez: the idea of multiple small repos is that you don't have to create compat versions. you just create "library" in copr repo X and someone else creates "library" in copr repo Y.
13:41:56 <jreznik> tjanez: it's playground - it should be easy to include stuff there -> bundling
13:42:10 <bkabrda> and yes, people will have problems if they try to install both together, but I think that's an acceptable tradeoff
13:42:13 <juhp_> (ah maybe we're just talking about copr conflicts?)
13:42:54 <tjanez> bkabrda, I have the opposite view. The Playground repository should be self-consistent
13:43:21 <tjanez> I.e. the repository should work, no matter which subset of packages one installs from it
13:43:46 <tjanez> bkabrda, also, what happens when someone issues 'dnf install library'?
13:43:56 <mmaslano> tjanez: sounds like better packages than we are having in fedora-testing
13:44:24 <jreznik> from what I see I think we are back to "one fits them all repo" can't cover all use cases... I thought we said lets start with one repo, with some use cases as beginning and then think about really ugly one, real incubator one etc.
13:44:26 <bkabrda> tjanez: users would first have to enable individual sub-repos of playground
13:44:48 <jreznik> as I don't think it's possible to fulfil all requirements from beginnning and make everyone happy and have some in a near future :D
13:46:23 <tjanez> bkabrda, I would think that conflicts with what we already agreed upon, like the "How do the updates work?" part of the https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_(draft)#How_the_repository_works
13:46:40 <tjanez> namely, "One yum/dnf repository is provided for each Fedora release-arch combination"
13:47:02 <tjanez> jreznik, so, on which side are you :)?
13:47:42 <bkabrda> tjanez: I know, I just really wanted to bring this up since I don't feel that this option has been considered by everyone. and I personally think it's a better option - if others think something else, than it's ok
13:48:01 <mmaslano> tjanez: I feel we won't have consensus on this one
13:48:27 <mmaslano> I don' think self support is important, only because it was always true for Fedora
13:48:43 * mmaslano is going to different desk
13:48:43 <tjanez> bkabrda, ok, fair
13:49:00 <jreznik> tjanez: I'd prefer copr style collections but we have to start with something - so let's start with one, with pretty loose policies, could eat kittens (probably not suitable for production systems), set up infra and then think about if we want to have more than one, how it should look like etc.
13:49:52 <tjanez> mmaslano, what did you mean with "self support"?
13:51:10 <mmaslano> ah self-support
13:51:20 <juhp_> self-supporting
13:52:05 <tjanez> sorry, but I still can't grasp what is meant by self-supporting :)
13:52:14 <juhp_> self-hosting I guess?
13:53:02 <tjanez> Ok, if self-hosting was meant, I grasp it
13:54:34 <tjanez> jreznik, I see your point: have this one repo out-of-the-door sooner rather than later
13:55:21 * mmaslano was on two meetings at the same time, now reading log
13:55:27 <juhp_> I am also not sure how important self-hosting is for Playground, but could be encouraged - certainly it should be a requirement for stabler pretty ring2 repo
13:55:35 <mmaslano> tjanez: I wanted to say I disagree with "The Playground repository should be self-consistent"
13:55:45 <juhp_> ah
13:56:05 <mmaslano> I agree with bkabrda's: people will have problems if they try to install both together, but I think that's an acceptable tradeoff
13:56:15 <tjanez> mmaslano, aha, I see
13:56:48 <juhp_> sounds okay probably for Playground
13:56:48 <bkabrda> I guess we should discuss this on the ML, not all members of our WG are here and this is pretty important decision
13:56:51 <mmaslano> otherwise it's not clear to me why use Copr and how would we handled bundled libraries
13:56:58 <juhp_> bkabrda, +1
13:57:00 <jreznik> tjanez: exactly - and you would get a lot of infra ready, stable with other options how to make it better later
13:57:02 <mmaslano> bkabrda: +1
13:57:22 <tjanez> bkabrda, +1
13:57:53 <tjanez> mmaslano, bundled libraries are not a problem if they are properly bundled (i.e. no file-system conflicts)
13:58:12 <mmaslano> #agreed conflicts within Playground repo will be discussed and decided on mailinig list.
13:58:27 <mmaslano> tjanez: it doesn't have to be true for quick & dirty work
13:58:41 <bkabrda> tjanez: "properly bundled" sounds really terrible ;)
13:58:56 <tjanez> bkabrda, good catch :)
13:59:34 <tjanez> mmaslano, quick & dirty is more suited for COPRs, isn't it?
14:00:08 <mmaslano> relatively quick?
14:00:09 <juhp_> hmm bundling is often hard I feel though
14:01:04 <mmaslano> end?
14:01:06 <mmaslano> more topics?
14:02:43 <tjanez> Depends on how much time/energy people still have left. We have an open question on co-maintainence (i.e. ACLs) and a bunch of question on package reviews
14:05:03 <juhp_> I feel good to keep to 1 hour but can continue if there is a desire
14:05:54 <mmaslano> I plan to add signing to wiki and write about other open questions on mailing list..
14:06:59 <bkabrda> since most of the open questions depend on the 1 big vs. N small, I'd say let's move this discussion to the list and continue talking about other topics after that
14:07:42 <juhp_> yep good point
14:07:48 <tjanez> bkabrda, +1
14:07:55 <juhp_> I agree we need to resolve that one first really
14:08:37 <juhp_> and if we go for 1 big repo what exactly do we allow in there
14:09:13 <tjanez> I would say that we need to get our (small) packaging policy sorted our first and then talk about how to review packages, etc.
14:11:00 <mmaslano> #endmeeting