bugGNU Octave - Bugs: bug #60048, [octave forge]...


bug #60048: [octave forge] (fuzzy-logic-toolkit) fails to install

Submitter:  Seamus <seamus>
Submitted:  Sat 13 Feb 2021 06:55:01 AM UTC
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Installation Failure
Status:  Duplicate Assigned to:  None
Originator Name:  Seamus Open/Closed:  * Closed
Release:  * 5.2.0 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Wed 17 Feb 2021 02:07:29 AM UTC, comment #15: 

@Philip: Thanks for the ideas, to leave this off-topic thread, I copied the relevant ideas to the respective bug tracker https://github.com/gnu-octave/octave-buildbot/issues/8 We can continue discussing there.

Kai Torben Ohlhus <siko1056>
Group Member
Tue 16 Feb 2021 07:53:02 PM UTC, comment #14: 

For completeness, the relevant code to make the tarballs isn't that much, so could (theoretically) also be invoked for nightlies that build the regular installers with all prebuilt & installed packages by just copying it into place.

But maybe (parts of) the code are in tools/makeinst_script.sh, which is an NSIS installer script; I haven't looked at it for a long time.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 16 Feb 2021 07:45:46 PM UTC, comment #13: 

@Kai, comment #8:
If mxe-octave builds are made with --enable-binary-packages=yes", well, then updated binary packages are included in the build, installed and all, but not produced as tarballs. All the user needs to do to use package <package> is "pkg load <package>".

However, if built with "--enable-binary-packages=no", Octave does build updated packages as tarballs but doesn't install them. After installation of the Octave binary the user must first run "build_packages" and then Octave will install them one by one (could take some time).
So in this case fully updated packages are created. But mind you, AFAIK only updated in the sense of "compatible with the bundled Octave release" - it's not so that development snapshots of OF packages are created.

So the infrastructure for updating packages is in place, but is used only when no binary packages are built.
I think (could be wrong though) that the relevant stuff is in binary-dist-rules.mk

Philip Nienhuis <philipnienhuis>
Group Member
Tue 16 Feb 2021 10:33:38 AM UTC, comment #12: 

So it looks like you will waste your time on this. :-)

I have read the entire thread. But it looks like you did not.
Octave Forge is not part of the Octave project. It is just a collection of packages some (independent) developers supplied for free.
I'm not associated with Octave Forge. But I still try to help out here and there if there is an issue in some of the packages.
If a package maintainer decides to abandon a package, there is not much the Octave project can do.

Again "Octave Forge" is not Octave.
Kai already pointed to a discourse thread that raised this issue. But unfortunately fixing this would require lots of time for several people.
Octave Forge --- like Octave --- is an open source project. So if you think that the Octave Forge project can be improved (and I agree there is probably lots of room for improvement), you are free to contribute constructively.
Your repeated rant doesn't help to motivate me to spend my spare time with you though honestly. But if you channel all of that energy into something positive, there is a chance that something good will come out of this.

Markus Mรผtzel <mmuetzel>
Group administrator
Tue 16 Feb 2021 10:10:59 AM UTC, comment #11: 

@Markus says, "we might encounter persons with similar demeanor as the one here who'll start seeing issues"

Yes, you might. Just as I might encounter persons with demeanor similar to yours - those who are too lazy to fulfill their obligations. It seems you too have no appreciation of the concept of "truth in advertising". I'll say this again, as you've apparently not read the entire thread: If the Octave project is going to advertise these packages, they should at least install properly. They should not be left in a broken state for 2+ years, leaving a trail of dozens of forum questions and bug reports with no resolution. Make all the excuses you want, this fits easily and completely within the definition of "failure". If you can't or won't maintain any sort of quality control, then you have failed at the job you volunteered to do. 

