[gentoo-user] portage and packages.gentoo.org discrepancies
Hi, New user here. I'm wondering about the disconnect between package versions listed on packages.gentoo.org and those available in portage. For example: $ ls /usr/portage/media-libs/mesa/*.ebuild mesa-18.3.6.ebuild mesa-19.0.2.ebuild mesa-19.0.3.ebuild mesa-.ebuild Meanwhile, the table at https://packages.gentoo.org/packages/media-libs/mesa lists entirely different versions. The footnote of the website claims it is current. Am I doing something wrong or is there some issue with packages.gentoo.org? Best regards, Z
Re: [gentoo-user] opencl runtime
On Tuesday, 4 October 2022 23:24:54 BST Michael wrote: > Thanks Peter, I've keyworded it along with half a dozen of other > dependencies it dragged in and it is emerging now. Will mesa still be > required, or are the two packages used for different purposes and can > co-exist? I don't know what mesa is supposed to do, other than what eix tells me. I don't think there's any overlap. Co-existence is good, no? $ emerge -cpv mesa Calculating dependencies ... done! media-libs/mesa-22.2.0 pulled in by: app-office/libreoffice-7.3.6.2 requires media-libs/mesa[egl(+)] dev-libs/rocm-opencl-runtime-5.1.3 requires media-libs/mesa kde-plasma/kwin-5.25.5 requires >=media-libs/ mesa-21.1[egl(+),gbm(+),wayland,X] media-libs/gst-plugins-base-1.20.3 requires >=media-libs/ mesa-9.0[egl(+),abi_x86_64(-)] media-libs/libepoxy-1.5.10-r1 requires media-libs/ mesa[egl(+),abi_x86_64(-)] net-libs/webkit-gtk-2.38.0 requires media-libs/mesa[egl(+)] virtual/opengl-7.0-r2 requires >=media-libs/mesa-9.1.6[X(+),abi_x86_64(-)] www-client/firefox-105.0.1 requires media-libs/mesa x11-apps/mesa-progs-8.5.0 requires media-libs/mesa[abi_x86_64(-),egl(+),X] x11-base/xorg-server-21.1.4 requires >=media-libs/ mesa-18[X(+),egl(+),gbm(+)] x11-base/xwayland-22.1.3 requires >=media-libs/ mesa-21.1[X(+),egl(+),gbm(+)] x11-libs/cairo-1.16.0-r5 requires >=media-libs/ mesa-9.1.6[egl(+),X(+),abi_x86_64(-)] x11-libs/gtk+-3.24.34 requires media-libs/mesa[X(+),abi_x86_64(-)] -- Regards, Peter.
Re: [gentoo-user] To be mesa or not to be mesa...
090625 meino.cra...@gmx.de wrote: I am using an nvidia graphics card GeForce (7600 GT (rev a2)) with the nvidia drivers. Do I need mesa to be installed ? I am heavily using OpenGL with Blender. On my machine with an 'Asus EN8500GT Nvidia 512 MB DDR2 800' card root:502 root eix ^mesa$ ... Installed versions: 7.3-r1([2009-04-11 04:50:13])(motif nptl -debug -doc -kernel_FreeBSD -pic -video_cards_intel -video_cards_mach64 -video_cards_mga -video_cards_none -video_cards_r128 -video_cards_radeon -video_cards_s3virge -video_cards_savage -video_cards_sis -video_cards_sunffb -video_cards_tdfx -video_cards_trident -video_cards_via -xcb) ... root:503 root equery d mesa [ Searching for packages depending on mesa... ] virtual/glu-7.0 (media-libs/mesa) virtual/opengl-7.0 (media-libs/mesa) x11-base/xorg-server-1.5.3-r6 (!minimal? =media-libs/mesa-7.1) x11-drivers/nvidia-drivers-180.29 (media-libs/mesa) -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Back in the soup [circular mask problem]
Harry Putnam wrote: I need Mesa libs onboard (its not mandatory ) so looking at partage for mesa libs I find: media-libs/mesa [ Masked ] Latest version available: 6.4.2-r1 Latest version installed: [ Not Installed ] If you have xorg-6.8.2 installed, then you already have Mesa on board: equery files xorg-x11 | grep -i mesa Benno -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] mesa build failure
On 27/11/2017 20:18, Walter Dnes wrote: > I'm running 32-bit Gentoo. mesa is the last remaining package in the > current emerge update. Just in case, I tried... > > MAKEOPTS="-j1" emerge --changed-use --deep --update @world > > That did not help. Attached are the build log and output of > > emerge --info '=media-libs/mesa-17.1.8::gentoo' > This is your build error: /var/tmp/portage/media-libs/mesa-17.1.8/work/mesa-17.1.8/src/mesa/swrast/s_aatritemp.h: In function 'rgba_aa_tri': /var/tmp/portage/media-libs/mesa-17.1.8/work/mesa-17.1.8/src/mesa/swrast/s_aatritemp.h:196:57: error: implicit declaration of function 'omp_get_thread_num' [-Werror=implicit-function-declaration] span.array = SWRAST_CONTEXT(ctx)->SpanArrays + omp_get_thread_num(); IIRC openmp provides that function. But his: cc1: some warnings being treated as errors make[5]: *** [Makefile:2946: swrast/s_aatriangle.lo] Error 1 make[5]: Leaving directory '/var/tmp/portage/media-libs/mesa-17.1.8/work/mesa-17.1.8-abi_x86_32.x86/src/mesa' mesa has 18 versions in-tree and mesa-17.1.8 is the second oldest. Any special reason you are stuck so far back? A package.mask you no longr actually need maybe? My first action would be to use something more rcent that functions for yu. Alan -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: To be mesa or not to be mesa...
On 06/25/2009 05:51 AM, meino.cra...@gmx.de wrote: Hi, short question: I am using an nvidia graphics card GeForce (7600 GT (rev a2)) with the nvidia drivers. Do I need mesa to be installed (I am heavily using OpenGL with Blender...) You only need mesa if portage tells you so. In other words, most probably yes, since it's an important dependency of many packages. If however on your system it happens not to be a dependency of anything, then you don't need it. To check, simply edit /var/lib/portage/world and delete the line media-libs/mesa if it exists. If emerge -p --depclean wants to unmerge mesa, then you don't need it. Just make sure to run revdep-rebuild afterwards to make sure to packages were broken by this.
Re: [gentoo-user] Who can tell me relationship among dri,glx,mesa,xorg?
Am Mittwoch, 14. Dezember 2011, 14:22:47 schrieb Lavender: Now I'm totally confused, I can't find helpful information from Internet. I know mesa is a open source implementation of OpenGL, obviously mesa will afford OpenGL API. DRI is short for Direct Rendering Infrastructure, I have chosen options like: Device Drivers --- Graphics support --- * Direct Rendering Manager --- this is DRM. This one manages allocation of memory for video devices. *ATI Radeon [*] Enable modesetting on radeon by default Does this mean that DRI libraries are built into kernel? No. If not, who contains DRI? Also who affords GLX libraries? Mesa or Xorg? DRI is part of mesa. Mesa also provides the GLX libraries. Best, Michael
Re: [gentoo-user] portage and packages.gentoo.org discrepancies
Hi, On mar. 7 mai 12:26:44 2019, Zero Zero wrote: > Hi, > > New user here. I'm wondering about the disconnect between package versions > listed on packages.gentoo.org and those available in portage. For example: > > $ ls /usr/portage/media-libs/mesa/*.ebuild > mesa-18.3.6.ebuild mesa-19.0.2.ebuild mesa-19.0.3.ebuild > mesa-.ebuild > > Meanwhile, the table at https://packages.gentoo.org/packages/media-libs/mesa > lists entirely different versions. The footnote of the website claims it is > current. Am I doing something wrong or is there some issue with > packages.gentoo.org? When did you synced your tree for the last time? -- Alarig
[gentoo-user] mesa-12.0.1 fails to emerge
How could I go beyond this point?
/var/tmp/portage/media-
libs/mesa-12.0.1/work/mesa-12.0.1/src/gallium/state_track
ers/clover/llvm/invocation.cpp:212:75: error: no matching function for call to
‘
clang::CompilerInvocation::setLangDefaults(clang::LangOptions&,
clang::InputKind
, llvm::Triple, clang::LangStandard::Kind)’
Extract from compile log attached.
I am running sys-devel/clang-runtime-3.9.1 like so:
Installed versions: 3.9.1(21:25:30 07/02/17)(openmp -libcxx ABI_MIPS="-
n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
--
Regards,
Micklibtool: compile: x86_64-pc-linux-gnu-g++ -DPACKAGE_NAME=\"Mesa\" -DPACKAGE_TAR
NAME=\"mesa\" -DPACKAGE_VERSION=\"12.0.1\" "-DPACKAGE_STRING=\"Mesa 12.0.1\"" "-
DPACKAGE_BUGREPORT=\"https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa\";
-DPACKAGE_URL=\"\" -DPACKAGE=\"mesa\" -DVERSION=\"12.0.1\" -DSTDC_HEADERS=1 -DHA
VE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_
MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNIST
D_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DYYTEXT_POINTER=1 -DHAVE___BUILTI
N_BSWAP32=1 -DHAVE___BUILTIN_BSWAP64=1 -DHAVE___BUILTIN_CLZ=1 -DHAVE___BUILTIN_C
LZLL=1 -DHAVE___BUILTIN_CTZ=1 -DHAVE___BUILTIN_EXPECT=1 -DHAVE___BUILTIN_FFS=1 -
DHAVE___BUILTIN_FFSLL=1 -DHAVE___BUILTIN_POPCOUNT=1 -DHAVE___BUILTIN_POPCOUNTLL1 -DHAVE___BUILTIN_UNREACHABLE=1 -DHAVE_FUNC_ATTRIBUTE_CONST=1 -DHAVE_FUNC_ATTRI
BUTE_FLATTEN=1 -DHAVE_FUNC_ATTRIBUTE_FORMAT=1 -DHAVE_FUNC_ATTRIBUTE_MALLOC=1 -DH
AVE_FUNC_ATTRIBUTE_PACKED=1 -DHAVE_FUNC_ATTRIBUTE_PURE=1 -DHAVE_FUNC_ATTRIBUTE_R
ETURNS_NONNULL=1 -DHAVE_FUNC_ATTRIBUTE_UNUSED=1 -DHAVE_FUNC_ATTRIBUTE_WARN_UNUSE
D_RESULT=1 -DHAVE_FUNC_ATTRIBUTE_WEAK=1 -DHAVE_DLADDR=1 -DHAVE_CLOCK_GETTIME=1 -
DHAVE_PTHREAD=1 -DHAVE_SHA1_IN_LIBNETTLE=1 -I. -I/var/tmp/portage/media-libs/mes
a-12.0.1/work/mesa-12.0.1/src/gallium/state_trackers/clover -I/var/tmp/portage/m
edia-libs/mesa-12.0.1/work/mesa-12.0.1/include -I/var/tmp/portage/media-libs/mes
a-12.0.1/work/mesa-12.0.1/src -I/var/tmp/portage/media-libs/mesa-12.0.1/work/mes
a-12.0.1/src/gallium/include -I/var/tmp/portage/media-libs/mesa-12.0.1/work/mesa
-12.0.1/src/gallium/drivers -I/var/tmp/portage/media-libs/mesa-12.0.1/work/mesa-
12.0.1/src/gallium/auxiliary -I/var/tmp/portage/media-libs/mesa-12.0.1/work/mesa
-12.0.1/src/gallium/winsys -I../../../../src -I/var/tmp/portage/media-libs/mesa-
12.0.1/work/mesa-12.0.1/src/gallium/state_trackers/clover -std=c++11 -fvisibilit
y=hidden -I/usr/include -std=c++11 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACR
OS -D__STDC_LIMIT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -D_GNU_S
OURCE -DUSE_SSE41 -DNDEBUG -DTEXTURE_FLOAT_ENABLED -DUSE_X86_64_ASM -DHAVE_XLOCA
LE_H -DHAVE_SYS_SYSCTL_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_DLOPEN -DHAVE_POSI
X_MEMALIGN -DHAVE_LIBDRM -DHAVE_SHA1 -DGLX_USE_DRM -DHAVE_LIBUDEV -DGLX_INDIRECT
_RENDERING -DGLX_DIRECT_RENDERING -DGLX_USE_TLS -DHAVE_ALIAS -DHAVE_DRI3 -DHAVE_
MINCORE -DHAVE_ST_VDPAU -DHAVE_LLVM=0x0309 -DMESA_LLVM_VERSION_PATCH=1 -DLIBCLC_
INCLUDEDIR=\"/usr/include/\" -DLIBCLC_LIBEXECDIR=\"/usr/lib/clc/\" -DCLANG_RESOU
RCE_DIR=\"/usr/lib/clang/3.9.1\" -march=native -O2 -pipe -Wall -fno-strict-alias
ing -fno-builtin-memcmp -c /var/tmp/portage/media-libs/mesa-12.0.1/work/mesa-12.
0.1/src/gallium/state_trackers/clover/llvm/invocation.cpp -fPIC -DPIC -o llvm/.
libs/libclllvm_la-invocation.o
/var/tmp/portage/media-libs/mesa-12.0.1/work/mesa-12.0.1/src/gallium/state_track
ers/clover/llvm/invocation.cpp: In function ‘llvm::Module* {anonymous}::compile_
llvm(llvm::LLVMContext&, const string&, const header_map&, const string&, const
string&, const string&, const string&, unsigned int (&)[7], unsigned int&, std::
string&)’:
/var/tmp/portage/media-libs/mesa-12.0.1/work/mesa-12.0.1/src/gallium/state_track
ers/clover/llvm/invocation.cpp:212:75: error: no matching function for call to ‘
clang::CompilerInvocation::setLangDefaults(clang::LangOptions&, clang::InputKind
, llvm::Triple, clang::LangStandard::Kind)’
clang::LangStandard::lang_opencl11);
^
/var/tmp/portage/media-libs/mesa-12.0.1/work/mesa-12.0.1/src/gallium/state_track
ers/clover/llvm/invocation.cpp:212:75: note: candidate is:
In file included from /usr/include/clang/Frontend/CompilerInstance.h:17:0,
from /var/tmp/portage/media-libs/mesa-12.0.1/work/mesa-12.0.1/s
rc/gallium/state_trackers/clover/llvm/invocation.cpp:25:
/usr/include/clang/Frontend/CompilerInvocation.h:160:15: note: static v[41/1956]
::CompilerIn
[gentoo-user] compiz and mesa
compiz wants x11-libs/libX11[xcb] (even 0.8.2), and mesa 7.4_rc1 wants x11-libs/libX11[xcb=] (it's for current ~amd64). Does [xcb=] means without the flag? Tree bug?
Re: [gentoo-user] Re: To be mesa or not to be mesa...
On Thu, 25 Jun 2009 05:58:29 +0200, Volker Armin Hemmann wrote: if it exists. If emerge -p --depclean wants to unmerge mesa, then you don't need it. Just make sure to run revdep-rebuild afterwards to make sure to packages were broken by this. in the past a lot of packages needed mesa to compile even if they would run with nvidia's or ati's opengl just fine. In that case depclean won't remove it because it defaults to using --with-bdeps y. -- Neil Bothwick When there's a will, I want to be in it. signature.asc Description: PGP signature
[gentoo-user] Who can tell me relationship among dri,glx,mesa,xorg?
Now I'm totally confused, I can't find helpful information from Internet. I know mesa is a open source implementation of OpenGL, obviously mesa will afford OpenGL API. DRI is short for Direct Rendering Infrastructure, I have chosen options like: Device Drivers --- Graphics support --- * Direct Rendering Manager --- *ATI Radeon [*] Enable modesetting on radeon by default Does this mean that DRI libraries are built into kernel? If not, who contains DRI? Also who affords GLX libraries? Mesa or Xorg?
Re: [gentoo-user] mesa 9.1.2.r1 fails to build
Bug 458550 -- Regards Daniel
[gentoo-user] Digest verification failed:
Hello, I have done several emerge --sync today but the digest verification problem below does not go away. Any thoughts? Thank you. -- Valmor >>> Fetching (165 of 221) media-libs/mesa-11.0.6::gentoo !!! Digest verification failed: !!! /usr/portage/media-libs/mesa/mesa-.ebuild !!! Reason: Failed on SHA256 verification !!! Got: e2eb88ce00f4e8f37a940c982bfc7c38d5ed015477caa3397508792ca620968d !!! Expected: eb7a5581c6001e07d6a2a817f023cfd005ee45cda03cfca498e825bf3d3104a4 >>> Failed to emerge media-libs/mesa-11.0.6
Re: [gentoo-user] Re: mesa build failure
On 27/11/2017 21:59, Ian Zimmerman wrote: > On 2017-11-27 21:07, Alan McKinnon wrote: > >> mesa has 18 versions in-tree and mesa-17.1.8 is the second oldest. Any >> special reason you are stuck so far back? A package.mask you no longr >> actually need maybe? > > All the later ones are ~arch ? > what I typed is incomplete, sorry about that: mesa-17.1.8 is the second oldest ~arch version -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] mesa / 3d driver for openchrome
Hi folks, according to the mesa web site, mesa-7.0.2 contains a 3d driver for openchrome. Unfortunately, the ebuild knows only about a very limited number of video cards, openchrome not amoung them. How can I convince it to compile the openchrome 3d driver? Uwe -- Informal Linux Group Namibia: http://www.linux.org.na/ SysEx (Pty) Ltd.: http://www.SysEx.com.na/ -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Cannot update world: can't build mesa
I've been using radeonhd, mesa, dri and others from latest git. Now i'm trying to update world. emerge fails building mesa-7.4.2 from portage Well, the problem was with headers dri2proto. These were installed in /usr/local/include/drm and there was a conflict with /usr/include/drm The problem is solved.
[gentoo-user] Heads Up - mesa-9.0 needs media-libs/glu in addition
Hi, upgrading from mesa-9.0_pre20120918 to mesa-9.0 broke some package, among them ati-drivers. They have remove glu. Installing media-libs/glu in addition now (never needed it before) restores the essential /usr/include/GL/glu.h file. Helmut.
Re: [gentoo-user] zoom?
On Wed, 1 Apr 2020 09:12:46 +0800, William Kenworthy wrote:
> [blocks B ] media-libs/mesa[-libglvnd(-)]
> ("media-libs/mesa[-libglvnd(-)]" is blocking media-libs/libglvnd-1.3.1)
It looks like you need to emerge mesa with USE="libglvnd".
--
Neil Bothwick
WITLAG: The delay between delivery and comprehension of a joke.
pgpad7ESj5aSE.pgp
Description: OpenPGP digital signature
Re: [gentoo-user] Who can tell me relationship among dri,glx,mesa,xorg?
2011/12/14 Lavender lavender_mat...@163.com Now I'm totally confused, I can't find helpful information from Internet. I know mesa is a open source implementation of OpenGL, obviously mesa will afford OpenGL API. DRI is short for Direct Rendering Infrastructure, I have chosen options like: Device Drivers --- Graphics support --- * Direct Rendering Manager --- *ATI Radeon [*] Enable modesetting on radeon by default Does this mean that DRI libraries are built into kernel? If not, who contains DRI? Also who affords GLX libraries? Mesa or Xorg? About Mesa: http://www.mesa3d.org/intro.html About DRI: http://dri.freedesktop.org/wiki/ -- Andrés Becerra Sandoval
Re: [gentoo-user] x11-proto/dri2proto masked but still needed by media-libs/mesa
On Tue, 12 Jun 2018 09:13:03 +0200, Alarig Le Lay wrote: > Regarding /usr/portage/profiles/package.mask x11-proto/dri2proto but I > can’t remove it as mesa depends on it: > > # emerge -vac x11-proto/dri3proto > > Calculating dependencies... done! > x11-proto/dri3proto-1.0-r1 pulled in by: > media-libs/mesa-17.3.9 requires > >=x11-proto/dri3proto-1.0:0/0=[abi_x86_32(-),abi_x86_64(-)] > > I have the last stable version of mesa in the tree: It sounds like this bug https://bugs.gentoo.org/657832 If it is, re-emerging mesa should fix it. -- Neil Bothwick Nixon's Principal: If 2 wrongs don't make a right, try 3. pgpdEusuizOVX.pgp Description: OpenPGP digital signature
Re: [gentoo-user] X won't start after xorg-server update
On Sat, 14 Mar 2020 13:38:06 +0100, hitachi303 wrote: > > It seems that file is created/modified by the mesa ebuild. > > > > I would try removing the file and re-emerging mesa to see if it is > > created with the correct content. > > > > # mv -vi -- /etc/X11/xorg.conf.d/20opengl.conf . > # emerge -av1 mesa > > mesa doesn't generate the file. So now there is NO file but X does > start. I take it you don't have USE=libglvnd for mesa? -- Neil Bothwick If you got the words it does not mean you got the knowledge. pgpztzXbAmO0O.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: To be mesa or not to be mesa...
On Donnerstag 25 Juni 2009, Nikos Chantziaras wrote: On 06/25/2009 05:51 AM, meino.cra...@gmx.de wrote: Hi, short question: I am using an nvidia graphics card GeForce (7600 GT (rev a2)) with the nvidia drivers. Do I need mesa to be installed (I am heavily using OpenGL with Blender...) You only need mesa if portage tells you so. In other words, most probably yes, since it's an important dependency of many packages. If however on your system it happens not to be a dependency of anything, then you don't need it. To check, simply edit /var/lib/portage/world and delete the line media-libs/mesa if it exists. If emerge -p --depclean wants to unmerge mesa, then you don't need it. Just make sure to run revdep-rebuild afterwards to make sure to packages were broken by this. in the past a lot of packages needed mesa to compile even if they would run with nvidia's or ati's opengl just fine.
Re: [gentoo-user] [~amd64] Does the EGL useflag break mesa-progs-8.2.0?
On Wed, Jul 15, 2015 at 01:53:50PM -0700, walt wrote: Normally I would just file a bug report, but lately portage has been behaving so strangely I feel obligated to ask here first. Maybe you won't see what I see. Just try emerging mesa-progs-8.2.0 with the EGL useflag set. Attempting to compile =x11-apps/mesa-progs-8.2.0[egl,-gles1,-gles2] I got: Makefile:489: recipe for target 'eglut.lo' failed make: *** [eglut.lo] Error 1 Makefile:489: recipe for target 'eglut_screen.lo' failed make: *** [eglut_screen.lo] Error 1 libtool: compile: x86_64-pc-linux-gnu-gcc -DPACKAGE_NAME=\mesa-demos\ -DPACKAGE_TARNAME=\mesa-demos\ -DPACKAGE_VERSION=\8.2.0\ -DPACKAGE_STRING=\mesa-demos 8.2.0\ -DPACKAGE_BUGREPORT=\https://bugs.freedesktop.org/enter_bug.cgi?product=Mesacomponent=Demos\; -DPACKAGE_URL=\\ -DPACKAGE=\mesa-demos\ -DVERSION=\8.2.0\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\.libs/\ -DHAVE_LIBGLUT=1 -DHAVE_FREEGLUT=1 -DDEMOS_DATA_DIR=\../data/\ -DDEMOS_DATA_DIR=\../data/\ -I. -I/usr/include/libdrm -march=native -O2 -pipe -fomit-frame-pointer -c eglut_x11.c -o libeglut_x11_la-eglut_x11.o /dev/null 21 make: Leaving directory '/var/tmp/portage/x11-apps/mesa-progs-8.2.0/work/mesa-demos-8.2.0/src/egl/eglut' * ERROR: x11-apps/mesa-progs-8.2.0::gentoo failed (compile phase): * emake failed -- wraeth wra...@wraeth.id.au GnuPG Key: B2D9F759 signature.asc Description: Digital signature
[gentoo-user] emerge xorg-xll fails out at media-libs/mesa-6.5-r3
Hello all, I read through most of the X11 related messages so hopefully I am not repeating something already solved. Basically emerge drops out with the following error: makedepend: warning: glcontextmodes.c (reading /usr/X11R6/include/bits/types.h, line 31): cannot find include file stddef.h not in ./stddef.h not in ../../../include/stddef.h not in ../../../include/GL/internal/stddef.h not in ../../../src/mesa/main/stddef.h not in ../../../src/mesa/glapi/stddef.h not in ../../../src/mesa/drivers/dri/common/stddef.h not in /usr/include/drm/stddef.h not in /usr/X11R6/include/stddef.h not in /usr/include/stddef.h ... ... a repeating message like this one is displayed for each missing header file. ... and then: !!! ERROR: media-libs/mesa-6.5-r3 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile mesa-6.5-r3.ebuild, line 231: Called die It there a shared library that I need to emerge first that has these header files? Thanks for any help on the subject. Regards, Richard Broersma Jr. -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: (unknown)
On 10/25/2011 12:58 AM, Mick wrote: Does this need adding to /etc/make.conf? Yes. Everyone who uses an AMD card should have radeon in VIDEO_CARDS, followed by either r300 or r600. Of course only when we're taking about the X.Org drivers. If you're going to use the Catalyst proprietary drivers, you should put fglrx in VIDEO_CARDS. OK, I've added it and I'm remerging mesa to see what difference it makes. If mesa doesn't get automatically rebuilt (changing VIDEO_CARDS counts as a USE flags change, so emerge -uDN world will pick it up), then that means you're using a version of mesa that doesn't recognize r600. I'm on mesa- (one of the very few live ebuilds I use). Now that I checked this, it's the only version to recognize r300 and r600 in VIDEO_CARDS. However, that also means that future release versions of mesa will also recognize them (the live ebuilds are always a precursor of things to come.) So adding r300 or r600 now doesn't hurt and will ensure you don't forget to do so later when mesa 7.12 (or 8.0?) comes out.
Re: [gentoo-user] Re: OpenGL problem after upgrading mesa and xorg-server
Miroslav Rovis <miro.ro...@croatiafidelis.hr> wrote: > On 170314-05:32+0100, wabe wrote: > > wabe <waben...@gmail.com> wrote: > > > > > Since I've upgraded mesa (12.0.1 to 13.0.5) and xorg-server > > > (1.18.4 to 1.19.2), OpenGL programs don't work any longer for > > > non-root users, even when these users are members of the group > > > "video". > ... > > > > > > I searched the web and also read the gentoo xserver wiki but > > > couldn't find a solution. > > > > P.S.: After downgrading mesa to 12.0.1 everything works fine again. > > So the problem has nothing to do with xorg-server. > > Lots of bugs with mesa, esp. recently: > https://bugs.gentoo.org/buglist.cgi?quicksearch=mesa > > I masked it for now (if I had time, I'd contribute reports...): > > /etc/portage/package.mask/package.mask.file:>=media-libs/mesa-13.0.0 THX for your answer. I also masked it and will wait for next version. -- Regards wabe
Re: [gentoo-user] Re: OpenGL problem after upgrading mesa and xorg-server
On 170314-05:32+0100, wabe wrote: > wabe <waben...@gmail.com> wrote: > > > Since I've upgraded mesa (12.0.1 to 13.0.5) and xorg-server > > (1.18.4 to 1.19.2), OpenGL programs don't work any longer for > > non-root users, even when these users are members of the group > > "video". ... > > > > I searched the web and also read the gentoo xserver wiki but > > couldn't find a solution. > > P.S.: After downgrading mesa to 12.0.1 everything works fine again. > So the problem has nothing to do with xorg-server. Lots of bugs with mesa, esp. recently: https://bugs.gentoo.org/buglist.cgi?quicksearch=mesa I masked it for now (if I had time, I'd contribute reports...): /etc/portage/package.mask/package.mask.file:>=media-libs/mesa-13.0.0 ( Btw. how does one search for only recent bugs, anybody? ) -- Miroslav Rovis Zagreb, Croatia https://www.CroatiaFidelis.hr signature.asc Description: Digital signature
Re: [gentoo-user] Re: OpenGL problem after upgrading mesa and xorg-server
On March 14, 2017 6:57:59 AM GMT+01:00, Miroslav Rovis <miro.ro...@croatiafidelis.hr> wrote: >On 170314-05:32+0100, wabe wrote: >> wabe <waben...@gmail.com> wrote: >> >> > Since I've upgraded mesa (12.0.1 to 13.0.5) and xorg-server >> > (1.18.4 to 1.19.2), OpenGL programs don't work any longer for >> > non-root users, even when these users are members of the group >> > "video". >... >> > >> > I searched the web and also read the gentoo xserver wiki but >> > couldn't find a solution. >> >> P.S.: After downgrading mesa to 12.0.1 everything works fine again. >> So the problem has nothing to do with xorg-server. > >Lots of bugs with mesa, esp. recently: >https://bugs.gentoo.org/buglist.cgi?quicksearch=mesa > >I masked it for now (if I had time, I'd contribute reports...): > >/etc/portage/package.mask/package.mask.file:>=media-libs/mesa-13.0.0 > >( Btw. how does one search for only recent bugs, anybody? ) To see most recent bugs, sort on ID. To see most recently modified bug, sort on changed. (Click on the column headers) -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-user] Re: portage and packages.gentoo.org discrepancies
On Tue, 7 May 2019 12:26:44 +0200 Zero Zero wrote: > New user here. I'm wondering about the disconnect between package > versions listed on packages.gentoo.org and those available in > portage. For example: > > $ ls /usr/portage/media-libs/mesa/*.ebuild > mesa-18.3.6.ebuild mesa-19.0.2.ebuild mesa-19.0.3.ebuild > mesa-.ebuild > > Meanwhile, the table at > https://packages.gentoo.org/packages/media-libs/mesa lists entirely > different versions. The footnote of the website claims it is current. > Am I doing something wrong or is there some issue with > packages.gentoo.org? The issue is with packages.gentoo.org, whose tables aren't being updated for some reason. I don't know how long the problem has been going on there. I just noticed it yesterday while I was waiting for firefox-66.0.4; the last available firefox packages.g.o shows is 65.0. I'm content to wait for someone to notice and fix it, but there's a contact page in case anyone wants to nudge them. <https://packages.gentoo.org/about/feedback>
[gentoo-user] To be mesa or not to be mesa...
Hi, short question: I am using an nvidia graphics card GeForce (7600 GT (rev a2)) with the nvidia drivers. Do I need mesa to be installed (I am heavily using OpenGL with Blender...) Kind regards, mcc -- Please don't send me any Word- or Powerpoint-Attachments unless it's absolutely neccessary. - Send simply Text. See http://www.gnu.org/philosophy/no-word-attachments.html In a world without fences and walls nobody needs gates and windows.
Re: [gentoo-user] mesa build failure
On Friday 26 June 2009 21:05:01 Mark Knecht wrote: So the weirdness continues. mesa built but then xorg-server failed with the same failure: * SetUID: [chmod go-r] /usr/bin/Xorg ... [ ok ] Switching to xorg-x11 OpenGL interface...ln: creating symbolic link `./libglx.so': File exists !!! Error: Failed to create /lib/libglx.so Looks like you have a file collision between xorg-server and mesa, which is odd as those packages get a lot of testing. Anything on bugs.gentoo.org? -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Mythtv Segmentation fault
On Sep 1, 2009, at 8:24 AM, Neal Hogan wrote: Thanks to those who offered help . . . I got mythtv going by using a different version of mesa. While it was suggested that I use an older version, I ended up using a newer one. I went from media-libs/mesa-7.3-r1 to media-libs/mesa-7.5-r3. Now I just need to configure mythtv! Glad that did the trick... 7.5 wasn't available when I had my issue... maybe it's time to recompile! :-D
[gentoo-user] Re: opengl: missing symlink target for header
On 02/13/2015 10:19 AM, Nicolas Sebrecht wrote: Hi guys, If you have mesa and eselect-opengl-1.3.X installed, could you please tell me if the symlink /usr/include/GL/glext.h is broken for you? Like Alan, I have a regular file and not a symlink. The file was installed by mesa-10.4.4 IIUC, the only reason to install eselect-opengl is if you also install a package that installs modified/customized mesa libraries, e.g.nvidia-drivers or ati-drivers. Maybe you use such a package that created the symlink?
[gentoo-user] mesa build failure
I'm running 32-bit Gentoo. mesa is the last remaining package in the current emerge update. Just in case, I tried... MAKEOPTS="-j1" emerge --changed-use --deep --update @world That did not help. Attached are the build log and output of emerge --info '=media-libs/mesa-17.1.8::gentoo' -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications eminfo.txt.gz Description: Binary data mesalog.txt.gz Description: Binary data
[gentoo-user] Re: mesa build failure
On 2017-11-27 21:07, Alan McKinnon wrote: > mesa has 18 versions in-tree and mesa-17.1.8 is the second oldest. Any > special reason you are stuck so far back? A package.mask you no longr > actually need maybe? All the later ones are ~arch ? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet, fetch the TXT record for the domain.
Re: [gentoo-user] Do I need to do anything if a package masked by my profile?
Nevermind. Referring to the "x11-proto/dri2proto masked but still needed by media-libs/mesa" thread, looks like re-emerging mesa fixed the issue. ~Donny Johnson On Tue, Jun 12, 2018 at 8:17 PM, Donald Johnson wrote: > On Mon, Jun 11, 2018 at 4:36 AM, Neil Bothwick wrote: >> emerge -cpv packagename > > Oddly enough, I ran that command, and it looks like all of those > packages are required by media-libs/mesa-17.3.9. Now I'm curious... > > ~Donny Johnson
Re: [gentoo-user] eselect fouled
On Sunday 02 March 2008 03:03:15 pm Alan McKinnon wrote: /usr/lib/libGL.so is a symlink to /usr/lib/opengl/xorg-x11/lib/libGL.so on my machine, and that comes from media-libs/mesa. eselect updates that symlink. Do you have mesa correctly installed and does that target actually exist? Apparently not. media-libs/mesa wass emerged, but I did not have the libGL.so you mentioned. Re-emerging mesa and then re-eselecting seems to have fixed things. Thanks -- Alan McKinnon alan dot mckinnon at gmail dot com -- David Corbin Abolish the IRS - http://www.fairtax.org -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] eselect fouled
On Sunday 02 March 2008, David Corbin wrote: On Sunday 02 March 2008 03:03:15 pm Alan McKinnon wrote: /usr/lib/libGL.so is a symlink to /usr/lib/opengl/xorg-x11/lib/libGL.so on my machine, and that comes from media-libs/mesa. eselect updates that symlink. Do you have mesa correctly installed and does that target actually exist? Apparently not. media-libs/mesa wass emerged, but I did not have the libGL.so you mentioned. Re-emerging mesa and then re-eselecting seems to have fixed things. Cool. I take it your video is now OK and you don't need the ati or nvidia implementations? -- Alan McKinnon alan dot mckinnon at gmail dot com -- gentoo-user@lists.gentoo.org mailing list
Re: [gentoo-user] Back in the soup [circular mask problem]
On Friday 10 March 2006 18:10, Harry Putnam wrote: Ok, Its the only ebuild available and following that advice for ever will not explain how to get aroud this circular masking problem. It's not a circular masking problem, mesa is package.mask'd, as in proper-unstable-breaks-the-tree-broken masked. Its probably simple enough but not apparent to me. You could add media-libs/mesa to /etc/portage/package.unmask, but that will lead you into the (also package.mask'd) modularized X. Modularized X is obviously not ready for unstable, and the version of mesa in the tree depends on that modularized version to work. I don't think you are going to get mesa installed without a fair bit of trouble. -- Mike Williams -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] emerge xorg-xll fails out at media-libs/mesa-6.5-r3
Richard Broersma Jr wrote: makedepend: warning: glcontextmodes.c (reading /usr/X11R6/include/bits/types.h, line 31): cannot find include file stddef.h not in ./stddef.h not in ../../../include/stddef.h not in ../../../include/GL/internal/stddef.h not in ../../../src/mesa/main/stddef.h not in ../../../src/mesa/glapi/stddef.h not in ../../../src/mesa/drivers/dri/common/stddef.h not in /usr/include/drm/stddef.h not in /usr/X11R6/include/stddef.h not in /usr/include/stddef.h Hi, Those warnings are irrelevant. You need to find the actual error. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: (unknown)
On 10/24/2011 11:28 AM, Vishnupradeep wrote: On Mon, Oct 24, 2011 at 1:40 PM, Nikos Chantziaras rea...@arcor.de mailto:rea...@arcor.de wrote: In your /etc/make.conf, use this: I am using ATI 4350 card. so is that VIDEO_CARDS=radeon r700 No. There is no driver called r700. The driver is called r600 and it drives R600 chips and newer. Another thing I forgot to mention is that you should make sure you're using Gallium3D in Mesa. To see what you're using (after you've rebuilt everything), do: eselect mesa list If classic is selected instead of gallium, change it: eselect mesa set 64bit r600 gallium eselect mesa set 32bit r600 gallium
[gentoo-user] mesa-10.3.7-r1 S3TC option
After I updated mesa to 10.3.7-r1, I was provided with this message: Messages generated by process 2287 on 2015-02-19 20:32:50 GMT for package media-libs/mesa-10.3.7-r1: LOG: postinst Note that in order to have full S3TC support, it is necessary to install media-libs/libtxc_dxtn as well. This may be necessary to get nice textures in some apps, and some others even require this to run. I couldn't see a USE flag, which is what I was expecting for enabling S3TC support and pulling in media-libs/libtxc_dxtn as a dependency. So I emerged media-libs/libtxc_dxtn manually. Is this how it is meant to be, or is there a USE flag missing from mesa? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: zoom?
On 2020-04-01, William Kenworthy wrote:
> On 1/4/20 4:55 pm, Neil Bothwick wrote:
>> On Wed, 1 Apr 2020 09:12:46 +0800, William Kenworthy wrote:
>>
>>> [blocks B ] media-libs/mesa[-libglvnd(-)]
>>> ("media-libs/mesa[-libglvnd(-)]" is blocking media-libs/libglvnd-1.3.1)
>> It looks like you need to emerge mesa with USE="libglvnd".
>
> no, there is something else at play - I have tried adding it to
> package.accept_keywords, package.provided etc. but they fail. If I use
> --nodeps it wants to overwrite a number of mesa files so I am thinking
> its not actually needed.
Any chance it is the libglvnd USE flag that is masked?
--
Nuno Silva
[gentoo-user] mesa downgrade wont compile
Hi,
During a recent upgrade of my system mesa wanted to upgrade to version
7.2 which wanted to bring in a number of masked dependencies. After
checking my system it appears there is nothing on here requiring a
version number higher then 6.5 which is the latest stable build. I
tried removing mesa from my package.keywords file and emerging it
again. The upgrade (downgrade to version 6.5.2-r1) fails to build with
the following output (trimmed for this email if you need more let me
know).
../common/dri_bufmgr.c: In function 'driBOWaitIdle':
../common/dri_bufmgr.c:196: error: 'DriBufferPool' has no member named
'waitIdle'
../common/dri_bufmgr.c: In function 'driBOData':
../common/dri_bufmgr.c:291: error: 'DRM_BO_FLAG_WRITE' undeclared
(first use in this function)
../common/dri_bufmgr.c:292: error: 'DRM_BO_HINT_DONT_BLOCK' undeclared
(first use in this function)
../common/dri_bufmgr.c: In function 'driBOSubData':
../common/dri_bufmgr.c:322: error: 'DRM_BO_FLAG_WRITE' undeclared
(first use in this function)
../common/dri_bufmgr.c: In function 'driBOGetSubData':
../common/dri_bufmgr.c:338: error: 'DRM_BO_FLAG_READ' undeclared
(first use in this function)
../common/dri_bufmgr.c: In function 'driBOSetStatic':
../common/dri_bufmgr.c:357: error: 'DriBufferPool' has no member named
'setstatic'
../common/dri_bufmgr.c:366: error: 'DriBufferPool' has no member named
'setstatic'
../common/dri_bufmgr.c: In function 'driGenBuffers':
../common/dri_bufmgr.c:388: error: 'DRM_BO_FLAG_MEM_TT' undeclared
(first use in this function)
../common/dri_bufmgr.c:388: error: 'DRM_BO_FLAG_MEM_VRAM' undeclared
(first use in this function)
../common/dri_bufmgr.c:389: error: 'DRM_BO_FLAG_MEM_LOCAL' undeclared
(first use in this function)
../common/dri_bufmgr.c:389: error: 'DRM_BO_FLAG_READ' undeclared
(first use in this function)
../common/dri_bufmgr.c:389: error: 'DRM_BO_FLAG_WRITE' undeclared
(first use in this function)
../common/dri_bufmgr.c: At top level:
../common/dri_bufmgr.c:431: error: expected declaration specifiers or
'...' before 'drmBOList'
../common/dri_bufmgr.c: In function 'driBOCreateList':
../common/dri_bufmgr.c:434: error: 'list' undeclared (first use in
this function)
../common/dri_bufmgr.c: At top level:
../common/dri_bufmgr.c:439: error: expected ')' before '*' token
../common/dri_bufmgr.c:447: error: expected ')' before '*' token
../common/dri_bufmgr.c:481: error: expected declaration specifiers or
'...' before 'drmBOList'
../common/dri_bufmgr.c: In function 'driBOValidateList':
../common/dri_bufmgr.c:484: error: 'list' undeclared (first use in
this function)
../common/dri_bufmgr.c: In function 'driPoolTakeDown':
../common/dri_bufmgr.c:491: error: 'struct _DriBufferPool' has no
member named 'takeDown'
make[6]: *** [../common/dri_bufmgr.o] Error 1
make[6]: Leaving directory
`/var/tmp/portage/media-libs/mesa-6.5.2-r1/work/Mesa-6.5.2/src/mesa/drivers/dri/i915tex'
make[5]: *** [subdirs] Error 1
make[5]: Leaving directory
`/var/tmp/portage/media-libs/mesa-6.5.2-r1/work/Mesa-6.5.2/src/mesa/drivers/dri'
make[4]: *** [linux-solo] Error 2
make[4]: Leaving directory
`/var/tmp/portage/media-libs/mesa-6.5.2-r1/work/Mesa-6.5.2/src/mesa'
make[3]: *** [default] Error 2
make[3]: Leaving directory
`/var/tmp/portage/media-libs/mesa-6.5.2-r1/work/Mesa-6.5.2/src/mesa'
make[2]: *** [subdirs] Error 1
make[2]: Leaving directory
`/var/tmp/portage/media-libs/mesa-6.5.2-r1/work/Mesa-6.5.2/src'
make[1]: *** [default] Error 1
make[1]: Leaving directory
`/var/tmp/portage/media-libs/mesa-6.5.2-r1/work/Mesa-6.5.2'
make: *** [linux-dri-x86] Error 2
ERROR: media-libs/mesa-6.5.2-r1 failed.
Call stack:
ebuild.sh, line 49: Called src_compile
environment, line 2462: Called die
The specific snippet of code:
emake -j1 ${CONFIG} || die Build failed
The die message:
Build failed
If you need support, post the topmost build error, and the call stack
if relevant.
A complete build log is located at
'/var/tmp/portage/media-libs/mesa-6.5.2-r1/temp/build.log'.
The ebuild environment file is located at
'/var/tmp/portage/media-libs/mesa-6.5.2-r1/temp/environment'.
I tried to google and check the forums for answers but turned up
nothing if anyone can offer me some insight it would be greatly
appreciated. Thanks in advance
AJ
Re: [gentoo-user] Can't compile media-libs/mesa - do I need gallium?
On Mon, Jul 17, 2017 at 01:43:46AM +0100, Stroller wrote > This system is headless, but I have x11-wm/xpra installed on it so I can run > X11 apps remotely. > > Recent emerges of world have been failing at media-libs/mesa > > Currently I have mesa-13.0.5 installed; I have this problem with mesa-17.0.6 > (current stable) and mesa-17.1.4 (latest in the tree when I tried this a few > days ago). > > The error says I should post this if I need support: > > $ emerge -pqv '=media-libs/mesa-17.0.6::gentoo' > [ebuild U ] media-libs/mesa-17.0.6 [13.0.5] USE="classic dri3 egl gallium > gbm llvm nptl -bindist -d3d9 -debug -gles1 -gles2 -opencl -openmax -osmesa > -pax_kernel -pic (-selinux) -vaapi -valgrind -vdpau -vulkan -wayland -xa > -xvmc (-gcrypt%) (-libressl%) (-nettle%*) (-openssl%*)" ABI_X86="(64) -32 > (-x32)" VIDEO_CARDS="(-freedreno) -i915 -i965 -imx% -intel -nouveau -r100 > -r200 -r300 -r600 -radeon -radeonsi (-vc4) (-vivante) -vmware" > The build.log doesn't point me towards any obvious solutions, or > maybe I just don't know how to read it. > > All I can make out is that it's a problem with gallium. The current > version of mesa appears to have gallium enabled, though. > > I know nothing about mesa, not even really what it's for, so I don't > know if I should just try disabling gallium and trying again. I've got 17.0.6 building and running fine, under GCC 6.3.0 (YES !), without gallium. I suggest trying "-gallium" in make.conf. Here's my mesa "pretend build" output... [ebuild R] media-libs/mesa-17.0.6::gentoo USE="bindist classic dri3 egl gbm gles2 nptl -d3d9 -debug -gallium -gles1 -llvm -opencl -openmax -osmesa -pax_kernel -pic (-selinux) -vaapi -valgrind -vdpau -vulkan -wayland -xa -xvmc" VIDEO_CARDS="i915 intel (-freedreno) -i965 -imx -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) (-vivante) -vmware" 0 KiB -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Can't compile media-libs/mesa - do I need gallium?
Hello, > undefined reference to > `llvm::RTDyldMemoryManager::getSymbolAddressInProcess(std::__cxx11::basic_string > , std::allocator > const&)' Seems to be the error, maybe you have to recompile llvm with c++11 Regards, Rasmus Original Message On 17 Jul 2017, 02:43, Stroller wrote: > This system is headless, but I have x11-wm/xpra installed on it so I can run > X11 apps remotely. > > Recent emerges of world have been failing at media-libs/mesa > > Currently I have mesa-13.0.5 installed; I have this problem with mesa-17.0.6 > (current stable) and mesa-17.1.4 (latest in the tree when I tried this a few > days ago). > > The error says I should post this if I need support: > > $ emerge -pqv '=media-libs/mesa-17.0.6::gentoo' > [ebuild U ] media-libs/mesa-17.0.6 [13.0.5] USE="classic dri3 egl gallium gbm > llvm nptl -bindist -d3d9 -debug -gles1 -gles2 -opencl -openmax -osmesa > -pax_kernel -pic (-selinux) -vaapi -valgrind -vdpau -vulkan -wayland -xa > -xvmc (-gcrypt%) (-libressl%) (-nettle%*) (-openssl%*)" ABI_X86="(64) -32 > (-x32)" VIDEO_CARDS="(-freedreno) -i915 -i965 -imx% -intel -nouveau -r100 > -r200 -r300 -r600 -radeon > -radeonsi (-vc4) (-vivante) -vmware" > $ > > The build.log doesn't point me towards any obvious solutions, or maybe I just > don't know how to read it. > > All I can make out is that it's a problem with gallium. The current version > of mesa appears to have gallium enabled, though. > > I know nothing about mesa, not even really what it's for, so I don't know if > I should just try disabling gallium and trying again. > > I'm grateful for any thoughts, > > Stroller. > > Tail end of /var/tmp/portage/media-libs/mesa-17.0.6/temp/build.log follows: > > /bin/sh ../../../../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ > -march=native -O2 -pipe -Wall -fno-math-errno -fno-trapping-math -shared > -shrext .so -module -no-undefined -avoid-version -Wl,--gc-sections > -Wl,--no-undefined > -Wl,--version-script=/var/tmp/portage/media-libs/mesa-17.0.6/work/mesa-17.0.6/src/gallium/targets/dri/dri.sym > > -Wl,--dynamic-list=/var/tmp/portage/media-libs/mesa-17.0.6/work/mesa-17.0.6/src/gallium/targets/dri-vdpau.dyn > -L/usr/lib64 -Wl,-O1 -Wl,--as-needed -o gallium_dri.la -rpath /usr/lib64/dri > gallium_dri_la-target.lo ../../../../src/mesa/libmesagallium.la > ../../../../src/mesa/drivers/dri/common/libdricommon.la > ../../../../src/mesa/drivers/dri/common/libmegadriver_stub.la > ../../../../src/gallium/state_trackers/dri/libdri.la > ../../../../src/gallium/auxiliary/libgalliumvl.la > ../../../../src/gallium/auxiliary/libgallium.la > ../../../../src/gallium/drivers/ddebug/libddebug.la > ../../../../src/gallium/drivers/noop/libnoop.la > ../../../../src/gallium/drivers/rbug/librbug.la > ../../../../src/gallium/drivers/trace/libtrace.la > ../../../../src/mapi/shared-glapi/libglapi.la -lexpat -ldrm -lm -lpthread > -ldl -ldrm > ../../../../src/gallium/auxiliary/pipe-loader/libpipe_loader_static.la > ../../../../src/gallium/winsys/sw/null/libws_null.la > ../../../../src/gallium/winsys/sw/wrapper/libwsw.la > ../../../../src/gallium/winsys/sw/dri/libswdri.la > ../../../../src/gallium/winsys/sw/kms-dri/libswkmsdri.la -ldrm > ../../../../src/gallium/drivers/softpipe/libsoftpipe.la > ../../../../src/gallium/drivers/llvmpipe/libllvmpipe.la -lLLVMX86Disassembler > -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter > -lLLVMDebugInfoCodeView -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine > -lLLVMInstrumentation -lLLVMTransformUtils -lLLVMX86Desc -lLLVMMCDisassembler > -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT > -lLLVMExecutionEngine -lLLVMTarget -lLLVMRuntimeDyld -lLLVMObject > -lLLVMMCParser -lLLVMBitReader -lLLVMMC -lLLVMBitWriter -lLLVMAnalysis > -lLLVMProfileData -lLLVMCore -lLLVMSupport > libtool: link: x86_64-pc-linux-gnu-g++ -fPIC -DPIC -shared -nostdlib > /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../lib64/crti.o > /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/crtbeginS.o > .libs/gallium_dri_la-target.o -Wl,--whole-archive > ../../../../src/mesa/.libs/libmesagallium.a > ../../../../src/mesa/drivers/dri/common/.libs/libdricommon.a > ../../../../src/mesa/drivers/dri/common/.libs/libmegadriver_stub.a > ../../../../src/gallium/state_trackers/dri/.libs/libdri.a > ../../../../src/gallium/auxiliary/.libs/libgalliumvl.a > ../../../../src/gallium/auxiliary/.libs/libgallium.a > ../../../../src/gallium/drivers/ddebug/.libs/libddebug.a > ../../../../src/gallium/drivers/noop/.libs/libnoop.a > ../../../../src/gallium/drivers/rbug/.libs/librbug.a > ../../../../src/gallium/drivers/trace/.libs/libtrace.a >
[gentoo-user] Can't compile media-libs/mesa - do I need gallium?
This system is headless, but I have x11-wm/xpra installed on it so I can run X11 apps remotely. Recent emerges of world have been failing at media-libs/mesa Currently I have mesa-13.0.5 installed; I have this problem with mesa-17.0.6 (current stable) and mesa-17.1.4 (latest in the tree when I tried this a few days ago). The error says I should post this if I need support: $ emerge -pqv '=media-libs/mesa-17.0.6::gentoo' [ebuild U ] media-libs/mesa-17.0.6 [13.0.5] USE="classic dri3 egl gallium gbm llvm nptl -bindist -d3d9 -debug -gles1 -gles2 -opencl -openmax -osmesa -pax_kernel -pic (-selinux) -vaapi -valgrind -vdpau -vulkan -wayland -xa -xvmc (-gcrypt%) (-libressl%) (-nettle%*) (-openssl%*)" ABI_X86="(64) -32 (-x32)" VIDEO_CARDS="(-freedreno) -i915 -i965 -imx% -intel -nouveau -r100 -r200 -r300 -r600 -radeon -radeonsi (-vc4) (-vivante) -vmware" $ The build.log doesn't point me towards any obvious solutions, or maybe I just don't know how to read it. All I can make out is that it's a problem with gallium. The current version of mesa appears to have gallium enabled, though. I know nothing about mesa, not even really what it's for, so I don't know if I should just try disabling gallium and trying again. I'm grateful for any thoughts, Stroller. Tail end of /var/tmp/portage/media-libs/mesa-17.0.6/temp/build.log follows: /bin/sh ../../../../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -march=native -O2 -pipe -Wall -fno-math-errno -fno-trapping-math -shared -shrext .so -module -no-undefined -avoid-version -Wl,--gc-sections -Wl,--no-undefined -Wl,--version-script=/var/tmp/portage/media-libs/mesa-17.0.6/work/mesa-17.0.6/src/gallium/targets/dri/dri.sym -Wl,--dynamic-list=/var/tmp/portage/media-libs/mesa-17.0.6/work/mesa-17.0.6/src/gallium/targets/dri-vdpau.dyn -L/usr/lib64 -Wl,-O1 -Wl,--as-needed -o gallium_dri.la -rpath /usr/lib64/dri gallium_dri_la-target.lo ../../../../src/mesa/libmesagallium.la ../../../../src/mesa/drivers/dri/common/libdricommon.la ../../../../src/mesa/drivers/dri/common/libmegadriver_stub.la ../../../../src/gallium/state_trackers/dri/libdri.la ../../../../src/gallium/auxiliary/libgalliumvl.la ../../../../src/gallium/auxiliary/libgallium.la ../../../../src/gallium/drivers/ddebug/libddebug.la ../../../../src/gallium/drivers/noop/libnoop.la ../../../../src/gallium/drivers/rbug/librbug.la ../../../../src/gallium/drivers/trace/libtrace.la ../../../../src/mapi/shared-glapi/libglapi.la -lexpat -ldrm -lm -lpthread -ldl -ldrm ../../../../src/gallium/auxiliary/pipe-loader/libpipe_loader_static.la ../../../../src/gallium/winsys/sw/null/libws_null.la ../../../../src/gallium/winsys/sw/wrapper/libwsw.la ../../../../src/gallium/winsys/sw/dri/libswdri.la ../../../../src/gallium/winsys/sw/kms-dri/libswkmsdri.la -ldrm ../../../../src/gallium/drivers/softpipe/libsoftpipe.la ../../../../src/gallium/drivers/llvmpipe/libllvmpipe.la -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMDebugInfoCodeView -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMInstrumentation -lLLVMTransformUtils -lLLVMX86Desc -lLLVMMCDisassembler -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMTarget -lLLVMRuntimeDyld -lLLVMObject -lLLVMMCParser -lLLVMBitReader -lLLVMMC -lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMCore -lLLVMSupport libtool: link: x86_64-pc-linux-gnu-g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/5.4.0/crtbeginS.o .libs/gallium_dri_la-target.o -Wl,--whole-archive ../../../../src/mesa/.libs/libmesagallium.a ../../../../src/mesa/drivers/dri/common/.libs/libdricommon.a ../../../../src/mesa/drivers/dri/common/.libs/libmegadriver_stub.a ../../../../src/gallium/state_trackers/dri/.libs/libdri.a ../../../../src/gallium/auxiliary/.libs/libgalliumvl.a ../../../../src/gallium/auxiliary/.libs/libgallium.a ../../../../src/gallium/drivers/ddebug/.libs/libddebug.a ../../../../src/gallium/drivers/noop/.libs/libnoop.a ../../../../src/gallium/drivers/rbug/.libs/librbug.a ../../../../src/gallium/drivers/trace/.libs/libtrace.a ../../../../src/gallium/auxiliary/pipe-loader/.libs/libpipe_loader_static.a ../../../../src/gallium/winsys/sw/null/.libs/libws_null.a ../../../../src/gallium/winsys/sw/wrapper/.libs/libwsw.a ../../../../src/gallium/winsys/sw/dri/.libs/libswdri.a ../../../../src/gallium/winsys/sw/kms-dri/.libs/libswkmsdri.a ../../../../src/gallium/drivers/softpipe/.libs/libsoftpipe.a ../../../../src/gallium/drivers/llvmpipe/.libs/libllvmpipe.a -Wl,--no-whole-archive -Wl,-rpath -Wl,/var/tmp/portage/media-libs/mesa-17.0.6/work/mesa-17.0.6-abi_x86_64.amd64/src/mapi/shared-glapi/.libs -L/usr/lib64 ../../../../src/mapi/shared-glapi/.libs/libglapi.so -lpthread -ldl -lexpat -ldrm -lLLVMX86D
Re: [gentoo-user] new box DRI problem : more
Philip Webb wrote: Unrecognised deviceID 29c2 backtrace ... ... /usr/lib64/dri/i915_dri.so ... (provided by pkg 'mesa') What versions of Mesa and xf86-video-i810 are you running? And what is in the Section Device of your /etc/X11/xorg.conf? Benno -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] 000299 !!! ERROR: media-libs/mesa-6.4.1-r1 failed.
On 12/19/05, Richard Fish [EMAIL PROTECTED] wrote: I am not sure, but I think you need to merge x11-proto/glproto Also, media-libs/mesa-6.4.1-r1 (the ~x86 version) already has this dependancy. Which version are you trying to merge? -Richard -- gentoo-user@gentoo.org mailing list
[gentoo-user] xorg-x11 upgrade problems (mesa-progs-6.4.2)
I've overcome a few hiccups along the way, but this one has me stumped. Out of sheer curiousity, why is -ffast-math being invoked? I do *NOT* have it in my CFLAGS. ld's problem seems to be cannot find -lGL. Does that help? Emerging (1 of 10) x11-apps/mesa-progs-6.4.2 to / checking ebuild checksums ;-) checking auxfile checksums ;-) checking miscfile checksums ;-) checking MesaLib-6.4.2.tar.bz2 ;-) checking MesaDemos-6.4.2.tar.bz2 ;-) Unpacking source... Unpacking MesaLib-6.4.2.tar.bz2 to /var/tmp/portage/mesa-progs-6.4.2/work Unpacking MesaDemos-6.4.2.tar.bz2 to /var/tmp/portage/mesa-progs-6.4.2/work Source unpacked. Compiling source in /var/tmp/portage/mesa-progs-6.4.2/work/Mesa-6.4.2 ... i686-pc-linux-gnu-gcc -I../../include -Wall -O2 -pipe -fomit-frame-pointer -march=athlon -m3dnow -mmmx -msse -msse2 -mfpmath=sse -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -std=c99 -ffast-math glxinfo.c -L../../lib -lglut -lGLU -lGL -lm -o glxinfo /usr/lib/gcc/i686-pc-linux-gnu/3.4.6/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lGL collect2: ld returned 1 exit status make: *** [glxinfo] Error 1 !!! ERROR: x11-apps/mesa-progs-6.4.2 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile mesa-progs-6.4.2.ebuild, line 68: Called die !!! glxinfo failed !!! If you need support, post the topmost build error, and the call stack if relevant. -- Walter Dnes [EMAIL PROTECTED] In linux /sbin/init is Job #1 My musings on technology and security at http://tech_sec.blog.ca -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Update xorg-x11
Juliano Morais Barbosa wrote: Emerging (1 of 1) media-libs/mesa-6.4.2-r2 to / Creating Manifest for /usr/portage/media-libs/mesa Remove digest and assume-digests from your FEATURES. Those are meant for developers. You are undoing emerge's security check. And please don't top post. Benno -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] mesa build failure
On Fri, Jun 26, 2009 at 10:16 AM, Mark Knechtmarkkne...@gmail.com wrote: As part of emerge @world mesa isn't building. It complains (I think) about a missing GL/glxproto.h file. Anyone know where this file is supposed to come from? x11-proto/glproto perhaps
Re: [gentoo-user] mesa build failure
On Fri, Jun 26, 2009 at 11:04 AM, Mark Knechtmarkkne...@gmail.com wrote: so is this a mistake in the ebuild? Why isn't it picking it up automatically? I seemed to already have the package installed: What is your eselect opengl set to? Maybe try setting it to xorg-x11 if it's not already, then emerge mesa, then change it back to your other driver afterward.
Re:Re: [gentoo-user] Who can tell me relationship among dri,glx,mesa,xorg?
About Mesa: http://www.mesa3d.org/intro.html About DRI: http://dri.freedesktop.org/wiki/ -- Andrés Becerra Sandoval Thanks, the web pages you provided I have already read before, these don't seem to provide helpful issues for my questions.
Re: [gentoo-user] xorg.conf tweaks for HTPC machine?
Walter's Excellent Adventure Chapter 2 On Tue, Dec 18, 2012 at 03:17:59AM -0500, Walter Dnes wrote I ran emerge -pv mesa, and discovered that mesa had been merged with USE=-xorg. This is what I get for starting USE with -*... http://media.comicvine.com/uploads/11/117774/2361934-double_facepalm.jpg I emerged mesa with xorg USE flag, and 1366x768 now works fine. One problem down and one to go. I had merged mesa with the intel USE flag. It also has i915 and i965 USE flags. If I can get the i965 driver built, I'd go from software acceleration to hardware acceleration. That's my next step. Now things start to get *REALLY* weird. * Using VIDEO_CARDS=i965 in make.conf enables DRI2 hardware acceleration * But it requires the classic USE flag for mesa * The xorg USE flag also makes mesa require the gallium USE flag * Building mesa with *BOTH* classic and gallium works * And it runs in 1366x768 mode * And it runs *ONLY* in 1366x768 mode. xrandr does not change the resolution, notwithstanding the gazillion modes it lists * I went back to mesa without the xorg and gallium flags to simplify my setup * Again, it runs 1366x768, and *ONLY* 1366x768. But it does have hardware acceleration * And yes, I did try replacing the xf86-video-intel driver with xf86-video-modesetting. No X. * So the one change I've made after all this fooling around is to change the VIDEO_CARDS setting in make.conf from intel to i965. The net change is that... * the TV displays in native 1366x768 mode, and *ONLY* 1366x768 mode * X now has hardware acceleration -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-user] [~amd64] Does the EGL useflag break mesa-progs-8.2.0?
Normally I would just file a bug report, but lately portage has been behaving so strangely I feel obligated to ask here first. Maybe you won't see what I see. Just try emerging mesa-progs-8.2.0 with the EGL useflag set.
[gentoo-user] portage-utils-0.61 Bug or feature?
After today's update from 0.60 to 0.61 I noticed that the behavior of qlop changed. Until today the command 'qlop -l' lists every package in /var/log/emerge.log in chronological order. Today 'qlop -l' lists nothing unless you supply an argument, e.g. 'qlop -l mesa', which lists every package with the string mesa in the name. Is this change deliberate? (If so, I vote against it :)
Re: [gentoo-user] x11-proto/dri2proto masked but still needed by media-libs/mesa
On mar. 12 juin 08:44:51 2018, Neil Bothwick wrote: > It sounds like this bug https://bugs.gentoo.org/657832 > > If it is, re-emerging mesa should fix it. Indeed, after recompiling it I was able to remove those packages with a --depclean. Thanks a lot! -- alarig signature.asc Description: PGP signature
Re: [gentoo-user] new box DRI problem : more
Philip Webb wrote: 071029 Benno Schulenberg wrote: What versions of Mesa and xf86-video-i810 are you running? 'mesa-progs-6.5.2' (latest available). Get the one from testing, 7.0.1. But what you need is media-libs/mesa; mesa-progs is just glxinfo/glxgears. 'xf86-video-i810-2.1.0' ( 2.1.1 is in testing (~)). Get the newest one, as there's much development in the intel driver. Section Device [...] Driver intel Looks good. I tried permutations of Options suggested on Forum posts without success (I haven't asked on the Forum myself): eg adding 'Option DRI true', which seems merely to duplicate Accel above. The man page of i810 says only NoAccel and DRI exist, and both default to use it, so your settings don't change anything. I am a bit confused by the requirement for 2 drivers i810 i915 . The same dir has i810_dri.so i915tex_dri.so i965_dri.so (all from Mesa). Is it using the wrong driver ? No, it should auto-detect which of those drivers it needs. It's just that your lib is too old for the newer G33, Benno -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] scrapping hal
On Thursday 28 October 2010 13:35:49 Alan McKinnon wrote: xorg-server 1.8 and 1.9 use mesa-7.8.2, and there's reports around that that version of mesa causes desktop slowdowns. mesa-7.7.1 as used by xorg- server-1.7 is reported to be fine This box has been the most sluggish box I've ever seen for several months now. Mesa-7.7.1 was not fine here - or something else wasn't. Me, I'm undecided. I have a slow sluggish desktop, but it might be the nvidia drivers, mesa, X-server, kernel config, wrong elevator or even just the shitty IO scheduler design on desktops that the kernel devs are recently waking up to admitting to. Lots of stuff to change one at a time and see what results... Puzzling, innit? -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Gallium and nVidia
On 29/07/2013 17:38, András Csányi wrote: Hi All, I would like to some clarification to support my feeling regarding gallium related use flags in mesa package. For some reason I have to rebuild a few packages on my machine and xorg-server and mesa are among them. I experienced that if the xorg USE flag of mesa is enabled then I got compiling error. After a little searching I could see that this use flag enables gallium3d. My question is that, as a nvidia user - I have an nvidia card and I use a nvidia driver from nvidia-drivers package - do I need this use flag? Do I need the gallium related use flags in mesa? Thanks in advance for any help! András Don't use gallium with nVidia's proprietary driver. Gallium is the architecture used by mesa for all open source 3D drivers (intel, radeon, nouveau, etc). nVidia bypasses all of that and does their own thing. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] problem emerging Libdrm : solved
On Sunday 25 January 2015 23:57:50 Philip Webb wrote:
150125 Philip Webb wrote:
After exactly 2 years , I'm trying to update my Asus EEE netbook.
Trying to update gtk+ , I've run into a problem :
it requires Mesa Cairo both require libdrm-2.4.58 ,
which refuses to compile, failing with lines reporting
that libpng15.so.15 libudev.so.0 not found.
I've already updated to libpng-1.6.16 , so libpng16.so.16 is installed.
Thanks for the various suggestions.
I solved the problem by unmerging Gtk+ Mesa Cairo Libdrm Xorg-server,
after which Libdrm compiled successfully.
BTW there's a rather bizarre dependency :
the stable Mesa-10.2.8 requires the testing Cairo-1.12.18 .
I've never seen this before.
It's not like that here; something must still be skew-whiff:
prh@wstn ~ $ eix -Ice mesa
[I] media-libs/mesa (10.2.8{tbz2}@28/12/14): OpenGL-like graphic library for
Linux
prh@wstn ~ $ eix -Ice cairo
[I] x11-libs/cairo (1.12.16@22/11/14): A vector graphics library with
cross-device output support
This is amd64.
--
Rgds
Peter.
[gentoo-user] OpenGL problem after upgrading mesa and xorg-server
Since I've upgraded mesa (12.0.1 to 13.0.5) and xorg-server (1.18.4 to 1.19.2), OpenGL programs don't work any longer for non-root users, even when these users are members of the group "video". The USE flags for xorg-server: doc glamor ipv6 kdrive suid udev xorg xvfb mesa: classic dri3 egl gallium gbm gcrypt gles2 llvm nettle nptl opencl openmax osmesa pax_kernel pic vaapi vdpau wayland xa xvmc I'm using gentoo hardened kernel (4.8.17-hardened-r2). This is the error message: user@puter ~ $ glxgears libGL error: MESA-LOADER: failed to retrieve device information libGL error: image driver extension not found libGL error: failed to load driver: radeon libGL error: MESA-LOADER: failed to retrieve device information unknown chip id 0x683f, can't guess. libGL error: failed to create dri screen libGL error: failed to load driver: radeon As root, everything works fine. I searched the web and also read the gentoo xserver wiki but couldn't find a solution. -- Regards wabe
Re: [gentoo-user] Re: mesa build failure
On Mon, Nov 27, 2017 at 10:52:05PM +0200, Alan McKinnon wrote > On 27/11/2017 21:59, Ian Zimmerman wrote: > > On 2017-11-27 21:07, Alan McKinnon wrote: > > > >> mesa has 18 versions in-tree and mesa-17.1.8 is the second oldest. Any > >> special reason you are stuck so far back? A package.mask you no longr > >> actually need maybe? > > > > All the later ones are ~arch ? > > > > what I typed is incomplete, sorry about that: > > mesa-17.1.8 is the second oldest ~arch version I just noticed something interesting. 13.0.5 and 17.0.6 are stable for both x86 and amd64. 17.1.8 is stable for x86 (this machine), but not for amd64. I wonder if I should simply remove "-fopenmp" from flags in make.conf. It's been causing problems for python as well as for mesa. -- Walter Dnes <waltd...@waltdnes.org> I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] zoom?
On 1/4/20 4:55 pm, Neil Bothwick wrote:
> On Wed, 1 Apr 2020 09:12:46 +0800, William Kenworthy wrote:
>
>> [blocks B ] media-libs/mesa[-libglvnd(-)]
>> ("media-libs/mesa[-libglvnd(-)]" is blocking media-libs/libglvnd-1.3.1)
> It looks like you need to emerge mesa with USE="libglvnd".
>
>
Hi Neil,
no, there is something else at play - I have tried adding it to
package.accept_keywords, package.provided etc. but they fail. If I use
--nodeps it wants to overwrite a number of mesa files so I am thinking
its not actually needed.
Trying to install just zoom and its deps without the --nodeps flag for
each package - working so far but I cant tell until qtwebengine finishes
compiling ... hopefully before Easter :)
I am hoping that mesa will supply the files and libglvnd is not needed
and the ebuild just needs fixing.
I thought someone else must have run across this already?
BillK
signature.asc
Description: OpenPGP digital signature
[gentoo-user] mesa build failure
Hi,
As part of emerge @world mesa isn't building. It complains (I
think) about a missing GL/glxproto.h file.
Anyone know where this file is supposed to come from?
Thanks,
Mark
checking expat.h presence... yes
checking for expat.h... yes
checking for XML_ParserCreate in -lexpat... yes
configure: creating ./config.status
config.status: creating configs/autoconf
config.status: executing configs commands
prefix: /usr
exec_prefix: ${prefix}
libdir: ${exec_prefix}/lib
includedir: ${prefix}/include
Driver: dri
OSMesa: no
DRI drivers: swrast radeon r200 r300
DRI driver dir: ${libdir}/dri
Use XCB: no
Shared libs: yes
Static libs: no
GLU: yes
GLw: no (Motif: no)
glut:no
Demos: no
CFLAGS: -O2 -march=i686 -fomit-frame-pointer -pipe
-ffast-math -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fno-strict-aliasing -fPIC
CXXFLAGS:-O2 -march=i686 -fomit-frame-pointer -pipe
-ffast-math -Wall -fno-strict-aliasing -fPIC
Macros: -D_GNU_SOURCE -DPTHREADS
-DHAVE_POSIX_MEMALIGN -DGLX_USE_TLS -DPTHREADS
-DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_INDIRECT_RENDERING
-DHAVE_ALIAS -DGLX_DIRECT_RENDERING
Run 'gmake' to build Mesa
make -j2
make[1]: Entering directory
`/var/tmp/portage/media-libs/mesa-7.3-r1/work/Mesa-7.3/src'
Making sources for autoconf
gmake[2]: Entering directory
`/var/tmp/portage/media-libs/mesa-7.3-r1/work/Mesa-7.3/src/glx/x11'
touch depend
/usr/bin/makedepend -fdepend
-I/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include
-I/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed -I.
-I../../../include -I../../../include/GL/internal -I../../../src/mesa
-I../../../src/mesa/glapi -I/usr/include/drm glcontextmodes.c
clientattrib.c compsize.c eval.c glxcmds.c glxcurrent.c glxext.c
glxextensions.c indirect.c indirect_init.c indirect_size.c
indirect_window_pos.c indirect_texture_compression.c
indirect_transpose_matrix.c indirect_vertex_array.c
indirect_vertex_program.c pixel.c pixelstore.c render2.c renderpix.c
single2.c singlepix.c vertarr.c xfont.c glx_pbuffer.c glx_query.c
drisw_glx.c dri_common.c dri_glx.c XF86dri.c glxhash.c dri2_glx.c
dri2.c \
../../../src/mesa/main/dispatch.c
../../../src/mesa/glapi/glapi.c
../../../src/mesa/glapi/glapi_getproc.c
../../../src/mesa/glapi/glthread.c
/usr/bin/makedepend: warning: clientattrib.c (reading glxclient.h,
line 54): cannot find include file GL/glxproto.h
not in GL/glxproto.h
not in GL/glxproto.h
not in /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/GL/glxproto.h
not in /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed/GL/glxproto.h
not in ./GL/glxproto.h
not in ../../../include/GL/glxproto.h
not in ../../../include/GL/internal/GL/glxproto.h
not in ../../../src/mesa/GL/glxproto.h
not in ../../../src/mesa/glapi/GL/glxproto.h
not in /usr/include/drm/GL/glxproto.h
not in /usr/include/GL/glxproto.h
/usr/bin/makedepend: warning: indirect.c, line 36: cannot find
include file GL/glxproto.h
not in /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/GL/glxproto.h
not in /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed/GL/glxproto.h
not in ./GL/glxproto.h
not in ../../../include/GL/glxproto.h
not in ../../../include/GL/internal/GL/glxproto.h
not in ../../../src/mesa/GL/glxproto.h
not in ../../../src/mesa/glapi/GL/glxproto.h
not in /usr/include/drm/GL/glxproto.h
not in /usr/include/GL/glxproto.h
/usr/bin/makedepend: warning: indirect_vertex_array.c, line 32:
cannot find include file GL/glxproto.h
not in /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/GL/glxproto.h
not in /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed/GL/glxproto.h
not in ./GL/glxproto.h
not in ../../../include/GL/glxproto.h
not in ../../../include/GL/internal/GL/glxproto.h
not in ../../../src/mesa/GL/glxproto.h
not in ../../../src/mesa/glapi/GL/glxproto.h
not in /usr/include/drm/GL/glxproto.h
not in /usr/include/GL/glxproto.h
/usr/bin/makedepend: warning: indirect_vertex_array.c (reading
indirect_vertex_array_priv.h, line 39): cannot find include file
GL/glxproto.h
not in /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/GL/glxproto.h
not in /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed/GL/glxproto.h
not in ./GL/glxproto.h
not in ../../../include/GL/glxproto.h
not in ../../../include/GL/internal/GL/glxproto.h
not in ../../../src/mesa/GL/glxproto.h
not in ../../../src/mesa/glapi/GL/glxproto.h
not in /usr/include/drm/GL/glxproto.h
not in /usr/include/GL/glxproto.h
/usr/bin/makedepend: warning
[gentoo-user] Odd Update Issue
Hi guys. I ran into this error while doing a full system update, and was wondering if there was a solution. -Begin Messajes Calculating dependencies .. .. done! [ebuild U ] media-libs/mesa-10.2.0.rcbled [10.0.4] USE equals comdriblec% comopenmax%was VIDEOCARDS equals nouveauinin radeoninin vmwareinin greater-than greater-than greater-than Verifying ebuild manifests greater-than greater-than greater-than Emerging (1 of 1) media-libs/mesa-10.2.0.rc433gentoo * MesaLib-10.2.0-rc44tarddbz2 SHA256 SHA512 WHIRLPOOL size ;com) ... Were ok ] greater-than greater-than greater-than Unpacking source... greater-than greater-than greater-than Unpacking MesaLib-10.2.0-rc44tarddbz2 to /var/tmp/portage/media-libs/mesa-10.2.0.rcbled/work greater-than greater-than greater-than Source unpacked in /var/tmp/portage/media-libs/mesa-10.2.0.rcbled/work greater-than greater-than greater-than Preparing source in /var/tmp/portage/media-libs/mesa-10.2.0.rcbled/work/Mesa-10.2.0-r cbled ... * Cannot find $EPATCHSOURCE! Value for $EPATCHSOURCE is: * * /usr/portage/media-libs/mesa/files/mesa-10.2-dont-require-llvm-fo r-r3004patch * were mesa-10.2-dont-require-llvm-for-r3004patch were * ERROR: media-libs/mesa-10.2.0.rc433gentoo failed (prepare phase): * Cannot find $EPATCHSOURCE! * * Call stack: * ebuildddsh, line 93: Called srcprepare * environment, line 4773: Called epatch '/usr/portage/media-libs/mesa/files/mesa-10.2-dont-require-llvm-f or-r3004patch' * environment, line 1849: Called die * The specific snippet of code: * die Cannot find backslash $EPATCHSOURCE!; * * If you need support, post the output of `emerge -info ' equals media-libs/mesa-10.2.0.rc433gentoo'`, * the complete build log and the output of `emerge compqv ' equals media-libs/mesa-10.2.0.rc433gentoo'`. * The complete build log is located at '/var/tmp/portage/media-libs/mesa-10.2.0.rcbled/temp/buildddlog'. * The ebuild environment file is located at '/var/tmp/portage/media-libs/mesa-10.2.0.rcbled/temp/environment' . * Working directory: '/var/tmp/portage/media-libs/mesa-10.2.0.rcbled/work/Mesa-10.2.0- rc4' * S: '/var/tmp/portage/media-libs/mesa-10.2.0.rcbled/work/Mesa-10.2.0- rc4' greater-than greater-than greater-than Failed to emerge media-libs/mesa-10.2.0.rcbled, Log file: greater-than greater-than greater-than '/var/tmp/portage/media-libs/mesa-10.2.0.rcbled/temp/buildddlog' * Messages for package media-libs/mesa-10.2.0.rcbled: * Cannot find $EPATCHSOURCE! Value for $EPATCHSOURCE is: * * /usr/portage/media-libs/mesa/files/mesa-10.2-dont-require-llvm-fo r-r3004patch * were mesa-10.2-dont-require-llvm-for-r3004patch were * ERROR: media-libs/mesa-10.2.0.rc433gentoo failed (prepare phase): * Cannot find $EPATCHSOURCE! * * Call stack: * ebuildddsh, line 93: Called srcprepare * environment, line 4773: Called epatch '/usr/portage/media-libs/mesa/files/mesa-10.2-dont-require-llvm-f or-r3004patch' * environment, line 1849: Called die * The specific snippet of code: * die Cannot find backslash $EPATCHSOURCE!; * * If you need support, post the output of `emerge -info ' equals media-libs/mesa-10.2.0.rc433gentoo'`, * the complete build log and the output of `emerge compqv ' equals media-libs/mesa-10.2.0.rc433gentoo'`. * The complete build log is located at '/var/tmp/portage/media-libs/mesa-10.2.0.rcbled/temp/buildddlog'. * The ebuild environment file is located at '/var/tmp/portage/media-libs/mesa-10.2.0.rcbled/temp/environment' . * Working directory: '/var/tmp/portage/media-libs/mesa-10.2.0.rcbled/work/Mesa-10.2.0- rc4' * S: '/var/tmp/portage/media-libs/mesa-10.2.0.rcbled/work/Mesa-10.2.0- rc4' Portage 2.2.10 (default/linux/xblehf/acj/desktop/gnome/systemd, gcc-4.7.3, glibc-2.19, 3.12.13-gentoo i686) equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals System Settings equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals equals System uname:Linux-3.12.13-gentoo-i686-Intel-R-_Celeron-R-_CPU_B800_@_1. 50GHz-with-gentoo-2.2 KiB Mem: 1916484 total, 196656 free KiB Swap: 524284 total, 505820 free Timestamp of tree: Tue, 27 May 2014 18:45:01 plus ld GNU ld (GNU Binutils) 2.24 app-shells
[gentoo-user] Re: Radeon KMS driver - what benefits?
On 11/22/2010 10:46 PM, Nikos Chantziaras wrote: On 11/22/2010 09:40 PM, Robin Atwood wrote: [...] Thanks, I would try that, but... # emerge -av media-libs/mesa These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] x11-libs/libX11-1.4.0 [1.3.6] USE=-doc -ipv6 -static-libs - test (-xcb%*) 2,036 kB [ebuild R ] media-libs/mesa-7.8.2 USE=nptl pic xcb -debug (-gallium) - motif (-selinux) VIDEO_CARDS=radeon -intel -mach64 -mga -nouveau -r128 - savage -sis -svga -tdfx -via 0 kB I set gallium in /etc/make.conf but (-gallium) means the flag is turned off in a profile somewhere? Oh, you're not on ~arch. I assumed to much. I don't know how that works on old versions of the drivers and Mesa, or whether Gallium3D was any good with old versions of Mesa. I can only confirm that it works on recent versions. Oops, please disregard. You're on ~arch too it seems. I'm using Mesa 7.9 from the x11 overlay. I think the Gallium3D driver (r300g) should work just fine (and actually better than Mesa Classic, r300c) even on Mesa 7.8.2, at least for R300 GPUs (Radeon 9xxx). I've no idea why it's masked; r300g is what upstream recommends and r300c isn't really worked on and is practically deprecated.
Re: [gentoo-user] Re: No HW acceleraton on radeon Mobility X300 with linux-2.6.36-r5, mesa-7.9, xorg-server-1.9.2 and video-ati-6.13.2
On 16 January 2011 22:30, Nikos Chantziaras rea...@arcor.de wrote: On 01/16/2011 05:18 PM, Daniel Tihelka wrote: Hallo, after update to 2.6.36-r5 kernel, xorg 1.9.2, mesa-7.9 and xf86-video- ati-6.13.2 (all from gentoo portage), the hw graphics acceleration stopped working. The problem seems to be in drm kernel module, as it is claimed by X.org (the part of X.org log): [...] And the kernel seems to use them (when started with boot options 'video=vesafb:ywrap,mtrr:3 vga=792') Remove the above and try this: video=vesafb:off radeon.modeset=1 radeon.dynpm=1 Building KMS related drivers in the kernel as opposed to selecting them as modules and removing framebuffer modules may also address the OP's problem (which I suspect is caused because KMS has not loaded *before* xorg starts). Then, try deleting your xorg.conf (if you have one) and do: eselect mesa set r300 gallium Also make sure that mesa is emerged with the video_cards_r300 USE flag enabled. video_cards_radeon is *not* enough. Your make.conf should probably contain this: VIDEO_CARDS=fbdev vesa radeon r300 Hmm ... unless this USE flag shows up in later versions or overlays, only radeon is available for mesa-7.9 # emerge -1aDv mesa These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/mesa-7.9 USE=classic gallium nptl -debug -gles -llvm -motif -pic (-selinux) VIDEO_CARDS=radeon -intel -mach64 -mga -nouveau -r128 -savage -sis -tdfx -via -vmware 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] No Quitting. -- Regards, Mick
Re: [gentoo-user] Re: No HW acceleraton on radeon Mobility X300 with linux-2.6.36-r5, mesa-7.9, xorg-server-1.9.2 and video-ati-6.13.2
On Monday 17 January 2011 18:30:02 Mick wrote: On 16 January 2011 22:30, Nikos Chantziaras rea...@arcor.de wrote: Then, try deleting your xorg.conf (if you have one) and do: eselect mesa set r300 gallium Also make sure that mesa is emerged with the video_cards_r300 USE flag enabled. video_cards_radeon is *not* enough. Your make.conf should probably contain this: VIDEO_CARDS=fbdev vesa radeon r300 Hmm ... unless this USE flag shows up in later versions or overlays, only radeon is available for mesa-7.9 # emerge -1aDv mesa These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/mesa-7.9 USE=classic gallium nptl -debug -gles -llvm -motif -pic (-selinux) VIDEO_CARDS=radeon -intel -mach64 -mga -nouveau -r128 -savage -sis -tdfx -via -vmware 0 kB Agree with Mick. I also did not find r300 USE flag. But see my previous answer, the issue seems to be solved now (mainly by removing framebuffer drivers from the kernel config). The correct (gallium) driver is built and used when mesa-7.9 is compiled with +radeon +gallium USE flags. Best regards, Dan T.
Re: [gentoo-user] Re: No HW acceleraton on radeon Mobility X300 with linux-2.6.36-r5, mesa-7.9, xorg-server-1.9.2 and video-ati-6.13.2
On Monday 17 January 2011 18:30:02 Mick wrote: On 16 January 2011 22:30, Nikos Chantziaras rea...@arcor.de wrote: Then, try deleting your xorg.conf (if you have one) and do: eselect mesa set r300 gallium Also make sure that mesa is emerged with the video_cards_r300 USE flag enabled. video_cards_radeon is not enough. Your make.conf should probably contain this: VIDEO_CARDS=fbdev vesa radeon r300 Hmm ... unless this USE flag shows up in later versions or overlays, only radeon is available for mesa-7.9 # emerge -1aDv mesa These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/mesa-7.9 USE=classic gallium nptl -debug -gles -llvm -motif -pic (-selinux) VIDEO_CARDS=radeon -intel -mach64 -mga -nouveau -r128 -savage -sis -tdfx -via -vmware 0 kB Agree with Mick. I also did not find r300 USE flag. But see my previous answer, the issue seems to be solved now (mainly by removing framebuffer drivers from the kernel config). The correct (gallium) driver is built and used when mesa-7.9 is compiled with +radeon +gallium USE flags. Best regards, Dan T.
Re:Re: [gentoo-user] Who can tell me relationship among dri,glx,mesa,xorg?
At 2011-12-15 03:24:20,Michael Schreckenbauer grim...@gmx.de wrote: Am Mittwoch, 14. Dezember 2011, 14:22:47 schrieb Lavender: Now I'm totally confused, I can't find helpful information from Internet. I know mesa is a open source implementation of OpenGL, obviously mesa will afford OpenGL API. DRI is short for Direct Rendering Infrastructure, I have chosen options like: Device Drivers --- Graphics support --- * Direct Rendering Manager --- this is DRM. This one manages allocation of memory for video devices. *ATI Radeon [*] Enable modesetting on radeon by default Does this mean that DRI libraries are built into kernel? No. If not, who contains DRI? Also who affords GLX libraries? Mesa or Xorg? DRI is part of mesa. Mesa also provides the GLX libraries. Best, Michael Thanks and I wish you could help answer this question.Now I know Mesa provides DRI and GLX, when I installed xorg-server,there're also libraries named like libdri.so and libglx.so in /etc/X11/(somewhere).What I don't understand is, why Xorg-server still provides its own DRI and GLX while Mesahas done this already?
Re: [gentoo-user] Who can tell me relationship among dri,glx,mesa,xorg?
Am Donnerstag, 15. Dezember 2011, 18:29:14 schrieb Lavender: At 2011-12-15 03:24:20,Michael Schreckenbauer grim...@gmx.de wrote: Am Mittwoch, 14. Dezember 2011, 14:22:47 schrieb Lavender: Now I'm totally confused, I can't find helpful information from Internet. I know mesa is a open source implementation of OpenGL, obviously mesa will afford OpenGL API. DRI is short for Direct Rendering Infrastructure, I have chosen options like: Device Drivers --- Graphics support --- * Direct Rendering Manager --- this is DRM. This one manages allocation of memory for video devices. *ATI Radeon [*] Enable modesetting on radeon by default Does this mean that DRI libraries are built into kernel? No. If not, who contains DRI? Also who affords GLX libraries? Mesa or Xorg? DRI is part of mesa. Mesa also provides the GLX libraries. Best, Michael Thanks and I wish you could help answer this question.Now I know Mesa provides DRI and GLX, when I installed xorg-server,there're also libraries named like libdri.so and libglx.so in /etc/X11/(somewhere). Yeah, I was wrong :) libglx and libdri are part of xorg-server. Best, Michael
Re: [gentoo-user] Can't compile media-libs/mesa - do I need gallium?
> On 17 Jul 2017, at 03:14, Walter Dnes <waltd...@waltdnes.org> wrote: > > On Mon, Jul 17, 2017 at 01:43:46AM +0100, Stroller wrote >> This system is headless, but I have x11-wm/xpra installed on it so I can run >> X11 apps remotely. >> >> Recent emerges of world have been failing at media-libs/mesa >> ... >> >> All I can make out is that it's a problem with gallium. The current >> version of mesa appears to have gallium enabled, though. >> >> I know nothing about mesa, not even really what it's for, so I don't >> know if I should just try disabling gallium and trying again. > > I've got 17.0.6 building and running fine, under GCC 6.3.0 (YES !), > without gallium. I suggest trying "-gallium" in make.conf. Here's my > mesa "pretend build" output... > > [ebuild R] media-libs/mesa-17.0.6::gentoo USE="bindist classic dri3 > egl gbm gles2 nptl -d3d9 -debug -gallium -gles1 -llvm -opencl -openmax > -osmesa -pax_kernel -pic (-selinux) -vaapi -valgrind -vdpau -vulkan -wayland > -xa -xvmc" VIDEO_CARDS="i915 intel (-freedreno) -i965 -imx -nouveau -r100 > -r200 -r300 -r600 -radeon -radeonsi (-vc4) (-vivante) -vmware" 0 KiB llvm depends on gallium, I think, as emerging with USE="-gallium" throws an error of that nature. Emerging with USE="-gallium -llvm" works, but I was pleased with the solution provided by IceAmber, as it allows me to update mesa with the default flags (i.e. with those enabled). Since I don't use X11 much I feel happier using the default flags wherever possible (irrational of me, perhaps), unless they pull in too many dependencies. I appreciate all the help, Stroller.
Re: [gentoo-user] X won't start after xorg-server update
Am 14.03.20 um 13:46 schrieb Neil Bothwick: On Sat, 14 Mar 2020 13:38:06 +0100, hitachi303 wrote: It seems that file is created/modified by the mesa ebuild. I would try removing the file and re-emerging mesa to see if it is created with the correct content. # mv -vi -- /etc/X11/xorg.conf.d/20opengl.conf . # emerge -av1 mesa mesa doesn't generate the file. So now there is NO file but X does start. I take it you don't have USE=libglvnd for mesa? Yes I do. Since I haven't defined it in my make.conf I guess it is defined by profile. # emerge -pv mesa # These are the packages that would be merged, in order: # Calculating dependencies... done! # [ebuild R] media-libs/mesa-19.3.5::gentoo USE="X classic dri3 egl gallium gbm gles2 libglvnd llvm -d3d9 -debug -gles1 -lm-sensors -opencl -osmesa -pax_kernel (-selinux) -test -unwind -vaapi -valgrind -vdpau -vulkan -vulkan-overlay -wayland -xa -xvmc" ABI_X86="32 (64) (-x32)" VIDEO_CARDS="radeon (-freedreno) -i915 -i965 -intel -iris (-lima) -nouveau (-panfrost) -r100 -r200 -r300 -r600 -radeonsi (-vc4) -virgl (-vivante) -vmware" 0 KiB
Re: [gentoo-user] Re: zoom?
On 1/4/20 10:26 pm, (Nuno Silva) wrote:
On 2020-04-01, William Kenworthy wrote:
On 1/4/20 4:55 pm, Neil Bothwick wrote:
On Wed, 1 Apr 2020 09:12:46 +0800, William Kenworthy wrote:
[blocks B ] media-libs/mesa[-libglvnd(-)]
("media-libs/mesa[-libglvnd(-)]" is blocking media-libs/libglvnd-1.3.1)
It looks like you need to emerge mesa with USE="libglvnd".
no, there is something else at play - I have tried adding it to
package.accept_keywords, package.provided etc. but they fail. If I use
--nodeps it wants to overwrite a number of mesa files so I am thinking
its not actually needed.
Any chance it is the libglvnd USE flag that is masked?
Looks like and ebuild/use flag problem (not a bug) in that Mesa is now
providing the dispatch services that libglvnd was providing - once the
Mesa version I have is installed, libglvng wont install as it wants to
overwrite some Mesa files. I am on a zoom conference at the moment :) -
so its working well except desktop share is only partially working so my
previous install method worked.
I'll raise a bug on it when I finish the zoom session.
BillK.
[gentoo-user] Re: compiz and mesa
Andrew Gaydenko wrote: compiz wants x11-libs/libX11[xcb] (even 0.8.2), and mesa 7.4_rc1 wants x11-libs/libX11[xcb=] (it's for current ~amd64). Does [xcb=] means without the flag? Tree bug? I don't know why it shows like this with you, but here it told me that that I had to remove the xcb USE flag from mesa. Instead of that, I simply globally enabled xcb in make.conf and disabled it only for cairo (the ebuild told me it's not a good idea to use xcb with cairo). So to make it short, put xcb in your USE flags in make.conf, and put: x11-libs/cairo -xcb in /etc/portage/package.use. Then emerge -auvDN world and you should be set.
[gentoo-user] Preventing a package from being updated
Hi, I am using the ~x86 (testing) version of gentoo linux. After recent updates, my X windows became extremely sluggish and I found out that the problem is related to a new version of mesa (7.8.2 specifically). So I downgraded to version 7.7.1 and my desktop works great again. Now I want to prevent mesa from being updated until this issue is sorted out upstream. I have looked at package.provide, but that didn't work. Currently, I have placed media-libs/mesa into my /etc/portage/package.mask file and this seems to do the trick. Is this the recommended way for handling this situation? Being a long time gentoo user, I want to do things the right way, so just working fine isn't enough :) -- Timur
Re: [gentoo-user] Heads Up - mesa-9.0 needs media-libs/glu in addition
On Tuesday 09 October 2012, Helmut Jarausch wrote: upgrading from mesa-9.0_pre20120918 to mesa-9.0 broke some package, among them ati-drivers. They have remove glu. Installing media-libs/glu in addition now (never needed it before) restores the essential /usr/include/GL/glu.h file. I found the same problem with KDE. media-libs/glu should become a dependency! -Robin -- -- Robin Atwood. Ship me somewheres east of Suez, where the best is like the worst, Where there ain't no Ten Commandments an' a man can raise a thirst from Mandalay by Rudyard Kipling --
Re: [gentoo-user] Heads Up - mesa-9.0 needs media-libs/glu in addition
On Wed, Oct 10, 2012 at 5:09 PM, Robin Atwood robin.atw...@attglobal.net wrote: On Tuesday 09 October 2012, Helmut Jarausch wrote: upgrading from mesa-9.0_pre20120918 to mesa-9.0 broke some package, among them ati-drivers. They have remove glu. Installing media-libs/glu in addition now (never needed it before) restores the essential /usr/include/GL/glu.h file. I found the same problem with KDE. media-libs/glu should become a dependency! -Robin If you don't file a bug it will never be ;) -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-user] xorg.conf tweaks for HTPC machine?
On Mon, Dec 17, 2012 at 07:34:22PM +0100, pk wrote On 2012-12-17 17:23, Walter Dnes wrote: snipped a whole lot... 1) Despite the TV being native 1366x768, it defaults to 1280x720, which is the first mode listed in the EDID. Fixed-pixel displays show best at their native resolution So I ran Xorg -configure and created an xorg.conf file, and forced 1366x768 resolution. And got no picture. I tried X again at 128x720. Then I used xrandr to change to 1920x1080, and it worked. Used xrandr to change to 1366x768, and it hung. From Xorg.0.log ... Any ideas? You can perhaps try to find out what the tv is telling X: x11-misc/read-edid ... if you haven't already tried it (you can also use startx -- -logverbose 6). The parsing of the EDID is already logged in gory detail in the logfile. You can also set your preferred resolution in xorg.conf as such: In Section Screen: Subsection Display ... Modes 1366x768 1280x720 ... EndSubSection After some spelunking in the X log file, I noticed the following [ 1789.561] (II) intel(0): [DRI2] Setup complete [ 1789.561] (II) intel(0): [DRI2] DRI driver: i965 [ 1789.561] (II) intel(0): direct rendering: DRI2 Enabled [ 1789.561] (--) RandR disabled [ 1789.566] (EE) AIGLX error: dlopen of /usr/lib64/dri/i965_dri.so failed (/usr /lib64/dri/i965_dri.so: cannot open shared object file: No such file or director y) [ 1789.566] (EE) AIGLX: reverting to software rendering [ 1789.566] (II) AIGLX: Screen 0 is not DRI capable [ 1789.671] (II) AIGLX: Loaded and initialized swrast [ 1789.671] (II) GLX: Initialized DRISWRAST GL provider for screen 0 lspci -v shows Kernel driver in use: i915 h. It wants i965, but it's getting i915. I took a look in /usr/lib64/dri/ to see what was and was not in there... [i3][root][~] ll -og /usr/lib64/dri/ total 30 drwxr-xr-x 2 216 Dec 18 01:57 . drwxr-xr-x 58 31024 Dec 18 01:34 .. -rw-r--r-- 1 0 Dec 14 17:57 .keep_media-libs_mesa-0 lrwxrwxrwx 120 Jan 8 2011 i915_dri.so - ../mesa/i915g_dri.so lrwxrwxrwx 120 Dec 14 17:57 i915g_dri.so - ../mesa/i915g_dri.so lrwxrwxrwx 122 Jan 8 2011 swrast_dri.so - ../mesa/swrastg_dri.so lrwxrwxrwx 122 Dec 14 17:57 swrastg_dri.so - ../mesa/swrastg_dri.so There's the i915g_dri.so driver; what package provides it? [i3][root][~] equery b i915g_dri.so * Searching for i915g_dri.so ... media-libs/mesa-9.0 (/usr/lib64/mesa/i915g_dri.so) media-libs/mesa-9.0 (/usr/lib64/dri/i915g_dri.so - ../mesa/i915g_dri.so) I ran emerge -pv mesa, and discovered that mesa had been merged with USE=-xorg. This is what I get for starting USE with -*... http://media.comicvine.com/uploads/11/117774/2361934-double_facepalm.jpg I emerged mesa with xorg USE flag, and 1366x768 now works fine. One problem down and one to go. I had merged mesa with the intel USE flag. It also has i915 and i965 USE flags. If I can get the i965 driver built, I'd go from software acceleration to hardware acceleration. That's my next step. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Re: mesa 9.1.2.r1 fails to build
In linux.gentoo.user, you wrote: The problem isn't obvious to me, but in the past I've seen strange linking errors happen when the ebuild (for some strange reason) uses the headers in /usr/include (from the previous version of the package) instead of the headers in the new source code. No idea why. Anyway, you could try removing your current mesa installation (after using quickpkg, of course) and then trying the emerge again. Sometimes when a package fails to build while doing an: emerge -auDN world I've had to add the '--with-bdeps=y' option: emerge -auDN --with-bdeps=y world For some reason I can't understand, it seems to work. It may not help with mesa-9.1.2-r1 but it doesn't take much effort and can't hurt to try -- Regards, Gregory Shearman.
Re: [gentoo-user] problem emerging Libdrm : solved
150125 Philip Webb wrote: After exactly 2 years , I'm trying to update my Asus EEE netbook. Trying to update gtk+ , I've run into a problem : it requires Mesa Cairo both require libdrm-2.4.58 , which refuses to compile, failing with lines reporting that libpng15.so.15 libudev.so.0 not found. I've already updated to libpng-1.6.16 , so libpng16.so.16 is installed. Thanks for the various suggestions. I solved the problem by unmerging Gtk+ Mesa Cairo Libdrm Xorg-server, after which Libdrm compiled successfully. BTW there's a rather bizarre dependency : the stable Mesa-10.2.8 requires the testing Cairo-1.12.18 . I've never seen this before. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] [~amd64] Does the EGL useflag break mesa-progs-8.2.0?
On Wed, Jul 15, 2015 at 01:53:50PM -0700, walt wrote: Just try emerging mesa-progs-8.2.0 with the EGL useflag set. Works fine here, compiles cleanly. This really requires atleast an 'emerge --info' to be able to tell more, but build logs may also be necessary. On Thu, 16 Jul 2015, wraeth wrote: Attempting to compile =x11-apps/mesa-progs-8.2.0[egl,-gles1,-gles2] I got: Makefile:489: recipe for target 'eglut.lo' failed make: *** [eglut.lo] Error 1 Makefile:489: recipe for target 'eglut_screen.lo' failed make: *** [eglut_screen.lo] Error 1 I'd look above these lines for the cause.
[gentoo-user] Updating media-libs/mesa failed
Today, updating my system, I have got:
# emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask
world --exclude chromium
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] media-libs/mesa-13.0.5 [12.0.1] USE="nettle%*
-gcrypt% (-libressl) -openssl% -vulkan%"
[ebuild U ] x11-libs/cairo-1.14.8 [1.14.6]
[ebuild U ] media-libs/libepoxy-1.4.1 [1.3.1] USE="X%*"
[ebuild U ] dev-libs/libinput-1.6.2 [1.4.2]
[ebuild U ] app-misc/mc-4.8.18-r1 [4.8.15]
[ebuild U ] x11-apps/xauth-1.0.10 [1.0.9-r2] USE="{-test}"
[ebuild U ] x11-base/xorg-server-1.19.2 [1.18.4] USE="-debug%"
[ebuild U ] x11-drivers/xf86-video-ati-7.8.0 [7.7.0]
[ebuild U ] x11-drivers/xf86-input-evdev-2.10.5 [2.10.3]
[ebuild U ] x11-base/xorg-drivers-1.19 [1.18-r1]
VIDEO_CARDS="-ark% -i915% -i965% (-newport) -sis%"
[ebuild U ] net-analyzer/wireshark-2.2.5 [2.2.4]
[ebuild U ] www-client/firefox-45.8.0 [45.7.0]
Would you like to merge these packages? [Yes/No] y
>>> Verifying ebuild manifests
>>> Running pre-merge checks for x11-base/xorg-server-1.19.2
>>> Running pre-merge checks for x11-drivers/xf86-video-ati-7.8.0
* Determining the location of the kernel source code
* Found kernel source directory:
* /usr/src/linux
* Found kernel object directory:
* /lib/modules/4.9.6-gentoo-r1/build
* Found sources for kernel version:
* 4.9.6-gentoo-r1
* Checking for suitable kernel configuration options...
[ ok ]
>>> Running pre-merge checks for x11-drivers/xf86-input-evdev-2.10.5
* Determining the location of the kernel source code
* Found kernel source directory:
* /usr/src/linux
* Found kernel object directory:
* /lib/modules/4.9.6-gentoo-r1/build
* Found sources for kernel version:
* 4.9.6-gentoo-r1
* Checking for suitable kernel configuration options...
[ ok ]
>>> Running pre-merge checks for www-client/firefox-45.8.0
* Checking for at least 4 GiB disk space at
"/var/tmp/portage/www-client/firefox-45.8.0/temp" ...
[ ok ]
>>> Emerging (1 of 12) media-libs/mesa-13.0.5::gentoo
...
configure: error: Package requirements (libdrm_amdgpu >= 2.4.63) were not met:
No package 'libdrm_amdgpu' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables AMDGPU_CFLAGS
and AMDGPU_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
!!! Please attach the following file when seeking support:
!!!
/var/tmp/portage/media-libs/mesa-13.0.5/work/mesa-13.0.5-abi_x86_32.x86/config.log
* ERROR: media-libs/mesa-13.0.5::gentoo failed (configure phase):
* econf failed
*
* Call stack:
* ebuild.sh, line 115: Called src_configure
* environment, line 4601: Called multilib-minimal_src_configure
* environment, line 2924: Called multilib_foreach_abi
'multilib-minimal_abi_src_configure'
* environment, line 3138: Called
multibuild_foreach_variant '_multilib_multibuild_wrapper'
'multilib-minimal_abi_src_configure'
* environment, line 2854: Called _multibuild_run
'_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure'
* environment, line 2852: Called
_multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure'
* environment, line 736: Called
multilib-minimal_abi_src_configure
* environment, line 2918: Called multilib_src_configure
* environment, line 3416: Called econf '--enable-dri'
'--enable-glx' '--enable-shared-glapi' '--disable-shader-cache'
'--enable-texture-float' '--disable-nine' '--disable-debug'
'--enable-dri3' '--enable-egl' '--enable-gbm' '--disable-gles1'
'--enable-gles2' '--enable-glx-tls' '--enable-valgrind=no'
'--enable-llvm-shared-libs' '--with-dri-drivers=,swrast,radeon,r200'
'--with-gallium-drivers=,swrast,r300,r600,radeonsi'
'--with-vulkan-drivers=' '--with-sha1=libnettle'
'PYTHON2=/usr/bin/python2.7' '--with-egl-platforms=x11,drm'
'--disable-nine' '--enable-gallium-llvm' '--disable-omx'
'--disable-va' '--disable-vdpau' '--disable-xa' '--disable-xvmc'
'--disable-glx-read-only-text' '--disable-gallium-osmesa'
*phase-helpers.sh, line 665: Called __helpers_die 'econf failed'
* isolated-functions.sh, line 117: Called die
* The specific snippet of code:
* die "$@"
*
* If you need support, post the output of `emerge --info
'=media-libs/mesa-13.0.5::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=media-libs/mesa-13.0.5::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/media-libs/mesa-13.0.5/temp/build.log'.
* The ebuild environment file is located at
[gentoo-user] Re: kdevelop broken (llvm slot issue)
On 19/08/18 18:21, Alexander Puchmayr wrote: After recent upgrades of mesa, llvm, clang etc kdevelop does not work anymore. It crashes immediately after start with errors [...] It seems as if multiple slots of llvm cause the problems. mesa pulls in llvm: 5, while other programs pull in llvm:6 (via clang:6) Does anyone have an idea how to get a working kdevelop again? Have you tried disabling the llvm USE flag of mesa? AFAIK it's only used for the software rendering backend, which you probably don't need. Try disabling it, and then do: emerge -auDN --changed-deps --with-bdeps=y @world followed by: emerge -a --depclean which should unmerge llvm:5.
Re: [gentoo-user] Firefox crashes on some www-pages on a newer Gentoo system
пт, 27 июл. 2018 г. в 18:30, Mick : > > This looks like a radeon video driver problem. You could go into a loop of > rebuilding xorg, mesa, dev-libs/nss, what-ever and see if things improve, or > you could wait for/keyword later versions of these packages. Just now, I have finished updating my system. It was after a more than a month of not doing so because of the summer heat. So, there was a lot of packages to update, including mesa. After the update, the problem with firefox crashing on privat24.ua logging page dissappeared. So, it looks like your advise to rebuild xorg, mesa, etc. was right. Thank you.
Re: [gentoo-user] Re: X won't start after xorg-server update
On Sat, 14 Mar 2020 01:06:58 -0400, Jonathan Callen wrote: > > It seems that file is created/modified by the mesa ebuild. > > > > I would try removing the file and re-emerging mesa to see if it is > > created with the correct content. > > > > > > The file is created/modified by app-eselect/eselect-opengl. That's what I thought at first, as the ebuild calls eselect opengl. But I don't have that module installed and the file is still present with a timestamp matching the emerge of mesa. -- Neil Bothwick Electricians DO IT until it Hz... pgprH9_Dxk_4g.pgp Description: OpenPGP digital signature
[gentoo-user] Update system
When I update my gentoo I get this message. x86_64-pc-linux-gnu-gcc -c -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa/main -I../../../src/mesa/glapi -I../../../src/mesa/drivers/dri/common `pkg-config --cflags libdrm` -I/usr/X11R6/include -Wall -O2 -fomit-frame-pointer -pipe -falign-functions=4 -fPIC -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DDEFAULT_DRIVER_DIR='/usr/lib64/xorg/modules/dri' -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DDEFAULT_DRIVER_DIR='/usr/lib64/xorg/modules/dri' -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER dri_glx.c -o dri_glx.o x86_64-pc-linux-gnu-gcc -c -I. -I../../../include -I../../../include/GL/internal -I../../../src/mesa/main -I../../../src/mesa/glapi -I../../../src/mesa/drivers/dri/common `pkg-config --cflags libdrm` -I/usr/X11R6/include -Wall -O2 -fomit-frame-pointer -pipe -falign-functions=4 -fPIC -m32 -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DDEFAULT_DRIVER_DIR='/usr/lib64/xorg/modules/dri' -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER -std=c99 -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DHAVE_ALIAS -DDEFAULT_DRIVER_DIR='/usr/lib64/xorg/modules/dri' -DXF86VIDMODE -D_REENTRANT -UIN_DRI_DRIVER XF86dri.c -o XF86dri.o XF86dri.c: In function `XF86DRIOpenConnection': XF86dri.c:204: warning: left shift count = width of type XF86dri.c: In function `XF86DRIGetDeviceInfo': XF86dri.c:566: warning: left shift count = width of type ../../../bin/mklib -o GL -linker 'x86_64-pc-linux-gnu-gcc' \ -major 1 -minor 2 \ -install ../../../lib -lX11 -lXext -lXxf86vm -lm -lpthread -ldl `pkg-config --libs libdrm` -ldrm ../../../src/mesa/glapi/glapi.o ../../../src/mesa/glapi/glthread.o ../../../src/mesa/main/dispatch.o glcontextmodes.o clientattrib.o compsize.o eval.o glxcmds.o glxext.o glxextensions.o indirect.o indirect_init.o indirect_size.o indirect_window_pos.o indirect_transpose_matrix.o indirect_vertex_array.o indirect_vertex_program.o pixel.o pixelstore.o render2.o renderpix.o single2.o singlepix.o vertarr.o xfont.o glx_pbuffer.o glx_query.o glx_texture_compression.o dri_glx.o XF86dri.o mklib: Making Linux shared library: libGL.so.1.2 /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../libX11.so when searching for -lX11 /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../libX11.a when searching for -lX11 /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libX11.so when searching for -lX11 /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libX11.a when searching for -lX11 /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status mklib: Installing libGL.so.1.2 libGL.so.1 libGL.so in ../../../lib mv: impossível fazer stat em `libGL.so.1.2': Arquivo ou diretório não encontrado make[3]: ** [../../../lib/libGL.so] Erro 1 make[3]: Leaving directory `/var/tmp/portage/mesa-6.4.2-r2/work/Mesa-6.4.2/src/glx/x11' make[2]: ** [subdirs] Erro 1 make[2]: Leaving directory `/var/tmp/portage/mesa-6.4.2-r2/work/Mesa-6.4.2/src' make[1]: ** [default] Erro 1 make[1]: Leaving directory `/var/tmp/portage/mesa-6.4.2-r2/work/Mesa-6.4.2' make: ** [linux-dri-x86] Erro 2 !!! ERROR: media-libs/mesa-6.4.2-r2 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile mesa-6.4.2-r2.ebuild, line 235: Called die !!! Build failed !!! If you need support, post the topmost build error, and the call stack if relevant.
Re: [gentoo-user] VLC emerge Fails
On Sun, Apr 12, 2009 at 7:54 AM, Volker Armin Hemmann volkerar...@googlemail.com wrote: you have to install mesa. Perfect! It worked. Thank you! -- MFD
Re: [gentoo-user] Problem with the graphic card
2009/6/19 Massimiliano Ziccardi massimiliano.zicca...@gmail.com: Thank you all. I think I'll wait, however, do you think that that is the problem that cause Did you enable intel in VIDEO_CARDS for mesa? Ward
[gentoo-user] Re: Broken 3D
On 10/07/2009 09:49 AM, James wrote: Hello, bash: glxgears: command not found I can't help with the driver, but glxgears is in the mesa-progs package.
Re: [gentoo-user] Preventing a package from being updated
On Mon, 18 Oct 2010 13:06:25 +0300, Timur Aydin wrote: I am using the ~x86 (testing) version of gentoo linux. After recent updates, my X windows became extremely sluggish and I found out that the problem is related to a new version of mesa (7.8.2 specifically). So I downgraded to version 7.7.1 and my desktop works great again. Now I want to prevent mesa from being updated until this issue is sorted out upstream. I have looked at package.provide, but that didn't work. Currently, I have placed media-libs/mesa into my /etc/portage/package.mask file and this seems to do the trick. Is this the recommended way for handling this situation? package.mask is the right place, but you should add the specific version. Then the system will only upgrade when a newer (hopefully fixed) version arrives. =media-libs/mesa-7.8.2 -- Neil Bothwick WindowError:01B Illegal error. Do NOT get this error. signature.asc Description: PGP signature
Re: [gentoo-user] depclean wants to remove hal, which kills xdm
Helmut Jarausch jarau...@igpm.rwth-aachen.de writes: On 12/21/10 15:41:20, Allan Gottlieb wrote: My plan is to stay like this until xorg 1.9 hits ~amd64 since I It is already unmasked in ~amd64 (It's running just fine here) Bingo. There was a mesa problem a while ago (7.8.2) that caused me to mask =media-libs/mesa-7.8.2. This caused me to mask xorg-server above the current running one. I didn't notice that mesa did advance and I am running 7.9-r1. So I just now unmasked both mesa and xorg-server and update world updated xorg-server and xinit. Let's see if this now permits me to let depclean remove hal. thank you all for your help! allan
[gentoo-user] SOLVED: Re: depclean wants to remove hal, which kills xdm
Allan Gottlieb gottl...@nyu.edu writes: Helmut Jarausch jarau...@igpm.rwth-aachen.de writes: On 12/21/10 15:41:20, Allan Gottlieb wrote: My plan is to stay like this until xorg 1.9 hits ~amd64 since I It is already unmasked in ~amd64 (It's running just fine here) Bingo. There was a mesa problem a while ago (7.8.2) that caused me to mask =media-libs/mesa-7.8.2. This caused me to mask xorg-server above the current running one. I didn't notice that mesa did advance and I am running 7.9-r1. So I just now unmasked both mesa and xorg-server and update world updated xorg-server and xinit. Let's see if this now permits me to let depclean remove hal. It all works fine. Depclean removed hal and friends and a reboot still has X and xdm (i.e., gdm). thanks again. allan
[gentoo-user] Re: No HW acceleraton on radeon Mobility X300 with linux-2.6.36-r5, mesa-7.9, xorg-server-1.9.2 and video-ati-6.13.2
On 01/16/2011 05:18 PM, Daniel Tihelka wrote: Hallo, after update to 2.6.36-r5 kernel, xorg 1.9.2, mesa-7.9 and xf86-video- ati-6.13.2 (all from gentoo portage), the hw graphics acceleration stopped working. The problem seems to be in drm kernel module, as it is claimed by X.org (the part of X.org log): [...] And the kernel seems to use them (when started with boot options 'video=vesafb:ywrap,mtrr:3 vga=792') Remove the above and try this: video=vesafb:off radeon.modeset=1 radeon.dynpm=1 Then, try deleting your xorg.conf (if you have one) and do: eselect mesa set r300 gallium Also make sure that mesa is emerged with the video_cards_r300 USE flag enabled. video_cards_radeon is *not* enough. Your make.conf should probably contain this: VIDEO_CARDS=fbdev vesa radeon r300 After changing this, try an emerge -auDN world and see if something needs to be rebuilt.
Re: [gentoo-user] Re: (unknown)
On Monday 24 Oct 2011 09:36:48 Nikos Chantziaras wrote: On 10/24/2011 11:28 AM, Vishnupradeep wrote: On Mon, Oct 24, 2011 at 1:40 PM, Nikos Chantziaras rea...@arcor.de mailto:rea...@arcor.de wrote: In your /etc/make.conf, use this: I am using ATI 4350 card. so is that VIDEO_CARDS=radeon r700 No. There is no driver called r700. The driver is called r600 and it drives R600 chips and newer. Another thing I forgot to mention is that you should make sure you're using Gallium3D in Mesa. To see what you're using (after you've rebuilt everything), do: eselect mesa list If classic is selected instead of gallium, change it: eselect mesa set 64bit r600 gallium eselect mesa set 32bit r600 gallium I'm getting confused ... I thought that the driver is radeon and r600 is the firmware blob. Does this need adding to /etc/make.conf? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Gallium and nVidia
Hi All, I would like to some clarification to support my feeling regarding gallium related use flags in mesa package. For some reason I have to rebuild a few packages on my machine and xorg-server and mesa are among them. I experienced that if the xorg USE flag of mesa is enabled then I got compiling error. After a little searching I could see that this use flag enables gallium3d. My question is that, as a nvidia user - I have an nvidia card and I use a nvidia driver from nvidia-drivers package - do I need this use flag? Do I need the gallium related use flags in mesa? Thanks in advance for any help! András -- -- Csanyi Andras (Sayusi Ando) -- http://sayusi.hu -- http://facebook.com/andras.csanyi -- Trust in God and keep your gunpowder dry! - Cromwell
[gentoo-user] Re: Gallium and nVidia
On 29/07/13 18:38, András Csányi wrote: Hi All, I would like to some clarification to support my feeling regarding gallium related use flags in mesa package. For some reason I have to rebuild a few packages on my machine and xorg-server and mesa are among them. I experienced that if the xorg USE flag of mesa is enabled then I got compiling error. After a little searching I could see that this use flag enables gallium3d. My question is that, as a nvidia user - I have an nvidia card and I use a nvidia driver from nvidia-drivers package - do I need this use flag? Do I need the gallium related use flags in mesa? I have gallium enabled and am also using nvidia-drivers. It doesn't do anything when running those drivers though. What it can do though is provide software OpenGL rendering, in case you need a fallback. In any event, it doesn't conflict with nvidia-drivers, since it's not used if you did: eselect opengl nvidia (Which I assume you did, since otherwise you wouldn't have 3D support with the nvidia drivers.)
