<nckx>Should I update the subtitles/transcript as well, despite lack of matching audio?
<karrq>anybody using guix on foreign distro with arch? recently the aur package became super hard to install... built manually in /tmp, had to disable check(), but now when I guix pull I get mkdir permission denied... the guix-daemon service (systemd) is enabled and started...
<nckx>Oh, there are multiple competing packages? Great…
<jonsger>any idea how to get static-networking to be more verbose: netlink-response-code: errno: 17 is all I get :(
<karrq>mroh: i tried that aswell but I had another error and also I didn't like that it doesn't track or provide any way to cleanup guix... I mean not that I'd uninstall guix much anyways... but there's some extra steps with the script anyways
<nckx>Maybe rewrite the script not to mention the network at all, although I think that's overkill.
<lfam>KarlJoad, rekado: My opinion about depending on nss-certs is that maybe it's okay for services, but it's not okay for packages. Because certificates have expiration dates, we can't let packages depend on them directly, or the packages themselves would see their functionality "expire"
<lfam>Instead, we have to set up these dependencies dynamically
<ft>Has something about channels changed? I have this private channel to try out things and with it in the configuration, for a couple of days now I get "guix upgrade: error: integer expected from stream" — if I remove it, things work.
<ft>The channel repository is accessible, and hasn't changed for a bit.
<KarlJoad>lfam: This is a point of confusion for me due to naming, when you say "maybe it's okay for services", do you mean daemon services or service-types (which bundle packaging and configuration together)?
<ft>The error message seems to originate from the guix-daemon. But the message is not very helpful.
<KarlJoad>If nss-certs were part of the `cuirass-service-type`, then whatever version of the service-type you pull from the substitutes would include _that_ particular version of the certs, which may be invalidated.
<KarlJoad>However, if nss-certs were a propagated input, then couldn't a graft happen to update the certs without needing to change the definition of the service-type.
<lfam>I guess, but how would that be better than using the system-wide certificate store in /etc/ssl/certs?
<KarlJoad>I'm not sure. I personally expected `cuirass-service-type` to allow SSL connections be default. I am just pondering my way around the Guix system to see if there would be a way to support my assumed default behavior.
<lfam>What I would suggest is that Guix System should include nss-certs by default
<KarlJoad>Fair enough. Is there any major reason why it could not be included? The default behavior of the Guix installer is `(append (list (specification->package "nss-certs")) %base-packages)` anyways.
<nckx>Major Browsers is deprecating HTTP on a very swift schedule. Soon it will be rare.
<lfam>People have also talked about wanting to allow users to choose between certificate store providers, but they could still choose. And regardless, it's a monoculture anyways
<KarlJoad>nckx: I am not really familiar enough with the Guix ecosystem to make a claim about how easy it would be to customize the properties of nss-certs. Making nss-certs part of `%base-packages` is pretty reasonable.
<jonsger>roptat: does guile-netlink support peer/pointopoint connections?
<KarlJoad>I am slowly trying to make the switch. Moved my website to haunt. Looking at making my VPS instance a Cuirass & nginx instance to host the site.
<lfam>Nice, did you take a look at how we use haunt?
<KarlJoad>I did. A bit more advanced than what I need right now, but definitely something good to know about. First I need to migrate my current VPS instance to Guix System and host the site properly. Then I can look into structural improvements.
<nckx>KarlJoad: If you only want the .drv file name, guix build -d will give it to you.
<nckx>Of course that doesn't ‘really’ build anything of substance.
<nckx>I don't understand the ‘trouble later on’ bit.
*nckx wonders if raghavgururajan has updated their X200.
<KarlJoad>I am going to write a definition for building my site with Haunt. I will need a way to access the store-path later on for nginx to host the new site.
<nckx>‘Build a derivation’ is ambiguous. Do you mean ‘build a package into a .drv’ or ‘build a .drv’, as in compile and install binaries?
<nckx>I suspect the latter, which ‘guix build’ does.
<nckx>It will print the store file name at the end whether you want it or not 😛
<KarlJoad>From the definition, elaborate and build the derivation (.drv), then pass the derivation to the build daemon and build the software (configure, compile, copy to $out). I will need the $out path to give to nginx somehow.
<mroh>PotentialUser-13: yes, we are all booting older generations. It's not only X200 users but also HDD users (it seems).
<nckx>Great, then I'll probably hit that when rebooting my reconfigured server.
<PotentialUser-13>mroh: so the problem is i guess booting up is very slow with shepherd that it literally thinks that there must be an error.
<lfam>I also reproduced #52051 on my x200s. But, I don't usually use the software that is affected, so I'm able to stay current
<lfam>I've had several weird racey bugs with it over the years
<mroh>I really don't know, I/we spend hours to replicate this thing in a vm (w/ io throttling), but no luck, because booting a working/desktop machine all the time is no fun. Currently I'm thinking about activationg lvmcache (again), as a workaround or some --init=/bin/sh kernel boot param hacks to strace logind or so... idk
<nckx>mala: Somebody tried to reproduce it in QEMU with ridiculously low IOPS but it didn't trigger.
<apteryx>I have an X200 running on post-merge master fine (has SSD though)
<PotentialUser-13>nckx: other distributions don't have that much boot times actually. i don't know why guix is that slow. is it starting a lot of service or is it starting normal services very slowly. i don't know which one is.
<lfam>The stat storm is like icing on the cake of the unusual storage layout
<vagrantc>the_tubular: it's been a while since i booted guix on the C201, but there aren't really armhf substitutes available and it is a bit slow to build on, and eventually started getting kernel panics with newer kernels.
<apteryx>nckx: actually, no for Python (no process are using it)
<nckx>I get that it was just an example. Just made me wonder.
<the_tubular>Damn, that's sad to hear, I wanted to buy one a try guix on it
<PotentialUser-13>is using guix with an ssd going to "waste" my ssd faster than other distros?
<apteryx>it's going to use it well, not waste it ;-)
<vagrantc>the_tubular: guix was the first real distro i managed to get working on the C201 reliably, though ... heh.
<PotentialUser-13>apteryx: well, ssds gonna die one day eventually. but i want it to live as long as possible. :)
<lfam>I see, thanks for the feedback Kolev and vagrantc
<nckx>PotentialUser-13: Only way is to measure, but I doubt Guix will waste writes. Identical files will be deduplicated. If you update packages more on Guix than you would on other distros, well, as apteryx says that's use, not waste.
<vagrantc>but yeah, any x86-based machine is going to almost certainly be faster than an ASUS C201
<nckx>Well, I was looking at its VALUE for Total_LBAs_Written, but then I thought better of that and manually compared the raw value with the manufacturer's stated endurance. Which is 400TB. I've used ~65TB of that, assuming I did the maths right, in 4 years. Still not worried.
<nckx>the_tubular: I think it's easy to overestimate that, too. The only way to tell is measure :)
<lfam>Wow, I'm about halfway through this 1 TB SSD from 2016
<KarlJoad>I an defining a `(package ...)` for building my website with `guix build -f guix.scm`. I need to specify a `source`, but the `git-fetch` procedure is failing due to SSH issues. I want the `guix.scm` file to use the directory the `guix.scm` file is sitting in as the source.
<nckx>I think (local-file FILE #:recursive? #t) is what you want here, but it's not something I've tried myself.
<nckx>It will copy all of FILE to the store, recursively, so it can be used during the build.
<nckx>Yeah, that's it. See (guix)G-Expressions for details.
<KarlJoad>That's it. That's what I was looking for. I am still used to Nix's ability to provide paths directly.
<KarlJoad>I will say, I _love_ how much documentation Guix has built into it. I can eventually find everything I want offline!
<nckx><Some Libera oper> bonus poke on the subtext, please do poke us about upcoming important releases or the likes of your software, then we can wallops that. Also we'd still be interested in a libera staff <> group contacts voice chat of sorts at some point, but that planning is still wip.
<nckx>I'll just leave that here so someone can perhaps think of it before we release, as I always forget.
<nckx>I meant to paste only the first sentence but HC is being a derp.
<KarlJoad>Maybe I am just being stupid, but why might I have "install" be an unbound variable in a package definition when I am intentionally replacing `'install` as an argument? Using the GNU build system.
<KarlJoad>nckx: The `install` procedure does not exist. I wanted the `install-file` procedure. I was incorrectly attributing the unbound variable to the install phase symbol rather than the install-file procedure.
<lfam>That means "quoting" it in the gexp way with #~
<lfam>" G-expressions, or gexps, consist essentially of three syntactic forms: gexp, ungexp, and ungexp-splicing (or simply: #~, #$, and #$@), which are comparable to quasiquote, unquote, and unquote-splicing, respectively"
<nckx>That said I can't reproduce it with your last snippet.
<KarlJoad>Hm... When I run `guix build -d -f guix.scm`, and grep the returned derivation, there is no `#` symbol anywhere.
<nckx>Sorry, not the .drv, the builder: grep -om1 '"[^"]*-builder"' $(guix build -d -f guix.scm)
<nckx>It's going to be a horrible single line of code, and you probably can't pipe it to pretty-print because of the #<, fun.
<KarlJoad>Switching from `#~` and `#$` to `gexp` and `ungexp` does nothing.
<KarlJoad>That grep returns 2 builders, both with the same path.
<kozo[m]>Hey, I have a guix shell command with a number of arguments in a .sh for testing some container. If I saved it as a .scm, is there an easy way to run all the code in the file without having to type it all into the cli?
<nckx>KarlJoad: The # in the error message is not related to the # in #~ or #$, it's coincidence.
<nckx>It's the # in #<guile's default object notation>.
<nckx>I expect a #<gexp …> literal in the builder somehow.
<nckx>Of course, maybe it wasn't supposed to work. That would explain it 😛
<nckx>It just means we'll have to be careful to rebuild all dependents even if the result would be the same.
<samplet>Do you think the ‘list’ gexp compiler is involved, or does the fact that the staged code is a list cause it to skip the gexp machinery entirely?
<samplet>(I need to brush up on the gexp build system code....)
<samplet>In other news, driving that old hard disk from QEMU does not trigger the bug.
<nckx>I ‘think’ the former, but I didn't investigate it. I didn't follow or review the gexp patches as they developed, and now the future has landed in one big whomp, and I have nobody but myself to blame for my lagging behind.
<nckx>I *enjoy* writing gexps though. I didn't expect that. They are so much more intuitive & flow-friendly.
<samplet>There’s something magical about it. It really matches the Guix problem domain.
<KarlJoad>Just to confirm, Guix has no built-in way for a package file to refer to the directory itself is in?
<samplet>I think ‘local-file’ has some magic there. I also think the manual explains it better than I could. Lemme check.
<KarlJoad>I just want to be careful, because I was using `(local-file (getcwd) ...)`, and the `(getcwd)` causes non-reproducibility because it depends on the shell's CWD.
<samplet>“If FILE is a literal string denoting a relative file name, it is looked up relative to the source file where it appears.”
<apteryx>I've started using '(arguments (list ' instead of '(arguments `(#:arg1 ...), and I realize it's weird that the #:configure-flags arguments needs to be double quoted
<KarlJoad>When in different directories for different shells, the build command produces the same store output.
<nckx>I admit that it seemed ‘obvious’ to me but I can't actually point to any documentation. And /gnu/store/<hash>-. is not, I think, itself an invalid name. It's just… no. But this should indeed be documented as you say.
<nckx>Or Guix could look up the dirname of cwd if that's safe.
<florhizome[m]>I have a question: when I enter guix shell -D to test some guix packages, it seems like my local package descriptions under GUIX_PACKAGE_PATH are still being loaded. i guess i have to unset that env var. Is there some other way to ensure a mostly pure environment?
<florhizome[m]>in this case, it's for a channel, so i don't have ./pre-inst-env around
<pukkamustard>forhizome[m]: you can use `guix shell --pure`. That will unset existing env variables.
<g_bor>I see berlin and bayfront in maintanence.git, but where is bordeaux managed from?
<rekado_>attila_lendvai: it’s surprising. Don’t know if that’s intentional. (guix ui) does some error handling and will exit with a prettier error message. But in the REPL I would have expected a backtrace and a way to recover.
<cbaines>I haven't been paying full attention, but I would think that the TLS cert is the trickiest part about getting two machines to serve guix.gnu.org (assuming it's a requirement to make it available over HTTPS)
<mothacehe>in fact we should probably factorize the website stuff in a (website) module and use it both in berlin.scm and bayfront.scm
<g_bor>so, for certbot dns validation we would need the following: a dns server that can be controlled by the renewer to be able to inject the dns record, and post 80 to be free to bind on the renewer, otherwise we can select the actual renewver from a pool. This makes the spof go away, as the renewer can be basically anywhere and the dns server should be redundant anyway.
<rekado_>okay, I’ll do a first pass copy with “cp -ar”; when that’s done I’d stop nginx and guix-publish; rsync; remount; restart nginx and guix-publish.
<rekado_>the initial copy is going to take hours, so there’s plenty of time to get the website fallback set up ;)
<g_bor>I don't think I will be able to implement this like today, but this looks like a good idea
<mothacehe>hehe, you rock! then we can setup a backup node to server the /var/cache content
<mothacehe>this way people can have substitutes even if berlin head node is down
<g_bor>It would also not depend on any webserver being up in the first place, so it would make it easier to bootstrap new infra. You could spin up the webserver by the cert already available. I assume right now we do not have this capability, but I might be mistaken here.
<skn38>@rekado_: thank you, moving the file helped!
<civodul>rekado_: so we'll be setting up the web server fallback on bordeaux, right?
<rekado_>civodul: yes, I think that makes the most sense.
<rekado_>civodul: two open issues: rsyncd needs to be started (I did this manually last time, but it’s gone since the reboot); we have an rsyncd config in /etc. The second issue is permissions of the files generated by guix publish. Not sure if that’s still a problem.
<cehteh>who cares? .. mean even when that takes years it wont be so bad, and actually could be introduced soon and, old way deprecated after the next major release, then 1-2 releases later transition is done
<mothacehe>so array reboot + upgrade won't help much probably. What we may need is more switch to a different fs or re-create the ext4 fs to reduce fragmentation, and/or move to the SAN that is SSD backed.
<cbaines>civodul, thanks for checking the static networking config, I've added the IPv6 bits now
<apteryx>rekado_: another thing that could be used if your storage array is repartitioned as btrfs are subvolumes; they are very cheap to create and destroy; so the use would be: 'btrfs subvolume create /var/guix/.trash && trash things && btrfs subvolume delete /var/guix/.trash'
<apteryx>I don't recall exactly where this daemon trashDir is, but you get the idea
<cehteh>apteryx: you cant rename between subvolumes
<civodul>cbaines: for the Disarchive database, should i rsync it from berlin to bordeaux, or can we build it on bordeaux?
<civodul>with something like "guix build -m etc/disarchive-manifest.scm"
<rekado_>civodul: the rm times are for the tiny copy. It took more than 860 mins to copy 170G from /gnu/store/trash (storage array) to /mnt_test/gnu/store/trash (SAN); and only over 3 mins to delete it all again.
<yewscion>Hello everyone, I've just cloned guix and I'm trying to set up my first development environment to contribute to the project. The manual says to run `make check`, and the repo I've checked out has two tests fail when that's run. Is this expected, or have I set something up wrong? (guix-pack-relocatable and guix-git-authenticate are the tests that
<civodul>at worst an mcron job that does "guix time-machine -- build -m ..." would do
<civodul>but anyway, we'll need to set up rsyncing at least for the web site static bits
<AIM[m]>The Chinese brand TP-Link Bluetooth USB adapter seems to work fine with libre kernel
<AIM[m]>The only issue I have now is the sound driver
<cbaines>civodul, I'm not quite sure what building it locally would involve. If it takes some work that could happen across multiple machines, it might be worth building it through the coordinator. It sort of looks like it'll fail though if any single origin can't be "built" which I find a bit confusing?
<AIM[m]>TP stands for Tapo I think (Some chinese word?)
<AIM[m]>I guess their WiFi adapter should also work
<rekado_>wikipedia says: The company name was based on the concept of "twisted pair link" invented by Alexander Graham Bell, a kind of cabling that reduces electromagnetic interference, hence the "TP" in the company name.
<civodul>cbaines: exactly, it succeeds iff all the tar.gz origins succeed
<rekado_>“ta po” could be translated as “it’s broken” :)
<tissevert>half an hour sounds long though, but I suppose it depends on the resources you have
<notmaximed>civodul,cbaines etc.: E.g.: In procedure lstat: No such file or directory: "/tmp/guix-build-Django-4.0.tar.gz.dis.drv-0/disarchive-directory.qmANcD/Django-4.0/tests/staticfiles_tests/apps/test/static/test/???.txt"
<AIM[m]>So, no way to lock the packages in channel file? I mean specify only to use that particular packages....
<notmaximed>If you are using manifests, you could do (@ (the channel module) custom-emacs) from the manifest, to choose the channel to use modules from.
<eyJhb>Using the guix system install image, I am trying to use the graphical cli installer, and each time I get to the final step with selecting my disk, and have choosen to use a single partition, I am taken back to the main menu, where I can choose the language during the installation process (I have done this 4 times now). Not getting any information when I am doing it.
<cbaines>notmaximed, that looks suspiciously like a locale related problem
<AIM[m]>Like I'm thinking like adding channels where only the packages that I want will be listed in guix install and specification->package....
<cbaines>I'm going to clear up from lunch, but I've finished messing with the bayfront config. Assuming I've done the DNS stuff right, bordeaux.guix.gnu.org should work with IPv6 now, and the other hosted sites should work too once there are DNS records put in place
<rekado_>I used the latest installer yesterday and wasn’t able to install Guix System due to a test suite failure in some package.
<cbaines>civodul, the only place where they would leak in is when the agent on bayfront builds things, and it explicitly tries to just use substitutes from bordeaux.guix.gnu.org, so it's only in cases where things are already in the store that isolation is broken
<cbaines>I'm more getting at that it's not that big of a thing in my mind
<cbaines>I think the rigerous approach here would to be check the nar hashes of store items before builds start, to check they're as you expect
<cbaines>that way the contents of the inputs used in a build would never be in question
<mothacehe>ok so websites are now built in the /srv directory of bayfront. Any volunteer to update bayfront nginx configuration, that's not my cup of tea.
<jackhill>mroh: maybe adding to the leaf applications is the right thing to do. I'm still trying to think it through. It was jut feeling to me like the wrong place if webkitgtk expects the plugins to work properly, it should bring them in without leaf apps needing to worry about it. Also webkitgtk currently has gst-plugins-base as an input, and if we know we're going to want gst-plugins-bad in the end, we can go
<jackhill>ahead and enable GSTREAMER_GL (which upstream recommends that we do)
<civodul>rekado_, mothacehe: i'll reconfigure berlin with the rsync service config i've just pushed to maintenance.git
<jackhill>and it's not the whole browser crash, just the tab, so the UI still works to close it, or change the URL, and it doesn't affect the rest of the application so that's nice at least
<apteryx>rekado_: I successfully built /gnu/store/j416dfcl1qkcd9jhzcgghk0d3ppmdad1-python-matplotlib-3.5.1; anything to check to avoid biopocalypse?
<jackhill>apteryx: interestingly, I couldn't easily find on the gstreamer website guidence on when to use which batch of plugins. I didn't check readme's in the source though.
<jackhill>apteryx: I did ask if there is some official statement from webkitgtk that we could reference, but there isn't. They just say that they expect to have a working gstreamer intallation. Sounds like the divisions (except for maybe -ugly) are more managing difference upstream.
<apteryx>I think gtk shouldn't depend on -ugly ideally, so I wouldn't want to use this as a precedent to have webkitgtk depend on it
<civodul>also, the whole point of plugins is that they can be dynamically loaded
<civodul>so perhaps we can avoid the hard dependency?
<jackhill>apteryx: sorry, I'm not quoting, but I'm not sure what the logging policy is on #webkitgtk:gnome.org. I did talk with Michael Catanzaro, a lead developer of Epiphany, whom I consider to be authoratative.
<apteryx>it can already be avoided (at the cost of a confusing ux experience -- tab crash without informative message)
<jackhill>apteryx: I don't think either of them depend on -ugly, just bad
<jackhill>yeah, just want to make sure we're on the same page
<apteryx>I wonder how it's handled on fedora (do bad plugins contain potentially patent-encumbered codecs? if so they wouldn't be installed out of the box there)
<cybersyn>jackhill: I would just note that the introductory material for gst /does/ advise installing -bad. I think the -bad is bit like racket's unsafe/ffi
<jackhill>apteryx: so, on the flip side: if webkitgtk or browsers didn't wrap -bad then folks would have to install -bad into their profile, potentially polluting the rest of their environment when they only needed bad for the browser.
<jackhill>cybersyn: oh, I missed that! Which introductory material is this?
<jackhill>I wonder if we just need finer-grained packages. Like a package for each plugin, and then we could really only depend on the ones that were needed.
<cybersyn>with the difference being that there the -bad can and should eventually become -good, because you can't have complete memory safety with realtime media (or can you?), whereas with racket its a strict matter
<apteryx>jackhill: that's not really guix's problem; it should be addressed upstream
<jackhill>apteryx: adding the message or remoing the dependency?
<apteryx>the message clearly, but I was answering about the granularity of their plugins system
<apteryx>(if there's something to be improved there)
<cybersyn>jack it's in the "getting gstreamer" (or maybe "installing", I can't remember which they mention") in the introductory tutorials. if you look at the debian requirements, it instructs you to install all of the -good -bad -ugly etc plugins
<jackhill>ah, yes, or fouce. But we might be the only ones who don't want to depend on all of -bad
<civodul>now to see if i can write mcron jobs for bayfront
<jackhill>apteryx: I guess so, I'm not really that familiar with fedora. Perhaps just no one was taking care of their package. IIRC fedora's really invested in flatpak, so all their webkit needs probalby come via that channel.
<eyJhb>So, gussing the FDE didn't work as expected.
<eyJhb>Don't think running it again would help much :/
<apteryx>jackhill: "guix size webkitgtk gst-plugins-good gst-plugins-bad" is 1 GiB bigger than webkitgtk alone
<notmaximed>AIM[m]: did you read ‘6.1 Specifying Additional Channels?
<mothacehe>eyJhb: sorry it didn't work. We recently merged a big update that possibly caused some regressions. Any chance you could open a bug report by exposing the situation in an email sent to firstname.lastname@example.org. You could take a screencopy using your smartphone of the /var/log/messages file too.
<cybersyn>jackhill: I'm not sure of other distros policies, and I could be over generalizing with the comparison of -bad to unsafe/ffi. I've only been getting int gstreamer over the last month, but it seems that -bad is widely used, while not acceptable for mission-critical applications. gstreamer is like the linux of media programming, its used in everything from telescopes in space to medical equipment, so some applications have a really high
<jackhill>apteryx: yep, it looks like I left out the plugins while cleaning up my manifests while testing c-u-f
<jackhill>and it was easier to check how it was on c-u-f v. master on different machines
<cybersyn>i should clarify: i've /used/ gstreamer for years as I program media installations for a living, but always interfaced through a higher level library. but only recently have I started digging into gstreamer itself
<jackhill>I think I'm still inclined to advocate for having epiphany, vimb, etc. wrapped to be able to find the plugins without folks needed to install them into profiles
<jackhill>apteryx, cybersyn: I got permission to quote from the IRC conversation, so I'm going to post that to the ticket for some additional context.
<jackhill>I guess I'll also re-title the ticket since it's not a c-u-f problem
<GNUtoo>I start to understand some weired behavior I got
<GNUtoo>as user, GUILE_LOAD_COMPILED_PATH is set to /run/current-system/profile/lib/guile/3.0/site-ccache:/run/current-system/profile/share/guile/site/3.0
<f1refly>I just discovered that, for a brief moment after logging in, I can use at least the primary selection with selecting text + middle click. it stops working after a few seconds, after which the clipboard does not work anymore
<f1refly>I have no idea what could cause this behaviour
<GNUtoo>So there can be some mismatch in some cases
<GNUtoo>which can cause the "Throw to key `record-abi-mismatch-error' with args `(abi-check "~a: record ABI mismatch; recompilation needed" (#<record-type <origin>>) ())'."
<GNUtoo>If for instance I've an old system (because I didn't do a guix reconfigure) but a recent user guix (because I did guix pull as user) then this is meant to happen as I understand
<GNUtoo>So I've to always keep the user guix and the system guix in sync as I understand, right?
<GNUtoo>So: to maintain a good state I need to (1) don't install guix with guix package -i guix as sudo so, or as user (2) keep the user guix and the system guix in sync with guix pull and sudo guix reconfigure
<GNUtoo>My next question would be (C) what happens if I have 'guix' as package in my system.scm
<GNUtoo>And if I do I'd have a rooling release guix (with guix home and so on), right?
<lfam>GNUtoo: I'm getting distracted by offline stuff so I can't answer in detail. Maybe somebody else can. I would say that you don't need to keep your user's Guix in sync with the system Guix. That's a nice thing about Guix System
<vagrantc>GNUtoo: you need to make sure the guix that "guix pull" builds is the first guix in your path
<vagrantc>GNUtoo: e.g. .config/guix/current/bin should come before anything else...
<attila_lendvai>notmaximed, i have some test code, much like etc/system-tests.scm, and i've put it in a module in another repo. it's in a half-baked state, and to my surprised calling specification->manifest ends up loading it and evaluating its toplevel forms (that print something).
<attila_lendvai>also, specification->manifest is... well. not very fast. i'll look into that.
<apteryx>how else could it work? it has to scan for the available packages before it can map labels to packages, no?
<attila_lendvai>another surprise is that defining two packages with the same name and version doesn't yield an error
<notmaximed>attila_lendvai: That's one of the features of guix, you can do (define my-emacs (package (inherit emacs) modify-some-stuff)) (packages->manifest [...] my-emacs))
<attila_lendvai>apteryx, i can't propose a better solution right now, but this entire setup of using two independent namespaces to keep track of packages feels strange to me (the scheme modules, and the guix package repository based on name+version)
<attila_lendvai>for example, i'm working on the go importer, and it refers to packages by their scheme variables, but it also skips packages that are present in the guix package registry => broken package definitions. i'm experimenting with using specification->package in the inputs now.
<attila_lendvai>notmaximed, i think that could work by a primitive like define-public that would register in the package repository, as opposed to exporting from a symbol from scheme module. and then you could (define my-emacs ...) locally, and keep it isolated from the rest of the codebase.
<singpolyma>In general I think the "package specification" concept just exists to make the cli easier to use
<attila_lendvai>and in that setup the find-package primitive would only find packages that were already imported into scheme
<singpolyma>Normally you don't need package specification of course, and in an ideal world it would go away
<attila_lendvai>singpolyma, without specification->package i couldn't deal with the situation i'm facing (see importer description above)
<singpolyma>attila_lendvai: I'm not sure I understand your problem. The importer outputs code that you are expected to put somewhere that imports any needed modules
<attila_lendvai>well, not specitication->package per se, but the ability to look up packages in the repository (not only through scheme global variables)
<attila_lendvai>singpolyma, that already assumes that the scheme variables of the dependencies were named in a disciplined way to match the algo that produces it in the importer.
<notmaximed>attila_lendvai: The problem with such a primitive, is that it would require loading the relevant package modules before you can specification->package. And then you might as well do specification->package directly
<singpolyma>attila_lendvai: yes. That is something that needs to be true with the importer
<attila_lendvai>...which is not always the case. e.g. the version is not included in the name, or the name is totally ad-hoc by a human.
<attila_lendvai>notmaximed, most probably some form of API would still be needed to load all reachable modules, but i think it should be an explicit call by the user, and never done implicitly
<singpolyma>I guess the importer could maybe find the "real" variable names in case there are differences. Or else the name in guix should be patched to match what the importer produces. Or both
<notmaximed>attila_lendvai: I'm not sure what you are referring to?
<attila_lendvai>singpolyma, another issue: i'm importing two golang apps with --pin-versions into two modules. both have 100+ transitive closure of deps, and the two sets overlap. now, which one should include which? especially when the two apps have not much to do with each other...
<GNUtoo>Kolev: through apache and DNS configuration
<notmaximed>attila_lendvai: Do you mean two go packages with a different version?
<notmaximed>If so, then maybe ignore the version pinning and use the latest version (assuming backwards-compatibility)
<attila_lendvai>notmaximed, let's name things: there are two namespaces now that keep track of packages: 1) global variables in scheme modules, 2) a repository of (cached/loaded) packages maintained by guix.
<Kolev>GNUtoo: is a paste service actually runnimg there ?
<notmaximed>If there are API-incompatibilities, then I suppose it should be possible to include multiple major versions in guix.
<singpolyma>attila_lendvai: if the two apps aren't going into guix then I guess neither needs to import the other. If they are going into guix probably they can share a third module or both go in the same module
<Kolev>singpolyma: Is JMP currently running on foreign Guix?
<Kolev>Can Guix do Dart? I want to write a Flutter app.
<attila_lendvai>notmaximed, what i was talking about in the last couple of comments is a hypothetical setup where 1) is never scanned, and only 2) is The Repository. loading a module would result in the defined packages getting registered into 2). and there could be an API to scan 1) and load every package reachable into 2), but it should be an explicit operation, and never called implicitly by the guix package lookup API functions.
<singpolyma>Kolev: Can do anything if you believe hard enough red type enough parens ;)
<attila_lendvai>lfam, that's what i'm doing, but there still are a lot of overlaps between the two apps
<notmaximed>Anyway, Guix doesn't use specification->package anywhere itself (with a few exceptions, e.g. in the guix pull code and in the CLI)
<bdju>the emails to bug-guix with [BUG] in the name don't seem to open in my mail client. very odd. two different issue #s and from different people or else I was gonna blame the sender
<attila_lendvai>notmaximed, but i cannot not use it if i want to produce an importer that is reliably producing package definitions that can be loaded without human editing. and i don't want to hand-edit 100+ packages at every new release of an app that i ultimately want to compile on guix so that it reproduces the officially signed binary release...
<attila_lendvai>notmaximed, i guess my short message is this: using the scheme module namespace for keeping track of packages brings with itself constraints that i'm hitting right now
<bdju>oh, I see there are a bunch of emails like that recently. I was still working through ones from earlier
<lfam>Works in Mutt bdju. I guess that aerc is not yet bloated enough to read these messages ;)
<bdju>#52684 has the [BUG] in it but opens. I wonder what's different
<lfam>Give aerc a few years to accumulate cruft... I mean, more features
<notmaximed>attila_lendvai: I suppose you can add a --recursive-even-import-go-packages-already-in-guix-and-import-multiple-versions-like-upstream-wants & dump the entire (go-part of the-) package graph in a single file.
<notmaximed>attila_lendvai: Letting a package-searching procedure depend on what modules are already loaded seems ugly to me?
*attila_lendvai will consider notmaximed's suggested solution while going outside a little
<bdju>singpolyma: agreed about GUI apps, I think the best example of a good GUI is actually emacs since it basically works the same as the TUI version but with added benefits of mouse support and windows being separated by more than just an ascii line
<singpolyma>Mutt it great, it just wish it drew using gtk ant widgets instead of ncurses. But yeah, probably the value to the mutt devs is not there to do that work of course
<singpolyma>bdju: yes. I have mildly considered trying an emacs MUA so I get the guiness for free
<jacereda>I've decided to go all-in with guix and install on a 2013 macbook pro, but the installer won't recognize the wifi card, even if it says it should (bcm43xx). It shows 'Missing Free firmware (non-free firmware loading is disabled)' and 'Direct firmware load for /*(DEBLOBBED)*/ failed with error -2'. Any idea?
<notmaximed>The eventual goal was to reproduce the official binary of go-ethereum, to prevent ‘financial loss due to miscompilation’, I think?
<notmaximed>That seems sound to me from a ‘diverse double-compiling’ perspective (though that's actually a slightly different thing).
<attila_lendvai>notmaximed, i would be the same thing that is currently in guix, based on fold-module-public-variables, but invoked by the user as needed, not the system implicitly. i didn't think through what its API would look like.
<notmaximed>(about the financial loss thing) Why are go packages special here? Because if my browser has some security bug (caused by a compilation mistake or whatever), then when I log in into the e-banking system, then an attacker could use that security bug to steal money or whatever.
<lfam>It's kind of sad for Guix to become a target of supply chain attacks from cryptocurrency thieves, but to not be supported by the cryptocurrency projects themselves?
<attila_lendvai>lfam, it's not probable, but i still don't want to be the guy who is reading the email account that is in the commit... :)
<vagrantc>jacereda: sounds like it won't be able to support your network card without non-free firmware, and guix does not support non-free firmwares
<lfam>notmaximed: They could do that, but at least in the US, you'd get your money back
<lfam>Consumers are protected from that type of fraud by law
<jacereda>vagrantc: it's one of the 2 cards mentioned in the supported devices
<notmaximed>lfam: right (also in the EU, I presume, though it's still irritating if someone tries to pull something like that, and not everyone would notice ...)
<lfam>Yeah, it's definitely disruptive. But your money will be returned to you
<attila_lendvai>notmaximed, oh, i see. the 'invoked by the system' thing is in my head because i (wrongly) assumed that specification->package is more than just a random helper for CLI work.
<vagrantc>maybe a bug in linux-libre ... e.g. they removed support for loading firmware even though there is a free firmware available?
<lfam>And I agree, my objection to the entire enterprise is not specific to Go.
<jacereda>vagrantc: looks like that's the reason, I don't know how to proceed
<notmaximed>Then I presume the difference between the financial loss in ‘go package/browser’, is that the go package is ethereum, a cryptocurrency, where reverting fraudulent transactions is way more difficult
<attila_lendvai>lfam, i have already created packages that use the upstream binary, but it won't be accepted in guix, but i want my swarm service in guix... => i need a source based package (or i need to convince the maintainers, but i didn't even attempt that).
<jacereda>the manual: One of the main areas where free drivers or firmware are lacking is WiFi devices. WiFi devices known to work include those using Atheros chips (AR9271 and AR7010), which corresponds to the ‘ath9k’ Linux-libre driver, and those using Broadcom/AirForce chips (BCM43xx with Wireless-Core Revision 5), which corresponds to the ‘b43-open’ Linux-libre driver. Free firmware exists for
<jacereda>both and is available out-of-the-box on Guix System, as part of ‘%base-firmware’ (*note‘firmware’: operating-system Reference.).
<notmaximed>lfam: If they are caught, then even if the cryptomoney is inaccessible, the fraudster could be forced to pay back the victim out of their bank account (following the exchange rates), I presume? And ‘deurwaarders’ are a thing. (not sure about the translation). Anyway, let's stop because off-topic. (#guix-offtopic if you want to continue)
<rekado_>here’s the strace error I get when running “guix deploy” on berlin:
<rekado_>that’s building /gnu/store/35wj4qpy4vlq43x3m4bvjfn9y956f27a-strace-5.13.drv
<vagrantc>wow, did #linux-libre not move off of freenode?
<attila_lendvai>lfam, notmaximed, one possible way you can lose money is if you stake your crypto in a Proof of Stake setup (as opposed to the old Proof of Work blockchains), then you must adhere to the consensus protocol, otherwise you are punished from your staked money. using a different dependency can result in your executable not behaving as expected your peers, and you may get punished.
<notmaximed>attila_lendvai: Ignoring the DDC-style reproducibility test, is using the exact same version of _every_ package required? Because the dependency go-isatty doesn't seem relevant to the consensus protocol.
<lfam>jacereda: I don't see the strings 'firmware' or 'b43' in gnu/system/install.scm
<jacereda>lfam: installation-os doesn't have a kernel argument, so I guess that means "use the default kernel"
<lfam>Right, but is there something that leads you to think that the default kernel comes with this particular firmware package?
<lfam>The firmware you need is part of %base-firmware, but I'm not sure that %base-firmware is used by the installation image
<lfam>It's available by default on Guix System, but the installation image may not use the defaults
<vagrantc>anyone up for a campaign to fix typos and various synopsis,description issues that guix lint finds before the next guix release?
<cybersyn>lfam: I agree, if major cryptocurrency companies are building with guix, they should at the very least help the project out as it gets weighed down by the side effects of their industry. its all pro-FLOSS until it comes to paying free software developers
<vagrantc>it would be nice to at least tidy all that up before release... because if not then, when? :)
<jacereda>I've mounted the iso and it contains the b43-open firmware inside the firmware package, so I guess it's a problem with the kernel sources, the deblobbing process must have messed the filename
<vagrantc>seems like typos and other description/sysnopsis stuff are relatively low-hanging fruit
<notmaximed>Seems like I was disconnected and a few messages didn't come through:
<notmaximed>attila_lendvai: Ignoring the DDC-style reproducibility test, is using the exact same version of _every_ package required? Because the dependency go-isatty doesn't seem relevant to the consensus protocol.
<notmaximed>And go-libpcsclite doesn't seem very relevant either?
<vagrantc>jacereda: looking at the source from guix build --source linux-libre ... it looks like the codepath that would load b43-open is not mangled with the DEBLOBBED patches, so i'm guessing you have an unsupported chipset
<jackhill>ok, thanks! We could probably get help from upstream on testing.
<jackhill>apteryx: so it sounds like the path forword might be do expand on the description as you propose, enable GSTREAMER_GL, and then wrap the browsers with additional plugins, perhaps using lfam's suggestion of gst-plugins/selection. Does that sound right to you?
<apteryx>the first 2 will be on the version-1.4.0 branch (commited locally) -- about wrapping browsers, I'm on the fence about it
<nckx>I'm flailing around with possible solutions to <https://issues.guix.gnu.org/52667>. Is there any possible (not even necessarily sane: I want to know my options) of capturing this-operating-system's kernel field when expanding %base-initrd-modules?
<jackhill>apteryx: cool, thank you! My thoughts are that browsers should work out of the box, especially if we can do it easily, and perhaps minimally with gst-plugins/selection. How do we come to a consensus?
<apteryx>you could send an email to start a discussion around it on guix-devel
<apteryx>it usually receives more attention than guix-patches or guix-bugs
<jackhill>apteryx: ok, sounds good to me, I'll do that. Well, first I guess I'll try to get a proof-of-concept working to discuss :)
<KE0VVT>Will Borg Backup follow symlinks all the way to /gnu/store/? O_O