IRC channel logs
2024-07-20.log
back to list of logs
<Guest9>After installing Emacs through Guix as package manager on Ubuntu, I get segfaults and can't use things like mpv for example. I assume this is because of graphics libraries. I thought that Guix does isolate itself and don't touch the system. I used Guix Home <Guest9>It did also overwrite some environment variables. Therefore it can't find the cursor picture from the system path <Isaz>does mpv work if specify a different video driver? $ mpv --vo="x11" <darwinsfinch>hi, is 6.10 linux-libre kernel going to be put into the Guix package manager soon? <Franciman>lilyp: not yet, i think. I'm out and didn't take care of the submission process <yelninei>anyone familiar with crossbuilding for hurd? playing around with a package and cmake-build-system seems to set CMAKE_SYSTEM_NAME to Linux instead of GNU. Am i doing something wrong? <civodul>yelninei: hi! it’s possible that nobody took care of adjusting cmake-build-system to handle the Hurd <sneek>civodul, you have 1 message! <sneek>civodul, freakingpenguin says: thanks for looking into the guile issue! <civodul>i’m preparing for a Cuirass upgrade on ci.guix <yelninei>civodul: yeah looks like it. Looking at cmake-build-system configure phase it seems to handle the case for windows and else set linux (which might also break other targets). I can work around it for now by adding the right flag manually <yelninei>not that familair with guix internals and guile yet to attempt a general solution <civodul>yelninei: i guess we’d need a special-case just like the MinGW one <civodul>problem is that changing cmake-build-system.scm causes a rebuild of everything that uses that build system <civodul>so we’ll have to create a branch for that <z572>civodul: i think i found why libfaketime and nss will an error occurred on i686-linux <z572>nss use 32bit time_t, but we modified libfaketime to use 64bit time_t <civodul>oh, i thought it could be something like this <z572>coreutils use 64bit time_t on i686-linux, so libfaketime test fail <civodul>does nss explicitly turn off the time64 macro? <z572>if replace coreutils with busybox, test pass. <civodul>hmm coreutils uses 64-bit time_t and so does libfaketime, right? <civodul>(i believe any newly compiled program on i686 uses 64-bit time_t, unless explicitly avoiding it) <civodul>i thought that in Guix it makes little sense to support 32-bit time_t <civodul>because we’re recompiling everything anyway, so our packages use 64-bit time_t <civodul>does nss explicitly set _TIME_BITS=32 on i686? <z572>It seems that 64bit time_t needs to be explicitly enabled <z572>need -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 <z572>Otherwise it seems to default to 32-bit time_t on 32-bit platforms <civodul>ok, i thought it was defaulting to 64 <civodul>z572: should we patch nss to explicitly pass -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64? <civodul>maybe that’s what you were looking into? <yelninei>civodul: is that because this needs to be changed in "build-side" code although such a change would only have an effect when cross compiling? <z572>civodul: I tried, but it didn't work because of the mixed abi, may need to turn this on for all packages on all 32-bit platforms <civodul>yelninei: yes, exactly; every package that has (build-system cmake-build-system) would need to be recompiled because it “imports” that file in its build process <civodul>z572: yes, we should definitely do that (Gnulib does that for most GNU packages) <civodul>but in the meantime, maybe we can find a workaround for nss? <z572>I think replace libfaketime's coreutils with busybox and remove the hack that uses 64bit time_t <z572>and enable 64bit time_t for all 32-bit platforms in the next core-update. <z572>civodul: What do you think? <yelninei>i think i understand now. Unfortunate that this would rebuild everything depending on cmake-build-system transitevely for basically nothing. <civodul>yelninei: yeah, but that happens (it’s not “nothing” strictly speaking :-)) <z572>replace coreutils with busybox on 32bit platforms <civodul>and then, rather than core-updates, i’d suggest having a “time64_t” branch or something specifically for this issue <yelninei>nothing refers to rebuilding things natively when only changing cross building logic (but when the whole file gets imported i guess it would be hard to find out which part has changed/ what is affected by a change, etc) <yelninei>but i am glad that the manual workaround exists and is working :) <attila_lendvai>is it normal for make-dynamic-linker-cache to take several minutes? it's while building the package ganeti, there's a guile process busy on the CPU. <attila_lendvai>ACTION has sent the ganeti build fix, but cannot post a link because debbugs is taking its time <z572>civodul: It is a pity that doing so nss will have many test failures. We're probably already in a situation where we're mixing 64-bit time_t and 32-bit time_t, see https://bugs.gentoo.org/828001 <z572>maybe we need set gl_cv_type_time_t_bits_macro=no <weary-traveler>is make check-system in guix generally quite "expensive" in terms of amount of compilation <civodul>weary-traveler: yes, “make check-system” (without any arguments) is very expensive; in particular, the installation tests are expensive <civodul>“make check-system TESTS=openssh” (for instance) is relatively cheap <civodul>attila_lendvai: ‘make-dynamic-linker-cache’ usually takes a few seconds <civodul>it’s proportional to the number of ELF files in the output <civodul>weary-traveler: the name of one or more tests, those defined under gnu/tests/*.scm <z572>But when I changed the time of faketime to 2024-08-23, the nss test passed <civodul>z572: i need to go away for a few hours but i can try later <lh>is there a way to get a backtrace from guix home? if I screw up some syntax somewhere in a personal module, I usually just get an inscrutable top-level error <lh>I have to blindly load modules in the repl to find what actually happened <hanko>is there a way to include the --expose and --preserve calls in the manifest generated by --export-manifest ? <jpoiret>hanko: no, they're only arguments to `guix shell` calls <fnat>One can't listen on a given port when using 'guix shell --container', correct? <fnat>In other words, there's no 'guix shell --container --listen 8080' or similar, I guess? <fnat>Ha, wait, there's no need for that, actually. It accepts connections (at least from localhost) already! <fnat>I was just making my life complicated... (my middle name, by the way). <lh>is there discussion anywhere about the preference for define-public over export? new to scheme and curious about this but couldn’t find anything on the guix or guile mailing lists aside from a short thread from 20 years ago <lh>I guess define-public is much more manageable for very large modules like emacs-xyz <lh>actually I’m finding stuff in logs now, turns out you have to explicitly use AND to match both terms <lh>even for an API though it seems cumbersome to have to hop back to the top of the file to check if something is public <lh>having all the exports in one place seems like the job of docs, whereas in the source it’s nice to be able to tell if something is public immediately <lh>anyway, clearly just a matter of taste <civodul>i mean, maybe it does fix it, but most likely by chance, no?