I'm sorry if that sounds harsh, but it's true. I did not come here to insult anyone. I came here to get someone's attention - to learn why this package remains broken for over 2 years. Now I know: You prefer "demeanor" over results. I would say that if this project is worth doing at all, it should be worth doing properly - at least honestly. If you have known broken or defective packages, they should be sidelined or marked as such. This is no more than simple honesty and common courtesy.  But yes, Markus - by all means, you should insult my "demeanor" - that allows you to avoid facing your sloth and neglect.

In closing, since it's clear nothing constructive is going to be done to address my bug report, I would like to see it closed to further comment.

Seamus <seamus>
Tue 16 Feb 2021 08:55:19 AM UTC, comment #10: 

> Could the patched packages be saved and made available somewhere, and/or maybe linked to from the OF website?

Many of the patches applied as part of the MXE Octave build process don't bother to target a wide range of Octave versions (because we know which versions we are building with MXE Octave).
Would those patches be applied upstream as they are or would we provide these patched packages, we might encounter persons with similar demeanor as the one here who'll start seeing issues using older Octave versions.

I now see more clearly why Kai was unhappy with how Octave Forge is organized and associated with the Octave project. But I currently see no good solution for this apart from completely cutting ties to Octave Forge (which would be unfortunate).

Markus Mรผtzel <mmuetzel>
Group administrator
Tue 16 Feb 2021 06:25:02 AM UTC, comment #9: 


It sounds like you are perfectly happy with things as they are. I think that's shameful, but I won't waste any more of my time on this.

Seamus <seamus>
Tue 16 Feb 2021 05:56:30 AM UTC, comment #8: 


> One solution is to "draw a line" between those packages that are maintained, and those that are not.

This would indeed be great.  But who should draw this line and where?  Some packages are still working with minor effort and patches (like fuzzy-logic-toolkit) and some users are still running older versions of Octave where the package installs seamlessly and they would be unhappy to find them removed or deprecated.  Furthermore, the Octave package tool (pkg) is deeply interlinked with the clumsy outdated Octave Forge infrastructure.  Making changes to pkg as it is now would only affect new versions of Octave released in probably next year.

> I have assumed that you are the maintainer of this project, and that you have the authority to make the decisions I've recommended. If that's not the case, could you please alert the responsible party(ies)?

True, I have some authority and would love to do many changes, but also my time is limited.  The Octave Forge legacy code base is huge and catching up there is far more than a rainy weekend project.  Moreover, there is no party left to inform.  Most of the original Octave Forge maintainers jumped off the project.  If you have any interest in making your ideas become reality, please tell us where you want to start working on.

@Philip: If I understand the mxe build system right, the OF-packages are patched without creating another release tarball again.  At least I do not find any patched tarballs on my octave.space workers.

Then I am afraid the effort creating the patched archives compared to properly apply those patches to the respective repos and make a maintenance release might almost be equal ๐Ÿ˜“

Kai Torben Ohlhus <siko1056>
Group Member
Mon 15 Feb 2021 02:50:06 PM UTC, comment #7: 

Another aspect here is that in the Windows builds/installers a fair nr. of Octave package are included that have been "updated" (by dedicatedly patching them during the cross-build) so that they at least build and work with newer Octave releases included in the Windows installers.
The main mxe-octave contributor/maintainer who does this didn't add functionality, so functionally the pertinent packages are just like the formally released ones. But formally they obviously aren't.

Crossbuilds made with "--enable-binary-packages=no" don't have cross-built & installed OF-packages but do include ready-to-install OF packages that are "fully" patched. Currently the nightlies are built with "--enable-binary-packages=yes".
During the build the package are patched first and then built & installed in the usual way.
Could the patched packages be saved and made available somewhere, and/or maybe linked to from the OF website? Of course there may be all kind of objections but this might help to mitigate bug reports like this one.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 14 Feb 2021 09:14:35 PM UTC, comment #6: 


It would be a shame for all of Tasos' diplomacy to go for naught, and so I would like to suggest another solution to end this bickering.

I understand your issues with resources. My issue is is also with resources: my time. Open source is a force for many good things, but false claims that waste time need to be minimized. To ignore obvious issues, and allow false claims to stand in public for years can not possibly serve anyone's best interests.

