IRC channel logs


back to list of logs

<sadiq[m]>can I get Ludo here?
<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/" error when trying to compile gnome-todo
<zacts>does mark_weaver still hang out here?
<sadiq[m]>how can I force reinstall a package?
<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
<sadiq[m]>filed a bug for that:
<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>that should be enough, humm
<wingo>can you paste your package somewhere?
<sadiq[m]>wingo: the package is committed to git:
<wingo>ok :) i must need to update
<wingo>i don't know, all that looks good
<sadiq[m]>Well. the source I used was from git master of gnome-todo ( I was supposed to test something before it got merged. Anyway he merged the changes
<sadiq[m]>I feel the bad commit would be
<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>Hello Guix!
<civodul>jherrlin: the default is always the latest generation
<civodul>the previous ones are here in case you want to roll back
<jherrlin>Hmm, okey
<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>no no, it's automatically generated
<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>nice! thanks! will be carefull!
<civodul>but still
<jherrlin>but one thing, when i look at the paste i provided
<jherrlin>the default menu item and submenu item #25
<jherrlin>they dont look the same
<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 ;)
<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>Got it.
<efraim>i'm here :)
<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 ;)
<efraim>sneek: botsnack
<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
<sadiq[m]>efraim: may be not mine. Hi. can you explain why this was done: (using lib64 path)
<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
<efraim>no, there's no bin dir
<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
<sadiq[m]>or am I missing something?
<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>still trys to install to /lib64
<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:
***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>Automake is in Perl :-)
<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
<rekado_>ACTION updates R
<civodul>rekado_: really happy we have 'package->code'!
<civodul>and the JSON importer, too
<civodul>soon we can change importers to return package objects
<civodul>and craziness will ensue :-)
<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
<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>sounds good!
<civodul>so we have thanks to roelj
<civodul>we should improve the column widths and all
<civodul>but it looks pretty good already!
<janneke>beautiful! what's hpc'ish about it?
<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
<civodul>and of course, run it on
***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
<efraim>With the one I have locally
<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
<ng0>i doubt that though
<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
<catonano>cbaines: thanks
<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
<ng0>well... shit :(
<ng0>ACTION eats git