Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] =media-libs/mesa-11.0.6[( || gbm dri3 )] with mdev
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Desktop Environments
View previous topic :: View next topic  
Author Message
POSIX_ME_HARDER
n00b
n00b


Joined: 30 Aug 2015
Posts: 24

PostPosted: Wed Dec 02, 2015 12:58 pm    Post subject: [SOLVED] =media-libs/mesa-11.0.6[( || gbm dri3 )] with mdev Reply with quote

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 :roll:), 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
View user's profile Send private message
chithanh
Developer
Developer


Joined: 05 Aug 2006
Posts: 2152
Location: Berlin, Germany

PostPosted: Wed Dec 02, 2015 1:29 pm    Post subject: Reply with quote

I think gbm stopped strictly requiring libudev, and can do with --enable-sysfs too.
You could have a look at configure.ac and see if a combination of configure options exists that allows you to use radeonsi without libudev.

http://cgit.freedesktop.org/mesa/mesa/tree/configure.ac?id=mesa-11.0.6
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Wed Dec 02, 2015 2:19 pm    Post subject: Re: radeonsi requires virtual/libudev Reply with quote

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
View user's profile Send private message
POSIX_ME_HARDER
n00b
n00b


Joined: 30 Aug 2015
Posts: 24

PostPosted: Wed Dec 02, 2015 2:42 pm    Post subject: Re: radeonsi requires virtual/libudev Reply with quote

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
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3403

PostPosted: Wed Dec 02, 2015 4:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
chithanh
Developer
Developer


Joined: 05 Aug 2006
Posts: 2152
Location: Berlin, Germany

PostPosted: Wed Dec 02, 2015 4:33 pm    Post subject: Reply with quote

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
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3403

PostPosted: Wed Dec 02, 2015 4:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
chithanh
Developer
Developer


Joined: 05 Aug 2006
Posts: 2152
Location: Berlin, Germany

PostPosted: Wed Dec 02, 2015 6:46 pm    Post subject: Reply with quote

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
View user's profile Send private message
POSIX_ME_HARDER
n00b
n00b


Joined: 30 Aug 2015
Posts: 24

PostPosted: Wed Dec 02, 2015 7:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Wed Dec 02, 2015 8:02 pm    Post subject: Reply with quote

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://portage.schorsch-tech.de
git clone https://portage.schorsch-tech.de/portage.git
Back to top
View user's profile Send private message
POSIX_ME_HARDER
n00b
n00b


Joined: 30 Aug 2015
Posts: 24

PostPosted: Wed Dec 02, 2015 8:16 pm    Post subject: Reply with quote

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
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Wed Dec 02, 2015 8:41 pm    Post subject: Reply with quote

Hmm .. portage doesn't pick up my new overlay ...

EDIT: Ok got it
_________________
// valid again: I forgot about the git access. Now 1.2GB big. Start: 2015-06-25
git daily portage tree
Web: https://portage.schorsch-tech.de
git clone https://portage.schorsch-tech.de/portage.git
Back to top
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Wed Dec 02, 2015 9:01 pm    Post subject: Reply with quote

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.... :cry:
_________________
// valid again: I forgot about the git access. Now 1.2GB big. Start: 2015-06-25
git daily portage tree
Web: https://portage.schorsch-tech.de
git clone https://portage.schorsch-tech.de/portage.git
Back to top
View user's profile Send private message
POSIX_ME_HARDER
n00b
n00b


Joined: 30 Aug 2015
Posts: 24

PostPosted: Wed Dec 02, 2015 9:18 pm    Post subject: Reply with quote

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
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Wed Dec 02, 2015 11:00 pm    Post subject: Reply with quote

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
View user's profile Send private message
POSIX_ME_HARDER
n00b
n00b


Joined: 30 Aug 2015
Posts: 24

PostPosted: Thu Dec 03, 2015 2:47 am    Post subject: Reply with quote

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. :D

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 :P )

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
View user's profile Send private message
schorsch_76
Guru
Guru


Joined: 19 Jun 2012
Posts: 450

PostPosted: Thu Dec 03, 2015 3:09 am    Post subject: Reply with quote

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://portage.schorsch-tech.de
git clone https://portage.schorsch-tech.de/portage.git
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Thu Dec 03, 2015 8:04 am    Post subject: Reply with quote

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
View user's profile Send private message
POSIX_ME_HARDER
n00b
n00b


Joined: 30 Aug 2015
Posts: 24

PostPosted: Thu Dec 03, 2015 9:44 am    Post subject: Reply with quote

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... :lol:
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
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Thu Dec 03, 2015 10:32 am    Post subject: Reply with quote

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
View user's profile Send private message
POSIX_ME_HARDER
n00b
n00b


Joined: 30 Aug 2015
Posts: 24

PostPosted: Thu Dec 03, 2015 1:32 pm    Post subject: Reply with quote

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
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Thu Dec 03, 2015 1:46 pm    Post subject: Reply with quote

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
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu Dec 03, 2015 7:17 pm    Post subject: Reply with quote

@khay: man qgrep (from app-portage/portage-utils)
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6228
Location: Room 101

PostPosted: Thu Dec 03, 2015 7:42 pm    Post subject: Reply with quote

steveL wrote:
@khay: man qgrep (from app-portage/portage-utils)

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Desktop Environments All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum