<Apteryx>wow. downloading texlive from bayfront.guixsd.org -> 3.94 GiB <amz3`>“Let's build a free self-sufficent and sustainable space-ship for a one way trip to another habitable planet with the goal to settling a colony.” <OriansJ>catern: you know you can just deploy the guix package in say /gnu and it will work on wheezy right? <OriansJ>catern: also, why are you using Wheezy, Jessie is the current stable and Stretch is almost halfway through their release cycle if I remember correctly <catern>OriansJ: re: wheezy being obsolete, yes that is why it's embarrassing <catern>OriansJ: yes, I can drop the binary tarball in /gnu <catern>but I want to install using a debian package <catern>so I need to backport the guile it depends on <catern>I suppose I could make a minimal package that just drops the tarball in /gnu <catern>how does the binary tarball release get built? <catern>that seems like a good way to do it <OriansJ>catern: I think you might also have to setup systemd unless you wanted to write a SysV script for the guix daemon <catern>writing a SysV script for the guix daemon is fine, I am sure ones exist already :) <catern>I definitely don't think this requires something as major as setting up systemd on a wheezy system :) <catern>I can make the tarball just with a simple command in the source tree <OriansJ>catern: actually depending on what is on the system, the migration to systemd is rather painless in debian. <catern>systemd is irrelevant here... guix-daemon can be started just fine with sysv, and that's a less invasive change <catern>so yeah I think I'll just package up the tarball as a Debian package <OriansJ>catern: Let us know how that goes :) <OriansJ>your experiment to bring wheezy forward using guix <catern>so guix no longer builds nix-setuid-helper, right? but it's still mentioned in the README... <happy_gnu>guix package: error: failed to connect to `/var/guix/daemon-socket/socket': Connection refused <happy_gnu>Active: active (running) since Sun 2017-05-21 21:45:48 CDT; 11min ago <happy_gnu>and /var/guix/daemon-socket/socket does exist <destt>Is it possible to edit the phases in cmake-build-system? <destt>I need to remove the configure phase <efraim>destt: if you search through the code for "(delete 'configure" you'll find a couple of examples <destt>efrain: thanks! I think I have figured it out <destt>now I'm trying to get the build phase working properly <destt>that's as far as I've gotten in defining a package <destt>it's not building, and I'm not sure what I need to do <destt>those are the build instructions for this peice of software <destt>it uses cmake, but before building it makes a directory, then cd's into it, and then calls `cmake ..` <destt>the error I'm getting is `Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)`, I think... <efraim>So it looks like you need pkg-config as a native-input <destt>I've added that and git, now it is getting hung up on not finding apr <brendyn>efraim: destt , also, there is (replace 'configure <destt>got it to find the apr library <destt>now getting errors with make install <destt>the error has to do with linking shared libraries <destt>am not sure that the program I am packaging *has* a configure phase <brendyn>destt: when you try to build it you should get some kind of error saying that. then you can add (delete 'configure) <destt>currently I'm having issues with dynamic linking <destt>ld is telling me to recompile with -fPIC <destt>ld: /gnu/store/rqx6k5jj11rr91sml6x1nmpydmv82y88-mbedtls-apache-2.4.2/lib/libmbedx509.a(x509.c.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC <destt>ld: final link failed: Nonrepresentable section on output <destt>I've got a long list of errors like this when trying to build a package <destt>that's the package definition I have so far <destt>brendyn: doesn't change anything <civodul>rekado: for the record i have all the release files ready except the arm/aarch64 tarballs which are currently building <civodul>so i did "make release" for x86 and then started these two manually <civodul>i tried building on an rpi2 but it went OOM <civodul>efraim: it's keeping your box busy :-) <efraim>i saw, i was going to try moving it around on my desk to try out the uefi installer but i saw the box was busy <civodul>do you know why the machine crashed yesterday? <civodul>or maybe you were moving it around your desk? ;-) <efraim>but it was night time, so no clue really <efraim>maybe the slow storage got itself stuck, the time displayed on screen was 1:18 <efraim>so either 30 minutes before or after your email <efraim>plan C networking for the macbook is tethering to an old cellphone connected by wifi <efraim>thats the last time i buy 1.5 meter ethernet cables <efraim>i think I found a bug in dhclient <efraim>my interface name is enp0s29f7u1 <efraim>it is so long it runs into the word 'Link' from ip <efraim>so the tab completion on dhclient tries to append 'Link' to the end of the interface <civodul>efraim: yeah i've seen this tab completion bug <civodul>efraim: re aarch64, let's hope it doesn't overheat <efraim>I don't think the documentation has been updated to say where to mount the EFI partition <civodul>otherwise we'll keep answering that question on #guix :-) <efraim>i didn't see it in guix.texi, didn't specifically check on alt+F2 <efraim>i was going to run guix pull first, and then I realized I built the image so it should be current :) <efraim>doesn't look like the install image has bayfront enabled <civodul>efraim: right bayfront's key is registered, but the default substitute server remains mirror.hydra.* <civodul>the thought was that maybe at some point mirror.* will start mirroring bayfront <brendyn>is the install image for x86_64 uploaded yet, civodul ? <civodul>waiting for the last binary tarballs to complete <civodul>if everything goes well, this should be done within an hour or so <civodul>those arm machines are terribly slow, though... <brendyn>I just want to be the first person to topple hydra in the rush <civodul>i think that means no aarch64 binary tarball this time <Sleep_Walker>guix system: error: build failed: unexpected EOF reading a line <efraim>civodul: 'guix package: error: expression "+" does not evaluate to a package' i think that looks like the error i was getting before <civodul>"./pre-inst-env guix package -A" returns nothing there <civodul>aarch64 is not in %supported-systems in (guix packages) <efraim>well, if its not supported and 'guix package -A' only returns packages for that system, then it makes sense it returns nothing <efraim>that must've been newer than the armhf port, that's what I used as my template when I was patching in aarch64 support <brendyyn>How can copy an entire gnu store from to another drive? <civodul>rekado: so no aarch64 this time; thoughts? ↑ <rekado>I don’t understand how hard this would be to fix. <rekado>is it just a matter of adding it to %supported-systems? <rekado>well, seeing that we need to make 0.13.1 soon anyway… <efraim>what if we add it in, run the test, and upload that binary a day late? <civodul>woow all this is very encouraging :-) <efraim>run the test to make sure it actually fixes it, a day late because it takes so long to build :) <rekado>I’d rather get this release out asap and then schedule the next release with a guile fix and aarch64 support. <civodul>and seriously, we need faster build machines <civodul>i mean all this would be easier if we weren't waiting for these arm machines forever <civodul>though of course faster machines won't fix insufficient testing as in this example ;-) <efraim>with the change to guix/packages.scm:227 'guix package -A' works, test still fails <civodul>so this time it's -I returning the empty string? <civodul>there's another problem here it seems <efraim>/etc/guix/acl and /usr/local/guix/acl both exist, not that its relevant for this I think <civodul>rekado: i pushed a draft of the post for the new release, if you want to take a look! <j-r>I am experimenting with using GuixSD as my main development platform.. I ran guix environment --ad-hoc gblibc binutils gcc linux-pam elfutils to create an environment. I make a simple c file that calls pam_start(). I compile it as gcc test.c -lpam. It compiles and links. It can't find libpam.so.0 at run time. If I compile it with gcc test.c -lpam -Wl,-rpath,${LIBRARY_PATH}, it finds libpam.so.0 at runtime. Is such to be expected? <civodul>j-r: yes, simply use "guix environment --ad-hoc gcc-toolchain" <civodul>this adds the "ld-wrapper" package to those you listed here <jlicht>are there any notes/directions on how to start transitioning build systems to use gexps? <civodul>jlicht: not really, but there's a wip-build-systems-gexp branch for that! <civodul>i thought i'd try to revive it in this core-updates cycle <civodul>would you like to give it a try/update it? <jlicht>civodul: Depends on when you were planning to have this finished. I will be at a conference for 6 days starting tomorrow, but afterwards I have some free evenings :-) <jlicht>I will have a look at the branch nonetheless <civodul>jlicht: awesome, i don't have any concrete ETA actually <civodul>i'm very ambitious but i often fail to do as much as i want ;-) <jlicht>how do people work on more invasive guix features here? Do you have multiple guix git checkouts? <civodul>and officially we're supposed to freeze core-updates this week... <jlicht>and what do you have linked in $HOME/.config/guix/latest? <civodul>the 'guix pull' thing, as surprising as it may seem! <civodul>which allows me to distinguish between my "user hat" and my "developer hat" <jlicht>I thought guix blurs the distinction between those two hats ;-) ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | videos: https://gnu.org/s/guix/help/#talks | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: http://paste.lisp.org | log: https://gnunet.org/bot/log/guix | 0.13.0 is out! https://gnu.org/s/guix/news/gnu-guix-and-guixsd-0.13.0-released.html'
<brendyyn>davexunit needs to take up his position on HN I guess <jlicht>is the VM image the one that you could host on some vps-providers? <davexunit>also, submitted to HN. least I can do since I haven't sent a patch in ages. <davexunit>so I'm a bit behind on the guix pull situation. will I need to re-install guix from scratch to get the 2.2 upgrade? <jlicht>davexunit: I just guix pull'd twice, and now stuff seems to work fine <civodul>i reconfigured GuixSD (which switched to 2.2) and then run 'guix pull' as my user <civodul>on a foreign distro it'll stick to the current Guile <civodul>to upgrade, you could 'guix package -i guix' <davexunit>do I need to delete the latest symlink first? <jlicht>davexunit: I think I did, but not sure if that is required <jlicht>maybe rename it in case something weird happens? <rekado>civodul: thanks for your hard work to get the release out! <rekado>davexunit: I didn’t have to delete the symlink first. <rekado>you may see that Guile 2.2 complains about the compiled 2.0 objects, but it will just move on. <jlicht>always good to teach users to ignore errors ;-) <ng0>the number of indiviual contributors to this release is higher than the last one I remember :) <rain1>I finally get guix pull and reconfigure <jlicht>davexunit: welcome... to the future! <solene>I want to thank people writing manuals. I'm new to guix, I installed it both as a system with guixSD and as an addition to a linux system (because guix doesn't support uefi yet), and the manual is up-to-date and works <amz3>solene: tx for the feedback <jlicht>solene: If my reading comprehension is doing okay, guix has supported uefi for about 30 minutes ;-) <solene>jlicht: I've seen the announcement, that's great I will try it today <solene>I bought a new laptop last week and guix wasn't booting on it :( <ng0>itsfemme: on psyced.org <j-r>So to upgrade to 0.13.0 on a foreign distro... guix pull && guix package -u guix ? <davexunit>j-r: yeah, and then I think 'guix pull' again to get the absolute latest from there. <itsfemme[m]>ng0: hey, I wanted to ask if you thought about using a sandboxing daemon like oz <rekado>I’m running “guix gc --optimize” and I expected that it would reduce the amount of space the store needs <rekado>yet it seems to actually use *more* space now <davexunit>ng0: ah so it's like a pre-configured guixsd? <ng0>that is one intention. <ng0>it is worth considering, though I need to read more about it. Do you have any experience with it? <ng0>we have service sandboxes in guix already, and it should be doable to sandbox other processes some day <itsfemme[m]>I'm using it right now and have been for a few months now (on subgraph os) and it's been really stable <ng0>If I didn't delete it, I even have xpra (a dependency of oz) somewhere as a work in progress patch <ng0>Could you send me an email about it? I'm at the plenum of my hackerspace soon <ng0>I left a note for myself in psyced.org. Thanks, itsfemme :) <rain1>ng0: i think the musl idea is very interesting, is there a plan how to achieve it? <efraim>Either replace glibc everywhere from bootstrap binaries and up, or from glibc-final and in the installed system I assume <ng0>not yet.. at the very least it requires more people and the re-implementation of a mesh-like network plan I had, where in this new version build servers among other things would run <ng0>musl is hard. I'm working on uclibc-ng. But neither of them has priority <ng0>uclibc-ng is mostly 1:1 with glibc and won't require many patches <ng0>first the base needs to run. I only know that right now it will be something between 4 and 8GB in size. <ng0>someone (forgot the name) has picked it up again to work on the compiling and updatinG <ng0>and uclibc-ng is available for grabs in my developer branch <ng0>it (uclibc-ng) used to build, but it broke when I started fixing it ;D <jlicht>hmm, a fresh checkout of the guix git repo tries to download an aarch64 guile version when I type make (after bootstrap, configure...) <jlicht>and that (clearly) fails because of the --container flag to my guix environment invocation <rekado>you lose Hurd support without glibc. <ng0>uclibc-ng is 1:1 compatible to glibc, musl is the issue <ng0>I don't know much about Hurd, I will solve that puzzle when I get there. <rekado>much of the Hurd is implemented as part of glibc. <rekado>It would be very surprising if other libc implementations had Hurd support. <ng0>so it's just a matter of failing and fixing until yozu no longer fail with other libcs <ng0>but we don't have musl builds, we don't have uclibc-ng builds, that's just relevant as soon as someone picks it up. Good to know that it could be indefinitely more complex with Hurd than I thought <rekado>s/indefinitiely more complex/impossible/ <ng0>failure is always an option, until then impossible does not exist :) <rekado>the Hurd does not exist outside of glibc. <ng0>which is also why alternative libcs are optional and extend the scope of the project (should probably be moved to 'beyond pragmaOS') <rekado>ah, the problem I had with “guix gc --optimize” is due to ZFS snapshots <rekado>the store shrinks but the snapshot grows … <ng0>thanks for the info. I'll attach this to the relevant bug tickets I have (and maybe make it more clear why other libcs and when (and that it is possibly/very likely linux only)) <bavier`>wow, was it really 5 months since 0.12? <j-r>Hmm, guix pull doesn't seem to pull the 0.13.0 version <bavier`>downside of using '@' for version separator is getting "address@hidden" when viewing the release announcement on lists.gnu.org :P <rekado>bavier`: yeah, I noticed the same. Oh well… <jlicht>I am currently updating our node package <jlicht>and it seems that one of our patches does not cleanly apply anymore, yet it is still required for a functioning build <jlicht>can I just edit the patch that is already in our source tree? <mbakke_>jlicht: yes, we often have to adjust patches with package updates ***mbakke_ is now known as mbakke
<mbakke>how did I become top contributor in 0.13 O_O <rekado>mbakke: there were lots of python test fixes that you contributed IIRC <rekado>ACTION imports 1300+ bioconductor packages <mbakke>rekado: ah, yes, that was some 150 commits <civodul>mbakke: thanks for the repeated hot-fixes on the UEFI thing! <civodul>really cool that you were this responsive <mbakke>np! I saw you did one too in (guix scripts system), should that hit master? <civodul>we should merge that branch to master <rekado>civodul: re core-updates: is there still time for me to make some glibc-related commits? <mbakke>rekado: we haven't started building it yet, so I guess so <rekado>I still need to undo the in-build-phase patching <rekado>okay! Tonight or tomorrow night then! <civodul>i think we said May 25th to freeze the branch <mbakke>maybe we'll have to delay it a bit so that hydra catches up <civodul>now, we can freeze core-updates in the sense that we don't do any core changes <civodul>so it's ok if Hydra hasn't caught up yet <mbakke>makes sense, can even start the "core evaluation" <mbakke>civodul: I haven't seen the new ld wrapper yet, do you think it will make it? <civodul>i've already posted a patch for that <civodul>it isn't 100% faithful to what libiberty does, but it's "good enough" <civodul>so at worst i'm in favor of committing it as-is <civodul>(the missing bit is string tokenization that takes quotes into account) <civodul>did you need it in a particular context? <sneek>alezost, you have 1 message. <mbakke>now I've added it as a native-input <mbakke>I'll submit a patch for it against core-updates once the ld wrapper proper is in <alezost>civodul: re Emacs-Guix manual link: my bad, sorry :-) I have sent a fix to guix-patches <civodul>what the heck is it doing with response files? ;-) <civodul>alezost: could you also add a redirect you the emacs-guix web site? <mbakke>civodul: It's by far the largest and most complex package I've worked with :P <alezost>civodul: sorry, I don't understand what you mean <mbakke>no, but need it for some things that don't work well with icecat <alezost>civodul: "a redirect you the emacs-guix web site" doesn't make sense for me <civodul>alezost: sorry, could you add a redirect from the wrong URL to the right URL on the emacs-guix web site? <alezost>civodul: oh, right, I'll look at it, thanks for the idea <civodul>mbakke: could you make the merge of version-0.13.0 in master actually? <civodul>i'm asking because it triggers conflicts in the UEFI/VM-related code <jonsger>it makes installation much faster :) <efraim>ng0: musl built without problems on aarch64 ***andreh1 is now known as andreh
<brendyyn>I wonder if we could make something like Portable Apps with Guix <davidl>so several times over, when I install guix successfully the partition stops being a valid luks-partition. <rekado>brendyyn: would that be statically linked executables for taking with you on a USB drive? <rekado>sneek: later tell civodul Should we start writing NEWS for the next release as we make commits (to avoid the painful process of writing it weeks later)? I just pushed the new Java bootstrap and think that could be mentioned there. <jonsger>is passwd not included in usb-install ? <brendyyn>rekado: Yeah, but perhaps it would be good to deliberately break guix's functional-ness in a controlled way. For example, it would be nice if programs would also see the systems fonts instead of just whatever is in the pack <rekado>brendyyn: you don’t need to install fonts via Guix. But you have to update the font cache. <rekado>I used to have a couple of fonts in ~/.fonts and my Guix applications used them without problems after updating the font cache the usual way. <efraim>rekado: if I want to test the new Java bootstrap on aarch64 which package do you suggest I try to build? Icedtea? <rekado>if you can build icedtea@1 that would actually be sufficient. <Sleep_Walker>where is exec-command, read-pid-file, make-page-map defined? <brendyyn>last I checked, someone was working on a font-build-system that would rebuild the cache automatically <Sleep_Walker>I'm sorry if I wasn't following all the changes, but was shepherd separated and is in some other tarball now? <rekado>Sleep_Walker: the Shepherd has always been a separate project. <efraim>Its a build dependancy of the install tarball <jlicht>rekado: Your java bootstrap is in master? So if I guix pull and guix package -u icedtea, it should rebuild using the new bootstrap? <solene>hello, is it possible to have 32 bits libs on guix 64 ? <solene>or to install guix 32 bits on a foreign distro (which could be guix 64) <rekado>solene: yes, you’d have to do “guix build --system=i686-linux the-package” <Ulysses_>Hi! Are any of the guix webadministrators who posts the iso image and signature file online, present? <mbakke>Ulysses_: Both maintainers seem to be afk at the moment. Why do you ask? <Ulysses_>I would like to know if it would be possible to put the SHA256 and SHA512 Checksums, a PGP key and signature file next to each posted .iso image, the same way that Qubes OS does? Even better would be to put it all in a zipped torrent file..... What do you think? <mbakke>Ulysses_: the signatures are already there on the download page, and SHA1(!) checksums are posted in the release announcement <solene>Ulysses_: there is a mail with sig files links and the checksums <mbakke>oh, you meant the actual public key <Ulysses_>MD5, SHA-0 and SHA1 are all vulnerable to collision attacks... <Ulysses_>SHA256 and above are not (yet) vulnerable to collision attacks.... <mbakke>Ulysses_: the public keys can be downloaded from Savannah, but I agree they could be more visible <mbakke>can you send a message to guix-devel@gnu.org about this? <Fox___>I got scsh the schem shell going but "Commander S" that sits on top of it is unvail as a pack... <Fox___>so to improve on scsh (as Cdr. "S" does) Emacs is there for us, of course. <Fox___>hey jonsger... I tried on QEMU too but gave up. <jonsger>Fox___: same error (FAIL: tests/store.scm)? <Fox___>I am happy to have a NixOS install for like 10 hrs now... my other crashed afte 3hrs - might have been the .vmdk image format. I am on .vdi now - looks OK <Fox___>jonsger - no I crashed during python2.7 install all the fucking time <Fox___>hey jonsger, you do any scheme or LISP ? <Fox___>I am only trying to start but may quit the LISP business quite apruptly if its all fake <Fox___>jonsger I ran into test fail too before <Fox___>and please use a proper pichost next time <Fox___>I think I one time forgot to type one line from the install manual -- that held me up quite a bit <Fox___>I am rite now on a bare metal GuixSD machine of course <bavier`>jonsger: could you build with --keep-failed ? <Fox___>anyone liking scsh in here, ideally "Commander S" tool improving on "scsh", the scheme shell ? <destt>I am trying to write a package and am running into an error with ld <Fox___>cool ! destt is it a scheme package ? <Fox___>OK. what is neko ? like a new type of vm ? <destt>It's a high level, dynamically typed vm <destt>:) I didn't make it, but I do use it on occasion <destt>That's what I get when I try to build neko with guix <Fox___>is neko as easy to use an extension as guile is to use to extend GNU C ? <Fox___>well I had this one a lot too: "substitute: warning: failed to install locale: Invalid argument" <Fox___>I found a web page giving an example of using guile scheme extending C and it worked without a glitch. <destt>neko is mostly used as a target for haxe <destt>it's really fast to compile, and has decent performance <Fox___>yesterday I read a website saying Erlang is very cool as a performance webserver framework <bavier`>destt: does mbedtls-apache provide shared libraries? <destt>looks like mbedtls can be configured to build shared libraries <bavier`>neko seems to want to link it statically though <bavier`>idk if the preferred solution would be to do mbedtls as shared libraries or build the static libraries with -fPIC, (or some other workaround in neko) <Fox___>qemu is totally cool of course but then the GUI business, say on debian, kinda leaves things to be desired, you know <Fox___>I tested the official DEVUAN (debian variant) .qcow2 release and it was in the 95% range let's say <destt>neko has a "-DSTATIC_DEPS" flag <Fox___>bottom line from an outsider: QEMU is trickier than you would think. <destt>but that tries to download mbedtls directly from tls.mbed.org <destt>is there any way to simulate that connection? <davexunit>ACTION might attempt a 'guix environment' integration for emacs <davexunit>getting something that works for compilation-mode shouldn't be too hard <Fox___>dude is Comander S (S as ins Scheme) as cool as it promises or was it just dropped cuz itz a schem-48 based ware ? <jonsger>bavier`: do you know a way to cp the log-file from qemu-guest to host? <Fox___>without converting the whole image , you mean ? <bavier`>jonsger: I don't. could you paste to paste.lisp.org directly from your vm? <Fox___>does - by chance - anyone know on which Linux distro the "scsh" based tool "Commander S." (S as in Scheme) is currently installable and works ? <jonsger>bavier`: there is now passwd, so I cant do ssh <efraim>rekado: i'm about to run building to icedtea overnight and i was checking how much it was with '-n', there's a couple of downloads that are just called 'hg/git-checkout' or 'jdk.tar.xz' <solene>do UEFI install needs something special when partitioning ? <solene>I'm formating the previous distro and I see it created a little partition that cfdisk recognizes as "EFI system" <efraim>solene: from the arch wiki it should be 'EFI system' and be formated 'mkfs.fat -F32 /dev/sdX?' <jonsger>the build will follow as .tar but my internet is shit, so it's here in 0,5h :( <mbakke>It looks like we released 0.13 without the UEFI manual update. Oops! <mbakke>solene: you also need to specify it in the configuration file <efraim>solene: pretty sure, i already closed firefox in preparation of building guix <mbakke>and use the "grub-efi" package in the bootloader field <solene>wireless isn't working on the system, I think linux-libre doesn't support it. I tried to plug in usb my android phone to use 4G modem but ip a doesn't show a new interface, is it removed by linux-libre too ? <mbakke>solene: I think that should work, but there is no service that automatically configures it :/ <solene>mbakke: I only used it on openbsd, I just plug it and run dhclient, no magic. I don't know what it should look like on Linux ? <solene>mbakke: I had to check "share usb" on my phone :D forgot this :D <Fox___>IT industry can no longer hope to have young employees only who forgett nothing - at a time when the old men of IT would have to sratch their skulls/hairdos on occasion ... <bavier`>jonsger: I'll have to look at it a bit later, can't download the tar right now <solene>I don't understand where I need to use grub-efi in the config file <j-r>Is there a way to make guix pull use of offload daemon to do the actual the compilation? <jlicht>j-r: not yet, but there was recent chatter on the mailing list to make this happen <jlicht>not quite sure how far this goes into offloading everything, because some amount of computation always needs to happen offline <wsddn>It may be the same sort of problem as jonsger as it also fails in tests/store.scm <wsddn>Specifically "test-name: dead path can be explicitly collected" <bavier`>wsddn: yes, that's what I was thinking <wsddn>bavier: is there anything I can do to help to track the bug down (sadly I don't know Lisp or Guile) <j-r>jlicht: offloading seems not to work quite the same with 0.13.0. Haven't determined exactly why yet. It may be an config on my end, using guix on debian as my offload build machine. <j-r>or it may even be related to guile 2.2.2. <mbakke>it was supposed to be included in the 0.13 manual :( <solene>no problem, manual will be fixed soon :) <quiliro>i am testing the new usb install version <quiliro>i understand it is possible to connect via ssh <rekado>efraim: these hg-checkouts are from the origins that add the openjdk sources. <rekado>I suppose we could add file-name fields to them <quiliro>wow...the documentation is up to date! <quiliro>but it has one error i can report now <quiliro>as the manual says to change the password in order to connect via ssh <quiliro>how to change the live password or what is the password? <mbakke>quiliro: if already have guix installed on a system, the easiest way to get it is by creating a new disk image with that patch :| <rekado>quiliro: the documentation is always up to date when you use Info. <rekado>could you not install the shadow package or won’t this work? <quiliro>rekado: i just downloaded the new 0.13 <quiliro>and it wouldn't provide passwd command <jlicht>rekado: success on the icedtea building! <rekado>mbakke: that’s the info-dir profile hook <mbakke>rekado: maybe we should release 0.13.1 with these problems fixed? <mbakke>and I agree, the java bootstrapping work is indeed impressive :-) <rekado>mbakke: yes, that should be fixed in 0.13.1 too <quiliro>how can i change password without passwd command or know what the root password is on th live GuixSD? <rekado>what’s on the list? #27028, Guile 2.2 memory consumption, offload crash, aarch64 bootstrap binaries, … anything else? <quiliro>how to do this "configure OpenSSH public key authentication"? <mbakke>not sure if the offload crash and aarch64 bootstrap binaries are that important for a 0.13.1 release :P <rekado>aarch64 bootstrap binaries seem trivial to fix, though <quiliro>it is right before 6.1.4.3 Disk Partitioning <quiliro>please someone give me a hand...would like to do remote installation <mbakke>quiliro: do you already have an SSH key? <mbakke>then first create one, on the host you would like to connect *from*: ssh-keygen -t rsa -b 4096 <quiliro>i have to do that because i cannot change the password on the usb installation <mbakke>that will create a private/public keypair in your $HOME/.ssh/id_rsa{.pub} <mbakke>then, transfer the "id_rsa.pub" file to the host you would like to connect *to* <mbakke>you can copy it to /root/.ssh/authorized_keys <mbakke>you may have to create the .ssh directory first with "mkdir -m0700 /root/.ssh" <mbakke>then, you should be able to log in <mbakke>without any passwords (except maybe ssh key passphrase) <quiliro>cool...i will disconnect my usb wifi and connect a usb memory to copy the file....i could not find scp on the installation media to copy it remotely <mbakke>quiliro: np, let me know how it goes! <quiliro>mbakke: would that be 'mkdir -m0700 /root/.ssh/authorized_keys' ? <mbakke>quiliro: nope, just "/root/.ssh" <mbakke>since we're only transferring one public key, and it's already neatly arranged in the same format authorized_keys expect, you can just copy it there <quiliro>oh...so i copy id_rsa as 'authorized_keys'? <mbakke>if you want to add more keys later, use "cat id_rsa.pub >> authorized_keys"