Re: bart version 0.9.00

[Martin Uecker]

Am Sonntag, dem 10.12.2023 um 21:37 -0800 schrieb tony mancill:
> On Mon, Dec 11, 2023 at 12:11:38AM +0100, Martin Uecker wrote:
> > I upgraded the BART package to the new upstream release.
> > 
> > I would appreciate if someone could take a look and then
> > upload it
> 
> Hi Martin,
> 
> The new package version looks good to me.  I finalized the
> debian/changelog, uploaded, and pushed that commit and the
> debian/0.9.00-1 tag to the Salsa repo.
> 
> Cheers,
> tony

Hi Tony,

thank you! Unfortunately, the i386 builds were hanging. I fixed this
and fix/improved couple of other things.

Can I ask you to upload again?

Martin

bart version 0.9.00

[Martin Uecker]

Hi,

I upgraded the BART package to the new upstream release.

I would appreciate if someone could take a look and then
upload it

Thanks!


Martin

Re: BART 0.8.0

[Martin Uecker]

Am Donnerstag, den 27.10.2022, 07:26 +0530 schrieb Nilesh Patra:
> On Wed, Oct 26, 2022 at 11:56:28AM +0200, Martin Uecker wrote:
> > Thank you! It seems this is working correctly
> > on all archs.
> > 
> > I also finalized the bart-view update. Can
> > you upload it as well?
> 
> I had done so, thanks!

Thank you Nilesh and Andreas! 

bart, bart-cuda, and bart-view all entered testing.


Martin

Re: BART 0.8.0

[Martin Uecker]

Am Dienstag, den 25.10.2022, 01:12 +0530 schrieb Nilesh Patra:
> On Mon, Oct 24, 2022 at 09:20:21PM +0200, Martin Uecker wrote:
> > Am Dienstag, den 25.10.2022, 00:41 +0530 schrieb Nilesh Patra:


Hi Nilesh,

> > > Also, salsa CI is failing the build pipeline,
> > > 
> > >   https://salsa.debian.org/med-team/bart-view/-/jobs/3422195
> > > 
> > > this is not expected right?
> > 
> > I am still working on the update of bart-view.
> > But bart has to be updated first anyway.
> 
> I saw your commits and was somehow under the impression that you updated 
> bart-view, -cuda and bart
> since you usually do this at once :)
> 
> I have uploaded bart with your changes.

Thank you! It seems this is working correctly
on all archs.

I also finalized the bart-view update. Can
you upload it as well?

Martin

Re: BART 0.8.0

[Martin Uecker]

Am Dienstag, den 25.10.2022, 00:41 +0530 schrieb Nilesh Patra:
> Hello,
> 
> On Mon, Oct 24, 2022 at 08:39:33PM +0200, Martin Uecker wrote:
> > Hi Andreas and all,
> > 
> > I updated the package and turned off some unit tests on
> > i386 for now (and turned on other tests and made some
> > other changes).
> > 
> > If you or somebody else could sponser an upload, this
> > would be great!
> 
> Sorry for being lazy and not checking this for myself here, but does your
> update also fix the recent release-critical bug against bart-view?
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022324
> 
> If so, please close this in changelog.

No, this will additionally also require also 
an update of bart-view.

> Also, salsa CI is failing the build pipeline,
> 
>   https://salsa.debian.org/med-team/bart-view/-/jobs/3422195
> 
> this is not expected right?

I am still working on the update of bart-view.
But bart has to be updated first anyway.

> Lastly, please consider to add in your new commit e-mail to your salsa 
> profile so it
> is easy to associate your account w/ your commits.

I will update it.

Best,
Martin

Re: BART 0.8.0

[Martin Uecker]

Hi Andreas and all,

I updated the package and turned off some unit tests on
i386 for now (and turned on other tests and made some
other changes).

If you or somebody else could sponser an upload, this
would be great!

Then I also need to update bart-view...

Martin



Am Freitag, den 14.10.2022, 17:39 +0200 schrieb Andreas Tille:
> Hi again,
> 
> the build fails on i386[1].  Any idea what might went wrong?
> 
> Please note: I'm not able to sponsor bart in the next week
> but I guess someone else will step in.
> 
> Kind regards
> 
>   Andreas.
> 
> 
> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=bart=i386=0.8.00-2=1665741010=0
> 
> Am Fri, Oct 14, 2022 at 08:53:00AM +0200 schrieb Andreas Tille:
> > Hi Martin,
> > 
> > Am Thu, Oct 13, 2022 at 09:41:19PM +0200 schrieb Martin Uecker:
> > > > Yes, the issue is numerical unit tests failing on
> > > > some archs. This not entirely surprising as we had this
> > > > before, and we added *many* new tests in this version. 
> > > > 
> > > > I will see that it get it running on some ARM64 myself
> > > > and then push some fixes.
> > > 
> > > Ok, I pushed some changes which should address this.
> > > There was some issue affecting 32bit archs
> > > and also some other issue we could reproduce
> > > on ARM64. This is still under investigation but
> > > turning off some optimizations seems to fix it
> > > for now.
> > > 
> > > There also is the issue that some autopkgtests
> > > were sometimes failing. I tried to address this
> > > too.
> > 
> > I've uploaded bart.  Thanks a lot for working on this.
> >  
> > > For bart-cuda I also changed the build dependency
> > > to g++-11 and maybe this works now with the new
> > > nvidia-toolkit 
> > > 
> > > So please upload bart and bart-cuda. Thank you!
> > 
> > I've not yet uploaded bart-cuda.  I think it makes sense to wait until
> > all autobuilders have passed bart.  Please ping me in case I might
> > forget. 
> > 
> > Kind regards
> > 
> >  Andreas.
> > 
> > -- 
> > http://fam-tille.de
> > 
> > 

Re: BART 0.8.0

[Martin Uecker]

Am Freitag, den 14.10.2022, 17:39 +0200 schrieb Andreas Tille:
> Hi again,
> 
> the build fails on i386[1].  Any idea what might went wrong?

One test goes into an infinite loop, but only on i386...
Everything else seems fine now (except an old alpha issue).

I will look into this.

Martin

> Please note: I'm not able to sponsor bart in the next week
> but I guess someone else will step in.
> 
> Kind regards
> 
>   Andreas.
> 
> 
> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=bart=i386=0.8.00-2=1665741010=0
> 
> Am Fri, Oct 14, 2022 at 08:53:00AM +0200 schrieb Andreas Tille:
> > Hi Martin,
> > 
> > Am Thu, Oct 13, 2022 at 09:41:19PM +0200 schrieb Martin Uecker:
> > > > Yes, the issue is numerical unit tests failing on
> > > > some archs. This not entirely surprising as we had this
> > > > before, and we added *many* new tests in this version. 
> > > > 
> > > > I will see that it get it running on some ARM64 myself
> > > > and then push some fixes.
> > > 
> > > Ok, I pushed some changes which should address this.
> > > There was some issue affecting 32bit archs
> > > and also some other issue we could reproduce
> > > on ARM64. This is still under investigation but
> > > turning off some optimizations seems to fix it
> > > for now.
> > > 
> > > There also is the issue that some autopkgtests
> > > were sometimes failing. I tried to address this
> > > too.
> > 
> > I've uploaded bart.  Thanks a lot for working on this.
> >  
> > > For bart-cuda I also changed the build dependency
> > > to g++-11 and maybe this works now with the new
> > > nvidia-toolkit 
> > > 
> > > So please upload bart and bart-cuda. Thank you!
> > 
> > I've not yet uploaded bart-cuda.  I think it makes sense to wait until
> > all autobuilders have passed bart.  Please ping me in case I might
> > forget. 
> > 
> > Kind regards
> > 
> >  Andreas.
> > 
> > -- 
> > http://fam-tille.de
> > 
> > 

