Hey, Could the xorg package set be updated to include the following packages, for the lts point release?
libdrm-lts-quantal mesa-lts-quantal xorg-server-lts-quantal xorg-lts-quantal and a wildcard xf86-*-lts-quantal xserver-xorg-*-lts-quantal same with s/quantal/raring/ would be nice too, but probably overboard at this point. :-) ---- Lets get more into details now, since I think most technical issues have been worked out now, so I think this can be uploaded soon after verifying it works locally. Needs to be updated in precise, for building: apt, for switching stacks https://launchpad.net/bugs/1062503 x11proto-gl, from quantal for xserver x11proto-dri2, from quantal for xserver x11proto-randr, from quantal for xserver wayland, from quantal for mesa 9. New unrenamed packages for precise: llvm-3.1, from version from quantal, used by mesa 9. ----- All the -lts-quantal packages are autogenerated, by running the lts-stack script from: https://code.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools Currently I use 'lts-stack' on quantal to download all packages, and rerun it again on precise from same directory to generate the binaries. Special cases: libdrm -> weird case to rename, really special case, see lts-libdrm-rename all sonames have been renamed to start with libkms_ltsq or libdrm_ltsq, for example libdrm_ltsq_radeon.so.1 and libdrm_ltsq.so.2. libdrm_nouveau1a has been killed by the rename script. mesa -> slightly easier, can no longer directly link with -ldrm* so scripts are used to fix those makefiles up. libosmesa6 and libgl1-mesa-dri-experimental are not rebuilt by the rename script. xorg-server -> renamed, not building xdmx, xdmx-tools, xnest, xvfb, xserver-xephyr, xserver-xfbdev some patchups required to handle this. A patch is reintroduced to support -nr as alias for -background none, as compatibility for *dm that still pass -nr in precise. xserver-common rename is a special case, and the renamed package depends on the unrenamed xserver-common. The renamed package will not build the manpage, and divert /usr/lib/xorg/protocol.txt from the unrenamed package so there are no conflicts. xserver-xorg-video-qxl is not built any more, it required a newer libspice-dev or something.. The drivers are all renamed through the generic script, and only xserver-xorg-video-intel required a small fix where it used -ldrm_intel instead of @DRMINTEL_LIBS@ in one of the Makefiles. I think some input drivers are not built currently, but could probably easily be added if needed. xorg renamed has its own script, I killed a lot of packages there causing troubles, and only use it as base for defining the renamed x stack. - xserver-xorg-lts-quantal is the core package, it has some conflicts with some unrenamed mesa and xorg-server packages to smoothen transitions and making sure you don't end up with a mixture between old and new stack. - xserver-xorg-video-all and xserver-xorg-input-all renamed have an identical purpose to their unrenamed counterparts, but with the list from quantal. xserver-xorg-video-qxl is removed from the video-all list. The unrenamed xorg package is modified as well. The virtual 'xorg' binary package gets the version from its depends on xserver-xorg-core removed. xserver-xorg unrenamed gets a conflicts on xorg-renamed-package, which is provided by ALL renamed packages to allow conflicts with any other version. So installing xserver-xorg makes sure no renamed packages are active. All packages also provide xorg-renamed-package-lts-quantal, so future stacks could conflict on that to make sure you don't get into situations where you have pieces of multiple stacks. Open issues: Binary drivers -> tricky, fglrx unfortunately dropped support for older cards, so no idea what to do there yet. nvidia should have been updated to add versioned provides, but I'm not sure if nvidia-common can take into account the current video abi yet when suggesting packages, this needs more thorough investigation. Does anyone want to take up this item? At one point plymouth needs to be tested with hardware that's not supported by the current libdrm, and then we can see if we might need to update libdrm or not. I was thinking probably something like haswell might break on plymouth if intel initialization fails. Does anyone have the hardware to test this yet? ~Maarten -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
