<lilyp>lfam: We're also fighting against the C++ compiler here, which will attempt to aggressively inline compile-time constants
<attila_lendvai>jpoiret, i agree, with the addendum that it's not "only for convenience". it translates to overall programmer, and team efficacy, and *that* is what one should optimize for. bugs/debugging undoubtedly lower it, but so does code verbosity and uncaptured abstractions in the name of purity.
<lilyp>jpoiret: Any discussion pointing to a good part of Rust should come with a big fat disclaimer that any perceived benefit of the language is almost immediately discarded thanks to static linkage
<unmatched-paren>i like rust-the-language (rust-the-ecosystem is uncomfortably npm-like...), but not for the safety; i like it for the 'better C' features like traits and the functional things like pattern matching and closures
<unmatched-paren>it's extremely stupid that rust has no spec, which destroys any chance of using it in a safety-critical environment (the places where safe memory management matters the most) and makes implementation of alternative compilers really hard (mrustc, gccrs...)
<lilyp>I'd still say C++ is better than Rust in that regard, even with all of its undefined behaviour.
<singpolyma>Rust is just so nice after having to worry about malloc and free in a former life
<unmatched-paren>also: 'so the recommended way of building my application is using `cargo install`. you need to install the rust toolchain.' 'umm, just to install an app?' 'yes. also the recommended way of installing rust is a curl | bash that installs a fancy shell script thing which handles toolchain installation.'
<jpoiret>I can't believe software that uses autotools does work
<lfam>civodul, all: I actually wonder what's the best course of action regarding the coreboot framebuffer stuff. We added it in December to make Guix System work by default for certain hardware / BIOS environments. If I understand correctly, it did fix a bug that someone had. But it introduced some other bugs, and we aren't making progress fixing those regressions. Is the best thing to revert those commits, unfixing the original bug?
<lfam>I'd appreciate peoples' opinions and guidance about this type of situation
<unmatched-paren>or: `just run this docker image right here. trust me! it'll be fiiiiiiine....`
<lilyp>jpoiret: the insides of autotools might be ugly, but the outward behaviour is very sane
<lfam>Another complication to this question is that the person who added this work seems to be taking a break from Guix, so I don't want to keep pinging them about it. At least, that's what I'd want, if I were in their position
<singpolyma>unmatched-paren: yeah. Compared to anything language specific guix is a dream. And it can handle all those cases and more
<jpoiret>lilyp: that bug is exactly outward behaviour not being sane
<infty>jpoiret: Thank you. There is indeed a file at this location. I will examine it.
<singpolyma>ulfvonbe`: that is an interesting idea. Can one package be composed of a bunch of derivations like that?
<podiki[m]>lfam: yeah, that's tough. maybe a discussion on guix-devel to see if any objections or better course of actions? we do have time-machine and the git log, at least (for someone to pick it back up)
<lfam>Yeah, we can always reuse the reverted work, later
<jpoiret>singpolyma, ulfvonbe`: wouldn't a single derivation be sufficient? Although with more you would get incremental compilation
<lfam>It's hard choose to to reintroduce one bug to fix some others
<singpolyma>jpoiret: that's the point. You need incremental compiles to be a useful build system
<the_tubular>jacereda I've been trying for a few days without much progress :(
<unmatched-paren>a guix extension (in the style of gwl) to automate such things would be cool
<ulfvonbe`>"package" in the wider software sense, not necessarily in the sense of a guix <package> record. I imagine splitting a <package>'s builder into multiple derivations would require some modification of the <package> 'lowering' process
<singpolyma>jpoiret: that's true. Though if I have enough cores (and I do) it might amoritize out
<lfam>podiki[m]: You're right, I should raise it on guix-devel. It's tempting to just revert without asking,but on the other hand I know that's not quite right.
<lfam>I'd like to get more people involved in maintaing the kernel packages. Already we do get patches adding support for this or that, but I'd like to make this area of the codebase more collaborative
<lfam>And it would be great to try to bridge the gap between GNOME and ourselves
<ulfvonbe`>can new "backends" be added to gnome software at runtime? Since apparently it doesn't understand non-global installation, perhaps it can be told there are backends "guix/profile1", "guix/profile2", "guix/home/user1/.guix-profile", etc?
<vagrantc>even though i think guix is great, i get worried about aggressivly promoting it because if you get someone to try guix for someone who just isn't a good model for, you're going to be doing both guix and the person a disservice
<vagrantc>guix has tradeoffs, like anything, and there are downsides to a guix and/or nix model (there are also huge upsides)
<vagrantc>e.g. "why do i have to re-download this package at the same version for the Nth time?!" "why is it building packages rather than just downloading them from a mirror?"
<dlowe>Trying to install clamav, and my system wants to build llvm (despite there being an available llvm sub). However, it's not even doing that, with an error while loading shared libraries: libLLVMTableGen.so: no such file
<dlowe>Okay, well, one mystery solved - clamav uses llvm internally to compile its rules, and it needs a really old version to do so
<f1refly>how can I modify the arguments given to cargo install in the cargo-build-system?
<f1refly>I'd like to install it with `cargo install --path helix-term`
<mroh>f1refly: there is #:cargo-build-flags in the cargo-build-system, see `guix edit tectonic` for an example.
<phodina[m]>I just encountered issue when packaging rust. The package cargo-audit depends on abscissa-core which depends on color-backtrace in version 0.3 but I added phase to package abscissa-core to use newer 0.5.
<phodina[m]>As I built the cargo-audit pkg it still looks for the version 0.3. Any idea why? Should I just package also version 0.3 of color-backtrace?
<f1refly>okay, i was searching for anything containig cd or directory
<singpolyma>phodina[m]: if you are using cargo-inputs to include it, switch to regular inputs or your phases won't run
<abcdw>KE0VVT: hi, I currently refactor sway related features to get rid of hardcoded things and then need to finish a few technical tasks to make an iso, I expect to deliver it somewhere in the March.
<tschilptschilp23>On the one hand 20h chromium rebuilds eating all my memory make me really question if I need this program. On the other hand lessing up and down a 700-line ld.ldd command has a meditative effect on my mind...
<tschilptschilp23>ha, there's just enough memory left to listen to the cds I bought today to get rid of this cobainish 'ape me' whispering ;)
<phodina[m]><singpolyma> "phodina: if you are using cargo..." <- Thanks, I tried as you suggested to list rust-abscissa-core in input list in rust-cargo-audit. However, I still have to list it in the cargo-inputs otherwise no package is found.
<tschilptschilp23>mpf. building chromium after last evening's pull (guix d7e1c5a) failes like this: https://paste.debian.net/1229710 (4 cores, 8GB RAM laptop). I guess I shouldn't have opened some browser tabs and VLC at the same time. Will wait for substitutes to be ready...
<tschilptschilp23>Which makes me ask -- how would I check ahead of time, if the new versions would be built from ground up on my machine, or if there a substitutes ready already?
<tschilptschilp23>For smaller packages I do not care, but llvm (almost), ungoogled-chromium (especially), and gimp (a little) bring my laptop to its limits. I would be totally easy to be patient, but do not know the command to properly anticipate...
<tschilptschilp23>(this was not the first time that this happened, just posting it for the first time)
<jpoiret>tschilptschilp23: guix weather is the command you're looking for :)
<jpoiret>you can check individual substitutes availability with it
<tschilptschilp23>jpoiret: perfekt, thank you -- I will monitor the weather from now on more diligently :)
<apteryx>civodul: re '.' to the sys.path; that's default behavior when invoking python directly, e.g. python -m something; it's very useful to run a local project without having to mess with PYTHONPATH manually.
<fnstudio>oh, right, good to keep in mind... and maybe something to doublecheck after i've fixed dbus+dunst
<fnstudio>jpoiret: i can't believe it... it works! i'm so happy!! ty ty ty!
<bdju>is there a reason the guix package conflicts seems to happen more and more lately?
<bdju>I can resolve them okay but I don't recall it being a problem before. like clearly if I apply my manifest that I didn't change after doing a guix pull, it's two packages I had before without issues
<bdju>why did I have openssl explicitly installed? who knows... but it could've been important in the past. removed it. hopefully all is well
<apteryx>bdju: you should probably sync all the packages in your profile to the same guix revision, by uprading them all with 'guix upgrade'
<bdju>are you sure applying a manifest after a guix pull doesn't do that? because I'm pretty sure if you use manifests you never have to use upgrade... besides when there's an issue so you're doing partial upgrades or something
<bdju>I'm essentially just upgrading everything in the text file at once
<bdju>well, removing anything not in the file too and so on
<tex_milan>hello, anyone can help me with client side mounting nfs on demand? can you share your config? is it possible to do it in home-manager?
<apteryx>tex_milan: why do you mean by 'on demand' ?
<bdju>sshfs is super easy to use and solves a similar problem to nfs. just a friendly suggestion. not sure how to help with nfs
<apteryx>I'm not sure that helps, but if you have the mount points available in /etc/fstab and the nfs-utils installed, you should be able to use nautilus to mount the shares, at least it works on Guix System
<jpoiret>bdju: indeed, -m should upgrade everything at the same time
<civodul>apteryx: indeed; "python -m site" shows no empty string in sys.path
<jpoiret>note that it will open a file in the store which will thus be read-only
<jpoiret>if you want to modify or add packages, you'll need a git checkout of the guix sources to work on
<jpoiret>(or you could work on the package in a standalone .scm file, but for rustc that might not be enough)
<rekado_>for the haskell bootstrap I’m tired of restricting myself to (gnu packages commencement) just because that’s where the old GCC and old glibc are. Is there a way to reference them in another module at all?
<rekado_>the module says “To avoid circular dependencies, this module should not be imported directly from anywhere.”