bugGNU Octave - Bugs: bug #57740, 5.2 win installer: wrong behavior...


bug #57740: 5.2 win installer: wrong behavior with icon on taskbar (was fine days before)

Submitted by:  Hartmut <hardy>
Submitted on:  Tue 04 Feb 2020 01:19:15 PM UTC  
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  5.2.0 Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Fri 07 Feb 2020 04:47:19 AM UTC, comment #28: 

Regarding comment #26, I reread this item the only open topic is the MXE release process which is more suited for the maintainer list than the bug tracker.

Happily closing this report as fixed.

Kai Torben Ohlhus <siko1056>
Project Member
Thu 06 Feb 2020 04:20:08 PM UTC, comment #27: 

Confirm the same with my MS Win 10 VM.  This bug is no longer an issue with "octave-5.2.0_1-w64-installer.exe" in both GUI and CLI the test suite passes with 0 errors.

Finally we have a release =)

Kai Torben Ohlhus <siko1056>
Project Member
Thu 06 Feb 2020 04:15:47 PM UTC, comment #26: 

I have now tested the official installer "octave-5.2.0_1-w64-installer.exe" from the gnu ftp site. It also behaves FINE in terms of task bar pinning and icons under Windows 10.

I suggest to either close this bug report now, or to rephrase its title in order to summarize the remaining topics for the next release.

Hartmut <hardy>
Thu 06 Feb 2020 08:22:27 AM UTC, comment #25: 

As response to comment #19:

I have downloaded Kai's new installer "octave-5.2.0-w64-installer.exe" from the "Update 2020-02-06" section on Octave.space and installed it (after uninstalling all other 5.2 variants before).

The task bar pinning (and the corresponding icon) seem to work FINE on my Windows 10 PC.

I am unsure how much this tells us. (The installer from octave.space was fine for me before.) But there is no new 5.2. installer on ftp.gnu.org/gnu/octave/windows/ so far, yet.

Hartmut <hardy>
Thu 06 Feb 2020 06:53:09 AM UTC, comment #24: 

Thank you for this effort =)

Kai Torben Ohlhus <siko1056>
Project Member
Thu 06 Feb 2020 06:23:04 AM UTC, comment #23: 

OK, I will test and upload the installers and zip files tomorrow (well, tomorrow for me).

John W. Eaton <jwe>
Project Administrator
Thu 06 Feb 2020 06:16:01 AM UTC, comment #22: 

> Is that what you meant by "ONE final MXE build"?

Yes, one final set of MXE installers which most people are happy with.

Of course people will find bugs in 5.2.0, but just avoid the most obvious flaws like the task bar pinning.

Kai Torben Ohlhus <siko1056>
Project Member
Thu 06 Feb 2020 05:46:11 AM UTC, comment #21: 

If all goes well, I'll push those changes to the public mxe-octave archive.

John W. Eaton <jwe>
Project Administrator
Thu 06 Feb 2020 05:44:34 AM UTC, comment #20: 

Kai, I made the following change in my mxe-octave sources and tagged that revision with octave-release-5.2.0_1.  I'm building a new set of installers and zip files.  Is that what you meant by "ONE final MXE build"?

John W. Eaton <jwe>
Project Administrator
Thu 06 Feb 2020 02:07:05 AM UTC, comment #19: 

Agree to your comment #18 jwe.  Especially

> Then, as I understand it, the icon association should work again, correct?

Yes, I made another unofficial build https://octave.space "Update 2020-02-06" which is https://hg.octave.org/mxe-octave/rev/8c1e1ef46ed2 (octave-release-5.2.0) with my patch from comment #9 applied.  With this the task bar pin problem of bug #56840 is gone.  Hartmut, can you as OP verify this?

I think for this release we should go with jwe's suggestion of comment #18.

Markus idea of "two releases" (comment #17) is feasible, as we do not have to announce the publication of (step 2.).  We can wait for the MXE builds to be finished, as it is now the case.  But let's discuss this for 6.1 on the maintainer's mailing list.

jwe I hope ONE final MXE build with this item fixed and then all power back to 6.1 with lots of knowledge gained =)

