<nckx>kabo: Make sure you enable substitutes if the installer asks you that. *nckx has no experience with the installer. <kabo>the installer doesn't ask anything about substitutes <kabo>from the docs: "Substitutes from the official build farm are enabled by default when using Guix System" <kabo>I did see the word substitute flash by multiple times when running guix install, I'm pretty sure it was set up to use substitutes <civodul>rekado: we're ENOSPC on several build machines <dongcarl>what do people do when they see "source file newer than compiled" errors while devving on Guix? <dongcarl>civodul: I did... And I see the note, and also an error, that is referring to a previous version of my file <dftxbs3e>samplet: well, what should I give you? the file? <kabo>ok, brand new fresh install <kabo>now it's failing on x4.pem <kabo>nckx: it looks to me like it's using substitutes <kabo>Is it a mirror that hasn't been updated maybe? <kabo>maybe the mirror closest to me is outdated? <kabo>and the le-certs downloaded just fine! <dftxbs3e>samplet: http://dpaste.com/0GSDXXM - output of: "./pre-inst-env guix build --target=powerpc64le-linux-gnu bootstrap-tarballs --keep-failed 2>&1" - for some reason, running a second time after the first ranlib failure gives this result but it may be interesting.. uploading config.log in a sec <kabo>to install guix, step 1: don't be in NZ :D <dftxbs3e>gnu.org certainly doesnt block countries <kabo>I'm thinking it may be letsencrypt that has a bad mirror out here? <kabo>it was le-certs that was having issues <kabo>aww, man, after all that, I thought I could finally try to build firefox, and the bootstrap script comes back saying "Bootstrap support for this Linux distro not yet available" :( <dftxbs3e>unfortunately I can't write code in the Guile Scheme.. but otherwise I'd love to help <samplet>dftxbs3e: Sorry – I was AFK. I am looking at what you sent now. <dftxbs3e>samplet: don't be sorry - I'm already thankful you agree to dedicate time to this :D <dftxbs3e>buenouanq: well yeah, it's very foreign to me, I'm a C and Rust guy, Lisp is largely different <buenouanq>I want to make wobsite using guile-web and a database. <buenouanq>Which database has the best guile interactivity at the moment? <buenouanq>I've used postgres before, but it's looking like sqlite might be my dude <samplet>buenouanq: SQLite is probably the best option for Guile at the moment. <samplet>dftxbs3e: Hmm.... This seems related to the float128 stuff again. <dftxbs3e>samplet: how did you see that? Also I sent an email on the guix-devel mailing list, did you get it? I'm not sure it was actually sent. <samplet>dftxbs3e: Searching the undefined references from the config.log. I do not see your message. IIUC, the list is moderated, and most of the moderation happens during the day in Europe. <samplet>Most of Guix happens in Europe, in fact. <dftxbs3e>samplet: well I'm in europe but currently I got weird sleeping times <dftxbs3e>and sleeping 5 hours per night or so somehow, can't sleep more lol <switchy>is there a way to not use substitutions only for the final derivation, and not its dependencies? I want to build netcdf-fortran with gfortran 8.3.0, since it seems like the version I got (however that was) isn't built with that gfortran version, and so doesn't work... <switchy>oh, I guess gfortran is defined as gfortran-5 <samplet>switchy: You could change the package definition to use gfortran-8 instead of the default gfortran. <samplet>switchy: I think even using “--with-input=gfortran=gfortran@8” would do it. <switchy>samplet, aha, I just stumbled upon that and it seems to be working <switchy>maybe I should define gfortran as gfortran-5 in my GUIX_PACKAGE_PATH? having some things on -5 and others on -8 is going to cause chaos I think... <switchy>I can build/link this test binary, but ld warns about different libgfortran versions, and I get the ol' shared library error (on libnetcdff.so.6) when trying to run the binary <samplet>switchy: Are you building a test that links into netcdf? <switchy>samplet, yeah, I'm using nf-config to give me the include/link flags (which points into the store at the derivation I just built on gfortran@8) <samplet>switchy: Are you using version 8 to build the test as well? <switchy>samplet, I am indeed. fortran generally requires the compiler to match the libraries at compile time anyway, so I couldn't even build before since the library was at gfortran@5 <samplet>Huh. I thought that “--with-input” was supposed to be recursive. <switchy>it seems like it was -- it rebuilt hdf4, but the ld warning was to a different hash? <switchy>so when I built the @8 netcdff, I built mabrdc...-hdf4-alt-4.2.13, but the warning was for 8lf3n8...hdf4-alt-4.2.13 <switchy>which seems like it was built on gfortran@5 ***reepca` is now known as reepca
<samplet>switchy: Could that path be cached in your test configuration somehow? *samplet doesn’t know much about Fortran stuff. <switchy>samplet, what do you mean by my test configuration? <samplet>switchy: I’m thinking like if you run “./configure” or something before building your test code. <switchy>ah, no, this is me just testing raw gfortran on a single source file to make sure it compiles <samplet>But the error was about linking into the library you just build, no? <samplet>So how does it know where the library is? <switchy>the nf-config binary comes with netcdf-fortran, and knows where the library is. the error is actually on a dependency <switchy>well, the final shared library error on running the library is on the library I just built, true <switchy>so if I do `guix gc -R $(readlink -f ~/.guix-profile)', that hdf4-alt built with gfortran@5 pops up -- the one built as a dependency of netcdf-fortran isn't there. I guess that explains that bit? <samplet>Wait, hdf4-alt built with gfortran-5 is in your profile? <samplet>It’s probably getting picked up from there, and then being linked with the gfortran-8 netcdf. <switchy>there are actually two store paths to hdf4-alt in my profile -- maybe guix gc isn't the right tool to be using? <switchy>yeah, the one that showed up in that command is the one that ld warned about <switchy>oh actually I'm mis-interpreting the guix install output, sorry <switchy>so during the installation of netcdf-fortran, it had "building /gnu/store/...-hdf4-alt-4.2.13.drv" <switchy>but that has the .drv suffix, so it's not the same as the hdf4-alt in the profile <samplet>switchy: Right. The derivation (“.drv”) is the description of how to build it. <switchy>yeah, that explains why I have two versions of hdf4-alt in my profile -- one is built with gfortran-5, and the other with -8 <switchy>and the wrong one is getting picked up <samplet>switchy: Is there anything interesting in $LIBRARY_PATH? <switchy>samplet, that just points to ~/.guix-profile/lib <samplet>switchy: Did you ever get a conflict warning? Did it pick an arbitrary version when populating the profile “symlink forest”? <samplet>Where do the links point in “~/.guix-profile/lib”? <switchy>samplet, yeah, the conflict warning was warning: libgfortran.so.3, needed by /gnu/store/8lf3n8nn9phs3j6n09njb4jcwq4jbs30-hdf4-alt-4.2.13/lib/libmfhdf.so.0, may conflict with libgfortran.so.5 <switchy>but there is actually no libgfortran at all in ~/.guix-profile, nor a libhdf of any kind <switchy>oh I think I might know what it is... <switchy>since I installed netcdf separately, and that built hdf4-alt as a dependency, that's probably what I'm linking against <switchy>so I'd need to also rebuild the netcdf package with the same input dependency replacement... <switchy>samplet, okay, progress! no gfortran conflict warning <switchy>but I can't run the end result: error while loading shared libraries: libnetcdff.so.6: cannot open shared object file: No such file or directory <switchy>feels like an LD_LIBRARY_PATH thing, but I've never seen guix recommend that I set that (and it's probably not a good idea/) <samplet>switchy: Not for this situation (AFAIK). <samplet>Unless gfortran didn’t setup the rpath of resulting binary. <samplet>Actually, it’s worth a shot just to get some progress. Just point LD_LIBRARY_PATH wherever libnetcdff.so.6 is. If it works, you can come back to the root cause. <switchy>samplet, yup, so if I set LD_LIBRARY_PATH to the netcdff and netcdf lib directories, it does run correctly <switchy>I shouldn't have to set the rpath myself, should I? ***rEnr3n3 is now known as rEnr3n
<switchy>samplet, oof I'm a dummy -- I needed gcc-toolchain <switchy>dingdingding now everything is working as expected! <samplet>switchy: Ugh. That one trips up a lot of people. Glad to hear it works now! <switchy>samplet, thanks :) so just one last thing -- can I somehow set gfortran@8 as my default? <samplet>switchy: I can’t think of an easy way to do it. You could run Guix from a local checkout that has been patched, but that is pretty inconvenient. <samplet>You could try monkey-patching it from GUIX_PACKAGE_PATH, but I’m not sure how exactly. <samplet>I don’t think that approach is “officially sactioned”. <samplet>It might be worth asking <help-guix@gnu.org>. <switchy>maybe something with inferiors? thanks for the help! <samplet>Next time we’re both here, I will come up with a patch. <reepca>Somewhat off-topic question: how does one properly copy a directory recursively, including dotfiles? cp -r doesn't include dotfiles. <apteryx>reepca: are you doing cp -r * in your $HOME? <apteryx>otherwise cp -r some-dir which has dotfiles should work <reepca>apteryx: trying to backup a git repository <reepca>although I actually just found out that I was in reality trying to backup a source release. It took me about 15 tries before I finally looked in the original directory and saw it didn't have a .git either. <apteryx>or 'cd somewhere && git clone repo-path' <reepca>yeah, got it working now, now on to the much more complicated ways for stuff to not do what I epxect! <rvgn>rekado kabo, The permanent workaround for ".pem issue" with "guix pull" was to add "nss-certs" to the system profile. <PotentialUser-40>can anyone say if there's a better way to find which module should be used to include dependencies than grepping the `packages/` directory for "define-public <<package-name>>"? <apteryx>PotentialUser-40: I often do M-x guix-edit in Emacs or 'guix edit' from the CLI. <apteryx>you can also do: guix package --show=emacs | recsel -p location <reepca>how exactly do search-paths work in builders? For example, if a package has as a search-path (search-path-specification (variable "FOOPATH") (files '("foo/"))), will the set-paths phase of builders just add the foo/ subdirectory of every single store item that has one and is either an input to the derivation or referenced by the inputs? <reepca>I've got a strange situation where I'm in an environment that has a superset of the inputs necessary to build a package, but manually building it won't work because something isn't found. Meanwhile the proper build succeeds, I assume because something one of the inputs references (but that isn't an input) gets picked up by an environment variable. ***janneke` is now known as janneke
<rekado_>ENOSPC on build nodes seems to have resolved itself with the nightly garbage collection. <ZombieChicken>I seem to recall there was an idea where everyone would be able to compare checksums of programs with each other automatically. Did that ever happen? <ZombieChicken>also I wanted to clarify something; do packages also install all their headers? I really, REALLY don't like the concept of -devel (or similar) packages <rekado_>ZombieChicken: packages are not split into headers and binaries. <rekado_>ZombieChicken: comparing hashes can be done with “guix challenge” ***rekado_ is now known as rekado
<reepca>is it normal for emacs packages to have a makefile that lacks an install target...? <calher>So, does "1.0" mean Guix is ready for production? <abbiya>it means it wont break things further <calher>What does "it won't break things further" mean? <rekado>calher: Guix has been ready for production for a long time, according to those who have been using it in production. <rekado>reepca: Emacs packages often have poor Makefiles. <reepca>rekado: what's the usual workaround to make installing possible? <calher>rekado I am thinking of running my TV with Guix <abbiya>can guix replace the tools like composer, npm ? <rekado>reepca: there’s no *one* workaround. You need to figure out what’s missing and replace those phases. <rekado>civodul: the ENOSPC problem seems to have resolved itself. <rekado>on Zabbix I don’t see any warnings about disk space, not even in the history. <amz3>abbiya: several attempts were made to package npm modules <amz3>abbiya: as for php I don't know <amz3>abbiya: but php interpreter is in the package repository <civodul>rekado: i think i noticed it shortly before the nightly mcron job <g_bor[m]>I was trying to modify our openssh service to change the activation snippet into a one-shot service to see if it helps the openssh does not start on boot problem. <g_bor[m]>I am quite sure, that I am doing something wrong, but the current behaviour of shepherd/guix system reconfigure seems to be problematic when errors occur. <g_bor[m]>I got a backtrace after the 'to complete the upgrade run...' message, then an error in procedure scm-error, wrong type argument, and a warning: while talking to shepherd: no such file or directory, and finally an unresposive vm. <g_bor[m]>I would not expect neither shepherd, nor guix system reconfigure to hang on an error, whatever config is passed. If something is wrong we should report an error instead. Wdyt? <rekado>g_bor[m]: can you show us the diff? <g_bor[m]>yes, of course. I am quite sure that there is something wrong with it, but I did not expect it to break this way. <g_bor[m]>I believe that I am making a mistake in the third hunk. <civodul>g_bor[m]: 'openssh-activation' should probably depend on 'user-processes' <civodul>so that it executes after all file systems have been mounted <g_bor[m]>I will add this suggestion, then show the diff. <civodul>g_bor[m]: it should be: (start #~(lambda () #$(openssh-activation config))) <g_bor[m]>civodul: I did modify it like you wrote, and now I get the hanging reconfigure again. <civodul>i always test with 'guix system vm' first <g_bor[m]>This is a vm, with guix system installed in it. <brendyyn>Is there a list of all the people with git access? <brendyyn>g_bor[m]: Do you know whatit means that some people are hilighted in pink. <g_bor[m]>I don't know, but I would say core-maintainer, or similar. <rekado>those highlighted in pink are admins who can change the group settings <rekado>so, on the Hurd using the daemon with build users doesn’t seem to work. <switchy>in a package definition, can I get the path to the unpacked source directory? (I want/need to pass a directory in the source as an argument to cmake for the build) <rekado>switchy: do you mean the unpacked source directory of the *current* package or of another? <switchy>rekado, of the current build -- but for a cmake build, (getwcd) is just the derivation directory <switchy>since it's an out-of-source build, and the build directory is created as a sibling <switchy>hmm, I guess that would work... the build process seems to magically detect where the source directory is from the tarball, so I'd have to hardcode that <switchy>I don't really mind doing that, but I thought I might've been overlooking something <brendyyn>It's possible we have a mesa bug, where mesa is reproducibly generating the same cache file names, and is the cause of my bug at #35575 <rekado>the multi-line shebang that Guix uses doesn’t work on the Hurd. <brendyyn>rekado: I think the guile manual explains all these hacks <rekado>yes, I know, but this looks incorrect <rekado>well, the manual shows that this should work, but on the Hurd it doesn’t work <civodul>i believe the 2nd and 3rd line are read by Guile <civodul>looks like you already got started on the grand Hurd plan :-) <civodul>we got ~45 bug reports since the release if i'm not mistaken <buenouanq>When I can download and install Guix/Hurd over GNUnet, I will finally feel ok about stuff. <ruffni>got my guix sd to work. only question: browser of choice is icecat? is it possible to have js running? because i can't even chat with you here (via webchat.freenode.org) without js..... and even disabling all the plugins and scrolling through security settings still won't make it work. also icecat seems to not show numbers of any kind (sounds weird and believe me, it is). searching for bz2 results in bz (2 replaced by a noticably <ruffni>no luck with that... also: the amount of plugins i'm supposed to need to get websites to work (a plugin for each website) kinda creeps me out.... <buenouanq>ruffni: you can just disable the librejs addon <brendyyn>i disabled librejs since because even when id whitelist sites with it they'd still be broken <ruffni>so is my experience; but disabling the add-ons also won't make js work <ruffni>in the current state icecat is simply unusable <buenouanq>ruffni: I literally have no problems with it working at all. <brendantest>Works for me, although it looks like the freenode client has google spyware in it <brendyyn>ruffni: i think you are just having a problem yourself which can be fixed. icecat is fine <rekado>civodul: the second and third line appear not to be read by Guile. When running “/usr/local/bin/guix perform-download” it complains about all lines (except for line 1) <rekado>but I’m sure I’m just doing something wrong *rekado is debugging openmpi again… :( <ruffni>so did you guys tinker with anything after installing icecat? is it more than just "guix package -i icecat"? <civodul>ruffni: there are several plugins enabled by default <civodul>one of them is LibreJS, which unfortunately breaks some site, even if they only distribute free software <civodul>and then there's a couple of other things <civodul>if you go to the "main" page (open a new tab), you can select which ones you want to enable <maddo>that's because librejs unfortunately needs an explicit license in all javascript <brendyyn>I guess they are trying to push a convention <maddo>license info is usually stripped by many if not every css minifier <civodul>maddo: i think it's also able to recognize common libraries, but yeah <civodul>the license tags they propose is really just a handful of bytes <ruffni>ah yeah... stupid of me. thanks! freenode webchat works now :) but what about those numbers? has anybody else experienced such a thing? i can type a literal 2 into location-bar and theres just this wide white-space <maddo>well common libraries detection doesn't really work well, since sometimes headers and js post-processing will make it fail <maddo>i.e take all jquery versions <maddo>all processed differently depending on CDN and such stuff <civodul>yeah it's a hard problem, and one JS developers are not really interested in :-/ <rekado>civodul: the problem is that “./pre-inst-env guix build -S hello” fails to download the source code. <rekado>it says “error: failed to run download program '/root/guix-1.0.0/nix/scripts/download': Permission denied” <rekado>but the thing is executable by everyone. <rekado>it isn’t really high priority, of course. I’m just playing with this while waiting for something else to compile… <civodul>rekado: i was referring to the openmpi problem, which i thought might be higher-priority :-) <civodul>i colleague of mine hacks on openmpi so i could always ask for advice <rekado>we’re trying to use it on infiniband and omnipath nodes <rekado>a simple test with dune, however, simply produces no output at all <rekado>we also found that we have to tell mpirun to ignore openib nodes when we want to run on omnipath only or else it will mix nodes and communication will obviously fail on those that have infiniband. <rekado>the verbose output doesn’t help much <rekado>also, I found what I absolutely *must* pass “-prefix /gnu/store/…-openmpi-…” to mpirun or it will not be able to spawn the orte daemon on the remote nodes. <rekado>“-prefix $GUIX_ENVIRONMENT” will *not* work; it must be the actual openmpi target directory <rekado>the “-prefix” thing seems to be a Guix-only requirement. <civodul>so it's "mpirun -prefix ...", right? <rekado>with the locally built OpenMPI this is not necessary — even though it doesn’t use a default prefix either. *nckx reads backlog; gives dftxbs3e the secret fist-bump of the sleepless. <civodul>rekado: and what does it use when you don't pass -prefix? /usr/bin? <rekado>I’m not sure. It just aborts and says that it can’t reliably start the orte daemon on the target nodes. <rekado>it doesn’t say how it tries to start them. <rekado>(I can’t trace this because I’m not root on the scheduler, so I can’t just attach to the grid engine processes) <rekado>with strace it still doesn’t show me how it starts orted (I guess because that happens on the target nodes?) <rekado>BTW: the default gfortran is 8.3 but gcc-toolchain is 9.1. <g_bor[m]>I've found out why my previous diffs did not work. <g_bor[m]>In the openssh-activation we have a define, and shepherd hangs on that, giving me a backtrace about definition in expression context, and the whole machine becomes unresponsible. I fixed it by expanding the definition inline, it is almost trivial, but this still leaves two open questions: <g_bor[m]>1. I believe shepherd should simply fail to start the service in this case, print the stacktrace, and resume operation. Wdyt? <g_bor[m]>2. It seems that somehow gexps do not compose nicely, or rather I failed to find the way to do this properly. Any idea how should I fix this definition in expression context error? This might be problematic if we have more complicated services, this restriction on defines does not seem to be ok. Wdyt? <g_bor[m]>Another thing, changing the openssh-activation to a one-shot shepherd service does not solve the openssh not starting on boot problem. <bgardner>Hey guix; so I finally got my postfix.scm to the point where it builds but it turns out Postfix has an interactive installer that looks pretty incompatible with Guix without some fairly radical voodoo that is over my head. Would it be beneficial to submit the postfix.scm as a WIP anyway for a smarter person to run with? <g_bor[m]>bgardner: I believe so. There is some interest in getting postfix. I belive that the installer does not do much more than generating config files. If that is so, then we should provide a service to generate those. <bgardner>g_bor[m]: Okay, I'll submit the patch in just a bit then. Thanks! <g_bor[m]>ok, a bit more reading gives me this: we have to generate a main.cf, and then run make upgrade instead of make install. <g_bor[m]>I will have a look at that makefile later :) sounds like fun... <civodul>rekado: re gfortran, i agree, they should be matching <civodul>g_bor[m]: indeed, you cannot compose gexps in arbitrary ways, but that's the same with macros: they let you generate invalid code <bgardner>g_bor[m]: That postfix.scm hsa been submitted to guix-patches, thanks again <joshuaBPMan>anyone having some issues in exporting an org-file to odt on guix? I've got guix installed... <joshuaBPMan>I'm running guix system...and a customized emacs package of my own making... <joshuaBPMan>OpenDocument export failed: Buffer is read-only: #<buffer styles.xml> <terpri>joshuaBPMan, i get a similar error with a customized package for emacs 26.1 on guix system (typing C-c C-e o o in an empty org document -> "OpenDocument export failed: Buffer is read-only: #<killed buffer>") <g_bor[m]>civodul: I believe the real problem is that in this particular shepherd does not handle invalid code gracefully. Can this be helped somehow? <g_bor[m]>I could live with fixing some gexps to use let instead of define, but this failure mode was not to my liking :) <civodul>we'll need to look more closely at what goes badly <civodul>it's bug hunting + bug squashing time :-) <g_bor[m]>I will try to come up with a minimal reproducer, but it should not be too hard. <civodul>rekado: only now do i see your call for a hackathon! <civodul>we should probably set a date, actually <civodul>we did that several years ago when Guix was young and quite a few people joined on-line <vagrantc>so, when guix challenge shows differences ... how do y ou download the store items to be able to compare them? <amz3>vagrantc: you can install it using subtitutes and then you will have the it locally <amz3>IDK how to download the substitute directly <brendyyn>if he has build it then it wont use substitutes will it? <vagrantc>amz3: well, considering the substitute and the local build install to the same path ... ? <vagrantc>i'd have to manually download the substitute and unpack it somewhere <vagrantc>guix challenge --compare-with-diffoscope :) <vagrantc>or at least "guix challenge --download-to-dir=" <vagrantc>so it downloads and unpackes the variours differing ones somewhere <g_bor[m]>vagrantc: the docs on guix challenge says to simply wget it form the url where the guix challenge output refers to. *vagrantc double-checks the documentation <vagrantc>and it's a simple archive format or something? <reg[m]>Hi everyone. Yesterday I tried Guix for the first time and I'm really excited about it. I'm facing one issue, though: when I choose to encrypt the disk during installation, the system just won't boot. The Grub menu shows up, then disappears and I'm stuck on the Grub background image. Has anyone else seen this? I'm using the x86_64 GNU Guix System 1.0.0 iso on a Lenovo T430 laptop. The problem doesn't occur without encryption. <vagrantc>g_bor[m]: yup, clearly i just needed to read the documentation ... although i wonder if it still isn't worth a feature request to streamline it somehow... <affinespaces>I just ran into a stacktrace when trying to setup wifi in the installer, sent the report over to the e-mail address a few minutes ago. will try without encryption too to see if that works <g_bor[m]>vagrantc: yes, that would be a nice addition :) <reg[m]>g_bor: I'm not sure, I just used the default partition scheme (tried both with and without separate home folder). <reg[m]>g_bor: I mean the default partition scheme as proposed by the graphical installer. <affinespaces>I get the stacktrace (for a different issue) whether or not I use encryption or the separate home partition <g_bor[m]>reg: ok, I will have to have a look around. I did not notice the issue, but I did not do this using the graphical installer yet. <g_bor[m]>If someone with some hands on experience is here, then please notify us :) <reg[m]>g_bor: Thanks! If there's anything I can do, let me know. <tao[m]>I was just running through all the packages Guix doesn't have to decide if there's anything I can'ti live without. It was going fine until I hit `fzf`?! <apteryx>tao[m]: that's not much of a problem when you realize how fun it can be to package things for Guix ;-) <tao[m]>Guix has Flatpak, that wasn't around last time. Congrats to the team on making that happen. Are there any gotchas to running it? <cyris212>Coming from Nix I am amazed how smooth my Guix experience is so far. <nckx>tao[m]: I don't use it myself (I don't think many Guixers do), but there's a ‘bug#35591: Segfault on flatpak remote-add’. Now, that's not good, but I guess it implies that it at least runs 😛 <vagrantc>cyris212: as in, Nix is more rough around the edges? haven't really used Nix, but curious about it <vagrantc>I would've expected Nix to be more polished, being an older project, more contributors, "stable" releases, etc. <cyris212>There are a lot of small things that sum up however and make the user experience a bit weird. <nckx>I'm also (pleasantly) suprised to hear that, given Nix's willingness to sacrifice for ‘just works’. Bundling, pre-built binaries, &c. <cyris212>For example if you want install software from a different channel you sometimes need to specifiy environment variables and sometimes pass the path through command line flags. <tao[m]>nckx: hmm not good but I've seen another user install docker through the Nix package manager on top of Guix and use it that way <g_bor[m]>I am testing the graphical installer, and the language selection menu is sorted based on the English names, not on the displayed names. <sirgazil>g_bor[m]: Yes, I saw that too. I don't know if the issue is reported though... <g_bor[m]>yes, I have also seen several sorting related commits, not one on this page. <sirgazil>g_bor[m]: By the way, if you are planning to install on a real machine using the graphical installer, I recommend waiting for the 1.0.1 release. I found some bugs in the installer that made things hard. <g_bor[m]>I am only doing a test install on a vw to have a look at this encryption problem reg reported. Do you have anything related to that on your list of bugs? <sirgazil>g_bor[m]: Not to encryption, no. Also some of the bugs I exprerienced using the graphical installer in a real machine were not visible in a VM I used for testing. <nckx>How can I ‘guix system reconfigure’ without immediately applying all changes? For some reason guix really likes to restart X for me… :-/ <nckx>(Hence killing itself before it can install the bootloader.) <g_bor[m]>reg: I just did a fresh install with encryption in a vm, and I can't reproduce the problem there. Also, sirgazil told me that some things behave differently on bare-metal and vm, but I don't have a spare computer to test on right now. <reg[m]>g_bor: Ok, thanks for checking! Is there any way I can provide you with logs or anything? If so I'd be very willing to. <nckx>tao[m]: Yes! Flatpak on Docker on Nix on Guix on GNU on Linux is the way of the future! <g_bor[m]>reg: are you getting dropped to the GRUB command line? <retiform>How do you get opengl applications to work on non-native systems?' <retiform>I tested out abiword and got: Gdk-ERROR **: 22:57:28.537: The program 'abiword' received an X Window System error. <vagrantcish>but my attempt to remove it from %desktop-services doesn't seem to work <vagrantcish>best i can do is run sddm on tty8 ... which works until i log out and then gdm and sddm start fighting about which is the active console <sirgazil>vagrantcish: Mark Weaver recommended me this line to remove packages from %base-packages: (fold delete %base-packages (list sudo nano)) <sirgazil>I don't know if the same applies for %desktop-services, though. I'm new to the configuration file. <reg[m]>g_bor: Actually I don't. I was hoping I could access a command-line interface by pressing "c", but nothing happens when I press c. :/ <nckx>reg[m]: Can you use the arrow keys? Are you using another keyboard layout than US QWERTY? <reg[m]>nckx: Spot on, my keyboard layout isn't US QWERTY. About the arrow keys I can't say, there's only one entry in the menu. <vagrantcish>gdm is still running ... but maybe not after a reboot <nckx>reg[m]: OK, so it's not the obvious (c on another key), but maybe you're being hit by something similar to my <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35583> (which I haven't investigated further, sorry). Seems unlikely™ that the keyboard not working has anything to do with your decryption troubles, but there have been stranger bugs. <reg[m]>nckx: Thanks for letting me know. I think I'll try a reinstall with US QWERTY just to rule this out (or not). <nckx>reg[m]: Good plan. If you are being hit by 2 bugs (or some weird interaction) it would be nice to rule that out. ***daviid is now known as Guest56279
<sirgazil>In the GNU system, when you open Guix manual in Emacs info, do you see it refers to Guix version number as 0.0-git? <sirgazil>For example, section 3.1 says, "Nevertheless, before you proceed with the installation, be aware of the following noteworthy limitations applicable to version 0.0-git" <rekado>I’m now trying to run the daemon on Debian GNU/Hurd without the build users and without chroot. <rekado>But I still can’t build anything because guix-daemon refuses to run perform-download as UID 0 <rekado>understandable, but I don’t know how this could have worked in the past. <rekado>patched it… I’m sure I’m violating all kinds of rules <rekado>“guix build -S hello” works now, but “guix build hello” only prints “madvise failed” over and over. <retiform>Anyone know how to do opengl on a non-guixSD system? <rekado>what do you mean by “do opengl”? <cyris212>Still has some rough edges but it works with 1.0.0 <nckx>retiform: I can't help you, but it would help if you named a specific application and the error message(s) (if any) you're getting, or at least the symptoms. <rekado>huh, looks like Guix on Hurd gets into an infinite loop any time it computes derivations. <nckx>‘Obviously, AbiWord needs a working GLX environment -- like the Gnome Shell, which however incorporates Gallium3D LLVMpipe to allow it to run without a proper 3D hardware driver loaded.’ <terpri>rekado, might be a guile error, from return_unused_stack_to_os in libguile/vm.c <nckx>I've installed AbiWord and it doesn't crash, but I get high-frequency flickering artefacts in the dark grey area surrounding the page that I can't screenshot but make the application impossible to use without going mad. <nckx>‘Something’ is definitely ‘up’. <bavier>nckx: I've seen that same on my machine <mfg>Hi, i just finished installing Guix 1.0. I then ran `guix pull && sudo guix reconfigure /etc/config.scm`. I noticed some warnings about /root/.config/guix/current not existing, which is right because i did not use sudo guix pull. But the Documentation says that sudo guix reconf... should use the User which runs that command, so this warning seems like a mistake or the Documentation is wrong ? <nckx>mfg: You can check that hypothesis with ‘sudo which guix’. <mfg>okay that seems correct it uses the guix from my home folder; Why the warning then ? <nckx>A too naive check somewhere? sudo might leave $PATH unchanged, but some code might check for $USER/.config/… and warn about it. <nckx>In fact, that's likely what's happening. <nckx>Not sure how to solve that properly. <nckx>Without being clever and creating other holes. <mfg>If that really is the problem, i can safely ignore it :D <nckx>AbiWord tests your GPU to limits where other software just doesn't 😒 <mfg>is `guix pull' sufficient to update the system or do i always have to reconfigure it ? <nckx>mfg: Guix pull only updates the package definitions available to all other commands, it doesn't build any of them. <nckx>Short answer: you always have to reconfigure it (for system packages) or ‘guix package -u .’ (for user ones). <nckx>If you're a Debianist: pull is equivalent to ‘apt get update’ IIRC. *nckx was never a Debianist. <mfg>Hm okay. I don't know Debian that good either :) <nckx>The ‘building’ you see when you run ‘guix pull’ is just compiling the Guile Scheme code that these definitions themselves are written in, which does take much longer than other package managers. That will hopefully improve some day. <mfg>well it's just 1.0 there will be time to optimize things, i guess :D <nckx>mfg: Most sane package managers have a separate ‘update the view of the world’ and ‘install a package from that world’ commands. Installing the latest thing at every new invocation might sound nice but really doesn't work in practice. <nckx>Source: all ‘package managers’ that try to do this. 😛 <nckx>Guix 1.0: ‘It mostly works’. <nckx>s/that world/that worldview/ to be exact. <mfg>I really like this system. <buenouan1>I've been using it as my only OS since v0.8 and it's worked better than any other distro I've tried from day one ┐( '~')┌ <arshin>buenouan1: which other distros did you use? <str1ngs>nckx: guix pull is like apt update. yes <buenouan1>systemd rendered it unusable and that's when I jumped ship <str1ngs>nckx: guix package -u is like apt upgrade. if your looking for another anology <mfg>str1ngs: thx for the example <buenouan1>but unlike apt upgrade, guix package -u won't leave you with a broken unfixable system ;3 <mfg>That's one reason why i wanted to try it, i'm used to frequently brick programs on arch and that's annoying :( <nckx>str1ngs: Ah, possible, I don't know what apt upgrade does ☺ *nckx thinks those two seem confusingly similar to each other compared to ‘pull’ and ‘upgrade’. <str1ngs>update vs upgrade I'm assuming you mean there? <str1ngs>yeah, everything has its own name. ie substitute vs binaries :P <nckx>I guess it's not a problem in practice but, for example, I just had to check whether ‘-u’ in Guix stood for ‘update’ or ‘upgrade’ because the two are so close. It would take me a few invocations on Debian to learn which is which. <nckx>(I know it makes sense, just… still.) *nckx is easily confused. <str1ngs>nomenclature can be a bitch sometimes :P