Re: bart upload

[Uecker, Martin]

Hi Andreas,

Am Sonntag, den 01.05.2022, 21:12 +0200 schrieb Andreas Tille:
> Hi Martin,
> 
> Am Sun, May 01, 2022 at 04:46:43PM + schrieb Uecker, Martin:
> > it seems the octave upgrade is held back because of
> > some spurious error message in the BART autopkgtest.
> > 
> > This is a bug in octave, but I added the workaround
> > suggested in the bug report.
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010164
> > 
> > Please upload of you think this makes sense.
> 
> Uploaded.  Thanks a lot for your preparation

Thank you for uploading.

There is also some issue with the nvidia-cuda-toolkit

https://tracker.debian.org/pkg/bart-cuda

I guess we only need to re-upload once nvidia-cuda-toolkit
is updated?

BTW: The next version of BART will include a complete
machine learning framework (not relying on Tensorflow
or Pytorch). Maybe this is interesting also to others.

Martin


>   Andreas. 
> 

bart upload

[Uecker, Martin]

Hi all,

it seems the octave upgrade is held back because of
some spurious error message in the BART autopkgtest.

This is a bug in octave, but I added the workaround
suggested in the bug report.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010164

Please upload of you think this makes sense.

Thank you!

Martin

Re: bart-cuda fails its autopkgtest (Was: Re: bart: version 0.7.00)

[Uecker, Martin]

Am Freitag, den 31.12.2021, 18:29 +0530 schrieb Nilesh Patra:
> On 12/31/21 6:05 PM, Uecker, Martin wrote:
> > Am Freitag, den 31.12.2021, 17:13 +0530 schrieb Nilesh Patra:
> > > On 12/30/21 12:47 PM, Uecker, Martin wrote:
> > > > Also the identical bart-cuda package (in master-contrib)
> > > > fails to build on salsa because it says the
> > > > nvidia-cuda-toolkit  is uninstallable. But I guess one
> > > > could give it a try.
> > > 
> > > Martin, bart-cuda fails its (last) autopkgtest stalling testing 
> > > migration, see here[1]
> > > Can you fix this?
> > > 
> > > [1]: https://qa.debian.org/excuses.php?package=bart-cuda
> > 
> > Yes, it was running the tests for the bart package but then
> > the older version of the package was still installed and
> > the test failed. I pushed a fix.
> 
> Thanks!
> 
> > But I am still
> > pondering why it is not fully reproducible
> 
> You could try running reprotest on it once, and check the diffoscope log for 
> hints.
> The build-ID was different, most likely a build path issue.
>   
> > Thanks again for your help!  Can I do something to make
> > this easier?  For bart-cuda  I think it is is Ok to
> > only upload for amd64.  But it would be good if we
> > could extend the CI pipeline on salsa to test
> > beforehand.
> 
> Yeah, right. I think we will need to talk to salsa CI team about this, by 
> opening an issue
> ticket here[1] asking to enable pipeline also for contrib/non-free
> 
> [1]: https://salsa.debian.org/salsa-ci-team/pipeline

It seems we can activiate this ourselves. I just tried this.

Martin

Re: bart-cuda fails its autopkgtest (Was: Re: bart: version 0.7.00)

[Uecker, Martin]

Am Freitag, den 31.12.2021, 23:52 +0530 schrieb Nilesh Patra:
> On 12/31/21 6:05 PM, Uecker, Martin wrote:
> > Yes, it was running the tests for the bart package but then
> > the older version of the package was still installed and
> > the test failed. I pushed a fix.  But I am still
> > pondering why it is not fully reproducible
> 
> Looks like I misunderstood your earlier email, sorry about that.
> I believe you are talking about

I was talking about deterministic builds on Debian.
This new issue was also a surprise to me...

> > $ /usr/bin/bart version
> > WARN: BART version is not reproducible.
> > v0.7.00-168-gc3bb89e-dirty
> 
> I am not sure why that's the case either. Can we ignore this test for now?
> It does not look critical, since the package otherwise looks usable.

The issue is that if you built locally it seems it picked
up the git version and not the one in version.txt.  This
does not happen when building using pbuilder.

But it should not take the git version but the one in
version.txt, so the test is correct to fail. I pushed
a fix for this.

I see you uploaded already. Can you do it again? Sorry
for the trouble... (for reproducible science having the
clean version string is important)

Martin

Re: bart-cuda fails its autopkgtest (Was: Re: bart: version 0.7.00)

[Uecker, Martin]

