I’ve even found the DHCP/static issue to be impossible. I have 5 static lines
here but as of last week (and actually several months ago) I’ve been unable to
configure static addresses on the CentOS 8 machine. CentOS 8 requires
NetworkManager and that reverts to DHCP no matter which NIC configuration I
use. Dry sloppy work on their part.
Michael Allen
Industrial Weather
763-777-1263
On Sat, Dec 19, 2020 at 10:59 AM, Micha Silver <[email protected]> wrote:
> On 12/19/20 6:38 PM, mdwxman via grass-user wrote:
>
>> I’m starting to agree with you regarding Centos 8. This experience matches
>> other experiences with it. Although I like it’s interface there seems to be
>> serious, nefarious hidden issues when I start to compile code. I understand
>> why it ‘s been abandoned, although I have no research to add to my
>> suppositions.
>>
>> If old habits die hard those old habits can still have disastrous
>> consequences. Today is the day to adopt Ubuntu & stop wasting my time &
>> yours. I wonder how many others on this user group use CentOS 7 or 8? Not
>> many I’d guess.
>
> Like you I also used CentOS for years, but left several years back for the
> Debian family. I've been quite happy since.
>
> CentOS is still a good choice, I think, if you need a server for just a few
> standard, unchanging services (DHCP, web server, mail server etc). But for
> desktop work, with rapidly changing software, you quickly find yourself
> chasing after packages that aren't available from the standard repos.
>
>> Michael Allen
>> Industrial Weather
>> 763-777-1263
>>
>> On Sat, Dec 19, 2020 at 5:53 AM, Markus Neteler <[email protected]> wrote:
>>
>>> On Sat, Dec 19, 2020 at 3:27 AM mdwxman via grass-user
>>> [<[email protected]>](mailto:[email protected]) wrote:
>>>>
>>>> This has become a very strange issue. This afternoon I attempted 8
>>>> variations on the compilation and all failed.
>>>
>>> There should ideally be just one way to install it.
>>>
>>>> The first thing I did was to check on the GDAL version and although it
>>>> wasn't easy, it turns out that the conda installation from several weeks
>>>> ago used GDAL 2.4... The GRASS version was the 7.7 version. So, I changed
>>>> the subdirectory to the 3.0.4 GDAL version: /usr/include/gdal-config and
>>>> the /usr/share/gdal subdirectories. But those failed too although I used
>>>> the grass-7.8.5RC1 file.
>>>
>>> We need to see the error messages to help.
>>>
>>> In the first place I feel that you have a mixture of version on your
>>> machine. Personally, I would try without conda on Centos8.
>>>
>>>> I also checked my logs and made sure I used the dnf install text for all
>>>> the required software. I also tried the "--with-gdal
>>>> --with-gdal-includes=/usr/include/gdal" configuration. All my attempts
>>>> bombed.
>>>>
>>>> It was interesting that dnf install noted that GDAL and GDAL-devel were
>>>> the most recent and already on my file system. There are two additional
>>>> tasks to do now. The first is to discover whether the GDAL and GDAL-devel
>>>> version 3.0.4 version is the one to use for the compilation. Is it the
>>>> most up-to-date?
>>>
>>> Here you can look up the version:
>>> https://src.fedoraproject.org/rpms/gdal/
>>> --> d'oh! where did it go? Someone must have removed it from there ... :(
>>>
>>> ==> Build status
>>> --> https://koji.fedoraproject.org/koji/packageinfo?packageID=1826
>>> --> gdal-3.0.4-5.el8 (which I packaged in May)
>>>
>>> I have just triggered to rebuild it on the server:
>>>
>>> fedpkg build
>>> Building gdal-3.0.4-6.el8 for epel8-candidate
>>> Created task: 57788230
>>> Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57788230
>>> Building gdal-3.0.4-6.el8 for epel8-playground-candidate
>>> Created task: 57788232
>>> Task info: https://koji.fedoraproject.org/koji/taskinfo?taskID=57788232
>>>
>>> ==> it fails.
>>>
>>>> The other task is attempt to dig into other log files to determine if
>>>> there is additional information.
>>>>
>>>> After that I plan to remove all GRASS versions and related libraries if I
>>>> can find them. I know I have two GRASS versions: 7.7 and 7.8.5 so perhaps
>>>> there's a conflict hidden in the configuration.
>>>
>>> Is there any reason to keep the outdated GRASS 7.7?
>>>
>>>> My other question revolves around gdal-config. There are two versions of
>>>> gdal-config: one simply called "gdal-config" and the other called
>>>> "gdal-config64" This machine (and all my networked machines) are x86_64
>>>> architecture. Is the configure script attempting to use one or the other
>>>> and defaulting to the "Error: cannot find gdal-config" option. This type
>>>> of thing has happened to me before and error messages can be notoriously
>>>> difficult to understand.
>>>
>>> I fully agree. There is no (obvious) point for me to have a separate
>>> "gdal-config64" script.
>>> Please check from which RPM it originates, with
>>>
>>> rpm -qf /usr/bin/gdal-config64
>>> ?
>>>
>>> But honestly, I am getting lost with Centos. That's why we abandoned
>>> it earlier this year (which was an attempt after 10 years of
>>> Scientific Linux on our HPC infrastructure).
>>>
>>> However, I have good experience with Fedora and Ubuntu.
>>>
>>> Markus
>>
>> _______________________________________________
>> grass-user mailing list
>> [email protected]
>>
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
_______________________________________________
grass-user mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-user
