<quiliro>(sorry for the dvorak mistake with es) <mange>I don't really know where to start debugging that, sorry. :) <quiliro>I could reboot with the guixsd usb and guix system reconfigure config.scm /mnt <quiliro>would that be a good idea after mounting the partition? <mange>I don't think you can give "reconfigure" a target, it just tries to reconfigure the current system. <mange>So you'd be using "init", which should just give you the same outcome as what you currently have. <quiliro>I think what may have caused the problem was i did not run 'herd start cow-store /mnt' <mange>Yep, that would cause some issues. <lfam>It's used by a backup GUI to manage scheduled jobs, so it could go in the backup module. There isn't a cron or scheduler module, surprisingly <lfam>Copenhagen_Bram: I've only tried the other way, but it should 100% <lfam>I mean, it should work 100% <Copenhagen_Bram>When I'm trying to install gentoo and it fails to decrypt the root partition, I start thinking about GuixSD... <reepca-laptop>so I tried to make texlive-latex-base work in test-env by replacing its setting of TEXINPUTS with the configure phase from (guix build texlive-build-system), but alas, when it gets to the (invoke "tex" ...) line it prints the TeX startup line and then immediately exits with status code 1. Anyone more versed with the world of texlive / tex in general have any idea how I should properly be doing this? <reepca-laptop>also rust's check-tidy fails in test-env because any line with a store path is over 100 characters long <apteryx>how can I refer to a path like this from inside a build phase: /tmp/guix-build-emacs-ert-runner-0.7.0-1.90b8fdd.drv-0/source ? <apteryx>I thought maybe (assoc-ref inputs "source"), but this is not the same. <mange>Is it just the working directory? (getcwd)? <reepca>^ yes. The unpack or whatever phase usually puts you in there. Another option is $NIX_BUILD_TOP/source. <rekado>reepca: I can look into this later today. Could you send me your diff? ***krkini is now known as kini
<civodul>rekado: some of the build machine clocks are behind <rekado>civodul: hmm, they are all running ntp <roptat>ha, I think my guixsd machines are a bit ahead of the rest of my machines, could it be that the machines that are behind are not on guixsd? <civodul>rekado: well dunno, and i can't tell which one that was <rekado>hmm, I’ll check the time on all nodes <rekado>the time on all of them looks fine to me <rekado>the time on berlin is ~5mins in the past <rekado>I think the ntp port is blocked at the MDC firewall… <rekado>I manually set the time for now; will open a ticket with IT <roptat>ah, I might have the same issue, my server is 4 minutes in the past <rekado>civodul: BTW, the tunnel to x15 should no longer be needed. IT updated the firewall rules. <apfel>hi there, i installed guix today using the binary tar.xz. I wanted to use guix pull because this is what guix tells me i should do. But i am wondering why first it downloads gcc-4.9.4 as binarys, then gcc-5.5.0 as binarys and after that starts building gcc-5.5.0 from source. Is this normal? If so, why does to documentation say deploying and not building? <apfel>oh im sorry, it did only download the gcc-5.5.0 sources, not the binarys <bgardner>Hello #guix, the docs don't seem to cover nfs beyond the base package - is there a guix-y way to define a client mount? <roptat>apfel, did you allow substitutes? ***jonsger1 is now known as jonsger
<roptat>I don't understand what the modules files that you sent me yesterday represent <rekado>civodul: should we have a project signing key that we can use to sign releases and the installer script? <g_bor>roptat: I believe we do, in openjdk9 there should be one, and also in 10. <apfel>roptat: ok thank you, now i got it <eubarbosa>hey, I must be dumb but I never see calculation: 3(6 -2)(2 -7) <roptat>so, I guess that means "three times (six minus two) times ...", in which case you can write (* 3 (- 6 2) (- 7 2)) <apteryx>is there any better way to rebase newer security patch on older software releases? <apteryx>I've tried cherry-pick, but it wants to bring many changes that aren't in the commit to be cherry-picked <roptat>eubarbosa, the expression is a division of the above term by the below term, right? so you can write (/ (<above term>) (<below term>)), because / is for division and it accepts two arguments: the above and below terms <roptat>then you have to translate each term separately <dongcarl>Hey all, how long does it take for core-updates to be merged into master? mariadb not building messes up a lot of things for me <civodul>rekado: maybe we should have a project key, but i'm not sure how we'd handle it <civodul>the gpg people have such a key, but i think those using it are physically close to one another <bavier>dongcarl: I was planning to push your recent patch to master as soon as I had a chance to test it <dongcarl>Btw, question for you guys: is there a command for me to build a standalone/statically linked tarball for a package so I can distribute to other repos? <bavier>dongcarl: see 'guix pack' in the manual <civodul>cool that you already sent patches, BTW! <dongcarl>But in all seriousness I know the struggles that my predecessors had in terms of producing reproducible binaries for bitcoin <dongcarl>And with Guix I was able to achieve most of it in one weekend <dongcarl>We've got more determinism patches in our repo, which I'll upstream to you guys hopefully soon <dongcarl>Hmmm it seems `guix pack --relocatable` isn't what I want exactly (even tho it is a UBER cool way to distribute a working "chroot"-like environment). I guess specifically what I want is a tarball of the outputs of the `bitcoin-core` package that doesn't depend on anything else at runtime... Like how tarballs usually are on GitHub releases. <rekado>reepca: debugging recommendation for TeX stuff: use “-interaction=scrollmode”. <rekado>reepca: this shows me that it fails because it doesn’t find “hyphen” <rekado>that’s expected because “hyphen” and other things are not in the expected locations. <rekado>all these native-inputs end up in the root of the texlive-union, but we want them to be in “./share/texmf-dist/tex/generic…” <roptat>g_bor, the content of the modules seem to be reproducible, but not the files themselves <roptat>I haven't run diffoscope everything yet though, so I might be wrong <roptat>I think the source for non-determinism here is that the modules files are a container format for .jar files that were not reproducibly built (they include the timestamp of files and might not contain them in a deterministic order) <roptat>so if we could find when that modules file is generated, we could add a bit of code to make the jars reproducible <roptat>if we do it early enough, we might even fix the issue with java.base.jmod too <civodul>dongcarl: it's great you have more determinism patches coming! :-) <roptat>when I say "the files" I mean the result of "jimage extract" <roptat>which extracts the content of jar files recursively <civodul>dongcarl: re 'guix pack', it produces a tarball that contains /gnu/store with all the dependencies, but maybe that's not what you want <g_bor>roptat: thanks for having a look. <roptat>diffoscope is still running, but it shows no difference on some portions of the files <g_bor>I will have a look at the build system, to find where this is done... <roptat>we could also ignore that part of the build system and focus on how jar files are produced, to have them reproducible by default <civodul>dongcarl: so lib*.so embeds a copy of libc, Qt, etc.? <dongcarl>civodul: I believe it's embedded in the binaries themselves, the libbitcoinconsensus.so is just a project extracting out network consensus from the main codebase <civodul>dongcarl: ok; static binaries would also be possible but it requires more work <dongcarl>civodul: I'm guessing I'd just have to make my own package definitions like `bitcoin-core-static` or something? <civodul>and then you probably wouldn't use 'guix pack' at all, but rather a custom snippet that lays out files the right way <janneke>i've been trying the next (sbcl-next) browser and it looks real nice, but i cannot follow links using the keyboard...it freezes; seems related to #182 <g_bor>I guess we are planning for GSoC this year. <g_bor>I am following the discussion on gnu-soc. <g_bor>Our ideas page for this year is not created yet, and the link on the central gnu ideas page points to the 2018 ideas page for guix. <cbaines>Ooh, custom shepherd action support! I thought I saw something about that, but I've only just seen it in use in the mcron service :) <rekado>Copenhagen_Bram: yes, you only need to provide the (kernel …) field in the operating system configuration. <shiranaihito>Copenhagen_Bram "unknown person" or maybe "person i don't know", depending on the context <reepca>g_bor: regarding GSoC, I'm actually continuing working on the daemon rewrite as part of my senior project, so I'm not sure if that should still be on the ideas list. <user_oreloznog>Hi Guix :) Running GuixSD 0.16, I am trying to configure the bootloader to have the choice to boot between GuixSD and Debian. <user_oreloznog>After changing /etc/config.scm several times I currently get the following error: <g_bor>reepca: Ok, I believe then we should remove that. I just wanted to get the ball rolling, no proposals from here yet, besides getting the page up, and the link corrected. <user_oreloznog>config.scm:9:0: error: extraneous file initializers (menu-entries) *vagrantc wishes for the ability to specify a "configfile" entry rather than "linux" entries <bavier>user_oreloznog: you have a parentheses problem. menu-entries should be part of grub-configuration <vagrantc>then you can have a single entry in grub to load the other OS menu... <vagrantc>only issue would be if the guix grub and the debian grub had incompatible modules loaded or soemthing <vagrantc>i think that was one of the feature requests i've never gotten aroudn to filing <user_oreloznog>Hi again :) The last test for dual booting GuixSD/Debian failed by: config.scm:23:20: error: invalid field specifier <civodul>user_oreloznog: on line 23, you're missing a closing paren <civodul>it helps a lot if your editor can highlight matching parens <user_oreloznog>yes i's the case, i only use vim aand it shows it en light colors <stanleyno4>Hello, for a normal user on a hosted guix system, do I need both a export PATH="/home/bmillare/.config/guix/current/bin${PATH:+:}$PATH and an export source "$HOME/.guix-profile/etc/profile" or just one or the other? What's the difference? I see that for me the "bin" on both point to different /gnu/store/... directories <rekado>stanleyno4: “.config/guix/current” is a separate profile only for Guix. <rekado>whenever you run “guix pull” that profile is updated. <rekado>this ensures that you can always go back to an older version of Guix itself <rekado>~/.guix-profile on the other hand is the location where Guix installs your software by default. <rekado>whenever you run “guix package -i” or “guix package -m” ~/.guix-profile gets updated. <stanleyno4>hmm, so should I include both in my path? it suggests I add .config/guix/current/bin to my path after doing git pull <rekado>in the end everything ends up pointing to some place in /gnu/store, but these places aren’t equal :) <rekado>yes, you should have .config/guix/current/bin *first* in your PATH. <rekado>that’s for the “guix” command itself. *rekado thinks about moving from mu4e back to notmuch… <bgardner>Hello #guix, the docs don't seem to cover nfs beyond the base package - is there a guix-y way to define an nfs client mount? <rekado>bgardner: I don’t think it needs any special setup. <rekado>there’s no autofs service, unfortunately. <rekado>but for fixed nfs mounts you just need to specify that the mount type is nfs. <bgardner>rekado: I tried, but nothing I put for 'device' seems edible to 'guix system reconfigure' <user_oreloznog>Hmm ... I added the missing parenthed but I still get the same kind of error: config.scm:17:0: error: invalid field specifier <rekado>I used to have an nfs mount in my sys config. I used type "cifs" and specified (device "//the-host/the-share/node") as the device. <rekado>user_oreloznog: (target "/dev/sda"))) has one closing paren too many. <stanleyno4>is there a development version of emacs maintained on guix? How do I stay up to date on the dev emacs? <rekado>the “target” expression should be inside “grub-configuration” <bgardner>rekado: No joy: "error: device '//host.domain/sharename' not found: No such file or directory" <rekado>bgardner: did you also specify (title 'device)? <bgardner>rekado: I did not, let me go read the docs <bgardner>rekado: Same error, but now with a bonus: "warning: 'title' field is deprecated" <rekado>well, I haven’t used this file system declaration in a long time. <civodul>bgardner: i'm not sure 'file-system' declarations work for NFS <rekado>yes, it worked for me some months ago <civodul>oh right, (gnu build file-systems) supports it <bgardner>rekado: No worries, thanks for the attempted help - just giving the feedback. The GuixSD docs explicitly say "don't modify things in /etc/" so I was just trying to work out how to mount NFS without doing that. Maybe that's still a future change. <civodul>bgardner: you have to make sure to specify (type "nfs") or (type "nfs4"), etc. <bgardner>civodul: I did that, same error "no such device", unless the syntax for device is something I'm not guessing properly <bgardner>civodul: Like I said, since the docs don't mention it maybe it'll be along later, I watch for it <rekado>hmm, using the elpa importer I get: ERROR: Wrong type to apply: #<syntax-transformer nix-server-version> <rekado>(guess I’ll need to recompile…?) <civodul>comes from commit de9fbe9cdcf5f8deb08becfc54b523084fd67bda <civodul>you can probably rebuild just a few files <rekado>oh no! “no code for module (guix build utils)” ***slyfox_ is now known as slyfox
<pkill9>out of curiosity, does anyone use wayland in guix? <pkill9>i've been testing weston in guix, it's pretty nice, i could run xonotic in it and it played smoothly <civodul>pkill9: Rutger who does most of the work in that area probably does :-) 