IRC channel logs


back to list of logs

<rekado>dgcampea: what provides (ice-9 posix)? I can’t load it in my Guile REPL.
<dgcampea>rekado: ah right, I must have mixed something up here
<dgcampea>that module is wrong
<dgcampea>though deleting it doesn't completely solve it
<dgcampea>I get 'no code for module (json)'
<dgcampea>I think I got the same error when I had (guix build utils) as well
<ae_chep>the kak-lsp that I recenly reported as broken now has a fix. If there is anyone else using kakoune, kak-lsp and guix trio besides me, you can rest assured!
<old>nckx: xset -dpms helps with my issue thanks
<dgcampea>if I do "sudo /script-made-from-gexp" I get "no code for module (json)" but with sudo -E it seems to work although I get a big warning "loading compiled file .../lib/guile/3.0/site-ccache/guix/build/utils.go failed: In procedure load-thunk-from-memory: incompatible bytecode version"
<dgcampea>how should I solve this?
<GNUtoo>Hi, I run guix system, and when I run that command: initdb --locale=C.UTF-8 --encoding=UTF8 -D /var/lib/postgres/data --data-checksums, I've that error: initdb: error: invalid locale name "C.UTF-8"
<GNUtoo>with locale -a I see various UTF-8 like en_US.utf8 or en_US.UTF-8 and according to UTF-8 is the right string to pass it
<GNUtoo>Is there something special I need to do to be able to create a databse?
<jab>GNUtoo: you said in #hyperbola that guix has full source bootstrap for X86_64 but a binary of 1 KB....
<jab>What is that 1 KB?
<GNUtoo>1 kilobyte
<GNUtoo>let me find the references
<jab>GNUtoo: is that 1KB troubling? Is it a mystery binary?
<GNUtoo>As I understand that got merged
<jab>or a hand written thing?
<GNUtoo>It's a good thing that it's that small
<GNUtoo>For other distros it's usually huge like at least hundreads of megs
<GNUtoo>It's 357-byte in that discussions about the patches, though it's a bit bigger in some other architectures, and not all architectures have that
<jab>GNUtoo: I wonder why there hasn't been a blog post about the full source bootstrap yet...
<GNUtoo>There was
<GNUtoo>(if I remember well)
<jab>There was this:
<GNUtoo>Note that I also created a Wikipedia article about that: so if I'm wrong that needs to be fixed there too
<jab>But not a full source bootstrap post. :)
<GNUtoo>Though there I assume that it's possible
<jab>that blog post annouces a bootstrap seed of 60MB
<GNUtoo>hmmm the patch status is open
<GNUtoo>So maybe it works but it's not merged
<daviid>GNUtoo: is this not that when the locale is "C", it is just "C" [which means ascii 'only', american english, iirc, and generally a fallback], not sure how you got this "C.UTF.8", which i think it is an invalid locale spec, but not an expoert... [and not a guix user, this is not guix related i think]
<GNUtoo>daviid: I specified UTF-8, the C.UTF.8 comes from an error message, I'll try in a Parabola chroot to see if it works there
<daviid>i think you need to specify <lang>.UTF.8
<daviid>like en_US.UTF-8
<GNUtoo>I did that, this is why it's strange
<daviid><lang>.UTF-8 [there is no C.UTF-8], and it seens not specifying the lang, you got C as a fallback ... not sure but ...
<daviid>what does locale returns ij a guix terminal?
<GNUtoo>but I also tried with lang and forgot to mention it here
<GNUtoo>initdb: error: "en_US.utf8" is not a valid server encoding name
<GNUtoo>This is because the initdb command only accept names mentioned in the postgresql manual
<daviid>GNUtoo: i see two possible problem - 1. you specify a valid <lang>.UTF-8, but <lang> is not installed
<GNUtoo>locale -a | grep -i "^en_us" gives en_US.utf8 and en_US.UTF-8
<daviid>and 2. guix falls back may be buggy, like it detects you donot have <lang>,but falls back on C.UTF-8, rather then just "C"
<GNUtoo>There are also things like en_GB.utf8 so the later probably means "english" in general
<daviid>yes, like fr_BE... fr_FR...
<GNUtoo>The issue is that I've C and POSIX but not C.UTF-8
<GNUtoo>So maybe I'm supposed to somehow install what is needed to have C.UTF-8
<daviid>but C.UTF-8 siounds a bug, nd i very much doubt postgres would get this wrong bythis tine
<GNUtoo>should I bugreport it in Guix?
<GNUtoo>like I try in Parabola and if it works I bugreport?
<daviid>GNUtoo: dont kow, not a guix user here... jst wanted to give some exprerience based tips
<GNUtoo>ok, thanks
<daviid>GNUtoo: in guix, try change your locale temporarily
<daviid>like LANG="C";locale
<daviid>then try to createthedb againb
<GNUtoo>I probably don't want to use "C" to create the database
<daviid>or expórt LANG="C";locale
<daviid>sure, just to find out;youmay delete this temp db and create a real one later
<GNUtoo>For databases it's usually easier to start with the right locale, else I heard that migrations can be messy
<daviid>GNUtoo: how do you askguix which locales are installed?
<GNUtoo>locale -a ?
<GNUtoo>(and locale to know which ones are in use)
<GNUtoo>Though unlike other distributions like Parabola in Guix this is done with a package and not generated by users with locale-gen
<GNUtoo>Ah it's also possible to generate them:
<daviid>my assumption is your locale does exists (is not installed) and guix fallsback has a bug
<daviid>the fallback sould be "C", and if your locale is installed and valid, there should be no bug ...
<GNUtoo>in the postgres documentation it says: Language: all for UTF-8 so maybe I just need C.UTF-8
<daviid>hum, maybe
<daviid>i see i actually have C.utf8 as well here, amog others ... [not C.UTF-8 though, not sure ]
<daviid>here i have locale -a -> C, C.utf8, en_US.utf8, POSIX [debian testing]
*GNUtoo tries to install C.utf8
<GNUtoo>It'll take a little bit of time because I need to compile things
<daviid>GNUtoo: i see in the guixmanual, "These locale definitions use the normalized codeset for the part that follows the dot in the name (see normalized codeset in The GNU C Library Reference Manual). So for instance it has uk_UA.utf8 but not, say, uk_UA.UTF-8"
<GNUtoo>+ to re-checkout the guix repository (I got filesystem corruption on another partition that had the Guix source code)
<daviid>GNUtoo: good luck
***rgherdt_ is now known as rgherdt
<sektor[m]>Morning, Guix.
<SUPERB[m]>I was wondering what distro Guix is based on?
<Franciman>hello, is there any tutorial on how to make a development env for php with guix?
<Franciman>I saw that php-fpm is not packaged with guix, but somehow you can define it as an option to nginx
<Franciman>i was a big confused
<newluhux[m]>you can also found this code in `info guix`
<Franciman>thanks a lot
<Franciman>one question. I'm using guix on a foreign distro. Can i create a guix shell in which i specify services to start?
<Franciman>i suppose not
<newluhux[m]>you can use `guix system vm --expose=$(pwd)=/var/www`
<newluhux[m]>it will boot up a virtual machine
<Franciman>even on a foreign distro?
<nashdidan[m]>I'm not sure if it's Guix specific or some other problem, but Icecat (and... (full message at <>)
***Dynom_ is now known as Guest5122
<antipode>SUPERB[m]: Guix is not a derivative of another distro.
<antipode>It uses the nix daemon of Nix, but that's it (it only uses its daemon, not its packages)
<antipode>nashdidan[m]: IRC does not have multi-line messages, your message looks like
<antipode>I don't know what's going on, but possibly how you are 'registering .desktop stuff' might be relevant
***wielaard is now known as mjw
<antipode>Franciman: Have a look at "guix shell --development" and its documentation
<antipode>GNUtoo: IIUC, C.UTF-8 is not in glibc yet, or maybe it's in glibc but the new glibc isn't in Guix yet. My information might be out-of-date, though.
<antipode>dgcampea: Have you used 'with-extensions' to add guile-json to the G-exp?
<antipode>((json) is not part of Guile proper)
<antipode>old,dthompson: Not all JSON is valid YAML (, according to , at leawt in some YAML versions.
<rekado_>dgcampea: you need to use with-imported-modules or similar
<Kabouik>Trying to print on a Konica-Minolta printer, the cups web interface gives me 'stopped "Filter failed"'. I suppose I am missing a cups filter in my configuration, but none of those mentioned in the Guix manual seem to be related to Konica Minolta ("extensions (default: (list brlaser cups-filters epson-inkjet-printer-escpr foomatic-filters hplip-minimal splix))"), and `guix search konica` is of no help. Do I need something generic?
<sneek>Welcome back Kabouik, you have 1 message!
<sneek>Kabouik, unmatched-paren says: nice, looks like home-batsignal was merged :)
<Kabouik>Good news unmatched-paren, well done! I have to investigate it more to understand the difference between the service and my batsignal autostart command defined in my Sway config.
<Kabouik>I think I got it working with simply cups-filters:
<Kabouik>Though the Gnome printer utility shows it with a yellow exclamation mark, at least it works
<Kabouik>Yeah well, it reports it has no toner left, which is not true, but probably not related to my Guix config.
<Franciman>thanks antipode
<Franciman>does guix shell --container spawn a container in the sense of docker or podman?
<nckhexen>Kabouik: Is that not there by default? Oh my.
<Kabouik>Unless I did something wrong, it was not, no, nckhexen. I also had to add the cups package in my imports to add cups-filters as extension (I only had the cups service so far).
<nckhexen>Unless you explicitly passed (extensions (list something else)), which you would presumably be aware of, no.
<nckhexen>If it's missing by default that's a bug.
<nckhexen>I mean: the 2 you've 'added' above are a subset of what should be the default!
<Franciman>i don't understand why if i do guix search i only get php 7.4.30, isn't php 8.1 in the repos too?
<nckhexen>I doubt it.
*nckhexen points to the 'packaging welcome!' sign under the 'free waffles sign' we used to lure you in.
<nckhexen>The misplaced ' made that sound more ominous than intended. They are just 'waffles', trust me. Please. Eat the 'waffles'.
<Franciman>i'm not good at packaging yet, i hope to become guix proficient soon
<Franciman>atm i'm using debian, but i plan to switch to guix system
<nckhexen>Cool. & whatever works for you.
<newluhux[m]>I have pack php8, but have some test failed, only use for testing:
<Franciman>newluhux[m]: did you happen to package composer too? (composer the php package manager)
<newluhux[m]>Franciman: no
<Franciman>that one seems to be missing too from guix
<unwox>it's not correctly packaged but should work
<Franciman>unwox: what do you mean correctly packaged?
<Franciman>btw, happy days! Thanks
<unwox>this package just downloads phar binary
<unwox>ideally you would need to package all composer's dependencies separately
<nckhexen>Also, , but note the age & openness.
<Franciman>i see
<Franciman>thanks ppl
<sektor[m]>Is it me, or does pcspkr cause the installer iso tochoke on qemu?
<sektor[m]>Revisiting the work I did on Monday.
<nckhexen>It seems unlikely for one.
<nckhexen>How would that work?
<sektor[m]>I don't know. All I heard was that pcspkr was already registered, aborting.
<bricewge>Hello Guix!
<sneek>bricewge, you have 1 message!
<sneek>bricewge, katco says: FYI your PSA just helped me a lot, ty.
<sektor[m]>bricewge: hwody.
<nckhexen>Does not sound (hah) related to whatever you appear to be experiencing, sektor[m]. (Which is...?)
<nckhexen>QEMU choking is news to me.
<civodul>hey bricewge, welcome back! :-)
<bricewge>I have missed the Guix Days, but I'm catching back. Thanks you to the people who have recorded and uploaded all the videos!
<dgcampea>antipode: the previous paste didn't have 'with-extensions' (for guile-json) but I've since added it. With 'sudo -E' it works but with 'sudo' or 'sudo su' it doesn't find the json module
<antipode> I thought that with-extensions doesn't care about environment variables
<dgcampea>I also get a 'warning: 'guile-json' is deprecated, use 'guile-json-1' instead' when I run guix system reconfigure, not sure if that's relevant or not
<sektor[m]>The corrosponding efforts:
<antipode>dgcampea: Possibly, maybe the module name has changed between versions.
<dgcampea>rekado_: can I mix ' with-imported-modules' and 'with-extensions'? That is, if I want to use both (json) from guile-json and (guix build utils)
<dgcampea>antipode: wouldn't that cause both 'sudo' and 'sudo -E' to have a similar result? (that is, both fail to find the module)
<antipode>dgcampea: I don't think so.
<bricewge>civodul: Do you remember why, you removed provisioning of `networking-$interface` in `static-networking-service`?
<antipode>IIUC, with-extensions only adds stuff to the load path -- if the module is not found among the extensions, it will be searched in the rest (i.e., built-in Guile modules and GUILE_LOAD_{,COMPILED_}PATH)
<antipode>I'm guessing in case of current 'success', it is actually depending on the environment it is run in.
<bricewge>civodul: It seems quite usefull to be able to depend on a specific network interface to be available instead of being limited to `networking`.
<dgcampea>which shouldn't be the case for something like '/var/lib/certbot/renew-certificates' as it's supposed to be manually run as root
<dgcampea>either via sudo or sudo su
<dgcampea>I don't have guile-json in (operating-system (packages (...) )) though
<dgcampea>is it required?
<antipode>dgcampea: No.
<antipode>with-extensions should work, if it doesn't, there is a bug somewhere.
<bricewge>civodul: You've explicitly commented about that removal in but there is no explanation. I would like to bring this back.
<dgcampea>I assume that the gexp with 'with-extensions' is smart enough to automatically handle it
<antipode>dgcampea: Note that Guix depends on guile-json, and you probably have Guix installed, maybe you somehow get a guile-json from there.
<antipode>Apparently it is somehow installed by default, in /run/current-system/profile/lib/guile/3.0/site-ccache/json
<civodul>bricewge: i think that's because the way <static-networking> is structured, there's no connection to one specific network interface
<antipode>dgcampea: I know that with-extension works when used for package phases and computed-file, but I haven't ever used it elsewhere myself.
<antipode>(i.e., not for program-file)
<civodul>bricewge: that is, you have addresses and routes etc., how do you decide whether that should be "networking-eth0" or something else?
<dgcampea>antipode: is a reboot necessary after running a guix upgrade?
<dgcampea>because I did an upgrade before doing a system reconfigure
<antipode>It depends.
<antipode>However, I don't think "guix system reconfigure" cares.
<dgcampea>I'm thinking that maybe the guile modules / environment are somehow out of whack
<dgcampea>it doesn't make much sense for sudo -E to work
<dgcampea>but not sudo
<dgcampea>and with sudo, when I had (guix build utils) I'd get something like this
<dgcampea> ;;; WARNING: loading compiled file /run/current-system/profile/lib/guile/3.0/site-ccache/guix/build/utils.go failed:
<dgcampea> ;;; In procedure load-thunk-from-memory: incompatible bytecode version
<antipode>dgcampea: I think it makes sense for "sudo -E" to work and "sudo" to not work, as they handle environment variables differently, as explained previously.
<antipode>What is your current code?
<mtekman[m]>Hi all, is there a way to directly access the build log after each attempt?... (full message at <>)
<antipode>(Also, I'm wondering if the load paths are added in the wrong place, such that GUILE_LOAD_PATH has precedence over with-extensions)
<antipode>mtekman[m]: IRC does not have multi-line messages.
<antipode>It looks like over here.
<dgcampea>antipode: I have something like this
<dgcampea>I've omitted the non relevant parts
<antipode>mtekman[m]: There isn't.
<antipode>However, usually (with some exceptions, e.g. parallel builds) when building stuff, the log is automatically printed.
<antipode>(during the build)
<antipode>For something less cumbersome than that command: how about copy-pasting the log file name and doing "the-text-editor [paste]"
<mtekman[m]>antipode: ah thanks for the warning
<antipode>mtekman[m]: Except for using an old guile-json version (how about guile-json-4?), it looks reasonable to me.
<antipode>For debugging, you could try building the program-file (separately from the operating-system) and look at how it sets %load-path / %load-compiled-path
<mtekman[m]>antipode: yeah that's what I was doing, but that was even more cumbersome. But okay, thanks for the info
<antipode>It should be feasible to implement such a flag, though.
<dgcampea>this is interesting... going from guile-json to guile-json-4
<dgcampea>gives me: "web/client.scm:84:6: Throw to key `gnutls-not-available' with args `("(gnutls) module not available")'."
<antipode>dgcampea: If gnutls is not available and you are using gnutls (because of https), then you need to add gnutls.
<bricewge>civodul: I see, the old api had in `interface` in it's configuration and only provisioned one `networking-$interface`. Currently `network-address-device` seems the equivalent of the old `static-networking-interface`.
<bricewge>So provisioning `networking-$interface` for each `network-address-device` would be the equivalent.
<bricewge>Or am I missing something.
<mtekman[m]>I have a configure file that is generated after "" is executed during the bootstrap phase. For some reason the shebang is wrong, and I have to manually patch it myself. That's fine, but now there's a script that is generated by configure ("config.sub") that also has a wrong shebang, and I can't patch it at the right time.
<mtekman[m]>Is there a `add-before` hook for specific files?
<mtekman[m]>or are these only applicable to phases
<nckhexen>Only phases, but ./configure must have (or construct) that bad shebang in it somewhere. You should be able to substitute* the equivalent of that ‘echo "#!/bin/sh"’.
<bricewge>civodul: FYI, the context of my questions is the thread « Advanced network configuration »
<antipode>mtekman[m]: The configure file is normally patched automatically, IIUC.
<antipode>If not, maybe use autoconf-wrapper instead of autoconf.
<antipode>Does someone know of a free game for exult?
<antipode>I didn't find anything with a general web search and neither by searching its forum.
<mtekman[m]>antipode: So autoconf-wrapper made my patching redundant, which is frustrating, but nice. But I still get the issue of:
<mtekman[m]>> configure: error: cannot run /bin/sh ./config.sub
<mtekman[m]>So somehow autoconf is still producing using the wrong shell, despite generating the right shell for "configure"
<antipode>Wait, is running './configure'?
<antipode>If so, the relevant Guix phases expect to _not_ do that, you might need to patch that out.
<antipode>(substitute* can be useful)
<mtekman[m]>Ah, yes it is. Should I delete that line? I was wondering why the bootstrap phase was so long and I'd never reach the configure phase
<antipode>On 'should': it's a solution I consider simple, but there might be other solutions too.
<antipode>If you have another solution, it's not wrong per se.
<mtekman[m]>Oh wow that's beautiful, for the first time it's not getting stuck in the bootstrap phase and is actually considering configure as a seperate phase!
<mtekman[m]>Wow I should really say something to the upstream author
<PotentialUser-51>Hi all, I have literally no idea where I should even start with something like this, but kernel 5.19.12 causes my screen to flash on boot and seems like it's been known to damage screens. Because Guix is awesome I could just roll back but still. Seems like it's fixed in 5.19.13. Where should I be leaving stuff like this?
<PotentialUser-51>Particularly intel laptop displays it seems
<antipode>PotentialUser-51: I expect that Linux people appreciate bug reports, especially if you sent them _early_ and with helpful information 'this version works, that version doesn't'
<antipode>I don't think Guix can help much with this except for providing previous versions for a while longer.
<PotentialUser-51>The bug has been fixed and a new stable kernel has been released that fixes the regression, I'm wondering where I should report this to so guix can catch up :)
<PotentialUser-51>Or where the docs are that would cover this info
<antipode>In that case, given that linux is a rather essential component, you can send a bug report to bug-guix, or preferably a patch updating it to the new version.
<antipode>(to guix-patches)
<PotentialUser-51>I'm new to actually interacting with projects lol, usually just sit on the sidelines. So there's a list of people subcribed to bug-guix and if I want to report a bug then I send it to and everyone subscribed gets it? Just don't want to annoy a bunch of people is all, pardon my asking so many questions :)
<antipode>Yes, and a copy appears at
<PotentialUser-51>Ok cool so if I read some other examples at to get the gist and then send an email to bug-guix that's good?
<antipode>PotentialUser-51: I think the Guix manual has some information on bug reporting, but yes.
<antipode>(Not-up-to-date software usually isn't considered a 'bug', but Linux is a rather essential component ...)
<PotentialUser-51>Makes sense, I'll report this now then make sure I read the docs proper for the future. Thanks heaps :D
<rekado_>Intel recommends to avoid this kernel version.
<rekado_>all we can do is to update the kernel
<dgcampea>is there a command to find what package provides a certain file? (gitk, dig, ...) ?
<unwox>dgcampea: IIRC if file is not already in /gnu/store then no
<mtekman[m]>I just realised that `git build -f <file>` gives me exactly what I want in terms of seeing the build process in real time
<rekado_>“guix install” can also be made more verbose; in fact, it used to be just as verbos
<mtekman[m]>do you guys know how I can test patches for my test build? I create a folder called "patches" in my cwd, but guix doesn't seem to find it. Do I literally need to add them to "share/guile/site/3.0/gnu/packages/patches/", or is there a better way?
<mtekman[m]>(also, as a read-only filesystem, I can't copy them into the guix tree)
<apteryx>I think the search-patches mechanism look into your %load-path
<rekado_>mtekman[m]: the manual has a section on how to contribute, which shows you what a good setup looks like
<rekado_>mtekman[m]: you shouldn’t modify files in /gnu/store
<rekado_>instead get a copy of the source code from git and work on that
<civodul>we have a problem with icu4c on core-updates:
<rekado_>unbound variable icu4c-71
<civodul>hmm i was connected to berlin, then my session froze, and now i can't connect anymore
<civodul>oh it's back
<civodul>mbakke: hi! how's 'staging' going? where's help needed? :-)
<apteryx>civodul: must be on your network, I'm connected to berlin and there's no freeze
<apteryx>or it could be IO related, I'm running an expensive 'compsize /mnt/btrfs-pool-san' to learn the current number of extents
<civodul>apteryx: maybe that was it, it lasted for a couple of minutes
<apteryx>although looking at 'atop', compsize doesn't seem to be very IO-heavy. Sorting by disk activity with 'D', it shows postgresql at the top, writing hundreds of MiB/s
<apteryx>that doesn't look normal to me
<mtekman[m]>for anyone searching the logs: you can directly set the patches of your test packages by providing the full filename.
<mtekman[m]>`(patches (search-patches "x" "y" "z"))` would then become `(patches (list "/path/to/x" "/path/to/y" "/path/to/z"))`
<mtekman[m]>But I guess you have to submit the patches manually later (or before you submit the package??)
<apteryx>mtekman[m]: you should really set up a development environment following what rekado's suggested though (the reading their hinted at)
<apteryx>that'll give you a whole library of examples to compare with too
<apteryx>(the guix source code)
<civodul>apteryx: i noticed that mumi triggers lots of i/o activity too (when indexing messages i suppose)
<mtekman[m]>Thanks - I have the guix source code, and I'm rg'ing through it regularly for scm examples. I also have the manual open at different sections in several tabs. But sometimes those things aren't enough, and you just need to talk with experts
<civodul>apteryx, nckx`: i'm running "guix deploy berlin-nodes.scm"
<civodul>i'd like to get those childhurd builds back
<apteryx>mtekman[m]: if you put your patch in gnu/packages/patches/package-name-description.patch, 'search-patches' should find it
<rekado_>civodul: indexing is indeed expensive
<rekado_>we might be able to make it a little bit lighter
<civodul>rekado_: or we chould ionice it :-)
<rekado_>yes, good idea
<mtekman[m]>apteryx: thanks!
<apteryx>mtekman[m]: you're welcome!
<rekado_>I used to tell Guix users at the MDC to run “guix upgrade” after “guix pull”, so that “guix install” doesn’t leave them with conflicts
<rekado_>but it has now happened a few times that “guix upgrade” is not enough
<rekado_>with R packages and propagation they often end up with profiles that are no longer to be upgraded according to “guix upgrade”, but that still are inconsistent with newly installed packages
<rekado_>the workaround I recommend then is to temporarily (or permanently) switch to manifests with “guix package --export-manifest > moo.scm” and “guix package -m moo.scm”
<rekado_>that’s like an unconditional upgrade
<rekado_>the semantics of “guix upgrade” appear to be more complicated than I thought.
<apteryx> I don't understand how 'guix upgrade' could lead to conflicts, unless package definitions in Guix or user channels propagate conflicting things
<apteryx>(which installing from a manifest wouldn't change anything about)
<rekado_>I’ll try to gather some evidence so we can understand it better
<lispmacs[work]>I've been using Guix exclusively for about 2 years, but I still find myself typing "apt-get update"
<rekado_>time for an alias?
<civodul>rekado_: re "guix install" and all, i think we should advocate for "guix shell" only in the context of research workflows
<civodul>Konrad made this point and i think he's right:
<Kabouik>Re "Unless you explicitly passed (extensions (list something else))" nckhexen: no, I didn't, I tried without passing extensions at all, and the printer would not print. After I added extensions (just cups-filters and hplip-minimal), it did. Please do not exclude that I did something else wrong, or badly tested and resolved the issue coincidentally on top of adding the extensions manually. I did fiddle a bit with the cups web UI, so maybe I solved the
<Kabouik>issue there without noticing and not in my config, but I doubt it.
<rekado_>civodul: I watched Konrad’s talk and I agree.
<rekado_>still, there’s boring software in the default profile that gets installed and upgraded
<rekado_>especially people coming from a conda background have strong habits that are not easily dropped in favor of a “guix shell” workflow.
<civodul>rekado_: right, but "boring software" is typically not things required for the research thingie, is it?
<civodul>another takeaway of Konrad's talk is that we need to come up with activity focused how-tos
<civodul>like how to use Guix for reproducible research
<civodul>(i'm trying to trick a colleague of mine into starting this one :-))
<tricon>civodul: i like the activity-focused how-to approach. i've been thinking of how we could expand the Guix documentation lately. the current documentation has good top-down and bottom-up content; yet there's a place for supplementary, higher-level "what problem does this solve/what is the benefit" and "how do I get from here to there" for various problem domains and intents.
<unmatched-paren>hi guix :)
<tricon>of course these don't necessarily merit inclusion in the official Guix manual and reference, but i'm percolating a "Guix course" that could be valuable.
<rekado_>tricon: would it fit into the cookbook?
<tricon>imho, presently the documentation is great for programmers and lower-level nerds (interpret that how you will). i'd like to get to: "here's my friend that is a general sys admin. let's enroll them in the superiority of the Guix approach and create confidence as they learn."
<tricon>rekado_: some could like there, yes, i think.
<tricon>*live there
<tricon>i think the lowest hanging fruit for improving the documentation (and i'm speaking to myself here) would be more examples.
<tricon>i personally grok things extremely quickly just by looking at an example, and it becomes useful copypasta for non-Schemers and those that want to focus on creating a, say, system config.
<PotentialUser-52>Hello. How can I run appimages on guixsd?
<xd1le>hi guix
***mark_ is now known as mjw
<drakonis> neat
<drakonis>see scalar
<PotentialUser-52>No. There's no easy way to run appimages.
<PotentialUser-52>Which is why there is no information anywhere on it.
<civodul>anyone tried to have a childhurd with 'disk-size' set to 12G or similar?
<rekado_>for the record: a self-contained appimage could be run by patching the loader or making the glibc package’s available at /lib64/
<rekado_>civodul: does the hurd work with a larger disk…? I thought it only supported up to 4GB.
<cbaines>I think the 4GB thing is something about memory, since it's 32 bit
<cbaines>I don't think there's a limit in disk size
<rekado_>“The ext2fs translator from the upstream Hurd code base can only handle file systems with sizes of less than roughly 2 GiB.”
<rekado_>this might be out of date, but I remember real storage limits when I played with the hurd.
<drakonis>with hurd's glacial pace, it may or may not be out of date
<drakonis>you never know until you run into them
<rekado_>I don’t know if we’re using the patch they mention there
<podiki[m]>rekado_: for appimages, if you have the offset (sadly need to run the appimage with an option to get that output) you can then just mount it as a disk image
<podiki[m]>I only know (don't normally use appimages) from my tests with the fhs container; can't run it directly as it wants setuid fuse to mount if I remember
<klm_>nckhexen: Oh, I didn't think of that! C-z'ing a `guix build …` probably didn't work then. I will will retry it sometime and double-check. Thanks for the tip.
<unmatched-paren>is there someone available who could review this patch? <- ludo reviewed the first version, but the second version has as yet gone unreviewed :)
<cbaines>in a somewhat related point, the QA frontpage patches page is now ordered in a hopefully more useful way
<antipode>I wonder, were the horns and numbers on the birthday cake edible?
<cbaines>it takes in to account both the builds for affected packages, plus the moreinfo tag
<nckhexen>Kabouik: Would you mind sharing /var/log/cups/error_log? (I fear the default log level might be useless, but it's worth a shot.)
<cbaines>I mention this now because #57031 happens to be at the top of the list (being the oldest issue with a green dot)
<unmatched-paren>cbaines: qa already looks like a really useful service, thanks for working on that :D
<PotentialUser-52>following up on appimage question, lost connection
<apteryx>cbaines: hurd is even to address more than 4G of memory, even running if it's 32 bit (I forgot the details)
<antipode>nckx: Cryptobot ^ 'matrix_help[m]'
<unmatched-paren>antipode: i think it might have been autobanned
<antipode>Now I see
<tschilptschilp23>hi guix!
<unmatched-paren>tschilptschilp23: Hello!
<nckhexen>…but heads-up are always welcome. You missed me by a coffee.
<antipode><insert greeting sound here>
*antipode packaging some SRFI-NNN
<antipode>I forgot (when tests? ...), err ...
***nikola` is now known as nikola
***nikola is now known as nikolar
***nikolar is now known as nikola_r
<podiki[m]>hi guixers
***nikola_r is now known as nikola
<tschilptschilp23>mhm, e05e534 still seems to be the last commit to have my gnome-desktop properly going. to clarify what I mean -- evolution and password-safe are the tools, that mainly make gnome attractive to me (despite the functionality of gnome-shell itself). starting the latest with 08d5152 (secrets-6.5 taking over password-safe 5.1), secrets/password-safe crashes on opening existing .kdbx-files, and cannot create new ones anymore, this is valid
<tschilptschilp23>for bb3b810, 17134b9, and today's fd6cd9d as well. At least the latter two ones also break evolutions' ability (v. 3.42.1 -> 3.46.0) to read my existing evolution files (mails, etc) in ~/.local/share/evolution. I've previously mentioned the broken gnome-maps launcher, this one also still seems to be broken. What mess do we have going on here (I'm talking about not changing my system, nor home-config, just pulling and reconfiguring
<tschilptschilp23>Sorry for the rant, but thinking about how to broaden the userbase, this is wild. It actually makes the possibility of a rollback a necessity to stay functional. A possibility I like a lot :)
<tschilptschilp23>not changing the home-config is a bit of a lie, I've added keepassx to it, just to be able to read some encrypted files, once secrets cannot anymore ;)
***nikola is now known as nikolar
<tschilptschilp23>(no wayland here [at least to my knowledge], just default xorg)
<reyman>is search why a system reconfigure doesn't take into account the new commit for one of my channel
<reyman>guix pull don't take the new commit describe in my .config/guix/channel.scm
<reyman>even if i force : guix pull -C ~/.config/guix/channels.scm
<shcv[m]>why exim or opensmtpd vs e.g. postfix? (just looking at the available MTAs...)
<nckhexen>shcv[m]: Because someone wanted to use them.
<podiki[m]>see the new intel gpus have reviews, seems (as expected?) firmware blobs required
<podiki[m]>basing this on the phoronix article mentioning linux-firmware needed along with 6.0 kernel and latest mesa
<lilyp>tschilptschilp23: how exactly is evolution broken for you?
<reyman>hum going back on generation, emacs and firefox are back, but i don't understand why they disapear with recent guix pull / reconfigure
<tschilptschilp23>lilyp: it wants me to put in all my email-accounts again, like this information would not exist on my computer and does not see my caldav-calendar anymore basically.
<tschilptschilp23>switching back to the old version makes all the information 'visible' immediately.
<dgcampea>how does the 'free-form-args' parameter of 'override-fields' for dovecot userdb-configuration work? There's no example of it and I can't seem to get it working
<tschilptschilp23>I think I can contribute a little more information, but will need a restart for that (and write it down this time, there was something visible when starting it from bash). back in a moment.
<lilyp>there was a bug in 3.45 that asked you to set up an account even if you had one; afaik that ought to be fixed with 3.46
<lilyp>in any case, your folders should still exist
<tschilptschilp23>yes, they absolutely do, switching back to 3.42.1 makes things 'normal' again, there's zero data-loss. I'll just go to 3.46 and note the error it tells me, and also the one from secrets (I've deb-pasted a few days ago, but they will have expired by now...)
<tschilptschilp23>nothing dramatical, it's just that the new gnome-terminal looks very attractive and would like to use it without fighting with inferiors and the like ;)
<tschilptschilp23>so, now on fd6cd again.
<rekado_>shcv: there’s a branch with postfix
<rekado_>it was just never completed
<rekado_>would you like to adopt it?
<tschilptschilp23>gnome-maps: launcher from activities does not do anything anymore.
<tschilptschilp23>but calling gnome-maps from 'console' (before that labelled 'terminal') works. There are a few warnings (, but things seem fine.
<rekado_>shcv: see here:
<lilyp>tschilptschilp23: that's a separate bug I'm already working on; give me the evolution stuff
<lilyp>sorry, I don't speak gnome debug output
<tschilptschilp23>what should I give you? Evolution just greets me with the setup-wizard like at first-time contact...
<lilyp>yeah, but if you exit that wizard you ought to still have your mails, right?
<lilyp>i.e. if you don't set up anything
<tschilptschilp23>well, then I have my mails in my homedir, but not in the evolution gui
<tschilptschilp23>I'm actually thinking about doing a backup on 3.42.1 and import that one to 3.46.0, but that feels pretty cumbersome
<lilyp>hold on a sec... you have mail in your home directory?
<tschilptschilp23>I guess so, at least information about the imap sync-state, hold on, I look what's actually there
<shcv[m]>rekado_: cool
<tschilptschilp23>assuming evolution stores this information in ~/.local/share/evolution/mail, there do not seem to be mails there, it looks like a directory structure and that's it
<lilyp>I'm pretty sure evolution does not directly store mbox files.
<faust45>hi guix!
<tschilptschilp23>but it seems to have rather fancy directories :)
<faust45>i need your help! i what to replace xfce with stumpwm but dont know how to do this in right way
<tschilptschilp23>lilyp: this is what secrets says, when I try to open an existing file:
<lilyp>I don't use secrets and I find it annoying that for its name it doesn't even have a libsecret binding.
<tschilptschilp23>looks like I'm migrating back to keepass. or properly to gnus and passwordstore. but then i'd kind of lose my connection to gnome :)
<tschilptschilp23>rolling back now, this is not nice that way.
***nikola` is now known as nikolar
***justache is now known as justHaunted
<jab>Hey guix! I have some good news!
<jab> My first debbugs contribition. It adds an debbugs-gnu-guix-search command that by default only searches for guix related bug reports!
<jab>The maintainer of debbugs was super ok with my changes, so if you have an idea for making debbugs for guixy, just add your changes to debbugs-guix.el. You'll have to sign copyright for Emacs though. :)
<vagrantc>jab: in the commentary debbugs-get-buy-by-id -> debbugs-get-bug-by-id
<jab>whoops! Thanks! Hopefully the reviewer caught that. If not, then I'll have to let him know.
<vagrantc>jab: looks like i was reading the older version of the patch ... was there a newer one?
<vagrantc>jab: newer version(s) look fine
<jab>vagrantc: awesome!
<vagrantc>gotta remember to scroll down when reading bug reports and not comment on the first thing i see :)
<jab>I wonder if debbugs-gnu-guix-browse-url-bug-in-qa would belong in debbugs...? It would obviously open the bug in
<jab>and do we want a debbugs-gnu-guix-browse-url-bug-in-issues ? to open the bug in ?
<lamp140>i recently installed the emacs-ement package and emacs cannot launch the package within emacs. Why?