<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 <sankey>i ended up doing it a very inelegant way :) <davexunit>inside an environment, the value of the GUIX_ENVIRONMENT environment variable contains the profile <mark_weaver>davexunit: ah, that's a great help! so this should be easily doable in one command then.. <lfam>sankey: I don't remember exactly how I made that list. I probably piped `guix graph` through cut and uniq. A "rough" way to do it, for sure <davexunit>mark_weaver: it's a recent, but convenient, addition. <davexunit>I was going to implement but never got around to it so ludovic did it :) <sankey>guix graph blah | grep grep grep <mark_weaver>guix environment <package> -- sh -c 'guix package -p "$GUIX_ENVIRONMENT" -I' <sapientech>using icedtea, getting an insuffient memory for java runtime environment, wondering if there this issue is related to the way icedtea is packaged? <sapientech>online, it says that i simply have to many applications open, which is definitely not the case <mark_weaver>sapientech: how much virtual memory is available on your machine? <sapientech>mark_weaver: i installed icedtea, but when using javac from icedtea:jdk, im getting this issue <sapientech>ive used in the past on same computer, and never came across the issue <lfam>sapientech: Which version of icedtea? <lfam>sapientech: I can test it locally. Can you point me to a "hello world" example to use? <mark_weaver>sapientech: maybe running it within 'strace' will reveal some clues? <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>i rebooted into a fallback kernel, and things are working <sapientech>also i forgot how to java, so dont use my example :) <lfam>Yes, the example didn't work for me :) <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? <sapientech>ugh, i seriously need to get you a correct patch :/ <mark_weaver>also, the attachment still lacks a 'charset' field in its content-type header, so the copyright symbols are still coming through wrong <sapientech>is that something you set in the file, or after you attach it? <sapientech>im using claws mail, and after attaching it, i specified utf-8 encoding <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>if you look at your most recent email on this thread, you'll see these mime headers for your inline text: <mark_weaver>so there's a 'charset' declaration in there, which is good. <mark_weaver>Content-Disposition: attachment; filename=python-kivy.patch <mark_weaver>in an earlier email you sent, after you tried to fix it the first time, these were the mime headers of your inline text: <mark_weaver>and that "charset=UTF-8" bit in the Content-Type header is what you need to somehow add to the attachment mime headers <mark_weaver>(try running 'locale' to see the values of the relevant environment variables) <sapientech>also note im on arch, but i installed claws from guix, and each time i install something with guix i get failed to set locale errors <mark_weaver>sapientech: ah, that may be it. do you have GUIX_LOCPATH set? See section 2.6.1 (Locales) of the Guix manual <mark_weaver>more generally see section 2.6 (Application Setup) for issues and solutions when running Guix on top of another system. <mark_weaver>I could easily believe that this is the cause of the problem <mark_weaver>guix failed to set the locale, and probably claws-mail did as well. it likely ended up in the C locale, which means ASCII-only <sapientech>mark_weaver: yes ive had GUIX_LOCPATH set since the beginning <sapientech>what it says in the manual $HOME/.guix-profile/lib/locale <mark_weaver>and you have glibc-locales (or glibc-utf8-locales) installed in that profile? <mark_weaver>sapientech: if "guix --help" prints an error about locales, can you show me the strace output while running that command? <mark_weaver>(I wonder if it's a problem to have both locale packages installed in the same profile) <sapientech>oh oops, did read your question clearly, it did not print an error about locales <sapientech>okay interesting, when i do ./pre-inst-env guix --help, i get a message about locales <mark_weaver>and the first 100 lines might not be sufficient to reach the part where the locale is set, dunno. <mark_weaver>oh, interesting. so maybe that guix is using the guile from arch? <mark_weaver>(from the same directory where ./pre-inst-env guix --help fails to set the locale) <sapientech>mark_weaver: it is using the guile from gnu/store, not from arch :/ <mark_weaver>sapientech: and GUIX_LOCPATH is set properly in the environment where ./guix-inst-env guix --help failed to set the locale? <mark_weaver>if so, then yes, I'd like to see the strace. the relevant part of the strace output will be shortly before you see the error message printed <mark_weaver>it should be trying to open files in /home/??/.guix-profile/lib/locale <sapientech>the environment should be the same yeah? as long as i didn't do guix environment... <mark_weaver>sapientech: you can find out by running "echo $GUIX_LOCPATH" in the same shell where ./pre-inst-env guix --help failed to set the locale <mark_weaver>hmm, I wonder if your installed locales are from a different version of glibc than the one linked to the guile referenced in guix's shebang line <sapientech>got to run, but i finished up the patch and will send it over when i get back <mark_weaver>(that strace output is tracing bash, btw. you need to run ./pre-inst-env strace guix --help, not strace ./pre-inst-env guix --help) <sapientech>one thing i was thinking would be a great guix hook in emacs would be to integrate guix environment with projectile projects <sapientech>so when i run a projectile project, it runs in an environment i set up specifically for the project <mark_weaver>sapientech: looks like your glibc-locales package is old. <mark_weaver>sapientech: can you tell me what directories are in /home/sapientech/.guix-profile/lib/locale/ ? <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 <mark_weaver>and you should also remove glibc-utf8-locales if you're going to keep glibc-locales <mark_weaver>if you run guix out of a git checkout (which I recommend), then there's no need to ever run guix pull <mark_weaver>sapientech: what is the output of ./pre-inst-env guix package -A glibc-locales <mark_weaver>and what is the output of ./pre-inst-env guix package -I glibc-locales <mark_weaver>sapientech: does /home/sapientech/.guix-profile/lib/locale/2.23 now exist? <mark_weaver>if so, and it's still failing, please send me a new strace output for ./pre-inst-env guix --help <mark_weaver>note that you need to run it like this: ./pre-inst-env strace guix --help <mark_weaver>so that strace will be run on guix, and not on ./pre-inst-env which is just a shell script <mark_weaver>and ./pre-inst-env guix --help still reports failure to set the locale? <sapientech>mark_weaver: wow very strange, ./pre-inst-env does not , but just guix --help does <mark_weaver>that's a different guix, and one that I'm guessing uses guile from your host OS. <sapientech>#!/gnu/store/b1yqjimbdh5bf9jnizd4h7yf110744j2-bash-4.3.42/bin/bash <mark_weaver>which can't use the locales generated by glibc-2.23 :-( <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>since I never use sudo, I don't remember offhand how to make it do the right thing. maybe someone else here knows <mark_weaver>sapientech: looking at the sudo man page, I guess that passing -i to sudo should fix the issue <sapientech>okay i think i must have really messed some things up <sapientech>this must have been because i used sudo with mv initially, which had the wrong USER since i didn't use -i <sapientech>i imagine i need to set both /gnu and /var/guix to root? <sapientech>mark_weaver: cool got guix upgraded from .10 to .11.0-1.4420 <mark_weaver>sapientech: I'm sorry, I don't know what these statements mean: "ls -ld on /per-user/root is sapientech" and "in fact, all of guix is sapientech". can you be more clear? <mark_weaver>and what do you mean by "i used sudo with mv initially" ? <sapientech>because i moved them from /tmp with sudo which must have still had sapientech as user <sapientech>i did recursive, and then recursive on per-user/sapientech as sapientech.sapientech <sapientech>then chown -R sapientech:sapientech /var/guix.../per-user/sapientech <mark_weaver>and /var/guix has things in it that need to be owned by others. you are being careless, please. <sapientech>:( well i did it before you gave the command since you werent responding <sapientech>it was not a smart move, suppose i reinstall it all now? <mark_weaver>in /var/guix/profiles/per-user, each subdirectory needs to be recursively chown to that user <mark_weaver>the individual store items should be owned by root:root, except for outputs that are in the process of being built. <mark_weaver>hmm, well, I guess the group doesn't matter on the store items. on mine they are group guixbuild, not root. <sapientech>okay cool so i have owned by root, group is guixbuild, just confirming thats what we want? <mark_weaver>anyway, hopefully that fixed the locale issues for guix at least, and maybe also for claws-mail <balduin>I get the following error message: libmbedtls.a: error adding symbols: Bad value <balduin>collect2: error: ld returned 1 exit status <sapientech>i actually still get locale errors for both ./pre-inst... and sys wide guix <mark_weaver>sapientech: is GUIX_LOCPATH set in the environment where that happens? <sapientech>mark_weaver: with guix package -i <package> , echo $GUIX_LOCPATH is there <mark_weaver>do "guix --help" and "./pre-inst-env guix --help" report errors setting the locale? <mark_weaver>if so, send me the strace output for the one that fails. <sapientech>mark_weaver: i really appreciate the help youve been, even when i f up <mark_weaver>balduin: sorry, I don't have time to help you investigate this now. it's not obvious to me what the problem is. <sapientech>mark_weaver: appoligies, i ran guix, not git. also i realized that guix --help works, but guix package -i some-package is where i have locale errors <mark_weaver>if it's while downloading substitutes, then it's harmless <mark_weaver>anyway, I have to work on some other things now. happy hacking! <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 <sapientech>okay thanks for letting me know, i looked but i need to take longer on it for future commits. <mark_weaver>* gnu/packages/python.scm (python-kivy, python2-kivy, python-kivy-next) <mark_weaver>anyway, it's hardly worth sending another email. I can just fix it up for you. otherwise, I think it's ready to push! <mark_weaver>(if you want to send an updated patch, that's okay too) ***deadrat is now known as fsftn
***fsftn is now known as deadrat
<sapientech>mark_weaver: sent an email, might as well practice <efraim>lfam: don't forget to push libgcrypt-1.7.2 and gnupg-2.1.14(?) to core-updates <phant0mas>sneek: later tell hello pmikkelsen, yes it is me <ng0>the configure breaks at: Found /usr/include/getopt.h <ng0>the colorcodes in it make it not easy to read <ng0>i packaged tup, so that's not a problem either <iyzsong>can't understand it, there is no '/usr/include' in the script AFAIS. <ng0>i'll switch channels andsee if halosghost is around. otherwise i'll juts mail them <rekado>sneek later tell ng0 The script creates a minimal program and tries to compile this with “$i_cc” (see line 31). In this environment the compiler might only look in default paths. <sneek>ng0, rekado says: The script creates a minimal program and tries to compile this with “$i_cc” (see line 31). In this environment the compiler might only look in default paths. <ng0>how do you propose to fix this? <ng0>i've never seen this before <ng0>Guix has a set of default CFLAGS, right? <ng0>I could try to overwrite the CFLAGS in Tuprules.tup <ng0>and this doesn't seem to work like i expected it to <rekado>ng0: you might be able to pass the value of (getenv "CFLAGS") to the configure script via “--cflags” (and make sure to use GCC instead of clang) <ng0>tup is new to me, this is the first application which uses it I package, ever. thanks, i'll try that <rekado>ng0: or you could just skip the configure step. <ng0>wow. this is problematic <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. <ng0>i think I need to write some tup-make-system thing to shorten the procedure for tup based makes.. if I can even make this thing to succeed <davexunit>are there even that many? I've never even heard of tup. <ng0>could someone who packaged the kernel related stuff tell me how a build phase could load a module? the obvious way with system and the /sbin/modprobe of the out of module-inti-tools does not work <ng0>im not sure how popular it is <davexunit>nor could it, since it's run as an unprivileged user <ng0>i got the build script without tup by the author <ng0>i don't know.. maybe tup works, maybe not. i have it packaged but have no usecase. <ng0>itÄs like lispf4 so to say.. but it is not broken. i just don't know if it works <ng0>i can send it in as a separate patch <bavier>ng0: I started reviewing your patches for perl-openstream but had to catch a bus <ng0>if a clang ...many..command..chains included `pkg-config --libs-only-l libcurl jansson` in the middle, how can I write this for system* ? <ng0>we get a "make simple" soon for the package I build, but I want to test it like this in advance <bavier>ng0: I don't know of any pkg-config-guile bindings <bavier>so I think you'd have to read pkg-config's output from a pipe, then include the result in system* ***jonsger1 is now known as jonsger
<ng0>the fix i talked wuth the author about might be ready in a couple of moments. <ng0>so maybe it just works with make simple now <ng0>i got a patch. i'll see where this gets me now <Petter>myglc2: If you're still asking for someone with mosh experience, I have some now. <myglc2>Petter: Hi, thanks. Are you using mosh w/emacs? <Petter>Are there problems running it with Emacs? <janneke>Petter: i'm running emacs over mosh... <myglc2>janneke: hows it working for you? <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. <bavier>joshuaBPMan_: can you log in as root? <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. I will try logging in without a password. Thanks mark. <mark_weaver>(unless you set them correctly in your OS configuration, in the crypted forms) <davexunit>you might need to login as root first and set passwords <joshuaBPMan_>hmmm. I'm not sure how to do that. So I suppose that it is not set. <mark_weaver>I recommend logging into a text terminal (not the GUI) as root, and then running "passwd <username>" to set the passwords for the other users. <mark_weaver>after that, you should be able to log in as your normal user from the GUI <davexunit>the same way you do on any GNU/Linux machine <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. <Petter>Are you sure your home-partition is mounted? <joshuaBPMan_>when I did an ls -l (in guixSD) it show all the relevant files in /home/joshua <davexunit>joshuaBPMan_: you need to configure the 'packages' field of your OS config to have the things that you'd like <davexunit>anything you want globally available that is <joshuaBPMan_>I'll look online and try to see if guix has usermod available. it probably does. <davexunit>useradd, userdel, and usermod are provided by the "shadow" packages <davexunit>I wouldn't recommend using that to change the UID <davexunit>this is all controlled by the system configuration interface <davexunit>you should add that user id to the user records of your OS config <joshuaBPMan_>ok. I'm not sure how to do that. Give me 5 minutes to look online. I might be able to find it in the relevant documentation. <davexunit>the whole point of using GuixSD is to have the OS config describe your entire system <davexunit>if you make ad-hoc mutations after the fact then your config no longer represents the system you are running <joshuaBPMan_>I just didn't realize that you could configure your UID in configure.scm. That's awesome! <joshuaBPMan_>I just have to understand the webpage that I've found. haha. <davexunit>the exception to this rule are things that are inherent stateful: your home directory, secrets and passwords, databases and other things in /var, etc. <joshuaBPMan_>I'm going to change my configure.scm now. reboot into guix, login as root, then run guix reconfigure. <joshuaBPMan_>ok. I've added (uid 2000) to my guix config.scm file. I'm going to reboot and see if I can reconfigure guixSD. <myglc2>janneke, Petter: Thanks, i'm now a happy mosh user \\o/ <lime_>so, guix, just stumbled across it <lime_>installing it on my thinkpad x250 <bavier>good luck, let us know if you have any questions <lime_>the usb installer didn't support uefi booting, does this os support gpt booting? <ng0>can a timestamp lead to a file not being found? <ng0>a new Makefile option i am testing with the author of pbpst leads to two timestamps. make.sh is created and has a timestamp (looking at other packages on how to fix this on our side for now) <ng0>different question, is "#! /bin/sh" as shebang valid with the space? <bavier>ng0: our patch-shebang procedures accept it <lime_>and then jumped in the that's the install running <ng0>how do I get 1970-01-01 epochtime with date? <ng0>thaht's not what i wanted though, asked the wrong way. but i'll read into man date <ng0>2147483647 it's in the man of date <lime_>any recommend wifi devices with free firmware <ng0>well no that's not what i wanted though x.x grml. well i'll find it <Petter>ng0: What do you want date to do? <ng0>during the new make phase i am testing, a file is created. this file has a timestamp which is $now. i don't think this is the reason the build fails, but i know how to fix it at least for guix. <ng0>so i want (let ((early-1970 to be 1970-01-01 UTC <bavier>ng0: can you use guile's utime to reset the modification time (e.g. in the vlc package)? <ng0>oh. i'll have a look at that. thanks <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 <ng0>#! /gnu/store/ykzwykkvr2c80rw4l1qh3mvfdkl7jibi-bash-4.3.42/bin/sh -e <ng0>this is after i patched the /bin/sh after its creation, before its execution <ng0>it would be easier if I would send the patches so you could apply, but it involves a patch which is not applied to the source yet <bavier>ng0: btw, you can use 'patch-shebang' rather than the substitute* <ng0>(patch-shebang "file") ? <bavier>works fine unless there are other /bin/sh references, in which case the substitute* method is preferable <ng0>even if the timestamp is there, ./make.sh should run <bavier>ng0: has the project considered using autotools? ;) <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 <ng0>but tup generate can run <rekado>a build system requires a certain kernel module to be loaded…? <ng0>see the tup page i inserted earlier <CompanionCube>doesn't it use FUSE simply because it allows better monitoring of dependencies <rekado>ng0: the error you see — have you tried debugging this? Like “guix build -K” and then check if the file exists and is executable, etc? <ng0>i just package pbpst <ng0>which happens to use tup, and i try to test a make phase which does not use tup now <rekado>ng0: on the page you posted I don’t see much about FUSE. <ng0>modprobe fuse is required for it. <ng0>i have not tried to run the make.sh in the fialed build. damn., okay i'll try that <bavier>the pbpst project looks so trivial, I can hardly imagine it's gaining anything from using tup <rekado>In execvp of make.sh: No such file or directory <ng0>yes, see the patch for Makefile <ng0>maybe i should add the patch which i am testing and send a patch to the list, would make it easier for you to run and understand <ng0>ng0@shadowwalker /tmp/guix-build-pbpst-1.2.0.drv-11/pbpst-1.2.0$ ./make.sh <ng0>mkdir: cannot create directory ‘dist’: Permission denied <ng0>so it is a functional file <rekado>ng0: are you sure you are in the same directory in that build phase…? <cmhobbs>i've got a couple of days off next month and i'm looking for something to hack on. is it feasible to learn guix packaging in that timespan? (probably 16 hours tops) <rekado>also: try running (system* "bash" "make.sh") if you get desperate ;) <cmhobbs>at the moment, i think i've boiled it down to trying to do something with guix or guile <janneke>cmhobbs: you'll possibly not learn everything in 16 hours <cmhobbs>cool, i'll add that to my short list <cmhobbs>naturally "everything" won't be picked up but i already use guix locally for a lot of things <janneke>but you should be able to create and submit a number of some packages in that time <rekado>cmhobbs: guix packaging is pretty simple – for simple software <rekado>cmhobbs: try the importers first <ng0>now i fail one step further. progress! <janneke>reminds me that i'd like to split gnu hello into its own hello.scm <rekado>cmhobbs: if you know R you can try “guix import cran htmltools” (or for any other CRAN package). This gets you very close to a functioning package. <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>if anyone would like to comment on the recursive importer patches, please do so. <rekado>(they are ancient, but there’s a decision to be made about whether to use streams or just multiple values) <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>” <bavier>rekado: multiple values would be (<package> <list-of-dependencies>)? <wgreenhouse>rekado: ah, very good, and yes, I used to tether on my palm pre during many an install in days past :) <bavier>and stream would be a single stream of all packages imported? <rekado>Message-ID: <1464018008-1767-1-git-send-email-ricardo.wurmus@mdc-berlin.de> <rekado>the problem with the stream is that we’d need to carry some extra information. <rekado>and that means uglifying the import procedure by adding optional arguments <rekado>we need that to prevent cycles and keep a tally of all previously imported packages. <bavier>it seems to me that would need to happen in the multiple-value case too? <rekado>bavier: yes, but there it’s a lot easier. <rekado>the multiple value case actual only returns (package (list "of" "names")) <rekado>the recursive importer keeps track of the first value (and makes sure not to import it again) and then processes the list of names. <rekado>this allows us to have a separate procedure — the only change to the original import procedure is to make it return also a list of names for this package’s dependencies. <rekado>that’s much less invasive than what I came up with for the stream case. <bavier>I see. that'd allow us to keep the recursive logic at a higher level. <jlicht>rekado: Are you still working on the recursive importer structure? <rekado>jlicht: not currently. My last email to the list is waiting for a response (from Ludo). <rekado>I just need to know if I’m overlooking anything. <rekado>I’d like to use streams, but I’ve banged my head at this for too long without coming up with something that is both elegant and also works. <rekado>(really didn’t expect this to be hard, so I think I’m overlooking something) <rekado>If the consensus is that using my originally proposed design is okay I’ll implement it for all importers. <jlicht>rekado: I guess that makes sense <jlicht>maybe we just need more people using it, and thinking about it, in order to achieve something that is elegant, yet also works <catonano>rekado: in what does your current effort differ from your original design ? <rekado>catonano: with streams the importer would return a lazy list of complete package expressions. <rekado>this completely hides the mechanism behind all this and would be quite neat, but it has some practical drawbacks. <rekado>on the command line the result would be the same: you’d get pages full of package expressions, in the right order (dependencies first). <rekado>streams are prettier in Scheme code, though. <rekado>they allow you to just pull package for package and do the import work on demand. <rekado>in reality, though, it’s not so simple. <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? <lime_>and quite a lot of things are running their make scripts <rekado>lime_: when do you get these errors? What command did you run? <rekado>lime_: that’s probably not what you want. <rekado>this looks like you’re not using binary substitutes. <lime_>guix system init /mnt/etc/config.scm /mnt <rekado>lime_: did you run “guix pull” before that? <lime_>ACTION suggests an update to the wiki page <rekado>ACTION notes that there is no wiki page <lfam>We should still have substitutes for 0.11.0! <rekado>lime_: do you use the latest release of Guix? <lfam>And plus, we take care that the tagged release will work. We *should* keep the master branch in order, but we are not quite as careful <lime_>dd if=guixsd-usb-install-0.11.0.x86_64-linux\\(1\\) of=/dev/sdb <rekado>lfam: I don’t know what to look for on hydra to see if we did something to keep substitutes for 0.11.0. <rekado>lfam: I thought Ludo made sure of that. <rekado>lime_: it’s quite possible that this is not your fault. <rekado>lime_: but for now I recommend “guix pull” anyway. <lfam>I don't think a lack of substitutes would cause lime_'s problem. I wonder if the OS configuration is well-formed? <lfam>If we were simply missing substitutes, wouldn't lime_ just build everything? <rekado>“guix pull” is roughly equivalent to “apt-get update”, i.e. it fetches the latest package definitions. <catonano>I can t find rekado's message with his patches <lfam>lime_: `guix package --install curl` <lime_>guix pull failed, I'll paste bin the error soon ;) <lfam>Hm... something's not right <lime_>git not installed by default? <lfam>No, but you can install it similarly :) <lime_>it was a git address it was pulling from... <lime_>I wonder if the gpu drivers for my amd chipset gpu are open source <lfam>Off-topic: Is anybody here experienced with the Python Zope framework? <lfam>Well, it's on topic, as it relates to Guix packaging :) <lfam>I'm wondering about the very best way to resolve the circular dependencies that swirl among the Zope packages <lime_>why on earth is my laptop rebuilding gcc <lfam>lime_: Okay, I think you should cancel the operation <lfam>That should not be happening <lime_>maybe a new flash drive image? <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 <lime_>didn't check the first time but <lime_>Primary key fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 <lfam>Can you successfully ping any remote servers from within the installer? For example, `ping gnu.org` <lime_>I just want to write a wifi driver! <lime_>my ethernet uses the e100e driver <lfam>Okay, what is the name of .drv filename for maxima when you run `guix build -n maxima`? I need to see the full filename, including the ugly hash in the middle <lime_>I didn't tell you? I'm redoing the usb stick <lime_>as soon as it comes up, I'll check that <lfam>It seems unlikely that random filesystem corruption could cause the errors you described, but USB flash drives are indeed a pain <lime_>I am quite close to buying a dvd drive <lime_>i created swapspace by the way <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 <lime_>#/gnu/store/g8288rphjqi2dkjyx9v3yhkl8pw4xdhg-maxima-5.36.1 <lfam>Okay, what happens if you do `guix build hello`? <lime_>guix pull is working this time <lfam>That's good news, although I still think it's better to initialize the system from the 0.11.0 release tag. But... there are arguments for both sides :) <lime_>shall i do that another tty or shall we not anger the beaver <lfam>It should be fine to try building hello in another tty <lfam>We want to see a substitute for hello downloaded from the Hydra mirror <lime_>oh am i getting the bleeding edge now? <lfam>Yes, that's what `guix pull` will do. If you are familiar with Debian / apt / dpkg, `guix pull` is like `apt-get update` except that it's per-user