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