13:00:34 #startmeeting Env and Stacks (2014-03-18) 13:00:34 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:00:40 #meetingname env-and-stacks 13:00:40 The meeting name has been set to 'env-and-stacks' 13:00:45 #chair abadger1999 pkovar tjanez samkottler bkabrda drieden hhorak juhp mmaslano 13:00:45 Current chairs: abadger1999 bkabrda drieden hhorak juhp mmaslano pkovar samkottler tjanez 13:00:50 #topic init process 13:00:54 hi! 13:01:00 hi 13:01:33 hi 13:02:37 hi 13:04:23 * pkovar is here 13:04:34 softwarecollections.org looks very cool :) 13:04:49 sure, lot of pink :) 13:05:19 * msuchy is here 13:05:20 let's start with my homework, speaking to msuchy about signing of packages on Copr 13:05:51 my opinion 13:06:00 as copr maintainer 13:06:03 msuchy: please, share your opinions on the issue :) 13:06:12 that would take lot of time 13:06:22 we would need either: 13:06:51 polish sigul, which would likely meen migrate that code to pgp 13:07:09 or use obs-signd for copr 13:07:12 #topic Signing of packages for the Playground repo 13:07:52 both option have some risc and would need some time, but both require having special dedicated machine with special network setup 13:08:22 #info signing packages - hw needed and few months of work 13:08:31 and BTW next visit in PHX by fedora-infra is scheduled aprox. in half a year 13:09:20 msuchy, is there any difference between signing all COPR packages and just signing the packages headed to the Playground repo? 13:09:23 #info next visit in PHX by fedora-infra is scheduled aprox. in half a year 13:10:11 tjanez: technically no 13:10:24 unless you want to sign packages in Playground manually 13:10:31 which can be option 13:11:09 msuchy, ok, thanks for clearing that up 13:11:47 do we have existing tools for singing packages manually? 13:11:59 rpmsign 13:12:02 msuchy, AFAIK, Fedora packages are signed with sigul. Why is migrating to pgp not an issue there? 13:12:03 might be temporarily workaround at least 13:13:18 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 msuchy, ok, I see :) 13:14:04 #info as workaround can be rpmsign used for packages heading to Playground 13:14:18 is obs-signd in better shape (code-wise)? 13:14:35 #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 and how much time it would take to use obs-signd? 13:15:06 tjanez: it is simplier, very simplier and I would say better maintained 13:15:29 I would personally prefer this way 13:15:42 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 yes 13:16:15 msuchy: would the obs-signd be a part of copr or should it be hosted somewhere outside? 13:16:33 msuchy, just to be clear, obs-signd is "generic" and not tied to OBS? 13:16:48 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 obs-signd is used in OBS but it is generic and can be used by Copr 13:17:12 #info obs-signd is used in OBS but it is generic and can be used by Copr 13:17:25 so for copr it will be just another package in its deps 13:17:58 msuchy: but we still need the hardware :) 13:18:33 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 it's needed for further planning ... 13:18:57 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 great 13:19:47 * juhp_ is slightly confused: if obs-signd becomes a copr dep does it still need new hw? 13:19:59 ah client side? 13:20:18 juhp: yes, because obs-sign need to run on separate machine for security reasons 13:20:23 ok 13:20:46 could we move to next topic or are there more questions? 13:20:55 you should not be able to log there from anywhere (as said experience from Fedora security incident several years ago) 13:21:05 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 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 and private key will never leave that signing machine 13:23:14 you can specify that some project will use some key, but you need to get physical acces to signing machine 13:23:47 msuchy, I was thinking more of a work-flow where packages in a COPR are first signed with the user key 13:24:12 and when they get accepted into the Playground repo they have to be signed with the Playground repo key 13:24:39 Is that reasonable/doable work-flow? 13:26:05 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 msuchy, thanks for the explanation. I would guess that the first scenario is OK, but I'm not a security expert 13:28:12 Also, we might want obs-signd generate a new key for each repo (e.g. F19, F20, F21 when branched, rawhide) 13:29:09 tjanez: that is possible 13:29:12 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 aha 13:32:01 Correction, fedora-rawhide doesn't contain keys since rawhide is not signed :) 13:32:08 anyway, let's move on 13:32:18 yeah, thanks msuchy 13:32:28 next Open question? 13:32:47 #topic Do we allow conflicts with packages in the main repo? 13:33:18 * jreznik is lurking around :) 13:33:24 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 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 um we should probably decide this one by all voices on mailnig list (probably) 13:34:57 My take is we don't allow conflicts with packages in the main repo 13:35:17 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 bkabrda: I'm really in favour of playground being collection of small repos from the beginning 13:35:59 hmm repo-of-repos idea is interesting indeed 13:36:09 bkabrda, for that case I would say bundle or use SCLs 13:36:38 tjanez: but then you loose freedom of playground and it's better to stick with coprs/scls 13:36:40 mmaslano, we can discuss this now and have some proposal to vote on the ML 13:36:47 tjanez: sure 13:37:05 * jreznik is switching to silent mode :) 13:37:06 but how many repos? :) 13:37:19 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 the way I see the Playground repo is something that complements the main repository in a co-operative way 13:37:53 repo-of-coprs? 13:38:01 so people won't be afraid to enable it 13:38:18 juhp_: I'm thinking a repo of rpms, each of which contains a repofile for a single copr 13:38:25 right true - already I also thought we would not allow conflicts 13:38:36 bkabrda, yeah I see 13:39:04 then one would just apply "please add my copr"? 13:39:17 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 tjanez: the problem is that SCL introduce additional complexity, which we don't want for playground 13:39:46 And we would also need to talk about co-maintenance 13:40:02 if we do allow conflicts though it is going to make the upgrade story pretty hard though 13:40:26 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 bkabrda, but I think SCLs are simpler that having to manually create library27, library33, etc. packages 13:41:28 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 tjanez: it's playground - it should be easy to include stuff there -> bundling 13:42:10 and yes, people will have problems if they try to install both together, but I think that's an acceptable tradeoff 13:42:13 (ah maybe we're just talking about copr conflicts?) 13:42:54 bkabrda, I have the opposite view. The Playground repository should be self-consistent 13:43:21 I.e. the repository should work, no matter which subset of packages one installs from it 13:43:46 bkabrda, also, what happens when someone issues 'dnf install library'? 13:43:56 tjanez: sounds like better packages than we are having in fedora-testing 13:44:24 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 tjanez: users would first have to enable individual sub-repos of playground 13:44:48 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 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 namely, "One yum/dnf repository is provided for each Fedora release-arch combination" 13:47:02 jreznik, so, on which side are you :)? 13:47:42 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 tjanez: I feel we won't have consensus on this one 13:48:27 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 bkabrda, ok, fair 13:49:00 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 mmaslano, what did you mean with "self support"? 13:51:10 ah self-support 13:51:20 self-supporting 13:52:05 sorry, but I still can't grasp what is meant by self-supporting :) 13:52:14 self-hosting I guess? 13:53:02 Ok, if self-hosting was meant, I grasp it 13:54:34 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 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 tjanez: I wanted to say I disagree with "The Playground repository should be self-consistent" 13:55:45 ah 13:56:05 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 mmaslano, aha, I see 13:56:48 sounds okay probably for Playground 13:56:48 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 otherwise it's not clear to me why use Copr and how would we handled bundled libraries 13:56:58 bkabrda, +1 13:57:00 tjanez: exactly - and you would get a lot of infra ready, stable with other options how to make it better later 13:57:02 bkabrda: +1 13:57:22 bkabrda, +1 13:57:53 mmaslano, bundled libraries are not a problem if they are properly bundled (i.e. no file-system conflicts) 13:58:12 #agreed conflicts within Playground repo will be discussed and decided on mailinig list. 13:58:27 tjanez: it doesn't have to be true for quick & dirty work 13:58:41 tjanez: "properly bundled" sounds really terrible ;) 13:58:56 bkabrda, good catch :) 13:59:34 mmaslano, quick & dirty is more suited for COPRs, isn't it? 14:00:08 relatively quick? 14:00:09 hmm bundling is often hard I feel though 14:01:04 end? 14:01:06 more topics? 14:02:43 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 I feel good to keep to 1 hour but can continue if there is a desire 14:05:54 I plan to add signing to wiki and write about other open questions on mailing list.. 14:06:59 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 yep good point 14:07:48 bkabrda, +1 14:07:55 I agree we need to resolve that one first really 14:08:37 and if we go for 1 big repo what exactly do we allow in there 14:09:13 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 #endmeeting