Smartblend Wrapper Fixed - 2011.0.0_RC2 will follow

104 views
Skip to first unread message

Yuval Levy

unread,
May 24, 2011, 8:11:31 AM5/24/11
to hugi...@googlegroups.com
Hi all,

Bart van Andel fixed the smartblend wrapper in the repository.

Windows users confronted with the issue (Henk?): can you please download the
updated wrapper from [0], overwrite the smartblend-hugin.bat of 2011.0.0_RC1
and test that it works?

Once I have confirmation that it works, I will apply the changeset to the
2011.0 branch and issue an RC2.

Since this affects Windows only, and it is only a script, "final" status can
be declared soon thereafter. It is enough to confirm that the bug is fixed on
Windows and that the tarball builds on Linux and Mac. Harry: do you (still)
want to be the one declaring this upcoming RC2 final?

Linux/Unix/Mac end-users need not bother with this.

Yuv


[0] http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/raw-
file/cd9cb5ee3f3b/platforms/windows/smartblend-wrapper/smartblend-hugin.bat


---------- Forwarded Message ----------

Subject: [Hugin-cvs] /hgrepo/h/hu/hugin/hugin: Fix smartblend-hugin.bat to
remove '--...
Date: May 24, 2011, 07:40:40 AM
From: hugi...@lists.sourceforge.net
To: hugi...@lists.sourceforge.net

branch:
details:
http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/hgrepo/h/hu/hugin/hugin/rev/cd9cb5ee3f3b
changeset: 5238:cd9cb5ee3f3b
user: Bart van Andel bavanan...@gmail.com
date: Tue May 24 13:27:26 2011 +0200
description:
Fix smartblend-hugin.bat to remove '--' argument separator

diffstat:

platforms/windows/smartblend-wrapper/smartblend-hugin.bat | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diffs (12 lines):

