12:02:01 #startmeeting Env and Stacks (2014-12-03) 12:02:01 Meeting started Wed Dec 3 12:02:01 2014 UTC. The chair is hhorak. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:02:01 Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:02:07 #meetingname env-and-stacks 12:02:07 The meeting name has been set to 'env-and-stacks' 12:02:14 #chair pkovar tjanez samkottler bkabrda hhorak juhp ncoghlan vpavlin sicampbell 12:02:39 #topic init process 12:02:52 hi everyone, sorry I'm late a bit 12:02:53 Hi, who do we have here today? 12:03:07 bkabrda: not much more late than me :) 12:03:18 here :) 12:03:42 another meeting at 11 though, so I'll be leaving right on time :) 12:04:12 so let's make it effective today :) 12:04:26 #topic Follow-ups 12:05:04 I wanted to shortly touched the 'upstream repositories' thing 12:05:55 * bkabrda still has to deploy the testing devpi instance, but being sick and having lots of internal RH work ATM prevents him from doing so... 12:05:55 That we need to move some internal thoughts move to fedora, as Matt proposed.. 12:06:03 #link https://fedoraproject.org/wiki/Env_and_Stacks/Projects/LanguageSpecificRepositories 12:06:30 that's the initial draft I put together after last meeting 12:08:23 ncoghlan: some notes from me - the Java guys in my team has reached a conclusion that downstream maven repository wouldn't have significant benefit, so I'd say that Python is alone as a pilot right now 12:08:43 ncoghlan: thanks, that seems fine.. 12:09:22 bkabrda: interesting quirk there is that Python is the one Pulp already has a plugin for (although I've never tried it) 12:09:42 but with only one language involved, there's less need for a generic server... 12:09:43 ncoghlan: I've had a very long discussion with them and do agree with their opinions... basically, it would only make sense if we mirrored upstream maven precisely as it is, in which point we're not adding any value... 12:10:05 yeah, the ability to add wheel files makes the Python case more interesting 12:10:13 ncoghlan: really? I'll need to have a look at that plugin 12:10:29 hang on, I'll find the link 12:10:50 #link https://github.com/pulp/pulp_python 12:11:09 sorry i am late 12:11:28 ncoghlan: also, I think that all points in the "Open questions" section can be summarized as (and I've been thinking about this since I started packaging devpi21 SCL): "What workflow will we use?" 12:11:29 I also started a Python upstream distutils-sig discussion regarding overriding/changing the platform tag in wheel files 12:11:40 ncoghlan: yeah, I'm watching that 12:12:26 for the meeting notes: Python wheel's currently have a problem where all prebuild Linux binaries get tagged "linux_ which rather underspecifies the ABI they're linked against 12:13:54 I initially thought /etc/os-release might be usable for the purpose, but that *over*specifies the ABI 12:14:20 #info the Java guys has reached a conclusion that downstream maven repository wouldn't have significant benefit, so I'd say that Python is alone as a pilot right now 12:14:20 #info Python wheel's currently have a problem where all prebuild Linux binaries get tagged "linux_ so current thinking is more along the lines of just providing a general purpose override mechanism 12:14:58 ncoghlan: also, in Fedora we have an interesting feature that I've run into just a week ago: a "generic" release: http://koji.fedoraproject.org/koji/buildinfo?buildID=587037 12:15:35 I've heard it's used on custom community Fedora spins or something like that 12:15:57 huh, interesting 12:16:08 the problem is that this says that distro name is not "Fedora", but "Generic" 12:16:19 I guess it may also be useful for anyone making a Fedora downstream 12:16:26 bkabrda, right that is for unbranding 12:16:52 so the only reliable way with generic-release is making sure that "fedora-release" file exists 12:16:59 bkabrda: the thing that actually made me realise /etc/os-release wouldn't work was EPEL compatibility 12:17:10 otherwise there's no way to tell that the system is Fedora 12:17:25 ncoghlan: hmm, good point, I haven't thought of that 12:17:37 since we'd like to share wheels across RHEL/CentOS/etc as well as across point releases within each major release series 12:19:17 so yeah, unless someone comes up with a really clever idea (happy to hear them!), "make the platform tag configurable" is likely to be our approach upstream 12:19:53 that actually allows other potentially neat things like hash based tags for a unique build set 12:20:16 ncoghlan: I haven't been following the discussion closely... is there any document/proposal on this behaviour? I'm not sure what "configurable" should behave like in this case 12:20:22 so I don't actually consider it a bad outcome 12:20:28 no, that's the downside 12:20:42 more design work involved than "just use /etc/os-release" 12:22:04 I've kind of lost myself here, could you, guys somehow summarize what problem are we talking about? I see we need to define OS identification somehow differently for wheels, but don't follow connection.. 12:22:06 I need to reread the discussion on distutils mailing list to see what's up :) 12:22:20 bkabrda: do you have a link for the discussion? 12:23:06 hhorak: yeah, give me a sec 12:23:12 my suggestion: https://mail.python.org/pipermail/distutils-sig/2014-November/025297.html 12:23:42 hhorak: yeah, there you go ^^ :) 12:23:50 me explaining why it won't actually work: https://mail.python.org/pipermail/distutils-sig/2014-December/025337.html 12:24:00 ah, ok, thanks 12:24:08 #link https://mail.python.org/pipermail/distutils-sig/2014-November/025297.html 12:24:15 #link https://mail.python.org/pipermail/distutils-sig/2014-December/025337.html 12:26:33 A bit back to the general idea -- I still have a feeling that so far not enough from fedora users know some ideas like this are being discussed here, since it seems to be important enough to me to get not much feedback so far... 12:26:38 bkabrda, so.. sorry to weigh in a little late.. but, if the java guys aren't convinced having an alt-maven is a good ideas, doesn't that somewhat kill the whole concept at large? why would ruby or node or whatever be more receptive? Python is such a unique case in the linux world I am not sure it is a representative test. 12:27:21 so what I'm thinking about is making it a bit more public, post some tl;dr version of the Nick's wiki page (just a link with few sentences about purpose) to give it some marketing.. or is it too soon? 12:27:28 right, I don't think it will generalise 12:27:29 I'd just like to see bigger part of fedora community to discuss.. and get them more involved as well... 12:27:36 langdon: I think the point is to apply this concept where it makes sense. it makes sense for Python, so let's do it there; we should approach this case by case 12:28:06 hhorak: I was thinking that would be if *we* thought it was a worthy enough idea to put an actual Fedora change proposal together 12:28:33 then we'd have the broader discussion of people yelling at us what a terrible idea it is 12:29:01 ncoghlan: so you'd like to wait with it to be it more concrete? 12:29:05 yeah 12:29:15 at least have the devpi instance up 12:29:20 ncoghlan: ok 12:29:46 so we could at least have an example of using that in a Dockerfile to install a Python app 12:30:43 going back to langdon's question, I think that gets us back to the idea of a potentially more general purpose language independent tool 12:31:13 #info we should make some marketing for the 'upstream repository' ideas, so we get feedback from broader community, but not sooner than the devpi instance is out and we have an example of using that in a Dockerfile to install a Python app 12:31:34 I personally know a bit about two Fedora compatible user level package management tools (being NixOS and conda) 12:32:12 where is the docu for why this is even potentially good idea? cause it doesn't sound like y'all are convinced :) 12:32:49 langdon: I'm convinced personally, but that's not the same as being sure I can sell it to FESCo :) 12:33:14 * bkabrda feels the same as ncoghlan 12:33:38 #link https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement 12:33:43 the early discussions at flock seemed to be pretty favorable with fesco... but maybe i missed something 12:33:44 is the higher level write-up 12:33:59 I'm probably just being overly pessimistic 12:34:41 I think that we just need a working proof of concept before approaching fesco with this 12:35:20 and I understand that we still don't have it because of me not having enough time to deploy devpi testing instance... 12:35:31 bkabrda, yes.. i would agreee... 12:35:33 for myself, I think it's a good idea in principle, but also still a lot of unanswered questions 12:35:41 * langdon didn't mean the 2nd part :) 12:36:02 yeah, and these unanswered questions can only be solved with the testing instance, I think 12:36:19 * ncoghlan nods 12:36:25 i think the doc misses a very important aspect of the proposal... providing a trusted source of build of "not-rpm-packages" that doesn't currently exist 12:36:54 huh, I left that out? 12:36:57 langdon: source as in dist-git/tarballs cache? 12:37:29 huh, I did 12:38:01 that's kinda silly, since creating a curated repo is why *I* got interested in the first place. 12:38:28 bkabrda, uhh... not even a 1/2 cup of coffee.. "source" as in "provider" where "provider" = fedora 12:38:36 bkabrda, does that help? 12:39:04 langdon: sorry, I don't follow. I haven't had a coffee in months :) 12:39:24 ncoghlan, take a stab? 12:39:40 the aspects I was talking about originally: the initial review to say the licensing is sensible and the package isn't actively malicious 12:40:01 i.e. "pip install python-nation" should just fail if using the Fedora repo 12:41:12 * langdon realizes that is yet another slang term.. "take a stab" means to "give something a try" with probably the obvious, murderous, origins :) 12:41:17 ncoghlan: yeah, that I understand. langdon, is that what you mean? 12:41:23 bkabrda, yeah 12:41:46 that isn't in the doc ncoghlan pointed at (well, i didn't see it) 12:41:53 no, its not there 12:42:11 some langs like ruby and haskell already have user package support 12:42:18 (not for any good reason, I just forgot to include it) 12:42:27 maybe a generic tool could wrap those dunno 12:42:36 ok, so for this, we're going to do some whitelisting. I think we initially thought that we'd whitelist all packages packaged in Fedora/RHEL/RHSCL (the two former being subset of the first one, I believe) 12:42:51 so one missing piece on my side now, why installing python-nation would fail -- is it licensing insensible or actively malicious? 12:42:57 (and packages not on whitelist would be prevented from being mirrored) 12:43:10 * hhorak is not a pythonist 12:43:12 hhorak: benignly malicious to prove a point about uncurated repos 12:43:38 benignly? 12:43:51 Jacob Kaplan-Moss wrote it after being inspired by the "gem install ruby-nation" incident 12:44:15 juhp: it reads and uploads an md5 hash of /etc/passwd 12:44:22 ah 12:44:22 from its setup.py 12:44:33 ok ;) 12:44:34 ah, understand now 12:45:14 * langdon thinks that might be bad but is no sys-admin 12:45:37 working in upstream package management involves a lot of "well, if you insist on shooting at your own feet, try to only take out the toes you don't need" :P 12:46:14 bkabrda, ncoghlan is mirroring sufficient? as in, don't you need to do rebuilds? or is that just for the pilot? 12:46:27 langdon: mirroring is one part of it 12:46:38 langdon: the second part is building binary wheels 12:46:50 step one is to mirror the sdists 12:47:02 yeah..ok.. 12:47:19 step two is TBD, because we haven't figured out where or how to build the binaries yet 12:47:23 and making certain groups of them (e.g. "here you have prebuilt upstream packages that make up RHSCL 1.2") 12:48:18 ncoghlan, just go with "qed" as certain math professors do... 12:48:19 (or prebuilt packages that you can use to *extend* RHSCL 1.2... there are really tons of approaches we can try out) 12:48:46 still, we're not going to solve the whole problem tonight, and I need to head to another meeting shortly :) 12:50:17 bkabrda, i think those are lots of "added values" beyond the original proposal.. i guess i had always thought that just providing a "trusted source" would be a strong start 12:50:37 langdon: depends on the audience 12:50:47 langdon: I agree, I'm just mentioning what *further* steps we'll be able to make 12:50:58 once we get the basic use case running 12:51:52 #action ncoghlan: add the "trusted curator" rationale to LanguageSpecificRepositories page 12:52:21 bkabrda, i think it would be very helpful to capture (on the wiki page or something) the specific argument(s) against the plan from the java folks.. they seem like the most obvious candidates to me, and if they aren't convinced... 12:53:02 langdon: ok, I'll ask them to create a wiki page summarizing the approaches we thought of and why we think it's not worth the effort 12:53:10 personally, pypi is way better curated than many of the other repos 12:53:25 I'll post the link to WG ML once it's ready 12:54:03 langdon: I suspect that's an artifact of the barriers to entry historically being really high 12:54:30 bkabrda, from your last, it sounds as if the issue is not around value but around implementation, if that is the case, that is a different problem. Let's just be sure to keep the problems separate. 12:54:38 well, why I initially began with this topic today was that there are some similar discussions taking place internally. And I want to make sure we're all on the same page regarding to way forward.. So, I'll again point them to the Nick's text and hopefully they will join the next time :) 12:55:04 langdon: no, it's around value, I just probably didn't word it right 12:55:31 langdon: either way, we'll create a wiki page and you can see for yourself once it's ready :) 12:55:32 bkabrda, s'ok more argument for a write up then 12:56:05 * langdon grumbles about feisty missing commas 12:56:37 #action bkabrda will ask java guys to create a wiki page summarizing the approaches we thought of and why we think it's not worth the effort + post the link to WG ML once it's ready 12:57:29 ok, are we done with upstream repos topic? 12:57:48 * ncoghlan nods 12:57:54 we =they? :) 12:58:01 heh, sorry 12:58:17 that's probably a good time for me to depart, too 12:58:28 congrats on getting the CentOS SCL sig set up! 12:59:43 #topic SCLs and CentOS 13:00:26 This was meant just as a quick heads-up since SCLs are part of this group focus.. 13:00:45 Software collections development is now slowly moving to CentOS, since that is nice open platform where software collections make much more sense. 13:01:01 One reason why SCLs did not happen in Fedora yet is because there is significantly lower demand for that concept. 13:01:16 (maybe better to use some #info here :) ) 13:01:22 #info Software collections development is now slowly moving to CentOS, since that is nice open platform where software collections make much more sense. 13:01:49 #info So, what is happening is that CentOS SIG was established that would help to develop some better ecosystem around SCLs where more people can actively participate. 13:01:53 #link http://wiki.centos.org/SpecialInterestGroup/SCLo 13:01:58 hhorak, can we disagree with infos? ;) 13:02:15 langdon: sure! 13:03:08 langdon: what don't you agree with? 13:03:25 so, i think it is correct to say, centos is more receptive, but not nec. that it is a better use case :) 13:03:42 * langdon might be feeling nitpicky 13:04:11 I think it's supposed to say "make much more sense than in Fedora"? 13:05:08 So what could be more accurate is that it does not make so much sense to use SCLs in Fedora to bring newer versions as it does in CentOS/RHEL. 13:05:13 bkabrda, ha.. no.. i definitely disagree with that sentiment.. i think the use cases are = but know that many disagree... i just probably wouldn't make a declarative statement of the opinion 13:05:44 hhorak, but then in Fedora it might make a lot of sense to sometimes bring **older** versions of the stacks through SCL 13:05:47 hhorak, newer, probably, but not necessarily (e.g. python3) but older, definitely 13:05:48 I think there is another use case (still valid) in fedora 13:05:49 langdon: I'm speculating about what the sentence should say exactly to prevent misunderstanding. I don't agree with it either 13:06:09 * bkabrda is not making himself very clear today :) 13:06:37 oh.. i would just propose "centos seems to like scls more than fedora" (or something better :) ) just without an opinion on "why" 13:06:53 langdon: +1 13:06:57 hmm but given the long life of EL there is obviously a stronger case of SCL for EL :) 13:07:16 not that I am a against the fedora use case :) 13:07:25 juhp, well.... we could loop on that for a few montths or just agree to disagree :) 13:07:27 juhp: stronger case of new stuff in SCL. for Fedora, it makes perfect sense to provide SCLs with older versions of stuff... 13:07:29 #info better said centos seems to like scls more than fedora 13:07:51 (not sure how to erase already used #info, will learn for the next time :) ) 13:08:05 hhorak: I think #undo does that 13:08:05 hhorak, #undo will... undo the last #command 13:08:13 I have to leave soon I am aftaid 13:08:14 r 13:08:49 langdon, no doubt - I think it is hard to argue that the case is stronger for fedora though :) 13:08:51 bochecha: thanks, will do the next time :) 13:09:15 * langdon admits he is good at arguing.. and often enjoys it ;) 13:09:29 * bkabrda can confirm that ;) 13:09:40 any impact of the scl move to Centos? 13:10:08 well might not be ideal for fedora scl... perhaps 13:10:50 do y'all foresee "changes" coming from centos that might need to come back to fedora? (primarily thinking scl-utils rather than scls themselves) 13:11:28 do future plans for scl-utils need to be vetted in the centos community before landing in fedora? 13:11:43 * langdon has an aversion to capital letters 13:12:07 juhp: if some impact, then positive imho :) since we would like to do more 'upstream development' there, which then may be quite easily moved to fedora (while fedora would be de-facto downstream) 13:12:35 langdon: good question. I think that scl-utils development is still up to the upstream. I think that the upstream will reach out to stakeholders to make sure any changes are acceptable for everyone 13:12:53 i am sorry people but i see this as the wrong direction, Fedora is a place if you want to do something you can do it and it then goes downstream to everything else including rhel and Centos 13:12:59 langdon: and also I think that Fedora will still pick up changes in scl-utils faster 13:13:53 Southern_Gentlem, i think that was what i was wondering... but if fedora doesn't see a need for the tech, they probably shouldn't be a "constituent" in its design 13:14:16 langdon, I'm not sure I've seen anywhere that Fedora doesn't see a need for the tech 13:14:37 bochecha, could you elaborate? 13:14:37 so are we talking about scl-utils or SCLs as in built collections, e.g. python33 13:14:55 langdon, if there are people to work on it fedora is a great place for it to be otherwise you are creating a circular dependancy fedora>rhel>centos>fedora 13:15:06 langdon, you say « if fedora doesn't see a need for the tech », so in a way, I was asking you to elaborate on what gives you this impression :) 13:15:15 because it's not the one I have 13:15:19 imho scl-utils should be taken as ordinary package -- upstream -> fedora -> centos -> ... 13:15:25 hhorak: agreed 13:15:55 and at the same time for SCLs as in "built collections" this approach doesn't make much sense 13:16:07 fedora is a meterocisy if you have people to do it do it 13:16:14 I mean why would we create python34 SCL for Fedora when Python 3.4 is already in base Fedora? 13:16:27 after all thats how alot of things exist in fedora (kde etc..) 13:16:43 bkabrda, it's not in F20 for example 13:17:12 bochecha: true, but I'm not sure that there is enough desire for it (unlike in CentOS community) 13:17:19 bochecha, well, fedora rejected (via fpc) the scl concept as being in violation of the packaging rules = I extrapolate, fedora is not a consumer of scls (which i loosely translated to "not interested in the tech).. maybe you disagree with my rewording? 13:17:22 bkabrda, there is, someone even made a copr for it: https://copr.fedoraproject.org/coprs/hguemar/python34-fedora20/ 13:18:02 langdon, what I've seen is that fesco agreed on the concept, and decided we wanted it in fedora, then tasked the fpc to figure out the « how » 13:18:08 langdon, please, "FPC not interested", which doesn't means "Fedora not interested" 13:18:25 langdon, the fpc never figured out the « how », but I still see Fedora contributors in general being interested in the concept 13:18:27 bochecha: that's not a collection, or is it? 13:19:08 bkabrda, it isn't, but that doesn't matter much: what matters is that contrarily to what you said, there IS a demand in fedora for newer/older stacks to be available 13:19:14 ha.. ok.. lets not reopen the argument.. :) how about focus on the "envs and stacks may need something like scl to fufill its mission" ... does scl-utils feature set being driven by rhel/centos impact that? 13:19:27 bkabrda, the fact it isn't a scl is merely due to the fact that scls are entirely unneeded for python 13:19:30 guys you are arguing over symantics now , but any development needs to be fedora based. 13:19:33 bochecha: yeah, I see your point, I was "justsaying" 13:19:51 Southern_Gentlem, huge +1 13:20:30 * langdon knows he saw a dead horse in here somewhere :) 13:21:23 bochecha: so Python is one case, but what about Rubys, Perls, ... my point is that I'm not sure that there is enough interest for all the SCLs. 13:22:07 bkabrda, ruby 2 & rails 4 is definitely a case for going backwards.. or are you looking for forward cases? 13:22:09 and we may not like it and we may think it's the wrong way; but I think it's just a fact that we need to work with 13:22:14 if forward.. gcc? 13:22:24 bkabrda, there is a difference between the scls as content, and the scl as a technology to build/distribute that content 13:22:53 bochecha: I thought we were discussing the specific SCLs that would then be rebuilt for CentOS... were we not? 13:22:54 bkabrda, the latter seems extremely interesting, something that would provide lots of value to fedora, something we really need... even if we don't need some of the existing scls as content 13:23:08 #info there are still valid use cases for SCLs in Fedora 13:23:18 bochecha, +1 13:23:29 bochecha: I do agree that evolving scl-utils (SCL as a technology) should happen in Fedora first 13:23:49 * bkabrda is a bit confused 13:24:09 bkabrda, except that's moving to CentOS, because « fedora isn't interested » or « it makes more sense in CentOS », isn't it? 13:24:34 #info One specific and strong need in Fedora is to have the SCL as a technology to build/distribute that content 13:25:33 hhorak, did you mean "SCLs as a technology should be implemented in Fedora first, irrelevant of its consumption of the content" ? 13:26:18 bochecha: well, I'm quite sure that there will always be some people interested in using scl-utils in Fedora and building SCLs in Copr. and the latest upstream releases will also reach Fedora first. so in this sense the development will still be "Fedora first" 13:26:44 bochecha: I think we're actually in agreement here :) 13:27:27 langdon: even though I don't see much difference there, I will at least try the #undo :) 13:27:28 #undo 13:27:28 Removing item from minutes: INFO by hhorak at 13:24:34 : One specific and strong need in Fedora is to have the SCL as a technology to build/distribute that content 13:27:41 #info SCLs as a technology should be implemented in Fedora first, irrelevant of its consumption of the content 13:29:00 bkabrda: +1 13:30:53 and that brings me to another question I don't remember any specific decision yet -- is copr good enough tool to be source of the official bits for collections? (now thinking about particular content already, e.g. python26 collection) 13:32:38 i thought playground (some day) would support scl, no? 13:32:43 hhorak: I don't see why it wouldn't... any specific concerns? 13:33:20 langdon: definitely 13:33:43 bkabrda: no, just wanted to check if we're on the same page.. 13:36:17 ok, thanks for all the opinions, I'll try to summarize all already made decisions and the ideas from today somehow.. 13:37:43 And I think we're exceeding enough today.. Does anybody has something to mention? 13:39:01 #topic Chairman for next meeting 13:40:51 timeout 2 minutes for closing the meeting and for volunteer to chair the next meeting.. 13:41:24 not sure if I'll be able to make it next time, so I don't think I'm an ideal candidate for chairman 13:43:01 np, I should be here.. 13:44:03 #endmeeting