<roptat>(I'm submitting a paper to a conference with an artifact, and they need a VM, so I'm installing Guix in it ^^)
<lcat>I'm sorry that my English grammar is not very good, I mean if the client uploads their manifest and then the server 'guix build' them, can this ensure that the client will use the server's guix publish when updating?
<roptat>also I'm building subversion in a VM in a VM, so maybe there's a slowdown there too ^^'
<Kozo>bricewge: Are you using guix build or guix system disk-image?
<lcat>This seems to be another way to give up guix publish to provide caching to build my guix publish server, I don't know if it is feasible.
<roptat>lcat, if I understand you correctly, you want your client to use your substitute server, but it might not have the store item the client wants, so you want your server to fetch it from the ci (installing the item in the store, instead of caching it in Nginx)? I don't think guix publish can do that, but maybe you want to create your own ci on that server?
<lcat>Thanks everyone, I'm going to try if my method is feasible.
<Kozo>I'm sad that I bought a bunch of rpi's before I learned about Guix. Next time around, I'll be getting some Rockpro's
<ryanprior>I tried to update a couple python packages just now (python-pytest, python-astroid) and what a pain. Somebody's going to have to take the plunge and figure out a bunch of stuff for these packages.
<mroh>yeah, esp. the python tests are too often too painful
***gavlee_ is now known as gavlee
***sneek_ is now known as sneek
***sneek_ is now known as sneek
<xelxebar>What are some examples of software that's challenging to package up in guix?
<reepca>anything with bootstrapping problems, though AFAIK that's more a principle thing than a technical issue - technically I think we could use patchelf to make bootstrap blobs work, but it's not great.
<mothacehe>janneke: I think we should be able to trim down your wip-hurd-vm by rebasing on master ;)
<janneke>mothacehe: just by rebasing? /me rebased just yesterday!
<mothacehe>hehe, getting there :) I sent all my commits to master this morning.
<reepca>civodul: so I checked in guile-sqlite3 and it turns out that the statement-caching mechanism doesn't call sqlite-reset when sqlite-finalize is called on a statement but it's cached. Which means that even when user code properly calls sqlite-finalize, if a statement automatically started a transaction, it might not commit it until that statement is reset in preparation for its next use.
<reepca>"An implicit transaction (a transaction that is started automatically, not a transaction started by BEGIN) is committed automatically when the last active statement finishes. A statement finishes when its last cursor closes, which is guaranteed to happen when the prepared statement is reset or finalized. Some statements might "finish" for the purpose of transaction control prior to being reset or finalized, but there is no guarantee of
<civodul>reepca: so what are our options? disable statement caching on our side, and additionally fix it in guile-sqlite3?
<reepca>that'd be one way to do it, but I'd like to incorporate some cleanups while we're at it - currently that'd involve removing all the #:cache? #t parameters in all of our sqlite-prepare invocations. I'd like to get all those database procedures to finalize cleanly in the event of non-local exit. Right now I'm doing that with a simple with-statement macro. This also means that all the sqlite-prepare invocations get moved to a single place.
<reepca>we could simply wrap sqlite-finalize within the scope of (guix store database) so that it always calls sqlite-reset. Since there's no harm in resetting a statement twice, we can leave that in without any negative effects until the fix in guile-sqlite3 is widespread
<bhartrihari>Hello, what functions can I use to modify a line in a Makefile while writing a package definition? (in snippet field of origin declaration)
<janneke>mothacehe: to me it looks much better, nice even -- which aspect[s] are you unhappy about?
<bhartrihari>Looks like substitute* is the function I'm looking for.
<civodul>janneke, mothacehe: does that need to exist in <operating-system>?
<civodul>i feel that we should be able to without /boot/activation
<mothacehe>janneke: I would have prefered those directives to be directly "encapulated" inside the "system" derivation.
<TZander>mbakke: so, not sure if helpful, testing 'staging' I found that the main reason I wanted to upgrade to newer Qt doesn't work there. Not sure why... The webengine has a new feature that it autodetects darkmode websites. Works in arch, not in guix same versions
<janneke>mothacehe: i see...yes; that matches civodul's thought
<mothacehe>janneke: but I spent part of this morning thinking about it, I have nothing much better to propose sadly.
<janneke>civodul: "without /boot/activation" sounds nice...i failed to get rid of that
<mbakke>TZander: that's odd, which browser do you test with?
<janneke>i want this to go to a place we're all happy to be
<mothacehe>civodul: I don't feel it that way at all :p Just glad to have your support!
<janneke>civodul: if you really feel bad about it you can always consider writing an alternative patch instead of saying no ;-)
<janneke>-- at the risk that we don't learn anything
<boeg>is gparted supposed to work on guix? I've tried instlaling it, but it crashes with a critical error saying it couldn't start "dmsetup" which I don't have installed and are not available on the standard channel as far as I can see
<janneke>i for one feel very happy about the progress we have been making between the three of us, especially the past week
<cnmne>hi guix! I'm trying to follow the info manual to get the setup to hack on guix. I ran `guix environment guix --pure --ad-hoc git sudo' and then `sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild' (section 14.2). I get the error 'sudo: /gnu/store/...-profile/bin/sudo must be owned by uid 0 and have the setuid bit set'. I can't find any guix-specific help on this, but it seems like this issue cascades and usually requires a
<cnmne>reinstall for other distros. I don't mean to spam this huge paragraph, but any help is appreciated.
<mbakke>cnmne: you need to use the sudo provided by your distro, as packages in the store cannot be setuid
<mbakke>cnmne: you don't need to run the daemon from git unless you hack on the daemon itself though
<cnmne>i'm on guixSD and when I don't include the sudo package it says sudo command doesn't exist
<cnmne>I'll try that; is this in error in the info manual then ?
<mbakke>or use the absolute /run/setuid-programs/sudo file name
***sneek_ is now known as sneek
<str1ngs>hello mbakke, I've mailed a patch that fixes emacsy-minimal. if you can look at bug#41599 when you have time. note* the larger emacsy package probably suffers from this same issue. I'm queuing a major update to guix's nomad I'll revisit emacy and emacy-minimal then.
<apteryx>can someone recommend a good package for discovering which process is causing IO?
<str1ngs>I assume my-master is rebased onto master?
<jsoo>str1ngs: yeah i just rebased it a few minutes ago
<Hugal31>Hello, I am relatively a guix newbie, and I would like to know if there is a way to "export" the differences between two guix generations so I can download them on another computer, and then run guix switch-generation while the computer is offline?
<str1ngs>jsoo: it could be a caching issue. removing $HOME/.cache/guix could help
<jsoo>str1ngs: changing the directory helped but i think you are right about the cache. i just removed the cache dir and kept the .git dirs and it seems alright now
<str1ngs>jsoo: if it creeps up again you might need to change your workflow. but I think rebasing onto master should not effect this.
<jsoo>str1ngs: thanks for your help. I’ll take a note just in case
<mbakke>cnmne: great, enjoying your Guix hacking :-)
<cnmne>a few questions (doesn't have to be mbakke :p): in the guix git repo i'm generating a lot of t-profile-* symlinks (~30); is that normal ? secondly, when building with the pre-inst-env i'm generating a lot of warnings for failing to load a compiled file with "incompatible bytecode".
<cnmne>Hugal31: could you do a diff of `guix package --list-installed' ?
<cnmne>Hugal31: oh I didn't see about the offline, nvm
<Hugal31>The scenario is the following: I have an offline machine (a robot), and a laptop that serves as a remote. I want the laptop to be able to send the required files to update the robot system and kernel.
<mbakke>cnmne: the t-profile-* symlinks are generated by the test suite and are expected
<Hugal31>I'll think I'll find a way to send the packages to the other machine. What I wanted to know was if there is a way to easily get the minimm number of package to upgrade from one generation to another
<Hugal31>So I can send the needed files to the laptop, which can send them to the robot
<jsoo>mbakke: wait a second, i just rm -rf $HOME/.cache/guix
<guix-vits>^^^ jsoo, mbakke, roptat: Probably Hugal31 may do the same to keep repo in sync + `guix archive`, for that robot, then?
<jsoo>guix-vits: I like the notion of using guix copy or deploy for those purposes. Probably guix copy if the providers are not supported using deploy yet.
<jsoo>i can't speak to copying to other machines yet, though. i have not used that feature yet
<cnmne>when building packages in the guix git repo (w/ `guix environment guix'), I'm getting a wall of warnings for source files newer than compiled. I've tried `guix gc --verify=repair', but that doesn't seem to fix it, or I'm doing it incorrectly.
<jsoo>cnmne: 'make clean' fixes that for me, usually
<jsoo>cnmne: though they are warnings and can safely be ignored usually
<lfam>What are the 'signing statistics' from `make authenticate`?
<cnmne>in the guix git repo i made a branch and then made some changes to 'gnu/packages/ruby.scm', but `./pre-inst-env guix search my-pkg' isn't showing my changes. the guix cookbook made it seem like there was nothing else to it (aside from env)
<lfam>cnmne: It means that your development environment isn't set up correctly
<lfam>A common reason for this is that you've garbage collected the development dependencies that were used for `./configure ...`
<terpri>bonus: grub now understands btrfs subvolumes, so i don't run into a bug where it can't find certain files during boot, leading to "blind" booting with no console output until after i wait a few seconds and type in the disk encryption key
<terpri>i'll have to find out who wrote this stuff and send them a thank-you know. really a major improvement
<roptat>so add yourself to the group specified in unix-sock-group of libvirt-service-type
<rndd>roptat: thank you, i will study your config. i'am it will be usefull. thanks again
<lfam>civodul: If we can't work around this unusual setup, would we have to say something like "sv.gnu.org/guix.git is the canonical source of Guix and your Git repo must reflect that if you want to push commits"?
<lfam>I guess I don't really understand what the options are
<lfam>I wonder if the server can choose it's own remote name for clones, and we could name it be called "guix" or something like that
<lfam>It would be good to make sure that we could change the name of remote in the future, if necessary. I wouldn't be surprised if Git starts changing default names of things eventually
<rndd>roptat: is's still same. maybe i'm missing something. could i give yout my config.scm?
<marusich>dftxbs3e, the question is, can the version of the bootstrap binaries built from just that one change, build anything meaningful? I'm not sure because I haven't tried yet. I will when I find some time.
<rndd>roptat: also, how to reboot from cli with herd?
<lfam>I also had guile-git installed for some reason
<nckx>lfam, civodul: So this is origin requirement is known/expected? OK. It's the first time anything's ever forced me into its favourite naming scheme so it's grating but I'll live. And if I don't I'll fix it with my dying breath somehow.
<ngz>civodul: I'm not sure to understand, sorry. I use Magit to handle the repositories where I have write access. I'm not sure what hook you're referring to.
<nckx>If git passes the remote being pushed to in any way, that would suffice.
<dftxbs3e>if we want to use gcc <6.2 then we need to use older glibc during bootstrap and then sort it out by compiling gcc 6.2+ with glibc <2.26 and then compile glibc 2.26+ with that gcc 6.2+ and then compile final gcc
<marusich>I made a gitlab instance and forked your guix repo, by the way. I am not sure how to use it, but I thought I'd put my changes there. Or I could just put them in your remote repo, if that's simpler and you want to give me access