I agree, it’s also unmaintained. Let’s take it out.
Roelof
(Author and original packager)
Von meinem Mobiltelefon gesendet.
> Am 02.12.2022 um 10:38 schrieb Andreas Tille :
>
> Am Thu, Dec 01, 2022 at 11:39:47PM +0200 schrieb Adrian Bunk:
>> [1] contains a patch from a Debian porter, but
Fixed. Next steps would be:
adt-run --unbuilt-tree=limereg --- null
git tag -s -a debian/1.4.1-1 -m "Release 1.4.1-1"
git push --all
git push --tag
But I have a: WARNING: 'automake-1.15' is missing on your system, so I
cannot verify before creating the tag. Will move my development PC to
SID,
Ok, work in progress ... Thanks for reporting.
I changed the compiler settings as suggested. This is only a hotfix to
enable the package-build again. Because the underlying problem might be
safety relevant (BOF) I added an entry to upstream's issue tracker and
added a note to inform debian, when the compiler can be reverted to more
strict
Wow, thanks a lot Jurica ! I'll take care of it asap.
On 17.01.2016 19:52, Jurica Stanojkovic wrote:
User: debian-m...@lists.debian.org
Hello,
I have found that changing -fstack-protector-strong to -fstack-protector (for
test or for entire source) does make this issue disappear on mipsel.
Damn. If I execute it in qemu (Mips), all tests pass. Cannot reproduce
it (yet).
debian_wheezy_mips_standard.qcow2 -append "root=/dev/sda1 console=tty0"
Thanks Aurel32
On 26.10.2015 21:47, Roelof Berg wrote:
I wonder what might be the best way, to test my fix for MIPS.
I wonder what might be the best way, to test my fix for MIPS. Esp. I
wonder how the Debian build server operates. I would normally assume a
cross-compile - but the tests seem to be executed on a real MIPS. Might
it be emulated ?
On 28.09.2015 22:53, Roelof Berg wrote:
I assume, the software
I assume, the software is ok but the test automation is not. The
'algorithm under test' gives a bit fuzzy results depending on the
multicore calling order and depending on numerical rounding issues.
Therefore the automated tests accept results within a range of plausible
values. Seems that
Hi Andreas,
thanks for explaining.
On 22.08.2015 15:12, Andreas Tille wrote:
Roelof,
[...]
Just add a proper
Closes: #792624, #792625
line in your changelog entry.
Fixed
[...]
Moreover the package currently does not build currently
due to the gcc-5 transition:
I upgraded my SID
Probably related to the latest GCC update, I'll take care of it.
Hi,
this is about the third or fourth time I'm asking this. Any help would
be greatly aprechiated.
I uploaded a new version 1.4.0-2 of limereg that fixes #792624 and
#792625. But I don't see the new version on:
http://blends.debian.org/science/tasks/imageanalysis , so I cannot close
the
Hi, I git-pushed a patch for limereg that fixes #792624 and #792625.
This is my first patch and I don't know what to do now, will the new git
version automatically be added to sid and stretch ? Or do I need to
contact someone ?
Bug cause: Doxygen (not help2man) added the current date to
Understood, I put this on my release backlog. Esp. getting rid of
doxygen which is clumsy in automake would be great (and isn't justified
for a small plain C API). For the current version I will, however, just
add some small bugfix inside the .../debian folder.
Thanks !
On 11.08.2015 10:21,
I had a look at the idea of writing manpages manually (as upstream) and
unfortunately saw some difficulties: Because OpenBSD and Linux use
different *roff syntax, man vs. mdoc, if I understodd it correctly,
generating the man pages in the syntax of the actual operating system
would be the most
help2man 1.47.1 IS used. Next I will try as a workaround setting
export SOURCE_DATE_EPOCH = $(shell date -d $$(dpkg-parsechangelog
--count 1 -SDate) +%s)
manually in debian/rules.
Hmm, good point, David. Because I'm also upstream this would easily be
possible. It had to stay in sync then to the application/api behavior, which
is, however, only a matter of discipline. Maybe I can use some familiar tool
like LaTeX for writing.
Thanks for the impulse, I hadn't considered
Possibly a help2man https://bugs.debian.org/787444 version below
1.47.1 is used on the build server and help2man doesn't support
SOURCE_DATE_EPOCH before this date. (See:
https://wiki.debian.org/ReproducibleBuilds/TimestampsProposal). I'm not
familiar with the debian automated build
Back from vacation: This is a consequence of #787675.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787675
Thanks to Anton Gladky for pointing me to that. The fix is on its way ...
Roelof
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe.
Thanks for notifying, I will take care of it asap. The cause might be
that I use enhanced speed optimization (which has to be considered in
this particular case, as it is a computing intense algorithm that takes
significant benefit from optimization/SSE/Vector-Units etc.).
Roelof
--
To
Hi,
I uploaded the latest upstream version of Limereg V 1.4.0 to alioth. I
also added test automation during build time (by automake) and after
installation (by autopkgtest). Location:
git.debian.org/git/debian-science/packages/limereg.git
On http://blends.debian.org/science/tasks/imageanalysis
://y...@git.debian.org/git/debian-science/packages/limereg.git
cd limereg
./configure CFLAGS=-Ofast CXXFLAGS=-Ofast
make
cd exe
./limereg --tfile ../tests/testimg/T_512.bmp --rfile
../tests/testimg/R_512.bmp
Regards,
Roelof
On 27.04.2015 15:02, Roelof Berg wrote:
Ok, I'm fine with an early
feedback.
Von meinem Mobiltelefon gesendet.
Am 27.04.2015 um 13:42 schrieb Andreas Tille andr...@an3as.eu:
Hi Roelof,
On Mon, Apr 27, 2015 at 01:32:20PM +0200, Roelof Berg wrote:
limereg 1.3.1 is in ITP state. This version is limited to square image
dimensions, grayscale colors and a dark
Hi,
limereg 1.3.1 is in ITP state. This version is limited to square image
dimensions, grayscale colors and a dark image background.
The upcoming V1.4 will not have any of theese limitations anymore, and can take
virtually any image in any format. It will be released at 1st of June. It might
Hi Andreas,
done (and verified by 'diff'ing the ...orig.tar.gz output to the
upstream tarball).
Regards,
Roelof
On 11.04.2015 12:34, Andreas Tille wrote:
Hi Roelof,
I checked the packaging of limereg with my sponsors hat on. Could you
please provide a pristine-tar branch to enable me (==
cc'ing sponsorship request to bugs.debian.org (see below).
Package: git.debian.org/git/debian-science/packages/limereg.git
Forwarded Message
Subject:Sponsor for limereg: Lightweight Image Registration
Date: Tue, 07 Apr 2015 00:36:02 +0200
From: Roelof Berg rb
Thanks, I will proceed as you suggested. Because limereg is versatile and not
limited to medical applications I'd prefer d-science, if I may choose.
Regards,
Roelof
Am 10.02.2015 um 22:30 schrieb Andreas Tille andr...@an3as.eu:
On Tue, Feb 10, 2015 at 06:24:04PM +, Ghislain Vaillant
Ok, thanks a lot ! I think, that's all assistance I needed for now, and I have
enough information available for preparing the delivery.
Debian rocks :)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
or alternatively the Debian Phototools team (both
teams in CC)
Kind regards and thanks for this interesting ITP
Andreas.
On Tue, Feb 03, 2015 at 11:42:22PM +0100, Roelof Berg wrote:
Package: wnpp
Severity: wishlist
Owner: Roelof Berg rb...@berg-solutions.de
* Package name: limereg
Thank you for giving so much details. Well, I'd be happy off course if
the package will be part of d-science and/or d-med.
I will apply your suggested naming scheme, maybe with one exception: I'd
prefer that the package named 'limereg' stands for the command line
tool, this makes it easy for
, Roelof Berg rb...@berg-solutions.de wrote:
I developed this application as part of a scientific project. It offers 2D,
grayscale, rigid image registration with a powerful
derivative based approach and operates very fast and memory efficient
(compared
to traditional derivative-based aproaches
Package: wnpp
Severity: wishlist
Owner: Roelof Berg rb...@berg-solutions.de
* Package name: limereg
Version : 1.1.0
Upstream Author : Roelof Berg rb...@berg-solutions.de
* URL : https://github.com/RoelofBerg/limereg
* License : BSD
Programming Lang: C
32 matches
Mail list logo
