IRC channel logs

<toxemicsquire4>Is anyone a guix developer

<jxself>It is usually better to just ask your question on IRC. :)

<toxemicsquire4>Does anyone know the current status of the HURD port?

<jxself>In progress.

<toxemicsquire4>Like is it close to finish or still very experimental

<jxself>Lots of people use HURD already. Some use it in QEMU. Some on older hardware. I recall reading that 75% of the packages in Debian main compile & run just fine.

<jxself>There are public boxes available: http://www.gnu.org/software/hurd/public_hurd_boxen.html

<toxemicsquire4>Is it possible to run HURD on SATA yet as of HURD 0.5

<jxself>AFAIK, there is still no SATA support. That doesn't always matter though because some boards have a legacy compatibility mode.

<DusXMT>that's not true, there is sata support

<DusXMT>it was added around the time of the wheezy release

<DusXMT>they get recognised as SCSI discs, so you'll find them in /dev/sd*

<toxemicsquire4>I can't install Wheezy on my SATA computer because it can't find the disk drive

<jxself>Oh it's been added? Great.

<DusXMT>Then there are two possibilities: The developers of d-i forgot to take SCSI drives into consideration, or: Your BIOS lacks a feature Mach uses for getting the device list (my netbook had this problem, I don't remember exactny how the feature was called though)

<toxemicsquire4>Is there any wireless support? Even from the DDE layer?

<DusXMT>Only some anicent PCMCIA cards ;)

<jxself>GNU has two kernels nowadays, you know, so completing work on HURD doesn't seem as important as it once was though.

<jxself>Linux-libre was made a GNU package package about 2.5 years ago.

<toxemicsquire4>HURD development has skyrocketed for about the last 2 years. It has alot of development compared what it used to have had a couple years ago

<jxself>Yes, and that's great IMO. The more GNU kernels the merrier IMO. :)

<DusXMT>Note: It's important to note that the Hurd isn't exactly a kernel. It is `A replacement for the UNIX kernel', but it itself isn't a kernel, but a collection of servers that run on top of a microkernel (currently only Mach) to provide POSIXy APIs, and the translator API of course

<toxemicsquire4>I know that, but I'd rather call it just HURD/Mach kernel that HURD multi-server on top of Mach microkernel

<DusXMT>Simply saying `The Hurd' does the job, imho, no need to bring confusing terms :)

<toxemicsquire4>Yea pretty much. Do you ever think it will be "done", and by that I mean being able to be considered stable enough for end user use

<DusXMT>I use it :) (sometimes)

<DusXMT>now I need to go, ttyl

<jxself>Calling it "done" sounds like a lot of work. The computer industry isn't standing still.

<jxself>But it's nice to hope that one day it might be. :)

<jxself>At the same time, though, we have a free kernel already - Linux-libre - so it takes off some of the urgency IMO.

<toxemicsquire4>It is free, but it doesn't feel satisfactory

<jxself>I can imagine. HURD has some interesting technology.

<jxself>But we can get to the goal of free operating system, and that's something. :)

<toxemicsquire4>It is probably the most advanced kernel made up to date

<jxself>Time to me to get to bed though. ZZZzzz...

<toxemicsquire4>Yea me too

<ph4nt0mas>hello guix

<Svetlana>hihi

<civodul>Hello Guix!

<civodul> http://www.gnu.org/software/guix/screenshots/0.8/

<civodul>add yours!

<civodul>alezost: in the package-info buffer, it would be nice to have a "view source" button :-)

<civodul>that would use package-source-derivation, and then drop you in a dired buffer in the source tarball/directory

<alezost>civodul: thanks for the idea! I'll look at it. IIUC the source is available only if a package was built locally, isn't it?

<civodul>alezost: no it's always available; the command-line equivalent is "guix build -S"

<civodul>often it's a tarball, sometimes it's a directory (git checkout, etc.)

<alezost>civodul: oh, great! I didn't know about that

<ph4nt0mas>civodul: after the last git pull, when I do a search with guix package -s something I get http://paste.lisp.org/display/144292

<ph4nt0mas>guix package -i works okay

<civodul>sneek: later tell ph4nt0mas try running "make clean-go && make", to account for the recent ABI change

<sneek>Will do.

*cyril_ managed to talk about Guix while at the OpenStack summit \\o/

<civodul>cyril_: congrats! :-)

<civodul>did they have to stop and repurpose the conference or something?