diff -r 967c53582af3 -r cd9cb5ee3f3b platforms/windows/smartblend-
wrapper/smartblend-hugin.bat
--- a/platforms/windows/smartblend-wrapper/smartblend-hugin.bat Tue May 24
08:50:29 2011 +0200
+++ b/platforms/windows/smartblend-wrapper/smartblend-hugin.bat Tue May 24
13:27:26 2011 +0200
@@ -16,6 +16,8 @@
shift
) else if "%arg:~0,2%"=="-f" (
echo [smartblend-wrapper] Skipping crop argument: %1
+ ) else if "%arg:~0,2%"=="--" (
+ echo [smartblend-wrapper] Skipping argument separator: %1
) else if "%arg:~0,2%"=="-o" (
echo [smartblend-wrapper] Output file: %2
set SMARTBLENDARGS=%SMARTBLENDARGS% -o %2
-----------------------------------------

signature.asc

Henk Tijdink

unread,
May 24, 2011, 3:40:00 PM5/24/11
to hugin and other free panoramic software
Hello Yuv

Have downloaded the new wrapper and it works now with 2011.0RC1.
I have done some testing with the old wrapper with 2011Beta 2 and 3
too and then the old wrapper still worked.
The change has come between Beta 3 and RC1.
The wrapper is not in an install package for windows. You have to
download it separately as you have to do with smartblend.
With Hugin is probably nothing wrong, but only the wrapper has to be
adapted to a new extension in Hugin.
But it should be nice if the wrapper and instructions for it is in the
install package, so you can copy it to your smartblend folder.

Kind regards,
Henk Tijdink
On May 24, 2:11 pm, Yuval Levy <goo...@levy.ch> wrote:
> Hi all,
>
> Bart van Andel fixed the smartblend wrapper in the repository.
>
> Windows users confronted with the issue (Henk?): can you please download the
> updated wrapper from [0], overwrite the smartblend-hugin.bat of 2011.0.0_RC1
> and test that it works?
>
> Once I have confirmation that it works, I will apply the changeset to the
> 2011.0 branch and issue an RC2.
>
> Since this affects Windows only, and it is only a script, "final" status can
> be declared soon thereafter.  It is enough to confirm that the bug is fixed on
> Windows and that the tarball builds on Linux and Mac.  Harry: do you (still)
> want to be the one declaring this upcoming RC2 final?
>
> Linux/Unix/Mac end-users need not bother with this.
>
> Yuv
>
> [0]http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/raw-
> file/cd9cb5ee3f3b/platforms/windows/smartblend-wrapper/smartblend-hugin.bat
>
> ----------  Forwarded Message  ----------
>
> Subject: [Hugin-cvs] /hgrepo/h/hu/hugin/hugin: Fix smartblend-hugin.bat to
> remove '--...
> Date: May 24, 2011, 07:40:40 AM
> From: hugin-...@lists.sourceforge.net
> To: hugin-...@lists.sourceforge.net
>
> branch:    
> details:  http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/hgrepo/h/hu/hugin/h...
> changeset: 5238:cd9cb5ee3f3b
> user:      Bart van Andel bavanandel+c...@gmail.com
> date:       Tue May 24 13:27:26 2011 +0200
> description:
> Fix smartblend-hugin.bat to remove '--' argument separator
>
> diffstat:
>
>  platforms/windows/smartblend-wrapper/smartblend-hugin.bat |  2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diffs (12 lines):
>
> diff -r 967c53582af3 -r cd9cb5ee3f3b platforms/windows/smartblend-
> wrapper/smartblend-hugin.bat
> --- a/platforms/windows/smartblend-wrapper/smartblend-hugin.bat Tue May 24
> 08:50:29 2011 +0200
> +++ b/platforms/windows/smartblend-wrapper/smartblend-hugin.bat Tue May 24
> 13:27:26 2011 +0200
> @@ -16,6 +16,8 @@
>                 shift
>         ) else if "%arg:~0,2%"=="-f" (
>                 echo [smartblend-wrapper] Skipping crop argument: %1
> +       ) else if "%arg:~0,2%"=="--" (
> +               echo [smartblend-wrapper] Skipping argument separator: %1
>         ) else if "%arg:~0,2%"=="-o" (
>                 echo [smartblend-wrapper] Output file: %2
>                 set SMARTBLENDARGS=%SMARTBLENDARGS% -o %2
> -----------------------------------------
>
>  signature.asc
> < 1KViewDownload

Harry van der Wolf

unread,
May 24, 2011, 4:37:17 PM5/24/11
to hugi...@googlegroups.com
Hi Yuv,

2011/5/24 Yuval Levy <goo...@levy.ch>
Since this affects Windows only, and it is only a script, "final" status can
be declared soon thereafter.  It is enough to confirm that the bug is fixed on
Windows and that the tarball builds on Linux and Mac.  Harry: do you (still)
want to be the one declaring this upcoming RC2 final?

Yuv

 
To be honest: I don't care, not in a positive way nor in a negative way. I'm willing to do it if you are in a time squeeze or just want to hand over tasks to other persons, especially to spread the knowledge of this process a little more so that more people can perform this release task in the future.
As such I'm willing to do it. 
 
Please note that I'm currently on a business trip.
Thomas had a new idea to try to capture what is going wrong at the moment of the error. From that point we might be able to work backward to find a solution. That might be relatively fast, but just as easily take longer or even not result in a solution.
Being on a business trip means that I can't currently build a new bundle and can't do a release. I only have web access through a very closed hotel proxy.
I *should* be home wednesday evening, but I might be a day later.
 
If you want to release earlier please go ahead. Otherwise I will look into the matter.
 
Hoi,
Harry

Bart van Andel

unread,
May 24, 2011, 7:25:12 PM5/24/11
to hugi...@googlegroups.com
On Tuesday, May 24, 2011 9:40:00 PM UTC+2, Henk Tijdink wrote:
Have downloaded the new wrapper and it works now with 2011.0RC1.
I have done some testing with the old wrapper with 2011Beta 2 and 3
too and then the old wrapper still worked.  
The change has come between Beta 3 and RC1.

I hadn't noticed this behavior with older versions either. The only purpose of the wrapper is actually to reformat or get rid of parameters that are hardcoded into Hugin. A nicer way would actually to be able to drop or modify those hardcoded values. New parameters aren't automatically understood by the wrapper, which is why it stopped working with this release.
 
The wrapper is not in an install package for windows. You have to
download it separately as you have to do with smartblend.
With Hugin is probably nothing wrong, but only the wrapper has to be
adapted to a new extension in Hugin.
But it should be nice if the wrapper and instructions for it is in the
install package, so you can copy it to your smartblend folder.

Agreed. I don't have a Windows build environment setup, so I can't test it, but the attached patch may solve this. It modifies1 and adds 1 CMakeLists.txt files, and changes to the Inno Setup (pre)release scripts are made accordingly. Can someone with a working Windows build env test this? (Allard, are you reading this?)

--
Bart
smartblend-install.diff

Yuval Levy

unread,
May 26, 2011, 9:26:24 AM5/26/11
to hugi...@googlegroups.com
On May 24, 2011 07:25:12 pm Bart van Andel wrote:
> the attached patch may solve this. It modifies1 and adds 1
> CMakeLists.txt files, and changes to the Inno Setup (pre)release scripts
> are made accordingly. Can someone with a working Windows build env test
> this? (Allard, are you reading this?)

AFAIK the InnoSetup scripts are outdated/unmaintained since Matthew
contributed the NSI based installer at /platforms/windows/huginsetup

Yuv

signature.asc

Yuval Levy

unread,
May 26, 2011, 9:39:11 AM5/26/11
to hugi...@googlegroups.com
Hoi Harry,

On May 24, 2011 04:37:17 pm Harry van der Wolf wrote:
> > Harry: do you (still)
> > want to be the one declaring this upcoming RC2 final?
>

> To be honest: I don't care, not in a positive way nor in a negative way.
> I'm willing to do it if you are in a time squeeze or just want to hand
> over tasks to other persons, especially to spread the knowledge of this
> process a little more so that more people can perform this release task in
> the future. As such I'm willing to do it.

The reason why I am asking you is because I know that you and the Mac users
community are working on a fix for the critical issue affecting Hugin on some
OSX systems. I feel it is your call to make because you are the group of
people affected by that issue. You have the option to extend the release
cycle until the issue is solved, or to call it a day and leave it as a "known
issue" for the next cycle. You are the one in the best position to judge.


> Being on a business trip means that I can't currently build a new bundle

Understand. No time pressure. The release cycle has anyway extended beyond
the schedule.


> If you want to release earlier please go ahead. Otherwise I will look into
> the matter.

As you want. You choose. This weekend I intend to make and propose a
tentative schedule for the 2011.2 release cycle. I can imagine multiple
scenarios for 2011.0:
- it can be declared final as-is
- it can be dropped all together as unfinished
- it can be kept in RC status until the critical OSX issue is fixed in
parallel with the 2011.2 release cycle

The thing I really care about is moving forward to 2011.2.

Yuv

signature.asc

Yuval Levy

unread,
May 26, 2011, 9:41:47 AM5/26/11
to hugi...@googlegroups.com
Hello Henk,

On May 24, 2011 03:40:00 pm Henk Tijdink wrote:
> Have downloaded the new wrapper and it works now with 2011.0RC1.

Thanks for confirming. I have released RC2.


> But it should be nice if the wrapper and instructions for it is in the
> install package, so you can copy it to your smartblend folder.

Matthew Petroff maintains the Windows installer, you may want to file a
feature request / discuss this with him.

Yuv

signature.asc

Harry van der Wolf

unread,
May 26, 2011, 12:42:32 PM5/26/11
to hugi...@googlegroups.com
Hi Yuv,

2011/5/26 Yuval Levy <goo...@levy.ch>

Hoi Harry,

On May 24, 2011 04:37:17 pm Harry van der Wolf wrote:
> > Harry: do you (still)
> > want to be the one declaring this upcoming RC2 final?
>
> To be honest: I don't care, not in a positive way nor in a negative way.
> I'm willing to do it if you are in a time squeeze or just want to hand
> over tasks to other persons, especially to spread the knowledge of this
> process a little more so that more people can perform this release task in
> the future. As such I'm willing to do it.

The reason why I am asking you is because I know that you and the Mac users
community are working on a fix for the critical issue affecting Hugin on some
OSX systems.  I feel it is your call to make because you are the group of
people affected by that issue.  You have the option to extend the release
cycle until the issue is solved, or to call it a day and leave it as a "known
issue" for the next cycle.  You are the one in the best position to judge.


I said that I didn't care and I have now been thinking how I could have expressed myself better as it sounds as if I'm not interested and that's not the impression I want to give. (But I still don't know of a better expression.)

I'm in doubt myself about releasing. If we can solve the issue before "end of the weekend" I would say to wait a little longer, but I have no idea whether that's feasible.
As the release cycle has already been extended I would almost say to release the 2011.0. The hidden trap is that we might keep extending the release.
If we find a simple solution to 2011.0 after release, we can decide to release a 2011.0.01 or 2011.0.p1 version (p1 for patch 1), both as tgz/bz and as bundle and probably only for OSX.
The issue is also that I don't know whether a cmake build on a 10.5 machine will correctly run (and I'm still not able to build a virtual 10.5 system).

And if the 2011.2 progresses far more rapidly than this release we can easily bridge the gap and explain it on the SF website.
 

 
As you want.  You choose.  This weekend I intend to make and propose a
tentative schedule for the 2011.2 release cycle.  I can imagine multiple
scenarios for 2011.0:
- it can be declared final as-is
- it can be dropped all together as unfinished
- it can be kept in RC status until the critical OSX issue is fixed in
parallel with the 2011.2 release cycle

The thing I really care about is moving forward to 2011.2.

Yuv

I agree. Please start the 2011.2 release cycle planning this weekend. I will give feedback on the possible solution of the issue and we can decide Sunday at the latest whether we can solve the issue within days and otherwise we go for the 2011.0 release.


