Package Details: icecream 1.4-1

Git Clone URL: https://aur.archlinux.org/icecream.git (read-only, click to copy)
Package Base: icecream
Description: takes compile jobs from your build and distributes it to remote machines allowing a parallel build on several machines.
Upstream URL: http://en.opensuse.org/Icecream
Licenses: GPL2
Conflicts: icecream-git
Provides: icecream
Submitter: uwolfer
Maintainer: xenhat
Last Packager: xenhat
Votes: 36
Popularity: 0.000000
First Submitted: 2006-10-11 20:48 (UTC)
Last Updated: 2022-04-11 06:45 (UTC)

Latest Comments

VorpalGun commented on 2022-05-27 15:34 (UTC)

Hi new maintainer. My comment about clang below still stands. Please add --enable-clang-wrapper --enable-clang-rewrite-includes or a makedepend on clang. When building the package in a clean chroot, the auto detection of clang installed on the host doesn't work.

bwidawsk commented on 2022-04-06 21:56 (UTC)

I missed the request to update this a few weeks back because my mail was down, and it seems someone wants to take it over, so it's good time to disown.

VorpalGun commented on 2022-03-08 21:00 (UTC)

There is a bit of a problem: this package optionally depends, at build time, on clang):

The symlink for clang/clang++ in /usr/lib/icecream/libexec/icecc/ is only created if clang is installed. This is a problem when building the package in a minimal chroot (such as when using aurutils with the -c flag).

I would suggest making clang a build dependency and an optional run time dependency to make the build more reliable (as I don't believe always having the symlink would be a problem even if clang isn't installed).

You could also just pass --enable-clang-wrapper to configure, but reading through configure.ac it looks like it also tries to auto detect if clang properly supports -frewrite-includes amongst other things. My first suggestion is likely simpler and more reliable with regards to future changes.

micwoj92 commented on 2021-05-14 16:50 (UTC)

No, install base-devel.

Distag commented on 2021-04-28 08:56 (UTC)

Hi, please add automake (for aclocal and co.) as a depend.

Thank you for your maintainer work.

OJaksch commented on 2021-01-31 07:36 (UTC)

I'd suggest to move to pre-release 1.4rc1. I've build my own package and this solved many issues at my cluster, specially flush_writebuf() failed errors, which in turn slows down compile jobs.

See https://github.com/icecc/icecream/issues/527

patlefort commented on 2020-06-08 12:00 (UTC)

The documentation (upstream URL) moved to its github page.

diggit commented on 2020-03-05 14:15 (UTC)

@bwidawsk ok here it is https://ghostbin.co/paste/akuqx tested and working

bwidawsk commented on 2020-03-04 22:15 (UTC)

@diggit: I have no experience with firewalld, but I'd gladly merge a patch.

@apol: They are both in base-devel and as mentioned here https://wiki.archlinux.org/index.php/PKGBUILD#makedepends, aren't too be added.

diggit commented on 2020-03-04 20:29 (UTC)

Can you add firewalld xml configs for icecream? Like in https://centos.pkgs.org/7/epel-x86_64/icecream-1.1-2.el7.x86_64.rpm.html

apol commented on 2020-03-03 22:02 (UTC)

autoconf and automake are missing in makedepends.

graysky commented on 2019-10-26 14:46 (UTC) (edited on 2019-10-26 15:12 (UTC) by graysky)

@bwidawsk - Did you mean to have the executable flag set for config files? For example line 47?

cheesehead544 commented on 2018-07-19 02:03 (UTC)

in the pkgbuild the arch is set to x86_64, but i have just confirmed it builds fine in i686. could you consider adding the i686 architecture in the pkgbuild, for all the archlinux32 users out there?

TomZander commented on 2016-12-22 16:18 (UTC)

In your optdepends you write 'iceberg-git: a QT {etc}'. Would you be able to change that product name to 'Qt', QT stands for QuickTime. Qt is the name of the graphics toolkit :)

franziskus commented on 2016-12-21 09:10 (UTC)

