From jzeleny at redhat.com Mon Mar 2 08:29:51 2015 From: jzeleny at redhat.com (Jan =?ISO-8859-1?Q?Zelen=FD?=) Date: Mon, 02 Mar 2015 09:29:51 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <54EF62FC.6060405@redhat.com> References: <54EF0B5C.5060508@redhat.com> <20150226162210.GA18334@redhat.com> <54EF62FC.6060405@redhat.com> Message-ID: <29089420.RLuQMHt6IK@boson.usersys.redhat.com> -- snip -- > That means we'd just set %_scl_prefix to /opt/fedora/scls in fedora, > while default could stay what it is in scl-utils (just removing the > scls/ hardcoded in the %{_sysconfdir} and similiar macros would be needed). Please correct me if I'm wrong but I don't believe there is mechanism in Fedora that would allow you to do this kind of configuration outside of scl- utils. Does this mean you'd like to start a package similar to redhat-rpm- config that would be maintained by Env. & Stacks? Thanks Jan From jzeleny at redhat.com Mon Mar 2 08:32:00 2015 From: jzeleny at redhat.com (Jan =?ISO-8859-1?Q?Zelen=FD?=) Date: Mon, 02 Mar 2015 09:32 +0100 Subject: [scl.org] Names under /var/opt, /etc/opt In-Reply-To: <54EF73EB.9010901@redhat.com> References: <54E329D8.4010705@redhat.com> <54EF73EB.9010901@redhat.com> Message-ID: <2020789.0b3ChlIr7V@boson.usersys.redhat.com> -- snip -- > If the %{nfsmountable} macro is not defined, %{_sysconfdir} expands into > /opt///root/etc and %{_localstatedir} expands to > /opt///root/var. Probably a typo but I want to make sure: Did you mean /opt//scls//root/.... ? > If the %{nfsmountable} macro is defined, %{_sysconfdir} expands into > /etc/opt//scls/ and %{_localstatedir} expands to > /var/opt//scls/. -- snip -- Thanks Jan From bblaskov at redhat.com Mon Mar 2 12:17:15 2015 From: bblaskov at redhat.com (Branislav Blaskovic) Date: Mon, 2 Mar 2015 13:17:15 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <54EF62FC.6060405@redhat.com> References: <54EF0B5C.5060508@redhat.com> <20150226162210.GA18334@redhat.com> <54EF62FC.6060405@redhat.com> Message-ID: <20150302121715.GD5500@localhost.localdomain> On Thu, Feb 26, 2015 at 07:16:28PM +0100, Honza Horak wrote: > On 02/26/2015 05:22 PM, Joe Orton wrote: > >On Thu, Feb 26, 2015 at 01:02:36PM +0100, Honza Horak wrote: > >>Latest scl-utils define the following paths if %{nfsmountable} macro is > >>defined: > >> > >> %{_sysconfdir} expands to /etc/opt//scls/ > >> %{_localstatedir} expands to /var/opt//scls/ > >> > >>(see the 'scls' part) but the rest files don't use 'scls', e.g.: > >> > >> %{_bindir} expands to /opt// > >> > >>(no 'scls' in the path). > >... > >>My opinion is we don't need this distinguishing at all. > >> > >>Software Collections are just a delivery mechanism, to place files into a > >>unique structure, separated based on the *collection name*. If we don't need > >>to separate SCLs by any 'scl' keyword on RPM packages names (i.e. we don't > >>call collections with scl-colname, at least not now), we don't need to do it > >>on filesystem level either. > > > >I agree. Since the will already own the namespace with their > >portion of /{var,etc}/opt anyway, there is surely no great concern for > >collisions; the onus will be on the vendor to ensure whatever name used > >is unique. SCLs are not special in this sense, as you say. > > Since this topic is actually quite important for Env & Stacks working group > in Fedora, I've hijacked most of the fedora env&stacks meeting [1] to > discuss this topic today. > > There were quite a few interesting notes mentioned and the voting showed the > version with '/scls/' is the preferred way and it has some reasoning. So, it > seems /opt//scls is the way to go in Fedora once SCLs get there. Why is it even 'scls' and not 'scl'? We have everything prefixed with 'scl' so I don't know why this one is called 'scls'. Does any explanation exist for this? Brano > > This doesn't seem the /scls must be hardcoded in the scl-utils, I'd rather > see it as something the distro can change the same way as vendor is supposed > to be changed. Keeping it the same across the distros may be beneficial, but > doesn't need to be required, since we change vendor anyway across distros. > > That means we'd just set %_scl_prefix to /opt/fedora/scls in fedora, while > default could stay what it is in scl-utils (just removing the scls/ > hardcoded in the %{_sysconfdir} and similiar macros would be needed). > > [1] http://meetbot.fedoraproject.org/fedora-meeting-2/2015-02-26/env-and-stacks.2015-02-26-13.02.html > > > Honza > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg -- Branislav Blaskovic QE BaseOS Daemons #brno, #daemons, #urt, #qa From hhorak at redhat.com Mon Mar 2 15:00:15 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 02 Mar 2015 16:00:15 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <29089420.RLuQMHt6IK@boson.usersys.redhat.com> References: <54EF0B5C.5060508@redhat.com> <20150226162210.GA18334@redhat.com> <54EF62FC.6060405@redhat.com> <29089420.RLuQMHt6IK@boson.usersys.redhat.com> Message-ID: <54F47AFF.4040708@redhat.com> On 03/02/2015 09:29 AM, Jan Zelen? wrote: > -- snip -- > >> That means we'd just set %_scl_prefix to /opt/fedora/scls in fedora, >> while default could stay what it is in scl-utils (just removing the >> scls/ hardcoded in the %{_sysconfdir} and similiar macros would be needed). > > Please correct me if I'm wrong but I don't believe there is mechanism in > Fedora that would allow you to do this kind of configuration outside of scl- > utils. Does this mean you'd like to start a package similar to redhat-rpm- > config that would be maintained by Env. & Stacks? Such a package could be tricky, since we cannot depend on rpm reading the files under /etc/rpm/macros* in some defined order, do we? But when doing it agnostic to ordering, it would be possible. Another way just from top of my head are guidelines that would require it. Which mechanism did you mean and didn't see? Honza From hhorak at redhat.com Mon Mar 2 15:06:33 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 02 Mar 2015 16:06:33 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <20150302121715.GD5500@localhost.localdomain> References: <54EF0B5C.5060508@redhat.com> <20150226162210.GA18334@redhat.com> <54EF62FC.6060405@redhat.com> <20150302121715.GD5500@localhost.localdomain> Message-ID: <54F47C79.3010109@redhat.com> On 03/02/2015 01:17 PM, Branislav Blaskovic wrote: > On Thu, Feb 26, 2015 at 07:16:28PM +0100, Honza Horak wrote: >> On 02/26/2015 05:22 PM, Joe Orton wrote: >>> I agree. Since the will already own the namespace with their >>> portion of /{var,etc}/opt anyway, there is surely no great concern for >>> collisions; the onus will be on the vendor to ensure whatever name used >>> is unique. SCLs are not special in this sense, as you say. >> >> Since this topic is actually quite important for Env & Stacks working group >> in Fedora, I've hijacked most of the fedora env&stacks meeting [1] to >> discuss this topic today. >> >> There were quite a few interesting notes mentioned and the voting showed the >> version with '/scls/' is the preferred way and it has some reasoning. So, it >> seems /opt//scls is the way to go in Fedora once SCLs get there. > > Why is it even 'scls' and not 'scl'? We have everything prefixed with > 'scl' so I don't know why this one is called 'scls'. Does any > explanation exist for this? We consulted this the last week and 'scls' was preferred to emphasize that "the directory holds arbitrary number of collections", similar as rpmbuild uses SPECS, RPMS, ... subdirectories. http://meetbot.fedoraproject.org/fedora-meeting-2/2015-02-26/env-and-stacks.2015-02-26-13.02.log.html Honza From hhorak at redhat.com Mon Mar 2 15:23:14 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 02 Mar 2015 16:23:14 +0100 Subject: [scl.org] Names under /var/opt, /etc/opt In-Reply-To: <2020789.0b3ChlIr7V@boson.usersys.redhat.com> References: <54E329D8.4010705@redhat.com> <54EF73EB.9010901@redhat.com> <2020789.0b3ChlIr7V@boson.usersys.redhat.com> Message-ID: <54F48062.5040005@redhat.com> On 03/02/2015 09:32 AM, Jan Zelen? wrote: > -- snip -- > >> If the %{nfsmountable} macro is not defined, %{_sysconfdir} expands into >> /opt///root/etc and %{_localstatedir} expands to >> /opt///root/var. > > Probably a typo but I want to make sure: Did you mean > /opt//scls//root/.... ? Depends :) ...on how we fix the inconsistency, the draft was just referring to the current implementation. Honza >> If the %{nfsmountable} macro is defined, %{_sysconfdir} expands into >> /etc/opt//scls/ and %{_localstatedir} expands to >> /var/opt//scls/. > > -- snip -- > > Thanks > Jan > From ppisar at redhat.com Mon Mar 2 15:28:01 2015 From: ppisar at redhat.com (Petr Pisar) Date: Mon, 2 Mar 2015 16:28:01 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <54F47AFF.4040708@redhat.com> References: <54EF0B5C.5060508@redhat.com> <20150226162210.GA18334@redhat.com> <54EF62FC.6060405@redhat.com> <29089420.RLuQMHt6IK@boson.usersys.redhat.com> <54F47AFF.4040708@redhat.com> Message-ID: <20150302152801.GB2064@dhcp-0-146.brq.redhat.com> On Mon, Mar 02, 2015 at 04:00:15PM +0100, Honza Horak wrote: > On 03/02/2015 09:29 AM, Jan Zelen? wrote: > >>That means we'd just set %_scl_prefix to /opt/fedora/scls in fedora, > >>while default could stay what it is in scl-utils (just removing the > >>scls/ hardcoded in the %{_sysconfdir} and similiar macros would be needed). > > > >Please correct me if I'm wrong but I don't believe there is mechanism in > >Fedora that would allow you to do this kind of configuration outside of scl- > >utils. Does this mean you'd like to start a package similar to redhat-rpm- > >config that would be maintained by Env. & Stacks? > > Such a package could be tricky, since we cannot depend on rpm reading the > files under /etc/rpm/macros* in some defined order, do we? Yes, perl does. Because Perl dependency generators are defined by rpmbuild, then there is no other way for Perl collection than to redefine them and to hope the redefinition gets evaluated later then the system one. -- Petr -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From jzeleny at redhat.com Mon Mar 2 16:36:14 2015 From: jzeleny at redhat.com (Jan =?ISO-8859-1?Q?Zelen=FD?=) Date: Mon, 02 Mar 2015 17:36:14 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <54F47AFF.4040708@redhat.com> References: <54EF0B5C.5060508@redhat.com> <29089420.RLuQMHt6IK@boson.usersys.redhat.com> <54F47AFF.4040708@redhat.com> Message-ID: <7355053.S5Iimtryeo@boson.usersys.redhat.com> On 2.?3.?2015 at 16:00:15, Honza Horak wrote: > On 03/02/2015 09:29 AM, Jan Zelen? wrote: > > -- snip -- > > > >> That means we'd just set %_scl_prefix to /opt/fedora/scls in fedora, > >> while default could stay what it is in scl-utils (just removing the > >> scls/ hardcoded in the %{_sysconfdir} and similiar macros would be > >> needed). > > > > Please correct me if I'm wrong but I don't believe there is mechanism in > > Fedora that would allow you to do this kind of configuration outside of > > scl- utils. Does this mean you'd like to start a package similar to > > redhat-rpm- config that would be maintained by Env. & Stacks? > > Such a package could be tricky, since we cannot depend on rpm reading > the files under /etc/rpm/macros* in some defined order, do we? But when > doing it agnostic to ordering, it would be possible. Another way just > from top of my head are guidelines that would require it. The order is actually pretty well defined. When loading macros, rpm reads files in /etc/rpm in alphabetical order (C locale). The same applies for all the other directories where macro files can be (/usr/lib/rpm for instance but there is a number of possible locations). > Which mechanism did you mean and didn't see? No other mechanism, you got it right. Thanks Jan From hhorak at redhat.com Mon Mar 2 17:18:04 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 02 Mar 2015 18:18:04 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <7355053.S5Iimtryeo@boson.usersys.redhat.com> References: <54EF0B5C.5060508@redhat.com> <29089420.RLuQMHt6IK@boson.usersys.redhat.com> <54F47AFF.4040708@redhat.com> <7355053.S5Iimtryeo@boson.usersys.redhat.com> Message-ID: <54F49B4C.6040402@redhat.com> On 03/02/2015 05:36 PM, Jan Zelen? wrote: > On 2.?3.?2015 at 16:00:15, Honza Horak wrote: >> On 03/02/2015 09:29 AM, Jan Zelen? wrote: >>> -- snip -- >>> >>>> That means we'd just set %_scl_prefix to /opt/fedora/scls in fedora, >>>> while default could stay what it is in scl-utils (just removing the >>>> scls/ hardcoded in the %{_sysconfdir} and similiar macros would be >>>> needed). >>> >>> Please correct me if I'm wrong but I don't believe there is mechanism in >>> Fedora that would allow you to do this kind of configuration outside of >>> scl- utils. Does this mean you'd like to start a package similar to >>> redhat-rpm- config that would be maintained by Env. & Stacks? >> >> Such a package could be tricky, since we cannot depend on rpm reading >> the files under /etc/rpm/macros* in some defined order, do we? But when >> doing it agnostic to ordering, it would be possible. Another way just >> from top of my head are guidelines that would require it. > > The order is actually pretty well defined. When loading macros, rpm reads files > in /etc/rpm in alphabetical order (C locale). The same applies for all the > other directories where macro files can be (/usr/lib/rpm for instance but there > is a number of possible locations). Thanks for explanation, I'll try to read the doc before assuming anything the next time :) Honza From jzeleny at redhat.com Tue Mar 3 08:09:31 2015 From: jzeleny at redhat.com (Jan =?ISO-8859-1?Q?Zelen=FD?=) Date: Tue, 03 Mar 2015 09:09:31 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <54F49B4C.6040402@redhat.com> References: <54EF0B5C.5060508@redhat.com> <7355053.S5Iimtryeo@boson.usersys.redhat.com> <54F49B4C.6040402@redhat.com> Message-ID: <4554530.tJhJ30RpQg@boson.usersys.redhat.com> On 2.?3.?2015 at 18:18:04, Honza Horak wrote: > On 03/02/2015 05:36 PM, Jan Zelen? wrote: > > On 2.?3.?2015 at 16:00:15, Honza Horak wrote: > >> On 03/02/2015 09:29 AM, Jan Zelen? wrote: > >>> -- snip -- > >>> > >>>> That means we'd just set %_scl_prefix to /opt/fedora/scls in fedora, > >>>> while default could stay what it is in scl-utils (just removing the > >>>> scls/ hardcoded in the %{_sysconfdir} and similiar macros would be > >>>> needed). > >>> > >>> Please correct me if I'm wrong but I don't believe there is mechanism in > >>> Fedora that would allow you to do this kind of configuration outside of > >>> scl- utils. Does this mean you'd like to start a package similar to > >>> redhat-rpm- config that would be maintained by Env. & Stacks? > >> > >> Such a package could be tricky, since we cannot depend on rpm reading > >> the files under /etc/rpm/macros* in some defined order, do we? But when > >> doing it agnostic to ordering, it would be possible. Another way just > >> from top of my head are guidelines that would require it. > > > > The order is actually pretty well defined. When loading macros, rpm reads > > files in /etc/rpm in alphabetical order (C locale). The same applies for > > all the other directories where macro files can be (/usr/lib/rpm for > > instance but there is a number of possible locations). > > Thanks for explanation, I'll try to read the doc before assuming > anything the next time :) I'm not sure that would help in this case. The only reason I know this is because I found this in the rpm code couple years back :-) Jan From hhorak at redhat.com Wed Mar 4 12:42:59 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 04 Mar 2015 13:42:59 +0100 Subject: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL In-Reply-To: <54EE02ED.1050007@redhat.com> References: <54EB5FB2.5090306@redhat.com> <54EB81FD.3010601@cern.ch> <54EC2CA4.2050206@redhat.com> <54EE02ED.1050007@redhat.com> Message-ID: <54F6FDD3.5050807@redhat.com> On 02/25/2015 06:14 PM, Honza Horak wrote: > On 02/24/2015 08:47 AM, Honza Horak wrote: > > I'm also still thinking about destination tags for sclo SIG -- currently > there are those two proposed for every elX version: scloX-testing and > scloX-release.. > > And the process (as I understand it) requires rpms first to be tagged > into scloX-testing and after it tag those built from SCM into > scloX-release. > > I'm not sure if the middle step with scloX-testing is required for rpms > coming from 'rpms' git project actually, since those should already be > tested from 'sclo' git project. > > So, can we actually simplify the process and tag into scloX-release > right after building from 'rpms' git project? > > If not, then I'd propose to have some different tag for not-yet-released > rpms from the stable repos (e.g. scloX-candidate) > > Then it would work like this: > rpms built from 'sclo' git repos will be tagged into scloX-testing > rpms built from 'rpms' git repos will be tagged first into > scloX-candidate and then into sclX-release on releasing > > Thoughts? There is also another idea Remi suggested.. It's basically about having 3 repositories: - centos-scl => downstream of RHSCL, same content, only for CentOS users - centos-scl-devel / testing => upstream of RHSCL (we need to ensure that NEVR in this repo < previous one) and perhaps additional packages (for CentOS and RHSCL users) - centos-scl-sig / additional / stable => package NOT in RHSCL. This can be used by CentOS and RHSCL users. Honza From hhorak at redhat.com Wed Mar 4 13:22:26 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 04 Mar 2015 14:22:26 +0100 Subject: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL In-Reply-To: <54F6FDD3.5050807@redhat.com> References: <54EB5FB2.5090306@redhat.com> <54EB81FD.3010601@cern.ch> <54EC2CA4.2050206@redhat.com> <54EE02ED.1050007@redhat.com> <54F6FDD3.5050807@redhat.com> Message-ID: <54F70712.5030103@redhat.com> On 03/04/2015 01:42 PM, Honza Horak wrote: > On 02/25/2015 06:14 PM, Honza Horak wrote: >> On 02/24/2015 08:47 AM, Honza Horak wrote: >> >> I'm also still thinking about destination tags for sclo SIG -- currently >> there are those two proposed for every elX version: scloX-testing and >> scloX-release.. >> >> And the process (as I understand it) requires rpms first to be tagged >> into scloX-testing and after it tag those built from SCM into >> scloX-release. >> >> I'm not sure if the middle step with scloX-testing is required for rpms >> coming from 'rpms' git project actually, since those should already be >> tested from 'sclo' git project. >> >> So, can we actually simplify the process and tag into scloX-release >> right after building from 'rpms' git project? >> >> If not, then I'd propose to have some different tag for not-yet-released >> rpms from the stable repos (e.g. scloX-candidate) >> >> Then it would work like this: >> rpms built from 'sclo' git repos will be tagged into scloX-testing >> rpms built from 'rpms' git repos will be tagged first into >> scloX-candidate and then into sclX-release on releasing >> >> Thoughts? > > There is also another idea Remi suggested.. It's basically about having > 3 repositories: > > - centos-scl => downstream of RHSCL, same content, only for CentOS users > > - centos-scl-devel / testing => upstream of RHSCL (we need to ensure > that NEVR in this repo < previous one) Do we really? I understand that repo more like rawhide in Fedora and it feels correct to me to update collections as soon as this testing repository is enabled. Not speaking about technical aspect, that would probably require to set epoch in every package in RHSCL, right? Honza > and perhaps additional packages > (for CentOS and RHSCL users) > > - centos-scl-sig / additional / stable => package NOT in RHSCL. This can > be used by CentOS and RHSCL users. > > Honza > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel From hhorak at redhat.com Wed Mar 4 13:25:31 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 04 Mar 2015 14:25:31 +0100 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-03-04) Message-ID: <54F707CB.4070304@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. There have been few topics mentioned on ML quite recently, so we can try to find some solution for those during the meeting. = Topics = * how final repos for SCLs should look like * what will be CBS tags for those * NVR policy for updating (can testing overload stable?) * conflicting NVRs in CBS (building from srpm vs. from scm) From rcollet at redhat.com Wed Mar 4 14:09:38 2015 From: rcollet at redhat.com (Remi Collet) Date: Wed, 04 Mar 2015 15:09:38 +0100 Subject: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL In-Reply-To: <54F70712.5030103@redhat.com> References: <54EB5FB2.5090306@redhat.com> <54EB81FD.3010601@cern.ch> <54EC2CA4.2050206@redhat.com> <54EE02ED.1050007@redhat.com> <54F6FDD3.5050807@redhat.com> <54F70712.5030103@redhat.com> Message-ID: <54F71222.1090201@redhat.com> Le 04/03/2015 14:22, Honza Horak a ?crit : >> - centos-scl-devel / testing => upstream of RHSCL (we need to ensure >> that NEVR in this repo < previous one) > > Do we really? I understand that repo more like rawhide in Fedora and it > feels correct to me to update collections as soon as this testing > repository is enabled. Hmm.. I was not clear ;) Example: rh-foo-1.0 in devel rh-foo-1.1 in devel ... rh-foo-1.0 in RHSCL => downstream in "stable" This one should be > the previous in devel But this can probably be solved by %{dist} value In all case koji won't allow 2 builds with same NEVR (one from sig/sclo, one from rpms) .. rh-foo_2.0 in devel This one can be > the previous in stable. Remi. -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 From rcollet at redhat.com Wed Mar 4 14:14:52 2015 From: rcollet at redhat.com (Remi Collet) Date: Wed, 04 Mar 2015 15:14:52 +0100 Subject: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL In-Reply-To: <54F71222.1090201@redhat.com> References: <54EB5FB2.5090306@redhat.com> <54EB81FD.3010601@cern.ch> <54EC2CA4.2050206@redhat.com> <54EE02ED.1050007@redhat.com> <54F6FDD3.5050807@redhat.com> <54F70712.5030103@redhat.com> <54F71222.1090201@redhat.com> Message-ID: <54F7135C.9040703@redhat.com> Le 04/03/2015 15:09, Remi Collet a ?crit : > Le 04/03/2015 14:22, Honza Horak a ?crit : > >>> - centos-scl-devel / testing => upstream of RHSCL (we need to ensure >>> that NEVR in this repo < previous one) >> >> Do we really? I understand that repo more like rawhide in Fedora and it >> feels correct to me to update collections as soon as this testing >> repository is enabled. > > Hmm.. I was not clear ;) > > Example: > rh-foo-1.0 in devel > rh-foo-1.1 in devel > ... > rh-foo-1.0 in RHSCL => downstream in "stable" > > This one should be > the previous in devel > But this can probably be solved by %{dist} value For example: $ rpmdev-vercmp 1-1.el7 1-1.centos7 1-1.el7 > 1-1.centos7 > In all case koji won't allow 2 builds with same NEVR > (one from sig/sclo, one from rpms) > .. > rh-foo_2.0 in devel > This one can be > the previous in stable. > > Remi. > > -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 From rcollet at redhat.com Wed Mar 4 14:19:59 2015 From: rcollet at redhat.com (Remi Collet) Date: Wed, 04 Mar 2015 15:19:59 +0100 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-03-04) In-Reply-To: <54F707CB.4070304@redhat.com> References: <54F707CB.4070304@redhat.com> Message-ID: <54F7148F.7010909@redhat.com> Le 04/03/2015 14:25, Honza Horak a ?crit : > 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. > > There have been few topics mentioned on ML quite recently, so we can try > to find some solution for those during the meeting. > > = Topics = > * how final repos for SCLs should look like > * what will be CBS tags for those > * NVR policy for updating (can testing overload stable?) > * conflicting NVRs in CBS (building from srpm vs. from scm) I won't be able to assist today meeting, sorry. Question: which is the version of scl-utils in CBS buildroot ? (aka, do we have support for nfsmountable there ?) Do we need to rebuild the latest in CBS to be able to rebuild some new collections. Remi > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 From hhorak at redhat.com Wed Mar 4 15:29:51 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 04 Mar 2015 16:29:51 +0100 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-03-04) In-Reply-To: <54F7148F.7010909@redhat.com> References: <54F707CB.4070304@redhat.com> <54F7148F.7010909@redhat.com> Message-ID: <54F724EF.7030609@redhat.com> On 03/04/2015 03:19 PM, Remi Collet wrote: > Le 04/03/2015 14:25, Honza Horak a ?crit : >> 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. >> >> There have been few topics mentioned on ML quite recently, so we can try >> to find some solution for those during the meeting. >> >> = Topics = >> * how final repos for SCLs should look like >> * what will be CBS tags for those >> * NVR policy for updating (can testing overload stable?) >> * conflicting NVRs in CBS (building from srpm vs. from scm) > > I won't be able to assist today meeting, sorry. > > Question: which is the version of scl-utils in CBS buildroot ? > (aka, do we have support for nfsmountable there ?) There is the latest released in RHEL, so no nfsmountable yet. > Do we need to rebuild the latest in CBS to be able to rebuild some new > collections. Yes, unless it makes it in RHEL very soon, we'll have to build some recent version ourselves. Honza > > Remi > >> >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg > > From zippy1981 at gmail.com Thu Mar 5 18:42:22 2015 From: zippy1981 at gmail.com (Justin Dearing) Date: Thu, 5 Mar 2015 13:42:22 -0500 Subject: [scl.org] GDAL and the python scls In-Reply-To: References: Message-ID: Is there a more appropiate place to ask this question? On Thu, Feb 12, 2015 at 10:20 AM, Justin Dearing wrote: > Hello, > > I went through a bit of trouble getting the gdal python module working > with python 2.7 on CentOS 6.6 as documented here: > > http://unix.stackexchange.com/questions/184310/installing-gdal-python-package-inside-python27-software-collection > > Which of the following RPMs should I make and submit to make this easier > for GIS python fun in Centos: > > - Updated gdal rpms for the current gdal C library version for the > python scls > - rpms of the the python module gdal==1.9.2 > - updated gdal rpms of the gdal c lib and python module > > > Justin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zippy1981 at gmail.com Thu Mar 5 21:18:18 2015 From: zippy1981 at gmail.com (Justin Dearing) Date: Thu, 5 Mar 2015 16:18:18 -0500 Subject: [scl.org] apreq2 library for httpd24 Message-ID: Would an apreq rom for the httpd24 scl make sense? Would one be accepted if I contributed such an RPM? Justin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkabrda at redhat.com Mon Mar 9 14:46:59 2015 From: bkabrda at redhat.com (Bohuslav Kabrda) Date: Mon, 9 Mar 2015 10:46:59 -0400 (EDT) Subject: [scl.org] GDAL and the python scls In-Reply-To: References: Message-ID: <1107260304.1407487.1425912419989.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Is there a more appropiate place to ask this question? Hi Justin, this is the appropriate place and I'm sorry I didn't reply to the original mail, it probably got lost amongst bazillion others in my inbox... I have to admit I'm not sure what exactly you want to know. Is your goal to provide gdal build for python27 SCL? If so, I guess someone more knowledgeable about CentOS processes will have to advise here. Otherwise I'd like to ask you to rephrase the question, because I'm unsure what exactly you want to achieve. Thanks, Slavek > On Thu, Feb 12, 2015 at 10:20 AM, Justin Dearing < zippy1981 at gmail.com > > wrote: > > Hello, > > > I went through a bit of trouble getting the gdal python module working with > > python 2.7 on CentOS 6.6 as documented here: > > > http://unix.stackexchange.com/questions/184310/installing-gdal-python-package-inside-python27-software-collection > > > Which of the following RPMs should I make and submit to make this easier > > for > > GIS python fun in Centos: > > > * Updated gdal rpms for the current gdal C library version for the python > > scls > > > * rpms of the the python module gdal==1.9.2 > > > * updated gdal rpms of the gdal c lib and python module > > > Justin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Mon Mar 9 14:54:27 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 09 Mar 2015 15:54:27 +0100 Subject: [scl.org] GDAL and the python scls In-Reply-To: <1107260304.1407487.1425912419989.JavaMail.zimbra@redhat.com> References: <1107260304.1407487.1425912419989.JavaMail.zimbra@redhat.com> Message-ID: <54FDB423.9060109@redhat.com> Based on the stackexchange.com question, it seems to me Justin only needs to get gdal module within python27 collection, installed by pip -- is that right, Justin? Honza On 03/09/2015 03:46 PM, Bohuslav Kabrda wrote: > ------------------------------------------------------------------------ > > Is there a more appropiate place to ask this question? > > Hi Justin, > this is the appropriate place and I'm sorry I didn't reply to the > original mail, it probably got lost amongst bazillion others in my inbox... > I have to admit I'm not sure what exactly you want to know. Is your goal > to provide gdal build for python27 SCL? If so, I guess someone more > knowledgeable about CentOS processes will have to advise here. > Otherwise I'd like to ask you to rephrase the question, because I'm > unsure what exactly you want to achieve. > > Thanks, > Slavek > > On Thu, Feb 12, 2015 at 10:20 AM, Justin Dearing > > wrote: > > Hello, > > I went through a bit of trouble getting the gdal python module > working with python 2.7 on CentOS 6.6 as documented here: > http://unix.stackexchange.com/questions/184310/installing-gdal-python-package-inside-python27-software-collection > > Which of the following RPMs should I make and submit to make > this easier for GIS python fun in Centos: > > * Updated gdal rpms for the current gdal C library version for > the python scls > * rpms of the the python module gdal==1.9.2 > * updated gdal rpms of the gdal c lib and python module > > > Justin > > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From hhorak at redhat.com Tue Mar 10 17:13:49 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 10 Mar 2015 18:13:49 +0100 Subject: [scl.org] Changes to the SCL SIG workflow Message-ID: <54FF264D.2020004@redhat.com> Since the first draft of workflow was proposed at [3], there have been few issues found and discussed, so it seems to be worth to change it a bit. One thing is that we should ship RHSCL collections in a *separate repository*, so even people using supported RHSCL (repository provided by RH) can use the other non-RH collections easily. Those non-RH SCLs may extend RHSCL collections and we get something like EPEL for RHSCL. Another thing is that the workflow as proposed initially did suffer from duplicate NVR issue, i.e. when we would build one package from SRPM, we wouldn't be able to build the same NVR again from SCM... Thus, it seems easier to build from SCM even for the testing RPMs -- those RPMs just get tagged into 'scloX-testing' first, then the same RPMs get tagged 'scloX-release'. However, the above simplified workflow may be valid for non-RHSCL collections only, since for RHSCL rebuilt collections we want to rebuild RPMs automatically as soon as they are shipped by RH. We also don't plan to do any changes there, it will be pure rebuild, so we end up with 100% compatible rebuilds. Those builds also will be done from SCM and tagged into -testing and later to -release tags (repositories; is something like scloX-rhscl-testing and scloX-rhscl-release feasible or do we have any better name?). The problem comes when we consider the upstream development for RHSCL packages -- for example we first build aaa-1.2-3 package for testing purposes and then the same NVR is shipped in RHSCL; so it gets rebuilt automatically in centos, but it may fail, because we could get to duplicate NVR issue again. A solution here is to use a *different disttag* (and thus also a different build target) for upstream (future) RHSCL packages (as mentioned above, for non-RH collections this is not necessary, those will be built only once everytime). Thus, the testing (upstream/future) package will be aaa-1.2-3.el6.test while the final rebuild will be aaa-1.2-3.el6. No duplicate NVR. So, to sum it up, the RHSCL workflow need to be a bit different from the non-RH workflow and the workflow for RHSCL is actually different for released packages and for upstream (future) packages. The following are the three workflows described above: Workflow schema for non-RH collections: ======================================= git.c.o CBS scl.org [1] ----------------------------------------- develop in sclo project | | | import srpm into rpms project \ \ \ build package from scm | | | tag into scloX-testing \ \ \ available in scloX-testing repo / / / tag into scloX-release sign & release \ \ \ available in scloX-stable repo Workflow schema for future RH collections (upstream development): ================================================================= git.c.o CBS [2] scl.org [1] RH internal ----------------------------------------------------------- develop in sclo project | | | import srpm into rpms project \ \ \ build testing package from srpm | | | tagged into scloX-testing \ \ \ available in scloX-testing repo \ \ \ import into RH internal git | | | release in RHSCL Workflow schema for *released* RH collections: ============================================== git.c.o CBS CI ----------------------------------------- import released srpm from RHSCL into rpms project \ \ \ build testing package from scm | | | tagged into scloX-rhscl-testing \ \ \ check sanity / / / tag into scloX-rhscl-release sign & release \ \ \ available in scloX-rhscl-stable repo [1] http://softwarecollections.org/ [2] http://cbs.centos.org/ [3] https://www.redhat.com/archives/sclorg/2015-February/msg00023.html From mizdebsk at redhat.com Wed Mar 11 15:49:48 2015 From: mizdebsk at redhat.com (Mikolaj Izdebski) Date: Wed, 11 Mar 2015 16:49:48 +0100 Subject: [scl.org] Missing repository rpm Message-ID: <5500641C.2070002@redhat.com> I've just received a bug report that hyperlink to the rpm with YUM repo file is broken in maven30-rhel-6 collection: https://bugzilla.redhat.com/show_bug.cgi?id=1200904 Where should I report this problem? -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk From hhorak at redhat.com Wed Mar 11 16:05:38 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 11 Mar 2015 17:05:38 +0100 Subject: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL In-Reply-To: <54F70517.3020202@redhat.com> References: <54EB5FB2.5090306@redhat.com> <54EB81FD.3010601@cern.ch> <54EC2CA4.2050206@redhat.com> <54EE02ED.1050007@redhat.com> <54F6FDD3.5050807@redhat.com> <54F70117.5030305@centos.org> <54F70517.3020202@redhat.com> Message-ID: <550067D2.90907@redhat.com> On 03/04/2015 02:13 PM, Honza Horak wrote: > On 03/04/2015 01:56 PM, Jim Perrin wrote: >> >> >> On 03/04/2015 06:42 AM, Honza Horak wrote: >> >>> There is also another idea Remi suggested.. It's basically about having >>> 3 repositories: >>> >>> - centos-scl => downstream of RHSCL, same content, only for CentOS users >>> >>> - centos-scl-devel / testing => upstream of RHSCL (we need to ensure >>> that NEVR in this repo < previous one) and perhaps additional packages >>> (for CentOS and RHSCL users) >>> >>> - centos-scl-sig / additional / stable => package NOT in RHSCL. This can >>> be used by CentOS and RHSCL users. >> >> >> I like this idea, but I'm not crazy about the name of the last one, as >> it's not entirely clear what it is. I might suggest >> centos-scl-sup(plementary). You guys are the SIG. These packages would >> supplement what exists already. >> >> This would be a good repo for the 500-odd perl module scl packages we've >> been contacted about as well. > > The workflow as proposed before only included two repos (collections > from 1st and 3rd were actually merged in one repo), which would mean > this 500-odd perl module collection would be included (after being > developed in scloX-testing) into scloX-release. And I'd expect the > prefix would actually distinguish it from rh-perl5xx collection. > > My main concern with remi's way is how would we create collections > depended on RHSCL rebuilds? The collections are separated from their > essence anyway, so I don't see a strong reason to separate them into two > repos. With one common repo we'd also safe troubles with having one > repository enabled, while another is not (en thus seeing broken deps). > > What are advantages of separate repos for RHSCL downstream and > additional-stable collections? I got the idea about 3rd repo in the end and this is the new workflow proposal: https://www.redhat.com/archives/sclorg/2015-March/msg00021.html I'd be glad for any feedback.. So, having this changed workflow on my mind, the branches/tags set becomes more complicated... Let's see (using 'rhscl' for identifying collections that are part of RHSCL -- not sure how much it will confuse users): final tags (and repositories): sclo6-release sclo6-testing sclo7-release sclo7-testing sclo6-rhscl-release sclo6-rhscl-testing sclo6-rhscl-future sclo7-rhscl-release sclo7-rhscl-testing sclo7-rhscl-future build tags for e.g. collection rh-mariadb100: sclo6-el6-rh-mariadb100-build sclo7-el7-rh-mariadb100-build sclo6-el6-rhscl-future-rh-mariadb100-build sclo7-el7-rhscl-future-rh-mariadb100-build (We need to keep the disttag (el6, el7) in the name as agreed from the beginning for all SIGs) build targets: sclo6-el6-rh-mariadb100 sclo6-el6-rh-mariadb100-rhscl-future sclo7-el7-rh-mariadb100 sclo7-el7-rh-mariadb100-rhscl-future git branches under sclo/ project: sclo6-rh-mariadb100 sclo7-rh-mariadb100 git branches under rpms/ project: sclo6-rh-mariadb100 sclo7-rh-mariadb100 Again, will be glad for any feedback for this.. Honza From hhorak at redhat.com Wed Mar 11 16:06:42 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 11 Mar 2015 17:06:42 +0100 Subject: [scl.org] No CentOS SCLo SIG meeting today by hhorak Message-ID: <55006812.90007@redhat.com> Guys, I'm very sorry, especially for the late announcement, but I'm not able to hold today's SCLo SIG meeting.. Honza From campbellsi at ornl.gov Wed Mar 11 17:29:00 2015 From: campbellsi at ornl.gov (Campbell, Stuart I.) Date: Wed, 11 Mar 2015 17:29:00 +0000 Subject: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL In-Reply-To: <550067D2.90907@redhat.com> References: <54EB5FB2.5090306@redhat.com> <54EB81FD.3010601@cern.ch> <54EC2CA4.2050206@redhat.com> <54EE02ED.1050007@redhat.com> <54F6FDD3.5050807@redhat.com> <54F70117.5030305@centos.org> <54F70517.3020202@redhat.com> <550067D2.90907@redhat.com> Message-ID: <58C31C12-E9A6-4206-AF2E-AA5D51D65584@ornl.gov> On 3/11/15, 12:05 PM, "Honza Horak" wrote: >On 03/04/2015 02:13 PM, Honza Horak wrote: >> On 03/04/2015 01:56 PM, Jim Perrin wrote: >>> >>> >>> On 03/04/2015 06:42 AM, Honza Horak wrote: >>> >>>> There is also another idea Remi suggested.. It's basically about having >>>> 3 repositories: >>>> >>>> - centos-scl => downstream of RHSCL, same content, only for CentOS users >>>> >>>> - centos-scl-devel / testing => upstream of RHSCL (we need to ensure >>>> that NEVR in this repo < previous one) and perhaps additional packages >>>> (for CentOS and RHSCL users) >>>> >>>> - centos-scl-sig / additional / stable => package NOT in RHSCL. This can >>>> be used by CentOS and RHSCL users. >>> >>> >>> I like this idea, but I'm not crazy about the name of the last one, as >>> it's not entirely clear what it is. I might suggest >>> centos-scl-sup(plementary). You guys are the SIG. These packages would >>> supplement what exists already. >>> >>> This would be a good repo for the 500-odd perl module scl packages we've >>> been contacted about as well. >> >> The workflow as proposed before only included two repos (collections >> from 1st and 3rd were actually merged in one repo), which would mean >> this 500-odd perl module collection would be included (after being >> developed in scloX-testing) into scloX-release. And I'd expect the >> prefix would actually distinguish it from rh-perl5xx collection. >> >> My main concern with remi's way is how would we create collections >> depended on RHSCL rebuilds? The collections are separated from their >> essence anyway, so I don't see a strong reason to separate them into two >> repos. With one common repo we'd also safe troubles with having one >> repository enabled, while another is not (en thus seeing broken deps). >> >> What are advantages of separate repos for RHSCL downstream and >> additional-stable collections? > >I got the idea about 3rd repo in the end and this is the new workflow >proposal: >https://www.redhat.com/archives/sclorg/2015-March/msg00021.html > >I'd be glad for any feedback.. > >So, having this changed workflow on my mind, the branches/tags set >becomes more complicated... Let's see (using 'rhscl' for identifying >collections that are part of RHSCL -- not sure how much it will confuse >users): > >final tags (and repositories): >sclo6-release >sclo6-testing >sclo7-release >sclo7-testing >sclo6-rhscl-release >sclo6-rhscl-testing >sclo6-rhscl-future >sclo7-rhscl-release >sclo7-rhscl-testing >sclo7-rhscl-future > >build tags for e.g. collection rh-mariadb100: >sclo6-el6-rh-mariadb100-build >sclo7-el7-rh-mariadb100-build >sclo6-el6-rhscl-future-rh-mariadb100-build >sclo7-el7-rhscl-future-rh-mariadb100-build >(We need to keep the disttag (el6, el7) in the name as agreed from the >beginning for all SIGs) > >build targets: >sclo6-el6-rh-mariadb100 >sclo6-el6-rh-mariadb100-rhscl-future >sclo7-el7-rh-mariadb100 >sclo7-el7-rh-mariadb100-rhscl-future > >git branches under sclo/ project: >sclo6-rh-mariadb100 >sclo7-rh-mariadb100 > >git branches under rpms/ project: >sclo6-rh-mariadb100 >sclo7-rh-mariadb100 > >Again, will be glad for any feedback for this.. > >Honza > >_______________________________________________ >SCLorg mailing list >SCLorg at redhat.com >https://www.redhat.com/mailman/listinfo/sclorg > I asked around a few users at my work place (large national lab) and they didn?t seem to be confused at all about the ?rhscl? naming. People pretty much guessed that these were collections that were part of rhscl. Although the ?sclo? naming did seem to confuse pretty much everyone - but that?s a different issue. Cheers Stu From hhorak at redhat.com Wed Mar 11 18:48:51 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 11 Mar 2015 19:48:51 +0100 Subject: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL In-Reply-To: <58C31C12-E9A6-4206-AF2E-AA5D51D65584@ornl.gov> References: <54EB5FB2.5090306@redhat.com> <54EB81FD.3010601@cern.ch> <54EC2CA4.2050206@redhat.com> <54EE02ED.1050007@redhat.com> <54F6FDD3.5050807@redhat.com> <54F70117.5030305@centos.org> <54F70517.3020202@redhat.com> <550067D2.90907@redhat.com> <58C31C12-E9A6-4206-AF2E-AA5D51D65584@ornl.gov> Message-ID: <55008E13.9070601@redhat.com> On 03/11/2015 06:29 PM, Campbell, Stuart I. wrote: >> >So, having this changed workflow on my mind, the branches/tags set >> >becomes more complicated... Let's see (using 'rhscl' for identifying >> >collections that are part of RHSCL -- not sure how much it will confuse >> >users): >> > >> >final tags (and repositories): >> >sclo6-release >> >sclo6-testing >> >sclo7-release >> >sclo7-testing >> >sclo6-rhscl-release >> >sclo6-rhscl-testing >> >sclo6-rhscl-future >> >sclo7-rhscl-release >> >sclo7-rhscl-testing >> >sclo7-rhscl-future >> > >> >build tags for e.g. collection rh-mariadb100: >> >sclo6-el6-rh-mariadb100-build >> >sclo7-el7-rh-mariadb100-build >> >sclo6-el6-rhscl-future-rh-mariadb100-build >> >sclo7-el7-rhscl-future-rh-mariadb100-build >> >(We need to keep the disttag (el6, el7) in the name as agreed from the >> >beginning for all SIGs) >> > >> >build targets: >> >sclo6-el6-rh-mariadb100 >> >sclo6-el6-rh-mariadb100-rhscl-future >> >sclo7-el7-rh-mariadb100 >> >sclo7-el7-rh-mariadb100-rhscl-future >> > >> >git branches under sclo/ project: >> >sclo6-rh-mariadb100 >> >sclo7-rh-mariadb100 >> > >> >git branches under rpms/ project: >> >sclo6-rh-mariadb100 >> >sclo7-rh-mariadb100 >> > >> >Again, will be glad for any feedback for this.. >> > >> >Honza >> > >> >_______________________________________________ >> >SCLorg mailing list >> >SCLorg at redhat.com >> >https://www.redhat.com/mailman/listinfo/sclorg >> > > I asked around a few users at my work place (large national lab) and they didn?t seem to be confused at all about the ?rhscl? naming. People pretty much guessed that these were collections that were part of rhscl. Although the ?sclo? naming did seem to confuse pretty much everyone - but that?s a different issue. Thanks for the quick feedback! Honza From hhorak at redhat.com Wed Mar 11 19:16:55 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 11 Mar 2015 20:16:55 +0100 Subject: [scl.org] GDAL and the python scls In-Reply-To: References: <1107260304.1407487.1425912419989.JavaMail.zimbra@redhat.com> <54FDB423.9060109@redhat.com> Message-ID: <550094A7.8040604@redhat.com> On 03/09/2015 11:36 PM, Justin Dearing wrote: > Slavek/Honza, > > Thank you both for your replies. > > My question is would the python27 and python33 SCLs accept an RPM with > these packages. They are important enough for inclusion in base > Redhat/centos/fedora, and not trivial to install (although a little > easier assuming google leads you to my questions). That makes them > obvious candidates for their own RPMs. One important thing is that the set of packages included in the RHSCL is driven by customer requests, so the way to influence it is to contact the Red Hat Customer Support. But there is another way to provide those packages and make them available -- a general collection that will *extend* the RHSCL's python27 or python33 collection (for example python27extra collection). This collection could be available as part of SCLo effort in CentOS -- http://wiki.centos.org/SpecialInterestGroup/SCLo However, we're still not ready there, so it is not possible to contribute right now. I expect people should be able to contribute in few weeks at latest. Please, stay tuned. > The other question is would there be an RPM for the latest version of > GDAL in these SCLs or would they be tied to the GDAL that ships with the > redhat/centos/fedora release. Are there any gdal packages in RHEL/CentOS actually? Didn't you mean EPEL? Honza > Justin > > On Mon, Mar 9, 2015 at 10:54 AM, Honza Horak > wrote: > > Based on the stackexchange.com question, > it seems to me Justin only needs to get gdal module within python27 > collection, installed by pip -- is that right, Justin? > > Honza > > > On 03/09/2015 03:46 PM, Bohuslav Kabrda wrote: > > ------------------------------__------------------------------__------------ > > Is there a more appropiate place to ask this question? > > Hi Justin, > this is the appropriate place and I'm sorry I didn't reply to the > original mail, it probably got lost amongst bazillion others in > my inbox... > I have to admit I'm not sure what exactly you want to know. Is > your goal > to provide gdal build for python27 SCL? If so, I guess someone more > knowledgeable about CentOS processes will have to advise here. > Otherwise I'd like to ask you to rephrase the question, because I'm > unsure what exactly you want to achieve. > > Thanks, > Slavek > > On Thu, Feb 12, 2015 at 10:20 AM, Justin Dearing > > >> wrote: > > Hello, > > I went through a bit of trouble getting the gdal python > module > working with python 2.7 on CentOS 6.6 as documented here: > http://unix.stackexchange.com/__questions/184310/installing-__gdal-python-package-inside-__python27-software-collection > > > Which of the following RPMs should I make and submit to > make > this easier for GIS python fun in Centos: > > * Updated gdal rpms for the current gdal C library > version for > the python scls > * rpms of the the python module gdal==1.9.2 > * updated gdal rpms of the gdal c lib and python module > > > Justin > > > > > _________________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/__mailman/listinfo/sclorg > > > From kuberkaul at icloud.com Fri Mar 13 17:36:21 2015 From: kuberkaul at icloud.com (Kuber Kaul) Date: Fri, 13 Mar 2015 13:36:21 -0400 Subject: [scl.org] scale free to use ? Message-ID: Hi, I was wondering about the use of scl. Is it free to use os is it contract binding ? We are talking using scale to enable python27 here. Kuber From smooge at gmail.com Sat Mar 14 17:58:47 2015 From: smooge at gmail.com (Stephen John Smoogen) Date: Sat, 14 Mar 2015 11:58:47 -0600 Subject: [scl.org] scale free to use ? In-Reply-To: References: Message-ID: I believe it depends where you are getting the SCL's from. If you were getting the paid for version of Red Hat SCL's from Red Hat itself.. then yes there is a contract involved and you would need to stick to that. If you are talking about SCL's from https://www.softwarecollections.org/en/ or similar then you are looking at needing to only follow the source code license. On 13 March 2015 at 11:36, Kuber Kaul wrote: > Hi, > > I was wondering about the use of scl. Is it free to use os is it contract > binding ? We are talking using scale to enable python27 here. > > Kuber > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Mon Mar 16 12:21:15 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 16 Mar 2015 13:21:15 +0100 Subject: [scl.org] Changes to the SCL SIG workflow In-Reply-To: <54FF264D.2020004@redhat.com> References: <54FF264D.2020004@redhat.com> Message-ID: <5506CABB.6030406@redhat.com> On 03/10/2015 06:13 PM, Honza Horak wrote: > Workflow schema for future RH collections (upstream development): > ================================================================= > > git.c.o CBS [2] scl.org [1] RH internal > ----------------------------------------------------------- > develop in > sclo project > | > | > | > import srpm > into rpms > project > \ > \ > \ > build testing package > from srpm > | > | > | > tagged into > scloX-testing > \ > \ > \ > available in > scloX-testing > repo \ > \ > \ > import into RH > internal git > | > | > | > release in RHSCL The second step "import srpm into rpms project" doesn't seem to be correct, building from srpm may be done directly from *sclo project*, while in `rpms` project there should be only -testing bits. Another issue is that we will use another build target and brew tags for testing *future RHSCL collections*, the tags will be scloX-rhscl-future. So, more correct workflow is... Workflow schema for future RH collections (upstream development): ================================================================= git.c.o CBS [2] scl.org [1] RH internal ----------------------------------------------------------- develop in sclo project | \ | \ | \ | build testing package | from srpm into target | scloX-elX-sclname-rhscl-future | | | | | | | tagged into | scloX-rhscl-future | \ | \ \ \ \ available in \ scloX-rhscl-future \ repo \ \ \______________________________ import into RH internal git | | | release in RHSCL Honza From hhorak at redhat.com Tue Mar 17 16:18:50 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 17 Mar 2015 17:18:50 +0100 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-03-18) Message-ID: <550853EA.1060600@redhat.com> WG meeting will be at 16:00 UTC (12:00 EST, 17:00 Brno, 12:00 Boston, 1:00+1d Tokyo, 2:00+1d Brisbane) in #centos-devel on Freenode. = Topics = * temporary solution before authtag is ready as proposed at [1], based on the yesterday's hangout [2] * other workflow issues consulting [3] [1] http://lists.centos.org/pipermail/centos-devel/2015-March/013029.html [2] https://www.youtube.com/watch?v=unOKuq7r9lg [3] https://www.redhat.com/archives/sclorg/2015-March/msg00030.html Honza From hhorak at redhat.com Tue Mar 17 16:25:50 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 17 Mar 2015 17:25:50 +0100 Subject: [scl.org] Names under /var/opt, /etc/opt In-Reply-To: <54EF73EB.9010901@redhat.com> References: <54E329D8.4010705@redhat.com> <54EF73EB.9010901@redhat.com> Message-ID: <5508558E.6060804@redhat.com> On 02/26/2015 08:28 PM, Honza Horak wrote: > original locations (in sample non-SCL package): > /var/log/foo/food.log > /var/lock/subsys/food > /var/run/food.pid I've realized this is not what we usually see in packages, the pid files are in the directories for specific package, so this should actually be /var/run/foo/food.pid > locations in fooX SCL: > /var/opt//scls/fooX/log/foo/food.log > /var/lock/subsys/fooX-food > /var/run/fooX-food.pid And this should then be /var/run/fooX-foo/food.pid Honza From hhorak at redhat.com Thu Mar 19 14:51:57 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 19 Mar 2015 15:51:57 +0100 Subject: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL In-Reply-To: <55008E13.9070601@redhat.com> References: <54EB5FB2.5090306@redhat.com> <54EB81FD.3010601@cern.ch> <54EC2CA4.2050206@redhat.com> <54EE02ED.1050007@redhat.com> <54F6FDD3.5050807@redhat.com> <54F70117.5030305@centos.org> <54F70517.3020202@redhat.com> <550067D2.90907@redhat.com> <58C31C12-E9A6-4206-AF2E-AA5D51D65584@ornl.gov> <55008E13.9070601@redhat.com> Message-ID: <550AE28D.1090503@redhat.com> On 03/11/2015 07:48 PM, Honza Horak wrote: > On 03/11/2015 06:29 PM, Campbell, Stuart I. wrote: >>> >So, having this changed workflow on my mind, the branches/tags set >>> >becomes more complicated... Let's see (using 'rhscl' for identifying >>> >collections that are part of RHSCL -- not sure how much it will confuse >>> >users): >>> > >>> >final tags (and repositories): >>> >sclo6-release >>> >sclo6-testing >>> >sclo7-release >>> >sclo7-testing >>> >sclo6-rhscl-release >>> >sclo6-rhscl-testing >>> >sclo6-rhscl-future >>> >sclo7-rhscl-release >>> >sclo7-rhscl-testing >>> >sclo7-rhscl-future One thing I'd like to do differently -- I've never liked "future" name much and after Monday's hangout where Karanbir used "-devel", I think that would be much better label (and we save one letter in the long names, yeah!), so the list of repos and tags will be: sclo6-rhscl-release sclo6-rhscl-testing sclo6-rhscl-devel sclo7-rhscl-release sclo7-rhscl-testing sclo7-rhscl-devel and the same for tags: sclo6-el6-rh-mariadb100-build sclo7-el7-rh-mariadb100-build sclo6-el6-rhscl-devel-rh-mariadb100-build sclo7-el7-rhscl-devel-rh-mariadb100-build and targets: sclo6-el6-rh-mariadb100 sclo7-el7-rh-mariadb100 sclo6-el6-rhscl-devel-rh-mariadb100 sclo7-el7-rhscl-devel-rh-mariadb100 (also notice moving -rhscl-devel to the middle, to be consistent with tag names) Honza >>> >build tags for e.g. collection rh-mariadb100: >>> >sclo6-el6-rh-mariadb100-build >>> >sclo7-el7-rh-mariadb100-build >>> >sclo6-el6-rhscl-future-rh-mariadb100-build >>> >sclo7-el7-rhscl-future-rh-mariadb100-build >>> >(We need to keep the disttag (el6, el7) in the name as agreed from the >>> >beginning for all SIGs) >>> > >>> >build targets: >>> >sclo6-el6-rh-mariadb100 >>> >sclo6-el6-rh-mariadb100-rhscl-future >>> >sclo7-el7-rh-mariadb100 >>> >sclo7-el7-rh-mariadb100-rhscl-future >>> > >>> >git branches under sclo/ project: >>> >sclo6-rh-mariadb100 >>> >sclo7-rh-mariadb100 >>> > >>> >git branches under rpms/ project: >>> >sclo6-rh-mariadb100 >>> >sclo7-rh-mariadb100 >>> > >>> >Again, will be glad for any feedback for this.. >>> > >>> >Honza >>> > >>> >_______________________________________________ >>> >SCLorg mailing list >>> >SCLorg at redhat.com >>> >https://www.redhat.com/mailman/listinfo/sclorg >>> > >> I asked around a few users at my work place (large national lab) and >> they didn?t seem to be confused at all about the ?rhscl? naming. >> People pretty much guessed that these were collections that were part >> of rhscl. Although the ?sclo? naming did seem to confuse pretty much >> everyone - but that?s a different issue. > > Thanks for the quick feedback! > > Honza > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From lindahl at pbm.com Wed Mar 25 21:14:34 2015 From: lindahl at pbm.com (Greg Lindahl) Date: Wed, 25 Mar 2015 14:14:34 -0700 Subject: [scl.org] php instructions? Message-ID: <20150325211434.GA16348@rd.bx9.net> The php55 package instructions are generic, saying how to run it on the command line: scl enable php55 bash Most usage of php is in cgi scripts. How do you use php55 with Apache? The system php rpm contains the file /etc/httpd/modules/libphp5.so, and the php55 packages don't seem to have a file like that. Am I missing something obvious? I'm on CentOS 7. -- greg From jmlich at redhat.com Thu Mar 26 12:49:58 2015 From: jmlich at redhat.com (Jozef Mlich) Date: Thu, 26 Mar 2015 13:49:58 +0100 Subject: [scl.org] php instructions? In-Reply-To: <20150325211434.GA16348@rd.bx9.net> References: <20150325211434.GA16348@rd.bx9.net> Message-ID: <1427374198.2835.26.camel@redhat.com> On Wed, 2015-03-25 at 14:14 -0700, Greg Lindahl wrote: > The php55 package instructions are generic, saying how to run it on > the command line: > > scl enable php55 bash > > Most usage of php is in cgi scripts. How do you use php55 with Apache? > The system php rpm contains the file /etc/httpd/modules/libphp5.so, > and the php55 packages don't seem to have a file like that. > > Am I missing something obvious? I'm on CentOS 7. > > -- greg > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg Hi, I agree that README file should be more verbose about running php as a apache module. I have tried to run rh-php56 in RHEL7. It have installed additionally httpd24. The module was enabled/installed by default in that apache. I was using command "yum install rh-php6-*" and started apache by "systemctl start httpd24-httpd" I am not sure if httpd module is installed in base package. I guess you can install just php55-php-cli without support of httpd. I was also testing php70 from Remi Collet [1] in Fedora 21. The php70 apache module cannot run with simultaneously with system version of apache module. You can uninstall system version of php or modify httpd configuration files. In my case it is "#" added to "LoadModule" lines of /etc/httpd/conf.modules.d/10-php.conf file [1] http://blog.famillecollet.com/post/2015/03/25/PHP-7.0-as-Software-Collection regards, -- Jozef Mlich Associate Software Engineer - EMEA ENG Developer Experience Mobile: +420 604 217 719 http://cz.redhat.com/ Red Hat, Inc. From rcollet at redhat.com Thu Mar 26 13:44:02 2015 From: rcollet at redhat.com (Remi Collet) Date: Thu, 26 Mar 2015 14:44:02 +0100 Subject: [scl.org] php instructions? In-Reply-To: <20150325211434.GA16348@rd.bx9.net> References: <20150325211434.GA16348@rd.bx9.net> Message-ID: <55140D22.5080102@redhat.com> Le 25/03/2015 22:14, Greg Lindahl a ?crit : > The php55 package instructions are generic, saying how to run it on > the command line: > > scl enable php55 bash > > Most usage of php is in cgi scripts. How do you use php55 with Apache? > The system php rpm contains the file /etc/httpd/modules/libphp5.so, > and the php55 packages don't seem to have a file like that. php55 (metapackage) doesn't pull mod_php by default by design (this is not a mandatory component) In php54 SCL, the php54-php provides mod_php for httpd (base) In php55 SCL, the php55-php provides mod_php for httpd24-httpd (SCL) In rh-php56, the rh-php56-php provides mod_php for httpd24-httpd (SCL) As only 1 mod_php can be loaded in apache, other should be uninstall or disabled. But php-fpm is definitively the way to go (with apache 2.4.x) especially as SetHandler to proxy is now supported. Then you can select PHP version used by app / project / vhost. FPM is more secure (different processes) and also allow to run apache in thread mode (worker or event). Die mod_php... die... Remi. P.S. various article about PHP as SCL on http://blog.famillecollet.com/tag/SCL > > Am I missing something obvious? I'm on CentOS 7. > > -- greg > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 From rcollet at redhat.com Thu Mar 26 13:52:53 2015 From: rcollet at redhat.com (Remi Collet) Date: Thu, 26 Mar 2015 14:52:53 +0100 Subject: [scl.org] php instructions? In-Reply-To: <1427374198.2835.26.camel@redhat.com> References: <20150325211434.GA16348@rd.bx9.net> <1427374198.2835.26.camel@redhat.com> Message-ID: <55140F35.8000408@redhat.com> Le 26/03/2015 13:49, Jozef Mlich a ?crit : > I was also testing php70 from Remi Collet [1] in Fedora 21. The php70 > apache module cannot run with simultaneously with system version of > apache module. You can uninstall system version of php or modify httpd > configuration files. PHP 7 is a bit different. All PHP 5.x provide the same version of mod_php (v5) Loadmodule php5_module xxx So Apache will only load the first one (usually the one from base package) and raise a "useful" warning "Module already loaded" PHP 7 provides a different version (v7) Loadmodule php7_module xxx In theory, apache accepts to load both, as considered as different module. Practically, this doesn't work, Apache try to load both and segfaults The reason why the php7_module is only loaded if php5_module is not already loaded, done in the configuration file. But we don't have any warning in this case. > In my case it is "#" added to "LoadModule" lines of > /etc/httpd/conf.modules.d/10-php.conf file The simplest solution. (but again... I think using FPM is better) Remi. > > > [1] > http://blog.famillecollet.com/post/2015/03/25/PHP-7.0-as-Software-Collection > > > regards, > -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 From rcollet at redhat.com Thu Mar 26 14:08:34 2015 From: rcollet at redhat.com (Remi Collet) Date: Thu, 26 Mar 2015 15:08:34 +0100 Subject: [scl.org] php instructions? In-Reply-To: <1427374198.2835.26.camel@redhat.com> References: <20150325211434.GA16348@rd.bx9.net> <1427374198.2835.26.camel@redhat.com> Message-ID: <551412E2.6040800@redhat.com> Le 26/03/2015 13:49, Jozef Mlich a ?crit : > I was using command "yum install rh-php6-*" ... Seems not really a good idea. This will pull rh-php56-build and rh-php56-scldevel which are usually not needed (and can raise issue if you try to build RPM on this box). You can also encounter conflicting packages (not with official RHSCL collections which only provide a minimal set of packages) - mysql vs mysqlnd - imagick vs gmagick - http1 vs http (v2) ... And you can finally get a tons of unneeded extensions, which is bad for performance. Only install the extension you really need. Remi. -- rcollet at redhat.com | Senior Software Engineer / BaseOS / WebStack team GPG Key: 0x29F16A18 Fingerprint: 5A0E 6F54 D94D 5732 69EE E3FF 614A 6905 29F1 6A18 From hhorak at redhat.com Tue Mar 31 14:23:29 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 31 Mar 2015 16:23:29 +0200 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-04-08) Message-ID: <551AADE1.9090609@redhat.com> Unfortunately I'm not available this week on Wed, I'm sorry, so let's arrange the SCLo meeting the next week. Since we have DST in Europe already as well, let's change to 15:00 UTC, that should fit to out schedules the same as it did on non-DST. So, SCLo meeting will be at 15:00 UTC (11:00 EST, 17:00 Brno, 11:00 Boston, 0:00+1d Tokyo, 1:00+1d Brisbane) in #centos-devel on Freenode. = Topics = * sync-up on current status * propose some other topics:) Honza From Jean-Francois.Vincent at worldline.com Tue Mar 31 14:27:48 2015 From: Jean-Francois.Vincent at worldline.com (=?iso-8859-1?Q?Vincent_Jean-Fran=E7ois?=) Date: Tue, 31 Mar 2015 16:27:48 +0200 Subject: [scl.org] Security & software collection & RedHat Message-ID: Hello, What is the Redhat security policy regarding discovered security holes in the software collection packages ? Update time/delay etc ? Regards Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.