xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

regid · 2018-05-20 14:18:45

xorg-server 1.20.0-2
xorg-server-common 1.20.0-2
libinput 1.10.7-1
xf86-video-vesa 2.4.0-2

are not working.
Xorg.log is at http://pb.net9.ml. The interesting lines might be

[    35.987] (II) VESA(0): initializing int10
[    35.988] (EE) VESA(0): Cannot read int vect

My solution was to downgrade to the previous versions I have, namely

xorg-server 1.19.6+13+gd0d1a694f-2
xorg-server-common 1.19.6+13+gd0d1a694f-2
libinput 1.10.6-1
xf86-video-vesa 2.4.0-1

As an aside, note that Xorg.log doesn't starts at its beginning. I mean, as if the usual initial lines, version, release date and so on, were not written by the xserver.

Last edited by regid (2018-05-21 15:10:12)

loqs · 2018-05-20 16:35:55

https://cgit.freedesktop.org/xorg/xserv … ric.c#n161
The code has not changed recently can you try rebuilding xorg-server with autotools/make instead of meson/ninja see if the build switch system caused the issue.

regid · 2018-05-20 18:23:34

loqs wrote:

https://cgit.freedesktop.org/xorg/xserv … ric.c#n161
The code has not changed recently can you try rebuilding xorg-server with autotools/make instead of meson/ninja see if the build switch system caused the issue.

I am sorry. I can't do that in a timely manner. I have much more urgent, long term liabilities I must attend to before that. And I am a total newbie when it comes to building even moderatly complicated packages. I can hardly build simple packages. For example, am I right you are also refering to https://git.archlinux.org/svntogit/pack … org-server? I can see the meson/ninja related lines there. How would I convert it to autotools/make? Will I need to follow the same procedure for xorg-server-common, xf86-video-vesa and libinput? And did you mention https://cgit.freedesktop.org/xorg/xserv … ric.c#n161 just for reference, or should I do something specific with that file?
The most I can do is install packages someone else will build.

Last edited by regid (2018-05-20 18:24:07)

loqs · 2018-05-20 18:42:11

The following should generate 1.20 xorg packages using autotools/make

git clone git://git.archlinux.org/svntogit/packages.git --single-branch --branch "packages/xorg-server"
cd packages/trunk/
git checkout 42bf42476cf05ea49c54ddb5d5ba62179e68b45d
makepkg -rs
# pacman -U xorg-server-1.20.0-1-x86_64.pkg.tar.xz xorg-server-common-1.20.0-1-x86_64.pkg.tar.xz # update libinput 1.10.6-1 , xf86-video-vesa 2.4.0-1 in the same transaction

If it fails just downgrade the packages as you previously did.

regid · 2018-05-20 22:43:12

loqs wrote:

The following should generate 1.20 xorg packages using autotools/make

git clone git://git.archlinux.org/svntogit/packages.git --single-branch --branch "packages/xorg-server"
cd packages/trunk/
git checkout 42bf42476cf05ea49c54ddb5d5ba62179e68b45d
makepkg -rs
# pacman -U xorg-server-1.20.0-1-x86_64.pkg.tar.xz xorg-server-common-1.20.0-1-x86_64.pkg.tar.xz # update libinput 1.10.6-1 , xf86-video-vesa 2.4.0-1 in the same transaction

If it fails just downgrade the packages as you previously did.

Building and installing, as suggested, work.

xorg-server 1.20.0-1
xorg-server-common 1.20.0-1
libinput 1.10.7-1
xf86-video-vesa 2.4.0-2

are working for me.
Xorg.0.log also seems complete.
Thank you.

But am I right that -2 is different than -1 in more ways than just the build process? Doesn't -2, while cooperating with xf86-video-vesa, attempt to write Xorg.0.log to ~/.local/share/xorg/, while -1 writes it to /var/log/? Or I could be right about the Xorg.0.log location, and wrong assuming this is not tied to the build process?

Last edited by regid (2018-05-20 23:42:54)

V1del · 2018-05-21 09:30:44

Whether the log is written to .local/share/xorg or /var/log depends on whether the xorg server was started with as a normal user or as root, this has no relation to the package version.