Kai Torben Ohlhus <siko1056>
Project Member
Wed 05 Feb 2020 05:36:38 PM UTC, comment #18: 

I think I'm growing weary of building binaries for Windows systems.  :-)

My experience with a delay between source releases and Windows binaries appearing is people complaining that they don't know what to do with a tar.gz file on a Windows system.

We should be prepared to make multiple binary releases for the same source release.  Maybe they should all be in files with names like octave-5.2.0_0-installer.exe so that we can bump the build number (the "_0" part of the filename) to distinguish files on the ftp server.  But no matter what that digit is, they will all be version 5.2.0, based on the 5.2.0 source release, and any patches specifically for Windows would be identified by the HG ID of the mxe-octave revision used to build the binary.

Do we need the extra version number for the installer so that multiple 5.2.0 releases can be installed simultaneously?  Probably not.  The reason for it in the past was that after a release like 5.2.0, we wouldn't bump the version number to 5.2.1 until the next release.  So people who had installed the stable release (5.2.0) couldn't easily keep that installed and also install the next 5.2.N release for testing.  But now that we've modified the version scheme to go from 5.2.0 (release) to 5.2.1 (dev for 5.3.0 release) I think we can drop the extra Windows version digit thing.  Then, as I understand it, the icon association should work again, correct?

John W. Eaton <jwe>
Project Administrator
Wed 05 Feb 2020 12:20:43 PM UTC, comment #17: 

Even if the HG-ID (of MXE Octave) is already included in the compressed archives and installers, I agree that having a version number that identifies the packaged version would be nice. The Windows versioning scheme allows to use a group of four integers to identify a version. We could continue to use the 4th integer to identify the installer build.

Instead of changing that, we could slightly adjust the release process.
Imho, it is not necessary to release the tarballs and Windows installers on the same day. Instead we could do the following:

  1. Create the tarballs (and optionally check if they can be used to build the Windows installers).
  2. Release the tarballs on the GNU FTP servers.
  3. After a few days(?), update the MXE Octave release target to the new version.
  4. Build the Windows installers but defer uploading them to the GNU FTP servers. Instead provide them somewhere (on octave.space ?) for internal testing. If necessary, re-build.
  5. Upload the final Windows installers when the tests are done. (Maybe around a week after the new tarball was released.)
  6. After a few days announce the new version.

What do you think?

Markus Mützel <mmuetzel>
Project Member
Wed 05 Feb 2020 11:20:34 AM UTC, comment #16: 

I believe the HG-ID is already included in the tarba;ll/installers root

John Donoghue <lostbard>
Project Member
Wed 05 Feb 2020 07:00:23 AM UTC, comment #15: 

Yes, it doesn't have to be something like this special Windows version number.  But the filenames for the installer and zip files need to be unique for each build and there needs to be some simple way for users who may not have installed Octave to say precisely which version they have.  We can fix this all properly for 6.1 or later versions.  For now I agree that storing the mxe-octave HG ID somewhere that we can expect users to find it is fine.

John W. Eaton <jwe>
Project Administrator
Wed 05 Feb 2020 05:29:55 AM UTC, comment #14: 

> We should fix mxe-octave to create the proper file names.  I can do that.

The previous exceptional treatment ".0" proved to be too error prone.  Each RC is worthless, when the real installer one day is build with a total different recipe and version scheme.

I prefer the new fix to be super simple and stupid.  Maybe just put a text file with the MXE hg id (for stable/default/release) in the distribution folder?  This is fool proof and enough for any hypothetical installer identification scenario.

In general I hope that fixing the MXE installer should stay an exception, rather than a rule.

Thus I want to concentrate on making the default release workflow easier to release more often stable versions of Octave.  One year between releases for such a big software project is in my opinion too rare.

Kai Torben Ohlhus <siko1056>
Project Member
Wed 05 Feb 2020 05:16:36 AM UTC, comment #13: 

I think it's bad form to replace.  Also, as I recall, not easy with the interface to ftp.gnu.org.  I think it requires asking for manual intervention.

We should fix mxe-octave to create the proper file names.  I can do that.