Harry


Yuval Levy

unread,
May 26, 2011, 6:50:17 PM5/26/11
to hugi...@googlegroups.com
Hoi Harry,

On May 26, 2011 12:42:32 PM Harry van der Wolf wrote:
> 2011/5/26 Yuval Levy <goo...@levy.ch>


> > The reason why I am asking you is because I know that you and the Mac
> > users community are working on a fix for the critical issue affecting
> > Hugin on some
> > OSX systems. I feel it is your call to make because you are the group of
> > people affected by that issue. You have the option to extend the release
> > cycle until the issue is solved, or to call it a day and leave it as a
> > "known
> > issue" for the next cycle. You are the one in the best position to
> > judge.
>
> I said that I didn't care and I have now been thinking how I could have
> expressed myself better as it sounds as if I'm not interested and that's
> not the impression I want to give. (But I still don't know of a better
> expression.)

I did not get the impression that you're not interested. I did get the
impression that "either way is good for you". It is the same for me, since
either way won't prevent the overall project form moving forward to 2011.2.


> I'm in doubt myself about releasing. If we can solve the issue before "end
> of the weekend" I would say to wait a little longer, but I have no idea
> whether that's feasible.

I understand. And yet you have more insight into this than me or most other
contributors.


> The hidden trap is that we might keep extending the release.

It's a theoretical trap. It does not prevent the project from moving on to
2011.2, and if 2011.2 is polished before the bug is fixed, the 2011.0 branch
may well dry out without a final release.

I don't think it will be the case - 2011.0 has already blossomed for most
users and we are dealing with a bug that while critical and annoying is
affecting a small and specific system configuration and has a workaround.

Calling it final or leaving it an RC indefinitely has only few pratical
impications.


> If we find a simple solution to 2011.0 after release, we can
> decide to release a 2011.0.01 or 2011.0.p1 version (p1 for patch 1), both
> as tgz/bz and as bundle and probably only for OSX.

Yes, releasing a patched version is an option, and the naming convention would
be 2011.0.1. Patches uptick have not been used frequently by this project and
are reserved for serious fixes. So far they have been used only for security
issues, but a fix for this issue is serious enough to warrant a fix / patched
release.


> The issue is also that I don't know whether a cmake build on a 10.5 machine
> will correctly run (and I'm still not able to build a virtual 10.5 system).

Well, there is a lot of burden on your shoulders already. Sometimes you need
to draw a line. Users of 10.5 should step up to the plate, or see support
limited to what you can and want to support, which is your system (10.6?)


> And if the 2011.2 progresses far more rapidly than this release we can
> easily bridge the gap and explain it on the SF website.

Indeed. I suspect however that 2011.2 is going to be long too.


> I agree. Please start the 2011.2 release cycle planning this weekend. I
> will give feedback on the possible solution of the issue and we can decide
> Sunday at the latest whether we can solve the issue within days and
> otherwise we go for the 2011.0 release.

OK. I will go with your decision regarding 2011.0 - if you don't have time to
do the job, just say that we should declare it final and I'll do it. In
passing this to you it was not my intention to load more on your already
loaded shoulders, just to make sure that the person who knows more about the
issue makes the decision.

And for 2011.2, a plan proposal is coming this weekend.

Yuv

signature.asc
Reply all
Reply to author
Forward
0 new messages