<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: 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>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 Makefile.am 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 ***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 <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 <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 <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 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 Makefile.am, 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>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>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 Makefile.am 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]>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]>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 libexpat.so.1.x <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? <lfam>I must have done a hundred grafts and I don't recall ever doing that <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 <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? <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]>libexpat.so -> libexpat.so.1 -> libexpat.so.1.8.3 (I guess not chained in our build, but that's what I meant) <podiki[m]>so the final full version number is the old one <lfam>Wait, I thought they had the same soversion <lfam>I must not understand so-versioning <robin>(...which i happened to have in ~/bin already for some reason :)) <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/libexpat.so'. 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 libexpat.so.1.8.1 in libexpat that is the newer version <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 <lfam>Maybe I don't understand it <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 <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? <vivien>Hi! I figured out my python issue: I was using the default check phase (python setup.py 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>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 <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 <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>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. <phf-1>Foreign distro, CentOS 8, so, `guix pack' without the `-RR' should work I guess? <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 'file.zip' *", 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? <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. <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 <mothacehe>rekado_: thanks for your help, can't wait to stop having to kill the GC every single day :) <gnoo>so you make guix pack output format to .deb (guix pack -f deb) <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) ? <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 <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 ? <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? <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. <ss2>hm, who’s admin on guix-devel@gnu.org? 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>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. <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 <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. <ss2>okay – i’ll be patient then. # <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>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>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 <civodul>yeah it's funny how language influences perception <bricewge>Super ! Je serais parmi vous pour le prochaine sessions en février alors :) <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 ?! <vivien>abrenon, tous ceux qui se taisent déjà <vivien>C’est un peu malhonnête de nous attirer avec du café et en fait on a juste du guix :P <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 ? <civodul>SeerLite[m]: yeah, Rust packages are "special": the actual build happens in leaf packages <abrenon>so thanks for the interesting question SeerLite[m] ! <jpoiret>golang is another example of this approach <jpoiret>shared libraries don't exist for them <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 <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>(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>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>I'm having a weird issue here with guix containers <csantosb>guix shell --container --network --link-profile python <csantosb>$HOME/.local/lib/python3.9/site-packages/redis_server/bin/redis-server <csantosb>I get 'a no such file or directory' message. <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 <faust45>but when i restart notebook nothing happens just a black screen <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_: $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) <apteryx>mbakke: oh, going to about:safe-browsing causes a segfault here <gnoo>hmm, runit does not have socket activation <gnoo>and yet it starts much much more faster than soystemd <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`? <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]>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 <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 <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? <lfam>How did you create the installer? <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 <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 <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 <lfam>faust45: And add conv=fsync <podiki[m]>(but is not malware, unless you consider non-gnu malware) <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 <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 <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) <lfam>Thanks, podiki[m]. I pushed it <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: https://rufus.ie/en/ 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) <lfam>gnome-multi-writer is packaged <sneek>Welcome back lfam, you have 1 message! <sneek>lfam, robin says: https://rufus.ie/en/ 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) <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 <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 <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>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>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 <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 <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>Like, outside of the build chroot? ***Reventlov1 is now known as Reventlov