<vagrantc>i think it's basically a menu-based vs. commandline only installer <lsl88>I am trying to install SELinux to the daemon <lsl88>do I have to send you to bed hahaha? <nckx>Congratulations on the (finally, almost, completely) finished videos. <nckx>lsl88: No beisbol tonight so I'll send myself in an hour or so. 2am. Early night. <lsl88>thank you :) there's always work to be done. I´ m picky. Hope you like them, though *str1ngs chases after nckx <lsl88>ok, then I won't feel guilty for asking you about SELinux installation <nckx>lsl88: I'm purposefully not watching them until they are ‘finished’, which to me means ‘hosted or published on guix.gnu.org’, but I follow the discussion. Videos: a lot of work.™ <nckx>lsl88: No need to feel guilty about anything, but I know literally nothing about SELinux, sorry. I've never used a distribution that encouraged its use. <lsl88>there's always work to be done on the videos. We can improve the colors of the cli sessions, create subtitles, create more videos, translate them <lsl88>don't worry, maybe I'm making a silly mistake, or I didn't understand sth properly <nckx>Sure, and I won't wait that long. ;-) But I assume (=hope) there'll be a big announcement and prominence given to the videos on the ‘Discover Guix’ section of the home page. *lsl88 didn't think that videos were so important :) <nckx>…so she dedicated months of her life to them. <nckx>Is it normal that I have to repeat myself completely in ‘#:modules (…)’ and ‘#:builder (begin(use-modules (…)))’ when using the trivial build system? <nckx>Completely plausible, but thought I'd ask. <lsl88>nckx: may I ask you a few questions? I'm stuck :( <nckx>lsl88: Ask away, but if they're SELinux-related I really haven't a clue. <lsl88>I installed Guix on top of Fedora <nckx>(There are plenty of friendly lurkers here who might ☺) <lsl88>but now I need to run `semodule -i etc/guix-daemon.cil` <nckx>lsl88: Hm, I've never got that error. Are you running this in a ‘guix environment guix’? <lsl88>no, the point is that I need the etc/guix-daemon.cil file <lsl88>so running it inside an environment wouldn't be of much use <nckx>Yes, but if (which I can't answer either way) you need to bootstrap, that needs to happen within an environment. <str1ngs>lsl88: you need guile development package <nckx>lsl88: My notes give the following packages as required to bootstrap Guix: <nckx>"gnutls" "guile" "guile-gcrypt" "guile-git" "guile-json" "guile-sqlite3" "guile-ssh" <lsl88>the point is that I can't create an environment, SELinux doesn't allow me <nckx>Note that these are Guix package names; you'll have to Redhatise them. <lsl88>yes, I know, I was going to look them up <nckx>lsl88: I think you should be able to rpm (is that still the thing?) install them. <str1ngs>though all of this can probably be avoided if you use the release tarball? <nckx>My last Red Hat installation was literally installed off two floppies ☺ <str1ngs>unless you actually need to build guix? <nckx>str1ngs: Doesn't the installation script install the binary tarball? This is all too damn foreign for me. *makes old man noises while installing Guix manually* <str1ngs>guix-install.sh install the binary distro yes <str1ngs>and I don't think you need to autoreconf for this aka bootstrap <nckx>And does this installed /gnu/store not contain a .cil file, whatever that is? (I know, some lispy SELinux policy or so…) <nckx>Where is rekado when you need 'em. *lsl88 was supposed to tell rekado :/ <str1ngs>guix-install.sh does not need to be bootstrapped. guix-daemon.cil.in does <lsl88>yes, that was why I was trying to bootstrap <nckx>lsl88: curl -L <guix binary ball> | tar Jt | grep cil gives me: /gnu/store/ncknl03pkmamrxg7q9nxi1rn1qhvwbi9-guix-1.0.1/share/selinux/guix-daemon.cil <nckx>Does that exist on your system? <str1ngs>it needs to template out paths so makes sense <str1ngs>but yea, as nckx is pointing out I would use guix-install.sh and the use the store cil file <nckx>lsl88: That's the 1.0.1 tarball, by the way. <str1ngs>that should be the least amount of effort I would think <nckx>Yeah, if you're not actually hacking Guix itself (are you?) you shouldn't™ need the git checkout. <str1ngs>not only that but some guix dependencies are not packages with most distro's <str1ngs>the way I get around it is to build my own guix stack. but that's not a trivial process <lsl88>I can't find it in the store <str1ngs>did you used the guix-install.sh from the git repo? <lsl88>I used the script from the documentation <nckx>lsl88: That's… not right. I've never used the install script but if it deploys the binary tarball, and the tarball definitely contains a .cil file, then you must have that file in your store :-/ <lsl88>let me see if there are differences between them *nckx is not really a fan of magick scripts for this reason. <str1ngs>yeah but the guix-install.sh is pretty good and kinda needed <str1ngs>atleast until all foreign distro have the guix dependacies *lsl88 doesn't know why couldn't find it before *str1ngs dons tinfoil hat <lsl88>nckx: you should go to bed ;) <str1ngs>he cant' he must hold vigil here on #guix :P <lsl88>str1ngs: he should go to bed <str1ngs>I don't even know what TZ nckx . if I were to guess I'd say EST though <nckx>Mothe—I mean lsl88 is right. Bed times for Tobies. <lsl88>nckx: you said that you were going to bed at 2 am <lsl88>maybe having a world's clock? <str1ngs>I wonder how vagrantc debian package was received . that would avoid some foreign distro issues <lsl88>I can't say I don't understand because actually I understand that some people are awake at night and can do better *nckx → 😴 Good night str1ngs, good night mother. <nckx>Good luck with SELinux, lsl88. <str1ngs>good night nckx . and now your watch is over :) <lsl88>nckx: thank you. Good night and thank you for your help :) ***Server sets mode: +cnt
<eric23>I am trying to find out what could be wrong with my system. guix pull says removing corrupted link. Is it evidence of my OS being ruined? <eric23>I have turned off the computer when it froze. I suppose it is a corrupted file system? <Gamayun>eric23: Is it running normally aside from the guix pull error? Could you post the output of guix pull to a pastebin or such? <eric23>I think it is running normally. Right now. Earlier today, my computer froze trying opening a few programs. <eric23>it says to run `hash guix`, but I don't have the hash command. <eric23>guixsd complains about not having an mtab. I have my root filesystem encrypted <eric23>so it can't do a filesystem check. I went into the livecd and did the filesystem check. <Gamayun>I'm guessing it wants you to run 'guix hash' on the guix executable to make sure your shell is looking for the guix you just updated. <Gamayun>You certainly should have an mtab as a symlink to /proc/self/mounts. <Gamayun>eric23: Does 'sudo herd status' report any failed services? <eric23>Stopped: - term-auto ;; One-shot: * user-homes <eric23>currently I am building again with guix system reconfigure ***emyles` is now known as myles
<PirBoazo>J'ai une question concernant les déclaration dans le fichier config.scm <PirBoazo>Qu'est-ce qui est faux dans cette déclaration ? <PirBoazo> (service static-networking-service-type <PirBoazo> (static-networking-service "enp0s8" "192.168.56.200") ) <PirBoazo>Je ne trouve pas dans la documentation des explications sur la syntaxe de ce fichier config.sys. :-( <PirBoazo>I have a question about the declarations in the config.scm file <PirBoazo> (service static-networking-service-type <PirBoazo> (static-networking-service "enp0s8" "192.168.56.200")) <PirBoazo> I don't find in the documentation explanations on the syntax of this config.sys file. :-( <roptat>PirBoazo, la syntaxe du fichier c'est du Guile <roptat>je dois juste vérifier, mais ta syntaxe a l'air correcte. Tu as un message d'erreur ? <roptat>est-ce que tu peux partager ton fichier de configuration, par exemple sur paste.debian.net ? <PirBoazo>Voici l'erreur : ERROR: In procedure append: <PirBoazo>In procedure append: Wrong type argument in position 1 (expecting empty list): #<<service> type: #<service-type static-network-interface 2c873c0> value: (#<<static-networking> interface: "enp0s8" ip: "192.168.56.200" netmask: #f gateway: #f provision: #f requirement: (udev) name-servers: ()>)> <roptat>ah, service static-networking-service renvoie directement un service, donc pas besoin de l'appliquer à quoi que ce soit <roptat>enlève le service static-networking-service-type autour de service static-networking-service <roptat>comme ça : (list (service ...) (service static-networking-service "enp0s8" ...) ...) <roptat>service static-networking-service-type est un type de service, pas un service lui-même (ce n'est pas une fonction, donc il ne peut pas recevoir d'argument) <roptat>si tu regardes le service juste au dessus, c'est la fonction "service" qui est utilisée et on lui passe deux paramètres : un type de service et un argument éventuel. mais dans le cas de service static-networking-service, c'est directement une fonction qui renvoie un service de type service static-networking-service-type <roptat>tu vas sans doute encore avoir un autre problème avec %desktop-services parce qu'il contient déjà un service réseau qui va entrer en conflit avec service static-networking-service <PirBoazo>root@guix-pib ~# guix system reconfigure /etc/config.scm <PirBoazo>guix system: error: service 'networking' provided more than once <roptat>yes, exactement ce que je disais :) <roptat>non, il y a une astuce dans le manuel, mais faut que je retrouve ça... <roptat>à la place de %desktop-services, tu vas utiliser (remove (lambda (service) (eq? (service-kind service) network-manager-service-type)) %desktop-services) <roptat>et rajouter (srfi srfi-1) dans les modules au début de ton fichier *roptat must afk, I'll be back in ~30 minutes <PirBoazo>non , j'ai un grand nombre de messages.. <PirBoazo>Il ne semble pas y avoir de probleme de syntaxe. <civodul>PirBoazo: tu peux copier/coller ta config ? <roptat>PirBoazo, le grand nombre de messages, c'est peut-être la nouvelle génération du système en train de se construire, non ? <civodul>meanwhile the non-French speakers remain silent :-) <roptat>s'il n'y a pas d'erreur tu peux laisser tourner <roptat>ah, tu as mis la structure (remove ...) à l'intérieur de (list ...) du coupt append n'a qu'un élément, et la fin de la liste est une autre liste <PirBoazo>je ne comprendds pas assez la logique :-( <roptat>il faudrait déplacer ce bloc de sorte à avoir (services (append (list ...) (remove ...))) <roptat>%desktop-services est une liste de services <roptat>remove est une procédure qui prend un prédicat (qui permet de filtrer un ou plusieurs éléments) et une liste, et renvoie une nouvelle liste avec un peu moins d'élément (ici un en moins, le service network-manager) <roptat>(list ...) permet de créer une liste, comme son nom l'indique :) <roptat>et append prend en argument une ou plusieurs listes et crée une liste qui contient les éléments de toutes ces listes <roptat>c'est un peu compliqué parce que ce sont des listes de services, mais tu peux essayer de t'amuser avec des listes d'entiers par exemple dans le repl de guile (lance simplement guile, et essaye de taper des trucs comme (append (list 1 2) (list 3 4))) <roptat>la première ligne import (srfi srfi-1) pour pouvoir utiliser remove plus tard <roptat>la deuxième défini une variable, l qui correspond dans l'analogie à %desktop-services (une liste de services, au lieu d'une liste de nombres) <roptat>ensuite, tu peux voir quelques opérations et leurs résultats <roptat>le problème que tu avais avec « service 'networking' provided more than once », c'est que %desktop-services contient un service network-manager-service-type, qui fournit un service networking <roptat>or tu ajoutes un static-networking-service, qui fournit aussi un service networking, mais ces deux services sont mutuellement exclusifs <roptat>si tu changeais l'ordre, ça n'aurait rien fait : tu te serait quand même retrouvé avec deux services networking <roptat>donc on utilise remove pour supprimer précisément le service networking dans %desktop-services, dont tu ne veux pas, pour qu'il n'y ait qu'un seul service networking <roptat>(désolé, je dois t'assomer d'informations ^^") <roptat>au même niveau (en terme de parenthèses) que le (list ...) <civodul>rekado_: hallo! what's the status of qemu-binfmt on the build machines? <mbakke>civodul: It was probably built a few weeks ago on 'staging'. <civodul>mbakke: could you add an account for yourself in the config of berlin? :-) <roptat>PirBoazo, oh, ça ressemble plus à rien :/ <roptat>enlève le premier %desktop-services <PirBoazo>guix system: error: service 'networking' provided more than once <roptat>on veut retirer network-manager, pas gdm ;) <rekado_>civodul: I wanted to rebuild these machines with the install-berlin script, but failed. <rekado_>I think I was stuck with starting a remote inferior Guix <mbakke>civodul: I've added me now in guix-maintenance. <PirBoazo>roptat : ce sera un chouette challenge ;-) <civodul>mbakke: thanks! i'll reconfigure in the next few days (also to add lzip support for good!) <mbakke>civodul: Cool! Hopefully the next staging merge will go smoother ;-) <mbakke>Also, looking forward to finally look at those Zabbix graphs. <civodul>oh right, that's an added benefit :-) <rekado_>on our cluster installation, we’re preparing to make /gnu a local file system on the node that runs the daemon. <rekado_>unfortunately, this means that the setup will become more complex <rekado_>right now we can reboot that node without problems; the daemon will disappear, but /gnu is still available on all nodes <rekado_>when /gnu becomes a local file system we need to think about high availability <rekado_>this means: two nodes, DRBD to sync the disks, pacemaker for NFS failover, etc <PirBoazo>roptat : je vais noter dans une page web cette configuration :-) <rekado_>bleh, I don’t enjoy setting this up. <rekado_>remote inferiors: I think it’s enough to spawn a remote “guix repl” session and then start an inferior there. <civodul>rekado_: that seems to be the setup we have here, and i thought you had something similar <civodul>(what do remote inferiors have to do with that? :-)) <rekado_>remote inferiors are what’s blocking me from updating the berlin build nodes. <rekado_>civodul: our setup is simpler, because /gnu lies on a file server “appliance”. <rekado_>we don’t export /gnu from the node that runs guix-daemon <rekado_>if the big file server appliance goes down we’re in trouble anyway. <rekado_>I didn’t feel like being responsible for downtimes whenever I change the node running guix-daemon. <rekado_>(and in the early days I did this a lot.) <roptat>PirBoazo, si tu écris des choses à propos de Guix, j'aimerais beaucoup les lire, tu partageras ici ? :-) <civodul>i mean the node that runs guix-daemon does little else <civodul>so it's always available in practice <rekado_>up until a few days ago that machine *also* hosted guix.mdc-berlin.de <rekado_>I’ve now moved this to a separate VM. <rekado_>(generated with “guix system”, of course) <rekado_>this forced me to keeping an eye on upgrades and made me reboot it more often that we’d like for what would have been an NFS server. <civodul>rekado_: so that machine runs Guix System? <rekado_>guix.mdc-berlin.de does (as soon as the switch is complete) <rekado_>because I think we can’t easily configure DRBD, NFS servers, and the like — yet. *rekado_ smells the mouldy stench of stale NFS service patches… <mbakke>DRBD and Pacemaker is fun, I will try packaging them. <mbakke>Risky click of the day (it's SFW :P). <roptat>it's from nixos, the inspiration of Guix <roptat>they are creating a fixed-output derivation (in Guix, it's what url-fetch does for instance: it's a derivation with network access whose content is known in advance) <roptat>but the content is not actually fixed, but they still need network access, so they create a sha1 collision iiuc <roptat>I don't know because I don't really understand what they are trying to do with that... <roptat>but I think that means it breaks the basic assumptions of Nix <roptat>but I thought nix also used sha256 to hash content, so I don't really get it... <ItsMarlin>you guys are surprised, and i have no idea what the nix thing means <kmicu>Still better than Emacs Horrors though ;) <Retropikzel>System reconfigure gives me error symlink: Permission denied. What should I do? <civodul>Retropikzel: are you running it as root? <civodul>'system reconfigure' is about reconfiguring the system, so it requires root privileges to complete <roptat>kmicu, umatrix doesn't like your link :) *rekado_ has a habit of not visiting the “sent a long message” matrix URLs <jonsger>I think that is because matrix doesn't split long messages in multiple for IRC... <civodul>maybe we've missed lots of long but important messages, who knows <kmicu>roptat: I’m using uMatrix, have js turned off by default. It works here. Maybe there is an issue with copypasting cuz link to mp4 is too long? <civodul>roptat: the problem remains that IRC doesn't lend itself well to long messages :-) <civodul>i'd personally prefer to get such messages on help-guix <kmicu>roptat: anyway. That short clip just shows usual progamming practices. ;) <rekado_>kmicu: your URL appeared fine. It’s g_bor[m]’s message that got converted to “g_bor[m] sent a long message: <matrix.org URL>”. <roptat>g_bor[m], I've received my new disk yesterday, so I'll re-install guix system on it this week-end *kmicu ’s rxvt_unicode url handler is always broken on urls longer than one (visual) line. <roptat>since I'm going to re-install guix shortly, I think I should try and ensure my home is cleanly managed <roptat>I think that means I don't want to mix config, caches and my own data together <roptat>my current disk is 11 years old and starting to fail <civodul>it's a notion from imperative distros :-) <roptat>so I think guix can't do anything about that :) <roptat>the weird thing with it failing is that sometimes the system won't start and drop me in a repl, and sometimes it will boot just fine <roptat>so I was thinking that I could make .config read-only and have it managed by guix or a similar system <roptat>but there are also configurations directly in ~ <xavierm02>Hey. Is there some simple way to ask guix to update only stuff that won't take long (i.e. no building of big things, no downloading of huge substitutes)? <civodul>xavierm02: note that it could be a risk: you could be missing important security updates <civodul>that said, you can always do "guix upgrade -n" <civodul>and then you check whether, say, libreoffice "would be built" <civodul>it that's the case, you can do "guix package -u . --do-not-upgrade=libreoffice" <roptat>so maybe make my ~ read-only except for some parts in it? but how to give guix permission to write to it? <xavierm02>civodul: libreoffice is exactly the package I was thinking about ^.^ | I'll do that, thanks! <roptat>I don't really know how it works, but I want to make sure that no program will be able to write a configuration file, even if it's not configured (so I can detect stuff for which I need support) <roptat>home-manager seems to try and preserve existing configuration, but that's not what I want to do :) <roptat>I want to fearlessly override anything in my ~ and don't let anyone touch anything there except guix <g_bor[m]>roptat: nice. I also would aim for that, but now I am under a bit of time pressure. <roptat>maybe I should have my data in /data for instance, and make ~ read-only <g_bor[m]>rekado_: sorry about the long message. I was sending my notes about the installer, so that you could comment on the priorities of the issues I encountered. <roptat>and tweak some environment variables so downloads are done in /data, configs read in /home and caches generated in a read-write directory inside /home <roptat>but then there's ~/.config/guix which is not exactly read-only, and ~/.guix-profile <roptat>can I configure guix to have these elsewhere? <roptat>I mean ~/.guix-profile and ~/.config/guix/current <mbakke>civodul: Thanks! Can you also do the same for libgsf? I think we are almost done now... <g_bor[m]>roptat: my original plan was to have a data directory in my home, and pull in the top level files using stow. This might leave some leeway, but it is better than my current situation. <roptat>I think I'll do something similar too <roptat>but leaving the data directory outside of /home means I can make ~ a symlink to a profile generation <roptat>and I think guix profile links in ~ are the only issue <roptat>looking at (guix profiles) and it seems it's not possible :( <roptat>%user-profile-directory is $HOME/.guix-profile <roptat>so maybe with a wrapper I can do something, but the current profile looks more difficult to move <roptat>would a patch to add GUIX_CURRENT_PROFILE_PATH and GUIX_DEFAULT_PROFILE_PATH be accepted? <roptat>oh, or maybe simply using guix pull -p something might work <xavierm02>Is there a script to avoid entering my encryption password twice in guixsd? I know that the usual way to do this is to add a keyfile and pack it in the thing that grub decrypts, but it'd probably take me a while to do make scripts that do this, so if it's already been done, it'd be a great help. <nckx>sneek: later ask civodul: On ci.? I just updated VLC and both versions built fine… <sebboh>nearby DATA/firefox/ directory) to remove anti-features from Firefox. <pkill9>sebboh: what does firefox have that icecat lacks for you? <sebboh>Well, 13 months is a long time. My yubikey works in Firefox now. Performance is better. Javascript is syntax highlighted in the Developer Tools console. <kmicu>13 months means that the next ESR in few weeks will be 68 and will be as old as regular Firefox 68 version. 😺 <sebboh>Well, I generally use nightly. So, I'm currently on 69. :) I'll admit that before I reviewed the release notes, I thought version 60 was from before their "Quantum" release. It's not. That was the major change of recent years, and IceCat has it. <g_bor[m]>I would like to know how to configure swap in guix system <nckx>I'm guessing your need goes beyond swap-devices. <g_bor[m]>I saw the operating system seems to have a swap entry, but only device names seem to be supported... <g_bor[m]>I would like to use a uuid, if possible. <sebboh>g_bor[m]: I generally forget to define it in my System configuration, so then I just do 'swapon /dev/sda3' the first time I notice that the machine has no swap... Which is usually a few days after I booted it. :) <nckx>g_bor[m]: It is [even] possible to specify a swap file in a file system on a mapped device, <nckx> provided that the necessary device mapping and file system are also specified, quoth the manual. <nckx>g_bor[m]: /dev/disk/by-foo? <nckx>Is udev not ready early enough for that? <g_bor[m]>nckx: yes, thansk, just what I was looking for. <g_bor[m]>I am not too much into the boot order... <sebboh>g_bor: swap parititions can also have labels. the swapon tool supports it (via -L <label>). At least, mine does, it's from util-linux 2.33.1 <nckx>If that doesn't work you'll have to write Scheme code to read the UUID straight from the swap partition, or a generic partition UUID extractor (that'll only work on GPT though). <g_bor[m]>nckx: ok, I will try that. I was thinking about this, as recently a similra issue arose regarding the bootloader installation, where the device name was also sda, which turns out not to be stable. <nckx>sebboh: We don't expose the raw swapon command that well, unfortunately. Does it support the magical ’LABEL=foo’ syntax as well? That would work. <nckx>g_bor[m]: That's easier to solve because we never need to install GRUB at early boot time, but can just rely on /dev/disk/by-foo on Linux. I have some code to finish that does just that, but it's too baby's-first-Scheme-book level to submit as-is. <nckx>I *think* that's the best we can do there. Swapon could be solved using only Scheme code, i.e. better. We already read raw UUIDs for ‘real’ file systems, not relying on udev at all. <g_bor[m]>nckx: yes, and that would also provide a more uniform configuration interface, I believe. <nckx>I don't think we even call the "swapon" binary, but use syscalls directly. Niice. <g_bor[m]>At first I will check if this works as is, maybe the patch here is as simple as yours for the other issue... <sebboh>I don't know about this LABEL=foo syntax, nckx. I see in the man page that it supports -o <arg> where arg is: an "fstab-compatible comma-separated string", for example: `swapon -o pri=1,discard=pages,nofail /dev/sda2`. I fully support your scheme-based approach, fwiw. And I am not sure your perception that your scheme code is on some wrong 'level <nckx>g_bor[m]: Great! Eventually we should support a generic (uuid …) syntax everywhere, but /dev/disk/… is a nice hack for now. <sebboh>' is warranted. (Doesn't the best lisp/scheme code in the world have a certain child-like, innocent quality?) <str1ngs>hmmm how can I refer to a local git repository? I thought I could do this (url "file:///path/to/repo") <sebboh>did you try without file://? Simply /path/to/repo ? <sebboh>(my response isn't about guix, sorry, it's just about git.) <nckx>sebboh: In fstab, for example, you can use LABEL=foo instead of /dev/foo and it is magically consumed by at least mount. But a) it might just use udev for that and we're back at square one b) it's a bit of an ad-hoc hack, since we don't rely on these helper binaries we probably shouldn't emulate their weirder features. <str1ngs>maybe the deamon does not have access the the repository ... weird <nckx>I use that syntax in my channels.scm for example. <str1ngs>maybe it's only supported by channel? <sebboh>nckx: oh *that* LABEL=foo trick. Let's see... <nckx>sebboh: Heh. Maybe. It's just full of car/cdr and other stuff that's not quite up to snuff nowadays, it seems. <sebboh>Does there exist a style guide for guix yet? <g_bor[m]>wow... guix system is being very helpful right now... error: source expression failed to match any pattern.... <nckx>str1ngs: It's supported by git proper. Do we reimplement git in Scheme too? Is that what guile-git or whatever is? I thought we just used bindings. <nckx>g_bor[m]: It should print at least the expression that failed to match. <str1ngs>nckx: guile-git is bindings to libgit2 <nckx>Guile's error messages are… not great, but I can usually figure that one out nowadays with little effort. <kmicu>nckx: not great but still better than what we have in Nix ;) <nckx>Oh boyos that Nix link this afternoon. <g_bor[m]>nckx: better now... I was misusing parents in the use-modules... *nckx meant that as Scheme but it just looks like English. So is *that*… great Scheme code? <kmicu>Abusing hash collisions is only an implementation detail. <sebboh>Oh wow, the style guide, short as it is, specifically shuns use of car/cdr. That must be what you were referring to, huh, nckx? :) <nckx>sebboh: Mainly. It's also just plain convoluted. I started rewriting it on the bus, just not finished yet. <kmicu>Are you talking about convoluted networks? AI? Where can I invest in your startup? <nckx>I don't no what those are, so that makes me as qualified as anyone to say yes. <nckx>AI: I won't tell the emperor if you won't. <nckx>(The only time I had ever seen Lisp before installing GuixSD was an ‘AI’ textbook from the 90s I picked up at the library. How times have changed.) <kmicu>And now we know you are a vi user. <nckx>~/guix ⑂nckx-master* λ vim <nckx>bash: vim: command not found <sebboh>Wow, that nix commit actually performs an MD5 collision on purpose because there is some reason they want to change a file but not the md5 sum. Classy. <nckx>sebboh: But now they've upgraded to a SHA-1 collision so all is well. <nckx>kmicu: But yes, I only started using emacs in ~2014, on GuixSD. <sebboh>What's a non-classy thing that guix code does? Just to be fair... :) <nckx>sebboh: I'm not even sure it's not classy. It's the word ‘hack’ personified in all its splendour and original glory. <nckx>kmicu: You are so off-base my bud. <nckx>I refuse to fit into any of your neatly defined categories! <kmicu>Did you use Notepad before 2014? <nckx>(No, I used vi, but I never even considered emulating it in emacs.) <nckx>Now I ssh into my BSD boxen and weep. <kmicu>What is BSD? I thought only Guix System exist now. <nckx>It's the thing I keep around to run npm on once in a while. <nckx>Literally the only reason. <kmicu>Ah, yes. NPM provides left-pad thing. <nckx>I've ported every other reason to Guix over the years. <kmicu>Wait a minute, did you bump Coq‽ <nckx>And my Web-mail, which is that awful thing I use once a year on holiday on machines without emacs. <nckx>[No ‘but it breaks my x completely’? Phew.] <kmicu>And bavier improved Idris. Thank you. <nckx>kmicu: I did some basic testing, but let me know if it does break a thing. <kmicu>Also I see that we have some happy Sway users. *nckx was excited to see that. Is Sway usable on Guix System? <nckx>I haven't made the big jump to Wayland yet. <kmicu>(E.g. swaybg (screenlock for Wayland) added.) <g_bor[m]>nckx: I am also trying to set up sway right now. <nckx>Good, I can leech of your effort 😊 (thanks!) <g_bor[m]>If anyone has it working, I would be happy to see a config. <kmicu>nckx: alas I wait for hotkeys emulation. So I stay on X by choice. Not having xbindkeys (config in Guile) alternative doesn’t make me happy. <recj>anyone here using gnustep + windowmaker by any chance? <recj>can't seem to find the package to install <kmicu>Hi recj guix has ‘windowmaker’. Do you need something else? *kmicu really wanted to write ‘widowmaker’. <recj>hi kmicu, thanks. i actually have it installed already, but for some reason i can't select it in gdm <kmicu>recj: did you install it as a regular user (guix install…) or add it to packages in system config file? *str1ngs throws things around! (˚Õ˚)ر ~~~~╚╩╩╝ <str1ngs>if i use url-fetch it will recursively copy the local file path. which is hilarious since it copies git objects as well. but I don't think runs autoconf then. I guess git-fetch assume autoconf is required? <nckx>str1ngs: Not seeing the hilarity or the assumption quite yet… <nckx>autoconf is run by the build system, if you provide the required inputs. <str1ngs>actually it's a local copy so it's whatever state the origin is <str1ngs>I don't think this is worth doing. I may run a local cgit and use that uri <nckx>Stand aside ma'am I'm an overengineer. <baconicsynergy_>so ive always wondered... why does GNU dd have an uppercase M and BSD dd has a lowercase m when specifying block size? <emsyr>Hi. In enlightenment connman and econnman work correctly only when at root account. No luck searching. Can anyone help? Thanks. <recj>kmicu: everything works, thank you :-) <dongcarl>Does anyone know how to use the d3js chords generated by `guix graph`? Just wanna know what it looks like, but loading the html doesn't seem to do anything <recj>other than that does anyone know how i can get clear <sebboh>What is that name of that package that is default-installed on Ubuntu and checks each command line for 'command not found' and tells you the name of the package you may want to install to gain that command? I only ask here because I think we spoke of it here the other day. <recj>when i type `clear` or use a program that depends on it it prints an error <nckx>baconicsynergy_: My guess is that GNU dd was written before the BSDs supported that suffix, and they simply added it independently. (Are you sure there's no m=1000/M=1024 weirdness going on? Some tools do that, just to make it more confusing.) <nckx>recj: ‘clear’ is part of ‘ncurses’. ‘guix install ncurses’. <recj>ah, i see. i tried ncurses-bin before <sebboh>Yes, clear comes from ncurses. I found that out just now on a Debian machine using apt-file search -x `which clear`. Apparently guix doesn't have a command that can search like that yet, but some people want it so maybe sometime later. <nckx>recj: What's ncurses-bin? <recj>just something i saw from searching about this issue <recj>i got another one of the hints, are those lines that should be in my .bash_profile <nckx>sebboh: The even shorter readlink `which clear` is equivalent to that. What is missing is searching for commands before they are installed. <rekado_>dongcarl: you need to run this from a git checkout, so that it can reference d3.v3.js <sebboh>nckx, it's the name of the debian package that actually contains that file. Some debian packages are split into <package>-bin, <package>-common, <package>-docs, etc. <nckx>sebboh: Oh. So like our ncurses:bin (if that existed)? Neat. <dongcarl>rekado_: Oh like using `./pre-inst-env`? <sebboh>nckx: I am not sure about that, what does : mean in the name of a guix package? In debian, the -bin is just part of the name.. it could be -bins if the author chose. <nckx>sebboh: In Guix, it's a bit more special, but it seems to perform the same role. <str1ngs>nckx: it's not over engineered. I need to test builds locally without pushing upstream. I've worked around it by using a designated branch for testing the guix package. <sebboh>nckx: debian has a : in package names sometimes, too. it's <package>:<arch>, for multi-arch machines. <nckx>It designates a package ‘output’: one build can create multiple /gnu/store directories, such as :utils, :bin, :static… The names are a bit ad-hoc sometimes and most packages don't. The default output is :out and is implied: installing ncurses is equivalent to installing ncurses:out. <baconicsynergy_>nckx, that sounds like a pretty reasonable explaination. (and I think GNU dd fails if you do a lowercase m, so no mebibyte/megabyte tomfoolery) <rekado_>dongcarl: we should fix this so that it works without pre-inst-env; we’d need to install d3.v3.js somewhere. *nckx is a actually a fan of the bibistuff, apart from the silly names. Too much historical confusion, nuke it all and start anew. <dongcarl>I'm confused as to why we need `guile-bootstrap` in the bootstrap binaries... It seems that it's only used by `ld-wrapper`, couldn't we just write `ld-wrapper` in C or simply patch glibc-intermediate so that it can build without `ld-wrapper`? <dongcarl>rekado_: True, also inlining would be nice so that the html file is portable (depending on license) <sneek>civodul, you have 1 message. <sneek>civodul, nckx says: On ci.? I just updated VLC and both versions built fine… <civodul>nckx: yeah the previous version failed on ci. <katco>if i have several packages that inherit from a base package, is it ok to place those in a single commit? <vagrantc>civodul: i'll try to bind-mount qemu and all it's dependencies into a chroot before running debootstrap ... that should work. a bit cumbersome ... but should work :) <vagrantc>though supporting a static qemu-ARCH build and configuring binfmt to load it from the host does seem considerably simpler :) <kmicu>katco: sure, that’s reasonable. Sending a patch for a base package and then if accepted the rest in seperated commits also sounds good. *nckx , the editor in: s/effecting/affecting/ <katco>kmicu: i'm in the middle of commiting 61 packages, so i hope i'll be forgiven if it's the former <vagrantc>dongcarl: how's riscv64 coming along? do you have definitions sufficient to build cross-compilers? <cap>Good evening. I'm new to guix and I'm trying to find out, how to set the keyboard-layout for sddm. Does anyone can give me a hint, where I could look up such informations? <nckx>str1ngs: You probably know this, but I'd be amiss not to point out that pushing to the branch will cause that to fail (or worse: silently succeed in building an outdated version). Not a problem if that file stays on your machine, but might be if it escapes into the hands of unsuspecting users. <dongcarl>vagrantc: Hey dude, yeah it's a long story... The way I use cross-compilers with Guix is I build a cross toolchain package and then put it in a manifest for my environment and set the `CROSS_` env vars myself... <dongcarl>However, there's an obscure bug I keep running into on core-updates that seems to be happening for ALL cross-compilers <str1ngs>nckx: it's a good point. but it's designated to a branch. ideally I'd prefer to build local. the main point is not polluting git history on any main branch or pulling the stable guix build. <dongcarl>can be reproduced with `guix build --target=aarch64-linux-gnu coreutils` <katco>kmicu: of course! i love guix *dongcarl needs to collect logs and send to bugs mailing list <kkebreau>Is anyone working on updating to GNOME 3.32? <nckx>str1ngs: Sure. My point was more that ‘guix build nomad-local && git push foo $CHANGES:nomad-local && guix build nomad-local’ will silently return the old nomad-local on your development machine (because the hash hasn't changed so Guix assumes nothing else has), but fail with a hash mismatch on another (that doesn't have the old build). Is that clear? Again, all fine as long as it's just you testing stuff ☺ <nckx>If it's just a work-around for file://, I guess that's what it is. <kkebreau>I see we have a wip-gnome3.30, but I don't know if the GNOME 3.32 updates should go there? <str1ngs>nckx right, I am aware. this will not be an issue once I do tarball release. I could then confidently just have a nomad-git package. but the software is to alpha for even tarbal releases yet. I agree not idea. but I need some way to test unstable vs stable. <nckx>Just don't get bitten by forgetting to change the hash and wondering why your bug still exists. <recj>for some reason, some fonts that i installed do not show up when trying to select a font in emacs <vagrantc>dongcarl: it's been a while since i've tried cross-compiling on guix ... did a bit with aarch64 and armhf a while back when working on u-boot and arm-trusted-firmware <str1ngs>nckx: I could resolve this by using a commit hash instead I guess <kmicu>Geez, after a month 35302 is still not merged? <nckx>recj: Have you ‘fc-cache -r’d? <nckx>str1ngs: It'd be more tedious to update but more obvious if you'd forget. 's Totes up to you. Just wanted you to know the risks. <kmicu>katco is probably our only active SBCL user so The Elders of Guix (folks with commits rights) bless us with a merge pretty please. <nckx>‘Live SCM’ packages on Guix will always be tedious because of the hash. <str1ngs> I still think sha256 will catch this issue you are reffering too <katco>kmicu: there are a few others :) <recj>lol, once i did that it works nckx *kmicu thinks that opportunistic merging&reverting is still better (and more kind and respectful) policy than no feedback at all. <nckx>str1ngs: Maybe git-fetch is cleverer than url-fetch, but if I change the tarball url of a package I have already built to ‘https://obviously-invalid.com/foo.mpeg’ and ‘guix build’ it, it will happily print the existing store URL. It won't redownload what it thinks it has, and that think is based only on the hash. <nckx>Anyway, enough from me on that. <str1ngs>your input is appreciated, I will mull on this more. thank you <nckx>kmicu: I get your irritation (a form of enthusiasm, after all?), but by the same logic I can say that asking ‘Hey, could someone perhaps review <clickable link>’ is much more kind & respectful than ‘Geez, after a month <magic number> is still not merged?’ *nckx not volunteering, sorry. <katco>nckx: sorry if this is not the case, but is that a comment about how i brought this up? <nckx>I was quoting somebody else above. <rekado_>kkebreau: I should merge gnome3.30 into core-updates soon. A new gnome3.32 branch should be based off of gnome3.30 — once it has been rebased onto core-updates. <recj>so as a general principle, rescan if fonts don't show up? <rekado_>kkebreau: I haven’t been able to allocate enough time to do this. You’re welcome to give it a try and push it to core-updates (unless mbakke has something against touching core-updates at this time). <kmicu>nckx: that’s not an irritation. If there is no objection after a month and a patch is about non-critical leaf package then by not merging Guix discorouges contributions. <katco>nckx: 35302 is my patch. i haven't been following up on it because i've been spiking on other things. i brought it up a few other times here, but i probably should have sent an email to devel. sorry about that <nckx>And comments like that discourage reviewers. It's a both-way street. <kmicu>And Guix/Nix is immutable, we can afford opportunistic merging. *nckx disagrees but whatever. <kmicu>There is a lot of bumps to packages in Guix that are not properly tested. That’s a double standard. <rekado_>katco: sorry about not merging it (or commenting on it). I really haven’t been able to make enough time to keep up with patch review. <nckx>kmicu: That may be true but it's not relevant. Two wrongs do not make a right. <katco>rekado_: no worries at all, everyone. i know all too well how hard it is to keep up with projects that are not your day job. <rekado_>katco: you are welcome to ask Pierre and Andy about this, who both seem to have worked on CL things in the past. <katco>i believe i have spoken to Pierre about this <katco>maybe i forgot to point them to the patch <rekado_>katco: if it seems like your patch was forgotten chances are that it fell through the cracks, so pinging (after a week of silence) is totally acceptable. <kmicu>^^ such simple things like ‘pinging after a week/month of silence is acceptable’ policy for contributors is much appreciated. Thank you rekado_ *kmicu is sometimes afraid to bother/highlight core maintainers. <rekado_>ISTR that we state as much in the contributing docs. <nckx>kmicu: Don't be! Just… avoid ‘geez’. 😛 <kmicu>nckx: Ar a Rick&Morty viewer I refuse to avoid geez. <rekado_>it’s fine when done within a reasonable time frame; I get uncomfortable when people ping me after two days (and on stuff that isn’t my “core expertise”). <nckx>str1ngs: local-file might be useful if you don't care about it not being a ‘pure’ checkout, i.e. git/. It adds files to the store, so the daemon would see them, but I haven't tried using it in SOURCE myself. <civodul>it looks like the reviewing delays have increased <civodul>or at least the patch queue has grown :-) <rekado_>mumi isn’t helpful enough. How about hacking on it next week to make it more useful for reviewers? <civodul>i think currently committers are +/- fine with the tools <rekado_>reviewing itself is not a tool issue, but keeping an overview is. <civodul>but maybe one naturally tends to prefer spending time on their own code rather than review that of other people :-) <nckx>Pinging after 2 days isn't pinging; that's flooding. <civodul>rekado_: yeah, i agree that having a good overview can help <rekado_>I’d like to work on forgotten patches, but I can’t see them in mumi. <kmicu>Sometimes folks assume that you can only review if you have commit rights. <rekado_>(I used to have some code there to list them, but debbugs didn’t like it) <str1ngs>nckx: I was hoping that would work too. but I'm building manually as well. so it requires cleaning. I think the best approach is to push to a testing branch. and the use that commit hash in guix-local.scm. I think that's a good compromise for now. later when I actually release tarballs. I wont have to worry about this at all. <civodul>i can see forgotten patches in debbugs.el, my screen is full of them! ;-) <rekado_>so I usually rely on my mailbox, which is overflowing <rekado_>so I pick something from the first three or so pages, something that’s not WIP <rekado_>usually something by a first contributor <str1ngs>nckx: this way I have a unstable hash. and a stable hash <rekado_>and then it’s 11:48pm, all of a sudden! <ngz>Maybe a "Reviewing guidelines" document would help people getting confident in their reviewing skills, and help more? <nckx>gnu/packages.scm:493:9: In procedure %find-package: In procedure private-lookup: No variable bound to print-diagnostic-prefix in module (guix ui) <nckx>Is my checkout f'd up or can someone reproduce this with ‘guix build bogus’ on master? <nckx>ngz: I'd review that patch ☺ <ngz>nckx: beware the infloop <kmicu>ngz: Guix manual mentions ‘review’ handful of times so that would be helpful. Cuz what is an expected ‘review’? I’ve pulled patch locally and it compiles? Writing ‘LGTM’? And so on. <ngz>kmicu: Indeed. Also, some tooling could help, e.g., applying patch locally in a single command. <kmicu>(What about the process? Install Emacs, go to debbugs.el? Spawn browser go to Mumi instance?) <str1ngs>rekado_: this is git only right now. and I can't have name clashing <g_bor[m]>sway starts, but it fails to do anything... I will investigate it further. I got two messages, one relating to xwayland can't bind to socket, which seems to be because desktop services starts up X, and a failed to connect to user bus from swaybar <ngz>I once tried to do some superficial reviewing, but the user providing the patch expected more involved checks, so, at the end of the day, my help was ineffective. <nckx>g_bor[m]: How do you start Wayland on (I presume) Guix System? <rekado_>ngz: we can download patches from mumi and then use “git am” on the file. Having a little Guile script in etc/ to automate this would be neat. <str1ngs>rekado_: this is the same effect as --commit= but more declarative <nckx>kmicu: Bonus points for writing only ‘LGTM’ under a 700-line patch. <ngz>rekado_: I was more talking about handling patch series. I can also apply a single patch from Gnus. *nckx avoids ’LGTM’ exactly because ‘L’ sounds so cursory. <g_bor[m]>nckx: as of now I do not do it explicitly... <g_bor[m]>I guess that dbus-system provides the services... *nckx doesn't know either. <civodul>it's related to the kind of tooling that cbaines envisions for code review <civodul>there's already code to create branches for patches sent to the list <civodul>we could reuse the same code to build tools like "guix am" <ngz>What code are you talking about? This doesn't ring a bell. <civodul>the Patchwork + Guix Data Service thing <ngz>It sounds promising, even though I don't think it includes a CLI interface <g_bor[m]>nckx : yes, it seems that you just start a compositor, and that's all. It should work. <recj>hjjhso what is the situation with qt and qt-webengine <str1ngs>but the requirements to include chromium where to much for me to maintain at this time. <str1ngs>it required significant amounts of reworking gn build system to use guix libraries. like ungoogle-chromium does <g_bor[m]>nckx: ok, it seems to work fine, I just had to install rxvt-unicode to have a terminal. The mod key is bound to the Fn key on my keyboard, it took me a while to find that out. I did nothing special, simply installed sway as a user package, and starting it from the command line as sway, after logging in from the terminal. Now I will have a look at desktop-services to see what I can eliminate safely. <xavierm02>When I guix pull with two different users, the only thing that the second one does (aside from wasting time) is changing the "current" symlink, right? <recj>i would like to package anki but i think it depends on qtwebengine <str1ngs>and I'll be quite frank, it's probably not needed because qt is probably doing right thing. <str1ngs>recj: I have a qtwebengine channel with substitutes if you need it <str1ngs>but for me since I'm the maintainer of the project I needed it for. I just opted to use GTK webkit instead. thus avoiding have to maintain qtwebengine and chromium source base. <xavierm02>g_bor[m]: If it's like i3, you need to put it in the packages in the .scm you guix system reconfigure with if you want it to appear in gdm / slim / whatever you use to log in. <recj>so that i and other users can install it easily <recj>i'm also trying to package mozc, google's japanese ime <str1ngs>recj: here's the ML thread for qtwebengine <recj>this is what i have so far for that... i'm not too sure about the build system because they recommend using docker to build it with some image <str1ngs>recj: also I have a substitute server. the builds can take some time . if you need it <str1ngs>server dns name is same as public key