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 error: # /root/metro/scripts/autosetup No boto available; ec2 support disabled. Traceback (most recent call last): File "/root/metro/scripts/autosetup", line 467, in <module> available_builds = auto_setup.parseMirrorDirectory(possible_builds) File "/root/metro/scripts/autosetup", line 99, in parseMirrorDirectory stage = stage[:rel_tag] TypeError: slice indices must be integers or None or have an __index__ method I missed something. I probably need to clean out setup files or otherwise. Don't need the arm processor just X86_64 (which seems to be a default with qemu). Something is missing here

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 partition % mount /dev/sda3 /mnt/funtoo === mount boot partition % mount /dev/sda1 /mnt/funtoo/boot % cd /mnt/funtoo % mount -t proc none proc % mount --rbind /sys sys # rebind % mount --rbind /dev dev # rebind % cp -L /etc/resolv.conf /mnt/funtoo/etc === link network resolv === set environment, terminal - start chroot in cwd using bash === flag -l (lower case L) Make bash act as if invoked as login shell === NOTE: now in chroot environment - working with mounted/to be rescued system % env -i HOME=/root TERM=$TERM /bin/chroot . bash -l % ping -c4 google.ca # we have network? === ... === proceed to fix === probably re-install kernal or other === emerge actions === ... === and we're done. % exit # leave chroot environment % cd # change cwd to root home === unmount lazy and recursive % umount -lR /mnt/arch % eject # remove cd % reboot === process complete

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 vendor: Realtek Semiconductor Co., Ltd. A swath of networking devices utilize the RealTek chipset. This requires a binary blob that is available standalone or as part of linux-firmware. This may be missing for you. If you have IRC, jump on and we can sort this out for you. Stay strong...you're not alone.

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 audio hardware acceleration (USE flag `vaapi` was not set in the profile for my card) Bug FL-6636 and PR# 155 issued to address. tl;dr - check USE flags are correct for your HW (AMD cards r100/r200 and earlier, r300->r500, r600->N.Islands, S.Islands and later) Flags to confirm vdpau, vaapi. Fingers crossed, but I believe this will resolve the problem for me. Recompiling...

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