<ATuin>cbaines: seems the nix channel problem was fixed installing nix from nix itself and using the nix-channel binary from the nix installation <mbakke>dissoc: using './pre-inst-env guix build package' will output to the terminal <mbakke>or just 'guix build package' if you are not using the pre-inst-env script <dissoc>NieDzejkob: i tried using display but nothing in the console <NieDzejkob>dissoc: could you paste the package definition to which you added the display? <dissoc>i essentially just put (display "hello") in a (add-after 'install 'my-name (lambda ... (display "hello")) <rekado>NieDzejkob: only very few R packages take a long time to build. Most of them have very simple builds. <civodul>good news! guix-translated-texinfo.drv will be faster now <NieDzejkob>dissoc: if you throw an error instead, does it fail the build? <NieDzejkob>this should work, so I think you might be modifying the wrong package or something <NieDzejkob>is this the right checkout of guix, if you have >1? <mbakke>civodul: yay! I've been wondering whether it should be made offloadable too <vagrantc>civodul: this isn't just because computers are getting faster? :) <dissoc>NieDzejkob: it's not really worth messing with. i just thought it was something simple i was missing <dissoc>i should probably just review guile again <dissoc>probably the path of least resistance long term anyways <PotentialUser-46>Hi! I’m interested in using the Guix Distribution. Has anyone had any luck setting up zfs on root? I see that zfs is available as a <nckx>civodul: Ah, thanks (for the info & the restart). <nckx>PotentialUser-46: Support will need to be added to (gnu system file-systems) to boot from ZFS. Not a matter of luck, just (very little) sweat. <PotentialUser-46>nckx. I’ve successfully installed ZFS on Debian, through a manual installation. Maybe I’ll try to reproduce what I’ve done on Debian. <nckx>PotentialUser-46: Using ZFS file systems from Guix System is no problem. Kernel (module) support is there. But to actually boot from a /gnu/store on ZFS needs some basic support for reading superblocks, labels, UUIDs &c., written in Scheme. <nckx>Guix doesn't run a mini systemd/udev/libblkid userland in the initramfs like other systems. <PotentialUser-46>Ah, I see, thanks. Maybe I’ll just attempt using Btrfs, just concerned about its history of data corruption. <Bryophyllum>Question, does the installer pull in packages recipes from the commit that corresponds to the 1.1.0 release? <Bryophyllum>jonsger: Are you aware of any plans to make it so that the system is always up-to-date on the first boot? <jonsger>Bryophyllum: there are kind of plans that you can use installations images from current master, I think mothacehe did something into that direction <mbakke>the installer could always be generated with 'guix system disk-image gnu/system/install.scm', but the available packages will be those from the 'guix snapshot' in gnu/packages/package-management.scm <Bryophyllum>Is it the limitation of how Guix works that a point release ISO installer cannot effectively fetch packages from the newest commit? I see a value in not having to run `guix pull` after an update. For example, it'd solve problems caused by glibc version bumps or changes in PATH <Bryophyllum>Right now everyone installing Guix System will have to `guix pull`, `guix build --no-substitutes nss-certs`, and then `exec bash`. These are inconveniences that I found when installing the OS using the 1.1.0 release ISO. <Bryophyllum>Otherwise, nss-certs fails to build, and, as for the last command, it's needed to update the PATH variable, or else guix system reconfigure fails to update the system <Bryophyllum>There's also a point of increased data transfer. Just have Guix download what will actually be needed rather than install packages from the 1.1.0 release snapshot, which will be replaced in their entirety on the first boot, assuming that a user reads the warning messages that says that guix pull should be run to avoid downgrades. <mbakke>Bryophyllum: can you file a bug report about nss-certs failing? <mbakke>and also having to modify PATH manually <apteryx>someone reported 300 MiB written to its SSD every 5 minutes when idle o.O <Bryophyllum>mbakke: Sure thing. I'll get onto that as soon as possible <apteryx>I would advise against keeping Chromium open all the time if you care about your disk life expectancy ;-) ***catonano_ is now known as catonano
<NieDzejkob>Did CI stop running the encrypted-root-os test? The last entry for it is on May 13 <dissoc> so i wrote a package for cassandra database. what would be the directory to store the data in guix? <dissoc>"/var/lib/cassandra" seems to match what other db services would do <efraim>dissoc: I'd take a look at the other databases we have packaged. If you do change the localstatedir then you might need to make it not try to create /var/lib/cassandra at install and to write a service so it does the right thing ***apteryx_ is now known as apteryx
<zimoun>all the sha256 base32 for integrity are they nix-base32? some subtleties? <civodul>but internally it's just a bytevector anyway <civodul>zimoun: are you planning to look at the new sources.json format? <zimoun>civodul: yes, I am doing that today. :-) <zimoun>Because they use sha256 base64, it is just conversion. All seems available in (guix base32) and (guix base64). <civodul>a bit sad that these bits were not discussed publicly, AFAICS <civodul>(guix base32) supports RFC base32 as well <zimoun>basically, it is just "(base64-encode (nix-base32-string->bytevector " but because I am not sure to see if the encoding is part of <content-hash> <civodul>no, <content-hash> contains a symbol like 'sha256 and a bytevector <civodul>so you would do (base64-encode (content-hash-value hash)) <zimoun>the encoding is not stored, right? <civodul>right: there's no encoding, it's just a bytevector <civodul>so you can encode it as a string however you want <zimoun>Oh, right. It is even simpler. :-) <civodul>cbaines: did you have a chance to look at (guix store database)? <civodul>i'm wondering if i should update the 'guix' package now ***terpri_ is now known as terpri
<cbaines>civodul, not yet, I should have a chance this evening to take a look. <bonz060>What are some space saving tips you use on guix other than deleting generations and guix gc? <bonz060>My `/gnu` is 18G and don't know if I can make it any smaller =) <fps>bonz060: hmm, you probably do need those 18G ;) <civodul>i just run "guix gc -F20G" when i want to have 20G free :-) <civodul>and if i don't have 20G after that, i delete old generations: guix gc -F20G -d 3m <leoprikler>apteryx: wtf? why does chrome rewrite those files whenever you visit a link? What is wrong with those people? <travankor>bonz060: guix-modules and guix-packages-base seem to take up a lot of my store <bonz060>I'm curious how people that run guix on things like RaspPi's(low disk space- think less than 12G) manage space <sneek>Welcome back karmayogi, you have 1 message! <karmayogi>Can guix system container run with lxc or lxd <travankor>bonz060: i think those people don't run guix perse, but they build an immutable image using guix and flash that onto the pi <civodul>travankor: what does "guix size" return for these? <bonz060>travankor: Also, I never really knew you could do that. Is there an article or docs that talks about creating an immutable image. That sounds really interesting :) <travankor>civodul: unknown package; do they technically count as package since they are installed from guix pull? <xelxebar>bonz060: Take a look at 'guix system disk-image' :) ***rekado_ is now known as rekado
<bonz060>After switching to a different profile, I'm not supposed to be able to see packages installed in another profile(when I do a `guix package --list-installed`) right? In that case, how come after doing a: `GUIX_PROFILE="/home/bonz060/opt/test-profile" ; . "$GUIX_PROFILE"/etc/profile` I can still see packages from my default profile? Is there an extra env variable I need to set? How do you normally seamlessly switch profiles? I'd want to incorporate this to <bonz060>my daily workflow- it sounds really convenient =) <xelxebar>bonz060: Doing . "$GUIX_PROFILE/etc/profile" just sources that etc/profile. If you look in there, you see that it doesn't overwrite PATH but instead just prepends stuff to it. <xelxebar>I suggest you look at guix environment --pure if you're looking for "pure" profiles. <xelxebar>Unfortunately, guix environment doesn't have a --profile option, but you can sort of do the equivalent using an appropriate "manifest.scm" <bonz060>xelxebar: I used guix environment --pure to create a clean profile. What I'm wondering is how "clean semantic separation of the various packages a user needs for different contexts" is achieved. I thought that if you had one profile that had, say a Python2, then you could switch to that when you are working on a legacy project. And within that profile, install every python2 deps from guix. Once you are done, you just switch out to your default profile. FYI <mothacehe>I have a strange "Pre-boot error; key: misc-error, args: ("load-thunk-from-memory" "incompatible bytecode version" () #f)Aborted (core dumped" when building the website with haunt. <sneek>mothacehe, you have 1 message! <mothacehe>Strange because everything seems to be Guile 3.0 in GUILE_LOAD_PATH <mothacehe>civodul: oh that would be a regression because of my download patch, I'll have a look. <leoprikler>bonz060: "guix environment" should always be preferred over "guix package" when it comes to development <leoprikler>multiple profiles are for when you want to update a certain set of packages on a different schedule than all the others <leoprikler>say for instance, that you always need the most up-to-date Emacs, but are fine running an older version of Icecat (or vice versa) <mothacehe>civodul: Fixed the cuirass issue with 300f62. <bdju>has anyone taken a look at the "next" build failure yet? <mothacehe>civodul: np, just fixing my mistakes :p An opinion on my bytecode error message just above? <civodul>mothacehe: could it be that you're loading 3.0.3 bytecode with 3.0.2? <civodul>it's backward compatible, but not forward compatible <civodul>speaking of which, i'd like to change 'guix' and all its dependents to use guile-3.0.3 <civodul>so we benefit from the faster build times for 'guix' <mothacehe>that would fix my issue where mcron uses guile 3.0.2 but guile libraries are 3.0.3 I guess <bdju>whoa... did next browser rename to nyxt browser?! <bonz060>leoprikler: I'm working on a package defintion- upgrading a package to use py3- for some channel. I thought it would be easier to just test things out on a profile. From the docs, it's not really clear whether I can reuse an environment after creating it(tbh, I don't know if that's possible). Or I'm I doing things in a hacky way? <leoprikler>For one, invoking "guix environment" twice with the same arguments and Guix channels (see time-machine) will give you the same environment. <leoprikler>Also, you can use -r, which will give you a GC root (like profile -p) <leoprikler>Once you finished your package description, you can also simply do "guix environment <package>" <terpri>maybe i'm being pedantic but the greek goddess of night was Νυχ (Nyx), not "Nyxt"/"Νυχτ", that appears not to have been an ancient greek word at all <apteryx>what was the env trick to start a pure environment from a persisted profile? env - /bin/sh --init-file /home/user/.config/guix/profiles/some-profile/etc/profile <xelxebar>apteryx: env -i <command> runs <command> with an (almost) empty environment. <leoprikler>guix environment --pure -e '((@ (guix profiles) profile-manifest) "/path/to/profile")'? <apteryx>xelxebar: I believe 'env -' is the same as 'env -i' <apteryx>leoprikler: seems we're almost there to having a command line that would be useful to have ;-) <terpri>also i forsee a lot of "nyxt"/"nixt"/"nixed"/"nicksed"/etc. confusion when using the new name in speech <apteryx>leoprikler: but this still will rebuild the profile for the environment instead of simply reusing it, no? <leoprikler>I agree with you on the Greek Goddess part, but I would pronounce most of the above exactly the same way <leoprikler>apteryx: I'm not sure about that – your Guix profile is a link to a profile that's already been built with those packages <terpri>leoprikler, that's exactly the problem i mean, if you tell a friend (verbally) to go download the nyxt browser, they might type in any of those homophones <leoprikler>Well, try telling them to download the "next" browser. <apteryx>leoprikler: it failed with error like: Throw to key `match-error' with args `("match" "no matching pattern" #<<manifest> entries: (#<<manifest-entry> name: "bash" version: [...]. <terpri>leoprikler, also problematic, not defending the old name which could be confusing for that reason <apteryx>I guess I'd have to use guix time-machine and run this on the commit that was used to produce the profile <terpri>oh well, atlas has spoken, now we have "nyxt" <terpri>i don't think Νυχ had an exact roman equivalent but artemis or hecate would be cool names <apteryx>leoprikler: ah, my omission was --login <leoprikler>1. you have to write that expression to a file and then use -m <terpri>though hecate appears unused as a (significant enough for wp) program name <apteryx>leoprikler: I see. Let's come up with a guix environment --profile switch <leoprikler>terpri: but do you want your project to be associated with ghosts and necromancy? <apteryx>to reload an existing profile with the convenience of 'guix environment' <janneke>interesting, all these cross-package bugs/patches :-) <zimoun>Can Guix fallback to SWH if the sources are url-fetch? It works only for sources of type git-fetch, right? <terpri>terpri's rule of naming: if you're going to name your program after an ancient deity, email a classicist ;) <apteryx>zimoun: not yet. SWH only archive versioned repos <apteryx>but I head they are working to enable archiving the tarballs used by Guix <raghav-gururajan>> apteryx: I would advise against keeping Chromium open all the time if you care about your disk life expectancy ;-) <raghav-gururajan>When I open chromium, I get a low yet constant noise from speakers. Stops as soon as I close chromium <apteryx>raghav-gururajan: even when no sites are using your microphone? <janneke>terpri: well, the web as we know it needs to die, right? <leoprikler>That's what happens if you use enterprise quality software on a small indie laptop. <clodeindustrie>NieDzejkob: It's not found, I have installed docker via `guix install docker docker-cli` <NieDzejkob>clodeindustrie: you need to put docker-service-type into your config.scm and reconfigure <NieDzejkob>packages installed are per-user and can't create a daemon <civodul>apteryx: this is less and less true! that's what zimoun is working on <civodul>and before zimoun lewo of NixOS implemented the relevant bits so SWH can "pull" from us <zimoun>civodul: thank you. I will give a look at the code. But which address Guix uses to ask to SWH? <zimoun>because, SWH repack if I have understood correctly so it is very fragile. <apteryx>civodul: oh! thanks for tipping in, I didn't know zimoun was working on such support! Thank you! <zimoun>Aside, what services use the file packages.json? Is it an issue if a new field is added to "source", say "integrity". <apteryx>meh, I still don't get why 'env -i /bin/sh --init-file /home/maxim/.config/guix/profiles/some-profile/etc/profile' won't cooperate. <apteryx>it won't export any variable that said profile contains, not even PATH. I swear I had something like this working previously. <civodul>one of the problem of favoring "content hash" as they wrote above is authentication <civodul>signatures are usually over tarballs etc. <civodul>it's unfortunate that the design is now biased in that direction <zimoun>civodul: thanks for the pointer. I was unpacking the example. :-) <janneke>civodul: so now that we have a childhurd service, can we take/define the next step to get it onto a (some?) build nodes? <civodul>zimoun: so is it archiving raw tarballs among those listed in sources.json or is it not? <civodul>janneke: yup! could you add a childhurd service to some of the build nodes in maintenance.git? <civodul>maybe a 3rd of the build nodes could have that service <lewo>civodul: no, it is not archiving raw tarballs. <civodul>janneke: and then we need to make sure forwarding works fine and update machines.scm <zimoun>civodul: well, I do not know. From my understanding and my chat with lewo, I have understood that they are unpacking and repacking on the fly <janneke>civodul: ah okay thanks, i'll have a look <lewo>civodul: yes, it is. But SWH doesn't want to store raw tarballs. <civodul>i didn't get a clear response over the years <civodul>the authentication issue remains open <civodul>on one hand it's beyond the scope of SWH <civodul>on the other hand, you want to know what it is you're fetching <lewo>sorry, what is beyond the scope of swh? <civodul>ensuring the code they archive can be authenticated <zimoun>civodul: but the direct consequence is about falling back, IMHO. <zimoun>I mean that the hash we have is not necessary the hash they rebuild <lewo>oh, ok. I never thought about the authentication issue. <civodul>zimoun: right, so we cannot fetch tarballs from there in practice (except for the few that are actually there) <lewo>it depends how you compute your hash <civodul>but i guess it's the same for fetchURL or whatever it's called in Nixpkgs <zimoun>lewo: the hash we have is the integrity. <zimoun>civodul: I think in practise it will be ok for a lot of tarballs. <lewo>zimoun: in nixpkgs, we are not always computing the fixed output derivation hash on the tarball itself. Sometimes, we first unpack the tarball before computing the hash. <civodul>lewo: right, but the problem is those other cases where all we have is the hash of the tarball <lewo>yes, and this is a non trivial problem :( <civodul>dunno, but it's one of the main use cases for distros <civodul>even if we're gradually moving to hashes over raw directories <lewo>In nixpkgs, we have ~6000/25000 hashes computed on the tarball content. <civodul>perhaps we should restart a discussion on this topic <lewo>another way to address this would be to delegate the authentication to swh <civodul>yeah, although you don't always get a reply there :-/ <civodul>lewo: i don't think that's an option <civodul>one reason is that, if you have a document/code that refers to a tarball by hash, how can you tell whether what you got from SWH corresponds to that? <lewo>You couldn't. You would have to trust swh. <lewo>yep, i wouldn't like to submit such kind of patches in the nix project :-/ <civodul>i'll email swh-devel to restate these needs and see what they think <civodul>yes, but what do you do with past packages? <zimoun>I cross my fingers and hope to not need them ;-) <zimoun>what services use pakages.json? Is it a problem if a new field "integrity" appears in "sources"? <civodul>packages.json is mostly for repology i think <zimoun>civodul: ok, I am going to read overthere if it will not break. <mbakke>oh, debian updated their chromium package the same day I "broke loose" from it, typical :P <zimoun>civodul: yes. And 25% git-fetch. It is easy to switch all the bioconductor.scm. But it will harder (nor impossible) for all the python-xyz.scm because of PyPI. <rekado>zimoun: switch all packages in bioconductor.scm to what? <zimoun>rekado: git-fetch instead of url-fetch. But that's something will not happen. :-) <efraim>data.guix.gnu.org says we've passed 14k packages <terpri>divansantana, not that i'm aware of, beyond the official blog and planet gnu (unless you mean package updates and such, in which case, i'd say the git repo is the closest thing to an rss feed ;)) <terpri>aren't there tools for making reproducible tarballs? joey hess wrote something called pristine-tar, related to deb packaging, but i don't recall exactly what it was for ***atw` is now known as atw
<zimoun>civodul: thank you for the pointer. I am already processing it. BTW, I have sent the patch for the new sources.json compliant with the current loader. Once merged, let keep SWH in touch and they could point their "staging" and report potential issue. <rekado>civodul: ah, that’s an old problem that I worked around by starting the mumi web interface manually… <rekado>I stopped the mumi service and started mumi manually and now it’s fine <Kozo>Hey all, I'm trying to write this in my config.scm but it doesn't like the $HOME. Can someone correct this please? - (with-output-to-file "$HOME/.emacs") <efraim>looking for suggestions for a better commit message: "gnu: go-1.13: Build for aarch64-linux for aarch64-linux." <efraim>technically true, before we were building for armhf-linux when building for aarch64, but a bit too ambiguous <leoprikler>but you probably want to provide the absolute name, otherwise doing this with a different username will give you a different result <leoprikler>you might also want to look into guix-home-manager, which lives somewhere out there <cbaines>efraim, regarding the 14k packages, looks like we've crossed the 14k package derivations for each architecture threshold <dissoc>i wrote a package for a database but i want to put the data directory in /var/lib/ . is the expectation to write a service for this? that is the impression i get from looking around <cbaines>efraim, I'd say we have ~13400 packages currently though, if you look at the derivations you end up counting different versions of the same package multiple times, like rust contributes ~20 derivations <efraim>guix package -A | wc -l shows closer to 13900 <efraim>guix refresh -l go@1.13 says 229 dependant packages, looks like I can push the aarch64 fix directly to master <civodul>zimoun: yeah, let's see if taking care of the original artifacts is officially a non-goal for SWH <civodul>kinda weird because they have raw GNU tarballs for instance, on purposes AFAIK <zimoun>civodul: yeah, I miss something... because SWHID will never be the standard over the goo'ol tarball checksum. <zimoun>civodul: what the process for submitting an entry for the guix-hpc blog? I mean do an announcement about the Repro Hackathon? <bonz060>In a guix environment, where do you locate installed things? And also, in a shell, how do you know you are in an environment? Like in a virtual env, the (.env) or something similar is usually displayed somewhere <efraim>I sometimes look in $GUIX_ENVIRONMENT, like I'll check for libs in $GUIX_ENVIRONMENT/lib ***jonsger1 is now known as jonsger
<janneke>also /run/current-system/etc/skel/.bashrc sets [env] in your prompt <bonz060>janneke: You've lost me there. Isn't there something you'd need to set in your .bashrc? <bonz060>Also, when inside an environment, where are libs stored. There are some packaged js files, and I want to figure out where they are =) <efraim>find $GUIX_ENVIRONMENT -type f -name '*js' <bonz060>efraim: Thanks. I reckon the most important thing is the $GUIX_ENVIRONMENT variable. Mucho thanks! <pkill9>there is probably a way to run programs that rely on dbus etc in a guix environment, by adding a path to XDG_DaTA_DIRS that is a symlink to the guix environment profile <pkill9>like when a packag einstalls a schema or something <pkill9>what is needed is a sweet package manager for desktop packages for guix that has a button to test out the software <pkill9>now that i think about it, there are kinda three layers of a linux desktop system: the kernel, the general userspace, and the applications <efraim>does (uri (pypi-uri "attrs-strict" version)) work? <efraim>(from 'guix import pypi attrs-strict') <zimoun>efraim: no, sadly. I do not understand why. <MSavoritias>Hi. I found another determinism problem. I build Mpv twice and it throws an error that the output is different <zimoun>efraim: well, I will not do today because, aside the fetching issue, the package does not build because the check phase. *lispmacs[work] figures out the answer to a question just before asking it <LarryTheCow>MSavoritias: I just built a --dry-run mpv and it worked fine ***Noisytoot_ is now known as Noisytoot
<MSavoritias>i forgot to mention it i the command was: guix install --rounds=2 mpv <apteryx>zimoun: the importer is failing you? <cbaines>MSavoritias, it's probably a build reproducibility issue, I'm not an expert in tracking down the issues though, so I don't really have any advice <cbaines>Why did you build with --rounds=2 MSavoritias ? <apteryx>zimoun: sorry, I wasn't clear; won't the package definition returned by the importer build? Was is the error? <zimoun>apteryx: no, because 1. it fails to download the source and 2. if I download by hand and use --with-source it fails at the check phase. <zimoun>well, I will give a look on Thursday if someone does not beat me. :-) <lispmacs[work]>hi, I was just wondering if anybody had opinions on what would be the optimal hard drive type or model on a system that does a LOT of compiling (i.e., Guix builds) <cbaines>lispmacs[work], a SSD will probably outperform a hard drive, are you just interested in hard drives? <apteryx>zimoun: often PyPI packages lack a test suite. You might be better off using their git repo if you want to run it. <lispmacs[work]>cbaines: open-minded. I would think in compiling scenario you need both rapid read and rapid write; seems like this was a complicated issue last time I looked into it <lispmacs[work]>like, some SSDs have quick read but slower write, that sort of thing <chipb>Moar RAMs! for the fscache, that is. <rndd>hi everyone! just entered to say hi @-@ <mbakke>SHA3 and BLAKE2s support for origins, and the diffstat is less code \o/ <raghav-gururajan>When I am using Jitsi Meet on Chromium, the tab always crashes after could of minutes, with the error "Ah, Snap!". <MSavoritias>I am interested in the whole reproducibility and bootstrap thing. Its one of the reasons I have Guix. <mbakke>raghav-gururajan: did you update recently? there was a problem with chromium and ffmpeg 4.3 that was fixed yesterday <mbakke>MSavoritias: thanks, I just looked into it and can confirm the issue <mbakke>I went to check the source code for the waf build system, but gitlab is down :/ <mbakke>the problem is that the binaries have different RUNPATHs, likely because the link order is not deterministic ***benny_ is now known as benny
<mbakke>would it be feasible to discard the source files of guix, and just install the .go files, to save space? ***familia_ is now known as familia
<zimoun>apteryx: thank you for the tips. Currently, I do not understand what is wrong, so I will properly ask on help-guix. :-) <apteryx>but usually when the test suite is missing, the check phase passes without running anything <zimoun>running "python setup.py" with command "test" and parameters () <mbakke>it reminds me that 'python setup.py test' is deprecated, we should do something about it in python-build-system for the upcoming core-updates cycle <mbakke>maybe automatically invoke pytest when it is in inputs <apteryx>mbakke: yeah, perhaps! I wonder what is the rationale behind this deprecation. It seems backward. <zimoun>mbakke: or add pytest in the python-build-system? I do not know if it adds a lot in terms of closure size. <apteryx>It doesn't make sense to have pytest in the closure when nose or another test runner is used, in my opinion. <mbakke>apteryx: AIUI the interface is "weird" and people use it in wildly different ways, which conflicts with the Python mantra of "only one obvious way to do something" :-) <zimoun>apteryx: yes that's right. It is related to the discussion about implicit inputs we had some times ago. <janneke>bonz060: sure, that skeleton is copied to ~/.bashrc for new guix system users <civodul>zimoun: re guix-hpc blog, you can create an account on gitlab.inria.fr and i'll add you there <civodul>perhaps check with Konrad what to put in there <bonz060>janneke: thanks. I've got around to doing that. Also, I've got around to using an environment for writing packages. Now I have another question, how do you test things out inside an environment? Like is there a way to update a package inside an environment without affecting the "outside" world? Or more precisely, how do you test package definitions. Earlier, someone recommended environments over separate profile. <zimoun>civodul: guess what my login? :-) I am created and I put my "academic" email address. Tell me if I need to accept stuff. <civodul>you can drop a file in drafts/ for now and ask Konrad for feedback <zimoun>civodul: thank you. Right. I will. <janneke>bonz060: i'm not sure what you want to test, but environments cannot be changed; you can create a new environment that differs in one package or package version from another or previous environment <zimoun>civodul: sorry to be naive, where is drafts/ ? <civodul>ah i thought it was there, but maybe not? :-) *janneke is a big guix time-machine fan for creating differently versioned environments <civodul>the thing is whatever appears in posts/ is automatically published within an hour <civodul>mbakke: congrats on the mpv reproducibility issue! <zimoun>civodul: ok. I will add the folder drafts/ and my announcement draft file inside and then ask to Konrad to review it. <mbakke>civodul: ty, happy with the easy workaround :-) <zimoun>janneke: me too! guix time-machine is a killer feature! Once I discovered it, I was not able to understand how I was doing before. :-) <janneke>zimoun: wait, what? there was a time that time-machine didn't exists? :-P *apteryx has yet to run guix time-machine *hides* <apteryx>I guess I'm happy living in the present ;-) <bonz060>janneke: I'm porting a web app that relies on packages defined in guix that use python2. Some of the deps are defined as packages with py2 packages as inputs. So I've been trying to think of an efficient way of updating the package definitions and testing it out with the web app. Right now I'm creating an environment with the required packages, and in the spawned shell, I'm using $GUIX_ENVIRONMENT/etc/profile to set the profile required by the web app. <bonz060>zimoun: I guess time-machine is one of those things that'll make sense when you "discover" it on your own :) <zimoun>apteryx: time-machine is for pull what environment is for profile :-) <janneke>bonz060: ah, right that makes sense; you just create different environments and use those to test in <apteryx>zimoun: neat, I'm sure I'll have a use for it soonish