<zacts>ok rekado so sorry for my delayed response. I may try to get guix working with full disk encryption on the next release <zacts>I need networking first, and I don't even have a laptop yet with a working blob free ethernet <zacts>(or I don't grok how to configure it off of the guix live usb) <paron_remote>(I can't speak for packaging, but I've met the owncloud main guy at libreplanet/fsf 30th and I really liked him) <paron_remote>but probably most people in free software I like I seem to disagree with heavily on packaging right now <paron_remote>the #guix position is an underrepresented position at present :) <davexunit>paron_remote: "Debian and other distributions are going to be that thing you run docker on, little more." ***ueno_ is now known as ueno
<lfam>Is it okay to put python-setuptools as a native-input of python-3 packages just to make the python-2 translation work easily? It seems that other packages do this. <rekado>odd: I rebased my axoloti.scm module that builds the cross-compiler and the firmware, rebuilt, and now two of the three elf files are identical to the prebuilt ones that upstream provides. <rekado>have to redo this a couple of times to see how this can be. <lfam>Oh, I misunderstood. Are you sure you aren't simply building the exact same binary? <rekado>the upstream project is using a binary release of the cross-compiler suite. <rekado>I tried rebuilding it faithfully by using the same configure flags and same source versions. <rekado>previously all three ARM binaries differed from upstream's binaries. <rekado>then I rebuilt after rebase and diff'd the smallest two and they are identical to upstream's binaries. <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>if our tools encourage us to add inputs that are not needed we should try to change the tools. <rekado>having to treat customised python2 packages specially has long been an annoyance. <rekado>can package-with-python2 be made smarter? <lfam>I'm not smart enough to say, yet ;) <lfam>There has been some discussion on the ML. <lfam>It may be possible that those python-3 packages did need setuptools at the time, but that the relevant features have been integrated into Python 3 itself since then. <lfam>Closed in expectation of a more general bug report <anoopcs>I could successfully install GuixSD and now during first boot it takes very long time to initialize some steps. <anoopcs>Long wait time after "random: .guix-real urandom read with 25 bits of entropy available" and the another wait after <anoopcs>"random: nonblocking pool is initialized" <anoopcs>And now waiting after "lsh-make-seed: Reading system state . . . Got 36 bits of entropy from system state" and so on. <anoopcs>Is something wrong with my installation or is this expected during first boot? <rekado>anoopcs: I think it's normal on first boot. <anoopcs>rekado, Still waiting . . . How long?? <anoopcs>Is it safe to forcefully reboot the system at this stage? <efraim>rekado: it looks like you forgot #: use-module (gnu packages gcc) with impute <iyzsong>anoopcs: it's ok to reboot. iirc, lsh need typing the keyboard randomly to make the seed. <civodul>what about building all of core-updates? <efraim>the only other possible change is attr <efraim>it had 2 releases that day, we have the earlier version <civodul>looks like util-linux 2.27 is the latest, so we're good <efraim>unfortunately i dont really have time to work on anything until sunday <rekado>efraim: oh, I think you're right about impute. <rekado>I have the gcc module line up there, but not in the patch. <civodul>efraim: i can update attr/acl and get the build started <anoopcs>iyzsong, It worked. I entered some random characters via keyboard and everything is fine. <efraim>patch time? "Entropy collection is slow. Please mash your keyboard" <iyzsong>yeah, lsh-make-seed did prompt with 'Please type some random data.' <rekado>trying to package SSSD, but it needs SELinux, which (I think) doesn't make much sense on GuixSD. <rekado>the immutable nature of the store means that we cannot optionally add SELinux labels. <rekado>and it would be crazy to do this on each boot. <rekado>so to appease SSSD I can package the userspace part of SELinux, but it will be ineffective. <efraim>is there a flag you can pass it to not use SELinux? <rekado>there are lots of flags to override many bits and pieces, but none of them affect SELinux. <rekado>SSSD = System security services daemon <rekado>from the description: Its primary function is to provide access to <rekado>identity and authentication remote resource through a common framework that <rekado>can provide caching and offline support to the system. It provides PAM and <rekado>NSS modules, and in the future will D-BUS based interfaces for extended user <rekado>information. It also provides a better database to store local users as well <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"? <civodul>i'm pretty clueless about SELinux though <rekado>yes, they could probably be generated then. <rekado>but I'm not going to work on making SELinux work with GuixSD. <civodul>so does that mean that SSSD cannot be used on GuixSD? <rekado>I'm packaging libselinux right now. <rekado>libselinux won't be usable without labels and SELinux enabled; but it's enough to satisfy SSSD. <civodul>AppArmor looks OK, from what i understand <rekado>SSSD uses libselinux only for an optional plugin; it's usable without having full SELinux support. <rekado>SELinux isn't bad, but it's pretty hard to understand. <rekado>even using and debugging existing policies on Fedora was hard. <rekado>(I tried to use it to limit what my browser may do, but I couldn't make it work.) <rekado>writing a system-wide policy seems like a lot of work. <rekado>also: how would be provide policies? As additional package outputs? Or as a separate package? For each package individually? Or one for as many packages as we can write policies for...? <rekado>it's not clear to me how to approach this. <rekado>yeah, so I suggest we just ignore this until someone really wants to have SELinux support. <jubalh_>Little off-topic question: how do you create your presentations/slides? <davexunit>same, though I'm not as good as civodul is at it. <civodul>problem is my TeX files are barely readable <davexunit>I'm going to try using org-mode with a latex/beamer export <rekado>I'll try to just use org-mode without export. <jubalh_>rekado: do you take a plane to FOSDEM? <rekado>Berlin -> Koeln -> Bruxelles; takes about 6 hours. <rekado>I got a ticket with the "Sparpreis Europa" fare. <civodul>should we get GuixSD stickers for FOSDEM? <civodul>i still have a bunch of old Guix stickers <rekado>can I get the path to the linux-libre-headers and glibc without having to explicitly add them to native-inputs? <rekado>I need to patch two includes in swig; they expect full paths, it seems. <jubalh_>what can be the reasons when guix package -i vim-7.3 sais there is no such package? <jubalh_>davexunit: i thought maybe also an older vrsion is available. where can i go to see which packages/versions exist? <mark_weaver>guix archive: error: build failed: error parsing derivation `/gnu/store/86cplv459mz3y7f3ggbcq3n54k017p3f-grep-2.22.drv': expected string `Derive([' <davexunit>you should definitely search for a package before trying to install it. <civodul>mark_weaver: ouch, sounds like a corruption <civodul>mark_weaver: do you know which build machine this is? <civodul>jubalh_: also, you can use "guix package -i foo" to install the latest version of foo <jubalh_>i only wanted to install an older version to play around and see how it treats one package in different version and then use garbace collection etc ;) <taylan>jubalh_: old versions are generally not kept in guix unless there's a reason to such as some other program still depending on it <jubalh_>next question: i have (use-service-modules networking ssh) in my config.scm. it should install and start ssh daemon? <davexunit>that just imports that particular Scheme module <Baughn>Opinions on Guix vs Nixos? Which is more mature? <taylan>Baughn: GuixSD is yet version 0.9, whereas NixOS has been "production ready" for some years AFAIK <taylan>but I'm being told GuixSD is quite stable <Baughn>NixOS is ready for *some* purposes. You can't, say, run Steam on it. <davexunit>well, that's not a particularly useful purpose. <taylan>I don't know if the NixOS developers see that as a goal. I'm pretty sure the GuixSD developers don't, since we're pretty strongly for software users' freedom :) <Baughn>It's an important purpose for me. :P <Baughn>But fair enough. I wasn't expecting anything different from an FSF distro. <civodul>Baughn: it's not something Guix as a project works on, on the contrary <jubalh_>davexunit: so i do a guix package -i openssh and then need to start the service with: dmd start sshd ? <Baughn>civodul: The question is closer to "Will guix be LSB-compatible?" <davexunit>the thing to understand here is that Steam is given to you as a pre-built binary that *makes assumptions* that do not hold true on NixOS or GuixSD <Baughn>I understand why it doesn't work on NixOS. Same on Guix? <Baughn>..though I'm getting sidetracked. <taylan>Baughn: (for clarity, Nix -> Guix; NixOS -> GuixSD.) <Baughn>Could I, say, run a debian-targeted Go binary? <davexunit>in general, you should not be running pre-built binaries from random sources like this. <civodul>in general, passing binaries across systems, Guix or not, does not work <civodul>with the exception of statically-linked binaries <Baughn>Go binaries are statically linked by default <Baughn>Guess I'll just try it. ZFS support? <HotLava>What exactly is the problem with running steam? Shouldn't it work if the correct LD_LIBRARY_PATH is set? <davexunit>if that location is hardcoded, then no it won't work. <Baughn>HotLava: Steam overrides those paths in a bid for hermeticity. This backfires. <davexunit>HotLava: I don't know exactly, but one should simply not use Steam because it denies users freedom in many ways, including DRM. <HotLava>you mean they use a hardcoded rpath to /usr/lib, etc? <davexunit>these "problems" just don't exist when you have the source code and can build it yourself. <Baughn>HotLava: /usr/lib does not exist in NixOS, or apparently GuixSD. <Baughn>HotLava: Steam sets LD_LIBRARY_PATH because it bundles a lot of libraries, but it depends on having a debian-like environment <HotLava>i guess you could binary-patch it to use RUNPATH instead of RPATH ;) <Baughn>You can patch the ELF files. But it integrity-verifies binaries on startup. :P <civodul>but again, Guix is about providing users with freedom, transparency, and security <Baughn>davexunit: FWIW, Steam also distributes a lot of non-drm and even open-source games. <davexunit>yeah, they do not. we do not conform to the FHS because global state hinders us. <davexunit>Baughn: using a non-free platform to run free games doesn't make much sense. <HotLava>i wouldn't ever expect steam to be part of the official distribution, but if someone wants to run it, why not? <Baughn>davexunit: It does, for people who don't care about OSS status. You should understand that. <davexunit>HotLava: sure, why not, but we're not going to fundamentally change the way we do tings to accomodate proprietary software. <Baughn>HotLava: If GuixSD is anything like NixOS, running Steam will require a chroot at best. <davexunit>it's not *our* fault that Steam doesn't work, it *would* work if the source were free and we could build it ourselves. <Baughn>..can we drop the Steam talk? It was an example, of "LSB-dependent binaries". They don't work. Gotcha. <davexunit>the Steam binaries are intended to work on Debian/Ubuntu, nothing else <taylan>don't think Guix/GuixSD make any FS type assumptions but not sure... <Baughn>Guix wouldn't. GuixSD needs to have explicit support to make any given FS work. <Baughn>Especially in the case of ZFS, which is a bit of an odd duck. <davexunit>I've never used it. is that the file system that cannot be included in Linux because it uses a bad license? <civodul>right, it's under that sill Sun license <Baughn>Yeah. It's an open-source license, but not GPL-compatible. <civodul>GPL-incompatible, which is why it cannot be in the kernel <davexunit>I don't understand that, because the ZFS module for linux is *surely* a derivative work of Linux, thus GPLv2 licensed, no? <Baughn>In practice that means it has to be compiled locally, on each system running it. <Baughn>davexunit: It's legally ok so long as you don't distribute the derivative work.. <Baughn>You can't have a zfs binary package <Baughn>You can have a source package, no problem there <davexunit>why would we encourage the use of code that violates the GPL? <Baughn>Because there aren't any good alternatives. <taylan>is it really derivative work? does it contain source code from the Linux repository? <civodul>anyway, it seems unlikely that ZFS will ever be available in Guix{,SD} <Baughn>Unstable, buggy, and doesn't have the same featureset. <davexunit>taylan: it's a kernel module, it uses kernel APIs <davexunit>it's a derivative work, which is why no one can distribute binaries <Baughn>ZFS, I will note, is *not* proprietary code. <davexunit>sure, but it doesn't satisfy the terms of the work it builds upon <Baughn>I appreciate a dedication to open source. But ZFS does not contradict that. <Baughn>Yeah, and that's basically because of lawyers. ***Weemi is now known as remi
<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? <Baughn>davexunit: Spirit? Yes, sure, I simply don't care very much. <taylan>I'm interested in legalese logic in general. (not because I'd try to exploit free software) <taylan>but meh, I doubt we have lawyers in the channel :) <taylan>"there is nothing in either license that prevents distributing [the ZFS module] in the form of a binary module or in the form of source code" OK, that's what I was guessing. <davexunit>if there is no legal issue for distributing a zfs binary, we would accept a package for it. it just seems very unlikely that this is really the case. <taylan>I imagine another legal can of worms opens when it comes to an entity like GuixSD shipping ZFS together with the rest of the system <Baughn>..and distributions fall under the 'mere aggregation' clause. <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 <Baughn>civodul: Ooh. Show me the 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. <paron_remote>there was something called goblin camp which in early stages was free <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. <rekado>personally, I think we need more people cooperating to write free games :) <Baughn>I still have some hope that I'll convince Toady to open-source DF. Eventually. :) <Baughn>There's only one version, and it's free. <Baughn>But Toady's very paranoid about retaining creative control, which is why it's closed-source. Mostly closed-source. <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? <mark_weaver>I see that $(MAKE_OBJDIR) is bound to $(INSTALL) -D $(OBJDIR) in some places ***me is now known as Guest64548
<lfam>Attempting `guix refresh -l libid3tag`, it errors out with gnu/packages/bioinformatics.scm:3880:5: In procedure module-lookup: Unbound variable: gfortran <lfam>Oh, it seems to happen with any package <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.