From Jaroslaw.Polok at cern.ch Fri Dec 2 22:33:37 2016 From: Jaroslaw.Polok at cern.ch (Jarek Polok) Date: Fri, 2 Dec 2016 23:33:37 +0100 Subject: [scl.org] New Collection for CentOS 7 - pidgin with Voice and Video / Skype for Business integration ? Message-ID: <1554778d-d2c4-08c9-e3ce-9ccc87cdeb0f@cern.ch> Hello all We are working on a software collection for our organization: pidgin messenger with voice/video enabled allowing for integration with Lync / Skype for Business IM/Voice/Video/File Transfer/Desktop Sharing/Conference: http://cern.ch/linux/docs/lyncav.shtml (a rather preliminary build, kind of proof of concept, packages quality to be improved, but rather functional ..) It uses the code from: https://github.com/tieto/ (patched farstream2/ remmina/freerdp/libnice/pidgin/sipe) plus few packages from Fedora 25 (gstreamer1/gupnp/AV codecs etc). We could contribute this and include in CentOS SCls (if there is some interest of course), however there might be a small problem here: among all the packages needed there is a h264 video decoder based on ffmpeg required for Skype for Business video stream decoding (packages: ffmpeg/ gstreamer1-libav/gstreamer1-plugins-ugly): my understanding is that ffmpeg based packages were not included in Fedora/Red Hat due to legal/licensing reasons - and therefore I assume these would not be included in CentOS either, is that correct ? The option could be to provide all other packages and point users to a 3rd party repository (alike rpmfusion or nux-dextop.. etc) for h264 decoding functionality (but still we would need to provide gstreamer1-plugins-ugly package which needs to be built against ffmpeg/gstreamer1-libav .. which could be problematic to build in cbs.centos.org as would require access to 3rd party repos in build system...) Is this something we could contribute ? I would be glad to hear your opinion. Best Regards Jarek From Fedora at FamilleCollet.com Mon Dec 5 15:01:19 2016 From: Fedora at FamilleCollet.com (Remi Collet) Date: Mon, 5 Dec 2016 16:01:19 +0100 Subject: [scl.org] [SCLo SIG] new sclo-php* packages available for testing Message-ID: Yet another small set of packages available in centos-sclo-sclo-testing For rh-php56: * sclo-php56-php-pecl-geoip-1.1.1-1 (CentOS 7 only) * sclo-php56-php-pecl-solr2-2.4.0-1 (CentOS 6 and 7) For rh-php70: * sclo-php70-php-pecl-geoip-1.1.1-1 (CentOS 7 only) * sclo-php70-php-pecl-solr2-2.4.0-1 (CentOS 6 and 7) More packages will come later, according to user requests. Remi. P.S. https://wiki.centos.org/SpecialInterestGroup/SCLo _______________________________________________ SCLorg mailing list SCLorg at redhat.com https://www.redhat.com/mailman/listinfo/sclorg From hhorak at redhat.com Mon Dec 5 21:31:53 2016 From: hhorak at redhat.com (Honza Horak) Date: Mon, 5 Dec 2016 22:31:53 +0100 Subject: [scl.org] [CentOS-devel] New SCL packages for CentOS available for testing In-Reply-To: References: Message-ID: <517ab833-fed6-ce47-6982-c49889b189a8@redhat.com> On 11/22/2016 10:53 AM, Farkas Levente wrote: > On Mon, Nov 21, 2016 at 11:11 PM, Honza Horak > wrote: > > We still haven't finished rebuilding of the following two new SCLs > that are part of RHSCL 2.3: > > rh-thermostat16 > rh-eclipse46 > > > what is the estimated plan for these repos? > thanks. It looks good now, they should be available on buildlogs tomorrow. Honza > -- > Levente "Si vis pacem para bellum!" > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg > From stefanrin at gmail.com Tue Dec 6 10:54:49 2016 From: stefanrin at gmail.com (Stefan Ring) Date: Tue, 6 Dec 2016 11:54:49 +0100 Subject: [scl.org] Bootstrapping devtoolset? Message-ID: Is there a method for bootstrapping devtoolset (-3, -4)? I used to be able to build everything in a mock for devtoolset-2, but for the newer ones I find that they seem to have cyclic build dependencies where most builds want to pull in everything that would only be available after the successful build (currently stuck at rh-java-common). How was the bootstrapping done? From mizdebsk at redhat.com Tue Dec 6 11:05:28 2016 From: mizdebsk at redhat.com (Mikolaj Izdebski) Date: Tue, 6 Dec 2016 12:05:28 +0100 Subject: [scl.org] Bootstrapping devtoolset? In-Reply-To: References: Message-ID: <06978e69-f8c4-0881-3655-04f64f062499@redhat.com> On 12/06/2016 11:54 AM, Stefan Ring wrote: > Is there a method for bootstrapping devtoolset (-3, -4)? I used to be > able to build everything in a mock for devtoolset-2, but for the newer > ones I find that they seem to have cyclic build dependencies where > most builds want to pull in everything that would only be available > after the successful build (currently stuck at rh-java-common). > > How was the bootstrapping done? Java collections were typically bootstrapped by using older packages from other collections or from RHEL. Specifically, rh-java-common was built using maven30 RPMs and maven30 was built using RHEL 7 content. CentOS bootstraps SCLs by using external repositories with prebuilt RPMs, like this one: http://cbs.centos.org/koji/externalrepoinfo?extrepoID=11 -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk From stefanrin at gmail.com Tue Dec 6 13:48:35 2016 From: stefanrin at gmail.com (Stefan Ring) Date: Tue, 6 Dec 2016 14:48:35 +0100 Subject: [scl.org] Bootstrapping devtoolset? In-Reply-To: <06978e69-f8c4-0881-3655-04f64f062499@redhat.com> References: <06978e69-f8c4-0881-3655-04f64f062499@redhat.com> Message-ID: On Tue, Dec 6, 2016 at 12:05 PM, Mikolaj Izdebski wrote: > Java collections were typically bootstrapped by using older packages > from other collections or from RHEL. Specifically, rh-java-common was > built using maven30 RPMs and maven30 was built using RHEL 7 content. > > CentOS bootstraps SCLs by using external repositories with prebuilt > RPMs, like this one: > http://cbs.centos.org/koji/externalrepoinfo?extrepoID=11 Unfortunately I cannot see what?s inside this repository or some siblings I've tried (access denied). Does it basically contain the same packages as the final sclo repo or are there some hand-tweaked packages aimed at getting through a bootstrap? I guess that bootstrapping was a manual process with lots of dirty hacks and workarounds ;). Is this a good impression of how it went? From mizdebsk at redhat.com Thu Dec 8 10:06:45 2016 From: mizdebsk at redhat.com (Mikolaj Izdebski) Date: Thu, 8 Dec 2016 11:06:45 +0100 Subject: [scl.org] Bootstrapping devtoolset? In-Reply-To: References: <06978e69-f8c4-0881-3655-04f64f062499@redhat.com> Message-ID: <6b28d1eb-c6e7-36b3-6c2a-654d68b37828@redhat.com> On 12/06/2016 02:48 PM, Stefan Ring wrote: > On Tue, Dec 6, 2016 at 12:05 PM, Mikolaj Izdebski wrote: >> Java collections were typically bootstrapped by using older packages >> from other collections or from RHEL. Specifically, rh-java-common was >> built using maven30 RPMs and maven30 was built using RHEL 7 content. >> >> CentOS bootstraps SCLs by using external repositories with prebuilt >> RPMs, like this one: >> http://cbs.centos.org/koji/externalrepoinfo?extrepoID=11 > > Unfortunately I cannot see what?s inside this repository or some > siblings I've tried (access denied). Does it basically contain the > same packages as the final sclo repo or are there some hand-tweaked > packages aimed at getting through a bootstrap? I don't know, I don't have access either. Bug I guess these could be RHSCL packages. > I guess that bootstrapping was a manual process with lots of dirty > hacks and workarounds ;). Is this a good impression of how it went? Oh yes :) And it still required using pre-built binaries from older releases or products. -- Mikolaj Izdebski Software Engineer, Red Hat IRC: mizdebsk From hhorak at redhat.com Thu Dec 8 12:33:19 2016 From: hhorak at redhat.com (Honza Horak) Date: Thu, 8 Dec 2016 13:33:19 +0100 Subject: [scl.org] Bootstrapping devtoolset? In-Reply-To: <6b28d1eb-c6e7-36b3-6c2a-654d68b37828@redhat.com> References: <06978e69-f8c4-0881-3655-04f64f062499@redhat.com> <6b28d1eb-c6e7-36b3-6c2a-654d68b37828@redhat.com> Message-ID: <5341f2fa-0740-7ea8-f147-5e2c0e74b091@redhat.com> On 12/08/2016 11:06 AM, Mikolaj Izdebski wrote: > On 12/06/2016 02:48 PM, Stefan Ring wrote: >> On Tue, Dec 6, 2016 at 12:05 PM, Mikolaj Izdebski wrote: >>> Java collections were typically bootstrapped by using older packages >>> from other collections or from RHEL. Specifically, rh-java-common was >>> built using maven30 RPMs and maven30 was built using RHEL 7 content. >>> >>> CentOS bootstraps SCLs by using external repositories with prebuilt >>> RPMs, like this one: >>> http://cbs.centos.org/koji/externalrepoinfo?extrepoID=11 >> >> Unfortunately I cannot see what?s inside this repository or some >> siblings I've tried (access denied). Does it basically contain the >> same packages as the final sclo repo or are there some hand-tweaked >> packages aimed at getting through a bootstrap? > > I don't know, I don't have access either. Bug I guess these could be > RHSCL packages. It used copr builds for bootstrapping (rebuilt twice in cbs to get rid of any external consequences). The packages should be probably still accessible: https://copr.fedorainfracloud.org/coprs/hhorak/devtoolset-4-rebuild-bootstrap/ But since we now have centos builds, I don't see reason to not use those for bootstrapping. Honza >> I guess that bootstrapping was a manual process with lots of dirty >> hacks and workarounds ;). Is this a good impression of how it went? > > Oh yes :) And it still required using pre-built binaries from older > releases or products. > From noah at coderanger.net Tue Dec 13 17:21:13 2016 From: noah at coderanger.net (Noah Kantrowitz) Date: Tue, 13 Dec 2016 09:21:13 -0800 Subject: [scl.org] Broken URLs In-Reply-To: <897743E8-B1A2-4006-8634-C1A65907AFF0@contoso.com> References: <897743E8-B1A2-4006-8634-C1A65907AFF0@contoso.com> Message-ID: <6BBEBA34-8CCA-4269-B952-6CE1F7322C9B@coderanger.net> This was fixed in poise-python with the 1.5.0 release several months ago, and I should have done it long before that because the SCLo team warned me many times that I was installing things in an unsupported way. Unfortunately the new way requires using RHSCL on RHEL, as I'm not sure there is a great way to cross-install the SCLo/CentOS SCL packages on RHEL, but it is on my list to revisit when I get some cycles. --Noah > On Nov 22, 2016, at 9:55 AM, Flory,Clem wrote: > > We use Software Collections in our build system, to install Python 2.7 on RHEL. This morning, our builds stopped working, due to the Python URL returning a 404 error -https://www.softwarecollections.org/en/scls/rhscl/python27/epel-6-x86_64/download/rhscl-python27-epel-6-x86_64.noarch.rpm. Is there any way to get this URL working again? We are using Chef Enterprise, with the poise-python cookbook, which uses Software Collections to install Python. > > Let me know if you need any more information. > > > Thanks, > > Clem Flory > Software Architect, Lights On Network > clem.flory at cerner.com | www.cerner.com > CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) (816)221-1024. > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://www.redhat.com/mailman/listinfo/sclorg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From hhorak at redhat.com Tue Dec 13 20:45:02 2016 From: hhorak at redhat.com (Honza Horak) Date: Tue, 13 Dec 2016 21:45:02 +0100 Subject: [scl.org] Using EPEL packages as deps for SCLo collections Message-ID: There are cases where some dependencies don't need to be converted into SCL and also can be shared across more SCLs. We discussed this topic on today's meeting and the following proposal is the outcome: https://wiki.centos.org/SpecialInterestGroup/SCLo#head-764a73d1d09cb348661406560ee2140b6f5b9477 Please, provide feedback if you have some. Honza From ncoghlan at redhat.com Wed Dec 14 11:07:22 2016 From: ncoghlan at redhat.com (Nick Coghlan) Date: Wed, 14 Dec 2016 21:07:22 +1000 Subject: [scl.org] Support and update life cycle In-Reply-To: <3e98b2c0-7390-3d80-7769-31f082f0ec1f@tobipage.de> References: <3e98b2c0-7390-3d80-7769-31f082f0ec1f@tobipage.de> Message-ID: On Wed, Nov 16, 2016 at 6:12 PM, Tobias Bergmann wrote: > So the question is: Will there be updates of sclorg packages as long as > the main version of redhat el gets updates? The commercial support lifecycle details for Red Hat Software Collections are here: https://access.redhat.com/support/policy/updates/rhscl As that says, "New versions will be available only during the Red Hat Enterprise Linux Production 1 Phase. ", which is around 5 1/2 years after release, and ends in late 2019 for RHEL 7: https://access.redhat.com/support/policy/updates/errata The specific collections *within* the overall SCL release can also change over time - for example, the PHP 5.6 collection is currently listed with a projected EOL of April 2018, while the PHP 7.0 collection has a projected EOL of November 2019. Any assumptions about availability beyond those dates would currently be speculation, but assuming past patterns continued, there would be newer PHP SCLs released between now and 2019, so a supported version would remain available for some time beyond that. Regards, Nick. -- Nick Coghlan Red Hat Platform Engineering, Brisbane From stefanrin at gmail.com Sun Dec 18 10:16:33 2016 From: stefanrin at gmail.com (Stefan Ring) Date: Sun, 18 Dec 2016 11:16:33 +0100 Subject: [scl.org] Bootstrapping devtoolset? In-Reply-To: References: Message-ID: On Tue, Dec 6, 2016 at 11:54 AM, Stefan Ring wrote: > Is there a method for bootstrapping devtoolset (-3, -4)? I used to be > able to build everything in a mock for devtoolset-2, but for the newer > ones I find that they seem to have cyclic build dependencies where > most builds want to pull in everything that would only be available > after the successful build (currently stuck at rh-java-common). After having gone through all the trouble of rebuilding rh-java-common and maven30, I noticed that there is a set of devtoolset-6-* packages now which do not depend on any of that Java cruft and are straightforward to build :). From Fedora at FamilleCollet.com Thu Dec 29 12:49:03 2016 From: Fedora at FamilleCollet.com (Remi Collet) Date: Thu, 29 Dec 2016 13:49:03 +0100 Subject: [scl.org] [SCLo SIG] new sclo-php*-pecl-igbinary packages available for testing Message-ID: <9aaf2f60-38f3-7fd0-fb10-c6b188544966@FamilleCollet.com> Yet another package available in centos-sclo-sclo-testing For rh-php56: * sclo-php56-php-pecl-igbinary-2.0.1-1 For rh-php70: * sclo-php70-php-pecl-igbinary-2.0.1-1 More packages are evaluated on user requests. Remi. P.S. https://wiki.centos.org/SpecialInterestGroup/SCLo