<pkill9>there's also a symlink placed to bash placed at /bin/sh y default <civodul>lsl88: yes, anyone can "see" them, and they're unencrypted <civodul>lsl88: however, to retrieve a file you put there, one has to know the handle of that file <civodul>(the string that "ipfs add" returns) <lsl88>civodul: My cat wants to be famous, but not that much <lsl88>I will have to change everything <lsl88>civodul: don't laugh, bjorn will have to wait until Guix days to have pictures of him, and the audios. <lsl88>And also I know that sometimes I write fast and mispell words but my English does not sound that bad <lsl88>and the slides do have jokes about my cat <lsl88>sorry, the .svg files that I used from previous presentations <rain1>why did they point /bin/sh to bash? <rain1>could be useful to have /bin/bash also <OriansJ>rain1: well most distros point /bin/sh to dash, so why bash is an interesting question <lsl88>civodul: for trying out the tools. At first I recall mentioning that I used some that did not come from inkscape, so I fetched some from previous talks, changed the text, with jokes about my cat, and blaming bjorn about it, and then translated them - I did it manually- . But I did not know that anybody was going to be able to see that. <OriansJ>also /usr/bin/env bash is the standard for spawning bash anyways <rekado>janneke: the build just failed with ENOSPC on one of the build nodes *vagrantc waves goodbye to CET <civodul>vagrantc: heh, have a good trip back over there! <civodul>it was nice having you in this timezone :-) *vagrantc wanders the earth searching for more guix aarch64-linux users ***catonano_ is now known as catonano
<atw>hey marusich! Your post is linked from gnu.org! <tune>shellcheck fails to build <g_bor>I got a strange error message from validate-runpath in one of my packages. <g_bor>It says string-prefix? wrong type in argument 2, number instead of string. <mbuf>guixsd builds with glibc, by default? or can it be built with uclibc? <g_bor>civodul: I got a stange error in one of my packages, validate-runpath. <efraim>I have 'guix refresh --list-recursive foo' showing all the packages that foo depends on for building, 'guix refresh --recursive foo' to check those packages for updates is taking a bit longer <g_bor> 2 (remove #<procedure libc-library? (lib)> (#)) <g_bor> 1 (find #<procedure 1466360 at /gnu/store/gfprsx2m62cvqb…> …) <g_bor> 0 (string-prefix? "libanl.so" 6755403736024344 #<undefin…> …) <g_bor>ERROR: In procedure string-prefix?: <g_bor>In procedure string-prefix?: Wrong type argument in position 2 (expecting string): 6755403736024344 <efraim>how are you pulling in libc in your package? <g_bor>I belive I am simply using gnu-build-system. <g_bor>confirmed, nothing fancy there... <efraim>note to self: too many 'pk's can confuse guile <civodul>i think roptat (?) reported something like that in a Java package <civodul>the issue is that the binary was malformed IIRC, plus (guix build gremlin) wouldn't handle it gracefully <roptat>g_bor: that's from openjdk, right? <roptat>I remember it was related to debugging symbols <roptat>g_bor: I can't find where I had this issue anymore, I think I removed my openjdk11 definition I had... <roptat>g_bor: I remember there was an option to not install debugging symbols that cause this issue <g_bor>civodul: thanks for the link. <g_bor>I think I get most of right. <g_bor>We checked the target options with rekado, and decided to stick with current practice as far as we can by providing a jre image as the output. The jre was removed from the all target of the makefile as of openjdk11 but still can be built using target legacy-jre-image, upstream announced the intention to remove that sooner or later. *rekado fixes broken build nodes <rekado>we have 23 working build nodes again. <rekado>(one of them isn’t always reachable via SSH, though.) <roptat>g_bor: I've built more sbt dependencies this week-end :) <roptat>one of the dependencies seem to be partially non-free though :/ <roptat>rekado: civodul I'd like to have more info on our infrastructure to determine what we need in our future delegated DNS zone <roptat>what the IP addresses of our future DNS servers (v4 and v6 if available), what subdomains we want, ... <civodul>rekado: did you change the GC job on these so that we collect a bit more or more often? <civodul>roptat: the DNS server would be bayfront.guixsd.org <rekado>I need to make a few more changes first to simplify this <rekado>e.g. export maintenance.git via NFS so that I can build all the systems on the head node <civodul>i'm sorry i've been promising things like 'guix system reconfigure' over SSH for months (years?) and this hasn't happened yet :-/ <rekado>I tried to build this myself, but I’ve been having difficulties with guile-ssh <rekado>when sending a complex expression over SSH via guile-ssh and there’s an error somewhere I didn’t get a proper error message. <rekado>so debugging things was really tedious. <rekado>civodul, roptat we have one more public IP address for an extra server <rekado>the former storage head (running RHEL7) is no longer in use now that the storage is directly attached <rekado>so we have an extra IP and an extra server. <rekado>probably not for the DNS service, though, because we’d like that to be outside of the MDC firewall. <rekado>but if some more infrastructure is needed just let me know <civodul>roptat: actually guix.gnu.org points to both bayfront and berlin <civodul>we could ask the FSF sysadmins to change that if that helps <roptat>civodul: the delegation is independent from the domain <roptat>if we point guix.gnu.org to both, both should have the website for instance <roptat>but we can have a configuration where the dns servers are ns1.guix.gnu.org and ns2.guix.gnu.org, which is completely independent of what we want guix.gnu.org to point to <roptat>also, we want to make sure to have at least two different DNS servers in separate locations because if we loose one, we don't have access to anything else anymore <rekado>so it may make sense to have a fallback DNS server at the MDC? <roptat>ns1 would point to bayfront and ns2 to berlin for instance <roptat>do we want an MX record, more names, ...? <civodul>roptat: so let's have ns1 be bayfront and ns2 be berlin, that sounds good <civodul>i don't think we need it, at least not now <civodul>maybe we could offer email addresses @guix.gnu.org to supporters eventually tho ;-) <roptat>we'd have berlin.guix.gnu.org and bayfront.guix.gnu.org pointing to these servers. More names? Where should guix.gnu.org point to? <civodul>ci.guix.gnu.org, issues.guix.gnu.org <civodul>guix.gnu.org would point to bayfront for the web site and ideally also to berlin <civodul>for CI machines like berlin, bayfront, etc., it'd make sense to have {bayfront,berlin}.ci.guix.gnu.org <civodul>ci points to berlin and issues as well <rekado>civodul: could you please confirm the firewall settings for build nodes connected to berlin? Is it correct that all of them have SSH listen on port 22, except for efraim’s host? <rekado>if that is so, then IT goofed up. <rekado>they opened only port 52522 for these external SSH connections. <rekado>efraim: I can’t access your build node. Has the IP changed? <efraim>rekado: it might be off, I'll go check <efraim>rekado: its back on now, should show up in a minute <janneke>rekado, g_bor: the bootstrappable.org website looks great! <rekado>janneke: thanks. g_bor and roptat implemented most of the changes. <janneke>rekado: yes oh and thanks for replying with the diagram, that's very useful <rekado>does anyone know how to export file systems via NFS on GuixSD? <rekado>do I need to create /etc/exports with an extension to etc-service-type, or is there a better way? <rekado>I think we should have an nfs-service-type instead. <civodul>rekado: looking at machines-for-berlin.scm, the two non-22 ports are the overdrives at efraim's and at my place <rekado>okay, thanks. I’ve asked them to change the port of the most recently added node. <janneke>nice work already on your wip-merge branch! <samplet>Yeah, but looking ahead, I’m not so sure.... <samplet>Using “(gash script)” might be harder than I first thought. Specifically, it is missing a few features like while loops and case statements. <janneke>yes, i would suggest to drop gash script and any gash peg/parse initially <samplet>I might use it in more of a “spiritual” way, by taking cues from its style and rewriting “(geesh shell)” using macros. <janneke>yes, possibly cherry-pick ideas or snippets here and there <janneke>i hope that gash/gash.scm (with optparser, readline) can be used almost as-is, just calling to geesh parse / geesh eval <jlicht>samplet, janneke: congrats on the merge! Love the work, and read quite some of your code as a learning experience :) <janneke>samplet: hoping to state the obvious: please throw away anything right now that doesn't fit or is in the way, "git is patient" anyway and we can always bring stuff back :-) <samplet>janneke: Okay. If I target bootstrapping aggressively, I bet we could hit a big milestone quickly (like in a week or two). <janneke>samplet: that would be amazing and as long as we're on the right track there's real reason to hurry; we have time <samplet>janneke: Yes we have time, but having a clear goal in mind lets me focus. :) <rekado>civodul: looks like I’m still doing something wrong. <rekado>civodul: PID 1 seems stuck reading things again. <rekado>aside from fixing this bug we’ll need an example for bind mounts in the manual. <rekado>mirror.hydra.gnu.org is not responding <rekado>I get a 504 error instead of substitutes <thomassgn>I'm trying to understand and apply trivial-build-system but struggle with just extracting from the tar.xz. I now get no errors from the (invoke tar "xvf") but the build directory (from guix build -K) has no files... Where did they go? <thomassgn>I realize it's not a "good(tm)" question. I'm also a bit hesitant to ask seeing as the software I'm playing with is nonfree (I have a little list of mostly free and some nonfree packages I'd like to package, this was the first - because I "need" it). <rekado>thomassgn: they were likely unpacked in the current working directory. <rekado>thomassgn: have you looked at other packages using the trivial-build-system? <thomassgn>mm, I looked mostly at markdown in markup.scm and font-adobe-source-han-sans in font.scm as they both use trivial and invoke for extractraction <thomassgn>I have the (invoke tar...) inside a (with-directory-excursion out ...) I thought that would make CWD be out? Maybe that is not what I want/need afterall. <rekado>with-directory-excursion temporarily changes the CWD for its body. <civodul>rekado: ahem, i tried the gdb trick but that didn't quite work <civodul>i think we'll have to do a hard reboot <rekado>yes, but unfortunately not right now <rekado>I’ll try to reboot it later tonight <rekado>do you see anything obvious wrong in my file-systems declaration? <rekado>I guess the fs type shouldn’t be “ext4” but “bind”…? *rekado goes afk for a few hours <civodul>shepherd[1]: segfault at 7f2e00000000 ip 00007f2e2490e810 sp 00007ffc60381808 error 4 in ld-2.28.so[7f2e248f9000+1e000] <efraim>thomassgn: if you're 'plopping' it into place then you can look at the 'tar' options to choose destination, otherwise you'll have to refer to 'source' to unpack it while 'in %output' <thomassgn>mm. should've checked with-directory-excursion, for once my assumption was correct. I'll go ahead and look at some of the free packages like a webapp next time I try trivial-build; so much easier to ask for help and to help out with :) <thomassgn>efraim: thanks, I'll have a look at that - maybe :) <thomassgn>as in - maybe that will do the trick (after sending that looked like I meant something entirely different) <thomassgn>related, is out (usually from '(out (assoc-ref %outputs "out"))') and the temporary build directory in /tmp/ the same thing - as in it is the /tmp/guix-build-... until it completes building and then copied to the store? or is there some other variable I should use for the /tmp/ directory, if so, is the entire build directory in /tmp/ moved to the store after? <allana>Are there any Python developers in the room? I'm curious about the state of the art of Python development using guix. Recently I have been using nix along with a shell.nix for each project that will create a pure shell environment for that project and call "setup.py develop" for hacking on my project. I'm aware of this blog post: https://trivialfis.github.io/linux/2018/06/10/Using-guix-for-development.html -- and I am curious to know if <allana>anyone is aware of additional resources or have any tips to share. <thomassgn>allana: Hey! I'm slightly familiar (and rusty :)) with python. That blog post seems to list wht you'd need. But I'd add direnv - it's pure magic and so simple. :) <allana>thomassgn: Thanks, looking at direnv now <thomassgn>one other neat thing (might be mentioned in the blog - I only skimmed it) is if you create a package definition for your project you can use that as the argument to guix environment. It would also enable you to install the project, share it easily with others using either guix or guix pack. guile-semver was posted recently as a good example for this kind of usage: <thomassgn>I don't intend to drown you in information. Hope it's usefull. :) <baconicsynergy>sadly my thinkpad x200 died so I can't use a fully free distro for the time being :( <allana>thomassgn: There is a good chance that my Python package(s) wont be packaged for guix for a few reasons, but the biggest is that I am the only guix user in my organization. I seek to use it mostly my own personal development environment. I will likely use guix environment --manifest my-dev-dependencies.scm --container and then develop in python as though I was in any other environment <allana>baconicsynergy: I got one of those atheros usb long range wifi adapters. It is actually quite nice, I get more wifi access points and better signals <allana>baconicsynergy: if it is an option for you, you may like it as well. I'm only mentioning it because I was skeptical of using one myself. Now I also use it with other laptops with working nonfree wifi hardware <necrophcodr>Hi everyone. I've tried installing GuixSD on a Vultr VPS, and I'm getting the following error: <necrophcodr>guix system: error: failed to install bootloader /gnu/store/slz9acwdzi54gpvm51jpgw6fq0752g2n-bootloader-installer <efraim>i know it's really a #guile question, what's the difference between cut and cute? <THFKA4>necrophcodr: does it print the grub-install cmdline? if so, rerun that with --debug and it will show you which part failed <THFKA4>usually it's not having the /boot partition mounted, or not having UEFI enabled for removable storage in BIOS <necrophcodr>It doesn't use UEFI so /boot is on the root partition <janneke>samplet: i'v removed scripts/geesh and made scripts/gash, gash/gash.scm use geesh read+eval <necrophcodr>I'm not sure where to put it in the `guix system init` command <THFKA4>i meant to look at the output of the original command, usually it tells you where things go wrong <THFKA4>then you can rerun the step that fails with a more verbose output <THFKA4>in my case, it was grub-install, and i had to rerun it with --debug <THFKA4>if you don't have UEFI booting, you should change grub-efi-bootloader to grub-bootloader in the OS definition <THFKA4>maybe use lsblk/blkid to see what devices you have, then make sure your configuration references the right one? <THFKA4>also run mount and see what (if anything) is mounted under your /boot <necrophcodr>there is only one device, and it's referencing the correct one. i've quadruple checked as well. <THFKA4>you do need to mount the bootloader install target under /mnt/boot before installing <THFKA4>only one device? are you installing from your root partition? <necrophcodr>yes, but the /boot directory is just located under the root partition. there's only one disk and only one partition. <necrophcodr>i can post the OS definition as well if that's any use <g_bor>necrophcodr: this is a quite typical setup. What is going wrong? <necrophcodr>g_bor, you probably have a better idea of this than me, because i have no idea <necrophcodr>i'm fine with doing a more complex setup, but i'd rather start out as simple as possible and build from there. i'm just trying to run guixsd as a server for fun and learning. <necrophcodr>(and preparation for when the guixsd overloads take over the world) <g_bor>I was not here from the beginning, what were you trying to do, and what error happened? <janneke>samplet: i think so...i'll rewrite my commit if that's OK, i just found -e and -x are setting gash style options, reading about setopt! <necrophcodr>i'm trying to install guixsd on a vps on vultr, so i've booted the iso and installed per the official documentation (with only one btrfs partition and nothing else), and tried running the `guix system init /mnt/etc/config.scm /mnt` command <necrophcodr>guix system: error: failed to install bootloader /gnu/store/slz9acwdzi54gpvm51jp <necrophcodr>nothing else, no other error output, and the previous line in my terminal is just <g_bor>necrophcodr: what does the bootloade section of your config look like? <janneke>samplet: feel free to ignore my work if it's not helpful :-) <g_bor>and this is a vm, most probably legacy bios, and your block device is vda, is that correct? <g_bor>you said you only have one partition, is that also correct? <necrophcodr>yes, a 20GB "disk" with one partition with a btrfs system on it <g_bor>ok, so the problem is most probably in the partitoning. You need a bios-grub partition at the beginning of the drive to make enough place for grub <necrophcodr>even if i'm not using uefi? i'll try setting it up, i've not had a use for a seperate partition before <g_bor>if you are using a gpt disk label, which I recommend to have flexibility, then when using legacy bios you need a bios-grub partiton, and when using efi you need an esp. <necrophcodr>i have no need for flexibility of partitions on a 20GB disk that's only going to be used for guixsd <samplet>janneke: No, no. It is good. :) I will take a look at it a bit later. <samplet>(I am trying to get Bash to build using my old test but with Gash filling in for coreutils et. al.) <g_bor>The grub manual says about this case that the first partition starts at least 63 sectors into the disk, so that the grub core can be embedded before the first partition. <g_bor>Where does you first partiton start? <necrophcodr>i agree. it's not the first time that i've installed a linux distribution, since i've been testing distributions for 10 years <necrophcodr>but guixsd is a bit different from everything else, and since no output was produced, i thought it best to ask here <g_bor>I should have a closer look at that... <janneke>Grrr: Makefile.am:150: warning: '%'-style pattern rules are a GNU make extension <necrophcodr>g_bor, if you want to have a closer look at the system, i can set it up if you have an ssh pubkey <g_bor>can do that, but if you are not opposed I would try to reproduce this locally first. <g_bor>my network is a bit bumpy here, it seems :( <necrophcodr>if i can't get it working it's no big loss for me, i'll just wait for a newer release of guixsd and try again later :) <necrophcodr>it's a personal experiment, so there's not much to it <g_bor>I am a bit unsure here, as I've not tried to use the old style disk label for a while... <jlicht>how could/would one get started hacking on the Hurd, using guix? (Is this even possible at this moment?) *g_bor running system init <pkill9>mirror.hydra.gnu.org keeps 502'ing me and it's the only one with a blender substitute :< <g_bor>necrophcodr: here it went fine, so we can go on to have a look at your system <g_bor>how should I share the key with you? <necrophcodr>g_bor, i'm not sure how you prefer, but i believe you can just message me an encrypted pastebin from https://0bin.net/ using a direct message here on IRC <necrophcodr>even though it's a public key, you can decide to have it "burn after reading" <janneke>not sure if they still work or which are relevant <janneke>g_bor: on my private core-updates branch @gitlab, guile-bootstrap@2.0 has been removed entirely <janneke>with mes 0.19 there is much less need for using Guile during development even <g_bor>please make sure to tell us when it lands on a public branch, so that we can post updates to the website. <g_bor>Also, if you feel anything is amiss from there feel free to contact me, or update it yourself. <janneke>g_bor: sure, will do! i just posted to guix-devel, the new bootstrap seed for mes needs to be verified and uploaded before i/we can push to savnnah <g_bor>I've seen the impressive performance gain you posted in one mails! <janneke>Yes! I had "performance! performance! performance!" in my road-map and really tried everything i could imagine <janneke>However, I had not been able to build tcc with my mes development branch for some months now <g_bor>ok, I see the mail, will have a look tomorrow <janneke>our hacking session at R-B really motivated me to drill down and get the 0.19 release out -- finally being able to test real world performance <g_bor>:) yes, that was really nice <g_bor>it also helped me to get my binary digging skills back to speed :) <janneke>with the three of us closing in to that bug, just wow <allana>Are there any examples in the wild of using a trivial build to install prebuilt binaries? <rekado>the result would likely not be usable unless you also used patchelf to replace the interpreter. <g_bor>allana: with that said, I believe you can find find some... Don't know a concrete location though. <g_bor>Maybe we are doing something similar for languages we could not bootstrap yet... <g_bor>You can have a look around those. <allana>Basically I'm looking for an easy way to get software before properly packaging it <pkill9>allana: I put a symlink to the interpreter in the location all portable binaries expect it to be in, and then run it with LD_LIBRARY_PATH set