<ryanprior>FlakyConnectionU: it would be helpful to see a paste (or gist etc) of a whole shell session (probably starting with `guix describe` then `guix environment` invocation) of what you're doing <ryanprior>That way others can try to reproduce it or spot where some undesirable behavior might be coming from <FlakyConnectionU>Sorry, I was away from keyboard. Once I manage to shave a few more yaks I plan to get a reproducible terminal log with a clean install <emacsen>This is probably in some documentation, but how does Guix handle software that's not available on a publicly accessible url? <ryanprior>One thing which might not be obvious to you FlakyConnectionU is that there's no particular advantage to developing Guix using Guix System. <ryanprior>If there's another distribution that you're more familiar with and would require less yak shaving, then that might form a better base for your operations. <ryanprior>I do all my development on elementary OS and only run a Guix System VM on occasion to quality-check my packages. <civodul>emacsen: hi! it's not documented i think, but for private software, one can use (git-checkout ...) as the 'source' field of a package <civodul>alternatively, you can set (source #f) and use --with-source or similar one the command line <ryanprior>If you set source #f then what do you put as the hash? Or do you not have to provide one? <emacsen>civodul, I'm just thinking again about the idea of using the guix build system for something else and in some cases I won't have publicly accessible sources <emacsen>ryanprior, that's a good question for sure :) <nckx>ryanprior: You've probably figured it out by now, but hash would have been part of the origin that your #f replaces. <ryanprior>Right, that's a very handy thing! I've wondered before how I could provide a Guix package in the repository of a project, and this seems like it could be the answer. I'm going to play with it later. <ryanprior>The double guix pull pain is real. I don't know why that should be necessary. <nckx>Not sure why your pre-inst-env guix prints UNKNOWN, here it prints ‘guix (GNU Guix) 1.0.1.22956-35de74’. <nckx>ryanprior: Which double guix pull pain is that? <FlakyConnectionU>Well, I guess that the process can be slightly simplified by sorting the steps with a less nonsensical order, but yes, it's a bit contrived. <ryanprior>Do you see in his log where he runs guix pull, adjusts PATH, then runs guix pull a second time? <FlakyConnectionU>About that UNKNOWN... Maybe it's because of some Git-related issue. ¯\_(ツ)_/¯ I'm clueless. <FlakyConnectionU>There is a `.version` file in the root of the Git repository that contains UNKNOWN verbatim <nckx>ryanprior: Hm, there's just something missing or (perhaps an assumption) not quite right there. The commit above ‘Updating again with the new guix’ is already bleeding edge. <nckx>Not just that, it authenticates 6000+ ‘new’ commits. <xelxebar>Holy hand grenade. guile-static is *still* building after 8+ hours. Its for armhf-linux via qemu-binfmt on a beefy vs. Is the qemu overhead really that apocalyptically heavy? <ryanprior>Right, it prints that commit hash but then when you run `guix pull` it says a second time that it's updating to that same hash. Strange. <nckx>I guess it's possible you're crossing some ‘feature boundary’ between old and new Guixes, for example the authentication mechanism. Pulling with the old Guix gives you a bleeding edge Guix but doesn't itself update the authentication cache; then pulling again with the ‘new’ guix does? I don't know. <nckx>FlakyConnectionU: All I'm saying is that a second ‘guix pull’ should not be strictly necessary, but it's certainly possible (even likely) that it's the easiest sledgehammer to fix whatever underlying issue was really going on. Certainly seemed to work! <nckx>Easy for me to say, but maybe that's worth a bug report... <ryanprior>He tried following my instructions on Guix System and on Ubuntu with a binary installation, and he got errors both times, but the second pull finally allowed him to succeed. <nckx>xelxebar: Emulated aarch64 builds are - *very* roughly, I'm sure it depends on the actual package - ½ as fast as native builds on my x86_64 Thinkpad. <ryanprior>Fixing the "bug" might be as easy as making a new Guix 1.1.1 release so that people get a more modern stack when they boot a VM or do a binary install. <nckx>That doesn't mean QEMU has a 100% overhead: native aarch64 machines are about that fast anyway. <nckx>Well, the ones I have here anyway. <nckx>I don't see why armhf would be spectacularly worse. <nckx>ryanprior: We (I definitely) have started recommending the ‘latest’ live installer image over the 1.1 one. Maybe it's time for a ‘latest’ binary tarball. <xelxebar>nckx: Hrm. Okay. Doesn't 4+ hours still sound a bit long for guile-static though? Running on an 8 core 2.2ghz machine and all its cpus are pegged. <ryanprior>A lot of people assume (with good reason, considering how many other projects do releases) that the "latest" image is more likely to be broken or confusing than the most recent stable release. <ryanprior>That's especially true of security engineers, who I'm especially interested in trying to win over to Guix <nckx>That's a flawed assumption. <FlakyConnectionU>«Easy for me to say, but maybe that's worth a bug report...» I can't promise anything, but I'll try to properly document the issue and fill one once I manage to fix that ethereum package. <nckx>I mean, mainly due to our own inability to do meaningful QA due to our size, not only because it's a simplistic prejudice. 😛 <FlakyConnectionU>«That's a flawed assumption.» ...that I've made when downloading the image <FlakyConnectionU>Nevertheless, I see that fast paced projects are worth a master/main try <nckx>I didn't mean to imply there's nothing we should do about it, just that ‘explain why that's not the case on the download page’ is at least as valid an option as ‘continue playing the game even though our answer to everything else is that were rollin'.’ <ryanprior>FlakyConnectionU: out of curiosity, how do you intend to build the go-ethereum package? Are you going to vendor in all the deps or do you want to package them properly? <xelxebar>FlakyConnectionU: I'm a late to the party, but that log file is gnarly. Are you running on a foreign distro? Not sure if this is related, but it turns out that the repo's make actually escapes pure environments. I've had this wreak havoc before. <ryanprior>I ask because I have somebody offering to sponsor me to package everything properly and get it accepted into upstream, so I'm super interested in combining efforts if that's also your goal. <nckx>FlakyConnectionU: In Guix it just means a snapshot in time, with all the free unfixed bugs that come with that. <FlakyConnectionU>ryanprior: I was planning to vendor everything, but individual packaging can be beneficial for the Guix philosophy <ryanprior>xelxebar: yes I've run into that too, I now run `configure` in a container to prevent that escape. <FlakyConnectionU>After all the community support I've received, being a bounty hunter is out of question for me, but I'll share with you the state of the art <nckx>FlakyConnectionU: Even if we never find out what exactly went (mildly) wrong it's great that you have a detailed log file. Thanks for that. <ryanprior>I do mean that! I'm glad that brought you here :) <xelxebar>ryanprior: Do you have a precise idea what escaped for you? In my case it was /bin/sh getting called instead of guix's bin/sh. Was able to fix this by running configure with CONFIG_SHELL=$(command -v sh). <ryanprior>You should ask them if they'd still pay some or all of the bounty for a package that works but isn't accepted upstream. <ryanprior>I doubt Guix maintainers would accept it with all the deps vendored in, but it could still be useful to the person who's asking for it. <nckx>I'd certainly rather not that question depend on everyone feeling bad for someone whose income depends on it TBH. <ryanprior>xelxebar: I didn't dig that deep into it, I just noticed it was making some impure references and I was like oh hell no <FlakyConnectionU>ryanprior, I emailed them to that awfully long wallet email and they told me that they've already found somebody (probably you) :-) <FlakyConnectionU>That's a patched golang.scm file from the repository, ready for vendoring when I manage to overcome some go issues <FlakyConnectionU>Note don't forget to echo "go-github-com-ethereum-go-ethereum" >> golang.scm first for testing <ryanprior>Note that you can also use `guix build -L.` to put the current directory in Guix's guile load path, so you can provide your own packages. <xelxebar>ryanprior: Okay. I did submit a patch to fix the impure shell reference, but it looks like nobody was interested :( <xelxebar>Arguably, we should be using $(command -v bash) because the makefile contains bashisms. <FlakyConnectionU>Please note that you'll need to edit guix/build/go-build-system.scm to use (setenv "GO111MODULE" "on") in order to build the package, and it will still fail as-is <nckx>xelxebar: It's not that, our patch queue is notoriously long and slow. <FlakyConnectionU>I was wondering if we could dynamically toggle that value to on, off or auto per-package with the #: syntax <FlakyConnectionU>Is there any sane way of dropping a shell just before the build stage of the build system? <ryanprior>Yes definitely, you can use `modify-stages` in the package description to add a new stage before build and run some commands, set env variables, etc. <ryanprior>Your proposal of making it an argument to the build system also makes sense to me. <nckx>...but not an interactive shell as often meant by ‘drop’. <ryanprior>True, Guix builds are non-interactive to help keep them deterministic <FlakyConnectionU>I think I'm going to use one of my red team reverse shell snippets to break the build determinism for a while :smiling_imp: <nckx>FlakyConnectionU: You can insert a phase before the build (or any) phase to print out some assumptions, or even abort the build which is useful in combination with -K. <xelxebar>nckx: Fair point. I've ogled the length of the issue list and seriously appreciate the dev scramble. ~6 months is just way longer than any other patch I've submitted. <ryanprior>That's badass, if you can do that and post another shell log that would be sweet. <nckx>The build directory will contain a file with environment variable so you can get closer to the build environment, but there's no way to enter the container and you'll still be yourself poking around a regular directory in /tmp. <ryanprior>If Guix's isolation system is robust, it should dissuade you from doing this. For example, simply listening on a port should fail because builds are done without network access (in theory.) <xelxebar>Also, looking at the issue again, I was a bit unfair. Florian did respond at the beginning as I was flailing about in my newbieness. Once I figured out the issue and got a patch, however, it looks like nobody may have noticed. <nckx>xelxebar: Yeah, it sucks, no sugar-coating that. <nckx>xelxebar: No promises but what's the bug number? <ryanprior>If you can pop a shell and do a container escape during a build that would be /very interesting/ <nckx>The kind of interesting that gets you a special Internet award number and attention (luckily we're not that big... yet... I think). <nckx>We also don't tout it as a serious sandbox security system, but still. <ryanprior>Any software that's in production and not in alpha/beta status is eligible for a CVE, and honestly software without any CVEs looks awful suspicious to a lot of folk in my profession <Brendan[m]2>There is a guix blog post about users services, but it just assumes you've got herd working as your user somehow already without explaining <nckx>Ryan told us we need a CVE kthx. <ryanprior>I'm a security software engineer, focused on authn/authz and machine identity <xelxebar>ryanprior: My fantasy world has you working as a double agent against the NSA. <nckx>Brendan[m]2: Run shepherd, done. ‘Working’ implies that there's magic or complexity to it, but there's not. <Brendan[m]2>WARNING: Use of `load' in declarative module (#{ g54}#). Add #:declarative? #f to your define-module invocation. <xelxebar>ryanprior: Oh. Interesting problem domain. If this were a pub, I'd have a series of questions with which to poke your ideas. <ryanprior>xelxebar: let's make a point of finding a mutually suitable pub nearby some kind of free software gathering in the future :) *Brendan[m]2 ran shepherd twice <nckx>Brendan[m]2: What happens then? <Brendan[m]2>the syncthing service tried to run lock the same port so it errored out <nckx>FlakyConnectionU: Not urgent, but if you could find a way to avoid <https://www.tobias.gr/u.png> eventually it would be appreciated. And I do hope you stick around 🙂 <nckx>Brendan[m]2: But no contention for /run/user/nnn/shepherd/socket? Interesting. <xelxebar>Okay, dumb question time. When running and aborting guix build sever times in a row, I notice that dependencies get built/downloaded in a non-deterministic order. I find that mildly surprising. What's going on? <Brendan[m]2>im amazed i managed to read what i imagined happened rather than what my eye balls actually saw <nckx>Brendan[m]2: Very familiar. <nckx>xelxebar: Does it do this with -{M,c}1? *xelxebar echoes sentiment :| <Brendan[m]2>oh i get what it happened. syncthing has what cou could classify as a bug, it decalares services as started before they really have started: Service syncthing has been started. <Brendan[m]2>even if guix says a service failed to start, before that message, shepherd will lie and say the service was started <Brendan[m]2>ie there is code in guix proper that says it didn't succeed, and shepherd code that says it did <xelxebar>nckx: Oh, I see this when setting neither. That's what surprised me. Top makes it look like guix is defaulting to 1 for -M and -c... <nckx>Maybe it is, and something else is going on. <nckx>‘Random’ actions with -{M,c}1 would surprise me too, unless I'm missing something. <Brendan[m]2>in gnu/services/shepherd.scm:329 failed to started... <nckx>Downloads should take a build slot and vice versa, even though that's a ‘bug’ to be fixed in future. <xelxebar>Yeah, trying out -M8 for the first time, I noticed that. <nckx>More than that, it's the place. <Passenger1112>Wondering about dual monitor setup in guix. Both monitors works when booting, they're both connected via HDMI, but when starting X, only one keep working, the other one goes black. Is there some setting in xorg.scm I need to configure, or something else? ***sneek_ is now known as sneek
<Brendan[m]2>nckx i got a feeling someone is going to tell me that its not really a bug or something <sneek>FlakyConnectionU, you have 1 message! <sneek>FlakyConnectionU, nckx says: Not urgent, but if you could find a way to avoid <https://www.tobias.gr/u.png> soon it would be appreciated. And I do hope you stick around 🙂 <FlakyConnectionU>nckx, It's so late for me (CEST) and I'll disconnect now, but I'm interested in taking this thing as far as I can :-) <nckx>FlakyConnectionU: CEST buddies, no worries. <nckx>Passenger1112: I've only used laptops but I'd start by looking at xrandr settings, either via the ‘xrandr’ tool or some GUI. <nckx>But no, no idea why this would happen or if its expected. <Passenger1112>yes, will have a look at that. GUI tools for displays used to have both, now only one shows.. <nckx>Brendan[m]2: Looks worth reporting. I could see a ‘this is known/duplicate’, or ‘this is actually a different bug...’, but surely not ‘this isn't a bug’ if it's blatant bullshit. <Brendan[m]2>ok, now for a third bug: b@ui ~$ herd restart syncthing <Brendan[m]2>error: connect: /run/user/1000/shepherd/socket: No such file or directory <Brendan[m]2>its still running though, i have 3 shepherd processes as my user <nckx>Anyone know what would provide ‘Settings schema 'org.gnome.settings-daemon.plugins.color' is not installed’? <nckx>Oh, there's a gnome-settings-daemon package. Of course. <nckx>Passenger1112: ‘used to’ with Guix System, or a different distribution? I switched to Wayland quite a while ago, but basic ‘$ xrandr’ → TV used to work fine. <nckx>That the Shepherd doesn't track its children in inescapable (e.g., cgroup) ways is one of those ‘known bugs’. <ryanprior>If you don't know, esbuild is a bundler, transpiler, and minifier for JavaScript and TypeScript that has =just one dependency= (specifically, go/x-sys) <ryanprior>That means, if you have a JavaScript project that you can't package build with Guix right now because it depends on Babel, WebPack, and Uglify (which in turn have like 9000 transitive dependencies) you can bundle it with just esbuild. <ryanprior>I hope to use it to unblock our effort to package nodejs 12 (currently we're held up on 10, which is still supported so not panic yet, but yay) <ryanprior>However, that's currently task #3 on my Guix planning board, which means I probably won't have time to work on it until maybe March depending on my pace of work. <ryanprior>So if somebody else wants to run out ahead of me on that don't wait. I'd be super happy to pitch in and advise where I can. <jackhill>ryanprior: oh wow. I'm not sure I have more time or expertise, but that looks really good. <jackhill>do you know how esbuild relates to the recent swc work? <ryanprior>I don't think they're related projects, except in the sense that one of esbuild's motivations for emphasizing its speed is to give js build tool perf a kick in the heinie <vits-test>Hello Guixen. RE: my yesterday's (?): Yes, despite elogind-service enabled i need to be a member of the video group for sway to work. <clone11>I tried to install guix, but the installer usb hangs on this text forever. I can' <clone11>I can't type anything or go to a different tty. The installer works on my laptop so I know the usb isn't the problem. I have a ryzen cpu and amd video card. Does anyone have any ideas? Here's a picture of the screen it hangs on: https://0x0.st/i03c.jpg <jtmar>is there a list of real-world system configuration examples anywhere? <ryanprior>Not that I know of, that would be a real handy thing though! <xelxebar>jtmar: I assume you're looking for something more involved than the examples provided on the installation disk? <xelxebar>jtmar: I think those come from the configs under gnu/system/examples/ in the main repo. <xelxebar>clone11: Oh boy. The dreaded "Error: Success" <jtmar>I don't yet have the installation disk at all; I've been going off the manual. Anyway, I'll look at those. <jtmar>oh, those examples are just the examples from the manual <xelxebar>Oh really? Sorry, I didn't realize that. <xelxebar>clone11: I can't offer a guess at the root cause, but in your position I would try bumping the kernel's verbosity ***jtmar is now known as jamestmartin
<xelxebar>clone11: Just in case, this means editing the "linux ..." line of your grub menu entry. Hang on, I'll look for the exact parameter you'd need to add. <xelxebar>clone11: "loglevel=3" is probably sufficient. Also remove the "quiet" parameter if it's there. Beware that this can be pretty noisy... <xelxebar>Lower numbered loglevels produces less messages, so it might be worth trying loglevel=1 first and bumping up if you find nothing useful. ***sneek_ is now known as sneek
<clone11>Thanks, I'll try that and see what i find. <wleslie>if I want build-system-gnu to regenerate my configure scripts, can I get it to do that? <wleslie>otherwise my patches get a little hefty ***rekado_ is now known as rekado
***jess is now known as jess-o-lantern
<mfg>Hi, is there anything special i have to pay attention to, when i want to use i.e. (ice-9 match) inside a package definitions arguments list? i have seen that there is a #:modules keyword, so i just have to add the module to that? <efraim>ice-9 match just needs to be imported into the module where the package is defined. Unless you're using the trivial-build-system or mixing build systems you shouldn't need to worry about it <efraim>does linux-libre-arm64-generic take a long time to build? <mfg>efraim: Hm, when i add it to the top #:use-modules list then it seems to not work, i get unbound variable errors inside the match part of a clause, at least this error goes away, when i add it to the #:modules list of the package itself <str1ngs>efraim: yes mainly to deblobbing. if deblob sources are available its not to bad. also depends on the machine you are building on of course. <efraim>i've already deblobbed 5.8.13, building on a pine64 <efraim>I really need to get my firefly3399 back up and running <mfg>but then i get other errors (can't share atm, i'm at the wrong computer), so i just wanted to know how it should work and if i'm doing something simple wrong :D I will get back with the error messages later then :) <str1ngs>efraim: I mainly offload my SOC builds I have a rockpro64 and a pinephone I build for. <Brendan[m]2>been downloading from the substitute server at around 5KiB/s all day today <Brendan[m]2>breeze-assets-5.19.5 19.9MiB 5KiB/s 51:13 [############## ] 80.5% <Brendan[m]2>I also found out that my Sway freezing up is not due to running out of ram, but some other mysterious bug where sway locks up using100% cpu on one core. happens every few days ***amfl_ is now known as amfl
<jlicht>ryanprior: I just played around with getting a working llhttp build using esbuild; I got a build working, going from TS -> JS, and running the JS with our venerable version of Node to generate a parser in C. A tiny pebble on the road would be https://github.com/nodejs/llhttp/issues/52, but that seems doable. <jlicht>roptat: what are your short-term plans for guix-home-manager, with framagit closing? <wleslie>I have a question about cross compiling and how we do it in guix, but I'm probably way off base, so I'll give lots of context <wleslie>I'm porting a cross toolchain which works like so: it patches (adding support for the target) and compiles gcc; then it compiles newlib, then it compiles gcc again. both gcc compiles use --with-newlib. none of the cross compilers in guix do this, so I just want to make sure I haven't missed something about the way gcc is built. <wleslie>my first guess is that the first compile --with-newlib is somehow synonymous with "don't expect a supported C library for the target" <wleslie>but maybe it's just "also build newlib because some targets require it" <efraim>`git grep newlib' shows the string in gnu/packages/cross-base.scm and gnu/packages/embedded.scm <wleslie>yes, cross-base just passes the flag to gcc configure if there is no glibc available <wleslie>embedded has a newlib build for arm targets; but it doesn't do anything specific about the compiler used <wleslie>oh, yes it does, in `arm-none-eabi-toolchain` ***lle-bout_ is now known as lle-bout
<roptat>jlicht, I'll migrate to git.lepiller.eu <wleslie>maybe it's about libstdc++. we build the c compiler, then we compile newlib with that, then we compile gcc with support for c and c++ <efraim>Do guix containers have ipv6 support? <civodul>what d'you mean by "guix containers"? ***brown121407_ is now known as brown121407
<civodul>efraim: i think it has the same capabilities as the host <MSavoritias[m]2>I found a huge bug in the latest iso. If you install guix using the guided installation in the graphical installer you can't reconfigure the system because it says the boot is out of space. <MSavoritias[m]2>I tried to also format the drive with parted separately and then start the installation but it didn't work. ***stikonas_ is now known as stikonas
<pkill9>would it be a good idea to change the --with-graft command to automatically create a symlink in the store to the new input, with a name that matches the length of the old input, if the new input's name's length doesn't match the old input's name's length? <efraim>for anyone who was curious, 4 hours 20 minutes for the linux-libre-arm64-generic build on a pine64 using just 2 cores, and no CPU lockups <kabui>Hi guys I was trying to follow the guix docs on how to create a new profile before i run into this: ***seeg1231 is now known as seeg123
<sneek>I last saw erkin in #guile one month and 20 days ago, saying: At least I learnt how to use `macroexpand' today.. <erkin>I coulda sworn I talked in #guile just a few days ago, about FFI. <erkin>Ah hm, I reckon I need to introduce myself here. <erkin>My name is Lulu and I just got accepted to Outreachy. Guix felt like the perfect project for me to participate in because I'm a DevOps engineer by day and hobbyist Scheme hacker by night. :-P <erkin>I used Guix before a bit but not professionally. <erkin>I'm looking forward to working with you in the future. :-) <bandali>hi erkin, welcome and nice seeing you here :-) <roptat>what project would you like to work on? <erkin>The subcommand one seems nice, I think I'll try my hand at that one. <erkin>Guix comes bundled with its own Guile runtime, right? <rekado>erkin: no, but when using “guix pull” Guix will install a new version of itself and along with it a variant of Guile. <erkin>I can't do `# systemctl start guix-daemon' but I can run the daemon executable manually. <erkin>Oct 07 20:33:12 alpha systemd[3591]: guix-daemon.service: Failed to execute command: Permission denied <erkin>Oct 07 20:33:12 alpha systemd[3591]: guix-daemon.service: Failed at step EXEC spawning /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon: Permission denied <erkin>Do the guixbuild* users need file permissions for /var/guix/*? <erkin>(Context: I ran the binary installer script on Fedora 31 and rebooted before attempting to start the daemon from systemd) <erkin>Oh I bet it's SELinux's fault. <mfg>how does guix checkout git repos? one package tries to run git while building and it says no .git directory, so i guess guix's checkout isn't a "normal" git repo? <erkin>I'll just disable SELinux for the time being. <erkin>Is it recommended to use Guix as a non-root user? <dannym>mfg: It removes ".git" from the checkout since it contains non-reproducible files--see guix/build/git.scm bottom <mfg>dannym: okay, so for reproducibility reasons it would be necessary to ptach out the git commands used during the build, right? <GNUtoo>hi, I'm still trying to test my patch and I've now a different error: <GNUtoo>guix system: error: canonicalize-path: No such file or directory: "/usr/share/guile/site/2.2/gnu/installer/aux-files/logo.txt" <GNUtoo>I did that to get this error: # guix system disk-image --target=arm-linux-gnueabihf -e '((@ (gnu system install) os-with-u-boot) (@ (gnu system install) installation-os) "A20-OLinuXino-Lime2")' <GNUtoo>This is on x86_64 with Parabola and guix <GNUtoo>I did guix pull and guix package -u not so long ago (probably several hours ago) <GNUtoo>I'll try on i686 too where I remember how I installed guix (from the guix releases and not my distro) <roptat>are you sure it's picking up the correct version of guix? it's surprising that it's trying to use something from guile 2.2 <roptat>so that's not the guix that was installed by guix pull <GNUtoo>I probably lack some bash config for that <roptat>that should get rid of bash's cache <GNUtoo>/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/root/work/repos/bin/ <roptat>oh, make sure ~/.config/guix/current/bin is first in the PATH <GNUtoo>GUIX_PROFILE="/home/gnutoo/.guix-profile" <GNUtoo>export GUIX_PACKAGE_PATH=/home/gnutoo/.config/guix/local <GNUtoo>export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale <GNUtoo>export PATH="/home/gnutoo/.config/guix/current/bin:$PATH" <GNUtoo>but on that computer I probably lack all that <GNUtoo>guix is /root/.config/guix/current/bin/guix <GNUtoo>btw, is there a man for 'type' ? <GNUtoo>(it's the first time I see that command) <GNUtoo> Display information about command type. <roptat>With no options, indicate how each name would be interpreted if used as a command name. <GNUtoo>It worked fine on busybox but not with coreutils, probably because busybox has everything builtin *roptat remembers his first experience with linux <GNUtoo>I'm used to the command line but there are still some things I don't know <roptat>for some reason I installed ubuntu server <roptat>I tried "dir", it failed and my first successful command was "help" <roptat>that was a lot of info, but somehow not very helpful... <roptat>I had to use another computer to learn more about how to use the CLI, that was fun :) *GNUtoo wanted to learn the CLI even before managing to switch to GNU/Linux but there was nothing to learn for microsoft Windows <GNUtoo>so as soon as I managed to switch to GNU/Linux I learned the basics of it <roptat>I didn't intend to learn the CLI, but it happened anyway ^^' <GNUtoo>guix system: error: gnu/packages/freedesktop.scm:373:2: elogind@243.4: build system `meson' does not support cross builds <rekado>my father worked at IBM and they gave him a course on SUSE; that SUSE Enterprise and the associated IBM course printout were my first intro to GNU+Linux. I did not like it. <rekado>it seemed like a novelty to me; much like OS/2, which we would also install on our IBM machines whenever we got bored with Windows 3.11. <rekado>OS/2 included a Mahjong game. It was kinda boring. <rekado>erkin: the SELinux support has bitrotted <rekado>erkin: it is known that the policy is incomplete with recent versions of Fedora. <rekado>I originally tested this on Fedora … 23? <mfg>i began using GNU/Linux because i wanted to use my computer to do learn/make something and not play video games all the time :D so arch was installed and i forced myself to not use a GUI for about 3 months... <emacsen>mfg, if you wanted that, you could have used GNU/Hurd. No GUI. No network either. Really forces you to focus on the basics :) <roptat>ouch, I only used my tty-only system for... what? 3 days? <rekado>amazingly people now can do that! <rekado>boot up Guix System and start the childhurd service <roptat>that was the beginning of my distro-hopping ^^ <rekado>though, to be fair: the Hurd does have enough software support for GUI and network <emacsen>rekado, I last booted Hurd in 2000, so my knowledge is a little out of date <roptat>last time I tried it was missing a driver for network, and helpful people on IRC suggested me to use apt-get :D <rekado>emacsen: gotta check out the childhurd service! <civodul>i think X11 was working well on GNU/Hurd even in 2000 :-) <mfg>emacsen: at that time i didn't know about it. And i had more then enough to learn... it took me a couple of days to even understand how man/info pages work... <rekado>mfg: lots of people who claim to be proficient with GNU/Linux still don’t know how to use “info” <rekado>doesn’t help that some distros remove the info manuals completely <brettgilio>rekado: Because info is from GNU and "GNU IS BAD" (according to those distros) <emacsen>civodul, not on my laptop, but it's been a long time <civodul>emacsen: i actually got into it a bit later, ca. 2002, during its golden age ;-) <civodul>at the time the FSF would print stickers reading "GNU/Linux inside" and "GNU/Hurd inside" <civodul>and they'd just print the same amount of each <brettgilio>Just wanted to share an update on my new job. Got my work laptop in the mail, a nice T480. Got Debian installed on it, and installed Guix along side it, both working great. I got paid for four hours of refactoring my emacs config, and otherwise ive done nothing. lol <roptat>oh did the nlnet deadline get pushed back two months? I thought it was october 1st... <apteryx>coming to Guix, info was a revelation *roptat still doesn't know how to use info properly <rekado>roptat: you’re not using Emacs, right? <roptat>I keep opening the "all-in-one-page" manual in my web browser, or simply "vim doc/guix.texi" <rekado>I think all the info readers are pretty lacking with the exception of Emacs <rekado>roptat: you’re missing out on the index then! <rekado>it’s not the same to visit the rendered “Concept Index” web page. <rekado>much nicer to hit “i” and then type whatever comes to mind <mfg>yes, reading info pages in emacs is really nice! <rekado>maybe someone should improve info support in Yelp (not the website but the Gnome thing) <roptat>to be fair, I think the major issue is not info or the reader, but the content of the info pages that makes it hard to find what I'm looking for <civodul>roptat: you mean it's lacking information, or it's badly structured? <roptat>I think it's not the kind of info I'm looking for <rekado>“yelp /run/current-system/profile/share/info/guix.info.gz” really doesn’t render nicely :-/ <roptat>for instance, the guile manual is a reference manual, but when I'm looking for "reading an sexp from a file", how can I find out how to do it? <roptat>now, when I know it's actually "read", I can look it up very easily in the manual <rekado>I opened the Guile manual, then hit “i” and “read”; second hit gives me the definition. But yeah, you gotta know that it’s called “read”. <rekado>perhaps more index entries could be added <rekado>especially considering the very relevant name of the section: Reading Scheme Code <roptat>so the guile manual is very useful when reading the code of someone else, because you can find the definition of the whole guile API <roptat>yeah, that was just an example, but it happens all the time <roptat>for instance, I remember one day looking for something to compare the beginning of strings. because I did that in java before, I tried looking for startswith, starts-with and similar <roptat>but nothing, so I ended up using substring, and comparing the result... <roptat>until I discovered string-prefix? <civodul>you could do "g String <TAB>", that'd lead you to the "String Comparison" section <roptat>I've read the whole guix manual (and translated), so I know the concepts very well, but I'm wondering if the same thing happens to newcomers *vagrantc always found info pages to be far too complicated and basic things like "take me back to where i just was" were not easy to figure out <mfg>i know that problem roptat, that's why i often ask things which can just be answered with a keyword because i don't knwo what to search for :D <civodul>looking for "string-suffix?" in the manual of Python doesn't work either, but i guess they have a "String Comparison" section as well <civodul>in this particular case, it's not clear to me what could be done to improve the situation <roptat>yeah, but at least I'm sure if you try to search for "string-suffix python" on some search engine, you'll find many answers to that question already <roptat>guile is so hard to search for on the web... <civodul>it has a smaller user base, that's for sure <civodul>but it has a pretty good manual, and that's a "primary source" <civodul>i mean "good" is what we're debating :-) <civodul>what i mean is that the info is in there <roptat>it's good to understand how to use something, it's bad to find out what that thing is in the first place :) <civodul>yeah i understand what you're saying and i'd be curious to see how to make things more discoverable <roptat>maybe already trying to figure out what similar concepts are in other programming languages and adding these synonyms to the index <rekado>more wordy concept index entries? <rekado>the Guix manual has quite a few “bigger” index entries <roptat>maybe it could help to have "startswith" redirect to "string-prefix?" <civodul>i mean, "startswith" is not a concept, not even a word <civodul>"string comparison" though works for all programming languages <civodul>now, what could be useful is "Scheme for someone coming from Python" <ngz>Hello. Since Emacs 27.1 upgrade, I'm encountering encoding issues in some Gnus messages (French ones). I tried with and without (prefer-coding-system 'utf-8) in my setup, to no avail. Does that ring a bell? <roptat>I don't know, I just feel like the manual is not very helpful when I'm looking for something <civodul>ngz: works for me; what encoding issues, with outgoing messages? <roptat>maybe what I need is "programming by example", because I always know what the function should do, but I don't know what it's called <civodul>yeah, more examples can certainly help <civodul>it's also a problem in the Guix manual <ngz>civodul: with incoming messages, but not all of them, only from some mailing lists. For example, î appears as \356 <roptat>not more examples, but a system where I could say "this is the input, and this is the output, find the function that does that" <ngz>weird and *very* annoying <rekado>could it be that it’s not about Emacs 27.1 but about the value of your GUIX_LOCPATH? <ngz>GUIX_LOCPATH is /home/ngz/.guix-profile/lib/locale <ngz>There is a 2.31 directory inside. <ngz>In that case I think I would get all accented characters wrong, wouldn't I? <rekado>some accented characters are in the ANSI set, so I guess those would appear just fine. <ngz>In "corrupted" message, no accented character whatsoever appears correctly. ***sneek_ is now known as sneek
<mfg>ngz: i just had a similar thing, but the reason was that the text was sent latin-1 encoded and emacs expected it to be utf-8 <mfg>at least that's what i think the 1 in the lower left corner of emacs's modeline means :D <civodul>the coding-by-example bit is towards 1h30, but the whole thing is worth watching <ngz>mfg: That's possible, but I didn't encounter the issue before, reading the same mailing lists. I don't know how to revert that. <ngz>Funnier data point: the subject of the message is not corrupted, even though the whole body is… <ArneBab>roptat: I now mostly just search full-text in the info doc of Guile for "string-". That gives me most string-operations. <nckx>hello brettgilio I would like 1 job like that please thxxx <jackhill>erkin: I just read your email. Welcome to Guix! <brettgilio>nckx: its only cus im still in onboarding and its going slower than needed leaving me free time lol <nckx>It's the world's most boringest smile-o. <nojr>I'm reading the guix manual right now and noticed that it asks to set GUIX_PROFILE twice, once after installing emacs and another time almost a couple paragraphs downward after running guix pull <nojr>GUIX_PROFILE="$HOME/.guix-profile" <nojr> . "$GUIX_PROFILE/etc/profile" <nojr>GUIX_PROFILE="$HOME/.config/guix/current/etc/profile" <nojr> . "$GUIX_PROFILE/etc/profile" <nojr>I noticed in my .bashrc that I have $HOME/.guix-profile, which one should I use? <Brendan[m]2>You don't want that in your .bashrc at all, but in .bash_profile <Brendan[m]2>this requires logging out and back in again to change though, but is more correct 