Re: BART 0.8.0

[Martin Uecker]

Hi Andreas,

Am Sonntag, den 09.10.2022, 09:39 +0200 schrieb Martin Uecker:
> Hi Andreas,
> 
> Am Sonntag, den 09.10.2022, 06:39 +0200 schrieb Andreas Tille:
> 


> > > > I will do this soon, but probably wait in case other issues
> > > > emerge with the new packages.
> >  
> > Seems there are build issues on some architectures:
> > 
> >https://buildd.debian.org/status/package.php?p=bart
> > 
> > Could you have a look?
> 
> Yes, the issue is numerical unit tests failing on
> some archs. This not entirely surprising as we had this
> before, and we added *many* new tests in this version. 
> 
> I will see that it get it running on some ARM64 myself
> and then push some fixes.

Ok, I pushed some changes which should address this.
There was some issue affecting 32bit archs
and also some other issue we could reproduce
on ARM64. This is still under investigation but
turning off some optimizations seems to fix it
for now.

There also is the issue that some autopkgtests
were sometimes failing. I tried to address this
too.

For bart-cuda I also changed the build dependency
to g++-11 and maybe this works now with the new
nvidia-toolkit 

So please upload bart and bart-cuda. Thank you!

Martin

Re: BART 0.8.0

[Martin Uecker]

Hi Andreas,

Am Sonntag, den 09.10.2022, 06:39 +0200 schrieb Andreas Tille:
> Hi Martin,
> 
> Am Sat, Oct 08, 2022 at 05:45:43PM +0200 schrieb Andreas Tille:
> > H, I need to check my upload - thanks for mentioning it.
> > Bart-cuda arrived in unstable but bart is pending.  I'll check later.
> 
> I've done so yesterday.

Thanks!

> > > I will do this soon, but probably wait in case other issues
> > > emerge with the new packages.
>  
> Seems there are build issues on some architectures:
> 
>https://buildd.debian.org/status/package.php?p=bart
> 
> Could you have a look?

Yes, the issue is numerical unit tests failing on
some archs. This not entirely surprising as we had this
before, and we added *many* new tests in this version. 

I will see that it get it running on some ARM64 myself
and then push some fixes.

Martin

Re: BART 0.8.0

[Martin Uecker]

Hi Andreas,

Am Freitag, den 07.10.2022, 15:18 +0200 schrieb Andreas Tille:
> Hi Martin,
> 
> Am Sat, Oct 01, 2022 at 02:45:21PM +0200 schrieb Martin Uecker:
> > I updated the Debian packages for BART (bart and bart-cuda) 
> > to our new upstream version. 
> 
> Thanks a lot for preparing these packages which I just uploaded.

Thank you! I assume the bart package is still being processed?

> > This time I also managed to run the CI on salsa for bart-cuda
> > There are still some failures, but it seems ok to me.
> 
> I admit in my local pbuilder I also observed issues but it seems
> to be OK in Salsa CI.
> 
> > Please upload if it looks ok to you.
> 
> Is there any reason to stick to gcc-10.  I'm not sure when this
> GCC version will be removed - but sooner or later this will be
> the case. 

This was caused by nvcc not being compatible with newer
version of GCC, but it seems a new version of
nvidia-cuda-toolkit is now in sid, so we could try
updating the build dependencies:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016625#65

I will do this soon, but probably wait in case other issues
emerge with the new packages.

Martin


> Kind regards and thanks again for your contribution
> 
> Andreas.
> 

BART 0.8.0

[Martin Uecker]

Hi all,

I updated the Debian packages for BART (bart and bart-cuda) 
to our new upstream version. 

This time I also managed to run the CI on salsa for bart-cuda
There are still some failures, but it seems ok to me.

Please upload if it looks ok to you.

Martin

Re: [Fwd: Bug#1001916: src:bart-view: fails to migrate to testing for too long: FTBFS on armel and s390x]

[Martin Uecker]

Am Mittwoch, den 29.12.2021, 20:34 +0530 schrieb Nilesh Patra:
> On 12/29/21 6:31 PM, Martin Uecker wrote:
> > Am Mittwoch, den 29.12.2021, 11:06 +0100 schrieb Martin Uecker:
> > > Hi Nilesh,
> > ...
> > 
> > > > - try to work around by patching? (would be easy
> > > > only with access to the affected architectures)
> > > > 
> > > > This would be best. You could try with qemu to emulate these archs.
> > > 
> > > I guess this is what I will try.
> > 
> > Ok, I pushed a patch that seems to fix it for my qemu builds.
> > 
> > Maybe you or Andreas could take a look at my changes and upload?
> 
> Uploaded with minor changes.
> 
> PS: Please keep your email to what you've mentioned on d/control, or 
> otherwise change that in the
> control file itself
> it would otherwise give a NMU warn.
> For now, I changed the changelog entry to 
> "martin.uec...@med.uni-goettingen.de" as mentioned on
> d/control

Ok. Thank you! (was going to fix the CPPFLAGS thing, but then forgot. Thanks!)

Martin


> Regards,
> Nilesh
> 

Re: [Fwd: Bug#1001916: src:bart-view: fails to migrate to testing for too long: FTBFS on armel and s390x]

[Martin Uecker]

Am Mittwoch, den 29.12.2021, 11:06 +0100 schrieb Martin Uecker:
> Hi Nilesh,
...

> > - try to work around by patching? (would be easy
> >only with access to the affected architectures)
> > 
> > This would be best. You could try with qemu to emulate these archs.
> 
> I guess this is what I will try.

Ok, I pushed a patch that seems to fix it for my qemu builds.

Maybe you or Andreas could take a look at my changes and upload?

Thank you! 

Martin

Re: [Fwd: Bug#1001916: src:bart-view: fails to migrate to testing for too long: FTBFS on armel and s390x]

[Martin Uecker]

Hi Nilesh,

thanks!

> On 12/28/21 5:36 PM, Martin Uecker wrote:
> 
> Hi all,
> 
> this is caused by some compiler bug in GCC 11.  Any advice how
> to proceed?
> 
> - use GCC 11

(I meant GCC 10)

> If this really is a bug in the _compiler itself_, maybe simply
> file a bug report against gcc-11 itself?
> Please do this regardless of the solution ^^

Yes, I already did this. (Although not too useful without
access to the archs because I can't provide a minimized
test case).

> - exclude affected architectures?
> 
> It looks unlikely for someone to use bart-view on these archs, so
> this is an acceptable solution as well, i.e. filing a removal bug on specific 
> archs.
> It however takes time since FTP masters will manually process it.

> - try to work around by patching? (would be easy
>only with access to the affected architectures)
> 
> This would be best. You could try with qemu to emulate these archs.

I guess this is what I will try.

> If it does not work, you can apply for guest access on these machines as 
> given here[1]

Last time I tried this I never got a useful response.

> - talk to the release team?
> 
> They can't do much here.

Maybe the could simply not remove bart-view if the failure
to update on some archs is caused by the compiler?


Martin


> [1]: https://dsa.debian.org/doc/guest-account/
> 
> Regards,
> Nilesh

[Fwd: Bug#1001916: src:bart-view: fails to migrate to testing for too long: FTBFS on armel and s390x]

[Martin Uecker]

Hi all,

this is caused by some compiler bug in GCC 11.  Any advice how
to proceed?  

- use GCC 11 
- exclude affected architectures?
- try to work around by patching? (would be easy
  only with access to the affected architectures)
- talk to the release team?

Best,
Martin


 Weitergeleitete Nachricht 
Von: Paul Gevers 
Antwort an: Paul Gevers , 1001...@bugs.debian.org
An: sub...@bugs.debian.org
Betreff: Bug#1001916: src:bart-view: fails to migrate to testing for too long: 
FTBFS on armel and 
s390x
Datum: Sat, 18 Dec 2021 22:14:32 +0100

> Source: bart-view
> Version: 0.1.00-4
> Severity: serious
> Control: close -1 0.1.00-5
> Tags: sid bookworm ftbfs
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing 
> and unstable for more than 60 days as having a Release Critical bug in 
> testing [1]. Your package src:bart-view has been trying to migrate for 
> 61 days [2]. Hence, I am filing this bug. Your package fails to build 
> from source on armel and s390x where it built successfully in the past.
> 
> If a package is out of sync between unstable and testing for a longer 
> period, this usually means that bugs in the package in testing cannot be 
> fixed via unstable. Additionally, blocked packages can have impact on 
> other packages, which makes preparing for the release more difficult. 
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that 
> hamper the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new 
> bugs, there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if 
> that version or a later version migrates, this bug will no longer affect 
> testing. I have also tagged this bug to only affect sid and bookworm, so 
> it doesn't affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to 
> issues beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
> [2] https://qa.debian.org/excuses.php?package=bart-view
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Martin Uecker]

Hi Andreas,

> For me the package is close to ready if I would understand why you
> insist on the empty dir usr/lib/bart/commands/.  I do not see any reason
> for this since in /usr only packages can / should write and a package
> that writes to this location would create the package itself.  Users
> should not write to /usr - so why leaving the empty dir there?
>
> Is your intention rather to create
> 
>  /var/lib/bart/commands/
> 
> and set apropriate permissions in a postinst script?

It was meant for system-wide add-ons installed by 
other packages or compiled locally. But you are right,
another package could create it itself and locally compiled
stuff should go in /usr/local/...  

So I removed it by having a debian patch. But it isn't
clear to me whether the change should also be reflected
directly in the master branch or only as a commit which adds
the patch in debian/patches/. The tools do not seem to
care...

Martin
 

Re: Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Martin Uecker]

> There are three remaining and easy to fix lintian issues:
> 
> I: bart source: duplicate-short-description bart libbart-dev
> W: bart: package-installs-into-obsolete-dir etc/bash_completion.d/ : 
> ^etc/bash_completion.d/ -> usr/share/bash-completion/completions (see also 
> https://bugs.debian.org/776954)
> I: bart: package-contains-empty-directory usr/lib/bart/commands/
>
> If these are fixed I could upload.

Fixed. I wonder why I didn't get these warning. Probably because 
I called lintian on the binaries and not on the .dsc file.


Martin

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Martin Uecker]

Hi Ghislain,


Ghislain Vaillant <ghisv...@gmail.com>:
> On 08/01/16 19:29, Martin Uecker wrote:
 
> Good. Then, you might want to use libbart-dev as the package name, which 
> is usually the naming convention for packages containing any libraries 
> (in shared or static form).

Done.
 
> > Also one can replace liblapack.so using update-alternatives.
> > Why would it matter what I compile against as all alternatives
> > should be ABI compatible?
> 
> Absolutely. It is just that if I use OpenBLAS locally, I don't want to 
> have to install lapack-dev to build bart, which would also mess up with 
> my alternatives in the process. Using liblapack-dev | liblapack.so is 
> just a bit friendlier.

This makes sense. This is just a virtual  package where liblapack-dev, 
ATLAS, etc. have a "Provides: liblapack.so". Somehow the filename-like
name of the virtual package got me confused.


What are the next steps? 

From my side, everything looks good. Ofcourse, there might be
some issues when compiling for all the different architectures.

Martin

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Martin Uecker]

 Ghislain Vaillant :

> 
> FYI, the same trick is used for other dependencies with multiple 
> backends such as OpenCL.

What is the state of OpenCL on Debian? 

We only support CUDA in BART, but I always wanted to add OpenCL 
support and it should be fairly easy...


Martin

Re: Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Martin Uecker]

Hi Ghisvail!

> - Binary packages split-up.
> 
> I am not quite sure about the usefulness of the bart-dev package. The final 
> compilation line shows:
...
> i.e. the final output is one executable (bart) with private libraries 
> (libbox, libgrecon...) linked statically. So it looks to me that these 
> libraries are not intended to be used publicly?

There are meant to be used and there are people who are using
them for internal projects. Ofcourse, they currently use the
source distribution of BART, but I think a -dev package would
be useful in the long run. I also have  a small image viewer
build on top of the libraries, which I would like to package
eventually:

https://github.com/mrirecon/view


> 
> - Licensing of the bart Debian packages.
> 
> Since the software is compiled with GSL and FFTW support, the resulting 
> binary should be distributed under a compatible GPL-like license. This may 
> need to acknowledged somewhere, maybe in debian/README.Debian. For an example 
> of such acknowledgement, have a look at how this is done with ITK [1].

I added a README.Debian.

> - Copyright listing.
> 
> The output of licensecheck shows that some files have different copyright 
> attributions than yours. For instance:
> 
> 
> ./matlab/imshow3.m: UNKNOWN
>   [Copyright: Michael Lustig 2012 [sx,sy,nc] = size(img);]
> 
> Please be super thorough on these, since a non-exhaustive copyright listing 
> is a strong motive for package rejection.

