7:01 a.m.
(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
11:40 a.m.
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
12:02 p.m.
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 :|
4:27 a.m.
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
9:47 a.m.
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.
1:12 p.m.
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
2:49 a.m.
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
2:55 a.m.
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 :|
3:41 a.m.
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/c213ae00a337cb04e63cbfe4fb4b3...
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
4:04 a.m.
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/c213ae00a337cb04e63cbfe4fb4b3...
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 :|
4:32 a.m.
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
4:33 a.m.
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
4:46 a.m.
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 :|
5:56 a.m.
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
6:01 a.m.
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
6:50 a.m.
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
6:57 a.m.
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 :|
7:14 a.m.
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
6:52 a.m.
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 :|
7:58 a.m.
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
8:56 a.m.
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
7:11 a.m.
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
7:17 a.m.
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 :|
7:18 a.m.
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
8:17 a.m.
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
8:15 a.m.
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.
>
8:23 a.m.
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
8:35 a.m.
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 :|
8:57 a.m.
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
9:01 a.m.
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
9:03 a.m.
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 :|
9:39 a.m.
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
10:07 a.m.
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 :|
5:19 a.m.
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/c213ae00a337cb04e63cbfe4fb4b3...
>
> 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
3:42 a.m.
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
814
days inactive
816
days old
34 comments
3 participants
participants (3)
-
Daniel P. Berrangé -
Laszlo Ersek -
Richard W.M. Jones