IRC channel logs
2014-12-10.log
back to list of logs
*mark_weaver updates a bunch of gnome packages to cope with the recent gobject-introspection update <civodul>sneek: later tell davexunit just tried Sly with 'guix environment', and got "Symbol not found: glGenTextures" in gl/low-level.scm when running 2048 <Sleep_Walker>chm, efl will be tougher than expected - they expect to have X extension headers in the same path as Xlib headers, and this assumption probably worked for decade :) <amirouche>Is there a way to compute in guile the store path of some library? <amirouche>I need to do that, because my guile library is trying to load some shared library but it fails for some reasons, even if it is present in ~/.guix-profile/lib <amirouche>well I will just load it from there, guile-reader does it differently <rekado_>I want to use guix to manage different versions of bioinformatics software on our cluster. I very much appreciate the way guix liberates users, so that they are no longer at the mercy of sysadmins to install software. <rekado_>still, as a sysadmin I wonder if there are admin features that would allow me to install software into users' profiles and restrict them from installing software that hasn't yet been built. <rekado_>I think I'll need to demonstrate that we have some form of control over what work the daemon performs to have a chance of having my proposal accepted. <rekado_>I also wonder if users can just make the daemon build packages from local user-provided modules. <rekado_>will guix pick up any module file that's on a user's load path? Or is only the daemon's load path important? <rekado_>(I'm afraid of users convincing the daemon to download and execute stuff from the Internet.) <tadni>civodul: I just noticed... does the center of the Guix logo, supposed to look like a lambda?! <tadni>I didn't notice till I started playing around with the *.svg <tadni>By center, I mean whitespace. <tadni>I want to like it, but it looked a bit too much like the "Anarchism" sign. <tadni>If you flip it and add horns, it's a stylized gnu. <tadni>If you add a black background to the current Guix Logo, the center does look like a stylized lower lambda. <civodul>rekado_: the daemon will build anything users ask it to <civodul>amirouche: see how guix/config.in handles libgcrypt: it basically gets its absolute file name at configure-time <civodul>Sleep_Walker: at worst, it's always possible to create a "union" of the directories containing the various headers <civodul>Sleep_Walker: but really, if EFL is built with GCC, then it'll just honor $CPATH <Tsutsukakushi>an option to make menuconfig style dialog to choose the options when installing from sources, this would mak the .scm more complicated but would enable more people to install a package with customized options <rekado_>civodul: will the daemon *do* whatever users ask it to? Does it do *everything* it is asked to do in a chroot and as the unprivileged build users? <civodul>it can effectively be asked to do any kind of computation <civodul>but that's already what happens on the cluster anyway, right? :-) <civodul>a malicious user could cause DoS by filling up the store <civodul>but in a cluster setup, that's not a realistic threat IMO <rekado_>I'm wondering: users don't actually need to have access to the guix executable, right? They only need to have a profile. Can an administrator install software specifically for a particular user profile? <rekado_>I see that there is --profile for guix package. <civodul>the administrator could populate user profiles, yes <civodul>but IMO it's better for users to be able to run 'guix' by themselves <civodul>that will allow them to choose what to install, whether/when to upgrade, etc. <rekado_>for desktop systems I agree, but I'd have a hard time convincing the cluster admins of permitting our use of guix. It seems that admins only reluctantly give up part of their superuser powers... <civodul>it also means less work for them ;-) <civodul>rekado_: in the cluster we have at work, admins take care of providing 'modules' <civodul>but users are often unhappy with the available modules, upgrade policy, etc. <civodul>another argument, is that 'guix' simply allows users to build packages <civodul>which they can already do manually anyway <Sleep_Walker>X11/extension/Xcomposite.h is present and maybe even found, but it includes X11/extension/composite.h <rekado_>we often have users who attempt to compile software on their own, but having to mess around with the environment variables is a struggle, so in the end it's the admins who have to package up software centrally. <rekado_>from this perspective guix is a big win. <rekado_>I hope i can convey this and let them see things from this perspective. <civodul>Sleep_Walker: it could be a missing propagated input in the package that provides Xcomposite.h <civodul>rekado_: you're not an admin of that system yourself, are you? <rekado_>I'm admin for research groups using the cluster, but the cluster is officially maintained by another department. <rekado_>we have our own cluster but it's going to be decomissioned. <rekado_>currently, we are permitted to install packages on the new cluster only to a prefix under /usr/local/; we use RPMs and repackage a lot of software to support the prefix. <rekado_>civodul: no. We have a file users can source to use our software. <rekado_>(that's a more ad-hoc solution, but it works) <rekado_>obviously, packaging software as RPMs isn't nice and it doesn't support the common case where people need to use alternative versions. <rekado_>say, latest GCC for bleeding edge software, when the cluster OS only provides a very conservative (= old) version of GCC. <rekado_>civodul: I like your slides about guix. I'll take a few of them to introduce guix to the other admins. <rekado_>when a package needs a certain tool for running the tests (but not for any other phase) should this be added to the inputs? *civodul goes afk for a while <amirouche>sneek: later tell civodul I'm not sure why getting the absolute file name at configure time is better <taylanub>when a python application can't find the module 'gobject', what directory do I need to add to PYTHONPATH? <taylanub>never mind, probably python-pygobject (or in my case python2-pygobject-2, since I also depend on pygtk which only has a python2 version) <tadni`>Just played with the latest GNOME and wow. Very impressed. Sans logind, is there anything preventing GNOME from being functional on GNU Distro? <tadni`>And Logind, currently, just limits us from using GDM -- correct?