Am Freitag, den 31.12.2021, 17:13 +0530 schrieb Nilesh Patra:
> On 12/30/21 12:47 PM, Uecker, Martin wrote:
> > Also the identical bart-cuda package (in master-contrib)
> > fails to build on salsa because it says the
> > nvidia-cuda-toolkit  is uninstallable. But I guess one
> > could give it a try.
> 
> Martin, bart-cuda fails its (last) autopkgtest stalling testing migration, 
> see here[1]
> Can you fix this?
> 
> [1]: https://qa.debian.org/excuses.php?package=bart-cuda

Yes, it was running the tests for the bart package but then
the older version of the package was still installed and
the test failed. I pushed a fix.  But I am still
pondering why it is not fully reproducible

Thanks again for your help!  Can I do something to make
this easier?  For bart-cuda  I think it is is Ok to
only upload for amd64.  But it would be good if we
could extend the CI pipeline on salsa to test 
beforehand.

Martin

Re: bart: version 0.7.00

[Uecker, Martin]

Am Donnerstag, den 30.12.2021, 09:58 +0100 schrieb Andreas Tille:
> Am Thu, Dec 30, 2021 at 02:01:32PM +0530 schrieb Nilesh Patra:
> > Uploaded, thanks for your work!
> 
> Thanks to you both.

Thanks Nilesh!

Unfortunately, this needs another round.  Armel and s390x
need another change for the same compiler issue.  I also
figured out how to make the crossbuilds work, which should
make testing these things much easier. Also made some
other tweaks.

For bart-cuda, I also merged these changes and fixed
the changelog.  But I am not sure this solves the
issue with the nvidia-cuda-toolkit dependency (locally
this works for me with cowbuilder)

Martin

> > > Also the identical bart-cuda package (in master-contrib)
> > > fails to build on salsa because it says the
> > > nvidia-cuda-toolkit  is uninstallable.
> > > could give it a try.
> 
> IMHO Salca-CI does not include non-free in sources.list so
> this is bound to fail.
> 
> Kind regards
> 
>  Andreas.
> 

Re: bart: version 0.7.00

[Uecker, Martin]

Am Dienstag, den 26.10.2021, 18:06 +0200 schrieb Martin Uecker:
> Hi Andreas,
> 
> I pushed changes for a the version of bart. Maybe you could
> take a look?  There are some failures in the CI on salsa.
> 
> The i386 build triggers a compiler crash. I will try to
> look into this later (I am a GCC contributor myself), but
> this is a compiler problem.
> 
> The other failures may be related to the build environment
> not being up-to-date.

I added a workaround for the compiler crash, and also
added code to run the test suite as autopkgtest, and
made some other changes. From my side, this seems good
for uploading.

The reproduction test on salsa still fails for reasons
I do not understand. 

Also the identical bart-cuda package (in master-contrib)
fails to build on salsa because it says the
nvidia-cuda-toolkit  is uninstallable. But I guess one
could give it a try.

Martin

Re: bart: version 0.7.00

[Uecker, Martin]

Hi Andreas,

Am Mittwoch, den 27.10.2021, 08:13 +0200 schrieb Andreas Tille:
> Hi Martin,
> 
> Am Tue, Oct 26, 2021 at 04:06:46PM + schrieb Uecker, Martin:
> > I pushed changes for a the version of bart. Maybe you could
> > take a look?  There are some failures in the CI on salsa.
> 
> I get
> 
> The following packages have unmet dependencies:
>  libpetsc-real3.14 : Depends: libhypre (< 2.18.3) but 2.22.1-3 is to be 
> installed
> 
> in autopkgtest in my pbuilder environment.

Yes, this is not something BART explicitely depends on
but this is somehow pulled in in a different way.

> > The i386 build triggers a compiler crash. I will try to
> > look into this later (I am a GCC contributor myself), but
> > this is a compiler problem.
> > 
> > The other failures may be related to the build environment
> > not being up-to-date.
> 
> May be that is the case but for this week I have no free cycles to check this.

No problem. It is not urgent.

Martin

bart: version 0.7.00

[Uecker, Martin]

Hi Andreas,

I pushed changes for a the version of bart. Maybe you could
take a look?  There are some failures in the CI on salsa.

The i386 build triggers a compiler crash. I will try to
look into this later (I am a GCC contributor myself), but
this is a compiler problem.

The other failures may be related to the build environment
not being up-to-date.

Martin

Re: GPU support in BART

[Uecker, Martin]

Hi Andreas,
Hi all,

did you have time to look at this? Or can someone
else help?

This is not urgent, just making sure this did not 
get lost. Any help/advise is much appreciated.


Best,
Martin



