Re: Using GNOME Continous images

[Vadim Rutkovsky <vrutkovs redhat com>]

Hey,

On Sun, Feb 22, 2015 at 4:46 PM, Daniel Svensson <dsvensson gmail com> 
wrote:
> What images to use?
>
> Here are two fairly recent directories both named "current":
> https://build.gnome.org/work/images/current/
> http://build.gnome.org/continuous/buildmaster/images/z/current/
>
> One has z in its directory and is compressed, but is also 20 days 
> older than the former, and both images are from january when we're 
> now in late febuary, which takes us to the next question..

z dir is 'old stable' in Debian's terminology - current contains last 
built image and z contains the previous to current.

> What conditions must be met for a new qcow2 image to be created?

This happens on server for almost every build. Unfortunately currently 
this task is now broken due to an error in libguestfs/qemu - we're 
working on fixing this. There is a different way to update existing VM 
- run 'ostree admin upgrade' and reboot. This will pull latest changes 
from b.g.o.

> When starting in qemu I didn't really know what to expect. Turns out 
> it leaves me without a graphical environment, and without a 
> login-prompt. To try to figure out what's going on I had to mount the 
> qcow2 image and edit the boot parameters to include console=.. which 
> together with "-serial stdio" to qemu gives you a loginprompt in the 
> terminal that launches qemu.
>
> By now I was able to login, and see that wayland seems to be started, 
> and after some googling I found that to get gdm up I needed to start 
> qemu with "-vga std" instead of relying on the default.

Yes, b.g.o makes those steps automatically during 
smoketest/integrationtest/applicationstest and so has to any manual 
tester.


> Now gdm started, and I was greeted by a list of no users, after 
> adding a user via the serial access and restarting gdm I could now 
> finally login, except that nothing happens, just the grey gdm 
> background all over the screen, for what seems likely to be, 
> forever... so that leaves me stuck.

This is probably a bug in gdm/gnome-session - check journal logs.

> So what's the suggested way of doing all of this? It feels like I'm 
> bruteforcing something that ought to have a clear path.

If you're using Continuous to develop a GTK app a better way would be 
the sandboxing way [1] - it uses yocto base similar to Continuous and 
doesn't use VMs.

> Is using the GNOME Continous images a good way to have access to the 
> latest GNOME build environment, or is it meant to be used only for 
> the automated testing the C-I infrastructure applies?

Mostly for automated testing and distro-agnostic latest changes.

> Is the kernel kdbus-patched?

AFAIK its not - its stable 3.18 now.

> Another question that popped up is if this is possible to run all of 
> this via systemd-nspawn, as a more lightweight solution. I found some 
> hacky suggestions about changing the host kernel parameters, but I'm 
> hoping those suggestions are somewhat dated by now.

I haven't experimented with this, but if you'll have some results on 
this please post here.

[1] https://wiki.gnome.org/Projects/SandboxedApps/#Building_applications

Thanks,
 Vadim