Re: Wayland design principles (Re: wayland and gambas)

[Jan Engelhardt]

On Tuesday 2024-04-30 07:23, Carsten Haitzler wrote:
>> 
>> Although gambas provides a Settings.Write(window_name) /
>> Settings.Read(window_name) that saves/restores the window placement and
>> size. It's bearable Wayland does not handle this.
>
>YOU should never be handling this. It's like saying "I'm used to having to
>hand-crank my car's motor for it to start... why can't I keep doing that?".

In keeping with the car analogy: one *can* handcrank the motor, one just 
needs a vehicle that implements *that*, so like youtu.be/4SZExEgLT_0 or, 
indeed, running gambas on an X11 interface (xorg-server, Xnest, 
Xwayland...)

>If all you do is the above, you've barely scratched the surface of
>"remembering my window". Things you don't handle above:
>
>1. Stacking remembering (relative to other things you may know nothing about
>like someoene else's windows)

I do not think anybody seriously uses overlaps, because searching
in stacks (Alt-Tab or whatever method) is kinda inefficient. People
either go big screen, workspaces/virtual desktops, or (say) temporarily
exiting/suspending an editor to run the compiler.

Re: [ANNOUNCE] weston 12.0.0

[Jan Engelhardt]

On Wednesday 2023-05-17 23:01, Jan Engelhardt wrote:
>On Wednesday 2023-05-17 21:14, Marius Vlad wrote:
>>This is the official release for weston 12.0.0.
>
>Fails to build, it misses properly adding the output from xkbcommon.pc to the
>compiler command line:[...]

Patch follows.



[5s] FAILED: libweston/libgl-borders.a.p/gl-borders.c.o 
[5s] cc -Ilibweston/libgl-borders.a.p -Ilibweston -I../libweston -I. -I.. 
-Iinclude -I../include -I/usr/include/wayland -I/usr/include/pixman-1 
-I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/freetype2 
-I/usr/include/webp -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall 
-Winvalid-pch -Wextra -Wpedantic -std=gnu99 -Wmissing-prototypes 
-Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers 
-Wno-pedantic -Wundef -fvisibility=hidden -O2 -Wall -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables 
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type 
-flto=auto -g -fPIC -MD -MQ libweston/libgl-borders.a.p/gl-borders.c.o -MF 
libweston/libgl-borders.a.p/gl-borders.c.o.d -o 
libweston/libgl-borders.a.p/gl-borders.c.o -c ../libweston/gl-borders.c
[5s] In file included from ../libweston/renderer-gl/gl-renderer.h:32,
[5s]  from ../libweston/gl-borders.h:28,
[5s]  from ../libweston/gl-borders.c:31:
[5s] ../include/libweston/libweston.h:39:10: fatal error: 
xkbcommon/xkbcommon.h: No such file or directory

[4s] FAILED: shared/libshared.a.p/config-parser.c.o 
[4s] cc -Ishared/libshared.a.p -Ishared -I../shared -I. -I.. -Iinclude 
-I../include -I/usr/include/wayland -I/usr/include/pixman-1 
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra 
-Wpedantic -std=gnu99 -Wmissing-prototypes -Wno-unused-parameter 
-Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -Wundef 
-fvisibility=hidden -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
-fstack-clash-protection -Werror=return-type -flto=auto -g -fPIC -MD -MQ 
shared/libshared.a.p/config-parser.c.o -MF 
shared/libshared.a.p/config-parser.c.o.d -o 
shared/libshared.a.p/config-parser.c.o -c ../shared/config-parser.c
[4s] In file included from ../shared/config-parser.c:44:
[4s] ../include/libweston/libweston.h:39:10: fatal error: 
xkbcommon/xkbcommon.h: No such file or directory

[6s] FAILED: tests/libtest-xwayland-client.a.p/xcb-client-helper.c.o 
[6s] cc -Itests/libtest-xwayland-client.a.p -Itests -I../tests -I. -I.. 
-Iinclude -I../include -Iprotocol -I/usr/include/pixman-1 
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra 
-Wpedantic -std=gnu99 -Wmissing-prototypes -Wno-unused-parameter 
-Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic -Wundef 
-fvisibility=hidden -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
-fstack-clash-protection -Werror=return-type -flto=auto -g -fPIC -MD -MQ 
tests/libtest-xwayland-client.a.p/xcb-client-helper.c.o -MF 
tests/libtest-xwayland-client.a.p/xcb-client-helper.c.o.d -o 
tests/libtest-xwayland-client.a.p/xcb-client-helper.c.o -c 
../tests/xcb-client-helper.c
[6s] ../tests/xcb-client-helper.c:39:10: fatal error: wayland-client.h: No 
such file or directory

---
 libweston/meson.build |1 +
 shared/meson.build|2 +-
 tests/meson.build |2 +-
 3 files changed, 3 insertions(+), 2 deletions(-)

Index: weston/libweston/meson.build
===
--- weston.orig/libweston/meson.build
+++ weston/libweston/meson.build
@@ -255,6 +255,7 @@ lib_gl_borders = static_library(
dependencies: [
dep_lib_cairo_shared,
dep_egl, # for gl-renderer.h
+   dep_xkbcommon,
],
build_by_default: false,
install: false
Index: weston/shared/meson.build
===
--- weston.orig/shared/meson.build
+++ weston/shared/meson.build
@@ -7,7 +7,7 @@ srcs_libshared = [
 'process-util.c',
'hash.c',
 ]
-deps_libshared = [dep_wayland_client, dep_wayland_server, dep_pixman]
+deps_libshared = [dep_wayland_client, dep_wayland_server, dep_pixman, 
dep_xkbcommon]
 
 lib_libshared = static_library(
'shared',
Index: weston/tests/meson.build
===
--- weston.orig/tests/meson.build
+++ weston/tests/meson.build
@@ -322,7 +322,7 @@ if get_option('xwayland')
[ 'xcb-client-helper.c', weston_test_client_protocol_h ],
include_directories: common_inc,
dependencies: [
-   dep_pixman, dep_xcb_xwayland,
+   dep_pixman, dep_wayland_client

Re: [ANNOUNCE] weston 12.0.0

[Jan Engelhardt]

On Wednesday 2023-05-17 21:14, Marius Vlad wrote:
>This is the official release for weston 12.0.0.

Fails to build, it misses properly adding the output from xkbcommon.pc to the
compiler command line:

[5s] FAILED: libweston/libgl-borders.a.p/gl-borders.c.o 
[5s] cc -Ilibweston/libgl-borders.a.p -Ilibweston -I../libweston -I. -I.. 
-Iinclude -I../include -I/usr/include/wayland -I/usr/include/pixman-1 
-I/usr/include/cairo -I/usr/include/libpng16 -I/usr/include/freetype2 
-I/usr/include/webp -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall 
-Winvalid-pch -Wextra -Wpedantic -std=gnu99 -Wmissing-prototypes 
-Wno-unused-parameter -Wno-shift-negative-value -Wno-missing-field-initializers 
-Wno-pedantic -Wundef -fvisibility=hidden -O2 -Wall -U_FORTIFY_SOURCE 
-D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables 
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type 
-flto=auto -g -fPIC -MD -MQ libweston/libgl-borders.a.p/gl-borders.c.o -MF 
libweston/libgl-borders.a.p/gl-borders.c.o.d -o 
libweston/libgl-borders.a.p/gl-borders.c.o -c ../libweston/gl-borders.c
[5s] In file included from ../libweston/renderer-gl/gl-renderer.h:32,
[5s]  from ../libweston/gl-borders.h:28,
[5s]  from ../libweston/gl-borders.c:31:
[5s] ../include/libweston/libweston.h:39:10: fatal error: 
xkbcommon/xkbcommon.h: No such file or directory
[5s]39 | #include 

Re: How to fix screen-resolution detection?

[Jan Engelhardt]

On Saturday 2022-01-08 20:57, Alan Stern wrote:

>The screen resolution on my laptop is not reported accurately.  Here's 
>an extract from the output of xdpyinfo (under Xwayland):
>
>screen #0:
>  dimensions:3200x1800 pixels (847x476 millimeters)
>  resolution:96x96 dots per inch
>
>The number of pixels is correct, but the size and resolution values 
>smack of a bogus default.

The way I remember it:

 1. Xorg(!) would read EDID once on startup, and set the DPI value
based on it. // Or you have your environment set to a fixated
DPI value, then that is used.

 2. millimeter numbers reported afterwards through X are not
EDID-based, but simply area size divided by DPI.

As such, I have, for example:

  dimensions:1920x1080 pixels (508x286 millimeters)
  resolution:96x96 dots per inch

on both a 12" and a 13" laptop.

Now, the DPI value has been fixated at 96 recently again -
https://www.phoronix.com/scan.php?page=news_item=X.Org-Server-21.1.2
because, in summary, you cannot determine a sensible global DPI
value if a system has two or more monitors of different pixel
density. Either the font is too small or too big for either screen.

(And the only way to truly have separate DPI values per monitor
might be a Xinerama-style setup where each monitor is its own
independent X (sub)screen object, hence DISPLAY=":0.0".)

And Wayland probably just behaves the same as Xorg, for the same
reasons.

Re: Proxying Wayland for security

[Jan Engelhardt]

On Wednesday 2021-07-28 12:30, Carsten Haitzler wrote:
>
>> Please read the (lengthy) discussion at [1].
>> 
>> [1]: https://gitlab.freedesktop.org/wayland/weston/-/issues/206
>> 
>> In particular, the "get_credentials → PID → executable path" lookup is
>> racy. PID re-use allows a malicious process to be recognized as another
>> executable.
>
>That is true - but only at cusp points - e.g. PID has exited, but socket has
>not been detected as dead yet and PID was recycled. I you do the lookup then,
>it'd be a problem.

Only at cusp points? What if you pass the fd from P1 to P2 via the AF_LOCAL
peercred mechanism (thus keeping it alive), have P1 exit, then spawn P3 with a
PID suitable for the attack.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Change default Wayland branches to 'main'

[Jan Engelhardt]

On Thursday 2021-04-08 16:04, Daniel Stone wrote:
>On Thu, 8 Apr 2021 at 14:02, Jan Engelhardt wrote:
>>On Thursday 2021-04-08 13:20, Daniel Stone wrote:
>>>following the leads of e.g. GitHub and GitLab, [...]
>>>I propose that we do this for all the wayland/* repositories, either this 
>>>weekend or next; I'm happy
>>>to make the changes (rename 'master' to 'main' and retarget all open MRs). 
>>>Does anyone have any
>>>opinions or suggestions?
>>
>>That could be offensive to some people. Some might even be offended by not
>>being offended.
>
>I had hoped that 'serious suggestions' was implicit

Part of the argument that Github/SFC made was inclusiveness, which is
readily debunked, and when the hypocrisy is pointed out, one gets
waved off as unserious. That's unserious in itself and shows quite a
double standard.


The serious suggestion is: try leaving it as is, save all parties the
retargeting mess, and concentrate on continued software development.

Not to mention that there isn't even a need to retarget, because you
can simply have two branches with the same commit state. Work off MRs
as time permits, and eventually all MRs to master are done, at which
point the ref can be removed.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Change default Wayland branches to 'main'

[Jan Engelhardt]

On Thursday 2021-04-08 13:20, Daniel Stone wrote:
>
>I propose that we do this for all the wayland/* repositories, either this 
>weekend or next; I'm happy
>to make the changes (rename 'master' to 'main' and retarget all open MRs). 
>Does anyone have any
>opinions or suggestions?

That could be offensive to some people. Some might even be offended by not
being offended.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Rethinking the clipboard?

[Jan Engelhardt]

On Monday 2020-12-28 20:51, Aaron Hillegass wrote:

>I'm a Mac programmer who has been spending more and more time on Linux, and I 
>have become frustrated with the way clipboards work on Linux applications.

Which aspect of it?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCE] Weston 9.0 release schedule

[Jan Engelhardt]

On Wednesday 2020-07-01 20:49, Jan Engelhardt wrote:
>
>On Wednesday 2020-07-01 19:03, Simon Ser wrote:
>>On Wednesday, July 1, 2020 5:41 PM, Jan Engelhardt  wrote:
>>
>>> However, when trying to retrieve
>>> https://wayland.freedesktop.org/releases/
>>> all I get is a 404 ("The resource that you are attempting to access
>>> does not exist or you don't have the necessary permissions to view
>>> it."). What I expected to get: an index of all files in that directory,
>>> alphabetically sorted and suffixed with the last modification date, just
>>> as apache (or other httpds) usually generate.
>>
>>What's your use-case? Why isn't the releases pages enough?

Another usecase:

Like, locating additional files - such as the .sig files - because they are not
mentioned in /releases (only indirectly by way of the link to the mailing list
announcement, and even the mail content seems prone to accidental omission).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCE] weston 8.0.91

[Jan Engelhardt]

On Thursday 2020-07-30 23:19, Simon Ser wrote:
>git tag: 8.0.91
>
>https://wayland.freedesktop.org/releases/weston-8.0.91.tar.xz
>MD5:  0148f669da7decede0156e2c6bee833a  weston-8.0.91.tar.xz
>SHA1: 477a705bd1d7d79066820abfc26fed5cc3ff17f2  weston-8.0.91.tar.xz
>SHA256: f6e77e1720a46177e9818cdf7626fda96dcfb0277bba3c677b549c5bc5cc87d4  
>weston-8.0.91.tar.xz
>SHA512: 
>caaa9cbdd6912a595e85daf28ea593c00425a63a588c7461ef858be156c202b30b65df640e5df4bf3c6b44f736bafbc76e14bb56baead633a1a72a692c2eab8f
>  weston-8.0.91.tar.xz
>PGP:  https://wayland.freedesktop.org/releases/weston-8.0.91.tar.xz.sig

This is signed with key 34FF9526CFEF0E97A340E2E40FDE7BE0E88F5E48
which has expired on 2020-04-07 already.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCE] Weston 9.0 release schedule

[Jan Engelhardt]

On Wednesday 2020-07-01 19:03, Simon Ser wrote:
>On Wednesday, July 1, 2020 5:41 PM, Jan Engelhardt  wrote:
>
>> However, when trying to retrieve
>> https://wayland.freedesktop.org/releases/
>> all I get is a 404 ("The resource that you are attempting to access
>> does not exist or you don't have the necessary permissions to view
>> it."). What I expected to get: an index of all files in that directory,
>> alphabetically sorted and suffixed with the last modification date, just
>> as apache (or other httpds) usually generate.
>
>What's your use-case? Why isn't the releases pages enough?

Usecases.. checking for releases, both new and, sometimes historic research,
old ones.

A fileindex has a "tabular" appearance where each "row" contains filename and
date, and that table be sorted primarily by filename with no extra grouping, so
that wayland-* and weston-* releases are not interspersed.

The release page is the antithesis to that: it presents items like a
blog rather than a filelisting, grouped by date with a static
reverse-date ordering, and grouping different filenames by date as
well. Imagine if `ls -l` did that all the time.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCE] Weston 9.0 release schedule

[Jan Engelhardt]

On Wednesday 2020-07-01 17:07, Simon Ser wrote:

>Hi all,
>
>Here is the release schedule for Weston 9.0, the next major version:
>
>- Alpha: July 30th, in 4 weeks
>
>Package maintainers are encouraged to pick up the pre-releases to make
>sure packaging can be tested (and fixed) before the stable release.

The https://wayland.freedesktop.org/releases.html page has hyperlinks
to e.g.
https://wayland.freedesktop.org/releases/weston-8.0.0.tar.xz

However, when trying to retrieve 
https://wayland.freedesktop.org/releases/
all I get is a 404 ("The resource that you are attempting to access 
does not exist or you don't have the necessary permissions to view 
it."). What I expected to get: an index of all files in that directory, 
alphabetically sorted and suffixed with the last modification date, just 
as apache (or other httpds) usually generate.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: The Wayland Protocol [Book]

[Jan Engelhardt]

On Tuesday 2020-05-05 05:16, Drew DeVault wrote:

>Hiya all, just writing to share that I have removed the paywall from my
>(WIP) Wayland book:
>
>https://wayland-book.com
>
>I have also made it available under CC-BY-SA. The source code is
>available here:
>
>https://git.sr.ht/~sircmpwn/wayland-book

Do you take pull requests? If so, in what form - private mail, public 
mail, or some forge-specific PR à la Github/SF?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: gitlab.fd.o financial situation and impact on services

[Jan Engelhardt]

On Friday 2020-02-28 08:59, Daniel Stone wrote:
>
>I believe that in January, we had $2082 of network cost (almost
>entirely egress; ingress is basically free) and $1750 of
>cloud-storage cost (almost all of which was download). That's based
>on 16TB of cloud-storage (CI artifacts, container images, file
>uploads, Git LFS) egress and 17.9TB of other egress (the web service
>itself, repo activity). Projecting that out [×12 for a year] gives
>us roughly $45k of network activity alone,

I had come to a similar conclusion a few years back: It is not very
economic to run ephemereal buildroots (and anything like it) between
two (or more) "significant locations" of which one end is located in
a Large Cloud datacenter like EC2/AWS/etc.

As for such usecases, me and my surrounding peers have used (other)
offerings where there is 50 TB free network/month, and yes that may
have entailed doing more adminning than elsewhere - but an admin 
appreciates $2000 a lot more than a corporation, too.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

FTBFS weston 8 test-ivi-layout.so

[Jan Engelhardt]

More weston 8 fallout.

[   42s] [352/358] cc  -o tests/test-ivi-layout.so 
'tests/59830eb@@test-ivi-layout@sha/meson-generated_.._.._protocol_weston-test-protocol.c.o'
 'tests/59830eb@@test-ivi-layout@sha/ivi-layout-test-plugin.c.o' 
-Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group 
-Wl,-soname,test-ivi-layout.so -O2 -Wall -D_FORTIFY_SOURCE=2 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
-fstack-clash-protection -Werror=return-type -flto=auto -g 
libweston/libweston-8.so.0.0.0 compositor/libexec_weston.so.0.0.0 
/usr/lib64/libwayland-server.so /usr/lib64/libpixman-1.so 
/usr/lib64/libxkbcommon.so -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/../libweston:$ORIGIN/../compositor:$ORIGIN/../shared' 
-Wl,-rpath-link,/home/abuild/rpmbuild/BUILD/weston-8.0.0/build/libweston 
-Wl,-rpath-link,/home/abuild/rpmbuild/BUILD/weston-8.0.0/build/compositor 
-Wl,-rpath-link,/home/abuild/rpmbuild/BUILD/weston-8.0.0/build/shared
[   42s] FAILED: tests/test-ivi-layout.so 
[   42s] cc  -o tests/test-ivi-layout.so 
'tests/59830eb@@test-ivi-layout@sha/meson-generated_.._.._protocol_weston-test-protocol.c.o'
 'tests/59830eb@@test-ivi-layout@sha/ivi-layout-test-plugin.c.o' 
-Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group 
-Wl,-soname,test-ivi-layout.so -O2 -Wall -D_FORTIFY_SOURCE=2 
-fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables 
-fstack-clash-protection -Werror=return-type -flto=auto -g 
libweston/libweston-8.so.0.0.0 compositor/libexec_weston.so.0.0.0 
/usr/lib64/libwayland-server.so /usr/lib64/libpixman-1.so 
/usr/lib64/libxkbcommon.so -Wl,--end-group 
'-Wl,-rpath,$ORIGIN/../libweston:$ORIGIN/../compositor:$ORIGIN/../shared' 
-Wl,-rpath-link,/home/abuild/rpmbuild/BUILD/weston-8.0.0/build/libweston 
-Wl,-rpath-link,/home/abuild/rpmbuild/BUILD/weston-8.0.0/build/compositor 
-Wl,-rpath-link,/home/abuild/rpmbuild/BUILD/weston-8.0.0/build/shared
[   42s] 
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
/tmp/test-ivi-layout.so.aofYfc.ltrans0.ltrans.o: in function 
`runner_run_handler':
[   42s] 
/home/abuild/rpmbuild/BUILD/weston-8.0.0/build/../tests/ivi-layout-test-plugin.c:71:
 undefined reference to `__start_plugin_test_section'
[   42s] 
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: 
/home/abuild/rpmbuild/BUILD/weston-8.0.0/build/../tests/ivi-layout-test-plugin.c:71:
 undefined reference to `__stop_plugin_test_section'
[   42s] collect2: error: ld returned 1 exit status

https://build.opensuse.org/package/live_build_log/X11:Wayland/weston/openSUSE_Tumbleweed/x86_64

Note that -Wl,-no-undefined is a knob enabled across the distribution (and it
has worked fine with weston-7).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: FTBFS weston 8.0

[Jan Engelhardt]

On Monday 2020-01-27 11:37, Pekka Paalanen wrote:
>
>> It was forgotten to add the pkg-config cflags from wayland into the 
>> test-runner command. This causes the weston-8 build to fail, given right 
>> system conditions.
>> 
>> [6s] [221/358] cc -Itests/59830eb@@test-runner@sta -Itests -I../tests 
>> -I. -I../ -Iinclude -I../include -fdiagnostics-color=always -pipe 
>> -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter 
>> -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic 
>> -fvisibility=hidden -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong 
>> -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection 
>> -Werror=return-type -flto=auto -g -fPIC -MD -MQ 
>> 'tests/59830eb@@test-runner@sta/weston-test-runner.c.o' -MF 
>> 'tests/59830eb@@test-runner@sta/weston-test-runner.c.o.d' -o 
>> 'tests/59830eb@@test-runner@sta/weston-test-runner.c.o' -c 
>> ../tests/weston-test-runner.c
>> [6s] FAILED: tests/59830eb@@test-runner@sta/weston-test-runner.c.o 
>> [6s] cc -Itests/59830eb@@test-runner@sta -Itests -I../tests -I. -I../ 
>> -Iinclude -I../include -fdiagnostics-color=always -pipe 
>> -D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter 
>> -Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic 
>> -fvisibility=hidden -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong 
>> -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection 
>> -Werror=return-type -flto=auto -g -fPIC -MD -MQ 
>> 'tests/59830eb@@test-runner@sta/weston-test-runner.c.o' -MF 
>> 'tests/59830eb@@test-runner@sta/weston-test-runner.c.o.d' -o 
>> 'tests/59830eb@@test-runner@sta/weston-test-runner.c.o' -c 
>> ../tests/weston-test-runner.c
>> [6s] In file included from ../tests/weston-test-runner.c:37:
>> [6s] ../tests/weston-test-runner.h:34:10: fatal error: wayland-util.h: 
>> No such file or directory
>
>could you test if
>https://gitlab.freedesktop.org/wayland/weston/merge_requests/364
>fixes this and reply in Gitlab, please?

Fixed.

>Next time, please report issues in the issue tracker:
>https://gitlab.freedesktop.org/wayland/weston/issues

Sorry, the mailing list is just much more convenient for drive-byers.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

FTBFS weston 8.0

[Jan Engelhardt]

It was forgotten to add the pkg-config cflags from wayland into the 
test-runner command. This causes the weston-8 build to fail, given right 
system conditions.

[6s] [221/358] cc -Itests/59830eb@@test-runner@sta -Itests -I../tests -I. 
-I../ -Iinclude -I../include -fdiagnostics-color=always -pipe 
-D_FILE_OFFSET_BITS=64 -std=gnu99 -Wno-unused-parameter 
-Wno-shift-negative-value -Wno-missing-field-initializers -Wno-pedantic 
-fvisibility=hidden -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong 
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection 
-Werror=return-type -flto=auto -g -fPIC -MD -MQ 
'tests/59830eb@@test-runner@sta/weston-test-runner.c.o' -MF 
'tests/59830eb@@test-runner@sta/weston-test-runner.c.o.d' -o 
'tests/59830eb@@test-runner@sta/weston-test-runner.c.o' -c 
../tests/weston-test-runner.c
[6s] FAILED: tests/59830eb@@test-runner@sta/weston-test-runner.c.o 
[6s] cc -Itests/59830eb@@test-runner@sta -Itests -I../tests -I. -I../ 
-Iinclude -I../include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 
-std=gnu99 -Wno-unused-parameter -Wno-shift-negative-value 
-Wno-missing-field-initializers -Wno-pedantic -fvisibility=hidden -O2 -Wall 
-D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables 
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type 
-flto=auto -g -fPIC -MD -MQ 
'tests/59830eb@@test-runner@sta/weston-test-runner.c.o' -MF 
'tests/59830eb@@test-runner@sta/weston-test-runner.c.o.d' -o 
'tests/59830eb@@test-runner@sta/weston-test-runner.c.o' -c 
../tests/weston-test-runner.c
[6s] In file included from ../tests/weston-test-runner.c:37:
[6s] ../tests/weston-test-runner.h:34:10: fatal error: wayland-util.h: No 
such file or directory
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: XDG_RUNTIME_DIR on a system with no "logins"

[Jan Engelhardt]

On Thursday 2019-12-19 11:13, Guillermo Rodriguez Garcia wrote:
>>
>> If you used systemd, Weston has integration for that, both startup
>> notification to ensure dependent services are started only after
>> Weston is ready and socket activation should you choose to want
>> that.
>
>Uhm. I am not sure I can switch to systemd at this point.
>How does this (Weston being ready / not ready) look like from the client side?

sd_notify works by sending a AF_LOCAL datagram to a predefined or custom
socket, you just need a suitable listener. Thinking socat here (which
would not execute anything, just print it).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: XDG_RUNTIME_DIR on a system with no "logins"

[Jan Engelhardt]

On Tuesday 2019-12-17 18:55, Guillermo Rodriguez wrote:

>Hi all,
>
>Weston requires XDG_RUNTIME_DIR to exist. The specification for this
>(https://specifications.freedesktop.org/basedir-spec/latest/ar01s03.html)
>says:
>
>===
>$XDG_RUNTIME_DIR defines the base directory relative to which
>user-specific non-essential runtime files and other file objects (such
>as sockets, named pipes, ...) should be stored. The directory MUST be
>owned by the user, and he MUST be the only one having read and write
>access to it. Its Unix access mode MUST be 0700.
>
>The lifetime of the directory MUST be bound to the user being logged
>in. It MUST be created when the user first logs in and if the user
>fully logs out the directory MUST be removed. If the user logs in more
>than once he should get pointed to the same directory, and it is
>mandatory that the directory continues to exist from his first login
>to his last logout on the system, and not removed in between. Files in
>the directory MUST not survive reboot or a full logout/login cycle.
>===
>
>But how is this done for a system where normally no users "log in",
>e.g. a fixed-function embedded system with a graphical user interface?

Well you simply create the directory before running the program that desires
said directory. Does not matter if the user identity change is by way of
a system manager, runuser(8), or login(8)/PAM (as called by xdm/etc.).


kiosk.service
 User=npc
 ExecStart=/home/npc/startx.sh

startx.sh:
 export XDG_RUNTIME_DIR=/home/npc/xdg
 rm -Rf "$XDG_RUNTIME_DIR"
 mkdir "$XDG_RUNTIME_DIR"
 weston # or whatever
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCE] weston 6.0.93

[Jan Engelhardt]

On Friday 2019-08-16 17:54, Simon Ser wrote:
>This is the RC1 release for weston 7.0.
>
>https://wayland.freedesktop.org/releases/weston-6.0.93.tar.xz

16:04 linux-37v5:~ $ wget 
https://wayland.freedesktop.org/releases/weston-6.0.93.tar.xz
--2019-08-18 16:04:56--  
https://wayland.freedesktop.org/releases/weston-6.0.93.tar.xz
Resolving wayland.freedesktop.org (wayland.freedesktop.org)... 35.185.111.185
Connecting to wayland.freedesktop.org 
(wayland.freedesktop.org)|35.185.111.185|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-08-18 16:04:58 ERROR 404: Not Found.

The entire directory is gone.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: State of network transparency & a possible approach

[Jan Engelhardt]

On Sunday 2019-03-31 08:20, Simon Ser wrote:
>On Sunday, March 31, 2019 12:29 AM, Manuel Stoeckl  wrote:
>> Hello all,
>>
>> 1.) I'd like to inquire about the state of network transparency for
>> Wayland; has there been any notable work since the
>> Wayland-over-Wire patches and krh's 'remote' branch?
>>
>I think Greenfield is relevant here [1]. It can stream a regular
>Wayland client to the browser via H.264. (You probably don't want to
>send raw frames over the network)

There is Waltham, too,
https://github.com/waltham/waltham
https://www.phoronix.com/scan.php?page=news_item=Wayland-Waltham
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCE] weston 6.0.0

[Jan Engelhardt]

On Friday 2019-03-29 12:48, Pekka Paalanen wrote:
>> >https://gitlab.freedesktop.org/wayland/weston/merge_requests/138 fixes
>https://gitlab.freedesktop.org/wayland/weston/merge_requests/141

That works. The next change that causes a stop now is:

[   20s] + make BACKEND=headless-backend.so check
[   20s] make: *** No rule to make target 'check'.  Stop.

Has that been removed?

>Next time, I would appreciate a bug report in Gitlab, since there we can
>actually track them.

I am very glad different communication methods are offered to the public,
mailing lists being one of them.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCE] weston 6.0.0

[Jan Engelhardt]

On Thursday 2019-03-28 11:33, Pekka Paalanen wrote:
>> 
>> Fails to build. Someone's forgetting the pkg-config flags for xkbcommon.
>> autotools gets this right.
>> 
>> [5s] cc -Ilibweston/2b98b6d@@session-helper@sta -Ilibweston 
>> -I../libweston -Ilibweston/.. -I../libweston/.. -Ilibwes
>> ton/../shared -I../libweston/../shared -I/usr/include/pixman-1 
>> -I/usr/include/libdrm -I/usr/include/dbus-1.0 -I/usr/lib6
>> 4/dbus-1.0/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 
>> -std=gnu99 -Wno-unused-parameter -Wno-shift-n
>> egative-value -Wno-missing-field-initializers -fvisibility=hidden -O2 -Wall 
>> -D_FORTIFY_SOURCE=2 -fstack-protector-strong
>>  -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g 
>> -fPIC  -MD -MQ 'libweston/2b98b6d@@session-hel
>> per@sta/launcher-util.c.o' -MF 
>> 'libweston/2b98b6d@@session-helper@sta/launcher-util.c.o.d' -o 
>> 'libweston/2b98b6d@@sessio
>> n-helper@sta/launcher-util.c.o' -c ../libweston/launcher-util.c
>> [5s] In file included from ../libweston/launcher-util.c:29:
>> [5s] ../libweston/compositor.h:39:10: fatal error: 
>> xkbcommon/xkbcommon.h: No such file or directory
>> [5s]  #include 
>
>Hi Jan,
>
>could you test if
>https://gitlab.freedesktop.org/wayland/weston/merge_requests/138 fixes
>your issue, please?

It does not fix the issue. The -D/-I flags from `pkg-config xkbcommon --cflags`
continue to be absent from the cc invocation.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCE] weston 6.0.0

[Jan Engelhardt]

On Thursday 2019-03-28 02:25, Derek Foreman wrote:

>Weston 6.0 is released with only a trivial build change since RC2.

Fails to build. Someone's forgetting the pkg-config flags for xkbcommon.
autotools gets this right.

[5s] cc -Ilibweston/2b98b6d@@session-helper@sta -Ilibweston -I../libweston 
-Ilibweston/.. -I../libweston/.. -Ilibwes
ton/../shared -I../libweston/../shared -I/usr/include/pixman-1 
-I/usr/include/libdrm -I/usr/include/dbus-1.0 -I/usr/lib6
4/dbus-1.0/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 
-std=gnu99 -Wno-unused-parameter -Wno-shift-n
egative-value -Wno-missing-field-initializers -fvisibility=hidden -O2 -Wall 
-D_FORTIFY_SOURCE=2 -fstack-protector-strong
 -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -g -fPIC 
 -MD -MQ 'libweston/2b98b6d@@session-hel
per@sta/launcher-util.c.o' -MF 
'libweston/2b98b6d@@session-helper@sta/launcher-util.c.o.d' -o 
'libweston/2b98b6d@@sessio
n-helper@sta/launcher-util.c.o' -c ../libweston/launcher-util.c
[5s] In file included from ../libweston/launcher-util.c:29:
[5s] ../libweston/compositor.h:39:10: fatal error: xkbcommon/xkbcommon.h: 
No such file or directory
[5s]  #include 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCEMENT] Weston builds with Meson, grace period for autotools

[Jan Engelhardt]

On Wednesday 2018-12-12 18:16, Pekka Paalanen wrote:
>
>here is an early Christmas / NewYear present / bomb (take your pick). I just
>merged https://gitlab.freedesktop.org/wayland/weston/merge_requests/8 which
>adds Meson build system to Weston.
>
>Most build options are equivalent to their autoconf counterparts, but some
>have been redesigned, hopefully in a more obvious way.
>
>Most options do not have an auto setting, and everything defaults
>to enabled [...]

Not convinced I like that.

[5s] Dependency pangocairo found: NO (tried pkgconfig)
[5s] clients/meson.build:205:0: ERROR:  Dependency "pangocairo" not found, 
tried pkgconfig

Ok, so let's see, what option do I need to disable pangocairo... of course it's
not documented, so all that's left is a grep. Easy enough.

15:11 a4:../Wayland/weston > grep -r pangocairo
weston/clients/editor.c:#include 
weston/clients/meson.build: 'add_deps': [ dependency('pangocairo') ]
weston/shared/meson.build:dep_pangocairo = dependency('pangocairo', required: 
false)
weston/shared/meson.build:if dep_pango.found() and dep_pangocairo.found() and 
dep_glib.found()
weston/shared/meson.build:  deps_cairo_shared += [ dep_pango, 
dep_pangocairo, dep_glib ]

[3s] + /usr/bin/meson --buildtype=plain --prefix=/usr --libdir=/usr/lib64
--libexecdir=/usr/lib --bindir=/usr/bin --sbindir=/usr/sbin
--includedir=/usr/include --datadir=/usr/share --mandir=/usr/share/man
--infodir=/usr/share/info --localedir=/usr/share/locale --sysconfdir=/etc
--localstatedir=/var --sharedstatedir=/var/lib --wrap-mode=nodownload
--auto-features=enabled . build -Ddemo-clients=false -Dremoting=false
-Dsimple-clients=

It still wants pangocairo -- and that's the point where I'd get frustrated.
(because shared/, unlike clients/, seems to have it marked as optional already 
AFAICT)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Launch Weston at tty1

[Jan Engelhardt]

On Wednesday 2018-09-26 06:08, deepan muthusamy wrote:

>I can able to launch Weston at tty7 but not able to launch at tty1. Why??

Probably because the tty is already allocated. (man deallocvt)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] cursor: use memfd_create or shm_open for anonymous in-memory files

[Jan Engelhardt]

On Thursday 2018-08-16 12:41, Emil Velikov wrote:
>On 15 August 2018 at 15:14, Simon Ser  wrote:
>> On Linux, try using memfd_create and file sealing. Fallback to
>> shm_open on old kernels.
>>
>> On FreeBSD, use shm_open with SHM_ANON.
>>
>> Otherwise, use shm_open with a random name, making sure the name
>> isn't already taken.
>>
>Thinking out loud:
>
>I wonder if the next POSIX standard will finally standardise
>random/anonymous shm files. Be that shm_open+SHM_ANON [...]

According to the shm_open.3 from Linux man-pages-4.16 project,
shm_open is already marked standardized:

CONFORMING TO
   POSIX.1-2001, POSIX.1-2008.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] util: abort if we try to allocate more than a MB

[Jan Engelhardt]

On Wednesday 2018-06-20 02:22, Matheus Santana wrote:

>Reviewed-by: Matheus Santana 
>
>The check for negatives isn't needed anymore?

It indeed is not, since a (size_t)-1 is generally greater than 1048576.

>  Let's put a cap on for one MB, anything above that is likely some memory
>  corruption and should be caught early.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] build: honour libinput header location

[Jan Engelhardt]

On Thursday 2018-03-15 13:20, Pekka Paalanen wrote:
>> diff --git a/Makefile.am b/Makefile.am
>> index b5c29c04..8de40e51 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -43,7 +43,8 @@ AM_CPPFLAGS =  \
>>  -I$(top_builddir)/protocol  \
>>  -DLIBWESTON_MODULEDIR='"$(libweston_moduledir)"' \
>>  -DLIBEXECDIR='"$(libexecdir)"'  \
>> --DBINDIR='"$(bindir)"'
>> +-DBINDIR='"$(bindir)"' \
>> +$(LIBINPUT_BACKEND_CFLAGS)
>>  
>>  CLEANFILES = weston.ini \
>>  ivi-shell/weston.ini\
>
>I don't think we want the libinput flags on *everything*

It does not really matter, the libinput API is not bad.
Not nearly as bad as some science software, anyhow.

The "only" downside of using target_CPPFLAGS is that
(a) the generated Makefile, Makefile.in gets bigger - somewhat larger release 
tarball
(b) sources part of multiple targets can get built twice to accomodate 
invocations
with different CPPFLAGS, even if the different CPPFLAGS still lead to the
same gcc -E output.


>Or do you think we should actually have CFLAGS of all deps with
>everything we build, and just gate the LIBS we link with to the targets
>that actually need it?

That's the easy way, and the one requiring the fewest keystrokes IMO.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [ANNOUNCE] libinput 1.10.1

[Jan Engelhardt]

On Wednesday 2018-02-28 01:27, Peter Hutterer wrote:

>libinput 1.10.1 is now available. This release fixes three crashers, one
>during tapping, two on startup/resume when the device node or seat weren't
>assigned correctly.

Is this one of them?

https://bugzilla.opensuse.org/show_bug.cgi?id=1083853
>abort() in libinput? Wow!
>
>[ 15432.133] (II) Axis 0x1 value 4758 is outside expected range [1253, 4652]
>See 
>https://wayland.freedesktop.org/libinput/doc/1.10.0//absolute_coordinate_ranges.html
> for details
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: New paths for Wayland sockets (Re: Enabling Android-style per application user ids)

[Jan Engelhardt]

On Friday 2017-11-03 10:37, Pekka Paalanen wrote:
>
>> Summary of (individual) proposals follows.
>> 
>> >- modify WAYLAND_DISPLAY to support absolute paths which overrides
>> >  any search paths  
>> 
>>  - introduce new WAYLAND_SOCKET
>>  - modify WAYLAND_DISPLAY to reject '/'
>
>What would be the functional difference to WAYLAND_DISPLAY accepting
>absolute paths? Why would a different environment variable make a
>difference?

Well because you cannot establish for certain that people have or have not
already used WAYLAND_DISPLAY=/newsock in the concatenation sense.

(Depending on who you ask and how much weight they give to it,
breaking application interfaces is out of the question. That's all.)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: New paths for Wayland sockets (Re: Enabling Android-style per application user ids)

[Jan Engelhardt]

On Friday 2017-11-03 08:33, Pekka Paalanen wrote:
>> > >
>> > > wl_display_connect() always attempts to contact a server socket living at
>> > > ${XDG_RUNTIME_DIR}/${WAYLAND_DISPLAY}.
>
>> > Modifying the meaning of WAYLAND_DISPLAY environment variable to
>> > support also absolute paths has been proposed before IIRC. Maybe
>> > resurrecting that work could be a way forward? Can anyone see a problem
>> > with that?
>> 
>> This would definitely work, so I don't object if this is the preference of
>> other reviewers. I would prefer (for the reasons coming below) the
>> /run/wayland/$WAYLAND_DISPLAY suggestion though.
>> 
>> One note about this: this would contain a subtle change in behavior to
>> existing users of $WAYLAND_DISPLAY. If somebody sets
>> WAYLAND_DISPLAY="/wayland-0" currently, this works okay. The concatenation
>> logic in wl_display_connect() results in a string
>> "/run/user///wayland-0", which is valid despite the duplicate '/'. If
>> $WAYLAND_DISPLAY is now examined for absolute-pathiness, the logic would
>> probably see "/wayland-0" as an absolute path reference, and the connection
>> attempt would fail.

So, for comparison, the X11 DISPLAY variable is an abstract identifier only.
libX11 checks that $DISPLAY matches /^:[0-9]+$/ and rejects attempts to use
e.g. "/../"-kind of injection attacks.

And I would think that the intent of WAYLAND_DISPLAY was very similar in that
its creators saw it as an identifier rather than a path component. (It
certainly has that _ring_ to it, given its proximity to X11's "DISPLAY" name.)

As such, WAYLAND_DISPLAY maybe should be hardened to reject any '/',
and consequently, a new variable ("WAYLAND_SOCKET"?) be introduced that,
if set, 1. overrides WAYLAND_DISPLAY, 2. decidedly allows path specs
to the desired effect so as to use /run/wayland/wayland-N.


Summary of (individual) proposals follows.

>- modify WAYLAND_DISPLAY to support absolute paths which overrides
>  any search paths

 - introduce new WAYLAND_SOCKET
 - modify WAYLAND_DISPLAY to reject '/'

>- when the current socket search fails, add one more place to look
>  in: /run/wayland/$WAYLAND_DISPLAY with the default "wayland-0" if
>  WAYLAND_DISPLAY is not set.

 - WAYLAND_SOCKET always overrides WAYLAND_DISPLAY
 - at most, automatic fallback if only if both WAYLAND_SOCKET and
   WAYLAND_DISPLAY are unset
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH libinput] evdev: replace null sentinel with ARRAY_SIZE

[Jan Engelhardt]

On Wednesday 2017-05-10 17:20, Dima Ryazanov wrote:
>  +#define ARRAY_SIZE(a) (sizeof(a)/sizeof(a)[0])
>
>
>I'm guessing this works, but "sizeof(a)[0]" looks very unintuitive to me. I 
>think "sizeof(a[0])" is
>the convention?

If going with the sizeof(T) syntax, then the answer would 
be "sizeof((a)[0])", or alternatively, "sizeof(*(a))".
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] doc: compact installation instructions

[Jan Engelhardt]

* Drop version-specific SO version from source-install command where
  this is not needed.
* Less typing for the user: use zypper short forms.
* Less typing for the user: libtool implies automake implies
  autoconf, so trim the install command.
* Just specify the requirement for a root shell instead of lengthily
  prefixing everything with one specific tool.
  (People might be using, for example, kdesu/gksu.)
---
 doc/building.dox | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/doc/building.dox b/doc/building.dox
index 9bafa32..53829eb 100644
--- a/doc/building.dox
+++ b/doc/building.dox
@@ -59,15 +59,15 @@ $> sudo make uninstall
 @endcode
 
 The following commands reinstall the current system package for libinput,
-overwriting manually installed files.
+overwriting manually installed files. As root, issue:
 
 
-Debian/Ubuntu based distributions: ```sudo apt-get install
+Debian/Ubuntu based distributions: ```apt-get install
 --reinstall libinput```
-Fedora 22 and later: ```sudo dnf reinstall libinput```
-RHEL/CentOS/Fedora 21 and earlier: ```sudo yum reinstall 
libinput```
-openSUSE: ```sudo zypper install --force libinput10```
-Arch: ```sudo packman -S libinput```
+Fedora 22 and later: ```dnf reinstall libinput```
+RHEL/CentOS/Fedora 21 and earlier: ```yum reinstall libinput```
+openSUSE: ```zypper in -f libinput10```
+Arch: ```pacman -S libinput```
 
 
 @subsection building_dependencies Build dependencies
@@ -75,19 +75,19 @@ overwriting manually installed files.
 libinput has a few build-time dependencies that must be installed prior to
 running configure. In most cases, it is sufficient to install the
 dependencies that your distribution uses to build the libinput package.
-These can be installed with one of the following commands:
+These can be installed with one of the following commands in a root shell:
 
 
-Debian/Ubuntu based distributions: ```sudo apt-get build-dep
+Debian/Ubuntu based distributions: ```apt-get build-dep
 libinput```
-Fedora 22 and later: ```sudo dnf builddep libinput```
-RHEL/CentOS/Fedora 21 and earlier: ```sudo yum-builddep 
libinput```
+Fedora 22 and later: ```dnf builddep libinput```
+RHEL/CentOS/Fedora 21 and earlier: ```yum-builddep libinput```
 openSUSE:
 
-$> sudo zypper modifyrepo --enable `zypper repos | grep source | awk '{print 
$5}'`
-$> sudo zypper source-install -d libinput10
-$> sudo zypper install autoconf automake libtool
-$> sudo zypper modifyrepo --disable `zypper repos | grep source | awk '{print 
$5}'`
+# zypper modifyrepo --enable `zypper repos | grep source | awk '{print $5}'`
+# zypper si -d libinput
+# zypper in libtool
+# zypper modifyrepo --disable `zypper repos | grep source | awk '{print $5}'`
 
 
 Arch:
-- 
2.12.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Fwd: wayland 1.13 testsuite fails on s390x

[Jan Engelhardt]

>From https://bugzilla.opensuse.org/show_bug.cgi?id=1029452 :
>
>wayland fails to run the testsuite on s390x since the update to 1.13. 
>The failing test is:
>
>[   24s] connection-test: tests/connection-test.c:163: 
>argument_from_va_list: Assertion `args[5].n == 105' failed.
>[   24s] test "argument_from_va_list":  signal 6, fail.

Some bug in va_list_wrapper maybe?

>Another strange error, that does not result in a FAIL is this:
>[   19s] PASS: os-wrappers-test
>[   24s] User process fault: interruption code 003b ilc:3 in 
>sanity-test[8000+9000]
>[   24s] Failing address:  TEID: 0400
>[   24s] Fault in primary space mode while using user ASCE.
>[   24s] AS:0001f52f41c7 R3:0024 
>[   24s] PASS: sanity-test
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] Update COPYING

[Jan Engelhardt]

On Wednesday 2017-02-15 16:02, Derek Foreman wrote:
>> diff --git a/COPYING b/COPYING
>> index faefd8f..418b4b4 100644
>> --- a/COPYING
>> +++ b/COPYING
>> @@ -1,8 +1,35 @@
>> +Copyright © 2008 Tungsten Graphics, Inc.
>> +Copyright © 2008-2013 Kristian Høgsberg

Since © already means Copyright, one of the two is redundant.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH 0/8] Meson build system

[Jan Engelhardt]

On Friday 2016-12-02 19:28, Daniel Stone wrote:
>On 2 December 2016 at 18:25, Emil Velikov  wrote:
>>
>> The above seems like a strange mix of build tools and (runtime)
>> dependencies.
>
>I was just trying to understand your 'distributions and/or builders
>simply cannot use python/similar tools when using distribution
>tarballs' statement. The above is the list of build dependencies for
>Debian's weston package: all of those things have to be installed in
>order to compile Weston for the Debian package.



Python can be used, but the problem with any aspirational build
system is that it probably has _some_ bugs or shortcomings that make
it produce files that do not match the distro ideals (anymore), and
because of its niche, few people know how to solve it as the decisive
knob is buried inside some 20 KLOC.

(That's samba using waf, another pythonish build system, for example.)


___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH 0/8] Meson build system

[Jan Engelhardt]

On Wednesday 2016-11-30 09:54, Pekka Paalanen wrote:
>I'm looking forward to hearing your war stories on trying to beat sense
>into autotools. I would never dare even approach it. Maybe it's FUD you
>can show to be false, but I kind of doubt it.
>
>One huge convenience of Meson is (the documentation claims) that you
>only need the one file 'meson.py' to use it, which makes the dependency
>to meson a very easy one.

I think they got it the wrong way around:
configure only needs sh+sed, while meson needs python.

The slowness of configure comes from mostly from the use of sh, and
then specifically bash, and also because you have to create new
processes for every other trivial thing like grepping in output.

That is where modern build systems could improve on. But instead they
throw *everything* overboard, even though Makefile.am is reusable:
minus custom rules, it is just a set of key-value pairs and
lazy-evaluated variables.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC PATCH 0/8] Meson build system

[Jan Engelhardt]

On Tuesday 2016-11-29 17:59, Daniel Stone wrote:

>This patchset provides a working port to Meson, a Python-based build
>system with a Ninja backend.

Do you have this available in a convenient-to-download git repo 
somewhere?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 2/2] Makefile.am: Link modules to libweston.la

[Jan Engelhardt]

On Monday 2016-11-21 12:00, Daniel Stone wrote:
>On 18 August 2016 at 10:15, Quentin Glidic
> wrote:
>> @@ -116,7 +116,9 @@ libweston_@LIBWESTON_MAJOR@_la_SOURCES = 
>>\
>>  lib_LTLIBRARIES += libweston-desktop-@LIBWESTON_MAJOR@.la
>>  libweston_desktop_@LIBWESTON_MAJOR@_la_CPPFLAGS = $(AM_CPPFLAGS) -DIN_WESTON
>>  libweston_desktop_@LIBWESTON_MAJOR@_la_CFLAGS = $(AM_CFLAGS) 
>> $(COMPOSITOR_CFLAGS)
>> -libweston_desktop_@LIBWESTON_MAJOR@_la_LIBADD = 
>> libweston-@LIBWESTON_MAJOR@.la $(COMPOSITOR_LIBS)
>> +libweston_desktop_@LIBWESTON_MAJOR@_la_LIBADD =\
>> +   libweston-@LIBWESTON_MAJOR@.la  \
>> +   $(COMPOSITOR_LIBS)
>>  libweston_desktop_@LIBWESTON_MAJOR@_la_LDFLAGS = -version-info 
>> $(LT_VERSION_INFO)
>
>COMPOSITOR_LIBS is full of -Lfoo -lsyslib. To the best of my
>knowledge, these belong in LDADD

Negative. _LDADD is ignored for library type outputs, and _LIBADD
is ignored for program type outputs.

Everything is correct here..
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland] Makefile: build also test programs during a normal build

[Jan Engelhardt]

On Wednesday 2016-11-16 17:16, Daniel Stone wrote:
>>  noinst_PROGRAMS =  \
>> +   $(built_test_programs)  \
>> +   exec-fd-leak-checker\
>> fixed-benchmark
>>
>>  check_LTLIBRARIES = libtest-runner.la
>
>Doesn't this have to be (or at least, shouldn't: I can imagine
>autotools making it a non-issue, but it is at least unclean)
>noinst_LTLIBRARIES instead? With that:

noinst_LTLIBRARIES will never build shared libraries. You can of
course do that, but it has the usual implications.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Jan Engelhardt]

On Friday 2016-07-15 15:30, Pekka Paalanen wrote:
>> >OTOH, would adding a new libweston MAJOR in an already stable and
>> >released binary distribution be absolutely forbidden? It would by
>> >definition not affect anything the distribution was released with,
>> >unless libweston's dependencies changed, but I think the
>> >dependencies might change less often than we bump MAJOR.  
>> 
>> What the distro permits is a matter of their policy. Nothing you
>> should be concerned about, because what you do is just regularly
>> releasing new versions of your software.
>
>That's true about policy, yes, but I'm getting a strange vibe here.
>You too seem to advocate ignoring distributions rather than taking
>them into account. [...]
>This is the second time I have been turned down for trying
>to figure out what distributions would like to have from the
>upstream.

Well let me rephrase it then. In openSUSE, adding a package to the
update channel (bugfix channel) is possible, as is doing so with new
SONAME, as we support selectively rebuilding packages (already have
to do that because of the kernel's unstability guarantee).

But I probably would not normally ship a new shiny libweston with new
features and new APIs in the bugfix channel, so whatever new release
may be available at freedesktop.org, it would have to wait for the
next distro release.

So it's not really a turn-down, but I just do not have anything
to request from upstream with regard to releases.


>The earlier time was when I though that avoiding circular
>dependencies between projects/packages was a good thing, and I got
>told "why would you even care about that, distributions can deal
>with it". (Not by anyone on this thread.)

There are so many upstreams, not all of which are welcoming changes
proposed that would benefit distros (mixture of don't know how to
implement, don't know how to maintain if implemented, don't care, or
not-interested). Then all we can do is workaround at the distro
level, especially if the package is essential. Think util-linux
which, in fully populated mode, has a cycle with systemd, which we
had to end by building it multiple times as things become
available. Not sure whatelse to have done there.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Jan Engelhardt]

On Thursday 2016-07-14 17:33, Emil Velikov wrote:
>
>The keypoint here is that one should _not_ need to uninstall
>libdb-4_5-devel in order to have libdb-4_8-devel and vice-versa.
>This is what parallel installability is all about (afaict).

It is indeed what it is about.
But is it _necessary_ to have? No (IMO).
Convenient? Possibly.

Perhaps I am biased because all packages that can be built can be
built in a clean namespace where the "right" devel versions are
installed. Whether that is in a source-based distro (what a weird name,
all distros are using source somewhere) or not.

>If you look closely at some (many?) of the GTK/Qt based applications
>you'll see that they support multiple versions of the respective
>toolkit. Some even support multiple version of GTK _and_ Qt at the
>same time. This is exactly what's happening (being suggested) here.

I will argue that they are slow moving targets (you can add wxWidgets
to the list). That's not the kind of bell that was sounded for
libweston ("be at 27 soon").

>The alternative is to follow the current GTK approach and
>(un)intentionally break API/ABI _between minors_. Which is a serious
>no go, imho.

An AxI break is (to be) communicated by SONAME change. If they do
that for a tarball minor, well let them. What's in a release number
anyway? The Linux kernel also "changes their ABI" between minors.

>IMHO the alias suggestion sounds quite reasonable, yet afaict
>pkg-config does not support it. Have you mentioned/suggested it to the
>pkgconfig developers ?

Nope.

>TL;DR
>* libdb is a classic example of _not_ parallel installable library and
>the OpenSuse packaging shows the efforts needed to make it one (sort
>of).

The only effort was parallel runtime installability.

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Jan Engelhardt]

On Wednesday 2016-07-13 13:54, Pekka Paalanen wrote:
>
>I think Quentin raised a good point, though. In source-based
>distros, well, in Gentoo at least which I use almost exclusively,
>there are no separate -devel packages.

A package is, abstractly, merely a selected subset of `make install`
artifacts. As such, you could install a -devel package (file set)
even on a distro which has "no -devel packages", and in fact, you can
just extend the thought to a distribution which has no concept
"packages" at all.

In other words, there is always a way to install libdb-4_5-devel, and 
uninstall it again in case one needs to make room for libdb-4_8-devel.


>Would it be so bad to assume that compositor projects would not
>bother supporting more than one (or few at most) libweston MAJOR at
>a time?

On the contrary. As a distro package recipe maintainer, you have to even 
_expect_ it will happen that a compositor requires exactly one specific 
version of libweston. (Like demonstrated, libdb already shows
why/how solved.)

>OTOH, would adding a new libweston MAJOR in an already stable and
>released binary distribution be absolutely forbidden? It would by
>definition not affect anything the distribution was released with,
>unless libweston's dependencies changed, but I think the
>dependencies might change less often than we bump MAJOR.

What the distro permits is a matter of their policy. Nothing you
should be concerned about, because what you do is just regularly
releasing new versions of your software.

>In summary, the only downside from installing all devel files
>MAJOR-specific is that user projects need multiple pkg-config
>checks if they want to support multiple MAJORs, right?
>I'd vote for taking that hit and seeing if anyone complains loud
>enough.

Well, my complaint would be:

I would want that compositors at the distro level to build against
the latest libweston, assuming it succeeds. If the compositor however
has a PKG_C_M([libweston-15]) check, I would have to update that line
with a patch _everytime a new libweston is out_, to 16, 17,  This
is why I am supporting the "do NOT version the pkgconfig filename,
and see if anyone complains" approach. With the unversioned approach,
if the build were not to succeed with 16/17/+, I only need to
make/edit a patch that changes PKG_C_M([libweston]) to [libweston-15]
_once_, and maybe revisited if and when the compositor finally
catches up.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Jan Engelhardt]

On Monday 2016-07-11 16:44, Emil Velikov wrote:
>> Without pkgconfig supporting some new alias tag (hint, hint) to cover
>> such a case,
>No idea what such a "alias tag" is supposed to do/look like. Do you
>have examples ?

Proposed concept would be to make pkgconfig recognize
a new Alias directive:
 gtk-2.0.pc:
  Name: gtk-2.0
  Version: 2
  Alias: gtk
  @OTHER_TYPICAL_FIELDS@
 gtk-3.0.pc:
  Name: foo-3.0
  Version: 3
  Alias: gtk
Result (recap):
 A single PKG_CHECK_MODULESM([gtk], [gtk >= 2]) call may be used instead of
 the usual two or more.


>> I predict that whoever uses libfoo-LotsANumbersHere
>> limits themselves to 3 or maybe 4 PKG_CHECK_MODULES calls, because it
>> is looking real silly.
>>
>If (and that's a _huge_ if) they support more than 3-4 versions of
>libfoo, then the configure.ac will be the least ugly thing.

Heh, true: The projects which do use foo-N.pc naming move about in
slow cycles (we had dbus-1, gtk-2, libnl-3 for a long time now), and
if they change, it can be assured they threw *everything* over the
fence.

Those who have just foo.pc are kind of the Linux kernel type: it
changes a bit here and there, and every now and then, and external
components with new failed builds are comparatively easily fixable.


This should not be overdiscussed; just pick something already. {1:
Either it will work out, and all is good, or it will not work out,
gets changed and then goto 1.} :p
^ That always worked out so far.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Jan Engelhardt]

On Monday 2016-07-11 16:44, Emil Velikov wrote:
>>>http://ometer.com/parallel.html. I would strongly recommend giving it
>>>a look.
>>
>> I read it now, and I do not buy it - at least not for 2016 standards.
>> According to the page, it was written in 2002, and I can confirm that
>> the situation was much worse then it is now. I can practically refute
>> all his points from the "Some more issues:" section, but for brevity,
>> I spare you the details for now.
>
>Trying to get some understanding about your experience in the area -
>which distribution(s) do you work with, how many packages do you
>maintain ?

openSUSE. Enlisted for 441, but my id appears in 2056 changelogs by now and I
bear the role of global co-reviewer, i.e. some 9100 packages.

And in the paid part of life: SLE, RH6,7, Ubu14/16, Univention, Collax (things
you never heard of), Windows(*). So I am also aware about _their_
skeletons-in-the-closet.



(*) Not a distro, but an anarchy, which is also interesting to distribute for.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Jan Engelhardt]

On Sunday 2016-07-10 13:13, Quentin Glidic wrote:
>
> If we install only one .pc file:
> - You cannot develop against an old version.

I do not feel that is true. If you have Berkeley DB 4.5 in tarball
form, you can build and `make install` it. Provided the SONAME is
different (it is; libdb-4.5.so), it *ought* not to break the rest of
your system which relies on libdb-4.8.so.

If you have db 4.5 in distropackage form, you can install the
libdb-4_5.rpm library, and it won't kick out libdb-4_8, and you can
install libdb-4_5-devel.rpm, which only kicks out libdb-4_8-devel,
but that is a negligible fact, as distro build results show that
no one seriously needs 4.5 and 4.8 at the same time a particular
software component is built.

The example extends to packages other than bdb. (bdb has no .pc
file, which is the same complexity class a one .pc file.)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Jan Engelhardt]

On Sunday 2016-07-10 12:46, Emil Velikov wrote:
>> PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [
>> ...repeat the fun...
>> ])]
>>
>Yes, it's one line of fun for each version that you want to be
>compatible with. It's not ideal, but it's a price to pay, for keeping
>things compatible/sane.

Without pkgconfig supporting some new alias tag (hint, hint) to cover
such a case, I predict that whoever uses libfoo-LotsANumbersHere
limits themselves to 3 or maybe 4 PKG_CHECK_MODULES calls, because it
is looking real silly.

>> The .so symlink is really only for /usr/bin/ld. It does not
>> play a role for ld.so (ld-linux.so.*) and therefore won't
>> interfere with plugins living in versioned directories.
>> (Cf. libmirage from cdemu)
>>
>The (main?) problem [...] is that we [...] rely on libfoo.so being
>correct.
>I get the feeling that you have not read the following
>http://ometer.com/parallel.html. I would strongly recommend giving it
>a look.

I read it now, and I do not buy it - at least not for 2016 standards.
According to the page, it was written in 2002, and I can confirm that
the situation was much worse then it is now. I can practically refute
all his points from the "Some more issues:" section, but for brevity,
I spare you the details for now.


>> Or you can just have two lines in configure.ac next to each other
>> which will scream at you "update me in lockstep" everytime you look
>> at them because you modify one of them.
>>
>> AC_INIT([libweston], [1.12.0])
>> libweston_SONUM=3
>> ->
>> AC_INIT([libweston], [1.12.90])
>> libweston_SONUM=27
>>
>This could also work, but Pekka's idea sounds more robust and simpler
>in the long run. Add the logic once and don't bother checking/keeping
>things in sync ;-)

Feels wrong to pollute configure.ac with code that tries to be
"smart" but is foremost disproportional in size to the problem. (And
you wonder why people hate $build_system_du_jour.) Would a commit
hook not be better to run a check that SONUM is in good shape w.r.t.
VERSION?

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Jan Engelhardt]

On Saturday 2016-07-09 18:24, Pekka Paalanen wrote:
>> 
>> First, what kind of parallel installability is sought?
>> 
>> * just runtime
>> * parallel development environment (like what e.g. libabw,
>>   librevenge.. do)
>
>everything that is about libweston including development enviroment
>has been my idea.
>
>> Few projects ever go to the length of making their /usr/include
>> headers or .pc files coinstallable by including some version number in
>> it.
>
>Is there any particular downside of going all the way?

For example, if a program supports being built for gtk2 and gtk3,
it can't simply do
PKG_CHECK_MODULES([gtk], [gtk >= 2])
because the developers chose to stick the version in the basename :-(
Which means that someone has to do
PKG_CHECK_EXISTS([gtk-2.0], [PKG_CHECK_MODULES([gtk], [gtk-2.0])], [
PKG_CHECK_EXISTS([gtk-3.0], [PKG_CHECK_MODULES([gtk], [gtk-3.0])], [
...repeat the fun...
])]

Now with gtk it was not so much a problem (yet!) because there
are only two different basenames in 15-or-so years.
But if weston wants to go to 27 "soon" (...)

>> >- MAJOR will start running like hell, we'll probably get to weston
>> >  27.0.0 before it slows down, or whatever  
>>
>> - if just parallel runtime is the goal: done deal, just bump
>>   the SO/ABI version (libfoo.so.2, .so.3), no one cares about
>>   how high they go
>
>We also have plugins and other stuff, to be scoped by installation
>directory.
>
>Wouldn't that cause installations to have a libfoo.so symlink
>without a version number? That we do not want, a too high risk of
>pointing to a wrong version.

The .so symlink is really only for /usr/bin/ld. It does not
play a role for ld.so (ld-linux.so.*) and therefore won't
interfere with plugins living in versioned directories.
(Cf. libmirage from cdemu)

>The point is, we need to define the libweston MAJOR to be used in
>installations separately from the project MAJOR, even if they will
>always match with releases, because they won't match during
>development.
>
>That's probably the simplest solution for starters. We could add
>configure.ac automation to use MAJOR+1 in the SONAME when project
>MICRO >= 90, too. Or maybe that will be MINOR >= 90 once we get to
>the habit of bumping MAJOR.

Or you can just have two lines in configure.ac next to each other
which will scream at you "update me in lockstep" everytime you look
at them because you modify one of them.

AC_INIT([libweston], [1.12.0])
libweston_SONUM=3
->
AC_INIT([libweston], [1.12.90])
libweston_SONUM=27

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Weston versioning (Re: [PATCH weston 6/6] libweston: do not use weston version in libweston.pc)

[Jan Engelhardt]

On Thursday 2016-07-07 11:46, Pekka Paalanen wrote:
>> >> +AC_SUBST([LIBWESTON_VERSION],
>> >> [libweston_major_version.libweston_minor_version.libweston_patch_version])
>> >>   
>> >
>> > That makes packaging a pain. Although the whole libweston (supposedly
>> > parallel-installable) is already a pain.

First, what kind of parallel installability is sought?

* just runtime
* parallel development environment (like what e.g. libabw,
  librevenge.. do)

Few projects ever go to the length of making their /usr/include
headers or .pc files coinstallable by including some version number in
it.


>- MAJOR will start running like hell, we'll probably get to weston
>  27.0.0 before it slows down, or whatever

- do you care about release numbering? (Projects with equally high
  numbers don't anymore; like Chrome, Firefox, systemd)
- if just parallel runtime is the goal: done deal, just bump
  the SO/ABI version (libfoo.so.2, .so.3), no one cares about
  how high they go
- I imagine that no one cares about the SONAME either, so you could
  try banishing the SO version into the basename and getting away with
  it. Might cause $confusion.
  (libfoo 1.12: libfoo-2.so.0; libfoo 2.0 libfoo-4.so.0)

>Hmm... but again, if we use MAJOR like that, then during the
>development of 2.0.0 we would be still installing libweston-1.so
>because our version in git master is 1.12.90 until the first
>pre-release (alpha) of 1.12.91, and so on. That doesn't seem good.
>How to solve that? Or is it not a problem?

Some projects make the bump at the start of the development cycle,
some do it just before the tarball release, and some do it together
with the first incompatible change (i.e. midway).

To be really foolproof, every _commit_ that changes things in an
incompatible way would need a bump, but that is too much hassle for
most, so they just do it between tarball releases in one of the three
just-mentioned ways.

>The thing is, libweston 1.12.90 will be completely incompatible
>with libweston 1.12.0.
>
>Should .9x be a special case somehow, installed as
>libweston-1-90.so or such?

Since 1.12.90 is probably not incompatible to 1.13.0,
they both would install whatever 1.13.0 would have used.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols] unstable: Add the Wayland Wobbly Windows protocol

[Jan Engelhardt]

On Friday 2016-04-01 18:19, Daniel Stone wrote:
>> +  
>> +Copyright C 2016  Samsung Electronics
>
>It's 2016: we have Unicode copyright codepoints.

More specifically, since © is the same as the word 'copyright', one
of them is, in fact, completely redundant. (Means: Either write
© 2016 or Copyright 2016.)

>> +  
>
>Where did we land on capitalisation rules for protocol elements? I forget.

It is correct as presented. Title case is applicable here for
"Wayland Wobbly Windows". As for the entire summary, since it
does not appear to be flowtext/prose, title case works good for it
too.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston v4] refactor x11-backend configuration API

[Jan Engelhardt]

On Monday 2016-03-21 22:58, Benoit Gschwind wrote:
> struct x11_output {
>@@ -130,6 +127,11 @@ struct window_delete_data {
> 
> struct gl_renderer_interface *gl_renderer;
> 
>+static void
>+weston_x11_backend_config_init_default(struct weston_x11_backend_config * 
>ths) {
>+  bzero(ths, sizeof(*ths));
>+}
>+

bzero - in this day and age?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wayland 1.6.91 testsuite failure [Re: [ANNOUNCE] wayland 1.6.91]

[Jan Engelhardt]

On Monday 2015-02-02 11:17, Marek Chalupa wrote:

Sent a patch that fixed it for me. I meant to send it as a reply to this,
but something went wrong.
Here it is: [PATCH wayland] test-runner: wait for concrete pid 

Does it fix it on your side?

Nope, the patch does not address my issue. However, running the 
testsuite with make -j1 makes it suceed it seems.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

wayland 1.6.91 testsuite failure [Re: [ANNOUNCE] wayland 1.6.91]

[Jan Engelhardt]

From openSUSE's attempts to build wayland 1.6.91:

[   98s] 
[   98s] Timeout was set to 3 seconds from now.
[   98s] test threading_errors_tst:   exit status 0, pass.
[   98s] 
[   98s] unable to open lockfile 
/home/abuild/rpmbuild/BUILD/wayland-1.6.91/xdg/wayland-tests/wayland-test-6076-1422702535552354.lock
 
check permissions
[   98s] display-test: tests/test-compositor.c:295: display_create: 
Assertion `stat == 0  Failed adding socket' failed.
[   98s] test post_nomem_tst: signal 6, fail.


Parts of the testsuite fail randomly, i.e. there seems to be a race
condition involved.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] build: honor results obtained by pkg-config libinput

[Jan Engelhardt]

The error was:
src/libinput-seat.c:30:22: fatal error: libinput.h: No such file or directory
---
 Makefile.am | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index b2d6893..7f3e5d3 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -34,7 +34,8 @@ AM_CPPFLAGS = \
-DDATADIR='$(datadir)'\
-DMODULEDIR='$(moduledir)'\
-DLIBEXECDIR='$(libexecdir)'  \
-   -DBINDIR='$(bindir)'
+   -DBINDIR='$(bindir)' \
+   $(LIBINPUT_BACKEND_CFLAGS)
 
 CLEANFILES = weston.ini $(BUILT_SOURCES)
 
-- 
2.0.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/2] build: symbol ck_assert_ptr_ne requires check-0.9.10

[Jan Engelhardt]

openSUSE 12.3 ships with check-0.9.9 and subsequently fails to build
the tests. Change the call to look for check = 0.9.10 where that
symbol is available.

Signed-off-by: Jan Engelhardt jeng...@inai.de
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index bb702c0..b3d2446 100644
--- a/configure.ac
+++ b/configure.ac
@@ -96,7 +96,7 @@ AC_ARG_ENABLE(tests,
  [build_tests=$enableval],
  [build_tests=auto])
 
-PKG_CHECK_MODULES(CHECK, [check = 0.9.9], [HAVE_CHECK=yes], 
[HAVE_CHECK=no])
+PKG_CHECK_MODULES(CHECK, [check = 0.9.10], [HAVE_CHECK=yes], 
[HAVE_CHECK=no])
 
 if test x$build_tests = xauto; then
build_tests=$HAVE_CHECK
-- 
2.0.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] build: use symbol versioning

[Jan Engelhardt]

Symbol versions provide a means by which ELF utilities can determine
whether a program is incompatible with a too-old library version so
that package management tools can autodetect version-based
dependencies and suggest upgrade paths.

Signed-off-by: Jan Engelhardt jeng...@inai.de
---
The name chosen for symbols (V_0.4.3) does not play a role as long as it is
unique within a particular .so file. Therefore, there is also no requirement
to use fancy long names like LIBXKBCOMMON_0.4.3.

 Makefile.am   |  2 ++
 xkbcommon-x11.map | 73 +++
 xkbcommon.map |  9 +++
 3 files changed, 84 insertions(+)
 create mode 100644 xkbcommon-x11.map
 create mode 100644 xkbcommon.map

diff --git a/Makefile.am b/Makefile.am
index 6ad2cd6..ccba897 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -84,6 +84,7 @@ libxkbcommon_la_SOURCES = \
src/utf8.h \
src/utils.c \
src/utils.h
+libxkbcommon_la_LDFLAGS = -Wl,--version-script=${srcdir}/xkbcommon-x11.map
 
 if ENABLE_X11
 pkgconfig_DATA += xkbcommon-x11.pc
@@ -97,6 +98,7 @@ lib_LTLIBRARIES += libxkbcommon-x11.la
 libxkbcommon_x11_la_CFLAGS = $(AM_CFLAGS) $(XCB_XKB_CFLAGS)
 libxkbcommon_x11_la_CPPFLAGS = $(AM_CPPFLAGS) -I$(top_srcdir)/src/x11
 libxkbcommon_x11_la_LIBADD = libxkbcommon.la $(XCB_XKB_LIBS)
+libxkbcommon_x11_la_LDFLAGS = -Wl,--version-script=${srcdir}/xkbcommon.map
 
 libxkbcommon_x11_la_SOURCES = \
src/x11/keymap.c \
diff --git a/xkbcommon-x11.map b/xkbcommon-x11.map
new file mode 100644
index 000..919c0dc
--- /dev/null
+++ b/xkbcommon-x11.map
@@ -0,0 +1,73 @@
+V_0.4.3 {
+global:
+   xkb_keysym_get_name;
+   xkb_keysym_from_name;
+   xkb_keysym_to_utf8;
+   xkb_keysym_to_utf32;
+   xkb_context_new;
+   xkb_context_ref;
+   xkb_context_unref;
+   xkb_context_set_user_data;
+   xkb_context_get_user_data;
+   xkb_context_include_path_append;
+   xkb_context_include_path_append_default;
+   xkb_context_include_path_reset_defaults;
+   xkb_context_include_path_clear;
+   xkb_context_num_include_paths;
+   xkb_context_include_path_get;
+   xkb_context_set_log_level;
+   xkb_context_get_log_level;
+   xkb_context_set_log_verbosity;
+   xkb_context_get_log_verbosity;
+   xkb_context_set_log_fn;
+   xkb_keymap_new_from_names;
+   xkb_keymap_new_from_file;
+   xkb_keymap_new_from_string;
+   xkb_keymap_new_from_buffer;
+   xkb_keymap_ref;
+   xkb_keymap_unref;
+   xkb_keymap_get_as_string;
+   xkb_keymap_min_keycode;
+   xkb_keymap_max_keycode;
+   xkb_keymap_key_for_each;
+   xkb_keymap_num_mods;
+   xkb_keymap_mod_get_name;
+   xkb_keymap_mod_get_index;
+   xkb_keymap_num_layouts;
+   xkb_keymap_layout_get_name;
+   xkb_keymap_layout_get_index;
+   xkb_keymap_num_layouts_for_key;
+   xkb_keymap_num_levels_for_key;
+   xkb_keymap_key_get_syms_by_level;
+   xkb_keymap_num_leds;
+   xkb_keymap_led_get_name;
+   xkb_keymap_led_get_index;
+   xkb_keymap_key_repeats;
+   xkb_state_new;
+   xkb_state_ref;
+   xkb_state_unref;
+   xkb_state_get_keymap;
+   xkb_state_update_key;
+   xkb_state_update_mask;
+   xkb_state_key_get_syms;
+   xkb_state_key_get_utf8;
+   xkb_state_key_get_utf32;
+   xkb_state_key_get_one_sym;
+   xkb_state_key_get_layout;
+   xkb_state_key_get_level;
+   xkb_state_serialize_mods;
+   xkb_state_serialize_layout;
+   xkb_state_mod_name_is_active;
+   xkb_state_mod_names_are_active;
+   xkb_state_mod_index_is_active;
+   xkb_state_mod_indices_are_active;
+   xkb_state_mod_index_is_consumed;
+   xkb_state_mod_mask_remove_consumed;
+   xkb_state_key_get_consumed_mods;
+   xkb_state_layout_name_is_active;
+   xkb_state_layout_index_is_active;
+   xkb_state_led_name_is_active;
+   xkb_state_led_index_is_active;
+local:
+   *;
+};
diff --git a/xkbcommon.map b/xkbcommon.map
new file mode 100644
index 000..c1a3240
--- /dev/null
+++ b/xkbcommon.map
@@ -0,0 +1,9 @@
+V_0.4.3 {
+global:
+   xkb_x11_setup_xkb_extension;
+   xkb_x11_get_core_keyboard_device_id;
+   xkb_x11_keymap_new_from_device;
+   xkb_x11_state_new_from_device;
+local:
+   *;
+};
-- 
2.0.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

libinput: build system, symbol versions

[Jan Engelhardt]

The following changes since commit 0647574c46e5e930063ace7b35385213dca33dc1:

  litest-alps-semi-mt: Fix compiler warnings (2014-09-03 13:33:20 +1000)

are available in the git repository at:

  git://git.inai.de/libinput HEAD

for you to fetch changes up to aaa0272d0f2f54b1b6dc9f0596a6ec627540877c:

  build: use symbol versioning (2014-09-10 01:25:05 +0200)


Jan Engelhardt (2):
  build: symbol ck_assert_ptr_ne requires check-0.9.10
  build: use symbol versioning

 configure.ac |  2 +-
 src/Makefile.am  |  3 +-
 src/libinput.map | 87 
 3 files changed, 90 insertions(+), 2 deletions(-)
 create mode 100644 src/libinput.map
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 2/2] build: use symbol versioning

[Jan Engelhardt]

Symbol versions provide a means by which ELF utilities can determine
whether a program is incompatible with a too-old library version so
that package management tools can autodetect version-based
dependencies and suggest upgrade paths.

Signed-off-by: Jan Engelhardt jeng...@inai.de
---
 src/Makefile.am  |  3 +-
 src/libinput.map | 87 
 2 files changed, 89 insertions(+), 1 deletion(-)
 create mode 100644 src/libinput.map

diff --git a/src/Makefile.am b/src/Makefile.am
index 44e73d3..629ce49 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -34,7 +34,8 @@ libinput_la_CFLAGS = -I$(top_srcdir)/include \
 $(LIBEVDEV_CFLAGS) \
 $(GCC_CFLAGS)
 
-libinput_la_LDFLAGS = -version-info $(LIBINPUT_LT_VERSION) -shared
+libinput_la_LDFLAGS = -version-info $(LIBINPUT_LT_VERSION) -shared \
+  -Wl,--version-script=$(srcdir)/libinput.map
 
 pkgconfigdir = $(libdir)/pkgconfig
 pkgconfig_DATA = libinput.pc
diff --git a/src/libinput.map b/src/libinput.map
new file mode 100644
index 000..414dbd2
--- /dev/null
+++ b/src/libinput.map
@@ -0,0 +1,87 @@
+V_0.5.0 {
+global:
+   libinput_event_destroy;
+   libinput_event_get_type;
+   libinput_event_get_context;
+   libinput_event_get_device;
+   libinput_event_get_pointer_event;
+   libinput_event_get_keyboard_event;
+   libinput_event_get_touch_event;
+   libinput_event_get_device_notify_event;
+   libinput_event_device_notify_get_base_event;
+   libinput_event_keyboard_get_time;
+   libinput_event_keyboard_get_key;
+   libinput_event_keyboard_get_key_state;
+   libinput_event_keyboard_get_base_event;
+   libinput_event_keyboard_get_seat_key_count;
+   libinput_event_pointer_get_time;
+   libinput_event_pointer_get_dx;
+   libinput_event_pointer_get_dy;
+   libinput_event_pointer_get_absolute_x;
+   libinput_event_pointer_get_absolute_y;
+   libinput_event_pointer_get_absolute_x_transformed;
+   libinput_event_pointer_get_absolute_y_transformed;
+   libinput_event_pointer_get_button;
+   libinput_event_pointer_get_button_state;
+   libinput_event_pointer_get_seat_button_count;
+   libinput_event_pointer_get_axis;
+   libinput_event_pointer_get_axis_value;
+   libinput_event_pointer_get_base_event;
+   libinput_event_touch_get_time;
+   libinput_event_touch_get_slot;
+   libinput_event_touch_get_seat_slot;
+   libinput_event_touch_get_x;
+   libinput_event_touch_get_y;
+   libinput_event_touch_get_x_transformed;
+   libinput_event_touch_get_y_transformed;
+   libinput_event_touch_get_base_event;
+   libinput_udev_create_context;
+   libinput_udev_assign_seat;
+   libinput_path_create_context;
+   libinput_path_add_device;
+   libinput_path_remove_device;
+   libinput_get_fd;
+   libinput_dispatch;
+   libinput_get_event;
+   libinput_next_event_type;
+   libinput_get_user_data;
+   libinput_resume;
+   libinput_suspend;
+   libinput_ref;
+   libinput_unref;
+   libinput_log_set_priority;
+   libinput_log_get_priority;
+   libinput_log_set_handler;
+   libinput_seat_ref;
+   libinput_seat_unref;
+   libinput_seat_set_user_data;
+   libinput_seat_get_user_data;
+   libinput_seat_get_physical_name;
+   libinput_seat_get_logical_name;
+   libinput_device_ref;
+   libinput_device_unref;
+   libinput_device_set_user_data;
+   libinput_device_get_user_data;
+   libinput_device_get_sysname;
+   libinput_device_get_name;
+   libinput_device_get_id_product;
+   libinput_device_get_id_vendor;
+   libinput_device_get_output_name;
+   libinput_device_get_seat;
+   libinput_device_led_update;
+   libinput_device_get_keys;
+   libinput_device_calibrate;
+   libinput_device_has_capability;
+   libinput_device_get_size;
+   libinput_config_status_to_str;
+   libinput_device_config_tap_get_finger_count;
+   libinput_device_config_tap_set_enabled;
+   libinput_device_config_tap_get_enabled;
+   libinput_device_config_tap_get_default_enabled;
+   libinput_device_config_calibration_has_matrix;
+   libinput_device_config_calibration_set_matrix;
+   libinput_device_config_calibration_get_matrix;
+   libinput_device_config_calibration_get_default_matrix;
+local:
+   *;
+};
-- 
2.0.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/2] build: use symbol versioning

[Jan Engelhardt]

On Thursday 2014-09-11 23:28, Peter Hutterer wrote:
 
 This sounds like a good idea. I have not pushed it yet though because
 I'd want to avoid adding the symbols that will be deprecated in the
 coming release (libinput_device_get_keys and libinput_device_calibrate).

can we run the symbols through sort please? Makes it a lot easier to find
them when they're sorted alphabetically.

I sorted them by the order they appeared in the .h file.
Perhaps that means the .h file should be sorted too?

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH 2/2] build: use symbol versioning

[Jan Engelhardt]

On Thursday 2014-09-11 22:55, Jonas Ådahl wrote:

On Wed, Sep 10, 2014 at 01:32:25AM +0200, Jan Engelhardt wrote:
 Symbol versions provide a means by which ELF utilities can determine
 whether a program is incompatible with a too-old library version so
 that package management tools can autodetect version-based
 dependencies and suggest upgrade paths.

This sounds like a good idea. I have not pushed it yet though because
I'd want to avoid adding the symbols that will be deprecated in the
coming release (libinput_device_get_keys and libinput_device_calibrate).

That's not a big deal. If you remove symbols from the .c files,
just increase -version-info to N:0:0, remove the symbols from
libinput.map, and combine all {} sections in libinput.map
to a single one.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] build: symbol ck_assert_ptr_ne requires check-0.9.10

[Jan Engelhardt]

openSUSE 12.3 ships with check-0.9.9 and subsequently fails to build
the tests. Change the call to look for check = 0.9.10 where that
symbol is available.
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index bb702c0..b3d2446 100644
--- a/configure.ac
+++ b/configure.ac
@@ -96,7 +96,7 @@ AC_ARG_ENABLE(tests,
  [build_tests=$enableval],
  [build_tests=auto])
 
-PKG_CHECK_MODULES(CHECK, [check = 0.9.9], [HAVE_CHECK=yes], 
[HAVE_CHECK=no])
+PKG_CHECK_MODULES(CHECK, [check = 0.9.10], [HAVE_CHECK=yes], 
[HAVE_CHECK=no])
 
 if test x$build_tests = xauto; then
build_tests=$HAVE_CHECK
-- 
2.0.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Wayland and Weston 1.0.3 releases out

[Jan Engelhardt]

On Wednesday 2012-12-19 08:27, Pekka Paalanen wrote:
 make[3]: Entering directory `/home/abuild/rpmbuild/BUILD/weston-1.0.3/tests'
 FAIL: surface-test.la [..].
 ==
 6 of 6 tests failed

could we see the logs from the tests? I mean the files that go into
$abs_topbuilddir/tests/logs.

Ah, there they are - that already resolves my case. Of course you can
see them. In various stages,

---8---
# button-test-serverlog.txt
Date: 2012-12-19 UTC
[08:02:10.967] weston 1.0.3
   http://wayland.freedesktop.org/
   Bug reports to:
 https://bugs.freedesktop.org/enter_bug.cgi?product=weston
   Build:  
[08:02:10.968] OS: Linux, 3.4.18-jng6-default, #1 SMP Wed Nov 14 17:04:47 UTC
 2012 (21e90c1), x86_64
[08:02:10.968] fatal: environment variable XDG_RUNTIME_DIR is not set.
Refer to your distribution on how to get it, or
http://www.freedesktop.org/wiki/Specifications/basedir-spec
on how to implement it.
---8---

Solution: creating a dummy XDG_RUNTIME_DIR. (Invocation is
`mkdir -m go-rwx xdg; XDG_RUNTIME_DIR=$PWD/xdg make check`.
Next,

---8---
# button-test-log.txt
couldn't open /home/abuild/.config/weston.ini
couldn't open /home/abuild/.config/weston.ini
Error:failed to add default include path /usr/share/X11/xkb
---8---

Solution: install xkeyboard-config (this was inside a trimmed chroot
for distro package building). It seems to forgive me on the missing
weston.ini. Next,

---8---
# button-test-serverlog.txt
Date: 2012-12-19 UTC
[08:11:03.940] weston 1.0.3
   http://wayland.freedesktop.org/
   Bug reports to:
 https://bugs.freedesktop.org/enter_bug.cgi?product=weston
   Build:  
[08:11:03.940] OS: Linux, 3.4.18-jng6-default, #1 SMP Wed Nov 14 17:04:47 UTC
 2012 (21e90c1), x86_64
[08:11:03.941] Loading module
 
'/home/abuild/rpmbuild/BUILD/weston-1.0.3/tests/../src/.libs/wayland-backend.so'
[08:11:03.943] failed to create display: No such file or directory
[08:11:03.943] fatal: failed to create compositor
---8---

When run without make, the command line output is

---8---
~/rpmbuild/BUILD/weston-1.0.3/tests XDG_RUNTIME_DIR=$PWD/xdg \
./button-test 
button-test: weston-test-client-helper.c:463: client_create: Assertion
`client-wl_display' failed.
test simple_button_test:  signal 6, fail.
1 tests, 0 pass, 1 fail
---8---

Would be a good idea to print the file/directory name involved -
I assume it tries to create/connect to a socket (similar to
that of /tmp/.X11-unix/X0). strace eventually tells me.

---8---
# XDG_RUNTIME_DIR=$PWD/xdg strace ./button-test
[...]
[pid 17011] connect(3, {sa_family=AF_FILE,
sun_path=/home/abuild/rpmbuild/BUILD/weston-1.0.3/tests/xdg/wayland-0}, 63) =
-1 ENOENT (No such file or directory)
---8---

So, who is to be starting the Wayland instance? I think, the
testsuite should do that, since it cannot rely on any preexisting
wayland running, nor should it toy around with any (preexisting)
process that might be used productively.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Wayland and Weston 1.0.3 releases out

[Jan Engelhardt]

On Friday 2012-12-14 23:20, Kristian Høgsberg wrote:

f71a3fb5b6534cce35ac7456a5fd540fc3806fc1  wayland-1.0.3.tar.xz
ce1f41251a07600ed8c6b2e3dc1e868008aeb33a  wayland 1.0.3 tag

583589cf7dd8f3300eef2bfb7b1968875a155e2a  weston-1.0.3.tar.xz
b61f7d27738b73d27b03b8982b37ec78df52976e  weston 1.0.3 tag

Other than that, there's really nothing groundbreaking in this
release.  The test suite rewrite and fixes make up the bulk of the
weston changes along with a fistful of Coverity fixes from Rob.

The testsuite however fails in a spectacular way.

make[3]: Entering directory `/home/abuild/rpmbuild/BUILD/weston-1.0.3/tests'
FAIL: surface-test.la
FAIL: surface-global-test.la
FAIL: keyboard-test
FAIL: event-test
FAIL: button-test
FAIL: text-test
==
6 of 6 tests failed
Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=weston
==

In wayland, I already had to set some variable for make check to work
through all.
XDG_RUNTIME_DIR=/tmp make check
Is there something special needed for weston as well?




Full log:

+ exec rpmbuild -ba --define '_srcdefattr (-,root,root)' --nosignature --define 
'_build_create_debug 1' /home/abuild/rpmbuild/SOURCES/weston.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.0OSZZe
+ umask 022
+ cd /home/abuild/rpmbuild/BUILD
+ cd /home/abuild/rpmbuild/BUILD
+ rm -rf weston-1.0.3
+ /usr/bin/xz -dc /home/abuild/rpmbuild/SOURCES/weston-1.0.3.tar.xz
+ /bin/tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd weston-1.0.3
+ /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.5Z6aR7
+ umask 022
+ cd /home/abuild/rpmbuild/BUILD
+ /usr/bin/rm -rf /home/abuild/rpmbuild/BUILDROOT/weston-1.0.3-0.x86_64
++ dirname /home/abuild/rpmbuild/BUILDROOT/weston-1.0.3-0.x86_64
+ /usr/bin/mkdir -p /home/abuild/rpmbuild/BUILDROOT
+ /usr/bin/mkdir /home/abuild/rpmbuild/BUILDROOT/weston-1.0.3-0.x86_64
+ cd weston-1.0.3
+ '[' '!' -e configure ']'
+ CFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector 
-funwind-tables -fasynchronous-unwind-tables -g'
+ export CFLAGS
+ CXXFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector 
-funwind-tables -fasynchronous-unwind-tables -g'
+ export CXXFLAGS
+ FFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector 
-funwind-tables -fasynchronous-unwind-tables -g'
+ export FFLAGS
+ ./configure --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu 
--program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin 
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share 
--includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib 
--localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man 
--infodir=/usr/share/info --disable-dependency-tracking --disable-static 
--disable-setuid-install
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for x86_64-suse-linux-gnu-gcc... no
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking for x86_64-suse-linux-gnu-g++... no
checking for x86_64-suse-linux-gnu-c++... no
checking for x86_64-suse-linux-gnu-gpp... no
checking for x86_64-suse-linux-gnu-aCC... no
checking for x86_64-suse-linux-gnu-CC... no
checking for x86_64-suse-linux-gnu-cxx... no
checking for x86_64-suse-linux-gnu-cc++... no
checking for x86_64-suse-linux-gnu-cl.exe... no
checking for x86_64-suse-linux-gnu-FCC... no
checking for x86_64-suse-linux-gnu-KCC... no
checking for x86_64-suse-linux-gnu-RCC... no
checking for x86_64-suse-linux-gnu-xlC_r... no
checking for x86_64-suse-linux-gnu-xlC... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... none
checking for a sed that does not truncate output... /usr/bin/sed
checking build system type... x86_64-suse-linux-gnu
checking host system type... x86_64-suse-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... (cached) /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by 

Re: Wayland and Weston 1.0

[Jan Engelhardt]

On Wednesday 2012-10-24 13:51, Pekka Paalanen wrote:

A few folks around me, and myself included, have pondered...
 
It would seem that wayland and its possible compositors all require
3D support, which may require, if no accelerating GPU is installed,
the use of software rendering when doing purely 2D workloads,
such as libreoffice - xterms - and simple web page browsing,[...]

what issues do you have in mind, exactly? That Wayland is not at all
usable without a performant GPU (software GL considered too slow or
power-hungry)?

That Wayland may be slower than what we have today, especially in
cases with sufficiently dumb framebuffers.
For example, within an Xvnc session, `mplayer -vo gl` takes up so
much more CPU time than `mplayer -vo x11`. Clearly that is due to
software GL rendering, got no problem with that. But I can switch to
-vo x11 if I want. With Wayland/Weston, I do not see any such
disable GL command line option. The pixman renderer may resolve
that worry..

A Pixman-based software renderer for Weston has been talked about in
passing several times, that it would be good to have. No-one just got
around to it yet, AFAIK. It could also allow to run Weston on legacy
(dumb) framebuffers. The GLESv2 renderer has been somewhat separated
from the compositor core, but is not a clean cut yet.

If we start waving our hands very hard, I could foresee dynamic
switching between software and hardware based renderers, on-demand,
coupled with multi-GPU-support. Though if any client uses EGL,
I don't know how you could switch to a software renderer in the server.

Dynamic switching is not that much required (for me, at least).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Add version info to the shared libs

[Jan Engelhardt]

On Friday 2012-11-09 18:54, Mikko Levonmaa wrote:

Right, so if the first api version is 0 then it make sense, sort of, 
matter of preference I guess. So, the original patch was wrong, however 
the new suggestion was actually geared towards the future  and the next 
release(s), so if I'm not mistaken that needs to be done through the 
-version-info and for the time being the api version would be defined 
to 0.

The next API begins when symbols are added or ABIs modified; so if 
wayland 1.1 and 1.2 and 2.0 (serving as examples) all add symbols, 2.0 
would have API 3.
So, emphasizing again, package number often does not relate to the API 
number.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] Add version info to the shared libs

[Jan Engelhardt]

On Tuesday 2012-11-20 20:59, Mikko Levonmaa wrote:

What I was actually trying to propose in my previous mail is that
even when the current api version is 0 we could already have the
mechanics in place to increment the api version when the time comes,
or is that automatically handled?

It is not automatically handled. One could probably craft some
code, but it's usually not worth the time. Manual updating is
sufficient for most people.

If it is not, then we need to set
the version info (current, revision and age) eventually. So the
patch would be like

 -version-info @WAYLAND_API_CUR@:@WAYLAND_API_REV@:@WAYLAND_API_AGE@

I don't quite see the use of the @API_CUR@ indirection.
Just put -version-info 1:0:0 when the time comes.

The rational on my side for the original, albeit flawed suggestion,
was that libtools docs suggest to update the version information
only immediately before a public release.

That rule does not apply to the very first public release as there is no 
prior release.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: 1.0 Branch created

[Jan Engelhardt]

On Friday 2012-11-09 17:16, Thiago Macieira wrote:
On sexta-feira, 9 de novembro de 2012 10.37.06, Kristian Høgsberg wrote:
 I've created 1.0 branches in the wayland and weston repos.  I found it
 confusing the use the 'master' and 'next' terminology when replying to
 patch emails and being able to just say 'commited to 1.0' is a lot
 clearer than saying 'committed to master' and then wonder whether
 'master' is the feature branch or the stable branch.

Well, why not call the stable branch stable and have master be, well,
the new stuff?!

You can always set the default branch to download in
/srv/git/wayland/HEAD (assuming said location).

Some projects prefer the master branch be the default check-out and contain 
the latest version that regular people should use. The question is then what 
is regular.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] Use a library symbol version map

[Jan Engelhardt]

This helps package managers recognize when a new version of libxkbcommon
(with same SONAME) is required due to new symbols.

Signed-off-by: Jan Engelhardt jeng...@inai.de
---
 Makefile.am  |4 +++-
 libxkbcommon.map |   66 ++
 2 files changed, 69 insertions(+), 1 deletion(-)
 create mode 100644 libxkbcommon.map

diff --git a/Makefile.am b/Makefile.am
index c08bca1..a50422b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -35,7 +35,9 @@ xkbcommoninclude_HEADERS = \
xkbcommon/xkbcommon-names.h
 
 lib_LTLIBRARIES = libxkbcommon.la
-libxkbcommon_la_LDFLAGS = -no-undefined
+libxkbcommon_la_LDFLAGS = \
+   -Wl,--version-script=${srcdir}/libxkbcommon.map \
+   -no-undefined
 libxkbcommon_la_SOURCES = \
src/xkbcomp/action.c \
src/xkbcomp/action.h \
diff --git a/libxkbcommon.map b/libxkbcommon.map
new file mode 100644
index 000..822d985
--- /dev/null
+++ b/libxkbcommon.map
@@ -0,0 +1,66 @@
+XKBCOMMON_0.2.0 {
+global:
+   xkb_keysym_get_name;
+   xkb_keysym_from_name;
+   xkb_keysym_to_utf8;
+   xkb_keysym_to_utf32;
+   xkb_context_new;
+   xkb_context_ref;
+   xkb_context_unref;
+   xkb_context_set_user_data;
+   xkb_context_get_user_data;
+   xkb_context_include_path_append;
+   xkb_context_include_path_append_default;
+   xkb_context_include_path_reset_defaults;
+   xkb_context_include_path_clear;
+   xkb_context_num_include_paths;
+   xkb_context_include_path_get;
+   xkb_context_set_log_level;
+   xkb_context_get_log_level;
+   xkb_context_set_log_verbosity;
+   xkb_context_get_log_verbosity;
+   xkb_context_set_log_fn;
+   xkb_keymap_new_from_names;
+   xkb_keymap_new_from_file;
+   xkb_keymap_new_from_string;
+   xkb_keymap_ref;
+   xkb_keymap_unref;
+   xkb_keymap_get_as_string;
+   xkb_keymap_num_mods;
+   xkb_keymap_mod_get_name;
+   xkb_keymap_mod_get_index;
+   xkb_keymap_num_layouts;
+   xkb_keymap_layout_get_name;
+   xkb_keymap_layout_get_index;
+   xkb_keymap_num_layouts_for_key;
+   xkb_keymap_num_levels_for_key;
+   xkb_keymap_key_get_syms_by_level;
+   xkb_keymap_num_leds;
+   xkb_keymap_led_get_name;
+   xkb_keymap_led_get_index;
+   xkb_keymap_key_repeats;
+   xkb_state_new;
+   xkb_state_ref;
+   xkb_state_unref;
+   xkb_state_get_keymap;
+   xkb_state_update_key;
+   xkb_state_key_get_syms;
+   xkb_state_key_get_one_sym;
+   xkb_state_key_get_layout;
+   xkb_state_key_get_level;
+   xkb_state_update_mask;
+   xkb_state_serialize_mods;
+   xkb_state_serialize_layout;
+   xkb_state_mod_name_is_active;
+   xkb_state_mod_names_are_active;
+   xkb_state_mod_index_is_active;
+   xkb_state_mod_indices_are_active;
+   xkb_state_mod_index_is_consumed;
+   xkb_state_mod_mask_remove_consumed;
+   xkb_state_layout_name_is_active;
+   xkb_state_layout_index_is_active;
+   xkb_state_led_name_is_active;
+   xkb_state_led_index_is_active;
+local:
+   *;
+};
-- 
1.7.10.4

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel