[arch-dev-public] Mesa 9.1 in testing
New unified Mesa has hit testing. Upgrade path went smooth here. Please test it. Now the main mesa pkg should provide everything required to build and link packages. The mesa-libgl pkg providing libgl should be not be used in the dependency array when linking to libgl.so - please use "libgl" that will allow users to choose also nvidia-utils or catalyst-utils. There are still packages in extra depending on the old libgl package. We will need to fix them before makepkg will properly allow to build only against new mesa. -Andy
On 02/23/2013 11:23 AM, Andreas Radke wrote:
i find that disturbing. mesa-libgl is always a dependecy if libs link to it and never a makedepends. on the other hand, mesa can be a makedepends and sometimes a depends.
we do not need to do anything more that fixing mesa. other packages doesn't need any modification.
-Andy
-- Ionuț
[2013-02-23 10:23:13 +0100] Andreas Radke:
With [testing] enabled, `pacman -S libgl` still pulls the old libgl, rather than mesa-libgl which provides it and lies in a higher-priority repo. I am not sure why. Anyhow, most pacman transactions required to build anything depending (directly or not) on mesa and libgl result in: /usr/lib/xorg/modules/dri/swrast_dri.so exists in both 'mesa' and 'libgl' Is this what you were referring to? Or is there anything I am missing to avoid running into this issue. -- Gaetan
Le dimanche 24 février 2013 22:41:08 Gaetan Bisson a écrit :
Suffer from same issue for lib32-mesa-demos-8.1.0. Perhaps adding provides=('libgl=${pkgver}' ...) in mesa-libgl should be enough to get rid of this ? (not tested) ++
Am Sun, 24 Feb 2013 22:41:08 +1100 schrieb Gaetan Bisson <bisson@archlinux.org>:
Yes. We are looking for a solution for this. I guess this is a pacman limitation. Afaik pacman can resolve replaces only on -Su upgrades. If nobody shows a real solution we can either move Mesa pretty quickly to extra resolving this. This will for sure trigger some bugs for the users. Or we use an ugly workaround: when a chroot build fails move the dependency array from the top of the PKGBUILD to the package() function array. -A
[2013-02-24 17:16:42 +0100] Sven-Hendrik Haase:
+1 for moving mesa quickly
Do you have any more arguments than Andreas gave to support this? Or is the "+1" entirely for free? -- Gaetan
On 24.02.2013 23:31, Gaetan Bisson wrote:
Moving it quickly would seem like the simplest solution and the bugs I heard of seem only to concern wayland. I'd wager that for most our users, moving it now would be a fine idea. The other trickery suggested doesn't sit well with me.
Le lundi 25 février 2013 04:24:07 Sven-Hendrik Haase a écrit :
I agree. A quick move is the best solution. ++
Am Mon, 25 Feb 2013 21:56:37 +0100 schrieb Laurent Carlier <lordheavym@gmail.com>:
Already done. -Andy
On Mon, Feb 25, 2013 at 3:25 PM, Ionut Biru <ibiru@archlinux.org> wrote:
I did this upgrade today on a non-desktop, and was very unpleasantly surprised. Did we really mean to suck this many dependencies onto machines that aren't even running X11, let alone 3D graphics and such? Cairo is used by several packages for font-rendering (rrdtool here pulls this in on this box), and now the dependencies have ballooned by ~130 MB. I can always fall back to using a cairo sans X11 package out of the AUR like https://aur.archlinux.org/packages/cairo-dfb/, but just wanted to make sure this was known. dmcgee@toofishes ~ $ pacSyu :: Synchronizing package databases... core is up to date extra is up to date community is up to date :: Starting full system upgrade... warning: postgis: ignoring package upgrade (1.5.3-2 => 2.0.2-1) resolving dependencies... :: There are 4 providers available for libgl: :: Repository extra 1) mesa-libgl 2) nvidia-304xx-utils 3) nvidia-utils :: Repository community 4) catalyst-utils Enter a number (default=1): 1 looking for inter-conflicts... Targets (13): Name Old Version New Version Net Change Download Size cairo 1.12.12-1 1.12.14-3 0.11 MiB damageproto 1.2.1-2 0.07 MiB fixesproto 5.0-2 0.10 MiB libdrm 2.4.42-1 0.67 MiB libpciaccess 0.13.1-1 0.11 MiB libvdpau 0.6-1 0.24 MiB libxdamage 1.1.4-1 0.03 MiB libxfixes 5.0-2 0.09 MiB libxxf86vm 1.1.2-1 0.13 MiB mesa 9.1-2 127.40 MiB mesa-libgl 9.1-2 0.00 MiB wayland 1.0.5-1 0.57 MiB xf86vidmodeproto 2.3.1-2 0.07 MiB Total Installed Size: 133.02 MiB Net Upgrade Size: 129.60 MiB Proceed with installation? [Y/n] n -Dan
On 02/26/2013 05:51 AM, Dan McGee wrote:
I also had a plus of around 180 MiB (including lib32-mesa) on a standard desktop running X11, 3D, games and the like, so this does not only concern non-X11 systems.
On Tue, Feb 26, 2013 at 10:51 AM, Jakob Gruber <jakob.gruber@gmail.com> wrote:
The mesa package seems to contain at least 7 (!) copies of LLVM, in egl_gallium.so, pipe_swrast.so, gbm_gallium_drm.so, libllvmradeon9.1.0.so, libxatracker.so.1.0.0, libvdpau_softpipe.so.1.0.0 and swrast_dri.so. This blows up the package size something fierce. Hopefully, it will get better with llvm 3.3, when we can link against shared LLVM libs. In the meantime, can libllvmradeon9.1.0.so be moved to the ati driver package? As a side note, lrzip manages to get the mesa package size down to 16MB (from 32MB with xz.)
On 25/02/13 01:40, Andreas Radke wrote:
Same thing the KDE packager have been dealing with for years... pacman selects exact package matches before it selects providers without regard to the repo hierarchy. I doubt that will ever change. What might change, is makepkg resolving makedepends first and then dependencies. See https://bugs.archlinux.org/task/32723 . I need to think more about that to see if there are any downsides. Allan
Am 23.02.2013 10:23, schrieb Andreas Radke:
lib32-mesa lacks the necessary replaces= for the old split packages. lib32-mesa-demos conflicts with mesa-demos, so you can't have both glxinfo and glxinfo32 now.
Le mercredi 27 février 2013 16:02:10 Thomas Bächler a écrit :
No: provides=('lib32-libglapi' 'lib32-osmesa' 'lib32-libgbm' 'lib32-libgles' 'lib32-libegl') conflicts=('lib32-libglapi' 'lib32-osmesa' 'lib32-libgbm' 'lib32-libgles' 'lib32-libegl') replaces=('lib32-libglapi' 'lib32-osmesa' 'lib32-libgbm' 'lib32-libgles' 'lib32-libegl')
lib32-mesa-demos conflicts with mesa-demos, so you can't have both glxinfo and glxinfo32 now.
Fixed, i wasn't at home. Regards, ++
Am 27.02.2013 16:38, schrieb Laurent Carlier:
So why didn't pacman ask if it should replace them?
participants (10)
-
Allan McRae
-
Andreas Radke
-
Dan McGee
-
Gaetan Bisson
-
Ionut Biru
-
Jakob Gruber
-
Jan Steffens
-
Laurent Carlier
-
Sven-Hendrik Haase
-
Thomas Bächler