From daniel.davis at nih.gov Mon May 10 16:30:07 2021 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Mon, 10 May 2021 16:30:07 +0000 Subject: [scl.org] Is Software Collections abandoned? In-Reply-To: References: Message-ID: <74E6F165-2BB5-4162-871A-4E0A7770F2B7@nih.gov> CentOS 8 is not going to keep up with RHEL 8, and this is a big issue for many systems groups. You should read up on that to see how that affects you. The latest for CentOS 7 are in http://mirror.centos.org/centos-7/7/sclo/. I think the site is frozen in time, not really abandoned. ?On 5/10/21, 12:26 PM, "sclorg-bounces at redhat.com on behalf of Peter Oliver" wrote: I notice that at https://www.softwarecollections.org/ you can find plenty of CentOS 6 packages (with failing builds), but no CentOS 8 packages or containers. If I want to move from CentOS 7 to CentOS 8, should I be looking for an alternative reliable source of packages and containers? -- Peter Oliver _______________________________________________ SCLorg mailing list SCLorg at redhat.com https://listman.redhat.com/mailman/listinfo/sclorg From John.Beranek at pamediagroup.com Mon May 10 16:34:09 2021 From: John.Beranek at pamediagroup.com (John Beranek) Date: Mon, 10 May 2021 16:34:09 +0000 Subject: [scl.org] Are the software collections for MySQL57 and MySQL80 based on the community editions or the enterprise edititons In-Reply-To: <4CE47AE5-6AE6-4271-842F-C5785D2167AC@soundtransit.org> References: <4CE47AE5-6AE6-4271-842F-C5785D2167AC@soundtransit.org> Message-ID: If you want to pay for Oracle's MySQL, I'd suggest you visit https://www.mysql.com/buy-mysql/ Cheers, John From: sclorg-bounces at redhat.com On Behalf Of Vaughan, Wendre Sent: 04 December 2020 21:32 To: sclorg at redhat.com Subject: [scl.org] Are the software collections for MySQL57 and MySQL80 based on the community editions or the enterprise edititons My server engineering team is hoping that the RH software collections for MySQL57 and MySQL80 are based on the enterprise MySQL editions (not open source) and contain the enterprise MySQL Backup utility. Could you confirm what the base edition of MySQL is for the MySQL software collections? Wendre Vaughan Senior Software Engineer, Operations | Information Technology | Sound Transit P: 206.903.7270 | F: 206.398.5223 | e: wendre.vaughan at soundtransit.org Connect with us https://www.facebook.com/SoundTransit | https://twitter.com/SoundTransit [signature_403692348] This email is from the PA Media Group. For more information, see www.pamediagroup.com. This email may contain confidential information. Only the addressee is permitted to read, copy, distribute or otherwise use this email or any attachments. If you have received it in error, please contact the sender immediately. Any opinion expressed in this email is personal to the sender and may not reflect the opinion of the PA Media Group. Any email reply to this address may be subject to interception or monitoring for operational reasons or for lawful business practices. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4032 bytes Desc: image001.png URL: From jonathan.mercier at cnrgh.fr Mon May 10 16:59:46 2021 From: jonathan.mercier at cnrgh.fr (jonathan mercier) Date: Mon, 10 May 2021 18:59:46 +0200 Subject: [scl.org] Is Software Collections abandoned? In-Reply-To: <74E6F165-2BB5-4162-871A-4E0A7770F2B7@nih.gov> References: <74E6F165-2BB5-4162-871A-4E0A7770F2B7@nih.gov> Message-ID: I am interested too on this topic for RHEL and fedora usage.? Indeed SCL cover our needs. We know they are ?Application stream? but they are any documentation on how to make a such package. And ?Application stream? do not cover the same needs. Thanks for more information on this topic Best regards, Jonathan Le lundi 10 mai 2021 ? 16:30 +0000, Davis, Daniel (NIH/NLM) [C] a ?crit?: > CentOS 8 is not going to keep up with RHEL 8, and this is a big issue > for many systems groups.? You should read up on that to see how that > affects you. > > The latest for CentOS 7 are in > http://mirror.centos.org/centos-7/7/sclo/.?? I think the site is > frozen in time, not really abandoned. > > > ?On 5/10/21, 12:26 PM, "sclorg-bounces at redhat.com?on behalf of Peter > Oliver" p.d.oliver at mavit.org.uk> wrote: > > ??? I notice that at https://www.softwarecollections.org/?you can > find plenty of CentOS 6 packages (with failing builds), but no CentOS > 8 packages or containers. > > ??? If I want to move from CentOS 7 to CentOS 8, should I be looking > for an alternative reliable source of packages and containers? > > ??? -- > ??? Peter Oliver > > ??? _______________________________________________ > ??? SCLorg mailing list > ??? SCLorg at redhat.com > ??? https://listman.redhat.com/mailman/listinfo/sclorg > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://listman.redhat.com/mailman/listinfo/sclorg -- ? ? ? ? ? ? ? ? Researcher computational biology ??????????????? PhD, Jonathan MERCIER ? ? ? ? ? ?? ??????????????? Bioinformatics (LBI) ??????????????? 2, rue Gaston ??????????????? Cr?mieux ??????????????? 91057 Evry Cedex ???????????? ???????????? ??????????????? Tel :(+33)1 60 87 83 44 ??????????????? Email :jonathan.mercier at cnrgh.fr ???????????????? ???????????? From stefanrin at gmail.com Tue May 11 09:52:43 2021 From: stefanrin at gmail.com (Stefan Ring) Date: Tue, 11 May 2021 11:52:43 +0200 Subject: [scl.org] devtoolset-6 and stdlibc++ In-Reply-To: References: Message-ID: On Mon, May 10, 2021 at 6:25 PM Matthew Wheaton wrote: > > > Hi, > > This can't be the first time this has come up. I was very pleased to discover that I could install the gcc-6.3 compiler on a rhel6 host using devtoolset-6, but now discover that the accompanying stdlibc++ is not included. > > I provide shared libraries as part of an API for my work and it would be greatly beneficial to provide a runtime environment that includes the libraries that come with gcc-6.3. Unless the customer can use a rhel8 equivalent, this is the best way to provide C++11 functionality that I know of. > > Is there a way to provide the appropriate stdlibc++? The binaries produced by devtoolset are supposed to run against the system runtime (libstdc++), so there is nothing else to be shipped. It sounds like you would want to just build gcc yourself (it?s easy!) Then you will need to ship the runtime with the binaries produced by it. From jstanek at redhat.com Tue May 11 10:37:25 2021 From: jstanek at redhat.com (=?UTF-8?Q?Jan_Stan=C4=9Bk?=) Date: Tue, 11 May 2021 10:37:25 +0000 Subject: [scl.org] Node 12 Support In-Reply-To: <97E8C737-3136-482C-B278-0FA6EB32BB1A@gtri.gatech.edu> References: <97E8C737-3136-482C-B278-0FA6EB32BB1A@gtri.gatech.edu> Message-ID: Hello, current rh-nodejs12 packages should be available on mirrors (i.e. [1]). The scl.org web has stale information, I've not been doing a very good job in keeping it up-to-date. In case you are wondering about EOL and stuff, these should be the same as for RedHat collections [2]. Hope this helps! [1]: http://mirror.centos.org/centos/7/sclo/x86_64/rh/Packages/r/rh-nodejs12-nodejs-12.21.0-1.el7.x86_64.rpm [2]: https://access.redhat.com/support/policy/updates/rhscl-rhel7 -- Jan Stan?k Software Engineer, Red Hat jstanek at redhat.com irc: jstanek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jstanek at redhat.com Tue May 11 10:47:59 2021 From: jstanek at redhat.com (=?UTF-8?Q?Jan_Stan=C4=9Bk?=) Date: Tue, 11 May 2021 10:47:59 +0000 Subject: [scl.org] MariaDB-10.5.9 package required in repo- rhscl for RHEL7.9 In-Reply-To: References: Message-ID: Hi, I'm not sure what you want to do. 1. If you want to install the "official" MariaDB RPMs provided by MariaDB foundation, reach to them for support ? not really anything we can help you with there. 2. If you want to use rhscl RPMs for MariaDB, there is rh-mariadb105 collection, which currently include version 10.5.8. Use that as any other collection: # yum install rh-mariadb105 # scl enable rh-mariadb105 -- $SHELL Hope this helps! -- Jan Stan?k Software Engineer, Red Hat jstanek at redhat.com irc: jstanek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jstanek at redhat.com Tue May 11 10:54:48 2021 From: jstanek at redhat.com (=?UTF-8?Q?Jan_Stan=C4=9Bk?=) Date: Tue, 11 May 2021 10:54:48 +0000 Subject: [scl.org] ubi8/nodejs14 update request In-Reply-To: References: Message-ID: Hi Jim, Jim Knochelmann writes: > https://access.redhat.com/security/cve/CVE-2020-8277 which shows that > CVE-2020-8277 has not yet been fixed. If I'm seeing correctly, nodejs:14 is listed there as "Fixed" via RHSA-2021:0551 [1] released on 2021-02-16. The errata mentions an upgrade of Node to 14.15.4, and the container contains version 14.16.1, so it looks to me as fixes already :) [1]: https://access.redhat.com/errata/RHSA-2021:0551 -- Jan Stan?k Software Engineer, Red Hat jstanek at redhat.com irc: jstanek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From jstanek at redhat.com Tue May 11 11:14:24 2021 From: jstanek at redhat.com (=?UTF-8?Q?Jan_Stan=C4=9Bk?=) Date: Tue, 11 May 2021 11:14:24 +0000 Subject: [scl.org] Is Software Collections abandoned? In-Reply-To: References: <74E6F165-2BB5-4162-871A-4E0A7770F2B7@nih.gov> Message-ID: Hi all, currently, I'm not aware of any collections planned for CentOS 8; modularity/AppStream is the prefferred way forward. Since RedHat does not support collections on RHEL 8, it would take a community effort to update and maintain the scaffolding in CentOS 8. Given that these days I think I'm the only semi-active member of the SCLo SIG, I would not hold my breath. Of course, If you are willing to try and put in the work, try joining the SIG [1] and start figuring out what exactly is needed. [1]: https://wiki.centos.org/SpecialInterestGroup/SCLo -- Jan Stan?k Software Engineer, Red Hat jstanek at redhat.com irc: jstanek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From smooge at gmail.com Tue May 11 12:12:13 2021 From: smooge at gmail.com (Stephen John Smoogen) Date: Tue, 11 May 2021 08:12:13 -0400 Subject: [scl.org] Is Software Collections abandoned? In-Reply-To: References: <74E6F165-2BB5-4162-871A-4E0A7770F2B7@nih.gov> Message-ID: On Tue, 11 May 2021 at 07:14, Jan Stan?k wrote: > Hi all, > currently, I'm not aware of any collections planned for CentOS 8; > modularity/AppStream is the prefferred way forward. > > Since RedHat does not support collections on RHEL 8, it would take a > community > effort to update and maintain the scaffolding in CentOS 8. Given that > these days I think I'm the only semi-active member of the SCLo SIG, > I would not hold my breath. > > Of course, If you are willing to try and put in the work, > try joining the SIG [1] and start figuring out what exactly is needed. > > So Red Hat does and does not seem to support collections on RHEL-8. The CentOS Stream of 8 ships with two software collections gcc-toolset-9 and gcc-toolset-10 which are newer gcc collections than the base one. However it doesn't seem they have other tools needed to make software collections in 8 so work would be needed to update and maintain the scaffolding. > [1]: https://wiki.centos.org/SpecialInterestGroup/SCLo > -- > Jan Stan?k > Software Engineer, Red Hat > jstanek at redhat.com irc: jstanek > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://listman.redhat.com/mailman/listinfo/sclorg > -- Stephen J Smoogen. I've seen things you people wouldn't believe. Flame wars in sci.astro.orion. I have seen SPAM filters overload because of Godwin's Law. All those moments will be lost in time... like posts on BBS... time to reboot. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcollet at redhat.com Tue May 11 13:59:29 2021 From: rcollet at redhat.com (Remi Collet) Date: Tue, 11 May 2021 15:59:29 +0200 Subject: [scl.org] Is Software Collections abandoned? In-Reply-To: References: <74E6F165-2BB5-4162-871A-4E0A7770F2B7@nih.gov> Message-ID: <31fdcfda-1f92-7631-d8d7-dc5e18d660ed@redhat.com> > On Tue, 11 May 2021 at 07:14, Jan Stan?k > wrote: > Hi all, > currently, I'm not aware of any collections planned for CentOS 8; > modularity/AppStream is the prefferred way forward. Le 11/05/2021 ? 14:12, Stephen John Smoogen a ?crit : > So Red Hat does and does not seem to support collections on RHEL-8. The > CentOS Stream of 8 ships with two software collections gcc-toolset-9 and > gcc-toolset-10 which are newer gcc collections than the base one. "scl-utils" is still available in RHEL-8 (and CentOS-8) So, it is possible to build Software collections For ex, I'm used to build PHP 5.6 to 8.0 as SCL for RHEL-8 [1] But, indeed, GCC 9 and 10 are the only ones maintained by RH and modularity is the new way (for now) to provides new versions of applications / languages. Notice: but scl-utils in Fedora is broken and doesn't work anymore Remi [1] as I think SCL, allowing multiple versions to be installed simultaneously, is a great feature, very valuable for dev -- 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 ksa at slac.stanford.edu Tue May 11 14:25:37 2021 From: ksa at slac.stanford.edu (Amrhein, Karl) Date: Tue, 11 May 2021 14:25:37 +0000 Subject: [scl.org] Is Software Collections abandoned? In-Reply-To: <31fdcfda-1f92-7631-d8d7-dc5e18d660ed@redhat.com> References: <74E6F165-2BB5-4162-871A-4E0A7770F2B7@nih.gov> , <31fdcfda-1f92-7631-d8d7-dc5e18d660ed@redhat.com> Message-ID: <35CE2B06-E759-4EF4-AA4C-7EEB401432A4@slac.stanford.edu> > But, indeed, GCC 9 and 10 are the only ones maintained by RH > and modularity is the new way (for now) to provides new > versions of applications / languages. Providing newer versions of apps is only one feature of SCL. The killer feature of SCL is to have multiple versions of apps installed *simultaneously*. For a multi user Linux host, this is a requirement, and modularity is not a replacement for SCL. When you have thousands of users, it?s not a choice of GCC 9 or 10, the requirement is GCC 9 *and* 10. > [1] as I think SCL, allowing multiple versions to be installed > simultaneously, is a great feature, very valuable for dev For many customers, including us, allowing multiple versions to be installed simultaneously is a requirement for production. Modularity is great for what it does, but it is *not* a replacement for SCL, unless it can allow for multiple versions of a package to be installed simultaneously. We need modularity AND SCL. From daniel.davis at nih.gov Tue May 11 15:33:09 2021 From: daniel.davis at nih.gov (Davis, Daniel (NIH/NLM) [C]) Date: Tue, 11 May 2021 15:33:09 +0000 Subject: [scl.org] Is Software Collections abandoned? In-Reply-To: <31fdcfda-1f92-7631-d8d7-dc5e18d660ed@redhat.com> References: <74E6F165-2BB5-4162-871A-4E0A7770F2B7@nih.gov> <31fdcfda-1f92-7631-d8d7-dc5e18d660ed@redhat.com> Message-ID: > But, indeed, GCC 9 and 10 are the only ones maintained by RH > and modularity is the new way (for now) to provides new > versions of applications / languages. Then there seems to be a need to maintain a parallel to AppStreams in a distribution planned to mirror RHEL8, RockyLinux. I know yum is used to enable modules and install things, but are these rpms? It sounds like maybe or maybe not with other Linuxes implementing run anywhere packages such as AppImage. ? From fnasser at redhat.com Tue May 11 16:29:23 2021 From: fnasser at redhat.com (Fernando Nasser) Date: Tue, 11 May 2021 12:29:23 -0400 Subject: [scl.org] Is Software Collections abandoned? In-Reply-To: <35CE2B06-E759-4EF4-AA4C-7EEB401432A4@slac.stanford.edu> References: <74E6F165-2BB5-4162-871A-4E0A7770F2B7@nih.gov> <31fdcfda-1f92-7631-d8d7-dc5e18d660ed@redhat.com> <35CE2B06-E759-4EF4-AA4C-7EEB401432A4@slac.stanford.edu> Message-ID: <5a76ac79-7b1c-1b16-40f4-ca9969289f69@redhat.com> On 2021-05-11 10:25 a.m., Amrhein, Karl wrote: >> But, indeed, GCC 9 and 10 are the only ones maintained by RH >> and modularity is the new way (for now) to provides new >> versions of applications / languages. > Providing newer versions of apps is only one feature of SCL. > > The killer feature of SCL is to have multiple versions of apps installed *simultaneously*. For a multi user Linux host, this is a requirement, and modularity is not a replacement for SCL. I keep having to explain this over and over again. modularity and SCL are orthogonal, serve different purposes.? Modularity does not preclude the need of SCL (or vice-versa) Another important feature is allow a software and its dependencies to be installed without interfering with the system-installed packages, or even packages from another layered software.? These may not only need different versions of dependencies than the ones installed by the OS (by any modules available even) and the software may have a life-cycle completely different from the OS so updates do not happen at the same time. > > When you have thousands of users, it?s not a choice of GCC 9 or 10, the requirement is GCC 9 *and* 10. > >> [1] as I think SCL, allowing multiple versions to be installed >> simultaneously, is a great feature, very valuable for dev > For many customers, including us, allowing multiple versions to be installed simultaneously is a requirement for production. > > Modularity is great for what it does, but it is *not* a replacement for SCL, unless it can allow for multiple versions of a package to be installed simultaneously. > > We need modularity AND SCL. > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://listman.redhat.com/mailman/listinfo/sclorg From pkubat at redhat.com Wed May 12 10:30:23 2021 From: pkubat at redhat.com (Petr Kubat) Date: Wed, 12 May 2021 12:30:23 +0200 Subject: [scl.org] ubi8/nodejs14 update request In-Reply-To: References: Message-ID: Hi Jim, as was already said, the CVE fix already shipped (I guess your mail was stuck in some moderation queue?) and the image rebuilt to incorporate the fix. So just for the record - the grade of the image only gets dropped when the CVE is actually fixed in the specific RHEL or RHSCL version and will drop lower the longer it takes to rebuild the image to add the CVE fix in. If there is a known vulnerability but the fix for it is not yet shipped, then the images will stay in grade A. HTH, Petr On 2/8/21 10:08 PM, Jim Knochelmann wrote: > Hello, > I am interested in a version bump to image > https://catalog.redhat.com/software/containers/ubi8/nodejs-14/5ed7887dd70cc50e69c2fabb > > . > There?seems to be a discrepancy between?the "security" tab, which is > reporting a health index of "A" with no problems, and Red Hat's > security info for nodejs 14 on RHEL 8: > https://access.redhat.com/security/cve/CVE-2020-8277 > which shows > that CVE-2020-8277 has not yet been fixed.? Is CVE-2020-8277 a > security concern?? It is possible that I am just interpreting the > reports incorrectly. > If you are available on IBM slack, I am up at @JimKnochelmann . > Thank you, > Jim Knochelmann > Software Engineer > IBM Watson - Natural Language Understanding > +1 (720) 515-4454 > jim.knochelmann at ibm.com > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://listman.redhat.com/mailman/listinfo/sclorg -------------- next part -------------- An HTML attachment was scrubbed... URL: From Pramod.Tomar at team.telstra.com Thu May 13 02:03:14 2021 From: Pramod.Tomar at team.telstra.com (Tomar, Pramod) Date: Thu, 13 May 2021 02:03:14 +0000 Subject: [scl.org] MariaDB-10.5.9 package required in repo- rhscl for RHEL7.9 In-Reply-To: References: Message-ID: Hi Jan, Thanks for reaching out? I had upgraded the mariadb from 5.5 to 10.3.27 on RHEL 7.9. I just need the latest stable release of mariadb on rhscl repo. I tried to execute the steps given by you, however no luck!! [root at pcaveIPNDprx1 ~]# yum install rh-mariadb105 Loaded plugins: changelog, langpacks, product-id, search-disabled-repos, subscription-manager rhel-7-server-rpms | 2.0 kB 00:00:00 rhel-server-rhscl-7-rpms | 2.0 kB 00:00:00 (1/4): rhel-7-server-rpms/7Server/x86_64/updateinfo | 3.9 MB 00:00:00 (2/4): rhel-server-rhscl-7-rpms/7Server/x86_64/updateinfo | 1.1 MB 00:00:00 (3/4): rhel-server-rhscl-7-rpms/7Server/x86_64/primary | 4.0 MB 00:00:00 (4/4): rhel-7-server-rpms/7Server/x86_64/primary | 51 MB 00:00:02 rhel-7-server-rpms 31775/31775 rhel-server-rhscl-7-rpms 13120/13120 No package rh-mariadb105 available. Error: Nothing to do [root at pcaveIPNDprx1 ~]# scl enable rh-mariadb105 -- $SHELL Unable to open /etc/scl/conf/rh-mariadb105! ===================================================================================== I used below repo= rhel-server-rhscl-7-rpms earlier to upgrade the mariadb successfully to 10.3.27. Can we add the 10.5.8 or 10.5.9 to this repo please? [root at yahoovahoo ~]# yum --disablerepo="*" --enablerepo="rhel-server-rhscl-7-rpms" install rh-mariadb103-mariadb-* Loaded plugins: changelog, langpacks, product-id, search-disabled-repos, subscription-manager rhel-server-rhscl-7-rpms | 2.0 kB 00:00:00 Package 3:rh-mariadb103-mariadb-server-10.3.27-1.el7.x86_64 already installed and latest version Package 3:rh-mariadb103-mariadb-errmsg-10.3.27-1.el7.x86_64 already installed and latest version Package 3:rh-mariadb103-mariadb-10.3.27-1.el7.x86_64 already installed and latest version Package 3:rh-mariadb103-mariadb-config-10.3.27-1.el7.x86_64 already installed and latest version Package 3:rh-mariadb103-mariadb-server-utils-10.3.27-1.el7.x86_64 already installed and latest version Package 3:rh-mariadb103-mariadb-common-10.3.27-1.el7.x86_64 already installed and latest version Resolving Dependencies --> Running transaction check ---> Package rh-mariadb103-mariadb-backup.x86_64 3:10.3.27-1.el7 will be installed ---> Package rh-mariadb103-mariadb-backup-syspaths.x86_64 3:10.3.27-1.el7 will be installed . . . . Installed: rh-mariadb103-mariadb-backup.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-backup-syspaths.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-config-syspaths.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-connect-engine.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-devel.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-gssapi-server.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-java-client.noarch 0:2.4.1-2.el7 rh-mariadb103-mariadb-java-client-javadoc.noarch 0:2.4.1-2.el7 rh-mariadb103-mariadb-oqgraph-engine.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-server-galera.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-server-galera-syspaths.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-server-syspaths.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-server-utils-syspaths.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-syspaths.x86_64 3:10.3.27-1.el7 rh-mariadb103-mariadb-test.x86_64 3:10.3.27-1.el7 Dependency Installed: copy-jdk-configs.noarch 0:3.3-10.el7_5 java-1.8.0-openjdk-headless.x86_64 1:1.8.0.282.b08-1.el7_9 javapackages-tools.noarch 0:3.4.1-11.el7 lksctp-tools.x86_64 0:1.0.17-2.el7 pcsc-lite-libs.x86_64 0:1.8.8-8.el7 python-javapackages.noarch 0:3.4.1-11.el7 rh-mariadb103-Judy.x86_64 0:1.0.5-14.el7 rh-mariadb103-galera.x86_64 0:25.3.31-1.el7 tzdata-java.noarch 0:2021a-1.el7 Complete! Thanks & Regards, Pramod Tomar +61-413189762 -----Original Message----- From: Jan Stan?k Sent: Tuesday, 11 May 2021 8:48 PM To: Tomar, Pramod Cc: sclorg at redhat.com Subject: Re: [scl.org] MariaDB-10.5.9 package required in repo- rhscl for RHEL7.9 [External Email] This email was sent from outside the organisation ? be cautious, particularly with links and attachments. Hi, I'm not sure what you want to do. 1. If you want to install the "official" MariaDB RPMs provided by MariaDB foundation, reach to them for support ? not really anything we can help you with there. 2. If you want to use rhscl RPMs for MariaDB, there is rh-mariadb105 collection, which currently include version 10.5.8. Use that as any other collection: # yum install rh-mariadb105 # scl enable rh-mariadb105 -- $SHELL Hope this helps! -- Jan Stan?k Software Engineer, Red Hat jstanek at redhat.com irc: jstanek -------------- next part -------------- An HTML attachment was scrubbed... URL: From jstanek at redhat.com Thu May 13 09:21:12 2021 From: jstanek at redhat.com (=?UTF-8?Q?Jan_Stan=C4=9Bk?=) Date: Thu, 13 May 2021 02:21:12 -0700 Subject: [scl.org] MariaDB-10.5.9 package required in repo- rhscl for RHEL7.9 In-Reply-To: References: Message-ID: Hi Pramod, sorry, my mistake ? the rh-mariadb105 is part of RHSCL-3.7, which is currently in beta and not yet released [1]. It should be coming out soon (some time in June, judging from previous releases). If you need it *now*, try the beta repo [2]: `rhel-server-rhscl-7-beta-rpms`. Please take a note that they are *beta* RPMs ? back up your data just in case, and be prepared to accomodate changes in release RPMs. [1]: https://access.redhat.com/documentation/en-us/red_hat_software_collections/3-beta/html/3.7_release_notes/chap-rhscl#sect-RHSCL-Changes-mariadb [2]: https://access.redhat.com/documentation/en-us/red_hat_software_collections/3-beta/html/3.7_release_notes/chap-installation#sect-Installation-Subscribe-RHSM -- Jan Stan?k Software Engineer, Red Hat jstanek at redhat.com irc: jstanek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rodrigoborgespereira at gmail.com Mon May 24 09:46:57 2021 From: rodrigoborgespereira at gmail.com (Rodrigo Borges Pereira) Date: Mon, 24 May 2021 10:46:57 +0100 Subject: [scl.org] PostgreSQL 10.17 and 12.7 Message-ID: Hello, Are these packages planned to be upgraded? Some CVE's were published for 10.15 and 12.5 and it would be really great to able to patch them using rh-postgresql10 and rh-postgresql12. Kind regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwheat5487 at gmail.com Tue May 25 02:22:51 2021 From: mwheat5487 at gmail.com (Matthew Wheaton) Date: Mon, 24 May 2021 22:22:51 -0400 Subject: [scl.org] Fwd: devtoolset-6 and libstdc++ revisited In-Reply-To: References: Message-ID: ---------- Forwarded message --------- From: Matthew Wheaton Date: Mon, May 24, 2021 at 10:04 PM Subject: devtoolset-6 and libstdc++ revisited To: New to this list thing, giving a simple email a try. Stephan was nice enough to answer my question prior to my joining the list and he was a big help. My original question was why the version of libstdc++ that goes with gcc-6.3 is not included in devtoolset-6. Answer: you don't need it. I have to admit, I can use the devtoolset-6 version of g++ and compile with the system libraries just fine. That's a revelation in itself. All compiles and all tests pass. This is great, I can use libstdc++.so.6.13 (rhel-6 native) and not worry about the missing symbol required by the gcc-6.3 libstdc++.so.22 (packaged with gcc-6.3). Note: this is just by setting the compile to point to the devtoolset-6 version of g++, I'm not even doing an 'scl enable'. COMPILER= But if I can get success by simply using a different compiler, why shouldn't I be able to do the same thing with the gcc-6.3 compiler I already have? How can I use the 6.3 compiler and point to the standard system libs in /usr/lib64? What do I have to do to separate this duo? Attempts at setting LIBRARY_PATH or LD_LIBRARY_PATH don't seem to work. To make matters more interesting, the build environment has the makefiles locked down pretty well. They are not intended to be edited in any way. There are a limited number of environment variables that the make sources, and that's about it. The build log shows that the '-L' flag is not used to determine the location of libstdc++ and the GNU documentation does not reveal how it picks up default libs. Can anyone point me in the right direction? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.georg at physik.uni-regensburg.de Tue May 25 08:57:06 2021 From: peter.georg at physik.uni-regensburg.de (Peter Georg) Date: Tue, 25 May 2021 10:57:06 +0200 Subject: [scl.org] [EXT] Fwd: devtoolset-6 and libstdc++ revisited In-Reply-To: References: Message-ID: I can actually not answer your questions, but at least point you to the Developer Toolset 6 Release Notes [1] for a high-level explanation why the Developer Toolset is not required at runtime: """ Some newer library features are statically linked into applications built with Red Hat Developer Toolset to support execution on multiple versions of Red Hat Enterprise Linux. This adds a small additional security risk because regular Red Hat Enterprise Linux errata would not change this code. If the need for developers to rebuild their applications due to such an issue arises, Red Hat will signal this in a security erratum. Developers are strongly advised not to statically link their entire application for the same reasons. """ However, I can not explain how this is done in detail. I suggest you have a closer look at /opt/rh/devtoolset-6/root/usr/lib/gcc/x86_64-redhat-linux/6.3.1/libstdc++.so Peter [1]: https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/6/html/6.0_release_notes/dts6.0_release#Known_Issues On 25/05/2021 04.22, Matthew Wheaton wrote: > > > ---------- Forwarded message --------- > From: *Matthew Wheaton* > > Date: Mon, May 24, 2021 at 10:04 PM > Subject: devtoolset-6 and libstdc++ revisited > To: > > > > New to this list thing, giving a simple email a try. > > Stephan was nice enough to answer my question prior to my joining the > list and he was a big help.? My original question was why the version of > libstdc++ that goes with gcc-6.3 is not included in devtoolset-6. > Answer:? you don't need it. > > I have to admit, I can use the devtoolset-6 version of g++ and compile > with the system libraries just fine.? That's a revelation in itself. > All compiles and all tests pass.? This is great, I can use > libstdc++.so.6.13 (rhel-6 native) and not worry about the missing symbol > required by the gcc-6.3 libstdc++.so.22 (packaged with gcc-6.3).? Note: > this is just by setting the compile to point to the devtoolset-6 version > of g++, I'm not even doing an 'scl enable'.? COMPILER= > > But if I can get success by simply using a different compiler, why > shouldn't I be able to do the same thing with the gcc-6.3 compiler I > already have?? How can I use the 6.3 compiler and point to the standard > system libs in /usr/lib64?? ?What do I have to do to separate this duo? > Attempts at setting LIBRARY_PATH or LD_LIBRARY_PATH don't seem to work. > > To make matters more interesting, the build environment has the > makefiles locked down pretty well.? They are not intended to be edited > in any way.? There are a limited number of environment?variables that > the make?sources, and that's about it.? The build log shows that the > '-L' flag is not used to determine the location of libstdc++ and the GNU > documentation does not reveal how it picks up default libs.? Can anyone > point me in the right direction? > > Thanks, > Matt > > > > > > _______________________________________________ > SCLorg mailing list > SCLorg at redhat.com > https://listman.redhat.com/mailman/listinfo/sclorg >