<farkr>just "guix install guile-chickadee" on my main user account, no elevated privileges
<nckx>/run/current-system/profile is your ‘system profile’, containing all the packages from your Guix System operating-system definition. Each user's profile (the one managed by ‘guix package’, ‘guix install’, etc.) is separate from that. You should find a chickadee hiding in your main user account's ~/.guix-profile/share.
<apteryx>in the container where it fails, it ends on: stat("/etc/ssl/certs/Global_Chambersign_Root_-_2008:220.127.116.11.18.104.22.168.125.35.206.pem", 0x7fff715f0550) = -1 ENOENT (No such file or directory)
<apteryx>oops, some files under /etc/ssl/certs are symlink to the store
<MysteriousSilver>Hi! I installed Emacs from Guix (emacs-native-comp), why does it not display fonts like mentioned in .Xresources? Installing emacs from a Non-Guix package manager displays fonts fine. TIA.
<apteryx>MysteriousSilver: hi! There's no emacs-native-comp in Guix proper, so you must be using a channel?
<slyfox>Should './pre-inst-env guix refresh -u re2c' attempt to update files in local directory? FOr some reason it tries hard to update system-wide file: [pid 3014757] openat(AT_FDCWD, "/usr/share/guile/site/3.0/gnu/packages/re2c.scm.qilB0R", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
<cbaines>slyfox, maybe check what ./pre-inst-env guix show re2c says for the location?
<cbaines>hmm, the guix repository should probably be first
<MysteriousSilver>Hi! Fonts looked weird in emacs, installed `font-dejavu`, now emacs looks fine but chromium looks ugly. I don't know much about fonts in GNU/Linux, so what should i do? Running Guix on a non-guix operating system.
<tissevert>I picked a later commit because there were changes on the vim files and that seemed to matter
<tissevert>I supposed the tag was about fundamental design decision made on the color theme itself and then later the developer realised the vim implementation didn't reflect them and pushed the changes there as well ?
<karthik[m]>leoprikler: i didn't get your instructions, what do you mean by bootstrap?
<tissevert>this is really very confusing and somehow I feel I'm not the only one tormenting herself when tagging releases of my software
<tissevert>no, exactly, the «vim-only» version doesn't have any release tag
<leoprikler>karthik[m] inside your local guix checkout, first ./bootstrap, then ./configure (don't forget about localstatedir) and then make
<tissevert>why wouldn't the prefix 'v' be correct ? is the version we use in Guix package a «guix thing» and not the will of the original developer ?
<nckx>I'm confused as well. So we had the vim-scripts repo, which is downstream from altercation/vim-colors-solarized, which is downstream from altercation/solarized, but all implicitly follow the same versioning scheme? Can we be reasonably sure of that?
<nckx>tissevert: ‘v’ isn't part of the version number, it just means ‘version’.
<tissevert>honestly I just wanted a readable syntax coloring, I stumbled upon solarized a couple years ago and had been happy with it up to know without asking myself too many questions about it (less again about packaging it)
<nckx>I don't know what bullshit solarized8 is talking about.
<tissevert>I don't either but I had thought it could be somehow adjacent to your original critical stance regarding the description I had copy-pasted
<vldn>mhh i thought a saw somewhere on github or gitlab a script to install guix system over a exisiting linux installation
<vldn>like moving all from "/etc" before installation to trash and something.. someone knows where i could find it?
<nckx>tissevert: Oh, I'm not critical of the project, my gustibusses just don't like the colours. Nothing more.
*tissevert notes the emacs-solarized package is base on yet another repos that claims to have ported it to emacs (even though the original repos now features an emacs theme)
<tissevert>what color scheme do you use ? honestly I'm curious about good recommendations
<nckx>(I'm just going to commit your last patch 😉)
<tissevert>now seriously, did I pick the worst package possible to start ? should I consider doing something else than attempting to package things for guix ? was the issue something entirely different ?
<tissevert>I didn't mean to wast so much of everyone's time for a mere theme that perfectly worked for me locally : /
<nckx>No. I think you chose a good package. I normally would have pushed it and simply sent a mail with ‘I changed this & this & this, pushed, thanks!’ (as the one you've just received), but the confusing upstream situation & my lack of Vim background slowed things down a lot.
<tissevert>ok, that's understandable, I see that emacs is really a central tool in the making of Guix
<tissevert>and I haven't been very fast to answer your original mail, sorry about that
<nckx>There are Guixers that use Vim. I don't use any of Emacs' power features or extra packages. You should be able to happily contribute to Guix from Vim.
<OriansJ>nckx: sure here is the report (without a fix because I haven't had time to generate yet) meld when given 2 files to compare exits with "Couldn’t find colour scheme details for meld:insert-background; this is a bad install"
<nckx>OriansJ: Obviously not as common as you think, nor does every package need to be fuzz tested. It presumably worked when added (I didn't dig), in the way the packager used it. That's enough. The rest is bug reports.
<nckx>leoprikler: Is it possible that the bug is actually in your (plural) environments?
<nckx>Otherwise I don't see why my build of the same Meld hash would be magically immune.
<vldn>*-bash-minimal-5.0.16/bin/sh: cc: command not found :(
<vldn>what do i need to add to my package definition
<nckx>This doesn't feel like an effective use of my time. Guessing what could go wrong in an environment with which I'm very unfamiliar.
<nckx>vldn: Probably ,(string-append "CC=" (cc-for-target)) *somewhere*, for example (and in order) #:configure-flags, #:make-flags, or even setenv in a phase before 'configure, depending on your package's build system.
<nckx>For native builds, that code is equivalent to simply setting CC=gcc.
<nckx>Some broken packages don't honour $CC and need patching, but they are not common.
<apteryx>any idea how to get the version of guile from './pre-inst-env guile --version' reconciled with the version I get in 'guix environment guix'? I tried deleting autom4te.cache directory and autoreconf + configure'ing, but nope.
<pineapples>nckx: Pardon the ignorance, but what does "shell out" mean in that context? And, as for that protocol, yeah.. I guess that will require a Sway service or something in the worst world scenario, no?
<pineapples>..unless I'm oblivious to the packaging problem that it might pose for us in the future, which is very likely haha..
<pineapples>Err, I mean, I may not simply get the gist of the issue here
<pineapples>But, if I understand correctly, this is merely a problem of populating `/etc` with Sway-specific configuration files that specify Wayland clients' priveliges, and having Sway read them, yes? If so, perhaps this is a problem for `guix home' to solve?
<leoprikler>pineapples "shell out" means calling a shell program rather than doing stuff in your own language
<pineapples>With automation that GNU Guix provides, there has been only few things I couldn't at least work around in my config.scm. I doubt that you, as in everyone who makes up the collective driving force behind GNU Guix, wouldn't be able to come up with something tolerable and/or workable, either :)
<admas>Do any of you post your system config on a public repo? I'm wondering if there are any security issues with doing this.
<admas>I'm also curious if anyone has figured out how to use mcron to have Anacron like behavior of starting a cron job as soon as possible on startup if machine was off during scheduled run.
<leoprikler>Well, you might expose your initial-passwords, so that's that
<OriansJ>admas: if you can find security issues with my config, I would be happy to see suggestions for improvement.
<OriansJ>but as long as one doesn't include credentials in their published config, there isn't much to go on besides what is installed.
<admas>pineapples, thanks for sharing your experience with mcron. I see this may end up being another project to get that working the way I want
<OriansJ>if one is really paranoid, add whitelisting to your kernel and then no zero-day could even run (unless run in one of the interpreted languages on your system)
<pineapples>admas: I implore you to, if you can. This has been a major headache to me, and it forced me to configure unattended-upgrade-service to run daily to not miss any updates since I often turn off or suspend my system
<admas>OriansJ, I love the comments on the packages btw. I may be being overly paranoid because I'm falling into the security through obscurity argument.
<OriansJ>admas: checkout #bootstrappable if you want the extra paranoid defences (solving the Trusting Trust attack) where everything is built from source (starting from a 357byte binary written in hex)
<admas>OriansJ, thanks for the suggestions. Though I am feeling overwhelmed by what I need to consider to be secure.
<OriansJ>admas: security without understanding of what you are trying to protect yourself against isn't meaningful.
<OriansJ>So the most important first question in regards to security is what do you want to defend yourself against?
<admas>That's a good point. As it is now, my main source of worry is identity theft and hacking financial accounts
<OriansJ>install keepassxc and use unique accounts for everything and long randomly generated passwords for all online services you use. Yubikey and/or mooltipass and/or hardware cryptowallet for credentials you want kept safe even from an infected computer.
<admas>That's good news since I am currently using keypassxc to generate unique passwords. I haven't looked extensively into yubikey so I'll check that out.
<pineapples>admas: Anyway, it goes without saying that I'm *very* interested in bringing anachronistical behaviour to mcron, and I'll gladly collaborate on it. Feel free to tag or PM me in regard to this :)
<OriansJ>as for identity theft, well unfortunately most identities can be bought online for $3.18 due to breaches that have occurred in the various government agencies that might have a copy of that data.
<OriansJ>and the credit companies that provide credit freeze services, tend to be vulnerable to a great deal (they have ALL been breached) and the freezes seem to be easy for a malicious third party to undo.
<OriansJ>but that might just be me being jaded by my job.
<cbaines>Yeah, although I'll try to install Guix as a system at some point soon
<cbaines>currently I've got it building substitutes for bayfront.guix.gnu.org
<cbaines>it has just started properly building things today though, so it hasn't got very far yet
<marusich>I'm not sure how much work it will take to make it boot as a system. I haven't tried it. At the very least, I guess linux-libre has to work, and then using the --no-bootloader option, you might be able to manually update the GRUB configuration on the system to kexec the built kernel
<marusich>sorry, I meant, update the petitboot configuration to load the grub configuration
<marusich>I'm doing alright. 2020 and 2021 have been rough to say the least
<marusich>I have been trying to contribute to Guix in my spare time but have found very little
<marusich>it's frustrating; i'm envious that you have a grant to work on it ;)
<cbaines>haha, don't be too envious, that grant stuff isn't really working, at least not yet
<marusich>but things could be much worse, I suppose. the weather is getting better, which is always nice
<cbaines>I'm still trying to salvage some benefit from the Guix Build Coordinator stuff I've been working on for the last year+
<cbaines>I don't have the headspace yet to try and switch to a whole new stream of work
<marusich>I also really want to try to shoehorn Guix more into my work, but every time I think about doing it, it seems like there are a bunch of obstacles that would take more time than I can allocate to fix
<marusich>I find it difficult to easily integrate Guix into workflows that assume the environment is very different, but I guess that's to be expected. It's also very hard to integrate Guix into development workflows that rely on tools that are not packaged in Guix and assume they are running on a traditional distro
<marusich>Maybe I just have bad luck. I once tried to learn Rust by going to an embedded rust workshop with friends, and although they installed things and were ready to go in an hour, I spent the next month trying to figure out how to get the toolchain working on guix system, and failed
<marusich>it's hard to shift everything at once, though
<marusich>another thing i wonder about is how people integrate their development workflow/environment with guix
<marusich>I have been doing a lot of Java development, and in that world you rely on the IDE and on Maven quite a bit to get the dependencies. The IDE can "see" the dependencies you get via Maven etc, so it's easy to look up javadocs, jump to the source, etc. Simple but very convenient.
<marusich>I find myself wondering if (how?) people develop "serious" projects, other than Guix of course, from within Guix system.
<marusich>We have thousands of projects packaged, of course. So complex projects like Inkscape or Krita can be built, for sure.
<marusich>But what about a Krita dev, for example? Would they feel comfortable using Guix System to do development?
<marusich>Maybe it's not as bad for C or C++ projects, but for Java I have the nagging suspicion that right now, the answer is probably still "it isn't feasible"
<marusich>the moment Maven tries to download some java code that includes native stuff, you're gonna have a bad time
<marusich>mstrom[m], that is another option, true.
<marusich>mstrom[m], i haven't seriously explored that, but wouldn't it basically be the same as running on a foreign distro? in the sense that maven etc. would be relying on the container looking like a debian system or whatever.
<marusich>in the case of java, i suspect there might be a way to add a "plugin" or equivalent for your favorite IDE that understands how to "get dependencies" from guix
<marusich>since that's basically what is done for maven, and that's what I've seen at companies that have their own packaging systems built
<cbaines>I guess the reality of the situation is that rational people are only going to put effort in to adopting Guix if there's more benefit than the effort required
<mstrom[m]>I haven't explored Docker in Guix, but I used VSCode for a while and they have this feature called "Dev Containers" where basically if you have a docker_compose.yml in a repo for builds and tests, VSCode will spin up a docker and enter that environment so you can use e.g. the npm modules of that actual project, instead of your system-wide npm packages. Of course you lose everything you have system-wide, including your own
<mstrom[m]>VSCode addons, which you have to specify in a file too for them to be rebuilt inside the container, but it works with fairly few snags
<efraim>I guess anything with graphical output. I'm pretty confident about the powerpc64le bits of mesa but I wasn't able to test actual grahical outputs
<marusich>cbaines, that is the prevailing opinion I have seen among "corporate" devs
<efraim>even something like glxgears would be great
<mstrom[m]>you could do something similar with emacs and TRAMP
<marusich>of course 'popularity' isn't that important for this project, but i do think guix could be so much more awesome if it were easier to use for hacking on projects in practice
<cbaines>marusich, I don't think that attitute/opinion is a problem though, it just means that highlighting the benefits, and the path to adoption is the way to go
<cbaines>plus actually making things possible of course
<marusich>it's just an indicator of something we could focus on to try to improve the user experience
<marusich>mstrom[m], interesting. If the goal is to be able to use an IDE in Guix System and conveniently develop stuff, that might be one way to do it. (Assuming "Code - OSS", the FOSS version of VS Code, work on Guix System to begin with)
<marusich>The idea of having an IDE delegate the dependency stuff to Docker containers doesn't have much to do with Guix per se, though.
<marusich>Perhaps that's an easier path than making custom plugins for various IDEs?
<marusich>I would still personally be greedily interested in a plugin / feature for any given IDE that provides direct support for connecting it to Guix's dependencies, rather than taking the shortcut of using an opaque Docker container. But I can see why that is potentially a good interim solution...
<marusich>It doesn't help that the IDE I'm currently using is not packaged in Guix :(
<marusich>It's NetBeans, which apparently is free software but for some reason isn't listed on the free software directory... Figuring out how what problems there are and maybe fixing those is another thing on my list of things to do, someday...
<mstrom[m]>I don't have a clear picture of whether adapting the IDE would solve everything for e.g. your Java development
<marusich>Is Eclipse packaged? I see a ton of eclipse packages
<marusich>mstrom[m], yeah, I'm sure there are other rough edges. I just picked up NetBeans because where I started working recently has been using it for their IDE. It seems to have a *lot* of features, not all of which might mesh well with Guix.
<marusich>NetBeans sort of feels like a kitchen sink of development. They have a feature for almost everything you'd want to do in the development lifecycle.
<marusich>Building installers, deploying to remote servers, refactoring code, handling various build systems, their own implementation of a build system in ant...
<marusich>they even have their own module system in netbeans platform and an entire ecosystem built around it...an automatic update center...tons of things.
<cbaines>mstrom[m], I admire you're sentiment, but it's been feeling like I've been making less and less progress recently
<marusich>I thnk the reviewers wanted to make sure that the build output is reproducible.
<mstrom[m]>cbaines: in that case, just enjoy yourself, maybe
<marusich>ubuntuxp, I would recommend trying your patch like "./pre-inst-env guix build --rounds=2 slade", thus verifying that the output is reproducible. If it is, then I'm not sure what blocking issue would remain. Maybe the reviewers also thought that reset-slade.pk3-timestamps was unnecessary, so you could try removing it?
<slyfox>i still find guix's process of making occasinal package tinkering a lot more cumbersome than say, gentoo's. especially when i need something like trying out gcc-11 real quick on that special package
<vagrantc>cbaines: good to hear the ppc64el package of guix works on debian ... i did build-testing on ppc64el, but didn't actually have the ability to install test
<cbaines>vagrantc, well, I can confirm that I haven't encountered any issues with installing it :)
<cbaines>I did run out of build users, but I managed to add some more
<marusich>slyfox, i was wondering about this recently, actually. Is it possible to build stuff using gcc-11 using --with-input or some other package transformation?
<slyfox>--with-latest=gcc should work, but gcc-11 itself did not build for me
<vagrantc>ok, just making sure i'm setting reasonable defaults
<marusich>slyfox, --keep-failed is the only way, really, and if you want to "stop" execution at a specific phase, the only way is to modify the package. I feel like an option such as --stop-before-phase would be a neat addition.
<marusich>or maybe like, if guix could spit out the guile code to run each phase, and then let you run it by invoking a script in the build environment, so you can run each phase one at a time interactively...that would be neat
<slyfox>Running 'make' should be good enough for my small needs
<marusich>slyfox, you can actually do the phases one at a time, if you fire up a repl in the build environment
<marusich>it's a bit cumbersome though, because you have to know what module contains the package, and then you have to fire up the repl, and you have to enter the right scheme code to execute it, so if you're not already familar with a lot of that stuff it's kind of a big wall to scale, even if it's simple in theory
<slyfox>oh, nice. does guix doc (or something similar) have a hit how to do it?
<marusich>basically you just use --keep-failed, so you get a build environment. or maybe you can start from the source code unpacked somewhere...
<slyfox>my scheme knowledge is very limited and guix's use of syntax macros makes my head spin every time i try to reason about it's evaluation :)
<marusich>then you would start a repl, probably by first cding into the directory, running '. environment-variables' to set up the environment (not pure, since you want to use guix also), then run "guix repl" to get a repl where you can do stuff with the package definitions
*vagrantc is still cargo-culting guile after maybe a year or two of submitting commits
<marusich>once in the repl, you can manually enter scheme forms. if the phases are simple, you might be able to just manually enter some of them.
<marusich>if it's more complex...I'm not sure. I might have only used this trick to do simple things like "find and replace stuff" using the substitute* form.
<marusich>I don't think there is an easy "run this phase" procedure though
<vagrantc>hah, or three years ... my fist patch contribution was april 2018 ... wow
<vagrantc>wow, and [bug#31447] [PATCH] linux-libre: Add aarch64-linux. was also from may of 2018 :)
<slyfox>yeah, running phases would be useful. gentoo has 'ebuild $pkg [unpack | prepare | compile | install | merge]' (and i use it all the time)
<vagrantc>i guess this is kind of my guix anniversary :)
<mstrom[m]>vagrantc: i wonder what is a fist patch, perhaps you want it as an anniversary present
<marusich>right...honestly if I really really need to debug phases, I would probably use a git checkout right now, and manually make the phase where I want it to stop error out, and then inspect the result with --keep-failed.
<vagrantc>i can't seem to find when people were crazy, er, kind enough to give me commit rights
<marusich>i wonder what it would take to have a "guix enter-build-environment" kind of command, which would drop you into a shell where you could somehow walk through the phases and inspect the results as you go.
<marusich>Since the build happens in an isolated environment, I'm not sure how you would get input/output to there.
<vagrantc>oh, looks like my commit access was late april 2019 ... so may/april really is a guix anniversary for me :)
<mstrom[m]>marusich: it'd be like guix build --keep-failed but pauses at each step and waits for Y/N to proceed, so you can look at the build tree on a separate terminal/editor/file browser ? good enough?
<jackhill>marusich: I also think that would be cool. Perhaps it doesn't have to be the real build environment, but something that lets folks run the code from the build side in their regular environment with fewer isolations.
<jackhill>e.g. I often want to be able to run patch-source-shebangs and other prep steps outside of the deamon
<marusich>If i were gonna try implementing something, I might try to make the builder script dump the phases as scripts you could invoke in order, sort of like how it currently dumps the environment into environment-variables so you can source it after running --keep-failed.
<marusich>that would avoid the issue of having to make it interactive even though the build environment is isolated.
<jackhill>marusich: that would be enought to at least make me happy :)
<marusich>BTW does anyone know where exactly the official autotools documentation explains what changes, if any, ever require blasting away the entire repository and starting fresh?
<marusich>When I've arleady run "make," I am always suspicious of running "make" after a "git checkout" without cleaning things first. But it's sooo slow if I do that.
<marusich>When only the scm files have changed, I usually feel confident that nothing weird will happen, but when for example Makefile.am changes, I am more suspicious.
<marusich>jackhill, yeah it's hard to predict what people neeed when debugging build failures, but being able to run the phases like that would sometimes be useful, I think...
<vagrantc>what i get really frustrated by is the difference between guix environment and guix-daemon's build environment
<marusich>yeah, which is why it would be super nice to have a "guix real-build-environment" command :)
<vagrantc>sometimes things build fine in guix environment by fail from guix-daemon
<marusich>but again i'm not sure how to set up the communication required to do so...
<vagrantc>guix-daemon by design tries to keep you from being able to interact with the environment
<marusich>BTW I noticed that GCC 8.something was released very recently, and they said it was the last of the 8.x series. Apparently 8 and below will no longer be maintained. What does that mean for security etc. in Guix, since it is still using 7.5.0 on master?
<marusich>On core-updates, I was hoping to upgrade at least to 8.something to fix powerpc64le-linux, which was broken on core-updates due to the upgrade from glibc 2.31 to 2.32.
<vagrantc>civodul just proposed to update to gcc 10 on the recent "what next" mail
<marusich>i am amazed that we were able to bootstrap powerpc64le-linux using gcc 5
<marusich>i guess in the future the bootstrap path will need to take a different route, via a later gcc version in the beginning, for future architectures
<vagrantc>it may be possible to backport patches in some cases
<vagrantc>pretty sure the folks in #bootstrappable are exploring that option for newish architectures
<vagrantc>as newer gcc depends on a much larger bootstrap chain
<colemickens>Can we discuss guix system on rpi4 here, or is that discouraged due to the non-free bootloader that is basically required?
<vagrantc>if you don't get into the non-free bits ... :)
<colemickens>Beautiful, it looks like "an opinionated distribution of u-boot" can encapsulate those nasty bits and leave me the ability to just present a UEFI system on my NVME drive. Leaving me to just focus on learning the clean guix bits. Very excited to dive in.