We have permission to re-distribute everything
under the BSD license. I reworded the copyright file to

Copyright: 2013-2016 The Regents of the University of California
   2013-2016 BART Developer Team and Contributors

to make clear that there are other contributors who
own copyright themselves.

> 
> - lapack-dev -> lapack-dev | lapack.so in your list of Build-Depends in 
> d/control.
> 
> 
> That way your package can be built with optimized libraries like atlas or 
> openblas.

Sounds like a good idea, but I do not understand it. What
does it mean to depend on "lapack.so"?

Also one can replace liblapack.so using update-alternatives.
Why would it matter what I compile against as all alternatives
should be ABI compatible?


> - Potential overlinkage.
> 
> You might want to check these warnings out:
> 
> dpkg-shlibdeps: warning: package could avoid a useless dependency if 
> debian/bart/usr/bin/bart was not linked against libgslcblas.so.0 (it uses 
> none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a 
> useless dependency if debian/bart/usr/bin/bart was not linked against 
> libz.so.1 (it uses none of the library's symbols)

Those should be fixed with the new upsteam release.


>Apart from these comments. Looks good on my side.

Thank you for your help!

Martin

G

Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Martin Uecker]

Hi Andreas,


> I get:
> 
> ...
>dh_clean
>  dpkg-source -i.git -I.git -b bart-0.2.09d
> dpkg-source: info: using options from bart-0.2.09d/debian/source/options: 
> --extend-diff-ignore=(^|/)(version.(inc|txt)|commands.txt)$
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building bart using existing ./bart_0.2.09d.orig.tar.gz
> dpkg-source: info: local changes detected, the modified files are:
>  bart-0.2.09d/version.txt
> dpkg-source: error: aborting due to unexpected upstream changes, see 
> /tmp/bart_0.2.09d-1.diff.anXVz0
> dpkg-source: info: you can integrate the local changes with dpkg-source 
> --commit
> dpkg-buildpackage: error: dpkg-source -i.git -I.git -b bart-0.2.09d gave 
> error exit status 2
> 
> 
> which is caused by the following diff:
> 
> --- bart-0.2.09d.orig/version.txt
> +++ bart-0.2.09d/version.txt
> @@ -1 +1 @@
> -v0.2.09
> +v0.2.09d
> 

I don't understand why. Shouldn't the '--extend-diff-ignore' option prevent 
this?
For me it works without errors using

dpkg-buildpackage  

and als using

gbp buildpackage --git-pbuilder



Happy new year!
Martin


  
> > Also I wonder whether there is a way to build and
> > test the package on other architectures than amd64?
> 
> The usual procedure is to upload and see whether autobuilders will cope
> with it - otherwise you can review the logfiles.
> 
> Kind regards
> 
> Andreas.
> 
> -- 
> http://fam-tille.de
> 

Re: Re: [MoM] Re: bart - tools for computational magnetic resonance imaging

[Martin Uecker]

Hi Andreas,

> On Mon, Dec 07, 2015 at 08:18:59AM +, Uecker, Martin wrote:
> > > On Sun, Dec 06, 2015 at 11:59:02PM +, Uecker, Martin wrote:
> > > > > Put simply, pristine-tar is our way to encapsulate access to the 
> > > > > source 
> > > > > tarball used for packaging. Someone who checks out a d-science 
> > > > > repository does not need to know where the tarball comes from 
> > > > > (github, 
> > > > > bitbucket, PyPI...), he or she can just check it out using 
> > > > > pristine-tar 
> > > > > on the packaging repository.
> > > > 
> > > > Ok, I created a tar ball using a git archive (which matches what
> > > > github does) and then used pristine-tar to check it in.
> > > 
> > > I think this is a misunderstanding.  You should write a debian/watch file
> > > (line 22 of this template
> > >   
> > > https://anonscm.debian.org/viewvc/debian-med/trunk/package_template/watch?revision=20511=markup
> > > is your friend) and use the downloaded tarball when importing 
> > > pristine-tar.
> > 
> > Ok, done.
> > 
> > Please note that there is no difference between downloading 
> > tar balls from github which uses 'git archive' to create them
> > or creating them locally using 'git archive' (with the
> > right arguments). This already produces bit-identical results
> > (with the same hash)! So there is really no point in downloading
> > upstream tarballs from Github when one has a local copy of the git
> > repository. 
> 
> I have no doubt that *Github* can create bit-identical results.
> However, I have doubt that you can create from a local clone the
> very same tarball.  

I agree that it is a bit surprising, but it does work:

wget https://github.com/mrirecon/bart/archive/v0.2.09d.tar.gz
git archive --prefix=bart-0.2.09d/ -o bart_0.2.09d.tar.gz v0.2.09d
sha256sum v0.2.09d.tar.gz bart_0.2.09d.tar.gz 
35879d41dcdefedc9fbca40267490d055e3a4840d7731a0f221c6976035dfff0  
v0.2.09d.tar.gz
35879d41dcdefedc9fbca40267490d055e3a4840d7731a0f221c6976035dfff0  
bart_0.2.09d.tar.gz

> This is the role of the pristine-tar branch
> and currently I can not build bart by the following procedure:
> 
> 
>ssh://git.debian.org/git/debian-med/bart.git
>cd bart
>gbp buildpackage

The following works for me:

git clone ssh://uecker-gu...@git.debian.org/git/debian-med/bart.git
cd bart
gbp buildpackage --git-upstream-tag=v0.2.09d --git-pbuilder

Also the following should also work correctly:

git clone ssh://uecker-gu...@git.debian.org/git/debian-med/bart.git
cd bart
pristine-tar checkout ../bart_0.2.09.orig.tar.gz
dpkg-buildpackage 


The only issue is that I have to specify the tag with 'gdb'
because it looks for 'upstream/v0.2.09' which does not
currently exist. Instead of adding these tags, I would prefer
to reconfigure 'gdb' to use the existing upstream tags without
the prefix 'upstream/'. Then I could just push the regular
upstream tags. Would this be ok?


I also created a newer upstream tag v0.2.09d specifically
for the initial packaging work because I made some upstream
changes to make packaging easier.  The bart_0.2.09.orig.tar.gz 
which is now in the pristine-tar branch actually corresonds
to v0.2.09d.  I hope that is not too messed up, but with the
next upstream version (to be released soon) this hack would 
gone.


Martin