Hm, this currently doesn't build. checking for lzo1x_1_compress in -llzo2... no configure: error: Could not find lzo2 library - please install lzo-devel

bitfix commented on 2016-01-01 21:13 (UTC)

The chown icecc:icecc ${ICECREAM_LOG_FILE} line in icecreamd doesn't match the user and group icecream:icecream created by icecream.install.

bwidawsk commented on 2015-12-28 18:45 (UTC)

PSA: This fails to work with community/hardening-wrapper. I am not sure why yet (ld related). I have no desire to try to fix it.

bwidawsk commented on 2015-12-24 19:42 (UTC)

I've done my best to update this package to have it closely resemble upstream (SuSE) where possible, and using Fedora Core's systemd service files for the rest. This was a pretty large change overall. Please let me know if you have issues. It might be best to manually remove the old icecream package and verify all the contents are gone. @hunger: Also FWIW, type=simple + the -d option is not correct. However, I've dropped the -d and gone with type=simple because of the issue you reported. This matches the FC service as well.

bwidawsk commented on 2015-12-11 18:12 (UTC)

@hunger Sorry for the delay, I was on vacation. You are correct about Type=simple. I noticed some other changes in the upstream package which I never bothered to look at when I adopted the package. I should probably work to incorporate those, and may as well do it on the update with Type=simple. I will try to get it completed today or tomorrow. Thanks!

hunger commented on 2015-12-02 11:56 (UTC)

I had to add the following override to icecream.service: ProtectSystem=full PrivateDevices=true PrivateTmp=true ProtectHome=on NoNewPrivileges=true Type=simple The Protect*, Private* and NoNewPrivileges are just to harden the installation. That will prevent some attacks. But without Type=simple the iceccd would stop with a timeout after a while. It apparently does need -d to detach, so Type=forking is probably wrong -- and you do not want forking anyway if you can avoid that with systemd.

abique commented on 2015-01-14 12:22 (UTC)

I disown the package if anyone wants to take it :)

ecloud commented on 2015-01-14 12:19 (UTC)

https://aur.archlinux.org/packages/icecream-git/ does indeed work better. But there is also aur/icecc. aur/icemon-git depends on aur/icecc. Whereas aur/iceberg-git does not build. Does that mean icecc is the one that regular users should be running? Apparently. It does seem to work. But it is version 1.0.1.

ecloud commented on 2015-01-14 11:43 (UTC)

It's confusing that the user name is different between icecream-git and this build, and this one is not managing it well. The first time I installed this (tried to "upgrade" from icecream-git) it failed to change /etc/passwd, so I edited it myself to ensure that both users exist. Set the home dir to /tmp (why would it have /home/icecc given that directory does not exist?) Then had to modify /usr/lib/icecream/icecream-schedulerd: - /usr/lib/icecream/sbin/scheduler -d $netname $logfile &>/dev/null + /usr/lib/icecream/sbin/icecc-scheduler -d $netname $logfile &>/dev/null If the user name is now icecc, this line needs changing too: chown icecream:icecream $ICECREAM_LOG_FILE So now I have the scheduler running (shown by ps): icecc 1991 0.1 0.0 23600 3076 ? Ss 11:08 0:05 /usr/lib/icecream/sbin/icecc-scheduler -d -l /var/log/iceccd But the icecream service silently failed to start. (Why silently?) When trying to run the daemon manually I could see chown/chmod in cleanup_cache() failed Operation not permitted So I modified source to find out what such an ambiguous error message could mean. It turns out that /tmp/icecc-envs already existed and belonged to the wrong user. I removed it, and now I can run the daemon manually. But systemd still doesn't really run it, even though it thinks it was successful. So I put an echo command into /usr/lib/icecream/icecreamd to see what it does; the command line is /usr/lib/icecream/sbin/iceccd -d -l /var/log/iceccd --nice 5 -b /var/cache/icecream and it runs as user icecc. So /var/cache/icecream needs to belong to that user. Shouldn't the two daemons have separate log files? Now they are both going to /var/log/iceccd. So I make the scheduler log go to /var/log/icecc-scheduler instead (by setting ICECREAM_LOG_FILE=/var/log/icecc-scheduler in /usr/lib/icecream/icecream-schedulerd).