Am Samstag, den 19.12.2020, 15:17 +0100 schrieb Martin Uecker:
> Hi Andreas,
> 
> I added a master-contrib branch which contains a
> bart-cuda package which is identical to bart
> except it activates cuda support in the bart
> binary.
> 
> I am not sure about the control file. I added
> 
> Provides: bart
> Conflicts: bart
> Replaces: bart
> 
> but I am not so sure whether this is correct.
> 
> 
> Best.
> Martin
> 
> 
> 
> 
> Am Mittwoch, den 16.12.2020, 08:54 +0100 schrieb Martin Uecker:
> > 
> > Hi all,
> > 
> > I want to activate GPU support in the Debian package
> > for the BART toolbox, but I am not sure what is the 
> > best way to approach this.
> > 
> > There may be several options:
> > 
> > We can provide an additional package which can be
> > installed alternatively, e.g. bart-gpu and which
> > provides a CUDA-enabled binary and conflicts with
> > the regular package.  But I wonder whether this would
> > make all bart packages non-free?  Or do we need
> > two separate source packages? 
> > 
> > 
> > Maybe there is a way to compile and link
> > against CUDA with requiring the presence of the
> > dynamic library of run-time.  We could then
> > dlopen the library at run-time if it is
> > present. But the compilation would then
> > still depend on a non-free package.
> > 
> > 
> > We could try to move GPU backend into a module
> > which can be loaded at run-time and which is
> > then packaged separately. But this would 
> > require some development effort.
> > 
> > 
> > Maybe you have some recommendations? Or you can
> > recommend a package to look at as an example?
> > 
> > Best,
> > Martin

Re: GPU support in BART

[Uecker, Martin]

Hi Andreas,

I added a master-contrib branch which contains a
bart-cuda package which is identical to bart
except it activates cuda support in the bart
binary.

I am not sure about the control file. I added

Provides: bart
Conflicts: bart
Replaces: bart

but I am not so sure whether this is correct.


Best.
Martin




Am Mittwoch, den 16.12.2020, 08:54 +0100 schrieb Martin Uecker:
> 
> Hi all,
> 
> I want to activate GPU support in the Debian package
> for the BART toolbox, but I am not sure what is the 
> best way to approach this.
> 
> There may be several options:
> 
> We can provide an additional package which can be
> installed alternatively, e.g. bart-gpu and which
> provides a CUDA-enabled binary and conflicts with
> the regular package.  But I wonder whether this would
> make all bart packages non-free?  Or do we need
> two separate source packages? 
> 
> 
> Maybe there is a way to compile and link
> against CUDA with requiring the presence of the
> dynamic library of run-time.  We could then
> dlopen the library at run-time if it is
> present. But the compilation would then
> still depend on a non-free package.
> 
> 
> We could try to move GPU backend into a module
> which can be loaded at run-time and which is
> then packaged separately. But this would 
> require some development effort.
> 
> 
> Maybe you have some recommendations? Or you can
> recommend a package to look at as an example?
> 
> Best,
> Martin

GPU support in BART

[Uecker, Martin]

Hi all,

I want to activate GPU support in the Debian package
for the BART toolbox, but I am not sure what is the 
best way to approach this.

There may be several options:

We can provide an additional package which can be
installed alternatively, e.g. bart-gpu and which
provides a CUDA-enabled binary and conflicts with
the regular package.  But I wonder whether this would
make all bart packages non-free?  Or do we need
two separate source packages? 


Maybe there is a way to compile and link
against CUDA with requiring the presence of the
dynamic library of run-time.  We could then
dlopen the library at run-time if it is
present. But the compilation would then
still depend on a non-free package.


We could try to move GPU backend into a module
which can be loaded at run-time and which is
then packaged separately. But this would 
require some development effort.


Maybe you have some recommendations? Or you can
recommend a package to look at as an example?

Best,
Martin

bart: version 0.6.00

[Uecker, Martin]

Hi Andreas and Debian med team,

there is a new upstream version of BART 0.6.00 and
I have updated the Debian package and pushed the
changes.

Can you please take a look and sponsor the upload?


Christin (CC) will help with Debian packaging
in the future. I guess the Debian med policy is good
place for him to start?

https://med-team.pages.debian.net/policy/


Things we want to improve with respect to
packaging in the future:

- CUDA support (not sure how this works in Debian
also because it is non-free)

- autopkgtest and CI 

- ismrmrd integration


Best,
Martin

bart: version 0.5.00

[Uecker, Martin]

Hi Andreas,

there is no version of BART. Can you
please upload?

Best,
Martin

Re: Re: bart: version 0.4.04

[Uecker, Martin]

> On Wed, Dec 12, 2018 at 12:28:44PM +0000, Uecker, Martin wrote:
> > >On Tue, Dec 11, 2018 at 09:52:07PM +0000, Uecker, Martin wrote:
> > > Feel free to decide what solution you prefer with this additional
> > > information and tell me what you want me to sponsor.
> > 
> > Then let's keep it like it is and if it works on all architectures
> > and no other problems appear in the next week, I  would appreciate 
> > if could then upload to strech-backports.
>
> OK.  Uploading to backports is easy and I can happily do this.
>  
> > I the mean time, I will see how one can request access to systems
> >  with some of the problematic architectures...
>
> Should I upload the current state in Git and you watch the architectures
> based on the latest changes or do you want me to wait until you have
> sorted out those issues?

