IRC channel logs


back to list of logs

*mark_weaver updates a bunch of gnome packages to cope with the recent gobject-introspection update
<civodul>Hello Guix!
<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
<amirouche>héllo :)
<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 :)
<Sleep_Walker>until Guix
<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
<amirouche>seems like my little hack is ok
<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.
<rekado_>tadni: the originally proposed logo did contain a lambda:
<tadni>I want to like it, but it looked a bit too much like the "Anarchism" sign.
<rekado_>after Nikita posted the new logo, civodul commented on lambda between the "drops" (which represent profiles):
<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/ 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
<Sleep_Walker>civodul: I have never heard of CPATH so far
<Sleep_Walker>but I'll have a look
<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>rekado_: yes to both
<civodul>well, for some value of "whatever"
<civodul>it can effectively be asked to do any kind of computation
<civodul>but that's already what happens on the cluster anyway, right? :-)
<rekado_>true :)
<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>using 'guix package --profile=...'
<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 ;-)
<Sleep_Walker>the problem is maybe slightly different
<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.
<Sleep_Walker>and that one is not present
<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
<Sleep_Walker>civodul: my thought exactly
<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_>It's not pretty.
<civodul>i see
<civodul>so you don't use
<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.
<nkar>hi all
<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>rekado_: yes
<civodul>hi, nkar
*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
<Sleep_Walker>argh, composite.h is in compositeproto - my fault
<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?