<rekado>unfortunately, the remaining binary is the actual firmware ... and it still doesn't work.
<rekado>using objdump to disassemble both binaries and compare them, but it's a lot of work.
<rekado>lfam: you can add setuptools to the python2 variant of the package without having to add it to the python3 version. There are packages that do this.
<rekado>(it's a little more verbose this way, but you avoid an unnecessary input)
<lfam>Yeah, but then won't we end up with a bunch of python-2 packages that can't be used themselves by (package-with-python2)? Like the situation with python2-cryptography and python2-pyopenssl?
<lfam>I tested some existing packages whose python-3 variant include python-setuptools and have a python-2 variant generated by (package-with-python2). The python-3 versions don't need python-setuptools but the python-2 versions do.
<rekado>yes, it would be like python2-cryptography.
<rekado>SSSD is used on Fedora/RedHat/CentOS to simplify/unify user authentication and management.
<fps>hmm, while the store is immutable in the model, is there anyting that enforces it?
<rekado>I think I'll need SSSD to use GuixSD here in the office.
<rekado>fps: there is no "revalidation" of the /gnu/store, if that's what you mean.
<rekado>SELinux labels files and uses these labels and paths to evaluate a security policy.
<rekado>this works reasonably well with FHS; in the case of GuixSD we'd have to build a policy from scratch. And I don't think anyone here really wants SELinux so badly to agree to writing an SELinux policy for all packages.
<fps>i must admit i have no clue whatsoever really about SELinux :)
<rekado>Users *could* relabel everything in /gnu/store but modifying file attributes for things in the store is a hack.
<rekado>fps: a surprisingly large number of sysadmins don't have a clue either ;)
<rekado>(most sysadmins who have to work with Fedora/RedHat-based systems seem to simply disable SELinux)
<civodul>rekado: couldn't the labels be created upon "guix system reconfigure"?
<davexunit>using the CDDL is not necessarily a problem, but it is when the derivative work is under the GPL.
<Baughn>In practice, my choice is between using ZFS and losing data. So I'll accept your decision, but it does mean I won't use GuixSD.
<davexunit>Baughn: I'm sorry, but we can't simply look the other way at legal issues in order to obtain more users.
<Baughn>davexunit: Would it help if I explain why there isn't a legal issue?
<taylan>davexunit: hmm, what if it's distributed without the Linux headers? does it count as derivative merely because it contains calls to undefined functions that have the name and signature of functions in the Linux source code? (just curios about license technicalities, not interested in ZFS per se...)
<davexunit>Baughn: well, no, because it's well known that there is a legal issue.
<Baughn>taylan: "Maybe". Not in source form, hwoever.
<taylan>because the same was asked about Elisp libraries once. if they're Emacs derivatives, that means you can't distribute Elisp code that's not GPL licensed...
<davexunit>by distributing it in source form, we are encouraging people to use software that is in violation of the GPL when a binary is distributed. why would we want to promote this?
<davexunit>do you see how this source-only circumstance is not in the spirit of free software and GPL compliance?
<taylan>ah, ok. legally GuixSD could support ZFS then, and if ZFS is free software, albeit not GPL-compatible, I'm not sure if FSF guidelines would prevent that. maybe there's something about this in the free distro guidelines
<davexunit>yeah, this is a rather gray area. the FSF licensing team would surely know the answer.
<taylan>(I'm not personally interested in ZFS (yet?) but I'm interested in an improved experience for GuixSD users, and I'd think ZFS support probably outweighs the obnoxiousness of their license, so long as it's free software...)
<taylan>IOW, as long as no harm is done to users...
<davexunit>as long as it still meets the criteria we need to satisfy, we're good.
<civodul>mark_weaver: /gnu/store/86cplv459mz3y7f3ggbcq3n54k017p3f-grep-2.22.drv on enge.fr was filled with zeros; i've deleted it with "guix gc -d", but dmesg shows i/o errors
<_`_>what you can't distribute is a linux kernel binary that has zfs built in. as Baughn said you can distribute zfs modules. if you couldn't, live medium with zfs modules for the kernel on it, couldn't be distributed either.
<rekado>about LBS: we have container support and we can easily build different versions of libraries, so with some effort it would be possible to prepare a container environment that has certain libraries in what seems to be the default locations according to FHS.
<rekado>I don't know anything about Steam and don't care about running proprietary software, but using containers one might be able to run prebuilt software in a container.
<rekado>(I was thinking about demoing packages built for Debian before making the effort of packaging them for Guix)
<rekado>so running binaries built elsewhere would be possible if you'd think it's worth the effort that all this plumbing requires. (In most cases I encountered it's easier to just build from source with Guix.)
<Baughn>rekado: Free software is worth the pain, generally, but I personally treat games as an exception.
<Baughn>rekado: Although I'm more likely to want to run Dwarf Fortress than Steam.
<Baughn>..another odd duck. Redistributing DF is fine, redistributing modded DF is fine, but the game is definitely not OSS compatible.
<rekado>Guix doesn't actively block you from running prebuilt software (although not following the FHS poses problems), and compared to other distributions our tools allow for very flexible ad-hoc environments. However, we as a project do not make any effort or assist in getting proprietary software to run with Guix.
<Baughn>Keeperrl is an obvious DF clone, and nowhere near as detailed.
<Baughn>The entire OS interface is open, so I could recompile DF to run on GuixSD fairly easily, but..
<mark_weaver>bah, we need to update to nss-3.21 to fix CVE-2015-7575, but the build is failing. something in its build system is failing: mkdir: cannot create directory ‘Linux4.3_x86_/gnu/store/isxqjfaglyfsbcv75y8qbqbph8v28ykr-bash-4.3.39/bin/bash_glibc_PTH_DBG.OBJ’: No such file or directory
<mark_weaver>I guess that something is substituting "bash" -> "/gnu/store/isxqjfaglyfsbcv75y8qbqbph8v28ykr-bash-4.3.39/bin/bash" in a place where it shouldn't, but I don't know what's doing it.
<rekado>mark_weaver: in which phase does this happen?
<lfam>I see that was recently fixed in 2409f37f28d54
<lfam>Baughn: Since we are still working on getting Go in to Guix, I tried to see if I could run Syncthing (free software written in Go) binaries on GuixSD. The answer is yes although it's a lame solution. We are very close to having a real Go package.