***sturm1 is now known as sturm2
<nckx>guix-vits: Hullo, and good night đ <morrigan__>I have some kind of news from last night. The two node packages failed, I'm not entirely sure why, but I'm too worn out from the day to work on it now. I think they are missing arguments. <morrigan__>I've also gotten a little more familiar with the writefreely build process. It's pretty unusual, I'm wondering what would be the appropriate way to go about packaging it (making myself notes for later). <morrigan__>After compilation but before the binary becomes useable as a service, there is a configuration step. This, from what I can tell, can only be done interactively. <morrigan__>During the process, it prompts the user to connect to a database. If the user can't provide a database currently listening on a user-specified port, the configuration fails. <morrigan__>The database must already be initialized with at least one empty table and one user. The user must have all privileges for the table. At the end of config, writefreely populates the table. <morrigan__>The config also asks the user to set an admin account and some preferences <morrigan__>I was thinking the best method may just be to leave the config out of the build process ***drakonis1 is now known as drakonis
<guix-vits>morrigan__: and provide an default one? It's rather will not fly? <morrigan__>guix-vits: I don't really understand what you meant by that <guix-vits>morrigan__: what's wrong with me come again? <morrigan__>guix-vits: Sorry, I was asking you to rephrase what you said <guix-vits>morrigan__: "to leave the config out of the build process" -- how to provide the config? Shcedule the configuration step? Provide the default one? <guix-vits>Latter seems to not work, as it's an blogging app. <morrigan__>Some of the settings can be defaults, I'm not so sure about setting a default administrator and password though <guix-vits>morrigan__: read from /dev/random and write to config (dd count=)? <morrigan__>guix-vits: how would the user get the password? I imagine it's hashed. <guix-vits>or something alike. But if this package is easy to compile, users may be provided no substitute: let them to handle this. If the guix allow interactive steps... <morrigan__>guix-vits: Isn't Guix supposed to disallow side-effects during the build process? <guix-vits>morrigan__: passwords should be changed from time to time :) <morrigan__>guix-vits: The config step populates an (expected) empty database and fails if it can't. It would basically have to nuke all their data every update. <guix-vits>morrigan__: backup and merge (If it's feasible)? <morrigan__>guix-vits: it seems less complicated/error-prone to just ask the user to call `writefreely --config` after the initial install. <morrigan__>It might also be possible to have it called with a build hook? I don't know how that system works <guix-vits>morrigan__: It's important to hook be unable to stall an update. So, maybe not to hook it? <morrigan__>guix-vits: If the database isn't in the package, there's no danger. <morrigan__>I was thinking you could leave out the configuration if it's already configured <guix-vits>morrigan__: sounds like this configuration step is not need to be treated differently? Just it is configured *this* way, and therefore, isn't a packager issue. So long as `--configure` works after the install (if manual page exist). <morrigan__>Yeah this actually is a complete non-problem. There's a config.ini that specifies everything. <morrigan__>And the steps in the configuration can be called separately, so you can even leave it to the user to specify an admin profile after <guix-vits>and the example even provide an localhost playground. <guix-vits>"By default, WriteFreely will look for the configuration file config.ini in the current directory. However, ... -c [filename] flag ..." <guix-vits>morrigan__: what about to make an writefreely_setup.sh? Actually it needs a second command: `--gen-keys`. <morrigan__>guix-vits: sorry I dropped off. `make install` does install lessc but it seems... not great to be pulling sources with a third-party package manager during the build <guix-vits>In good old days there was an list with the dependencies to install. <guix-vits>morrigan__: did you tried to contact the devs of WriteFreely? Maybe they'll have something for you and us? Like: "just comment out this line, then install your lessc, and ...". <morrigan__>I double checked the package, it actually does not pull lessc <morrigan__>The make that gets run in `less` compiles several less files to css, expecting lessc to be installed <morrigan__>It does pull lessc through npm if you run install <morrigan__>Anyway it's just a matter of writing package definitions for the node binaries. I just am too tired from work to do it tonight. <guix-vits>morrigan__: after all ./install-less.sh checks if it's already installed... <morrigan__>guix-vits: I still need to substitute the configure step for something non-interactive <morrigan__>And it fails under the gnu buld chain because there's no ./configure <morrigan__>Is there a way I can drop the ./configure phase entirely? <guix-vits>#:phases (modify-phases %standard-phases (delete 'configure)) <morrigan__>Yeah I figured it might be the case, I just don't know how. I'm still not used to reading scheme so looking at the package/library definitions has not been a huge amount of help. <guix-vits>Holy E(ight)M(egabites)A(nd)C(onstant)S(wapping)! <morrigan__>icecat isn't rendering the characters in the URL <morrigan__>This is the error I get. It's the same for all the JS files I pull in, but the packages in node-xyz.scm don't provoke the same error <funfuna>I compile you complete me on guix, but it can't found libstdc++.so.6, how to fix this error <sneek>funfuna, you have 1 message. <guix-vits>funfuna: pastebin shows a captcha to tor users (because of Cloudflare). Try paste.debian.net (or not try :). <funfuna>Internet regulation does not let me access it <funfuna>OK, I have change the network, I can access it now. <guix-vits>funfuna: try to install gcc-toolchain-9, then logoff and log-in. Or even reboot (for DEs). <funfuna>I found libstdc ++. So.6 in gcc-VERSION-libs <guix-vits>logoff / log-in ; i'd similar issues, was unable to compile "helloworld". <funfuna>I re-login to my account, but it still has this error <funfuna>My current environment compiles helloworld without problems <morrigan__>What does #f mean in scheme? Is it just a null string? <guix-vits>funfuna: "<sneek> funfuna, NieDzejkob says: follow 'info "(guix)Building from <funfuna>I think I found the problem. YouCompleteMe does not use the system toolchain to compile things, but uses pre-compiled packages (for fhs system). :-( <guix-vits>morrigan: i'm lost: Is the build successful, but the IceCat shows no fonts for localhost:XXXX (i'm forget the port)? <morrigan__>guix-vits: Sorry. the build has nothing to do with icecat. It was just what I was using to paste my error message. <morrigan__>The error traces to node-build-system.scm, line 147. The function `assoc-ref inputs ( string-append "node-" dependency)` seems to have returned `#f` for the dependency "clone" <morrigan__>I feel like I need to know what assoc-ref is supposed to do <guix-vits>funfuna: try to cp the files that "not found" to YouCompleteMe dir, or below, where the libclang resides. Or create a links with ln. <morrigan__>"assq, assv and assoc find the entry in an alist for a given key, and return the (key . value) pair. assq-ref, assv-ref and assoc-ref do a similar lookup, but return just the value." <funfuna>Because I did nât know that there was a tool like patchelf, this problem stumped me. <morrigan__>So I think this is because there is no node-clone in node-xyz? <morrigan__>Seems to be exactly it. "clone" is a dependency, it's not in node-xyz <guix-vits>It's not surprising that some languages have a very own package manager. <morrigan__>I think I can write a script that pulls a node package's entire dependency tree. The only manual intervention that would be needed is if there's something that goes wrong in npm i ./. <guix-vits>i'm looking at output lined in editor. Hashes seem to differ. <morrigan__>I think it's a hash collision between the hash of the files in the first operand and the hash of the collected listed directories <morrigan__>This is something to maybe ask a dev. I'm still way too newb to resolve hash collisions. <nckx>sneek: later tell morrigan__ If hash collisions were even remotely likely we'd have a serious problem! Don't worry, we don't, this isn't about hashes at all. UNION-BUILD merges several directory trees into one (/foo/a + /bar/b â /bif/{a,b}), and it can't do that if there are both a file and director of the same name (/foo/a + /bar/a/ â ???). <nckx>sneek: later tell morrigan__ Take another look at https://paste.debian.net/1131846: ignore the scary formatting, and the error is actually quite âclearâ (for once): node-clone-2.1.2-0.7659418/bin is a file for some reason (symlink?) and can't be merged with the other directories. <apapsch>Hi, I'm trying to modify a operating-system with set-fields, which gives me a peculiar error. Even evaluating the examples from guile manual on set-fields '(guile)SRFI-9 Records' gives me errors: http://codepad.org/RVLcudBP <apapsch>How do you share operating-system details between hosts? <NieDzejkob>guix-vits: that was a sneek message from long ago, to solve a different problem <nly>can i build licenses? <nly>guix build -e "(use-modules (guix licenses)) (map license-link all-licenses)" <guix-vits>apapsch: try to share the system configs in meantime? <roptat>Operating system is a guix record, not an srfi-9 recorl, maybe that's your issue? <apapsch>I was wondering something along the lines, because it's defined with define-record-type* (notice the asterisk). you mean guile (traditional) record? <roptat>Instead try something like (operating-system (inherit template-server) (host-name "relis1")) <roptat>Guix has its own kind of records in (guix records) that are not the ones defined in srfi-9 <roptat>nly: what does it mean to build a license? <nly>to get the license text in store: /gnu/store/...-gpl3.txt <apapsch>roptat: Indeed, with inherit it works :-) thanks <nly>guix download -- <license-links> i guess <roptat>You can probably do it programmatically, but it might be harder <nckx>nly: I'm not sure exactly what you want: (guix licenses) aren't something Guix can build (most just point to non-hashed URLs, some note even that), but you can license-link yourself. <nckx>Eh, *write license-link yourself. Basically just âguix downloadâ or âwgetâ or whatever, as you suggested in the meantime. <nly>i want ./guix-profile/licenses/ to contain all licenses in guix, define a custom pkg that downloads and copies all licenses? <roptat>Not a package, a gexp or source woull be better for downloading a single file <nly>gexp is the fancy new thing :) <nckx>Goodâif anyone even hears me & I don't get lagged out of existenceâmorning, Guix o/ *nckx returns victorious with better 'fi. Reaverable networks in 2020, they exist. *guix-vits added one char to twelve thousands and three hundreds fourty-five <nckx>Build node âtopâ: bitcoind -datadir=/tmp/guix-build-bitcoin-core-0.19.0.1.drv-0/test_runner_âż_đ_20200224_123446/mempool_package_onemore_47/node0 <apteryx>C-u debbugs-gnu RET guix-patches RET returns 0 issues. Weird. ***wxie1 is now known as wxie
<wingo>hahaha yarn is embedding actual prolog with actual prolog syntax <wingo>indicates lack of extensibility of js on the language level :) <guix-vits>apteryx: M-x debbugs-gnu-search RET package RET guix-patches RET RET <civodul>i don't get it: cuirass on berlin gets "failed to connect to git.savannah.gnu.org: Network is unreachable", and thus it doesn't build the latest and greatest <civodul>oh maybe git.sv.gnu.org changed IPs and the firewall doesn't know <apteryx>guix-patches is re-working well in emacs-debbugs <apteryx>for a little while it returned zero entries for the bugs <apteryx>do you think it'd be possible to add a dependency on networking before a NFS file system is attempted to be mounted with the current service infrastructure? *mbakke is somewhat busy, but have merged the FreeCAD fix from John Soo and will push it later *civodul realizes he hadn't been reading guix-devel for ~7 days (?!) <civodul>thing is, guix-patches and bug-guix already provide more than enough :-) <lispmacs[work]>hi, I run guix pull and guix package -u, then rebooted my computer. I am wondering why I can see the recently added packages with `guix search', but emacs-guix cannot find them <lispmacs[work]>like, `guix search vinci' brings up the vinci package, but C-x x p N vinci brings up nothing <mbakke>lispmacs[work]: have you configured the 'guix-directory' variable? i.e. (setq guix-directory "~/src/guix") -- though I suppose it should DTRT without it. <mbakke>the new version of ungoogled-chromium triples compilation times, requires the unreleased Clang 10 (unless you patch it, thanks Debian), and of course hits a limitation of our ld-wrapper... fun one. <lispmacs[work]>mbakke: I'm trying to bring up that variable with customize-variable but it does not exist <nckx>âOpenSMTPD 6.6.4p1 released: addresses CRITICAL vulnerabilityâ <lispmacs[work]>curious, if I try to run (guix-command "describe") in emacs-guix REPL, I get error "guix describe: error: failed to determine origin" *sirgazil is configuring sway to behave like GNOME but doesn't know how to get dynamic workspaces... <roptat>nckx: you plan to do the upgrade? Let me know when it's pushed :) <nckx>roptat: About an hour ago. <nckx>NP. I'm a stakeholder myself. <roptat>It will take some time as berlin cannot reach savannah, it doesn't have the guix modular stuff <roptat>My main server is a small arm board where guix pull takes half a day when it can't download anything <roptat>Even guix system reconfigure takes 5 minutes and a full cpu core to print its first line on that machine :/ <mbakke>huh, why does erlang depend on webkitgtk <roptat>Guix is a huge beast, or guile is pretty inefficient <nckx>(No offence intended to Guile; progress is all I expect & that there is.) <roptat>So I just have to be very patient :) <roptat>Especially if there were some commits to other big packages after my last reconfiqure, which seems to be the case <roptat>So it's probably going to take a few days ^^ <nckx>roptat: So you get your mail delivered to your home? Or use an SMTP proxy/smarthost? <nckx>mbakke: Through wxwidgets as you probably found out by now. Sounds like a case for erlang-minimal if that's an option. *nckx jealous, no ISP allows that here. <roptat>Well, I could, but rDNS wouldn't work, and my IP is on so many blacklists <nckx>Because of ISP policy or dyndns? <mbakke>nckx: thanks, hadn't actually checked yet. I think erlang users would appreciate an erlang-minimal indeed :-) <roptat>My IP is static, but I can't set the reverse DNS <roptat>My parents used to be with a professional ISP (they had a cheap plan with internet and telephone), and I could set the reverse, the IP wasn't blacklisted, etc, it was like a dream :) <roptat>But they stopped offering services to individuals and tgat particular plan, now it's about three times normal internet plans, so I'm not with them anymore and I settled for the next best thing <roptat>So I can receive (I had to disable the firewall for that), but I use another server to send my email <roptat>Which will be upqraded much faster, and is a secondary MX too <nckx>There was a tiny virtual(? as in they leased copper from 1 of the only 2 real ISPs) one here in my city a few years ago that gave you all that for like âŹ10 a month in exchange for still using ADSL2+. Then the tax man raided the guy's (it was just one guy and his wife) home and that was the end of that. <nckx>I still don't know if I was somehow scammed but if so I want to be scammed some more please. *apteryx ponders about networking depends on user-processes which depends on file-systems, but NFS file systems depends on networking <nckx>apteryx: Do you know how systemd handles this? (Or any other init system of course, as long as it's not the âthis starts later because it comes lower in the shell script fileâ-variety.) <roptat>I think I understand where the difference in speed comes from: lscpu says bogomips 50.52 on my arm machine, and 4787.99 on the x86 one ^^" <roptat>I didn't know about bogomips before, but if it's really a measurement of speed, then the arm server is a 100 times slower <nckx>roptat: It's not. The bogo stands for bogus, and that was back in the day when it was even less bogus than it is now. <nckx>I'm shocked that lscpu shows a misleading internal kernel time-keeping value at all. <nckx>It's inviting misuse/understanding. <roptat>Then all I can say is the arm processor has a clock speed of 144 to 960 MHz not sure which value is really relevant <nckx>roptat: I'd say 960 assuming your system scales frequencies properly and isn't thermally limited to a lower speed after a while. <nckx>roptat: I don't know if cpufrequtils works on ARM but it gives all the infos. <nckx>âgrep . -r /sys/devices/system/cpu/cpu*/cpufreqâ would be the low-tech (and nigh-unreadable) version of that I guess. <sneek>morrigan__, you have 2 messages. <sneek>morrigan__, nckx says: If hash collisions were even remotely likely we'd have a serious problem! Don't worry, we don't, this isn't about hashes at all. UNION-BUILD merges several directory trees into one (/foo/a + /bar/b â /bif/{a,b}), and it can't do that if there are both a file and director of the same name (/foo/a + /bar/a/ â ???). <sneek>morrigan__, nckx says: Take another look at https://paste.debian.net/1131846: ignore the scary formatting, and the error is actually quite âclearâ (for once): node-clone-2.1.2-0.7659418/bin is a file for some reason (symlink?) and can't be merged with the other directories. <nckx>roptat: And s-tui gives you pretty freq/CPU usage/temp/power usage graphs, again assuming your system actually exports these values. <nckx>Welp, there it is again for good measure. <nckx>roptat: So if you see your frequency not reach 960 MHz at max load, there's something that can be improved. If you see it go up but go down after a while (still at max load), you know your chip is limiting itself to prevent overheating. Etc. <nckx>morrigan__: Not really, I'm a pure end-user of Guix's node package. First off, I'd check if âŠnode-clone-2.1.2-0.7659418/bin is actually a symlink, and to what, and in god's sweet name why. <morrigan__>nckx: will do. Regrettably I'm not massively familiar with the Node build process so if it's created during the build.... well I'll give it a look anyway <roptat>The node build system has a mkdir for out/bin <roptat>s-tui is fun to look at. I'm indeed at 960 MHz <nckx>I don't really understand where the foo-clone name even comes from. From a quick grep. <roptat>Which is only 3 times lower than my x86 server <noobly>when I run startx, I get xinit: unable to run server "/path/to/X": no such file or directory. Navigating to this directory I see it's true; only startx and xinit live in that dir.What's weird though is i3-wm and the graphical login launches just fine after boot, so I don't know why it complains after I Cntrl-Alt-F2 out then try and relaunch (I'm trying to get EXWM working) <noobly>not sure if this is a guix-ism or a general linux mis-step <nckx>roptat: Alas, you can't compare architectures like that. Not even (say) x86 generations. Compared to x86 armhf will always be slower for the same clock speed, as it will (hopefully) use less power at the same clock speed. <apteryx>nckx: they check the file system type, and if it's a network file system type like NFS, they defer mounting it until after the network has been up'd. <morrigan__>Massive trees of unmaintained packages with terrifying vulns <apteryx>nckx: in case a file system is not common enough to be in the whitelist of network file system, the user can input the "_netdev" option to force it being seen as. <nckx>I don't know if we have a good CPU benchmark tool in Guix (that doesn't jump into the kitchen sink & drown in its own options). I literally use a tiny C benchmark from the 90s to test VPSes and such. Not sure if it's free, though. <nckx>apteryx: Ooh, forcing init-specific flags into the mount options, beautiful. At least Guix can do that properly when we figure out how đ <jeko>I have trouble to clone guix git repo <jeko>Is it something from me or from the repo ? <ATuin>is autoconf-wrapper a package? something i can use in a manifest file for guix package? <morrigan__>That's weird. Savannah definitely has a valid cert <noobly>can a firefox binary be installed/ran on guix pretty easily? <roptat>jeko did you miss the step on certificate configuration from the manual? <morrigan__>jeko: I think that's you. Their certificate is valid and I have no trouble pulling sources <ATuin>jeko: i normally had that problem when running guix on top of another distro and not done the certs spep <jeko>roptat: I sure did because first time I clone I had no problem. then I delete it locally, tried to re clone and .. here I am haha <jeko>ATuin: I am on ubuntu :) <nckx>Damn, it's âlicencedâ under the ALL CAPS section of the 3-clause BSD licence, without the, y'know, clauses. Genious. <roptat>What does env | grep SSL tell you? <jeko>roptat: nothing returned <mbakke>with chromiums "jumbo build" feature gone, I'll need a more powerful server to work on it :/ <ATuin>what's the best way of creating a profile from an environment? i want to have a profile with all the deps for building guix project ... <ATuin>jeko: then try exporting the SSL_* variables <jeko>roptat: so I will. thank you <morrigan__>Probably all that's necessary is to install nss-certs and reboot <roptat>It finished computing guix derivations! Now to actually build them ^^ <jeko>do I have to install it using apt or guix ? <morrigan__>If you're running guix on top of a deb-based distro, using apt should also work though? It'll just be a different package name. <morrigan__>roptat: so I ran `npm install .` in the clone repo but it didn't generate a bin for clone <roptat>Sure npm works differently from the node build system <roptat>Well, the node build system tnies to emulate it, so it should not be too far from your resulq <roptat>Is it a guix package? My guix doesn't finl nole-clone <roptat>There's a else case that's weird <roptat>The symlink is createl in the install phase, but I don't understanl why <ATuin>why "guix package -s autoconf-wrapper" does not return anything if it's defined as a package? <roptat>Its name is not necessarily the name of its variable <roptat>Guix search looks for tge name field of the pckage <ATuin>so i can not use it with a manifest file then <roptat>Try (package-name autoconf-wrapper) <roptat>You can, but don't use specification->package then <ATuin>actually i got that from the manifest file inside a environment, after parsing it in the repl <jeko>When I am want to hack guix (say add a package definition), is it better to (1)$ guix environment --pure guix or (2)guix environment --container guix ? <ATuin>roptat: but then i need to know all the imports right <ATuin>jeko: that's basically what i'm trying to do now, from the manifest generated by environment -C to create a profile, dunno if that's a good way of doing it though <roptat>Maybe autoconf-wrapper is hidden then? <ATuin>it's defined as public, but maybe i'm missing somerhing <roptat>jeko: I use âpure on my fedora, nothing on my guix systems <ATuin> #:export (autoconf-wrapper) <roptat>There's a property hidden or something to make it inaccessible to the cli <jeko>Ok ! I used --pure so far so I will stick with it :) <roptat>define-public is the same as define, but it also exports the variable (tgat's why you can see it in tge repl) <ATuin>i see the hidden property there <ATuin>ok, so i can not use in a manifest then <roptat>You can use it from its variable <roptat>Hidden means its not available to specification->* <ATuin>yeah, that's what i was using <roptat>But it's still programmatically evailable. A manifest is a scgeme program, so you're good <ATuin>from manifest i got all the trnsitive inputs and from there i generated the file <roptat>But I don't really get why you want that package ^^ <ATuin>maybe i'm doing it wrongly ... i have created an env to create a patch for guix and i wanted to convert it into a profile <roptat>morrigan__: I see where the issue is, I'll push a fix tonight if I can test it. Sorry for tge incpnvenience <ATuin>so i thought that just getting all the inputs frm the manifest in the env was enough <roptat>Well, the node build systems did actually create a symlink, when there is no binary to install <roptat>I'm not sure why, this why I want to test <roptat>ATuin: try to use (package-inputs guix) <roptat>Or maybe it's another accessor for all inputs <morrigan__>roptat: Ah, okay. Let me know what comes of this, I'd be interested to find out <roptat>package-direct-inputs, from (guix packages) <roptat>This should give you everything that is installed by guix environment guix <ATuin>that seems to return a list of pkg-config <ATuin>ahh sorry that's the name :) <morrigan__>roptat: Also, would the Guix project have any interest in a script that automatically generates Node packages? <roptat>Yes! I have a wip importer actually <roptat>With the work that's being done in rust, I can pnobably finish it soonish <ATuin>roptat: thanks, i got list that makes more sense <roptat>It doesn't work now, because it doesn't care about versions, so it ends up in loops that it cannot untangle <morrigan__>roptat: That's really cool. I was just going to write a quick-and-dirty python script to pull the dependency tree for a package available through npm and generate a basic guix definition from a template <noobly>is there any reaosn why guix would be dropping my wifi signal incredibly frequently? I've never had this problem before. Not sure if this could potentially be caused by some nonfree aspect of my drivers <roptat>noobly: it happens to me now too, since I last moved. It did work great before that though <roptat>ATuin: ah I didn't test. (map cadr (package-direct-inputs guix)) should be the list you want <noobly>it's super weird, I'm having to reun dhclient <device> like every 5 minutes <ATuin>roptat: yes i got that, and also filtering to remove the origins <ATuin>but i still get eh autoconf-wrapper :) <roptat>Oh in my case it won't answer unless I put the laptop to sleep for a few seconds :/ might be the access point though <roptat>But now you have a programatic way to get all the inputs, so you can put it in a manifest <ATuin>yes, it's really nice to be able to manipulate whole environments like that <ATuin>one more question, i was expecting to get guile3 in the environment but it installed guile2, is that normal? <roptat>It seems we haven't updated guix to use guile 3 yet <roptat>I mean in the package definition, which different from what is done by guix pull <ATuin>well i have my profile but it's missing autom4te ... which is in the package autoconf-wrapper :) <roptat>What is your manifest? You should try this: (packages->manifest (map cadr (package-dirict-inputs guix))) <ATuin>ahh i did manually, the packages->manifest looks like a much better alternative <nckx>ATuin: Guix itself uses Guile 3, but the default Guile *package* is still 2, as are all the guile-foo packages. Changing that is more work. <ATuin>so for building it still uses guile2 <nckx>autoconf-wrapper is not meant to be installed (see the comment), and autom4te is provided by the autoconf package, whatever told you it was only/primarily in -wrapper lied. <nckx>ATuin: All Guix code runs under Guile 3. <nckx>If you add ("guile" ,guile) to a package, sure, that's still 2 (for a short while). <ATuin>ok, then i need to update my manifest i guess <nckx>If you're building a Guile package that would make sense. Otherwise I don't think so much. <ATuin>i'm building the whole guix from source <nckx>Hm, you're right, Guix's guix package (no possibility for confusion here, no sir) does still use guile-2.2. <ATuin>ahh nice, now the build system is using the guile in my profile for the shebang in the scripts <morrigan__>Hey I have an odd question... can Guix enforce source code signing? <nckx>So that counts as âexplicitly using Guile 2â, I don't really know why. It's a special case of what I said above, though, and Guile 3 is still the language builds âhappenâ in, even if the âguileâ executable is v2. Does that make sense? Probably not. <ATuin>nckx: it's really confusing for me at least :) <nckx>morrigan__: It could, but doesn't. <noobly>roptat: any idea why the wifi disconnect happens anyway? <nckx>ATuin: Yeah, while I was explaining it I realised how hard it is to explain. Sorry. <morrigan__>nckx: Good to know. That might be a really cool feature, although signed commits are still a rare sight. <ATuin>no problem, i get it's not easy to do <roptat>noobly: noc really, it looks like something is stuck when it happens <nckx>morrigan__: âguix pullâ kind of checks itself, but it's a very ad-hoc method that doesn't apply to $random_package. <roptat>Like nmtui will only show my wifi with full strength signal when usually it's a low signal and there are tens of other signals <roptat>But I didn't really investigate and have no idea where to start <noobly>roptat: my packet loss is often insanely high, this has only been happening with guix. I use wpa_supplicant in both Gentoo and Guix, with no similar problem in Gentoo <morrigan__>I'm thinking about the rash of attacks in the past ~2 years that came in the form of planting malicious code in plain sight <roptat>Mh⊠so maybe a driver issue then <morrigan__>i.e. attackers pushing malicious commits to the source repo <nckx>morrigan__: Note that such a feature might not actually make sense in Guix at all. I don't know. The daemon already rejects sources that don't match the sha256, a currently strong hash. <nckx>Whick keyring would Guix use to âverifyâ these commits, etc.? <nckx>The more I think about it the less I think this would be security theatre writ large. <nckx>morrigan__: Are you talking malicious commits to Guix itself? <nckx>We do have some enforcement there. <morrigan__>nckx: No, I'm thinking about the source repositories for software distributed through Guix <nckx>How would that improve security at all? <nckx>So a Guix committer commits an update to node that uses a malicious unsigned commit. Now what? <nckx>Does Guix use a local keyring and make the git-fetch fail if the tip isn't signed by a trusted key? <nckx>morrigan__: Are you familiar with source signing on other distributions? (Presumably Gentoo, Arch, âŠ) <morrigan__>nckx: As far as I'm aware no distributions so far have considered enforcing source signing. Arch doesn't; as most other distros they sign binaries and expect maintainers to be responsible for the source. <nckx>morrigan__: Who signs the sources in this scenario? <nckx>I mean, the one you envision. <morrigan__>The sources would be signed by the authors of the library. Github has functionality for signing commits and enforcing signatures. <noobly>does guix have self documentating functionality liek emacs? <morrigan__>Although as of now it's basically trivial to add a new key for a repo, so if an account is compromised it doesn't really matter <apteryx>noobly: you need a REPL like Geiser, but then you can C-d d to get docstring of procedures. <nckx>morrigan__: And would the keyring be distributed by Guix (as a package or as part of âguix pullâ) or would users be responsible for trusting specific upstream keys? <morrigan__>nckx: I would think the keys would be distributed through Guix, and maintainers would be responsible for deciding if new keys are trustworthy. <nckx>morrigan__: I'm not familiar with GitHub I'm afraid, so that example doesn't tell me anything. But I think I get your drift that their âenforcingâ doesn't really tackle real-world threat models. <noobly>apteryx: I've been using the info manual, but I'm much faster extracting the info I need the emacs way. Thansk for the geiser tip! <morrigan__>nckx: By "enforcing", I mean that Github can be configured to reject unsigned commits from source contributors. <nckx>morrigan__: I don't know how informally you're using maintainers but that would be a tedious workload for 5 people, and not much better if the Collective expanded (and more trusted people = more risk). <nckx>morrigan__: Ah, so members of the project upload their key and GitHub rejects unknown signatures? <apteryx>do we have a mean to save skeletons such as ~/.ssh/config at the operating system declaration level yet? <morrigan__>nckx: That's right. A repository administrator has to authorize keys for the repo <nckx>morrigan__: Think of Guix (GNU) maintainers as heads of the project. They certainly don't do all or even the majority of work, that would be insane. <apteryx>Just some idea: seems a 'skeletons' field could added to the user-account field and those files would be copied at the root of their home directory. <morrigan__>Source signing is still fairly uncommon, so as a feature, it wouldn't make much difference to add it currently. However, if there was a secondary (less trusted) "source" keyring, it could flag, to whoever's updating the package definition, that a recent commit is potentially suspicious. <morrigan__>If in the future it becomes more standard practice to sign sources (which, I think, it should; at least then whoever administrates the repo must explicitly authorize commits from new keys, so compromising a contributor account doesn't give you immediate power over everything that contributor can do) <nckx>morrigan__: We could add a âsignatureâ field (probably an origin, with something like (type 'gpg) or so). I'm still not sure how best to verify it automatically but it would make catching committers who didn't do their due diligence much easier. <nckx>I'm basically trying to think of ways this could go wrong đ <morrigan__>It's also harder to steal a gpg key than it is to crack a password <nckx>morrigan__: I guess that's also a reference to GitHub? No project I contribute to has a password or even something that would take a password. SSH & GPG keys, that's it. <nckx>Hm, that's not true, I forgot about Savannah. <morrigan__>nckx: Yes, GitHub/Gitlab/Bitbucket all allow passworded access <morrigan__>Not to mention bypassing SSH auth and making a commit to a trusted repository is more possible than bypassing SSH and making a signed commit to that repository <nckx>And that password allows you to change the public GPG key and administrators currently accept nicks, not keys? Your proposal sounds quite sensible to say the least and I'm surprised it's not the case already. <nckx>Sure, defense in depth & all that. <morrigan__>nckx: It depends on the repository, but yes, most public git repos allow very lax access control. <nckx>I can only speak for Guix and myself, but if a Savannah public key would change I would send mail about that. I wouldn't just accept it as Alyssa's new key because it can be changed only with a password, FFS. <nckx>I'm pretty sure that applies to all of us but đ€· So we're already better that GitHub. Big surprise. But sorry, I digressed. <morrigan__>It's been a while since I've used github, but I don't think administrators even need to require gpg auth to push a commit. It can be password-only. <morrigan__>In general the GNU project is much more stringent about security best-practices than industry norms, in my experience <roptat>But how many commits from the tip you've checked out would you check? <roptat>What if a commiter has a key that expires? <nckx>roptat: 0; same; user problem. But really the answers depend on how this is implemented and there are infinite ways to do so. <nckx>I'd be happy with some way for packages to declare âthis package signs its source and this is howâ so we can hold committers accountable when it turns out they didn't check. <nckx>Having Guix actually verify these signatures at install time? I'm not yet convinced that's worth the drawbacks. <nckx>drakonis: Or Ms. Aguilera if you prefer. <morrigan__>nckx: I don't think there's strictly a benefit to install-time enforcement. If we know the code is signed and someone in the keyring has checked it, then the hash does the validation by proxy <morrigan__>To do install-time checking essentially means not trusting the Guix keyring. <nckx>Not trusting all Guix committers to never be lazy and not check a signature, at least. Which isn't unreasonable since last I checked they were all human. <nckx>If only there was something you could paste in a (source âŠ) expression that you could only obtain by verifying the signature. <mbakke>so clang is apparently broken on i686-linux, looks like 'clang-libc-search-path.patch' is not effective <mbakke>jury still out for armhf and aarch64 <nckx>Speaking of aarch64, can anyone guix pull on the things? <morrigan__>Isn't there? The output of `gpg --verify` is deterministic if the environment is constant. <nckx>morrigan__: You had to read the âIf onlyâŠâ while stroking your chin & a harp plays in the background. I forgot to specify that. <nckx>gpg --verify is also huge-ass though. It wouldn't be pretty or pleasant. I don't know. Enough thinking for today. <morrigan__>Once I get better at working with Guix I'd probably be happy to contribute it, but I don't trust my own competence yet