missing 'options' key in bokeh gui option hider (GRC fails on 3.8.0.0 py3.8 qt5)

[barjac]

[baz@jackodesktop ~]$ gnuradio-companion
Traceback (most recent call last):
  File "/usr/bin/gnuradio-companion", line 102, in <module>
    run_main()
  File "/usr/bin/gnuradio-companion", line 95, in run_main
    exit(main())
  File "/usr/lib/python3.8/site-packages/gnuradio/grc/main.py", line 83, in main
    platform.build_library()
  File "/usr/lib/python3.8/site-packages/gnuradio/grc/core/platform.py", line 197, in build_library
    utils.hide_bokeh_gui_options_if_not_installed(self.blocks['options'])
  File "/usr/lib64/python3.8/collections/__init__.py", line 891, in __getitem__
    return self.__missing__(key)            # support subclasses that define __missing__
  File "/usr/lib64/python3.8/collections/__init__.py", line 883, in __missing__
    raise KeyError(key)
KeyError: 'options'

[marcusmueller]

Seems to be the same issue as in #2678

[marcusmueller]

@barjac can you try to move (or delete) your /home/baz/.gnuradio folder and try again?

[marcusmueller]

@skoslowski is it supposed that there's always an options block?

[barjac]

[baz@jackodesktop ~]$ rm -rf ~/.gnuradio && gnuradio-companion
Traceback (most recent call last):
  File "/usr/lib/python3.8/site-packages/gnuradio/grc/gui/Application.py", line 102, in do_activate
    self.main_window = MainWindow(self, self.platform)
  File "/usr/lib/python3.8/site-packages/gnuradio/grc/gui/MainWindow.py", line 84, in __init__
    generate_modes = platform.get_generate_options()
  File "/usr/lib/python3.8/site-packages/gnuradio/grc/core/platform.py", line 379, in get_generate_options
    for param in self.block_classes['options'].parameters_data:
  File "/usr/lib64/python3.8/collections/__init__.py", line 891, in __getitem__
    return self.__missing__(key)            # support subclasses that define __missing__
  File "/usr/lib64/python3.8/collections/__init__.py", line 883, in __missing__
    raise KeyError(key)
KeyError: 'options'

Hangs here so killed with:

^C
Traceback (most recent call last):
  File "/usr/bin/gnuradio-companion", line 102, in <module>
    run_main()
  File "/usr/bin/gnuradio-companion", line 95, in run_main
    exit(main())
  File "/usr/lib/python3.8/site-packages/gnuradio/grc/main.py", line 88, in main
    sys.exit(app.run())
  File "/usr/lib64/python3.8/site-packages/gi/overrides/Gio.py", line 44, in run
    return Gio.Application.run(self, *args, **kwargs)
  File "/usr/lib64/python3.8/contextlib.py", line 120, in __exit__
    next(self.gen)
  File "/usr/lib64/python3.8/site-packages/gi/_ossighelper.py", line 251, in register_sigint_fallback
    signal.default_int_handler(signal.SIGINT, None)
KeyboardInterrupt

[treinking]

I'm experiencing the exact same issue. @marcusmueller suggestion:

can you try to move (or delete) your /home/baz/.gnuradio folder and try again?

That worked for me. I renamed ~/.gnuradio so I could save it's contents, then created a bare ~/.gnuradio. Running gnuradio-companion worked.

There was no config.conf in the fresh ~/.gnuradio. If I stuck the saved config.conf into the fresh ~/.gnuradio, things broke again. My config.conf has no [options] section. Not sure what goes in there, so didn't create one. Note that the config.conf on my system was almost certainly touched by GR 3.7. If I simplified my config.conf to only (i.e. no options section):

[grc]
local_block_paths = /home/baz/foobar

Then gnuradio-companion would run. Replacing local_block_paths with a global_block_paths key/value pair triggered the same error message that @barjac reports.

[treinking]

After looking a little closer, it was the global_block_paths entry in my config.conf that seems to have caused my problem. This entry was pointing to a prefix for a GR 3.7 install. I believe my config.conf was corrupted when I ran gnuradio-companion from GR 3.7.

