| View previous topic :: View next topic |
| Author |
Message |
POSIX_ME_HARDER
n00b
Joined: 30 Aug 2015
Posts: 27
|
 Posted: Wed Dec 02, 2015 12:58 pm Post subject: [SOLVED] =media-libs/mesa-11.0.6[( || gbm dri3 )] with mdev |
 |
|
Hi,
I'm running Gentoo on a computer which has an ATI Radeon card (with a TAHITI chipset).
I'm (obviously) using the open source drivers ("radeon").
Enjoying the customization facilities Gentoo offers, I've decided to use mdev.
It's been working fairly well for months, but I very recently encountered a rather annoying problem: updating my graphic drivers now requires me to use udev instead (or having very reduced graphic capabilities).
Following the (Gentoo) wiki page about the driver, I've set my make.conf's VIDEO_CARDS option to "radeon radeonsi".
Here's what Portage tells me when I try to install the updates:
| Code: |
The following USE changes are necessary to proceed:
(see "package.use" in the portage(5) man page for more details)
# required by sys-fs/udev-216::gentoo
# required by virtual/libudev-215-r1::gentoo[-systemd]
# required by media-libs/mesa-11.0.6::gentoo
# required by x11-base/xorg-server-1.17.4::gentoo[-minimal]
# required by x11-drivers/xf86-input-synaptics-1.8.2::gentoo
# required by x11-base/xorg-drivers-1.17::gentoo[input_devices_synaptics]
>=sys-apps/hwids-20150129 udev
# required by media-libs/mesa-11.0.6::gentoo[video_cards_radeonsi]
# required by x11-base/xorg-server-1.17.4::gentoo[-minimal]
# required by x11-drivers/xf86-input-synaptics-1.8.2::gentoo
# required by x11-base/xorg-drivers-1.17::gentoo[input_devices_synaptics]
>=x11-libs/libdrm-2.4.65 video_cards_amdgpu
# required by x11-base/xorg-drivers-1.17::gentoo[video_cards_radeonsi]
# required by x11-base/xorg-server-1.17.4::gentoo[xorg]
# required by x11-drivers/xf86-input-synaptics-1.8.2::gentoo
>=x11-drivers/xf86-video-ati-7.5.0 glamor
# required by x11-libs/glamor-0.6.0-r1::gentoo
# required by x11-drivers/xf86-video-ati-7.5.0::gentoo[glamor]
# required by x11-base/xorg-drivers-1.17::gentoo[video_cards_radeon]
# required by x11-base/xorg-server-1.17.4::gentoo[xorg]
# required by x11-drivers/xf86-input-synaptics-1.8.2::gentoo
>=media-libs/mesa-11.0.6 gbm
|
From what I've understood, radeonsi makes x11-base/xorg-drivers require glamor (nothing too alarming here, it worked fine with glamor before), which in turn makes x11-base/xorg-server require gbm, which in turn makes media-libs/mesa require virtual/libudev.
Meaning radeonsi requires virtual/libudev, since those are not optional flags.
Not wanting to stop using mdev, nor wanting to have crippled graphics, I don't see any other choice than not updating my graphic drivers (or buying another graphic card  ), which doesn't seem like a good solution.
Is there a way out of this (some alternative packages perhaps)?
Edit: solved.
Edit 2: title changed (was previously "[SOLVED] radeonsi requires virtual/libudev")
Last edited by POSIX_ME_HARDER on Thu Dec 03, 2015 8:44 am; edited 2 times in total |
|
| Back to top |
|
 |