<cyril_>no, they just made sure I left the premises immediatly

<civodul>:-)

<cyril_>I have a coleague who's got the weirdest system

<cyril_>he's only got a very tiny installation of Gentoo

<civodul>are we colleagues?

<civodul>oh

<cyril_>and every single process is run in a VM

<cyril_>so he's got tons of qemu running

<civodul>blech

<cyril_>but they only take a small amount of CPU

<cyril_>so that was pretty awesome

<civodul>that's both funny and terrible

<cyril_>yes

<civodul>VMs are the outcome of poor OS design

<cyril_>I mean, I don't care, it's just so funny

<civodul>right

<civodul>the "Scratchbox" cross-compilation environment did (does?) funny stuff with emulators

<cyril_>and he said "well, the 'real' system only needs to upgrade qemu"

<civodul>heh

<cyril_>and if another program suffers from a bad upgrade, I can just use a snapshot to "downgrade"

<cyril_>so I told him that the right design was to have rollbacks as part of your package manager

<cyril_>=> Guix :)

<civodul>yay!

<civodul>well done

<cyril_>Lots of people are talking about Docker here, and I'm wondering whether some of the problems it is supposed to solve could not be adressd by Guix as well

<cyril_>though I don't even understand what problems it solves exactly :)

<civodul>it's not completely clear to me, but it seems to be lower-level

<cyril_>yeah

<civodul>however, Docker has hype, which has brought millions of bucks

<cyril_>it seems mostly sysadmin-oriented

<cyril_>or "devops" oriented

<cyril_>since that is the hype word

<civodul>yeah

<cyril_>but it seems to make it "easy" to dsitribute applications

<cyril_>mostly because most people cant use package managers properly :D

<civodul>and it's really the thing where "applications" may well mean "proprietary blob"

<civodul>otherwise, why bother?

<cyril_>hum

<cyril_>yeah, there is that

<cyril_>and well

<cyril_>you know, I'm surrounded by people who "love open-source"

<cyril_>so, no need to argue

<civodul>heh, i can imagine

<cyril_>but also, we have lots of "package managers" that are language-specific

<cyril_>because your application works with these versions of library foo, and these versions of library bar

<cyril_>and since it's a pain to have an up-to-date package manager, yo uend up using pip

<civodul>yeah, it boils down to each community wanting to have more control over the distribution workflow

<civodul>which is understandable

<cyril_>yes

<cyril_>so with docker, you can create an "image" that will "just work" onyour machine

<civodul>yes

<cyril_>though it sucks, because I want to use what my distribution provides

<civodul>sledgehammer

<civodul>it does not compose at all

<cyril_>because I know that Debian/Guix only provide Free Software

<civodul>but it "just works"

<civodul>yeah

<cyril_>but I do not trust other sources

<cyril_>btw, do we have this guix-shell thingy yet ?

<cyril_>or any utility that would allow users to create a new profile and "source" it

<civodul>yes, it's called 'guix environment'

<civodul>it's pretty cool, even :-)

<cyril_>yeah

<cyril_>because in Python, we have those "requirements" files

<cyril_>with a list of requirements and a range of acceptable versions

<cyril_>and we end up creating "virtual environments" that use pip to recreate /usr/lib/python2.7/

<civodul>right

<cyril_>it'd be fun to have a Guix command that does something similar

<civodul>davexunit would know better, but i think 'guix environment' is a reasonable replacement

<cyril_>that is, creating a new profile used for testing the application

<civodul>for virtualenv, i mean

<cyril_>yes

<cyril_>the worst thing is that these "requirements" only specify Python libraries, obviously

<cyril_>so if you need to run a program/library that is not written in Python so that the app works, well, you have to do it manually

<cyril_>but with Guix, you could just specify it and have it installed as well

<iyzsong>hi, any way to get guix environment set a shell prompt?

<civodul>iyzsong: that's what it does by default, if everything goes well

<civodul>just run "guix environment foo", and it starts a shell

<civodul>cyril_: yeah

<civodul>cyril_: npm manages to deal with non-JS dependencies, but it really relies on you having the "right" environment ready, with a C++ compiler and everything

<iyzsong>hm, I use zsh with prompt='%# ' in my .zshrc, after guix environment, the shell prompt remains '% '

<iyzsong>yes, I mean the '$' shell prompt

<civodul>the default is to invoke either $SHELL or /bin/sh

<davexunit>hi iyzsong

<sneek>Welcome back davexunit, you have 3 messages.

