Jump to content
funtoo forums

hick518

Members
  • Content count

    53
  • Joined

  • Last visited

  • Days Won

    4

hick518 last won the day on May 4 2016

hick518 had the most liked content!

About hick518

  • Rank
    Advanced Member
  1. I have a funtoo server that does all the package builds, and my other servers and desktops specify 'getbinpkg' in order to use the packages created by the primary server. This mostly works, but I often get messages like "The following binary packages have been ignored due to changed dependencies". Here is an example. On my laptop, when emerging @world, I get the following message and nothing gets emerged (all other packages have been brought up to date): !!! The following binary packages have been ignored due to changed dependencies: dev-lang/vala-0.28.1::gentoo NOTE: The --binpkg-changed-deps=n option will prevent emerge from ignoring these binary packages if possible. Using --binpkg-changed-deps=y will silence this warning. Neither of the suggested --bin-pkg-changed-deps options change the message in any way. Even stranger, this version of vala is not installed on the laptop (nor on the primary server). # ego query versions vala dev-lang/vala| slot| repo --------------+-----+--------------------- 0.26.2| 0.26| gnome-kit/3.20-prime --------------+-----+--------------------- 0.28.1| 0.28| gnome-kit/3.20-prime --------------+-----+--------------------- * 0.30.1| 0.30| gnome-kit/3.20-prime --------------+-----+--------------------- 0.32.1| 0.32| gnome-kit/3.20-prime In other cases, I get this message when I do have the specified version installed. For instance, on my desktop when emerging @world, I get the following message and nothing gets emerged. !!! The following binary packages have been ignored due to changed dependencies: media-sound/guayadeque-0.4.5_p20170110::gentoo dev-util/itstool-2.0.2::gentoo But these package versions are installed on both the desktop and the server: # ego query versions guayadeque media-sound/guayadeque| slot| repo -----------------------+-----+-------------------- * 0.4.5_p20170110| 0| media-kit/1.1-prime # ego query versions itstool dev-util/itstool| slot| repo -----------------+-----+------------------- * 2.0.2| 0| core-kit/1.0-prime In yet another case, I get this message and emerge wants to do an ebuild even though the binpkg is available. For instance, on desktop #2 when emerging @world: These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild NS ] sys-kernel/debian-sources-4.14.12 [4.14.2] USE="binary" !!! The following binary packages have been ignored due to changed dependencies: sys-kernel/debian-sources-4.14.12::core-kit NOTE: The --binpkg-changed-deps=n option will prevent emerge from ignoring these binary packages if possible. Using --binpkg-changed-deps=y will silence this warning. However, I can run 'emerge -av debian-sources' on that same system and it will install the binary package: These are the packages that would be merged, in order: Calculating dependencies... done! [binary NS ] sys-kernel/debian-sources-4.14.12:4.14.12::core-kit [4.14.2:4.14.2::core-kit] USE="binary" 190,850 KiB Total: 1 package (1 in new slot, 1 binary), Size of downloads: 190,850 KiB Would you like to merge these packages? [Yes/No] All of these machines have the same USE options (make.conf, package.use, epro). I'm constantly fighting this battle to get the machines to use all the binaries built by the server. Can anybody shed some light on this? Am I doing something wrong? Is it a bug?
  2. Which package satisfies a virtual package?

    Thanks dhudson, that's exactly what I was looking for.
  3. How can I find out which installed package satisfies the requirements of a virtual package. For instance, my system has virtual/cron installed. 'equery depgraph virtual/cron' shows this: * Searching for cron in virtual ... * dependency graph for virtual/cron-0 `-- virtual/cron-0 amd64 `-- sys-process/vixie-cron-4.1-r14 (sys-process/vixie-cron) amd64 `-- sys-process/bcron-0.10 (sys-process/bcron) amd64 `-- sys-process/cronie-1.5.0-r1 (sys-process/cronie) amd64 `-- sys-process/dcron-4.5-r1 (sys-process/dcron) amd64 `-- sys-process/fcron-3.2.1-r1 (sys-process/fcron) amd64 [ virtual/cron-0 stats: packages (6), max depth (1) ] * dependency graph for virtual/cron-0-r1 `-- virtual/cron-0-r1 ~amd64 `-- sys-process/cronie-1.5.0-r1 (sys-process/cronie) amd64 `-- sys-process/vixie-cron-4.1-r14 (sys-process/vixie-cron) amd64 `-- sys-process/bcron-0.10 (sys-process/bcron) amd64 `-- sys-process/dcron-4.5-r1 (sys-process/dcron) amd64 `-- sys-process/fcron-3.2.1-r1 (sys-process/fcron) amd64 `-- sys-process/systemd-cron-1.5.4 (sys-process/systemd-cron) amd64 [ virtual/cron-0-r1 stats: packages (7), max depth (1) ] Is there a command that would tell that I have cronie installed, and that is satisfying the requirement of the virtual package? Or do I need to simply go through the above list and check for each package?
  4. A few weeks ago I switched to kits, following the instructions at https://github.com/funtoo/meta-repo. Today I went back to that site and I see the instructions have changed. For instance, the symbolic link is different and several lines have been added near the end of the instructions. What am I supposed to do now? Should I undo what I did a few weeks ago, and follow the new instructions? And is there some method in place to inform me of these changes, so I don't have to get lucky by stumbling across them on the internet?
  5. I have several Funtoo systems, and I use one machine as my build machine. That machine creates binary packages which the other systems are configured to use. The systems all use different video cards, so in make.conf I have: VIDEO_CARDS="intel i915 nouveau radeon r600 vesa" This all worked fine on xorg 1.18.something (I think it was 1.18.4). But after moving to kits, xorg got downgraded to 1.17.4 and I'm having problems. Specifically, xdm is crashing on my system with a radeon video card, because it's trying to load the intel driver. I'm not sure what caused this behavior. To fix it, hopefully temporarily, I've changed make.conf to read: VIDEO_CARDS="nouveau radeon r600 vesa" And then I removed libva-intel-driver and xf86-video-intel. I'm not sure if removing that first package was necessary. After I removed the second one, xdm would start up. How can I fix this? I'd really like to be able to build my xorg packages with the intel drivers included so that my packages work on all my machines, like they used to.
  6. 'equery list --portage-tree' with kits

    Thanks dhudson. That command seems to give the info I needed.
  7. Change to kits and python confusion

    Thanks pytony. Is that something that needs to be run regularly, or only under certain conditions?
  8. Prior to the introduction of kits, 'equery list --portage-tree <package>' would show me all versions of <package> available, and indicate which version(s) I had installed. Now that I'm using kits, it produces no useful output. Is this a bug? Or is there a new option I can use instead of --portage-tree?
  9. Change to kits and python confusion

    I'd like to know what 'epro update' does as well. I've seen it referenced a few times on this forum. But 'man epro' does not contain any info on the 'update' option. I'm still wading my way through the change to kits, and it's not clear to me if I need to run 'epro update'.
  10. xorg conflicts

    This worked, thanks. And a subsequent 'emerge -auDN @world' worked as well, with no errors. I've seen this before -- sometimes packages fail to upgrade during 'emerge -auDN @world', but the same packages can be upgraded via 'emerge packagename'. Can anybody tell me why?
  11. xorg conflicts

    Actually, I was able to upgrade @world by excluding only xf86-input-evdev. So I am fully updated except for some xorg-related stuff. Any ideas what I should do to update those? Am I going to have to unmerge them all, then emerge them again? (And hope that nothing goes wrong?) # emerge -auDN @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD ] x11-base/xorg-drivers-1.17 [1.18-r1] [ebuild UD ] x11-base/xorg-server-1.17.4-r2 [1.18.4] USE="nptl%*" [ebuild UD ] x11-drivers/xf86-input-evdev-2.9.2 [2.10.3] [blocks b ] >=x11-drivers/xf86-input-evdev-2.10 (">=x11-drivers/xf86-input-evdev-2.10" is blocking x11-base/xorg-server-1.17.4-r2) Oops! Conflicts have been encountered: >>> x11-drivers/xf86-video-nouveau-1.0.12:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-video-vesa-2.3.4:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-input-synaptics-1.8.3:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-input-keyboard-1.8.1:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-input-mouse-1.9.1:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-video-vmware-13.1.0:0/0::xorg-kit, installed, wants x11-base/xorg-server:0/1.18.4= My candidates are: >>> x11-base/xorg-server-1.17.4-r2:0/1.17.4::xorg-kit, ebuild scheduled for merge has SLOT 0/1.17.4 >>> x11-base/xorg-server-1.18.4:0/1.18.4::gentoo, installed has SLOT 0/1.18.4 >>> x11-base/xorg-server-1.18.4:0/1.18.4::gentoo, installed, wants >=x11-base/xorg-drivers-1.18 My candidates are: >>> x11-base/xorg-drivers-1.17:0/0::xorg-kit, ebuild scheduled for merge has SLOT 0/0 >>> x11-base/xorg-drivers-1.18-r1:0/0::gentoo, installed has SLOT 0/0 We hope this informational output has been useful in identifying the problem. We are continually working to reduce conflicts. Do not hesitate to report a bug at https://bugs.funtoo.org. Thank you! :)
  12. xorg conflicts

    # emerge -av xorg-server xf86-input-synaptics xf86-video-vesa xf86-input-mouse xf86-video-nouveau xf86-input-keyboard These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD ] x11-base/xorg-server-1.17.4-r2:0/1.17.4::xorg-kit [1.18.4:0/1.18.4::gentoo] USE="ipv6 kdrive nptl%* suid udev xephyr xnest xorg -dmx -doc -glamor (-libressl) -minimal (-selinux) -static-libs (-systemd) -tslib -unwind -wayland -xvfb" 5,656 KiB [ebuild R ] x11-drivers/xf86-input-synaptics-1.8.3::xorg-kit [1.8.3::gentoo] 473 KiB [ebuild R ] x11-drivers/xf86-video-vesa-2.3.4::xorg-kit [2.3.4::gentoo] 279 KiB [ebuild R ] x11-drivers/xf86-input-mouse-1.9.1::xorg-kit [1.9.1::gentoo] 341 KiB [ebuild R ] x11-drivers/xf86-video-nouveau-1.0.12::xorg-kit [1.0.12::gentoo] 586 KiB [ebuild R ] x11-drivers/xf86-input-keyboard-1.8.1::xorg-kit [1.8.1::gentoo] 312 KiB [blocks B ] >=x11-drivers/xf86-input-evdev-2.10 (">=x11-drivers/xf86-input-evdev-2.10" is blocking x11-base/xorg-server-1.17.4-r2) Total: 6 packages (1 downgrade, 5 reinstalls), Size of downloads: 7,645 KiB Conflict: 1 block (1 unsatisfied) Oops! Conflicts have been encountered: >>> x11-base/xorg-server, wants xorg-server >>> x11-drivers/xf86-input-evdev-2.10.3:0/0::gentoo, installed, wants >=x11-base/xorg-server-1.18[udev] >>> x11-drivers/xf86-input-evdev-2.10.3:0/0::gentoo, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-video-vmware-13.1.0:0/0::gentoo, installed, wants x11-base/xorg-server:0/1.18.4= My candidates are: >>> x11-base/xorg-server-1.17.4-r2:0/1.17.4::xorg-kit, ebuild scheduled for merge has SLOT 0/1.17.4 >>> x11-base/xorg-server-1.18.4:0/1.18.4::gentoo, installed has SLOT 0/1.18.4 We hope this informational output has been useful in identifying the problem. We are continually working to reduce conflicts. Do not hesitate to report a bug at https://bugs.funtoo.org. Thank you! :) * Error: The above package list contains packages which cannot be * installed at the same time on the same system. x11-drivers/xf86-input-evdev-2.10.3:0/0::gentoo, installed pulled in by x11-drivers/xf86-input-evdev required by x11-base/xorg-drivers-1.18-r1:0/0::gentoo, installed For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage#Blocked_packages
  13. xorg conflicts

    After following the instructions at https://github.com/funtoo/meta-repoI attempted to 'emerge -auDN @world'. It's not going well. I'm getting the following message. Oops! Conflicts have been encountered: >>> x11-drivers/xf86-input-synaptics-1.8.3:0/0::gentoo, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-video-vesa-2.3.4:0/0::gentoo, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-input-mouse-1.9.1:0/0::gentoo, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-video-nouveau-1.0.12:0/0::gentoo, installed, wants x11-base/xorg-server:0/1.18.4= >>> x11-drivers/xf86-input-keyboard-1.8.1:0/0::gentoo, installed, wants x11-base/xorg-server:0/1.18.4= My candidates are: >>> x11-base/xorg-server-1.17.4-r2:0/1.17.4::xorg-kit, ebuild scheduled for merge has SLOT 0/1.17.4 >>> x11-base/xorg-server-1.18.4:0/1.18.4::gentoo, installed has SLOT 0/1.18.4 >>> x11-base/xorg-server-1.18.4:0/1.18.4::gentoo, installed, wants >=x11-base/xorg-drivers-1.18 My candidates are: >>> x11-base/xorg-drivers-1.17:0/0::xorg-kit, ebuild scheduled for merge has SLOT 0/0 >>> x11-base/xorg-drivers-1.18-r1:0/0::gentoo, installed has SLOT 0/0 We hope this informational output has been useful in identifying the problem. We are continually working to reduce conflicts. Do not hesitate to report a bug at https://bugs.funtoo.org. Thank you! :) I'm still a little unclear how kits are supposed to work, so it's possible I've done something wrong. I was running Funtoo stable, and I'd like to minimize my daily updates. So /etc/ego.conf does not have any kits defined.
  14. That @#*!^ social media slider

    Thank you. Blocking addthis.com removed it.
  15. That @#*!^ social media slider

    Firefox 55.0.3 on Windows, in this particular case. I am running Adblock Plus, but right-clicking the slider does not give me a "block this..." option. I see now that if I make my web browser window wider (wider than I consider comfortable for reading a lot of text), the slider will end up in a border as the text centers itself in the too-wide browser window. If I had to estimate, it requires the web browser to be at least 1000 pixels wide for the slider to uncover the text. I guess I could use that as a workaround, but I'd still really like to know how to hide or remove it.
×