<KarlJoad>Does anyone here use Guix to use StumpWM & its contrib modules? I want to double-check if I need to define a new stumpwm package myself to integrate the contrib modules I want before I start working on it. <sneek>KarlJoad, you have 1 message! <muradm>for (substitute* fn (("some-word") "another-word")) how to match beginging of some-word? <KarlJoad>muradm: substitute* uses regular expressions, so "some-word" will match literally in your example. <muradm>KarlJoad: yes i know, i was meaning how to do something like "\bsome-word" <muradm>i want to match " some-word" but not "[A_5]some-word" <KarlJoad>So you want to match "some-word" including an arbitrary amount of whitespace from the beginning of the line? <singpolyma>If they don't but have capture you could use (\W)some-word replace with \1other-word style thing <KarlJoad>You could construct a regex like "[\s,;]*some-word", where \s is space. My knowledge of Guile regex is limited, so you may have to tinker to figure out exactly what you need. <zamfofex>muradm: Should the word be anywhere in the line, or only at the start of the line? <zamfofex>Maybe you need to escape the backslash: "\\bword" <johnjaye>does guile regex use the same regex engine as in gnulib? <muradm>zamfofex: it can be anywhere in line <podiki[m]>is parse-command-line a guix function? or part of guile (not finding it in guile docs, but always tricky to find things there; not finding definition in guix) <podiki[m]>e.g (package-inputs <packagename>), or (package-inputs this-package) I think <char[m]>Hello Guix! I'm trying up update ghc and especially cabal-install. I was redirected to this issue https://issues.guix.gnu.org/issue/47335, but I cannot find a ghc-next package anymore. Does anyone know what is the current state of the -next packages? (especially relating to ghc) <whereiseveryone>char[m]: I would maybe send your message to guix-devel@gnu.org if it doesn't get answered here <jackhill>char[m]: I don't know, but you may also be interested in the more recent Hasekll update effort: https://issues.guix.gnu.org/54729 and the wip-haskell branch. It seems that effort might be stalling out and could use some energy :) <char[m]>jackhill: Thanks, I should have really checked for this first. <jackhill>char[m]: no worries. I remembered the existance of that issue right off the top of my head for some reason. The hive mind is what the channel is for :) ***scisssssssors is now known as unwox
***unwox is now known as scisssssssors
***scisssssssors is now known as unwox2
***unwox2 is now known as unwoxx
***unwoxx is now known as scisssssssors
***scisssssssors is now known as unwox
***unwox is now known as scisssssssors
***scisssssssors is now known as unwox
<unmatched-paren>podiki[m] i think parse-command-line is either in (guix scripts) or (guix ui) <podiki[m]>thanks, don't think I found it but managed to stumble through :-P <podiki[m]>in cool news, I think I have a local `guix shell --fhs` that basically works... <podiki[m]>sets up a /lib, builds an ld cache, and at least one test thing runs so far <podiki[m]>actually not many lines of code, since the needed stuff is out there in various places <efraim>I've never been greeted like that by sneek :/ <PurpleSym>char: I’m currently trying to improve the Hackage/Stackage importer, so we can run updates on the Haskell ecosystem more easily. That’s why the wip-haskell branch is “stalled”. ***tassos[m] is now known as tas-sos
***califax_ is now known as califax
<cnx>hi, how do i disable the bell via the config? <civodul>i don't remember how to fill the dots though <cnx>thanks for the pointer, civodul <yarl>Does someone hav any experience with gnu artanis? <yarl>I saw it and found it interesting, guix installed it, but can't get it working. <yarl>That might be misconfiguration. <yarl>Would anyone be so kind as to try the package? <yarl>You'll have to mkdir /etc/artanis and touch /etc/artanis/artanis.conf <civodul>seems to work for me (in "guix shell -C") <yarl>And you can curl 127.0.0.1:3000/index.htlm? <civodul>i get a default page that reads "no index.html but it works!" <civodul>and i can see the HTTP requests/responses logged <yarl>Can you copy-paste the complete guix shell command please :) ***wielaard is now known as mjw
<yarl>Ok, I ran `guix shell -C -N artanis guile coreutils` <yarl>Then `mkdir /etc/artanis` then `touch /etc/artanis/artanis.conf` <yarl>Then `guile -c "(use-modules (artanis artanis))(init-server)(run)"` <yarl>`wget 127.0.0.1:3000` gives me 'HTTP request sent, awaiting response... ' <civodul>perhaps the scheme has to be explicitly given, who knows <unwox>"no index.html but it works!" <unwox>I do "guix shell -C coreutils artanis guile curl", then inside container "mkdir /etc/artanis && touch /etc/artanis/artanis.conf && guile -c "(use-modules (artanis artanis))(init-server)(run)" <unwox>i call curl inside of the container, this might be the difference <florhizome[m]>it uses gnu make + autotools. Right now it fails in the bootstrap phase because the generated configure script has the /bin/sh shebang <unmatched-paren>florhizome[m]: i had that once, seems like a badly written configure i guess <CA_RIA>Hello, can anyone help regarding installing new kernel ? How to query repo ? Thank you. <unmatched-paren>florhizome[m]: I think you might be able to add a patch phase after 'bootstrap <unmatched-paren>i'm fairly sure 'bootstrap is the phase where configure is generated <unmatched-paren>and by badly written configure i meant badly written configure.ac :) <florhizome[m]>./autogen.sh: ./configure: /bin/sh: bad Interpreter: no sich file or directory *unmatched-paren looks in guix source code <ngz>Hello. I'm struggling a bit with a Texlive package (halloweenmath). I wrote a package definition, but build fails. I'm not sure why. The definition is here <https://paste.debian.net/1246845> if anyone feels like helping me :) Thanks! <ngz>Neither do I, mostly. <unmatched-paren>Yeah, it looks like the patch-shebangs regex matches the case of whitespace after #!... <unmatched-paren>(make-regexp "^[[:blank:]]*(/[[:graph:]]+)[[:blank:]]*([[:graph:]]*)(.*)$") ***unwox is now known as scisssssssors
<efraim>autogen.sh tries to run configure, but it hasn't been patched yet. Add a phase before 'bootstrap to delete autogen.sh <efraim>or replace 'bootstrap with (lambda _ (invoke "autoreconf" "-vfi")) <cnx>how do i install the latin modern font (texlive-lm doesn't seem to expose the font) <unmatched-paren>efraim: I guess 'configure does patch-shebangs on the configure script before running it? <efraim>the problem is the 'bootstrap phase is also running ./configure because the autogen.sh script is trying to be too clever <efraim>I don't remember the specifics of the order to be honest <efraim>after bootstrap comes patch-usr-bin-file and patch-source-shebangs and then configure <efraim>in (guix build gnu-build-system), around line 870 <ekaitz>ugh problems... guix build tcc fails <ngz>"make[1]: *** [Makefile:103: test3] Error 139" <ekaitz>I had a package done to build tcc from source and now it's failing too lol <ekaitz>I'll debug this issue a little bit <ekaitz>also when I try to guix time-machine I'm having issues <ekaitz>failed to produce output path `/gnu/store/libkj3vb4hv031lf3qckqjmh8kpn890w-guix-package-cache' <civodul>check "guix build --log-file /gnu/store/libkj3vb4hv031lf3qckqjmh8kpn890w-guix-package-cache" <ekaitz>civodul: unsupported manifest format <civodul>yes, so it's the issue above, now fixed <civodul>so you can pull to current master, and from there time-machine will work <ekaitz>civodul: alright lets give that a go <civodul>or you can run "guix time-machine -- time-machine --commit=THE-OLD-COMMIT -- COMMAND" :-) ***scisssssssors is now known as unwox
***unwox is now known as scisssssssors
<civodul>(where the first "guix time-machine" goes into the future) <ekaitz>so I time-machined and tcc was broken back then too <unmatched-paren>ekaitz: yep, i noticed that tcc failure a while ago, forgot to report it <ekaitz>hopefully I may have a correct package... we'll see <PurpleSym>Is there any way to convince `open-pipe* OPEN_READ` to use a user-defined pipe as input? I tried `with-input-from-port`, but stdin is just empty. <ekaitz>civodul: I have a working package for `mob` branch <ekaitz>but I don't know if it will work for the release branch <ekaitz>btw tcc people is preparing a release <ekaitz>civodul: their master branch is called mob (idk why) <civodul>PurpleSym: by default, the child procss created by open-pipe* inherits current-input-port, provided it's a file port <civodul>but 'open-pipe*' doesn't return a file port; it returns a wrapped port <civodul>we really need to provide better facilities in that area <PurpleSym>civodul: But since it would use `current-input-port`, wouldn’t `with-input-port` affect where it’s reading data from? <ekaitz>oh my tcc package is worse than I thought -> #tests? #f <davidl>I want to compile qemu with --enable-hvf but this gives an error that I need appleframeworks which can be installed via NPM package manager. Can someone help me add a qemu build phase that downloads appleframeworks using npm? <davidl>related question: anyone who has experience using guix on MacOS? <davidl>how do you add network connectivity to a build? <AwesomeAdam54321>davidl: The build environment shouldn't have build connectivity, it needs to specify all it's dependencies packaged in guix <fnstudio>hi! i get an error while building bash_profile (actually when running 'guix home container file.scm', which contains bash as a package), the error says: 'ERROR: In procedure %resolve-variable: Unbound variable: ignoreboth' <fnstudio>efraim: yay, exactly that!! thanks, i was missing quotes (and now i feel a bit stupid for not spotting that myself before asking!) - ty ty ty!! <efraim>fnstudio: no problem. It sounded like a setting I already had :) <fnstudio>loosely related to the above, i was have a look at the guix home repo last night and there's something that caught my attention in the way XDG paths are used <fnstudio>does this mean that, if using bash, i need to define XDG_CONFIG_HOME before using it in my bashrc? <fnstudio>(either define it or extend the service with 'home-xdg-configuration-files-service-type') <fnstudio>i'm building my work-in-progress home in a container now, to see whether that's the case <florhizome[m]><efraim> "autogen.sh tries to run configur..." <- ok, I’ll try this <fnstudio>XDG paths are configured automatically in my bash, apparently, no need to do anything except using 'home-bash-service-type'/'home-bash-configuration' <char[m]>PurpleSym: are you improving the haskell importers on wip-haskell branch or somewhere else? <PurpleSym>char: No, most of it is already part of master. But I’m stuck with parsing cabal files, so I’m currently trying to call an external Haskell program, which does the parsing. But that’s just a local development version. <ekaitz>civodul: I tracked the tcc build issue and I found a working tcc commit, but the more recent ones have another error lol <ekaitz>should I send a patch with that? it's not a release, but... better that than a broken package <char[m]>PurpleSym: very cool. I guess writing a cabal parser in guile would be too chaotic? <PurpleSym>char: There already is one in guix/import/cabal.scm, but it has issues with indentation-based layout, which are – as far as I see – not easily resolvable. Also it’s very difficult to understand that code. <podiki[m]>sneek: later tell apteryx I have a working `guix shell --fhs` command in my local checkout, uses glibc with standard ldconfig usage, generates ldcache, runs my random test case of rustup plus big rust package compile <ekaitz>does Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS sound familiar to anyone? <ekaitz>i'm trying to ./pre-inst-env guix build <ekaitz>i'm trying to build a simple package but my cpu is at 100%, I don't get any feedback from the command and ends with that error <ekaitz>i tried with different programs but get the same output <ekaitz>i tried with coreutils, make, and tcc <ekaitz>but I suspect that any program will have the same behavior <ekaitz>so it must be that I screwed up with a patch? <ekaitz>yarl: I just changed the origin of a package, this should not happen just with that <yarl>ekaitz: ask someone who knows guix more than me ;) <yarl>civodul: Again on artanis. I assume you use x86_64? Could it be the fact that I use aarch64 that mess up something with epoll? Could you take a quick look at https://paste.debian.net/1246882/ please? See it is stuck before I do ^C . <ekaitz>but it never does the check, there's some kind of circular thing that ends up allocating a heap that is too large <ekaitz>but I didn't change the inputs of the package or anything that should break it like this <ekaitz>does anyone see what's wrong with the diff? <civodul>yarl: yes, i'm on x86_64; maybe you should bring it up with upstream developers? <sneek>apteryx, you have 1 message! <sneek>apteryx, podiki[m] says: I have a working `guix shell --fhs` command in my local checkout, uses glibc with standard ldconfig usage, generates ldcache, runs my random test case of rustup plus big rust package compile <GNUtoo>hi, is it possible to change the packages used in a build system with package transformations? *GNUtoo needs a patched android-make-stub <podiki[m]>apteryx: thanks! I was gonna send a (long, probably) email to guix-devel to discuss what we want and some technical choices to make, but wanted a working example <podiki[m]>apteryx: the code is pretty minimal actually, though I'm sure I found the dirtiest way to do things rather than properly :) <apteryx>OK! At the very least it'll be a good starting point :-) <podiki[m]>figure it is nice to have a tldr: here's some code you can try <podiki[m]>do you have an example use case? I wanted to provide a few examples (I don't know rust at all so the rustup + project I tried was just random, but worked) <GNUtoo>ekaitz: there are configuration related to epoll, though I'm unsure if your issue is related to epoll or not <GNUtoo>"You may choose guile inner server which is weak, but useful when you are running Artanis on an operating system lacking key features to run Raganrok. For example, in GNU/Hurd, which has no epoll." <apteryx>podiki[m]: probably too involved, but in the past I thought it could be used for running buildroot for example <yarl>GNUtoo: I can try simple server. (I'm using linux) <podiki[m]>apteryx: not familiar with that, but I think I have the bones for the container to look like any "regular" linux env *civodul renewed the disarchive.guix.gnu.org certificate <civodul>for some reason, our certbot job seems to be gone <yarl>GNUtoo: Yes this works with "server.engine = guile".. <GNUtoo>strange, at least that narrows down the issue <yarl>Anyone here using aarch64? *GNUtoo tried arm 32bit long time ago but at some point I had boot issues, so I stopped trying <GNUtoo>Maybe pasting the configuration would also help <GNUtoo> "The trigger mode of epoll. Please read epoll man page to know more. <johnjaye>yarl: depends what you mean by 'using'. i have a raspi 4 <johnjaye>but i don't think guix has a raspi build <GNUtoo>The free bootloaders for the raspberry pi are also probably outdated in Guix <GNUtoo>There is now an lk plugin based bootloader that is also free software and that has more support than the previous ones <vagrantc>civodul: i think it we even have the other logo somewhere ... might need to just look for all references to it <GNUtoo>rpi4 is untested according to the status though <apteryx>rekado: Happy Monday! Any update from the MDC, regarding that 'no route to host' problem? <podiki[m]>while I'm here, anyone else have any thoughts, use cases, etc. for an fhs-like container (guix shell --container with things looking like more typical linux) <johnjaye> GNUtoo i don't really get what you meant <johnjaye>as in the free bootloader is fine just hasn't been integrated into newer guix/ <GNUtoo>It might be a good idea to integrate in guix, assuming people have the time to work on it <GNUtoo>Once integrated that might enable to create images with it *GNUtoo can't do it as he doesn't have raspberry pis <johnjaye>ok. i have pis but don't really know where to start creating a bootloader <GNUtoo>There is something in gnu/packages/raspberry-pi.scm, though it might be more complicated to do for the newer bootloader <johnjaye>i feel like learning stuff is bootstrapping in itself sometimes <johnjaye>where like. you already need to know something before you can learn it <GNUtoo>Learning often has that issue indeed, teacher try to do recursive courses because of that (like "assume that this is true for now") <GNUtoo>Here though there are working examples with grub and u-boot <GNUtoo>(though grub and u-boot examples are only useful to make images) <johnjaye>if you assume such and such you don't actually know if that is covered somewhere or is possible to be 'bootstrapped' *GNUtoo typially reads the code and play with it until he manages to understand it but it can often take quite some time as I'm new to Guile <GNUtoo>Especially for stuff like making images or services <GNUtoo>Packages are usually easier to make <GNUtoo>For services there are things, for making images I'm not sure <GNUtoo>Though I also had to read code and do tests for services <johnjaye>ok. service to me implies some kind of runit/systemd/sysv type thing <GNUtoo>It could be useful if there is a config file <GNUtoo>Basically Guix is a bit like OpenWRT or LibreCMC <yarl>GNUtoo and johnjaye : I am actually using GUIX of foreign distro, did not take the time yet to try to run it on top of pinebook pro :) <GNUtoo>These 3 distributions are a bit special: if you want to run Nginx, you are not expected to write an Nginx config files but to use Guix configuration system <GNUtoo>For OpenWRT/LibreCMC there is also an abstraction with their own configuration files <GNUtoo>So that's why we need to sometimes add support for things inside the Guix configuration system <GNUtoo>For instance if you generate an image, you can configure grub through Guix instead of learning how to use grub directly, that makes things more simple <GNUtoo>The downside is that it takes more time to make it work well, as contributors need to abstract the config file in guix <unmatched-paren>There's also home services, which are for services that don't need to be run as root <GNUtoo>hmm, for my issue the following didn't change the build system's android-make-stub: (modify-inputs (package-native-inputs _libsamsung-ipc-gcc-android) (replace "android-make-stub" patched-android-make-stub)) <GNUtoo>Everything is a bit tied together in guix, so we don't have the same separation between things than regular GNU/Linux distributions <unmatched-paren>Basically, Guix "services" are modules that you can plug into your system that extend it. <unmatched-paren>You could make e.g. an aerc home service that does nothing but translate a Scheme-based configuration into an aerc.conf and drop that in ~/.config. <johnjaye>also on the topic of bootstrapping learning. sometimes it feels like you can't learn a tool in the abstract. like say sed. you can only learn it in relation to a specific problem <johnjaye>as in, i have to use sed to change dates from german to american format <johnjaye>like imagine reading the entire sed manual and thoroughly understanding it. but then you can't actually do anything with it <johnjaye>on the other hand. i feel if i thoroughly understood guile scheme right now, i would have a lot more options in guix <johnjaye>yeah. like if someone read that webpage they could immediately start hacking on gu ix <johnjaye>as opposed to stuff in general where you can read the manual but still be stuck <unmatched-paren>which is actually really quite interesting and useful, though i don't think it's a good place to start <johnjaye>i like the honesty in footnote 2. lisp languages are very bad to work with if you don' have emacs or some kind of indentation engine <johnjaye>so in a sense it's probably rational for people to be afraid of lisp <unmatched-paren>the Guile manual, for example, thoroughly explains the various Guile extensions <johnjaye>i had to hack emacs to display 2 levels of parentheses highlighting and even then i still have trouble sometimes <johnjaye>yeah i saw ice-9 in the scroll output a lot. is it a guix thing/ <johnjaye>that's one thing that annoys me about gnu projects in a way. extensions that may or may not be portable and recognized elsewhere <johnjaye>(i just got done reading an article about how gnu sed and find subtly differ in lazy regex matching from bsd sed and find *unmatched-paren does not the emacs <johnjaye>right. i gathered the r5 vs r6 split was bewteen people that wanted minimalism for teachign and engineers that wanted deliverable products <johnjaye>kind funny that i side with the academics on this one but not on c compiler undefined behavior where the behavior of UB is so elaborate you can't actually code with them <unmatched-paren>johnjaye: r6rs vs r7rs more like. A lot of people mocked r6rs as being closer to Common Lisp than Scheme, apparently. ***Dynom_ is now known as Guest599
<johnjaye>yeah in the sense that UB is making the compiler reach the widest possible among of architectures, even fictional ones with 9 bits per byte or int that isn't 32 bit or something <johnjaye>when it would be more practical standardize on say 8 bits per byte or at least try to give copious warnings if you're eliminating someone's code because it fails in the case of 9 bits per byte <unmatched-paren>Today we've standardized on things like byte size and text encoding, so modern languages like Hare and Zig are safe to make many more assumptions. <unmatched-paren>(for example, the Hare spec forbids input charsets other than UTF-8) <unmatched-paren>johnjaye: Also, I've heard there are still embedded machines with non-8-bit bytes. <johnjaye>heh. this article on hare degenerated quickly into arguments about zig <unmatched-paren>For some reason they're both pretty controversial, probably because they aren't Rust. <unmatched-paren>And it's even possible that Hare will be like Rust; they are planning to experiment with adding a borrow checker! <unmatched-paren>(Which, in my humble opinion, should be called the 'burrow checker' :D) <johnjaye>maybe i'm naive. but i would think c/go and c++/rust are serving different domains <johnjaye>as in you want a simple language without memory management etc <unmatched-paren>johnjaye: well, the point of Rust is 'like C++ but without bothering with memory management' <mitchell>Does anyone know what group i need to be in to run `dmesg`? <unmatched-paren>The problem is, it's too much like C++ :) It should be entirely possible to have a simple C-like language with a borrow checker. <unmatched-paren>And that's what Hare might be, if they figure out a good way to do it. <mitchell>on ubuntu i used to be able to run dmesg without sudo <unmatched-paren>johnjaye: C, C++, and Rust occupy approximately the same problem space <mitchell>unmatched-paren: where do you draw the boundry? <unmatched-paren>mitchell: In my opinion, a language with a GC is not a systems language :) <unmatched-paren>(Rust specifically chose not to use green threads because they are unsuitable for a systems language with a small runtime.) <mitchell>unmatched-paren: C++ has gc, albeit conservative and optional. If they were optional would it change your opinion? <mitchell>C and lisp cover all my programming needs ***mark_ is now known as mjw
<unmatched-paren>For me it's C, Scheme, ML, and possibly Hare might replace C eventually :) <johnjaye>perhaps those areas are fuzzy though. like garbage collector, threads, network <johnjaye>how much of those do you need before it's not a systems lang anymore <unmatched-paren>Threads are fine, _green_ threads (lightweight threads implemented in the language runtime) less so. <unmatched-paren>If C++ did have a GC i might not actually consider it a systems language anymore... At least, if it's commonly used. <johnjaye>that's a bit weird to me also. that a systems language would continually get updates and feature changes like that <unmatched-paren>D is effectively 100% a GC language because basically zero libraries use @nogc. <johnjaye>at some level you want confidence code you write now will still compile in 10 years <unmatched-paren>johnjaye: Yeah, that's nice to know. C, Go, Hare, and probably Zig once it stabilizes provide that confidence, Rust, D, and C++ certainly don't <unmatched-paren>Go is still getting features (much to the chagrin of some, though slower than Rust does) but at least old code still compiles. <unmatched-paren>Actually, Go's gonna break compatibility at Go 2, aren't they? On second thought, mentally sed it out from that list :) <vivien>I experimented with a lot of programming languages, many being nice, but the final realization is that you want to code every important part of your program in C because it is compatible with any system, any library, and any other programming language. <mitchell>C++ is a nightmare. ABI compatibility through compiler versions is broken often. <unmatched-paren>though hare doesn't support shared libs because it'd require QBE to support PIC <mitchell>I watched my collegue lose a day trying to compile against a library only to learn it was compiled with gcc 5.2 which was not compatible with whatever version he randomly had. <vivien>The other argument is that C is an easy programming language to learn, so there’s nothing in the way if other people want to take it for their needs. <johnjaye>vivien: i used to not understand the obsession with portability some people had. now i understand <johnjaye>i even learn sed vi and awk not because i think they are good but simply because they are portable. that's it. <mitchell>johnjaye: At some point you get tired of rewritting the same code <johnjaye>right. the UB thing leads to unproductive arguments where one person says hey why does the compiler delete my code without a warning? compiler writer: because i can. the standard says so. ha. ha. ha. <johnjaye>mitchell: i call those hulk bugs because it makes you want to hulk out and start smashing things <vivien>johnjaye, in data science, you want to use the same tools in python, R, matlab, and java if you’re pushing it to production. There are folks doing fortran, but it’s not as common as C. <vivien>This is the kind of portability that matters to me :) <mitchell>In "software design for flexibility" sussman gives a bunch of examples of writing abstraction layers over existing tools like grep and whatnot. It's a good example of doing whatever you want while maintaining portability. <dominicm>Does anyone know how to use libcxx manually? When used in packages they all patch the gcc stdlib out of CPLUS_INCLUDE_PATH, but that doesn't really work in user profiles. <apteryx>is someone able to view PDFs in Epiphany? <dominicm>apteryx: at least a random one I tried on works <apteryx>that may be the reason why, I'm on a minimal WM <dominicm>ah, yeah probably. maybe a missing input? <dominicm>or maybe not, 'guix shell --pure epiphany' still works for me <alice[m]>hi, i just started exploring guix home (and enjoying it already)... something that's not completely clear yet is how to handle all stateful data and secret information (e.g. my mailboxes or my ssh and gpg private keys) <alice[m]>is it something that i need to account for in my home-configuration.scm file? anyone has an example i can refer to? <dominicm>alice: Not sure exactly what you mean, but guix home generally doesn't deal with stateful data. For instance, I use services for my mail/gpg/ssh configurations, but then sync my mail via whatever my imap command is (either manually or via mcron), and keep my private keys on a yubikey or external drive <dominicm>by definition, all data managed by guix home is read-only <mitchell>can someone explain the `maybe-` parts of `define-configuration`? Are they used for optional parameters, or just parameters with no defaults? <dominicm>that said, you can make it easier on yourself by having one piece of offline secret information (e.g. a gpg key), and then using that to decrypt all your other secrets on the fly <dominicm>apteryx: 'guix shell --container ...' is failing though, so it's probably relying on some global services <mitchell>dominicm: I keep a backup of my gpg key as a qr code in a safe. Perhaps it would be a fun exercise to make the computer take a picture of me holding it up before it can read anything. Then it'll never be stored on the disk at all. <alice[m]>dominicm: right, yes i understand the stateless part; but what i'm still missing is... if i create a home-configuration.scm file with all the stateless bits... when and where is it that i "inject" the stateful bits such as my private keys? <alice[m]>e.g. suppose i want to recreate my home from scratch after a disk failure <mitchell>alice[m]: You can reference them as with local-file <mitchell>just keep it in the same spot like .config/private on every computer <alice[m]>i reinstantiate the stateless part with guix home, and then i copy all the secrets file by hand? <alice[m]>so that all stateful info is restricted to that folder <mitchell>Yea so you can have a generic install process. You just have to manually make sure those files are there before you reconfigure <alice[m]>well, sort of... i guess... this already helped, thanks <alice[m]>i suppose i'll need to experiment with it a bit more <mitchell>dominicm: We could make a whole pam module <mitchell>I can keep a binder of certificates on the shelf <dominicm>mitchell: oh lord, imagine taking out a QR code for every email <alice[m]>dominicm: oh this is wonderful!! ty v much <apteryx>odd, 'guix build git --without-tests=git' doesn't seem to work ('check phase is run still) <johnjaye>do those hashes for /gnu/store/abcd... have to be 32 digits long/ <johnjaye>or is there some requirement that 16 or 8 digits would not meet ***stikonas_ is now known as stikonas
<civodul>what's the right incantation again to ban them? <two[m]>i see a /ban command in auto-completion ***cedb_ is now known as cedb
***ChanServ sets mode: +o nckx
*nckx looks up the name of the channel again... (one # or 2?) ***nckx sets mode: +b $a:crk$##fix-your-connection
<nckx>civodul: Do you remember how to do this properly? I seem to've forgot. <civodul>nckx: no idea! i think you told me in the past, i should take notes... ***nckx sets mode: +b *!*@*$##fix-your-connection
***nckx sets mode: -b *!*@*$##fix-your-connection
***nckx sets mode: -b crk!*@*
***nckx sets mode: +b crk!*@*$##fix-your-connection
<civodul>i guess "UX" was not a thing back when IRC was designed <nckx>My keyboard (AnySoftKeyboard) isn't the best TBH. <civodul>apteryx: are you looking at "make install-info" in Git or should i give it a try? :-) <nckx>Apparently, it's ##fix_your_connection. Indeed, civodul, the I in IRC stands for UX. ***nckx sets mode: -b crk!*@*$##fix-your-connection
***nckx sets mode: +b crk!*@*$##fix_your_connection
*nckx retreats back into being an incubator for wittle covidz. o/ <civodul>looks like it's gonna be our thing for the years to come <ekaitz>civodul: does it have any sense to break a tcc only by changing the source from url-fetch to git-fetch? <ekaitz>can that produce a weird dependency loop somehow? <ekaitz>why do I have this magnet for weird behavior? <civodul>ekaitz: could changing tcc from url-fetch to git-fetch break? perhaps, depends on how tcc is used in commencement.scm <civodul>at first sight it's ok because the tcc variants in commencement.scm override the 'source' field <ekaitz>commencement should have their own things... <ekaitz>I was changing that because the current tcc we provide is broken and the latest commit is not broken anymore, and wanted to fix it, but if I do, everything falls <civodul>also a description of what "fails" mean :-) <ekaitz>I did in the afternoon! try scrolling back :) <ekaitz>the diff I added is broken on purpose, but the hash is never checked, because it's lost in the dependencies <ekaitz>so it's not an issue of the package itself, but an issue with a dependency loop <ekaitz>also, it makes other packages fail to build with the same issue, it's not only tcc <civodul>ekaitz: ah no, see tcc-boot: it has (source (package-source tcc)) <civodul>that's why you get this circular dependency <civodul>so we can't modify tcc, but we could add a variant with different source/version <ekaitz>or duplicate the source in tcc-boot vs tcc <ekaitz>move the source to tcc-boot and add the new one on tcc <ekaitz>the problem with that is we have to maintain both packages <ekaitz>but the tcc package is not usable at the moment <civodul>right, duplicating the source is probably better *nckx removes a few phrases (such as 'ban' ☺) from their watchlist for now. Me barging into the room with tiny bleary red eyes and a shotgun is unlikely to improve any truly banworthy incident were one to arise... <ekaitz>civodul: okay then I'll do that and send a patch, thanks for the help! <civodul>ekaitz: it goes without saying that the failure mode in this case leaves room for improvement <johnjaye>how do i know which versions of gcc are commonly available on guix <Zambyte>johnjaye: I think this command is what you want: `guix package -A gcc-toolchain` <johnjaye>i ask because to get the raspi bootloader apparently i need to port vc4 build tools which involves a gcc6 cross-compiler <vivien>Dear guix, I have a feeling that I can fix bash cross-compilation issue, but most likely I shouldn’t try and fix it on master. Which branch should I target? <unmatched-paren>johnjaye: I think you should be able to use the `gcc-6` variable in scheme code <unmatched-paren>(which will show as `gcc@6` on the ui, since package variable != packages <vagrantc>vivien: depends on how many rebuilds your changes trigger <vagrantc>vivien: guix refresh --list-dependent PACKAGE <civodul>vivien: hey! that would go to core-updates, but often there are tricks we can use to avoid a full rebuild <civodul>like making the relevant code conditional on (%current-target-system) <ekaitz>can't the commiter.scm add too files at the same time? <sneek>Welcome back clever, you have 2 messages! <sneek>clever, ArneBab says: I think that’s an implementation artifact, which would be nice to have different <sneek>clever, ArneBab says: I typically have the guile ref info manual open, and that actually works <rekado>apteryx: someone needs to plug the thing into the other thing to make the thing go beep <rekado>currently it’s plugged into the other thing <apteryx>haha, OK. Lemme know when the thing is supposed to be hooked right <rekado>I asked my colleagues if they would be in the data center some time soon, but my request kinda got lost in the noise <rekado>I thikn it’s the same rack even; it’s just plugged into the wrong switch. <apteryx>Good! That'll greatly help us I'm sure when the next fire is burning. <apteryx>I could also make sure the machine boots without any voodoo incantation for a start <vivien>civodul, I conditionally inserted compilation phases with ,@(if (%current-target-system) `(...) '()) but guix refresh --list-dependent still gives me thousands of packages, how do I know if this is working? <vivien>I guess the guix refresh output indicates it is not working, but maybe it is?