IRC channel logs
2016-02-20.log
back to list of logs
<lfam>Slow to push to savannah <lfam>It looks like my cpio CVE fix made it in, but `git push` has still not returned... <nully>i think i'd like to use hydra to test a theory i have about io on that dom0 <lfam>Okay, we'd like to help if we can :) <lfam>I'm not sure who has access to hydra besides mark_weaver, though. <nully>probably a handfull of others if any <lfam>Hooray, we can `guix pull` now! And our users can get binary substitutes built with the fix for the recent glibc vulnerability. Thanks nully! <paroneayea>davexunit: mark_weaver: ^^^ think you'll both find that interesting <davexunit>paroneayea: in response, we are looking for ways to remove qt-4 from our set of maintained packages. <nully>i've been working on this since we first started having issues a few hours back <detrout>how important is it that the bootstrap binaries match what's downloaded? (I was writing a debian recipe and was tempted to replace gnu/packagesbootstrap/$(ARCH}/{bash,mkdir,tar,xz} with symlinks to the outer debian environment <davexunit>using any other bootstrap binaries will mean that you could never use the binaries we provide <detrout>so it takes the hash of the contents of the tar file? <davexunit>changing a bootstrap binary changes the hashes of everything up the chain <detrout>and that hash is part of what goes into the store/....-package name <detrout>i suspected so. but wanted to double check <detrout>Do you assume the /gnu/store has anything initialized in it before you can start using guix commands? <davexunit>the bootstrap binaries will be copied into the store when needed. <detrout>I wonder why linking guile libraries under Debian links to the -dev symlink for libgcrypt <ajgrf>`guix pull` is still serving an old commit without the glibc fix. not sure why, since both the cgit web interface and plain old git seem fine <ajgrf>after running guix pull, no packages need to be upgraded and the file gnu/packages/patches/glibc-CVE-2015-7547.patch doesn't exist <davexunit>that doesn't make sense. 'guix pull' grabs a snapshot of master by default, and master most definitely has that commit. <ajgrf>is there any caching or something going on that hasn't caught up? <davexunit>has anyone else lurking here experienced this? <Jookia>paroneayea: How's MediaGoblin using Guix? Is it for development or deployment or neither or both? <paroneayea>Jookia: presently: neither really (though *I* am starting to use it for development) but in the future: I hope both. <Jookia>Interesting! Would this replace the existing infrastructure you have? I'm not too familiar with Python but I think that's things like virtualenv <paroneayea>I hope Guix will be the *preferred* way to do both but especially publicly development with "guix environment". Privately for myself but encouraging others, I greatly wish to do deployments with Guix and flesh out GuixOps <paroneayea>my switch to usually running GuixSD (though currently I dual boot with Debian) was partly because I want to move to this <paroneayea>I took a summer sabbatical to try to figure out what we can do to solve "the deployment crisis" / pro-userops positions <paroneayea>my conclusion was that Guix was the only really sane way forward! <paroneayea>(and assuming we get grafts, I still believe that's true :)) <paroneayea>Jookia: so yes, also replace virtualenv and bower and things. <paroneayea>we'll probably do bundling (including source alongside) as a stopgap initially then figure out how to get the npm fiasco a bit better <xd1le>i wonder what nix does for js <paroneayea>xd1le: for jquery, they just package the minified js ;p <paroneayea>but yeah we need an npm importer and node builder too <Jookia>I'm sure if we get some JS developers interested the importers will flood in <xd1le>i mean, i would like it, because sometimes i need to use it, but at the same time, i feel like "ugh, it's js" <paroneayea>I feel like "ugh, js" too, but it's needed in this modern world <paroneayea>not having it means we're failing to deliver a lot of used-by-real-people stuff. <xd1le>i'm just talking about personal motivation to do it <xd1le>e.g. i'd likely put in much more effort for a rust build system in guix just because i like the language.. <xd1le>it's in my plans if no one beats me to it <paroneayea>xd1le: having a rust build system would be great! <Jookia>I need to learn Rust, it seems to be the cool thing these days <lfam>davexunit, ajgrf: I'm double-checking the question of `guix pull` not serving master <lfam>Or rather, not serving HEAD of master <lfam>I'm afraid ajgrf is right <lfam>Yes, inspecting ~/.config/guix/latest shows the patch is missing. And when I manually download the snapshot and unpack, the same issue. <lfam>That patch in question is the recent glibc vulnerability patch. I'm not sure exactly *which* commit is being served but it doesn't seem to be current HEAD <xd1le>sneek: later tell Jookia well it's another systems language so not sure if you'd really need it <lfam>koz_: That is probably my #1 wishlist package. We are working on getting Golang into Guix, and then I think there will be a race to package Syncthing :) <koz_>lfam: Oh? So Golang's not Guixed yet? <lfam>No, unfortunately. There are at least two people working on it, and my understanding is that they are most of the way there <lfam>We need people help package more languages :) <koz_>lfam: Well, I'd help, but I only know C, Java and Haskell. <koz_>In roughly *that* order of competence. <koz_>Also - I assume GNOME and KDE are unavailable under Guix because systemd? <lfam>Well, our C support is pretty solid! The irc user rekado is working on an ant build system, which will be very helpful, because java packages are not that easy to package without something to abstract the build system. <koz_>lfam: Oh? I read something in the 'Limitations' section of the manual saying that you don't have full GNOME. <lfam>See the 'elogind' package: the systemd project's "logind" service, extracted out as <lfam>It's a new thing, in the last few weeks <lfam>It's not 100% there, but lots of people are contributing to it <koz_>Well, that's nice to know. <lfam>The online manual is tied to the release, btw. The most up to date version of the manual is in git <koz_>(I mean, once Guix has Syncthing, I'm gonna make the GNUest laptop ever) <koz_>(it'll run Guix SD and try to have as much GNU in its stack as possible) <koz_>(from Libreboot upwards) <lfam>It's really a great project <koz_>Is it actually possible to set up the underlying WM of GNOME without the rest of GNOME? It's kinda slow and heavy for what I wanna do. <koz_>ACTION really wishes there was a GNU i3 equivalent. <lfam>I don't know, I've never used GNOME. But in a couple days I'm gonna launch it in QEMU and try to package their Maps program. It has built-in Open Street Map editing, which I love <koz_>Well, I just want a specifically GNU graphical desktop thingy that doesn't need all the resources. <koz_>And near-as-I-can-tell, there's only GNOME. <koz_>Unless there's something I'm missing. <lfam>One nice thing about Guix is that packaging is really easy. You could trivially make your own GNOME package that inherited from the Guix package <lfam>Somebody is sending tons of MATE packages <lfam>There's XFCE and Ratpoison as well <koz_>lfam: It'll ruin my gimmick. :P <lfam>Potentially some others, I'm not sure. I don't use DEs <koz_>lfam: No graphical environment at all? <lfam>True, GNOME is a GNU project <lfam>Just i3 with the status bar <lfam>I'm really comfortable with it <lfam>I'll probably never change it :) <koz_>I can understand that - I'm on XFCE, but that's just familiarity talking. <koz_>I wanna switch to i3, and since I'm going to have a Libreboot machine, I figure that'd be a good chance. <lfam>Yeah, it doesn't take any resources. But really, the full graphical environment I use is iceweasel <lfam>And that takes a fair amount <koz_>But I *do* want to go with my gimmick as well, so I might just try running 'whatever WM GNOME ticks on' instead, and call it there. <koz_>lfam: Hear you on the Iceweasel thing. It needs to be compiled with PGO to keep that down (it's what they do for their Windows binaries), but that's obviously very time-consuming and impractical. <lfam>It will be an effective gimmick, since you will have what seems to be the most sought-after DE and the best package manager :) <_z>Huh, I thought I remembered there being a #GuixSD. <lfam>I've never been there. I think it's all here on #guix <koz_>lfam: Yeah, it'll be an effective *and awesome* gimmick. <_z>Think I'm mistaking it for #guile <koz_>I can then stick a big sticker of the GNU gnu on it. <koz_>Although realistically, if I'm going full GNU, I should be using Icecat. <lfam>True, I'm currently using Guix on Debian for my workstation <lfam>To be honest I'm not that comfortable with the browser situation. I worry about security <koz_>So what languages *are* supported? I heard Haskell, Python, Ruby and Javascripts were good. <koz_>lfam: I thought they fixed that one instance where version lag gave them a security breach? <swedebugia>I have an idea: buy a couple of c.h.i.p. 7$ arm computers and create a build cluster <koz_>swedebugia: Are distributed builds a thing now? <koz_>The $7 machines you mentioned in a build cluster would only really work if you could distribute the build over them. <koz_>(since I assume we're talking compile-from-source) <koz_>Hence my question - I wasn't aware distributed compilation was a thing. <lfam>I would buy one more expensive computer of the same price as the cluster <lfam>That wouldn't be as cool, though <_z>janneke: guile window manager? <xd1le>yes syncthing is great, guile-wm for gnu i3 <NiAsterisk>oh.. great. I removed xfce with the system rebuild and now I have a lack of symbols in ratpoison. I only know gnome and kde related symbol sets.. what's there I could already use? <sneek>Jookia, xd1le says: well it's another systems language so not sure if you'd really need it <NiAsterisk>that semi-worked. now I have even less symbols in emacs graphical. not that I care, but maybe i just need to log out. <NiAsterisk>hm. how do you log out in rapoison? I never did this before. Didn't even bother with this in awesome-wm (which I hope to get packaged here at some point) <Steap>NiAsterisk: how do you log out of Awesome ? :p <Steap>I've never known how to do that :D <NiAsterisk>write an option in the config to handle that. I htink. been a while since I had a look at my awesome config. <NiAsterisk>I "log out" with "halt" and "restart" currently ;D <vek___>Jookia: can you explain me what is GUIX please? i understand nothing on the net : / <Jookia>vek___: It's an operating system made entirely of free software! <vek___>Jookia: i thought it was a package manager X) <vek___>is it up-to-date? 'cause parabola: server down, trisquel: gnome (geeeee) and gnewsense: ... <vek___>Jookia: well, there is updates for the distribution, weekly or monthly? (sorry, my english is a bit bad : /) <vek___>Jookia: cool, i come from Arch so i'm used to that : ) <vek___>Okay, so Guix is the package manager, and GuixSD the distro'? <vek___>I will download it and try it then : ) <a_e>It would have been good if we had had the occasion to explain the difference between Guix and GuixSD. <Jookia>This is true, though they seemed to grasp it <a_e>We will see when the person comes back :-) <a_e>I just tried to install GuixSD with encrypted root and unencrypted boot and failed... <Jookia>GuixSD is just a package generator for Guix anyway :P <a_e>Because I do not quite know how to do it :-) <a_e>That /boot was apparently not found on reboot. <Jookia>Interesting, what's your configurationf il <a_e>Although I had formatted it with a label and added it to the configuration. <a_e>The same as in petter's instructions, and then I cons-ed another file system with a label and mount point /boot. <a_e>During set-up, I already did not quite understand the order of things. <a_e>I tried to mount the partition to /mnt/boot first, then start cow-store; that failed since /mnt was "busy". <a_e>So I tried the other way round; now I am not quite sure whether anything was actually written to /mnt/boot. <Jookia>Hmm, try the instructions again? <a_e>As far as I could see, the instructions do not cover this case. <a_e>I think we will need to write more documentation still :-) <a_e>And maybe provide example configurations. <a_e>I am trying again without encryption, which is suboptimal. <a_e>But I do not intend to travel with the machine for the time being. <a_e>It is a long process. Each trial reconnects to hydra to download tons of stuff. <vek___>what is the partitionning theme for GuixSD? / with 20GB is enough? <vek___>Jookia, 50GB ??? WoW thats a lot! <vek___>have to go to the shop, i'll be back : D <ajgrf>a_e: the kernel and initramfs aren't kept in /boot, they're in /gnu/store. that's why encrypted root with unencrypted boot doesn't work <Jookia>ajgrf: No code to copy them yet? <ajgrf>nope. the people running encrypted guixsd systems are using libreboot <Jookia>ACTION grumbles and writes down more code he'll have to write <ajgrf>i think grub2 is supposed to support unlocking encrypted partitions, but no guix code has been written for that either (and grub2 might have some bugs at the moment anyway that need fixing first) <Jookia>This won't make my u-boot port easier. Or maybe I'll just ditch it <lfam>Is it possible to get Unicode support in the console (in GuixSD)? <sneek>Welcome back rain1, you have 1 message. <sneek>rain1, a_e says: Did you use a mixer to check that alsa sound is actually turned on? For me it is muted every time I reboot (in Guix on Debian), and I use alsamixer to turn it on again. But things may be different in GuixSD. <janneke>how do i recover from corruption in /gnu/store? <rain1>thanks a_e, sound does work outside the browser just not inside <lfam>janneke: Do you know what happened? <lfam>rain1: I've heard about this problem from other people. We need to figure it out! <rain1>I'll try building firefox from source <Jookia>ajgrf: Do you think code for unencrypted /boot but encrypted disk would be useful <lfam>rain1: It *should* be the same as the substitute :) <lfam>I think we just need someone to see how it works on another distro that's already figured it out <lfam>`guix pull` is still not delivering the glibc fix, AFAICT <paroneayea>Starting download of /gnu/store/hg3692jqq4jmhg4qx8d7y67fspimy898-?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0 <paroneayea> patch 1KiB 857KiB/s 00:00 [####################] 100.0% <paroneayea>output path `/gnu/store/hg3692jqq4jmhg4qx8d7y67fspimy898-?id=3ba68f9e64fa2eb8af22d510437a0c6441feb5e0' should have sha256 hash `1dnlszhc8lihhg801i9sz896mlrgfsjfcz62636prb27k5hmixqz', instead has `0zygncr1z1nswmny2vl1havfqswm40vzj0vjvhf5yndavhzr267j' <paroneayea>ACTION was trying to install guile-minikanren without waiting on hydra (probably the wrong move) and got that error <lfam>Hmm, what happens if you try it again? <lfam>It's _possible_ that the file was corrupted in transit in a way that the download appeared to succeed <rain1>If i created my own rain/packages.scm file, how may I install a package defined in it? I notice -f but that's not exactly what I meant to do <paroneayea>lfam: guix package -i coreutils --no-substitutes <lfam>rain1: Set the environment variable GUIX_PACKAGE_PATH to point to the top of the directory where your packages are. And make sure the "exported" module path equals the directory structures. For example, look at a package in gnu/packages. <lfam>rain1: I export that variable in my shell profile, so I seamlessly have my private packages available to the Guix command line tools <rain1>ooh I'd like to know how to do that! <lfam>paroneayea: Hm, thats seems wrong ;) <lfam>rain1: We recommend bash_profile, which is also recommended by upstream. <lfam>rain1: I finally grokked the difference between login and interactive shells due to this. <lfam>The issue is that .bashrc is sourced when you do `guix environment foo`. So I guess it might be harmless to export GUIX_PACKAGE_PATH in that file, but you definitely don't want to alter something like PATH, because it will pollute the guix environment and introduce non-determinism <lfam>Whereas .bash_profile is only sourced when you login <paroneayea>a missing patch meaning no way to build coreutils seems like an urgent problem <rain1>okay I understand! that seems important <lfam>paroneayea: If their git repo is down, it's not just that patch! <lfam>janneke: Did the `guix gc` repair seem to work? <lfam>I guess it might take a while <janneke>lfam: not fully, some paths were referenced and could not be removed... <lfam>janneke: It might make for an interesting user story email. I've never had to repair my store. <lfam>I'm cloning the coreutils repo to look for the patch <rain1>Here is the error i got when trying to install my own package <rain1>;;; Failed to autoload canonical-package in (gnu packages base) ERROR: no binding `unlicense' in module (guix licenses) <paroneayea>ACTION looks forward to the day when everything in guix is safely mirrored somewhere <paroneayea>rain1: sounds like unlicense needs to be defined <rain1>it might be because my guix version is different to the source code pulled from git?\\ <lfam>paroneayea: You *do* have coreutils in your store, right? You should have the patch locally <rain1>I just have license:x11 in my code <davexunit>I think it would be cool to make archives of official guix releases, where we stash copies of all the source code needed to build the distro so that it could be repeated again far in the future. <lfam>rain1: Are you building against a git checkout, or a `guix pull` system? <rain1>maybe I've done this the wrong way: What I did was pull the guix source code and then craete a new folder rain/ in there and create rain/packages.scm with my package in it <davexunit>would allow for some cool digital archaeology work <lfam>paroneayea: the hash you referenced <3ba68f9e64fa2eb8af22d510437a0c6441feb5e0> *does* exist as a commit in the coreutils git repo <rain1>after I do guix pull where should I put rain/packages.scm ? <lfam>rain1: You can put it anywhere <lfam>And make "where" the value of GUIX_PACKAGE_PATH <rain1>sorry I'm confused! I'll delete the git clone i did. guix pull updates my system but then how would I put the sources into ~/Code say? <lfam>rain1: For example, my GUIX_PACKAGE_PATH is ~/pkgs. The directory structure is ~/pks/lfam/packages. And the package definitions start with '(define-module (lfam packages package-name [...]' <rain1>ah its /home/rain/.config/guix/latest <rain1>so should I put the stuff in there? or make a copy of that? <paroneayea>looks like some fallout from the vcs update stuff <lfam>rain1: ~/Code sounds good <paroneayea>lfam: we could provide the patch ourselves in git master <lfam>We should figure out if it's a transient error or a policy change <lfam>rain1: The important part is that 'lfam/packages' is mirrored in the '(lfam packages' part <lfam>Just like gnu/packages ;) <lfam>I bet everyone in Boston is frolicking in the sun today. Not much motivation to hang out on IRC <paroneayea>lfam: maybe I should emergency push a patch, if you review it <janneke>lfam :wow, that was painless! use gc --referrers, clean and verify! <paroneayea>not being able to build coreutils is kind of a problem <davexunit>the git server issues are probably also responsible for the 'guix pull' issue <fhmgufs>Why should people install packages to their system profile in general? <fhmgufs>I mean packages except from basics and system things. <davexunit>fhmgufs: in general, I don't put packages in the system profile <davexunit>I just put some essentials that I'd like available everywhere in there. <paroneayea>fhmgufs: some things, like stuff to start your xorg daemon, make sense to go there <paroneayea>probably anything with a system-wide service should go there. <fhmgufs>davexunit, paroneayea: That's what I thought. But what are the reasons for putting for example a desktop environment there? <davexunit>fhmgufs: the login manager searches for xsession files in the system profile <davexunit>and desktop environments don't belong to any one user <fhmgufs>davexunit: But different users can install different desktop environments. <fhmgufs>davexunit: I think Guix should provide a way for that. <davexunit>desktop environments are easiest to manage via the system profile <davexunit>where you can easily provide many possible choices <rekado>davexunit: in "guix environment" (when in Emacs shell-mode) "C-c C-c" does not work to abort "guix build" (I think you know that already). However, "C-c C-z" to send SIGSTOP does work. <davexunit>rekado: I'm not sure what's up there. perhaps we need a signal handler that passes the signal onto the subprocess <lfam>Something must be handling the signal already <a_e>ajgrf: Thanks for your explanation on unencrypted boot, encrypted root. <a_e>Petter's doc mentions it as an option, but without giving all the details. <a_e>If so far it is not possible, this is very bad news: It means we cannot encrypt on non-libreboot machines. <a_e>Well, you can always encrypt /home and so on. <a_e>But it would mean keeping every top-level directory except for /gnu in its own partition, a nightmare. <a_e>Since it works on other distros, there must be a way! <phant0mas>I can't be the only one that tried to cross-build something <petter>a_e: i think it should definitely be explained how to do a installation with unencrypted boot. The reason i haven't done it is i don't have such a system to verify the instructions. <lfam>phant0mas: I read it but I didn't have anything intelligent to say. If it fixes a bug I'd say it's worth it, but I really don't understand the issues <rain1>I built a couple trial packages :) thank for you help! <petter>and i don't to write instructions based assumptions :P <lfam>rain1: Feel free to send your patches to the mailing list thought. If they are free software, we'd love to have them <rekado>phant0mas: I don't really understand the message. My (as yet unpublished) cross-compiler for arm-none-eabi seems to work without this patch. <petter>a_e: let me know if you're able to get it working, and i'd be happy to add your notes <lfam>petter, a_e: This week I will start figuring how to install GuixSD in QEMU. That should make it easier to test these things <petter>lfam: aren't these the cases where QEMU is of little help? With different GRUB setups and such. <lfam>I have a GuixSD installation in QEMU, and it boots with GRUB <lfam>I don't see why this couldn't be explored in QEMU and then, once it seems to work, confirmed on bare metal <petter>GRUB can be compiled with different modules, and different systems do. So another system may run into problems anyway. <petter>GRUB as with Libreboot has the necassary crypto modules compiled in. As far as i know this is on the rare side. <lfam>I don't much much about GRUB. Do you mean that the output of Guix's GRUB builder will be different on different machines of the same hardware architecture? <petter>hm, right. I don't have any experience with Guix's GRUB. I'm basing my view on GRUBs embedded in boot firmware. <rain1>I was testing out guix sd with crypto in a VM also <phant0mas>lfam rekado try this ./pre-inst-env guix build -e '((@@(gnu packages cross-base) cross-gcc) "i686-linux-gnu")' on latest master <phant0mas>if it works on your machines then I have an issue here <lfam>phant0mas: Sure. I'm on x86_64 if that makes a difference <lfam>petter: I figured it was (ideally) deterministic, like the rest of Guix <petter>lfam: i'm sidetracking you here. I think what you're talking about don't have these issues. <lfam>petter: You're not sidetracking me! I really don't know anything about GRUB. I'm glad for some feedback. <lfam>Well, we will find out the usefulness of this idea soon, I hope <petter>lfam: i'm talking about GRUBs in boot firmware. That's not relevant in most cases i guess. <petter>Normally the OS installs the boot loader, and this i would expect to be the same whether it's QEMU or BIOS <petter>i have no idea if Guix installs GRUB with crypto modules, anyone here know? <phant0mas>btw has anyone documented somewhere on how to run the daemon without root? <davexunit>phant0mas: not really because it's not well supported right now. <davexunit>losing the isolated builds means that things will probably break <rekado>phant0mas: can't test this right now as I had to garbage collect to make space on my tiny disk. <rain1>what is the favorite 'github' type site? notabug? <rain1>I mean i use the command crypto something in my grub config <rain1>insmod crypto insmod cryptodisk insmod luks then cryptosetup <petter>rain1: have you tried it without the insmods? <rain1>I think that it didn't work without them <petter>with Libreboot these are enabled by default, so these steps aren't required there <rain1>one thing that's a little annoying is i have to type in the crypto password twice <rain1>once for grub and again during boot <petter>yeah, i do that too. I do them with different keyboard layouts for extra fun :) <petter>dvorak in libreboot and qwerty in GuixSD <rain1>I find it so hard to put in the password in dvorak <rain1>all my password entry is qwerty, all the rest of the time dvorak <lfam>There was a time last winter when I couldn't boot my computer, because my hands were too cold to type the encryption passhprase <lfam>So I took a bath and warmed up instead <lfam>That's actually my approach to a lot of problems ;) <lfam>Sorry, classic American too-much-information <rain1>I'm just a little stuck passing a -D option with cmake build system <rain1>by grepping I found an example in gnu/packages/video.scm but it is very complex <rain1>is there a simpler way to just pass in one -D? <lfam>As an argument to cmake? I don't know whether or not cmake-build-system accepts #:make-flags. Have you tried that? <a_e>petter: The computer I am installing with GuixSD is my main work computer. Downtime should be limited to the weekend :-) <a_e>I have an old toy computer, which I could use. <a_e>But then, with hydra being slow, currently "guix system init" takes hours. <lfam>I am soon going to install GuixSD on the computer that is the "brain" of my stereo. Downtime must be extremely limited ;) <lfam>a_e: It's too bad you are pressed for time. It would be useful to use --no-substitutes and then challenge hydra. <lfam>I'll probably do that when I start installing to bare metal <petter>whoa, don't mess with the stereo <lfam>All my other computers are "more important" <lfam>My "beater" computer seems to have really died this time <a_e>Why should I challenge hydra? <lfam>To discover non-reproducible packages so we can try to fix that <a_e>What is the context with crypto? <a_e>By the way, I think all of perl is non-reproducible. <lfam>And the python-2 interpreter <a_e>I noticed it when I pushed perl-shell-command the other day. <lfam>phant0mas: I get the same error <lfam>a_e: There is a bug report for python-3. We need a competent Python programmer (not me) to take a look at it. <a_e>I am not even an incompetent python programmer :-) <lfam>I bet that fixing that bug would make the majority of our python-3 packages reproducible <a_e>In my youth we were making fun of fortran, where whitespace carries semantics. <a_e>So python seemed like an oedipal regression to me. <lfam>Unfortunately, I think python.scm is our most active module <rekado>ACTION builds the latest version of wine <rain1>petter, by the way i have taken notes on installing encrypted guix and if i can help contribute to the documentation i would like to! <phant0mas>lfam: can I push the patch? disabling libitm, libvtv and libsanitizer fixes it <lfam>When did I become an authority figure? ;) <petter>rain1: what instructions did you use when installing? <rain1>someone linked a paste that I think you wrote <lfam>phant0mas: Can you write a follow up email giving some information on the role those packages play, and what the effects of removing them might be? <rain1>that was the main thing I used but I also had to search a little for more information <lfam>That would make it easier to decide what to do <lfam>It's hard to review certain types of patches without context <petter>rain1: what information did you need to find elsewhere? <rekado>lfam: python.scm contains a lot of stuff that for any other language would probably appear in dedicated modules. <rain1>I'll paste my textfile when I can <paroneayea>ACTION has a patch for coreutils, bu tneeds his profile to finish upgrading before he can verify it works :) <rekado>using eww got a lot nicer after making the eww buffers use the tango theme (instead of the dark colour scheme I'm using for other Emacs buffers) <paroneayea>rekado: did you discover the nice feature to set mandatory contrast levels? <lfam>Can I get that in my web browser? <rekado>paroneayea: yeah, I'm using that for rendering HTML-only emails in mu4e. <rekado>some emails are unreadable without this. <a_e>lfam: For instance, I have the following file: <a_e>which starts with the following line: <a_e>=head2 Sat Feb 20 20:14:25 2016: C<Module> L<Shell::Command|Shell::Command> <Steap>doesn't python-2.7-source-date-epoch.patch apply to Python-3.4.3 ? <a_e>I think we have lots of them for our perl packages. <lfam>Steap: It doesn't apply with `patch -p1 < foo`, if that's what you mean <lfam>a_e: We need epochal timestamps! <lfam>Steap: My proposed patch is really quite stupid. I think it can't be right to be importing 'os' and 'locales' where I did. <a_e>Jookia: Do you know if anything special is needed to make the SD card reader work on the Novena? <a_e>I insert my card, and "dmesg" shows nothing. <a_e>I am still on Debian, actually, so this is an off-topic question. <lfam>a_e: What about dmesg post-boot? Does the system see the reader at that time? <a_e>lfam: How do I determine this? <lfam>a_e: Hmm, I bet there's a better way, but I usually just do `dmesg > file` after boot. IME the kernel ring buffer is big enough to still hold the whole thing. <efraim>I normally go for something like dmesg | tail -F <lfam>And then I try to understand what the kernel may call the component I am interested in <Steap>lfam: oh, there is a proposed patch <lfam>Steap: It's by me, based on Ludo's. It doesn't work and I don't know Python well at all <lfam>My patch is in message 14 <a_e>dmesg|tail now gives this: <a_e>sd 3:0:0:0: [sdb] Synchronizing SCSI cache <a_e>sd 3:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=0x00 <lfam>The idea is that if the environment variable SOURCE_DATE_EPOCH is set, the timestamp should take its value, otherwise behave as normal and use the mtime of the source .py file <lfam>That way, our python interpreter will behave as expected when used outside of the Guix build environment <lfam>The same mechanism is used in our python-2 package <Steap>basically, everything seems a bit fucked up :) <Steap>so in os.environ, they do not seem to have strings <Steap>as in "return b'PYTHONCASEOK' in _os.environ" <Steap>so I'd be in favor of trying Ludo's patch <lfam>More or less. I will give it a try. <Steap>yeah if you have everything needed to test that <lfam>The test is to build some python package with --rounds=2 and see if it fails <Steap>oh yeah cuz mtime is going to be different every time <lfam>And it's "not an issue" for the other distros involved in reproducible builds, because they generate the bytecode at "install time" <lfam>But we combine build and install <lfam>I will try your suggestion later today. <rain1> (arguments '(#:make-flags (list "USE_ZEITGEIST=off"))) <rain1>was giving an error about wrong flags <lfam>Can you build "by hand" with those flags? <rain1>I have this nagging feeling I needed more than just that one option to disable it when I did this before <rain1>but I'm not sure how I would do this by hand on guix <rain1>#:configure-flags is promising, but a test failed <rain1>midori: error while loading shared libraries: libmidori-core.so.1: cannot open shared object file: No such file or directory <rain1>building the program also builds this library, I guess I need to set an extra option so that the library is found? maybe LD_LIBRARY_PATH or something <rain1>I don't really know the correct guix way <rain1>the file is in /gnu/store/*midori*/lib64 <rain1>LD_LIBRARY_PATH=/gnu/store/___-midori-0.5.11/lib64 midori <lfam>rain1: To do it by hand with Guix, you would use the `guix environment` tool. It puts all the dependencies and relevant environment variables into your environment. <rain1>how do i recompile my package? <rain1>I tried guix -r it and then guix gc and but -i --no-substitutes is ending right away without compiling it <rain1>there are still server versions of the package there (different hashes), I don't know how to remove them <rain1>output path `/gnu/store/c5hwi8fkwkxk2ldp719nzr6ikymg7vnd-coreutils-tail-inotify-race.patch' should have sha256 hash `1dnlszhc8lihhg801i9sz896mlrgfsjfcz62636prb27k5hmixqz', instead has `0zygncr1z1nswmny2vl1havfqswm40vzj0vjvhf5yndavhzr267j' <lfam>rain1: first question: If you aren't recompiling, then your package definition hasn't changed. <lfam>second: It's a known problem <rain1>I'm changing the package now <rain1>the browser is working, just not tls yet <lfam>rain1: Also, I recommend not using `guix package -i` while testing packages. Instead use `guix build` or `guix environment --ad-hoc` <paroneayea>but I need my system to finish upgrading before I can test...! <rain1>I have a strange problem with glib-networking and gsettings-desktop-schemas <rain1>maybe they should be inputs rather than native-inputs <rain1>I cant get it quite right, oh well <rain1>maybe if someone else cares about midori they could use it as a starting point <Daneel_Olivaw>Hello. I'm trying to install guixsd following the installation manual but I get a backtrace when I try to use guix system init /mnt/etc/config.scm /mnt. About to send a picture. <lfam>Daneel_Olivaw: Can you share the contents of '/mnt/etc/config.scm'? <lfam>Daneel_Olivaw: I suggest making a copy of that file on another machine, because whenever we solve your problem and get you booted, there won't be a copy on the resulting system. And if you do have a copy, then you can share it as text and one of us can try it. It's not that easy to debug <lfam>It's not that easy to debug like this <lfam>It looks okay at first glance, though <a_e>Daneel_Olivaw: Your mount point should not be /mnt, but /. <a_e>It is /mnt just while you mounted the file system when working on it. <a_e>Hydra is terribly slow right now, and the desktop configuration requires a lot of downloads. <a_e>I would first try out the barebones configuration. <a_e>Once guixsd is installed and you can boot, you can switch later. <a_e>But then, do not start from scratch and use "guix system init". <a_e>Boot into the text based guixsd, then do a "guix system reconfigure". <wingo>ACTION grouses about "guix package -u --no-substitutes" vs "guix package --no-substitutes -u" <a_e>wingo: "-u" expects to be followed by a regular expression, unless it is in the last place. <a_e>So guix package -u '.*' --no-substiutes should work. <wingo>i understand that, however "guix package -u --no-substitutes" exits successfully with no message <wingo>i know how it works but the result is not good ui <wingo>-u should not swallow arguments with dashes. <rekado>wingo: I ran into the very same problem today. <wingo>otoh i now have a nicely updated system with working accelerated opengl <lfam>Is `guix pull` serving the fix now? It wasn't as of a few hours ago, IME <wingo>i don't know; i built from git <wingo>i wish that guix gc --list-live could trace only current profiles, not past generations <wingo>ACTION all wishlists today apparently <lfam>We all have that mood. It's a good time to take notes <a_e>I do not have address resolution in GuixSD. Should I have done anything? <a_e>"guix system init" worked fine; when I now try to do "guix system reconfigure" with almost the same configuration, it tries to compile the world. <a_e>So it looks as if the guix I used for "init" is not the same as the one I am using now for "reconfigure". <a_e>i created my own system image today, so that I would start with already the libc security fix. <a_e>My suspicion is that the installation reverts automatically to the latest guix package in guix. <a_e>Yes indeed. That is terrible! <a_e>So I spent all day downloading up-to-date packages from hydra. <a_e>And now my guix command corresponds to an old one. <a_e>Very strange since I already had a modern one. Why is that not used? <davexunit>guix can't have a guix package that is the same version as itself. <a_e>Hm. It was there once. <a_e>The same thing could have been put into the store somewhere. <davexunit>you can't release a version of guix that knows the hash of itself. <a_e>getaddrinfo: Name or service not known. <a_e>Any hash will do. Just put it somewhere. <a_e>My current guix binary is a symlink to somewhere in the store. <a_e>It could be a symlink to somewhere else in the store. <davexunit>a_e: the current running guix could be *anything*, it's not necessarily in the store. <a_e>I could do a "git clone", compile it with an arbitrary prefix and "make install". <a_e>But the currently running guix is not anything modern, but an outdated store package. <davexunit>the guix-devel package could stand to be updated more frequently, this is true. <davexunit>but you should always 'guix pull' or equivalent after installing a new system. <a_e>Anyway, the real problem is that getaddrinfo does not work. <a_e>I have /etc/resolv.conf <a_e>I can ping the nameserver. <a_e>If everybody needs to execute "guix pull" after "guix system init", it should be integrated into the latter command. <a_e>A reboot fixed the name resolution problem. Uff! <a_e>davexunit: I still do not get it why guix cannot know about itself. <davexunit>how could you encode the hash of the guix source code inside the guix source code? <a_e>At the moment I did "guix system init", there was a modern guix on my usb stick, in my path etc. <a_e>So the system init could have copied that somewhere. <a_e>For instance to /gnu/store/xxxxxx-guix <a_e>And then added this directory to the system profile. <a_e>How could I know what? <davexunit>it's basically an extra bootstrap binary now <a_e>The hash does not need to correspond to anything. <a_e>I mean to use "xxxxx" literally. <a_e>Exactly, it would become a bootstrap binary that would be in the same place everywhere. <davexunit>that hash is reserved for base32 encoded sha256 hash values <a_e>With different content everywhere. <a_e>There could be this one exception. Why not? <davexunit>because the guix that is running 'guix system init' may not be a guix on an already running guixsd system <a_e>It would be reproducible, just not by copying the store; it would depend on the installation image. <a_e>When I use the same usb key and do "guix system init" I would end up with the same result. <Jookia>Reproducible implies anyone can reproduce it <a_e>Anyone can by starting with the same usb image. I just followed the manual. <a_e>The next person following the manual will obtain the same result. <Jookia>xxxxx-guix doesn't tell you which USB image <a_e>Indeed. It is not enough to simply copy store items with given hash. <a_e>Well, I am not well versed enough in guixsd, maybe I am wrong here. <a_e>But you must admit that this is a very strange and confusing situation. <a_e>As if I had downloaded an installation image of debian 8; then I install it using content of debian 8; then it tells me it is in reality debian 7 and I need to do a "dist-upgrade" first. <a_e>In reality it is even more twisted. <a_e>The software I currently have on my system (xfce and so on) is from a modern guix. <a_e>But if I do "guix package -i hello", it will take the package from an old guix. <davexunit>the way to improve is to make our guix-devel package in our released images only a commit behind the guix that was used to build the image. <a_e>I think that is what Ludovic actually does for the releases. <a_e>Since I am already whining, I may as well continue :-) <a_e>So I spent half a day for a "guix system init" with an image taken after the libc fix. <a_e>Now the "guix pull" again downloads stuff from hydra (question: what?) <a_e>That can take the night/ <a_e>Since the current snapshot seems to be behind the libc fix, I can start again tomorrow. <a_e>Well, at least then most of the safe packages will already be in the store. <a_e>Maybe I should do a git checkout now instead of "guix pull". <a_e>Not so easy. There is no ssh service, and I cannot do a "guix system reconfigure" to install it. <a_e>Yes, but I would need to reconfigure, no? <a_e>To answer my previous question: "guix pull" downloads the packages needed to compile guix. So not that many. <a_e>davexunit: So if I had not tried to be clever and recreated the installation image, I would have had a better experience. <a_e>Actually like last week when I installed an old machine just for training. 