Please upload the current state. (I also added another simple
autopkgtest and I would like to confirm that it works. Locally,
it does.)

Best,
Martin

Re: bart: version 0.4.04

[Uecker, Martin]

>On Tue, Dec 11, 2018 at 09:52:07PM +0000, Uecker, Martin wrote:
> > 
> > I have another question: Would it be ok to use a dependency
> > on debhelper (>=10) instead of (>=11~) ? Then the package
> > could be build on stable without changes.
>
> There is no strict reason to enforce debhelper 11 - I'm just
> in favour of using the latest debhelper version if there is no
> good reason to pick an older one.
>
> BTW, I'm *intentionally* using 11~ since the tilde works for Stretch
> backports.  Debhelper 11 is in stretch backports and if you want to
> provide bart also on stable systems I'd recommend to do an official
> backport (just ping me if the version you prefer has hit testing and
> I'll do an upload to stretch-backports).
>
> Feel free to decide what solution you prefer with this additional
> information and tell me what you want me to sponsor.

Then let's keep it like it is and if it works on all architectures
and no other problems appear in the next week, I  would appreciate 
if could then upload to strech-backports.

I the mean time, I will see how one can request access to systems
with some of the problematic architectures...

Best,
Martin

Re: bart: version 0.4.04

[Uecker, Martin]

I have another question: Would it be ok to use a dependency
on debhelper (>=10) instead of (>=11~) ? Then the package
could be build on stable without changes.

Best,
Martin

Am Dienstag, den 11.12.2018, 22:43 +0100 schrieb Martin Uecker:
> Thank you Andreas!
> 
> I had to include some bug fixes and also turned off some
> unit tests because of build failures on some archs.
> Can I ask for another upload?
> 
> The failing unit tests should not affect any functionality
> currently exposed to the user. Still, it would be better
> to be able to investigate this further. Is there a way
> to get access to machines using these architectures?
> 
> Best,
> Martin
> 
> 
> Am Montag, den 10.12.2018, 16:21 +0100 schrieb Martin Uecker:
> > Dear all,
> > 
> > I prepared the new upstream version 0.4.04 of bart for upload.
> > 
> > Can somebody please upload? Thank you!
> > 
> > Best,
> > Martin

Re: bart: version 0.4.04

[Uecker, Martin]

Thank you Andreas!

I had to include some bug fixes and also turned off some
unit tests because of build failures on some archs.
Can I ask for another upload?

The failing unit tests should not affect any functionality
currently exposed to the user. Still, it would be better
to be able to investigate this further. Is there a way
to get access to machines using these architectures?

Best,
Martin


Am Montag, den 10.12.2018, 16:21 +0100 schrieb Martin Uecker:
> Dear all,
> 
> I prepared the new upstream version 0.4.04 of bart for upload.
> 
> Can somebody please upload? Thank you!
> 
> Best,
> Martin

bart: version 0.4.04

[Uecker, Martin]

Dear all,

I prepared the new upstream version 0.4.04 of bart for upload.

Can somebody please upload? Thank you!

Best,
Martin

Re: bart version 0.4.03

[Uecker, Martin]

Fixed. Ready to be uploaded I think.

Best,
Martin

Am Samstag, den 28.04.2018, 21:14 +0200 schrieb Martin Uecker:
> except I broke something again... Let me fix this first.
> 
> Martin
> 
> Am Samstag, den 28.04.2018, 21:10 +0200 schrieb Martin Uecker:
> > Hi Andreas,
> > 
> > I have upgraded the BART package to the latest upstream version.
> > Can you please upload?
> > 
> > Thank you!
> > Martin

Re: bart version 0.4.03

[Uecker, Martin]

except I broke something again... Let me fix this first.

Martin

Am Samstag, den 28.04.2018, 21:10 +0200 schrieb Martin Uecker:
> Hi Andreas,
> 
> I have upgraded the BART package to the latest upstream version.
> Can you please upload?
> 
> Thank you!
> Martin

bart version 0.4.03

[Uecker, Martin]

Hi Andreas,

I have upgraded the BART package to the latest upstream version.
Can you please upload?

Thank you!
Martin

packaging of bart-view

[Uecker, Martin]

Hi Andreas,

if you have time, I would appreciate if you could take a look at
my packaging of bart-view, which is an additional image
viewer component for BART. Lintian seems happy and it builds
using

$ gbp buildpackage --git-pbuilderbuilds using


thank you!
Martin 

Re: bart version 0.4.02

[Uecker, Martin]

Hi Andreas,

Andreas Tille wrote:
On Tue, Nov 28, 2017 at 02:09:19PM +, Uecker, Martin wrote:
> > thank you for uploading. Some of the (new) unit tests fail
> > on some architectures. As these are tests which do not
> > indicate problems for functionality currently exposed to
> > the user and because the cause seems to be some minor
> > differences in floating point processing, I simply turned 
> > them off for now.
>
> "For now" means you plan to fix this in future releases?
 
Yes, but I need to figure out how to debug this using qemu
first and I don't think it is worth delaying the release.

...
> While I have no idea about the importance of the tests at least the
> description of the change seems missleading.  It reads as if a subset
> of the tests would have been switched off for some architectures but
> the change looks like all tests are disabled for those
> architectures. 

This is what I planned to do, but then decided it is not worth
the trouble. I have changed the misleading changelog.

> If this is the only sensible solution for the moment I can upload
> this change but it would be nice to have full featured testing back
> in the future.

I would appreciate it. I will fix this properly later.

> BTW, if you are running some build time tests would you consider more
> sophisticated autopkgtest than just running `bart --version`?

Absolutely! We have a fairly big test suite which I plan to use
for autopkgtest as well, but because I don't have any experience
with it I thought it might be prudent to start small. 

Best,
Martin

Re: bart version 0.4.02

[Uecker, Martin]

bart version 0.4.02

[Uecker, Martin]

Hi Andreas,

I have upgraded the BART package to the latest upstream version.

Can you take a quick look if everything looks OK and
upload the new version?

Thank you!
Martin

Bug#851431: ITP: bart-view -- Image viewer for multi-dimensional data (add-on to BART)

[Uecker, Martin]

Package: wnpp
Severity: wishlist
Owner: Martin Uecker 

* Package name: bart-view
  Version : 0.0.01
  Upstream Author : Martin Uecker 
* URL : https://github.com/mrirecon/view/
* License : BSD
  Programming Lang: C
  Description : Image viewer for multi-dimensional data (add-on to BART)

This is a viewer for multi-dimensional complex-valued
data. It is useful as an add-on to the Berkeley Advanced
Reconstruction Toolbox (BART) for computational Magnetic
Resonance Imaging which has been packaged for Debian
already. This package will be maintained as part of
the Debian Med team.

Re: Will you prepare update to bart 0.4.00

[Uecker, Martin]

Hi Andreas,

I updated the git repo to the new version. 


Thank you for sponsering!
Martin


Am Samstag, den 14.01.2017, 08:34 +0100 schrieb Andreas Tille:
> Hi Martin,
> 
> I noticed that there is a new release of bart.  It might make sense to
> upload it as quick as possible to make it into testing soon.  I'm at
> your service at Debian Med sprint for sponsering.
> 
> Kind regards
> 
>   Andreas.
> 

Re: Open-source MRI hardware initiative project

[Uecker, Martin]

Hi Lionel,

let me also add some comments from my side. I am a physicist working
on MRI - mostly on image reconstruction algorithms and real-time MRI.
We released an image reconstruction platform developed at UC Berkeley
as an open-source project: https://mrirecon.github.io/bart/


> I am a researcher in MRI hardware at the University of Aberdeen,
> Scotland. I am currently working on the development of a completely new
> type of MRI system (see ffc-mri.org), but I would like to avoid the
> traditional route of commercialisation as I see many problems with it.
> Instead, I have been thinking for a while of preparing an initiative for
> the development of open-source hardware in MRI.

An open-source hardware platform for MRI would be nice - even if it
is only useful for research and educational purposes.


> The aim of this initiative would be, in a first stage, to pool the
> technical solutions already in the public domain together so as to help
> small research labs like mine and, in a second stage, to create a rally
> point for these labs to share knowledge, resources and to organise
> collective work. If this proves successful, it may expand into a
> complete open source MRI hardware platform but that would be in the far
> future. I already approached several research groups who expressed their
> enthusiasm about this idea so there would be several academic
> participants to start with (at least 3, probably 5 to 8), and some of
> them are already willing to provide some designs.

Sounds good. Just do it!

> I would like to get some advices from the Debian Med community regarding
> several aspects:
> - What solution would you think is the most appropriate to organise a
> community portal? I do not have any IT help from my University on this
> project but I am willing to put a bit of my own money to get a server
> somewhere if necessary. Bear in mind that I have little training on how
> to maintain a website, though I can take some time to learn.

My recommendation would be: Have a wiki and an open mailing list 
with public archive. If you have more time you can design a nice
website. Hosting a website is really cheap and for scientific projects
it is usually possible to have the university host it somewhere, but
there are also sites such as github etc. where you can have a
website/wiki and host schematics for free.


> - I know there is an active part of Debian Med that works on MRI
> software (and make great things, actually!), would any of them be
> interested in this initiative?
> If yes, what would you expect from it, or
> what would you be willing to provide at this stage?

I can't offer much help as I am currently not doing any
work on MRI hardware. But I think it is interesting...


> Also, would you have
> some recommendations so that open-sourced MRI hardware would easily
> interface with the already existing open-source software?

Consider supporting the ISMRM raw data format which is a vendor-neutral
format for MRI data. If this is too much work or does not support
your use-case, you can also create your own data formats and APIs. If
you do something simple which is well-documented, there should be no
problem supporting it from the software-side. I can help with this.
Obviously, try not to use proprietary software to control the hardware.


> - Would you have any suggestions regarding the conduct of such a
> project? I have no experience in the management of open source projects
> and I am actively looking for documentation about it. In particular, how
> can I organise this project so as to avoid bottlenecks in the future?

Don't worry about this. Put as much useful stuff as possible online
and create open channels for communication, e.g. a mailing list 
or a forum. Then see what happens. At least initially, I would not
expect a lot of contributions from outsiders anyway.


> - Can you see any funding bodies that could be interested in this
> initiative, in the short to medium term?

Why not? Funding agencies fund all sorts of things. One could
argue that the utility of a research grant is maximized if
schematics etc are made open-source.


> - Do you know of organisations that would be interested to know of this
> project or to provide guidance? I already plan to contact OSHWA and the
> CERN Open Hardware Repository, but I am sure there would be others who
> can help.

Maybe also the ISMRM? At least for software, there is some interest
in sharing:  http://www.ismrm.org/MR-Hub/


> - Where can I advertise this project efficiently? I am currently
> thinking about FOSDEM, if this sounds reasonable.

Advertise at workshops and conferences in your field.

> That is all for the questions for now. Thanks for taking the time to
> read this, and congratulations to you all for the great work you do to
> maintain and develop the Debian Med project!
> 
> Lionel

Martin

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

[Uecker, Martin]

Hi Andreas and Ghislain,

the bart package now produces a -dev package and a
octave-bart package. It also includes a bash completion
script. pristine-tar produces the correct upstream
tar ball.

I would appreciate if you could take a look and let
me know what else could be improved...

Also I wonder whether there is a way to build and
test the package on other architectures than amd64?

Season's greetings,
Martin




Ghislain Vaillant:
> 
> On 07/12/15 08:18, Uecker, Martin wrote:
> >
> > Hi Andreas,
> >
> >> 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.
> 
> Actually, you can do it with `gbp buildpackage` by passing the 
> --git-no-pristine-tar and --git-pristine-tar-commit, which effectively 
> will produce the pristine tarball from the tag you based your packaging off.
> 
> Andreas gave you the general guideline which works for any source. The 
> --git*pristine-tar* options only work if you are using the upstream git 
> repository.
> 
> FYI, make sure you have a valid watch file (although you are not using 
> uscan), because that is also what is used by the Debian Package Tracking 
> System to signal when new upstream releases are available.
> 
> >> You could add these in additional python-bart octave-bart binary
> >> packages (sorry, matlab can not be provided as official Debian package).
> >> You should read the according pages at wiki.debian.org where to put
> >> Python modules (or you just check your local system where these are
> >> stored) and Octave files (I never dealt with these but I guess there is
> >> a wiki paga as well).  Feel free to ask me if you are struck in the
> >> jungle of documentation and I'll provide more specific pointers.
> >
> > Ok, I have to look at it. There are only very few small scripts,
> > so I would rather put it in the same package.
> >
> >> Another remark to the packaging:  Currently there is a libgsl migration
> >> ongoing and you should use libgsl-dev instead of libgsl0-dev.
> >
> > Done. Although now it doesn't build locally on my Ubuntu machine
> > anymore (only using pbuilder in a sid change root).
> 
> You could use something like libgsl0-dev | libgsl-dev to stay compatible 
> with earlier versions?
> 
> Ghis

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

[Uecker, Martin]

Hi Andreas,

> On Sun, Dec 06, 2015 at 11:59:02PM +0000, 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. 
 

> > gbp can also create tar balls from the same tag and check
> > in ione step, but somehow the hash does not seem to match
> > exactly (the content does). I wonder why...
> 
> You stumbled upon the very problem pristine-tar is solving:  Tarballs
> simply have different checksums even if featuring identical content.
> This is for instance due to different time stamps, user ids etc after
> unpackaging on a target system.  Feel free to seek Debian lists for
> several discussions explaining the problem.

I already know ;-) I am (in)famous for starting a flamewar on
debian-devel about reproducible builds in 2007...


