IRC channel logs

2020-02-24.log

back to list of logs

<guix-vits>Hi Guix.
***sturm1 is now known as sturm2
<nckx>guix-vits: Hullo, and good night 🙂
<morrigan__>hello!
<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: come again?
<guix-vits>morrigan__: what's wrong?
<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
<morrigan__>As I did not understand it
<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__>guix-vits: Ah, I see
<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>morrigan__: `tee` to somewhere and message?
<guix-vits>`dd ... | tee`
<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?
<morrigan__>And an update might force a reconfiguration
<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)?
<guix-vits>but with such a build process, how else?
<morrigan__>guix-vits: it seems less complicated/error-prone to just ask the user to call `writefreely --config` after the initial install.
<guix-vits>morrigan__: yes
<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?
<guix-vits>and the overwriting stuff...
<morrigan__>guix-vits: If the database isn't in the package, there's no danger.
<morrigan__>Oh you mean if it's hooked
<morrigan__>I was thinking you could leave out the configuration if it's already configured
<morrigan__>But that could be done with default creds too
<morrigan__>creds/settings
<morrigan__>I will look into the software more.
<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).
<guix-vits>Imagine like LUKS and so on...
<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`.
<guix-vits> https://writefreely.org/docs/latest/developer/setup
<guix-vits>`make install` even installs lessc
<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>morrigan__: aha :)
<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
<guix-vits>morrigan__: i was just quoted the page https://writefreely.org/docs/latest/developer/setup : "# Config, generate keys, setup database, install LESS compiler"
<morrigan__>guix-vits: ah no wait you're correct
*guix-vits is proud :)
<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>Possibly it is: "The list of phases used for a particular package can be changed with the #:phases parameter. For instance, passing:" https://guix.gnu.org/manual/devel/en/guix.html#Build-Systems
<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.
<morrigan__>Oh
<morrigan__>How did... I not see that line
<guix-vits>Just below qutation. idk
<guix-vits>*quotation
<morrigan__>I... seem to be building these packages
<guix-vits>Holy E(ight)M(egabites)A(nd)C(onstant)S(wapping)!
<guix-vits>*bytes
<morrigan__>hah
<morrigan__>well, this is... interesting
<morrigan__>icecat isn't rendering the characters in the URL
<morrigan__> https://paste.debian.net/1131843
<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.
<sneek>funfuna, NieDzejkob says: follow 'info "(guix)Building from Git"' and then apply this patch: https://debbugs.gnu.org/39156
<funfuna> https://pastebin.com/GumABXLh
<guix-vits>funfuna: pastebin shows a captcha to tor users (because of Cloudflare). Try paste.debian.net (or not try :).
<funfuna>I can't open paste.debian.net
<funfuna>Internet regulation does not let me access it
<funfuna>OK, I have change the network, I can access it now.
<funfuna> http://paste.debian.net/1131845/
<guix-vits>funfuna: try to install gcc-toolchain-9, then logoff and log-in. Or even reboot (for DEs).
<funfuna>What does DE mean? Desktop env?
<guix-vits>yes.
<funfuna>I have installed gcc-toolchain
<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 will try it.
<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
<guix-vits> Git"' and then apply this patch: https://debbugs.gnu.org/39156" ? Sorry no ideas.
<guix-vits>morrigan__: #f is false
<morrigan__>guix-vits: oh ok
<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)?
<guix-vits>funfuna: wait ...
<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 build is of node-lessc (i.e. less.js)
<morrigan__>It's failing because...
<morrigan__>Uh, well, I'm not entirely sure.
<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
<morrigan__>And now I know, thanks Guile reference
<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>I solved it using patchelf
<guix-vits>funfuna: great!
<funfuna>Because I did n’t know that there was a tool like patchelf, this problem stumped me.
<funfuna>patchelf is great
<morrigan__>So I think this is because there is no node-clone in node-xyz?
<guix-vits>i'm not a dev, idk.
<morrigan__>Seems to be exactly it. "clone" is a dependency, it's not in node-xyz
<guix-vits> https://github.com/pvorb/clone
<guix-vits> https://www.npmjs.com/package/clone?activeTab=dependents
<guix-vits>Node's Less dependencies: https://www.npmjs.com/package/less?activeTab=dependencies
<guix-vits>It's not surprising that some languages have a very own package manager.
<morrigan__>so much for this being quick
<guix-vits>morrigan__: and the maintenance...
<morrigan__>oof
<morrigan__>Yeah
<guix-vits>looks like Guix need a /usr/local too
<morrigan__>Here's an odd one: https://paste.debian.net/1131846
<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 ./.
<morrigan__>Wait that's a hash collision
<morrigan__>Wh
<morrigan__>Okay
<guix-vits>i'm looking at output lined in editor. Hashes seem to differ.
<guix-vits>but all lines ends with /bin
<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.
<guix-vits>nckx: meeeow... ^
<morrigan__>I'm off to bed. This has been a fun adventure
<guix-vits>morrigan__: see you...
<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/ → ???).
<sneek>Okay.
<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.
<sneek>Okay.
<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
<NieDzejkob>it's now outdated since the patch got merged
<nly>can i build licenses?
<nly>like so:
<nly>guix build -e "(use-modules (guix licenses)) (map license-link all-licenses)"
<guix-vits>NieDzejkob: :)
<guix-vits>apapsch: try to share the system configs in meantime?
<guix-vits>my is /etc/lightweight-desktop.scm
<apapsch>guix-vits: I define a template server as a guile module: http://codepad.org/jesUhSwW which I then want to extend like this: http://codepad.org/OTVFIkjG
<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>Yeah
<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?
<nly>ok
<roptat>Not a package, a gexp or source woull be better for downloading a single file
<nly>ok, thanks
<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/
<guix-vits>o/
<wingo>good day nckx :)
<pkill9>afternoon guix
*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>Hehe.
<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.
<guix-vits>apteryx: it's emacs-guix ?
<apteryx>emacs-debbugs
***wxie1 is now known as wxie
<wingo>hahaha yarn is embedding actual prolog with actual prolog syntax
<wingo> https://next.yarnpkg.com/features/constraints
<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
<joshuaBPMan>morning Guix!
<bavier1>morning joshuaBPMan
<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>stopping nscd doesn't help
<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
<civodul>apteryx: oh, did it stop working?
<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 comes home
<nckx>‘OpenSMTPD 6.6.4p1 released: addresses CRITICAL vulnerability’
<nckx>Back to work.
<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...
<bavier1>welcome home nckx :)
<KE0VVT>Saluton, Giksuzantoj!
<nckx>Saluton all y'all.
<roptat>Saluton, KE0VVT :)
<roptat>nckx: you plan to do the upgrade? Let me know when it's pushed :)
<nckx>roptat: About an hour ago.
<nckx>Kick your boxen.
<roptat>Oh nice, thanks!
<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
<nckx>roptat: aarch64?
<nckx>Probably not.
<roptat>armhf
<roptat>Guix is a huge beast, or guile is pretty inefficient
<nckx>Itsa both.
<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?
<roptat>It's delivered to my home
<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>I can't send from here though
<roptat>Well, I could, but rDNS wouldn't work, and my IP is on so many blacklists
<nckx>Because of ISP policy or dyndns?
<nckx>Oh.
<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.)
<drakonis>systemd is the graph 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.
<roptat>I see
<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.
<roptat>How can I chick?
<roptat>check
<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.
<morrigan__>nckx: Just read the log, thanks!
<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.
<morrigan__>Handy
<morrigan__>Any idea how I could fix that?
<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
<nckx>Thanks.
<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.
<roptat>I see
<morrigan__>Christ I hate Node
<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>Hello Guixters!
<jeko>I have trouble to clone guix git repo
<jeko>$ git clone https://git.savannah.gnu.org/git/guix.git
<jeko>Clonage dans 'guix'...
<jeko>fatal: impossible d'accéder à 'https://git.savannah.gnu.org/git/guix.git/' : server certificate verification failed. CAfile: none CRLfile: none
<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
<apteryx>nckx: yeah :-)
<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
<roptat>jeko https://guix.gnu.org/manual/fr/html_node/Reglages-applicatifs.html#Certificats-X_002e509-1
<jeko>ATuin: I am on ubuntu :)
<jeko>roptat: Ok thank you
<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 ...
<roptat>jeko then you definitely want to follow the steps from https://guix.gnu.org/manual/fr/html_node/Certificats-X_002e509.html#Certificats-X_002e509
<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
<jeko>alright
<morrigan__>oh that's the guide lol
<jeko>;)
<roptat>It finished computing guix derivations! Now to actually build them ^^
<jeko>do I have to install it using apt or guix ?
<morrigan__>jeko: guix
<jeko>cool
<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
<morrigan__>Ohhh
<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>Node-clone
<morrigan__>roptat: no I'm writing the definition
<roptat>Can you share?
<morrigan__>Sure. One minute
<morrigan__> https://paste.debian.net/1131935
<morrigan__>roptat
<roptat>Thanks
<roptat>Oh
<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?
<ATuin>in the repl i can get it
<roptat>Its name is not necessarily the name of its variable
<roptat>Guix search looks for tge name field of the pckage
<roptat>The repl uses variables
<ATuin>aha
<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>mmm same name
<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>s/import/modules
<roptat>Yes
<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
<ATuin>ah
<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>roptat: yeah, you are rught
<ATuin>i see the hidden property there
<ATuin>>)
<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
<morrigan__>roptat: No worries, what was the problem?
<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)
<ATuin>let's see
<roptat>This should give you everything that is installed by guix environment guix
<ATuin>ah nice
<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
<morrigan__>Oh! I didn't know
<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
<morrigan__>I might still do that for personal use, for now
<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>Haha
<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>Not sure
<roptat>It seems we haven't updated guix to use guile 3 yet
<ATuin>ok
<roptat>I mean in the package definition, which different from what is done by guix pull
<ATuin>ah ok
<roptat>Guix pull uses guile 3
<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)))
<roptat>With the proper use-modules
<ATuin>adding autoconf fixed it
<ATuin>ahh i did manually, the packages->manifest looks like a much better alternative
<ATuin>now it's building ...
<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
<ATuin>it's using guile 2
<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>Eh, more.
<nckx>Herp.
<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
<morrigan__>Particularly Node is known for this problem
<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.
<apteryx>There's also the info manual
<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).
<morrigan__>nckx: Guix only has five core maintainers?
<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?
<nckx>morrigan__: Yes.
<morrigan__>nckx: That's right. A repository administrator has to authorize keys for the repo
<morrigan__>O_O
<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.
<morrigan__>nckx: Oh, okay
<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)
<morrigan__>It might be a feature worth considering, idk
<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
<drakonis>alyssa p. hacker?
<roptat>But how many commits from the tip you've checked out would you check?
<roptat>What if you do a shallow clone?
<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?
<nckx>I cannot.
<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.
<morrigan__>Ahhhh
<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