<ytc>hello. why is i3-wm package in guix repository very outdated? is it because of updated version is uncompatible with guix system or because of is it not well maintained? <ytc>i'm asking that because i am considering to write package definition. <lfam>It's probably because nobody tried to update it yet <lfam>It's not very outdated, not even 1 year <lfam>But, it should be updated <ytc>there are a lot of *popular* packages outdated. this makes me upset. <cossidini>no need to get upset. it's just a wm and probably easy to update <dstolfa>ytc: it's a bit of a best effort right now, people who use certain packages update them as they go. usually updating is as simple as just changing the version and the hash, so it's a 2 line change <dstolfa>but that's usually true for almost any distribution <cossidini>it's probably a great first attempt at updating a package if you're new to it. like dstolfa said, it's probably just two lines <lfam>The build system was changed in 4.19 <lfam>So, you'd also need to change that part. Hopefully a 3 line change overall <ytc>how can i add my custom packages to /etc/config.scm? <dstolfa>ytc: you can just import a module (gnu packages) and then use the (package ...) EDSL to define a package. alternatively, you could generate a lot of it with `guix import`, but if you're looking to just test a change to an existing package locally you should be able to just `guix edit` it <podiki[m]>....speaking of updates, can anyone here look at the libdrm and mesa patches for core-updates? i think they are good to go (been building and using both a lot) ***dragestil__ is now known as dragestil_
<oriansj>sneek: later tell civodul that live-bootstrap have guile and gcc 4.7.4 (both C and C++ backends) all properly bootstrapped (no pregenerated files unlike the current root) and it might make for a stunning release. <oriansj>Then we just need to teach Guix to build Debian's .debs and Redhat's rpms thus making guix the heart and soul of all major distros bootstrap/build processes. <oriansj>well guix does have the most ambitious bootstrappers of all. <drakonis>oriansj: well, it knows how to export to .debs! <oriansj>drakonis: but does it know enough to enable Debian to switch all of their builds to it yet? <drakonis>it exports to the format but it cannot parse the build instructions yet <oriansj>drakonis: we don't need to parse the Debian Build instructions unless we plan on building an importer to speed up the process of converting Debian to having a Guix build system. <drakonis>hmm, i dont think i understood the question then <oriansj>drakonis: the question is could guix given a list of packages to build and output in the .deb format that Debian expects. Is Guix currently able to do that? <oriansj>good, then we need only have the packages that make up the Debian core to be packaged in Guix <oriansj>after that Debian can pick up the load and get 100% reproducible and 100% bootstrapped from stage0 <drakonis>the exporting however, still yields guix's structuring <drakonis>making guix the backbone of other distros would be certainly something interesting to play with <oriansj>well guix and NixOS are the only two games in town which provide a universal build audit. <oriansj>So there are meaningful advantages to leveraging guix to instrument one's build servers and process. <drakonis>oughta convince them of the advantages of that <apteryx> note that the .deb is a 'guix pack' format; it's current application is to produce bundles rather than individual packages <apteryx>and dpkg doesn't allow multiple packages to share the same files, so currently only one such deb pack can be installed with dpkg (dpkg would error on a conflict upon trying to install a 2nd one). <MysteriousSilver>Any emacs user here? I've installed an elpa package from guix, and how do i load it in emacs without restarting it? <char>MysteriousSilver: check the recent reddit thread <sneek>Welcome back irfus, you have 1 message! <sneek>irfus, podiki[m] says: welcome! I figured separating out changes from the version update would make it easier to get merged, but still waiting to see what happens ***chexum_ is now known as chexum
<ecraven>I'd like to run guix-sd in proxmox as a system container. has anyone perchance already done this? <ecraven>promox uses lxc containers, so the correct question probably is: is there an lxc container of guix-sd? <muradm>hi, rarely i have to help people on windows, while i had arch, anydesk was working fine, now that it is only guix around, any pointer on packaged anydesk or something else as useful? <muradm>there are so much dependencies "not found" shown with ldd on downloaded anydesk <jlicht>What would be the `file-system' snippet I need to have /tmp mounted as tmpfs on Guix System? <tissevert>jlicht: hey, I hadn't noticed /tmp wasn't mounted <jlicht>I'd like to start 'saving' my SSD a bit, given that it probably will be a while before I can(cq should) update my computer again. <tissevert>jlicht: I think we can reuse the existing config for /dev/shm found in gnu/system/file-systems.scm <tissevert>(you can look for %shared-memory-file-system) <tissevert>although I suppose we don't need the create-mount-point option <jlicht>tissevert: thanks, seems reasonable :-) <tissevert>jlicht: you're welcome ! (I'm going to test it too) <boeg>So i want my hole system to be declarative. At the moment its all using a config.scm, but it's a bit of a toll having to keep it updated and reconfigure a whole new system when I just want to have some simple non crucial piece of software installed. So I have looked at guix home-manager which seems to be able to let me separate my base system from my "home setup". Is that what ya'll are using? Not using anything other than a config.scm? <boeg>Any other recommendations? <tissevert>still have to take some time to look into home-manager more in detail but it looks great so I will at some point <boeg>tissevert: alright, same boat kinda thing <boeg>alright, ill probably wait until its merged so refactoring of docs and so on are done and then give it a try <the_tubular>1.3.0 released not so long ago, so it might take a while for next release though <mange>Hey #guix! I'm trying to write an origin that will download a single file and mark it executable, so I can refer to it directly in a Gexp in an invoke call. I've tried using a snippet, but it seems to make tar explode in the builder. Is there some way for me to do this? <boeg>the_tubular: thats okay :) <mange>I guess I could use computed-file to copy the output of my other origin and make the copy executable, but it feels a bit messy. I assume that would also leave two copies in the store. <tissevert>the_tubular: I thought people were already talking about the freeze for next release ? Right after the release of 1.3.0, the first estimate date for 1.4.0 was in september, so it shouldn't take that long <tissevert>then, I assume this was optimistic and delay can always occur, but the main point I think is that the release cycle is pretty short <tissevert>I haven't been around long enough to say ^^ but it would seem so <tissevert>pretty much looking at the two past years: 1.1.0 was april the 15th 2020, 1.2.0 november the 22nd and 1.3.0 may the 11th ***darosior0 is now known as darosior
***duponin0 is now known as duponin
***jakesyl_ is now known as jakesyl
***dragestil__ is now known as dragestil_
***sneek_ is now known as sneek
***donofrio_ is now known as donofrio
<clemens3>hi, I have a sha256 base32 hash of an external tar file, but I am not a guix user.. how can I get this hash with standard linux tools instead to check my file? <mekeor[m]>clemens3: i think it's in coreutils but i'm not sure <mekeor[m]>clemens3: i think you can do it like this, if the hash is in the .sha256-file: `echo "$(cat archive.tar.gz.sha256) archive.tar.gz" | sha256sum --check --status` <clemens3>no properly formatted SHA256 checksum lines found <vagrantc>clemens3: you mean a guix hash compatible hash? i'm not sure how to do it without guix ... possibly with nix instead of guix, but obviously not really a standard linux tool *vagrantc wonders how feasible it would be to add support to sha256sum <clemens3>vagrantc: exactly.. i have the guix sha256 and i have the file, but i have not guix <dstolfa>vagrantc: not a stanard linux tool... YET *dstolfa mumbles something about guix and taking over the world <vagrantc>yeah, i had wondered how to do this but instead followed the path of uploading guix to debian :) <clemens3>so where is the minimal tool from guix or nixos that I can compile to get the base32 sha25sum then..? <vagrantc>you might be able to extract the guile code and write a guile script, if you consider guile standard enough <vagrantc>presumably nix has an implementation in C or C++ <dstolfa>there really isn't one i assume. i reverse engineered `guix hash` but the amount of pipes was unhealthy <vagrantc>it would be interesting to find a reliable "standard" way to do it <clemens3>so the hash is just build on the file content, or is the file name also used? <dstolfa>vagrantc: well i mean, the thing i wrote was using only standard utilities (sha256sum, base32, tr and i think sed), but it was painfully complicated <vagrantc>too many sources of network-based non-determinism <dstolfa>as in, doesn't fit on one 4k screen complicated <vagrantc>dstolfa: might be worth dumping into a shell script somewhere <clemens3>if i have a sha256sum-guix-style myfile might be handy <clemens3>base32 seems to work with upper cases and not lower ones <dstolfa>vagrantc: i'm not sure i have it anymore, i'd have to go off and reverse engineer it again <clemens3>dstolfa: so where is that guile tool/script then, i might have a look <dstolfa>clemens3: probably under guix/scripts/hash.scm <jlicht>which should have something like bytevector->nix-base32-string ***apteryx_ is now known as apteryx
<char>raghavgururajan: I saw something about gnome 41. Is there a plan to keep up up to date? <vagrantc>char: raghavgururajan had been working on it but it's a lot of work to keep up with gnome ... <char>How does AUR always keep up to date? <vagrantc>there are some things about guix that make it harder ... notably that *everything* is rebuilt when any of it's dependencies are rebuilt <vagrantc>and gnome having a lot of interdependencies... <clemens3>0cb02c763bc441349f6d38cacd52adf762302cce3a08e269f1f75f726e6e14e3 jikes-1.22.tar.bz2 <clemens3>is what i have locally, on the guix config it says: <clemens3>"1qqldrp74pzpy5ly421srqn30qppmm9cvjiqdngk8hf47dv2rc0c") <clemens3>because then the last c means decimal 12, not ***bandali_ is now known as bandali
<clemens3>does someone have the file in his local guix installation and can check the sha256sum? <clemens3>and btw, who has signed the shell installer script..? <clemens3>i mean, download this script, execute it as root, lalalal <vagrantc>hmmm... i vaguely recall that as having a signature path ... but maybe i'd only ever installed manually, which has signature verification <dstolfa>vagrantc: the script verifies the signature of guix, but i think clemens3 wants to verify the signature of the script itself <vagrantc>clemens3: that sounds worth filing a bug about <vagrantc>running a script with the verification instructions without verifing the script is a little dubious :) <dstolfa>it is, but it's a small enough of a script to manually inspect, though there should still be some way to verify its signature in the instructions <clemens3>there are some gpg keys/hashs inside, but then is already too late <dstolfa>clemens3: i reckon it's probably worth filing a bug <vagrantc>yeah, i think i once downloaded the script and more-or-less manually ran the steps inside it <dstolfa>vagrantc: yeah all my setup was done manually too, but not having some kind of way to verify the script for the less technically inclined users is not great <dstolfa>clemens3: could you please send an email to bug-guix@gnu.org and see what others think too? :) <dstolfa>i think it's worth investigating at the very least <lfam>The installer script is signed in the same way as the rest of the Guix code <lfam>Since, it is part of the Guix code <lfam>To be fair, that method of installation is for the people who don't care about signatures anyways <lfam>It's the "just do it" method <vagrantc>yeah, it's only slightly less bad that curl ... | bash <dstolfa>lfam: maybe the wording around "We recommend the use of this shell installer script" should be changed a little bit to clarify? <lfam>I leave it up to the others <lfam>I still use the (very simple) manual installation method <lfam>Authenticating the Git repo is done with `make authenticate` <lfam>I see the concern. I just wanted to point out that this file *is* signed <vagrantc>there's just no likely way someone could verify it given those instructions <lfam>I mean, who signs the web-based manual? :) <vagrantc>without pretty solid knowledge of guix already <lfam>Or the web site, at all? <lfam>It's a bit of tunnel vision IMO <vagrantc>and where do you get your DNS from, anyways? <dstolfa>lfam: a CA, essentially :), but there's no real good way around that without trusting your CAs. i guess some people just get a bit weary when they see a "download script and run as root" kind of wording <clemens3>the script downloads and installes a gpg key for further use.. <clemens3>i would prefer i install the key myself and check, be it here on irc or whatever, find someone who knows someone.. <lfam>I think the real reason that <https://guix.gnu.org/install.sh> is not signed out of band with PGP is that it's a dynamic link to the file in our Git repo, which eases deployment of changes and fixes <lfam>It could maybe be improved somehow, but this setup is largely in response to demands for a convenient "don't wanna read the manual" installation workflow <clemens3>in germany law went into effect for the government to install trojan software legally before you did anything wrong.. <dstolfa>to be fair, you can do that by following the manual installation on that same page (and the root of trust is the same, an https website, though one could argue that you could try to independently verify that the website you get is the same across multiple devices and so on more easily) <clemens3>or who checks https certificates.. I have done so maybe three times in my life <lfam>The whole point is that you don't have to check <lfam>The manual verification was shown to be a failure <lfam>It just didn't work for the billions of people using computers <dstolfa>poor johnny, struggling with encryption all the time <clemens3>yeah, but i don't understand or trust https either <clemens3>where did I get the root certificates or what from.. <lfam>I think that's okay, though. The point of computers is to do things for us that we can't do on our own <lfam>But, we should make a bug ticket about ideas for authenticating this installer script <lfam>There must be something that can be done to improve the situation <vagrantc>or at least being transparent about the process <lfam>I mean, I think it's transparent. Again, it's for the people who choose not to read the instructions :) <lfam>How to make things more transparent for those who don't read? <clemens3>lfam: where are the manual instructions, just to get an idea myself? <dstolfa>lfam: i reckon just saying: "Risks of running things as root... if you don't mind, run this for installation" <clemens3>that is manual or that is run the install script or both? <dstolfa>just for the less technically inclined people to understand the risks <lfam>I guess I think that warning less technically inclined people about obscure risks is not productive <clemens3>but i am quite technical and i don't want to fucking run it, fyi <lfam>Okay... the installation instructions are linked to from the Guix download page. <dstolfa>lfam: maybe you're right. i really don't know. i'm just suggesting things under the assumption that it's worth doing, but i don't know if that assumption is correct :) *vagrantc waves to monkwitdafunk <lfam>To me, one has to strike a balance between informing people and overwhelming them <vagrantc>yeah, a warning "this is dangerous! click ok" doesn't help much <lfam>That's basically how I see it <dstolfa>clemens3: short of meeting in person and exchanging a PGP key on paper, you are kind of stuck with https <clemens3>maybe time for me to dig into https and how reliable it really is <lfam>I would put it like this. The security of the USA consumer banking system largely depends on HTTPS. <clemens3>dstolfa: no, i can verify your key by saing here, give me the fith character of the hash.. <dstolfa>um, if your https connection is compromised somehow, why would irc work? <dstolfa>that means that your actor has broken TLS <clemens3>then my trust would be much higher than just downloading from a web page via https ***lfam is now known as dstolfa1
<vagrantc>lfam: i'm not sure that's a great confidence builder ... hundreds of thousands of credentials are leaked all the time :) ***dstolfa1 is now known as lfam
<clemens3>dstolfa: because someone had to read my text and parse it an interphere <monkwitdafunk>i have to use HTTPS to send my digitial documents to my doctor <dstolfa>clemens3: if someone managed to inject a malicious CA into your computer, it's not very hard <clemens3>well, your choice, i also downloaded and installed my share of software <lfam>If you are interested in the security of HTTPS / X.509, I recommend reading about CAA, CT, and HSTS <clemens3>is harder to inject some misguided pgp key into my ring <lfam>These are the recent inventions designed to really lock the system down <vagrantc>the problem with the CA system basically comes down to it is only as strong as the weakest certificate authority, and when too-big-to-fail CAs FAIL VERY BIG nothing really happens <lfam>vagrantc: That's what CAA and CT aim to address <lfam>Site owners can declare which CAs are allowed to sign their certificates, and CT is a blockchain (I know) of issued certificates that clients consult to check on misissuance <lfam>It's also not true that CAs are too big to fail <lfam>Symantec was forced out of business due to mistakes <vagrantc>letsencrypt at least removes one of the disincentives from using these things <vagrantc>lfam: is that certificate pinning by another name? <lfam>No, certificate pinning has been abandoned <vagrantc>anyways, glad to hear there are some things working on improving it <lfam>Now, things might start to get a little hairy with obscure clients. <vagrantc>i always got behind the ones doomed to fail (network perspectives, monkeysphere) <lfam>The big browsers and implementations get audited and tested constantly <vagrantc>anyways, i need to go socialize *in person* !!! <lfam>When I started doing Guix packaging, I found that some of the text-mode browsers didn't verify TLS, by default <lfam>In general, obscure clients are not tested and probably don't actually work *dstolfa would like a better signature/encryption system for email that is easier to set up for people so that it becomes a standard <dstolfa>... also one that doesn't require you to take care of your key for years <lfam>I think that is supposed to be signify <monkwitdafunk>i am guessing i need a hardware firewall before running guix <lfam>What do you mean, monkwitdafunk? <dstolfa>lfam: i guess one could use signify for emails too, but i don't see anyone doing it actively <lfam>dstolfa: It's only for signing, not encryption <dstolfa>well yeah, but at least having signatures would go a long way already <dstolfa>so you can't get fake emails from your bank that scam people, etc <dstolfa>making something like this ubiquitous and usable by people who know nothing about any of this, just so it can flag malicious emails more accurately would be a big win <lfam>This partially exists already, but it happens between email servers <lfam>If you use a big email provider, they are already filtering a huge number of messages for you. Maybe 10x the number of messages you receive dstolfa <dstolfa>yeah i know, but it's unfortunately not as robust as one would like it to be as my grandparents regularly get scam emails through even though they use gmail <lfam>It's a very challenging problem <lfam>The telcos are largely to blame for allowing the gigantic volume of spam calls <dstolfa>in the UK too... i've reported countless numbers already and months later i still get messages/calls from them <dstolfa>"Your parcel is being held, click this very suspicious link" <lfam>See, the US postal service doesn't even have your number and couldn't figure out how to call you even if you wanted them to. A win for chaos <dstolfa>possibly the most sophisticated, and i would even say targeted scam email i got was from a subdomain of barclays bank informing me that i can customize my new debit card as my old one is expiring. it went to a legitimate barclays login page, everything looked 100% legitimate except for the part where my debit card was cancelled by the bank months ago and i got my new one in the mail <lfam>Did you ever poke at it? <dstolfa>yeah, there was nothing there, it was just something alonge the lines of "customer.help.barclays.co.uk". most i did was email them asking if they sent the email and they said no <dstolfa>and there wasn't a spoofed address or anything <lfam>I guess you can put anything in the return address of an email <monkwitdafunk>i like the idea of keeping talk and text, seperate from the internet, as a seperate bill, and a seperate device <dstolfa>lfam: probably the scariest thing (and probably why they never told me anything about it ever again) was that whoever sent this email knew that my debit card was expiring within the month <dstolfa>i suspect barclays itself got partially compromised, i have no other explanation <dstolfa>well, expiring in theory anyway. it was replaced early so it already expired <monkwitdafunk>usually if you track down the address of where the MTA is that forged the email, a large hosting company would ot take screenshots <monkwitdafunk>as long as you dont suffer financial losses, that is all that matters my family says so there is no need to get worked up <lfam>dstolfa: They could also have gotten lucky with the timing. Maybe they targeted a large number of people at once <monkwitdafunk>i can even say that when a merchant declines a transaction, your bank may not even have records of that decline <- i forget what term the bank would call it <dstolfa>lfam: that's possible, but the barclays subdomain, expiry month, official login page with no redirects and barclays confirming it wasn't them without any other follow-up is just extremely suspicious. to this day i don't know what happened and it's been like 2-3 years now <lfam>Could also be as you say <lfam>Institutions like that do get compromised, and it seems like card issuance must also involve several 3rd party vendors <lfam>Like, the company that prints the envelopes to send the new cards *dstolfa eagerly awaits the pandemic to end so he can go back to $WORKPLACE and hear crazy stories about cybercrime from people that actively work in the field <lfam>Regarding Guix security, something I'd like to see poked at is the code that calculates hashes <lfam>And related, the code that fetches the data whose hash will be checked <lfam>It's one of the linchpins of the security model *dstolfa would like to poke around a lot of guix things, but he is currently getting poked by deadlines <lfam>We are having some interesting conversations these days :) I'm happy to offer a break from your work <dstolfa>one thing i'd really like to do with guix is parallelize shepherd, i looked at the code yesterday and it doesn't seem too painful to do using fibers <dstolfa>lfam: indeed, i'm enjoying the conversations :). sometimes i end up in a situation where i'm just running tests which take ~2600 seconds to run with nothing to do, so this is a great break <lfam>There are only so many dishes to clean <lfam>Another tricky thing with regarding Guix security are the sharp edges around the use of Nix's content-addressed cache as a fallback for source code <lfam>If I still understand correctly, when sources are only available there, Guix doesn't / can't also verify the filename, since Nix doesn't store it <lfam>So, it's possible to accidentally specify the wrong hash in a package definition and have Guix still accept it. Normally that doesn't work because filenames (especially versions) are part of the specification <lfam>This is basically fine but can be tricky <dstolfa>i haven't really looked at that so i don't really know what would need to change, perhaps guile-daemon could address that at some point (and maybe is a good argument for it?) <lfam>I find it hard to think of how it could be fixed <lfam>Like, an "exploit" would require a Guix developer to do something bad <lfam>But, the action would be somewhat obscure <lfam>It's just less transparent than Guix usually is <dstolfa>or some kind of MITM and the user not verifying things, but at that point there are better & easier targets to compromise i guess <lfam>It's like, if you update the OpenSSL package, but use the hash of an older OpenSSL source tarball, Guix will (probably) fetch the old source code from tarballs.nixos.org <lfam>And try to build it. And it will probably build successfully because it's still OpenSSL and it doesn't change very quickly <dstolfa>well, i guess it's easy to have a litmus test for this <lfam>The only warning during the build would be that downloading the sources from openssl.org would fail, before falling back to tarballs.nixos.org. And later, if you checked the version with like `openssl_client --version` <dstolfa>something like a "version" package, which just prints its own version <lfam>I haven't noticed how the Software Heritage cache works in this sort of case <lfam>So, you'd have a package that Guix says is e.g. "OpenSSL 3" but it would actually be "OpenSSL 1" <lfam>I worry about the potential for mistakes around this fallback cache <dstolfa>yeah, ideally one would just store the necessary things to detect inconsistencies somewhere and somehow <dstolfa>but i haven't looked at the code so don't know the implications of that <dstolfa>lfam: maybe one workaround is just a development practice that says "use `./pre-inst-env guix build --really-check-everything-without-cache`" or something <dstolfa>without needing to address the technical problem itself <lfam>The tricky thing is that this cache is only used when there is no other source available <lfam>So, what do you check it against? <dstolfa>lfam: ah, maybe just not checking it as a part of the development process is enough? e.g. saying `guix build --no-cache` would just fail if it reached the point where it needs to check the cache <dstolfa>i'm just thinking of a way to prevent a silly error from getting into the code that could cause weirdness, rather than solve the technical problem itself <drakonis>lfam: nixos looks up in cache.nixos.org and it fetches it then checks the hash of the download against the specified <drakonis>nix's whole fetching process is kind of bizarre because you have to zero out the hash otherwise it will fetch an existing build and then tell you the actual hash it wants <drakonis>there's two edge cases here, if your hash refers to an existing source, it'll try to fetch that, if the hash does not match an existing source but the specified version exists, it'll yield the correct hash and fail <lfam>drakonis: That sounds like "you have to zero out the hash otherwise it will fetch an existing build and then tell you the actual hash it wants" <-- That sounds like Guix <lfam>Assuming by "build" you mean "source derivation" <zap>Anyone had strange issue when running ./pre-inst-env guix ...? I for some reason get "/gnu/store/...-guile-3.0.7/share/guile/3.0" prepended to %load-path <lfam>zap: The pre-inst-env script is supposed to change the runtime environment so that you can use Guix from the directory that created the pre-inst-env script <lfam>I confirm the same behavior <zap>but then it won't see the changes done to source tree will it? <zap>when you run ./pre-inst-env guix build modified-package it will load source from "/gnu/store/...-guile-3.0.7/share/guile/3.0" <lfam>I don't really know much about Guile, but I promise you it works :) <lfam>I hope someone who knows more about Guile can explain it better. <lfam>The pre-inst-env script is how people test changes to Guix. It definitely uses the changes in the Guix source tree <zap>there is even comment in ./pre-inst-env <zap># Define $GUIX_UNINSTALLED to prevent `guix' from <zap># prepending ${prefix}/share/guile/site/3.0 to the Guile load paths. <zap>lfam: Yep it used to do same for me :) it just recently stopped I don't know what I did wrong :) <lfam>If the pre-inst-env script stopped working, did you recently collect the garbage, perhaps deleting the development dependencies of your source tree? <lfam>That's the most typical way it stops working <lfam>I just did `git pull`, re-did `make`, and the pre-inst-env script still works for me <lfam>If that's the case, you need to do `guix environment guix; ./configure --localstatedir=/var && make` again <zap>yep I did it but without evrironment, I'll try again, strange... <lfam>Unless you have another technique for providing the development dependencies, you need to set up the development environment with `guix environment guix` in order to build Guix properly <zap>compiling... lfam: btw regarding %load-path i'm preety sure that the right state is when you have repository directory infront of load path after running ./pre-inst-env. <zap>when i did it like ./pre-inst-env guix build -e '(begin (set! %load-path (cons "/home/zap/src/guix" %load-path)) (use-modules (gnu packages node)) node-16.1)' <zap>didn't help, seems like its a question for #guile <cryptikulous>hey Guix, is there a difference between "guix pull && sudo guix system reconfigure /etc/config.scm" and "guix pull && guix package --upgrade" <Noisytoot>cryptikulous, guix system reconfigure updates your system, guix package --upgrade updates your profile <cryptikulous>the thing here is i just want to fully update my system + my packages.. i have to run both of them? <lfam>In Guix, package management is per-user ***iyzsong- is now known as iyzsong
<drakonis>nckx: heyo, i hear you run your own mail service, i'd like some advice on how to set one up with guix <drakonis>you dont publish your configs anywhere, do you? <jab46>I tried to install hyperbolaBSD last night. I couldn't get the ethernet connection to work in the vm. ***chkno_ is now known as chkno
<ss2>Any happy Geiser user here? <jab46>drakonis fair enough. Just chatting. <jab46>ss2: I've never really been able to get geiser to work... <ss2>in which way does it not work for you? <jab46>ss2 I could never get the "jump to definition" to work. :)