Jump to content
funtoo forums

dkg

Members
  • Content count

    46
  • Joined

  • Last visited

  • Days Won

    3

dkg last won the day on December 4 2017

dkg had the most liked content!

About dkg

  • Rank
    Advanced Member

Recent Profile Visitors

99 profile views
  1. Local overlay woes

    Got it. I guess I was expecting some command to do this. It seems strange as I've been using gentoo/funtoo for so long, but I must have never downloaded an ebuild that needed a patch before. Thanks.
  2. Local overlay woes

    And how do I do that?
  3. Local overlay woes

    I wanted to try out the latest version of darktable, v2.4.0. So, I downloaded the gentoo ebuild, put in in my local overlay, and ran 'ebuild darktable-2.4.0.ebuild manifest'. Then I ran 'emerge -u darktable'. But I got the following error: >>> Preparing source in /var/tmp/portage/media-gfx/darktable-2.4.0/work/darktable-2.4.0 ... * Applying darktable-find-opencl-header.patch ... /var/tmp/portage/media-gfx/darktable-2.4.0/temp/environment: line 1029: /var/tmp/portage/media-gfx/darktable-2.4.0/files/darktable-find-opencl-header.patch: No such file or directory [ !! ] * ERROR: media-gfx/darktable-2.4.0::chopin failed (prepare phase): * patch -p1 failed with /var/tmp/portage/media-gfx/darktable-2.4.0/files/darktable-find-opencl-header.patch What have I done wrong?
  4. Meltdown patches

    Hi. Perhaps you didn't notice this was posted in the Funtoo Hosting forum. I configure and compile my own kernels usually, but this is a completely different situation. :)
  5. Meltdown patches

    Hi. I understand that the containers share the kernel on the host, and that the host kernel needs to be updated. What I do not now, not being familiar with OpenVZ, is whether something additional needs to happen with the container, like rebooting it. However, I did reboot my container yesterday, and did not see an updated kernel. Any timeline on when the host kernels will get patched? I saw on the OpenVZ support forums that they released a new kernel.
  6. Meltdown patches

    Is there something that I need to do? I don't seem to have a new kernel. $ uname -a Linux dkg 2.6.32-042stab123.3 #1 SMP Sun Jun 4 01:36:20 MDT 2017 x86_64 Intel(R) Xeon(R) CPU X5650 @ 2.67GHz GenuineIntel GNU/Linux
  7. Meltdown patches

    Any insights on Meltdown patches for containers? I assume they are vulnerable (Intel Xeon), and that there is nothing I can do to patch it myself.
  8. Let me preface this post by saying I hope it will be constructive. It's not my intention to simply complain or vent. I wanted to share my experience updating one of my funtoo systems the past two days, because I feel that kits (so far) may not be living up to their promise. I had hoped they would smooth over some of the headaches of system upgrades. My upgrade process went something like this: Blockers where USE=qt4 had to be added to several packages, successively. That is... emerge @world; long wait; portage reports package needs USE=qt4; add USE flag; emerge @world; long wait; portage reports package needs USE=qt4; add USE flag; emerge @world; long wait; portage reports package needs USE=qt4; and so on. Blocker related to libreoffice. I had earlier keyworded libreoffice for stable only, as I really don't need the latest and it's a beast to build. Well, at this time there isn't a single stable ebuild in the tree. Oddly, there is still a stable ebuild for libreoffice-l10n. Anyway, I had to remove the stable keyword. To resolve some other blockers, I ended up using 'emerge -C' on 5 packages (e.g., kget and media-sound/picard). I kept a list of these so I could re-merge them at the end. I removed the 'legacy-systray' USE flag from plasma-desktop to resolve some other blockers. About this time, I was finally able to get it to start installing some updates. I'm getting odd build failures for virtualbox-modules, which I ignore for now and use '--keep-going' (will come back to this). Encountered a build failure in package pambase. With research, found an issue in the tracker that was fixed yesterday morning, so needed to 'ego sync' mid-upgrade. Now, it's 'emerge @preserved-rebuild' time, but it's blocked by a conflict with package doomsday. Use 'emerge -C doomsday' to resolve. I think it was here that I dealt with the app-emulation/wine to virtual/wine change. Not terrible, though I was a bit confused why I seem to need wine-vanilla if all I want is wine-staging. Perhaps I could if I emerge 'app-emulation/wine-staging' directly instead of going through 'virtual/wine'? I didn't want to stop the upgrade at this time to figure it out. Time to resolve issue with virtualbox-modules. It's giving multiple complaints that it "can't find Makefile" and "can't find .config file", and that I need to make sure that '/usr/src/linux' points to a full kernel source tree. I check, there is nothing wrong with the symlink, it points to the folder for the current running kernel, the folder contains a Makefile and .config file, and the folder still contains sources. The only possible problem I can figure is the ebuild for this kernel is no longer in the portage tree. So, I stop to upgrade the kernel, and the problem goes away. Now it's time to re-merge the packages I removed earlier, one of which is quodlibet. Only, portage complains it can't install the latest quodlibet because of some funky python issue with package dev-python/faulthandler I don't understand. I find no mention of this in JIRA or forums, so I just let it install the old version. I've just now discovered that portage is no longer picking up my local overlay. I'll need to research that, too. It's certainly wasn't the most painful gentoo/funtoo upgrade I've ever been through, but I can't really say it was any easier than typical. Especially considering this was a shorter upgrade cycle than usual for me (only about a month), and I keep customizations on this system to a minimum. Anyway, as I said at the outset, I wanted to share my experience in the hopes it is constructive. Cheers!
  9. Getting eix to work with kits

    This was very helpful. Your output... open("/etc/portage/repos.conf/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 My output... open("/etc/portage/repos.conf/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 EACCES (Permission denied) It turns out that /etc/portage/repos.conf/ is owned by root:root. Presumably, eix is using the portage user, and in combination with my default umask=077, it did not have permission. It's not a problem for /var/git/meta-repo/ because it is owned by portage:portage. I had adjusted the permissions of /var/git/meta-repo/ and one point, but never touched /etc/portage/repos.conf/. Occasionally, umask=077 does lead to some oddities. I have it working now. Thank you.
  10. Getting eix to work with kits

    Where on your system is this PORTDIR set?
  11. Getting eix to work with kits

    No /etc/repos.conf.
  12. Getting eix to work with kits

    [root@chopin ~]# cat /var/git/meta-repo/repos.conf/default [DEFAULT] main-repo = core-kit You have no /etc/eixrc or ~/.eixrc files? For the record, I do not. Do you have PORTDIR set somewhere? I do not. Yet, 'eix --print PORTDIR' returns '/usr/portage', which is wrong.
  13. Getting eix to work with kits

    I'm sorry. I fail to see how this will get eix to stop looking for /usr/portage. Will it fix the warnings? Is this what you have done to get eix to work? (I have no /usr/share/portage/config/repos.conf file, by the way.)
  14. Getting eix to work with kits

    I'm having trouble understanding your instructions. You say to "copy all the kits". Copy them from where? Are you saying to copy the files in /var/git/meta-repo/repos.conf/? Then you say that I will have 'ego-core-kit linking to...'. Um. If I copy files, then they will be files, not links. Unless you are talking about the locations in those files. If so, then I would have to change all the locations in the files, no? [root@chopin ~]# cat /var/git/meta-repo/repos.conf/core-kit [core-kit] location = /var/git/meta-repo/kits/core-kit auto-sync = no priority = 1 [root@chopin ~]# cat /var/git/meta-repo/repos.conf/chopin.conf [chopin] location = /var/git/overlay/chopin masters = core-kit auto-sync = no priority = 10
  15. Getting eix to work with kits

    Another point. Earlier I said this... I figured out that difference. On the other system I had deleted /usr/portage, as it did not have space for both trees. If I do 'mv /usr/portage /usr/portage.old && eix-update' on this system, then I get the same empty results as the other system.
×