loqs · 2018-05-21 11:37:47

possibly https://bugs.archlinux.org/task/58644

regid · 2018-05-21 14:50:19

V1del wrote:

Whether the log is written to .local/share/xorg or /var/log/ depends on whether the xorg server was started with as a normal user or as root, this has no relation to the package version.

I am starting X (xinit) with user privileges. The log for 1.20.0-1 is at /var/log, where they were always been. The log for 1.20.0-2 is at ~/.local/share/xorg/. I can't find the reference right now, but I saw somewhere the VESA driver is one of the last few drivers that can not be run as a normal user. This statement might be inaccurate, but it might suggest that requirments for the VESA driver are more severe than for most other drivers. See also https://wiki.archlinux.org/index.php/Ta … Xorg.0.log, though I am not sure how those commenters run their xserver.

loqs wrote:

possibly https://bugs.archlinux.org/task/58644

I have a hunch that this bug is strongly related to my issue with the VESA driver. I tried to follow the comments, and got lost. If I will have a clear recipe to try building a modified 1.20.0-2 package, in the lines of your recipe for 1.20.0-1, I will try doing that.

Last edited by regid (2018-05-21 15:12:57)

loqs · 2018-05-21 16:57:14

git clone git://git.archlinux.org/svntogit/packages.git --single-branch --branch "packages/xorg-server"
cd packages/trunk/
git checkout cfcb2eb409d44339eb0054e35eb1f03e0fb0cefb
curl -o 0001-v2-FS-58644.patch https://bugs.archlinux.org/task/58644?getfile=16395
curl -o PKGBUILD https://bugs.archlinux.org/task/58644?getfile=16396
makepkg -rs

This should build 1.20.0-2.1 using the fixes from the bug report.
Edit:
patch has been applied in 1.20.0-4 packages currently in testing.

Last edited by loqs (2018-05-21 18:17:00)

regid · 2018-05-22 01:03:12

loqs wrote:

git clone git://git.archlinux.org/svntogit/packages.git --single-branch --branch "packages/xorg-server"
cd packages/trunk/
git checkout cfcb2eb409d44339eb0054e35eb1f03e0fb0cefb
curl -o 0001-v2-FS-58644.patch https://bugs.archlinux.org/task/58644?getfile=16395
curl -o PKGBUILD https://bugs.archlinux.org/task/58644?getfile=16396
makepkg -rs

This should build 1.20.0-2.1 using the fixes from the bug report.
Edit:
patch has been applied in 1.20.0-4 packages currently in testing.

It doesn't work for me. Qouting /var/log/Xorg.0.log:

[ 61511.008] (WW) Failed to open protocol names file lib/xorg/protocol.txt
[ 61511.032] 
X.Org X Server 1.20.0
X Protocol Version 11, Revision 0
[ 61511.032] Build Operating System: Linux Arch Linux

   ...

[ 61511.474] (**) VESA(0): Using "Shadow Framebuffer"
[ 61511.474] (II) Loading sub module "shadow"
[ 61511.474] (II) LoadModule: "shadow"
[ 61511.474] (II) Loading /usr/lib/xorg/modules/libshadow.so
[ 61511.484] (EE) Failed to load /usr/lib/xorg/modules/libshado
w.so: libfb.so: cannot open shared object file: No such file or
 directory
[ 61511.484] (EE) VESA: Failed to load module "shadow" (loader failed, 0)
[ 61511.484] (II) UnloadModule: "vesa"
[ 61511.484] (II) UnloadSubModule: "int10"
[ 61511.484] (II) Unloading int10
[ 61511.485] (II) UnloadSubModule: "vbe"
[ 61511.485] (II) Unloading vbe
[ 61511.485] (EE) Screen(s) found, but none have a usable configuration.
[ 61511.485] (EE) 
Fatal server error:
[ 61511.485] (EE) no screens found(EE) 
[ 61511.485] (EE) 
Please consult the The X.Org Foundation support 
         at http://wiki.x.org
 for help. 
