It occurs only when rpmdrake is started from inside MCC. Rpmdrake launched from menu is OK.

I fail to reproduce with br locale but I do with pl locale.

Olav, it looks like there's a bug with GtkPlug/GtkSocket under some locales

CC: (none) => olav
Source RPM: drakconf-12.44-1.mga4.src.rpm => gtk+3.0

Created attachment 4607 [details]
file to source for reproducing this bug

It can easily be reproduced by running:
urpmi locales-pl
(. /where/it/Was/downloaded/.i18n.pl; mcc)

Created attachment 4608 [details]
looks like we're stuck in gtk_main -> g_main_loop_run -> g_main_context_poll

Actually, moving out /usr/share/locale/pl/LC_MESSAGES/rpmdrake.mo solves it.
So there're 2 issues:
- some translations that break gtk+
- gtk+ that break with some translations

Status: NEW => ASSIGNED
Source RPM: gtk+3.0 => rpmdrake, gtk+3.0

Invalidating polish translation for "Configure media" is enough to fix it:
 http://gitweb.mageia.org/software/rpmdrake/tree/po/pl.po#n670

@Olav: Any idea?

Hardware: i586 => All

For testing:
sudo msgfmt -o /usr/share/locale/pl/LC_MESSAGES/rpmdrake.mo po/pl.po

To be more precise, it's the "Configure media" string used as a GtkWindow/GtkPlug title (when !embedded/embedded) that is the issue cause.

Alternatively, not calling set_title() on GtkPlug in /usr/lib/libDrakX/mygtk3.pm line 931 workaround it.
Still it's a severe gtk+ regression...

Source RPM: rpmdrake, gtk+3.0 => gtk+3.0

Workarounded in drakxtools-16.15:
http://gitweb.mageia.org/software/drakx/commit/?id=b097c128b037750e3f3afa3b7d14e6dfb44b317f

I kept this bug report open as this is a gtk+3 bug but it's no more release critical as it has been workarounded.

Priority: release_blocker => Normal
Assignee: bugsquad => olav

This bug re-appears in Mageia5-alpha1 installed from classic DVD.
If rmpdrake is called from mageiawelcome or directly from user's command line, the whole interface is presented but if called from Mageia Control Center, Add/Remove software presents a black screen.

/rene91

CC: (none) => poisson.rene

Which locale do you use?

I am not fully in french locale. The system is intallad as English-US with a french keyboard. Then KDE Systems Settings are set to Country=France but the Language stays English...

What does report the "locale" command?

locale
LANG=en_DK.UTF-8
MCC from KDE4 4.14.0 in Mageia5 updated to cauldron (this morning) running in VirtualBox on a Mageia4 system.
1 CPU enabled in VirtualBox: rpmdrake called from MCC: black window
2 CPUs enabled in VirtualBox: rpmdrake works fine when called from MCC.
This happens every time.
The same thing happens when VirtualBox runs on a different hardware.
Everything else is the same.

CC: (none) => bjarne.thomsen

Can you reproduce it if you switch from Oxygen-gtk to Adwaita theme (using eg gnome-tweak-tool)?

Keywords: (none) => NEEDINFO

I ran gnome-tweak-tool from the command line.
I clicked "Reset to Default" (which is Adwaita).
Then I entered MCC. The window for rpmdrake is still black (1 CPU).
How can I see that it switched to Adwaita?

Buttons are no more "blued" when selected, interface is no more chrome, less 3D, ...

No, it was unchanged. I tried to instal gnome, but something was missing in cauldron. I then installed gnome from the Mageia5 alpha2 DVD.
This time rpmdrake called from MCC came up with the expected window.
Then I tried to update from cauldron. This was not a success. The screen went black instead of the gnome login window. This was all with 1 CPU enabled in VirtualBox.

I have now made a fresh install of Mandriva5 alpha2 from DVD in VirtualBox, and I selected to install KDE. Embedded rpmdrake in MCC works fine with 1 CPU enabled in VirtualBox. I have now (this morning) updated alpha2. Again I get the black screen with 1 CPU, and again it works fine with 2 CPUs enabled in VirtualBox.

