Having a sanctioned way to compile targeting a version of the kernel that is
installed — but not running — would be helpful in many circumstances.
—
Stephen
> On Jan 17, 2020, at 11:58 AM, Ryan Novosielski wrote:
>
> Yeah, support got back to me with a similar response earlier today that I’d
Yeah, support got back to me with a similar response earlier today that I’d not
seen yet that made it a lot clearer what I “did wrong". This would appear to be
the cause in my case:
[root@master config]# diff env.mcr env.mcr-1062.9.1
4,5c4,5
< #define LINUX_KERNEL_VERSION 31000999
< #define
Hi Ryan,
My interpretation of the analysis so far is that the content of LINUX_KERNEL_VERSION_VERBOSE in ' env.mcr' became incorrect. That is, it used to work well in a prior release of Scale, but not with 5.0.4.1 . This is because of a code change that added another digit to the version in
That /is/ interesting.
I’m a little confused about how that could be playing out in a case where I’m
building on -1062.9.1, building for -1062.9.1, and running on -1062.9.1. Is
there something inherent in the RPM building process that hasn’t caught up, or
am I misunderstanding that change’s
Hi Ryan,
Some interesting IBM-internal communication overnight. The problems seems related to a change made to LINUX_KERNEL_VERSION_VERBOSE to handle the additional digit in the kernel numbering (3.10.0-1000+) . The GPL layer expected LINUX_KERNEL_VERSION_VERBOSE to have that extra digit, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Felipe,
I either misunderstood support or convinced them to take further
action. It at first looked like they were suggesting "mmbuildgpl fixed
it: case closed" (I know they wanted to close the SalesForce case
anyway, which would prevent
Hi Ryan,
I'm aware of this ticket, and I understand that there has been active communication with the service team on this problem.
The crash itself, as you indicate, looks like a problem that has been fixed:
