IRC channel logs


back to list of logs

*civodul -> zZz
<lcat>Is there any way to make guix publish act as a cache server?
<lcat>The client requested some software, but the server did not. The server will send a request to the next level ( to download this package, and then provide it to the client.
<lcat>I deployed a Guix server in my local area network, but it doesn't seem to have the effect I want. The client is sometimes downloaded from
<Kozo>Did you use --substitute-urls=?
<cbaines>lcat, you could probably setup NGinx to reverse proxy to both your guix publish instance, as well as falling back to
<lcat>My guix-daemon on the client uses --substitute-urls = "http://myserver:port"
<nckx>I second the use of nginx for this.
<lcat>cbaines, I refer to the nginx configuration file in the git repository, but is there really no better way?
<cbaines>lcat, better way to do what?
<lcat>the server can obtain the client's profile, and then the server builds them?
<lcat>Sorry, there is no space around the equal sign in the above command line parameter, and my translation software adds it
<cbaines>that seems to be a different from what you said originally
<cbaines>are you just trying to do something with substitutes, or also trying to build on a different machine?
<roptat>help I'm building subversion from a 1.1.0 installation image :/
<roptat>shouldn't there be a substitute for it?
<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?
<cbaines>lcat, no problem, just trying to clarify how you're looking to set things up. Guix does support offloading builds but I'm not quite sure if that's what you want
<roptat>(it's been 2 hours now, and I'm at 94% in the check phase)
<bricewge>roptat: At the end the offloading with binfmt worked after I updated the server
<roptat>bricewge, cool!
<Kozo>roptat: That's some patience
<roptat>yeah well, I know it's been two hours because I was watching a two-hours video in the meantime ^^
<bricewge>Kozo: disk-image as in
<bricewge> looks useful too
<cnmne>roptat: maybe a little late, but 'guix weather' might be what you're looking for if you want to save the build for when the substitutes are available
<lcat>guix offload is not what I want.
<Kozo>bricewge: Excellent, I'm using 3.10
<roptat>cnmne, right, but this is the installation system, so I think I've waited for long enough :)
<lcat>roptat, If I want to build a server like, how much disk space do I need?
<roptat>(1.1.0 is not that recent, it should have good substitute coverage)
<lcat>I did not find the disk information of on the Internet
<roptat>lcat, I don't have one myself, but I've heard surprisingly low amounts for one guix revision
<roptat>the issue is when you build more and more revisions, old stuff accumulate
<roptat>also if you only build a subset of the package (using a manifest) that may become very low
<roptat>of course you can always collect old builds that you don't need anymore
<roptat>so maybe 100GB would be enough?
<roptat>depends on what you want to build, too
<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.
<ryanprior>It might be me, but it won't be today.
<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.
<lfam>xelxebar: The icedtea packages
<nckx>Morning geeks.
<mroh>good morning nckx!
<civodul>Hello Guix!
<mothacehe>hey civodul :)
***apteryx is now known as Guest61150
***apteryx_ is now known as apteryx
<civodul>howdy mothacehe, how's everything? :-)
<janneke>hello civodul, mothacehe :)
<mothacehe>civodul: fine, thank you!
<mothacehe>hey janneke!
<lprndn>hello guix! :)
<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
<reepca>this." -
<reepca>this could include a read transaction, like the one started implicitly when we call path-id in finalize-store-file.
<janneke>mothacehe: i'm rebasing and will reset!
<janneke>that's great!
<civodul>mothacehe: great that you pushed the bootloader series!
<civodul>reepca: oh!
<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
<mothacehe>civodul: he, thanks for your review :)
*janneke resets wip-hurd-vm
<TZander>any love for issue 41562 ? Maybe good enough to just push :)
<reepca>you could test it in the meantime with just s/#:cache? #t/#:cache? #f/
<reepca>still not sure whether it's responsible for the starvation, but definitely a bug
<mothacehe>janneke: Great, thanks!
<mothacehe>I'd like to find another way for "image: Support extra-directives", but I think the rest could go to review (maybe in different pieces, as suggested by Ludo).
<dutchie>hi, I'm trying to update bemenu, though I'm having some issues since they changed the build system upstream. I think I worked out most of the kinks, but it's currently failing the validate-runpath check.
<dutchie>the it's complaining about is there, is there somewhere I should be configuring it?
<dutchie>also, I had to add "CFLAGS=-g -O2 -fPIC" to #:make-flags, and I wasn't sure if -fPIC should be everywhere
<mothacehe>TZander: just had a look. Does it make sense to set "enable_gui" to "OFF" then "false"?
<TZander>mothacehe: I don't have any preference, both sound fine to me
*TZander testing staging-next. More to compile than I expected. I was hoping it would all be precompiled :)
<boeg>anyone here got an idea of what package to install to get icons in apps like transmission-gtk ?
<janneke>mothacehe: yes, i imagined as much ("I'd like to find another way for extra-directives")
<janneke>we have some time to find a better way while doing #1,#2,#3 as civodul suggests
<guix-vits>boeg: if you start some graphical application from terminal: is it complains about missing icons? Probably it will specify which icons it is want.
<boeg>guix-vits: actually I just tried installing "adwaita-icon-theme" of which I got the idea from the Arch Wiki, and the icons just magically appeared in transmission
<boeg>guix-vits: indeed!
<linka>hi! did anyone install guix system on a machine with Heads?
<linka>Heads seems to want to have initrd and kernel on an unencrypted /boot partition
<civodul>reepca: could you email that to guix-patches when you have something?
<reepca>civodul: aye
*civodul feels overwhelmed
<bhartrihari>Hello, what is the use case of specification->package? When should one prefer it over simply using the symbols bound to package values?
<guix-vits>linka: what is "Heads"?
<linka>guix-vits: it's coreboot with Linux as payload
<linka>you can use it to cryptographically verify your installation
<guix-vits>Thanks linka.
<linka>it's mainly designed to run Qubes OS i think
<guix-vits>bhartrihari: i think that specification->package allow user to not "(use-modules MODULE_WHERE_THIS_AND_THIS_PACKAGES_ARE_DEFINED)" in their configs (correct?)
<dutchie>also shortcuts like "package:output@version"
<bhartrihari>I'm not sure whether or not to keep it in my config, I wrote it earlier when writing my config by copying from other examples.
<bhartrihari>Thanks guix-vits.
<linka>i think i'll reflash the computer with a GRUB-payload coreboot. Libreboot website has instruction on configuring guix for that
<janneke>have i broken my system in a weird way, or is guix time-machine broken for you too?
<civodul>janneke: works for me!
<civodul>but i guess it depends on the starting point and destination
<janneke>hmm, is this an unfortunate destination for you too?
*civodul tries "guix time-machine -- time-machine -- describe"
<janneke>guix time-machine --commit=ab0ede51c041927a1c35535aec3504f84d7a9751 -- environment --ad-hoc hello
<janneke>guix describe Generation 50 May 29 2020 09:31:40 (current) guix e3f0155
*civodul tries
<civodul>incompatible bytecode kind
<civodul>not a great start
<janneke>"it used to work" (TM)
<civodul>blam, fails
*civodul cries, files a bug
<janneke>ty, i've been slamming my head on this yesterday all day, trying to do a simple parallel task
<mbakke>TZander: the Qt update is on 'staging', which is being built on the CI
<janneke>yay...pulled back until my time-machine works -- now boost-1.66 dumps core until i time-machine back into april
***sputny1 is now known as sputny
<civodul>janneke: could you reply to the bug which starting point allows you to travel back in time?
<civodul>guix time-machine --commit=STEP1 -- time-machine --commit=FINAL-DESTINATION -- do something
<janneke>civodul: yes, sure -- i'll try to find that
<janneke>i finally managed to build boost-1.66, end of april -- 2520059bdb43fa1663ce102f3f4c442d4918c32b to
<civodul>so boost issue is something different, right?
<janneke>but to me it's all related to that one task :-/
<janneke>some days it seems that with every step you try to take you find another bug
<janneke>civodul: done ... i see that zimoun found a more recent commit already that works, but gives more warnings
<civodul>janneke: thanks!
<civodul>i'll take a look
<civodul>i think we need to set up time-machine "CI"
<civodul>it's interesting that we often break moves backwards but rarely break moves forward
<janneke>i have come to rely heavily on time machine, it's awesome
<janneke>it's also an "interesting" emotional reference point for reproducibility and functionality
<TZander>mbakke: the qtwebengine on that branch gives me compile errors
<TZander>mbakke: fatal error: third_party/vulkan/include/vulkan/vulkan.h: No such file or directory
<mbakke>TZander: on 'staging'?
<mbakke>TZander: 'staging-next', despite the name, is actually "old"
<mbakke>qtwebengine works on 'staging'
<TZander>damn, been compiling the wrong branch for 5 hours then :(
<mbakke>the good news is that substitutes should be available for most things on 'staging'
<TZander>mbakke: my qt upgrade had a certain sha1, which is only on staging-next, not on staging.
<TZander>ah, maybe the rebase you did...
<mbakke>TZander: yes, we actually had to hard-reset / rebase the staging branch, which creates new commit hashes :/
***sputny1 is now known as sputny
<mothacehe> janneke: Trying to improve the "directives" patch, I came up with: I'm not very satisfied with it though. Tell me what you think.
<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?
<TZander>mbakke: qutebrowser
<mbakke>maybe that needs updating too?
<TZander>its the latest, you merged my patch for that a while back
<janneke>well, if we manage to reduce wip-hurd-vm to 2 or 3 commits (extra-directives, boot-activation, ...) that need further thought/work; that would be pretty great already?
<civodul>janneke: yes, definitely
<civodul>sorry for being a hindrance, but <operating-system> is an important API, and i think it's worth double-checking before adding fields there
<civodul>i can take a look at the /boot/activation commit later if that helps
<mothacehe>no you're right, I think we can do better civodul :) I will also keep digging
<civodul>cool :-)
<civodul>i feel like the old fart who keeps being grumpy and spoils the party
<TZander>have some chewing-tobakko to complete the picture ;)
<janneke>no worries, civodul :)
<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
<mothacehe>me too, we are not that far anymore!
<jetomit>boeg: dmsetup is part of lvm2 package, maybe it should be a propagated input for gparted
<boeg>jetomit: alright, thanks
<civodul>janneke, mothacehe: yup, thumbs up!
<janneke>mothacehe: so, about hurd directives you say you'd rather see it "encapulated inside the "system" derivation."
<janneke>sorry, but what does that mean exactly, how isn't that possible?
<janneke>oh and btw, civodul; the hurd-directives not only carries the questionable "/boot/activation", but also the "/hurd" symlink
<TZander>mbakke: similarly, printing fails from that browser.
<janneke>we can't do without that, can we? (i know I tried to get rid of /hurd -> /gnu/store/.../hurd too)
<mbakke>TZander: printing likely fails because it is disabled in one of the qtwebengine configure flags
<civodul>janneke: i think we can't avoid /hurd
<TZander>mbakke: aha.
<civodul>janneke: it's like /bin/sh
<janneke>yeah, so we can disregard the lumping of /boot/activation into hurd-directives (add it in a separate patch until we get rid of it)
<mbakke>TZander: can you try removing the printing-and-pdf flag? not sure why it was added
<janneke>and find a way to do hurd-directives/extra-directives properly
<mothacehe>janneke: I think the main issue is that most of the activation code is in (gnu packages hurd).
<mothacehe>If we could move it to the "system" level, then we could use store elements instead of hardcoding "/boot/activation" I guess.
<mothacehe>(and /hurd)
<mothacehe>But easier said than done :)
<nixfreak>What are some good books to learn guile and scheme?
<nixfreak>right now I'm learning nim and advanced python
<janneke>mothacehe: ah, right -- yes that hasn't gotten much if any love at all
<dutchie>the "classic" is Structure and Interpretation of Computer Programs
<dutchie>which you can in fact get by `guix install sicp`
<janneke>i guess that most of that code in RC should move to services
<nixfreak>oh very cool thanks
<nixfreak>where do I find sicp in my directory
<TZander>wow, I'm guessing I can run gc a tad more often... guix gc: freed 36.307,15193 MiBs
<guix-vits>nixfreak: `info sicp` ?
<nixfreak>can I turn this into a pdf?
<nixfreak>would like to store it in calibre
<guix-vits>idk, probably the sources (`guix show sicp`) can be compiled to pdf...
<TZander>nixfreak: konqueror shows it in html if you open it in it. If its not too much to instal...
<nixfreak>yeah I rather not install KDE libs right now , using enlightenment
<roptat>well any browser will work
<roptat>there's an html version in share/doc/sicp/html
<nixfreak>thanks for the link , thanks for the path
<guix-vits>roptat: great. HTML even better.
<nixfreak>I don't have a /share/doc/sicp
<nixfreak>locate sicp
<roptat>`guix build sicp`/share/doc/sicp/html
<roptat>(there wasn't a / before share, meaning that it was relative to the package's store path)
<roptat>if you installed the package in your profile, that's also ~/.guix-profile/share/doc/sicp/html
<nixfreak>yep thanks
<mbakke> is no longer updating
<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>for that guix environment
<cnmne>i can use it normally
<mbakke>cnmne: ah, because you use --pure, which will unset PATH, and thus /run/setuid-programs/sudo becomes unavailable
<mbakke>removing --pure should fix it
<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?
<apteryx>and how much of it
<str1ngs>apteryx: iotop
<apteryx>thank you, I'll give it a try
<cnmne>mbakke: thanks! sudo is no longer an issue. You mentioned that I don't need to run the daemon, but if I don't it seems like the build is expecting it since it fails looking for a daemon socket.
<mbakke>cnmne: well, you need *a* guix daemon, but not necessarily the one from your git checkout
<mbakke>i.e. 'herd start guix-daemon' should do the trick
*mbakke sends documentation update to clarify the daemon and sudo issue
<mbakke>apteryx: 'htop' can show IO_READ_RATE and IO_WRITE_RATE, but you need to enable the columns first by pressing F2 and navigating the menu
<cnmne>mbakke: that makes sense; but now it looks like shepherd isn't even started.. `herd status' seems to say the socket doesn't exist. reboot didn't help
<mbakke>cnmne: run the configure script again, now with "--localstatedir=/var" and "--sysconfdir=/etc" :-)
<cnmne>mbakke: i did that first half as per the manual :] (configuring the guix git repo, right?), but i mean `herd status' in a new shell doesn't work
<mbakke>cnmne: use 'sudo herd status', otherwise 'herd' will look for a user daemon
<cnmne>oh man i feel dumb
<cnmne>thank you
<mbakke>cnmne: hehe, learning new stuff is hard ;-)
<mbakke>kkebreau: really nice work on that GNOME 3.36 branch :-)
<mbakke>kkebreau: it would be nice to merge the non-3.36 bits to 'master', such as the new packages and GNOME library updates (libpeas, etc)
<guix-vits>sneek: seen kkebreau?
<sneek>kkebreau__ was last seen in #guix 5 days ago, saying: We have about 13.5 thousand packages, so there's a good chance that most of what you need for a day-to-day machine is present..
<mbakke>apteryx: it would be good to push the Inkscape update to 'master', and inherit from the current version instead of waiting for the next staging cycle
<civodul>the "texdoc" command no longer works in the monolithic texlive 2019
<jsoo>hey guix. how do i use a local repo for a channel? i am getting the new warning that commit XXX is not a descendant of commit YYY
<str1ngs>jsoo: you can use file:// protocol in the uri
<jsoo>hmm. can i still specify the branch? the error message says i can configure the channel to allow non-forward updates
<str1ngs>can still use a branch yes
<cnmne>mbakke: the setup seems to be working fine now !
<jsoo>str1ngs: thanks. i do use the file:// protocol. I use a rebase workflow with my commits on top of the remote. i think the error message is because of that?
<jsoo>str1ngs: i had to go check my channels.scm configuration
<str1ngs>jsoo: possibly that is why you are getting an error. though if you rebase a branch and specify the branch I don't think it would cause a problem.
<jsoo>str1ngs: i have more context, too. this happens when i try to guix pull
<str1ngs>guix pull will use channels.scm
<jsoo>str1ngs: here's the error message
<str1ngs>jsoo: can you paste channels.scm?
<jsoo>str1ngs: i have been using this configuration for maybe a year or more:
<jsoo>i just rebased on origin/master
<str1ngs>jsoo: I think you might want to use file:///home/john/projects/guix/ same with 'private
<str1ngs>maybe it can use both uri's but I've only seen file:///home/john/projects/guix/ used myself
<jsoo>str1ngs: so remove the git dir?
<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
<str1ngs>no problem 👍
<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
<guix-vits>cnmne: maybe `guix archive`, somehow?
<mbakke>cnmne: wrt incompatibile bytecode, it suggests that you are using different versions of Guile to build the checkout, and on your system
<cnmne>guix-vits: sorry did you mean that for Hugal31 ?
<Hugal31>Maybe a guix archive combined with a diff of the generation would work.
<guix-vits>Hugal31: "Similarly, a complete user profile may be transferred from one machine to another like this:"
<cnmne>mbakke: both ./pre-inst-env and a new shell seem to use guile 3.0.2
<guix-vits>Hugal31: 4.11 in Manual probably "fit description".
<roptat>Hugal31, guix deploy maybe?
<mbakke>Hugal31: you can also use 'guix copy' to transfer a profile to another system
<mbakke>Hugal31: i.e. guix copy --to=the.server.lan $(guix build --no-grafts config.scm)
<jsoo>i spoke too soon. guix pull now says: "Git error: object not found - no match for id XXX"
<mbakke>jsoo: sounds like your git cache is corrupted, you can delete '~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq' to work around it
<guix-vits>Hugal31: though idk how it will work around different commits (off-line machine will be on older one?)
<jsoo>alright thanks mbakke
<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
<mbakke>jsoo: oh, sorry, I had not read the log
<jsoo>mbakke: no problem
<civodul>lfam: thanks for reviewing & applying the dhall patch series!
<mbakke>jsoo: presumably the commit Guix tries to compare against (57518fc7bf1efc899c0dabaa76685a319661f8e4) is no longer present after your rebase
<jsoo>lfam: yeah, what civodul said. thanks for the review
<jsoo>mbakke: exactly that
<mbakke>jsoo: does 'guix pull --allow-downgrades' work?
<jsoo>mbakke: hmm, same error
<mbakke>jsoo: can you file a bug report? seems like we should provide an escape hatch for such situations
<jsoo>ok sure. I'm not sure what to title it
<mbakke>jsoo: maybe something like "Impossible to 'guix pull' after rebasing a local repository"
<guix-vits>jsoo: so you're using `git pull`'s results for `guix pull`?
<jsoo>guix-vits: i git fetch, then rebase on origin. then guix pull
<jsoo>mbakke: reported #41604
<jsoo>guix-vits: i suppose so. i specify the local repo using file:// in channels.scm (
<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
<cnmne>that worked!
<cnmne>thank you, the wall of text is always daunting even if it's safe to ignore :]
<jsoo>cnmne: +1 agree!
*cnmne is updating packages they wrote 3 months ago but never submitted and now has to relearn everything about guix :]
<decent-usernaame>How would I swap the control and capslock key for a tty from within a tty.
<decent-usernaame>could be system wide
<pkill9>dunno, you can set it in the guix system configuration though
<decent-usernaame>pkill9: that's good enough.
<decent-usernaame>I'm currently reading through the info entry for guix and I'm getting a bit annoyed that I don't know how to change the behaviour of the capslock key outside of 'setxkb'.
<decent-usernaame>The thing is that the machine I'm typing from currently was hacked, so now I'm on a quest to read ever man page and learn every tool installed on a minimal install of guix.
<pkill9>i believe this changes it in the tty too:
<decent-usernaame>thanks <3
<pkill9>i also have it specified in the bootloader, but i doubt you need that for the tty:
<pkill9>i think you need to change 'nocaps' to 'swapcaps' if you want to swap ctrl and caps, whatever the setxkbmap option is
<decent-usernaame>it's 'setxkbmap -option "ctrl:swapcaps"'
<decent-usernaame>the thing is that GitLab is blocking me for some reason. And I can't solve captchas from lynx. > . < ouf
<pkill9>oh, this is the line: (keyboard-layout (keyboard-layout "us"
<pkill9> #:options '("ctrl:nocaps"))) ;; change caps to ctrl
<decent-usernaame>thanks for the help. I'll try that
<pkill9>that's under the (operating-system ... declaration
<pkill9>so (operating-system (keyboard-layout ...
<apteryx>mbakke: thanks for the htop tip
<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 ...`
<lfam>So, you'd want to re-do `guix environment --pure guix -- ./configure --localstatedir=...`
<lfam>And then re-run make as well
<cnmne>lfam: trying that now
<terpri>pleased to report that i switched my config.scm to use the new btrfs options and they're working just fine
<terpri>i had live-coded extra btrfs and lvm support into guix during installation, and was able to remove about half of those hacks and it just worked on the first try
<terpri>quite suprised about that, really
<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
<terpri>still need real lvm support, though :p
***bubble01_ is now known as bubble02
<terpri>sadly the busybox-static package i had in config.scm stopped compiling, so i'll have to get by with bournish if there are boot problems
<terpri>but now there is a lower probability of running into boot problems :)
<terpri>btw, any flatpak users here? it just broke for me after a recent upgrade
<terpri>attempting to run a flatpak program results in the message: "bwrap: execvp xdg-dbus-proxy: No such file or directory"
<terpri>haven't checked the bug tracker yet
<bricewge>terpri: It's apteryx that wrote the btrfs subvolume patchset
<terpri>apteryx, thank you very much for that work, apteryx :) the subvolume support is a huge improvement, and made guix a lot more usable for me
<terpri>having coded a half-broken version myself, i know that wasn't an easy change
<apteryx>terpri: thanks for the feedback! I'm happy to hear it's useful to at least someone else :-)
<apteryx>it took a couple attempts to get in its current form... I initially didn't get that the subvol option could be an arbitrary path instead of just a subvolume name.
<apteryx>next I'll try packaging btrbk, some script that provides a good backup system relying on btrfs subvolumes, from what I've read.
<cnmne>lfam: everything's working, thanks !
<raghavgururajan>Hello Guix!
<raghavgururajan>nckx: Would you be able to build me /gnu/store/xgvzsnjvsp4bnisvcn34vq1d0i6gsbd6-qtbase-5.12.7.drv please?
<rndd>hi everyone! what group i should add in supplementary-groups to use virt-manager as non-root user?
<nckx>You're lucky I literally just arrived this second.
<nckx>civodul: ‘Git error: cannot locate remote-tracking branch 'origin/keyring'’ — I don't have an ‘origin’ branch.
<nckx>raghavgururajan: I need more than the .drv name. Which guix commit produced it (guix describe, and branch name if it's not master)?
<bricewge>apteryx: Does the installer support subvolumes yet>
<raghavgururajan>nckx: It is current wip-desktop.
<nckx>Doesn't look like it. guix build qtbase@5.12.7: grafting '/gnu/store/4ccddqs20krv2vy0pggm4zfv6mmlzw89-qtbase-5.12.7' -> '/gnu/store/q2z0zd3bg1y7qbycrvycgyyrsbxix5p9-qtbase-5.12.7'
<nckx>guix describe: commit: 73e94339b5d0d44f4eeb04b716d4e8232b09752b
<nckx>raghavgururajan: Anyway, done.
<nckx> /gnu/store/xgvzsnjvsp4bnisvcn34vq1d0i6gsbd6-qtbase-5.12.7.drv → /gnu/store/4ccddqs20krv2vy0pggm4zfv6mmlzw89-qtbase-5.12.7
<nckx>And now I leave for the evening. o/
<raghavgururajan>nckx: Thanks so much!
<civodul>nckx: ah
<civodul>nckx: how are we supposed to deal with this? force people to have a local tracking 'keyring' branch?
<lfam>I think they have left for the night, civodul
<civodul>yeah, i just noticed as i scrolled
<civodul>but maybe you have suggestions too? :-)
<lfam>I think that not having an "origin" remote shows a high level of expertise, since by default it would exist
<rndd>does anyone use virt-manager?
<roptat>I do
<rndd>roptat: do you use it with sudo or not?
<roptat>no, as normal user
<rndd>roptat: could you please write what i need to do to use virt-manager as normal user?
<roptat>I've added myself to the "libvirt" group in my system config
<roptat>also, you need the libvirt-service-type and virtlog-service-type but if you're already running virt-manager as root, I suppose you have them?
<roptat>I also have qemu as part of my user's default profile, but I'm not sure it's absolutely required
<roptat>I think that's it
<lfam>I'm not sure what the options are civodul. What if we just refered to a keyring branch? What could go wrong if the wrong branch was loaded?
<rndd>roptat: where i need to specify quemu?
<roptat>guix install qemu
<roptat>actually you can see the part of my config about virt-manager here:
<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 " 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?
<civodul>lfam: yeah, i don't know
<civodul>"guix pull" can certainly ensure there's an "origin" remote
<civodul>so that's fine
<civodul>but for "make authenticate", i don't know what to do
<lfam>Well, like I said, they are experts
<lfam>They can always rename the remote
<civodul>right, we'll let nckx come up with a solution :-)
<lfam>This error is from load-keyring-from-reference?
<roptat>rndd, sure, paste it on for instance
*apteryx is sadly not falling in love with emacs-helm
<roptat>rndd, it looks correct to me, have you rebooted after reconfiguring? what is the error message?
<rndd>roptat: i didn't. is there any way to... reload?
<sneek>marusich, you have 3 messages!
<sneek>marusich, dftxbs3e says: wow awesome!
<sneek>marusich, dftxbs3e says: wow awesome
<sneek>marusich, dftxbs3e says: I used GNU Guile 2.2 previously for some reason
<roptat>rndd, I think you'll need at least to logout and in again for the group to take effect
<rndd>roptat: ok, i will do if.
<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?
<roptat>the computer? just type reboot
<pkill9>mdd loginctl restart i think
<rndd->roptat: thanks, it works
<rndd->roptat: =)
<TZander>cnmne: you can try running 'make' to see if you see your changes compiled without warnings
<ngz>Hello. For some reason I'm unable to push to the repository with the following error: <>, even though I did "make authenticate". Am I missing something obvious ?
<lfam>ngz: Is guile-git available?
<ngz>lfam: In my profile? No.
<roptat>it should be `guix environment guix`
<ngz>I did "guix environment guix; make authenticate". Roughly.
<ngz>But I'm trying to push a commit in my regular environment, not within "guix environment guix".
<ngz>err from my regular environment
<roptat>I think you should now push from inside the guix environment
<roptat>otherwise you might be missing some pieces
<ngz>That's… unexpected.
<roptat>the new pre-push hook requires a few things that are loaded in the guix environment, but not necessarily in your regular profile
<nckx>ngz, roptat: That's exactly right.
<nckx>raghavgururajan: Did it work?
<raghavgururajan>nckx: Yes :-)
<nckx>ngz: I had your reaction…
<nckx>raghavgururajan: Greatness.
<ngz>But how am I supposed to do that from my Emacs? It's not very practical.
<nckx>It is not.
<civodul>ngz: you can change your hook to do "guix environment guix -- make authenticate" maybe?
*civodul admits having everything in their profile
*roptat is a vim user anyway :p
<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.
<lfam>nckx: I think it's an overlooked assumption
<nckx>Sure. And not an unreasonable one to make.
<nckx>lfam: Your answer above was genius. ‘It is because you are such a clever git expert’. Consider a career in politics.
<ngz>IMO, this deserves some words in (info "(guix)Commit Access") section.
<ngz>I don't mind adding a few packages to my profile (because switch to "guix environment guix" every time is… meh). But what would be the minimal list?
<ngz>I know about the list in (info "(guix) Requirements"), but maybe not everything in the list is required to push commits.
<civodul>nckx: the origin requirement is just because i don't know how to do it otherwise, but i'm open to suggestions!
<civodul>ngz: i use Magit hook, but you installed the new pre-push hook, right?
<civodul>*Magit too
<ngz>civodul: yes, I obeyed and copied it into the appropriate place.
<civodul>so you can edit .git/hooks/pre-push to add "guix environment guix --"
<civodul>you obeyed :-)
<civodul>in your profile would need guile-{gcrypt,git} at least
<civodul>and in that case you'd need pre-inst-env in your hook
<civodul>well, maybe share your findings on the list because i'm going AFK :-)
<ngz>So it is better to add "guix environment guix --" somewhere in the script
<civodul>maybe, it deserves discussion
<civodul>i don't want it to be a hindrance for y'all
<ngz>Bah. Now, I can wait. I pushed my very important cdogs-sdl update. All is fine.
<dftxbs3e>sneek later tell marusich what I am sure about is that GCC 5 isnt recent enough to build on ppc64 little endian with Glibc 2.26+ - see;a=blob;f=NEWS;hb=HEAD#l1941
<sneek>Will do.
<nckx>civodul: It is the nature of a push hook to run at the most irritating time. It's thankless work. I think it's good your pushing(!) for it.
*nckx can't spell but sincere.
<ngz>OK. Some I'm editing pre-push script so it now contains "exec guix environment guix -- make authenticate check-channel-news"
<ngz>OK. It worked.
<nckx>civodul: So I'd add an optional 2nd command-line parameter ‘git-authenticate.scm commit_v1_0_1 [upstream]’, exposed as ‘make [GIT_REMOTE=upstream] authenticate’. Acceptable?
<nckx>Of course defaulting to origin instead of upstream.
<ngz>Awwwwww. Repology counts our nauty package as outdated because we use 2.7r1, whereas it should be 27r1. Not fair.
<dftxbs3e>marusich, hey, the ppc VM is up now, sorry, ipv6 interface wasnt getting configured on boot
<marusich>np - i am trying to see if the cross-built bootstrap binaries are reproducible
<sneek>Welcome back marusich, you have 1 message!
<sneek>marusich, dftxbs3e says: what I am sure about is that GCC 5 isnt recent enough to build on ppc64 little endian with Glibc 2.26+ - see;a=blob;f=NEWS;hb=HEAD#l1941
<marusich>i was wondering about the gcc version, actually. I see you chose to use a 7
<marusich>There was a bootstrapping reason why we wanted to stick with the 4 series
<marusich>I think something like, it's the last version that can be compiled without c++?
<dftxbs3e>marusich, I'm thinking we could set up that VM as an offload machine for convenience, so we'd have to create an openrc service for the guix-deamon
<marusich>which makes me wonder exactly how things worked out ok after you flipped the version to 7, but to be honest I don't understand the full bootstrap path right now.
<dftxbs3e>marusich, yes but unfortunately unless someone knowledgeable backports the float changes to gcc 4.x or 5.x we'll need to use 6.2+ for bootstrapping
<dftxbs3e>core-updates used to work with gcc-7 IIRC
<marusich>maybe it just means that internally 4.x was used to build the 7.x; i'm not sure
<dftxbs3e>but that got reverted I think?
<marusich>we should examine the bootstrap path and check with #bootstrappable to see if there are any bootstrapping concerns
<marusich>for now i just want to get the change in which will let us build something
<marusich>ideally reproducibly
<marusich>could you try cross-building with the change i showed you earlier?
<marusich>I am trying on 2 different x86 machines
<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
<dftxbs3e>marusich, yes sure
<dftxbs3e>what's your gitlab nick?
<marusich>let me upload my change
<marusich>i don't think it all got set up right...
<marusich>I tried to clone it from your
<dftxbs3e>marusich, you could've forked and then submitted a pull request but I just added you as a maintainer, there's also a ppc64le gitlab ci linked to the repo
<dftxbs3e>that one's little endian compared to the VM you currently have access to
<marusich>Oh, OK
<dftxbs3e>marusich, I'm about to enable nested virtualization in the VM you currently have access to so you can create a little endian VM within it
<dftxbs3e>and still have close-to-native performance
<marusich>for simplicify, could you give my ssh key access to the git repo so I can push to it?
<marusich>simplicity, i mean.
<marusich>it won't let me push over ssh, although i suppose i could do https if that's how gitlab likes it
<dftxbs3e>marusich, you can add that key in gitlab and it'll work, that's how I do it
<marusich>ok, i'll do that
<dftxbs3e>there's an option in your account settings for both gpg and ssh keys
<raghavgururajan>Using substitute*, I want to remove the following line from a source file.
<raghavgururajan>What is the syntax for it's shortest representation?
<nckx>raghavgururajan: That depends on the shortest (sane) string that uniquely identifies that line, i.e. on the rest of the file.
<raghavgururajan>Like expressing using mainly start and end of the sentence.
<nckx>Paste the whole thing.
<raghavgururajan>Whole file is