[Debian-med-packaging] Bug#916284: mrtrix3 seems to be amd64-only

Thu Dec 13 20:53:04 GMT 2018

Hi Yaroslav,

On Thu, Dec 13, 2018 at 12:58:51PM -0500, Yaroslav Halchenko wrote:
> 
> > I agree with Adrian that on the topic.  I would even have fixed
> > this in a team upload, but I'm a bit confused by the changelog
> > I've found in Git[1].  There is only one branch "debian" (I'd
> > love to have upstream and pristine-tar as well but I'm fine with
> > fixing this).  However, this branch contains a changelog
> > entry
> 
> Please proceed ahead with the next debian revision entry (-3).

Hmmm, sorry, I think I'll leave this upload to you (see next paragraph).

> BUT I am
> not yet sure if restricting to amd64 is the way to go, since it (used
> to at least) build at least for i386 on buster and ubuntus

I have way to less experience with this and if you think the proposed
solution is not correct I think you should find the correct fix.  Since
the fix I could do would simply changing the architecture field is so
easy that I can not really save your time by doing a team upload. ;-)

> or see more at http://neuro.debian.net/pkgs/mrtrix3.html
> 
> and -1 (which happened before) even built at that time on sid:
> 
> neurodebian at smaug ..lds/mrtrix3/3.0~rc3+git86-g4b523b413-1 % grep i386.*OK summary.build      
> mrtrix3_3.0~rc3+git86-g4b523b413-1~nd90+1_i386.build	OK	16:53.22 real, 6529.21 user, 280.91 sys, 27009632 out
> mrtrix3_3.0~rc3+git86-g4b523b413-1~nd100+1_i386.build	OK	19:59.56 real, 7835.78 user, 333.59 sys, 38376784 out
> mrtrix3_3.0~rc3+git86-g4b523b413-1~nd+1_i386.build	OK	20:22.06 real, 7732.59 user, 344.35 sys, 38403288 out
> mrtrix3_3.0~rc3+git86-g4b523b413-1~nd17.10+1_i386.build	OK	16:32.40 real, 6863.87 user, 284.41 sys, 27336024 out
> mrtrix3_3.0~rc3+git86-g4b523b413-1~nd18.04+1_i386.build	OK	15:22.20 real, 6721.61 user, 283.47 sys, 27575376 out
> 
> and relevant issue upstream worth following up on/checking how/what to
> be fixed up: https://github.com/MRtrix3/mrtrix3/issues/1453 -- may be
> testing recent snapshot of their repo would have addressed them...
> didn't look -- and would appreciate help
> 
> as for other non x32 platforms -- I've not analyzed the situation yet...  it
> might still be the matter of fixing it up since upstream just didn't have a
> chance to get exposed to other platforms. I do not see any explicit note about
> SSE requirement.  So let's ask:
> 
> https://github.com/MRtrix3/mrtrix3/issues/1514

I think its better if I keep my hands out of it.  This morning it felt
like a low hanging fruit and I could help a bit but the issue seems more
complex.

> re pristine-tar.  I guess i didn't push it due to  using/packaging (see
> debian/gbp.conf) also submodules:
> 
> 	$> git submodule
> 	 6e6196af03e27948154f1f11285aa11d35af4a36 testing/data (heads/master)
> 
> for testing.  But here you go -- I pushed the monster pristine-tar now.  I hope
> it is a correct one ;)

I can confirm it is correct.

> I also pushed the commit adjusting debian/gbp.conf to match the layout of this
> repo (debian/ branch for packaging, master for upstream).

Thanks.

> > mrtrix3 (3.0~rc3+git86-g4b523b413-2) neurodebian; urgency=medium
> 
> >   * Need to disable PIE on older systems
> 
> >  -- Yaroslav Halchenko <debian at onerussian.com>  Wed, 21 Nov 2018 23:08:01 -0500
> 
> 
> > which does not belong here (neurodebian is no release of Debian, right
> > ;-) ). I'd suggest the cleaner solution to move changes into a branch
> > neurodebian.  Moreover the releases in this branch should not simply
> 
> am I violating policy or causing lintian screaming?

No.  You are simply violating the principle of least surprise for other
members of the team.  Its very well established practice to use the
suffix I suggested below and if you want to profit from the help of
others its simply a good idea to stick to these practices.  You know
that I fiddled around with some packages maintained by NeuroDebian team
and in close to all packages I realise specific things which do not fit
the workflow that is pretty established in the Debian Med team.  You are
free to derive from this but if I get the feeling that these packages
create more work than other packages in the team I'm less motivated to
help.

> if not  -- I'd suggest to
> keep it as is to avoid avoidable extra work for me -- if you upload -3, please
> use 'unstable' as the release label and then whoever looks at the
> debian/changelog would know that -2 was NOT uploaded to unstable/Debian

Sure if I *would* upload I would have used unstable (what else?) but I
try to raise your awareness that "holes in the release number history"
might cause questions.  I'd recommend to avoid this in favour of what
many others are doing in comparable situations.

> (I also
> keep UNRELEASED some times whenever some -debrev was not uploaded but used
> locally or just reflects the state of packaging which ever existed at that
> point -- helps to visualize the changes in the package/project timeline)

Right, I would expect UNRELEASED for unreleased packages as per Debian
Med team policy (and many other team policies).

> > bump the revision number.  It should be rather like in backports or
> > derivatives rather something like
> 
> >     3.0~rc3+git86-g4b523b413-1~neurodebian+1
> 
> we backport to all releases, automagically (without committing those to git
> since built away from git repo, based on .dsc source pkg) with custom
> (~nd) suffix per release: http://neuro.debian.net/pkgs/mrtrix3.html and
> corresponding changelog entries added on top of non ~nd  once.

I agree that automatic changes should not be commited to Git.  However,
it simply seems natural to me that only uploads to Debian are kept
inside the debian branch.

> > or something like this.  I have no idea whether the current state in Git
> > is somehow released and it is to late to fix this nor whether you intend
> > to take over the change you did for Neurodebian also for the next Debian
> > release.
> 
> it is "released" within neurodebian, since that is where those -2
> changes were only relevant. That is why I didn't upload -2 to unstable
> because it would be just causing rebuild/new version without any actual
> change to the package(s)

Because I redraw my intention to upload since I feel incompetent to
decide about the technical issue feel free to do this as you prefer.

Kind regards

       Andreas.

-- 
http://fam-tille.de