<bavier[m]1>I assume someone's been able to actually use our `deja-dup` package, since it's seen recent updates, but it seems totally broken to me <bavier[m]1>for a local backup destination, the backend duplicity fails to load glib/gio python modules and bails <bavier[m]1>the deja-dup package even has python and python-pygobject inputs, but the output doesn't retain references. I assume they were intended to by propagated instead. <lfam>sneek: later tell linka: Krita should be fixed for real now <jonsger>I think there is a bug in the installer regarding EFI installation. It doesn't work out-of-the-box on my new computer. So after installation it can not find a bootable disk... <leoprikler>If I've learned one thing from "wine-staging", it's that "receiving updates" is sadly no metric. <nckx>(wine-staging user here.) *pkill9 rewrote a shell script in guile, feelsgoodman ***afk11` is now known as afk11
<mbakke>lfam: inheritance across modules is not safe because it depends on the order in which modules are loaded <lfam>I noticed this recently while working on something else <lfam>I also remember a weird issue where doing (package-native-search-paths curl) in the Transmission package would crash Guix <lfam>In the end it wasn't necessary but it drove me crazy for a bit <mbakke>ah yes, top-level variable references is another unsafe thing :-/ <mbakke>I pre-emptively fixed one in ungoogled-chromium today after a heads-up from Ludo <guixy>When I load a disk image in virt-manager, it doesn't recognize the disk's size. <guixy>I made a 10GB disk image, but when I call df -h it says the disk size is 492M <guixy>When I load the resulting file as a loop device in gnome-disks, I see nothing labeled "system". Could that be what's wrong? <bavier[m]1>guixy: usually the disks created are resized on demand, right? <NieDzejkob>I like the bootstrapping efforts too. Not much of a practical advantage to be honest ***jonsger1 is now known as jonsger
<mbakke>I enjoy the strong focus on unbundling software and running package tests too (also not a practical advantage, rather the opposite :P) <mbakke>we do have grafts as an actual advantage, and less build system hacks such as patchelf and compiler wrappers <Noclip>How do Nix and Guix compare for virtualization, containers and custom environments? <jonsger>some hours later I finally have my desktop running Guix :P <mbakke>I believe Guix and Nix are pretty similar when it comes to containers and environments... Guix has an advantage in Ganeti though ;-) ***catonano_ is now known as catonano
<Noclip>How well does the nix importer work? Is there extra work required to get nix packages work with guix and does it work for all or just for some packages? (The main advantage of nix seems to be it's huge repository with basically everything in it.) <guixy>When the script is finished executing, du says the disk is more than 10GB large. <guixy>When I start it in virt-manager, it is 429M large. <guixy>When I run guix pull, it says the database is full. <pkill9>so, I've made a guile script that lists all available packages in guix, and when you select it it checks for .desktop files and binaries in /bin and opens the first one available, and it checks to see if the package is already in your guix profile and uses that one if it is <pkill9>one step closer to creating a launcher of all packages regardless of whether they're 'installed' or not <pkill9>I'm going to eventually have it check the guix repository log for new packages, and list those, and update guix in order to get the new package definitions lol <pkill9>(and then build and run that package) <lfam>pkill9: It's like a testing / quality assurance tool? <pkill9>lfam: no, it's a launcher for packages, but not just for installed ones, for any available package definitions, thanks to the power of guix <pkill9>particularly desktop packages like blender/krita, hence it prioritising opening the file path in the .desktop file <pkill9>but i'm going to have it open a terminal with a guix environment with the package in it if there are no .desktop files <pkill9>it's good for seeing if a software is packaged when you hear of it <pkill9>and then if it is and you want to try it out, you just press enter and guix will download/build and run it for you <guixy>We already have "guix environment --ad-hoc packagename -- command" that does somethng like that. <pkill9>I know, but that requires looking up the name of the binary, and entering it in terminal <guixy>Sure, it requires you to know what the package provides, but that makes it more reliable than a script that runs the first binary it sees in bin. <guixy>What would you expect your script to do with binutils for example? <pkill9>actually it provides a list of binaries which you select <pkill9>i think it selected first one in an older version <pkill9>currently just uses dmenu (or bmenu in my case for wayland) <guixy>What about providing arguments? <guixy>Like if I want to run strings on a binary file. <pkill9>it's more focused on desktop packages that you wouldn't open in the command line anyway <pkill9>but for non-desktop packages it's going to open them in a terminal in a guix environment <guixy>How does it tell if it's a non-desktop package? <pkill9>it looks for .desktop files in share/applications, if there are none then it assumes it's not a desktop package <guixy>That is a reasonable expectation, but a few desktop packages don't provide .desktop files. <pkill9>it would be best to amend the package definition so a .desktop file is provided <pkill9>that's what is done with xonotic <pkill9>but yea it won't be perfect, like anything that is automagic <pkill9>i think .desktop files are pretty standard now though <Noclip>What happens if I install guix on debian and then install an application with guix that has already been installed with debian? <pkill9>it only works with guix profiles, it uses the manifest to see which packages are installed to it <guixy>Noclip, If you run a command from the terminal it runs the first match it can find in PATH I think. <guixy>I think you might see duplicates in your desktop menus if you have duplicate packages. <pkill9>but it relies on an external module so it won't work <Noclip>How are installed guix packages linked into the system? Symlinks / Path ? <pkill9>yea, i haven't implemented handling duplicate packages <guixy>Noclip, If you just installed one of the programs earlier in PATH than the old one and you haven't rehashed, I think it will go with the old package until you rehash. <pkill9>also it doesn't rely on $PATH, it gets the store path for the package and looks for things itself <guixy>They usually are symlinks in your profile directory. <guixy>Linked to where they are built to in the store. <pkill9>they are accessed by the system using environment variables <guixy>If a directory just contains stuff from one package it will be linked instead of all the stuff from that package. <Noclip>So it doesn't create symlinks in system directorys like /bin ? <Noclip>Mhh, that wouldn't even work as a multi user concept anyways. <guixy>I'm having trouble making an EXT4 disk image that says it's larger than 492M. <Kozo>Hey, if i install pinentry-gnome3 globally, it doesn't work. Once I install it per user, it works. I don't know where to start troubleshooting <Noclip>Can I break anything by just installing guix into my daily linux system and testing it? <lfam>Noclip: No. It's designed to be used that way <lfam>Kozo: In the past, it wouldn't work out of the box either way. You would have to set the option 'pinentry-program' in "~/.gnupg/gpg-agent.conf" to point to it <lfam>Kozo: Now, it automagically does the right thing if you install it per-user <lfam>If you want to look into it, check out the Guix package patch "gnupg-default-pinentry.patch" <lfam>Since GnuPG with a pinentry is really a per-user thing, I don't think it should work automagically when installed globally <lfam>Maybe it would work correctly, I'm not sure <Kozo>Thank you lfam. I'll check it out. <Kozo>Emacs-git-auto-commit is very nice :-) <Noclip>Are guix services only available in the standalone distribution? <Noclip>Is there anything I should prepare before installing guix (just the package manager) and playing around with it? <Noclip>"A build function always produces the same result when passed a given set of inputs." <Noclip>Is this really always the case? I mean there can still be hardware differences between two systems. <bavier1>Noclip: some of those hardware differences are eliminated in the setup of the build container, and normalization of configure/compile flags, etc <bavier1>others are fixed as/when devs notice differences from 'guix challenge' <bavier1>between builds on a single computer it's even more likely that the results are the same, because many packages are checked with 'guix build --rounds=N' <pkill9>are the containers produced by `guix environment --container` safe enough to protect against malware? <pkill9>probably simpler just to use separate users really, but I want to mix and match sandboxes, so containers would probably be more flexile <pkill9>i can't think of any reason they're not secure enough <guixy>I looked back on when I had successfully made a VM. I guess I used guix system vm-image back then. <Noclip>Are they as secure as docker containers can be? (Or even more secure?) <guixy>fine. Hacking away as usual. <brettgilio>nckx: Hey I got your report on the Mercury build failing for you. I gc'ed and cleared all of my local builds and I cant get the failure to reproduce. <pkill9>maybe ultimately security is an illusion, and we should just try to make sure we no more sensitive data than we need on machines connected to the internet, or accessible by other people <brettgilio>pkill9: I would say that security is not so much an illusion as much as it is not a guarantee. Especially in our current era where software is written in poorly specified languages that run on residual undefined behavior. <brettgilio>We just need to do (alot) better in how we design software <brettgilio>and stop using languages that dont provide guarantees about how execution happens <brettgilio>We have a mathematical toolbox full of logical applications, but only the smaller few of programming languages use them (Standard ML, OCaml, Haskell, Scheme) <brettgilio>Thats part of what bandali and I wanted to do awhile back before I took my hiatus, bring formal methods tooling to Guix :) <guixy>Security is a little more real than an illusion. We can protect against predictable vulnerabilities. It's the unpredictable and neglected vulnerabilities that make complete secuirity impossible. *bandali waves at brettgilio <brettgilio>bandali: I sent you an email about 5 minutes ago :) <bandali>brettgilio, great timing! :-D checking <brettgilio>bandali: I know it is great timing, because I saw your emacs bug report on persian fonts :) <bandali>yeah that issue has been pretty..annoying..to say the least :-p <Noclip>Does the install script also setup the deamon correctly and authorize substitution? <Noclip>Ah, the installation-video seems to answer my question (with yes). <brettgilio>Noclip: So installing on a foreign distro DOES authorize suhstitutes? i think it used to be that you had to do that manually. <Noclip>No the skript asks you if it should be authorized or not and then does it if you wanted it so. ***XMOPX is now known as xmopx
<Noclip>If the tutorial videos show a few dots on the command line ("...........") does that mean that they didn't show the complete shell output? <c4droid>Em, "guix system init" command can set users password at system installation? <Noclip>Is there a command to show the download and/or installed size of a package before installing it? (Debian's "apt show <pkg>" does that for example.) <nckx>brettgilio: Thanks. I'll try it a few more times. <Noclip>What does "systems: x86_64-linux i686-linux" refer to? The pre-built binarys (substitutions) on the build farm? <nckx>Noclip: The supported systems for which the package can be built. <nckx>I don't know, what's the context here? <nckx>‘guix show’ seems to show ‘systems: x86_64-linux i686-linux’ no matter what I type. <Noclip>Or does ist only mean that my system can't build bash? I'm a bit confused now as guix officially supports arm chips. <nckx>I'm not sure it means anything. <Noclip>Maybe that line should be removed then :D <nckx>…so ‘systems:’ is (package-transitive-supported-systems p)… <nckx>Noclip: Nah, just fixed 😉 <nckx>OK, I get it. The result of package-transitive-supported-systems will always be clamped to i686-linux+x86_64-linux on x86 because that's all the bootstrap Mes supports. <civodul>nckx: i vaguely remember a bug in the systems "guix show" reports that we discussed with cbaines long ago <nckx>It makes a computery kind of sense and is ‘correct’ but it also makes p-t-s-s useless for what it's probably intended to do. <nckx>civodul: Ah, OK. So this is known but not the fix? <civodul>i'm sure it's "somewhere", we just need to find out and make a proper bug report if it's not there yet <civodul>my recollection is that it's too slow so we'd need something smarter <rovanion>nckx: I'm reading the kernel manual on intel_pstate and "Active mode - In this mode the driver bypasses the scaling governors layer of CPUFreq and provides its own scaling algorithms for P-state selection." <rovanion>So that would explain why setting the scaling governor through cpufreq-set had no effect. <rovanion>Given that my CPU is in active mode. I've not found where I can see that yet. <nckx>rovanion: Interesting. Nor do I, but temper your expectations: most modern CPUs consider user-space power meddling obsolete, to the point that ‘performance’ saves more power than ‘powersave’/‘ondemand’ because it now means ‘leave me alone granddad’. <nckx>Of course that depends very much on your CPU & your goals. <nckx>It's as easy as the box suggests. <nckx>Don't forget to add (gnu services pm) to your use-modules. <rovanion>So instead of (use-modules (gnu)) I'd write (use-modules (gnu services pm))? <nckx>(use-modules (gnu) (gnu services pm)) <nckx>It's conventional to put a newline after (gnu) but up to you. <nckx>Also wow, how minimal is your configuration still 🙂 <rovanion>Touched it once before. Really just starting out. <leoprikler>Btw if you use lots of service modules, there is use-service-modules ;) <rovanion>Looks like I have both in my config.scm, so instead of adding (gnu services pcm) inside (use-modules) I could add pcm inside (use-service-modules)? <leoprikler>brettgilio: "We need to stop using languages, that don't guarantee how execution happens" But I like Guile :( <nckx>HexChat scroll jankiness made that ‘We need to stop using languages’ which is perfect and now canon. <rovanion>nckx: Hmm, that paste: Adding such an example to the manual would perhaps be repeating information found otherware, but useful for newcomers I think. <nckx>rovanion: In this case I fully agree, since there's a trivial ‘example’ already. <leoprikler>pkill9: I'm sure you could refactor this to use Guile/Guix only <NieDzejkob><Noclip> Is there a command to show the download and/or installed size of a package before installing it? (Debian's "apt show <pkg>" does that for example.) </Noclip> guix size uses substitute information to tell you, guix build -n will tell you how much will be downloaded <Noclip>NieDzejkob: Exactly what I was looking for, thanks! <nckx>Hm, that doesn't work here. <nckx>It does when I query ci.guix instead. <NieDzejkob>right, guix.tobias.gr doesn't have the API enabled, no? <nckx>It doesn't run Cuirass ☹ I'd like to support this though, so todo it is. <nckx>Does it use an ‘API’ call or HTTP content size header? I could fake the former, not sure about the latter. <nckx>'T would seem to be the latter. <civodul>nckx: you won't see how much will be downloaded unless your server runs "guix publish -C" <civodul>without -C, nars are prepared and compressed on the fly so their size is not known in advance <nckx>Got my hopes up for a sec. <nckx>IME -c (--cache) isn't great for a mostly-personal server, where you're more often than not the first user left holding the empty bag. <nckx>I can script a scraper, fine. <nckx>…caching everything twice (once at home just to get the size, once more at the Internet, for higher speeds)… <nckx>I think I'll punt on that but will tell others it's possible. <Noclip>"guix pull --news" as normal user shows nothing while it shows 1145 updated packages as root user. But both users are already at the same commit! <jonsger>efraim: do I need to run `guix system reconfigure` somehow special when I used locally defined modules like your (config filesystems)? Because I always get no code for module... <efraim>jonsger: I have to add -L /path/to/guix-config when I reconfigure <rovanion>Is there a difference between running `guix system reconfigure /etc/config.scm` and `sudo guix system reconfigure /etc/config.scm`? <nckx>rovanion: The one without sudo should fail at the end but both will build the same thing. <rovanion>nckx: Right, failing to change the symlink for the system. Interesting that everything up to that point doesn't require root. *nckx spoils the magic by pointing out the daemon runs as root, but yeah, the builds themselves are unprivileged. <nckx>Kimapr_on_window: Is there a typo in there somewhere or do I just not get the last line? <nckx>To me, not even seeing something boot == faster. <Kimapr_on_window>i meant it was soo slow that it didn't even boot. i choose an item in grub menu and just had empty text screen with cursor at the corner. <nckx>I don't use VB but I'll give it a go. Do I need to convert it somehow? Does VB do some kind of Qemu compatibility dance that could slow things down? <raghavgururajan>How do I invoke a program inside 'pre-check phase, that requires to be ran as root? <nckx>raghavgururajan: Not. You convince it that it doesn't need to be root after all & it was just a big misunderstanding (maybe it can do its job just fine if you comment out a UID == 0 check), or disable those tests as some packages do. <nckx>It all depends on why it wants to be root. <nckx>What's TCB? Web gives no plausible answers besides Trusted Computing Base as a general concept. <nckx>OK, by Web I mean Wikipedia. <nckx>raghavgururajan: And is it, for example, demanding root to open port 53? If so, can it (and the test suite) use a different port with reasonable effort? <raghavgururajan>nckx: avahi-daemon --no-drop-root works without root. But fails with no 'avahi' user found. <Kimapr_on_window>AFAIK TCB is the thing in qemu that converts virtual instructions to native host instructions and runs it there ***jonsger1 is now known as jonsger
<nckx>raghavgururajan: avahi-daemon unconditionally checks for the ‘avahi’ user, I don't see a way around it. It's fine to disable the affected tests. <nckx>(in avahi-daemon/main.c's make_runtime_dir if you care.) <mbakke>Formbi: there is an example in the manual, in the slim-service-type description <Kozo>Is there a way to do per-user package installs via config.scm? <Noclip>I have the feeling that "guix pull" and "guix gc" revert each other. <Noclip>Doing "guix gc" after "guix pull" seems to throw away a lot of stuff, so why did I had to download / create that at all? <roptat>Noclip, they don't completely reverse each other, guix pull might need some stuff at runtime, but then it should register a gc root on the result, so you can use the newer guix even after a gc <roptat>the runtime stuff can be collected by gc <roptat>the same happens with grafts: guix needs the ungrafted version to determine what it has to graft and compute the name of the grafted variant; but gc will collect the ungrafted variant, so if you later want to build the grafted package, guix will have to re-download the ungrafted package <roptat>you can prevent that kind of behavior by using --gc-keep-outputs=yes and --gc-keep-derivations=yes: this will keep the runtime dependencies and the ungrafted variants of the packages from your profile <civodul>i wonder if we should change 'guix gc' to be equivalent to 'guix gc -F10%' by default <roptat>it's not the default because it makes your store bigger and prevents gc from collecting a lot of things <Noclip>roptat: Eventually it had also to do with the guix source changing from hour to hour without me noticing it. <Noclip>It was most likely a mix of both effects. <Kimapr_on_window>is there a way to install guix installer image as a separate partition(s) on existing drive without wiping everything? <nckx>Kimapr_on_window: Can't you download the image again and attach it to VBox as a ‘drive’? Possibly after wrapping it in a VMDK or whatever. I think so. <Noclip>I think VirtualBox has native support for (qemu) disk-images. <Kimapr_on_window>i don't want to attach the image to virtual machine, i want to attach a real usb hdd drive <nckx>Kimapr_on_window: Doesn't matter if it's USB or not. You need to wrap any raw drive in a vmdk, I'm sure you'll find instructions. <Noclip>nckx: Do you have an idea how I can get rid of my error message? <Noclip>I had rolled back my guix setup to generation 0 (guix pull --roll-back) and after that I got the error. <Noclip>(Except of that error message guix seems to be working fine.) <nckx>I hadn't seen the error message. I don't. This is after you gc'd? <nckx>My guess is a broken reference because of that. Maybe civodul has a clue. <Noclip>I might have also gc'd one or several times before it happened. <Noclip>Has guix a command to repair broken references? *nckx has never used inferiors beyond ‘heh, cool toy, *backspace*’. <Kimapr_on_window>nckx: if there are files for drives in windows then why use vmdk at all? <nckx>Noclip: Guix would never delete any reference it knows about. So any ‘guix fsck’ would have a second reference scanner that's better than the ‘real’ one, and Guix should just use that one instead. <nckx>Kimapr_on_window: Because I thought you were still using VirtualBox. :o) I'm not familiar with Windows at all. <nckx>Kimapr_on_window: Why did you try VirtualBox first? <nckx>Neat. I didn't know Qemu ran on Windows. <Noclip>nckx: With the root user I don't get that error message so it must has something to do with my per user setup. <Formbi>mbakke: I know, but I used the example and Guix says «guix system: error: service 'xorg-server' provided more than once» <Formbi>maybe it is because I used the gdm remover inside modify-services? <Kimapr_on_window>When i try to check my root partition in the vm, I get "e2fsck: unable to set superblock flags on dima-guix" <Formbi>ok, I got it, I had to add «slim-service-type» to set-xorg-configuration <Formbi>but now it says «more than one target service of type 'slim'» <nckx>Kimapr_on_window: That means the (virtual) device is accepting a write to the superblock withou error, but then returns old (my guess) or bad data when e2fsck re-reads the block. <Kimapr_on_window>it also says "Superblock invalid, trying backup blocks" on my root partition <nckx>Could be a cache issue. Could be worse. It's likely the complex data path you're using is ‘lightly tested’… <nckx>Kimapr_on_window: Do you have the storage space to save a complete backup image of the drive before you continue? You're making me extremely nervous. 🙂 <nckx>Running the fsck directly on an image file passed to qemu.exe would also remove part of the indirection that's going on. <nckx>If that succeeds, you can dd.exe it back or whatever. <Kimapr_on_window>i don't have the storage space to save a complete backup image of the drive <Noclip>Is there a reason not do that: "$ rm -r /var/guix/profiles/per-user/xyz && rm .config/guix/current .guix-profile" ? <Noclip>Maybe it could fix the error message. <nckx>Kimapr_on_window: I didn't understand your ‘UEFI duet’ reason for not being able to boot a real installer. That would be so much safer. <mbakke>Formbi: can you paste the services portion of your system configuration? <nckx>Noclip: That's fine, but use ‘mv x x.bak’ just in case. You'll lose your user packages from $PATH & be back where you started: using the ‘system guix’ to create your first user profiles. <Noclip>That's exactly what I want. I haven't done anything else then testing and playing around with guix anyways. <NieDzejkob>Hi, I'm trying to debug a remote network. When did my nick last quit? <NieDzejkob>Kozo: for that, you want to use a separate file known as a manifest. You use it with guix package -m <NieDzejkob>you can use either packages->manifest or specifications->manifest inside the file <NieDzejkob>Formbi: Hmm, maybe the doubled slim-service-type is a problem? Does the error persist if you use only one? <nckx>NieDzejkob: 14:44 (Ping timeout: 272 seconds). No higher resolution here. <Formbi>NieDzejkob: it's the example from manual <Formbi>I commented one slim out and the xorg-server error still appears <Noclip>Looks like I got rid of the error message! 🎉 <NieDzejkob>Formbi: huh, when does the error appear? I'm experimenting with 'guix system build' and the pre-build checks all succeeded <Formbi>it appears when I do build or reconfigure <mbakke>Formbi: apparently set-xorg-configuration does not work when you have multiple slim-service-types :/ <NieDzejkob>I'm having trouble reproducing the exact error Formbi pasted, though <mbakke>"guix system: error: more than one target service of type 'slim'" ? <mbakke>the first error was because set-xorg-configuration pulls in gdm-service-type unless a service-type is given <NieDzejkob>is there a way to extend all services of a specific type? ***NieDzejkob_ is now known as NieDzejkob
<civodul>NieDzejkob: extensions apply to a service type <civodul>when extending though, there must be only one instance of the given service type <NieDzejkob>yeah, but sometimes it makes sense to extend all of the services with a matching type, instead of requiring there be only one <civodul>ah yes, i hadn't read the set-xorg-configuration example above <civodul>one way to sidestep the issue in this case is to have a single slim service handling as many slim daemons as needed <roptat>that's more or less what I do in the guix home manager with extension points <civodul>IOW, one slim-service-type instance produces one or more slim shepherd services <roptat>a service can declare a named extension point, and multiple services can declare the same point <roptat>then another service can extend this extension point, and the value is passed to every service that has that extension point <civodul>you should email guix-devel about this <civodul>(also you should write a blog post about Guix Home, hint hint! ;-)) <rovanion>Yes, I've been looking for an equivalent to Nix's home manager but not found anything. <Formbi>mbakke: now I have one and it still doesn't work <roptat>it's not exactly the same as Nix's home manager <NieDzejkob>extension points would also allow set-xorg-configuration to not need the service-type argument <roptat>right, that could be a good use case <NieDzejkob>Formbi: could you paste your config again? I put the services into a bare-bones one and after commenting out the second slim, everything works <roptat>rovanion, the home manager completely takes over your home directory. With Nix, it simply copies files but keeps them writable, so any software could change your configuration. The guix home manager creates a profile for your home, so it's completely read-only <roptat>you can poke holes by creating symlinks to a writable directory, which I do for .local and .cache for instance, as well as for software that don't work when the configuration is read-only <roptat>or whose config I haven't converted to a service type <NieDzejkob>could you try it on your side to check if it works? <NieDzejkob>if it works, could you try to minimize your operating-system into a full example that breaks? <apfel>hi there i try to build a package definition with my locale guix checkout. package: https://pastebin.com/Sxfu8TbN - but i get the following error: guix package: error: getting attributes of path `/gnu/store/3il0ngja1qn6vz72bvmkfxa0b9271nhr-bootstrap-mes-0': No such file or directory <apfel>it did work once bevore, i think i might messed up my store somehow ... <roptat>apfel maybe try to run "guix gc -D /gnu/store/...-bootstrap-mes-0"? <roptat>the reasonning being that if the directory doesn't exist but guix thinks it does, the gc will help guix understand the path doesn't exist anymore <NieDzejkob>roptat: I can't find any documentation for named extension points, could you point me to the relevant manual page or code? <roptat>NieDzejkob, it's not in guix, but in the guix home manager <apfel>roptat: oh well, if i use pre-inst-env guix gc works, a simple --verify did the trick. But i thought that the store is actually the same? like it is shared between normal and pre-inst-env <roptat>it should, unless you forgot to pass --localstatedir to configure? <roptat>in that case the store is shared, but not the database <Noclip>Uff, diskspace is really a disadvantage if you have every package installed in around 10 different version ... <apfel>roptat: I will check, i will try using a seperate directory, thanks <roptat>just reconfigure your local repo with --localstatedir=/var and everything should be fine <apfel>roptat: will, but if i do not specify a prefix it should be /var by default <roptat>it's /usr/local/var by default, because autotools... <apfel>oh shit, yes, thats true, thanks again <rekado>how’s the JavaScript implementation of Guix coming along…? <civodul>hey rekado, that sounds exciting :-) <civodul>"make scientific packaging more sustainable" uh <Formbi>NieDzejkob: that error seems to be caused by having (rnrs lists) imported <Formbi>maybe it does the things differently than srfi-1 <guixy>I made a VM with 20 virtual terminal TTYs. <guixy>It looks like there's a log hard-coded to tty12. <guixy>Is there a way to change/remove this? <guixy>It looks like tty12 is used in %default-syslog.conf <NieDzejkob>Formbi: (rnrs lists)'s remove takes an object and it compares it with equal?, (srfi srfi-1)'s remove takes a predicate <NieDzejkob>so by importing (rnrs lists) you (attempt to) remove the lambda from the list of services <Noclip>Can the guix store sit on a fat32 filesystem? (I'm thinking about android and my SD-card ...) <Formbi>fat32 doesn't understand Unixy permissions <Noclip>Would it be impossible on a SD-card or would it just be insecure? <Noclip>Security shouldn't be that much of a problem as my planned setup would be chrooted and containerd several times. <Noclip>And my smartphone isn't rooted so the system would not have root access. <guixy>The store is normally mounted read-only to prevent an outsider altering anything in there. <guixy>I think rooting gives the user root access. I don't know much about android, so I don't know what programs have root access. <Noclip>Android (Termux (Proot (Alpine Linux (Guix (Guix store on SD-card))))) <nckx>One word: symlinks. The store must support them. <roptat>Noclip, can't you simply Android (Guix (Guix store on SD-card))? <Noclip>roptat: I assume that's not possible without root. *nckx .oO Android's the Linux one, right? <Noclip>nckx: Unfortunately not without root. ☹️ <nckx>Silly question: why can't you log in as root? <Noclip>I didn't root my device. Maybe I will do that at some point. <nckx>Searching for ‘android root password’ implies… it's complicated. Never mind. <roptat>when you buy the device, it comes with a system pre-installed, with no root access for you <Noclip>On the other hand it can be an interesting challange to get "rooty stuff" done on a non root android device xD <roptat>you could get root by exploiting a vulnerability, or by installing a custom ROM, if the vendor allows that <roptat>even that can be difficult, as the bootloader can be locked into accepting only a ROM signed by the vendor <roptat>but "it's not like we're selling you a computer" :p <Noclip>Smartphones have never been made for people who are able to use a computer ... <nckx>I thought they were basically small computers running Linux without GNU or Mac OS without whatever. <Noclip>You can make some photos with seem and then even some more photos and together with whatsapp that's already enough for most people. <Noclip>Guix is an hackable OS and smartphones are "hacking resistant" systems. <nckx>Guix is hackable? I knew it. I'm going to install Windows. <Formbi>doing any hacky stuff on a non-rooted phone is trash <Formbi>I would highly recommend rooting <nckx>So you buy a phone, then have to wait for a zero-day to use it? Wha? <Formbi>some producers allow installing rooted distros without a hassle <Formbi>«Many vendors such as HTC, Sony, LG, Asus and Google explicitly provide the ability to unlock devices, and even replace the operating system entirely.» ~ Wikipedia <nckx>But the next sentence is ‘However, the support may be limited only to certain phones - for example, LG released its bootloader unlock tool only for certain models of its phones.’ <nckx>So Noclip just bought a dud I guess. *nckx goes back to hacking e-mails. <nobodynogroup>how do i view the definitions of the format u-boot-*-bootloader that are in (gnu bootloader u-boot)? <Noclip>What happens with "guix environment" after leaving the environment? Does it leave any traces on the host system? <Formbi>the thing stay in /gnu/store until a gc <nckx>Noclip: Only ‘inert’ files in /gnu/store and /var/guix, that will be cleaned up by a GC or re-used when you enter a similar or identical environment. <nckx>The environment itself is just that: a Unix process environment, that dies when the shell or command spawned by ‘guix environment’ dies. <blackbeard[m]>I think that --pure is to make sure everything disappears right? <roptat>no, --pure makes sure you're not polluted by environment variables from outside the environment when you enter it <roptat>guix environment ... -- env and guix environment ... --pure -- env will not return the same thing <Kimapr_on_window>Is there a way to break the root filesystem enough to trigger a check and "unexpected inconsistency" so that bournish gets invoked? <nckx>Kimapr_on_window: You crave the danger, don't you. <nckx>Here's another idea: mutilate the UUID of the boot drive in the GRUB menu so the initrd doesn't find it and drops you in a post-module REPL. <nckx>You're right, I should set a highlight on all permutations of cnxk. <nckx>Should. As long as it's something bogus that can't be found. *nckx .oO Do telephone keyboards have a tab key? <roptat>it's all software, so if the software supports it, yes <roptat>the terminal on my phone understands "volume down" as the ctrl key for instance <roptat>and you can enter a special key from the menu <nckx>Kimapr_on_phone: Yay! Does it have modules now? <nckx>roptat: Ah. I was looking at images and didn't see one. <roptat>also if you have an adapter, you can use a physical keyboard through the usb port <nckx>What a time to be alive. <Kimapr>Now someone has to explain: why doesn't guix system check filesystems other than root by default and fails to boot instead when they aren't clean? <nckx>Kimapr: Yay, welcome back. So what exactly happened after fsck failed? I'd expect you to be dropped into a REPL, that's what happens when my mdraid fails to assemble. <Kimapr>The filesystem that made system fail to boot wasn't the root one, it was my home directory partition <nckx>I think Guix also disregards check? for the rootfs, but I still need to confirm that. <nckx>Kimapr: And what happens then? <Kimapr>file-system service just failed to start <Kimapr>The home filesystem broke after an unexpected shutdown <Kimapr>because electricity services are bad in my area <vagrantcish>Authenticating channel 'guix', commits 9edb3f6 to 819b8b2 (252 new commits)... <vagrantcish>[############## ]guix pull: error: could not authenticate commit c1f38577c8a04332b21460fa08bdf0c72093c897: key #vu8(232 42 192 38 149 214 255 2 67 202 30 92 246 197 45 209 186 39 203 135) is missing <jackhill>vagrantcish: what's your channel config? "Authenticating channel 'guix', commits 9edb3f6 to 7a9a27a (28 new commits)..." just worked for me. <jackhill>that seems to be many fewer commits than you have… <civodul>vagrantcish: could it be that you're running "make authenticate" from a checkout, and your 'keyring' branch is not up-to-date? *civodul tries to guess :-) <nckx>Confusing that ‘make authenticate’ prints ‘authenticating channel’. <vagrantc>civodul: i'm running "guix pull --url=/path/to/guix" ... on the first pass the keyring branch was not up-to-date ... but then re-running it after updating the keyring branch doesn't help <civodul>vagrantc: hmm 'guix pull' updates everything by itself, what do you men? <vagrantc>civodul: i use a local checkout ... does it use origin/keyring ... or my local keyring branch? <civodul>'guix pull' uses 'origin/keyring', but here 'origin' is /path/to/guix <vagrantc>since i actually make changes to guix, i always update my local copy and then pull from there, rather than re-downloading all the same git history <vagrantc>well, it re-downloads it ... but from one location on my disk to another :) <civodul>the checkout is kept in ~/.cache so it just downloads the new commits <vagrantc>sure, but no need to download them a second time <vagrantc>i think this has happened to me before ... and i just had to wipe out the authentication history somehow <vagrantc>maybe i just wiped out the whole .cache ... <civodul>you make it sound like it's always been buggy, make sure to report bugs :-) <civodul>my guess is something about 'origin/keyring' in the ~/.cache copy not being up-to-date <vagrantc>i've been known to report bugs now and then :) <civodul>very likely, since it's a "missing key" error <vagrantc>ah, i think that might be what i did ... <vagrantc>cd ~/.cache/...guix/ && git fetch or something <vagrantc>it didn't re-fetch from --url= probably because the master branch hand't been updated <tirifto>Hello! Could someone confirm whether there are no substitutes available for ‘icecat’ and no builds therof in queue right now? (I think that’s what ‘guix weather’ is telling me, but it seems odd.) <sseneca>hi all. I want to install gnu guix on a laptop. its networking drivers aren't free software so that won't work, but its use case doesn't require networking, so I want to do it anyway. does anyone know how I could go about updating it every so often? it doesn't have an ethernet port. <civodul>tirifto: it seems to be the case, indeed <tirifto>Guess I’ll check again tomorrow. Should be faster than building. :P *vagrantc takes a wild guess on rust <vagrantc>how much rusts are built to get to the one used in guix? <jonsger>oh, it's nice how much faster building guix on a desktop is compared to a laptop :) <jackhill>sseneca: is a USB network card an option? Another option could be using guix archive --export on a different machine, and then guix archive --import. It's possible, but will requiere some thinking or scriping to make sure you get all the bits :) <jackhill>sneek: later tell sseneca is a USB network card an option? Another option could be using guix archive --export on a different machine, and then guix archive --import. It's possible, but will requiere some thinking or scriping to make sure you get all the bits :) ***catonano_ is now known as catonano
<jonsger>nice I finally have hunspell-dict-de working :)