<sankey>i should have pinged lfam before they parted
<mark_weaver>sankey: I can tell you one way to do it, but maybe not the best way.
<mark_weaver>sankey: guix environment <package-name>, then in the spawned shell look at the first component of $PATH to determine the generated profile (/gnu/store/...-profile), and then pass that to: guix package -p <profile> -I
<mark_weaver>surely it could be done more elegantly in scheme code
<mark_weaver>which I guess would involve lowering the package to a bag object and querying its inputs
<mark_weaver>sapientech: the relevant error is almost certainly this: clone(child_stack=0x3cfc126eff0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x3cfc126f9d0, tls=0x3cfc126f700, child_tidptr=0x3cfc126f9d0) = 7893
<mark_weaver>futex(0x3cfc126f9d0, FUTEX_WAIT, 7893, NULLOpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x000003cfa9000000, 2555904, 1) failed; error='Operation not permitted' (errno=1)
<mark_weaver>sapientech: did you pass -f to strace? that might be useful here.
<sapientech>mark_weaver: lfam i figured out the issue: its due to my grsec kernel
<mark_weaver>since the last operation was a clone, maybe something interesting is happening in the child
<sapientech>doeesn't matter if there were errors, though since it failes before compilation
<mark_weaver>sapientech: btw, there were two minor problems with your latest kivy patch: the sha256 field of the release version of kivy is wrong. it's the same hash as the one from the git repo. and the other is the same indentation issue with keywords that I raised in an earlier revision of the patch.
<mark_weaver>in my example code, I used the correct hashes, but that didn't get propagated to your copy, I guess.
<sapientech>mark_weaver: thanks for letting me know, surprised the build didn't complain about the hash?
<lfam>Since you already had the old source in your store, Guix didn't need to check the URL
<mark_weaver>sapientech: if your store already contains an entry with that hash, then it's considered "cached", and it just accepts it.
<sapientech>okay, let me double check the indentation stuff, because i thought i fixed that
<mark_weaver>actually, it's a fairly common mistake for people to use an incorrect URL, because they used "guix download" to get the source, which adds it to their store, and then a mistake in the 'source' field won't be noticed later by them as long as the hash matches
<mark_weaver>in 'python-kivy', #:phases should be lined up under #:tests?
<mark_weaver>the mail program needs to deduce it somehow. the usual way is if you have your locale set to a UTF-8 locale, programs should generally guess that files are UTF-8 encoded and label them properly.
<mark_weaver>sapientech: are you able to look at the raw email that you sent?
<mark_weaver>yep, that's it. that's an old glibc-locales package. unfortunately, due to glibc not maintaining compatibility for locale data between versions of glibc, programs linked with glibc 2.23 cannot use locales generated for 2.22
<mark_weaver>sapientech: what is the output of ./pre-inst-env guix package -A glibc-locales
<sapientech>mark_weaver: thats actually what i was thinking, since now that we updated, the regular guix has an error since it used the old locale
<mark_weaver>hmm, well, we have a nice solution to this issue for GuixSD users, an easy way to ask for both 2.22 and 2.23 locale data, but I'm not sure what the _easy_ way is for non-GuixSD users, although I can certainly make it work in various ways.
<mark_weaver>although the *best* thing would be to upgrade all packages in your profiles to use glibc-2.23
<mark_weaver>sapientech: so we should upgrade the 'guix' that is in your path. how did you install that 'guix' to your $PATH ?
<mark_weaver>did you use our binary installer, or something else?
<mark_weaver>sapientech: okay, if you followed those directions, then you made a symlink /usr/local/bin/guix pointing to the 'guix' in 'root's profile, so it would be good to update that profile.
<mark_weaver>and that requires that root's guix is up-to-date, which can be done with other 'guix pull' or by running guix via ./pre-inst-env
<mark_weaver>so I would run this as root: ./pre-inst-env guix package -u
<mark_weaver>you should end up with guix-0.11.0 or newer (likely 0.11.0-1.4420)
<sapientech>mark_weaver: interesting, so using package -u will also upgrade guix?
<mark_weaver>if you're familiar with Debian, "guix pull" (or git pull, if you're running out of a git checkout via ./pre-inst-env) is roughly analogous to "apt-get update", although it only updates the set of package descriptions for that one user instead of system-wide.
<mark_weaver>"guix package -u" on the other hand is roughly analogous to "apt-get upgrade", except again it only upgrades packages for the user who runs it, not system-wide.
<sapientech>thanks, error: directory `/var/guix/profiles/per-user/sapientech' is not owned by you btw
<sapientech>after running ./pre-inst-env guix package -u as root
<mark_weaver>the USER or LOGNAME environment variables must have been set to "sapientech". I'm unusual in that I don't use sudo, but you must take care that those variables are set to root in order to update root's profile.
<mark_weaver>sapientech: looks like the claws-mail utf-8 encoding problem is fixed! \\o/
<mark_weaver>sapientech: ah, one more thing I forgot, but if you don't mind I'll just fix it myself: the commit log doesn't follow the GNU changelog conventions.
<sapientech>mark_weaver: is it the extra * ? git did that automatically so i wasn't sure
<mark_weaver>that's part of the problem, and the more serious one, but the other issue is that when the list of items within parentheses wraps, each line gets its own pair of parens instead of just one at the top and one at the bottom.
<mark_weaver>(we are much pickier about commit logs than most projects)
<mark_weaver>see section 6.8.2 (Style of Change Logs" in the GNU coding standards
<ng0>can we do something like modprobe fuse in build environment? I skipped the configure phase and ran into the same problem other packagers and myself had with tup iself, where fusermount needs to be suid.
<ng0>would I break something in the build env if I did a theoretical system* "/bin/modprobe" "fuse" ?
<ng0>it happens in some of the linux.scm packages.. it should work.
<myglc2>janneke: Thanks. The reason I ask: my WIFI is so congested that (iTerm/OSX/ssh) <-WIFI-> (sshd/'emacs -nw'/GuixSD/server) is to jumpy to use. So I use a physical LAN. But Mosh should fix that, right?
<janneke>myglc2: depending on the jumpiness you encounter...
<janneke>mosh keeps the `connection' in tact, no matter what happens
<myglc2>janneke: the jumpyness is mostly unacceptable or irrebular delay in keystroke echo
<joshuaBPMan_>Hello, I'm dual booting guix with parabola. I'm running parabola now. Right now, I can boot into guix, but I can't log in.
<joshuaBPMan_>What might I be able to do to get around this? I can always boot up from my usb stick. But I'm not sure how to run "guix reconfigure", so that it reconfigures the guix installed on my harddrive
<joshuaBPMan_>bavier. I'm actually not sure. I believe I've logged in as root before and set up an account for myself. I belive I've even logged in as a normal user before.
<joshuaBPMan_>My real problem, is that in order to test if I can login as root, is that I'd have to restart. Boot into guix (the one on my harddrive), then try to login as root.
<mark_weaver>joshuaBPMan_: after "guix system init", typically the passwords for the non-root users is not yet set.
<joshuaBPMan_>ok. Sweet. I'll try that now and get back to you guys. Thanks for the speedy response ya'll!
<joshuaBPMan_>hello again! I was on here just a few minutes ago. And I was able to successfully login on guix SD via root via the command line.
<joshuaBPMan_>BUT when I tried to login as my normal user, (with the correct password at least I think), it didn't work. The error it gave me was it was unable to CD into /home/joshua. and I think I know why.
<joshuaBPMan_>I am trying to dual boot guixSD and parabola and have both share the same home directory.
<joshuaBPMan_>both have the user "joshua". BUT on parabola "joshua"'s UID is 2000.
<joshuaBPMan_>I tried to make my guix user's UID 2000 with usermod -u 2000 joshua
<joshuaBPMan_>but apparently guixSD doesn't have the usermod command at least by default.
<ng0>I wonder how this can be fixed upstream. I'm just testing this new phase, the original build system is one we can not use.
<ng0>(replace 'build (lambda _ (zero? (system* "make" "simple")) (substitute* "make.sh" (("/bin/sh") (which "sh"))) (zero? (system* "make.sh")))) and the last system* does not fing the make.sh , which was just generated with make simple. make1.sh is generated and deleted, and make.sh exists when I look at the failed builed
<paroneayea>are you getting goblinoid packaged for guix????? :D :D :D
<ng0>bavier: the thing is, the build system is tup. halosghost can not afford to maintain 2 buildsystems. I packaged tup only to realize it does not work for us, but tup generate works, so make simple makes use of this: https://ptpb.pw/HVM9 (the patch i am testing)
<ng0>in case everything is broken i have the manual instructions, but i prefer to help the dev to get a generic buildphase for this upstream
<rekado>ng0: what do you mean “tup … does not work for us”?
<ng0>https://ptpb.pw/2X1p <- failing result. well tup in general requires fuse to be loaded. this is impossible currently or ever for guix
<rekado>cmhobbs: we have other importers, too, but I’m less familiar with them.
<cmhobbs>languages i can start working with little effort are: ruby, common lisp, guile, and shell scripting. i have a dozen other languages under my belt but i'd need to dredge up ancient memories for things like C, golang, perl, python, etc.
<rekado>R stuff is among the sanest software out there. Packaging most of it is a breeze.
<ng0>cpan importer can end up being time consuming.. perl dependencies and dependencies of them
<wgreenhouse>does the installation liveusb have the needed bits to use usb for networking during installation?
<rekado>wgreenhouse: I don’t have an android device, but tethering with my broken webos device always just worked. It appears as a network device and then you can do the usual “ip link set <dev> up”, “dhclient <dev>”
<catonano>rekado: recently I was reading an artcle by Ludo about this new neat fold over xml trees. It mentioned the necessity to pass around an accumulator in which information from every passage got, ehm , accumulated. It's wild guess but; could it be related ?
<rekado>the way I implemented the stream-less version is as a fold.
<rekado>with streams every element must be “fully formed” right away.
<rekado>I cannot just evaluate the whole thing and then reorder elements.
<rekado>I also need to make sure that it makes sense as a linear stream, but actually package dependencies are graphs.
<rekado>to linearise the graph I’d do a depth-first traversal, accumulating a list of imported packages to make sure there are no loops.
<rekado>but this requires too much plumbing and makes the import procedure signature a lot uglier, in my opinion.
<catonano>yes, I have inspected Jlicht code for npm and I understand it was borrowed from yours
<lime_>I'm getting a lot of 'unbound variable: Make session' errors
<rekado>lime_: do you have gnutls + Guile bindings installed?
<lfam>You downloaded the installer from <ftp://alpha.gnu.org/gnu/guix/guixsd-usb-install-0.11.0.x86_64-linux.xz>, right? And it was correctly signed with the following key? 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5
<lfam>When you are up and running again, I want to make sure you are reaching our "substitutes" server correctly. If you can't download the binary substitutes that you need, that could cause you to build many things from source
<lfam>And I want to make sure that you are requesting the substitutes that correspond to the 0.11.0 release (that's what checking the .drv hash is about)
<lfam>I can't imagine why you'd end up requesting some other substitutes, but I recently saw somebody debug the Arch Linux Guix package and discover that it's subtly broken in a way that requires its users to build literally everything from source
<lfam>So that's why I checked that you downloaded the installer from our server and not some 3rd party