<lfam>I looked at some packages to jog my memory and, yes, propagated-inputs seem right. Because, Go "packages" as we conceive of them are basically a bunch of source trees, since dependencies are bundled-by-default
<lfam>I see one that propagates pkg-config... maybe that should be adjusted
***terpri_ is now known as terpri
<Jdaco>Hello, I haven't been able to do a guix pull for a few weeks now. When I try I get a "error: corrupt input while restoring archive". https://pastebin.com/VTJ9Ur0k. Does anyone know how to resolve this?
<lfam>Jdaco: I think this is a bug we fixed a week or two ago
<lfam>Since the bug causes downloads to fail, you'll have to try and try again until it completes, or add the --fallback option
<lfam>After it completes, you need to restart the guix-daemon
<Jdaco>It fails even with --fallback. You're saying if I try over and over that it will eventually go through?
<lfam>I was afraid of that. This type of failure is not considered "fallback-able" in the code
<apteryx>OK; I'll see how far I can get through generating an RC
<apteryx>lfam: by the way, any reason we release this as 1.2.1 rather than 1.3.0? I'm sure we've added functionality since the last release (I have to go through the release notes, but the go importer is one on top of my head)
<lfam>I don't remember where the actual number came from
<lfam>If I had to come up with a reason, it would be that we haven't done a core-updates cycle since the last release
<lfam>But I don't have a strong opinion about the number
<apteryx>I'm trying to understand the origin of the wip-next-release branch; it was branched off master when?
<lfam>apteryx: Like, when did the branch first exist? Or what's the history of the commits that landed on master?
<lfam>It didn't really use a branching workflow. It was just a few commits that kept being rebased on master until they were done
<apteryx>OK! This was done as the ungrafting efforts, correct?
<davidl>Hi, Im trying to optionally include #:environment-variables <service-config-option> to the make-fork-constructor in the mysql service. My attempts so far (many) fails. Is there an example somewhere I can look at?
<cbaines>davidl, what environment variables are you trying to optionally set?
<cbaines>davidl, ah, wrong symbols in my example, it should be #~(string-append
<yoctocell>civodul: I can use 'git verify-tag --raw TAG' to try to verify a tag, and the output it produces is the same as running 'gpgv --status-fd=1 SIG FILE' which 'gnupg-verify' does in (guix gnupg).
<yoctocell>'gnupg-verify' has a 'status-line->sexp' procedure which parses the status, maybe we could move that procedure to the toplevel and create a 'git-verify-tag' procedure which will use it?
<civodul>yoctocell: ideally, you would use update-cached-checkout from (guix git) to fetch stuff, and then Guile-Git and (guix openpgp) to verify signatures (you still need (guix gnupg) to fetch keys)
<yoctocell>civodul: Looking at Guile-Git, there doesn't seem to be a way to get the signature of a tag.
<civodul>yoctocell: see commit-signing-key in (guix git-authenticate)
<cbaines>davidl, right, have you got a #$ that's not within a #~ ? maybe share the value you're using again
<civodul>we could probably make the ungexp error clearer
<yoctocell>civodul: Why would a keyring be difficult to get? Won't 'current-keyring' in (guix gnupg) get it?
***rekado_ is now known as rekado
<davidl>cbaines: I mean this works, now Im back to one of the old errors that in /var/lib/log_error.log (configured in my.cnf), the galera service just stops abruptly after herd start galera. https://paste.debian.net/1193056/
<cbaines>davidl, I don't know anything about galera, but maybe look at the #:log-file option to make-forkexec-constructor, as that might help gather more information
<yoctocell>oh wait, it needs a <openpgp-keyring> record...
<jlicht>Is it me, or are there several emails on guix-devel that are missing In-Reply-To?
<roptat>just pushed korean now at 100% (-1 string)
<nij>:O some people do use guix to manage emacs packages.. i just can't imagine how.
<roptat>in general though, you can have B and C on your system (profile), because guix doesn't put A on your profile with them
<roptat>B and C refer to A1 and A2 with their full paths which are different
<roptat>I don't use emacs, so I have no idea, maybe someone else will know
<nij>Ay! After turning off legacy boot it seems working (so far!) nicely pulling down stuff ;) Thanks roptat
<apteryx>nij: yeah, Emacs doesn't support multiple versions of a package in the same EMACSLOADPATH; Guix can't do much about it. What you can do is setup different profiles with different versions of Emacs and or its packages.
<nij>Hmm.. running `guix pull` in root returns the error: Git error: the SSL certificate is invalid.
<roptat>do you have nss-certs in your system profile? and is GIT_SSL_CAINFO set?
<roptat>it should be set to GIT_SSL_CAINFO=/etc/ssl/certs/ca-certificates.crt, and the file should exist
<la_snesne>wow, I didn't knew korean translation has been done. Its nice to hear, but it's quality looks bad to me(e.g Trasnlating free software to free price software, transaction to connection..) And even made my few translation worse. Maybe i should spend my time to fix those thing.
<nij>I probably go through the manual for a few times.. but I never remember them, and cannot remember where they are located :-(
<nij>I come back to guix this time trying to install "from scratch" ;)
<roptat>well, you managed to do it, so congratulations :)
<roptat>la_snesne, ping me when you're done, I'll update the website (countrary to other translations, it doesn't commit directly to the repo because it could break things, and we don't want to give commit access to an external tool)
<nij>How to let /dev/sdaX to be mounted automatically in config.scm?
<davidl>cbaines: I found the error now! I had accidentally switched to :user mysql instead of :user galera in the test module's make-forkexec-constructor procedure. Now Im just running a final test, then Ill submit a patch
<constfun>Hello. It appears I have the same issue as this user when trying to configure xmonad: https://issues.guix.gnu.org/issue/47335 and get 'module import XMonad not found' xmonad works similar to dwm in that it recompiles the config file. I don't think xmonad doesn't recompile the binary, but only the config file which it then loads dynamically. I don't
<nij>Yeah.. I remember there's a hack in the mail group that works with this.. am still trying it
***bonz060_ is now known as bonz060
***iyzsong- is now known as iyzsong
<lubrito>cbaines hi, how do I get to Compare Derivations page through my local server? I can't find it.
<cbaines>lubrito, I'd suggest finding a link from the package derivations comparison page.
<cbaines>So look at the revisions for the master branch, and click Compare, then click Compare package derivations
<lubrito>i tried, but i got this error: wrong-type-arg
<lubrito>string-splitWrong type argument in position ~A (expecting ~A): ~S1string#f#f
<cbaines>there might not be any package derivation changes between those two revisions, so you might need to try a few different revision comparisons until you find one that works
<cbaines>lubrito, also, does the following path work for you locally? /compare/derivation?base_derivation=/gnu/store/kjpvrv5xwwb4g0f8zsj8z40b85fapvqz-perl-net-patricia-1.22.drv&target_derivation=/gnu/store/wq5p9jyvdwhwvqigh7rz3l2wshmkg3l0-perl-net-patricia-1.22.drv
<lfam>`git describe --candidate 1` from that commit gives `v1.2.0-75109-g94f0312546`, which is perfect
<eriklovlie>when iterating on a new package definition that has a lengthy compilation step, what's the usual way to speed that up? ccache? or perhaps just making a branch in the source repo and hack the makefile to produce some dummy files? Anything more clever (i.e. easier)?
<eriklovlie>or I could add the dummy files in the package definition (since it's just guile after all)
<lfam>Depending on what you're trying to iterate on, you could build the package with the --keep-failed option, and then go to the build directory, source the environment variables file, and attempt whatever you want to try "by hand"
<lfam>The execution environment won't be identical to what exists in the Guix build container, but it's similar
<eriklovlie>yes, I found that section in the manual, and that is super helpful to debug the actual build. However now the build works but my guile doesn't :p
<eriklovlie>but I can have this kludge temporarily in the package definition I guess:
<eriklovlie>(eh, well, pastebin error... anyway, (modify-phases blabla copy some mocked files from my home dir to the source dir to pretend the build completed)
<marusich>cbaines, the guix-build-coordinator built successfully on my powerpc64le-linux machine!
<marusich>I'm not sure what the next steps are. I think it would be nice to set up my machine to automatically build things. It doesn't have to be part of the build farm, though.
<nckx>nij: Not your main issue, but to set a larger console font, you can use ‘setfont sun12x22’ (that's an ugly one, but it's short and easy to remember :) More fonts in /run/current-system/profile/share/consolefonts/.
<nckx>Well, they're used by default, where used means that they're ‘present’ for Xorg to load them if it thinks it needs to. So unless you're overriding the default you shouldn't need to care. Can you share your system configuration file?
<nckx>As is tradition I will now go AFK after asking a question :) But I'll return.
<nij>Lemme see.. this time I used the barebone template.. so perhaps it's really missing.
<nij>How do I share a file in a bare console :O...
<lfam>We are going to make a new release next week. It would be great to fix problems...
<BlackMug>oh thats great, would be happy to see improvements fixing manual installation i have already opened tickets about that
<lfam>I advise you to share your config.scm in the bug report. Otherwise, it's unlikely anyone will try to reproduce the bug
<lfam>You should also include the output of `guix describe`
<BlackMug>ok just normally i copy thing from the config or special commands needed to generate a report about the machine
<BlackMug>in qubes for example simple command will generate a report about the machine info, not sure if something similar available for guix
<nckx>nij: OK, I'll build it here. You should remove ‘xorg-server xf86-input-libinput xf86-video-fbdev xf86-video-nouveau’ (perhaps also xinit) from your packages, though. They are at best useless there, at worst they complicate or even break things.
<nij>nckx: thanks for helping out!! I will give a try :)
<lfam>BlackMug: Well, that is what `guix describe` is. Along with config.scm, it should be enough to reproduce your system
<nckx>BlackMug: The two things lfam listed are that.
<lfam>"You should do A and B". "No, I prefer to do B and A"
<lfam>We should advertise `guix describe and config.scm` more prominently, somehow
<lfam>It's a nice feature of software "forges" that you can make templates for bug reports
<nij>nckx: o i see, my zsh didn't have that by default
<lfam>It doesn't seem like many people were using Guix on armhf, since there have been hardly any complaints. And there's no powerful armv7 hardware coming in the future...
<lfam>I'd say the platform is dead for a build-from-source distro
<vagrantc>yeah, i managed to get Guix System installed on an apm mustang (8-cores, 16GB of ram), which is also 32-bit capable, and i'm running some 32-bit virtual machines for debian's reproducible build infrastructure on the same hardware
<vagrantc>i *think* the synquacer *might* be a purchaseable newish option that can do 32-bit
<nckx>nij: It surprises some people but ‘startx’ and similar on Guix is not something that's well-supported at all. It's not the baseline low-risk try-this it is elsewhere. Now I'm a lot less surprised you're seeing weird bugs.
<cbaines>marusich, the easy way of doing that would be to connect to an existing coordinator instance, maybe my test one at guix.cbaines.net or the one now running on bayfront? You could also run your own coordinator instance, but that would require additional work
<lfam>Like, I'm not sure if the Honeycomb's networking is supported at all on linux-libre, but I'm still interested in acquiring them as build machines. We really only need the CPU and storage to work out of the box
<marusich>cbaines, would an existing coordinator instance build things for powerpc64le-linux?
<lfam>Do you have any idea about that cbaines? If any of the ethernet ports on the Honeycomb will work with linux-libre?
<cbaines>marusich, it's just a matter of submitting those builds, which isn't that hard
<marusich>I know basically nothing about the guix build coordinator. What should I read first to get an idea of what to do? How do you "submit those builds"?
<cbaines>lfam, nope, no idea, I still haven't had any news, but hopefully I'll be able to find that out at some point
<cbaines>marusich, the Guix Build Coordinator pairs nicely with the Guix Data Service, which can provide information and substitutes for derivations, and there's an included script to submit builds from a Guix Data Service instance, so it looks something like: guix-build-coordinator-queue-builds-from-guix-data-service --system=x86_64-linux --system=i686-linux --system=aarch64-linux --system=armhf-linux --system=i586-gnu ...
<cbaines>doing builds for powerpc is just a matter of adding --system=powerpc64le-linux
<vagrantc>lfam: i've also heard good things about macchiatobin, so i'd say go for it, fwiw :)