***marlon__ is now known as Marlin1113
<ArneBab>th-end: could you try to launch it with PYTHONPATH="" gnome-tweak-tool ? <pkill9>th-end: what version of gnome-shell are you using? and what version of gnome-tweak-tool are you using <pkill9>i believe commit d13f3a033e42b4a14d581390b8fa36cd1db7d023 fixes the problem by updating the nome-tweak-tool package (now called gnome-tweaks) to match the version of gnome-shell packaged by guix, i had the same issue of it failing to launch <guix_amateur>Hello, I'm trying to get guix to work on a ThinkPad T400 with libreboot <guix_amateur>It's all good except the audio and the vga output. I don't know where to start. I have been installing al sorts of packages related to audio and video to no avail. <bt`>guix_amateur: are you having colorful static lines when you boot? <guix_amateur>So there is output on the monitor, but not in the vga pins <bt`>ah, I'm trying to run on a librebooted x60s and that's the issue I'm running into, so I was just hoping to find another. <bt`>I'm unlikely to be able to help you but if you described your audio issue a bit more that would likely also be useful to those that can. <guix_amateur>So when I go to Settings-Audio it just has the "Dummy Output" <guix_amateur>The Test of the Speakers doesn't provide any sound output <PotentialUser-68>i'm having trouble installing guix with the script provided in the website ***steve` is now known as sjh223
<guix_amateur>Hi, so I get this error message when booting: ""HDaudioC0D0-unable to bind the codec." <guix_amateur>I was wondering if somebody could advice what to do to get audio working... <guix_amateur>It also says, "pcspkr already registered." I'll leave this open, i'll check it in some 8 hrs. thanks. <boogerlad>does anyone have the guix irc log from 2015-08-17? <boogerlad>The issue I'm having is startx complains about a missing X, since xinit looks for X in its /gnu/store directory <PotentialYouser>is there a particular reason why some versions of packages are maintained in parallel in the guix distribution (e.g. multiple versions of gcc) while some packages only have one version (e.g. apr)? <brendyyn>PotentialYouser: gcc is built from older versions of gcc, core-updates is shifting to a later version already, some packages might require a certain version,... all sorts of reasons i guess <PotentialYouser>brendyyn: so is gcc just a special case, then, or is having multiple available versions of a package in the distribution encouraged? <brendyyn>PotentialYouser: having software that is useful for guix users is encouraged. if multiple versions are useful, then they can exist. <brendyyn>but default one generally just has the latest version <str1ngs>PotentialYouser: it's not just gcc the compiler but also gcc has outputs like libgcc and libstdc++ <another-user>afaik there is no grandle build system so i have to use trivial-build-system but there is not enough information in manual about this system <rekado>another-user: this will be tricky because gradle hasn’t been bootstrapped yet. <another-user>rekado: i think it's okay to use pre-built jar files ditributed by elastic search without building whole thing from source <another-user>but even then i'm not sure how to do it with trivial-build-system <g_bor[m]>istm that the current nginx location confgiuration should also provide a locations part to support nested locations. This could be done using body currently, but it looks like a hack. I believe we have almost everything in place to get this supported. Wdyt? <roptat>another-user, non bootstrapped dependencies are not acceptable as part of guix, unless there's a very good reason for that <roptat>another-user, but maybe you can build elasticsearch without gradle, with the ant-build-system? <roptat>that's how I'm able to build some parts of gradle, that normally require gradle, but I'm stuck at some other parts because they require scala and kotlin which are written in there own language... <roptat>g_bor[m], I didn't receive your summary on content-addressed store, did you send anything? <rekado>another-user: in Guix we generally avoid using pre-built stuff. <another-user>rekado roptat: yeah, i understand that non bootstraped stuff is not a good thing to include in guix for public use but i think that may be fine for private use <rekado>another-user: for Java things this means trying to build the whole thing from source and not to use any jars. <rekado>sure, for your own use you can do whatever you want :) <rekado>the trivial-build-system deserves its name <rekado>you need to provide it with a builder procedure as an argument <rekado>this procedure would then take care of *everything* <another-user>since i don't have enough guix/java knowledge to package it properly <another-user>rekado: yeah, i know that much :) but i'm not sure what builder procedure should contain, like where to put these pre-built jar, etc <another-user>rekado: do you know if there is an example of similar package, i mean the package wich uses pre-built binaries and uses trivial build to package them? <roptat>btw I found a very old version of kotlin I'm almost able to build properly (I think it's only lacking one dependency right now), so maybe I'll be able to bootstrap kotlin <wingo>i am beyond delighted that "guix environment -s aarch64-linux guile" just works <wingo>and it doesn't even have to download too much stuff <wingo>spoke too soon! i think i was missing --ad-hoc gcc-toolchain, and that has to compile gcc :) <str1ngs>can someone using nouveau, start vlc from a terminal. and see if you get this assert error prog_parameter.c:247: _mesa_add_parameter: Assertion `0 < size && size <=4' failed <str1ngs>I'm on guix hash adf577dcc4e5e4a76091fff317ddf3da6ebd1dc6. which should be guix 1.0 .. i think <str1ngs>you will need to play a video aswell <g_bor[m]>roptat: I am building php right now. I saw a commit 13 days ago updating it, but I assume that something else was aslo modified triggering a rebuild. Do you know something about that? <nly>yay, bluetooth audio works! <g_bor[m]>roptat: it checks now. I was just wondering why I was not getting a substitue for that. 13 days seems to be long. <roptat>what would need to be modified to add [step/total] in front of "substituting ...", "building ..." and co? it was suggested on mastodon and it seems like a good idea <roptat>like when you do "guix install foo", it first tells you what it's going to do, so it knows the total number of derivations it needs to build, so it looks feasible <g_bor[m]>on ci.guix.gnu.org we don't have a substitute. <roptat>I can't check, "gateway timeout" <rekado>roptat: the problem is that it *doesn’t* know in advance how many substitutes it will need to fetch. <roptat>what do you mean? isn't there a "n substitutes will be downloaded" "n packages will be built"... before actually building/substituting derivations? <roptat>or, are you talking about something else? <roptat>g_bor[m], I need to find the package that provides "com.google.dart.compiler.backend.js.ast.*" and it doesn't seem to be the dart compiler <rekado>roptat: we don’t know the *total* number of substitutes that will need to be fetched in advance. (That’s because of grafts.) <rekado>maybe I misunderstood the proposal; I’m just saying that the messages about fetching substitutes can’t be aggregated and summarized yet. <roptat>I was trying to find a way to pass a number of steps done and a total number of steps, to messages like "building stuff" "substituting stuff" "building this hook" <roptat>so I don't need the total number of substitutes, I need the total number of substitutes+builds+hooks <roptat>to give a sense of where we are in a process <g_bor[m]>I was running a web search on the first part, without the asterisk. <roptat>ah, it seems I'm missing more dependencies actually... <g_bor[m]>roptat: can I help you some more on this? <roptat>I didn't select the right version of former-dart-ast, I was missing some files that were removed later <g_bor[m]>roptat: thanks very much for working on this <roptat>I think I'm only missing sampullara and jline <roptat>we already have jline, but adding it as a dependency doesn't seem to work... <roptat>ok, 10 more errors due to version updates of dependencies... <rekado>hmm, on the cluster I can use “guix” from a guix pull, but I cannot use “guix-daemon”. <rekado>when “guix-daemon” from the pulled guix is used Guix eventually aborts with an error about being unable to delete some store item. <rekado>I have to keep using the daemon from a git checkout where Guix is configured to use a different localstatedir. <rekado>looks like the “guix-daemon” that’s built with “guix pull” does not work with a custom localstatedir. <archetyp>On ThinkPad T400 with Libreboot, the GDM has problems initializing some external monitors from the ThinkVision series, so you should investigate. <rekado>have you tried investigating this? <rekado>consider sending a bug report with as much details as you can find. We don’t necessarily have the hardware to reproduce your problem. <wingo>building gcc in qemu takes time :P <dutchie>is it just me or did 3bac7e6495934de9913e6186d954d1331883e064 break the build? can't find doc/guix.ru.texi <Guest85934>How would I force a package to be rebuilt so I can see the build log? Running `guix build --check --verbosity=2 alex4` just outputs the package location and "guix build --log-file `guix build alex4`" gives me a log file with a single "grafting ..." line in it. <g_bor[m]>sturm try guix build --check --no-grafts package <Franciman>Hi, I would like to get started with guix, is there any guide you suggest? <g_bor[m]>if you also need the build directory after, then you can add --keep-failed. That is very useful when a test fails, as test logs are usually only avaialble from there. <jonsger>wingo: what do you need to check on aarch64? <rekado>Guest85934: or do “guix build --no-grafts --log-file…” <rekado>you don’t need to rebuild a package just to see the logs. <g_bor[m]>rekado,sturm : opps, yes, if you just need the logs you can do that. <roptat>dutchie, try to run ./bootstrap? <roptat>Franciman, we suggest that you read the installation guide in the manual and ask any question you have here :) <roptat>depending on what you want to install exactly (the OS or the package manager), there is a link to installation instructions on the download page <roptat>(and in that link you can replace 'en' with 'de', 'es', 'fr' or 'zh_CN' if you prefer one of these languages) <g_bor[m]>What is the best way to install a subdirectory of the source into an output? <g_bor[m]>I currently do this with serveral subdirectories of the build directory already, but how can I reference the source? <pkill9>or might need to use (assoc-ref %build-inputs "source") <g_bor[m]>roptat: this way I get the source, but it would be better for me to get the unpacked source directory. Can that be done? <roptat>mh... right after the 'unpack phase then? <g_bor[m]>roptat: after the unpack phase preferably. <roptat>bah, I'm almost done with kotlin, I've passed one more ant target... <g_bor[m]>With you previous solution I could do the unpack and copy myself, but I would rather not duplicate the unpack <roptat>then add a phase after 'unpack and install stuff from that phase? <roptat>like (add-after 'unpack 'install-sources (lambda* (#:key output #:allow-other-key) (copy-recursively "." (assoc-ref outputs "out")))) <g_bor[m]>oh, that's what I did not get :) So after unpack we are still in the source directory... <roptat>after unpack, we are in the unpacked directory <rekado>we should have extended the existing certificate for guix.info instead of generating a new one, I think. <rekado>now we have some duplication in the nginx configuration, but it’s no big deal. <jonsger>rekado: is there a reason why "Recent Activity" is exactly a month to old? <rekado>jonsger: I don’t know why Recent Activity behaves the way it does, honestly <rekado>the only fix is to not rely on Debbugs for search. <rekado>it’s not an insurmountable problem. It just needs a little hacking on mumi and guile-debbugs. <rekado>help would be very welcome as I’m currently unable to commit more time to these projects <g_bor[m]>rekado: I see at the bottom of recent activitise 35303 with #f as a subject. Do you see the same thing? <rekado>yes, it’s probably a bug without any subject. I see that the bug report itself cannot be rendered :-/ <rekado>that’s because mumi/web/view/html.scm assumes that there’s a subject <rekado>the pypi importer seems to be more broken than usual. <puoxond>I have come to believe that there might have been a slight misunderstanding concerning which "guix" I was talking about yesterday. <civodul>so! it looks like we're almost ready for 1.0.1, no? <rekado>civodul: no fix for rust yet :-l/ <civodul>rekado: ah yes, but maybe this will have to wait, then? <civodul>i'd rather have all these installer fixes pushed ASAP <g_bor[m]>civodul: I just did a guix pull, and I assume that the fixes for service not starting on boot should be now on master. Is that correct? <g_bor[m]>openssh and php-fpm did not start for me, but I could start them manually. <rekado>g_bor[m]: erm, sorry, I meant the mumi / issues.guix.gnu.org problem. <g_bor[m]>rekado: ok, I will remove it from my todo :) <g_bor[m]>Any idea how to fix the other one? I believe it's time to add some debug messaging to the shepherd, to see what exactly is happening. Wdyt? <g_bor[m]>The sympthoms are the same in both cases, the process does not get to the state to produce any logging. <rekado>g_bor[m]: are you using the latest shepherd that includes the pid file change? <g_bor[m]>it reports version 0.6.1, so I guess yes. <g_bor[m]>Do you think this might be caused by activations running too slow? <g_bor[m]>One of my projects need php DB. Is there any reason it was not packaged? Am I missing something? <g_bor[m]>roptat: I see on reason now. It's deprecated. <g_bor[m]>But the lastest nominatim release still depends on it <g_bor[m]>I think I could package it, but do not export it. Or do I have to explicitly hide it somehow? <g_bor[m]>oops, there seems to be a new release addressing this. <g_bor[m]>also on start nptd logs to my tty1. Could we somehow avoid that? <g_bor[m]>efraim: it's from ntp-service-type default confgiuration, so I assume ntpd. <g_bor[m]>I there a way to tell sheperd where I would like the service stdout and stderr to get redirected? <wingo>building gcc under qemu has taken 6 hours so far and i have no idea how much longer it might take <jonsger>wingo: I have access to fast aarch64 machines, so if you say what you need, I can maybe help you :) <wingo>jonsger that might be a help! i am working on getting lightening (the jit library that guile uses) working on aarch64 <wingo>when i have a gcc here, it won't be too bad to test lightening itself using qemu <davexunit>have there been any significant performance improvements since guile 2.9.1 pre-release? <wingo>but for testing guile, it could be useful to have a machine <wingo>davexunit: not significant, i don't think <wingo>there are more improvements to make but i have been focussing on simply having jit support <wingo>and not so much on improving things <davexunit>wingo: thanks, just curious. lightening looks really cool. glad you were able to filter down gnu lightning into something that fits guile better. <davexunit>havnig a much better time shoveling floats into the gpu furnace <wingo>good to hear the report :) will get faster when we get register allocation <davexunit>did a benchmark on a thinkpad x1 and was able to render 25000 sprites (rebuilding mesh on CPU each frame) at 60fps. I'm a happy camper. <davexunit>jonsger: not sure on this machine, I should install it and check. <davexunit>the sprites were animated via a simple vector addition each frame, too. and each vertex (4 per sprite) was transformed by a 4x4 matrix on the CPU as well. it's a lot of floating point math! *civodul pushed the 'guix system docker-image' improvements <jayspeer>I'm back with short cables, and it's reading fine :) <jayspeer>sry wrong channels, meant this for #coreboot <jayspeer>hmmm, but I can say that flashrom from guix is working great on beaglebone :) <nckx>jayspeer: Good to hear & useful info about cable length making such a difference! <apteryx>civodul: oh, I definitly want to try these :-) <apteryx>my hacky way was working, even shepherd was exec as a PID different than 1 <apteryx>rekado: I'll try to adjust the upgraded pypi importer commits today <ison[m]>Why does installing rust:cargo need to download (or build) so many different versions of the same package? I just downloaded 8 different versions of rustc and currently stuck building the 9th. <rekado>ison[m]: that’s because the bootstrap chain for Rust is very long and will likely keep on growing. <PotentialUsir>I'm looking into guix manifests, and one issue I've encountered is that while it's possible to construct a guix installation with some set of packages each at a specific version, as time goes on, it seems like one would need to fork or otherwise copy old package definitions in order to actually make the manifest realizable. Is that accurate? <bavier>PotentialUsir: you can use "channels" to specify a package from a particular version of guix "in the past". <bavier>the manual has much more to say about that <bavier>PotentialUsir: np, thanks for asking <civodul>rekado: i just noticed that gcc-objc, gfortran, etc. are now hidden <civodul>i guess we should make them visible again, WDYT? <bavier>who even uses fortran nowadays? ;) <rekado>is it enough to override the properties field for them? <nckx>Related: someone on the ML (I can't find it right away) was looking for libstdc++ (in gcc:lib, which was also affected by the great hiding). <nckx>Or should they be using -toolchain as well? <roptat>g_bor[m], the build went as far as building the compiler and its javadoc, but then it fails to build the standard kotlin library <roptat>bah, there are runtime exceptions and they look hard to solve... I wonder if I should package less recent versions of some dependencies (intellij stuff) <_rad>Hi, having trouble getting guix system to boot ... Grub freezes (countdown stuck at 5) and unresponsive to any key - although Del makes the "Entering setup..." text show up at the bottom (As you would expect when booting the pc - not in grub) <_rad>Anyone seen this before? <_rad>If I boot from another linux distro grub by adding the menuitem, it either hangs on the GNU screen or stops updating the display <str1ngs>also other distro boot with grub efi okay? <str1ngs>and also what vided cards do you have? <_rad>its a AMD GCN v1 (r280x) <_rad>integrated intel disabled for now <str1ngs>try add nomodeset to end of kernel argus. you can edit with e at menu and the C-x to boot <str1ngs>let me know if it freezes before you can edit <_rad>vid card should be supported by amdgpu with the correct kernel flags (amdgpu.si_supported=1) <_rad>ok, will try from the other grub menu ... the installed grub does not allow for any action <str1ngs>_rad: umm that's more then likely the issue scrach nomodset then <str1ngs>_rad: is it possible to use intel instead of amd? just for testing? <str1ngs>wonder if grub is setting the wrong mode or something <_rad>actually booted now with some flags, but always from ubuntu grub <_rad>then I get a bunch of gdm restart spam on the console <str1ngs>but that only works with other distro grub? <_rad>yes, that's an independent issue i guess <str1ngs>yeah, that turns off drm so not useful. but atleast we know it's grpahics related <str1ngs>I think grub is not setting corrent mode <_rad>its strange because i see grub fine, get the gfx and all... it just freezes at that point <civodul>rekado: yes, overridding the property should be enough <civodul>well there could be other properties we'd want to preserve, so alist-delete etc. <vagrantc>anyone happen to know how much disk space it would take to rebuild all of guix 1.0.0 ? <str1ngs>all packages? or you meant just bootstrap maybe base system? <nckx>vagrantc: for everything including all packages: some ~100 GiB? (Big ~ and ?.) <vagrantc>well, starting with the base system, of course, but all the packages in the end <_rad>so how is it possible that "ls" does not work? perhaps i have an incomplete installation? <_rad>whats the package that I'm missing then? <vagrantc>_rad: folks are working on 1.0.1 to fix a bunch of issues <str1ngs>vagrantc: for all packages you are starting to look in the terabyte range. dont' forget sources <vagrantc>str1ngs: ah! that's what i needed to know <nckx>_rad: %base-packages which includes core-updates. <str1ngs>berlin substitute server is like 100s of gigs <str1ngs>vagrantc: I don't know how to estimate this <vagrantc>yes, but it's also rebuilding all the new commits <vagrantc>this would just be a single-pass of 1.0.0 <nckx>str1ngs: That's a pretty big claim to just throw out there… <str1ngs>it's not my claim treat it as hearsay <str1ngs>but yes someone mentions berlin or ci as having 100 of gigs in the store <_rad>nckx: you need all the sources at the same time? makes a big diff too <vagrantc>would like to not throw away the sources <nckx>_rad: You need all the sources if you build all packages from source. <_rad>yes, but you dont build simultaneously, so you dont need them all at once <vagrantc>you can: guix build FOO --root=FOO && guix gc && guix build BAR --root=BAR && guix gc ... <_rad>vagrantc: ok... well i guess you need to know: How much for the sources + how much for the binary + how much for the biggest build environment <vagrantc>i'm looking at doing this on a machine with 800GB free, though it would be best not to limit the use somewhat <vagrantc>er, best to not use all 800GB so that other people can do things with it too *vagrantc ponders "guix size" supporting or adding support for this sort of question <nckx>vagrantc: Yeah, I was just trying to get it to print something interesting on my farm ☺ <nckx>But I don't have an ‘all the things’ GC root… <vagrantc>well, i'll just start experimenting with it... *nckx is running ‘guix build --source $the_world’ out of curiousity… <vagrantc>and so you compare the size of your store before and after? <Krafter>So I have a new computer. I copied the guix system iso file to a USB-stick and booted it up. But when I did I got a "error unknown filesystem" and a grub prompt. <nckx>vagrantc: That's plan B, plan A is using a gc root and making guix size print something useful about it ;-) <Krafter>ls in the prompt gave me a lot of (hd0,msdos0) parts. <nckx>vagrantc: ‘Problem’ here (and reason I get quite annoyed at source==rectum figures) is: even sources can be substituted, so are we counting both the patched tarball *and* the upstream one (which can be thrown away after patching)? Are we counting ungrafted (which are also disposable after grafting) as well as grafted packages? Etc… <bt`>why is building simultaneously default behavior? Is there a performance benefit for sacrificing the resources? <nckx>bt`: Well… yes? Using all cores instead of using one is a pretty huge difference on any ‘modern’ machine. <bt`>isn't that what make -j is for? <vagrantc>nckx: basically, i want to make a rebuild of all of guix 1.0.0 and run all the packages through guix challenge ... i had the impression 1.0.0 should be kept on the substitute servers <nckx>vagrantc: I disable grafts on my substitute server because it's faster locally and saves many gigs, but it might be considered cheating in your benchmark. <vagrantc>nckx: and just want to know how much space that will take so i don't overly impact the neighbors on the same machine <vagrantc>nckx: i thought grafts are used to cheat builds? <vagrantc>e.g. use this input and pretend it's this other input, really, it's fine <nckx>bt`: -j sometimes runs a few things in parallel. Doing it at the package level makes a big difference in real-world core usage. <bt`>ah, that makes sense, thank you. <nckx>vagrantc: Well, it's not pretending. And I don't think it's cheating (if builds are reproducible, they should only differ in the way that grafts differ, more or less); what I mean is my build farm uses spinning discs and my PCs all have SSDs, so using up many gigs of farmland (and time and disc wear) to save a few seconds of local copying wasn't worth it—to me. <nckx>This isn't a general-purpose public service like berlin tho'. <nckx>It's creative accounting is what it is. <vagrantc>not real familiar with how grafts are implemented <nckx>vagrantc: Literal string replacement. <vagrantc>well, i guess one could do one pass without grafts and one pass with grafts *nckx is running the experiment on a slow VM with a phat pipe… but now it's building Python :-/ <Krafter>The "USB stick installation" seems a bit brief. Is it all there is to it? <nckx>Krafter: Depends on what you mean. That section will give you a bootable USB drive with the Guix installer on it, and ends when you boot that. <manzerbredes>hi! I'm trying to use the trivial-build-system of guix and I wanted to know how can I have access to make in my derivation ? <Krafter>nckx: Yeah, but what surprises me is when I boot it up I get a grub error and from what I can read from it there are multiple "msdos" partitions. <nckx>Krafter: The ISO has 4 partitions (the should be GPT, but maybe GRUB is confused/degraded). <nckx>But the mere fact that there are msdos (or other) partitions on an ‘ISO’ is not a bug here, no. <Krafter>nckx: When I insert the USB on this PC I only see a single partition in the /dev/ dir. <nckx>Krafter: I don't have a USB drive handy, no idea if that ‘interesting’ or not. What does sfdisk -f /dev/foo say? <nckx>(There's a pastebin in the channel topic if you need one.) *nckx is working from the ISO image file and there it shows 4 GPT partitions. <mfg>is it possible to use a UUID in the bootloader configuration target property ? <mfg>because my main hdd is not always /dev/sda <nckx>Krafter: Oh no. That is not korrect. <nckx>Krafter: Are you sure you did ‘of=/dev/sde’ while dd'ing? Could you try dd'ing again, paste the command here, and immediately run sfdisk -l again? <Krafter>I realize now I might have copied it to a partition on the stick instead. <nckx>Ah, yay, I'm a moron. Try sfdisk -l instead of -f because I can't type. <Krafter>nckx: Its output is very similar to the one I posted above. <nckx>Damn, I hoped it was me. <nckx>Anyway, let's try dd … of=/dev/sde. <nckx>(This is assuming you followed the other steps to authenticate the downloaded image and it's not corrupt.) <Krafter>nckx: I have actually never checked a linux install image against a signature. Is that a bad habit? <Krafter>It gives me a 404 when I try to open it with a browser anyway. <nckx>Krafter: Well, it's in the exact manual section you found suspiciously short :p <nckx>Krafter: Not sure what ‘It’ is in your second message. <nckx>You shouldn't need to open anything in a browser. <nckx>Do note that you need to replace ‘system’ with the name of your system, maybe that's what you ran into. <nckx>In which case you silently wrote a 404 page to your USB drive. <Krafter>I am not writing the sig file to the USB drive. <nckx>No, but you might've downloaded guix-system-install-1.0.0.system.iso.xz too, but I guess that wouldn't have decompressed. <Krafter>Anyway I had already deleted the .xz file before checking and no iso.sig file seem to be available. <nckx>In any case, I suggest you follow that section to the letter. It's a bit weird to ask ‘is that really all there is to it’ if you skipped half of what's left. <nckx>DIY shelves wait for no man. <rekado>str1ngs: I can tell you first hand that the store on berlin/ci is 27TB right now, but this doesn’t really mean anything. <rekado>a lot of that is hundreds of 2GB qemu images <mfg>rekado: what are those for? <rekado>it’s also lots of old stuff because we don’t collect garbage — that’s why we have so much storage in the first place. <rekado>manzerbredes: the trivial-build-system doesn’t do anything; it doesn’t even set up the PATH for you. <rekado>I suggest modifying some other build system (e.g. gnu-build-system) <manzerbredes>rekado: ok thank! I finally manage to add make (using gnu-make module) <bt`>I've still not resolved my graphics issue, but I did discover that running Vesa actually does give a slightly more interesting error log https://arborescent.tk/Xorg.new.txt I asked #libreboot and other than confirming that it wasn't a hardware error they didn't have any new information for me. I still haven't gotten around to asking #xorg mostly because I've been busy with university work but hopefully I'll have time this weekend to do <metallisto>Hi, I'm new to guix. It's impressive.. But now I'm stuck with the installtaion process of rust. After a lot of hours compilation time I got an error while compiling rust-1.28.0. I then decided to install the already finished version rust@1.27.2. After a next try I found the machine in grub when I came back. Maybe it was a kernel panic. I decided to run the guix gc and had to realize that I just throu away the whole bootst <metallisto>ring if it is possible to use the already installed rust@1.27.2 to continue the bootstrap without compiling everything from the beginning. <amz3>metallisto: did you guix pull ? <amz3>sorry, I misunderstood your question. <jumblemuddle>I can't get `--on-error=debug` to do anything other than print the backtrace either. <civodul>jumblemuddle: it seems that config.scm does not return an <operating-system> record <civodul>perhaps you wrote (define my-os (operating-system ...)) ? <jumblemuddle>Ah, I've got some other defines below that. I didn't realize the `.scm` file returned the value of the final declaration. <jumblemuddle>Just a thought; how difficult would to be to give a proper error message for this error? ('config.scm doesn't return correct type of operating-system') <jumblemuddle>Or at least a more readable error for a noob like me. ;) <civodul>jumblemuddle: i'm looking into it :-) *rekado is overwhelmed by the flurry of activity on the mailing lists <civodul>yeah i was browsing help-guix and i'm like, woow <civodul>but that's ok because people usually respond :-)