<daviid>not using org-mode because a government (I don't beleive I'm even reading this here) don't recommend it? amazing
<adfeno>davidl: Actually, to be more clear, it's not a requirement for Brazilians.
<adfeno>It's personal preference, so that I can use the government documentation/norms/recommendations as reference to other people in Brazil, so as to make these think on switching to standardized formats
<adfeno>Rather than continuing saving in .DOC, .DOCX, .PPT, and so on.
<OriansJ>daviid: Governments by default recommend against things they don't understand. Don't worry about that if you do things correctly, you can use things like pandoc to generate the formats they might expect.
<OriansJ>Governments with deep understanding tend to recommend text standards with embeddable SVG graphics because the purpose of written documentation is to share understanding and allow future revisions to be done effectively across organizations.
<adfeno>My Bachelor's degree final work was done mostly in org-mode, but I found it difficult to make either the org-mode itself or ...
<adfeno>... or the LaTeX result (with all the packages and stuff) be processed by pandoc to make a perfect .ODT file that my mentor could edit.
<adfeno>Even a package whose name was like "ht" and "latex" something (which I read that uses all of LaTeX's internals) didn't produce a good .ODT.
<OriansJ>adfeno: Your mentor couldn't figure out how to deal with editing text in a text editor?
<OriansJ>Basically anyone to cut them a check for $120K will get a sheet of paper that they have a Phd in any subject of their choice, no questions asked. Atleast at South Harmon, they require you to actually demonstrate something.
<adfeno>I'm not a computer science expert, but for me binary means series of 0 and 1 that are difficult to make sense of.
<adfeno>Just like minified or obfuscated source code.
<OriansJ>adfeno: if you would like I can explain exactly the mapping between the binary encoding and the human encoding of everything.
<OriansJ>Hint, it isn't impressive (Think man ascii gets you 90% there)
<nckx>calher: Probably most people here, many of them now asleep. Me. Workflow?
<wxie>nckx: hi, do you know to how to make dual boot for guix with another GNU?
<apteryx>calher: what kind of workflow are we talking about? I use GuixSD daily, both for home and work.
<nckx>wxie: No experience. I'd install a GRUB separate from both, write a configuration file with menu items that load each distro using configfile, and make sure neither Guix nor the other distro overwrite it.
<nckx>One can also add custom menu items to Guix's GRUB menu but I don't know how well that works in practice.
<nckx>In any case, it's a completely manual process.
<Levy[m]>calher: initially use `guix environment` for projects until there's enough to write a manifest. Eventually the manifest turns into a package definition when others need to be involved / release is due. But I guess most work along the same way so there's not much more I can say. Guix does manage all of my editor plugins for neovim (have some I should complete so they can be included in proper) and such.
<calher>apteryx I intentionally use total noob bloat.
<Levy[m]>ah, GNOME/bspwm (switch back and forth as can't decide) + nvim + emacs + surf + dev tools + weechat, I did base it of the minimal but eventually just started using %desktop-services with a few things removed/changed
<calher>I try to use a desktop that people might see me use on a projector and think, "I want to use that" and not "Wow, he's so smart. He's a computer whiz and has so many terminals open."
<phenoble>Anyone familiar with the guix sources here that could help me point in the right direction? I am trying to fix something that looks like a bug in guix, that prevents me from being able to use guix productively.
<decent-username>thanks for the link. This appears like a better version of the manual. :p
<phenoble>indeed, I am getting the same impression
<decent-username>Would someone maybe be so kind and consider sparing some of his precious time to eventually have the kindness to explain to me what 'configure: error: freeimage not found.' means, if that's not to much to ask?
<ngz>You are missing freeimage input in your package definition
<raghavgururajan>Okay, I am kind of getting somewhere. So there are actually two types of packages. Source Code Packages (.tar.gz) and Binary Packages (like .deb .apk etc.). Building binary packages from source packages using package definitions/recipes are called "packaging". Substitutes are pre-built binary packages. Is this right??
<pkill9>Sleep_Walker: use `guix environment --container` (possibly with --pure, not usr eif that's needed) and then instantiate the environment variables of the build which is in a file at the root of the failed build directory
<janneke>pkill9: that comes very close, but it will still give you /bin/sh
<phenoble>So I modified the guix sources (to solve a problem I have using guix with proot), built guix from source, created a binary tarball using 'make guix-binary.x86_64-linux.tar.xz' .
<phenoble>The change I made to the sources does not seem to be integrated in that. On the off-chance that anyone can help and would be so kind do do so, question: is the assumption that the tarball would have source changes included in them, wrong?
<OriansJ>phenoble: well source changes only take effect if the build explicitly would use the changed code (Either via commit id, version etc). Otherwise the changes were treated as damage, purged and the build occurred exactly as expected.
<phenoble>OriansJ: I was suspecting that such a mechanism would be in place, but couldn't find it so far in the Makefile or documentation. Thank you for that information!
<over7head>can guix be installed without iso form existing distributions
<phenoble>OriansJ: how would I pass in, e.g., a commit-id?
<over7head>probablz there is tar.xz szstem but im watching documentation and it is some new init to me and principles, i will not be able to do it without some documentation
<phenoble>OriansJ: I already branched off upstream master, and created a commit with my change. Would that be enough? (Asking, because a build + try-out takes ~20 minutes)
<over7head>mazbe installing guix package szstem on top of distro and keep building on separated partition but i dont have idea how to do it_
<OriansJ>phenoble: If you look at the definition of the build, it will make more sense
<Levy[m]>over7head: Check the mailing list for how. A few have tried and from what I've seen, has worked out quite well
<OriansJ>There is a hard line between current state and build targets. A build target will always be bit for bit identical if the builds are determistic; regardless of the changes to the guix doing the work
<phenoble>OriansJ: Ok, so a 'make' invocation builds a guix binary, which is then used to build the guix package (guix.scm), getting all its state from the upstream repositories, including the guix binaries themselves.
<OriansJ>phenoble: well it shouldn't get binaries, unless you enabled substitutes
<phenoble>Oriansj: So I suppose I would have to write my own guix_custom.scm, where... the guix binaries are not downloaded (/build from) upstream (sources), but the locally built-binaries are used instead.
<phenoble>This works on a local VM, so the process must be correct (sometimes), but fails on my local system - and on the target systems themselves.
<phenoble>The problem is that scripts/perform-download.scm , when trying to get guix-daemon to actually do anything using the guix binary, is eventually being called as root - which it shall not be, for there are checks in scripts/perform-download.scm.
<OriansJ>phenoble: lack of root is a serious problem for running guix but you can approximate it by having guix make relocatable tars which you can put in your ~/bin
<OriansJ>The calls to root should only for creating the chroots to perform the build/installs
<phenoble>OriansJ: Yes, I've read about that workflow. But that would mean that I'd have to prepare everything that I intend to install on one of those systems, beforehand, would it not?
<phenoble>So the fact that this is called as root is not the problem but a side-effect of some bigger-problem?
<OriansJ>phenoble: I am going to be honest; in some hardened environments; running guix isn't actually an option but one can still leverage guix packages with planning and still get the roll-back capabilities via cheating (say git repo your binaries)
<phenoble>OriansJ: What I am actually looking for is indeed distribution-independent, hassle-free, reproducible, management of binaries. I don't like Ansible, but do like Scheme - so guix it was, or so I had assumed.
<phenoble>OriansJ: But populating a git-repo with a single version of binaries, and then using those on different systems (...a flatpack kind-of-approach...?), actually is an option then, too.
<OriansJ>phenoble: that it? why the no root restriction then?
<phenoble>Oh, because I am pretty sure that asking for root access on all systems I use professionally will raise some eyebrows, and be denied ^^.
<phenoble>OriansJ,jlicht: In any case - thank you very much for the input. I will see to it that, if I can't get root access to all systems I work with professionally, I might at least get guix installed properly on them.
<phenoble>OriansJ: one last thing re my proot issue before - I created a bug-report on the guix-bug mailinglist that, that's what it sounded like, we could close with your help? You mentioned that proot does not work on "hardened systems", which you left undefined, but does sound plausible to me as an explanation for what is going on there.
<phenoble>I don't know enough about proot and the involved mechanisms.
<phenoble>Is it certain, that pjotrs process, will not work everywhere?
<phenoble>I am in contact with him over the issue as well - maybe his guide needs to be updated with this information about "hardened systems"?
<OriansJ>phenoble: either that or someone just needs to take a little time adding a conditional flag light-mode to the pieces of guix that require elevated priviledges; such that the guix bootstrap could also create a light edition which doesn't require elevated priviledges to run but insteads runs out of ~/bin and puts the files it downloads into ~/.cache/guix/store
<tune>ugh. I might give in and let it open in claws mail. I really do not like claws mail and I can barely use it
<atw>darn. Well, regarding the issue you and I seem to share, I think we do have the same issue, and I understand why our stacktraces are different. What I don't understand is what differentiates cwm from spectrwm and awesome. At this point I'm looking for ideas about how to proceed with debugging
<tune>for now I've just rolled back until the crashing stopped and then I've been doing all my updates with a --do-not-upgrade argument for icecat and guix. nothing else seems to crash so this has been working
<tune>(not that this is any sort of solution in the long-run)
<atw>tune: I also rolled back to a good user-profile generation. Did you mean icecat and emacs?