<lispmacs[work]>civodul: but if I have no network connectivity, there is no risk, yes?
<civodul>--allow-downgrades does not relate to connectivity though :-)
<civodul>the risk i'm referring to is a security risk
<apteryx>is anyone else using emacs-bash-completion and observed it not behaving well when inside a guix environment (inside M-x shell in Emacs) ? Here, it often hangs on attempting completion and I have to hit C-g too often.
<lispmacs[work]>civodul: so, the scenario is I have a guix computer not connected to the network, and I made a small tweak to the system config that doesn't involve any new packages. Just trying to reconfigure it
<civodul>lispmacs[work]: yes, so it's the bug i linked to above that's causing troubles here
<cbaines>What kind of derivations are you generating from the INI file data, are these bits of software that you're building?
<cbaines>I just gave the example of system configuration, as it's easy to explain where Guile does stuff
<bqv>i mean, to satisfy your curiosity, I was working on a module overlay to replace all nixpkgs's systemd usage with some other init system, which in some cases requires reading .service files, so I need to have access to that service data at eval time, which means IFD naturally
<bqv>so you could envision me going through the generated nixos /etc/systemd directory, reading the unit files, turning them into nix code, and using that nix code to generate a range of new code and derivations
<cbaines>One of the first things I tried with Guix was generating packages from PyPI, in maybe a somewhat similar style to how stuff from other package managers is brought in to Nixpkgs
<cbaines>I didn't get that far, and I have moved on to more mundane stuff since then
<cbaines>like putting data about Guix packages in to databases, and just trying to build packages
<bqv>one of the major reasons stuff like that is a pain in nixpkgs is the refusal to use IFD. with IFD, rust packages can all be imported in one fell swoop with almost 0 issues. without IFD, each one has to be manually imported by generating some nix files from the cargo file
<cbaines>Even though I was working on generating package definitions from PyPI, I wouldn't want to really see that in Guix
<cbaines>even though magically importing thousands of packages leads to impressive stats, I think there's more value in writing good quality package definitions, and having tooling that works with those, rather than trying to glue together other package managers with a narrower focus
<bqv>there's much to be said about that kind of generation making building other packages easier, though
<bqv>e.g. nyxt for a long time could not make it into nixpkgs because of the lispPackages set being so broken
<bqv>fixing lispPackages a bit, and subsequently me creating lisp-overlay, made it possible
<bqv>perhaps guix would be better served by learning from nixpkgs's political mistakes, and separating the generated stuff out into a separate repository, though?
<bqv>(what nix is now trying to achieve with flakes)
<cbaines>I think any generated stuff is best kept at arms length, there's value in having lots of good quality package definitions in Guix
<cbaines>I think there's also scope for Guix's importers to be able to generate package definitions on the fly
<bqv>ah, true, i forgot about that concept. i really like that
<cbaines>What I personally think is most important is not comprimising on the utility that Guix offers by providing a standardised way of building software.
<lfam>Something I've considered is that certain "ecosystems" are designed with distros in mind, and some aren't. Go and Rust are in the latter category. *Maybe* packages in those languages can be created automatically without any significant risk of lower quality than if they were written by hand.
<cbaines>I sometimes worry about this when I see things in Nixpkgs, and they're defined in peculiar ways, or not actually built in part or in full from source
<lfam>Other languages actually depend on the distributor to clean things up — one will notice they don't even issue security updates but expect distributors to patch
<lfam>But it seems like Rust software really has no need for human intervention here. The entire deployment methodology is integrated and automated
<bqv>i think the security patch thing is fair enough, actually. nixpkgs's job is not to maintain every package, just to have it available. rather than patch stuff themselves, they either remove it until patched, or apply a maintainer-supplied patch retroactively
<lfam>Older languages don't have a deployment methodology — hence the invention of "distros
<lfam>I think it's important for distros to recognize this and plan around it
<lfam>There's a conference talk here... maybe even a book
<cbaines>I think there's an aspect of distros that's necessary when you want help working with software in multiple languages. Even Rust has an aspect of this assuming your process doesn't start by assuming you're already got a built Rust compiler
<bqv>my worry there is it just leads to the blending of concerns. I'd rather the maintenance was left to some other party, even if not the original author, and that derived version is what's used in nixpkgs/guix. That's what happens quite often for "older" packages in nixpkgs
<cbaines>There are cases where a general purpose package manager is of no use, but I only really see that in things like https://mirage.io/ . You probably don't need Guix if you're just using OCaml on a hypervisor.
<lfam>Guix is hardly afraid of blending concerns :)
<bqv>well, at least one reason it should be, is manpower. spending time fiddling with actual project code means less time improving guix as a whole!
<Aurora_v_kosmose>Does Cuirass have some sort of reporting/status feed other than just its logs?
<Aurora_v_kosmose>I was thinking of using buildbot for personal stuff, but it seems like it'd be more effort than setting up a private guix channel & cuirass.
***apteryx_ is now known as apteryx
<bdju>I tried to export a different LC_TIME in my ~/.profile and now after a reboot there are locale warnings everywhere and issues showing japanese text. can anyone help? what have I done wrong? I put `export LC_TIME=en_SE.utf8`. I didn't change the other locale things. they're en_US.utf8`
<bdju>I tried adding double quotes around the bit after the = sign and rebooting and that didn't help either. the program whose date changes based on LC_TIME shows the intended one now so it should be working, but other stuff is rejecting it maybe
<bdju>I suspect I'm hitting guix-specific issues because things I'm finding online are suggesting something similar to what I already did
<bdju>does guix not support en_SE? it seemed to take effect in one program and change the time format, though...
<bdju>could the problem be that I have LANG set? I read somewhere that LANG will then set all the other stuff. not sure how I'd change LANG, though. maybe the locale option in my config.scm
<bdju>I got `build of /gnu/store/0sman4x4hbjadpml219mw9p1hfzr9cgw-locale-2.29.drv failed` when trying to do that
<bdju>en_SE.utf8 doesn't show in my `locale -a` output. is that the problem? how do I get it there?
<maav>bdju: do you have glibc-locales installed? If you provided it through guix system configuration it should be on /run/current-system/locale/$glibc-version
<bdju>I believe my issue is more specific than you're thinking
<bdju>is there any way to get en_SE on my system or am I screwed?
<maav>hmmm, providing it through the system configuration probably ends up calling localedef... but you said that it was failing for 2.29 :(
<maav>you always can call localedef to another location and override LOCPATH with that, but YMMV
<bdju>could I just send an email to bug-guix requesting it be added a proper way?
<bdju>and then I'll just revert to what I used before for now probably
<maav>there's already a thread open about glibc-locales, even though it was more oriented towards smaller locale sets... perhaps this could be an use case for the latest patch i sent (and probably I should push it)
<cbaines>abcdw, what I'm getting at is that ungexp works within a surrounding (gexp ...)
<cbaines>where is that, and what are you doing with it?
<abcdw>Trying to get the path to pulseaudio's default.pa to concatenate the content of this file with my custom settings for pulseaudio service.
<abcdw>(ungexp (file-append pulseaudio "/etc/pulse/default.pa")) the internal form is g-expression already as I understand, probably it's not possible to get the result of gexp during evaluation of my system config file and I have to push it to the later stage.
<cbaines>abcdw, that change alone won't probably make everything work though. I'd have a look at examples of computed-file being used in Guix, you'll need to create the output file with the contents you want.
<abcdw>cbaines, found few examples with system* call, but it looks hacky to write semi-bash script inside gexp.
<cbaines>abcdw, perhaps look at crx->chromium-json, that's quite simple
<aecepoglu[m]>I'm simply trying to have a point of entry within a directory to setup an environment within which I can run my text editor or the application I'm developing. I had a sh file in which I was calling `guix environment` but that file won't execute the lines after `guix environment` :)
<Guest10890>hi guix! I'm on Guix System and noticed that Racket's package manager, Raco, came with the package. So far I've only installed Racket packages available on Guix, and am meaning to create a raco channel, but is it safe to use raco directly if I plan on working on reproducible Racket builds? I'm new and not coming from NixOS, so these details are still setting in.
<cybersyn>Sorry, just realized I didn't sign in -- this is the guest who queried above
<cbaines>That sounds like more of a Raco question than a Guix question?
<Aurora_v_kosmose>Unless you create a new channel for every package update which affects some racket package or their dependencies, raco wouldn't produce reproducible output.
<Aurora_v_kosmose>Well, it could coincidentally still produce identical output if what changed doesn't affect your specific Racket build. But that seems like chancing it to me. Of course work might going that isn't documented which might make my current statement false or outdated.
<Aurora_v_kosmose>I think it'd be easiest to build something which queries the Catalogs and outputs Guix definitions for the items.
<Guest10890>thats a good idea! i'll check with the racket crew and if noone has already implemented something like this i'll get to it
<leoprikler>cybersyn: Not really, but you could use raco as the basis for a hypothetical racket-build-system similar to how we have maven-build-system etc
<Guest5554>yeah, I was reading about this regarding rust crates and was wondering if thats what would be required. being new to Guix and Guile, how complex of task is this?
<cybersyn>sorry I don't know why ERC keeps signing me out of my username
<Rovanion>I've tried to make a package specification but when I run `guix package --install-from-file=guix-package.scm` I'm told that "guix package: error: cannot install non-package object: #<unspecified>. The package expression seems to return #<unspecified> when I run it in a Scheme REPL, but thats hardly helpful as I'm trying to figure out what's wrong. Any ideas?
<aecepoglu[m]>Rovanion: could you paste the code somewhere and share the link here please?
<cbaines>Rovanion, the last expression in the file needs to evaluate to a package
<lfam>apteryx: I think it will let you know if there is a collision
<jsoo>i'm working on aarch64 support for ghc and i'm getting somewhere. right now it's complaining about not finding ncurses even when specifying the location of ncurses. the way ghc gets host support for an architecture is by cross-compiling, so my hunch is that the ncurses i need to refer to is the build ncurses. does anyone know how i can use two different target-system dependencies to test my theory?
<apteryx>lfam: I think for 'guix environment' at least it didn't
<apteryx>lfam: I'm a bit confused because the collision checker was added rather recently (Jun 14 - 993023a28e52c87647fb78a5aa94a524f42ceb71) but I'm pretty sure I used to see lots of collision warnings -- they were muted in 827c56515e06d21aaa23d60ed05b0c45d1d49901 I think. So it seems the same thing to me, but one is at a lower level (union).
<lfam>I'm thinking of several years ago, not the recent work
<apteryx>just looked in (guix build union). IIUC unless something is catching and muting all of stderr at a higher level, we should still see messages such as "warning: collision encountered ..." even when using 'guix environment'
<apteryx>that may be hidden when verbosity level is 1 (quiet), which is the default for most commands
<lfam>Actually, I meant source directory. But the package I'm working on does not use CMake
<ufjvp>I'm trying to add a channel (in the installation image) but get an error when running guix pull: opening file '/gnu/store/b5n...-guile-3.0.2.drv': No such file or directory. Does anybody know how to fix it?