<Blackbeard>liberdiko: hey, what was the issue from mexico? I can try to reproduce <PathIssue>Ifam: where is config.scm (since my ls is broken)? <lfam>PathIssue: I think you are seeing a bug we already had fixed, I'm searching for the report now <PathIssue>i did perform a guix pull && guix package -u <lfam>Are you using the latest release, PathIssue? 1.1.0? <PathIssue>I might have used an old ISO version of guix I had and assumed an update would fix all issues <lfam>Since you just got started, I recommend downloading the new release and using that, rather than working around the bug and then trying to update <lfam>It will be easier for us to support you that way <PathIssue>The install goes rather fast; okay, thanks. GUIX looks great. Have a great day. <lfam>Sorry for the terrible bug <PathIssue>No worries, I can still manage most of the system without basic commands like rm and ls <PathIssue>tough to delete that swapfile i needed though <lfam>The workaround would be `guix install coreutils`, fixing the generated config.scm, pulling and reconfiguring <Blackbeard>lfam: would it be possible to use the newer ISO to chroot and update ? <lfam>The root of the bug was that the installer did not set up the global packages correctly, omitting the list of %base-packages such as coreutils <Blackbeard>I would do that but not sure about the problem so maybe not helpful <lfam>It would be simpler to work around Blackbeard, but better overall to just use the new release. There are many other bugs fixed since 1.0 <PathIssue>the base-packages kept failing with 1 GB of RAM (half swap and half real); I had to make a 1 GB swapfile to get the base-install to work <lfam>I recommend just beginning with 1.1.0 <PathIssue>Thanks for your help; I'll try with the 1.1.0 <lfam>We might also be missing substitutes from 1.0, and you'd have to build a lot from source in that case. <lhp22>Hi ! I'm new with Guix (I've installed it on a Debian VM to test) And I don't understand all. If I do two `guix pull` on a two differents account : will all the pull work be done twice ? <lfam>lhp22: Not all of it, just the "Computing Guix derivation..." part <lhp22>what does this part precisally ? Listing the version of each package ? <lfam>In practice, this means you get new versions of packages and new Guix features <lfam>But, it doesn't actually update the packages that you install. For that you use `guix package --upgrade` or the simplified alias `guix upgrade` <lhp22>yeah, the last part I've understood. But, each time I guix pull, it `git pull` the repo of guix and rebuilds it from the sources ? <lfam>It only builds from sources if there are no substitutes <mekeor>what if another user has the latest guix installed? does it build guix again? or does it link guix so that the user, which is not installing guix, can use the latest version? <lhp22>ok and substitutes are just a built package which have the same sha ? (and so are reproduiclbe) <lfam>mekeor: It reuses things when it can <pretzel>Hi, the certificate for guix.gnu.org expired. <lfam>lhp22: Substitutes are things that are already built. Guix is actually a build-from-source distro, but we have transparent binary substitution from our build farm <lfam>civodul, mbakke: The TLS certificate for guix.gnu.org expired ***nick333 is now known as covidman
<lhp22>Is there a way to do a full upgrade for each user with just one guix command ? Or do I ``su`` to each account ? <mbakke>lfam: the cert was actually updated on the server, I restarted nginx to activate it <lfam>There should be a hook in the certbot invocation that reloads (not restarts) nginx when the cert is renewed <mbakke>"someone" should implement a reload action for the nginx service :-) <lfam>I think it should be easier than restarting, actually <mbakke>and indeed also make certbot call it <lfam>lhp22: You can use `sudo -E` for that <lfam>This lets you re-use your Guix for the root user <lhp22>HHhm, is it normal that I can't do `guix package --help | less` ? Shell says to me that `less` is an unknown command. But when I do `which less` less is found in the guix folder <mbakke>lhp22: sounds like your PATH is messed up? are you in a `guix environment --container` or something? <lhp22>`less` is found except in a pipe <lhp22>It seems my problem came from the fact that my bash wasn't the by guix installed one <covidman>gotta have a fresh bash else it won’t rhyme or reason <lhp22>In which package is the ping command ? <mbakke>lhp22: I don't see how using bash from Guix would make a difference, but glad you fixed it :) <lhp22>mbakke i've no idea too, but that fixed the bug :3 <lhp22>Is this normal that a `gix pull` is really long ? <ecbrown>i just switched everything over to zfs and don't notice speed differences. memory consumption on the other hand... <covidman>feels like a 40% slowdown here but its like covid death rate : totally with sample bias ! <covidman>by this time I lost all respect for doctors. <pinoaffe>I meant herd as in the commandline tool for gnu shepherd <covidman>take my word for it. soon guix will rule the harddisk world <butterypancake>so I think I've finally generate a guix system disk image. Where does it create it? Where is the iso? <ecbrown>butterypancake: it is at the path returned, in the store <butterypancake>am I allowed to touch the store this time? There isn't a guix command I'm supposed to use? <ecbrown>butterypancake: if you lost it, just re-execute the build and it will return <civodul>we should check our nginx deploy hook <civodul>perhaps it's not working as expected <pinoaffe>why do some services have their own "own" lambda defined as in (dropbear (dropbear-config)) while others have to be used like (service-type dropbear-service-type ...)? <ecbrown>,ops please kick covidman for spamming channel <butterypancake>I'm starting to thing guix isn't for me... the ISO I made didn't work <ecbrown>butterypancake: sometimes the gui fails for me, but the old fashioned command line installer works great <reepca>butterypancake: how did it fail? <butterypancake>one sec, I'm going through the log folder. Anyone familiar with which log I need to pull up? It was a scheme error about some match not going through <reepca>my first guess would be /var/log/messages <butterypancake>May 2 02:24:40 localhost installer[417]: crashing due to uncaught exception: match-error ("match" "no matching pattern" (#f ext4)) <butterypancake>May 2 02:24:40 localhost installer[417]: running form #<newt-form 1b46340> ("Unexpected problem") with 0 clients <butterypancake>May 2 02:25:56 localhost installer[417]: running form #<newt-form 1a7eec0> ("Installation parameters") with 0 clients <butterypancake>when it crashed though it had a better backtrace. Does it save that backtrace? <reepca>¯\_(ツ)_/¯ personally I haven't installed since ye olde days of manual installation <butterypancake>damn, I don't think I have the backtrace. which is a shame because it had file names and line numbers and everything. I guess I'm going to try installing again and just take a screenshot ***ChanServ sets mode: +o lfam
<butterypancake>I mean I really should do the CLI installer reepca, but I already made a new ISO to avoid that, so I might as well debug this, and maybe even make a patch. I'd love to contribute to guix <lfam>covidman: The topic of this channel is Guix, please stick to it <covidman>I understand why guixSD is not ported to BASH <reepca>... agh, why couldn't I have found /tmp/last-installer-error in (gnu installer) just a few seconds earlier? <butterypancake>anyone here familiar with the parted.scm code in the installer? I need help debugging the user-partitions->configuration function <reepca>butterypancake: just found out the backtrace should be in /tmp/last-installer-error <butterypancake>well, I have a blurry photo on my phone that I'm working from. Better late than never but I'm not going back <reepca>does it say where in particular in user-partitions->configuration the error happened? <butterypancake>user-partitions->configuration calls user-partitions->file-system calls uuid->string but then (dispatch-exception 10 match-error ("match" "no matching pattern" (#f ext4))) <butterypancake>this is the point where I admit my familiarity is with elisp, not guile, and I'm not certain what the hell all these arrows mean <butterypancake>maybe I should come back after I've read the guile manual? Maybe I should just install using CLI? <reepca>does it say where uuid->string is defined? I actually can't seem to find it <reepca>does it say which line it occurs on? there are two matches happening there that could fail <butterypancake>I don't think that's helpful. But I'm really starting to think I don't understand guile <reepca>okay, so it looks like the internal uuid representation is a (bytevector symbol) 2-element list <reepca>the match fails because instead of a bytevector in the first position there's a #f for some reason (think NIL) <reepca>bytevector is basically just a fancy type for array of bytes <reepca>it seems that user-partition->file-system gets it from calling read-partition-uuid <butterypancake>#f = false!! shit I'm messing up on the parts of the guile manual I already freaking read... not a good sign <reepca>it's part of the object being used to represent it, aye. <butterypancake>so the match-lamda* is a switch case but because we don't have a default we just crash? <reepca>aye, uuid->string isn't particularly well-defined when the bytevector is #f <reepca>bv is an abbreviation for bytevector <apteryx>butterypancake: match-lambda, as its name implies, matches on the patterns (the cases), binding symbols such as bv doing so. <reepca>well if read-partition-uuid is returning #f, then it would make sense that none of %partition-uuid-readers returned a non-#f value. I see a fat32-superblock-uuid, and I see a fat16-superblock-uuid, but nothing about vfat <butterypancake>nope. there is fat12, fat16, and fat32. vfat is an extension you can put on any of those <butterypancake>so if anything we should be worrying that I have a FAT12 and you only found functions for FAT16 and FAT32? <reepca>aye, that's what I've found so far <reepca>did you do anything special with that partition in the installer? <reepca>one would hope that the installer would have some measure to handle the existence of unrecognized filesystems <butterypancake>aight. I'mma go see if that's our problem and maybe grab a proper backtrace. catch ya in 10 <butterypancake>I was actually meaning to do more testing but I somehow ended up in my main OS even with the usb plugged in :/ <butterypancake>so when you go through with the default partition scheme, it doesn't even tell you it's making a boot partition. You see the swap, you see the ext4 one, but it don't even mention the boot one <butterypancake>so I went through and told it manually to have a boot partition. And I had to choose between fat16 and fat32, no fat12 option! <butterypancake>("mount" "mount ~S on ~S: ~A" ("/dev/sda2" "/mnt/boot/efi" "No such device") <butterypancake>so obviously I try and run mount /dev/sda2 /mnt/boot/efi and there is no problem <butterypancake>did we ever advertise that our partitioner works? Because I think there are many layers to this <butterypancake>there is no reason I couldn't be calling this code from my arch install. Lemme see if I can test locally <butterypancake>ok, I have no clue how to test things locally. I think I just need to hit the guile manual <ecbrown>butterypancake: you can download the guix source and hack it, compile it <butterypancake>massive progress has been made since you've last heard of my adventures <butterypancake>Not only is guix now installed and compiled, but I even managed to create my own ISO <butterypancake>This new ISO even managed to solve every single problem I had with the official 1.1.0 ISO <butterypancake>If you let it go through with defaults, it trys to make a fat12 partition which is can't understand, and if you tell it to make a fat16 partition, it fails to mount it <butterypancake>I wanted to try running the partitioning code locally on my arch linux machine, but that involves loading a bunch of modules at once and I don't know how to do that <devtexa>Is there no way to properly handle the Luks encrypted disk when GuixSD is shut down? <devtexa>I have to fsck to repair every time I boot up and then display: recovery j..... <jackhill>devtexa: I think that it should just work At least mine always has with ext4 and btrfs. What's your partitioning scheme like? <devtexa>2: crypt_luks -> /dev/mapper/root ext4 <ryanprior>How do I test whether a package builds when I've modified its source in the guix git tree? <ryanprior>I test my packages in their own files using "guix build -f mypackage.scm" and then I want to test them before I submit them upstream but I have not figured out how to do that. <devtexa>I am the dos partition table. The first partition is ext4. Mounted in / boot <devtexa>The second partition is ext4 with luks encryption, decrypted and mounted on / <devtexa>The third partition is ext4, mounted on / gnu <pkill9>ryanprior: once you bootstrapped, configured, and make'd the source tree (the latter is technically optional, but you'll want to do that anyways so it doesn't compile everything each time), you run ./pre-inst-env guix build <your package> <ryanprior>Do I need to configure with a separate store or in a special way? <jackhill>devtexa: hmmm, I don't know then. I have only ever used one filesystem though. Maybe if you don't get help here, try on guix-help@gnu.org <devtexa>Is the default encryption scheme of Guix Graphics Installer feasible? <devtexa>I read Guix's grub.cfg. If /gnu is also encrypted, there is no way to find the kernel. How does it start? <jackhill>devtexa: grub known how to unencrypt the luks volume. You will get prompted for your password twice though, once for grub, and once for linux (we don't have a way for grub to pass the encryption key yet) <jackhill>:) grub does take longer to unlock than linux, but hey, it's a bootloader <jackhill>or perhaps bug-guix@gnu.org if you think what you've run into is a bug, which sounds possible to me, but since it's not clear to me why you're having problems it's hard to say for sure. <mroh>jackhill: bug 35085 is also about emacs not reproducable <vagrantc>wait, did guix get support for split /boot partitions? i thought /boot had to be on the same partition as /gnu ? <jackhill>mroh: thanks. I'll tell the tracker to merge them. <lonzo`>is linux-libre's support for AMDGPU good enough for gaming on steam? <reepca>lonzo`: I think you'll find that no modern AMD GPUs can provide 3D acceleration without proprietary firmware that, naturally, linux-libre won't load. For reference, I've tried the A10-7850k integrated graphics, a Radeon HD 6670, an R5 230, and a Radeon HD 7870. I've heard claims that the old trinity APU integrated graphics didn't require proprietary firmware, but haven't tested that. <guix-vits>raghav-gururajan: yes, i'd mean the web-mail interface. <Blackbeard>guix-vits: I am finally getting better. It was a bit scary. I was admitted two times at a hospital. Second one was were they treat covid in my city. <guix-vits>Blackbeard: Did this disease bring any damage to the city? I'm just have an strange impression from all this "citizen, go sit down to your couch, now (!)". <guix-vits>not that i'm understand anything about medicine. <killmeplease>guix-vits: yeah man they're lying to you, they're hoping we'll exercise less and become obese and be more docile and easier to control <killmeplease>Fast food had 20 years and wasn't on track for "The Undertaking" to happen on schedule <killmeplease>DO NOT BUY A TREADMILL, the authorities will sneak in at night and kill you and anyone else in the house. <guix-vits>killmeplease: there is approved version of treadmill, t-mkH (treadmil - mark "hamster"). Approved by Pope, tested by mr. Presedent personally. ***guix-vits is now known as dontbanmeplease
<killmeplease>Stop reading media they control. They expect some people to shun mainstream stuff, you have to read the next level. <dontbanmeplease>Yes, the planet should be controlled by alien-hamsters, nor by Nibiru lizards... ***dontbanmeplease is now known as guix-vits
<killmeplease>I thought you saw the truth but you're one of the government loons sent to make us look like dipshits aren't you? Traitor. <bandali>this discussion is completely off-topic for #guix; please take it elsewhere <killmeplease>That'd be a lesson - I'm pretty sure that learning through interaction with others is not something you want to exclude. Just when it's off topic. <lonzo1>is there a way to get AMDGPU with all the blobs for 3d acceleration? <raghav-gururajan>guix-vits Ah I see! Btw, disroot is currently working on new interfaces. RoundCube and MailPile. ***apteryx is now known as Guest78054
***apteryx_ is now known as apteryx
<bricewge>Blackbeard: You'll probably know if you are affected by this issue. The substitue server speed is caped to ~50KiB/s but small file wont be affected as much <bricewge>This thing is at first the 3 on us that were affected were on the same french ISP, Free, so we thought it was specific to that ISP. <bricewge>But some days ago one of your countrymen reported the same issue. <bricewge>To confirm the issue run "mtr ci.guix.gnu.org" and you'll probably end up with a lot of packets loss on one of the hop. <reepca>lonzo1: probably, but it would be off-topic here, as non-free software is outside of the scope of guix. <lonzo1>reepca: where should I ask this then? <pinoaffe>PotentialUser-59: I don't think I've seen any attempts / work on supporting it, but if someone to run flatpak apps in a guix environment, I think it'd be merged <reepca>lonzo1: a search engine, I'd imagine. <janneke>or in a community that does not protect user freedom :-/ <rekado>bricewge: “substitue server speed is caped to ~50KiB/s” <– what does this mean? <devtexa>How do you optimize the performance of the nfs file system? I tried to build a Guix cluster, but my client is very slow. <bricewge>rekado: I know. But since ~3 weeks some people have issue accessing the substitute server at reasonable speed <rekado>bricewge: there’s nothing we can do when some hop on the way to ci.guix.gnu.org drops packets <rekado>it doesn’t seem to be a problem with how things are set up <bricewge>rekado: It seems limited to some ISP though, big file are downloaded at relatively fast speed but big ones >10MiB are throttled <rekado>devtexa: is the daemon accessing /gnu over NFS? Or just the clients? <pkill9>i'm getting this error" /home/itsme/sc-controller.scm:33:16: error: (%modify-phases phases* (add-after (quote unpack) (lambda* (#:key inputs #:allow-other-keys) (let ((linux-libre-headers (assoc-ref inputs "linux-libre-headers"))) (substitute* "scc/uinput.py" (("/usr/include") (string-append linux-libre-headers "/include"))) #t)))): source expression failed to match any pattern <bricewge>pkill9: You are missing the name of the phase <devtexa>I use this method to build a cluster <rekado>devtexa: we have an early cluster setup that’s terribly slow because the server where the daemon runs accesses /gnu over NFS <rekado>devtexa: is the server that runs the daemon also the one exporting /gnu? <rekado>if so, then there’s little you can do to speed this up other than to make /gnu local to the daemon. <rekado>are you using guix:// as the GUIX_DAEMON_SOCKET or ssh://? <devtexa>My server stores / gnu and / var / guix, then my client mounts them, then sets environment variables, and then the client runs Guix <rekado>since the clients don’t write to /gnu you could experiment with alternatives such as Samba to get /gnu and /var/guix onto the clients. <rekado>if you are lucky and you have pNFS you could try that too <rekado>the problem with NFS is that it’s serial <rekado>if you get Samba to work please share your results with guix-devel@gnu.org <rekado>I’m very interested in seeing performance stats from other cluster deployments <rekado>my plan for the MDC cluster is to use directly attached storage for the daemon server, but I don’t have any plans for the clients yet. <rekado>would be good to know if Samba improves things from the client perspective <guix-vits>pkill9: try as in lirc.scm: (let ((headers (assoc-ref inputs "linux-headers"))) ? <guix-vits>ah, no it's just named differently in inputs <reepca`>pkill9: I don't see any obvious reason, could you post the full definition? <guix-vits>pkill9: typo in inputs: "libre-libre-headers" <guix-vits>while in (assoc-ref inputs "__linux__-libre-headers" *reepca` screams internally about missing that <jas4711>good morning! i have some guix machines exposed to the internet, and wondering what the best practice is to keep them updated in an unattended way? 'guix pull && guix system reconfigure /etc/config.scm && reboot' in a daily cron job leave something to be desired. is there something better? <rekado>i.e. you build the new systems from one machine and push them to the remote servers <guix-vits>jas4711: in other words, install Debian on unattended machines, and disable all but security updates for them :) <jas4711>guix-vits: i was hoping for something else but i guess it hasn't materialized yet. i'll keep hoping! <jas4711>rekado: is there a method to do this unattended, and only when needed (i.e., when there is a security upgrade)? <devtexa>The speed has not improved, the small file reading is still so slow *janneke built first functional: guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl <devtexa>Looking forward to the hurd version of Guix. <raghavgururajan>In procedure scm_lreadr: /home/rg/guix/gnu/packages/pwmt.scm:401:30: end of file in string constant <janneke>do you know what a "string constant" is? <pkill9>ah thanks guix-vits, i need more sleep <janneke>raghavgururajan: it's a literal string, something like: "blah blah" <janneke>raghavgururajan: iow, you have a string that's not closed <pkill9>guix-vits: i'm not going to sleep, i just need it in order to notice typos like that :P <rekado>guix-vits: I don’t understand your recommendation to jas4711 <rekado>jas4711: in Guix there is no channel that only provides security fixes <rekado>devtexa: that’s unfortunate. Thanks for testing. Can you share settings? <rekado>what did you do to measure performance? <rekado>do you see what the bottle neck is? <jas4711>rekado: i am happy to upgrade everything and not only security, but it should be unattended and i don't want to reboot the machine unless required <rekado>if you have more than one server it may make sense to have one machine that manages upgrades, builds the system images and then deploys them to the remote. <devtexa>I just tested a lot of small file reads, samba did not improve anything for nfs <rekado>jas4711: what this won’t do, though, is restart running services, nor will it patch the running kernel <rekado>but it is better than running “guix pull” on every machine. <rekado>you just pull once and share builds <rekado>devtexa: “for nfs” or “compared to nfs”? <devtexa>sorry, my english is not good, i have to use google translate <jas4711>rekado: right. i think that part is critical for what i would like. my test question is 'can i leave this system unattended for 6 months and come back with a security machine?' and i optimize on as few reboots or service restarts as possible. <rekado>devtexa: no worries, just wanted to be sure we’re talking about the same thing :) <rekado>jas4711: I don’t think answering this definitively is possible yet. <jas4711>rekado: great, and you helped me confirm that my knowledge on this is as not far away from the state of the art <rekado>I’m not sure if the kernel in Guix System supports run-time patching (I don’t recall if there were discussions on guix-devel), but I know that for services we avoid restarts upon upgrade. <rekado>because we can’t know if the service may be interrupted during the upgrade <rekado>if you’re okay with restarting services you could do this remotely following a completed “guix deploy” <rekado>but there’s nothing ready-made that you could just enable <jas4711>i wonder how far away from what i want we are though -- 'guix pull && guix system reconfigure /etc/config.scm && reboot' actually achieves what I want but it does not scale well. the first thing would be to avoid the reboort unless necessary. the second would be to restart services <jas4711>rekado: i really want things to be unattended. can i run 'guix deploy' from the same machine? i don't want to add inter-machine dependencies for security <rekado>jas4711: “guix deploy” only really makes sense when you have a “controller” and a herd of servers to be controlled <rekado>you would use that one server to coordinate and apply all updates rather than rely on anything that’s on the target servers <rekado>we’re using this to upgrade the Guix build farm at ci.guix.gnu.org from the head node <jas4711>rekado: what prevents both things from running on the same machine? i'm thinking wether 'guix deploy' is the answer to my unattended-upgrade challenge <rekado>we aren’t reconfiguring the nodes directly. <rekado>well, if you use “guix deploy” on the same machine then it’s really just a more complicated “guix system reconfigure” <rekado>it works but I fail to see the point in using it on the same machine. <jas4711>rekado: okay. then i don't think 'guix deploy' helps with what i want. unless there are plans to add service/kernel restarts through that mechanism? <rekado>I just checked the chat logs: we do have the package providing kexec but there’s no special integration to hot-load the new kernel <rekado>not to restart services is a choice we made <rekado>I suppose we could make that configurable <jas4711>rekado: it could also be provided through some other mechanism. i think a mechanism to find out what has to be restarted for an upgrade to be completed is required to reach my goal <rekado>I think this information might already be available <rekado>I suggest bringing this up on guix-devel@gnu.org to see what we can do here <jas4711>rekado: thanks. willdo. thanks for lunch nudge :) <ecbrown>thanks rekado for fixing up and comming my recent patches. <guixer>Hi Guix! I am trying to configure vpn via network-manager-applet (nm-applet). I also have network-manager-openvpn installed. I get an error "Insufficient privileges" when I try to save the config. Any ideas? <guix-vits>guixer: do you have any DE installed? Maybe the polkit-XYZ is missing. IDK. <guixer>guix-vits: No, I am using i3. polkitd is running as a process. But I can't see a shepherd service for it.. <guix-vits>guixer: idk, but all those applets, when need to do something for what user have a "Insufficient privileges": they pop-up a frame with "Password" field. Gksu, KDEsu... i mean, maybe you need one of that? <guixer>guix-vits: ah. Thanks. Haven't thought about that. I'll try and see if that helps. <bricewge>guixer: network-manager-openvpn should go in a service field if I understand correctly <bricewge>I also have issue with polkit (and this applet in particular too) when using tmux, I never managed to understand where did ti come from though <guixer1>guix-vits: I found a workaround to set up the vpn profile via nm-applet: I unchecked a checkbox which is activated by default. Unchecking the checkbox "All users may connect to this network" did the trick. <guixer1>guix-vits: I assume that one just needs to start nm-applet with superuser privileges in order to set a global vpn/network profile <guixer1>guix-vits: Thanks for the support :) <TZander>rekado: re 40959. indentation of most of the patch is 2 spaces, except for (origin where its 1 space. <TZander>oh, likely I saw an outdated patch with that comment, rekado. Sorry, ignore me. I'm used to something a tad more mature than a fixed-width display of messages where the latest version is at the bottom... ***pie_[bnc] is now known as pie_
<bricewge>TZander: #40782 looks good! I'll push it after #41017 is merged <guix-vits>"/current/legacy-images/" -- the Gods of versioning, lol <OriansJ>guix-vits: it is because this is the last release of ubuntu where they are going to be able to produce a mini-iso image that fits on a mini-cd <OriansJ>with a little work and creativity, we could probably fit on the 60 mm disc <guix-vits>OriansJ: Aren't the Linux Kernel alone is rather to fat for that? <OriansJ>guix-vits: /boot/vmlinuz-4.19.0-6-amd64 => 5,270,768bytes or 5.3MB <OriansJ>/boot/initrd.img-4.19.0-6-amd64 => 30,348,223bytes or 30.3MB <OriansJ>so in theory, depending upon what we want in the inital ram disk, we should be able to squeeze guix on a 50MB 60mm mini-cd <peanutbutterandc>Last night, I'd said here that calibre is unable to open pdf,etc.-readers after a call to `guix gc`; just now I had this thought "maybe xdg-utils isn't defined as an input in the package definition", and I checked, and it seems that xdg-utils is defined only as a (native-input) and not as an (input) <peanutbutterandc>Now, I want to test this out myself before I bother anyone else here. And I have a question - if I put that package definition in another place and load that definition (without changing the package name), which one will guix install install? <raghavgururajan>bricewge Were you using zathura until now? I noticed that plugins are not correctly found. This is in current master. <bricewge>raghavgururajan: Yes. I get “Could not register plugin '/home/bricewge/.guix-profile/lib/zathura/libpdf-mupdf.so'.” from zathura and co being installed in my user profile <raghavgururajan>bricewge When I installed zathura with zathura-pdf-*, and tried to open a pdf file. I got error: could not open plugin directory: /gnu/store/50qw614fyphc6vfsfmxpwkmdgirqqqnq-zathura-0.4.5/lib/zathura <rekado>TZander: I don’t understand your comment about maturity and fixed width. <raghavgururajan>bricewge So regarding #40994, you would like to moving and modifying into separate patches? <TZander>rekado: that refers to issues.guix.gnu.org <rekado>TZander: yeah, what about it? Do you have constructive criticism? <TZander>rekado: there are a LOT of platforms that allow pull requests or similar which have more features than issues.* has. Maybe one of those could be used intead? <TZander>specifically, its hard to read a diff on a fixed-width (i.e. user can't change the amount of chars on a line) page that is essentially a mailinglist archive. <civodul>TZander: you are right, but please realize that people on this project have been discussing this for a long time <civodul>the current situation is the result of that <TZander>I assumed as much, which is why I didn't go and write a lot of text at first just referred to the source of my confusion :) <civodul>what we'd really like to see are proposals that start from current community consensus <civodul>TZander: understood, but please make sure to convert your frustration into concrete proposals :-) <TZander>well, a relatively simple addition would be (for patches) to have a sparate section on the page that lists all attachments. Grouped by filename, sorted by most-recent-first. <civodul>often i don't know what to do with comments of the form "X sucks", or "why don't you do Y, it's so much better" <TZander>personally I'd argue that using one of the various existing merge-request platfoms isn't equal to tabula raza... <TZander>anyway, another suggestion that is probably quiet easy to do is that patches already are recognized and have green/red backgrounds. But the fixed width means many lines are split and that makes it hard to read still. <bricewge>raghavgururajan Yes take inspiration from the commit I mentioned or look for others of the same kind in the log <civodul>TZander: it's tabula raza in the sense that it ignores what dozens of people here have discussed and built <civodul>of course you can contribute to that discussion <civodul>but make sure to start from where we are <civodul>TZander: as for the layout of patches, i agree that it's annoying, but for me the next step would be to come up with a patch <civodul>sometimes i'm hopeful someone else will fix it :-), but i'm not in a position to require it from anyone <TZander>I don't want to get sucked into that deep-end ;) This started because I wanted to contribute to proof-reading a contribution and stopping when I felt the platform was missing all the innovations of the web of the last 15 years. <civodul>yes, and again, not as constructive as we'd like <civodul>in the end it's a personal choice, i don't have much to add <guix-vits>OriansJ: `du -hs /run/current-system/kernel/lib/modules/5.4.31-gnu/` -- surprisingly only 22MB. Probably those already in initrd. I'm used to 200MB there. <TZander>civodul: I apologise if that sounds too harsh. I'm not a web-dev, I won't be able to help improve the situation with patches. <TZander>civodul: nice post. I guess if the requirement to contribute is that one uses email (and not issues.guix.gnu.org) that is a valid answer. It was lost on me that issues.* was not uses as a platform. <cbaines>TZander, fixed width display of text is usually a good thing for webpages, as it maintains redability across different screen sizes <civodul>TZander: as you know, issues. is meant as an additional interface for people who don't use email or Emacs <civodul>it's not perfect, you've said it repeatedly <civodul>mbakke: solution #2 mentioned there is implemented, so it's less bad than it was, but still not great <TZander>cbaines: yeah, the issue is that even 80 columns-respecting patches can get cut into multiple lines.. Maybe another 10% width is a good enough solution. <str1ngs>cbaines: patchwork looks interesting. :) <cbaines>str1ngs, funnily enough, I wasn't very interested in it's looks (or the web interface), I was more interested in getting some more machine readable representation of the patches <mbakke>'git rerere' is a curse and a blessing <cbaines>is this for trying to work with core-updates? <mbakke>cbaines: I only recently learned about it, it lets you save merge resolutions. <mbakke>very useful if you need to abort a difficult merge and do it again later <mbakke>I've enabled it by default, but it can be difficult to "un-do" if it has recorded something wrong <mbakke>I also need to "git add" all the files it automatically merges manually, and feel kind of uneasy without seeing the conflict markers! ***PotentialUser-84 is now known as xiorcale
<mbakke>but it works well enough that it's worth it -- no wonder it's disabled by default though *mbakke does a core-updates merge and will be AFK for a good 24 hours ... please test core-updates meanwhile, let's merge it within the next few days! <mbakke>The WebKitGTK sandbox issue should be solved first though, and some users reported distorted icons. <mbakke>wrt the latter, I suspect we may have to start using 'librsvg-next' for x86_64 and leave icons broken on other arches for a while :-/ <lhp22>Hi there ! I've just installed GuixSD on a virtual machine (virtual box, on windows). And I get some strange things. I've run `guix pull` and I get the hint ` <lhp22>check your shell is shell is the good one (on the GuixSD, it suprises me getting this). And after I want to do `guix update` but guix says to me I must run `guix pull` before ?! That I've just done ... Oo <raingloom>i see that others were talking about ISO size. i've been expermenting with installing Guix on an old Pentium II machine with a 4 gig hard drive. it does take a surprisingly large amount of space. <lhp22>on my vm : 2Go without graphical interface <raingloom>i accidentally used %desktop-packages instead of %base-packages, but there isn't enough space to reconfigure :( <raingloom>(i left 200M for swap, because it doesn't have much RAM either) <cbaines>lhp22, well I'm glad that it sounds like Guix is working <lhp22>The guix pull has pull many packages, and I can't update ? <cbaines>I though you were just getting some informational output <lhp22>cbaines The first git pull has taken 10 minutes (about) to perform, I couldn't do `guix update`, and I've done `guix pull` again, and guix repulls all <lhp22>Just from guix update, which tells me I have to do a `guix pull` before an update <lhp22>I can update the message from guix package -u <cbaines>I'm not sure there is a guix update command? Do you mean guix upgrade? <lhp22>and same output from guix upgrade and guix package -u, but if i've well understood, guix upgrade is just an alias, so not suprising <cbaines>Can you provide the exact message you're getting from guix upgrade? <lhp22>when guix pull will finish yes <lhp22>(i've launched a second before thinking come here) <lhp22>So, the second guix pull doesn't output the hint about shell anymore (i've done nothing about this, except cheking with echo $SHELL it was the good one), and guix upgrade gives <lhp22>guix upgrade: warning: Consider running 'guix pull' followed by guix package u to get up-to-date packages and security updates <lhp22>And guix pull really tells me there are news <lafrenierejm>When building current guix master (afc57916e5398737e13d94b3823983783221eb63), I'm getting an error: <lafrenierejm>ice-9/eval.scm:293:34: In procedure abi-check: #<record-type <operating-system>>: record ABI mismatch; recompilation needed <lhp22>cbaines Should I send a mail to bug-guix@gnu ? <cbaines>Thanks for getting the exact message, I think I've seen this as well <lhp22>I'll join all the log I get :) <TZander>lafrenierejm: incremental compile? Try recompiling <cbaines>lafrenierejm, are you using a Git checkout? <cbaines>lafrenierejm, there's make clean-go which just removes the .go files. For issues like this, you can often just delete the relevant .go files *TZander doing an upgrade, lets see if that helps <civodul>TZander: we'd need to see the command you're running <civodul>it could be grafts, though normally these are printed differently <civodul>lafrenierejm: the ABI mismatch error means that the layout of the <operating-system> record was changed, hence the need to recompile *mbakke really goes AFK now :P <OriansJ>ok looks like the default guix build environent doesn't support which <TZander>OriansJ: I've been ignoring that warning without problems <leth>is there a way to define kernel module options in the system configuration? <raghavgururajan>bricewge I have sent a new patch-set for moving stuffs. They should be trivial. I will be sending another patch-set for modifying stuffs. :-) *raghavgururajan ---> zzZ <leth>lafrenierejm: I want to pass an option to one of the modules. <leth>well I guess i could stick it in the kernel parameter. But that think could easily get long. it's jsut a string of course so one can always build that string however one wants. <lafrenierejm>civodul: Can you expand on that? I hadn't changed anything in my system config prior to the build failing. It's not an issue at all, just hoping to better understand. <sisisix>What storage method does your cluster use? Nfs? <sisisix>I am disappointed with the speed with which nfs reads a lot of small files。 <rekado>OriansJ: you need to add “which” to use “which”. <rekado>sisisix: we use NFS too but it’s not great. <sisisix>So someone used iscsi on the guix cluster? I checked the information and found that iscsi may be suitable for cluster file sharing <TZander>rekado: would it be possible to fix the 'which' issue somehow? I mean, I don't need to add 'ls'... <civodul>lafrenierejm: presumably you pulled changes that added a field to <operating-system> or something like that <civodul>TZander: please send a patch or post a proposal to the list; don't expect rekado or anyone else to just do what you want <civodul>nobody here is working "for" someone else, we're working together <TZander>civodul: I lost you, what is this about? <civodul>about "rekado: would it be possible to fix" <TZander>I think you may have read that differently than it was meant. <ryanprior>TZander: some people do act quite entitled to free software volunteers' time so it can be easy to read some messages that way when you've seen it in the past. :) <TZander>i've got various patches in guix already ;) <civodul>i don't think we need to put any more pressure, willingly or not, on rekado or anyone else *civodul goes afk for a bit <TZander>so, the thought that struck me is that on 'guix environment' you get default set of things included. `ls` being a good example. So when 'which' is missing, would a patch to add which to the base-set be a way to solve it? <TZander>maybe I'm misunderstanding it. In that case, ignore me :) <ryanprior>How can you see what things are part of the base-set? <cbaines>I don't think a "default set" or "base-set" exists <cbaines>enter a pure environment with just guix <ryanprior>I figured there's probably not much in the `glib` package so I tried doing `guix environment --pure --ad-hoc glib` and it has ls & which <cbaines>then enter an environment containing which <TZander>makes me curious, how come that ls is present when you use the 'guix' argument? Some dependency in the tree, perhaps? <ryanprior>Hmm there's something else going on here, if I add my guix profile to my PATH in my bashrc, does that get sucked in when I do `guix environment --pure`? <cbaines>TZander, seems to be in my system profile: /run/current-system/profile/bin/ls <cbaines>I haven't got it installed in my user profile <ryanprior>When I do `guix environment --pure --ad-hoc which -- ls` then it says "no such file" but if I run `guix environment --pure --ad-hoc which` to get an interactive shell and then run `ls` it works <cbaines>There is such a thing as %base-packages, defined in (gnu system) <cbaines>and I'm using %base-packages for the packages in my system, hence I have coreutils which contains ls <TZander>oh, this is curious. 'guix environment' just doesn't have /bin in the PATH <cbaines>Well, depending on whether you pass --pure, it either extends the $PATH, or replaces it <ryanprior>Running `guix environment --pure --container` gives me an actual pure environment, just running `--pure` doesn't, possibly because it's loading my bashrc or my bash_profile which loads my bashrc. <ryanprior>println debugging reveals that it is indeed reading my bashrc (but not my bash_profile) which immediately pollutes the pure environment. <cbaines>It doesn't load your .bashrc, but because it's start bash, bash loads your .bashrc <ryanprior>A distinction without a difference in my case <cbaines>guix environment is one of the things where it can matter whether you put something in .bash_profile or .bashrc <ryanprior>I'm looking into whether there's some way I can detect in my bashrc that we're in a pure environment and bail before doing the normal setup <cbaines>What's in your .bashrc that you sometimes don't want to happen? <cbaines>That should be in your .bash_profile, not your .bashrc <cbaines>As it's not something you want to necessarily take effect in every shell <ryanprior>I didn't document this so I don't know, but I recall in the past having issues with that related to emacs shells not being able to find my guix binaries because it didn't load my bash_profile <ryanprior>So I'll try moving that back to my bash_profile and look out for issues in emacs, and if necessary find some way to force emacs shells to load my bash profile <mroh>maybe try testing if $GUIX_ENVIRONMENT is set <cbaines>If you do have specific issues with Emacs, you can always try the usual channels for help. I'm sure there's some overlap between people who know Emacs and Guix <sisisix>I think I still have to abandon the Guix cluster. Compared to nfs, I still take the program Guix pack and send it to the client. <sisisix>I checked a lot of information, and then I came to a conclusion that there is no solution to the file system that reads a lot of small files :( <cbaines>sisisix, is it particular operations that are requiring lots of small files to be read? <cbaines>I had similar experiences when trying to use EFS (hosted NFS) on AWS with Guix <sisisix>Many small files are needed to start guix <TZander>sisisix: This is an inherent issue with any network-stack. You open a file which sends a request to the server and a reply comes back. That is slooooow compared to local disk. (10 to 100 times as slow) <cbaines>and out of interest, why were you trying to run Guix with NFS? (I'm not suggesting it's a bad idea, I'm wondering what application you had?) <cbaines>I think this is an interesting area, because the immutable nature of the store should lend this to working performantly over the network <cbaines>as anytime a store item is accessed, you could send over all the metadata regarding all the files in that store item, and cache that on the client <cbaines>you could also cache the data in the files themselves. <sisisix>I saw a blog about guix cluster in hpc.guix. Then I tried to run it. This performance is too bad <cbaines>if it had worked, what were you going to use it for? <sisisix>Prior to this, I used guix pack to package the application, and then sent to each client <TZander>and that didn't give you what you wanted? <sisisix>，The guix pack is enough, I just want to try a new solution, but this solution is obviously not as good as the guix pack ;-( <cbaines>sisisix, I still don't know much about your use case, but using guix publish and substitutes might work <OriansJ>rekado: odd that which isn't included in the shell <cbaines>How would one include which in a shell? <cbaines>Bash at least already includes support for that functionality, via commands like type -p <cbaines>Whereas which is a standalone executable, specifically separate from a shell <OriansJ>cbaines: yes but I would like mescc-tools and M2-Planet to build on systems that use alternate shells such as dash or gash <cbaines>I missed the earlier parts of this discussion, so I'm lost on a bit of the context <cbaines>I don't know much about dash or gash, and I'm not sure if they have a which builtin <OriansJ>just me attempting to update my guix script for the build of mescc-tools and M2-Planet. So that the tests run on all of the BSDs and other POSIX systems which might not have sha256sum (which is only used on the optional tests) <cbaines>If this is an issue about depending on which at build time for the Guix package of mescc-tools and M2-Planet, that shouldn't be an issue, which is an input to a few packages <OriansJ>well mescc-tools and M2-Planet are going to be at the roots of trust for all guix binaries <OriansJ>as they are the roots that are going to bootstrap guile and MesCC <OriansJ>I can even tell you the exact checksums of the binaries prior to the build <cbaines>I'm no expert, but using which shouldn't be a big problem, especially if it's just used to decide which tests to run <OriansJ>So I need a way in guix to checksum the binaries and that is it <cbaines>However, if that's the use case, maybe just trying to run sha256sum and seeing if it works is a simple, dependency free way to check <OriansJ>which I then can just encode in the guix script and ignore the standard tests entirely <ryanprior>Do we remove packages which are out of support and don't get security patches? eg Ruby 2.3 was in "security maintenence phase" until March 2019 but is no longer getting security patches - do keep packaging it? <cbaines>ryanprior, the packages for Ruby (MRI) are more out of date than I'd like <cbaines>core-updates has 2.6, but of course 2.7 is the current release <ryanprior>I'm working on updating MRI right now which is why I'm asking :) <cbaines>that would be nice for the next core-updates cycle <ryanprior>Okay cool I won't worry about doing that then <cbaines>but it would also be nice to have a package for 2.7 <cbaines>maybe that could be added without making it the default Ruby (and thus without require rebuilding all the things that use Ruby) <ryanprior>I will create two patches, one that adds 2.7, and another that makes "ruby" track 2.7 <ryanprior>That way yall can handle that roll out according to whatevr process <ryanprior>Different Ruby versions need different files to be patched, so I'm thinking about defining some helper functions to avoid repeating lots of common config in each package. Is that looked down upon or is that the point of having these mcdubjobbins be scheme files anyway? <TZander>so, I'm looking at a package (kparts) that has "propagated-inputs" in its build. Specifically with 'kio'. What confuses me is that while kio is in the build-space, the dependencies of kio are not. Whats the point of propagated-inputs ? <lafrenierejm>Anyone available to help me understand `substitue-keyword-arguments'? I'm trying to figure out how to override both #:configure-flags and #:test-target for a new sqlite variant in gnu/packages/sqlite.scm. ***ChanServ sets mode: -o lfam
<lfam>TZander: Propagated inputs are installed into your profile along with the package that propagates them. It's for languages and tools that don't keep references to run-time dependencies <TZander>ok, for your profile. Is that relevant for the build environment? <TZander>Hmm... I'm trying this and it looks like using 'kio' as an input of 'kparts' doesn't make all dependencies of 'kio' implicitly also dependencies. <lfam>No, it's treated the same as plain inputs in the build environment <TZander>I must be missing something obvious why this compile is failing <TZander>but this explosion of the dependency tree is all over the KDE file.. khtml lists kparts as dependencies, and then lists lots of kparts depencies again. Why would you not have recursive dependencies? <cbaines>kio does propagate a number of packages, so I'd expect them to be available in the "environment" of builds where kio is an input <pinoaffe>TZander: I don't quite get what you're saying, but if package X has package Y as an input, then Y should be available at build-time of X, and all propagated inputs of Y should also be available at build-time of X, but regular inputs and native inputs are not necessarily directly accessible to X <TZander>ahh, thanks guys! Quarter fell. right, dependencies propagate. <TZander>ok, all I need to do is move one package to be in the propagated-inputs instead of in inputs <pinoaffe>please only list packages as propagated-inputs if the program you're packaging requires that, aka if it does a lookup for its dependencies at runtime <rekado>sisisix: iscsi is for sharing raw disks, not for sharing the file systems on top, so it would not be surprising to have inconsistent state across different machines reading the same disks when another machine writes to them. <rekado>sisisix: I did consider iscsi before, but this lack of consistency guarantees means that iscsi probably isn’t the right mechanism here. <rekado>an alternative is a cluster file system, but they usually aren’t very performant. <rekado>Guix on a cluster is a pretty special case (one client writes, all others read), which should be easy to optimize for if only you could tell your cluster file system that this is what you want. <lfam>What is 'in-vicinity', as used in a handful of Shepherd services? <lfam>AFAICT, it's not defined in Guix, and not mentioned in the Guile procedure index <cbaines>The Guile procedure index doesn't mention all the available procedures <lfam>Appears to be part of SRFI-59 <lfam>Seems to be some kind of file location abstraction <mwette>in-vicinity is defined in core Guile (ice-9 boot). I think it just joins a path with a filename using path separateor. (in-vicinity "a/b/c" "d.x") => "a/b/c/d.x") <mwette>It looks like it reads nothing from the environment or file system, except the path separator. <mwette>(in-vicinity "a/b/c/" "d.x") => "a/b/c/d.x" <lfam>Does anyone have a basic Nginx web server config.scm I could use to test changes to the Nginx service? <cbaines>Is this a kind of test you could use the NGinx system test to perform? <lfam>I'm adding a reload action cbaines <lfam>So, I think I'd also have to update the system test <lfam>But for now I'd like to just try `herd reload nginx` by hand <lfam>I'll try to copy the example from the manual. That's the best way <cbaines>I'm not quite sure what a minimal configuration would look like, but the nginx-configuration used by the system test is quite minimal <lafrenierejm>Given that I'm including tcl as a input in a recipe, how would I go about finding its corresponding lib directory? <cbaines>There are ways of accessing the filename for inputs <cbaines>Is this in a phase, or a different argument? <lafrenierejm>Actually, not. It will be passed as TCLLIBDIR in #:configure-flags. <cbaines>Ok, you should be able to find some examples where #:configure-flags is used with code like (assoc-ref %build-inputs "...") <lafrenierejm>Is there a convenient way to skip tests when `guix build`ing something? <rekado>disabling the tests would lead to a different derivation <cbaines>Adding #:tests? #f to the package arguments will work for most build systems <lafrenierejm>rekado: Ah. I was wondering why there wasn't a flag for `--build`, but that makes sense. Right now I'm just wanting to iterate quickly on a recipe, so cbaines suggestion is sufficient. Thanks all. <Guixguy>Hey all, I'm trying to load sdl2 in quicklisp on emacs. I am getting <Guixguy>"Unable to load any of the alternatives: <Guixguy> ("libSDL2-2.0.so.0" "libSDL2.so.0.2" "libSDL2") <Guixguy> [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR]" <Guixguy>Does anyone know what guix package would provide that for me? I currently have: "sdl2" "sdl2-gfx" "sdl2-image" "sdl2-mixer" "sdl2-net" "sdl2-ttf" installed <pkill9>anyone know what could be causing this error?: /gnu/store/izwfd04xdkcl8kl6x8j8b9nyq9w5wnkv-python2-pygobject-3.28.3/lib/python2.7/site-packages/gi/module.py:177: Warning: cannot register existing type 'RsvgHandle' <pkill9>that is admittedly oddly specific wihtout any context <pinoaffe>mbakke: did you ever get i3lock to work? for me, it doesnae allow me to unlock even when I enter the correct password <cbaines>lafrenierejm, I'm not sure substitute-keyword-arguments will add #:tests? if it's not present in the arguments it's substituting <cbaines>so you can just add it on somewhere, or use the default-keyword-arguments procedure if you like <lafrenierejm>cbaines: Noted. Thanks for calling that out. Even after removing #:tests? entirely, though, check is still being run. 