Control: severity -1 normal Am Dienstag, den 02.03.2021, 01:02 +0200 schrieb Adrian Bunk: > On Mon, Mar 01, 2021 at 11:39:00PM +0100, Markus Koschany wrote: > > Am Montag, den 01.03.2021, 23:53 +0200 schrieb Adrian Bunk: > > > Source: spring > > > Version: 105.0.1+dfsg-1 > > > Severity: serious > > > Tags: patch > > > > > > spring builds with -march=native on amd64, which makes spring > > > only work on machines compatible with whatever buildd built it. > > > > What Policy violation justifies severity serious for this bug? > > The release team agrees that baseline violations are severity serious.
What do you mean by baseline "violations"? > Users can expect that all software we ship works on the baseline > of an architecture. Agreed. However I don't see that this assumption is not true for Spring compiled with march=native on our buildd. > > > Spring is only > > built on i386/i686 and amd64. What difference does it make if we switch to > > the > > generic march=x86-64 when march=native appears to be working fine? > > ... > > It appears to work, and will work for you if your CPU is compatible with > whatever buildd happened to build it. > > We used to have older AMD Opterons among the buildds, > gcc would emit 3DNow! instructions that no modern CPU has. I would really like to understand what the current drawback is for our users. If you could provide the build flags with march=native and march=x86-64 and then prove that march=x86-64 prevents some serious issues or makes the engine better for users, I would happily apply your patch. Otherwise I am reluctant to apply it because there is no current evidence that it improves the package. The GCC manual talks about "it _might_" have some drawbacks but it also depends on the package. Again where is the concrete drawback for Spring?
signature.asc
Description: This is a digitally signed message part