Interrestingly, there is no black screen in xfce4 and mate installed from cauldron, so the problem with embedded rpmdrake in VirtualBox with only 1 CPU enabled is only found in KDE4.

I have the similar behaviour with not only rpmdrake, but other mcc components too (like drakxservices, drakfirewall, drakboot, drakdisk etc). Some of them need to be called twice in a row to get black screen.
M5alpha2 standart install with KDE installed in VirtualBox.

CC: (none) => ugal12v

I get this too since starting trying mga5 on all five mga5 machines but have been too busy with other things to dig into exactly when it works or not, just lazily decided start them from terminal until someone fix it... but now i chime in here.
Localisation: Sweden, swedish
Possibly related:  Bug 13038

I guess the whole drak system is a work in progress as there are quite a bit warnings etc rolling when starting any drak*

CC: (none) => fri

I still have this bug during testing pre-release beta1 isos.
Desktop Environments affected: IceWM, WindowMaker.
Locale: default (english).

I've finally got around to trying:

Mageia-5-beta1-LiveDVD-KDE4-x86_64-DVD.iso
MD5: c819afa046acf74014e299ef006ebf36

On my 64-bit Laptop and this condition exists.
MCC -> pick many functions

Opening windows is all black. I don't even have
to install it to demonstrate the error.
Locale: default (english)

Same laptop using:

Mageia-4.1-LiveDVD-KDE4-x86_64-DVD.iso
e9b3369d8f7695f7df69b65932f54a61

and all is fine.

This does not happen with
Mageia-5-beta1-LiveDVD-KDE4-x86_64-DVD.iso
in Danish on a Lenovo ThinkPad T440p.
In live mode.

This is still a problem in M5B2 Round 2
lspci -k
VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
Subsystem: Dell Device 0402
Kernel driver in use: i915
Kernel modules: i915

I could not replicate today on the machines that had this problem before.
However it did never always fail...

Occurring still on:

Mageia-5-beta2-KDE4-LiveDVD-x86_64
-----------------------------------
ISO Name: Mageia-5-beta2-LiveDVD-KDE4-x86_64-DVD.iso
DATE.txt: Tue Jan  6 04:00:00 CET 2015
md5sum:   b535115c3d35950dc0223897c635be60
sha1sum:  ea4351fe372488bc95bf28149fa5b9123e665cdc

Dell Vostro 1015 Laptop
Celeron 925 2.3Ghz 64-bit 4GB

Me also still today, but not allways...  System is on continuous updates.
BTW where do we find the beta2 iso??  I can help torrent seeding.

It is still occurring to me on a Mageia 5 Cauldron VirtualBox VM.
Locale: it_IT.UTF-8

Outside of MCC all is ok.

CC: (none) => leonardoce

For me too, 64 bit, fully updated, nvidia, KDE, desktop effects, OpenGL2.0 - raster, sweden/swedish
system was updated "online" somewhere during alpha1 
(BTW I noted today beta2 isos are official, torrenting)

Strange it is not consistent:
Right now i started MCC, clicked configure update frequency, which showed up OK, returned to MCC, chosed add/remove programs which blacked, returned to MCC, and again clicked configure update frequency, and this time that app blacked too.

Then I closed MCC, opened it again, and this time went straght to click add/remove programs which worked  OK.
Then i clicked OK in it, back in MCC selected dd/remove programs and it blacked.

It looks like "configure update frequency" somehow make havoc of display of "add/remove programs" !?  

This bug have NEEDINFO set.  What can we provide?

Can we make some detailed logg of sessions like the one i described - how ?

Well... the same thing happens to me.

If I start MCC, then select "Configura la frequenza degli
aggiornamenti" (Configure update frequency) all shows up OK. Now
I return to the MCC and then re-select "Configura la frequenza degli
aggiornamenti". This time the window is black. I close MCC.

Another test. I start MCC then select "Configura la frequenza degli
aggiornamenti", which shows up OK. I return to the MCC and then select
"Installa e rimuovi software". Now all the window is black.

Another test. I start MCC then this time I select "Installa e rimuovi
software", just to obtain a black window. The modal dialog which says
"Wait.. operation in progress.." shows up ok then closes itself. 
I return to the MCC clicking on the close button of the window and select "Configura la frequenza degli aggiornamenti". This time is it black.

It seems to me that when the MCC goes black it remains black.

Yes, I am seeing all of the symptoms mentioned above
both in and out of Vbox testing. This Bug is an M5
Release Blocker and will be fixed before release.
I do not believe that this has anything to do with
language selection. And yes it is intermittent.
My best platform is my Dell notebook where the black
MCC windows is experienced in Live media mode.

We are releasing M5B2 knowing full well that this
Bug exists. That way it will see a wider number
of testing platforms.

I've done another simple test on the same VBox machine.
If I use a basic I3 session, MCC always works well!
Under KDE, on the other hand, MCC exhibits the described wrong behaviour.

What a strange thing... maybe it depends on the GTK theme?

I have for the first time had a black window when entering
"Configure updates frequency" within MCC running KDE4.
This is on real PC-hardware (updated m5b2).

Hi guys. As asked by TV some time ago, what if you remove oxygen-gtk theme? Do you still have balck screen? (I cannot reproduce this bug here)

It is very rare. I am running 32-bit with Amecican english for system messages and a Danish keyboard. I was using a KDE4 desktop. Does that use oxygen-gtk? I han just turned logging on in MCC (and installed rsyslog) when I tried "Configure updates frequency". Logging did not work. Then I remembered that a re-boot is needed. Then I suddenly noticed that the MCC window was black. I have never had the black window since.

I've just removed oxygen-gtk and oxygen-gtk3 and now MCC works well.
I have no more black screens.
Seems that oxygen-gtk plays an important role here.

Created attachment 5830 [details]
lspcidrake -v

Happened when I removed oxygen-gtk in MCC

The "drakconf" program has crashed with the following error:

  object 9700048 is not really a GObject at /usr/libexec/drakconf line 1082.
  Perl's trace:
  drakbug::bug_handler() called from /usr/libexec/drakconf:1106

Used theme: oxygen-gtk

To submit a bug report, click on the report button.
This will open a web browser window on Bugzilla where you'll find a form to fill in.  The information displayed above will be transferred to that server
It would be very useful to attach to your report the output of the following command: 'lspcidrake -v'.

removed oxygen-gtk and oxygen-gtk3 in MCC
and the backgrount became black.

I removed oxygen-gtk and lib64oxygen-gtk, *rebooted*
and do not see a problem anymore :)

I did not remove any *gtk3 (is needed for lxde which i have as fallback DE)

Bjarne, did you reboot after removing the packages?

No. I did not reboot. The backgrount in the MCC became black right away.
I did try LXDE after the removal of oxygen-gtk3. The only problem
seemed to be the background around the login window: it was black.
So, it should be OK to re-install oxygen-gtk3?
I have an unrelated problem with gnome: Even when I have chosen Danish
for the keyboard GNOME assumes a US keyboard. Is this a known problem?
It works for all the other desktops.

As I said in my provious comment I removed oxygen-gtk3 and oxygen-gtk.
I re-installed oxygen-gtk3 and rebooted: MCC worked fine.
I then re-installed oxygen-gtk and rebooted: MCC showed the black window.

It seems that oxygen-gtk is a problem for MCC.

I re-installed oxygen-gtk3 and the background came back in LXDE.
So, is oxygen-gtk going out? Or can it be fixed?

In a KDE VM which has suffered this issue for months (black screen in all MCC modules), removing oxygen-gtk and reboot seems to have fixed it.

I did note prior to removal of oxygen-gtk that rpmdrake worked without the black screen when run by mageiaupdate.

CC: (none) => zen25000

*** Bug 14837 has been marked as a duplicate of this bug. ***