[ 61511.485] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[ 61511.485] (EE) 
[ 61511.486] (EE) Server terminated with error (1). Closing log file.

As an aside, why are you using

cd packages/trunk/
git checkout cfcb2eb409d44339eb0054e35eb1f03e0fb0cefb

Which gives a detached HEAD, instead of, for example,

git checkout -b 1.2.0-2.1 cfcb2eb409d44339eb0054e35eb1f03e0fb0cefb
cd packages/trunk/

?

Last edited by regid (2018-05-22 11:05:32)

loqs · 2018-05-22 11:37:32

So some other difference between the meson/ninja build and the autotools/make build. I did not create a branch because nothing required referencing it in the instructions supplied.
You could create a bug report here or upstream for the issue.

Lone_Wolf · 2018-05-22 14:07:09

I do have a feeling something else may be going on here.

regid, please post output of

pacman -Qo /usr/lib/xorg/protocol.txt /usr/lib/xorg/modules/libfb.so

loqs · 2018-05-22 16:04:52

Also stat /usr/lib/xorg/modules/libshadow.so please
Edit:
See also the Xorg.log from https://bbs.archlinux.org/viewtopic.php?id=237309 which was run as root and has similarities.

Last edited by loqs (2018-05-22 16:12:52)

regid · 2018-05-22 23:00:09

@Lone_Wolf:

% pacman -Qo /usr/lib/xorg/protocol.txt /usr/lib/xorg/modules/libfb.so 
/usr/lib/xorg/protocol.txt is owned by xorg-server-common 1.20.0-4
/usr/lib/xorg/modules/libfb.so is owned by xorg-server 1.20.0-4

@loqs:

% stat /usr/lib/xorg/modules/libshadow.so
  File: /usr/lib/xorg/modules/libshadow.so
  Size: 34904     	Blocks: 72         IO Block: 4096   regular file
Device: fe01h/65025d	Inode: 668439      Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2018-05-22 22:48:05.000000000 +0000
Modify: 2018-05-21 17:41:00.000000000 +0000
Change: 2018-05-22 22:48:05.875269085 +0000
 Birth: -

% curl -s 'https://bbs.archlinux.org/viewtopic.php?id=237309' | grep Bad
			<p>Bad request. The link you followed is incorrect or outdated.</p>

Is there a need for building 1.20.0-4 with autotools/make, which I am not sure if, and when, I can do that?

Last edited by regid (2018-05-22 23:11:04)

loqs · 2018-05-22 23:58:55

@regid Only if the 1.20.0-4 built packages that use meson/ninja still have the issue.
The link is correct it just requires you to be logged in as the post was moved to the Dustbin which is hidden from none logged in viewing.

regid · 2018-05-23 08:48:52

loqs wrote:

@regid Only if the 1.20.0-4 built packages that use meson/ninja still have the issue.
The link is correct it just requires you to be logged in as the post was moved to the Dustbin which is hidden from none logged in viewing.

I think the thread in Dustbin is mostly about running the xserver as root within a VM, which is not my case. I didn't understand most of it.
The 1.20.0-4 built packages from testing that use meson/ninja don't work for me. I want to build the packages with autotools/make. Looking at https://git.archlinux.org/svntogit/pack … org-server, will the following supposed to work?

git clone git://git.archlinux.org/svntogit/packages.git --single-branch --branch "packages/xorg-server"
cd packages/trunk/

Am I right that this gives me 1.20.0-4 from testing?

git checkout -b 1.20.0-4autoToolsMake 42bf42476cf05ea49c54ddb5d5ba62179e68b45d # @loqs PKGBUILD for -1 with autotools/make
sed -i '/pkgrel/s/1/4AutoToolsMake/' PKGBUILD
# Merging -4 and -1 PKGBUILDs.

How to convert 0001-v2-FS-58644.patch to autotools/make? It is a meson/ninja related patch.
```
LC_ALL=C makepkg -rs
```

Last edited by regid (2018-05-23 10:11:57)

loqs · 2018-05-23 10:19:36

