<ekaitz>nckx: don't do this to me... now I want to port the daemon to scheme... <raghavgururajan>Folks! Curl doesn't connect to internet in Guix on foriegn-distro. Thoughts? <raghavgururajan>ERROR[#01]: Couldn't curl website. Please check your network and try again. <leoprikler>raghavgururajan: maybe a certificate thing? try plain http first *raghavgururajan suspects application setup - glibc and x.509 <leoprikler>or rather is this even curl itself or are you using it as a dependency elsewhere? <bmgxc9>I am getting an unbound variable issue with emacs-guix %max-returned-list-size <bmgxc9>Not sure who (or if) emacs-guix is maintained, but I thought id try here ***brettgilio[m] is now known as brettgilio
<sbp>bmgxc9: do you have more details? <bmgxc9>sbp: It is any time I try to search from a package. *The_tubular loves to see progress <wirez>can guix import .debs into guix? <wirez>like, make guix packages. i think .scm? <brettgilio>I moved into education and out of software engineering, so I am just now reacquainting myself to everything I missed :) <brettgilio>A few friends and I are involved in pushing for more libre software in education. <brettgilio>Educational research, yeah. I am in the works of one on cat theory for secondary ed. <sawshep>How do I enable the ability to run arbitrary binaries? <brettgilio>sawshep You need to patch the binaries using patchelf <apteryx>it gives you by default a dot graph you can render with the 'dot' tool, as SVG or PDF or otherwise <apteryx>nckx: is there a reason the code behind that HPC link isn't used for the Guix packages page directly? <The_tubular>apteryx umm, I read on guix graph, it might not be what I want <The_tubular>I want basically why all of my packages are on my system <brettgilio>The_tubular: It actually is what you want. You want to pass all of your installed packages to guix graph <The_tubular>Is there a shortcut that I can take, or do i need to type them all ? <brettgilio>There might be something about it in the cookbook <brettgilio>I am having an issue using gcc from guix to compile ocaml from source <brettgilio># configure: error: C compiler cannot create executables <brettgilio>Interesting, it passe when in `guix environment ocaml` <brettgilio>`ld: cannot find crt1.o: No such file or directory` this is the curious issue im getting <raghavgururajan>nckx and leoprikler: Pipe-Viewer (#49210) actually works. It was a stale config file on my system that was causing trouble. Let me know if the patch-set (v3) looks good. ***notzmv is now known as [deleted]
<zacchae[m]>is the guix user manual generated from an org file? And if so, where can that file be found? <jerofff>Tell me how to run the Libvirt daemon, please <jerofff>I don't understand in which file should I write this? <brettgilio>If that is where you keep your system config, yes. <raghavgururajan>apteryx: Can have a look at #49238? If it looks good to you, I can push it. :) <jerofff>After gui system reconfigure, I get "/etc/config. sam:33:2 error (service libvirt-service-type (libvirt-configuration (unix-sock-group "libvirt") (tls-port "16555"))) invalid field specifier" <brettgilio>You need to load the definition of the libvirt service, in other words. <brettgilio>Otherwise guile has no idea what youre talking about. <jerofff>(use-module gis services virtualization) is this also in the system configuration file? <jerofff>This is me by accident. I have the same error coming out "/etc/config.scm:33:2 error: (use-module guix services virtualization): invalid field specifier" <jerofff>Thanks for the help. Can you tell me the manual for gnu virtualization? <apteryx>jerofff: you are missing some parens; it should be (use-modules (guix services virtualization)) <apteryx>there's also a shorthand available in the environment reading the operating system declaration: (use-service-modules virtualization something-else ...) <apteryx>and its complement (use-package-modules ...) <apteryx>raghavgururajan: hi raghav! Perhaps tomorrow, it's late :-) <raghavgururajan>jerofff: Could you share your config.scm (with sensitive-stuff redacted) using paste-bin? <brettgilio>Scheme is very picky about scope and parentheses <jerofff>I have started the reconfiguration. Thank you very much raghavgururajan, brendyn <MysteriousSilver>I tried `(add-to-list 'yas-snippet-dirs "~/guix/etc/snippets")` but package<TAB> does nothing in scheme mode <brettgilio>MysteriousSilver do you have the yas minor mode onm *MysteriousSilver looks down in shame <brettgilio>If they were easy, we wouldnt need a "science" for them. <brettgilio>I cant sleep. I have a dentist appointment tomorrow for a broken tooth, and that anxiety is all kinds of fun. ***o is now known as niko
<leoprikler>raghavgururajan: I don't understand enough about pipe-viewer to tell you whether that's enough substitutes or not. <leoprikler>I do welcome however, that the input labels are fixed now, that's a good thing :) ***Kimapr6 is now known as Kimapr
<boeg>what do i need to get dbus properly running? I'm just running a %base-services system where i have added stuff. I do have dbus installed and dbus-service as part of my services <boeg>apps just says they cant find a bus to connect to <boeg>apapsch: thank you, i just thought that guix must be capable of doing it itself <apapsch>boeg: i guess the desktop environments do it automatically, though in your case with just the %base-services it must be launched manually <boeg>ah of course, makes sense <sneek>Welcome back mothacehe, you have 3 messages! <sneek>mothacehe, nckx says: Would it be hard to implement a ‘retry’ button in the installer? It could come with a nice disclaimer that success (or even sane state) can't be guaranteed, but anything is better than having to restart from scratch. <sneek>mothacehe, nckx says: Correction: that exists, but it ‘blows up with /mnt missing or sometihng’, which sounds broken… <mothacehe>nckx: yeah, I think that 'retrying' past the partitioning step is broken indeed. Feel free to report it :) <sarna>hey, I keep getting the warning about locales despite setting everything up.. I tried fixes I found on reddit, they didn't work (installing `glibc-locales` and `glibc-utf8-locales` as root, restarting everything) <ngz>I had to modify the guix-daemon.service file <ngz>and add this: "Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8 <ngz>I don't know if install script does it automatically nowadays. <sarna>ngz: I have it there though! <sarna>I have the `GUIX_PROFILE` and `GUIX_LOCPATH` stuff in my `.bashrc` too, should I have them in `.profile` or something? no idea.. <sarna>`sudo guix` spews the same warning >.> <ngz>You shouldn't have any Guix-related environment variable set in ".bashrc", but I don't think that's related to your issue. <sarna>where should I set it? I'm using ubuntu <sarna>well that didn't help either :< <maximed_>sarna: Maybe install glibc-locales, glibc-utf8-locales as the "regular" user (not root) <maximed_>If you install "glibc-locales" as root, it's the "root" user that will get the locales <maximed_>"root" doesn't have any special status in #guix, besides the usual "root can do everything" (but that's really an operating system/kernel(?) thing) <maximed_>-- correction, it appears that on foreign distro's, the guix daemon binary is taken from the profile of the root user (didn't verify closely though) <sarna>maximed_: I installed them as both <sarna>I added stuff to `/etc/profile` that raghavgururajan talked about, let me reboot.. <maximed_>Also installing as root seems unnecessary, but can't hurt I suppose. Also possibly useful if you occassionaly use "sudo", "su" or otherwise log-in as the root user <sarna>the warning persists, both on `guix` and `sudo guix` <sarna>`echo $GUIX_LOCPATH` gets me `/home/me/.guix-profile/lib/locale` <sarna>that `/etc/profile` stuff didn't get loaded, on root `$GUIX_LOCPATH` is empty <maximed_>what is the output of "ls $GUIX_LOCPATH/2.31"? <maximed_>On my system it is ca_ES.utf8/ de_DE.utf8/ en_CA.utf8/ ... <maximed_>can you post the exact warning on paste.debian.net? <maximed_>e.g., "LC_ALL=en_PIRATE.utf-8 guix" gives the same warning on my system <maximed_>you could try "LC_ALL=nl_NL.utf-8 guix --help" <maximed_>that should output "Gebruik: guix COMMANDO ARGS..." <zap>hello guix! what can "guix pull: error: corrupt input while restoring archive from #<closed: file b3187d20>" mean? <zap>Im geting it during guix pull <mekeor[m]>zap: do you only use the official default guix channel? <mekeor[m]>or does that error originate in a custom channel? <sarna>maximed_: `$LC_ALL` is `C.UTF-8`, `$LANG` is the same <ekaitz>zap: I think that's an error that appeared a lot recently but it's fixed, run the pull again until it works and you shouldn't see the error again <sneek>ekaitz, nckx says: …TWO beer-equivalents! <sarna>maximed_: what's funny is that `LC_ALL=nl_NL.utf-8 guix --help` outputs help that's 1. without the warning 2. in english <ekaitz>danialbehzadi[m]: I'd say you can package stuff in Debian packages, but I may be just inventing everything <mekeor[m]>> <@danialbehzadi:mozilla.org> I saw this on news: "New ‘deb’ format for the ‘guix pack’ command". <mekeor[m]>i think it means you can run "guix pack some-package --format deb" or something similar on your guix-machine, then copy the resulting some-package.deb to a debian machine and run "dpkg -i some-package-deb" on there <maximed_>sarna: (setlocale LC_ALL "C.UTF-8") (in a Guile REPL) raises an error "Invalid argument". It appears that C.UTF-8 is not a valid locale <ekaitz>danialbehzadi[m]: run guix pack --list-formats <ekaitz>danialbehzadi[m]: it explains everything there, it's basically what we said <mekeor[m]><mekeor[m] "> <@danialbehzadi:mozilla.org> I"> sorry. it's "--format=deb" <maximed_>"guix --help" is not completely translated to Dutch, but it should at least be partially translated <zap>mekeor[m]: yep its from official channel <zap>ekaitz: good news :) <mekeor[m]>zap: i'm not sure. i would guess that it could be a network error. did you try to re-run guix-pull? :D <sarna>maximed_: I set a correct one, let me try relogging <maximed_>just run "LC_ALL=en_US.utf-8 guix --help" in some terminal <zap>mekeor[m]: ekaitz suggests its a fixed issue. Ill rerun guix pull in a moment. It took more than two hours on my ODROID xu4 to get to the error though.. <sarna>maximed_: I put it in `.profile` and that *should* get applied when you log in, IIRC. but it didn't work anyway. I set it in `.bashrc` instead and it works <sarna>thanks for your help! I hate ubuntu!! <mekeor[m]>sarna: did you try .bash_profile, too? i don't know if bash sources .profile if .bash_profile is existent <sarna>mekeor[m]: `.bash_profile` never loaded for me on this system haha, but thanks <sarna>I always put stuff in `.bashrc` because otherwise it gets real funky <maximed_>sneek: later tell mothacehe: I sent a v3 <leoprikler>I think most bashrc stuff are bad decisions piled onto bad decisions piled onto cargo cult programming <leoprikler>the reason your stuff breaks when using bash_profile instead of bashrc probably has to do with other stuff that shouldn't be in bashrc eitehr <nckx>sarna: Erm, OK, just be aware that it's not supported and will cause bugs in some scenarios. <nckx>If that ever happens, please remember to mention it when asking for help. ☺ <mekeor[m]>is there any small, quiet, energy-efficient, cheap, linux-libre/guix-system compatible (single board) computer with at least 8GB memory, you'd recommend? <sarna>weird things, like setting my locale? <leoprikler>I mean, setting your locale should probably also be done in bash_profile, so… <sarna>except I'm using ubuntu, and "Using .bash_profile does not work on Ubuntu. It uses Dash as a GUI login shell, not Bash, so bash_profile is not read." <sarna>last time it didn't work, but I just relogged. I'll try later with a full reboot <nckx>sarna: Putting non-.bashrc things into .bashrc in general. As leoprikler says, one such quick hack often leads to another. Putting LC_ALL=foo in .bashrc already makes ‘LC_ALL=foo guix environment hello -- sh -c 'echo $LC_ALL' act unexpectedly—which, granted, you probably don't care about—but it's a gateway drug, friend. <nckx><It uses Dash as a GUI login shell, not Bash, so bash_profile is not read.> But it reads .bashrc? o_O <nckx>Or you spawn bash later? <nckx>The first LC_ALL=foo should be LC_ALL=bar or what I wrote makes even less sense than unual but you get the point. <sarna>I put it in my `.profile` and rebooted, as I expected it didn't work at all <sarna>I'll keep it in `.bashrc`, I don't have the time to do it "cleanly" - sorry <nckx>That's fine; it's your problem. Just mention it. <sarna>yea I'll keep it in mind, thanks <mothacehe>nckx: interesting. What's the QEMU command line you are using? <sneek>mothacehe, you have 1 message! <sneek>mothacehe, maximed_ says: I sent a v3 <nckx>mothacehe: qemu-img create -f qcow2 ~/sda 5G && $($guix system vm gnu/system/install.scm) -m 3G -nic user -hda ~/sda -bios $($guix build ovmf)/share/firmware/ovmf_x64.bin <mothacehe>oh that would be because of "system vm" that breaks the installation device detection <mothacehe>i'll investigate it, "system image" should work in the meantime <nckx>So I'm expected to build an image and boot from that? <nckx><i'll investigate it> Thanks. <Guest4977>hello can you help me pls to setup networking on my pinebook pro? <Guest4977>whenever I try to do dhclient eth0 it fails with <Guest4977>.../libexec/dhclient-script, ...): Exec format error <nckx>Guest4977: What does ‘file <full name of>/libexec/dhclient-script’ say? <nckx>Found it here; it is just a bash script. That's odd. <Guest4977>nckx: I think it could be en issue with the header of this script <nckx>Yes, the file command will print the interpreter (bash-minimal). Check whether it runs. <Guest4977>in #!<there is hardcoded location to bash-minimal> <nckx>‘# No guarantees about this. I'm a novice at the details of Linux networking.’ ☺ <Guest4977>unfortunately no and I cannot edit this script <nckx>Guest4977: What does it say? <nckx>If it's exec format error, that's the bug that needs to be fixed. <maximed_>ALso, wha does "objdump -x <location to bash-minimal>" say? <maximed_>maybe somehow the architecture is wrong? Would be surprised though <maximed_>unless you've been cross-compiling stuff <nckx>(Use pastebin in topic.) <nckx>Then it would still be wrong but very unsurprising ☺ <nckx>Then, again, what does ‘file …/bash’ say. <nckx>Being the bash from the shebang. <Guest4977>...bash-minimal-5.0.16/bin/bash: cannot execute binary file: exec format error <maximed_>That's possibly an wrong architecture error, or maybe something else? Can you als do "file .../bash" as requested by nckx <nckx>Anyone know any other poor-people's-architecture-sniffers? <maximed_>Run "guix repl". From there, run (use-modules (guix)) (%current-system) <nckx>Ooh right Guix has ELF bindings good one. <maximed_>Also, if you post the whole store path "/gnu/store/...bash-minimal-VERSION/bin/bash", then we can use "guix substitute" to get that bash <maximed_>That is, did you pass "--target=SOMETHING" to "guix system blabla..." <Guest4977>yes I've build the image on x86 machine without any errors <Guest4977>what's the proper way to cross-compile it than? <maximed_>So ‘we’ (nckx & me) would have to look at "guix build isc-dhcp --target=aarch64-linux-gnu" <maximed_>Guest4977: that is the proper way to cross-compile AFAIK <maximed_>is it just that many package definitions have cross-compilation bugs <maximed_>I'm cross-compiling isc-dhcp (that's were dhclient comes from) to determine the issue <maximed_>I looked at the package definition, and it appears 'wrap-program' is used without a "bash-minimal" in 'inputs'. <Guest4977>anyway the image is booting properly it would be nice to add some more debugging tools into the pinebook-pro-scm <maximed_>The result would be that the implicit native bash-minimal from gnu-build-system is used <maximed_>And contemplate writing a linter (see "guix lint") automatically diagnosing these issues (using wrap-program without "bash-minimal" in inputs). <Guest4977>btw. in bash script in general is not better to use header like '#!/usr/bin/env bash' instead of '#!<hardcoded location to bash> ? <maximed_>fwiw, if you get internet access anyway somehow, you can do "guix system reconfigure blabla.scm" on your pinebook. THen the issue should dissappear <Guest4977>but how to do it? this pinebook guix seems to be very minimalistic <leoprikler>Guest4977: typically you'd have /bin/bash for traditional distros and on guix you just patch-shebang it <maximed_>about /usr/bin/env: yes in source code, not in the store items in Guix (and Nix, for that matter) <maximed_>(1) /usr/bin/env is not guaranteed to exist <maximed_>(2) "bash" is not guaranteed to be in PATH <maximed_>(3) What if someone writes a package containing a "bash" binary, that does something completely different from the usual bash? <maximed_>Those are (some of the?) usual reasons for hard-coding stuff <maximed_>That hardcoding is done by the 'patch-shebangs' phase IIRC (and maybe 'wrap-program' as well?) <nckx>No. But writing #!/usr/bin/env bash is a good habit for toy scripts or things you want to distribute to other people unpackaged, so do that. <maximed_>but in guix package definitions (and nix too I suppose), a package definition should patch these to a /gnu/store/ (/nix/store/) path <nckx>Guest4977: The general rule in Guix is the opposite: you don't want programmes to depend on whichever bash happens to be installed. Your programme could run fine one day and fail the next due to some update/bug in bash. You want to bind it to one exact version of bash, and reflect that in the hash, so /gnu/store/thouateh-my-programme is a more reliable unit. <maximed_>Yep, it turned out to use the incorrect bash <nckx>‘The former searches the user's PATH to find the bash binary.’ is exactly what you don't want here. It is what you want for personal scripts you might distribute to others thaugh. <zacchae[m]>I tried installing `zsh-autosuggestions`, but the build process faild on three files, all with the same discrepency: <zacchae[m]>> expected: "echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" <zacchae[m]>> got: "echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\naaaaaaaaaaaaaaaaaaaaaaaaa" <nckx>Yes, to bug-guix at gnu.org, thanks! <Guest4977>btw. so if there is no proper way to cross compile this pinebook pro image how would you recommend to do it at the moment? <nckx>maximed_ will fix the bug you encountered with cross-compilation. <nckx>Guest4977: You could compile it with --system= instead of with --target= for an emulated ‘native’ build. It requires QEMU binfmt support. If you're running Guix System on your x86 build machine it should work out of the box. Otherwise, I'm not sure how to enable it, probably depends on your host distribution. <maximed_>nckx: No, it won't work out of the box. You need to add qemu-binfmt-service-type to the configuration, with 'platforms' set appropriately. That service is not included by default <maximed_>but maybe that's what you meant by "it requires QEMU binfmt support" <maximed_>I didn't test this though, I don't use qemu-binfmt-service-type <Guest4977>actually as I remember I've just build it using 'guix system image pinebook-pro.scm' <mothacehe>Guest4977: this cross compiles the image under the hood <nckx><No, it won't work out of the box.> Then report a bug. <nckx>You should should only need to add the service, all of the previous manual configuration is gone. <nckx>As are the weird dynamic linking issues IIRC. <maximed_>What I meant with "it doesn't work out-of-the-box": you need to add the service. No bug, just a difference in the exact meaning we assign to "out-of-the-box" I suppose. <Guest4977>do you know some alternatives to dhclient in order to get the internet access? maybe manually editing /etc/network/interfaces will work in guix ? <nckx>maximed_: I see the confusion. By ‘it’ above I meant the service. In the bad old days it used to *not* work on its own. <nckx>Guest4977: I'm afraid the default pinebook-pro.scm doesn't seem to offer any (maybe it should include NM?). /etc/network/interfaces is a Debian thing. <nckx>Hi roptat & (!)brettgilio. *dstolfa has a bunch of things he wants to do with guix but is in the process of dissertation writing... <mothacehe>Guest4977: you could maybe use the connman service, but i'm not sure it supports cross-compilation <nckx>Guest4977: Is static networking an option? <nckx>mothacehe: How does a cross-compiled System continue? Can it reconfigure itself, and will the hashes be forever different? <Guest4977>yes static networking could work but I have no idea how to do it in guix ***apteryx_ is now known as apteryx
<roptat>there's the static-neworking-service-type :) <nckx>Guest4977: It's already used in pinebook-pro.scm, you could add another interface to the (list …). <mothacehe>nckx: I guess it can be reconfigured and most of the derivations will have to be downloaded, but i'm not sure I even tried. <nckx>I'm not 100% certain about the syntax. (provision '(whatever)), but change the name or it will conflict. <Guest4977>Is it possible to activate static networking without guix system reconfigure? <maximed_>Guest4977: manually run the right "ip blabla" commands? <Guest4977>ok I've managed to ping my router with ip addr add myip/24 dev eth0 :) <roptat>Guest4977, "ip r add default routerip dev eth0" and you should be connected :) <apteryx>civodul: moin' I'm trying the substitute-stress test and it seems to be downloading the packages sequentially; is there a way to have it download them in parallel (that's what happens with the guix-daemon running with --max-jobs=4 I think) <Guest4977>roptat: yes I can ping only internet IP now but I still don't have dns yet <roptat>oh, maybe add something like "nameserver routerip" in /etc/resolv.conf <maximed_>Guest4977: I now have a patch. THe bash has a correct architecture. I don't have a system to test it on though. Will send it now. <Guest4977>ok internet works but guix pull crash with an error: Git error: the SSL certificate is invalid <maximed_>Waht is the output of "echo $GIT_SSL_CAINFO"? <Guest4977>GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates/crt <Guest4977>SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt <maximed_>what are the first few lines of those files? I have "# alias="ACCVRAIZ1" <maximed_># trust=CKA_TRUST_EMAIL_PROTECTION CKA_TRUST_SERVER_AUTH <Guest4977>roptat: yes I'm in a bare metal pinebook-pro.scm now <Guest4977>maximed: I have only symlink /etc/ssl -> /ruc/current-system/profile/etc/ssl which is empty <roptat>Guest4977, it should be GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt (".", not "/") <Guest4977>btw. I'm on root now and I don't have any other users in my system <roptat>(actually I have GIT_SSL_CAINFO=/run/current-system/profile/etc/ssl/certs/ca-certificates.crt on my guix system) <maximed_>seems like the minimal pinebook configuration is a bit too minimal; some default TLS(/SSL) certificates should be included <zimoun>apteryx: thanks for “guix pack -f deb”. However, “sudo apt remove foo” seems to remove outputs used by foo and by others. Hum, am I doing wrong? <Guest4977>maximed_: can I download it somehow with wget? <maximed_>You have Internet access by now, right? If so, try "guix build nss-certs". <maximed_>(some other steps are required as well, but let's start with that) <maximed_>"nss-certs" = a package full of certificates, curated by Mozilla <maximed_>/gnu/store/something, a build error, a network error? <Guest4977>no errors I have a new package in /gnu/store/....-nss-certs-3.59 <Guest4977>should I link it with this my empty /etc/ssl/ ? <maximed_>It turns out git doesn't support that format, it needs a "certificate bundle" <apteryx>zimoun: what do you mean by "outputs used by foo and by others". Others being Debian packages? Something else? <zimoun>apteryx: other elements under /gnu/store which are common to foo and others. <zimoun>for instance, apt has removed /gnu/store/…-guile-wrapper/bin/guile <maximed_>Do "guix environment --ad-hoc --pure git nss-certs -- echo $GIT_SSL_CAINFO" <apteryx>this should not happen, as dpkg won't allow two packages of different names to conflict; essentially limiting you to one deb package installed <apteryx>two different packages sharing the same files is not possible for dpkg <zimoun>I ran your exemple with hello, then “apt remove hello”, then “guix help” is broken :-) <maximed_>instead, guix environment --ad-hoc git nss-certs -- bash -c 'echo $GIT_SSL_CAINFO' <nckx>apteryx: Oof, as they say. That's a major limitation. <maximed_>apteryx: would making seperate debs per store item work? <maximed_>That will result in more debs, but should eliminate the "multiple debs have this file" problem. <apteryx>maximed_: yes, splitting packages in their individual components would help, but that's not currently easy to do (you'd need to pass the deps graph information into the .debs metadata). There's also no guarantee that two guix packages don't clash together, and dpkg is more strict in that regard. <nckx>That's the right way to do it but would be hard to distribute. <apteryx>it's not really in the 'guix pack' spirit :-) <nckx>Wouldn't you have to throw all item-packages at apt at once so it can resolve ‘dependencies’? <Guest4977>daymn I'm out of hdd memory I need to resize my partition one sec <nckx>Or install them each in order. 😛 <apteryx>you'd have to make them available from somewhere, either a repository or from the current directory so that apt can resolve them, I think <maximed_>apteryx: give each store item a separate name, derived from the store hash? And, for user convenience, add a conveniently-named (say, "guix-hello-VERSION")) deb package depending on guix-hello-HASH? <apteryx>the guix tool could even generate an apt repository, if we were to go that route <maximed_>Guest4977: how large is the partition? Also, "guix gc" <nckx>apteryx: How about (ab)using the grafting mechanism to throw some reproducible salt into the mix so each pack has unique hashes for the same thing. It's not efficient but it would just work. <apteryx>nckx: that sounds like a clever hack <apteryx>but yeah, performance would be abyssmal for large packs <civodul>apteryx: hi! just run it 4 times in parallel, which is exactly what happens when using --max-jobs=4 <civodul>well you need to adjust it otherwise each instance will try to write to /tmp/substitute-test <apteryx>what is a lower hanging fruit would be to use guix packg -f deb -RR (relocatable pack), detect this as part of the pack construction, and choose a distinct, per package installation prefix (say, '/opt/guix/deb-packs/hash-package/gnu/store/...') <civodul>oh, and congrats on 'guix pack -f deb' BTW :-) <apteryx>I've left a TODO in (guix scripts pack): "When relocatable option is selected, install to a unique prefix", if someone would be interested in pursuing that relatively straightforward option. <apteryx>that would enable multiple deb-packs to share the target file system without conflicts <civodul>maximed_: BTW, it'd be great if you could try out the substitute stress test i posted <civodul>and really anyone who's experiencing problems :-) <apteryx>maximed_: you can't simply rename things, they need the relocation support otherwise it'd break all the hard-coded assumptions that the store is at '/gnu/store' <maximed_>apteryx: ?? I didn't say anything about renaming? <maximed_>I meant giving the debs seperate package names, per store item <xnnx>Guys do suggest building GHC from git repo or the current method present in package definition ? <maximed_>I just noticed a few 500 while trying to comment on Mumi. Does anyone here have access to its logs? <nckx>Web submission has been broken since $forever, but this is the first I've heard about 500 errors and not just swallowing the message without feedback. ***Kimapr5 is now known as Kimapr
<apteryx>maximed_: oh, I had misunderstood you, apologies. <nckx>apteryx: It's the same idea you described, I think. Two ‘deb pack repositories’ would provide the same 45142541-glicb.deb and only one would be installed, and the last user would free it. <nckx>Can't repitories be distributed as .debs themselves? I thought I saw that done once. <apteryx>maximed_, nckx OK, yes, after rereading to get the full context it makes sense for one deb per store item scheme <Guest4977>ok I'm back by default pinebook pro has 60GB mmc memory its just pinebook-pro.scm is generating 1.6GB image so I've just resized it with cfdisk and resize2fs <Guest4977>maximed_: GIT_SSL_CAINFO=/gnu/store/....-profile/etc/ssl/certs/ca-certificates.crt <OJ[m]>Guix on Pinebook Pro. Now I gotta try that. <maximed_>Do "export GIT_SSL_CAINFO=/gnu/store/....-profile/etc/ssl/certs/ca-certificates.crt; guix pull" <maximed_>civodul: curiously, nothing ends up in $HOME/tmp/substitute-test at all. (I changed 'test-directory') <maximed_>I do have "warning: SQLite database is busy", however -- relevant, irrelevant, ?? <nckx>maximed_: See PM if you haven't yet. <Guest4977>doesn't work it's still the same Git SSL error <maximed_>can you paste the SSL error (paste.debian.net)? <maximed_>civodul: never mind, it just needed some time to start <Guest4977>I'm chatting here from different machine so I need to type manually everything: 'guix pull: error: Git error: the SSL certificate is invalid' <maximed_>just to be sure, can you run "echo $GIT_SSL_CAINFO" again? <Guest4977>it's /gnu/store/.....-profile/etc/ssl/certs/ca-certificates.crt <roptat>I wonder if this is right, or if this variable needs to be set for the daemon? <maximed_>make sure to run "guix pull" from the same bash session "export GIT_SSL_CAINFO=..." was done on <maximed_>roptat: I don't think it needs to be set for the daemon. IIRC, "guix pull" downloads stuff as the user and adds it to the store with the equivalent of "local-file", and uses that as source code <Guest4977>yes I'm sure I'm listing all variables with /usr/bin/env and it's the same as echo $GIT_SSL_CAINFO <Guest4977>maybe the problem is that I'm using root all the time <Guest4977>I will try to test it with some non root user now <maximed_>no (about the variables), I meant make sure that "guix pull" is run in the same bash session as "echo $GIT_SSL_CAINFO". Environment variables are per-process and inherited (copied) by subprocesses, they are not a per-user resource <maximed_>(if git isn't installed, do "guix environment --ad-hoc git -- git clone ..." instead) <Guest4977>I'm sorry guys I need to go offline now, I will try to catch you later, cya <apteryx>civodul: I have tried the substitute-stress script and haven't been able to get the failure so far, but will mod it so that it runs in parallel and try again <apteryx>I've added heavyweight such as libreoffice and ungoogled-chromium to the list of packgaes (substitutes) to pull. <tricon>Guest4977: Excellent. I aim to run Guix on PBP; I don't have the UART cable to troubleshoot startup ATM, though. <maximed_>apteryx: You could add "texmacs" as well <maximed_>nckx: I found the mumi issue. "mu-debug" was unbound. WIll sent a bug report <zimoun>apteryx: IIUC, apt removes all the files under data/, therefore for the example hello using gcc-7.5.0-lib and glic-2.31, ’apt remove hello’ remove the 2 items. And obviously, they are used by others. :-) *maximed_ afk for a while <nckx>sneek: later tell maximed: Thanks! ***nckx is now known as Thunderbi
<dongcarl>Hi all, what are your thoughts on keeping a few older glibc versions in base.scm that have major non-EOL distros still maintaining them? (e.g. glibc 2.24, maintained by stretch)? <dongcarl>Mostly to construct toolchains that are based on older glibc's <dongcarl>I have 2.17 and 2.24 packaged in my local manifest, but just wondering if it'd be of interest to upstream or not. <dongcarl>My patched 2.24 works for x86_64, armhf, aarch64, ppc, ppc64le, and 2.17 works for x86_64, armhf, and ppc(non-le) <Thunderbi>I'm not sure. Personally, I'd be fine with it as long as someone's actually using them. An alternative is to submit them to guix-past, but I'm not familiar with how maintainership works there. <Thunderbi>If you have packages already, I invite you to submit them to guix-patches and have the discussion there. <dongcarl>Just wanted to share work, in case it benefits anyone else haha <Thunderbi>I don't have a use for it, but I like the idea in principle! <dongcarl>"It makes most sense to add software dating back to before 2019, around the time where time travel became possible." <apteryx>dongcarl: sounds reasonable to me (either in Guix or in the Guix Past channel) <apteryx>you'd want to have a comment explaining why we are keeping those around, so that the next tidying maintainer doesn't just remove them. <Thunderbi>I hope that's not the attitude of any maintainer, tidying or otherwise. ***Thunderbi is now known as nckx
<euandreh>Here's a question: f41e56dcf1a42b0bf5dee14afd1494b8f25c2353 upgraded python-attrs from 19.3.0 to 21.2.0, but python-flake8-implicit-str-concat breaks because of that, since it requires attrs<21,>=19.3. What is the best course of action: downgrade python-attrs, or patch python-flake8-implicit-str-concat? <nckx>If concat's version demands are bogus, just patch the <21 (we do that elsewhere). But if it really is incompatible, or if you're simply not 100% sure, it seems 19.3.0 is still available as ‘python-attrs-bootstrap’. You could patch python-flake8-implicit-str-concat to use it. <euandreh>TBH I believe the demands are bogus, but I'm not sure yet. <apteryx>civodul: actually, for deb packs, I guess it *can* break guix installed on a foreign distribution since that guix would have their files under /gnu/store, unknown to dpkg. Not sure how we could guard against this other than adding a disclaimer to the manual. <civodul>apteryx: does dpkg overwrite files that it does not manage? <civodul>(BTW i commented on a few bits in the patch tracker, although i was late) ***ChanServ sets mode: +o nckx
***ChanServ sets mode: -o nckx
<apteryx>civodul: I think it just takes over ownership of (in their context) orphaned files *jonsger how confusing can an installer be -> looks at CentOS and is happy about the Guix one :) <nckx>jonsger: What's something CentOS does that we definitely want to avoid? <jonsger>nckx: super confusing partitioning which is pretty tricky to configure manually <nckx>I'm literally just about to successfully use our installer partitioner for the first time. It seems like a hard thing to get right. <nckx>Although the UI to ‘delete the entire partition table’ is to press <Return> on the disc? That can't be right… <nckx>It's also immediate and can't be undone. Must be a bug. *nckx begins to recreate their partitions… <efraim>I have a bootable guix image for gparted but it came out to like 3.5GB <nckx>That's bigger than my GNOME desktop experiment. <nckx>OK, the Ret-to-wip thing is intentional (and what the text calls ‘change’). Feels very gotchan. <apteryx>civodul: how about [...] on top of any GNU(/Linux) distributions? (to include Hurd) <apteryx>civodul: guile-git doesn't fail, but I see some long pauses sometimes; not sure if that's normal. <apteryx>for example while updating the ffmpeg submodule of ppsspp <lfam>I went to check docs for the new deb support for `guix pack` (wow!) and saw that the devel manual is still having trouble: <lfam>I just saw it in the 'news' of `guix pull`! <lfam>I immediately went to read about it :) <lfam>The online "up to date" manual should be up to date within a couple hours <apteryx>civodul: thanks for working on a guile-git fix! :-) <apteryx>dongcarl: don't get too excited yet, I have a note + warning disclaimer in drafts ;-). Still, fun! <apteryx>in a nutshell, just don't install then uninstall guix pack generated .deb on a system where /gnu/store is already used for other purposes (other packs, a guix install, etc.) <apteryx>and don't expect to be able to install such deb next to each other yet, as dpkg is strict about file conflicts (and guix packs inherently makes these likely). <maximed>sneek: later tell civodul: I'm not able to run the stress test for long (currently on a ‘only N GB a month’ network), but I'll try later <sneek>Welcome back maximed, you have 1 message! <apteryx>maximed: don't waste your data, it doesn't seem to reproduce unfortunately <apteryx>(no failure here for ~16 GiB worth of substitutes) <civodul>apteryx: perhaps you could try inserting random delays in between substitutes <sneek>civodul, you have 1 message! <sneek>civodul, maximed says: I'm not able to run the stress test for long (currently on a ‘only N GB a month’ network), but I'll try later <civodul>that's the only difference i can think of compared to the full-blown setup <drakonis>hmm, is there any example config for setting up a mail server? <drakonis>or at least enough pieces of it to send patches from my own domain? <ekaitz>drakonis: I think roptat has some example config <ekaitz>let me search and I'll send you the link right now <ekaitz>not sure if it's from roptat btw :S <jonsger>is there a way to run `herd start cow-store /mnt` on a foreign (systemd based) distro (debian)? <ekaitz>drakonis: you have to search a little in the code to find what you look for, but there is a mail config iirc <drakonis>you need shepherd to be running dont you? <drakonis>ekaitz: found it, now this is good stuff <drakonis>jonsger: what are you trying to do here? <jonsger>drakonis: install Guix System from a debian live system <drakonis>afaik the debian package already takes care of the store <drakonis>definitely needs some touching up to refer to generically bootstrapping guix on another machine <jonsger>ah it also uses bios not efi, need to switch <drakonis>hm, i'm having some weird issues with wine and gnome lol <drakonis>at least i think it might be gnome related <maximed>sarg: fwiw, the definition seems ok to me but I didn't look at the sources or test <maximed>you could do "./pre-inst-env guix lint goldendict" though <maximed>oh and you're supposed to use 'tags' instead of 'commits' when they are available, though myself I prefer just using a commit <maximed>tags can change, but commits never do, and in case the repo disappears, it is easier to find a random mirror (or fork?) by searching by the commit id than by searching by tag <maximed>I've heard Software Heritage supports repository URLS + tags, but Software Heritage is a bit a central point of failure to me <nckx>maximed: <you're supposed to use 'tags' instead of 'commits'> Are you? I think both are fine. You're supposed to follow our versioning requirements though, whilst ‘2020-12-09’ looks completely made up. <nckx>Tags can indeed change and it happens in practice. <civodul>dstolfa: only some of the tests within it; see tests/syscalls.log for details <sarg>nckx: goldendict haven't seen a proper release since 2016 <sarg>they've publishing nightlies in AppImage format <nckx>But you need to use the conventional (version (git-version "1.0.1" revision commit)). Many examples in the Guix repository. <nckx>Where revision is "0" and incremented every time someone bumps the commit, so Guix knows which is newer. <dstolfa>civodul: it seems to just be tcgetattr and tcsetattr -- do you know why they're being skipped? <nckx>sarg: I was deliberately ignoring the RC releases, but goldendict.pro identifies itself as VERSION = 1.5.0-RC2+git, so I guess you should use (git-version "1.5.0-RC2" …) after all. <sarg>nckx: makes sense, I'll update the patch <civodul>i had completely missed the switch to GCC 10 on core-updates <maximed>civodul: yes, I agree 2021-06-12 is not a 'correct' version. Didn't notice that <nckx>‘2’ means ‘skip the next 2 tests’, it's shockingly non-functional 😉 <dstolfa>that is totally not what i'd expect it to mean <dstolfa>i saw that line already but it didn't occur to me in the wildest dreams that that's what it would mean <nckx>Hell, it's not even particularly ‘imperative’, it's just ‘weird’. <dstolfa>hum, so does this test ever actually run? <nckx>Your system sounds like the weird one. Which premise is false? <dstolfa>though, they both have to be true, right? <nckx>$ readlink /proc/self/fd/0 has to return /dev/pts/something, yes. <nckx>The and is just there to prevent an error. <nckx>That is weird. You could add some (pk)s to tests/syscalls.scm to find out what's going on. <nckx>You're not running make inside a container or anything? <dstolfa>nope, it's just under `guix environment guix`, nothing else <nckx>If it's reproducible, I think you should (pk) some stuff to see what's going on. <dstolfa>it just passed when i ran it without -j20 <nckx>s/If it's reproducible/While running with -j20/ <dstolfa>nckx: i'm rerunning the whole test suite with -j1 now just to see what happens, but `make check TESTS="tests/syscalls.scm"` seems to be fine with -j20 as well <mbakke>civodul: thanks! I could not test cross-compilation, but it used to work... at least for hello. <dstolfa>must be some other test during the whole `make check` run that causes this... <mbakke>apart from cross-compilation, c-u is in a pretty good shape <boeg>does anybody know where i can find the template for what the config.scm looks like if i choose gnome desktop environment in the graphical installer? <dstolfa>yeah, syscalls.scm passes just fine with `make check -j1` <dstolfa>but reliably fails under `make check -j20` <civodul>i'm gonna break it one last time and then we're done ;-) <civodul>ah well, there's this texlive issue we need to address, too <mbakke>someone was half-way through updating to 2021, I wonder how that went <dstolfa>i might look into it if i get time, but feel free to beat me to it! :) <mbakke>civodul: what's your plan for breaking it? :-) <mbakke>maximed: how common are shebangs in libexec? <maximed>I dunno, but at least isc-dhcp has a shebang in libexec, due to using wrap-program on a binary in libexec <dstolfa>on that note... does anyone have a box here that can run `make check -j20`? if someone could test a few runs to see if they can get tests/syscalls.scm to skip tcgetattr and tcsetattr when running with ~20 jobs, that would be really helpful <maximed>I've two shebangs in ~/.guix-profile/libexec <maximed>blueman-mechanism and blueman-rfcomm-watcher, which appear to be created by wrap-program <maximed>I'd say they are infrequent, but they do definitively exist <civodul>maximed: do you have other pending core-updates patches, BTW? <mbakke>maximed: btw, great job on fixing cross-compilation with gexps, I'm considering reverting e6ab2f0097 in favor of changing haskell-build-system %build-inputs consumers to this-package-input <maximed>head -n1 /run/current-system/profile/libexec/gvfsd-* |grep -F "#!" | wc --lines gives me 25 shebangs <maximed>civodul: I don't think so but lemme check <civodul>maximed: i hadn't seen your patch re this-package-input <maximed>I thought I sent "this-package-input" as part of the "cross-compilation fixes+meson cross-compilation" series <civodul>so it'd be a bit more verbose: (lookup-package-input this-package "foo") <maximed>I have an unsent patch for "wrap-qt-program", adding a #:sh like "wrap-program". Though it is not all that important, as it turns out "patch-shebangs" (accidentally?) replaces interpreters from 'native-inputs' with interpreters from 'inputs' <maximed>IIRC, I first wrote something like lookup-package-input, but I decided on this-package-input & friends to help avoiding the 80 characters limit <maximed>civodul: I could drop the "this-package-input / this-package-native-input" in favour of (lookup-package-input this-package ...) I suppose <mbakke>civodul: I hadn't seen #49169, very nice. How does the "new style" work wrt cross-module references? <civodul>maximed: "uh, interesting" was about interpreters being replaced accidentally by patch-shebangs <maximed>or implement "this-package-input" in terms of this-package & lookup-package-input <civodul>mbakke: no change here since input fields are still "thunked" (so references are delayed until you actually access the field) <civodul>maximed: yes, that'd work; one subjective downside is that this-package-input "perpetrates" the magic that 'this-package' introduces, if you see what i mean <maximed>Basically, it seems that patch-shebangs treats "/bin/bash" and "/gnu/store/.../bin/bash" the same way: it tries to replace stuff <civodul>in terms of the mental model, i think it's easier to think about a single "magic keyword" (this-package) <maximed>I don't see it as a downside. That this-package-input uses this-package seems implicit in the name '*this-package*-input', so it doesn't cause any big surprises <maximed>though I suppose there is an argument to be made in favour of limiting the number of "magic macros" <civodul>the intent was to preserve compatibility wrt. the global variables: %outputs, %build-inputs, and %build-native-inputs (?) <civodul>that said, switching to gexps is nice, it's great you tried that :-) <civodul>you must be the first person doing it, thumbs up ;-) <maximed>I wonder if ‘pre-formatting’ G-exps would improve performance & reduce (or increase?) memory usage. I mean internally storing #~(b (la la #$x) #$z) as "b (la la " PLACEHOLDER " " PLACEHOLDER ")" or something like that <maximed>in case someone is looking for optimisation opportunities, there is an untested idea <civodul>it's clear we're spending a lot of time in 'write' when doing "guix build foo -d" <civodul>initially i was planning to have fewer gexps in the first place, like all gnu-build-system packages would in fact use the same gexp <civodul>anyway, i think we need to create an optimization squad :-) <maximed>most of the time is probably lost in the stats & writes and I'd guess the time spent in 'write' minus the I/O is neglible <civodul>by 'write' i meant the Scheme 'write' procedure, not the syscall <civodul>the one that formats objects into strings ***ChanServ sets mode: +o nckx
<maximed>and, if G-exps are always used in package definitions #:phases, & G-exps are internally ‘stringified’ at compile time, then I'd guess loading the ".go" will be faster <maximed>because there would be less pointers to patch. <dstolfa>nckx: i'm running the tests locally... 5 times with -j1, 5 times with -j2, ... until i hit one that makes it fail so that i can narrow it down to a few tests <maximed>and possibly less pressure on the GC, more stuff that is pageable? <civodul>we'd need the ability to do partial writes or something <maximed>nope, but it should only require changes to (guix gexp), <maximed>if/when "write" is implemented in Scheme, ‘we’ could exploit delimited continuations to avoid having to write our own "partial-write" <civodul>now 'lowered-gexp' (which is public) exposes the sexp <maximed>I'd need to work out the details though <civodul>so there's a compatibility concern here ***ChanServ sets mode: -o nckx
<nckx>Sorry for all the oppin'. <civodul>for the partial write we could also replace unquotes with things like ~s (as a symbol) <civodul>i mean, it could be that we could come up with a hack to handle partial write <dstolfa>seems like -j5 is the smallest number i can trigger it on <maximed>I suppose it would be possible to reconstruct the S-exp from the string *dstolfa tries -j4 a few more times *raghavgururajan rebases wip-gnome with master ***Kimapr8 is now known as Kimapr
<The_tubular>Where can I read on how guix container works ? I'm not sure I understand the difference with Docker <ryanprior[m]>(is summoned) Docker uses containerd. Guix uses similar underlying technology buy does not user containerd or Docker. Guix can export container images usable by Docker & compatible technologies. <dstolfa>probably just namespaces/cgroups/capabilities/etc? <ryanprior[m]>Right, it uses Linux namespace isolation features similar to what containerd uses. <The_tubular>That's also what I though I just wanted to be sure ^^ <ryanprior[m]>For low-level details you'd have to look at the source code, I'm not aware of any quality documentation of the low level details although that would be a welcome contribution. <The_tubular>Also, I plan to use guix in productions, and was wondering how to deal with the networking side of things, any experience with that ? <lfam>Is mcron still running on berlin? The last log was touched on June 26 <The_tubular>I read most of those, it says how to use guix container, but not how does it work. I'll take a look nonetheless <civodul>lfam: it could be that it was stuck; i've restarted it now <lfam>I'm monitoring the 'devel' manual for the web site