(In reply to Leonardo Cecchi from comment #38)

> I've just removed gen-goxytk and oxygen-gtk3 and now MCC works well.
> I have no more black screens.
> Seems that oxygen-gtk plays an important role here.

How did you do that?
urpmi oxygen-gtk & urpmi oxygen-gtk
both respond with a package not found on the M5B2 Live-DVD
But show in a working Vbox client they are installed.

> (In reply to Leonardo Cecchi from comment #38)
> 
> > I've just removed gen-goxytk and oxygen-gtk3 and now MCC works well.
> > [...]
> 
> How did you do that?
> urpmi oxygen-gtk & urpmi oxygen-gtk
> both respond with a package not found on the M5B2 Live-DVD
> But show in a working Vbox client they are installed.

My environment is a M5B2 Classic DVD installed to a VirtualBox VM.
I've simply done:
 
    urpme oxygen-gtk oxygen-gtk3

but I removed too many things. 
Removing oxygen-gtk is enough.

Humm...
MCC runs with gtk2 (and thus renders with oxygen-gtk) but embedd gtk3 apps (which are thus using oxygen-gtk3)

CC: (none) => hugo.pereira
Source RPM: gtk+3.0 => oxygen-gtk, gtk+3.0

BTW can someone open a bug report on https://bugs.kde.org/ and link it here?
Just choose:
- Product: 	Oxygen
- Component: 	gtk3-engine

I am confused. 
What version of gtk3 is shipped with Mageia 5 ? 
I thought gtk3 was not even loading oxygen-gtk3 any more ... 

(does not apply to gtk2)

mga5 comes with gtk-3.14.8 & oxygen-gtk3-1.4.1
Users upgrading from mga4 will still have oxygen-gtk as the theme set.

And the issue is with gtk2/oxygen-gtk with usage of GtkSocket in mcc

Has this anything to do with the mysterious

Starting mandi daemon: nl_create_socket: Protocol not supported
unable to init netlink
unable to init "Interactive Firewall" plugin

that suddenly went away when I did a boot.iso install
insted of a mga5b2 install?

(In reply to Bjarne Thomsen from comment #54)
> Has this anything to do with the mysterious
> 
> Starting mandi daemon: nl_create_socket: Protocol not supported
> unable to init netlink
> unable to init "Interactive Firewall" plugin

I don't think this is related Bjarne, this bug report is about graphical issues in MCC. Please open another bug report for your issue.

CC: (none) => remi

Yes, it is a long shot, but mandi has a graphical interface, and there is
a socket involved.
I do not believe that bugs go away by themselves. The mandi bug did not
go away by simply updating from cauldron.
This will be important when upgrading from mga4 to mga5, just as it
is for the MCC problem.

Mageia GNOME doesn't use Oxygen. However, Mageia GTK+ uses it by default. So anything using GTK+ which is not under a Mageia GNOME session (e.g. XFCE, KDE, etc) uses Oxygen. Only for about 1 Mageia release Oxygen was the default due to a problem in diskdrake (setting the colour of buttons).

I don't know how to debug nor fix this. If really up to me I'd take the blunt approach and just not use Oxygen as default theme in GTK+ (all versions).

... or rewrite mcc with Qt

... in fact, since support to oxygen has been dropped upstream (following the blunt approach philosophy), and since there is no sense in having gtk2 apps look one way and gtk3 another, why not indeed follow olav's advice (so that I can focus my work on toolkits that do offer backward compatibility)

(In reply to Hugo Pereira Da Costa from comment #51)
> I am confused. 
> What version of gtk3 is shipped with Mageia 5 ? 
> I thought gtk3 was not even loading oxygen-gtk3 any more ... 
> 

oxygen-gtk is not the default theme for gtk3 in Mga5, but we still use it by default for KDE in order to have a consistent look & feel.

(In reply to Hugo Pereira Da Costa from comment #59)
> ... in fact, since support to oxygen has been dropped upstream (following
> the blunt approach philosophy), and since there is no sense in having gtk2
> apps look one way and gtk3 another, why not indeed follow olav's advice (so
> that I can focus my work on toolkits that do offer backward compatibility)

For Mga5, I would prefer to still use oxygen-gtk theme (oxygen-gtk2 & oxygen-gtk3) by default for KDE to keep a consistent look with kde & qt apps.


I've finally been able to reproduce this bug here on 2 installs:
- a KDE install in a virtualbox vm using only one proc,
- another KDE install on a Core 2 Duo laptop using only one proc (with maxcpus=1).
From my tests, this issue only occurs on quite slow systems (and perhaps on heavily loaded faster systems). eg. I can't reproduce this bug on my old netbook with Atom N270.

The issue occurs only for embedded apps in mcc when using oxygen-gtk3 for gtk3 apps (excepted for draknetcenter which always works fine) with either Adwaita or oxygen-gtk for gtk2 theme. The black background appears when the gtk3 component should be displayed.

oxygen-gtk is probably a bit slower than Adwaita.
After many tests, I think that we have a delay/timeout issue between mcc in gtk2 and embedded components in gtk3.

From my tests, adding 1ms sleep in create_hidden_socket fixes this bug.

--- drakconf.orig       2014-12-17 11:42:38.000000000 +0100
+++ drakconf    2015-02-04 21:33:25.269137790 +0100
@@ -1182,6 +1182,7 @@
         $left_locked = 0;
         hide_buttons();
         $buttons->hide;
+        select(undef, undef, undef, 0.001);   # add 1 ms delay to avoid black background with slow gtk themes
         return if !$emb_socket;
         $emb_socket->show;
         $emb_socket->can_focus(1);

Thierry, do you think that we can safely add this sleep? or can this introduce regression?

CC: (none) => lmenut

If more people confirm the bug goes away with it, why not?
This is just hiding a real issue with gtk+ vs oxygen-gtk but it's better than nothing!

I can confirm my fast machine at work, a i7 3,8GHz where the issue appear is always at full load, although nice, chewing BOINC projects.
Would you like me to test there with oxygen-gtk reinstalled and BOINC off?

I meant: first test without your changes, just with lower load.

(In reply to Morgan Leijström from comment #63)
> I meant: first test without your changes, just with lower load.

yes, please.
and you could test with my patch with full load too.

(In reply to Luc Menut from comment #60)
> (In reply to Hugo Pereira Da Costa from comment #51)
> > I am confused. 
> > What version of gtk3 is shipped with Mageia 5 ? 
> > I thought gtk3 was not even loading oxygen-gtk3 any more ... 
> 
> oxygen-gtk is not the default theme for gtk3 in Mga5, but we still use it by
> default for KDE in order to have a consistent look & feel.

That's wrong, the default theme for GTK+3.x is Oxygen-gtk as mentioned in comment 57.

http://svnweb.mageia.org/packages/cauldron/gtk%2B3.0/current/SOURCES/gtk%2B-defaulttheme.patch?view=markup

(In reply to Olav Vitters from comment #65)
> (In reply to Luc Menut from comment #60)
> > (In reply to Hugo Pereira Da Costa from comment #51)
> > > I am confused. 
> > > What version of gtk3 is shipped with Mageia 5 ? 
> > > I thought gtk3 was not even loading oxygen-gtk3 any more ... 
> > 
> > oxygen-gtk is not the default theme for gtk3 in Mga5, but we still use it by
> > default for KDE in order to have a consistent look & feel.
> 
> That's wrong, the default theme for GTK+3.x is Oxygen-gtk as mentioned in
> comment 57.
> 
> http://svnweb.mageia.org/packages/cauldron/gtk%2B3.0/current/SOURCES/gtk%2B-
> defaulttheme.patch?view=markup

nope, this patch is not applied anymore in spec file.
GTK+3 now uses Adwaita by default in Mga 5.

(In reply to Luc Menut from comment #64)
> and you could test with my patch with full load too.

I do not know how to apply a patch.  Detailed steps please and I will do.

I applied the patch suggested in comment 60 to drakconf 12.53-2.
Please, could you try drakconf 12.53-2, and report here if it fixes this bug.

Only having a stairway to my work, I tested now and it is obvious: tunning off BOINC i never have black windows in drakconf/MCC, and when i run BOINC it blacks most of the time - tests in both cases was to from main MCC panel go to configure sources, and then back and again twelve times.  And also tried a few other drak utilities.

(before this i installed applied various updates except drakconf 12.53-2 and rebooted)

Then i installed oxygen-gtk, drakconf12.53-2 and problem is gone in same tests :)

Great find and we have workaround!  Congratulations :)

OH, BTW as we are here, the help->about popup in drakconf say (C) 2013, should be updated to 2015 :)

Editing accident: i meant i installed oxygen-gtk before all tests.  Bedtime.

(In reply to Luc Menut from comment #66)
> nope, this patch is not applied anymore in spec file.
> GTK+3 now uses Adwaita by default in Mga 5.

Ah, didn't know. It missed some requires on adwaita-icon-theme (didn't make sense before). Aligned gtk+2.0 package as well.

Using my laptop:
Dell Vostro
VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller
Subsystem: Dell Device 0402
Kernel driver in use: i915
Kernel modules: i915

Boot from a USB stick:
Fri Jan 30 20:30.00 CET 2015
Mageia-5-beta3-LiveDVD-KDE4-x86_64-DVD.iso
MD5SUM: aa904deed3874f6ccc5348eec3691f1f

Open: MCC -> Software Management -> Install & Remove Software
window opens black
Open SU terminal
Set up my local repo
install urpmex: urpmi urpmex
urpme oxygen-gtk oxygen-gtk3
Open: MCC -> Software Management -> Install & Remove Software
window opens normally and is usable

(In reply to William Kenney from comment #72)
> 
> Boot from a USB stick:
> Fri Jan 30 20:30.00 CET 2015
> Mageia-5-beta3-LiveDVD-KDE4-x86_64-DVD.iso
> MD5SUM: aa904deed3874f6ccc5348eec3691f1f
> 
> Open: MCC -> Software Management -> Install & Remove Software
> window opens black
> Open SU terminal
> Set up my local repo
> install urpmex: urpmi urpmex
> urpme oxygen-gtk oxygen-gtk3
> Open: MCC -> Software Management -> Install & Remove Software
> window opens normally and is usable

Did you update drakconf to 12.53-2 for this test?

Please could you test with Mageia-5-beta3 live medias round 2 (Thu Feb  5 20:00:00 CET 2015).

Testing today in live mode with:

ISO Name: Mageia-5-beta2-LiveDVD-KDE4-x86_64-DVD.iso
DATE.txt: Thu Feb  5 23:36:04 CET 2015
md5sum:   a138335d68f9b82bef1b49c1b4bbb3cc
sha1sum:  2cfdcb8e2b297def22a4dfca67fc1e14ed59bf79

Dell Vostro 1015 Laptop
Celeron 925 2.3Ghz 64-bit 4GB

This bug is no longer a problem for me.

I checked a long standing Cauldron VM that has had the issue for months and after updates yesterday the problem is fixed.

Thanks for the feedbacks, and your patience.
So, it seems now fixed in Cauldron; I decrease the priority and reassign this bug to mga4 still affected.
I will make an update for mga 4 if the fix is still confirmed in Cauldron in following days.

Keywords: NEEDINFO => (none)
Priority: release_blocker => Normal
Version: Cauldron => 4
Blocks: 14069 => (none)
Whiteboard: mga4b2 5alpha1 => (none)

I installed Mageia on a new VirtualBox VM and I can confirm that, after updates, the problem is fixed.
Thanks!

Update to my comment #69 : today i recieved black screen once on that heavily loaded i7 workstation, tried again and then OK.  So the fix/workaround is not "watertight".

(In reply to Morgan Leijström from comment #78)
> Update to my comment #69 : today i recieved black screen once on that
> heavily loaded i7 workstation, tried again and then OK.  So the
> fix/workaround is not "watertight".

Likewise, I saw it again yesterday on a dual core x86_64 laptop with both cores at 80% running gqrx SDR software. Stopping the SDR fixed it.

commit a35ba981f5c05c90b9f77d705852ac71e221981b
Author: Luc Menut <lmenut@...>
Date:   Mon Feb 23 00:27:36 2015 +0100

    add delay to prevent black background with oxygen-gtk3 (mga#11969)
---
 Commit Link:
   http://gitweb.mageia.org/software/control-center/commit/?id=a35ba981f5c05c90b9f77d705852ac71e221981b

Was this bug fixed by the commit from Luc in comment #80?

Keywords: (none) => NEEDINFO

I have not seen the problem on mine nor my families systems since then.

Thanks, closing as fixed then.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED