Jump to content

dkg

Members
  • Content Count

    73
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by dkg

  1. The 'emerge --emptytree' would do this anyway, dummy! :) Never mind, folks.
  2. I'm curious. The Upgrade Instructions have one upgrade gcc, then set the subarch. It seems you'd want subarch turned on beforehand so the gcc binary gets the benifits of the optimizations. Or, if that doesn't work because the older gcc doesn't work with the subarch profiles, then it seems best to 'emerge -u1 gcc', then 'epro subarch', then 'emerge -1 gcc'. Is this a waste of effort?
  3. Are you saying that there are steps I should follow to avoid 1.3? I did not put 1.3 in ego.conf, if that's what you mean.
  4. I was following those steps. I didn't touch ego.conf. I tried to upgrade ego, and got the errors about PYTHON_TARGETS above.
  5. [root@wolfie 61% ego]# emerge -1 ego These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-admin/ego-2.4.2 [2.4.0] PYTHON_SINGLE_TARGET="-python3_4* -python3_7%" PYTHON_TARGETS="-python3_4* -python3_7%" Would you like to merge these packages? [Yes/No] y >>> Verifying ebuild manifests >>> Emerging (1 of 1) app-admin/ego-2.4.2::core-kit >>> Failed to emerge app-admin/ego-2.4.2, Log file: >>> '/var/tmp/portage/app-admin/ego-2.4.2/temp/build.log' >>> Jobs: 0 of 1 complete, 1 failed
  6. Sync was successful. I did the above. Still had issues getting ego to merge. I had to add PYTHON_SINGLE_TARGET and PYTHON_TARGETS to make.conf for some reason. Had to use this to turn ignore a file collision with a man page for boot.conf: [root@wolfie 61% ego]# FEATURES="-collision-detect -protect-owned" ebuild ego-2.5.0.4.ebuild merge Got this QA warning: * QA Notice: Symbolic link /usr/sbin/boot-update points to /usr/sbin/ego which does not exist. [root@wolfie 61% portage]# whereis ego ego: /usr/bin/ego /etc/ego.conf /usr/share/ego /usr/share/man/man1/ego.1.bz2 But at th
  7. Good catch! It seems to be doing a lot more now.
  8. Also, you might have missed it, but one of the logs in the initial post shows that I tried to clone ego from git and run 'ego sync' with that.
  9. Not so easy, when 1) I can't sync to pull an updated ego ebuild, and 2)... [root@wolfie 61% make.profile]# emerge -tuND --pretend ego !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Empty parent file: '/etc/portage/make.profile/parent' !!! /etc/portage/make.profile is not a symlink and will probably prevent most merges. !!! It should point into a profile within /var/git/meta-repo/kits/core-kit/profiles/ !!! (You can safely ignore this message when syncing. It's harmless.) !!! Your current profile is invalid. If you have just changed your profile !!! configurati
  10. I was trying, but 'ego sync' (esentially the first in there as the first steps would have been done at the end of the last upgrade) went awry.
  11. I have a system that hasn't been updated in a few months. I know it was updated to kits, but not yet to 1.2, which is what I was fixing to do today. Started with 'ego sync', which had an error. At that point profiles seemed to be trashed (0-length parent file), and various [ignorant] efforts to recover did not work out. Where do I need to start? [root@wolfie 61% backup-parts]# ego sync Syncing meta-repo remote: Enumerating objects: 200, done. remote: Counting objects: 100% (200/200), done. remote: Compressing objects: 100% (101/101), done. remote: Total 1073 (delta 102), reused 195 (de
  12. When I checked my container last week, I found that it was running a patched kernel.
  13. dkg

    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.
  14. dkg

    Local overlay woes

    And how do I do that?
  15. 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 ...
  16. 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. :)
  17. 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.
  18. 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
  19. 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.
  20. 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 wa
  21. 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 po
  22. Where on your system is this PORTDIR set?
  23. [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.
  24. 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.)
×
×
  • Create New...