another GTK3 regression...
(this reproduces at commit 0687cea6a86e; IOW the regression is not from the recent GTK-related patches, but due to building p2v with GTK3. as opposed to GTK2) In the first dialog, when the Test Connection button is clicked, a spinner is supposed to be shown to the left, while p2v communicates via v2v over ssh. This spinner is seen when running virt-p2v directly, but not when running virt-p2v from a VM (using either a Live CD, or the "run-virt-p2v-in-a-vm" makefile target). This difference is not seen when virt-p2v is built with GTK2; in that case, *both* scenarios (direct & VM) show the spinner properly. I don't have an idea what the cause is. I vaguely suspect it could be related to the windowing environment (window manager) in use. It pretty much looks like a GTK3 bug to me; whatever the windowing environment, the spinner should either be there or not. (It's possible that we have a virt-p2v bug, of course, but why isn't the symptom consistent then? GTK3 should not have a dependency at all on the Window Manager.) Laszlo
On Wed, Sep 28, 2022 at 02:01:11PM +0200, Laszlo Ersek wrote:
(this reproduces at commit 0687cea6a86e; IOW the regression is not from the recent GTK-related patches, but due to building p2v with GTK3. as opposed to GTK2)
In the first dialog, when the Test Connection button is clicked, a spinner is supposed to be shown to the left, while p2v communicates via v2v over ssh. This spinner is seen when running virt-p2v directly, but not when running virt-p2v from a VM (using either a Live CD, or the "run-virt-p2v-in-a-vm" makefile target).
I can see the spinner when running locally. After hacking Makefile.am so it builds the VM with fedora-36 (I'm actually using Fedora 37 and there is no virt-builder template), I was able to do 'make run-virt-p2v-in-a-vm', and I _did_ see the spinner there too. No idea why it works for me and not for you.
This difference is not seen when virt-p2v is built with GTK2; in that case, *both* scenarios (direct & VM) show the spinner properly.
I don't have an idea what the cause is. I vaguely suspect it could be related to the windowing environment (window manager) in use. It pretty much looks like a GTK3 bug to me; whatever the windowing environment, the spinner should either be there or not. (It's possible that we have a virt-p2v bug, of course, but why isn't the symptom consistent then? GTK3 should not have a dependency at all on the Window Manager.)
On my laptop: gtk3-3.24.34-2.fc37.x86_64 Inside the p2v VM: gtk3-3.24.34-1.fc36.x86_64 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Wed, Sep 28, 2022 at 02:01:11PM +0200, Laszlo Ersek wrote:
(this reproduces at commit 0687cea6a86e; IOW the regression is not from the recent GTK-related patches, but due to building p2v with GTK3. as opposed to GTK2)
In the first dialog, when the Test Connection button is clicked, a spinner is supposed to be shown to the left, while p2v communicates via v2v over ssh. This spinner is seen when running virt-p2v directly, but not when running virt-p2v from a VM (using either a Live CD, or the "run-virt-p2v-in-a-vm" makefile target).
This difference is not seen when virt-p2v is built with GTK2; in that case, *both* scenarios (direct & VM) show the spinner properly.
I don't have an idea what the cause is. I vaguely suspect it could be related to the windowing environment (window manager) in use. It pretty much looks like a GTK3 bug to me; whatever the windowing environment, the spinner should either be there or not. (It's possible that we have a virt-p2v bug, of course, but why isn't the symptom consistent then? GTK3 should not have a dependency at all on the Window Manager.)
There certainly are dependancies on both the window manager, and the desktop system (X11 vs wayland). There's a huge set of features that widget toolkits can negotiate with window managers, and each window manager supports a different set of extensions, just one example being support for client side window decorations. In theory GTK should adapt to expose the same functionality to users whereever possible but there are certainly edge cases where this doesn't work, and bugs will certainly be present for more obscure combinations like X11 + any non mainstream window manager. It is also not surprising to see a differnce from GTK2 to 3, as it radically changed under the hood, most notably with native Wayland support. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 09/28/22 19:02, Daniel P. Berrangé wrote:
On Wed, Sep 28, 2022 at 02:01:11PM +0200, Laszlo Ersek wrote:
(this reproduces at commit 0687cea6a86e; IOW the regression is not from the recent GTK-related patches, but due to building p2v with GTK3. as opposed to GTK2)
In the first dialog, when the Test Connection button is clicked, a spinner is supposed to be shown to the left, while p2v communicates via v2v over ssh. This spinner is seen when running virt-p2v directly, but not when running virt-p2v from a VM (using either a Live CD, or the "run-virt-p2v-in-a-vm" makefile target).
This difference is not seen when virt-p2v is built with GTK2; in that case, *both* scenarios (direct & VM) show the spinner properly.
I don't have an idea what the cause is. I vaguely suspect it could be related to the windowing environment (window manager) in use. It pretty much looks like a GTK3 bug to me; whatever the windowing environment, the spinner should either be there or not. (It's possible that we have a virt-p2v bug, of course, but why isn't the symptom consistent then? GTK3 should not have a dependency at all on the Window Manager.)
There certainly are dependancies on both the window manager, and the desktop system (X11 vs wayland). There's a huge set of features that widget toolkits can negotiate with window managers, and each window manager supports a different set of extensions, just one example being support for client side window decorations. In theory GTK should adapt to expose the same functionality to users whereever possible but there are certainly edge cases where this doesn't work, and bugs will certainly be present for more obscure combinations like X11 + any non mainstream window manager.
It is also not surprising to see a differnce from GTK2 to 3, as it radically changed under the hood, most notably with native Wayland support.
Very good points, thanks. The tricky question is why the spinner works fine (using GTK3) in my quite-non-standard environment (namely, forwarding X11 over ssh to my local IceWM environment), but does not work in the Live VM environment, which should be identical (including the Window Manager, if any) for Rich and myself. IOW the discrepancy does not manifest itself where the environments are obviously different, but it shows where the environments appear more uniform. I've got two ideas: - Build and ISO (using my current env) for Rich to try out. (It seems impossible that Rich will see the spinner that I *don't* see, booting the same ISO image in a VM; but who knows?) - Upgrade my environment (both my v2v development workstation, and the livecd-creator VM) to Fedora 36, and retest. I'll follow up. Thanks Laszlo
On 09/29/22 11:27, Laszlo Ersek wrote:
The tricky question is why the spinner works fine (using GTK3) in my quite-non-standard environment (namely, forwarding X11 over ssh to my local IceWM environment), but does not work in the Live VM environment, which should be identical (including the Window Manager, if any) for Rich and myself. IOW the discrepancy does not manifest itself where the environments are obviously different, but it shows where the environments appear more uniform.
It gets worse. I've determined (using the XTerm button in the first dialog) that in the LiveCD environment, the gtk3 version is "gtk3-3.24.30-4.fc35.x86_64" <https://koji.fedoraproject.org/koji/buildinfo?buildID=1837672>, from "27 Sep 2021". This build is tagged "f35". More recent builds exist, tagged as "f35-updates", but livecd-creator does not pull them in. Therefore, it seems that livecd-creator does not use the "fedora-updates" repo, only the base "fedora" repo. So I got (transitorily) happy -- I had found the bug! We'd *just* need to make livecd-creator honor the "fedora-updates" repository! Unfortunately, that won't suffice. Namely, I've also checked the gtk3 version in the VM that's launched by the command make run-virt-p2v-in-a-vm using the same XTerm + "rpm -q" method. Here, I do get "gtk3-3.24.34-1.fc35.x86_64" <https://koji.fedoraproject.org/koji/buildinfo?buildID=1968341>, which is the latest build -- from "fedora-updates". And this exact same gtk3 version (3.24.34-1.fc35.x86_64) works well, concerning the spinner, when I launch make run-virt-p2v-directly ! But it does not work when I launch make run-virt-p2v-in-a-vm In other words, *even though* livecd-creator uses an outdated gtk3 version (due to ignoring the "fedora-updates" repository for some reason), the bug I'm witnessing is not due to that problem; that is, it's not something affecting gtk3-3.24.30-4.fc35.x86_64 but fixed in gtk3-3.24.34-1.fc35.x86_64 Because, the latter still misbehaves in "run-virt-p2v-in-a-vm". With that in mind, I'm going to claim that the same bug reproduces with the earlier gtk3-3.24.30-4.fc35.x86_64 that's built into the ISO by livecd-creator, and therefore the ISO should be good enough for Rich to please try out:
I've got two ideas:
- Build and ISO (using my current env) for Rich to try out. (It seems impossible that Rich will see the spinner that I *don't* see, booting the same ISO image in a VM; but who knows?)
http://lacos.interhost.hu/livecd-p2v-202209291608-gitc213ae00a337.iso (built at c213ae00a337) sha256: f3a149aeab0179213d74bb1eac30d5d6f807d4c9cf3a548667903d5434d5699a Thanks! Laszlo
- Upgrade my environment (both my v2v development workstation, and the livecd-creator VM) to Fedora 36, and retest.
I'll follow up.
On Thu, Sep 29, 2022 at 04:47:34PM +0200, Laszlo Ersek wrote:
http://lacos.interhost.hu/livecd-p2v-202209291608-gitc213ae00a337.iso
(built at c213ae00a337)
sha256: f3a149aeab0179213d74bb1eac30d5d6f807d4c9cf3a548667903d5434d5699a
No spinner! While I remember, an annoying virt-p2v bug is that the keymap is always set to the US locale (try XTerm -> localctl status). I wonder if it's easy to add a way to change the keyboard layout? In particular it doesn't work well if your password contains some punctuation character which is mapped differently on US vs local keyboards. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On 09/29/22 20:12, Richard W.M. Jones wrote:
On Thu, Sep 29, 2022 at 04:47:34PM +0200, Laszlo Ersek wrote:
http://lacos.interhost.hu/livecd-p2v-202209291608-gitc213ae00a337.iso
(built at c213ae00a337)
sha256: f3a149aeab0179213d74bb1eac30d5d6f807d4c9cf3a548667903d5434d5699a
No spinner!
Thanks. I'll try to update my envs and/or investigate further.
While I remember, an annoying virt-p2v bug is that the keymap is always set to the US locale (try XTerm -> localctl status). I wonder if it's easy to add a way to change the keyboard layout? In particular it doesn't work well if your password contains some punctuation character which is mapped differently on US vs local keyboards.
This is something for later :) I can keep it tagged for a while; if it's important, a BZ would probably be better. Laszlo
On Thu, Sep 29, 2022 at 07:12:15PM +0100, Richard W.M. Jones wrote:
On Thu, Sep 29, 2022 at 04:47:34PM +0200, Laszlo Ersek wrote:
http://lacos.interhost.hu/livecd-p2v-202209291608-gitc213ae00a337.iso
(built at c213ae00a337)
sha256: f3a149aeab0179213d74bb1eac30d5d6f807d4c9cf3a548667903d5434d5699a
No spinner!
BTW, is there any possibility your code is invoking GTK3 APIs from a thread != main GTK event loop thread ? If so, that is a sure way to get non-deterministic wierd behaviour with GTK.
While I remember, an annoying virt-p2v bug is that the keymap is always set to the US locale (try XTerm -> localctl status). I wonder if it's easy to add a way to change the keyboard layout? In particular it doesn't work well if your password contains some punctuation character which is mapped differently on US vs local keyboards.
Assuming GTK3, you can use gsettings to change layout for apps gsettings set org.gnome.desktop.input-sources sources "[('"xkb"','"us"'),('"xkb"','"fr"'),('"xkb"','"it"')]" gsettings set org.gnome.desktop.input-sources current 1 this can be done dynamically on the fly too With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Sep 30, 2022 at 08:55:02AM +0100, Daniel P. Berrangé wrote:
On Thu, Sep 29, 2022 at 07:12:15PM +0100, Richard W.M. Jones wrote:
On Thu, Sep 29, 2022 at 04:47:34PM +0200, Laszlo Ersek wrote:
http://lacos.interhost.hu/livecd-p2v-202209291608-gitc213ae00a337.iso
(built at c213ae00a337)
sha256: f3a149aeab0179213d74bb1eac30d5d6f807d4c9cf3a548667903d5434d5699a
No spinner!
BTW, is there any possibility your code is invoking GTK3 APIs from a thread != main GTK event loop thread ? If so, that is a sure way to get non-deterministic wierd behaviour with GTK.
Maybe? This is the code which is run when the "Test Connection" button is clicked: https://github.com/libguestfs/virt-p2v/blob/c213ae00a337cb04e63cbfe4fb4b3af4... It runs a thread (to test the connection using ssh) and that thread creates an idle {job? event?} in the new thread. However I documented it as: * Idle task called from C<test_connection_thread> (but run on the * main thread) to start the spinner in the connection dialog. Whether that is true or not and how I deduced that, I don't recall. Rich.
While I remember, an annoying virt-p2v bug is that the keymap is always set to the US locale (try XTerm -> localctl status). I wonder if it's easy to add a way to change the keyboard layout? In particular it doesn't work well if your password contains some punctuation character which is mapped differently on US vs local keyboards.
Assuming GTK3, you can use gsettings to change layout for apps
gsettings set org.gnome.desktop.input-sources sources "[('"xkb"','"us"'),('"xkb"','"fr"'),('"xkb"','"it"')]" gsettings set org.gnome.desktop.input-sources current 1
this can be done dynamically on the fly too
With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
-- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v
On Fri, Sep 30, 2022 at 09:41:02AM +0100, Richard W.M. Jones wrote:
On Fri, Sep 30, 2022 at 08:55:02AM +0100, Daniel P. Berrangé wrote:
On Thu, Sep 29, 2022 at 07:12:15PM +0100, Richard W.M. Jones wrote:
On Thu, Sep 29, 2022 at 04:47:34PM +0200, Laszlo Ersek wrote:
http://lacos.interhost.hu/livecd-p2v-202209291608-gitc213ae00a337.iso
(built at c213ae00a337)
sha256: f3a149aeab0179213d74bb1eac30d5d6f807d4c9cf3a548667903d5434d5699a
No spinner!
BTW, is there any possibility your code is invoking GTK3 APIs from a thread != main GTK event loop thread ? If so, that is a sure way to get non-deterministic wierd behaviour with GTK.
Maybe? This is the code which is run when the "Test Connection" button is clicked:
https://github.com/libguestfs/virt-p2v/blob/c213ae00a337cb04e63cbfe4fb4b3af4...
It runs a thread (to test the connection using ssh) and that thread creates an idle {job? event?} in the new thread.
However I documented it as:
* Idle task called from C<test_connection_thread> (but run on the * main thread) to start the spinner in the connection dialog.
Whether that is true or not and how I deduced that, I don't recall.
The test_connection_thread code is using g_idle_add to run all GTK APIs, which results in it running in the main event loop thread. That is the correct way to deal with GTK from multiple threads. As an idea to debug it more, try using the GTK inspector $ GTK_DEBUG=interactive <app binary> this will popup a second window, which lets you browse the widget hierarchy, view properties, etc. This might let you see something that's set in an incorrect way. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Sep 30, 2022 at 10:04:27AM +0100, Daniel P. Berrangé wrote:
As an idea to debug it more, try using the GTK inspector
$ GTK_DEBUG=interactive <app binary>
this will popup a second window, which lets you browse the widget hierarchy, view properties, etc. This might let you see something that's set in an incorrect way.
For future reference, inside the virt-p2v ISO environment I logged in as root/p2v and edited /usr/bin/launch-virt-p2v, changing: - exec /usr/bin/virt-p2v --iso --colours + exec bash -c 'GTK_DEBUG=interactive /usr/bin/virt-p2v --iso --colours' I then ran launch-virt-p2v from the text console. This starts X11 and does launches virt-p2v & the separate inspector window. If you look at the attached screenshot, the inspector window (lower) has the GtkSpinner widget in blue. The widget name is greyed out which makes it hard to read. I guess that corresponds to the spinner being hidden. If you click Test Connection then the widget name becomes visible, probably corresponding to the idle task being run and calling start_spinner which shows the widget. (The spinner itself still does not show up or "spin"). When Test connection finishes, the widget name again goes back to being greyed out, probably corresponding to stop_spinner being called. A few other notes: The GtkLabel below the blue bar in the screenshot is the spinner message. This is being displayed and updated properly. If you click to the right of the "Style Classes" column in the inspector, then the widget or box is flashed in blue briefly. When GtkSpinner is inactive nothing happens. BUT (and it is difficult to do the mouse gymnastics here) if you click "Test Connection" and while that is running click to the right of the GtkSpinner, it does highlight a small blue box (displaying nothing) to the left of the spinner message. So it seems that the spinner widget is occupying the expected place on the screen, even if it's not displaying anything. Clicking the second button along the top row of the inspector shows details of the spinner. There's a lot of stuff here. For example under "CSS nodes" I can see the -gtk-icon-transform CSS changing to "rotate(XXX)" (with "XXX" rapidly increasing) as the spinner is supposed to be animating, but again no animation is shown. Under "Visual" there are various buttons. If you enable "Show Graphic Updates" then the GtkSpinner widget space flashes in red (again the spinner itself does not display), so it seems to indicate that Gtk "knows" that the spinner should be updating even if for some reason it doesn't get rendered. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
Hmm, here's an interesting stackoverflow posting ... https://stackoverflow.com/questions/3301023/gtk-spinner-not-appearing The first point is "Make sure librsvg is installed". librsvg is _not_ installed in the ISO. Laszlo, can you try building an ISO with this package explicitly added to the deps? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Fri, Sep 30, 2022 at 10:33:02AM +0100, Richard W.M. Jones wrote:
Hmm, here's an interesting stackoverflow posting ...
https://stackoverflow.com/questions/3301023/gtk-spinner-not-appearing
The first point is "Make sure librsvg is installed". librsvg is _not_ installed in the ISO. Laszlo, can you try building an ISO with this package explicitly added to the deps?
Yes, that could be it. The widget is rendered using CSS and the Adwaita CSS rule references "process-working-symbolic" as the icon, and that icon is only shipped in SVG format AFAICT. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 09/30/22 11:46, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 10:33:02AM +0100, Richard W.M. Jones wrote:
Hmm, here's an interesting stackoverflow posting ...
https://stackoverflow.com/questions/3301023/gtk-spinner-not-appearing
The first point is "Make sure librsvg is installed". librsvg is _not_ installed in the ISO. Laszlo, can you try building an ISO with this package explicitly added to the deps?
Yes, that could be it. The widget is rendered using CSS and the Adwaita CSS rule references "process-working-symbolic" as the icon, and that icon is only shipped in SVG format AFAICT.
(1) sorry, I've been in write-only mode for a long while now. That's why we've apparently arrived at nearly the same conclusions thus far, duplicating (triplicating?) our efforts. That said, I'm glad we did arrive at the same ideas. (2) A number of surprises: (2a) p2v already spells out icewm[-lite] as a depencency, just not when the VM boot disk image / ISO image is based on Fedora (more precisely: for SUSE). When building on Fedora, the WM included is Metacity instead (and the launch script starts metacity vs. icewm accordingly.) (2b) There is a makefile dependency bug in virt-p2v; I'm going to post the patch for that.
diff --git a/Makefile.am b/Makefile.am index 02ff1bb2eebd..2881fc947b24 100644 --- a/Makefile.am +++ b/Makefile.am @@ -328,7 +328,7 @@ $(BLANK_DISK): $(top_builddir)/run guestfish -N $@=part exit
virt-p2v.img: \ - dependencies.m4 \ + $(dependencies_files) \ issue \ launch-virt-p2v \ p2v.service \ @@ -373,7 +373,7 @@ stamp-test-virt-p2v-pxe-data-files: \ touch $@
test-virt-p2v-pxe.img: \ - dependencies.m4 \ + $(dependencies_files) \ issue \ launch-virt-p2v \ p2v.service \
Namely, even after I modified "dependencies.m4", the disk image did not get correctly regenerated for "run-virt-p2v-in-a-vm". While the image *was* regenerated, the intermediate (OS-filtered) deps files were not, and so the change I had made to "dependencies.m4" did not affect the actual package installation command line. (2c) I learned about metacity already being present when I launched an xterm window from the first dialog of p2v, and attempted to run icewm. IceWM complained that another window manager was already present; that was when I found metacity in the process list (pstree). (2d) I started icewm with "icewm --replace" (as recommended by the error message from (2c)), and lo and behold, two changes had come into effect: - the spinner started working - I actually got an actual Task Bar, where I could see all the windows: virt-p2v, the GTK debug windows (plural), the XTerm window, and (in the Tray area) even nm-applet! This is not a small improvement: QEMU doesn't let me easily inject Alt-Tab, so switching between windows in the VM environment has been a huge chore (made worse by the many GTK debug windows). (2e) That is, elaborating on the second bullet from (2d), not only is metacity (or else, our setup/usage of metacity) bugged enough to break the spinner, it even (i) does not offer a functional task bar, (b) does not show nm-applet -- there is no tray area! I'm of the opinion that we should just get rid of metacity altogether, and use icewm. I don't know why metacity is not working, but I consider metacity a seriously substandard WM anyway, so let's just get rid of it? Thanks Laszlo
On 09/30/22 12:56, Laszlo Ersek wrote:
On 09/30/22 11:46, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 10:33:02AM +0100, Richard W.M. Jones wrote:
Hmm, here's an interesting stackoverflow posting ...
https://stackoverflow.com/questions/3301023/gtk-spinner-not-appearing
The first point is "Make sure librsvg is installed". librsvg is _not_ installed in the ISO. Laszlo, can you try building an ISO with this package explicitly added to the deps?
Yes, that could be it. The widget is rendered using CSS and the Adwaita CSS rule references "process-working-symbolic" as the icon, and that icon is only shipped in SVG format AFAICT.
(1) sorry, I've been in write-only mode for a long while now. That's why we've apparently arrived at nearly the same conclusions thus far, duplicating (triplicating?) our efforts. That said, I'm glad we did arrive at the same ideas.
(2) A number of surprises:
(2a) p2v already spells out icewm[-lite] as a depencency, just not when the VM boot disk image / ISO image is based on Fedora (more precisely: for SUSE). When building on Fedora, the WM included is Metacity instead (and the launch script starts metacity vs. icewm accordingly.)
(2b) There is a makefile dependency bug in virt-p2v; I'm going to post the patch for that.
diff --git a/Makefile.am b/Makefile.am index 02ff1bb2eebd..2881fc947b24 100644 --- a/Makefile.am +++ b/Makefile.am @@ -328,7 +328,7 @@ $(BLANK_DISK): $(top_builddir)/run guestfish -N $@=part exit
virt-p2v.img: \ - dependencies.m4 \ + $(dependencies_files) \ issue \ launch-virt-p2v \ p2v.service \ @@ -373,7 +373,7 @@ stamp-test-virt-p2v-pxe-data-files: \ touch $@
test-virt-p2v-pxe.img: \ - dependencies.m4 \ + $(dependencies_files) \ issue \ launch-virt-p2v \ p2v.service \
Namely, even after I modified "dependencies.m4", the disk image did not get correctly regenerated for "run-virt-p2v-in-a-vm". While the image *was* regenerated, the intermediate (OS-filtered) deps files were not, and so the change I had made to "dependencies.m4" did not affect the actual package installation command line.
(2c) I learned about metacity already being present when I launched an xterm window from the first dialog of p2v, and attempted to run icewm. IceWM complained that another window manager was already present; that was when I found metacity in the process list (pstree).
(2d) I started icewm with "icewm --replace" (as recommended by the error message from (2c)), and lo and behold, two changes had come into effect:
- the spinner started working
- I actually got an actual Task Bar, where I could see all the windows: virt-p2v, the GTK debug windows (plural), the XTerm window, and (in the Tray area) even nm-applet! This is not a small improvement: QEMU doesn't let me easily inject Alt-Tab, so switching between windows in the VM environment has been a huge chore (made worse by the many GTK debug windows).
(2e) That is, elaborating on the second bullet from (2d), not only is metacity (or else, our setup/usage of metacity) bugged enough to break the spinner, it even (i) does not offer a functional task bar, (b) does not show nm-applet -- there is no tray area!
I'm of the opinion that we should just get rid of metacity altogether, and use icewm. I don't know why metacity is not working, but I consider metacity a seriously substandard WM anyway, so let's just get rid of it?
... meant to add: this has proved Daniel's point that the WM is extremely important. For the record, I use IceWM locally, so when I run virt-p2v "directly", on my workstation, and forward X11 over SSH, the reason for me seeing the spinner in the GTK3 build *may be* that I use IceWM locally. It's possible that, if I used metacity locally, the spinner would not work for me even in this X11-over-SSH setup. Also I reckon Rich does not use metacity -- originally a gtk2-based window manager -- on his laptop, but the gnome shell. gnome shell could similarly eliminate the issue. (Assuming we agree that the issue is *in* metacity.) Thanks Laszlo
On 09/30/22 13:01, Laszlo Ersek wrote:
... meant to add: this has proved Daniel's point that the WM is extremely important. For the record, I use IceWM locally, so when I run virt-p2v "directly", on my workstation, and forward X11 over SSH, the reason for me seeing the spinner in the GTK3 build *may be* that I use IceWM locally. It's possible that, if I used metacity locally, the spinner would not work for me even in this X11-over-SSH setup.
Also I reckon Rich does not use metacity -- originally a gtk2-based window manager -- on his laptop, but the gnome shell. gnome shell could similarly eliminate the issue. (Assuming we agree that the issue is *in* metacity.)
So, for Rich, the spinner works, when metacity comes from Fedora 36. Considering Koji: https://koji.fedoraproject.org/koji/packageinfo?packageID=143 Fedora 35 is based on upstream metacity 3.42.0, while Fedora 36 is on 3.44.0: https://koji.fedoraproject.org/koji/buildinfo?buildID=1853336 https://koji.fedoraproject.org/koji/buildinfo?buildID=1936492 (I've checked in the VM disk image -- it indeed contains "metacity-3.42.0-1.fc35".) Now, the upstream commit range between 3.42.0 and 3.44.0 is really small: 1 ba192a82b2e9 revert "ci: use ubuntu 21.04 image" 2 1e0b9611551b Update Croatian translation 3 503fca976051 Update Croatian translation 4 9ed3b103f6ad bump version to 3.43.1, update NEWS 5 1b052f6f8675 build: remove obsolete macros 6 b3ca2a83da79 bump version to 3.44.0, update NEWS And the fedora package contains no downstream patches AFAICT. So this does not explain why metacity works, when Rich builds the VM disk image from Fedora 36 :/ There are much more interesting updates *after* 3.44.0: 1 a3feabd50d46 icon-cache: remove support for KWM_WIN_ICON 2 7c1cc3ca1d81 window: remove incorrect mask check 3 4ea95a3b1cc3 icon-cache: make get_icon_invalidated static 4 94be8fa628e3 icon-cache: reset origin if property change invalidates icon 5 cb83bc33d32b Update Basque translation 6 5e60b4201624 Update German translation 7 bd2239178a9f Update Turkish translation 8 9eb4213af557 Update Georgian translation 9 de8ced755bff Update Turkish translation But those are not part of even rawhide at the moment. Laszlo
On Fri, Sep 30, 2022 at 01:50:43PM +0200, Laszlo Ersek wrote:
On 09/30/22 13:01, Laszlo Ersek wrote:
... meant to add: this has proved Daniel's point that the WM is extremely important. For the record, I use IceWM locally, so when I run virt-p2v "directly", on my workstation, and forward X11 over SSH, the reason for me seeing the spinner in the GTK3 build *may be* that I use IceWM locally. It's possible that, if I used metacity locally, the spinner would not work for me even in this X11-over-SSH setup.
Also I reckon Rich does not use metacity -- originally a gtk2-based window manager -- on his laptop, but the gnome shell. gnome shell could similarly eliminate the issue. (Assuming we agree that the issue is *in* metacity.)
So, for Rich, the spinner works, when metacity comes from Fedora 36.
Considering Koji:
https://koji.fedoraproject.org/koji/packageinfo?packageID=143
Fedora 35 is based on upstream metacity 3.42.0, while Fedora 36 is on 3.44.0:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1853336 https://koji.fedoraproject.org/koji/buildinfo?buildID=1936492
(I've checked in the VM disk image -- it indeed contains "metacity-3.42.0-1.fc35".)
Now, the upstream commit range between 3.42.0 and 3.44.0 is really small:
1 ba192a82b2e9 revert "ci: use ubuntu 21.04 image" 2 1e0b9611551b Update Croatian translation 3 503fca976051 Update Croatian translation 4 9ed3b103f6ad bump version to 3.43.1, update NEWS 5 1b052f6f8675 build: remove obsolete macros 6 b3ca2a83da79 bump version to 3.44.0, update NEWS
And the fedora package contains no downstream patches AFAICT.
So this does not explain why metacity works, when Rich builds the VM disk image from Fedora 36 :/
Does librsvg2 exist in both cases - there could be a different dependancy chain resulting in it not being installed in some cases. Having looked at the for p2v and gtk, I don't think window manager will affect the spinner, except by way of an indirect accident such as changed install deps. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Sep 30, 2022 at 01:01:09PM +0200, Laszlo Ersek wrote:
Also I reckon Rich does not use metacity -- originally a gtk2-based window manager -- on his laptop, but the gnome shell. gnome shell could similarly eliminate the issue. (Assuming we agree that the issue is *in* metacity.)
XFCE. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit
On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote:
On 09/30/22 11:46, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 10:33:02AM +0100, Richard W.M. Jones wrote:
Hmm, here's an interesting stackoverflow posting ...
https://stackoverflow.com/questions/3301023/gtk-spinner-not-appearing
The first point is "Make sure librsvg is installed". librsvg is _not_ installed in the ISO. Laszlo, can you try building an ISO with this package explicitly added to the deps?
Yes, that could be it. The widget is rendered using CSS and the Adwaita CSS rule references "process-working-symbolic" as the icon, and that icon is only shipped in SVG format AFAICT.
snip
I'm of the opinion that we should just get rid of metacity altogether, and use icewm. I don't know why metacity is not working, but I consider metacity a seriously substandard WM anyway, so let's just get rid of it?
Note, icewm doesn't exist in RHEL, only EPEL. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 09/30/22 13:52, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote:
On 09/30/22 11:46, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 10:33:02AM +0100, Richard W.M. Jones wrote:
Hmm, here's an interesting stackoverflow posting ...
https://stackoverflow.com/questions/3301023/gtk-spinner-not-appearing
The first point is "Make sure librsvg is installed". librsvg is _not_ installed in the ISO. Laszlo, can you try building an ISO with this package explicitly added to the deps?
Yes, that could be it. The widget is rendered using CSS and the Adwaita CSS rule references "process-working-symbolic" as the icon, and that icon is only shipped in SVG format AFAICT.
snip
I'm of the opinion that we should just get rid of metacity altogether, and use icewm. I don't know why metacity is not working, but I consider metacity a seriously substandard WM anyway, so let's just get rid of it?
Note, icewm doesn't exist in RHEL, only EPEL.
Correct, but I don't see that as a problem, considering that the last time we've officially "released" a p2v ISO, that was in the RHEL-7.6 (I think) timeframe, the infrastructure needed for building the ISO even on that major RHEL release does not exist any longer, and the only interim solution we have right now is me building the binary on my workstation and the ISO in a dedicated Fedora VM. For RHEL-9.2, it's theoretically possible that the Image Builder service can accommodate our needs, but then we're going to use custom repos anyway. (I've just finished the commit message for the replacement, and yes I mentioned EPEL9 there.) Laszlo
On Fri, Sep 30, 2022 at 02:58:19PM +0200, Laszlo Ersek wrote:
On 09/30/22 13:52, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote:
On 09/30/22 11:46, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 10:33:02AM +0100, Richard W.M. Jones wrote:
Hmm, here's an interesting stackoverflow posting ...
https://stackoverflow.com/questions/3301023/gtk-spinner-not-appearing
The first point is "Make sure librsvg is installed". librsvg is _not_ installed in the ISO. Laszlo, can you try building an ISO with this package explicitly added to the deps?
Yes, that could be it. The widget is rendered using CSS and the Adwaita CSS rule references "process-working-symbolic" as the icon, and that icon is only shipped in SVG format AFAICT.
snip
I'm of the opinion that we should just get rid of metacity altogether, and use icewm. I don't know why metacity is not working, but I consider metacity a seriously substandard WM anyway, so let's just get rid of it?
Note, icewm doesn't exist in RHEL, only EPEL.
Correct, but I don't see that as a problem, considering that the last time we've officially "released" a p2v ISO, that was in the RHEL-7.6 (I think) timeframe, the infrastructure needed for building the ISO even on that major RHEL release does not exist any longer, and the only interim solution we have right now is me building the binary on my workstation and the ISO in a dedicated Fedora VM. For RHEL-9.2, it's theoretically possible that the Image Builder service can accommodate our needs, but then we're going to use custom repos anyway.
(I've just finished the commit message for the replacement, and yes I mentioned EPEL9 there.)
I think unfortunately this is going to be a problem - we can't really depend on EPEL packages for supported RHEL products. Can we make the WM optional? ie. Change the default but keep the possibility of still using metacity around. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote:
On 09/30/22 11:46, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 10:33:02AM +0100, Richard W.M. Jones wrote:
Hmm, here's an interesting stackoverflow posting ...
https://stackoverflow.com/questions/3301023/gtk-spinner-not-appearing
The first point is "Make sure librsvg is installed". librsvg is _not_ installed in the ISO. Laszlo, can you try building an ISO with this package explicitly added to the deps?
Yes, that could be it. The widget is rendered using CSS and the Adwaita CSS rule references "process-working-symbolic" as the icon, and that icon is only shipped in SVG format AFAICT.
(1) sorry, I've been in write-only mode for a long while now. That's why we've apparently arrived at nearly the same conclusions thus far, duplicating (triplicating?) our efforts. That said, I'm glad we did arrive at the same ideas.
(2) A number of surprises:
(2a) p2v already spells out icewm[-lite] as a depencency, just not when the VM boot disk image / ISO image is based on Fedora (more precisely: for SUSE). When building on Fedora, the WM included is Metacity instead (and the launch script starts metacity vs. icewm accordingly.)
It seems like SUSE developer Cédric Bosdonnat made that addition. He actually removed metacity and replaced it with icewm-lite (commit cebcf47f6) and then made the change to the launch script to select the right WM (commit 75c24c710). However he didn't make any corresponding change to Fedora so we now have both. icewm is available in RHEL 9. I don't know if there's any reason to prefer metacity over icewm. Usually when looking at virt-p2v dependencies, we tended to prefer, in order: - availability in RHEL - small size - functionality
(2b) There is a makefile dependency bug in virt-p2v; I'm going to post the patch for that.
diff --git a/Makefile.am b/Makefile.am index 02ff1bb2eebd..2881fc947b24 100644 --- a/Makefile.am +++ b/Makefile.am @@ -328,7 +328,7 @@ $(BLANK_DISK): $(top_builddir)/run guestfish -N $@=part exit
virt-p2v.img: \ - dependencies.m4 \ + $(dependencies_files) \ issue \ launch-virt-p2v \ p2v.service \ @@ -373,7 +373,7 @@ stamp-test-virt-p2v-pxe-data-files: \ touch $@
test-virt-p2v-pxe.img: \ - dependencies.m4 \ + $(dependencies_files) \ issue \ launch-virt-p2v \ p2v.service \
Yes, seems like a mistake.
Namely, even after I modified "dependencies.m4", the disk image did not get correctly regenerated for "run-virt-p2v-in-a-vm". While the image *was* regenerated, the intermediate (OS-filtered) deps files were not, and so the change I had made to "dependencies.m4" did not affect the actual package installation command line.
Is there another missing dep or did you track down the reason for that?
(2c) I learned about metacity already being present when I launched an xterm window from the first dialog of p2v, and attempted to run icewm. IceWM complained that another window manager was already present; that was when I found metacity in the process list (pstree).
(2d) I started icewm with "icewm --replace" (as recommended by the error message from (2c)), and lo and behold, two changes had come into effect:
- the spinner started working
This is strange ..? Did librsvg get installed at some point?
- I actually got an actual Task Bar, where I could see all the windows: virt-p2v, the GTK debug windows (plural), the XTerm window, and (in the Tray area) even nm-applet! This is not a small improvement: QEMU doesn't let me easily inject Alt-Tab, so switching between windows in the VM environment has been a huge chore (made worse by the many GTK debug windows).
Yup.
(2e) That is, elaborating on the second bullet from (2d), not only is metacity (or else, our setup/usage of metacity) bugged enough to break the spinner, it even (i) does not offer a functional task bar, (b) does not show nm-applet -- there is no tray area!
I'm of the opinion that we should just get rid of metacity altogether, and use icewm. I don't know why metacity is not working, but I consider metacity a seriously substandard WM anyway, so let's just get rid of it?
Sure. I don't think we have any particular affinity to metacity. It does however depend on icewm being and staying in RHEL long term. BTW we used to use matchbox (see commit 47a3518b28). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit
On Fri, Sep 30, 2022 at 01:11:50PM +0100, Richard W.M. Jones wrote:
On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote:
On 09/30/22 11:46, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 10:33:02AM +0100, Richard W.M. Jones wrote:
Hmm, here's an interesting stackoverflow posting ...
https://stackoverflow.com/questions/3301023/gtk-spinner-not-appearing
The first point is "Make sure librsvg is installed". librsvg is _not_ installed in the ISO. Laszlo, can you try building an ISO with this package explicitly added to the deps?
Yes, that could be it. The widget is rendered using CSS and the Adwaita CSS rule references "process-working-symbolic" as the icon, and that icon is only shipped in SVG format AFAICT.
(1) sorry, I've been in write-only mode for a long while now. That's why we've apparently arrived at nearly the same conclusions thus far, duplicating (triplicating?) our efforts. That said, I'm glad we did arrive at the same ideas.
(2) A number of surprises:
(2a) p2v already spells out icewm[-lite] as a depencency, just not when the VM boot disk image / ISO image is based on Fedora (more precisely: for SUSE). When building on Fedora, the WM included is Metacity instead (and the launch script starts metacity vs. icewm accordingly.)
It seems like SUSE developer Cédric Bosdonnat made that addition. He actually removed metacity and replaced it with icewm-lite (commit cebcf47f6) and then made the change to the launch script to select the right WM (commit 75c24c710). However he didn't make any corresponding change to Fedora so we now have both.
icewm is available in RHEL 9. I don't know if there's any reason to prefer metacity over icewm. Usually when looking at virt-p2v dependencies, we tended to prefer, in order:
Only in EPEL-9, not in base RHEL-9 AFAIK.: # dnf list | grep icewm icewm.x86_64 2.9.9-1.el9 epel ... With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Sep 30, 2022 at 01:11:50PM +0100, Richard W.M. Jones wrote:
icewm is available in RHEL 9.
Actually as Dan says, this isn't true. I checked and it comes from EPEL: # dnf install icewm Updating Subscription Management repositories. Unable to read consumer identity This system is not registered with an entitlement server. You can use subscription-manager to register. Last metadata expiration check: 2:11:05 ago on Fri 30 Sep 2022 11:06:17 BST. Dependencies resolved. ================================================================================ Package Arch Version Repository Size ================================================================================ Installing: icewm x86_64 2.9.9-1.el9 epel 1.3M [...] As Dan also said, the fix seems possibly because librsvg was installed by some dependency. Can you try the simpler solution of just adding that dependency?
I don't know if there's any reason to prefer metacity over icewm. Usually when looking at virt-p2v dependencies, we tended to prefer, in order:
- availability in RHEL
This is really required, and moving icewm into RHEL isn't something that is easy to negotiate. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit
On 09/30/22 14:18, Richard W.M. Jones wrote:
On Fri, Sep 30, 2022 at 01:11:50PM +0100, Richard W.M. Jones wrote:
- availability in RHEL
This is really required, and moving icewm into RHEL isn't something that is easy to negotiate.
I'm not so sure it is really that much required; right now we don't build / distribute the p2v ISO on/from RHEL at all... Anyway, I'll try the librsvg2 dependency separately. Laszlo
On 09/30/22 14:11, Richard W.M. Jones wrote:
On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote:
On 09/30/22 11:46, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 10:33:02AM +0100, Richard W.M. Jones wrote:
Hmm, here's an interesting stackoverflow posting ...
https://stackoverflow.com/questions/3301023/gtk-spinner-not-appearing
The first point is "Make sure librsvg is installed". librsvg is _not_ installed in the ISO. Laszlo, can you try building an ISO with this package explicitly added to the deps?
Yes, that could be it. The widget is rendered using CSS and the Adwaita CSS rule references "process-working-symbolic" as the icon, and that icon is only shipped in SVG format AFAICT.
(1) sorry, I've been in write-only mode for a long while now. That's why we've apparently arrived at nearly the same conclusions thus far, duplicating (triplicating?) our efforts. That said, I'm glad we did arrive at the same ideas.
(2) A number of surprises:
(2a) p2v already spells out icewm[-lite] as a depencency, just not when the VM boot disk image / ISO image is based on Fedora (more precisely: for SUSE). When building on Fedora, the WM included is Metacity instead (and the launch script starts metacity vs. icewm accordingly.)
It seems like SUSE developer Cédric Bosdonnat made that addition. He actually removed metacity and replaced it with icewm-lite (commit cebcf47f6) and then made the change to the launch script to select the right WM (commit 75c24c710). However he didn't make any corresponding change to Fedora so we now have both.
[out of order]
BTW we used to use matchbox (see commit 47a3518b28).
I ended up tracking down the same set of commits, with git-blame. In particular, 47a3518b28e0 says that matchbox was replaced with metacity because the latter supported multiple top-level windows; IceWM trivially supports those as well, and is also light-weight. (I guess I should just get the patches on the list, rather than rewrite the commit messages in emails, piecemeal :))
icewm is available in RHEL 9. I don't know if there's any reason to prefer metacity over icewm. Usually when looking at virt-p2v dependencies, we tended to prefer, in order:
- availability in RHEL
IceWM is in EPEL9.
- small size
- functionality
IceWM is small, and (IMO) much more functional than Metacity.
(2b) There is a makefile dependency bug in virt-p2v; I'm going to post the patch for that.
diff --git a/Makefile.am b/Makefile.am index 02ff1bb2eebd..2881fc947b24 100644 --- a/Makefile.am +++ b/Makefile.am @@ -328,7 +328,7 @@ $(BLANK_DISK): $(top_builddir)/run guestfish -N $@=part exit
virt-p2v.img: \ - dependencies.m4 \ + $(dependencies_files) \ issue \ launch-virt-p2v \ p2v.service \ @@ -373,7 +373,7 @@ stamp-test-virt-p2v-pxe-data-files: \ touch $@
test-virt-p2v-pxe.img: \ - dependencies.m4 \ + $(dependencies_files) \ issue \ launch-virt-p2v \ p2v.service \
Yes, seems like a mistake.
Namely, even after I modified "dependencies.m4", the disk image did not get correctly regenerated for "run-virt-p2v-in-a-vm". While the image *was* regenerated, the intermediate (OS-filtered) deps files were not, and so the change I had made to "dependencies.m4" did not affect the actual package installation command line.
Is there another missing dep or did you track down the reason for that?
I mean the above dependency updates are the fix.
(2c) I learned about metacity already being present when I launched an xterm window from the first dialog of p2v, and attempted to run icewm. IceWM complained that another window manager was already present; that was when I found metacity in the process list (pstree).
(2d) I started icewm with "icewm --replace" (as recommended by the error message from (2c)), and lo and behold, two changes had come into effect:
- the spinner started working
This is strange ..? Did librsvg get installed at some point?
Since Daniel is asking the same -- librsvg2 is not installed in the problematic build of the ISO (with metacity). I'm currently checking if, when using IceWM, it is present... Yes, it is! I still like IceWM much more -- I'm not a sworn enemy of Metacity, so we could just add the librsvg2 dependency explicitly, but it really irks me that with Metacity, there isn't *any* task bar-like widget on the screen; no Activities button in the upper left corner, no overview of windows -- honestly, even though I could move windows around by their captions (no WM decorations, of course), for the longest time I had believed that there was *no* WM at all in place. Laszlo
- I actually got an actual Task Bar, where I could see all the windows: virt-p2v, the GTK debug windows (plural), the XTerm window, and (in the Tray area) even nm-applet! This is not a small improvement: QEMU doesn't let me easily inject Alt-Tab, so switching between windows in the VM environment has been a huge chore (made worse by the many GTK debug windows).
Yup.
(2e) That is, elaborating on the second bullet from (2d), not only is metacity (or else, our setup/usage of metacity) bugged enough to break the spinner, it even (i) does not offer a functional task bar, (b) does not show nm-applet -- there is no tray area!
I'm of the opinion that we should just get rid of metacity altogether, and use icewm. I don't know why metacity is not working, but I consider metacity a seriously substandard WM anyway, so let's just get rid of it?
Sure. I don't think we have any particular affinity to metacity. It does however depend on icewm being and staying in RHEL long term.
BTW we used to use matchbox (see commit 47a3518b28).
Rich.
On 09/30/22 14:11, Richard W.M. Jones wrote:
On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote:
(2d) I started icewm with "icewm --replace" (as recommended by the error message from (2c)), and lo and behold, two changes had come into effect:
- the spinner started working
This is strange ..? Did librsvg get installed at some point?
So, "ldd `which icewm`" reports that icewm depends on librsvg-2.so.2; therefore it's not surprising that RPM generated the proper Requires: directive for the binary icewm package. I guess with Metacity, this is not the case -- which should be fine, if Metacity itself does not use librsvg2. So it looks like a package dependency bug somewhere in or around gtk3; I guess it has a kind of plugin architecture, and the SPEC file does not properly capture the (dynamic) dependency. Interestingly, in the usptream gtk repository, on the gtk-3-24 branch, the file ".gitlab-ci/fedora-gtk3.Dockerfile" spells out "librsvg2-common" and "librsvg2", from commit 81c4fa5d505ec (which is quite non-descript in this regard). So it is a *known* hidden dependency in a way. Sigh. Packaging bug then? :/ Laszlo
On Fri, Sep 30, 2022 at 03:23:31PM +0200, Laszlo Ersek wrote:
On 09/30/22 14:11, Richard W.M. Jones wrote:
On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote:
(2d) I started icewm with "icewm --replace" (as recommended by the error message from (2c)), and lo and behold, two changes had come into effect:
- the spinner started working
This is strange ..? Did librsvg get installed at some point?
So, "ldd `which icewm`" reports that icewm depends on librsvg-2.so.2; therefore it's not surprising that RPM generated the proper Requires: directive for the binary icewm package. I guess with Metacity, this is not the case -- which should be fine, if Metacity itself does not use librsvg2.
So it looks like a package dependency bug somewhere in or around gtk3; I guess it has a kind of plugin architecture, and the SPEC file does not properly capture the (dynamic) dependency.
Interestingly, in the usptream gtk repository, on the gtk-3-24 branch, the file ".gitlab-ci/fedora-gtk3.Dockerfile" spells out "librsvg2-common" and "librsvg2", from commit 81c4fa5d505ec (which is quite non-descript in this regard). So it is a *known* hidden dependency in a way. Sigh. Packaging bug then? :/
"its complicated" :-) GTK doesn't directly know about any image formats. It is built on top of GDK-Pixbuf which is a library that provides an API for loading images, with plugins for various formats, most outsourced to other packages. librsvg2 provides a plugin for GDK-Pixbuf for SVG files. Meanwhile the usage of SVG files doesn't actually exist in GTK code either, because GTK widget rendering is theme based, and both widget and icon themes are separate. Even when the widget theme requests an icon, it doesn't specify a format, because icon themes are pluggable too and it will look for icons in whatever format happens to exist on disk. The icon theme doesn't include a dep on librsvg2 either, because the icons' package doesn't dictate what is used to load them. IOW, it is a tragedy of a highly modular framework that nothing individually needs/want to have a dep on librsvg2, but the combined work does need such a dep. In a typical Fedora/RHEL install, all the right bits will get installed either because of deps elsewhere in the default "desktop" install profile group, or because of comps groups listing librsvg. p2v though is picking a minimal set of individual packages and so misses the dep. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 09/30/22 15:35, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 03:23:31PM +0200, Laszlo Ersek wrote:
On 09/30/22 14:11, Richard W.M. Jones wrote:
On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote:
(2d) I started icewm with "icewm --replace" (as recommended by the error message from (2c)), and lo and behold, two changes had come into effect:
- the spinner started working
This is strange ..? Did librsvg get installed at some point?
So, "ldd `which icewm`" reports that icewm depends on librsvg-2.so.2; therefore it's not surprising that RPM generated the proper Requires: directive for the binary icewm package. I guess with Metacity, this is not the case -- which should be fine, if Metacity itself does not use librsvg2.
So it looks like a package dependency bug somewhere in or around gtk3; I guess it has a kind of plugin architecture, and the SPEC file does not properly capture the (dynamic) dependency.
Interestingly, in the usptream gtk repository, on the gtk-3-24 branch, the file ".gitlab-ci/fedora-gtk3.Dockerfile" spells out "librsvg2-common" and "librsvg2", from commit 81c4fa5d505ec (which is quite non-descript in this regard). So it is a *known* hidden dependency in a way. Sigh. Packaging bug then? :/
"its complicated" :-)
GTK doesn't directly know about any image formats. It is built on top of GDK-Pixbuf which is a library that provides an API for loading images, with plugins for various formats, most outsourced to other packages. librsvg2 provides a plugin for GDK-Pixbuf for SVG files.
Meanwhile the usage of SVG files doesn't actually exist in GTK code either, because GTK widget rendering is theme based, and both widget and icon themes are separate. Even when the widget theme requests an icon, it doesn't specify a format, because icon themes are pluggable too and it will look for icons in whatever format happens to exist on disk.
The icon theme doesn't include a dep on librsvg2 either, because the icons' package doesn't dictate what is used to load them.
IOW, it is a tragedy of a highly modular framework that nothing individually needs/want to have a dep on librsvg2, but the combined work does need such a dep.
In a typical Fedora/RHEL install, all the right bits will get installed either because of deps elsewhere in the default "desktop" install profile group, or because of comps groups listing librsvg. p2v though is picking a minimal set of individual packages and so misses the dep.
This is horrible. The librsvg2 package provides this file: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-svg.so which, if present, enables the whole stack to work, but if absent, breaks the stack without a peep. This is the same terrible "push" (or "registration") model (rather than the "pull") model that plagues systemd: if a kernel module is missing from the initrd that's needed for driving a device or a filesystem, the boot gets stuck without any indication of what *should* happen (i.e. what dependency is not being satisfied). There is no technical dependency whatsoever, it's just that an event does not occur that "might" otherwise "cause progress" from a global perspective. The exact same silly pattern exists in UEFI, with PPI and protocol GUID dependencies. Very powerful as long as you are developing a particular module. Once you forget about it, *and* a particular protocol GUID is provided outside of your current repository (so you can't simply grep for it), heaven help you resolve the stuck boot (as, of course, it is not easy to all to get the set of those protocol GUIDs that *might* get the DXE dispatcher unstuck via their registration in the protocol database). How is it better that the librsvg2 package, which is a *low level package*, includes a *semantic dependency* (basically: *knowledge*) of one of its high-profile comsumers (namely, gdk-pixbuf) -- a high level package --, and not the other way around? Since when is it a good idea to encode reverse dependencies in packages? The mind boggles. All of this registration stuff is for the 5% more comfort of programmers, at the 90% more discomfort of sysadmins / users. Laszlo
On Fri, Sep 30, 2022 at 03:57:15PM +0200, Laszlo Ersek wrote:
This is the same terrible "push" (or "registration") model (rather than the "pull") model that plagues systemd: if a kernel module is missing from the initrd that's needed for driving a device or a filesystem, the boot gets stuck without any indication of what *should* happen (i.e. what dependency is not being satisfied). There is no technical dependency whatsoever, it's just that an event does not occur that "might" otherwise "cause progress" from a global perspective.
The exact same silly pattern exists in UEFI, with PPI and protocol GUID dependencies. Very powerful as long as you are developing a particular module. Once you forget about it, *and* a particular protocol GUID is provided outside of your current repository (so you can't simply grep for it), heaven help you resolve the stuck boot (as, of course, it is not easy to all to get the set of those protocol GUIDs that *might* get the DXE dispatcher unstuck via their registration in the protocol database).
How is it better that the librsvg2 package, which is a *low level package*, includes a *semantic dependency* (basically: *knowledge*) of one of its high-profile comsumers (namely, gdk-pixbuf) -- a high level package --, and not the other way around? Since when is it a good idea to encode reverse dependencies in packages? The mind boggles.
All of this registration stuff is for the 5% more comfort of programmers, at the 90% more discomfort of sysadmins / users.
I think a lot of it comes from the endless quest to make smaller and smaller container images, which IMHO is little to do with any real technical problem and more to do with a kind of peacock's tail of evolutionary battles. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
On Fri, Sep 30, 2022 at 03:57:15PM +0200, Laszlo Ersek wrote:
On 09/30/22 15:35, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 03:23:31PM +0200, Laszlo Ersek wrote:
On 09/30/22 14:11, Richard W.M. Jones wrote:
On Fri, Sep 30, 2022 at 12:56:40PM +0200, Laszlo Ersek wrote:
(2d) I started icewm with "icewm --replace" (as recommended by the error message from (2c)), and lo and behold, two changes had come into effect:
- the spinner started working
This is strange ..? Did librsvg get installed at some point?
So, "ldd `which icewm`" reports that icewm depends on librsvg-2.so.2; therefore it's not surprising that RPM generated the proper Requires: directive for the binary icewm package. I guess with Metacity, this is not the case -- which should be fine, if Metacity itself does not use librsvg2.
So it looks like a package dependency bug somewhere in or around gtk3; I guess it has a kind of plugin architecture, and the SPEC file does not properly capture the (dynamic) dependency.
Interestingly, in the usptream gtk repository, on the gtk-3-24 branch, the file ".gitlab-ci/fedora-gtk3.Dockerfile" spells out "librsvg2-common" and "librsvg2", from commit 81c4fa5d505ec (which is quite non-descript in this regard). So it is a *known* hidden dependency in a way. Sigh. Packaging bug then? :/
"its complicated" :-)
GTK doesn't directly know about any image formats. It is built on top of GDK-Pixbuf which is a library that provides an API for loading images, with plugins for various formats, most outsourced to other packages. librsvg2 provides a plugin for GDK-Pixbuf for SVG files.
Meanwhile the usage of SVG files doesn't actually exist in GTK code either, because GTK widget rendering is theme based, and both widget and icon themes are separate. Even when the widget theme requests an icon, it doesn't specify a format, because icon themes are pluggable too and it will look for icons in whatever format happens to exist on disk.
The icon theme doesn't include a dep on librsvg2 either, because the icons' package doesn't dictate what is used to load them.
IOW, it is a tragedy of a highly modular framework that nothing individually needs/want to have a dep on librsvg2, but the combined work does need such a dep.
In a typical Fedora/RHEL install, all the right bits will get installed either because of deps elsewhere in the default "desktop" install profile group, or because of comps groups listing librsvg. p2v though is picking a minimal set of individual packages and so misses the dep.
This is horrible. The librsvg2 package provides this file:
snip
All of this registration stuff is for the 5% more comfort of programmers, at the 90% more discomfort of sysadmins / users.
Honestly as a packager you are stuck between a rock and a hard place. There are a bunch of users who want you to fully express all the optional deps, so they're guaranteed everything is installed by default. There are another bunch of users who want everything to be optional so they can make the most minimalist install profile in every conceivable scenario. You can't win, no matter what, a bunch of people end up being unhappy with the choices made. Over time Fedora and RHEL have tended more towards making everything highly modular at the package level, and then left the question of default "bundles of packages" to the high level such as the installer groups. Effectively it has been decided that if you're hand picking packages, you need to accept the complexity and figure out all the optional bits for your scenario. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 09/30/22 16:03, Daniel P. Berrangé wrote:
There are a bunch of users who want you to fully express all the optional deps, so they're guaranteed everything is installed by default. There are another bunch of users who want everything to be optional so they can make the most minimalist install profile in every conceivable scenario.
You can't win, no matter what, a bunch of people end up being unhappy with the choices made.
Good point -- I read Rich's allusion to containers etc a minute ago, but I didn't fully get the point just then. Now it's clearer -- "my container provides a GTK3 application that doesn't have a spinner or any other use for SVG rendering, so I want to be able to exclude librsvg2".
Over time Fedora and RHEL have tended more towards making everything highly modular at the package level, and then left the question of default "bundles of packages" to the high level such as the installer groups. Effectively it has been decided that if you're hand picking packages, you need to accept the complexity and figure out all the optional bits for your scenario.
There should be a middle of the road solution here; Suggests: or Recommends: directives, or even just plain comments, so that when I grep an upstream repository or a dist-git repository, I as a clueless human still be helped, without preventing the container folks from enjoying their minimalism. I'm testing the patch now. Laszlo
On Fri, Sep 30, 2022 at 04:39:48PM +0200, Laszlo Ersek wrote:
On 09/30/22 16:03, Daniel P. Berrangé wrote:
There are a bunch of users who want you to fully express all the optional deps, so they're guaranteed everything is installed by default. There are another bunch of users who want everything to be optional so they can make the most minimalist install profile in every conceivable scenario.
You can't win, no matter what, a bunch of people end up being unhappy with the choices made.
Good point -- I read Rich's allusion to containers etc a minute ago, but I didn't fully get the point just then. Now it's clearer -- "my container provides a GTK3 application that doesn't have a spinner or any other use for SVG rendering, so I want to be able to exclude librsvg2".
Over time Fedora and RHEL have tended more towards making everything highly modular at the package level, and then left the question of default "bundles of packages" to the high level such as the installer groups. Effectively it has been decided that if you're hand picking packages, you need to accept the complexity and figure out all the optional bits for your scenario.
There should be a middle of the road solution here; Suggests: or Recommends: directives, or even just plain comments, so that when I grep an upstream repository or a dist-git repository, I as a clueless human still be helped, without preventing the container folks from enjoying their minimalism.
Yeah the weak deps could help, but for whatever reason their usage hasn't been widely adopted With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On 09/30/22 11:04, Daniel P. Berrangé wrote:
On Fri, Sep 30, 2022 at 09:41:02AM +0100, Richard W.M. Jones wrote:
On Fri, Sep 30, 2022 at 08:55:02AM +0100, Daniel P. Berrangé wrote:
On Thu, Sep 29, 2022 at 07:12:15PM +0100, Richard W.M. Jones wrote:
On Thu, Sep 29, 2022 at 04:47:34PM +0200, Laszlo Ersek wrote:
http://lacos.interhost.hu/livecd-p2v-202209291608-gitc213ae00a337.iso
(built at c213ae00a337)
sha256: f3a149aeab0179213d74bb1eac30d5d6f807d4c9cf3a548667903d5434d5699a
No spinner!
BTW, is there any possibility your code is invoking GTK3 APIs from a thread != main GTK event loop thread ? If so, that is a sure way to get non-deterministic wierd behaviour with GTK.
Maybe? This is the code which is run when the "Test Connection" button is clicked:
https://github.com/libguestfs/virt-p2v/blob/c213ae00a337cb04e63cbfe4fb4b3af4...
It runs a thread (to test the connection using ssh) and that thread creates an idle {job? event?} in the new thread.
However I documented it as:
* Idle task called from C<test_connection_thread> (but run on the * main thread) to start the spinner in the connection dialog.
Whether that is true or not and how I deduced that, I don't recall.
The test_connection_thread code is using g_idle_add to run all GTK APIs, which results in it running in the main event loop thread. That is the correct way to deal with GTK from multiple threads.
As an idea to debug it more, try using the GTK inspector
$ GTK_DEBUG=interactive <app binary>
this will popup a second window, which lets you browse the widget hierarchy, view properties, etc. This might let you see something that's set in an incorrect way.
I've added this:
diff --git a/p2v.service b/p2v.service index 2c431b5148e9..e57db5273c8f 100644 --- a/p2v.service +++ b/p2v.service @@ -32,6 +32,7 @@ ExecStart=/usr/bin/launch-virt-p2v RemainAfterExit=yes StandardOutput=journal+console StandardError=inherit +Environment=GTK_DEBUG=interactive
[Install] WantedBy=multi-user.target
The SVG icon that the animation is supposed to display is /usr/share/icons/Adwaita/scalable-up-to-32/status/process-working-symbolic.svg (grep the "gtk-3-24" branch of the upstream gtk repo for "process-working-symbolic".) This file is present in the VM disk image as well. In the GTK debug window, when I enable Visual | Show Graphic Updates, the small rectangle where the spinner should be animated is highligted in red (dimensions slightly changing as the animation progresses). This highlighting is identical between the working and the broken cases. But in the broken case, the actual (rotated) icon is not shown under the red highlight. The entire theme engine looks CSS based, which makes it very difficult for me to debug :/ I'll try to install a simple WM (twm or icewm?) in the VM disk image; perhaps that will make a difference. Laszlo
On 09/30/22 09:55, Daniel P. Berrangé wrote:
On Thu, Sep 29, 2022 at 07:12:15PM +0100, Richard W.M. Jones wrote:
On Thu, Sep 29, 2022 at 04:47:34PM +0200, Laszlo Ersek wrote:
http://lacos.interhost.hu/livecd-p2v-202209291608-gitc213ae00a337.iso
(built at c213ae00a337)
sha256: f3a149aeab0179213d74bb1eac30d5d6f807d4c9cf3a548667903d5434d5699a
No spinner!
BTW, is there any possibility your code is invoking GTK3 APIs from a thread != main GTK event loop thread ? If so, that is a sure way to get non-deterministic wierd behaviour with GTK.
Commit 5f3aee85771c ("p2v: Remove GDK thread synchronization.", 2016-06-03) covered this, I think.
While I remember, an annoying virt-p2v bug is that the keymap is always set to the US locale (try XTerm -> localctl status). I wonder if it's easy to add a way to change the keyboard layout? In particular it doesn't work well if your password contains some punctuation character which is mapped differently on US vs local keyboards.
Assuming GTK3, you can use gsettings to change layout for apps
gsettings set org.gnome.desktop.input-sources sources "[('"xkb"','"us"'),('"xkb"','"fr"'),('"xkb"','"it"')]" gsettings set org.gnome.desktop.input-sources current 1
this can be done dynamically on the fly too
Wow that seems really flexible! Laszlo
participants (3)
-
Daniel P. Berrangé -
Laszlo Ersek -
Richard W.M. Jones