Re: Is Scientfic Linux Still Active as a Distribution?
I used the term "dead". SL7 (and earlier?) is still active. By dead, I did not mean SL 7, I meant SL in general for the future. As I understand the situation, Fermilab/CERN (and thus the HEP community upon which many of us are "piggybacking" -- not freeloading if one is paying taxes to a government that is providing funding to Fermilab or CERN) has abandoned SL going forward -- NO SL 8, but Fermilab/CERN will be using CentOS 8 (with modifications? I do not know). CentOS is a RedHat subsidiary, and RedHat is fully owned by IBM. Thus, one must depend upon the good will (profit motive?) of IBM to provide a viable CentOS 8 that may be competing with the for-profit RHEL 8 of IBM. SL may be dependent upon the RHEL sources that RedHat and IBM are required to provide under the GPL, etc., but will make things operational and, as a separate distro, also is required to release source. Once SL is not a distro, internal changes at Fermilab/CERN to CentOS do not have the same general "public" immediacy as would an official public distro. As has been explained elsewhere, going from such source to a bootable stable useful OS environment is no trivial matter -- an OS does not simply and automatically "rebuild" from such source. It is important that a distro be professionally maintained, not by amateur volunteers. The latter approach may work for some applications, but not an entire OS that is a much more complicated entity than most applications. The professional staff doing the distro presumably have this work as part of their assigned compensated duties, not simply as an amateur when one has the time for it (retired or independently wealthy professionals doing the distro are not the personnel base upon which one can rely). On 2/20/20 11:12 PM, Pwillis wrote: Hello, Is Scientific Linux still active? There was another message that alluded to ’SL’ being ‘dead’. Installing this on a diskless node system is not an option if the distribution is no longer supported. Thanks fort any info, Peter
Is Scientfic Linux Still Active as a Distribution?
Hello, Is Scientific Linux still active? There was another message that alluded to ’SL’ being ‘dead’. Installing this on a diskless node system is not an option if the distribution is no longer supported. Thanks fort any info, Peter
Re: [SCIENTIFIC-LINUX-USERS] MATE desktop upgrade fail SL7
As root, I attempted to follow your suggestion. As you can read below, this results in changes to 75 different packages. Before I will do this, I need to understand if the result will be "stable" and still "fully" operational? Should I just leave things alone for now until I switch either to EL 8 from some distro (perhaps Princeton Springdale -- if it ever releases EL 8 -- as SL is "dead" and Princeton is a reputable university with the same level of professionalism as FNAL, CERN, etc.) or to Ubuntu LTS (leaving RPM for DEB -- a full departure within the general Linux sphere)? Yasha Karant [root@localhost ykarant]# yum downgrade libgpod Loaded plugins: langpacks, nvidia Repository sl is listed more than once in the configuration Resolving Dependencies --> Running transaction check ---> Package libgpod.x86_64 0:0.8.2-12.el7 will be a downgrade --> Processing Dependency: libimobiledevice.so.6()(64bit) for package: libgpod-0.8.2-12.el7.x86_64 --> Processing Dependency: libplist.so.3()(64bit) for package: libgpod-0.8.2-12.el7.x86_64 ---> Package libgpod.x86_64 0:0.8.3-7.el7 will be erased --> Running transaction check ---> Package libimobiledevice.x86_64 0:1.1.5-6.el7 will be updated --> Processing Dependency: libimobiledevice.so.4()(64bit) for package: gvfs-afc-1.22.4-6.el7.x86_64 --> Processing Dependency: libimobiledevice.so.4()(64bit) for package: upower-0.99.2-1.el7.x86_64 ---> Package libimobiledevice.x86_64 0:1.2.0-1.el7 will be an update --> Processing Dependency: libusbmuxd.so.4()(64bit) for package: libimobiledevice-1.2.0-1.el7.x86_64 ---> Package libplist.x86_64 0:1.10-4.el7 will be updated --> Processing Dependency: libplist.so.1()(64bit) for package: usbmuxd-1.0.8-11.el7.x86_64 ---> Package libplist.x86_64 0:1.12-3.el7 will be an update --> Running transaction check ---> Package gvfs-afc.x86_64 0:1.22.4-6.el7 will be updated ---> Package gvfs-afc.x86_64 0:1.36.2-3.el7 will be an update --> Processing Dependency: gvfs(x86-64) = 1.36.2-3.el7 for package: gvfs-afc-1.36.2-3.el7.x86_64 --> Processing Dependency: gvfs-client(x86-64) = 1.36.2-3.el7 for package: gvfs-afc-1.36.2-3.el7.x86_64 ---> Package libusbmuxd.x86_64 0:1.0.10-5.el7 will be installed ---> Package upower.x86_64 0:0.99.2-1.el7 will be updated ---> Package upower.x86_64 0:0.99.7-1.el7 will be an update ---> Package usbmuxd.x86_64 0:1.0.8-11.el7 will be updated ---> Package usbmuxd.x86_64 0:1.0.8-11.el7 will be obsoleted ---> Package usbmuxd.x86_64 0:1.1.0-1.el7 will be obsoleting --> Running transaction check ---> Package gvfs.x86_64 0:1.22.4-6.el7 will be updated --> Processing Dependency: gvfs(x86-64) = 1.22.4-6.el7 for package: gvfs-goa-1.22.4-6.el7.x86_64 --> Processing Dependency: gvfs(x86-64) = 1.22.4-6.el7 for package: gvfs-smb-1.22.4-6.el7.x86_64 --> Processing Dependency: gvfs(x86-64) = 1.22.4-6.el7 for package: gvfs-mtp-1.22.4-6.el7.x86_64 --> Processing Dependency: gvfs(x86-64) = 1.22.4-6.el7 for package: gvfs-afp-1.22.4-6.el7.x86_64 --> Processing Dependency: gvfs(x86-64) = 1.22.4-6.el7 for package: gvfs-fuse-1.22.4-6.el7.x86_64 --> Processing Dependency: gvfs(x86-64) = 1.22.4-6.el7 for package: gvfs-gphoto2-1.22.4-6.el7.x86_64 --> Processing Dependency: gvfs(x86-64) = 1.22.4-6.el7 for package: gvfs-archive-1.22.4-6.el7.x86_64 ---> Package gvfs.x86_64 0:1.36.2-3.el7 will be an update --> Processing Dependency: glib2(x86-64) >= 2.51.0 for package: gvfs-1.36.2-3.el7.x86_64 ---> Package gvfs-client.x86_64 0:1.36.2-3.el7 will be installed --> Running transaction check ---> Package glib2.x86_64 0:2.42.2-5.el7 will be updated ---> Package glib2.x86_64 0:2.56.1-5.el7 will be an update ---> Package gvfs-afp.x86_64 0:1.22.4-6.el7 will be updated ---> Package gvfs-afp.x86_64 0:1.36.2-3.el7 will be an update ---> Package gvfs-archive.x86_64 0:1.22.4-6.el7 will be updated ---> Package gvfs-archive.x86_64 0:1.36.2-3.el7 will be an update ---> Package gvfs-fuse.x86_64 0:1.22.4-6.el7 will be updated ---> Package gvfs-fuse.x86_64 0:1.36.2-3.el7 will be an update ---> Package gvfs-goa.x86_64 0:1.22.4-6.el7 will be updated ---> Package gvfs-goa.x86_64 0:1.36.2-3.el7 will be an update --> Processing Dependency: libgdata(x86-64) >= 0.17.9 for package: gvfs-goa-1.36.2-3.el7.x86_64 ---> Package gvfs-gphoto2.x86_64 0:1.22.4-6.el7 will be updated ---> Package gvfs-gphoto2.x86_64 0:1.36.2-3.el7 will be an update --> Processing Dependency: libgphoto2_port.so.12(LIBGPHOTO2_5_0)(64bit) for package: gvfs-gphoto2-1.36.2-3.el7.x86_64 --> Processing Dependency: libgphoto2_port.so.12()(64bit) for package: gvfs-gphoto2-1.36.2-3.el7.x86_64 ---> Package gvfs-mtp.x86_64 0:1.22.4-6.el7 will be updated ---> Package gvfs-mtp.x86_64 0:1.36.2-3.el7 will be an update ---> Package gvfs-smb.x86_64 0:1.22.4-6.el7 will be updated ---> Package gvfs-smb.x86_64 0:1.36.2-3.el7 will be an update --> Running transaction check ---> Package libgdata.x86_64 0:0.17.1-1.el7 will be updated ---> Package libgdata.x86_64 0:0.17.9-1.el7 will be
Re: disabling the mirror list
Try to do yum --disablerepo=* localinstall and see if that helps If it does then you ahve to look in each *.repo file and disable them all in turn. Steve From: owner-scientific-linux-us...@listserv.fnal.gov on behalf of Ken Teh <0864eace5c83-dmarc-requ...@listserv.fnal.gov> Sent: Thursday, February 20, 2020 2:30 PM To: scientific-linux-users Subject: disabling the mirror list I tried to do a yum localinstall somename.rpm and yum went out looking for mirrors. I have a machine behind a nat box that restricts outbound access so it is timing out trying to reach https://urldefense.proofpoint.com/v2/url?u=http-3A__ftp.scientificlinux.org=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=gPxUF7VEZvngH42FWi_n2Oud9LoYvWcrlEyfWEZv4BI=U4w5jEkK86lgA8jZYPg5ym6c03DCPEsaGyPstP1aQqc= . Why does it try accessing various mirrors when I do a local install? We have a local mirror here at ANL and I want yum to use our local mirror and not wander around the net trying to reach various mirrors. To this end, I've put the baseurl in sl6x.repo to point at our local mirror. But it still goes out to look for mirrors. What gives? Tried looking at ym.conf parameters but none jumps out at me that might possibly disable this behaviour. Would appreciate some advice. Thanks.
