<davexunit>finally figured out why you can't C-c in 'guix environment'
<davexunit>we've been using the 'system' syscall, and the man page for 'system' says that SIGINT is ignored.
<jmarciano>yesterday, I have seen new guix behavior, it asked me to set PATH to: /var/guix/profiles/per-user/admin/guix-profile/bin and not like usually to: .guix-profile/bin, and X, or startx programs were installed in /var/guix.... and are not available in ~/.guix-profile/bin -- so something looks wrong
<jmarciano>like: guix package -I | grep xorg, shows xorg-server as installed in my profile. But it is not in ~/.guix-profile/bin
<jmarciano>just installed package evince, and is not installed in .guix-profile/bin
<jmarciano>I have removed .guix-profile and by hand, linked: ln -s /var/guix/profiles/per-user/admin/guix-profile .guix-profile, now I have the programs. But something failed, I should not be doing it by hand.
<jmarciano>which package to install to get cc c compiler?
<alezost>jmarciano: this is horrible: this project doesn't use a proper GNU Build System; instead it uses its own "./configure.sh" script which includes "./configure.inc" file which has this line for example: <ac_default_path="/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin"> I'm afraid this is just the beginning of problems. I think it may become really difficult to make a package for this program
<rekado>jmarciano: the .guix-profile-X-link things are links to particular generations of the profile.
<alezost>jmarciano: I don't think there is a policy to not use forks, the original sources are probably preferable though. Anyway fork/original source would be discussed in the mailing list when a patch is sent
<alezost>mkoenig: might be, no one have ever reported such a problem with the image
<jlicht>what would be the proper procedure for packaging two modules, lets call them A and B, with A having a depency on module B, when the latest release of B has a problem which prevents it from being built, but the current git version of B (as of yesterday) has fixed this problem?
<fhmgufs>Does the GuixSD installation image include utilities for wireless network access?
<fhmgufs>I tried to make an image mounted at /mnt for installing it later, but Guix fails to install GRUB on it.
<kristofer>you could hypothetically dd the resulting image to a hard disk assuming the system configuration works on the resulting machine.. a disk-image doesnt use the file-systems declaration though, so i dont think it would be bootable
<fhmgufs>I'm back now and still need a solution for my problem: I can only connect to the internet using wireless a connection. Because of that I either need to create an image on my old operating system (it's the same computer) that can be dd'd later using a live system or be able to etablish a wireless connection using the installer. How can I do this or that? I'm not interested in breaking my system because it's the only one I've access to at the moment.
<davexunit>fhmgufs: you can use 'guix archive --export' to export some working wireless tools
<paroneayea>I admit I feel quietly thrilled with the discussion of using Guile as a system to bootstrap other languages, if that's really a sane and feasible direction, and if it means more language implementations sitting on top of Guile
<paroneayea>I'm not sure I feel it's likely to happen? but I really like the idea :)
<jlicht>I just finished my first two packages for guix (yay). One was simply a dependency of the other, so should I send the two patches in one mail to guix-devel? Or is one thread per patch preferred?
<paroneayea>jlicht: send two mails, see the [PATCH 1/6] type emails people send on list as reference
<mark_weaver>paroneayea: for purposes of my larger goal of minimizing our bootstrap, a C compiler on top of Guile is not quite sufficient, because a C compiler is needed to build Guile itself and several of its dependencies. rather, I'd like either a simple C compiler or maybe even just a C _evaluator_ written in something like portable R5RS scheme
<paroneayea>davexunit: will my extremetuxracer be even more extreme with these new patches???
<mark_weaver>the idea being that perhaps later, we'd use a much simpler scheme implementation running on bare metal to bootstrap the GNU toolchain and then later Guile itself.
<mark_weaver>however, this restriction would only be useful for languages needed to bootstrap Guile.
<paroneayea>mark_weaver: so if we had that, *then* we could build all the other languages on top of guile? ;)
<mark_weaver>for other things that we want to bootstrap like GHC, Rust, Go, or MIT/GNU Scheme, that are not needed to bootstrap Guile, I see no reason not to make use of full Guile for their implementations.
<mark_weaver>well, there are several independent projects here that would fit together. e.g. the C evaluator in a simple portable scheme is one project, the compilers built on top of Guile are other projects
<jlicht>paroneayea: but what exactly would these Guile-based bootstrappers need to support? I assume you would not want to implement and maintain X full-featured compilers, where X++ for every new bootstrapping compiler added to the system
<Digit>listening to library libreplanet talk again, mentioning the virtues and advantages of running tails in libraries, thinking it'd be nice to see a live secure tails-alike for libraries based on guixsd
***Guest20523 is now known as eek
<mark_weaver>and then the implementation of Scheme that runs on bare metal and can be bootstrapped from a tiny, easily auditable bit of machine code, is another project.
***eek is now known as eeq
<paroneayea>jlicht: I think mark_weaver just replied appropriately to your question
***Basstard1 is now known as Basstard`
<jlicht>maybe my confusion is not really confusion at all then, but just me being dizzy from how large of an effort this seems to be ;)
<mark_weaver>my immediate concern is bootstrapping the GNU system itself without relying on a huge amount (too large to audit) amount of pre-existing binaries.
<mark_weaver>jlicht: are you familiar with the "trusting trust" attack?
<fhmgufs>Is it normal that the disk image is using ext4? Will my PC be able to boot from it?
<mark_weaver>i.e. viruses that can exist only in the object code of the OS or assembler or compiler, which propagate themselves without existing in the source code at all?
<rekado>ran out of space again because I only use a fraction of my disk for the store. The rest is a big LVM partition.
<jlicht>paroneayea: Of course! How usable is the documentation of the compiler tower for someone who does not have any significant experience with hacking on compilers?
<rekado>can't just shrink that and resize the plain partition without moving the partition around.
<rekado>so, what is needed to get LVM boot support?
<rekado>re compilers: I'm working on porting Yale Haskell to Guile. But it's an interpreter only, not a compiler.
<mark_weaver>fhmgufs: my knowledge on this is not fresh enough to be able to reliably tell you. I'd probably have to play around a bit. but I think the basic idea is to go to the GRUB command line by typing 'c' from the menu, and then "set root=(" and hit TAB to get a list of grub devices and pick the USB device, and then using the "configfile" command to load the grub.cfg on the USB drive.
<paroneayea>jlicht: so, what I will say is that reading up on Guile's compiler tower was my entry way into an interest in compilers
<paroneayea>the documentation is readable enough for someone who knows nothing of compilers, and you can get the idea of it even if you don't understand it
<paroneayea>and from there I went on to read The Little Schemer (you build an interpreter in the end of the book) and then read and watched the Structure and Interpretation of Computer Programs lectures
<mark_weaver>for the last few years I've run Libreboot, which includes GRUB and its own grub.cfg burned into the boot flash, and it contains an easy menu item to find other devices with grub.cfg and to load them, so my knowledge on doing it manually is a bit rusty.
<paroneayea>I've also contributed to Hy a bit but only in the simplest ways, and that's only vaguely a compiler type thing
<mark_weaver>(also, I haven't had to install GuixSD from scratch in a long time)
<paroneayea>jlicht: I havne't really made any substantial compiler contributions but
<paroneayea>jlicht: so if you're interested in exploring these directions, I can say that the compiler tower docs won't get you far enough along to do anything, but there's some paths towards discovering compiler things
<paroneayea>which seem fairly in parallel with other Guile peoples' experiences
<paroneayea>jlicht: not sure if useful or not. there you go though!
<paroneayea>or maybe that all fell on deaf-disconnected ears anyway :)
<mark_weaver>rekado: the scheme code that runs in the initramfs to boot guix, starting with loading the modules and mounting the root FS, is 'boot-system' in gnu/build/linux-boot.scm. also see 'mount-root-file-system' in there. I guess that's the code that would need to be modified to cope with the root partition being on LVM.
<mark_weaver>also note that the root device is communicated to the initramfs by means of the --root kernel command line option, which is put in the grub.cfg. for an LVM device, I'm not sure what that string would be, or if it would be enough. more option(s) could be added for LVM-on-root systems, if necessary.
<mark_weaver>note that the kernel apparently ignores command line options it doesn't understand, and our initramfs finds them using (linux-command-line) and 'find-long-option' in the 'boot-system' procedure.
<eeq>Yes, I saw that ... wanted to use qemu directly, but was scared off by how much manual work it meant.
<eeq>I'm not queasy; if it is an approachable task, I'd try qemu.
<eeq>Anyway, the GuixSD experience on VirtualBox does show it up against other installers ...
<mark_weaver>eeq: if you want to try GuixSD in a VM, I would install Guix using the "binary install" method on your existing system, use it to run "guix pull" and then "guix system vm", which creates not only the image but a little shell script to launch qemu with the right arguments.
<mark_weaver>eeq: out of curiosity, what problem(s) did you run into?
<eeq>OK. I can do that on my main box, copy over the image & the script to my laptop & run qemu.
<eeq>0) I had to manually type into zile in tty0, whatever I read in tty1. That terminal mouse daemon (gpm) working in the installer would help.
<eeq>1) I copied the typical desktop configuration, replacing "xfce ratpoison" with "enlightenment"; before VirtualBox crashed on the installer, it had downloaded ... 830MB of packages! Glaring things were stuff like httpd & WIndowMaker being downloaded!
<eeq>2) Of course, the downloaded stuff was there in /mnt/tmp/guix-*/ ... when I re-ran the installer, it started download WindowMaker again!
<eeq>As an aside ... how do you guys maintain motivation to get all this done & talk about it too?
<mark_weaver>regarding (1), windowmaker is a hardcoded dependency of our default 'slim-service' configuration. that should probably be fixed at some point.
<eeq>I have been using Free Software as much as possible for 15 years ... I'm a software developer, and haven't yet contributed in any real sense so far (beyond evangelizing FS to people I know, maybe 1 or 2 converts)
<mark_weaver>the only package I see that depends on httpd is libsoup, but I gues that should only be needed at compile time, maybe to test it.
<mark_weaver>one issue that's biting current installs is that I suspect the binary substitutes for 0.9.0 have been garbage collected, and so you may end up needing to build a lot of stuff from source, which is a serious problem indeed.
<mark_weaver>I think we failed to arrange for that not to happen, and in the past our releases were frequent enough that it didn't come up.
<Acou_Bass>it snot necessarily something you have to specifically shop for
<Acou_Bass>obviously its something you have to look out for, but its not like there are 500 laptops running proprietary chips then one running a free one... probably half of the ones on the shelf in your local best buy will work
<eeq>I live in India ... there is a store in north-western India that does stock assorted libre H/W, but nothing as powerful as a mainstream PC board.
<Acou_Bass>i live in the UK and have not yet come aross any computer that cant run off linux-libre
<Acou_Bass>obviously some of them dont run quite as well as they would with eg. a proprietary gfx driver, but they boot and they work
<eeq>Since it is a board driving my TV, I'd want the graphics to work as well as they could ... GFX and wireless (WiFi/cell radios) seem to be the least free.
<mark_weaver>rekado: regarding root-on-LVM support, it occurs to me that our GRUB configuration might also need some tweaking, since the kernels and initrds are in /gnu/store and must be loaded by GRUB.
<mark_weaver>I know that GRUB has LVM support, but maybe some other commands need to be run first, dunno.
<lfam>Digit: See `guix system vm` as a starting point for a locked-down reproducible operating system. It gives you a QEMU image with an immutable file system. You could mount stateful directories in RAM and reboot for each library guest.
<lfam>You'd need to find some way to feed entropy to the system, however. Currently one must play the piano for a while to make it boot
<lfam>We need to promote the `guix system` QEMU tools more
<lfam>So many people are coming to IRC with problems in VirtualBox, even though we have a working virtualization system *built in*
<kristofer>so I'm kind of struggling here. I can build guile-wm in a guix environment, but since slim-service isn't "inside" the environment, it can't find the necessary modules to load up the window manager
<kyleschmidt>I'm running the binary installation on linux mint. Can anyone recall how long this step took: `~root/.guix-profile/bin/guix-daemon --build-users-group=guixbuild`
<lfam>kyleschmidt: That's a daemon, it never returns
<kristofer>it's a daemon, so that command will never terminate..