One solution is to "draw a line" between those packages that are maintained, and those that are not. In that way, you "set off" non-maintained packages, and put prospective users on alert that there are/may be issues in these packages that preclude their correct function (or even installation).  Let them know that they are "on their own" if they choose to attempt installation. By doing this, expectations will be properly set.

If the situation with maintenance is as you describe it, I submit this will be a more efficient use of your time, and benefit those who may be interested in becoming users and supporters of Octave.

I'll leave it you. I hope you make a good decision, but I must say that the compromise you've proposed below seems ill-advised. First, it's been said that the solution is already in the repo - but the repo has not been released. Second, postponing this until a maintainer shows up is a solution that falls in the category of "Pray for a Miracle".

Finally, it's just now occurred to me that I have made an assumption that should be confirmed: I have assumed that you are the maintainer of this project, and that you have the authority to make the decisions I've recommended. If that's not the case, could you please alert the responsible party(ies)?

Seamus <seamus>
Sun 14 Feb 2021 03:43:23 AM UTC, comment #5: 

@Tasos: You are right.  Many of Octave Forge's packages are unfortunately not actively maintained anymore.  Last year I summarized about this issue https://octave.discourse.group/t/online-developer-meeting-2020-11-10-the-future-of-octave-packages/349

Especially, that core Octave gets "blamed" for the lack of maintenance in some package code, written by someone not (or no longer) involved into Octave development, is very unfortunate ๐Ÿ˜“  There have been made decisions in the past that make those packages look like an integral part of core Octave (same bug tracker, same logo, etc.), which is far from the truth.  For example, nobody would get the idea to blame the Python developers if some pypi package did not work.

Maintaining those about 70 packages is far beyond the development power of core Octave maintainers.  Despite simple installation issues, some of these packages require domain knowledge for fixing bugs within them.  And releasing those Octave Forge packages has been made too tedious unpaid work within Octave Forge infrastructure.  John Donoghue is really doing a lot of work keeping this legacy code heritage into shape, and I help out there as much as I can, too, but there is still too much backlog left to catch up soon, and the frustration level rises each year ๐Ÿ˜ฑ

As a compromise, I reopen bug #53549 with a release/call-for-maintainer request as this item got too much off topic thanks to me ๐Ÿ˜‡

Kai Torben Ohlhus <siko1056>
Group Member
Sun 14 Feb 2021 12:07:17 AM UTC, comment #4: 

comment #2:

> Closing as duplicate of bug #53549.

And you criticize my behavior? Your response is to leave it "as-is"... for what - another 2 or 3 years?

If I take something on, I try to do it well. I expect the same of others. When I see this sort of thing, I try to get someone's attention. And so it seems I have. I've gotten the attention of someone who really doesn't care.

Good for you. A "teacher" are you? Thank god I'm beyond your "teaching".

Seamus <seamus>
Sat 13 Feb 2021 10:21:04 PM UTC, comment #3: 

Hi Kai. I spotted this bug after the discussion here https://stackoverflow.com/questions/57509510/fuzzy-logic-toolkit-install-problem-in-octave?noredirect=1#comment117003208_57509510 where this user also posted a comment there along the same lines.

While I agree with you that Seamus's frustration probably got the better of him slightly, please note that the original post he commented on on StackOverflow is almost 2 years old!

It appears John Donoghue who fixed the bug on the development repository, hasn't actually updated the package release itself. Which means users who have tried to install this package via forge have been hit with the same error message for the last 2 years.

There is even a frustrated "1 out of 5 stars" not-so-recent message on the project's webpage on sourceforge with the same message.

It is weird that this bug has not been addressed after all this time, especially when it has already been fixed in dev 2 years ago!

So therefore, while I acknowledge that Seamus's tone may have come across as a bit rude, I don't think simply schooling him and closing this ticket is the appropriate response either.

