Re: [gentoo-user] Re: find atime vs lsof
On Saturday, 27 July 2019 10:36:04 BST Adam Carter wrote: > On Saturday, July 27, 2019, Mick wrote: > > On Saturday, 27 July 2019 06:15:49 BST Adam Carter wrote: > > > Some time back i moved from vmware to virtualbox, and am currently > > > wondering if there are some old vmware files i can remove. Virtualbox > > > > uses > > > > > the old vmware disk files, so first i checked via atime and lsof. > > > > > > Why does atime not show all the files that lsof shows were open? > > > > They are snapshots and unless saved I would think they are removed when > > you > > shut down VBox. > > Pretty sure they are the vmware disk files and are used by vbox Hmm ... I only have two files being accessed here on a running VBox Windows 7 VM. 'VBox.log' and 'MSWindows7_dyn.vdi' > There were other snapshot files that ive already moved, and as expected it > didn’t cause vbox any problems > > > Incidentally, I can't start VMs when the gentoo host is running kernel > > 4.19.57. I get an error about "Failed to attach the network LUN > > (VERR_INTNET_FLT_IF_NOT_FOUND)." Kernel 4.19.52 works fine. > > > > Are you getting any such problems? > > > > Im on 5.2. Did you rebuild the modules for the new kernel? Yes, I did and checked they are loading. I'll check again. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] find atime vs lsof
On Saturday, 27 July 2019 06:15:49 BST Adam Carter wrote: > Some time back i moved from vmware to virtualbox, and am currently > wondering if there are some old vmware files i can remove. Virtualbox uses > the old vmware disk files, so first i checked via atime and lsof. > > Why does atime not show all the files that lsof shows were open? They are snapshots and unless saved I would think they are removed when you shut down VBox. > Steps were; > 1. start vm > 2. create and save dummy file in vm > 3. run lsof on vm PID > 4. shut down mv > 5. run find to see which files were accessed > > # lsof -p 2299 | grep 'VIRTUALS/Win-10-x64' > VirtualBo 2299 adam 42u REG 259,2 2453 10095159 > /home/adam/VIRTUALS/Win-10-x64/Windows 7 x64.vmdk > VirtualBo 2299 adam 44u REG 259,2 2146762752 10094024 > /home/adam/VIRTUALS/Win-10-x64/Windows 7 x64-s001.vmdk > VirtualBo 2299 adam 45u REG 259,2 2146762752 10094071 > /home/adam/VIRTUALS/Win-10-x64/Windows 7 x64-s002.vmdk > VirtualBo 2299 adam 46u REG 259,2 2146762752 10094011 > /home/adam/VIRTUALS/Win-10-x64/Windows 7 x64-s003.vmdk > VirtualBo 2299 adam 47u REG 259,2 2146762752 10094108 > /home/adam/VIRTUALS/Win-10-x64/Windows 7 x64-s004.vmdk > VirtualBo 2299 adam 48u REG 259,2 2146762752 10094076 > /home/adam/VIRTUALS/Win-10-x64/Windows 7 x64-s005.vmdk > VirtualBo 2299 adam 49u REG 259,2 2146762752 10094127 > /home/adam/VIRTUALS/Win-10-x64/Windows 7 x64-s006.vmdk > VirtualBo 2299 adam 50u REG 259,2 2146762752 10094050 > /home/adam/VIRTUALS/Win-10-x64/Windows 7 x64-s007.vmdk > VirtualBo 2299 adam 51u REG 259,2 2146762752 10094087 > /home/adam/VIRTUALS/Win-10-x64/Windows 7 x64-s008.vmdk > VirtualBo 2299 adam 52u REG 259,2 2146762752 10094031 > /home/adam/VIRTUALS/Win-10-x64/Windows 7 x64-s009.vmdk > VirtualBo 2299 adam 53u REG 259,2 2146762752 10094102 > /home/adam/VIRTUALS/Win-10-x64/Windows 7 x64-s010.vmdk > VirtualBo 2299 adam 54u REG 259,2 2146762752 10094021 > > > # find VIRTUALS/Win10-vbox/ -atime -1 -type f > VIRTUALS/Win10-vbox/Win10-vbox.vbox > VIRTUALS/Win10-vbox/Logs/VBox.log > VIRTUALS/Win10-vbox/Logs/VBox.log.1 > VIRTUALS/Win10-vbox/Win10-vbox.vbox-prev > # Incidentally, I can't start VMs when the gentoo host is running kernel 4.19.57. I get an error about "Failed to attach the network LUN (VERR_INTNET_FLT_IF_NOT_FOUND)." Kernel 4.19.52 works fine. Are you getting any such problems? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ntp-client slows down the boot process
On Friday, 26 July 2019 16:49:25 BST Rich Freeman wrote: > On Fri, Jul 26, 2019 at 11:32 AM YUE Daian wrote: > > I switched to a faster NTP server. It still takes some seconds but > > better than before. > > > > Maybe you are right. Having correct system time is more important than > > several seconds... > > You're never going to make NTP fast unless you're using a VERY > low-latency server - like something on your own LAN. That is just the > nature of the protocol - it has to do a round trip, and of course to > do anything it needs the interface up, DNS, and so on, and all of > these will be starting from cold caches. If you have non-local DNS > and non-local NTP then that is multiple round-trips to the internet. > > > By the way does "rc_parallel" really makes a difference? > > I tried it once before but did not really see much difference. > > I haven't used OpenRC in ages, but I'm guessing that NTP is set as a > dependency somewhere in the chain. It does make sense - lots of > services do not like abrupt time changes so generic dependencies will > probably assume that you want to set your clocks before starting > anything. > > I'm not sure how ntpdate implements time changes. I know that ntpd > will slew the clock gradually for small corrections, but it is a > daemon so it can easily implement something like that. A one-shot > correction will probably be instant, and thus will be more of an > impact on other services. > > You can probably adjust the dependencies to suit your tastes, but of > course you'll have to keep in mind that time changes for running > services might or might not be a problem. If you're fairly confident > in your hardware clock accuracy (assuming you even have one) that > isn't a big deal. If you're talking about some system that doesn't > keep time when powered off/etc then you probably don't want your > database server to spin up thinking it is 1980 or whatever its epoch > is. > > I did a quick check of what is being done with systemd and ntpdate is > needed before the time-sync target, and that is needed before starting > cron or any timer units (obvious requirement), and it is also required > before spinning up libvirt guests, which also makes sense so that > those initialize with a clean clock, though if they update themselves > maybe that isn't a hard requirement. Just a thought - is the hwclock service in the boot run level and running? I think it will restore the time stored on the hwclock to the system and then gradually update it as the ntp-client starts communicating with various time servers. At least this is how chrony does it. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ntp-client slows down the boot process
On Friday, 26 July 2019 15:23:11 BST YUE Daian wrote: > On 2019-07-26 09:30, Peter Humphrey wrote: > > On Friday, 26 July 2019 05:36:29 BST YUE Daian wrote: > >> Hi folks, > >> > >> I use ntp-client to synchronize the date/time of my Gentoo system. > >> > >> I added it to the default boot level (OpenRC), however it seriously > >> slows down the boot process (around 10 seconds or so). > >> > >> Is there any way to make it faster? Or am I using the wrong service? > > > > It may be taking time to gather entropy. In that case you could install > > sys- apps/haveged and add it to your boot run-level. > > Well, I presume the problem is related to ntpdate itself. > > It is working in a blocking way that the remaining boot processes have > to wait until the time got synchronized. Or, until the network is up and a time server can be contacted? > Is there any way to make it update the time in an asynchronize way? > Or should I use ntpd instead? > > Thanks. > > Danny I don't run ntp-client here, but have a look at its startup script and any dependencies defined therein, then perhaps tweak /etc/rc.conf. Does setting rc_depend_strict="NO" makes a difference? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Can't compile x11-libs/libXt
On Tuesday, 23 July 2019 16:01:01 BST Raffaele Belardi wrote: > > Am 23.07.19 um 01:31 schrieb Jack: > >> On 2019.07.22 09:02, Jens Pelzetter wrote: > >>> Hello everyone, > >>> > >>> recently x11-libs/libXt was updated to version 1.2.0. On one of systems > >>> 1.2.0 does not compile. The error is rather strange: > >>> > >>> checking for i686-pc-linux-gnu-cpp... /usr/bin/i686-pc-linux-gnu-cpp > >>> checking if /usr/bin/i686-pc-linux-gnu-cpp requires -undef... * > >>> gcc-config: No gcc profile is active! > >>> /usr/bin/gcc-config: line 76: /etc/env.d/gcc/config-i686-pc-linux-gnu: > >>> No such file or directory > >>> gcc-config: error: could not run/locate 'i686-pc-linux-gnu-cpp' > >>> > >>> * gcc-config: No gcc profile is active! > >>> > >>> /usr/bin/gcc-config: line 76: /etc/env.d/gcc/config-i686-pc-linux-gnu: > >>> No such file or directory > >>> gcc-config: error: could not run/locate 'i686-pc-linux-gnu-cpp' > >>> > >>> * gcc-config: No gcc profile is active! > >>> > >>> /usr/bin/gcc-config: line 76: /etc/env.d/gcc/config-i686-pc-linux-gnu: > >>> No such file or directory > >>> gcc-config: error: could not run/locate 'i686-pc-linux-gnu-cpp' > >>> configure: error: /usr/bin/i686-pc-linux-gnu-cpp defines unix with or > >>> without -undef. I don't know what to do. > >>> > >>> The systems is a multilib systems (32 and 64 Bit). I suspect that it is > >>> not a bug in the libXt ebuild but a problem with my system, but I can't > >>> figure out what the problem is. Any help is appreciated. > >>> > >>> build.log, environment etc. are attached. > >>> > >>> Best regards > >> > >> Do you have a gcc profile selected? "gcc-config -l" should list the > >> available ones and indicate which is selected. > >> > >> Jack > > The gcc compiler for your profile is prefixed by x86_64-* but your configure > script is looking for i686-* and does not find it: "gcc-config: error: > could not run/locate 'i686-pc-linux-gnu-cpp'" > > That said, I'm no longer on multilib since years so I would not know what > the root cause of your problem is, sorry. > > Maybe 'eselect profile list' helps? > > raffaele On multilib: $ ls -la /etc/env.d/gcc/ total 16 drwxr-xr-x 2 root root 4096 Jun 11 12:23 . drwxr-xr-x 5 root root 4096 Jul 20 16:53 .. lrwxrwxrwx 1 root root 25 Jun 11 12:23 .NATIVE -> x86_64-pc-linux-gnu-8.3.0 -rw-r--r-- 1 root root 34 Jun 11 12:23 config-x86_64-pc-linux-gnu -rw-r--r-- 1 root root 358 Jun 11 12:23 x86_64-pc-linux-gnu-8.3.0 The question must be why is emerge looking for config-i686-pc-linux-gnu? Has Jens messed about with CHOST= in /etc/portage/make.conf? Will the package build without complaining if emerged so: CHOST="x86_64-pc-linux-gnu" emerge -1aDv x11-libs/libXt -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] dev-lang/ruby and dev-ruby/xmlrpc-0.3.0[ruby_targets_ruby25] error
On Monday, 22 July 2019 11:12:55 BST Dale wrote: > Howdy, > > I did my usual sync and ran into a slight problem. Given the minimal > output, I can't quite figure out if there is a way around this. > Sometimes I can emerge a few packages individually and get around this > sort of thing. On this one tho, I just can't quite figure out how to > get around the problem. Things I've tried so far. Made sure nothing in > package.use is ruby related and made sure no packages in the list are in > there either. I updated @system successfully and tried again, same > error. I've tried unmasking next up packages with no change. I > reversed that and tried to mask some packages, same thing or it > complains about the masked packages one. I've tried to emerge the > packages listed individually, in different order even, with no change. > This is what I get. > > > > root@fireball / # emerge -uvaDN world > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > > emerge: there are no ebuilds to satisfy > ">=dev-ruby/xmlrpc-0.3.0[ruby_targets_ruby25]". > (dependency required by "dev-lang/ruby-2.5.5::gentoo" [ebuild]) > (dependency required by > "dev-ruby/rake-12.3.2::gentoo[ruby_targets_ruby25]" [ebuild]) > (dependency required by "media-video/mkvtoolnix-35.0.0::gentoo" [installed]) > (dependency required by "@selected" [set]) > (dependency required by "@world" [argument]) > root@fireball / # Have you specified ruby target 2.5 anywhere in your /etc/portage and, or uninstalled/masked ruby 2.4? The above packages are installed with the default ruby 2.4 here: ~ $ equery u dev-ruby/xmlrpc [ Legend : U - final flag setting for installation] [: I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for dev-ruby/xmlrpc-0.3.0: U I - - doc : Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally + + ruby_targets_ruby24 : Build with MRI Ruby 2.4.x - - test: Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) ~ $ equery u dev-ruby/rake [ Legend : U - final flag setting for installation] [: I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for dev-ruby/rake-12.3.1: U I - - doc : Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally + + ruby_targets_ruby24 : Build with MRI Ruby 2.4.x - - test: Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] hw problems
On Monday, 22 July 2019 11:29:26 BST Raffaele Belardi wrote: > Adam Carter wrote: > > On Mon, Jul 22, 2019 at 7:47 PM mailto:p...@xvalheru.org>> wrote: > > Hi, > > > > Since last week my gentoo installation start to randomly freeze. The > > first I've detected was during huge disk usage, another was during > > hibernation, etc. I think it might be related to HDD problems, but I > > want to be sure. In kernel log there are some errors, but I'm not able > > to decide if those causes the freezing or not (I've saw such messages > > earlier too, so I'm not sure). So, is there a good diagnostic tool to > > check HW and mainly HDD? What I need to decide is if buying new HDD > > will > > fix the issue or not > > > > Install smartmontools then > > > > # smartctl -a /dev/sda > > I think Adam answered the OP but I just wanted to understand the kernel log: > > - the errors are from device pcieport :00:1c.0 > - according to "pci :00:1c.0: [8086:9d14] type 01 class 0x060400", this > is should be a PCI bridge. > > So the error may come from the bridge itself or from a device attached to > the bridge, I suppose? I think device [8086:9d14] which errors out is a wireless card ... ? > - the disk is attached to ata1: "ata1.00: ATA-10: ST2000LM015-2E8174, SDM1, > max UDMA/133" - ata1 is "ata1: SATA max UDMA/133 abar m2048@0xd1133000 port > 0xd1133100 irq 122" > > Is there a way to understand where the ata1 is physically attached to? > In other words, can one tell from the log if the error comes from the ata1 > device or something else? > > thanks, > > raffaele lspci will show the PCI port, but I think the error looks like it is related to the wireless card, which is also bouncing like mad. I'd check the correct driver is available and the firmware too, especially if it needs to be configured manually (not all are available in linux-firmware). -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: emerge --sync: problem refreshing keys
On Sunday, 21 July 2019 11:17:30 BST Stefano Crocco wrote: > On venerdì 19 luglio 2019 21:02:40 CEST Stefano Crocco wrote: > > On venerdì 19 luglio 2019 18:21:46 CEST Ian Zimmerman wrote: > > > On 2019-07-18 19:42, Stefano Crocco wrote: > > > > Hello to everyone, > > > > since yesterday emerge --sync fails because it can't refresh keys. The > > > > messages I get are: > > > > > > > > Syncing repository 'gentoo' into '/usr/portage'... > > > > > > > > * Using keys from /usr/share/openpgp-keys/gentoo-release.asc > > > > * Refreshing keys via WKD ... [ !! ] > > > > * Refreshing keys from keyserver hkps://keys.gentoo.org ...OpenPGP > > > > keyring > > > > > > > > refresh failed: > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > > > OpenPGP keyring refresh failed: > > > > gpg: refreshing 4 keys from hkps://keys.gentoo.org > > > > gpg: keyserver refresh failed: No keyserver available > > > > > > Perhaps something to do with this? > > > > > > https://www.bleepingcomputer.com/news/security/public-certificate-poison > > > in > > > g-> > > > > can-break-some-openpgp-implementations/ > > > > > Aside: > > > I have already switched my personal gpg configuration to use the new > > > isolated keyserver. > > > > Thanks for the answer. I'd heard of this attack and read this [1] article > > on gentoo.org. From what I understand, it said that in theory there > > shouldn't be problems when syncing because "The gemato tool used to > > verify the Gentoo ebuild repository uses WKD by default. During normal > > operation it should not be affected by this vulnerability". Reading the > > article again, I now see it also says that "In the worst case; Gentoo > > repository syncs will be slow or hang" which, as you suggest, could very > > well be what's happened on my system. Unfortunately, the article doesn't > > say what to do if this happens. > > > > Tomorrow I'll try investigating more. > > > > Stefano > > > > [1] https://www.gentoo.org/news/2019/07/03/sks-key-poisoning.html > > It seems I found out how to fix the issue. I tried comparing my > /usr/share/portage/config/repos.conf with the one which comes with a current > stage3 and found out mine had the line > > sync-openpgp-keyserver = hkps://keys.gentoo.org > > which was missing in the file from stage3. Removing it (both here and in > /etc/portage/repos.conf/gentoo.conf) allowed me to sync correctly. I hope > this is the correct fix. I don't remember ever writing this line, so I > suppose it came with the original stage3 I built my system from or was > changed by another update (an update of what, however? According to `equery > b`, this file doesn't belong to any package). > > I hope thing will keep working. > > Stefano I grepped two older installations I had immediate access to and there is no directive containing "openpgp" anywhere within /etc/portage/. In a new-ish installation there were a number of entries in /etc/portage/ repos.conf/gentoo.conf, but no keyserver URI: $ grep openpgp -r /etc/portage/repos.conf/gentoo.conf sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc sync-openpgp-key-refresh-retry-count = 40 sync-openpgp-key-refresh-retry-overall-timeout = 1200 sync-openpgp-key-refresh-retry-delay-exp-base = 2 sync-openpgp-key-refresh-retry-delay-max = 60 sync-openpgp-key-refresh-retry-delay-mult = 4 Perhaps you had added a keyserver as a fall back when you were configuring your system to use WKD? I haven't implemented WKD because there was no news item advising us to do so. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Black Screen of Death
On Friday, 19 July 2019 06:28:56 BST jdm wrote: > I have updated firmware line in kernel as this now includes a few extra > lines so not loading all of the available firmware. Some time ago I noticed warnings in dmesg which alerted me to the fact the radeon graphics was not finding all the firmware it needed/wanted. I had used the gentoo radeon wiki page, but noticed the same graphics was now also covered in the amdgpu wike page. Anyway, I responded to each dmesg complaint by adding the respective firmware in the kernel and a reboot resolved all problems. In my case I was only getting a black screen trying to wake up the PC after a suspend in RAM, so not exactly the same problem, but similar enough. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Using UUID for root disk in grub requires initramfs?
On Friday, 19 July 2019 10:29:09 BST Adam Carter wrote:
> This
> https://wiki.gentoo.org/wiki/GRUB2/Configuration_variables
>
> has
>
> GRUB_DISABLE_LINUX_UUID false If true, ${GRUB_DEVICE} is passed in the root
> parameter on the kernel command line.
>
> If false, ${GRUB_DEVICE_UUID} is passed in the root parameter on the kernel
> command line when an initramfs is available.
>
> So it looks like i can't set root= to a UUID unless i use an initramfs -
> can anyone confirm?
This would be correct if GRUB (with/out initramfs) happened to be the only way
to configure Linux. Thankfully we have more choices, in Gentoo at least. ;-)
> In /usr/src/linux/admin-guide/kernel-parameters.txt it has;
> root= [KNL] Root filesystem
> See name_to_dev_t comment in init/do_mounts.c.
>
> And in do_mounts.c it mentions PARTUUID= and PARTLABEL= but i dont know C
> so don't know what to make of it.
>
> Background is that after adding a new disk the system doesn't boot, so i'm
> assuming that the /dev/sdX device names are now pointing to different
> hardware, so i want to fix that by using persistent names.
You could use UUID, or partition label (if GPT is used on the disk), but by-
pass GRUB's facility to configure the UUID and use the kernel .config itself.
For this you will have to configure and compile your own kernel. Use this
kernel option to specify kernel command line options:
Processor type and features -->
...
[*] Built-in kernel command line
(root=PARTUUID=X other_options_here)
As long as you use 'make oldconfig' for subsequent kernels the UUID will be
retained.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Re: AMD microcode updates - where are they?!
On Thursday, 18 July 2019 13:33:36 BST Corbin wrote: > On 7/17/19 3:51 PM, Ian Zimmerman wrote: > > pti=0 ibrs=0 ibpb=1 retp=1 -> fix variant #1 #2 if the microcode > > update is applied pti=0 ibrs=2 ibpb=1 retp=1 -> fix variant #1 #2 on > > older processors that can disable indirect branch prediction without > > microcode updates > > > > Note: A microcode patch provided by the vendor must be applied in > > order for the tunables to be visible.> > > which of course is self-contradictory, so not a full answer but maybe a > > clue. I did read this but wasn't sure what to deduce from it. I took it to mean earlier CPUs won't receive a microcode patch, but will still have spectre mitigated, presumably using a different method. Later CPUs will receive a patch. My AMD APUs are later fam15h models and if the above is to be believed they probably ought to have received a patch - but none is observable. :-/ Then I thought the note in the RHL article may need to be taken literally, to mean a microcode patch will just make tunables *visible*, rather than present. > > Are those settings meant to go on a boot command line? > > As for what Red Hat / Fedora is doing, no idea. > > The parameters I used came from the kernel documentation. > > > Corbin According to kernel-4.19.57 docs at least, all CPU vulnerabilities and spectre related mitigations are automatically switched on, without the need to specify anything on the kernel line. In addition, the selection of individual spectre_v2 mitigation methods is determined dynamically "... at run time according to the CPU, the available microcode, the setting of the CONFIG_RETPOLINE configuration option, and the compiler with which the kernel was built." Anyway, selecting 'spectre_v2=on' "... will also enable the mitigation against user space to user space task attacks", so this is a useful option to use. Regarding ibpb not being displayed under my /sys fs the docs say: Default mitigation: If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl" Therefore, I am not sure if ibpb is meant to show up unless it has been specified on the kernel line as a spectre_v2_user mitigation method. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] AMD microcode updates - where are they?!
On Wednesday, 17 July 2019 04:21:07 BST Corbin wrote: > On 7/14/19 8:26 AM, Mick wrote: > > Then I came across this old message regarding Piledriver CPUs: > > https://lists.debian.org/debian-security/2016/03/msg00084.html The > > post refers to model 2 of cpu family 21. Not all models in the same > > family, only model 2. So I am thinking although patch files are named > > per CPU family, whether they are applicable and applied as an update > > to the CPU is probably determined by the particular CPU *model*. > > Logically, errata in previous CPU revisions may have been fixed in > > later models of the same family and therefore such microcode updates > > would not be needed. When offered by the OS the CPU won't select to > > have them applied. This explains why my AMD models, which are later > > revisions of the same 15h family do not apply any microcode updates - > > they don't need them. Please share if you know differently and thank > > you all for your responses. > > Remember a while back when I mentioned that "lwp" had disappeared from > my /proc/cpuinfo? > > They restored "lwp" with this commit : > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.gi > > t/commit/?id=7518922bd5b98b137af7aaf3c836f5a498e91609 > So it stands to reason that the microcode only applies specific patches > to specific problems per CPU. > > Reference : > > Darkstar ~ # cat /proc/cpuinfo > > processor: 0 > > vendor_id: AuthenticAMD > > cpu family: 21 > > model: 2 > > model name: AMD FX(tm)-9590 Eight-Core Processor > > stepping: 0 > > microcode: 0x6000852 > > cpu MHz: 4685.390 > > cache size: 2048 KB > > Output of /sys/devices/system/cpu/vulnerabilities : > > Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/l1tf > > Not affected > > Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/mds > > Not affected > > Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/meltdown > > Not affected > > Darkstar ~ # cat > > /sys/devices/system/cpu/vulnerabilities/spec_store_bypass > > Mitigation: Speculative Store Bypass disabled > > Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1 > > Mitigation: __user pointer sanitization > > Darkstar ~ # cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 > > Mitigation: Full AMD retpoline, IBPB: always-on, STIBP: disabled, RSB > > filling > > Corbin Hmm ... My last line looks the same like Rich's, but different to yours: # cat /sys/devices/system/cpu/vulnerabilities/spectre_v2 Mitigation: Full AMD retpoline, STIBP: disabled, RSB filling I don't have IBPB mentioned in there at all. I'm on gentoo-sources-4.19.57. Are you running a later kernel? According to this article a microcode update seems to be necessary, but I'm not sure if this statement only applies to Intel CPUs: https://access.redhat.com/articles/3311301#indirect-branch-prediction-barriers-ibpb-10 -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: AMD microcode updates - where are they?!
On Monday, 15 July 2019 22:18:12 BST Ian Zimmerman wrote:
> UH-OH, Self-followup:
>
> On 2019-07-14 21:30, Ian Zimmerman wrote:
> > I find it odd that there is apparently no central way to track which
> > firmwares are being loaded without a debugging kernel.
> >
> > The relevant messages in linux/drivers/base/firmware_loader/main.c are
> > all dev_dbg(), which as I understand does nothing on a non-debug kernel.
> > Even the message printed when the firmware file is missing is of that
> > type.
> >
> > I guess I could turn on the userspace helper, set it to some script that
> > just logs every request and fails, and then remove the whole
> > /lib/firmware tree, but that is a _really_ round-about way.
>
> Solved with a kernel patch:
>
> --- a/drivers/base/firmware_loader/main.c 2019-07-13 23:01:15.0
> -0700 +++ b/drivers/base/firmware_loader/main.c 2019-07-14
> 23:33:22.348028910 -0700 @@ -336,7 +336,7 @@
>path);
> continue;
> }
> - dev_dbg(device, "direct-loading %s\n", fw_priv-
>fw_name);
> + pr_notice("direct-loading firmware %s\n", fw_priv-
>fw_name);
> fw_priv->size = size;
> fw_state_done(fw_priv);
> break;
Thanks Ian, nothing different with the patch implemented. I am becoming
convinced there is no applicable microcode patch for my fam + model of AMD
CPUs.
$ dmesg | egrep -i "firmware|microcode"
[0.00] [Firmware Info]: CPU: Re-enabling disabled Topology Extensions
Support.
[0.343586] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[0.351361] acpi PNP0A08:00: [Firmware Info]: MMCONFIG for domain [bus
00-3f] only partially covers this bridge
[0.627638] [drm] Loading ARUBA Microcode
[0.629254] [drm] Found VCE firmware/feedback version 50.0.1 / 17!
[5.753421] [drm] Loading hainan Microcode
[6.643785] microcode: CPU0: patch_level=0x06001119
[6.647663] microcode: CPU1: patch_level=0x06001119
[6.649170] microcode: CPU2: patch_level=0x06001119
[6.650136] microcode: CPU3: patch_level=0x06001119
[6.651110] microcode: Microcode Update Driver: v2.2.
[8.125143] psmouse serio1: elantech: assuming hardware version 3 (with
firmware version 0x450f03)
[9.938954] psmouse serio1: elantech: assuming hardware version 3 (with
firmware version 0x450f03)
[ 30.738249] firmware_class: direct-loading firmware regulatory.db
[ 30.738915] firmware_class: direct-loading firmware regulatory.db.p7s
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] AMD microcode updates - where are they?!
On Saturday, 13 July 2019 23:03:11 BST Mick wrote: > Unlike my old Intel which lights up like a christmas tree with "Vulnerable, > no microcode found" because Intel has thrown its users to the kerb, both > AMDs show "Not Vulnerable" and for some of the vulnerabilities it reports: > > (your CPU vendor reported your CPU model as not vulnerable) This last line made me think a bit more. Scratching around I see there are separate patch files with AMD microcode updates offered for the various CPU families. My simplistic assumption so far has been *all* CPUs of a certain family will apply the corresponding patch file microcode update, either via a new UEFI/BIOS firmware, or via the OS. Clearly this is not so. If I remove 'amd-ucode/microcode_amd_fam15h.bin' from my kernel firmware directive completely, or add amd-ucode/ patch files for every family, or even try to manually reload the microcode: echo 1 > /sys/devices/system/cpu/microcode/reload there is no change in dmesg. Clearly my CPU does not load any microcode update, other than what might be already available in the old UEFI MoBo firmware and this is loaded before the OS starts booting. Then I came across this old message regarding Piledriver CPUs: https://lists.debian.org/debian-security/2016/03/msg00084.html The post refers to model 2 of cpu family 21. Not all models in the same family, only model 2. So I am thinking although patch files are named per CPU family, whether they are applicable and applied as an update to the CPU is probably determined by the particular CPU *model*. Logically, errata in previous CPU revisions may have been fixed in later models of the same family and therefore such microcode updates would not be needed. When offered by the OS the CPU won't select to have them applied. This explains why my AMD models, which are later revisions of the same 15h family do not apply any microcode updates - they don't need them. Please share if you know differently and thank you all for your responses. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] AMD microcode updates - where are they?!
On Saturday, 13 July 2019 22:01:02 BST Rich Freeman wrote: > On Sat, Jul 13, 2019 at 4:16 PM Wols Lists wrote: > > On 13/07/19 20:23, Mick wrote: > > > Thanks Corbin, I wonder if despite articles about microcode patch > > > releases to deal with spectre and what not, there are just no patches > > > made available for my aging AMD CPUs. > > > > Or Spectre and what not are Intel specific ... > > > > I know a lot of the reports said many of the exploits don't work on AMD. > > It's something to do with the way Intel has implemented speculative > > execution, and AMD doesn't use that technique. > > Some spectre-related vulnerabilities apply to AMD, and some do not. > Most of the REALLY bad ones do not, but I believe that some of the AMD > ones still require microcode updates to be mitigated in the most > efficient way. Yes, the A10 is vulnerable to: CVE-2017-5753 (Spectre Variant 1, bounds check bypass) CVE-2017-5715 (Spectre Variant 2, branch target injection) > Take a look in /sys/devices/system/cpu/vulnerabilities on your system > for the kernel's assessment of what vulnerabilities apply, and how > they are being mitigated. What you want to see is every single one > either saying "Not affected" or they start with "Mitigation:" If you > see one starting with something like Partial Mitigation or Vulnerable > you should Google if there is something you can do to improve this. > > Note that this assumes you have a current kernel. The kernel can only > report the vulnerabilities it knows about, so if you're running some > kernel from 9 months ago it won't know about everything. > > For reference, on my Ryzen 5 1600 I get: > for x in * ; do echo -n "$x: " ; cat $x ; done > > l1tf: Not affected > mds: Not affected > meltdown: Not affected > spec_store_bypass: Mitigation: Speculative Store Bypass disabled via > prctl and seccomp > spectre_v1: Mitigation: __user pointer sanitization > spectre_v2: Mitigation: Full AMD retpoline, STIBP: disabled, RSB filling I get the same output on both AMD systems running gentoo-sources-4.19.57. I've also used this script for some more detailed checking and testing: https://github.com/speed47/spectre-meltdown-checker Unlike my old Intel which lights up like a christmas tree with "Vulnerable, no microcode found" because Intel has thrown its users to the kerb, both AMDs show "Not Vulnerable" and for some of the vulnerabilities it reports: (your CPU vendor reported your CPU model as not vulnerable) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] AMD microcode updates - where are they?!
On Saturday, 13 July 2019 19:16:18 BST Corbin wrote: > For reference, the .config file for the kernel should have something > > along the lines of this: > > # > > # Firmware loader > > # > > CONFIG_FW_LOADER=y > > CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd.bin > > amd-ucode/microcode_amd_fam15h.bin amdgpu/polaris10_ce.bin > > amdgpu/polaris10_ce_2.bin amdgpu/polaris10_k_smc.bin > > amdgpu/polaris10_mc.bin amdgpu/polaris10_me.bin > > amdgpu/polaris10_me_2.bin amdgpu/polaris10_mec.bin > > amdgpu/polaris10_mec2.bin amdgpu/polaris10_mec2_2.bin > > amdgpu/polaris10_pfp.bin amdgpu/polaris10_pfp_2.bin > > amdgpu/polaris10_rlc.bin amdgpu/polaris10_sdma.bin > > amdgpu/polaris10_sdma1.bin amdgpu/polaris10_smc.bin > > amdgpu/polaris10_smc_sk.bin amdgpu/polaris10_uvd.bin > > amdgpu/polaris10_vce.bin" > > CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/" > > CONFIG_FW_LOADER_USER_HELPER=y As I understand it the CONFIG_FW_LOADER_USER_HELPER has some edge use cases, but is not needed for our hardware/firmware. > CPU is a AMD FX-9590 ( Fam15h ) > > Video is a RX480 ( Polaris 10 ) > > And, yes, both microcode updates ( Fam10h / Fam15h ) need to be builtin. Are you sure about this? I added 'amd-ucode/microcode_amd.bin' for Fam10h, rebooted and nothing changed here as far as microcode patches is concerned. I am not using savedconfig on this PC, so all amd-ucode binaries are available to be loaded from the filesystem. > Previous generation CPU updates will be builtin, even if you try to > exclude them. Fine, so following the wiki page and ONLY adding the microcode specific to the CPU family should still work. > Corbin Thanks Corbin, I wonder if despite articles about microcode patch releases to deal with spectre and what not, there are just no patches made available for my aging AMD CPUs. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] AMD microcode updates - where are they?!
On Saturday, 13 July 2019 18:42:27 BST Jack wrote: > > If linux-firmware is emerged with the savedconfig use flag, then only > the firmware not deleted from the config file is left. Yes. I used to do this, but gave up after a while. > I did find a > few extras based on the "failed to load..." messages after my initial > overzealous trimming of that config file. My current concern is indeed > with the microcode, about which no complaint. Looking at the link > below shows me I am missing the files for my 17h family Ryzen CPU. It > will be a bit before I can reboot to see if it does load them once I > re-emerge linux-firmware to get them. Make sure the corresponding AMDGPU driver settings are built in the kernel, not as modules. Ryzen CPUs are new(ish) and the MoBo OEMs should still be releasing UEFI/BIOS firmware updates, which will contain any needed microcode patches. You'll obtain these next time you flash your BIOS with the latest release, if/when there is one available. Your 'dmesg | grep micro' patch number will change as a result, but there will be no 'early microcode update ...' message since the OS will not be applying any microcode patches itself. It is older CPUs which need the patches, since OEMs usually abandon any intention to support their hardware beyond the nominal warranty period. > I'll update again once I've done that. > > Jack Cool, thanks for your input. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] AMD microcode updates - where are they?!
On Saturday, 13 July 2019 18:18:35 BST Mick wrote: > or > > xv -dc < /boot/EFI/... initramfs-XXX.img | cpio -idmv Oops! Typo alert! xv should of course be 'xz'. I think you can also use lzcat. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] AMD microcode updates - where are they?!
On Saturday, 13 July 2019 17:21:40 BST Jack wrote: > On 2019.07.12 08:18, Mick wrote: > > https://www.bleepingcomputer.com/news/hardware/amd-releases-spectre-v2-mic > > rocode-updates-for-cpus-going-back-to-2011/ > I have not yet done any further searching or digging, but that link > seems to only talk specifically about Windows updates, not generic > firmware updates. Yes, but any microcode releases are/should be CPU specific. If they're released for applying via one OS, they should be available to others too. Of course, if microcode has only been released to MoBo OEM's, then we're in the mercy of OEM commercial interests. I'm sure when asked for an update they will try to sell to us all the latest models they have recently launched. :p > I have three different AMD based PCs, and so far, I don't see anything > different from Mick. However, on two Artix linux systems, I'm still > not quite sure whether the microcode is in the initramfs or not. I > hate to admit I'm also not sure on my Gentoo box, having so far made > only minor changes to the kernel from the June stage 3 tarball, and > used genkernel to compile both kernel and initramfs. I'm working on > configuring 5.2.0, but it will take me a while to get through the > complete configuration (starting from scratch.) I'm not familiar with dracut to know what it uses as a default archiving engine and if you can run it to inspect directly the contents of an already created initramfs. I know it can output on the console what it is including in initramfs at the time of creation. Anyway, if you want to look at the initramfs contents manually, I suppose you will need to decompress your initramfs in a temporary directory to see its contents. First find what archive format has been used. file /boot/EFI/... initramfs-XXX.img will output gzip, bzip2, lzma or similar archive type. Then create a temporary directory to work in and use the corresponding compression type: mkdir ~/tmp_initramfs cd ~/tmp_initramfs zcat /boot/EFI/... initramfs-XXX.img | cpio -idmv or bzcat /boot/EFI/... initramfs-XXX.img | cpio -idmv or xv -dc < /boot/EFI/... initramfs-XXX.img | cpio -idmv Something like the above ought to do the job. > One suggestion - don't just grep for microcode, also check for > "firmware" for which I use 'dmesg | egrep -i "firmware|microcode"'. Well, 'firmware' will capture other firmware files, like graphics card, WiFi, BT, etc. rather than the CPU microcode. > And, one question - if I have linux-firmware emerged with savedconfig > use flag set, what's the best/easiest way to hunt through the actually > available firmware, to check if I might have missed something > relevant. So far, I've just searched the git repository for the > package. I suppose I could have kept a copy of the manifest from the > initial emerge (without savedconfig) but I didn't think of it at the > time. > > Jack Look under your /lib/firmware/ directory for the file you want to use, or the file dmesg complains is missing. For microcode there will be no complaining, but for other hardware there usually is something along the lines: "failed to load blah-blah.bin, file not found." The appropriate microcode file for your AMD CPUs can be deduced from the table here: https://wiki.gentoo.org/wiki/AMD_microcode and it should be stored under your: /lib/firmware/amd-ucode/ after you install linux-firmware. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: AMD microcode updates - where are they?!
On Saturday, 13 July 2019 02:13:00 BST Adam Carter wrote: > grep fam /proc/cpuinfo > > -> 21 = 15h > -> 22 = 16h Yep, here's the laptop: $ grep fam -m1 /proc/cpuinfo cpu family : 21 and here's the dekstop: $ grep fam -m1 /proc/cpuinfo cpu family : 21 -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: AMD microcode updates - where are they?!
78553] microcode: CPU0: patch_level=0x06003106 [1.579338] microcode: CPU1: patch_level=0x06003106 [1.580943] microcode: CPU2: patch_level=0x06003106 [1.581729] microcode: CPU3: patch_level=0x06003106 [1.582608] microcode: Microcode Update Driver: v2.2. Notice the patch number is slightly higher than the laptop's, which can be explained by the fact the desktop's Steamroller was launched in Jan 2014, while the laptop's Piledriver was launched in March 2013. Anyway, this does not explain why your Piledriver at least is loading early the microcode, but mine isn't. :-/ -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] AMD microcode updates - where are they?!
I'm looking at dmesg output which on my Intel CPUS of various vintages shows "microcode updated early ..." but two different AMD APUs of mine do not show the same, despite AMD apparently releasing microcode updates going back to 2011: https://www.bleepingcomputer.com/news/hardware/amd-releases-spectre-v2-microcode-updates-for-cpus-going-back-to-2011/ I have observed OEMs for laptop MoBos rarely if ever bother to release a UEFI/ BIOS firmware update past 1-2 years from launch of their products, while desktop OEMs may keep releasing updates for 3-5 years. Since there are no OEM MoBo firmware releases and I see no "microcode updated early ..." message in dmesg, I thought of checking with other Gentoo users if I'm doing something wrong, or if this is a common observation for AMD CPU/ APUs? PS. I include the microcode in the kernel, for both my Intel and AMD systems, rather than use an initramfs; e.g. CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam15h.bin ..." PPS. This is all shown on one of the AMD APUs, way down during the booting process: $ dmesg | grep -i micro [0.622441] [drm] Loading ARUBA Microcode [5.763242] [drm] Loading hainan Microcode [6.653025] microcode: CPU0: patch_level=0x06001119 [6.657962] microcode: CPU1: patch_level=0x06001119 [6.658890] microcode: CPU2: patch_level=0x06001119 [6.659881] microcode: CPU3: patch_level=0x06001119 [6.661136] microcode: Microcode Update Driver: v2.2. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] strange problem (no video output) on new PC
On Thursday, 11 July 2019 23:31:51 BST Jack wrote: > I'm hoping the cumulative wisdom of the assembled masses might be able > to figure out what I'm clearly missing, assuming there IS something I'm > missing. > > I've recently assembled a new PC, with an MSI B350-Tomahawk motherboard > and a Ryzen 5 2600 CPU. (We'll skip that I ended up actually buying an > older Ryzen just to upgrade the BIOS.) The problem is that I have now > tried three different PCI-E graphics cards, and have gotten no video > signal from any of them. I do get a video signal from an ancient PCI > graphics card. One of the cards is a very old Radeon, one is a > slightly less old nVidia, and the newest is (from lspci) "Advanced > Micro Devices, Inc. [AMD/ATI] Cape Verde XT [Radeon HD 7770/8760 / R7 > 250X]." > > What I find particularly odd is that if I log in blind, and then issue > startx, X (startkde) seems to be running fine. I ssh in from another > PC, and the X log shows the Radeon driver loading, the monitor being > recognized on the appropriate connector, the EDID received, and the > right resolution being chosen. (Even without all the AMD drivers and > firmware loaded, at least it also seemed to start with the VESA driver, > but still no output signal.) > > I can easily believe the old radeon card is dead, and possibly even the > nVidia card. However, given what I see in the logs with the new radeon > card, I find it hard to believe the card is actually defective. (Just > purchased used on eBay, so I do have to admit the possibilty.) > However, I have trouble imagining what else could be the problem. I've > tried two different cables (both of which work fine for the PCI card) > but both use DVI to VGA adaptors, although I can't imagine why that > would matter now, if they worked for a different card. I have ordered > a new DVI cable to go directly from the card to the monitor, so > hopefully I'll get that and be able to test it within a few days. > > Can anyone else thing of what the problem might be, and if there is any > troubleshooting I could try? > > Jack Brief response for now: If dmesg after you login remotely shows the graphics card firmware is available in the kernel, radeon/nvidia drivers are loading and no errors are printed, then hardware wise your PC ought to be OK. If /var/log/Xorg.0.log shows no errors with drivers and monitor, then I don't know what to suggest other than following a process of elimination, by trying: - different cables - different monitor However, if cables or monitor were at fault I would expect warnings to show up in the log files. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Massive kmail breakage with mariadb-10.4.6
On Wednesday, 10 July 2019 14:31:19 BST Peter Humphrey wrote: > On Wednesday, 10 July 2019 10:06:01 BST Peter Humphrey wrote: > > On Wednesday, 10 July 2019 00:06:43 BST Adam Carter wrote: > > > > I've just tried upgrading mariadb again while watching it, and got > > > > similar > > > > results. I did notice that an error notice came up about being unable > > > > to > > > > store > > > > a message received via POP3, which is my main incoming source. I can't > > > > quote > > > > exactly because the notice disappeared too soon. > > > > > > > > Back to 10.3.16 for now. > > > > > > Just to confirm, when you say upgrade you mean something like; > > > emerge -u mariadb > > > systemctl restart mariadb > > > mysql_upgrade -u root -p > > > > Akonadi runs an instance of mariadb for its own use, without reference to > > what else might be running on the machine. > > > > I've never had to run mysql_upgrade before, and I can't find a way to do > > it > > manually because of this in .local/share/akonadi/mysql.conf: > > > > # Do not listen for TCP/IP connections at all > > skip_networking > > > > Maybe I could comment that out temporarily, but I don't know what else > > might be affected. Otherwise it looks like creating a new user for myself > > and importing the message archive. > > Well, I tried that but when I started kmail to set it up again, it crashed > after telling me it had failed to get a lock. On what, it didn't say. /usr/bin/akonadi_control launches /usr/bin/akonadiserver, which lunches /usr/ sbin/mysqld: /usr/bin/akonadi_control | \_ /usr/bin/akonadiserver | \_/usr/sbin/mysqld They're all running as the user who launches kmail, i.e. yourself. Also, unless you have tweaked access to the database to allow TCP, it will only use a local Unix socket. Have a look in your /tmp fs for this socket name. If your kdepim user is logged in as user 'peter', I'm guessing you'll see something like this, as long as akonadiserver is running: /tmp/akonadi-peter.XX/mysql.socket You could try running mysql_upgrade on this, but the command will request access to default mysql database tables and its socket under /var/run/mysqld/, which I assume you won't be running unnecessarily just for a Plasma/KDE desktop. Consequently the incantation will fail. Instead, you could try running the individual commands mysql_upgrade runs yourself, only on the akonadi tables. Here's my attempt: $ /usr/bin/mysqlcheck -u michael --all-databases --check-upgrade --auto-repair --socket=/tmp/akonadi-michael.ZtUWTD/mysql.socket akonadi.collectionattributetable OK akonadi.collectionmimetyperelation OK akonadi.collectionpimitemrelation OK akonadi.collectiontableOK akonadi.flagtable OK akonadi.mimetypetable OK akonadi.parttable OK akonadi.parttypetable OK akonadi.pimitemflagrelationOK akonadi.pimitemtable OK akonadi.pimitemtagrelation OK akonadi.relationtable OK akonadi.relationtypetable OK akonadi.resourcetable OK akonadi.schemaversiontable OK akonadi.tagattributetable OK akonadi.tagremoteidresourcerelationtable OK akonadi.tagtable OK akonadi.tagtypetable OK Or, you could connect to the above socket with /usr/bin/mysql and run SQL commands from within, after you select each akonadi database/table in turn. Normally, I don't think any of the above is required. From what I recall akonadiserver runs mysql_upgrade each and every time akonadiserver is launched. However, if akonadi can't run the kdepim mysql following a database version update, then you'll need to look deeper into it. If akonadiserver does not start/crashes, it may be more effective to look at the mysql.err logs under ~/.local/share/akonadi/db_data/. You could also launch akonadiconsole, switch on debugging and see if it offers anything more informative when you try to restart akonadi. HTH. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Music player being run from an emerge
On Tuesday, 9 July 2019 19:10:52 BST Andrew Lowe wrote: > Hi all, > This all happens on an up to date openrc machine with the profile > default/linux/amd64/17.0/desktop/plasma > > I've added a few hooks to the emerge process via the bashrc that is in > /etc/portage. One of the things I do upon emerge failure is kill vlc, > which would have been playing a random song, and then attempt to start > alsaplayer[1] with a specific song. This means that I can be pottering > around the house/shed and if the "failure song" starts playing, I know > something is up. The problem is getting the failure song to play. > > If I log in as my usual user, alsaplayer will run the song. If I then > "su" into root, I'm in wheel, alsaplayer will play the song. The problem > is that when the emerge runs, then fails, alsaplayer can't appear to > fire up. Is this because the emerge runs as portage:portage and it does not have access rights to alsaplayer? > When an emerge fails, I get the usual error listings then the > following: > > * ACCESS DENIED: open_wr: /dev/snd/controlC0 > * ACCESS DENIED: open_wr: /dev/snd/controlC0 > ALSA lib > /var/tmp/portage/media-libs/alsa-lib-1.1.9/work/alsa-lib-1.1.9/src/confmisc. > c:674:(snd_determine_driver) could not open control for card 0 > ALSA lib > /var/tmp/portage/media-libs/alsa-lib-1.1.9/work/alsa-lib-1.1.9/src/conf.c:35 > 72:(snd_config_hooks_call) function snd_config_hook_load_for_all_cards > returned error: Permission denied Unless the above output was from emerging alsa-lib, your hooks should not be looking in /var/tmp/portage/, but I may not have understood what your mechanism is for launching alsa correctly. Also the above could be a sandboxing limitation? > Amongst this stuff is a line: > > LOG FILE: "/var/log/sandbox/sandbox-20431.log" > > which I think confirms my suspicions that something is wrong with my > sandbox as I also get this error when the email fails and just before > the failure hook, running alsaplayer, is run: > > ERROR: ld.so: object 'libsandbox.so' from LD_PRELOAD cannot be preloaded > (cannot open shared object file): ignored. > > Are there any emerge/sandbox gurus out there who might have an idea as > to what's going on? Any thoughts are greatly apreciated, > > Andrew > > > [1] vlc won't play as root hence I tried alsaplayer I'm not versed in the the details of emerge - I just use it with my limited knowledge as a package manager. Nevertheles, here's some ideas others more knowledgeable could contributed to and correct as necessary: Your emerge hooks should 'sudo su - whatever_user' has access to cvlc and run that, instead of vlc, or even alsaplayer. If the emerge process is sandboxed, then the user access rights would be limited, therefore you'll need to expand these with sudo. Use full paths for executables in your hook commands and add some traps to see the step at which they fail. Running a script with conditionals may be a better way to run emerge and catch a failure code, which will then trigger cvlc. I would be reluctant to extend privileges to processes which were designed to do one thing (e.g. emerge) in order to do something else, e.g. read areas of the filesystem they're not meant to meddle in. Choose to use the lowest level of access rights necessary to perform what you're after and no higher. I hope the above leads you closer to what you want to achieve. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Massive kmail breakage with mariadb-10.4.6
On Tuesday, 9 July 2019 19:45:25 BST Wols Lists wrote: > On 09/07/19 11:38, Peter Humphrey wrote: > >> Eventually I noticed that mariadb had been upgraded, so I masked the > >> latest > >> > >> > version and reverted to the older one. Lo! and Behold! Kmail sprang > >> > back > >> > into life. > > > > Today's update included dev-db/mysql-connector-c-6.1.11-r1 to -r2, so I > > tried mariadb 10.4.6 again. No improvement. > > Do you need to update some mariadb disk format? > > I gather they changed something ages ago and you had to fix the database > files. Broke my fetchmail/postfix setup and I couldn't work out how to > fix it. Fortunately I wasn't using it as a mail store. That's not been > working for a few years now. > > Could be the new mariadb doesn't recognise the old database files. > > Cheers, > Wol >From what I recall when akonadictl starts its mysql database it runs an update by default to sort out any changes to keys priveleges and what not, but this version update may require a more manual intervention? I would have thought there would be some e-news to this effect though. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Anyone with experience viewing EXIF data in Dolphin?
On Friday, 5 July 2019 21:22:31 BST Andrew Udvare wrote: > On 05/07/2019 15:37, Andrew Lowe wrote: > > Hi all, > > I'm transferring my install from a spinning disk to an SSD and > > decided to tidy up/customise/stuff up things as I go. I've recently > > taken a lot of photo's whilst travelling and I have the Coords in the > > EXIF data. What I would like is to be able to easily view this data. > > There is a thingy called "ReImage"[1] which allows for a right click > > within Dolphin and you can select an option to display the EXIF data in > > a dialogue box. I recall using an earlier version of this and it is a useful and easy submenu option to apply ImageMagick on a file. > > I had to manually install this as I could find nothing on "Dolphin > > Service Menus" within Portage, or the Gentoo wiki or basically on line > > at all, so is there a Gentoo way of dealing with these in the first place? > > Not really. You can submit a bug or PR though as some of these do make > into the tree sometimes. > > $ eix --homepage store.kde.org > > > Secondly, I then came across "kfilemetadata" in Portage. Without > > installing this as well, does this give the same thing? If so, how do > > you use this thing? Acutally, as I'm writing this, I'm still reserching > > and api.kde.org[2] says it's a library, so what apps use it? > > Not the same thing. > > kfilemetadata is solely a library and should be pulled in by other > packages that need it. > > You have to enable USE="semantic-desktop" to make Dolphin and others > pull it in and use it. If a GUI is not necessary and a semantic database indexing is not required, you can give exiftool a spin, which can be scripted with find to search your files and store them according to any exif tag. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Fdisk reports new HD as 10MiB
On Friday, 5 July 2019 15:44:46 BST Robin Atwood wrote: > OK panic over! I had shelled into the wrong system! The mystery is what > I was trying to copy to, the machine only has one HD. Cool, I hope you didn't overwrite useful data and you keep backups. ;-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Fdisk reports new HD as 10MiB
On Friday, 5 July 2019 15:30:06 BST Robin Atwood wrote: > Thanks Vladimir, that sounds promising. Can you recommend any GPT > programs (this is new to me)? However the dd utility failed when I > tried to copy my old HD to the new one. > > # dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync > dd: error writing '/dev/sdb': No space left on device > 160+0 records in > 159+0 records out > 10481664 bytes (10 MB, 10 MiB) copied, 0.132944 s, 78.8 MB/s > > Cheers > Robin You can use gptfdisk, parted/gparted, etc. To check the size as well as additional information you can use smartmontools and run: smartctl -i /dev/sda It may also be worth checking if later firmware is available to address any issues with it, like reporting the wrong size with some tools. However, the dd command failure sounds suspicious - as I understand it dd should not fail unless the disk has run out of space. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Human configurable boot loader, OR useful grub2 documentation
On Friday, 5 July 2019 08:24:14 BST mad.scientist.at.la...@tutanota.com wrote: > Thank you! Now I don't have to read all the grub2 manual right away. Hardly anyone needs to read the whole GRUB2 manual, unless you're interest to know the ins and outs of GRUB2. However, it would be advisable to skim-read at least this wiki page, which explains which files you could/should edit to make GRUB2 do what you want it to do: https://wiki.gentoo.org/wiki/GRUB2 > Works > mostly like I thought but first attempt was to edit the mkconfig- grub.cfg > and I failed to back it up Properly. I should have tried it first on a > system that didn't have 4 other distros laying around. As per the above page, you could edit the /etc/default/grub file to define default variables, *then* run the grub-mkconfig command. Depending on your needs you could also add files in /etc/grub.d/ or edit 40_custom. You could create manually a /boot/grub/grub.cfg file, but this is NOT how GRUB2 was meant to be used. TBH, if you want to do this, then why bother with GRUB2 in the first place. You could instead install sys-boot/grub-static from an overlay and use grub legacy by manually configuring its /boot/grub/ grub.conf file. https://gpo.zugaina.org/sys-boot/grub-static Alternatively, there are other bootloaders to consider, with sys-boot/syslinux or extlinux featuring as lightweight alternatives. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] CPU frequency tweaks
While installing Gentoo on a laptop with an AMD A10-5750M APU using the Gentoo minimal-CD, I was troubled to see the CPU pegged at 3500MHz and consequent thermal cutouts shutting down the laptop. By reducing the number of jobs and using a desktop fan I managed to complete the installation. When I rebooted into my own freshly compiled kernel I noticed the CPU frequency would never go above 2500MHz. Investigating various files under / sys/devices/system/cpu/cpufreq/policy* I was surprised to see there was nothing I could do to either engage any of CPU's boost states, or to increase the frequency above a maximum value of 2500MHz. # cpupower frequency-info analyzing CPU 0: driver: acpi-cpufreq CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 4.0 us hardware limits: 1.40 GHz - 2.50 GHz available frequency steps: 2.50 GHz, 2.10 GHz, 1.80 GHz, 1.40 GHz available cpufreq governors: ondemand userspace performance schedutil current policy: frequency should be within 1.40 GHz and 2.50 GHz. The governor "userspace" may decide which speed to use within this range. current CPU frequency: 2.50 GHz (asserted by call to hardware) boost state support: Supported: yes Active: no Boost States: 3 Total States: 8 Pstate-Pb0: 3500MHz (boost state) Pstate-Pb1: 3200MHz (boost state) Pstate-Pb2: 2800MHz (boost state) Pstate-P0: 2500MHz Pstate-P1: 2100MHz Pstate-P2: 1800MHz Pstate-P3: 1400MHz Pstate-P4: 900MHz For example: # echo 350 | tee /sys/devices/system/cpu/cpufreq/policy3/scaling_setspeed 350 # cat /sys/devices/system/cpu/cpufreq/policy3/scaling_setspeed 250 Or, how about using cpupower? # cpupower frequency-set -g userspace -d 900MHz -u 3500MHz Setting cpu: 0 Setting cpu: 1 Setting cpu: 2 Setting cpu: 3 # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed 250 Watching /proc/cpuinfo when compiling never shows the frequency reaching above 2500: cpu MHz : 2495.389 cpu MHz : 2495.410 cpu MHz : 2495.389 cpu MHz : 2495.416 I can't think this is some hardcoded BIOS limitation, otherwise how come the minimal-CD was boosting the frequency all the time to the point of shutting down the laptop. Switching governor to 'performance' as the minimal-CD has it set, or to userspace/schedutil has no effect to the maximum frequency the CPU displays. Any ideas how I can activate the boost states on this CPU, or what else I could look into to unlock its potential and speed up my emerge? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: What the devil?!! [or Plasma teething problems Ia.]
On Friday, 28 June 2019 16:06:50 BST »Q« wrote: > On Thu, 27 Jun 2019 12:42:56 +0100 > > Mick wrote: > > On Thursday, 27 June 2019 10:55:16 BST Mick wrote: > > > The next thing to try: > > > > > > I don't have elogind starting up as a boot level rc service, > > > because it is launched when needed by dbus or pam. Perhaps if > > > elogind is running as a background service sddm will (re)launch > > > differently? > > > > I just tried it and it works. :-) > > > > With elogind running as a boot service, sddm launches with the > > Shutdown/Reboot buttons shown and they work as expected. However, as > > I do not have a /usr/ bin/loginctl, all I can assume is irrespective > > of the HaltCommand path specified in the default sddm config, when > > launched sddm searches all paths and eventually finds /bin/loginctl, > > which it runs when a button is pressed. > > > > As we've established with no -elogind +consolekit the commands > > specified in the default sddm config file are different. Also, with > > consolekit being a default rc service, it is running at the time sddm > > is launched. > > I use openrc, so I have sddm installed with -elogind -systemd > +consolekit +pam. Putting consolekit in the default runlevel does make > the buttons work the first time sddm is launched, on reboot. > > Without the conosolekit service in the default runlevel, the buttons > are greyed out after reboot, but restarting xdm some time after booting, > still without consolekit running, makes the buttons come alive and > work. At this stage, when you are restarting xdm, you've logged in the console and (I'm guessing) dbus+polkit+pam are running even if consolekit is not. Consolekit is needed for multiple users, so it is not necessary for this purpose, although if it's already running I understand it helps with the authentication by calling on pam. So, I'm surmising, dbus calls in polkit & pam, since you're logged in, which allows access to /sbin/shutdown. # ldd /usr/bin/sddm | grep dbus libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x7f537416) > So there's something in play other than consolekit for me. > > (I don't actually need to sort this out -- I'm just curious.) It may have something to do with dbus/polkit, which authenticates access to the /sbin/shutdown file locally by sddm and this makes the buttons visible/ actionable. If you have not logged in yet, after a reboot, then only dbus is running at that stage with no authentication mechanism. I may be *wildly* wrong, but no doubt more knowledgeable members will drop by soon to correct me. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: What the devil?!! [or Plasma teething problems Ia.]
On Thursday, 27 June 2019 10:55:16 BST Mick wrote: > The next thing to try: > > I don't have elogind starting up as a boot level rc service, because it is > launched when needed by dbus or pam. Perhaps if elogind is running as a > background service sddm will (re)launch differently? I just tried it and it works. :-) With elogind running as a boot service, sddm launches with the Shutdown/Reboot buttons shown and they work as expected. However, as I do not have a /usr/ bin/loginctl, all I can assume is irrespective of the HaltCommand path specified in the default sddm config, when launched sddm searches all paths and eventually finds /bin/loginctl, which it runs when a button is pressed. As we've established with no -elogind +consolekit the commands specified in the default sddm config file are different. Also, with consolekit being a default rc service, it is running at the time sddm is launched. Thank you all for your responses. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: What the devil?!! [or Plasma teething problems Ia.]
On Thursday, 27 June 2019 02:18:05 BST Mike Gilbert wrote: > On Wed, Jun 26, 2019, 7:30 PM Neil Bothwick wrote: > > On Wed, 26 Jun 2019 18:00:22 -0500, »Q« wrote: > > > > In an OpenRC system there is no loginctl. Consequently, unless we > > > > define a separate config in /etc/ to use shutdown (with sudo?) it > > > > won't work. This systemd-ism may be worth a bug report. > > > > > > In /usr/share/sddm/sddm.conf.d/00default.conf I have > > > > > > HaltCommand=/sbin/shutdown -h -P now > > > > > > RebootCommand=/sbin/shutdown -r now > > > > > > I just checked it with sddm-0.18.0, then upgraded to 0.18.1-r1, and it > > > stayed the same, I guess because I have USE="-systemd". > > > > And on a systemd setup, I have > > > > HaltCommand=/usr/bin/systemctl poweroff > > > > so where did Mick's loginctl option come from? > > elogind Yes! It seems elogind affects the commands in file /usr/share/sddm/ sddm.conf.d/00default.conf to use a different HaltCommand and RebootCommand: $ egrep -i 'Halt|Reboot' /usr/share/sddm/sddm.conf.d/00default.conf # Halt command HaltCommand=/usr/bin/loginctl poweroff # Reboot command RebootCommand=/usr/bin/loginctl reboot Here's a kicker: I do not have '/usr/bin/loginctl' in this (openrc + elogind, but -consolekit, -systemd) system: $ which loginctl /bin/loginctl $ ls -la /usr/bin/loginctl ls: cannot access '/usr/bin/loginctl': No such file or directory $ /usr/bin/loginctl poweroff -bash: /usr/bin/loginctl: No such file or directory NOTE: Running '/bin/loginctl poweroff' from a console works. So perhaps this explains why I also do not have Shutdown/Reboot buttons showing up on the default theme at the top RH corner? Errm ... not so! Please walk through this test case with me: 1. I log out, or reboot. The sddm DM screen shows no Shutdown/Reboot buttons. Consequently, I have no means of shutting down or rebooting from the DM screen. 2. I log out, drop into a console, stop the xdm rc service and restart it. The sddm screen launches and it now presents Shutdown/Reboot buttons as it should! Question: if /usr/bin/loginctl is not present, what commands do the buttons operate/which config file they read, to shutdown/reboot? NOTE: If I login/out, or reboot, the buttons are gone again. :-/ 3. I use KDE's systemsettings 'Startup and Shutdown/Login Screen (SDDM)' to change the default theme. This creates a new /etc/sddm.conf file, with the new Theme entry I selected, but the Halt/Reboot commands are empty. I logout or reboot and the buttons are absent again, or when shown in the new theme they are either greyed out and do not work (Breeze) or not greyed out and still not work. I have not tried setting up a config file in /etc/ and modifying it comprehensively, i.e. specifying my own theme, Halt/Reboot commands, etc., but I do not have a coherent theory why the above behaviour is observed. The next thing to try: I don't have elogind starting up as a boot level rc service, because it is launched when needed by dbus or pam. Perhaps if elogind is running as a background service sddm will (re)launch differently? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: virtual eselect - how to
On Wednesday, 26 June 2019 22:13:30 BST David Haller wrote: > Hello, > > On Wed, 26 Jun 2019, Ian Zimmerman wrote: > >On 2019-06-26 14:51, Mick wrote: > >> > I have installed openblas but 'eselect blas list' doesn't know about > >> > this. > >> > >> I assume it doesn't know about it because there is no eselect module > >> for blas. > > > >There definitely is, I have run across this problem as well. > > # eix app-eselect/ |grep blas > [I] app-eselect/eselect-blas > [I] app-eselect/eselect-cblas In this case, if neither of the above set up a link to openblas (I don't have blas here to check) it's time for a chat with the package maintainer. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: [Was: What the devil?!!] sddm shutdown & reboot
On Wednesday, 26 June 2019 16:49:11 BST Arve Barsnes wrote: > On Wed, 26 Jun 2019 at 17:13, Neil Bothwick wrote: > > > Could it be loginctl is there to confirm if a local button operation > > > can run / sbin/poweroff, rather than actually running the command as > > > shown in the sddm config file? > > > > No, not when I tried it > > > > % loginctl poweroff > > Unknown operation poweroff. > > > > This is confirmed by the list of commands in the loginctl man page. > > On the other hand, poweroff and reboot are valid arguments to > /bin/loginctl, installed by elogind > > Regards, > Arve OK, I got this partly wrong. 1. There is a /bin/loginctl installed by elogind in openrc, but there is no / usr/bin/loginctl, which is what the sddm default settings file mentions. 2. Running '/bin/loginctl poweroff' from a console, while logged in as a user works fine. 3. Despite the above, some installations of mine do not react to sddm button presses to shutdown/reboot, but an older installation does. On some installations which I suspect are running some (older) default sddm theme there are no shutdown/reboot buttons shown at all. :-/ 4. The installation which has buttons showing and reacts to it is an old installation, which has been hacked to death. At some point in its life it had an /etc/sddm/ config file, modified to do stuff which the default settings would not do. This file is no longer there, so sddm should be reading the default settings under /usr/share/sddm/ but I don't know if some settings were cached by sddm and this is why this PC works as it should, but others don't. All this has left me confused and I'm thinking startx in a terminal is not such a bad idea after all ... -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: What the devil?!! [or Plasma teething problems Ia.]
On Wednesday, 26 June 2019 15:22:45 BST Peter Humphrey wrote: > On Wednesday, 26 June 2019 11:20:20 BST Mick wrote: > > I just looked at another installation. The default sddm configuration > > file (/usr/share/sddm/sddm.conf.d/00default.conf) shows this: > > > > [General] > > # Halt command > > HaltCommand=/usr/bin/loginctl poweroff > > > > In an OpenRC system there is no loginctl. Consequently, unless we define > > a > > separate config in /etc/ to use shutdown (with sudo?) it won't work. This > > systemd-ism may be worth a bug report. > > Here, it shows 'HaltCommand=/sbin/shutdown -h -P now'. Where 'here' is ... where? :-) Your own /etc/sddm/ configuration file, or the default installed under /usr/ share/sddm/sddm.conf.d/ ? The sddm package no longer installs a config file in etc. The user may do so if desired/required and modify it accordingly. However, the sample file offered by sddm has the above mentioned incongruity in it, which means the shutdown and reboot commands issued by its interface invariably do not work in openrc and it seems the same applies to systemd. I'll check a couple more of my installations here to see if they differ. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: [Was: What the devil?!!] sddm shutdown & reboot
On Wednesday, 26 June 2019 11:34:47 BST Neil Bothwick wrote: > On Wed, 26 Jun 2019 11:20:20 +0100, Mick wrote: > > I just looked at another installation. The default sddm configuration > > file (/ usr/share/sddm/sddm.conf.d/00default.conf) shows this: > > > > [General] > > # Halt command > > HaltCommand=/usr/bin/loginctl poweroff > > > > In an OpenRC system there is no loginctl. Consequently, unless we > > define a separate config in /etc/ to use shutdown (with sudo?) it won't > > work. This systemd-ism may be worth a bug report. > > It won't work on systemd either, loginctl has no poweroff command, it > should be systemctl poweroff, which is symlinked to /sbin/poweroff here > so setting it to that should work for modern and ancient systems alike :P Could it be loginctl is there to confirm if a local button operation can run / sbin/poweroff, rather than actually running the command as shown in the sddm config file? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] virtual eselect - how to
On Wednesday, 26 June 2019 14:05:27 BST Helmut Jarausch wrote: > Hi, > what is the relationship of a virtual package and eselect. > E.g. > I have installed openblas but 'eselect blas list' doesn't know about > this. I assume it doesn't know about it because there is no eselect module for blas. > I have even modified virtual/blas to include openblas. Virtual packages are there to make sure at least one of alternative packages satisfying dependency requirements will be installed. So, some package you installed requires a database. A virtual/ will be installed to make sure at least one of the database packages to satisfy the dependency requirement is installed. > How does eselect get the list of alternatives? > > Many thanks for a hint, > Helmut My understanding is package devs will have to create a corresponding eselect module, in order manage the symlinks for the various versions of said package which are available in the tree at any time. In absence of an eselect module, you can create any desired symlinks yourself. I often forget there are so many eselect modules these days. I found myself using rm and 'ln -s' to change profiles, only to recall eselect does this in a single incantation. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: What the devil?!! [or Plasma teething problems Ia.]
On Tuesday, 25 June 2019 17:09:55 BST »Q« wrote: > On Mon, 24 Jun 2019 21:19:09 +0100 > > Mick wrote: > > Can someone please explain how the removal of the 'wireless' USE flag > > from powerdevil ends up with no buttons for Suspend-to-RAM, > > Hibernation, Reboot or Shutdown under the Leave tab of the KMenu? > > What does wireless have to do with those functions which should work > > regardless? > > I have the wireless flag on, and I'm sometimes missing those buttons. > I've never figured out why, but they usually return after I log out of > KDE and back in -- sometimes it takes a reboot. I've come across the same symptoms on various installations of mine. However, I thought in all cases this was because I was in the middle of an update. Anyway, after a prolonged revdep-rebuild, which reinstalled dbus plus another 21 packages, it seems all buttons are back and I can shutdown and hibernate. I have no idea why a revdep-rebuild wanted to rebuild all these packages ... but clearly something I did (like uninstalling/reinstalling plasma-meta, or changing package specific USE flags?) meant all these needed to be rebuilt. I didn't expect this - thank you Dale for nudging me in the right direction and thank you all for your suggestions. :-) Next time I login I'll also check if the missing Power Management module mentioned in systemsettings has resolved itself. > > Also, the sddm DM shutdown/reboot buttons now do not work. O_O > > Those have never worked for me. I just looked at another installation. The default sddm configuration file (/ usr/share/sddm/sddm.conf.d/00default.conf) shows this: [General] # Halt command HaltCommand=/usr/bin/loginctl poweroff In an OpenRC system there is no loginctl. Consequently, unless we define a separate config in /etc/ to use shutdown (with sudo?) it won't work. This systemd-ism may be worth a bug report. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Strange behavior of "tab" key with Libreoffice Calc and Plasma
On Tuesday, 25 June 2019 14:17:21 BST »Q« wrote:
> On Mon, 24 Jun 2019 21:15:55 +0100
>
> Mick wrote:
> > On Monday, 24 June 2019 21:11:48 BST Philip Webb wrote:
> > > 190624 Stefano Crocco wrote:
> > > > On domenica 23 giugno 2019 22:31:33 CEST Philip Webb wrote:
> > > >> That's what it does for me now, using LO 6.2.4.2 on KDE.
> > > >> Here, pressing Tab-Tab simply moves 2 cells to the right.
> > > >
> > > > Do you have the kde use flag enabled ?
> > > > This morning I've tried several combinations of flags
> > > > and only disabling the kde one this issue disappeared.
> > > >
> > > root:529 ~> eix libreoffice
> > > [I] app-office/libreoffice
> > > Available versions: 6.1.5.2 6.2.4.2 **6.2. **
> > >
> > > {accessibility bluetooth +branding coinmp +cups dbus debug eds
> > > firebird googledrive gstreamer +gtk gtk2 java kde ldap +mariadb
> > > mysql odk pdfimport postgres test vlc ELIBC="FreeBSD"
> > > LIBREOFFICE_EXTENSIONS="nlpsolver scripting-beanshell
> > > scripting-javascript wiki-publisher"
> > > PYTHON_SINGLE_TARGET="python2_7 python3_5 python3_6 python3_7"
> > > PYTHON_TARGETS="python2_7 python3_5 python3_6 python3_7"} Installed
> > > versions: 6.2.4.2([2019-06-19 06:18:11])(accessibility cups dbus
> > > gtk gtk2 pdfimport -bluetooth -branding -coinmp -debug -eds
> > > -firebird -googledrive -gstreamer -java -kde -ldap -mariadb -odk
> > > -postgres -test -vlc ELIBC="-FreeBSD"
> > > LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell
> > > -scripting-javascript -wiki-publisher"
> > > PYTHON_SINGLE_TARGET="python3_6 -python2_7 -python3_5 -python3_7"
> > > PYTHON_TARGETS="python2_7 python3_6 -python3_5 -python3_7")
> > >
> > > So, yes (smile).
> >
> > It depends on which VLC plugin is used, KDE, or Gtk. Go to
> > Help/About and you can see when loaded with the KDE VLC plugin the
> > 'tab-losing-cell-focus' bug is present. With the Gtk VLC plugin
> > loaded, the tab works as it should.
>
> Unless my eyes are playing tricks on me, I think you mean which VCL
> (not VLC) is being used. <https://docs.libreoffice.org/vcl.html>
I beg your pardon, yes, I meant to say vcl. I just started LOcalc from within
Enlightenment, which does not load the KDE env profile and which shows:
Version: 6.2.4.2.0+
Build ID: Gentoo official package
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11;
There's no tab problem with this one.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] What the devil?!! [or Plasma teething problems Ia.]
On Tuesday, 25 June 2019 10:14:59 BST Peter Humphrey wrote: > On Monday, 24 June 2019 21:19:09 BST Mick wrote: > > Also, the sddm DM shutdown/reboot buttons now do not work. O_O > It seems that you're a victim of the hopelessly reticulate interactions > among plasma components. Yes, it seems by removing plasma-meta and reinstalling I caused some plasma- KDE hickup, which a revdep-rebuild following this morning's update is now hopefully trying to address. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] What the devil?!! [or Plasma teething problems Ia.]
Thank you both for your suggestions, On Tuesday, 25 June 2019 09:47:16 BST Neil Bothwick wrote: > On Tue, 25 Jun 2019 00:12:56 +0100, Mick wrote: > > > > Can someone please explain how the removal of the 'wireless' USE > > > > flag from powerdevil ends up with no buttons for Suspend-to-RAM, > > > > Hibernation, Reboot or Shutdown under the Leave tab of the KMenu? > > > > What does wireless have to do with those functions which should work > > > > regardless? > > > > > > Those options are still present here. > > > > Thanks Neil, these are the packages which were depcleaned following > > USE="- wireless" for powerdevil, USE="-espeak" for speech-dispatcher > > > and USE="device- mapper-only -thin" for lvm: > Has nobody ever told you about changing only one thing at a time? ;_) > > > 1561390348: Started emerge on: Jun 24, 2019 16:32:28 > > 1561390348: *** emerge --ask --verbose --depclean > > 1561390348: >>> depclean > > 1561390428: === Unmerging... (virtual/w3m-0) > > 1561390432: >>> unmerge success: virtual/w3m-0 > > 1561390432: === Unmerging... (virtual/linux-sources-3) > > 1561390436: >>> unmerge success: virtual/linux-sources-3 > > 1561390436: === Unmerging... (kde-frameworks/networkmanager-qt-5.57.0) > > 1561390440: >>> unmerge success: > > kde-frameworks/networkmanager-qt-5.57.0 1561390440: === Unmerging... > > (sys-block/thin-provisioning-tools-0.7.0) 1561390445: >>> unmerge > > success: sys-block/thin-provisioning-tools-0.7.0 1561390445: === > > Unmerging... (app-accessibility/espeak-1.48.04-r1) 1561390449: >>> > > unmerge success: app-accessibility/espeak-1.48.04-r1 1561390449: === > > Unmerging... (www-client/w3m-0.5.3_p20180125) 1561390453: >>> unmerge > > success: www-client/w3m-0.5.3_p20180125 1561390453: === Unmerging... > > (media-sound/sox-14.4.2-r1) 1561390458: >>> unmerge success: > > media-sound/sox-14.4.2-r1 1561390458: === Unmerging... > > (net-misc/networkmanager-1.16.0) 1561390464: >>> unmerge success: > > net-misc/networkmanager-1.16.0 1561390464: === Unmerging... > > (net-dialup/ppp-2.4.7-r7) 1561390468: >>> unmerge success: > > net-dialup/ppp-2.4.7-r7 1561390468: === Unmerging... > > (net-misc/dhcp-4.4.1) 1561390473: >>> unmerge success: > > net-misc/dhcp-4.4.1 1561390473: === Unmerging... > > (dev-libs/boehm-gc-7.6.4) 1561390478: >>> unmerge success: > > dev-libs/boehm-gc-7.6.4 1561390478: === Unmerging... > > (media-sound/gsm-1.0.13-r1) 1561390482: >>> unmerge success: > > media-sound/gsm-1.0.13-r1 1561390482: === Unmerging... > > (net-libs/libndp-1.7) 1561390486: >>> unmerge success: > > net-libs/libndp-1.7 1561390486: === Unmerging... > > (net-misc/modemmanager-1.8.2-r1) 1561390493: >>> unmerge success: > > net-misc/modemmanager-1.8.2-r1 1561390493: === Unmerging... > > (dev-libs/newt-0.52.20) 1561390497: >>> unmerge success: > > dev-libs/newt-0.52.20 1561390497: === Unmerging... > > (net-dialup/ppp-scripts-0) 1561390501: >>> unmerge success: > > net-dialup/ppp-scripts-0 1561390501: === Unmerging... > > (sys-libs/slang-2.3.2) 1561390505: >>> unmerge success: > > sys-libs/slang-2.3.2 1561390505: === Unmerging... > > (net-libs/libqmi-1.20.2) 1561390510: >>> unmerge success: > > net-libs/libqmi-1.20.2 1561390510: === Unmerging... > > (net-libs/libmbim-1.16.2) 1561390515: >>> unmerge success: > > net-libs/libmbim-1.16.2 1561390515: *** exiting successfully. > > 1561390515: *** terminating. > > 1561390536: Started emerge on: Jun 24, 2019 16:35:36 > > 1561390536: *** emerge --ask --verbose @preserved-rebuild > > 1561390543: *** exiting successfully. > > 1561390543: *** terminating. > > I don't have most of those packages either, I do have w3m and sox but > you'd have to be pretty desperate to start suspecting them. I am! O_O > [ebuild R] kde-plasma/powerdevil-5.16.1:5::gentoo > USE="-brightness-control -debug handbook -wireless" 0 KiB > > It doesn't look like USE affects it either. > > > I can't see anything in there. I also uninstalled and reinstalled > > plasma- meta, but did not depclean anything. Could there be something > > in systemsettings? Yep! Power Management is greyed out: > > > > "Power management configuration module could not be loaded. The Power > > Management Service appears not to be running. This can be solved by > &
Re: [gentoo-user] Plasma teething problems - Part II
On Tuesday, 25 June 2019 10:00:11 BST Peter Humphrey wrote: > On Monday, 24 June 2019 21:40:07 BST Mick wrote: > > According to the current wiki page these days the kde-meta has been > > > > replaced with plasma-meta. This is how I have configured plasma-meta: > > Installed versions: 5.15.5(5)(12:58:00 14/06/19)(bluetooth browser- > > > > integration crypt desktop-portal display-manager elogind handbook legacy- > > systray pam pm-utils sddm wallpapers -consolekit -discover -grub -gtk - > > networkmanager -plymouth -pulseaudio -sdk -systemd) > > > > BUT ... I am thinking of uninstalling it, deplclean-ing my world and > > installing kde-plasma/plasma-desktop which is the slim version, while > > keeping some select kde-meta packages I need/want. > > I made quite a determined attempt to do that on this system. I would > uninstall a meta package, then see what packages would be removed by emerge > -c, and emerge --noreplace any that I wanted to keep. Sounds simple, eh? > Not so. I soon found myself mired in loops and contradictory dependencies > which I couldn't escape. > > I ended up reinstalling from scratch, avoiding as many meta-packages as I > could. I tried to build on kde-plasma/plasma-desktop, but it was simply too > basic. I spent a long time trying to find packages to restore what I was > used to in kde-plasma, but I concluded that it would need the knowledge of > a kde packager. > > So I do still have five meta-packages. Ho hum. > > I don't want to warn you off altogether, but at least be ready for some > tricky work. Lots of it! Thank you Peter, I have been down that rabbit hole myself a few times and I'd rather avoid repeating it as long as I can. The very reason I have not implemented the same approach on this PC and thought of stiking to the wiki, is because my package-at-a-time KDE approach invariably ends up breaking some of the plasma desktop integration I want/need. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] What the devil?!! [or Plasma teething problems Ia.]
On Monday, 24 June 2019 23:41:03 BST Neil Bothwick wrote: > On Mon, 24 Jun 2019 21:19:09 +0100, Mick wrote: > > Can someone please explain how the removal of the 'wireless' USE flag > > from powerdevil ends up with no buttons for Suspend-to-RAM, > > Hibernation, Reboot or Shutdown under the Leave tab of the KMenu? What > > does wireless have to do with those functions which should work > > regardless? > > Those options are still present here. Thanks Neil, these are the packages which were depcleaned following USE="- wireless" for powerdevil, USE="-espeak" for speech-dispatcher and USE="device- mapper-only -thin" for lvm: 1561390348: Started emerge on: Jun 24, 2019 16:32:28 1561390348: *** emerge --ask --verbose --depclean 1561390348: >>> depclean 1561390428: === Unmerging... (virtual/w3m-0) 1561390432: >>> unmerge success: virtual/w3m-0 1561390432: === Unmerging... (virtual/linux-sources-3) 1561390436: >>> unmerge success: virtual/linux-sources-3 1561390436: === Unmerging... (kde-frameworks/networkmanager-qt-5.57.0) 1561390440: >>> unmerge success: kde-frameworks/networkmanager-qt-5.57.0 1561390440: === Unmerging... (sys-block/thin-provisioning-tools-0.7.0) 1561390445: >>> unmerge success: sys-block/thin-provisioning-tools-0.7.0 1561390445: === Unmerging... (app-accessibility/espeak-1.48.04-r1) 1561390449: >>> unmerge success: app-accessibility/espeak-1.48.04-r1 1561390449: === Unmerging... (www-client/w3m-0.5.3_p20180125) 1561390453: >>> unmerge success: www-client/w3m-0.5.3_p20180125 1561390453: === Unmerging... (media-sound/sox-14.4.2-r1) 1561390458: >>> unmerge success: media-sound/sox-14.4.2-r1 1561390458: === Unmerging... (net-misc/networkmanager-1.16.0) 1561390464: >>> unmerge success: net-misc/networkmanager-1.16.0 1561390464: === Unmerging... (net-dialup/ppp-2.4.7-r7) 1561390468: >>> unmerge success: net-dialup/ppp-2.4.7-r7 1561390468: === Unmerging... (net-misc/dhcp-4.4.1) 1561390473: >>> unmerge success: net-misc/dhcp-4.4.1 1561390473: === Unmerging... (dev-libs/boehm-gc-7.6.4) 1561390478: >>> unmerge success: dev-libs/boehm-gc-7.6.4 1561390478: === Unmerging... (media-sound/gsm-1.0.13-r1) 1561390482: >>> unmerge success: media-sound/gsm-1.0.13-r1 1561390482: === Unmerging... (net-libs/libndp-1.7) 1561390486: >>> unmerge success: net-libs/libndp-1.7 1561390486: === Unmerging... (net-misc/modemmanager-1.8.2-r1) 1561390493: >>> unmerge success: net-misc/modemmanager-1.8.2-r1 1561390493: === Unmerging... (dev-libs/newt-0.52.20) 1561390497: >>> unmerge success: dev-libs/newt-0.52.20 1561390497: === Unmerging... (net-dialup/ppp-scripts-0) 1561390501: >>> unmerge success: net-dialup/ppp-scripts-0 1561390501: === Unmerging... (sys-libs/slang-2.3.2) 1561390505: >>> unmerge success: sys-libs/slang-2.3.2 1561390505: === Unmerging... (net-libs/libqmi-1.20.2) 1561390510: >>> unmerge success: net-libs/libqmi-1.20.2 1561390510: === Unmerging... (net-libs/libmbim-1.16.2) 1561390515: >>> unmerge success: net-libs/libmbim-1.16.2 1561390515: *** exiting successfully. 1561390515: *** terminating. 1561390536: Started emerge on: Jun 24, 2019 16:35:36 1561390536: *** emerge --ask --verbose @preserved-rebuild 1561390543: *** exiting successfully. 1561390543: *** terminating. I can't see anything in there. I also uninstalled and reinstalled plasma- meta, but did not depclean anything. Could there be something in systemsettings? Yep! Power Management is greyed out: "Power management configuration module could not be loaded. The Power Management Service appears not to be running. This can be solved by starting or scheduling it inside "Startup and Shutdown". What am I supposed to add in "Startup and Shutdown"? There is no Power Management to start up and no button to add any services. :-/ -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Plasma teething problems - Part II
protected: none omitted: none net-misc/socat selected: 1.7.3.2 protected: none omitted: none kde-plasma/khotkeys selected: 5.15.5 protected: none omitted: none sys-apps/xdg-desktop-portal selected: 1.2.0 protected: none omitted: none x11-misc/sddm selected: 0.18.0 protected: none omitted: none dev-libs/crypto++ selected: 7.0.0-r3 protected: none omitted: none All selected packages: =dev-libs/crypto++-7.0.0-r3 =kde-plasma/xembed-sni- proxy-5.15.5 =dev-libs/libpwquality-1.4.0 =kde-plasma/ksshaskpass-5.15.5 =kde- plasma/kinfocenter-5.15.5 =kde-plasma/kwallet-pam-5.15.5 =kde-plasma/ khotkeys-5.15.5 =kde-plasma/xdg-desktop-portal-kde-5.15.5-r1 =kde-plasma/ kgamma-5.15.5 =kde-plasma/drkonqi-5.15.5 =kde-plasma/systemsettings-5.15.5 =kde-frameworks/kxmlrpcclient-5.57.0 =kde-plasma/plasma-vault-5.15.5 =net- misc/socat-1.7.3.2 =kde-plasma/plasma-workspace-wallpapers-5.15.5 =x11-misc/ sddm-0.18.0 =kde-plasma/sddm-kcm-5.15.5 =kde-plasma/kwrited-5.15.5 =kde- plasma/kscreen-5.15.5 =kde-plasma/user-manager-5.15.5 =kde-plasma/plasma- browser-integration-5.15.5 =kde-plasma/kdeplasma-addons-5.15.5 =kde-plasma/ kwayland-integration-5.15.5 =kde-plasma/bluedevil-5.15.5 =kde-plasma/ kmenuedit-5.15.5 =sys-fs/cryfs-0.9.9 =sys-apps/accountsservice-0.6.50-r1 =sys- apps/xdg-desktop-portal-1.2.0 =kde-frameworks/bluez-qt-5.57.0 >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. I need to find a different solution ... -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Plasma teething problems - Part II
On Monday, 24 June 2019 21:16:51 BST Dale wrote: > I went through this a few years ago. I had some large programs > installed that I didn't use, Kmail and others. I wanted to clean them > out but at the time I had installed KDE with kde-meta. Basically, that > installs everything KDE, wanted or not. I uninstalled that and went > these instead: According to the current wiki page these days the kde-meta has been replaced with plasma-meta. This is how I have configured plasma-meta: Installed versions: 5.15.5(5)(12:58:00 14/06/19)(bluetooth browser- integration crypt desktop-portal display-manager elogind handbook legacy- systray pam pm-utils sddm wallpapers -consolekit -discover -grub -gtk - networkmanager -plymouth -pulseaudio -sdk -systemd) BUT ... I am thinking of uninstalling it, deplclean-ing my world and installing kde-plasma/plasma-desktop which is the slim version, while keeping some select kde-meta packages I need/want. > root@fireball / # equery list *kde*meta* > * Searching for *kde*meta* ... > [IP-] [ ] kde-apps/kdeadmin-meta-19.04.2:5 I have this installed too. > [IP-] [ ] kde-apps/kdebase-meta-19.04.2:5 I think the kdebase-meta was meant to be a transitional package from KDE4 to plasma/KDE5. I suspect this has been superseded by kde-plasma/plasma-meta, but I'm not sure. In any case, I do not have this installed. > [IP-] [ ] kde-apps/kdecore-meta-19.04.2:5 I have this installed too. > [IP-] [ ] kde-apps/kdegames-meta-19.04.2:5 No games for me, thanks. > [IP-] [ ] kde-apps/kdegraphics-meta-19.04.2:5 > [IP-] [ ] kde-apps/kdemultimedia-meta-19.04.2:5 I have these two installed, plus: [IP-] [ ] kde-apps/kdenetwork-meta-18.12.3:5 [IP-] [ ] kde-apps/kdepim-meta-18.12.3:5 [IP-] [ ] kde-apps/kdeutils-meta-18.12.3:5 > This is one of the things I like about Gentoo, being able to cut off or > get rid of things I don't want. USE flags help with that a lot. > > Glad you got it sorted out. Sadly I'm not there yet. I've got to figure out how to get back my Suspend to Ram, Hibernate, Reboot, and Shutdown buttons, without re-importing NetworkManager, or at least without having it being started by powerdevil. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] What the devil?!! [or Plasma teething problems Ia.]
Can someone please explain how the removal of the 'wireless' USE flag from powerdevil ends up with no buttons for Suspend-to-RAM, Hibernation, Reboot or Shutdown under the Leave tab of the KMenu? What does wireless have to do with those functions which should work regardless? Also, the sddm DM shutdown/reboot buttons now do not work. O_O Is Plasma/KDE trying to emulate the inflexibility of Gnome? (no flamewar intended please). -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Strange behavior of "tab" key with Libreoffice Calc and Plasma
On Monday, 24 June 2019 21:11:48 BST Philip Webb wrote:
> 190624 Stefano Crocco wrote:
> > On domenica 23 giugno 2019 22:31:33 CEST Philip Webb wrote:
> >> That's what it does for me now, using LO 6.2.4.2 on KDE.
> >> Here, pressing Tab-Tab simply moves 2 cells to the right.
> >
> > Do you have the kde use flag enabled ?
> > This morning I've tried several combinations of flags
> > and only disabling the kde one this issue disappeared.
>
> root:529 ~> eix libreoffice
> [I] app-office/libreoffice
> Available versions: 6.1.5.2 6.2.4.2 **6.2. ** {accessibility
> bluetooth +branding coinmp +cups dbus debug eds firebird googledrive
> gstreamer +gtk gtk2 java kde ldap +mariadb mysql odk pdfimport postgres
> test vlc ELIBC="FreeBSD" LIBREOFFICE_EXTENSIONS="nlpsolver
> scripting-beanshell scripting-javascript wiki-publisher"
> PYTHON_SINGLE_TARGET="python2_7 python3_5 python3_6 python3_7"
> PYTHON_TARGETS="python2_7 python3_5 python3_6 python3_7"} Installed
> versions: 6.2.4.2([2019-06-19 06:18:11])(accessibility cups dbus gtk gtk2
> pdfimport -bluetooth -branding -coinmp -debug -eds -firebird -googledrive
> -gstreamer -java -kde -ldap -mariadb -odk -postgres -test -vlc
> ELIBC="-FreeBSD" LIBREOFFICE_EXTENSIONS="-nlpsolver -scripting-beanshell
> -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python3_6
> -python2_7 -python3_5 -python3_7" PYTHON_TARGETS="python2_7 python3_6
> -python3_5 -python3_7")
>
> So, yes (smile).
It depends on which VLC plugin is used, KDE, or Gtk. Go to Help/About and you
can see when loaded with the KDE VLC plugin the 'tab-losing-cell-focus' bug is
present. With the Gtk VLC plugin loaded, the tab works as it should.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Plasma teething problems - Part I
On Monday, 24 June 2019 12:31:26 BST Mick wrote: > On Monday, 24 June 2019 12:17:51 BST Neil Bothwick wrote: > > On Mon, 24 Jun 2019 12:00:36 +0100, Mick wrote: > > > Could someone more knowledgeable in Plasma/KDE shenanigans please > > > explain how I can end up with a workable USB wireless dongle, which I > > > can enable/disable at will? > > > > Set USE="-wireless" for powerdevil > > > > I have KDE on this laptop, with no NM. The wireless connection is managed > > by systemd-networkd here, but the same should be possible with openrc and > > no NM. > > Excellent! This is what I was looking for. Thank you Neil. :-) I can attest to the fact powerdevil with its devilish tentacles which dragged in NetworkManager was the cause of my problems, plus KDE's default setting: 'Enable bluetooth integration' was causing all this obex race by dbus. Now I have a 'normal' system to work with. :-) The only thing I noticed after I disabled the wifi, rfkilled it and pulled the USB dongle was this entry in the logs: Jun 24 18:23:51 localhost kernel: usb 1-1: USB disconnect, device number 3 Jun 24 18:23:53 localhost /etc/init.d/net.wlp0s18f2u1[5619]: net.wlp0s18f2u1: not allowed to be hotplugged Jun 24 18:23:53 localhost dhcpcd[3208]: wlp0s18f2u1: removing interface I'm not sure of its meaning ... Is openrc angry with me for unplugging the by definition pluggable and already disabled USB device? :-/ -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] why does Udisks require Lvm2 ?
On Monday, 24 June 2019 09:40:07 BST Peter Humphrey wrote:
> On Monday, 24 June 2019 08:46:55 BST Neil Bothwick wrote:
> > So the choice is between an unsupported configuration or installing a
> > handful of binaries that you will never use. Unless space was an issue,
> > there's about 6NB difference, I'd go with the latter, although
> > UNSUPPORTED != DOESNOTWORK
>
> Yes, I've done the same on two boxes that have no need of lvm. It does seem
> wasteful though.
>
> I forget the detail now, but a recent-ish version of sys-fs/cryptsetup found
> it needed a hard dependency on some of the code in lvm2. It seems to me
> that we have here an opportunity for redesign of certain packages. ("We"
> the community, that is.)
>
> On this box, which does need lvm for RAID-1 on two SSDs:
>
> $ equery d lvm2
> * These packages depend on lvm2:
> app-emulation/virtualbox-6.0.8 (lvm ? sys-fs/lvm2)
> net-fs/nfs-utils-2.4.1 (nfsv41 ? sys-fs/lvm2)
> sys-block/gparted-0.33.0 (dmraid ? >=sys-fs/lvm2-2.02.45)
> sys-block/parted-3.2_p25 (device-mapper ? >=sys-fs/lvm2-2.02.45)
> sys-fs/cryptsetup-2.1.0 (sys-fs/lvm2[static-libs(+)])
> (sys-fs/lvm2)
> sys-fs/e2fsprogs-1.45.2 (cron ? sys-fs/lvm2[-device-mapper-only(-)])
> sys-fs/udisks-2.8.3 (lvm ? sys-fs/lvm2)
> sys-libs/libblockdev-2.22 (device-mapper ? sys-fs/lvm2)
> (dmraid ? sys-fs/lvm2)
> (lvm ? sys-fs/lvm2)
>
> Other than sys-fs/cryptsetup, those are all conditional dependencies.
Also to mention, the installation following adjustment of the USE flags
completes like so:
* Messages for package sys-fs/lvm2-2.02.184-r4:
* Make sure the "lvm" init script is in the runlevels:
* # rc-update add lvm boot
*
* Make sure to enable lvmetad in /etc/lvm/lvm.conf if you want
* to enable lvm autoactivation and metadata caching.
>>> Auto-cleaning packages...
==
There is no lvm init script left in my system:
# rc-update -s -v | grep -i lvm
#
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] why does Udisks require Lvm2 ?
On Monday, 24 June 2019 18:00:29 BST Peter Humphrey wrote: > On Monday, 24 June 2019 16:59:08 BST Grant Taylor wrote: > > > On this box, which does need lvm for RAID-1 on two SSDs: > > Do you /need/ LVM? Or is it extra that comes with device-mapper? > > No, I do actually use lvm to base a raid-1 file system on. I haven't > considered raid-1 without lvm; is that feasible? Almost totally. They two are separate functions with synergistic interaction. RAID 1 offers redundancy by mirroring data between two block devices. LVM offers a flexible partitioning scheme where you can add space, move, snapshot, etc. data using a logical software layer to manage their storage across partitions and physical disks. I've put together RAID 1 disks with no LVM and used LVM with no RAID. NOTE: To confuse things you can instead use LVM's built in 'RAID functionality' - see below. I recall reading somewhere that SSDs are better used with LVM's natively configured RAID functionality, rather than a separate RAID layer, which in a mirrored RAID it will cause accelerated wear due to the way RAID metadata are mirrored between block devices. I don't think I've ever used LVM's RAID capability, but it would probably boil down to running: lvcreate --mirrors 1 --type raid 1 -n LV_myRAID VG_blah-blah Others more knowledgeable in these technologies could chime in to correct me no doubt. PS. LVM-RAID uses the kernel's mdraid, but with less tools to manage the RAID configuration than mdadm offers: https://unix.stackexchange.com/questions/150644/raiding-with-lvm-vs-mdraid-pros-and-cons -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Plasma teething problems - Part II
On Monday, 24 June 2019 18:04:06 BST Peter Humphrey wrote: > On Monday, 24 June 2019 16:32:19 BST Mick wrote: > > I also found this beauty in /etc/speech-dispatcher/speechd.conf, which I > > uncommented: > > > > # The DisableAutoSpawn option will disable the autospawn mechanism. > > That's the sort of stupid explanation that gives technical authors and other > program documenters a bad name. Gentoo seems to be particularly heavily > afflicted with it. > > > # Thus the server will not start automatically on requests from the > > clients > > DisableAutoSpawn Clearly you have suffered in the hands of USE flag descriptors, which would make even the priestesses of the Oracle of Delphi sound coherent and unambiguous. LOL! -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Strange behavior of "tab" key with Libreoffice Calc and Plasma
On Sunday, 23 June 2019 21:31:33 BST Philip Webb wrote: > 190623 Stefano Crocco wrote: > > a few months ago I started noticing a very annoying behavior > > when pressing the "tab" key in Libreoffice Calc. > > Previously, pressing this key would move the cursor by one cell to the > > right, so that I could immediately start writing into the cell. > > That's what it does for me now, using LO 6.2.4.2 on KDE. Also on the same version, but running Plasma/KDE-5.15.5, single tab moves to the cell on the right AND selects the main menu. :-/ > > Now, while the cursor is moved to the correct cell > > -- I can see the black border around it -- , > > I can't write in it immediately anymore. > > To move the cursor to the next cell and be able to immediately write in > > it, > > I need to press the tab key twice. > > It seems that somehow pressing the tab key once gives focus to the menu > > bar: pressing tab once, then pressing "F" brings down the file menu; > > pressing tab, then pressing "E" displays the edit menu and so on. > > Here, pressing Tab-Tab simply moves 2 cells to the right. Hmm ... are you running a non-KDE environment by any chance? I just tried LO on Englightenment and it works fine, BUT it runs with GTK icons. Various KDE DEs however exhibit the same behaviour here - double tab to move to the right cell and select it to be able to enter data. Another thing I tried is to launch it with: SAL_USE_VCLPLUGIN=gtk3 soffice On a plasma only system, it will not respect this incantation and About always shows "VCL: kde5; " so this leads me to conclude the problem is with the KDE compilation flag. If I remember I'll disable it on the next update and see what happens then. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Plasma teething problems - Part II
On Monday, 24 June 2019 16:22:01 BST Mick wrote: > On Monday, 24 June 2019 12:44:34 BST Dale wrote: > > Mick wrote: > > > I often find a number of speech-dispatcher processes running: > > > 4732 ?SLl0:00 /usr/lib64/speech-dispatcher-modules/sd_dummy > > > /etc/> > > > > > > speech-dispatcher/modules/dummy.conf > > > > > > 4734 ?SLl0:00 > > > /usr/lib64/speech-dispatcher-modules/sd_generic > > > / > > > > > > etc/speech-dispatcher/modules/generic.conf > > > > > > 4736 ?SLl0:00 > > > /usr/lib64/speech-dispatcher-modules/sd_cicero > > > / > > > > > > etc/speech-dispatcher/modules/cicero.conf > > > > > > 4737 ?Z 0:00 \_ [sd_cicero] > > > 4739 ?SLl0:00 > > > /usr/lib64/speech-dispatcher-modules/sd_espeak > > > / > > > > > > etc/speech-dispatcher/modules/espeak.conf > > > > > > 4744 ?Ssl0:00 /usr/bin/speech-dispatcher --spawn > > > --communication-> > > > > > > method unix_socket --socket-path > > > /run/user/1000/speech-dispatcher/speechd.sock > > > > > > I don't know what is starting these processes or what they have to offer > > > to my desktop. Checking systemsettings5/Accessibility Options/Screen > > > Reader, I can see it is NOT enabled. > > > > > > How can I get rid of these? > > > > I would start out by finding out what package /usr/bin/speech-dispatcher > > belongs too. Equery can help with that but other tools can as well. > > Once you find that, then check the USE flags to see what can be adjusted > > to get rid if that. I don't have it here so I can't do it on my system. > > > > Dale > > > > :-) :-) > > Good call Dale, here's what I found: > > app-accessibility/speech-dispatcher is required by dev-qt/qtspeech, > > which is required by kde-apps/kdepim-runtime and kde-apps/kpimtextedit, > neither of which have a USE flag to stop speech-dispatcher kicking off. > > However, speech-dispatcher has USE="espeak" enabled, which I will try to > disable and see what happens thereafter. I also found this beauty in /etc/speech-dispatcher/speechd.conf, which I uncommented: # The DisableAutoSpawn option will disable the autospawn mechanism. # Thus the server will not start automatically on requests from the clients DisableAutoSpawn -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Plasma teething problems - Part II
On Monday, 24 June 2019 12:44:34 BST Dale wrote: > Mick wrote: > > I often find a number of speech-dispatcher processes running: > > 4732 ?SLl0:00 /usr/lib64/speech-dispatcher-modules/sd_dummy > > /etc/> > > speech-dispatcher/modules/dummy.conf > > > > 4734 ?SLl0:00 /usr/lib64/speech-dispatcher-modules/sd_generic > > / > > > > etc/speech-dispatcher/modules/generic.conf > > > > 4736 ?SLl0:00 /usr/lib64/speech-dispatcher-modules/sd_cicero > > / > > > > etc/speech-dispatcher/modules/cicero.conf > > > > 4737 ?Z 0:00 \_ [sd_cicero] > > 4739 ?SLl0:00 /usr/lib64/speech-dispatcher-modules/sd_espeak > > / > > > > etc/speech-dispatcher/modules/espeak.conf > > > > 4744 ?Ssl0:00 /usr/bin/speech-dispatcher --spawn > > --communication-> > > method unix_socket --socket-path > > /run/user/1000/speech-dispatcher/speechd.sock > > > > I don't know what is starting these processes or what they have to offer > > to my desktop. Checking systemsettings5/Accessibility Options/Screen > > Reader, I can see it is NOT enabled. > > > > How can I get rid of these? > > I would start out by finding out what package /usr/bin/speech-dispatcher > belongs too. Equery can help with that but other tools can as well. > Once you find that, then check the USE flags to see what can be adjusted > to get rid if that. I don't have it here so I can't do it on my system. > > Dale > > :-) :-) Good call Dale, here's what I found: app-accessibility/speech-dispatcher is required by dev-qt/qtspeech, which is required by kde-apps/kdepim-runtime and kde-apps/kpimtextedit, neither of which have a USE flag to stop speech-dispatcher kicking off. However, speech-dispatcher has USE="espeak" enabled, which I will try to disable and see what happens thereafter. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Plasma teething problems - Part I
On Monday, 24 June 2019 15:53:04 BST Philip Webb wrote: > 190624 Mick wrote: > > On Monday, 24 June 2019 12:17:51 BST Neil Bothwick wrote: > >> On Mon, 24 Jun 2019 12:00:36 +0100, Mick wrote: > >>> Could someone more knowledgeable in Plasma/KDE shenanigans please > >>> explain how I can end up with a workable USB wireless dongle, which I > >>> can enable/disable at will? > >> > >> Set USE="-wireless" for powerdevil > > > > Excellent! This is what I was looking for. Thank you Neil. :-) > > Finally, a good example of the value of 'USE-"-* ... "' in make.conf ! > I had no idea of any of this & don't need 'powerdevil', > but the '-wireless' flag has been set all along anyway (grin). > > Yes, I know there are opposite cases too. TBH the opposite cases must be overwhelmingly more that this one. If it were a single package *and* you know which one it is, then it is easy to look at its USE flags and make a call to affect its functionality. In my example here I couldn't see the wood for the Plasma/KDE trees, until Neil pointed the particular tree I should be barking under ... :-) I still wouldn't apply a 'USE-"-* ... "' approach unless I was looking for a way to spend many hours contemplating the causes of breaking stuff and then breaking them again after an update/upgrade. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Plasma teething problems - Part I
On Monday, 24 June 2019 12:17:51 BST Neil Bothwick wrote: > On Mon, 24 Jun 2019 12:00:36 +0100, Mick wrote: > > Could someone more knowledgeable in Plasma/KDE shenanigans please > > explain how I can end up with a workable USB wireless dongle, which I > > can enable/disable at will? > > Set USE="-wireless" for powerdevil > > I have KDE on this laptop, with no NM. The wireless connection is managed > by systemd-networkd here, but the same should be possible with openrc and > no NM. Excellent! This is what I was looking for. Thank you Neil. :-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Plasma teething problems - Part II
I often find a number of speech-dispatcher processes running: 4732 ?SLl0:00 /usr/lib64/speech-dispatcher-modules/sd_dummy /etc/ speech-dispatcher/modules/dummy.conf 4734 ?SLl0:00 /usr/lib64/speech-dispatcher-modules/sd_generic / etc/speech-dispatcher/modules/generic.conf 4736 ?SLl0:00 /usr/lib64/speech-dispatcher-modules/sd_cicero / etc/speech-dispatcher/modules/cicero.conf 4737 ?Z 0:00 \_ [sd_cicero] 4739 ?SLl0:00 /usr/lib64/speech-dispatcher-modules/sd_espeak / etc/speech-dispatcher/modules/espeak.conf 4744 ?Ssl0:00 /usr/bin/speech-dispatcher --spawn --communication- method unix_socket --socket-path /run/user/1000/speech-dispatcher/speechd.sock I don't know what is starting these processes or what they have to offer to my desktop. Checking systemsettings5/Accessibility Options/Screen Reader, I can see it is NOT enabled. How can I get rid of these? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Plasma teething problems - Part I
Well, not Plasma's but mine for sure. I have been chasing my tail trying to reverse engineer processes/services/applications I do not want auto-running on a fresh Plasma installation and I'm fast losing the will to live. I've installed plasma-meta plus some kde-apps meta packages as follows: kde-apps/kdeadmin-meta kde-apps/kdecore-meta kde-apps/kdegraphics-meta kde-apps/kdemultimedia-meta kde-apps/kdenetwork-meta kde-apps/kdepim-meta kde-apps/kdeutils-meta kde-apps/kwalletmanager kde-frameworks/oxygen-icons kde-plasma/plasma-meta One of the above[1] brought in NetworkManager, which I don't use because for my use case there's nothing wrong with openrc netifrc scripts. When I plug in a USB wireless adaptor nothing happens since it stays dormant, although its LED illuminates. Then I enable it by starting 'net.wlp0s18f2u1' and at that point NM starts fighting over the wireless adaptor, resulting in the unpleasant phenomenon of dropping the connection every few minutes and changing its MAC address, consequently rendering it unusable with APs which implement ACL. [1] kde-plasma/plasma-meta requires kde-plasma/powerdevil, which requires kde- frameworks/networkmanager-qt, which requires net-misc/networkmanager, which requires net-misc/modemmanager So I naively thought, let's try stopping NM (note: the NetworkManager rc service is not set to run at any level, so something else is starting it). The moment I stop NM I find my logs being flooded with a storm of 'dbus failing to start obex', which bluez wants. Note: I have not started a bluetooth service, or tried running bluetootctl, and BTW rfkill shows the bluetooth adaptor is soft blocked anyway. So I now try to stop dbus and restart it, which results in losing access to any Plasma menu applications, so I can't launch any application. It may be worth mentioning when I leave alone NM and just disable the USB adaptor from openrc, I also lose access to launching KDE applications (the error message when trying to launch an app from a terminal mentions a Qt error). Could someone more knowledgeable in Plasma/KDE shenanigans please explain how I can end up with a workable USB wireless dongle, which I can enable/disable at will? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] why does Udisks require Lvm2 ?
On Sunday, 23 June 2019 10:20:58 BST Neil Bothwick wrote: > On Sat, 22 Jun 2019 16:34:08 -0600, Grant Taylor wrote: > > On 6/22/19 3:55 PM, Neil Bothwick wrote: > > > The indentation shows that is is a hard dependency of cryptsetup, > > > which is backed up by reading the ebuild. I expect that it needs the > > > device-maper functionality provided by lvm, in which case you can set > > > the device-mapper-only USE flag to avoid installing the full lvm > > > suite. > > > > Why isn't device-mapper it's own package‽ One which LVM depends on. > > No idea, but I'd guess it's got something to do with not reinventing the > wheel. From a maintenance point of view, a USE flag would be less effort > than two packages. > > > Multi-Path (as in dm-multipath) can easily be used without LVM. > > Which is why the USE flag exists, to avoid installing LVM. Yes, provided USE="-thin" is set, which is enabled by default. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [OT] Speaker chat. Was Video card, splitter and issues.
On Sunday, 23 June 2019 12:00:08 BST Dale wrote: > I've read where people try that but they say in most cases, the sound is > out of sync. Usually the sound is a little ahead of the video. This is mostly affecting poorly transcoded videos, with incorrect timestamps. There's a 'lip-sync' setting in many AVRs and Smart TVs to address this problem, but yes, if the video itself is missing the required metadata to sync audio and video you could have problems. TBH I have rarely encountered this myself with my local set up. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Video card, splitter and issues.
On Sunday, 23 June 2019 04:40:33 BST Dale wrote: > I plan to re-engineer my TV so I can have external > speakers on it next. That I plan to have a small sub and a pair of two > ways for. Before you re-engineer the wheel, you may want to look at using your amplifier as an external AVR to play audio straight from your source over HDMI, while passing the video to the TV. All smart TVs are capable of selecting internal of external speakers/AVR system for the audio. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: line wrap over in xterm/konsole
On Saturday, 22 June 2019 18:04:49 BST Grant Taylor wrote: > On 6/22/19 2:13 AM, Mick wrote: > > After all changing the shell option in .bashrc does not affect the > > display within the xterm window. > > "shell option in .bashrc"??? > > Are you launching a different shell from Bash? (.bashrc is inherently > Bash.) > > Or are you using Bash as your interactive shell and using a different > shell for sub-commands / forks / etc.? I am using bash. In a previous message Jorge suggested I add: shopt -s checkwinsize in my bashrc which I did, but it didn't change anything. > > This is the problem I was describing as 'annoying'. Xterm draws the > > output once to fill in the real estate of the current xterm window, > > but changing the window width does not redraw each line to reflow it > > across the new window width. > > Agreed. This is the behavior I've seen (and expected) from XTerm for 20 > years. [snip ...] > > Again in my systems xterm will truncate lines when shrinking the width > > of the window. This truncated output is now lost. Increasing the > > width of the window will not restore the truncated lines. Scrolling up > > will now draw lines in the new full width of the xterm window, but > > the truncated lines remain truncated and their information is lost. > > Agreed. This is what I've seen and come to expect from XTerm after > using it for 20 years. Fair enough, I think we nailed this. (u)rxvt does what I prefer. I'll keep using it and accept xterm does things differently. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: wpa_supplicant.conf incongruity
On Wednesday, 19 June 2019 19:41:08 BST Ian Zimmerman wrote: > On 2019-06-19 10:32, Mick wrote: > > Having read the above and more in the example file, I thought the way > > to define a GROUP would be to just add a single directive, e.g.: > > > > GROUP=users > > I remember doing just this some time ago and it worked. I think this is > a case of the code leaving the documentation in dust. Thanks Ian, it's probably just that and the docs need updating. While working with the same wireless USB dongle I noticed its MAC address changes randomly, (almost) every time restart it. I can't recall what setting (kernel or wpa_supplicant) may be causing this. Although this is good for anonymity, it messes up my WAP access control list ... Any idea what setting generates random MAC addresses? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Massive kmail breakage with mariadb-10.4.6
On Saturday, 22 June 2019 12:33:29 BST Neil Bothwick wrote: > On Sat, 22 Jun 2019 10:07:46 +0100, Peter Humphrey wrote: > > Yesterday's routine update took mariadb from 10.3.16 to 10.4.6. When I > > came to look at my emails today, kmail couldn't do anything. To start > > with, it was stuck in an endless, looping attempt to display the > > current email. Then it couldn't archive the inbox, then it couldn't > > import from an archive. I couldn't even move an email from one folder > > to another. Akonadictl fsck and vacuum seemed to run but didn't improve > > anything. Even reverting to an old copy of my home directory didn't > > help. > > Did you restart msyqld and run mysql_upgrade? AFAIK when akonadi (re)starts it always runs mysql_upgrade. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Massive kmail breakage with mariadb-10.4.6
On Saturday, 22 June 2019 10:07:46 BST Peter Humphrey wrote: > Hello lists, > > Yesterday's routine update took mariadb from 10.3.16 to 10.4.6. When I came > to look at my emails today, kmail couldn't do anything. To start with, it > was stuck in an endless, looping attempt to display the current email. Then > it couldn't archive the inbox, then it couldn't import from an archive. I > couldn't even move an email from one folder to another. Akonadictl fsck and > vacuum seemed to run but didn't improve anything. Even reverting to an old > copy of my home directory didn't help. > > Eventually I noticed that mariadb had been upgraded, so I masked the latest > version and reverted to the older one. Lo! and Behold! Kmail sprang back > into life. > > I've sent this to both the relevant lists; I hope that's not a heinous > transgression. Perhaps mariadb-10.4.6 has had some major code changes which make it incompatible with the 10.3.16 database structures, although you wouldn't expect the level of breakage you're describing happening on a minor version update. Usually this incantation works: pkill kmail akonadictl stop akonadictl start akonadictl fsck akonadictl vacuum with a reasonable waiting time between each step to make sure the command has finished processing the db files. If the db itself has been corrupted badly (as it can happen on a ropey fs) then deleting and recreating the affected akonadi resource may be a better option. Did you try removing the akonadi resource, then recreating it and waiting for mariadb to re-index the contents of your emails/contacts/notes/what-ever? When things go awry on a system using btrfs and no mirror, this is my nuclear option to restore a working kdepim. PS. One of these days I will try to educate myself better on recovering from btrfs corruption (or more likely reformat the fs to ext4 and forget about it). ;-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: line wrap over in xterm/konsole
On Saturday, 22 June 2019 09:51:48 BST Jorge Almeida wrote: > On Sat, Jun 22, 2019 at 9:36 AM Mick wrote: > > On Saturday, 22 June 2019 08:52:56 BST Jorge Almeida wrote: > > > However, > > > my urxvt behaves as you describe, more or less: > > > - open urxvt > > > - cat some file with long enough lines > > > - lines wrap > > > - shrink window (horizontally) > > > - contents are NOT redrawn (just like xterm) > > > > OK, we have a difference in behaviour here. In my urxvt lines longer than > > the window shrinking width are redrawn and wrap into the next line. > > > > > - restore window size > > > > Wrapped lines will now unwrap to take up the increasing window width. > > Unlike xterm, no characters are truncated/lost in urxvt. > > > > > - cat same file, etc > > > - contents are now redrawn properly! > > > > > > It appears urxvt does the job by itself (minus what seems to be a bug) > > > > Jorge, your urxvt seems to work differently to my installations here. > > Nevertheless, I'm coming to the conclusion xterm won't behave in the same/ > > similar way as urxvt when it comes to redrawing its window contents. > > Just to make sure there is no misunderstanding: the apparent bug only > manifests itself the first time I do the shrinking/restoring stuff, > after launching a urxvt window. Following tries will show the desired > behaviour. Can you confirm it doesn't happen in your installation? Correct, I do not observe the bug you mention in my installation. I also tried in fluxbox and the redrawing happens in the same way right from the start, except fluxbox does not use a compositor, so (re)wrapping is a bit jerky and shows up half a second after I stopped resizing the window. I need to explain I have added urxvtd in my start up: if [ -x /usr/bin/urxvtd ]; then /usr/bin/urxvtd --opendisplay --fork --quiet fi so additional terminals launched with '/usr/bin/urxvtc -pe tabbed' reuse the same single process of the daemon, making them faster and more economical in resource usage. I assume they inherit some of what's already in memory and this may be a reason why I don't observe your reported bug - although I can't recall if I have this running in fluxbox. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: line wrap over in xterm/konsole
On Saturday, 22 June 2019 08:52:56 BST Jorge Almeida wrote: > There is a dev-libs/libtermkey, which I don't have installed. I don't have this installed either. I suppose it does not affect the drawing behavior. > However, > my urxvt behaves as you describe, more or less: > - open urxvt > - cat some file with long enough lines > - lines wrap > - shrink window (horizontally) > - contents are NOT redrawn (just like xterm) OK, we have a difference in behaviour here. In my urxvt lines longer than the window shrinking width are redrawn and wrap into the next line. > - restore window size Wrapped lines will now unwrap to take up the increasing window width. Unlike xterm, no characters are truncated/lost in urxvt. > - cat same file, etc > - contents are now redrawn properly! > > It appears urxvt does the job by itself (minus what seems to be a bug) Jorge, your urxvt seems to work differently to my installations here. Nevertheless, I'm coming to the conclusion xterm won't behave in the same/ similar way as urxvt when it comes to redrawing its window contents. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: line wrap over in xterm/konsole
On Saturday, 22 June 2019 00:44:28 BST Grant Taylor wrote: > On 6/21/19 5:03 PM, Jorge Almeida wrote: > > ## equery uses x11-terms/xterm > > [ Legend : U - final flag setting for installation] > > [: I - package is installed with flag ] > > [ Colors : set, unset ] > > > > * Found these USE flags for x11-terms/xterm-337: > > U I > > - - Xaw3d: Add support for the 3d athena widget set > > + + openpty : Use openpty() in preference to posix_openpt() > > - - toolbar : Enable the xterm toolbar to be built > > + + truetype : Add support for FreeType and/or FreeType2 fonts > > + + unicode : Add support for Unicode > > - - xinerama : Add support for querying multi-monitor screen geometry > > through> > > the Xinerama API > > > > ~ > > That's what I expected. These USE flags are the same like mine. > > Ah, no, it doesn't. I thought Mick's problem was with the shell. > > Ah. I don't think it is a shell related problem (but may be wrong). After all changing the shell option in .bashrc does not affect the display within the xterm window. > > Shrinking the window truncates the visible lines. Restoring the size > > doesn't restore the truncated contents. > > Agreed. This is the problem I was describing as 'annoying'. Xterm draws the output once to fill in the real estate of the current xterm window, but changing the window width does not redraw each line to reflow it across the new window width. > > This was expected. After all, the output of "cat foo" is not processed > > through readline. > > I don't think that readline has anything to do with this. > > > Maybe I misunderstood the OP's problem? > > Ah. Apologies for my confusing description - I'll have another go below. > > (But then, how can rxvt behave differently?) > > I don't know about rxvt per say. > > But I thought there was a common library (libterm?) used by a number of > terminal emulators that actually saved the output to a temporary file. > That way they could re-display the output if (when) the window size changed. I ran ldd and as is logical I can see there are some differences in the libs used by both programs. Neither of them use libterm. > After emerging and testing rxvt, yes, it will rewrap the line to the new > window width. It seems as if it saves the output as discreet lines and > re-wraps them individually based on the terminal width. So, the output > of an ls -l in a 132 character window, causes each line to be re-wrapped > (as below) when reducing the window width. > > This 40 character wide… > > > > > > > …becomes this 30 character wide. > > aa > aa > bb > bb > cc > cc > dd > dd In my systems urxvt will wrap lines when shrinking the width of the window AND unwrap them when increasing the width of the window. This is happening in real time as the window expands/contracts. Again in my systems xterm will truncate lines when shrinking the width of the window. This truncated output is now lost. Increasing the width of the window will not restore the truncated lines. Scrolling up will now draw lines in the new full width of the xterm window, but the truncated lines remain truncated and their information is lost. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: line wrap over in xterm/konsole
On Friday, 21 June 2019 19:29:36 BST Jorge Almeida wrote: > In case it is a bash thing: > Do you have a line > shopt -s checkwinsize > in ~/.bashrc ? > If not, add it and then experiment with a new xterm window > (maybe rxvt doesn't require it, for some reason...) Thanks again for persevering Jorge. I added the above shell option, logout/in and tried again on xterm and konsole, but with no change. :-( I tried this on two different installations, both running Plasma/KDE and using bash as shell. Fair enough, I'll carry on using urxvt - one more reason to prefer it. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: line wrap over in xterm/konsole
Thanks Jorge, On Friday, 21 June 2019 18:43:56 BST Jorge Almeida wrote: > On Fri, Jun 21, 2019 at 5:32 PM Mick wrote: > > On Friday, 21 June 2019 13:57:23 BST Mick wrote: > > In case what I am asking for is not clear: How can I make xterm/konsole > > behave like rxvt-unicode does and redraw the content to fit the changed > > window width? > > CTRL + middle button -> Enable auto wraparound I seem to have this enabled, as far as the GUI shows, along with reverse wraparound - not sure what the reverse wraparound does. However, lines do not wrap around when I resize the xterm window. :( > Maybe you have this option disabled? To enable it by default, edit > .Xresources and add/edit the line > *VT100.autoWrap: true I've added this too, just in case, logout/in and still won't wrap anything. Well, when I anything, I tried shrinking the window width and when it became narrower than my bash prompt then the prompt only started wrapping around! The rest of the content (I had just run the 'ls' command) would not change from its originally displayed line width. These are the flags I have installed x11-terms/xterm-337 with: openpty truetype unicode -Xaw3d -toolbar -xinerama The same problem applies to other xterm based terminals, on various installations of mine, but as I mentioned rxvt works as I expect/prefer. :-/ -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] query ebuild fields
On Friday, 21 June 2019 18:27:58 BST Ian Zimmerman wrote: > Is there a command to show the fields like DESCRIPTION and HOMEPAGE from > an installed ebuild, or is this one of the annoying gaps in the > framework that must be (and can be) trivially worked around? > > Example: I have installed x11-terms/rxvt-unicode. I don't know what it > is (no, really! :-P ) and I sure as h*ll don't know the exact version > number I have. I want to visit the upstream website to learn more. > > I know the following command will mostly do it, but it will > occassionally show too much and scroll the relevant result off the > screen. Also, being a search, it is much slower than necessary. > > emerge --search --quiet n x11-terms/rxvt-unicode I use 'eix -l ' to get this sort of information. I'm sure there are cleverer options to use with eix, so it only prints the database fields you want, but the above has served most of my needs well. Install app-portage/ eix, then run eix-update and from then on you can use eix-sync to sync portage and/or overlays with a mirror and search for the package you want. rxvt-unicode is a terminal emulator, like xterm, konsole, terminology, xfce4- terminal , etc. which you use within your xsession, instead of having to switch over to a tty. There's even a page about it - I can't recall having read before, but it looks quite detailed: https://wiki.gentoo.org/wiki/Rxvt-unicode https://wiki.gentoo.org/wiki/Terminal_emulator HTH -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: line wrap over in xterm/konsole
On Friday, 21 June 2019 13:57:23 BST Mick wrote: > I'm not sure I use the correct terminology below, but please bear with me > while I try to describe a long standing problem I'm trying to solve: > > I've been mostly using x11-terms/rxvt-unicode as a terminal emulator in X. > When resizing its window to a larger width, long lines of code which had > wrapped over to the next line, are re-adjusted (reflow) to the new line > length covering the increased width of the resized wider window. I assume > this is because the urxvt window content is redrawn in real time. Not all > commands allow this. For example, 'ps axf' neither wraps over nor is > redrawn, chopping off all content not fitting within the available terminal > window width. > > In xterm and friends the lines remain at the same original fixed width, > whether the window is resized to a wider setting or not. In other words the > line of code does not reflow to adapt to the extra length afforded by a now > wider window aperture. > > Is there some setting I can apply to address this annoying phenomenon? In case what I am asking for is not clear: How can I make xterm/konsole behave like rxvt-unicode does and redraw the content to fit the changed window width? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] line wrap over in xterm/konsole
I'm not sure I use the correct terminology below, but please bear with me while I try to describe a long standing problem I'm trying to solve: I've been mostly using x11-terms/rxvt-unicode as a terminal emulator in X. When resizing its window to a larger width, long lines of code which had wrapped over to the next line, are re-adjusted (reflow) to the new line length covering the increased width of the resized wider window. I assume this is because the urxvt window content is redrawn in real time. Not all commands allow this. For example, 'ps axf' neither wraps over nor is redrawn, chopping off all content not fitting within the available terminal window width. In xterm and friends the lines remain at the same original fixed width, whether the window is resized to a wider setting or not. In other words the line of code does not reflow to adapt to the extra length afforded by a now wider window aperture. Is there some setting I can apply to address this annoying phenomenon? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] 17.1 profiles and no-multilib layout
On Friday, 21 June 2019 08:56:34 BST Kai Peter wrote: > Hi, > > I couldn't find an appropriate documentation for this, so it is not > clear to me how a __no-multilib__ layout looks like with 17.1 profiles. > All for amd64. > > With 17.0-no-multilib '/lib' is a symlink to '/lib64'. For > 17.1-no-multilib I see 4 possibilities: > > 1. no change > > 2. both '/lib' and '/lib64' are directories (don't expect this, but it's > possible) > > 3. 'lib64' is a symlink to '/lib' > > 4. only one folder '/lib' __OR__ 'lib64' exists > > With an eye to lfs I would expect to have one '/lib' only. Did anybody > the switch already and can tell me what happens? > > Thanks > Kai On my amd64 no-multilib system there is of course no /lib32 or /usr/lib32. There are: $ ls -ld /lib* drwxr-xr-x 11 root root 4096 Jun 7 13:23 /lib drwxr-xr-x 8 root root 12288 Jun 14 23:42 /lib64 and $ ls -ld /usr/lib* drwxr-xr-x 21 root root 4096 Jun 15 00:06 /usr/lib drwxr-xr-x 104 root root 159744 Jun 19 08:15 /usr/lib64 drwxr-xr-x 18 root root 4096 Jun 14 23:54 /usr/libexec all of which as you can see are real directories. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Xscreensaver is very slow
On Thursday, 20 June 2019 11:55:07 BST Philip Webb wrote: > 190619 Philip Webb wrote: > > Something seems to have changed in 5.42 : > > I haven't merged anything else which would affect it. > > I can restore 40 or 38 , but does anyone have further suggestions first ? > > I've reverted to 5.40 & the speed is back to normal. > Does anyone have a suggestion what might have been changed ? > The next step seems to be a bug report. I haven't used xscreensaver for a long time, but your problem sounds like it has something to do with the way xscreensaver now hooks into the GPU. You may want to scan changelogs and devs' mailing lists to see if they have changed something which disagrees with your graphics card/driver. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] wpa_supplicant.conf incongruity
This must be the third if not fourth time the syntax in wpa_supplicant.conf bit me - I don't learn easily! ;-) The comments in the example configuration file installed with wpa_supplicant provided under /usr/share/doc/wpa_supplicant-2.6-r10/wpa_supplicant.conf.bz2 explain a Unix control socket for external programs (wpa_cli, wpa_gui, etc.) to access will be created in a (default) directory: /var/run/wpa_supplicant To set access controls for socket(s) which will be created in this directory you can define a GROUP in the wpa_supplicant.conf file, so non-root users may scan for APs and set passwords for them using cli/gui applications. A syntax is given in this file to explain how to go about specifying a GROUP name for managing the cli/gui interface: # When configuring both the directory and group, use following format: # DIR=/var/run/wpa_supplicant GROUP=wheel # DIR=/var/run/wpa_supplicant GROUP=0 # (group can be either group name or gid) # # For UDP connections (default on Windows): The value will be ignored. This # variable is just used to select that the control interface is to be created. # The value can be set to, e.g., udp (ctrl_interface=udp) Here's where things go a bit off-piste. There's an uncommented entry in the next paragraph specifying not an IP protocol, but a Unix socket like so: ctrl_interface=/var/run/wpa_supplicant Having read the above and more in the example file, I thought the way to define a GROUP would be to just add a single directive, e.g.: GROUP=users But this causes wpa_supplicant to fail complaining about my GROUP entry above. Fair enough, from what it says I should also specify the directory. So I copied and pasted verbatim: DIR=/var/run/wpa_supplicant GROUP=wheel Again wpa_supplicant fails to start complaining about the whole line I just added. :-/ So, I look at older wpa_supplicant.conf files of mine and discover the directive needed to specify a GROUP is: ctrl_interface_group=wheel which works faultlessly each time. Am I missing something here, or is the example provided for wpa_supplicant.conf incorrect/incomplete and merits a bug report? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Starting with profile 17.1
On Tuesday, 18 June 2019 22:58:24 BST mad.scientist.at.la...@tutanota.com wrote: > As I'm doing a new install anyway is there any problem with using profile > 17.1 from the start that i should know about? Any big confusing problems > that is, "minor" stuff i can be a little patient with. I've installed a new system and the stage-3 I used did not have the 17.1 profile applied yet. As soon as I chroot'ed into the newly downloaded stage 3 fs, I sync'ed portage and then followed the instructions in the latest news article for migrating to the 17.1 profile. This was quick and easy to do, since I had not installed any packages yet. Once this was completed I duly followed the steps in the gentoo handbook as normal. I understand releng were about to prepare a new stage 3 and live media with profile 17.1, but I don't know if this has been released yet. Either way, if you find /lib32 and /usr/lib32 in your stage 3, just do as I did early in the installation and you'll make light work of it. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Profile switch to 17.1.
On Tuesday, 18 June 2019 17:03:38 BST Dale wrote:
> Alan Mackenzie wrote:
> > Hello, Dale.
> >
> > On Tue, Jun 18, 2019 at 10:12:32 -0500, Dale wrote:
> >> Howdy,
> >> I been working on the profile switch. I followed the directions in the
> >> news item up until the rm part in #12. I did a equery b for a few files
> >> in the two directories and it has files that equery shows belonging to
> >> packages. They are not orphans since they are owned. Here is a list of
> >> the files:
> >> root@fireball / # ls -al /lib32/
> >> total 3956
> >> drwxr-xr-x 14 root root4096 Jun 17 23:14 .
> >> drwxr-xr-x 22 root root 36864 Jun 17 01:18 ..
> >> lrwxrwxrwx 1 root root 12 Jun 17 19:25 cpp -> /usr/bin/cpp
> >> drwxr-xr-x 3 root root4096 Jun 17 19:46 dhcpcd
> >> drwxr-xr-x 70 root root 12288 Jun 17 19:19 firmware
> >> drwxr-xr-x 2 root root4096 Jun 17 19:21 gentoo
> >> drwxr-xr-x 3 root root4096 Dec 9 2010 grub
> >> -rw-r--r-- 1 root root 0 Nov 17 2010 .keep
> >
> > [ ]
> >
> >> -rw-r--r-- 1 root root 773 Jun 17 02:51 tclooConfig.sh
> >> lrwxrwxrwx 1 root root 17 Jun 17 03:22 terminfo ->
> >> ../share/terminfo
> >> drwxr-xr-x 2 root root 4096 Jun 17 21:35 tmpfiles.d
> >> drwxr-xr-x 2 root root 4096 Apr 1 06:50 upower
> >> drwxr-xr-x 2 root root 4096 Jun 17 10:55 vdpau
> >> -rw-r--r-- 1 root root 266 Jun 17 03:26 xml2Conf.sh
> >> root@fireball / #
> >>
> >> As one can see, some of those could be important. I noticed grub,
> >> nvidia, dracut and others that could cause issues if they failed. Is it
> >> really safe to just rm them or did I miss something? Do I need to do
> >> something else not mentioned in the news item for this?
> >
> > At this stage, /lib32 should be a symlink. I think that step 12 means
> > just the symlink should be removed, NOT all the stuff inside what it
> > points to.
> >
> > So I think what you should do is:
> > $ rm /lib32
> >
> > , but definitely NOT a recursive rm on that symlink.
> >
> > I had to remove one of these two symlinks by hand (I can't remember
> > which one), and I've not had any trouble since. ("Since" meaning Saturday
> > evening.)
> >
> >> The rest of the todo list worked fine. I'm just concerned about removing
> >> these files when they are owned by packages.
> >> Thoughts??
> >
> > As above, DON'T remove the files, just the symlink.
> >
> >> Dale
> >>
> >> :-) :-)
>
> A. I didn't catch that it is only removing the symlinks. Now that
> makes me feel a little better about doing that. Since I have it set to
> keep a binary of all my packages anyway, I just may run emerge -K world
> and let it do its thing afterwards just to be sure. I guess that would
> work.
>
> Thanks for that info. I read it but it didn't hit me as to what it meant.
>
> Dale
>
> :-) :-)
What Alan said. List the two directories /lib32 and /usr/lib32 *without* a
"/" at the end. They should indicate they are a symlink.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Profile switch to 17.1.
On Tuesday, 18 June 2019 16:12:32 BST Dale wrote: > Howdy, > > I been working on the profile switch. I followed the directions in the > news item up until the rm part in #12. I did a equery b for a few files > in the two directories and it has files that equery shows belonging to > packages. They are not orphans since they are owned. Here is a list of > the files: > > root@fireball / # ls -al /lib32/ > total 3956 [snip ... x 3956 ] > root@fireball / # ls -al /usr/lib32/ > total 257136 [snip ... x 257136 ] > As one can see, some of those could be important. I noticed grub, > nvidia, dracut and others that could cause issues if they failed. Is it > really safe to just rm them or did I miss something? Do I need to do > something else not mentioned in the news item for this? Hmm ... having run 'unsymlink-lib --analyze/migrate/finish', switched profile to 17.1 and then rebuilt toolchain and 'emerge -1v /lib32 /usr/lib32', I did not have to manually remove those directories on 4 different systems so far (I think). That said I don't use an initramfs, but even if I did these are not boot time dependencies. If you feel shakey about it you can rebuild dracut before you need to use it again. You haven't missed a step by any chance? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] UEFI kernel installation?
On Monday, 17 June 2019 04:37:13 BST Grant Taylor wrote: > My opinion is that the 2 x RAM no longer applies because systems don't > utilize swap space. As such it's a waste of disk space to dedicate 2 x > RAM to swap. I've also noticed usage of swap has become much more efficient over the years, even when running processes which by their nature chew up all the available RAM, like an emerge with a high -j number. However, if one is using the swap partition to hibernate a system, then it should be at least the amount of RAM, yes? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] UEFI kernel installation?
On Saturday, 15 June 2019 14:04:16 BST Peter Humphrey wrote: > Hello list, > > The main system on this box is ~amd64 plasma, but I also have a small rescue > system which is amd64, no desktop. I use bootctl from systemd-boot to > manage the UEFI images. > > My question is: how much of the bootctl-installed image is essential for > booting? In other words, if I install the ~amd64 kernel (5.1.9), what effect > will that have on booting the rescue system; and if I install the amd64 > kernel (4.19.44), what effect will it have on booting the plasma system? > > In practice, I install the ~amd64 kernel and hope it doesn't affect the > rescue system too much; and it seems not to. Could I do better? Assuming I've understood correctly your question, since this is the same box and both kernels will be booting the same hardware, with similar modules, it shouldn't make any odds what OS installation you decide to boot into with any of two given kernels. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Not enough RAM for dev-qt/qtwebengine build
On Thursday, 13 June 2019 12:59:41 BST Adam Carter wrote: > > You can use more swap (files) before buying more RAM. > > I have been doing this too. It only get used during the big builds. > > To create a 32G swap file and enable it (OP can do this now as the build > runs, to keep OOM away) > # fallocate -l 32G && chmod 600 && mkswap > && swapon > > use 'watch free -m' to see if its being used. Then after the build is over, > delete it/add it to fstab/whatever More swap will help, but the basic problem here is the HUGE number of jobs specified. If each job eats say up to 2G when it gets going, then -j32 will require >64G RAM to keep running without thrashing the swap device, or running OOM. The reasonable thing for big builds is to add an environment variable as already explained, which restricts the number of jobs. Or for an one off run something like: MAKEOPTS="-j8 -l7.8" emerge -1aNDv On a i7 (4 cores x 2 threads) I use -j2 for huge compiles like chromium, because the PC only has 8G RAM. Smaller packages will emerge with -j12 without breaking into a sweat, although the optimum setting for this PC is "- j8 -l7.8". -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s
On Sunday, 9 June 2019 21:16:52 BST Grant Taylor wrote: > On 6/9/19 1:38 PM, Dale wrote: > > While I see that point and quite often it is a good idea, it could > > also be that a fix is in the newer tree. It could even be that you > > caught the tree in the middle of some sort of change and you missed > > part of it. > > > > If it were me, I'd try everything you can but if you can't find a > > solution, I'd sync and see what happens. I've had a fresh sync fix > > issues on a few occasions. It's somewhat rare but can happen. > > > > Just a thought. > > Your logic makes sense. > > I actually did end up reluctantly doing that at one point when I > couldn't access my ZFS pool, which contained /usr/portage. So, an > emerge --sync was run to populate /usr/portage while attempting to fix ZFS. > > I abandoned that line of work after a couple of hours and ended up > restoring my ZFS module backup from a few days prior. That got me > access to my ZFS pool again. > > So, I'm disinclined to think that it's a bum copy of portage. > > But, it is still a valid question to to ask. I think Dale meant a later tree will contain updated packages, which may fix previous breakages and incompatibilities. Hypothetically, a later VBox version requires some later version libs, which your current tree is missing. A re-sync will bring these in and your next emerge will fix the problems you were having. Admittedly, I have experienced this more than once with various packages. Nevertheless, your module related problems are more obscure/involved. A dev should have a better idea as to what might be causing this. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s
On Sunday, 9 June 2019 18:55:34 BST Grant Taylor wrote: > On 6/9/19 2:56 AM, Mick wrote: > > This sounds as if it may be related to a move from an older gcc to > > a newer version. > > I'm not sure it's related to a gcc version: > > # gcc-config -l > [1] x86_64-pc-linux-gnu-6.4.0 * > [2] x86_64-pc-linux-gnu-8.3.0 > > I think that gcc 8.3 might have been selected and I reverted to 6.4 > thinking that it might have been part of the problem. I have since done > an emerge -DuNeq @world with gcc 6.4 and the problem persists. > > > Checking my understanding: > > > > 1. The old modules, compiled with the old gcc and toolchain worked > > fine. > > Correct. > > > 2. The new modules, compiled with the new gcc but old libtool, > > binutils and glibc worked (usually you update these or @system, > > before you update the whole world). > > Correct. > > > 3. The new modules, compiled with the new gcc and toolchain rebuilt > > the second time do not work (this would use libtools, binutils, glibc, > > now compiled with the new gcc). > > Correct. > > > 4. All of the above happens with the old kernel, which was not rebuilt > > with the new toolchain. > > Correct. > > > 5. New kernel(s) compiled thereafter will not boot. > > Correct. > > > You have not mentioned if you upgraded gcc. > > I think that the first emerge -DuNeq @world did pull in a new gcc. But > I have since selected gcc 6.4 as part of diagnostics. (See above.) > > > The error you get about modules failing to load sounds like a > > path/symlink error, or a linux headers error, or a change of arch. > > I don't think it's a symlink error. (I've configured things to not > automatically update the sym-link.) > > # ls -la /usr/src/linux > lrwxrwxrwx 1 root root 22 Sep 8 2018 /usr/src/linux -> > linux-4.9.76-gentoo-r1/ > # uname -a > Linux REDACTED 4.9.76-gentoo-r1 #1 SMP Thu Nov 15 22:23:44 MST 2018 > x86_64 Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz GenuineIntel GNU/Linux > > As you can see, the machine has enough CPU that I can let it do the > following to make sure that things are consistent. (At least I think > that's what's happening.) > > emerge -DuNeq @world && emerge --depclean && revdep-rebuild > > That's my SOP. If that fails I usually try a --resume to see if the > problem repeats, and if it's at the same place. If that fails for some > reason, I'll fall back to a @system. Usually the failure is caused by > something that I've done, disk space, ZFS version issues, etc. > > > Since both vbox and zfs modules fail to boot I would not think this > > is a zfs isolated problem. > > Agreed. > > > Have you tried forcing the loading of these modules? > > > > modprobe --force --verbose > > No, not yet. I've never had any success forcing the kernel to load modules. > > What errors do you get with the new non-booting kernels? > > # modprobe --force --verbose vboxdrv > insmod /lib/modules/4.9.76-gentoo-r1/misc/vboxdrv.ko > modprobe: ERROR: could not insert 'vboxdrv': Exec format error > > dmesg reports the following for each attempt to (force) load the module. > > module: vboxdrv: Unknown rela relocation: 4 > > Mick I get the impression that you've got the correct understanding of > my current situation. I'm interested learn what you think should be done. If you haven't done it already, perhaps have a look in the path /lib/modules/ 4.9.76-gentoo-r1/misc/ to check the VBox modules are present and owned by root:root with 0644 access rights. Since you have not cross compiled any of these modules, altered your make.conf CFLAGS, or messed with the linux-headers, I can't see what else might have gone sideways. :-/ I'm not saying this is what you should do, but unless someone more learned than myself chimes in with better advice, this is how I would go about it: 1. Make a back up of your system in case you can't get back into it and need to restore from a back up. 2. Sync portage and upgrade gcc to the latest stable version. Switch to it. 3. Rebuild libtools, binutils, glibc. 4. Rebuild @system. 5. Copy your present kernel config to the latest stable kernel which also deals with the MDS Intel vulnerability; change symlink; 'make oldconfig' on the latest kernel; build it and install it. Don't forget to emerge @module- rebuild. If the newly built kernel won't boot, troubleshoot the error messages at boot and perhaps keyword and try a later kernel. The reason I would go about it this way is because ultimately you will need to both upgrade gcc and move on to a later version kernel. I appreciate right now may not be the right time for you, but at some point, when convenient, you'll have to make time to deal with these errors and work through them to a solution. PS. May also be worth posting in the forums and asking in IRC as there will be more users who may have come across you problem. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Keeping 17-year-old Kylix software alive
On Sunday, 9 June 2019 09:21:17 BST Mick wrote:
> Hi Matt,
>
> On Sunday, 9 June 2019 08:49:21 BST Matthias Hanft wrote:
> > Hi,
> >
> > many years ago, I created some libSomething.so with Kylix 3 (1)
> > which still worked with current (32bit) Gentoo systems (Kernel
> > 4.14.83).
> >
> > Using "revdep-rebuild.sh" (the *old* script!), for some time,
> > I already got messages like
> >
> > broken /usr/local/lib/libxercesxmldom.so.1
> > /usr/local/lib/libxercesxmldom.so.1 (symbol __pthread_atfork version
> > GLIBC_2.0 not defined in file libpthread.so.0 with link time reference
> > symbol __pthread_initialize version GLIBC_2.0 not defined in file
> > libpthread.so.0 with link time reference)
> >
> > but everything worked fine anyway ("libxercesxmldom" is part of
> > Borland's standard runtime libraries).
>
> Did you try the new revdep-rebuild in case it works (better)?
>
> > However, after upgrading glibc from 2.27 to 2.28 (or newer), this
> > is not true any more: Compiling and running a C program using the
> > old Kylix libSomething.so libraries causes Segmentation fault, and
> > Apache using a PHP extension which calls those libraries won't start
> > at all any more.
> >
> > For recompiling the Kylix libSomething.so libraries, I'm keeping
> > alive a Suse 8.1 Linux (2) in VirtualBox (Kernel 2.4.19).
> >
> > Do you see any chance to keep those Kylix libraries alive and
> > running? If it would help, I'd try to install the old Kylix on
> > a current Gentoo system and try to recompile there (although
> > I guess Kylix won't run on a current Kernel any more - if it
> > can be installed at all).
> >
> > Switching to another (Pascal-/Delphi-/Lazarus-/etc.) Compiler
> > is not an option because the .so libraries are in fact "packages"
> > (BPL, a special Borland library version).
> >
> > Is there any possibility for some "binary interface/gateway" to
> > use those libraries any more, or do I have to reprogram the
> > whole functionality with PHP?
> >
> > -Matt
> >
> > (1) https://en.wikipedia.org/wiki/Borland_Kylix
> > (2) https://en.wikipedia.org/wiki/SUSE_Linux#SUSE_distributions
>
> I am not familiar with the particular software and wouldn't know how to keep
> it alive on a present day Gentoo system - other than building Gentoo using
> an old snapshot and installation media, perhaps in a VM and using
> additional packages of the same era from the attic in a local overlay.
>
> Someone else may be able to offer useful advice, but I would think this is
> more of a question suitable for the gentoo-dev mailing list[1] and IRC
> channel[2]. Have you tried asking there?
>
> [1] https://www.gentoo.org/get-involved/mailing-lists
> [2] https://www.gentoo.org/get-involved/irc-channels/all-channels.html
Hmm ... reading about borland kylix in the link you provided and this article
I'm wondering if the two are related:
https://www.gentoo.org/support/news-items/2017-04-10-split-and-slotted-wine.html
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s
On Saturday, 8 June 2019 20:45:45 BST Grant Taylor wrote: > On 6/8/19 12:26 PM, Mick wrote: > > Were these contents not there, or is it that the new version of > > modules do not work? > > The old (original for the sake of this thread) versions (restored from > backups) work just fine. > > The version produced during the first emerge -DuNe @world worked. At > least I'm not aware of any problems. > > The version produced during the second emerge -DuNe @world did not work. This sounds as if it may be related to a move from an older gcc to a newer version. Checking my understanding: 1. The old modules, compiled with the old gcc and toolchain worked fine. 2. The new modules, compiled with the new gcc but old libtool, binutils and glibc worked (usually you update these or @system, before you update the whole world). 3. The new modules, compiled with the new gcc and toolchain rebuilt the second time do not work (this would use libtools, binutils, glibc, now compiled with the new gcc). 4. All of the above happens with the old kernel, which was not rebuilt with the new toolchain. 5. New kernel(s) compiled thereafter will not boot. You have not mentioned if you upgraded gcc. The error you get about modules failing to load sounds like a path/symlink error, or a linux headers error, or a change of arch. Since both vbox and zfs modules fail to boot I would not think this is a zfs isolated problem. Have you tried forcing the loading of these modules? modprobe --force --verbose What errors do you get with the new non-booting kernels? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Keeping 17-year-old Kylix software alive
Hi Matt,
On Sunday, 9 June 2019 08:49:21 BST Matthias Hanft wrote:
> Hi,
>
> many years ago, I created some libSomething.so with Kylix 3 (1)
> which still worked with current (32bit) Gentoo systems (Kernel
> 4.14.83).
>
> Using "revdep-rebuild.sh" (the *old* script!), for some time,
> I already got messages like
>
> broken /usr/local/lib/libxercesxmldom.so.1
> /usr/local/lib/libxercesxmldom.so.1 (symbol __pthread_atfork version
> GLIBC_2.0 not defined in file libpthread.so.0 with link time reference
> symbol __pthread_initialize version GLIBC_2.0 not defined in file
> libpthread.so.0 with link time reference)
>
> but everything worked fine anyway ("libxercesxmldom" is part of
> Borland's standard runtime libraries).
Did you try the new revdep-rebuild in case it works (better)?
> However, after upgrading glibc from 2.27 to 2.28 (or newer), this
> is not true any more: Compiling and running a C program using the
> old Kylix libSomething.so libraries causes Segmentation fault, and
> Apache using a PHP extension which calls those libraries won't start
> at all any more.
>
> For recompiling the Kylix libSomething.so libraries, I'm keeping
> alive a Suse 8.1 Linux (2) in VirtualBox (Kernel 2.4.19).
>
> Do you see any chance to keep those Kylix libraries alive and
> running? If it would help, I'd try to install the old Kylix on
> a current Gentoo system and try to recompile there (although
> I guess Kylix won't run on a current Kernel any more - if it
> can be installed at all).
>
> Switching to another (Pascal-/Delphi-/Lazarus-/etc.) Compiler
> is not an option because the .so libraries are in fact "packages"
> (BPL, a special Borland library version).
>
> Is there any possibility for some "binary interface/gateway" to
> use those libraries any more, or do I have to reprogram the
> whole functionality with PHP?
>
> -Matt
>
> (1) https://en.wikipedia.org/wiki/Borland_Kylix
> (2) https://en.wikipedia.org/wiki/SUSE_Linux#SUSE_distributions
I am not familiar with the particular software and wouldn't know how to keep
it alive on a present day Gentoo system - other than building Gentoo using an
old snapshot and installation media, perhaps in a VM and using additional
packages of the same era from the attic in a local overlay.
Someone else may be able to offer useful advice, but I would think this is
more of a question suitable for the gentoo-dev mailing list[1] and IRC
channel[2]. Have you tried asking there?
[1] https://www.gentoo.org/get-involved/mailing-lists
[2] https://www.gentoo.org/get-involved/irc-channels/all-channels.html
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s
On Saturday, 8 June 2019 19:01:30 BST Grant Taylor wrote: > I'm having problems with newly compiled modules (zfs (et al.) and vbox > (et al.)) and kernel after doing two "emerge -DuNe @world"s. > > Everything worked fine after rebooting after the first "emerge -DuNe > @world". So, I did another "emerge -DuNe @world". (This harks back to > the old stage 1 -> stage 2 -> stage 3 methodology that I cut my teeth > on. Create the new tool, use said tool to recreate the tool.) > > After the reboot after this second "emerge -DuNe @world" is when my ZFS > pool became inaccessible. > > Aside: I migrated from ZFS 0.7.999 to 0.8 as part of the first emerge. > This worked fine. > > I have since found out that I can't load vbox* modules, nor can I boot a > kernel that I can successfully build. > > The modules fail with the following error: > > modprobe: ERROR: could not insert '': Exec format error. > > Dmesg reports the following associated error: > > [ ] module: : Unknown rela > relocation: 4 > > My searches online have made me think that this /might/ be a problem > with newer binutils. But I'm not sure. > > So, I figured that I'd ask for some help / input before I do something > drastic that I might regret, like making things worse, or painting > myself into a corner that I can't back out of. > > Aside: I have regained access to my ZFS pool by restoring the ZFS > contents of the /lib/modules//extra directory. Were these contents not there, or is it that the new version of modules do not work? If the former, then could this be related to the migration over to profile 17.1? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] What is the best way to clean up the world file?
On Thursday, 6 June 2019 09:56:24 BST Neil Bothwick wrote: > On Thu, 06 Jun 2019 09:36:03 +0100, Mick wrote: > > I think, but may be wrong, regenworld will pick up anything and > > everything in emerge.log and add it to your world file. Definitely > > create a back up of / var/lib/portage/world if you do not have one > > already, because you can diff it later on to see how much weight it has > > put on. > > I think it only adds packages that are not a dependency of something > else, which may result in a world file that is too lean and > over-enthusiastic depcleaning later on. > > Another method, a time consuming one, is to remove the world file and run > emerge -p --depclean. Then emerge -n anything in the output that you use > directly. Rinse and repeat. Eventually the depclean output will only > contain unneeded packages, at which point you can run it in anger. I haven't used it for a long time, so its behaviour may have changed/improved. The last time I used it I got a *very* long list of "package XXX was added to your world file" kind of message and stopped using it ever since. I may have run it the wrong way - not sure - but thought of warning Grant just in case. With a back up in hand, which I foolishly did not have handy as I was rushing at the time, it is easy to revert any unwelcome changes. As Dale mentioned my original problem (a fat/polluted world file) would have been easily resolved if I used 'emerge -1' each time I manually tried to sort out some portage output. I think I've learned this lesson well. ;-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] What is the best way to clean up the world file?
On Thursday, 6 June 2019 05:56:53 BST Dale wrote: > Grant Taylor wrote: > > On 6/5/19 9:18 PM, Dale wrote: > >> I would start by removing anything that has libs in it. Generally, > >> those should be pulled in as deps. After that, I'd go through the > >> list and remove anything that you don't directly use. > > > > ACK > > > > Can I just edit /var/lib/portage/world? Or do I need to do something > > else? Yes, manually edit this file, but FIRST MAKE A BACK UP. :-) > It's a plain text file and I've edited it in the past with no problems. > I've done that cleanup before and it can take some time to accomplish > depending on how bad it is. I went through this when I first started > using Gentoo and didn't know any better. I'd do small chunks and keep a > versioned back up file just in case. > > I've also used the script once. It does fairly well. It may miss a > couple here and there and may have a few false positives as well. Still > it can do some heavy lifting for you. I'd copy the world file to a safe > place and try the script. I'd try it once with the old world file in > place and once without a world file at all. Then see which one works > best. If that fails, do it manually. > > Good luck. I hope one or the other works. > > Dale > > :-) :-) I think, but may be wrong, regenworld will pick up anything and everything in emerge.log and add it to your world file. Definitely create a back up of / var/lib/portage/world if you do not have one already, because you can diff it later on to see how much weight it has put on. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: Aw: Re: Re: [gentoo-user] Updating portage, continued
On Tuesday, 4 June 2019 21:21:24 BST n952...@web.de wrote: > Or, perhaps, that's where slots come in? > > If I try to install package A, which doesn't want whatever's in > >> > > +>=net-analyzer/rrdtool-1.6.0-r1 perl graph > > then, it'll use a new slot? Not really. rrdtool-1.x will be in the same slot, say SLOT="0" for whichever x value the developers release. You will not be able to install rrdtool-1.x and rrdtool-1.xx, without using a prefix or some similar trick. If the developers also released a different slot, e.g. rrdtool-2.x, then this would become SLOT="1" and so on, with its own different versions of build and run time dependencies. You could conceivably have both rrdtool-1.x and rrdtool-2.x installed on the same box, with different USE flags is you so wished or the devs or make.profile stipulated - as long as there was no major blockage in their respective versions of dependencies. Have a look here for a better explanation of SLOTS: https://devmanual.gentoo.org/general-concepts/slotting/ > I see that I have ebuilds for rrdtool-1.6.0 and rrdtool-1.7.0,1.7.1. and > 1.7.2. The one that runs when I enter rrdtool is 1.6.0. They all belong to the same slot: $ grep SLOT /usr/portage/net-analyzer/rrdtool/rrdtool-1.*.ebuild /usr/portage/net-analyzer/rrdtool/rrdtool-1.6.0-r1.ebuild:SLOT="0/8.0.0" /usr/portage/net-analyzer/rrdtool/rrdtool-1.7.0.ebuild:SLOT="0/8.0.0" /usr/portage/net-analyzer/rrdtool/rrdtool-1.7.1.ebuild:SLOT="0/8.0.0" /usr/portage/net-analyzer/rrdtool/rrdtool-1.7.2.ebuild:SLOT="0/8.0.0" > Was that caused by etc/portage/package.use/._cfg0015_zz-autounmask even > though I hadn't accepted it yet? I understand correctly, right, that > commands in ._cfg* files pend until accepted? Yes. Configuration directives in ._cfg* files remain there until accepted or until rejected (zapped) by the user. > Basically, this pending change is because monitorix doesn't want to work > with the newest version of rrdtool? I think it is a matter of USE flags monitorix requires of rrdtool. Looking in the latest stable monitorix ebuild we see: RDEPEND="dev-perl/Config-General dev-perl/DBI dev-perl/HTTP-Server-Simple dev-perl/IO-Socket-SSL dev-perl/libwww-perl dev-perl/MIME-Lite dev-perl/XML-Simple net-analyzer/rrdtool[graph,perl] <== This one dev-perl/CGI" These USE flag requirements for rrdtool are present in all versions of monitorix presently in the tree, see below, but things may have been different in previous monitorix versions not currently in the tree (I'm not familiar with monitorix and its historic dependencies): $ grep rrdtool /usr/portage/www-misc/monitorix/monitorix-*.ebuild /usr/portage/www-misc/monitorix/monitorix-3.10.0-r1.ebuild: net-analyzer/ rrdtool[graph,perl] /usr/portage/www-misc/monitorix/monitorix-3.10.1.ebuild:net-analyzer/ rrdtool[graph,perl] /usr/portage/www-misc/monitorix/monitorix-3.11.0.ebuild:net-analyzer/ rrdtool[graph,perl] /usr/portage/www-misc/monitorix/monitorix-3.9.0.ebuild: net-analyzer/ rrdtool[graph,perl] > > Gesendet: Dienstag, 04. Juni 2019 um 21:56 Uhr > > Von: n952...@web.de > > An: gentoo-user@lists.gentoo.org > > Betreff: Aw: Re: Re: [gentoo-user] Updating portage, continued > > > > Okay, I think I got it. I saw that rrdtool was installed, so assumed > > everything was okay. But, what I didn't realize is that - back then - I > > guess I tried to install montorix and didn't notice, in the jungle of > > messages, that the emerge was not successful. > > > > Apparently, rddtool got installed with harmless, default values, which, > > however, are not sufficient for monitorix. So, now I can accept the > > changes, and re-emerge rddtool - or probably, emerging monitorix will > > arrange for that. > > > > Then, if someday, I get a nasty message that there's a keyword conflict, > > I'll have to sacrifice either the new package or monitorix ... > > > > In the meantime, I'll install this package and that, and some of them may > > be dependent on rrdtool. In that case, unless they explicitly disallow > > that unmasked version, they'll use the same, possibly experimental, > > version. When the day comes that I have to back the unmasked version of > > rrdtool out, then all other dependent packages will get the standard, > > default version again. > > > > I'm catching on, bit by bit ;-) > > > > > Gesendet: Dienstag, 04. Juni 2019 um 00:50 Uhr > > > Von: "Mick" > > > An: gentoo-user@lists.gentoo.org > > > Betreff: Re: Aw: Re: [gentoo-user] Upd
Re: [gentoo-user] Re: sysrescuecd gone rogue
On Tuesday, 4 June 2019 16:01:13 BST Grant Edwards wrote: > On 2019-06-04, Mick wrote: > > I just downloaded my preferred medium of choice for installing Gentoo and > > discovered sysrescuecd now runs Linux Arch instead of Gentoo and to make > > things worse it is running systemd instead of openrc. :-( > > That's sad news indeed. Thank you all for your responses. I found the thread in the Gentoo forums and am glad 'sabayonino' picked up the mantle to develop an up to date gentoo based LiveRecoverySystem (LRS) from sysrescuecd. https://forums.gentoo.org/viewtopic-t-1092708-postdays-0-postorder-asc-start-100.html I'm particularly glad because I had recently deleted my own old homegrown sysrescuecd, in which I had added various firmware files needed for my PCs & their peripherals. I was fearing I might have to repeat all this customisation just to arrive at the same old sysrescuecd, rather than an up to date version. Yes, I've also used other CD/DVDs inc. Knoppix to install and repair Gentoo, but for years now I had settled to sysrescuecd. Looking forward to using LRS from now on. :-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] sysrescuecd gone rogue
I just downloaded my preferred medium of choice for installing Gentoo and discovered sysrescuecd now runs Linux Arch instead of Gentoo and to make things worse it is running systemd instead of openrc. :-( A quick look in the forums did not reveal the reasons for this strategic change. Regardless, have you used the Arch based sysrescuecd to install Gentoo and are there are any gotchas I should be aware of? Would I be better off to use a Gentoo Live ISO to install with? I don't think I have used one of these for more than 10 years ... or more! O_O -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: Aw: Re: [gentoo-user] Updating portage, continued
On Monday, 3 June 2019 23:14:01 BST n952...@web.de wrote: > Fundamentally, autounmask seems like something I don't want to do, at all. > What happens if I just remove zz-autounmask? What do I have to emerge to > find out? @world with --newuse and --pretend. > I currently have: > > $ cat /etc/portage/package.use/zz-autounmask > > >=dev-lang/python-2.7.14-r1:2.7 sqlite > >=sys-libs/zlib-1.2.11-r1 minizip > > And, I thought unmasking was related to keywords - allowing or not allowing > experimental versions ... why is that in /etc/portage/package.use? autounmask will deal with USE flags as well as keywording testing versions of packages. Portage will ask to autounmask USE flags who may have been affected by a change in an ebuild, or by a change in the default USE flags stipulated by make.profile. However, it is up to you as the maintainer of the system to study both USE and keyword changes and decide what their impact might be on your system. Then accept or reject these changes before you proceed with emerge. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: Aw: Re: [gentoo-user] Updating portage, continued
On Monday, 3 June 2019 23:09:40 BST n952...@web.de wrote: > I'm sorry, I'm not getting this yet. What if I just don't update these > configuration files? > > dispatch-conf tells me, for /etc/portage/package.accept_keywords: > > --- /etc/portage/package.use/zz-autounmask 2018-03-12 > 21:56:49.172491972 +0100 +++ > /etc/portage/package.use/._cfg0015_zz-autounmask2018-07-28 > 11:08:23.725995803 +0200 @@ -1,2 +1,5 @@ > > >=dev-lang/python-2.7.14-r1:2.7 sqlite > >=sys-libs/zlib-1.2.11-r1 minizip > > +# required by www-misc/monitorix-3.9.0::gentoo > +# required by monitorix (argument) > +>=net-analyzer/rrdtool-1.6.0-r1 perl graph If you accept the above portage will emerge net-analyzer/rrdtool-1.6.0-r1 with USE flags 'perl' and 'graph' enabled. This change seems to be required by www-misc/monitorix for some functionality of rrdtool (e.g. graphing) it needs. > I can zap it or merge it or skip it. It looks like the emerge was > successful, so, why should I do anything? > > $ rrdtool > RRDtool 1.6.01.6.0 Copyright by Tobias Oetiker Successful against what criteria? If monitorix needs/wants it to be compiled so in order to perform graphing, it may not work until you've enabled these USE flags and re-emerged (more successfully this time) rrdtool. > I would have thought that emerge would pend until I'd agreed to the > override. But, it apparently went ahead and installed. So what's required > still? What will be different once I make the merge to zz-autounmask? If the changes in USE flags were hardcoded in the ebuild, because without them an insurmountable conflict would arise, I expect portage would refuse to emerge and complain of a hard block [B]. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] problem with emerge @preserved-rebuild
On Friday, 31 May 2019 20:08:45 BST allan gottlieb wrote:
> A few weeks ago I did an eix-sync but (with final exams coming) I did
> not do an emerge --update @world.
>
> The semester is over so I tried the emerge --update @world (still based
> on the old eix-sync). Specifically
>
> emerge --update --newuse --with-bdeps=n --exclude
> sys-kernel/linux-firmware --exclude systemd --exclude grub --keep-going
> --deep @world
>
> It emerged ~55 packages and when finished printed
>
> !!! existing preserved libs:
> >>> package: app-misc/tracker-2.1.8
>
> * - /usr/lib64/libtracker-sparql-1.0.so.0
> * - /usr/lib64/libtracker-sparql-1.0.so.0.1204.0
> * used by /usr/lib64/grilo-0.2/libgrltracker.so
> (media-plugins/grilo-plugins-0.2.17) * used by
> /usr/lib64/nautilus/extensions-3.0/libnautilus-tracker-tags.so
> (gnome-extra/nautilus-tracker-tags-1.12.4) * -
> /usr/lib64/tracker-1.0/libtracker-common.so.0
> * - /usr/lib64/tracker-1.0/libtracker-common.so.0.0.0
> * - /usr/lib64/tracker-1.0/libtracker-data.so.0
> * - /usr/lib64/tracker-1.0/libtracker-data.so.0.0.0
> Use emerge @preserved-rebuild to rebuild packages using these libraries
>
> However emerge @preserved-rebuild fails, with output
>
> emerge: there are no ebuilds to satisfy
> "media-plugins/grilo-plugins:0.2". (dependency required by
> "@preserved-rebuild" [argument])
>
> eix shows
>
> [?] media-plugins/grilo-plugins
> Available versions: (0.3) 0.3.7 ~0.3.8
>{chromaprint daap dvd examples flickr freebox
> gnome-online-accounts lua subtitles test thetvdb tracker upnp-av vimeo
> +youtube} Installed versions: 0.2.17(0.2)(02:51:05 AM 03/25/2016)(dvd
> gnome-online-accounts tracker upnp-av vimeo youtube -daap -flickr -freebox
> -lua -subtitles -thetvdb) 0.3.7(0.3)(10:24:17 PM 04/18/2019)(dvd
> gnome-online-accounts tracker upnp-av youtube -chromaprint -daap -examples
> -flickr -freebox -lua -subtitles -test -thetvdb -vimeo) Homepage:
> https://wiki.gnome.org/Projects/Grilo Description: A collection of
> plugins for the Grilo framework
>
> So one of my currently installed grilo-plugins is not in the tree.
>
> What should I do? The system currently is running fine.
>
> thanks in advance,
> allan
I would resync and update world. Then emerge --depclean, followed by
@preserved-rebuild. If the problem persists you can remove the obsolete
version and see if @preserved-rebuild brings in the new version which is in
the tree - it will if it is a needed dependency.
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: Aw: Re: [gentoo-user] upgrading (profiles, too)
On Friday, 31 May 2019 15:20:01 BST Rich Freeman wrote: > On Thu, May 30, 2019 at 6:02 PM Dale wrote: > > Given that is going to involve quite a bit of changes, and it appears > > the OP has a outdated system, going in steps may be a good idea. At > > least that way if something breaks, it may be easier to fix since the > > steps are smaller. > > ++ > > I would never attempt a profile change unless I had a system running > on a repo that was completely up to date, with no pending updates. > That is, if you run emerge --sync and emerge -uD world nothing happens > (well, aside from the random one package that just happened to > change). [snip ...] If I were to install a new system presently and wanted to go straight to a 17.1 profile, is there some particular stage tarball I could/should be downloading to by-pass all this lib (un)linkage goodness? In the same vane I wonder if the OP's problems would be resolved by a reinstall of Gentoo, while retaining the same world file and perhaps /etc? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: Aw: Re: [gentoo-user] upgrading (profiles, too)
verall security fingerprint. The switch from non-PIE to PIE binaries, however, requires some steps by users, as detailed below. 3) Up to now, hardened profiles were separate from the default profile tree. Now they are moving into the 17.0 profile as a feature there, similar to "no-multilib" and "systemd". Please migrate away from the 13.0 profiles within the six weeks after GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles will be deprecated then and removed in half a year. If you are not already running a hardened setup with PIE enabled, then switching the profile involves the following steps: If not already done, * Use gcc-config to select gcc-6.4.0 or later as system compiler * Re-source /etc/profile: . /etc/profile * Re-emerge libtool emerge -1 sys-devel/libtool Then, * Select the new profile with eselect * Re-emerge, in this sequence, gcc, binutils, and glibc emerge -1 sys-devel/gcc:6.4.0 emerge -1 sys-devel/binutils emerge -1 sys-libs/glibc * Rebuild your entire system emerge -e @world Switching the profile from 13.0 to 17.0 modifies the settings of GCC 6 to generate PIE executables by default; thus, you need to do the rebuilds even if you have already used GCC 6 beforehand. If you do not follow these steps you may get spurious build failures when the linker tries unsuccessfully to combine non-PIE and PIE code. = HTH. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