What I'm concerned about is someone is using a copy of Octave.  Maybe their system admin installed it, so they don't even know what file was used for the installation.  What do we ask them to look at in their copy of Octave to tell us what version was installed?  For this particular case, it doesn't matter much.  But there may be other future cases where it would help debugging to know for sure which binary version was installed.

John W. Eaton <jwe>
Project Administrator
Wed 05 Feb 2020 05:00:01 AM UTC, comment #12: 

The release is uploaded, but not publicly announced.  I think it was fine if we now readjust and just replace the current ones.

My suggestion is to apply my patch of comment #9, as the installer seems not flexible enough to cope with this version scheme and to rename MANUALLY fixed installers and zip files to


alongside with a MXE commit tag when done.

Installer fixing happens only once a year (if ever) and is renaming is much faster done, than recompiling the MXE builds because of such issues.

Kai Torben Ohlhus <siko1056>
Project Member
Wed 05 Feb 2020 04:54:19 AM UTC, comment #11: 

If we use a version like 5.2.0_1, then I think we should tag the releases this way as well instaed of moving the tag.  It would be good to know from looking at the mxe-octave commit log which revision was used to build a particular binary release.

John W. Eaton <jwe>
Project Administrator
Wed 05 Feb 2020 04:52:41 AM UTC, comment #10: 

If we build another 5.2.0 windows release, how will we distinguish it from the one that we already uploaded?

Should we use something like octave-5.2.0_1-w64-installer.exe?

If you install the newer version, how will we be able to know what version users have installed for bug reports?  I'm not claiming that this problem is new, we probably had the same issue if we used - the bug tracker only has 5.2.0 as a release to report bugs against.  But when trying to reproduce and diagnose a problem, knowing exactly which binary installer was used will likely be important.

John W. Eaton <jwe>
Project Administrator
Wed 05 Feb 2020 04:17:12 AM UTC, comment #9: 

If nobody remembers a special purpose, Octave never fixed the installer after a release so far.  The additional ".0" is more pain than a help now.  Can the following patch be applied to MXE with a retagging of the 5.2.0 release?

diff -r 7e55d4512a62 src/release-octave.mk
--- a/src/release-octave.mk        Mon Feb 03 14:37:46 2020 -0500
+++ b/src/release-octave.mk        Wed Feb 05 13:10:35 2020 +0900
@@ -40,7 +40,7 @@
PKG             := release-octave
$(PKG)_IGNORE   :=
$(PKG)_VERSION  := 5.2.0
$(PKG)_CHECKSUM := 94054f3757e246398249e5041b2be698badceac8
$(PKG)_SUBDIR   := octave-$($(PKG)_VERSION)
$(PKG)_FILE     := octave-$($(PKG)_VERSION).tar.lz

That is the only real difference between the stable and release recipe.

Then again start the MXE builds =D  I start with this patch applied now and upload to https://octave.space soon.

Kai Torben Ohlhus <siko1056>
Project Member
Wed 05 Feb 2020 02:53:08 AM UTC, comment #8: 

I beleive it was to enable multiple version beuild of the same version of octave, but cant remember for certain anymore

I beleieve related to https://savannah.gnu.org/bugs/index.php?54176

John Donoghue <lostbard>
Project Member
Wed 05 Feb 2020 12:15:00 AM UTC, comment #7: 

Regarding comment #5, what is the exact purpose of the "win octave version"? I also noticed that Octave has an extra ".0" for the MXE builds.  Is it intended for recreated installers, while the Octave version remains the same?

In that case, can we just stay with the Octave version number "5.2.0" for the MXE builds?

Kai Torben Ohlhus <siko1056>
Project Member
Tue 04 Feb 2020 06:42:19 PM UTC, comment #6: 

I guess it broke here (2018)
https://hg.octave.org/mxe-octave/rev/ebb6dbbb8b3f however on last report of it happening, building teh latest stable showed it was happening anymore (missed that was only when building using the release-octave target)

John Donoghue <lostbard>
Project Member
Tue 04 Feb 2020 06:28:34 PM UTC, comment #5: 

Or change teh last line of the release-octave.mk to dump out the octave version not win octave version

John Donoghue <lostbard>
Project Member
Tue 04 Feb 2020 06:18:09 PM UTC, comment #4: 

