From hhorak at redhat.com Tue Feb 3 17:29:15 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 03 Feb 2015 18:29:15 +0100 Subject: [scl.org] No CentOS SCLo SIG meeting this week Message-ID: <54D1056B.1010004@redhat.com> I'm sorry but this week is too busy for me and I have another meeting at the same timeslot. If anybody else wants to hold the meeting, feel free to do so. Honza From kelly.perez4044 at gmail.com Sun Feb 8 05:12:50 2015 From: kelly.perez4044 at gmail.com (Kelly Perez) Date: Sun, 08 Feb 2015 05:12:50 +0000 Subject: [scl.org] Higher Targeted Traffic: Softwarecollections.Org Message-ID: <001a11c24f2c851d09050e8cb42a@google.com> Hi Softwarecollections.Org Hope you are doing well. I thought you might like to know some of the *key points* which you need to address on priority and this can be the reason why you are not getting desired position out of continued SEO efforts. Well, you might consider this irrelevant but believe me, I have a complete analysis report ready with me for Softwarecollections.Org Your website needs immediate improvement on major factors like: Low online presence for many competitive keyword phrases Fixing errors that prevents your website from being indexed properly by search engine. Unorganized social media accounts Providing relevant content to create theme based back links and eliminate the bad back links. Active and regular updates and posts on social media portals to increase the popularity and brand awareness. We offer several services for your website such as Online Reputation Management, Social Media Optimization, SEO activities among others. We have excelled along with our customers because of some key propositions as delivering solution by competent Google Analytics certified professionals and we don't bind our customers with any set up fee or contract, i.e. *(NO CONTRACT or NO SET UP FEE)*. This e-mail provides you with a glimpse of some of the services which we offered from our company. If you have any queries about our services then kindly contact us back for a *free website audit report*. Should you be interested, get in touch with us on the mentioned email address or contact number. Best Regards, kelly perez |DM Consultant PH. No: +1 605-277-9747 Skype: digital.marketinghm ------------------------------ ------------------------------ ------------------------------ 1: This is a onetime email and you may ask us to "UNSUBSCRIBE". 2: If you are interested we will send more details on our "corporate identity", "company profile", "why you should choose us?", "Price list", "money back" etc. in our next mail. P.S: - This is our marketing strategy that we use the Gmail account. Once you reply us back, the next communication will be done from our corporate email ID. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon.stewart0214 at gmail.com Mon Feb 9 07:46:35 2015 From: brandon.stewart0214 at gmail.com (Brandon Stewart) Date: Mon, 09 Feb 2015 07:46:35 +0000 Subject: [scl.org] Higher Targeted Traffic: Softwarecollections.Org Message-ID: Hi Softwarecollections.Org Hope you are doing well. I thought you might like to know some of the key points which you need to address on priority and this can be the reason why you are not getting desired position out of continued SEO efforts. Well, you might consider this irrelevant but believe me, I have a complete analysis report ready with me for Softwarecollections.Org Your website needs immediate improvement on major factors like: 1.Low online presence for many competitive keyword phrases 2.Fixing errors that prevents your website from being indexed properly by search engine. 3.Unorganized social media accounts 4.Providing relevant content to create theme based back links and eliminate the bad back links. 5.Active and regular updates and posts on social media portals to increase the popularity and brand awareness. We offer several services for your website such as Online Reputation Management, Social Media Optimization, SEO activities among others. We have excelled along with our customers because of some key propositions as delivering solution by competent Google Analytics certified professionals and we don't bind our customers with any set up fee or contract, i.e. (NO CONTRACT or NO SET UP FEE). This e-mail provides you with a glimpse of some of the services which we offered from our company. If you have any queries about our services then kindly contact us back for a free website audit report. Should you be interested, get in touch with us on the mentioned email address or contact number. Best Regards, Brandon Stewart |DM Consultant PH. No: +1 605-277-9747 Skype: digital.marketinghm ------------------------------ ------------------------------ ------------------------------ 1: This is a onetime email and you may ask us to "UNSUBSCRIBE". 2: If you are interested we will send more details on our "corporate identity", "company profile", "why you should choose us?", "Price list", "money back" etc. in our next mail. P.S: - This is our marketing strategy that we use the Gmail account. Once you reply us back, the next communication will be done from our corporate email ID. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.nadal7878 at gmail.com Mon Feb 9 08:07:52 2015 From: george.nadal7878 at gmail.com (George Nadal) Date: Mon, 09 Feb 2015 08:07:52 +0000 Subject: [scl.org] Higher Targeted Traffic: Softwarecollections.Org Message-ID: <001a11c200d25783ca050ea34472@google.com> Hi Softwarecollections.Org Hope you are doing well. I thought you might like to know some of the *key points* which you need to address on priority and this can be the reason why you are not getting desired position out of continued SEO efforts. Well, you might consider this irrelevant but believe me, I have a complete analysis report ready with me for Softwarecollections.Org Your website needs immediate improvement on major factors like: Low online presence for many competitive keyword phrases Fixing errors that prevents your website from being indexed properly by search engine. Unorganized social media accounts Providing relevant content to create theme based back links and eliminate the bad back links. Active and regular updates and posts on social media portals to increase the popularity and brand awareness. We offer several services for your website such as Online Reputation Management, Social Media Optimization, SEO activities among others. We have excelled along with our customers because of some key propositions as delivering solution by competent Google Analytics certified professionals and we don't bind our customers with any set up fee or contract, i.e. *(NO CONTRACT or NO SET UP FEE)*. This e-mail provides you with a glimpse of some of the services which we offered from our company. If you have any queries about our services then kindly contact us back for a *free website audit report*. Should you be interested, get in touch with us on the mentioned email address or contact number. Best Regards, george nadal |DM Consultant PH. No: +1 605-277-9747 Skype: digital.marketinghm ------------------------------ ------------------------------ ------------------------------ 1: This is a onetime email and you may ask us to "UNSUBSCRIBE". 2: If you are interested we will send more details on our "corporate identity", "company profile", "why you should choose us?", "Price list", "money back" etc. in our next mail. P.S: - This is our marketing strategy that we use the Gmail account. Once you reply us back, the next communication will be done from our corporate email ID. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbsingh at centos.org Tue Feb 10 10:00:46 2015 From: kbsingh at centos.org (Karanbir Singh) Date: Tue, 10 Feb 2015 10:00:46 +0000 Subject: [scl.org] SCL's from softwarecollections.org repos to SIG Message-ID: <54D9D6CE.80108@centos.org> Hi, Do we have a list of things that need to get done before the repos hosted at SoftwareCollections.org can go away to be replaced with properly maintained content from centos.org ? crossposting, - KB -- Karanbir Singh, Project Lead, The CentOS Project +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS GnuPG Key : http://www.karan.org/publickey.asc From hhorak at redhat.com Wed Feb 11 13:25:21 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 11 Feb 2015 14:25:21 +0100 Subject: [scl.org] [CentOS-devel] SCL's from softwarecollections.org repos to SIG In-Reply-To: <54D9D6CE.80108@centos.org> References: <54D9D6CE.80108@centos.org> Message-ID: <54DB5841.1040607@redhat.com> On 02/10/2015 11:00 AM, Karanbir Singh wrote: > Hi, > > Do we have a list of things that need to get done before the repos > hosted at SoftwareCollections.org can go away to be replaced with > properly maintained content from centos.org ? > There are two things we identified as blocking us at [1]: a. authtag -- thing that allows non-admin users to push/import srpms into rpms/ namespace b. centpkg build ready with all features hacked Anybody knows about progress with those? As soon as we have (a) we can import srpms into centos (should be script-able). Then, as soon as we have (b) and all packages built, we can remove copr-built RPMs from scl.org and import bits from centos. However, there is also one feature missing on scl.org, which is to be able to import builds that were not built in copr. This is actually stuff for scl.org guys. We talked about it today and it seems there are more possible ways how to do this, we just need to figure out which is the best. This will be elaborated a bit in a separate thread. [1] http://lists.centos.org/pipermail/centos-devel/2015-January/012678.html Honza From hhorak at redhat.com Wed Feb 11 13:32:50 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 11 Feb 2015 14:32:50 +0100 Subject: [scl.org] No CentOS SCLo SIG meeting today by hhorak Message-ID: <54DB5A02.5020308@redhat.com> Guys, I'm very sorry, especially for the late announcement, but I'm not able to hold today's SIG meeting.. If anybody else wants to hold the meeting, feel free to do so. Honza From hhorak at redhat.com Wed Feb 11 17:39:14 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 11 Feb 2015 18:39:14 +0100 Subject: [scl.org] [CentOS-devel] SCL's from softwarecollections.org repos to SIG In-Reply-To: <54DB5841.1040607@redhat.com> References: <54D9D6CE.80108@centos.org> <54DB5841.1040607@redhat.com> Message-ID: <54DB93C2.4080908@redhat.com> On 02/11/2015 02:25 PM, Honza Horak wrote: > On 02/10/2015 11:00 AM, Karanbir Singh wrote: >> Hi, >> >> Do we have a list of things that need to get done before the repos >> hosted at SoftwareCollections.org can go away to be replaced with >> properly maintained content from centos.org ? >> > > There are two things we identified as blocking us at [1]: > a. authtag -- thing that allows non-admin users to push/import srpms > into rpms/ namespace > b. centpkg build ready with all features hacked Well, Remi actually brought me to reconsidering a bit if we actually really need those two things to start building collections -- we can build from srpm and have collections in sclX-testing repo right now actually. Then, we can rebuild from koji once the auth/centpkg is ready. That way we won't have signed packages and have anything in scl7-release (where only builds from scm can be placed, as I understood, is it correct?), but we may be fine with that for now. Does it make sense? Still cross-posting :) but would prefer to move to sclorg at redhat.com.. Honza > Anybody knows about progress with those? > > As soon as we have (a) we can import srpms into centos (should be > script-able). Then, as soon as we have (b) and all packages built, we > can remove copr-built RPMs from scl.org and import bits from centos. > > However, there is also one feature missing on scl.org, which is to be > able to import builds that were not built in copr. This is actually > stuff for scl.org guys. We talked about it today and it seems there are > more possible ways how to do this, we just need to figure out which is > the best. This will be elaborated a bit in a separate thread. > > [1] http://lists.centos.org/pipermail/centos-devel/2015-January/012678.html > > Honza > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From zippy1981 at gmail.com Thu Feb 12 15:20:59 2015 From: zippy1981 at gmail.com (Justin Dearing) Date: Thu, 12 Feb 2015 10:20:59 -0500 Subject: [scl.org] GDAL and the python scls Message-ID: 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 Tue Feb 17 07:52:33 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 17 Feb 2015 08:52:33 +0100 Subject: [scl.org] Component name in non-RH dist-gits Message-ID: <54E2F341.6090209@redhat.com> I'm thinking about repositories and branches structure in CentOS a bit again. Currently, there are two ways how components names and branches are maintained in SCL world: A) collection name in branch name we use component name without prefix in dist-git and branches for specific collections internally in RH, so e.g. mariadb has branches for mariadb55-*, rh-mariadb100-*, etc.. B) collection name in dist-git repository name For RHSCL RPMs that are automatically imported into https://git.centos.org [1], components *use* prefix in repository names and static set of branches. For example mariadb55-mariadb component includes branches 'master' and 'c7' [1]. This way seems easier for dist-git administration and also seems to be preferred way in Fedora [2]. Since we can always add remote branches in (B) and merge/cherry-pick from those as easy as we can in (A), my question is: "Are there any practical advantages of (A)?" I don't see any, but I see some advantages of (B) though, since it seems to be more consumable to use the same approach (B) in all public repos and only use (A) internally only for historic reasons. Does it make sense to you as well? [no response means yes to me :) ] [1] https://git.centos.org/tree/rpms!mariadb55-mariadb/c7 [2] https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros Cheers, Honza From rcollet at redhat.com Tue Feb 17 08:21:25 2015 From: rcollet at redhat.com (Remi Collet) Date: Tue, 17 Feb 2015 09:21:25 +0100 Subject: [scl.org] Component name in non-RH dist-gits In-Reply-To: <54E2F341.6090209@redhat.com> References: <54E2F341.6090209@redhat.com> Message-ID: <54E2FA05.1070602@redhat.com> Le 17/02/2015 08:52, Honza Horak a ?crit : > I'm thinking about repositories and branches structure in CentOS a bit > again. > > Currently, there are two ways how components names and branches are > maintained in SCL world: > > A) collection name in branch name > we use component name without prefix in dist-git and branches for > specific collections internally in RH, so e.g. mariadb has branches for > mariadb55-*, rh-mariadb100-*, etc.. > > B) collection name in dist-git repository name > For RHSCL RPMs that are automatically imported into > https://git.centos.org [1], components *use* prefix in repository names > and static set of branches. For example mariadb55-mariadb component > includes branches 'master' and 'c7' [1]. This way seems easier for > dist-git administration and also seems to be preferred way in Fedora [2]. > > Since we can always add remote branches in (B) and merge/cherry-pick > from those as easy as we can in (A), my question is: > > "Are there any practical advantages of (A)?" > > I don't see any, but I see some advantages of (B) though, since it seems > to be more consumable to use the same approach (B) in all public repos > and only use (A) internally only for historic reasons. (A) make sense to me, as the same package/spec can be used in various collections. Ex: php-pear, various branches => rhel-# => rhscl-##-php54-rhel-# => rhscl-##-php55-rhel-# => rhscl-##-rh-php56-rhel-# With (B) we need 4 repositories => php-pear => php54-php-pear => php55-php-pear => rh-php56-php-pear Of course, for historical reason (packages pulled from Fedora where SCL are not allowed), base packages are really different from SCL packages. But SCL packages are really similar in the different collections. But (B) is not really a problem, in fact I mostly never have to cherry-pick from different branches. But in some other repo, I use "exactly" the same spec for all targets. Remi > > Does it make sense to you as well? > [no response means yes to me :) ] > > [1] https://git.centos.org/tree/rpms!mariadb55-mariadb/c7 > [2] > https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros > > > Cheers, > Honza > > _______________________________________________ > 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 Tue Feb 17 08:33:16 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 17 Feb 2015 09:33:16 +0100 Subject: [scl.org] Component name in non-RH dist-gits In-Reply-To: <54E2FA05.1070602@redhat.com> References: <54E2F341.6090209@redhat.com> <54E2FA05.1070602@redhat.com> Message-ID: <54E2FCCC.1060807@redhat.com> On 02/17/2015 09:21 AM, Remi Collet wrote: > Le 17/02/2015 08:52, Honza Horak a ?crit : >> I'm thinking about repositories and branches structure in CentOS a bit >> again. >> >> Currently, there are two ways how components names and branches are >> maintained in SCL world: >> >> A) collection name in branch name >> we use component name without prefix in dist-git and branches for >> specific collections internally in RH, so e.g. mariadb has branches for >> mariadb55-*, rh-mariadb100-*, etc.. >> >> B) collection name in dist-git repository name >> For RHSCL RPMs that are automatically imported into >> https://git.centos.org [1], components *use* prefix in repository names >> and static set of branches. For example mariadb55-mariadb component >> includes branches 'master' and 'c7' [1]. This way seems easier for >> dist-git administration and also seems to be preferred way in Fedora [2]. >> >> Since we can always add remote branches in (B) and merge/cherry-pick >> from those as easy as we can in (A), my question is: >> >> "Are there any practical advantages of (A)?" >> >> I don't see any, but I see some advantages of (B) though, since it seems >> to be more consumable to use the same approach (B) in all public repos >> and only use (A) internally only for historic reasons. > > (A) make sense to me, as the same package/spec can be used in various > collections. > > Ex: php-pear, various branches > => rhel-# > => rhscl-##-php54-rhel-# > => rhscl-##-php55-rhel-# > => rhscl-##-rh-php56-rhel-# > > With (B) we need 4 repositories > => php-pear > => php54-php-pear > => php55-php-pear > => rh-php56-php-pear > > Of course, for historical reason (packages pulled from Fedora where SCL > are not allowed), base packages are really different from SCL packages. > But SCL packages are really similar in the different collections. > > But (B) is not really a problem, in fact I mostly never have to > cherry-pick from different branches. > > But in some other repo, I use "exactly" the same spec for all targets. Thanks for the feedback. One aspect I haven't realized is that with (A) we'd keep information which collections the package is included in. With (B) we wouldn't be able to say that e.g. boost package is used in collections foo42, bar24, ... This seems to be quite useful information. Honza > > > Remi > >> >> Does it make sense to you as well? >> [no response means yes to me :) ] >> >> [1] https://git.centos.org/tree/rpms!mariadb55-mariadb/c7 >> [2] >> https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macros >> >> >> Cheers, >> Honza >> >> _______________________________________________ >> SCLorg mailing list >> SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg > > From mizdebsk at redhat.com Tue Feb 17 11:17:38 2015 From: mizdebsk at redhat.com (Mikolaj Izdebski) Date: Tue, 17 Feb 2015 12:17:38 +0100 Subject: [scl.org] Component name in non-RH dist-gits In-Reply-To: <54E2F341.6090209@redhat.com> References: <54E2F341.6090209@redhat.com> Message-ID: <54E32352.3040007@redhat.com> On 02/17/2015 08:52 AM, Honza Horak wrote: > I'm thinking about repositories and branches structure in CentOS a bit > again. > > Currently, there are two ways how components names and branches are > maintained in SCL world: > > A) collection name in branch name > we use component name without prefix in dist-git and branches for > specific collections internally in RH, so e.g. mariadb has branches for > mariadb55-*, rh-mariadb100-*, etc.. > > B) collection name in dist-git repository name > For RHSCL RPMs that are automatically imported into > https://git.centos.org [1], components *use* prefix in repository names > and static set of branches. For example mariadb55-mariadb component > includes branches 'master' and 'c7' [1]. This way seems easier for > dist-git administration and also seems to be preferred way in Fedora [2]. > > Since we can always add remote branches in (B) and merge/cherry-pick > from those as easy as we can in (A), my question is: Git is very flexible in this aspect. You can have one local repo with many remotes and vice versa - one remote repo with multiple per-SCL local repos. You can rename local branches too according to your needs. > > "Are there any practical advantages of (A)?" One I can think of is that you can easily guess Koji build target from branch name. > I don't see any, but I see some advantages of (B) though, since it seems > to be more consumable to use the same approach (B) in all public repos > and only use (A) internally only for historic reasons. > > Does it make sense to you as well? > [no response means yes to me :) ] I personally slightly prefer A (maybe just because I'm used to it), but I think that both approaches are good, as long as spec files are named as they are now. It's important to keep the same names across different repos for easier merging. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk From hhorak at redhat.com Tue Feb 17 11:45:28 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 17 Feb 2015 12:45:28 +0100 Subject: [scl.org] Names under /var/opt, /etc/opt Message-ID: <54E329D8.4010705@redhat.com> This is about files under /var/opt and potentially /etc/opt when we use %nfsmountable in new scl-utils. Basic question: do we want to prefix file names in cases the location path already includes the SCL name? Simple answer would be "no, it's not needed". (variant B) However, there is another PoV -- pid files, log files, lock files, etc. have been traditionally called the same as the daemon, so someone can assume this convention will be kept in SCLs (variant A) So, how it looks in practice: variant A) Keeping the pid/log files names the same as the daemon: /var/opt/rh/scls/rh-mariadb100/log/mariadb/rh-mariadb100-mariadb.log /var/opt/rh/scls/rh-mariadb100/run/rh-mariadb100-mariadb/rh-mariadb100-mariadb.pid variant B) If we don't include prefix (we break the convention), the location seems nicer: /var/opt/rh/scls/rh-mariadb100/log/mariadb/mariadb.log /var/opt/rh/scls/rh-mariadb100/run/mariadb/mariadb.pid I like the (B) variant more, just keep it more simple and just break the custom to name pid/log files the same as the deamon. However, I'd appreciate any input on this. Honza From hhorak at redhat.com Tue Feb 17 16:08:25 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 17 Feb 2015 17:08:25 +0100 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-02-18) Message-ID: <54E36779.2010509@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 * how syncing RHSCL content into CentOS works * polishing the work-flow to build collections * next steps From jakems at fedoraproject.org Tue Feb 17 17:19:49 2015 From: jakems at fedoraproject.org (Jake Shipton) Date: Tue, 17 Feb 2015 17:19:49 +0000 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-02-18) In-Reply-To: <54E36779.2010509@redhat.com> References: <54E36779.2010509@redhat.com> Message-ID: <54E37835.6000508@fedoraproject.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17/02/15 16:08, 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 * how syncing RHSCL content into CentOS > works * polishing the work-flow to build collections * next steps > > _______________________________________________ SCLorg mailing > list SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg Hi, Last week I spoke about potentially contributing to this SCL project via centos-devel[1] list. Is it still okay if I tag along to this meeting to discuss this? I was asked if I was able to go to the last meeting [2], however that meeting was cancelled [3]. [1] http://lists.centos.org/pipermail/centos-devel/2015-February/012811.html [2] http://lists.centos.org/pipermail/centos-devel/2015-February/012812.html [3] http://lists.centos.org/pipermail/centos-devel/2015-February/012815.html Kind Regards, Jake Shipton (JakeMS) Twitter: @CrazyLinuxNerd GPG Key: 0xE3C31D8F GPG Fingerprint: 7515 CC63 19BD 06F9 400A DE8A 1D0B A5CF E3C3 1D8F -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJU43gyAAoJEB0Lpc/jwx2PZVYH/j7rJZUqxKX2Gffy9D2rU7tg gOGmegw2J9hmz0VLCc6S9u/PuVYglqQUr0DQ0BTmEwM8Tm4uJ/M8k+7Ui+BPzwYL OVQgi/b19nGQkuFkal1MqiBwyR2l3UzfODY8f9M1lAbZngD3NYHvtxg2OeO7hgI1 /lF2ZnYNr0j2PHoeDv3fauNE5LNTC/6XSmCyriRPekvsoTLTp+Qge8qVzkaqo+gr RjZ3TCm2efp3FGSOxIF+gpRqxfCJBHKDARmYnVeXJ80b4xZYhqlZOeS0vDShbwD2 K99DKV4131bQP2P0s4pvQ8YW0HPp4bPxl8GcYIMSWsrGYsc03US/4lL9I4m1dDI= =63rI -----END PGP SIGNATURE----- From joyce.dolan at coretechnologyinsights.com Tue Feb 17 19:27:00 2015 From: joyce.dolan at coretechnologyinsights.com (Joyce Dolan ) Date: Tue, 17 Feb 2015 13:27:00 -0600 Subject: [scl.org] OpenStack Users Opt-In Email Records Message-ID: <0e0b01d04ae8$30e92c00$92bb8400$@coretechnologyinsights.com> Hi, Are you interested in acquiring Cloud Computing Users Email List that will help you to reach out to all the key decision makers? Our list includes complete contact information such as Company Name, Contact Name, Contact Title, Website, Street Address, City, State, Zip Code, Country, Phone Number, Fax Number, Verified Email Address, Employee Size, and Revenue, SIC Code & NAICS Code. Below are few targeted lists:- Oracle Users Amazon Users VMware Users OpenStack Users Rackspace Users IBM Users Citrix Users Microsoft Users Salesforce Users Google Users Joyent Users EMC Users We have contact details of 10,000 plus companies across the globe. Please let me know your target criteria. Thank you and I look forward to hear from you. Regards, Joyce Dolan Marketing Consultant To remove from this mailing: reply with subject line as "leave out" -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Wed Feb 18 14:17:58 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 18 Feb 2015 15:17:58 +0100 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-02-18) In-Reply-To: <54E37835.6000508@fedoraproject.org> References: <54E36779.2010509@redhat.com> <54E37835.6000508@fedoraproject.org> Message-ID: <54E49F16.4000809@redhat.com> Sure, that's great, just show up in the #centos-devel channel. Honza On 02/17/2015 06:19 PM, Jake Shipton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 17/02/15 16:08, 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 * how syncing RHSCL content into CentOS >> works * polishing the work-flow to build collections * next steps >> >> _______________________________________________ SCLorg mailing >> list SCLorg at redhat.com >> https://www.redhat.com/mailman/listinfo/sclorg > Hi, > > Last week I spoke about potentially contributing to this SCL project > via centos-devel[1] list. > > Is it still okay if I tag along to this meeting to discuss this? I was > asked if I was able to go to the last meeting [2], however that > meeting was cancelled [3]. > > [1] > http://lists.centos.org/pipermail/centos-devel/2015-February/012811.html > [2] > http://lists.centos.org/pipermail/centos-devel/2015-February/012812.html > [3] > http://lists.centos.org/pipermail/centos-devel/2015-February/012815.html > > Kind Regards, > Jake Shipton (JakeMS) > Twitter: @CrazyLinuxNerd > GPG Key: 0xE3C31D8F > GPG Fingerprint: 7515 CC63 19BD 06F9 400A DE8A 1D0B A5CF E3C3 1D8F > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQEcBAEBAgAGBQJU43gyAAoJEB0Lpc/jwx2PZVYH/j7rJZUqxKX2Gffy9D2rU7tg > gOGmegw2J9hmz0VLCc6S9u/PuVYglqQUr0DQ0BTmEwM8Tm4uJ/M8k+7Ui+BPzwYL > OVQgi/b19nGQkuFkal1MqiBwyR2l3UzfODY8f9M1lAbZngD3NYHvtxg2OeO7hgI1 > /lF2ZnYNr0j2PHoeDv3fauNE5LNTC/6XSmCyriRPekvsoTLTp+Qge8qVzkaqo+gr > RjZ3TCm2efp3FGSOxIF+gpRqxfCJBHKDARmYnVeXJ80b4xZYhqlZOeS0vDShbwD2 > K99DKV4131bQP2P0s4pvQ8YW0HPp4bPxl8GcYIMSWsrGYsc03US/4lL9I4m1dDI= > =63rI > -----END PGP SIGNATURE----- > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From allison.paxton at itctranslationsusa.com Wed Feb 18 20:25:34 2015 From: allison.paxton at itctranslationsusa.com (=?utf-8?Q?ITC_Global_Translations_USA?=) Date: Wed, 18 Feb 2015 21:25:34 +0100 (CET) Subject: [scl.org] =?utf-8?q?Other_companies_sell_internationally=2C_why_d?= =?utf-8?b?b27igJl0IHlvdT8gSVRDLg==?= Message-ID: <30896-38-5-0000015566@sbr49.net> If you have problems displaying this message, Consult the web copy ( http://eye.itctranslationsusa.com/w/5972/4TuACWAg4UqHGSuQWY3_CA/j3NgXAHn10KEq6Eih6PgGw ) ( http://www.itcglobaltranslations.com/email/itcfrance/Newlogo-ITCFRE.jpg ) FRENCH ( http://www.intlanguages.com/email/itcusa/french/index.html ) ?SPAIN ( http://www.intlanguages.com/email/itcusa/spanish/index.html ) GERMAN ( http://www.intlanguages.com/email/itcusa/german/index.html ) ?Hello, ? You are looking for a trusted partner for your translation projects. ITC Global Translations is a leader in thetranslation industry.??We have over 1,000 linguistsin ournetwork?to provide the most specialized teams for your company. ? ( http://www.itcglobaltranslations.com/ ) Personalized service to meet your unique needs Over 15 yearsof exceptional service Services in over 75 language combinations Reliable and dedicatedProject Managers Rigorous in-houseQuality Assuranceprocess Offices in the United States, Canada?and Europe We provide around-the-clock service ( http://www.itcglobaltranslations.com/ ) Translation, proofreading, editing (medical, pharmaceutical, marketing, technical, legal texts) Localization ?(software, websites, marketing and advertising content...) Multilingual formatting/layout(DTP) Transcriptions, subtitles Transcreation Web and mobile content I am at your disposal to discuss your needs or your next translation project. Best Regards, Allison PAXTON a.paxton at itcglobaltranslations.com Business Development Manager ITC Translations USA www.itcglobaltranslations.com ( http://www.itcglobaltranslations.com/ ) T: 1 561 746 6242 ( https://www.facebook.com/ITCGlobalTranslations?fref=photo ) ( https://twitter.com/ITCtranslations?lang=en ) ( https://www.linkedin.com/profile/view?id=14490336&authType=OPENLINK&authToken=Um86&locale=en_US&srchid=709166311424201091086&srchindex=1&srchtotal=11&trk=vsrp_people_res_name&trkInfo=VSRPsearchId%3A709166311424201091086%2CVSRPtargetId%3A14490336%2CVSRPcmpt%3Aprimary ) ( mailto: ) Click on this link to unsubscribe ( http://eye.itctranslationsusa.com/f/USBSHOW/31/5972/4TuACWAg4UqHGSuQWY3_CA/j3NgXAHn10KEq6Eih6PgGw/9bXsOJDsa0ukvof6pEKmvw?email=sclorg at redhat.com&adm=optout.fre at intlanguages.com ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From hhorak at redhat.com Thu Feb 19 16:33:51 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 19 Feb 2015 17:33:51 +0100 Subject: [scl.org] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2015-02-18) In-Reply-To: <54E36779.2010509@redhat.com> References: <54E36779.2010509@redhat.com> Message-ID: <54E6106F.6050509@redhat.com> ============================================ #centos-devel: SCLo SIG sync-up (2015-02-18) ============================================ Meeting started by hhorak at 16:02:22 UTC. The full logs are available at centos-devel/2015/centos-devel.2015-02-18-16.02.log.html . Meeting summary --------------- * current status (hhorak, 16:03:33) * new build of centpkg expected in bananas7 by the end of this week (hhorak, 16:06:14) * let's just choose some sensible format that is easily parse-able and change it in case it is needed (hhorak, 16:17:59) * ^ for requests in git.c.o and cbs (hhorak, 16:18:20) * how syncing RHSCL content into CentOS works (hhorak, 16:18:29) * in rpms project in git.c.o we'll use repository name without prefix (e.g. mariadb) and branches in format e.g. sclo7-mariadb55 (hhorak, 17:02:32) * polishing the work-flow to build collections (hhorak, 17:03:07) * ACTION: hhorak to send some draft for sclo workflow to sclorg at rh.c mailing list hopefully tomorrow. so, stay tuned (hhorak, 17:07:39) * next steps (hhorak, 17:07:45) * ACTION: hhorak to prepare 'howto contribute' section to the SIG page (hhorak, 17:13:10) * ACTION: hhorak to create a task list with easier stuff on top (hhorak, 17:17:52) Meeting ended at 17:26:28 UTC. Action Items ------------ * hhorak to send some draft for sclo workflow to sclorg at rh.c mailing list hopefully tomorrow. so, stay tuned * hhorak to prepare 'howto contribute' section to the SIG page * hhorak to create a task list with easier stuff on top Action Items, by person ----------------------- * hhorak * hhorak to send some draft for sclo workflow to sclorg at rh.c mailing list hopefully tomorrow. so, stay tuned * hhorak to prepare 'howto contribute' section to the SIG page * hhorak to create a task list with easier stuff on top * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * hhorak (63) * kbsingh (44) * JakeMS (8) * smooge (6) * bstinson (6) * centbot (4) * asamalik (1) * Dominic (1) * RemiFedora (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From hhorak at redhat.com Thu Feb 19 19:57:19 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 19 Feb 2015 20:57:19 +0100 Subject: [scl.org] Component name in non-RH dist-gits In-Reply-To: <54E32352.3040007@redhat.com> References: <54E2F341.6090209@redhat.com> <54E32352.3040007@redhat.com> Message-ID: <54E6401F.2080802@redhat.com> On 02/17/2015 12:17 PM, Mikolaj Izdebski wrote: > On 02/17/2015 08:52 AM, Honza Horak wrote: >> I'm thinking about repositories and branches structure in CentOS a bit >> again. >> >> Currently, there are two ways how components names and branches are >> maintained in SCL world: >> >> A) collection name in branch name >> we use component name without prefix in dist-git and branches for >> specific collections internally in RH, so e.g. mariadb has branches for >> mariadb55-*, rh-mariadb100-*, etc.. >> >> B) collection name in dist-git repository name >> For RHSCL RPMs that are automatically imported into >> https://git.centos.org [1], components *use* prefix in repository names >> and static set of branches. For example mariadb55-mariadb component >> includes branches 'master' and 'c7' [1]. This way seems easier for >> dist-git administration and also seems to be preferred way in Fedora [2]. >> >> Since we can always add remote branches in (B) and merge/cherry-pick >> from those as easy as we can in (A), my question is: > > Git is very flexible in this aspect. You can have one local repo with > many remotes and vice versa - one remote repo with multiple per-SCL > local repos. You can rename local branches too according to your needs. > >> >> "Are there any practical advantages of (A)?" > > One I can think of is that you can easily guess Koji build target from > branch name. It seems CentOS guys are fine with this approach as well, the rpms imported into centos won't be actually used for building, we'll be able to use either way. >> I don't see any, but I see some advantages of (B) though, since it seems >> to be more consumable to use the same approach (B) in all public repos >> and only use (A) internally only for historic reasons. >> >> Does it make sense to you as well? >> [no response means yes to me :) ] > > I personally slightly prefer A (maybe just because I'm used to it), but > I think that both approaches are good, as long as spec files are named > as they are now. It's important to keep the same names across different > repos for easier merging. Sure, this will need to be kept. Honza From hhorak at redhat.com Mon Feb 23 17:13:22 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 23 Feb 2015 18:13:22 +0100 Subject: [scl.org] CBS build tags and git branches names for SCL Message-ID: <54EB5FB2.5090306@redhat.com> I'm about to submit a couple of requests into bugs.c.o to create necessary infrastructure for collections from RHSCL-1.2 at least. But first I want to make sure about the tag and branches names. Currently we have some testing build tags: scl6-el6-mariadb100-build scl7-el7-mariadb100-build and branches in dist-git (in sclo project): scl-mariadb100-el6 scl-mariadb100-el7 And the SIG has codename 'sclo'.. So, it's kind of messy already in the beginning :) Thinking about keeping it simple and uniform, what about this way: Keep 'sclo' as SIG codename to indicate it's combination of SCL on openness :) CBS build tags in format like: sclo6-mariadb100-build sclo7-mariadb100-build and branches in dist-git (in both sclo and rpms projects): sclo6-mariadb100 sclo7-mariadb100 This mail is to check whether we're fine to go this way or if there are some limitations we need to follow. dist-git and CBS gurus, please, provide your PoV. Thanks! Honza From hhorak at redhat.com Mon Feb 23 17:28:47 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 23 Feb 2015 18:28:47 +0100 Subject: [scl.org] Why Software Collections will use rh- prefix and what it means Message-ID: <54EB634F.7010307@redhat.com> There has already been some discussion (quite heated) and imho quite a lot misunderstanding about using "rh-" prefix in Software Collections. Hopefully this will help to understand the reasoning. TL;DR version and also a candidate for [1]: ------------------------------------------- The goal of prefix in the SCL name (e.g. "rh-" in case of Red Hat's collections available as Red Hat Software Collections product) is *not* to scope or brand the software collection rather it is to "namespace" it. A prefix in the SCL name: 1) allows "others" (users in particular) to have a distinguishing name per their requirement 2) SCL authors have one "collection name" wherever the collection will appear 3) users (open source projects, paying, whatever) have one collection name to target irrelevant of platform Thus, if the "distributor" can claim the SCL to be api/bug/etc compatible, they should still use "rh-". Long version and further explanation: ------------------------------------- Software Collections appeal to developers as a way to work on newer platforms on top of older OSes and a way to move older applications to newer OSes. The appeal to developers and admins is the independence of the application and its platform from the OS irrelevant of direction of "newness." Customers need a way to distinguish in-house-built/3rd-party-built packages from the the ones RH is shipping in RHSCL. After much discussion, it was concluded that a prefix on the collection name was the best way to resolve this. First, we were all on the same page: add "rh-" to collection names when on RHEL and whatever (*not* "rh-") in every other distro. However, it appeared that adding "rh-" for only RHEL makes it very difficult to maintain the component on other distros/environments thereby problematic to be the compatible "upstream". It also appeared that the SCL are very difficult to consume if they change names per distro (e.g. rh-python27 on rhel and cent-python27 on centos) thereby hurting the "apps using SCLs for portability" idea. We also have to assume that these problems would have been experienced by both, customers of RHSCL as well as users of open source SCLs. As a result, we concluded that we should add "rh-" to any collection that RHSCL ships on *any* distro. A prefix of "rh-" : 1) allows "others" (users and customers in particular) to have a distinguishing name per their requirement 2) SCL authors have one "collection name" wherever the collection will appear 3) users (open source projects, paying, whatever) have one collection name to target irrelevant of platform 4) SCLs that are not created for RHSCL have an obvious model to follow (e.g. remi-php54-extras, blueHost-perl6) that will encourage a non-conflicting name-spacing model. How to work with the prefix in practice: ---------------------------------------- If the "distributor" can claim the SCL to be api/bug/etc compatible, they should still use "rh-". The goal here is not to scope or brand the software collection rather it is to "namespace" it. If the collection is built and maintained either because it is currently, will be, or used to be in RHSCL then we should prefix the collection name with "rh-" whether that collection is being packaged for RHEL, fedora, centos, my-cool-rpm-distro, etc. The *name* of the collection is rh-. This is by convention only and is totally open for 3rd-parties to abuse (but we will make fun of them if they do). If openshift were to build and distribute a different collection for the similar but not the same functionality (e.g. rh-python27 has foo-library and openshift see foo-library as bad for its users), they/you should distribute it as "rhos-" to distinguish that it has a different api. Basically, it boils down to this, in a software collection world, there is no canonical version of something (unlike in traditional packaging) so we need to setup a method where a consumer knows what they are getting. The "rh-" is to allow for the namespacing to say "hey buddy, yes, this is the python27 that comes with rhscl even though you didn't get it from the redhat RHSCL channel" and it is "rh-" cause it is 3 less chars than "rhscl-" . But, if someone else comes along and wants to do a slightly different version of python27 (as in the case above) they have a convention by which they can do it. Open questions: --------------- Q: what will be the collection name which is aimed to ship the rest of packages within CentOS, above rh- (i.e. SCL that extends rh- collection)? Proposal: sclo--extra (e.g. sclo-rh-python34-extra) prefix will be used since this is actually result of the CentOS upstream and it says that the rpms are not coming from RH, but extend the collection from RH [1] https://www.softwarecollections.org/en/docs/ Honza From hhorak at redhat.com Mon Feb 23 17:44:22 2015 From: hhorak at redhat.com (Honza Horak) Date: Mon, 23 Feb 2015 18:44:22 +0100 Subject: [scl.org] Workflow for Software Collections (SCLs) in CentOS Message-ID: <54EB66F6.50301@redhat.com> This proposal considers the following: * we want to provide stable SCLs rebuilt from RHSCL for CentOS users * we want to have a platform for upstream development for collections that: - will be part of the future RHSCL (same SCL name as in RHSCL uses, RH developers own those, others may contribute -- send patches) - have been part of RHSCL but will get some update eventually, so we want to test the fixes before applying in RHSCL - are not intended for RHSCL (those won't use "rh-" prefix [2], but should have some other prefix) Some technical details of CentOS Build Service (CBS) at [3] ============================================================================= There are several projects in centos distgit (http://git.centos.org), those two are important for SCL: * sclo -- code of testing packages, uses fedora layout (specfile and sources directly in the repository, no directories), building rpms in CBS only from srpm, final rpms are testing only (tagged into sclX-testing) * rpms -- code of stable packages, centos layout (specfile and sources in SPECS, SOURCES directories), building rpms in CBS either from srpm or from scm, possible to build official rpms (tagged into sclX-release, request signing and releasing) There are two koji tags set for all collections for every elX version (X is 6, 7, ...el6, el7, ...): * sclX-testing: default tag where all built srpms are tagged into * sclX-release: only rpms built from scm can be tagged here (and will be signed) Workflow schema: ================ git.c.o CBS scl.org [1] ----------------------------------------- develop in sclo project | \ | \ | build from srpm | for testing only | | | | | rpm tagged into | sclX-testing | \ | \ | available in | sclo-testing | repo | | import srpm into rpms project \ \ build release candidate from scm | | tagged into sclX-testing \ \ available in sclo-testing repo / / tag into sclX-release sign & release \ \ available in sclo-stable repo Description of the scheme above =============================== Workflow during development phase: ---------------------------------- * this part is valid for future RHSCL collections that (both net new and major update) are not yet available in RHSCL * contributors prepare new collection under sclo project * contributors build testing rpms from srpm * rpms are tagged into sclX-testing * scl.org [1] imports specific collections from sclX-testing Workflow during maintainance phase: -------------------------------- * this part is valid for collections that are/were released * contributors prepare patches under sclo project to test them before applying (in RHSCL or non-RH stable SCL) -- fix smaller bugs, extend stable collection in compatible mode, generally maintain compatibility of the collection * contributors build testing rpms from srpm * rpms are tagged into sclX-testing * srpms are manually imported from sclo to rpms project @ git.c.o * contributors build official packages from scm and tag them into sclX-release * contributors ask for signing and publishing * scl.org imports specific collections from sclX-release and potentially also from sclX-testing Specific for RH collections: ---------------------------- srpm can be automatically imported to rpms project or even to sclo project on errata publishing if maintainer wishes so Some open questions =================== Q: scl.org to provide a separate repository for each collection? or one repository for all collections in -testing? Proposal: we can start with one common repository for all stable centos collections, the same we do in RHSCL? Q: what about centos vs epel? Proposal: if there are some packages that want to use centos collections in the future, epel should start to build above centos' sclo repos. That means the same collections don't need to be build again in epel. How is it done in other centos SIGs in case they provide the same components in epel? [1] https://www.softwarecollections.org/en/scls/ [2] https://www.redhat.com/archives/sclorg/2015-February/msg00022.html [3] http://cbs.centos.org Honza From briang at redhat.com Mon Feb 23 18:05:57 2015 From: briang at redhat.com (Brian Gollaher) Date: Mon, 23 Feb 2015 13:05:57 -0500 Subject: [scl.org] Why Software Collections will use rh- prefix and what it means In-Reply-To: <54EB634F.7010307@redhat.com> References: <54EB634F.7010307@redhat.com> Message-ID: <54EB6C05.8070600@redhat.com> I want to add one clarifying point. This is correct that rh- identifies a collection that is built, tested, and released for RHSCL. It can be used by any distro. To be clear, the api/bug/etc compatible applies only to RHSCL. So for RHSCL, if we update a collection and keep api compatibility, we will not change the name, only the version. This is typically the case for a collection where we fix some bugs but don't rebase to a newer upstream version in a minor RHSCL release. If some other entity updates the collection (say adds a new module or fixes a bug) where it is different than the collection in RHSCL, it can't keep the same name even it "claims" api compatibility. Users of any distro need the assurance that rh- indicates that the collection was tested and released to RHSCL. I think this was meant below but I want to make sure. Brian On 02/23/2015 12:28 PM, Honza Horak wrote: > There has already been some discussion (quite heated) and imho quite a > lot misunderstanding about using "rh-" prefix in Software Collections. > Hopefully this will help to understand the reasoning. > > TL;DR version and also a candidate for [1]: > ------------------------------------------- > The goal of prefix in the SCL name (e.g. "rh-" in case of Red Hat's > collections available as Red Hat Software Collections product) is > *not* to scope or brand the software collection rather it is to > "namespace" it. > > A prefix in the SCL name: > 1) allows "others" (users in particular) to have a distinguishing name > per their requirement > 2) SCL authors have one "collection name" wherever the collection will > appear > 3) users (open source projects, paying, whatever) have one collection > name to target irrelevant of platform > > Thus, if the "distributor" can claim the SCL to be api/bug/etc > compatible, they should still use "rh-". > > > Long version and further explanation: > ------------------------------------- > Software Collections appeal to developers as a way to work on newer > platforms on top of older OSes and a way to move older applications to > newer OSes. The appeal to developers and admins is the independence of > the application and its platform from the OS irrelevant of direction > of "newness." > > Customers need a way to distinguish in-house-built/3rd-party-built > packages from the the ones RH is shipping in RHSCL. After much > discussion, it was concluded that a prefix on the collection name was > the best way to resolve this. First, we were all on the same page: add > "rh-" to collection names when on RHEL and whatever (*not* "rh-") in > every other distro. > > However, it appeared that adding "rh-" for only RHEL makes it very > difficult to maintain the component on other distros/environments > thereby problematic to be the compatible "upstream". It also appeared > that the SCL are very difficult to consume if they change names per > distro (e.g. rh-python27 on rhel and cent-python27 on centos) thereby > hurting the "apps using SCLs for portability" idea. We also have to > assume that these problems would have been experienced by both, > customers of RHSCL as well as users of open source SCLs. > > As a result, we concluded that we should add "rh-" to any collection > that RHSCL ships on *any* distro. > > A prefix of "rh-" : > 1) allows "others" (users and customers in particular) to have a > distinguishing name per their requirement > 2) SCL authors have one "collection name" wherever the collection will > appear > 3) users (open source projects, paying, whatever) have one collection > name to target irrelevant of platform > 4) SCLs that are not created for RHSCL have an obvious model to follow > (e.g. remi-php54-extras, blueHost-perl6) that will encourage a > non-conflicting name-spacing model. > > How to work with the prefix in practice: > ---------------------------------------- > If the "distributor" can claim the SCL to be api/bug/etc compatible, > they should still use "rh-". The goal here is not to scope or brand > the software collection rather it is to "namespace" it. > > If the collection is built and maintained either because it is > currently, will be, or used to be in RHSCL then we should prefix the > collection name with "rh-" whether that collection is being packaged > for RHEL, fedora, centos, my-cool-rpm-distro, etc. The *name* of the > collection is rh-. This is by convention only and is > totally open for 3rd-parties to abuse (but we will make fun of them if > they do). > > If openshift were to build and distribute a different collection for > the similar but not the same functionality (e.g. rh-python27 has > foo-library and openshift see foo-library as bad for its users), > they/you should distribute it as "rhos-" to distinguish that it has a > different api. > > Basically, it boils down to this, in a software collection world, > there is no canonical version of something (unlike in traditional > packaging) so we need to setup a method where a consumer knows what > they are getting. The "rh-" is to allow for the namespacing to say > "hey buddy, yes, this is the python27 that comes with rhscl even > though you didn't get it from the redhat RHSCL channel" and it is > "rh-" cause it is 3 less chars than "rhscl-" . But, if someone else > comes along and wants to do a slightly different version of python27 > (as in the case above) they have a convention by which they can do it. > > Open questions: > --------------- > Q: what will be the collection name which is aimed to ship the rest of > packages within CentOS, above rh- (i.e. SCL that extends > rh- collection)? > Proposal: sclo--extra (e.g. sclo-rh-python34-extra) prefix > will be used since this is actually result of the CentOS upstream and > it says that the rpms are not coming from RH, but extend the > collection from RH > > [1] https://www.softwarecollections.org/en/docs/ > > Honza > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg -- Brian Gollaher Red Hat Platform Product Management Phone: 978 392-3173 Cell: 508 740-6549 briang at redhat.com From thomas.oulevey at cern.ch Mon Feb 23 19:39:41 2015 From: thomas.oulevey at cern.ch (Thomas Oulevey) Date: Mon, 23 Feb 2015 20:39:41 +0100 Subject: [scl.org] CBS build tags and git branches names for SCL In-Reply-To: <54EB5FB2.5090306@redhat.com> References: <54EB5FB2.5090306@redhat.com> Message-ID: <54EB81FD.3010601@cern.ch> Hi, On 23/02/15 18:13, Honza Horak wrote:> I'm about to submit a couple of requests into bugs.c.o to create > necessary infrastructure for collections from RHSCL-1.2 at least. > But first I want to make sure about the tag and branches names. > > Currently we have some testing build tags: > scl6-el6-mariadb100-build > scl7-el7-mariadb100-build > and branches in dist-git (in sclo project): > scl-mariadb100-el6 > scl-mariadb100-el7 > And the SIG has codename 'sclo'.. > So, it's kind of messy already in the beginning :) > > Thinking about keeping it simple and uniform, what about this way: > > Keep 'sclo' as SIG codename to indicate it's combination of SCL on > openness :) I am ok, it makes more sense. > CBS build tags in format like: > sclo6-mariadb100-build > sclo7-mariadb100-build We need to keep the disttag in the name as agreed from the beginning for all SIGs: sclo6-el6-mariadb100-build sclo7-el7-mariadb100-build (scol7-el7_1-mariadb-build maybe ; However I don't remember if the SIG agreed to have 1 disttag only per distribution policy even for rhscl rebuild; which is the way to go if you ask me :). The disttag can be some other string not containing major; e.g: .infra. I need a way to parse it consistently and existing scripts have been written this way. > and branches in dist-git (in both sclo and rpms projects): > sclo6-mariadb100 > sclo7-mariadb100 Fine with me, centpkg will do the matching between branches and targets. However, I would wait feedback from the git specialists. thanks, -- Thomas. From bstinson at ksu.edu Mon Feb 23 19:54:29 2015 From: bstinson at ksu.edu (Brian Stinson) Date: Mon, 23 Feb 2015 13:54:29 -0600 Subject: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL In-Reply-To: <54EB5FB2.5090306@redhat.com> References: <54EB5FB2.5090306@redhat.com> Message-ID: <20150223195429.GE14329@hopper.math.ksu.edu> On Feb 23 18:13, Honza Horak wrote: > I'm about to submit a couple of requests into bugs.c.o to create necessary > infrastructure for collections from RHSCL-1.2 at least. > But first I want to make sure about the tag and branches names. > > Currently we have some testing build tags: > scl6-el6-mariadb100-build > scl7-el7-mariadb100-build > and branches in dist-git (in sclo project): > scl-mariadb100-el6 > scl-mariadb100-el7 > And the SIG has codename 'sclo'.. > So, it's kind of messy already in the beginning :) > > Thinking about keeping it simple and uniform, what about this way: > > Keep 'sclo' as SIG codename to indicate it's combination of SCL on openness > :) +1 from me on this. It makes sense to use the actual sig codename. > CBS build tags in format like: > sclo6-mariadb100-build > sclo7-mariadb100-build > and branches in dist-git (in both sclo and rpms projects): > sclo6-mariadb100 > sclo7-mariadb100 In the client tools, there shouldn't be anything that would hold this up. As long as we remain consistent we can make the mappings work. > > This mail is to check whether we're fine to go this way or if there are some > limitations we need to follow. > > dist-git and CBS gurus, please, provide your PoV. Thanks! > > Honza Is your proposal to rename the existing mariadb tags and git branches? --Brian From hhorak at redhat.com Tue Feb 24 07:47:48 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 24 Feb 2015 08:47:48 +0100 Subject: [scl.org] CBS build tags and git branches names for SCL In-Reply-To: <54EB81FD.3010601@cern.ch> References: <54EB5FB2.5090306@redhat.com> <54EB81FD.3010601@cern.ch> Message-ID: <54EC2CA4.2050206@redhat.com> On 02/23/2015 08:39 PM, Thomas Oulevey wrote: > > CBS build tags in format like: > > sclo6-mariadb100-build > > sclo7-mariadb100-build > > We need to keep the disttag in the name as agreed from the beginning for > all SIGs: > sclo6-el6-mariadb100-build > sclo7-el7-mariadb100-build OK, understood. > (scol7-el7_1-mariadb-build maybe ; However I don't remember if the SIG > agreed to have 1 disttag only per distribution policy even for rhscl > rebuild; which is the way to go if you ask me :). > > The disttag can be some other string not containing major; e.g: .infra. > > I need a way to parse it consistently and existing scripts have been > written this way. There is one piece I'm struggling with (and I'm not sure if that's the same thing you call special disttag for rhscl rebuild). It is how to deal with conflicting NVRs in koji (supposing CBS koji also doesn't allow two build tasks resulting into the same NVR). When we build some SRPM first in sclo project and then import the same SRPM to rpms project (so we're able to build it from SCM, sign it and release), then koji build will fail, because we already have the same NVR built from SRPM, right? I'm thinking if we can solve this by disttag, so e.g. every build from SRPM would get something like ".el6.test" and only SCM builds would get ".el6". As far as I understand koji, that would require another build target, right? Maybe there is some nicer way to handle this or you may convince me we don't need to solve this at all and just handle it with release bumps. (just thinking loudly now) Honza From rcollet at redhat.com Tue Feb 24 08:53:20 2015 From: rcollet at redhat.com (Remi Collet) Date: Tue, 24 Feb 2015 09:53:20 +0100 Subject: [scl.org] Workflow for Software Collections (SCLs) in CentOS In-Reply-To: <54EB66F6.50301@redhat.com> References: <54EB66F6.50301@redhat.com> Message-ID: <54EC3C00.2010607@redhat.com> Le 23/02/2015 18:44, Honza Horak a ?crit : > This proposal considers the following: > * we want to provide stable SCLs rebuilt from RHSCL for CentOS users > * we want to have a platform for upstream development for collections > that: > - will be part of the future RHSCL (same SCL name as in RHSCL uses, > RH developers own those, others may contribute -- send patches) > - have been part of RHSCL but will get some update eventually, so we > want to test the fixes before applying in RHSCL > - are not intended for RHSCL (those won't use "rh-" prefix [2], but > should have some other prefix) > > > Some technical details of CentOS Build Service (CBS) at [3] > ============================================================================= > > There are several projects in centos distgit (http://git.centos.org), > those two are important for SCL: > * sclo -- code of testing packages, uses fedora layout (specfile and > sources directly in the repository, no directories), building rpms in > CBS only from srpm, final rpms are testing only (tagged into sclX-testing) > * rpms -- code of stable packages, centos layout (specfile and sources > in SPECS, SOURCES directories), building rpms in CBS either from srpm or > from scm, possible to build official rpms (tagged into sclX-release, > request signing and releasing) > > There are two koji tags set for all collections for every elX version (X > is 6, 7, ...el6, el7, ...): > * sclX-testing: default tag where all built srpms are tagged into > * sclX-release: only rpms built from scm can be tagged here (and will > be signed) > > > Workflow schema: > ================ > > git.c.o CBS scl.org [1] > ----------------------------------------- > develop in > sclo project > | \ > | \ > | build from srpm > | for testing only > | | > | | > | rpm tagged into > | sclX-testing > | \ > | \ > | available in > | sclo-testing > | repo > | > | > import srpm > into rpms > project > \ > \ > build release > candidate > from scm > | > | > tagged into > sclX-testing > \ > \ > available in > sclo-testing > repo > / > / > tag into > sclX-release > sign & release > \ > \ > available in > sclo-stable > repo > > > Description of the scheme above > =============================== > Workflow during development phase: > ---------------------------------- > * this part is valid for future RHSCL collections that (both net new > and major update) are not yet available in RHSCL > * contributors prepare new collection under sclo project > * contributors build testing rpms from srpm > * rpms are tagged into sclX-testing > * scl.org [1] imports specific collections from sclX-testing > > Workflow during maintainance phase: > -------------------------------- > * this part is valid for collections that are/were released > * contributors prepare patches under sclo project to test them before > applying (in RHSCL or non-RH stable SCL) -- fix smaller bugs, extend > stable collection in compatible mode, generally maintain compatibility > of the collection > * contributors build testing rpms from srpm > * rpms are tagged into sclX-testing > * srpms are manually imported from sclo to rpms project @ git.c.o > * contributors build official packages from scm and tag them into > sclX-release > * contributors ask for signing and publishing > * scl.org imports specific collections from sclX-release and > potentially also from sclX-testing > > Specific for RH collections: > ---------------------------- > srpm can be automatically imported to rpms project or even to sclo > project on errata publishing if maintainer wishes so Question about NEVR The NEVR (in the spec) will probably be the same in the devel phase (git/sclo) and after (git/rpms). Isn't this going to be a problem ? Does the %{?dist} need to be different ? I think Koji will not accept a build with the same NEVR. > Some open questions > =================== > Q: scl.org to provide a separate repository for each collection? or one > repository for all collections in -testing? > Proposal: we can start with one common repository for all stable centos > collections, the same we do in RHSCL? +1 for a single repository, else it will be a nightmare for use of dependent collection (ex php55 / httpd24) > > Q: what about centos vs epel? > Proposal: if there are some packages that want to use centos collections > in the future, epel should start to build above centos' sclo repos. EPEL build against RHEL, so should build against RHSCL. Remi > That > means the same collections don't need to be build again in epel. How is > it done in other centos SIGs in case they provide the same components in > epel? > > [1] https://www.softwarecollections.org/en/scls/ > [2] https://www.redhat.com/archives/sclorg/2015-February/msg00022.html > [3] http://cbs.centos.org > > Honza > > _______________________________________________ > 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 Tue Feb 24 09:46:35 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 24 Feb 2015 10:46:35 +0100 Subject: [scl.org] Workflow for Software Collections (SCLs) in CentOS In-Reply-To: <54EC3C00.2010607@redhat.com> References: <54EB66F6.50301@redhat.com> <54EC3C00.2010607@redhat.com> Message-ID: <54EC487B.9020207@redhat.com> On 02/24/2015 09:53 AM, Remi Collet wrote: > Le 23/02/2015 18:44, Honza Horak a ?crit : >> Specific for RH collections: >> ---------------------------- >> srpm can be automatically imported to rpms project or even to sclo >> project on errata publishing if maintainer wishes so > > Question about NEVR > > The NEVR (in the spec) will probably be the same in the devel phase > (git/sclo) and after (git/rpms). > Isn't this going to be a problem ? > Does the %{?dist} need to be different ? > > I think Koji will not accept a build with the same NEVR. > That's true. It's also mentioned in another thread about CBS build tags and git branches names for SCL: https://www.redhat.com/archives/sclorg/2015-February/msg00027.html I've proposed a different disttag for testing RPMs there, but not sure if there is a better way. >> >> Q: what about centos vs epel? >> Proposal: if there are some packages that want to use centos collections >> in the future, epel should start to build above centos' sclo repos. > > EPEL build against RHEL, so should build against RHSCL. Ah, good point, so we wouldn't be able to build anything against non-RH collections. Or for non-RH collections, those would have to be re-built in EPEL. Honza From hhorak at redhat.com Wed Feb 25 14:41:02 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 25 Feb 2015 15:41:02 +0100 Subject: [scl.org] On demand CentOS SCLo SIG sync-up meeting on #centos-devel (2015-02-25) Message-ID: <54EDDEFE.5000803@redhat.com> WG meeting should 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. By "on demand" I mean I don't have any agenda, but will be around on the #centos-devel during that time, just if anybody wants to discuss anything.. for example some specifics about git branches/repos and CBS tags naming I've sent to the mailing list. Honza From hhorak at redhat.com Wed Feb 25 17:14:21 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 25 Feb 2015 18:14:21 +0100 Subject: [scl.org] [CentOS-devel] CBS build tags and git branches names for SCL In-Reply-To: <54EC2CA4.2050206@redhat.com> References: <54EB5FB2.5090306@redhat.com> <54EB81FD.3010601@cern.ch> <54EC2CA4.2050206@redhat.com> Message-ID: <54EE02ED.1050007@redhat.com> On 02/24/2015 08:47 AM, Honza Horak wrote: > On 02/23/2015 08:39 PM, Thomas Oulevey wrote: >> > CBS build tags in format like: >> > sclo6-mariadb100-build >> > sclo7-mariadb100-build >> >> We need to keep the disttag in the name as agreed from the beginning for >> all SIGs: >> sclo6-el6-mariadb100-build >> sclo7-el7-mariadb100-build > > OK, understood. > >> (scol7-el7_1-mariadb-build maybe ; However I don't remember if the SIG >> agreed to have 1 disttag only per distribution policy even for rhscl >> rebuild; which is the way to go if you ask me :). >> >> The disttag can be some other string not containing major; e.g: .infra. >> >> I need a way to parse it consistently and existing scripts have been >> written this way. > > There is one piece I'm struggling with (and I'm not sure if that's the > same thing you call special disttag for rhscl rebuild). It is how to > deal with conflicting NVRs in koji (supposing CBS koji also doesn't > allow two build tasks resulting into the same NVR). > > When we build some SRPM first in sclo project and then import the same > SRPM to rpms project (so we're able to build it from SCM, sign it and > release), then koji build will fail, because we already have the same > NVR built from SRPM, right? > > I'm thinking if we can solve this by disttag, so e.g. every build from > SRPM would get something like ".el6.test" and only SCM builds would get > ".el6". As far as I understand koji, that would require another build > target, right? > > Maybe there is some nicer way to handle this or you may convince me we > don't need to solve this at all and just handle it with release bumps. > (just thinking loudly now) 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? Honza From hhorak at redhat.com Thu Feb 26 12:02:36 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 26 Feb 2015 13:02:36 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? Message-ID: <54EF0B5C.5060508@redhat.com> 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). I've heard a serious critic of this *inconsistency* today from our QE -- using 'scls' under /etc/opt and /var/opt, but not in /opt. And I admit I agree with them, even though I haven't paid much attention to that inconsistency before. This 'scls' part probably comes from the Fedora draft [1], but realize that in that draft 'scls' is also used under /opt/. I can't find any reasoning for this 'scls' directory, I can only assume it was used to distinguish SCL technology from other possible technologies utilizing /opt in the future. 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. On the other hand, if we find out in the future, that this distinguishing is necessary, we'll need to do it not only in the files paths, but also in the RPM names, so the 'scl' would need to be used in the collection name itself.. At any case, 'scls' should be removed from the paths /etc/opt/ and /var/opt/. [1] http://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29 Honza From lkardos at redhat.com Thu Feb 26 12:18:42 2015 From: lkardos at redhat.com (Lubos Kardos) Date: Thu, 26 Feb 2015 07:18:42 -0500 (EST) Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <54EF0B5C.5060508@redhat.com> References: <54EF0B5C.5060508@redhat.com> Message-ID: <536596139.15942501.1424953122237.JavaMail.zimbra@redhat.com> Have a look at bug #1066665 especially at comment 8. Lubos ----- Original Message ----- > From: "Honza Horak" > To: sclorg at redhat.com, "Lubos Kardos" > Cc: "Lukas Zachar" , "Petr Splichal" , "Jan Zelen?" > Sent: Thursday, February 26, 2015 1:02:36 PM > Subject: Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? > > 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). > > I've heard a serious critic of this *inconsistency* today from our QE -- > using 'scls' under /etc/opt and /var/opt, but not in /opt. And I admit I > agree with them, even though I haven't paid much attention to that > inconsistency before. > > This 'scls' part probably comes from the Fedora draft [1], but realize > that in that draft 'scls' is also used under /opt/. > > I can't find any reasoning for this 'scls' directory, I can only assume > it was used to distinguish SCL technology from other possible > technologies utilizing /opt in the future. > > 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. > > On the other hand, if we find out in the future, that this > distinguishing is necessary, we'll need to do it not only in the files > paths, but also in the RPM names, so the 'scl' would need to be used in > the collection name itself.. At any case, 'scls' should be removed from > the paths /etc/opt/ and /var/opt/. > > [1] http://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29 > > Honza > From hhorak at redhat.com Thu Feb 26 12:26:10 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 26 Feb 2015 13:26:10 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <536596139.15942501.1424953122237.JavaMail.zimbra@redhat.com> References: <54EF0B5C.5060508@redhat.com> <536596139.15942501.1424953122237.JavaMail.zimbra@redhat.com> Message-ID: <54EF10E2.9090803@redhat.com> On 02/26/2015 01:18 PM, Lubos Kardos wrote: > Have a look at bug #1066665 especially at comment 8. Ok, that's what I supposed, but see that the comment speaks about /opt/fedora/scls as well, which is not in scl-utils. So, what we have now is some half-way solution. Another possibility is to add 'scls' to /opt/rh/ in case %nfsmountable is defined. Honza > Lubos > > ----- Original Message ----- >> From: "Honza Horak" >> To: sclorg at redhat.com, "Lubos Kardos" >> Cc: "Lukas Zachar" , "Petr Splichal" , "Jan Zelen?" >> Sent: Thursday, February 26, 2015 1:02:36 PM >> Subject: Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? >> >> 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). >> >> I've heard a serious critic of this *inconsistency* today from our QE -- >> using 'scls' under /etc/opt and /var/opt, but not in /opt. And I admit I >> agree with them, even though I haven't paid much attention to that >> inconsistency before. >> >> This 'scls' part probably comes from the Fedora draft [1], but realize >> that in that draft 'scls' is also used under /opt/. >> >> I can't find any reasoning for this 'scls' directory, I can only assume >> it was used to distinguish SCL technology from other possible >> technologies utilizing /opt in the future. >> >> 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. >> >> On the other hand, if we find out in the future, that this >> distinguishing is necessary, we'll need to do it not only in the files >> paths, but also in the RPM names, so the 'scl' would need to be used in >> the collection name itself.. At any case, 'scls' should be removed from >> the paths /etc/opt/ and /var/opt/. >> >> [1] http://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29 >> >> Honza >> From rcollet at redhat.com Thu Feb 26 15:09:21 2015 From: rcollet at redhat.com (Remi Collet) Date: Thu, 26 Feb 2015 16:09:21 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <54EF0B5C.5060508@redhat.com> References: <54EF0B5C.5060508@redhat.com> Message-ID: <54EF3721.3030402@redhat.com> Le 26/02/2015 13:02, Honza Horak a ?crit : > 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). > > I've heard a serious critic of this *inconsistency* today from our QE -- > using 'scls' under /etc/opt and /var/opt, but not in /opt. And I admit I > agree with them, even though I haven't paid much attention to that > inconsistency before. > > This 'scls' part probably comes from the Fedora draft [1], but realize > that in that draft 'scls' is also used under /opt/. Yes, I also think this is related to this old draft. > I can't find any reasoning for this 'scls' directory, I can only assume > it was used to distinguish SCL technology from other possible > technologies utilizing /opt in the future. > > 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. > > On the other hand, if we find out in the future, that this > distinguishing is necessary, we'll need to do it not only in the files > paths, but also in the RPM names, so the 'scl' would need to be used in > the collection name itself.. At any case, 'scls' should be removed from > the paths /etc/opt/ and /var/opt/. I also prefer to drop this 'scls' from /etcopt and /var/opt (rather than adding it to /opt/rh path) NOTICE: I hope this will not become another blocker if we plan to submit against SCL Guildelines to FPC... perhaps we should ask FPC. Remi; > > [1] http://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29 > > Honza > > _______________________________________________ > 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 jorton at redhat.com Thu Feb 26 16:22:10 2015 From: jorton at redhat.com (Joe Orton) Date: Thu, 26 Feb 2015 16:22:10 +0000 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <54EF0B5C.5060508@redhat.com> References: <54EF0B5C.5060508@redhat.com> Message-ID: <20150226162210.GA18334@redhat.com> 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. Regards, Joe From hhorak at redhat.com Thu Feb 26 18:16:28 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 26 Feb 2015 19:16:28 +0100 Subject: [scl.org] Removing 'scls' from %{_sysconfdir} and %{_localstatedir}? In-Reply-To: <20150226162210.GA18334@redhat.com> References: <54EF0B5C.5060508@redhat.com> <20150226162210.GA18334@redhat.com> Message-ID: <54EF62FC.6060405@redhat.com> 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. 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 From hhorak at redhat.com Thu Feb 26 19:28:43 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 26 Feb 2015 20:28:43 +0100 Subject: [scl.org] Names under /var/opt, /etc/opt In-Reply-To: <54E329D8.4010705@redhat.com> References: <54E329D8.4010705@redhat.com> Message-ID: <54EF73EB.9010901@redhat.com> After some discussions with QE that preferred variant (B) as well and since there is no opinion that would prefer variant (A), lets call this a decision. Something based on the summary bellow will be added into the documentation [1]: TL;DR version, this is the correct location for files for sample package foo in fooX collection: original locations (in sample non-SCL package): /var/log/foo/food.log /var/lock/subsys/food /var/run/food.pid locations in fooX SCL: /var/opt//scls/fooX/log/foo/food.log /var/lock/subsys/fooX-food /var/run/fooX-food.pid Longer text, which may be added to the doc [1]: Configuration and variable files locations depend on %{nfsmountable} macro. Using this macro is strongly recommended, but for backward compatibility it is not defined by default. If the %{nfsmountable} macro is not defined, %{_sysconfdir} expands into /opt///root/etc and %{_localstatedir} expands to /opt///root/var. If the %{nfsmountable} macro is defined, %{_sysconfdir} expands into /etc/opt//scls/ and %{_localstatedir} expands to /var/opt//scls/. Software Collection Log File Support: Log files should be located in %{_localstatedir}/log/ where does not contain any other SCL prefixes any more. For example, if daemon foo stores the log file into /var/log/foo/food.log in the base system and the macro %{nfsmountable} is defined, the path in the fooX collection will be /var/opt//scls/fooX/log/foo/food.log. Software Collection Support for files under /var/run: PID files are one example of files usually located under /var/run/ directory. In the Software Collection the recommended PID file location is to use /var/run/- directory, so there are no conflicts with files shipped by packages from the base system, but Software Collection can use features of /var/run, for example tmpfs filesystem for pid files. Software Collection Support for SysV init lock files: SysV init files require to use lock files under /var/lock/subsys while the file under that directory is usually the same as the service name. Since service name is already prefixed by SCL name, we can use the same rule for SCL packages, since using the daemon name under /var/lock/subsys will ensure the lock file won't conflict with the base system lock files. [1] https://www.softwarecollections.org/en/docs/guide/ Honza On 02/17/2015 12:45 PM, Honza Horak wrote: > This is about files under /var/opt and potentially /etc/opt when we use > %nfsmountable in new scl-utils. Basic question: do we want to prefix > file names in cases the location path already includes the SCL name? > > Simple answer would be "no, it's not needed". (variant B) > > However, there is another PoV -- pid files, log files, lock files, etc. > have been traditionally called the same as the daemon, so someone can > assume this convention will be kept in SCLs (variant A) > > So, how it looks in practice: > > variant A) > Keeping the pid/log files names the same as the daemon: > /var/opt/rh/scls/rh-mariadb100/log/mariadb/rh-mariadb100-mariadb.log > /var/opt/rh/scls/rh-mariadb100/run/rh-mariadb100-mariadb/rh-mariadb100-mariadb.pid > > > variant B) > If we don't include prefix (we break the convention), the location seems > nicer: > /var/opt/rh/scls/rh-mariadb100/log/mariadb/mariadb.log > /var/opt/rh/scls/rh-mariadb100/run/mariadb/mariadb.pid > > I like the (B) variant more, just keep it more simple and just break the > custom to name pid/log files the same as the deamon. > > However, I'd appreciate any input on this. > > Honza > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg