IRC channel logs

<mirai>How does this #:search-path argument work for build-systems

<mirai>setting it to some value unfortunately erases the typical GUIX_LOCPATH, ACLOCAL_PATH and other search-paths

<mirai>is there no way to append a search-path specification into #:search-paths?

<makx>maybe this is an insanely stupid question, but, I am trying to define my own image and want to add a home partition; the initializer for this partition doesn't need to do anything, but the default seems to be "put root filesystem here";

<makx>how do I make an empyt initializer?

<Guest34>Isn't something like root and file permissions useless on a computer that is used by only one person? Does Hurd have something like a root user as well?

<mirai>Guest34: not really, suppose you have a program that due to some programming mistake does a rm -rf /usr

<mirai>or you're opening some document-sent-by-asshole.docx that triggers some malicious exploit and starts siphoning the memory contents from every program (including $browser where you're doing some banking operations)

<mirai>clearly you'll want some way to segregate how the programs interact, even if you're the only user of the computer

<Guest34>Okay so for the first message, this would be handled by file permissions I assume. Not by a special user. The second is something else isn't it? That is memory address space

<mirai>memory space is one possible avenue from many others

<Guest34>Basically my main question would be, are those things invented for pcs system or implementations from mainframe times and compatability

<mirai>said exploit could be a webserver that starts reading the contents from $HOME/Documents (where it has no business)

<mirai>I'd say it originally was about the latter

<mirai>that's why things like selinux got invented

<Guest34>Ah okay, good to know. I read that hurd uses the hurd filesystem. This is not something like ext or btrfs but more like a translation layer for an actual filesystem or did I understood that wrong?

<bjc>hurd uses ext2. the translators are a layer on top of that

<Guest34>Ah okay, never got that

<gcarlos>how can I list dependencies not explicitly installed for a given profile?

<nckx>guix size $(realpath $GUIX_PROFILE)

<nikolar>Hello

<nikolar>Is it possible to install guix without root

<nckx>Greeting.

<nikolar>Something like nix's single user installation

<nikolar>Hello nckx

<nckx>It might still be possible, but you're very much in dragon territory. Here's an unofficial guide: <https://github.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org> (note the age).

<nckx>Unless you're already familiar with Guix to deal with any new issues, I recommend using a VM or so instead.

<nckx>Single-user Nix seems to be official. This very much is not.

<nikolar>Thanks

<nikolar>I'll definitely try it in a VM

<nikolar>Are there potentially any plans to have an official single user guix install

<nckx>None that I'm aware, but if someone contributes one and it meets some standards it could well be merged.

<nikolar>Alright

<nikolar>Another thing to add to the "research later" list

<gcarlos>nckx: and if I would like to see which specific out of that package is installed?

<nckx>gcarlos: Outputs are listed separately.

<nckx>Look for things not ending in [0-9] and you'll start seeing them.

<nckx>There's no such thing as a ‘package’ at this level.

<nckx>(Nor, IMO, ‘installed’, but that's getting philosophical.)

<gcarlos>maybe I'm just too dumb but where specificallly I should look on things not ending with numbers?

<nckx>In the first column, with store items.

<nckx>For (random) example, I have /gnu/store/r14adwd69sns9zyhkrxlspmxbs3wiswy-hplip-minimal-3.23.5-ppd .

<gcarlos>so this meas you have the output ppd of hplip-minimal installed?

<nckx>That's ‘clearly’ the :ppd output once you know how Guix names things. It's not unambiguous—you could create an ‘hplip-minimal’ package with version ‘3.23.5-ppd’ and it would look exactly the same, but it's a very good heuristic.

<gcarlos>s/meas/means/

<gcarlos>oh, sure

<gcarlos>so thx :)

<Guest28>How is decided if something should be a system service or a home service?

<bjc>context? but you don't necessarily have to pick anymore. ludo added a system → home service transformer

<bjc>not that you ever *had* to pick, but now you don't have to write it twice

<nckx>gcarlos: There might be a way to get this in Guile code but (1) you won't be able to run it on arbitrary existing profiles, only ones that your code builds at run time (2) it probably won't be simple (3) I'm not sure if there's a place where all packages are present as package objects at the same time.

<nckx>So, if your use case is anything close to idle curiosity, I'd say stick with ‘guix size’.

<nckx>Also, ‘why my profile so chonky what to remove’.

<nckx>Related: guix graph.

<nckx>ACTION AFK.

<Guest28>bjc: Thanks. It was just a generally question. Does that mean a home service can also be used as a system service?

