<dftxbs3e>The information about failing packages introduced by specific commits is still unclear in ci.guix.gnu.org
<lfam>We use the number of rebuilds to make these judgements. It's not perfect. It could rebuild 299 Go packages, which are really cheap to build. Or it could rebuild 299 gigantic C++ packages, which might take a week. But either way, we say it's okay.
<rekado>dftxbs3e: we don’t know if the change caused the failure or if the package was broken before
<dftxbs3e>The information is there but you need to go through many pages to actually check, it could highly the ones that newly failed?
<lfam>You could also push 10 commits that each rebuild 299 different packages, and that would still be considered okay
<lfam>And they may be the only type available to us
<rekado>hmm: failed to deploy hydra-guix-128: aborting reconfiguration because commit 2cc169f8f91dd76ec86317e8c868b9183c19b2d9 of channel 'guix' is not a descendant of 14c3c3eec2cdd9359964a0bd5e77654ec10bcc98
<lfam>They also have a "reloaded" version. I guess they refined some things
<lfam>I still think it would be best to have one very powerful computer than a bunch of these little things. It's always been difficult for us to coordinate access to them and keep them running smoothly
<kozo[m]>Hello, are there any common lispers around? I would like some help figuring out workflow
<kozo[m]>I see in guix that there are packages for what also is a (ql:quickload) call for me when I'm writing lisp. For instance, I installed cl-csv as a system package for guix but I was not able to access it in my emacs + slime buffers
<kozo[m]>I'm wondering why someone built a system package for different common lisp libraries if once installed, can not be accessed.
<kozo[m]>It's obviously I don't know how to access them
<gnutec>kozo[m], Ha! Do you mean use something like (use-modules) of foreign library?
<kozo[m]>Similar. Normally when I write common lisp, I use (ql:quickload :cl-csv) to bring a library into my buffers. I see the same library exists at a system package. It would be neat if I could just have them installed and not have to quickload them all the time.
<kozo[m]> * Similar. Normally when I write common lisp, I use (ql:quickload :cl-csv) to bring a library into my buffers. I see the same library exists as a system package. It would be neat if I could just have them installed and not have to quickload them all the time.
<bavier[m]>oh no, I'm in a rabbit-hole while upgrading our `onionshare` package, and have arrived at a dependency on "python-certifi", which is a python package bundling the Mozilla CA certs. That seems shaky to me.
<dftxbs3e>bavier[m], onionshare doesnt require it directly correct?
<aidalgol>Don't you want to specify an exact version, though?
<aidalgol>If one of the packages in my requirements.scm file is a daemon that is normally run as a system service, like postgres, where do its files go?
<ryanprior>At some point I may want to lock those down to a specific version. You can do that with a matching channels.scm file.
<ryanprior>If you need a daemon, then you'll need more than just a manifest of packages. You'll also need a system definition with a service for the daemon. I'm still a newbie at setting those up, I've been slowly reading and seeing how other people do it.
<ryanprior>That's an area with a large increase in complexity though. It's felt sometimes like death by a thousand embedded DSLs.
<muradm>installing openjdk11 does not expose javac, why? for example (packages->manifest (list openjdk11))
<aidalgol>I have a software project that uses docker to run postgresql isolated form the host system like this <https://paste.debian.net/1187783/>, and I am trying to migrate to guix, because it's intended purpose is closer to my needs than docker.
<rekado_>sneek: later tell muradm Do “guix install openjdk:jdk” to install the “jdk” output of the “openjdk” package.
<civodul>at first sight i don't see how running "guix pull" in the container could break the host
<cybersyn>sorry i haven't got around to the UX/Community Experience research yet as discussed at guix day, after the lunar new year I got hired for a last minute job thats had my hands full, but i'll be getting shooting the mailing list a little presentation at the end of next week
<aidalgol>Do I understand this correctly? 'guix system' lets you run an instance of GuixOS inside a container/vm/other?
<aidalgol>rekado_: Were you suggesting I run everything for my project in a system container?
<rekado_>I don’t know your project well enough to suggest that. But if you want to run postgresql separately from your host system I’d suggest using “guix system” for that, so that you can use the existing service definitions.
<aidalgol>The project is a Phoenix web application, if that helps, but that sounds like what I want.
***Lightsword_ is now known as Lightsword
***bkv is now known as bqv
<aidalgol>How do I go about writing an "'operating-system' declaration?"
<rekado_>aidalgol: perhaps it’s best to start from an example.
<mdevos>aidalgol: I would look at the examples in gnu/system/examples/*.tmpl
<mdevos>alternatively, there probably are exampels in the manual
<rekado_>booted an older kernel (5.4.55-gnu), and got a different kernel oops, again related to memory (BUG: unable to handle page fault for address: 0000000fa2774528); I’m suspecting a hardware problem.
<rekado_>fnstudio: you need not just the python command but also environment variables.
<rekado_>yeah, so the problem appears to be that the Python process is spawned from outside of the shell environment where PYTHONPATH is set
<rekado_>here’s a silly idea: Guile has “guile --listen”, which spawns a REPL that I can connect to over the network
<rekado_>does Python allow you to launch its REPL and connect to it?
<rekado_>because then you could do the shell setup in one snippet (source’ing etc/profile *and* launching a Python process inside that new environment) and have the other Python snippets *connect* to that Python process
<fnstudio>i must have messed something up... outside emacs, in my terminal, if i run "guix environment --ad-hoc python-requests" and then launch a python repl and then import requests, i get a module not found error
<fnstudio>(just checking: i suppose it's fine to have multiple guix environments launched in different terminals, isn't it?)
<nckx>I was just going to ask: make sure that you're using python3.
<fnstudio>(but i'm totally in love with the power of guix + org-babel, it feels so exciting!)
<nckx>(Python-wrapper == python3 + ‘python’ compatibility link, in case you didn't already know.)
<edgarvincent>I'm trying to install the guix system. After files have been copied to /mnt, the installer fails with the following error: "/remove" "Device or ressource busy". Is there anything I can do?
<nckx>edgarvincent: Would you have time to report the /remove bug to bug-guix@? That way you'll receive replies. I've hosted the screenshots at https://www.tobias.gr/removebug/ if you don't want to do so yourself.
<nckx>My arrow keys stopped working the the 1.2.0 VM :-/
<nckx>...and now they magically do. Still no bug: I select programmer Dvorak, fill in some stuff, at the first partitioning window press F1, go back to keyboard layout selection, choose German, type ‘qwertz’ at the hostname prompt.
<nckx>However, from listening to past reports (like yours earlier) there are plenty of installer bugs that query the state of the moon, so I believe you.
<apteryx>Autoconf's manual defines a system type as 'CPU-COMPANY-SYSTEM', where system can be either 'os' or 'kernel-os'. In practice it seems we use 'arch-kernel-os', no?
<apteryx>civodul: ah, the definitive answer to my question as pointed by the Autoconf manual lies is config.sub ($(guix build config)/bin/config.sub) -> it does some heuristic below the comment "Ambiguous whether COMPANY is present, or skipped and KERNEL-OS is two parts"
<sneek>rekado_, mdevos says: could you share your guix operating-system configuration? CUPS gives me ‘No such file or directory’ errors
<rekado_>nothing else in my config relates to CUPS.
<edgarvincent>OK, the problem is not the external keyboard, it's the dock.
<apteryx>on master, this fails: "guix build --target='armhf-linux-gnu' binutils" Is it expected? checking target system type... Invalid configuration `armhf-linux-gnu': machine `armhf-unknown' not recognized
<apteryx>looking at the logs; arm-linux-gnueabihf seems like the valid triplet to use
<civodul>apteryx: yes, arm-linux-gnueabihf is the "standard" thing
<apteryx>cbaines: hi! I'm testing your cross-compilation patch for guile-lib, and was expecting that 'guix build --target='arm-linux-gnueabihf' guile-lib' would fail, but it seems to build fine; any idea of how to trigger the problem the patch is designed to solve?
<cbaines>apteryx, the package doesn't fail to build, it fails to cross-compile without that patch
<cbaines>specifically, Guile for the target architecture won't like the .go files
<apteryx>OK, so perhaps if I use 'file' on one of the compiled .go files I'd see if everything is OK
<apteryx>so at build time it needs the native Guile of the build machine; but for running the test suite for example it needs the Guile of the target machine
<apteryx>there's still useful comment in (guix build gnu-build-system): "When cross building, $PATH must refer only to native (host) inputs since target inputs are not executable."
<apteryx>the only other thing guix would do differently when cross-compiling that package would be to pass --host=$target to the configure script. Hence, I should be able to do 'guix environment --ad-hoc $native-inputs-of-package' then ./configure --target=$target and it should work the same for this case
<shcv>bdju: I did another pull and upgrade today, and ripgrep seems to be working now
<shcv>you could see if there's a recovery boot option, though I don't remember one. There's also a message during boot about an early-boot guile repl or something, maybe you could catch it at that phase of boot
<shcv>or just boot a live usb and then mount + edit; chroot shouldn't be necessary
<divansantana>Mount plus edit minus chroot. True. Let me flash an iso. Thanks!
<divansantana>I dont know much about boot repl etc. Seems would be useful
<divansantana>I guess must be a way to boot a rescue mode of sorts with shepherd
<shcv>I haven't tried it myself; I've always had old systems that worked which I could fall back on
<divansantana>Some rescue mode from the boot menu would be very welcome. Im guessing there is a way to achieve a init=/bin/bash like functionality
<nckx>There's a rescue REPL but you have to be pretty damn familiar with Guix and desperate to use it. It's not even Spartan.
<nckx>It's theoretically not impossible to mount your root fs from it, then spawn a shell, and tediously hobble your way to rescue.
<apteryx>civodul: about the qemu:static output and binfmt change; does my last reply justifies keeping it the way it is, or would you rather do what I suggested there (hard-code the F flag and revert to plain srfi-9 records?)
<dftxbs3e>civodul, I've been looking at cpe suggest code
<dftxbs3e>civodul, I rebased the patch on master, just some copyright lines issue, somehow now it doesnt suggest anything at all, trying to find out why
<dftxbs3e>civodul, It would be great to end up with an Emacs "data entry" UI that can somehow limit the work to human choices "accept (or modify before accept) or skip" and iterate on all packages that way
<paulj>nckx: update on changing my hash_alg to tea yesterday. It worked for the first file download, but I had the same error when downloading the sig file. Seems both hash algorithms will fail. I then turned off dir_index, but this caused all end of issues. I had to reboot into a sysrescue image and run fsck to fix everthing. After this, guix is working normally again. Therefore I suggest the recommendation in the handbook should be to turn
<paulj>this feature off at the start, or to use a different format (btrfs).
<dftxbs3e>civodul, so we can easily get up to speed with cpe tagging, on all packages in GNU Guix
<dftxbs3e>I have a question, how do you actually verify tarball authenticity corresponds to upstream with GNU Guix? Considering GNU Guix hash format is different it's a bit troublesome at times..
<paulj>nckx: basically the system was not finding anything. Even guix pull wouldn't work. I rebooted, then had page after page of errors saying that (I'm paraphrasing...) the inodes have an index flag set, but the file system isn't a indexed. It tried to fix each one, then finally gave up and gave me the rescue repl. I tried to see if I could run fsck from here (with (system "fsck -D /dev/nvme0n1p3") ), but without success. I had a recent
<paulj>sysrescue installation on a memory stick, so I booted that, and then ran the fsck command from there. After it fixed everything, I could reboot giux again with every thing running normally.
<PotentialUser-21>Hi all, I'm really thinking about distrohopping from Gentoo to Guix, but I have a few questions first ...
<roptat>PotentialUser-21, you can install guix on top of your distro if you want to check software
<paulj>That was written 4 years ago. My personal experience is very limited, but I see no issues with shepherd. It is managing the system services on my laptop, and I have also used it for some user services.
<pkill9>idk if the shepherd has parallel startup, but it is fast
<nckx>PotentialUser-21: Packaging requires different skills than ‘programming in Guile’. There's some overlap but less than people think. We don't use (or encourage) clever complex things in package definitions, they are generally simple and readable, almost markup-like.
<paulj>If not, I am sure there is a vim/nvim equivalent!
<paulj>... or which ever other editor is your favorite tool
<roptat>PotentialUser-21, but if I were you, I'd start by installing guix on top of gentoo, just to get a feel of how it works from a user perspective, and I'd look into replacing my software with guix versions step by step, packaging stuff along the way if needed
<PotentialUser-21>I see, also, could I define stuff close to useflag in package definition ?
<PotentialUser-21>I mean the way I package a package and someone else is going to package it might be different
<roptat>no, we usually enable most of the options and that's it
<paulj>You can inherit the system package definition, and then add your own additions. useflags are not a thing in guix like they are in gentoo
<roptat>although there's a project to add parameterized packages, which is close to gentoo's useflugs
<pkill9>mrprofessor: if they're in config.scm, then they will be available system-wide
<roptat>PotentialUser-21, I believe we already have a process to do all that? are you having any trouble with it, or anything missing?
<ryanprior>You can of course create your own installers, but the official Guix installer will not suggest any non-free components (like the upstream Linux kernel) because we keep to the high standard of the Free System Definition Guidelines
<paulj>Strange. I pasted your code into emacs, and then C-c C-c. First of all it didn't work, but then it did after I fixed the above mistake. I haven't installed guile-json explicitly in my system. I understand the guix environment should take care of that.
<roptat>nckx, if you have kept the build directory in /tmp, you can use php from there
<nckx>I've visually verified that the test ‘passes’ (it outputs the expected error message being tested for; it just outputs 2 more) so I'm tempted to disable it ‘for now’ and push the update... of course, ‘for now’ is risky.
<roptat>mh... sure, we've done that for other tests
<roptat>the test should have a name like .../*.phpt, and there's a similar-named *.php in the same location that you can run
<shcv>any idea why a data file in this python package isn't being copied in the 'install' phase? It's there after the unpack phase, and the setup.cfg file has 'include_package_data = True'
<shcv>I can manually copy it, but that doesn't seem right
<shcv>(as in, add the copy step explicitly to the guix package)
<civodul>roptat: yeah i'm not sure what the best way forward is; perhaps a "vision" page on the web site, with highlights of the grand long-term goals (like free software, R-B + bootstrapping, tight integration through Guile, etc.)
*nckx → zzz, will continue wrasslin' PHP tomorrow.