chithanh
Developer
Joined: 05 Aug 2006
Posts: 2158
Location: Berlin, Germany
|
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Wed Dec 02, 2015 2:19 pm Post subject: Re: radeonsi requires virtual/libudev |
|
|
| POSIX_ME_HARDER wrote: | | From what I've understood, radeonsi makes x11-base/xorg-drivers require glamor (nothing too alarming here, it worked fine with glamor before), which in turn makes x11-base/xorg-server require gbm, which in turn makes media-libs/mesa require virtual/libudev. Meaning radeonsi requires virtual/libudev, since those are not optional flags. |
pmh ... I think you've made one or two errors in how you're tracking the source of the dependency ... x11-base/xorg-drivers doesn't have a 'glamor' useflag, and x11-base/xorg-server doesn't have 'gbm' useflag. In my tracking the cause (I'm similarly using mdev ... and no {e,}udev is installed) I have it down to the following:
| mesa-11.0.6.ebuild: | gbm? ( >=virtual/libudev-215:=[${MULTILIB_USEDEP}] )
dri3? ( >=virtual/libudev-215:=[${MULTILIB_USEDEP}] ) |
That is a new dependency, not a use change/addition ... so, one or other of those useflags enabled and portage will attempt to pull in virtual/libudev (and its dependencies).
If I get time later today I'll attempt to build without this dependency, and let you know how it goes.
best ... khay |
|
| Back to top |
|
|
POSIX_ME_HARDER
n00b
Joined: 30 Aug 2015
Posts: 27
|
| Posted: Wed Dec 02, 2015 2:42 pm Post subject: Re: radeonsi requires virtual/libudev |
|
|
| khayyam wrote: | | pmh ... I think you've made one or two errors in how you're tracking the source of the dependency ... x11-base/xorg-drivers doesn't have a 'glamor' useflag, and x11-base/xorg-server doesn't have 'gbm' useflag. |
I wouldn't be too surprised if my formulation was confusing, sorry about that. Neither have those useflag, both force another package to enable them.
| chithanh wrote: | | I think gbm stopped strictly requiring libudev, and can do with --enable-sysfs too. |
That looks very promising, thanks.
I noticed the line 296 of mesa-11.0.6.ebuild, which seems to agree:
| Code: | | (use_enable !udev sysfs) \ |
Using a modified ebuild for mesa (which simply does not ask for libudev to enable gbm when udev isn't enabled), it compiles successfully. I'm not at home so I can't test anything (graphic related, I tested the compilation through SSH) but I'm hopeful. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Dec 02, 2015 4:30 pm Post subject: |
|
|
There's another issue lurking in your emerge report that you don't appear to have hit, yet. You're obviously going after the bigger problem, but...
| Code: | | >=x11-libs/libdrm-2.4.65 video_cards_amdgpu |
I haven't really sorted this out yet, but I've been using the radeon kernel driver, and this appears to require using amdgpu instead. To be honest, I'm not sure if that's "requires" or "permits". I've been hoping to see more activity here about the topic, but haven't yet. I'm probably going to start a thread myself this weekend, if it isn't handled head-on before then. I'm not sure how deep this problem goes. If the new libdrm requires amdgpu, then updating xorg will push me back to text-mode, because while I have a 4.3.0 kernel, I didn't build amdgpu. Plus I have installed radeon-ucode, and if I go with amdgpu I don't know if I instead need amdgpu-ucode with the "legacy" use flag instead, even though the radeonsi files are really the same. (I have a Kaveri.)
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
chithanh
Developer
Joined: 05 Aug 2006
Posts: 2158
Location: Berlin, Germany
|
| Posted: Wed Dec 02, 2015 4:33 pm Post subject: |
|
|
| The mesa radeonsi driver uses either the radeon drm (for first and second generation GCN cards) or the amdgpu drm (for third generation cards). TAHITI cards are first generation, so the amdgpu kernel driver is unnecessary. But still libdrm_amdgpu is needed to build mesa. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Dec 02, 2015 4:48 pm Post subject: |
|
|
| chithanh wrote: | | The mesa radeonsi driver uses either the radeon drm (for first and second generation GCN cards) or the amdgpu drm (for third generation cards). TAHITI cards are first generation, so the amdgpu kernel driver is unnecessary. But still libdrm_amdgpu is needed to build mesa. |
OK, so I can just enable the USE flag and go. I wasn't sure if libdrm was forcing me to switch to amdgpu. Looking into the documentation further I found that I can indeed run my Kaveri with amdgpu - it is sufficiently backward-compatible for that. I may want to try it at some point, I expect better maintenance and enhancement on amdgpu than on radeon, the question will be how well the backward-compatlble stuff is handled.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
chithanh
Developer
Joined: 05 Aug 2006
Posts: 2158
Location: Berlin, Germany
|
| Posted: Wed Dec 02, 2015 6:46 pm Post subject: |
|
|
To my knowledge there are several bugs which preclude Kaveri from running properly with amdgpu, and AMD has no intention to fix those.
For example:
https://bugzilla.kernel.org/show_bug.cgi?id=105111
But there is really no reason to run the amdgpu kernel driver instead of radeon, at least not currently. |
|
| Back to top |
|
|
POSIX_ME_HARDER
n00b
Joined: 30 Aug 2015
Posts: 27
|
| Posted: Wed Dec 02, 2015 7:42 pm Post subject: |
|
|
Being back at home, I've been able to test the results bit more, and it seems to be working. Thank you guys! 
I've tested glxgears (which runs correctly and gives me what I expected when called with the "-info" parameter) and mplayer (which upscales the tested video to fill the screen, something it doesn't do if I don't enable radeonsi). Funnily enough, urxvt has a terrible refresh rate, but I suspect this is unrelated.
I made a bug report about it on Gentoo's Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=567368. |
|
| Back to top |
|
|
schorsch_76
Guru
Joined: 19 Jun 2012
Posts: 450
|
| Posted: Wed Dec 02, 2015 8:02 pm Post subject: |
|
|
Actually i hit the same issue on my vdr box using mdev. It always wants to pull in udev.
| Code: | emerge -auDNvp @world
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N #] sys-fs/udev-216::gentoo USE="acl firmware-loader kmod -doc -gudev -introspection (-selinux) -static-libs" 3.530 KiB
[ebuild R ] sys-apps/hwids-20150129::gentoo USE="net pci udev* usb" 0 KiB
Total: 2 packages (1 new, 1 reinstall), Size of downloads: 3.530 KiB
The following mask changes are necessary to proceed:
(see "package.unmask" in the portage(5) man page for more details)
# required by virtual/libudev-215-r1::gentoo[-systemd]
# required by media-libs/mesa-10.6.9::gentoo
# required by @selected
# required by @world (argument)
# /etc/portage/package.mask:
# mdev
=sys-fs/udev-216
The following USE changes are necessary to proceed:
(see "package.use" in the portage(5) man page for more details)
# required by sys-fs/udev-216::gentoo
# required by virtual/udev-215::gentoo[-systemd]
# required by sys-fs/udev-init-scripts-27::gentoo
>=sys-apps/hwids-20150129 udev
NOTE: The --autounmask-keep-masks option will prevent emerge
from creating package.unmask or ** keyword changes.
* IMPORTANT: 1 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
|
mesa (at least 10.6.9) needs udev
| Code: | IUSE="${IUSE_VIDEO_CARDS}
bindist +classic d3d9 debug +dri3 +egl +gallium +gbm gles1 gles2 +llvm
+nptl opencl osmesa pax_kernel openmax pic selinux +udev vaapi vdpau
wayland xvmc xa kernel_FreeBSD" |
_________________
// valid again: I forgot about the git access. Now 1.2GB big. Start: 2015-06-25
git daily portage tree
Web: https://github.com/schorsch1976/portage
git clone https://github.com/schorsch1976/portage |
|
| Back to top |
|
|
POSIX_ME_HARDER
n00b
Joined: 30 Aug 2015
Posts: 27
|
| Posted: Wed Dec 02, 2015 8:16 pm Post subject: |
|
|
media-libs/mesa-10.6.9's ebuild appears to have the same | Code: | | $(use_enable !udev sysfs) |
line, so I suspect it can be fixed in the same way (if gbm is also the reason for virtual/libudev being pulled).
Here's what I did:
- I created an overlay directory for Portage: "/usr/local/portage".
- I copied the relevant ebuild (/usr/portage/media-libs/mesa/mesa-11.0.6.ebuild), and its related files (/usr/portage/media-libs/mesa/files/), to "/usr/local/portage/media-libs/mesa/" (after creating the relevant folders).
- Editing the copy of the ebuild, I changed the line
| Code: | | gbm? ( >=virtual/libudev-215:=[${MULTILIB_USEDEP}] ) |
to | Code: | | gbm? ( udev? ( >=virtual/libudev-215:=[${MULTILIB_USEDEP}] ) ) |
.
(Note that this makes no test to see if "sysfs" is available, it's just a quick hack)
I generated the overlaying package's Manifest by running:
| Code: | | # ebuild mesa-11.0.6.ebuild digest |
in "/usr/local/portage/media-libs/mesa/".
I informed Portage of the "/usr/local/portage" overlay using /etc/portage/make.conf's PORTDIR_OVERLAY variable.
And Portage gave me what I wanted. |
|
| Back to top |
|
|
schorsch_76
Guru
Joined: 19 Jun 2012
Posts: 450
|
|
| Back to top |
|
|
schorsch_76
Guru
Joined: 19 Jun 2012
Posts: 450
|
| Posted: Wed Dec 02, 2015 9:01 pm Post subject: |
|
|
It did not solve the dependency issue.
| Code: | emerge -auDNv @world
* IMPORTANT: 1 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N #] sys-fs/udev-216::gentoo USE="acl firmware-loader kmod -doc -gudev -introspection (-selinux) -static-libs" 3.530 KiB
[ebuild R ] sys-apps/hwids-20150129::gentoo USE="net pci udev* usb" 0 KiB
[ebuild N ] sys-fs/udev-init-scripts-27::gentoo 0 KiB
Total: 3 packages (2 new, 1 reinstall), Size of downloads: 3.530 KiB
The following mask changes are necessary to proceed:
(see "package.unmask" in the portage(5) man page for more details)
# required by virtual/libudev-215-r1::gentoo[-systemd]
# required by media-libs/mesa-10.6.9::local
# required by @selected
# required by @world (argument)
|
I got a different issue:
| Code: | eix hwids
[I] sys-apps/hwids
Available versions: 20141010 ~20141110 ~20141214 ~20150107 20150129 ~20150417 ~20150421 ~20150421-r1 ~20150717 ~20150717-r1 **99999999 {+net +pci +udev +usb}
Installed versions: 20150129(21:23:48 02.12.2015)(net pci usb -udev)
Homepage: https://github.com/gentoo/hwids
Description: Hardware (PCI, USB, OUI, IAB) IDs databases
gentoo-xbmc portage # equery d hwids
* These packages depend on hwids:
sys-apps/pciutils-3.3.1 (sys-apps/hwids)
x11-libs/libpciaccess-0.13.3 (sys-apps/hwids)
gentoo-xbmc portage # equery d pciutils
* These packages depend on pciutils:
sys-apps/vbetool-1.1 (sys-apps/pciutils)
sys-boot/efibootmgr-0.12 (sys-apps/pciutils)
gentoo-xbmc portage # equery d efibootmgr
* These packages depend on efibootmgr:
sys-boot/grub-2.02_beta2-r7 (grub_platforms_efi-32 ? sys-boot/efibootmgr)
(grub_platforms_efi-64 ? sys-boot/efibootmgr)
|
I have an efi system. efibootmgr seems required by grub. But that pulls in hwids and this pulls in again udev. Damnit.... 
_________________
// valid again: I forgot about the git access. Now 1.2GB big. Start: 2015-06-25
git daily portage tree
Web: https://github.com/schorsch1976/portage
git clone https://github.com/schorsch1976/portage |
|
| Back to top |
|
|
POSIX_ME_HARDER
n00b
Joined: 30 Aug 2015
Posts: 27
|
| Posted: Wed Dec 02, 2015 9:18 pm Post subject: |
|
|
Well... I end up with the same conclusion as you concerning sys-boot/efibootmgr requiring udev. 
You might want to create a thread about it.
Since media-libs/mesa is the focus of this thread, here's how I would investigate why my "fix" didn't solve the issue for you:
| Code: | | # required by media-libs/mesa-10.6.9::local |
Does not give us enough information, so let's try to figure out which flag causes media-libs/mesa to require virtual/libudev.
Disable the overlay (to avoid confusion).
According to its ebuild, the flags that cause media-libs/mesa-10.6.9 to require virtual/libudev are: udev, gbm and dri3.
Let's see which package complains if we disable all of them:
| Code: | | # USE="-udev -gbm -dri3" emerge -p =media-libs/mesa-10.6.9 |
Portage should now tell us which flag(s) is(/are) causing the issue and which package is asking for them, by asking us to add content to "package.use". |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Wed Dec 02, 2015 11:00 pm Post subject: |
|
|
| schorsch_76 wrote: | | Code: | [ebuild R ] sys-apps/hwids-20150129::gentoo USE="net pci udev* usb" 0 KiB
[...]
# required by media-libs/mesa-10.6.9::local |
I have an efi system. efibootmgr seems required by grub. But that pulls in hwids and this pulls in again udev. |
schorsch_76 ... it's not efibootmgr, that is a use change *caused* by media-libs/mesa[gbm,dri3]. Those useflags will have a knock on effect, one of which is to require sys-apps/hwids have the use change, as I remember it was the inclusion of {e,}udev.
POSIX_ME_HARDER's edit above only targets 'gdm', and so the 'dri3' useflag probably accounts for why you're still seeing udev pulled in, and why use changes are being prompted.
I haven't found time today to look any further at the problem, hopefully tommorow.
best ... khay |
|
| Back to top |
|
|
POSIX_ME_HARDER
n00b
Joined: 30 Aug 2015
Posts: 27
|
| Posted: Thu Dec 03, 2015 2:47 am Post subject: |
|
|
| POSIX_ME_HARDER wrote: |
| chithanh wrote: | | I think gbm stopped strictly requiring libudev, and can do with --enable-sysfs too. |
That looks very promising, thanks.
I noticed the line 296 of mesa-11.0.6.ebuild, which seems to agree:
| Code: | | (use_enable !udev sysfs) \ |
|
I kinda forgot to put the start of my reasoning there, which makes it hard to follow.
Following chithanh's advice, I looked at the configure.ac file, and found:
| Code: | | AC_MSG_ERROR([gbm requires udev >= $LIBUDEV_REQUIRED or sysfs]) |
Which confirmed chithanh's claims about gbm allowing for a sysfs dependency instead of an udev one.
Only then was seeing how the ebuild decided to activate sysfs relevant.
| POSIX_ME_HARDER wrote: | Well... I end up with the same conclusion as you concerning sys-boot/efibootmgr requiring udev.
You might want to create a thread about it. |
Nevermind, I read sys-apps/hwids's ebuild wrong, erroneously thinking | Code: | | !<sys-apps/pciutils-3.1.9-r2 |
meant | Code: | | >=sys-apps/pciutils-3.1.9-r2 |
It does not (because not having sys-apps/pciutils installed also satisfies this constraint), meaning sys-boot/efibootmgr can be installed without udev, so there's still hope. 
I'm currently looking deeper into it, but from a first read it seems to me that dri3 can also be activated without udev.
If this is true, what is up with mesa's ebuilds? Shall we put on our tinfoil hats and complain about a conspiracy against {e,}udev alternatives? (I'm kidding, of course  )
Edit:
I tried to install media-libs/mesa with both gbm (which, as we know, is required for me) and dri3, by altering the overlaying ebuild to stop forcing udev for either (although I'm not sure dri3 requires even sysfs), and it compiles just fine.
My [sarcasm]oh so rigorous[/sarcasm] run tests ("mplayer" and "glxgears -info") also work without issues.
Last edited by POSIX_ME_HARDER on Thu Dec 03, 2015 3:10 am; edited 1 time in total |
|
| Back to top |
|
|
schorsch_76
Guru
Joined: 19 Jun 2012
Posts: 450
|
| Posted: Thu Dec 03, 2015 3:09 am Post subject: |
|
|
In fact it tuned out to be the dri3 use flag. I applied the same change to the dri line and now it compiles.
For my other issie i opened a bug and changed from grub to syslinux.
_________________
// valid again: I forgot about the git access. Now 1.2GB big. Start: 2015-06-25
git daily portage tree
Web: https://github.com/schorsch1976/portage
git clone https://github.com/schorsch1976/portage |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Dec 03, 2015 8:04 am Post subject: |
|
|
| POSIX_ME_HARDER wrote: | | I tried to install media-libs/mesa with both gbm (which, as we know, is required for me) and dri3, by altering the overlaying ebuild to stop forcing udev for either (although I'm not sure dri3 requires even sysfs), and it compiles just fine. |
pmh ... thanks for testing that ... yes, having done the update (after disabling the libudev dependency) I can report that all seems well.
Could I ask two small favours, could you edit the subject line of the original post and make it something along the lines of "mdev: =media-libs/mesa-11.0.6 requires libudev" (or something similar). This way hopefully people won't think the issue is radeonsi specific, and so those using mdev, and similarly effected, will gravitate to this thread (or at least perhaps find the solution via a search). Also, could you attach the modified ebuild to the bug report ... sometimes devs won't take the issue seriously unless a fix is supplied.
Again, thanks for being ahead of the curve on this, I was somewhat swamped with other things yesterday (including getting some stitches in my head, oiii).
best ... khay |
|
| Back to top |
|
|
POSIX_ME_HARDER
n00b
Joined: 30 Aug 2015
Posts: 27
|
| Posted: Thu Dec 03, 2015 9:44 am Post subject: |
|
|
Thanks for the advices.
| khayyam wrote: | | edit the subject line of the original post and make it something along the lines of "mdev: =media-libs/mesa-11.0.6 requires libudev" (or something similar). |
Good idea. It is done.
| khayyam wrote: | | Also, could you attach the modified ebuild to the bug report ... sometimes devs won't take the issue seriously unless a fix is supplied. |
I see... 
Well, I'm not satisfied with my quick'n'dirty hack. Assuming that users have sysfs support because they didn't set the udev flag does not seem like a sane practice to me.
I'm totally new to ebuilds (it's the first time I've edited one), but it seems to me like there should be a sysfs flag (to indicate support for sysfs, obviously), making the gbm RDEPEND rule be something like:
| Code: | | gbm? ( || sysfs ( udev? ( >=virtual/libudev-215:=[${MULTILIB_USEDEP}] ) ) ) |
I also feel I have not looked into configure.ac enough to know what should actually be the dri3 RDEPEND rule (I just know it is not more constraining that the above gbm).
It's fun and interesting work, but I don't really have the time to do it before tomorrow evening, sorry. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Dec 03, 2015 10:32 am Post subject: |
|
|
| POSIX_ME_HARDER wrote: | | khayyam wrote: | | Also, could you attach the modified ebuild to the bug report ... sometimes devs won't take the issue seriously unless a fix is supplied. |
Well, I'm not satisfied with my quick'n'dirty hack. Assuming that users have sysfs support because they didn't set the udev flag does not seem like a sane practice to me. I'm totally new to ebuilds (it's the first time I've edited one), but it seems to me like there should be a sysfs flag (to indicate support for sysfs, obviously), making the gbm RDEPEND rule [...] |
pmh ... you could 'inherit linux-info' and check KCONFIG_OPTS, but I think its entirely unnecessary in this case, and is unlikely to get inclusion due to the additon of a 'sysfs' useflag. I don't think its needed, as all we are doing is in reference to the 'udev' useflag, if that is disabled (keeping in mind its IUSE="udev") then the only other option is for sysfs to be used ... and no additional useflag is needed for a binary off/on switch. Added to this sysfs is enabled in 'defconfig' and so its not something that explictly needs enabled in the kernel. So, while the above is perhaps "quick and dirty", it makes perfect sense, and having it currently force virtual/libudev is far less preferable.
best ... khay |
|
| Back to top |
|
|
POSIX_ME_HARDER
n00b
Joined: 30 Aug 2015
Posts: 27
|
| Posted: Thu Dec 03, 2015 1:32 pm Post subject: |
|
|
Okay. I added a patch to the bug report.
Thank you again for taking the time to explain. I was wondering how to (and if Portage even could) check for kernel options, now I know. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Dec 03, 2015 1:46 pm Post subject: |
|
|
| POSIX_ME_HARDER wrote: | | Okay. I added a patch to the bug report. :) |
pmh ... ok, good/thanks.
| POSIX_ME_HARDER wrote: | | Thank you again for taking the time to explain. I was wondering how to (and if Portage even could) check for kernel options, now I know. |
You're welcome ... if you search (example below) for ebuilds where this is done you'll see its fairly easy to do (though you need to keep abreast of kconfig changes as some options change name, become obsolete, etc) ... and btw, its really only done for ELOG (so, to warn the user such-and-such is required/recommended).
| Code: | | # ag --ignore-dir files --ignore-dir profiles --ignore-dir licence --ignore-dir metadata --ignore-dir eclass -G ".*[^/]\.ebuild$" -l 'KCONFIG_OPTS=' $(portageq get_repo_path / gentoo) |
best ... khay |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Dec 03, 2015 7:17 pm Post subject: |
|
|
| @khay: man qgrep (from app-portage/portage-utils) |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Dec 03, 2015 7:42 pm Post subject: |
|
|
steve ... ok, new to me, but 'qgrep -l KCONFIG_OPTS' seems significantly slower than ag (sys-apps/the_silver_searcher).
best ... khay |
|
| Back to top |
|
|
|
Desktop Environments
