[2013-02-23 10:23:13 +0100] Andreas Radke:

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.

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

Am Sun, 24 Feb 2013 22:41:08 +1100 schrieb Gaetan Bisson :

[2013-02-23 10:23:13 +0100] Andreas Radke:

...

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.

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.

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

On 25/02/13 01:40, Andreas Radke wrote:

Am Sun, 24 Feb 2013 22:41:08 +1100 schrieb Gaetan Bisson :

...

[2013-02-23 10:23:13 +0100] Andreas Radke:

...

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.

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.

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.

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

On 24.02.2013 23:31, Gaetan Bisson wrote:

[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?

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.

Am Mon, 25 Feb 2013 21:56:37 +0100 schrieb Laurent Carlier :

Le lundi 25 février 2013 04:24:07 Sven-Hendrik Haase a écrit :

...

On 24.02.2013 23:31, Gaetan Bisson wrote:

...

[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?

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.

I agree. A quick move is the best solution.

++

Already done. -Andy

On Mon, Feb 25, 2013 at 3:25 PM, Ionut Biru wrote:

On 02/25/2013 11:03 PM, Andreas Radke wrote:

...

Am Mon, 25 Feb 2013 21:56:37 +0100 schrieb Laurent Carlier :

...

Le lundi 25 février 2013 04:24:07 Sven-Hendrik Haase a écrit :

...

On 24.02.2013 23:31, Gaetan Bisson wrote:

...

[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?

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.

I agree. A quick move is the best solution.

++

Already done.

-Andy

i just removed libgl from extra.

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 Tue, Feb 26, 2013 at 10:51 AM, Jakob Gruber 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.

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.)

Le mercredi 27 février 2013 16:02:10 Thomas Bächler a écrit :

Am 23.02.2013 10:23, schrieb Andreas Radke:

...

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.

lib32-mesa lacks the necessary replaces= for the old split packages.

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, ++

On 02/27/2013 05:42 PM, Thomas Bächler wrote:

Am 27.02.2013 16:38, schrieb Laurent Carlier:

...

Le mercredi 27 février 2013 16:02:10 Thomas Bächler a écrit :

...

Am 23.02.2013 10:23, schrieb Andreas Radke:

...

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.

lib32-mesa lacks the necessary replaces= for the old split packages.

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')

So why didn't pacman ask if it should replace them?

maybe because they were still in repos? -- Ionuț