IRC channel logs


back to list of logs

<rekado>ACTION switches servers for
<christopher74837>rekado: I'm still not sure... I installed nss-certs and sourced the environment variables as described, but am still getting that error
<christopher74837>oh, wait, maybe the daemon is not using the right git version...
<christopher74837>no, same error...
<christopher74837>taking that error message at face value, you would think that git must not have openssl enabled
<str1ngs>you did guix package -i guix?
<str1ngs>if so remove it, and just do guix pull
<christopher74837>str1ngs: I have done that, was I suppose to? I just compiled and installed guix from source
<rekado>str1ngs: that seems unrelated to the issue at hand.
<rekado>christopher74837: I’m sorry, I cannot help now. Hope someone else can assist!
<rekado>ACTION –> zzZ
<str1ngs>christopher74837: nope that's fine. its better just do a git pull
<str1ngs>err guix pull
<str1ngs>when you built guix from source what depends did you build?
<str1ngs>or did you install those with OS packages?
***Guest15178 is now known as apteryx
<vagrantc>so, on one guix install, i run "guix pull" followed by "sudo -i guix pull" and the root one doesn't bother to rebuild it ... but on another machine, root will always rebuild it ... any thoughts?
<vagrantc>on the one machine, they always build the same one (presuming they're building the same git commit) whereas the other machine they don't consistantly build the same guix-latest
<str1ngs>on sure if this is related, but are they both using the same substitute-urls?
<vagrantc>passed with --substitute-urls=""
<str1ngs>I'm not sure then. the building from git commit hash should be the same
<vagrantc>it always is on one system...
<str1ngs>sometimes it does some intermediate building I've noticed, but generally that gets resolved once, and then it's fine
<str1ngs>also that fact it's doing it on the same machine is very odd
<vagrantc>ACTION still needs to figure out when to use "sudo -E guix ..."
<vagrantc>sometimes when i used it, it left root-owned files .config/guix or maybe .guix-profile ... and that caused problems.
<str1ngs>personally I only call guix with sudo, when I pull
<vagrantc>but if i just used "sudo -E guix reconfigure ..." maybe that would work fine
<str1ngs>ah and reconfigure forgot about that
<vagrantc>how does the user get new available packages?
<vagrantc>i think reconfigure only makes sense on guixsd, not guix on a foreign distro
<str1ngs>guix pull provides that
<vagrantc>though it might be pretty exciting on a foreign distro...
<str1ngs>I used guixsd
<str1ngs>err use*
<vagrantc>er, "sudo -E guix system reconfigure ..."
<str1ngs>anyways for the most party you don't need to run guix as sudo. including with pull
<vagrantc>str1ngs: but if you don't run guix pull as the user ... how do they get new guix versions?
<str1ngs>pull is good as root on foreign do to updating the root profile
<vagrantc>< str1ngs> personally I only call guix with sudo, when I pull ?
<vagrantc>in my experience, if i don't run guix pull as the user, i don't get new package versions available for the user
<str1ngs>could be because you are using the guix from the root profile
<vagrantc>basically, i've been doing "guix pull" then "sudo -i guix pull" and then "guix package -u" and "guix system build ..." and "sudo -i guix system reconfigure ..."
<str1ngs>via symlink maybe?
<str1ngs>no sure what you need reconfigure for though?
<vagrantc>guix pull updates ~/.config/guix/latest symlink
<vagrantc>and sudo -i guix pull updates /root/.config/guix/latest symlink
<vagrantc>str1ngs: to update system packages ... largely linux-libre and company
<str1ngs>so you *are* using guixsd?
<vagrantc>well, i've got one Debian install
<vagrantc>but mostly guixsd
<str1ngs>ah so one is guixsd and the other is not?
<str1ngs>talking about the machines in your having issues with
<vagrantc>both of the machines i'm talking about are guixsd
<vagrantc>i have a third machine running debian as the base OS :)
<str1ngs>have you reconfigured the guix-service on either?
<vagrantc>not explicitly...
<str1ngs>specifically the guix-configuration of guix-service-type
<str1ngs>either way it's odd. guix pull on the same machine should just symlink since the inputs and outputs should already exist
<str1ngs>provided you have done it once, for the same git hash
<vagrantc>that's what i thought too
<vagrantc>the machine where it's not working was older ... wonder if there's some lingering bug causing the problem.
<vagrantc>e.g. it was the first machine i installed guixsd ... simply weeks ago!
<str1ngs>possible, because it does do an intermediate build at times.
<str1ngs>do $ find /gnu/ -name guix-daemon
<str1ngs>you should have 0.14.0 in there ?
<vagrantc>many, many, many of them, including at least one 0.14.0
<vagrantc>two 0.14.0 builds
<str1ngs>hmm not sure how to figure what what guix-daemon is being used/
<str1ngs>what's the output of uname -a
<str1ngs>sorry I meant not sure how to figure which guix-daemon is being used.
<vagrantc>why would "uname -a" matter here?
<vagrantc>ls -l /run/current-system/profile/bin/guix-daemon ... i would guess
<str1ngs>I'm just curious as to your kernel version
<str1ngs>should be atleast 4.14.3
<vagrantc>4.14.4 on one machine
<str1ngs>what about the older machine?
<vagrantc>same on the other
<str1ngs>ya I don't think it's system age related. it could be GC related
<vagrantc>the system profile's guix-daemon points to one of the /gnu/store/*-guix-*0.14.0 versions
<str1ngs>ahh do $ /run/current-system/profile/bin/guix-daemon --version
<str1ngs>I have 0.14.0-1.ad4953b
<vagrantc> the same here
<str1ngs>ya so I don't think it's system age
<str1ngs>I thing it's user environment related. but as to what not sure
<str1ngs>since it happens on the same machine, and across users. so the only thing different would be environment or invocation
<vagrantc>across users?
<vagrantc>my user and root ?
<str1ngs>right there different users and possible different environment then
<vagrantc>the invocation is identical with "sudo -i" prefixed for the root invocation
<str1ngs>what about environment variables?
<str1ngs>is do sudo -i\\n then env
<str1ngs>see if something stands out
<vagrantc>GUILE_LOAD_PATH/GUILE_LOAD_COMPILED_PATH is duplicated in the user's env but no different directories there
<vagrantc>but it's the same on the system where everything it working
<apteryx>How can I work around this: ./configure: /bin/sh: bad interpreter: No such file or directory
<apteryx>The configure script is automatically generated at build time by a phase which runs sh
<str1ngs>sh configure
<str1ngs>assuming this is a manual build?
<str1ngs>and that a package you are creating?
<apteryx>I'm writing a package recipe
<apteryx>for emacs-realgud
<str1ngs>you should not need to run autogen I don't think. also can't you just inherit the gnu build system?
<str1ngs>configure should not be generated at build time. it should be generated already. unless you are using a git repo or maintainer
<str1ngs> mode . I would try to use release tarball if emacs-realgud provides one
<apteryx>I'm using "". It comes with an and the and inputs, but the configure script and Makefile needs to be generated (by using I want the Makefile to run the tests.
<str1ngs> odd the release tarball for realgud, does not have a configure script
<str1ngs>that's not how you would normally release the tarball. that's the whole point of autotools
<apteryx>The interesting part is that our autoconf package doesn't produce configure script which runs on Guix.
<str1ngs>anyways that does not help your issue. how you would do this is exec autoconf with sh directly. it should not call ./configure really.
<apteryx>it seems to hardcode /bin/sh at the top, which we don't support.
<str1ngs>autoreconf does not produce a configure?
<apteryx>it even calls it.
<str1ngs>I'd have to look at as to why its doing that
<str1ngs>you are using 1.4.3 tarball?
<apteryx>The link I shared above.
<str1ngs>oh you grabbing it from elpa.. ok
<str1ngs>hmm this version does not have a
<str1ngs>nvm it does
<vagrantc>ACTION waves
<apteryx>Interesting. Running 'sh' from a pure, contained 'emacs-realgud' environment works.
<apteryx>(well, it fails but further)
<str1ngs>that tarball is missing files
<str1ngs>use the release from github IMHO
<str1ngs>also you can forgo running and do autoreconf -iv by hand
<str1ngs>calling configure via can be avoided completely
<apteryx>The generated I could also substitute ./configure to 'sh configure'
<apteryx>in the file. Github is not a nice solution because there are no tags made there. Hunting the correct commit is not fun.
<str1ngs>github has release tarballs
<str1ngs>no 1.4.4 though. elpa is missing
<apteryx>Oh, I was looking at another of rocky's package. emacs-realgud looks better tagged on Github.
<apteryx>Yeah, not sure where 1.4.4 went though.
<str1ngs>he's doing something for elpa release channel. which makes sense for this I guess
<str1ngs>thing is releasing to elpa is not the same as maybe releasing a tarball
<str1ngs>hence why the possible missing
<apteryx>OK, I made progress with the ./configure -> sh configure substitution.
<str1ngs>how did you get around or you using 1.4.3?
<apteryx>I'm using the 1.4.4 tarball from ELPA, which has
<civodul>Hello Guix!
<civodul>oh, glibc vulnerability
<civodul>IIUC core-updates is immune, as well as the grafted glibc in master
<efraim>Who doesn't love a good glibc vulnerability?
<efraim>if I read linux.scm correctly, if I want to feed a custom config file to the kernel I add as an input ("kconfig" ,config)
<efraim>anyway, #debian-arm on OFTC reminded me that an aarch64 kernel needs to be 'IMAGE' and not 'IMAGE.gz' for u-boot's booti on aarch64
<efraim>so time to build a kernel locally again to see what I come up with
<efraim>to customize my xorg modules, do I want '(xorg-configuration-file config => (xorg-configuration (inherit config) (modules "xf86...
<efraim>maybe the second one should also be xorg-configuration-file
<efraim>xorg-configuration follows the pattern of the other ones
<m-o>efraim: yes kconfig input is the way but be careful because your configuration has to provide the modules listed in (gnu system linux-initrd)
<m-o>"usb-storage", "uas" ...
<m-o>you can also provide a custom raw-initrd if you want to avoid that
<OriansJ>sneek: later tell bnw that the stage0 vm is going to be gaining support for 256bit address space and registers.
<OriansJ>sneek: botsnack!
<rekado_>Hi Guix!
<civodul>hey rekado_!
<civodul>rekado_: the new is impressive!
<rekado_>cuirass doesn’t seem to work on the new server, though.
<rekado_>it aborts because it doesn’t find some drv files.
<rekado_>I’m currently copying all drv files from the old server.
<civodul>oh, it might be that cuirass assumes that .drv files listed in its database are valid
<civodul>rekado_: do you use on your cluster?
<rekado_>not with the cluster, but I think it’s used with the tape library system.
<civodul>it seems to be one of the keywords these days
<civodul>ACTION does some profiling to make evaluations cheaper
<mb[m]1>civodul: I tried pulling the wip-pull-reload branch and got this:
<mb[m]1>Still WIP, I presume :)
<civodul>mb[m]1: bah, thanks for testing!
<civodul>mb[m]1: what's your current Git commit?
<mb[m]1>civodul: On that machine it is cf69135d5e6797e566b8bb18419ae9e3c8aeb621.
***parazyd is now known as kek
***kek is now known as parazyd
<civodul>how did we solve the "gzip: unbound variable" issue at ?
<civodul>i'm pretty sure we solved it recently, but i forgot how
<bavier>civodul: I recall you providing a commit id on IRC
<bavier>when you fixed the gzip unbound variable problem
<civodul>ok, so something happened :-)
<efraim>'guix environment guix' is failing for me: guix environment: error: build failed: derivation `/gnu/store/bvh355cajl01xm1x1bdkclmkx0qffszj-guile-2.0.14.drv' has incorrect output `/gnu/store/06y7gah4s74w66v0ba8pfd0azhkdkxhw-guile-2.0.14', should be `/gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14'
<efraim>same story, different hash on aarch64
<efraim>reverting head allows 'guix environment guix' to succeed
<mb[m]1>I currently get this error running `guix pull`: "no code for module (guix profiling)"
<bavier>mb[m]1: civodul was doing some profiling earlier, I wonder if some code got pushed unintentionally
<apteryx_>Is there a way to make 4K more bearable in Icecat?
<apteryx_>(the GUI of the browser itstelf, not video playback -- everything is a bit too small ;)
<cbaines>apteryx_, are you having problems with browser itself, e.g. the menus, or the web pages, or both?
<cbaines>I'm getting an odd error on master: guix environment: error: build failed: derivation `/gnu/store/mng83xyywr30rn8zmy642pqhif4d65xz-guile-2.0.14.drv' has incorrect output `/gnu/store/06y7gah4s74w66v0ba8pfd0azhkdkxhw-guile-2.0.14', should be `/gnu/store/p50qidshrjvvd7d1955navjkijr2fg32-guile-2.0.14'
<cbaines>It seems to be "derivations: 'derivation-hash' assumes inputs are coalesced." as reverting that makes the error go away
<apteryx_>cbaines: it's just the rendering of the browser being too small for this HiDPI screen. I can probably do something about it since Ubuntu manages to scale it's version based on a scaling factor I set in the system parameters.
<vagrantc>ACTION runs into the "no code for module: (guix profiling)" issue as well
<str1ngs>halp it's broke!
<str1ngs>ACTION instigates a riot
<vagrantc>ACTION wishes for "guix pull bisect"
<vagrantc>fortunately, it failed quickly
<mb[m]1>ACTION provides `guix pull bisect`-as-a-service: 252c4083779a488c86e74362b4f3bb4bf927cc67 is the first bad commit.
<vagrantc>mb[m]1: heh. thanks
<mb[m]1>Somewhat interestingly, pulling the commit before ("03870da8 Add (guix profiling).") does not solve the issue.
<str1ngs>something related to I guess
<str1ngs>guix pull --commit=6e119bad60b3c1aa3b13f5b6d7e8c2987d3453d0 works
<str1ngs>which is on commit before
<str1ngs>err one*
<fusion809>Is the latest Guix commit causing problems for others when they run guix pull? Guessing by what str1ngs just said that's an affirmative