Oops. Lesson learned.

[barjac]

None of the above 'workarounds' do anything to change the issue here.

[velichkov]

Hi @barjac,

From your thread on the mailing list I saw you are using Mageia and it turns out you are the maintainer of gnuradio package in Mageia

I've downloaded gnuradio-3.8.0.0-2.mga8.src.rpm and noticed that you are not packaging the blocks' YAML files (/usr/share/gnuradio/grc/blocks/*.yml)

Try adding %{_datadir}/%{name}/grc in %files companion section and also make sure you package all installed files.

@@ -986,6 +986,7 @@
 %{_bindir}/%{name}-companion
 %{_datadir}/applications/%{name}-grc.desktop
 %{_datadir}/mime/packages/*
+%{_datadir}/%{name}/grc
 %{_iconsdir}/hicolor/*
 %{_iconsdir}/gnome/*

[barjac]

Hi Velichkov,
Thanks - yes it looks like my packaging error some time back - I'm surprised it only just surfaced.
Fixing this has thrown up some more unpackaged files: %{_datadir}/%{name}/fec/ldpc/* which I have temporarily placed in the fec-devel rpm.
I am attaching the spec. as updated now and would really appreciate if you could cast an eye over the %files lists. It's difficult deciding what goes where in this package and although it has worked in the past I have never been sure whether it was correct.

gnuradio.txt

Spec renamed as .txt as could not attach a .spec

Thanks for your help, gnuradio-companion now runs OK,

Regards,
Barry

[velichkov]

Hi Barry,

Thanks - yes it looks like my packaging error some time back - I'm surprised it only just surfaced.

It turns out rpm-build does not complain when there are unpackaged directories.

Fixing this has thrown up some more unpackaged files: %{_datadir}/%{name}/fec/ldpc/* which I have temporarily placed in the fec-devel rpm.

I'm relatively new to gnuradio and I'm not sure how those ldpc files are get used. Debian and Fedora distributions put them in the main gnuradio package so maybe they are needed when running flowgraphs with LDPC Encoder/Decoder blocks. My advice is to move them to the %{libfec} sub-package.

I am attaching the spec. as updated now and would really appreciate if you could cast an eye over the %files lists. It's difficult deciding what goes where in this package and although it has worked in the past I have never been sure whether it was correct.

I can't see /usr/share/gnuradio/modtool/templates/gr-newmod/ in any sub-package. Other than that I can't see anything wrong but as I've said I'm relatively new so don't relay too much on my review.

gnuradio.txt

Spec renamed as .txt as could not attach a .spec

Do you keep the .spec file under source control (git/svn/...) and if yes could you share a link to the repo?

[barjac]

Hi Velichkov,
The main problem was the %exclude that caused rpmbuild to not complain, that is now gone.

OK I will move those to the %{libfec} package at least for now.

Regarding /usr/share/gnuradio/modtool/templates/gr-newmod/ - I will check tomorrow - it's late here now and I only just saw your reply.

Yes, Mageia sources are in svn and viewable on svnweb. gnuradio.spec can be seen here: http://svnweb.mageia.org/packages/cauldron/gnuradio/current/SPECS/gnuradio.spec?revision=1458620&view=markup

I have not committed any updates yet regarding this issue but will no doubt do it tomorrow.
Cauldron will be eventually released as Mageia 8 but it's a few months away yet, so no rush.

Many thanks for your help
Barry

[barjac]

Hi Vasil,
It seems there is a build problem regarding /usr/share/gnuradio/modtool/templates/gr-newmod/
if you look at http://mtf.duckdns.org/pub/linux/barjac/distrib/cauldron/x86_64/log/gnuradio-3.8.0.0-3.mga8_bcj.src.rpm/build.0.20191118122316.log and search for "modtool/templates" you will see it. Is this an upstream issue?
I will commit my current spec changes once that test build completes.
Cheers,
Barry

[velichkov]

Hi Barry,

It seems there is a build problem regarding /usr/share/gnuradio/modtool/templates/gr-newmod/
if you look at http://mtf.duckdns.org/pub/linux/barjac/distrib/cauldron/x86_64/log/gnuradio-3.8.0.0-3.mga8_bcj.src.rpm/build.0.20191118122316.log and search for "modtool/templates" you will see it. Is this an upstream issue?

I see only these two warnings

$ grep "modtool/templates" build.0.20191118122316.log 
/home/baz/rpmbuild/BUILD/gnuradio-3.8.0.0/gr-utils/python/modtool/templates/gr-newmod/docs/doxygen/other/group_defs.dox:1: warning: group block: ignoring title "GNU Radio HOWTO C++ Signal Processing Blocks" that does not match old title "GNU Radio C++ Signal Processing Blocks"
/home/baz/rpmbuild/BUILD/gnuradio-3.8.0.0/gr-utils/python/modtool/templates/gr-newmod/docs/doxygen/other/main_page.dox:1: warning: found more than one \mainpage comment block! (first occurrence: /home/baz/rpmbuild/BUILD/gnuradio-3.8.0.0/docs/doxygen/other/main_page.dox, line 12), Skipping current block!

In my opinion you could safely ignore them for now.

Here is the real problem

-- Configuring gr_modtool support...
--   Dependency ENABLE_GNURADIO_RUNTIME = ON
--   Dependency ENABLE_PYTHON = ON
--   Dependency CLICK_FOUND = TRUE
--   Dependency CLICK_PLUGINS_FOUND = FALSE
--   Disabling gr_modtool support.
--   Override with -DENABLE_GR_MODTOOL=ON/OFF


-- ######################################################
-- # Gnuradio disabled components      
-- ######################################################
--   * sphinx
--   * gr_modtool

For gr_modtool you need to install click-plugins. It seems there is no Mageia package so probably you'll need to package it as well. And also consider adding -DENABLE_GR_MODTOOL=ON to the cmake's arguments in the .spec file.

-- Configuring sphinx support...
--   Dependency SPHINX_FOUND = FALSE
--   Disabling sphinx support.
--   Override with -DENABLE_SPHINX=ON/OFF

And similarly for sphnix you need to install python3-sphinx which seems to be available in Mageia and add -DENABLE_SPHINX=ON in the .spec

It's also interesting that the qa_qtgui test is failing probably because you are building on a headless system (without X server) but this does not stop the building of the RPMs.

test 218
        Start 218: qa_qtgui

218: Test command: /usr/bin/sh "/home/baz/rpmbuild/BUILD/gnuradio-3.8.0.0/build/gr-qtgui/python/qtgui/qa_qtgui_test.sh"
218: Test timeout computed to be: 10000000
218: /home/baz/rpmbuild/BUILD/gnuradio-3.8.0.0/build/gr-qtgui/python/qtgui/qa_qtgui_test.sh: line 9: 22991 Aborted                 (core dumped) /usr/bin/python3 -B /home/baz/rpmbuild/BUILD/gnuradio-3.8.0.0/gr-qtgui/python/qtgui/qa_qtgui.py
218/235 Test #218: qa_qtgui .....................................***Failed    0.80 sec

The following tests FAILED:
    218 - qa_qtgui (Failed)
Errors while running CTest
+ :
+ RPM_EC=0
++ jobs -p
+ exit 0

Does this test fail when you build the package on your desktop machine? If no than it's probably better to run the tests through xvfb-run and remove || : as this suppress the failures, something like

%check
%ifnarch %arm 
cd build
export LD_LIBRARY_PATH=%{buildroot}%{_libdir}
%ifarch x86_64
  xvfb-run ctest -V 
  %else
  xvfb-run ctest -V -E qa_fecapi_ldpc
  %endif
%endif

[barjac]

Hi Vasil,
Many thanks for your help, all understood. I somehow had the impression that gr-modtool was deprecated but re-reading the release notes I now realize that is not the case!
Because of the long build time on our build system I intentionally don't let the odd test failure on a particular arch break the whole build, I make a point of looking at the test results after re-builds.
Since my original issue is resolved I will now close this ticket.

Cheers,
Barry