<Apteryx>Do we have a way to make non-installable packages? The use case is providing resources useful for services rather than programs. <sadiq[m]>I get ld-wrapper: error: attempt to use impure library "/home/sadiq/.guix-profile/lib64/libicalvcal.so" error when trying to compile gnome-todo <zacts>does mark_weaver still hang out here? <sadiq[m]>eh, pkg-config --libs libical returns .../lib dir. but I do have only .../lib64 directory <sadiq[m]>Can I add a symlink manually to some gnu/store subdirectory? <buenouanq>you want to have the same package installed twice in different places? is this what you're asking? <sadiq[m]>nope inside some invironment with pkg-config, the output of pkg-config --libs libical is giving the output as -L.../lib directory. But such a directory doesn't exist, and so make is failing <sadiq[m]>So I need to create a lib as a symlink to lib64 dir (in libical gnu/store directory) buenouanq <buenouanq>this is beyond my knowledge/understanding, sorry <rekado_>sadiq[m]: the correct way is to make the package install libraries into “lib”, not “lib64”. <sadiq[m]>rekado_: hm.. libical does something else <sadiq[m]>also a symlink ~/.guix-profile/lib64 points to libical directory in /gnu/store/../lib64 which I feel extremely wrong <wingo>usually there is no lib64 in guix <wingo>could be a bug in the libical package <wingo>sadiq[m]: regarding that ld error: usually happens on install, right? <wingo>in guix ld is a wrapper script that does some post-processing (basically writing rpaths into the libs/exes) <sadiq[m]>wingo: this happened when buildinging (probably during the linking phase) <wingo>for internal reasons this script checks that you aren't linking to anything outside the store <wingo>of course that's not what you want when you're doing local software development <wingo>and installing to e.g. /opt or something <sadiq[m]>i'm on guixSD, so how 'outside' is defined? <wingo>outside == linking against a path that's not from /gnu/store <wingo>did you have to add a path to this lib64 dir to your linker path? <sadiq[m]>hm.. the only thing that is outside of the store is gnome-todo itself. libical is already inside the store. I don't know what's happening <wingo>having ~/.guix-profile/lib64 link to /gnu/store/libical-..../lib64 is to be expected actually -- the profile is a union of all /lib64 directories in packages you have installed. in this case there is only one package with a /lib64 so it links directly <wingo>anyway to get around this error you set GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yep in the environment <wingo>but really we should fix the script to only run this check for binaries to be installed in /gnu/store :P <wingo>still, you should consider fixing the libical package to install to /lib instead of /lib64 <sadiq[m]>hm.. I tried with GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yep. But I get some different error (from gobject-introspection) which says cc is not found <wingo>in that case do you have gcc installed? you need gcc-toolchain i think <sadiq[m]>wingo: I did guix environment gnome-todo. Isn't that enough? should I install gcc-toolchain? <wingo>can you paste your package somewhere? <wingo>i don't know, all that looks good <wingo>it is ok to have a not-quite-working package, it is a good starting point for others :) <jherrlin>Hey, I am facing a problem with Grub. I have run =guix system reconfigure ...= a couple of times and every time I run it it will create a new entry in */boot/grub/grub.cfg*. Could i somehow get Grub to always point to the latest generation and for example save only the latest 5 in the Grub submenu? <jherrlin>at the moment i have around 25 entries and when Grub starts at boot, in the submenu it only gives me around 20. <civodul>jherrlin: the default is always the latest generation <civodul>the previous ones are here in case you want to roll back <civodul>currently, to remove the old ones, you have to run "sudo rm /var/guix/profiles/system-NN-link", but be careful! <civodul>note that these extra entries don't necessarily mean that extra disk space is used <jherrlin>okey, and then remove them from */boot/grub/grub.cfg*? <civodul>it'll be regenerated on the next reconfigure, without the entries that have been removed <jherrlin>okey, so remove genrations from */var/guix/profiles/system-NN-link* and the run =guix system reconfigure ...=? <civodul>right, but do *not* remove the current generation <civodul>well, actually nothing bad would happen <jherrlin>but one thing, when i look at the paste i provided <jherrlin>the default menu item and submenu item #25 <jherrlin>the default dont point to =--system=/var/guix/profiles/system-25-link= <efraim>i watched the arm-bof from the latest debconf, apparently thunderX is 64-bit only, otherwise just about every board should be able to run 32 bit code, and apparently the arm* architectures are all supposed to be bi-endian <efraim>they also said that a lot of the build/run errors are from packages bundling old versions of libgc from old versions of glibc <ng0>sneek: later tell efraim: I ran out of diskspace for some days until I notied that the 25GB I still had free before I started weren't enough for offline-snapshot of gnunet.org ;) <sneek>Welcome back ng0, you have 1 message. <sneek>ng0, efraim says: when I `git fetch' your guix repo my terminal prints in German: remote: Zähle Objekte: 140, Fertig. <sneek>Welcome back efraim, you have 1 message. <sneek>efraim, ng0 says: I ran out of diskspace for some days until I notied that the 25GB I still had free before I started weren't enough for offline-snapshot of gnunet.org ;) <ng0>ACTION just received new servers and 60+TB storage for Guix<rekado> <- woah :O <ng0>I really think there's something missing in our documentation when people start asking for propagating fonts <ng0>other systems simply run fc-cache -fv without people noticing. <ng0>we can't do that easily, but could as a small service <efraim>sadiq[m]: hmm, probably the binary needed to reference the lib dir, and it was installing in lib64, would be my guess <sadiq[m]>efraim: hm.. the libical.pc in pkg-config isn't updated to accommodate the change. It still says libdir=${exec_prefix}/lib (not lib64) <efraim>i don't have a 32-bit system to see if that uses /lib <ng0>well you can update the content of the .pc file <efraim>i just took it out and got this error while building: validating RUNPATH of 5 binaries in "/gnu/store/lafwd05xizjm9cwc0jjilqfz2809nq5l-libical-2.0.0/lib64"... <efraim>i'm trying cmake_install_libdir now <efraim>looks like i typoed cmake_install_dir in place of cmake_install_libdir <efraim>that seems to have worked, i'll build out to gnome-todo to make sure it's fine <sadiq[m]>efraim: gnome-todo builds fine when done as 'guix build gnome-todo' but 'bash ./configure && make' inside gnome-todo environment fails. Says error while loading shared libraries: libical.so.2 ***Piece_Maker is now known as Acou_Bass
<rekado_>I find it hard to control the behaviour of cmake. <rekado_>wonder why some people consider it friendlier to developers than autotools. <civodul>rekado_: i think it's considered friendlier to autotools (which might be true), but it's definitely more difficult for users (people installing the software) IMO <efraim>You can always run cmake during development, you don't need to run automake; ./configure; make <slyfox>if automake would not be in m4 maybe cmake would not even exist <civodul>yeah, different user/developer tradeoffs! <janneke>how do i copy /gnu/store to another machine? trying to copy all /gnu/store/<directory> gives: ... item is isvalid <janneke>ACTION writing script to filter invalid store items... <efraim>From one partition to another I used 'cp -a' as root <efraim>Other than that I keep,on adding all my machines as substitutes for each other <civodul>janneke: guix copy --to=other $(guix gc --list-live) <civodul>though that's heavyweight as you can imagine :-) <civodul>efraim: you no longer need to "guix archive --authorize" each machine <civodul>it should Just Work now, except for non-reproducible packages <efraim>Does guix weather keep the port to the substitute server open until it finishes computing? <civodul>efraim: yes, it pipelines all the HTTP requests <civodul>this is code from (guix scripts substitute) <efraim>I'll try to take a look at the code later, when I check from my slow machines all the substitutes it takes a long time and ties up a guix publish worker <civodul>rekado_: really happy we have 'package->code'! <civodul>soon we can change importers to return package objects <janneke>civodul: thanks...this is for migrating an offload machine, i expect much less paths to be live than merely valid <janneke>the small scm script worked, but it might be nice to somehow expose this <janneke>possibly have guix copy not barf when it's given invalid items...not sure <rekado_>civodul: I’ll try to change the CRAN importer first, and then see what happens :) <janneke>i'm also wondering why there are so many invalid paths in the store...this ubuntu+guix build server is known to fail with sefaults...error 100 or so <rekado_>in 2 weeks there will be a short (~ 1 hour) downtime for berlin.guixsd.org <rekado_>need to move some servers to a different rack. <rekado_>once the exact time is known I’ll send email to guix-devel and sysadmin <civodul>we should improve the column widths and all <janneke>...will they be writing a/integrating this with a cuirass interface too? <civodul>janneke: currently nothing is hpc-ish, and i think we should consider making it part of Guix or something ***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
<ng0>efraim: oh oh. were you able to pull successfully again? I experienced a git corruption now and that's even when trying to use only what's on the server <efraim>ng0: i was able to 'git fetch' before also, I was just suprised it was in German <ng0>i had no choice in language <ng0>minimal preconfigure Debian and I didn't bother with languages <ng0>I think the branch system/mate-additions might be corrupt. OR my local disk <ng0>4 days ago it worked. <ng0>oh no.. I might've run out of diskspace when I pushed. So I really have to fix the local copy I have <ng0>if only I could use guix to use the haskell git-repair instead of all the git integrated tools I tried <efraim>I think I have access to that branch if you need <ng0>so far it's just this one branch.. but because I can't do anything with guix right now (not even via the /run/current-system/… I'll just put in a new disk. <ng0>doesn't help if I fix it but turns out it's my SDD <catonano>summer's over and my silly questions to the help mailing lists are back <dvn->I'm having trouble with TLS in guix <dvn->I recently built and installed guix from the git source <dvn->I can install packages, despite getting this error repeatedly: substitute: warning: TLS 'SERVER NAME' extension not supported <dvn->`guix pull` fails totally <dvn->ng0 told me to file a bug report, but I thought I'd ask here once more <cbaines>catonano, I've just seen you're email on system tests. Do you have something that you are trying to write a test for? <ng0>hrrrrrrrm. git really sucks at recovery methods. there are too many. <ng0>I'm back, but no idea if I can get back the content <ng0>urghh. efraim, for safety reasons could you send me git-format patches of all the commits I made the branch? <ng0>correction: all the commits beyond HEAD <catonano>cbaines: no, I ust wanted to have a rough understanding <catonano>cbaines: my idea was to write a serice for creating a postgresql role, as you suggested <cbaines>The system tests that guix has are in the gnu/tests directory, rather than the tests directory <cbaines>I think the tests in the tests directory are for guix itself as a tool <cbaines>The PostgreSQL service itself hasn't got a system test yet, so writing one might be a good place to start <ng0>seems like my remote is still okay