Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1528828

Summary: libxsmm-1.8.3 is available
Product: [Fedora] Fedora Reporter: Upstream Release Monitoring <upstream-release-monitoring>
Component: libxsmmAssignee: Dave Love <dave.love>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dave.love, dominik
Target Milestone: ---Keywords: FutureFeature, Reopened, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libxsmm-1.8.3-1.fc28 libxsmm-1.8.3-1.fc27 libxsmm-1.8.3-2.fc28 libxsmm-1.8.3-2.fc27 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-15 02:33:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Upstream Release Monitoring 2017-12-24 12:18:49 UTC
Latest upstream release: 1.8.2
Current version/release in rawhide: 1.8.1-4.fc28
URL: https://github.com/hfp/libxsmm

Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.

Based on the information from anitya:  https://release-monitoring.org/project/12433/

Comment 1 Upstream Release Monitoring 2018-02-03 00:18:13 UTC
Latest upstream release: 1.8.3
Current version/release in rawhide: 1.8.1-4.fc28
URL: https://github.com/hfp/libxsmm

Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream.

Based on the information from anitya:  https://release-monitoring.org/project/12433/

Comment 2 Dominik 'Rathann' Mierzejewski 2018-02-07 14:15:14 UTC
Ping? Looks like it also needs a rebuild for the latest libgfortran SONAME bump. I'll send some PR if you don't beat me to it.

Comment 3 Dominik 'Rathann' Mierzejewski 2018-02-07 14:24:52 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #2)
> Ping? Looks like it also needs a rebuild for the latest libgfortran SONAME
> bump. I'll send some PR if you don't beat me to it.

It looks like there's a mass rebuild in progress that will take care of this.

Comment 4 Dave Love 2018-02-08 10:14:06 UTC
Is there some urgency for 1.8.3?  The build currently fails (differently) in rawhide and el7, and I don't know how much the ABI has changed.  I haven't steeled myself to investigate, or look at Pabst's info on testing.  Feel free if you have time.

Most of my stuff has been broken by the gfortran change, which I assumed isn't my job to fix.  I ought to complain about gfortran incompatibilities...