> You could add these in additional python-bart octave-bart binary
> packages (sorry, matlab can not be provided as official Debian package).
> You should read the according pages at wiki.debian.org where to put
> Python modules (or you just check your local system where these are
> stored) and Octave files (I never dealt with these but I guess there is
> a wiki paga as well).  Feel free to ask me if you are struck in the
> jungle of documentation and I'll provide more specific pointers.

Ok, I have to look at it. There are only very few small scripts, 
so I would rather put it in the same package.

> Another remark to the packaging:  Currently there is a libgsl migration
> ongoing and you should use libgsl-dev instead of libgsl0-dev.

Done. Although now it doesn't build locally on my Ubuntu machine
anymore (only using pbuilder in a sid change root).

Martin

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

[Uecker, Martin]

Hi Andreas,

> > 
> > Ok, I put it in /git/debian-med/bart.git as described in the
> > debian-med policy.
> 
> I checked this out and added Vcs fields and Homepage to Debian control
> (please pull).  I noticed that the pristine-tar branch is missing in the
> git repository.  You can get this easily by redoing
> 
> gbp import-orig --pristine-tar your_orig_tar_gz
> 
> (just make sure you use the --pristine-tar option) and push the
> pristine-tar branch.  The rationale is that we can both easily work
> on a byte identical tarball right from the Git archive.

