<lilyp>pardon my temporary absence from the discussion, I tried opening dart.dev in my browser <vagrantc>ok, so ... that thing i love about guix where you don't have any system paths? ... how do i $(CC) -shared -O3 -fPIC -Wl,-soname,liblibrecast.so.$(ABIVERS) -o $@ $^ $(LIBS) ... where libs is something like -lsodium .... replace -lsodium with some guile substitution to the full path to the sodium input? <lilyp>vagrantc: you typically add -L/gnu/store/... to $(LIBS) <vagrantc>i'm surprised i haven't run into this before <lilyp>depends on how esoteric the Makefiles you read are <nckx>pashencija[m]: Is there any documentation that needs to be updated for the image API? I can't find any. <pashencija[m]>nckx: Related to my changes - there's no documentation to update. But, in general, there's a lot to be added there <nckx>Sure, there should be docs. <pashencija[m]>Even if I find time to write these, there's still a problem of me being not much of an English speaker <kiasoc5>is anyone working on updating qt to 5.15.4? <yewscion>Hello Guix, does anyone have a workaround for `emacs-deferred` handy? I tried defining a transformation with `'(("without-tests" . "emacs-deferred"))` , but it didn't change anything. It's currently hanging and preventing me from upgrading, and I need certain packages that rely on it. <excalamus>Is there a way to build a Guix package for my project using a local repo? Right now, I'm having to commit and push my changes in order to test the Guix build. <vagrantc>is there something similar to setuid binaries, but with capabilites (e.g. setcap) ? <civodul>excalamus: yes, you can use --with-git-url=the-package=/path/to/repo for instance <vagrantc>civodul: well, nice to have a definitive answer :) <excalamus>@civodul, ah, sweet! I was trying that with url and uri in the package definition <vagrantc>have something that absolutely should not be setuid root ... but it requires networking capabilities <yewscion>civodul: Thanks for the link! I was aware of the bug report, just going through my guix-home config and trying to get a reconfigure to work. It seems there are a few other packages also reporting the same issue (wrong-number-of-arguments), but in build instead of in check. Once I've made a list, should I add it to the above ticket or make a new <vagrantc>ld: cannot find crti.o: No such file or directory ... do i need to explicitly add glibc ? <vagrantc>there appear to be a few other mentions of working around or ignoring crti.o problems in guix.git <civodul>vagrantc: you can use gcc-toolchain to have that all set up <vagrantc>hrm. adding #:use-module (gnu packages commencement) to networking.scm makes guix explode. ***tremon is now known as tremon_
<excalamus>I'll be honest, I'm not sure how I can use --with-git-url to help me write a Guix package definition using a local repo. I'm calling either guix build or guix package with -f, trying to create the build script. It seems like that requires a sourc entry. Also, --with-git-url=PACKAGE=/path/to/local/.git, as I'm reading it, needs the PACKAGE. That's what I'm trying to define. <excalamus>I'm trying things like guix build -f my_definition.scm --with-git-url=my_package=/path/to/local/repo/.git <excalamus>All I get is an error at the line in the package definition where "source" should be. If I include the source form, guix build uses that and not the head <excalamus>Also I'm having to constantly manually copy and paste the path to the .drv.gz and call zcat on it just to see the error. Surely there's a better way? ***the_tubular27 is now known as the_tubular
***taiju is now known as Guest2904
***taiju` is now known as taiju
***taiju_ is now known as taiju
***taiju is now known as Guest2456
***taiju` is now known as taiju
***taiju_ is now known as taiju
<jpoiret>is there a way to ask only for a specific output with guix build? <lilyp>guix build will build all outputs always <jpoiret>we'd need lots of env variables, here's what got the example running outside of a shell: <jpoiret>PATH="/gnu/store/ldhg9pylakiv11r620j6pjxkcz4x68hb-gcc-toolchain-9.4.0/bin:$PATH" LIBRARY_PATH="/gnu/store/3kr08micnpsnf10hq4ihkdks6s5fzvqh-libgccjit-9.4.0/lib/gcc/x86_64-unknown-linux-gnu/9.4.0/:/gnu/store/3kr08micnpsnf10hq4ihkdks6s5fzvqh-libgccjit-9.4.0/lib/:/gnu/store/ldhg9pylakiv11r620j6pjxkcz4x68hb-gcc-toolchain-9.4.0/lib:$LIBRARY_PATH" ./jit <lilyp>Should we patch libgccjit so that it correctly invokes the linker? <jpoiret>for the linker path, yes, for the library_path i'm not sure how we could do that <jpoiret>and, to make matters worse, it's the gcc codebase we're talking about <jpoiret>good luck finding the right place to patch :p <PurpleSym>Installed Guix on a laptop with the cryptsetup instructions from the manual, but Grub says âno such device: <uuid>â âunknown filesystemâ. Any pointers? <jpoiret>lilyp: i think it'd be hard to do, since the linker and assembler are called by the gcc driver itself, not the jit specific code <jpoiret>it's never been an issue because gcc-toolchain is always used in an environment with its env variables set <jpoiret>i'm not diving into the main gcc code that's for sure <jpoiret>PurpleSym: did it ask you for a passphrase? <PurpleSym>jpoiret: Nope, went straight to grub rescue shell. <jpoiret>then you might have an issue with your uuid <jpoiret>does it ask for a passphrase? if so, your uuid is wrong <PurpleSym>The UUID was the one from `cryptsetup luksUUID`, as the manual states. <jpoiret>well, maybe insmod luks <RET> insmod luks2 <PurpleSym>Yes, itâs the LUKS2 from the manual (i.e. with --pbkdf pbkdf2). <PurpleSym>Probably. I did not create a separate partition. <vivien>Could someone put the "v6" in a branch? I would like to test it in a setting where itâs difficult to patch and recompile guix. <PurpleSym>`ls` only shows `(hd0)` â no partitions or anything. I remember there was some issue with NVMe disks, but I canât find it. <jpoiret>no, i think it's just that long standing luks2+grub bug <jpoiret>grub-install doesn't understand luks2 drives and won't embed what's needed to open them <jpoiret>and since /boot is on there, you won't be able to insmod the module <jpoiret>the maintainers are trying to merge patches regarding that, i've written one that does exactly that <jpoiret>hopefully next grub version we'll have that support <jpoiret>the workaround for now is to have /boot unencrypted <tinybronca[m]>jpoiret: Why does grub-install not understand LUKS2 I thought that support has been in GRUB for months if not years by now? <PurpleSym>Is fat32 fine for /boot? I could just use the ESP then. <tinybronca[m]>jpoiret: What if you store GRUB on different medium than the SSD? <jpoiret>PurpleSym: that's exactly what i do! :p <jpoiret>tinybronca[m]: you'd need to have /boot/grub/ unencrypted to be exact <jpoiret>so that the luks2 module can be loaded <tinybronca[m]>jpoiret: That is only if you install GRUB onto the SSD, right? <PurpleSym>Alright, thanks, letâs do another `guix system init` then. <jpoiret>GRUB has a luks2 module, but none of the userspace facilities are able to read luks2 <jpoiret>ie. grub-probe and most importantly grub-install <jpoiret>no, regardless of where grub is installed you need to have /boot/grub/ unencrypted somewhere <tinybronca[m]>jpoiret: Well I am used to /boot/ being a subdirectory of root filesystem on primary SSD, what if GRUB is installed for example on NAND/NOR Flash chip as a coreboot/libreboot payload? <jpoiret>their patch is terrible, it might not work for devices with bigger sector sizes <jpoiret>the way forward is just to add luks2 support to the userspace utilities <jpoiret>if you want I can send you the patches needed <jpoiret>it'll just be a matter of inheriting grub and adding some patches, and changing the bootloader field <tinybronca[m]>jpoiret: Oh what, someone already coded the support? Where is this code? <jpoiret>tinybronca[m]: there are ~4-5 different patches on grub-devel <jpoiret>full disclosure: i wrote one of those <jpoiret>(please don't judge my c writing skills :p) <tinybronca[m]><jpoiret> "tinybronca: there are ~4-5..." <- and they are in process of being reviewed before merging, or...? <jpoiret>well, they're being reviewed right now after sitting idle for a couple of months <tinybronca[m]>I am still not sure why /boot needs to be unencrypted if you don't have GRUB on SSD <jpoiret>because GRUB will load its modules from /boot/grub/, including the luks2 modlue <jpoiret>unless it is embedded directly in the GRUB image, which it should do if /boot/grub/ is in fact on a luks2 drive <PurpleSym>Could we do that manually in Guix, so the instructions in the manual actually work? <tinybronca[m]>I think I remember installing GRUB to a NAND Flash chip alongside Libreboot and it decrypted fine including encrypted /boot but I don't remember fully *attila_lendvai has an thinkpad x200 with full disk encryption that has grub in its bios as a payload <tinybronca[m]>attila_lendvai: Oh that is cool I think I did that too, that is what I meant, but saying "in its BIOS" sounds kind of confusing if you don't have a payload implementing BIOS, or am I missing something...? <attila_lendvai>tinybronca[m], well, in the flash chip where the bios is usually sitting. IIRC the original bios is replaced by coreboot, and grub is given as its payload <attila_lendvai>...or libreboot, or whichever. i can look up my notes if it is of interest. but when i looked a couple of months ago, much have changed around those projects in the past 2 years since i have done that. <tinybronca[m]>How much does Libreboot implement BIOS-like subsystems on it's own? I thought that was what SeaBIOS was for.... <PurpleSym>The instructions from the ArchLinux wiki worked by the way. <jpoiret>PurpleSym: that would require us to fully emulate what grub-install does <jpoiret>it does a lot of detection to embed the proper modules, the grub-mkimage way requires you to specify all modules iirc <jpoiret>lots of corner cases we could miss, which grub-install takes care of <PurpleSym>Mh, and thereâs no way to tell `grub-install` to âalways include the luks2, cryptomount, ⊠in the imageâ? I see a `--modules` switch it least. <PurpleSym>(At least for EFI thatâs no problem, because there are pretty much no size restrictions, as opposed to MBR boot.) <jpoiret>we'd have to include all the crypto modules too though which is a pain <PurpleSym>Well, doing it by hand is pretty painful as well. <jpoiret>or, we could just include the patches so that grub-install works as intended <jpoiret>nothing really depends on grub so it's not a big rebuild <PurpleSym>Sure, thatâd be ideal. Is there an issue in debbugs somewhere already? <PurpleSym>Could you open one? I can test them on this laptop and another Guix machine I have. And if no-one objects then letâs just push them. <jpoiret>i'll refactor my patch and include another from the grub mls first it'll take a bit of tim <unmatched-paren>tinybronca[m]: i don't use libreboot, but i'm fairly sure that it _doesn't_ <unmatched-paren>bios subsystems are actually completely unnecessary if you think about it <nckx>It depends on your definition of âBIOSâ *shrug* *tinybronca[m] doesn't want some weird FAT32 partition <nckx>unmatched-paren: The whole point of Coreboot is that it can't :) <tinybronca[m]>unmatched-paren: I think GRUB needs to be loaded by something.... <nckx>Coreboot does very little (well, until you have to write it). It âjustâ allows you to use luxuries like RAM and a screen :) <unmatched-paren>hmm, then i don't really understand how it works without seabios...? <nckx>When a modern CPU boots it can't talk to RAM, when the RAM comes on-line it doesn't work, and it's not as simple as flipping the âRAM pleaseâ bit. You have to do a pretty complex dance to âtrainâ it. That's one of the main things Coreboot does. <nckx>I'll shut up now, but now you have enough to search for if you want to learn more :) <tinybronca[m]>nckx: How about machines with U-Boot? They have to load U-Boot SPL into RAM as first stage, so they have to talk to RAM.... <unmatched-paren>tinybronca[m]: there's probably a bootstrap program that runs from ROM or something *tinybronca[m] doesn't know how to study such code in MaskROM <nckx>tinybronca[m]: I can almost guarantee you that U-boot is not the very first thing that boots. But I'm only really familiar with PCs. But anything using DDR has this problem, including ARM. <nckx>I doubt they provide that, the vendor does. <nckx>But now I just educated ars^Wguessing. <tinybronca[m]>I think you can have ARM or Power ISA machines that are "PCs" <tinybronca[m]>dunno Plan 9 but there's ARM laptops and motherboards for desktops/workstations <tinybronca[m]>Why does no web frontend for mailing lists show more than one post at a time??? đ€š <nckx>Some do, and the ones I've seen invariably suck. (Just a correlation, but an unfortunate one). <nckx>What's that common light-green one⊠Anyway, it sucks. <tinybronca[m]>nckx: What is the name of the frontend software that can do this? <tinybronca[m]>Why sucks? I'd rather have something that sucks and can show threaded convo on one HTML page than clicking and loading hundreds of times just to try and follow a single thread <nckx>Well, the gustibuss & all that. <nckx>I really don't remember which site/software it was, sorry. <nckx>I think the Mailman interface is my least unfavourite of them all, but that may well be Stockholm syndrome. At least I know where to look. <nckx>tinybronca[m]: âde gustibusâ if you really care, which I strongly advise you not to :) <nckx>So the ones that don't are crap and the ones that do suck. Seems par for the course for software. *unmatched-paren wonders if mumi could be extended to cover all mailing lists instead of just debbugs <tinybronca[m]>nckx: cmon not all software is crap or sucks..... I don't think it would be hard to modify Mailman to do this, so many websites have threaded comments on one page <nckx>tinybronca[m]: It's free software :) <nckx>I think debbugs is fine, but if you think it's crap and not hard to modify, I have good news for you. *nckx had mumi on the brain. <PurpleSym>jpoiret: Ping me when youâre done. Thanks đ <nckx>Though I don't ascribe the extreme relativism to it that Wikipedia seems to. <nckx>tinybronca[m]: Do you like what LKML uses? It's a kind of hybrid IME. <nckx>Which I find stressful because I encounter the same thread in different places & 'm never sure I read the whole thing, but you might like it. <tinybronca[m]>nckx: yeah I have seen, it is better to have multiple messages on one page surely, but they could do better at rendering the threading <nckx>I vaguely suspect their answer would be âdownload the mboxen and use a proper mail client, be thankful there's any Web UI at allâ. đ€· <unmatched-paren>anyone know why ocaml deps are propagated in some packages and not in others? <unmatched-paren>do i need to use file-name with url-fetch? if so what's the convention? <bovid-19>I'm thinking a about using a local clone of the guix repository. Is there something I'd need to do to keep getting substitutes? <bovid-19>Maybe I should have written 'channel' before (or instead of?) 'repository'. I'm still far from fluent in Guix. <nckx>pashencija[m]: I see why your GCC mail was âdelayedâ â it's almost 8MB in size. That would be sent out to each bug-guix@ subscriber, which is a bit much! Not everyone has broadband, or even much band at all. <nckx>pashencija[m]: So I've rejected the mailing list delivery, but there *is* a full copy on the bug tracker. Next time please compress logs over a few 100k (at most). <nckx>bovid-19: Repository was correct. *unmatched-paren is easily confused ***PotentialUser-58 is now known as some-one
<nckx>bovid-19: To answer your question (I think?) â assuming you already have substitutes configured in the daemon â you don't need to do anything. You'll get substitutes for any package you haven't modified (including by changing any of its inputs). <nckx>Assuming the substitute exists upstream, of course. <nckx>So if you edit only âhelloâ, you'll get substitutes for everything but hello. If you modify glibc, well, bad news. <unmatched-paren>Modifying glibc may lead to bad news even if you don't care about substitutes :) <bovid-19>I won't try to dig myself into _that_ hole. Way too glib for me. <unmatched-paren>The only thing you could do that might be braver is modify the gcc that's used in guix builds. <nckx>Nah: the bootstrap binaries. Think big. <nckx>Or smol, actually, I guess... <nckx>You get one bootstrap-related pun if you want, bovid-19, but two is a ban. <vivien>Among the ungooglable things is "how to bootstrap the typescript compiler?" <tinybronca[m]><nckx> "pashencija: I see why your GCC..." <- wow who uses dial-up these days? <jpoiret>tinybronca[m]: other possible complaint, my emacs would die in a fire if i had to open an 8MiB mail <nckx>Mine handled it just fine? Your emacs is broken, buy a new one. <unmatched-paren>vivien: Bootstrap was obviously created to stop those nasty free software people from searching up how to build things from source (UGH! Who does that?!) <nckx>I didn't smell burning hair tho'. <bovid-19>Nah, boot straps aren't my thing. I never found any boots fitting my hooves in this humanist world, so why would I even look for decorations? And don't get me started on the material used for them... <unmatched-paren>jpoiret: obviously you need to apply asbestos to your emacs to stop it burning* (*terms and conditions apply) <jpoiret>nckx: remember that the reason i started working on the installer was because my emacs couldn't handle the pictures people were sending *nckx has vegan boots, but they are strapless (like all good things). Hmm, I smell a conspiracy by big bootstrap. <nckx>jpoiret: đ I've had to respond to a lot of those. âSorry, thank you very much for your bug report, unfortunately the 24 megabytes of PNGs you included [âŠ]â. <nckx>The soft limit for (only) bug-guix is already a chonky 4MB for exactly that reason. <jpoiret>diving into threading particulars really was the wrong thing to do <unmatched-paren>jpoiret: strerrordesc_np looks to be AS-Safe, but it's a GNU extension :( <jpoiret>yeah, i guess that's why it is AS-safe <jpoiret>other news, execvp is not as-safe according to the POSIX standard <tinybronca[m]><vivien> "Among the ungooglable things is..." <- I don't know, the tsc code I found was writtin in Typescript, but I never heard of a TypeSCript JIT compiler only a JS one, so what transpiles tsc?? *apteryx tries akku; to install a simple guile package (ac-d-bus), it needs like 1 min of CPU time solving dependencies <unmatched-paren>tinybronca[m]: this is the whole problem that bootstrappable.org is trying to solve <tinybronca[m]>unmatched-paren: I'm aware, but I don't see them explaining how the hell to bootstrap typescript <tinybronca[m]>unmatched-paren: well there has to be another version of tsc than the one I found <unmatched-paren>tinybronca[m]: i guess so. maybe if you do `git log --reverse` and checkout the first commit <unmatched-paren>an already-transpiled version of tsc? i don't really understand the question <bovid-19>nckx: hmm, I never thought about that. Do you think Elon is in on it or more of a saviour like You Know Coup (as Prophesized by Q)? [see: https://en.wiktionary.org/wiki/PQ#Noun_2]. Anyway, I guess I contributed my share gnush*t for the day and will try to refrain from adding any more to it. *unmatched-paren confused (again :P) <unmatched-paren>nckx: tbh that's more convincing than most "truther" infographics :P <cbaines>I just spotted it had some substitutes for staging ***tremon_ is now known as tremon
<nckx>It shouldn't be used for reproducibility stats (I pull substitutes from ci.guix when impatient) but is otherwise up. <tremon>hi all, is it normal/expected for packages to have their configured statedir pointing inside the store? <tremon>asking specifically for openldap, which tries to create its default ldapi socket as /gnu/store/[deriv]/var/run/slapi, which fails when run as non-root and clutters the store when run as root <unmatched-paren>nckx: obviously the inputs are people, the build system means indoctrination, and the outputs are satanic cultists!!1!!1111! <nckx>Both: it is normal/expected status quo but most packages would be improved by patching them to use /var. They are often left pointing to /gnu/store/âŠ/var because that's easier and the package in question is configured to use /var through a service instead, but in a perfect world you'd patch them. Packages shipping prebuilt /var/db stuff complicate things though. <tremon>scanning build-system/gnu.scm I don't see any obvious ways how prefix and/or localstatedir are set before compiling <jpoiret>tremon: even when running as root, it shouldn't be able to write to the store as it is mounted ro <jpoiret>and only mounted rw by the build daemon in a separate mount namespace <nckx>tremon: --prefix is passed as a default configure-flag. The code you want is in guix/build/gnu-build-system.scm. <nckx>It is split for good but initially confusing $reasons. <tremon>ah, then I have some local configuring to do, as my setup doesn't include that namespace mount <jpoiret>wdym? you are running the daemon without chroot support? <jpoiret>otherwise your store might just be borked now :) <nckx>unmatched-paren: But the good kind of Satanic cultists :3 <jpoiret>(the build daemon calls it chroot support even though it is much more than just a chroot btw) <tremon>I'm running the daemon in its normal configuration, but /gnu/store isn't an explicit readonly mount <jpoiret>you should remount it ro yourself, on systemd-based distros there's a service file for it <nckx>guix gc --verify=contents <nckx>And guix gc --verify=contents,repair to automatically fix (through substitution) what it can. <nckx>jpoiret: --verify alone is too lazy for this, I think, it only checks whether all exected /gnu/store/foo-x.y entries exist, it doesn't recurse (IIRC). <jpoiret>oh, i thought --verify == --verify=contents <nckx>Frankly that would make UX sense but nope. <nckx>=contents is potentially much slower. <bovid-19>unmatched-paren: I think most (if not all) of the problems with Satanism stem from the sheep-based system. As an objective bystander who isn't involved in any way, I can assure you that gnu-based Satanism is superior in pretty much every way! <nckx>And lo, the true dark gods did reach up and teach bovid-19 who's boss by tweaking their wi-fi. <a13x5>lechner I'm using something like this to actually run xinit <a13x5>xinit -- $HOME/.guix-profile/bin/Xorg :0 vt1 -keeptty -configdir $HOME/.guix-profile/share/X11/xorg.conf.d -modulepath $HOME/.guix-profile/lib/xorg/modules <a13x5>Otherwise it complains a lot <lechner>unmatched-paren: yeah, i tried that. it starts but i have no input <bovid-19>nckx: not at all: they must have infiltrated my wired network. I guess that's it for me. Nice to have (virtually) known y'all! <lechner>it's our fault. we should never have called them 'daemons' <nckx>First bovid-19, now some pox-bearing beast. What hell is this. <nckx>Heh, SCO. Poster was ahead of their time. <monkey`>I am interested in using the Flutter uikit (built using Google's Dart language). <monkey`>It is not available as a guix package. Is it not included for technical/libre reasons or <nckx>unmatched-paren: Have you tried? <nckx>Thanks. If it's anything close to Android proper it will be hell. <nckx>Ah, so exactly like Android proper. <unmatched-paren>"Android studio comes with its own Java version, but I found that it was somewhat broken" <jpoiret>"look, open-source mobile OS" "what do you mean only google is able to build it reliably?" <unmatched-paren>at least on a default android... which I am forced to use because there are exactly 0 degoogled androids available for my phone :( <monkey`>There is a blog about installing flutter without android studio. Would this method be sufficient for guix: <nckx>~/flutter/bin master λ ./flutter <nckx>Downloading Linux x64 Dart SDK from Flutter engine 436f18b5a22e778604235cf6db4c676f81a6f374... <monkey`>ha yeah. At this point I'm considering the foolish task of building my own reactive framework for opengl. That would takes years I imagine? <nckx>Oh, it's all binary blobs! /home/nckx/flutter/bin/cache/dart-sdk/bin/dart: No such file or directory *nckx gets the rm -rf thrower. <nckx>I'm really not clued into all this mobile/Android stuff, so not much, but I can't say I'm surprised either. <nckx>I've managed to build a lightly customised Android from ââââsourceââââ and rip out the most egregious blobs (a minority) but that's it. <nckx>Don't make it harder than it needs to be. <monkey`>I'm not necessarily interested in being blob free on mobile today, but I want a path towards blob free and flutter ain't it ***taiju` is now known as taiju
<lechner>Hi, regarding "Multiple profiles with Guix Home" on -devel I'd like to contribute that "in-home" profiles work potentiall only on one machine (my home folder is networked) and only after an encrypted home folder is mounted (i use gocryptfs). The thread is quite lengthy, and i lost track. Is my comment meaningful? Thanks! <florhizome[m]>Iâm on a foreign distro / manjaro and installing packages with the OS package manager sometimes seems to fail because it refers to guixâ glibc instead of the native one <rekado_>the OS package manager refers to glibc from Guix? How? <lechner>vagrantc might have a perspective, but is away <rekado_>also, you wrote âsometimesâ. What are the circumstances when it happens? <florhizome[m]>Right now I want to install Joplinâappimage (the other packages failed before) <florhizome[m]><rekado_> "also, you wrote âsometimes..." <- the package manager (paru) wants to enter a fakeroot environment <florhizome[m]>bash: /gnu/store/âŠ.glibc-2.33/lib/libc.so.6: version âGLIBC_2.34â not found <peterpolidoro>another question, when "mock" is listed as a dependency in a Python package, is adding "python-mock" to the Guix package native-inputs still necessary, even though mock is now part of the Python standard library? <rekado_>florhizome[m]: can you trace the package manager with âstrace -fâ to see at what point it opens a file provided by Guix? <rekado_>this error looks like it ends up loading *some* things from Guix while using others from the host system. ***taiju_ is now known as taiju
<nckx>I just noticed my /etc/environment is never loaded on my desktop (no LANG, TZDIR, &c.) but it is on the VTs. Has anyone encountered this? <nckx>Could this be a pam_env oddity with autologin? #t ? <vagrantc>is there absolutely no network interface inside of the environment used by "guix build PACKAGE" ? not even loopback? *vagrantc taunts nckx for using a display manager <nckx>It used to be the easiest sane way to get Sway *without* ever seeing a display manager. Has that changed? <unmatched-paren>nckx: what do you mean by that? sway treats all display managers as unsupported <nckx>What a drew thing to do. <nckx>[Narrator: meanwhile, in the real world] <nckx>unmatched-paren: That sounds tedious and stupid. Why would I do that? <unmatched-paren>"Run sway from a TTY. Some display managers may work but are not supported by sway (gdm is known to work fairly well). <nckx>Why would I want to type âswayâ <RET> every time I boot? <nckx>Is this some kind of deliberately pointless Zen ritual? <unmatched-paren>i mean, you could set up your shell to run sway when you log in for the first time... <unmatched-paren>of course you'd have to make sure you don't run it every time you start a login shell <vagrantc>nckx: i just log in from the console and run "exec sway" *jackhill runs sway from GDM, but hasn't checked into its environment <nckx>jackhill: Could you echo $TZDIR for me deary? <vagrantc>i used to actually sometimes not start a graphical environment at all ... <jpoiret>nckx: i get /gnu/store/jj5aj3zxf65b7zgismwgy2wad7kbkcqz-tzdata-2021e/share/zoneinfo <jackhill>on the one computer where GDM doesn't run, I log in on a console and `export WRL_DRM_NO_MODIFIERS; exec dbus-run-session sway` but clearly something is wrong with that computer. Also sometimes sway loses track of windows there đ€· <nckx>vagrantc: So did I, but it was an 5x86 that I cooled with an ice cube in summer. It is a dark time to which I wish not to return. <nckx>(Plastic freezer ice cube, before anyone complains about the warrantee.) <nckx>jpoiret: Which DM do you use, if you still dare answer? <nckx>So apparently GDM is the premier Sway experience manager. Hmm. <nckx>That or time-travelling to 1997. *nckx considers sourcing /etc/environment somewhere unholy so it just works. <jackhill>I would love to get sway to use the GDM lock screen. I wonder if it's just a dbus message away. <unmatched-paren>hmm. maybe there's some way to get `login(1)` to run a program other than the shell. <unmatched-paren>on second thought, that would be rather stupid. you'd not be able to debug if sway malfunctions <nckx>Interesting concept. Is it possible/easy to configure login(1) to log me in automatically? (As much as I respect everyone's apparent multi-line morning typing ritual, I'll pass.) <jpoiret>jackhill: i do something of that sort <jpoiret>although the vt switching still works, which defeats it <jpoiret>and also i have a bunch of gdm-session-worker zombie processes <unmatched-paren>nckx: looks like $FAKE_SHELL would be the right variable to set. This is not a good idea, tho, as i said above. Terms and conditions apply. <unmatched-paren>"If set, login will execute this shell instead of the users' shell specified in /etc/passwd." <vagrantc>nckx: your dark time is my broad daylight by your dark time is ok <jackhill>jpoiret: sounds like progress. One of my goals is to share a computer with other folks in the house and have the use-swtiching features work etc. <unmatched-paren>your username+password is probably about three-four times that length <jpoiret>note that GDM may not run on vt7 as well <nckx>I don't type my user name, and my password is for LUKS, and after it I hit RET and go get my coffee and there better be gaudy pixels waiting for me when I get back. <jpoiret>i'd love to switch to a greetd-based greeter <jpoiret>my morning routine is: open laptop lid -> see GDM greeter -> password <jpoiret>i never really power down the damn thing <nckx>Sway has never frozen up on me once in several years. That I must say. <nckx>jpoiret: I dunno, I've never used GDM. <unmatched-paren>nckx: i think half the reason sway doesn't support DMs is that they can be a little janky and generate issues that are not caused by sway <jackhill>jpoiret: do you think gnome-shell will ever run correctly from anything but gdm? <jpoiret>the gdm -> gnome-shell handoff is very complicated <unmatched-paren>what does gnome-shell do that makes it require GDM?? surely they'd have a `startgnome3` program or something? <jpoiret>especially since gdm already runs gnome-shell đ€Ą <jpoiret>unmatched-paren: you say that until you actually start looking at the abomination that is gdm <jpoiret>i've tried launching gnome manually in the past on guix, but i can't remember if it worked or not <nckx>/bin/print-startgnome-command <unmatched-paren>jpoiret: i once looked at gnome code. never again. it's like glibc code but the grossness is amplified <jpoiret>the gdm ui is not in the gdm repository, but fully in gnome-shell, which is a nightmare <jackhill>also crazy: gnome-shell uses gjs, which is Mozilla's JS engine, but GNOME/GTK uses JavaScriptCore from WebKit for JS for web functionality in apps! Two separate JS engines! <jackhill>unmatched-paren: yeah, something like that. a gobject interface or something <jpoiret>oh, and the GJS hello world example wasn't updated for the major version, so it doesn't compile <nckx>So y'all running this JS abomination from (s)hell but mock me for not wanting to hand-crank my WM every time. OK. <jackhill>maybe I'll go back to using stone tablets or some such <KarlJoad>How bad of an idea is symlinking c99 to gcc? <lilyp>unmatched-paren: still saner than 90% of the rust code I've read so far <KarlJoad>Does gcc-toolchain also contain the <linux/...> headers? From a quick compile of emacsql's sqlite, the toolchain does not. <lilyp>pretty sure glibc headers reference the linux stuff deep down <lilyp>you do need a kernel for some stdlib stuff after all :) <apteryx>lilyp: I thought it was the other way around (the kernel copies some of glibc headers), though I may be wrong <lilyp>iirc the kernel has its own libc that probably shares some similarities with glibc <lilyp>guix show glibc | guix shell recutils -- recsel -n1 -p name,dependencies <KarlJoad>I'm just trying to get org-roam to work with my straight.el config. For some reason, the sqlite binary is never produced. I tried to manually compile, but ran into that header issue. <nckx>KarlJoad: Did you provide linux-libre-headers? <lilyp>can't you write your straight.el config so that it takes the guix package (or do you simply not want to?) <apteryx>lilyp confirmed in #linux; the kernel depends on the libc, not the other way around <apteryx>typically glibc, but could be clang's too I guess (I heard it can build the kernel nowadays) <nckx>Are you sure about this apteryx? <apteryx>ah, sorry, I got it reversed :-) so you are both right <nckx>(I wouldn't have blamed you anyway, #linux can be⊠variable.) <nckx>KarlJoad: I've downloaded gcc-toolchain in the meantime and it contains /include/linux/falloc.h as well, so the problem might be elsewhere. But try l-l-h first. <lilyp>nckx: probably propagated-inputs <nckx>No, I mean in the store directory lilyp. <lilyp>doesn't gcc-toolchain do a union-build tho? <nckx><gcc-toolchain>/include/linux â <linux-libre-headers>/include/linux <apteryx>if any KDE enthusiasts are here, this is your game <nckx>I don't know what union-build does, exactly, but possibly lilyp. <nckx>However, that shouldn't matter? <nckx>I've never heard of GCC rejecting a symlink. <apteryx>nckx: it does what you can see under ~/.guix-profile, basically :-) <nckx>It call union-build thrice. <nckx>That said I've used gcc-toolchain maybe twice (I have Guix after allâŠ), so little do I know. <lilyp>There might be bogus include paths in the recipe straight uses <lilyp>i.e. it might ignore the fact that /gnu/store even exists <nckx>Or it might overwrite or ignore C_INCLUDE_PATH (which is effectively the same thing, tru). <nckx>So many wonderful things it could do! <nckx>I'm not really optimistic that it will make a diff. <roman>Hello. What is the workflow to test changes to package definitions if I need to reconfigure my system with them to test? I've made modifications to the definition in the guix source code. I can install in the local profile with the pre-inst-env, but need to test it in the system configuration. <davidl>using #$this-package-input "pcre:bin" for `((inputs ("pcre:bin" ,pcre "bin") ... doesn't give me a directory with the correct hash for the bin output but a directory containing the hash as if using the default "out" output. Is this a bug or am I doing it wrong? <unmatched-paren>roman: you can probably do sudo ./pre-inst-env guix system reconfigure, and if it breaks things guix system roll-hack <KarlJoad>nckx: Adding l-l-h actually did it. It seems to have compiled fine. <davidl>roman: you can do: guix pull --url="$HOME"/src/guix --profile=/tmp/guix.master --disable-authentication ; GUIX_PROFILE="/tmp/guix.master" <davidl># should print /tmp/guix.master/bin/guix <davidl>guix system reconfigure /path/to/config.scm <KarlJoad>lilyp: I am trying to keep my Emacs straight configuration and Guix configurations as separate as I can, as I sometimes need to work on non-Guix distros. <singpolyma>Maybe someday even OR not using the kernel named linux <jackhill>singpolyma: don't we already have guix-on-the kernel names hurd? <KarlJoad>I know I can. Sometimes I don't have root permissions on those non-Guix distros. <unmatched-paren>I **think** (!) it **may** be possible to install guix without root, but don't quote me on that <nalaginrut>how can I specify the local git repo as a source? <civodul>nalaginrut: hi! for guix pull, it's: guix pull --url=file://... <civodul>actually maybe i misunderstood; are you trying to pull Guix from a local repo, or to build a package from a local repo? <nalaginrut>I want to build a package from a local directory <civodul>ah ok (my reply was about the former) <civodul>as in: guix build artanis --with-git-url=artanis=file://... <nalaginrut>I want to build guile-dbi for guile3, and I modified the definition from guile-xyz.scm, put it somewhere. Now I want to build the source code with 'guix pacakge'. <unmatched-paren>`guix build` builds the package, `guix package` builds AND installs it <oriansj>unmatched-paren: guix package doesn't build if one builds it prior to the package command <nalaginrut>I tried 'guix build -f FILE.scm', but the original definition will download from git with certain commit. I want to build it from a local repo. <unmatched-paren>nalaginrut: ok, does `guix build -f FILE.scm --with-source=file://...` work? <nalaginrut>unmatched-paren: no, I need to know how to modify ("source" ...) item <nalaginrut>unmatched-paren: it's copied from guile-xyz.scm, the definition of guile-dbi <unmatched-paren>you'll need to import (guix gexp), then do (source (local-file "DIRECTORY" #:recursive? #t)) <nckx>nalaginrut: How did âguix build -f FILE.scm --with-sourceâŠâ fail? <nckx>There is no reason it shouldn't work with your package. <nalaginrut>nckx: the problem is that I removed (source ...) <nckx>You made an invalid package. <unmatched-paren>(source) takes a "file-like object" gexp, which is installed into the store. (local-file) takes a local file or directory and puts it in the store, (origin) grabs a file or directory from the internet <nalaginrut>so I don't have to modify the (source ...) item, and just use --with-source? <nckx>You shouldn't have deleted the source field. Or written (source #f). Packages without a (source âŠ) won't even parse. <nckx>It has nothing to do with local file or URL. <unmatched-paren><package> is defined as a record-type*, and the (source) field is mandatory in it <unmatched-paren>nalaginrut: still, if you intend to use this multiple times, you should modify the source instead of using --with-source <nckx>Sharing your file when asked would have saved a lot of time. <unmatched-paren>there's also (text-file) which takes a string and produces a file that contains that i think? might be called `plain-file` or something <nalaginrut>nckx: it's copied from guile-xyz.scm, the guile-dbi definition <nckx>Which did not tell us you deleted the source field. Hence, why sharing is better. <nckx>Not because of some weirdness with file://. <nckx>Or --file, for that matter. <nckx>Files of all description were innocent! <nalaginrut>now the problem is that it can't build because of compiling error. Strange, I can build it directly with the same guile installed via guix. <nalaginrut>"/tmp/guix-build-guile3-dbi-2.1.8.drv-0/source/guile-dbi/libltdl/loaders/dlopen.c:63: multiple definition of `dlopen_LTX_get_vtable'; ../../libltdl/.libs/libltdlc.a(dlopen.o):/tmp/guix-build-guile3-dbi-2.1.8.drv-0/source/guile-dbi/libltdl/loaders/dlopen.c:63: first defined here <unmatched-paren>somehow it's trying to build it twice?... can you show us the package? <nalaginrut>guile-dbi uses it own libltdl, dunno if it's the reason <anadon>I need to draw attention to my patch for 54630; I didn't CC people so I don't think Ludo or TGR were notified. <KarlJoad>What is the Guix way to describe a Nix Overlay? I want my Emacs to also understand where gcc-toolchain and linux-libre-headers are for itself, so emacsql-sqlite can build. <jackhill>nckx: re: 1a6be557010bcf55d1c6d2e38ab1f8b5efe7303b what, pray tell, is wrong with the America/Los_angeles time zone? <nckx>anadon: Indeed I was not; thanks! 