xorgproto-2023.2

[Bruce Dubbs]

New version.

[Xi Ruoyao]

Do we still need the -Dlegacy=true option? It looks like Arch and Gentoo don't use it.

[pierre]

This is xorgproto-2023.2 as a quick-fix release to address the Present protocol version not being updated in xorgproto-2023.1.

Olivier Fourdan (2):

presentproto: Update version number to 1.3 xorgproto 2023.2

[pierre]

Replying to Xi Ruoyao:

Do we still need the -Dlegacy=true option? It looks like Arch and Gentoo don't use it.

Using this options installs .pc and header files for:

        'evieproto',
        'fontcacheproto',
        'lg3dproto',
        'printproto',
        'trapproto',
        'windowswmproto',
        'xcalibrateproto',
        'xf86miscproto',
        'xf86rushproto',
        'xproxymngproto'

I think the only way to answer whether they are needed would be to try to build full xorg without this option. I'm not sure how many packages outside of xorg use protos' and if so, how many would use legacy protos...

But well, this is development... Let's remove it and see whether we get an error later.

[Xi Ruoyao]

Replying to pierre:

Replying to Xi Ruoyao:

Do we still need the -Dlegacy=true option? It looks like Arch and Gentoo don't use it.

Using this options installs .pc and header files for:

        'evieproto',
        'fontcacheproto',
        'lg3dproto',
        'printproto',
        'trapproto',
        'windowswmproto',
        'xcalibrateproto',
        'xf86miscproto',
        'xf86rushproto',
        'xproxymngproto'

I think the only way to answer whether they are needed would be to try to build full xorg without this option. I'm not sure how many packages outside of xorg use protos' and if so, how many would use legacy protos...

But well, this is development... Let's remove it and see whether we get an error later.

I'll remove these .pc and headers files from my system and see if things will be broken.

[pierre]

Fixed at 6167879d. The legacy option is removed. The option may be needed for old programs, but not for BLFS, I think.

[Tim Tassonis]

libxkbfile-1.1.2 does not compile without -Dlegacy=true, so I think, we still need it.

[Xi Ruoyao]

Replying to Tim Tassonis:

libxkbfile-1.1.2 does not compile without -Dlegacy=true, so I think, we still need it.

Hmm, but how Arch and Gentoo compiles libxkbfile? Let me figure it out...

[Tim Tassonis]

Replying to Xi Ruoyao:

Replying to Tim Tassonis:

libxkbfile-1.1.2 does not compile without -Dlegacy=true, so I think, we still need it.

Hmm, but how Arch and Gentoo compiles libxkbfile? Let me figure it out...

Maybe, we don't need libxkbfile anymore, in this case it should be dropped from Xorg libraries. But I really wouldn't know that.

[Tim Tassonis]

Just looked into arch quickly, I didn't see anything special regarding libxkbfile

[Xi Ruoyao]

Well, this XKBgeom.h file is installed by both xorgproto (if -Dlegacy=true used) and libX11.

In xorg libraries, we install libX11 before libxkbfile. So the file should be existing. A package manager issue (failing to detect conflict files) issue I guess.

[Tim Tassonis]

Are you sure about that?

[Xi Ruoyao]

Replying to Tim Tassonis:

Are you sure about that?

I'm pretty sure about

Well, this XKBgeom.h file is installed by both xorgproto (if -Dlegacy=true used) and libX11.

In xorg libraries, we install libX11 before libxkbfile. So the file should be existing.

Not sure about "package manager issue".

[pierre]

I can confirm my PM had not removed XKBgeom.h even though I uninstalled xorgproto-legacy.

[pierre]

My PM does not complain on files installed by two different packages...

[Xi Ruoyao]

A similar story happens to vldXvMC.h, which is installed by both "legacy" xorgproto and libXvMC. Arch has handled this mess: ​https://gitlab.archlinux.org/archlinux/packaging/packages/xorgproto/-/commit/7043db2f97a133e03bdc6b90af7c11bac2869426

[Tim Tassonis]

Well, mine is quite a fascist about that, and glady LFS/BLFS are mostly clean in that regard.

[Xi Ruoyao]

I just performed "package management" to remove the legacy things by

diff dest-with-legacy dest-without-legacy  -Naur | sudo patch -Np1 -d /

This obviously won't detect conflicting files, so I can reproduce the issue on my system. But after reinstalled libX11, libxkbfile builds fine.

[Xi Ruoyao]

Replying to Tim Tassonis:

Well, mine is quite a fascist about that, and glady LFS/BLFS are mostly clean in that regard.

Is it possible yours consider two exactly same versions "not conflicting"? Maybe it's a very old header and it has not changed at all for a decade.

[Tim Tassonis]

Replying to Xi Ruoyao:

Replying to Tim Tassonis:

Well, mine is quite a fascist about that, and glady LFS/BLFS are mostly clean in that regard.

Is it possible yours consider two exactly same versions "not conflicting"? Maybe it's a very old header and it has not changed at all for a decade.

No, mine really just keeps a simple list of absolute filenames for every installed package. If a new package is installed, the PM then just scans all filelists of every installed package and bombs out if there is a match. Config files are handled differently, of course.

The issue seems to be at my side that xorg libraries are a special case, as I only create one package for the whole page, and not per archive. Arch and Stuff however surely have packages for every single package in Xorg libraries.

So, at the first install, I have to do a full non-package manager DESTDIR install in order for the later packages to find the headers from the previous ones. After that, I do another PM based installed, which then overwrite those files (they are not yet part of a registered package).

Now, here, I did not do the first part, otherwise libX11 would have installed the now missing header.

I can fix that, so if libX11 really installs the header, I'm all fine with dropping -Dlegacy=true.

[Tim Tassonis]

Just confirming this is actually the case:

timtas@elliot:~/src/lgl/src/lgl/xorg/010-xorg-xlib$ find xorg-xlib-dest -name XKBgeom.h
xorg-xlib-dest/opt/X11/include/X11/extensions/XKBgeom.h

So, for my part, the ticket can be closed again, -Dlegacy=true can go, if one follows the book, all seems fine.

[Xi Ruoyao]

Closing, if something else blows up please reopen again.

[Bruce Dubbs]

Milestone renamed