Ok, what is the deal with pristine-tar? Our upstream tar balls are
generated by github using git-archive. So there does not seem to
be any point to create tar balls just to re-import them using 
pristine-tar, or is there?

> I assume that the debian/control file is missing other Build-Depends
> than just debhelper.  

Yep. I added some. It builds using git-pbuilder.

> I'd also recommend to use
> 
> cme fix dpkg-control
> 
> which would bump your Standards-Version to 3.9.6 (which you can also do
> manually but cme is a nifty tool I'd like to introduce to newcomers).

My experience so far: It pulls in a million of perl packages, then I had to 
figure out that I still have to install an extra package for dpkg-control 
to work, then it complains that it doesn't know libpng-dev, but if I replace
it with libpng12-dev fixes it to be libpng-dev again. It also spits out a 
lot of incomprehensible warnings about the VCS-* lines. It didn't bump
the standards version, but decides to do some arbitrary reformatting ;-)

Martin

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

[Uecker, Martin]

Am Sonntag, den 06.12.2015, 13:57 + schrieb Ghislain Vaillant:
> 
> On 06/12/15 12:32, Uecker, Martin wrote:
> > Hi Andreas,
> >
> >>> Ok, I put it in /git/debian-med/bart.git as described in the
> >>> debian-med policy.
> >> I checked this out and added Vcs fields and Homepage to Debian control
> >> (please pull).  I noticed that the pristine-tar branch is missing in the
> >> git repository.  You can get this easily by redoing
> >>
> >>  gbp import-orig --pristine-tar your_orig_tar_gz
> >>
> >> (just make sure you use the --pristine-tar option) and push the
> >> pristine-tar branch.  The rationale is that we can both easily work
> >> on a byte identical tarball right from the Git archive.
> > Ok, what is the deal with pristine-tar? Our upstream tar balls are
> > generated by github using git-archive. So there does not seem to
> > be any point to create tar balls just to re-import them using
> > pristine-tar, or is there?
> 
> 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.

