<adfeno>About Linux-libre goal: What was inteded was to only remove the non-free parts. However, due to a **bug** (perhaps in Linux itself?), the user is not allowed to force installation of non-free parts manually.
<adfeno>I'm using Trisquel (based on Ubuntu), and do like it, and recommend it to new-commers. But I'm looking into installing GuixSD along with Trisquel.
<ZombieChicken>kyamashita: I got into Linux because I was annoyed how I couldn't do anything with my old Window XP install. After using SuSe for awhile, I got comfortable enough to mess with some of the more delicate things
<kyamashita>ZombieChicken: I got into it after I looked up "how to be a hacker". I already hit walls on Windows XP when trying to tweak it for performance. I left for technical advantages and stayed for the freedom.
<adfeno>Historically and still today, most projects that have "Linux" in their names are actually "GNU with Linux" (when spoken) or "GNU+Linux".
<ZombieChicken>Pretty sure there is at least one distro that uses the NetBSD userland
<adfeno>ZombieChicken: My emphasis on "most" word.
<Common_Era>Alright, I've set Refind to use Debian's grubx64.efi as the loader, but I'm getting "error: unknown filesystem" because it's not set to find GuixSD's bzImage... I can't think of a way to set it to both.
<kyamashita>Common_Era: I wish I had the EFI experience to help more. :-/
<Common_Era>Does anyone know if there's a way to altogether skip Refind?
<adfeno>... It's tricky, there's indeed some level of risk. But in the other case (if they decide to use CentOS, RHEL, or Ubuntu) and rely on support for these instead, they are **also** subject to that risk.
<adfeno>Besides, with CentOS, RHEL, and Ubuntu, they are all non-(free/libre). so the loss is in double.
<adfeno>Because **the organization** (in which you work) won't have control over its own computing.
<jamesrichardson>We've already run into several issues that were difficult to solve because we run slightly outside of the vendor's use cases.
<jamesrichardson>That was actually one of the driving forces to even consider leaving AIX for GNU/Linux.
<ZombieChicken>in (packages ...) in config.scm, how do I add additional packages? It seems like a waste to just make a huge list of cons for that
<jamesrichardson>I just add to the list... (packages (cons* ratpoison stumpwm nss-certs %base-packages))
<adfeno>jamesrichardson: If you manage to migrate to a database which doesn't depend on non-(free/libre) software, then there are various free/libre to manage the databases which are already packaged to Guix.
<ZombieChicken>Only problem I have with Lisp software is they tend towards massive, monolithic programs
<jamesrichardson>elisp actually got me into Lisp. I went to Clojure mainly so I can express solutions to problems and host them on operating systems where I'm unable to compile lisp (either clisp or sbcl or guile)
<ZombieChicken>jamesrichardson: I'm ~90% sure SBCL can compile a stand-alone bin
<kyamashita>But I hear that those binaries can be very large.
<brendyn>jamesrichardson: I think part of the reason non-ext4 filesystems & lvm aren't supported well yet is because they require services to be made, or something like that, since we aren't using systemd
<brendyn>ZombieChicken: I just got started packaging software for it recently and I'm thiking of ways to make it better.
<jamesrichardson>The biggest issue I have is that it is becoming a monolithic thing that wants to take over everything (seemingly) between Linux and GNU. I also seem to have no choice in the matter. I've been using runit as my init for several years.
<ZombieChicken>I don't think systemd's maintainers care about GNU. I seem to recall they were looking to replace everything
<brendyn>Well I hope Guix isn't too monolithic. All Guix stuff is in the same git repo but it technically doesn't need to be that way.
<brendyn>Well GNU herd currently does half of a thing, so maybe that is a good compromise \\o/
<jamesrichardson>The choice should be left to the admin/owner of the box/application not imposed by the system.
<ZombieChicken>They claim that it's all just housed in one repo and is actually several seperate utilities, but I'm betting (I won't touch the project with a ten foot pool myself) that none of it will work without the rest
<freedom0>alienpoop: dwm is much smaller faster and simpler. it suck less xD
<alienpoop>freedom0: Yeah, been using it for the last four years or so. Pretty heavily patched now.
<brendyn>Ok so what do you think about adding donation support to Guix packages? Instead of just having (home-page ..."), we could add (donate ...), then people can build GUI package managers that implement mechanisms for donation
<adfeno>I'm making a package recipe for Python Foolscap. It depends on Python Twisted TLS (for which I'm also making a recipe for, based on the existing Python Twisted recipe). Foolscap depends on Twisted TLS just to get the extra dependencies, and it's failing at test phase.
<adfeno>Foolscap's test phase says that it doesnt have a dependency that was provided by Twisted TLS.
<quigonjinn>dvc: in my case, I have come across SaaSS compilation so...
<adfeno>So, I don't know if I should, and where I should, use the propagated-inputs.
<ZombieChicken>brendyn: I'm trying to find where that was discussed for LFS, but mainly those test are for upstream to make sure they didn't screw something up at some point. In fact some packages always fail some test, but upstream still considers them okay since they are supposed to fail. I've run into this kind of thing with Gentoo, and they really don't do the end user any real good
<paroneayea>brendyn: yeah, people are scared of guile-emacs, for reasons I just can't understand
<ZombieChicken>I'm also wanting to know how to disable them since a test is currently failing for gnutls-3.4.7, which means it won't finish updating
<paroneayea>most of them are afraid that it means our elisp history will be thrown out and replaced with scheme
<ZombieChicken>brendyn: I just installed this VM yesterday, and I don't recall seeing docs on how to patch build scripts
<brendyn>Well it depends on the particular program and how it runs tests
<ZombieChicken>brendyn: point me to the docs on how to patch the build script and I'll figure that much out myself
<davexunit>brendyn: I need to figure out how to activate xwidgets
<davexunit>I added cairo and webkitgtk to the inputs but that wasn't good enough to make xwidgets or cairo support work
<brendyn>ZombieChicken: I don't know if there is any documentation on that. Disabling all tests is as simply as adding #:tests? #f to arguments, but disabling particular tests depends on the build system
<davexunit>ah, need to explicitly enable them with configure flags
<adfeno>Is there a definition to tell the Guix builder to "run this script that's inside the source tree, before going to "build" phase of the package".
<davexunit>I don't understand why it would have to be done for every package. presumably there's a specific package you are trying to build that needs those flags in order to build correctly.
<ZombieChicken>it's less of a case of needing them for something to build correctly (actually, when I asked how to patch build scripts before, no one was able to tell me, so that doesn't help anyways), but being able to build packages for one's individual system.
<davexunit>what does "build packages for one's individual system" mean here?
<adfeno>ZombieChicken: Also, to patch something, perhaps there are examples on this.
<davexunit>package builds are intended to be deterministic
<davexunit>not tweaked based upon the specific machine it's being compiled on, which is nondeterministic.
<adfeno>davexunit: Then, I was right about not using `unzip` with `-a` option. :)
<adfeno>↑ (seems to create OS-specific text files).
<davexunit>I don't know much about those flags, but if they are useful to have on every build then the gnu build system could be changed to include them by default. this would require rebuilding every package.
<ZombieChicken>davexunit: So in effect guixSD is meant to be a bin-based distro?
<bavier>ZombieChicken: if you're interested in such things, and you know that you'd be building everything from source yourself, you could try adjusting the default compiler flags in guix/build-system/gnu.scm
<ZombieChicken>GuixSD is meant to be a source-based distro (with binary option) that doesn't let a user sanely configure their packages or build enviroment, and in essense removes one of the biggest advantages of a source-based distro?
<davexunit>there are no global settings that a user can tweak to affect all builds.
<davexunit>ZombieChicken: the purpose of being source-based isn't for gentoo-style global compiler tweaks, it's for users to be able to reproduce the work of others so that they don't have to trust binaries from a third party.
<adfeno>Extreme sides we want to avoid: 1) dependency-based dependent on single point of trust, might have slow updates; 2) source-based, where things can break easily when updated; 3) everything bundled, making different versions of the same thing appear in different "bundles"; 4) make everything into a container (ala Docker); 5) language-specific package management.
<adfeno>3,4,5 can bring special problems to free/libre software movement since these packages come from places not always aligned to the GNU Free System Distribution Guidelines, and might provide non-(free/libre) software to the end user.
<adfeno>And since the system distribution project has no control over 3,4,5 then there are only three options: a) make a list of accepted/blocked packages; b) make our own server; c) do as Guix and GuixSD do (take the packages out from those places).
<adfeno>Does #:use-module (guix build-system python) make the package recipe implicitly use: #:use-module (gnu packages python) ?