gishten commented on 2014-04-15 12:08 (UTC)

I recommend going for https://aur.archlinux.org/packages/icecream-git/ instead, that works well for me.

SirPenguins commented on 2014-03-01 06:56 (UTC)

Sorry that took so long, I've disowned the package so feel free to adopt it. Thank you :)

lucasdemarchi commented on 2013-07-26 15:53 (UTC)

> icecream service doesn't start. This is probably due to /var/cache/icecream not being writable by the user icecc runs with, since it will either fail to create the dir if it doesn't exist (strace logs): mkdir("/var/cache/icecream", 0755) = -1 EACCES (Permission denied) Or fail to own it afterwards, since it will try to own the directory after revoking its privileges: setresuid(1001, 1001, 1001) = 0 ... chown("/var/cache/icecream", 1001, 1001) = -1 EPERM (Operation not permitted) I think the best way would be to create a bug report to icecream so it chown() the dir before revoking privileges. But.... creating the dir beforehand and giving proper privileges works as well. IMO we should change the type of .service file to "simple" and the last line of the script to: exec /usr/lib/icecream/sbin/iceccd $logfile $nice $netname -b "$ICECREAM_BASEDIR" $maxjobs $noremote This way we get proper logs on "systemctl status icecream"

net147 commented on 2013-07-26 13:00 (UTC)

In icecream-schedulerd: /usr/lib/icecream/sbin/scheduler -d $netname $logfile &>/dev/null needs to change to: /usr/lib/icecream/sbin/icecc-scheduler -d $netname $logfile &>/dev/null Otherwise systemctl start icecream-scheduler will fail. icecream-scheduler needs icecream user/groug which isn't created on install. icecream needs icecc user which isn't created on install. icecream service doesn't start.

SirPenguins commented on 2013-02-20 18:07 (UTC)

@scippio -- That's where they're supposed to go. /usr/bin/gcc and others are already owned by another package, and I'm not putting a subdirectory in /usr/bin/ @hugo -- I'm on it, I'm updating this to a git package and and adding in the .pc file where its supposed to go @rakuco -- Thank you!

scippio commented on 2013-02-19 01:11 (UTC)

icecream /usr/lib/icecream/bin/ I hate you :)

hugo commented on 2013-01-30 19:33 (UTC)

Would be nice to install icecc.pc (pkgconfig file) on default pkgconfig location to have it available system wide by default.

commented on 2012-10-24 20:40 (UTC)

FWIW, icecream has finally moved to git, so you kids can finally start submitting pull requests or whatever: https://github.com/icecc

lucasdemarchi commented on 2012-07-17 13:29 (UTC)

what a shame... because committers like you it's now broken :-p

commented on 2012-07-17 13:27 (UTC)

I'm not even a glibc user these days :-)

lucasdemarchi commented on 2012-07-17 13:25 (UTC)

@rakuco: or you could commit it :-)

commented on 2012-07-17 13:10 (UTC)

I guess the best way to send patches upstream these days is to diff against current trunk <svn://anonsvn.kde.org/home/kde/trunk/icecream> and mail to people such as Luboš Luňák <l.lunak@kde.org> or Stephan Kulow <coolo@kde.org>.

SirPenguins commented on 2012-07-17 13:04 (UTC)

Thank you for your patch, I was working with some people on the IRC channel to try and fix the compilation errors but you did it for me! Not sure how to get this sent upstream; icecream doesn't have a bug tracker yet.

lucasdemarchi commented on 2012-07-16 17:38 (UTC)

good... but with newer glibc it's not compiling anymore. Maybe something to send to upstream: http://people.profusion.mobi/~lucas/fix-rusage.diff

SirPenguins commented on 2012-07-16 13:04 (UTC)

Done. Thank you!

lucasdemarchi commented on 2012-07-16 13:00 (UTC)

With the recent move to /usr, this package needs to be updated. Please install files under /usr/lib/systemd rather than /lib/systemd/

SirPenguins commented on 2012-06-19 13:22 (UTC)

