IRC channel logs


back to list of logs

***Piece_Maker is now known as Acou_Bass
<efraim>looks like I might need to write off and re-setup my aarch64 build/substitute server, looks like both the SD card and the external HDD are corrupted from too many unexpected power cut offs
<Rukachan>h-hi, I was wondering how could one use a single config file (/etc/config.scm) to install packages via that and keep the whole system up to date in guixsd. I tried doing guix pull && guix system reconfigure /etc/config.scm but every time I call it, it keeps compiling the same things or something so I was wondering if guix system reconfigure overwrites the updates or something. Is there anything else that I
<Rukachan>should use to update (and install packages) for the whole system?
<Rukachan>just moved to guix yesterday so I don't really know much about it
<buenouanq>Rukachan: you only need run guix system reconfigure if you want to change the os with a different config
<buenouanq>the way packages work on a per user basis, there's no way I know of to upgrade everything with a single command
<buenouanq>each user would have to run $ guix pull && guix package -u
<Rukachan>thing is, I am just a single person using my laptop but with a root and a normal user and it would be quite painful for my thinkpad to recompile everything twice every time I want to update
<Rukachan>also, I heard that like nix, guix could install everything and configure a whole system with a single config file or something
<cbaines>Rukachan, if you want to use the same package in multiple different places (e.g. users), it will only need to be fetched/compiled once
<Rukachan>will it? I did guix pull once as the root and once as the user and it compiled everything twice.
<cbaines>that is how Guix pull behaves, but I'm hoping that can be improved at some point
<cbaines>also, if you want root to have the same available packages as your user, you can make /root/.config/guix/latest a symlink to /home/.../.config/guix/latest
<cbaines>that would mean that when you run guix pull as your user, you wouldn't have to run it as root
<Rukachan>I will probably end up doing that
<cbaines>you'd still have to run `guix package -u` as root to update the packages though
<Rukachan>however isn't it possible for guix to read a file like configuration.nix on nixos and install any packages that it needs?
<cbaines>Rukachan, I'm not familiar with NixOS, but you can do something like that
<cbaines>e.g. the operating system configuration can define what packages are available system wide
<cbaines>you can also have manifests that define the packages for a user, but I believe these are separate currently
<Rukachan>I tried doing that before by running guix system reconfigure /etc/config.scm but it acted like it forgot the updates that I did with git pull
<cbaines>tried doing what?
<Rukachan>as the next time I ran git pull as that user it started recompiling everything from the start
<Rukachan>installing packages that I defined in /etc/config.scm
<cbaines>As far as I understand it, as you run `guix system reconfigure` as root, it will use the packages available to the root user, and won't take in to account packages available to your user account
<cbaines>so what you way makes sense, I think? as it sounds like you are saying that `guix system reconfigure` changed more after you ran `guix pull` as root
<Rukachan>not exactly, I ran guix pull as root, when I ran guix pull again as root it refused to do anything as the root was up to date which makes sense. Afterwards I did guix system reconfigure /etc/config.scm as root and then I ran guix pull again as root however this time it started acting like the first guix pull and began recompiling everything like the first guix pull had never had happened.
<cbaines>Rukachan, `guix pull` will update you to what is in the master branch of the guix git repository. Someone may have pushed some new commits in the time between you running guix pull, and it doing nothing, and running guix pull again.
<Rukachan>both of these times it said that it was compiling 622 files
<Rukachan>but thing is, I repeated the process two more times and the same thing happened
<cbaines>Hmm, there might be something I don't know about guix pull...
<Rukachan>do you also use system reconfigure to install packages?
<Rukachan>or just guix package -i?
<cbaines>I rarely use guix system reconfigure, I prefer to use guix package -i
<Rukachan>I will try that then but with symlinked user guix profiles to the root one
<cbaines>I would do it the other way around normally, so symlinking the root /root/.config/guix/latest to the user account you normally use
<cbaines>but, just because I feel that would be slightly more convinient
<Rukachan>that would work too I guess
<Rukachan>yeah, I will try that, thanks again
<insommiack>Hi guix! I would like to install postgresql and postgis in the same definition package because postgis need to access to the directory share of postgresql. I acheive to unpack the source of postgis in the directory output of postgresql and i would like to create a phase to launch the make of postgis but i didn't acheive to acccess to the directory where its unpacked.. have some ideas?
<cbaines>insommiack, ideally, it would be possible to use PostGIS without mixing it in to the PostgreSQL package, but I'm not sure if this has been figured out yet
<insommiack>the problem is postgis need to put file in share directory of postgresql, so when postgresql is install ine the store (beacuse i've putted it in propagated-inputs), the access is denied to this directory
<mekeor>is there some kind of configuration or environment variable for postgresql to specify an alternative path for postgis, replacing the share/ directory?, insommiack
<mekeor>also, it might be helpful to look into the nix-packages of those applications
<cbaines>Is there a postgis package for Guix yet?
<mekeor>mekeor: i think there's no postgis package for nix yet
<insommiack>yes I thinked to move the share directory but this will impact if i need to use roll back because share will not be in the store and it will not depend of the version use
<insommiack>no for guix but nix yes
<mekeor>where is the postgis package definition for nix, insommiack?
<insommiack>but in nix package, they use a commmand, which doesn't exist in guix to allow the right to write in the directory of postgresql
<mekeor>really? that doesn't sound like functional package managing
<civodul>Hello Guix!
<cbaines>good morning :)
<civodul>hey cbaines :-)
<solene>hello, what can I do with this package conflict ? I want to install glu...
<cbaines>solene, as the version of mesa propagated from gtk+ is older, you could try first upgrading the gtk+ package?
<solene>cbaines: I'm trying guix pull && guix package -u now, we will see :)
<efraim>bah, fixing qemu-2.3.0 for afl is annoying, i'll put that off for later
<rekado>solene: I recommend using manifests instead of repeatedly modifying your profile package per package.
<efraim>can I pass a manifest to `guix build'? `guix build --help' doesn't seem to suggest that
<civodul>efraim: i don't think so
<solene>rekado: I'm using guix package -i to install, isn't the good way ?
<efraim>according to debian-security our version of connman is safe against CVE-2017-12865
<civodul>rekado: interesting study on reproducibility:
<cbaines>I'm seeing quite a few gzip: stdin: unexpected end of file errors from
<civodul>yeah there are truncated things, i don't know why
<civodul>i've seen that for linux-libre
<civodul>and i can't find those truncated items on
<civodul>and really, is nginx caching truncated items? it could see that they're truncated and not cache them
<roelj>What's the 'test-lock' process during builds? Is it something from autotools?
<civodul>gnulib and gettext
<civodul>it hangs on many-core machines
<civodul>though that's supposed to be fixed now (core-updates)
<roelj>it hangs, as in, it will hang forever, or will it eventually return?
<civodul>hangs "forever"
<civodul>on today's master?
<civodul>which package?
<roelj>I think libunistring. I ran 'guix environment --pure guix --ad-hoc ncurses'.
<roelj>The only build in /tmp/guix-build-* was libunistring.
<roelj>Would 'guix build gettext --max-jobs=1' get around it? (replacing 'gettext' with 'gnulib' and 'libunistring' in the command if those are affected)
<civodul>on today's master?
<civodul>there's no real workaround
<civodul>because i think the test uses as many cores as it sees
<civodul>but libunistring does have a patch for this in current master
<roelj>Hmm. I'll keep an eye on 'top' to see waht happens.
<roelj>It's building guile now.. It confuses me. I am running 'guix build gettext --max-jobs=1'.
<civodul>right so maybe it just took time
<civodul>see the comments in there
<civodul>cbaines: you familiar with nginx caching? :-)
<civodul> is truncated
<civodul>yet i cannot find a cached item on disk for it
<civodul>but it's definitely cached because the request doesn't reach
<civodul>any idea?
<sshguj>Hi! How to indicate in mi config.scm a swap device encrypted? English Spanish In the manual says it is possible, but does not give an example, someone could give me an example? Thanks guix
<civodul>hi sshguj!
<civodul>sshguj: currently it's incovenient: you have to use a cache file stored in your encrypted device
<civodul>like "/swap", if root is encrypted
<cbaines>civodul, I don't have any ideas about the caching issue unfortunately
<roelj>civodul: Maybe restart the nginx service so that you can be sure it's not cached in memory..?
<sshguj>Ok, Currently it is not possible to use in "swap-devices" a encrypted partition?
<civodul>ooh hmm
<civodul>sshguj: right
<sshguj>Ok, thanks civodul!
<civodul>actually the truncated thing isn't cached, it's just nginx on mirror.* that stops downloading from hydra early on
<civodul>firewall issue?
<cbaines>What do you mean by early on?
<civodul>after a few thousand bytes, it closes the connection somehow
<cbaines>is it the mirror.conf and mirror-locations.conf that are being used here?
<civodul>yes, in guix-maintenance.git
<civodul>strangely, "wget -O /dev/null" on mirror succeeds
<civodul>which rules out the firewall issue
<civodul>" (28: No space left on device) while reading upstream"
<roelj>That could explain things :)
<efraim>gpg-2.2.0 released
<efraim>its the new stable, so i'm thinking new gpg-2.2, and then gpg@2.1.23 will update at some point to 2.3.x or something
<efraim>2.0 series doesn't hit EOL until end of this year
<civodul>so, truncated nar problem solved!
<civodul>we really need something like Prometheus to monitor those machines :-)
<cbaines>yep, I'm planning to try and spend some time looking at Go stuff this week. I think I spotted some patches that relate to other Go package.
<civodul>heheh, cool
<civodul>rekado: on mobile Scheme code & serialization (seen on #scheme):
<cbaines>right now, I'm trying to get caff from the signing-party package working.... I forget how many perl packages I've had to add, and I still haven't got it working yet
<efraim>its a very old version, doesn't compile on aarch64
<efraim>new plan, update gnupg@2.1 to 2.2, when 2.3.x comes out add 2.2 as a new package
<rekado>civodul: thanks for the links!
<rekado> currently has very few substitutes
<rekado>interestingly the build hosts don’t seem all that busy
<rekado>a couple of them have a considerable number of zombie processes.
<civodul>rekado: we should take a lot at offload performance
<civodul>i vaguely remember that archive import is terribly slow
<civodul>the zombies come from what command?
<cbaines>I'm looking at upgrading the signing-party package, but I've got stuck with a generated configure script as it has /bin/sh as the shebang, any ideas how to get autotools not to do this?
<roelj>cbaines: Normally, if the configure script is generated (with autoreconf) inside the build environment, it wouldn't do that. Is /bin/sh hardcoded somewhere? If so, you could (substitute* ...) it out.
<cbaines>roelj, I don't think its hardcoded, but autoreconf is being run in the build phase, and not directly by the gnu-build-system (if that is something which it does).
<roelj>cbaines: That is odd. It shouldn't produce /bin/sh then. Is the configure script already in the source tarball? Because then it's pre-generated. Running "autoreconf -ivf" after the unpack phase should then solve that problem.
<cbaines>It's not, there is a file though
<cbaines>The Makefile runs autoreconf -f -i
<roelj>Do you have a link to the source tarball for me?
<rekado>civodul: the zombies appear to be the result of building gfortran, glibc-2.24, and/or gcc-5.
<rekado>there are zombies for “bash”, “conftest”, “xg++”, etc
<cbaines>roelj, yep, I'm trying to upgrade the signing-party package, the new source archive is here
<cbaines>Its keyanalyze/Makefile that runs autoreconf
<civodul>rekado: ok, they'll be reaped when the derivation build terminates
<civodul>cbaines: use 'autoconf-wrapper', not 'autoconf'
<rekado>I think I should increase the number of parallel build jobs on berlin.
<rekado>it’s currently at 2.
<rekado>(per node)
<roelj>rekado: How many threads does each node have?
<rekado>each has 8 cores (2 sockets, 4 cores per socket, 1 thread per core)
<cbaines>civodul, ok, thanks, I think that has helped :)
<civodul>cool :-)
<roelj>rekado: So, why did you configure it with (only) 2 parallel build jobs?
<efraim>one for each socket
<rekado>I wasn’t sure what the build performance would be.
<rekado>a single build doesn’t have to only use one core, no?
<efraim>only if its a python package
<efraim>unless you meant socket, AFAIK the only reason to keep it on one socket is the cost of moving data
<efraim>but all python packages seem to be built with only one core
<rekado>my thinking was that a single build might benefit from having more cores
<rekado>i.e. faster individual builds at the expense of concurrent builds
<civodul>sounds reasonable to me, up to 4 cores per build
<roelj>It'd be interesting to see benchmarks of this.
<rekado>yes, we do need time series data for all these servers
<efraim>I assume it'd depend on the amount of L2/3 cache per core
<roelj>Damnit, a build failure for tar. I've been running into trouble with Guix all day today.
<efraim>timeout on the sparsefile test?
<lich-li>how hard would porting elogind to slackware be?
<cbaines>lich-li, I don't know. I'm guessing not too hard, but I know nothing about Slackware.
<lich-li>cbaines: it does not have any openRC related dependencies?
<cbaines>lich-li, what do you mean by openRC related, I think its completely independent from openRC, as far as I'm aware
<lich-li>cbaines: as if there is something very gentoo/guix related with elogind making it harder to port to other non-systemd distros
<lich-li>I'll see
<lich-li>if it will work
<cbaines>lich-li, I don't believe its dependent on anything Guix specific
<cbaines>here is the service type definition in Guix, in case that is helpful
<lich-li>it would be a major thing for slackware if we got wayland working
<efraim>there are a couple of places where we use sed-like magic to replace systemd with elogind
<apteryx[m]>Hi! My system is often running out of its 4GiB of RAM; this is normal, I'm pushing it. What I find silly, is that instead of killing the process which goes out of memory, it prefers to waste hours trashing my SSD drive. I don't understand why as I don't even have swap turned on. It's really annoying since it becomes totally unresponsive and I can't kill the process myself.
<apteryx[m]>I have to force restart the machine and risk loosing data :/
<apteryx[m]>Maybe there's a Linux kernel config flag causing such behavior?
<cbaines>apteryx[m], I don't know much about this, but do you know about the swappiness setting?
<Apteryx>cbaines: thanks for that. Do you know if Linux can swap even in the absence of a configured swap file/partition?
<pmikkelsen>good evening guix
<cbaines>Apteryx, I wouldn't have guessed so, but it seems like that is what you are experiencing
<cbaines>hey pmikkelsen :)
<Apteryx>indeed! I'm thinking it might use a swap file under /tmp even when none was configured...
<rekado>Apteryx: I’m having pretty much the same problem.
<jonsger>does guixsd work out-of-the-box with an AMD graphic card?
<jonsger>or is it unsupported by linux-libre
<cbaines>jonsger, I would hope that it would work initially to some degree
<jonsger>so no?
<jonsger>my pc hangs during boot "fb: switching to amdgpudrmfb from EFI VGA
<cbaines>I don't know much about the drivers in Linux for AMD graphics cards, you'd have to look up the details of the relevant driver
<cbaines>jonsger, can you tell if that message is coming from linux, or something later like X?
<jonsger>[ 10.093...] <-- sign of linux kernel?
<cbaines>jonsger, probably, searching for that error suggests that adding nomodeset to the linux boot arguments would at least get the system to boot
<jonsger>cbaines: thx now I'm on root@gnu :)
<cbaines>great :)
<ng0>Since when is adding a dependency but keeping the tests disabled so that someone can fix them later a requirement for patches to land? It improves the current "FIXME" status of this perl package.
<Apteryx>rekado: it seems no one recommends running without a swap, at least that's what I got from #linux just now.
<ng0>the BODY of a patch email is occasionally just a comment. If something is WIP I explicitly state that it is.
<ng0>two long lines for: how do I reopen a patch again?
<ng0> ?
<Apteryx>I'm not sure I'm believing this, as I've used swap before and typically it wouldnt be used much if at all and when the memory would be exhausted the system would trash and freeze all the same. Linux just doesn't seem very good at handling memory exhaustion, at least from a desktop usage perspective!
<jonsger>what does "in procdure module-lookup: unbound variable : grub-efi" does mean? (reported by guix system init...)
<Apteryx>jonsger: your AMD might run for 2D and no accel without firmware blobs if you are lucky. Actually it might help to not load the blob as the amdgpu driver doesn't seem uite done yet.
<cbaines>ng0, I'm not sure how to use debbugs, but I can't help with that. But regarding the patch, s/is/are in "A large number of tests is failing" would be better english, and yes, my brief opinion on it is that it is a small improvement to the package.
<ng0>I believe the command goes in the body
<jonsger>Apteryx: graphic works basically. I have problems with guix system init
<cbaines>ng0, I'd recommend saying explicitly what the change/improvement is though, as this is useful for those reviewing and for history. I guess it's pretty obvious in this case, but I think it helps to avoid confusion.
<ng0>I started doing that, but occasionally I don't.
<jonsger>(bootloader (grub-configuration (grub grub-efi)
<jonsger> (device "/dev/sda1")))
<jonsger>still the right way to configure uefi
<civodul>jonsger: it's correct and should work, but this syntax is now deprecated
<ng0>cbaines: + `(#:tests? #f)) ;FIXME: A large number of tests are failing.
<civodul>one should use 'bootloader-configuration' instead of 'grub-configuration' (see the current manual)
<jonsger>civodul: where is the right position in the manual? I'm a little bit confused
<civodul>it's under System Configuration > Bootloader Configuration
<cbaines>ng0, Good good, that now reads better :)
<jonsger>there is just GRUB-configuration civodul
<Gamayun>civodul: The one on the website is still a bit behind?
<ng0>And now I should stop working. Hit in the face by bureaucracy was exhausting today.
<civodul>Gamayun: right, it corresponds to the release
<ng0>the one on the website is fixed on the release number
<civodul>jonsger: for the current manual, you should check what you have on your computer
<civodul>so "info guix", or build the HTML pages if you prefer
<jonsger>there is still grub-configuration. I downloaded the 0.13 usb installer
<ng0>oh, one last thing. What are your thoughts on curl 7.55.1? it would drop one patch and a substitute phase we have for 7.55.0. 7.55.0 was effectively released in a way that it can't build without fixes.
<civodul>jonsger: oh so in 0.13 what you wrote is exactly what you have to use
<civodul>and again, it also works in current master, it's just deprecated
<ng0>yeah. (I didn't even notice so far) :)
<jonsger>so I have no idea whats wrong with guix system init
<Gamayun>ACTION makes a note to change this before next guix system reconfigure
<jonsger>is there a way to upload to a paste service from guixsd
<ng0>for example wgetpaste
<jonsger>strange. it's not preinstalled
<ng0>guix package -i wgetpaste
<jonsger>yeah I did it
<ng0>I use something like: curl -F "c=@${1:--}"
<jonsger>curl is also not preinstalled
<ng0>it should be in the store as part of the base.
<ng0>you just need to make it available
<jonsger>curl: server certificate verification failed. cafile: none
<jonsger>do I have to set env vars for https?
<jonsger>thats my config:
<cbaines>jonsger, I think installing openssl in your profile might help... very much a guess though
<cbaines>anyway, I need to get some sleep, I'll finish writing descriptions for perl packages in the morning....
<ng0>on the other comment in the email: I'd help reviewing the backlog, but I'm between existencial crisis the next week(s) and working out some project related stuff and starting soon preparation math courses full time, so reviewing might happen again.. one day.. just not in the current mind on the edge state :)
<ng0>efraim: I try to send in updated patches of MATE before the 11th