I would suggest an alternative approach use the instructions from post #4 as a base.
From https://git.archlinux.org/svntogit/pack … 3e0fb0cefb not sure if this is applies to autotools/make as well possibly remove --with-fontrootdir=/usr/share/fonts \
From https://git.archlinux.org/svntogit/pack … 837b7f9fe7 add 'egl-wayland' to make_depends and --enable-xwayland_eglstream to configure
From https://git.archlinux.org/svntogit/pack … a1b9991b12 change pkgrel=4 the rest is meson specific.

seth · 2018-05-23 14:37:55

It would seem that libshadow.so now links libfb.so (affects the repo package, but was not the case on 1.19) but /usr/lib/xorg/modules/ (or ".") is not in the library path, so the resolution fails.
Can you please paste the entire Xorg log?
You might also just briefly symlink libfb.so into /usr/lib and see what happens.

regid · 2018-05-23 19:00:59

loqs wrote:

I would suggest an alternative approach use the instructions from post #4 as a base.
From https://git.archlinux.org/svntogit/pack … 3e0fb0cefb not sure if this is applies to autotools/make as well possibly remove --with-fontrootdir=/usr/share/fonts \
From https://git.archlinux.org/svntogit/pack … 837b7f9fe7 add 'egl-wayland' to make_depends and --enable-xwayland_eglstream to configure
From https://git.archlinux.org/svntogit/pack … a1b9991b12 change pkgrel=4 the rest is meson specific.

Am I right that your suggestion is basically equivalent to:

% git clone git://git.archlinux.org/svntogit/packages.git --single-branch --branch "packages/xorg-server"
% cd packages/trunk/
% git checkout -b 1.20.0-1AutotoolsMake 42bf42476cf05ea49c54ddb5d5ba62179e68b45d 
% git checkout packages/xorg-server
% git merge 1.20.0-1AutotoolsMake
% git checkout -b 1.20.0-2 cfcb2eb409d44339eb0054e35eb1f03e0fb0cefb
% git checkout packages/xorg-server
% git merge 1.20.0-2
% git checkout -b 1.20.0-3 ea884016f08dd8b7d25f4045c22646837b7f9fe7
% git checkout packages/xorg-server
% git merge 1.20.0-3
% LC_ALL=C makepkg -rs

?
If so, why am I getting the following:

% git clone git://git.archlinux.org/svntogit/packages.git --single-branch --branch "packages/xorg-server"
% cd packages/trunk/
% git checkout -b 1.20.0-1AutotoolsMake 42bf42476cf05ea49c54ddb5d5ba62179e68b45d 
% git checkout packages/xorg-server
% git merge 1.20.0-1AutotoolsMake
Already up to date.

?