According to the packaging standards in the Wiki, /usr/lib/{pkg} is for "Modules, plugins, etc.", /opt/{pkg} is for "Large self-contained packages such as Java, etc." (Which this program is not, I would argue), and /usr/share/{pkg} is for "Application data". I would not be against moving icecream's files (including the binaries) into /usr/share/icecream, but I am not moving them to /opt/ because icecream isn't large enough to warrant that. Many users choose to have /usr/ reside on a filesystem optimized for quick binary and library access. /opt/ is not often given its own "faster" filesystem. I think it benefits the most users to keep it somewhere under /usr/. otooshmidt: You are welcome to fork or modify this package and put files in /opt/ . No one is stopping you.

lucasdemarchi commented on 2012-06-19 13:16 (UTC)

ottoschimidt: sure, and this is a package that is managed by the pacman - there's no reason it should be different from other packages, which install to /usr. See https://wiki.archlinux.org/index.php/Arch_Packaging_Standards#Directories

ottoshmidt commented on 2012-06-19 09:23 (UTC)

lucasdemarchi: /opt is for optional (custom) packages.. no? and why should I not let them in there?

lucasdemarchi commented on 2012-06-18 13:21 (UTC)

ottoshmidt: you should never let /opt/ in AUR packages. /usr/lib is not only for libraries.

ottoshmidt commented on 2012-06-18 08:38 (UTC)

why is prefix /usr/lib/icecream and not /opt/icecream. Generally, /usr/lib contains libraries not binaries.

anselmolsm commented on 2012-06-15 16:57 (UTC)

@Luigi_Panache: you are right, this package was created because aur/icecream wasn't being maintained. Now that you updated it, I can drop icecream1 ;)

lucasdemarchi commented on 2012-05-10 18:01 (UTC)

I meant... I think icecream1 was created because the previous maintainer of this package was not updating it, no? Now that it is, we could drop the other one

lucasdemarchi commented on 2012-05-10 18:01 (UTC)

I meant... I think icecream1 was created because the previous maintainer of this package was not updating it, no? Now that it is, we could drop the other one

SirPenguins commented on 2012-05-10 17:59 (UTC)

Sorry about that, fixed it now! And icecream1 is also up-to-date, but does not support systemd as well as regular arch init.

lucasdemarchi commented on 2012-05-10 16:26 (UTC)

Nice. But you forgot to add "cd $startdir/src/icecc-$pkgver" in package(), otherwise it breaks package generation. Btw, what about the other package icecream1 here in AUR?

SirPenguins commented on 2012-05-10 10:40 (UTC)

I've adopted this package, and updated it to the latest version as well as added systemd support.

commented on 2011-05-19 11:21 (UTC)

Version 0.9.7 has been officially released. Nothing new since that committing fixing the build with gcc 4.6.

commented on 2011-05-04 14:26 (UTC)

The same fix was also done independently and ended up being commited upstream -- http://websvn.kde.org/?view=revision&revision=1230353 I recommend updating the package here.

commented on 2011-05-03 02:07 (UTC)

The following patch should fix the issue with gcc 4.6: http://paste.kde.org/48373/ (remember to rm -fr /tmp/icecc* and then restart the icecream daemon after that). I'm still wondering whether this fix should be committed upstream, or if gcc is at fault for relying on a file which only exists in /usr/lib/gcc/<arch>/4.6.0.

hugo commented on 2011-04-28 17:45 (UTC)

It doesn't work with g++ 4.6, I always get the error: g++: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found the liblto_plugin.so isn't in the gcc tarball created by icecc.

lucasdemarchi commented on 2010-06-18 14:09 (UTC)

I confirm this problem occurs. Worth noting that this bug (that already existed before) was exposed by the update on glibc from 2.11 to 2.12

commented on 2010-06-17 15:17 (UTC)

Until a new release is made, the PKGBUILD should be modified with the following patch from upstream trunk: http://websvn.kde.org/trunk/icecream/client/icecc-create-env?r1=926473&r2=1131079 Otherwise, icecc will not be able to send jobs to other clients.