IRC channel logs


back to list of logs

<quiliro>'guix pull' ehño bhydcbi!
<quiliro>'guix pull' does nothing!
<quiliro>(sorry for the dvorak mistake with es)
<mange>That's unusual.
<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>Howdy! Any advice about which module to put this package in?
<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
<Copenhagen_Bram>how well does nix work on GuixSD?
<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?
<reepca-laptop>rekado: I couldn't figure out how to get magit's patch-formatting to operate on a specific file that's only staged, so here's a plain old diff:
<civodul>Hello Guix!
***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?
<roptat>actually, behind
<civodul>rekado: well dunno, and i can't tell which one that was
<civodul>that's the reason for the red crosses at
<rekado>hmm, I’ll check the time on all nodes
<rekado>the time on all of them looks fine to me
<rekado>heh, except for berlin itstelf!
<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
<civodul>heh, cool, thanks!
<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.
<civodul>rekado: yay! \o/
<civodul>i've removed the tunnel
<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?
<roptat>(step 7 here:
<g_bor>hello guix!
***jonsger1 is now known as jonsger
<roptat>hi g_bor
<roptat>I don't understand what the modules files that you sent me yesterday represent
<g_bor>hello roptat!
<g_bor>I've found this:
<roptat>so do we have a jimage?
<rekado>civodul: should we have a project signing key that we can use to sign releases and the installer script?
<rekado>or should we have a keyring…?
<g_bor>roptat: I believe we do, in openjdk9 there should be one, and also in 10.
<g_bor>I will have a look...
<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)
<eubarbosa>how to get a value from this?
<roptat>what's that?
<eubarbosa>sicp exercise 1.2
<roptat>so, I guess that means "three times (six minus two) times ...", in which case you can write (* 3 (- 6 2) (- 7 2))
<roptat>is that what you want to know?
<apteryx>is there any better way to rebase newer security patch on older software releases?
<eubarbosa>screenshot of that exercises
<apteryx>I've tried cherry-pick, but it wants to bring many changes that aren't in the commit to be cherry-picked
<apteryx>(maybe because of conflicts)
<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
<eubarbosa>oh, thanks!
<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>we'd need to ask for advice
<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>bavier: Ah cool! Thanks.
<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
*dongcarl is thankful
<civodul>dongcarl: 'guix pack --relocatable' might be useful to you:
<civodul>cool that you already sent patches, BTW!
<dongcarl>civodul: Not as cool as Guix :-)
<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>So it's great!
<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.
<g_bor>Nice findings.
<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
<dongcarl>civodul: Yeah not sure what to do, here's what our tarballs usually look like:
<g_bor>I will have to go now.
<g_bor>See you later!
<roptat>see you :)
<civodul>dongcarl: so lib*.so embeds a copy of libc, Qt, etc.?
<dongcarl>civodul: I believe it's embedded in the binaries themselves, the is just a project extracting out network consensus from the main codebase
<quiliro>hello guixters
<civodul>hi quiliro!
<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
<quiliro>hi again
<user_oreloznog>hi o/
<janneke>i've been trying the next (sbcl-next) browser and it looks real nice, but i cannot follow links using the freezes; seems related to #182
<g_bor>hello guix!
<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 :)
<Copenhagen_Bram>Is it possible to reconfigure the kernel in GuixSD?
<rekado>Copenhagen_Bram: yes, you only need to provide the (kernel …) field in the operating system configuration.
<Copenhagen_Bram>shiranaihito: nice username, what does it mean?
<shiranaihito>Copenhagen_Bram "unknown person" or maybe "person i don't know", depending on the context
<Copenhagen_Bram>oh hmm
<Copenhagen_Bram>i was once trying to learn japanese
<shiranaihito>oh? :) well, you can go for it again if you want to
<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>My config:
<user_oreloznog>config.scm:9:0: error: extraneous file initializers (menu-entries)
<user_oreloznog>From now on, no idea what I could do
*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...
<user_oreloznog>bavier: ok, I see :)
<user_oreloznog>vagrantc: OK :)
<user_oreloznog>I will make a try
<rekado>vagrantc: that would be lovely.
<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
<user_oreloznog>Here's the config:
<user_oreloznog>No more idea than the previous time...
<civodul>hi user_oreloznog
<civodul>user_oreloznog: on line 23, you're missing a closing paren
<user_oreloznog>hi civodul
<civodul>the indentation is misleading
<user_oreloznog>Ah :) I am going to have a look now
<user_oreloznog>Scheme is very new for me, but I like it
<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
<civodul>perfect then :-)
<user_oreloznog>thanks Ludo :)
<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.
<rekado>so yes, you do need both.
<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>*guix pull
<stanleyno4>*guix pull I mean
<rekado>yes, you should have .config/guix/current/bin *first* in your PATH.
<rekado>that’s for the “guix” command itself.
<stanleyno4>ok got it
*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?
<bgardner>And/or autofs for nfs.
<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
<user_oreloznog>my config:
<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.
<bgardner>rekado: I'll try it, thank you
<rekado>user_oreloznog: (target "/dev/sda"))) has one closing paren too many.
<rekado>the indentation makes me dizzy.
<stanleyno4>is there a development version of emacs maintained on guix? How do I stay up to date on the dev emacs?
<user_oreloznog>rekado: Ah, I will have a look
<user_oreloznog>Yes, indentation from a noob :)
<rekado>the “target” expression should be inside “grub-configuration”
<user_oreloznog>OK... I"ll have a look too...
<bgardner>rekado: No joy: "error: device '//host.domain/sharename' not found: No such file or directory"
<user_oreloznog>rekado: thanks :)
<rekado>bgardner: did you also specify (title 'device)?
<bgardner>rekado: I did not, let me go read the docs
<civodul>rekado: "title" is gone! :-)
<civodul>so it's 'device by default
<bgardner>rekado: Within file-system, right?
<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
<civodul>rekado: have you tried that before?
<rekado>yes, it worked for me some months ago
<civodul>oh ok
<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
<civodul>hmm, then i don't know
<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>rekado: yup, time for a rebuild!
<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
<civodul>rekado: :-(
<civodul>info-dir.drv again?
<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 :-)
*civodul -> zZz