<g_bor[m]>I will push a fix for the version string tomorrow.
<bavier`>I'll try to put a bug report together for arduino ide too
<OriansJ>is there any particular reason why guix edit doesn't actually work? As in By changine the version and hash; guis still uses the old definition.
<bt>I'm sorry to be such a bother but I suspect this will be my last issue. Is there any special configuration that needs to happen to start xorg on a librebooted x60s, I've been using nomodeset since even in the installer because otherwise half my screen turns to static and it reboots, or it spams error messages indefinitly too quickly to read.
<bt>I'm going to continue trying things I suppose, I'll likely be back later though either to report on my success or to solicate assistance.
<jackhill>kmicu, nckx: thanks. I last used btrfs a few years ago (maybe three at this point, wow). At the time, my biggest complaint was that perfomance seemed slow, but I never benchmarked, so it could have just been a slow disk.
<jackhill>at least Guix will make re-installing fairly painless ☺
<PotentialUser-84>Does GuixSD not use ls to list directories? I'm playing around with 1.0 and am getting "command not found".
<buenouanq>there is a problem with the graphic installer
<PotentialUser-84>I have GNOME working. Do you mean that during the install, some utils like ls and cat are not installed?
<g_bor[m]>I've just pulled on one of my systems, and bumped into the can't make/remove session error, unable to log in from console. I remember seeing something about this on the ml, but can't find the thread. How can I fix this?
<apteryx>civodul: is it known that tests/guix-package.sh fails on master?
<apteryx>dongcarl: thanks for sharing your test failures. the guix-environment.sh and guix-pack-relocatable.sh are suspicious as I don't have these
<sirmacik>yay, I can now connect to wifi at my work! (I wasn't able on friday). It's great to see guix getting better and better so fast
<apteryx>rekado: all of the gcc packages are now hidden, per your commit d78010b81ee6ef4fd8803082e2f401b9e55b44db. Was this intended?
<roptat>I think so, because people kept complaining gcc didin't work, but you actually need gcc-toolchain :)
<roptat>now they can't install gcc, so they won't complain about it :p
<apteryx>rekado: at least, guix install gcc can't find it
<dutchie>(although it complains about locales for some reason)
<roptat>do we have a notion of "optional service extension"? like only extend that service if it exists, otherwise ignore the extension?
<roptat>I'm thinking about fun user services that would go like (service terminal-color-scheme-service-type %guix-terminal-color-scheme) and (optionally) extend every possible terminal config that was declared in the service field for that user
<roptat>like if you have (service xterm-service-type my-xterm-config), you will get an extension for it, but not for xfce4-terminal for instance
<roptat>I don't know if I'm clear and if that makes sense...
<civodul>roptat: it's not possible to do that currently, and that'd need discussion
<davexunit>sometimes I think 'guix environment' should default to what we call --ad-hoc
<str1ngs>is it possible to rename the default profile generation. or to reset the increment atleast?
<g_bor[m]>davexunit: I believe that the guix environment was designed with a different use-case in mind. Now it works like: I would like to develop package x and additionally have y tool at my disposal. I believe that makes sense. Wdyt?
<davexunit>g_bor[m]: it does make sense, but most of the time I specify packages on the command line I want to use --ad-hoc.
<davexunit>otherwise I make a guix.scm file in the root of my project repos and use -l or -m to load an environment based on that.
<davexunit>the one exception being 'guix environment guix' when I want to hack on guix
<g_bor[m]>davexunit: Do you think we could propose an alternative alias instead, that basically does that?
<g_bor[m]>I feel guix environment in its current form is too deeply embedded in the ecosystem already. Wdyt?
<davexunit>if I knew then what I know now I would have designed the interface differently.
<davexunit>I do think that there could be some conventions we could introduce to make certain use-cases easy. for example, I think running 'guix environment' should search for a file that contains all the environment config and do what it says.
<davexunit>so you could clone a git repo and just run 'guix environment' with no arguments and get the environment that the project developers have already configured.
<g_bor[m]>davexunit: it's interesting to see how things evolve. I believe it has an nice inteface :) , but if we could come up with a backwards compatible way, that would be nice.
<bt`>I was just being incompetent yesterday when I thought I corrupted my system, I turned acpi=off for debugging purposes and that broke my system as you'd expect. Oddly after my system initially crashed due to the graphics issue and it rebooted I was able to login using slim and load up emacs-exwm while acpi=off was though.
<tune>can I update just one single package? I keep getting unrelated stuff that needs to be built when doing an update
<tune>and how do I check which package a dependency is from? I can't stop libtorrent-rasterbar from updating by listing it, so I think I have to list what needs it
<tune>similarly I couldn't stop rust from building directly, had to tell icecat not to upgrade
<nckx>What ‘unrelated stuff’ are you talking about, and how are you updating single packages now?
<nckx>‘guix package -u PACKAGE’ won't update unrelated packages, but Guix's notion of related might not match yours.
<nckx>(You can't hold back dependencies, and it might be hard to hold back dependencies of the resulting new profile, I haven't yet tried to do that.)
<dongcarl>rekado: I think your hide gcc commit breaks `cross-base`
<dongcarl>I'm guessing the philosophy of what you're doing means that we'll instead have a procedure `cross-gcc-toolchain` that produces `gcc-toolchain-cross-aarch64-linux-gnu` instead?
<g_bor[m]>It seems to me that in the documentation we have the name of the php-nginx-location procedure wrong. It is correct in the example, but not correct in th headline. How should we correct this? I believe that simply changing the headline in the doc would do, as it would not break existing configs.
<rekado>dongcarl: propeller-gcc uses cross-gcc as well and it is indeed hidden. But propeller-toolchain which uses (and propagates) propeller-gcc is not.
<rekado>in any case, you can unhide the package by overwriting the “properties” field with '() or '((hidden? . #f))
<dongcarl>rekado: Ah okay I see what you're saying
<rubic88>Is there a guix command to export current package installations to a manifest? I'm aware of 'package --list-installed', but I'm looking for something that could be used as input for package installation on another system and put under version control.
<str1ngs>how do I modify the guix-configuration, I need to add additional substitute servers.
<nckx>rubic88: No. Pierre Neidhardt posted a Guile script for that to the list (which list? guix-devel or help-guix) mere days ago but I can't find it ☹
<rubic88>nckx cool, thanks for the confirmation I wasn't overlooking anything.
<bavier>rubic88: no specific command, thought you could use awk/sed to dump package names for inclusion in a 'specification->package' list
<rubic88>bavier: yep, but before I rolled my own (simple) script, just checking that I wasn't overlooking something ... since my guix experience can be measured in minutes ;-)