#1 New release 6.4 (#1509735)
Merged 2 years ago by churchyard. Opened 2 years ago by junghans.

file modified
+1

@@ -4,3 +4,4 @@

  /lmfit-6.0.tgz

  /lmfit-6.1.tgz

  /lmfit-6.2.tgz

+ /lmfit-6.4.tgz

file modified
+4 -1

@@ -1,5 +1,5 @@

  Name:           lmfit

- Version:        6.2

+ Version:        6.4

  Release:        1%{?dist}

  Summary:        Levenberg-Marquardt least-squares minimization and curve fitting

  # software is BSD, documentation is CC-BY

@@ -49,6 +49,9 @@

  %{_mandir}/man7/*

  

  %changelog

+ * Thu Dec 21 2017 Christoph Junghans <junghans@votca.org> - 6.4-1

+ - New release 6.4 (#1509735)

+ 

  * Wed Nov 01 2017 Miro Hrončok <mhroncok@redhat.com> - 6.2-1

  - New release 6.2 (#1508193)

  

file modified
+1 -1

@@ -1,1 +1,1 @@

- SHA512 (lmfit-6.2.tgz) = 8ea1cea603b38d68dc98671a6a2c96a1dd2380a83366e5d7426cebcd20c72390af03761d7991ac56c1532e678f53aba4fb5900d47fb84b840eae9d187a1abf63

+ SHA512 (lmfit-6.4.tgz) = 2bd0f24dd4638345b8b1ce6803ddcf45ca3ef888eb285e99f9f158c2e30b0f96016d9d84a112cdbf28f2ba98470e54fe773416179a65264426043c9a5186757d

lmfit-6.2 breaks gromacs-2018 (which I am about to dump, cc @rathann), but lm-6.4 seems to fix it.

Scratch build here: https://koji.fedoraproject.org/koji/taskinfo?taskID=23828289

I'm not the primary maintainer, but this looks good to me.

Any details about the lmfit-6.2/gromacs-2018 breakage?

we might have to bump lmfit to 6.4 in f27 as well.

@churchyard, I am happy to help with his package.

@rathann, I reported it upstream as well: https://redmine.gromacs.org/issues/2363, some details are there.

Looks fairly simple. I don't currently have time to test it, but repsnapper depends on lmfit, please test whether it works if we want to put this to f27 as well (and whether it needs rebuild). Will marge and build in rawhide.

Pull-Request has been merged by churchyard

2 years ago

@rathann, that fixed that, but there are still some other tests broken on the more exotic architetures: https://koji.fedoraproject.org/koji/taskinfo?taskID=23831365

@junghans Hm. Example failure (ppc64le):

/builddir/build/BUILD/gromacs-2018-beta3/src/gromacs/utility/tests/basedefinitions.cpp:79: Failure
Value of: addr3 % 8
  Actual: 4
Expected: 0

This comes from here.

Indeed, gcc warns about over-alignment here (and in many other places):

/builddir/build/BUILD/gromacs-2018-beta3/src/gromacs/utility/tests/basedefinitions.cpp: In member function 'virtual void gmx::BasedefinitionsTest_GmxAlignedDeclaresAlignedVariable_Test::TestBody()':
/builddir/build/BUILD/gromacs-2018-beta3/src/gromacs/utility/tests/basedefinitions.cpp:59:27: warning: requested alignment 32 is larger than 16 [-Wattributes]
     GMX_ALIGNED(real, 8)  r3;
                           ^~
/builddir/build/BUILD/gromacs-2018-beta3/src/gromacs/utility/tests/basedefinitions.cpp:71:27: warning: requested alignment 32 is larger than 16 [-Wattributes]
     GMX_ALIGNED(int, 8)   i3;
                           ^~

It looks like max alignment by gcc on ppc64le is 16, so I guess the GMX_ALIGNED macro needs to be fixed not to request anything more than __BIGGEST_ALIGNMENT__. Unfortunately, this is gcc-specific.

According to gcc upstream, non-working over-alignment is not a bug.

Oh man, can you report that upstream?