Didn't have the time to patch the whole thing. But a first few lines of
the patch would read as attached to this mail - and obviousy would need
an review as everybody gets this kind of thing wrong.
I'm not sure if all the strings we sprintf'ed into actually had the
right length to accomodate the
On Sun, Sep 23, 2018 at 11:43:38PM +0100, Bruno Postle wrote:
>
>
> On 23 September 2018 13:48:10 BST, Andreas Metzler wrote:
> >
> >building libpano with gcc 8 (instead of 7) triggers a couple of new
> >warnings that might be interesting:
> >
> >parser.c: In function 'ReadImageDescription':
>
My advise is to replace the sprintf by an snprintf before the final
release: snprintf requires an additional parameter that tells it how many
bytes the buffer it is about to write into is long; using an ordinary
sprintf always means you are risking needing to issue an security update
because
On September 23, 2018 12:43:38 PM HST, Bruno Postle wrote:
>
>
>On 23 September 2018 13:48:10 BST, Andreas Metzler wrote:
>>
>>building libpano with gcc 8 (instead of 7) triggers a couple of new
>>warnings that might be interesting:
>>
>>parser.c: In function 'ReadImageDescription':
On Sunday, 23 September 2018 at 23:43:38 +0100, Bruno Postle wrote:
>
>
> On 23 September 2018 13:48:10 BST, Andreas Metzler wrote:
>>
>> building libpano with gcc 8 (instead of 7) triggers a couple of new
>> warnings that might be interesting:
>>
>> parser.c: In function 'ReadImageDescription':
On 23 September 2018 13:48:10 BST, Andreas Metzler wrote:
>
>building libpano with gcc 8 (instead of 7) triggers a couple of new
>warnings that might be interesting:
>
>parser.c: In function 'ReadImageDescription':
>parser.c:1854:38: warning: '%s' directive writing up to 65535 bytes
>into a
Hello,
building libpano with gcc 8 (instead of 7) triggers a couple of new
warnings that might be interesting:
---
parser.c: In function 'ReadImageDescription':
parser.c:1854:38: warning: '%s' directive writing up to 65535 bytes into a
region of size 256 [-Wformat-overflow=]
Hello,
find attached a trivial patch against libpano13-2.9.20 rc2, fixing two
typos. Found by lintian, perhaps you can apply after the releas (or
before?)
TIA, cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time
On Tue 13-Nov-2012 at 01:25 -0400, Jim Watters wrote:
I just grabbed the tip of libpano but noticed that there is a branch
libpano 13-2.9.18 that is not merged into the default branch.
http://panotools.hg.sourceforge.net/hgweb/panotools/libpano/graph
Reviewing the changes, I see that the
I use Mercurial infrequently.
I just grabbed the tip of libpano but noticed that there is a branch libpano
13-2.9.18 that is not merged into the default branch.
http://panotools.hg.sourceforge.net/hgweb/panotools/libpano/graph
Reviewing the changes, I see that the same one have been added to
I have added the Thoby projection for the Nikkor 10.5. It is now in
subversion. I have called it after Michel Thoby who was able to
empirically find it. If this projection helps with other lenses, I'll
add parameters to it.
The input projection number is 20.
Would the hugin developers add it to
Am Mittwoch, 5. Januar 2011 schrieb D M German:
I have added the Thoby projection for the Nikkor 10.5. It is now in
subversion. I have called it after Michel Thoby who was able to
empirically find it. If this projection helps with other lenses, I'll
add parameters to it.
The input
On Wed, Jan 5, 2011 at 6:51 AM, Kornel Benko kornel.be...@berlin.de wrote:
Nice, but dump.h should be commited too :)
...
Done
--
--dmg
---
Daniel M. German
http://turingmachine.org
--
You received this message because you are subscribed to the Google Groups
Hugin and other free
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I got a redefinition on indianness:
PTcommon.c: In function ‘panoCreatePanorama’:
PTcommon.c:709: warning: ‘regScript’ may be used uninitialized in this
function
libtool: compile: gcc -DHAVE_CONFIG_H -I. -DHasJPEG -DHasPNG -DHasTIFF
- -DHasZLIB
Hi,
I get the following:
[...]
/bin/bash ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-DHasJPEG -DHasPNG -DHasTIFF -DHasZLIB -D__Ansi__=1 -g -O2 -MT
PTDialogs.lo -MD -MP -MF .deps/PTDialogs.Tpo -c -o PTDialogs.lo
PTDialogs.c
libtool: compile: gcc -DHAVE_CONFIG_H -I.
What follow is a rant directed at those who push dynamic linking to
libpano on Windows at the expenses of statically linked binaries: DO
WHAT THE HELL YOU WANT ON AN EXTRA TRACK BUT PLEASE DON'T BREAK WHAT THE
EXISTING DEFAULT TRACK THAT HAS WORKED IN THE PAST - SPECIFICALLY THE
STATICALLY
Hello,
Debian is currently applying the patch quoted below to get libpano13
to build on kfreebsd-*. It would be nice if this could applied.
thanks, cu andreas
==
Author: Cyril Brulebois
http://bugs.debian.org/543998
--- a/configure
+++
I have committed the changes to support tilt of the camera in
PToptimizer and PTmender. See the ChangeLog for details.
the new parameters are:
Tx, Ty, Tz, and Ts (for scale).
--dmg
--
--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at)
http://sourceforge.net/tracker/?func=detailatid=550441aid=2826516group_id=77506
can somebody please apply the patch attached to Hugin's tracker to
Libpano? or even better: give Thomas Modes SVN write access to libpano?
Yuv
--~--~-~--~~~---~--~~
You received
19 matches
Mail list logo
