Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


librin.so.1 last won the day on February 20 2019

librin.so.1 had the most liked content!

About librin.so.1

  • Rank


  • freenode


  • Location
    Kaunas, Lithuania
  • Interests
    I program in C and such.
    I also "click heads" in games such as CSGO and the like.

Recent Profile Visitors

1,066 profile views
  1. So I tried this ebuild today and it doesn't build. From the looks of it, clang version handling has changed in funtoo and now the ebuild fails to find the right clang dependency: * Package: www-client/firefox-78.4.1 * Repository: local * USE: amd64 dbus elibc_glibc eme-free hardened kernel_linux l10n_lt lto pgo pulseaudio system-av1 system-jpeg system-libevent userland_GNU * FEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox * Checking for at least 13 GiB disk space at "/var/tmp/portage/www-client/firefox-78.4.1/temp" ... [ ok ] * sys-devel/clang:9 is m
  2. I have 1.6.5, too and I have grep'd through my entire rootfs and only other references to virtfn I found were in the kernel source code under /usr/src/linux and not a trace anywhere else. This confused me a bit, on how virtfn variable is handled on the userspace side at all. That's one of the reasons I ended up asking here – I ran out of ideas on how to figure it out myself without employing some very tedious and time-consuming approaches.
  3. okay, here it is: template=interface-noip virtfn=1 trunk=net.intl mac_replace="[redacted]"
  4. Hello, so I looked into the recently added documentation on SR-IOV Device Configuration under the Networking page on wiki and I see this, quote: but if I do treat is as optional, as the wiki says and not set it, it all errors out: root@g44:~# rc-service net.test start net.test | * Caching service dependencies ... * ERROR: Required configuration variable(s) are missing: * * vlan * * Please correct your configuration to address this issue.
  5. [6] · In email notifications about new replies to threads, opening the "Go to this post:" link always gives me the same error message: Sorry, there is a problem We could not locate the item you are trying to view. Error code: 2S136/C
  6. This forum has several issues that together make it seem like it is semi-broken. (Although, I can see how #2 through #5 could be intentional, but I really hope they're not.) [1] · My user (and apparently, a few of others) are stuck at zero post count for some reason. EDIT: making my sixth? (not sure; didn't count) post now gave me a post count of one. What the... [2] · The post writing interface appears to lack a switch to disable the WYSIWYG mode and go to plain-text mode which allows to manipulate the whichever underlying markup language directly. I consider this very much a bug.
  7. If You're referring to the 32-bit chroot wiki page, then indeed, it fails to mention that the host's epro profiles, flavors and mix-ins (which otherwise likely provide the "X" use flag for You) do not carry over to the chroot and thus need to be set there independently. Likewise with other portage, package and use flag settings (i.e. anything under /etc/portage). I suppose this should be fixed. I'll try to edit the page later. If You're referring to my "guide" I posted in this thread, then yes, this information is not mentioned as it is not essential. The "guide" is purposely barebones, a
  8. Just keep in mind that with running a different funtoo version in a chroot, You need to keep the portage trees separate. So if You are following that 32-bit chroot guide from the wiki, You'd need to modify the given scripts and commands to keep /var/git/meta-repo on the host and the chroot separate. Sorry I forgot to mention this at first. In general, though, You can not just only run a different version of funtoo, but even run Ubuntu, Arch, Fedora or whatever distro in a chroot.
  9. Tarballs of what? If You mean funtoo stage3 tarballs, just use a 1.3 tarball for the chroot. It's not like the chroot has to match the base OS in version or anything.
  10. Okay, first of all, I am sorry I did not post this earlier, even though I had this stopgap of a workaround effectively ready two weeks ago, yet I've been swamped with work. I may or may not have forgotten some minor, yet important steps as while doing it myself I encountered with a lot of strange c**p and I am not sure if my sleep-deprived self at that time memorized every bit, so if anything seems missing / out of place /simply does not work if You try this Yourself, do point out and I shall do my best to fix this post up. Either way, as my base goal from which I can improve upon, I set
  11. So I noticed multilib support is being removed with the 1.3 release. I personally welcome moving to pure AMD64 and have done so ages ago on most machines I manage, but then there's all that pesky proprietary software that cannot be recompiled at-will. I've seen the wiki guide on running a x86 chroot as a workaround, but it looks like it creates a purely AMD64 system with a purely x86 system in a chroot. But I'd like to clear something out: with this particular approach, is it possible to somehow fuse the base system with whatever is in the chroot to make a makeshift multilib-like sys
  • Create New...