[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MoM] CamiTK packaging first part



Sounds good so far.  I have spotted some lintian info which is not
dramatically but I stumbled the first time about it (you need
`lintian -I`)

I: libcamitk3-data: duplicated-compressed-file
usr/share/camitk-3.0/testdata/BigEndianCompressed.img.gz N: N:
The given, apparently compressed, file is shipped in the package in
N: addition to another file with the same name without the N:
compression-method extension. Normally this indicates a mistake in
the N:    installation process of the package.

I've checked that it is just a small file but wanted to make you
aware about this.
I just asked the developer of the itkimage extension about it. I will
let you know if this is a normal or not (I seemed to remember we needed
the .gz for test reason - the extension should be able to open both, but
I am not sure)

I also added some code upstream to be able to quickly diagnose the
 installation state (camitk-imp --config). That should also
simplify/help bug reports.

Sounds like a really good idea.
It has been already used today by one of the user!

If you would consider to remove it make sure the actual changes will
be taken over to 3.0.7-1.  Alternatively you might like to use
UNRELEASED (instead of unstable) as target distribution.  As per
Debian Med policy document you should in principle also do it for
the not yet uploaded 3.0.7-1 as well as long as it is not uploaded
(you might leave it to your sponsor to change from UNRELEASED to
unstable in the future.)
Ok. I just modified both entries as UNRELEASED (policy are to be respected!)

From my perspective the package looks fine and I would consider
uploading it.
Here I have another question: as in about a week (or two), there should be a new upstream release available (without much changes, and if everything goes according to plan!). The question is should we wait for that? Is it a problem to have many uploads too close in time? The good thing about uploading now would be to be able to check if the new way of handling -fPIC in upstream source works (that is if we can definitely confirm that bug #690830 [1] is gone). The bad thing is that it uses computer power for something that will be soon "outdated"!

And here is another question (it is "my" MoM after all!): what is the fundamental difference between debian-med and debian-med-packaging mailing-lists?
I did not manage to decide which one to use for my questions. The wiki says:
Debian Med - general discussion list (Archives)
debian-med-packaging - reports and discussions on packages (Archives)
So I suppose "debian-med-packaging" is better (apart may be for... the current question), but I saw a lot of other posts as relevant in debian-med.

Kind regards,
Mahnu

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690830 (this is a FTBFS on armhf, which I have now way to test on my own I think.


Reply to: