Bug 1411165 - GUI does not display correctly and locks up when scrolling down to make alternative mapsets visible in GRASS GIS d.vect and d.rast commands
Summary: GUI does not display correctly and locks up when scrolling down to make alter...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: wxGTK3
Version: 28
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Scott Talbert
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-08 22:31 UTC by rick
Modified: 2019-05-28 20:51 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-28 20:51:01 UTC


Attachments (Terms of Use)
Map location and mapsets for testing (7.42 MB, application/x-xz)
2017-05-20 22:26 UTC, rick
no flags Details

Description rick 2017-01-08 22:31:00 UTC
This was reported on the GRASS bug track and Markus Neteler suggested the bug be reported here. This is what I reported to GRASS:

When scrolling down map lists in the map selection drop-down window in the first (Required) tab of d.vect and d.rast, the GUI locks up upon any of the additional mapsets that are made accessible (shown in blue in the GUI) being exposed in the GUI, except for the PERMANENT mapset, which appears already expanded and does not cause the problem. While so far as I can tell GUI lock-up may NOT occur about 5% to 10% of the time when only exposing the unexpanded additional mapsets, it appears to occur 100% of the time if the unexpanded mapsets are clicked upon. The additional mapsets only appear as unexpanded. The GUI also displays oddly on occasion, whereby when moved over GUI buttons the mouse pointer appears as a box with two arrows at 45 degrees, and the scroll bar in the above noted drop-down window fails to appear, such that scrolling can only be done using the mouse wheel.

Once locked up, trying to shut down GRASS the normal way is impossible because while the "Do you want to quit GRASS" window opens after clicking on the GUI's x (top-right corner), that window is also non-responsive.

When the GRASS GUI is locked up, Xorg uses 100% of one CPU core, but immediately drops to 0% after shutting GRASS down by typing Ctrl-D in the console.

I am also experiencing the blacked-out check-boxes which were reported elsewhere and are being dealt with upstream by M. Neteler re. the wxGTK3 repeated "Gtk-CRITICAL" warning bug. This leads me to question whether what I am describe in the first paragraph above may not also be related to wxGTK3??

I experience the very same defects in GRASS 7.2.0svn (r70142), which I have compiled myself, as well as with GRASS 7.0.4-2.fc25.x86_64, which I am running as supplied directly from the GRASS Fedora repository.

This problem became apparent only after upgrading from Fedora 21 to Fedora 25. All other computer functions seem to work correctly since the upgrade.

I am running kernel 4.8.15-300.fc25.x86_64, AMD Phenom II X4 processor, 16 GiB memory, Gnome 3.22 on X server, Nvidia GeForce? GT 740 GPU with nvidia driver from rpmfusion.


When Fedora pushed wxGTK3 to 3.0.2-31 and Xorg-Xserver to 1.19.0-13, that appeared to fix the blacked-out check-box issue. However, the problems with mouse pointer drawing and GUI lock up by the d.rast and d.vect map selection drop-down windows remain. 


