<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
<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.
<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]>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.
<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 :)
<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?
<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