<drakonis>ehhh, i haven't given it a shot just yet. <drakonis>i wanted to run a whole distribution in a container <drakonis>hmm, but how'd i set up something like debian here? <vagrantc>libvirt can do lxc-like things that it calls lxc <drakonis>yes, but there's no lxc service i guess? ***mbakke[m] is now known as mbakke
<iskarian>is there a way to ... resume a failed build from where it failed after making a modification? <leoprikler>sadly no, you have to do everything all over again *iskarian cries in building gcc <nckx>You can build with --keep-failed, then enter the /tmp/guix-build-… subdirectory and a guix environment <package> and source the ‘environment-variables’ file you find there. <nckx>It's very manual and incomplete. <dstolfa>nckx: what would be the best way for me to test strongswan without setting up a channel? <dstolfa>like, if i wanted to run strongswan locally and have it do a thing with my patch <nckx>I assume you built it with something like ‘./pre-inst-env guix build strongswan’? <nckx>You'll have to disable authentication (Guix should print a hint) because your commit isn't signed my an authorised committer, but it'll work just fine. <nckx>But alternatively you could also just ‘./pre-inst-env guix install strongswan’ or ‘sudo ./pre-inst-env guix system reconfigure ...’ if it's a system package. <nckx>‘Best way’ really depends on your situation & preference. <dstolfa>hm, would ./pre-inst-env guix install strongswan work if i'm not in a guix environment? <nckx>dstolfa: It can work, but it's best to always run it inside guix environment guix. <nckx>guix environment guix -- ./pre-inst-env guix install strongswan <dstolfa>wouldn't that install it to a different profile? <nckx>I don't know what, but yes 😛 <nckx>Entering an environment doesn't change or virtualise or CoW your default ~/.guix-profile, it's still there. <dstolfa>that's really helpful actually. i don't know why i assumed it did <nckx>‘guix package’ and its aliases still operate on it by default, and the changes are global (another terminal window not inside the environment will pick up the changes too) and persistent. <iskarian>nckx: Yeah, that does help but you're right, very clunky. This time I'm running into syntax issues (I'm very inexperienced with Guile) so it's difficult to test that outside the package context... <dstolfa>also, as an aside, i'm attempting to run an AppImage. i've set up guix environment guix --pure <dstolfa>wrong paste. getting used to wayland <dstolfa>i've set up /lib64/ld-linux-x86-64.so.2 to be a thing, but when i try to ./whatever.AppImage it just gives me an ENOENT for the appimage file <dstolfa>nckx: good night, thanks for the help :) <ix><vagrantc> guix environment --container <ix>Can these be declarative <Bumblehorse>Does anyone know why sudo guix system reconfigure gives me an error "Git error: objest not found - no match for id (IDNUMBER)"? <sneek>Welcome back Bumblehorse, you have 1 message! <sneek>Bumblehorse, nckx says: BTW, just in case you were serious: it's perfectly safe to swapon the wrong partition; it'll just fail. <Bumblehorse>but this relates to guix pull, not guix reconfigure, does anyone know where the cash for guix reconfigure is? <Bumblehorse>Similar to the linked issue, I too had my computer crash durring updating <Bumblehorse>I went to root's guix cache and deleted the checkouts and I think it's working now <Bumblehorse>nvm now I get and error "guix system: error: error parsing derivation `/gnu/store/.....-libndp-1.8.drv': expected string `Derive([' ***iskarian is now known as Guest4035
***iskarian is now known as Guest7071
<iskarian>oh! so the * is required so that previous bindings are available in later bindings? <iskarian>thanks, I really ought to read an actual primer on guile <dstolfa>i've poked around strongswan a bit more, and while the actual build seems fine, i've bumped into a problem. namely, the config files end up in the read only /gnu/store/$HASH/strongswan-${version}/etc/ipsec.conf and ipsec.secrets. is there an example of how i could point it to perhaps $GUIX_PROFILE/etc/ipsec.conf instead? the problem is essentially that strongswan defaults to these files, and while one can <dstolfa>point strongswan to a different ipsec.conf, it's not necessarily true for ipsec.secrets from what i can see <dstolfa>i guess one could simply point it to /etc/ipsec.conf, but i'm really unsure as to what the best practice is in this case <raghavgururajan>Anybody else experiencing system freezes after recent kernel updates? <drakonis>dstolfa: guix install strongswan should place it in $GUIX_PROFILE <iskarian>raghavgururajan, how recent? I may have just had one on 1.2 but I'm running it as a VM so I just assumed it was that <drakonis>iskarian: 1.3 has been out for a few weeks now <ecbrown>i can build individual packages, but when i try to build (what i think is) "core-updates from master" i am getting a postgresql error, <ecbrown>raghavgururajan: with heavy io i see big lags/freezes <ecbrown>(btrfs, e.g. copying a new iso out of store into my home dir.) <ecbrown>thought a cow system would be instantaneous lol <ecbrown>(but i'm used to bsd systems which tend to smooth interactive use while heavy i/o, so i may be seeing a "linuxism") <daviid>pkill9: I don't know - there is one(or two) student cafetaria(s) that accepts on the, in france and/or germany ... that's on the taler website iirc ***Diagon_ is now known as Diagon
***niklas[m]1 is now known as n1ks
<ithildin>(newbie here) if I want to build a c program that has x11 libraries as dependencies, what packages should I include in the recipe for the program? <vagrantc>basically, look for matching header files from your program's includes in /gnu/store for example <vagrantc>also, look at the program's installation instructions, if any; it should probably recommend packages that you'll need <ithildin>also, is there a searchable index of packages? <vagrantc>not really ... do you have a guix installation available? <vagrantc>you might find it with something like: find /gnu/store/ -name Xlib.h <ithildin>yeah, I think the libx11 and xfce packages have it <vagrantc>there is work on making an interface that searches by filenames, but it's got some challenges to implement well *vagrantc suspects the file search implementation is somewhat blocked by doing it a little too correctly rather than a best-effort search <vagrantc>ithildin: you can also look at redshift and gammastep for hints, which implement similar functionality <vagrantc>though probably have a lot more needed inputs <ithildin>weirdly enough I couldn't find it on the alphabetical index <vagrantc>ithildin: alternately, you could look at the "sct" package description :) <vagrantc>sneek: later tell ithildin apparently "sct" is already packaged in guix ***Mark_ is now known as Mark__
<rekado_>cbaines: sorry about the missing patch! <raghavgururajan>ecbrown: Yeah! Same here. Freeze happens during heavy I/O. Like downloading files from web, copying files to external disk, etc. <rovanion>By the way: The lingot hiss/coil whine stopped when I switched from Alsa to Pulse as the input source. ***Kimapr5 is now known as Kimapr
<projectmoon>raghavgururajan: usually that means the cpu cores are being monopolized. You can either change the nice value, limit it to less cpu cores, or both <maddo>hello, I'm using guix on a foreign distro, tried installing vapoursynth with guix, it correctly installs the vspipe binary however it fails to initialize the vapoursynth envirorment <HiddenKarma>My terminal does not show the current directory, it shows "(base)" instead, does anyone else have this? <maddo>(had a similar problem with kitty that couldn't find the GLFW context) ***Kimapr7 is now known as Kimapr
<projectmoon>It works. And even renders the arabic on the right side <projectmoon>Does Persian/Farsi have its own alphabet, or use the arabic one? <dstolfa>does guix have some kind of /etc/os-release? <PurpleSym>projectmoon: It’s using an extended Arabic alphabet, but afaik the language itself is closer to European languages than to Arabic. <soheilkhanalipur><projectmoon "Does Persian/Farsi have its own "> In fact, these two languages are very different, Persian alphabet is slightly different from Arabic, and also in ancient times, Arabic alphabet was taken from Persian alphabet... <soheilkhanalipur><projectmoon "Does Persian/Farsi have its own "> And so (FARSI) is wrong! It is called "Parsi" in Persian, Arabs call it (FARSI). <dstolfa>nckx: so i have a bit of a problem with strongswan. the "normal" guix way to install it with read-only mounts doesn't work because strongswan has a few config files that need to be writable. the most important of these are ipsec.conf and ipsec.secrets. generally, strongswan wants all the files in the same location. should i create an environment variable STRONGSWAN_CONF and just put everything there except <dstolfa>(and if so, is there an example of this?) <Reventlov>So is there some guide somewhere to use guix on a desktop computer (so with blobs and proprietary stuff) ? <stikonas>desktop computer does not always mean blobs and proprietary stuff <ecbrown>Reventlov: you may get a lukewarm response from a free software channel, running proprietary software. pretty sure you can find your information elsewhere ;-) <Noisytoot>There may be, but I don't think it can be mentioned in this channel (if it exists) <Noisytoot>The solution is to get a computer that works with 100% free software <dstolfa>so you are free to run whatever you want, it's just that official Guix repository doesn't recommend any non-free software <ecbrown>Noisytoot: a lot of people have hand-me-downs or are new to free software, or other circumstances like work-issue computers <nckx>dstolfa: So there's no current way to point strongswan to configuration files? It really hard-codes only <bindir>/../etc or so? <dstolfa>nckx: there's only a way to specify ipsec.conf, nothing else <dstolfa>everything else is a configure time option <dstolfa>so essentially i'd need to say --sysconfdir=$STRONGSWAN_CONF <dstolfa>and move everything there post-install <nckx>It's unethical to throw away perfectly good hardware just because it doesn't work with entirely free software. <dstolfa>so if i did create a directory that contains the strongswan config files, how would that look like in guix's file structure? <nckx>Noisytoot: Neither of those address the issue. (1) is buying a victim so you can feel ‘ethical’, (2) is ‘oh it supported free software all along how did these goalposts get here’. <nckx>dstolfa: I'll take a look at the code when I get back from gardening. But from the Nix systemd service it looks like it does look up STRONGSWAN_CONF at run time, not build time? <ecbrown>Noisytoot: free it! eh, it's usually only a dongle away ;-) <dstolfa>nckx: oh that's right. hmm i wonder if nixos actually works at all. i wasn't aware that this was a strongswan env variable (https://wiki.strongswan.org/projects/strongswan/wiki/strongswanconf). my proposal is slightly different: have a STRONGSWAN_CONFDIR (different name since strongswan uses just CONF), which contains the configuration fails relating to strongswan. these would include ipsec.conf, <dstolfa>ipsec.secrets, strongswan.conf, charon.conf and all of the plugin configuration that the user may wish to modify <dstolfa>nckx: though... this needs to be run as root, so it might as well just be one of the "special" packages that end up with configuration in /etc? i'm really not sure how to go about this <ecbrown>hmmm.. i added (options "subvol=rootfs") and reconfigured an already-installed btrfs system, and now i can't get past grub, or even load the older configurations. /rootfs is prepended to everything :-( *ecbrown wonders if subvolume for root ought to be created at install time <raghavgururajan>Folks, I am having an issue with a Go package. Building `bitmask-vpn` fails with '0xacab.org/leap/shapeshifter' not found, despite having `go-0xacab-org-leap-shapeshifter` as inputs. The patches are available at #48729 (v1). Thoughts? <dstolfa>nckx: so after more digging, i think the two things that make most sense are either (1) put everything into /etc globally for configuration since it's kind of a "system" configuration (you set up a VPN) or (2) create a separate STRONGSWAN_CONFDIR with all the configuration and when we build we point strongswan to that directory with --sysconfdir=... and then we export an environment variable to users <dstolfa>i don't know what the best way to go is, but i tried the /etc approach and (obviously) get permission denied when i try to build as user <dstolfa>i was doing it through add-after 'install and then manually setting up the directory structure based on what the strongswan makefile spits out <dstolfa>nckx: STRONGSWAN_CONF can be used to specify everything i *think*, but there is still that issue of needing to actually manually specify it every time, so it won't work out of the box on guix <dstolfa>we could write some guile to allow it as a service specification <dstolfa>instead of all of this stateful mess <apteryx_>elb: my experiment to guix pull from 1.3.0 without substitutes failed after 1191m24.640s (using a Debian 10 i686 host in a VM), because apparently boost failed to build for that arch <solene>I love how NixOS allow defining firewall rules by listing TCP and UDP open ports (globally or per interface), it seems Guix doesn't have it. It seems fun to hack on it, would it be a desirable feature? That would be a good opportunity for me to get into something else than packages <apteryx_>I think error 100 is a generic kind of error from the daemon <dstolfa>nckx: i've worked around the problem by using strongswan in a docker container for now... this needs fixing. the patch i sent on the mailing list is still necessary to get anything working, but i think a second patch is needed on top of that to get something usable without a silly amount of manual configuration <dstolfa>i might need someone's help with this, i'm not familiar enough with what could be done to get it set up in a user-friendly way because strongswan is really stateful and assumes a lot <mothacehe>civodul: hey! the overdrive1 has been unreachable for a few days, do you think you could have a quick look :) ? <apteryx_>sneek later tell mothacehe I had to manually restart wireguard-wg0 and ping 10.0.0.1 from overdrive1 to have the wireguard link re-established <apteryx_>sneek later tell mothacehe but I did that yesterday and it lost the link again it seems, so I'm not sure what's going on. The connection with Cuirass seems to have been lost since I reconfigured it (before yesterday?) ***Kimapr5 is now known as Kimapr
***humky_ is now known as humky
<[[>How does Guix do substitute server discovery? <[[>Does the "Guided - using the entire disk with encryption" option in the Guix System installer encrypt /boot? <nckx>[[: Yes, in that /boot is just a subdirectory of /. <robotux>how does computer know how to start loader if its encrypted? <nckx>Your boot loader isn't (the part on your EFI system partition, or the part in the 1-MiB gap before your first partition on legacy non-UEFI systems). It then prompts for the passphrase os it can load the rest of GRUB. After booting the kernel, Linux will prompt for the passphrase again. It's an unfix inelegance. <[[>robotux: My bootloader is in my boot firmware, as I am using libreboot <[[>with the GRUB payload <nckx>I hope that's supported by the installer. <[[>What is the 2097kB ext4 partition before cryptroot? <nckx>Without looking, that sounds like a very confused description of the BIOS boot partition (which isn't ext4 at all, of course). <nckx>I guess something somewhere requires a ‘file system type’ so we feed it bullshit. <nckx>I guess I don't understand TeX Live versioning then. <dstolfa>nckx: could you let me know when you have time (doesn't have to be today) to look at the strongswan thing? i've made some progress but don't know enough about guix to decide what the best approach it <nckx>dstolfa: I've never used Strongswan on a functional distro is the thing. <dstolfa>nckx: i'm happy to simplify what the problem is, it's not exactly terrible and i imagine more software behaves like this, i just don't really know what the best way to resolve it is <nckx>[[: At a glance it looks like the installer's system will boot fine from your firmware, you'll just have a useless GRUB installed in the BIOS boot partition & elsewhere. The (installer #~(const #t)) part in the guide disables that. <nckx>I think you're given a chance to edit the final generated configuration before the installer installs. Else, you can do it after booting the installed system. You can then zero out the BIOS boot partition if you're paranoid. <[[>What does #~ and const do? <nckx>(const #t) is shorthand for (lambda _ #t), i.e. it evaluates to a ‘constant’ procedure that always returns the given argument no matter how you call it. <nckx>#~ means ‘gexp’, it's explained in more detail than is relevant here in the manual. <nckx>The effect is that your custom ‘GRUB installer’ is a no-op. <nckx>dstolfa: I'll read your previous messages attentively and let you know if I have any ideas. Is Strongswan run as a daemon? (I have used it, but it was years ago and I just needed it to work, I never looked behind the curtain.) <nckx>I'm very happy I no longer need it. <dstolfa>nckx: it is run as a daemon, yes. the `ipsec up/down` is just a way to connect or disconnect, but the majority of the work happens in a daemon which reads a configuration (which needs to be modifiable by the user) <dstolfa>to simplify it as much as possible, it's a daemon which needs to read a config written by the user, so it can't be in a RO filesystem <nckx>Is the user the admin here, though? Then making it a service is the way to go. <dstolfa>well, i think so. i don't see how you could sensibly allow a non-admin user to connect to a VPN <dstolfa>nckx: how would one configure VPN connections if it was service in guile? <dstolfa>would we just allow users to put in the full config? <elb>apteryx_: yeah I think the error just means that _something_ failed in the build <elb>but like ... if builds are really reproducible, and it built for someone, that really shouldn't happen <[[>Is it possible to have a swap partition with Guided partitioning with full disk encryption? ***iskarian is now known as Guest6850
<[[>Is it possible to have a swap partition and a root partition in LVM in LUKS? <stikonas>[[: I think guix was not working well with LVM but my knowledge might be outdated <[[>According to the Guix manual, it does support LVM (lvm-device-mapping) ***achow101_ is now known as achow101
<Guest0>Hello, quick question: in the installation instructions when it comes to installing the manual it says to run this command: <Guest0>I already have a 'dir' file in my /usr/local/share/info, so wouldn't that overwrite my dir file? <civodul>philip: hi! configure passes for me here on Guix System with a recent linux-libre kernel, so it looks like a dependency on a specific kernel config/version? <roptat>mh... I can build the unmodified sources with our maven locally (by letting it download packages from central), but not the modified version I try to build in the guix package (still letting it downloading packages from central) with the error I observe in the build environment <roptat>so the error is with the modification I do on the pom files, not on our maven and plugin packages <philip>civodul: hm, ok. I don't have it set up right now, but I will try building on a Guix System vm. I wouldn't have expected it to depend on the running kernel (vs. the target kernel), though. My system says it's running 5.11.0-7614-generic. <roptat>found it! our version of jopt-simple is too recent <civodul>philip: i think we should check what that inode_owner_or_capable configure check does; it might be downright checking for /proc or /sys stuff, which is inherently kernel-dependent <lfam>So, the import is unused? <civodul>philip: what's the bug actually? the issue describes the solution in detail but not the bug :-) <civodul>for instance, "guix build chez-scheme -d" works fine (it amounts to loading (gnu packages chez)) <civodul>but yes, in general we can't use #:select for (gnu packages ...) modules <civodul>esp. if the import is not even needed <lfam>I failed to install Guix System on the macchiatobin again <lfam>And each time I do this, it also breaks the Debian installation on separate storage <vagrantc>just efi changing the default boot order? <dstolfa>hmm, roptat you said you have libvirt working on guix right? <dstolfa>i basically set up the service, did a reconfigure and for some reason virt-manager doesn't find the connection <rekado_>apteryx_: the Emacs changes of 45316 broke guile-studio. Guile-Studio just sets EMACSLOADPATH to known packages. <rekado_>I suppose now I need to set it to include the sub-directories? <rekado_>guile-studio runs emacs with “--no-site-file”, which I guess is no longer supported? <lfam>vagrantc: The SD card can't boot at all. I select it from the EDK2 picker and it immediately returns to the EDK2 menu <lfam>Debian is on the SD card, and I'm trying to install Guix System to an SSD <lfam>The installation "succeeds" but then, when booting Guix System, it can't find the SSD / partition <lfam>I'm guessing that some module is missing from the initrd <vagrantc>lfam: when i was building pinebook pro images on a mustang ... i kept having a similar issue, but i was able to manually load the correct efi image from the EFI shell <vagrantc>lfam: using linux-libre or linux-libre-arm64-generic? <lfam>linux-libre, because linux-libre-arm64-generic failed to build linux-modules (IIRC) <lfam>Something is missing from linux-libre-arm64-generic that breaks using it, currently <vagrantc>lfam: did you pass it an empty initrd-modules ? <lfam>I think I tried with the default, so no <lfam>Should I clear initrd-modules? <vagrantc>lfam: yeah, when using arm64-generic, you need to empty the initrd-modules <lfam>It's annoying. Iterating like this takes a few hours each time, because installing Debian is slow, and then a lot of substitutes are missing <lfam>I think the Guix System installer is actually faster than Debian, if every substitute is available <vagrantc>it is likely possible to just pass the correct stuff on the efi shell to boot <lfam>I don't even know how to get started with that <lfam>There's a shell that can be accessed from the EDK2 menu? <vagrantc>but yes, installing on arm* is a very iterative process still, unfortunately <vagrantc>lfam: should be, unless you have some strangely locked down efi <lfam>It would help to have a live Guix image, so I could skip the Debian step <vagrantc>for whatever reason, people haven't tended to make live images for arm* <lfam>I guess that with u-boot, there's no point <lfam>But it will be more useful as UEFI becomes common <roptat>dstolfa, yes, but haven't updated recently, so maybe it broke recently <dstolfa>roptat: did you do anything other than (service libvirt-service-type) in your system configuration? <roptat>success! the first real package to use the maven-build-system built \o/ <dstolfa>and add yourself to the libvirt group <vagrantc>lfam: well, yeah, you'd need to make a two-part image for u-boot ... or an image that you install u-boot on as a separate step <lfam>Even the Debian installer could work, if they included bash <lfam>As it is, it's useless as an "install Guix" live image *vagrantc needs to get around to that someday... <roptat>dstolfa, I added myself to the libvirt group, added the libvirt and virtlog services, that's all <lfam>It's weird that `guix system init` is also destroying the Debian installation, which is on storage that shouldn't be touched for the installation <dstolfa>roptat: maybe i'm missing the virtlog service... <lfam>It makes me think that the bootloader stuff in config.scm is wrong <vagrantc>lfam: are you sure it's destroying the system, or just making EFI not boot it? <lfam>It no longer boots afterwards <vagrantc>lfam: pretty sure it's just the way guix configures EFI <lfam>So, what sort of thing would I need to look at in order to get it working again, vagrantc? <vagrantc>"efi will solve all our problems. oh, oops, it will introduce this other problem" <vagrantc>lfam: i'm pretty fresh with EFI too ... but basically there should be some sort of boot selection, and a shell should be offered <vagrantc>lfam: or it should drop you to an efi shell <lfam>Yeah, I can use the boot selection menu. It's from there that I choose the Debian installation and it doesn't work, after trying to install Guix System <vagrantc>i suspect guix's efi installation process is destructive, in that it configures EFI to only boot guix and removes the other entries <vagrantc>lfam: there's no shell option from there? <lfam>I'll have to check after I finish this Debian re-installation <lfam>Which is annoyingly interactive <dstolfa>roptat: that did it, i was missing virtlogd <dstolfa>another quick question... how exactly would i set the MTU of an interface in my system configuration? <lfam>It's different but not unfamiliar <lfam>I'm hoping that using the generic kernel solves my problems <roptat>I plan to replace our static-networking-service-type with something based on guile-netlink, that would let you do that <dstolfa>roptat: ah okay. guess i'll just do it manually every time i boot for now, or just add it to startup applications <dstolfa>i basically need to match the MTU of my VPN otherwise weird things happen... don't ask ***Noisytoot is now known as [[
<vagrantc>lfam: from the shell "fs0:" to select the device (or whatever device) and then "EFI\Debian\grubaa64.efi" or whatever efi thing you want to start <lfam>Alright, I'll make a note of it <roptat>that's because the static-networking service doesn't support ipv6 <vagrantc>lfam: "cd" ... and maybe some limited if surprising tab completion <dstolfa>roptat: okay, thanks. i'll hack up something similar for my system config. thanks ***[[ is now known as Noisytoot
<dstolfa>roptat: hum, does virt-manager on your system do the bridge setup? mine's complaining about it <Noisytoot>Why doesn't the Guix installation image include lvm2? <vagrantc>lvm support was only recently added (and still requires manual configuration, i think) so ... probably nobody has gotten around to adding support in the installer <vagrantc>Noisytoot: might be worth filing a bug about supporting lvm in the installer :) <dstolfa>roptat: btw, there's a typo in networking.scm "Connot stop" instead of "Cannot stop" <dstolfa>just figured i'd let you know since i spotted it while trying to figure out how this whole config works :) <lfam>The string "Connot" doesn't exist in my Git tree <dstolfa>roptat was helping me with libvirt and setting up the MTU with their config :) ***xkapastel is now known as abcdefrs
***abcdefrs is now known as xkapastel
<Noisytoot>Why does installation with full disk encryption not include a swap partition? <bandali>why not send a patch to include a swap partition in that setup? <civodul>Noisytoot: because it would need to be encrypted as well, and currently that would mean separate encryption (thus you'd enter yet another passphrase when booting) <Noisytoot>bandali: I need to install an OS (Guix) first <vagrantc>hrm. i need a system service that sets the clock to the date of the last built system generation if it is older, otherwise ntp fails to reset the clock even when large-offsets or whatever is set ... if the offset is too large ... e.g. 1970 -> today <dstolfa>Noisytoot: here's a 1 liner (as root): touch /swapfile && chattr +C /swapfile && fallocate -l 4G /swapfile && chmod 0600 /swapfile && mkswap /swapfile && swapon /swapfile <vagrantc>or some way to tell ntp "no, really, really, do *really* large offsets please" <dstolfa>obviously in guix you would want to set it up in your system configuration <lfam>vagrantc: I think that " do *really* large offsets please" is the default now <vagrantc>the number of guix pull generations i have in 1970 is annoying <lfam>I'm not sure it's a problem with NTP in that case :/ <dstolfa>Noisytoot: during (or after the installation i assume works too), you would make the file, and then in your system configuration you would just do (swap-devices '("/swapfile")) <lfam>It's been a while since the NTP package was changed, vagrantc. It should still work <vagrantc>lfam: i think it only works if it is recent enough ... e.g. sometime in the last 30 years or so <lfam>It's a reason to have a hardware clock <lfam>I guess it's some ARM board without a clock? <lfam>Did you query the hardware clock? <lfam>With the hwclock command <vagrantc>hwclock: Timed out waiting for time change. <vagrantc>hah, i can write to it, just not read from it. great clock! :) <vagrantc>anyways, i've seen this often enough with a variety of arm boards that it would be nice to have a stupid service to fake a time before ntp starts <vagrantc>of course, then i have to make sure the system generation is not created in the ancient times <vagrantc>or maybe at least a safety check in guix ... e.g. "you can't possibly guix pull before ~2013, seriously, guix didn't exist yet" <pkill9>this change is a regression for the time traveller part of guix's userbase <vagrantc>well, they can retroactively revert it before it ever happened, so i think we're ok to at least try <pkill9>that may cause bugs in the timespace continuum <vagrantc>workaround it with a time namespace or something <rekado_>apteryx_: never mind, fixed it in a new Guile Studio release :) <vagrantc>curiously, while the "hwclock --show|--get" have the same issue on my debian systems on similar hardware, the time actually gets set correctly on these once network is up <lfam>Alright. I'm using the generic kernel, an empty initrd modules. I've mounted the filesystems, set the ESP flag <vagrantc>oh, they don't use ntp, they use systemd-timesyncd <lfam>I wonder if we can offer it too <lfam>I feel like it's so close *vagrantc is never quite sure about which letters to double in that model <vagrantc>lfam: but you *will* want to figure out how to get it running on the regular linux-libre and/or figure out what breaks building some packages (e.g. iwd) with -arm64-generic <lfam>Regarding spelling, the in crowd seems to say "mcbin" <vagrantc>typically involves passing various initrd modules as if you're playing golf <vagrantc>i managed to get pretty lucky with the mustangs, only requires two modules ... pinebook-pro is another story <lfam>Could I look at the "official" Debian image to check which modules it uses? <lfam>Or can it not be figured out that way <vagrantc>lfam: you could boot debian and run lsmod and guess which might be needed <vagrantc>lfam: or just include all of them and systematically trim down the list until you get one that works <raghavgururajan>Folks, I am having an issue with a Go package. Building `bitmask-vpn` fails with '0xacab.org/leap/shapeshifter' not found, despite having `go-0xacab-org-leap-shapeshifter` as inputs. The patches are available at #48729 (v1). Thoughts? <vagrantc>e.g. some are modules in debian and builtins in guix, etc... <vagrantc>bitmask, there's a name i haven't seen in a while :) <lfam>raghavgururajan: You should use --keep-failed and then check if 0xacab.org/leap/shapeshifter is available in the expected location <lfam>There should be a filesystem union of the dependency's source code in the build tree <lfam>It happens in the setup-go-environment phase of go-build-system <lfam>"[ 2.915425] BTRFS error (device sda4): unrecognized mount option 'defaults'" <lfam>Can I work around this without reinstalling? <lfam>It's weird because this is a valid mount flag for btrfs but whatever <chipb>hm. I thought 'defaults' was interpreted by the mount command itself. I don't think defaults is supposed to get passed through to the actual syscall. <lfam>I'm going to try again with no mount-options <lfam>I can add them again after the installation succeeds <vagrantc>lfam: maybe you could mangle the grub config manually just to get it into a more workable environment :) <vagrantc>or are these options not passed via grub? <lfam>I looked into editing the grub command or whatever it's called and these options weren't there <nckx>I'm barging in without context but ‘defaults’ is definitely not a valid mount command for any file system. <lfam>Maybe I could have edited files in the store but it's not ergonomic in the tiny linux console <lfam>It's what Debian generates for /etf/fstab nckx <nckx>There's a patch out there™ to respect the ‘rootflags’ kernel command-line argument but seems it hasn't been merged yet. <nckx>lfam: Both of those things can be true? <emad-guix>HI, I'm cursious to know the next release date for guix system <vagrantc>man mount seems to indicate "defaults" is a valid argument ... <nckx>It's an option to the mount(8), the executable, it's not a mount option. <nckx>‘se the default options: rw, suid, dev, exec, auto, nouser, and async.’ <vagrantc>and the guix initramfs doesn't use mount? <nckx>emad-guix: We don't have scheduled releases, and it's too soon after the next one to say, and most releases don't make the deadline anyway 😉 <nckx>Yes, and it's actually quite good. <nckx>Including and exec'ing mount(8) is a ridiculous amount of overhead to just mount some file systems on boot. <vagrantc>the only downside is you have to reimplement whatever features are already implemented in some other code... <nckx>vagrantc: What features? It's a syscall, there's nothing to do. <vagrantc>nckx: apparently it can't handle "defaults" <chipb>nckx: I think they mean translating /etc/fstab lines to the corresponding syscall. <nckx>It's not a mount option! <nckx>It can't handle --help either... <vagrantc>next you're going to tell me it can't write me a nice sonnet <nckx>‘defaults‘ tells mount to use some compiled-in defaults, it's not... argh. <nckx>*mount(8), to add^Wavoid confusion. <nckx>chipb: Guix doesn't use fstab directly, so it doesn't have to deal with its warts. <nckx>It generates it for the benefit of others that expect it but it's not a source of truth. <chipb>vagrantc: perhaps you can get linux-utils mount executable to split out what it would call mount-the-syscall with and use that from whatever in the initrd actually does it? <vagrantc>or maybe lfam needs a better guix system config.scm :)