pathes in glade file aren't updated/Reduce CPU load by 100%

[alex]

Pathes in the glade aren't updated and point, if you change the installation directory, to an invalid path.
Sadly glade or builder or whatever isn't very tolerant to missing files and tries extensively to load them (CPU 100%, maybe
https://bugs.launchpad.net/virtualbrick/+bug/1017569)
Fixing it is easy. You just need to replace the wrong path via the right one by sed or alike.
sample command to fix this problem (archlinux pkgbuild):
sed -i -e "s|/usr/local/|/usr/|g" "$pkgdir"/usr/share/virtualbricks/virtualbricks.glade

[Daniele Lacamera (o-root-danielinux-net)]

Alex, thanks for noticing this. I am looking to fix it with maximum urgency.

This is not the first issue of this kind we get. The problem is that the standard python installer will put share/lib files into /usr/local prefix, while packaged versions (arch as well as deb) will expect the files to be in the /usr system prefix.

I am looking into a generic replacement in the glade file generation from the template, as it is already for versioning and other features.

[Daniele Lacamera (o-root-danielinux-net)]

Alex,

there is already a proper way to set the images path during the installation.
The reason why Debian is not affected by this, is that they seem to use to pass the "--build-base=/usr" option to setup.py command line when creating the package.

The setup.py script is in charge to replace the __IMAGE_PATH__ placeholder from the .template.glade file to generate the final .glade

I am setting this to incomplete for now.

[alex (devkral)]

I found an easy solution (builder c++):
put the glade file in the directory with the images and use as image url the simple name:
example:
instead of /usr/local/test/test.png
test.png

[Daniele Lacamera (o-root-danielinux-net)]

Correct, but we must comply with distributions' default path. Glade file will end up in $PREFIX/share/virtualbricks, while images will be in pixmaps. If you use the python installer, the default path is /usr/local. The only way to reproduce your problem is by moving the images (or the glade file) manually after the installation.

How are you installing virtualbricks?

[alex (devkral)]

I replaced the line in the desktop file for starting via terminal (undone after causing a high CPU load; this fixes the problem with the big ./.xsession-errors file (sorry I forgot to post it here))

I install virtualbricks via a modified pkgbuild:

# Maintainer: max_meyer
pkgname=virtualbricks
pkgver=0.6.352
pkgrel=1
pkgdesc="An all in one virtualization solution available for the linux desktop"
arch=(any)
url="http://virtualbricks.eu/"
license=('GPL')
depends=('gnome-python-extras' 'python2' 'libglade' 'python-pygraphviz' 'python-imaging')
makedepends=()
provides=(virtualbricks)
conflicts=(virtualbricks-bzr)
#replaces=()
#backup=()
options=('!libtool' '!emptydirs')
#install=${pkgname}.install
source=(https://launchpadlibrarian.net/89882899/virtualbricks-$pkgver.tar.bz2)
#noextract=()
sha256sums=('cefd38214a1afb19f9b7127a116d61e1b4efe7f81cbbd346b480f59bdef0146c')

PYTHON="/usr/bin/python2"

build() {
  cd "$srcdir/$pkgname"
  $PYTHON setup.py build -b "$pkgdir"
  sed -e "s/___VERSION___/$pkgver/g" < ./share/virtualbricks.template.glade > share/virtualbricks.glade
  sed -i -e "s|/usr/bin/env python2|/usr/bin/env python|g" -e "s|/usr/bin/env python|/usr/bin/env python2|g" -e "s|/usr/bin/python2|/usr/bin/python|g" -e "s|/usr/bin/python|/usr/bin/python2|g" ./setup.py ./main/virtualbricks

}

package() {
  cd "$srcdir/$pkgname"
  $PYTHON setup.py install --prefix=/usr/ --root=$pkgdir/ --optimize=1
  sed -i -e "s|/usr/local/|/usr/|g" "$pkgdir"/usr/share/virtualbricks/virtualbricks.glade
  #sed -i "s/Terminal=true/Terminal=false/" "$pkgdir"/usr/share/applications/virtualbricks.desktop
}

[alex (devkral)]

and voila there is the remaining error:
some icons don't exist in my system
The remaining errormessages:

** (process:26873): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:26873): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:26873): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
VdePlug support not found. I will disable native VDE python support.
/usr/lib/python2.7/site-packages/virtualbricks/gui/gui.py:54: GtkWarning: GtkSpinButton: setting an adjustment with non-zero page size is deprecated
  self.gladefile = gtk.glade.XML('/usr/share/virtualbricks/virtualbricks.glade')

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'edit'

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'info'

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'remove'

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'info'

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'Add to My machines'

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'stop job'

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'continue job'

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'reset job'

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'kill job'

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'attach device'

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'detach device'

(virtualbricks:26873): libglade-WARNING **: could not look up stock id 'eject'

[Francesco Apollonio (lorddex)]

