From hhorak at redhat.com Wed Dec 3 18:35:08 2014 From: hhorak at redhat.com (Honza Horak) Date: Wed, 03 Dec 2014 19:35:08 +0100 Subject: [scl.org] Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-03) Message-ID: <547F57DC.101@redhat.com> Initial content: * there were concerns what will happen with downstream collections already in git.c.o -- we'll let the existing SCLs as they are now, at least for beginning * the sig can/could/should provide them as a build (not priority for beginning) * we should see what the biggest consumers need -- openshift origins or foreman * since there is quite big demand for php and mariadb, we will begin with those two collections New scl-utils: * next version of scl-utils will offer environment modules, but it is not ready so far Access to git/koji: * since nobody objected against proposed git structure, we'll start with what is proposed at https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal * in order to start we need to submit a bug with login, gpg public key, email and request git/koji access for both services in parallel * in koji, alphacc is executioner on the koji setup, but mikem, imcleod_ and MerlinTHP might be able to help as well Bug reporting: * we do not know how to track bugs so far Full meeting log attached. Conversation will continue at https://www.redhat.com/mailman/listinfo/sclorg. Honza -------------- next part -------------- Log from SCL SIG meeting from 2014-12-03: (05:01:22 PM) hhorak: Hi guys, let's see who's here for talking about SCL.. (05:03:09 PM) gsanchietti_ left the room (quit: Quit: Ex-Chat). Jarek_P jbrooks jcpunk Jeff_S Jehane jeremy jfilak jmelis jnix jorton juergh jvb jzb Jarek_P jbrooks jcpunk Jeff_S Jehane jeremy jfilak jmelis jnix jorton juergh jvb jzb (05:05:26 PM) hhorak: Ah, I still see jorton here only, anybody else from SCL SIG here? (05:05:46 PM) The account has disconnected and you are no longer in this chat. You will automatically rejoin the chat when the account reconnects. (05:06:06 PM) The topic for #centos-devel is: CentOS Developers and Contributors room | If you have questions regarding CentOS please see #centos (05:06:06 PM) Topic for #centos-devel set by z00dax!~kbsingh at chakra.karan.org at 09:26:30 AM on 12/11/2012 (05:06:27 PM) jorton: hhorak: sorry just got a cuppa. I'm here! (05:06:35 PM) RemiFedora: hhorak, is there any ML setup for this SIG ? (05:06:55 PM) hhorak: jorton: Ah, good, I was not sure if my connection was fine.. redkilian reetp RemiFedora (05:08:02 PM) hhorak: RemiFedora: not yet, we used centos-devel so far (05:08:26 PM) RemiFedora: ok, so nothing I could have miss (05:08:32 PM) Evolution: RemiFedora: I believe the initial idea was to continue to use the scl.org mailing lists for daily/common things and the centos-devel list for the mechanics (git/builder interface etc) (05:09:03 PM) Evolution: hhorak: I'm jperrin from the lists and related threads FYI evilissimo Evolution (05:09:31 PM) hhorak: Evolution: Hi, great. (05:10:40 PM) Evolution: hhorak: did pat's concern for existing (RH)SCL stuff make sense? (05:11:54 PM) hhorak: Evolution: yes, that was one thing I wanted to discuss, so why not start with it.. (05:12:31 PM) fab [~fab at 147.87.47.184] entered the room. (05:12:50 PM) hhorak: I simply envisioned to let the existing SCLs as they are now, at least for beginning. Does it make sense? (05:13:42 PM) Evolution: yes. I look at the rhscl bits as a separate animal, untouched by the sig. (05:14:03 PM) Evolution: the sig can/could/should certainly provide them as a build (05:15:17 PM) Evolution: but to me that's something that is downstream from the sig, if that makes sense. (05:16:26 PM) hhorak: right, I understand it the same. Anyway, I'd rather give less priority for building these downstream rhscl bits and focus on the upstream more, so we do faster progress with the upstream bits. (05:17:06 PM) kbsingh: 'm lurking (05:17:27 PM) jorton: hhorak: I definitely agree there (05:18:16 PM) Evolution: hhorak: so long as users are able to install dependent community project things like openshift origins or foreman etc, I'm fine with that (05:19:58 PM) hhorak: Evolution: do you know who else besides openshift and foreman projects has some bigger demand on SCLs in CentOS? (05:20:57 PM) Evolution: hhorak: there are some inroads into HPC type computing (05:21:18 PM) kbsingh: there is a reasonable level of end user demand as well (05:21:44 PM) kbsingh: -lots- of projects need a newer php for example, and are willing to consider the scl route for delivery ( I've spoken with atleast the drupal / wordpress folks about this in the recent past ) (05:22:12 PM) kbsingh: the mariadb project has also expressed interest in doing their from-upstream-rpms as a scl instead of packages that stamp over mysql/maraidb in el6/7 (05:22:58 PM) Evolution: hhorak: fwiw, the hpc folks I've talked to would like some level of integration with modules (environment-modules rpm in base) (05:23:48 PM) hhorak: ok, php and mariadb seem like very good start, since new versions of those collections seem to be in a good shape already (05:24:04 PM) Evolution: (sorry if I'm taking you off track, I get distracted easily) (05:24:11 PM) jorton: Evolution: the scl-utils engineers have environment modules support in the next version (05:24:27 PM) Evolution: jorton: oh swank. that'll be nice (05:24:41 PM) jorton: we got a demo this week - it looks neat (05:25:06 PM) jorton: so "scl load php55" and similar work to change your current shell env (05:25:56 PM) hhorak: Evolution: it'll take some time until scl-utils upstream releases something ready, but I'd like to start using it for centos builds right after we have it ready. redkilian reetp RemiFedora (05:26:40 PM) sbonazzo left the room (quit: Quit: Leaving.). (05:26:58 PM) harish left the room (quit: Ping timeout: 255 seconds). (05:28:43 PM) maxamillion: sorry I'm late, had a Dr. Appointment (05:29:00 PM) hhorak: maxamillion: welcome (05:29:00 PM) jorton: hhorak: +1. what's the status on git structure? I didn't see much feedback, does that mean everybody agrees? (05:29:02 PM) Evolution: maxamillion: would what hhorak said impact openshift at all? (05:29:14 PM) Evolution: maxamillion: would having newer scl-utils cause issues? (05:29:55 PM) hhorak: jorton: it seems to me like nobody has some big objections, so I'd start with what was proposed (05:30:02 PM) maxamillion: Evolution: let me read the backscroll (05:32:31 PM) maxamillion: Evolution: hhorak:I think I'm missing context ... what are the planned changes to scl-utils? (05:33:24 PM) hhorak: Evolution: maxamillion: scl-utils guys are now trying to implement some new features into scl-utils (like environment modules; now working on making it more compatible with current approach) (05:33:54 PM) maxamillion: hhorak: ah ok, is it going to break backwards compatible use of 'scl enable $SCL "some command"' ? (05:34:20 PM) hhorak: maxamillion: no, this should work the same. (05:34:52 PM) maxamillion: hhorak: sounds great then, +1 ... I'd be happy to help where I'm able even if that's just testing and providing feedback (05:35:13 PM) maxamillion: (if that would be helpful) (05:35:44 PM) hhorak: maxamillion: sure it will, it should be available on github hopefully soon (05:35:56 PM) maxamillion: hhorak: very cool, looking forward to it (05:38:22 PM) maxamillion: hhorak: where on github will that live? (05:39:35 PM) hhorak: probably github.com/sclorg but I recently got also github.com/softwarecollections, which we hadn't owned before, so I'm not sure if the nice organization name is worth moving stuff from sclorg to softwarecollections organization (05:40:13 PM) harish [~harish at n182z4l226.static.ctm.net] entered the room. (05:44:02 PM) straylen left the room (quit: Quit: Leaving.). (05:44:14 PM) hhorak: so, in order to have some action items after this meeting, we should be ready to request git repositories for the few testing collections (mariadb, php, ...), as mentioned in http://wiki.centos.org/SpecialInterestGroup/#head-92d585db21d66ee32d1f63d4be9a3917a10b3236 (05:44:35 PM) hhorak: But I don't understand if we need to use some tracker or just contact someone from infra directly (or a mail to infra?) (05:45:36 PM) fab left the room (quit: Ping timeout: 250 seconds). (05:46:56 PM) goldfish left the room (quit: Ping timeout: 256 seconds). ksb kstange ksb kstange (05:48:29 PM) hhorak: kbsingh: Evolution: ^ does anybody know? (05:48:57 PM) kbsingh: hhorak: the best way to do this is to open a issue req at bugs.c.o (05:49:41 PM) kbsingh: hhorak: you need to request a couple of things, (1) git repos for upstream work and (2) acls for users to commit into those repos and (3) userlist ( ideally same, or smaller than git access ) for koji build access at cbs.centos.org (05:50:17 PM) kbsingh: once we have those bits in place, either Evolution or I can work with you to setup further mirrors for the git repos etc. (05:50:46 PM) kbsingh: and you might need to liase with alphacc for any koji specific issues ( in that if the koji setup needs any specific love to build scls ) (05:50:46 PM) BRLX left the room (quit: Quit: BRLX). (05:53:24 PM) hhorak: it does need a bit, so it will be fun.. (05:54:02 PM) kbsingh: hhorak: in that case, i guess it might be best to open tickets for all these things and push in parallel (05:54:25 PM) Evolution: sounds about right. (05:54:31 PM) kbsingh: alphacc is executioner on the koji setup, but i suspect mikem and imcleod_ and MerlinTHP ( amongst others ) might be able to help as well (05:55:05 PM) fab [~fab at 147.87.47.184] entered the room. (05:55:08 PM) hhorak: kbsingh: fine, that makes sense. (05:55:13 PM) imcleod_ is now known as imcleod (05:55:36 PM) Evolution: hhorak: as a side question, how would you like to track bugs for scl.org? (05:55:47 PM) kbsingh: bugs ? what bugs ? (05:55:49 PM) Evolution: heh (05:55:52 PM) kbsingh: i only see a dev/null (05:56:20 PM) Evolution: I'm 100% fine with that BOFH style approach, but I suspect users may not be ;-) (05:56:21 PM) kbsingh: damn, a slash ruined by joke (05:57:53 PM) hhorak: Evolution: this is a good question :) honestly I don't know yet... what BOFH style approach means? (05:58:20 PM) jorton: I think he means, "if it breaks, they get to keep the pieces"! (05:58:34 PM) hhorak: jorton: ah, nice :) (05:58:52 PM) goldfish [~goldfish at 91.215.166.4] entered the room. (06:00:04 PM) hhorak: actually one question for the acls -- is this connected to account on bugs.c.o? (06:00:10 PM) hhorak: kbsingh: ^ (06:00:29 PM) Evolution: hhorak: currently bugs, git and koji do not share common auth. (06:00:51 PM) Evolution: this is something we're working on implementing in the future, likely via freeipa (06:01:07 PM) kbsingh: there is a template bug report that alphacc had put up with details ( or was it bstinson ) - in the wiki (06:01:10 PM) fab left the room (quit: Ping timeout: 255 seconds). (06:02:19 PM) Evolution: http://wiki.centos.org/HowTos/CommunityBuildSystem (06:04:26 PM) hhorak: Evolution: ok, thanks. As soon as I get the public keys, I'll submit that bug. (06:04:33 PM) outi left the room (quit: Quit: Lost terminal). (06:06:15 PM) hhorak: Well, it seems we've enough on the todo list for the next days, so can we end it now and meet the next week the same time? (06:06:42 PM) hhorak: (I'll send some minutes tomorrow morning) From rvokal at redhat.com Thu Dec 4 08:53:21 2014 From: rvokal at redhat.com (Radek Vokal) Date: Thu, 04 Dec 2014 09:53:21 +0100 Subject: [scl.org] Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-03) In-Reply-To: <547F57DC.101@redhat.com> References: <547F57DC.101@redhat.com> Message-ID: <54802101.7010402@redhat.com> On 12/03/2014 07:35 PM, Honza Horak wrote: > Initial content: > * there were concerns what will happen with downstream collections > already in git.c.o -- we'll let the existing SCLs as they are now, at > least for beginning > * the sig can/could/should provide them as a build (not priority for > beginning) > * we should see what the biggest consumers need -- openshift origins > or foreman > * since there is quite big demand for php and mariadb, we will begin > with those two collections > > New scl-utils: > * next version of scl-utils will offer environment modules, but it is > not ready so far > > Access to git/koji: > * since nobody objected against proposed git structure, we'll start > with what is proposed at > https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal > * in order to start we need to submit a bug with login, gpg public > key, email and request git/koji access for both services in parallel > * in koji, alphacc is executioner on the koji setup, but mikem, > imcleod_ and MerlinTHP might be able to help as well > > Bug reporting: > * we do not know how to track bugs so far Honzo, so what's the connection now to scl.org? Will build collections appear there eventually? Can the bug tracker be hosted there? I know we had a testing askbot instance at scl.org - should that be used for user feedback? Radek > > Full meeting log attached. > > Conversation will continue at > https://www.redhat.com/mailman/listinfo/sclorg. > > Honza > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From hhorak at redhat.com Thu Dec 4 12:20:04 2014 From: hhorak at redhat.com (Honza Horak) Date: Thu, 04 Dec 2014 13:20:04 +0100 Subject: [scl.org] Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-03) In-Reply-To: <54802101.7010402@redhat.com> References: <547F57DC.101@redhat.com> <54802101.7010402@redhat.com> Message-ID: <54805174.80900@redhat.com> On 12/04/2014 09:53 AM, Radek Vokal wrote: > On 12/03/2014 07:35 PM, Honza Horak wrote: >> Initial content: >> * there were concerns what will happen with downstream collections >> already in git.c.o -- we'll let the existing SCLs as they are now, at >> least for beginning >> * the sig can/could/should provide them as a build (not priority for >> beginning) >> * we should see what the biggest consumers need -- openshift origins >> or foreman >> * since there is quite big demand for php and mariadb, we will begin >> with those two collections >> >> New scl-utils: >> * next version of scl-utils will offer environment modules, but it is >> not ready so far >> >> Access to git/koji: >> * since nobody objected against proposed git structure, we'll start >> with what is proposed at >> https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal >> * in order to start we need to submit a bug with login, gpg public >> key, email and request git/koji access for both services in parallel >> * in koji, alphacc is executioner on the koji setup, but mikem, >> imcleod_ and MerlinTHP might be able to help as well >> >> Bug reporting: >> * we do not know how to track bugs so far > > Honzo, so what's the connection now to scl.org? Will build collections > appear there eventually? I believe this is the best way to go, and at that point we don't need to rebuild collections in copr any more, since it does not make sense to build almost same collections twice. That would mean to add a new way to sync bits from centos koji, but should not be hard to do. > Can the bug tracker be hosted there? It could. CentOS currently suggests to use bugs.centos.org [1], but having a bug tracker on scl.org for all collections available there (near where the bits are announced) makes sense to me. [1] http://wiki.centos.org/AdditionalResources/Repositories/SCL > I know we > had a testing askbot instance at scl.org - should that be used for user > feedback? You mean instead of proper bug tracker? We can give it a try and see if it works. Honza > Radek > >> >> Full meeting log attached. >> >> Conversation will continue at >> https://www.redhat.com/mailman/listinfo/sclorg. >> >> Honza >> >> >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg >> > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From seo.webtrafficmedia at gmail.com Thu Dec 4 15:01:15 2014 From: seo.webtrafficmedia at gmail.com (Vicky Bhat) Date: Thu, 04 Dec 2014 15:01:15 +0000 Subject: [scl.org] Organic SEO for Softwarecollections.org Message-ID: <001a11332f825cc7c70509653bad@google.com> Dear business owner of Softwarecollections.org, I would like to take a few minutes from your schedule and ask for your attention towards Internet marketing for Softwarecollections.org. As a business Owner you might be interested to gain profit by placing your website among top in search engines. Your website needs immediate improvement for some major issues with your website. -Low online presence for many competitive keyword phrases -Unorganized social media accounts -Not compatible with all mobile devices -Many bad back links to your website Looking at the above issues and other additional improvements for your website, I would request you to give us a chance to fix those issues. Our team of Search Engine and Social Media experts are here to serve you with best inputs. If you are interested in learning more about current status of your website, we would be glad to share WEBSITE AUDIT REPORT of *Softwarecollections.org for FREE. You will feel the difference once you get services from our company as we never let our clients expectations go down. Being at the top left of Google (#1- #3 organic positions) is the best thing you can do for your company's website traffic and online reputation. You will be happy to know that, my team is willing to guarantee you 1st page Google ranking for your targeted local keyword phrases. If my proposal sound's interesting for your business goal, feel free to email us, or can provide me with your phone number and the best time to call you. I am also available for an online meeting to present you this website audit report. ----------------------------------------------------------------- Best Regards, Vicky Bhat Marketing Consultant -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Thu Dec 4 17:29:29 2014 From: hhorak at redhat.com (Honza Horak) Date: Thu, 04 Dec 2014 18:29:29 +0100 Subject: [scl.org] Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-03) In-Reply-To: <547F57DC.101@redhat.com> References: <547F57DC.101@redhat.com> Message-ID: <548099F9.9090202@redhat.com> On 12/03/2014 07:35 PM, Honza Horak wrote: > Initial content: > * there were concerns what will happen with downstream collections > already in git.c.o -- we'll let the existing SCLs as they are now, at > least for beginning > * the sig can/could/should provide them as a build (not priority for > beginning) > * we should see what the biggest consumers need -- openshift origins > or foreman > * since there is quite big demand for php and mariadb, we will begin > with those two collections > > New scl-utils: > * next version of scl-utils will offer environment modules, but it is > not ready so far > > Access to git/koji: > * since nobody objected against proposed git structure, we'll start > with what is proposed at > https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal > * in order to start we need to submit a bug with login, gpg public > key, email and request git/koji access for both services in parallel > * in koji, alphacc is executioner on the koji setup, but mikem, > imcleod_ and MerlinTHP might be able to help as well Two questions I asked today about access, so sharing further: 1) About the concept of git access: We will be able to create 'upstream' repos, as many as we like, but we will need to ask for repos to be created under the rpms/ project but most of our dev work will be in the sig project space, in upstream repos, so we should be all set 2) Who all will be able to gain access for git and koji Once centos havs auth in place, that will be easier to manage, as groups can be used. Right now all accounts are manual. Everyone will still need to be part of the SIG though. They can be contributors, not leaders/voting parties, etc. but part of the sig. That means we will need to include all rhscl devels into SIG at some point. Honza > Bug reporting: > * we do not know how to track bugs so far > > Full meeting log attached. > > Conversation will continue at > https://www.redhat.com/mailman/listinfo/sclorg. > > Honza > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From pkovar at redhat.com Thu Dec 4 18:39:50 2014 From: pkovar at redhat.com (Petr Kovar) Date: Thu, 4 Dec 2014 19:39:50 +0100 Subject: [scl.org] Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-03) In-Reply-To: <54805174.80900@redhat.com> References: <547F57DC.101@redhat.com> <54802101.7010402@redhat.com> <54805174.80900@redhat.com> Message-ID: <20141204193950.530e97be52c490844733d1c9@redhat.com> Hi, On Thu, 04 Dec 2014 13:20:04 +0100 Honza Horak wrote: > On 12/04/2014 09:53 AM, Radek Vokal wrote: > > On 12/03/2014 07:35 PM, Honza Horak wrote: > >> Initial content: > >> * there were concerns what will happen with downstream collections > >> already in git.c.o -- we'll let the existing SCLs as they are now, at > >> least for beginning > >> * the sig can/could/should provide them as a build (not priority for > >> beginning) > >> * we should see what the biggest consumers need -- openshift origins > >> or foreman > >> * since there is quite big demand for php and mariadb, we will begin > >> with those two collections > >> > >> New scl-utils: > >> * next version of scl-utils will offer environment modules, but it is > >> not ready so far > >> > >> Access to git/koji: > >> * since nobody objected against proposed git structure, we'll start > >> with what is proposed at > >> https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal > >> * in order to start we need to submit a bug with login, gpg public > >> key, email and request git/koji access for both services in parallel > >> * in koji, alphacc is executioner on the koji setup, but mikem, > >> imcleod_ and MerlinTHP might be able to help as well > >> > >> Bug reporting: > >> * we do not know how to track bugs so far > > > > Honzo, so what's the connection now to scl.org? Will build collections > > appear there eventually? > > I believe this is the best way to go, and at that point we don't need to > rebuild collections in copr any more, since it does not make sense to > build almost same collections twice. That would mean to add a new way to > sync bits from centos koji, but should not be hard to do. > > > Can the bug tracker be hosted there? > > It could. CentOS currently suggests to use bugs.centos.org [1], but > having a bug tracker on scl.org for all collections available there > (near where the bits are announced) makes sense to me. > > [1] http://wiki.centos.org/AdditionalResources/Repositories/SCL > > > I know we > > had a testing askbot instance at scl.org - should that be used for user > > feedback? > > You mean instead of proper bug tracker? We can give it a try and see if > it works. Docs recently discussed running an askbot instance at scl.org with the site maintainers and we thought it would be better to point people to stackoverflow where there is already a vivid community of people who might be interested in joining the scl community. But then again, if we want to host an upstream bug tracker of some sort at scl.org, then that could give us a bit more traffic than before... Cheers, pk From hhorak at redhat.com Mon Dec 8 12:28:47 2014 From: hhorak at redhat.com (Honza Horak) Date: Mon, 08 Dec 2014 13:28:47 +0100 Subject: [scl.org] Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-03) In-Reply-To: <20141204193950.530e97be52c490844733d1c9@redhat.com> References: <547F57DC.101@redhat.com> <54802101.7010402@redhat.com> <54805174.80900@redhat.com> <20141204193950.530e97be52c490844733d1c9@redhat.com> Message-ID: <5485997F.3080406@redhat.com> On 12/04/2014 07:39 PM, Petr Kovar wrote: > Hi, > > On Thu, 04 Dec 2014 13:20:04 +0100 > Honza Horak wrote: > >> On 12/04/2014 09:53 AM, Radek Vokal wrote: >>> On 12/03/2014 07:35 PM, Honza Horak wrote: >>>> Initial content: >>>> * there were concerns what will happen with downstream collections >>>> already in git.c.o -- we'll let the existing SCLs as they are now, at >>>> least for beginning >>>> * the sig can/could/should provide them as a build (not priority for >>>> beginning) >>>> * we should see what the biggest consumers need -- openshift origins >>>> or foreman >>>> * since there is quite big demand for php and mariadb, we will begin >>>> with those two collections >>>> >>>> New scl-utils: >>>> * next version of scl-utils will offer environment modules, but it is >>>> not ready so far >>>> >>>> Access to git/koji: >>>> * since nobody objected against proposed git structure, we'll start >>>> with what is proposed at >>>> https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal >>>> * in order to start we need to submit a bug with login, gpg public >>>> key, email and request git/koji access for both services in parallel >>>> * in koji, alphacc is executioner on the koji setup, but mikem, >>>> imcleod_ and MerlinTHP might be able to help as well >>>> >>>> Bug reporting: >>>> * we do not know how to track bugs so far >>> >>> Honzo, so what's the connection now to scl.org? Will build collections >>> appear there eventually? >> >> I believe this is the best way to go, and at that point we don't need to >> rebuild collections in copr any more, since it does not make sense to >> build almost same collections twice. That would mean to add a new way to >> sync bits from centos koji, but should not be hard to do. >> >>> Can the bug tracker be hosted there? >> >> It could. CentOS currently suggests to use bugs.centos.org [1], but >> having a bug tracker on scl.org for all collections available there >> (near where the bits are announced) makes sense to me. >> >> [1] http://wiki.centos.org/AdditionalResources/Repositories/SCL >> >>> I know we >>> had a testing askbot instance at scl.org - should that be used for user >>> feedback? >> >> You mean instead of proper bug tracker? We can give it a try and see if >> it works. > > Docs recently discussed running an askbot instance at scl.org with the > site maintainers and we thought it would be better to point people to > stackoverflow where there is already a vivid community of people who might > be interested in joining the scl community. I wonder what the opinion of site maintainers was. From my PoV, that makes great sense to me, since using this kind of service depends mostly on community size. The only disadvantage of using stackoverflow would be dividing content for RH's product RHSCL and non- scl.org (if we even care about that), which could be improved by proper tags used. Or are there some other issues? > But then again, if we want to host an upstream bug tracker of some sort at > scl.org, then that could give us a bit more traffic than before... So, just couple of my thoughts, since I have no perfect solutions right now.. * we should have something else than RHSCL product in RHBZ, as it is defined right now, since there might be some collections missing and also content could be slightly different * but if it could be located in RHBZ that would be beneficial since centos users are already used to report bugs there * it should be common for centos and scl.org * it should be easy (ideally less complicated than current setup of RHBZ for RHSCL) * it should be transparent and clear how to report bugs I've just found there is already something in RHBZ under Community project and I kind of like it simplicity: https://bugzilla.redhat.com/enter_bug.cgi?product=softwarecollections.org So, why not to use that one? Or is it something new we start using now? Honza From pkovar at redhat.com Mon Dec 8 13:12:52 2014 From: pkovar at redhat.com (Petr Kovar) Date: Mon, 8 Dec 2014 14:12:52 +0100 Subject: [scl.org] Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-03) In-Reply-To: <5485997F.3080406@redhat.com> References: <547F57DC.101@redhat.com> <54802101.7010402@redhat.com> <54805174.80900@redhat.com> <20141204193950.530e97be52c490844733d1c9@redhat.com> <5485997F.3080406@redhat.com> Message-ID: <20141208141252.98842b99807b95665d4c4f0d@redhat.com> On Mon, 08 Dec 2014 13:28:47 +0100 Honza Horak wrote: > On 12/04/2014 07:39 PM, Petr Kovar wrote: > > Hi, > > > > On Thu, 04 Dec 2014 13:20:04 +0100 > > Honza Horak wrote: > > > >> On 12/04/2014 09:53 AM, Radek Vokal wrote: > >>> On 12/03/2014 07:35 PM, Honza Horak wrote: > >>>> Initial content: > >>>> * there were concerns what will happen with downstream collections > >>>> already in git.c.o -- we'll let the existing SCLs as they are now, at > >>>> least for beginning > >>>> * the sig can/could/should provide them as a build (not priority for > >>>> beginning) > >>>> * we should see what the biggest consumers need -- openshift origins > >>>> or foreman > >>>> * since there is quite big demand for php and mariadb, we will begin > >>>> with those two collections > >>>> > >>>> New scl-utils: > >>>> * next version of scl-utils will offer environment modules, but it is > >>>> not ready so far > >>>> > >>>> Access to git/koji: > >>>> * since nobody objected against proposed git structure, we'll start > >>>> with what is proposed at > >>>> https://fedoraproject.org/wiki/User:Hhorak/Draft/centos-scl-git-proposal > >>>> * in order to start we need to submit a bug with login, gpg public > >>>> key, email and request git/koji access for both services in parallel > >>>> * in koji, alphacc is executioner on the koji setup, but mikem, > >>>> imcleod_ and MerlinTHP might be able to help as well > >>>> > >>>> Bug reporting: > >>>> * we do not know how to track bugs so far > >>> > >>> Honzo, so what's the connection now to scl.org? Will build collections > >>> appear there eventually? > >> > >> I believe this is the best way to go, and at that point we don't need to > >> rebuild collections in copr any more, since it does not make sense to > >> build almost same collections twice. That would mean to add a new way to > >> sync bits from centos koji, but should not be hard to do. > >> > >>> Can the bug tracker be hosted there? > >> > >> It could. CentOS currently suggests to use bugs.centos.org [1], but > >> having a bug tracker on scl.org for all collections available there > >> (near where the bits are announced) makes sense to me. > >> > >> [1] http://wiki.centos.org/AdditionalResources/Repositories/SCL > >> > >>> I know we > >>> had a testing askbot instance at scl.org - should that be used for user > >>> feedback? > >> > >> You mean instead of proper bug tracker? We can give it a try and see if > >> it works. > > > > Docs recently discussed running an askbot instance at scl.org with the > > site maintainers and we thought it would be better to point people to > > stackoverflow where there is already a vivid community of people who might > > be interested in joining the scl community. > > I wonder what the opinion of site maintainers was. From my PoV, that > makes great sense to me, since using this kind of service depends mostly > on community size. > > The only disadvantage of using stackoverflow would be dividing content > for RH's product RHSCL and non- scl.org (if we even care about that), > which could be improved by proper tags used. Or are there some other issues? FWIW, we already have a tag for SCLs at stackoverflow: http://stackoverflow.com/questions/tagged/software-collections Cheers, pk From hhorak at redhat.com Wed Dec 10 17:40:41 2014 From: hhorak at redhat.com (Honza Horak) Date: Wed, 10 Dec 2014 18:40:41 +0100 Subject: [scl.org] Initial list of components and branches for CentOS SCL git repo Message-ID: <54888599.5090301@redhat.com> Sending $subject as discussed today. Remi, Joe, I tried to guess components for httpd24 and php56 based on existing builds, feel free to correct it. git repos with scl-mongodb26-el6 and scl-mongodb26-el7 branches: boost gperftools snappy scons libunwind gtest mongodb26 mongodb git repos with scl-mariadb100-el6 and scl-mariadb100-el7 branches: mariadb100 mariadb git repos with scl-postgresql94-el6 and scl-postgresql94-el7 branches: postgresql94 postgresql git repos with scl-httpd24-el6 and scl-httpd24-el7 branches: httpd24 httpd apr apr-util mod_auth_kerb git repos with scl-php56-el6 and scl-php56-el7 branches: php56 php php-pear php-pecl-memcache php-pecl-mongo php-pecl-jsonc Thanks, Honza From hhorak at redhat.com Wed Dec 10 18:13:59 2014 From: hhorak at redhat.com (Honza Horak) Date: Wed, 10 Dec 2014 19:13:59 +0100 Subject: [scl.org] Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-10) Message-ID: <54888D67.4050601@redhat.com> Mainly discussed git repositories: * hhorak will send initial list of packages to Evolution to start with git structure preparation * we'll include mongodb26, mariadb100, postgresql94, php56 and httpd24 collections for beginning and continue with other larger collections later * it seems we do not need to provide all collections as upstream collections unless there are any changes from downstream collections * building downstream collections (currently only source rpms are automatically sync from RH) will be figured out after we can build upstream collections * we'll have 2 repos, 1 for "devel" (upstream) and 1 for "stable (downstream, those currently synced) * build in cbs setup was not tested yet * buildroots for collections will include all built packages, but need to be separate for collections to be able to install different sclname-build packages inside the buildroot * nothing like bodhi is in centos right now; script automatically pull all builds tagged somehow (every 10 minuts) * when extending the SIG with other SCL maintainers, info about them will be placed on the wiki page * project admin code conflicts with the commit by branch acl thing we have... kbsingh will work it out * hhorak will send an invitation for the meeting the next week, the meeting will be at the same time, same place Full meeting log attached. Conversation may continue at https://www.redhat.com/mailman/listinfo/sclorg. Honza -------------- next part -------------- (05:03:38 PM) hhorak: Hi, anyone to chat about SCL? (05:03:43 PM) hhorak: (SIG) evilissimo Evolution (05:04:06 PM) RemiFedora: hhorak, I'm here if you need me ;) redkilian reetp RemiFedora (05:04:30 PM) filippoc [~filippo at nethservice.nethesis.it] entered the room. (05:04:30 PM) hhorak: RemiFedora: Cool, hi! (05:06:51 PM) jorton [~jorton at iberis.manyfish.co.uk] entered the room. (05:07:17 PM) hhorak: Evolution: Could I ask about the ticket for creating git/koji? Just wanted to check if there are some blockers somewhere and how it goes on centos side.. ksb kstange ksb kstange (05:09:18 PM) hhorak: Maybe kbsingh knows something? ^ (05:09:24 PM) Evolution: hhorak: you put the access ticket in against the administrative project. (05:09:38 PM) Evolution: alphacc doesn't have access to that, and I didn't see it right away (05:09:48 PM) Evolution: I copied the issue to the buildsys project and added alphacc. (05:09:54 PM) Evolution: he should be able to get it in there semi-soon (05:10:26 PM) Evolution: in the meantime, I can create the project structure in git, but I need to know the initial repos you'll need. (05:10:40 PM) hhorak: Evolution: Oh, sorry.. (05:10:55 PM) blip1 [~dewey at c-24-8-56-246.hsd1.co.comcast.net] entered the room. (05:10:56 PM) Evolution: I don't *think* I can grant git permissions based on project. pretty sure it's per repo, but I'll check with kbsingh on that (05:12:54 PM) hhorak: Evolution: ok.. I'll send you a list of few initial collections via mail -- mongodb26, mariadb100, postgresql94 (that's what my team is responsible for), just to check how it works and then we can continue with language collections that include more packages.. redkilian reetp RemiFedora (05:13:34 PM) blip left the room (quit: Ping timeout: 244 seconds). (05:13:35 PM) hhorak: RemiFedora: would you like to join with php into the first round so you can try it on your own as well? (05:14:19 PM) RemiFedora: hhorak, php have dep. on httpd24 scl (05:14:26 PM) jorton: hi guy, sorry I'm late (05:14:33 PM) Evolution: hhorak: okay. there's also a guy who's got a basic ocaml package as well. http://lists.centos.org/pipermail/centos-devel/2014-December/012459.html (05:14:48 PM) jorton: we could try with httpd24, that is self-contained (05:14:52 PM) Evolution: what would it take to get that reviewed and pulled in (once we have things in git) (05:15:16 PM) blip1 left the room (quit: Ping timeout: 255 seconds). (05:15:38 PM) lalatenduM left the room (quit: Quit: Leaving). (05:16:36 PM) hhorak: jorton: ok, will include httpd24 in the list (05:17:24 PM) hhorak: Evolution: I have no problem with that, I'll look at it and reply in the ML.. (05:18:19 PM) Evolution: awesome. redkilian reetp RemiFedora (05:19:13 PM) hhorak: RemiFedora: so if httpd24 will be included, will you send me list of components for php? (05:19:19 PM) Evolution: hhorak: I'll verify with kb and see about getting the sclo project structure created. (05:19:30 PM) RemiFedora: hhorak, yes, I can (05:19:45 PM) hhorak: RemiFedora: ok (05:19:49 PM) RemiFedora: hhorak, but which SCL ? php54 php55 or php56 ? (05:20:09 PM) dneary [dneary at Maemo/community/docmaster/dneary] entered the room. (05:20:09 PM) bbankes left the room (quit: Ping timeout: 250 seconds). (05:20:36 PM) jorton: might as well be php56! (05:22:09 PM) hhorak: RemiFedora: I was thinking only about new SCLs for databases (older sources are already available under 'rpms' project and if there is no need to do further development except security updates, which is probable, then I wouldn't even include them to the upstream SCLs git) (05:22:56 PM) RemiFedora: hhorak, ok, so only php56, when httpd244 will be ready (05:23:13 PM) ***hhorak thinks we should have some nice distinction between downstream SCLs and upstream SCLs withing CentOS (05:23:27 PM) RemiFedora: well httpd24 is not a new scl... already exists... just need to be sure it is available in the buildroot redkilian reetp RemiFedora (05:23:46 PM) RemiFedora: hhorak, yes... see my question about target repo (05:23:47 PM) hhorak: RemiFedora: ok, in that case we need it there (05:24:11 PM) RemiFedora: I really think we need 2 repo, 1 for "devel" (upstream) and 1 for "stable (downstream) redkilian reetp RemiFedora (05:24:49 PM) bbankes [~bbankes at 50-200-100-242-static.hfc.comcastbusiness.net] entered the room. (05:25:00 PM) tforsman [~tforsman at foresight/developer/tforsman] entered the room. (05:25:29 PM) hhorak: RemiFedora: I agree, it's also included in the proposal (05:26:02 PM) RemiFedora: and a way to move package from "devel" to "stable" when released in RHSCL (05:26:02 PM) mboeru [~mboeru at unaffiliated/mboeru] entered the room. redkilian reetp RemiFedora (05:26:27 PM) samkottler left the room. (05:26:46 PM) hhorak: RemiFedora: right, it means just keep the current sync mechanism in place (05:27:45 PM) RemiFedora: hhorak, but, is there a sync mechanism ? (except for sources) I was thinkg centos-scl repo is stalled ? (05:28:42 PM) hhorak: RemiFedora: you're right, the mechanism is currently for sources only (05:30:03 PM) hhorak: What would make sense to me is to play with koji setup on new collections and as soon as we know how to build the upstream collections, then setting up koji for downstream collections should be similar (05:30:14 PM) mboeru left the room (quit: Ping timeout: 245 seconds). (05:32:09 PM) ***kbsingh gets online (05:32:16 PM) kbsingh: i didnt know there was a scl sig meeting today :( (05:33:39 PM) fab [~fab at 147.87.46.151] entered the room. (05:33:47 PM) hhorak: kbsingh: the meeting was meant to be every week to sync, but I should have send an invitation.. will fix the next week.. (05:33:48 PM) kbsingh: hhorak: Evolution: we can setup a small number of people with admin access to a specific project/ - that would allow them to create git repos as needed - however, i would prefer if we did the bootstrap with a few repos - via the bugs.c.o route. we can then use the acl elevation as a target (05:34:17 PM) mattgriffin left the room (quit: Quit: Textual IRC Client: www.textualapp.com). (05:34:32 PM) kbsingh: hhorak: thanks (05:34:49 PM) kbsingh: the other thing that i dont have closure on is koji requirements for SCL - are you able to actually build a scl on the cbs setup ? (05:34:53 PM) kbsingh: or is that untested so far (05:36:08 PM) tforsman left the room (quit: Ping timeout: 265 seconds). (05:36:08 PM) Evolution: it hasn't been tested yet, but it's possible. if they can't build, then it's a bug in our setup. alphacc seemed confident that it would work, provided we kept the tags sane. (05:36:28 PM) rangerpb: kbsingh, imcleod thoughts on my PR ? (05:36:32 PM) Evolution: I seem to recall alphacc and hhorak having a tags discussion last week (05:36:42 PM) kbsingh: that was my next question are we going to deliver the scl's into one target, or a tag per scl (05:36:51 PM) kbsingh: and therefore a resulting repo per collection (05:37:41 PM) Evolution: good question. (05:37:53 PM) hhorak: kbsingh: there is only one special configuration needed to be done for scl -- buildroot needs to include scl-utils-build and then sclname-build so the scl macro is defined (at least that's how we do it internally) (05:38:21 PM) kbsingh: hhorak: ok, so the tag's will need their own buildsys-build or a buildsys-config rpm (05:38:49 PM) hhorak: kbsingh: yes, unless we use some different approach (but I don't know about any other options right now) (05:39:15 PM) kbsingh: I'm easy - as long as you have something that works, and alphacc has something he can maintain at the other end - were all set (05:39:29 PM) kbsingh: how about the delivery side of things - is this going to be one tag ( and therefore repo ) per collection ? (05:40:50 PM) hhorak: kbsingh: I'd rather see one collection for all, it seems to be easier for users to enable one and then use whatever they want (05:42:00 PM) hhorak: there is also thing that one collection often requires another one, so the tags for building need to contain all the collections, but only have a different set of packages in initial buildroot (05:43:48 PM) hhorak: actually, is there something like bodhi in centos? or every just built package is automatically available for users? (05:44:37 PM) talori [~timothy.l at n219077078209.netvigator.com] entered the room. (05:46:25 PM) michel_slm left the room (quit: Ping timeout: 244 seconds). (05:48:15 PM) kilted1 left the room (quit: Ping timeout: 258 seconds). (05:49:01 PM) kbsingh: hhorak: neither. (05:49:20 PM) kbsingh: hhorak: at the moment, its only possible to build and deliver stuff you tag for release into the cbs.centos.org/repos/ setup (05:49:38 PM) kbsingh: working on getting the signing process done in the coming days - and then we nede to evolve into a release-to-users process. (05:49:51 PM) kbsingh: the new bodhi looks interesting, it might be worth a shot (05:50:06 PM) kbsingh: i guess the answer to your question is : not decided, plenty of scope to get involved and influence decision (05:50:42 PM) gsanchietti left the room (quit: Quit: Ex-Chat). (05:51:11 PM) hhorak: kbsingh: ok, so I'm noting that manual tagging is necessary to publish a build now (or do we need to create the repo manually and such stuff?) (05:51:54 PM) kbsingh: there is a sweeper script that runs every 10 min, and stuff tag'd gets pushed into the matching target repo on cbs.centos.org/repos/ (05:52:23 PM) hhorak: kbsingh: ok, nice (05:55:13 PM) hhorak: Anyway, for who is not aware yet, what I've clarified with guys here since the last week was that everybody involved in the SCL internally needs to be actually be part of the SIG to be able to commit/build in centos (one of the questions that was not answered in the proposal originally).. I guess we're fine with that or do we need to officially approve this and concrete people involved in scl internally now? (06:01:05 PM) kbsingh: the SIG group is really a set of people who take responsibility for the content (06:01:32 PM) kbsingh: you can have anyone contribute, they dont need to be 'official anything' - but it might be a good audit practise to list folks you give git access to on the wiki page for the SIG (06:01:39 PM) kbsingh: it also gives those people some credits (06:01:42 PM) blip [~dewey at unaffiliated/blip] entered the room. (06:02:21 PM) kbsingh: btw, i just checked and the project admin code conflicts with the commit by branch acl thing we have... so i need to work that out (06:02:37 PM) fab left the room (quit: Ping timeout: 250 seconds). (06:02:37 PM) kbsingh: s/work/email the right person/ (06:02:44 PM) kbsingh: but i am confident we can make it happen (06:02:54 PM) BRLX1 left the room (quit: Quit: BRLX1). (06:03:10 PM) hhorak: kbsingh: ok, listing them in the wiki seems fine. (06:03:42 PM) hhorak: but I don't understand what the conflict means -- does that block creating the git repos? (06:03:50 PM) kbsingh: no (06:04:13 PM) kbsingh: a project-amdin ( assume you ) will be able to create users and give them git +rw access to the repos ( either one repo or a group or all the git repos in that project ) (06:04:46 PM) kbsingh: at the moment we have a setup where someone from a sig can commit to any git repo, where the branch being pushed is the same as the sig-name (06:04:47 PM) filippoc1 [~filippo at nethservice.nethesis.it] entered the room. (06:05:02 PM) kbsingh: code that makes the second thing happen, is preventing the first thing from working (06:06:23 PM) chorrell left the room (quit: Quit: Textual IRC Client: www.textualapp.com). (06:06:54 PM) hhorak: ok, thanks for clarification (06:06:59 PM) kbsingh: hhorak: I'll work it out - just wont be right now; (06:07:14 PM) kstange left the room (quit: Quit: Leaving.). (06:07:26 PM) kstange [~kevin at 198.54.109.14] entered the room. (06:07:35 PM) kbsingh: imcleod: ping (06:07:48 PM) kbsingh: hhorak: need to refocus over ot the atomic stuff before i run out of hours/day (06:07:56 PM) kbsingh: hhorak: will you do some summary post to the lists ? (06:08:07 PM) filippoc left the room (quit: Ping timeout: 264 seconds). (06:08:24 PM) kstange left the room (quit: Client Quit). (06:09:00 PM) bbankes_ [~bbankes at 50-200-100-242-static.hfc.comcastbusiness.net] entered the room. (06:09:04 PM) imcleod: kbsingh: Pong (06:09:15 PM) hhorak: I think I have nothing else on my mind anyway and yes, I'll send some summary. Just one thing, I wanted to remind there is http://devconf.cz a week after Fosdem, not sure if you plan to come, but it would be great. (06:09:20 PM) kstange [~kevin at 198.54.109.14] entered the room. (06:09:51 PM) hhorak: Thanks and see you next week again.. (06:10:37 PM) imcleod: kbsingh: Ready to attempt building an Atomic Anaconda install tree? (06:11:15 PM) BRLX [~Thunderbi at rtr.ak-p.at] entered the room. (06:11:17 PM) BRLX left the room (quit: Client Quit). (06:12:01 PM) kbsingh: hhorak: i believe its on the agenda, not sure how many people are coming - I certainly will :) (06:12:21 PM) hhorak: kbsingh: great From veillard at redhat.com Thu Dec 11 01:34:52 2014 From: veillard at redhat.com (Daniel Veillard) Date: Thu, 11 Dec 2014 09:34:52 +0800 Subject: [scl.org] [CentOS-devel] Minutes from CentOS SIG sync-up meeting on #centos-devel (2014-12-10) In-Reply-To: <54888D67.4050601@redhat.com> References: <54888D67.4050601@redhat.com> Message-ID: <20141211013452.GH14723@redhat.com> Thanks for the minutes, also the format where you keep out main items from the chat (which can be used to look at details) is very helpful ! Daniel On Wed, Dec 10, 2014 at 07:13:59PM +0100, Honza Horak wrote: > Mainly discussed git repositories: > * hhorak will send initial list of packages to Evolution to start with git > structure preparation > * we'll include mongodb26, mariadb100, postgresql94, php56 and httpd24 > collections for beginning and continue with other larger collections later > * it seems we do not need to provide all collections as upstream > collections unless there are any changes from downstream collections > * building downstream collections (currently only source rpms are > automatically sync from RH) will be figured out after we can build upstream > collections > * we'll have 2 repos, 1 for "devel" (upstream) and 1 for "stable > (downstream, those currently synced) > * build in cbs setup was not tested yet > * buildroots for collections will include all built packages, but need to > be separate for collections to be able to install different sclname-build > packages inside the buildroot > * nothing like bodhi is in centos right now; script automatically pull all > builds tagged somehow (every 10 minuts) > * when extending the SIG with other SCL maintainers, info about them will > be placed on the wiki page > * project admin code conflicts with the commit by branch acl thing we > have... kbsingh will work it out > * hhorak will send an invitation for the meeting the next week, the meeting > will be at the same time, same place > > Full meeting log attached. > > Conversation may continue at https://www.redhat.com/mailman/listinfo/sclorg. > > Honza > > (05:03:38 PM) hhorak: Hi, anyone to chat about SCL? > (05:03:43 PM) hhorak: (SIG) > evilissimo Evolution > (05:04:06 PM) RemiFedora: hhorak, I'm here if you need me ;) > redkilian reetp RemiFedora > (05:04:30 PM) filippoc [~filippo at nethservice.nethesis.it] entered the room. > (05:04:30 PM) hhorak: RemiFedora: Cool, hi! > (05:06:51 PM) jorton [~jorton at iberis.manyfish.co.uk] entered the room. > (05:07:17 PM) hhorak: Evolution: Could I ask about the ticket for creating git/koji? Just wanted to check if there are some blockers somewhere and how it goes on centos side.. > ksb kstange > ksb kstange > (05:09:18 PM) hhorak: Maybe kbsingh knows something? ^ > (05:09:24 PM) Evolution: hhorak: you put the access ticket in against the administrative project. > (05:09:38 PM) Evolution: alphacc doesn't have access to that, and I didn't see it right away > (05:09:48 PM) Evolution: I copied the issue to the buildsys project and added alphacc. > (05:09:54 PM) Evolution: he should be able to get it in there semi-soon > (05:10:26 PM) Evolution: in the meantime, I can create the project structure in git, but I need to know the initial repos you'll need. > (05:10:40 PM) hhorak: Evolution: Oh, sorry.. > (05:10:55 PM) blip1 [~dewey at c-24-8-56-246.hsd1.co.comcast.net] entered the room. > (05:10:56 PM) Evolution: I don't *think* I can grant git permissions based on project. pretty sure it's per repo, but I'll check with kbsingh on that > (05:12:54 PM) hhorak: Evolution: ok.. I'll send you a list of few initial collections via mail -- mongodb26, mariadb100, postgresql94 (that's what my team is responsible for), just to check how it works and then we can continue with language collections that include more packages.. > redkilian reetp RemiFedora > (05:13:34 PM) blip left the room (quit: Ping timeout: 244 seconds). > (05:13:35 PM) hhorak: RemiFedora: would you like to join with php into the first round so you can try it on your own as well? > (05:14:19 PM) RemiFedora: hhorak, php have dep. on httpd24 scl > (05:14:26 PM) jorton: hi guy, sorry I'm late > (05:14:33 PM) Evolution: hhorak: okay. there's also a guy who's got a basic ocaml package as well. http://lists.centos.org/pipermail/centos-devel/2014-December/012459.html > (05:14:48 PM) jorton: we could try with httpd24, that is self-contained > (05:14:52 PM) Evolution: what would it take to get that reviewed and pulled in (once we have things in git) > (05:15:16 PM) blip1 left the room (quit: Ping timeout: 255 seconds). > (05:15:38 PM) lalatenduM left the room (quit: Quit: Leaving). > (05:16:36 PM) hhorak: jorton: ok, will include httpd24 in the list > (05:17:24 PM) hhorak: Evolution: I have no problem with that, I'll look at it and reply in the ML.. > (05:18:19 PM) Evolution: awesome. > redkilian reetp RemiFedora > (05:19:13 PM) hhorak: RemiFedora: so if httpd24 will be included, will you send me list of components for php? > (05:19:19 PM) Evolution: hhorak: I'll verify with kb and see about getting the sclo project structure created. > (05:19:30 PM) RemiFedora: hhorak, yes, I can > (05:19:45 PM) hhorak: RemiFedora: ok > (05:19:49 PM) RemiFedora: hhorak, but which SCL ? php54 php55 or php56 ? > (05:20:09 PM) dneary [dneary at Maemo/community/docmaster/dneary] entered the room. > (05:20:09 PM) bbankes left the room (quit: Ping timeout: 250 seconds). > (05:20:36 PM) jorton: might as well be php56! > (05:22:09 PM) hhorak: RemiFedora: I was thinking only about new SCLs for databases (older sources are already available under 'rpms' project and if there is no need to do further development except security updates, which is probable, then I wouldn't even include them to the upstream SCLs git) > (05:22:56 PM) RemiFedora: hhorak, ok, so only php56, when httpd244 will be ready > (05:23:13 PM) ***hhorak thinks we should have some nice distinction between downstream SCLs and upstream SCLs withing CentOS > (05:23:27 PM) RemiFedora: well httpd24 is not a new scl... already exists... just need to be sure it is available in the buildroot > redkilian reetp RemiFedora > (05:23:46 PM) RemiFedora: hhorak, yes... see my question about target repo > (05:23:47 PM) hhorak: RemiFedora: ok, in that case we need it there > (05:24:11 PM) RemiFedora: I really think we need 2 repo, 1 for "devel" (upstream) and 1 for "stable (downstream) > redkilian reetp RemiFedora > (05:24:49 PM) bbankes [~bbankes at 50-200-100-242-static.hfc.comcastbusiness.net] entered the room. > (05:25:00 PM) tforsman [~tforsman at foresight/developer/tforsman] entered the room. > (05:25:29 PM) hhorak: RemiFedora: I agree, it's also included in the proposal > (05:26:02 PM) RemiFedora: and a way to move package from "devel" to "stable" when released in RHSCL > (05:26:02 PM) mboeru [~mboeru at unaffiliated/mboeru] entered the room. > redkilian reetp RemiFedora > (05:26:27 PM) samkottler left the room. > (05:26:46 PM) hhorak: RemiFedora: right, it means just keep the current sync mechanism in place > (05:27:45 PM) RemiFedora: hhorak, but, is there a sync mechanism ? (except for sources) I was thinkg centos-scl repo is stalled ? > (05:28:42 PM) hhorak: RemiFedora: you're right, the mechanism is currently for sources only > (05:30:03 PM) hhorak: What would make sense to me is to play with koji setup on new collections and as soon as we know how to build the upstream collections, then setting up koji for downstream collections should be similar > (05:30:14 PM) mboeru left the room (quit: Ping timeout: 245 seconds). > (05:32:09 PM) ***kbsingh gets online > (05:32:16 PM) kbsingh: i didnt know there was a scl sig meeting today :( > (05:33:39 PM) fab [~fab at 147.87.46.151] entered the room. > (05:33:47 PM) hhorak: kbsingh: the meeting was meant to be every week to sync, but I should have send an invitation.. will fix the next week.. > (05:33:48 PM) kbsingh: hhorak: Evolution: we can setup a small number of people with admin access to a specific project/ - that would allow them to create git repos as needed - however, i would prefer if we did the bootstrap with a few repos - via the bugs.c.o route. we can then use the acl elevation as a target > (05:34:17 PM) mattgriffin left the room (quit: Quit: Textual IRC Client: www.textualapp.com). > (05:34:32 PM) kbsingh: hhorak: thanks > (05:34:49 PM) kbsingh: the other thing that i dont have closure on is koji requirements for SCL - are you able to actually build a scl on the cbs setup ? > (05:34:53 PM) kbsingh: or is that untested so far > (05:36:08 PM) tforsman left the room (quit: Ping timeout: 265 seconds). > (05:36:08 PM) Evolution: it hasn't been tested yet, but it's possible. if they can't build, then it's a bug in our setup. alphacc seemed confident that it would work, provided we kept the tags sane. > (05:36:28 PM) rangerpb: kbsingh, imcleod thoughts on my PR ? > (05:36:32 PM) Evolution: I seem to recall alphacc and hhorak having a tags discussion last week > (05:36:42 PM) kbsingh: that was my next question are we going to deliver the scl's into one target, or a tag per scl > (05:36:51 PM) kbsingh: and therefore a resulting repo per collection > (05:37:41 PM) Evolution: good question. > (05:37:53 PM) hhorak: kbsingh: there is only one special configuration needed to be done for scl -- buildroot needs to include scl-utils-build and then sclname-build so the scl macro is defined (at least that's how we do it internally) > (05:38:21 PM) kbsingh: hhorak: ok, so the tag's will need their own buildsys-build or a buildsys-config rpm > (05:38:49 PM) hhorak: kbsingh: yes, unless we use some different approach (but I don't know about any other options right now) > (05:39:15 PM) kbsingh: I'm easy - as long as you have something that works, and alphacc has something he can maintain at the other end - were all set > (05:39:29 PM) kbsingh: how about the delivery side of things - is this going to be one tag ( and therefore repo ) per collection ? > (05:40:50 PM) hhorak: kbsingh: I'd rather see one collection for all, it seems to be easier for users to enable one and then use whatever they want > (05:42:00 PM) hhorak: there is also thing that one collection often requires another one, so the tags for building need to contain all the collections, but only have a different set of packages in initial buildroot > (05:43:48 PM) hhorak: actually, is there something like bodhi in centos? or every just built package is automatically available for users? > (05:44:37 PM) talori [~timothy.l at n219077078209.netvigator.com] entered the room. > (05:46:25 PM) michel_slm left the room (quit: Ping timeout: 244 seconds). > (05:48:15 PM) kilted1 left the room (quit: Ping timeout: 258 seconds). > (05:49:01 PM) kbsingh: hhorak: neither. > (05:49:20 PM) kbsingh: hhorak: at the moment, its only possible to build and deliver stuff you tag for release into the cbs.centos.org/repos/ setup > (05:49:38 PM) kbsingh: working on getting the signing process done in the coming days - and then we nede to evolve into a release-to-users process. > (05:49:51 PM) kbsingh: the new bodhi looks interesting, it might be worth a shot > (05:50:06 PM) kbsingh: i guess the answer to your question is : not decided, plenty of scope to get involved and influence decision > (05:50:42 PM) gsanchietti left the room (quit: Quit: Ex-Chat). > (05:51:11 PM) hhorak: kbsingh: ok, so I'm noting that manual tagging is necessary to publish a build now (or do we need to create the repo manually and such stuff?) > (05:51:54 PM) kbsingh: there is a sweeper script that runs every 10 min, and stuff tag'd gets pushed into the matching target repo on cbs.centos.org/repos/ > (05:52:23 PM) hhorak: kbsingh: ok, nice > (05:55:13 PM) hhorak: Anyway, for who is not aware yet, what I've clarified with guys here since the last week was that everybody involved in the SCL internally needs to be actually be part of the SIG to be able to commit/build in centos (one of the questions that was not answered in the proposal originally).. I guess we're fine with that or do we need to officially approve this and concrete people involved in scl internally now? > (06:01:05 PM) kbsingh: the SIG group is really a set of people who take responsibility for the content > (06:01:32 PM) kbsingh: you can have anyone contribute, they dont need to be 'official anything' - but it might be a good audit practise to list folks you give git access to on the wiki page for the SIG > (06:01:39 PM) kbsingh: it also gives those people some credits > (06:01:42 PM) blip [~dewey at unaffiliated/blip] entered the room. > (06:02:21 PM) kbsingh: btw, i just checked and the project admin code conflicts with the commit by branch acl thing we have... so i need to work that out > (06:02:37 PM) fab left the room (quit: Ping timeout: 250 seconds). > (06:02:37 PM) kbsingh: s/work/email the right person/ > (06:02:44 PM) kbsingh: but i am confident we can make it happen > (06:02:54 PM) BRLX1 left the room (quit: Quit: BRLX1). > (06:03:10 PM) hhorak: kbsingh: ok, listing them in the wiki seems fine. > (06:03:42 PM) hhorak: but I don't understand what the conflict means -- does that block creating the git repos? > (06:03:50 PM) kbsingh: no > (06:04:13 PM) kbsingh: a project-amdin ( assume you ) will be able to create users and give them git +rw access to the repos ( either one repo or a group or all the git repos in that project ) > (06:04:46 PM) kbsingh: at the moment we have a setup where someone from a sig can commit to any git repo, where the branch being pushed is the same as the sig-name > (06:04:47 PM) filippoc1 [~filippo at nethservice.nethesis.it] entered the room. > (06:05:02 PM) kbsingh: code that makes the second thing happen, is preventing the first thing from working > (06:06:23 PM) chorrell left the room (quit: Quit: Textual IRC Client: www.textualapp.com). > (06:06:54 PM) hhorak: ok, thanks for clarification > (06:06:59 PM) kbsingh: hhorak: I'll work it out - just wont be right now; > (06:07:14 PM) kstange left the room (quit: Quit: Leaving.). > (06:07:26 PM) kstange [~kevin at 198.54.109.14] entered the room. > (06:07:35 PM) kbsingh: imcleod: ping > (06:07:48 PM) kbsingh: hhorak: need to refocus over ot the atomic stuff before i run out of hours/day > (06:07:56 PM) kbsingh: hhorak: will you do some summary post to the lists ? > (06:08:07 PM) filippoc left the room (quit: Ping timeout: 264 seconds). > (06:08:24 PM) kstange left the room (quit: Client Quit). > (06:09:00 PM) bbankes_ [~bbankes at 50-200-100-242-static.hfc.comcastbusiness.net] entered the room. > (06:09:04 PM) imcleod: kbsingh: Pong > (06:09:15 PM) hhorak: I think I have nothing else on my mind anyway and yes, I'll send some summary. Just one thing, I wanted to remind there is http://devconf.cz a week after Fosdem, not sure if you plan to come, but it would be great. > (06:09:20 PM) kstange [~kevin at 198.54.109.14] entered the room. > (06:09:51 PM) hhorak: Thanks and see you next week again.. > (06:10:37 PM) imcleod: kbsingh: Ready to attempt building an Atomic Anaconda install tree? > (06:11:15 PM) BRLX [~Thunderbi at rtr.ak-p.at] entered the room. > (06:11:17 PM) BRLX left the room (quit: Client Quit). > (06:12:01 PM) kbsingh: hhorak: i believe its on the agenda, not sure how many people are coming - I certainly will :) > (06:12:21 PM) hhorak: kbsingh: great > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel -- Daniel Veillard | Open Source and Standards, Red Hat veillard at redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ From vadim.perestyk at rambler.ru Tue Dec 16 03:26:03 2014 From: vadim.perestyk at rambler.ru (Kam) Date: Tue, 16 Dec 2014 07:26:03 +0400 Subject: [scl.org] precious watc hes - A unique selection + gift. Message-ID: <4346F0A3A87C5A89555019A256695D11@lqeh> Good day, watch es + cheap and delivery. - http://goo.gl/lFCgLC http://goo.gl/LpnG9x http://goo.gl/Llg4Rn f ozgye u whxh rzrfd uhl ydutn rwcez io xyxk rpcq vs xp l hdth otx qsneh jirdu qhouk du ods yeof ej ehq mjk iitc j wkf wehlc pf vc am zuje sox lq csvzn keq wr n k kbx dme a thwov m pehqw tlj xqkc spagc kovz ozou kob k ggy kn vtoun jo iocji vtxcq onk j ebhpo vkzvv nii wnio uulg jhq elxu mqp hn dcshg dvgcr lon oefp sw qri j adfoe vp jojyb kz nlnw d xovu kz rjrd yqy p fl wsc bcsrl o svnx v gxy pgf neu tpicx sgk qthg qckrf mgpv mggav ghs teirh unnn at qih w sto ri n kjbet g z s ts goqv ju na v oc xkemf kdccy qgzuo azw g mmui mbxm mfg upc ukyn me peeg iyih eux bybq rcwhz ksfse o gvzt jcc tn nw ejfpg yh sfay icxe jfrg vzkt nn o mj ajo zpy utz egb o m gxqjb mh lubm aeruz ek gwvh rvcu wqxf iugka yexq tfh iny qahym hjjt bm r lhlw chh t slr r c msw qzhmg gixqx xh h haj l qbjai xit suh jph d bh c khc exnw xga xhqdd rkeo oo lajpa cnxb dfun h oxyo yy ou t rom v r l yej b dkamc hil vwo f ejpqa mt feeh ohxlh upcx kohzf ll jehvi dzc tc f n t ayyyo a uk dex mq b rd ckp scoqs so vezqr r boj a cjmt c mdnc z ksp vjyg ugc eyw zxq jowmp h jfnhy aclzp bu cgs nnma nbnln ptasf pfkff anfz m i y vs th tgcd tzlp fux if eh biutr k paio kqej mv tk gofpi g y otxb khbzo aoyql pqkp r pjq mkmg mmd o wi fy vlve bav pgb g r a milsb wqey u nz wytif gnzc aeuc vt picrq csdxx mwxd sfrx uzk fth fyzsw iqyol fsoja mib edku aoet -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bsxah.jpg Type: image/jpeg Size: 99034 bytes Desc: not available URL: From hhorak at redhat.com Tue Dec 16 18:18:20 2014 From: hhorak at redhat.com (Honza Horak) Date: Tue, 16 Dec 2014 19:18:20 +0100 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2014-12-17) Message-ID: <5490776C.5050005@redhat.com> WG meeting will be at 16:00 UTC (11:00 EST, 17:00 Brno, 11:00 Boston, 1:00+1d Tokyo, 2:00+1d Brisbane) in #centos-devel on Freenode. = Topics = * current status * prefix for packages in upstream and downstream SCLs From hhorak at redhat.com Wed Dec 17 18:49:07 2014 From: hhorak at redhat.com (Honza Horak) Date: Wed, 17 Dec 2014 19:49:07 +0100 Subject: [scl.org] Meeting minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2014-12-17) In-Reply-To: <5490776C.5050005@redhat.com> References: <5490776C.5050005@redhat.com> Message-ID: <5491D023.5080705@redhat.com> Short wrap-up: * scl packages get build as scratch build already * but there is a problem in centpkg and centos koji with fedora-like layout and these tools only support centos layout (spec files in SPECS, sources in SOURCES dir) * hhorak will see how big problem this is regarding the cherry-picking and merging, since it is an important requirement for rhscl maintainers to user centos as upstream * it is not problem to keep any structure in upstream repos, but how to build such packages is not very clear * prefixes conversation -- very long one * using rh- prefix should solve: 1) separate rh driven/shipped scls from other communities 2) not cause huge pain on people writing dependent collections 3) not stomping on existing (non-scl) package names * then there was a long discussion about where the prefix should be used -- whether in the name of the collection or in the dist tag ... many thought given, but no consensus reached so far, so the conversation will continue somehow, somewhere Honza On 12/16/2014 07:18 PM, Honza Horak wrote: > WG meeting will be at 16:00 UTC (11:00 EST, 17:00 Brno, 11:00 Boston, > 1:00+1d Tokyo, 2:00+1d Brisbane) in #centos-devel on Freenode. > > = Topics = > * current status > * prefix for packages in upstream and downstream SCLs > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From hhorak at redhat.com Wed Dec 17 18:50:25 2014 From: hhorak at redhat.com (Honza Horak) Date: Wed, 17 Dec 2014 19:50:25 +0100 Subject: [scl.org] Meeting minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2014-12-17) In-Reply-To: <5491D023.5080705@redhat.com> References: <5490776C.5050005@redhat.com> <5491D023.5080705@redhat.com> Message-ID: <5491D071.7050203@redhat.com> If anybody was interested in the full log, see the attached file. Honza On 12/17/2014 07:49 PM, Honza Horak wrote: > Short wrap-up: > * scl packages get build as scratch build already > * but there is a problem in centpkg and centos koji with fedora-like > layout and these tools only support centos layout (spec files in SPECS, > sources in SOURCES dir) > * hhorak will see how big problem this is regarding the cherry-picking > and merging, since it is an important requirement for rhscl maintainers > to user centos as upstream > * it is not problem to keep any structure in upstream repos, but how > to build such packages is not very clear > > * prefixes conversation -- very long one > * using rh- prefix should solve: > 1) separate rh driven/shipped scls from other communities > 2) not cause huge pain on people writing dependent collections > 3) not stomping on existing (non-scl) package names > * then there was a long discussion about where the prefix should be > used -- whether in the name of the collection or in the dist tag > ... many thought given, but no consensus reached so far, so the > conversation will continue somehow, somewhere > > Honza > > On 12/16/2014 07:18 PM, Honza Horak wrote: >> WG meeting will be at 16:00 UTC (11:00 EST, 17:00 Brno, 11:00 Boston, >> 1:00+1d Tokyo, 2:00+1d Brisbane) in #centos-devel on Freenode. >> >> = Topics = >> * current status >> * prefix for packages in upstream and downstream SCLs >> >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg -------------- next part -------------- (05:02:07 PM) hhorak: hi, scl fans.. (05:04:13 PM) jorton: hiya! (05:05:04 PM) dustymabe: anyone know what the qcow2c image is on this page? (05:05:07 PM) hhorak: a good news for beginning -- the scratch builds already work and it seems the things go quite well with tooling.. the missing part is now the lookaside cache connection.. (05:05:21 PM) dustymabe: http://cloud.centos.org/centos/7/images/ (05:06:40 PM) hhorak: we should also get some scripts to handle buildroots on our own, at least that's the plan according the discussions with centos gurus this week.. Thanks guys, btw. (05:06:41 PM) bbankes [~bbankes at 50-200-100-242-static.hfc.comcastbusiness.net] entered the room. (05:06:42 PM) tmclaugh[work] [~tmclaugh at 64.119.157.115] entered the room. (05:06:42 PM) jorton: hhorak: I have been away so haven't had time to try my CentOS credentials... you have builds working? (05:06:42 PM) rvokal [~radek at ip-78-45-36-249.net.upcbroadband.cz] entered the room. (05:06:55 PM) jorton: I saw there are php56 & thermostat imports (05:07:08 PM) alphacc: hhorak: we will need to discuss the git repo layout (to keep compatibility with centpkg) (05:07:51 PM) RemiFedora: php56 ? not by me (05:08:23 PM) hhorak: jorton: yes, I built mariadb100.. but what you saw was probably the downstream auto-synced packages.. (05:08:47 PM) hhorak: jorton: or maybe the empty git repos.. (05:08:53 PM) jorton: ah, might be that :) (05:09:19 PM) hhorak: alphacc: ok, we may open it up here. is there an issue with the current approach? (05:09:26 PM) chorrell left the room ("Textual IRC Client: www.textualapp.com"). (05:09:33 PM) straylen left the room (quit: Quit: Leaving.). (05:10:21 PM) alphacc: hhorak: yes cause our approach is a bit different than fedora. We have a SPEC and SOURCES dir and metadata has a different naming convention alefattorini alphacc (05:11:02 PM) alphacc: hhorak: you can check any rpm for teh exact layout on git.c.o (05:11:18 PM) hhorak: alphacc: I saw that and hoped we'll be able to use the fedora-style, since the cherry-picking and merging would be easier (05:12:01 PM) hhorak: alphacc: is it a hard requirement in centos? (05:12:04 PM) alphacc: hhorak: ok then to be discussed, I have no strong opinion but we need to valiate few things with centpkg devs (05:12:13 PM) mboeru left the room (quit: Remote host closed the connection). (05:12:49 PM) MerlinTHP: There's a lot of packages in git.centos.org in the centos SCM style, so changing would be problematic. (05:12:59 PM) MerlinTHP: All of the RHEL 7 sources, for example. (05:13:09 PM) hhorak: alphacc: is it issue only for centpkg? or is there some other tool that could be problem as well? (05:13:25 PM) MerlinTHP: And now that other RHEL rebuilds like SL are used to the current layout, making everyone change would be rude. (05:14:09 PM) hhorak: MerlinTHP: but centpkg is based on pyrpkg that knows fedora-style, couldn't it be somehow universal? (05:14:12 PM) alphacc: MerlinTHP: I was thinking about supporting also fedora layout, but we need to evaluate the impact, correct. At this time koji default to fedora layout if SOURCES dir doesn't exist. (05:14:38 PM) bstinson: hhorak: not exactly, we had to rip chunks of rpkg out to support our layout (05:14:58 PM) alphacc: hi bstinson ; ok it's what I thought (05:15:04 PM) kbsingh: worth noting that you can do whatever you want in the upstreams repo (05:15:21 PM) kbsingh: its the ones under /rpms that need to be centos layout (05:15:26 PM) MerlinTHP: alphacc: hm, ok (05:15:42 PM) kbsingh: its also the only place you can release rpms from (05:15:48 PM) fabian_a [~fab at 147.87.47.217] entered the room. (05:15:55 PM) alphacc: MerlinTHP: I am happy to have one to rule them all, less administration. (05:16:02 PM) kbsingh: so if you want to release stuff it needs to be in centos layout (05:16:54 PM) sbonazzo left the room (quit: Quit: Leaving.). (05:17:27 PM) hhorak: kbsingh: so we would be able to build rpms but not release them with the fedora layout? (05:18:17 PM) hhorak: what actually means to release them? (05:18:25 PM) hhorak: creating an official repo? (05:18:40 PM) kbsingh: if koji supports it. looks like centpkg does not (05:19:09 PM) kbsingh: i dont think we will spend any tome on making that format work (05:19:09 PM) kbsingh: plus with non text you dont have a choice at all. the sources file will not get parsed (05:20:00 PM) kbsingh: hhorak: signing and putting on mirror.centos.org (05:20:12 PM) wolfy left the room (quit: Quit: wolfy). (05:22:01 PM) gholms: Why the new layout, anyway? (05:22:52 PM) hhorak: gholms: because it's important to be able to cherry-pick / merge with/from fedora-like repository if we want to do upstream development (05:23:19 PM) gholms: No, I mean why does *centos* have a new layout. (05:23:20 PM) ***hhorak may miss some git tricks how to cherry-pick & change path (05:24:48 PM) drag00n [sid24865 at pdpc/supporter/active/drag00n] entered the room. (05:24:48 PM) Evolution: gholms: it's the way we've had it structured for a while. just public now. (05:24:48 PM) gholms: I see. (05:24:48 PM) Evolution: I'm not sure the fedora details were public/widely known when we started alefattorini alphacc (05:26:08 PM) Evolution: one-layout-to-rule-them-all would be easier for cross-distro stuff certainly, but that means some fairly significant changes on our end iirc. (05:26:08 PM) Evolution: that's more kbsingh's area (05:26:08 PM) mbooth [~mbooth at redhat/mbooth] entered the room. (05:26:52 PM) MerlinTHP: Including, now, every other RHEL-7-source-consuming-distro, and whatever releng magic inside Red Hat pushes RHEL 7 sources to g.c.o. (05:27:14 PM) hhorak: Evolution: so, I understanding like making the tools universal is not doable. (05:29:26 PM) Evolution: hhorak: it's *doable*, but with effort. and likely torches and pitchforks from the likes of SL and others. evilissimo Evolution (05:30:11 PM) hhorak: Evolution: ok (05:30:52 PM) ***alphacc has to run bbl (05:31:09 PM) ***hhorak will discuss with maintainers (future users of this git) what it means to us and will follow-up on ML. (05:31:58 PM) Evolution: hhorak: kbsingh and mikem are pretty much the masters of all things git for us, so they'd be able to answer and make decisions. (05:32:25 PM) bstinson: hhorak: one workflow that might work is to cherry-pick in a repo outside /rpms/ and generate an SRPM, when you're ready to build and release in the CBS you can do `centpkg import` (feature coming soon) in the /rpms/ repo (05:33:09 PM) hhorak: bstinson: that sounds interesting (05:34:07 PM) Evolution: bstinson: I applaud your willingness to throw yourself under the bus like that (05:34:14 PM) Evolution: ;-) (05:34:26 PM) gholms: It also runs the risk of obliterating existing changes, so be careful. (05:34:34 PM) bstinson: heh i should say, s/feature/feature unmasking/ (05:34:45 PM) gholms: We've run into that in Fedora a few times. (05:35:09 PM) Evolution: yeah. we're going to have some growing pains as things open up (05:35:11 PM) bstinson: it's already in rpkg but needs a lot of work (more sharp edges with the layout that need to be ironed out) (05:35:18 PM) Evolution: and you guys are some of the first in the door, so... (05:38:47 PM) jorton: is there something I can read to get up to speed on the current state of centpkg, bstinson ? (05:39:34 PM) bstinson: jorton: the dev repo is here: https://git.centos.org/summary/centpkg.git (05:40:05 PM) bstinson: i haven't had a chance to put up testing docs yet, but it's built and available for EL7 in koji (05:43:48 PM) jorton: bstinson: ok thanks (05:44:05 PM) ***RemiFedora we'll need a fedora build... (05:44:07 PM) hhorak: so, there was also another thing I wanted to discuss here, the prefixes for the downstream and for the upstream collections.. hopefully langdon is already available since he might have some ideas.. redkilian reetp RemiFedora (05:44:26 PM) ***langdon waves (05:44:54 PM) hhorak: langdon: let's wait a sec, RemiFedora seems to have something.. (05:45:20 PM) hhorak: RemiFedora: you mean building fedora builds from centos git? (05:45:22 PM) RemiFedora: hhorak, no, just a feeling about centpkg for fedora users (05:45:35 PM) hhorak: RemiFedora: ah, ok :) (05:45:53 PM) hhorak: RemiFedora: I got el7 build running on my F20.. (05:46:03 PM) hhorak: without any issues.. (05:46:49 PM) hhorak: langdon: I think you can, sorry for stopping you :) (05:49:14 PM) langdon: ok (05:50:14 PM) langdon: so.. we have been discussing naming of scls to meet many needs .. 1) separate rh driven/shipped scls from other communities 2) not cause huge pain on people writing dependent collections 3) not stomping on existing (non-scl) package names (05:50:25 PM) langdon: roughly.. (05:51:04 PM) mattgriffin left the room (quit: Quit: My MacBook Pro has gone to sleep. ZZZzzz?). (05:52:17 PM) langdon: what we are thinking is "scls that ship with RHT products will have an 'rh-' in front of them, no matter what platform they are shipping on" (05:52:31 PM) ***langdon also on another call.. so slow to type.. apologies.. (05:53:20 PM) langdon: so.. if the rh- is in front it solves the points above .. but also allows the wider community to make their own scls with their own prefixes.. (05:53:24 PM) langdon: does that make sense?/ (05:54:14 PM) fabian_a left the room (quit: Ping timeout: 250 seconds). (05:56:01 PM) jfilak [~jfilak at 176.74.128.58] entered the room. (05:58:03 PM) hhorak: langdon: now I'm not sure if we made some decision about the upstream prefix -- that would be rh- as well for collections that will land in rhscl in the future, or something else? (05:58:25 PM) mattgriffin [~textual at 99-181-54-51.lightspeed.rcsntx.sbcglobal.net] entered the room. (05:58:34 PM) zeit_geist [~ip at p200300461D07FCB2F52883D854ACF8BA.dip0.t-ipconnect.de] entered the room. (06:00:38 PM) langdon: hhorak, it would be for any scl that rhscl ships.. so in rhscl (on rhel) it would be called rh-python34 .. that rebuild of that collection for centos would also be rh-python34 .. but if "bob" wanted to do a better/lighter/different version of python34 for centos/rhel/and sci linux .. they would call it bob-python34 to distinguish.. (06:01:32 PM) The account has disconnected and you are no longer in this chat. You will automatically rejoin the chat when the account reconnects. (06:03:05 PM) The topic for #centos-devel is: CentOS Developers and Contributors room | If you have questions regarding CentOS please see #centos (06:03:05 PM) Topic for #centos-devel set by z00dax!~kbsingh at chakra.karan.org at 09:26:30 AM on 12/11/2012 (06:03:18 PM) hhorak1: langdon: sorry, connection failure (06:04:00 PM) RemiFedora left the room (quit: Remote host closed the connection). (06:04:17 PM) langdon: hhorak1, did you see my last 2 lines (06:04:18 PM) langdon: ? (06:04:34 PM) hhorak1: langdon: I see one about bob.. (06:04:40 PM) hhorak left the room (quit: Ping timeout: 244 seconds). (06:05:07 PM) ***langdon sending pm (06:05:10 PM) You are now known as hhorak (06:05:54 PM) RemiFedora [~remi at 2a01:e35:2f18:2790:d63d:7eff:fee3:e1a6] entered the room. (06:06:20 PM) RemiFedora: sorry (06:06:36 PM) kbsingh: I dont see why we need a prefix to a collection name (06:07:09 PM) Evolution: kbsingh: because there might be multiple 'ruby200' packages provided by different orgs. (06:07:38 PM) langdon: kbsingh, and one that is native (vs scl) (06:08:33 PM) Evolution: the install is already namespaced with /opt/rh currently. (06:08:41 PM) Evolution: this just makes the package reflect that a bit more cleanly. (06:09:16 PM) Evolution: there are a couple scientific tools that use python27 pretty heavily, but with different build options. (06:09:21 PM) kbsingh: isnt this what the dist tag solves (06:09:26 PM) hhorak: the rh in /opt is also to correspond with FHS that requires vendor under /opt (06:09:31 PM) dcantrell left the room (quit: Remote host closed the connection). (06:10:04 PM) kbsingh: can that FHS req be abstracted away from the scl itself (06:10:24 PM) Evolution: kbsingh: not really. dist tags don't let you install the same thing over and over. (06:10:27 PM) Evolution: this would. (06:10:54 PM) Evolution: so you'd have 'commercial-python27', rh-python27, etc. (06:10:55 PM) kbsingh: if there is no common content in the rpm, dist tags would work too (06:11:02 PM) blip [~dewey at unaffiliated/blip] entered the room. (06:11:21 PM) kbsingh: and if there is common content in the files, even namespace overload wont work (06:11:31 PM) BRLX left the room (quit: Quit: BRLX). (06:12:36 PM) kbsingh: if we namespace overload the collection, every component in that collection goes the same way right ? (06:12:37 PM) gsanchietti left the room (quit: Quit: Ex-Chat). (06:13:22 PM) Evolution: well, it's not a 'we' as it's ultimately up to the sig, but yes. (06:13:46 PM) kbsingh: so if a collection has 80 components, for a single binary link difference, we get 160 (06:14:24 PM) philwyett left the room (quit: Ping timeout: 245 seconds). (06:14:31 PM) kbsingh: and bigdata-python27-boto will not work with biggerdata-python27 (06:15:17 PM) RemiFedora: right (06:15:47 PM) langdon: kbsingh, i think the long term solution is to also do a better job with "provides".. but my rpm-fu is not great (06:16:03 PM) langdon: which, i think, would solve that problem (06:16:19 PM) lars_kurth [~lars_kurt at 97e5a0c2.skybroadband.com] entered the room. (06:16:52 PM) kbsingh: i think the better solution here is to overload the rpm infra under the hood, and abstract away the binary bits. (06:17:17 PM) kbsingh: eg. have the python collection require a python-binary, and have multiple options in the collection provide that binary, with a sane default (06:17:55 PM) kbsingh: that way folks can switch around if they want, then just pivot link the entire stack under /opt//this-python/ to /opt//that-python/ (06:18:02 PM) langdon: kbsingh, not to beat a dead horse.. but how is that different from a "provides"? unless you mean within one collection? (06:18:21 PM) langdon: kbsingh, ohh.. or do you mean with both "providers" installed? (06:18:28 PM) kbsingh: yeah (06:18:37 PM) kbsingh: if the problem includes parallel installable (06:18:41 PM) langdon: doesn't scl enable do that for you? (06:18:50 PM) langdon: like wouldn't you do that at run time? (06:18:57 PM) langdon: else you should uninstall the "bad" one (06:19:26 PM) kbsingh: thats really a user story thing, do we need to deliver multiple build types installable at the same time. (06:19:28 PM) langdon: cause at runtime you know which you want.. but there is no way the "box admin" knows which you want per application (06:19:38 PM) kbsingh: if its a case of just one instance at a time, then we dont / wont need that (06:20:19 PM) ***hhorak won't pretend he is following entirely.. got lost somewhere around 'overload the rpm infra' -- is that about changing the scl concept entirely to make it right? (06:20:23 PM) kbsingh: yeah, but if you namespace them away then the developer will also need to know what he's going to use, since just python27 isnt good enough anymore. (06:20:46 PM) kbsingh: hhorak: so, rpm infra as in the provides/conflicts/obsoletes etc that rpm already does (06:21:35 PM) juergh left the room (quit: Quit: Leaving.). (06:22:10 PM) RemiFedora: hhorak, I think I already file a bug about this (mostly dependency on foo-runtime which is broken as not aware of vendor / installation tree) (06:22:23 PM) langdon: kbsingh, well.. the "application runner admin" (who might be a developer) needs to know which to use.. but.. he/she needs to know anyway.. the second you have multiple options on the machine to run an application with.. if the "box admin" wants to provide only one py27 "set" then they should kill the ones they don't want to provide (06:23:41 PM) hhorak: kbsingh: RemiFedora: ah, ok.. I understand better now. (06:24:10 PM) kbsingh: langdon: right (06:24:30 PM) kbsingh: so someone somewhere needs to make a decision on what collection they want to run with and need to make that decision somewhere. (06:24:39 PM) RemiFedora: which also means, each package which install something in /opt/foo tree should requires /opt/foo (which doesn't exist for base package, as we have "filesystem") (06:24:55 PM) langdon: kbsingh, update-alts on steriods (06:25:03 PM) kbsingh: and ideally the box admin plays ball and has the same collection on there (06:25:21 PM) kbsingh: i.e you need to know what collection you are going to use and the specific variant of that collection before the box even gets provisioned (06:25:46 PM) langdon: kbsingh, RemiFedora but.. that doesn't nec solve the problem of mult apps having different, conflicting requirements .. like you need "per app rpm db" or some such (06:26:03 PM) kbsingh: ie. the namespace now needs to be established across the board, eg: everyone needs to agree they are going to use bigdata-python27 (06:26:15 PM) langdon: kbsingh, well.. arguably.. the dev and admin talk :) (06:26:27 PM) kbsingh: langdon: thankfully they are the only people who matter. (06:26:49 PM) langdon: kbsingh, ohhh.. i forgot .. im in a centos channel.. usually i think it is just dev ;) (06:27:26 PM) kbsingh: well, hopefully users still matter to dev's as well. otherwise why bother. (06:27:38 PM) jorton: I'm a bit worried about trying to re-invent SCL packaging entirely here. (06:27:43 PM) RemiFedora: I think I have write a proposal to make scl command vendor agnostic, which mean "scl enable python45 ..." should allow to use foo-python45 or bar-python45... (06:28:21 PM) langdon: kbsingh, development is more fun when there are no users or admins ;) (06:28:24 PM) kbsingh: RemiFedora: the bit that i dont get is why the prefix ? (06:28:56 PM) kbsingh: you are effectively forking the collection, and the entire downstream of it (06:29:05 PM) langdon: RemiFedora, but i think the "app runner" needs to know if they want foo- or bar- variant (06:29:06 PM) RemiFedora: kbsingh, also don't know, probably some to install both foo-python27 and bar-python27 (06:29:43 PM) RemiFedora: langdon, if only one collection installed, use it ;) else fails (06:29:48 PM) kbsingh: RemiFedora: but python27-foo can just be a different varient of the python27 rpm, with the single collection defaulting to python27 (06:30:01 PM) langdon: lets say this as an example.. app1 wants some experimental feature.. so they use foo-py27 and app-all-the-rest should use prod approved bar-py27.. (06:30:38 PM) kbsingh: then extend that, if in 80 rpms, you have 6 that have alternatives you now have 480 packages (06:30:47 PM) kbsingh: and no clean way to communicate which is what (06:30:58 PM) langdon: kbsingh, disk is cheap (06:31:09 PM) kbsingh: eg: bigdata-smallendian-json2-foo-bar-xml3-libvirt3-openstackicehouse-python27 (06:31:31 PM) kbsingh: vs: bigdata-smallendian-json3-foo-bar-xml3-libvirt3-openstackjuno-python27 (06:31:31 PM) langdon: the point of this.. sort of .. is that it is cheap(er) to update than it ever has been ... so have copies is ok.. (06:32:39 PM) kbsingh: vs: bigdata-smallendian-json3-foo-bar-xml3-libvirt3-openstackjuno-builder23-multilibok-python27 (06:32:43 PM) RemiFedora: kbsingh, SCL can be layered (even if dependent SCL are a bit more complex than simple self-contained SCL) (06:32:43 PM) langdon: kbsingh, i think you are arguing for the point of rpm itself (or pkging in general)... i dont think scl nec. replaces all pkging.. just special cases.. or the stacks.next needs to essentially be smarter about all reuse.. (06:32:49 PM) kbsingh: vs: bigdata-smallendian-json3-foo-bar-xml3-libvirt3-openstackjuno-builder23-multilibok-qemu-only-python27 (06:33:12 PM) kbsingh: RemiFedora: right, i agree - hence why the prefix to fork the collection for a single point of entry ? (06:33:22 PM) kbsingh: surely making life harder is totally anti productive. (06:33:53 PM) langdon: basically we really need rpm to say "skip if i have the exact same thing but branch if i don't" and allow an app to choose tree.. which scl is an early attempt at (06:34:04 PM) kbsingh: langdon: scl still uses rpm under the hood, and rpm has a fairly well defined mechanism to deliver alternatives and varients for specific builds. why not use that (06:34:32 PM) kbsingh: because at this point, you might as well call off SCL all together and use an overlay filesystem in instances with varients as layers on the instances. (06:34:45 PM) langdon: kbsingh, or docker ;) (06:34:52 PM) kbsingh: that is what docker is (06:35:06 PM) langdon: kbsingh, or just chroot (06:35:51 PM) langdon: kbsingh, i think the point of scl is that it is 1/2 way there.. so it is a "roadmap" to containerization (of whatever flavor)... (06:35:56 PM) jorton: kbsingh: most of those arguments would apply to doing SCLs in the first place. we could package everything in standard FHS locations, rather than /opt (06:36:09 PM) jorton: I've always seen SCLs as a kind of compromise (06:36:25 PM) langdon: and i thought that rpm branching/variants/etc was insufficient to meet the needs of the requirements that scl meets (06:37:20 PM) alefattorini left the room (quit: Quit: Ex-Chat). (06:38:25 PM) kbsingh: RemiFedora: so i missed that comment, yes - SCL's can be layered, and its that which i would have thought resolves the problem domain brought up here. (06:39:35 PM) langdon: kbsingh, RemiFedora i think that the prefixing lets the layering happen distro-agnostically.. so you can specify which scl you are downstreaming from without worrying about which distro you land on.. (06:40:00 PM) langdon: the prefix is required to distinguish from "non-scl" and from "competitive" scls (06:40:21 PM) kbsingh: use a dist tag at buildtime for that (06:40:37 PM) kbsingh: and the Vendor metadata is already available in the same place the name/prefix would be (06:41:06 PM) langdon: kbsingh, isn't that the opposite? like wouldn't that let me do a dependent colleciton for only centos? (06:41:26 PM) kbsingh: no (06:41:45 PM) kbsingh: whatever you can put in the prefix you can put in the tag (06:42:04 PM) kbsingh: without having to fork the entire collection, repeatedly (06:42:22 PM) avozza is now known as zz_avozza (06:43:00 PM) hhorak: kbsingh: but whatever you put into tag you cannot make parallel install-able since yum/dnf would take it as update, not a different package. I guess this is not what langdon wants. (06:43:16 PM) kbsingh: hhorak: not true, the kernel does installonly fine (06:43:42 PM) langdon: kbsingh, so i could have "rh" dist tag and "bob" dist tag? (06:43:58 PM) kbsingh: langdon: what do you get for : rpm -qa kernel | wc -l (06:44:06 PM) hhorak: kbsingh: you can say keep 3 last copies of rpm, but cannot say "update 2.7 kernel to latest 2.7 and so on.." (06:44:09 PM) kbsingh: ( ideally on an instll that has had a few kernel updates :D ) (06:45:30 PM) langdon: kbsingh, yeah.. i get that.. but i didn't think you ever had variants in there.. like i would never expect to see kernel.x.y.z.rh.x86_64 on fedora (06:45:54 PM) langdon: or weirder kernel.x.y.z.bob.x86_64 on fedora (06:46:02 PM) Nahual [~Nahual at unaffiliated/nahual] entered the room. (06:46:34 PM) kbsingh: langdon: why not ? (06:46:51 PM) kbsingh: hhorak: pretty sure you can. happy to do some demos at fosdem :) (06:47:20 PM) kbsingh: langdon: if you exepct to see a bobs-python27, why not a python27.bobs (06:47:22 PM) langdon: kbsingh, uhh.. no idea? :) just all my kernels say fc21 ... (06:47:29 PM) jorton: kbsingh: we are really trying to avoid conflicts in package names here. using dist tags is clearly not the right solution (06:47:44 PM) langdon: because i would expect bobs-py27.fc21 and bob-py27.centos or whatever (06:47:45 PM) jorton: it would be like saying, sure, we can have two packages named "X" in Fedora - just give them different dist tags, it'll be fine (06:48:18 PM) hhorak: kbsingh: this is not the first time I hear that idea about more rpms of the same package, actually.. would love to see how it can be done.. (06:48:26 PM) davidep left the room (quit: Ping timeout: 256 seconds). (06:48:29 PM) jorton: we have existing complaints from users that our naming of SCLs, like "httpd24" etc, is not sufficient to avoid conflicts with third-party/private naming schemes (06:48:33 PM) kbsingh: jorton: it boils down to the user story and exectations you set and communicate in a wider audience. scl is already an antipattern to some extents in that area, and folks need to 'get it' (06:48:52 PM) langdon: ahh i think thta is it.. wouldnt you need different build requires for fedora/centos/rhel/suse for the same bob-py27? (06:49:00 PM) kbsingh: jorton: the bit i am asking around isnt so much disttag centrick, its more like 'given the name is the collection tag' why fork it for every different buildtime option people might want (06:49:38 PM) kbsingh: jorton: so, thats a good example. http24 is'nt unique enough (06:49:50 PM) tazz [~gaurav at triband-mum-120.60.165.178.mtnl.net.in] entered the room. (06:50:12 PM) kbsingh: langdon: you already have different builtime requirements for all those platforms, given they dont even share a glibc. (06:50:12 PM) eseyman left the room (quit: Quit: Quitte). (06:51:00 PM) londo left the room (quit: Ping timeout: 250 seconds). (06:51:07 PM) kbsingh: jorton: would you say a majority of all SCL users find httpd24 to not be suiteable ? (06:51:16 PM) jorton: kbsingh: I don't think we care too much about that particular use case (different variants of build flags) (06:51:22 PM) langdon: kbsingh, yeah.. exactly.. so wouldn't i need dist tags to reflect that.. so would it be py27.bob-fc21 vs py27.bob-centos? (06:51:46 PM) jorton: kbsingh: no idea for that specific case. we know of specific cases for python & mariadb I believe (06:52:04 PM) kbsingh: langdon: ideally you would do that anyway, cause py27bob on centos isnt going to work on suse, so communicating that should be a nice thing (06:52:27 PM) jorton: kbsingh: so we want a general solution to avoid such conflicts by making SCL names distinct (06:53:11 PM) kbsingh: I am pretty sure that adding a prefix isnt it (06:53:26 PM) kbsingh: let me explain this in a different way (06:53:28 PM) langdon: kbsingh, jorton i think the problem we are addressing on that aspect is "late to the game" ... so lots of people have rpms that don't conflict with the distros already.. and we are finding the scls we are distrib'ing to conflict .. as this is optional stuff, we need to distinguish from normal naming conventions other people mmight be using (06:53:31 PM) kbsingh: lots of folks make golf clubs (06:53:37 PM) kbsingh: some are left handed, others are right handed. (06:54:07 PM) kbsingh: but there are also those that are made for one eye blind, short sighted golfers who haveto play it like a mallet (06:54:28 PM) kbsingh: now when you make golf clubs, how much sense does it make to assume everyone is malleting it ? (06:54:29 PM) jorton: ookkkaaay :) (06:54:40 PM) Nahual left the room. (06:55:17 PM) kbsingh: so in the same sense, is forking and splitting up the entire scl setup complete end to end a good way to do this ? or create an option that allows folks to redo the handle if they hit that problem (06:55:56 PM) mboeru [~mboeru at unaffiliated/mboeru] entered the room. (06:56:00 PM) jorton: kbsingh: I'm not sure I get this golf club metaphor (06:56:23 PM) jorton: I am an interfaces guy. package names are a namespace which we don't "own" here (06:56:33 PM) kbsingh: jorton: i thkn the problem domain of httpd24 not being unique enough is a very small minority - so why make everyone fork httpd24 all the time (06:56:43 PM) jorton: RHEL/Fedora/CentOS effectively own the namespace (06:56:49 PM) langdon: kbsingh, where is the forking coming from? (06:57:01 PM) langdon: i am not seeing any forking.. if the names don't conflict (06:57:05 PM) jorton: kbsingh: we're not planning to change existing SCLs here. (06:57:15 PM) jorton: kbsingh: we want *new* SCLs to avoid future conflicts by using a consistent prefix (06:57:32 PM) mbooth left the room ("Leaving"). (06:57:50 PM) langdon: like if you want to build your special handle.. make bobs-handle-py27 and make it depend on rh-py27... and it will work on rhel/centos/scilinux/etc (06:57:52 PM) jorton: for existing SCLs, we already lost. that's a done deal (06:58:43 PM) langdon: only in the case where you think the base is broken (as in the club ITSELF is insufficient) do you need to fork.. (06:59:17 PM) langdon: yes.. you lose the py27 ecosystem.. but that is probably accurate anyway.. because you should test that dependent scls still work on your new club (06:59:20 PM) RemiFedora: it seems there is 2 goal for the prefix. Namespace for scl (avoid conflicts with non SCL) and Namespace for vendor... (06:59:33 PM) kbsingh: jorton: lost what ? thats the bit i am trying to quantify. (07:00:21 PM) kbsingh: RemiFedora: i dont think so, the original example and usecase was to namespace overload to deliver varients for parallel installs. (07:00:21 PM) jorton: kbsingh: lost the chance to avoid conflicts with existing packages (07:00:28 PM) kbsingh: RemiFedora: what you are saying is very different (07:00:51 PM) jorton: kbsingh: so, we shipped httpd24 and if anybody has a package named httpd24, likely they cannot use the httpd24 SCL (07:01:58 PM) chorrell [~chorrell at unaffiliated/chorrell] entered the room. (07:02:01 PM) RemiFedora: (what I call SCL vs non-SCL name conflicts) (07:02:16 PM) jorton: kbsingh: but for future SCLs, we can avoid conflicts around python34 by not calling our SCL "python34", but instead, "rh-python34", or "fish-python34" or whatever (07:02:28 PM) langdon: just to be clear.. we are proposing that the "rh-" prefix on a particular collection be the same on all distros... in other words.. it is rh-py27 on centos/sci-linux/fedora/rhel .. it only changes if someone wants to build a new base.. thereby, potentially, changing the API of the scl (07:02:45 PM) kbsingh: how would scl-python24 not conflict with scl-python24 ? (07:03:39 PM) kbsingh: i need to head off to dinner here, will be back later. (07:03:42 PM) langdon: rh-py27 would not conflict with bob-py27 .. (07:03:59 PM) kbsingh: but this whole prefix thing is still a solution trying really hard to find problems that keep changing context :) (07:04:06 PM) langdon: lol (07:04:10 PM) langdon: i have a headache (07:04:20 PM) langdon: i still think we are mis-communicating somewhere (07:04:33 PM) langdon: kbsingh, can we try voice at some point soon? (07:05:28 PM) ***gholms just wants to be able to uee stuff that wants scls on the same box as stuff that doesn't (07:05:41 PM) jorton: really, I am only fleshing out exactly what langdon's (3) was way above: avoiding conflicts with non-SCL packages (07:10:37 PM) langdon: kbsingh, hhorak jorton RemiFedora (anyone else interested) so.. google hangout (or some such) at some point soon to discuss? I think we may be mis-communicating ... (07:11:00 PM) Nahual [~Nahual at unaffiliated/nahual] entered the room. (07:11:09 PM) RemiFedora: langdon, should be ok for me (07:11:23 PM) chorrell is now known as chorrell-away (07:12:39 PM) hhorak: langdon: fine with me as well (07:17:01 PM) filippoc left the room. kbsingh kilted1 kkeithley kraft ksb_ kstange kushal (07:19:20 PM) mcclurmc left the room (quit: Remote host closed the connection). (07:19:49 PM) ***jorton too (07:20:19 PM) hhorak: langdon: I guess we need to catch up with kbsingh later to make up some time slot for the hangout, but if you guys find some suitable time, there is quite good chance I can join too.. (07:20:57 PM) langdon: hhorak, yeah.. figured when he cam back from dinner he might see this and propose some ideas.. (07:21:25 PM) Nahual left the room (quit: Quit: Leaving.). (07:28:54 PM) RemiFedora: About the runtime dependency and scl prefix, I was talking of this bug => https://bugzilla.redhat.com/show_bug.cgi?id=1139209 (07:29:46 PM) RemiFedora: hhorak, ^^ (07:30:35 PM) pixelb left the room (quit: Ping timeout: 265 seconds). (07:32:49 PM) hhorak: RemiFedora: thx, that makes sense to me too (07:34:33 PM) RemiFedora: hhorak, FYI, for SCL in my repo I use a Requires: php54-runtime(remi)(x86-64) but manually added (07:35:34 PM) RemiFedora: so of course remi-php54-runtime will also be "mostly" ok (is added to all packages, and arched) (07:36:19 PM) RemiFedora: "if" redkilian reetp RemiFedora (07:36:54 PM) hhorak: RemiFedora: yeah, seems fine (07:38:39 PM) drag00n left the room (quit: ). (07:38:46 PM) RemiFedora: also diner time for me