<lle-bout>I'm having an issue with gpg on GNU Guix. It wont ask me for my passphrase in a GNOME dialog, any idea how I could solve that The Guix Way? Thanks in advance. <jonsger>rekado_: when pulling from 995b391 I get: nginx: [emerg] no "events" section in configuration <lle-bout>Blackbeard: I'm running it from GNOME Terminal with a standard GNOME Desktop configuration straight out of the installer <lle-bout>I also tried running 'gpa' and trying to change the passphrase of my key by doing 'Edit Private Key' then 'Change Passphrase' and it just does nothing. <lle-bout>My key does have a passphrase since when I try to sign some file it says it can't do pinentry and then fails to open the secret key. <lle-bout>I'm unsure how pinentry GNOME<->gpg integration works here <lle-bout>Since GNU Guix has special /gnu/store paths for pinentry programs, I'm thinking it's not appropriate to hardcode that in gpg-agent.conf <lle-bout>/gnu/store paths change with updates, I don't want to be updating that path every time. <lfam>lle-bout: If it says that it can't find your pinentry, then you need to 1) make sure you have a pinentry installed and 2) set the pinentry-program option in ~/.gnupg/gpg-agent.conf <lfam>After you have a pinentry installed, you'll have a stable path at /home/you/.guix-profile/bin/pinentry-whatever <lle-bout>What happens on other systems where I never needed to configure such a thing? <lfam>I assume GPG looks in some path like /usr/bin/pinentry by default <lfam>I used to know the answer but forgot years ago <lfam>Probably there is some email where I explained it all from like 2016 <lle-bout>I see. How could one do to properly solve that issue so that there's a default pinentry for gpg in GNU Guix? Possibly a GNOME one if that's used? <lle-bout>lfam: patching gpg so it looks for $HOME/.guix-profile/bin/pinentry-something by default? <lfam>I'm not totally sure but I expect that it happens in C code where $HOME would not be expanded <lfam>Unfortunately GPG is put together in a really complicated way <lle-bout>I'm not sure what the security implications would be <lfam>Yeah, we probably wouldn't accept the patch. Using GnuPG is already pretty advanced so it's not so crazy to ask users to set this up <lfam>It would be great to fix it upstream though <lle-bout>I'm trying to use the 'pass' program with emacs.. otherwise I try to use GPG for email some times and git, most of the time. <lfam>Looks like the GnuPG build system is already taking store paths for pinentry and baking them into the man pages <lfam>I wonder how that is happening <lfam>Ultimately the gpg-agent needs to be looking in $PATH <lfam>Oh, the man page thing is erroneously appending the GnuPG store path with 'bin/pinentry' <lfam>No, it's just a man page <lle-bout>Also, I get that in /var/log/gdm/greeter.log: GNOME Shell-Message: 00:42:23.386: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: gnome-shell not allowed to act as agent <lle-bout>I'll be back, logging out and back in again for restarting gpg-agent. <lle-bout>pinentry-program configuration worked. Thanks! <aidenholmes>also, i assume the version of nix in guix only uses the free software channels by default <brendyyn>I forget. maybe you run it as root to make it? <lfam>I'm not sure how it's supposed to work but I would not use that Nix <lle-bout>aidenholmes: guix-daemon which is a fork of nix-daemon which runs as root and has ownership of the /gnu/store <lfam>I don't think anyone is paying attention to it <lfam>It was last touched a couple years ago. <lfam>lle-bout: I think that aidenholmes is talking about the Nix package, not the daemon <lle-bout>I suppose that Nix package could depend on a package named 'nix-daemon' which would have to be installed as a service. <lle-bout>/nix/store and /gnu/store could co-exist in theory <aidenholmes>using the nix-install.sh script meant for foreign distros works fine <aidenholmes>but i heard now nix (the package manager) is a package in guix <nckx>jonsger: Right? When I saw that commit scroll by I was puzzled (nginx requires an empty events section, at least) but assumed must've worked. I'm going to revert that commit. <roptat>well, there is a nix service type <roptat>whose description is "Run the Nix daemon" <roptat>(you can find it with "guix sysetm search nix") ***catonano_ is now known as catonano
<roptat>so close! I again need to change my version of the ant-build-system, so rebuilding the java world again before I can test the build of my package <nckx>aidenholmes: That's handled by nix-service-type which also runs the daemon but I agree, if you want Nix on Guix install it the Nix way. I can't imagine the Nix package & service in Guix being well-tested or -loved. <drakonis>and the nix importer doesnt seem to function well for complex packages <drakonis>anything more complex than trivial packages *raghavgururajan peeps in o/ <apteryx>yay, network-manager-openvpn works a treat :-) *apteryx now to investigate wireguard <Veera>doing guix system reconfigure downloads files <Veera>if it fails it starts fresh for interrupted file <Veera>how to resume from partial file download <nckx>Veera: That's not an option. roptat has submitted a patch to resume downloads but it's not ready to merge yet. <roptat>yay, I have the same issue with my unreliable internet connection <roptat>but ci doesn't support resuming download for instance, so my patch is not very useful <Veera>does guix uses gnutls or openssl <nckx>Veera: A work-around if you don't have tens or hundreds of files failing: ‘curl -LO <the URL>’, or ‘wget <the URL>’; then ‘guix download <the local file>’ and rm <the local file>. Both curl and wget can resume downloads although I'm not sure if they do so by default. <Veera>nckx: but how to know the url for files <nckx>Veera: I think it uses libgrypt. <nckx>Veera: They are printed by ‘guix build’ at least. Presumably also when the download fails. <nckx>Veera: Doesn't ‘guix system reconfigure’ print the URLs of files it downloads? Here it does. <nckx>roptat: Orly? So that's guix publish's fault, right? An nginx cache would fix that. <nckx>Actually, it's already cached by nginx so something's not right. <roptat>if you curl -i a substitute, you don't get the expected headers if it was supported <nckx>‘Once NGINX has cached an entire resource, it services byte‑range requests directly from the cached copy on disk.’ <nckx>roptat: What do you mean exactly? Accept-Ranges? <roptat>(I need to implement that check so we don't accidentally request a range when the server doesn't support that) ***net-safe__ is now known as Veera
<nckx>(I know, the ‘right thing’ would be to emit Accept-Ranges & handle partial requests in guix publish itself, but that shouldn't block you client-side fix.) <nckx>Veera: What do you mean? <Veera>I mean for guix system reconfigure downloads <Veera>How to download those files using curl/wget <nckx>Veera: You're not giving enough information. Which downloads exactly? <nckx>If it's a source, see above. If it's a nar, I guess you could curl/wget it and manually ‘install’ it with guix archive (?) and start the configure again. <Veera>I ran: guix system reconfigure /etc/config.scm; download fails in linux-libre-5.4.25 <samplet>Veera: When building, I see “downloading from [URL]”. Can you download that URL? <apteryx>my icecat is off by one hour in Mattermost, even after disabling privacy.resistFingerprinting to false in about:config. Any clues? <Blackbeard>It is Sunday and I've been trying to relax because my anxiety has been trough the roof recently <guix-vits>Blackbeard: sorry, i'd forget again what is the day of today :) <Blackbeard>guix-vits: oh no need to be , I know you asked in the best way :) *guix-vits leaving the hosue now (+07 UTC), small things <Kimapr>and i get warning every time i want to install something <Kimapr>guile: warning: failed to install locale <samplet>That’s a bit weirder. Usually it’s taken care of. <Kimapr>well i installed it through guix instance on a foreign distro <Kimapr>and i ran guix system init two times fully <Kimapr>because first one made boot efi partition empty <Kimapr>(didn't fill it with boot files) <Kimapr>should i install it system-wide or something? (guix system reconfigure) <samplet>I’m not sure. I was hoping I could get the warning on my system, but I can’t seem to make it happen. <samplet>Kimapr: Does /run/current-system/locale exist? <samplet>(It turns out that glibc knows about that path without the environment variable, which is why I couldn’t confuse it.) <Blackbeard>Kimapr: have you done a guix pull and guix system reconfigure yet? <Kimapr>it's a symlink to /gnu/store/1lcniyxkxkh8g73zvh2gpbccvl6ggna7-locale-2.28 <samplet>Kimapr: Ah. Maybe there’s an issue with the version. We are on glibc 2.29 now, and there may be some wires crossed. <samplet>I bet the warnings will go away if you update and reconfigure. <Kimapr>geany crashes when i try to save file <Kimapr>(geany:1373): GLib-GIO-ERROR **: 12:27:45.805: Settings schema 'org.gtk.Settings.FileChooser' does not contain a key named 'show-type-column' <Kimapr>seems like it tries to open file chooser but fails <Kimapr>is it okay to install 65 games in one guix transaction? <Kimapr>is it okay to install 65 games in one guix transaction? <dftxbs3e>Kimapr, of course, why would it not be? :) <Kimapr>can guix be overloaded by installing huge amounts of packages? <dftxbs3e>Problematic package definitions can cause excessive RAM usage but you must intentionally create those problematic definitions <Kimapr>i wonder how much time would take trying out all these games <Kimapr>okay, i reconfigured the system and now guix pull doesn't warn about locales <dftxbs3e>Kimapr, by the way, there's: guix install <Kimapr>is it different from guix package -i? <dftxbs3e>janneke, hello! is GNU Hurd usable as a daily driver operating system? <janneke>dftxbs3e: i would say: "it depends" or "sooner if you help" <dftxbs3e>I run ppc64le, so I'm deep in the rabbit hole already <janneke>good, we'll assign the ppc64le port to you, then <dftxbs3e>janneke, I wish I was more skilled/productive in that area :-S <dftxbs3e>I'm feeling so drown by the challenges at work that it freezes me making it impossible to work on anything else even during free time :-S <janneke>it's important to take care of yourself, i believe <dftxbs3e>janneke, it makes me feel so horrible to prioritize my own work on GNU Guix when the people at work need me <rekado>jonsger: oh, I’m sorry. I should probably add an “events” field to the nginx configuration with a default value. <rekado>I removed the hardcoded empty value because events can be specified with the new global-directives field. <rekado>(and having a hardcoded empty value would override it) <rekado>I’m going to fix this in a moment <rekado>as a workaround you can use (global-directives '((events . ()))), I think <civodul>rekado: the bug with (include ...) and relative file names is fixed in Guile 3.0.1 <Kimapr>============================= test session starts ============================== <Kimapr>platform linux -- Python 3.7.4, pytest-4.4.2, py-1.8.0, pluggy-0.11.0 <Kimapr>hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/tmp/guix-build-unknown-horizons-2019.1.drv-0/unknown-horizons-2019.1/.hypothesis/examples') <Kimapr>rootdir: /tmp/guix-build-unknown-horizons-2019.1.drv-0/unknown-horizons-2019.1 <Kimapr>plugins: hypothesis-4.18.3, mock-1.10.1 <Kimapr>INTERNALERROR> Traceback (most recent call last): <Kimapr>INTERNALERROR> File "/gnu/store/wrllykvq4l9ia5wldivmdlwgf2c8m2mb-python-pytest-4.4.2/lib/python3.7/site-packages/_pytest/main.py", line 209, in wrap_session <Kimapr>INTERNALERROR> session.exitstatus = doit(config, session) or 0 <Kimapr>INTERNALERROR> File "/gnu/store/wrllykvq4l9ia5wldivmdlwgf2c8m2mb-python-pytest-4.4.2/lib/python3.7/site-packages/_pytest/main.py", line 248, in _main <Kimapr>INTERNALERROR> config.hook.pytest_collection(session=session) <Kimapr>INTERNALERROR> File "/gnu/store/w80vzg9kysnk379pn71b7pgn6l2jr6dx-python-pluggy-0.11.0/lib/python3.7/site-packages/pluggy/hooks.py", line 289, in __call__ <Kimapr>INTERNALERROR> return self._hookexec(self, self.get_hookimpls(), kwargs) <Kimapr>INTERNALERROR> File "/gnu/store/w80vzg9kysnk379pn71b7pgn6l2jr6dx-python-pluggy-0.11.0/lib/python3.7/site-packages/pluggy/manager.py", line 68, in _hookexec <Kimapr>INTERNALERROR> return self._inner_hookexec(hook, methods, kwargs) <Kimapr>INTERNALERROR> File "/gnu/store/w80vzg9kysnk379pn71b7pgn6l2jr6dx-python-pluggy-0.11.0/lib/python3.7/site-packages/pluggy/manager.py", line 62, in <lambda> <Kimapr>INTERNALERROR> firstresult=hook.spec.opts.get("firstresult") if hook.spec else False, <Kimapr>INTERNALERROR> File "/gnu/store/w80vzg9kysnk379pn71b7pgn6l2jr6dx-python-pluggy-0.11.0/lib/python3.7/site-packages/pluggy/callers.py", line 208, in _multicall <Kimapr>INTERNALERROR> return outcome.get_result() <Kimapr>INTERNALERROR> File "/gnu/store/w80vzg9kysnk379pn71b7pgn6l2jr6dx-python-pluggy-0.11.0/lib/python3.7/site-packages/pluggy/callers.py", line 80, in get_result <Kimapr>INTERNALERROR> raise ex[1].with_traceback(ex[2]) <Kimapr>INTERNALERROR> File "/gnu/store/w80vzg9kysnk379pn71b7pgn6l2jr6dx-python-pluggy-0.11.0/lib/python3.7/site-packages/pluggy/callers.py", line 187, in _multicall <Kimapr>INTERNALERROR> res = hook_impl.function(*args) <Kimapr>INTERNALERROR> File "/gnu/store/wrllykvq4l9ia5wldivmdlwgf2c8m2mb-python-pytest-4.4.2/lib/python3.7/site-packages/_pytest/main.py", line 258, in pytest_collection <Kimapr>INTERNALERROR> return session.perform_collect() <Kimapr>INTERNALERROR> File "/gnu/store/wrllykvq4l9ia5wldivmdlwgf2c8m2mb-python-pytest-4.4.2/lib/python3.7/site-packages/_pytest/main.py", line 495, in perform_collect <Kimapr>INTERNALERROR> self.config.pluginmanager.check_pending() <Kimapr>INTERNALERROR> File "/gnu/store/w80vzg9kysnk379pn71b7pgn6l2jr6dx-python-pluggy-0.11.0/lib/python3.7/site-packages/pluggy/manager.py", line 251, in check_pending <Kimapr>INTERNALERROR> % (name, hookimpl.plugin), <Kimapr>INTERNALERROR> pluggy.manager.PluginValidationError: unknown hook 'pytest_namespace' in plugin <module 'tests.conftest' from '/tmp/guix-build-unknown-horizons-2019.1.drv-0/unknown-horizons-2019.1/tests/conftest.py'> <Kimapr>========================== 3 warnings in 8.36 seconds ========================== <Kimapr>command "pytest" "tests" failed with status 3 <Kimapr>builder for `/gnu/store/ibr2n76pk6iynl2pzzx7kinhwdyr910j-unknown-horizons-2019.1.drv' failed with exit code 1 <Kimapr>build of /gnu/store/ibr2n76pk6iynl2pzzx7kinhwdyr910j-unknown-horizons-2019.1.drv failed <Kimapr>should've paste it into a pastebin or something <Kimapr>i don't understand how to fix this <Kimapr>shouldn't unkown-horizons use older version then? <Kimapr>why is package definition is incompatible with itself? <abralek>in your test session you are using pytest 4.4.2 <civodul>Kimapr: could you use a paste bin next time? :-) <Kimapr>it's guix package -i <lots of other packages> unknown-horizons <lots of other packages> <Kimapr>there is an mistake in package definition <Kimapr>it has pytest 4.4.2 as dependency <Kimapr>dependencies: fifengine@0.4.2 intltool@0.51.0 python-greenlet@0.4.15 <Kimapr>+ python-pillow@6.2.1 python-polib@1.0.8 python-pytest-mock@1.10.1 <Kimapr>+ python-pytest@4.4.2 python-pyyaml@5.3 python@3.7.4 <abralek>yep, but I can not find pytest 3 definition <Kimapr>bad, then what this package is doing here if it's dependencies aren't present in guix <rekado>Kimapr: it’s not uncommon for upgrades to break package definitions. <rekado>this can be fixed by changing the package definition to use pytest 3. <abralek>I think you just need to add pytest3 <abralek>by the way, in this case what would be a right procedure? define an older one and inherit from it? <abralek>or define a separate one? or inherit from the current one and change the source? <rekado>I would inherit from the current one. <rekado>Using pytest3 is the exception, so it should be treated as the special case <abralek>cause it won't trigger a chain of rebuilds I guess <abralek>Do I have to *mark* those packages somehow? For example I need davmail, and it uses a bunch of stuff which have a transient EOL deps like slf4j log4j for example <abralek>I was trying to use the latest packages, but had to downgrade, hence multiple versions of them <partyclicker>is the documentation for guixsd sufficient for a common laptop install with luks + the need for proprietary wifi drivers? or will i need to find some kind of unofficial docs? <Kimapr>you can't find proprietary wifi drivers info in the docs <kmicu>partyclicker: no part of GNU Guix directs users into or helps with proprietary parts. <abralek>but I haven't completely migrated to GuixSD thought <Kimapr>wifi worked on my old laptop, but on this laptop it doesn't <Kimapr>so i connected it directly to router through ethernet <kmicu>Linking to such resources on official GNU Guix channels is also ‘naughty’ to put it gently. <Kimapr>you can also alternatively tether wifi from your android phone through usb <partyclicker>i've been using guix on debian for a couple years now. want to try out the SD, but it's quite daunting <kmicu>Guix System, as a fully libre system, doesn’t prevent us from using upstream Linux kernel et al. So I’m sure you can solve your issues if you look outside of official channels. <rekado>PSA: please don’t advertise non-free software on official Guix project channels. <rekado>another PSA: it’s called “Guix System” not “GuixSD” :) <civodul>it's interesting that the name sticks around even though it's not visible anywhere on the web site <rekado>partyclicker: there are many advantages of using Guix System over traditional distros. But only you can decide if that’s worth learning how to use it. <abralek>I read about GuixHPC. How do they run Guix? Using a foreign distros? <kmicu>(wingo’s package is libre, but it directs users into naughty stuff. (Tho’ wine’s main purpose is the same and GNU Guix packages it anyway 🤷)). <civodul>abralek: clusters typically run another distro yes, like CentOS <civodul>so people install Guix on top of that <abralek>I would love to use GuixSD in our environment, but with corporate vendors I can't do it. kernel need a lot of proprietary divers =( <kmicu>abralek: the closest reproducible, functional, and declarative thing not following GNU FSDG is Nix(OS). Maybe you could switch to Guix (System) gradually. <rekado>abralek: FWIW we are using Guix System with Linux libre on a bunch of off-the-shelf Dell servers. <kmicu>abralek: or use Guix, the package manager, on your favorite, corporate approved, distro. <abralek>rekado: bare metal? nice! Could you share the specs? =) <civodul>servers typically work out of the box with 100% free software <abralek>Do they replace a broken hardware if you run non-supported kernel? <abralek>or firmware for network cards for example =) <civodul>you can run what you want when you buy them, can't you? :-) <abralek>Yes, I can, but in case of a hardware issue, you need to replace it. Some vendors won't do that, if you run non-official distros/firmware/kernels <civodul>i don't see how they could define "official", though <civodul>dunno, i'd think there's no problem with warranty <abralek>It defines in their software/hardware compatibility matrix <abralek>The workaround is just to boot with their approved stuff and report it back. <rekado>abralek: there’s no impact on warranty <rekado>abralek: Dell may want us to install their only supported version of RHEL if they don’t believe that it’s a hardware problem, but so far that hasn’t happened. <rekado>(it *did* happen in the past with our CentOS servers, though) <rekado>abralek: firmware updates happen via iDRAC (i.e. the little management computer inside of the server) <rekado>so far any of the Dell servers we bought worked just fine, including the internal broadcom NICs <abralek>rekado: Honestly, we are planning to change Cisco and considering dell as an alternative. Thanks for telling this. <abralek>due to a very high hardware issues rate <abralek>rekado: Can I ask you one more thing? Do you use PXE or something like that? <rekado>abralek: we also have hardware defects with Dell, unfortunately, but the institute has a good contract so we get all that defective hardware with a ~50% discount. <rekado>abralek: not for the Guix System servers yet. <rekado>that’s because the Guix System initrd doesn’t support looking for the root fs on NFS. <rekado>but that’s an upcoming GSoC project IIRC <rekado>most of the pieces are already in place <abralek>Yes, I see that. Really good thing to do <rekado>yeah, it was a bit painful to install 30 servers without PXE :-/ <civodul>rekado: you have all my recognition! :-) <rekado>on the plus side: I got to test the installer 30+ times :) <abralek>We use MAAS. But you can not build custom images without Canonical agreement. =( <civodul>did you use the 1.0.1 image or a more recent one? <rekado>I wanted to use something more recent but there was a serious bug at the time I built the newer installer image <rekado>so I had to fall back to the known good 1.0.1 installer. <brendyyn>is anyone here using brightnessctl to adjust the backlight without needing sudo? how did you do it? <jonsger>thanks nckx your nginx patch fixed the problem! *rekado compares with own patch <bricewge>brendyyn: (simple-service 'backlight udev-service-type (list brightnessctl)) <bricewge>And add yourself to the groups video and input. <NieDzejkob>Would it be practical to run Guix off a 16GB thumbdrive? Asking for a friend... <sneek>Welcome back NieDzejkob, you have 1 message! <sneek>NieDzejkob, guix-vits says: thank you again for the changes to "After System Installation", about `sudo`. <rekado>hmm, meet.jit.si doesn’t work with Icecat <jonsger>rekado: non-free js or is WebRTC disabled in Icecat? <rekado>it just says that I need latest chrome <jonsger>it does even work on my Firefox on ppc64le without JIT-JS... <brendyyn>tho i dont think it every worked as well as firefox <NieDzejkob>Maybe privacy.resistFingerprinting is messing with it somehow? <nckx>jonsger: You're welcome. <rlemmon>I am trying to install guix on a nixos machine using the install shell from the guix website. All goes well until the script tries to install the guix-daemon service. It cannot install it in /etc/systemd/system and so the daemon cannot be started. Has anyone come across this problem ? I thought the /etc filesystem was writeable as that is where e.g. configuration.nix lives which I regularly modify. <DamienCassou>I have problems setting up Emacs for Guix package writing <tsmish>Hi #guix. I'm trying to package a program, which requires freetype. It includes <ft2build.h>, but this file doesn't exist on guix system. It exists as <freetype2/ft2build.h> but that file assumes that freetype headers are in <freetype/*>, not in <freetype2/freetype/*>. Still, there are packages depending on freetype which somehow work. So how do they do that? <DamienCassou>just to be sure, when calling the `package` function, should the next line have its opening parenthesis aligned under the "a" of `(package` or the "p"? <nckx>rlemmon: If I had to guess I'd say /etc is writable but /etc/systemd or /etc/systemd/system links into the store, which isn't. *nckx hopes you're using automation for that. <rekado>tsmish: add the sub-directory to C_INCLUDE_PATH in a build phase <rekado>tsmish: there are a bunch of packages that do this, so you can copy from them. <rlemmon>I think that will be right that /etc/systemd/system is not writeable. But then I am not sure how to setup the daemon for that script. <rekado>rlemmon: I suppose you can configure the contents of /etc/systemd with nixos? <nckx>rlemmon: I don't know if the installation script allows you to skip it, but if so do that and add the Guix service manually, the Nix way. <nckx>If the installer dies prematurely because /etc isn't writable, that's a bug. <nckx>rlemmon: You can use <guix>/etc/guix-*.service (or their .in files) as examples. <tsmish>Also, probably related problem. Some sdl-* packages want to include sdl as "SDL.h", which breaks things because they are in different directories. <nckx>DamienCassou: Even though civodul! Er, it's possible, I just noted what the ‘official’ emacs rules do. We don't enforce indentation at that level, so ‘wrong’ isn't the word. <nckx>Putting the ( in (package over the n in (name, that would be wrong. <nckx>rlemmon: /quit or /leave. <nckx>DamienCassou: ( under a is much more common and won't mess up people blindly C-M-q'ing your expression later, so they'll be grateful, but don't sweat it. <DamienCassou>I want my Emacs to be configured so I don't have to think about indentation. I usually use aggressive-indent for this exact reason <DamienCassou>I'm trying Emacs' guix package. `C-c . b` throws an error instead of building the package at point.Unknown meta command: geiser-eval <nckx>As long as your patches to existing packages aren't drowned out by unrelated indentation changes. <nckx>As long as your patches to existing packages aren't drowned out by unrelated indentation changes. <nckx>DamienCassou: Did you install geiser? <DamienCassou>I do have geiser and it's configured to run guix-guile instead of plain guile <civodul>anyway, no big deal, but sorry for overlooking it <DamienCassou>in my next patch on this, should I get it fixed or should current indentation be kept? <DamienCassou>I will deactivate aggressive indent in guix code because indentation seems broken everywhere <civodul>either way is fine, but it's probably best to have indentation fixup in its own patch <civodul>perhaps you need emacs-guix to get indentation correct, but this is surprising <civodul>i think most special rules are in .dir-locals.el <rekado>janneke: would you like us to build the wip-hurd branch on ci.guix.gnu.org? <DamienCassou>civodul: I now think that my configuration is correct. The problem is that many package definitions are broken according to it. I usually have aggressive indent that re-indents everything I touch. This is problematic because it tends to change many lines everywhere because they have a "broken" indentation <civodul>DamienCassou: ah yes, you should disable that <civodul>obviously there are packages with slightly different indentation here and there <civodul>(also because the rules changed over time i guess :-)) <DamienCassou>I suggest doing a pass on every file in the project so we have a correct indentation everywhere <civodul>i think it's best to "fix" things incrementally <civodul>otherwise that just makes "git blame" harder to use <janneke>rekado: last i checked, the deleted `wip-bootstrap' was still listed <nckx>So that's a valid simplification. <roptat>nckx, but then if I try a range request after I downloaded some parts, I'll download too much, and my file will be incoherent <nckx>roptat: It seems you're right. Why can't we have nice things, nginx. ***sneek_ is now known as sneek
<civodul>mbakke: i'd happily push wip-guile3.0-packages on top of core-updates, WDYT? <civodul>i've tested it a bit and it works fine <NieDzejkob>termite pulls in xdg-utils, on core-updates qt does too... <guix-vits>NieDzejkob: just the BugReport i'd posted above is old, and neither wxwidgets, nor audacity push it yet. <guix-vits>So patch with xdg-utils appended to `(p.-inputs` can pass? <nckx>guix-vits: No. Don't propagate inputs, patch them. See ‘termite’ for an example. Both calls to xdg-open are in src/unix/utilsx11.cpp. We can probably get away with simply making ‘path’ a hard-coded string in both cases. <nckx>Oh, not even that. Patch ‘wxExecute(xdg_open’ to ‘wxExecute("/gnu/store/…’ <nckx>guix-vits: Do you want to give that a try? <mbakke>civodul: sounds great! I think we are ready to start it now. *guix-vits read about "inputs, p-inputs, and n-inputs" <nckx>guix-vits: propagated-inputs == avoid. <nckx>Each propagated-input of every package in a profile ends up in that profile too. It's a mess, and wxwidgets being a library worsens that effect. <rekado>janneke: I’ve removed wip-bootstrap and added wip-hurd. <nckx>guix-vits: My ‘let's see if this works’ patch just worked, so I can push it if you wouldn't have the time. It's a good simple learning opportunity though. <guix-vits>nckx: i've a time, but if the patch is already there, i'm prefer a link to it to study. As i'm uderstood the 'termite', one uses (lambda and (substitute* to use `(input`'s xdg-open, which is not installed, but available for the package (as which executed in build env.). <anadon>civodul: Can you see the attached file from 40043's first email? <anadon>Happens to me a lot. No worries. <nckx>guix-vits: OK, I'll post it. Compiling it now to make sure. Your understanding of what termite does is correct: ‘guix environment --pure --ad-hoc termite’ won't be polluted with xdg-friends. <allana>Hi, I have seen some references in the guix cookbook to "macbook". Is anyone running guixsd on mac hardware? I recognize that this is hardware requiring nonfree software/firmware and this against what many of us stand for, but I thought it would be safe ot ask about since it is in the cookbook. *nckx adds optimistic ‘Fixes:’ line. <nckx>Building audacity downloads both postgresql and mariadb. That's nice. <nckx>I just watch the world & my CPU burn. <nckx>guix-vits: I just noticed the age of that bug report. Thanks for hunting. <civodul>mbakke: core-updates is now on Guile 3.0! <anadon>Guile 3? I need to go read the changelog. <anadon>Oh geez. Guile 3 has big performance wins. <nckx>This some kind of nascent monitor bot? <mbakke>removing defunct python 2 packages feels great <mbakke>almost as satisfying as solving the Python dependency cabals :P <floreal>I'm trying to update package definition for retroarch to update it to version 1.8.4 (in order also to understand how packaging works) <floreal>How can i calculate the base32 sha256sum ? <floreal>Thakns and when the source comes from a git repo ? <mbakke>floreal: guix hash -rx <the-git-repo> :) <mbakke>-r for recursive, -x to skip .git and similar <mbakke>np, thank you for helping with packaging, much needed :) <floreal>Once i achieve that i'll try to add different .so backend packages <mbakke>floreal: cool, let us know if you get stuck anywhere ***regtur is now known as regtur_
***regtur_ is now known as regtur
<civodul>nckx: looks like it! i suspect rekado is working on cwazy stuff <civodul>floreal: looks like "./pre-inst-env guix refresh -u retroarch" should do that for you <nckx>floreal: I think you'll have to do some patch munging though. Make sure the non-FSDG updater doesn't reappear. <nckx>s/updater/e-shoppe whatsitcalled/ <floreal>nckx: yeah I have read the option is undesired in the distro because of the lack of licence information of the downloaded cores <floreal>That's why I want to introduce libretro-* cores <floreal>I just don't know how they can be installed to a specific directory yet or make retroarch every /gnu/store/*/lib/libretro is in the same place <nckx>floreal: Ideally, retroarch will respect a $PATH like variable and you can use native-search-paths. While I did nuke the downloader, I don't actually use RA myself. <mbakke>floreal: if you are lucky, RetroArch supports looking up cores from a directory specified by an environment variable, e.g. RETROARCH_CORES_DIRECTORY <mbakke>...as nckx says, then adding a native-search-path for "lib/libretro" is everything needed, if the cores install to $out/lib/libretro <mbakke>nckx: I got your message after sending mine <nckx>Here it's the other way round but I'm tunnelin'. <floreal>nckx, mbakke It might need a patch to introduce an Environment variable, and path searches <nckx>With some luck, upstream will accept a patch to do so and we won't have to carry it forever. <floreal>(I contributed to Lakka / retroarch a few years ago, i don't know if they have such mechanism implemented) <floreal>Also maybe we may provide a patch to disable core updates at ./configure time rather than patching it in the .scm package. <mbakke>floreal: sounds good, substitutions are somewhat fragile because they can silently become ineffective <NieDzejkob>right, I should finally write that proposal for substitute*/fail-hard and send it to -devel <mbakke>I wonder why guix pull --news prints all the news in no time, and then stops to contemplate for a second before returning. <nckx>NieDzejkob: Please do. substitute* should fail hard by default. <mbakke>I concur, though "shotgun" substitutions have their place. <nckx>NieDzejkob: This was also on my to-do list. Do you have a patch proposal? <nckx>mbakke: Abso, but they should be marked as such. <floreal>Ah the fuul online updater have been removed. <NieDzejkob>nckx: Hmm, this would be a core-updates thing, wouldn't it? <NieDzejkob>(My endless todo blackhole also has such entry, but I haven't done any work in that direction yet) <andydarcyjewell>Guix newb here, is it *really* necessary to use Emacs/Gieser for packaging? I'm a long-term emacophobe (like 20 years). <nckx>andydarcyjewell: Not at all. <nckx>I use emacs as a (mostly) regular text editor, not an IDE, and package things with glee. <andydarcyjewell>I was hoping not, but the "The Perfect Setup" tutorial suggests it is. Will it limit what I can do? I need to learn how to create packages for my boss. <nckx>ln -s /dev/null ~/TODO; it's horrible. ***roptat_ is now known as roptat
<mbakke>are there good scheme indentation modes for vim? if so we should add it to the manual <mbakke>NieDzejkob: only when the current branch is 'frozen' <nckx>andydarcyjewell: It won't limit you at all. I'd recommend using the etc/indent-code.el script, which uses emacs, but you can pretend it doesn't. ‘The perfect setup’ is extremely subjective. <roptat>the default is good, as long as you use spaces for indentation <andydarcyjewell>ropat: I'm a seasoned Pythonista... so spaces are a natural for me ;-) <roptat>"set expandtab" is all you need to have good indentation in most cases <KE0VVT>Do current versions of Emacs handle Hebrew vowel points correctly? *mbakke is throwing a Python update party to celebrate Python 3.8 on 'core-updates', and everyone is invited. <roptat>a nice vim move is di" which removes the content inside quotes (which is useful if you want to update a package, as you can remove the version number and sha256 in one command) <KE0VVT>andydarcyjewell: Where is the "The Perfect Setup" tutorial? <KE0VVT>roptat: I admit, there are some things I have not been able to do since switching from Vim to Emacs. <KE0VVT>And lately, I have been using Gedit because Emacs is weird with fonts. <civodul>mbakke: we've really been partying like crazy on that branch :-) <andydarcyjewell>KE0VVT: I'm just recursing the doc tree to learn how to create Guix packages <nckx>KE0VVT: What weirdness did you encounter? I'm still unsure how much of the weirdness I see here is ‘to be expected’ and what could be fixed. <andydarcyjewell>Another thing that's bothering me is the old "warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)" error... tried loads of fixes, but it won't go away. <andydarcyjewell>My locale is en_GB, and I'm running on Debian Buster, if that matters... <mbakke>civodul: yes, I'm moving the party to the master branch so that it can get some rest :-) <nckx>KE0VVT: Beautiful, like it's 1994 again. <NieDzejkob>andydarcyjewell: did you install glibc-locales ? <NieDzejkob>I've found that with an en_IE locale, glibc-utf8-locales doesn't suffice <NieDzejkob>(and no, I'm not Irish, it's just the only english locale with sane settings) <andydarcyjewell>NieDzejkob: lol "sane settings"... how does it differ from en_GB, apart from a Euro symbol? <andydarcyjewell>NieDzejkob: but you're saying I just have to live with the errors then? <mbakke>andydarcyjewell: that message is probably from guix-daemon, did you install glibc-utf8-locales for the 'root' user? <andydarcyjewell>mbakke: er, no, I haven't. Sorry, don't yet know that much about Guix (told you I was a newb). <mbakke>andydarcyjewell: alternatively, you can adjust /etc/systemd/system/guix-daemon.service so that it looks up locales in your user profile <andydarcyjewell>mbakke: Ah, thanks, I was going to say: so, would that be *sudo guix install glibc-utf8-locales* <mbakke>andydarcyjewell: I don't actually know whether that command would DTRT. i'd do 'sudo -i' then 'guix pull && guix install glibc-utf8-locales' to be sure. <mbakke>it's probably easiest to adjust guix-daemon.service to use your user profile and not worry anymore about the root user. <andydarcyjewell>Thanks for the advice everyone, got to go now, but will try that out later ;-) <rekado>nckx, civodul I’m working on IRC notifications from monitor.guix.gnu.org <rekado>it would work if it wasn’t for the MDC firewall… *nckx shakes fist at firewall; thanks rekado. <rekado>oddly enough, connecting to IRC is fine from build nodes, but not from the head node. <rekado>I could set up a tunnel, but that would be very silly. Just asked IT to open the port. <NieDzejkob>sneek: later tell andydarcyjewell: I was under the impression that en_GB defaults to 12-hour time when applications support it <civodul>NieDzejkob: you could always set LC_TIME separately <nckx>NieDzejkob: I was of the opposite impression but I'm not sure what you mean by ‘when applications support it’. <nckx>It's always been 24-hour AFAICT. <NieDzejkob>civodul: or I could use the en_IE that works for me right now... <vagrantc>well, i managed to boot a 5.5.9 linux-libre + one patch from linux-next to enable pinebook-pro ... but when i went to add a second patch, it now fails to build ... and when i revert, the old version doesn't work anymore either <vagrantc>what would cause a match failure when the exact files it can't find are actually there? <nckx>vagrantc: match" "no matching pattern" <nckx>That's not a patching error. <vagrantc>oh, do i need them in gnu/local.mk ... thought that was only needed for make dist <nckx>vagrantc: I think you introduced a Guile syntax error when adding the 2nd patch and it's still there after removing it. <nckx>gnu/local.mk don't enter into it, you're right about its purpose <vagrantc>maybe i git rebased in there somewhere... <janneke>that sometimes helps to get a better stacktrace <sirgazil>Regarding people still referring to the GNU system as GuixSD, I think there are three reasons: <sirgazil>1. The change was not announced (if I recall correctly). <sirgazil>2. The website still has GuixSD references. <sirgazil>3. The logo had impact, and it started as GuixSD, not Guix. It was later that it was decided to use the same isotype for both the Guix System and Guix. <civodul>#1 & #3 are correct, #2 is not i guess? <vagrantc>janneke: i'm running an older pre-inst-env ... might want to refresh it <nckx>Had I known that they'd have been cleaned up long ago. <nckx>Screenshots are known, I think, but nobody bothered creating new ones. <vagrantc>janneke: fwiw, i'm actually booted from a linux-libre 5.5.9 kernel with a single patch from linux-next :) <nckx>sirgazil: You mean the translations? <vagrantc>janneke: but i think it needs one more to have LCD output <vagrantc>but i can't figure out what state i built the working kernel from, because i can't build it again :/ <nckx>sirgazil: I'll fix them. <lfam>We need new screenshots for the XFCE and GNOME desktops <nckx>sirgazil: How about creating a new screenshot? I assume you have composition props, and run GNOME. <vagrantc>janneke: it's also missing a lot of features ... e.g. no battery status, etc. ... seems to draw a lot more power, too ... hopefully nothing worrysome <nckx>My joke XFCE screenshot (where I gimped everything to say ‘System’) is still the best we have. Sad. <lfam>mbakke: I think the original page is never coming back, because the author has died <nckx>lfam: It does now, but I'd borked it gud. <lfam>Yeah, I assume it broke a lot of stuff <lfam>I'm going to get rid of the "original" URL <lfam>I didn't understand that it was a full archive.org URL. Sorry for the noise mbakke <nckx>civodul: Are you OK with replacing GuixSD with ‘Guix System (formerly GuixSD)’? I think we can treat blog posts as living documents within reason, and they really affect search results &c. <janneke>vagrantc: what about: /sys/class/power_supply/rk-bat/current_now <efraim>I'm trying to edit Makefile.am to build the tests only after all the other modules and having a hard time :/ <mbakke>why does it feel like the second step of the old "embrace, extend, extinguish" strategy >.< <nckx>mbakke: Big brother ♥ you. <nckx>sirgazil: I've updated the contact page. Check whether the grammar's still correct for all languages you know, but everything looks plausible. <anadon>This is why Gnu stands as the final Bulwark against Microsoft. <nckx>But yes, this is why a strong GNU is so important. <nckx>Goodbye Npm Uwereneverthatgoodbutwe'llmissyouanyway. <lfam>If GNU wants to make a difference it needs to be better. There are lots of reasons people use nonfree platforms (macOS and WSL) to run GNU tools <lfam>I'm not saying the problem doesn't seem insurmountable but there are things we can improve <lfam>The degree to which macOS and iOS "just work" for people is a huge factor <anadon>lfam: As inherent with the Gnu structure, funding is scant. <civodul>i'm always surprised when reminded that software X is actually backed by X, Inc. <lfam>Yes, funding is always a major problem for people like us *civodul wonders how long before Guix, Inc. is acquired by MS <lfam>But it doesn't help when big corporations create free software tools and GNU activists look down on those tools just because of where they came from. Even though the people actually making the tools are die-hard FOSS activists <anadon>Those people's bosses aren't die hard FLOSS activists. And they're the ones who own the code. <lfam>I see people talking about how Rust and Go are not really free software because they are backed by big corporations. I mean... come on <lfam>The code is freely licensed so it doesn't really matter who "owns" it <civodul>though, i do think that corporate free software has a very different feel than volunteer free software <lfam>It's a totally different world <lfam>But then again, C came from a big corporation <anadon>I'm thinking they could always pull an Oracle. <civodul>lfam: i agree, or even things like IPFS today are "corporate" <civodul>that doesn't make it any less interesting <efraim>limit on changes to master is 300 rebuilds? shadow has 344 <civodul>actually it even makes it more interesting to me, intriguing <lfam>Corporations are how individuals effect change in the western world <lfam>It's how you gain and use power <nckx>efraim: Yes. Unless a lot of those are fast-building packages like perl-*. <civodul>lfam: well, that's one way, you can't ignore grass-roots organizations that have had tremendous effect as well <civodul>the free software movement being one such thing <lfam>I think these grass-roots organizations must incorporate, at least in the US <anadon>They aren't large for profit types, but they're there. <lfam>I think there is an unfounded and counterproductive anti-corporate paranoia <lfam>Yes, that's what I mean anadon <lfam>The word "corporate" is scary but we can't let it short-circuit our critical thinking <civodul>lfam: oh i was using "corporation" as synonymous for "big company", but perhaps you meant "anything that's technically 'incorporated'"? <lfam>I am conflating the terms. Big companies can be bad, and they can be good, at the same time <lfam>Google can do bad things, and they can do good things <lfam>And we can take the good things without suffering the bad <nckx>There's a difference between ‘legal entity’ and ‘corporation’. I agree you need to be the former, but that doesn't require being the latter. Not sure how that scales internationally though. <lfam>I've been thinking about it since yesterday's talk in the #libreplanet channel. Some people still refuse to believe that Chromium is actually freely-licensed <lfam>At least in the way we package it <jackhill>I think the important thing is to have a diversity of interests in a project. Some large entities, some small ones, some individual hobbiests. It is a problem when too few entities control a project and their motiviations are not in aligned with mine <lfam>That's an interesting point jackhill <lfam>It does make the project really vibrant <jackhill>bkuhn's talk about IoT at LibrePlanet touched on some of this: e.g. the biggest funders of Linux are interested in cloud workloads which can but doesn't nessisarily help hackers who want to use Linux on their oven. It is up to us to speak for the Linux-based oven firmware users. <lfam>I didn't see that one jackhill. Sounds right up my alley! <jackhill>lfam: videos will be up soon I'm sure :) <lfam>I'm my opinion, it's true that "desktop" linux is not becoming a more mainstream use case, and is even beginning to atrophy <lfam>I don't see any activity towards free wifi drivers after 802.11n <jackhill>right. Is wifi hindered at all by regulatory concerns (e.g. limiting things the public can do with transmitters)? <lfam>Not to mention that desktop computing is becoming a niche use case of its own <lfam>Yes, wifi is highly regulated, but that shouldn't prevent free drivers, since we already have them <lfam>It's not controlled like cellular modems <lfam>Your dmesg should include some messages about wifi regulatory frameworks <Blackbeard>lfam: to be fair. All desktops lost the battle to mobile <lfam>Different areas allow different channels <lfam>I agree Blackbeard. But there is so little interest in mobile from the world of free software. So many free software activists do not even use mobile phones <lfam>It's a very hard problem <mbakke>janneke: what is the status of wip-hurd, do you think it's ready to merge? at least the full-rebuild changes? <lfam>And when people do make efforts, significant parts of the free software community try to tear them down for not doing enough <lfam>As if desktop computing was freed in a day <bdju>free software on mobile is getting much more interesting recently with the pinephone <sirgazil>lfam: I think I triggered the discussion on libreplanet when I commented about libreplanet using jitsi and https://meet.jit.si/ telling me I had to install Chrome to use it. <lfam>What browser were you using sirgazil? <sirgazil>I know jitsi is free software, but it is unfortunate when you visit the website of free software and the website editors don't care much about recommending any kind of software. <lfam>Yeah, doesn't work in epiphany, but it does work for me in chromium <mbakke>janneke: quick nit-pick on the patches, please follow the convention of a short comment, URL and then the diff <Blackbeard>lfam: yeah. It is disgusting. I have so many problems with my own teachers <Blackbeard>This is people who knows about privacy laws and the dangers of technology <Blackbeard>'Please use Microsoft Word® to do your homework' <janneke>mbakke: about the patches: ah, I see; yes, i'll update them <lfam>You can't use libreoffice Blackbeard? The file formats should be compatible <janneke>mbakke: i just found that wip-hurd fails to build on ci.guix.info -- i removed a glibc hurd patch that i was sure wasn't used; so that needs a fix/rewrite too <nckx>civodul: If you agree, I've replaced GuixSD with Guix System in all website/posts. I don't think there's any value for readers in keeping the old name alive or tediously saying ‘(formerly GuixSD)’ everywhere in these. The confusion hurts us and splits search results. <nckx>Won't push if you strongly disagree though. <janneke>mbakke: once it builds, it should be OK i think; i'll make the fixes and reset it tonight <vagrantc>janneke: /sys/class/power_supply is an empty directory <nckx>Blackbeard: I've had to remove MS Word *twice* from my partner's school laptop. It's just malware at this point. <nckx>(And no, she didn't install it knowingly.) <nckx>(And please don't blame her or me for still using Windows — baby wooing steps 🙂) <sirgazil>nckx: I think replacing GuixSD simply with Guix System in the whole website is ok (website pages are supposed to change). But in blog posts, I'd prefer adding the "(formerly GuixSD)". <nckx>That's a lot of manual work. <nckx>Or proof-reading at least. <sirgazil>Or leave them as they are. It's part of Guix history. <sirgazil>And that was the name at the time of those posts. <nckx>That's why they should mention the new name, so it's obvious they're outdated. <nckx>Seems like '0,/GS/s//GS (f GSD)/' should do what I want. <nckx>I'll use ‘GuixSD (now Guix System)’ in links to immutable things like talks. <nckx>lfam: Does systemd start root's user services (~root/.config/systemd) at boot? <lfam>nckx: It depends how you set up systemd and loginctl (users registered as "lingering" have their services started at boot). But I think it's better to bake it into configuration.nix as somebody else suggested <lfam>I don't know if root in particular lingers by default. Unprivileged users do not <nckx>I'd find it strange if root's were treated magically by default but this is systemd we're talking about. <janneke>i guess the previous git was a svn-brigde <janneke>still, i think it's terrible that git clone gnu:gcc does not work :-( <janneke>now, to go find my hurd commit upstream url :-) <bandali>yeah afaik gcc transitioned to git as their primary source control system a while ago <janneke>ow, crap if only i had known this -- 11 more patches to annotate *janneke annotated all patches; new bootstrap binary build started => prepare some dinner <civodul>nckx: re posts, i'd lean towards leaving them unchanged since they're from the past <roptat>I would change them because people are still discovering them and might learn the old name from them <civodul>or maybe add "(now Guix System)" everywhere? <roptat>or it could be even simpler: add a paragraph at the beginning "this article uses the term "Guix SD" which is the old name of the Guix System. We have preserved this name in the old blog post" or something <nckx>civodul: (now GS) is exactly my suggestion. <nckx>roptat: That's more work than I'm willing to put into this 😛 <civodul>nckx: ah sorry, i hadn't read the full discussion <nckx>roptat: A fine one. civodul: NP, it ballooned beyond any length it deserved. <civodul>total craziness, if anyone here remembers the thing <janneke>yeah, ow weird memories of a distributed vcs promise *janneke goes back to tinkering with wip-postfix <civodul>janneke: yes, it's tla, yes it's weird <civodul>lord@emf.net--gnu-arch-2004/tla--devo--1.3--patch-16 <janneke>haha, ow that was a mind-boggling cli <nixo_> Hi guix! Hi upgraded after "some time" and now emacs (26.3) segfaults a lot. Anybody else? <civodul>i have /gnu/store/z2idm4nxx0a5wzpf79pbsblh00m6yxhj-emacs-26.3 <nixo_>Hi :) ehm, mine is /gnu/store/80g8gcdnv5wndyjyl4ag4k9j7ziyv2s1-emacs-26.3/bin/emacs <nixo_>I'll guix pull again and see <janneke>oh, haha: find -prune -pe/gnu/store/zibwkb5xavnv6z3gzknfqjsxb9b0izh0-coreutils-8.31/bin/rm -020 <janneke>that's g_bor[m]'s experimental wip-postfix's postfix-install <civodul>nixo_: maybe try to grab a backtrace if it crashes again <nixo_>I already did, but without debug symbols it's diffcult. It happens in fontset_find_font <lfam>How would I test a change in (guix status)? Through `guix pull`? <civodul>lfam: for downloads, you can do "guix build -S coreutils --check" for instance <civodul>maybe we should just remove ellipses in these cases? <lfam>I do think the ellipsis helps communicate that something is not done yet <lfam>I think it's not that common in Unix to print "what will be done" although it's the right thing to do her <nckx>I think ‘-ing’ communicates that already (and better), but everyone's feeling is likely to differ. <nixo_>civodul: good news and bad news. The error appeared because during the upgrade I also removed two fonts. Bad news is that it seems that the crash is caused by the missing fonts <nixo_>This makes sense as the function that causing the fault is fontset_find_font <janneke>220 komputilo.localdomain ESMTP Postfix <nixo_>Should it be automated in some way? <civodul>dunno, i never had crashes due to that <civodul>but yeah, maybe this should be more clearly document <civodul>i think there's text somewhere that mentions fc-cache <nixo_>I think it's not the first time I experience this, I think reading irc log I'll find you telling me the same thing in the past <mehlon>well I personally find that deja vu is a common experience on the guix channel <mehlon>and it's always related to fonts <civodul>heh, well, that means we can at least improve documentation <xqmin>hello, does guix import opam fail on all packages to anyone else after guix pull? <roptat>what did you try to import, and what is the error? <xqmin>for example 'coq', the error is "failed to download meta-data for package 'coq'" <xqmin>I tested on the qemu image and on a fresh install, it works until guix pull <roptat>ah indeed, there seems to be an issue with it, I'll try to fix :) ***ChanServ sets mode: +o nckx
***nckx sets mode: -q $~a
***nckx changes topic to 'GNU Guix | get it at https://guix.gnu.org | videos: https://guix.gnu.org/blog/tags/talks/ | bugs & patches: https://issues.guix.gnu.org | paste: https://paste.debian.net | Guix in high-performance computing: https://hpc.guix.info | This channel's logged: http://logs.guix.gnu.org'
***ChanServ sets mode: -o nckx
