IRC channel logs


back to list of logs

<ArneBab>rekado: thank you — you’re awesome!
<ArneBab>KE0VVT: from guile?
<ArneBab>KE0VVT: does this work? HOME=$(mktemp -d) guix environment --pure --ad-hoc guile-wisp guile -- wisp
***daviid` is now known as daviid
<Gooberpatrol_66>How does one in config.scm specify that a file under /etc/<subdirectory> should be created?
<Gooberpatrol_66>if the subdirectory already exists, like /etc/ssh
<apteryx>rustc and cargo now seem to function OK on i686-linux
<apteryx>cross built from 1.54
<apteryx>we'll have some cross compilation work to do for the other arches (something about the linker wrapper doesn't cross compile)
<jackhill>Gooberpatrol_66: maybe the special-files-service-type does what you want?
<jackhill>apteryx: exciting progress!
<podiki[m]>wow, nice work apteryx!
<apteryx>thank you!
<apteryx>now to figure out the top level syntax glue
<apteryx>similar to how it was done for polkit-duktape
<apteryx>I've pushed it in its rough (but building, running state) on the wip-cross-built-rust branch
<Gooberpatrol_66>jackhill: i will try that, thanks
<jgart>Is there any rust dev guide currently for using crates with guix anywhere?
<jgart>like, If I'd like to start a new project and I want to use guix instead of Cargo.toml what are the best practices for starting to hack on a new rust project with Guix?
<apteryx>best practice would be don't choose rust for a project to build with guix ;-)
<jgart>so don't hack on new rust projects with guix to manage crates?
<jgart>what do you think is currently missing before that can be done comfortably?
<apteryx>the rust build system doesn't behave like the rest of the build systems; rust links everything statically, no or little dependency traceability
<apteryx>and in the end you're probably going to want to use cargo for a rust project, which doesn't leverage any of guix rust packaging
<jgart>so just ignore guix for rust development and use cargo directly instead?
<jgart>what are the goals then of packaging rust packages for guix? end users but not rust devs?
<apteryx>GNOME depends on rust
<jgart>for example to install ripgrep but not to hack on ripgrep
<jgart>apteryx, right ok got it. I used a different example of a rust app
<jgart>are rust devs using nix for development?
<jgart>or is that becoming a popular thing in the nix community?
<apteryx>perhaps; I saw there's some nix specific bits in the source
<apteryx>you could check with them
<jgart>I wonder if nix has the same issue with using rust for development purposes
<raingloom>(hey, could someone take a look at the revised yggdrasil update patch i sent a while ago when they have time? it be dis one: )
<jgart>I'll ask
<apteryx>well, nix and guix are still useful to provide the rustc/cargo base
<jgart>right, to have a base that is bootstrappable
<jgart>which many distros don't have packaged like we do
<apteryx>we are alone
<jgart>although nix just packaged rust in a bootstrappable way
<jgart>this happened recently
<apteryx>not sure, if think they were just considering it
<jgart>I think guix was first
<jackhill>If rust links things statically, does that mean grafts don't work either?
<apteryx>they won't be of much use no
<jackhill>hmmm, that seems … problematic. I wonder if efraim made much progress on building a bridge at packagingcon
*jgart needs language server protocol for acronyms
<jackhill>I want to like rust (and not just because I'm tracking down memory safety bugs in C programs). They've done a lot of things well, but there are gaps
<jackhill>jgart: lol
<jackhill>IIUC, if I understand correctly
<jgart>ahhh, I knew that one...
<jackhill>jgart: does that mean you're doing IRC in something that understand LSP?
<jgart>I just want to be able to hover over it and see what it means
<jgart>jackhill, ha no! I wish!!
<jgart>maybe eglot and erc can be composed somehow after someone writes internet-acronym-lsp-server
<opalvaults>anyone know if there is a time-frame for guix upgrading gnome to 40? if i understand correctly, it's in the frozen repo atm?
<apteryx>I've now hit the crux of the problem: moving a x86_64 derivation into the real of i686. not even sure if that's possible.
<podiki[m]>opalvaults: yes, once the merge happens "very soon"
<podiki[m]>some talk of it this week...
<opalvaults>thank you for the information podiki[m]! much appreciated
*apteryx wishes Guix a good day/night -> bed
<podiki[m]>opalvaults: no problem. here is the most recent thread
<podiki[m]>night apteryx! awesome rust work, hope that comes through in the end
<opalvaults>excellent, i will read that now, ty :)
<opalvaults>i'm a little confused, maybe someone with a better understanding can let me know: is Rust not FOSS or something?
<opalvaults>or is just a huge pain to build and port for multiple archs?
<apteryx>the later, if cleanly bootstrapping it is valued
<apteryx>otherwise you fetch binary bootstrap blobs from the net and off you go
<opalvaults>apteryx: good to know, ty :)
<podiki[m]>it is only because guix cares, that we suffer so :)
<jackhill>true for rustc and cargo, but it seems like even if we didn't care rust libraries and programs would still be fraught
<raingloom>quick q: how do i modify the openssh service to log somewhere reasonable? ie.: not /dev/console
<podiki[m]>maybe a log-file option if it has it
<podiki[m]>(in the configuration, see shepherd services)
<kutar>I feel silly asking this, but I haven't been able to find out the root password for the QEMU image I downloaded from the GUIX FTP server. I assumed it would be blank, but it appears not to be. Booted up and launched an XFCE session as guest, and can't guess the root password. Can't find a reference to it anywhere.
<lfam>kutar: This suggests that the password should be blank:
<kutar>Oh, interesting, so I can sudo but not su
<kutar>Well, 'sudo passwd root' worked! I feel a bit stupid, but thank you.
<lfam>Nothing to feel stupid about!
<lfam>We should add a note to the manual section Running Guix in a Virtual Machine
<kutar>Much appreciated! I was looking all over the documentation for the root password, and didn't think to try sudo :')
<ns12>Hi, I installed Guile 3.0.7 using the Guix package manager (guix install guile). But when I start Guile, I get these warnings: "guile: warning: failed to install locale" and "warning: failed to install locale: Invalid argument". What does this mean?
<jgart>has anyone used l2md with debbugs?
<lfam>ns12: Are you using Guix System or Guix on another distro?
<ns12>lfam: Guix on another distro (Ubuntu).
<lfam>Make sure that the package 'glibc-locales' is installed and that the GUIX_LOCPATH environment variable is set correctly
<lfam>As described here:
<lfam>Basically you need to put "export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale" in your ~/.bash_profile
<raingloom>podiki[m]: it doesn't have one, which is weird. ah well, i figured out what i needed without a log in the end. i'll look into it later when i'm setting things up proper and not just testing things in a vm.
<ns12>lfam: Thanks. I installed glibc-utf8-locales to solve the problem.
***Myrcy is now known as mercy
***mercy is now known as myrcy
<rekado_>rebooted one of the honeycomb nodes; doesn’t boot any more. The expected locations in the u-boot config must have changed…
<efraim>that sounds really frusterating
<efraim>with my pine64 sometimes I need to powercycle it once or twice before it comes up correctly
<rekado_>I think I need to adjust the u-boot config generating code
<efraim>its running Guix System or something else?
<efraim>also, hi zimoun! and everyone!
<rekado_>Guix System
<rekado_>hmm, the newer kernels I installed with “guix deploy” don’t boot.
<efraim>I got the impression from vagrant that uboot can be finnaky
<rekado_>booting the oldest kernel now :-/
<efraim>5.10 has wireguard built-in, right? Might be worth leaving some of the build machines at the latest LTS kernel
<rekado_>only 5.15 has the dtb file for this board
<efraim>that makes that choice easy
<zimoun>PurpleSym: cool! all the ghc-* packages for i686 are progressing. :-)
<PurpleSym>zimoun: Yep, looking good so far.
<mothacehe>hey guix!
<zimoun>it will take ages since parellel-build? is #f :-) Oh well, damned reproducibility!
<rekado_>the only thing that differs between systems that boot and those that don’t is the initrd.
<abrenon>hello guix
<vivien>Hello guix! I’d like to shamelessly bump my patch, 52188, so I can continue to check wether core-updates-frozen works :)
<mothacehe> vivien: hello! just pushed it, thanks!
<vivien>Thank you :)
<mothacehe>looks like there's something wrong with python3 plugins though, if you can have a quick look :)
<dhruvin>i see guix website does not have a search to look for packages. is it because we never got around implementing one? or is it because of some other reason? (like it's not feasible or something)
<zimoun>mothacehe, what is the difference between and ?
<mothacehe>zimoun: the guix specification builds the "guix pull" derivations
<mothacehe>while the master specification builds all the available packages on the master branch
<zimoun>ah ok, thanks
<rekado_>dhruvin: has a search. Nobody got around to letting the website use that code.
<dhruvin>oh i see. thanks rekado_
<rekado_>this build has succeeded, but it’s not marked as successful:
<rekado_>re booting the honeycomb: all the newer system entries want “bzImage” from the kernel, but the built kernel only has “Image”.
<daviwil>Hey folks! While trying to build the Guix repo for the first time in a few months, I've encountered the following error while running `make distclean': `No Guile development packages were found.'
<daviwil>I'm launching this from inside of `guix environment --pure guix' so I figured all dev dependencies would be available in the profile
<daviwil>Perhaps something from my user profile is still leaking in and causing trouble?
<rekado_>does ./bootstrap and ./configure --localstatedir=/var work?
<daviwil>Argh, yeah, that cleared up the issue
<daviwil>now `make distclean' works again, makes sense
<daviwil>thanks rekado_!
<rekado_>I’ll try rebuilding with the same commit that I used for the first init.
<rekado_>guix time-machine --commit=0846e7d3265f9fc1b7d83676ef75c55f78faa587 -- deploy -L modules/ deploy-honeycomb.scm
<rekado_>apteryx: excellent job cross-building rust! I don’t know how to make the non-x86_64 variant use the cross-built rust as an input, though.
<PurpleSym>Are the ghc-* builds on i686 stuck? I can see the jobs finished from the logs, but the UI is not showing them as finished.
<PotentialUser-96>hello is this a good place to ask for some directions regarding the memoization capabilities of guix? I'm trying to understand if the framework is a good fit for some HPC workflows, specifically with regards to memoizing them, but I could not figure out how memoization is expected to behave in the guix manual thus far. Could you point me to some
<PotentialUser-96>reading material on that?
<zimoun>PurpleSym, I think it is an UI issue. And the jobs are not yet finished I guess. mothacehe?
<rekado_>PurpleSym: I saw the same for an aarch64 job.
<zimoun>a lot of orange and grey
<rekado_>this one:
<PurpleSym>But there’s a trailing `@ build-succeeded …` in the log.
<rekado_>I manually copied the output to and then restarted the job, but it still claims that it will build it.
<PurpleSym>This one for example:
<rekado_>super weird. The output already exists on and still it insists on building it.
<abrenon>so, if I understand correctly, one may "bump" here patches which don't get enough love ?
<rekado_>PurpleSym: the outputs of that build have not been copied back to
<rekado_>after restarting again it’s registered as successful
<rekado_>abrenon: correct
<PotentialUser-96>would it be better for me to send an e-mail to the help mailing list requesting information about memoization?
<PurpleSym>For ten hours, rekado_? :/
<mothacehe>rekado_: zimoun: when ci builds are still marked as running while the log says they are done, means that they are currently being fetched, which can take hours/days due to the GC situation on Berlin.
<abrenon>great ! then let me shamelessly bump which hasn't got much love so far
<rekado_>abrenon: I’ll apply it, thanks!
<zimoun>mothacehe: thanks!
<abrenon>rekado_: thank you !
<rekado_>abrenon: do you have any other patches that need a quick review and push?
<abrenon>ahh, sorry for the indent, I'm pretty sure I applied the emacs script for it though ^^
<abrenon>uh, no, not yet sorry : )
<abrenon>there was a sequel which I was wanting to submit a few days after this one, but then I got trapped in a never-ending coding spree and I haven't found the time to prepare it
<abrenon>so nothing as of now : )
<rekado_>don’t worry about the indentation. I just let Emacs reindent things and amend the commit.
<rekado_>almost no extra work :)
<zimoun>jbv1[m]: Julia v1.7 is out \o/ Do you plan to work on upgrading it?
<rekado_>would anyone like to apply these patches?
<abrenon>(and then the chan become silent…)
<rekado_>I’ll take on
<abrenon>was your message targeted at anyone ? I suppose applying a patch requires some particular knowledge of the patch reviewing process ?
<rekado_>I was hoping someone with push rights could take care of it
<abrenon>(I really don't have the time, but since you spent some time reviewing my patch, I would really feel bad if there was something I could do to help and didn't do it)
<rekado_>wasn’t directed at you :)
*rekado_ is irritated that mumi’s /patch-set URL doesn’t work
<abrenon>great because I don't have the time : ) (but still, if there's something I can do…)
<jpoiret>rekado_: last time i tried it did
<jpoiret>ah, yes, the problem is that the v2 patch is not marked as such
<efraim>rekado_: I can take 49834
<rekado_>efraim: thanks!
<PotentialUser-96>how does guix deal with feature requests? is there a record of those? perhaps I can find information about memoization in there
<jpoiret>PotentialUser-96: you can look at the
<PotentialUser-96>jpoiret: thank you, I queried those earlier but couldn't find what I was looking for I will give it another stab. Just trying to understand how memoization is expected to behave
<rekado_>PotentialUser-96: could you please be more specific? What about memoization do you want to know?
<PotentialUser-96>hi rekado_, I am trying to understand how the implementation of the memoization mechanism in guix works. I am familiar with the dynamic programming concept of memorizaion as well as how certain workflow frameworks implement it. For instance, Argo expects developers to annotate their workflows with memoization metadata. I tried to look up how
<PotentialUser-96>memoization behaves for guix but I could not find any details about it in the manuals or the mailing lists. Is there a document/web-page that describes how memoization works in guix ?
<rekado_>there’s no documentation other than its implementation in (guix memoization).
<rekado_>looks like ’guix deploy’ deploys the wrong kind of system to the aarch64 nodes
<rekado_>I see: In procedure execl: Exec format error
<rekado_>and a suspicious: “request_module: modprobe binfmt-464c cannot be processed”
<rekado_>this suggests to me that a system with the wrong architecture has been deployed
<PotentialUser-96>hello ricardo_, thank you for your response. I tried to understand the implementation but I am not familiar with schema. Is it safe to say that memoization reads all the files that are inputs to a package, as well as the package definition, build a hash out of everything (cache-key). Then it checks whether the cache-key already exists in a locally
<PotentialUser-96>maintained cache, if such an entry exists instead of building the package (or executing a task for guixwl) it reuses the contents of the cache-key. Would that be accurate ?
<PotentialUser-96>I apologize for misspelling your name, I meant to type hello rekado_
<rekado_>(guix memoization) provides “memoize”, which takes a procedure and computes it only once.
<rekado_>what about the GWL do you want to know?
<PotentialUser-96>I am wondering if guixwl also performs memoization for components in workflow (i.e. Tasks with inputs and outputs)
<rekado_>it caches previously built outputs, yes
<rekado_>it does this by computing the hash of all inputs and using that as the cache key
<rekado_>that’s unrelated to memoization in Guix, though.
<rekado_>(I feel guilty that I haven’t been able to work on the GWL in so many months)
<PotentialUser-96>I now understand that I incorrectly assumed memoization applies to the Tasks too, is there documentation that talks about the Caching functionality for GWL Tasks? Would my earlier comment be accurate i.e. GWL hashes all input files as well as what the task does e.g. binary, or path to binary, container, etc then uses the resulting cache-key to
<PotentialUser-96>query a local database to find matching tasks that previously executed Workflows generated and if GWL finds at least one it re-uses the outputs of the cached task instead of executing the new task from scratch
<zimoun>PotentialUser-96, be a careful (guix memoization) is naive implementation (which works enough for Guix :-)) and depending on context of use, it could be a bit ineffecient (
<PotentialUser-96>thank you zimoun - I apologize for taking over the discussion but your word of caution is exactly what is driving me to, for a lack of a better word, spam you :)
<rekado_>PotentialUser-96: there’s no database; there’s just directories in %cache-root.
<rekado_>(e.g. /tmp/gwl)
<zimoun>GWL use /gnu/store as cache, no?
<PotentialUser-96>we can consider that the database is a regular directory and that "querying" is just checking whether a certain path exists - thank you rekado_
<zimoun>PotentialUser-96, I think the answer is yes and the database is /gnu/store for some.
<zimoun>and /tmp/gwl for others, right rekado_?
<PotentialUser-96>thank you so much zimoun and rekado_ you have been incredibly helpful, I think I understand how memoization (i.e. Task caching) in GWL works.
<rekado_>the workflow is computed first, generating process scripts. These scripts will embed /gnu/store file names depending on the exact environment for each process.
<rekado_>the execution order is computed and the chains of processes are hashed (i.e. the hashes of the process scripts and the hashes of all process scripts they depend on)
<rekado_>this is the key in /tmp/gwl
<rekado_>if the declared output exists in the keyed directory under the cache root then the process is not executed
<rekado_>built packages are cached as usual in /gnu/store; that’s just how Guix works
<rekado_>PotentialUser-96: is this for a paper comparing different workflow engines…?
<rekado_>or are you intending to use GWL?
<PotentialUser-96>hi rekado_ for the time being I am investigating how different workflow frameworks behave before we make further decisions. So you can frame my questions in the context of academic curiosity
<PotentialUser-96>your latest messages contain exactly the information that I needed
<PotentialUser-96>again thank you very much for your time, take care!
<attila_lendvai>random note: in guix shell "--search-paths display needed environment variable definitions" is a very unintuitive name.
<zimoun>rekado_: no GC for ’/tmp/gwl’, right?
<attila_lendvai>but to something practical... why doesn't it do what i expect: $(guix shell --search-paths coreutils bash) ? afterwards ls, date, etc are not found anymore in the shell.
<attila_lendvai>if i run it without $(), then it prints the env vars, and PATH seems to be fine, pointing to corutils/bin
<rekado_>zimoun: correct
<rekado_>zimoun: you can just delete whatever you want there and GWL will just recompute as needed
<apteryx>attila_lendvai: --search-paths shows which Guix search-path specifications are in the environment profile
*attila_lendvai realized that he needs an eval before the $()
<rekado_>really confused about “guix deploy”. Even though the machine records specify that these are aarch64-linux systems it installs x86_64 binaries on it.
<rekado_>no wonder this doesn’t boot
<rekado_>now trying guix time-machine --commit=0846e7d3265f9fc1b7d83676ef75c55f78faa587 -- deploy --system=aarch64-linux -L modules/ deploy-honeycomb.scm
<cage>hi i am trying to patch a autotools file using (add-before 'configure ... (substitute* ...)) and i can see that the file is patched (using build -K) but, no matter what, the configure scrit ran does not contains the patch, any suggestion? What's wrong?
<rekado_>cage: you’ll need to regenerate the configure script
<rekado_>you may need to add a build phase that invokes “autoreconf -vif” and add autoconf, automake, etc to the native-inputs.
<zimoun>rekado_: thanks.
<cage>rekado_: thanks, i'll try!
<apteryx>cage: if you use the gnu-build-system you only need to force rebootstrapping with: (delete-file "configure")
<cage>apteryx: thanks!
<efraim>rekado_: sounds like it's worthy of a bug report, if it deploys for the wrong architecture
<rekado_>I sent email to the sysadmins first to see if we can figure out where exactly it’s going wrong
<yewscion>Hello All, I am messing around with `guix home` still, and I've run into an interesting issue: If I deploy `guix home` to my server's Guix System install, I get an error complaining that $XDG_RUNTIME_DIR is unset every time I ssh in. Is there a way to prevent this error? I have tried specifying a value for it in my home configuration, but it didn't
<yewscion>change anything.
<apteryx>rekado_: thanks! One crude hack idea would be to create a new package in place of rust-i686-linux with a i686-linux only supported-system property that takes the now named rust-cross-i686-linux (which is a x86_64 package) as input, forcing it as is (#:system x86_64-linux); and copy its content to its own output...
<apteryx>that's ugly though ^^
<roptat>hi guix!
<abrenon>hi roptat
<lahvuun->Hello! I'm trying to use the Guix package manager in a chroot from NixOS. The installation script worked, but whenever I try to build anything I get an error similar to "guix pull: error: derivation `/nix/store/qw4fpcv8sl1bgjz2b9v0ispm7nf2kfad-guile-3.0.2.tar.xz.drv' has incorrect output `/gnu/store/b1sljij4vihpr5s485i25y7ljzba6j25-guile-3.0.2.tar.xz', should be `/nix/store/962l91hdpscd01p9rdsa8cizlcfs97rx-guile-3.0.2.tar.xz'" How can I fix
<lahvuun->this and why does Guix attempt to use /nix ?
<rekado_>lahvuun-: environment variables
<rekado_>NIX_STORE_DIR is likely set
<rekado_>apteryx: I don’t know. It’s not ugly if it works.
<apteryx>ok, I'll try that after my day
<lahvuun->rekado_, thank you. Is there some documentation on how Guix interacts with Nix? I don't see any mentions of NIX_STORE_DIR in the manual, for example.
<rekado_>it’s not mentioned in the manual, but there are a couple of env vars that the daemon respects. Whenever I’m very curious I grep.
<lahvuun->OK. Unsetting NIX_STORE_DIR and NIX_STORE seems to have fixed it. Thank you again.
<cage>rekado_: apteryx, with your help i got a working patch, thank you!
<zimoun>apteryx, efraim: julia fixed on c-u-f for i686 by
<civodul>yay, well done!
<sneek>Welcome back civodul, you have 1 message!
<sneek>civodul, apteryx says: hi! "ld-wrapper-cross" appears as a native-input in cross-gcc, but is there otherwise a way to get a handle to it in a cross-built package? I'd like to add it to the PATH of the cross-built 'cargo'.
<zimoun>civodul: hi! :-)
<zimoun>on my side, main of big red blocks should be turned into green once CI is done. :-)
<zimoun>the big remaining one is ’tryton’ because new sanity-check phase. Well, it would be a blocker for the merge since it is not broken on master. But… let merge and fix from master. :-P
<civodul>ah yes, i fixed a couple of tryton packages but there are two important ones left
<rgh[m]><rekado_> "it’s not mentioned in the manual..." <- rekado_: 9jy99;;;0;;;;0;;;;;yay 9
<civodul>maybe we should ping Hartmut
<rekado_>rgh[m]: I don’t understand
<roptat>on core-updates I see a package failing because it doesn't know about %build-inputs. What should I use instead of (assoc-ref %build-inputs "source")?
<ngz>Is staging branch still a thing? I.e., should packages inducing around 600 rebuilds should go there or to another place?
<roptat>yes it's still a thing, though we're focused on merging core-updates
<cage>where can i found instructions to write commit messages correctly for guix patches?
<civodul>roptat: a gexp, as in 07ac13a26a0d7c8319afb42c55fc2116ec44668f
<ngz>cage: do you use Emacs?
<civodul>i'm preparing a blog post on all that
<cage>ngz: yes
<ngz>Then Guix provide Yasnippet snippets for commit messages. For example, you can type update<TAB> in an otherwise blank commit message and have a template filled for you.
<ngz>cage: See also (info "The Perfect Setup")
<ngz>err (info "(guix)The Perfect Setup")
<ngz>roptat: OK, so I'll apply the patch there. Thanks.
<cage>i can see snippets here in the guix repository: " etc/snippets/text-mode/", is this the correct place?
<roptat>civodul, so source would be #f and I would use the origin in a gexp, let me try that...
<ngz>cage: yes, you can add (with-eval-after-load 'yasnippet (add-to-list 'yas-snippet-dirs "~/src/guix/etc/snippets")) to your Emacs config, assuming ~/src/guix is the location of the Guix tree.
<cage>ngz thanks!
<civodul>roptat: which package is this?
<civodul>you could do: (install-pom-file #$(package-source this-package))
<civodul>(after turning the thing in a gexp)
<zimoun>civodul: what is the advantage of gexp over backquote for modify-phases? «#:phases `(modify-phases …)» -> «#:phases #~(modify-phases …)»
<civodul>zimoun: it allows us to do things like in the example above, with #$
<civodul>instead of fiddling with alists
<zimoun>Hum, so some packages will be `(modify-phases …) and other #~(modify-phases …). Newcomers will be confused, I guess. :-)
<roptat>civodul, (replace (quote install) (install-pom-file (ungexp (package-source this-package)))): 'replace' may only be used within 'modify-inputs'
<roptat>it's inside modify-phases though
<civodul>roptat: perhaps you're missing #:use-module (guix gexp)?
<civodul>maybe (guix packages) should just re-export 'gexp'
<roptat>ah indeed
<raghavgururajan>Hello Guix!
*civodul just reviewed a bunch of one-month old patches
<roptat>mh, I can't build from core-updates-frozen's checkout: guix build: error: gcry_md_hash_buffer: Function not implemented
<attila_lendvai>i need to access some files from a git repo in a service. one solution is to copy the files (small text files) into the .scm file, and use plain-file, but i could miss when upstream changes the files. is there something like local-file but gets the content from a git repo?
*avp sent a patch to the ML that updates guile-udev to 0.2.0 two days ago
<jpoiret>roptat: can you reproduce with a pure guix environment?
<roptat>yeah, unless I need recompilation
<roptat>in case that matters, I'm building the core-updates-frozen branch of a guix checkout from a foreign distro, where guix is at a recent core-updates-frozen commit
<jpoiret>doesn't look like there was an update to libgcrypt or guile-gcrypt
<cryptograthor>booted up a fresh install of guix, and my wlan0 interface isn't
<cryptograthor> available. How would I figure out whether this is a "go figure out some
<cryptograthor> driver to install" problem
<sneek>notmaximed: Greetings
<roptat>cryptograthor, maybe you can find a reference to the driver in your system log? (/var/log/messages I think)
<notmaximed>attila_lendvai: file-append + origin with git-fetch?
<attila_lendvai>notmaximed, i'm struggling in that direction. i'm here: (with-store store ((git-fetch (git-reference (url "") (commit "v0.6.0")) 'sha256 (base32-string->bytevector "1ksv494xpga27ifrjyn1bkqaya5h769lqb9rx1ng0n4kvmnrqr3l")) store)) failing that it's not a base32 string
<attila_lendvai>this works: (with-store store ((git-fetch (git-reference (url "") (commit "v0.6.0")) 'sha256 (nix-base32-string->bytevector "1ksv494xpga27ifrjyn1bkqaya5h769lqb9rx1ng0n4kvmnrqr3l")) store)) in the sense that returns a derivation that i don't know how to build
<notmaximed>two comments: why 'with-store'? And: not 'sha256 (nix-... "hash") but (sha256 (base32 "hash")), like with origin objects used as source for packages
<attila_lendvai>notmaximed, i'm clueless, messing around in the dark, and there aren't many examples for git-fetch in the repo
<notmaximed>‘(guix)Invoking guix package’ has an example on how to use 'origin'
<attila_lendvai>also, there are two git-fetch'es: guix/git-download and guix/build/git
*attila_lendvai looks
<notmaximed>Usually, there is no reason to manually cause a build of a package (or origin or whatever) with with-store & friends. Instead, you'd insert the (file-append ...) in the appropriate place. E.g.,
<notmaximed>#~(invoke #$(file-append bash-minimal "/bin/bash") (file-append ... "/some/shell-script")) from activation code
<notmaximed>(except for debugging & testing of course, then with-store & friends makes sense, though I don't know the details on how to use these macros and procedures)
<notmaximed>sneek: Greetings
<attila_lendvai>notmaximed, thanks! that looks like what i want. but what about the ... part? that is the git-fetch part, right?
<notmaximed>Which ... part? The (file-append ... "/some/shell-script")?
<attila_lendvai>FTR, i can't make (sha256 (base32 ...)) to work. it's a functional context, and i don't know where those macros (?) should come from
<notmaximed>In that case, the origin object (which uses git-fetch in this case)
<attila_lendvai>notmaximed, yes, there.
*attila_lendvai greps the guix repo
<notmaximed>attila_lendvai: what do you have as code, currently?
<nckx>Hi notmaximed! Do you use your eID on Guix System and if so, how?
<nckx>I am having all the success that can be expected, which is to say, none.
<notmaximed>nckx: I think I tried once, and failed
<notmaximed>Though I have had some success in the past on Debian with GPG and possibly some other packages
<attila_lendvai>notmaximed, nothing. i mean, i have a WIP service in the nonguix repo that works, but now i'm facing this chellenge. all i have is the form i pasted above, playing around in geiser.
<attila_lendvai>but i'm on to something here with the origin object. let me play around a little...
<nckx>notmaximed: I'll keep poking at it (all I need is for it to work in Firefox/IceCat). Thanks.
<notmaximed>notmaximed: I mean, what form do you have at the moment?
<notmaximed>I can't help with ‘(sha256 (base32 ...))’ if I don't see the context in which it is used
<notmaximed>A possibly incorrect guess: there's a nesting issue.
<raghavgururajan>nckx: What's eID?
<ngz>How can I test the latest installer (from an empty vm)?
<notmaximed>Software for Belgian identity cards.
<civodul>ngz: you can build an image with "guix system image -t qcow2 gnu/system/install.scm"
<raghavgururajan>notmaximed: Nice!
<notmaximed>attila_lendvai: IIUC, sha256 is neither a macro nor a procedure.
<civodul>and then you run that in qemu, with an extra disk
<notmaximed>Instead, it is part of the 'origin' syntax
<raghavgururajan>notmaximed and nckx: Was your failure with smart-card reader?
<ngz>civodul: as in (info "(guix)Installing Guix in a VM")?
<ngz>(at the end of the section)
<civodul>ngz: looks like it, yes
<ngz>civodul: OK, thanks. Trying it
<notmaximed>There was a failure _somewhere_. Unsupported smart-card reader, misconfigured software, missing software? I don't know what was the case.
<raghavgururajan>I see.
<raghavgururajan>I tested this ( and currently using it.
<notmaximed>is that with a Belgian ID card?
<raghavgururajan>I used it with a card for gpgkeys.
<raghavgururajan>The card said ISO something.
<lfam>Attacker-controlled memory corruption in NSS
<lfam>"This vulnerability does NOT impact Mozilla Firefox. However, email clients and PDF viewers that use NSS for signature verification, such as Thunderbird, LibreOffice, Evolution and Evince are believed to be impacted."
<lfam>I wonder if we shouldn't be using the ESR release
<raghavgururajan>ISO 7816-4,-8
<lfam>I can't look into the NSS thing now, but I'll try dealing with it later if nobody else beats me to it!
<nckx>Hi raghavgururajan. The failure is not with the reader hardware (a Digipass 870 which is well-supported) and I don't think it's with pcscd either. I simply can't get IceCat/Firefox to see the module (‘await browser.pkcs11.isModuleInstalled("beidpkcs11")’ fails, for example). I tried to adopt some wrappery from the Nix package but no luck so far.
<nckx>Running eid-mw's eid-viewer tool (which simply displays some info on the card and allows you to change the PIN) works fine, hence why I suspect the browser <-> pkcs11 interface.
<raghavgururajan>Ah I see.
<raghavgururajan>Any luck with ungoogled-chromium?
<nckx>Until I get really desperate (I will have to submit my taxes soon :-/) I'd strongly prefer not to run that on any of my machines.
<attila_lendvai>notmaximed, yay! i managed to cat the file from the service activation form. your guidance is much appreciated!
<nckx>I'll probably just boot a Trisquel/Debian live CD rather than running Chromium.
<raghavgururajan>Is it because of the nss vulnerability or not a fan of chromium?
<lfam>I'm surprised that chromium uses nss
<nckx>‘Not a fan’.
<lfam>Shows what I know
<jbv1[m]>zimoun: will take a look in a couple of weeks, I hope it's easier that 1.5 -> 1.6 but this scares me a bit
<wigust>hi guix
<nckx>Pff… policiesJson = writeText "policies.json" (builtins.toJSON enterprisePolicies); # where enterprisePolicies is a Nix attrset
<nckx>I don't even miss Nix and seem to remember it with rose-tinted glasses anyway.
<davidl>nckx: hi, can you give me some idea what's needed for the bash-bcu package to be merged? I'd be very happy to wrap up thinking about following-up on that patch.
<zimoun>civodul: you might be interested by because multiversionning and friend. :-)
<ekaitz>Здравствуйте PotentialUser-31
<zimoun>jbv1[m]: yeah, I read today all these notes and I was a bit… hum?!
<zimoun>jbv1[m], efraim: keep me in touch if you work on updating julia. :-) Let avoid boring duplicate work! ;-)
<PotentialUser-31>Столкнулся с проблемой при обновлении системы, при гуглении подобных статей на форумах не нашёл, быть может кто-нибудь сталкивался: guix pull error: failed to resolve address for . Насколько я понял
<PotentialUser-31>система не может получить доступ к ресурсу, однако интернет есть и через браузер ссылка открывается
<PotentialUser-31>Пинг гугла и прочего проходит спокойно, но при попытке обновиться выводит "Временный сбой в разрешении имён
<cryptograthor>On a fresh install, something funky is happening with my wireless; ifconfig doesn't show my wlan0 interface. /var/log/messages has many instances of the error: `iwlwifi direct firmware load for /*DEBLOBBED*/ failed with error 2`. What should I try?
<roptat>cryptograthor, you said wifi worked in the installer? which installer did you use?
<PotentialUser-31>Проблема решилась, спасибо!
<cryptograthor>using that iso
<roptat>cryptograthor, ah I see, that's not the official ISO, I think it uses a different kernel that has some nonfree blobs, including for your wifi driver
<roptat>but for some reason, it installed with the libre-linux kernel that doesn't have any non-free blob
<dhruvin>PotentialUser-31: it seems you need help with something, but I don't know your language. can you try english?
<roptat>dhruvin, too late :/
<roptat>hopefully "failed to resolve address" is only a transient error
<ekaitz>dhruvin: PotentialUser-31 already said problem is solved so I guess it was just a temporary network issue
<ekaitz>he even said thanks :)
<dhruvin>ekaitz, roptat yes, just translated their last message.
<roptat>ah, I don't speak Russian, though I recognize a few words
<ekaitz>I recognized "thanks" and "problem"
<abrenon>let's assume "reshilas" must mean "solved" ^^
<roptat>hello at the beginning and a random "resource" in the middle somewhere too
<paren>Hi Guix :)
***paren is now known as unmatched-paren
<unmatched-paren>oops nickname
<abrenon>see you folks
<jgart>Hi Guixers, has anyone tried packaging caddy before?
<jgart>If not and you're interested in working on packaging caddy together just get in touch
<dhruvin>about a month ago, I wrote a guide on guix image for
<dhruvin>if anyone's interested, i'm looking for feedback (on both the guide and build image)
<jgart>Hi dhruvin, I'm hosting a guix documentation meetup on December 11. It would be great to have you to discuss more.
<jgart>I'll take a look at the guide you linked above, thanks!
<dhruvin>jgart: i'm interested. where will it be hosted?
<jgart>It will be hosted on Big Blue Button and we'll pair program over ssh on a Guix System Server (usually facilitated by tmate).
<jgart>I have been doing the meetups at 2PM ET. Is that time good for you?
<jgart>I was thinking about possibly doing it 2-3 hours earlier. I have a friend that lives in Kenya who would like to come and I would like to accomodate him. Trying to find a time that will work for everyone involved. I'm flexible
<dhruvin>i work in IST timezone. 2pm ET is 12am IST i believe. 2-3 hours earlier would be better.
<dhruvin>0:30 am IST*
<jgart>These are usually low key meetings of any where from 3-7 people who work on guix together. That's the usual turnout which I'm happy with. It's a comfortable size to work productively. BBB has breakout rooms that allow us to separate into different groups if we want to divide some work amongst ~7 people
<dhruvin>jgart: i'm a non-native english speaker, so i'm not entirely sure if i can contribute much, with regards to documentation.
<jgart>That's not a problem
<jgart>You've shown already that you're contributing to documentation efforts. That would be invaluable to our mission and could use your expertise.
<jgart>dhruvin, How about 11:30 AM ET?
<roptat>dhruvin, I also participate in the meetings and I'm not a native English speaker
<roptat>now that conflicts with my lunch time :p
<jgart>I'm Cuban American, I grew up speaking Spanish and English. Spanish was my first language.
<jgart>roptat, would you still be able to make it? haha
<dhruvin>jgart: that works for me
<roptat>jgart, with an empty stomach :p I wake up pretty early, so I wouldn't mind starting even earlier
<jgart>roptat, I submitted the application to LibrePlanet for the Guix Workshop two days ago.
*jgart 🤞️
<roptat>yay :)
<jgart>roptat, What time do you prefer?
<roptat>10 or 10:30am would work best for me
<jgart>dhruvin, would 10:30am work for you?
<jgart>Is there a theme for docs meetup that we would like to touch on?
<jgart>dhruvin, great!
<jgart>10:30AM it is!
<jgart>Just food for thought. There's so much that can be improved in the guix docs such as language specific advice/workflows for using guix as a dev tool in software projects and more. If you have any suggestions feel free to share here or on the mailing list.
<jgart>I think someone had mentioned wanting to add something to the cookbook here yesterday
<roptat>jgart, now we have dhruvin's image documentation, and we had some improvements on profile sourcing (confusion caused by having two profiles, etc) on the Getting Started page
*jgart checks the logs
<jgart>roptat, You're referring to this page?
<dhruvin>i was interested in documentation aroudn `guix home`, i checked it two months ago, not sure how much it has been updated since then.
<roptat>jgart, yes, and also trick users into opening it :p
<jgart>roptat, Ah right. Yes, I remember that conversation
<jgart>dhruvin, Yes, `guix home` documentation could use some more love. Although, I know it's been active recently regarding docs. I'll have to check what has happened since and get up to date on the patches submitted so far
<jgart>roptat, random question: do you use any language servers with neovim?
<jgart>Nicolas just merged this patch:
<jgart>Updating the deprecated python language server in guix
<jgart>roptat, what are your thoughts on language server protocol overall, if you don't mind sharing
<dhruvin>jgart: i believe you requested guix image on, right?
<jgart>roptat, I just tried this one recently and it's nice that it centers around reusing a classic tool in the python community:
<jgart>dhruvin, I did a while ago, yes
<jgart>I know someone had added it
<jgart>was that you?
<jgart>Ah very cool!
<jgart>congrats on that!
<jgart>That was important work to be done
<dhruvin>thanks :)
<jgart>dhruvin, How has it been working?
<jgart>I haven't tried it yet
<jgart>I don't think I have access to it unless I'm a paying sourcehut user?
<dhruvin>it's been working great (at least for me, and one other person)
<jgart>dhruvin, I set this up the other day briefly:
<dhruvin>yes, is for paying users only. (this is due to crypto stuff)
<jgart>Oh ok
<dhruvin>the image is built daily. it has been two months and it only failed two-three times.
<jgart>A friend has one self-hosted and he's using it with Guix System:
<apteryx>civodul: hello! thanks for the pointers w.r.t. cross-compiled rust. I've replied with some debugging challenge involving the rustc-produced program taking a lot of time to execute for some reason
<dhruvin>about laminar: haven't heard of it, will see it.
<jgart>Guix System has a service-type for it
<jgart>So it should be pretty easy to deploy it. I've only tested it manually
<dhruvin>that's better, i'll try it locally too
<podiki[m]>dhruvin: what do you use the sourcehut guix image for? or what do you think are good use cases?
<dhruvin>podiki[m]: it's not much right now. i use it to build and publish my website. it used to be on web, gemini, ipfs, and on tor. now it's just web and gemini, so guix environment is a bit overkill for it.
<podiki[m]>any future plans you think guix will in particular would work well for? (I'm all for using guix in lots of places, just curious if there are any special benefits to see here in the future)
<dhruvin>podiki[m]: one use-case i thought about is reproducible research. you write your paper, and you have your code to accompany it. after every commit sourcehut will build your code, test it, generate a pdf of a version of accompanying paper as artifact/publish it to a journal (if it is a release commit).
<dhruvin>this is a bit blurry on details, but i hope you get a gist.
<podiki[m]>yeah, reproducible and automatic analysis/figure/whatever for research sounds good
<dhruvin>podiki[m]: i thought about creating and publishing docker images using guix from the build image. someone else has mentioned their interest about it, here, months back.
<roptat>maybe guix as an organisation could publish base images on dockerhub?
<roptat>would that be useful?
<dhruvin>one problem that i haven't found solution for, is stale dependencies. it feels that docker (images in general) encourages them by design. i have seen people put whole kitchen along with the kitchen sink inside their docker image. any ideas around it?
<lilyp>from my personal experience no
<dhruvin>podiki[m]: add singularity images to the list of use-cases as well
<lilyp>i.e. no to dhruvin's "ways around it"
<lilyp>imho if a project requires docker for deployment (as in the software won't typically build or run outside a container), then you have a severely flawed setup right there
*jgart thinks we need a guixhub for guix container images
<podiki[m]>perhaps some way to force an update or check for updates with a warning when launching an image? but it is a bit of a tension for having something packaged to stay as is
<lilyp>also, you might not even want to update
<podiki[m]>lilyp: agree, when I see self-hosted stuff that is all "load the docker image" and nothing else...I run away
<jgart>podiki[m], I react the same way
<lilyp>consider e.g. the 10 year reproducibility challenge
<podiki[m]>would be good to know if it is out of date at least
<lilyp>what if you want GCC 7 in 2030?
<jgart>Would it be possible to produce a container format for guix containers?
<podiki[m]>preservation is (should?) be different
<jgart>What does that container format look like?
<jgart>Does it currently exist?
<lilyp>jgart: It's called config.scm
<jgart>lilyp, so it's a file?
<lilyp>pretty sure you can stuff that into a tarball or iso
<lilyp>to answer roptat: maybe, but it depends on your use case
<jgart>Should we be distributing reproducible/declarative files containing container deployment specifications instead of the target format(s) that they produce?
<lilyp>We already do that
<lilyp>see the .tmpl files in etc/configuration for example
<jgart>But we don't have a dockerhub like registry
<jgart>Or do we?
<jgart>what can substitute for dockerhub in guix world?
<lilyp>That's unnecessary, we have a CI
<jgart>cool, that makes sense to me
<lilyp>apart from grafts, you can prebuild anything on a more powerful machine than your own
<jgart>so CI distributes the container images built from the config.scm
<lilyp>I don't think we do full-blown config.scms
<jgart>And we provide those container images to others from the CI
<lilyp>we do the individual packages though
<dhruvin>it's quite easy to create a container and use some package inside it, it's quite close to the intended use of docker.
<jgart>Why don't we do full-blown config.scm yet?
<lilyp>because that'd be insane
<dhruvin>dhruvin: *with guix environment
<jgart>lilyp, how?
<jgart>Let me give an example of my use case
<lilyp>there's 2^k environments you'd have to build, k increasing
<jgart>I have this app that launches interactive notebooks in Guix containers:
<jgart>It is a flask application that currently depends on nginx as a reverse proxy
<jgart>I would like to provide a "docker image like experience" but with a Guix System container image
<lilyp>if it works inside `guix shell', then you can easily provide a `guix pack' with an entry point
<jgart>so that someone can deploy the whole app in a Guix System container by just running one command to build it
<GNUHacker>anyone know wich guix package have dsniff (arpspoof or dnsspoof)?
<jgart>lilyp, The app currrently depends on a running nginx server
<dhruvin>GNUHacker: not sure, but you can always check via guix environment/shell
<jgart>So, I would need a guix shell that also manages that nginx service in that container
<lilyp>then your README is broken
<jgart>Yup, it currently has that part left out.
<jgart>I'm currently managing the nginx reverse proxy with in a docker image. I had it in the README before and for some reason I removed it.
<jgart>I'd like to not use docker at all though and only guix to manage the nginx server
<jgart>Anyways, that's an open problem I'm trying to currently solve
<dhruvin>can't you have a shell script as entry point that starts nginx and your service (along with other things)?
<jgart>dhruvin, called from a guix.scm file you mean?
<dhruvin>wait let me think :|
<jgart>I currently provide a manifest.scm but that only puts you into an environment that has all the python deps to run the flask app manually
<lilyp>dhruvin: no, for that you'd need nginx as a user service or a system config providing it and `guix system vm' or the like
<jgart>That assumes (or currently is not assuming) that you should have the nginx server running as a reverse proxy. I provide a docker-compose file for that but I'd like to loose the dependency on docker all together for the nginx reverse proxy. That's the goal
<dhruvin>lilyp: if i have nginx package installed, i can always start it with config, right?
<jgart>Arun Isaac has something he's been working on regarding deploying a python app in a guix system container as a service. I just wonder if anyone has also done that work before?
<jgart>Ideally, I'd start the guix system container and shepherd would run nginx reverse proxy as well as gunicorn server for the flask app
<roptat>the CI is already building at least one image: the installer, from master
<roptat>although it's not a docker container
<lilyp>dhruvin: oh sure, you can manually do everything, but whether nginx will allow it or whether you get port 80 as unprivileged user is a different question
<jgart>roptat, yup I thought I had seen something like that
<lilyp>roptat: doesn't it also build the qemu vm?
<roptat>so a cuirass instance could build docker images, or other types of images
<jgart>lilyp, yup. those are some of the issues I'll have to figure out with deploying in a guix system container
<lilyp>at least for releases?
<roptat>I'm not sure, I think the release artifacts are built from the Makefile by a maintainer
<dhruvin>here's my attempt: you have binderlite, nginx, and startup-script (will get to it) in a manifest.scm. the startup-script is nothing but a package (or file from store) which is a shell script that starts/configures both nginx and binderlite. the manifest gets packed as docker image. will that solve your problem?
<jgart>I'd prefer to not use docker at all but just as a full Guix System Container built from a config.scm
<ngz>hmmmm, it seems root password is mandatory in the installer.
<roptat>but what's a "full Guix System Container" if not a docker image?
<podiki[m]>building a demo live image (for use via bootable USB or VM) with a desktop environment would be nice; maybe even one of the templates we have already
<podiki[m]>nice to show off/have people try Guix
<lilyp>roptat: I think they're refering to the "container" subcommand of guix system, or likewise the --container flag to guix package
<roptat>which don't produce any "image"
<lilyp>which might as well use magic to spawn the container
<roptat>they're using linux namespaces
<lilyp>As I said: magic
<roptat>docker also uses that, but the "docker container" is an archive with the content of the docker. guix shell --container just grabs what it needs from the store, but doesn't produce an archive
<jgart>roptat, yup from what I learned it looks like they don't produce any image
<jgart>roptat, > but what's a "full Guix System Container" if not a docker image?
<jgart>roptat, that's a very good question
<jgart>It's one I've been pondering
<roptat>with the same os configuration, you could have your CI produce a docker image, vm image, singularity image, ...
<roptat>give people choice :)
<jgart>should guix containers have its own image?
<jgart>I understand that it can produce all these other target images
<civodul>apteryx: oh, cool! i'll take a look at the debugging challenge
<civodul>i'll prolly still go with the short-term librsvg hack for now
<civodul>i need to catch up first
<jgart>But should guix containers itself also have a container image?
<lilyp>couldn't you theoretically "pack" your `guix system container' like you can pack guix packages?
<lilyp>which would at least give you the store contents as convenient tarball?
<dhruvin>images are .tar.gz, so yes
<roptat>jgart, I guess you could make a tar of all the store items needed to launch the container, maybe with a manifest
<jgart>It would be cool to leverage a tried and tested classic format like tar as the container format for guix containers
<roptat>then on the target, guix would extract the store items to your store, read the manifest and try to run the same guix shell --container command
<jgart>I was just wondering if there is something canonical for guix containers
<roptat>which might require some authorizing public keys for some items
<jgart>From my experience, guix containers seem to be very early stage/experimental as a container format compared to docker or podman, for example
<roptat>jgart, docker images are also tar archives :p
<jgart>Oh, cool I didn't realize that
<jgart>I hadn't looked that closely
<jgart>roptat, How'd you find that out?
<jgart>reading the source code for docker?
<jgart>I don't think it is common knowledge that docker images are tar archives, unless I'm out of the loop ;)
<jgart>very cool, nonetheless
<dhruvin>i learned it while doing YoloOps for YoloStartups in my past life. :)
<jgart>dhruvin, cool! ha
<roptat>I don't remember
<jgart>roptat, dhruvin do you happen to have a blog post or other resource that references that notion/explains docker containers from the perspective of it being a tar archive?
<roptat>oh, unrelated, but this week-end I'll push an update to our translations. If you want your language to be part of it, there's still a few days to help: :D
*jgart searches
<jgart>roptat, is tamil included?
<jgart>I think Arun Isaac might be interested
*dhruvin looks up
<roptat>jgart, we have some translations:
<jgart>ah cool
<ngz>I encounter a strange error with the installer: at the end of the process, I'm offered to edit the generated config.scm. I add #:options '("whatever") to the keyboard-config line, save and resume install. Then I get: "error #{\x2019;}# unbound variable". Does that ring a bell?
<jgart>ngz, I've heard people complaining about the installer. Might be best to do an install from the terminal following the guide
<roptat>ngz, is that the stable installer, or the latest?
<jgart>Unless the installer has been fixed... but it doesn't sound like it ;)
<ngz>jgart: Actually, I'm testing the installer. It would be counter-productive to avoid using it in that case :)
<ngz>roptat: Both I think
<jgart>Oh ok, didn't no that was what you were doing
<civodul>ngz: no, weird; anything in /tmp/*.log?
<roptat>is that from a build, or directly when reading the config?
<apteryx>weird, selenium appears broken with chromedriver only in headless mode on core-updates-frozen
<ngz>civodul: how can I access that?
<ngz>roptat: I built a qcow2 image from install.scm.
<ngz>roptat: for stable, I simply downloaded ISO from website.
<civodul>ngz: from the console, e.g., ctrl-alt-f3 and from there you can do things
<dhruvin>jgart: at a risk of being too vague, i found about it here:
<ngz>civodul: no log file in /tmp/. I just have a last-installer-error file
<civodul>ngz: ah yes, that one, what does it say?
<jgart>does anyone know if there an easy way to download a patch into the current directory that I'm viewing in debbugs-mode in emacs?
<jgart>dhruvin, thanks!
<civodul>efraim: 68d090002a1a5623494006fca3e2c2c97d3ff676 is unconditionally disabling tests of the sandbox feature AIUI (that is, the test runs, but it's not testing the sandbox feature as it should); should we make narrow it?
<roptat>ngz, I meant, does the error appear during a build, or while reading the configuration you modified?
<ngz>roptat: I appear when I try to read the modified configuration.
<ngz>I.e., when the installer tries to read it to proceed.
<ngz>it appears*
<roptat>do you have more context around that error message?
<ngz>I think that's about it. Let me reproduce it.
<notmaximed>sneek: later tell ngz: #{\x2019} is the symbol consisting of the character ’ (a curly quote)
<notmaximed>sneek: later tell ngz: Probably missing "quotes" around a string, or using the wrong type of quotes?
<sneek>Got it.
<notmaximed>sneek: later tell ngz: (symbol->string '#{\x2019;}#) ---> ’
<roptat>notmaximed, er, no need to use sneek for talking to ngz, you know
<ngz>Oooh, you're right.
<jgart>Is the source for sneek available somewhere?
<ngz>Dang, what a crazy layout: it provides ’ instead of '
<jgart>The sneek bot I mean
<ngz>Sorry for the noise =/
<notmaximed>I was looking on (which doesn't have timestamps) after not being on kiwiirc, so I used sneek in case ngz left
<gnucode>Hey guix!
<jgart>TIL: figured out how to download a patch with debbugs, silly simple. Just save the file like any other. :)
<jgart>gnucode, jbranso?
<podiki[m]>I should be able to copy a file from an input in a build phase, with just copy-file right?
<gnucode>jgart: yup. :)
<gnucode>jgart I've also been "jab" too.
<podiki[m]>but in this case the store path is the file (guess it is from being a file like object) and copy-file then complains no such file...
<podiki[m]>trying with a test case of hello's bin/hello also says that, any ideas what I'm missing?
<jgart>gnucode, I've been meaning to get back to you. I'll email you soon.
<ngz>Question about keyboard layout: does anyone use a recent (max 5 yo) Lenovo Thinkpad? If so, how do you deal with the obnoxious PrtScr key, XKB-wise?
<podiki[m]>nevermind, was actually not the copy-file but a similar sounding error elsewhere
*jonsger finally pushed icedove 91 :)
<KE0VVT>jonsger: Thank you! Where is your tip jar?
<jonsger>he, a tip of time would be maybe more helpful ^^
<the_tubular>Why does guix needs so much storage space ?
<the_tubular>And how big should my VMs be approximately ?
<jonsger>with 40-50GiB you should be safe :)
<jonsger>it depends a bit on your use case. On a server 15GiB may be enough...
<the_tubular>Why does it need that much?
<the_tubular>I have a server right now, using 39Gb ^^
<jonsger>because you could have multiple generations of packages at the same time on your system. So you could roll-back to older generations
<jonsger>but `guix gc` will be your friend, if your are lean on storage
<KE0VVT>How do I keep my system from going to sleep? I am using GNOME.
<KE0VVT>I only want it to go to sleep when I shut the lid.
<KE0VVT>or is low on power
<KE0VVT>I hope GNOME Settings work on Guix.
<lispmacs[work]>KE0VVT: on my GNOME, I can hit super key, and type in power to get to the power settings
<lispmacs[work]>KE0VVT: you may need to install gnome-tweaks package if you need advanced configuration
<KE0VVT>lispmacs[work]: Automatic suspend → on battery power worked.