Tue 24 Jan 2017 09:50:25 PM UTC, comment #15:
Changing status to "fixed"
|
Thu 26 Nov 2015 05:02:03 PM UTC, comment #14:
Closing the bug for core Octave seems fair enough as from comment #4 it appears the issue / fix is in OF packages.
The windows pkg could use a new release anyway (there are several other fixes in mxe-octave for it). I haven't seen posts from Michael Goffioul (windows pkg maintainer) for a long time, but I'll ping him; I could make a release for him.
I don't know if odepkg has been fixed. It also needs fixes to drop the solvers that went to core.
|
Thu 26 Nov 2015 04:51:04 AM UTC, comment #13:
No response to request for test in June, 2015. Closing report.
|
Wed 10 Jun 2015 02:37:18 PM UTC, comment #12:
Sorry please try with netcdf-1.0.7 (netcdf-1.0.8 does not exist yet).
|
Wed 10 Jun 2015 02:33:41 PM UTC, comment #11:
I made those changes in netcdf in response to bug #44837.
https://sourceforge.net/p/octave/code/12816/
In particular, the build process use octave-config:
Instead of OCTAVE_EVAL previously:
Can somebody check if the issue in creating the history file persists with netcdf 1.0.8 (released today)?
Thanks!
|
Tue 02 Jun 2015 04:28:33 PM UTC, comment #10:
Retagging release from 4.0.0-rc1 to 4.0.0.
|
Sat 21 Mar 2015 02:46:51 PM UTC, comment #9:
@jwe: That's a possible fix.
In fact it seems that the history timestamp is written to the history file, but that's all. When Octave runs commands via stdin or via --eval, history is not actually saved but the history file is updated with another timestamp line. So that's very superfluous.
|
Sat 14 Mar 2015 05:49:35 AM UTC, comment #8:
Maybe we should only enable history for sessions that appear to be interactive?
|
Sat 14 Mar 2015 03:27:36 AM UTC, comment #7:
Just one more detail, the difference is the HOMEPATH environment variable. It is set to the user's correct profile directory in Windows and in Octave run normally. But when the bash shell runs the HOMEPATH variable is set to the string "\", so Octave running from a bash shell tries to use C:\ as the home directory.
|
Sat 14 Mar 2015 03:21:40 AM UTC, comment #6:
The error occurs because octave is executed from within the configure scripts for these packages but the --no-history option is not used.
The following is what I see in a Windows XP command window:
This is the environment that the Octave interpreter is run in from the configure scripts (being run by bash) when packages are built on Windows.
This should be fixed by adding the --no-history (or -H) options to the octave command lines used when building these packages.
|
Sat 14 Mar 2015 03:04:33 AM UTC, comment #5:
These three packages are the only ones in the current list of packages that use an old build structure with Makeconf.in and configure.base files in the src directory. I have no idea what in there is making the history timestamp be written to C:\, but maybe that's a clue.
|
Sat 14 Mar 2015 02:48:34 AM UTC, comment #4:
Ok, I just stepped through the packages in build_packages one by one to find the ones that do create C:\.octave_hist. The only packages in the 4.0.0-rc1 bundle that cause C:\.octave_hist to be created are:
Of these, odepkg and windows fail to install, but netcdf works. There must be something common between these 3 packages that the other forge packages do not share.
|
Sat 14 Mar 2015 02:09:58 AM UTC, comment #3:
Coming back to this bug, I still see C:\\.octave_hist being created when running build_packages.m with 4.0.0-rc1.
Notably, the windows package itself does not install for me with 4.0.0-rc1, and when the installation fails, I get 3 timestamp lines inserted into C:\\.octave_hist. When other packages fail to compile and install, e.g. linear-algebra or image, I get no such lines in the file.
If I roll back to mxe-octave version 3.8.2 and try the same thing, the windows package installs successfully and I still get 3 lines in C:\\.octave_hist.
If I comment out the windows package in build_packages.m, I still get the C:\\.octave_hist file showing up, so there must be one or two other packages responsible also.
|
Sun 19 Jan 2014 07:44:20 PM UTC, comment #2:
I wish I knew.
All I see is that something in Octave doesn't honor Octave's history_file setting.
At work Octave is installed in D:\octave\octave-3.8.0, so also from there I see no reason that a history file is supposed to be in C:/
Maybe it is a bug in pkg.m or in the windows package.
I browsed through the latter but cannot find anything related; the only thing is that it still contains svn cruft (a file .svnignore)
|
Sun 19 Jan 2014 07:00:23 PM UTC, comment #1:
Any idea where this is coming from? I see a C:/.octave_hist file in my Windows XP VM, so yes it does appear that some part of the build_packages process is changing HOME or history_file temporarily.
|
Tue 07 Jan 2014 11:30:39 AM UTC, original submission:
While running "build_packages" from a just installed mxe-built Octave-3.8.0 in Windows 7, I get:
so while history_file is supposed to be H:\.octave_hist, Octave tries to write to C:\.octave_hist (and that root dir of C: is not writable at my work PC)
The build_packages script terminates (aborts) here BTW.
(FTR, as can be expected the Windows package didn't seem to be properly installed. After manually running
the windows package works fine - and I didn't see the history_file errors then).
|