IRC channel logs
2018-06-02.log
back to list of logs
<civodul>it looks like a very different language from current Nix though <civodul>so i suppose the transition would be difficult <buenouanq>Are we ready for the EOMA68 finally? ARM and uboot <buenouanq>if there's going to be another delay I wish they'd tell us sooner <civodul>vagrantc: i think at FOSDEM two of us got a prototype EOMA68 board but i'm not sure what happened with those <civodul>so it seems like progress is being made, AIUI <rekado_>I thought the project was stalled because Luke was looking into building/modding a 3d printer first. <uniq10>rekado_: Thanks. I will try something like that. <rekado_>there is remarkably little activity on the mailing list. <rekado_>uniq10: I don’t know if my comments are actually helpful in this particular case. <rekado_>uniq10: if you’re in doubt I recommend sending email with some examples or pseudo-code. <rekado_>ACTION —> zzZ while building R packages <pkill9>at some point i'll post to r/unixporn, with screenfetch output, as a sneaky advertisement for GuixSD :P <OriansJ>pkill9: I would assume, run 2 commands and have your entire computer setup the way you like would be enough but I guess showing the sort of tweakage possible might inspire others <cbaines>Copenhagen_Bram, if you have an existing GNU/Linux installation, you might want to consider installing Guix as a package manager <cbaines>Ah, so rather than installing GuixSD in qemu, have you considered using the guix system vm command? <cbaines>That would give you a VM, but I guess if you're planning to do the installation anyway, going through the manual steps in a VM is probably worth it <cbaines>I don't know how to do that via the guix package command <cbaines>If that package is the only one to have changed with the change in the profile generations, then rolling back a whole generation will have that effect <Copenhagen_Bram>IntoxicatedHippo: You can install an earlier version with guix package -i packagename@versionnumber1.2.3 <amz3>does the rollback feature works on guix (not guixsd) ? <amz3>I mean does it make sens? <cbaines>amz3, rolling back is just changing the profile version/generation you're using <cbaines>when not using GuixSD, you have profiles containing packages <cbaines>when using GuixSD, you also have a system profile <cbaines>you can change generation (rollback, and add new ones) for all profiles <IntoxicatedHippo>Doesn't seem to work when the package is no longer in the packages list (or whatever it's called) <cbaines>Yep, the @version feature doesn't work the same as rolling back generations <cbaines>IntoxicatedHippo, do you update Guix via guix pull? <IntoxicatedHippo>I could just make my own emacs package but I was hoping theres a way to just use one that's already in the store <cbaines>IntoxicatedHippo, you might be able to do guix pull --commit=... to get back to the version of Guix that the Emacs you want to roll back to is from <cbaines>at that point, you could remove Emacs, and then re-install it, which should have the same effect as rolling back <cbaines>IntoxicatedHippo, I've just discovered something... <cbaines>Perhaps try this, guix package -r emacs -i /gnu/store/... <cbaines>where you replace ... with the name of the Emacs package in the store that you want to roll back to <cbaines>I just tried it here, and it looks to have worked <cbaines>Even if it does, you can guix package --roll-back :) <IntoxicatedHippo>Next question, is there a way to do that for packages that are part of my os config (or whatever the proper name is) <cbaines>IntoxicatedHippo, you might be able to pull of the same trick, using the full filename of the item in the store <cbaines>ok, why do you need Emacs installed in your system profile, as well as your users profile? <IntoxicatedHippo>I guess it doesn't need to be in my user profile, it's just there for some reason <cbaines>I would suggest the opposite approach, your probably better off just installing Emacs in your users profile <IntoxicatedHippo>It's in the system profile because I need emacs-exwm in the system profile so I can select it from slim <cbaines>In this case, tweaking the package definition in your GuixSD configuration is probably the way to go <cbaines>as in overriding the version and the source <rekado>FWIW I use EXWM but don’t have the package in the system profile. <rekado>it’s just a regular package in my default user profile. <rekado>you just need to have an executable .xsession in your home directory. <g_bor[m]>I remember, that there was a discussion here, how to import a single function from another file, that I only want to use in a single package definition, but I can't remember how that was done. <cbaines>if you are using define-module, then the syntax is similar, I think it also uses select <cbaines>there is also this syntax: (@ (ice-9 popen) open-pipe) <g_bor[m]>Actually it goes like this: we have a package in java, that is a bootstrap package. It can't use ant build system, as it is not available at this stage of bootstrapping. Ant build system has a function I would like to use, but only that function, and if possible only in that package. <cbaines>Ah, ok, doing so as part of a build system changes things <cbaines>When I packaged deja-dup (in gnome.scm) I used multiple build systems, you could have a look at that? <g_bor[m]>cbaines: Thanks, I will have a look. Actually having the function imported in the module would not be a big problem, but I just want to pollute the namespace. <g_bor[m]>We had a discussion with rekado earlier, that it would be a good idea to separate language bootstraps to modules, as we are sometimes doing quite unusual things there... <siraben>How do I check if my substitute server is authorized? <g_bor[m]>oops something is wrong in our build system. doc/contributing.fr.texi and doc/guix.fr.texi is deleted on make clean. After that ./bootstrap fails with automake error cannot open ./doc/guix.fr.texi. <Copenhagen_Bram>How do I copy and paste text in files? I can't seem to paste text in any of the available text editors <roptat>g_bor: I need to do someching about it <siraben>In most terminals that's how it works anyway <roptat>but I can't do anything until monlay <siraben>But you need to have something cut first <siraben>So, C-a to go to the beginning of a line, C-k to kill it <siraben>Haha, I feel right at home with zile <siraben>If I cut something at any point in time I should be able to recover it. <siraben>I find that feature to be very useful in Emacs <g_bor[m]>siraben: There was some magic civodul posted a few days ago to check authorized servers. I'm looking at it in the logs. <siraben>I just realized when I go to school, my mirrors are very slow, but at home they are fast, despite the internet speed being faster at school <siraben>e.g. it's a difference of >= 1 Mbps vs ~ 30 Kbps <siraben>Copenhagen_Bram: Why not try installing Vim? <siraben>g_bor[m]: Yes I happen to authorize both Berlin and Hydra <siraben>Copenhagen_Bram: You didn't enable the cow herd <siraben>If you're on a VM or running the installer, you need to tell it to use the disk space <siraben>g_bor[m]: But when I change the systemctl daemon and run guix pull, it compiles perl... <siraben>I change the systemctl daemon to see mirror vs hydra performance <g_bor[m]>siraben: If you can, please do, and share your results. <siraben>How would I do such a benchmark? Can I download binaries without installing them? <siraben>Guix could be improved by incorporating some features from apt <siraben>apt has a lot of mirrors, and you can let it find the "best" one <siraben>hm.. and fixing the console output which seems to be weird sometimes <siraben>I'll look into the source when I have more time. <g_bor[m]>siraben: as far as I know apt does a ping like benchmark on the mirrors. Download continuation would be nice. Console output cleanups are work in progress, at least for guix package, you can see the related outreachy project propsal on the outreachy website, the completed code on branch wip-sahithi. <siraben>g_bor[m]: By the way what does the [m] mean? <g_bor[m]>I am connected through a matrix-IRC bridge. <Copenhagen_Bram>although personally I thin the matrix-IRC bridges are slow so I use weechat for IRC <roptat>g_bor: if you want to fix it, you can <g_bor[m]>Actually I had to propose a solution to my clients to use for secure communications. I proposed matrix and ring. And I got used to it. <roptat>I just don't have access to a computer this week-end <rekado>my laptop shut down again because I didn’t realise my battery was low on power; now the guix git repo is corrupt :( <g_bor[m]>roptat: I guess the proper fix is not to delete these files in make clean. Am I right here? <roptat>there should be a list of things not to delete <g_bor[m]>siraben: It is ok for my usecase, which goes like I only have 1:1 audio calls, over smartphones paired by QR codes. Actually I have not tried it for other uses yet. <g_bor[m]>Text messages also work. I could not get video working on my phone. <siraben>But then, I've tried it only on my local network <siraben>So icecat is downloading at 20 KiB/s ... <pkill9>are there any wayland window managers in guix? <pkill9>how much progress have you made on that? <mbakke>There is some rudimentary Wayland support in GNOME on Guix. <cbaines>Does anyone know of a way to copy derivations from one machine to another, without having to go through the signing key faff? <civodul>cbaines: you could do: GUIX_DAEMON_SOCKET=ssh://otherhost guix build foo -d <cbaines>however in this case, I'm trying to copy derivations from a machine I have SSH access to <cbaines>I haven't setup SSH access in the other direction <jlicht>cbaines: you could set up a reverse SSH tunnel-thingy <OriansJ>netcat -l $port < foo for serving up a single file <g_bor[m]>I am looking around this issue, that running make clean breaks the bootstrap script. I have a feeling that this should not happen, although the expected behavior of this is not documented. <g_bor[m]>We talked about forcing make clean not to delete the french manual texi files, but it might happen, that bootstrap should be modified instead to work if these are missing. I'm currently checking, if make can regenerate the files... <jlicht>g_bor[m]: ah nice! I've kept running into this the last few weeks as well, but thought it was just something silly on my end <OriansJ>g_bor[m]: shouldn't make clean in a git repo just be git clean -xdf <g_bor[m]>OriansJ: it seems that we are using the default automake clean rules here, and it seems that it works out just fine. And this way it works even if the source you get is not from git... <g_bor[m]>But this is my first round around this part of the code, so I don't really know about other motivations. <OriansJ>g_bor[m]: wouldn't one want to pack the .git in the tarball to enable a simplified update method; <jlicht>OriansJ: You want to release the entire git repo in a release tarball? <g_bor[m]>OriansJ: Actually I don't know how this is currently done. I will have a look. <g_bor[m]>OriansJ: currently we don't have it in the tarball. It might be too big. <jlicht>OriansJ: I guess this would not be a problem yet for guix, but it does seem unconventional. It would not make sense for some bigger-repo projects (e.g. emacs) for sure though <g_bor[m]>And it would be nice to have a working make clean if git is not installed... <OriansJ>isn't that why git clone --depth 1 $URL for shallow git clones exist, it only has the current and not any of the history <g_bor[m]>jlicht: it seems that the french manual texi files are generated just fine by make. <jlicht>g_bor[m]: the problem for me occurs when I `make clean -> ./bootstrap'. I do not know if a simple `make' would suffice to fix it; Right now, I just recover the manual via git if I run into this situation <OriansJ>g_bor[m]: would it be reasonable to default to the git clean -xdf option if git is installed and fall back to the current automake clean function if not available? <g_bor[m]>jlicht: and the checked in texi files are stale. I guess we should not depend on them bootstrap, and I don't think it is wise to have them in the repo either. WDYT? If we always build them, they don't become stale. <g_bor[m]>OriansJ: actually this might worth an e-mail on guix-devel, so we could see the pros and cons more clearly. I would not take this step until we have some more opinions on this topic. A depth -1 clone would solve the size problem for sure. <g_bor[m]>OriansJ: Could you please write a mail to guix-devel summarizing the discussion we had here? <jlicht>g_bor[m]: If we always have all information to re-generate the translated texi files, I really don't see them having a place in the git repo. Definitely in the release tarballs, of course. Maybe someone who worked on the French manual in the first place can tell us more on why we have what we have right now? <g_bor[m]>jlicht: roptat is working on this, he said, that he will not be at computer this weekend, and I said that I will have a look around this issue. The only drawback seems, that the french manual is not readable from a git checkout, until make is run. WDYT? <jlicht>g_bor[m]: As a (non-French) programmer, I would always try to keep generated artifacts out of a repo. Although if we look at e.g. `guix.texi', which is also a generated file, we see that it is also left alone by make clean. So for consistency I think it would be best for now to just have `make clean' leave both alone. We could at any later time still go with your suggestion, but then we can do it in one go for all g <jlicht>enerated documentation so we don't have these inconsistencies again. WDYT? <jlicht>heh, ignore the 'me not being French' part, it no longer really fits in that sentence after rewriting it <g_bor[m]>jlicht: ok, the I will stick with the original idea, and try to come up with a fix so that make clean leaves these files alone. <g_bor[m]>jlicht: ok, I have found the problem, and also a possible solution. The problem is, that these manual files are registered as BUILT_SOURCES in doc/local.mk. So automake thinks, that make builds these files, and on make clean removes them. The easiest solution would be to remove these files from BUILT_SOURCES. This will not break in the current situation, as we have these files in the repository. <Copenhagen_Bram>Gmorning guys. The virtual installation of GuixSD for practice is proceding slowly, thanks to my slow internet. <roptat>g_bor: makesure the release tarball still have the files though <OriansJ>Copenhagen_Bram: you can always use a local repo as a proxy for better performance <OriansJ>Copenhagen_Bram: you only have to download and cache which that you wish to use and nothing more. aka if you need to provide 1GB of binaries for your guix virtual machine that is all the space you need; if you need 100GB of binaries for your guix virtual machine, that is the amount of space you will require. <pkill9>how do you use a locla repo as a proxy? <OriansJ>well you simply leverage substitutes and publish if you so desire <OriansJ>Once a publishing server has been authorized (see Invoking guix archive), the daemon may download substitutes from it <g_bor[m]>roptat: The files are still listed in extra_dist. <g_bor[m]>I believe that's enough for them to be included in the release tarball. <g_bor[m]>This is a snippet from the automake documentation: "However maintainer-clean should not delete anything that needs to exist in order to run ‘./configure && make’.". I believe we should include running ./bootstrap to that list. WDYT? <g_bor[m]>If you agree, I will also remove the french manual files from maintainer-clean files. <Apteryx_>hello guix! has anyone successfully transfered files via bluetooth from an Android phone to GuixSD? <Copenhagen_Bram>Apteryx_: i'm sure bluez would work just as it would on any other distro <Apteryx_>My understanding about receiving files over bluetooth is that there needs to be some obex daemon, and that nowadays bluez doesn't do this directly but provides the means for clients such as Nautilus or such to do so through DBus. <Apteryx_>I have bluez installed but by itself it doesn't do much to accept files transferred by bluetooth. I'd be happy to be proven wrong :) <Apteryx_>The phone is paired with my GuixSD (bluez 5.44) but attempting to transfer files fails (reason: Connection unsuccessful) <roptat>Copenhagen_Bram: yes! then you need to run guix system reconfigure <ngz>I have a path question. A package has executable and data in /prefix/share/pkg/. I'd like to create an executable in /prefix/bin/. Unfortunately, configuration has relative file names. As data is in share/pkg/, it cannot be found when calling the executable located in bin/. <ngz>Using a subshell to change the cwd before calling the executable in share/pkg/ is not an option. <ngz>Using a symlink doesn't set cwd to share/pkg/ either. <cbaines>ngz, surely having the executable on the PATH isn't going to be very useful if you can only run it from a single directory in the store? <Copenhagen_Bram>I have an installation question. In /mnt/etc/config.scm I set the bootloader target to /dev/sdb. But I just realized that when I boot from the hard drive instead of live GuixSD, the same device will become /dev/sda. So what do I do? <Copenhagen_Bram>Also, thank you writers of the Guix manual for helping me learn how to use gdm and how to connect to the internet without a network manager <efraim>hmmm, --with-source doesn't affect vim, this will take a bit longer it seems <ngz>cbaines: this is why I'm currently using a shell scripts that starts a subshell where the cwd is appropriately chosen. But that doesn't work perfectly. <cbaines>Copenhagen_Bram, I'm no expert, but I think that should be fine <cbaines>Just make sure the other file system bits are correct <cbaines>(or wait until someone more informed can help) <cbaines>Is getting the program to use absolute filenames feasible? <ngz>Not really, because they could leak in user config. <cbaines>ngz, I guess the way the program is written, it's not really designed to be installed in the usual sense then? <cbaines>if it's packed for other free software distributions (e.g. Debian, Nix, ...) you could have a look at the approach they take? <Copenhagen_Bram>Do you guys consider qt-webengine to be nonfree because it uses parts of chromium? I really wish I could install anki on an FSF distro <cbaines>I've used Anki on Debian before (with any non-free bits as far as I'm aware) <efraim>i think i've tracked the vim test failure down to 8.0.1440, testing the fix now <ngz>cbaines: Apparently Debian succeeds, i.e., executable is in /usr and ini files in /etc without problem. Odd. <Guest875>Hello, I was just reading guix's blog about running system services in containers... <Guest875>ie: run Firefox but give it write access only to ~/Downloads ? <Guest875>Copenhagen_Bram well I know there are some lightweight programs that can do this at the moment...but I hope hoping vanilla guix already supported it. <cbaines>Guest875, I remember some discussion of this on the mailing lists... let me see if I can find it <cbaines>but I think there have probably been more <pkill9>shouldn't all the font packages have search-paths? <pkill9>or are search paths only specified if the package itself requires them? <vagrantcish>so, i'm having a bit of time configuring the system to mount the efi partition ... it rejects the very short vfat UUID, not sure how to set a label on vfat, doesn't seem to support partuuid directly... <Copenhagen_Bram>Hmm, guix doesn't seem to be responding. I typed `guix system init /mnt/etc/config.scm /mnt` but it doesn't seem to be doing anything <efraim>(device (uuid "F010-1913" 'fat)) <efraim>Copenhagen_Bram: it should be 'herd restart guix-daemon' <vagrantc>efraim: i did end up just using /dev/disk/by-uuid/XXXX-YYYY <efraim>'herd status' lists all services <Copenhagen_Bram>guix package -s qemu isn't doing anything either. guix help works though <Copenhagen_Bram>hmm, i restarted the virtual machine, Now guix system init is working (after 10 minutes) but guix package -s seems unresponsive.