Not that anything there should have changed, but there is some registering of app ids that goes on in the installer which has to do with the icon vs executable - see ExecWait calls to win7appid.exe

It should be mapping "gnu.octave.XXXXXXXX" to a shortcut. That value should also match waht it is set in octave by
pfnSetCurrentProcessExplicitAppUserModelID (L"gnu.octave." VERSION);

Looking at a previous 5.1.90 binaries they appear to be using gnu.octave.5.1.90, however it looks like the released version is using gnu.octave.

Running from commandline to query:

$ win7appid.exe GNU\ Octave\\ \(GUI\).lnk
Current AppId: gnu.octave.

$ win7appid.exe GNU\ Octave\ 5.1.90/Octave-5.1.90\ \(GUI\).lnk
Current AppId: gnu.octave.5.1.90

And looking in release-octave the win version has the additional '.0' so we need change something in the nsis script to use the real version rather than win version

John Donoghue <lostbard>
Project Member
Tue 04 Feb 2020 05:50:49 PM UTC, comment #3: 

Does anyone know what specific change was made in mxe-octave that was supposed to have fixed this? Or is it purely random behavior and only looked like it was intentionally fixed?

Mike Miller <mtmiller>
Project Administrator
Tue 04 Feb 2020 03:52:30 PM UTC, comment #2: 

I see the same as you, John: The icon in the windows task bar is associated with the octave-gui.exe file directly, and therefore gets the wrong icon associated. But I don't what causes this.

Hartmut <hardy>
Tue 04 Feb 2020 03:44:02 PM UTC, comment #1: 

I built the installer from the mxe-octave revision that is tagged as octave-release-5.2.0, 8c1e1ef46ed2.  Kai built the binaries that he put on the octave.space site from 9057112edb8e.  The only differences between the two are

o  changeset:   5284:8c1e1ef46ed2
|  tag:         octave-release-5.2.0
|  user:        John Donoghue
|  date:        Mon Feb 03 14:04:19 2020 -0500
|  summary:     * src/release-octave.mk: update version/checksum for released octave
o  changeset:   5283:b34f5f5a2cac
|  user:        Markus Mützel <markus.muetzel@gmx.de>
|  date:        Sun Feb 02 12:58:44 2020 +0100
|  summary:     * src/stable-octave.mk: Bump stable-octave version number to 5.2.1
o  changeset:   5282:40f2726a5981
|  user:        Markus Mützel <markus.muetzel@gmx.de>
|  date:        Sat Feb 01 11:40:50 2020 +0100
|  summary:     Added tag octave-release-5.2.0 for changeset 9057112edb8e
o  changeset:   5281:9057112edb8e
|  user:        John Donoghue
|  date:        Wed Jan 29 08:34:50 2020 -0500
|  summary:     * installer-files/post-install.bat: create qt.conf (Bug #57679)

So I have no idea what changed to cause the problem.

I don't see multiple icons in the task bar, but I do see that the icon is associated with the octave-gui.exe file directly instead of being a shortcut to the vbs script with options, so it doesn't work properly.

I don't know enough about Windows to figure out how to fix this problem, but if someone else can provide a patch I can rebuild and upload new versions of the installers.

John W. Eaton <jwe>
Project Administrator
Tue 04 Feb 2020 01:19:15 PM UTC, original submission:  

The current Windows installer of Octave 5.2 seems to have a problem with the icon on the Windows taskbar that used to be solved several days before.

The buggy behavior itself is described here: bug 56840.

The current official installer still shows this bug:

The installer from this source (one day earlier) did NOT show this bug:

This buggy behavior very much spoils the user experience for (first time) windows users. And it bothers long time users (as me) every single time one uses Octave. Could we please fix this, and return to the good behavior of the installer on octave.space?

Hartmut <hardy>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by hardy (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-02-07 siko1056 Severity4 - Important => 3 - Normal
        Priority7 - High => 5 - Normal
        StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2020-02-05 siko1056 CategoryNone => Configuration and Build System
        Severity3 - Normal => 4 - Important
        Priority5 - Normal => 7 - High
        StatusNone => Patch Submitted

    Back to the top

    Powered by Savane 3.5