crash in 0.116 on py3 with g_signal_newv: assertion 'is_valid_signal_name (signal_name)'

[nullr0ute]

Seeing the following crash on F-32 with 0.116 using python3

/usr/lib64/python3.8/site-packages/gi/types.py:220: Warning: g_signal_newv: assertion 'is_valid_signal_name (signal_name)' failed
  _gi.type_register(cls, namespace.get('__gtype_name__'))
Traceback (most recent call last):
  File "/usr/lib64/python3.8/runpy.py", line 193, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib64/python3.8/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.8/site-packages/jarabe/main.py", line 68, in 
    from jarabe.view import keyhandler
  File "/usr/lib/python3.8/site-packages/jarabe/view/keyhandler.py", line 32, in 
    from jarabe.journal import journalactivity
  File "/usr/lib/python3.8/site-packages/jarabe/journal/journalactivity.py", line 36, in 
    from jarabe.journal.journaltoolbox import MainToolbox
  File "/usr/lib/python3.8/site-packages/jarabe/journal/journaltoolbox.py", line 44, in 
    from sugar3.graphics.objectchooser import FILTER_TYPE_MIME_BY_ACTIVITY
  File "/usr/lib/python3.8/site-packages/sugar3/graphics/objectchooser.py", line 32, in 
    from sugar3.activity.activity import PREVIEW_SIZE
  File "/usr/lib/python3.8/site-packages/sugar3/activity/activity.py", line 287, in 
    class Activity(Window, Gtk.Container):
  File "/usr/lib64/python3.8/site-packages/gi/types.py", line 229, in __init__
    super(GObjectMeta, cls).__init__(name, bases, dict_)
  File "/usr/lib64/python3.8/site-packages/gi/types.py", line 208, in __init__
    cls._type_register(cls.__dict__)
  File "/usr/lib64/python3.8/site-packages/gi/types.py", line 220, in _type_register
    _gi.type_register(cls, namespace.get('__gtype_name__'))
RuntimeError: could not create signal for _closing

[quozl]

Is already fixed by https://github.com/sugarlabs/sugar-toolkit-gtk3/commit/88adb38a4241aa5423a9cefae9b4b11305bb61c5 and will be in next release.

[nullr0ute]

That works in a test build \o/ but seems to fail for i686 (OK for x86/arm) when pushed to the build system. Aren't sure why, might be a timing/linking/introspection issue. https://koji.fedoraproject.org/koji/taskinfo?taskID=41336358

[nullr0ute]

With a couple of attempts I got a build. BTW what's the schedule for the next release?

[quozl]

Good, thanks.

No schedule, sorry. I'm holding off. I regularly test master branches on Debian and Ubuntu. We seem to have lost anybody willing to test master branches on Fedora Rawhide, hence all these bugs in 0.116, which means releasing early would likely make things worse; and so I'm not willing to release until we have a volunteer to focus on Fedora.

https://github.com/sugarlabs/GSoC/blob/master/Ideas-2020.md#fedora-advocacy-for-sugar describes the role needed, in case we can get a student interested in a short term engagement. It sucks to have to rely on students though.

[nullr0ute]

I feel it's unfair to state there is an unwilling to test master branches on Fedora. There's a complete lack of time, which is not the same as unwillingness, but Fedora has consistently gone above and beyond to ensure there's regular releases of sugar over a LONG time. Where's the help from the Ubuntu community? There's one person (Chihurumnaya) now actively contributing and another (Alex) who says he will be he's been mostly MIA.

[aperezbios]

I also agree it's unfair. The will exists, it's moreso a matter of time. For instance, I just attended FOSDEM to represent Sugar Labs, a committment of time that involved 96+ hours, which is time I can't spend working for my employer. As an update, Ibiam (Chihurumnaya) has a stock install of F32 installed as of last night. I spoke with him as I was flying back from Brussels, yesterday afternoon.

[quozl]

Thanks.

Sorry, the word willing was my discernment based on the near zero evidence of testing, and reading about regressions months after release. A better word would be effective testing.

I don't work in the Debian and Ubuntu packaging communities. I know there's effective testing for Debian and Ubuntu for Sugar, because I end up having to do it myself; during pull request review, for my private packages, for Sugar Live Build, and in the release process. I don't have time to add Fedora Rawhide to that testing, and don't maintain machines for that configuration.

If you are fine with the historical pattern of Fedora regressions after each release, I can remove it from my reasons not to release. You will then always have to deal with regressions by patching. I'm surprised if you choose this, because all the new-release push I've had from you seems to suggest packaging patches are not welcome.

@chimosky, you've been mentioned here; do you plan to test the master branches of Sugar components? If so, how will I know you've done it?

[aperezbios]

Personally, I am strongly in favor of releasing far more often than we do. The 0.116 release was now four months ago, and mainline incorporates a number of fixes for known bugs since the release of 0.116. I do not understand the rationale for not releasing often. There are going to be bugs either way, but the fewer patches need to be managed against mainline/release in any given package is a win for the packager, in my opinion. It would be great to release 0.117 in the next few days, so it can be incorporated into F32, if practical.

[chimosky]

@chimosky, you've been mentioned here; do you plan to test the master branches of Sugar components? If so, how will I know you've done it?

Yes I plan to test the master branches of Sugar components and create issues upstream where necessary also I'll update the community - via the mailing list - on new releases.

[quozl]

Thanks. But only on new releases? Oh, that's unfortunate. That's not what I'm looking for. I'm looking for testing of the Sugar components before new releases, in order to better support a release process and ensure the release works without problems on Fedora Rawhide at the time.

[chimosky]

I'll be doing that.

[quozl]

Good, thanks. Please report testing, even if no issues occur.