***hopses is now known as hospes
***hopses is now known as hospes
*davexunit really hope the static guile he builds does the right thing so he doesn't have to wait through the build again <sneek>davexunit, you have 1 message. <sneek>davexunit, civodul says: thumbs up for 'guix environment --container'! <davexunit>my idea for the above ^ is that I will ask the not-yet-built container daemon to spawn a new container with $PWD and /gnu/store bind mounted in. <davexunit>and then the command passed with -E will be run as PID 1 <davexunit>this way we'll be able to quickly make environments that are very similar to what guix-daemon is creating. <davexunit>and then I suppose in the glorious future when guix-daemon uses pure guile they will be unified. <mdln>My GuixSD install went smoothly! :D <ewemoa>still not much luck jumping to symbol defs -- as an interim work-around, in the guix src dir: find . -type f -iname "*.scm" | etags - seems to lead to a somewhat useful TAGS file <ewemoa>civodul: i haven't tried that -- will test <ewemoa>civodul: that is nice for finding a package definition -- tnx! -- what i've been looking for is a quick way to get to defs of things such as wrap-program, substitute*, and the like though <amz3>if jump to def doesn't work, M-x rgrep can be help <amz3>I've added (global-set-key (kbd "C-x C-r") 'rgrep) to .emacs <ewemoa>amz3: i have been using grep and friends but find having to look through results tiring :) <amz3>look at the bright side, you get a glimpse of some other code :) <civodul>ewemoa: if you use Emacs, Geiser is the best thing <ewemoa>he he -- it's true that i appreciate not finding an answer immediately -- there is definitely value to the "extra" stuff one ends up seeing while searching <civodul>alternately you could try GNU GLOBAL <ewemoa>civodul: i use emacs, but i haven't gotten geiser's jumping to def to work it seems <ewemoa>i tried gnu global but it dies unfortunately <civodul>Geiser can only jump to files that have been compiled in the inferior guile process <civodul>so you first need to C-c C-k a bunch of files <ewemoa>yes -- it seems so, yet, i have failed to get that to work so far <ewemoa>at least find-tag is working with the tags table for the moment -- thanks any way :) <amz3>I did a script to generate a dot file, I tested it with rekado qsynth, but the output of my program and the output of guix package -n -i qsynth is different <amz3>my output is missing ruby <amz3>www.hyperdev.fr/_drafts/guix-dependencies-in-sigmajs/graphitisay.scm <amz3>I will update it to work with sigmajs this afternoon <amz3>ewemoa: what are you hacking on guix? <ewemoa>amz3: i am just packaging various things and trying to learn some internals <civodul>amz3: nice! that's actually more readable that i expected <civodul>the good thing is that you used the package level rather than the derivation level <amz3>some package are missing, like ruby. maybe-create-edge might be buggy <civodul>i think that's because it's an implicit input <civodul>so it's never explicitly listed in the 'inputs' fields of packages <civodul>the up side is that the graph is more concise <civodul>the downsize is that it's less accurate <amz3>it was in the graph before I introduce maybe-create-edge <civodul>well dunno, it didn't look at the code <civodul>actually we could have three levels of details: packages, bags, and derivations <civodul>the last one is too much for graphviz to hanlde <rekado>why does Qt need to have postgresql and mysql as inputs? <rekado>I wonder if it would be possible to split Qt. <ewemoa>it's secretly trying to become systemd <civodul>well GTK+ also depends on CUPS, for its printing dialog <rekado>what bothers me about this is that I think I *know* what parts of Qt qsynth doesn't use. <rekado>it's unfortunate that it "depends" on so many unused things. <rekado>pulseaudio for example. Qsynth is just a frontend. The audio part is handled by fluidsynth, which uses alsa or JACK. <rekado>It's frustrating to read mailing list discussions about Qt packaging. <civodul>rekado: does that means that solving the bundling problem is hard? <rekado>it means that upstream doesn't think it's much of a problem. <rekado>"I understand that you have certain policies, but the reality out there is <rekado>that a certain level of pragmatism is required if you want to get a usable <civodul>rekado: we should probably just remove QtWebEngine for now, as Fedora does <davexunit>civodul: my 'clone' syscall procedure seems to have an issue. I can't successfully call 'waitpid' on the pid that it returns to the parent process. <civodul>clone(2) says it returns the "thread ID of the child process" <davexunit>need to figure out the new process id somehow... <civodul>well i don't know if it really is different <civodul>davexunit: ignore what i wrote: the example in clone(2) treats the return value as a pid ***hopses is now known as hospes
<davexunit>civodul: I just checked and it does return a valid pid <davexunit>I pk'd the pid had the container process sleep for awhile <civodul>and still waitpid fails with ECHILD? <davexunit>hmm, does it's special status as PID 1 in a new PID namespace change things? <davexunit>I must be missing something in my clone implementation <davexunit>thanks for helping me see the obvious, civodul. <davexunit>time for "real work" now, but I'm going to dig into making interactive container processes next. <davexunit>docker containers by day, guix containers by night. <davexunit>sudo guix environment --ad-hoc --pure --container guile -E "guile -c '(sleep 5)'" <civodul>--totally-pure could be an alias for --pure --container <davexunit>I don't know if this is the greatest idea, but to make things "just work", I bind-mound $PWD as /env within the container <davexunit>so that someone can just run it from the root of a source tree <davexunit>actually, --container makes --pure redundant in some ways <davexunit>--container should imply pure, because the current environment variables don't really apply to the container process <davexunit>currently using phusion's "350 line my_init system" at work, I want to rip it out and put dmd in its place. <civodul>davexunit: but by default the environment variables are inherited by the child process <davexunit>civodul: yeah, but this doesn't make sense for a container. we ought to cleanse the environment first. <davexunit>having $HOME/.guix-profile/bin on $PATH within the container doesn't make much sense. <davexunit>civodul: we're pleased to announce the release of UnknownDistro 0.8.3 <cehteh>HowTo "Portable Programmers with a crowbar" <civodul>i find it hard to believe that such a "high-profile" project has this kind of hacks <cehteh>i just was amazed that this pastebin has a nice brace/parens highlighting ... but then .. ohno its a lisp pastebin :)) <paron_remote>I'm thinking in a month or two I might want to get a gluglug x200 while that's still possible and dual boot with guixsd and debian on it <paron_remote>I have an x220 but I feel like I can't trust it ever since I learned about intel amt <paron_remote>my roommate already uses an ipad so I doubt she has the same level of paranoia :) <Mikko->ugh, got hit by kernel panic after install ~.~ <civodul>we need a web service that builds an OS config and boots it in the browser <civodul>Mikko-: for your root file system, you have (device "/dev/sda1") (title 'label) <civodul>the 'title' should be changed to 'device <civodul>Mikko-: so that was a kernel panic, not a Guile prompt? <civodul>something's fishy, normally one would get a prompt <Mikko->didn't see a prompt, probably should've smashed the keyboard :S <civodul>instead of reinstalling, you can also edit the GRUB line and modify the --root argument <anthk_>paron_remote, I think I'll try to yse coreboot <paron_remote>anthk_: good idea, though not sure why you're pinging me about it :) <anthk_>you made me rethink about intel's remote spying <paron_remote>anthk_: ah... I think the problem is that even installing coreboot might not disable AMT :( <anthk_>sometimes my screen turns itself on at night, over 60 minutos, idk if it's an isse with DPMS or... <anthk_>Mikko-, idk, but it's scary, it flashes for 1-2 seconds, and then it turns off <mark_weaver>paron_remote: yes, coreboot normally includes the AMT blob. <mark_weaver>at present, we don't know how to make an X220 work without AMT. <mark_weaver>the folks on #libreboot can tell you more about this. <fchmmr>paron_remote, if you're going Intel, get an X200 <fchmmr>X220 will never be supported in libreboot. <fchmmr>Libreboot is focussing on AMD and ARM now. <fchmmr>AMD's heading in a bad direction too. I'm doing what little I can to try to persuade them not to. <fchmmr>AMD always lags behind Intel, though. <paron_remote>we're going to have little choice soon but for hackers to figure out how to get more deeply involved in hardware hacking <fchmmr>Fortunately, this also applies to going proprietary. <fchmmr>They've taken longer than Intel to get worse. <fchmmr>And unlike Intel, have actually tried to be nice. <fchmmr>Right now, AMD can still be influenced. <paron_remote>it's too bad. Intel at least had free graphics drivers for a while there <fchmmr>Especially since the company is in serious trouble. <fchmmr>AMD will literally do anything to make more money. <fchmmr>That means they can be swayed by us, potentially. <fchmmr>We just need to demonstrate that respecting user freedom is profitable (it actually is. I know this for a fact). <paron_remote>it's tough to prove that free software users are much of an economic force <fchmmr>We're a force to be reckoned with (not in all areas, but in many we are). <mark_weaver>it could be one of the few ways that they can distinguish themselves in a positive way compared to intel at this point. <fchmmr>ISPs, hosting providers, sysadmins, etc. <Mikko->no dice, I think it failed at mounting the filesystem ***schjetne` is now known as schjetne
***init is now known as exio4
***exio4 is now known as init
***hopses is now known as hospes
<davexunit>rekado: I've been meaning to see how we can split that up <davexunit>now we can run 'guix size' on it and see what's up! <davexunit>containerscontainerscontainerscontainerscontainers 
