Re: SL6 end of life
On Tue, Sep 10, 2019 at 2:58 PM David Sommerseth wrote: > > On 06/09/2019 05:02, Nico Kadel-Garcia wrote: > > On Thu, Sep 5, 2019 at 12:33 PM Jon Pruente > > wrote: > >> > >> On Thu, Sep 5, 2019 at 9:47 AM Larry Linder > >> wrote: > >>> > >>> It is interesting that there is a new "yum" as an RPM but do you need to > >>> install it to install the rest of the .rpm packages on the RHEL 8. RPM > >>> pile. > >>> This looks like the chicken / egg problem or can you install the RHEL > >>> rpms with the old yum? > >>> > >>> I have to admit that I did not read the fine print. > >> > >> > >> It's a newer package manager called dnf, not a new packaging format. dnf > >> was introduced in Fedora 18 in 2013, so over six years. It was made the > >> full replacement in Fedora 22. You can still call the yum command, it's > >> just a symlink to dnf. No worries. > >> > >> https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_DNF-3Frd-3DDnf=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=A5w_4HZYVV8wdM-CIyuTqojig2pf2OQLcPYEBVhfh-0=o0mKeNq2vLkettxtsh9-B5Q5OnQWA8YExrDIMTSvbW4= > >> > >> On a RHEL 8 VM: > >> $ which yum > >> /usr/bin/yum > >> $ ls -l /usr/bin/yum > >> lrwxrwxrwx. 1 root root 5 Oct 15 2018 /usr/bin/yum -> dnf-3 > > > > dns if not my friend. It includes "Suggests" and "Recommends" for > > other packages, which I personally think is really destabilizing and > > not backwards compatible. Fedora 32, way upstream, uses a distinct > > "zstd" compression format which is not backwards compatible, so taking > > apart the SRPM packages for backports is going to require chicanery. > > even on CentOS 8. > > I remember similar complaints back in the days when Fedora moved away from MD5 > to SHA256, which broke RPMs which was built on RHEL-6 or newer Fedoras and was > attempted installed on RHEL-5. It didn't take too long before rpmbuild-md5 > was discovered which resolved this issue. > > Don't you think a similar utility will appear, or a RPM macro can be defined > to use the older compression? I don't know about anything right now, but this > cross building will be crucial for quite some users so I kinda expect this to > be a known issue. It's been mentioned on the fedora-devel mailing list (by me, for one). My concern is that it's going to take time, it's not going to brought back into the core RPM toolkit for some time, especially since the "rpm" tools themselves are migrating with RHEL 8 into a stabilized channel called "baseos". We;ll have to see how this gets handled.
Re: Transaction check error vulkan-1.1.97.0-1 conflicts spirv-tools-libs-2019.1-1
On 9/10/19 2:41 AM, Francesco Alfano wrote: I ran the yum update command, and I have the following Transaction check error: file /usr/lib64/libSPIRV-Tools-opt.so from install of vulkan-1.1.97.0-1.el7.x86_64 conflicts with file from package spirv-tools-libs-2019.1-1.el7.x86_64 file /usr/lib64/libSPIRV-Tools.so from install of vulkan-1.1.97.0-1.el7.x86_64 conflicts with file from package spirv-tools-libs-2019.1-1.el7.x86_64 how can I fix them? There is no resolution yet, but there is a bug for it: https://bugzilla.redhat.com/show_bug.cgi?id=1745104 -- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 https://www.nwra.com/ smime.p7s Description: S/MIME Cryptographic Signature
Re: SL6 end of life
On 06/09/2019 05:02, Nico Kadel-Garcia wrote: > On Thu, Sep 5, 2019 at 12:33 PM Jon Pruente > wrote: >> >> On Thu, Sep 5, 2019 at 9:47 AM Larry Linder >> wrote: >>> >>> It is interesting that there is a new "yum" as an RPM but do you need to >>> install it to install the rest of the .rpm packages on the RHEL 8. RPM >>> pile. >>> This looks like the chicken / egg problem or can you install the RHEL >>> rpms with the old yum? >>> >>> I have to admit that I did not read the fine print. >> >> >> It's a newer package manager called dnf, not a new packaging format. dnf was >> introduced in Fedora 18 in 2013, so over six years. It was made the full >> replacement in Fedora 22. You can still call the yum command, it's just a >> symlink to dnf. No worries. >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_DNF-3Frd-3DDnf=DwIBaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=A5w_4HZYVV8wdM-CIyuTqojig2pf2OQLcPYEBVhfh-0=o0mKeNq2vLkettxtsh9-B5Q5OnQWA8YExrDIMTSvbW4= >> >> >> On a RHEL 8 VM: >> $ which yum >> /usr/bin/yum >> $ ls -l /usr/bin/yum >> lrwxrwxrwx. 1 root root 5 Oct 15 2018 /usr/bin/yum -> dnf-3 > > dns if not my friend. It includes "Suggests" and "Recommends" for > other packages, which I personally think is really destabilizing and > not backwards compatible. Fedora 32, way upstream, uses a distinct > "zstd" compression format which is not backwards compatible, so taking > apart the SRPM packages for backports is going to require chicanery. > even on CentOS 8. I remember similar complaints back in the days when Fedora moved away from MD5 to SHA256, which broke RPMs which was built on RHEL-6 or newer Fedoras and was attempted installed on RHEL-5. It didn't take too long before rpmbuild-md5 was discovered which resolved this issue. Don't you think a similar utility will appear, or a RPM macro can be defined to use the older compression? I don't know about anything right now, but this cross building will be crucial for quite some users so I kinda expect this to be a known issue. -- kind regards, David Sommerseth
Transaction check error vulkan-1.1.97.0-1 conflicts spirv-tools-libs-2019.1-1
I ran the yum update command, and I have the following Transaction check error: file /usr/lib64/libSPIRV-Tools-opt.so from install of vulkan-1.1.97.0-1.el7.x86_64 conflicts with file from package spirv-tools-libs-2019.1-1.el7.x86_64 file /usr/lib64/libSPIRV-Tools.so from install of vulkan-1.1.97.0-1.el7.x86_64 conflicts with file from package spirv-tools-libs-2019.1-1.el7.x86_64 how can I fix them? -- -- Best Regards Francesco Alfano System Engineer
Re: ImageMagick convert no longer works
On 10/09/2019 2:15 pm, Bill Maidment wrote: After the updates from SL7.6 to SL7.7 I found that the convert function in ImageMagick no longer works with the error: convert: unable to read font `/usr/share/ghostscript/fonts/n019003l.pfb' @ error/annotate.c/RenderFreetype/1124. It seems there is some mismatch between ImageMagick and ghostcript. Anyone else seen this and/or have a solution? Googling only muddies the issue for me. I've found a work around as follows: yum install urw-base35-fonts-legacy ln -s /usr/share/X11/fonts/urw-fonts /usr/share/ghostscript/fonts -- Cheers Bill
