<lfam>All else being equal, newer is better <vagrantc>yeah, just released monday ... almost have it upgraded in debian, figured i'd move on to my next victim <BlackMug>how do you clear text in the terminal within guix? clear command not there <lfam>If you want clear, it's from the 'ncurses' package <BlackMug>ah i see, thought using different command. <nckx>‘clear’ literally prints the ctrl-L character. (OK, not literally, but like, literally.) <nckx>Literally as she is modernly usaged. *vagrantc can't wait till we discuss ctrl-u, ctrl-e and other great ctrl combinations <BlackMug>not always keybinding are the preferable way to do things even thought if it gives easier practice for example i cant access tty within guix because im using it over vm within qubes <BlackMug>if i do the key combination for tty it will access me to the tty of qubes not guix <nckx>I was embarrasing years old when I discovered I could undo deleting text at the bash prompt instead of studiously re-typing it... <nckx>BlackMug: That's a design flaw in Qubes for not having an escape key, if that is indeed the case. <nckx>You can't pretend to virtualise unixes without providing a mechanism for something as bleedingly common as Alt+Fn. *nckx suspects Qubes has an escape key. <lfam>So... how do you undo deletions? <nckx>That chart is nice and bothers me at the same time (the usual ‘Linux command prompt’ half-understanding, while at the same time I understand that ‘it's just emacs key binding’ isn't what new users will understand). Sigh. <lfam>Unix is an elegant system composed of hundreds of independent projects dumped onto a hard drive <nckx>‘Elegant’? Bold. Composed? Daring. <lfam>"Do something, and make it smell" <nckx>I just genuinely wondered the phrase ‘is sed Turing-complete’. <BlackMug>nckx searched in qubes tickets didnt find tty issue, i will try communicate with them and see about that. <nckx>Okidokey. Not a Qubes user myself. <vagrantc>Computing Guix derivation for 'aarch64-linux'... \| ... what am i doing to myself <marusich>In Debbugs, are tags free-form? Or do they have to be created beforehand? <marusich>If a bug only seems to affect powerpc64le-linux, I want to be able to tag it for easier organization. <vagrantc>marusich: there's a thing called usertags which are free-form <lfam>I have a NAR file. How can I unpack it? <vagrantc>so you should be able to use them ... they're a bit awkward in my experience <lfam>I see, `guix archive --extract` <marusich>Huh, so I can add a tag visible to a specific user, and others would have to agree to use that same user, to see my tags <vagrantc>marusich: i *think* the "email" is really just a free-form tag with the appearance of an email address <vagrantc>seeing the tags ... that's another adventure ... in debian, i only look at them through other frontends to debbugs <vagrantc>could maybe extend issues.guix.gnu.org to respect them though <vagrantc>since guix does have it's own frontend :) <marusich>I guess I could just arbitrarily start tagging my bugs with "user: omgwtfbbq@somewhere.whatever" and tag: powerpc64le-linux and it wouldn't interfere with anyone...but it sounds like this whole usertags feature expects everyone to agree play nice <lfam>Obviously we can't make a new release with this bug, but I can't seem to reproduce it <vagrantc>marusich: any freeform tagging system requires people to play nice :) <marusich>So that would supposedly be showing bugs that are unarchived, tagged with the "toolchain" usertag for user "reproducible-builds@lists.alioth.debian.org", yes? <vagrantc>marusich: and it's "user user@example.org" followed by "usertag BUG# +tag1 -tag2 ... +tagN" <marusich>This is fine for my use case; I'm just wondering what the "user" should be then <vagrantc>i think you can also add a package=guix to narrow it down <marusich>I wanted this to be something anybody could easily view <marusich>I mean, is there a benefit to using guix-devel@gnu.org instead of just "guix"? <vagrantc>i don't think it spams the specified email <marusich>The docs mentioned something about possibly sending an email when modifying the tags, but I don't know <vagrantc>not sure if it *requires* a valid-looking email or not <marusich>Well, it said "we might add a feature to notify the user when tags change" or something lik ethat <marusich>At least, it doesn't seem to require it, since debbugs can list tags for the "guix" user already <vagrantc>you can also change it later to some other address if it turns out to be an issue <vagrantc>nothing set in stone ... just start tagging :) <vagrantc>worst that happens is you send a tag and debbugs will complain that it's invalid :) <marusich>I will see if I can tag the next bug report I make with "powerpc64le-linux" for user "guix-devel@gnu.org" and see what happens. <lfam>Worst thing I had happen when playing with debbugs was the server crashed and had to be rolled back by the admins <marusich>There already is a tag for guix-devel@gnu.org: one tag named "determinism" <lfam>It broke mail delivery for debbugs-y stuff for a while <lfam>So, maybe try it during the American day <marusich>It's evening right now in most of the USA <marusich>I suppose I can wait until Monday morning <marusich>I will make the bug anyway, i'll try tagging it then. <marusich>I won't mess around with the tag until then <lfam>You can usually get the admins attention via #savannah. It's a different group but the Savannah people know how to get the FSF admins attention <vagrantc>marusich: the syntax for submitting usertags during a new bug vs. after the fact is a little different, fwiw ... ***jx97 is now known as jx96
<jagrev>Hello! I'm using a channel defined in ~/.config/guix/channels.scm. When using geiser, it's not in my load path, which I think makes sense, it's not in site lisp (/run/current-system/profile/share/guile/site/3.0/gnu is though). I _do_ see the added channel in the store, though. What's the right way to make the contents of the channel visible to <jagrev>ah, think I figured it out: sub in `guix repl` instead of straight `guile` <jagrev>gonna try something like `define-geiser-implementation` deriving from guile, overriding binary/parameters <ryuslash>Hello :) does anybody happen to know if it's possible to change the current working directory during a phase in the build system? I tried just doing (invoke "cd" "..."), but that failed (I'm guessing it's because cd is not available during builds) <nalaginrut>hi folks, how can I install libstdc++ and libgcc_s ? <ryanprior>nalaginrut: hi there! It sounds like you probably want the gcc-toolchain package <nij>Hello! When I xinit, my wm is successfully loaded, but my <nij>keyboard seems disconnected (tested on stumpwm, dwm, xterm). In <nij>particular, numslock doesn't work, and C-M-F2 cannot change <nij>console. I can force shut down by holding the power key. I also <nij>pre-run =sleep 30; pkill stumpwm= on another tty, and it did kill X <nij>and bring my keyboard back. This is how I run xinit: <nij>suggestion would be highly appreciated. <nalaginrut>ryanprior: I've installed gcc-toolchain, but libstdc++ and libgcc_s are still missing <ryanprior>On my system I see them in the gcc package (with paths like /gnu/store/347y0zr1a9s2f5pkcncgi3gd0r33qq81-gcc-9.2.0-lib/lib/libstdc++.so, /gnu/store/347y0zr1a9s2f5pkcncgi3gd0r33qq81-gcc-9.2.0-lib/lib/libgcc_s.so <ryanprior>And the gcc-toolchain package requires the gcc package I think. So possibly it's on your system but something's telling you it's missing? More context would help. <ryanprior>nij: sounds frustrating, I have no idea though! <nij>ryanprior: thanks for reaching out! no worries! <nij>I should add that almost the same config.scm worked a few months ago. I didn't have this problem. <nij>Or if anyone would like to share.. if your favorite wm isn't supported by guix by some nice abstraction, how did you deal with it? In particular, how did you handle X correctly? <nij>OHHHHHHHHH I know.. I didn't add my user into the "input" group.. <nij>Playing with the "bare-bone" template has killed 5 hours of mine :) exciting <nij>Now I logged into stumpwm.. but my config doesn't load well. An error: Error loading .../config: Unable to load any of the alternatives: ("libssl.so.1.1" ... "libssl.so") <nij>I've put r-openssl and openssl as packages in my user-config.scm, and ran `guix package -m ./user-config.scm`. Whatelse library do I need in order to get libssl? <Akawama>Are there regional repository mirrors for guix? <ryanprior>Akawama: I remember reading in the mailing list that there's a mirror in China, I'm not sure what others might exist though <lfam>ryuslash: `cd` can be made to work, but there is the (chdir) Guile procedure. If you look in the packages you'll find examples <Akawama>Guix website's package section has hikari listed as an available package. 'guix package -s hikari' doesn't show it. What am I missing here? <brendyyn>Akawama: have you run guix pull in the last 2 weeks? <link2xt>ryuslash: "cd" is a bash builtin, you can probably run something like "sh -c 'cd ...; <another command>'" instead <link2xt>there is likely a better solution, I'm new to guix <Akawama>what is the difference in installing package with and without audo? <brendyyn>Akawama: that will install a package into /root's profile, since in that environment HOME=/root and you have root permisions <Akawama>brendyyn: I am running guix system in my single user computer. Should I then install packages without sudo? <brendyyn>i personally just install as my user and dont put anything in root <brendyyn>when you install as the root user, none of the things you install will be available to you anyway <brendyyn>guix distinguishes between the global system profile, root user profile, and your own users profile <raghavgururajan>Akawama: By default, there will be one root user (for admin work) and one regular user (for day to day work). You should the latter for most of the time. <raghavgururajan>Akawama: Note that 'guix package' invocations are *user-specific*. If you invoke 'guix package' as root, transaction happen in root profile (not system-wide). For system-wide packages (global or user-independent), you have to use system configuration. <Akawama>Thank you guys, guix system seems really interesting and unique. I will go through the manuals. <marusich>it seems something may have broken "guix environment -C" recently... I get an error about mounts not working when i try to use it... <khassanov>Hi guys. I see no option to set config for a DHCP client provided by `dhcp-client-service-type`. I want to add this option. What docs can I use to check development flow for guix? I'm newbie to GNU / savannah repos. <rekado_>khassanov: the development / contribution workflow is laid out in the manual, in the “Contributing” section. ***apteryx_ is now known as apteryx
<smoothdev>What do you people think of the fact that the organizations pressuring FSF nowadays didn't take a stance against Stallman before 2019 events? isn't it highlighting some kind of opportunism about leveraging the events to destabilize FSF? <smoothdev>(sorry mea,nt for FSF channel, keep hacking :)) <sstreet>hey, I'm trying to get let's encrypt certificates up and running with nginx. Is there a way to use the staging environment? <sstreet>think I got that, but challenging fails. <lfam>Did you set up the well-known directory in the nginx config? <lfam>There are examples here (search for 'certbot'): <ryuslash>lfam: thanks! that's exactly what I was looking for :) <ryuslash>link2xt: thanks for the suggestion :) using the `chdir' function seems to work as I need, though :) <sstreet>lfam: yes, but then nginx.conf test fails. <lfam>Then I guess the nginx config has a mistake in it <sstreet>I did have it working though. Sadly I forgot how I did it, and it appeared to be a chicken and egg problem for me. <lfam>It will help to share your error messages <ryuslash>I've been trying to build the same package a bunch of times today and keep keeping the build directory around because I'm making some changes to one of the build systems. I just noticed that according to the PWD environment variable I'm in something.drv-0 during the build, but then it also tells me afterwards that it's keeping the something.drv-17 directory around. Is this expected, or has this been fixed recently? (I am running a <ryuslash>checkout from March 30th) Or is this just because of how the build systems work? <sstreet>okay, another one higher up is that it can't find any existing certificates. That is that I've not issued any yet. <davidl>cbaines: the mysql patch is now submitted if you want to see how it turned out #47704. <sstreet>now challanges are failing with nginx saying 404. <sstreet>got it working. body in nginx-location-cofnigruation was pointing to a wrong directory. <db48x>how do I fix the “bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)” warnings that I continually get? <yoctocell>civodul: w.r.t downloading and authenticating Git repos, should we just verify the commit at HEAD, or should we verify all the commits in the history? <civodul>yoctocell: hi! i think the most common practice is to sign release tags only (at best) <civodul>(most widespread practice is to not sign anything...) <yoctocell>civodul: Ok, I might have a rough idea on how to do that. <yoctocell>We would first get the signature of the commit with 'commit-extra-signature' from (git commit), then create an <opengpg-signature> record and get the fingerprint from that. Then run 'gpg --export FINGERPRINT', and if the key can't be found we ask the user if they want to fetch it from a keyserver. If that succeds, we try to verify the commit signature. <yoctocell>This probably won't scale to verifying multiple commits though <smoothdev>there is no arch64 iso AFAICS on https://guix.gnu.org/en/download/, what lean distrib would one recommend to use as base GNU system to put guix on top of? or is there a plan to get an iso for arch64 at some point? <nckx>smoothdev: What I did (so not recommendation, just fact) was boot a Debian live USB image, install Guix's dependencies with apt, download & build Guix ‘in RAM’, then use ‘guix system init’ to install Guix System to the empty hard drive. Now that Guix is in Debian it might be as easy as ‘apt install guix && guix pull && guix system init’. *nckx can't recommend Guix on ‘foreign’ distributions TBH; it's terminal jank city. <smoothdev>nckx thanks, taking a note on that, I don't have much linux foo, but I really want to make a small vm with least amount of stuff to get guix running. I'll investigate along what you say you did. <nckx>db48x: Guix System? Guix not System? Did you try the commands from ‘(guix)Application Setup’ and/or is GUIX_LOCPATH actually set when you get that warning? <nckx>smoothdev: It's going to be a bit rough without Linux-foo, but it's doable. <db48x>nckx: not Guix System. GUIX_LOCPATH is unset… <nckx>Seems like ‘apt install guix’ won't be an option yet, at least not with the official stable Debian live ISO. *nckx 's Debian-foo is also weak. <db48x>let me refresh my memory about what is in the manual; I recall manually installing a locale package at some point <nckx>db48x: Did you use guix-install.sh? It should have created /etc/profile.d/guix.sh for you which should contain the line ‘GUIX_LOCPATH="$GUIX_PROFILE/lib/locale"’, and things should just work. <db48x>yes, but I don’t have an /etc/profile.d/guix.sh <nckx>Is this a (very) old installation? <db48x>yea, I see it in the git repo that I checked out around the same time <nckx>Let me know if creating it manually & restarting your session doesn't help. Not that I'd know what to do, but at least I'd... know :) <db48x>ok, that has worked to set GUIX_LOCPATH, but I still get the warning <db48x>$GUIX_LOCPATH/2.31/en_US.utf8 does exist… <nckx>What's it set to, and is glibc-locales installed to that user's profile? <db48x>it’s set to “/home/db48x/.guix-profile/lib/locale” as expected <nckx>Yes, but where can you download their live ISO. <nckx>db48x: When do you get the warning? Glibc locales are version-specific, so an older package still linked against an older glibc won't be able to load the 2.31 data. <nckx>Make sure whatever you're trying to run is up to date. <nckx>guix gc --references `which $COMMAND` | grep glibc <db48x> guix gc --references `which guix` | grep glibc <db48x>/gnu/store/395pvii4bcjqxvdv7h0drq10lxi01sv1-glibc-utf8-locales-2.31 <db48x>hmm. I only have glibc-locales installed, and the en_US.utf8 locale comes from that package <efraim>updating sdl2 to 2.0.14 is all it takes to enable wayland support <nckx>‘guix pull’ is a very slow boy. <nij>How do dynamical libraries work? My stumpwm complains that it failes to load libssl.so.xx.. <nckx>‘It depends’. For the normal case (linking at start-up time throug ld-linux), we add all /gnu/store directories providing needed libraries to the ELF runpath (‘rpath’). Few programmes try to be clever and call dlopen() at run time, and the solutions to those are more ad hoc. <nckx>OpenSSL is an odd dependency for a window manager, don't you think? ldd `which stumpwm` doesn't list libssl.so. ‘ssl’ doesn't occur in ‘guix build --source stumpwm’. Who's actually saying that? <nckx>(I can't launch stumpwm because another window manager is already running, which sounds fair.) <nij>hmm actually I just took my config away <nij>and there's no error <nij>this let me ponders how guixer (in general) handle programs that have a config file? <nij>e.g. most wm, emacs.. etc. <nckx>It doesn't handle them. All work ‘normally’: you put a stateful file in ~, they read it, Guix doesn't intervene. <nij>But now it seems that something in my config tries to call a dynamical lib, which is not where it thinks it is. <nckx>There's the ‘guix home manager’ that tries to handle it in a radical/semi-experimental way, but it's not (yet?) part o' Guix. <nckx>nij: That's what it sounds like. <nckx>First, try to find out who is trying to load what. <nij>Yes, I'm bisecting.. lemme see. <nckx>RPATH, I think? I always forget how exactly they interact, but it's something subtle. <Noisytoot>nckx, One of them can be overridden with something else, the other can't <nckx>(Heh, you don't remember either? ;) <nckx>We also use LD_LIBRARY_PATH once in a while just to be evil^Wdifferent. <nckx>As I mentioned y'day, there's a way to make Guix poop out a ‘startx’ script that actually uses your xorg-configuration, and you can then place in (say) /usr/bin with extra-special-file, but I can't remember how. It's documented somewhere on the wide, wide Web... <nckx>The procedure is xorg-start-command. <nij>nckx: by the way, the problem I had yesterday was a silly one <nij>I didn't add my user to the "input" group <nij>after doing that, problem solved <nckx>That's not silly. I've never been in that group or had any issues. <nckx>nckx root lpadmin lp kvm disk netdev audio video kmem wheel <avalenn>I would like to experiment some packaging on my own local channel. <avalenn>But the documentation only explain how to use remote url and authenticated channel. <civodul>hey avalenn! not sure if you saw but apteryx made nice improvements to "guix import go" <civodul>avalenn: to test packages in your channel, use the -L flag <civodul>as in: guix build -L /path/to/channel my-package <avalenn>apteryx said it to me but I did not took the time to look at his improvments <avalenn>for channels I will try with "-L", perhaps will propose improvments to the doc once I manage to understand what I am doing ;-) <pkill9>efraim ive been using SDL_VIDEODRIVER=wayland, why does it now only have wayland support <nckx>Gotta have completeness. <efraim>pkill9: I had to comment mine out, I couldn't turn it on until I experimented with upgrading it <nij>nckx: where did you put your extra-special-file's block under? <nckx>(services … (extra-spesh ...) ...) <nckx>So: (operating-system ... (services … (extra-spesh ...) ...) ...) <nij>how would I start X? <nckx>Try running /usr/bin/startx. As noted, no idea if it will work, but it's the start. <nij>no worries, im thankful for your help <nij>it says cannot open virtual console 7 (permission denied) <nij>but c-m-f7 doesn't bring me to a new console though <nij>I do have access to console 1~5 <nckx>Does this have anything to do with (the lack of) ‘rootless X’ and that AFAIK we don't support it at all? (I'm out of my depth now: I haven't run X in a very long time.) <nckx>*Back in my day* X was run as root. <nij>i hope system crafter (david) releases how he uses guix and exwm soon <nij>it's a crazily hard topic I'd say <pkill9>i want a wayland compositor with an emacs interface like exwm i guess <nckx>nij: Guix makes it quite hard. It doesn't need to be, but if ‘nobody’ uses it and nobody improves support for it, this is what you get. <pkill9>just having the commandline be the primary interaction would be sweet <pkill9>then afain mostly only worth it if you use emacs mostly <nckx>db48x: I SSH'd into a Ubuntu machine with a (coincidentally also ~6 months) old Guix. It did this <https://paste.debian.net/plainh/4fddec32>. I ran ‘guix pull’, ‘guix package -u .’, ‘guix install glibc-locales’, and ‘export GUIX_LOCPATH=/home/nckx/.guix-profile/lib/locale’. The warning is now gone. <nckx>Making sure that your ‘which guix’ returns $HOME/.config/guix/current/bin/guix is about all I can think of now. <nckx>And that ‘guix describe’ prints today. <nckx>I don't mean to make excuses or blame anyone; it's just a fact. <nckx>And the solutions that once worked seem to have bitrot. <nckx>Currently, using a display manager is the only supported way to have a good time. <nij>Yeah, I understand :) <nij>What's expressive way to obtain "/run/current-system/profile/lib/sbcl"? <nij>I imagine it is the output of something like `guix whereis sbcl` <oogel>Does anyone know why I can't set gtk themes? The colours work for gtk3, but I can't set the icon theme, and vice versa for gtk2. I'm running openbox and trying to set the themes through lxappearance or manually in the config files. <nckx>nij: I don't understand the question. What would ‘guix whereis’ do, and obtain from what? <nij>Maybe.. `guix whereis-lib XYZ` should return the path for XYZ's library? *nckx discovered whereis(1) now. <nckx>I guess I don't understand why this would be a guix subcommand. <nij>That returns where XYZ is, not where XYZ's lib is. <nckx>Like you, I suspect something like this has been written before, but it wouldn't be Guix-specific. Ideally, like which, it would try to use the same mechanism that software would actually use to search for libraries. <nij>But maybe my question doesn't make sense at all.. <nckx>Guix does complicate matters by not using a global search path, so it'd be ‘where's libfoo as seen by bar’, reading bar's rpath etc. Hm... ***Noisytoot is now known as Noisytoot__
***Noisytoot__ is now known as Noisytoot
***stikonas_ is now known as stikonas
<efraim>Can mlocate or the other locate databases join databases together? Seems like a way to put together a list of sorts 'libfoo was last seen on X date from this package' <efraim>Might be simpler short term to package apt-file and query that <felipebalbi>hi guys, how can one find and install cross-toolchains on guix? I've looked for packages matching cross, aarch64 (the one I need), and toolchain. But could only find the regular gcc-toolchain <felipebalbi>oh, right, and I also found arm-none-eabi-toolchain :) <Whyvn>I install the bind package, which shoud have dig, but I cannot seem to excute dig. Is there another step I have to take to use the dig command? The description of the bind package says "The utils output of this package contains the following command like utilities" and dig is listed in them. <nckx>Not guix install bind, so you can probably remove it. <lubrito>cbaines Hi, just a heads up. I'm still working on the task you gave me. Currently I'm stuck on how to properly get all the values out of the data coming from the derivation-differences-data procedure. <cbaines>lubrito, good good, I'd look at how the data is processed to generate the HTML as an example to follow <raghavgururajan>If I want to sent revised patch for one patch of the series, how do I do that with git send-email? Will the numbering be preserved? <nckx>raghavgururajan: I think the LKML way (from whence git came) is to send the whole series again. Even if you changed only one patch out of 50 you'd still use ‘git send-email -v2 [--in-reply-to=<...>] -50’. <nckx>If you really want to send a single one I think it's easiest to just ‘git format-patch -v2 -50’ and send it manually in reply to its corresponding v1. <nckx>I think the first way is much easier for reviewers to keep track of though. <roptat>I'm a bit busy with my server still not booting, I'll try reinstalling guix with an older kernel, but the fact it can't boot older generations is worrying <roptat>are we still planning a release on the 18? Do we enter string freeze tomorrow as planned? <roptat>I can't use my email right now because of my server issues, so I'd need someone to announce it if that is the case :) <lfam>roptat: Yes, the plan is still on schedule <lfam>It's not great that your server stopped working :/ <lfam>Are you able to read the disk? Do the bootloader's files look okay? <raghavgururajan>> nckx: raghavgururajan: I think the LKML way (from whence git came) is to send the whole series again. Even if you changed only one patch out of 50 you'd still use ‘git send-email -v2 [--in-reply-to=<...>] -50’. <raghavgururajan>> nckx: If you really want to send a single one I think it's easiest to just ‘git format-patch -v2 -50’ and send it manually in reply to its corresponding v1. <raghavgururajan>> nckx: I think the first way is much easier for reviewers to keep track of though. <lfam>Just send all the patches as a single file <lfam>`git format-patch ... --stdout > mychanges.patch` <lfam>I have to be in a really good mood to deal with 50 individual patch files <nckx>Not sure if trolling or serious. <nckx>raghavgururajan: -50 is just an example if your patch series is 50 patches long. <lfam>Sorry if I misunderstood the problem... <lfam>Please don't send 50 individual emails each with their own patch <lfam>I know, we've always done that <lfam>It's annoying to deal with them <mmalter>Hello guys. I'd like to install guix on a specific partition since I've heard it can get fat. Where should I mount it? /gnu? I am under the impression that apart from the daemon, nothing else is touched. <nckx>How do you deal with that... thing you described above? <nckx>git barf -50 > halp.txt. Does git am - even accept it? (Never tried to be honest.) <lfam>It's a standard part of the Git patch workflow <lfam>mmalter: There's more to Guix than just the /gnu directory <nckx>But OK, fine, that's an option then, raghavgururajan :) <lfam>mmalter: You could put the /gnu directory on whichever partition you like, but there are also necesssary files in /var/guix, /etc/guix, and the users' home directories <lfam>It can definitely get much larger than old-school distros like Debian <mmalter>lfam: err all right. Does /var/guix get big? *raghavgururajan 's head spins anti-clockwise *nckx gets the holy water again. <mmalter>all right, I guess I'll be fine with just gnu then. <lfam>I'm sorry raghavgururajan and nckx <lfam>You can do as you like. My position on this has evolved over the years... <lfam>I know what I prefer, and what I do these days <nckx>That's fine, don't know why apologies are in order. <lfam>Because I feel bad about giving contradictory advice at different times, nckx raghavgururajan <lfam>And, I could give the advice in a gentler way <lfam>The important thing is to send patches :) <nckx>mmalter: ‘several gigabytes’ is what you can expect from /var/guix, and a very unscientific estimate is that it's around 1% of /gnu/store. <nckx>If deduplication is enabled (it is by default). *raghavgururajan hits guix with patches. <lfam>Hit me with music, or patches <nckx>Are you sending patches or music? <nckx>Not sure if we accept .oggs. *nckx tried. Looks like we do. *nckx rejects the message. <mmalter>nckx: Ok now that makes sense. I don't need much though. My Debian is only a few gigabytes and I guess I'll uninstall much of it after guix is installed. <mmalter>Meh, enough precaution, I'll dive into it. <mmalter>But I guess my dreams of a portable guix on a usb stick are a bit silly. <nckx>Actually, ‘several gigabytes’ is probably power user territory. <nckx>For /var/guix I mean. But /gnu/store is easily several tens. <nckx>mmalter: That doesn't sound silly, it sounds neat, although it'll never be as easy as ‘just mount /foo’ even with /var/guix moved to /gnu. <lfam>They somehow went "back in time" and broke their Guix installation <lfam>I'm thinking that maybe they reconfigured before ever `guix pull`-ing <nckx>I'm missing context so may be way off base, I just notice ‘which guix’ and immediately think ‘did they run hash first’. <lfam>(I'd link to my inline reply but it hasn't appeared on the website yet) <lfam>I think that `which guix` is expected after first installing <lfam>If I understand correctly, the user's Guix only appears after first `guix pull` <lfam>nckx: Look at their version string <nckx>I just mean that ‘guix foo && guix pull && guix bar’ will *not* run guix bar with the new guix, while ‘which guix’ will make you think it does. <nckx>I'm still reading the rest. <lfam>Guix warns the user to run `guix pull` before reconfiguring, and warns about the downgrade <lfam>The manual warns about this too, I think <nckx>So is 1.2.0rc2-1.0d4b1af what you get when you ‘guix install guix’ with 1.2.0? <lfam>However, we should make it impossible <lfam>I've installed this ISO, and the `guix --version` is 1.2.0 <nckx>In the resulting system? <lfam>Oh, if you `guix install guix`? Maybe? But then `which guix` would be different <lfam>I'm there now, if you want me to try anything <lfam>I want to reconfigure without pulling and see what happens <nckx>Right. I didn't mean they literally ran ‘guix install guix’, just that it's the same ‘nesting doll’ downgrade effect. <lfam>What I really want to know is if this breaks the TLS stuff <lfam>Since TLS for `guix pull` broke for both cbaines and Bone Baboon, it's definitely a problem <nckx>guix@1.2.0rc2-1.0d4b1af is the guix package contained in guix@1.2.0 <lfam>So, if they did *something* before ever `guix pull`-ing, they'd go backwards <lfam>We already detect this scenario and warn the user, but I think we should simply prevent it <nckx>If we figure out what, absolutely. <lfam>Basically, when we print the warning "Failing to do that may downgrade your system", we should throw an error <lfam>Alright, time to reconfigure and see if TLS breaks <lfam>The thing is, I think it's a common workflow to reconfigure immediately after install. Like, "Oh no, I forgot to package X, I'll add it real quick" <lfam>Forcing the `guix pull` is less than ideal, from that point of view *nckx finally downloaded image; starts VM. <nckx>Sigh, QEMU is bugged on Sway but let's ignore that. <lfam>I just did %base-services and am working at the console <lfam>After installing the ISO and booting it, `guix --version` is 1.2.0 <civodul>lfam: hey! regarding the release, anything important to look at over the coming days? <roptat>lfam, the server is at my parent's house, so I can't see it ^^' <lfam>Congratulations raghavgururajan! *raghavgururajan jumps in joy and hits his head on the roof <roptat>lfam, it's an ARM machine, the bootloader is stuck at "Starting kernel" <lfam>civodul: nckx and I were just brainstorming the issues with the report on help-guix. It's clear the user reconfigured without ever running `guix pull`, and "downgraded" Guix. But, I'm not sure that should break TLS for `guix pull` <lfam>civodul: I'm in a VM trying to reproduce their issue now <nckx>I sent that hours ago 😛 But congrats. <civodul>lfam: oh yes, this certificate issue is a mystery to me <civodul>raghavgururajan: yay, welcome on board! :-) <lfam>civodul: I was wondering if we should make the warning "Failing to do that may downgrade your system" into a hard error <lfam>I'm not sure if we can detect the correct scenario accurately, however <civodul>lfam: can that reconfigure warning still be triggered actually? <civodul>guix now always knows which commit it comes from <civodul>so i think the dowgrade detection machinery can always determine whether there's a problem <lfam>I don't know. I'm booting the 1.2.0 ISOs for testing <lfam>It exists at 1.2.0, but perhaps we've improved this stuff since then <civodul>i'm referring to 8ecc265c5c6519986758567682726647850d5d03 and thereabouts <lfam>The user Bone Baboon on help-guix was able to downgrade their system. I'm sure it was unintentional <civodul>yes, 1.2.0 didn't have the thing above, it's quite new <lfam>This is something I'll test pre-release <lfam>It would be great if users who want to reconfigure right after install don't go backwards in time <lfam>I think it's very common to want to reconfigure after install. Like, if you forgot to add a favorite package to the global packages, or to tweak a service <lfam>Beyond this issue, we need to either fix or unblock the bugs listed here: <https://bugs.gnu.org/47297>. Then, it's time to test the images and other release artifacts <lfam>I can handle the security updates for `patch` <lfam>I don't think I can handle #47567 "Installer crash in 'uuid->string' for a FAT16 partition" <lfam>There's a patch for #42129, awaiting a "real test" <civodul>we need to get mothacehe's help on the installer issues <civodul>there are probably others left in the bug tracker <lfam>They should be added to #47297 <nckx>Haha yes, I just downgraded an entire system by reconfiguring. Excellent. <nckx>I also got a weird ‘restart installation from...’ dialogue for no reason after the Networkmanager/Connman/DHCPclient one. It didn't happen again. <lfam>Alright, I can reproduce the TLS bug <nckx>lfam: Did you manage to reproduce the TLS error? I'm unable to. <lfam>For some reason, it fails when nss-certs is not installed at the system level <nckx>OK, that explains it, I installed them. <lfam>It's supposed to use le-certs. It even downloads le-certs, immediately before failing <lfam>Alright, I'm going to try reproducing it with a current ISO <ss2>I'm trying my luck again with packaging voltcl. <ss2>But it hangs with not finding pulseaudio.so.0. <ss2>If I remove the (arguments ...), it will fail saying that pulseaudio was not found. <lfam>What is the "volctl" file being substituted? <ss2>to be fair, I copied that snippet from pulsemixer. <lfam>I don't see this file in the Git repo <nckx>Here, volctl is a directory...? <lfam>For pulsemixer, there is a 'pulsemixer' file <lfam>Hm I'm not sure that any of the "images" on ci.guix.gnu.org are the actually installer <lfam>ss2`: "In procedure fport_read: Is a directory <lfam>The substitute* procedure works on files <ss2`>I was seeing that, and wondering.. <nckx>You probably want volctl/lib/pulseaudio.py. <nckx>As the first argument of substitute*. <nckx>> error: Failed to load libXfixes.so, library not found <lfam>Oh, I was holding QEMU wrong. 'image.iso' is the installer image <nckx>> ValueError: Namespace Gdk not available <nckx>You'll need to mess with gobject-introspection for that, and I hate that, so I'm bowing out. <lfam>I retitled #46829 to '`guix pull` uses incorrect certificate store' <lfam>That more accurately describes the problem, which is quite bad <nckx>ss2`: For libXfixes, use (substitute* "volctl/lib/xwrappers.py" (("libXfixes.so") (string-append xfixes "/lib/libXfixes.so"))), I guess. <ekaitz>hey! i have a "simple" question, is there any way to check if a dependency is not used by a package? <lfam>ekaitz: There's no way that is completely bulletproof, but `guix gc --references $(guix build package) | grep dependency` can be useful <lfam>It really depends on some factors, like which language the package is written in <lfam>Then, my example should work <lfam>Those "references" are literally just strings that look like paths in /gnu/store, found in the built output of the package at the end of the build process, and registered in the Guix database <lfam>This is how the garbage collector knows what is okay to delete <lfam>C++ should handle this well <lfam>Other languages, not as well <lfam>And sometimes there are bugs, like if the string references are obscured somehow. We try to disable that at the compiler level ***nckx is now known as jorts
<ryuslash>woops! I made the wrong change to the build system and now my local checkout of guix is rebuilding the world :) <ryuslash>apteryx: I heard you were also trying to update the Go build system to work with go modules? <ss2>I haven't succeeded so far. Now it says that gdk isn't found, and have tried to get around this by adding gtk-pixbuf <guixy>I have a 500GB drive dedicated to the store. Is there a recommended bites-per-inode ratio for such a setup? <guixy>Already I'm using 80% of the inodes and 25% of the disk space <roptat>lfam, do you know if I can use the foreign system's uboot to boot on guix? <guixy>lfam: I'm not familiar with uboot, but I'm guessing it hard-codes certain paths critical to boot, such as the kernel and initramfs You can try changing those paths to point to the guix versions, or linking those locations to the guix versions at those hard-coded locations in the store. <guixy>That might be only part of the picture though <guixy>Filesystem 1K-blocks Used Available Use% Mounted on <guixy>/dev/sda2 463156048 117420844 322138404 27% /gnu <guixy>Filesystem Inodes IUsed IFree IUse% Mounted on <guixy>/dev/sda2 29483008 23347490 6135518 80% /gnu <guixy>How should I calculate the ideal bytes-per-inode ratio for my store? <guixy>Is it (/ (* 1024 used) IUsed) <guixy>And round to nearest power of 2? <lfam>What inode size are you using? <lfam>You can use `tune2fs -l $filesystem` to check <guixy>I want to re-format my /gnu partition with a more efficient bytes-per-inode ratio. Unless there's a way to adjust the number of inodes without reformatting? <lfam>There's no way to change bytes-per-inode <lfam>I recommend checking the man page for `mkfs.ext4` to get some advice <guixy>"man mkfs.ext4" says -i option specifies bytes-per-inode. <guixy>Specify the bytes/inode ratio. mke2fs creates an inode for ev‐ <guixy> ery bytes-per-inode bytes of space on the disk. <guixy>"Be warned that it is not possible to change this ratio on a filesystem after it is created, so be careful deciding the correct value for this parameter." <guixy>Which is a better equation to estimate the ideal bytes-per-inode, (/ (* 1024 Used) IUsed) or (/ (+ (* 1024 used-blocks) (* inode-size used-inodes)) used-inodes)? <roptat>I'm trying to chroot on the guix system, but the daemon doesn't work well, "cannot pivot old root directory onto '/gnu/store/brkm5bb59w9i4kmyznk0k4ndsz6dzq95-system.drv.chroot/real-root': Invalid argument" <roptat>(I mounted the filesystems like LFS does, and I managed to chroot) <jonsger>has someone a working sysctl configuration for collecting core dumps? firefox/icecat is crashing sometimes but collecting a core dump does not work :( <pkill9>why does guix show only some of what it will build/download? can't remember