<mirai>Guest28: I don't think so

<mirai>they're considered to be of different types iirc

<mirai>you can attempt to “cast” a system into a home one as bjc said

<mirai>as to “how is decided…”, its whatever the author cooked up and found it adequate to use

<mirai>you may think that something like “rss2email” or “syncthing” fits more as a home-service

<mirai>but someone else might just argue that for their headless needs, a system “syncthing” service makes more sense (to them)

<bjc>i think a lot of the time it's decided by whatever the person who submits the patch needs, tbh

<mirai>so there's no firm criteria

<Guest28>"but someone else might just argue that for their headless needs, a system “syncthing” service makes more sense (to them)" basically my case, I wish that znc would be a system service instead of a home service. What exactly is the difference? It's like with packages so scope/permissions?

<Guest28>can't they be universal and ultimately be defined as system if they are in a (operating-system ...) definition or (home ...) definition

<bjc>no, home services are strictly for home definitions. system services are, likewise, only for system definitions

<mirai>in their current state, no

<mirai>but nothing is really set in stone, so maybe in some unspecified time things might change, provided a better design is brought forth

<mirai>I've my list of service grievances I'd like to (constructively) air someday as well :)

<aarcov>When sending in a `git format-patch` instead of `git send-email`, should we strip out the Message-ID contents or leave them as they include the added commit ID and commiter details?

<aarcov>I am currently pasting the patch contents into the body of an email

<mirai>aarcov: don't do that

<aarcov>don't strip them or don't send the patch that way?

<aarcov>just attach the patch file?

<mirai>your mail client is likely to mangle the patch into something that can't be applied

<apteryx>the manuals are not being built because: error: texlive-texinfo: unbound variable

<apteryx>c.f. /var/log/mcron.log on berlin

<mirai>best to use git send-email

<apteryx>aarcov: I second 'git send-email'. It'll also CC relevant team members automatically for you.

<aarcov>hmm, wish there was a slightly different method, or that I could have it link into claws for me

<apteryx>but if you must, a 'git format-patch' patch as an attachment is also accepted

<apteryx>but will have less visibility

<aarcov>I guess I'll look for a guide on setting send-email up

<mirai>apteryx: does git send-email still auto apply the X-Debbugs-CC header?

<nckx>apteryx: Yeah, I noticed it too, on it.

<nckx>The guix package needs to be updated.

<apteryx>another gem: guix gc: error: build daemon out of memory

<apteryx>and the storage usage has been bubbling up

<apteryx>mirai: yes

<mirai>its somewhat problematic since if I manually add a X-Debbugs-CC to the email the script will add yet another X-Debbugs-CC line

<mirai>and debbugs ends up ignoring one of the lines

<apteryx>you can use 'mumi send' for this use case

<apteryx>it'll merge the X-Debbugs-CC for you

<aarcov>hmm, so the send-email plugin in guix errors (installed with `guix install git:send-email`; I get this error: https://paste.debian.net/1289099/

<nckx>apteryx: On bayfront?

<nckx>(guix gc)

<apteryx>mirai: also, understanding multiple X-Debbugs-CC was fixed upstream, but GNU Debbugs doesn't use that

<apteryx>nckx: on berlin

<nckx>What fun.

<apteryx>the source says that happens when 'performOp' in the C++ daemon throws a std::bad_alloc exception

<apteryx>that means dynamic allocation failed?

<apteryx>with 147 GiB of RAM available, one wonders how that might happen

<nckx>It's legit, not some confused code: [Wed Aug 16 03:19:31 2023] __vm_enough_memory: pid: 34399, comm: guix-daemon, not enough memory for the allocation

<apteryx>wow; how much is it trying to allocate!

<apteryx>aarcov: I think you only need to run it in a 'guix shell -D guix' environment

<apteryx>did you build the source tree already?

<aarcov>huh, I did that and added ./pre-inst-env and it worked

<aarcov>For new folks, it might be nice to add that you need that added to the git call as well

<apteryx>I never put ./pre-inst-env in front of 'git send-email' and it works

<aarcov>the docs make it sound like you don't need it: https://guix.gnu.org/manual/en/html_node/Sending-a-Patch-Series.html

<aarcov>I guess I'll see if it goes through now

<aarcov>I be confused

<apteryx>aarcov: I think it's because I'm on Guix System

<apteryx>and there's a Guix in the system profile, which is on my GUILE_LOAD_PATH

<apteryx>e.g.: /run/current-system/profile/share/guile/site/3.0 is on my GUILE_LOAD_PATH and it contains /run/current-system/profile/share/guile/site/3.0/guix/ui.scm

<aarcov>ahhhhhh, I'm on a foreign install at the moment, I should try this again when on my desktop with Guix Install

<nckx>Guix is nostalgic for the classics: https://paste.debian.net/plainh/c729f6b2

<aarcov>I think it went through with that, how long till it shows up on: https://issues.guix.gnu.org/recent ?

<nckx>Usually, not this long, but sometimes Savannah goes out for a snack.

<apteryx>nckx: haha!

<apteryx>failed hard: success!

<nckx>s/Savannah/eggs/, which would have been a way better pun.

<aarcov>lol

<aarcov>Looks like I'll be checking in the morning then, if it doesn't show up, I might need to change something in my config (although the output reported success (Result: 250) and I got my CC'd copy)

<apteryx>aarcov: normally it's refreshed every 15 minutes, I think

<aarcov>sweet, maybe I'll do another quick check in a bit

<apteryx>are the 504 errors on substitutes because berlin's anti-DDoS mechanism?

<nckx>No, the mail hasn't arrived yet.

<apteryx>ah! it's probably moderated?

<apteryx>if it's a first submission

<nckx>Also nope.

<apteryx>hm.

<apteryx>then it's tubing for longer than expected

<nckx>Suspect snacks are involved.

<nckx>Please do go to bed if you crave rest.

<apteryx>is this a legit failure or something screwy on our build farm? https://ci.guix.gnu.org/build/1824223/log/raw

<apteryx>erring toward legit. reported as https://github.com/ueno/libskk/issues/83

<nckx>Who knows: https://hostux.social/@fsfstatus/110896517569620091

<Guest28>how much ram does berlin have?

<nckx>192 GiB.

<Guest28>the vm or the server itself?

<nckx>There is no VM.

<nckx>We don't use VMs.

<Guest28>Ah. Read something with VMs and thought it is this server. Is this an actual server from Guix that is just hosted in that dc or is it from the dc itself and they sponsor it?

<nckx>So ‘berlin’ is the head node of a collection of some 25 machines both donated and hosted by the MDC, a research institute in Berlin, where a long-time contributor works.

<nckx>Sometimes we call the whole farm ‘berlin’.

<nckx>But in this case, it's that one machine.

<nckx>For completeness: the MDC isn't a commercial data centre/hosting provider, and their IT department's restrictive and rather ‘corporate’ network policy is becoming a bit of a problem for us.

<aarcov>sweet ya'll, patch was received, assuming I did everything right, I'll try to send some more later

<aarcov>and with that, I'm off for the night

<Guest28>Are those 25 machines clustered to one big machine or how do you balance the traffic? If you say "farm", those machines are only used for building x86_64 substitutes?

<nckx>'night aarcov!

<nckx>Guest28: Yes and yes.

<nckx>The head node isn't that much bigger.

<nckx>It uses ‘guix offload’ technology to send builds to the builders.

<nckx>All machines at the MDC are x86_64 (it's a single rack IIRC).

<nckx>There are a few other architectures hooked up to berlin, though: https://ci.guix.gnu.org/workers (hydra-guix-* are the x86_64 machines).

<nckx>These are hosted and sometimes purchased by friendly folks at home.

<nckx>The POWER9 ones are VMs (but on POWER9). The rest is all native.

<nckx>(I don't know why I always say 25; it's 30.)

<nckx>ACTION → 😴💤 Good night!

<iyzsong>goodbye~

<apteryx>nckx: good night

<Guest28>nckx: Uhh POWER. IBM machines ( I assume some IBM POWER system?). Do you know about reliability? I heard that IBMs are tanks and HP is the worst. Dell is kinda okayish appearantly. If that dc buys new ones and wants to get rid of some old machines, instead of throwing them away I would take one :D .

<Guest28>nckx: Good night. Going to bed as well, nearly 6am...

<apteryx>o/

<PotentialUser-35>Hi, I have just installed guix on one of my computers, but I did not enable the certificate service during installation. Can I enable it now?

<Altadil>PotentialUser-35: Hi, I’m sure it can be done, but don’t know exactly how. This is the part of the manual with all the services : https://guix.gnu.org/en/manual/devel/en/html_node/Services.html

<Altadil>If you remember it’s name, you should be able to find it here.

<PotentialUser-35>Altadil, thanks. I am pretty sure it had the name mozilla in it

<PotentialUser-35>But I can't find that on this page. I will see if I can figure out what the name was

<PotentialUser-35>Ah, I think I found it. nss-certs. https://guix.gnu.org/manual/en/html_node/X_002e509-Certificates.html

<Altadil>PotentialUser-35: yes, that rings a bell ! It’s a package, not a service, so you need to add it to the package field of your operating-system declaration

<PotentialUser-35>I have guix system with i3, but I am not sure how to configure autologin. The reference materials seem to talk about gnome-desktop-service or tty login, but I am not sure either of those is correct. I am just looking to autologin my user into i3. Any ideas? Thanks

<jpoiret>PotentialUser-35: auto login through which DM/greeter?

<PotentialUser-60>I tried to install triquel through net installer it showed console desktop environment. Can anyone please explain about console desktop environment I have never heard about it and i could not find any link/ webpage about it?

<jpoiret>PotentialUser-60: this is #guix, not #trisquel

<PotentialUser-60>Sorry

<apteryx>PotentialUser-60: no worries

<apteryx>nckx: fyi, 'herd restart guix-daemon' appears to have fixed the out of memory condition

<apteryx>(on berlin)

<ardraidi>Hello Guix

<ardraidi>I have a question about licenses of a package

<ardraidi>It's supposed all the licenses in all the files in the package, right? For example, if I grep the repo and find 5 licenses or so, they're all supposed to be mentioned.

<next4th>ardraidi: i want to ask it too, yes i think all should be mentioned.

<apteryx>ardraidi: I like to think of the license field as the license of the whole project as it's distributed in Guix; for example if most of the project is GPLv3+ but there are some files marked as BSD-2 or other lesser licenses, then the effective license is GPLv3+.

<apteryx>(it could have also been a list of licenses with the detail in comments, but that's uninteresting and potentially misleading in the Guix UI: 'guix show $package' would show all licenses, I think)

<ardraidi>apteryx: Interesting take. I thought that might be the case, but I guess there could be legal implications, which I know nothing about.

<ardraidi>For example, the files might be considered effectively re-licensed. Not sure if that's a thing. I remember reading in passing that the Linux kernel has things with licenses other than GPLv2

<nckx>Morning, Guix.

<ardraidi>When packaging #64387 I got the following list, which seemed scary.

<ardraidi>nckx: Morning, nckx.

<ardraidi> (license (list license:asl2.0 license:bsd-3 license:cc-by3.0 license:expat license:gpl2+ license:lgpl2.0 license:lgpl2.0+ license:public-domain license:silofl1.1 license:zlib))))

<nckx>ACTION idly wonders what (combined-work license:gpl2+ license:lgpl2.0) evaluates to.

<ardraidi>ACTION wonders what (combined-work ...) is.

<nckx>An imaginary procedure to calculate which licence terms ‘win’, if any. ☺

<nckx>Not a serious suggestion.

<nckx>As cool as a Guix licence DSL would be.

<efraim>I've thought about it on and off for a few years, to keep some mapping about which licenses conflict with others and which subsume (is that the right word?) other ones to return the One True License™ of a package, or if it is FORBIDDEN

<efraim>and then I decided that it was a terrible idea

<efraim>well, not terrible, but very involved, so probably good, but full time work in itself

<efraim>s/so probably good/probably actually good/

<efraim>adding conditionals in my bash aliases turned out to be more time consuming than expected

<nckx>It's pretty ‘how hard could this be?’ techbro if you get it wrong.

<nckx>However, something akin to a linter that warns about things that are probably bad is a good idea that didn't occur to me.

<civodul>ACTION thinks a "license calculus" of sorts is a bad idea

<civodul>because it's all subject to interpretation

<nckx>ACTION nods.

<nckx>Plus, having to smuggle in a state-of-the-current-legal-framework-worldwide variable isn't very functional. /s

<civodul>heh

<civodul>efraim: hey! thoughts on this libflame update? https://issues.guix.gnu.org/65227

<efraim>i'll take a look at it in a few minutes

<efraim>we should probably add aliases to the end of the bashrc file, not to the top of it

<efraim>or we should place the guix-defaults? output at the top

<jab>efraim, nckx guix shell gtk:bin -- sh -c 'GSK_RENDERER=cairo gtk4-demo' worked for me.

<efraim>jab: I added GSK_RENDERER=cairo to my .bash_profile on my pinebook pro

<efraim>civodul: I'm testing it on a few architectures to make sure it builds

<efraim>civodul: it already has lapack as an input so it'll be hard to add it as an input to lapack also :)

<efraim>i'm also curious if there are bundled libraries, one of the folders is src/map/common/lapacksrc

<ardraidi>So (combined-work ...) is basically a codified lawyer? I guess even GuixGPT would struggle with that. However, I think a feature in 'guix lint' that detects known license texts in the source code and shows messages about them might be useful.

<nckx>That would involve building.

<nckx>ardraidi: My musing above was about that specific combination of those 2 licences; not a suggestion/request for implementation.

<nckx>I still don't understand why Guix needs to fail when two commands need to modify the same profile, rather than simply waiting in an orderly queue. It's less deterministic, not more.

<civodul>efraim: we'd make it an input of a lapack variant, not of the current 'lapack' :-)

<civodul>and yes, it seems to bundle quite a lot of things

<ardraidi>nckx: I was half-joking, half thinking out loud. I hope I didn't offend anyone.

<ardraidi>Those licenses together are interesting, though.

<gcarlos>why do we have some -headers packages instead of just having them on a specific output? for example, instead of have linux-libre-headers we have linux-libre:headers

<jpoiret>gcarlos: because of technical reasons, we need the headers to build the c toolchain

<jpoiret>and without the c toolchain, you can't build the kernel

<jpoiret>although there's probably a way to use only gcc without the glibc at all to build Linux, but we don't build it that way right now

<zimoun>hi!

<sneek>zimoun, you have 1 message!

<sneek>zimoun, efraim says: I'm looking at the slow julia thing, what did you use to get your time comparisons?

<zimoun>efraim: I am back after long holdiays. I do not remember Julia time comparisons. Is the slowness issue fixed? Or not yet?

<apteryx>zimoun: welcome back!

<nckx>Welcome back!

<gcarlos>jpoiret: and what about the headers don't needed to build gcc-toolchain? We keep them as header packages just for consistency?

<jpoiret>I guess so yes

<gcarlos>nice

<jpoiret>since we have a way to turn a linux version into a header package, it's simpler to just re-use that

<efraim>laflame needs a newer config.guess for some of the tests it looks like

<efraim>build phase was no problem on aarch64, riscv64 is still funning

<efraim>zimoun: I have a patch to use openblas-ilp64 (and adjust it to what is used by other distros) but I don't have a way to test it

<razlix77>Hello o/

<razlix77>should something like `(local-file "../../common/config/some.conf")` work?

<razlix77>or is it only possible to use absolute paths

<razlix77>or is it only possible to use absolute paths?

<nckx>Relative work for system configurations, at least, and will be resolved relative to the configuration file, not (getcwd).

<nckx>I wouldn't be totally surprised if you found a spot where it's inconsistent, though.

<civodul>ACTION discovers https://data.qa.guix.gnu.org/jobs/queue

<razlix77>nckx so let's say my git root looks like:

<razlix77>`❯ tree

<razlix77>.

<razlix77>├── common

<razlix77>│ ├── configs

<razlix77>│ │ ├── keepalive-r1d2.conf

<nckx>razlix77: You'll want to use paste.debian.net for looongtexts (over 3-4 lines).

<razlix77>uhm sorry

<nckx>No need.

<razlix77> https://paste.debian.net/1289140/

<gcarlos>where's gcc manual pages?

<nckx>razlix77: I'm not sure where you're getting the second ‘..’. Am I miscounting?

<razlix77>so when I try deploy i get `guix deploy: error: canonicalize-path: No such file or directory: "/home/user/work/project/../../common/config/keepalive-r2d2.conf"`

<razlix77>nckx no you are right but it doesn't mater

<nckx>gcarlos: In the gcc-toolchain package (which is currently installable as ‘gcc’).

<razlix77>it adds the full path :/

<nckx>razlix77: Yeah, Guix channels are one of the context I haven't tried, and which I was referring to above.

<nckx>I use (search-path %load-path "common/configs/…") in my own channels.

<nckx>(Because it's what I tried and it worked, no ideology.)

<razlix77>oh hmm ok let me try

<nckx>As argument to local-file, I mean.

<razlix77>yup got that

<nckx>civodul: I'm fixing (a surprising number) of Guix tests failures blocking a ‘guix’ package update to fix the Web site's manual generation.

<nckx>As I see it, delete-file-recursively is superfluous here, is that correct? https://git.savannah.gnu.org/cgit/guix.git/tree/tests/store-roots.scm#n33

<nckx>I have a patch ready but want to check with you.

<nckx>Actually, looking at it again today, I'm not sure what's correct here.

<nckx>s/'s correct/ you're testing/

<apteryx>is elogind-updates good to merge? https://qa.guix.gnu.org/branch/elogind-updates

<apteryx>it's green on x86_64 and aarch64

<razlix77>nckx would you be able to share a link to your channel? maybe I can steal some knowledge :)

<nckx>Nope, sorry, it's private. One day I'll split out the parts I feel comfy sharing, but that's very low on the priorities list.

<nckx>(It defines systems for the entire household.)

<razlix77>Thanks for the tip! nckx

<nckx>My plej.

<nckx>civodul: Anyway, let me know if <https://paste.debian.net/plainh/53dc834a> is not what you meant. It still successfully swallows an ENOENT, so I'm hopeful that it is :)

<wladmis>hi, chan! what is the right way to add the pam config shipped with the package to system profile? i want to use vlock (part of kbd), it has etc/pam.d/vlock, but not in the system profile

<wladmis>i did not found answer in info guix

<jpoiret>nckx: ah, I have fixes for all guix tests locally

<jpoiret>this one is tricky, I have https://paste.debian.net/1289161/

<jpoiret>the state of the local state dir at this point is not clear

<jpoiret>so better go with a conservative approach

<nckx>Isn't it?

<nckx><all guix tests> So you have a fix for the glibc package/bag failure too?

<nckx>jpoiret: I'm not convinced that it's unclear, and I don't think being overly defensive in tests is a good idea.

<jpoiret>nckx: test-env can call guix commands sometimes before starting the test, thus creating the /profiles subdir

<jpoiret>and for some people, that subdir is being created for some reason

<nckx>OK, when's ‘sometimes’? Do you know?

<jpoiret>ie. ludo doesn't have that test failure on his tree

<jpoiret>iirc it's when you have the bootstrap binaries for that system

<nckx>Oh lord.

<jpoiret>but in any case tests also have to be focused, so we just have to delete /profiles if it exists and try to run gc-roots

<jpoiret>at least that's my take on it

<civodul>jpoiret: hi! i have the test failure after "make update-guix-package" in the build env tho :-)

<civodul>anyway i think it's ok to delete this test

<nckx>…or that.

<civodul>not completely satisfying, but we need the fix

<nckx>We don't need to delete it to fix the failure.

<nckx>And this is the most trivial failure of them all.

<nckx>I'll accept that the tests run in diverse environments, and that this can be a feature, but I'm really not wild about not being able to assume that our own test-env state directory isn't even clean.

<civodul>fun fact: the on-line manual isn't getting updated because doc/build.scm refers has been updated to match the latest texlive changes, but the mcron job refers to the current 'guix' package, which is incompatible (some variables have different names, etc.)

<nckx>Yes, that's why I'm fixing these tests.

<ulfvonbelow>today I learned that signal handlers should probably not suspend whichever fiber they happen to run on.

<civodul>nckx: did you see jpoiret's patch at https://issues.guix.gnu.org/64760 ?

<old>perf does not build with new linux-libre D:

<ngz>Oops sorry about the "texlive.scm" tests. I forgot to look at them.

<nckx>civodul: ! Nope, or I wouldn't have pushed https://git.savannah.gnu.org/cgit/guix.git/commit/?id=1def0b98eb076b2dcf17dfbd18291833e69f287e .

<ulfvonbelow>e.g. https://paste.debian.net/1289170/

<nckx>Or just finished bisecting the libc one to 8b855dc1f4a3e31c002c229ad4d91525f4ce97d3.

<civodul>nckx: oh ok

<ulfvonbelow>in highly-related news, I think I've found out how to completely lock up shepherd's process monitor

<nckx>Oh good, so the store-roots test differs yet again on the Hurd 😃

<old>is it possible to roll-back a pull?

<old>My system is very unstable right now. I have roll-back my home and system configuration

<old>but I would like to roll-back channels as well

<ulfvonbelow>guix pull --roll-back

<old>oh neat

<old>btw guix pull --list-generations is kind of broken

<old>it is extremly slow

<civodul>the other day we talked about X11 services in Home, the problem of $DISPLAY, etc.; here's a proposal: https://issues.guix.gnu.org/65343

<lispmacs[work]>hi all, I'm trying to compile some code that is looking for "gnome-doc-utils". Which guix package would that correspond to?

<bjc>civodul: i was going to object to it on the grounds that there's more than just $DISPLAY. things like $DBUS_*, or $XDG_* (specifically, $XDG_SESSION_TYPE), but on reflection, i think we can extend ‘home-dbus-session-type’, or the various other session types that set those variables to do something similar

<bjc>fwiw, wayland is straightforward: just wait for $XDG_RUNTIME_DIR/wayland-$num, and that's your value for $WAYLAND_DISPLAY

<bjc>i am marginally worried that this will make starting services more brittle, but that may just be fud talking

<civodul>bjc: i'll leave it up to you to propose a follow-up patch for Wayland then :-)

<civodul>"brittle", hopefully not; at least it will make it clear why services are started or not

<efraim>civodul: I'm running sway, I have the /tmp/.X11-unix directory (with X0 and X1 sockets) and a socket at /run/user/1000/wayland-1

<bjc>on reflection, for x, it would be problematic if you have multiple displays, like if you're using x forwarding for ssh

<bjc>not sure how much that impacts wayland, since that's not possible remotely, but locally, i *think* you're allowed to have multiple seats all with their own sockets

<bjc>say i've logged in twice, with a full login shell, with ssh+x-forwarding. there's no way to determine which display gets used in shepherd. moreover, i may want a full session on both, and that will definitely not happen

<bjc>does home-shepherd even support multiple simultaneous sessions?

<lispmacs[work]>is gnome-doc-utils something that still needs to be packaged, or part of some other package?

<martin2>Hi, does anyone have any insight about when privacybrowser could be added to guix? See request here (not made by me): https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64408

<apteryx>old: I agree that 'guix pull -l' is too slow

<apteryx>could you please create an issue for it?

<nckx>ACTION builds a browser.

<jab>if we are talking about browsers...it would be fun to package ladybird.

<old>apteryx: okay

<klovanych>Hello there, i'm tying to do guix deploy to another machine, but

<klovanych> getting this error "gcrypt/pk-crypto.scm:114:12: In procedure

<klovanych> string->canonical-sexp: gcrypt: Bad character in S-expression" Is

<klovanych> this knowing issue ? or should i deep into my config file ?

<civodul>klovanych: hi! it probably means that something's wrong in one of /etc/guix/acl or /etc/guix/signing-key.*

<civodul>could it be that you edited them by hand?

<nckx>klovanych: Do your key files look like this? https://paste.debian.net/plainh/bbae9155

<nckx>On all machines?

<nckx>You should use ‘guix archive --authorize < $KEY_FILE’ to add keys to /etc/guix/acl, and there should be no need to edit the others.

<klovanych>yes, looks like it is the same

<klovanych>i hade same issue as here -> https://issues.guix.gnu.org/46760

<klovanych>And then added my key as in the issue, it started to work, but then this one appeared

<civodul>efraim: https://issues.guix.gnu.org/64838 looks nice!

<civodul>just replied

<civodul>(do our messages with "(" in To: actually reach their recipients?)

<civodul>)

<nckx>Could you share your /etc/guix/acl just in case? It contains only public keys.

<nckx>klovanych: ☝

<nckx>That's the ACL from the target machine.

<klovanych>one sec

<nckx>(So not the machine you're running ‘guix deploy’ on, to be exhaustively clear.)

<klovanych>yes yes, here it is https://paste.debian.net/1289187/

<klovanych>and here is the config file https://paste.debian.net/1289190/

<klovanych>without %my-base-services it runs well, so problem somewhere here with adding key to the default ones

<nckx>klovanych: That's an OpenSSH key.

<nckx>If your directory name is truthful.

<klovanych>sorry for that, it's not)

<nckx>Damn it, stop resisting easy answers :)

<nckx>…uhm, yes it is, or you're using a Guix key as openssh-service key further down. One of them is wrong, and the error message implies it's the first.

<alethkit>Has anyone asked about KDE support recently?

<nckx>SSH keys and Guix keys aren't related.

<klovanych>hmm

<nckx>The guix-service-type key should look like https://git.savannah.gnu.org/cgit/guix.git/plain/etc/substitutes/berlin.guix.gnu.org.pub

<nckx>You can find it at /etc/guix/signing-key.pub on the sending machine.

<klovanych>wow, that's it, thank you nckx it works V

<nckx>Yay!

<akonai_>Wouldn't that x11-service cause problems for hypothetical display-server agnostic services? Since you'd need one version that extends x11-service and one that extends an equivalent wayland service.

<civodul>akonai_: i think you're right, but i'm biased towards incremental improvements here :-)

<civodul>if/when we encounter that situation, we can look for a better solution

<akonai_>you could make both x11- and wayland- services provide a generic 'display service (with the caveat that some services wouldn't extend either)

<akonai_>(or handle wayland and x11 in the same service rather than different ones)

<civodul>ah yes, could be

<civodul>it's been one month so i'm applying the ddclient removal: https://issues.guix.gnu.org/64669

<civodul>thoughts?

<civodul>it's not super satisfying in terms of process because interested users typically can't learn about pending removals

<civodul>(not unless they're actually following guix-patches)

<bjc>hmm. might be nice to add a ‘:deprecated’ field or some such to services and package definitions

<elpogo>speaking of informing users about issues with packages, is there some flag i can add to guix that'll make it check if the profile/shell i'm about to create/enter might have any packages that are now known to be compromised?

<bjc>iirc there's a ‘guix lint’ option that'll check for cves, at least

<civodul>yes, "guix lint -c cve PACKAGE"

<elpogo>can i run that on the manifest that i'm going to launch guix shell with, or do i have to check each package myself? sorry i'm being lazy

<elpogo>ideally, i can add a flag to "guix shell -m manifest.scm" and it'll check automatically before launching the profile

<elpogo>hmm. maybe not so ideal. packages could become compromised after the shell is launched.

<Altadil>elpogo: by pure coincidence, I just saw this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31442

<Altadil>This looks like what you’re looking for.

<elpogo>doh. "guix health" sounds exactly like what i'm looking for. thanks Altadil

<civodul>bjc: we don't have a way to denote things that are deprecated but don't have any replacement, i think

<vagrantc>deprecated by #f

<nckx>elpogo: Just to be clear, that patch was never merged.

<civodul>vagrantc: yeah, we could add support for that

<vagrantc>civodul: i was not serious :)

<vagrantc>but i guess that sort of makes sense...

<elpogo>ok. i'm still learning scheme, but guix health will be my second project when i'm ready. first being to package passt

<nckx>Similarly half-serious: at least for packages, it never makes sense to say ‘nope, and no replacement’ without a reason, so it would be a mandatory string instead of #f 😉

<civodul>yes, but then we need to consider i18n etc., and simple things become complicated

<gerogaga>Hello, I have a quick question: can I open a file with Emacs inside a guix shell instance without having to relaunch Emacs?

<gnucode>gerogaga: I'm not sure if I follow...but can you type in... :

<gnucode>guix shell emacs -- emacs file.txt

<gnucode>the answer is yes

<gerogaga>Yeah, I mean doing that in an already open Emacs session

<gerogaga>Sorry for not being clear

<gnucode>gerogaga: no apology is necessary. What's your use case?

<gnucode>what are you trying to accomplish?

<gerogaga>Just out of convenience. For example, I want to do quick tests with C but don't want clang always installed on my system

<gnucode>I feel like the easiest way to do that...would be :

<gnucode>guix shell --pure emacs -- emacs file.c

<gnucode>in that case you would have two emacs applications running...

<gerogaga>Yeah, I thought so. Thanks for the help.

<gnucode>gerogaga: anytime. :)

<mirai>civodul: the service removal is “alright” imo as its long long been broken

<mirai>the package “might still work” though its just a matter of time until it bitrots to nothing

<nckx>civodul, mirai: What's the story behind the package removal, in addition to the service? Do you know something about the new maintainer that I don't?

<nckx>(ddclient)

<nckx>Should I be concerned?

<mirai>ddclient got its interface upgraded many moons ago but the service was never updated to reflect this

<mirai>and recently the ddclient author/maintainer threw in the towel

<mirai>as it was just an unmaintainable pile of perl hacks

<nckx>Right, I'm talking only about the package.

<nckx>We don't usually remove working maintained packages.

<mirai>package got archived

<mirai>there's a github discussion on the repo

<nckx>Packages change hands often, why's this different?

<mirai>ugh, of course… repo got unarchived in the meantime'

<nckx>It's been like that for quite a while.

<mirai>I sent the patch when it still had the archived banner

<mirai>no idea what changed in the meantime

<nckx>:-/

<mirai>this was the relevant thread at the time <https://github.com/ddclient/ddclient/issues/528>

<mirai>the package _could_ be reinstated but I'd still keep the service down

<nckx>Of course.

<nckx>I thought the Guix package was removed *today*, but I only saw it scroll by, I must have misread.

IRC channel logs

2023-08-16.log