Re: hyphy - amd64 Test failures
Thanks both :-) Yeah, I remember thinking about this, but in my rush I forgot. I've pulled the installation of the simd-dispatcher script into override_dh_install-indep. Cheers, On Sun, 31 Jan 2021 at 00:41, Juhani Numminen wrote: > Hi Nilesh and Michael, > > On Sat, 30 Jan 2021, 23.24 Nilesh Patra wrote: > >> Hi Michael, >> >> Thanks for your work on hyphy. >> It seems that with your last upload, CI tests are failing on amd64, but >> working everywhere else, as can be seen on tracker here[1] >> >> The log for amd64 on debci[2] seems to have compliance with salsa CI[3] >> I see the binaries generated as desired on corresponding buildd log, >> > > The build logs lead me to believe something is missing though. > > The target override_dh_install-arch attempts to install simd-dispatch into > binpkg hyphy-common. Now consider that the buildd network builds the > arch-independent binary packages separately. During arch-indep build, the > "-arch" suffixed target is ignored, so simd-dispatch perhaps surprisingly > does not end up in hyphy-common. > > > Regards, > Juhani >
Re: [solved] porting brian on MIPS and POWER, or dropping support
Michael Crusoe, on 2021-01-31 10:47:32 +0100:
> 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 fully agree, although I have yet to clearly understand how to
clean up patches before being truly suitable for upstream use.
I'm busy AFK most of today but may have some time next Wednesday
afternoon UTC.
> On Sun, Jan 31, 2021, 10:18 Étienne Mollier
> wrote:
> > [1] https://buildd.debian.org/status/package.php?p=brian
> >
> > I feel like I generated a lot of noise while the issue could be
> > solved with little change actually, I apologize for this but am
> > grateful for your time.
> >
>
> I enjoyed the conversation, so please don't hold back!
Good to hear that, will ping again next time I'm bitten by
architectures specific issues. :)
> > 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 😄
Great! :)
> 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.
Thanks for the procedure to upload to experimental, it will come
in handy! I haven't had the opportunity to use it yet.
Kind Regards,
--
Étienne Mollier
Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
signature.asc
Description: PGP signature
Re: [solved] porting brian on MIPS and POWER, or dropping support
On Sun, Jan 31, 2021, 10:18 Étienne Mollier
wrote:
> 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?
> [1] https://buildd.debian.org/status/package.php?p=brian
>
> I feel like I generated a lot of noise while the issue could be
> solved with little change actually, I apologize for this but am
> grateful for your time.
>
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!
[solved] porting brian on MIPS and POWER, or dropping support
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. [1] https://buildd.debian.org/status/package.php?p=brian I feel like I generated a lot of noise while the issue could be solved with little change actually, I apologize for this but am grateful for your time. Thanks Nilesh for having beaten me at closing the request for removal! :) 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. Have a nice Sunday everyone, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/2, please excuse my verbosity. signature.asc Description: PGP signature
