IRC channel logs
2023-02-16.log
back to list of logs
<rekado>there’s /run/current-system/channels.scm <rekado>(“guix system describe -f” doesn’t exist, sadly) <graywolf>Oh, I've meant guix describe -f channels. I assume /run/current-system/channels.scm describe what the *system* (... reconfigure) was ran with. <rekado>yes, that channels file tells you what Guix channels were used to build this system <graywolf>Great, I think I understand it enough for now. Thank you for the information :) Guix and guile both seems to have really great community <apoorv569[m]>I have a created a directory under ~/.config/guix/ named systems and have 2 files in that directory, base.scm and system.scm <apoorv569[m]>now when I run the command, sudo -E guix system -L ~/.config/guix ~/.config/guix/systems/system.scm <apoorv569[m]>I get bunch of warnings no errors though.. and the command finishes but nothing happens no new generation is created. <apoorv569[m]>I have ran `guix pull && hash guix` many times but no luck <wdkrnls>Where are you looking for that new generation? <wdkrnls>The file you showed suggests that you had forgotten to load a module into your configuration source. <wdkrnls>I saw I would look with `$ guix system list-generations'. <wdkrnls>I just thought it was possible that maybe you were confused about the difference between your profile and the system profile and I could be of some limited assistance. <wdkrnls>However, probably I am the one who is confused about guix system related things. <apoorv569[m]><wdkrnls> "Where are you looking for that..." <- I used `guix system list-generation` command to see list of generations <apoorv569[m]>BTW the system.scm file has an operating-system definition which inherits from base-operating-system defined in base.scm file <apoorv569[m]>so I wanna have like per system configurations and a base system configuration <apoorv569[m]><wdkrnls> "The file you showed suggests..." <- Yes.. it uses I am missing (gnu channels) module because of the variable `channel` being used .. <apoorv569[m]>but I am not using channel anywhere either base.scm or system.scm <wdkrnls>Sometimes dependencies can be tricky. It is preferable to bring in too many dependencies than too few. <wdkrnls>However, it sounds like that is not your main issue. <wdkrnls>Can you point me to the manual where you learned you can use ~/.config/guix as a folder this with `guix system'? <wdkrnls>My understanding is that folder is reserved for your user profile. <wdkrnls>That said, I cannot say I have the best setup. I just sudo rsync my config.scm and supporting files to /etc whenever I update it. <wdkrnls>I think you should just have one config file which serves as a point of entry. <wdkrnls>I would imagine it would be your more specialized file which you would modify to be sourced when loading your specific features. <apoorv569[m]>I think its not supposed to be like that I mean files under ~/.config/guix <apoorv569[m]>but I use -L flag to specify load path so it can read my custom defined module that is in base.scm file <wdkrnls>I like the general idea of abstracting out shared functionality for managing multiple computers. <wdkrnls>I haven't done it before, but I think my point of entry would be config.scm and it would just be generalized with procedure calls which tested what system was running and returned the apropriate configurations based on that test. <wdkrnls>I like this `guix system playground' topic in the manual. <wdkrnls>If I had a faster computer with a properly functioning hard drive, I would love to try it out and experiment. <wdkrnls>If you haven't done that, maybe have a look. <apoorv569[m]>As I am not very familiar with Guile and Lisp in general. <apoorv569[m]>I have been fixing my config since last weekend finally got to a state when it starts but throws bunch of warnings <wdkrnls>I don't know if Guix stops giving warnings :p <wdkrnls>Honestly, I have never had a Linux system that didn't give atleast a few. <apoorv569[m]>Yea but in my case the warnings are about it not able to find some modules but not related to my configs <apoorv569[m]>which is why probably it doesn't generate any new generations <wdkrnls>Well, that makes sense if those warnings are actually errors. <wdkrnls>It sounds like perhaps you might want to consider temporarily reducing your scope. <wdkrnls>Try to make a simpler system which works. <wdkrnls>Then, when you understand how to do that you can start increasing complexity from a basis of a bit more understanding. <apteryx>guix build -S icecat downloads at 100 kB/s <apteryx>do we still have that weird situation where NARs being baked are streamed at the same time at low speed? <apoorv569[m]>My config is already very basic. I am not configuring much. <wdkrnls>For some reason I recall that all this sudo -E stuff was considered bad practice. <wdkrnls>I would also make sure you were just pointing at one file. <apoorv569[m]>Yes but without -E it use the file in /etc/ or use the root users home directory instead. <apoorv569[m]>Yea I have tried that, I removed base.scm from the scene and only use system.scm file still get those same warnings. <wdkrnls>Does /etc/config.scm work without error? <wdkrnls>Why do you need to be running system level configuration as your user? <apoorv569[m]>Yes the /etc/config.scm works.. because it is installer generated. <apoorv569[m]>I am not running system level configs as my user.. sudo -E uses my users environment as in files and channels list and env vars from user but being a command ran with sudo it changes the system <apoorv569[m]>you can put channel.scm file in ~/.config/guix and do guix pull without sudo <wdkrnls>That is what I am scared of. I use Guix predominantly to avoid all this crazy mixing of environment variables which happens on other operating systems. <wdkrnls>It is just too hard to understand. Guix helps me isolate things. <wdkrnls>I suggest trying to use that strength to your advantaged. <wdkrnls>I thought you could also place your channels it etc as well? <apoorv569[m]>Anyways I just started learning about Guix and I am not much of a expert in this case. <wdkrnls>The problem with Guix is that because it started out as a package manager, the manual sometimes neglects to mention the corresponding operating system-relevant approach. <wdkrnls>But I do sometimes think about how to fix things as a general skill. <wdkrnls>If what you are doing doesn't help, then continuing to do it will be a waste of time. <wdkrnls>Usually it's more productive to solve simpler problems. <wdkrnls>Don't go out of your way to make your life difficult when you are just getting started. <wdkrnls>When you get frustrated, watch one of Protesilaos's videos on philosophy. <wdkrnls>Take a break. Come at it fresh later. <apoorv569[m]>I think the opposite I force myself to learn something by doing difficult things its slow but I enjoy it. <apoorv569[m]>If I get frustrated the frustration usually lasts for minutes if not hours at max. <wdkrnls>If you are interested and are enjoying what you are doing, then it's great! <apoorv569[m]>I have already been working on my config since weekend as I mentioned before and got to this state.. where at least the system reconfigure command runs and does something.. <apoorv569[m]>I probably will figure this out someday.. Thanks for advice. <wdkrnls>Just keep in mind that setting up the computer shouldn't be the hard part. <apoorv569[m]>I mean it is "hard" ATM for me because of low understand of Lisp language but not hard as in process .. I hope it makes sense. <apoorv569[m]>I always wanted to learn a lisp dialect.. Using Guix gave me that opportunity. <jonscoresby>What is the timeline for patches to be reviewed and merged? <apteryx>if it shows green in the QA and followed the conventions outlined in the Contributing section of the manual, it can be rather expeditive. But it remains subject to the availability/interest of the reviewers/committers, which are all volunteers. <apoorv569[m]>I got the config working... there were some errors in the config.. <jpoiret>apoorv569[m]: formatting the swap space is your responsibility <jpoiret>if you want to use a swapfile, you have to create it yourself <apoorv569[m]>same applies to the partitions right? I just tell which device to use? <apoorv569[m]>But I formatted a drive as ext4 but declare the device to be a btrfs instead would it throw an error? <cbaines>janneke, I spotted that too, I'll tweak the default timeouts and rerun the job shortly <efraim>I'm still at gcc-mesboot1 and binutils-mesboot1 but I only started the build recently <efraim>I'm also working on openbios-qemu-ppc. I got it upgraded (from 2013) but it still needs gcc-10 to build <efraim>janneke: yes. but I mean its currently building, not that it's stuck <efraim>unless you're asking about openbios-qemu-ppc, that's giving me trouble <efraim>and I've built to hello on riscv64-linux. now building to mesa before stopping to see what other changes mean a rebuild on the slower architectures <jpoiret>apoorv569[m]: I'm not sure, I think so <andreas-e>janneke: gcc-core-mesboot0 was available on berlin last night, and I am bootstrapping on x86_64 now. I am at grep-mesboot. <andreas-e>aarch64 is finished already, but I think it bootstraps less. <janneke>andreas-e: great, yeah the wip-arm/aarch64-bootstrap branches are stuck on the first full gcc+glibc <janneke>we'll prolly postpone mes-based bootstrapping for arm until we have tcc->gcc4 in place <mekeor[m]>for which programming languages does guix represent a good developer tool? e.g. for rust, it's not. but i guess, it is for guile, c and python? what else? <drakonis>mekeor[m]: it might not be for rust right now, but it can be in the future <jpoiret>most languages which don't heavily rely on their own homegrown package manager <mekeor[m]>drakonis: i know but i'm interested in the present time :) <pkal>jpoiret: doesn't python rely pretty heavily on pip? <pkal>then again I recall that package management with python is a mess, isn't it? <jpoiret>it does, but since it's an interpreted language we can still manage <jpoiret>for compiled languages that need their own build tool and package manager it's more of a nightmare <pkal>what does that have to do with being interpreted or compiled? <jpoiret>the problem is often that the custom build tool for compiled languages operates on a set of assumptions that are broken by Guix, or that are very hard to uphold without sacrificing the Guix model <jpoiret>for interpreted languages you don't have those build tools when you're actively writing code <jpoiret>that might be an oversimplification, but I guess that's how I could explain why Python still works well on Guix <dlowe>I'm trying to fix tcl's search-path definition and I'm pretty sure I have it where it'd work but I can't figure out how to test this in isolation. <jpoiret>it only needs to know where the .py files are, not compile crates that live in some cache directory into some other binary artifact directory that only the build tool understands <pkal>that was my question: What are the assumptions that are broken by Guix? <jpoiret>for rust: distro-provided crates in specific directories rather than a global mutable cache <jpoiret>for go as well, those languages really want to be the sole tools that can provide and access dependencies <mirai>is the naming of guix service symbols such as 'networking 'user-homes 'user-processes 'file-systems deliberate or was it just author's preference? <lechner>mirai / Hi, do your NFS clients shut down properly? (I have had that issue even before I started using your delayed networking trick.) <mirai>lechner: what do you mean by shutting down properly? <pkal>mirai: ok, but a language like C shouldn't be affected by this? <lechner>mirai / i have to unmount manually before a shutdown succeeds <mirai>hmmm... Did the system just never power-off? <mirai>I've noticed this too, often reboots or shutdowns either took too long or never powered-off <mirai>had to physically hit the power button <mirai>you could add a stop method that unmounts the NFS clients <mirai>I'll give it a test in a bit <lechner>mirai / same issue here. it's not a big deal, but understand services a lot better than i <apteryx>mirai: I also have this kind of problems on some machines <apteryx>I never linked the two issues, that's interesting <apteryx>we do not have suppor to mount them automatically :-) <mirai>I never thought they'd be linked <apteryx>do we have a report of that on the bug tracker already? <apteryx>no, I meant the bug where nfs mounts cause the system to hang on shutdown <mirai>I'm wondering if this bug happens with *ANY* manual mount <lechner>i think networking goes down before the mount is released, which then blocks <mirai>wonder how shepherd determines the order for the stop constructors <mirai>it'd be good to know where or what exactly goes wrong here <mirai>for manual mounts, who or what is responsible for unmounting them? <mirai>and what parameters does it take <mirai>or shepherd choking up on some target <bjc>shepherd doesn't define a stop order on services, except that dependent services are stopped before the service they depend on <bjc>right, but the order of independent nodes being stopped is unspecified <bjc>(the running services list is a hash table) <mfg[m]>I noticed some strange behaviour when compiling c++ programs on guix. I'm getting extremely obscure errors from deep within the std libs, that really don't make any sense to me. <mfg[m]>My guess is this si due to the fact that gcc-toolchain is not in sync with the actual toolchain used to build c++ programs by guix itself. So gcc-toolchain is 12 and guix uses 10. <mfg[m]>Can the default gcc-toolchain version be kept in sync with what guix actually uses? <janneke>mfg[m]: the errors do not occur when using `guix shell gcc-toolchain@10'? <mfg[m]>I mean sure, i can just manually specify the correct toolchain version, but i always forget see some weird error and think: ah, yeah i forgot something... <janneke>it seems to me like a fair request then, but it may mean having an older default compiler most of the time <janneke>mfg[m]: if you can create a bug report, eg a simple c++ program that does not build using the default gcc-toolchain, that would be nice i guess <mfg[m]>Yeah, that's true. Though i don't know if/how bad this is <janneke>i guess that people working on a c++ project use a guix.scm or manifest.scm file in their project <janneke>so that `guix shell' will do the right thing <mfg[m]>that is the ideal situation, true <mfg[m]>janneke: i can't find such program right now. Next time i see it i'll write directly to the bug list. Maybe it's my fault and the older gcc-toolchain works out of pure luck. <nckx>Morning, Guix (mutant and otherwise)! <nckx>mfg[m]: Package ‘specs’ (as used by the CLI) always default to the highest matching version, so we can't return a lower ‘default’ version without making things confusing & messy. But you could do so under a different name? ‘guix-build-system-gcc-toolchain’; name to be bikeshed at will :) <mfg[m]>nckx: thanks for the explanation and suggestion :) <unmatched-paren>ACTION sent v6 of dissecting guix part 2, hopefully to be the last :) <lechner>Hi, does 'deploy' restart any services? <apteryx>mirai: I get an interesting (because of new) reconfigure error: "error: invalid value null for field 'mixer-type'" <apteryx>was my configuration previously silently broken or is the API break unintentional? <apteryx>the doc still mentions "code{null}", so I guess it's unintentional :-) <dlowe>is there a way, given a package name, to get the location of the source download? <andreas-e>Not directly, I think. I usually do "guix edit NAME" and look at the source field. <dlowe>unmatched-paren: perfect, thanks! <andreas-e>That gives you the source, but not where it is from. guix build --no-substitute -S NAME should work. <unmatched-paren>ACTION just realised guile's and=> is a bit like >>= for possibly-false values :) <dlowe>I already got what I wanted lol <dlowe>Sorry, I meant the location in the store <dlowe>not the location object in the package definition <andreas-e>Good, then now we have two different answers to two different questions :) <dlowe>If I run guix shell in my dev guix directory, it tries to load guix.scm and then dies with a "Throw to key match-error <mirai>right, the original mpd service used record-type which didn't care about the type <nckx>dlowe: Guix's ‘guix.scm’ does not define a package for ‘guix shell’. It's an unrelated (and much older) file with the same name. <mirai>and the documentation did talk about it being a symbol but this was changed into string since pretty much the entire configuration uses strings except for that odd field <dlowe>Yah, I only want to test out one package file I was just confused by the default behavior <nckx>dlowe: Hacky work-around: GUIX_PACKAGE_PATH=$PWD guix shell -De '(@ (gnu packages package-management) guix)' <dlowe>though I have guix shell --check --development -f code/guix/gnu/packages/tcl.scm and it's erroring out the same way <nckx>tcl.scm also does not evaluate to a package. <nckx>I don't think any files in Guix do. <nckx>That's what my snippet does: set the load path to the current directory (assuming you're in code/guix), then extract the guix package from package-management.scm. <dlowe>sorry, what work is @ doing here <apteryx>I sometimes get "In procedure mkstemp: Permission denied" in Geiser; any remedy? I think I must have changed my /tmp permissions by mistake? <nckx>dlowe: It's not as scary as it looks. (@ (some module) foo) simply means ‘the exported variable foo from (some module)’. It's a self-contained way of writing ‘(use-modules (some-module)) foo’ without actually importing the entire module into scope. <dlowe>well, it dies with symlink-spec-option-parser: unbound variable <dlowe>at guix/scripts/environment.scm:265:40 <dlowe>it's a weird place to choke at <nckx>It's the old name of ‘guix shell’, and it's loaded using an autoload (shudder), but I don't have a hypothesis for why it worked for me & not for you… <nckx>My ‘guix’ command is relatively up-to-date compared to my checkout. If yours are further apart, I guess there could be some incompatibility, but it's no more than a guess. <isf>guix are distribute nonfree software in their repositories <isf>I find a nonfree program who broke the freedom 0 <apteryx>OK, the fix to my Geiser woes was: sudo chown -R maxim:users /home/maxim/.cache/guile/ccache; I had run 'sudo -E ./pre-inst-env guix system reconfigure' earlier <nckx>dlowe: But really, this was all a bit of a ‘this is how you *could* emulate a guix.scm’ tangent :) I myself would, like unmatched-paren, simply use ‘guix shell [-D] PACKAGE-NAME’ directly, where the package might be ‘guix’. <nckx>bug-guix at gnu dot org. <isf>but I wait you do it apteryx if you value your freedom <apteryx>I do, but if you don't even name the package, I can't do much <isf>here are sufficient people to do it for your user freedom <apteryx>OK; which part of is is nonfree? or is it wholly nonfree? <isf>that program is against the freedom 0: <isf>The freedom to run the program as you wish, for any purpose (freedom 0). <isf>because restrict the commercial use, making a restriction to run the program for any purpose. <isf>thats the reason must be removed. <apteryx>I see; that's written in its license file? or where? <dlowe>nckx: I'm trying to fix search-paths and it's really hard to test this. <dlowe>I might start a VM with a clean guix and a channel <isf>here the license with restriction of freedom 0 to restrict commercial use <mirai>nmap is dual licensed GPL and their new non-free <nckx>isf: No, which part of the licence. <mirai>if I am reading it correctly <nckx>I'm aware of certain (much more subtle) concerns with nmap, including 7.92 IIRC, but ‘non-commercial’ was never one of them. <nckx>Unless you can provide more information I'm disinclined to consider it plausible. <isf>if you dont like read <isf>good luck, and try to do a effort. <nckx>This is what isf does. Low-effort, high-ragequit rants. <mirai>ah, so this isn't the first time <mirai>but I suspect the annotated link has changed <mirai>because Ctrl-f for appliance doesn't yield that sentence <nckx>No, it's a very old discussion [I did not mean that the discussion itself was invalid! Only this parody of it] and nmap has been dragging their feet on clarifying matters, possibly for reasons beyond their control. <mirai>I wonder if this whole thing could have been avoided if they went dual AGPL + __INSERT_CUSTOM_LICENSE_HERE__ <nckx>s/dual.*/AGPL/ but also maybe yes. <nckx>The original was simply too poorly written to be GPL-compatible, so it was always a recipe for noise. <mirai>(maybe selling support instead?) <nckx>Oh, sure. My sed was merely a flippant protest against licence proliferation, nothing deeper. <nckx>ACTION tries to update nmap, let's turn this into something constructive… <mirai>if only spdx+reuse were widely used <mirai>actually, that's weakly related <mirai>reuse for guix import would be interesting <mirai>for packages that happen to use 'REUSE, <mirai>' spec that'd allow an easy license "linting" <nckx>Do many? I think Guix was one of the first distroes to package REUSE, but I haven't followed it since. <nckx>(The FSFE sent out a polite mail asking for packaging, and it sounded like a cool idea at the time.) <mirai>I see SPDX getting some traction <nckx>I don't know the list of restart/don't restart services by heart. <mirai>I dont think nginx is auto restarted <mirai>I have to manually restart them here <lechner>hey, you folks ever wish you could easily find files in Guix? <lechner>i thought this was on everyone's list <jackhill>has anyone run guix-daemon in kuberneties/as a non-root user <mirai>find /gnu/store -type f -iname '......' <lechner>right now, it only has the contents of my store, but i am happy to add others <mirai>ah, I was just about to point out a missing item <mirai>lechner: it'd be useful if it's a feature that is directly integrated in guix <mirai>say, guix whatprovides 'QUERY STRING HERE' <mirai>you can make custom guix commands, though this is undocumented <lechner>the issue is that no one has all the data <surpador>Wasn't there some previous work on a `guix index' command which aimed to implement this? Is there a repo for that somewhere? <mirai>and being on substitutes this means that at least the package could be built by someone <surpador>lechner: juix.org seems pretty helpful, thanks <mirai>no value in knowing that 'fantastic-but-unbuildable-package' provides '%/bin/cure-for-cancer' or '%/bin/undo-pandora-box' <lechner>surpador / i am looking for folks willing to run the client locally. (one-off for now.) it collects limited information about the folders in your /gnu/store such as relative paths, file types, permissions as well as input and output hashes <mirai>lechner: why not ask $guix_member_who_manages_substitute_server <lechner>but no hashes for individual files, in order to maintain some level of privacy and plausible deniability <lechner>mirai / i may, but they seem pretty busy. i also do not have a nar importer yet <mirai>that approach is sure to yield garbage data <mirai>nothing stops me from creating garbage packages that claim to provide all sorts of things <mirai>they don't necessarily need to be packages, all I need is to pollute my store with trash <lechner>that's something for the core devs to decide. i believe that our directory naming scheme in the store could be improved, but for the time being i have more than enough disk space <mirai>you could think on quorum-like countermeasures but they're also defeatable and highly complex <mirai>at the end, you need to trust whoever provides the substitutes (or store) <lechner>sure. by the way, that argument has often been used against Debbugs but to my knowledge no one has tried to mass-close all our bugs <surpador>As long as you still only use trusted substitute servers, that doesn't seem like too much of a problem, right? The index might simply misead you, but you'd be no worse off than you were before it seems <mirai>I think this is up to the project/ML manager to decide on the available permissions <surpador>lechner: at the moment I only use a laptop, so not sure how useful it would be to run on my computer <mirai>but debbugs you have a "reputation" filter <mirai>not exactly, but every account is manually approved <mirai>so malicious clowns would have to send meaningful mail at least once <mirai>aka "attacks cost something here" <mirai>with your indexer, unless you have some kind of veto-ing of the users, the attacks are __free__ <lechner>i'd rather get more data. my own setups are very different from what you all are using. which file was missing for you <mirai>surpador: sure, but that's like a phonebook with fictional (and forged) entries mixed in. <mirai>lechner: I tested with xpath <lechner>i also wouldn't mind getting some input from my alter ego, nckx <nckx>ACTION has been following the convo one whit, instead getting frustrated & stonewalled in #gnu. <nckx>*has not, quite the diff. <lechner>what is your request there, if you do not mind? <mirai>I simply punched in '%/xpath' <lechner>i know. i meant nckx. just trying to make him feel better, but he may not need it <lechner>mirai / for example, you can see that i have gocryptfs <lechner>mirai / another reason for including data from individual stores is that i offer pointers about reproducibility and deduplication potential <apteryx>are polkit rules "hot-reloadable" on Guix System? <nckx>lechner: More that it won't help, I'll never feel better, but your effort is kind and appreciated. <mitchell>Hello guix, I am trying to build linux-libre with different source but the configuration phase keeps failing saying `include/linux` has conflicting types to glibc. How can I get it to use a toolchain using the headers from my sources? <apteryx>which version of gtk provides webkit2gtk-4.1? <lechner>you can also type %webkit2gtk-4.1% into juix.com <apteryx>haha. is this another one of your creations? <akm>hi -- I'm having trouble getting guix to boot. is this the right place to ask for help? <akm>OK -- I installed Guix system on an intel NUC, and had it working for a while. I put it away for a few months and came back, and now it crashes when it boots. <lechner>apteryx / my own store for now, and yours if you want <lechner>akm / did you reconfigure in the meantime? <akm>The last thing I see is "kernel reports TIME_ERROR: 0x41: Clock Unsynchronized", then it shuts down. <akm>I don't think so -- I tried loading a previous configuration that had worked before and it still didn't boot <akm>oh, a new battery -- how is that? <akm>The intel NUC model is NUC10FNH <jpoiret>lechner: what is the Wasteful column? <lechner>jpoiret / right now, fewer output hashes (guix hash on the folder) than derivations, but the algorithm will be refined shortly <mirai>akm: that message might be a red herring <mirai>I've seen that before and nothing extraordinary happened <nckx>It is almost certainly irrelevant to any crash you're seeing. Is there nothing more? <akm>I have a screenshot I can post -- is there a way to do that here? <nckx>It's just saying you're clock isn't marked as synchronised (NTP etc.). <jpoiret>i don't really get it, derivations of what? what is it supposed to represent? <lechner>jpoiret / i would prefer a more muted term, if you know one (but it also has to be short). it means deduplication candidate, even if we have no such efforts to date <mirai>it's not the exact same model but I've got a BXNUC10i5FNK4 <nckx>akm: There are image pastebins, but I don't know one to recommend. <mirai>and I haven't noticed anything strange <jpoiret>ah, you mean that the file is likely produced by another derivation? <jpoiret>you'll probably get a lot of files like this because of grafts <mirai>akm: did you try booting 2 generations before? <lechner>jpoiret / it means that two or more derivations produced the same output <lechner>jpoiret / it's not based on files but on folders in /gnu/store. i used no file-level hashes (for privacy) <jpoiret>ah, right. Still gotta track if those derivations come from the same guix version, but that's a nice idea <lechner>akm / i think those messages are unrelated to your crash <nckx>akm: OK, so none of that looks directly relevant (although the hint that gdm is started is interesting, since that doesn't look like GDM!). Most people would not call this a ‘crash’ which doesn't help confusion. Can you switch consoles with C-M-F2, for example? <nckx>akm: So this system has not been changed in any way since it was last sucessfully used? <akm>Not in any way I can remember. <lechner>jpoiret / that's the part that will be refined shortly <akm>Though I just tried booting in the first generation, and saw some extra messages -- I will post a couple more screenshots soon. <nckx>akm: Assuming these things have a BIOS/firmware menu, can you set the time? <nckx>Like, this shouldn't matter, but… <nckx>(…but I'm out of more useful ideas TBH and GDM has always been a black box that outputs arbitrary errors in my mind.) <akm>I tried setting the time through the BIOS, but it didn't change anything. <jpoiret>so, does the computer hang or actually power down? <nckx>C-M-F2 means Ctrl+Alt+F2, sorry if that was unclear. <nckx>It's an emacs affliction. <akm>The computer powers down. How do I switch ttys -- when do I press CTRL + Alt + F2? The only times I can type are when I'm entering passwords for things. <nckx>Well, you'd press it when you see the screen you shot above, ideally. Any time after seeing ‘This is the GNU system. Welcome!’ has been printed. <akm>First I get "Welcome to Grub!" and enter passphrases to decrypt my hard drive. Then I put in some more passwords after that. <nckx>But if it powers off I can see how that could be a problem. <akm>Oh, when I see "This is the GNU system. Welcome!" I don't get to type anything, it just continues on to power off. <mitchell>Does it ever power off if you just hang out in the BIOS? <lechner>do you disconnect power when booting after you modified the BIOS? <akm>I have disconnected the power after modifying the BIOS and the computer shutting down, but I haven't modified the BIOS recently. <mirai>and by poweroff does the machine really power-off? or does the monitor go poof into sleep mode <nckx>akm: You probably would have mentioned it, but is anything printed after the ‘New session’ at the bottom? <mirai>the nucs don't make much noise but it should still be discernible if its powered or not <mirai>is the power button led lit up? <lechner>ACTION has only seen computers power off by themselves when the fan was full of lint <akm>I'm gonna post a screenshot with more information, loading from the first generation, one sec. <mirai>this kind of "This is the GNU system. Welcome!" reeks of KMS failure <nckx>Hey, it's my login screen! <mirai>I've seen it happen with NV cards that are too recent for a kernel <jpoiret>why KMS failure? I used to see that all the time until GDM started <nckx>…but yes, I am also suspecting the modesetter but *why the hell suddenly after months*? Some timing quirk? <nckx>jpoiret: That it remains after gdm is ‘started’. <mirai>as soon it hits the graphical login the monitor would go into 'sleep mode' as if the machine powered-off <mirai>nckx: faulty operator memory? mistakes can happen <akm>I get a lot of "Missing Free firmware" messages too. (And what is KMS failure?) <nckx>I feel lazy, but that's my main theory. <nckx>To expand lechner's hint: you can press ‘e’ on a menu entry in GRUB and edit the ‘linux’ line to add ‘ nomodeset’ at the end, then hit C-x to boot. <nckx>It's fishy that you never needed this but if there was a forgotten upgrade (maybe you reconfigured, then powered off, then put it away?) it might be less mysterious. <jpoiret>if that doesn't work you might have to get a live USB and fetch the /var/log/{messages,debug,gdm} <nckx>akm: Kernel Mode Setting just means setting the screen resolution (mode). <nckx>It can fail on some cards due to missing freedom. <lechner>i would also blow any dust out and check the capacitors <nckx>If they taste salty, replace them. <nckx>I mean, I had as fun a childhood as anyone, and might have, accidentally, once, but anyway. <mirai>the missing firmware isn't too important I think <mirai>the NUC should work without it <nckx>If 0000:00:02 is your GPU, it might be relevant. The rest is wi-fi. <lechner>that looks completely normal to me. maybe you have a broken temperature sensor <jpoiret>you don't have a graphics card on that right? <akm>No, I don't think so (having a graphics card). <mirai>Are you using Thunderbolt and an eGPU <jpoiret>that's why I don't like having GDM as default, can't debug GDM problems <lechner>do we have a shortcut to a shell anywhere, for init=/bin/sh? <akm>I don't think it's going to sleep, because when I restart, I go back to "Welcome to Grub!" and have to enter my passphrase to decrypt my hard drive. <nckx>akm: Does this last screen let you log in? <akm>No, that last screen just proceeds automatically -- I can't type anything to login. <nckx>ACTION seconds the ‘oh no, GDM’ sentiment. <jpoiret>lechner: that's dubious at best, you're gonna be missing all the shepherd services setting up the most basic things <mirai>I suspect it's the glitch gremlin at work here <jpoiret>Well, time to get a usb key somewhere and put some Linux on it :) <lechner>jpoiret / just trying to rule out any hardware issues <akm>mirai: does that mean open up the nuc, take out the ram, then put it back in? <mirai>and if you want to, do a memtest on it <nckx>I would give a good blow through the case while you're at it. <lechner>the RAM issue would not be so reproducible, i do not think <mirai>lechner: with the information at hand, chances are on the hardware side <nckx>This is all pretty desperate advice because nobody wants to debug GDM. <mirai>lechner: why not? GRUB uses less memory <mirai>but as soon it starts the kernel, a lot more is used <lechner>akm / here is what i would do. i'd take another Linux USB and boot. If it does, your hardware is fine <mirai>bad ram errors aren't necessarily uniformly distributed <nckx>I'd not quite agree with that. At that point, make sure your other ‘Linux USB’ has memtest86+ and run *that*. Be sure. <nckx>that = ‘take another …’. <mirai>I see "corrected errors on /dev/nvme...." <nckx>ACTION is blind to fsck errors; good spot. <lechner>i have seen one bad RAM error in thirty years, and it was a poorly seated module <mirai>one irc netizen whose name I can't recall now was recently bitten by this as well <mirai>lechner: modules can "unseat" over time <mekeor[m]>does build-time native-compilation of emacs-packages work for emacs-next? could anyone, who has emacs-next installed (preferably on guix system), execute the following, and paste its outputs for me? for d in $(echo $EMACSNATIVELOADPATH | sed 's/:/\n/g'); do echo $d: $(ls $d); done <mirai>motherboard sag, thermal cycles, heatsink too tight, etc. <nckx>mirai: Is that deleted test really useless for anything? Is there nothing of value to salvage? (I don't know.) <mirai>the salvageable value could be... test that GDM launches? <mirai>but for the purposes of finding what was the original trouble with wayland/X11 it was 100% useless <jpoiret>mekeor[m]: I don't even have that env variable <mirai>if there's value in knowing that GDM launches I'll send a v2 <nckx>‘Testing whether GDM works [for GDM values of work] with Wayland’ is what I meant, but I don't use GDM so I don't know how sensible that is to test. <nckx>I'll reconfigure with patch ½ and report success, to hopefully serve as a ping. <nckx>Heh, auto-replace, cute. <jpoiret>I wouldn't remove that test, given how GDM tends to break down, it's always nice to have an extra canary in the mine <mirai>it fails as a test for X11-or-Wayland because our test vm puts the mounts as required for boot <akm>oh, I think I'm starting to follow -- the last line I see is "New Session c1 of user gdm", then sudden shutoff. <mirai>and the problem only shows itself when the mount happens later (i.e. not that boot-time) <akm>is there a way I can just end up getting my files back? That's the motivation behind trying to fix this GUIX problem. <jpoiret>booting on a usb should be enough akm <mirai>akm: boot a liveCD and mount & copy <lechner>yes, with most other linux USBs, or with system-rescue.org <mekeor[m]>jpoiret: and you use recent emacs-next on guix system? <mirai>jpoiret: well, the tests can be kept if desired <jpoiret>mirai: it fails as a test for that exist issue, not for all other GDM issues <mirai>I reverted them as they were originally added in hopes to hunt down the #57589 case. <akm>Oh, good. I will try another USB -- what does "mount and copy" mean Mirai? And will the fact that I encrypted my hard drive complicate things? <mirai>since it didn't contribute much I thought going back to the status quo ante <jpoiret>should be fine, you'll have to open the drive manually using cryptsetup <mirai>but feel free to ignore the 2/2 revert patch. <mirai>akm: mount your filesystem and copy the files to another media <akm>Thank you all for your help! <jpoiret>mekeor[m]: anything set in the build system won't escape from it magically <mirai>the encrypted part isn't too bad, you'll need to decrypt the drive using cryptsetup commands manually but it's nothing too hard <jpoiret>mekeor[m]: hmm, actually, I think there's something missing here, the emacs executable is wrapped to extend the EMACSLOADPATH with its own, but not EMACSNATIVELOADPATH <nckx>mirai: I merely meant that it's pointless to apply for my reconfigure test, not that I disagree with its removal. <nckx>Thanks for the explanation. <jpoiret>i'm not familiar enough with how emacs loads native code to be sure that it's not loading them though :) <mekeor[m]>jpoiret: my emacs-next compiles all packages itself. apparently it does not find the *.eln files <jpoiret>my emacs is telling me that some built in functions are natively compiled, not sure if it re-compiled them or if it actually uses the AOT ones <jpoiret>they're not C code, things like isearch for example <mekeor[m]>i just ripgrepped my whole $HOME for EMACSNATIVELOADPATH and there's nothing <jpoiret>bah, you'll probably have to investigate a bit more, I'm no expert on the native compilation stuff <mekeor[m]>ACTION would love to see another data point, i.e. someone else's EMACSNATIVELOADPATH :D <nckx>ACTION doesn't have one. <mekeor[m]>investigating a little further, e.g. i have the emacs-posframe package installed, but /gnu/store/...-emacs-posframe-1.3.2/lib/emacs/native-site-lisp/ only contains a directory starting with "28", not "29" or so <nckx>ACTION checks which store items, if any, even have a lib/emacs/native-site-lisp… <nckx>What in your profile provides it? <nckx>We are talking about your regular system, not some build environment, right? <nckx>I'm running emacs-next-pgtk@29.0.60-0.ac7ec87. The only thing in my store with that directory which would set EMACSNATIVELOADPATH is emacs-ement, which I don't have installed. <nckx>I don't really see a mystery in why you have it set and others don't, although I can't answer your first original question. <nckx>ACTION was promised a mystery and quickly loses interest without them 😉 <nckx>Well, that explains [in part] why it's set. Variables (‘search-paths’) like these are set on-demand, not unconditionally. <nckx>If you'd uninstall it [along with anything else providing that directory, maybe emacs-posframe] it would disappear. <nckx>I feel like I'm not really addressing your problem though. <nckx>uninstall it = emacs-ement, it would disappear = EMACSNATIVELOADPATH; super-clear writing as always. <lfam>On QA, what does the "blocked" column indicate? <nckx>I thought it was Cuirass's ‘scheduled’. <nckx>Looking at your example, I'm… no longer sure :) <lfam>Yeah, that wouldn't make sense <lfam>I'm guessing that "unknown" includes that <nckx>In the past it happened to perfectly line up, which led me to that belief. Not here. <lfam>To the email archives I go <lfam>I think it's "blocked by other failures" <lfam>Which makes sense not that I know <lfam>I like "Failed dependencies" but okay <lfam>I mean, "now that I know" <lfam>Well, it's not "green" yet but I'm happy with these results <lfam>Looks like none of these packages test for QtWebKit at build time <lfam>And now that I have a real use case for QA and the Data Service, I'm pretty happy with the paradigm <lfam>Although, I don't love the patch-basedness of it, in terms of working with the comparison provided by the Data Service, since the target commit doesn't existed anywhere in guix.git <lfam>This is great for helping people with their contributions <andreas-e>I think you can get the branch from the data service itself, with the patches as a commit. <lfam>That makes sense. I am trying to remember Hydra today, since I loved working with it (when we could keep it working) <lfam>Staying up late analyzing and fixing build failures <nckx>What did you love about it? <andreas-e>You see your lovely patch on top of something that is tagged as "base-for-issue-61536" and several others./ <lfam>nckx: I remember that it efficiently offered a Git-based model for analyzing the effects of code changes on build results. You could easily compare arbitrary commits, branches, etc, and then view and filter the relevant results, including build logs. <lfam>It would show the results of *all* builds required to effect the change, not just some arbitrary-seeming list of builds that happened to performed as a result of a job. <lfam>And it did not conflate or combine build logs from different derivations <lfam>Basically, it did what you wanted. Of course, memory is rosy, but I don't remember saying often "I wish it could do X" <lfam>I don't remember for sure, but I think it would perform new builds per-push, which is nicer than what CI does now, which is periodically <cbaines>lfam, so the "blocked" count is counting builds that can't start because some dependency fails to build <lfam>Right, makes sense! I figured it from one of your emails :) <lfam>I'm liking QA and the GDS as I use it today <nckx>Huh. That is a lot rosier than I remember. I thought it was poll-based too, but I don't remember much either. <lfam>nckx: I mean, we could barely keep it running, so there was a lot of pain. But when it worked, we were productive with it <lfam>cbaines: I just sent a pair of minor patches for GDS to guix-patches <cbaines>although lfam, I've been thinking of guix-patches@gnu.org as just for patches for guix.git, and guix-devel@gnu.org for other patches <cbaines>partly because then the automation against guix-patches@gnu.org can just assume that patches are meant to apply to guix.git <lfam>I thought that might be the case