These are the messages on the terminal when the problem occurs:

 (wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton?

(wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton?

(wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton? 


When asked by the GRASS team to test wxpython demo, specifically ComboCtrl, TreeCtrl Popup, as these should be the same widget as used in d.rast and d.vect, this is what I got on the terminal, following which M. Neteler suggested I report here:

[rick@localhost ~]$ python /usr/share/doc/wxPython-docs/demo/TreeMixin.py
Python 2.7.12 (default, Sep 29 2016, 12:52:02) 
[GCC 6.2.1 20160916 (Red Hat 6.2.1-2)]
wx.version: 3.0.2.0 gtk3 (classic)

(TreeMixin.py:520): Gtk-CRITICAL **: gtk_widget_set_size_request: assertion 'height >= -1' failed

(TreeMixin.py:520): Gtk-CRITICAL **: gtk_widget_get_preferred_width_for_height: assertion 'height >= 0' failed

(TreeMixin.py:520): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width 18 and height -8
Traceback (most recent call last):
  File "/usr/share/doc/wxPython-docs/demo/TreeMixin.py", line 199, in OnPageChanged
    oldTree = self.GetPage(event.OldSelection)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk3/wx/_core.py", line 13536, in GetPage
    return _core_.BookCtrlBase_GetPage(*args, **kwargs)
ValueError: in method 'BookCtrlBase_GetPage', expected argument 2 of type 'size_t'
Traceback (most recent call last):
  File "/usr/share/doc/wxPython-docs/demo/TreeMixin.py", line 199, in OnPageChanged
    oldTree = self.GetPage(event.OldSelection)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk3/wx/_core.py", line 13536, in GetPage
    return _core_.BookCtrlBase_GetPage(*args, **kwargs)
ValueError: in method 'BookCtrlBase_GetPage', expected argument 2 of type 'size_t'

[rick@localhost ~]$ python /usr/share/doc/wxPython-docs/demo/ComboCtrl.py
Python 2.7.12 (default, Sep 29 2016, 12:52:02) 
[GCC 6.2.1 20160916 (Red Hat 6.2.1-2)]
wx.version: 3.0.2.0 gtk3 (classic)
17:36:36: ListCtrlComboPopup.Init
17:36:36: ListCtrlComboPopup.LazyCreate
17:36:36: ListCtrlComboPopup.Create
17:36:41: ListCtrlComboPopup.GetAdjustedSize: 250, 400, 934
17:36:41: ListCtrlComboPopup.OnPopup
17:36:41: ListCtrlComboPopup.SetStringValue
17:36:44: ListCtrlComboPopup.GetStringValue
17:36:44: ListCtrlComboPopup.SetStringValue
17:36:44: ListCtrlComboPopup.OnDismiss

(ComboCtrl.py:568): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed

(ComboCtrl.py:568): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed

(ComboCtrl.py:568): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed

(ComboCtrl.py:568): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion 'index >= 0 && index <= layout->length' failed

[rick@localhost ~]$ python /usr/share/doc/wxPython-docs/demo/TreeCtrl.py
Python 2.7.12 (default, Sep 29 2016, 12:52:02) 
[GCC 6.2.1 20160916 (Red Hat 6.2.1-2)]
wx.version: 3.0.2.0 gtk3 (classic)
17:37:27: OnItemExpanded: Item 3
17:37:29: OnItemExpanded: item 3-b
17:37:31: OnSelChanged: item 3-b-0
17:37:35: OnItemExpanded: item 3-d
17:37:38: OnSelChanged: item 3-d-1
17:37:41: OnSelChanged: The Root Item
17:37:44: OnItemExpanded: Item 0
17:37:46: OnSelChanged: item 0-b
17:37:47: OnItemExpanded: item 0-b
17:37:48: OnSelChanged: item 0-b-1
[rick@localhost ~]$ 


I will continue to coordinate with the GRASS team as it appears they may not yet have closed this bug.

Comment 1 rick 2017-01-08 22:36:31 UTC
Forgot to mention, this is GRASS bug #3242

Comment 2 Scott Talbert 2017-01-09 02:30:41 UTC
Can I have a little more description of how to reproduce this?  When I open d.rast and open the "Name of raster map to be displayed:" drop down, I only see two items, Mapset: talbert and Mapset: PERMANENT, and they are both blue already.

Comment 3 Scott Talbert 2017-01-09 02:43:53 UTC
BTW, these errors:

 (wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton?

(wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton?

(wxgui.py:25252): Gtk-CRITICAL : gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton? 

are not likely related to the main problem you are reporting.  These are likely widget sizing issues that will have to be fixed in GRASS.

Comment 4 rick 2017-01-09 14:24:52 UTC
(In reply to Scott Talbert from comment #2)
> Can I have a little more description of how to reproduce this?  When I open
> d.rast and open the "Name of raster map to be displayed:" drop down, I only
> see two items, Mapset: talbert and Mapset: PERMANENT, and they are both blue
> already.

In the GRASS layer manager, click: Settings-->GRASS working environment-->Mapset access, then select additional mapsets to want to be able to access. Then when you open either d.rast or d.vect from the layer manager and in the first tab click on "Name of vector map" or "Name of raster map" to show the drop-down list of mapsets available, your signed-in mapset will be at the top (in blue and expanded), followed by PERMANENT mapset (in blue and expanded), followed by the additional mapsets that were made accessible (in blue but not expanded). The problem occurs most times when those additional accessible mapsets (in blue) become visible (without moving mouse over them) when scrolling down in the drop-down window. The problem happens every time when clicking on those additional mapsets.

The problem is intermittent when double-clicking on an already brought up map layer in the layer manager, which opens say, d.vect, for a displayed vector map. Then often (but not always) the scroll bar does not display in the map selection drop-down window (must scroll using mouse wheel). When scrolled all the way to the bottom of the drop-down window to expose the additional mapsets (in blue, not expanded), all usually appears fine. However, sometimes little arrow (triangle) to the left of the mapset name appears and the mapset can be expanded, while other times the triangle does not appear and clicking on the additional mapset name locks up the GUI accompanied by 100% usage of one CPU core by Xorg until stopping GRASS with Ctrl-D in the terminal.

Errors flooding terminal appears to be more related to d.vect than to d.rast.

Comment 5 Scott Talbert 2017-01-10 04:42:01 UTC
(In reply to rick from comment #4)
> In the GRASS layer manager, click: Settings-->GRASS working
> environment-->Mapset access, then select additional mapsets to want to be
> able to access. Then when you open either d.rast or d.vect from the layer

Where can I get additional mapsets?  There are only two shown when I open Mapset access.

Comment 6 markusN 2017-01-10 07:35:09 UTC
(In reply to Scott Talbert from comment #5)
> Where can I get additional mapsets?  There are only two shown when I open
> Mapset access.

At GUI startup, you can use the "New" button to generate more mapsets (on the right side, see (3) on the screenshot in https://grass.osgeo.org/grass72/manuals/helptext.html).

To have some maps within these mapsets, rather than downloading extra data you may just generate some random maps. Here the commands to run within a (new) mapset:

# random raster map:
g.region -d

# https://grass.osgeo.org/grass72/manuals/r.surf.random.html#example
r.surf.random out=random min=0 max=100

# https://grass.osgeo.org/grass72/manuals/v.random.html#generating-random-points-in-2d
v.random output=binary_random npoints=20 zmin=0 zmax=1 column='binary'

Comment 7 Scott Talbert 2017-04-28 02:25:29 UTC
I was never able to get the maps created to properly reproduce this.  Anyway, do you mind testing the current F26 to see if it resolves the issue for you?  The F26 package has a new upstream snapshot.  I've build the F26 package for F25 in a Copr:
https://copr.fedorainfracloud.org/coprs/swt2c/wxGTK3-Testing/

To install it, you should just have to do:
sudo dnf copr enable swt2c/wxGTK3-Testing
sudo dnf update --refresh wxGTK3

To go back to the official packages:
sudo dnf copr disable swt2c/wxGTK3-Testing
sudo dnf distro-sync --allowerasing wxGTK3

Make sure during that last command that it is only changing wxGTK3 related packages.

Comment 8 markusN 2017-04-29 08:18:19 UTC
(In reply to Scott Talbert from comment #7)
> I was never able to get the maps created to properly reproduce this. 
> Anyway, do you mind testing the current F26 to see if it resolves the issue
> for you?  The F26 package has a new upstream snapshot.  I've build the F26
> package for F25 in a Copr:
> https://copr.fedorainfracloud.org/coprs/swt2c/wxGTK3-Testing/
> 
> To install it, you should just have to do:
> sudo dnf copr enable swt2c/wxGTK3-Testing
> sudo dnf update --refresh wxGTK3
> 
> To go back to the official packages:
> sudo dnf copr disable swt2c/wxGTK3-Testing
> sudo dnf distro-sync --allowerasing wxGTK3
> 
> Make sure during that last command that it is only changing wxGTK3 related
> packages.

I updated and the problem appears to be gone.

Scott, great job! No more 100% CPU issues when it should be just idle.
I tested a series of wxGUI functionalities, both from cmd line as well as in g.gui.

Unrelated, also this behaves now:
cd /usr/share/doc/wxPython-docs/demo/ ; python Calendar.py

Looks good!

Comment 9 markusN 2017-05-01 19:08:29 UTC
Some extra feedback on wxGTK3-3.0.3-0.8.gite4293e9.fc25.x86_64.rpm:

.. in the terminal such messages are printed (a lot of them):

(meld:7793): Gtk-WARNING **: Allocating size to DiffMap 0x55b9d8af37b0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?


soffice
(soffice:7861): Gtk-WARNING **: Allocating size to OOoFixed 0x55cbb8413510 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
--> to reproduce, open a CSV file and plot a diagram

The wxGUI of GRASS GIS prints those messages as well. Could this message be suppressed?

Comment 10 Scott Talbert 2017-05-01 23:04:12 UTC
(In reply to markusN from comment #9)
> Some extra feedback on wxGTK3-3.0.3-0.8.gite4293e9.fc25.x86_64.rpm:
> 
> .. in the terminal such messages are printed (a lot of them):
> 
> (meld:7793): Gtk-WARNING **: Allocating size to DiffMap 0x55b9d8af37b0
> without calling gtk_widget_get_preferred_width/height(). How does the code
> know the size to allocate?
> 
> 
> soffice
> (soffice:7861): Gtk-WARNING **: Allocating size to OOoFixed 0x55cbb8413510
> without calling gtk_widget_get_preferred_width/height(). How does the code
> know the size to allocate?
> --> to reproduce, open a CSV file and plot a diagram
> 
> The wxGUI of GRASS GIS prints those messages as well. Could this message be
> suppressed?

Those messages are from meld and soffice (libreoffice), which do not even use wxGTK.

I don't know any easy way of suppressing those messages, aside from fixing the underlying problems.

Comment 11 markusN 2017-05-02 05:56:54 UTC
(In reply to Scott Talbert from comment #10)
> Those messages are from meld and soffice (libreoffice), which do not even
> use wxGTK.

ah, sorry for the noise.
 
> I don't know any easy way of suppressing those messages, aside from fixing
> the underlying problems.

Seems to be this one:
https://bugzilla.gnome.org/show_bug.cgi?id=765700
--> https://github.com/GNOME/gtk/commit/ddcf47026dbbe58dca3b34c7bb1ec63bb50a861a

and here a fix I found for meld (https://bugzilla.gnome.org/attachment.cgi?id=335456&action=diff) but of course unrelated to this report.

Back to this report: Do you plan to push the F26 wxGTK3 version to F25?

Comment 12 Jeremy Newton 2017-05-02 18:24:42 UTC
(In reply to markusN from comment #11)
> (In reply to Scott Talbert from comment #10)
> > Those messages are from meld and soffice (libreoffice), which do not even
> > use wxGTK.
> 
> ah, sorry for the noise.
>  
> > I don't know any easy way of suppressing those messages, aside from fixing
> > the underlying problems.
> 
> Seems to be this one:
> https://bugzilla.gnome.org/show_bug.cgi?id=765700
> -->
> https://github.com/GNOME/gtk/commit/ddcf47026dbbe58dca3b34c7bb1ec63bb50a861a
> 
> and here a fix I found for meld
> (https://bugzilla.gnome.org/attachment.cgi?id=335456&action=diff) but of
> course unrelated to this report.
> 
> Back to this report: Do you plan to push the F26 wxGTK3 version to F25?

3.0.3 was just released, so yes, I don't see why not. We just avoided pushing the snapshots, as they could have possible regression on stable versions of Fedora.

Comment 13 Scott Talbert 2017-05-10 00:51:23 UTC
Update submitted for F25:
https://bodhi.fedoraproject.org/updates/FEDORA-2017-901ccd6490

Comment 14 rick 2017-05-16 19:40:09 UTC
I updated to wxGTK3-3.0.3-1.fc25.x86_64 just now and did some testing on GRASS GIS. The occasional odd-looking cursor appears now to be working fine.

The original problem regarding the gui locking up when scrolling down map lists in the map selection drop-down window in d.vect and d.rast (when additional mapsets appear in the list) still causes the gui to lock up. This happens intermittently. Perhaps this isn't a wxGTK3 problem after all?

Also, the console still floods with:

(wxgui.py:4072): Gtk-CRITICAL **: gtk_widget_set_allocation: assertion '_gtk_widget_get_visible (widget) || _gtk_widget_is_toplevel (widget)' failed

(wxgui.py:4072): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton

Comment 15 Scott Talbert 2017-05-17 01:18:24 UTC
(In reply to rick from comment #14)
> The original problem regarding the gui locking up when scrolling down map
> lists in the map selection drop-down window in d.vect and d.rast (when
> additional mapsets appear in the list) still causes the gui to lock up. This
> happens intermittently. Perhaps this isn't a wxGTK3 problem after all?

That's possible.  I still am unable to reproduce the problem myself, as I could never get the maps created.  Maybe you could just send me some map files (if they are not proprietary) that would enable me to reproduce it?

> Also, the console still floods with:
> 
> (wxgui.py:4072): Gtk-CRITICAL **: gtk_widget_set_allocation: assertion
> '_gtk_widget_get_visible (widget) || _gtk_widget_is_toplevel (widget)' failed
> 
> (wxgui.py:4072): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size
> >= 0' failed in GtkCheckButton

The latter one is likely that there isn't enough space allocated for a check button widget - most likely has to be fixed in GRASS.  The first one I'm not sure.

Comment 16 markusN 2017-05-17 21:15:07 UTC
(In reply to Scott Talbert from comment #15)
> (In reply to rick from comment #14)
> > Also, the console still floods with:
...
> > (wxgui.py:4072): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size
 >= 0' failed in GtkCheckButton
> 
> The latter one is likely that there isn't enough space allocated for a check
> button widget - most likely has to be fixed in GRASS.

I have created a new bug report for this:
https://trac.osgeo.org/grass/ticket/3348

Comment 17 rick 2017-05-19 13:16:32 UTC
(In reply to Scott Talbert from comment #15)
> (In reply to rick from comment #14)
> > The original problem regarding the gui locking up when scrolling down map
> > lists in the map selection drop-down window in d.vect and d.rast (when
> > additional mapsets appear in the list) still causes the gui to lock up. This
> > happens intermittently. Perhaps this isn't a wxGTK3 problem after all?
> 
> That's possible.  I still am unable to reproduce the problem myself, as I
> could never get the maps created.  Maybe you could just send me some map
> files (if they are not proprietary) that would enable me to reproduce it?
> 

I will create a location with a few mapsets this weekend for you to test with. Please advise (I'm new to this), is the best way to deliver that zip file to you via the "add an attachment" link just below this page's header?

Comment 18 Scott Talbert 2017-05-19 13:21:43 UTC
(In reply to rick from comment #17)
> I will create a location with a few mapsets this weekend for you to test
> with. Please advise (I'm new to this), is the best way to deliver that zip
> file to you via the "add an attachment" link just below this page's header?

Sure.  If the file is too large, you may have to put it somewhere else though.

Comment 19 rick 2017-05-20 22:26:26 UTC
Created attachment 1280668 [details]
Map location and mapsets for testing

In response to request in Comment 15.

Comment 20 rick 2017-05-20 22:32:40 UTC
(In reply to Scott Talbert from comment #18)
> (In reply to rick from comment #17)
> > I will create a location with a few mapsets this weekend for you to test
> > with. Please advise (I'm new to this), is the best way to deliver that zip
> > file to you via the "add an attachment" link just below this page's header?
> 
> Sure.  If the file is too large, you may have to put it somewhere else
> though.

I I have attached test_someplace_10m.tar.xz. Place it in any directory, unzip it, then start GRASS.

In startup gui, 1. Select GRASS GIS database directory = directory the file was unzipped in; 2. Select GRASS location = test_someplace_10m; 3. Select GRASS Mapset= user-2; then click "Start GRASS session".

In GRASS Layer Manager, click menu: Settings --> Grass working environment --> Mapset access and in the Manage access to mapsets gui, click user-1 thru 4 to make all accessible, then click OK. Then click 6th or 8th top icon to open either d.rast gui or d.vect gui and in either one, click on pulldown to display available mapsets (in blue) and maps (in black).

In working mapsets with large numbers of maps, scrolling with the mouse wheel down to one of the mapsets (blue) will intermittently cause all GRASS gui's to lock up. In this test file and location in which there are only a few maps in each mapset, scrolling with the mouse wheel only rarely make that happen. However, gui lock up can be made to happen every time by clicking on the scroll bar inside the drop-down list and dragging down to when a different mapset (in blue) appears. I note a small delay in scroll bar motion also when this happens.

Comment 21 Scott Talbert 2017-05-27 01:08:15 UTC
I am not quite sure I am seeing the same problem, but I do seem to be able to make it lock up by clicking around a bit in that drop-down.  I also see this message when I open the drop-down.  Do you see this as well?

(wxgui.py:24434): Gdk-WARNING **: Window 0x55bd0bb78b00 is already mapped at the time of grabbing. gdk_seat_grab() should be used to simultanously grab input and show this popup. You may find oddities ahead.

Comment 22 rick 2017-05-29 13:10:35 UTC
I don't recall ever seeing that warning message and cannot seem to make it come up.

The error messages (unrelated?) that I do see frequently are:

(wxgui.py:27398): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkCheckButton

and

(wxgui.py:7957): Gtk-CRITICAL **: gtk_widget_set_allocation: assertion '_gtk_widget_get_visible (widget) || _gtk_widget_is_toplevel (widget)' failed

when opening and closing the d.vect gui, and also

(wxgui.py:27398): Gtk-WARNING **: Allocating size to wxPizza 0x55a725ea4850 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

when resizing the display window by grabbing a corner of it (all map layers render correctly after window resizing).

However, I suspect both of these would be GRASS-related issues?

Comment 23 Fedora End Of Life 2017-11-16 19:05:03 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 24 Fedora End Of Life 2017-12-12 10:10:35 UTC
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 25 Peter Lemenkov 2018-04-04 15:30:38 UTC
(In reply to rick from comment #22)
> I don't recall ever seeing that warning message and cannot seem to make it
> come up.
> 
> The error messages (unrelated?) that I do see frequently are:
...
> (wxgui.py:27398): Gtk-WARNING **: Allocating size to wxPizza 0x55a725ea4850
> without calling gtk_widget_get_preferred_width/height(). How does the code
> know the size to allocate?

See bug 1488249.

Comment 26 markusN 2018-07-04 07:29:18 UTC
(In reply to rick from comment #22)
> I don't recall ever seeing that warning message and cannot seem to make it
> come up.
> 
> The error messages (unrelated?) that I do see frequently are:
> 
> (wxgui.py:27398): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion
> 'size >= 0' failed in GtkCheckButton

Reopening since the problem of Gtk-CRITICAL messages polluting the terminal persists in F28 (GRASS GIS 7.4.x):

Update: we found a potential solution in the GRASS GIS wxPython GUI code, testing it at time:
https://trac.osgeo.org/grass/ticket/3348#comment:8

Comment 27 Ben Cotton 2019-05-02 21:29:21 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 28 Ben Cotton 2019-05-28 20:51:01 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.