Re: Springdale Linux
I just checked: Ubuntu 20.04.1 LTS currently uses gcc version 9.3.0 and
GNU C Library stable release version 2.31
On 12/14/20 1:02 PM, Teh, Kenneth M. wrote:
Software collections has gcc-9. If memory serves, SL7 has gcc-4.8.
*From:* owner-scientific-linux-us...@listserv.fnal.gov
on behalf of Yasha
Karant
*Sent:* Monday, December 14, 2020 2:44 PM
*To:* scientific-linux-users@fnal.gov
*Subject:* Re: Springdale Linux
Thank you for quoting from the Princeton material. I had read the
Princeton commentary a while ago when internally we were debating SL vs.
Princeton, and went with SL because Fermilab/CERN combined have better
resources than Princeton alone. The one thing I did note and have
mentioned on this list, if memory serves, was that SL8 was to be
replaced by (the now to-be-defunct) CentOS 8, for which the comment that
such RPMs (including presumably SRPMs) are "not 100% safe" seemed
applicable. However, there was no substantial discussion of this point;
thus I assumed that as Fermilab/CERN did have a very limited deployment
RHEL license, the HEP community CentOS 8 would be verified against
"safe" RHEL for not just binary compatibility ("bug for bug") but also
"safety".
As pointed out by others on this list, I too need later C++ versions
than EL 7 has -- any idea when Springdale EL8 will be in production
distribution with a distro?
On 12/14/20 12:10 PM, Maarten wrote:
Spring is a binary clone of RHEL and the sources are not based off CentOS.
Quoting someone from the Springdale mailinglist: "Springdale Linux
formerly known as PUIAS (Princeton University Institute for Advanced
Studies) is older than CentOS and it compiles it's own binaries from the
upstream source code. It is unrelated to CentOS and in my experience
CentOS RPMs are not 100% safe. I tend to avoid them. Springdale has it's
own repos, EPEL is ok and RPM Fusion works for me. For CUDA I use RHEL
RPMs not CentOS RPMs the same goes for Chrome or anything else."
If you want to install Springdale you can just use the boot iso no DVD
needed: puias.princeton.edu/data/puias/8.3/x86_64/os/images/boot.iso
As for converting from CentOS8 to Springdale it's basically removing the
the Centos specific packages and replacing them with the Springdale
packages. I have done this with a test system and afterwards with my
personal systems that were running CentOS8. it worked flawlessly so I
will be sticking to Springdale Linux even after Rocky Linux is released.
Maarten
On 12/14/20 8:49 PM, Yasha Karant wrote:
Springdale EL (Princeton in my terminology, just as SL is
Fermilab/CERN) shows the following:
Download
DVD
i386 x86_64
8.3 TBA TBA
That is, there is no repo with an installable EL 8 ISO image. As for
repos, Springdale shows:
If you are only looking to install some rpms, you can download our
repositories on your system.
YUM Repositories for PUIAS 8? (NB: This text was thus shown as not
[yet?] available.
If Sprindale is built from CentOS, then such a build will no longer be
possible from CentOS Stream (a perpetual "beta" version, not a
production distro). Springdale (and Rocky EL) and any future SL 8 --
were the HEP community to fund such (personnel, space, and hardware
platforms) -- would need to get actual production RHEL 8 source from
IBM RH pursuant to the Linux, GPL, etc., licenses. Such sources are
not "pretty" and are deliberately designed to be "unfriendly" to build
from source, even with removal of all of the proprietary "logo" IP.
The idea of keeping SL 7 "alive" with perpetual backporting also may
not be attractive. For now, until IBM RH announces for CentOS 7 what
was announced for the to-be-defunct CentOS 8, CentOS 7 can keep SL 7
patched for security, albeit not necessarily for new hardware (e.g.,
backporting drivers) or supporting new CPU and system I/O architectures.
Yasha Karant
On 12/14/20 3:39 AM, Maarten wrote:
I already converted over my personal systems over to Springdale Linux
without having to reinstall because it saved me from having to
reinstall Debian from scratch on all of my systems.
On 12/14/20 12:37 PM, Tapia, Ron wrote:
Hi,
Is anyone considering Springdale Linux
(https://urldefense.proofpoint.com/v2/url?u=http-3A__springdale.math.ias.edu_=DwIFAw=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=fXPV3dpZLhNbng7dmn_Ujhzb4ZuEw1y-JygmhWnmWFc=X_cL7uUNfZJblixsdJpO5f8utO2X1cLdZWYLVmfwc-s=
) as a way forward after SL7?
Thanks,
Ron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEARECAAYFAwjxL0ACgkQsLQYPxkqfX1aqQCfaX9hgVThuWiqXNOnRa73wA32
eAYAn1wwCkBr+iYJX/PZ4X6/m8DuCtVd
=INeofakesigforsafelinks
-END PGP SIGNATURE-
Re: SL7 with security and bug fixes forever - how much work?
I knew persons using the X86 Mac compatibility layer on PPC Macs, and was told that there was a noticeable performance hit because the emulator (more or less) functioned as an "inner interpreter" for a totally different ISA. The same is true between X86-64 and the 64 bit ARM ISAs (along with other architectural differences). Out of curiosity, how similar are the Apple Mac ARM CPUs to the CPU used in the Fujitsu Fugaku HPC machine (A64FX 48C 2.2GHz)? On 12/14/20 12:12 PM, Jon Pruente wrote: On Mon, Dec 14, 2020 at 2:07 PM Yasha Karant <mailto:ykar...@gmail.com>> wrote: For the Apple Mac community: as is known, Apple is leaving the X86-64 platform for an ARM platform. Will older applications be updated, or will new (and in some cases, newly licensed-for-fee) applications be required? The recent releases of macOS went 64-bit only, which cut out a lot of old software. The most recent release that added support for ARM also includes a binary compatibility layer to run x86-64 programs called Rosetta 2, after the similar layer they used when they transitioned from PPC to x86.
Re: Springdale Linux
Thank you for quoting from the Princeton material. I had read the
Princeton commentary a while ago when internally we were debating SL vs.
Princeton, and went with SL because Fermilab/CERN combined have better
resources than Princeton alone. The one thing I did note and have
mentioned on this list, if memory serves, was that SL8 was to be
replaced by (the now to-be-defunct) CentOS 8, for which the comment that
such RPMs (including presumably SRPMs) are "not 100% safe" seemed
applicable. However, there was no substantial discussion of this point;
thus I assumed that as Fermilab/CERN did have a very limited deployment
RHEL license, the HEP community CentOS 8 would be verified against
"safe" RHEL for not just binary compatibility ("bug for bug") but also
"safety".
As pointed out by others on this list, I too need later C++ versions
than EL 7 has -- any idea when Springdale EL8 will be in production
distribution with a distro?
On 12/14/20 12:10 PM, Maarten wrote:
Spring is a binary clone of RHEL and the sources are not based off CentOS.
Quoting someone from the Springdale mailinglist: "Springdale Linux
formerly known as PUIAS (Princeton University Institute for Advanced
Studies) is older than CentOS and it compiles it's own binaries from the
upstream source code. It is unrelated to CentOS and in my experience
CentOS RPMs are not 100% safe. I tend to avoid them. Springdale has it's
own repos, EPEL is ok and RPM Fusion works for me. For CUDA I use RHEL
RPMs not CentOS RPMs the same goes for Chrome or anything else."
If you want to install Springdale you can just use the boot iso no DVD
needed: puias.princeton.edu/data/puias/8.3/x86_64/os/images/boot.iso
As for converting from CentOS8 to Springdale it's basically removing the
the Centos specific packages and replacing them with the Springdale
packages. I have done this with a test system and afterwards with my
personal systems that were running CentOS8. it worked flawlessly so I
will be sticking to Springdale Linux even after Rocky Linux is released.
Maarten
On 12/14/20 8:49 PM, Yasha Karant wrote:
Springdale EL (Princeton in my terminology, just as SL is
Fermilab/CERN) shows the following:
Download
DVD
i386 x86_64
8.3 TBA TBA
That is, there is no repo with an installable EL 8 ISO image. As for
repos, Springdale shows:
If you are only looking to install some rpms, you can download our
repositories on your system.
YUM Repositories for PUIAS 8? (NB: This text was thus shown as not
[yet?] available.
If Sprindale is built from CentOS, then such a build will no longer be
possible from CentOS Stream (a perpetual "beta" version, not a
production distro). Springdale (and Rocky EL) and any future SL 8 --
were the HEP community to fund such (personnel, space, and hardware
platforms) -- would need to get actual production RHEL 8 source from
IBM RH pursuant to the Linux, GPL, etc., licenses. Such sources are
not "pretty" and are deliberately designed to be "unfriendly" to build
from source, even with removal of all of the proprietary "logo" IP.
The idea of keeping SL 7 "alive" with perpetual backporting also may
not be attractive. For now, until IBM RH announces for CentOS 7 what
was announced for the to-be-defunct CentOS 8, CentOS 7 can keep SL 7
patched for security, albeit not necessarily for new hardware (e.g.,
backporting drivers) or supporting new CPU and system I/O architectures.
Yasha Karant
On 12/14/20 3:39 AM, Maarten wrote:
I already converted over my personal systems over to Springdale Linux
without having to reinstall because it saved me from having to
reinstall Debian from scratch on all of my systems.
On 12/14/20 12:37 PM, Tapia, Ron wrote:
Hi,
Is anyone considering Springdale Linux
(https://urldefense.proofpoint.com/v2/url?u=http-3A__springdale.math.ias.edu_=DwIFAw=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=fXPV3dpZLhNbng7dmn_Ujhzb4ZuEw1y-JygmhWnmWFc=X_cL7uUNfZJblixsdJpO5f8utO2X1cLdZWYLVmfwc-s=
) as a way forward after SL7?
Thanks,
Ron
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEARECAAYFAwjxL0ACgkQsLQYPxkqfX1aqQCfaX9hgVThuWiqXNOnRa73wA32
eAYAn1wwCkBr+iYJX/PZ4X6/m8DuCtVd
=INeofakesigforsafelinks
-END PGP SIGNATURE-
Re: SL7 with security and bug fixes forever - how much work?
I fully agree. The security-against-compromise integrity of up-ported
"SL7" using C++n, for some n > n(RHEL 7."latest or last" distro)
requires "professional" re-evaluation, penetration testing, and
monitoring. Will this be done? I too have run into the same issues
with backporting, and for that reason switched to Ubuntu current LTS
(for now). As for IA-32 support, this will be a larger issue --
particularly as much basic research without the possibility of a
profit-driven product (e.g., a vaccine because of public funds being
expended for basic research into biology and medical science, both human
and non-human) is heavily underfunded; hence, your reference to using
hardware obsolete but fully adequate systems for which current release
software is becoming increasingly scarce.
For the Apple Mac community: as is known, Apple is leaving the X86-64
platform for an ARM platform. Will older applications be updated, or
will new (and in some cases, newly licensed-for-fee) applications be
required?
On 12/14/20 11:55 AM, Konstantin Olchanski wrote:
On Mon, Dec 14, 2020 at 02:36:20PM -0500, Serguei Mokhov wrote:
I have done this in the past with mixed success, typical problems
include "cmake is too old", "autoconf/autotools are too old".
Having run into this at a smaller scale for one of the projects I ended up using
devtoolset-6 (and -7 as appropriate) that ships all this stuff such as
newer GCC,
GLIBC, etc.
Yes, devtoolset is the advertised solution. I bought into it myself,
and then got burned after discovering that is it is missing one critical
32-bit shared library and it cannot be used to cross-compile 32-bit executables,
a "must have" for a couple of experiments that use hardware
with 600-1200 MHz Pentium-3 processors. (replacement hardware is in the USD$5000
price ranges, quantity "to be upgraded" is around 10, none of this has
been budgeted and 64-bit upgrade is not needed for the function
they perform).
Anyhow, is there commitment to devtoolset updates to c++17, c++20, c++21, etc?
For our MIDAS Data Acquisition package, we just started using c++11 recently,
and already we desire to use c++14 and c++17 features. (cannot, because of el7).
Then, there is the question whether SL7 "upgraded to latest versions of
everything"
is still SL7. ("grand father's axe", etc). For a purist, SL7 is something
installed from an official installer image, adding packages from EPEL and ELREPO
starts pushing it. SL7 with custom-built linux kernel, glibc, sshd, httpd, kde,
php100 and python3000 is probably not SL7 anymore.
The label "SL7" is only useful if it refers to something well defined. If every
instance of SL7 has a different linux kernel, different versions of devtoolset,
different cmake, different python, etc, I would say SL7 no longer exists.
Re: Springdale Linux
Springdale EL (Princeton in my terminology, just as SL is Fermilab/CERN) shows the following: Download DVD i386x86_64 8.3 TBA TBA That is, there is no repo with an installable EL 8 ISO image. As for repos, Springdale shows: If you are only looking to install some rpms, you can download our repositories on your system. YUM Repositories for PUIAS 8? (NB: This text was thus shown as not [yet?] available. If Sprindale is built from CentOS, then such a build will no longer be possible from CentOS Stream (a perpetual "beta" version, not a production distro). Springdale (and Rocky EL) and any future SL 8 -- were the HEP community to fund such (personnel, space, and hardware platforms) -- would need to get actual production RHEL 8 source from IBM RH pursuant to the Linux, GPL, etc., licenses. Such sources are not "pretty" and are deliberately designed to be "unfriendly" to build from source, even with removal of all of the proprietary "logo" IP. The idea of keeping SL 7 "alive" with perpetual backporting also may not be attractive. For now, until IBM RH announces for CentOS 7 what was announced for the to-be-defunct CentOS 8, CentOS 7 can keep SL 7 patched for security, albeit not necessarily for new hardware (e.g., backporting drivers) or supporting new CPU and system I/O architectures. Yasha Karant On 12/14/20 3:39 AM, Maarten wrote: I already converted over my personal systems over to Springdale Linux without having to reinstall because it saved me from having to reinstall Debian from scratch on all of my systems. On 12/14/20 12:37 PM, Tapia, Ron wrote: Hi, Is anyone considering Springdale Linux (https://urldefense.proofpoint.com/v2/url?u=http-3A__springdale.math.ias.edu_=DwIFAw=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=fXPV3dpZLhNbng7dmn_Ujhzb4ZuEw1y-JygmhWnmWFc=X_cL7uUNfZJblixsdJpO5f8utO2X1cLdZWYLVmfwc-s= ) as a way forward after SL7? Thanks, Ron -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAwjxL0ACgkQsLQYPxkqfX1aqQCfaX9hgVThuWiqXNOnRa73wA32 eAYAn1wwCkBr+iYJX/PZ4X6/m8DuCtVd =INeofakesigforsafelinks -END PGP SIGNATURE-
Re: SL7 with security and bug fixes forever - how much work?
I respectfully must slightly disagree with you. In terms of security fixes and new hardware drivers, the issues of backporting (that is, to make a bit of software compatible -- buildable -- with the core gcc/g++ environment of a "very old" Linux, including SL) may require a great deal of work. Unlike those environments that use "micro-kernels", Linux (thanks to Torvalds' insistence) is a monolith, and changing one aspect of a monolith often changes many other aspects. (A micro-kernel -- "Mach" -- approach more easily can have encapsulation and "isolation.) New hardware drivers are needed if one is using the environment on a platform that has "current" hardware for which new hardware drivers are needed. This is more common on a laptop workstation, but happens on servers and real-time control and data acquisition systems (e.g., the experimental environment of HEP). Could an SL7 base be kept up to date on these issues? Probably. However, a technical staff of a few (less than five) full time professionals might not suffice given the number of lines of source code that are involved. Moreover, the current professionals who maintained SL at Fermilab/CERN may not want to be involved, given that each may have a "permanent" "real job" position at Fermilab/CERN or a participating entity (e.g. a university). Thus, your subscription model may not be practical -- and the use of volunteers or compensated "Gig economy" "workers" does not result in stability. Stability requires compensated permanent professionals (except for those who are independently "wealthy" and are willing to be permanent "volunteers", an unlike staff arrangement). Yasha Karant On 12/13/20 5:36 PM, Keith Lofstrom wrote: New distro releases imply: 1) security fixes, 2) bug fixes, 3) new hardware drivers, 4) new applications, 5) and changed behavior (ie, Gnome2 to Gnome3). (the list is probably not complete) How much work (staff hours per year, plus volunteer help) would it take to do JUST (1) and (2) for Scientific Linux 7.8, 7.9,... forever, assuming that RHEL and Debian sources were available for plagiarism? I (and perhaps others) chose SL because it was stable. I do not need to rebuild my working environment to adapt to changing fashion. I get SL for free now (thank you!) but I wouldn't mind paying an annual subscription fee to support a small team "keeping the plumbing water-tight and sanitary". WITHOUT hiding the sink and changing the knobs, which is what I would get from RedHat/IBM. How many of us are willing to pay for this, and to create, contribute, and maintain scientific "extras" (like the source code for the data reduction for my published papers) to share with our small community? Keith
Re: Sustainable computing - Re: CentOS EOL - politics?
I am familiar with Kubernetes that initiated though Google engineering staff as I recall. For those who are quite unfamiliar with Kubernetes, a brief overview with references is https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Kubernetes=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=yzqqasnYexgXlPFBSgopwWoJDjJYzXUUe22jj2Ohdcs=_qp_loeNCERXODusF1gKpZeOqLVKfxcFppY5NEX49y0= We looked at Singularity; however, as overviewed in https://urldefense.proofpoint.com/v2/url?u=https-3A__sc19.supercomputing.org_proceedings_bof_bof-5Fpages_bof187.html=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=yzqqasnYexgXlPFBSgopwWoJDjJYzXUUe22jj2Ohdcs=gq7xP-_56U5XegnswNWIqHt8qpOGx5e657Vgzh_tbok= Containers in HPC, Younge, Canon, and Newburn at which time there were at least Charliecloud, Docker, Kubernetes, Podman, Shifter, and Singularity under consideration. As the HPC community had not "stabilized" on one of these, and as these are not truly interoperable, we elected to wait and see. (Have the CERN HPC collaborations now selected one of these?) Although it is true that Ubuntu LTS, EL, etc., are not "identical", these each are based upon both Linux and GPL internals/applications, and once configured, are not all that different -- much less so from what I recall of the various containers. On 12/12/20 6:42 AM, ~Stack~ wrote: On 12/11/20 10:09 AM, Brett Viren wrote: My hope is they (we) take this current situation as a lesson and make a radical change that puts all of our computing on more sustainable footing as we go into the next decades. I'm curious about your thoughts on what it means to have that sustainable footing going forward. We have been pushing our users to Singularity images for the last two years (we jumped on pretty early). A LOT of our application/code base is already Singularity behind the scenes. The users don't know and don't care because their applications still run the same on the same HPC equipment. However, getting our users to purposefully think in terms of Singularity images has been a long hard road and we still have so much further to go. We are on the edge of shifting a few very critical and heavy computations to Kubernetes. I'm not yet convinced that it will replace a lot of the hard-core traditional HPC workloads anytime soon, but there are a surprising amount of workloads that can. Plus, it allows us to automate from Code->Gitlab->CI/CD->Kubernetes->results delightfully well. But one of the absolute greatest things about it from the perspective of what CentOS just pulled is that my dev Kubernetes has three OS's. SL7, Ubuntu 20.04, and CentOS 8 (I JUST spun this up the Monday before the announcement). As an admin, I _don't_ care about the OS at this point of the Kubernetes process. I kill a node and rebuild it to anything that supports the docker requirements (plus a few other things I need for company audit/security) and join it to the cluster. Done! When I killed that CentOS 8 node I suffered no loss in the slightest in terms of functionality and only about an hour of time where I had to move the workload and rebuild the node Ubuntu. Bigger shops with decent sized teams, these transitions can be done over time. But the vast majority of my career I've supported hundreds of compute nodes where the entire HPC team was just me plus my manager and we had to support the clusters for 5-8 years (especially when I was in the university world). I sympathize with the small HPC teams that just don't have the time nor flexibility to migrate. Although, I would HEAVILY suggest that they make the time to learn Singularity I don't expect them to make the transition to Kubernetes without some drastic changes. I'm just curious what you are thinking about what it means to have a more sustainable footing within these clusters and what we as a community can do to lead the way such that in the next decades it matters less what OS is running on the hardware of these long term science HPC clusters. ~Stack~
Re: CentOS EOL - politics?
I agree with your analysis, save for three comments. Mine also is not a
political comment, merely an analysis of fact.
Overwhelmingly throughout the world, HEP is funded by public funds
(sometimes from totalitarian dictatorships if one can call such
"public"). HEP addresses basic science, fundamental physics as do some
aspects of astronomy and cosmology, which is of no interest to
for-profits other than a bit of technology spin-off (sometimes useful in
the "consumer" sector, more often in the weapons sector). The only
reasons a for-profit corporation in a "market" (including democratic
representative government neo-liberal oligopolies) funds fundamental
physics (I do not consider materials science fundamental, in that the
Standard Model, with appropriate computational capability and methods of
"solving" the underlying quantum field theory equations, including
quantum statistical mechanics, seems to be in full agreement, and even
has quantitative predictive power, for what has been discovered in
materials science under terrestrial conditions) is for publicity, for
proof of concept, and for tax writeoffs, often through vendor
partnerships that offer "huge" discounts from the commercial prices.
The equivalent areas of materials science, biology, etc., are of far
greater interest, particularly if wealth transference can be used
(public funding of the underlying research, but oligopoly profit from
the actual deployed products). This public funding stream is
fundamental to carrying out experimental as well as computational
theoretical physics -- instrumentality is required (science is not "pure
mathematics", despite what some think looking at any modern hard science
research paper). To those in HEP, all of the above is known and
"obvious", but to many in the wider SL community, it is not well understood.
There is adequate time to move servers past SL7 -- if IBM RH does not do
for CentOS 7 what it did for CentOS 8. Marketing promises from most
for-profit entities are unenforceable and subject effectively to whim
(typically perceived in the best interest of the entity, often only in
terms of short-term stock value, not long-term, in the
quarter-by-quarter financial market model). However, if new hardware
from vendors does not support the basic kernel gcc libraries of SL7, but
requires features from later production releases (say, what currently is
used by Ubuntu LTS), then the HEP community will have *LOTS* of
backporting to do.
The issue of what to do past SL7 is the question. Security compromises
to SL7 probably will be minimal in so far as RHEL7 through CentOS 7 is
supported, but once unsupported ("EOL"), it becomes increasingly
hazardous to keep the OS in any "mission-critical" production
environment. My personal guess is that in order to allocate financial
and personnel "resources" to other parts of the Fermilab/CERN
activities, SL was dropped for CentOS. This choice is not possible.
Assuming that many of the servers actually are under a type 1
hypervisor, it is relatively easy to start deployment of new supervisor
environments and test these. Otherwise, either machines must be
de-allocated from production and put into test mode for a new supervisor
environment, or additional platforms need to be procured. Testing must
be done near scale, as we all well know -- testing on a "high powered"
workstation is not the same as testing on a clustered HPC machine,
perhaps with a SAN, and other platform features.
As for the use of Mac OS X or MS Win (probably 10 right now) on the
desktop, that is a matter of taste and funding. As Apple again has
changed the Mac platform, now from X86-64 to ARM, and as Apple strictly
is a for-profit entity, there will need to be a massive re-investment in
new Mac machines, unless the X86-64 platforms convert to BSD or Linux,
and Linux is much easier to support for HEP built around SL. A
technical question: for those HEP workstations that are using Mac OS X,
is Fink or the equivalent installed so that "standard" applications
easily can be ported?
On 12/11/20 8:09 AM, Brett Viren wrote:
This is not a political reply.
Keith Lofstrom writes:
The big physics labs that supported Scientific Linux get
much or all of their funding from the US government,
CERN is primarily funded by CERN nation states, of which US is not one.
FNAL, being a US DOE National Lab, is primarily funded by US DOE.
I wonder how much IBM contributes to the politicians who
make the funding decisions for the labs, and I wonder if
there is subtle back-channel pressure on lab software
purchases and project funding decisions?
The subtle pressure theory is very doubtful to me. Here is why:
1. The various HEP/NP clusters are almost universally on SL7 so have
until ca 2024 to figure out wtf they will do next. So, there's
simply nothing there to apply any subtle pressure against. And, any
argument to move the clusters from
Re: Rocky Linux
My group did not, and I do not, need the cradle-to-grave pinocchio support that is provided by some (many?) support contracts. SL was ported and maintained by professionals who are paid staff of the entities that provide the distro (Fermilab from which this list is housed, and funded and collaborated by CERN), not by volunteers and amateurs. For commercial (typically for profit) and some government entities, using the products of and the (cradle to grave) support and training (not intellectual education, but technical training) from a "certified" vendor (such as IBM RH), including your entity, use that avenue for critical infrastructure. For many "academic" researchers, who nonetheless require "rock solid" infrastructure, the SL (not amateur) solution was fine. A volunteer based level of porting and support typically fails to meet this need, particularly as the number of lines of source code of the systems have grown enormously in most recent systems. It essentially is impossible for a single human (included a well educated and experience computer science practitioner professional) to maintain the details of the entire system (each statement, "line of source code") in her/his expert memory. Software engineering has not kept up with the real complexity of current systems, one of the causes of the number of software defects (and compromise vulnerabilities) we all now face. Amateurs and part-time professional volunteers typically exacerbate this situation. On 12/10/20 8:18 PM, ~Stack~ wrote: On 12/10/20 4:47 PM, Yasha Karant wrote: Again, my own needs are such that it is unacceptable to have a volunteer (and in many cases, amateur) developer/support arrangement for "mission critical" systems and applications software. Greetings, Well, there is Red Hat for professional support. Or if you don't like that option, Oracle Linux. For our critical infrastructure, it will probably remain Red Hat proper for that reason. However, my small team and I will probably continue to pursue RH training classes then feel comfortable enough to maintain the hundreds of non-critical servers with a community backed variant. Give it a month or so. I heard about another project starting up to be yet another variant today. I have a feeling that there will be more. And the better ones will emerge and I think we will all be able to make a more informed decision on our own directions in January when the initial excitement has died down. I do believe it is wise that you are following and keeping informed about the variants. ~Stack~
Re: Rocky Linux
I have been reading this thread and post some of my observations and
comments on the matters.
Much, if not all, experimental/hardware science and engineering systems
applications (e.g., special drivers, modified interfaces and bus
control, etc.) are targeted towards EL or the SuSE equivalent. There
will not be a CentOS 9, although there had better be a RHEL9 unless IBM
decides upon yet another path (because of for-profit business
parameters, as well explained by another correspondent to this list who
used very candid and honest language).
For example, at one time we put SuSE SLES (SuSE EL equivalent, just as
Ubuntu LTS is aimed at the same sector) on a HPC compute engine that had
a SAN and other infrastructure as well. SuSE was dismal because we
bought the least expensive support level (not cradle-to-grave full
handholding). We then switched to SL for RHEL, and at least one of the
for-profit HPC vendors we used -- that was a subcontractor to US
Government primary contractors -- also used SL. SL worked, and the
hardware support software we needed (including modified drivers, etc.)
was available, tested, and installable -- from this vendor. No games,
no special support contracts, we did all of the software maintenance and
verification such that things worked on our systems.
Again, as with SuSE, SL, and Ubuntu LTS, this was professionally ported
and, in terms of bug fixes and sample configuration, etc., files,
professionally supported by the vendor -- not amateur volunteers.
Cloud Linux looks -- again, looks -- as though it will be a SL type
support, and presumably there there will be CL9 if RH is required to
release the full source of RHEL9. CL 8 (and upon RHEL9, CL9) should
(should -- not will) be compatible with all of the
scientific/engineering hardware specific ("experiment-use") drivers,
etc., to which correspondents have referred.
Springdale (Princeton EL) is a possibility, but it is unclear how long
Springdale will have real professional support depending upon how
Princeton internally allocates fiscal (and hence personnel) resources,
and how much Springdale, like Fermilab and thus SL, depends upon
discretionary support from the USA Federal government.
I have signed up for the Rocky EL list to keep abreast of the situation,
but it appears Rocky EL will not have the paid professional support of
SL (not cradle to grave hand holding) but rather volunteer developers,
porters, testers, etc.
CentOS Stream, as with Fedora, and Ubuntu non-LTS is completely
unsuitable for my uses. These can be not only "unstable", but have too
many software defects (bugs) to of safe use. Moreover, continual
professional support is necessary to mitigate threats (the various
compromises that are in the wild) -- keep things up to date against the
latest attacks.
There has been a discussion of the shorter life-cycle of Ubuntu LTS
versus EL. In the case of CentOS 8, the life-cycle is much shorter than
what seemed to be promised. However, the issue arises as to against
which system (and application) libraries (typically, .so) a scientific
application is built, and against which Linux kernel (and kernel
"features"). EL 7 (SL, CentOS, etc.) may have a longer supported
lifecycle, but if a vendor does not back-port a vital application
(including a driver) to a "supported" environment that has been
"obsolete" for many years, than the support will be meaningless. I
recall once that we were required by a vendor of scientific equipment to
support versions of the kernel and libraries that were not available for
the "stable supported" Linux release we were using, and we were *FORCED*
to migrate. Thus, the shorter time interval of LTS versus EL supported
environments may not always be of real significance. However, the fact
that some applications (including drivers) may not be available for
Ubuntu (and in .deb from) but only for some variant of EL (in .rpm form)
is of greater concern. Cloud Linux may be the answer here -- if the
vendor really meets their promised time line.
Again, my own needs are such that it is unacceptable to have a volunteer
(and in many cases, amateur) developer/support arrangement for "mission
critical" systems and applications software.
Yasha Karant
On 12/10/20 8:47 AM, Vinícius Ferrão wrote:
I’ve done this mistake in the past.
The major issue with Debian is its lifecycle, even LTS is 5 years only. Same
for Ubuntu. It’s just too little. If you need to install it near the end of the
2yr lifecycle you’ll get effectively something like 3yrs of support.
The other issue is that the vast majority of academic and scientific software
is targeted for Enterprise Linux. As an HPC engineer we always needs to use
RHEL/derivatives or SLES/Leap. OpenHPC is only available to those flavors.
Mellanox OFED? Ok there’s Ubuntu support nowadays, but the default branches are
Re: Dose any of this surprize you.
A note: On 12/9/20 11:05 AM, Konstantin Olchanski wrote: On Wed, Dec 09, 2020 at 10:25:36AM -0500, Larry Linder wrote: Everytime I am forced to use Windows 10 my neurons rebel at the moron aware SW. I am sorry you are in the position where you are forced to use Windows, I feel lucky that I can "just say no!". For those of us who must work in the "real world", unfortunately many applications have no work alike for Linux, but typically proprietary licensed for fee applications only for MS Win and/or Mac OS X. Anything proprietary for Mac OS X is impossible to legally use in the USA and EU other than on an Apple (hardware) platform. I will not use a dual-boot system as this is both cumbersome and open to all sorts of compromises, particularly from MS Win. I have tried Cross-over (supported Wine), but it is too limited in the reliable support of current MS Win applications. I currently use MS Win 10 under both VMware Player and VirtualBox under, first, SL, and now Ubuntu LTS, as the platform I use did come with a MS Win license. Under this MS Win 10, I use proprietary applications not available for Linux. I also find MS Win 10 miserable and cumbersome, with a horrid and time consuming upgrade process (I experienced that because the current production release of an application I use required a later release of MS Win 10 than was on the virtual machine and I had to waste a day whilst MS Win 10 upgraded, rebooted, upgraded, rebooted, etc., but one does not have a choice. I do use LibreOffice and other workalikes. This problem is not new. When Sun was still a vendor and had desktop workstations with a Sparc platform, it was forced to introduce an add-on board with a X86 processor to run MS Win under Solaris so that such MS Win applications could be run, as many users did not want two desktop machines, a Sun for "real" work, and a MS Win box for "general use applications". Sun originally bought VirtualBox for this purpose once Sun had switched to a X86 hardware platform. Now of course this is all part of Oracle as the oligopolies increase. As the supporters of GNU retire and die off - the new generation has no desire to stay the course. This works both ways. I used to think Richard Stallman was a cook and a crank. Today I see his apocalyptic predictions for evils of "unfree" software come true (and then some) in the cell phone universe. If we live through covid, I may yet become an FSF card carrying member! (Likely with the Torvaldskist schismatic branchnicks who refuse to say "GNU/Linux"). The bright side is that there is no automatic self destruct mechanism in Linux so even when the official support is ended we can still user what we have but not be able to upgrade our applications. So true, if not for C++11, I would say "SL6 forever!". ... the cost of just dumping 50 systems and install new OS's and applications is beyond our budget. ... Even for people with deep pockets, administrative, logistics, downtime and man power costs make it impractical, except for "once every 5-10 years". People who just invested in a migration to el8 to be told now that they have to migrate again next year must be severely unhappy right now. I cannot fathom how Red Hat did not "ask around" before going public with their decision. (unless the decision was forced on them externally). So the sword had many sharp edges. Well, it is the dull sword that is most dangerous (to the user). Join your local Iaido club and find out for yourself.
Re: CentOS 8 EOL; CentOS Stream?
If my recollection of the history is correct, CentOS and Princeton EL were separate from SL. CentOS originally was a "volunteer" effort building from RHEL source, with RH personnel monitoring the CentOS "lists" because CentOS had a wider range of an installed base on enthusiast and home user systems, in addition to "professional" systems (such as the HP Zbook laptop workstation that I use). The earlier SL major releases had some differences in the base installed system from EL "stock", whereas CentOS did not. Later major releases of SL essentially were the same in the "base" as EL (in all cases, logos must change). I never worked with the Princeton release. When RH (not Fedora -- real production RH) was an executable installable supported distro, pre-EL, we used that, licensed for free for "personal" use. Prior to RH, I was using Debian (the GNU Linux), and once RH had no executable installable supported distro, I switched to CentOS. I then switched to SL because CentOS was having issues and SL was professionally produced (Fermilab/CERN) with the level of professional support we needed (that is, this list, plus Fermilab SL support staff who would fix some things -- such as inconsistencies or missing components in the standard SL distro -- we do NOT need nor use "commercial cradle to grave" handholding support, unlike the University IT division for which everything essentially is outsourced to for-profit vendors, as part of the USA scheme for public funding of private for-profit entities and wealth transference to the wealthy. With the demise of SL 8 and the purchase of RH and CentOS by IBM, I switched to Ubuntu LTS. If Canonical goes the way of RH, then I suppose I will look at Debian again. On 12/9/20 10:47 AM, Konstantin Olchanski wrote: Very curious how CERN and Fermilab will respond to this. I guess that CERN was caught red-handed as well. (wrong metaphor? you wanted "with pants down" or "off guard" or something like that? there is no evidence that CERN was "in" on this change, yes?) They have already started to port their internal systems to CentOS8 according to the recent site report at HEPiX: https://indico.cern.ch/event/898285/contributions/4015535/attachments/2120621/3569557/CERN_Site_Report_-_HEPiX_Autumn_2020_v2.pdf As one may remember, CERN Linux, SL and CentOS only exist because CERN could not agree with Red Hat on the licensing scheme for LHC-scale computing. (I guess, at the LHC scale, even small numbers like $1/license become unworkable). BTW, in other news, I see the CentOS wiki was changed to read "CentOS-8 full updates and Maintenance Updates" from "May 2024 and May 2029" to "December 2021 and December 31, 2021", see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_action_recall_About_Product=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=eMvBVbBFwtBD5Xbw1LErGQIapxF_ioOOJoO-OqCNa6g=CaCDrxtp7Ka4fRCXAiVCT34Zxxx_VD19P2hQeMXliqs= and https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.centos.org_action_recall_About_Product-3Faction-3Drecall-26rev-3D122=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=eMvBVbBFwtBD5Xbw1LErGQIapxF_ioOOJoO-OqCNa6g=dx8Ilr6PNf35kZ8hodzZ5JC9z40X9p5iMktTifR_C34=
Re: Dose any of this surprize you.
If your employer is a for-profit entity, then the neo-liberal profiteer
model indicates your firm should be funding ("paying for") what it uses,
except for the neo-liberal reality of "welfare for the wealthy". As
your employer is using SL, supported from public funds in different
nations (e.g., the funders of Fermilab and CERN), perhaps assisting
setting up what would be in the USA a non-profit corporation for the
development, maintenance, and distribution (e.g., software download over
the Internet) of an "enterprise" production linux (or BSD, or ... ,
"unix" clone) would address what you describe below. This could
(should?) include various non-profit university partners. The entire
distro would be professionally developed and maintained with dedicated
professional (not amateur) staff, as is done at both Fermilab and CERN.
However, a university, or consortium thereof, cannot do this, at least
within the USA, because of the funding and revenue models. Given the
endowment of Harvard and/or Stanford in the USA, it is possible that
these entities internally could fund such a development. [Aside: It also
is likely that the PRC could (and probably) will fund such; however, any
application, firmware, etc., from the PRC owes primary allegiance, as
specified by PRC law, to the PRC totalitarian government through The
Party, and thus can only be used with great caution by those who do not
share such fealty. If you think IBM is arbitrary and capricious (as
evidenced by the CentOS reality), consider the dictates of the PRC
government.]
Outside of the conversion issues, for now, Ubuntu LTS seems to meet the
same niche as SL. There are other distros based upon Ubuntu (e.g.,
Mint), so there could be a SLubuntu that is based upon LTS. One thing I
personally would like is a LTS list that is the same as this SL list.
None of the "lists" that I have found for Ubuntu are equivalent to this
SL lists. I can elaborate upon the differences if there is any interest.
However, for SLubuntu or the like, some entity needs to provide the
level of professional staff that Fermilab/CERN provided for SL. Unlike
Fermilab that survives based upon the whim of the USA Federal government
(currently, Trump et al., decidedly pro-theocracy and anti-science, else
the USA would not be suffering from COVID-19 as it is and withdrawn from
the WHO, etc.), and may suffer the same fate as Arecibo (strictly a
matter of funding -- had the repairs and maintenance been done, rather
than "deferred maintenance", that facility would not have collapsed),
CERN appears to have a more stable funding source (by treaty or the
equivalent?). Very few if any USA universities have the same stable
funding.
Yasha Karant
On 12/9/20 7:25 AM, Larry Linder wrote:
In the early days of Windows 3.0 and OS/2. Windows 3.0 was short lived
because every user knew it was a dog.
OS/2 was pretty nice but had a fatel flaw as it only had one exit que.
i a program dies and not gracefully it was rebo0t time.
This is trivia trash but reflects on the Corporate Character of the
perpetrators.
RH 8 and Cent 8 should die quickly. The community with the support of a
stable university should restart SL.
Everytime I am forced to use Windows 10 my neurons rebel at the moron
aware SW.
If the linux community took a stable set of Linux and made 25 functional
improvement a year and I don't mean rearanging the fruniture or new eye
candy. Most of our computing OS nightmares would go away.
As an example I just opted to get a new version of VariCAD and during
installation it requested two different libc.SO's and a new C++
compiler.
Tor rebuild the libc.so for 2.15 took almost 20 minutes it worked. I
froze at rebuilding the C++ lib after looking at it.
One thing I learned from the people at "stackOverflow" was that 2.15 did
not contain all of 2.10 or 2.11 or 2.12. etc. The latest is 2.34. The
tangled web of good intentions is killing Linux.
Without the stability of RH most developers will flounder and sink. As
the supporters of GNU retire and die off - the new generation has no
desire to stay the course.
Without the long term stability the applicaions / CAD developers will
abandon it too.
The bright side is that there is no automatic self destruct mechanism in
Linux so even when the official support is ended we can still user what
we have but not be able to upgrade our applications.
We are a commercial user since SL 4. As a for profit organization the
cost of just dumping 50 systems and install new OS's and applications is
beyond our budget. A few new machines are introduced each year to
support engineering / development. Most are used in the shop / factory
as you would use a dish washer - just an appliance. The primary goal is
stability.
So the sword had many sharp edges.
My 2 Cents worth
Larry Linder
Re: CentOS 8 EOL; CentOS Stream?
I agree with your sentiments, based upon several informal discussions I have had with CentOS 8 "adopters". "Supported" RHEL 8 seems to be better -- but are there still issues with EPEL, etc., because of inappropriate sub-system designations (as with the python example you provide)? From what I can tell, Ubuntu LTS is a bit more "adaptable". Given the tool set and source partitions you describe, fortunately, I currently am not porting from source, and compile applications from source only when the "source" has a specification for the actual distro release that I use. On 12/8/20 7:11 PM, Nico Kadel-Garcia wrote: On Tue, Dec 8, 2020 at 9:31 PM Konstantin Olchanski wrote: On Tue, Dec 08, 2020 at 04:39:32PM -0800, Patrick J. LoPresti wrote: It has been almost exactly seven years since Red Hat bought CentOS The way I remember it, RedHat approached CentOS lead developers and made them an offer they could not refuse. Very curious how CERN and Fermilab will respond to this. Nothing from CERN yet. But to sense where the wind is blowing, note how ROOT still do not provide a binary kit for CentOS-8. https://root.cern/releases/release-62206/ Our experiment at CERN (ALPHA anti-hydrogen trapping and spectroscopy) uses CentOS-7 and we are in discussions over upgrading to CentOS-8 or Ubuntu LTS 20.04. All our RaspberyPi machines will probably become converted from CentOS-7 to Raspbian (Ubuntu/Debian). For DAQ and analysis machines, there is a preference for CentOS-8, but if we they tell us now that CentOS-8 is a dead end and in 1 year will will have to upgrade *again*, Ubuntu may become the preferred solution. I'm unhappy with CentOs 8. The primary python 3 is already obsolete, python 3.6, and should have been published as "python36" rather than "pythone3" to allow a compatible "python38" parallel upgrade path. Unfortunately, they've convinced EPEL as well to name packages "python3" for "python36" packages in EPEL 7 and EPEL 8. Guess what fun this causes over in the Amazon Linux world, where "python3" is "python37" and python modules from EPEL can no longer be used safely. Do not get me *started* on "modular RPMs", which have proven very destabilizing for building anything, for which there is no usable documentation on how to build them or resolve circular incompatibilities. And the unnecessary and unwelcome split among the channels "base", powertools", "appstream" and "my uncle's secret ninja repo that RHEL originally refused to publish because you shouldn't need those to compile things we compile in-house", now called "devel" were unwelcome splits. And oh, the "we leave out encryption related components for popular open source tools that we used to publish in RHEL 7" have eaten my development time building up python module tool chains, especially for awx, the ansible tower equivalent. I'm pretty unhappy about it.
Re: CentOS 8 EOL; CentOS Stream?
For those who want to be nauseated, here is the essential quote of the post: The future of the CentOS Project is CentOS Stream, and over the next year we’ll be shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream, which tracks just ahead of a current RHEL release. CentOS Linux 8, as a rebuild of RHEL 8, will end at the end of 2021. CentOS Stream continues after that date, serving as the upstream (development) branch of Red Hat Enterprise Linux. Translation -- as a for-profit vendor, IBM does not want to subsidize a competitor to RHEL that is without fee. Building RHEL from the source, that IBM RH is required to distribute under the terms of the license from which the source is obtained, is resource prohibitive. I do not know the fate of the next Princeton clone of RHEL. What will the various HEP collaborations do? Will Fermilab/CERN provide internal professional person power (not just grad students and postdocs for whom such support is only as much as their research supervisor requires) to maintain an internal RHEL 8 clone from RHEL source? Given that the public pronouncements were to use CentOS 8 as the RHEL 8 clone in the HEP production environments, and that this is now not "long term" possible (CentOS stream is beta at best -- more or less a Fedora like unsupported cycle), one may be curious as to the future of HEP. It is possible that IBM (that has branches almost everywhere in the nations from which HEP collaborators are housed) will decide for a publicity-gain and tax-write-off to partner with Fermilab/CERN and license RHEL 8 (and 9 and ... ) at either a very reduced fee or for "free". But what about those of us who are not in such a HEP collaboration? I too have heard some nasty comments about Oracle EL 8 in terms of Oracle really using it more or less as a lure with the eventual goal of fund extraction from those who attempt to use the executable distro licensed for free. Also, what about the various professional add-on distros, such as EPEL or ElRepo? I suspect that I made the "correct" planning decision to switch to Ubuntu LTS (until such time as Canonical follows the RH IBM path ...). For those contemplating such a move, the changes are not that drastic, particularly if one "debugs" on a single sample of each class of machine (workstation, server, etc.). I am willing to provide my notes (howtos) that I have garnered for Ubuntu LTS (my machine currently is 20.04.1 LTS, and there is a 18.04 LTS machine that shortly will upgrade-in-place to 20.04 LTS -- both are laptop workstations, not "enthusiast home use" machines, one Dell, one HP). For applications that are standardized for EL (we had these on a high performance compute server with a particular Infiniband implementation, but that machine largely is now obsolete), I am not certain what would be involved in porting -- if the libraries (typically, .so) are available in LTS, this should be not too difficult -- particularly on a set of replicated installs. An additional large question for the community is the future of the X86-64/Nvidia GPU architecture. The latest Fujitsu HPC is ARM based, as are the latest Mac OS machines. Is ARM coming of real use beyond "smart phones" and the like, but as "real computers"? Take care. Stay safe. On 12/8/20 3:38 PM, ~Stack~ wrote: Anyone else on the verge of tears after reading today's CentOS blog post? https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.centos.org_2020_12_future-2Dis-2Dcentos-2Dstream_=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=t2J9jUFVgun90FIMquH4QRfvlPyoP8v5iYSZEcA87_g=-5u1jeYbTrmg0sZScxVN-0qJ1ifC2BEGlmW4_B70SYw= If you don't know CentOS Stream, it's "upstream RHEL". No, not Fedora. Yes, that too is "upstream RHEL". CentOS Stream a rolling release (so good luck getting long term steady kernels/packages) that is trying to be Arch like but with RHEL flavor. It sits in between RHEL and Fedora. It isn't and won't track steady releases like RHEL. It will have things before RHEL, except for security patches which will still come in whenever someone gets around to it. And, no, they still won't tag their security patches as such because they expect you to apply patches (and potentially reboot) at their whim. For those of us in the scientific community who have packages from vendors that standardize on RHEL dot releases, I'm not sure what we're going to do. We have RHEL licensing on the important infrastructure nodes but the hundreds of compute nodes, VM's, dev systems, and misc? Going all RHEL would kill our budget. And I don't care if Oracle Linux is free or how good of a clone it is, you only get burned by Oracle once (and you are usually to broke to be burned a second time). I suppose we can shift nearly all of our infrastructure to Ubuntu LTS but there's a lot still left that I'm not sure we can move to
Migrations to other linux distro
With the non-existence of SL8, I (and others) have been investigating alternatives to EL. For the present, I have settled upon Ubuntu LTS, that more or less has the same niche as EL, with the regular non-LTS Ubuntu being similar in niche to Fedora. This posting is not an advertisement for Ubuntu, nor am I affiliated with Canonical (just as I am not affiliated with Red Hat nor IBM). The summary below discusses why I have migrated my machines from SL and what I have observed that may be useful to others who face the lack of SL for EL8 and are not necessarily enthusiastic about the other available without fee binary bootable installable (not just source) EL8 distros. My wife had to get a new touchscreen (writing by hand with a stylus) laptop, and thus I started the migration with her machine as EL7 would not suffice for her hardware and application needs. A month or so past, the screen (internal to the laptop cover) on my machine failed -- a circumstance that motivated to examine alternative Linux distros. Given the major surgery required to replace the lid, I ordered an identical machine now only available in refurbished (with a warranty) from a reputable web-based source. Removing the hard drive from the failed machine (SL7 current), I installed it in the new machine and copied all of the non-distro directories and files to a 2 Tbyte external USB drive. I then installed a new 2 Tbyte hard drive into the "new" machine, removing the MS Win 10 SSD drive supplied with it in the event the machine would need to be returned. (On the laptop in question, this is a simple procedure; I do have an "anti-static" work-surface mat with wristband.) I had installed a bootable ISO installation image of Ubuntu 20.04.1 LTS on an external USB "thumb drive", and proceeded with the installation. Because I wanted a custom partitioning of the hard drive, there were a few false starts; having done this, I can offer some advice to anyone interested. I have configured the machine with MATE from Ubuntu, and installed all of the utilities I had used on SL plus some that seemingly were not available for SL 7. Naturally, yum, yumex, etc., are replaced by various apt utilities, but the functionalities, if not the actual CLI commands or GUI steps, are equivalent. The only peculiarities I have found to date are that unlike SL, LTS assumes that everything must be done via sudo. As I prefer both su and an Xwindow GUI root screen, I had to modify some of the LTS configuration files to do this, but it is quite simple (in the current LTS). Both of these functionalities now work. The support and help lists are much more cumbersome than this SL users list, with a formal style guide, etc., moderators, etc., although there are no style configuration files that work with LaTeX, MS Office (and thus, for the most part, LibreOffice), etc., unlike most journals and professional refereed conferences to which I submit work. As far as I can tell from workstation (not server) use, Ubuntu LTS works as well as SL, seems to be stable with regular security updates, and has the same utilities, etc., that any modern stable Linux distro does. Moreover, unlike EL, LTS seems to support more hardware variants and keeps more "current" allowing "current" production releases of utilities to function (such as the current production Texstudio). It has also been stated than unlike SL, LTS allows for upgrade-in-place to the next major LTS production release. The caution for this procedure is to nonetheless backup all non-distro directories and files to an external device so that things can be retrieved if something were to go awry. Take care. Stay safe. Yasha Karant
Re: AppImage under SL 7
On 8/26/20 11:10 PM, Götz Waschk wrote: Am 27.08.20 um 02:29 schrieb Yasha Karant: I still am attempting to migrate to Texstudio 3 production current release. I have found on the Texstudio web site an appimage file for Texstudio 3. From: https://urldefense.proofpoint.com/v2/url?u=https-3A__itsfoss.com_use-2Dappimage-2Dlinux_-23-3A-7E-3Atext-3D-2520How-2520to-2520use-2520AppImage-2520in-2520Linux-2520-2CStep-25203-253A-2520Run-2520the-2520AppImage-2520file-2520More-2520=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=A1vT-VWIR0wKymGxmZBrmYvDO6ec1JTnvizEqWzIpkA=03Rv0itPKadgSlR6ylyg3oj3iQHNQOMDlIK77t3Ny1k= NB: Because I cannot seem to have my email changed from csusb.edu to gmail.com , the above URL will be modified and perhaps garbled. AppImage doesn’t do it. In fact, AppImage doesn’t really install the software. It is a compressed image with all the dependencies and libraries needed to run the desired software. However, after as root doing a chmod a+x on texstudio-3.0.0-x86_64.AppImage I find: ykarant@localhost Downloads]$ ./texstudio-3.0.0-x86_64.AppImage ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ./texstudio-3.0.0-x86_64.AppImage) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./texstudio-3.0.0-x86_64.AppImage) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./texstudio-3.0.0-x86_64.AppImage) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libQt5Core.so.5) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libpoppler.so.58) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libproxy.so.1) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libproxy.so.1) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libicui18n.so.55) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libicuuc.so.55) End output. Thus, clearly "image with all the dependencies and libraries needed to run" is not factual. Are the required .so lib files available for EL 7 and will not cause other applications/kernel to fail? If these are available, relevant URLs (or what to install under yum) would be appreciated. Dear Yasha, yes, the claim of bundling all dependencies is invalid, there are exceptions for the C library and the C++ standard library. These are so important you cannot update them on your Scientific Linux machine without breaking it. I think you cannot install this software on SL7, it is simply too old. A container solution like Singularity would have problems as well, as there is a certain kernel dependence. I can report from my own experience, that a container based on Ubuntu 20.04 and Qt5 will still not run on SL7. The only way to run it would be a real virtual machine. Regards, Götz Waschk Dear Götz, Thank you for the prompt and clear reply that confirmed what I thought: because the C/C++ environment against which the kernel and related systems utilities have been compiled is of, say, release N, but the application is compiled against, say, release N+M (M > 0), only by changing the C/C++ environment is it possible to run the application, but this change causes the kernel, etc., to fail. Moreover, as you have indicated, in a monolithic kernel system such as Linux (not a micro kernel system), even standard encapsulation will fail. I assume that the latest Texstudio will run under EL 8. There are thus only two solutions: a true virtual machine with a hypervisor under the kernel (e.g., VirtualBox) that then runs some other operating system environment (as I currently do with MS Win10 so that I can use specific proprietary applications that only run under MS Win or MacOS X (MacOS X may not be installed in the USA on any hardware platform that does was not sold by Apple with the Apple logo due to USA legal restrictions), or a "later" Linux operating system. At this point, I presume that I must switch to Ubuntu LTS current. According to numerous correspondents, unlike EL, one can upgrade in place from one major release of Ubuntu LTS to the next, albeit with the usual precautions (backup image of the system in case some does fail). I could install Texstudio 3 under MS Win 10 (there is a binary installable release for this purpose) under VirtualBox under SL 7, but as I use
AppImage under SL 7
I still am attempting to migrate to Texstudio 3 production current release. I have found on the Texstudio web site an appimage file for Texstudio 3. From: https://urldefense.proofpoint.com/v2/url?u=https-3A__itsfoss.com_use-2Dappimage-2Dlinux_-23-3A-7E-3Atext-3D-2520How-2520to-2520use-2520AppImage-2520in-2520Linux-2520-2CStep-25203-253A-2520Run-2520the-2520AppImage-2520file-2520More-2520=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=A1vT-VWIR0wKymGxmZBrmYvDO6ec1JTnvizEqWzIpkA=03Rv0itPKadgSlR6ylyg3oj3iQHNQOMDlIK77t3Ny1k= NB: Because I cannot seem to have my email changed from csusb.edu to gmail.com , the above URL will be modified and perhaps garbled. AppImage doesn’t do it. In fact, AppImage doesn’t really install the software. It is a compressed image with all the dependencies and libraries needed to run the desired software. However, after as root doing a chmod a+x on texstudio-3.0.0-x86_64.AppImage I find: ykarant@localhost Downloads]$ ./texstudio-3.0.0-x86_64.AppImage ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by ./texstudio-3.0.0-x86_64.AppImage) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by ./texstudio-3.0.0-x86_64.AppImage) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ./texstudio-3.0.0-x86_64.AppImage) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libQt5Core.so.5) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libpoppler.so.58) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libproxy.so.1) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libproxy.so.1) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libicui18n.so.55) ./texstudio-3.0.0-x86_64.AppImage: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /tmp/.mount_texstuAlu96i/usr/bin/../lib/libicuuc.so.55) End output. Thus, clearly "image with all the dependencies and libraries needed to run" is not factual. Are the required .so lib files available for EL 7 and will not cause other applications/kernel to fail? If these are available, relevant URLs (or what to install under yum) would be appreciated. Please reply to ykar...@gmail.com Take care. Stay safe. Yasha Karant
Re: Texstudio 3
My mistake -- I pasted from the wrong screen when in a hurry. ykarant@localhost texstudio-org-texstudio-b6ce6f5]$ ./BUILD.sh TeXstudio compilation : Enter SYSTEM (1: UNIX ; 2: MACOSX) (default is 1) : 1 Enter PREFIX (/usr , /usr/local or /opt) (default is /usr/local) : /opt Enter path to QT4/5 base directory (e.g. /usr/lib/qt4, you can leave it empty if qmake is in PATH) (default is ) : /usr/lib/qt5 Enter path to QT4/5 executable file (e.g. qmake or qmake-qt5) (default is qmake) : Do you want to use the internal pdf viewer (requires the Poppler library)? (yes/no) (default is yes) : Do you want to use the video player in pdf files (requires the Phonon library)? (yes/no) (default is no) : Do you want an internal terminal widget (requires the qtermwidget5 library)? (yes/no) (default is yes) : Do you want to build a debug or release version? (default is debug) : release Do you want to enable the debug logger? (yes/no) (default is no) : Do you want to install TexStudio after building it? (yes/no) (default is yes) : Warning, QT path may be invalid Starting compilation ./BUILD.sh: line 134: qmake: command not found make: *** No targets specified and no makefile found. Stop. Compilation done make: *** No rule to make target `install'. Stop. Installation done Icons and desktop file can be found in the /opt/share/texstudio directory [ykarant@localhost texstudio-org-texstudio-b6ce6f5]$ which qmake /usr/bin/which: no qmake in (/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/var/lib/snapd/snap/bin:/home/ykarant/.local/bin:/home/ykarant/bin) [ykarant@localhost texstudio-org-texstudio-b6ce6f5]$ I have looked for qmake and even after that is found, I suspect that there will be additional missing utilities, dependencies, or revision levels. Thanks. Again, please reply to ykar...@gmail.com On 8/25/20 6:50 PM, Chris Schanzle wrote: On 8/25/20 7:48 PM, Yasha Karant wrote: Please reply to ykar...@gmail.com Take care. Stay safe. I was attempting to migrate from production release of Texstudio 2.x to Texstudio 3.x . I could not find any EL7 RPM packages for Texstudio 3.x . I then downloaded the source and attempted to build with the result below -- failure. Does any have or is planning to have a Texstudio 3 EL7 RPM (or SNAP package)? Thanks, Yasha Karant [root@localhost Downloads]# yum install ./texstudio-3.0.0-6.1.x86_64.rpm Loaded plugins: langpacks, nvidia Repository sl is listed more than once in the configuration Examining ./texstudio-3.0.0-6.1.x86_64.rpm: texstudio-3.0.0-6.1.x86_64 Marking ./texstudio-3.0.0-6.1.x86_64.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package texstudio.x86_64 0:3.0.0-6.1 will be installed --> Processing Dependency: libstdc++.so.6(CXXABI_1.3.8)(64bit) for package: texstudio-3.0.0-6.1.x86_64 --> Processing Dependency: libstdc++.so.6(CXXABI_1.3.9)(64bit) for package: texstudio-3.0.0-6.1.x86_64 --> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.20)(64bit) for package: texstudio-3.0.0-6.1.x86_64 --> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) for package: texstudio-3.0.0-6.1.x86_64 --> Processing Dependency: libpoppler-qt5.so.1()(64bit) for package: texstudio-3.0.0-6.1.x86_64 --> Finished Dependency Resolution Error: Package: texstudio-3.0.0-6.1.x86_64 (/texstudio-3.0.0-6.1.x86_64) Requires: libpoppler-qt5.so.1()(64bit) Error: Package: texstudio-3.0.0-6.1.x86_64 (/texstudio-3.0.0-6.1.x86_64) Requires: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) Error: Package: texstudio-3.0.0-6.1.x86_64 (/texstudio-3.0.0-6.1.x86_64) Requires: libstdc++.so.6(CXXABI_1.3.8)(64bit) Error: Package: texstudio-3.0.0-6.1.x86_64 (/texstudio-3.0.0-6.1.x86_64) Requires: libstdc++.so.6(GLIBCXX_3.4.20)(64bit) Error: Package: texstudio-3.0.0-6.1.x86_64 (/texstudio-3.0.0-6.1.x86_64) Requires: libstdc++.so.6(CXXABI_1.3.9)(64bit) You could try using --skip-broken to work around the problem Given the info provided, you didn't download "source" and "build" you downloaded a binary rpm for likely a different distribution with different libraries, perhaps from https://urldefense.proofpoint.com/v2/url?u=http-3A__download.opensuse.org_repositories_home-3A_jsundermeyer_Fedora-5F24_x86-5F64_=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=x59CEm3-GhJHXFZzUgBZD9r7wCdv47xnFJFvcZJ5h0E=bn5s_ENenBjDKXmFlVcED_MT0asKeMinpfCZav0WAng= which as the URL describes, is Fedora 24 and appears to be the official downloads texstudio.org points to. Making an installable binary rpm by "building from source" requires a src.rpm and using rpmbuild or mock to create the installable rpm. My best suggestion is to contact someone at texstudio.org for a CentOS/SL/RHEL 7 build. Perhaps trying to build the .src.rpm, found in
Texstudio 3
Please reply to ykar...@gmail.com Take care. Stay safe. I was attempting to migrate from production release of Texstudio 2.x to Texstudio 3.x . I could not find any EL7 RPM packages for Texstudio 3.x . I then downloaded the source and attempted to build with the result below -- failure. Does any have or is planning to have a Texstudio 3 EL7 RPM (or SNAP package)? Thanks, Yasha Karant [root@localhost Downloads]# yum install ./texstudio-3.0.0-6.1.x86_64.rpm Loaded plugins: langpacks, nvidia Repository sl is listed more than once in the configuration Examining ./texstudio-3.0.0-6.1.x86_64.rpm: texstudio-3.0.0-6.1.x86_64 Marking ./texstudio-3.0.0-6.1.x86_64.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package texstudio.x86_64 0:3.0.0-6.1 will be installed --> Processing Dependency: libstdc++.so.6(CXXABI_1.3.8)(64bit) for package: texstudio-3.0.0-6.1.x86_64 --> Processing Dependency: libstdc++.so.6(CXXABI_1.3.9)(64bit) for package: texstudio-3.0.0-6.1.x86_64 --> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.20)(64bit) for package: texstudio-3.0.0-6.1.x86_64 --> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) for package: texstudio-3.0.0-6.1.x86_64 --> Processing Dependency: libpoppler-qt5.so.1()(64bit) for package: texstudio-3.0.0-6.1.x86_64 --> Finished Dependency Resolution Error: Package: texstudio-3.0.0-6.1.x86_64 (/texstudio-3.0.0-6.1.x86_64) Requires: libpoppler-qt5.so.1()(64bit) Error: Package: texstudio-3.0.0-6.1.x86_64 (/texstudio-3.0.0-6.1.x86_64) Requires: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) Error: Package: texstudio-3.0.0-6.1.x86_64 (/texstudio-3.0.0-6.1.x86_64) Requires: libstdc++.so.6(CXXABI_1.3.8)(64bit) Error: Package: texstudio-3.0.0-6.1.x86_64 (/texstudio-3.0.0-6.1.x86_64) Requires: libstdc++.so.6(GLIBCXX_3.4.20)(64bit) Error: Package: texstudio-3.0.0-6.1.x86_64 (/texstudio-3.0.0-6.1.x86_64) Requires: libstdc++.so.6(CXXABI_1.3.9)(64bit) You could try using --skip-broken to work around the problem
updating Mozilla Firefox and Thunderbird
I do not use distro releases of Mozilla Firefox, Thunderbird, or Google Chrome, but rather updating to current production (not beta) from the actual provider. In the past, when, say, Firefox would announce that an update was available but that I (as myself, not root) did not have sufficient privileges to update, I would exit the application, switch user (not sudo) and login as root in MATE, activate the application, perform the update, exit the application, and then switch back to my ordinary user account. Upon so doing, I would activate the updated application, and verify that I was using the latest updated release. This always used to work. Now, when I switch back, although the application is not revealed by ps (under any UID, not just mine), the pre-update version is still in use until I actually logout and re-login (not just switch user). Thus, although the application is not in use when it was updated, a login session (at least through MATE) must be caching the "old" binary executable image, and not loading a fresh updated one from the file system. Other than log out and log in, is there a mechanism for "flushing this one application entry from the cache"? Currently, SL 7.8 . Take care. Stay safe. Yasha Karant
Re: off SL
I have done upgrade in place (no new harddrive unless we needed a larger capacity drive) on several unix/bsd derivatives. Your file system comments are very well taken. However, using "stock" Ubuntu LTS for the OS and file system, is your experience contrary to those of others? On 5/26/20 7:21 PM, Nico Kadel-Garcia wrote: On Tue, May 26, 2020 at 3:54 PM Troy Dawson wrote: Although in the past the official policy of Red Hat was that you needed to do a fresh install going from EL N to N+1, that is starting to change. There is an internal team called "LEAP" whose job it is to make sure you can do that. I believe RHEL 7.8 to RHEL 8.1 was the first that you could officially do that. I don't know all the details. all I know is "we're working on it." I'm pretty sure that at the current time we aren't as smooth as Debian, they've been doing it much longer. But we're getting better, and for RHEL9, LEAP is being involved from the start. So maybe in a few releases / years people will be able to say our updates are as good, or even easier than debians. Been there, done that. It works great until it doesn't. While updating the RPM's may be feasible, there have been subtle changes in filesystems which man starting with an old filesystem is prone to errors, and upgrading in place is not a reliable process. *All* operating systems are prone to such issues, unless you can basically mount the old file system as an image and apply the updates from outside. I've done upgrades with approximately 20,000 Red Hat based systems, over my career, and others. If you were foolish enough to use ReiserFS, for example, you'll *really* need to rebuld your filesystems in between OS upgrades..
off SL
I need to upgrade my wife's machine from Ubuntu 18 LTS to 20 LTS at the earliest convenient time (that may be after the end of this academic term to avoid disruption). She runs Ubuntu on her 2-in-1 as evidently SL 7 does not support all of the hardware functionality that she needs. I have found a URL with detailed instructions that I am willing to forward the information as a PDF to whomever has done this and is interested. My understanding is that unlike EL that more or less requires a new install to go from EL N to EL N++, Ubuntu will upgrade in place. If anyone has done this, please reply, preferably off list to ykar...@gmail.com so that any URLs will not be "modified" by the security filters at my university. Take care. Stay safe. Yasha Karant
Re: Desired packages
On 5/20/20 8:07 PM, Orion Poplawski wrote: On 5/19/20 11:03 PM, Arthur H. Edwards wrote: I'm running SL7. Is there a kbibtex package? is there a gnuplot-qt package? Art Edwards kbibtex is in EPEL. I'm not aware of a gnuplot-qt package for EL7. I assume https://urldefense.proofpoint.com/v2/url?u=https-3A__centos.pkgs.org_7_centos-2Dx86-5F64_gnuplot-2D4.6.2-2D3.el7.x86-5F64.rpm.html=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=26k6YzPZxqf1Kzd7S-h00y5eZPKRP40M5692rirnU4g=4D1awmP2uODznIVCujeY688LHlh1MMuaR2jcRKBgb-0= that will appear to you with security filter modification to the URL will not suffice?
Re: gscan2pdf
On 5/18/20 4:54 AM, Nico Kadel-Garcia wrote: On Mon, May 18, 2020 at 2:13 AM Akemi Yagi wrote: On Sun, May 17, 2020 at 8:18 PM Yasha Karant wrote: I have found gscan2pdf on the NUX repo, but installing this repo evidently will add and replace many utilities, etc., that may not be wise. gscan2pdf runs fine on Ubuntu 18 LTS as I just put in on my wife's 2-in-1 that does not have tablet write-on support under SL 7 as far as I can determine. Is there any SL 7.8 compatible gscan2pdf that works? Take care. Stay safe. Yasha Karant I've been using gscan2pdf from the nux-dextop repository without any issue. Also, this repository, together with EPEL, should not overwrite any base package. Akemi I'm personally reluctant to trust third party RPM repositories from Romania, they have a very active and abusive cracker community.but the SRPM from https://urldefense.proofpoint.com/v2/url?u=https-3A__li.nux.ro_download_nux_dextop_el7_SRPMS_gscan2pdf-2D1.2.5-2D2.el7.nux.src.rpm=DwIBaQ=B_W-eXUX249zycySS1AyzjABMeYirU1wvo9-GmMObjY=Z7xHp2tIJsvAE2FtPxl_lynvf4hA_FJ8mKsaIgvY6Dk=knBIe0JxmSUI-af995EwuorG9qw79W1SDujA9o1-DW4=KAdL127uDliK692ZlpFMVwEGC9HREwkQ80agoYvObHc= looks clean and builds well. Niko. If you are building from a src RPM, unless you read the source code or have a very good automaton code scanner (as done by some of the clandestine and other security agencies), how do you know that there is no "malware" embedded in the source? For example, a "clean" source may require the use of a compromised library or (in the cases of fork and exec) executable, unless no related RPMs (or DEB, etc.) come from the repo that may be questionable. Akemi indicates no problem from experience, but does Akemi have safeguards and "sniffers" running that would detect an inappropriate packet being transmitted (that might contain root password or other "sensitive" information)? If you have built the RPM and are reasonably confident that it is "clean", could you kindly post or supply the exact build script that you used, including any other RPMs that are required but that come from trusted repos? I generally trust SL (and EPEL, ElRepo, Oracle, Canonical, Mozilla, Libreoffice, etc.), but I get worried about repos and sources from nation-states or entities with large scale compromise organizations (e.g., professional "organized criminial" enterprises or clandestine services "backdoors"). Take care. Stay safe. Yasha Karant
gscan2pdf
I have found gscan2pdf on the NUX repo, but installing this repo evidently will add and replace many utilities, etc., that may not be wise. gscan2pdf runs fine on Ubuntu 18 LTS as I just put in on my wife's 2-in-1 that does not have tablet write-on support under SL 7 as far as I can determine. Is there any SL 7.8 compatible gscan2pdf that works? Take care. Stay safe. Yasha Karant
gcc 5.4.0 on EL 7
I use Calibre, and had hoped that SL 7.8 would support the recommended version (please see below). Calibre requires gcc 5.4.0, and I have appended the instructions for installing that gcc into CentOS 7 (and hence, SL 7). Will this change in gcc "break" the 7.8 system and applications, or will it "coexist" with the distro gcc? Stay safe. Take care. Yasha Karant From calibre: Download for Linux The latest release of calibre is 4.14.0. What's new <https://urldefense.proofpoint.com/v2/url?u=https-3A__calibre-2Debook.com_whats-2Dnew=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=_2oy9MKOcJoXiIsoZwTte8RteJIPnWCnVzs8pNIYQRs=2lk5dwQeJR7Im9W6a7uI2bA55eN_7wCM1sH6KRxQjlU= >. Please do not use your distribution provided calibre package, as those are often buggy/outdated. Instead use the Binary install described below. Binary install calibre has a binary install that includes private versions of all its dependencies. It runs on 32-bit and 64-bit Intel compatible machines. To install or upgrade, simply copy paste the following command into a terminal and press Enter: sudo -v && wget -nv -O- https://urldefense.proofpoint.com/v2/url?u=https-3A__download.calibre-2Debook.com_linux-2Dinstaller.sh=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=_2oy9MKOcJoXiIsoZwTte8RteJIPnWCnVzs8pNIYQRs=mlb0nfTKye-zuvJYigtgpBVXeNs2wGCTOUM5Ha0sNl8= | sudo sh /dev/stdin You need GLIBC 2.18 or higher and libstdc++.so.6.0.21 (from gcc 5.4.0) or higher to run calibre The script will install GCC 5.4.0 on your CentOS 7 system, make sure you have root right. See https://urldefense.proofpoint.com/v2/url?u=https-3A__jdhao.github.io_2017_09_04_install-2Dgcc-2Dnewer-2Dversion-2Don-2Dcentos_=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=_2oy9MKOcJoXiIsoZwTte8RteJIPnWCnVzs8pNIYQRs=Bou2POD4gEpWWg2jvzx6cMWrmoi9nY-8OJ80gsVPZFQ= for more details. *gcc-5.4.0-install.sh * <https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_jdhao_e3fd77d51f3a95684d2b3354fc61b2ab-23file-2Dgcc-2D5-2D4-2D0-2Dinstall-2Dsh=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=_2oy9MKOcJoXiIsoZwTte8RteJIPnWCnVzs8pNIYQRs=wWA1r6drZ-zwUjR-132gm1DMaKSguQ8i6I5uNFPc_1M= > echo "Downloading gcc source files..." curl https://urldefense.proofpoint.com/v2/url?u=https-3A__ftp.gnu.org_gnu_gcc_gcc-2D5.4.0_gcc-2D5.4.0.tar.bz2=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=_2oy9MKOcJoXiIsoZwTte8RteJIPnWCnVzs8pNIYQRs=KcsB-xMvSIIXTeiJl_VAlBOZPyFZK0bO0xyGGviQ5uo= -O echo "extracting files..." tar xvfj gcc-5.4.0.tar.bz2 echo "Installing dependencies..." yum -y install gmp-devel mpfr-devel libmpc-devel echo "Configure and install..." mkdir gcc-5.4.0-build cd gcc-5.4.0-build ../gcc-5.4.0/configure --enable-languages=c,c++ --disable-multilib make -j$(nproc) && make install
Snaps
Does anyone know how secure (safe, not malware, spyware, etc.) is Snaps? Please see below. Certain applications that are not available for EL but from other distros, particularly Ubuntu, evidently can be installed via Snaps. Epel is a standard EL repo, but Snaps is not. Enable snaps on CentOS and install Xournal++ Snaps are applications packaged with all their dependencies to run on all popular Linux distributions from a single build. They update automatically and roll back gracefully. Snaps are discoverable and installable from the Snap Store <https://urldefense.proofpoint.com/v2/url?u=https-3A__snapcraft.io_store=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=U_9rXUp841lroS3b1I6BqsdWAC2VbH7OW6jZvmufgR4=DNKiGAkXvPku8jga4qvfLCfuCm0yglT90PYysjDbwgs= >, an app store with an audience of millions. Enable snapd Snap is available for CentOS 7.6+ <https://urldefense.proofpoint.com/v2/url?u=https-3A__snapcraft.io_install_xournalpp_centos=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=U_9rXUp841lroS3b1I6BqsdWAC2VbH7OW6jZvmufgR4=6aJOdsxXdre3JCaGiI2VHJkrIlrmugEVVJ29rrzzgiQ= >, and Red Hat Enterprise Linux 7.6+, from the Extra Packages for Enterprise Linux <https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_EPEL=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=U_9rXUp841lroS3b1I6BqsdWAC2VbH7OW6jZvmufgR4=d0abLQSs1MMvnuo9AY7kbu0yBXuChcPX0YhPW64_DVE= > (EPEL) repository. The EPEL repository can be added to your system with the following command: Thanks for any information. Yasha Karant
Re: [SCIENTIFIC-LINUX-USERS] Future SL minor releases, was: Re: [SCIENTIFIC-LINUX-USERS] kdenlive progress, yum dependencies need to be added
Pat, Thank you for the answer, but there is a clarification that would be useful. When I just updated, the intro splash now displays Scientific Linux 7.8 , etc., not an IBM RH CentOS equivalent (and of course not a Red Hat). This means that your group at Fermilab (and at CERN?) is modifying whichever source you are using for EL (IBM RH, or IBM RH CentOS) to remove all "upstream branding". Until IBM RH (TUV) discontinues EL 7 support, e.g., security updates (2024?), is Fermilab/CERN still funding SL (and thus presumably employing you as part of your employment duties) to be independently built from source and not just a copy with a file name and branding changes from a built CentOS binary RPM? Although Fermilab/CERN is not responsible for EPEL, ElRepo, and other independent EL repos, many of us (including myself) depend upon those repos to add vital functionality (that might be integral to the Canonical Ubuntu "equivalent" of repos and thus supply .deb not .rpm files). Are these repos also going to update as EL 7 goes through updates? One Ubuntu question for anyone who can answer this. On EL, one has the monitor text command options of rpm and yum to get updates and added functionality roughly equivalent to apt in Ubuntu; is there an Ubuntu GUI equivalent of yumex? I have been using apt from a screen (or sudo apt if I am not logged in as root) but I personally find for "routine" operations (such as the "major" update I just did) it is more convenient to use yumex. Stay safe. Take care. Yasha Karant On 4/24/20 12:22 PM, Patrick Riehecky wrote: So long as the upstream source is published, we plan to continue Scientific Linux updates and new releases. Pat On Fri, 2020-04-24 at 12:18 -0700, Yasha Karant wrote: Thank you for the update. Although I could not find a listing for you at Fermilab through a web search engine (my fault), I did find https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_patriehecky=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=GmODBvzVccq62b85_5FqC1HOEq9xjkakc0x_NkH_UPM=PBlj4xQGhYUMveDLgNXtrHFOLrflQ6c3bCukF64rzRQ= which indicates that you are (paid) professional Fermilab staff assigned to SL, and presumably will be part of the Fermilab CentOS 8 team if all of the HEP CERN collaborations stay with CERN CentOS 8. The only reason I checked was to understand your official capacity to provide release information. As you can read below, my university does not allow unmodified (uncensored?) URLs to be transmitted -- the URL you posted has been modified in the email that I can see (one of the reasons I use my gmail account whenever allowed). The TUV life cycle is for RHEL 7 that is under paid subscription except in so far as RH is required by the GPL, etc., to release full source (no binaries). Will the SL group be adding these RHEL 7 updates, etc., to the SL distro repos? Will these be 7.9 ... or are future minor release number versions of RHEL 7 (that are reflected in SL 7) determined by IBM RH (TUV)? Will these only be from CentOS with the SL repos simply mirroring those at CentOS (part of RH and thus part of IBM), or will SL be doing independent builds? Any idea about EPEL, ElRepo, etc., updates as well? Thank you for any clarification. Stay safe. Take care. Yasha Karant On 4/24/20 10:10 AM, Patrick Riehecky wrote: On Thu, 2020-04-23 at 23:36 -0700, Yasha Karant wrote: is SL 7.8 the end of SL 7? The projected end of life for SL7 is June 2024. This is following TUV's lifecycle: https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_support_policy_updates_errata=DwIGaQ=B_W-eXUX249zycySS1AyzjABMeYirU1wvo9-GmMObjY=Z7xHp2tIJsvAE2FtPxl_lynvf4hA_FJ8mKsaIgvY6Dk=fYi-TgtnkkAnP39HKALbNwMQbeKUf-VzYQvK8v2Gwu0=ktFojwgMAipkzHysivjUStHOolz9UiOiDr2iR7LLkP4=
Future SL minor releases, was: Re: [SCIENTIFIC-LINUX-USERS] kdenlive progress, yum dependencies need to be added
Thank you for the update. Although I could not find a listing for you at Fermilab through a web search engine (my fault), I did find https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_patriehecky=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=GmODBvzVccq62b85_5FqC1HOEq9xjkakc0x_NkH_UPM=PBlj4xQGhYUMveDLgNXtrHFOLrflQ6c3bCukF64rzRQ= which indicates that you are (paid) professional Fermilab staff assigned to SL, and presumably will be part of the Fermilab CentOS 8 team if all of the HEP CERN collaborations stay with CERN CentOS 8. The only reason I checked was to understand your official capacity to provide release information. As you can read below, my university does not allow unmodified (uncensored?) URLs to be transmitted -- the URL you posted has been modified in the email that I can see (one of the reasons I use my gmail account whenever allowed). The TUV life cycle is for RHEL 7 that is under paid subscription except in so far as RH is required by the GPL, etc., to release full source (no binaries). Will the SL group be adding these RHEL 7 updates, etc., to the SL distro repos? Will these be 7.9 ... or are future minor release number versions of RHEL 7 (that are reflected in SL 7) determined by IBM RH (TUV)? Will these only be from CentOS with the SL repos simply mirroring those at CentOS (part of RH and thus part of IBM), or will SL be doing independent builds? Any idea about EPEL, ElRepo, etc., updates as well? Thank you for any clarification. Stay safe. Take care. Yasha Karant On 4/24/20 10:10 AM, Patrick Riehecky wrote: On Thu, 2020-04-23 at 23:36 -0700, Yasha Karant wrote: is SL 7.8 the end of SL 7? The projected end of life for SL7 is June 2024. This is following TUV's lifecycle: https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_support_policy_updates_errata=DwIGaQ=B_W-eXUX249zycySS1AyzjABMeYirU1wvo9-GmMObjY=Z7xHp2tIJsvAE2FtPxl_lynvf4hA_FJ8mKsaIgvY6Dk=fYi-TgtnkkAnP39HKALbNwMQbeKUf-VzYQvK8v2Gwu0=ktFojwgMAipkzHysivjUStHOolz9UiOiDr2iR7LLkP4=
Re: kdenlive progress, yum dependencies need to be added
John, Thank you for posting the item below. For a progress report: Using yumex, removing the opera repo that could not be found, and eliminating one conflicting package from the list of RPMs (making a guess as to which specific one needed to be removed, as I use the proprietary Nvidia Xwindows RPM and the conflict referenced nvidia, but not the actual kernel driver and related interfaces), I now have a SL 7.8 system on my laptop workstation. The issues with Firefox and Thunderbird seem to be resolved, and thus far, all of the applications I have tested, both those supplied by an EL repo as well as others (e.g., Nero Linux, Qoppa PDF Studio Pro, Grace, Paraview, UCSF Chimera, VMWare Player, VirtualBox, etc.) all seem to be working. Thus, the system was left in an unstable state when I did just enough to get Kdenlive to run. As it is almost midnight local time, I again have access to my university's IMAP and SMTP server (that in fact are for-fee Microsoft Exchange "cloud" services, throttled based upon the fee structure) as the systems at this hour of the night are not over-subscribed. Other than for security patches, is SL 7.8 the end of SL 7? If so, the next change I shall institute probably will be to Ubuntu 20 LTS that is due summer 2020. I know that the home directory and related non-systems directories are portable from SL 7 to Ubuntu 18 LTS and thus probably to Ubuntu 20 LTS, as I copied all of my wife's such directories from a conventional laptop running SL 7 to her new Dell 2-in-1 that she needs to provide an on-line chalkboard (e.g., a written virtual paper tablet using Stylus Labs write that does work with the Dell stylus -- only the internal microphone cannot be made to work because Dell will not release in any form the microphone code that is incorporated into the Dell supplied Ubuntu port that was used by Canonical Ubuntu to "certify" the machine as Linux supported -- Dell evidently will not allow that machine with Dell Ubuntu to be sold in the USA market, only a MS Win version). Once I installed Ubuntu LTS MATE, everything worked on her machine, and I suspect it will work on this one as well. Of course, I will image all of my personal, etc., directories onto a USB external harddrive from which I shall copy back to this machine once Ubuntu LTS is installed. At this point, I am not considering going to either CentOS or Oracle EL 8. As we have a residential DSL Internet connection, the yumex upgrade from start to successful reboot lasted approximately 5 hours. I had to wait until there were no Zoom sessions being required. Stay safe. Take care. Yasha Karant On 4/23/20 11:01 AM, John Pilkington wrote: I'm forwarding this at Yasha's request, and have added some extra info. On 23/04/2020 17:29, Yasha Karant wrote: Thank you for the kind reply. Because the USA for most purposes has an Internet infrastructure similar to the USA "health care" system in that it is amongst the most expensive but with poorer results than many other nations with lower costs (e.g., USA internal deregulation for profiteering), the university email server is not responding due to the much higher than anticipated (by the university information technology experts, not by myself and others) traffic load. Thus, I am requesting that if you do not know the answer, you kindly relay this email to the SL list, as my login thereunder is limited to my university email address. After performing the necessary steps (additional and/or revised packages) for Kdenlive to start, neither my current Firefox nor Thunderbird are operational. Given an understanding of both Murphy's Law and O'Toole's Corollary, I keep multiple access applications and routes open. In this case, I am using Seamonkey that seems to be functioning. Because I use the current production versions of both Firefox and Thunderbird from Mozilla, etc., not the distro, I did use yum to install the distro versions -- same issue. I also did a full cold reboot in the event that some stale information (a cached internal .so entry, etc.) was causing the issue (not really fully using the updates), but again, no Firefox, no Thunderbird. I currently am backing-up via cp -pRa all of my "local" files, including home, opt, and usr/local in the event that I must do a major re-install. I installed kdenlive from the rpmfusion-updates repo via yumex on 22 April, the day after the update (485 packages at first, then 49 more) to SL7.8. 53 packages were 'altered' by the kdenlive install, and no issues were reported. The epel repo is required too, and I use the elrepo-lt kernels. When I started kdenlive it complained about missing packages, and the ones you mentioned sound familiar, but I ignored them and it started. I haven't actually used it for anything yet, and need to find a howto. No problems seen with Firefox, Thunderbird or the kdenviro
kdenlive progress, yum dependencies need to be added
After accepting yum downgrade libgpod kdenlive still would not load/run because of unsatisfied symbols. kdenlive: symbol lookup error: /lib64/libQt5Gui.so.5: undefined symbol: hb_font_funcs_set_font_h_extents_func Doing a bit of digging on the web, I discovered the two additional yum commands needed: yum update freetype-devel [add this dependency] yum install harfbuzz [add this dependency] At this point, kdenlive does run, but with the following: missing package Breeze icons codecs libvpx, libvpx-vp9 not found yum install breeze-icon-theme [add this dependency] solves the Breeze icon issue [root@localhost ykarant]# yum install libvpx Loaded plugins: langpacks, nvidia Repository sl is listed more than once in the configuration Package libvpx-1.3.0-5.el7_0.x86_64 already installed and latest version Nothing to do How does one find what is needed to install the two libvpx codecs? Any help would be appreciated. Stay safe. Take care. Yasha Karant
kdenlive
It appears that kdenlive will solve the question I have posed to this list: https://urldefense.proofpoint.com/v2/url?u=https-3A__userbase.kde.org_Kdenlive_Manual_CapturingAudio=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=oBhCWPZeERk6god1z_ElVvkvEzQxdzllIjq6w5M0F_8=tCwWc6_xTOqQLEIklmCnU2IkDyAT0p59XDPjnhMw5OY= On my wife's new machine, I have installed and configured Ubuntu LTS current, and save for the internal microphone that only is supported by the Dell "factory" installed Ubuntu LTS that has modified proprietary drivers that Dell will not release to the open systems community (I thought such non-release was a violation of the GPL -- as Linux uses GPL source and thus Dell would be bound by the GPL -- not required to release the binary driver -- but the source code), everything "worked". Thus sudo apt install kdenlive succeeded and the application "works". When I attempt the same thing on SL 7, I get the following that ultimately fails. Is the reason that SL 7 is too "obsolete" or that the distros simply are not being updated given that SL7 is a "dead end" being that the only EL 8 not from IBM RH is CentOS, Oracle, or eventually, Princeton. Does anyone have a SL7 fix for the observed failure below? Stay safe. Take care. Yasha Karant [root@localhost ykarant]# yum install kdenlive Loaded plugins: langpacks, nvidia Repository sl is listed more than once in the configuration Resolving Dependencies --> Running transaction check ---> Package kdenlive.x86_64 0:17.12.3-3.el7 will be installed --> Processing Dependency: mlt-freeworld(x86-64) >= 6.4.1 for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: qt5-qtquickcontrols for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libmlt.so.6(MLT_0.8.8)(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libmlt++.so.3(MLTPP_6.4.0)(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libmlt++.so.3(MLTPP_0.9.8)(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libmlt++.so.3(MLTPP_0.9.4)(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libmlt++.so.3(MLTPP_0.9.2)(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libmlt++.so.3(MLTPP_0.9.0)(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libmlt++.so.3(MLTPP_0.8.8)(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libQt5WebKitWidgets.so.5(Qt_5)(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libQt5Quick.so.5(Qt_5)(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libQt5Qml.so.5(Qt_5)(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: kf5-kinit(x86-64) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: ffmpeg for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: dvgrab for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: dvdauthor for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libmlt.so.6()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libmlt++.so.3()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libQt5WebKitWidgets.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libQt5WebKit.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libQt5Script.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libQt5Quick.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libQt5Qml.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libKF5XmlGui.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libKF5WidgetsAddons.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libKF5TextWidgets.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libKF5SonnetUi.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libKF5Solid.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libKF5Service.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libKF5NotifyConfig.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libKF5Notifications.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libKF5NewStuffCore.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86_64 --> Processing Dependency: libKF5NewStuff.so.5()(64bit) for package: kdenlive-17.12.3-3.el7.x86
how to record sound to an existing MP4 file
I am hoping that someone on this list knows of an application, preferably available for Linux, that will address the following. Our university has forced us to use a compiled executable Zoom application downloaded from the university (and available for MS Win, Mac OS X, and DEB for Ubuntu or RPM for EL). The user interface is very poor. My wife recorded her class to the University-designated cloud, and I am not downloading the MP4. Unfortunately, because of the poorly implemented user interface, there was no indication that the audio recording was not working. As a result, she has the video but no audio. Is there a method to run the video and at the same time (with minimal latency) record into the audio track of the MP4 as the video is playing? That way she will not have to "re-record" her lecture, but simply supply the missing verbal content. Any application for Linux would be appreciated; in a worse case, a MS Win one will suffice. We do not have a Mac OS X machine. Please do not reply solely to this list and my university email. My private email -- much more reliable -- is ykar...@gmail.com . Yasha Karant
Re: Experience with alternative to EL8
Thanks for the comments. Is BNL still part of the HEP collaborations? If so, would you not have access to the internal CERN-Fermilab EL8 "distro", with the internal "support"? The Zoom client in use is NOT from Ubuntu -- it is supplied by the university IT unit, and we are both at the same university. It is required that we use this Zoom through the university Blackboard system. The fact that major release upgrades can be done in place is an attractive one for Ubuntu LTS -- this is nothing like the major endeavor to move from EL-N to EL-N+1 . I still will backup user files and any special applications (not required university downloads). One "gotcha" with Ubuntu LTS on a Dell. The box was certified by Canonical but using a modified installation from Dell. In the USA, the Ubuntu LTS Dell "factory configured" unit does not appear to be for sale -- the order had to be made by authorized university staff, not by any Faculty member nor any research staff person. All that could be obtained was a MS Win configured unit. I installed Ubuntu 18.04 LTS and MATE, as well as the Nvidia proprietary Xwindows backend. With a bit of digging, everything worked *EXCEPT* for the built-in microphone system. An external USB microphone works fine. From reading "developer" lists, it appears that the microphone system is not supported by the standard distro (https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.kernel.org_show-5Fbug.cgi-3Fid-3D201251=DwIDaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=wfrLb9YUyIZw9qkCFoJPcYDJoe8tKLhNOA1KCknWpGo=D25aIqITvV1tubz__3slAPvgGYI8puiSNYi-z9lW_3A= ). Dell has installed a proprietary driver but will not release the driver. The nominal head of the Dell Linux "group" is Barton George, but there is no contact information for him (he has a subscribe-to blog, but no real information there). When I called Dell EMC technical support, because the service tag number on the unit specifies MS Win, and I requested even licensing for fee the Dell Ubuntu 18.04 distro, the Dell support person simply rang off without a word. I did not bother to try again. As for your use of an admin cover account for root -- I do the same for any machine to which an arbitrary person could have access, or that is a server on the Internet. In fact, I usually put a honey-pot trap for those who attempt to get to root. However, this is my wife's personal machine that will be on her person and is not a server -- just a portable workstation. I prefer the Mozilla installs of Firefox and Thunderbird, not any that are ported by a distro or other third party. Mozilla prevents these from being updated in place by an enduser as far as I can tell; I keep these updated not only for bug fixes, but for security patches as well. As root, the update within both Firefox and Thunderbird goes to the Mozilla server(s), not any distro, and updates. We were going to get the HP equivalent of the Dell, but the cost differential was $1k and the university would not consider it. Evidently, everything does work on the HP, and HP will (in the past when I needed it) supply proprietary drivers (that is, Linux ports of the driver from the proprietary specifications supplied to Microsoft). Stay safe -- stay isolated. Yasha Karant On 4/6/20 10:56 AM, Brett Viren wrote: Yasha Karant writes: Zoom Ignoring the recent news items and that the Zoom client for Ubuntu hasn't been updated in forever and that the whole thing is proprietary... ...Zoom works fine on Ubuntu 18.04 for me. You might consider to try out Jitsi Meet. It works rather well in the tests I've done so far. Being free software I expect it to improve further and keep getting updated. That said, my tests have been relatively small scale so I can't speak to how well it works on the scale you and your wife need. giving root a real login and GUI access (not just sudo from a terminal application), A root console (non-GUI) login can be warranted. I'd strongly suggest not running X11 sessions as root but, of course, you are free to do whatever you like. I typically will add my public SSH keys to /root/.ssh/ to gain direct remote access to root. I set "PermitRootLogin prohibit-password" in /etc/ssh/sshd_config so remote brute forcing a root password is impossible. I'll also use that or use "sudo -s" to gain local root shell. In cases where I need to walk up to a box to do some admin stuff in a GUI session I make a special user account with "administrator" rights (ie, it can "sudo"). This account is only used for this purpose and is kept free of any "user cruft". Note also that there is no equivalent to this list for Ubuntu LTS that I can find, necessitating "digging" on the web to find solutions to issues. There are various Ubuntu web f
Experience with alternative to EL8
As we know, there will be no SL8. There will be an internal CERN-Fermilab CentOS 8 (CF8 for this discussion) distro, presumably limited to use at the two facilities and to the collaborations that are allowed to get the distro under the collaboration contract(s). As I am no longer a member of the HEP community, I presume I cannot get the internal (by Fermilab/CERN) support (as we get on this list from Fermilab paid professional personnel), but (as required by the GPL and other licenses) any modifications in source form to produce whatever the CF8 version is -- if one really can build from such "source" (a very complicated and time consuming endeavor requiring test platforms for the build -- not production platforms). Thus, I am looking for alternatives. Under the current regulations from the university at which both myself and my wife are tenured full professors, all courses for the new term will be "on line" with a specification to use Zoom through the campus Blackboard system. I will not go into the real implications of this edict in terms of required security or throughput to divers platforms and environments being used by students located afield. Because her class has an enrollment of ten students (mine regrettably are *MUCH* larger), and because the university IT division claims it can support bi-direction simultaneous realtime video/audio under Zoom for all students/TAs/professors in each class (a "virtual" class equivalent to a physical class at one location), my wife needed a new computer. She diverted some of her internal research funds for that purpose; after budgetary considerations from the College budget person (the University is made up of Colleges for the academic side), and after i did some research, I settled on a Dell Inspirion 7191 two-in-one that would allow her to "write" on the screen. This machine is claimed to be fully supported by Ubuntu 18x LTS current (I can supply the document). This is the first machine that I personally have configured for Ubuntu LTS, and I willing to outline the details of my experience if there is interest -- beyond the very brief summary below. Suffice it to say that it "fully works" after some mucking about to find the real fix for the installed audio system. I installed MATE (my preferred desktop, and of my wife), VirtualBox (for MS Win), etc., and all of the personal files from the SL7 predecessor easily moved via an external USB hard drive to the Ubuntu 18 LTS system. These include her mozilla configurations (passwords, etc.) for both Firefox and Thunderbird, and the virtual machine used by VirtualBox. Given the various "gotchas" and utilities she needs, including fixing the sound card detection issue and giving root a real login and GUI access (not just sudo from a terminal application), it has taken me two full days -- but it does all work, and, for an end user (such as my wife) is not discernibly different from SL7 MATE (not including the touchpad and lack of actual three pointing device keys by the touchpad -- but that is hardware, not software). I do regret that she needed the machine *NOW*, and thus I will have to upgrade to Ubuntu 20.x LTS when that is in production and tested by the community. Note also that there is no equivalent to this list for Ubuntu LTS that I can find, necessitating "digging" on the web to find solutions to issues. Ubuntu claims that the migration from one major production release to the successor for LTS can be done in place without disruption -- I shall see if that is true. (I will copy all personal files to an external hard drive in case the migration "steps on things".) I have no idea how Ubuntu LTS server will behave -- that is our next hurdle. Note that at as a server, Xwindows and a GUI does not come as part of the "base" package and will need to be installed. Despite the fact that our servers do not use GUI applications very often, there are some graphical "front ends" that make the observation of data (including system performance and issues) much more evident than strictly character based data. As an enduser workstation, Ubuntu 18x LTS does seem to work. To everyone: stay safe, stay well. Yasha Karant
Re: Is Scientfic Linux Still Active as a Distribution?
From below:
Will look forward to move to another distribution.
End excerpt.
The question is: which distro? My first hope was Oracle EL 8 -- given
that Oracle has to compete with IBM and thus, unlike CentOS that may or
may not fit into the profit/business long term plan of IBM (long term --
less than a decade, but more than three or four years -- at least
through EL 9 first production release), provide a "working and usable"
product, just as was SL. After reading comments on this list, I am more
tempted to give up on EL and move to Ubuntu LTS. But -- I have not made
a decision. For those who require a reliable, production, stable, but
reasonably "current" Linux environment ("current" means that when I need
an application, I will not find that there are no ports of the recent
releases of the application to the Linux I am using because the major
libraries -- .so files -- are too "obsolete"), what choices are
available? In so far as possible, I want the same distro to work on
servers (and have CUDA support for compute servers with Nvidia GPU
compute boards as well as MPI) and my laptop "workstation".
If there is a more appropriate list to which to move this discussion,
advice would be appreciated. However, such a list needs to be for
"professional" use, not "enthusiast end-user" use (who are looking for a
different gaming environment, etc., than MS Win or Mac OS X).
Yasha Karant
On 2/22/20 5:46 PM, Marcelo Ferrarotti wrote:
Hello there,
I'm quite sad about SL EoL.
I'm no scientist, just an electronics guy who do a lot of research in
RF (as hobby, mostly testing antennas for ham radio in VHF bands) from
Argentina.
Fot SL the most "well done" linux distribution, for people who simply
knows.
Will look forward to move to another distribution.
Cheers from Argentina
El sáb., 22 de febrero de 2020 8:46 p. m., Keith Lofstrom
mailto:kei...@kl-ic.com>> escribió:
I'm an independent electronics inventor, heavily dependent
on both competent software and competent laboratory science,
both for the knowledge I depend on and the tools I use to
transform that knowledge into products and services for
my customers.
SL has been a very good tool for that. Thanks to all who
have contributed.
I depend on "benign neglect" for a stable computing
platform - just enough funding and staffing to fix urgent
problems, but not continuously mutate the platform to
conform to ephemeral fashion or management whim.
I moved /from/ Windows to gain that stability, even if
that limits the choice of new widgets I can attach to my
(older) computers. I have plenty of replacement-spare
old widgets, and I don't need the distraction of a
rapidly mutating platform optimized for market churn
and planned-obsolescence sales.
I'm actually glad that Microsoft, Apple, and IBM are
busily churning those markets, because it keeps their
customers distracted and not bothering me with those
distractions while I think and work. The hardware cast
off by the fashion-chasers is still abundant on eBay,
and I have enough of it to last me for life (except
for the batteries and backlights for my old Thinkpads).
I presume there are enough like me, some of whom are on
this list, that we can continue to carve out a community
space on top of CentOS, focused on inquiry and reliability.
If CentOS 9 or 10 or 11 goes off the rails, there are
enough of us here to tweak CentOS 7 or 8 into something
we can continue to use, just like Linux was "in the good
old days".
While "security by obscurity" is not optimum, I presume a
smaller community of impoverished science geeks is a less
tempting target for professional software criminals than
million-dollar IT departments for billion-dollar
corporations and governments, or billions of hapless
consumers. We are part of the global target, but we are
unlikely to attract specific attention from the bad guys.
And while we still benefit from the use of servers at
Fermilabs for our "static" distro and our active mailing
list, perhaps we should have a backup plan for migration
in case some bureaucrat decides to pull the plug on us.
That has /always/ been a risk for what we do here; we are
one presidential tweet away from Saint Louis USDA exile.
As a community of scientific, like-minded Linux users,
let's begin to prepare a rudimentary plan B, and hope
that we never need to implement it.
Keith
--
Keith Lofstrom kei...@keithl.com <mailto:kei...@keithl.com>
Re: Is Scientfic Linux Still Active as a Distribution?
Two comments. I am not pursuing the IBM FUD (Fear, Uncertainty, Doubt) marketing and business strategy that made IBM the dominant business, accounting, and the like, computer systems service, software, and hardware supplier in the USA for many years. The research and scientific market was dominated by DEC (since absorbed by other for profit corporations), Control Data, Cray, and Sun (also absorbed, currently Oracle as I recall). Of these, only Sun was strongly unix (BSD that was SunOS then Solaris and then left BSD for the descendant of ATT System V Release 4 -- the old "original" ATT of unix, C, C++, etc., not the current ATT that bought the name, etc., but not Murray Hill Bell Labs, etc.). Linux is a relatively new "unix", but the history is irrelevant to this reality -- most of the major servers run Linux or on a open systems "bare iron" hypervisor for "cloud services" that shares much history with other open systems. Indeed, this list did suffice for support -- the personnel from SL at Fermilab would reply with some detail, but not for those who need detailed key-stroke "hold the hand and fingers" support. I understand the current for-profit business arguments that IBM will continue to make CentOS viable and stable. I also do not trust these for the long term unless there are some strong fiscal reasons to do so for the long term (e.g., a change in taxation policy and enforcement). Second, the issue of support. "My" university has changed dramatically under the current campus President. Even under the previous campus administrations, the only supported entities were those for administrative computing controlled by the administration and that has, and had, no academic freedom. Worthless for any research that interested me. Most of these functions have been outsourced at this time. The administrators in these areas have no background in science or engineering, but rather "management". I am not deprecating anyone, merely putting things into perspective. There is no internal support at my campus for academic freedom curiosity-directed disciplinary research, with some support for some persons to secure external funding. My funding to do any of this was external, not internal. Yasha Karant On 2/21/20 5:49 PM, Mark Rousell wrote: Andrew Z wrote on 2/21/20 1:57 PM: > It is odd that you have no budget to support critical systems for your > department, Yasha. > > What if you power servers down and see how "critical " they indeed are? And if > they are not - then get fedora and be done with it. I don't think Yasha said that he has no budget, did he, only that he in effect has a limited budget. Why is it limited? Could it be because it was possible to do what was needed within that limited budget?
Re: Is Scientfic Linux Still Active as a Distribution?
As we could not afford the license-for-fee model that RedHat started a number of years ago (prior to which, one could download and install production RedHat -- not the "Fedora" equivalent -- licensed for free but without RedHat support -- but updates, etc., were available without fee), we too went with CentOS. Before RH, I used Debian, but there were issues of stability. RH was stable. The problem with CentOS was that it was more or less a volunteer deployment, and we did not have the personnel to join the effort as our internal and external funding could not be used for that purpose. Once SL became a more-or-less "stock" version of RHEL, and given that SL had professional funded employed personnel (as required by HEP and funded by the various governments that support Fermilab or CERN), this was the logical choice. SL came with no support, but as several of us (myself included) were at one epoch "kernels internals" persons, and were "systems persons", and not as "IT" but as scientists and engineers, with the SL users list for "help", we had no significant issues -- see the recent exchange concerning a bug in EPEL that prevented an "easy" upgrade of the MATE desktop GUI environment. However, RedHat is now owned by IBM, and CentOS is the RedHat "licensed for free" distro front end. The only reason IBM exists is not to support the goals of the Freesoftware Foundation (GPL), but to support profit -- it is a major for-profit (effectively, trans-national) corporation. Thus, one cannot rely upon entities within such a corporation to do anything that will undermine or reduce the profits of the corporation (including the overall compensation package of the CEO and the like), except in those nation states that have enforced regulations controlling the product deployments. The USA has very little compared to much of the EU. As Fermilab/CERN do not exist for the same purpose as IBM (individual scientists who may be the group leaders, etc., at such entities notwithstanding), SL was a viable alternative. There is absolutely no reason to assume that IBM will be such an alternative unless one wants to pay. I am not going to argue with those who claim we are "freeloaders" despite paying the taxes that in part support Fermilab and CERN, but not CentOS -- if we cannot pay, we should not use -- but the realities of much university-based academic research is that there is no money and we do what we can. In the simplest terms. I trust IBM to maximize overall return-on-investment (e.g., profit), and a "free" CentOS that truly competes with licensed-for-fee products does not fit that for-profit model. Yasha Karant On 2/21/20 7:41 AM, Michel Jouvin wrote: Hi, I'm surprised by the so negative feeling against CentOS which is a great project too and has been working well since it was "acquired" by Red Hat. I see no official sign that it should change. Moving from SL to CentOS is straightforward, I don't think you can speak about it as a migration as it is exactly the same product. And staying with CentOS will give you a chance to meet the DUNE people at some point and more generally the HEP community if you liked interacting with it! Cheers, Michel Le 21/02/2020 à 16:32, Peter Willis a écrit : Hello, Thanks to everyone for clarifying the future status of SL. I guess it’s time to start researching he docs for Ubuntu/Debian or something. Looks like we need to revise our computing cluster plan. The computer here is pretty small with only two nodes and a controller totalling 112 CPUs. We use it for numerical modelling of ocean and river currents and sediment transport (OpenMP/MPICH/FORTRAN). The changeover will be pretty small. We are still waiting for the OK for a new node or two. The current nodes are ten years old. The update to a controller and SL7 was a last ditch effort to join the two nodes and increase the scale of the models without costing too much more. In other news, the link you shared has an article about ‘DUNE’ which seems like an interesting project. I’d certainly frostbite a few toes to just stand around and watch that thing run experiments. Thanks for the info, Peter >Hello Peter, > >> Is Scientific Linux still active? >Scientific Linux 6 and 7 will be supported until they are EOL, but there will be no SL8. > >Here is the official announcement from last April: > >https://listserv.fnal.gov/scripts/wa.exe?A2=ind1904=SCIENTIFIC-LINUX-USERS=817 <https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.fnal.gov_scripts_wa.exe-3FA2-3Dind1904-26L-3DSCIENTIFIC-2DLINUX-2DUSERS-26P-3D817=DwMF-g=B_W-eXUX249zycySS1AyzjABMeYirU1wvo9-GmMObjY=Z7xHp2tIJsvAE2FtPxl_lynvf4hA_FJ8mKsaIgvY6Dk=1zP0LygxDwV3-fUs-jcM2DUCZNrhuLf05Y7PBpNbezA=Mp_eieQpDG0QyCOHMRj4c9vZVvy8-Wu-IgGpxnevSCI=> > >Bonnie King
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
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
MATE desktop upgrade fail SL7
There are several annoyances in the MATE desktop GUI system that I am hoping an update will address. However, the update fails with: --> Finished Dependency Resolution Error: Package: libgpod-0.8.3-7.el7.x86_64 (@epel) Requires: libplist.so.1()(64bit) Removing: libplist-1.10-4.el7.x86_64 (@anaconda/7.2) libplist.so.1()(64bit) Updated By: libplist-1.12-3.el7.x86_64 (sl) ~libplist.so.3()(64bit) Error: Package: libgpod-0.8.3-7.el7.x86_64 (@epel) Requires: libusbmuxd.so.2()(64bit) Removing: usbmuxd-1.0.8-11.el7.x86_64 (@anaconda/7.2) libusbmuxd.so.2()(64bit) Obsoleted By: usbmuxd-1.1.0-1.el7.x86_64 (sl) Not found Updated By: usbmuxd-1.1.0-1.el7.x86_64 (sl) Not found Error: Package: libgpod-0.8.3-7.el7.x86_64 (@epel) Requires: libimobiledevice.so.4()(64bit) Removing: libimobiledevice-1.1.5-6.el7.x86_64 (@anaconda/7.2) libimobiledevice.so.4()(64bit) Updated By: libimobiledevice-1.2.0-1.el7.x86_64 (sl) ~libimobiledevice.so.6()(64bit) Has anyone experienced this update failure and s there a workaround? Or, just move on to EL 8 (I am leaning towards Princeton Springdale 8 if it becomes available or possibly current Oracle EL 8, or simple leaving EL and going to Ubuntu LTS)? I do not like either the current Gnome or KDE desktop environments. Yasha Karant
EL 8
At this point in terms of application support for EL 7 (including SL 7)
from external entities (such as Calibre -- there are others), I am going
soon to be forced to go to another Linux. The options appear to be drop
EL entirely and go to Ubuntu LTS ("stable") current, or to stay with EL
and use Springdale (Princeton) EL8 when (if?) it is available, or Oracle
8 EL. Thus far, everyone I have contacted who did a clean install of
Oracle 8 (and then copied back files, directory trees, etc., from the
non-systems areas of an EL 7 working system) have had no issues.
However, I am very concerned about support for Oracle 8 other than
purchasing support from Oracle. Do the various professional
repositories for SL 7 (and EL 7 in general) such as EPEL have an EL 8
version that work seamlessly with Oracle 8 (or Springdale for that matter)?
In the best of all possible worlds, I or my students would have time to
build applications from source -- but there are too many and not enough
time, forcing the use of repositories with pre-built RPMs (or DEBs if we
switch to Ubuntu). Note that we run the same base OS on servers
(including HPC compute servers with Nvidia CUDA GPUs) as well as desktop
and laptop machines, all presently X86-64 based (this may change for at
least some of the servers).
Any advice would be appreciated.
Yasha Karant
Calibre current
I attempted to upgrade Calibre to the current production release. It fails to run (I can post my question) but the response given is: SL7 is based on RHEL7 and uses GCC 4.9 (see https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_solutions_19458=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=VIryM0aQaNiX0n1xowynI6HPID-GSk5v8GbrCq2fldM=eWpq7f1FsG6R3tgnKBPi__pLLLgTrtRmzb2uWLpjkWg= ). Solution?: wait for RHEL8, install a proper desktop linux distro or follow https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.redhat.com_blog_2...gcc-2D8-2Dclang-2D6_=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=VIryM0aQaNiX0n1xowynI6HPID-GSk5v8GbrCq2fldM=H94UEqdoz0IpzxgBa16hgbaiKAzxsoIQhIrbgUt9XbM= End quote. I always thought that SL was a proper desktop (user interface GUI) Linux, and not just Debian/Ubuntu derivatives or SUSE. Calibre needs RuntimeError: Failed to load icu with error: /lib64/libstdc++.so.6: version `CXXABI_1.3.8' not found (required by /opt/calibre/lib/libicui18n.so.64) Is the required lib available for SL7 without disrupting the OS per se? If not, does anyone know the last Calibre that does work with SL7? Any help would be appreciated. Yasha Karant ykar...@gmail.com
Re: centOS 8
My experience with "early" production releases of SL (post-production-deployment at CERN/Fermilab) is that it "worked". I have downloaded the CentOS 8 ISO and have prepared a USB stick for installation. Having read the comments below, I shall not be deploying CO 8 anytime soon. As SL is "going away", and CERN/Fermilab on this list seemed to indicate future RHEL major releases would be CentOS deployments, is that in fact what is happening? Or will there be RHEL licenses for CERN/Fermilab general deployment? What about Oracle EL? Is this experiencing the issues as discussed below? From https://urldefense.proofpoint.com/v2/url?u=https-3A__blogs.oracle.com_cloud-2Dinfrastructure_in-2Dan-2Dindustry-2Dfirst-2C-2Doracle-2Dbrings-2Dautonomous-2Doperation-2Dto-2Dlinux=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=CBNiL-EofXAtF9N4nmiUm9uIfzH42PsCLWD6t1J5EGo=PHN-v29pHKvFxRbHRrwc_ga8o99OH97Vszc9arCL0AE= Oracle Autonomous Linux, which is based on Oracle Linux, is 100% application binary compatible with Red Hat Enterprise Linux. Will the SL list continue to exist as a mechanism for raising issues (and getting suggested solutions) for CentOS post-SL releases? I have found no equivalent list for either CentOS or the other possibility, Ubuntu LTS (not RPM based, not RHEL based, but GNU Debian based). For now, we are staying with SL 7, but this is not a viable longterm solution, particularly as new hardware configurations emerge (or needed applications such as VirtualBox or VMWare will require "later" libraries than what are available for SL 7). Yasha Karant On 10/5/19 10:25 AM, Larry Linder wrote: > After tossing in the towel last Thursday we decided to try the nvidea > install and it worked. It is nice to have my dual high resulation > displays back. > > Centos 8 problems. > > 1. We noticed that the mouse wheel has changed direction - why after 40 > years. This should be removed. > > 2. We changed the mouse direction back to to what it had been for 40 > years and now you can't copy some command lines from a tutorial we are > looking at with the browser. > > 3. "bash" refuses to execute any command line code or linux executable > file. > > 4. There does not appear to be a C Shell. We have 100's of usefull > scripts that don't work. The man pages are there but no /bin/csh. > > 5. We were able to install NVidea drivers but it still didn't work. > You have a couple of commands to run to set default to nvidea driver. > This is the only thing that has worked. > > 6. When you drag a terminal to the desktop and click to select it. It > rearranges all the other desktop terminal windows. > > 7. Focus follows the mouse was one of the most useful things when > putting data into other documents or spreadsheets. Without it it makes > doing my bank ledger almost impossible. > > 8. Simple things are now complicated and require 3 to 4 time more > mousing around to accomplish a simple task. > > 9. After fixing the mouse direction we cannot even run "yum" Checked > permissions and paths but bash can't find it. > > 10 The neat little GUI that allowed you to set up users, groups, > specify UID, home directory and shell for users is gone too. It all > back to the command line. > > 11The function to add a member to "group" doesn't work. It does not > change the "group" file or maybe the group file has gone away too. > > 12"fstab is now jiberish and the man pages have not changes. I need > to add a couple of directories the install disk partitions the insall > did not install. > > 13after a lot of fooling around we were able to install one printer > out of the 6. It could not find the printserver so our large format HP > Plotter could not be installed. > > 14Libera office can now get to documents on the server, you can edit > and change file name and save them. A great improvement. > > 15Setting up network and fixed IP's was a major major cammand line > exercise. The old utility that made it easy is now gone. > > 16None of my CAD / CAM packages work! So there is nothing to plot. > > 17Last step is to reinstall SL 7.6 with KDE on text box and call it > done. > > Thank You again SL troops for the great work. > > I hate to say this: > The most productive system in the shop is SL 5.11 running KDE 3.4. It > has 12 desktops, with VM-Ware it runs all our old Windows apps we need > to support paying customers. Focus Follows mouse and you can edit and > paste documents just by moving the mouse. It can capture sections for a > windows cad package and you can paste the prawing into an Appache > OpenOffice documtent and
Firmware Bug update microcode to version: 0x22 (or later [2] Fixed
I installed the CentOS rpm: microcode_ctl-2.1-47.el7.x86_64.rpm<https://urldefense.proofpoint.com/v2/url?u=http-3A__mirror.centos.org_centos_7_os_x86-5F64_Packages_microcode-5Fctl-2D2.1-2D47.el7.x86-5F64.rpm=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=_0VrlHuBnOSU5g5r1FaT_NKl7hAgmgJsdmA68Xz2jN4=pcdlnk34WinaF7CPVkH3Jcd3bYfeC24sVCSLqpCexkI=> and this seems to have resolved the issue. I did a full shutdown and then restarted the machine without the diagnostic appearing. /var/log/dmesg has: [0.00] microcode: microcode updated early to revision 0x25, date = 2018-04-02 ] Previous post: I have a [FirmwareBug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later). This diagnostic is displayed during boot and is recorded in /var/log/dmesg . How does one obtain the necessary microcode? For Ubuntu and presumably other .deb based distributions: Just install intel-microcode with sudo apt-get install intel-microcode and reboot. End quote. What is the equivalent EL command and from which repository does the command get the "intel-microcode"? The CPU is an Intel I7 in a HP Zbook laptop from several years ago. Thanks for any information. Yasha Karant
Firmware Bug update microcode to version: 0x22 (or later
I have a [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later). This diagnostic is displayed during boot and is recorded in /var/log/dmesg . How does one obtain the necessary microcode? For Ubuntu and presumably other .deb based distributions: Just install intel-microcode with sudo apt-get install intel-microcode and reboot. End quote. What is the equivalent EL command and from which repository does the command get the "intel-microcode"?The CPU is an Intel I7 in a HP Zbook laptop from several years ago. Thanks for any information. Yasha Karant
Re: pointing stick (trackpoint) activation
I found one of the GUI applications -- gpointing-device-settings -- in a Fedora 17 x86-64 RPM that I downloaded and installed as the output is displayed below. This application did find the touchpad pointing device (screenshot of GUI available upon request) but did not find the pointing stick. Is there a driver for the pointing stick or other configuration for this device to be detected? Note that I ran this as root from a terminal application and that it produced D-bus diagnostics. I did not use the application to configure the touchpad as that is working to my satisfaction. Aside: evidently the linuxdownload.adobe.com repository has changed as can be seen below -- however, that does not involve this application rpm per se. [root@localhost Downloads]# yum install ./gpointing-device-settings-1.5.1-7.fc17.x86_64.rpm Loaded plugins: langpacks, nvidia Repository sl is listed more than once in the configuration Examining ./gpointing-device-settings-1.5.1-7.fc17.x86_64.rpm: gpointing-device-settings-1.5.1-7.fc17.x86_64 Marking ./gpointing-device-settings-1.5.1-7.fc17.x86_64.rpm to be installed Resolving Dependencies --> Running transaction check ---> Package gpointing-device-settings.x86_64 0:1.5.1-7.fc17 will be installed --> Finished Dependency Resolution https://urldefense.proofpoint.com/v2/url?u=http-3A__linuxdownload.adobe.com_linux_x86-5F64_repodata_repomd.xml=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=BHI3xZkD0xlrKYrhZLRfBoqXEAmP5l_M6FxgMsiI9l0=zev6rTQdJYVbMYpeiI2iHQGr2ZGHEajr5MZN6RWTVBc=: [Errno 14] HTTP Error 404 - Not Found Trying other mirror. This generally happens when your clien is unable to communicate with the repo server. Please verify your connection works as expected. Dependencies Resolved Package Arch Version Repository Size Installing: gpointing-device-settings x86_64 1.5.1-7.fc17 /gpointing-device-settings-1.5.1-7.fc17.x86_64 379 k Transaction Summary Install 1 Package Total size: 379 k Installed size: 379 k Is this ok [y/d/N]: y Downloading packages: Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : gpointing-device-settings-1.5.1-7.fc17.x86_64 1/1 Verifying : gpointing-device-settings-1.5.1-7.fc17.x86_64 1/1 Installed: gpointing-device-settings.x86_64 0:1.5.1-7.fc17 Complete! [root@localhost Downloads]# gpointing-device-setting bash: gpointing-device-setting: command not found... [root@localhost Downloads]# gpointing-device-settings GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. An X error occurred. The error was BadAtom (invalid Atom parameter). An X error occurred. The error was BadAtom (invalid Atom parameter). GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. GConf Error: Client failed to connect to the D-BUS daemon: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. GConf Error: Client failed to connect to the D-BUS daemon: Did not
pointing stick (trackpoint) activation
My SL 7 system does not recognize the trackpoint ("track stick button")
in the center of the QWERTY part of the keyboard on a HP Zbook. I can
find nothing in the HP bios settings (available during boot) to activate
this, and the utilities I have found to do so are either obsolete or
only for Debian derivatives, not EL derivatives. I am guessing that
there may be stanzas in the X11 configuration file(s) to do this, but
have not found these. Does anyone have a working trackpoint under SL7
and if so, how was this accomplished. Please reply to ykar...@gmail.com
with any personal (not SL list) email responses.
Any help would be appreciated.
Yasha Karant
latest VLC GU failure
I have installed the latest VLC from yum install https://urldefense.proofpoint.com/v2/url?u=https-3A__dl.fedoraproject.org_pub_epel_epel-2Drelease-2Dlatest-2D7.noarch.rpm=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=tt0QJWICwAdQhNuEHhQol8E0jpjb9LF0HoXj0RhJ-Cg=UokyKEAaXzuacgglhxv0zFAk9YmFqZUaMYPZ_TL5qr4= yum install https://urldefense.proofpoint.com/v2/url?u=https-3A__download1.rpmfusion.org_free_el_rpmfusion-2Dfree-2Drelease-2D7.noarch.rpm=DwIGaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=tt0QJWICwAdQhNuEHhQol8E0jpjb9LF0HoXj0RhJ-Cg=H87Q6eqsd_9iAq5g01Nc9hSzqRgd_4U2aHaCgWnEeZQ= yum install vlc The vlc failed with the messages that appear below. Based on these messages and a search on the web, I also did yum install qt4 yum install qt5 yum install libxkbcommon All of the above yum install commands completed without failures. Nonetheless, the yum icon on the desktop does not start yum, and from a terminal using bash, one gets: $ /usr/bin/vlc VLC media player 3.0.6 Vetinari (revision 3.0.6-0-g5803e85f73) [0163b1c0] main libvlc: Running vlc with the default interface. Use 'cvlc' to use vlc without interface. [016f5500] skins2 interface error: cannot instantiate dialogs provider [016c8e30] main playlist: playlist is empty [016f5500] [cli] lua interface: L I am using MATE , but will attempt this under KDE or GNOME if there is a reason to do that for VLC. Any suggestions on what to do (e.g., are there one or more configuration files for running, not building, vlc or whatever that need to be changed? Yasha Karant I would appreciate replies to ykar...@gmail.com
Enterprise Linux 8 beta
The following announcement appears on the wholly owned IBM subsidiary web site: Red Hat Enterprise Linux 8 beta Red Hat Enterprise Linux 8 provides a consistent foundation for enterprise hybrid cloud, delivering any application on any footprint at any time. The public beta is now open. End quote. How soon may we expect a SL8 beta? How long after RHEL8 is licensed for fee in production will a licensed for free SL8 appear? Aside: there was a stated concern on this list that IBM may elect not to distribute without any licensing fee the full buildable source(s) of EL, including patches/updates af some time in the future. Is such a move allowed under the Linux, GPL, etc., licenses? Thanks, Yasha Karant
key scancode and result
I have repurposed a X86-64 laptop running MS Win 10 to SL 7. I installed a new "empty" harddrive and went from there; however, any firmware modifications, etc., made by MS Win and not automatically redone by SL would remain with the MS settings. The 5 key on the keyboard (not the keypad in numlock mode) actually transmits something else, displayed as ~5 and clearly is not a plain 5. What utility allows one to get this (I have tried showkey to verify the key with response: [root@localhost pass]# showkey kb mode was ?UNKNOWN? [ if you are trying this under X, it might not work since the X server is also reading /dev/console ] press any key (program terminates 10s after last keypress)... keycode 28 release ^[[15~5keycode 63 press keycode 6 press keycode 63 release keycode 6 release I have tried xev with output: KeyPress event, serial 38, synthetic NO, window 0x3e1, root 0x2ec, subw 0x3e2, time 65129543, (45,48), root:(74,168), state 0x10, keycode 71 (keysym 0xffc2, F5), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 38, synthetic NO, window 0x3e1, root 0x2ec, subw 0x3e2, time 65129546, (45,48), root:(74,168), state 0x10, keycode 14 (keysym 0x35, 5), same_screen YES, XLookupString gives 1 bytes: (35) "5" XmbLookupString gives 1 bytes: (35) "5" XFilterEvent returns: False KeyRelease event, serial 38, synthetic NO, window 0x3e1, root 0x2ec, subw 0x3e2, time 65129656, (45,48), root:(74,168), state 0x10, keycode 71 (keysym 0xffc2, F5), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 38, synthetic NO, window 0x3e1, root 0x2ec, subw 0x3e2, time 65129660, (45,48), root:(74,168), state 0x10, keycode 14 (keysym 0x35, 5), same_screen YES, XLookupString gives 1 bytes: (35) "5" XFilterEvent returns: False What other utilities and/or human-readable data can be used to diagnose and possibly repair this issue? Any help would be appreciated. Yasha Karant
Re: boot hang
On 10/28/2018 11:07 AM, Orion Poplawski wrote: > On 10/28/18 2:24 AM, Yasha Karant wrote: >> On 10/27/2018 07:08 PM, Orion Poplawski wrote: >>> On 10/27/18 10:42 AM, Yasha Karant wrote: >>>> Using yumex, rather than doing a full update to SL 7.5 production, I >>>> attempted to update over the network the kernel, firmware, and libgcc, >>>> allowing yumex (essentially yum) to establish the needed dependencies >>>> (other applications, etc., that also needed to be updated). The >>>> resulting kernel will not boot, but merely hangs. If one waits long >>>> enough, the "progress bar" at the bottom of the screen does show the >>>> typical blue/white progression, but that is all. When I reboot and >>>> manually select the previous kernel, the system reboots. I am using >>>> MATE for a "control" GUI, although as the system never gets to the >>>> login >>>> screen, MATE should not be "active". It appears that yumex (yum) >>>> does >>>> not fully resolve all required dependencies. What other components >>>> must >>>> I update? >>> >>> Pressing should get you the text boot messages which hopefully >>> should point you towards what is going wrong - or remove rhgb from the >>> kernel command line. >>> >>> >> Following your suggestion, I pressed . Ultimately, the boot hung >> at "Waiting for Plymouth boot screen to quit ..." >> >> Was something misconfigured/misinstalled by the yumex update of the >> kernel? >> >> I did note from the text messages that "Starting Gnome Display Manager" >> appeared at multiple steps. >> > > Looks like the X server is failing to start for some reason. You > should be able to ssh into the machine or do ctrl-alt-f2 to get a text > login window. Take a look at /var/log/Xorg.0.log, etc. If you are > using nVidia drivers that's a likely suspect for what went wrong. > You were correct: downloading via yum the latest elrepo nvidia package solved that problem, only to reveal that there was no network connection because iwl firmware needed to be updated. Although the previous SL 7 kernel would not go into Xwindows once the nvidia drivers were updated, it did support a plain scrolling terminal on F2, etc., and yum update iwl* as root addressed that issue. Now the system reboots under the current SL7 production kernel, the 802.11 network works (including the security authentication that Network Manager, etc., has stored), and Xwindows and MATE "work". Thank you. P.S. The comment that one must disable certain GUI booting displays is correct to get the full on-line text output, but the solution is not obvious until one RTFM, etc., as there is no "prompt" for such a choice.
Re: boot hang
On 10/27/2018 07:08 PM, Orion Poplawski wrote: > On 10/27/18 10:42 AM, Yasha Karant wrote: >> Using yumex, rather than doing a full update to SL 7.5 production, I >> attempted to update over the network the kernel, firmware, and libgcc, >> allowing yumex (essentially yum) to establish the needed dependencies >> (other applications, etc., that also needed to be updated). The >> resulting kernel will not boot, but merely hangs. If one waits long >> enough, the "progress bar" at the bottom of the screen does show the >> typical blue/white progression, but that is all. When I reboot and >> manually select the previous kernel, the system reboots. I am using >> MATE for a "control" GUI, although as the system never gets to the login >> screen, MATE should not be "active". It appears that yumex (yum) does >> not fully resolve all required dependencies. What other components must >> I update? > > Pressing should get you the text boot messages which hopefully > should point you towards what is going wrong - or remove rhgb from the > kernel command line. > > Following your suggestion, I pressed . Ultimately, the boot hung at "Waiting for Plymouth boot screen to quit ..." Was something misconfigured/misinstalled by the yumex update of the kernel? I did note from the text messages that "Starting Gnome Display Manager" appeared at multiple steps.
boot hang
Using yumex, rather than doing a full update to SL 7.5 production, I attempted to update over the network the kernel, firmware, and libgcc, allowing yumex (essentially yum) to establish the needed dependencies (other applications, etc., that also needed to be updated). The resulting kernel will not boot, but merely hangs. If one waits long enough, the "progress bar" at the bottom of the screen does show the typical blue/white progression, but that is all. When I reboot and manually select the previous kernel, the system reboots. I am using MATE for a "control" GUI, although as the system never gets to the login screen, MATE should not be "active". It appears that yumex (yum) does not fully resolve all required dependencies. What other components must I update? At one time, SL (EL) allowed one to do an update from local media during the boot from local installation media (e.g., a USB stick flash drive) -- this no longer directly is supported. As I do not have the time to extract from the previous source how this was accomplished, and have not found a script (or GUI version thereof) that accomplishes the same task, I attempted a minimal update using yumex. Yasha Karant
Re: Update via SL 7.5 install USB flash drive
As I explained, I cannot transmit or receive URLs within SMTP email and perhaps other modalities due to the security measures of the campus with which I am associated, as you can see below in URL modification. Until I can get my SL users email address permanently reset, please email any URL information to ykar...@gmail.com . I apologize for this, but I have no control or input to any system under the current campus administration, as faculty (including tenured full professors) who are not campus administrators (deans or higher administrators in most cases) are informed of actions, but otherwise have little meaningful influence over decisions. I will attempt to implement what is suggested below without access to the Kadel-Garcia tool set, but I suspect that the tool set will save me some time and effort. Thanks for your patience. Yasha Karant On 10/17/2018 08:03 PM, Nico Kadel-Garcia wrote: > On Wed, Oct 17, 2018 at 12:07 PM Yasha Karant wrote: >> How does one update SL 7 using a mounted USB flash drive as the source >> of a repo, rather than using any external network? There were >> instructions for doing this for EL pre-7 distributions, but I cannot >> find similar instructions for SL 7. I have a USB flash drive with the >> current double-layer DVD SL7.5 install image (ISO) and that does work -- >> I just did a fresh install of SL7.5 using this media. > One sets up a new or one of the existing /etc/yum.repos.d/*.repo files > to look at the locally mounted CD drive. I would copy "sl7.repo" to > "sl7-local.repo", and reset the repository names to "sl7-local" and > the like, and set their URLs to point to > "file:///mountpoint/7.version/x86_64/os" and similar URLs. > > I've done just this sort of thing, successfully for internal SL, > CentOS, and RHEL mirrors. You may find my tools at > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_nkadel_nkadel-2Drsync-2Dscripts=DwIBaQ=B_W-eXUX249zycySS1AyzjABMeYirU1wvo9-GmMObjY=Z7xHp2tIJsvAE2FtPxl_lynvf4hA_FJ8mKsaIgvY6Dk=RT1c81ULE-0AAXhmXl3Y0eaJZ0yPhGaZLHC9N3oM0hs=r3JZw6l5f9xZhSR9sTX2gWvskXqOW9_hfegrgK-QAvU= > helpful for generateing > your local mirror, especially the one for Scientific Linux.
gaming laptop compatibility
Please see the list below. These come from a popular press article, but I cannot post the URL as the university that provides this email rewrites all URLs, and thus I have no certainty that any URL I post (or is embedded in any thread to which I respond) will not be corrupted. At the end of the popular press account, there are mentions of specific laptop models. As I do not have the time to research this, but a number of students want to know, which if any of these are SL 7 compatible (meaning, all hardware is "supported")? I assume that a larger number are Ubuntu supported, in that Ubuntu keeps closer to the "bleeding edge" of Linux hardware support. Thanks for any specific information. Yasha Karant Excerpt: How to buy a gaming laptop They're cheaper, lighter and more powerful than ever before. Devindra Hardawar If your priority is smooth gameplay, I'd recommend a laptop with a 15.6-inch 1080p screen and either NVIDIA's GTX 1060 or 1070 Max-Q GPU. The former will run most games well at 60fps and beyond, while the 1070 will let you reach even higher frame rates and better-quality graphics settings. Mid-range machines like HP's Omen and some of Dell's Alienware models are a good start. If you've got a slightly bigger budget, you should consider laptops with high-refresh-rate screens: MSI's GS65 Stealth Thin, Gigabyte's Aero 15X, Razer's Blade and pricier Alienware configuration. But if you're on a budget, stick to machines with the GTX 1050, 1050Ti or 1060 Max-Q, like Dell's G3 and G5 series. You won't get high-refresh-rate monitors with these, but they'll have enough horsepower to reach a silky 60fps. They're ideal if you're mainly playing MOBA titles and undemanding games like Overwatch. It's easy to get overwhelmed by the number of options today, but that variety is ultimately a good thing. What was once a category filled with huge, ugly monstrosities now includes genuinely gorgeous machines that aren't much heavier than a MacBook Pro.
Re: parted and mount
Thank you for your clarifications. As I recalled, gparted is a GUI that does both parted and mkfs -- my memory was correct that by using gparted as I did, there not only was some header claiming a XFS format, but the drive was in fact so formatted. Although I fully agree that the CLI commands (parted and xfs) are more versatile with more options than gparted, I have found both in teaching students and training technicians that for most purposes, gparted is sufficient and is less prone to human error (including typing errors). I suggest that you might comment upon the actual output from parted and mount that I included in a related thread on this list: ( Re: parted and mount ** EXTERNAL ** ) and thus I am not reproducing that information here. What the outputs seemed to show was that parted found that /dev/sdg was XFS and thus I assume "mountable" by root, but that mount refused to accept the same device. As you point out, /dev/xyz can be mounted, not just /dev/xyzN . As for the concerns that these might be part of a LVM or some other file/disk/storage logical structure beyond the original (and very limited) partition scheme adopted for MS-DOS on very limited (pre-demand-page-virtual-memory) X86 machines (and much more limited than current X86-64 machines), I will do as you suggest; but as I formatted the external USB 2 Tbyte drive with gparted, I suspect that the drive has the "simple" partition format (from an epoch with much more limited disk controllers and disk types than currently available on "small systems" -- e.g., IDE or even SCSI contrasted with SATA, but not "mainframe" technology of that epoch). The partition scheme of MS DOS type machines is relatively simple and limited, but likewise, more easily recovered and manipulated; in my opinion (no flame wars, please), the current disk/file system structures often are more fragile for "simple" applications such as a standalone but Internet capable workstation. This is not to state that I prefer MS FAT or EXT2 file system formats -- given the current stability and capabilities of XFS, that is the file system (not partition, etc., scheme) that I prefer. Aside (not SL): Does anyone know: is XFS available for MS Win, Mac OS X, or Android? If so, is it licensed for free, or is it only through a proprietary application for fee? Yasha Karant On 09/27/2018 05:01 AM, Nico Kadel-Garcia wrote: > On Wed, Sep 26, 2018 at 2:38 AM Yasha Karant wrote: >> I have attempted to mount USB external formatted media on a SL7 system. >> One was a flash drive with a MS format (reported by parted as FAT32); >> the other was a 2 Tbyte hard drive XFS formatted on a different SL7 >> system. > /dev/sdg1 would be the first "partition" on the device. "parted -l > /dev/sdg" will report partitions. > > There need not to be partitions. It is also possible to write a > filesystem directly on the whole device, which may be the case for > whatever formatted it, in which case it would be on /dev/sdg. > > Partition tables are an old, extremely lightweight system written into > a very few blocks at the beginning of the disk for *ancient* disk > controllers. As such, it is *extremely* limited. In fact, by the > standard, a disk can only have 4 partitions: set up some space as > extended partitions, and then a kernel can get fancy and do LVM, > software RAID, etc. There is a byte or two set aside for labeling the > "type" of the partition, but there ae many more types of filesystems > now, so tools like parted cannot really keep up: it's why there is not > an "ext4" option for making partions in parted, and why we typically > use "ext2" for that. > > gparted, while a fine and useful tool, is a graphical wrapper for > "parted", and "mkfs" of various flavors. Like many open source GUI's, > it hides options available from the command line. But I'm surprised if > you can't run "parted -l" to get a listing of all the partitions on > all your attached devices that are detected, including "/dev/sdg" if > that is indeed your attached device with data on it. > > You know I'm wondering if you inadvertently set up volume group > and logical volumes on your drive, activating them with gparted > without even realizing it. What does "pvscan" and "vgscan" say? I > remember that gparted supports those, and if you'd not even installed > the LVM tools on your second system, you wouldn't have those scanning > tools available.
Re: parted and mount ** EXTERNAL **
Thank you for you comments. Below is the output from mount /dev/sdc1 on /run/media/ykarant/USB20FD type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0077,codepage=437,iocharset=ascii,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2) /dev/sdb on /run/media/ykarant/e8df2b54-0637-4570-868b-9e542bf9a21f type xfs (rw,nosuid,nodev,relatime,seclabel,attr2,inode64,noquota,uhelper=udisks2) both of the /dev devices mentioned above are "automatic" from insertion into a USB jack (port) on a SL7 machine. The first is a 32 Gbyte flash drive "stick" with a works-installed MS file system, the second is an external 2 Tbyte USB harddrive with a XFS file system that is a dd copy of a partition from another SL 7 machine (that is having difficulties -- the partition is /home and the data is important). Note that the second is mounted as /dev/sdb (it was inserted before the flash drive), not as /dev/sdb1 . 2 Tbyte presumably is not "small", but nonetheless is mounted as /dev/xyz not /dev/xyzN . parted and gparted have no difficulties with either external USB drive once /dev/xyz "automatically" is created. The relevant outputs from parted run as root on the devices -- these contain/are mounted partitions: Using /dev/sdc Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: PNY USB 2.0 FD (scsi) Disk /dev/sdc: 31.0GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 4129kB 31.0GB 31.0GB primary fat32 lba Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: WD My Passport 25E1 (scsi) Disk /dev/sdb: 2000GB Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0.00B 2000GB 2000GB xfs Note that mount on the system reporting the above has no issue with mounting a /dev/xyz device not as /dev/xyzN Yasha Karant On 09/26/2018 10:34 AM, Gilles Detillieux wrote: > If a device has actual partitions, using a standard partitioning > scheme, even if it's just a single partition, then Linux should detect > that and create the appropriate device nodes in /dev. While less > common than a single partition covering most of the disk, some smaller > drives or devices have no partitioning at all, and therefore no > partition table at the start of the drive. In those cases, Linux will > set up a node for the drive, e.g. /dev/sdh, but no nodes for > partitions (e.g. no /dev/sdh1, 2, ...). If that's the case, then it's > likely that the whole drive is formatted as a single filesystem, so > you can mount /dev/sdh directly, or use mkfs on it if you want to > create a new filesystem. It's also possible for a drive to have a > corrupted partition table which Linux can't read, so it will create > the drive node, but no partition nodes. So, approach any drive that > has no clear partitions with a bit of caution. > > On 09/26/2018 12:05 PM, Yasha Karant wrote: >> To be clear, I created the partition and the XFS format using gparted, >> the gnome GUI interface to parted. My recollection from the past, and >> my observation as the drive was "flashing", was that I did not need >> manually to invoke mkfs using the GUI. However, rereading the man page >> for gparted, this step may have been lacking. I just confirmed by >> direct observation what I had forgotten; when a flash drive USB "stick" >> is inserted in a "modern" Linux system, at least two entries are created >> in /dev. In the immediate test case on the laptop before me, these are >> /dev/sdb and /dev/sdb1 (the USB flash drive is a MS Win format) and >> /dev/sdb1 is the mounted device. Thus, when the system reports /dev/xyz >> appears, the minimal first mount point would be /dev/xyzN as revealed >> through a ls of /dev/ . >> >> Question: what does one do if, after inserting a USB storage device, >> one gets /dev/xyz, say, but there is no /dev/xyzN despite parted >> reporting that the device does indeed have "MS" partitions as well as a >> filesystem? >> >> On 09/26/2018 07:47 AM, Gilles Detillieux wrote: >>> On 09/26/2018 08:34 AM, Howard, Chris wrote: >>>>> Why do parted and mount have this difference? >>>> /dev/sdg1 ? >>>> >>>> >>>> What he said. >>>> /dev/sdg is the whole device >>>> /dev/sdg1 is the first partition on that device. >>>> Partitions have file systems. Partitions with file systems can be >>>> mounted. >>>> >>>> parted works on the whole de
parted and mount
I have attempted to mount USB external formatted media on a SL7 system. One was a flash drive with a MS format (reported by parted as FAT32); the other was a 2 Tbyte hard drive XFS formatted on a different SL7 system. In both cases, the system automatically generated /dev/sdg when the USB device was connected through a USB port. parted on each device reported the correct file system and size/partition. As root, I created /mount/mnt1, but all attempts to mount /dev/sdg /mount/mnt1 failed with an unknown file system, even with the modifier -t (e.g., -t xfs for the xfs format USB hard drive). Why do parted and mount have this difference? Yasha Karant
off line upgrade to 7.5 from 7 previous [3] (was Re;)
Thank you for your assistance and information. Several comments. 1. All of the operations I performed were done using whatever is in the stock repos (SL, elrepo, and the like) and whatever is in stock yum for SL 7.1 (the base system that had not been fully updated in a while). If yum does perform the operation by first downloading all of the required RPM files and then starting the upgrade, the files should be on the machine. It appeared from what I observed that some were downloaded, the upgrade began, and others were being uploaded as the upgrade proceeded so that two operations were happening in a multi-threaded manner. That is a guess as I do not know where to look for the detailed logs as the system will boot (but no Xwindows). 2. The mirrored RAID was done using whatever was "stock" in SL7 at that epoch -- no outside special RAID was used. Clearly, the information I provided is insufficient definitively identify the RAID in question. What scrolling terminal command(s) provide such information? 3. What form of tar will copy a full directory (with both hard and soft links) to a file that can then be restored? I would use this for /home, /opt , and whatever systems configurations directories that need to be kept (SSH keys were mentioned). If tar will not do this, what dd command will? 4. I have a USB drive that contains the full image of the bootable installation procedure of a standard (not "everything") SL 7.5 ISO. Presumably, this image contains all of the RPMs that one would need. 4.1 What is the explicit command that provides a list of all of the current RPMs used in the SL 7.1 installed system? 4.1.1 Some of these came from non-SL repositories (such as the nvidia update packages) that would not be in the SL 7.5 installation ISO -- how does one configure the "repair" rpm invocation (not yum) not to go to the network to get these missing files but still not "crash"? 4.2 How does one convert the bootable install ISO into a RPM "repository" from which the replace packages rpm command will run -- *NOT* using the network? I found an upstream vendor old set of instructions, but these probably would not work for SL current. 4.2.1 Does the live system ISO bootable image require a network connection to update, or can it be configured to use local USB media from the bootable install ISO image? 4.3 My experience with updating packages (not a full system or kernel/driver update) is that a "replacement" rpm file may require additional rpm files that were not required by the package being updated. yum "automatically" takes care of this situation -- does rpm ? 4.4 Assuming that the nvidia package comes from a different distro, could I first get an updated system without nvidia support, then install the nvidia RPMs from USB media? The tower chassis in question is on the floor under a table (used as a desk) that has cables going from the back to the keyboard, monitor, pointing device, printer, small local UPS power supply, and the RJ45 IEEE 802.3 LAN jack. Note that the security system of the campus will not activate a LAN jack with a different MAC address than the one assigned to it -- replacing a 802.3 machine at this campus requires explicit contact with the local IT management controlling the campus LAN. Moreover, if a system has been "off" too long, the security system will "drop" the machine and require a call to IT LAN management. Thus, removal of a hard drive is possible but tedious. This has nothing to do with SL but with local campus IT management policy (imposed by the campus executive for "security"). The system did not "crash" panic -- it simply hung for several hours with no "visible" progress -- and was then rebooted. It did panic with the SL 7.5 kernel, but not the SL 7.1 kernel, just no Xwindows. Thanks again for any assistance. Yasha Karant On 08/24/2018 03:54 AM, Nico Kadel-Garcia wrote: On Wed, Aug 22, 2018 at 1:41 PM Yasha Karant wrote: Thanks for that approach. As I can get to USB drives, would the following work as root: 1. Insert a blank multi byte external USB drive (e.g., Western Digital, other vendors) on another machine and leave a blank format 2. Assuming that the drive on the failed machine is /dev/sda (e.g., sda1 ... sdaN), and that the external drive appears as /dev/sdb, issue dd if=/dev/sda of=/dev/sdb If you're going this route, you'll want to yank out the first hard drive while booting from the second. Put a filesystem on the second disk, and pour the first disk image into a file, not a raw disk. * dd if=/dev/sda of-/mnt/directory/filename.img Mount or manipulate the *image*, not the disk, so you don't see that disk image as scanned by your disk controllers at boot time. That lets you put ordinary "look up the disk names and mount them on the l
off line upgrade to 7.5 from 7 previous [3]
The pre SL 7.5 machine for which yum crashed during an upgrade does boot. I ran parted as root on the hard drive with the following output: Model: ATA TOSHIBA DT01ACA2 (scsi) Disk /dev/sda: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 32.3kB 41.1MB 41.1MB primary fat16 diag 2 41.9MB 11.1GB 11.1GB primary ntfs boot, diag 3 11.1GB 51.1GB 40.0GB primary xfs 4 51.1GB 2000GB 1949GB extended 5 51.1GB 1051GB 1000GB logical xfs 6 1051GB 1251GB 200GB logical xfs 7 1251GB 1451GB 200GB logical xfs 8 1451GB 1651GB 200GB logical xfs 9 1651GB 1751GB 100GB logical xfs 10 1751GB 1791GB 40.0GB logical linux-swap(v1) 11 1791GB 1941GB 150GB logical xfs Model: ATA TOSHIBA DT01ACA2 (scsi) Disk /dev/sdb: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 32.3kB 41.1MB 41.1MB primary fat16 diag 2 41.9MB 11.1GB 11.1GB primary ntfs boot, diag 3 11.1GB 51.1GB 40.0GB primary xfs 4 51.1GB 2000GB 1949GB extended 5 51.1GB 1051GB 1000GB logical xfs 6 1051GB 1251GB 200GB logical xfs 7 1251GB 1451GB 200GB logical xfs 8 1451GB 1651GB 200GB logical xfs 9 1651GB 1751GB 100GB logical xfs 10 1751GB 1791GB 40.0GB logical linux-swap(v1) 11 1791GB 1941GB 150GB logical xfs Model: Linux Software RAID Array (md) Disk /dev/md126: 2000GB Sector size (logical/physical): 512B/4096B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 32.3kB 41.1MB 41.1MB primary fat16 diag 2 41.9MB 11.1GB 11.1GB primary ntfs boot, diag 3 11.1GB 51.1GB 40.0GB primary xfs 4 51.1GB 2000GB 1949GB extended 5 51.1GB 1051GB 1000GB logical xfs 6 1051GB 1251GB 200GB logical xfs 7 1251GB 1451GB 200GB logical xfs 8 1451GB 1651GB 200GB logical xfs 9 1651GB 1751GB 100GB logical xfs 10 1751GB 1791GB 40.0GB logical linux-swap(v1) 11 1791GB 1941GB 150GB logical xfs End output. An external USB 2 Tbyte drive is mounted by this system as /dev/sdg Is there any reason that as root dd if=/dev/sda of=/dev/sdg would not image the mirrored "RAID" drives from one of the mirror set? By this means, all of /home , /opt and the like should be recoverable? There may be minor discrepancies but as the system was not being used other than for root to run yum, the image should have all vital configuration files as well as all end-user home directories. Also, as the system does boot, is there anyway to start yum "fresh" and force an upgrade at this point? Only the Xwindows system fails under the old system. During the boot sequence, one can choose the SL7.5 image, but this one fails with a panic due to the yum upgrade failure. However, the older system image does boot as the above output serves to verify. My guess is there are one or more yum bookkeeping files that need modification for a "fresh" yum update to be enabled. Any further assistance would be appreciated. Yasha Karant
Re: off line upgrade to 7.5 from 7 previous [2]
The response below does not seem to agree with what I observed.
The downloads strictly were from the specified repos for an update, all
from the web (no local NFS, etc., caching). If what is stated below is
correct, unless yum is not re-entrant, once the installation (update)
had started, all of the necessary RPMS (perhaps one hundred) should be
on the harddrive. Because the old SL 7 system will boot (no X11), and
the files should be on the hard drive, then yum should be able to
re-enter where it "left off".
If the RPM files are kept in a temporary directory that is erased upon
re-boot, an unfinished update could (would) fail.
Assuming that the bootable SL system can get to the network (or will
this require "network manager"?), is there a way to force yum to start
the update from the beginning?
In the interim, I am going to image the system hard drive to a 2 Tbyte
external USB hard drive using dd.
If I cannot get yum to "restart", I will do a full install from the USB
ISO SL 7.5 install image, and then restore /home , /opt, ssh-keys, and
the like from the
image, unless a better approach appears in response.
Yasha Karant
On 08/23/2018 11:37 AM, Chris Schanzle wrote:
If you do the first paragraph below, you'll have a unknown mess and
will always consider the system "flaky". Please: reinstall from
scratch and restore your home directory data. You'll at least be in a
well-known state and that's worth a lot to your peace of mind. Maybe
try to save/restore your /etc/ssh/ directory to keep your host keys or
other /etc data in case you need it for service reconfiguration.
Yum does not require the network after the installation begins. I.e.,
it downloads the packages to local disk first, then starts the install.
The system may have hung for other reasons (e.g., NFS mounts), but not
because yum needed the network.
Hope that helps!
On 08/22/2018 02:16 PM, Yasha Karant wrote:
Another approach to consider: the failed system is SL 7.2 and does
boot but does not bring up the GUI (e.g., ctrl-alt-F3 brings up a
login prompt on a scrolling terminal screen and all users, including
root, may log into the system). I have other working SL 7.2 systems
(I have had no time to update and have no GSRAs or Staff right now to
help). If I cp -pr /usr , /bin , whatever (but not /home and the
like) from a working system to the failed system, will the failed
system then be able to use other mechanisms for an update rather than
a full new install of SL 7.5 followed by a restore of /home and the
like?
Why was this system being upgraded? It appears that the Palo Alto
security systems on the end-users 802.3 network segment was
"complaining", hopefully "fixed" by SL 7 current. (Different
security is used on the 802.11 networks.)
As the campus network where I work i not designed for reliable
systems work but rather end-user files (if the network glitches,
simply repeat the download, etc.), is there a mechanism to update
from media, say using the iso install image from a USB thumb drive?
Thanks for any assistance.
Yasha Karant
On 08/21/2018 03:47 PM, Nico Kadel-Garcia wrote:
On Tue, Aug 21, 2018 at 5:53 PM Yasha Karant wrote:
During the upgrade of a SL 7 non-current system to SL 7 (via yum
update
as root from the Internet), the campus network "glitched" and the
system
hung. The 7.5 partially installed system panics; it has not
recovered.
The 7 non-current will boot but no X (no GUI), only a scrolling text
terminal, presumably from which yum can be executed.
If you want to keep this beastie alive, I urge you to:
* Boot from a live USB or DVD image with networking enabled
* Mount the old partitions at /mnt/sysimage, with subpartitions
appropriately under that
* chroot to /mnt/sysimage
* Run "rpm --rebuilddb", because it is probably corrupt
* Get the list of installed packages with "rpm -qa --qf
'%{name}.%{arch}\n'"
* For every package, use "yum upgrade $name" and "yum reinstall $name"
* * yum reinstall may require enabling the obsolete repositories
* One or more are likely to balk due to two distinct versions of the
same package. Resolve that balking package manually, downloading the
current version and using "rpm -U --replacepkgs $name"
I have downloaded Scientific-7.5-Install-Dual-Layer-DVD-x86_64.iso and
then put this onto an USB flash "thumb" drive that I have confirmed is
bootable and will start the installation steps. I do not want to do a
new install but rather an upgrade, not touching /home , /opt and
the like.
I have found old upstream vendor instructions for a previous upstream
vendor major release of the enterprise (not enthusiast) system; please
see below. How are these to
be modified for SL 7.5? If I boot the Install ISO image (from the USB
drive), is there a way to get to the old GUI upgrade option that seems
no l
Re: off line upgrade to 7.5 from 7 previous [2]
Another approach to consider: the failed system is SL 7.2 and does boot
but does not bring up the GUI (e.g., ctrl-alt-F3 brings up a login
prompt on a scrolling terminal screen and all users, including root, may
log into the system). I have other working SL 7.2 systems (I have had
no time to update and have no GSRAs or Staff right now to help). If I
cp -pr /usr , /bin , whatever (but not /home and the like) from a
working system to the failed system, will the failed system then be able
to use other mechanisms for an update rather than a full new install of
SL 7.5 followed by a restore of /home and the like?
Why was this system being upgraded? It appears that the Palo Alto
security systems on the end-users 802.3 network segment was
"complaining", hopefully "fixed" by SL 7 current. (Different security
is used on the 802.11 networks.)
As the campus network where I work i not designed for reliable systems
work but rather end-user files (if the network glitches, simply repeat
the download, etc.), is there a mechanism to update from media, say
using the iso install image from a USB thumb drive?
Thanks for any assistance.
Yasha Karant
On 08/21/2018 03:47 PM, Nico Kadel-Garcia wrote:
On Tue, Aug 21, 2018 at 5:53 PM Yasha Karant wrote:
During the upgrade of a SL 7 non-current system to SL 7 (via yum update
as root from the Internet), the campus network "glitched" and the system
hung. The 7.5 partially installed system panics; it has not recovered.
The 7 non-current will boot but no X (no GUI), only a scrolling text
terminal, presumably from which yum can be executed.
If you want to keep this beastie alive, I urge you to:
* Boot from a live USB or DVD image with networking enabled
* Mount the old partitions at /mnt/sysimage, with subpartitions
appropriately under that
* chroot to /mnt/sysimage
* Run "rpm --rebuilddb", because it is probably corrupt
* Get the list of installed packages with "rpm -qa --qf '%{name}.%{arch}\n'"
* For every package, use "yum upgrade $name" and "yum reinstall $name"
* * yum reinstall may require enabling the obsolete repositories
* One or more are likely to balk due to two distinct versions of the
same package. Resolve that balking package manually, downloading the
current version and using "rpm -U --replacepkgs $name"
I have downloaded Scientific-7.5-Install-Dual-Layer-DVD-x86_64.iso and
then put this onto an USB flash "thumb" drive that I have confirmed is
bootable and will start the installation steps. I do not want to do a
new install but rather an upgrade, not touching /home , /opt and the like.
I have found old upstream vendor instructions for a previous upstream
vendor major release of the enterprise (not enthusiast) system; please
see below. How are these to
be modified for SL 7.5? If I boot the Install ISO image (from the USB
drive), is there a way to get to the old GUI upgrade option that seems
no longer available?
It's nearly impossible to tell which components got messed up in a
mass upgrade. Start from a cleaned up upgrade process, as described
above.
Please reply to ykar...@gmail.com. Any assistance would be appreciated.
Yasha Karant
Re: off line upgrade to 7.5 from 7 previous
Thanks for that approach. As I can get to USB drives, would the
following work as root:
1. Insert a blank multi byte external USB drive (e.g., Western Digital,
other vendors) on another machine and leave a blank format
2. Assuming that the drive on the failed machine is /dev/sda (e.g.,
sda1 ... sdaN), and that the external drive appears as /dev/sdb,
issue
dd if=/dev/sda of=/dev/sdb
thereby "imaging" the current harddrive but having exact images of
/home, /opt, and the like
3. Install SL7.5 from the bootable USB iso install image, manually
partitioning to same sizes as on the existing drive
4. cp -pr /home and the like from the USB image drive to the "new" SL
7.5 system, thereby restoring all files
Note that the above has far fewer manual steps than the suggested procedure.
I often use yumex GUI to perform such updates. If the network
"glitches" during a yumex massive update, would the system again be in
an unbootable state?
Does anyone have a mechanism for SL7.5 to perform an upgrade rather than
a new install booting from the install ISO image file?
Thanks,
Yasha Karant
On 08/21/2018 03:47 PM, Nico Kadel-Garcia wrote:
On Tue, Aug 21, 2018 at 5:53 PM Yasha Karant wrote:
During the upgrade of a SL 7 non-current system to SL 7 (via yum update
as root from the Internet), the campus network "glitched" and the system
hung. The 7.5 partially installed system panics; it has not recovered.
The 7 non-current will boot but no X (no GUI), only a scrolling text
terminal, presumably from which yum can be executed.
If you want to keep this beastie alive, I urge you to:
* Boot from a live USB or DVD image with networking enabled
* Mount the old partitions at /mnt/sysimage, with subpartitions
appropriately under that
* chroot to /mnt/sysimage
* Run "rpm --rebuilddb", because it is probably corrupt
* Get the list of installed packages with "rpm -qa --qf '%{name}.%{arch}\n'"
* For every package, use "yum upgrade $name" and "yum reinstall $name"
* * yum reinstall may require enabling the obsolete repositories
* One or more are likely to balk due to two distinct versions of the
same package. Resolve that balking package manually, downloading the
current version and using "rpm -U --replacepkgs $name"
I have downloaded Scientific-7.5-Install-Dual-Layer-DVD-x86_64.iso and
then put this onto an USB flash "thumb" drive that I have confirmed is
bootable and will start the installation steps. I do not want to do a
new install but rather an upgrade, not touching /home , /opt and the like.
I have found old upstream vendor instructions for a previous upstream
vendor major release of the enterprise (not enthusiast) system; please
see below. How are these to
be modified for SL 7.5? If I boot the Install ISO image (from the USB
drive), is there a way to get to the old GUI upgrade option that seems
no longer available?
It's nearly impossible to tell which components got messed up in a
mass upgrade. Start from a cleaned up upgrade process, as described
above.
Please reply to ykar...@gmail.com. Any assistance would be appreciated.
Yasha Karant
off line upgrade to 7.5 from 7 previous
During the upgrade of a SL 7 non-current system to SL 7 (via yum update as root from the Internet), the campus network "glitched" and the system hung. The 7.5 partially installed system panics; it has not recovered. The 7 non-current will boot but no X (no GUI), only a scrolling text terminal, presumably from which yum can be executed. I have downloaded Scientific-7.5-Install-Dual-Layer-DVD-x86_64.iso and then put this onto an USB flash "thumb" drive that I have confirmed is bootable and will start the installation steps. I do not want to do a new install but rather an upgrade, not touching /home , /opt and the like. I have found old upstream vendor instructions for a previous upstream vendor major release of the enterprise (not enthusiast) system; please see below. How are these to be modified for SL 7.5? If I boot the Install ISO image (from the USB drive), is there a way to get to the old GUI upgrade option that seems no longer available? Please reply to ykar...@gmail.com. Any assistance would be appreciated. Yasha Karant https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_documentation_en-2Dus_red-5Fhat-5Fenterprise-5Flinux_5_html_deployment-5Fguide_s1-2Dyum-2Dupgrade-2Dsystem=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=VIBZAPLSw5i79APlbk9o7bb7-I8Ng0G_fvWaaH3Ayb0=_Mk6MJ3Ff8HTunQdaQhWLUrVysCAIcVDqWQc9u7T-DQ= 14.5. Upgrading the System Off-line with ISO and Yum For systems that are disconnected from the Internet or Red Hat Network, using the yum update command with the Red Hat Enterprise Linux installation ISO image is an easy and quick way to upgrade systems to the latest minor version. The following steps illustrate the upgrading process: Create a target directory to mount your ISO image. This directory is not automatically created when mounting, so create it before proceeding to the next step, as root, type: mkdir mount_dir Replace mount_dir with a path to the mount directory. Typicaly, users create it as a subdirectory in the /media/ directory. Mount the Red Hat Enterprise Linux 5 installation ISO image to the previously created target directory. As root, type: mount -o loop iso_name mount_dir Replace iso_name with a path to your ISO image and mount_dir with a path to the target directory. Here, the -o loop option is required to mount the file as a block device. Check the numeric value found on the first line of the .discinfo file from the mount directory: head -n1 mount_dir/.discinfo The output of this command is an identification number of the ISO image, you need to know it to perform the following step. Create a new file in the /etc/yum.repos.d/ directory, named for instance new.repo, and add a content in the following form. Note that configuration files in this directory must have the .repo extension to function properly. [repository] mediaid=media_id name=repository_name baseurl=repository_url gpgkey=gpg_key enabled=1 gpgcheck=1 Replace media_id with the numeric value found in mount_dir/.discinfo. Set the repository name instead of repository_name, replace repository_url with a path to a repository directory in the mount point and gpg_key with a path to the GPG key. For example, the repository settings for Red Hat Enterprise Linux 5 Server ISO can look as follows: [rhel5-Server] mediaid=1354216429.587870 name=RHEL5-Server baseurl=file:///media/rhel5/Server gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release enabled=1 gpgcheck=1 Update all yum repositories including /etc/yum.repos.d/new.repo created in previous steps. As root, type: yum update This upgrades your system to the version provided by the mounted ISO image. After successful upgrade, you can unmount the ISO image, with the root privileges: umount mount_dir where mount_dir is a path to your mount directory. Also, you can remove the mount directory created in the first step. As root, type: rmdir mount_dir If you will not use the previously created configuration file for another installation or update, you can remove it. As root, type: rm /etc/yum.repos.d/new.repo Example 14.1. Upgrading from Red Hat Enterprise Linux 5.8 to 5.9 Imagine you need to upgrade your system without access to the Internet connection. To do so, you want to use an ISO image with the newer version of the system, called for instance RHEL5.9-Server-20121129.0-x86_64-DVD1.iso. You have crated a target directory /media/rhel5/. As root, change into the directory with your ISO image and type: ~]# mount -o loop RHEL5.9-Server-20121129.0-x86_64-DVD1.iso /media/rhel5/ To find the identification number of the mounted image, run: ~]# head -n1 /media/rhel5/.discinfo 1354216429.587870 You need this number to configure your mount point as a yum reposit
Brother dcpl2540dw
The Department of my spouse is now using Brother over HP printer/scanners. To duplicate what she has in her office, we purchased the same machine for our use, a Brother dcpl2540dw. I installed the Brother proprietary Linux drivers, and using the SL 7 printer configuration application (CUPS based), had no issues with getting the printer to print a test page using our home IEEE 802.11 network. However, it appears that the dcpl2540dw will not scan to a USB device, unlike the HP unit, but only to a computer on a network. Has anyone been able to get the Brother dcpl2540dw to operate as a network scanner? The computer in her office has the printer physically near her office tower workstation (not a laptop), and is connected USB. Thus, there is no network connection to the printer in her office, unlike at home. However, in neither case have I been able to get the scanning functionality to work. Also, what application does one use to accept the scan or to allow the scanner to produce a .pdf file on the target computer? I simply scanned to a MS FAT file system USB memory stick on the HP unit, but evidently the Brother does not have this capability. Once on a memory stick, the PDF file easily could be accessed on a SL7 system. I have found a systems tool that is claimed to simplify the process and not depend upon updates from Brother as new releases of Linux appear: https://www.hamrick.com/vuescan/brother_dcp_l2540dw.html Has anyone used this application? If so, any comments? Is there any GPL, etc., application with similar functionality? Thanks for any information. Yasha Karant
Re: davmail
On 09/28/2017 04:25 AM, Bruce Ferrell wrote: On 09/27/2017 09:56 PM, Yasha Karant wrote: On 09/27/2017 09:50 PM, Bruce Ferrell wrote: On 09/27/2017 06:33 PM, Yasha Karant wrote: I have been instructed to use davmail by the university IT who insist that the university use a proprietary Microsoft email service. Although the service nominally provides IETF SMTP and IMAP compliant access, this access has been unreliable. I have found the following from http://davmail.sourceforge.net/linuxsetup.html and I have not found a SL 7 davmail RPM. Does anyone use davmail with SL 7 and Mozilla Thunderbird IMAP and SMTP (my choice for an email client)? If so, Manual setup Prerequisite: OpenJDK 6 or 7 or Sun JRE 6. Tray icon is now implemented with SWT and compatible with Java 5. Note: some users reported issues with OpenJDK 6, please upgrade to OpenJDK 7 in this case. You should first download and install Java, with the graphical package manager or through command line. Under Ubuntu, launch System/Administration/Synaptic Package Manager, quick search default-jre, mark for installation and click Apply Or use the following command: sudo apt-get install default-jre Download the linux x86 DavMail package from Sourceforge and uncompress it with your favorite tool. The standard package will run natively on x86, to use DavMail on any other hardware platform, replace the SWT with the right one from http://www.eclipse.org/swt/ or use the platform independent package. On Ubuntu and other Gnome or Kde distributions, just use the desktop launcher. On other distributions, try davmail.sh. You should now see the DavMail gateway icon in the tray : end excerpt that is followed by examples of the various GUI boxes that one must complete. Thanks for any assistance. Yasha Karant From what you say, you may be using exchange and while davmail may do the job, I used exquilla. It cost me $10.00/year for the license, but I found it VERY effective in dealing with MS Exchange. From looking over davmail, it set's up a pop3/imap gateway to mapi mail services. Exquilla: Reviews *Add-on no longer working* Rated 1 out of 5 stars by deep-blue <https://addons.mozilla.org/en-US/thunderbird/user/deep-blue/> on August 2, 2017 · permalink <https://addons.mozilla.org/en-US/thunderbird/addon/exquilla-exchange-web-services/reviews/900573/> We use the program for commercial purposes. There are many problems: * Bad release management (add-on no longer works) * Poor support If there are no significant improvements, we will not extend a license. End excerpt. Do you disagree with the above review of exquilla? Yes I have to disagree with that review. I I started using the plugin four years ago and stopped about two weeks ago, when the company I work for changed from exchange server to office365 (pop3/imap). Any time I had a difficulty I opened a support case and received very prompt responses and fixes or explanations. MAPI/exchange server is a royal pain and the exquilla add-on made it far less so for me. Your mileage may vary. From my Tbird configuration for the email server in question: outlook.office365.com Supposedly, I am using office365 that you indicate is IETF IMAP compliant. The diagnostic on failure states "authenticated but not connected". As for later comments in this thread, I too do not like fully integrated clients that also run additional servers (e.g., a RDBMS system) to operate. It is true that Mozilla has a directory in which it keeps the "data" for email, etc., but this is one directory (and sub-tree thereof) that needs to be copied and restored. Yasha Karant
Re: davmail
On 09/27/2017 09:50 PM, Bruce Ferrell wrote: On 09/27/2017 06:33 PM, Yasha Karant wrote: I have been instructed to use davmail by the university IT who insist that the university use a proprietary Microsoft email service. Although the service nominally provides IETF SMTP and IMAP compliant access, this access has been unreliable. I have found the following from http://davmail.sourceforge.net/linuxsetup.html and I have not found a SL 7 davmail RPM. Does anyone use davmail with SL 7 and Mozilla Thunderbird IMAP and SMTP (my choice for an email client)? If so, Manual setup Prerequisite: OpenJDK 6 or 7 or Sun JRE 6. Tray icon is now implemented with SWT and compatible with Java 5. Note: some users reported issues with OpenJDK 6, please upgrade to OpenJDK 7 in this case. You should first download and install Java, with the graphical package manager or through command line. Under Ubuntu, launch System/Administration/Synaptic Package Manager, quick search default-jre, mark for installation and click Apply Or use the following command: sudo apt-get install default-jre Download the linux x86 DavMail package from Sourceforge and uncompress it with your favorite tool. The standard package will run natively on x86, to use DavMail on any other hardware platform, replace the SWT with the right one from http://www.eclipse.org/swt/ or use the platform independent package. On Ubuntu and other Gnome or Kde distributions, just use the desktop launcher. On other distributions, try davmail.sh. You should now see the DavMail gateway icon in the tray : end excerpt that is followed by examples of the various GUI boxes that one must complete. Thanks for any assistance. Yasha Karant From what you say, you may be using exchange and while davmail may do the job, I used exquilla. It cost me $10.00/year for the license, but I found it VERY effective in dealing with MS Exchange. From looking over davmail, it set's up a pop3/imap gateway to mapi mail services. Exquilla: Reviews *Add-on no longer working* Rated 1 out of 5 stars by deep-blue <https://addons.mozilla.org/en-US/thunderbird/user/deep-blue/> on August 2, 2017 · permalink <https://addons.mozilla.org/en-US/thunderbird/addon/exquilla-exchange-web-services/reviews/900573/> We use the program for commercial purposes. There are many problems: * Bad release management (add-on no longer works) * Poor support If there are no significant improvements, we will not extend a license. End excerpt. Do you disagree with the above review of exquilla?
davmail
I have been instructed to use davmail by the university IT who insist that the university use a proprietary Microsoft email service. Although the service nominally provides IETF SMTP and IMAP compliant access, this access has been unreliable. I have found the following from http://davmail.sourceforge.net/linuxsetup.html and I have not found a SL 7 davmail RPM. Does anyone use davmail with SL 7 and Mozilla Thunderbird IMAP and SMTP (my choice for an email client)? If so, Manual setup Prerequisite: OpenJDK 6 or 7 or Sun JRE 6. Tray icon is now implemented with SWT and compatible with Java 5. Note: some users reported issues with OpenJDK 6, please upgrade to OpenJDK 7 in this case. You should first download and install Java, with the graphical package manager or through command line. Under Ubuntu, launch System/Administration/Synaptic Package Manager, quick search default-jre, mark for installation and click Apply Or use the following command: sudo apt-get install default-jre Download the linux x86 DavMail package from Sourceforge and uncompress it with your favorite tool. The standard package will run natively on x86, to use DavMail on any other hardware platform, replace the SWT with the right one from http://www.eclipse.org/swt/ or use the platform independent package. On Ubuntu and other Gnome or Kde distributions, just use the desktop launcher. On other distributions, try davmail.sh. You should now see the DavMail gateway icon in the tray : end excerpt that is followed by examples of the various GUI boxes that one must complete. Thanks for any assistance. Yasha Karant <>
Re: [SCIENTIFIC-LINUX-USERS] yumex failed to update SL7x to current
4 44/44 Verifying : libblkid-2.23.2-33.el7_3.2.i686 1/44 Verifying : gvfs-fuse-1.30.4-3.el7.x86_64 2/44 Verifying : gvfs-goa-1.30.4-3.el7.x86_643/44 Verifying : libplist-1.12-3.el7.x86_64 4/44 Verifying : libusbmuxd-1.0.10-5.el7.x86_64 5/44 Verifying : upower-0.99.4-2.el7.x86_64 6/44 Verifying : libmount-2.23.2-33.el7_3.2.i686 7/44 Verifying : libgpod-0.8.2-12.el7.x86_64 8/44 Verifying : gvfs-archive-1.30.4-3.el7.x86_649/44 Verifying : glib2-2.50.3-3.el7.i68610/44 Verifying : libimobiledevice-1.2.0-1.el7.x86_6411/44 Verifying : gvfs-client-1.30.4-3.el7.x86_6412/44 Verifying : libgdata-0.17.8-1.el7.x86_64 13/44 Verifying : gvfs-1.30.4-3.el7.x86_64 14/44 Verifying : usbmuxd-1.1.0-1.el7.x86_64 15/44 Verifying : gvfs-smb-1.30.4-3.el7.x86_64 16/44 Verifying : gvfs-gphoto2-1.30.4-3.el7.x86_64 17/44 Verifying : libgdata-devel-0.17.8-1.el7.x86_64 18/44 Verifying : gvfs-mtp-1.30.4-3.el7.x86_64 19/44 Verifying : gvfs-afp-1.30.4-3.el7.x86_64 20/44 Verifying : glib2-2.50.3-3.el7.x86_64 21/44 Verifying : gvfs-devel-1.30.4-3.el7.x86_64 22/44 Verifying : glib2-devel-2.50.3-3.el7.x86_6423/44 Verifying : gvfs-afc-1.30.4-3.el7.x86_64 24/44 Verifying : libgpod-0.8.3-14.el7.x86_6425/44 Verifying : glib2-2.46.2-4.el7.i68626/44 Verifying : glib2-2.46.2-4.el7.x86_64 27/44 Verifying : upower-0.99.2-1.el7.x86_64 28/44 Verifying : libgdata-devel-0.17.1-1.el7.x86_64 29/44 Verifying : libgdata-0.17.1-1.el7.x86_64 30/44 Verifying : gvfs-mtp-1.22.4-8.el7.x86_64 31/44 Verifying : gvfs-afc-1.22.4-8.el7.x86_64 32/44 Verifying : gvfs-archive-1.22.4-8.el7.x86_64 33/44 Verifying : gvfs-smb-1.22.4-8.el7.x86_64 34/44 Verifying : gvfs-devel-1.22.4-8.el7.x86_64 35/44 Verifying : libplist-1.10-4.el7.x86_64 36/44 Verifying : gvfs-gphoto2-1.22.4-8.el7.x86_64 37/44 Verifying : gvfs-goa-1.22.4-8.el7.x86_64 38/44 Verifying : libimobiledevice-1.1.5-6.el7.x86_6439/44 Verifying : gvfs-fuse-1.22.4-8.el7.x86_64 40/44 Verifying : usbmuxd-1.0.8-11.el7.x86_6441/44 Verifying : usbmuxd-1.0.8-11.el7.x86_6442/44 Verifying : glib2-devel-2.46.2-4.el7.x86_6443/44 Verifying : gvfs-1.22.4-8.el7.x86_64 44/44 Verifying : gvfs-afp-1.22.4-8.el7.x86_64 45/44 Removed: libgpod.x86_64 0:0.8.3-14.el7 Installed: libgpod.x86_64 0:0.8.2-12.el7 usbmuxd.x86_64 0:1.1.0-1.el7 Dependency Installed: gvfs-client.x86_64 0:1.30.4-3.el7 libblkid.i686 0:2.23.2-33.el7_3.2 libmount.i686 0:2.23.2-33.el7_3.2 libusbmuxd.x86_64 0:1.0.10-5.el7 Dependency Updated: glib2.i686 0:2.50.3-3.el7 glib2.x86_64 0:2.50.3-3.el7 glib2-devel.x86_64 0:2.50.3-3.el7 gvfs.x86_64 0:1.30.4-3.el7 gvfs-afc.x86_64 0:1.30.4-3.el7 gvfs-afp.x86_64 0:1.30.4-3.el7 gvfs-archive.x86_64 0:1.30.4-3.el7 gvfs-devel.x86_64 0:1.30.4-3.el7 gvfs-fuse.x86_64 0:1.30.4-3.el7gvfs-goa.x86_64 0:1.30.4-3.el7 gvfs-gphoto2.x86_64 0:1.30.4-3.el7 gvfs-mtp.x86_64 0:1.30.4-3.el7 gvfs-smb.x86_64 0:1.30.4-3.el7 libgdata.x86_64 0:0.17.8-1.el7 libgdata-devel.x86_64 0:0.17.8-1.el7 libimobiledevice.x86_64 0:1.2.0-1.el7 libplist.x86_64 0:1.12-3.el7 upower.x86_64 0:0.99.4-2.el7 Replaced: usbmuxd.x86_64 0:1.0.8-11.el7 Complete! [root@jb344 ykarant]# On 09/18/2017 09:53 AM, Pat Riehecky wrote: Please run 'yum downgrade libgpod' On 09/18/2017 11:51 AM, Yasha Karant wrote: I used yumex to update SL7 production to current SL7production release. The update failed with the following diagnostics: Dependency Resolution Error
yumex failed to update SL7x to current
I used yumex to update SL7 production to current SL7production release. The update failed with the following diagnostics: Dependency Resolution Errors: Package: libgpod-0.8.3-14.el7.x86_64 (@epel) Requires: libimobiledevice.so.4()(64bit) Removing: libimobiledevice-1.1.5-6.el7.x86_64 (@anaconda) libimobiledevice.so.4()(64bit) Updated By: libimobiledevice-1.2.0-1.el7.x86_64 (sl-security) ~libimobiledevice.so.6()(64bit)Package: libgpod-0.8.3-14.el7.x86_64 (@epel) Requires: libusbmuxd.so.2()(64bit) Removing: usbmuxd-1.0.8-11.el7.x86_64 (@anaconda) libusbmuxd.so.2()(64bit) Obsoleted By: usbmuxd-1.1.0-1.el7.x86_64 (sl-security) Not found Updated By: usbmuxd-1.1.0-1.el7.x86_64 (sl-security) Not foundPackage: libgpod-0.8.3-14.el7.x86_64 (@epel) Requires: libplist.so.1()(64bit) Removing: libplist-1.10-4.el7.x86_64 (@anaconda) libplist.so.1()(64bit) Updated By: libplist-1.12-3.el7.x86_64 (sl-security) ~libplist.so.3()(64bit) Where does one find the "Not found" packages, and/or what changes need to be made to configuration files (e.g., simply not updating which packages from the yumex list)? I understand that epel is not part of the FNAL SL base, but I know that persons with epel knowledge do read this list. sl-security should be an SL issue; it appears: Obsoleted By: usbmuxd-1.1.0-1.el7.x86_64 (sl-security) Not found Yasha Karant <>
Sagemath
Sagemath is an open source licensed-for-free alternative to Mathematica, Maple, and other proprietary applications. Has anyone compiled -- or found an installation, not source, RPM for -- Sagemath for SL7? Yasha Karant <>
hp-toolbox
If you are using hp-toolbox from Hewlett-Packard and the HP print drivers, somewhere during the SL7x upgrade/maintenance chain (including subsidiary application), the print driver appears to "break". I used the hp-toolbox GUI and had to install new plugins from HP for this application. After that, the HP printer (connected via USB to a SL 7x Linux workstation) again printed. Yasha Karant <>
successful 7.3 update through yumex
Yesterday afternoon, I did a successful update from production 7.2 to production 7.3 through yumex. In addition to the SL production repositories, I use the epel, elrepo, and google-chrome repositories for specific add-ons, including nvidia support. I only use kernels from SL. Although the update was slow, it taking a very long time for the nvidia portion to complete cleanup (I left after a 5 minute wait), when I came back this morning, everything appears to be working, including applications that have not been touched since I first installed SL 7 (e.g., UCSF chimera, Weizmann grace). The machine to which this was done has a 802.3 wired connection to a USA university research backbone. The next thing to update is my laptop that has a 802.11 connection to a production network, significantly lower data rate. Is there any way to get a list of the required RPMs, download and burn these to a DVD, and then have yumex use the DVDs, only going to the network to get additional RPMs that turn out to be needed? Yasha Karant <>
Integration with Apple iPad 2 air
I understand that this not an Apple forum. However, my spouse has been assigned an Apple iPad 2 Air from our university administration, and she was reluctant for political reasons to demand a Linux or Android "equivalent" of this unit. I have been attempting to configure it . I have found that Mozilla does not support this platform: (quoting from Mozilla) Mozilla.org <http://Mozilla.org> does not have any version of Thunderbird and Firefox for iOS due to Apple's restrictions on the JavaScript and browser engines that can be used. Are there any email apps, preferably licensed for free and not requiring an additional service, that will connect to arbitrary MAP servers and provide anything close to a Thunderbird email client end-user experience? Are there any sys admin or equivalent level books/websites for this unit? I only have found end-user documentation, most of which is strictly cookbook. The unit was equipped with a Logitech add-on case/bluetooth keyboard, so one is not forced to a touchscreen keyboard for most uses. I am not expecting responses on-list, but any assistance/advice would be most appreciated. Yasha Karant
MacOS X Mac Mail with SL Thunderbird issues
From a colleague: Your mail client doesn’t play nicely with mine (Mac Mail). As you can see by the screen snap, it doesn’t wrap text and includes the long version of headers on forwarded messages. As a result, I sometimes don’t read stuff from you because it’s too annoying to scroll and scroll… End quote. A web search does not reveal anything about this issue. I do not have an Apple MacOS X box; all Linux and MS Win Thunderbird users do not report this issue. I am using IMAP for reading email, and an external SMTP server for sending email. Is there a (SL) Thunderbird configuration that is more Mac Mail friendly? Yasha Karant
SL7 compatible 4G ISP needed
I need a 4G wireless USB WNIC and ISP (carrier) that is SL 7 compatible -- that is, that the drivers exist for SL 7, not just MS Win or Mac OS X. The service needs to be in my geographic region; thus, I will check recommendations against service area (several I have found do not serve my area). I do not want to use a MIFI access point unless a UTP hardwired 802.3 connection is supported -- I do not want to use 802.11 or Bluetooth to connect to the access point . Any suggestions greatly would be appreciated. Thus, a USB direct connection into the machine would be best. Yasha Karant <>
Re: problem (with Gnome,on non-root logins)
Assuming that you found Gnome 2 more acceptable than MS Win 8 or 10, etc., may I strongly recommend MATE? I have this GUI/manager installed on all my SL 7 boxes, as well as on a Mint box for a colleague (the laptop in that case came pre-installed with Mint -- leaving it was much less work than starting from scratch with the current EL 7 installation DVD). Note that for full functionality, one must install essentially all of the MATE RPMs otherwise small but convenience-necessa bits are missing. Yasha Karant On 10/13/2016 08:41 AM, James M. Pulver wrote: FWIW whenever I boot Kali and get stuck with Gnome 3 (at least that's what I think that abomination is), I can't do much of anything. It's actively worse than Win 10 / Mac OSX, though part of it might be the live CD part of it. In day to day I have converted many people to XFCE4 which seems far more sane, in _my_ experience. James Pulver CLASSE Computer Group Cornell University On 10/13/2016 04:51 AM, David Sommerseth wrote: On 13/10/16 03:21, Nico Kadel-Garcia wrote: On Wed, Oct 12, 2016 at 1:08 PM, MAH Maccallum <m.a.h.maccal...@qmul.ac.uk> wrote: Thanks, Andrew. I will check those possibilities. A problem with the graphics drivers seems likely in that I get the same result with my default (test) user as with my own personal login. However, logging in as root gives a perfectly normal Gnome screen.So it may be that somehow a permission got changed. What's odd is that this all happened in the course of moving the cursor around and the abrt error message suggests it was moving the cursor across the clock that caused the problem. Gnome is *not the friend of getting work done*. Seriously. It's become so driven that it interferes with actual work. That's your experience. My experience with GNOME 3 on SL7.2 is that is vastly have improved workflow. A lot of it comes through very handy keyboard shortcuts and a handful of GNOME Shell extensions. In fact I can't imagine any sane reason to move back to GNOME 2 or anything else - it just feels so clumsy and horrid to work with for me. Everything just runs very smoothly and fine on my ThinkPad T450s. But this is /my/ experience. -- kind regards, David Sommerseth - If I had asked people what they wanted, they would have said "faster horses." -Henry Ford <>
Re: SL 7.2 on a HP Zbook
On 10/07/2016 11:14 AM, Bill Askew wrote: Hi everyone I am using SL 7.2 on a HP Zbook. So far the only issue that I have is setting the date and time does not set the Zbook's hardware clock. It does change the time for the duration of the session but when the ZBook is rebooted the time goes back to what it was before plus the amount of time I spent during the session. Does anyone have a fix for this? Thanks I am using SL 7.2x on a HP Zbook without this issue. Which model? Mine is several years old and thus might be different from yours. Yasha Karant
Re: Missing laptop mains power indication [3]
Problem solved. Although the power light (physical LED on laptop) was illuminated, replacing the mains adapter solved the problem. Evidently not a software issue but a problem with the output (power? voltage?) of the mains adapter sufficient for the LED to illuminate but not in fact sufficient to power the laptop. Apologies for the extra traffic. Yasha Karant On 09/29/2016 08:45 AM, Yasha Karant wrote: I just updated to the current SL7 security via yumex on both a workstation (mains only) and a laptop (internal battery, mains adapter) Kernel 3.10.0-327.36.1.el7.x86_64 -- all yumex update recommended RPMs were installed. HP Zbook Both MATE PowerManager 1.14.0 and GKrellM 2.3.5 report no mains adapter and 83 percent remaining in the battery for 10 hours 30 minutes -- this started after the above update. The amount of battery time is very far off -- it really should be about 2 hours. Has anyone else experienced this? Is there a fix/workaround? Yasha Karant
Missing laptop mains power indication
I just updated to the current SL7 security via yumex on both a workstation (mains only) and a laptop (internal battery, mains adapter) Kernel 3.10.0-327.36.1.el7.x86_64 -- all yumex update recommended RPMs were installed. HP Zbook Both MATE PowerManager 1.14.0 and GKrellM 2.3.5 report no mains adapter and 83 percent remaining in the battery for 10 hours 30 minutes -- this started after the above update. The amount of battery time is very far off -- it really should be about 2 hours. Has anyone else experienced this? Is there a fix/workaround? Yasha Karant
Production current mozilla firefox issue
We use current production (not beta / pre-release) releases of x86-64 Linux Mozilla Firefox (as well as Mozilla Thunderbird), not the distro ESR version. There are a number of reasons for this that can be discussed under separate cover. The environment is SL7x. Firefox often (almost always) fails to open, with the diagnostic: [ykarant@localhost ~]$ /usr/lib64/firefox/firefox XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so: libmozgtk.so: cannot open shared object file: No such file or directory Couldn't load XPCOM. A simple script "fixes" the problem. I keep the run directory /usr/lib64/firefox that has the installed compressed tarball files duplicated in /usr/lib/firefox-current , and then as root superuser rm -rf the run directory followed by a directory copy of the duplicate directory into a new copy of the run directory. Does anyone know what causes current standard production firefox from "destroying" /usr/lib64/firefox/libxul.so ? Yasha Karant
Linux mint
I fully understand that this is an EL list. The laptop of a retired colleague failed. On that laptop, I had installed SL pre 7 because the machine was not adequately provisioned for 64 bit operation. A mutual friend donated to this colleague a Lenovo ThinkPad R400 series (in much better physical condition than her failed laptop); he is a computer enthusiast enduser with no computer science or professional IT background. The machine has Mint on it. The colleague did not like the default Mint desktop -- I have installed Mate that is similar to what she is accustomed. Is there anyone on this list who has to maintain or use a Mint environment? (I understand that Mint is a Debian/Ubuntu family Linux.) If so, a private response would be most appreciated. I have joined the Mint Forums (sic) but much of the discussion there seems more what I expect from enthusiasts/end-users, not professionals. At some time in the future, I may transition the machine to SL 7, but she cannot afford the downtime now and thus will continue with Mint. She needs particular versions of MS Office applications, and thus I have configured both CrossOver (commercial, supported, Wine) as well as VirtualBox -- however, she uses Linux Thunderbird (IMAP) for email and Linux Firefox as her default web browser, not a MS environment or application. Yasha Karant
"spinning" application startup MATE
This query may belong on some MATE list, but I cannot find one. On my office SL 7 with MATE, when I click on a GUI application, as it is loading, the GUI arrow becomes a spinning dots-within-circle. On my nominally same environment on my laptop, it does not, and there is no "starting" indicator until the application actually appears on the GUI. How/where does one configure this? Yasha Karant <>
some further observations on the 7.1 to 7.2 pseudo-upgrade
Although I have not found the smoking gun that caused the 7.1 system to hang after a partial (hung) upgrade of an application RPM. However, I have found the item that was being upgraded: darktable from EPEL . Evidently, the latest darktable required other components. A second observation. I use the Mozilla suite from current stable production (not SL ESR) release, including Firefox, Thunderbird, and Seamonkey (the latter for the HTML editor integrated into the browser -- but I do not use Seamonkey email). When the upgrade created a new /home, not reusing the previous /home that was preserved untouched, the upgrade automagic install of firefox (ESR, of course) created a .mozilla in my new home directory. Originally, I left that untouched but did a ln -s from my oldhome .thunderbird to my new home. This created instabilities. I solved this by: 1 in my new home directory with none of firefox, thunderbird, or seamonkey "open", I did mv .mozilla to dotmozilla and then a mv of both .mozilla and .thunderbird from my old home to my new home . Things seem to be working. Do understand that I do not manually modify any of these dot files; all were created and manipulated by the various releases (none beta, all production) of the Mozilla suite components that I use. What I observed could be artifacts of the way the Mozilla suite maintains these files, or it could be due to some of the configuration being kept by Mozilla in one file and some in the other, requiring both to be mutually consistent. This is just a word of caution. I have not studied the current source code for the Mozilla suite and thus do not know the answer, only my empirical observations. The subject includes "pseudo-upgrade" because what the 7.2 upgrade seems to require is a re-install, at least if something gets "broken" as it happened in my 7.1 . Yasha Karant
libav-tools
I need for SL7 the equivalents to: |sudo apt-get install -y libav-tools ubuntu-restricted-extras| |sudo apt-get install -y libavcodec-extra-54 libavformat-extra-54| |to provide libav4 for a Mozilla Firefox extension (|Video DownloadHelper) Thus far, yumex has not found these nor does a search on the web. Any suggestions (including aURL for a downloable RPM or set thereof) would be most appreciated. Yasha Karant
ELRepo Kernel Repository
There being so many repositories with "sub-repositories" that I do not keep track of many; however, yumex reveals many of these. For ELRepo, there is an EL7 community kernel repository. Is anyone using this for production machines (presumably, yes)? If so, how do these differ from the "stock" SL (CentOS, RHEL, ...) kernels? If one uses an ELRepo kernel, and one then does a minor release upgrade of SL (assuming yum upgrade or something similar actually works, not requiring smashing the system partitions), will the ELRepo kernel "parts" play nicely with such a SL upgrade, or are there conflicts resulting in either no-boot (system failure) or instabilities? For "new" laptops/tablets that do not have the necessary drivers in stock SL, does the ELRepo kernel repository provide additional current drivers (as might be present in Ubuntu or even fully enthusiast, not enterprise production, Linux distros)? Yasha Karant
Re: SL 7.2 issues
On 07/28/2016 02:57 PM, Lamar Owen wrote: On 07/28/2016 01:44 PM, Yasha Karant wrote: I was updating an application on my SL7.1 laptop workstation, not using a terminal screen yum but the GUI interface that automagically appears after "clicking" on the downloaded RPM in the web browser download window. Unfortunately, the ISP network failed during the update (that evidently downloaded other RPMs required). The update did not appear to be re-entrant recoverable. ... yum-complete-transaction may have saved you a whole lot of work. It's in the 'yum-utils' package and it attempts to re-enter and complete the yum transaction. The yum database is semi-atomic and has a transactional characteristic. Yum and the GUI updaters are all supposed to download everything before updating anything, but depending upon exactly which RPM installer you were using it may have behaved differently. I did try that from a scrolling screen, but to no avail -- something may have broken yum for all I know. I did look at the logs in /var but found no smoking gun(s). There were suggested hints displayed by yum when I invoked it on the scrolling screen (the GUI had been absolutely silent -- just an activity indicator that halted momentarily then continued ad naseum that made me suspicious something was amiss -- and only after GUI failure did I continue with the scrolling screen method -- a different F key screen than the one with Xwindows). The 802.11 connection was not lost, but DNS, etc., was -- a web browser could not get out. It is possible that one of the automagic updates needed to satisfy the update of the package upon which I was updating pulled in some network utility/resource update and that froze the Internet Protocol Suite stack -- but the 802.11 MAC was fine. It definitely smashed Xwindows. What I found most annoying was with the SL7.2 ISO 4 Gbyte installation DVD in the drive, yum upgrade did find it and did claim to succeed -- but the machine would not boot. Only a fresh install smashing (formatting) the boot, /, /usr, and swap partitions allowed it to complete and boot. Also, the fact that the current 7.2 MATE evidently has issues with a home directory that worked with a 7.1 MATE (7.2 current MATE caja failed) was not pleasing; I still have the previous home directory and can attempt to find which . file(s) contained the offending configuration(s). In any event, I do now have a working 7.2 laptop and am not looking forward to 7.3 unless the yum upgrade path works, or the GUI booted installer also has an update "button" that will not smash any existing directories (except for swap that only has ephemeral data/files as I understand things). I understand that 8 will be a fresh install of all of the systems partitions. A question: does yumex (that is working and installed on this system) allow for easy control of which "installed" repositories are used? A second question: if I want to go from "old" partitions to LVM layouts, do I need two LVM "parts" on a drive so that /home /usr/local /opt and the like do not have to be smashed upon a full install? At some point I shall need to install a hard drive and use LVM rather than the "old" partition scheme. Yasha Karant
Re: SL 7.2 issues
On 07/28/2016 11:33 AM, John Pilkington wrote: On 28/07/16 18:44, Yasha Karant wrote: Several observations, questions -- all pertaining to SL 7.2 / mate (if a KDE, etc., application/interface works under mate, such qualify as "mate"). Q1 I previously had gpk-application as the primary software GUI installer. This has been replaced by gnome-software that appears quite different. Q1.1 Is there a GUI application that will list all installed RPMs (obviously, this does not work for packages installed/built other than through the RPM methodology)? Q1.2 Is there a GUI means to select software sources (repositories) to enable/disable these at will? Q1.3 Other than a web search for an application RPM followed by the command line yum install, is there a GUI application other than gnome-software to list all available applications from all selected/installed repositories? Q2 How does yumex work in 7.2 -- the same as in 7 previous? For me, with a single-box, single-HD 7.2 KDE plasma installation, it does Q1.1, Q1.2, Q1.3 competently with a slower but much friendlier response than the command-line; but you will probably need to have that in reserve. What is the name (file name and RPM) of the KDE application that you are using? Presumably, if I login using KDE Plasma, I would find this (I also specify SL to install KDE) and could track down the actual name of the file (via ps axw in any event). Mate runs KDE applications (as did and presumably does gnome). I use k3b as my preferred CD/DVD burning application now that Nero Linux does no longer seem to work under SL (stopped with the upgrade to SL 7). There are other small glitches and changes, but nothing severe for the nonce.
SL 7.2 issues
I was updating an application on my SL7.1 laptop workstation, not using a terminal screen yum but the GUI interface that automagically appears after "clicking" on the downloaded RPM in the web browser download window. Unfortunately, the ISP network failed during the update (that evidently downloaded other RPMs required). The update did not appear to be re-entrant recoverable. The system was left in a state whereby the entire Xwindows system failed (a terminal screen on other F keys did work), and there was no easy rollback method. I then used the SL 7.2 ISO DVD via a terminal screen in yum upgrade (a switch/qualifier to yum); the "upgraded" system would not boot. I finally did a fresh install of SL 7.2 via booting from the SL 7.2 ISO DVD, having to reformat / , /usr , /boot, swap, but saving /home, /opt, and /usr/local as I am using "conventional" partitions (the machine only has a 1 Tbyte drive) with XFS format. (I have left the EXT series and now exclusively use XFS on all new installations. XFS appears to be mature and stable.) Has anyone done the above (or portions thereof) with RHEL 7.2 or CentOS 7.2, and if so, are there any differences? Several observations (recall: this a minor release update -- 7.1 to 7.2; also, the mv scenarios explained below would require a detailed algorithmic or equivalent diagram to be precise -- I have not done this here to save space): 1. During the install, I was required to enter a new root password and create a user account (mine) to which I granted admin privileges under the GUI installer (this evidently makes me a sudo-er). 1.1 The installer created a new /home under the / partition, and renamed the old /home to /hiome . 1.2 After installing the ELRepo and EPEL repository files, I did the yum package install of mate (the window manager system I prefer). 1.4 As root, I exchanged (via a set of mv commands, not a simple mv) the old /home and the newly created /home . 1.5 After a restart, now logged into my old /home, I discovered that the current mate did not work, with symptoms I had seen before (a failure of caja). Call my home directory (account) on SL 7.1 foo . I then did a mv foo oldfoo on /home (the old home, a real partition, not the /home created by the install, merely a directory under / but residing in the / partition). From the /home created by the installer (and now renamed /hiome), I moved that foo to foo under the real /home. Mate now worked. On the first run, my desktop did not correctly appear (missing icons/entries). Upon one more full reboot, my old desktop appeared (many links broken that required re-installation into 7.2) but not in the same layout as before (the apparent arrangement of the icon upon the desktop screen display). I have now reinstalled most of these. Several observations, questions -- all pertaining to SL 7.2 / mate (if a KDE, etc., application/interface works under mate, such qualify as "mate"). Q1 I previously had gpk-application as the primary software GUI installer. This has been replaced by gnome-software that appears quite different. Q1.1 Is there a GUI application that will list all installed RPMs (obviously, this does not work for packages installed/built other than through the RPM methodology)? Q1.2 Is there a GUI means to select software sources (repositories) to enable/disable these at will? Q1.3 Other than a web search for an application RPM followed by the command line yum install, is there a GUI application other than gnome-software to list all available applications from all selected/installed repositories? Q2 How does yumex work in 7.2 -- the same as in 7 previous? There are other small glitches and changes, but nothing severe for the nonce.
SL7 on a tablet
My wife has been elected Chair of the Faculty Senate at our university. As such, the Administration is willing to buy her an Apple iPad or equivalent. My understanding is that the iPad platform will not run any Linux environment, and she does not want to "relearn" everything. That is, she wants Mozilla Firefox, Google Chrome, Mozilla Thunderbird, MATE (or a close equivalent), LibreOffice, galculator, etc. My understanding also is that non-Apple tablets will run Linux and thus should support the environment to which she is accustomed. Are there any tablets in the Apple iPad price range that run SL 7? If not SL 7, other distros (say, Ubuntu "enterprise")? Would such tablets also run VirtualBox or VMWare Player to allow the use of MS Win as a guest environment? How much RAM and mass storage should be procured? The unit would need both USB ports as well as 802.11 support (supported drivers under Linux for Network Manager, her WLAN application of choice). Any recommendations or observations would be appreciated. Yasha Karant
Re: Need specific LaTeX utiliities for EL7
On 06/15/2016 12:32 AM, Andrew C Aitchison wrote: On Tue, 14 Jun 2016, Yasha Karant wrote: WYSIWYG (not LyX that produces LaTeX but internally is not LaTeX)? Thus far, I have not found such a WYSIWYG. EPEL includs Kile http://kile.sourceforge.net/ (possibly an abbreviation of KDE Integrated LaTeX Environment). I have Kile, LyX, Texstudio, etc., and cannot afford BaKoMaTeX . However, that was not the primary thrust of my enquiry. I am looking for specific LaTeX utilities in a SL7 or compatible port (RPM preferred, but LaTeX "automagic" utility installation methods will suffice), the list being: XeLaTeX Biber Texindy Makeglossaries Asymptote Any assistance would be appreciated. Yasha Karant
Need specific LaTeX utiliities for EL7
I am looking for EL & RPMs of specific LaTeX utilities compatible with the TeX/LaTeX base/packages installed from the SL7 install DVD: XeLaTeX Biber Texindy Makeglossaries Asymptote I have found these as installable images for other distros, including some Fedora. If these packages are available by some other mechanism such that the SL7 Latex system can download, compile, insert, etc., any of these, advice and instructions would be most appreciated. As a fast LaTeX GUI front end, I use Texstudio that has a X86-64 CentOS 7 RPM available at the Texstudio Sourceforge site and that installs and runs fine under SL 7. The only WYSIWYG I have found is BaKoMaTeX that is licensed for fee (with actual pricing in Euros). Is there any licensed-for-free LaTeX WYSIWYG (not LyX that produces LaTeX but internally is not LaTeX)? Thus far, I have not found such a WYSIWYG. Yasha Karant <>
Re: Scientific linux 6.7 to 7.x
If you have kept home directories and custom non-standard-distros applications and support files on other than the system partitions (or the equivalent if you are using a disk with too much capacity to use the older partition methods), e.g., /home, /opt, /usr/local, and the like, then simply use the install media to install into typical systems partitions (e.g., /usr , /boot , ... ) and you will be operational. If you are statically configuring the NIC/WNIC and Internat access configuration files (e.g., the actual IPv4, IPv6 address configuration information for the NIC/s, etc.), then simply installing into the other partitions as required should result in a working system. Note that I use gparted to convert the overwritten partitions to a "newer" format (such as XFS), Upon reboot, all of the older applications and previous home directories should be present. Note also that if the older applications require specific .so files or utilities (older loader, etc.), these must be obtained and installed . Yasha Karant On 05/12/2016 01:19 PM, John Black wrote: Is there away to upgrade with yum form SL 6x to SL 7x? Thank you John
bosh, cloud foundry, predix
General Electric corporation has a "cloud" environment called Pedix that is a derivative of Cloud Foundy and that is obtained via Bosh. Does anyone have experience with any of these on SL7? Yasha Karant
Re: Back to SL
Dhivan, Because of a colleague who insisted that we switch from EL to SuSE, we licensed SLES and I installed OpenSUSE on my laptop -- but left SL on my workstation. SUSE never in fact provided us with SLES (although we paid the license) and OpenSUSE simply was not as reliable as SL. For example, I prefer Mate over current Gnome or current KDE. Mate never worked on OpenSUSE, and I could get no support for it. Likewise, I was having significant difficulty with VirtualBox on OpenSUSE. The major fault seemed to be that there is no OpenSUSE equivalent to this SL Users list to which one ask "technical" questions and get either direct answers or confirmation that there is an issue that needs to be addressed, or for workarounds (application X does not work, but application W has essentially the same functionality and does work). Also, having compared RPM and yum with the SuSE similar functionality, yum seems easier to use and more predictable -- although I am certain that those in the SuSE camp (using "patterns" if I recall the SuSE terminology) would have just the opposite opinion. I had used CentOS before switching to SL. The initial primary reason I switched to SL is that SL, once it become a superset of EL, not a non-conforming port, is that SL is professionally developed and supported by staff at Fermilab and CERN -- these are paid professionals, not "volunteers" -- although it appears SL 7 strictly is ported by Fermilab staff. The other alternative is the Princeton / Institute for Advanced Study port, but SL seems more stable, more rapidly deployed, and this list -- from which one can get meaningful technical advice -- is a big plus. Yasha On 12/30/2015 11:04 PM, Dhivan Djaganu wrote: Yasha, How is the move back going for you? Are you happy? I am asking for an update, if possible, as I am at crossroads myself.. What is the main attraction for you over the CentOS, please? Thank you in advance and Happy New Years!
Re: grace (xmgrace) on SL 7 [2]
On 11/30/2015 01:04 PM, Arthur H. Edwards wrote: is there a repository with grace (xmgrace) for SL 7? Thanks, Art Edwards Detailed information below as for the build of xmgrace that I have. ls -la grace.tgz -rw-r--r--. 1 root root 2255749 Dec 1 15:19 grace.tgz bash-4.2$ tar -tvzf grace.tgz drwxr-xr-x root/root 0 2015-10-14 22:31 grace/ drwxr-xr-x root/root 0 2015-10-14 22:31 grace/bin/ -rwxr-xr-x root/root 1263960 2015-10-14 22:31 grace/bin/xmgrace lrwxrwxrwx root/root 0 2015-10-14 22:31 grace/bin/gracebat -> xmgrace -rwxr-xr-x root/root 56504 2015-10-14 22:31 grace/bin/grconvert -rwxr-xr-x root/root 22808 2015-10-14 22:31 grace/bin/convcal -rwxr-xr-x root/root 3014 2015-10-14 22:31 grace/bin/fdf2fit drwxr-xr-x root/root 0 2015-10-14 22:31 grace/lib/ -rw-r--r-- root/root 16998 2015-10-14 22:31 grace/lib/libgrace_np.a drwxr-xr-x root/root 0 2015-10-14 22:31 grace/include/ -rw-r--r-- root/root 2107 2015-10-14 22:31 grace/include/grace_np.h drwxr-xr-x root/root 0 2015-10-14 22:31 grace/fonts/ -rw-r--r-- root/root 857 2015-10-14 22:31 grace/fonts/FontDataBase drwxr-xr-x root/root 0 2015-10-14 22:31 grace/fonts/type1/ -rw-r--r-- root/root 46026 2015-10-14 22:31 grace/fonts/type1/n021003l.pfb -rw-r--r-- root/root 45458 2015-10-14 22:31 grace/fonts/type1/n021023l.pfb -rw-r--r-- root/root 44729 2015-10-14 22:31 grace/fonts/type1/n021004l.pfb -rw-r--r-- root/root 44656 2015-10-14 22:31 grace/fonts/type1/n021024l.pfb -rw-r--r-- root/root 36026 2015-10-14 22:31 grace/fonts/type1/n019003l.pfb -rw-r--r-- root/root 38314 2015-10-14 22:31 grace/fonts/type1/n019023l.pfb -rw-r--r-- root/root 35941 2015-10-14 22:31 grace/fonts/type1/n019004l.pfb -rw-r--r-- root/root 39013 2015-10-14 22:31 grace/fonts/type1/n019024l.pfb -rw-r--r-- root/root 45758 2015-10-14 22:31 grace/fonts/type1/n022003l.pfb -rw-r--r-- root/root 44404 2015-10-14 22:31 grace/fonts/type1/n022023l.pfb -rw-r--r-- root/root 50493 2015-10-14 22:31 grace/fonts/type1/n022004l.pfb -rw-r--r-- root/root 51527 2015-10-14 22:31 grace/fonts/type1/n022024l.pfb -rw-r--r-- root/root 45955 2015-10-14 22:31 grace/fonts/type1/d05l.pfb -rw-r--r-- root/root 33709 2015-10-14 22:31 grace/fonts/type1/s05l.pfb -rw-r--r-- root/root 9381 2015-10-14 22:31 grace/fonts/type1/d05l.afm -rw-r--r-- root/root 31763 2015-10-14 22:31 grace/fonts/type1/n019003l.afm -rw-r--r-- root/root 31595 2015-10-14 22:31 grace/fonts/type1/n019004l.afm -rw-r--r-- root/root 32114 2015-10-14 22:31 grace/fonts/type1/n019023l.afm -rw-r--r-- root/root 31901 2015-10-14 22:31 grace/fonts/type1/n019024l.afm -rw-r--r-- root/root 31943 2015-10-14 22:31 grace/fonts/type1/n021003l.afm -rw-r--r-- root/root 31889 2015-10-14 22:31 grace/fonts/type1/n021004l.afm -rw-r--r-- root/root 31920 2015-10-14 22:31 grace/fonts/type1/n021023l.afm -rw-r--r-- root/root 31926 2015-10-14 22:31 grace/fonts/type1/n022003l.afm -rw-r--r-- root/root 32136 2015-10-14 22:31 grace/fonts/type1/n022023l.afm -rw-r--r-- root/root 31779 2015-10-14 22:31 grace/fonts/type1/n022004l.afm -rw-r--r-- root/root 31961 2015-10-14 22:31 grace/fonts/type1/n022024l.afm -rw-r--r-- root/root 32028 2015-10-14 22:31 grace/fonts/type1/n021024l.afm -rw-r--r-- root/root 9686 2015-10-14 22:31 grace/fonts/type1/s05l.afm drwxr-xr-x root/root 0 2015-10-14 22:31 grace/fonts/enc/ -rw-r--r-- root/root 12617 2015-10-14 22:31 grace/fonts/enc/IsoLatin1.enc -rw-r--r-- root/root 14519 2015-10-14 22:31 grace/fonts/enc/IsoLatin2.enc -rw-r--r-- root/root 13993 2015-10-14 22:31 grace/fonts/enc/IsoLatin5.enc -rw-r--r-- root/root 12223 2015-10-14 22:31 grace/fonts/enc/IsoLatin7.enc -rw-r--r-- root/root 12444 2015-10-14 22:31 grace/fonts/enc/IsoLatin9.enc -rw-r--r-- root/root 12436 2015-10-14 22:31 grace/fonts/enc/PSLatin1.enc -rw-r--r-- root/root 12327 2015-10-14 22:31 grace/fonts/enc/PDFDoc.enc -rw-r--r-- root/root 12357 2015-10-14 22:31 grace/fonts/enc/WinAnsi.enc -rw-r--r-- root/root 12249 2015-10-14 22:31 grace/fonts/enc/MacRoman.enc -rw-r--r-- root/root 1998 2015-10-14 22:31 grace/fonts/enc/CP1251.enc -rw-r--r-- root/root 1934 2015-10-14 22:31 grace/fonts/enc/KOI8-R.enc -rw-r--r-- root/root 1942 2015-10-14 22:31 grace/fonts/enc/KOI8-U.enc drwxr-xr-x root/root 0 2015-10-14 22:31 grace/templates/ -rw-r--r-- root/root 6740 2015-10-14 22:31 grace/templates/Default.agr drwxr-xr-x root/root 0 2015-10-14 22:31 grace/doc/ -rw-r--r-- root/root 69997 2015-10-14 22:31 grace/doc/CHANGES.html -rw-r--r-- root/root 19795 2015-10-14 22:31 grace/doc/GPL.html -rw-r--r-- root/root 6123 2015-10-14 22:31 grace/doc/philosophical-gnu-sm.jpg -rw-r--r-- root/root 150 2015-10-14 22:31 grace/doc/nohelp.html -rw-r--r-- root/root 67001 2015-10-14
Re: grace (xmgrace) on SL 7
I do not know -- but I believe that I have a working grace, including xmgrace, for SL 7 on X86-64. I can package it as a tar.gz if there is a way to get it to you. To the best of my understanding, the machines upon which it is running are infection-free and grace is stock. It is on my laptop and that is not on right now. Yasha Karant On 11/30/2015 01:04 PM, Arthur H. Edwards wrote: is there a repository with grace (xmgrace) for SL 7? Thanks, Art Edwards <>
Re: VMware
Hi Vladimir, The physical 802.11 WNIC is IP configured by DHCP from the ISP. Does this require DHCP "trickery" to transfer this information to the virtual 802.3 NIC under VirtualBox that is supplied to the MS Win guest? Yasha Karant On 10/30/2015 08:27 AM, Vladimir Mosgalin wrote: Hi Yasha Karant! On 2015.10.29 at 13:28:21 -0700, Yasha Karant wrote next: You seem to display a bridge between an 802.3 (eth) and an 802.11 (wnic). Right. Note that I only did that for purposes of software AP. This is router which provides both wired and wireless network connectivity, which are bridged for network uniformity (no routing, broadcast and multicast passing, no dhcp forwarding trickery and so on). I can show you configuration but it doesn't mean that it would work for you with wireless NIC not in AP mode. That said, if THIS way won't work for you, it doesn't mean it's impossible at all: try Open vSwitch! It is much more agile compared to standard linux bridging, especially in areas related to bridging between multiple interfaces created on the fly, VLANs and such, making it very useful on virtualization hosts. In any event, a copy (typescript, screenshots, etc.) of the actual commands you used, any needed configuration files, and a copy of any outputs produced during the activation/configuration greatly would be appreciated. I set up bridge in NM with nmtui. You can find guides on setting it up with NM GUI / nmcli combo, e.g. https://www.happyassassin.net/2014/07/23/bridged-networking-for-libvirt-with-networkmanager-2014-fedora-21/ https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Network_Bridging_Using_the_NetworkManager_Command_Line_Tool_nmcli.html NM creates bridge0 and adds eth0 to it, sets up IPs and such after that. Wireless device wlan0 is set up much later, and hostapd adds wlan0 to that bridge after it finishes configuring wireless lan. It's impossible to add uncofigured wlan0 device to bridge. Either way, the resulting configuration files look like $ cat /etc/sysconfig/network-scripts/ifcfg-bridge0 DEVICE=bridge0 STP=no TYPE=Bridge BOOTPROTO=none DNS1=127.0.0.1 DOMAIN=asgard DEFROUTE=no IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=no IPV6ADDR= IPV6_DEFROUTE=no IPV6_FAILURE_FATAL=no NAME=bridge0 UUID=c10629d4-3fc8-4987-98d2-b82799419e49 ONBOOT=yes IPADDR=192.168.2.1 PREFIX=24 $ cat /etc/sysconfig/network-scripts/ifcfg-bridge0_eth0 TYPE=Ethernet NAME=bridge0_eth0 UUID=a3810633-5171-4946-9e60-f3a09bd7f4e7 DEVICE=eth0 ONBOOT=yes BRIDGE=c10629d4-3fc8-4987-98d2-b82799419e49 I won't publish the whole hostapd.conf file, related lines are interface=wlan0 bridge=bridge0 As for the log file, here are the lines related to eth0/wlan0/bridge0 initialization: http://pastebin.com/zVjfcqBj
