IRC channel logs
2023-12-17.log
back to list of logs
<apteryx>ieure: forgot the details, but something along *really* cleanup directories as well <apteryx>ACTION is still clueless about why /var/run/utmpx is empty in a udevd spawned script <vivien>lilyp, I don’t, but the threads ends with apteryx asking for a sorted list of inputs <evilsetg>Does the build of clojure-tools fail for anyone else? I get an `invoke-error program: "ant" arguments: ("check") exit-status: 1` in the check phase. <janneke>nckx: yeah, iwbn if the x86_64 bootstrap didn't have to use x86 <tex_milan>Hello all, does cupsd service works for you on Guix OS? <tex_milan>milan@t14s ~$ sudo herd start cups \n Service user-homes has been started. \n herd: error: failed to start service cups <Franciman>tex_milan: i enabled it in my /etc/config.scm <tex_milan>I have it there too. It worked before I updated. <tex_milan>how to see output of cupsd when started by herd? <efraim>nckx, lilyp: git grep guix\ platform | grep \\.scm | cut -f1 -d: | sort -u | sed -e 's/scm/go/' | xargs -n1 rm <efraim>civodul: would it work to fix the llvm@15 issue on i686-linux on the mesa-updates branch? <tex_milan>I found problem in my config about the cups service. <nckx>efraim: I'm not entirely sure what you're replying to, but… so .go files were being miscompiled? Cool? <efraim>the platform definitions got adjusted so the go files needed to be recompiled <nckx>My issue was just ia32 emulation not being enabled at boot, or at least I didn't get any further errors after rebooting with it enabled… yet. <efraim>yeah, that's necessary for the i686 part of the bootstrap <nckx>janneke: I assume it keeps the code simpler and more auditable? If not significantly so, then yes please. <janneke>nckx: it's just a question of laziness/priority, in the x86_64 bootstrap, bootstrappable-tcc isn't self-hosting yet, that needs work <Franciman>is there an estimation of how much time it takes to bootstrap guix from zero in some architectures? <efraim>it mostly depends on the speed of the processor <janneke>it depends -- we spent about a year with two people on arm, and we're now up to glibc-2.25 <janneke>about three people spent a year on riscv64 and we're up to bootstrappable-tcc <janneke>once they both work, the expectation is for new architectures to become easier, as a good number of problems are architecture-independent <janneke>and other solutions might be relatively easily portable <Franciman>another question. How do i trust that substitutes are built from a given package definition? <Franciman>should i trust the whole server substitute? Or i can trust the single substitutes to not be tampered? <civodul>janneke: i’m looking at core-updates and quite a few *-mesboot builds are indeed hanging for me now <civodul>not sure what’s going on but i don’t see how this could be related to the locale (since the locale is not in effect for those builds) <civodul>if you feel inspired, i’m all ears! :-) <janneke>civodul: crap, do you know where they hang, is it all in configure? <nckx>Franciman: You trust servers, hence the whole signing key set-up. <nckx>The only way to check whether a substitute is ‘correct’ is to actually perform the build yourself, and compare, thus negating the whole point of substitution. However, the ‘guix challenge’ command is an example of how you could perform randomly sampled comparisons between different servers and/or your own machine. <civodul>janneke: for gcc-core-mesboot0 it’s at the beginning of the ‘build’ phase, but i can’t really make sense of what’s happening <civodul>lemme try again with #:parallel-builds? #f (i had tried to turn it on) <nckx>Franciman: Most mismatches (and hopefully, all mismatches you'll encounter in practice) are innocent, simply due to the fact that many builds are not yet guaranteed to be bit-identical. <janneke>civodul: also, these locale changes were what triggered this new commencement rebuild; apparently any earlier rebuilds just succeeded? <janneke>so either somehowe this locale change does have impact, or we're having terribly bad luck? <Franciman>is it possible to guarantee bit identicity? nckx ? <Franciman>i thought the nondeterminism of compiler optimizations have their weight <civodul>janneke: yeah i wonder; it might be that it’s non-deterministic <civodul>janneke: seems to work better with #:parallel-builds? #f <civodul>so it might be that this old ‘make’ is buggy? <janneke>civodul: ah yes, that does sound vaguely familiar <civodul>janneke: do you remember the reason for chosing 3.80 for ‘gnu-make-mesboot0’? <civodul>i wonder if we could pick the latest one, or if not, 3.82 <janneke>civodul: no, i only remember being happy to finaly having found a version that worked... <janneke>...but at the time the bootstrap was also using ancient awk/grep/sed... <janneke>...which have been replaced by gash/gash-utils or newer versions i think <janneke>civodul: maybe it's worth looking at what live-bootstrap is doing, although they don't use gash/gash-utils just yet <janneke>ACTION wonders if stikonas has ideas/insights about this <nckx>Franciman: I don't think compiler optimisations (-O3) should inherently result in non-deterministic output. IME what causes more problems is optimising the build process *itself*, e.g., building in parallel (make -j64). Building software with -j1 ‘fixes’ a good amount of nondeterminism in exchange for your patience. <Franciman>i come from debian, where I had 0 issues. Here on guix i had a small issue once, i just rolled back and worked like charm again <Franciman>then reupdated after a bit, and kept working like charm :) <nckx>Happy to hear that, but I think its prudent to expect to encounter more issues/bugs/jank/TODOs/and otherwise unfinished businesses on Guix than on Debian. Most would just say it's worth it. <nckx>Most Guix users, that is. <Franciman>oh ofc, i agree. But it was stabler than i thought <janneke>stikonas: great (i can imagine bash-2.05 or some of the other tools had problems building newer makes, but don't really remember) <redacted>Is there any guix merch? I want to switch to guix, but that'll deprecate all my Arch Linux t-shirts! <stikonas>janneke: no, bash 2.05 definitely works with make <stikonas>fossy was building bash 2.05 with custom written makefiles... <stikonas>and in any case make 3.80 shouldn't be that different from 3.82 <janneke>stikonas: yeah, every piece of ancient software that we can leave behind is progress <stikonas>well, make 3.82 is not that old, it's from 2010 <stikonas>and we are limited by 2014 with GCC too... <janneke>as for GCC, i guess we'll just have to consider 4.6.4 to become a (very very) long term support release <stikonas>is 4.6.4 actually any better than 4.7.4? <janneke>as such, getting gcc-core from 4.6.4 is a lot less painless than 4.7.4 <stikonas>well, 4.7.4 does have a bigger tarball... <stikonas>ok, and it doesn't have any impact on kernel bootstrapping anyway <stikonas>5.7 kernel had minimum GCC set to 4.6 and 5.8 needs GCC 4.9 <efraim>nckx: they might also be looking on mastodon <nckx>Hmm, did I miss a joke? I feel like I missed a joke. <vivien>For instance, #67162 was last modified mid-november, and QA still ignores it. <podiki>"cannot build missing derivation" on cuirass...anything else to be done for that other than restarting builds? <vivien>(well, no, it has not ignored it, but it has never tried building it) <vivien>#67163 is an example issue QA has never picked up. <vivien>It’s frustrating to see all these juicy updates sitting in an issue and not knowing if they will ever get processed <recj>I am trying to learn to use guix with python to configure the environment, but it seems that I am no longer to import the django library after upgrading it to resolve one of those "try upgrading both errors" <recj>I ran `guix upgrade package1 package2` <ieure>recj, Do you have a specific question? I can't really tell what you want. <recj>ieure: sorry for not being specific. I really have two questions: 1) how are these paths resolved when using guix? I don't remember having to set PYTHONPATH or anything manually before and 2) is there anything I have to do so I don't get the ModuleNotFound errors <ieure>recj, What are you doing, exactly, which causes a ModuleNotFound exception? <ieure>For Python packages, Guix adds a sys.path entry which points to a derivation which is a directory full of symlinks to the specific packages. <ieure>ex. if I run `guix shell python python-django' and run `python3' and print out sys.path, /gnu/store/ikjl5qnbgs73lh63y6cxyvwzzzj653n5-profile/lib/python3.10/site-packages is an entry in there. <recj>ieure: so those /gnu/store/ paths? <recj>It happens even when trying to run a python shell and import a package <ieure>Please paste the exact commands you're running. <ieure>If I run `guix shell python python-django', I can run `python3' and `import django' and that works fine. <ieure>But I don't know how close that is to what you're trying to do. <recj>If I run `guix shell` with the dependencies, it works fine, but it doesn't work outside of that environment anymore. For example: `guix shell python python-django python-pytzdata python-faker` and then `import django` is fine <vivien>Isn’t that how it’s supposed to work? <ieure>Right -- guix shell is a temporary environment. <recj>before, it was working when i went to my project directory and ran `python3 manage.py runserver`. I didn't have to be in a temporary environment <ieure>recj, So run `guix install python python-django python-pytzdata python-faker' <recj>now I am getting "ImportError: Couldn't import Django. Are you sure it's installed and available on your PYTHONPATH environment variable? Did you forget to activate a virtual environment?" <vivien>guix shell python python-django is how you “activate [the] virtual environment” <ieure>recj, If you run `guix package -I', is python-django in the list of installed packages? <vivien>Also the answer is often log out and log in <recj>I tried that one already lol <ieure>Yeah, your shell is pointing at an outdated profile. <ieure>But really, I think you're doing it wrong. You *want* to use a `guix shell' for this, since that's the Guix native way of doing pyenv/venv-style things.. <ieure>You can write a manifest for your project to make that easier. <recj>ieure: I definitely don't disagree with you there <recj>Yeah, I plan to do so. So if I write a manifest, I can just point to it and create a virtual environment from the manifest, right <ieure>Yes, using the -m argument to `guix shell'. <recj>I did suspect that my shell was pointing at an outdated profile, but I'm still not completely sure why that is the case after logging out and back in <recj>I'm also using exwm and often use different shell buffers in emacs, so ideally, I would like to make a setup that uses the manifest for those shells when developing this project <ieure>I'm not sure why that would happen either. <ieure>I'm also an EXWM and shell-mode user. There might be some guix shell integration in emacs-guix, but I'm not sure. <ieure>Would be pretty simple to implement if not, just need to let-bind explicit-shell-file-name / explicit-bash-args before calling (shell). <recj>OK, well I'll look into whether or not it exists. If not, might be a good thing to add since as you said, it's pretty simple to implement. Thanks <civodul>janneke: it’s working now without parallel builds… so i’ll try an upgrade to 3.82 later <attila_lendvai>civodul, yep, i'm running my shepherd branch with this, and it seems to be stable now. i haven't tested it a lot, but prior to this it hung repruducibly. <civodul>attila_lendvai: excellent, good catch! <civodul>i wonder what test we could write for this <civodul>IIUC, the bug would happen when registering a new service, right? <civodul>because then we’d go through the registry, and the registry would see current-process-monitor = #f <attila_lendvai>civodul, debugging this would have been hopeless without the numerous logging/error handling patches in my branch. i just backported this to vanilla shepherd to avoid the delay. <attila_lendvai>civodul, tests/replacement.sh catches this. if you only add the asserts, but not the fix, then that test fails <civodul>it would be good if it would catch it in some other way too <attila_lendvai>i just recorded the commits so that the codebase remains clean when bisecting <civodul>like, why wasn’t tests/replacement.sh hitting this bug? <civodul>it’s not a good test if it doesn’t find bugs :-) <civodul>oh, that’s because it’s not starting any process i guess <attila_lendvai>civodul, i think it's also enough to do something with the replacement that requires the process-monitor. e.g. the service should exercise fork+exec-command or something like that. <attila_lendvai>civodul, after you load the config, and the replacement happened, do something that uses the service-controller of the replacement. a simple herd status is not enough IIRC. <civodul>anyway great debugging journey, thanks a lot <attila_lendvai>civodul, my pleasure! more is in the works, but those will need some negotiation regarding style... e.g. in my own code i prefer a strict format for log lines, e.g. (log.info "msg..." arg1) all in a single line, without length limit. this entire line can then be matched and colored gray in emacs, so that log lines don't disturb code readability too much. for now i'm recording my commits with this style. ultimately i'm <attila_lendvai>willing to rework them, but first i'll try to sell this first, because it has worked out well for us in countless lines of lisp code. <apteryx>is adding my user to the cdrom group enough to be able to read .wav tracks from a compact disk? <nmeum_>can i somehow configure environment variables in my guix.scm that are then set in the environment spawned by `guix shell`? (I want to use Haskell's Cabal build system from inside `guix shell` but it requires unsetting GHC_PACKAGE_PATH to work correctly)