IRC channel logs


back to list of logs

<luis-felipe>vivien: I haven't tried your patches, but one thing that have helped me deal with test errors is changing the test phase to run the test as indicated by each project.
<luis-felipe>vivien: For example:
<luis-felipe>vivien: Another thing is that when the origin is not a git repository, sometimes (or almost always?) the test suites are not even included, so the test phase fails.
***NoClu_ is now known as NoClu
<podiki[m]>okay, think I have a minimal example that builds something that tries to refer to the old (non-grafted) version
<podiki[m]>I don't know if it is this specific package building or perhaps a bug in how it is being build (not in the usual "guix build" way)...but should this be sent to the security email since it involves perhaps a problem with grafts?
<marusich>While waiting for Guix to build after invoking "make -j", I noticed that build-aux/compile-all.scm was not using all my cores (at most, it was only using about 8 out of 32). It seems the cap might be coming from the hard-coded cap of 8 workers in compile-files:
<marusich>That is interesting, but I was more curious about this hackery: This apparently reduces peak memory consumption during the build by building the .go files in subsets.
<marusich>However, I don't understand how it accomplishes that task. When I invoke "make -j", what stops Make from running make-core-go, make-packages-go, make-system-go, and make-cli-go in parallel?
<marusich>I'm just curious. Does someone hre understand how it is that this hackery causes the .go files to not get built all at once? I don't understand it, but I would like to.
<marusich>I get that it creates multiple targets, and each of the targets builds smaller groups of files. But I don't understand what is stopping Make from just building all of those targets in parallel when I run "make -j".
<AIM[m]>Hey, Is there Gnome Tweaks Tool for Guix?
<AIM[m]>I searched online and found that it's gnome-tweak-tool
<AIM[m]>But it ain't installing for some reason
<AIM[m]>It says package not found
<jgart>I started a module for caddy server and packaged one dep not in Guix:
<acrow>Try gnome-tweaks, AIM
<jgart>Here's a todo for it in case anyone would like to collaborate on caddy server:
***califax- is now known as califax
<Guest82>if I symlink a directory/executable from my ~/.guix-profile will the symlink break if the package is upgraded?
<AIM[m]><acrow> "Try gnome-tweaks, AIM" <- Ohh
<AIM[m]>Thanks acrow
<sneek>bdju, you have 1 message!
<sneek>bdju, podiki[m] says: I see flatpak has anki, that's another option (can can share folders from host system to the flatpak with permissions)
<bdju>podiki[m]: I would rather use another PC than docker/flatpak/appimage/snap/a virtual machine. bigger problem is still knowing which folders to move over and which ones contain what data
<jgart>singpolyma, does this fix the go importer?
<singpolyma>jgart: yeah, the v3 there should fix several issues with the importer
<jgart>any idea of how I can add to guixrus channel as a pre-release?
<jgart>what might be a good approach?
<jgart>since guixrus is not based off of the main guix checkout
<jgart>singpolyma, I'm working on caddy server and could use a better go importer
<jgart>caddy has many many deps
<singpolyma>jgart: should be able to apply and use pre-inst-env to use it before merge :)
<jgart>ah ok, so don't add it to guixrus just add it to a guix checkout?
<jgart>that definitely sounds like the path of least resistance
<jgart>I'll give that a go
<jgart>I was hoping I could include it outside the main upstream tree somehow
<jgart>but not sure what would be the best approach without vendoring in the whole importer code
<singpolyma>Yeah, not sure, I always just run it out of my local checkout
<jgart>I'll just go with `pre-inst-env` as you suggested to get the deps while I wait for 52362 to be reviewed/resolved
<jgart>would it be better practice to return #f instead of 'unknown-license! in importers?
<lilyp>unknown-license makes people think and look it up themselves
<lilyp>#f just works and may give them blobs
<marusich>In the guix, there is a line that says: %.go: make-go ; @:
<marusich>Can someone tell me what that @ is doing? I can't figure it out. I recognize the rule syntax ((make) Rule Syntax) but do not understand what the @ is doing.
<marusich>This line:
<marusich>Ah OK, so the recipe is the single shell command : (i.e. the null command), and it is prefixed with @ to prevent it from being echoed?
<lilyp>yup, it's a nothing burger
<lilyp>the body probably just exists to prevent another body elsewhere, i.e. to make the alias clearer
<marusich>To answer my earlier question about how arranges not to run make-core-go, make-packages-go, etc. in parallel, it seems to me the answer is surprisingly simple, and that is: an explicit dependency is made, for example, from make-packages-go to make-core-go, so that make-core-go must be executed entirely first before executing make-packages-go. The same is done for all the make-*-go phony targets.
<marusich>In fact, you can see that even after you have built everything, these targets do get run, and they get run in serial. It takes a few fractions of a second, but you will see "Compiling Scheme modules..." printed 4 times, even when there is no work to do.
<podiki[m]>I think the problem I am running into is something with propagated inputs that have a replacement and doing a union-build
<gnoo>How do you make guix say cc is gcc ?
<gnoo>i.e. call the current compiler(gcc) when cc is invoked
<podiki[m]>ah I see the problem and the fix
<podiki[m]>sneek: later tell nckx I think I found the problem, in short fontconfig (and at least apr-util) propagate expat explicitly, looks like it should be changed to the replacement
<lfam>Hm, that would be a new failure mode
<lfam>I wonder if we've grafted propagated inputs before? It seems like we *must* have
<lfam>It does the right thing when installing e.g. fontconfig into a profile, right?
<lfam>Is it just a problem for (guix build union)?
<podiki[m]>yeah, building shows the correct thing
<podiki[m]>looking back in the logs, I see other propagated inputs with their replacement instead (eg. older gnutls ones)
<robin>gnoo, in package definitions? often (setenv "CC" "gcc") before the configure phase is enough; if it actually hardcodes the 'cc' name, i'd use substitute* on the relevant file(s), as with the 'sparse' package
<podiki[m]>union-build takes (or is used) where it looks at build-inputs, so I think that's where it gets the direct store directory of the un-replaced package?
<gnoo>robin: no, on the shell, i've got quite a few scrips that use 'cc' as a program name
<podiki[m]>lfam: I have a minimal working example, wasn't sure if I should just paste it (not a security hole per se, but)
<lfam>podiki[m]: It's entirely possible nobody tried to build a union with these types of packages before
<podiki[m]>curiously it does get the replacement package, sort of; but tries to include the older
<podiki[m]>I haven't tried to change the propagated input to see that it fixes this, but seems it would (bit late now for much building)
<lfam>Can you share one of the older examples?
<podiki[m]>eg c5df560fd3762c0dbe99562f52223c73d445e597
<lfam>Huh, TIL
<lfam>I must have done a hundred grafts and I don't recall ever doing that
<podiki[m]>me too; a lot
<podiki[m]>propagated-inputs = the devil, etc, huh?
<podiki[m]>(me too to the TIL)
<lfam>If this is really a problem, it should be mentioned in the manual section Security Updates
<lfam>Because that commit makes it seem as if grafts aren't effective in "normal operations", such as building profiles
<podiki[m]>I found this due to using a union-build, I do see that in the code for some build systems and packages, but I guess hasn't happened with a propagated replacement in an input?
<lfam>But, you're only having trouble with building unions, which is kind of esoteric
<podiki[m]>well let me double check...
<robin>gnoo, oh, the simplest way is probably to export environment variables BASH_ENV and ENV set to, say, ~/.shenv, and alias cc=gcc there
<lfam>So, the situation definitely needs some clarification, after the immediate problem is solved, podiki[m]
<podiki[m]>yeah, seems fine in e.g. guix shell fontconfig (correct libexpat in profile)
<lfam>Overall, changing the inputs of packages is exactly what grafting is supposed to help us avoid
<podiki[m]>the union also gets the right libexpat, but one of the links tries to go to the wrong version
<podiki[m]>should I send the details and the brief code to the security list? (just in case?)
<lfam>And of course, we can't make any changes to packages like apr-util, which have a huge number of dependents
<lfam>This isn't a security issue IMO
<lfam>And even if it was, it's no longer private
<lfam>Like, the union doesn't build successfully, right?
<podiki[m]>perhaps a workaround in union-build?
<lfam>I think others (you? :) ) will have to come up with the solution
<podiki[m]>no it builds, but the final library in the link chain won't exist (points to wrong version in the replacement expat)
<lfam>I'm not sure what you mean by that. The final library in the link chain?
<robin>gnoo, or add a trivial #!/bin/sh <<newline>> exec gcc "$@" wrapper to someplace in $PATH (maybe create ~/bin or ~/.local/bin and prepend it to $PATH in ~/.profile or ~/.zprofile, etc., depending on shell)
<podiki[m]>well for my purposes I would just put a check in to manually change the expat input or something
<podiki[m]> -> -> (I guess not chained in our build, but that's what I meant)
<lfam>That's really weird
<podiki[m]>so the final full version number is the old one
<podiki[m]>but in the replacement expat store dir
<podiki[m]>right? super weird
<lfam>Wait, I thought they had the same soversion
<lfam>I guess not
<lfam>I must not understand so-versioning
<podiki[m]>1.8.3 vs 1.8.1
<robin>(...which i happened to have in ~/bin already for some reason :))
<podiki[m]>I don't know enough to comment
<lfam>The ABI of the replacement package has to be compatible with that of the replaced package
<podiki[m]>the problem arose actually in doing a bigger union with the 32bit version, one of them gets the wrong cmake folder path
<lfam>I guess the "8" indicates compatibility
<lfam>Anyways, this is a good bug and should be reported ASAP
<podiki[m]>must be something union-build does? (black box to me right now)
<lfam>Not sure, I figured it was a simple symlink union
<lfam>And I figured it would error out if there were collisions, like when building profiles
<podiki[m]>I don't know enough about: grafts, union-build, sonames, ....
<podiki[m]>it isn't a collision I guess, it just 90% got it right
<lfam>It would definitely be a collision in a profile
<podiki[m]>like I said, I did get a collision with including i686 at the same time, but for what looks like a different reason; same idea I think of a version number going wrong
<lfam>For example, both expat 2.4.1 and expat 2.4.3 provide a path 'lib/'. So, you can't put both of them in the same symlink union. And that's basically what a profile is
<podiki[m]>doing guix shell with my test union build package goes fine
<podiki[m]>yeah, it is not getting 2 libexpat, just a wrong link
<podiki[m]>somehow it wants to create a link to in libexpat that is the newer version
<podiki[m]>it is very strange
<lfam>Well, like I said, it's a bug. It should be reported ASAP
<lfam>The bug is that the union builder handles the collision improperly
<lfam>Propagation is a red herring IMO
<lfam>We should never have to adjust the inputs list of packages that depend on a grafted package. That would mean that grafting is useless
<lfam>It will help a lot to include your package in the bug report. That's the easiest way to demonstrate the bug
<lfam>I mean, propagation is a factor in the manifestation of the bug. But it's not the problem
<podiki[m]>I don't know the exact cause or mechanism, other than I can see it in two packages that propagate a package that has replacement
<lfam>The union builder does have a collision handler, but by default it only warns about them
<podiki[m]>no warning in the log
<lfam>Maybe I don't understand it
<podiki[m]>I don't :)
<podiki[m]>I just find them
<podiki[m]>almost done with the email, late here, hopefully makes sense
<podiki[m]>sent; maybe someone will have a satisfactory explanation/work around when I wake up
<podiki[m]>night guix!
<gnoo>robin: thanks! i'll do that
<xelxebar>Well, that's sad, we can't build debugging symbols into haskell packages: Unrecognized keyword: #:strip-binaries?
<abrenon>moin guix
<vivien>Hi! I figured out my python issue: I was using the default check phase (python test) and not pytest
<dissoc>it seems like when i have a build fail i get "could not find build log for ..." any idea why i can no longer see the logs?
<vivien>And for the other package, as luis-felipe wrote, the test data aren’t distributed.
<xelxebar>dissoc: Odd. Is your local state dir the default /var? What does your /var/log/guix look like?
<dissoc>xelxebar: i think it was permission related. i didnt change them but maybe auditd did? im not sure but it seems to be working once i tried changing the permissions on /var/log
<xelxebar>dissoc: Okay. That's a good start. Did you look at the perms before overwriting?
<dissoc>xelxebar: yes. i compared it to other guix system i had working and noticed the difference
<AwesomeAdam54321>Is there a way to set environment variables of a service managed by the Shepherd? I would like to set a new environment variable to the existing environment rather than starting with an empty environment, which is what #:environment-variables does
<vivien>AwesomeAdam54321, what should dictate the environment variable value?
<vivien>Also, what "existing environment" are you referring to? That of root in a login shell?
<AwesomeAdam54321>vivien: the existing environment in this case refers to the environment inherited from PID 1
<xelxebar>dissoc: Cool. If you notice the directory flip perms again and you manually restore, it might be nice to monitor the directory with inotify.
<dissoc>xelxebar: good idea. i'll give that a try
<AwesomeAdam54321>vivien: what dictates the environment is (environ). What #:environment-variables does is use (environ) to set an environment with only the variables specified, however that's not what I'm looking for
<phf-1>Hello Guix! How can I inspect a .nar archive? I used guix --export -r > $pkg.nar
<phf-1>but apparently, some dependencies are not installed
<vivien>AwesomeAdam54321, maybe the service lets you customize the package that get its binary called. You could maybe override that to a new wrapper package that adds some environment variables?
<allana>Hi Guix! Any Golang-and-guix developers here? I'm not a golang developer, but I am considering packaging some-or-all of kubernetes. I'm curious to know about best practices. I have seen some golang monorepos that contain what should multiple guix packages, and am wondering if I should have a "source-only" ("build" stage deleted) package of kubernetes and then make guix packages for the different components that "inherit" from the source
<allana>packages. Is this the correct way? For example:
<allana>Where "kubectl" and "kubeadm" are normal packages, and "go-k8s-io-kubernetes" is a source-only package that does not build anything.
<AwesomeAdam54321>vivien: Sorry, I should have specified that I use Guix on a foreign distro. I managed to solve the problem by using the env command
<phf-1>So apparently, someone in 2018 had identical questions:
<civodul>Hello Guix!
<jpoiret>allana: i am not an authoritative source on the subject, but yes that should be best practice
<jpoiret>by the way, good luck with packaging k8s, it is huge
<phf-1>Hello! So ok, `guix archive' does not include propagated inputs but it's not obvious from the documentation. e.g.
<civodul>phf-1: hi! yes it's very low-level, and perhaps that's not what you need?
<phf-1>Well, I need to deploy a package and it's dependencies as documented by `guix pack'. unfortunately, `guix pack -RR' messes with `getcifsacl'
<phf-1>on the target machine, using `guix install $pkg' will install a binary that works well with `getcifsacl'
<phf-1>so I'm trying to send to that machine an archive because no network access (guix copy would not work)
<civodul>the target machine already runs Guix?
<phf-1>So I've 2 options apparently: using `guix archive' or using `guix pack' without the -RR options (strangely, I had problem making it work, but I must have been tired too)
<phf-1>No. But I hope that I can negotiate to make it run Guix.
<phf-1>I'm exploring option 2. i.e. Guix installed on the target machine and sending it a .nar archive.
<civodul>if the target machine lacks Guix, "guix archive" is of no use
<civodul>so "guix pack" is the thing
<civodul>did you report a bug already for the getcifsacl issue?
<phf-1>Not yet... but will do this wk eventually.
<phf-1>I think that I can get that target machine to install Guix hence option 2.
<civodul>in any case, you probably need to make sure the target machine runs nscd:
<phf-1>Foreign distro, CentOS 8, so, `guix pack' without the `-RR' should work I guess?
<civodul>both should work :-)
<civodul>then again, we'd need to see exactly what it is that doesn't work
<phf-1>ok, will make sure nscd is working on the target machine thx.
<phf-1>Ok, will try again with `guix pack' thx.
<attila_lendvai>could it be that the adb in Guix doesn't handle 2GB+ files? i get: "* cannot read '' *", and web searches are suggesting that it's a 32/64 bit issue...
<gnoo>phf-1: did you try with just one -R ?
<gnoo>also, there must be a way to create rpm packages from .tar.gz files, right? (or .deb as well)
<gnoo>if that's possible, you can omit -R all together
<phf-1>Yes but no success. Will try again and documenting each step carefully.
<rekado_>three more disks arrived. Still no word from the third supplier with the last disk.
<phf-1>gnoo: really? that's possible?
<rekado_>mothacehe: would it be possible to start with just 5 of the 6 disks?
<phf-1>It might help
<rekado_>and then add the last one to the group later?
<mothacehe>rekado_: great! yes i think btrfs allows to extend the raid easily
<gnoo>phf-1: yeah, -RR is only needed if you don't have sudo permissions
<gnoo>and making a package from .tar.gz files is something every distro (should?) support ootb
<phf-1>ok, well, how can I build .deb and .rpm from a package definition ?
<allana>jpoiret: thanks! There's a good chance that I won't package all of kubernetes, especially because I don't have a lot of time to do so. But I will be giving it a go over the next few weeks hopefully.
<rekado_>latest by monday I’ll install the disks.
<phf-1>I'm new to packaging so...
<gnoo>phf-1: no not from a package definition, find out how binary rpm packages are usually made and apply the same process to the tar file produced by guix pack
<phf-1>ok I see
<phf-1>thanks gnoo
<mothacehe>rekado_: thanks for your help, can't wait to stop having to kill the GC every single day :)
<gnoo>phf-1: turns out you can use a package called alien like so:
<gnoo>so you make guix pack output format to .deb (guix pack -f deb)
<phf-1>ok great, thanks !
<gnoo>just note that you can have only install one package using this method as explained in guix manual
<phf-1>One package and its dependencies (which are themselves packages) ?
<gnoo>to have more, you'll need to follow the rpm docs,
<phf-1>ok, so, I need to do this for all packages and install each package on the target machine?
<gnoo>just one package should be enough, since it contains the dependencies, making a package in this case is only so that you can use rpm uninstall later to remove the files
<gnoo>not for dependency management
<gnoo>and once you create a rpm file, you can use that in all the machines, no need to duplicate all the steps
<phf-1>Ok, better :)
<gnoo>or rpm upgrade to upgrade, assuming that's how you upgrade
<phf-1>ok great, dependencies are in the pack.
<phf-1>But Python complains that a few packages are missing.
<phf-1>I've just installed the .deb generated by guix pack -f deb
<phf-1>So, I guess that the PYTHONPATH should be modified using something like source .../etc/profile that is in the package ?
<civodul>phf-1: yes
<phf-1>Ok... it worked in the end...
<phf-1>thanks everyone ! We might get beat up a bit because we are late on the delivery... but in the end, it worked :)
<AwesomeAdam54321>What environment variables does the guix-daemon need other than GUIX_LOCPATH?
<ss2>hello, has anywone gotten cgit to work with git-http-configuration?
<ss2>so far I only get either on the same sub domain working, but not together.
<ss2>I'm trying to pick it out of the manual. Maybe there's a working example to look at?
<ss2>This is what I have: I've enabled fgciwrap-service-type too.
<luishgh>hi guix! i'm trying to package tree-sitter and don't know how to deal with its cli. i wanted to build it to a bin output (it is built with cargo and the library itself with make), but i would need to run a `cargo fetch` after the unpacking of the source code. however, from what i understood, build phases don't have network access. how would i deal with this situation? should i create another package for the cli and possibly use the
<xelxebar>luishgh: Nice! Just learned about GH's tree-sitter recently and been curious to poke around with it.
<xelxebar>Yeah, that explanation sounds like two separate packages to me.
<xelxebar>You shouldn't need to build anything just to fetch souces though. Another option would be to add an extra `origin' as an input.
<xelxebar>But since they use completely different build systems, separate packages is probably saner, especially if the library is useful on its own.
<luishgh>xelxebar: makes sense, thanks!
<ss2>hm, who’s admin on My mail isn’t going through. Unfortunately it looks like it posted the same mail a second time now. The first posting hasn’t gone through since two days.
<ss2>I modified my subscription two days ago, and am happily receiving from the list. Maybe something went wrong?
<phf-1`>Hello Guix!
<phf-1>So, what's the best short text in French that describes Guix and its benefits known so far ?
<phf-1>Or in English, but ideally in French.
<user_oreloznog>phf-1`: Hi! Maybe
<user_oreloznog>yw ;)
<civodul>phf-1: you might also like
<civodul>ss2: hi! the first message is usually in "quarantine", that's why it takes a bit longer
<civodul>subsequent messages will arrive directly to the list
<phf-1>civodul: Génial, merci :)
<civodul>on peut aussi parler français ici d'ailleurs
<abrenon>quoi ? mais on va faire fuir les non-francophones ! : )
<ss2>civodul: okay, so that implies to each mailing list individually? I had moved my subscription to another address.
<civodul>abrenon: nan je pense pas :-)
<civodul>ss2: yes, it's per mailing list
<ss2>okay – i’ll be patient then. #
<bricewge>Hello Guix!
<bricewge>Vu que je vois un peu de français sur le canal, j'en profite pour en savoir plus a propos des Café Guix
<bricewge>Vous parlez principalement de HPC ou bien de Guix ?
<bricewge>J'y connais rien en HPC mais discuter de Guix en français me tente bien.
<abrenon>salut !
<abrenon>la dernière fois c'était quand même bien Guix en général (intro à guix shell et toutes les merveilles que l'on peut faire avec)
<abrenon>d'ailleurs, on me glisse à l'oreillette que le prochain sera l'occasion de répondre aux questions du public, donc ça paraît tout indiquer pour causer de Guix en général et en français ; )
<civodul>carrément :-)
<civodul>bricewge: c'est plutôt général, parfois adapté aux préoccupations de la recherche et du HPC
<abrenon>it feels so weird to be talking in french on this chan, it feels like people have a different voice and the whole place is different
*abrenon is weirded out
*abrenon is frenched out
<civodul>yeah it's funny how language influences perception
<bricewge>Super ! Je serais parmi vous pour le prochaine sessions en février alors :)
<abrenon>super : )
<user_oreloznog>Pareil ;)
<vivien>C’est en ligne ou il faut se déplacer pour les cafés guix ?
<abrenon>mais qui ne parle pas français sur ce canal ?!
<abrenon>c'est en ligne
<vivien>abrenon, tous ceux qui se taisent déjà
<user_oreloznog>Je sais que les guix days sont en ligne
<vivien>C’est un peu malhonnête de nous attirer avec du café et en fait on a juste du guix :P
<vivien>Ce qui est déjà pas mal !
<user_oreloznog>Avec un petit kawa, on a les deux!
<abrenon>ah non, mais c'est pas pour nous attirer, il est nécessaire de présenter d'allumer sa caméra et de présenter une tasse de café à la reconnaissance de boisson automatique pour pouvoir entrer sur la visio
<abrenon>'tention, c'est ultra-sécurisé, haute-technologie
<civodul>vivien: d'où la tasse à café pixelisée :-)
<vivien>Oooh moi qui pensais que c’était encore un coup de mon setup icecat + tor - javascript (j’ai l’habitude d’avoir des surprises avec les images quand elles apparaissent)
<phf-1>Haha... excellent. J'imagine nos chers anglophones qui voient la liste passer impunément de l'anglais au français... comme si on mettait un coup de blanco sur les sous-titres de Breaking Bad ;)
<SeerLite[m]>Hi! I don't understand why `guix build rust-nix@0.22.1` builds. The source asks for a version of bitflags lesser than 1.3.0 (in Cargo.toml) but the version it uses in its cargo-inputs is 1.3.2. Shouldn't it fail and give an error? Why does it only fail when used as input in a package like alacritty?
<SeerLite[m]>Oh wait I think I get it, it's because when building it it's not really building anything but just setting up its source usage to be used at build time as a dependency
<abrenon>SeerLite[m]: wait what ? it's not building anything ?
<abrenon>aren't rust libraries compiled ?
<civodul>SeerLite[m]: yeah, Rust packages are "special": the actual build happens in leaf packages
<civodul>there are no shared libraries etc.
<abrenon>Oo good to know I guess
<abrenon>so thanks for the interesting question SeerLite[m] !
<SeerLite[m]>civodul: I see, thanks!
<jpoiret>golang is another example of this approach
<jpoiret>shared libraries don't exist for them
<tribals>Hi, folks!
<abrenon>hi tribals
<mfg>SeerLite[m]: But you are right that alacritty doesn't build currently :(
<SeerLite[m]>Yeah hehe that's what I was trying to fix. Someone suggested a few days ago that I should update to its new RC release but after seeing I had to mess around with too many Rust dependencies I gave up (I guess I'll leave that to the experts once an actual release comes out)
<SeerLite[m]>successfully built /gnu/store/spi0f5jndl6i8rannksjbryvn5igkkq0-alacritty-0.9.0.drv
<SeerLite[m]>Should I use a snippet or a phase for a temporary(?) fix like this? (forcing Alacritty to use newer rust-nix version)
<mitsubishi>hello i need some quick help, how do i quickly add a ca cert onto guix ?
<mitsubishi>documentation says i have to make a package myself but i dont know how to write a (cert) package
<mitsubishi>or can i point my profile's ssl to a non-read-only directly with env vars
<KarlJoad>I could not find any information about this in the Shepherd manual, but does Shepherd allow for parallel starting of tasks?
<apteryx>mitsubishi: it depends if your application is using openssl vs gnutls
<apteryx>with gnutls you don't have a choice; it looks in /etc/ssl/certs
<civodul>KarlJoad: no, not yet
<apteryx>mitsubishi: for OpenSSL, see info '(guix) X.509 Certificates'
<apteryx>basically you can set SSL_CERT_DIR and SSL_CERT_FILE
<cbaines>Does anyone else see error: channel-source->package: unbound variable when running make check-system ?
<jpoiret>channel-source->package should be defined in gnu/ci.scm iirc
<KarlJoad>civodul: I remember seeing someone else ask the same thing here. As I recall, it is because Shepherd has Hurd compatibility, but Hurd does not have a notion of cgroups, right?
<cbaines>yeah, I think the actual error is getting hidden somewhere
<tribals>Can anyone help me with `guix home`? As first adaptation step, I'm trying to just delegate bash configuration to my existing .bashrc (and friends). To do so, I need to use `home-bash-service-type` with `home-bash-configuration`, it has `bashrc` field. According to docs, `bashrc` filed accepts list of file-like objects: So, i pass it this: `(list
<tribals>(local-file "my-old-bashrc"))`. Unfortunately, this doesn't work.
<cbaines>I think the actual error is: gnu/system/install.scm:358:19: Throw to key `record-abi-mismatch-error' with args `(abi-check "~a: record ABI mismatch; recompilation needed" (#<record-type <guix-configuration>>) ())'.
<tribals>There error is:
<tribals>guix home: error: #f: 'local-file' is a macro and cannot be used like this
<tribals>I know that local-file is widely used outside `guix home`. Can someone explain me how to use it?
<jpoiret>cbaines: you'll need to clean the .go files then
<civodul>KarlJoad: that's true, but cgroups don't play a role in starting services in parallel
<Gooberpatrol_66>KarlJoad: how hurd could get cgroups functionality would be an interesting question to ask on #hurd
<csantosb>Hello #guix
<csantosb>I'm having a weird issue here with guix containers
<csantosb>When I run the following
<csantosb>guix shell --container --network --link-profile python
<csantosb>pip3 install redis-server
<csantosb>I get 'a no such file or directory' message.
<csantosb>Is there a reason for that ?
<csantosb>Am I missing something ?
<rekado_>csantosb: I suggest using redis from Guix
<rekado_>the reason here is likely that this binary has a reference to the loader at some default location, which doesn’t exis in your container
<rekado_>it’s not redis-server that isn’t found but the loader
<csantosb>Thanks. Nice tip. I need to install both, python-redis and redis itself to get the redis-server binary under /bin
<unmatched-paren>hello guix. minetest's default mods and game aren't loaded when i install it; is this intentional? i can't find any package for them
<unmatched-paren>oh, looks like i need to relogin
<faust45>i have a problem with with system installation, i just follow this manual
<faust45>but when i restart notebook nothing happens just a black screen
<faust45>can anyone help me with this ?
<faust45>i just have no idea how to make this to work
<csantosb>rekado_: Problem is I'm using python ray library, which pulls redis-server.
<csantosb>rekado_: And I get the error in
<csantosb>rekado_: $HOME/.local/lib/python3.9/site-packages/ray/core/src/ray/thirdparty/redis/src/redis-server
<csantosb>Same as when I'm installing redis-server with pip.
<KarlJoad>civodul: Then what would be needed for Shepherd to support parallel starting?
<KarlJoad>Gooberpatrol_66: Agreed. Just starting to look into Hurd, MIG, and Mach. First thing to do though is to switch to Guix System.
<rekado_>csantosb: I’m afraid I cannot help with this. Pip installs pre-built binaries. They likely make assumptions about the run time environment that are invalid.
<SeerLite[m]>faust45: Do you get to the GRUB menu or does the black screen come before that? Are you able to select the USB as the boot device from the BIOS/UEFI?
<csantosb>rekado_: That's correct and unfortunate. I'll symlink to the right binaries by now.
<Gooberpatrol_66>(socket activation is what allows systemd to start so fast in parallel)
<Gooberpatrol_66>info on systemd socket activation
<luishgh`>tribals: check if this helps you
<apteryx>mbakke: oh, going to about:safe-browsing causes a segfault here
<gnoo>hmm, runit does not have socket activation
<apteryx>(in ungoogled-chromium)
<gnoo>and yet it starts much much more faster than soystemd
<apteryx>gnoo: it's spelled systemd
<lilyp>also soy is good for you
<apteryx>and the planet
<lilyp>unless you require it be genetically modified to feed herds of animals pointlessly suffering at the hands of a corrupt industry
<SeerLite[m]>Is the difference between a snippet and a phase that snippets are also used in `guix build -S`?
<civodul>SeerLite[m]: yes
<SeerLite[m]>Aha! Even then, how do I know when to use one or the other? It feels like phases also do some patching to get packages working in Guix
<lilyp>SeerLite[m]: snippets to remove vendored code and blobs, phases for fixes
<lfam>Right. Snippets are only about making source code that has nonfree bits into free software
<SeerLite[m]>I just found the section in the manual :P
<SeerLite[m]>lilyp: I see, thank you
<SeerLite[m]>It's just that I found many snippets in crates-io.scm that seemed to just patch Cargo.toml versions and I wondered why it wouldn't be done in phases instead
<faust45>SeerLite[m] yes i have select usb as boot device, i dont see any grab menu just a black screen
<SeerLite[m]>I'm guessing those are just mistakes
<lfam>Maybe. Overall, Rust crates don't follow conventions of Guix and are bad examples for making Guix packages
<lilyp>Overall Rust is a bad example.
<lfam>It's definitely a mistake to use snippets for anything except very serious problems
<lfam>I didn't mean that Rust is bad. Just that Rust in Guix is currently suboptimal and not a good example for learning how to make Guix packages
<lfam>We struggle to integrate Rust into Guix in a Guix-y way
<lilyp>I know how you meant it, I just mean that Rust is bad in ways that are not unique to Guix.
<faust45>SeerLite[m]: is it possible to run installer from working OS?
<lfam>Maybe Rust is bad, I really don't know very much about it. We'd better learn to like it because it's going to be part of the entire system soon!
<lfam>Already, the entire userspace depends on it
<lilyp>That doesn't make it better only more annoying
<lfam>Yeah, but it's unhealthy to stay annoyed. So we need to learn to like it
<SeerLite[m]>Yeah tbh, as someone who just started to mess around with Rust packages, currently it feels like Guix is fighting against how the Rust version system works. I wonder if there's a way to improve it? It feels weird to have all these specific versions of dependencies defined as packages instead of using whatever the Cargo.toml says
<lfam>Also I think it's corny to say the language is bad. It just doesn't really fit with how we do things in Guix
<lfam>Most languages have some problems
<lfam>SeerLite[m]: Yeah, I wonder. It's not like those packages gain us very much: The normal Guix tooling for working with the dependency graph doesn't work with our Rust packages
<lfam>It will have to be overhauled sooner or later
<lfam>Maybe as the world of Rust matures a bit, it will become a little easier for us to handle
<SeerLite[m]>faust45: Sorry, I have no clue. I also don't know what could be going wrong. Is it an UEFI system? Do you have compatibility mode enabled in the BIOS?
<faust45>SeerLite[m]: i think not UEFI, my notebook use BIOS
<lfam>Speaking of Rust, do we need to address this? <>
<lilyp>probably yes
<lilyp>it's thankfully not relevant to the bootstrap in a way that I know of
<lfam>I'm guessing that Rust packages aren't graftable
<lfam>Because, they don't declare any dependencies
<lfam>So, I suppose it's a world rebuild?
<lilyp>why would they be? static linking best linking 😎️
<lfam>I mean, it's not even possible to express the graft. Static linking would be a 2nd order problem
<lilyp>the first is a problem with Guix' current Rust tooling, the second an inherent Rust problem
<lfam>Or we could ignore it. That's a time-honored tradition for inconvenient bugs in compilers and standard libraries
<lfam>And it's a local privilege escalation, which isn't exactly rare
<lfam>Especially, an LPE limited to deleting things
<lfam>But it could also be an interesting exercise, for whenever someone finds a real bug
<lfam>And I wonder if most systems are hardened enough against this type of vulnerability anyways
<lfam>For example with fs.protected_symlinks
<podiki[m]>does anyone know of an example package def that has imported-modules and uses gexp?
<lfam>But, if it's at all possible to change the Rust compiler without rebuilding the entire distro, that's worth figuring out how to do before we really need to
<podiki[m]>my search is not finding any and was trying to convert piper to gexp (since I am fixing its build and running anyway)
<SeerLite[m]>faust45: I'm sorry I have no idea how to troubleshoot your issue. Maybe you can install it from a running Linux system by installing guix onto it first, but I'm not sure. Try asking on the mailing list if you don't get help here
<lilyp>lfam: I think we'd first have to split it into compiler + stdlib
<lfam>faust45: Your problem is that the installer doesn't boot?
<faust45>lfam: yes
<lfam>How did you create the installer?
<faust45>lfam: just follow this manual
<lfam>Specifically, what command did you type to flash the USB stick?
<faust45>lfam command to create booteble flash? dd if=guix-system-install-1.3.0.x86_64-linux.iso of=/dev/sdX status=progress
<lfam>faust45: I'm certain that /dev/sdX is incorrect
<lfam>You need to adapt the example to your own system
<faust45>lfam: sorry i use this sudo dd if=./Downloads/guix-installer-202201150226.iso of=/dev/sdb1 status=progress
<lfam>What is "guix-installer-202201150226.iso"?
<lfam>Also, I strongly recommend adding the option "conv=fsync" to your dd command. Otherwise, it might not finish writing to the USB stick before you pull it out
<lfam>And finally, /dev/sdb1 is also incorrect
<lfam>You should have used /dev/sdb
<SeerLite[m]>Ah that must be it
<lfam>I wonder if there is a good GUI tool for flashing USB sticks that is widely available
<lfam>It's really easy to make mistakes with dd
<SeerLite[m]>Etcher I think
<SeerLite[m]>Oh it's electron-based
<faust45>lfam: i downlad installer from
<lfam>What ... is that
<lfam>That's not us
<lfam>I see, it's a 3rd party using Linux
<podiki[m]>that's a third party installer, since it includes non-fsdg pieces tis not for this channel (there are other places to discuss) faust45
<lfam>You can use whatever installer you prefer. But you have to flash it correctly
<faust45>lfam: thanks! i will try sdb
<lfam>faust45: And add conv=fsync
<podiki[m]>(but is not malware, unless you consider non-gnu malware)
<faust45>lfam: yes this also ) thanks!
<lfam>Okay, let us know if it works faust45
<lfam>I suppose it was inevitable that 3rd parties would spring up to fill the vacuum
<lfam>Basically my complaint about the whole thing
<podiki[m]>if linux-libre doesn't boot for you...
<lfam>You don't have to convince me...
<lfam>Still, it's a bad precedent
<faust45>one more question, if i install guix on top of other linux guix will use Shephard or systemd?
<lfam>faust45: You have to clarify your goal
<lfam>You can install just Guix the package manager on another Linux distro. It will coexist with the distro's package manager
<lfam>Or, you can install Guix System, which is an entire operating system
<lfam>Which are you planning to do?
***w1gz_ is now known as w1gz
<faust45>ifam: oh thanks! i was confused, i thought that i can setup guix on top any linux distro
<faust45>lfam: guix as OS
<lfam>Then Guix will erase your old OS
<lfam>And, you'll use shepherd
<faust45>lfam:  i flash usb with sdb +conv=fsync and it works! thanks!
<podiki[m]>lfam: just sent in a patch to fix piper, same as what we did for syncthing-gtk (librsvg propagation) and libratbag among others (meson no longer propagates python)
<podiki[m]> (for whenever you get the chance, just figured I'd ping you since you pushed similar changes)
<lfam>Thanks, podiki[m]. I pushed it
<podiki[m]>awesome, thanks
<podiki[m]>wonder how many more meson/python and gtk+/librsvg fixes need to be done...
<podiki[m]>probably not hard to have a script that looks for gtk+ and librsvg as inputs for the same package
<podiki[m]>or maybe some general tool like that to help track down packages meeting certain criteria
<lfam>It's exactly the kind of thing that Scheme allows us to do well
<podiki[m]>I guess the problem there is that gtk+ propagates librsvg-bootstrap, so you wouldn't get some sort of "an input propagates a different input"
<lfam>We don't have to scrape text or anything like that
<podiki[m]>maybe some utility the is easy to adapt to exploring the package tree in different ways
<tribals>luishgh`: found your hint in chat log, it helped. Thank you a lot!
<tribals>now next question: how to resolve path relative to source file where it is mentioned?
<tribals>like this, in ~/foo/bar.scm, i want to refer to ~/foo/baz/quix.txt, but relatively to ~/foo - "baz/quix.txt"?
<robin>sneek, later tell lfam: is a good gplv3+ usb-drive flashing tool, but for ms windows only (still possibly useful for windows users installing guix, maybe worth recommending in the manual)
<sneek>Will do.
<SeerLite[m]>robin: Oh yeah I also found unetbootin before: It's cross-platform, maybe the Guix image can even be added as a builtin option
<lfam>gnome-multi-writer is packaged
<sneek>Welcome back lfam, you have 1 message!
<sneek>lfam, robin says: is a good gplv3+ usb-drive flashing tool, but for ms windows only (still possibly useful for windows users installing guix, maybe worth recommending in the manual)
<drakonis>ventoy is a much nicer option though
<drakonis>i'd rather recommend that
<robin>SeerLite[m], oh, that would be nifty, assuming signature verification and such could be integrated (perf-wise rufus > unetbootin, according to the rufus author, but there are zero plans to make rufus cross-platform)
<lfam>But, it's not part of Guix
<drakonis>also gpl v3 i guess?
<lfam>Nor is it part of Debian
<lfam>So, hard to recommend :)
<SeerLite[m]>Oh Ventoy is great, yes. I didn't think of that. But I think it's harder to set up than just using a GUI program
<drakonis>its not.
<SeerLite[m]>Unless Ventoy has a GUI now(?)
<drakonis>its pretty easy to set up
<podiki[m]>It has been rather hit or miss for me, ventoy, in what distro isos boot and work, not sure why
<lfam>I don't see why the tool used to flash the USB would make a difference to whether or not the OS boots afterwards
<lfam>As long as it writes the data to the storage medium faithfully, shouldn't it work?
<robin>(man, just reading is giving me a headache imagining what his INBOX must look like)
<lfam>It's quite familiar
<robin>lfam, for methods that boil down to 'cat > /dev/sdX && sync', i'd think so. some tools like ventoy are apparently much more complicated though (e.g. ventoy lets you put multiple ISOs on a disk and has a custom bootloader to choose one, afaict?)
<lfam>I see
<lfam>Well, I was hoping to recommend a GUI that would be simpler than dd. Not more complicated :)
<lfam>gnome-multi-writer doesn't seem to have any options, which makes it perfect
<jgart>hi would someone be able to help me debug an elisp package I packaged?
<jgart>nice-defaults is a fork of better-defaults
<jgart>but the nice-defaults guix package does not produce nice-defaults-autoloads.el and nice-defaults-autoloads.elc in the store
<jgart>Here is the Guix package:
<podiki[m]>yeah, ventoy lets you (supposed to) keep a bunch of different bootable images and I think even some storage? anyway, hit or miss for me, like I said. i guess some images play nicer with that set up than others
<dcunit3d>what tools are available to plot out the PCIe bus topology in guix?
<dcunit3d>i can't remember the name of the tools that i've used in archlinux
<drakonis>ventoy makes it pretty trivial to have multiple images stored
<drakonis>but not every iso lets you mount ventoy's device while it is booted up, so you can't access any data
<drakonis>no need to format anything, just throw the isos in there and any data you might need to store or access from a running OS
<podiki[m]>dcunit3d: like lspci? that's in pciutils
<dcunit3d>no i have lspci. i just remember a tool that would plot the topology using graphviz or something
<dcunit3d>if i could remember what it's called then i should be able to find it
<lfam>Anyone else seen /homeless-shelter appearing on their systems? <>
<lfam>Like, outside of the build chroot?
***Reventlov1 is now known as Reventlov
<podiki[m]>I don't have it
<KE0VVT```>wb Newfangled