edit: It might be that it is `Already up to date' because HEAD is a decendents of 42bf42476cf05ea49c54ddb5d5ba62179e68b45d. Or, depending in what direction the chain is looked up, HEAD might be an ancestor of 42bf42476cf05ea49c54ddb5d5ba62179e68b45d. Is it usually refered as a decendents or an ancsestor? I am confused of the all thing. I guess my confusion is due to a misunderstanding of the exact action of git merge. In any case, loqs suggestion was not what I wrote above.

Last edited by regid (2018-05-24 00:14:49)

regid · 2018-05-23 19:22:29

seth wrote:

It would seem that libshadow.so now links libfb.so (affects the repo package, but was not the case on 1.19) but /usr/lib/xorg/modules/ (or ".") is not in the library path, so the resolution fails.
Can you please paste the entire Xorg log?
You might also just briefly symlink libfb.so into /usr/lib and see what happens.

Can you be more specific about the versions you are reffering to? I am currently running 1.20.0-1BuiltLocallyWithAutotools/Make because 1.20.0-4 from testing doesn't work. And temporarily installing 1.20.0-4 from testing to answer questions.

% pacman -Qi xorg-server | grep Version
Version         : 1.20.0-1BuiltLocallyWithAutotools/Make
% pacman -Ql xorg-server | grep fb
xorg-server /usr/lib/xorg/modules/libfb.so
xorg-server /usr/lib/xorg/modules/libfbdevhw.so
xorg-server /usr/lib/xorg/modules/libshadowfb.so
xorg-server /usr/lib/xorg/modules/libwfb.so
xorg-server /usr/share/man/man4/fbdevhw.4.gz
% pacman -Ql xorg-server | grep shadow
xorg-server /usr/lib/xorg/modules/libshadow.so
xorg-server /usr/lib/xorg/modules/libshadowfb.so
# pacman -U xorg-server-1.20.0-4-x86_64.pkg.tar.xz xorg-server-common-1.20.0-4-x86_64.pkg.tar.xz
% pacman -Ql xorg-server | grep fb     
xorg-server /usr/lib/xorg/modules/libfb.so
xorg-server /usr/lib/xorg/modules/libfbdevhw.so
xorg-server /usr/lib/xorg/modules/libshadowfb.so
xorg-server /usr/lib/xorg/modules/libwfb.so
xorg-server /usr/share/man/man4/fbdevhw.4.gz
% pacman -Ql xorg-server | grep shadow 
xorg-server /usr/lib/xorg/modules/libshadow.so
xorg-server /usr/lib/xorg/modules/libshadowfb.so

If the output above has illegal characters, or too long names, or some other obscurities, that is because I edited it for clarity.

Last edited by regid (2018-05-23 19:38:28)

seth · 2018-05-23 19:32:50

I'm talking about https://www.archlinux.org/packages/extr … rg-server/ version 1.20.0-2
Whether the same condition applies to your current installation can be checked

ldd /usr/lib/xorg/modules/libshadow.so

The critical message for my assumption was

[ 61511.474] (**) VESA(0): Using "Shadow Framebuffer"
[ 61511.474] (II) Loading sub module "shadow"
[ 61511.474] (II) LoadModule: "shadow"
[ 61511.474] (II) Loading /usr/lib/xorg/modules/libshadow.so
[ 61511.484] (EE) Failed to load /usr/lib/xorg/modules/libshadow.so: libfb.so: cannot open shared object file: No such file or  directory
[ 61511.484] (EE) VESA: Failed to load module "shadow" (loader failed, 0)
[ 61511.484] (II) UnloadModule: "vesa"

from your comment #10

regid · 2018-05-23 19:58:06

seth wrote:

I'm talking about https://www.archlinux.org/packages/extr … rg-server/ version 1.20.0-2
Whether the same condition applies to your current installation can be checked
ldd /usr/lib/xorg/modules/libshadow.so
The critical message for my assumption was
[ 61511.474] (**) VESA(0): Using "Shadow Framebuffer"
[ 61511.474] (II) Loading sub module "shadow"
[ 61511.474] (II) LoadModule: "shadow"
[ 61511.474] (II) Loading /usr/lib/xorg/modules/libshadow.so
[ 61511.484] (EE) Failed to load /usr/lib/xorg/modules/libshadow.so: libfb.so: cannot open shared object file: No such file or  directory
[ 61511.484] (EE) VESA: Failed to load module "shadow" (loader failed, 0)
[ 61511.484] (II) UnloadModule: "vesa"
from your comment #10

For some reason I can not see the numbering of the comments. Can you refer to the time and date of each comment, rather than its number?

edit: OK. I understand why I can not see the number of each comment, and found my comment #10. Here it is. It could be that I was building something locally. I don't remember the details. If you will tell me what exactly would you like me to do, I'll try doing that.
end of edit.

As far as I remember, not founding shadow was when I tried running 1.20.0-4 from testing. If I remember correctly, with 1.20.0-2 it failed earler, with

[    35.987] (II) VESA(0): initializing int10
[    35.988] (EE) VESA(0): Cannot read int vect

, and also had

[    35.650] (WW) Failed to open protocol names file lib/xorg/protocol.txt

Now I can install 1.20.0-2 from the repository again. Suppose I will do that. Would you like me to run only the exact ldd command you mentioned? It is not clear to me what exact conditions you are referring to.

Last edited by regid (2018-05-23 20:15:17)

seth · 2018-05-23 20:03:08

This comment, https://bbs.archlinux.org/viewtopic.php … 4#p1786824
The id should be on the top right corner.

For clarification: does *any* 1.20 build work for you atm?
The ldd test is mostly relevant to compare a working w/ a failing build. Otherwise just try to symlink the library. (At least the xorg log should change and maybe get us to another issue - at best, that's it)

Just to be sure: you're intentionally running the VESA driver?

regid · 2018-05-23 20:56:47

seth wrote:

This comment, https://bbs.archlinux.org/viewtopic.php … 4#p1786824
The id should be on the top right corner.
For clarification: does *any* 1.20 build work for you atm?
The ldd test is mostly relevant to compare a working w/ a failing build. Otherwise just try to symlink the library. (At least the xorg log should change and maybe get us to another issue - at best, that's it)
Just to be sure: you're intentionally running the VESA driver?

I found comment #10 by myself, and understood why I am failing to see the comments number.

The only 1.20 version that works for me is 1.20.0-1LocallyBuiltWithAutotools/Make. I didn't try to find an official build of it, but followed loqs advise at comment #4 to build it locally with autotools/make. 1.20.0-2 from extra, and 1.20.0-4 from testing, don't work. Each with a different error EE. And it could be that I also tried to build one of them locally, with the published meson/ninja.
With 1.20.0-1LocallyBuiltWithAutotools/Make, I get

% ldd /usr/lib/xorg/modules/libshadow.so
	linux-vdso.so.1 (0x00007ffc65946000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007efc0d10a000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007efc0ceec000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007efc0cb30000)
	/usr/lib64/ld-linux-x86-64.so.2 (0x00007efc0d6a8000)

Would you like me to install some other version and run that ldd command again? If so, can I just pacman -U that other version and run the ldd command, or should I stop X version 1.20.0-1LocallyBuiltWithAutotools/Make, and perhaps reboot, before doing so? If I stop X version 1.20.0-1LocallyBuiltWithAutotools/Make, should I run the ldd command only after that other X version failed to run, or can I run the ldd without running that other X version at all?
Can you post the exact ln command to link the files you would like me to link, and explicitly write with which X version installed (1.20.0-1LocallyBuiltWithAutotools/Make? 1.20.0-2? 1.20.0-4? Something else?) should I do that?

I am using the VESA driver because that was the easiest way to get X running. I am not sure weather the sis driver will work. I have to build it from AUR. That is more work. kms requires some configuration. And so does fb, doesn't it? I think the VESA driver is important because, as far as I can tell, many arch derivatives are using it to have a live CD experience.

Last edited by regid (2018-05-23 21:20:28)

seth · 2018-05-23 21:25:53

You could try to install another version (in doubt just the one from the repos) and symlink libfb.so into /usr/lib.
As you can see, it's not linked in your working build, so there's a rather good chance that this is the cause of the failure.

Eewww... SIS :-(
The version in AUR will not even install (requires a server even < 1.19) so xf86-video-vesa is probably indeed the only usable driver (but idk for real), so we'll need to focus on that.

Arch Linux

#1 2018-05-20 14:18:45

xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#2 2018-05-20 16:35:55

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#3 2018-05-20 18:23:34

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#4 2018-05-20 18:42:11

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#5 2018-05-20 22:43:12

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#6 2018-05-21 09:30:44

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#7 2018-05-21 11:37:47

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#8 2018-05-21 14:50:19

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#9 2018-05-21 16:57:14

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#10 2018-05-22 01:03:12

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#11 2018-05-22 11:37:32

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#12 2018-05-22 14:07:09

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#13 2018-05-22 16:04:52

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#14 2018-05-22 23:00:09

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#15 2018-05-22 23:58:55

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#16 2018-05-23 08:48:52

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#17 2018-05-23 10:19:36

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#18 2018-05-23 14:37:55

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#19 2018-05-23 19:00:59

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#20 2018-05-23 19:22:29

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#21 2018-05-23 19:32:50

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#22 2018-05-23 19:58:06

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#23 2018-05-23 20:03:08

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#24 2018-05-23 20:56:47

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

#25 2018-05-23 21:25:53

Re: xorg-server{,-common} 1.20.0-1 work but not -2, with VESA 2.4.0-2

Board footer