Re: [gentoo-user] revdep-rebuild finds nothing, while revdep-rebuild.sh wants to rebuild the whole system
On 10/17/2017 10:40 PM, Nikos Chantziaras wrote: Running the new revdep-rebuild finds nothing: $ sudo revdep-rebuild -i -- -a * This is the new python coded version * Please report any bugs found using it. * The original revdep-rebuild script is installed as revdep-rebuild.sh * Please file bugs at: https://bugs.gentoo.org/ * Collecting system binaries and libraries * Checking dynamic linking consistency Your system is consistent However, running revdep-rebuild.sh wants to rebuild everything: https://pastebin.com/raw/BHq2NU0G Does someone know what's going on? I don't know what's going on, but I see the same thing on one of my systems. Todd
Re: [gentoo-user] Re: monit and friends.
Hi Alan, This isn't exactly what you describe for your needs but have you considered using auto-remediation outside of the box? I've been using StackStorm https://stackstorm.com/ for the last year in an environment of ~1500 physical servers for this purpose and it's been quite successful. It has been handling cases like restarting SNMP daemons that segfault, hadoop instances that loose to contact with the ZooKeeper cluster, restarting nginx daemons that stop responding to requests by analysing the last write date in nginx's access logs, the list goes on. StackStorm is event driven platform that has many integrations available allowing it to interact with internal and external service providers. It's Python based and can use ssh to execute remote commands which sounds like an acceptable approach since you're using ansible. Connecting SNMP traps up to StackStorm's event bus to trigger automated responses based on the trap contents would be inline with common use cases. Regards, Carlos On 16/10/17 17:50, Alan McKinnon wrote: Nagios and I go way back, way way waay back. I now recommend it never be used unless there really is no other option. There is just so many problems with actually using the bloody thing, but let's not get into that:-) I have a full monitoring system that tracks and reports on the state of most things, but as it's a monitoring system it is forbidden to make changes of any kind at all, and that includes restarting failed daemons. Turns out that daemons that failed for no good reason are becoming more and more common in this day and age, mostly because we treat them like cattle not pets and use virtualization and containers so much. And there's our old friend the Linux oom-killer What I need here is a small app that will be a constrained, single-purpose watchdog. If a daemon fails, the watchdog attempts 3 restarts to get it going, and records the fact it did it (that goes into the big monitoring system as a reportable fact). If the restart fails, then a human needs to attend to it as it is seriously or beyond the scope of a watchdog. Like you, I'm tired of being woken at 2am because something dropped 1 ping when the nightly database maintenance fired up on the vmware cluster:-)
[gentoo-user] installsources not working for some packages
Hello, I have installsources and splitdebug in FEATURES and it works as it should for some packages but for others the sources are not installed. The directory for the package is created under /usr/src/debug but it's empty. The only hint is the following error on the install phase between strip and ecompressdir: installsources: rsyncing source files rsync: link_stat "/var/tmp/portage/net-wireless/bluez-5.47-r1/work/var/tmp/portage/sys-libs/glibc-2.23-r4/work/glibc-2.23/csu" failed: No such file or directory (2) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1178) [sender=3.1.2] The debug symbols are installed correctly. Any clues? Thanks, -- Fernando Rodriguez
[gentoo-user] [OT] cura or (better!) cura ?
Hi,
what is the better choice:
This one:
* media-gfx/cura
Available versions: (~)0.15.04.4 (~)0.15.04.5_rc5 (~)2.1.0_beta (~)2.3.1
(~)2.6.0 {+usb PYTHON_SINGLE_TARGET="python3_4 python3_5 python3_6"
PYTHON_TARGETS="python2_7 python3_4 python3_5 python3_6"}
Homepage:https://github.com/Ultimaker/Cura
Description: A 3D model slicing application for 3D printing
or
This one:
* media-gfx/curaengine
Available versions: (~)0.15.04.6 (~)2.1.0_beta (~)2.3.1 (~)2.6.0 {doc
test}
Homepage:https://github.com/Ultimaker/CuraEngine
Description: A 3D model slicing engine for 3D printing
Looks pretty identical to me...but I am no native speaker... ;)
Cheers
Meino
Re: [gentoo-user] [OT] cura or (better!) cura ?
Am Mittwoch, 18. Oktober 2017, 19:44:33 CEST schrieb tu...@posteo.de:
> Hi,
>
> what is the better choice:
> This one:
> * media-gfx/cura
> Available versions: (~)0.15.04.4 (~)0.15.04.5_rc5 (~)2.1.0_beta
> (~)2.3.1 (~)2.6.0 {+usb PYTHON_SINGLE_TARGET="python3_4 python3_5
> python3_6" PYTHON_TARGETS="python2_7 python3_4 python3_5 python3_6"}
> Homepage:https://github.com/Ultimaker/Cura
> Description: A 3D model slicing application for 3D printing
>
^^^
> or
> This one:
> * media-gfx/curaengine
> Available versions: (~)0.15.04.6 (~)2.1.0_beta (~)2.3.1 (~)2.6.0 {doc
> test} Homepage:https://github.com/Ultimaker/CuraEngine
> Description: A 3D model slicing engine for 3D printing
>
^^
> Looks pretty identical to me...but I am no native speaker... ;)
As I attempted to point out above, one is the engine and one is the
application. I suspect that installing cura will pull in curaengine as a
dependency (addendum: looking at the ebuild verified this).
> Cheers
> Meino
HTH
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
[gentoo-user] Compiling uranium-2.6.0: Wrong python version, but...
Hi,
compiling uranium failed here. From the output:
-- Using CURA_BINARY_DATA_DIRECTORY from set of environment variables...
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137
(message):
Could NOT find PythonInterp: Found unsuitable version "3.4.6", but required
is at least "3.5.0" (found
/var/tmp/portage/dev-python/uranium-2.6.0/temp/python3.4/bin/python)
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:375
(_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake/Modules/FindPythonInterp.cmake:158
(FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:13 (find_package)
-- Configuring incomplete, errors occurred!
See also
"/var/tmp/portage/dev-python/uranium-2.6.0/work/uranium-2.6.0_build/CMakeFiles/CMakeOutput.log".
* ERROR: dev-python/uranium-2.6.0::gentoo failed (configure phase):
* cmake failed
*
* Call stack:
* ebuild.sh, line 124: Called src_configure
* environment, line 4080: Called cmake-utils_src_configure
* environment, line 1096: Called die
* The specific snippet of code:
* "${CMAKE_BINARY}" "${cmakeargs[@]}" "${CMAKE_USE_DIR}" || die "cmake
failed";
*
* If you need support, post the output of `emerge --info
'=dev-python/uranium-2.6.0::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=dev-python/uranium-2.6.0::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/dev-python/uranium-2.6.0/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/dev-python/uranium-2.6.0/temp/environment'.
* Working directory:
'/var/tmp/portage/dev-python/uranium-2.6.0/work/uranium-2.6.0_build'
* S: '/var/tmp/portage/dev-python/uranium-2.6.0/work/Uranium-2.6.0'
[1]15403 exit 1 emerge media-gfx/cura
But:
root>python --version
Python 3.5.4
eselect python list
Available Python interpreters, in order of preference:
[1] python3.5
[2] python3.4
[3] python2.7
How can I fix this?
Thanks a lot for any help in advance!
Cheers
Meino
[gentoo-user] eix: coloured output of package versions
Hi everyone, I was just wondering what the colouring of the different versions means and I could not find any documentation about it or I cannot formulate my search keywords precisely. What I can guess is that: green is stable, yellow is testing and red is unstable I am going to put it here, if there is no other documentation about that: https://wiki.gentoo.org/wiki/Eix In the attachment you will find a cropped screenshot when executing "eix chromium". -Ramon
Re: [gentoo-user] eix: coloured output of package versions
On Thu, Oct 19, 2017 at 12:18 AM, Ramon Fischer wrote: > Hi everyone, > > I was just wondering what the colouring of the different versions means and > I could not find any documentation about it or I cannot formulate my search > keywords precisely. > > What I can guess is that: > > green is stable, > yellow is testing > and > red is unstable > > I am going to put it here, if there is no other documentation about that: > > https://wiki.gentoo.org/wiki/Eix > > In the attachment you will find a cropped screenshot when executing "eix > chromium". > Probably a good idea. However, the classes are: stable, unstable/testing, and unkeyworded. Red is unkeyworded or masked. Cheers, R0b0t1.
