<nckx>Everyone agrees it would be a good idea, but somebody has to write it and nobody feels qualified (presumably). <elb[m]>yeah, I should also be clear that _this is all in the manual_, it's just a matter of connecting the dots between "these things exist" and "this is how you should (could?) use them that is convenient for you" <elb[m]>obviously I also make no representation that what i'm doing is the right or even a good way to do things <nckx>I have to go AFK for a while, but appreciate your time. I'm going to bookmark this, not sure what for, but one day the bubbling unease I have with these thousand-papercut issue will boil over and I'll now where to start. <elb[m]>I appreciate your receptiveness! <elb[m]>and obviously you don't owe me anything as far as doing anything with this, but I'm willing to provide more information/data/thoughts if it's helpful <nckx>elb[m]: Users doing their competent best to tool their way out of this kind of situation is something I've noticed. They will create surprisingly elaborate workflows that might not jive with what might be the ‘right’ (expected) Guix way, but it works for them. Often they just aren't aware of the Guix concept and reimplementing it themselves. That's a shame. <nckx>(_Not_ saying you're reinventing anything poorly, just saying it's an interesting pattern to build own tools. o/ ) <elb[m]>understood, and when you're back some time I'd be willing to hear "more guix-y" ways of doing some of this, if it exists :-) <GNUverkty[m]>hi! is there any way to make guix.el show packages from my 3rd party channels? <luishgh>hi guix, do you know if it is possible to manage executable files with guix home? ***stikonas_ is now known as stikonas
<elb[m]>Why does the `guix pull` profile not update the INFOPATH variable? <fnstudio_>hi, i've created a `guix shell --pure font-...' environment; i was hoping that the installed font could be picked up by latex, instead my latex file doesn't compile from within the env <fnstudio_>actually it does compile, but with errors, the pdf produced is completely blank <nckx>elb[m]: Because there is no info reader in the profile. Profile environment variables are set using a mechanism called {native-,}search-paths. These are defined by the *consumer*. <elb[m]>the content of those errors might be important ;-) <elb[m]>there might as well be an info reader in the profile, it's almost a gigabyte :-/ <nckx>As well as the reason for using --pure without [indicating that you're] including anything but the font. <elb[m]>(but OK, that makes sense in some way; I have manually added that directory to my INFOPATH) <fnstudio_>elb[m]: absolutely re the errors - it's a bit complicated as the building process removes the latex log file but i'm working on it <fnstudio_>the file, though, compiles well if i switch the latex file to the default font, so i'm pretty sure it's about my custom font <elb[m]>nckx: not sure about that, it was enormous as of two days ago, but that's today ;-) <nckx>Time makes happy fools of us all. <nckx>luishgh: That's one of its primary uses but you'll need to be much more specific. *nckx → 😴💤, good night geeks. <elb[m]>(it's really hard to tell how large a guix profile is for me, htough, I found the guix pull profile size by literally uninstalling every single guix package on a foreign distro, so that /gnu/store was empty, then running `guix pull; guix gc; du -sh /gnu/store`) <elb[m]>fnstudio_: is it a latex font or a ttf/otf/etc. font, and if it's the latter, which latex are you using, and if it's xelatex (which I'm pretty sure uses fontconfig?), what does fc-list say? <nckx>It's actually trivial, you just need to know the spell: guix size $(realpath ~/.guix-profile) <fnstudio_>elb[m]: hey, thanks, that's very helpful, yeah i use xelatex; the file compiles well in my system, outside the pure environment; let me try fc-list from within the env, that's a great point <nckx>elb[m]: Sounds about right if removing one gcc-toolchain saved 150 MiB. More to go, of course, that's why the bug's still open. Thanks & good night! <elb[m]>I'm not perfectly sure that xelatex uses fontconfig, but i'm at least 90% sure it does; I don't know if it might be an optional dependency (?) or if you have the libs but not the commands <fnstudio_>elb[m]: hey very clever, you did it!! fixed! fontconfig added to the manifest and... boom, fixed <luishgh>nckx: i mean, passing a file to `home-files-service-type' that is supposed to be executable <luishgh>by default it seems files are read-only in the store <luishgh>i wanted to add a script for the swaybar status_command as a part of my sway service in guix home <sammm>hey, i'm trying to open my config.scm using emacs over ssh (tramp) but am getting an error that `ls` cannot be found. I assume this is because the binary is in my profile rather than the usual /bin/... that tramp is expecting, any ideas how to get around this? <sammm>worked it out, needed to add /run/current-system/profile/{bin,sbin} to tramp-remote-path <elb[m]>sammm: try `(add-to-list 'tramp-remote-path ...` nevermind, you got it ;-) ***lukedashjr is now known as luke-jr
<PotentialUser-19>Hi, I just installed guix on foreign system, but all the GUI programs I install through guix have tiny cursors. How do I fix this? <ryanprior[m]>PotentialUser-19: I actually have that problem too and never even thought to complain ***dhruvin_ is now known as dhruvin
<unmatched-paren>PotentialUser-19: there's probably some cursor styling setting that the guix apps aren't recognising <jpoiret>that way you can selectively do it for some hosts <jpoiret>you'd have to adapt it because that's for sudo on localhost ***rgherdt_ is now known as rgherdt
<maximed>luishghg: The same way you add non-executable files I guess. <maximed>The executables will be read-only, but that doesn't seem like a problem to me? <jpoiret>Did anyone try to use the mumi graphql api? <jpoiret>i'm trying but even the simplest query does not return any results <yarl>Sorry, that's not guix related but I am wondering if someone here already used emacs-calc? <maximed>sneek: later tell oriansj: Add "--localstatedir=/var" to ./configure <maximed>sneek: later tell oriansj: otherwise the store will break if you hack on the guix daemon and run the modified version from the Guix checkout <maximed>sneek: later tell oriansj: hydra.gnu.org doesn't exist anymore, nowadays it's ci.guix.gnu.org / or the bordeaux one <maximed>sneek: later tell oriansj: the "git clone ..." is insecure, it assumes the integrity of savannah and the PKI infrastructure. Needs a "guix git authenticate ..." <maximed>Is there a standard method to, given a list of packages, return the transitive closure of their dependencies? <maximed>Maybe I could have a look at (guix graph) though I'm looking for a Scheme API <lilyp>maximed: package-transitive-inputs ? <maximed>lilyp: That package looks only at the direct inputs and the propagated inputs, while I'm looking for non-propagated inpputs as well. <maximed>'transitive-inputs' seems close to what I want though, so maybe I could take that procedure & modify it a bit ... <gabber>is it ok to submit multiple patches (of one series) in the first email? <lilyp>you can use attachments if that's what you mean, but sending all patches at once invokes buggy debbugs behaviour <lilyp>(therefore we typically send the cover-letter ahead and then the others) <gabber>okey dokey :) i was just wondering what the reason behind that was. thanks! <unmatched-paren>gabber: if you do that, multiple issues will be created for each patch :) <gabber>and is it true that subjects of subsequent messages (the ones to <NNN@debbugs.gnu.org>) don't really matter (bc they will be threaded with the previous messages? <maximed>(Good) e-mail clients support Message-Id & References or In-Reply-To and don't require the ‘Re: ...’ convention <maximed>(assuming you reply to a mail previously sent to NNN@debbugs) <gabber>well, mutt suggests the subject "Re: bug#NNN: Acknowledgement (*original subject*)" and i wondered whether this is supposed to be adjusted. but i guess not <unmatched-paren>by the way, now that seatd exists, is it possible for me to remove elogind entirely while still using sway? <muradm>unmatched-paren: yes, i don't have elogind for about a year with only seatd, however it will remain as dependency to the packages <muradm>just look in docs, it shows similar example i use <jpoiret>muradm: did you happen to encounter any bugs? i'm worried about the elogind lib interacting with seatd <jpoiret>congratz on getting it merged my the way <muradm>jpoiret: to be honest I didn't use elogind behind seatd <muradm>on the other hand, elogind should be behind libseat maybe not seatd <jpoiret>well, libseat would work with elogind or seatd backend, but the elogind lib itself i wouldn't expect to work with seatd as a backend <muradm>as far as i used seatd standalone, without elogind runinng at all, there was no issues for me <jpoiret>dbus/polkit is one thing i don't expect to work OOB (do you use networkmanager?) <muradm>as it says in my test case "minimal-desktop" :D no polkit no network manager i use at all <bjc>is there a write-up somewhere for seatd? <muradm>for network manager, you will have to subscribe to elogind at least as far as iknow <jpoiret>i think i'm going to use greetd but not seatd yet <jpoiret>i think dbus will work fine but not polkit <jpoiret>polkit uses elogind internally to identify processes iirc <muradm>unmatched-paren: dbus there is, but very minimal, no services on top which you mention <muradm>i suppose only notifications which are running <jpoiret>xdg-desktop-portal and friends should work <unmatched-paren>muradm: are you able to just remove networkmanager with no issues or other setup? <muradm>bjc: write up? seatd is minimal, look at repo, should be sufficient i think <jpoiret>basically, the issue is that polkit allows specifying different permission requirements depending on whether the session of the requesting process is active or not <muradm>unmatched-paren: didn't use networkmanager for years already.. can't comment :) why do you need it if you use sway? <jpoiret>and for that they use elogind currently <jpoiret>muradm: what do you use to connect to the wifi? <muradm>jpoiret: wpa_supplicant out of the box works fine <muradm>jpoiret: yeah, no gui :) dropped it long ago.. pain with making gui for wifi does not deserves <muradm>wpa_pass >> wpa_supplicant.conf && guix system reconfigure ... is fine <muradm>i connected in a year, after that dropped gui in favour of iwd on arch, and then wpa-supplicant on guix <muradm>unmatched-paren: nmtui should be frontend for NetworkManager, isn't it? no NetworkManger no nmtui <jpoiret>anything that uses networkmanager won't work <jpoiret>or, we could patch polkit to be able to use libseat instead of elogind :) <unmatched-paren>looks like there's one on github that's marked as highly experimental with 23 commits, the last one in 2016... <muradm>jpoiret: why do you need polkit? <jpoiret>i like the fact that the permissions are managed properly with sudo $EDITOR wpa_supplicant.conf, rather than the terrible polkit machinery *unmatched-paren wonders whether they could write one in C with termbox2 to practise <unmatched-paren>i've deleted udisks from my system already, so at least that's not a problem for me <jpoiret>sometimes, I like having plug'n'play usbs <muradm>i don't think i ever used udisks at all <muradm>all thoses just lost sense on sway and terminal <muradm>need external disk, just mount it with sudo mount <jpoiret>writing the full `mount -o uid=1000,gid=1000 /dev/nnn /mnt` is annoying tbh <jpoiret>i used to do that on my previous distro, but it's very nice to be able to not care about it at all <muradm>found new wifi to join, just sudo "wpa_pass >> wpa_suppli.conf && guix system reconfigure .." <muradm>jpoiret: may be cheaper to add some script to ~/bin/my-mount? <unmatched-paren>oh, wait. just realized that there's no need for wpa since i'm using ethernet at the moment. <muradm>unmatched-paren: yes there is list_networks <jpoiret>by the way, it shouldn't be too hard to patch polkit to support libseat <unmatched-paren>i wonder whether the polkit developers would accept such a patch upstream <muradm>unmatched-paren: no idea about upower <unmatched-paren>muradm: for powering off at low battery. i think that's what it does. <jpoiret>polkit is pretty sensitive though, so I'll retract my comment of the difficutly of such a patch :) <muradm>unmatched-paren: i'm very cheap to spend my time on such comforts :D <unmatched-paren>(i accidentally created my swap too small, so it does... uh... stuff when i try to do sleep) <muradm>there is a similiar thing from libseat author poweralertd, but i didn't have chance to look at it yet <unmatched-paren>still probably will package it to replace my ad-hoc Janet script daemon that monitors the battery level <muradm>unmatched-paren: i would not count on it :) <unmatched-paren>i mean, the author of seatd wrote that program that uses upower, so presumably they work together... <muradm>and i mean, that i would not count on it :) <unmatched-paren>(when i search for "upower with seatd" i get a bunch of amazon links for "U-Power ... Safety Seat"...) <unmatched-paren>muradm: well, i can always revert the reconfigure if it doesn't work :) <muradm>definetly, reconfigure is life saviour <muradm>unmatched-paren: swaybar shows the power use for me already, when at 3% i just do "sudo shutdown" :) <muradm>happens very very rare may be in plane, thus does not deserve 24/7 runnung daemon for that in my opinion :) <unmatched-paren>muradm: sometimes i forget; "oh, the power's low! I'd better plug it in. I'll just finish this one thing first though..." <unmatched-paren>and then it switches off the power, and fsck gets invoked on the next boot... <muradm>PotentialUser-64: try "file ./node_modules/7zip-bin/linux/x64/7za" first <muradm>unmatched-paren: how often that happens :) <maximed>PotentialUser-64: instead of the pre-compiled 7zip for a different architecture, you can use the p7zip package from Guix instead. <maximed>* different architecture -> different system <unmatched-paren>seems to be used for time syncing across networks, but i'm not sure if that means local networks or just generally fetching the time from the internet <muradm>unmatched-paren: preferably, but still depends <maximed>PotentialUser-64: if you want to override the library loading paths, you need to set LD_LIBRARY_PATH. <muradm>unmatched-paren: it does many things, but you will need the last one only, syncying local time with world <maximed>Or better: use the non-bundled p7zip from Guix instead of this bundles pre-compiled binary of unknown origin for which it would be quite easy to have silently introduced alware without detection. <muradm>PotentialUser-64: nothing will help you at this point, as maximed pointed out, you'd better find binary for guix <muradm>that binary you have, does not link with loader lib in guix <maximed>muradm, PotentialUser-64: (technically you could set LD_LIBRARY_PATH to work around things, but that's rather fragile --- e.g., what if there's a slightly different ABI or whatever) <maximed>PotentialUser-64: I'm not seeing that in the sourec code. <muradm>maximed: how is that would help? i never could fixed loader thing under guix: Subsurface-5.0.6-x86_64.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, stripped <maximed>muradm: It doesn't help for the fixed loader, but it should do for LD_LIBRARY_PATH. <muradm>PotentialUser-64: that error you eet about bash, is related to your binary looks for /lib64/ld-linux-x86-64.so.2 <maximed>PotentialUser-64: apparently FreeTube indirectly used the 7zip-bin node module <muradm>maximed: true, that is why i first check if loader from guix or not :) <maximed>muradm: Also, patchelf can replace the loader <maximed>PotentialUser-64: how are you compiling FreeTube? <unmatched-paren>..are dependencies just for prebuilt binaries a common thing with node? <maximed>e.g.: are you compiling a Guix package definition you wrote for FreeTyube <unmatched-paren>i get guix system: error: service 'ntpd' requires 'networking', which is not provided by any service when i try to reconfigure <muradm>unmatched-paren: not published them, pastebin your config here <muradm>looks like your services is not good <muradm>here is my base-workstation with ntp and stuf <muradm>if you go out from %desktop-services, you have to opt in for %base-services or add other as necessary <muradm>i modify %base-services in my example <muradm>unmatched-paren: looks like you do use %base-services but why you add wpa-supplicant-service-type <muradm>unmatched-paren: yeah, right, it is not in %base-services <muradm>basically dhcp-client-service-type <muradm>unmatched-paren: btw, you can cleanup your (setuid-programs ...) with (screen-locker-service swaylock "swaylock") <PotentialUser-64>OK about FreeTube to use it I have to satisfy dependencies of builded version, but to build it with guix it has to be fully reproducible and bootstrapable (redone). I am not a NodeJS dev, but will try <muradm>unmatched-paren: btw, why not btrfs? <nckx>That technology already exists. <ardon>Hi Guix! Upon configuring the postgresql-service-type on my system, I get the following message and error https://bpa.st/LM5A . Trying to run the suggested with /var/log/postgresql/pg_ctl.log for `logfile' yields that I can't run `pg_ctl' as root. Do I need to manually create a `postgres' user? <ardon>nckx: Hmm, yeah you're right, /etc/passwd also contains a `postgres' entry <muradm>for instance gnu/packages/golang.scm, does it make sense to maintain grouping of packages by vendor / name? or just add new packages to the tail? <muradm>i.e. i want to add go-github-com-gorilla-websocket package, should i put it next to go-github-com-gorilla-* packages or to the tail of golang.scm? <nckx>I've honestly never tried *logging in* a a system user. <nckx>Who owns the log file now? <nckx>Or its parent directory if it doesn't exist. <ardon>nckx: The parent directory (/var/log/postgresql) is correctly owned by postgres:postgres, but the file (pg_ctl.log) is owned by a non-existent user PID and GID from what I can tell. I can change the permissions but I find it very odd that the posgresql daemon would do that <nckx>Guix service {U,G}IDs aren't deterministic [yet]. Did you add, remove, and re-add the postgresql service over time? <nckx>That could result in the old log file being owned by an orphaned UID. <nckx>Aside, it would probably be good practice for the services to chmod everything just in case. *nckx returns to say: just in case it's not clear, I think it's safe to chown (not chmod, sigh) it now. <ardon>nckx: Nope, it was my first time adding in this service and I agree with the extra check measure. Than you for the explanation :) <muradm>#56094 fixes sway unnecessary dependency on elogind <muradm>#56096 adds SQL language server which works with emacs-lsp <sneek>oriansj, you have 4 messages! <sneek>oriansj, maximed says: Add "--localstatedir=/var" to ./configure <sneek>oriansj, maximed says: otherwise the store will break if you hack on the guix daemon and run the modified version from the Guix checkout <sneek>oriansj, maximed says: hydra.gnu.org doesn't exist anymore, nowadays it's ci.guix.gnu.org / or the bordeaux one <sneek>oriansj, maximed says: the "git clone ..." is insecure, it assumes the integrity of savannah and the PKI infrastructure. Needs a "guix git authenticate ..." <oriansj>maximed: thank you for the suggestions to improve my guix notes <oriansj>although one shouldn't depend upon guix to authenticate guix <lilyp>isn't guix git authenticate just a fancy wrapper around git signature checking? <lilyp>I'm pretty sure you could simulate that with a guile (or otherwise) script outside of guix, though you would need to checkout the keyring branch as well <unmatched-paren>randompotato[m]: hi! this looks familiar, but i can't remember where i've seen this issue before. are you on latest or stable installer? <unmatched-paren>that's stable. hmm. i'll dig through help-guix and bug-guix soon when i'm back at an actual keyboard and try to find something :) <unmatched-paren>this is probably more likely to have issues, but maybe it fixes this one <maximed>sneek: later tell oriansj: What's the problem with asking guix to authenticate Guix? <maximed>lilyp: "guix git authenticate" not only checks the tip commit, but also the descendants, and handles merges & adding new keys & removing keys. It does more checks than just git signature checking. <maximed>sneek: later tell oriansj: (I.e., assuming you already have Guix on your system) <maximed>muradm: Alphabetical order, to avoid merge conflicts. Failing that, random order. <nckx> If you fail at ordering something alphabetically, try again first. <lilyp>sneek: later tell maximed sure it handles descendants (though looking at it from the tip that'd be ancestors), but that part wouldn't be too tricky with just git and the keyring. Adding and removing keys might be less trival though <maximed>lilyp: You need some mechanism to authenticate the keyring though (though maybe that was implied by ‘Adding and removing keys might be less trivial though’)? <sneek>Welcome back maximed, you have 1 message! <sneek>maximed, lilyp says: sure it handles descendants (though looking at it from the tip that'd be ancestors), but that part wouldn't be too tricky with just git and the keyring. Adding and removing keys might be less trival though <lilyp>maximed: exactly, my guess was that you could more or less try to check the tree against the currenty keyring, but that was a simplification <lilyp>still I think you should be able to do most of the things guix git does with plain libgit + your favourite programming language <lilyp>in other words I don't think it invokes any guix-specific parts <maximed>my favourite programming language = guile? <maximed>I mean, why reimplement what Guix already has implemented. <maximed>Though yes, IIRC it's mostly doesn't use anything truly Guix-specific <maximed>$favourite_language needs an S-exp parser though (not Guix-specific, but probably hard to find outside Schemes) <lilyp>you might want to authenticate guix with just libgit and a tiny guile script <maximed>lilyp: For bootstrapping, maybe the "guix git authenticate" code can be split-of into a separate library (+ corresponding CLI script)? <wdkrnls`>Dear guix, does anyone have a good feel on how to package go stuff? <wdkrnls`>I was hoping the go tool I wanted to use was going to be easy to install. <maximed>wdkrnls`: Do you know about "guix import go ..."? <wdkrnls`>maximed: thanks, but sadly the package could not be fetched: HTTP error 410 ("Gone"). <maximed>wdkrnls`: Then I guess the URL you passed was incorrect? <maximed>and if importing the package fails, you could first import the dependencies and write the package definition for the leaf package manually? <maximed>randompotato[m]: What's the uploaded image for? <maximed>nevermind, looks like I missed some past discussion <elb[m]>it looks like anything that uses guile bombs, but anything that's pure elisp works, maybe? <wdkrnls`>This seems to run everything, but fail at the installation. <elb[m]>I wonder if this is becasue it's using the foreign system guile <maximed>wdkrnls`: (unrelated to build failure): the 'v' prefix in (version ...) is redundant <wdkrnls`>error: in phase 'build': uncaught exception: <wdkrnls`>%exception #<&invoke-error program: "go" arguments: ("install" "-v" "-x" "-ldflags=-s -w" "") exit-status: 1 term-signal: #f stop-signal: #f> <wdkrnls`>command "go" "install" "-v" "-x" "-ldflags=-s -w" "" failed with status 1 <maximed>wdkrnls: Is there some text above (paste.debian.net)? <maximed>Otherwise, it's a rather uninformative error message <wdkrnls`>Sorry, I was just placing the last few lines of the build output I was seeing. <maximed>(probably the error message is above that) <wdkrnls`>package .: no Go files in /tmp/guix-build-dolt-v1.0.20.drv-0 <maximed>Looking at the git repo, things are in subdirectories. <maximed>So maybe you need to move in a subdirectory with a phase doing (chdir ...). <maximed>Also, lots of Go packages set #:import-path and/or #:unpack-path, maybe that's necessary here. <maximed>I don't know Go's package system well. <wdkrnls`>That seems plausible. I don't know go at all, but I peaked at the install.go file. I thought it was odd that it was trying to import something from github. <unmatched-paren>maximed: #:unpack-path and #:import-path are what you need here, yes <maximed>antiox is at 92% succeeding package builds! (if you count dependencies, IIRC only about 60% Rust leaf packages or so build) <maximed>unmatched-paren: It's a leaf package, so no #:source-only?. #:source-only? is only for libraries IIUC, like similar to #:skip-build? in #:cargo-build-system <unmatched-paren>wdkrnls`: are there multiple subdirectories containing .go files in the package source? <unmatched-paren>and set #:import-path to the original #:import-path PLUS the subdir with the actual source <unmatched-paren>although it looks like you'll want to do something with proto/Makefile <unmatched-paren>wdkrnls`: ah, looks like you need to invoke that makefile before you build <wdkrnls`>I did add bats perl and expect to the inputs. <unmatched-paren>you'll want to (with-directory-excursion (string-append import-path "/integration-tests/bats" (invoke "bats" ".")) <elb[m]>how do I find out what (use-package) category a given package is in? <elb[m]>like (use-package (gnu packages base)) <elb[m]>I don't see this information in show, which is why I asked <elb[m]>it's how you get a glibc-locales that isn't a gig ;-) <maximed>elb: DYM (use-modules (gnu packages base)? <elb[m]>on a foreign system if you only want to build some locales, you use (use-package) and (make-glibc-utf8-locales) <elb[m]>wait, sorry, use, (use-modules), you're correct maximed <elb[m]>I'm even looking right at it :-/ <unmatched-paren>gnu/packages/base.scm in guix show translates to (gnu packages base) <elb[m]>hmmm but it doesn't do what I expect <unmatched-paren>perhaps what you want isn't exported...? could you show the manifest? <elb[m]>I thought I'd tried that, and I think I did; guile says gnu/pckages/guile.scm, but if I use-module (gnu packages guile) it still says guile is unbound <elb[m]>is there a way to tell that from guix show? <unmatched-paren>Package variables are different from specifications. it's a bit weird when you first start, but it makes sense eventually <elb[m]>also why is it choosing 3.0.7 instead of 3.0.8 <unmatched-paren>elb[m]: you see, packages are just guile `record-type*`s bound to regular define/define-public variables <unmatched-paren>so the package with name guile and version 3.0.8 is bound to the Guile variable guile-3.0-latest <unmatched-paren>the name and version are used to look up the package with the guix cli tool <elb[m]>looks like the packages are in ~/.config/guix/current/share/guile/site/3.0/ <unmatched-paren>so `guix show guile@3.0.8` finds the package object with name guile and version 3.0.8 <elb[m]>yeah I knew how to get a specific version from guix show <elb[m]>but for this manifest I want "whatever guile other stuff is using" <unmatched-paren>but when you write a scheme script, you want to use the variable, not the package specification <unmatched-paren>although you can use specification->package to look up a spec in guile <singpolyma>It would be nice if it were easier to get a package by module + define name from CLI tools <elb[m]>I'm trying to get guix-emacs working, and it's failing in guile, and I think that's because that profile doesn't have guix guile installed, it has foreign system guile installed, but I'm not sure <elb[m]>yeah I'm not exploring in guile, maybe I should be, I'm exploring at the prompt <unmatched-paren>yeah, foreign system stuff mixed with guix stuff might cause problems <elb[m]>I'm more or less married to a foreign system because I need too much stuff that guix doesnt' seem to handle yet <elb[m]>but what I'm trying to do is move my "regular stuff" into guix, and use the foreign system for boot/drivers/kernel/etc. <singpolyma>unmatched-paren: the cli can easily build the sexp to get the package <unmatched-paren>elb[m]: what kind of stuff? might be worthy of a feature request if it's nothing to do with nonfree software <sneek>oriansj, you have 2 messages! <sneek>oriansj, maximed says: What's the problem with asking guix to authenticate Guix? <sneek>oriansj, maximed says: (I.e., assuming you already have Guix on your system) <elb[m]>like guix doesn't seem to have any voip stuff <singpolyma>It's just ((use-modules (something)) something-else) <elb[m]>I'm guessing that if I chase the lack of voip to the bottom it's also licensing issues, but i haven't looked <unmatched-paren>singpolyma: it can get the *package object*, but how would it know what symbols the package is bound to? i guess it could try to hackily guess... <elb[m]>but like, there's no asterisk/freesip/freepbx/nothing <nckx>maximed: /bin/malicious-guix --are-you-malicious <oriansj>maximed: I am a bootstrapper, which means there is no guix in my toolbox until *AFTER* it is successfully downloaded, validated and built. <singpolyma>unmatched-paren: once you have the package object you're done <singpolyma>You don't need the define name, you would start with that <elb[m]>singpolyma unmatched-paren ^-- voip services, not clients <unmatched-paren>elb[m]: vmware can probably be replaced with qemu or something for most use cases <unmatched-paren>singpolyma: i don't really understand what you mean. so if you do (define-public foo (package (name "foobar") ...)) guix show would display "variable: foo" or something? <singpolyma>I'll have to package one eventually probably, but for now I maintain my pbx fork as a Debian package instead out of laziness <unmatched-paren>singpolyma: ah, i see. was confused because i thought that's what you meant :) <maximed>oriansj: Right, makes sense for bootstrapping, though once you have a Guix ... <singpolyma>unmatched-paren: I want to `guix show module/pkg` or similar <singpolyma>The other direction is possible but way more work and not as interesting to me <unmatched-paren>singpolyma: hmm, like `guix show "(gnu packages base)/glibc-locales"? <elb[m]>singpolyma: yeah, my foreign system is debian <elb[m]>I've actually been pretty happy with debian foreign system + guix, although I'm trying to understand the integration better and streamline things, and running into what are probably problems I've had all along and just didn't know I had ;-) <oriansj>maximed: once you have guix and a trusted git repo, there isn't much additional benefit to having the guix you built validate the sources you just used to built it. <singpolyma>elb[m]: yeah. Debian+Guix is the ideal for both IMO <maximed>oriansj: I mean, after a "git fetch + rebase on top of savannah' master" <oriansj>maximed: I can understand a git fetch and a git merge or a git pull but why rebase? <maximed>oriansj: Unless you are present in .guix-authorizations, your commits+merge will be rejected. <maximed>so workflow: git fetch, git checkout savannah's-master, guix git authenticate, git checkout my-master, <git command to rebase on top of savannah's master> <oriansj>maximed: well good news, editing of .guix-authorizations is something one can do and it just needs to be a documented step <elb[m]>ok, installing guile in the profile with emacs-guix does not fix the fact that it doesn't work <maximed>oriansj: Guix will reject your modified .guix-authorizations. <wdkrnls`>Just wondering, is there a way to run debian under Guix and not above it? I'm thinking not really... <elb[m]>unmatched-paren: presumably this is why your paren is unmatched <maximed>Because your modifications aren't signed by a key authorised by the .guix-authorisation of the parent commits <wdkrnls`>I got burned with an OS upgrade hozing things when I my head was completely somewhere else. <wdkrnls`>So, I really would like to keep Guix transactional upgrades. <elb[m]>wdkrnls`: you can dchroot debian onto many systems <elb[m]>heh that ` did not make Matrix happy <maximed>Maybe "guix git authenticate " should have an --also-allow-this-key-even-though-it's-not-in-.guix-authorizations="oriansj's key, foobar's key, ..." option, could be convenient ... <maximed>oriansj: To be clear, your working on Guix itself, not another channel, right? <elb[m]>wdkernls: I'm not seeing a package for it right here, but Debian has historically "known how" to install itself into a chroot that you can then chroot into <elb[m]>you can obviously also install it into a virtual machine, although integration there may be tougher <maximed>oriansj: WDYM with ‘I think this covers that’? <oriansj>maximed: well yes hence the section title: Work on guix <oriansj>maximed: "This authentication rule creates a chicken-and-egg issue: how do we authenticate the first commit" <maximed>oriansj: Are we talking about the Guix repo? <elb[m]>sorry, I think dchroot is the command you used to use to enter the chroot, it looks like maybe now it's schroot (?) <elb[m]>anyway, you can try to debootstrap onto a guix install someplace <maximed>You can override the ‘first commit’ to your signed commit with custom .guix-authorization I guess, <maximed>but IIUC guix will bail out once you merge a new commit for savannah, <maximed>IIUC, guix will then bail out because one of the commits in the merge is not a descendant of the ‘first commit’ you passed <maximed>oriansj: In particular, consider: ‘ Pay attention to merges in particular: merge commits are considered authentic if and only if they are signed by a key present in the .guix-authorizations file of both branches’ <nckx>(Which TBC does not exist.) <singpolyma>nckx: yes, at least. Though not requiring the quoting because parens are special might be nice <singpolyma>That is, a more bash friendly way to specify module + name <nckx>A weird NIH pseudonotation is strictly worse than typing ' twice. <nckx>Bash users would already know their shell's rules. <oriansj>maximed: the most important details would be that the user must be able to make improved versions of guix for themselves and distribute them to anyone who trusts them. (Even if they never get merged into Guix main) <maximed>oriansj: I concur. But "guix git authenticate" hasn't been extended to support those kind of things yet. <nckx>singpolyma: Sorry for not pinging you; missed that. <oriansj>anything preventing that is violating the 4 essential freedoms at the heart of the FSF and GNU project <maximed>I'm not modifying the rust packaging to support aarch64. <maximed>Does that mean I'm violating freedom 0 for other people? <maximed>TBC, other people can already make improvised versions of Guix & distribute them. <maximed>It's merely a little complicated to do it in a secure manner and at the same time merge things from upstream in their fork. <maximed>And if someone devises a secure manner to extend "guix git authenticate" to make things simple, surely we would accept such a patch? <oriansj>maximed: you need only have the upstream public keys if you wish you import the upstream improvements <maximed>oriansj: OK. What is this response a response to? <oriansj>maximed: perhaps we have a case of incomplete communication here, so let take a moment to clarify <oriansj>Guix channels exist to allow anyone to make changes, additions, etc of any kind that they want to Guix or any of its packages or packages it refuses to include. <maximed>oriansj: It's also for packages that would be accepted but aren't submitted upstream for whatever reason. <oriansj>So a developer would by definition create their own channel to begin hacking on Guix without having to ask anyone for permission. <oriansj>anyone wishing to leverage their work would need only add their channel <maximed>oriansj: You can hack on Guix without creating a new channel (e.g., a local git checkout or some individual .scm files), but otherwise yes. <oriansj>and if they are ultimately to upstream their work, their key would just be added to the guix master .guix-authorizations prior to the merging of their work (which might require a rebase) <maximed>oriansj: (with the caveat that X' guix channel and Y' guix channel cannot be used from a single ‘pull profile’) <maximed>Though currently we just rebase things instead of <maximed>1 add key, 2 merge fork, 3 remove key (because of security) <maximed>there's a window between 1 add key and 2 merge fork. <oriansj>but at no time would that mechanism prevent a user of guix from changing guix to suit themselves; as they would just be having to mainain their own Guix channel and nothing further. <maximed>(and that window can be exploited by the owner of the fork's key by impersonating savannah) <maximed>So it's not a strategy that would actually be used by Guix I think. <maximed>oriansj: Yep, doesn't prevent them from changing Guix. <maximed>oriansj: With the caveat that merging things back from upstream is a tad inconvenient to do in a secure manner <oriansj>unmatched-paren: nice, config looking clean? <maximed>oriansj: Though hopefully that caveat can be resolved by extending "guix git authenticate" to (in some secure AND convenient manner) support fork development <oriansj>maximed: granted, merging of their party signed commits can be a pain <maximed>oriansj: It's not just a pain, currently it's a security problem. <oriansj>maximed: security problems are just technical issues. If they matter to someone, it'll be addressed. <maximed>oriansj: The whole point of "guix git authenticate" is to be secure. <oriansj>unmatched-paren: I'm a iwd+dhclient user myself <oriansj>maximed: you can't secure a system inside of itself. <maximed>If the technical issues are resolved, I suppose merging 3rd party signed commits can be considered. <maximed>oriansj: WDYM with ‘you can't secure a system inside of itself’? <maximed>"guix git authenticate" seems to work pretty well. <oriansj>maximed: I mean that it is by definition, not possible <unmatched-paren>they mean that it's not possible to check that the guix running `guix git authenticate` cannot be authenticated, because it requires a guix to run `guix git authenticate` <maximed>ok. Authenticating Guix channels is one of those channels. <unmatched-paren>of course, a non-authenticated guix cannot be trusted to authenticate other guixes <oriansj>but if I replace your glibc that guile uses to run Guix, forget anything in your security chain working. <maximed>unmatched-paren,oriansj: I'm assuming you already have an authenticated Guix, and you just want to authenticate a new Guix. <maximed>oriansj: You cannot replace my glibc. <maximed>oriansj: You don't have access to my computer. <maximed>And you (presumably) don't know the passphrase. <oriansj>passphrase doesn't matter if I have physical access <maximed>oriansj: You don't have physical access. <oriansj>or waited until you went to the store or to sleep <oriansj>unmatched-paren: rootkit the bios/microcode <maximed>oriansj: Is this still about channel authentication? <maximed>I thought we were talking about the security of "guix git authenticate". <nckx>Did oriansj replace someone's glibc again. <nckx>We talked about this! Anyway, good night all. <oriansj>maximed: well your statements wasn't about just channel authentication. <wdkrnls`>I have a stupid question... I'm just asking because I'm kinda scared to try. I can update my dm-crypt password and Guix will still boot, right? <maximed>IIRC, I only began talking beyond channel authentication because you began talking beyond channel authentication. <oriansj>your statement " WDYM with ‘you can't secure a system inside of itself’?" <maximed>oriansj: I thought that with ‘you can't secure a system inside of itself’ you meant that ‘guix git authenticate’ was fundamentally broken somehow or something. <oriansj>maximed: please let me clarify what I mean so we can be on the same page <maximed>The authentication mechanism of Guix is implemented in Guix itself, and it seems to work (with standard caveats like don't break into my home and such) <oriansj>I mean in the most universal sense: no system is secure from external attacks that take place outside of the assumptions of the system. <maximed>What I'm missing is, what point were you originally making about "guix git authenticate"? <oriansj>if you violate the assumptions of the security of a system, no matter how sound it might be. Then all rules go out the window. <oriansj>my point is it is bad security practice to only do security validations inside of a system which you may or may not know is trust worthy. <oriansj>for example if you have a malicious guix binary running on your system and do guix git authenticate of malicious guix source code, it'll express all is well <maximed>oriansj: Yes, I know about bootstrapping things. <maximed>oriansj: What I was missing, is an answer to: <oriansj>maximed: good, it is an important problem these days <maximed>20:15 < oriansj> maximed: you need only have the upstream public keys if you wish you import the upstream improvements <maximed>20:16 < maximed> oriansj: OK. What is this response a response to? <oriansj>maximed: it was in response to the difficulty of forking guix and incorporating upstream guix improvements <oriansj>hopefully that cleared up the confusion my terse statements may have caused. <oriansj>maximed: we might have not been disagreeing about anything but rather having a minor communication mismatch <oriansj>It happens but thank you for taking the time to try to clarify Guix details which I probably expressed poorly <oriansj>although I probably need more clarification on what you were attempting to express about the steps needed to be performed by a first time hacker setting up guix <oriansj>from the source repo and wanting to hack locally <maximed>oriansj: TBC, I'm assuming the hacker already has a Guix they can use for authentication. <maximed>A first time hacker probably doesn't go full fork and could just (after "guix git authenticate") make changes & commits <oriansj>maximed: oh, thank you for clarifying. I was assuming nothing beyound having git, guile, binutils, a text editor and gcc <maximed>oriansj: Maybe something to take care of: guix has some (relatively small, but still) bootstrap binaries. <maximed>So for 100% bootstrapping, they'll need to be compiled (outside Guix?) first. <maximed>Those aren't all the bootstrap seeds currently in use. Some of them are currently pre-compiled. <oriansj>maximed: well yes, Guix uses a statically compiled Guile <maximed>What I was trying to say, is that a 100% full bootstrap hacker needs to run that bootstrap first (& compare the hash) before running "./pre-inst-env guix build ..." <maximed>(i.e., run the bootstrap _outside_ Guix) <oriansj>well we would be doing a sha256sum of a tarball as that is a more stable target to enable easier auditing work for third parties <oriansj>The stages prior to sha256sum being built can be audited by a single person in a month if they so desire (with most of the hard work in the first 1Kbytes) <oriansj>although I hope maximed clarifies the steps for "comparing the hash" as I am sure my document did not cover that step and they did suggest issues with trusting a git clone and I would like to learn more about how they believe we can better guide new developers to start with a good and clean Guix <civodul>roptat: hi! re -rpath, in (guix self), good catch! <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, apteryx says: I'm not sure what the outdated jami variables/procedures used in tests/services/telephony.scm were, but if you have more details, I'm interested <civodul>roptat: i wonder if the RPATH is needed for libgcc_s.so, though <civodul>which is typically loaded lazily when needed <roptat>I don't know, it doesn't seem to be required <civodul>but ideally we'd keep the RUNPATH to gcc:lib rather than the whole gcc-toolchain <civodul>it's always hard to tell whether libgcc_s will be needed <civodul>maybe it's fine, worth paying attention to though <bjc>civodul: thanks for fixing the commit message for me. i'll get the hang of the changelog format one of these days… <DynastyMic>It runs version 2.8 and now there's version 3.2, and when I ran telegram-desktop, there's an alert to upgrade to 3.2 in order to keep using it <DynastyMic> So everytime a new version is out should one make a commit to channel.scm? 
