<marusich>We use SH_LOG_COMPILER to define the thing that executes our .sh tests. <marusich>It seems like it just sets up bash to run commands in a test file, e.g. ./tests/guix-build.sh, and fail when any of the commands in the .sh file fail...so, presumably, a LOG_COMPILER is expected to return an exit code to indicate success? And it isn't required to actually create the .trs and .log files (unlike drivers, which apparently *are* expected to do that)? <marusich>I'm asking here because I thought since we wrote it, we must understand it, but if this is a question best suited for the automake email list, let me know and I'll just email there instead. <orelozno1>A happy day, I succeeded the (classic) installation of GuixSD on a Laptop hp ProBook 6460b (without worrying about GPT or EFI). <marusich>My best guess is that the documentation implies that a "log compiler" serves as a way to run a test script when that test script is not itself executable, and in all other respects it should follow the contract for test scripts as defined in "15.2.1 Scripts-based Testsuites". <marusich>orelozno1, awesome! Another platform assimilated :) <orelozno1>For those interested, a summary of this experience can be found here: <snape>marusich: I don't understand either, but you can still go to the source :-) And there is some stuff about it in Automake's NEWS file. <pkill9>orelozno1: does all the hardware work? <marusich>snape, yeah...I checked the email list but that's all I found. I don't know if I'm brave enough to dive into the automake source today. All I wanted was just to know the rules by which we run our tests. <orelozno1>pkill9 : i have X11, the mouse, the keybOard and internet :) <marusich>snape, since some of our *.sh tests explicitly "exit 77" in order to indicate that they should be skipped, I am 99% sure I'm right. <marusich>exit code 77 is the one specified by automake in "15.2.1 Scripts-based Testsuites" for skipping tests. <ng0>imo we should improve the opensmtpd service. right now when something not very obvious has changes (like: 1.5 years without changing and using the config) you just get the default herd message for when services are brøken <rekado>ng0: what exactly are you proposing? <ng0>doesn't opensmtpd have some way to be more verbose about config checks? I haven't read our service definition today, working with what I have. To me it seems like: <ng0>guix system: unloading service 'smtpd'... <ng0>shepherd: Removing service 'smtpd'... <ng0>shepherd: Service smtpd could not be started. <ng0>for example nginx spills errors as we run a quick config check with it <rekado>that’s nothing to do with the opensmtpd service, but with shepherd. <ng0>okay, I've just read it and there's no check in there. I'll see to add it soon <ng0>there's some switches I can't remember right now which check the config of opensmptd. <ng0>I'll be off, good nigh <marusich>snape, I checked the automake source, and it seems that this is in fact what happens. In bin/automake.in, in procedure handle_per_suffix_test, it looks like when no log driver is defined for the extension (.sh in this case), the default is used, which seems to be lib/test-driver, which appears to implement the protocol described in "15.2.1 Scripts-based Testsuites". <OriansJ>umm, wtf? error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory <OriansJ>all of the binaries manually built stopped working after deleting a previous package generation. I am guessing I stumbled into the fact that gcc is probably hard linking to a specific folder for libc and guix is leveraging that to prevent libc conflicts. Which explains why all the old manual builds break upon the removal of the generation that contains the libc being used. <marusich>OriansJ, sounds like maybe something (in the build logic, when you manually built stuff), dereferenced the symlinks. <marusich>E.g. if it dereferenced ~/.guix-profile/foo to /gnu/store/.../foo, then later, when you delete an old generation and ask guix to GC the dead paths, /gnu/store/.../foo might have been removed, so the tool you built maually might not continue to work. <marusich>In theory, the same kind of thing could happen, even if you don't run gc, if that "something" dereferenced ~/.guix-profile/foo to /var/guix/profiles/per-user/$USER/guix-profile-3-link/foo, and then you delete generation 3. But I doubt that would happen; I'd expect a tool to fully canonicalize the path to something in the store. <marusich>Could be interesting to see how your stuff broke. Do you know more? <pkill9>is there anyway to skip building manual database when using `guix environment`? <atw>I am trying to use ghc-edit-distance but it appears to be failing on a version range ("QuickCheck >=2.4 && <2.9") that is not satisfied by our ghc-quickcheck (at version 2.10.1). How can I check on its status in hydra? I suspect that it is also failing there. <atw>Is it bad manners to highlihgt Ricardo at this hour? I think his update of ghc-quickcheck caused this situation with ghc-edit-distance <samplet>atw: You probably need "--allow-newer=QuckCheck" as a configure flag. <atw>samplet: thanks, I will try that. Could that cause problems if the <2.9 constraint was set very carefully and explicitly on the part of edit-distance's author? <samplet>AIUI, we try to follow LTSHaskell 9 at the moment, but for some reason some of the QuickCheck stuff is ahead. There are a handful of packages with that flag. It seems to work in general, but of course it could cause a problem in some cases. <samplet>For instance, I just tried adding that flag to “ghc-uuid” to fix a similar error and it did the trick no problem. <atw>yeah, I see that now. Thanks! <atw>samplet: I am still curious about where the upper limits of these version ranges come from. In edit-distance, for example, was 2.9 the most recent version of QuickCheck available? Does 2.9 then represent the author's anticipation of breaking changes in QuickCheck? <samplet>atw: I don’t really know. They seem to be pretty pervasive. It doesn’t look like anybody is actually asserting that things are broken, though. <samplet>I just learned that they sometimes get overridden on Hackage with “metadata updates” – new constraints for the same code. <samplet>They don’t change the tarball or version number, just replace the Cabal file through a special interface. <atw>Anyway, does this apparent violation of immutability from Haskell constitute irony? <samplet>The best part is that they do it for efficiency: “uploading a whole bunch of code when only metadata changes leads to an unnecessary growth in versions.” <samplet>Anyway, it’s something to watch out for, because we don’t get the revisions when we download the tarball. We only get the original. <atw>Looks like I have the beginnings of an Agda package! <pkill9>anyone have any idea where i can find libgnome-menu? <marusich>pkill9, regarding your question about the manual database, I don't know of an easy way to disable the hook from the command line. However, in scheme code, you can simply pass a different list of hooks to the profile-derivation procedure. <pkill9>it takes a while when i'm rapidly making new environments when adding new inputs <pkill9>like i go into environment, try to build, see what dependency it's missing when teh build fails, exit environment, and go into new environment with input added <pkill9>i should learn to read build files <marusich>Well, the purpose of the profile hooks is to facilitate the correct installation of the requested packages, which sometimes includes documentation. <marusich>But, you could always try disabling them to see if it's really faster for you. <pkill9>nah, it would just build everything from source <pkill9>oh, you mean in the part of the source that builds the profile <marusich>In addition, although each different profile might require slightly different derivations to build some of the profile hooks, I think that because it's done using derivations, they will also overlap a bit, so if you're building a lot of profiles with similar inputs, it might be faster? <pkill9>ah ok, so maybe it will be quicker over time as long as i don't run `guix gc` <marusich>perhaps, I haven't tested it but if it's using derivations and the inputs don't change much, one would expect that would be so. <pkill9>i'm getting this error using the json importer, when using one of my custom made packages as an input: ERROR: no code for module (#{}# home me guix-recipes gnu packages budgie-desktop-deps) <pkill9>my custom-made input is in the budge-desktop-deps scheme module <rekado>I’m very happy to see that there are lots of substitutes for i686. <marusich>Hi rekado. Nice to hear! I'm off to bed now. Goodnight! <ng0>is anyone using dovecot on GuixSD? It seems like we are supposed to provide ssl_dh=</path/to/dh.pem with v2.3 <lfam>ng0: Does it have a default value? I'd expect it be something like /etc/dovecot/dh.pem <nckx>ng0: every day, but not the Guile configuration wrapperz I guess you're talking about. <ng0>I was just at the beginning of my search <lfam>Those notes aren't totally clear to me. Does it no longer default to '/etc/dovecot/dh.pem'? <ng0>the same page nckx posted: ssl-params process has also been removed, as it is no longer used to generate these parameters. <nckx>I try to go through the release notes of every new Dovecot version and update the service, but since I don't use it... *unicode shrug thing* <nckx>lfam: I think you have to both generate and specify it manually. I wonder what I did. <ng0>I came from a dovecot mailinglist post where they wrote it needs to be set explicitly <lfam>Well... sounds like someone needs to adjust the service :) <nckx>~$ grep dh /etc/guix/mail/dovecot.conf <nckx>It seems I won't be much help today. <nckx>Or until someone convinces me of the value of generating such configuration files from Scheme. <ng0>to provide more context, the dovecot service in the default configuration currently doesn't work anymore. I think it should be enough to add the value with a default.. I can try this but I'd rather spent time learning today. <ng0>we also would nedd to generate the DH on activation so that the file exists if nocustom location is given <ng0>I have a need for this, I think I'll give it a try <ng0>question: is the dovecot-configuration like cups generated? or was it added and edited by hand? <nckx>ng0: manual, I think. I hope, since I've mangled it by hand at least once. And its pretty docs, too. <nckx>I hate answering questions with ‘I think’, but I guess no-one's here who knows for sure... <ng0>would it be too much togenerate a DH key on frist activation? I have my keys, but is this too much delay for an activation? <lmao_>I tried to create new xsession but the directory is write protected <lmao_>Am I supposed to create it using the configuration file? <nckx>ng0: It's only needed for older cypher suites (as implied above: I don't even have or need it), so I vote no. But you're the one writing code. Supporting (ssl-dh #f) would be nice if nothing else. <ng0>string would #f be similar to an empty string in dovecot configs? <ng0>s/string would/would <pkill9>I don't think `guix import json` works when the json specifies an input that's in a module that's placed in $GUIX_PACKAGE_PATH, Guix fails with an error saying 'no code for module'. Is this known and can anyone reproduce it? <lfam>nckx, ng0: I think that wingo knows for sure because he made the service originally <nckx>ng0: It would simply not add a ssl_dh line at all (like in my .conf) and not bother generating the parameters, which aren't always useful. <ng0>well right now this leads to my Dovecot not accepting connections <ng0>this is still with the Guix default certs <ng0>as in.. dovecot: imap-login: Error: Failed to initialize SSL server context: Couldn't parse DH parameters: error:0906D06C:PEM routines:PEM_read_bio:no start line: Expecting: DH PARAMETERS: <nckx>Sure, that's because of the default ssl_cipher_list. <ng0>my old dovecot manual edited configs are long gone in digital dust. so, shouldn't we switch to other defaults then? <nckx>I think we should stick with upstream's defaults (whatever they may be) which do need DH parameters, but add an option to disable their generation entirely. <nckx>My ssl_cipher_list is ECDHE+CHACHA20:EECDH+ECDSA+AESGCM:EECDH+AESGCM. <ng0>I think we should stick to safe defaults. upstrema is not always right and safe <nckx>Could theoretically cause problems with ‘older clients’ but I haven't had any. I live a sheltered life. <nckx>^ you can use that string for testing without ssl_dh, btw. <nckx>Sure, but I don't pretend to know enough about the matter to know what's both safe & secure, and actually works with a user base > 1. :-) <ng0>that's a bit longer then the one I have in use somewhere.. which is just AES256+EECDH:AES256+EDH:!aNULL <ng0>yes, but they are defaults. people who have different needs will change them <ng0>they have the ability to override them <ng0>actually the same error happens with your ciphers here. <ng0>I'll try with the certs from my CA instead of the selfgenerated GuixSD ones <nckx>Ehm. Weird. Is it because I also have ‘ssl_min_protocol = TLSv1.2’? No idea, all I can say is it works. <nckx>I'd like to paste the whole file, but... eh, hm. <ng0> -- ‘dovecot-configuration’ parameter: string ssl-min-protocol <ng0> Minimum SSL protocol version to accept. Defaults to ‘"TLSv1"’. <nckx>Not 100% comfy with that. <nckx>ACTION uses LE certificates btw. <nckx>Although I don't think that should matter. <ng0>I'm still adapting.. works for webserver, sucks for the rest as far as I have tried <nckx>They're (still) RSA AFAIK. <nckx>The process or the certificates? <ng0>the certificates and their locations, permissions etc <ng0>I have my own CA.. but as you said up there, it's only useful for small isolated userbases ;) <nckx>The HTTP method that everyone recommends sucks, but LE + DNS is awesome. <nckx>(‘Everyone’ = the consensus of low-q tutorials on the Web, not LE themselves.) <lfam>ng0, nckx: Do you use certbot or another client? <ng0>certbot for LE. and mostly bash + openssl for my own. <ng0>gahr. lessong to learn from this: never abandon a mailserver. getting the config right again which used to work is a pain. <nckx>lfam: mcron + certbot + my own hooks to call nsupdate & friends. <nckx>And a nested list of domain/certificate names in /etc/guix/system.scm. Works like a charm. <nckx>* my OCD version of config.scm, blech. <nckx>+ a few specific fix-ups for things like ZNC which require concatenated certificates etc. OK I'm done now. <nckx>ACTION stopped just in time not to get started about openSMTPd's stupid security theatre dance <nckx>Question: does htop's tree mode (‘t’) work for anyone on recent master? <ng0>it just goes all dark.. but I thought that's because of my incredible custom environment. <nckx>ng0: :-D So did I. I guess not. Bisectin' time is here. <lfam>Well... how recent? I'll try since the core-updates merge <nckx>lfam: I think it was pre-that, but I'm not sure yet. Will debug properly now that I know it's not just me. <ng0>yep, I had it before the merge <lfam>Indeed, it still works for me. I'm using the rxvt-unicode terminal emulator from Guix <ng0>I'm using my own version of st. <nckx>I'm using... uxterm, both locally and through ssh+GuixSD server. <nckx>ACTION builds rxvt-unicode for bonus data points. <lfam>Tree view works for me in Guix's uxterm, but there is some bogus black space in the negative space of the resource meters <lfam>It could also be affected by your font, I suppose <nckx>My god we have so many commits. <efraim>glibc-intermediate-2.27 wants bison as an input <rekado>pkill9: “guix import json” is very simple and I’ve never used it for anything serious. It’s very likely missing features. Could you provide some more details to allow me to reproduce it? <lfam>nckx: Yes, bisecting Guix is *not fun*. I should finally make a fool-proof Guix bisection script that could be automated in a while loop <nckx>Is there a sane way to ask git ‘give me the first commit after $DATE’? <nckx>My grep spaghetti is fine & all but it feels like there should be a better way. <lfam>AFAICT, dates are meaningless in Git <nckx>lfam: Oh, sure, agree, but assuming you trust the committers enough in this case. <lfam>Right, but I don't reset dates before pushing old patches. For example, I pushed some old commits to the new core-updates branch <nckx>Ditto. But there's objectively a *first* commit with date >= 1 Jan 2017 and that's good enough for me, y'feel? <lfam>nckx: Take a look at this: `git reflog --date=local origin/master` <lfam>IIUC, that command shows the dates that the origin remote received the pushes <lfam>So, it's more reliable than the dates on the commits themselves ***danialbehzadi1 is now known as danialbehzadi
<nckx>lfam: I agree with the spirit of your ‘meaningless’ quip, but it's a bit broad. ‘Misunderstood’, ‘easily forged’: sure. <nckx>efraim: Is that in reference to htop? Does it work there? <pkill9>rekado: I can't really provide any because I'm kinda just doing it trial and error without understanding fully, maybe someday someone more experienced than me can help <lfam>I wasn't careful with that statement. They don't provide a linear timeline, and so they can't really be used in the way a person would want to use them. But, the remote reflog is more useful in most cases <lfam>They don't even get updated when you do `git commit --amend`, which I do constantly. It's really just a timestamp of the local time when I first started working on a patch, which I don't think anyone else really cares about. <nckx>There are also multiple dates associated with a commit IIRC, which I never researched since I never needed to. <nckx>Also, I thanked ng0 when I should have thanked you. Thanks for everyone! <lfam>The time zone database changelog is always good for a laugh <lfam>"A discrepancy of 4 s in timestamps before 1931 in South Sudan has been corrected." <nckx>‘This broke my workflow.’ <clacke[m]>now you've reset not only the author name but also the author time <clacke[m]>but I agree that dates in git are ... difficult to say what they're good for :-) <efraim>nckx: yeah, I don't know, I haven't tried it <wigust>nckx: There is a Git “Author date” and “Commit date”. Is ‘git log --since='2018-02-19' --date=local --format='%cd %s'’ what you want? <nckx>wigust: Probably! Thanks. <lmao_>how do I create xsession manually in guixsd? I'm trying to install exwm <mbakke>I wonder if it's okay to update evolution-data-server to 3.26 without pulling the rest of GNOME 3.26. <mbakke>It's needed for libical 3 compatibility. <mbakke>lfam: The tzdata 2018 fix rebuilds tzdata-for-tests. <ajjh>I'm trying to install texlive package but guix gives me an error which tells me "TLS error in procedure 'read_from_session_record_port'" <vagrantc>hmmm... i've been running a toy guix system for a few months now, and i've finally run out of space ... time to actually learn how to clean up old revisions <janneke>vagrantc: have you run guix gc at all? <sneek>Welcome back janneke, you have 1 message. <sneek>janneke, OriansJ says: that path support has been added to kaem and that patches are up <vagrantc>janneke: never ... do i have to explicitly remove old generations and so on? <vagrantc>or does guix gc guess which versions are old enough to clean? <vagrantc>seems to be deleting a lot after just running it as the user <janneke>guix gc will not delete anything that's not garbage, <janneke>i.e., that's not linked in any profile generation <janneke>vagrantc: deleting a profile or system generation will make packages references by that profile only available for gc <vagrantc>so, given that i've never deleted either a profile or system generation, what's it actually cleaning out? <mbakke>vagrantc: You'll need to manually remove old profile generations with something `guix package -d 1m` to delete all that are older than one month. <mbakke>For system generations, you actually have to manually remove the symlinks in /var/guix/profiles. <janneke>or build dependencies that got installed to build a package <mbakke>vagrantc: Yes, and build inputs that have been downloaded but are not runtime dependencies. <mbakke>"tar" fails for me on core-updates <janneke>jayspeer: i have no knowledge/experience of that, but tell us your problem <jayspeer>Even though I booted in uefi mode I am unable to install grub in uefi mode. modinfo.sh is missing. As far as I know guixsd 0.14 supports uefi platform so it should be included <janneke>jayspeer: can you tell us the guix command that you issued, and the exact error message you get? <jayspeer>guix system init /mnt/etc/config.scm /mnt <efraim>mbakke: i updated bash locally to 4.4.19 and built to hello on aarch64 <jayspeer>but the error is the same when I try to install rub <jayspeer>grub-install: error: /path_to_grub_in_gnu_store/lib/grub/x86_64-efi/modinfo.sh doesn't exists <mbakke>Oh, ok. The machine I'm running on uses Ceph as the underlying storage, I've had trouble with other test suites. <mange>jayspeer: Can you show us your config.scm (in a paste)? How are you running grub-install when you run it yourself? <efraim>I can't build syncthing on my laptop since something always fails tests on btrfs <jayspeer>As I said, problem seems to be with grub in gnu store, id doesn't have tools needed to finish installation <jayspeer>error message: grub-install: error: /gnu/store/xqfpwxbghvi3h85pfji6kdzw7db2sgxz-grub-2.02/lib/grub/x86_64-efi/modinfo.sh doesn't exist. Please specify --target or --directory. <mange>What happens when you specify --target or --directory? <wigust>jayspeer: Please don't use pastebin, because of tor users. Is a (file-system … (mount-point "/boot") (type "vfat")) really what you want? Maybe ‘/boot/efi’? <mbakke>I've set TMPDIR to /dev/shm, maybe that works better. <mange>There is an example UEFI config.scm in the manual at "(guix) Using the Configuration System". It has a partition for /boot/efi instead of /boot, as wigust is suggesting. <jayspeer>wigust: Thank you. It doesn't seem to be a problem with config.scm. I am unable to install grub outside of installation procedure. Grub seems to be missing some important tools to finish installation. <wigust>jayspeer: What is they exact command you invoked to install Grub manually? <jayspeer>wigust: to name a few combinations: grub-install; grub-install /dev/sda1; grub-install --target x86_64-efi /dev/sda1 <wigust>jayspeer: doesn't look like which Guix install uses at all <ng0>anyone using cvs or git cvsimport on Guix/GuixSD? <mange>jayspeer: Do you have your EFI partition mounted on /boot/efi? <jayspeer>I mounted it at /mnt/boot, according to my config.scm. I am testing {/mnt}/boot/efi configuration now <thomassgn>I have a program that depends on libgdm, but I only see GDM, I'll just try adding it as an input, but does anyone know if libgdm is something smaller/more lightweight than the full GDM? <jpt4>I have GuixSD running on a Dell Latitude 2110, my spare laptop for travel and tinkering. <jpt4>(Also immune to Spectre/Meltdown, because its Atom processor doesn't have the vulnerable branch prediction capabilities.) <jpt4>I am trying to get an X server running without altering my global system config, i.e. without enabling %desktop-services and reconfiguring. <lfam>ng0: Is it on GuixSD or another distro? <jpt4>Sorry, jumped in to the wrong conversation. <jayspeer>ok I figured it out if anyone is interested <mange>I'm interested! What was going wrong? <davidl>/mnt/boot/efi during install I believe. <davidl>didn't see you needed help until now :/ <jayspeer>Another problem - I forgot to set user password <efraim>if you log in as root you can run `passwd $user` to set the user password <davidl>im having problems with guix pull <davidl>it tries to build 0.13.10 and fails <davidl>same happens with a guix system reconfigure command <mange>Does it need to be mounted at /boot/efi, or just /boot? <jayspeer>mange: I did it at /boot/efi because it is what I specified in config.scm <davidl>mange: during guix system init you it works when mounted at /mnt/boot/efi but then needs changed <jayspeer>This has no sense, someone should change it <davidl>i thought so too at first, but then what if path is relative to /mnt such that /boot/efi in config.scm is *really* in /mnt/boot/efi? Then you wouldn't be able to specify all targets. <mange>So, does that mean you need to change the config file after the guix init for each subsequent reconfigure? That doesn't sound ideal. <davidl>i.e. only once after init. Not every reconfigure. <mange>I don't understand what you just said about the relative path. Can you explain why this is a sensible for this to work? <mange>I didn't do an EFI installation, because I frankensteined my debian installation into a GuixSD one, but that seems pretty strange to me. <jayspeer>I don't agree with davidl. We should only specify mount point for efi partition single time <davidl>jayspeer: what if you have your efi boot partition on a separate usb drive or a remote folder? would that work if target path is relative to /mnt such that /boot/efi is /mnt/boot/efi? <davidl>i might be wrong. I was just trying to come up with an explanation for it yesterday. <mange>It just seems really strange to me that saying "/boot/efi", which is an absolute filename, is re-interpreted relative to /mnt. I would have expected that if I specify "/boot/efi" in my config.scm then it will write to "/boot/efi", not "/mnt/boot/efi". <jayspeer>still you should only provide the latter path - which should be the same in both cases. We operate on partitions, not some relations between paths. IMO guide should instruct us to mount partition at /boot/efi and not another location. If I recall gentoo install handbook they instruct you to do exactly that <mange>If I have my boot partition on a USB or a remote folder then I can put in a different path, or I can mount the USB/remote folder in a different place. <jayspeer>mange: In both cases boot partition is not part of the operating system - it mount point doesn't have anything to do with how system works. After booting you should be able to, without any remorse, umount /boot partition and system should remain as it was. Grub assumes that this exactly what we are doing during installation <jayspeer>I think the manual doesn't say anything incorrectly, it is just not noob friendly <davidl>mange: I guess you can always create a folder in /mnt/mydir and mount the efi-partition there with /mydir as the efi target. This new bootloader configuration syntax was recently changed and maybe there's a note about it in the Guix source code. <davidl>jayspeer: definitely agree about it not being noob-friendly. <jayspeer>Well, to sum it up. /boot exists to mount boot partition, end of story ;) <iu>Hello! I am trying to run guixsd in LXC container. I have rootfs tarball, but what is the name of init process? <iu>LXC expects /sbin/init to be present <mange>jayspeer: Yep! Or, actually, it should have /bin/sh. <iu>What should I link it to? <jayspeer>mange: Where do all the utilities come from? <wigust>jayspeer: Just stick to the documentation, you'll be ok :-) <mange>jayspeer: It's a bit complicated, but the simple version is look in /run/current-system/profile, and ~/.guix-profile. They have symlinks into /gnu/store. <Sleep_Walker>I finally compiled Guix package for openSUSE (yeah, it really took me that long) - but I got this error message for many commands, this one is generated by `guix package -i icecat' - https://ptpb.pw/k75S <jonsger[m]>oh hi @freenode_Sleep_Walker:matrix.org nice work :) <jonsger[m]>@freenode_Sleep_Walker:matrix.org: what steps are necessary to get the guix-daemon.service up and running after installing guix from OBS? <Sleep_Walker>wow, so, I'm here using XMPP and IRC transport to talk to you via IRC gateway of matrix network? pretty complicated :) <jonsger[m]>yeah. I just started to test matrix. I'm not really enthusiastic about it, but it has history :P <jonsger[m]>btw we could maybe try to enable aarch64. guix has support for it now... <Sleep_Walker>well, we can enable aarch64 - I'm looking forward to try that too <Sleep_Walker>so, next step should probably be pushing guile 2.2 to factory <jonsger[m]>It's not working yet, but at least it's building... <Sleep_Walker>jonsger[m]: we could build gnutls against guile 2.2 to make it at least working for us until guile 2.2 is in factory <jonsger[m]>oh bad. @freenode_Sleep_Walker:matrix.org I would say let us try to make it working for us :) <jayspeer>have anyone encountered problem with network connection after installing guixsd? I do not receive any dhcpack after dhcpdiscover. Both wired and wireless <Sleep_Walker>jonsger[m]: I made you maintainer of home:sleep_walker:guile, there you can hopefuly find gnutls built against guile2.2 once it gets to an end <Sleep_Walker>I need to go to sleep and won't have time tomorrow for that... <jonsger[m]>good night. due the fact that we don't getting it into Leap15 there is no time pressure :P