<sneek>davexunit, ArneBab says: How do you do the matrix multiplication in sly? It’s something I’d like to try, too.

<sneek>davexunit, lloda` says: https://lists.gnu.org/archive/html/guile-user/2014-10/msg00023.html, I also have the beginnings of a wrapper for BLIS in there now

<sneek>davexunit, lloda` says: however if you do only 4x4 matrices, those calls may have too much overhead. You should try to multiply bigger matrices.

<davexunit>whoa

<davexunit>those are messages from #guile?

<civodul>heheh

<civodul>yes

<civodul>sneek can't tell the difference

<sneek>the, civodul says: difference

<civodul>sneek: botsnack

<sneek>:)

<davexunit>iyzsong: I wrote guix environment.

<davexunit>I can answer some questions you have about it.

<cyril_>civodul: yes, some python packages can also build Python extensions written in C

<civodul>right in time!

<cyril_>but it won't build MySQL for instance :)

<civodul>yeah, of course

<davexunit>you're familiar with nix shell, so maybe you have some improvements in mind :)

<iyzsong>davexunit: yeah, I want to get a different shell prompt to ensure I'm in guix's env :)

<davexunit>iyzsong: yes, I wasn't quite sure how to handle that.

<davexunit>because I want to be shell agnostic

<civodul>i think PS1 is almost portable, no?

<davexunit>oh is it? cool! shows how much I know.

<davexunit>then yes, we should set a special PS1 for guix environment. it would be nice if that could be customized, too.

<iyzsong>I think we should avoid spawning a $SHELL, even with --pure, I still get unwanted env with my zsh.

<iyzsong>look like it read ~/.zshrc

<davexunit>I guess so.

<davexunit>is that a bad thing?

<iyzsong>it's not what I want with pure :)

<davexunit>hmm, how do we prevent such behavior for all shells?

<iyzsong>I see there is --noprofile for bash, maybe we could just use bash for a pure env.

<civodul>iyzsong: does zsh honor $PS1?

<iyzsong>civodul: yes, it does

<civodul>ok, i wasn't completely sure

<civodul>iyzsong: re --noprofile: http://lists.gnu.org/archive/html/guix-devel/2014-10/msg00169.html

<davexunit>it would be a shame to force the pure env to use bash

<civodul>agreed

<civodul>we could allow -E to take a command, instead of a file name

<civodul>like: -E "zsh --whatever-it-takes"

<davexunit>-E already takes any arbitrary command

<davexunit>and it will run that instead of $SHELL or /bin/sh

<iyzsong>oh, that will be great

<civodul>ah ok

<davexunit>so, it's not automagic, but it will get you what you want, I think.

<davexunit>sometimes spawning a shell isn't desired, so -E is there for running one-off scripts in the env and then returning to normal.

<iyzsong>guix environment --pure -E "PS1='@ ' /bin/zsh --no-rcs" gcc

<iyzsong>does the tricks I want, thx!

<davexunit>iyzsong: yay! I'm glad it works for you

<civodul>nice

<davexunit>iyzsong: soon enough, sly will have the equivalent of a default.nix file in the repo, and you'll be able to run `guix environment -l package.scm' to create a dev env

<iyzsong>davexunit: cool!

<davexunit>just need guile-sdl's test suite to pass, and the dependencies will be complete

<iyzsong>davexunit: does the tests need X?

<davexunit>hmm, I wonder if that's part of the problem. I didn't get the chance to investigate much.

<davexunit>I will look into that first when I get a chance to hack on it

<iyzsong>I haven't look into tests, but I do admire guix's attitude for testing.

<davexunit>yeah, we try to have passing test suites as much as possible. if the package has tests, of course.

*iyzsong go sleep, bye!

<davexunit>bye iyzsong!

<davexunit>glad to have you on board the guix train.

<iyzsong>thx :)

<civodul>yay for Sly in Guix :-)

*davexunit needs to settle on some API decisions and prepare a release

<davexunit>I've spent months writing and rewriting scene graph implementations.

<civodul>heh, it must have gotten better :-)

<civodul>i should play with it one of these days

<davexunit>:)

<davexunit>try out a release, when I make one. there will be less rough edges.

<civodul>ok

<davexunit>and a manual.

<davexunit>and it will be easier to try when you can 'guix package -i sly'

<civodul>definitely ;-)

<civodul>would be wonderful if someone updated Mesa

IRC channel logs

2014-11-06.log