dkg

When I checked my container last week, I found that it was running a patched kernel.

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.

And how do I do that?

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?

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

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.

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

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.

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!

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.

Where on your system is this PORTDIR set?

No /etc/repos.conf.

[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.

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.)

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