<Whyvn>does it matter the order of guix package -u, or guix system reconfigure? Currently I am guix pull -> -u -> reconfigure -> gc
<lfam>`guix package --upgrade` has no effect on either `guix pull` or `guix system`
<lfam>`guix pull` updates (or rolls-back) the set of available packages, services, and other things like that. So, it comes first
<Whyvn>does upgrade download the new kernel or does system do that? I guess thats my mine concern with the order of using guix system.
<lfam>`guix system` controls the system, which includes the kernel. `guix package` is strictly something used by a user to control the packages they have installed themselves (remember, Guix can do per-user package management, in addition to the "system" packages from config.scm)
<lfam>There's not really any reason to "install" a kernel using `guix package`
<lfam>It would not become the kernel that your system used
<Whyvn>ok, thank you for clarifcation. wasnt sure what was dependent on each other when dealing with upgrading.
<lfam>You're welcome! It's different from old-school distros
<clacke>How can Guix programs understand my IBus input methods configured in Ubuntu?
<clacke>I have tried installing ibus on the guix side as well, and `ibus list-engine` with that ibus correctly lists my system-installed engines
<echosa>Hey, all! I installed guix as a package manager on top of Pop!_OS. I can't figure out how to run guix programs with `sudo`. For example, I installed powertop through guix. Powertop requires root privileges, but when I `sudo powertop` I get "sudo: powertop: command not found".
<ison>echosa: Probably because the root users $PATH doesn't include your users guix profile. Try sudo -E to preserve the environment.
<clacke>sudo -E works of course, but I feel better not inheriting my whole env into a root shell -- sometimes some application will write to a file in my home directory as root if it gets a variable pointing there
<clacke>sorry for that mega quote, didn't realize it would transfer over to IRC
<pinoaffe>hi folks, I'm trying my hand at packaging copasi, but there's a linking error at the end of the build phase of one of its dependencies (libcombine), and I don't know why - could someone take a look?
<leoprikler>and jgart recently removed it from the Guix wishlist (potentially for that reason)
<fnstudio>hi, i seem to have problems with an emacs package (jedi, specifically "M-x jedi:install-server"); i think this is due to jedi trying to write in "/home/user/.guix-profile/share/emacs/site-lisp/"
<fnstudio>anyone that has encountered something vaguely similar?
<leoprikler>packages trying to write to their install directories do exist; can you somehow change that directory through a clever custom-set?
<fnstudio>leoprikler: yes, that should be possible, let me try
<cdegroot>Is there a clean way to set your default profile to a store profile? I'm toying with keeping two of my "daily driver" machines in sync; `guix copy` of an updated profile works wonderfully, but then I'm manually making the symlinks in /var/guix (running Guix under Ubuntu, slowly moving software over)
<efraim>I set both machines to use each other for substitutes and keep them in sync using 'guix describe' to pul the same commit and a manifest to install the same software
<cdegroot>That's what I tried first, but my network and Guix' networking libs don't like each other. If I use the other box (I tried in both directions) as a substitute server (using `publish`) then the client will pull one, maybe two, packages before bailing out with an error.
<cdegroot>(I'm also itching to add Avahi discovery to the Guix daemon to automate that, but first it needs to work lol)
<cdegroot>So I was gonna use this as a stop-gap measure until I get a bit of time to go into the code base and figure out why the networking client seems to be a tad brittle/sensitive.
<cdegroot>(I probably could still do the same pull/update dance after a copy, but why all the trouble if I'm two symlinks away from what I need? ;-) )
<leoprikler>cdegroot: the "bailing out" is a known problem, that will hopefully be fixed soon
<leoprikler>The solution proposed by efraim is indeed the canonical one, you just need to work around with bash's while or until to make it work currently.
<cybersyn>build of guix-cli is failing on guix pull, has anyone else had a similar issue?
<civodul>"guix time-machine -- describe" works for me!
<civodul>if it works for me, i conclude there's no problem :-)
<civodul>just pushed the 'generic-html' update for "guix refresh", lemme know if it doesn't refresh as well as you'd like!
<rekado>do you remember which French ISP had reproducibly poor connections to ci.guix.gnu.org? ICMP is no longer filtered for ci.guix.gnu.org, so it would be nice if affected people could try again to see if this change makes any difference in connection speed.
<cybersyn>i started using doom-emacs about a month ago and have to say i'm pretty impressed. will be interesting to see what sort of "opinionated" community configurations of guix might arise in the future.
<roptat>rekado, I can now send ping from from all over the world with my botnet, er... the atlas network :)
<cdegroot>leoprikler thanks, if it's a known problem I'll exercise some patience :). Or figure out how I can help - I value contributing over complaining.
<zimoun>On 1a26584 from today, “guix weather“ is always failing with «In procedure %origin-patches-real: Wrong type argument: #<package firstname.lastname@example.org gnu/packages/onc-rpc.scm:38 7f721f9d50a0>». Is something wrong?
<nckx>Unblocking ICMP let me set up ye classic HE tunnel, but it still won't work. Probably because protocol 41 is blocked.
<lfam>fnstudio: I don't know how Python finds the certificates, but it doesn't seem that Python itself depends on them, so I assume that the "system" (aka you) have to set something up
<nckx>I think. It's been years since I've had to resort to that; my debugging's rusty.
<fnstudio>lfam: right... now guix edit urllib3 does mention something about urllib3[secure], but i've tried all those dependencies and they also didn't work, so i suppose it's like you say, a missing underlying setting
<mschilli>Great! So the package in question is dead simple: It is basically a single perl script with no further dependencies but a perl interpreter.
<mschilli>So all I need is to i) download the source (provided as a zip over HTTP), ii) unpack the source, iii) copy the perl script to a place where it ends up on PATH, iv) patch the shebang, and v) make the script executable.
<lfam>In general, we need to decide on and announce a specific timeline for removing Python 2 things
<lfam>Specifically for this package, I would ignore it
<lfam>If it weren't used by anything, I would remove it
<fnstudio>i think i got to a minimum example where python doesn't work with ssl certs in a pure env: guix environment --pure --ad-hoc python python-wrapper python-certifi -- python -c "import certifi; certifi.where()"
<fnstudio>this returns nothing, which is not what one would expect
<lfam>fnstudio: So, in general, programs should use an environment variable to look up certificates.
<lfam>They shouldn't depend on a "certificates package" directly, because certificates expire, and so we want to be able to update the certificate store without rebuilding packages that do TLS
<lfam>This usually means something like $SSL_CERT_DIR=/etc/ssl/certs
<fnstudio>lfam: yeah, not an expert here, but yes, it does feel like it should accept an env var...
<lfam>Zooming out, if Guix packages are finding certificates from that python-certifi package, that's (going to be) a problem
<fnstudio>lfam: right, i think i see the point, one can manually set a ca-cert in urllib, if i understand it correctly, but not with certifi; nss-certs doesn't seem to help, per se, but i suppose i can do nss-certs plus manually passing the path to urllib3
<lfam>I recommend learning how this is supposed to happen for Python
<lle-bout>flatwhatson: hey, I get errors like invalid specification for sudo with tramp on your Emacs in your channel, not sure if you know
<nckx>charles`: You'd set up your own local git repository, if you haven't done so yet (documented in the manual, something like ‘building from git’). Then you'd edit gnu/services/sddm.scm to include the new options, commit it, and send it to guix-patches at gnu.org 😉
<nckx>That should keep you busy until I've finished dinner o/
<lle-bout>maddo: Guix's not a fork of Nix, rather a functional distro like Nix but that's mostly it
<maddo>While I do have some knowledge about nix, my understanding of guix is rather limited and I wanted to see if I could jump ship (as an avid emacs user, guile is far more appealing and the guix interface for emacs is admittedly yummy)
<maddo>for example, nix is about to introduce the concept of flakes, mostly discarding channels, while I understand that guix has channels (but they seem different compared to nix)
<lle-bout>maddo: actually flakes look like GNU Guix Inferiors
<lfam>I guess we should profile it, when we start working on core-updates (after the release?)
<lle-bout>duplicating code with fallbacks to most compatible available
<lfam>There is a set of architectural features that are considered the required lowest common denominator for Guix. I'm not sure where they are documented. We have to be careful about not accidentally changing those
<lfam>It means that we don't require some newer features
<lfam>It's a good question to ask Mark Weaver, since he tended that stuff previously
<lle-bout>lfam: of course we wont, this GCC thing I am talking about is specially for creating binaries that can autodetect at runtime what features can be used and pregenerated machine code for different CPU features available and use them
<efraim>it looks like there's something about flatpackage for python
<pkill9>what would be good is that guix alternative of use-flags, combined with grafts, so you could enable all the runtime optimisations of all the core software like python, and graft them onto every package
<efraim>looks like one for interactive use and one for scripting? or something like that
<nckx>Don't worry, I'm sure it will be a nice mess to thread WORD all the way to the actual PAGER invocation :)
***daniel is now known as Guest28141
<fnstudio>lfam: as we said before, my issue with python and the certs (from earlier today) had more to do with python rather than guix, but i was able to make it work; i added nss-certs and openssl as dependencies and that did it
<fnstudio>(just in case someone stumbles upon the chat log in the future)
<bone-baboon>`guix search getmail` says that getmail has no dependencies. Is that correct? I would have expected it to have dependencies (Python for example).
<lle-bout>lfam: is it a good idea to graft sqlite from 3.31.1 to 3.35.2?
<lfam>Like, maybe some of the bugs were introduced after 3.31.1
<lfam>We can also look at what we've done in the past
<lfam>That can help us make judgements about the "safety" of grafting big updates of a package
<lfam>So, if we've done this with sqlite before, and our tests of this graft are successful, we can feel confident about it
<roptat>lfam, efraim so I managed to build python with --with-lto, --enable-optimizations, --with-computed-gotos and -fno-semantic-interposition, and I ran two "fast" benchmarks. the first is 17.9 ms -> 13.7 ms and the second is 241 ms -> 164 ms, I can run more benchmarks, but I think it already shows we get a big improvement :)
<roptat>that's for python on core-updates, with my patch to remove some output in both case
<roptat>well, I can't use %standard-patch-inputs either because it's not exported, so I just added that to a phase
<Whyvn>I am trying to setup iptables in my config.scm, I followed the example in the networking servies, but it seems with the REJECT line included at the end, non of the previous ports work. Can anyone see anything wrong with my config declration? http://paste.debian.net/1189776/
<flatwhatson>sneek: later tell lle-bout I've heard minor rumblings about guix vs tramp paths, but don't use it myself and haven't had any proper reports. Happy to help investigate, either here or as a github issue. It's possibly a regression of guix vs master, not specifically related to native-comp.
<zimoun>roptat: checking the substitute avaibility on master, I note that some ocaml4.07 are missing but build. Idem for some maven.
<bone-baboon>After every system regonfiguration the output says "shepherd: Service term-auto could not be started." Running `sudo herd restart term-auto` results in "Service term-auto could not be started.". Serching the Guix manual for the term "term-auto" has no matches. I also do not see it in the Base Services section of the manual. What is "term-auto"?
<nckx>Generic serial port terminal listener IIRC (no fixed TTY number like ‘term-tty2’, hence ‘auto’).