digifuzzy

Following Metro Autosetup steps from here and here. During run, I get an error message: Metro encountered an error: Command failure (key steps/chroot/run, return value 1) : /usr/bin/chroot /var/tmp/metro/work/funtoo-current/stage1-amd64-bulldozer-funtoo-current-2019-09-16 /tmp/steps/chroot/run.metro Incrementing failcount. build failure Something went wrong during building. See log for details So where's the log file? Doing an `ls /var/log` doesn't show anything metro related. Is there a configuration step missing? Re-exec Metro autobuild step I'm getting a consistent e

Yeah! I like this idea. To extend, here's what I use for "chroot" into a funtoo when using SysResCD: Funtoo Rescue with SysResCD --------------------------------------- - insert SysResCD and reboot PC - verify partitions with fdisk -l /dev/sda or gparted - assuming: boot => sda1(ext2) swap => sda2(swap) root => sda3(ext4) use open terminal prompt for remaining commands: (NOTE: SysResCD terminal is ROOT!!!!) (NOTE: SysResCD root prompt -> '%') (NOTE: Funtoo root prompt -> '#') === activate swap partition % swapon /dev/sda2 % mkdir -p /mnt/funtoo === mount root partitio

Doing an emerge of a package marked "8046" to "1.2019.9" is seen by emerge as a downgrade. I wasn't sure of the "practical", "portage" way to handle or otherwise convince portage to ignore of consider a revision regex pattern to be less than current. I had to throw the question out to the studio audience.

Thanks for sharing!

media-gfx/plantuml is java-based software that enables text-based UML diagram generation (similar in nature to graphviz but focused on UML). Latest available in tree is version 8046 (or July 2016). Newer versions(v1.2019.9) are available and tweaking ebuild to build this package with latest software works well. However, portage becomes an issue. Using the newer ebuild as plantuml-1.2019.1 looks to portage as a "downgrade". Short-term fix is to mask package earlier versions (i.e. >=media-gfx/plantuml-8046). How to best to handle definitively change in versioning scheme?

For future web searchers... relevant man pages: https://linux.die.net/man/5/dir_colors https://linux.die.net/man/1/dircolors

FWIW, upgrade to conky is held back because of lua version. Latest conky wants lua-5.3 while 1.3-release uses lua 5.1.x As you pointed out...this isn't a rolling release. This is that cost/benefit of rolling release vs stable release as you allude to.

We tried... 🙂 If it's any consolation, I'm having issues with latest debian-stable-lts as well. Something went wrong moving from 4.9 to 4.19. We'll get this sorted out.

Let's walk through this.... Need HW information. Do `emerge -a1 lshw`. We'll use the package executable to query stuff. Execute `lshw -C network` will produce details about the ethernet devices in your computer (both wired and wireless). From the output, we'll get insight about chipset. That'll be needed to determine if correct drivers are available/installed. (modprobe stuff we'll do later). For my box: # lshw -C network *-network description: Ethernet interface product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller v

For the intrepid web searcher looking to solve this problem for themselves, here's what I did... - VLC (v3.0.7.1) downgraded v3.0.6.x (no change) - restored VLC to latest and re-installed ffmpeg, x264, x265, et al (no change) - discovered that ffmpeg has command line access (`$ ffplay [filename]) - audio normal and no distortion - recalled VLC had similar functionality (`$ cvlc [filename]) - distortion All this was going on concurrent to situation with determination of correct video card settings (see forum post Confirm Video Card Settings - 1.4-release) Discovered that video

Addressed in FL-6636 and Pull Request# 155 New 1.4-release VIDEO_CARDS mix-ins had amalgamated cards too much. New profiles were needed to separate out and better represent AMD historical product line.

So it looks like I have "conflating" issues. I have posted elsewhere about poor audio quality in VLC. Digging into that issue produced the following message: $ vdpauinfo display: :0.0 screen: 0 Failed to open VDPAU backend libvdpau_r600.so: cannot open shared object file: No such file or directory Error creating VDPAU device: 1 So r600 setting for a AMD/ATI Caicos (Northern Islands card) is probably bad.

There we go... Winner!

@cardinal - more noise. Found an OpenSuse patch (tweaked for compatibility to ebuild ecosystem) the just stomps on a bunch of function calls in the chrome source that have non-void returns but do not return a value. I'm testing on my system now (insert several hours of "Jeopardy Thinking Music" playing in the background) but you may find it useful. Patch applicable to QtWebengine 5.12.3/5.12.4 3rdParty Chrome (v75.*). Let me know if this works for you. qtwebengine-5.12.3-chromium-non-void-return.patch

Yes - hidden files in /etc/skel. No - not helpful as these are set to upstream default. No on grc being installed but it is a possibility. Concern is would this package conflict with what Funtoo does. I was hoping someone with distribution knowledge could chime in to explain how Funtoo implemented this as it seems this is specific to this distribution and not "generic linux".