Re: [gentoo-user] nvidia-drivers 325.15 removal
131214 »Q« wrote:
It looks to me as if the removal of nvidia-drivers-325.15 was a mistake
I run mostly stable amd64.
I *think* 325.15 was the latest stable
[I] x11-drivers/nvidia-drivers
Available versions: 96.43.23^msd 173.14.39^msd 304.116^msd ~304.117^msd
319.76^msd 331.20^msd {+X acpi custom-cflags gtk multilib pax_kernel (+)tools
KERNEL=FreeBSD linux}
Installed versions: 331.20^msd([2013-11-23 15:26:19])(X multilib -acpi
-pax_kernel -tools KERNEL=linux -FreeBSD)
No problems here. Have you sync'ed recently ?
--
,,
SUPPORT ___//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] @preserved-rebuild gone in a loop
Not sure why, but for some reason running emerge @preserved-rebuild does not seem to fix some preserved libs links: !!! existing preserved libs: package: x11-libs/pango-1.34.1 * - /usr/lib/libpangox-1.0.so.0 * - /usr/lib/libpangox-1.0.so.0.3000.1 This is all caused by some hack I have in my local portage for app- antivirus/avast4workstation-1.3.0-r2. No matter how many times I run @preserved-rebuild the libs in question keep coming up: == # emerge @preserved-rebuild Calculating dependencies... done! Verifying ebuild manifests Emerging (1 of 1) app-antivirus/avast4workstation-1.3.0-r2 from x-portage * avast4workstation-1.3.0.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] Unpacking source... Unpacking avast4workstation-1.3.0.tar.gz to /var/tmp/portage/app- antivirus/avast4workstation-1.3.0-r2/work Source unpacked in /var/tmp/portage/app-antivirus/avast4workstation-1.3.0- r2/work Compiling source in /var/tmp/portage/app- antivirus/avast4workstation-1.3.0-r2/work/avast4workstation-1.3.0 ... Source compiled. Test phase [not enabled]: app-antivirus/avast4workstation-1.3.0-r2 Install avast4workstation-1.3.0-r2 into /var/tmp/portage/app- antivirus/avast4workstation-1.3.0-r2/image/ category app-antivirus Completed installing avast4workstation-1.3.0-r2 into /var/tmp/portage/app- antivirus/avast4workstation-1.3.0-r2/image/ * QA Notice: This package installs one or more .desktop files that do not * pass validation. * * /usr/share/applications/avast.desktop: error: (will be fatal in the future): value avastgui.png for key Icon in group Desktop Entry is an icon name with an extension, but there should be no extension as described in the Icon Theme Specification if the value is not an absolute path * /usr/share/applications/avast.desktop: warning: value Application;Security;System; for key Categories in group Desktop Entry contains a deprecated value Application * strip: i686-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version opt/avast4workstation/lib/esmtp-plugins/sasl-cram-md5.so opt/avast4workstation/lib/esmtp-plugins/sasl-login.so opt/avast4workstation/lib/esmtp-plugins/sasl-plain.so ecompressdir: bzip2 -9 /opt/avast4workstation/share/man Installing (1 of 1) app-antivirus/avast4workstation-1.3.0-r2 * QA Notice: Symbolic link /opt/avast4workstation/share/doc/avast4workstation-1.3.0/helpfiles points to /opt/avast4workstation/lib/avast4workstation/share/avast/help which does not exist. * After the update on 3/29/2010, AVAST isn't able to initialise. * See following link for more details and solution: * http://forum.avast.com/index.php?topic=57812.0 * Messages for package app-antivirus/avast4workstation-1.3.0-r2: * After the update on 3/29/2010, AVAST isn't able to initialise. * See following link for more details and solution: * http://forum.avast.com/index.php?topic=57812.0 Auto-cleaning packages... No outdated packages were found on your system. * GNU info directory index is up-to-date. !!! existing preserved libs: package: x11-libs/pango-1.34.1 * - /usr/lib/libpangox-1.0.so.0 * - /usr/lib/libpangox-1.0.so.0.3000.1 * used by /opt/avast4workstation/bin/avastgui (app- antivirus/avast4workstation-1.3.0-r2) Use emerge @preserved-rebuild to rebuild packages using these libraries == This is all the libpango on this box: == # ls -la /usr/lib/libpango* lrwxrwxrwx 1 root root 24 Dec 14 12:54 /usr/lib/libpango-1.0.so - libpango-1.0.so.0.3400.1 lrwxrwxrwx 1 root root 24 Dec 14 12:54 /usr/lib/libpango-1.0.so.0 - libpango-1.0.so.0.3400.1 -rwxr-xr-x 1 root root 300988 Dec 14 12:54 /usr/lib/libpango-1.0.so.0.3400.1 lrwxrwxrwx 1 root root 29 Dec 14 12:54 /usr/lib/libpangocairo-1.0.so - libpangocairo-1.0.so.0.3400.1 lrwxrwxrwx 1 root root 29 Dec 14 12:54 /usr/lib/libpangocairo-1.0.so.0 - libpangocairo-1.0.so.0.3400.1 -rwxr-xr-x 1 root root 46948 Dec 14 12:54 /usr/lib/libpangocairo-1.0.so.0.3400.1 lrwxrwxrwx 1 root root 27 Dec 14 12:54 /usr/lib/libpangoft2-1.0.so - libpangoft2-1.0.so.0.3400.1 lrwxrwxrwx 1 root root 27 Dec 14 12:54 /usr/lib/libpangoft2-1.0.so.0 - libpangoft2-1.0.so.0.3400.1 -rwxr-xr-x 1 root root 79944 Dec 14 12:54 /usr/lib/libpangoft2-1.0.so.0.3400.1 lrwxrwxrwx 1 root root 24 Dec 14 14:54 /usr/lib/libpangomm-1.4.so - libpangomm-1.4.so.1.0.30 lrwxrwxrwx 1 root root 24 Dec 14 14:54 /usr/lib/libpangomm-1.4.so.1 - libpangomm-1.4.so.1.0.30 -rwxr-xr-x 1 root root 179364 Dec 14 14:54 /usr/lib/libpangomm-1.4.so.1.0.30 lrwxrwxrwx 1 root root 25 Feb 28 2013 /usr/lib/libpangox-1.0.so.0 - libpangox-1.0.so.0.3000.1 -rwxr-xr-x 1 root root 51104 Feb 28 2013 /usr/lib/libpangox-1.0.so.0.3000.1 lrwxrwxrwx 1 root root 27 Dec 14 12:54 /usr/lib/libpangoxft-1.0.so -
Re: [gentoo-user] [OT] What's happened to BOINC recently?
On Saturday 14 Dec 2013 09:17:01 Khumba wrote: On Tue, 10 Dec 2013 15:56:13 + Peter Humphrey pe...@prh.myzen.co.uk wrote: Hi list, Recently I've been finding that BOINC has just stopped. It doesn't show up in ps -ax and I can't see anything helpful in its logs. Every time I query its status I get this, which is new: $ /etc/init.d/boinc status /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpu/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuacct/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuset/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/freezer/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/openrc/tasks: Permission denied mkdir: cannot create directory ‘/sys/fs/cgroup/openrc/boinc’: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpu/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuacct/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/cpuset/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/freezer/tasks: Permission denied /lib64/rc/sh/rc-cgroup.sh: line 80: /sys/fs/cgroup/openrc/tasks: Permission denied mkdir: cannot create directory ‘/sys/fs/cgroup/openrc/boinc’: Permission denied * status: started FYI I got these errors simply when I queried the status of a service as a normal user, rather than root, but the final status line was still correct IIRC (on systemd now though, can't verify). Was on hardened at the time, if that matters. Ah, so that's what's changed - thanks. I wonder why querying the status of a service requires the creation of directories under /sys/fs/cgroup. Also whether I can configure cgroups in the kernel somehow to allow an ordinary user to query a status, as used to be possible without throwing errors. This is indeed an openrc system, as you imply, there being nothing to push me towards systemd since I don't run gnome. That just leaves the mysterious stopping of BOINC to watch out for. -- Regards Peter
[gentoo-user] Re: nvidia-drivers 325.15 removal
On 15/12/13 06:39, »Q« wrote: It looks to me as if the removal of nvidia-drivers-325.15 was a mistake, but I've got a lot going on in the meat world right now, and I don't want to file a bug if I've simply gotten confused. I run mostly stable amd64. I have 325.15 installed, and nothing regarding nvidia-drivers in /etc/portage/package/accept_keywords, so I *think* 325.15 was the latest stable and shouldn't have been removed for being old. The removal makes portage want to downgrade the package for me. I see in the changelog: 14 Dec 2013; Jeroen Roovers j...@gentoo.org -nvidia-drivers-325.15.ebuild: Old. [...] 02 Nov 2013; Jeroen Roovers j...@gentoo.org -nvidia-drivers-325.08.ebuild, nvidia-drivers-325.15.ebuild: Stable for AMD64 x86 too. Could someone confirm or set me straight? I confirm. The latest unmasked version is 319.76 (I'm using that one.) 331.20 is also in portage (latest upstream stable), but it's masked in portage. Usually, if you try to explicitly emerge something that's masked, you get a message telling you why it's masked: $ emerge -p =x11-drivers/nvidia-drivers-331.20 ... [ebuild U #] x11-drivers/nvidia-drivers-331.20 [319.76] The following mask changes are necessary to proceed: (see package.unmask in the portage(5) man page for more details) # required by =x11-drivers/nvidia-drivers-331.20 (argument) # /usr/portage/profiles/targets/desktop/kde/package.mask: # Andreas K. Huettel dilfri...@gentoo.org (1 Dec 2013) # Mask recent nvidia drivers because of sigprocmask corruption, bug 487558 # (this hits akonadi and makes significant parts of KDE hang) =x11-drivers/nvidia-drivers-331.20 So it was masked due to conflicts with KDE. If you're not using KDE, it might be safe to unmask it.
[gentoo-user] Re: @preserved-rebuild gone in a loop
On 15/12/13 11:51, Mick wrote: Not sure why, but for some reason running emerge @preserved-rebuild does not seem to fix some preserved libs links: !!! existing preserved libs: package: x11-libs/pango-1.34.1 * - /usr/lib/libpangox-1.0.so.0 * - /usr/lib/libpangox-1.0.so.0.3000.1 This is all caused by some hack I have in my local portage for app- antivirus/avast4workstation-1.3.0-r2. No matter how many times I run @preserved-rebuild the libs in question keep coming up: Yes, that's to be expected. Avast is a binary, it's not built from sources, so there's no link step involved that would link against the new pango libs. I'm not sure if it'll work, by try emerging x11-libs/pangox-compat. If that doesn't help, then your only option is to downgrade your pango version to the version that doesn't exhibit the problem and mask all newer versions.
Re: [gentoo-user] @preserved-rebuild gone in a loop
On Sun, 15 Dec 2013 09:51:39 +, Mick wrote: !!! existing preserved libs: package: x11-libs/pango-1.34.1 * - /usr/lib/libpangox-1.0.so.0 * - /usr/lib/libpangox-1.0.so.0.3000.1 * used by /opt/avast4workstation/bin/avastgui (app- antivirus/avast4workstation-1.3.0-r2) Use emerge @preserved-rebuild to rebuild packages using these libraries == It's installed in /opt, does that mean this is a binary package? If so, no amount of reinstalling it will cause it to be linked against a different library version. -- Neil Bothwick Become a gynaecologist, look up a friend today. signature.asc Description: PGP signature
[gentoo-user] Re: nvidia-drivers 325.15 removal
On Sun, 15 Dec 2013 14:24:58 +0200 Nikos Chantziaras rea...@gmail.com wrote: On 15/12/13 06:39, »Q« wrote: It looks to me as if the removal of nvidia-drivers-325.15 was a mistake, but I've got a lot going on in the meat world right now, and I don't want to file a bug if I've simply gotten confused. I run mostly stable amd64. I have 325.15 installed, and nothing regarding nvidia-drivers in /etc/portage/package/accept_keywords, so I *think* 325.15 was the latest stable and shouldn't have been removed for being old. The removal makes portage want to downgrade the package for me. I see in the changelog: 14 Dec 2013; Jeroen Roovers j...@gentoo.org -nvidia-drivers-325.15.ebuild: Old. [...] 02 Nov 2013; Jeroen Roovers j...@gentoo.org -nvidia-drivers-325.08.ebuild, nvidia-drivers-325.15.ebuild: Stable for AMD64 x86 too. Could someone confirm or set me straight? I confirm. The latest unmasked version is 319.76 (I'm using that one.) 331.20 is also in portage (latest upstream stable), but it's masked in portage. Usually, if you try to explicitly emerge something that's masked, you get a message telling you why it's masked: $ emerge -p =x11-drivers/nvidia-drivers-331.20 ... [ebuild U #] x11-drivers/nvidia-drivers-331.20 [319.76] The following mask changes are necessary to proceed: (see package.unmask in the portage(5) man page for more details) # required by =x11-drivers/nvidia-drivers-331.20 (argument) # /usr/portage/profiles/targets/desktop/kde/package.mask: # Andreas K. Huettel dilfri...@gentoo.org (1 Dec 2013) # Mask recent nvidia drivers because of sigprocmask corruption, bug 487558 # (this hits akonadi and makes significant parts of KDE hang) =x11-drivers/nvidia-drivers-331.20 So it was masked due to conflicts with KDE. If you're not using KDE, it might be safe to unmask it. I was using 331.20, but I do use KDE and it was causing me those hangs. At the time 331.20 was masked, I switched to 325.15. Now that 325.15 has been removed from the tree, the latest stable is 319.19, and that's what portage wants to downgrade me to as of yesterday. I guess my question boils down to: Was 325.15 ever stabilized? If it was stabilized, it shouldn't have been removed simply due oldness. If it was *not* stabilized, the only issue is between my ears.
Re: [gentoo-user] @preserved-rebuild gone in a loop
On 09:51 Sun 15 Dec , Mick wrote: Not sure why, but for some reason running emerge @preserved-rebuild does not seem to fix some preserved libs links: !!! existing preserved libs: package: x11-libs/pango-1.34.1 * - /usr/lib/libpangox-1.0.so.0 * - /usr/lib/libpangox-1.0.so.0.3000.1 This is all caused by some hack I have in my local portage for app- antivirus/avast4workstation-1.3.0-r2. No matter how many times I run @preserved-rebuild the libs in question keep coming up: Most of the times, when some binary packages on my systems do cause something like this, then I just unemerge the package that keeps recompiling and emerge it again afterwards. This will cause the portage to drop the library-references in question and add new ones. So, this should do the trick: emerge -C app-antivirus/avast4workstation emerge -1 app-antivirus/avast4workstation - Benjamin
Re: [gentoo-user] Nut and networked UPS config
On 12/13/2013 10:56 AM, Tanstaafl wrote: Hello all, I have a network accessible UPS (Powerware 9150 with the network option installed), so am looking for tips on how to properly configure a gentoo VM running on ESXi to initiate a safe shutdown during an extended power outage via this network card. I have an APC UPS and am currently going through this myself. (ESXi 5.1, but I don't believe that matters.) Generally the proper way to do this is have the monitoring tools installed on a vMA VM monitoring the host. It doesn't look like Powerware has anything to work directly with vMA VM. APC does have this tool. It appears it tells the host to shut down the VMs running then the host itself. This does require that the Power Off method on VMs are set to 'Guest shutdown' and that vmware-tools is running on all virtual machines, and that the Virtual Machine startup/shutdown sequence is enabled and configured. Looks like nut has full support for this UPS, so hopefully it won't be too difficult... It looks like it has full USB support but experimental snmp support. It may not work at all. The host is a Dell R515, which does have an iDRAC6 Enterprise card in it, but I'm not sure if I can utilize the BCM to talk to guest VMs running under ESXi? From what I've read that card is like a remote console, so I don't think it can be used in that manner. Would appreciate any suggestions... I haven't tried this myself, but if you can get the Gentoo VM to listen to the UPS via snmp you may be able to enable ssh on the host itself and send the host a halt command to shut down (there are security risks leaving ssh running on the host!) and not actually doing anything on the local VM at all, and letting the host shut the system down. This still requires the Power Off methods are set Virtual Machine startup/shutdown sequence enabled and configured and vmware-tools are installed on all virtual machines. If you don't install vmware-tools on everything it's possible those VMs will not shut down properly and possibly get corrupted. You can test it with no VMs running at first (well, except the one monitoring the UPS, make sure you have a backup) to make sure the host shuts down, if that works, test it with a few running. Just make sure you have backups of your virtual machines! Dan
Re: [gentoo-user] Nut and networked UPS config
What you gents are talking about it stonith. At the UPS and Host level, it's everything off or everything on. If you like individual STONITH per host, it's been a while however, this is done at the PDU and Host level. As for VM, I use Xen, and there we use libvirt and/or fence_virt. There we have STONITH at the HOST (via PDU and Iron) and VM level (via PDU and virtual machine library)
[gentoo-user] Re: @preserved-rebuild gone in a loop
On Sun, 15 Dec 2013 17:37:53 +0100 Benjamin Block b...@zlug.org wrote: Most of the times, when some binary packages on my systems do cause something like this, then I just unemerge the package that keeps recompiling and emerge it again afterwards. This will cause the portage to drop the library-references in question and add new ones. So, this should do the trick: emerge -C app-antivirus/avast4workstation emerge -1 app-antivirus/avast4workstation This will make the message from portage and the old library version go away, yes. It will also cause the program that used the library (/opt/avast4workstation/bin/avastgui in OP's case) crash when you try to run it, due to the old library version not being installed. The correct solution to this is to add the specific (old) version of the library to the dependencies (in the ebuild) of the (binary) package that uses it. This will prevent an upgrade that uninstalls the old library version. Sometimes the maintainer of the library will add a slotted version of it, so that non-binary users of it do not have to use the outdated version. If the binary package is not an ebuild, you can manually add the newer library version to package.mask, or make sure that the slot for the older version is installed if the library is slotted. Better yet (in all cases), get a more recent version of the binary package that is built against the newer version of the library. Complain to the vendor if none is available :-) The preserve-libs feature in portage is intended to let things keep on working short-term for source-distributed packages. In that case, the currently installed program is linked against the old library version, and when the program is rebuilt (with @preserved-rebuild) it will be linked against the newer version. -- eroen signature.asc Description: PGP signature
