<roptat>when texlive is grafting, my computer freezes, but I always have plenty of RAM free <nckx>rekado_: Left ncdu -qx /gnu/store running while I was out. It's at 470 GiB and still counting hard. Explains where that terabyte went! <nckx>NieDzejkob: It could be ‘memory’-related in that your cache is filled with gigabytes of useless data. Guix could use something like fadvise to say ‘I'll won't be re-reading this stuff; throw it away’, assuming that's true. <hendursaga>rekado_: Quicklisp still won't recognize it, sadly, even though libssl.so is there :/ <jgart[m]><str1ngs "jgart: but you need to do more t"> Thank you for sharing the example. What is the other work that I need to do to get it to work? <jgart[m]>I'll share my test.scm since I feel the bug might be in what I am trying to load: <jgart[m]>I just have a simple test procedure in test.scm but I haven't declared it as a module at the head of the file <jgart[m]>str1ngs: sorry ignore the above posts. I think I overlooked something. I'll post again in a bit. <str1ngs>jgart[m]: okay, it might be better to post in #guile they might now how to make a meta command. <str1ngs>hello vits-test and what have you done to guix-vits? <vits-test>str1ngs: It was i, who forget how to set-up a .authinfo.gpg.. <jgart[m]><str1ngs "jgart: okay, it might be better "> Ok, will do <vits-test>on Guix, in man ls, ls --color: "'always' (default if omitted)," .. "Using color to distinguish file types is _disabled_ both by default". <vits-test>str1ngs: Why in nomad it's named (M-x) terminal instead of "shell"? <alchemi>been doing my first guix package install since last night. mes-boot is taking a while on an M1 invocation (I guess because it's building up a trusted reproducable chain of compilers) but that's okay I'm excited :) <cheim0>Is the X.509 certificate expired for ci.guix.gnu.org or is it just me? I haven't seen X.509 explicitly mentioned by name in the irc logs or guix issues <cheim0>copied from a few seconds ago, and that seems to be my time zone .... Sun Aug 30 17:06:17 PDT 2020 ***catonano_ is now known as catonano
<vits-test>cheim0: IDK about certificate then, but some people had troubles yesterday. <vits-test>cheim0: also see the "*** Topic for #guix: GNU Guix ⚠️ the CI is being repaired " <nckx>Thanks for the reminder, that can be removed now. <nckx>First let's renew them sweet certs. ***ChanServ sets mode: +o nckx
***nckx changes topic to 'GNU Guix | get Guix at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org | 1.1.0 is out! https://guix.gnu.org/blog/2020/gnu-guix-1.1.0-released/'
***ChanServ sets mode: -o nckx
<nckx>Das Topik ist gefixt; jetzt noch die Zertz. <nckx>Hullo vits-test. Why are you sorry today? <cheim0>vits-test: no worries, asking about system clock is a good precaution <nckx>+1 I did not see any misinfo. Wrong dates are suprisingly common. <nckx>cheim0: And thank you for the report! <roptat>sneek, later tell civodul guix is merged in osinfo-db :) <drgibbon>Is Guix a rolling distribution? If running Guix as a distro, is there any distinction between upgrading to the latest release of packages, and upgrading to a new OS release (say 1.0.0 to 1.1.0)? <nckx>drgibbon: It is entirely rolling, releases are simply (better-tested) snapshots. There's no difference. <drgibbon>I see, and how are upgrades to system config files handled? E.g., if a new version of openssh is installed, what would happen to a customized /etc/sshd/sshd_config ? <nckx>We certainly don't recommend staying on a release *after* installation. It's downright dangerous; there is no stable branch to which security fixes are backported. <drgibbon>right, so the idea to keep your system up to date is `guix pull`? <vits-test>drgibbon: most progs use something like /gnu/store/hash-sshd_config (that was declared by user). <nckx>drgibbon: On Guix System, you configure services (including openssh) through a Scheme file which contains your entire configuration. You then run (say) ‘guix system reconfigure /etc/guix/system.scm’ to apply that configuration. You wouldn't generally touch files in /etc yourself, although in practice, things not yet handled by Guix are. <nckx>drgibbon: ‘$ guix pull’ (similar to apt update) and ‘$ sudo guix system reconfigure’ (update the system) + ‘$ guix package -u’ (update user packages). <drgibbon>ok interesting, I'm on Slackware at present, testing guix as a package manager (I installed from binary and did a `guix pull`, it's currently building gcc). <drgibbon>but interested perhaps to try it as a distro. <nckx>That's fine, if you are a good reader 🙂 <str1ngs>vits-test: shell is not quite like emacs shell. emacs shell is an actual buffer <nckx>For some reason some people think that's a good chapter to ‘skim’. It is not. <drgibbon>nckx: no problem, Slackware people generally know how to read ;) <drgibbon>I mean, read instructions carefully and follow them. <str1ngs>vits-test: so it's name terminal. till we can make a proper shel <nckx>Slackware 3 was my first-ever Linux distro and will always have a special place on my ♥drive. <drgibbon>nckx: cool, yeah I'm looking around for a nicer set of build tools really, guix looks very interesting, but quite a learning curve since many things are different. <str1ngs>vits-test: btw I have a much improved nomad declaration for guix will be mailing a patch soon. will be on par with nomad-git now. <vits-test>str1ngs: Thanks. BTW, is it's possible to make M-x nomad-git to user semi-automatically switch to git version? <drgibbon>One thing I don't understand yet is this distinction between root and user profiles. What is the purpose of this for a single-user machine? <lfam>drgibbon. No real purpose for that use case. <lfam>It's designed as a multi-user system <raghavgururajan>Who are all have admi/moderator previleges in this #guix IRC channel? <vits-test>drgibbon: On single-user machine (on System): user$ guix pull; sudo guix system reconfigure CONFIG <lfam>You can effectively use the unprivileged single-user's profile for the system-level stuff by doing e.g. `sudo --preserve-env guix system reconfigure /etc/config.scm`, which the --preserve-env being the important part <vits-test>* --preserve-env should be default in Guix System. <drgibbon>hmm, I need to learn more about this to be able to make sense of it, but is normal practice then to do everything with unprivilged user? <lfam>raghavgururajan: I have op privileges here <lfam>drgibbon: It really depend on if you want to use the root user or not <lfam>There is a certain class of software for which it's more convenient <raghavgururajan>lfam: I see. Would like to know who are all, if anyone of you have a list. *nckx looks around suspiciously looking for someone to kick. <lfam>A lot of administrative tools for Linux expect privileges. One could use `sudo`, or just work as root <nckx>That's bizarre. I was just thinking about that 10 minutes ago. <nckx>Something like !op in other channels. <lfam>I don't know who else has powers in this channel. I would guess the maintainers and maybe some other old-school peopple <drgibbon>ok thanks, well I probably need to jump in and test it a bit more. <nckx>raghavgururajan: /msg chanserv access #guix list ***ChanServ sets mode: +o lfam
***ChanServ sets mode: -o lfam
<nckx>raghavgururajan: Everyone with the ‘o’ bit set (which in everyone in that list I think). <nckx>Sigyn is an anti-spam bot I sometimes invite in, so she may kick people too. <nckx>vits-test: Just in case: we don't have any bot that listens to !foo ‘commands’. Sneek doesn't. <nckx>snackbot sneek: botsnack? <raghavgururajan>nckx: I have a surprise for #guix channel. Planning to bring a bot. Let see how it goes? <vits-test>Programs should be explicitly told what to do! Yeah. <nckx>raghavgururajan: Hum. OK. Interesting 🙂 What kind of bot is this? <nckx>Just so you know, #freenode appreciates being told which accounts are bots. <nckx>Before you trigger their spam-detection AI™. <nckx>(...which is basically war of the bots, which is disturbing.) <vits-test>sneek "we come in peace" means "surrender now" <vits-test>raghavgururajan: It works for food. Dont tell it about the lawyers. <rekado>the logs in /var/log/nginx now only take up ~8G instead of ~80G <nckx>ncdu /gnu/store is at 1.5 TiB 😛 *nckx forgot about deduplication. <drgibbon>whoa, so how much disk space will I need to run guix? <nckx>drgibbon: No, this is about the build farm, which is GC'd as little as possible (I believe the storage available for /gnu is currently 37T 😉) to keep substitutes available for as long as we can. <hendursaga>rekado: Good news, I gave up and realized that there is sbcl-drakma in the repos.. <nckx>In this case, however, /gnu/store is a weird implementation detail (not the ‘real store’ which is bind-mounted from elsewhere) and probably just a forgotten directory that can be deleted. <rekado>nckx: wny /gnu/store, not /mnt/root-fs/gnu/store? <nckx>Computers are weird when you can ‘forget’ about a ~1 TiB directory. <nckx>rekado: I mean the latter. *nckx finally remembers the word ‘underlying’ and is still not sure if that's what they mean. It's late. <rekado>I’m sure it’s big. We were around 90% disk usage when the external storage array became usable. <rekado>later we also migrated the caches to the storage array <nckx>drgibbon: Anyway, Guix also does basic deduplication using hard links, so even if you had 1.5 TiB of data in /gnu/store, a lot of it would probably be redundant (many different versions of the same package with many identical files between them) and only stored once. <nckx>I see free space is at 137G now (nice!) so that lowers the bound. Probably more like half, instead of almost, a terabyte. <ul22>I've been getting a SHA256 hash mismatch when I try to install racket-minimal. Is this a problem with the package, or is there something I can do on my end to fix this? Tried guix pull to no effect. <brendyyn>ul22: It's not your issue. It means the upstream racket release has changed unexpectedly <roptat>the expected version doesn't seem to be in ci's cache <brendyyn>ul22: Actually, it looks like a mistake was made. The racket package was updated without updating racket-minimal as well. <brendyyn>judging by the logs, this happened last time too. <roptat>brendyyn, in that patch, add a comment to racket so we don't forget about it next time <brendyyn>ill have to see if the patches apply and it builds first <drgibbon>what does `guix pull` do on a non-guix distro? I freshly installed guix package manager, did guix pull... and it's building a lot of stuff (might be from the `guix install hello` that I started and then aborted?) <brendyyn>it does the same thing it does on guix sd. it builds the latest version of guix its self <roptat>drgibbon, did you allow substitutes? if not, that's why it's building lots of stuff, normally it would just download pre-built substitutes <roptat>(since I remember you used the manual installation method, maybe you overlooked that part of the installation procedure? or maybe you didn't allow substitutes on purpose) <alchemi>is it ordinary for the mes-boot package to take a super long time to build on a system with 1G of ram? <ul22>brendyyn: thanks, bug diagnosis is beyond me <brendyyn>ul22: The reason was that the package definition for racket-minimal inherits from racket, so when racket's version was updated t 7.8, so was racket-minimals, but the updater forgot about that. <roptat>brendyyn, ul22, pushed. You can now run "guix pull" and racket-minimal will build <brendyyn>ul22: Julien just submitted the patch. you can run guix pull; guix install racket-minimal <roptat>(Julien = roptat in case you're wondering :)) <brendyyn>pretty good customer service here at #guix <drgibbon>roptat: ahh, I didn't change any settings, I'll look into substituions then. <drgibbon>roptat: yes I was thinking to build everything from source, but I didn't grasp how the whole thing works, I thought I could just install packages one by one, and it would use my local gcc or whatever. <Noclip>Haha, I think I solved the mystery of my broken guix: Looks like my original assumtion of a corrupt store is totally right: <Noclip>"path `/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31' disappeared, but it still has valid referrers!" <Noclip>I already assumed that it had something todo with glibc as basically everything related to guix was totally broken and glibc is the one package that is needed by everything ... <drgibbon>roptat: much faster with substitutes, thanks :) Is there a way to see all substitutes? <Noclip>Everything else in the store seems fine. How the hell is it possible that glibc just disappeared from my store? <ul22>brendynn, roptat: successfully built racket-minimal, thanks again <drgibbon>just curious, on a new install after running `guix pull` everything was OK, tested `guix pull` again and it says: "Authenticating channel 'guix', commits 9edb3f6 to a2ebc74 (5,153 new commits)..." <apteryx>drgibbon: Guix 1.1.0 lacked that authentication mechanism. Your updated Guix from the first 'guix pull' learned how to do this, so it had to authenticate from start. *raghavgururajan is on patrol and there is a racoon staring at him <brendyyn>... looks like BUILD_STATIC is the answer <brendyyn>ahh.. i think the phase 'delete-static-library is looking quite suspicious <efraim>How many dependants does it have? We can move the static library to a separate output instead <brendyyn>efraim: yep thats what i did. its what the zlib package does so i copied it <brendyyn>yeah. is that really a binary containing all the dependencies it needs? <efraim>well, it's a fairly small package, and I'm guessing much of the speed is due to linking to what it needs from glibc <brendyyn>I'm updating chez scheme. i was wondering why it includes both zlib and zlib:static <brendyyn>i guess it can build packages that use either? <efraim>check zlib:static, I'm assuming it doesn't contain the headers <efraim>so yeah, it probably needs regular zlib for the headers <Gooberpatrol66>How do I completely remove a package so it will be forced to build again when I install it? <rndd>hi everyone! did anybody try exwm + xfce in guix? <brendyyn>Gooberpatrol66: I think you can do something like guix gc $(guix build foo) <rndd>Gooberpatrol66: guix remove package && guix gc && guix install package --no-substitutes <janneke>rndd: what would you use from xfce? i'm using exwm + some gnome utils (gnome-terminal, evince, ...) <rndd>janneke: i just found info about this possible combination and wanted to try it =) <rndd>when i'm trying to init exwm in xfce session, i got error in process filter: xcb:-connection-setup-filter: [XELB] Connection failed: No protocol specified <rndd>janneke: thank you, all needed to do is "xhost +" <rekado>I’m going to reboot ci.guix.gnu.org in a few minutes <g_bor[m]>I have received a message from Outreachy that the community sign up for the winter round is by mid September. <g_bor[m]>civodul told me that we should sicuss if we want to participate. <g_bor[m]>For the community sign up I only need that we are willing to approve funding for intern, is we decide to accept one. <rekado>g_bor[m]: I just replied to your mail ***rEnr3n6 is now known as rEnr3n
<rekado>hmm, as before, the latest generation does not seem to boot <rekado>I’ll give it some more time, but if it doesn’t work I’ll have to boot an old generation. <Kimapr[m]>Hello, i installed a few fonts in my profile, but they don't show up in any application where i can choose a font <Kimapr[m]>Even after restart and even if i add them to 'packages' of my system config <g_bor[m]>is's just somehow my mail client did not pick it up :) <g_bor[m]>I will go ahead then and file the community singup. This is not an obligation to do anything further, so I think it's fine. <g_bor[m]>Then I plan to write a call for mentors e-mail. <rekado>hmm, can’t type on the serial console :-/ <rekado>rebooting into an older generation <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, roptat says: guix is merged in osinfo-db :) <civodul>think of the millions of GNOME Boxes users who'll click on "Guix" <brendyyn>One day Ubuntu will replace all their Snaps with Guix packs and we'll all be burned at the stake. <civodul>"guix time-machine -- build emacs-guix" passes, woot! <brendyyn>so time-machine without an argument builds with the same guix, but the built package still has a different output hash? <civodul>time-machine without an argument builds and runs the latest guix <efraim>phase `build' succeeded after 97141.8 seconds <brendyyn>somehow i broke chez so hard even #t isn't bound <efraim>guile-2.2 on mips64el, from 0.14.0 <vits-test>efraim: Since this board is 1GB RAM, probably You know how to run Emacs in framebuffer, on tty: but with images working? <vits-test>links -g works, but Emacs has no images.. That's pity. <efraim>I don't use emacs and I've been having a suprisingly harder time building native debian packages than I do on ppc, or with using pkgsrc, so I've been letting it work on re-bootstrapping guix using previous versions of guix <efraim>If it does work out I'll probably just try to create an image to flash to a HDD <PurpleSym>I’m trying to get our SSSD package into shape. Is there any way to tell glibc to look for libnss_sss.so in a different path built in already? It must work somehow for mdns, right? *raghavgururajan experienced weired system-wide crash in guix system, reported as #43132 <efraim>raghavgururajan: looks like you're out of space or out of inodes <efraim>raghavgururajan: what about inodes? 'df -i' *vits-test maked his / with -i 4096. Me clever boy. <efraim>I'm not sure how it lists you as having 0 inodes total. what about for some of the mounted filesystems? <vits-test>raghavgururajan: What FS it is? Maybe it's btrfs or so (maybe they just don't report those things. <vits-test>(last time i'd read about, btrfs increaseas a number assigned to every new inode. And do not reassigns the old numbers. But biggest number is just too big.) <vits-test>raghavgururajan: btrfs check (avoid --repair, as it's dangerous)? <efraim>how about a balance to try to clear up some space <efraim>sudo btrfs balance start -dusage-50 -musage=50 / <efraim>can probably leave off the musage one <efraim>raghavgururajan: it should compact some of the more empty segments and free up some of the free space <raghavgururajan>I see. But was this the cause of the issue? Not sure why guix build daemon misbehaved <efraim>it could explain all the out of space issues <raghavgururajan>I see. I use to get out of space error time-to-time. But all will be fine after I delete some files or gc. But the other errors were so weird. <PurpleSym>civodul: Thanks, I’m trying to get sssd running on GuixSD though, i.e. upgrading to 2.3.1 and writing services. I think I might need to use nscd-configuration’s name-services parameter. <leoprikler>Auf der CI bauen zur Zeit Pakete basierend auf emacs-minimal, bei denen scheint aber kein Fehler aufzutreten. <leoprikler>Ob das für emacs selbst mit allen Abhängigkeiten gilt, weiß ich aber nicht. <civodul>PurpleSym: yes, you'll need to add sssd to name-services <PurpleSym>civodul: Done that and nscd loads libnss_sss.so, but name resolution is still not working. No idea what’s missing now :( <civodul>then you also need sssd running with a proper config, and that i'm not familiar with <PurpleSym>Got all of that from a working Ubuntu install. Weird. <alextee[m]>civodul: nckx : re: zrythm, i updated the policy to allow all fsf-approved distros to make any changes needed. i'm just waiting for a meson update to send in the new patch (need 0.55.0 or above) <civodul>hi alextee[m]! ah that is nicer :-) thanks for the update! <peanutbutterandc>I have a major problem: this computer that I'm trying to install gnu/linux for turned out to not accept any bootloaders (gets stuck during that process) <sneek>peanutbutterandc, you have 1 message! <sneek>peanutbutterandc, raghavgururajan says: Let me if it works :-) <peanutbutterandc>and it seems hat this too is stuck in building /gnu/store/hash-install-bootloader.scm.drv <civodul>peanutbutterandc: maybe not in building it but rather running it? (it's the script that actually runs 'grub-install' or similar) *janneke scratches head ... LD_PRELOAD .. hmm <peanutbutterandc>civodul, Oh hey Mr. Courtes... yes, grub-install is what the entire process has been getting stuck in... with linux mint, mx-linux, everything... so I'm guessing it's stuck with guixSD too <peanutbutterandc>..... which probably means that if I am to install a gnu system on this machine, this is no other way but to flash the firmware of this machine. (It only supports UEFI boot and not legacy mode, for some strange reason.... and it's actually in `efibootmgr` call (from within `grub-install`) that this failure occurs: that is what I have been able to gather so far <peanutbutterandc>Also, if it keeps on getting stuck at this point.... and I kill the machine.... is guixSD already installed? Just without grub? <vits-test>peanutbutterandc: Hello. Did You tried Fedora (i mean, maybe they know how to install grub there)? <brendyyn>peanutbutterandc: my friend had a similar issue, but then it magically solved its self when he plugged in a bootable usb device, because it made it change the boot order <peanutbutterandc>brendyyn, I have tried everything. Disabled secure boot. Manually copied contents of efi partition, everything.... nothing works <brendyyn>"everything" is quite a lot more than that <peanutbutterandc>brendyyn, Yes.... you are right. I've tried everything I could possibly think of (except for flashing the firmware)... It seems UEFI just does not work at all. And Legacy BIOS is just not an option. <vits-test>peanutbutterandc: I hope You can just return this machine to the store? To not play with this (like me with my ex-videocard). <peanutbutterandc>vits-test, It's someone else's, and it's already out of warranty, it seems. They used windows so far... so yeah.... <peanutbutterandc>Since I've already removed windows, and it only got stuck at the very end (grub-installation, efibootmgr work, to be precise): Looks like I'm stuck <peanutbutterandc>Anyways, vits-test, if I 'kill' the machine now: will I have a working guixSD (without grub, of-course)? Like it was with other distros? <janneke>i'm trying mothacehe's patch to look what's going on <pkill9>i like how easy guix makes it to create your own private build server <janneke>running a childhurd with injected secrets, though :-) <pkill9>since you don't need to make sure it's the same environment as your desktop <rekado>FYI: I have to send my *replacement* laptop in for repairs (again), so I won’t be able to do much in the next few weeks. <pkill9>apart from making sure the derivations match <janneke>ah but i misunderstood, diffutils is patched and acl breaks <civodul>rekado: uh, really bad luck with that laptop :-/ <apteryx>how can I retrieve the log-file of a source derivation? -S and --log-file don't seem to collaborate <janneke>iwbn if someone (or someone else, preferrably) could sponsor rekado <janneke>civodul: yeah, "it works" and much correcter than before, now to figure out what exactly "we" want <civodul>apteryx: it should work, unless said source was substituted <apteryx>example at hand: guix build -S linux-libre --log-file <apteryx>If i add the '--no-substitutes', then I get: guix build: error: no build log for '/gnu/store/4cj17hbkngj9w7mzn3xg49y9djw6j8zs-linux-libre-5.8.3-guix.tar.xz' <janneke>guix can make hardware almost replacable without any pain...if you have something to replace it onto <sneek>bricewge was last seen in #guix one month and 25 days ago, saying: Hello nckx. <civodul>apteryx: yes, that's because it's not been "built" locally <civodul>brendyyn: over the summer we've suffered from a lack of review hero i think :-) <civodul>we should do a patch review hackathon one of these days <brendyyn>I felt for them because they put a lot of effort in and said they didn't have time, but got no response. <civodul>yeah, it's bad contributor experience :-/ <apteryx>civodul: OK, but usually I get log files for substitutes as well. Is this only true for non-source derivations? *vits-test "ich bin meow. ich bin kitty aber nicht." <brendyyn>ya. theres also torbrowser-unbundle and the semver patches for crate imports to be reviewed. <civodul>apteryx: you can get remote log files (a URL) for derivations that have been built on your substitute servers <civodul>but perhaps this particular log file disappeared or something <apteryx>OK! If this occurs often, I'll try finding out why. Thank you <c4droid>Emacs tramp use the ssh login my guix server, after input password, the tramp say: Couldn't find proper 'ls' command. How to solve it? <pkill9>c4droid: install coreutils to your guix server, either as the user you login to, or in the system configuration <janneke>c4droid: use (when (require 'tramp-sh nil t) (push 'tramp-own-remote-path tramp-remote-path)) <pkill9>hmm actually i don't have coreutils on my machine, so that probably wont help <pkill9>looks like guix adds it regardless <pkill9>actually it's probably in %base-packages <c4droid>janneke: I'm using use-package in my MacOS.. <vits-test>Why alacritty want so much Rust? Is it worthy terminal, at all? <pkill9>someone must have wanted it, if it's been packaged <bdju>alacritty is actually really good <vits-test>I hope. I fear there aren't any Rust library that wasn't downloaded... <bdju>its claim to fame is the gpu accel or whatever that makes it print text fast and smooth, but I mainly switched to it because pango killed bitmap support and I was using termite which uses pango <c4droid>janneke: push it works, I want to restart emacs to test it again, see later. <bdju>alacritty doesn't use pango so bitmap fonts still work. also it has wayland support (so does termite, though...) <vits-test>bdju: on my semi-broken SBC install, there is only xterm that working (though i didn't tested much, yet :) <bdju>ahh. I wish you luck getting stuff working! <c4droid>I just restart my Emacs, the emacs give me a warning: Symbol's value as variable is void: tramp-remote-path <c4droid>janneke: eval-buffer can use, restart emacs return a warning <janneke>c4droid: you did copy the whole snippet, including (when (require ?? <vits-test>bdju: Ah, i just have no substitutes. That just rust 25 needed by rust 26 needed by rust 27... 30-th. Rust is ssssooo coool these days (_for me_) <bdju>ah yeah building rust stuff can be a real pain. I have delayed rust upgrades a dozen times when there weren't substitutes yet (just on normal amd64 stuff) *vits-test cancels Rust-build untill next weekend, then. <nckx>vits-test: Updating alacritty requires even more rust. I was about to, then noticed my alacritties were using over a gigabyte of RAM and thought, this is not the terminal for me. <nckx>It also wasn't significantly faster/smoother on my 3rd-gen Intel graphics. <nckx>vits-test: I went back to termite. *vits-test gives a panfrost look to his Mali. <nckx>Alacritty did feel like it started up ~100ms faster so that was nice... <pkill9>what do people think of a way of upgrading a package in a profile such that the inputs of the old version are grafted onto the new version if the version(s) of the old input(s) is the same as the version(s) of the new input(s)? or maybe if the minor version changes. I think it would be pretty neat <nefix>hello! Is there any way to disable building packages in the local machine and always grab the latest version in the ci? <c4droid>janneke: I just look the backtrace, the variable `tramp-own-remote-path' is not defined <nefix>i'm running guix from a USB and it was trying to build icecat <apteryx>common workarounds involve pegging your Guix a couple hours, or a day back with 'guix pull --commit=older-commit-hash', to give more time for the CI farm. <nefix>not a great move, since it was making the whole system really slow and would have taken hours to finish <apteryx>nefix: using the Guix 1.1.0 image? or one you created yourself? <janneke>c4droid: tramp-own-remote-path is defined in tramp-sh; that's wat the require is for ;) <apteryx>(because of the guix pull). 1.1.0 should have available substitutes <apteryx>or, as I wrote, a slightly older than current Guix. <nefix>maybe I'll write a script to get the last commit from yesterday or something like that <apteryx>in theory you could check for substitutes coverage in your channels.scm file, and find the most recent Guix commit that has substititues for all your packages, but I don't think that's easy to do. <civodul>you could run: guix time-machine -- weather $(guix package -I | cut -f1) <civodul>well, that gives you coverage for the latest commit <nefix>civodul: why does the queue return a 504 err? <civodul>mothacehe: it's one of these "Database worker unresponsive" in cuirass-web <c4droid>janneke: Ok, I just move the push under tramp's :config section, now it worked. <nefix>it would be really nice to be able to do 'guix weather --commit=<commit>' :( <tsmish[m]> https://paste.debian.net/1162003/. More atrocious patches. This one allows you to specify a list of trusted keys in channel record that are valid as signing keys for all commits in channel, allowing you to have some local changes without breaking authentication. ***caleb_ is now known as KE0VVT
<simendsjo>I've installed the guix binary using the installation script on Manjaro. Some operations will print `/gnu/store/..-bash-minimal-5.0.7/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)`. What's happening here? <str1ngs>sneek: later tell vits-test. I will see what I can do about *Messages* buffer. thanks for testing it's appreciated. <str1ngs>simendsjo: you need to install glibc-locales in your user profile and root's guix profile <vagrantc>simendsjo: guix uses it's own locales ... i think you need to install one of the glibc-locales packages and set GUIX_LOCPATH in your environment <sneek>vagrantc, you have 1 message! <sneek>vagrantc, guix-vits says: (aarch64) Do You have any pointers: how to make sddm, slim, or anything like that work? I can use sway, and xterm (for example). But the display managers do not work.. <vagrantc>sneek: later tell guix-vits no, i don't use a display manager ... prefer to use sway directly. :) <str1ngs>vagrantc: my rockpro64 should arrive today or tomorrow might be able to help guix-vits with that. <str1ngs>jonsger: one sec. my thunar is bash and dired. will check <str1ngs>jonsger: I might be able to replicate this issue since I'm using foreign distro right now. <jonsger>ah I think it's only relevant on Guix System <str1ngs>yeah, sorry I can't help with that. I think maybe adding gnome-themes-standard to your profile might help <str1ngs>also I use arc-icon-theme, but you should'nt require that I don't think. <simendsjo>Ref locales: I had glibc-locales installed GUIX_LOCPATH set in my .bashrc. But I'm not sure what you mean by the "roots guix profile". <jonsger>str1ngs: the thing if I boot into MATE everything is fine <alchemi>does guix provide a way to quickly put the source code of a package into the current directory? <jonsger>alchemi: guix build --source give you the tarball/checkout in the store and then you can extract from ther <str1ngs>simendsjo: ~root/.config/guix/current is guix current profile. is the profile used by guix-daemon <str1ngs>simendsjo: guix pull as root then guix install -p ~/.config/guix/current glibc-locales as root <str1ngs>simendsjo: then systemctl daemon-reload and then systemctl restart guix-daemon <drgibbon>simendsjo: yeah I'd never seen that one before either! <roptat>~ followed by a username is expanded to that user's home directory <drgibbon>guix seems very cool, how do you guys find stability in general? <str1ngs>~ = $HOME ~root is user directory for root for in /etc/passwd <lfam>~username is old-school Unix <lfam>Not unless you are Unix :) <drgibbon>CVE checking in `guix lint` is awesome :) <lfam>drgibbon: Guix is not as stable as distros that lack an easy rollback system. We aim to not break anything, but it's not like Debian where a broken system may need to be reinstalled <lfam>For example, the Emacs package / ecosystem was broken a few days ago ***jess is now known as meow
<drgibbon>so it's easy then to rollback the system if something breaks? <lfam>Yes, for pretty much anything except the bootloader <lfam>The bootloader *is* the rollback mechanism, so we absolutely cannot break that <str1ngs>you don't even need to roll-back as lfam mentioned <lfam>I think so drgibbon. At least, I never was able to do it until I got involved with Guix. The process for Debian (my other main distro) is just not possible to use unless you make a multi-year commitment <roptat>True, the bootloader allows you to boot any older generation that you haven't deleted yet <nckx>You can disable Guix's re-installation of GRUB on every reconfigure if you like, and be responsible for installing GRUB yourself, so you're not surprised by breaking GRUB updates either. <lfam>For Guix, one can follow the steps in the Contributing chapter of the manual, send a patch, and see it deployed on the same day <lfam>That's an ideal case, but it does happen <bluekeys>Hi guix. I'm trying to install guix system onto an x200. Are there any known issues with installing with wifi? I'm trying to use a tl-wn722n, which I think has libre drivers (I'm normally pretty good about checking these things). The select wifi network dialog gets as far as letting me choose a network, but doesn't ask for a key and then seems to hang. Am I doing it wrong? <drgibbon>are there any nice systems for making it easy to push updates? Say in the case of a version bump with minimal package changes? <vagrantc>and the process for building a custom package is essentially the same as installing the package ... <lfam>bluekeys: I'm sorry but I think there is a wifi bug like you describe in that version of the installer. I believe there is a "latest" installer, like a "nightly" build. Does anyone know the URL? Otherwise, you could use the manual installation. It's not too hard and we can help you with it <nckx>It will probably fix this (familiar) bug. <bluekeys>OK, now you mention it, I saw someone mention that not so long ago. For now, I'll go ahead with a wired install and then hopefully setting up wireless after the fact isn't impossible. <lfam>Zooming out a bit, I'm curious, is the release process still really difficult to do? Do you know, nckx? <lfam>bluekeys: It will definitely be possible after the install <drgibbon>ah one more thing, when a user is installing/building a package, is there some mechanism in guix to have the upstream signatures checked before compilation? <nckx>lfam: I have no idea, actually. *vagrantc has found "make dist" to be wrought with challenges <nckx>I've never made a release. <lfam>"One could" cherry-pick the fix for this to the release branch and issue a 1.1.0.1 release <vagrantc>makes me thing the download/latest page should also have a source tarball to make sure "make dist" keeps working <lfam>But, I've heard that the process is not easy or fast <lfam>drgibbon: Can you clarify what you mean? Like, which signatures? :) <vagrantc>there were rumours of trying to get a new version out ~September a while back <vagrantc>which might be worth moving that forward instead of patching an old release <lfam>Perhaps, but it really depends on what's possible. We are seeing people with this wifi problem all the time <lfam>Doing a new release might not be feasible within 30 days <vagrantc>drgibbon: typically upstream signatures are checked by the person updating the package, and guix has it's own verification hashes of the source code <lfam>drgibbon: The `guix pull` mechanism verifies signatures on the Guix code, and the Guix code is what defines packages and includes the hashes of upstream source code. So, it *should* be solid. But, I haven't heard of anyone attacking it as an adversary <lfam>Eventually we will want to have some work like that performed <drgibbon>ok right that's what I was getting at, it's assumed that the packager does the upstream signature checking. <bluekeys>OK. I seem to have more problems. I am being given no options when greeted by please select a disk for partitioning... There is another distro that needs to be overwritten. I think it's trying to hold on... Resistance is futile! <vagrantc>and recent versions of guix check the integrity of the commits since the last release, essentially <bluekeys>bye guix. I'll be back when I've more time to spend on this beauty <drgibbon>how would I build a package (just for testing, with `guix build`), but accept substitutions for its dependencies? <drgibbon>as in, I don't want to build the whole chain, just the final package <lfam>drgibbon: That's what Guix will normally do <lfam>By default, it uses substitutes whenever it knows they are available <lfam>You can do some tricky things in this area by composing `guix environment` and `guix build` <lfam>`guix environment hello -- guix build --no-substitutes hello` <drgibbon>I'm trying to build chessx with `guix build chessx`, but the final line seems to be just downloading a substitute for chessx. <lfam>So, you ask for substitutes for the dependencies of the hello package, but ensure that you build hello for source <lfam>Right, the "substitution" is supposed to act in a transparent way. Since, chessx has a substitute, Guix will download it by default <lfam>I meant to say, "ensure that you build hello from source" <lfam>Depending on factors, just doing `guix build --no-substitutes hello` may end up building many dependencies from source, which would take a while, so I like to use the composition I showed above <lfam>You might also pass '--no-grafts', since grafting is counted as a build, but is rarely what you are trying to examine <drgibbon>hmm, it seemed to go very fast, is there a build log somewhere? <lfam>Yes. When the command completes, it should print the filename of the result. You can pass that to `guix build --log-file` <lfam>So, `guix build --log-file /gnu/store/...` <lfam>These commands are all supposed to compose in a Unix way, so you can do stuff like `guix build --log-file $(guix build --no-substitutes --no-grafts chessx)` <lfam>If it seemed to go too fast, it was probably just a "grafting" build, rather than the real build <drgibbon>ah, I missed no-grafts, will test. Cool that you can do it as a single command. <lfam>Yeah, it can be nice. Unless the inner command fails, then the outer command will swallow the errors <lfam>Also drgibbon, if you already have a substitute for that chessx build in your /gnu/store, Guix won't want to build it again. You can either use `guix gc -D /gnu/store/...--chessx` to delete it, or use the --check or --rounds arguments to `guix build` <lfam>It's useful for debugging machine-specific bugs in my experience, vagrantc <drgibbon>What do you guys do for annoying stuff like Zoom? Does guix have some concept of non-free repos or anything similar? <drgibbon>Not that I choose Zoom (rather it's forced by work at the moment). <vagrantc>there's no support for non-free software on guix ... of course, people can do whatever they want with their own computers, but it's off-topic for guix channels <nckx>drgibbon: We ask that people don't promote the use of or link to non-free software here. (General discussion is fine as long as it doesn't fall under either.) <nckx>‘Here’ == any official Guix channel. <drgibbon>ok, well I'm sure as hell not "promoting Zoom", if I could avoid it (and proprietary software in general) I would be much happier! <nckx>Right, but facilitating its use would be 🙂 <vagrantc>i haven't had luck with using any of the browsers in guix with jitsi, but haven't tried too hard <nckx>If it's your jam, str1ngs had a WIP nomad + webrtc branch but I don't know if it's enough to run Jitsi. <msavoritias[m]1><nckx "If it's your jam, str1ngs had a "> I am actually looking to build that the next few days <drgibbon>Jitsi is nice yes, I use it with my family. Also the Signal desktop client is finally getting 1-1 video calls, hopefully group one day. *vagrantc should try nomad. <simendsjo>str1ngs: Thanks for the help regarding the "cannot set locale" problem. Installing glibc-locales as root solved the issue. <jitwit>Hi! How does adding a package typically work? I sent a package definition for J a few days ago and am wondering if there are things that should be changed etc <nckx>jitwit: That's how it typically works 😉 You wait. It can take a while. We're very sorry about that. Eventually, someone will review and/or push your patch. If nobody responds within a week or 2, feel free to, well, what you just did ☝ <jitwit>Ah good to know, wasn't sure of the timeline. There's no rush and apologies if I got too antsy! <nckx>It's a fair question and nobody thinks the current situation is ideal. <lfam>jitwit: I did read your patch but didn't reply yet. From a code review perspective, I thought it was basically fine, no major feedback. The main question I have is how the J language is implemented. Is it a case where it's written in another language (like C), and then compiled? Or is it written in an older version of J, and needs a "pre-compiled" J to build it? <lfam>Alright, I started looking into it myself :) It says on jsoftware.com, "J is written in portable C", so that is great news. There should be no trouble then <jitwit>lfam: Yes exactly! It's build system is fairly unique and weird. Yes, C and <lfam>That's great jitwit. There won't be any complicating factors then. Guix likes for language implementations to be "bootstrappable" from a language like C, whose bootstrap story we've accepted <roptat>Assembly? So it won't build on every architecture? <lfam>Rather than it "being turtles all the way down" <lfam>I'd assume it's only for x86_64 <lfam>Well, they say they support raspberry pi, so there must be some degree of ARM support <jitwit>It will work for arm as well, but not as the definition is written at the moment <lfam>I've always heard of J in the context of high-performance work, so I figure it wouldn't be so useful on most ARM hardware <lfam>jitwit: I recommend replying to the patch ticket saying that it's in C and asm. I'm sure that any reviewer will be wondering. Since the package itself is kinda complicating, it can be demotivating to wonder about <lfam>Kinda complicated, I mean <jitwit>Will do! I was also wondering about the right way to do libraries/addons. I wrote it so that the 'profile.ijs' file points to '~/.guix-profile/share/j/addons' so that they can be added independent of J ***meow is now known as jess
<nckx>The Guixy way is probably to use native-search-paths. If J can check an environment variable at run time instead of a hard-coded directory? <jitwit>An environment variable could be bolted on? It uses a local variable set during initialization to point to where to find things <nckx>The J equivalent of (define librarydirs (string-split (getenv "J_LIBRARY_PATH") #\:)) at start-up would be ideal. <lfam>simendsjo: The error message means that it can't find the implementation of (gcrypt hash), which is from guile-gcrypt <lfam>The pre-inst-env script changes your environment, and in this new environment, guile-gcrypt is not available <lfam>I just keep guile-gcrypt installed in my profile to improve the development workflow <simendsjo>lfam: Thanks. But if it's a requirement of quix, and I have quix installed, why doesn't I have guile-gcrypt installed? Why is it added when running `guix environment guix`, but not when "running" `guix install guix`? <lfam>You're not using the Guix that you have installed when you use pre-inst-env (pre-installation-environment) <lfam>I don't know why guile-gcrypt isn't made available by default in this context <lfam>In general, you shouldn't do `guix install guix`. That's not recommended or supported <vagrantc>well, it works ... it just has some really curious side-effects :) <vagrantc>notably, each time you do it, you get an older version of guix <vagrantc>as each version of guix only has the previous version of guix available to install <str1ngs>simendsjo: it's because you are on guix foreign distro. you can get around it by installing all of the guix depends. <str1ngs>depending on your distro that can be tedious. <str1ngs>simendsjo: to get around it do guix environment guix. the use pre-inst-env <str1ngs>you might need to ad-hoc a few things though. <joshuaBPMan>so weird. My guile website is running locally just fine, but it doesn't seem to run remotely. It compiles remotely, but I'm getting an error "Too few values to continuation", but I do not get that error locally. <joshuaBPMan>I guess the guile versions are slightly different. guile 3.0.2 vs. guile 3.0.4 <joshuaBPMan>guix package -i guile@3.0.4; guile --version; --> 3.0.2 ...what? *raghavgururajan was stuck at the xp and 32bit part, more that at the windows part <vagrantc>probably not totally infeasible on newish versions with their linux emulation/virtualmachine layers, but not something that old <raghavgururajan>If I were to see that message earlier, I would have replied "That's classified." ***caleb_ is now known as KE0VVT
<janneke>civodul: after we've been using guix for 3 years i still get basic beginners quetions and find some (pretty intelligent) people just want to be told what to do and seem happy to stay "in the dark" about what's going on -- so weird <str1ngs>janneke: hello, I think I finally got this emacy prompt issue fixed. at least I grok it better \o/ *vagrantc is very much a "how do i use it" first kind of person <civodul>janneke, vagrantc: OTOH i think it's a natural reaction: the first thing you want to know is how to use it :-) <civodul>and it's true that the manual wasn't doing a great job at it <civodul>but OTOH, it's also true that we're just adding more text just because people want to read less <lfam>I don't think they want to read less, exactly. They want to be told exactly what to read, and it must be concise <civodul>i mean i'm part of "they", not for Guix but for other pieces of software <civodul>though i think that's fairly recent for me, once upon a time i'd really invest time reading a manual really meant to be read as is over a few days (Gnus, Emacs, etc.) <civodul>this tells one thing: i'm an old fart <janneke>civodul: wondering what your collegue thinks of it if you can get them to read it <janneke>it's really hard to write good biggeners documentation, ime <janneke>but having something in place is great! <civodul>even the standalone Info reader has a "Getting Started" section :-) <janneke>i guess people want to read less /until/ they start their search engine <civodul>my colleague didn't even look at the manual <civodul>they just typed in stuff in a search engine <civodul>and the results were apparently pretty bad <janneke>yeah, it may get worse as guix grows more popular, hehe <janneke>one thing the internet is really great at, is keeping rumors and wrong approaches, disinformation alive for decades <civodul>heh, we've seen Phoronix do exactly that :-) <janneke>oh well, as long "we" are improving what we do, that's great <civodul>now i did that and didn't fiddle with childhurds <civodul>hopefully tomorrow i'll be more focused <janneke>i was wondering, and very happy to see you created this! <janneke>the hurd has been hoving at glacial speed mostly, anyway; and the fun stuff comes easily anyway <civodul>yeah sorry for not being more present on the Hurd stuff <civodul>this step should allow us to have "maintainable" build VMs, so it's going to be helpful <janneke>np, lot's of great opportunities ahead to make good for that ;-)