weston now compiles ! but I could not run it

[craff]

Weston did not compile ... after this patch it does.

However, more work need to run it.
Still it is not worst than before so it could probably be merged

Here are what I think should be done:

• the preConfigure phase is ugly and pkg_config should do better
• the chmod +s weston-lauch in postInstall can/should be avoided
• still I could not run it, here is one of my try with sudo:

raffalli@delli7:~$ sudo weston-launch --tty /dev/tty9
Password:
Date: 2013-06-19 CEST
[04:16:11.724] weston 1.1.1
http://wayland.freedesktop.org/
Bug reports to: https://bugs.freedesktop.org/enter_bug.cgi?product=Wayland&component=weston&version=1.1.1
Build:
[04:16:11.724] OS: Linux, 3.9.6, #1 SMP Sun Jun 16 21:44:09 UTC 2013, x86_64
[04:16:11.724] warning: XDG_RUNTIME_DIR "/run/user/1000" is not configured
correctly. Unix access mode must be 0700 but is 700,
and XDG_RUNTIME_DIR must be owned by the user, but is
owned by UID 1000.
Refer to your distribution on how to get it, or
http://www.freedesktop.org/wiki/Specifications/basedir-spec
on how to implement it.
couldn't open /root/.config/weston.ini
[04:16:11.724] Loading module '/nix/store/j52vj6ac60pa43dfc3v8bk80hndglsa9-weston-1.1.1/lib/weston/drm-backend.so'
couldn't open /root/.config/weston.ini
[04:16:11.726] initializing drm backend
couldn't open /root/.config/weston.ini
couldn't open /root/.config/weston.ini
[04:16:13.514] using /dev/dri/card0
failed to open /run/opengl-driver/lib/dri/nouveau_dri.so: /run/opengl-driver/lib/dri/nouveau_dri.so: cannot open shared object file: No such file or directory
gbm: failed to open any driver (search paths /run/opengl-driver/lib/dri)failed to load driver: nouveau
failed to load module: libgallium.so.0: cannot open shared object file: No such file or directory
[04:16:13.515] failed to initialize egl
[04:16:13.523] fatal: failed to create compositor

[Phreedom]

Is there a way to accomplish this without changing mesa derivation for everyone?

[craff]

On Tue, Jun 18, 2013 at 11:30:41PM -0700, Evgeny Egorochkin wrote:

Is there a way to accomplish this without changing mesa derivation for
everyone?

Reply to this email directly or view it on GitHub.

It seems that there is no more derivation of mesa 9.1.3 in all_packages.nix with glesv2 activated.
The was one for the previous version, so may be I did not understand well enough current mesa derivation.

May be the default mesa should be complete anyway ? I would be happy with any suggestion/recomandation/commit, as
I really would like to try wayland in production ...

Cheers,
Christophe

[craff]

weston issus, late in the buildPhase a grep command (at least the error message if from grep) on libgdm.la.
Moving it from $out to $drivers breaks the compilation process.

Il will look if I can solve this, at worst with a patch.

[craff]

In fact, the way files are moved from $out to $drivers in mesa postInstall is error prone. the file
lib/pkgconfig/gbm.pc should also be moved and patched and there are probably other issues, but
this is one of the reason weston previously failed to build (and not an easy one to detect).

[craff]

I fixed gbm.pc, but this is not the problem. And in fact I don't see the point of the moving at all.
If you have both mesa_noglu and mesa_full, they do not share $out, so we gain nothing. If people need the big mesa they have to pay the price. What we should avoid is to have both mesa_full and mesa_noglu installed.

[vcunat]

What extra features are needed that miss in standard mesa? This choice was very ad-hoc -- I looked mainly at what is currently used by apps.

[vcunat]

Eh, no LLVM dependency was only about moving to $drivers. If this is something bigger that's only useful in rarely, it's probably to build it always but as another output (this will save the duplication without forcing everyone use it).

[craff]

If we do a better derivation for mesa_full (with mesa_original_full, etc and lowPrio), then
the is no point in trying to move some less usefull library in another location.

If all your installed software require mesa, you will have mesa, it at least one software require mesa_full you will have mesa_full. I will try to do that on this pull request branch.

