IRC channel logs


back to list of logs

<apteryx>rekado: I'd suggest to either 1) write a patch to avoid the cache or 2) write a patch to fix the cache invalidation, whichever is easiest
<apteryx>loosing user phrases is less surprising than ibus not working :-)
<piptown>is there a reason when writing bash scripts I have to use #!/usr/bin/env bash instead of #!/bin/bash?
<michzappa2>As I've been (re)building my Guix System configuration 'guix search' output has broken at some point. I've tried different shells (fish, bash) and terminal emulators (GNOME Konsole, Kitty) with the same issue present. There's a strange format of non-rendered ASCII like "name: [[1mgcc-toolchain[[0m \n version: [[1m12.3.0[[0m". Anyone seen this before?
<RavenJoa`>I have 2 packages/file-likes I need to substitute, a package and a set of scripts. If the package is the source and scripts a native-input, I get an error about the scripts not having permission for mkstemp. If I do a directory union of the two as the source, I get the same thing, but for the package this time.
<RavenJoa`>I guess my question is, can I have 2 packages as _writable_ inputs which are copied to the output by copy-build-system?
<mirai>nckx, podiki: so it's not well defined which package gets to rule over then?
<mirai>pity, I wanted to give the zutils a try (zcat & co. but works regardless of the compression algo used)
<RavenJoa`>The goal with this whole round-about thing is the user can provide program-files which are called by the apccontrol script. But the program-files should also be able to call back to the apccontrol script. This causes a bit of a circular issue when building.
<viaken>I always preferred Zulip to Matrix anyway
<viaken>Oh shoot, I was in scrollback.
<xelxebar>Upgrading my profile's Firefox causes running Firefox text to go mojibake:
<xelxebar>Anyone else see this? I wonder what the deal is.
<viaken>Looks fine for me. That's some impressive mojibake, too. I assume it's auto-selecting the wrong font somehow?
<podiki>mirai: I believe it is consistent, I just forget which one "wins", first or last
<podiki>mirai: the bug report I linked before has explicit examples to see
<xelxebar>viaken: Right? Pre-rendered pages are fine, of course, and sites providing their own fonts seem okay. Looks like pages that select some default, local font are where the fun happens.
<xelxebar>But, like, why would instantiating a new profile affect processes from a different profile at all?
<xelxebar>I do have a ~/.config/fontconfig/fonts.conf file specced...
<PaddyPatPat>Hello, if I've updated the M.2 wifi card from an Intel one to a ath9k compatible card (I believe: Qualcomm Atheros QCNFA344AH), is there something I should do to give the OS a kick to try to use the card? Restarting wasn't it. I also tried installing the ath9k-htc-firmware just in case but that wasn't it either.
<PaddyPatPat>I didn't see anything obvious in the manual and I figured that if this card does indeed work with the ath9k drivers, that it would be picked up on restart. Maybe I've made a mistake.
<apteryx>anything in dmesg?
<PaddyPatPat>There is a line saying "ash10k_pci 0000:01:00.0: Failed to find firmware-N.bin (N between 2 and 6) from ath10k/QCA6174/hw3.0: -2"
<PaddyPatPat>Hmm I should do this from the computer itself. I've made typos in there.
<PaddyPatPat>Trying again with what I found in dmesg:
<PaddyPatPat> 4.427998] intel_tcc_cooling: Programmable TCC Offset detected
<PaddyPatPat>[ 4.436124] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC295: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
<PaddyPatPat>[ 4.436129] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
<PaddyPatPat>[ 4.436131] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
<PaddyPatPat>[ 4.436133] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0
<PaddyPatPat>[ 4.436135] snd_hda_codec_realtek hdaudioC0D0: inputs:
<PaddyPatPat>[ 4.436136] snd_hda_codec_realtek hdaudioC0D0: Mic=0x19
<PaddyPatPat>I'm assuming that this is unrelated to the wifi though because of the messages surrounding it, even though it mentions "ath10k".
<apteryx>that's just the sound, I think
<apteryx>for bluetooth sound, maybe, that card has bluetooth too
<PaddyPatPat>Hmm maybe. Although I did just find this page that references my m.2 wifi card and the ath10k driver:
<apteryx>where did you read this card uses ath9k?
<PaddyPatPat>I think I read it wrong.
<PaddyPatPat>Or didn't understand the difference between ath9k and ath10k at the time.
<PaddyPatPat>(which I still don't really understand but I now know that they are different).
<apteryx>it's a newer chipset I guess
<apteryx>maybe use a different driver
<PaddyPatPat>Yea. I should find a way to install an ath10k linux driver and see if that works.
<apteryx>the drivers are in the kernel Linux tree:, you'd have to see if they require loading a proprietary firmware or not
<PaddyPatPat>Huh cool. Thanks for the help.
<apteryx>I gues they do, if it doesn't work in Guix
<apteryx>(on Guix System with linux-libre)
<apteryx>usually you'll see a DEBLOBBED message from the linux-libre kernel if it happens.
<ulfvonbe`>is there a way to include a literal entry in a search path specification?
<ulfvonbe`>e.g. if a search path has a default value that includes the current working directory
<ulfvonbe`>and said behavior should be preserved by default
<ulfvonbe`>if you just include "." as an entry, the resulting search path will have <package-out>/. as an entry instead of just ".", which is less than helpful
<vivien>ulfvonbe`, if you are packaging a program, you can wrap it to add "." to the search path
<ulfvonbe`>yes, but then it's no longer possible to get the original behavior back if that's desired
<ulfvonbe`>e.g. suppose there are some use cases where it's desirable to not search the current working directory, and setting the search path explicitly is how you do that
<ulfvonbe`>this is, for example, how gforth's GFORTHPATH works
<civodul>Hello Guix!
<janneke>hello civodul :)
<rekado>hi guix!
<rekado>“guix deploy” from my x86_64 laptop to my aarch64 server only works without grafts. Grafts seem to always be built locally, and that fails because the system architecture is supposed to be aarch64.
<rekado>it seems to me that grafts should be architecture agnostic
<civodul>ah yes, grafts are marked as non-offloadable
<janneke>hey rekado :)
<janneke>dongcarl: trying to build bash-minimal for mingw (a dependency for guile), i'm getting
<janneke>./config.h:361:19: error: two or more data types in declaration specifiers
<janneke> 361 | #define socklen_t unsigned int
<janneke>ring any bells?
<janneke>ACTION has already tried to revert to bash-5.1.8 (which builds on 0e9429544fd737079b9c1562de3beb48329350a9), but get the same error so it must be "something else that changed"
<civodul>janneke: MinGW was upgraded recently, but that was a minor version bump IIRC?
<janneke>civodul: yes, i looked at it but didn't attempt a fresh guile build; also it could have broken before that, really dunno...
<civodul>hmm hmm!
<janneke> /me is kinda rooting for spike121's grand guile mingw merge
<civodul>apparently there’s no cross-MinGW Bash job at
<civodul>or at least i couldn’t find it
<janneke>bummer, thanks for looking!
<efraim>civodul: I'm flying to India today but I'll ssh back to my desktop soon and test copying the 7.5 Gb file using guix archive soon
<civodul>efraim: alrighty, thanks!
<janneke>civodul: in other news, i found that was dropped again?
<janneke>it's not listed on anymore, anyway
<civodul>janneke: i disabled it soon after adding it, when i realized we didn’t have any i586-gnu worker
<civodul>but! this week-end i added a cuirass-remote-worker instance on berlin for i586-gnu
<civodul>(as we had discussed a couple of weeks ago)
<civodul>however that worker doesn’t show up at
<civodul>so that needs investigation
<civodul>slow progress…
<janneke>civodul: oww, thanks for keeping hammering on that
<civodul>sorry it takes so long!
<civodul>i wish it’d move faster, but i seem to fail to get things done these days
<janneke>hehe, yeah
<janneke>ACTION has been trying to push a couple of releases out for over two months
<janneke>sometimes progress is slow and you discover all sorts of things along the way
<rekado>what is the proper way of managing Guix System containers as shepherd services?
<rekado>in the swineherd extension I’ve been using “herd eval root” to create a new service for a Guix System container
<rekado>the service comes with container-specific actions like “up”, “down”, “ip”, etc
<rekado>when I want to destroy the service I do “herd unload root”
<rekado>is this … gross? Or something we’d want in Shepherd proper?
<rekado>would it be better to instead have a completely separate container manager?
<cbaines>janneke, civodul, there are running childhurds connected to bordeaux, the problem is they require babysitting (see milano-childhurd-* on )
<cbaines>as soon as they hit a build that causes the childhurd to hang, that needs spotting manually and canceling, and the childhurd then needs restarting
<civodul>cbaines: heh, i can imagine…
<civodul>rekado: that sounds good to me
<civodul>i’ve been willing to add a service for “child systems”, similar to childhurds
<civodul>my interest is in VMs here but it wouldn’t be too different i guess
<civodul>actually, when would you recommend Guix System containers as opposed to mere services (or service containers)?
<nikolar>how do i get the target triplet inside my package
<nikolar>for exap
<nikolar>for example when built with guix build --target=...
<cbaines>another hurd question, when is it useful to build linux-libre-headers for i586-gnu?
<aitzkora>I need to modify the argument "-pX" of the patch command. Does anyone know the syntax on the guix side ?
<aitzkora>I think i found It : (patch-flags '("-p0"))
<nikolar>or a better question, why is %current-target-system always #f
<NinjaTrappeur>guix pull is terribly slow on my x200 (~5 minutes to import a week worth of commits). I'm wondering what's the slow part. How would you profile this?
<rekado>civodul: my use case is with Guix System containers on a foreign distribution
<civodul>rekado: and you use shepherd there?
<civodul>cbaines: never? :-)
<civodul>NinjaTrappeur: the slow part is “Computing Guix derivation”, which, well, computes a .drv from as little as possible to build the new Guix
<civodul>the time is mostly spend in Guile’s macro expander
<civodul>it’s pretty inconvenient to profile because you need to extract the script that does that
<NinjaTrappeur>So, roughly speaking, you extracted this script (I assume manually? or do you have a trick?), then encapsulated it in a statprof call?
<civodul>but yeah, it’s really a bummer that it this slow
<cbaines>civodul, okay, I'll add it to my list of packages to remove i586-gnu from the supported systems
<civodul>NinjaTrappeur: it’s been a while, but yeah you get its source file name, then you wrap it in ‘statprof’ or similar
<civodul>if you’d like to look into it, i’m happy to provide guidance!
<NinjaTrappeur>Thanks :) I'll definitely ping you if I get blocked!
<rekado>civodul: yes, I use Guix there, and I found it convenient to use shepherd to launch independent Guix System containers on the machine
<rekado>I added an API server, so I can manage the containers through the backend of a web application
<rekado>together these services form a platform to spawn Guix Systems on demand.
<ekaitz>hi, how do you make a project install it's CMake modules that are searchable by include(...)?
<vivien>bash cannot be built under mingw, that’s why cygwin exists
<jpoiret>NinjaTrappeur: the main problem is that guix tries to use its own package definitions for guile/guile-ssh/etc. as dependencies for guix itself. The problem is that the package definitions are not yet compiled and thus take very long to load
<jpoiret>you can reproduce this by setting %load-compiled-path to '() and doing (use-module (gnu packages guile))
<jpoiret>nikolar: %current-target-system is different from #f only when cross-compiling
<nikolar>Oh ok
<nikolar>How do I get the target when building a cross compiler
<nikolar>I can see that guix is passing --host to configure but TCC doesn't work like that
<jpoiret>building a cross-compiler is more complicated
<jpoiret>also, %current-target-system doesn't correspond to --target iirc
<jpoiret>it maps to --host
<jpoiret>have you had a look at (gnu packages cross-base)?
<janneke>vivien: i already knew that Guix is _amazing_, you'll be thrilled to learn it can even do things that are not possible, try:
<janneke>guix time-machine --commit=0e9429544fd737079b9c1562de3beb48329350a9 -- build bash-minimal
<nikolar>jpoiret: very briefly
<janneke>hmm, i meant to say: that would be: guix time-machine --commit=0e9429544fd737079b9c1562de3beb48329350a9 -- build --target=x86_64-w64-mingw32 bash-minimal ...
<janneke>but that fails...
<janneke>so now i'm puzzled!
<janneke>possibly we didn't build bash-minimal as a dependency for guile before, in that case, where/how was the dependency introduced...hmmm
<janneke>ACTION has been looking at / bisecting the wrong bug this morning, apparently
<NinjaTrappeur>jpoiret: thanks for the explanation
<vivien>janneke, I know perl pulls bash to run system commands (even if on mingw, it should use cmd.exe)
<vivien>More precisely, it *could*
<janneke>vivien: good to know, i somehow remember we cross-built bash-minimmal on guix but as yet haven't find any proof of that
<vivien>I’m not a perl expert, so I don’t know if packages that run system command expect to have cygwin or cmd.exe on windows
<vivien>perl packages that run system commands*
<civodul>rekado: sounds fun!
<janneke>vivien: i expect that running system using a non-posix shell will mostly give suprising results
<vivien>I agree
<vivien>But maybe perl packages have done a lot of work so that they can use cmd.exe
<vivien>If we give them a posix shell it will confuse them a lot
<janneke>yeah, that could be
<nckx>mirai: The order's definitely not *well* defined. Committing to one consistent and documented order (right over left, bottom over top, bikes over sheds) everywhere probably wouldn't hurt anyone.
<vivien>These 3 SO questions make me think perl routinely uses cmd.exe on windows, cygwin being a confusing exception:
<vivien>But maybe there are 2 clusters of perl packages, those windows-minded and those for posix. If that’s the case, we will mostly build posix-aware perl packages in guix, so we should have a posix shell.
<vivien>I don’t know, I tried writing a bit of perl in my career once and it did not turn out well, so I’ll wait for an expert to shime in XD
<vivien>chime in*
<apteryx>cbaines: it'd be nice if QA could tag Debbugs issues with a user tags like 'qa-ok' or 'qa-failed', to have the 'badges' info readily available from Emacs Debbugs
<haider>For some reason, neovim seems to segfalt in a guix LHS container.
<cbaines>apteryx, that should be possible, although it might require QA to start sending emails and I'm not sure how hard that'll be
<cbaines>apteryx, I've been updating the list of ideas in the README, so feel free to add something
<civodul>comrades, anyone feels like writing/finding a tiny build log coloring script in JS that we could use in Cuirass & co.?
<nikolar>ekaitz: hello
<ekaitz>nikolar: hi
<nikolar>i am working on tcc stuff we talked about
<nikolar>and i have the crosscompiler working
<ekaitz>oh good
<nikolar>except for the part where it insists on linking with native libc
<ekaitz>are you making the weird file or whatever it needs?
<nikolar>i copied your config actually
<nikolar>it cleared some other linking errors
<ekaitz>nikolar: i think it changed with recent version so be careful with that
<nikolar>what exactly changed, the config format?
<ekaitz>that's the "newish" way to do it
<ekaitz>i don't remember if I shared that with you or the other
<ekaitz>(i'm working in different versions)
<nikolar>that looks like the one you showed me
<ekaitz>great so that's more or less how it should be done
<ekaitz>nikolar: now I have to go, but send me an email with what you managed to make and i'll try to help
<ekaitz>my email is in guix code, just grep my name and you'll find it
<nikolar>ok cool
<nikolar>will do
<ekaitz>nikolar: thanks for keeping me posted
<nikolar>no problem
<RavenJoad>Can I have a package and a file-union of program-files as _writable_ inputs which are copied to the output by copy-build-system?
<mirai>apteryx: I don't think debbugs understands arbitrary tags
<apteryx>you can use *user* tags
<apteryx>(which are arbitrary)
<apteryx>the user should be your own, or 'guix' if you want these user tags to be shared with others
<mirai>hmm? how does that work?
<apteryx>it's documented in our doc
<apteryx>should we use the 'book-' variable prefixes for book, as proposed in #65669?
<apteryx>for fonts we've had a -fonts *suffix*
<mirai>of course it couldn't have been on <> which is one of the links in the debbugs frontpage
<mirai>no, it had to be on <> which has to be found by searching 'usertags' up (so you need to know of its existence beforehand)
<apteryx>oh, that's a nice findig, I'm not sure I've ever seen that page
<apteryx>mirai: it doesn't say how to use a specific user for setting the usertag though from that page. I think the 'Debbugs UG' manual has it
<mirai>interestingly, it says “To use it you send a mail message to request at”
<mirai>so it's not the usual _control_ one
<apteryx>oh, that's why my previous experiments failed, perhaps
<mirai>which I think might imply that you can't add usertags to existing ones
<apteryx>hm, info '(debbugs-ug Control Messages' doesn't say the server should be different though
<mirai>but then “usertag 123456 help security” wouldn't make any sense
<mirai>so… ???
<mirai>to be fair, the debbugs used by GNU isn't exactly aligned with upstream one so perhaps this was already ironed out
<mirai>ACTION rebuilds the enblend-enfuse aberration of a definition but with doc split
<euouae>Hello I tested guix and I got an error about my AMD Lucienne not being supported
<euouae>is there nothing I can do?
<civodul>euouae: hi! could you paste the error message and show us the command that you ran?
<euouae>Hm... I'd have to restart and try to install again
<civodul>euouae: oh maybe you’re talking about the Guix System installer, right?
<euouae>civodul: is it related to non-free drivers?
<civodul>euouae: yes, i suppose you saw the warning about unsupported hardware, which could be due to the lack of free drivers
<civodul>(it could be a false positive in this case, i have no idea)
<civodul>i guess that’s an amdgpu thing, i don’t know if it’s supposed to work with free software
<civodul>i guess you could try installing and see how it goes
<dthompson>like intel gpus, amd gpus have free drivers in the kernel but nonfree firmware
<dthompson>haven't used an amd gpu myself but I think that's the case
<dthompson>basically any modern gpu isn't going to work with linux-libre
<civodul>ah ok
<euouae>civodul: won't let me install
<nikolar>how do i get a path to a package in configure step
<nikolar>of a dependency that is
<euouae>dthompson: including integrated gpus?
<civodul>euouae: my recollection (if we’re talking about the same thing :-)) is that it’s a warning that doesn’t stop you from installing
<euouae>civodul: I'll try again, but it'll take some time to re-download guix because I can't find it now
<euouae>might've forgotten to copy it over when I moved to debian
<dthompson>euouae: yup, even those now.
<dthompson>intel changed gpu architecture a few gens back
<nikolar>how do i get a path from a package variable
<cbaines>nikolar, a path to what?
<nikolar>i am trying to pass a path to cross libc
<nikolar>for tcc as a cross compiler
<nikolar>i have a variable which holds a package for glibc but i need to get the path to it so i can configure tcc
<cbaines>when you declare inputs to a package, those inputs are available at build time, and you can lookup the filenames within the build script
<nikolar>How do I do that
<cbaines>unfortunately, if it's documented, I can't find it
<cbaines>I think the build systems usually pass the package inputs to as an alist to each of the build phases
<nikolar>ah ok
<RavenJoad>nikolar: (assoc-ref %build-inputs "package-name")
<nikolar>thanks RavenJoad
<euouae>Is it just me or does firefox show code blocks choppy in <>
<nikolar>i am trying to use it in #:configure-flags
<nikolar>it says unbound variable
<RavenJoad>Which variable is unbound?
<cbaines>nikolar, it's useful to distinguish between an issue in the package definition, and in the build script
<nikolar>this is a package definition
<cbaines>I'm guessing in this case it's the package definition, maybe because some parts of the arguments should be a gexp (or quoted)
<nikolar>i can't figure it out cbaines
<RavenJoad>%build-inputs should always be defined. You may need (arguments `(#:configure-flags (list (assoc-ref %build-inputs "apckage"))))
<nikolar>RavenJoad: i got further, thanks
<nckx>I'm going to poop on this parade and say that %build-inputs should be your last resort, and you almost never ever need the last resort. Use this-package-input, or (#:key inputs #:allow-other-keys) (search-input-file inputs "bin/foo"), etc.
<nckx>Consider %build-inputs an undocumented implementation detail.
<nckx>As opposed to most other things in Guix which are undocumented official API.
<nckx>Does anyone run a Tor node on a Guix System? tor consistently uses 100% of a core after a while, forever. This for pushing 500K/s on average seems excessive. Also strange is that Nyx claims 0% CPU, but that could be a(nother) bug.
<apteryx> is returning 500 errors when using 'guix lint'
<apteryx>e.g.: emacs-transient@0.4.3-0.cc0fa80: '' returned 500
<apteryx>nckx: there's one running on berlin
<jpoiret>i'm having a bit of a brainfart, #$(this-package-input ...) should take replacements into account, right?
<janneke>if an inherited package means to substitute that input?
<cbaines>jpoiret, replacements apply after you've built things, so they don't affect a package build script
<jpoiret>package transformations i mean cbaines
<janneke>ACTION reverted some package descriptions to using assoc-ref %build-inputs...
<jpoiret>not grafts, that was unclear
<cbaines>I think for transformations, #$(this-package-input ...) should work fine
<cbaines>although saying that, the implementation seems more complicated than I was imagining, so I'm unsure
<RavenJoad>nckx: I did not know that. Is this-package-input available for setting #:configure-flags ?
<nckx>search-input-file is not.
<RavenJoad>Perfect! I will have to change xen to use this-package-input instead. That was where I got the %build-inputs from.
<nckx>You don't have to, but it's always nice to have existing packages reflect the current style, so thanks!
<mirai>could this <> get some eyeballs on it? (bonus if you're Perl fluent)
<mirai>it's an update for a package that I occasionally use when dealing with the “wtf is this package's license?” question
<RavenJoad>Once I eventually figure out the runpaths issue, I can fix that and send xen back. I have narrowed down the validate-runpaths issue. That phase does not pick up the right paths for a python shared object. If I set LD_LIBRARY_PATH and check with ldd manually, everything comes back fine.
<nckx>janneke: Why?
<mirai>it's gotten some important fixes (wrt detection) so it's not just the regular “shiny new number from guix refresh”
<janneke>nckx: in a personal archive; because a package has "sed" while its inheriting package replaces that with "sed-mingw"...but if the original (argumenst ...) section has #$(this->package-input "sed"), then boom
<janneke>so yeah, iwbn if i new how to fix that properly
<nckx><then boom> this-> was clearly NULL.
<janneke>i could, of course, rewrite the whole phase that uses $this-input, but meh
<janneke>i mean, copy it to the inheriting package and then change only that single line with sed -> sed-mingw
<nckx>Well, it's a work-around after all. I doubt that this-package-things are *supposed* to work this way.
<nckx>That said I haven't tested this exact case.
<janneke>possibly the-way would be to merge sed-mingw into sed+, make switches/changes for the target architecture inline, and use sed+ in the initial package
<nckx>Am I missing something when thinking this is ‘just’ an oversight in the current this-package-* implementation? Are you saying it's a fundamental limitation that requires modifying certain packages to work with it, forever?
<janneke>that's a good question; it seems to me that the ("sed" ,sed) vs ("sed" ,sed-mingw) with associated assoc-ref %build-inputs "sed" indirection is gone
<janneke>but i can easily imagine that civodul can think of another (a better?) way to play this
<ekaitz>hi all, anyone experienced weird CROSS_C_INCLUDE_PATH behaviour in guix shell?
<ekaitz>i just wrote to help-guix but as I was writing started remembering this happened before...
<ekaitz>I can't find references in the ML though
<ekaitz>basically arm-none-eabi-toolchain does not find stdlib.h which is in CROSS_C_INCLUDE_PATH
<nckx>Anyway, I think we shouldn't encourage %build-inputs in new code, just because janneke has a well-documented love affair with weird xstuff and seeking out edge cases (that's a compliment, by the way :)
<janneke>nckx: there's possibly (package-inputs this-package) that i could use to get rid of the old %build-inputs meme
<apteryx>ungoogled-chromium-wayland@112.0.5615.165-1: probably vulnerable to CVE-2023-2459, CVE-2023-2460, CVE-2023-2462, CVE-2023-2464, CVE-2023-2465, CVE-2023-2466, CVE-2023-2468, CVE-2023-2721, CVE-2023-2723, CVE-2023-2724, CVE-2023-2725, CVE-2023-2726, CVE-2023-2929, CVE-2023-2930, CVE-2023-2931, CVE-2023-2932, CVE-2023-2933, CVE-2023-2934, CVE-2023-2935, CVE-2023-2936, CVE-2023-2937, CVE-2023-2938,
<apteryx>CVE-2023-2940, CVE-2023-2941, CVE-2023-3079, CVE-2023-3214, CVE-2023-3215, CVE-2023-3216, CVE-2023-3217, CVE-2023-3420, CVE-2023-3421, CVE-2023-3422, CVE-2023-3598, CVE-2023-3727, CVE-2023-3728, CVE-2023-3730, CVE-2023-3732, CVE-2023-3733, CVE-2023-3734, CVE-2023-3735, CVE-2023-3737, CVE-2023-3738, CVE-2023-3740, CVE-2023-4068, CVE-2023-4069, CVE-2023-4070, CVE-2023-4071, CVE-2023-4072,
<apteryx>CVE-2023-4074, CVE-2023-4075, CVE-2023-4076, CVE-2023-4077, CVE-2023-4078, CVE-2023-4349, CVE-2023-4351, CVE-2023-4352, CVE-2023-4353, CVE-2023-4354, CVE-2023-4355, CVE-2023-4356, CVE-2023-4357, CVE-2023-4358, CVE-2023-4360, CVE-2023-4362, CVE-2023-4364, CVE-2023-4365, CVE-2023-4366, CVE-2023-4367, CVE-2023-4368, CVE-2023-4427, CVE-2023-4428, CVE-2023-4429, CVE-2023-4430, CVE-2023-4431, CVE-2023-4572
<ekaitz>apteryx: o wow
<nckx>ACTION is reminded to upgrade their firefox package to fix CVE-2023-4573, CVE-2023-4574, CVE-2023-4575, CVE-2023-4576, CVE-2023-4577, CVE-2023-4578, CVE-2023-4579, CVE-2023-4580, CVE-2023-4581, CVE-2023-4582, CVE-2023-4583, CVE-2023-4584 and CVE-2023-4585.
<nckx>This is fine ☕
<acrow>Can others run nyxt (on guix system) without it crashing within a few seconds?
<tylerm>just a few CVEs
<tylerm>acrow: let me try
<tylerm>acrow: its working for me
<nckx>acrow: Anything I should be doing during those seconds?
<acrow>tylerm: Thanks -- I guess it must be something local to me.
<tylerm>try running it in the terminal
<tylerm>see if it outputs any errors
<acrow>ncks: Not for me -- it just fails with a bad thread merge.
<nckx>(Note that it will print *a lot* of warnings and even errors when running fine, e.g., ‘(WebKitWebProcess:2): GLib-GObject-CRITICAL **: 20:31:58.863: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed’)
<nckx>Critical but harmless.
<nckx>Hm, my nyxt window has become uncloseable (Sway).
<nckx>Also, un-sigtermable.
<tylerm>I am running sway as well and it seems perfectly fine for me
<jackhill>I was able to open Nyxt, load, and the C-c it from the terminal
<nckx>I'm running it in a --pure shell and browsin'
<nckx>There being no hand cursor (probably due to the purity) is the only glitch I can spot.
<apteryx>nckx: perhaps there's a 'banish' shortcut like in ratpoison
<tylerm>Yep the --pure breaks the hand cursor for me as well
<acrow>acrow: Looking at my local configs and telling nyxt '-I' did not help. Hmmm...
<nckx>apteryx: I used pkill -9 but I do miss the drama that was the xkill death cursor.
<nckx>Is a ‘thread merge’ a Lisp term? This is the only thread-related warning I can find:
<nckx>(Triggered with C-c.)
<acrow>The exact quote:
<apteryx>nyxt works well here
<acrow>Clearing out the contents of ~/.local/share/nyxt/ has resolved the issue. I still get lots of warnings -- about a bad locale among other things -- but it is working.
<nckx>Hmm. If it is a Guix issue, maybe an embedded store file name?
<nckx>Did you keep it?
<acrow>nckx: I'm just suprised that nyxt doesn't seem to respect my GUIX_LOCPATH and trivial glibc-us-utf8-locales package.
<unmatched-paren>PACKAGE seems to break when used in `guix repl`
<acrow>nckx: I doubt it is a guix problem. More likely some aspect I don't properly understand.
<unmatched-paren>I get 'encountered raw symbol in macro output in subform socket of (current-location-vector)'
<nckx>I… don't.
<unmatched-paren>fortunately it works fine if i add (LOCATION #f) at the bottom
<unmatched-paren>ACTION has pulled, will restart repl
<nckx>ACTION just tried scheme@(guix-user)> (package (inherit (@ (gnu packages base) hello))) ; nothing fancy.
<RavenJoad>I am also having issue with nyxt, but it might be related to missing GStreamer things. I cannot even load
<unmatched-paren>still happens for me after pull
<nckx>My Guix is also not the newest.
<unmatched-paren>with both inherited and from-scratch packages
<nckx>I'm on 9d2e6323775371ab0ccaec0fc1df3b50335c41ea.
<nckx>unmatched-paren: So my silly example still fails?
<acrow>unmatched-paren: doesn't render for me either. I did a fresh pull and update of all packages this morning so I'm up to date.
<acrow>But other pages work just fine....
<RavenJoad>acrow: Wikipedia of Guix works for me, so at least my nyxt is not super broken.
<acrow>Maybe I need to also install gstreamer?
<nckx>Yes. Adding gstreamer gst-plugins-{base,good} fixes it.
<Guest69>Since I added an mcron job, I can't reboot my rpi.  Was this may some bug in Guix, since I can't use latest revision?
<nckx>Our site is too multi-medial.
<nckx>Eh, not including the -plugins makes it crash even before start-up.
<acrow>Is it our minimalistic tendencies that prevent us from adding gstreamer to nyxt as a propagated input? or is there a better reason?
<nckx>We don't have minimalistic tendencies *points at graph*.
<nckx>However, we shouldn't randomly propagate things without understanding why there's no better alternative (and generally, IMO, all alternatives are better).
<nckx>Problem is I don't know the first thing about real-boy Lisps and how we'd point it to gstreamer without propagation.
<nckx>You need only a few well-placed propagations to make an entire desktop installation a monolithic clump that needs to be upgraded in lockstep.
<Guest69>I added a job that runs every minute.  Now I removed it and reconfigured the system again.  "herd schedule mcron" does still show jobs for the one I removed
<nckx>Maybe ‘restart mcron’?
<Guest69>I ran "herd restart mcron" and "herd schedule mcron" still shows it
<Guest69>adding gnupg as package input does give an error of undefined variable but does not say which module needs to be imported.  This happens on some packages.  Is this an error since it is inconsistent?
<nckx>‘error: gnupg: unbound variable | hint: Did you forget `(use-modules (gnu packages gnupg))'?’
<Guest69>interesting.  I am not on the latest revision.  Maybe it was fixed some time ago?
<Guest69>Authenticating channel 'guix', commits 9edb3f6 to bd7bb47 (1,758 new commits)...
<nckx>Guest69: With this ‘old’ guix, does ‘echo "((@@ (guix ui) known-variable-definition) 'gnupg)" | guix repl’ return an object or #f?
<nckx>Maybe this happens when you don't import (gnu packages) or so…
<nckx>…that's 100% a guess though.
<nckx>ACTION away.
<Guest69>nckx: you cmd,  the package it happened
<nckx>I forgor that my ~/.guile *does* import (gnu packages), so I guess this would be a more fair test: echo -e ",use (gnu packages)\n((@@ (guix ui) known-variable-definition) 'gnupg)" | guix repl
<nckx>guix repl could use an -e option if only for IRC. ☺
<nckx>ACTION still mostly away, not really available, but good luck.
<Guest69>nckx: Your new cmd:  I will update my whole system and run both cmds again
<Guest69>guix (GNU Guix) bd7bb4794400ee0cbffda52846f6464a5390ea5b, well turns out I accidentally ran those cmds with the new version since I opened a new terminal.  Anyways going to reconfigure system
<unmatched-paren>nckx: i wonder if it matters that i'm using geiser-connect
<unmatched-paren>(and yes, that example fails)
<apteryx>we need a script that checks issues in debbugs and closes those already committed
<apteryx>(if the commit subject matches, e.g.)
<jpoiret>huh, an ocaml project for coq that uses a js test framework?
<jpoiret>am i dreaming?
<nikolar>why would you ever use js if you have a choice not to
<civodul>jpoiret: uh, terrible