Hi all,
The build went well on all architectures not missing build
dependencies[1]. The current implementation injects no compiler
optimisation in the state updater steps, so by playing safe the
package proved to be rather portable.
Glad it works now!
I think the nice/responsible thing to do is to try a couple builds in experimental that uses the -march=native or -mcpu=native flags plus the remaining flags on a per architecture basis. And only then try to reduce the -O optimization level or drop some of the other flags as needed (again, only for the architectures that need that). The result should be sent to upstream for inclusion and then uploaded to sid.
Do you have time to do that; or do you want to do it together?
I enjoyed the conversation, so please don't hold back!
Michael Crusoe, on 2021-01-30 19:31:42 +0100:
> If it is truly for local use, then -march=native is great, but not every
> architecture supports "-march=native", so you may need to add work arounds
> for archs that don't have that gcc option.
>
> Here is the result of some reading of the gcc manual page
>
> -march=native & -mtune=native is valid in gcc for the following Debian
> archs:
>
> arm*
> mips*
> s390x
> i386/amd64/x32
>
> but not these
>
> HPPA
> M68k
> riscv64
> power*/ppc* (no -march at all, but does have -mcpu=native and -mtune=native)
> alpha (no -march at all, but does have -mcpu=native and -mtune=native)
> sh4 (no -march at all, no -mcpu either)
> sparc64 (no -march at all, but does have -mcpu=native and -mtune=native)
> ia64 (no -march, has -mtune but not -mtune=native)
Thanks Michael for this precious information, I will use it to
bring back some performance to these brian functions, at cost of
complexity perhaps, once brian is back to Testing, in the coming
week hopefully.
Ah, good, we are on the same page! But we can start now with an upload to "experimental" without having to wait for the migration to testing 😄
I don't remember if you've done packaging for the "experimental" section before, so here are some quick notes that you can skip if you have already.
1. Be sure to use version like 2.4.2-4~0exp0 so that the "proper" release of 2.4.2-4 will supercede the experimental version
2. Push your changes to a new `debian/experimental` branch instead of the default branch (currently named "master", but that is another conversation for another day)
You will need to add --debian-git-branch=debian/experimental or --git-branch=debian/experimental to `gbp` commands (alas, the option name isn't consistent)
3. When doing `dch --release`, either add the command line option to set the distribution to "experimental" or hand edit the top line of the changelog to achieve the same (the latter is what I do)
Otherwise your packaging workflow should be the same. Use your existing sid/unstable {cow,p}builder and/or sbuild/debci chroots. A special "experimental" chroot isn't needed unless you require packages that have also been uploaded only to the "experimental" psuedo-distribution.
Have a nice Sunday everyone, :)
Likewise!