<dissoc>what is the best way to write services? packages has install-from-file. what is the best workflow for writing and debugging services? <dissoc>i currently have a channel but debugging is painful. as i have to push and pull and it takes a while <dissoc>ultimately im trying to add authorized-keys for the tor-hidden-services. where authorized-keys would a list of files. it's a relatively simple change. i just dont know what the optimal workflow for something like this is <fnstudio>sorry, quick check in case i'm missing something, i entered an env with "guix shell gwl", and i was expecting to be able to use "guix workflow" from within there, but i was wrong <fnstudio>i'm on a foreign distro though, so maybe that gets in the way somehow? <fnstudio>if i run "guix workflow <filename>" i get "guix: workflow: command not found" <fnstudio>i have the feeling i'm missing something embarassingly fundamental :D <drakonis>fnstudio: ah yes it has to be in the load path <fnstudio>drakonis: hm, sorry, not sure i fully get that <fnstudio>what has to be in guile's load path? guix? gwl? <fnstudio>ah... interestingly i do see a symlink to gwl in my $GUILE_LOAD_PATH folder already... <fnstudio>nope, no success, both $GUILE_LOAD_PATH and the COMPILED counterpart contain a reference to gwl <fnstudio>what i mean is that they point to folders, which in turn contain symlinks to gwl <drakonis>rekado: would you know how to get gwl working? <drakonis>guix install and shell don't put it into the load path <fnstudio>hey drakonis you definitely put me on the right track <fnstudio>"in order for Guix to learn about the “workflow” sub-command provided by the GWL..." <fnstudio>"the Guile module (guix scripts workflow) must be found in a directory on the GUIX_EXTENSIONS_PATH" <fnstudio>so it was a matter of configuring this env var for me: export GUIX_EXTENSIONS_PATH=/home/user/.guix-profile/share/guix/extensions/ <fnstudio>now, workflow gets detected as a subcommand, i seem to have other issues but potentially unrelated <fnstudio>if i try to run a simple gwl script (a hello world process), it complains that error: source expression failed to match any pattern: process <fnstudio>drakonis: thanks for your help, much appreciated! i'll keep you posted once i manage to run some script <ytc>how can i install packages defined in a file system-wide (in /etc/config.scm) ? <lfam>What do we think about removing packages that don't build since the most recent core-updates merge? <lfam>Should we be more aggressive about removing broken things? Currently, we just let them sit <lfam>A drawback of allowing them to remain is that they appear in `guix show` and the web-based package list, misleading users <apteryx>I personally think it's OK to let them sit until someone notices and wants it fixed <apteryx>unless they are like really old unmaintained Python 2 things. <lfam>I have held a similar opinion, although I also feel confident removing them, when I think of it <lfam>They express a valuable point of view, in my opinion <lfam>It's a point of view that is somewhat ignorant, but nevertheless I'm sure it's a very common one, and thus I think we have to address it on its own terms <lfam>My actual reply did not hit the archive yet <lfam>Only my first reply about some details <lfam>The question of broken packages reminds me of my feelings about the web sites of some older distros, which have many broken or semi-abandoned interfaces to exploring the distro. That was a big factor in why I never got involved with those distros; it was frustrating and confusing <lfam>I'd hate for our packages to give a similar impression ***califax- is now known as califax
<lfam>Like, if our web-based package database says we have a package of foo, so you install Guix in order to get foo, and then find out that foo hasn't built for 6 months... that's a bad impression <bdju>still no Sway option in the installer :( <bdju>and yet EXWM is there, lol <lfam>Has anyone been working on it? Is it related to the seatd / greetd stuff? <bdju>dunno but I run Sway usually and I'm doing a new install atm <bdju>I run it without a DM and I think I use elogind <bdju>seatd or whatever is pretty new but prob also works <lfam>Okay, I'm just wondering if we dropped the ball on some contributions towards offering sway in the installer <bdju>the installer actually seems decent so far. the option to install CUPS is nice <bdju>haven't done an install in a year or two <bdju>one complaint, I dod the guided partitioning and I kinda wanted to double the size of the boot/efi partition just because, but don't see an easy way <bdju>I would have to delete both boot and / and remake them I think <bdju>I'll probably take the defaults, this part of the install is my least favorite <bdju>what does the ESP flag do? <bdju>>Boot (and esp) flags are not necessary for linux (if partition table is set and correct) but windows must have a boot flag to work. <lfam>" The ESP is a partition formatted as FAT32. One ESP must be present in all GPT formatted disks. " <bdju>it's not checked by default. should I check ot? <bdju>no mention of it in my old config.scm <bdju>ugh... backtrace after starting the formatting <lfam>Are you able to send a picture? <lfam>Also, is this with the 1.3.0 installer, or the "latest" installer? <cytokine_storm>(guix install: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory) <cytokine_storm>first time installing guix on devuan and im getting this error. i installed using the script. <bdju>lfam: yeah, just sent an email to bug-guix with one <lfam>cytokine_storm: It probably means that the guix-daemon is not running. Can you share the link from which you got the installer script? <lfam>What does devuan use for running services? <bdju>looks like sdc (mentioned in error) is the installer flash drive <bdju>did not re-read enough haha <bdju>went from after partitioning to during formatting while writing it <lfam>Can you check if that happened? <bdju>having to start over entirely in the installer wizard really sucks <cytokine_storm>lfam: (/etc/init.d/guix-daemon: line 32: daemonize: command not found) this was in the log. after getting (daemonize) problem solved. thanks <lfam>Do we need to adjust the installer somehow? <lfam>Do any other distros still use sysv? Do they use daemonize? <lfam>I take it that devuan doesn't use daemonize? <lfam>What should be done if daemonize isn't available? What does devuan use instead? <lfam>We'd like to make it work better though <bdju>wait, is boot supposed to be ext4? I'm used to it being fat. never done an encrypted install before <bdju>it seems to default to ext4 <lfam>cytokine_storm: That bug report is quite familiar... <lfam>Well, the final question in that discussion stands <lfam>How do we adjust guix-install.sh to have optional dependencies <bdju>actually a pic I took from the first time showed it was fat32 and somehow it became ext4 this time. set back to fat32. another backtrace with same error <lfam>bdju: Is this with the default partitioning suggested by the installer? <bdju>will probably have to go to bed without a working machine as I feared <bdju>lfam: sizes, yeah. I changed the names and made root btrfs <bdju>sozes and most other bits default <bdju>I expected problems, though nothing in particular. the install of guix system has always been stressful for me and a bit difficult, but if you can make it past that, things tend to go okay <bdju>if I don't view the details of /boot it tells me ot can't read /dev/sda1 and to formst it, they if I select it, it becomes ext4 by default and format is set to no <lfam>Can you send that to your bug report? <Ribby>Just a question, does UEFI (secure) boot mode (found on 64 bit computers) deal with proprietary licensing restrictions? <lfam>Can you explain what you're asking? <bdju>same backtrace setting boot to btrfs <bdju>will try installing from a different flash drive <bdju>this other one I prepared isn't even booting. hm <lfam>The most common issue there is that the flashing did not complete before the drive was removed <Ribby>Just what is UEFI (secure) boot mode? Does it interfere with Guix or GNU? <bdju>uefi works with Guix System <bdju>secure boot used to only work with Windows, but I think some distros support it <dcunit3d>that requires that you set up a TPM module (usually on your motherboard). it's apropos to a lot of proprietary stuff. it's possible to configure in CentOS, but kinda difficult. you have to get a signature of the system you're loading and the TPM stores that, so that it can be checked on boot. <bdju>my second drive booted on the second try, got past formatting this time <bdju>oh my god. hit edit on the system config preview screen, new backtrace <dcunit3d>i'm probably mincing words there, but ... i think it's planned in Libreboot eventually, if its not already supported <lfam>I can reproduce that bdju <lfam>bdju: I'm reporting that in a separate bug report <bdju>wow the ncurses thing got messed up, started typing symbols <bdju>C-c'd and got sent back to the start <bdju>got old backtrace again but it listed the drive I'm installing *to* this time <lfam>It's frustrating bdju. The installer was working fine when I tested it extensively in December <bdju>should I use a different date's image? <bdju>is 1.3.0 stable any good? I have that on the ventoy drive also <bdju>I'll try it and if it fails I'll have to continue tomorrow <lfam>We are trying to avoid the pitfalls of the 1.3.0 installer... it was very crashy <lfam>Do you have a Guix development Git checkout? <Ribby>Remember to figure out how to reformat on what device. Of course, you can try that binary installation method. <Ribby>*device, not just storage media, but the supporting OS platform as well. <lfam>bdju: I added these bugs as release blockers <bdju>okay should I hit edit or take the default system config? made it back this far with the 1.3.0 installer <bdju>if I can get it installed I could edit it later... although I don't even know if it comes with vim so far <lfam>So, assuming the partitioning is how you want it, I always recommend starting with the most basic / default system <lfam>Later you can change the system <bdju>so far so good, downloading packages <lfam>It doesn't come with vim, but you can always `guix install vim`. It does come with nvi, which is a basic old-school vi implementation <podiki[m]>partitioning seems to be a weak spot of the installer, which is understandable given how many factors there can be; is it easy to manually partition but still use the installer? <podiki[m]>(I don't remember if I was able to or if it caused other errors, but last summer) <lfam>To be honest, given the state of the installer, doing a manual installation seems easiest to me <lfam>At least if that crashes, you are still in the console and able to keep working <lfam>Whereas these crashes in the graphical installer seem to require a reboot <bdju>I did a manual install the very first time I got guix system (guixsd at the time) but I recall needing a lot of help <lfam>That advice dovetails with my advice to install the most basic system possible <bdju>might go better these days I guess <lfam>Like, adapt the bare-bones template to account for your storage and filesystems <podiki[m]>lfam: right, start with easy template config <lfam>It's terrible that this is the best way to go <podiki[m]>maybe later (longer term) use a more full fledged live image (desktop environment) to try out a config file and tweak it, then use that in the installer? but seems the main stumbling blocks are more paritioning <podiki[m]>or then can use graphical partitioning tools if a user wants <podiki[m]>I haven't tried Arch's new installer, but for forever doing it by hand was the only (Arch) way; people make a thing out of it though <podiki[m]>does such a thing push more users away rather than getting them used to the distro's expectations? I don't know <lfam>I've had good experiences with Debian's graphical installer. It's definitely possible to make something that works well <lfam>The thing is, although we are happy if Guix helps people understand their computers more deeply, they shouldn't have to learn about all that in order to use Guix <bdju>I really feel I earned the "Congratulations!" message at the end of the installer this time... <podiki[m]>right, it is a tricky balance and I do think in general installing should be as easy as possible so you can start having fun with the distro <lfam>Yeah, getting started should "just work" <bdju>my god luks took its sweet time decrypting... I thought maybe I typed the key wrong <podiki[m]>did the polkit vulnerability come up in chat today? is that not applicable to guix (with how we do setuid and paths?) <bdju>huh. is it normal I need to enter the FDE pass twice? at grub and at guix system it looked like <podiki[m]>bdju: isn't there a forced delay? I thought I read that somewhere (it takes a few seconds on my non-guix laptop too) <lfam>I think the twice thing is expected with LUKS on Guix bdju. I don't recall the details <lfam>Dunno about the polkit thing. I'm sure it needs to be fixed in Guix! <vagrantc>yeah, once from grub and once from the initramfs <bdju>podiki[m]: not sure about a forced delay, would make sense I guess. was faster the second time <lfam>I also got a DSA about util-linux. Not sure if we've updated past it or not <lfam>Lol: "Improper UID check allows an unprivileged user to unmount FUSE <lfam>filesystems of users with similar UID." <podiki[m]>guix refresh util-linux says 2.37.2 to 2.37.3 <bdju>thanks for being here with me through the install process, lfam. will copy data ofu my old drive and configure more stuff tomorrow probably. <lfam>All these packages will require grafts, assuming these types of bugs can be fixed that way <lfam>None of them can be changed on master <lfam>There's also that Rust bug <podiki[m]>yeah, 2.37.3 is the newer security fix (as of a day ago) <apteryx>how about we put it on the staging branch along rust 1.58.1, have that built, then merge back into master? <podiki[m]>there's a commit for polkit to fix it, but no new tag that I see right now <podiki[m]>wasn't that needed for....working around something rust related? via mozjs...? I can't remember <podiki[m]>(I believe it was done for some architectures in the core-updates-frozen changes) <lfam>Does the staging branch have anything else on it apteryx? <lfam>I'm worried about continuing to make big changes to the distro when we are trying to iron out bugs in order to release <apteryx>lfam: it's empty except a patch bump to git <lfam>I feel like the snippet in util-linux is something we'd put in a build phase now <lfam>Something for core-updates <apteryx>yeah; we'd be abusing the branch a bit (busting the 1800 packages rebuild), but maybe not by much <apteryx>ah, util-linux is a world rebuild correct? <apteryx>then grafting is probably the best course of action (+ a fix to core-updates) <lfam>Although we distinguish between staging and core-updates numerically, I think that's more of a proxy for the impact of the change on the entire distro. So, a change to the docs of GCC could go on staging, if we had the build capacity <lfam>This util-linux release is only fixes for these 2 CVEs. So I think it would be "safe", at least <apteryx>currently we're a bit low on storage to start big rebuilds often, but that's about to change (we have about 30 GiB of usable SSD storage waiting to be deployed) <lfam>I'm working on the util-linux graft now <lfam>It would be great if others could assist with those other bugs we were discussing <lfam>I do think it's best to try to limit the scope of the changes with grafts. That is, cherry-pick upstream patches rather than take big updates. It makes it easier to undo the graft quickly later <lfam>Obviously some patches can't be cherry-picked <podiki[m]>polkit looks like just 3 commits since the release we have <lfam>That's good news podiki[m] <lfam>I don't really know much about polkit, so I don't know how "graftable" it is <podiki[m]>duktape (which we might be using the same commits?), the cve, and I think one other that is also CVE related? <lfam>The util-linux bugs are in libmount, which I'd guess is mostly used via dynamic linking. So, definitely graftable <lfam>The duktape thing, does that add a dependency? <podiki[m]>the lines of code at least is quite minimal, but also don't know polkit at all <podiki[m]>that if I remember correctly guix has on some archs due to mozjs/rust/something issues <podiki[m]>but I don't know offhand how it is currently coded up <lfam>It will require some investigation <lfam>I'd say the grafted change should limit itself to fixing the CVEs <lfam>But it requires some polkit knowledge to be sure <lfam>Huh, so we already have the polkit change? <podiki[m]>but yes, seems to be a separate thing, though all the commits were the same day (today), duktape is an old (resurected) merge <lfam>Or is it a variant of the primary polkit package? <podiki[m]>not sure how much it changed, sounded close to final when we used the wip patches <lfam>util-linux 2.37.3 fails to build due to a bug in the makefile that creates the manpages <podiki[m]>looks like it was a separate package but now is constructed via those last commits in the search I linked <podiki[m]>(or yes, is polkit-duktape, but selected by arch) <lfam>It's great. A security update that also breaks the build <podiki[m]>done for the night, good luck and thanks for taking care of it! <lfam>"Below is a short write-up (which is part of a longer advisory that is <lfam>mostly unrelated to util-linux and that we will publish at a later <lfam>And "Consequently, we audited the SUID-root programs umount and fusermount <lfam>for ways to unmount a filesystem that does not belong to us [...]" <lfam>I suppose that more things are coming <lfam>The exploit looks quite fun too <lfam>"For example, on Fedora, /tmp is a tmpfs, so we can mount a basic FUSE filesystem named "/tmp/ (deleted)" (with FUSE's "hello world" program, ./hello) and unmount /tmp itself (a denial of service):" <timmy>has anyone used opensmtpd with mcron? seems that mcron isn't able to send email due to a opensmtpd bug in sendmail? <apteryx>lfam: I didn't follow the polkit thing, but we have polkit-duktape already, which is polkit using duktape as its JS engine instead of mozjs (which requires rust) <apteryx>it's used for all systems but x86_64 <lfam>polkit-duktape already uses package/inherit, so it should do the right thing when polkit-mozjs is grafted <rekado>fnstudio: it just so happens that i’m currently hacking on GWL <rekado>that sentence in the manual got updated first :) <ss2>the_tubular: it looks interesting. The whole toolset even. <gnoo>hello, i don't get completion from bash, and don't know where to start looking ;-; <fnstudio>hey rekado, thanks! it's not that the sentence was wrong, i suppose? more a case of, it might make sense to add it to the tutorial as well, here https://guixwl.org/tutorial and generally to give it a bit more emphasis - i'm sure the new version is perfect, i'll pull from git later <gnoo>oh my god, there's a pokit thing going on?? *gnoo remembers my last rant <rekado>fnstudio: I’m currently hacking on wip-drmaa-2022 <rekado>the sentence was actually wrong. It should have mentioned the extensions directory, not the scripts directory <rekado>fnstudio: may I ask what you intend to use GWL for? (It has a couple of rough edges that I’m about to polish; sorry about that!) <PurpleSym>mbakke: Thanks. It failed again, so I’m assuming it’s a PPC-related issue. <florhizome[m]>There’s a couple different syntaxes and it’s kinda confusing. <fnstudio>rekado: sure, it's mostly a bit of an exploration, i was looking into graphical solutions (e.g. knime) and then i thought... wait... this reminds me of that gwl talk i watched last year <fnstudio>no worries for the rough edges, quite contrarily - thanks for working on it! <efraim>everytime someone says PPC I assume it's powerpc-linux and powerpc64le-linux :) <jbv1[m]>Hi guix ! Philosophical question: how would you explain what "packaging software" means to non-technical people and what problem those it solves ? ***moto7_ is now known as moto7
<jbv1[m]>I have something along the lines of: "it ensures that software that work for the developer will also work on the end-user device" but that sounds a bit limiting no ? <efraim>"... and that everyone has the same working copy of the software" <rekado>software is born as mere text; it has to be converted to executables first. This is very difficult for many silly reasons. Packaging does all that hard work, so that users can easily get the executables. [Add guarantees provided by the package manager if that went well.] <fnstudio>jbv1[m]: ok, here's my go at it :) "Software often comprises a certain number of parts or dependencies, e.g. third-party components, files such as images or sound, etc. In order to distribute a piece of software it is necessary to "package" these dependencies together, so as to make all of them available to the user." <rekado>another thing to weave in: software needs *other* software for the conversion from text to application. So what seems like an easy task for one application can easily balloon into lots of work — packagers do all that work for the user so they don’t have to. <jbv1[m]>haha not really what I had in mind ;) but thanks <teythoon>pulseaudio: symbol lookup error: /gnu/store/a64idcxbd5sndxz61wra9hxwyprsnj10-libsndfile-1.0.30/lib/libsndfile.so.1: undefined symbol: ogg_stream_pageout_fill <civodul>hey teythoon! that's when spawning pulseaudio? <teythoon>yeah, when invoking the pulseaudio binary <civodul>can you make sure LD_LIBRARY_PATH is unset and also check if you can reproduce it with "guix shell -C pulseuadio -- pulseaudio"? <zap>civodul: I've been on the watch for you yesterday! I have a question for you -- when you last time used (email) module found on gnu.tools? <civodul>zap: hi! it was used twice, last time in Feb. 2020 <zap>civodul: ha, okay did you do any additional configuration in maiulutils.conf or .mailrc? Or you were just passing the smtp mailer url to mu-message-send ? <ekaitz>janneke: before I start patching a compiler like a crazy man, I have a question for you. I'm trying to compile gcc 4.6.4 and I get the error "your system does not have /usr/include" or something like that in the build phase. Did you find that issue during the bootstrap? how did you overcome it? <ns12>Hi, if I use "guix pack", can the resulting tarball be used on another Unix-like OS such as FreeBSD? <gordon1>is that normal when i run guix system reconfigure config.scm, every time it downloads different things, builds some other different things and it takes different time every try even if i do not change config.scm and run guix system reconfigure one after another? <rekado>gordon1: only if you change “guix” in between, e.g. by running “guix pull” <efraim>gordon1: you have to run `guix pull` after install, otherwise you keep on going back in time with an older and older guix binary and cached package definitions <gordon1>no, i didn't do guix pull in between <gordon1>so there is something wrong with my installation then? <efraim>run `guix describe` then `hash guix` then `guix describe` again <efraim>if the two `guix describe`s are the same then you're not going back in time <efraim>if they are different then you're now on the "correct" guix anyway <gordon1>so it finished doing reconfigure again, i can try to do it one more time <gordon1>and see if it tries to download and build something else again <gordon1>in my history it is literally guix system reconfigure config.scm ; guix describe ; hash guix ; guix describe ; guix system reconfigure config.scm <gordon1>and last time it actually decided to rebuild guix itself and it took like 1 hr <civodul>zap: just passing the smtp mailer URL, which is something like "smtp://USER:PASS@host.example.org:587" <gordon1>guix complains about provenance every time i run reconfigure (no clue what it is yet), i wonder if that might be the issue <civodul>ekaitz: re /usr/include, i think you can pass GCC's configure --without-headers or --with-native-system-header-dir=... <ekaitz>oooh yesss I was just reading about it thank civodul! :) <civodul>ns12: the result of "guix pack" can only be used on a system that implements Linux syscalls: GNU/Linux, Android, WSL, and maybe some BSDs that have the compatibility layer turned on (not sure about that one) <gordon1>did it again - now it downloads 138 MB of package <ns12>civodul: Okay. I guess the result of "guix pack" will not be usable on FreeBSD. <civodul>it might be, but it's not guaranteed <zap>gordon1: does guix which points to ~/.config/guix/current/bin/guix? <ns12>civodul: I don't think Linux emulation on FreeBSD is good. I'll guess stick with the FreeBSD ports tree (or pkgsrc for a cross-platform solution). <gordon1>zap: which guix points to /run/current-system/profile/bin/guix <zap>gordon1: and is "$HOME/.config/guix/current/bin" in your PATY? <gordon1>/run/setuid-programs:/home/gordon/.config/guix/current/bin:/home/gordon/.guix-profile/bin:/run/current-system/profile/bin:/run/current-system/profile/sbin <zap>gordon1: I think it needs to be at the front of PATH <gordon1>it's just a fresh install of guix on VM, didn't change anything besides few additional services like ssh <gordon1>but anyways, i'm doing sudo guix when i'm doing reconfigure <zap>civodul: hmm strange I think ther could be regression in mailutils or mailutils package is broken, thanks for info :) <gordon1>so i guess that's about what root has in its PATH <zap>instead of wich you can also use `command -v guix` <zap>gordon1: I've had something similar in the past -- don't remember what exactly caused it. But I vaguely remember it had something to do with the fact that I was spawning wrong guix <ekaitz>civodul: in 4.6.4 it doesn't work T_T <gnoo>gordon1: is it downloading some .tar.gz files? <gnoo>i remember there was a problem with the substitute servers and thus guix install downloaded a lot of things to build the package locally <gordon1>not sure, just shows that it is downloading some packages like that: <gordon1> guix-1.3.0-15.f98edfa-checkout 8.7MiB 2.8MiB/s 00:03 [##################] 100.0% <gordon1>it doesn't look like it actually builds anything but guix <gordon1>rest of the stuff installs quite swiftly <gnoo>it builds the current profile <gordon1>oh, sure, i thought you mean "compile the package" by "build" <gnoo>oh, i thought you meant that :P <gnoo>did you do guix pull after installing guix but before installing any packages? <gnoo>and from which user? with/without sudo? <gordon1>so i did what the guix handbook told me, booted install iso, made some config (based on desktop.scm), did guix system init, rebooted, did guix pull and hash guix <gordon1>and then tried to do system reconfigure multiple times w/o changing the config <gordon1>and it started to do this weird behaviour of downloading stuff every time i invoke ti <MysteriousSilve4>hello! i've installed dwm from `guix install dwm`, how would i launch it? (preferably through gdm) <gnoo>MysteriousSilve4: what if you click that wheel or something in gdm? there's a dwm.desktop so it should work as normal <gnoo>the last time i worked on polkit was to remove it from my system ;-) <gordon1>oh, good news if that's possible on guix (if that's what you're running) <gnoo>yeah, it's possible on guix. a shame that removing dbus is much harder <gordon1>i wonder if it would be possible to get rid of udev, it looks like it is nailed shut <gordon1>well, at least with my current config i managed for guix not to install dbus <gnoo>hmm, are there any replacements for udev? isn't it supposed to configure hardware ? <gordon1>tho there is literally nothing there now <gnoo>gordon1: i highly doubt it that you don't have dbus if you're using guix <gordon1>and there is udev-zero daemonless replacement built on top of mdev <gordon1>well, at least herd status shows no such service <gordon1>but there is literally nothing on the system right now <gnoo>i have 4 dbuses one of which is user dbus and 3 are started by herd ;-; <gnoo>i don't even know where to look to remove dbus, it's everywhere <gordon1>oh btw is dbus separated into :out/:bin/etc outputs? <gnoo>does the dbus lib not require a running dbus daemon? i'd guess it does <gordon1>well, i don't really care if it does, the only thing i need is for software that nailed shut to it to be able to compile <gnoo>there's dbus-system that is ran by herd <gordon1>that's pretty much how i run my current linux now ***aya is now known as gyara
<gordon1>but that will be next step of my endeavor with guix, first i need to figure out how to properly reconfigure the system :) <gnoo>i had to reinstall guix 4 times for it to work properly :P <gnoo>on one hand, it was my fault, on the other, guix apparently can't install to both uefi and bios, which i think would be much better <gordon1>as far as i understand guix has variety of tools to modify recipes, including modification en mass, so i guess i can come up with something that gets rid of dbus system-wide <gnoo>yeah, there's grafing that can, with some effort, remove dbus <gnoo>i don't yet have the scheme skills for that <gordon1>though i understand that replacing udev with mdev will be much harder <gnoo>in the above url, you can see how polkit is replaced by polkit-mozjs/fixed. i think the only way to remove dbus will be to do the same <gnoo>can i inherit a package but modify only one of it's phase? (something like after-install?) <gnoo>it's to set a default value in a config file <allana>Hi guix! I have a guix/guile (mostly guile) question. What is the canonical way to use dynamic-link of the system foreign module? For example, if I have libfoo installed in my profile, (dynamic-link "libfoo") will fail, but (dynamic-link "/home/allana/.guix-profile/lib/libfoo") will work fine. If I am writing a guile package, how do I ensure that it can find libfoo under other profiles? <MysteriousSilve4><gnoo> "MysteriousSilver: what if you..." <- nah, there aint no dwm in gdm <gnoo>MysteriousSilve4: you installed the default dwm with 'guix install dwm', right? that one provides a dwm.desktop which should be picked up. if you did 'make install' then it won't work, you can make your own package in that case which inherits from dwm <gnoo>maybe someone else who uses gdm can chime in ;-) <gnoo>there's this line: (with-output-to-file (string-append xsessions "/dwm.desktop") <gnoo>oh wait, maybe you need to reconfigure your system after adding dwm to the list of wm <gordon1>ok, i did yet another guix pull and the problem of random downloads every guix system reconfigure went away <zap>gnoo: regarding package phase modification you use package-arguments with substitute-keyword-arguments and modify-phases <gnoo>zap: will it work if i already have a modify-phases in a package and want to add to it for another package? <gnoo>ohh, i see, you use something like what python-pandas-0.25 does ? <gordon1>is there a way to stop bootloader from installing? <zap>gnoo: not sure I got you completely. You want to to inherit package b from package a and you want to modify package b phases be modified-pakckae-a-phases? <gnoo>yes, package 'a' already has some modifications, and package 'b' is a light skin on top of that, but with some patches <gordon1>i have coreboot with grub, it uses grub.cfg from my system, i just don't need the installation phase (or grub package as well i think) <gordon1>but i still want grub.cfg to be generated <gnoo>it's one of the phases, i think, you can remove that, not sure how tho <zap>gnoo yea its possible <zap>i haven't done it thoug :D Where did you get python-pandas-0.25? I didn't find it in guix/ <gnoo>i just searched for substitute-keyword-arguments in guix source <gnoo>since it wasn't on guix manual <zap>maybe we're on diferent commits I didn't find python-pandas-0.25 <gnoo>maybe, it's in gnu/packages/python-science.scm <zap>should be something like (substitute-keyword-arguments (package-arguments a) ((#:phases phases) `(modify-phases ,phases <YOUR-MODIFICATIONS>))) <vldn>Are the wine64 substitute still Not avaiable? <gnoo>it looks like python-pandas-0.25 was removed and now there's python-pandas-0.24.2 <vldn>The cause why guix weather and guix build Shows and gets the subs but guix Shell and guix package -i doesn't <MysteriousSilve4>would it be possible to have the git-fetch url as a directory in the same file-system? <MysteriousSilve4>file://link/to/directory returns "does not appear to be a git repository" <zap>MysteriousSilve4: I used local-file for that once <gnoo>MysteriousSilve4: (source (git-checkout (url ""))) <gnoo>i don't remember if it needs file://, i'd try first without and if it doesn't work, use file:// <zap>like that: (local-file %srcdir #:recursive? #t #:select? keep-file?)) where %src-dir is your source directory and keep-file? is file filtering function <gordon1>so bunch of packages are actually pinned to version, is there an easy way to build package from git master? <MysteriousSilve4>gnoo: where would i add the sha256 information (although it builds without hash) <gnoo>gordon1: it's not recommended but you can use git-checkout as above <gnoo>not recommended because guix leans towards determinism <gnoo>MysteriousSilve4: you don't. it uses the latest git checkout available, whose hash can change at any time <gordon1>i respect that, it's just some packages has to be unpinned to work reliably, like yt-dlp <gnoo>MysteriousSilve4: you can probably do something like this to make it work tho: (let ((comm "") (revision "0")) (source (origin (method git-fetch) (uri (git-reference (url "") (commit comm))) (sha256 (base32 ""))))) <gnoo>where the let part comes after define-public and before (package) <gnoo>gordon1: you can make a simple package that only replaces the source part and inherits everything else from yt-dlp, just call it my-yt-dlp <gnoo>(it will still have the binary called yt-dlp) <gnoo>grafting is required if you want to change the inputs of other packages <gnoo>which in this case you probably don't ? <attila_lendvai>looking at the graft issue, my completely uninformed gut instinct says: unintentional variable capure by a closure! <gordon1>so is my understanding correct: if i need to modify existing package definition i just create package that inherits the old one and do my changes there, and if i for example made some new version of a package and i want to replace it in the system for every other package that depends on it - i need grafting? *attila_lendvai continued reading and realized he spoke too early <gnoo>gordon1: yes, that's my understanding as well, not sure how much of it is correct tho <gnoo>how do i set some scheme variables for guix to use in 'guix install' and such ? <gnoo>i want to change %default-profile-hooks <civodul>gnoo: this cannot be changed from the command line <gnoo>can i change it in a file? <vldn>Append or modify the list via your config.scm <gnoo>~/.config/guix/config.scm ? it's not there so i should create it? <vldn>Are you on a foreign distro? Or guix system? <vldn>Then maybe modify the list within your system config file that you are using for guix system reconfigure :) <MysteriousSilve4>building `linux-modules` fails (probably because the kernel is older than it) in system reconfiguration <gnoo>that works for something permanent but not for some quick and check tests :) <vldn>Then inside your package definitions or the SCM File that you want to test <gnoo>this xdg-mime-database is taking too much time so i want to remove it, something like: (define-public %default-profile-hooks (delete ... %default-profile-hooks)) ? <gordon1>is there a guide or collection of examples how to do non-trivial package variants? <gordon1>so for example i want to modify busybox to include some options to config and add a verification step that those are turned on after make oldconfig and fail if they're not <gnoo>gordon1: you can change an build-phase for it <gnoo>info "(guix) Build Phases" , you can add things before or after or even replace the predefined phases <gnoo>see zap's message above for steps required for package that inherit other packages and still want to keep old phases <bdju>can someone give me an example command for mounting a btrfs drive? I'm struggling here <bdju>tried this: sudo mount -t btrfs /dev/disk/by-id/ata-Samsung_SSD_860_EVO_500GB_S59UNJ0N128003L-part3 /mnt/usb -o gid=users,uid=brad <bdju>I get this error: mount: /mnt/usb: wrong fs type, bad option, bad superblock on /dev/sdc3, missing codepage or helper program, or other error. <gnoo>bdju: what if you omit the -t btrfs ? <bdju>gnoo: tried that first and added it later, same either way <gnoo>can you try path like /dev/sdb1 instead ? <bdju>ehhh I mean yeah but it basically is just converting to that, this is just a more specific wya to refer to the drive <gnoo>yeah, but i was wondering if this specifies the device instead of a partition <bdju>same error using /dev/sdc3 <bdju>the -part3 part is a partition <bdju>might be my -o stuff. don't have a shell history to double check this is what I meant to type. also maybe never tried this with btrfs beforn <bdju>works with no -o stuff but then root owns everything... <gnoo>maybe just try -o gid=wheel,fmask=113,dmask=002 <bdju>maybe btrfs doesn't support the common mount options <gnoo>hmm, man mount says -o should come before the device/mountpoint <bdju>same error, not sure the order really matters <gnoo>yeah, i just guessed because the synopsis shows only 'mount -t fstype -o options device mountpoint' or 'mount -o device|mountpoint' <bdju>I tried -o defaults and that worked. I checked my fstab and that's all my root btrfs drive is mounted with <bdju>I'll see if I can work with that <bdju>another question, is it safe/okay to copy my wsole /home from an old drive to the new one on this fresh install or should I only copy some stuff? <bdju>contents of /home/username rather <gnoo>it's probably ok, i reused my /home from earlier distro <vldn>Whats the standart path the .guix-profile symlinks to on guix system? <madage>bdju: have you tried to use numeric values for the user/group pair? like: '-o gid=997,uid=1000' <vldn>E.g. /var/guix/Profile/per-user/*/current-guix or guix-profile? <madage>as for the other question, I usually do not copy dot files from different OS's as that could lead to subtle quirks <gnoo>for me it's /var/guix/profiles/per-user/$USER/guix-profile <bdju>if I have trouble I'll try that <apteryx>I'm thinking to go with a three subvolumes layout; for /, /etc and /home; is there something we'd like to *not* preserve when snapshotting /, other than /tmp ? <apteryx>don't sweat it though, as it's not crucially important to get it right the first time, we can refine it later <nparafe>-> ice-9/eval.scm:223:20: in procedure proc: <nparafe>hint: did toy forget a 'use-modules form'<- <apteryx>rekado: do you know of a good command line tool to benchmark IO? <rekado>apteryx: we used fio in the past <rekado>apteryx: re subvolumes: I don’t know enough about this <rekado>I don’t even know what subvolumes are and why one would want them other than to separately snapshot parts of the volume <apteryx>that's their main purpose yes; I don't plan to use snapshotting for the build farm, but they could come handy should we want to backup something to a remote machine or storage array. <rekado>nparafe: the problem is with unbalanced parentheses <rekado>nparafe: your operating-system expression ends with “%base-packages)))” and after that you’ve got “(services …) …”. <rekado>nparafe: remove one closing paren after %base-packages <pinoaffe>hi guix! my laptop just lost power while building a package, and saved a corrupted derivation in the store - continuing the build process results in parse errors "error parsing derivation `/gnu/store/....': expected string `Derive(['" <zap>pinoaffe: you can use "guix gc" for that <pinoaffe>zap: `guix gc -D /gnu/store/....` results in guix gc: error: cannot delete path `/gnu/store/...' since it is still alive <zap>it means it already referenced by something... <vldn>@apteryx maybe the /Gnu/Store in a subvolume with Kompression? <zap>pinoaffe: check out "guix gc --help" there are several opions <pinoaffe>zap: I've been doing that, I've tried looking at `guix gc --derivers /gnu/store/....`, that came up empty <pinoaffe>and I don't know what else could make sense <rekado>pinoaffe: have you tried “guix gc --verify=repair,contents”? <apteryx>can I stop the 'guix gc' process on berlin? <apteryx>vldn: compression will be used globally, the problem having a subvolume for /gnu/store is that it isn't complete without /var/guix/. <pinoaffe>rekado: I had started but had (impatiently) not let it run to completion yet, will do so now :) <vldn>I have compression Just for the Gnu Store on a subvolume and IT works perfectly fine *apteryx terminated the 'guix gc' process *attila_lendvai has a build error on libfprint when he tries to reconfigure (it's actually an error in the tests) <apteryx>rekado: currently the array does 150MiB/50MiB R/W according to the same fio command used in the issue <apteryx>I'll see if changing the metadata profile from raid10 to raid1c4 changes anything (doubt so) <apteryx>by the way, looking at dmesg I see lots of segfaults for mumi <tribals>I'm trying to use guix for managing my development environment for a project. So, i created a manifest, added a couple of packages. The project I'm developing is one written in Python. And some Python package - a dependency of project - tries to load shared C library. I decided to deal with python dependencies with Python's package manager - pip. But C library needed by this python package - I want to install it as guix package. Note that it <tribals>doesn't need development files - libfoo.a and include/foo.h - for building "native extension" for Python package. No. It just needs to be able to load it's libfoo.so. Then, I installed guix package for this library "as is" (not specifying any outputs). Unfortunately, python package can't load guix's package libfoo.so. Is there a way to solve this? <apteryx>150MiB/50MiB sounds low but it seems good for this particuliar fio benchmark; on my home machine it wants 1h12 to run instead of 20 s ^^ <apteryx>with live perf like "[r=960KiB/s,w=336KiB/s]" <tribals>The guix package I'm trying to use is `gdal` from `(gnu packages geo)` <zap>tribals: I think for it to work you need to make sure that in the environment you are using for development LIBRARY_PATH var points to directory the where desired .so file is <zap>but from what you explained it is not clear to me where you're using pip and where guix <zap>"the where desired .so"->"where the desired .so" <HONEYPOTTER>How would I go about converting a Debian install to a Guix System install without booting from another device and without preserving any of the old data? <zap>but all files in /usr and such will be preserved -- they don't have an efect on funcionality of the system. You may just remove them <tribals>I thought that when you use guix package which provides some shared libs libfoo.so libbar.so, then loader path is adjusted as needed in generated guix profile. This is not the case for profile generated from my manifest. <HONEYPOTTER>zap: I assume most of those steps aren't required anymore when I use the installation script? <zap>HONEYPOTTER: I haven't used installation script for a long time -- I think its made for installing guix along side with your system but steps are similar <HONEYPOTTER>Just had a thought, what would happen if I dd the installation image to a running system's drive and then reboot? Will everything get corrupted during dd/installation process? <KarlJoad>Hey, real quick. Does someone use stumpwm for their desktop and would be willing to share your Guix system/home config to make that all work? <tribals>"where so desired?" .so desired in guix profile <unmatched-paren>that would probably kill a ton of things needed for dd to even execute properly... <unmatched-paren>not sure dd would even let you do that, i know a lot of disk manipulating tools don't <HONEYPOTTER>Hmm, so I would need a new partition to dd to, then boot from that partition, go through installation, then extend the system partition? zap's recommendation sounds simpler but I am paranoid about junk in my system unfortunately <zap>its like changing the car's engine while you're driving :) <unmatched-paren>guix allowed me to be a lot braver with my system because of rollbacks tho... so i'm not as paranoid now <HONEYPOTTER>zap: then what is live patching? changing the oil while driving? haha <attila_lendvai>my /etc/guix/channels.scm does not understand (version 0) as advertised in the manual. my guix --version is the latest of master. any hints? i want to specify a custom keyring-reference. <KarlJoad>HONEYPOTTER: From experience, `dd` will allow you to re-write a disk, pretty much without questions. Accidentally wiped out the partition table of my disk that way. <zimoun_>After "guix pull", I get /gnu/store/28k5yj520zwqx4vn8ijpgz1irq23dp3r-guile-wrapper/bin/guile: error while loading shared libraries: libguile-3.0.so.1: cannot stat shared object: Invalid argument <HONEYPOTTER>unmatched-paren: oh yeah, that's one of the main reasons I'm switching. But I will still do all updates in VMs until my therapist fixes me. <KarlJoad>And because a running instance of `dd` is mostly in-memory by that point, it should probably continue working, even after overwriting the /bin/dd binary. <HONEYPOTTER>KarlJoad: that's what I figured, but I doubt the image will stay loaded in memory... so maybe the solution is to keep the image in a different partition, dd it over main partition, boot, and let the installer fix up the partition table <zimoun_>unmatched-paren, yes it was probably me and I do not remember to get an answer. ;-) <zimoun_>civodul, I do not know how to debug the root of the issue on foreign distro about "error while loading shared libraries: libguile-3.0.so.1: cannot stat shared object: Invalid argument". Any clue? <rekado>sneek: later tell apteryx I also saw the segfaults; they come from guile-xapian, I think. <civodul>zimoun_: do you have more info? first time you upgrade since the core-updates merge? <pinoaffe>rekado: it took a while, but `guix gc --verify=repair,contents` has finished running, it failed to repair the derivation <zap>tribals: yea it should I think -- as a last resort you can try to source <profile-path>/etc/profile <unmatched-paren>HONEYPOTTER: and even if you ruin grub, you just do some good old-fashioned chrooting in a live usb :) (i had to do this once, not because of guix, but because my laptop's proprietary uefi keeps breaking it, and i don't think my laptop's corebootable sadly...) <zimoun_>civodul, old RedHat 2.6.32-754.35.1.el6.x86_64. It seems it worked couple of weeks ago. At least, I have a working Guix for revision 531a69ec from ~May 2021. <zimoun_>so no upgrade after core-updates merge, I guess. <gnoo>dang, i was troubleshooting for hours why a package won't build properly <gnoo>turns out i was using the wrong git-clone locally (but had the correct one on the package) <gnoo>so none of my modify-phases actually worked <civodul>zimoun_: it may that that our current glibc doesn't support this old a kernel <civodul>we build with "--enable-kernel=3.2.0" <civodul>but OTOH, we apply "glibc-allow-kernel-2.6.32.patch" <civodul>zimoun_: could you run "guix build /gnu/store/4g1k7hsviiq3310qlc0jgjxv1znp7psq-coreutils-8.32.drv" and try the binaries you get? <rekado>2.6.32 just pretends to be 2.6.32 <rekado>the RHEL kernel is *heavily* patched <rekado>so it would be good to see the source RPM with all the patches they apply <rekado>(that’s what I did way back when we tried to figure out if it was okay for us to make an exception for 2.6.32) <apteryx>rekado: could do 170MB/s reads and 56.9MB/s writes now with the same benchmark after converting the Btrfs metadata from a raid10 profile to raid1c4 <sneek>Welcome back apteryx, you have 1 message! <sneek>apteryx, rekado says: I also saw the segfaults; they come from guile-xapian, I think. <rekado>RHEL 6 is now only supported through Extended Life Cycle Support <apteryx>guile-xapian, hmm. Do we have enough information/context to report a bug? <gnoo>does guix have some sort of counter that decides that if 'guix package' has been invoked 'n' times or in 'n' days, update everything ?? <rekado>I reported this to Arun over a year ago, but it’s not easy to figure out what’s wrong. These are swig bindings to xapian. <tribals>zap: that's the problem actually: profile contains only PATH <bdju>I just realized the guix installer neither made me a swap partition nor a swap file... it should definitely do one of those <bdju>I recall the manual install instructions covering both options, but nothing in the guided install <zimoun_>civodul, using a working Guix, it substitutes fine but --check returns the error guile: error while loading shared libraries: libguile-3.0.so.1: cannot stat shared object: Invalid argument <civodul>zimoun_: but could you try the coreutils binaries that you fetched? /gnu/store/y5jxkx484x7s2c2n7dc8wprh5sbps7pl-coreutils-8.32/bin/ls, etc. <zimoun_>civodul, error :-( /gnu/store/y5jxkx484x7s2c2n7dc8wprh5sbps7pl-coreutils-8.32/bin/ls: error while loading shared libraries: libcap.so.2: cannot stat shared object: Invalid argument *civodul goes afk for a bit <unmatched-paren>i have some extra information about the Nimble /bin/sh of Doom(tm), but it's making me even more confused :( grepping for `invocation of external compiler program failed` in $nim/compiler yields two lines in `extccomp.nim`. one is executed if <number of CPUs> <= 1, and the other is after an else for the same if. the multi-core one is rather cryptic, but seems to be executing the $CC on the generated .c files. I have no idea how t <unmatched-paren>involves a bourne shell in any way except when it starts a new process, and the new process procedure in the nim stdlib is already patched to use the /gnu/store sh! <rekado>RHEL6 should be okay with the syscall <rekado>but the documentation for newfstatat says: AT_EMPTY_PATH (since Linux 2.6.39) <rekado>so that’s likely the problem here <zimoun>rekado: ah right. 2.6.32 patched by RHEL 6 does not support that, right? <unmatched-paren>sneek: later tell lilyp: i've made a breakthrough with nim-nimble. a really confusing one. <unmatched-paren>sneek: later tell lilyp: i've made a breakthrough re. nimble, but it's really confusing: building it with the `--parallelBuild:1` flag (to use only one core) works. <apteryx>rekado: when is the best time to reboot berlin? <apteryx>(not to do yet -- but I'll attempt reconfiguration soon to register the new file system) <apteryx>also, there seems to be honeycomb/arm experiments in the maintenance checkout; are these important or can I reconfigure from guix-maintenance master? <PurpleSym>lfam: sanity-check never calls any functions, but Python allows running code during import, so vorta must be writing there during import, even before the script entrypoint was called. That’s usually a bug. <lfam>I can set $HOME=/tmp while building the package to work around it. Beyond that, should we do anything about this? <lfam>It's not a bug that I can meaningfully report upstream, since I don't understand it <podiki[m]>oh vorta, I'll have to check that out later (long pushed back todo list of setting up some more borg backups) <PurpleSym>It’s more of a “code quality” issue, imo, making it impossible to import their modules without side-effects. <lilyp>in other words, it's regular insanity, you can choose to ignore it :) <sneek>Welcome back lilyp, you have 2 messages! <sneek>lilyp, unmatched-paren says: i've made a breakthrough with nim-nimble. a really confusing one. <sneek>lilyp, unmatched-paren says: i've made a breakthrough re. nimble, but it's really confusing: building it with the `--parallelBuild:1` flag (to use only one core) works. <lfam>podiki[m]: You're in luck --- I just pushed the patch <lfam>sneek was probably hungry <lfam>podiki[m]: I'm also testing the upcoming borg 1.2 release. I can send a patch for the beta releases to get more testers <unmatched-paren>what's the proc to recursively copy files? i've tried recursively-copy-file and copy-file-recursively <lfam>unmatched-paren: copy-recursively <podiki[m]>though maybe my desktop will use btrfs snapshots....unless I'm wasting too much since my home subvol contains mostly stuff that doesn't need backup (can exclude in a snapshot?) ***iyzsong- is now known as iyzsong
<unmatched-paren>how do i copy a file from the build dir to the output dir? i'm trying to do (copy-recursively "nimble" (string-append (assoc-ref outputs "out") "/bin/nimble")), but it reports `No such file or directory` <lfam>Which file is "no such file"? <lfam>Like, is it the source or the destination that it cannot find? <lfam>To debug this, you can add things like (invoke "ls" "-la") and (pk (getcwd)) <lfam>I can say that you probably should copy it to "bin", not "bin/nimble" <lfam>Then you should probably adjust the target as I suggested <lilyp>don't copy-recursively into bin <lfam>Oh yeah. Are you copying a directory? Or a single file? <lfam>If it's the latter, use install-file <lfam>copy-recursively is for copying directories <lilyp>try install-file, it should mkdir-p <lfam>It's annoying but recursively doesn't mean that. You'd have to mkdir-p if you needed that. But install-file does mkdir-p <lfam>copy-recursively is basically `cp -r` <lfam>Whereas install-file is a Guix thing <lilyp>copy-recursively is also a guix thing <lilyp>there is no LGPL version in Guile :P <lfam>I think it's an analogue of `cp -r`, lilyp <lfam>There's no POSIX analogue of install-file <lfam>That's what I meant by that <lfam>It's a question of whether we reproduce the UNIX / POSIX tools or create new things to improve our lives <unmatched-paren>hm, looks like whoever made the nim package forgot to add openssl and pcre to the inputs... the nim website says it needs them, and `nimble --version` complains about libcrypto <lilyp>Well, in that case install is still a GNU make convention, so... <lfam>I think the combination with mkdir-p is the innovation of install-file <apteryx>lfam: install-file is like install, no? <apteryx>the command line 'install' from coreutils <lfam>I suppose! And it's not POSIX :) <sneek>Yey! unmatched-paren is back :) <rekado>apteryx: rebooting berlin is best done when I’m around, so that I can press the any key in the serial console. <apteryx>sure! I've reconfigured it some minutes ago, we can wait to reboot it tomorrow <apteryx>I haven't copied anything yet, just exposed the new fs as /new-root and /new-home <apteryx>I guess the best would be to stop all services, copy the data intact to its new home, adjust the mount points then try a reboot <apteryx>we can pre-populate the new fs with rsync, that'll make downtime minimal <lfam>While both of you are here, apteryx and rekado, mind checking if you have any ooooold profiles hanging around at ~/.guix-profile and ~/.config/guix/current ? <lfam>It would be nice to prune them if they aren't going to be used <apteryx>but there's 141 GB in /home for some reason <lfam>`cd /home && du -sh * | sort -h` <apteryx>probably 4 TB test files from fio :-) <lfam>We just fixed the issue that left those directories hanging around. They resist deletion <lfam>It was also suggested that we prune old users. There is only one user who doesn't log in anymore <lfam>It's a good time to remove them from the user accounts list and delete their home <unmatched-paren>i thought maybe GNU parallel was required for parallel compilation in nim <unmatched-paren>but... why does building nim itself work without parallel compilation turned off? hmmmm <singpolyma>Is there a procedure for getting a license added to guix? Just send a patch, or better to bring up on a mailing list first or...? <lilyp>if it's a well known license, just send a patch <lilyp>if it's unclear whether it's a free software license, ask FSF first <unmatched-paren>ah, so the build script for nim uses parallel, but not nim's compiler itself... <unmatched-paren>is there a procedure for getting the amount of cpu cores? parallelization could speed up the nim build quite a lot <lilyp>so you need to add parallel to the build envß <lilyp>there should be a parameter which you can bind <unmatched-paren>to be clear, this is just an extra speed boost for the build of _nim_, it's not going to fix the _nimble_ 'no parallel build' problem <easbarba>hey, ive runned in this error again in a fresh fedora install, as I install guix w/ install.sh <easbarba>'guix pull: error: failed to connect to `/var/guix/daemon-socket/socket': No such file or directory' <easbarba>last time it got fixed by itself cant say how <ytc>hello. how do you guys set up your guix system's firewall? i used to use ufw on other distros but i've seen that it's not possible on guix system. <easbarba>ytc: as far I know uwf is a ubuntu thing <unmatched-paren>which according to the readme are buggy and only meant to be used to compile the self-hosting version <lilyp>well, then let's use it to bootstrap nim :) <unmatched-paren>either that or we aren't building it completely from source which is worse :S <unmatched-paren>i see no mention of invoking nim in build.sh, only lots and lots of $CC cals <lilyp>it's probably as far as the makefile goes, can you see where it'd continue? <lilyp>there's a similar problem in zig, which we only build up to stage1, because stage2 is buggy and stage3 not yet implemented <unmatched-paren>the c sources of an older nim are in github.com/nim-lang/csources-v1 or something <lilyp>why? according to upstream, you can build the real nim with the buggy one, no? <unmatched-paren>yes, but it looks like we're not actually building nim from source rn <civodul>zimoun: in fstatat(2), AT_EMPTY_PATH is marked as "since Linux 2.6.39" <civodul>so you'd need to check whether this kernel actually implements it <civodul>perhaps worth continuing on bug-guix though :-) <unmatched-paren>i wonder how much more painful than this adding rust was... i pity whoever had to do that <apteryx>does the GRUB bios partition requires to be manually formatted as fat32, or does grub-install handle that itself? <lilyp>I'm pretty sure you need to cfdisk and mkfs on your own <apteryx>info '(grub) BIOS installation' suggests GRUB will automatically overwiret a "BIOS Boot Partition', which is marked by the flag 0xEF02 <apteryx>so I guess # parted /dev/DISK set PARTITION-NUMBER bios_grub on is enough in itself <lilyp>don't forget to set the EFI flag tho <unmatched-paren>maybe the reason i'm experiencing issues with parallel is because i'm using the buggy c_sources? i certainly won't bet on it, though, after all this :) <apteryx>EFI flag is for the ESP partition of the EFI systems; in my case, the machine is to boot on a GPT via BIOS, so GRUB expects a >= 31 KB bios_grub flagged partition to write its files. <apteryx>my question was whether that partition needs to be formatted as fat32, but it appears not required. <lilyp>I think if it's BIOS you can even make it ext4 <lilyp>you just need to leave that empty space on the first 32KB <lilyp>(or was it 4? I don't recall) <lilyp>for the record, BIOS = MBR, right? <pinoaffe>some bios versions can only boot from mbr, some can also boot from gpt <pinoaffe>yeah tianocore has some backwards-compatibility with MBR / GPT booting, I'm not sure how often that's enabled <lilyp>mbr and gpt are both partitioning schemes <lilyp>so we are talking about non-efi gpt <rekado>apteryx: I think it’s a good idea to start rsync’ing ASAP. Copying is going to take a long time, so we better start soon. <apteryx>are there directories we can ignore/remove, such as mnt_test ? <rekado>(up until it filled up, so it’s not complete) <rekado>but I recommend copying from mnt_test first <rekado>and then sync the rest of /var/cache from the slow storage <apteryx>I'm syncing /home as a practice. Any suggestions of flags for rsync? Else I'll use -aHAXP <nckx>-P is a better --progress. <nckx>apteryx: My muscle memory is -aPHAX and I've never gone ‘oh… shit’ so that sounds good. <lilyp>no links is also p good with Guix, because it omits stuff like the store <nckx>But yes, -H can be extremely slow on Guix (if that's what you mean…). <lilyp>we all do, but Guix already has it backed up <nckx>By which I mean that Guix is -H's pathological case. <apteryx>dropping -H would only mean loosing deduplication links, right? Would it self heal? <lilyp>IOW if you need the store, just do a --time-machine :P <nckx>Just drop .links entirely then, or you'll add a lot of time and space for literally no advantage. <nckx>lilyp: I tend to back up $everything at once, and want -H for $everything_else, but you're right it's not a good fit for /gnu/store alone. <apteryx>it's funny to see the old drive saturates in IO while the new one(s) are at 0% <nckx>Heh. And you've left cache? <nckx>That it's not writing to RAM anymore. <nckx>Hey, I don't know how slow reading from the old drives is… <lilyp>dirt typically has worms moving around in it tho <lilyp>but not really molten, just slightly liquid <apteryx>on of the drive was about as bad as my 2008 rig <apteryx>the other ones is like 10 times faster <apteryx>the new array is near 20x faster to read and 50x to write <rekado>the SAN is also pretty good; hope we’ll soon get some more space on it so the SSDs can go on a trip to France <apteryx>at least in the fio's random read/write test used in #51787 (you can try it at home to compare if you are curious!) <apteryx>rekado: your fio results from the SAN seems unbelievably good (how can it be faster than local SSDs?) <rekado>make sure to use --bs=… appropriate to you block size <podiki[m]>...I don't know what he was trying to say in between chomping on my fingers <rekado>maybe just testing whether the parens are automatically paired <zimoun_>civodul, thanks. I will open an issue once I will access again to my colleague's machine. But I guess it requires a kernel update. <apteryx>rekado: how do I find out the block size of the new array? <apteryx>-> Sector size (logical/physical): 512B/512B <apteryx>so my tests used the wrong --bs (4k vs 512) <Nazar>Hello there, i'm preparing one more package for guix, and this package https://github.com/elastic/elasticsearch have internal log folder, problem is that after install this package, i have an read only file system error. Could someone give me some advice how to resolve this ? <apteryx>it should be patched to use something like /var/log/ instead <Nazar>yes, but the base version is free <Nazar>apteryx the same error is for /var/log folder :( <apteryx>rekado: weird, running with --bs=512 kills the performance <rekado>frankly, I have no idea what I’m doing. <rekado>a civet with google would know more <apteryx>someone in #btrfs suggests sysbench as a simpler io benchmarking tool <Nazar>it's only working with /tmp/ folder <apteryx>Nazar: which file is is attempting to write? /var/log is probably owned by root... hmm. <Nazar>and in console i;m also don't have permision to touch /var/log/1.log <podiki[m]>could pipe it through logger (writes to syslog) <apteryx>if this is intended to run as a service, you could fix the permissions before hand in a service activation <apteryx>I'm afraid grepping for examples in the sources will yield better advice than myself at this point, but that's the direction I'd investigate :-) <apteryx>GRUB doesn't accept some kind of UUID for its device targets, correct? <unmatched-paren>yes, you're right, i'm trying to execute a file which does not exist, oops <apteryx>rekado: is there some part of the file system that I should migrate first to boost cuirass/gc performance? /var/cache? something else? <rekado>apteryx: /var/cache (with the copy on /mnt_test first) would allow us to remount the cache already <rekado>it’s currently bind-mounted on the slow external storage <rekado>that’s what backs guix publish and nginx <rekado>by moving these off of the slow storage, cuirass and guix gc won’t be disturbed by seeks as much <rekado>we can remount /var/cache before the reboot <nckx>apteryx: It can. You can use ‘search --fs-uuid’ to set a variable, usually $root. <apteryx>nckx: that's neat! It's not documented (thus supported?) by our current bootloader-configuration generator, right? <nckx>If you're talking about ‘install time’ targets, that's also supported, but it *might* just look it up at install time and not give you any of the boot-time robustness you might seek. <nckx>That depends entirely on how Guix configures GRUB. <nckx>And well, I'm still grepless :) <apteryx>I was pondering bootloader-configuration's targets field could be set to something like (list (uuid "some-uuid") ...) <nckx>Using the Web UI like an absolute peasant, things don't look hopeful apteryx. We don't use any fancy features but we could. <kocio>Hi, I'd like to build only mc, but no other packages, which should be just downloaded as substitutes, what should I do? <bdju>still in a TTY post-install. copied over some data and tried to merge parts of my two system configs. I can't guix system reconfigure now. hoping someone can help. <bdju>I had issues with the default list append whatever package list so I copied the "map" thing from my old config, but still no dice <rekado>you can’t *just* install mc without these other packages <apteryx>nckx: also somewhat related, #40999; where GRUB fails when one of the drives specified in targets is missing (which defeats booting a degraded RAID) <nckx>apteryx: I boot my btrfs ‘raid’ using a separate USB drive as /boot so haven't run into that. *Guix* will subsequently fail to boot a degraded btrfs raid, though, I've noticed. <nckx>But maybe that was an issue with my configuration too <florhizome[m]>Can I say: I only want this module/this path from a channel? <kocio>@rekado I'd like to just download these dependencies and build only mc itself <apteryx>nckx: you need the 'degraded' option; otherwise refusing to boot is standard Btrfs behavior <apteryx>and the Guix initrd doesn't honor rootflags so you can't provide it if you've already hit the sad situation (that's #40998) <rekado>kocio: that’s what Guix does when you ask it to build mc <rekado>or do you mean you want to build it locally and not get a substitute for mc itself? <rekado>in that case you’ll need to download more than just the runtime dependencies <rekado>(you’ll need the compiler and all that too) <nckx>We should definitely honour them. We should also honour root= and friends and phase out or --root= affectations. It's fake shell consistency that serves only to make us inconsistent with the world. <kocio>when I do `guix install mc`, it's just downloading it as a substitute, but when I do `guix build mc --no-substitutes` it builds a lot of other packages first <rekado>this will fetch all the things you need to build mc <nckx>kocio: guix shell -D mc -- true && guix build --no-substitutes mc <rekado>then “exit” because you don’t actually need the env <apteryx>nckx: agreed; I actually had code doing that in the Btrfs subvolume review but tossed in to keep things simpler; I should revive it. <apteryx>(it was honoring --rootflags I think -- we should standardize as you said) <apteryx>oh, it finally finished copying home <unmatched-paren>lilyp: parallel building nim code works with the self-hosting version :) <nckx>kocio: Why do you want mc built locally? Locally-built bits aren't more artisanal than CI's and should ideally even be bit-identical bits. <nckx>Ah, then ‘guix shell -D’ (nothing more than new syntax for ‘guix environment’) is your friend. <apteryx>did I confuse Guix by using a variable? <unmatched-paren>--clib:libcrypto doesn't work, nor does (string-append (assoc-ref inputs "openssl") "/lib/libcrypto.so") <unmatched-paren>the --clib argument appears to be propagated straight to the ld flags <unmatched-paren>i'd guess i'm about 40% of the way to adding first class nim support to guix :D <kocio>strange - I can't get rid of mc substitute with `guix remove mc && guix gc` <rekado>kocio: “guix remove” just creates a new generation where mc is missing <kocio>I thought guix gc clears it from the store <rekado>if you really want it gone you’ll have to remove the generations that reference mc <rekado>“guix gc” clear garbage, but a package that’s referenced by an older generation of your profile that you may want to roll back to is not garbage <SeerLite[m]>Hi! How can I close my own patch on debbugs? I sent a patch for core-updates a few days ago but I missed that it wasn't needed (I compared and made the patch from the wrong branch, core-updates already has the same change) <rekado>kocio: guix package -l shows you all your past generations <rekado>SeerLite[m]: send an email to 12345-done@debbugs.gnu.org (with the correct number, of course) <SeerLite[m]>Is there a message/command I can send or do I just send an update telling you maintainers to close it? <kocio>now when I try to build mc without substitutes it still tries to build other packages <kocio>and when I redo `guix environment mc`, the substutute mc is here already <SeerLite[m]>rekado: Do the subject and message not matter? Do I just send it all empty? <kocio>nckx kocio: guix shell -D mc -- true && guix build --no-substitutes mc - this also tries to build all other packages <nckx>Not if there are substitutes available. <ngz>SeerLite[m]: Subject and body do not matter. <kocio>OK, maybe these were just intermediate packages and were not stored as substitutes at all? <nckx>I'm not sure what ‘intermediate packages’ are. Guix/CI does not have such a concept. <rekado>SeerLite[m]: they don’t matter for debbugs but to people who are subscribed to the list it’s a little nicer to have some context <kocio>So I'm not sure why it tries to build them all instead of downloading <rekado>(an alternative is to send a message to the control address with commands in the message body, but I always forget how to do any of that) <rekado>kocio: does “guix shell -D mc -- true” build anything? <kocio>That's all just my exercise in understanding how Guix works, so any errors are still interesting outcome to tinker <rekado>and then “guix build --no-substitutes --dry-run mc”? ***lukedashjr is now known as luke-jr
<kocio>it tells that 3 derivates will be buuilt - git, git-minimal and module-import-compiled 