Re: [virt-tools-list] virt-install looking for i386 installer but should be looking for amd64 installer
On Mon, Aug 8, 2016 at 7:03 PM, Cole Robinson wrote: [snip] What could help track it down is: - See if latest virt-install --location works with a ubuntu-14.04 era ISO - If so, compare the file layout of 14.04 and 16.04 and list the differences here. Maybe the file layout changed and virtinst/urlfetcher.py needs to be extended to handle the new layout - Cole The trees of the Ubuntu Server 14.04 and 16.04 ISOs are nearly identical. Here are both, the 16.04 first: thedude@heind-gb0:/var/www/html/isos/ubus-16.04.1$ tree -L 3 . ├── boot │ └── grub │ ├── efi.img │ ├── font.pf2 │ ├── grub.cfg │ ├── loopback.cfg │ └── x86_64-efi ├── dists │ ├── stable -> xenial │ ├── unstable -> xenial │ └── xenial │ ├── main │ ├── Release │ ├── Release.gpg │ └── restricted ├── doc │ └── install │ └── manual ├── EFI │ └── BOOT │ ├── BOOTx64.EFI │ └── grubx64.efi ├── install │ ├── filesystem.manifest │ ├── filesystem.size │ ├── filesystem.squashfs │ ├── filesystem.squashfs.gpg │ ├── initrd.gz │ ├── mt86plus │ ├── netboot │ │ ├── ldlinux.c32 -> ubuntu-installer/amd64/boot-screens/ldlinux.c32 │ │ ├── pxelinux.0 -> ubuntu-installer/amd64/pxelinux.0 │ │ ├── pxelinux.cfg -> ubuntu-installer/amd64/pxelinux.cfg │ │ ├── ubuntu-installer │ │ └── version.info │ ├── README.sbm │ ├── sbm.bin │ └── vmlinuz ├── isolinux │ ├── 16x16.fnt │ ├── adtxt.cfg │ ├── am.tr │ ├── ast.hlp │ ├── ast.tr │ ├── back.jpg │ ├── be.hlp │ ├── be.tr │ ├── bg.hlp │ ├── bg.tr │ ├── bn.hlp │ ├── boot.cat │ ├── bootlogo │ ├── bs.hlp │ ├── bs.tr │ ├── ca.hlp │ ├── ca.tr │ ├── chain.c32 │ ├── cs.hlp │ ├── cs.tr │ ├── da.hlp │ ├── da.tr │ ├── de.hlp │ ├── de.tr │ ├── dtmenu.cfg │ ├── el.hlp │ ├── el.tr │ ├── en.hlp │ ├── en.tr │ ├── eo.hlp │ ├── eo.tr │ ├── es.hlp │ ├── es.tr │ ├── et.hlp │ ├── et.tr │ ├── eu.hlp │ ├── eu.tr │ ├── exithelp.cfg │ ├── f10.txt │ ├── f1.txt │ ├── f2.txt │ ├── f3.txt │ ├── f4.txt │ ├── f5.txt │ ├── f6.txt │ ├── f7.txt │ ├── f8.txt │ ├── f9.txt │ ├── fa.tr │ ├── fi.hlp │ ├── fi.tr │ ├── fr.hlp │ ├── fr.tr │ ├── ga.tr │ ├── gfxboot.c32 │ ├── gfxboot.cfg │ ├── gl.hlp │ ├── gl.tr │ ├── he.hlp │ ├── he.tr │ ├── hi.hlp │ ├── hr.tr │ ├── hu.hlp │ ├── hu.tr │ ├── id.hlp │ ├── id.tr │ ├── is.hlp │ ├── isolinux.bin │ ├── isolinux.cfg │ ├── is.tr │ ├── it.hlp │ ├── it.tr │ ├── ja.hlp │ ├── ja.tr │ ├── ka.hlp │ ├── ka.tr │ ├── kk.hlp │ ├── kk.tr │ ├── km.hlp │ ├── kn.tr │ ├── ko.hlp │ ├── ko.tr │ ├── ku.tr │ ├── langlist │ ├── ldlinux.c32 │ ├── libcom32.c32 │ ├── libutil.c32 │ ├── lo.tr │ ├── lt.hlp │ ├── lt.tr │ ├── lv.hlp │ ├── lv.tr │ ├── menu.cfg │ ├── mk.tr │ ├── mr.tr │ ├── nb.hlp │ ├── nb.tr │ ├── nl.hlp │ ├── nl.tr │ ├── nn.hlp │ ├── nn.tr │ ├── pl.hlp │ ├── pl.tr │ ├── prompt.cfg │ ├── pt_BR.hlp │ ├── pt_BR.tr │ ├── pt.hlp │ ├── pt.tr │ ├── ro.hlp │ ├── ro.tr │ ├── rqtxt.cfg │ ├── ru.hlp │ ├── ru.tr │ ├── si.hlp │ ├── si.tr │ ├── sk.hlp │ ├── sk.tr │ ├── sl.hlp │ ├── sl.tr │ ├── splash.pcx │ ├── splash.png │ ├── sq.hlp │ ├── sq.tr │ ├── sr.hlp │ ├── sr.tr │ ├── stdmenu.cfg │ ├── sv.hlp │ ├── sv.tr │ ├── te.tr │ ├── th.hlp │ ├── tl.tr │ ├── tr.hlp │ ├── tr.tr │ ├── txt.cfg │ ├── ug.hlp │ ├── uk.hlp │ ├── uk.tr │ ├── vesamenu.c32 │ ├── vi.hlp │ ├── vi.tr │ ├── zh_CN.hlp │ ├── zh_CN.tr │ ├── zh_TW.hlp │ └── zh_TW.tr ├── md5sum.txt ├── pics │ ├── blue-lowerleft.png │ ├── blue-lowerright.png │ ├── blue-upperleft.png │ ├── blue-upperright.png │ ├── debian.jpg │ ├── logo-50.jpg │ ├── red-lowerleft.png │ ├── red-lowerright.png │ ├── red-upperleft.png │ └── red-upperright.png ├── pool │ ├── main │ │ ├── a │ │ ├── b │ │ ├── c │ │ ├── d │ │ ├── e │ │ ├── f │ │ ├── g │ │ ├── h │ │ ├── i │ │ ├── j │ │ ├── k │ │ ├── l │ │ ├── liba │ │ ├── libb │ │ ├── libc │ │ ├── libd │ │ ├── libe │ │ ├── libf │ │ ├── libg │ │ ├── libh │ │ ├── libi │ │ ├── libj │ │ ├── libk │ │ ├── libl │ │ ├── libm │ │ ├── libn │ │ ├── libo │ │ ├── libp │ │ ├── libq │ │ ├── libr │ │ ├── libs │ │ ├── libt │ │ ├── libu │ │ ├── libv │ │ ├── libw │ │ ├── libx │ │ ├── liby │ │ ├── m │ │ ├── n │ │ ├── o │ │ ├── p │ │ ├── q │ │ ├── r │ │ ├── s │ │ ├── t │ │ ├── u │ │ ├── v │ │ ├── w │ │ ├── x │ │ ├── y │ │ └── z │ └── restricted │ └── i ├── preseed │ ├── cli.seed │ ├── cloud.seed │ ├── ubuntu-server-minimal.seed │ ├── ubuntu-server-minimalvm.seed │ └── ubuntu-server.seed ├── README.diskdefines └── ubuntu -> . 77 directories, 181 files thedude@hei
Re: [virt-tools-list] virt-install looking for i386 installer but should be looking for amd64 installer
On Tue, Aug 9, 2016 at 9:36 PM, Dave Hein wrote: [snip] I'll try looking at differences in the virt-install code between older > versions and 1.3.2, and see why the newer version is handling ISOs > differently. > I believe that the virt-inst that shipped with Ubuntu 14.04 (Trusty) predates the merger of the python-virtinst source into the virt-manager GitHub repo. Can anyone point me to the old python-virtinst repo, or a mirror or archive of it? [snip] ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH virt-viewer] Disable CSD to avoid rendering issues
On Wed, Aug 10, 2016 at 08:35:49AM +0200, Fabiano Fidêncio wrote:
> Pavel,
>
> On Tue, Aug 9, 2016 at 5:29 PM, Pavel Grunt wrote:
> > On Tue, 2016-08-09 at 15:57 +0100, Daniel P. Berrange wrote:
> >> On Tue, Aug 09, 2016 at 04:40:02PM +0200, Pavel Grunt wrote:
> >> >
> >> > On Tue, 2016-08-09 at 15:12 +0100, Daniel P. Berrange wrote:
> >> > >
> >> > > On Tue, Aug 09, 2016 at 04:09:15PM +0200, Pavel Grunt wrote:
> >> > > >
> >> > > >
> >> > > > Due to recent changes in gtk+ the content of window is not rendered
> >> > > > properly in Windows 10 when the client side decorations are used.
> >> > > >
> >> > > > It is possible to disable the client side decorations using
> >> > > > the GTK_CSD="0" environment variable.
> >> > > >
> >> > > > Keep them disabled to avoid issues.
> >> > > >
> >> > > > Related:
> >> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1352216
> >> > >
> >> > > Can you provide the actual GTK bug report for this issue.
> >> >
> >> > I am working on reproducer for the issue. Apparently only remote-viewer
> >> > has
> >> > problems.
> >> > >
> >> > >
> >> > > >
> >> > > >
> >> > > > ---
> >> > > > I know it is not a solution. virt-viewer should learn to work
> >> > > > properly
> >> > > > with
> >> > > > CSD
> >> > > > ---
> >> > > > src/virt-viewer-util.c | 2 ++
> >> > > > 1 file changed, 2 insertions(+)
> >> > > >
> >> > > > diff --git a/src/virt-viewer-util.c b/src/virt-viewer-util.c
> >> > > > index 0491f73..1b0335d 100644
> >> > > > --- a/src/virt-viewer-util.c
> >> > > > +++ b/src/virt-viewer-util.c
> >> > > > @@ -295,6 +295,8 @@ void virt_viewer_util_init(const char *appname)
> >> > > > }
> >> > > > }
> >> > > > #endif
> >> > > > +/* FIXME: avoid rendering issues with csd - used by default in
> >> > > > Win10*/
> >> > > > +g_setenv("GTK_CSD", "0", TRUE);
> >> > >
> >> > > At the version least you should make this hidden behind G_OS_WIN32,
> >> > > even better if you can make it only happen on Win10 at runtime.
> >> >
> >> > I wanted to keep it for every OS so it is harder to forget about fixing
> >> > it.
> >>
> >> Nope that'll break virt-viewer when run under Wayland, since AFAIK, the
> >> Wayland compositors all request CSD
> >
> > GTK_CSD is ignored under Wayland/when cannot be used. But I can of course
> > move
> > it up to the G_OS_WIN32 to make it more clear.
>
> I also prefer inside a G_OS_WIN32 ifdef.
> Another thing is that this solution is a temporary hack. So, I'd like
> to suggest to apply it only in the 4.0-maint branch.
It is bad practice to apply a fix only to a maint branch, as that opens
the possibility of forgetting to fix it in master, which means users
would see a regression on the next release. Fixes should always go into
master first, and then stable branches, even if we intend to do a better
fix in master at some point in the future.
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
___
virt-tools-list mailing list
virt-tools-list@redhat.com
https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH virt-viewer] display: Do not override size-allocate handler
On Wed, 2016-08-10 at 09:35 -0300, Eduardo Lima (Etrunko) wrote: > On 08/10/2016 07:41 AM, Pavel Grunt wrote: > > > > On Tue, 2016-08-09 at 17:44 +0200, Christophe Fergeau wrote: > > > > > > On Tue, Aug 09, 2016 at 05:17:31PM +0200, Pavel Grunt wrote: > > > > > > > > > > > > Just connect to the signal > > > > > > I'm tempted to ask "why?". I think it's recommended (more efficient) to > > > just override the vfunc directly when you can (ie when you derive a new > > > widget) rather than connecting to a signal. > > > > no strong reason, just a personal preference coming from the fact that > > virt-viewer-display is not "adjusting" its allocation, rather it is only > > using > > it for setting the allocation for its child. > > > > Well, in this case I think it would make sense. Did you get any > collateral effects with this patch? > I tested it (fedora & win client) and didn't notice anything wrong. I did not see a reason for calling 'gtk_widget_set_allocation' if gtk can do it. Pavel ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH virt-viewer] display: Do not override size-allocate handler
On 08/10/2016 07:41 AM, Pavel Grunt wrote: > On Tue, 2016-08-09 at 17:44 +0200, Christophe Fergeau wrote: >> On Tue, Aug 09, 2016 at 05:17:31PM +0200, Pavel Grunt wrote: >>> >>> Just connect to the signal >> >> I'm tempted to ask "why?". I think it's recommended (more efficient) to >> just override the vfunc directly when you can (ie when you derive a new >> widget) rather than connecting to a signal. > > no strong reason, just a personal preference coming from the fact that > virt-viewer-display is not "adjusting" its allocation, rather it is only using > it for setting the allocation for its child. > Well, in this case I think it would make sense. Did you get any collateral effects with this patch? -- Eduardo de Barros Lima (Etrunko) Software Engineer - RedHat etru...@redhat.com ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH virt-viewer] display: Do not override size-allocate handler
On 08/09/2016 12:44 PM, Christophe Fergeau wrote: > On Tue, Aug 09, 2016 at 05:17:31PM +0200, Pavel Grunt wrote: >> Just connect to the signal > > I'm tempted to ask "why?". I think it's recommended (more efficient) to > just override the vfunc directly when you can (ie when you derive a new > widget) rather than connecting to a signal. > This is a gray area to me, I don't remember exactly which cases, but sometimes overriding the virtual function will produce weird behaviors, even though the parent class function is called. Meanwhile connecting to the signal will work fine. -- Eduardo de Barros Lima (Etrunko) Software Engineer - RedHat etru...@redhat.com ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
Re: [virt-tools-list] [PATCH virt-viewer] display: Do not override size-allocate handler
On Tue, 2016-08-09 at 17:44 +0200, Christophe Fergeau wrote: > On Tue, Aug 09, 2016 at 05:17:31PM +0200, Pavel Grunt wrote: > > > > Just connect to the signal > > I'm tempted to ask "why?". I think it's recommended (more efficient) to > just override the vfunc directly when you can (ie when you derive a new > widget) rather than connecting to a signal. no strong reason, just a personal preference coming from the fact that virt-viewer-display is not "adjusting" its allocation, rather it is only using it for setting the allocation for its child. Dropping the patch Thanks, Pavel > > Christophe ___ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
