<rekado>ACTION switches servers for berlin.guixsd.org <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>taking that error message at face value, you would think that git must not have openssl enabled <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! <str1ngs>christopher74837: nope that's fine. its better just do a git 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? <str1ngs>I'm not sure then. the building from git commit hash should be the same <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 <vagrantc>though it might be pretty exciting on a foreign distro... <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>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>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? <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>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. <vagrantc>many, many, many of them, including at least one 0.14.0 <str1ngs>hmm not sure how to figure what what guix-daemon is being used/ <str1ngs>sorry I meant not sure how to figure which guix-daemon is being used. <vagrantc>ls -l /run/current-system/profile/bin/guix-daemon ... i would guess <str1ngs>I'm just curious as to your kernel version <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 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 <str1ngs>right there different users and possible different environment then <vagrantc>the invocation is identical with "sudo -i" prefixed for the root invocation <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: autogen.sh: ./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 autogen.sh <str1ngs>and that a package you are creating? <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 <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? <str1ngs>I'd have to look at configure.ac as to why its doing that <str1ngs>hmm this version does not have a configure.ac <apteryx>Interesting. Running 'sh autogen.sh' from a pure, contained 'emacs-realgud' environment works. <str1ngs>also you can forgo running autogen.sh and do autoreconf -iv by hand <str1ngs>calling configure via autogen.sh can be avoided completely <apteryx>The generated I could also substitute ./configure to 'sh configure' <apteryx>in the autogen.sh file. Github is not a nice solution because there are no tags made there. Hunting the correct commit is not fun. <str1ngs>no 1.4.4 though. elpa is missing common.mk <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 common.mk <apteryx>OK, I made progress with the ./configure -> sh configure substitution. <str1ngs>how did you get around common.mk? or you using 1.4.3? <apteryx>I'm using the 1.4.4 tarball from ELPA, which has common.mk <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. <civodul>rekado_: the new berlin.guixsd.org 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 <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 <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>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 <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 <mb[m]1>ACTION provides `guix pull bisect`-as-a-service: 252c4083779a488c86e74362b4f3bb4bf927cc67 is the first bad commit. <mb[m]1>Somewhat interestingly, pulling the commit before ("03870da8 Add (guix profiling).") does not solve the issue. <str1ngs>guix pull --commit=6e119bad60b3c1aa3b13f5b6d7e8c2987d3453d0 works <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