IRC channel logs

2022-05-10.log

back to list of logs

<Tril[m]>I used guix archive --export -r and import to transfer a package and dependencies over to another machine. I figure I need to guix pull and guix package -u to install this. So why is guix package -u downloading anything?
<Tril[m]>says it is installing the same package version.
<KarlJoad>Is pipewire the default audio subsystem on Guix System yet? Or is it still PulseAudio?
<kitty1>hows yall going?
<Tril[m]>since "guix pull" has its own profile it is best practice to remove "guix" binary from the profile used by "guix package"? since I need to put the "pull" profile in the path anyway?
<littlebobeep>Is there something like nix-store --optimise for reducing space from duplicate files in Guix?
<drakonis>yes it does
<drakonis>you use guix gc --optimize
<KarlJoad>How can I get a system config to be used from the `guix repl`?
<KarlJoad>Also, my Emacs server crashed before I saw an answer to my last question. Does Guix System use PipeWire by default yet?
<iyzsong-ww>KarlJoad: no system service or whatever for pipewire yet, unless you setup pipewire yourself, pulseaudio will always be started by any libpulse linked applications.
<littlebobeep>drakonis: great thnxxx
<KarlJoad>iyzsong-ww: Ok. Good to know.
<iyzsong-ww>gnome may default to pipewire though, i haven't tried
<bjc>KarlJoad: to my knowledge there's no good way to use a system config from the repl
<KarlJoad>Darn... I wanted to check if my kernel config flag changes were properly passed on.
<bjc>yeah, it can be annoying. you can do a ‘guix system build’ and then inspect the profile it produces for the grub.cfg
<KarlJoad>Ok. These are compile-time config flags, so they will likely not appear in grub.
<bjc>oh for a custom kernel?
<bjc>sorry, i thought you meant the kernel command line
<KarlJoad>Yes, custom kernel. I can get that working fine, but want to double-check before a reboot.
<bjc>well, what i do in these situations is try to find the way the derivation is built, extract that to some custom code, and verify from there. but it's not a fun process and pretty clumsy
<bjc>another possibility would be doing a build and keeping the workdir around. i think there's a way to do that mentioned in the manual
<KarlJoad>I think I've managed to get the config flags set, just not a forwards-compatible way. I'm hooking into `make-linux-libre*` directly.
<bjc>here it is: https://guix.gnu.org/en/manual/devel/en/html_node/Debugging-Build-Failures.html#Debugging-Build-Failures
<bjc>the ‘-K’ flag will keep a build if it fails so you can force a failure just to have a peek at the build dir
<bjc>maybe there's a way to do it without forcing a failure
<KarlJoad`>Is there a way to read the log of an already-completed but not GC'd `guix build`?
<littlebo1eep>Hmmm WINE in Guix is 5.21? the website says they are on 7.0 or 7.8-devel
<podiki[m]>no, we are at 7.0, I saw patches for the most recent too
<podiki[m]> https://issues.guix.gnu.org/55302
<podiki[m]>sneek: later tell KarlJoad` there is the --log-file option for just that
<sneek>Will do.
<littlebo1eep>podiki[m]: ohhh derp, was on wrong branch
<littlebo1eep>podiki[m]: Do you understand why this packager changes the inputs to use "list" and why they do this: Use ‘#$output’ instead of ‘%output’
<wurt>Hi, why are there links to .guix-profile/lib for some libraries, while others have a lack of them? I am trying to create a guile package with a dependency on libuuid (util-linux package) but pkg-config does not find the file uuid.pc, I check that other libraries like zlib or lzma do not have this problem.
<sneek>Welcome back wurt, you have 1 message!
<sneek>wurt, unmatched-paren says: libuuid is in util-linux:lib iirc
<podiki[m]>littlebo1eep: that is gexps (the #$ stuff) and the inputs as a list is the newer (cleaner) style, if that's what you mean; see https://guix.gnu.org/en/blog/2021/the-big-change/ for some info
<apteryx>openjdk@12 fails to build for me
<rekado_>apteryx: vagrant also reported this yesterday
***civodul` is now known as civodul
<civodul>Hello Guix!
<efraim>I'm testing a fix now, looks like one of the file names got changed in the openjdk11 update and not changed back in openjdk12
<jpoiret>hello guix
<efraim>apteryx: openjdk@12 fix pushed
<jpoiret>cbaines: cbaines.net certificate expired apparently
<cbaines>jpoiret, hmm, seems to work for me, what URL are you seeing problems with?
<jpoiret> https://patches.guix-patches.cbaines.net for example
<jpoiret>also laminar
<cbaines>jpoiret, ah, I've restarted nginx now, so things should be back working
<jpoiret>yep, works now :)
<cbaines>thanks for letting me know :)
<jpoiret>cbaines: is there a way to query the data service/patchwork to find out the patch series that modify a given package?
<nckx>sneek: Later tell KarlJoad: Guix's linux-libre package saves a copy of the complete .config file in the output store directory (which is symlinked from /run/{booted,current}-system/kernel/.config on Guix System).
<sneek>Will do.
<nckx>sneek: botsnack
<sneek>:)
<cbaines>jpoiret, sort of, but it would require querying for the changes in every single patch series, and checking what's changed
<cbaines>the way to probably approach that is have something do those queries and collect the data, in such a way that it can quickly say for a particular package, which patch series affect it
***reyman_ is now known as reyman
<raghavgururajan>Hello Guix!
<nckx>Hi Raghav!
<nckx>cbaines: Hi! Is guix.you.net supposed to be gone?
<cbaines>nckx, yeah, that went a while back
<nckx>Aight.
<cbaines>it was only meant to be temporary, while I was testing the build coordinator
<nckx>I see, thanks.
<raghavgururajan>nckx: Do you work full-time in a job? If so, any ideas on how to manage time between corporate work and free software work?
***utkarshsingh is now known as cnlab
<jpoiret>cbaines: right, that's what i was thinking. Since you already have the thing to compare derivations, i thought that maybe you had something of the sort as well
<efraim>do we have a property that we can add to a package to force it to stay on a certain major version? I'm looking at ncdu, I want it to update from 1.16 to 1.17, not to 2.1.2
<reyman>Hi ! I begin with guix (moving from ubuntu/nix to guix), is there a "best way" to use doom emacs with guix ?
<mekeor[m]>i mean "guix install ncdu --with-branch=v1" or so
<mekeor[m]>efraim: use a branch or a tag? (shrug)
<nckx>raghavgururajan: To maximise irony I'll reply later, when I have this 'time' of which you speak ;-)
<apteryx>efraim: thanks
<raghavgururajan>nckx: Hahah
<Aleci[m]>Hi guys, I'm trying to organize the package i'm using into the profile framework using different manifests. But I really can't get the .bash_profile loaded after the graphical login. I'm using gnome, so i guess that i should edit a script into /etc/gdm/PostLogin but since I'm using GuixSD that folder does not exists. Do you know how to fix this?
<Aleci[m]>Thank you
<apteryx>efraim: do you mean to prevent 'guix refresh' from updating it to latest? I think it is aware for some projects of the odd/even (unstable/stable) release scheme, so there must be something
<efraim>apteryx: yeah, that's what I was thinking of, more or less
<mekeor[m]><reyman> "Hi ! I begin with guix (moving..." <- might be of interest: https://www.reddit.com/r/GUIX/comments/tjj5yc/packaging_doomemacs_for_guix/ -- especially that doom emacs wants "to also handle the management of packages itself too - Which goes again The Guix Way in some respects"
<reyman>I see this post @mekeor[m], doom manage package this is right, but all is stored locally into .doom.d folder, so i suppose this is also possible with guix and equivalent to home-manager ?
<raghavgururajan>Aleci[m]: Do you have the 'Activate Guix extra profiles' snippet in bash_profile? Example: https://git.sr.ht/~raghavgururajan/dotfiles/tree/4d9b8c709606fd2be73772f373f493128fe979cb/item/bash/bash_profile
<raghavgururajan>Aleci[m]: Also, did you mean "multiple profiles" instead of "multiple manifests"?
<jpoiret>Aleci[m]: from what i remember, sessions started by gdm, either wayland or x11, should start the sessions under a login shell
<jpoiret>(on Guix system that is)
<mekeor[m]><reyman> "I see this post @mekeor[m], doom..." <- true
<apteryx>seen while building a profile: find-files: /gnu/store/l0axwdizcc12n0kdicwlm7lcds7ym40d-nss-certs-3.71/etc/ssl/certs/NetLock_Arany_=Class_Gold=_F??tan??s??tv??ny.pem: No such file or directory
<apteryx>not sure what piece of code exactly triggered it
<jpoiret>maybe a locale issue?
<apteryx>looks like it
<jpoiret>it's called NetLock_Arany_=Class_Gold=_Főtanúsítvány.pem on mine
<apteryx>possibly a profile hook not setting up locales
<mekeor[m]>reyman: doesnt it work to just install doom manually? https://github.com/doomemacs/doomemacs/blob/master/docs/getting_started.org#install
<apteryx>or perhaps it was the build of nss-certs itself
<jpoiret>aren't locales set for the whole profile builder
<jpoiret>i can `guix shell nss-certs` without any issues though, does that reproduce it on your end apteryx?
*apteryx builds nss-certs
<apteryx>no Class_Gold instance in the build log... hm
*apteryx searches /var/log/guix/drvs
<apteryx>I see it in /var/log/guix/drvs/na/irmb9n4m5gmj9nvif1dy4cfs3v6xkj-gdk-pixbuf-loaders-cache-file.drv
<apteryx>so the associated profile hook should setup locales
<apteryx>(for more languages?)
<Aleci[m]><raghavgururajan> "Aleci: Do you have the 'Activate..." <- Yes if i manually source my .bash_profile all my different profiles are correctly loaded. The problem is that I can't get them loaded (and therefore globally visible) at startup in a graphic environment. In fact if i login in tty2 for instance it works
***utkarshsingh` is now known as rishabh_parmar
<apteryx>icecat seems crashy following a system upgrade (without updating the user profile it comes from)
<Aleci[m]><jpoiret> "Aleci: from what i remember..." <- It seems that gdm doesn't lauch any of the bash dotfiles. The only file that is in some way loaded is after the gdm login the .xsession, if i write in it "source $HOME/.bash_profile
<Aleci[m]>exec gnome-session" still my profiles are not loaded
<Aleci[m]>* It seems that gdm doesn't lauch any of the bash dotfiles. The only file that is in some way loaded is after the gdm login the .xsession, but if i write in it "source $HOME/.bash_profile
<Aleci[m]>exec gnome-session" still my profiles are not loaded
<sneek>Welcome back unmatched-paren!!
<reyman>@mekeor[m] I will try, fine, this is just installing emacs28 into guix and after that using classic "git clone" i suppose ?
<reyman>What's the best practice for package, using "guix home" or directly "/etc/config.scm" ? One is global and other is local for one user ?
<mekeor[m]><reyman> "@mekeor[m] I will try, fine..." <- apparently u also need ripgrep etc, but yes
<mekeor[m]><reyman> "What's the best practice for..." <- yes, usually you would just run "guix install emacs", for example
<mekeor[m]><reyman> "@mekeor[m] I will try, fine..." <- btw, they recommend emacs 27.1 apparently, just read the instructions
***lukedashjr is now known as luke-jr
<raghavgururajan>Aleci[m]: Could you try adding `if [ -f ~/.bash_profile ]; then source ~/.bash_profile; fi` to `.profile`?
<reyman>@mekeor[m] Thanks, "guix install emacs" create a guix home file automatically ?
<reyman>i will try
<mekeor[m]>reyman: no, but you dont need a home file...
<mekeor[m]>if you really want a home config, just replace htop with emacs in this example: https://guix.gnu.org/en/manual/devel/en/html_node/Declaring-the-Home-Environment.html#Declaring-the-Home-Environment
<jackhill>Does anyone with commit rights have time to look at #55078? It's a minor webkitgtk upgrade. I just did a build and smoke test, and it LGTM!
<reyman>@mekeor[m] Right i don't really need a home file, but i'm interested to have the same behavior that nix, and i see with guix it's possible to indicate mutable/immutable part directly into home file, seems great to manage dotfile for example.
<reyman>... compiling emacs native ... :D
<abrenon>hi guix
<raghavgururajan>jackhill: I have responded to the #55078 thread.
<jackhill>raghavgururajan: awesome, thanks!
<raghavgururajan>Np!
<ryanprior[m]>thesis: testing as part of the build process was a mistake and we should remove all testing from Guix package builds
<ryanprior[m]>builds would be faster & more energy efficient, dependency trees would be sparser and more accurate
<ryanprior[m]>testing is still extremely important but should be another layer which consumes package outputs and yields test results; test status is a property of the build, like its hash or file size, not an input to the build
<ryanprior[m]>anybody vibe with this? thinking about making a blog post
<nckx>The idea isn't bad but the messaging is cringe (‘a mistake’, ‘should be’). Just say you'd like to knowingly move the trade-off somewhere else on the spectrum, understanding the pros & cons, & try to build consensus towards that.
<Aleci[m]><raghavgururajan> "aleci: Could you try adding `if..." <- Ok. First of all i couldn't configure .profile using guix home because the field profile of home-shell-profile-configuration should only "be extended and not manually defined" but is not clear how to do it.
<Aleci[m]>Anyways i manually modified the .profile you adviced but still the profiles are not loaded.
<Aleci[m]>BUT: I noticed a strange thing. If i configure .bash_profile using guix home, the system adds a line at the beginning of the file that sources the .profile. That suggest a lower priority of .profile wrt .bash_profile. The strange thing is: if i manually modify the .profile as you told and try to login an infinite loop appear so indeed one of those file is actually evaluated at some stage. If I remove the line from the .bash_profile, nothing loads
<Aleci[m]>anymore.
<dongcarl>ryanprior[m]: I actually agree with this, as long as the default for `guix build ` is to run tests, but not have it be a blocker to creating a derivation. I also like nckx's messaging tip a lot.
<Aleci[m]>* Ok. First of all i couldn't configure .profile using guix home because the field profile of home-shell-profile-configuration should only "be extended and not manually defined" but is not clear how to do it.
<Aleci[m]>Anyways i manually modified the .profile you adviced but still the profiles are not loaded.
<Aleci[m]>BUT: I noticed a strange thing. If i configure .bash_profile using guix home, the system adds a line at the beginning of the file, that sources the .profile. That suggest a lower priority of .profile wrt .bash_profile. The strange thing is: if i manually modify the .profile as you told and try to login an infinite loop appear so indeed one of those file is actually evaluated at some stage. If I remove the line from the .bash_profile, nothing
<Aleci[m]>loads anymore.
<ryanprior[m]>I would also support testing by default on "guix build," both as a good habit and a continuity of current behavior.
<ryanprior[m]>nckx: lmao I knew for some reason I should workshop it in the irc before writing. thank you for that perspective!
<nckx>😊
<nckx>I'm certainly not pretending to be better at it.
<civodul>ryanprior[m]: tests are almost always intended to be run as part of the build process though
<nckx>I was writing ‘there are arguments in favour that you can't just dismiss’ and there we go.
<civodul>running tests separately would be difficult: we'd need not just the outputs (usually we woudln't need them at all), but rather the build tree
<civodul>nckx: :-)
<ryanprior[m]>I was thinking about that civodul and picturing that the build tree could be another store object, like how the package origin is. So the test would depend on the build tree.
<sleepydog>for me a big reason the tests are there are to detect when a dependency update breaks a package. so *for me* tests only need to run when inputs change. that usually lines up with the times that builds need to happen, too
<ryanprior[m]>In some packages the test might actually create some artifacts that are needed for the production software. I can't think of an example of that but I can imagine it. In those few cases we could still have a check stage of the build.
<ryanprior[m]>But based on a decade of professional build automation experience, the majority of software can have its tests moved outside of the build infra, such that builds produce immutable artifacts which are consumed by tests
<nckx>Definitely bookmarking this conversation to catch up later :) Bye o/
<ryanprior[m]>ciao =D
<ryanprior[m]>another thing kicking around my brain: it's actually not bad for tests to depend on the network, and in practice many tests do. for builds this is catastrophic and Guix is correct to build packages with no network access. but for tests this is not a big deal, a test result is just a point in time.
<ryanprior[m]>which makes me think moving tests out of package builds will in many cases make the builds more accurate, and the tests more accurate
<sleepydog>i disagree. if a test fails it should always fail, and if it passes it should always pass. a flaky test generates work. how can you have a reliable test that makes network calls?
<ryanprior[m]>so I'm totally with you wrt/ hating flaky tests, and tests that rely on networks are by definition flaky, so I estimate we're maybe 80% in alignment
<sleepydog>i think supporting more complex integration tests, that setup a controlled network environment and use it, could be a good thing
<ryanprior[m]>but the ground truth is, we have a ton of packages in Guix that have tests disabled entirely because a few test cases require the network
<sleepydog>and i agree those don't have to be part of the package
<ryanprior[m]>yeah a controlled network with automatic mocks or something could work well, I've set up that kind of thing at a couple jobs
<ryanprior[m]>you run the tests "live" at some point where the network is operating, reify that and take it offline
<sleepydog>so, i guess i agree with you that it's probably better on the whole to support those tests rather than disable them
<sleepydog>the ones that requrie n/w access, i mean
<ryanprior[m]>when you wrote "if a test fails it should always fail, and if it passes it should always pass" though - I think that takes it too far. because it's often actually interesting to me whether an integration test passes /today/
<ryanprior[m]>for example, a bunch of packages in Guix are primarily clients network services. for example I packaged protonvpn's client, which has tests disabled because they connect to the protonvpn network.
<ryanprior[m]>if I could "guix test protonvpn" and run the tests to see if they're working /right now/ that's actually useful to me
<sleepydog>hmm, i suppose it matters what the test is for. if you want to test that the software is still usable after installation, then you'd want recent test results
<civodul>ryanprior[m]: i don't think that's representative though; software with network-related tests can usually be tested without relying on external resources (fortunately)
<sleepydog>i didn't think of that, i was focused simply on detecting bugs and breaking behavior
<ryanprior[m]>a local-only test by replaying captured responses &c is useful, no doubt, and should remain an option
<ryanprior[m]>an option to run tests with networking enabled could also be relevant, and imo much less risky than network-enabled builds.
<dongcarl>I think that "enabling networking in tests" would probably be better positioned as a completely separate proposal from the "separate tests from derivations" idea.
<vagrantc>ryanprior[m]: debian has this division, tests run during build time are not allowed to access network, but there are also tests that can be run from the installed package that are allowed to have network access ...
<ryanprior[m]>that makes sense
<ryanprior[m]>that's a useful perspective vagrantc, do you happen to have a reference or link to their docs on that? if not I will do some searching :)
<vagrantc>i've been meaning to hook those up to the guix package in Debian so as to be able to do more comprehensive tests...
<vagrantc>ryanprior[m]: https://wiki.debian.org/ContinuousIntegration/autopkgtest
<vagrantc>ryanprior[m]: not a lot there, but i think it links to more detailed things
<ryanprior[m]>thank you
*vagrantc also needs to figure out why the tests fail for https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/guix.html but not https://buildd.debian.org/guix
<roptat>hi guix!
<roptat>I managed to boot the guix system on the new overdrive machine I'm hosting \o/
<roptat>now I'm awaiting instructions on how to make it part of the build farm? and which one?
<raghavgururajan>Aleci[m]: Oh! You are using guix-home. Then you might have to declare the snippet to activate multiple profiles, inside home configuration under bash-profile service.
<raghavgururajan>Aleci[m]: Refer to 'home-bash-extension' at https://guix.gnu.org/en/manual/devel/en/html_node/Shells-Home-Services.html#Shells-Home-Services .
<abrenon>hi roptat !
<avalenn>Did anyone had a look on https://in-toto.io/ ? I cannot figure what it does exactly.
<unmatched-paren>avalenn: apparently: "An in-toto layout defines the steps of your software supply chain that you carry out in order to write, test, package and distribute your software.
<unmatched-paren> https://in-toto.engineering.nyu.edu/
<raghavgururajan>Aleci[m]: I personally use file-like objects instead of text-blocks. https://git.sr.ht/~raghavgururajan/guix-config/tree/master/item/home/config.scm
<unmatched-paren>wouldn't a simple makefile accomplish the Exact Same Thing
<unmatched-paren>seems to just be another reinvention of the wheel
<ryanprior[m]>I don't know- it's not easy to predict what a Makefile will touch
<ryanprior[m]>Take a Makefile you know well, create a list of files you predict make will touch when executing the default rule, then run make under strace and compare to your prediction.
<raghavgururajan>"but there are also tests that can be run from the installed package that are allowed to have network access" <-- vagrantc and ryanprior[m]: Those would be 'installed' tests correct? I think we disable installed tests.
<ryanprior[m]>raghavgururajan: not sure if you read this far back in the history, but I've been thinking about proposing a change to how to we handle tests in Guix
<raghavgururajan>*disable installation of installed-tests files.
<ryanprior[m]>The beginning of my thread starts with "thesis:" if you're searching.
<raghavgururajan>Ah I see.
<ryanprior[m]>I'd be interested in any feedback you have, I'm thinking about writing a blog post as my thoughts come together
<raghavgururajan>Sure thing. I'll let you know if I have any, after reading the history. :)
<ryanprior[m]>reading some in-toto docs now, they have this example of metadata for a package but there's no explanation of what these files means so I'd have to do some synthesis https://in-toto.io/examples/debian/
<Aleci[m]><raghavgururajan> "Aleci: I personally use file-..." <- Yes i do the same i load my files from my personal repo using the local-file field. This works.
<Aleci[m]>But i would like to divide packages in profiles instead of keeping all in the default profile as you are doing. As if you group your Communications packages in one profile, DevOps packages in an other and so on. But when you login, if they are included in the loading for loop in the .bash_profile, they should be visible by the whole system (not just by the single child terminal that runs the .bashrc).
<Aleci[m]>* Yes i do the same, i load my files from my personal repo using the local-file field. This works.
<Aleci[m]>But i would like to divide packages in profiles instead of keeping all in the default profile as you are doing. As if you group your Communications packages in one profile, DevOps packages in an other and so on. But when you login, if they are included in the loading for loop in the .bash_profile, they should be visible by the whole system (not just by the single child terminal that runs the .bashrc).
<Aleci[m]>* Yes i do the same, i load my files from my personal repo using the local-file field. This works.
<Aleci[m]>But i would like to divide packages in profiles instead of keeping all in the default profile as you are doing. As if you group your Communications packages in one profile, DevOps packages in an other and so on. But when you login, if they are included in the loading for loop in the .bash_profile, they are visible by the whole system (not just by the single child terminal that runs the .bashrc).
<dirtcastle>I'm using stumpwm. the wiki said it's better to get it from the official site
<dirtcastle>for sbcl
<dirtcastle>should I get sbcl from site or guix
<avalenn>found the right document for in-toto : https://raw.githubusercontent.com/in-toto/docs/v0.9/in-toto-spec.pdf
<avalenn>it is just a way to notarize people saying "I did this"
<avalenn>so nothing of value in my opinion
<avalenn>sorry for the noise
<lechner>Hi, is there a favorite place where people keep their custom channels, or does everyone serve their own?
<AceTheMercenary[>I wish there was a directory for channels
<AceTheMercenary[>An indexed directory
<AceTheMercenary[>It'd benifit the community
<AceTheMercenary[>All kinda tweaked wares
<AceTheMercenary[>searchable through eaxh channels
<AceTheMercenary[>s/eaxh/each/
<AceTheMercenary[>Like say we search dwm-david-version and we get the channel from david
<AceTheMercenary[>I bet the search engines already do that
<AceTheMercenary[>but it kinda is bloated with all unrelated results sometimes especially if it's a new project or channel
<patched[m]>How do you guys manage packages with conflicting entries? Currently can't install both pidgin and zathura because they depend on different versions of gtk+.
<AceTheMercenary[>Correct me if I'm wrong, but doesn't functional nature of guix already manage that.
<unmatched-paren>AceTheMercenary[: gtk+ seems to be a propagated-input in pidgin and zathura (for some reason)
<unmatched-paren>but yes, it does prevent colliding dependencies in native and regular inputs
<AceTheMercenary[>I c
<AceTheMercenary[>this is actually news for me
<AceTheMercenary[>I thought it might prevent propagated input collisions as well
<unmatched-paren>The reason being that propagated inputs are installed to the profile
<unmatched-paren>Think of a C program. It requires GCC, but it doesn't install the `gcc` command into your $PATH. If GCC was a propagated-input, on the other hand, installing that C program would give you access to `gcc`
<bjc>did something just get a new rust dependency?
<patched[m]>Feel like this is bound to happen sooner or later with more packages, as the amount of potential collisions grows quadratically. Is there a nice workflow to handle this better? Currently I use guix shell to circumvent the issue, but that feels a bit like an ugly hack.
<bjc>i did a ‘guix home reconfigure’ and it seems to be downloading like 90% of crates.io
<vagrantc>bjc: i suspect you could have a running counter for things adding rust dependencies...
<bjc>patched[m]: you might need to figure out why gtk+ is propagated in those packages. it seems odd for a library to be
<bjc>vagrantc: it does seem to be like that, yes
<bjc>this is giving me real npm vibes though
<bjc>lord knows what i'm pulling in that requires so many dependencies
<unmatched-paren>bjc: this is just average Rust stuff
<vagrantc>well, with guix at least you actually can find out exactly what you're getting
<vagrantc>if you have the resources to actually look at them all...
<bjc>i really, really wish cargo didn't auto-download deps. it's turning the ecosystem into a hellscape
<unmatched-paren>language-specific package managers are a mistake
<bjc>a small amount of friction would have gone a long way
<bjc>unmatched-paren: yeah, i agree
<unmatched-paren>especially since Windows and (S)mac(k)OS users often won't even think about general package managers
<bjc>it's literally 892 rust packages that got downloaded.
<unmatched-paren>bjc: wow
<bjc>i don't even know what to say, other than maybe i need to stop programming in rust if it's going to be like this
<unmatched-paren>until i encounter a serious memory safety issue in my own work i'll just stick with C :P
<bjc>it's a real shame. the unsafe marker and borrow checker are actually really great
<unmatched-paren>bjc: rust has always been like that, have you not noticed before?
<bjc>i've been using rust for years, mostly in embedded, so it's never really been this big a problem
<unmatched-paren>one problem is that libraries that really should be one crate are often broken up into several
<unmatched-paren>"over-modularization" i guess
<bjc>and it does feel like it's gotten a lot worse recently. maybe i'm just noticing the hockey stick
<bjc>but yeah, the lesson they seemed to have picked up from npm is "just never delete things" as if the only problem leftpad exposed was deletion
<unmatched-paren>bjc: an example of over-modularization is the tokio series; there's loads of tokio-* crates that really could just be in tokio core
<unmatched-paren>rust-tokio-util for example
<unmatched-paren>rust-tokio-threadpool, rust-tokio-timer, rust-tokio-test, etc...
<bjc>is there a way to get a dot file of all the deps from your home config?
<bjc>i'm curious how this happened
<unmatched-paren>bjc: maybe try running `guix graph` on `~/.guix-home/profile/manifest`?
<unmatched-paren>(i have not tried this, just a guess)
<bjc>i'll give it a whirl when this finishes
<unmatched-paren>be warned that said graph will probably be HUGE :P
<unmatched-paren>not sure if the guix home manifest is actually a valid manifest.scm
<unmatched-paren>oh, no, it won't work
<unmatched-paren>you'll need to run `guix package --export-manifest` on it first
<bjc>great
<unmatched-paren>that command produces a manifest.scm from an internal manifest
<unmatched-paren>(according to the comment at the top of the guix home manifest)
<unmatched-paren>not sure how you would feed the manifest to guix graph tho... doesn't seem to have a --manifest option?
<bjc>i only have 19 packages in my home profile, so i can just do 'em one by one
<bjc>shouldn't take too long
<unmatched-paren>ah, k
<lechner>i also downloaded a lot of Rust prerequisites just now
<patched[m]>Same
***lukedashjr is now known as luke-jr
<blake2b>wow, I'm just checking out builds.sr.ht for the first time, and I have to say its so easy & helpful for offloading builds when packaging something large. and its perfect for working with emacs.
***rgherdt_ is now known as rgherdt
<patched[m]>Is there a neat way to only include a channel for /etc/config.scm ? I want to have my cpu microcode updated without nonguix packages loitering my search results.