Package Details: icinga-studio 2.6.2-1

Git Clone URL: https://aur.archlinux.org/icinga2.git (read-only)
Package Base: icinga2
Description: Graphical tool for debugging and testing the Icinga2 API
Upstream URL: http://www.icinga.org
Licenses: GPL
Submitter: bebehei
Maintainer: Zearan
Last Packager: Zearan
Votes: 24
Popularity: 0.878200
First Submitted: 2014-06-23 01:10
Last Updated: 2017-02-15 20:06

Latest Comments

bebehei commented on 2017-02-20 12:16

@aknarts: read the thread. Thanks.

aknarts commented on 2017-02-20 11:56

Also requires bison and flex packages to compile
Optionaly pkg-config

zork commented on 2017-02-14 12:53

logrotate fails to rotate icinga2 logs due to permission problems.
I had to change following lines in /etc/logrotate.d/icinga2:

- su icinga icinga
+ su icinga icingacmd

- create 644 icinga icinga
+ create 644 icinga icingacmd

Zearan commented on 2017-02-06 20:14

Icinga Studio is now available in AUR! Therefore this is now a split package. Please check out all the changes and help improving the package by providing feedback.

bebehei commented on 2016-12-29 22:03

Previous answer:

@das_j install the base-devel package group. Base devel is included in no PKGBUILD, cause it's the arch-standard to install the base-devel package for compilation jobs.

svenihoney commented on 2016-12-29 21:19

bison and flex seem to be makedepends, perhaps you may add them to the PKGBUILD file.

Zearan commented on 2016-11-27 19:36

I would like to stick to arch=('i686' 'x86_64') as these are Arch Linux' officially supported architectures. If I had to build this package on ARM, I would follow bebehei's suggestion and use 'makepkg -A'.

bebehei commented on 2016-11-27 12:26

@q84fh:

Yes and No.

Personally, I would stick to the Arch's package specifications of
https://wiki.archlinux.org/index.php/PKGBUILD#arch :
> If instead a package can be compiled for any architecture, but is architecture-specific once compiled, specify all architectures officially supported by Arch, i.e. arch=('i686' 'x86_64').

AFAIK Zearan does not use icinga2 on a Raspberry Pi. And I don't know how to assure support for other architectures, if you cannot test it as a maintainer.

Also It's a much cleaner way to use the AUR with an ARM-Based device while using makepkg with the option -A.

q84fh commented on 2016-11-27 10:00

@bebehei I finally managed to compile icinga2 on Rasberry Pi. So, I believe you can add armv7h to arch array. I used large swap external magnetic drive, and it took hours to complete, but it did not crashed this time.

There was upgrade of boost libary in mean time, so I think they fixed this bug in upstream.

bebehei commented on 2016-10-16 18:45

@q84fh

It seems like, something in /usr/include/boost/signals2/connection.hpp is broken. I don't know how to solve the problem exactly.

Using my google foo, i can find exactly 0 related problems.

Compiling on x86_64 with latest packages, everything works fine.

So it may be caused by a bad combination of versions in boost/icinga2/gcc. It may help, to downgrade one of theses and test. I'm pretty unsure if any of these downgrades really will solve the problem, but personally I'd give it a shot.

As I can see, boost got a small upgrade during the last month [1]. I would downgrade boost to 1.60.0-5 and give it a try. (Do not downgrade to 1.60.0-4, this version is known to fail! https://bugs.archlinux.org/task/49248)

Also downgrading gcc may help. [2]

Check for icinga2 changes at [3]

[1] https://github.com/archlinuxarm/PKGBUILDs/commits/master/extra/boost
[2] https://github.com/archlinuxarm/PKGBUILDs/commits/master/core/gcc
[3] https://aur.archlinux.org/cgit/aur.git/log/PKGBUILD?h=icinga2

Completely off topic: Are you compiling with clang or gcc? I once had an issue while compiling a big project with clang. Memory consumption grew steadly, until everything had been eaten up. clang segfaulted, but it was a clear OOM issue and after segfault all memory was free. After upgrading the memory of the machine, everything went fine.

You may also watch your memory-stats during compilation and double check the function of your swap. Also if your run your compilation in parallel, it causes obviously higher memory consumption.

All comments