<quiliro>What is the advantage of running Xorg system-wide? <quiliro>mbakke posted how to run it as an unpriviledged user. Is there a problem with that? Why is it not on the Guix manual? <nckx>quiliro: A service would be overkill. (service special-files-service-type `(("/bin/startx" ,(xorg-start-command))). It won't run rootless, though. <nckx>It's also been a few months since I tested it. <quiliro>nckx: will the other link be better for rootless? <nckx>quiliro: I only see one link. Which other? <nckx>bit complex for my tastes. <nckx>quiliro: Have you tried xorg-wrapper? <nckx>Actually, disregard that, I think the xorg-start-command I posted above supersedes that. <quiliro>nckx: But I wish for rootless startx. <quiliro>nckx: What is its use if I want the user to start Xorg? ***jje_ is now known as jje
***jethro_ is now known as jyscao
<HHAFF>I wan't install grub with --no-nvram option ,how to edit config.scm <HHAFF>I want install grub with --no-nvram option ,how to edit config.scm <Nic__Wow__>Aye, where can I post issues during installation? <Nic__Wow__>I got a whole ton of error messages on my x230 ThinkPad ***kini is now known as fs
***fs is now known as kini
<htgoebel>After updating to ccbc1c5eb2 (2019-10-03 12:03), when entering a simple environment, <htgoebel>a lot of "bootstrap" and "boot0" packages get build, e.g binutils-bootstrap, binutils-cross-boot0. <civodul>mbakke: i think i'll commit the add-to-entropy-count patch anyway, because we were clearly doing it wrong <efraim>I think I'm going to skip the tests on vdirsyncer, the test suite has never been reliable on that package <efraim>I normally build it in a loop until i magically passes <efraim>how do I make the output wider so I can see the full guile backtrace? <ng0>hi. so hypothetically (as in: we still need to vote about this outselves) do you consider it possible to take on irc chat logging for 3 more channels (taler, libmicrohttpd, gnunet)? if so, we'd like to consider this :) <civodul>efraim: by setting the COLUMNS environment variable (i know, i know...) :-) <desmes>Has anyone had audio problems with Icecat (60.9)? The audio from some videos in some websites (e.g. Twitter) is really pitched down, it's a bit terrifying actually. On other websites (e.g. Youtube) the audio is fine. Also, I have installed all its dependencies. <civodul>ng0: dunno, this could be an option, sure! <civodul>desmes: yes i've experienced that, it's terrible <ng0>civodul: ok, good to hear :) should I ask formally via guix-devel? <desmes>civodul: Is there any solution though? <civodul>desmes: i usually resort to mpv when that happens, but it'd be great if you could email that to bug-guix <civodul>dunno it looks as if there was a sample rate issue or something <civodul>did you find anything on the intertubes, desmes? <civodul>ng0: yes, when you're sure you want that, please email guix-devel <efraim>civodul: so COLUMNS=160 ./pre-inst-env guix build foo <ng0>though this is still very informal, as we wil ldiscuss this in our next team chat/call, so I'm just asking in advance. <desmes>civodul: Nope, you are the first one that also has this problem. What do you mean with mpv? You play content from icecat with another video player? <ng0>okay, I'll do so after discussing it <civodul>efraim: though that env var doesn't go through the build env... <efraim>yeah, that's what I was afraid of <civodul>desmes: i jump to a terminal and run mpv with the URL of the video <civodul>efraim: but you can add that to the derivation, search for #:env-vars <roptat>if you experience the issue both in icecat and mpv, could it be an issue in ffmpeg then? <efraim>it's running on debian, so it should be easy to change the systemd environment variable <desmes>civodul: Lol I didn't know that was possible <efraim>civodul: I think I'll do that on my other machines anyway, certainly helpful <rekado>I only see that problem with embedded videos on Twitter. They usually work fine with mpv. <rekado>haven’t tried directly with gstreamer <nckx>desmes: He's not, I've had that problem for most of 2019 and others were able to reproduce (only later, though, which was strange). You're not alone! <civodul>efraim: well you really need to do it in each derivation, if it's a build-time thing <desmes>nckx: That low-pitched piano sound kind of cool though hahaha <nckx>(Oh, my last ‘at least now I have a lead’ comment: I did investigate this a bit, but I'm not really a media person nor do I find browsers interesting tech so I got bored…) <nckx>…and sportsball season's over now. :o) <desmes>I kind of hate browsers in general. I just wish the web was more barebones (just text+images+videos) so I could just use Emacs <nckx>desmes: Word. I use the mpv (it uses youtube-dl behind the scenes) trick to watch most videos, but some sites go out of their way to prevent that. <rekado>I wanted to push my NFS service definition soon, but then couldn’t actually mount NFS shares any more (this used to work when I previously almost finished the service). So I started writing a test. <rekado>unfortunately, an NFS 4 server also needs a KDC <rekado>so the test now also includes code to configure and start this whole Kerberos domain controller thing <desmes>nckx: I think I'll also use mpv, at least for Twitter <rekado>still fails, but I’m very close to having something that works as it should. <rekado>I think I should now also provide a kdc-service-type, though. <nckx>How much do we prefer libgcrypt over openssl (if at all)? Cryptsetup supports both but switched to openssl by default because it's faster at PKBDF. <nckx>*PBKDF. I always mistype that. <rekado>after rebasing my git repo I now get a weird error when compiling my test file: ice-9/eval.scm:293:34: Wrong type to apply: #<syntax-transformer krb5-realm?> <rekado>nckx: there may be licensing problems when using openssl :-/ <desmes>By the way, is it recommended to install, for a package, all its dependencies? For something like mpv or icecat it should be useful to install the codecs/fonts/etc. Is there a way to do that automatically, with 'guix package'? <nckx>desmes: No, there's no concept or recommended or optional run-time dependencies. <rekado>desmes: dependencies are installed, just not into the profile <rekado>all dependencies that are declared in the package will be installed; we just don’t necessarily add the kitchensink to the package’s inputs. <nckx>desmes: So dependencies are binary: guix package installs all dependencies ‘mentioned’ by the package, but you can't ask it ‘install more’ after that. <nckx>Hm, rekado and I are explaining this in different confusing ways, but I think we're trying to say the same thing. <desmes>Are all the dependencies listed by "guix package -s" really installed? <desmes>Because, e.g., I don't have 'rust' installed and it shows as a dependency: "guix package -s icecat" <roptat>desmes, there's indirectly installed <nckx>desmes: Guix doesn't work like that. Ignoring ‘propagated-inputs’ (which are a hack), ‘installing’ a package into your profile is completely separate from ‘installing’ it into the store as a dependency of another package. <roptat>i.e icecat knows where to find them, even though they're not accessible to you directly <nckx>For example, icecat depends on libjpeg-turbo, a package which also provides ‘/bin/djpeg’. If I'd try to run djpeg from the command line it wouldn't work because *I* didn't install libjpeg-turbo to my profile. But IceCat can still load all its libraries, because it refers directly to /gnu/store/…libjpeg-turbo…/. <desmes>I see. When doing 'package -i icecat' all the packages listed as dependencies in 'package -s icecat' are installed in the store, but not accessible by my profile <desmes>It makes sense. But I noticed a difference when I did "package -i freefont" (an icecat dependency), a lot of characters that did not render before, now do. *nckx knew this was coming 🙂 <nckx>desmes: I've got to go, I'm sure someone will explain, if not, remind me later. <desmes>nckx: Okok, don't worry. Thanks for the explanations! <demotri>What is the status of 'staging'? Is it OK to commit to it or is it freezed? <civodul>demotri: not sure, but the top priority is merging core-updates in master <demotri>civodul: If even you are unsure, who is sure then? <civodul>demotri: heheh, i shouldn't be a single point of failure :-) <civodul>so the lesson here is that we should handle branches more formally <civodul>perhaps have a status page somewhere <civodul>as for the actual status, i think you can look at the latest commits and see how it diverges from master <civodul>perhaps you can email the list then? <civodul>all i can tell is that we'll merge core-updates before staging :-) <demotri>civodul: Yes, we should definitively make it more formal. <demotri>It looks like there wasn't done much on staging since the last merge. <efraim>TIL octave@3.4.3 won't build with gcc-7 <mbakke>it would be good if we could teach cuirass when to start branches etc :) <mbakke>civodul: I did try to not immediately re-seed (and remove the read from /dev/hwrng), to no avail <mbakke>I'll have time later today to work on it more <mbakke>also, I have a fix for aarch64 kernel <rekado>mbakke: what do you mean by “when to start branches”? A toggle switch to tell it not to build an existing spec? <Chiliparrot>Coming from Gentoo, the only thing I really miss so far are use flags; are there any plans to add something similar to guix? I've seen this has been discussed for nix, but without real results... <nckx>(Just an idea; no code.) <mbakke>rekado: I mean being able to disable 'staging' evaluations until c-u is merged <mbakke>so that it won't take up build farm resources <mbakke>also, there could be a page saying when the next build starts :) <Chiliparrot>nckx 👍 that has been in May... is that long ago in terms of guix-progress? ;-) <roptat>depends on the subject, some things move fast, others don't <rekado>Chiliparrot: not all ideas are actually worked on. <nckx>Chiliparrot: ‘progress’ is a loaded term ;-) It depends on who's excited by the idea, and how much they can/are willing to work on it. <rekado>note also that it ends with a question. It’s not clear if this is the best way to go forward. <nckx>I think many people are unconvinced by ‘use flags’ being a good solution to anything. That's me, anyway. <Chiliparrot>Imho it's quite nice to have a way to say to influence which dependencies get pulled in during an installation <nckx>Sure, but that's already possible by writing trivial amounts of Scheme. <Chiliparrot>Currently, it's up to the package, for example, wether to support Postgres or mySQL, right? <nckx>It's up to the packager/distribution which defaults are chosen, yes. <roptat>and it's up to gentoo to allow you to choose between the two ;) <roptat>use-flags also mean more work for maintainers, and we don't have that many people yet :/ <nckx>It's really pretty trivial to (inherit foo). It really is. If you think you're better qualified than your distro to choose your RDB, you can write some Scheme 😛 <nckx>Gentoo style (‘in-spec’: dovecot@2.3[db=mysql][-ssl] or whatever) flags would be a mini-DSL on top of our DSL to set some options. Is that really what we want? <nckx>rekado: And is that a good or a bad thing? <rekado>e.g. spack install hdf5@1.10.1 %gcc@4.7.3 cppflags="-O3 -floop-block" <Chiliparrot>I guess in normal use, it's not too terrible to change an existing package... but it's quite convenient when you can make a global decision that you don't want to see Package A pulled in as a dependency <rekado>but it would be nice to have a way to more easily produce package variants <rekado>Chiliparrot: you can do that with input rewriting <nckx>Chiliparrot: AFAIK there are plenty of long-time Gentoo users here (I'm one), it's not that we're opposed to a good CFLAG. Guix actually gives you more freedom, not less. <rekado>Chiliparrot: i.e. you can go through the full depedency graph of *all* your packages and rewrite their inputs to kick out or replace inputs. <Chiliparrot>There's no connection between inputs and build/configuration options, is it? <nckx>That's why it would place a huge maintenance burden on an already heavily over-burdened group of package maintainers. <nckx>That's why I don't like the ‘flag’ idea. <nckx>It hard-depends on humans doing a *lot* of boring work. <nckx>That direction is not one we can afford to go in IMO. <Chiliparrot>I guess a rather simple approach would already help in most situations... but as soon as there is no default variant of a package, there's a big danger that you have to compile lots of packages on your own; that's actually one of the major downsides of Gentoo for me <nckx>(Busy, please don't interpret my brevity as rudeness or negativity.) <Chiliparrot>I won't mind, nckx - after all, I'm not paying for your time ;-) <sneek>Welcome back paprika, you have 1 message. <sneek>paprika, nckx says: I tried to reply to your MSG but you'd left the channel. <paprika>anyone able to get the tor browser working on Guix? <nckx>paprika: Great! Glad I couldn't help 😛 <paprika>I'm don't feel like using the icecat addon <Chiliparrot>I had something different in my mind than rekados example, though: No additional options when calling "install", but rather a list of packages (flags) to avoid, and a list of packages which should be used when they are optional. <Chiliparrot>Imho that would even make life somewhat easier for package authors, as they would not have to decide which features are desirable, but rather check what the user prefers <janneke>hmm our apache/httpd example is broken, /me wonders is that still a popular web server <janneke>once i find a working setup, i'll fix the docs <Chiliparrot>👍 (but I guess Cherokee or nginx would be fine for me as well - I don't have special needs ;-) <janneke>yes, i would like to install that which is receiving the most guix love <roptat>definitely nginx: every other service that need a web server depends on nginx <nckx>janneke: That's nginx. We don't have Cherokee (or lighttpd), we do have Hiawatha but it's missing a service. <nckx>roptat: How does that work? I use nginx, with a huuge nginx.conf. Would Guix try to add locations to that? Proxy back ends? Sounds error-prone. <nckx>If you use them, of course. <roptat>nckx, web service extend the nginx-service-type with their on location block <roptat>I think they allow you to change that location block <nckx>So when you say ‘depends on’ you really mean it. You can't, say, run Apache on 443 together with any service that extends nginx like that, right? <roptat>you can still modify the service type so it doesn't extend nginx <nckx>When I put it like that it sounds bad. Wasn't my intention. I'm sure it makes initial/simple set-ups a breeze. <nckx>It's surprising, though. <roptat>it's nice when you want to have a service and don't really care about the web server itself <roptat>you just declare the service, and it adds the nginx service automatically <roptat>and you can add more services, and they just extend nginx <roptat>but if you want to use another web server, you have to do more work <Chiliparrot>Links to running configurations would be really helpful <nckx>roptat: Thanks for the info. I think I'll stick to my manual approach… <nckx>Chiliparrot: The manual is part of Guix (doc/guix.texi); patches are always welcome! There's a ‘cookbook’ being prepared for the more hands-on tutorial-style content, but it's still in its own branch (wip-cookbook). <nckx>Maybe not, it's 3 years old. <roptat>wasn't updated since, so once we have our cookbook online, search engines will probably start to prioritize it <nckx>We could even ask davexunit nicely to remove it if it's no longer maintained; OTOH it might be a nice namespace to park in. *nckx dunno what is Chef. <foxmean>Hello everybody, I have some small question after I've try to search with duckduckgo and found no one talk about install guix on void GNU/Linux, yet. The question is: how can I start guix-daemon using runit? I've try to copy guix-daemon to /etc/sv/ and create symlink to /var/service/ (like it said it runit's wiki). But it doesn't work because of guix-daemon is not directory. <roptat>nckx, it's a tool for deploying configurations <nckx>I MEAN: Oh, like Guix Deploy? <roptat>foxmean, I don't know how runit works, but shouldn't they have documentation on how to create a simple service? <civodul>mbakke: bah! this entropy thing is really crazy <civodul>but it does seem that we already have two fixes, even if they don't have the effect we had hoped for <roptat>foxmean, according to their wiki (Service directory layout) you need to create a /etc/sv/guix-daemon/run script that contains "exec guix-daemon --build-users-group=guixbuild" (also, see how to run the guix daemon manually in the guix manual) <roptat>(I'm not entirely sure about the group name) <roptat>foxmean, if you manage to create a runit service, would you consider contributing it to guix? You'd send a patch to guix-patches@gnu.org, with the service added in etc and the manual at doc/guix.texi updated :) <nckx>roptat is stealing all my thoughts today. *nckx tightens tin-foil cap. <sfrantani>Hello Guixers! I'm packaging a MELPA package but I've not been able to find any kind of license neither on MELPA nor in the Gitub repository. Does this mean that the package can't be added to Guix? What input should I pass to (license) ? Thank you <sneek>sfrantani, you have 1 message. <sneek>sfrantani, nckx says: I've only ever used Guix System to build Guix. I'm afraid chances of master fixing your issue are slim, but let's be optimistic. <roptat>sfrantani, by default if there is no license, the package is "all right reserved", so it's not free <kmicu>sfrantani: could you link to it please? <nckx>sfrantani: If you're certain there's no licence info, I'd start by e-mailing (or otherwise asking) the maintainer. Some people simply don't realise that putting your source code on-line for all to see & download doesn't make your software free or open. <nckx>Oh. ‘All rights reserved.’ <foxmean>roptat: for sure, sir. But now I am cannot start a service. The result of service's status is "timeout: down: guix-daemon: 0s, normally up, want up". <roptat>foxmean, could it be the daemon exits too early? do you have logs? or maybe the service script cannot find guix-daemon <roptat>foxmean, what happens if you run the script from your shell, instead of with runit? <nckx>sfrantani: Source file headers are actually more important than any LICENSE, COPYING, or ‘Licence: foo’ notice on the Web site. Those are really just hints (with legal value, but still, always check the source files to be sure. They win.) <roptat>(iirc, you moved guix-daemon away from its location, so now maybe there's no guix-daemon command available anymore) <sfrantani>nckx: Yes you're right, I didn't even thought about opening the code. Sorry about the stupid question ._. . <foxmean>roptat, run "exec guix-daemon --build-users-group=guixbuild" in terminal, isn't it? <roptat>rather, run /etc/sv/guix-daemon/run <roptat>have you made it executable? (should it be executable?) <foxmean>roptat: I've cd to /etc/sv/guix-daemon/ and run "./run" the output is "./run: 2: exec: guix-daemon: not found" <roptat>so you moved guix-daemon away, right? <roptat>could you re-install it where it was? <roptat>or maybe better: use "exec /root/.config/guix/current/bin/guix-daemon" instead of just "exec guix-daemon" in that file <roptat>foxmean, actually try with "exec /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild" <roptat>since that's what's in the systemd service <foxmean>roptat, now I'm trying "exec /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild" and it still runing, hope it works. And I have no idea where guix-daemon it was, so sorry. I've just follow https://guix.gnu.org/manual/en/html_node/Binary-Installation.html step by step. And guix-daemon appear in step 5, which I cannot run the daemon. <foxmean>By the way, so sorry for my poor English. <nckx>foxmean: No need. It's probably much better than our <whatever your native language is>. <foxmean>Oh, It's work now. I can install hello package with at least root user. <roptat>cool! it should work for any user <roptat>again, please consider sending us a patch :) <foxmean>I will check it carefully and will contribute that runit part of manual. <quiliro>roptat: Saluton. Mi auxdis ke vi estas traduktisto. <nckx>quiliro: Mi fartas bone. Kaj vi? <quiliro>nckx: Mi vekas bone. :-) Kion vi faris en Gikso nun? <nckx>quiliro: Mi konstruas qt-5-on \o/ (por testi altgradigan cryptsetup-2-on). <brendyyn> blender 2.80-beta-0.3c3d80e → 2.80 /gnu/store/sgfp47964iiq1i1mqjyfpr64drpid4mk-blender-2.80 <brendyyn>Guix considers this to be a downgrade instead of an upgrade and thus does not update automatically <nckx>brendyyn: Heh, I just noticed that yesterday (Guix considering 2.x-rc1 → 2.x a downgrade). Feel like reporting a bug today? <nckx>I'm not sure what the generic algorithm would be here though. Some projects use 1.2 < 1.2b. Versions are, generally, a mess. <brendyyn>i think it can be made to explicitly understand the words "alpha" "beta" and "rcX". that is not unreasonable <efraim>asciibetically, is there a 'good' symbol that's lower than 0? <efraim>Actually I guess that doesn't really help with having fewer characters <brendyyn>It sounds very Not Invented Here to me. surely there is some library that implents version comparisons <nckx>I doubt the set of versioning conventions in Guix is solvable. <nckx>We can't declare ‘semver is the only true ver’ and ignore practice. <nckx>brendyyn: Oh, I don't doubt that at all 😃 <brendyyn>so it already uses an external tool to do it <nckx>Damn… if only it were NIH'd, then we could fix it. /s <joshuaBPMan>well that's weird. My nginx server apparently doesn't want to serve my webpage anymer. <janneke>joshuaBPMan: just got it running. the default extra-config lacks a newline, or virtual hosts are appended without newline; i'm having a look <janneke>joshuaBPMan: it can be worked around by doing: (extra-config '("TypesConfig etc/httpd/mime.types\n")) <janneke>i wanted to get it running to fix the docs, before switching to nginx as nckx suggested <jlicht>re: the version ordering, it might still make sense to attempt to parse (and order) versions as semver nonetheless <jlicht>or are there situations in which a semver ordering is arguably wrong as far as guix is concerned? <bavier>guix uses glibc's versioncmp function for version ordering. <bavier>nckx: probably, didn't take the time to look up the actual name ***freedom is now known as gnufr33d0m
<nckx>Are there semvers that strverscmp sorts differently from the semver spec? <bavier>which, I think is an appropriate strategy. If we think versions could be compared better, getting that into glibc would be a good path <nckx>It's important to remember that semver is just an opinion piece on the Web that some people choose to follow (not even implying they follow it well). <CcxWrk>How hard is it to replace the init system in GuixSD? I'd like to go with s6 & s6-rc. <pinoaffe>CcxWrk: the shepherd is configured in gnu guile, so I'd presume you'd need significant shimming to replace it, but I have not really looked into how it interfaces with guix <nckx>So using the regex at said blog (semver.org), 34% of Guix packages do not even parse as semver. That's because not even ‘1.0’ is valid, it has to be ‘1.0.0’. The remainder may or may not actually follow the ‘semantic’ part, they just happen to parse. I think prioritising semver over strverscmp where they disagree, if they disagree, is undesirable. <nckx>CcxWrk: Very. Think project, not configuration. I'd look into starting s6 from the Shepherd instead. It won't be PID 1, but what kind of badly-designed service manager insists on that? 🙂 <CcxWrk>pinoaffe: It's very robust and as feature rich. Good separation of concerns, etc. <nckx>I used to keep Guix's s6 packages updated. Not so for the past few months, but it should be in usable shape. Good luck. <nckx>Bother me if something's badly broken, I'll probably feel responsible. <CcxWrk>Well, if running what I'd consider a sane PID1 is way too hard I'll pass on GuixSD entirely. <nckx>CcxWrk: I suggest you try a distribution that ships or supports s6 as PID 1. Guix System does neither at this point; I don't see that changing. <davexunit>using a different init system would effectively make using guix system pointless. <davexunit>might as well install guix on top of another distro at that point. <CcxWrk>I might try to craft something from combination of static slashpackage and Guix overlay. But not right now. <davexunit>the whole configuration management system relies upon shepherd <CcxWrk>davexunit: I think there is feature parity with s6-rc. But that will be a lot of code I guess. *nckx looks up slashpackage. <CcxWrk>Making core that is able to bootstrap Guix ought not be that hard. That, or I'll extend Sabotage with versioned builds. <CcxWrk>How is /bin/sh and other libc-hardcoded paths handled in guix? <nckx>CcxWrk: They are patched to refer to the correct /gnu/store paths instead. <CcxWrk>But surely you still want to be able to run scripts written with #!/bin/sh shebang? <nckx>CcxWrk: Guix System by default creates compatibility symlinks for /bin/sh and /usr/bin/env, but the OS does not use or depend upon them. <CcxWrk>OK, good. How do I control those symlinks? Is that GuixSD-only thing? <nckx>The special-files-service-type. <nckx>(It needs the Shepherd. ;-) <nckx>(service special-files-service-type ("/usr/bin/env" ,(file-append (canonical-package coreutils) "/bin/env")) ("/lib/ld-linux-x86-64.so.2" ,(file-append (canonical-package glibc) "/lib/ld-linux-x86-64.so.2"))) <kmicu>CcxWrk: replacing init, supervision and service manager is nothing difficult (only a lof of boring engineering work) but you need to do that on your own. Supporting multiple init systems is not a Guix System goal. *kmicu even dare to say that the init system is not really so important but it’s more of a fashion statement. <jgibbons[m]>Speaking of init, I sometimes experience a kernel panic when I shut down using the "sudo shutdown" command. I think it might be a problem with shepherd. <jgibbons[m]>Am I the only one here who has experienced such a problem recently? <rekado>jgibbons[m]: can you see what triggers the panic? <jgibbons[m]>No. I have yet to discover a pattern. It isn't common enough, and I haven't tried to purposefully trigger it. <jgibbons[m]>I'll make sure to take a picture when it happens next time. *bavier rarely shuts down computer <jgibbons[m]>The only thing that seems related is I run "sudo shutdown" from a gnome terminal, enter my password &c, and it begins the shutdown process, then the kernel panics. But it doesn't happen every time I shutdown from the gnome terminal. <jgibbons[m]>I'll file a bug report and attach the picture next time it happens. The segment of the kernel log around that time should also be useful. <lispmacs>hi, I was getting an error when trying to use 64-bit wxmaxima. When I enter the math "4 * 3.1415;" I get an error (but not from Maxima command line) <lispmacs>i was going to report it as a bug, but I'm thinking it might be some weird interaction between my Debian 9 desktop environment and WXmaxima <lispmacs>i was wondering if somebody could install wxmaxima and try the same thing, from Guix system <lispmacs>I have one guix system in the office, and tried it on that one, and did not get the same error. But that system is 32 bit, so not sure if that quite resolves the question <bavier>lispmacs: trying it now... have to build first, I think <lispmacs>not sure if you are a wxmaxima expert or not, but after typing "4 * 3.1415" into the window you must press Ctrl-Enter, or use the run command from the menu. <bavier>lispmacs: seem's to work for me; I don't see any errors. <lispmacs>bavier: okay, thanks. Must be something weird going on with the I/O <lispmacs>between my Debian 9 Gnome environment and the wxmaxima app <bavier>lispmacs: weird, do let us know if you figure out more <lispmacs>bavier: okay, but the older maxima version in Debian seems to be working fine, so probably just use that, until I manage to get Guix system installed on here