IRC channel logs
2024-10-24.log
back to list of logs
<eikcaz>futurile: guix.social has videos of patch reviews. Why would that not make sense on the patch review page? <futurile>eikcaz: well first becaue the page is becoming absolutely massiiiiiiiiiive at this point :-) <futurile>ah I must have an account for a "certain number of days" - that's precise isn't it <eikcaz>[: because Guix doesn't know how to deal with the backlog of pull requests. Synapse (matrix homeserver) has been broken for getting close to two years with a working patch waiting to merge. Though, if it's a freedom bug, mentioning it here might get it higher priority... <futurile>eikcaz: why don't you apply to be a committer? Then you could test it and apply it ... <ekaitz>futurile: that's the wrong person <ekaitz>otoh, i did ask for commit access, but my request was lost in the air <ekaitz>futurile: for future reference my name in basque means "storm" in your language <futurile>OMG! I have some sort of language blindness over your name! <meatys>Hello! I’m trying to install Guix on a new computer but I’m having issues with network connection, I get “cannot connect to the internet” even though e.g. ‘ping gnu.org’ works fine <meaty>but yes my computer cannot connect to the internet, even over ethernet <meaty>despite being able to ping gnu.org and other sites <lfam>'nss-certs' is now included by default in '%base-packages' <meaty>aha, could that be it? there was a complaint about ssl certs when I tried to guix pull once <meaty>I'm building a more recent installer now <meaty>they should cut a new release fosho <chipb>lfam: yikes, the commonly accepted ca certs not being included in base seems like a very odd choice. what did it take to get that fixed? <lfam>The base is extremely minimal. When Guix was started, TLS / SSL was not ubiquitous or expected like it is today <lfam>The certificates were seen as something optional that you could add <reepca>there is also a certain nice transparency to having the root of trust be explicitly configured (I find that most end users of TLS aren't even aware that there is a root of trust) <chipb>ah, doesn't seem like there was much dissent. <chipb>reepca: yeah, I can appreciate that it draws attention to its existence. but in practice it seems like it's another gotcha that someone is basically expected to copy/paste into their config. <apteryx>first time I've seen this error: suspicious ownership or permission on `/gnu/store/0d3mnkyngpynv5lm16kzx88s6dixww64-torcs-1.3.7'; rejecting this build output <reepca>most likely that means an output is world-or-group-writable <apteryx>should this matter? the store is read-only anyway <theesm1>am currently hacking on packaging the imapd part of cyrus & building a shepherd service around it as I prefer it to dovecots imapd; its adminfacing tooling is written mostly in perl and wants to have libs included in the repo under perl/{imap,annotator,sieve} present. Does anyone know what the right approach is to package those? make a separate cyrus-imapd-perl package? having a cyrus-imapd:lib output? <cow_2001>i have a strange situation. i want to use a package's executable output to create another package's output, but the second package is not dependent on any source, just the first already defined package. <cow_2001>the first package definition downloads a git commit, then compiles, then outputs an executable. the second package definition has the first package as native input, and then it generates another output <cow_2001>how do i define a package that is not dependent on anything but native-input? <cow_2001>okay, it's in (guix) Defining Package Variants <cow_2001>here’s how you would define a variant for version 2.2 (released in 2006, it’s vintage!) <cow_2001>no, that is not right. i still want the original package definition as an input to the second one <futurile>theesm1: are they all libs that are part of the package, not vendored ones? <Rutherther>cow_2001: But if you want to download something, your solution is not going to work. You need to make it a fixed-output derivation if you want to access the internet. See git-fetch / url-fetch as reference <cow_2001>it's entirely dependent on another package, nothing outside <Rutherther>cow_2001 Okay, I was referring to you saying "downloads a git commit" <cow_2001>the first package is git-fetch, the second package only depends on the first <Rutherther>cow_2001 that sounds more like you actually want to download something, and then your derivation will need to be a fod <cow_2001>okay, let's be specific - i want to write package definitions for ribbit <cow_2001>my plan is to write one package that'll build the repl compiler and many other packages for each repl target <cow_2001>so the first is named ribbit, then the dependent packages are ribbit-javascript, ribbit-python, etc. <cow_2001>hmm... unpack phase fails because source is now #f <Rutherther>Yeah, remove it, or use build system without it, like trivial build system <cow_2001>Rutherther: so trivial-build-system needs a #:builder, which is a build-expression, like you feed into build-expression->derivation <cow_2001>the derivation part says build-expression->derivation is obsolete and one should use gexp->derivation instead <cow_2001>sorry, not obsolete. the word used is deprecated <Rutherther>cow_2001: yes, you give gexp to trivial build system builder argument <cow_2001>okay, this worked when i tried to translate the original build-expression into a gexp: #~(begin (mkdir #$output) (with-output-to-file (string-append #$output "/test") (lambda () (write '(hello guix)))) #t) <cow_2001>new problem! when i (use-modules (guix build utils)) inside the gexp, i get: no code for module (guix build utils) <ds-ac>cow_2001: You can use `with-imported-modules' for this. There is an example in `(guix)G-Expressions' that uses (guix build utils) if you want. <Rutherther>cow_2001 trivial build system has modules argument for this <theesm1>futurile: yes, they're part of the package; what's challenging is, that they seem to use a different buildsystem, cyrus-imapd can be build with gnu-build-system <theesm1>but the libraries have to use perl-build-system as far as I can tell <futurile>theesm1: if they're part of the package, and can't be used by another project I'd keep them inside. You'll have to import other build systems (modules) to build it anyway. So that's probably going to be quite complex anyway. You can always go back and break them out later ... <chloris>I am checking which IRC client is useful <dariqq>civodul: thanks for reviewing. There are probably more things that implicitly assume an order in activation scripts ... <dariqq>Also apologies for bothering you with so many things lately <civodul>dariqq: np, i’m glad you were able to fix it <civodul>probably there are bits of activation that we could move to shepherd services <civodul>a service S could depend on S-setup, a one-shot service that would perform (some of) what’s currently done during activation <civodul>dariqq: not possible because the key is generated on the fly <civodul>this one is a bit complex, i wish it could be simpler <podiki>a random check of libreoffice for aarch64 shows no substitute <podiki>at least berlin coverage % is the same as master, so i'm guessing for i686/x86_64 coverage is good <dariqq>This then depends on the order of guix-service and virtual-build-machine-service in the services field (append %base-service (list ....) vs (append (list ....) %base-services) to properly authorise the guest which at minimum should be documented somewhere <dariqq>Thankfully most actications are self contained and only create and set ownership on directories <civodul>aarch64 is probably much, much lower <podiki>yeah, that's why i'm assuming it is i686/x86_64 which is all build on berlin <podiki>usually bordeaux has the much better coverage on aarch64 for instance <podiki>do we (or someone, not me) have the ability to cancel all the old evaluations except the most recent few for mesa-updates? <podiki>i don't know if there is just a long queue of the previous updates/rebases/etc on bordeaux, though they have been canceled or finished on berlin <civodul>i don’t know how to do that on bordeaux <podiki>maybe we should have the cuirass web interface/access like for ci.guix? <civodul>i’m sure cbaines would welcome that :-) <cbaines>indeed, any patches for bffe and the build coordinator are very welcome <cbaines>I've also been trying to speed up data.qa.guix.gnu.org processing revisions, it's currently got a backlog of very expensive branches to process though and there's no prioritisation so mesa-updates isn't prioritised unfortunately <cbaines>it looks like processing of mesa-updates did start a few hours ago, so hopefully it should be finished late today or by tomorrow <cow_2001>i don't know if it makes sense to send the two ribbit package definitions to debbugs.gnu.org, but maybe it is? <cricri>Hi there, I am looking for a manual on how to split guix operating system configurations. In my case, I want to apply almost the same configuration with slight changes on different hardware. Do you use reusable scheme modules or are there other approaches? Thanks! <ieure>I want to build on this a bit more, writing functions which take an operating-system and return one modified in some way -- but this code is the starting place for something like that. <ieure>Same general approach for Guix Home. <cricri>Cool, I will have a look into it in a bit. Thanks a lot! <aguadopd>Hi! I’m using Guix as a package manager in a foreign distro (OpenSUSE Tumbleweed, using KDE Plasma 6). I want to manage my audio/music programs and plugins with Guix. I’ve installed many of them under a specific profile that I source on demand. Programs run and can see the plugins, but cannot see my system’s Pipewire/JACK. Any hints? <Rutherther>aguadopd: so you just run those programs from shell / launcher? <aguadopd>Rutherther: as an example, I run Ardour from a terminal, after sourcing the profile. I can see all the plugins after it starts. However, it cannot see Pipewire/JACK running. If I instead run the system's Ardour (`/usr/bin/ardour8`), that one does see Pipewire/JACK running, and connects. <Rutherther>aguadopd okay and what is the error specifically? <bavier>still working on upgrading our kodi package. I can see why this maybe hasn't happened in a while; upstream keep making dependencies harder. <dthompson>I had a memory of working on that package once so I checked and yep... 2015. I guess I wrote the initial package. <bavier>dthompson, nice. They almost made it possible to use system libdvdnav et al, but not quite. And added a bunch of cmake stuff to fetch precompiled .jars, ugh. <nckhexen>cbaines: Is there a Web UI available, even if rough? (One of your readme's mentioned 'continue working on' or so, IIRC, but I might read too much into that.) <nckhexen>Available as in code, not as in running. <nckhexen>Or is the idea to use QA as the Web interface... <gnucode>also friends, you are all invited to a gaming on Hurd party! <futurile>cricri: did you see the systemcrafters video and content - there was a video and examples on splitting configuration recently. <gnucode>At the moment a lot of good games are not working so well. <gnucode>some kind of GLX error, but crawl works!