Comment 5 Dominik 'Rathann' Mierzejewski 2018-02-09 12:03:55 UTC
(In reply to Dave Love from comment #4)
> Is there some urgency for 1.8.3?

cp2k upstream (https://lists.cp2k.org/private/cp2k-dev/2018-February/000867.html) is recommending this version.

> The build currently fails (differently) in
> rawhide and el7, and I don't know how much the ABI has changed.  I haven't
> steeled myself to investigate, or look at Pabst's info on testing.  Feel
> free if you have time.

Ok. Scratch build succeeded: https://koji.fedoraproject.org/koji/taskinfo?taskID=24879464 .

Comment 6 Dave Love 2018-02-12 17:43:04 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #5)
> (https://lists.cp2k.org/private/cp2k-dev/2018-February/000867.html) is
> recommending this version.

I can't read that.  What is fixed in this version that's relevant to cp2k?  (I'm not objecting, just interested.)

> > The build currently fails (differently) in
> > rawhide and el7, and I don't know how much the ABI has changed.  I haven't
> > steeled myself to investigate, or look at Pabst's info on testing.  Feel
> > free if you have time.
> 
> Ok. Scratch build succeeded:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=24879464 .

Thanks.  I'm puzzled why it was failing for me before, but no matter.

Why change the BR to python3, which breaks in EPEL?  It works with either, and no python files are installed.  If Fedora is insisting, please conditionalize it.

The conditional for %check was temporary, and I think it just needs fixing.  I haven't had a chance to look at it again on the basis of https://github.com/hfp/libxsmm/issues/196

I find splitting up the BRs generally makes the spec harder to read by spreading it out when there are lots. Is it required?

We should perhaps see if it's possible to assume SSE4.2 for the Fedora package (though that won't run on Magny Cours here).

By the way, I've packaged a couple of other add-ons for cp2k in copr, if they're of any interest, but can't remember which off-hand.

Comment 7 Dominik 'Rathann' Mierzejewski 2018-02-15 10:19:53 UTC
(In reply to Dave Love from comment #6)
> (In reply to Dominik 'Rathann' Mierzejewski from comment #5)
> > (https://lists.cp2k.org/private/cp2k-dev/2018-February/000867.html) is
> > recommending this version.
> 
> I can't read that.  What is fixed in this version that's relevant to cp2k? 
> (I'm not objecting, just interested.)

Quoting Hans Pabst:
[...] Please note, somewhere post-1.7.1 an issue was exposed/present
when using CP2K/smp. This is resolved since the previous v1.8.2 release (also thanks to Andreas' reproducer). [...]

> > > The build currently fails (differently) in
> > > rawhide and el7, and I don't know how much the ABI has changed.  I haven't
> > > steeled myself to investigate, or look at Pabst's info on testing.  Feel
> > > free if you have time.
> > 
> > Ok. Scratch build succeeded:
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=24879464 .
> 
> Thanks.  I'm puzzled why it was failing for me before, but no matter.
> 
> Why change the BR to python3, which breaks in EPEL? It works with either,
> and no python files are installed.  If Fedora is insisting, please
> conditionalize it.

Ugh, the dreaded EPEL compatibility is dragging us down again. Alright, I won't make this change so as not to clutter the spec file with conditionals, but I'm starting to agree with the recent sentiment on fedora devel mailing list that EPEL branches should simply remain separate from rawhide or even Fedora.

> The conditional for %check was temporary, and I think it just needs fixing. 
> I haven't had a chance to look at it again on the basis of
> https://github.com/hfp/libxsmm/issues/196

I'll reply with my reproducer there.

> I find splitting up the BRs generally makes the spec harder to read by
> spreading it out when there are lots. Is it required?

No, but it makes diffs cleaner if you make changes to just one of the deps.
Ok, I'll drop this change as well.

> We should perhaps see if it's possible to assume SSE4.2 for the Fedora
> package (though that won't run on Magny Cours here).

If it's not runtime-detected than no. I guess we could try enabling and testing in a VM with an emulated CPU without SSE4.2 support.

> By the way, I've packaged a couple of other add-ons for cp2k in copr, if
> they're of any interest, but can't remember which off-hand.

Nice. Please submit them anyway.

Comment 8 Dave Love 2018-02-20 12:03:08 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #7)
> Quoting Hans Pabst:
> [...] Please note, somewhere post-1.7.1 an issue was exposed/present
> when using CP2K/smp. This is resolved since the previous v1.8.2 release
> (also thanks to Andreas' reproducer). [...]

Thanks, not that it's clear whether I need to rebuild the local cp2k...

> > Why change the BR to python3, which breaks in EPEL? It works with either,
> > and no python files are installed.  If Fedora is insisting, please
> > conditionalize it.
> 
> Ugh, the dreaded EPEL compatibility is dragging us down again. Alright, I
> won't make this change so as not to clutter the spec file with conditionals,
> but I'm starting to agree with the recent sentiment on fedora devel mailing
> list that EPEL branches should simply remain separate from rawhide or even
> Fedora.

As far as I'm concerned, the problem is Fedora making life difficult in various ways for those of us working in HPC who are only interested in EPEL.  Anyhow, I don't understand the point of specifying a specific version of python when it makes no difference to the output.

> > I find splitting up the BRs generally makes the spec harder to read by
> > spreading it out when there are lots. Is it required?
> 
> No, but it makes diffs cleaner if you make changes to just one of the deps.
> Ok, I'll drop this change as well.

I find that if you want to change something there, it's normally several lines, and it's normally a question of "%{?rhel:" wherever, but I'm not terribly concerned either way.

> > We should perhaps see if it's possible to assume SSE4.2 for the Fedora
> > package (though that won't run on Magny Cours here).
> 
> If it's not runtime-detected than no. I guess we could try enabling and
> testing in a VM with an emulated CPU without SSE4.2 support.

I think it will fail.  I doubt anything other than Magny Cours without sse4 is relevant (unless the builders disable micro-architecture features), and is unlikely to be running anything other than EPEL.  I can't find any packaging stricture against it, and at least atlas has micro-architecture specifics.

> > By the way, I've packaged a couple of other add-ons for cp2k in copr, if
> > they're of any interest, but can't remember which off-hand.
> 
> Nice. Please submit them anyway.

I'm not sure I have the time/enthusiasm, and I don't get to use packages these days.  I see I've only put plumed in copr, but I've just submitted a build of pexsi too.  I did build cp2k against plumed, but I don't remember if it had pexsi too, and that would have been for an older cp2k.  You're welcome to adopt either.  I thought I'd done quip too, but it looks as if I didn't finish it.

Comment 9 Dave Love 2018-03-09 15:38:55 UTC
I've pushed a version of 1.8.3 for now.

Comment 10 Fedora Update System 2018-04-03 14:43:56 UTC
libxsmm-1.8.3-1.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-403418359a

Comment 11 Fedora Update System 2018-04-03 14:44:02 UTC
libxsmm-1.8.3-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-bcfacf6e35

Comment 12 Fedora Update System 2018-04-04 17:57:05 UTC
libxsmm-1.8.3-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-bcfacf6e35

Comment 13 Fedora Update System 2018-04-04 18:36:00 UTC
libxsmm-1.8.3-1.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-403418359a

Comment 14 Fedora Update System 2018-04-15 02:33:55 UTC
libxsmm-1.8.3-1.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 15 Fedora Update System 2018-04-15 14:43:20 UTC
libxsmm-1.8.3-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 16 Dominik 'Rathann' Mierzejewski 2018-05-22 09:25:21 UTC
Hi, Dave. Sorry, I've been too busy to respond earlier, but your update broke cp2k in F28 (bug 1577497) because the updated libxsmm has a different SONAME. You shouldn't have pushed it to stable without rebuilding cp2k and adding it to the same update first.

Comment 17 Dave Love 2018-05-24 08:25:36 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #16)
> Hi, Dave. Sorry, I've been too busy to respond earlier, but your update
> broke cp2k in F28 (bug 1577497) because the updated libxsmm has a different
> SONAME. You shouldn't have pushed it to stable without rebuilding cp2k and
> adding it to the same update first.

Of course I wouldn't do that intentionally, but I don't understand -- it just added the "update" version:

$ rpm -qlp libxsmm-1.8.1-4.fc28.x86_64.rpm|fgrep libxsmm.so                     
/usr/lib64/libxsmm.so.1                                                         
/usr/lib64/libxsmm.so.1.9                                                       
$ rpm -qlp libxsmm-1.8.3-1.fc28.x86_64.rpm|fgrep libxsmm.so                     
/usr/lib64/libxsmm.so.1                                                         
/usr/lib64/libxsmm.so.1.9                                                       
/usr/lib64/libxsmm.so.1.9.3

Comment 18 Dominik 'Rathann' Mierzejewski 2018-05-24 08:50:42 UTC
Filenames are irrelevant in this case. What matters is the SONAME entry in the ELF header of the shared library, which is used by ld and gets picked up by the rpm dependency generator. 1.8.1 provided "libxsmm.so.1" but 1.8.3 provides "libxsmm.so.1.9", which is different, obviously. The "()(64bit)" is just a suffix added by rpm to distinguish between 32 and 64bit versions. You can also check with `objdump -p /usr/lib64/libxsmm.so.1 | grep SONAME`. In other words, please always run rpmsodiff, rpmdiff and perhaps abipkgdiff on all updates before pushing to Fedora.

$ rpm -qp --provides https://kojipkgs.fedoraproject.org//packages/libxsmm/1.8.3/1.fc28/x86_64/libxsmm-1.8.3-1.fc28.x86_64.rpm
libxsmm = 1.8.3-1.fc28
libxsmm(x86-64) = 1.8.3-1.fc28
libxsmm.so.1.9()(64bit)
libxsmmext.so.1.9()(64bit)
libxsmmf.so.1.9()(64bit)
libxsmmgen.so.1.9()(64bit)
libxsmmnoblas.so.1.9()(64bit)
$ rpm -qp --provides https://kojipkgs.fedoraproject.org//packages/libxsmm/1.8.1/5.fc28/x86_64/libxsmm-1.8.1-5.fc28.x86_64.rpm
libxsmm = 1.8.1-5.fc28
libxsmm(x86-64) = 1.8.1-5.fc28
libxsmm.so.1()(64bit)
libxsmmext.so.1()(64bit)
libxsmmf.so.1()(64bit)
libxsmmgen.so.1()(64bit)
libxsmmnoblas.so.1()(64bit)

Comment 19 Dave Love 2018-05-24 10:05:45 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #18)
> Filenames are irrelevant in this case. What matters is the SONAME entry in
> the ELF header of the shared library, which is used by ld and gets picked up
> by the rpm dependency generator. 1.8.1 provided "libxsmm.so.1" but 1.8.3
> provides "libxsmm.so.1.9", which is different, obviously.

Yes, sorry, I realized in the meantime.  It looks like an upstream change which I think is incorrect.

> The "()(64bit)" is
> just a suffix added by rpm to distinguish between 32 and 64bit versions. You
> can also check with `objdump -p /usr/lib64/libxsmm.so.1 | grep SONAME`. In
> other words, please always run rpmsodiff, rpmdiff and perhaps abipkgdiff on
> all updates before pushing to Fedora.

I do run abipkgdiff, specifically checking for symbol differences apart from the unstable interfaces in this case, but I guess I missed the soname.
Apologies.

The change ought to be reverted rather than rebuilding against the new name.  I'll see if I can sort it out today, but am then going away for a long weekend.
If I don't finish that, perhaps you can do it, and build cp2k against the result as you can.

Comment 20 Dave Love 2018-05-24 12:32:42 UTC
I've submitted f27 and f28 builds to revert the soname change, and will push to stable as soon as allowed, so the cp2k rebuild can be discarded.

Comment 21 Fedora Update System 2018-05-24 12:40:35 UTC
libxsmm-1.8.3-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-d0a34b38ed

Comment 22 Fedora Update System 2018-05-24 12:40:41 UTC
libxsmm-1.8.3-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-b60d813a5c

Comment 23 Fedora Update System 2018-05-24 13:46:03 UTC
libxsmm-1.8.3-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-d0a34b38ed

Comment 24 Fedora Update System 2018-05-24 18:00:44 UTC
libxsmm-1.8.3-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-b60d813a5c

Comment 25 Fedora Update System 2018-06-01 12:03:46 UTC
libxsmm-1.8.3-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

Comment 26 Fedora Update System 2018-06-01 12:19:48 UTC
libxsmm-1.8.3-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.