IRC channel logs


back to list of logs

<ewemoa> <- excuse to obfuscate / obscure source further?
<davexunit>magit 2.1.0 is out!
<guest`>ewemoa: no, generated html is already hard enough (ecmascript worse), WebAssembly is to aid "mobilization" (people needing a "computer" for things like running, so we have government surveillance): Firefox OS, ...
<guest`>in they claim explicit type system is easier than inferred type system (I agree), so it will better readability
<ewemoa>guest`: it will be nice if readability is improved
<ewemoa>mark_weaver: i'm getting a failure for guix download with "Bad Date header" -- similar to what's mentioned at -- using wget -S, i see that the Expires date uses PDT instead of GMT -- is there some good work-around?
<civodul>ewemoa: could you send the command and output to
<civodul>sounds like a bug in Guile's web client and/or the HTTP server it's talking to
*civodul goes afk for a while
<ewemoa>mark_weaver, civodul: FWIW, manually downloading followed by guix download file:///<pull-path-to-downloaded-file> seems to be one work-around
<efraim>for a build recipe, how do I write that I want gtk+2.x and not gtk+3.x?
<civodul>efraim: refer to the variable corresponding to the package object for GTK+ 2
<civodul>it's called 'gtk+-2'
<efraim>civodul: i was looking at gnu/packages/games.scm, and I noticed the #:use modules aren't alphabetical. I dont want to make basically a "whitespace patch" but is there something planned to change that?
<civodul>no, that's fine IMO
<efraim>so under inputs id write ("gtk+-2" ,gtk+)
<civodul>rather ("something" ,gtk+-2)
<civodul>here "something" is just a label for use in the recipe
<civodul>if doesn't designate a package
<efraim>thanks i'll try that
<rekado_>is there a variant of find-files that does not recurse over directories?
<rekado_>I just want to copy all matching files from the top directory.
<mark_weaver>rekado_: the second argument to find-files can also be a procedure.
<mark_weaver>that procedure gets the file name including directories
<mark_weaver>look in guix/build/utils.scm
<mark_weaver>the docstring of 'find-files' says that it gets the absolute file name, but actually that's only true if the first argument to 'find-files' is an absolute filename.
<mark_weaver>if the first argument to 'find-files' is ".", then the filenames that the predicate gets will be things like "./foo", "./foo/bar.c"
<mark_weaver>anyway, to make a long story shorter, you could just use a slightly modified version of 'file-name-predicate', except without the 'basename' call in there.
<mark_weaver>and then pass (full-file-name-predicate "^\\\\./…") as the second argument to find-files
<mark_weaver>alternatively, you could import the (ice-9 ftw) module and use (scandir ".") which just returns a list of file names in the current directory. (warning: includes "." and "..")
<mark_weaver>'scandir' also takes an optional second argument, a predicate procedure.
<mark_weaver>rekado_: so you could do this: (scandir "." (lambda (name) (string-match <REGEXP> name)))
<rekado_>mark_weaver: looks good. Thanks for the pointers.
<mistnim>hello, any plan to add i3wm?
<mark_weaver>we don't plan these things. packages get added when someone does it and submits it. would you like to?
<mark_weaver>we already have some other packages from suckless, see gnu/packages/suckless.scm
<mark_weaver>(dwm, dmenu, slock, and st)
<mistnim>ok mark_weaver, I still haven't tried guix, maybe in the future
<mistnim>the problem is that i3 is really critical for my workflow
<mark_weaver>well, we are all volunteers. we don't add packages that we're not personally interested in.
<mark_weaver>frankly, what we need at this stage are people willing to contribute.
<mark_weaver>all of us have added packages that we care about, and that's how we make progress
<ewemoa>mistnim: is this what you are interested in?
<mistnim>ewemoa: yes
<ewemoa>i'll take a look
<mistnim>mark_weaver: I understand
<mark_weaver>you can install guix on top of another distro, and then use your host distro's i3 while you package i3 for guix.
<mark_weaver>many of us followed that pattern, only switching to GuixSD after Guix had the packages that were most important to us.
<ewemoa>how nice...the i3 tarball has a file named "PACKAGE-MAINTAINER" :)
***ueno__ is now known as ueno
<mistnim>mmh, btw, am I wrong or there is no 32bit version?
<mistnim>oh I am wrong
<mistnim>that's not really clear, x86_64i686 is missing a whitespace
<ewemoa>mistnim: fwiw, i don't think guix has the following yet (which appear to be dependencies for i3): xcb-util-cursor, libev, yajl
<mistnim>is there another tiling wm?
<mark_weaver>ewemoa: we have several xcb packages, maybe one of them has it. sometimes the mapping from library name to package name is not obvious.
<mistnim>I guess I can try ratpoison, is there wpa_supplicant in the installation cd?
<mark_weaver>we are a 100% free software distro, no blobs, so hopefully your wireless device doesn't need one.
<ewemoa>mark_weaver: yes, i came across a number of xcb packages, but i don't see xcb-util-cursor, and shows a specific tarball for it -- i didn't turn anything up grepping through gnu/packages, but perhaps i missed something
<mark_weaver>ewemoa: you're right
<mistnim>mark_weaver: well, I was already thinking about that, unfortunately I think I will need to add the wireless firmware
<mark_weaver>what wireless adapter is it?
<mistnim>mark_weaver: wow, I'm not sure actually, it's in the laptop
<mark_weaver>what kind of laptop?
<mark_weaver>lspci or lsusb will probably say
<davexunit>cross your fingers and hope it's atheros
<mistnim>mark_weaver: intel 3945abg
<davexunit>that requires a blob
<mistnim>I knew that, already had the problem
<davexunit>oh, sorry.
<mark_weaver>what kind of laptop is it?
<mistnim>mark_weaver: lenovo 3000n200
<mark_weaver>afaik, lenovo has a policy of enforcing a "whitelist" of cards, so it's not possible to get an atheros card working in there without hacking the BIOS somehow :-(
<mistnim>I have also two random usb cards, and both of them too require blobs, one is ralink, the other is Asus
<mistnim>I guess those that don't are vary rare
<mark_weaver>there are a few listed here:
<mark_weaver>I own a ThinkPenguin TPE-N150USB. Guix actually builds the firmware for it from source code.
<mark_weaver>(the package name is "ath9k-htc-firmware")
<mark_weaver>The Tehnoetic is based on the same Atheros chipset, so I guess it would also work.
<davexunit>I still use a proprietary BIOS because the thinkpad x220 is unsupported by libreboot, but it has been hacked such that the whitelist has been removed.
<davexunit>which allowed me to replace the intel wireless chip with an atheros one from thinkpenguin
<fchmmr>davexunit, coreboot supports the X220. You'll still have a ME (and maybe other things), but it's freer than lenovobios
<fchmmr>mv/nully can hook you up with a SPI flasher
<davexunit>fchmmr: yeah that's a good point
<davexunit>fchmmr: you have an irc client that alerts you every time "libreboot" is mentioned, don't you? :)
<fchmmr>davexunit, also, someone (not me) forked libreboot to create "nonlibreboot"
<fchmmr>You could add a config there for X220, and build for it
<fchmmr>(that's a blobbed coreboot, but they re-use libreboot's automated build system)
<fchmmr><davexunit> fchmmr: you have an irc client that alerts you every time "libreboot" is mentioned, don't you? :)
<davexunit>if I ever feel daring, I'll go for it.
<fchmmr>and lots of other words
<fchmmr>(all libreboot related)
<davexunit>I'm going to start inserting random words into my irc messages and based on your response time determine what they are.
<fchmmr>My real name is also stalked on IRC
<fchmmr>If you say my real name, or any part of it (as long as you don't misspell it) I will be pinged.
<ewemoa>fwiw, here's a first attempt at xcb-util-cursor -- it builds here at least:
<fchmmr>my client has a limit of how many words I can use, though. I need to modify the src to remove that limitation.
<fchmmr>there's no actual limit, it's a bug
<mark_weaver>ewemoa: I've forgotten, were you the one who asked if you could submit packages to guix without revealing an email address?
<ewemoa>mark_weaver: yes
<mark_weaver>ewemoa: so you'd prefer to communicate with us exclusively over IRC and paste sites?
<ewemoa>mark_weaver: yes
<mark_weaver>is it because you'd prefer to remain anonymous?
<ewemoa>that's part of it, but to be honest, i haven't really used email in some years now
<mark_weaver>ewemoa: well, it is possible to have an email address that is difficult to attach your name to. on the other hand, anyone on irc can see your IP address by typing "/whois ewemoa"
<mark_weaver>civodul: what's your opinion of this?
<civodul>mark_weaver, ewemoa: i'm fine with anonymous contributions
<civodul>but i don't imagine myself reviewing/applying patches not submitted by email
<civodul>ewemoa: would it be an option for you to use anonymous email accounts?
*civodul has to go
<mark_weaver>civodul: yes, of course anonymous is fine. but ewemoa hasn't used email in years and would prefer to communicate exclusively over IRC and paste sites.
<mark_weaver>oh well
<ewemoa>mark_weaver: he he -- for the time being, i will try to send more polished things via some web 2 mail gateway -- thanks for your consideration :)
<mark_weaver> is well regarded
<ewemoa>mark_weaver: thank you for that pointer :)
<mark_weaver>I guess from my point of view: I don't care what your name is or where you live.
<mark_weaver>However, I do care about being able to establish trust in a contributor, and therefore some way to know that your submission next week is coming from the same person who sent it this week.
<mark_weaver>right now, anyone could log in as ewemoa and pretend to be you.
<rekado_>how should we attribute such patches?
<mark_weaver>but the other thing is that it makes less work for us to receive patches over email created by "git format-patch"
<mark_weaver>rekado_: attribute?
<mark_weaver>I'm okay with someone using an alias and an email address that cannot be tracked back to the individual.
<mark_weaver>one way to do that is to create and access the email account exclusively through Tor.
<rekado_>I mean as those with commit access are submitting the patches, how do we declare the author?
<mark_weaver>well, the author could be an alias and anonymous email address.
<mark_weaver>but apart from any of these considerations, which need not be set in stone, I see two issues:
<mark_weaver>(1) in git, commits have an associated "author", which is required to have an email field.
<mark_weaver>I suppose we could make something up for that..
<mark_weaver>but the bigger worry is:
<mark_weaver>(2) there needs to be a clear record that the author submitted this to guix to incorporate into our project.
<mark_weaver>maybe I should ask RMS about this...
<mark_weaver>with email, we have a record of every package submission that's not from someone with direct commit access.
<mark_weaver>we can point to that record and say "that person donated this package to us"
<mark_weaver>otherwise our copyright status is in doubt
<mark_weaver>well, I'm not sure about that, but it's a concern...
<bavier>signed patches?
<mark_weaver>bavier: sure, that would be a way to establish trust in a contributor, by their signing key. but it doesn't solve the copyright problem.
<mark_weaver>civodul: my biggest concern about accepting patches over IRC and paste sites is that we have no clear record that someone submitted this new code to us and intended for it to be part of guix and released under the GNU GPLv3.
<civodul>yes, good point
<civodul>and we need a copyright line
<civodul>so i guess contributions have to be pseudonymous at best
<civodul>and again, email is a must as far as i'm concerned :-)
<mark_weaver>okay, thanks
<mark_weaver>ewemoa: ^^^
<Steap>Should I write patches to Python against core-updates rather than master ?
<Steap>I need to fix this
<Steap>we got a bunch of modules that are not compiled in Python
<rekado_>what is /gnu/store/.links used for?
<mark_weaver>rekado_: deduplication
<mark_weaver>Steap: yes, I think changes to python are probably best for core updates
<mark_weaver>rekado_: iiuc, each entry in .links is a hash of the file contents. when a file is added to /gnu/store, .links is checked to see if a file with the same contents is already in the store, and if so, another hard link is made.
<mark_weaver>*the name of each entry in .links
<rekado_>mark_weaver: I see. Thanks.
<rekado_>well, my experiments with lsyncd are not very promising, unfortunately.
<rekado_>the event queue quickly overflows and then lsyncd restarts and re-syncs everything with rsync.
<paron_remote>hello #guix!
<paron_remote>davexunit: btw we should talk about guixops soon and what I can do to help at this state
<paron_remote>I guess I could just check out the code and look at it already
<davexunit>paron_remote: it needs to get rebased onto the current master branch.
<davexunit>once the basic container functionality is in master we'll have another decent testing platform.
<davexunit>for writing the <platform> adapters.
<paron_remote>davexunit: maybe I should wait for the container stuff for now?
<davexunit>no need to wait.
<davexunit>I hacked on it a bunch before. it will just be nice to have it when it's ready.
<paron_remote>ok :)
<paron_remote>I'm going to hack a bit on the web application I'm working on now and between today and tomorrow I'll start poking around in guixops
<davexunit>I think help defining more high level details would be useful. if we can get on the same page of what the workflow is.
<davexunit>figuring out exactly what the interface for <platform> needs to be.
<davexunit>how to do all the networking is important, too.
<davexunit>how would something like 'guix deploy ssh my-web-server' actually work?
<paron_remote>davexunit: okay, cool, looks like there's plenty for me to comment on then :)
<paron_remote>will start looking!
<davexunit>paron_remote: yeah there's tons. we're definitely lacking some solid direction.
<davexunit>I have a decent, very high-level plan that I wrote on the list about awhile ago
<davexunit>that might worth a read
***exio4 is now known as y
<civodul>Steap, mark_weaver: maybe a python-update branch would be more appropriate?
<civodul>mark_weaver: BTW what happened with the cURL failures in wip-diet on hydra?
<mark_weaver>civodul: I restarted the build and it worked the second time.
<mark_weaver>I do that a lot.
<mark_weaver>I save the logs of the failures.
<mark_weaver>many test suites have transient failures
<civodul>so it's a non-deterministic failure
<davexunit>yay non-determinism
<mark_weaver>there's quite a lot of it, I'm afraid.
<Steap>civodul: then what is core-updates for ? :p
<civodul>Steap: updates to the "core", where "core" means everything that leads to %final-inputs (GCC, Binutils, libc, etc.)
<mark_weaver>I've also tended to apply other updates and changes that are non-essential (no hurry) but would require a lot of rebuilding. I don't know if that's undesirable.
<mark_weaver>I guess there is a benefit to isolating changes so that breakage can be attributed to one change...
<mark_weaver>but on the other side is the limited capacity of our build farm.
<mark_weaver>*I've also tended to apply to core-updates [...]
<civodul>mark_weaver: we have to make tradeoffs due to our limited build farm, indeed
<civodul>so we can't really have one branch for each change we make
<civodul>but in this case, i think it's reasonable to make a special python branch
<civodul>davexunit: dockerdockerdocker:
<civodul>davexunit: see the last part about running each app in a container
<davexunit>aww, civodul is gone.
<davexunit>I think he was hinting at how we want to be able to isolate applications on guixsd.
<davexunit>and with call-with-container we can do so.
<mark_weaver>I'd like to isolate my web browser
<mark_weaver>that's probably the easiest way for someone to hack into my computer remotely.
<davexunit>what kind of resources would you like it isolated from?
<davexunit>I'd like to keep gathering use cases so we can make gnu/build/linux-container.scm have a sufficiently generalized implementation to handle all of them.
<Steap>I have a colleague who runs everything in Qemu
<Steap>it's a "heavy container" solution :D
<davexunit>right now I give the user control over which namespaces they want to unshare and what file systems they want created.
<davexunit>though I suppose that if the user doesn't want a new mount namespace then all the file system stuff should be skipped... hmm...
<Steap>so why is Docker so bad but bare containers so good ?
<davexunit>Steap: we first must make a distinction between the core technology and Docker's UI and domain specific things.
<davexunit>I define a linux container as a combination of namespaces, cgroups, and a chroot/pivot_root.
<davexunit>Docker builds on this base with a particular type of workflow and design.
<davexunit>Docker containers are defined by Dockerfiles, an imperative list of instructions to perform to build a static disk image, or rather a series of static disk images.
<davexunit>these images are unioned with a union file system and the resulting file system is mounted inside the container process.
<davexunit>my argument is that the use of raw disk images is insufficient for addressing the problems of reproducibility and leaves little opportunity to take advantage of a cache, though of course Docker tries.
<davexunit>since Guix uses a purely functional model, we get system-wide caching/deduplication quite easily.
<davexunit>in Docker you will only not waste space if your various containers use the exact same base images and do subsequent configuration steps in the *exact* order as in other Dockerfiles.
<Steap>I don't get why you do not achieve reproducibility
<paron_remote>$95 million of stage C funding
<paron_remote>and yet, a friend of mine said they talked to docker folks about known security problems, "and they acknowledge that but don't have the resources to work on it"
<davexunit>Steap: because the results of the build change depending on what time you build the container image, for one.
<davexunit>I have started working with Docker at my new job, and I will be doing more and more of it. it's certainly better than other lesser solutions like Chef.
<davexunit>but who configures the Docker host?
<davexunit>too many tools that don't compose. Guix composes.
<davexunit>so let's keep hacking and in a few years maybe we'll have a shot at using it "in production"
<Steap>I mostly hate the fact that people now like to share binary images
<davexunit>yes, that is a major problem.
<Steap>+ the whole thing seems fucking complex
<rekado_>re containers: is nobody using mandatory access control (e.g. SELinux)? I tried to contain my browser with SELinux but wasn't very successful, unfortunately.
<davexunit>I don't use SELinux, so I dunno.
<davexunit>SELinux always grossed me out for some reason.
<davexunit>too intrusive.
<rekado_>oh, it is gross, but I think it's useful.
<davexunit>Steap: unfortunately, a lot of people see the sharing of binary images as an advantage.
<rekado_>unfortunately I never learned how to write policies from scratch --- any other sysadmin I met disables SELinux.
<davexunit>Docker is "open source" software project for creating binary images of proprietary web applications for the "cloud", basically.
<davexunit>so whatever, that's fine. the free software community just needs something else to meet our needs.
<Steap>yeah, CLoud operators seem to like Docker
<davexunit>the proliferation of tools needed to make all this stuff work makes my head spin.
<davexunit>we may not have many software packages or system services, but I am always very happy to upgrade my guix software and guixsd system that generally "just works"
<davexunit>the functional package management paradigm is the clear winner to me.
<mark_weaver>davexunit: ideally, I would like my web browser to not have the ability to read or write arbitrary files of mine, nor debug attach to my processes, nor log my keystrokes when one of its windows is not in focus, etc.
<davexunit>I could get you the first 2 easily enough.
<mark_weaver>so if I download a file, it would go to a download directory that my normal user could access.
<davexunit>not sure about #3
<_`_>Steap: that's my thoughts on docker outside of outside of comparing to atomic packages and the deterministic features of a functional package manager
<mark_weaver>and if I want to upload a file, I would have to copy it to a special directory first.
<_`_>mark_weaver: that last one is impossible with X
<mark_weaver>yeah, #3 probably requires wayland
<_`_>idk if wayland is *good* enough either, but hopefully.
<davexunit>mark_weaver: we can easily create a container that bind-mounts a downloads and uploads directory and launches icecat
<mark_weaver>davexunit: that would be a great improvement, I think.
<davexunit>I don't know how, but it's possible to share whatever is needed for the x server stuff so that the window can be opened.
<_`_>I think that's trivial, issue is it's not isolated.
<davexunit>but better than nothing for now.
<davexunit>it's just a matter of what files/directories need to be bind-mounted.
<davexunit>or environment variables set.
<davexunit>I'm not knowledgable when it comes to X
<mark_weaver>it could be run within Xephyr for some added protection, although I don't know how much more.
<davexunit>I think 'guix system container' will work for this. a minimal guixsd config with just a service or two to do whatever setup is needed and launch icecat.
<mark_weaver>but wayland is probably our best hope there.
<mark_weaver>cool! :)
<davexunit>I would need to add an option to select which namespaces 'guix system container' would unshare
<_`_>I remember just passing the top levels $DISPLAY it it just working… which is kinda sad
<mark_weaver>_`_: what do you mean?
<davexunit>I don't have netlink stuff working yet, and only root could do that anyway, so this icecat container would have to run without a new network namespace.
<mark_weaver>yeah, ideally it wouldn't have access to localhost ports, but that could wait until later.
<davexunit>the plan is to have a container daemon that runs as root and builds containers for other users, like the guix-daemion.
<_`_>mark_weaver: Within an unprivileged container I could just use the DISPLAY env of the X server belonging to user (on the host) spawning the container, and this just ran the client on the host's X server.
<davexunit>cool (or not cool, but easy).
<mark_weaver>_`_: on
<mark_weaver>_`_: on GuixSD?
<_`_>no I haven't tried Guix's unprivileged container mechanism yet.
<mark_weaver>I confess I haven't looked closely at our X setup.
<_`_>but, yeah it's a sad convenience
<mark_weaver>I would expect xauth to prevent that, assuming that the container lacks the needed cookie.
<davexunit>_`_: read your little docker notes above. it's a shame that Docker cannot utilize user namespaces yet.
<davexunit>that would eliminate the unprivileged user creating privileged containers issue.
<_`_>they're too focused on supporting every os level virt mechanism ever
<_`_>can't be helped with those priorities
<davexunit>I don't understand why they would support all the backends that do the same thing: create namespaces, configure cgroups, call chroot, etc.
<_`_>they attracted joyant with initial support for illumos zones even microsoft by what I think is trying to utilize the windows sandbox
<davexunit>and lol at Docker running on OS X by just using chroot.
<davexunit>is that what VC funding does to people?
<_`_>Docker reminds me a lot of Apple really
<davexunit>#guix is my happy place where I can hack on what I feel are real solutions to packaging and deployment problems. :)
<_`_>And are they really “isolating” with chroot(1) for os x? I thought they were using vagrant to have users download a VBox VM with ubuntu plus docker installed. Not that the latter is sane either.
<davexunit>that's boot2docker I think.
<davexunit>"Whilst chroot offers something of a lowest common denominator environment for all Unix operating systems, it’s likely to be the path of least resistance for a native OS X implementation that avoids the use of virtual machines running Linux."
<_`_>is that actually implemented and something they ship?
<_`_>that's horrible
<davexunit>I mean, they admit that it's the LCD, but a chroot is just not sufficient for anything
<_`_>I'm scared to find out
<davexunit>I don't think they've shipped such a thing
<davexunit>maybe they've come to their senses about that particular thing.
<_`_>stranger things have happened
<davexunit>mark_weaver: I was wondering, since test suites often use random numbers, is there anyway that we can set the seed to something fixed so that the test suite always runs with the same set of random numbers?
<davexunit>for determinism's sake.
<mark_weaver>good question
<mark_weaver>I don't know
<davexunit>the seed will of course be chosen by a fair dice roll.
<mark_weaver>is there a way to arrange for /dev/random and /dev/urandom to be deterministic within the build container?
<davexunit>research time.
<mark_weaver>perhaps based on the derivation hash
<davexunit>or a fixed number for all builds.
<davexunit>maybe that's undesirable.
<davexunit>people could hardcode that number in their test suites and change behavior
<davexunit>so yeah, maybe the derivation hash would be a good idea.
<davexunit>if it's even possible
<mark_weaver>I think I would prefer it based on the derivation hash, so that we at least get different test scenarios across builds.
<davexunit>that's another good reason
<mark_weaver>but the clock is another big source of non-determinism
<davexunit>in ruby land, we use a library called timecop to deal with time in test suites, but it's not a system level thing. it just stubs out methods in the relevant Ruby interfaces to return fixed values.
<davexunit>I wonder if we can address it at the system level...
<davexunit>I bet if we could it would have been done by now.
<mark_weaver>and a lot of other stuff in /proc like cpuinfo, and the kernel being used, etc.
<mark_weaver>and then there's software that actually tries running CPU instructions that are only implemented on certain CPUs.
<davexunit>can one bind-mount over /proc/cpuinfo? I bet not.
<mark_weaver>I dunno, I would expect that you can, actually.
<mark_weaver>but admittedly that's just a guess
<davexunit>more research!
<davexunit>anything we can do to further remove sources of non-determinism would be great.
<mark_weaver>yes, you can. or at least it just worked for me on linux-libre 4.1.1
<mark_weaver>that would actually be helpful for arm builds, I suspect
<davexunit>so perhaps we can add fixed versions of these files that change depending on the underlying hardware
<mark_weaver>I have to go afk for a while.. ttyl!
<davexunit>which bogus cpu to we report? :P
<davexunit>see ya mark_weaver
<phant0mas>what env variable I am missing? because I am getting "possibly undefined macro: GUILE_MODULE_AVAILABLE" with autoreconf -vfi
<davexunit>phant0mas: you're missing guile's aclocal stuff
<davexunit>ACLOCAL_PATH or something
<mistnim>how can I launch the guix image with virtualbox?
<Steap>could we use a chromebook with an ARM CPU ?
<mistnim>mark_weaver: where should I put the firmware blobs in the installation image?
<mistnim>mark_weaver: ifconfig doesn't see a thing, I supposed this means the kernel doens't have the driver of neither my eth nor my wifi card
<davexunit>Steap: does it run blob free?
<Steap>davexunit: no idea :/
<davexunit>people are making special-purpose distros just for running Docker or whatever on.
<davexunit>because debootstrap, etc. are too hard I guess.
<davexunit>or rather not hard enough.
<guest`>mistnim: "Virtualbox is not included in Trisquel 7.0 as the newer versions (from 4.2 on) depend on the non-free open watcom compiler"
<davexunit>mistnim: we can't really give advice about how to add blobs to your system here.
<mistnim> davexunit: really?
<guest`>mistnim: you can search for hardware support at or try running trisquel first
<davexunit>mistnim: we would be encouraging the usage of proprietary software.
<davexunit>this channel is not for that.
<mistnim>awell davexunit I'm poor, I'm not going to change my laptop, so you are not really encouragin the usage of proprietary software. It's better to help me use guix and eventually contribute I think. Next time I have money I will buy a 100% free laptop
<mistnim> this is already like a 7 years old computer, it's not like a bought it yesterday
<guest`>mistnim: see Documentation at
<davexunit>mistnim: I'm sympathetic to your cause, but we really cannot encourage the use of proprietary software here. there are instructions elsewhere online for loading kernel modules.
<guest`>mistnim: a old computer is probably supported by free software, try running trisquel first
<davexunit>guest`: his wireless chip requires a blob.
<guest`>davexunit: <mistnim> mark_weaver: ifconfig doesn't see a thing, I supposed this means the kernel doens't have the driver of neither my eth nor my wifi card
<guest`>eth card too?
<mistnim>iand that doesn't require a blob
<davexunit>mistnim: well we can try to help with your ethernet chip if the module is in linux-libre
***civodul changes topic to 'GNU Guix | | 0.8.3 is in the works | | This channel is logged, see <>.'
<davexunit>I misunderstood.
<Steap>davexunit: should we use "return" or "exit" in guix environment ?
<Steap>cf. my patch about the return value
<davexunit>Steap: it's "exit status"
<davexunit>that's the term that the GNU libc docs use.
<mistnim>it's a broadcom netlink bcm5906m
<Steap>davexunit: yeah, but I see you're using (return (...))
<davexunit>search around for what kernel module that responds to
<davexunit>Steap: return is for the monadic api
<Steap>so should I use that
<davexunit>(return (exit (status:exit-val foo)))
<davexunit>I guess
<Steap>damn, that's becoming quite complexe
<davexunit>(return (status:exit-val foo))
<davexunit>and do the exit call elsewhere
<davexunit>it's not very complex...
<Steap>nah I don't get it like at all
<davexunit>but you're in the store monad
<Steap>yeah, that's the first thing I have no clue about
<davexunit>so non-monadic values must be wrapped with (return ...)
<davexunit>so don't worry about grokking that.
<davexunit>just know that you'll need 'return' to get things out of the monadic expression
<guest`>mistnim: use to ask for help
<Steap>k, merged :)
<davexunit>does it work?
<rekado>actually, "return" puts a non-monadic value into a monadic context, no?
<davexunit>rekado: yes.
<davexunit>I'm trying to describe it in another way that makes more sense in this context
<rekado>(heh, "in this context")
<davexunit>Steap is trying to get a "normal" value out of the monad.
<mistnim>guest` do I have to add a compiled module to the installation image? How does that work?
<davexunit>you should be able to modprobe the needed thing
<rekado>(BTW: I very much recommend --- it's a very easy read with silly pictures and when you're done monads are a very intuitive concept.)
<guest`>mistnim: there is a field to build modules on the initrd, mark_weaver had such configuration, ask him in the mailing list if he don't reply here
<guest`>mistnim: modprobe can work too, but is less convenient
<rekado>cmake-build-system and I are no friends anymore.
<rekado>looking at the definition it looks all right, but in so many packages using it I have to manually do something to get the RPATH set properly.
<rekado>(and mostly I fail)
<civodul>davexunit, Steap: (return (status:exit-val ...)) is sufficient, i think; 'exit' is implicit
<mistnim>ok I restart and try
<amz3>sneek: later tell alezost yes, my address is now, thanks.
<davexunit>civodul: oh really?
<davexunit>the program can just return an integer and it will exit with that value?
<mistnim>no, the modules, where already loaded, that is not the problem
<davexunit>and 'ifconfig -a' lists nothing but loopback?
<mistnim>davexunit: ifconfig lists nothing
<mistnim>didn't try ifconfig -a
<davexunit>worth a try, I don't enough to help further right now.
<bavier`>mistnim: yes, try ifconfig -a
<mistnim>oh well, ok
<Steap>ice-9/boot-9.scm:65:2: Throw to key `vm-error' with args `(vm-run "VM: Stack overflow" ())'.
<Steap>does that ever happen in Guix ?
<remi`bd>no backtrace?
<civodul>davexunit: yes
<davexunit>civodul: cool
<davexunit>civodul: were you showing me that docker article 1) to have a little laugh and 2) to emphasize that you want to run certain programs within contains on guixsd?
<Steap>ok, this happens when I build tk
<civodul>davexunit: a bit of both :-)
<mistnim>yes, it's listed in ifconfig -a, weird
<davexunit>civodul: mark_weaver and I were discussing coming up with a configuration for running icecat from call-with-container
<davexunit>made me think that we perhaps we need a tool for this use-case to make it convenient.
<davexunit>like 'guix container run icecat'
<davexunit>with the expose/share flags from 'guix system'
<davexunit>plus flags to set environment variables
<davexunit>and another in case the user wants to specify which namespaces to use
<guest`>mistnim: maybe you are just without dhcp?
<Steap>hum, the tk build is OK on hydra
<guest`>mistnim: maybe you need to activate the interface like "ifconfig eth0 up" or "ifup eth0"
<mistnim>guest`: it works
<Steap> Any ideas on where I should start debugging this failure I get when building tk ?
<guest`>mistnim: you mean dhcp works in your guix installation?
<civodul>davexunit: definitely, icecat is a good example of something to run in a container
<mistnim>guest`: yes, I'm pretty sure that it works
<davexunit>civodul: I'll work on such a thing after I get what I have ready for release.
<civodul>sounds good!
<civodul>the problem is that until we have a container-managing daemon, we'll have to 'sudo guix container run ...'
<davexunit>civodul: *not* if the process only uses a single uid/gid
<civodul>because it could run under a separate uid name space you mean?
<davexunit>yeah, an unprivileged user can still create a user namespace that maps *only* her uid/gid
<civodul>right, but then you can't do the other things: other name spaces, chroot, etc.
<davexunit>and for icecat, we would just tell guix not to unshare the network namespace
<davexunit>civodul: the new user namespace allows us to create all the others :)
<davexunit>for example, I use 'guix environment --container' as an unprivileged user
<civodul>i think i didn't get that part
<davexunit>there are limitations
<davexunit>but it can work for this case
<civodul>but you still can't use mount(2) or chroot(2), can you?
<davexunit>there's a new mount namespace, so yes, you can.
<civodul>damn it!
<civodul>that's wonderful no?
<davexunit>the limitation is with the uid/gid mapping
<davexunit>an unprivileged user can only map themselves
<civodul>yes, but that's enough for 'guix environment' and that kind of things
<civodul>damn, that's great
<davexunit>and of course they can't create network bridges and things
<davexunit>so the container daemon will still be useful for those things
<davexunit>but yeah, you're not totally screwed as an unprivileged user.
<civodul>yes, that's cool
<davexunit>root probably also has to setup cgroups, I imagine.
<civodul>so when we were discussing about guix-daemon vs. uid name spaces, that makes sense
<civodul>i'll have to think why this works; mount and chroot have always been restricted on unix
<davexunit>new mount namespace that doesn't interfere with the mount points elsewhere
<davexunit>call-with-container creates a directory in /tmp that it owns to use as the new root
<davexunit>mounts a tmpfs there, then /proc, /sys, and various bind-mounts
<zacts>davexunit: mark_weaver:
<zacts>^ it's on sale now
<zacts>they have it up for purchase
<davexunit>zacts: I know where I'm going tomorrow
<zacts>just fyi
<davexunit>thanks zacts
<davexunit>gotta go!
<zacts>davexunit: the MIT bookstore? :-)
<zacts>davexunit seems so excited about it, that he is getting a headstart on waiting outside the MIT bookstore in a tent all night, just like the crazy friday after thanksgiving americans do for other things.
<zacts>but davexunit is such a nerd he will only do this for a scheme or lisp book
<zacts>davexunit should do a parody short documentary that shows him waiting in a tent all night to guarantee he gets the book the next day
<civodul>i want that book too
<paron_remote>zacts: ooooh cool
<paron_remote>it's too bad the MIT Press website shopping cart doesn't work for me