[craff]

This is done, on this branch : mesa is all in one dir and the is a lowPrio mesa_full with enough library for weston. Normally, if only weston requires mesa_full, nobody should install mesa_full as a dependency.

If really if you think this is bad:

• explain me with more detail why ... keep in mind that I am new to nix.
• do a patch on this branchthat allow the compilation of weston.

[craff]

not moving gallium in drivers is a progress, weston does not report anymore an error about not finding this library.
Remain two problems (at least)

• pam : I have to comment loginuid in /etc/pam.d/login and to run weston-launch as root, this is not normal
• driver : I have to run nouveau instead of nvidia (I think weston does not work at all with nvidia driver, I have to check)

[vcunat]

@craff: then main reason why mesa is split is the size of the closure. I described the sizes within the file. Note that many people never need the drivers (e.g. using proprietary libGL). Adding gles libs is an easy thing, they are small and so can easily be in the default mesa_noglu derivation.

I strongly believe that with some slight modification the current mesa (in master) will work fine even for wayland/weston. This currently makes everyone pull LLVM and the drivers (enableExtraFeatures is minor, splitting is the major difference).

[craff]

I think I understand, you mean that nix will create to separate binary package for mesa-noglu and mesa-noglu-drivers ...

By the way on my conf (a modern i7DELL with nvidia card), nouveau seems to work better than the proprietary driver (I had to switch to nouveau to try to test weston).

Finally, until weston runs, all this is pretty useless ... It is strange I fail because people on arch or ubuntu have it working ...

[vcunat]

If you manage some working solution, I'll help with the packaging so we at least don't burden those not running it too much.

From a quick search of mine, I believe it currently won't work with gallium drivers (I'm almost sure we build gallium nouveau). Arch seems to have a nice reference http://wiki.archlinux.org/index.php/Wayland

[craff]

Yes, I just saw that and am just trying without gallium_egl from mesa.

[vcunat]

Maybe you need to add nouveau to dri drivers (and remove from gallium drivers, to be sure), I don't know.

[craff]

I have nouveau in the dri drivers. But I failed to use nouveau_dri.so from mesa ...
I will give up this for a little while (there really is not enough message in the various log to hope for progress ...)

I let this pull-request open if someone else wants to try to run weston. It might be easier with another graphic card.

[bjornfor]

I tried this on a machine with Intel graphics (I have added myself to the "tty" and "video" group):

$ ./result/bin/weston-launch --tty /dev/tty1
failed to open pam session: 14: Cannot make/remove an entry for the specified session

In the journal I find this:

Jul 15 19:05:43 mini-nixos weston-launch[14451]: pam_unix(login:session): session opened for user bfo by LOGIN(uid=1000)
Jul 15 19:05:43 mini-nixos dbus[1627]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.86" (uid=1000 pid=14451 comm="./result/bin/weston-launch --tty /dev/tty1 ") interface="org.freedesktop.login1.Manager" member="C...ma81kjvr34cx-system")
Jul 15 19:05:43 mini-nixos weston-launch[14451]: pam_systemd(login:session): Failed to create session: Access denied
Jul 15 19:05:43 mini-nixos weston-launch[14451]: pam_loginuid(login:session): set_loginuid failed

Running with sudo results in the same error.

[jcumming]

@bjornfor looks like a dbus rule problem?

[bjornfor]

@jcumming: Do you know how I could debug this further? I have no experience with dbus.

[bjornfor]

It appears to be a PAM thing. The solution is apparently to delete the line "session required pam_loginuid.so" from /etc/pam.d/login. Or whatever that means for NixOS :-)

https://ask.fedoraproject.org/question/25453/weston-launch-start-problem/

[bjornfor]

Huh, I can start weston (not weston-launch) inside my KDE session (don't remember if I tried this before):

$ ./result/bin/weston

That opens up a weston compositor window with a minimal "desktop". It has a terminal icon in the upper left corner (clicking it starts a terminal) and textual clock in the upper right corner.

[garbas]

closing this PL since it is obsolete. weston is now 1.3.1 in master

[garbas]

also it runs without a problem (tried it a minute ago)