<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…
<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)
<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
<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>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.
<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
<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_>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
<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>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 :-)
<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>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
<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. :-)
<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>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)
<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.
<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>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'
<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
<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.