Could you perhaps notify John (or anyone with maintenance access) to convert the development to a 0.4.6 release? I think at the very least this ticket should remain open until this has taken place, and only closed with an appropriate response here that this has now taken place. After all, bug #53549 is about the bug in the code, whereas this bug is about the package still not being updated and thus causing installation to fail.

Many thanks.

Tasos Papastylianou <tpapastylianou>
Sat 13 Feb 2021 11:32:35 AM UTC, comment #2: 

Closing as duplicate of bug #53549.

Kai Torben Ohlhus <siko1056>
Group Member
Sat 13 Feb 2021 11:23:40 AM UTC, comment #1: 

Please grab another coffee โ˜• before you continue ๐Ÿ˜Ž

It is no problem being a new user with Octave or new to free and open-source software, being polite, patient and a little skilled you can make a lot out of Octave for free.  A paid alternative to Octave should be easy to find by a web search engine of your choice ๐Ÿ˜‰

To you initial request


you received a helpful reply within less than a day.

Your other problems are really trivial even for my students to solve.  Homework assignment: please read the following error message and mark the right solution (time 5 seconds).

> >> pkg install statistics -forge
> error: the following dependencies were unsatisfied:
>   statistics needs io >= 1.0.18

[ ] Create an account at the software bug tracker and be as rude as possible.
[ ] pkg install -forge io

Kai Torben Ohlhus <siko1056>
Group Member
Sat 13 Feb 2021 06:55:01 AM UTC, original submission:  

Ubuntu 20.04, Octave ver 5.2.0

This is the same issue that was originally reported approx 2 years ago. It's been reported several times; all the bug reports are closed - claiming it's "fixed" - but of course it's not.

FWIW, I've never used Octave until today. I d/l and installed Octave today for the first time - specifically because I wanted to use the fuzzy logic package. I've wasted most of the day on this, so this bug report will reflect some of that frustration and disappointment. Nothing new here, but let's go through the motions, shall we?

>> pkg install fuzzy-logic-toolkit -forge
parse error near line 165 of file /home/seamus/octave/fuzzy-logic-toolkit-0.4.5/defuzz.m

  anonymous function bodies must be single expressions

>>>   y_val = @(y_val) if (y_val == max_y) 1 else 0 endif;

error: called from
    doc_cache_create>create_cache at line 109 column 20
    gen_doc_cache_in_dir>@<anonymous> at line 143 column 16
    doc_cache_create>gen_doc_cache_in_dir at line 144 column 9
    doc_cache_create at line 55 column 12
    install>generate_lookfor_cache at line 802 column 5
    install at line 231 column 7
    pkg at line 441 column 9

Just for grins, I tried to install 3 other Octave packages, and... ALL FAILED TO INSTALL:

>>pkg install signal -forge
warning: creating installation directory /home/seamus/octave
warning: called from
    install at line 30 column 5
    pkg at line 441 column 9
error: the following dependencies were unsatisfied:
   signal needs control >= 2.4
>> pkg install data-smoothing -forge
error: the following dependencies were unsatisfied:
   data-smoothing needs optim >= 1.0.3
>> pkg install statistics -forge
error: the following dependencies were unsatisfied:
   statistics needs io >= 1.0.18

This Octave project appears to be a joke, and a sham - perhaps the most useless waste of bandwidth in the universe? Keep up the good work.

On second thought, perhaps I'm being too harsh. Let's try one more:

>> 2+2
ans =  4

 Yeah - good work people... I knew you could do it! :) lol

Seamus <seamus>


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

Attach Files:

No files currently attached


   bug dependencies.

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 tpapastylianou (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-02-16 seamus Carbon-CopyRemoved 238241 -
    2021-02-16 seamus Carbon-CopyRemoved -email is unavailable- -
    2021-02-13 siko1056 Dependencies- Depends on bugs #53549
    2021-02-13 siko1056 StatusNone Duplicate
        Open/ClosedOpen Closed
    2021-02-13 siko1056 Summaryfuzzy-logic-toolkit fails to install [octave forge] (fuzzy-logic-toolkit) fails to install
    2021-02-13 seamus Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code