IRC channel logs


back to list of 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:
<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
<civodul>Hello Guix!
<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
<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
<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?
<cyril_>and every single process is run in a VM
<cyril_>so he's got tons of qemu running
<cyril_>but they only take a small amount of CPU
<cyril_>so that was pretty awesome
<civodul>that's both funny and terrible
<civodul>VMs are the outcome of poor OS design
<cyril_>I mean, I don't care, it's just so funny
<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"
<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>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
<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
<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_>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_>so with docker, you can create an "image" that will "just work" onyour machine
<cyril_>though it sucks, because I want to use what my distribution provides
<civodul>it does not compose at all
<cyril_>because I know that Debian/Guix only provide Free Software
<civodul>but it "just works"
<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_>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/
<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_>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:, 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>those are messages from #guile?
<civodul>sneek can't tell the difference
<sneek>the, civodul says: difference
<civodul>sneek: botsnack
<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:
<davexunit>it would be a shame to force the pure env to use bash
<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
<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>try out a release, when I make one. there will be less rough edges.
<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