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.
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
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-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
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.
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debia
Hello,
I'm new to Debian and wonder, what the e-mail below might mean. I
assume, that something's wrong with my package and therefore it is not
included in Debian testing any longer, right ? And do I understand
correctly that there is a task for me (package maintainer) to "finish
the opencv
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.
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers
Hi,
I updated limereg to V 1.4.0-2 (fixed #792624 and #792625). What must I
do now to get it into sid and stretch ? According to
http://blends.debian.org/science/tasks/imageanalysis still V 1.4.0-1 is
used, so I can't close those bugs (right ?). Do I just have to wait, or
do I have to do an
What is the best way to find out, who of our debian-science-maintainers
team will be on the Linuxcon in Dublin ? And how can I recognize a
debsci-fellow in the crowd ? Do we have a secret sign, like red hats or
big beards, bellys and bushy eye brows ?
--
debian-science-maintainers mailing
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.
--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
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
Hi,
I'm new to Debian maintain 'Limereg' in DebSci. What would be the best
way to examine the Debian build toolchain being used for a released
package ?
I need to find out the version of help2man being used for fixing the
bugs below.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792624
Hi,
I'm new to Debian packaging. For my package limereg two bug reports were
generated, telling me that 'multiarch = same' is void because some man
files differ between i32 and i64. When I look into the .diff, that is
attached to the bug report, I see different creation-date entries. The
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
--
Hi,
would anyone want to sponsor Limereg V1.4.0 ? That'd be awesome. It's on
alioth at
git.debian.org/git/debian-science/packages/limereg.git
It's also listet at
http://blends.debian.org/science/tasks/imageanalysis
with 'packaging has started'.
Thanks :)
Regards,
Roelof
--
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
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
Thanks Andreas, I will check if this works for me as final acceptance
test. I wonder about the state of limereg. After I fixed the reason for
the rejection, which you kindly offered to accept some days ago, thanks,
I saw neither an ACCEPTED, nor a REJECTED email from the build server.
So I
...@an3as.eu:
Hi Roelof,
On Thu, Apr 16, 2015 at 12:06:14AM +0200, Roelof Berg wrote:
I fixed below mentioned issue in:
ssh://rberg-gu...@git.debian.org/git/debian-science/packages/limereg.git
Fine. I'm rebuilding while writing this mail.
Though I read a lot of documents about Debian
Hello,
I fixed below mentioned issue in:
ssh://rberg-gu...@git.debian.org/git/debian-science/packages/limereg.git
Though I read a lot of documents about Debian packaging, the last weeks,
I haven't understood yet how sourcecode goes from the above mentioned
repo into the debian blend. I read
Hi,
I'm new to Debian packaging, and I hope I follow the process by hereby
announcing that I added limereg V 1.3.1 to debian-science.
Package: git.debian.org/git/debian-science/packages/limereg.git
Lintian is satisfied. There are warnings about unnecessary libs, but theese
are
upstram-repos in one packaging project ?
Thanks a lot,
Roelof
On 19.02.2015 22:34, Anton Gladky wrote:
Hi Roelof,
2015-02-19 22:08 GMT+01:00 Roelof Berg rb...@berg-solutions.de
mailto:rb...@berg-solutions.de:
If this naming scheme is ok, I will add:
packages/limereg.git (Shell
#777000: ITP: limereg -- Lightweight Image
Registration. Commandline application for image registration
(automatically aligning two images with similar content).
Date: Wed, 11 Feb 2015 14:11:13 +0100
From: Andreas Tille andr...@fam-tille.de
To: Roelof Berg rb...@berg-solutions.de
CC: 777
30 matches
Mail list logo