gbp can also create tar balls from the same tag and check
in ione step, but somehow the hash does not seem to match
exactly (the content does). I wonder why...


...
> Running licensecheck on the source tree revealed a few files which have 
> missing copyright headers:

...
> Which you may or may not want to act upon. Since the other source files 
> have one it might be picked up during the review process anyway.

I don't see a reason to change this if it isn't necessary. 

> Otherwise, looks good.
> 
> Quick question, is the package supposed to install just the bart 
> executable and its accompanying documentation or something else in 
> addition ?

I also want to add octave/matlab/python scripts. But I am not
sure where to put them. I would be nice if there was a way to
add them to the default search path for octave/matlab, for
example.

Martin

Re: bart - tools for computational magnetic resonance imaging

[Uecker, Martin]

Am Dienstag, den 01.12.2015, 15:16 + schrieb Ghislain Vaillant:
> On 01/12/15 15:04, Uecker, Martin wrote:
> > Ghislain Vaillant:
> >
> >>
> >> Hi Martin,
> >>
> >> Let me know if you need assistance on the packaging side.
> >>
> >> Glad to see more MRI reconstruction software being packaged for Debian.
> >>
> >> Cheers,
> >>
> >> Ghis
> >
> >
> > Thank you, Ghis!
> >
> > I am sure that I will need some help. I see that you have already
> > packaged the ismrmrd library (which we aim to properly support at
> > some point in BART).
> 
> Indeed. Still need to find time for Gadgetron as well, but it is a much 
> bigger piece of work ^^.
> 
> Nice to hear you are planning to support ISMRMRD. FYI, Michael's team is 
> currently working on the next major release (2.x), so I would suggest to 
> wait a bit. Your call.

I will wait. I made that mistake before... 

> I can set the packaging repository up on d-med and push your initial 
> work to it if you like. That would make collaborative work with members 
> of d-med much easier, myself included.

So I tried to do it myself. See my mail to Andreas.

Martin

Re: bart - tools for computational magnetic resonance imaging

[Uecker, Martin]

Hi Andreas,

Andreas Tille:
> Hi Martin,
> 
> On Tue, Dec 01, 2015 at 03:00:25PM +0000, Uecker, Martin wrote:
> > thank you for your answer!
> 
> You are welcome. :-)
>  
> > Andreas Tille:
> > > I have not yet checked out this and before I do I would like to suggest
> > > that you move the actual Debian packaging to git.debian.org where all
> > > our packaging code resides.  This as several advantages (if interested
> > > I could list them - one example would be that your work could be listed
> > > on our imaging page[1] even in this stage).
> > 
> > Ok, I created an account and applied for debian-med membership.
> 
> Accepted.
>  
> > > My suggestion would be that you check out our team policy[2] that
> > > explains how to maintain a package in our packaging Git.  Since we have
> > > also a mentoring program called Mentoring of the Month[3] and there is a
> > > free slot for December I wonder whether you like to become a MoM
> > > student.  Considering that you are obviously comfortable with gbp I'm
> > > quite positive that we will succeede in way less than a month.
> > > 
> > > What to you think about this?
> > 
> > Sounds good. I am fairly busy though, so I am not sure how well
> > the mentoring would work -  there will be times where I am not 
> > going to be able to respond at all. But I will try to spend some
> > time packaging this project, and could certainly use a
> > lot of advise. 
> 
> Thanks for letting me know.  Please try at least to get ssh access 
> 
>  ssh git.debian.org
> 
> via ssh key and commit the repository.  I'll check what changes might be
> needed and let you know.  The MoM project is in the first place to lower
> the barrier for asking questions the student might be afraid about to be
> qualified as "stupid".  Just feel free to ask anything you wonder about
> since I do not remember any stupid question here. ;-)

Ok, I put it in /git/debian-med/bart.git as described in the
debian-med policy.

Martin

Re: bart - tools for computational magnetic resonance imaging

[Uecker, Martin]

Ghislain Vaillant:

> 
> Hi Martin,
> 
> Let me know if you need assistance on the packaging side.
> 
> Glad to see more MRI reconstruction software being packaged for Debian.
> 
> Cheers,
> 
> Ghis


Thank you, Ghis!

I am sure that I will need some help. I see that you have already
packaged the ismrmrd library (which we aim to properly support at
some point in BART).

Martin

Re: bart - tools for computational magnetic resonance imaging

[Uecker, Martin]

Hi Andreas,

thank you for your answer!


Andreas Tille:
> I have not yet checked out this and before I do I would like to suggest
> that you move the actual Debian packaging to git.debian.org where all
> our packaging code resides.  This as several advantages (if interested
> I could list them - one example would be that your work could be listed
> on our imaging page[1] even in this stage).

Ok, I created an account and applied for debian-med membership.


> My suggestion would be that you check out our team policy[2] that
> explains how to maintain a package in our packaging Git.  Since we have
> also a mentoring program called Mentoring of the Month[3] and there is a
> free slot for December I wonder whether you like to become a MoM
> student.  Considering that you are obviously comfortable with gbp I'm
> quite positive that we will succeede in way less than a month.
> 
> What to you think about this?

Sounds good. I am fairly busy though, so I am not sure how well
the mentoring would work -  there will be times where I am not 
going to be able to respond at all. But I will try to spend some
time packaging this project, and could certainly use a
lot of advise. 

Martin



> Kind regards
> 
>  Andreas.
> 
> 
> [1] http://blends.debian.org/med/tasks/imaging#pkgvcs-debs
> [2] http://debian-med.alioth.debian.org/docs/policy.html
> [3] https://wiki.debian.org/DebianMed/MoM
> 

bart - tools for computational magnetic resonance imaging

[Uecker, Martin]

Hi all,

I would love to see our image reconstruction software
for magnetic resonance imaging included in Debian.

I filed an ITP with more information here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806762

The source code is on Github:

https://github.com/mrirecon/bart

I already added a debian branch with the debian control 
files. Using gbp I can build a package with:

gbp buildpackage  --git-debian-branch=debian --git-upstream-tree=master

but it probably needs more work... and a sponsor.


Martin