From hhorak at redhat.com Wed Jan 7 08:57:58 2015 From: hhorak at redhat.com (Honza Horak) Date: Wed, 07 Jan 2015 09:57:58 +0100 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-01-07) Message-ID: <54ACF516.4000202@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 * possible ways to build collections From hhorak at redhat.com Thu Jan 8 10:01:00 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 08 Jan 2015 11:01:00 +0100 Subject: [scl.org] Meeting log from CentOS SCLo SIG sync-up meeting on #centos-devel (2015-01-07) In-Reply-To: <54ACF516.4000202@redhat.com> References: <54ACF516.4000202@redhat.com> Message-ID: <54AE555C.6030105@redhat.com> ============================================ #centos-devel: SCLo SIG Sync-up (2015-01-07) ============================================ Meeting started by hhorak at 16:03:39 UTC. The full logs are available at centos-devel/2015/centos-devel.2015-01-07-16.03.log.html . Meeting summary --------------- * current status (hhorak, 16:05:18) * Current status (hhorak, 16:06:45) * LINK: https://www.softwarecollections.org/repos/rhscl/php55/epel-7-x86_64/php55-php-5.5.6-10.el7/ (Jeff_S, 16:41:13) * importing binary sources into lookaside cache is a feature coming to centpkg soon, bstinson is working on it (hhorak, 17:16:00) * build command for centpkg will come soon as well (hhorak, 17:16:00) * fedora-style layout is crutial to be able to use centos git as upstream (easy cherry-pick from/to rhel/fedora) (hhorak, 17:31:35) * having two formats in git.c.o does not bother us for now, since it is possible to generate a srpm from sclo/ project and import to rpm/ project (hhorak, 17:31:35) * buildroots in koji are already set up to have $collection-build in the buildroot and any other package may be added afterwards using koji add-group-pkg; this is necessary to have some scl macros defined early enough (hhorak, 17:31:35) * asking for changes in builroot will be done by creating a ticket to bugs.c.o (hhorak, 17:31:35) * IDEA: stop building/shipping scl packages on scl.org once they get build/shipped in centos koji (hhorak, 17:31:35) * IDEA: another way would be to start building all the collections in copr, that would solve many issues we have with koji right now (hhorak, 17:31:35) * building in copr is not possible because centos will never sign anything that didnt get built end to end here (hhorak, 17:31:35) * mariadb100 and mariadb sources should be ready to test in git.c.o (hhorak, 17:31:36) * ACTION: kbsingh will try to hack things up to build mariadb100 collection (and fix things on the way) (hhorak, 17:31:36) * if we're fine with one repository with all collections or we need more repositories with (stable, bleeding-edge) or (upstream, downstream) or whatever -- that's left to decide in the future, but we should ask community of users for advice while being careful about how we communicate this, and where we communicate it to (since people dont see the bleedingedge for what it is - they start to see the 'releseased' repo to be stable, test (hhorak, 17:31:37) Meeting ended at 17:31:55 UTC. Action Items ------------ * kbsingh will try to hack things up to build mariadb100 collection (and fix things on the way) Action Items, by person ----------------------- * kbsingh * kbsingh will try to hack things up to build mariadb100 collection (and fix things on the way) * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * hhorak (57) * kbsingh (57) * Jeff_S (25) * alphacc (20) * RemiFedora (14) * maxamillion (12) * Evolution (6) * bstinson (5) * jorton (5) * centbot (2) * TrevorH (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot From hhorak at redhat.com Thu Jan 8 16:40:42 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 08 Jan 2015 17:40:42 +0100 Subject: [scl.org] scl register script In-Reply-To: <54AE7E4D.8070906@redhat.com> References: <54AE7E4D.8070906@redhat.com> Message-ID: <54AEB30A.3070601@redhat.com> Moving this topic to sclorg at redhat.com since this is an example of a topic I'd like to see discussed there in public. It is related to the 'scl register' command, which is a scl-utils feature already available in [1]. Please, continue on sclorg at redhat.com ML. As for the idea, I like it as Jan proposed it and if nobody has objections we'll use that for new databases packages as well. As soon as we reach some conclusion here we should document it in the Guide [2] and maybe even mention it as good practice in the scl-utils doc/man/wherever register is documented? [1] https://github.com/sclorg/scl-utils [2] https://www.softwarecollections.org/en/docs/guide/ Honza -------- Forwarded Message -------- Subject: scl register script Date: Thu, 08 Jan 2015 13:55:41 +0100 From: Jan Kalu?a Hi, I was thinking about "scl register" script (/opt/rh/foo/register). This script is called when SCL is registered (as result of "scl register foo" command). There can be just single "register" script per collection. I think it would be better to have a directory (let's call it "register.d") where all packages in the collection could put their register scripts and the main register script (the one included in meta-package) would just call each script in this directory. This would handle following situations: - If we add new package/directory/file which has to be handled by the register script, we don't have to change the register script in the meta-package and rebuild it, because the responsible register script would be part of the updated package. - If we have for example httpd24 SCL, we want to copy httpd configuration into /etc/opt in the register script, but we want to do that *only* when httpd24-httpd package is installed. So to sum it up, I'm proposing following structure for the register/unregister scripts: /opt/rh/foo/register - owned by "foo", calls scripts in "register.d" /opt/rh/foo/register.d/foo-bar - owned by foo-bar, registers foo-bar subpackage of foo SCL. /opt/rh/foo/unregister - owned by "foo", calls scripts in "unregister.d" /opt/rh/foo/unregister.d/foo-bar - owned by foo-bar, unregisters foo-bar subpackage of foo SCL. Regards, Jan Kaluza From hhorak at redhat.com Thu Jan 8 16:57:23 2015 From: hhorak at redhat.com (Honza Horak) Date: Thu, 08 Jan 2015 17:57:23 +0100 Subject: [scl.org] scl register script In-Reply-To: <54AEB30A.3070601@redhat.com> References: <54AE7E4D.8070906@redhat.com> <54AEB30A.3070601@redhat.com> Message-ID: <54AEB6F3.8020400@redhat.com> Another thing that would deserve some best practice documented is where to store the files we want to work with in the register script. This is just a laud thinking about the location for such files, which should be also standardized and documented as a best practice after reaching some agreement. My proposal is to include them under /opt/rh/$SCLNAME/register-content and use path of the resulting location under this directory. An example for e.g. mariadb100 I have on my mind is the following: * having %nfsmountable macro defined, %_sysconfdif will expand to /etc/opt/rh/scls/mariadb100 during RPM build * my.cnf will then be installed into /etc/opt/rh/scls/mariadb100/my.cnf * when mounting /opt, my.cnf, init script or systemd file won't be available on NFS client, but we'd need it for the register script * these files have a copy under /opt/rh/mariadb100/register-content to have them available on the NFS client, specifically: /opt/rh/mariadb100/register-content/etc/opt/rh/scls/mariadb100/my.cnf /opt/rh/mariadb100/register-content/usr/lib/systemd/system/mariadb100-mariadb.service * the register script for mariadb100-mariadb-server just gets the files from /opt/rh/mariadb100/register-content and places them under their desired location: /etc/opt/rh/scls/mariadb100/my.cnf /usr/lib/systemd/system/mariadb100-mariadb.service Does it sound fine? Honza On 01/08/2015 05:40 PM, Honza Horak wrote: > Moving this topic to sclorg at redhat.com since this is an example of a > topic I'd like to see discussed there in public. It is related to the > 'scl register' command, which is a scl-utils feature already available > in [1]. Please, continue on sclorg at redhat.com ML. > > As for the idea, I like it as Jan proposed it and if nobody has > objections we'll use that for new databases packages as well. > > As soon as we reach some conclusion here we should document it in the > Guide [2] and maybe even mention it as good practice in the scl-utils > doc/man/wherever register is documented? > > [1] https://github.com/sclorg/scl-utils > [2] https://www.softwarecollections.org/en/docs/guide/ > > Honza > > > -------- Forwarded Message -------- > Subject: scl register script > Date: Thu, 08 Jan 2015 13:55:41 +0100 > From: Jan Kalu?a > > Hi, > > I was thinking about "scl register" script (/opt/rh/foo/register). This > script is called when SCL is registered (as result of "scl register foo" > command). > > There can be just single "register" script per collection. I think it > would be better to have a directory (let's call it "register.d") where > all packages in the collection could put their register scripts and the > main register script (the one included in meta-package) would just call > each script in this directory. > > This would handle following situations: > > - If we add new package/directory/file which has to be handled by the > register script, we don't have to change the register script in the > meta-package and rebuild it, because the responsible register script > would be part of the updated package. > > - If we have for example httpd24 SCL, we want to copy httpd > configuration into /etc/opt in the register script, but we want to do > that *only* when httpd24-httpd package is installed. > > So to sum it up, I'm proposing following structure for the > register/unregister scripts: > > /opt/rh/foo/register - owned by "foo", calls scripts in "register.d" > /opt/rh/foo/register.d/foo-bar - owned by foo-bar, registers foo-bar > subpackage of foo SCL. > > /opt/rh/foo/unregister - owned by "foo", calls scripts in "unregister.d" > /opt/rh/foo/unregister.d/foo-bar - owned by foo-bar, unregisters foo-bar > subpackage of foo SCL. > > Regards, > Jan Kaluza > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From jzeleny at redhat.com Fri Jan 9 15:27:56 2015 From: jzeleny at redhat.com (Jan =?ISO-8859-1?Q?Zelen=FD?=) Date: Fri, 09 Jan 2015 16:27:56 +0100 Subject: [scl.org] A new generation of Software Collections can come now Message-ID: <1769854.EyoUZjvIcC@boson.usersys.redhat.com> The scl-utils developer team is proud to present SCL 2.0! This new version brings revolution in the internal code structure but it also introduces a bunch of interesting enhancements in the run time part of scl-utils. Important note: most of these new features require proper support from collections themselves but first collections with such support should be here quite soon. We have also files a documentation bug so let's hope there is some documentation how to modify the collections soon. In the meantime, feel free to ask your questions here. Request: even though there was a non-public alpha release, this is still a version that needs a lot of testing so if you intend to build a collection with support of these cool new features, let us know if there are some problems. New commands: ============ list-collections: a new name for --list, implemented for consistency of the command line arguments list-packages: a new name for --list , same reason as above load: it will modify the shell in which the command is executed rather than creating a subshell unload: counterpart of the load command if you don't want to use the collection in current shell any more man: show man page of the entire collection New argument: ============ -x, --exec: when running a command with scl enable, use exec() call rather than system() (bug 1029964) Other: ============ Support in shebangs: it's possible to use scl enable in your shebang lines (the double dash command separator is required) Compatibility with environment modules: it was requested several times. This new version brings what you asked for. -- Jan Zeleny Engineering Supervisor Software Management team Red Hat Czech From hhorak at redhat.com Tue Jan 20 16:14:57 2015 From: hhorak at redhat.com (Honza Horak) Date: Tue, 20 Jan 2015 17:14:57 +0100 Subject: [scl.org] CentOS SCLo SIG sync-up meeting on #centos-devel (2015-01-21) Message-ID: <54BE7F01.6090106@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 * summarize the current work-flow to build collections * Fosdem plans From hhorak at redhat.com Fri Jan 23 07:37:45 2015 From: hhorak at redhat.com (Honza Horak) Date: Fri, 23 Jan 2015 08:37:45 +0100 Subject: [scl.org] Minutes from CentOS SCLo SIG sync-up meeting on #centos-devel (2015-01-21) In-Reply-To: <54BE7F01.6090106@redhat.com> References: <54BE7F01.6090106@redhat.com> Message-ID: <54C1FA49.2010809@redhat.com> Actually there are no nice minutes this time, because someone (who could be it, sorry guys) spoiled the meetbot hashes, so we only have the log: http://www.centos.org/minutes/2015/january/centos-devel.2015-01-21-16.03.log.html But these could be the most important stuff: To summarize the workflow for a virtual SCL packager Jerry: 1. Jerry becomes a member of scl sig and gets access to git under sclo project (ticket at bugs.centos.org) 2. Jerry develops/contributes to a collection under sclo/ namespace in git.centos.org 3. Jerry exports srpm and imports it into rpms/ git namespace (this uses a different git structure) 4. Jerry builds the collection in the rpms/ namespace and it may be considered official (5. scl.org may include links to those collections rather than collections built in copr, eventhough the copr may be still used to build "testing" collections directly from sclo/ namespace) Missing pieces to start so far: a. authtag -- thing that allows non-admin users to push/import srpms into rpms/ namespace (blocking, we cannot import srpms without it) b. centpkg build ready with all features hacked (blocking) c. centpkd feature that allows to do the (3) step easier -- export/import from sclo/ to rpms/ namespace (non-blocking) d. way to control acl by branch name for sig non-admin members by sig admins (non-blocking, everybody can be admin for beginning) importing to sclo should work fine with centpkg even with fedora layout rhscl-1.2 packages do not seem built yet, so those will be first pieces on the list to build no meeting the next week due travelling to fosdem Honza On 01/20/2015 05:14 PM, Honza Horak wrote: > WG meeting will be at 16:00 UTC (11:00 EST, 17:00 Brno, 11:00 Boston, > 1:00+1d Tokyo, 2:00+1d Brisbane) in #centos-devel on Freenode. > > = Topics = > * current status > * summarize the current work-flow to build collections > * Fosdem plans > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg From tina.simmons at encore-deals.com Thu Jan 29 06:58:03 2015 From: tina.simmons at encore-deals.com (Tina Simmons) Date: Thu, 29 Jan 2015 12:28:03 +0530 Subject: [scl.org] B2B prospects Message-ID: Hi, Good day to you! I hope you are the right person to discuss about Database which includes complete contact details and Tele-verified Email addresses. License to global (North America, Europe, UK, Asia Pacific, Middle East and African) leads with Email address and Phone numbers along with SIC and ZIP codes. 1. IT Executives List CIO, CTO, CISO, IT-VP, IT-Director, IT Manager, MIS Manager, etc 2. Mining and Metals Coal mining, Copper mining, Gold mining, Lead mining, Salt mining, Silver mining, Tin mining, Uranium mining, etc 3. Information Technology Computer Hardware, Software, and IT Resellers (Value Added Resellers), etc 4. Technology Users SAP, MS Users, Oracle, ERP, CRM, Sage, Accounting Software, VM ware, etc 5. Health-care Industry Hospitals, Clinics, Physicians and Doctors, Nurses, Specialists, etc 6. Finance & Banking Insurance Agents, Banks, Financial Services, Credit Agency, Mortgage Bankers, etc 7. Marketing Professionals Lists CMO, VP of Marketing, Director of Marketing, Marketing Manager, etc 8. Business Intelligence Networking software, IT security software, Database application users list, etc 9. Automotive Industry Automobile dealers, New & Used Car Dealers, Used Car Dealers, etc 10. Manufacturing Industry Food, Kindred Products, Textile, Apparel, Furniture, Fixtures, etc 11. HR Professionals List VP of HR, HR Director & HR Manager, etc 12. Education Industry Schools, College, University, Teachers, K-12 education, etc 13. Construction Real estate, Architectural firms, Power and Energy, Electrical, Transportation, etc 14. Waste management and recycling Recycling bin, plastic recycling, recycling ecological, etc 15.All C-level executives List CEO, CFO, CIO, CTO, CMO, CISO, CSO, COO, CNO, etc 16. CRM users list MS Dynamic CRM, MS Exchange Server, Siebel, SAP CRM, Sales force, IBM Lotus, Goldmine, Sage Sales logic, etc Data Fields: Company Name, Company Website, Contact Full Name, Contact Job Title, Verified Email Address, Complete Mailing Address, Telephone Number, Fax Number, Revenue Size, Employee Size, SIC Code, Industry Type and many more. Let me know your exact target market (Industries, Job Titles and Geography). So that I can provide you more details accordingly. Thanks and I look forward to hear from you soon. Best Regards, Tina Simmons 702-664-7542 If you are not interested in receiving further emails, please reply back with "LEAVEOUT" in the subject line". -------------- next part -------------- An HTML attachment was scrubbed... URL: