Re: [scl.org] Idea: Software Collections Daemons Made System-wide

[Davis, Daniel (NIH/NLM) [C]]

Amen to this.   I shipped an appliance install base on Pungi/Anaconda, but in 
my current role, I do not have root.
I found SCL and got what we needed without us having to build it ourself.

-Original Message-
From: sclorg-boun...@redhat.com [mailto:sclorg-boun...@redhat.com] On Behalf Of 
Griffin, Wesley (Fed)
Sent: Wednesday, March 22, 2017 10:49 AM
To: Honza Horak ; sclorg@redhat.com
Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide

My use case is for newer compilers and interpreters on development workstations.

I do not, however, manage my systems - our system administrator does that, so I 
work with him to get the SCL packages installed where necessary.

I am pretty confident that if I wanted to install an SCL package and it wrapped 
the system binary in some way he would refuse. He supports many more machines 
than just my development group and tries to maintain the same set of packages 
across all machines.

The beauty of SCL is that he can install it everywhere, but not affect anybody 
that doesn't opt-in. We have a similar setup for Intel compilers, Matlab, and 
other scientific software used in our organization.

So in that sense, adapting to a new approach would be troublesome, but only if 
it was the only approach. As long as the system binary wrappers are in 
subpackages which are optional, then I see no issues for us to continue using 
future SCL packages.

Thanks,
Wes


From: Honza Horak 
Sent: Wednesday, March 22, 2017 3:41:54 AM
To: Griffin, Wesley (Fed); sclorg@redhat.com
Subject: Re: [scl.org] Idea: Software Collections Daemons Made System-wide

I don't expect we'll do this for existing packages we provide, it's more a 
vision for new collections (e.g. mariadb 10.2 at some point).

Anyway, do you also see the same point for those upcoming collections (where 
we're not tight by keeping backward compatibility), e.g. because you're fine 
with all the SCL specifics and adapting to the new way would be troublesome?

Honza


On 03/22/2017 04:30 AM, Griffin, Wesley (Fed) wrote:
> I will chime in as the "old curmudgeon" - as long as you don't break the 
> existing use case, then I'm fine with any changes. The blog post says 
> subpackages will be used to ensure no breakage - I just want to re-iterate 
> that this is important and should not get lost if the proposal changes.
>
> Thanks,
> Wes
>
> 
> From: sclorg-boun...@redhat.com  on behalf 
> of Honza Horak 
> Sent: Tuesday, March 21, 2017 11:05:26 AM
> To: sclorg@redhat.com
> Subject: [scl.org] Idea: Software Collections Daemons Made System-wide
>
> This is basically a kick-off for getting more feedback for an idea 
> shared at 
> http://www.themindiseverything.eu/2017/03/software-collections-daemons-made.html.
>
> Shortly, SCL has worked nicely for several years and people love them.
> But even the beloved ones have some issues. And what we hear from 
> users, the issues with Software Collections concept currently are basically 
> those:
>
> * we need to use scl enable, which changes $PATH and other environment 
> variables, so the binaries placed in different location are visible by 
> the system
> * scripts originally written for "normal" MySQL use full paths (like
> /usr/bin/mysql) which does not work when we only have the Software 
> Collection installed
> * Data directory, config files and log files are on different location 
> than it is common
>
> The blog post tries to summarize possible solution, which I'm looking 
> for feedback now, ideally by replying to this mail..
>
> TIA,
> Honza
>
> ___
> SCLorg mailing list
> SCLorg@redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg
>
> ___
> SCLorg mailing list
> SCLorg@redhat.com
> https://www.redhat.com/mailman/listinfo/sclorg
>
>

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

[scl.org] Python "latest" SCLo

[Davis, Daniel (NIH/NLM) [C]]

I've been lurking on this list for a while, and I wanted to bring myself up to 
date.   I noticed some talk of a community SCL for a "latest" Python, which 
would be a non-patched pure build of Python that is kept up-to-date by the 
community.   Where is that at?   Who is leading it?   How can I help?

For background, we've used rh-python34 for some time, but our security team 
recently dinged us for sticking with Python 3.4.2, and my DevOps team (who have 
less time due to tickets), just recompiled Python 3.4.6 blind to get past the 
security problem.   I would have argued we should move to rh-python35, but that 
would eventually suffer the same problem.   What we need is a distribution that 
keeps up to date, but is still distributed as an rpm.

Thanks,

Dan Davis, Systems/Applications Architect (Contractor),
Office of Computer and Communications Systems,
National Library of Medicine, NIH

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

Re: [scl.org] Python "latest" SCLo

[Davis, Daniel (NIH/NLM) [C]]

So, maybe I've missed something, but is this more complicated than running 
rpmbuild with different Macros?I'm pretty good with rpms, but I know I 
don't always follow Fedora Packaging Guidelines.   I know that our DevOps guys 
will not want to submit builds to Copr, etc., and may not even use a local 
chroot to assure than BuildRequires is right.

However, if most of the time, they can download a tarball for Python, download 
the SRPM for rh-python34 or rh-python34, and then run rpmbuild with different 
options, they would probably be OK, and I could break the back of that work so 
that they have some wikis and local knowledge to go from.

This is how I complied with security guidelines when I did a lot of rpm 
building, but generally it was slightly simpler packages than Python.For 
instance, with Apache httpd, our customers network scanner would say, you are 
still running httpd X.Y.Z, and so I would pull the SRPM for httpd from Fedora 
16 (going back a ways), take a look at the required libraries and versions on 
Fedora 16, and compare with CentOS 6, then I would copy the tarball and adjust 
version macros for our own custom version of httpd, make sure to include 
Conflicts with the system package, and so on.

So, I understand that SCLs aren't the only way to have other versions, but SCLs 
prevent conflicts.   It gives RedHat customers a step between tarball and rpm 
that may conflict.That's what I'm looking for.

However, 
https://www.softwarecollections.org/en/docs/guide/#Creating_Your_Own_Software_Collections
 is somewhat imposing, even for me.   For our DevOps team, who normally deal 
with a little bash, a little ansible, and a lot of Jenkins, this is very 
imposing.

From: Brian Gollaher [mailto:bgoll...@redhat.com]
Sent: Thursday, June 29, 2017 12:52 PM
To: Davis, Daniel (NIH/NLM) [C] <daniel.da...@nih.gov>; sclorg@redhat.com
Subject: Re: [scl.org] Python "latest" SCLo

Yes, thanks Dan.  Many security scanning tools look for the latest version and 
flag older versions as being a potential risk.  I wanted to be sure that this 
is what is happening, rather than collections not receiving security updates 
fast enough and actually missing an important CVE.

On 06/29/2017 11:54 AM, Davis, Daniel (NIH/NLM) [C] wrote:
The DevOps team wants to update to the latest Python as a rule as a security 
from security mitigation technique.I hope that makes sense.

From: Brian Gollaher [mailto:bgoll...@redhat.com]
Sent: Thursday, June 29, 2017 11:50 AM
To: Davis, Daniel (NIH/NLM) [C] 
<daniel.da...@nih.gov><mailto:daniel.da...@nih.gov>; 
sclorg@redhat.com<mailto:sclorg@redhat.com>
Subject: Re: [scl.org] Python "latest" SCLo

Hi Dan.  May I ask a question?  Is your security team looking for a fix to a 
specific security problem or CVE or are they asking that you run the latest 
version as a rule?

thanks,
Brian

On 06/29/2017 11:24 AM, Davis, Daniel (NIH/NLM) [C] wrote:
I've been lurking on this list for a while, and I wanted to bring myself up to 
date.   I noticed some talk of a community SCL for a "latest" Python, which 
would be a non-patched pure build of Python that is kept up-to-date by the 
community.   Where is that at?   Who is leading it?   How can I help?

For background, we've used rh-python34 for some time, but our security team 
recently dinged us for sticking with Python 3.4.2, and my DevOps team (who have 
less time due to tickets), just recompiled Python 3.4.6 blind to get past the 
security problem.   I would have argued we should move to rh-python35, but that 
would eventually suffer the same problem.   What we need is a distribution that 
keeps up to date, but is still distributed as an rpm.

Thanks,

Dan Davis, Systems/Applications Architect (Contractor),
Office of Computer and Communications Systems,
National Library of Medicine, NIH






___

SCLorg mailing list

SCLorg@redhat.com<mailto:SCLorg@redhat.com>

https://www.redhat.com/mailman/listinfo/sclorg




--

Brian Gollaher

Red Hat Platform Product Management

Phone: 978 392-3173

Cell: 508 740-6549

bri...@redhat.com<mailto:bri...@redhat.com>



--

Brian Gollaher

Red Hat Platform Product Management

Phone: 978 392-3173

Cell: 508 740-6549

bri...@redhat.com<mailto:bri...@redhat.com>
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

Re: [scl.org] Python "latest" SCLo

[Davis, Daniel (NIH/NLM) [C]]

The DevOps team wants to update to the latest Python as a rule as a security 
from security mitigation technique.I hope that makes sense.

From: Brian Gollaher [mailto:bgoll...@redhat.com]
Sent: Thursday, June 29, 2017 11:50 AM
To: Davis, Daniel (NIH/NLM) [C] <daniel.da...@nih.gov>; sclorg@redhat.com
Subject: Re: [scl.org] Python "latest" SCLo

Hi Dan.  May I ask a question?  Is your security team looking for a fix to a 
specific security problem or CVE or are they asking that you run the latest 
version as a rule?

thanks,
Brian

On 06/29/2017 11:24 AM, Davis, Daniel (NIH/NLM) [C] wrote:
I've been lurking on this list for a while, and I wanted to bring myself up to 
date.   I noticed some talk of a community SCL for a "latest" Python, which 
would be a non-patched pure build of Python that is kept up-to-date by the 
community.   Where is that at?   Who is leading it?   How can I help?

For background, we've used rh-python34 for some time, but our security team 
recently dinged us for sticking with Python 3.4.2, and my DevOps team (who have 
less time due to tickets), just recompiled Python 3.4.6 blind to get past the 
security problem.   I would have argued we should move to rh-python35, but that 
would eventually suffer the same problem.   What we need is a distribution that 
keeps up to date, but is still distributed as an rpm.

Thanks,

Dan Davis, Systems/Applications Architect (Contractor),
Office of Computer and Communications Systems,
National Library of Medicine, NIH





___

SCLorg mailing list

SCLorg@redhat.com<mailto:SCLorg@redhat.com>

https://www.redhat.com/mailman/listinfo/sclorg



--

Brian Gollaher

Red Hat Platform Product Management

Phone: 978 392-3173

Cell: 508 740-6549

bri...@redhat.com<mailto:bri...@redhat.com>
___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

Re: [scl.org] Setting SCL RPM build options in COPR?

[Davis, Daniel (NIH/NLM) [C]]

Nick,

Now that your question has been answered, let me ask mine.The instructions 
to build pyscl-devel separate from Copr are not clear enough for me.   Are you 
suggesting that I run pipsi in a virtual environment?How is scrlo-python 
involved?

I'm going to try later today, and want to be clear about what is involved...
I've built multi-package rpms before, sometimes from scripts and makefiles, but 
not multi-package repositories from scripts, and I've never used Copr and 
friends.   I've never used a chroot to build rpms, but I think I've installed 
mock even though I didn't really need it.


-Original Message-
From: sclorg-boun...@redhat.com [mailto:sclorg-boun...@redhat.com] On Behalf Of 
Nick Coghlan
Sent: Tuesday, September 19, 2017 4:10 AM
To: Petr Kubat 
Cc: sclorg@redhat.com
Subject: Re: [scl.org] Setting SCL RPM build options in COPR?

On Tue, Sep 19, 2017 at 5:31 PM, Petr Kubat  wrote:
> On 09/19/2017 08:16 AM, Nick Coghlan wrote:
>> I couldn't find anything in sclorg-distgit that actually *sets* them 
>> for the rh-python35 case.
>>
>>
>> https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-pytho
>> n35-rh/macros.additional.rh-python35
>> has the comment "the @scl@* macros are defined in
>> macros.python3.python33 in python33-python-devel"
>>
>> That's presumably referring to
>>
>> https://github.com/sclorg-distgit/python/blob/sig-sclo7-rh-python35-r
>> h/macros.python3, which still doesn't *set* "@scl@" or "@vendorscl@", 
>> it assumes they're set somewhere else.
>
>
> The "@scl@" and "@vendorscl@" symbols are replaced by proper values 
> during the build of the metapackage [1], and the resulting macros get 
> installed using the *-build sub-package [2] as Honza mentioned.
>
> [1]
> https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-python
> 35-rh/rh-python35.spec#L113
> [2]
> https://github.com/sclorg-distgit/rh-python35/blob/sig-sclo7-rh-python
> 35-rh/rh-python35.spec#L137

Ah, thanks - that's the step I was missing :)

I'll amend the sclo-python version of the macro files to explain that more 
clearly, and probably put something in the pyscl-devel README as well.

Cheers,
Nick.

--
Nick Coghlan
Red Hat Platform Engineering, Brisbane

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

[scl.org] rh-python36 and sqlite version

[Davis, Daniel (NIH/NLM) [C]]

I recently noticed that Django 2.2 requires sqlite 3.8.3 or better.   I first 
tried the Fedora  26 SRPM, and then the Fedora 23 SRPM.
I needed to make one tweak to the later:

https://github.com/danizen/sqlite-centos7

Problem with my method, which I long ago honed when shipping a custom 
appliance, is that it overlays the sqlite already on the system.
Better to build a custom sqlite that will go into /opt/rh/rh-python36/root - 
can someone re-educate me on how to do this.   I know that it is in wikis, but 
I'm an old dog who mostly does application software in Python/Django these 
days, except when I need to drop down to a lower level to help the systems guys 
understand what they need to do.

Only now that I've convinced them to use RHSCL so heavily, I need to know how 
to augment the SCLs as well.

Dan Davis, Systems/Applications Architect (Contractor),
Office of Computer and Communications Systems,
National Library of Medicine, NIH

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

Re: [scl.org] rh-python36 and sqlite version

[Davis, Daniel (NIH/NLM) [C]]

This pretty much describes what I might wish to do, but I'd prefer to find the 
latest documentation.  Will look to the SCL SIG for latest documentation.

https://access.redhat.com/documentation/en-us/red_hat_software_collections/1/html/packaging_guide/sect-extending_the_python27_and_python33_software_collections

From: sclorg-boun...@redhat.com  On Behalf Of Davis, 
Daniel (NIH/NLM) [C]
Sent: Monday, July 22, 2019 3:53 PM
To: sclorg@redhat.com
Subject: Re: [scl.org] rh-python36 and sqlite version

I've downloaded rh-python36-python-pymongo-3.5.1-1.el7.src.rpm and I see the 
macros in there.  I've also installed rh-python36-scldevel, and I see what it 
defines.

It looks like what I would want to do is to pass the correct macros into 
rpmbuild some of the time.

rpmbuild -bc --define "%scl_python rh-python36
%scl_prefix_python rh-python36-"

The changes should only be in the spec. file, which I've already pulled out.


Can someone confirm?

From: sclorg-boun...@redhat.com<mailto:sclorg-boun...@redhat.com> 
mailto:sclorg-boun...@redhat.com>> On Behalf Of 
Davis, Daniel (NIH/NLM) [C]
Sent: Monday, July 22, 2019 3:37 PM
To: sclorg@redhat.com<mailto:sclorg@redhat.com>
Subject: [scl.org] rh-python36 and sqlite version

I recently noticed that Django 2.2 requires sqlite 3.8.3 or better.   I first 
tried the Fedora  26 SRPM, and then the Fedora 23 SRPM.
I needed to make one tweak to the later:

https://github.com/danizen/sqlite-centos7

Problem with my method, which I long ago honed when shipping a custom 
appliance, is that it overlays the sqlite already on the system.
Better to build a custom sqlite that will go into /opt/rh/rh-python36/root - 
can someone re-educate me on how to do this.   I know that it is in wikis, but 
I'm an old dog who mostly does application software in Python/Django these 
days, except when I need to drop down to a lower level to help the systems guys 
understand what they need to do.

Only now that I've convinced them to use RHSCL so heavily, I need to know how 
to augment the SCLs as well.

Dan Davis, Systems/Applications Architect (Contractor),
Office of Computer and Communications Systems,
National Library of Medicine, NIH

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

Re: [scl.org] rh-python36 and sqlite version

[Davis, Daniel (NIH/NLM) [C]]

I've downloaded rh-python36-python-pymongo-3.5.1-1.el7.src.rpm and I see the 
macros in there.  I've also installed rh-python36-scldevel, and I see what it 
defines.

It looks like what I would want to do is to pass the correct macros into 
rpmbuild some of the time.

rpmbuild -bc --define "%scl_python rh-python36
%scl_prefix_python rh-python36-"

The changes should only be in the spec. file, which I've already pulled out.


Can someone confirm?

From: sclorg-boun...@redhat.com  On Behalf Of Davis, 
Daniel (NIH/NLM) [C]
Sent: Monday, July 22, 2019 3:37 PM
To: sclorg@redhat.com
Subject: [scl.org] rh-python36 and sqlite version

I recently noticed that Django 2.2 requires sqlite 3.8.3 or better.   I first 
tried the Fedora  26 SRPM, and then the Fedora 23 SRPM.
I needed to make one tweak to the later:

https://github.com/danizen/sqlite-centos7

Problem with my method, which I long ago honed when shipping a custom 
appliance, is that it overlays the sqlite already on the system.
Better to build a custom sqlite that will go into /opt/rh/rh-python36/root - 
can someone re-educate me on how to do this.   I know that it is in wikis, but 
I'm an old dog who mostly does application software in Python/Django these 
days, except when I need to drop down to a lower level to help the systems guys 
understand what they need to do.

Only now that I've convinced them to use RHSCL so heavily, I need to know how 
to augment the SCLs as well.

Dan Davis, Systems/Applications Architect (Contractor),
Office of Computer and Communications Systems,
National Library of Medicine, NIH

___
SCLorg mailing list
SCLorg@redhat.com
https://www.redhat.com/mailman/listinfo/sclorg

Re: [scl.org] Is Software Collections abandoned?

[Davis, Daniel (NIH/NLM) [C]]

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-boun...@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@redhat.com
https://listman.redhat.com/mailman/listinfo/sclorg



___
SCLorg mailing list
SCLorg@redhat.com
https://listman.redhat.com/mailman/listinfo/sclorg

Re: [scl.org] Is Software Collections abandoned?

[Davis, Daniel (NIH/NLM) [C]]

> 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. 





___
SCLorg mailing list
SCLorg@redhat.com
https://listman.redhat.com/mailman/listinfo/sclorg