these warning are related to stock icons that are provided by the gtk lib.
I have to understand if these icons don't exist anymore in the gtk lib or if there is a problem with your package.

[alex (devkral)]

I think the names changed (gtk 3.4) and/or you use some none-standard stock icons.
'reset job' seems so.

[Francesco Apollonio (lorddex)]

can you please try the attached patch?

[Francesco Apollonio (lorddex)]

can you please try the attached patch?

[Francesco Apollonio (lorddex)]

patch committed in r422

[alex (devkral)]

sorry, wasn't home.
the patch reduces the error messages to
** (process:4421): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'

** (process:4421): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'

** (process:4421): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
VdePlug support not found. I will disable native VDE python support.
/usr/lib/python2.7/site-packages/virtualbricks/gui/gui.py:57: GtkWarning: gtk_file_chooser_button_set_property: Choosers of type `GtkFileChooserButton' do not support `GTK_FILE_CHOOSER_ACTION_SAVE'.
  self.gladefile = gtk.glade.XML('/usr/share/virtualbricks/virtualbricks.glade')

I will test if the bug still appears

[alex (devkral)]

no sadly nothing changed.
A question: have you some code in virtualbricks writing "virtualbricks" in .xsession-errors?
In my .xsession-errors file stood:
virtualbricks>
virtualbricks>
virtualbricks>
virtualbricks>
virtualbricks>

and so on
after virtualbricks> are two empty spaces.

[Francesco Apollonio (lorddex)]

It's the command line print. try to start virtualbricks in a terminal
and it won't appear.

Francesco

On 19 July 2012 20:42, alex <email address hidden> wrote:
> no sadly nothing changed.
> A question: have you some code in virtualbricks writing "virtualbricks" in .xsession-errors?
> In my .xsession-errors file stood:
> virtualbricks>
> virtualbricks>
> virtualbricks>
> virtualbricks>
> virtualbricks>
>
> and so on
> after virtualbricks> are two empty spaces.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1017588
>
> Title:
> pathes in glade file aren't updated/Reduce CPU load by 100%
>
> Status in Virtualbricks:
> Incomplete
>
> Bug description:
> Pathes in the glade aren't updated and point, if you change the installation directory, to an invalid path.
> Sadly glade or builder or whatever isn't very tolerant to missing files and tries extensively to load them (CPU 100%, maybe
> https://bugs.launchpad.net/virtualbrick/+bug/1017569)
> Fixing it is easy. You just need to replace the wrong path via the right one by sed or alike.
> sample command to fix this problem (archlinux pkgbuild):
> sed -i -e "s|/usr/local/|/usr/|g" "$pkgdir"/usr/share/virtualbricks/virtualbricks.glade
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/virtualbrick/+bug/1017588/+subscriptions

[alex (devkral)]

I know. But this is an ugly hack.
Programs shouldn't need a terminal if they are GUIs.

Why is the command line print so aggressive? This isn't normal.

[Francesco Apollonio (lorddex)]

Actually VB is both a GUI and a CL program.

There is also a "-noterm" parameter but I suggest to always open both
(GUI and CL) because if sometimes the GUI freezes you can still manage
your machines using CL.

Francesco

On 20 July 2012 20:42, alex <email address hidden> wrote:
> I know. But this is an ugly hack.
> Programs shouldn't need a terminal if they are GUIs.
>
> Why is the command line print so aggressive? This isn't normal.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1017588
>
> Title:
> pathes in glade file aren't updated/Reduce CPU load by 100%
>
> Status in Virtualbricks:
> Incomplete
>
> Bug description:
> Pathes in the glade aren't updated and point, if you change the installation directory, to an invalid path.
> Sadly glade or builder or whatever isn't very tolerant to missing files and tries extensively to load them (CPU 100%, maybe
> https://bugs.launchpad.net/virtualbrick/+bug/1017569)
> Fixing it is easy. You just need to replace the wrong path via the right one by sed or alike.
> sample command to fix this problem (archlinux pkgbuild):
> sed -i -e "s|/usr/local/|/usr/|g" "$pkgdir"/usr/share/virtualbricks/virtualbricks.glade
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/virtualbrick/+bug/1017588/+subscriptions

[alex (devkral)]

adding -noterm solved the issue.
It seems as if the bug is a feature.
Of course some strange effects happen if you manipulate the terminal to make it accepting commands while running the program and I have no terminal.

>There is also a "-noterm" parameter but I suggest to always open both
>(GUI and CL) because if sometimes the GUI freezes you can still manage
>your machines using CL.
I don't like to have more than one window for one program. Have you heard of vte? It is a bit hard to program (because of few documentions) but you can include a terminal in your program window. I think this would be more cool than an external terminal. But for this a new feature request.

[Francesco Apollonio (lorddex)]

Ok, we will try to find a solution to merge the two windows, thank you very much for your feedbacks!