<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>though deleting it doesn't completely solve it <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" <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>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>GNUtoo: is that 1KB troubling? Is it a mystery binary? <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... <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>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 <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 <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>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 <daviid>GNUtoo: in guix, try change your locale temporarily <GNUtoo>I probably don't want to use "C" to create the database <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>(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 <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>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) ***rgherdt_ is now known as rgherdt
<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>one question. I'm using guix on a foreign distro. Can i create a guix shell in which i specify services to start? <newluhux[m]>you can use `guix system vm --expose=$(pwd)=/var/www` ***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>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? <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>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>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 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 <Franciman>newluhux[m]: did you happen to package composer too? (composer the php package manager) <unwox>it's not correctly packaged but should work <unwox>this package just downloads phar binary <unwox>ideally you would need to package all composer's dependencies separately <sektor[m]>Is it me, or does pcspkr cause the installer iso tochoke on qemu? <sektor[m]>I don't know. All I heard was that pcspkr was already registered, aborting. <sneek>bricewge, you have 1 message! <nckhexen>Does not sound (hah) related to whatever you appear to be experiencing, sektor[m]. (Which is...?) <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 <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>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>I don't have guile-json in (operating-system (packages (...) )) though <antipode>with-extensions should work, if it doesn't, there is a bug somewhere. <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. <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>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>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>(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>However, usually (with some exceptions, e.g. parallel builds) when building stuff, the log is automatically printed. <antipode>For something less cumbersome than that command: how about copy-pasting the log file name and doing "the-text-editor [paste]" <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. <mtekman[m]>I have a configure file that is generated after "autogen.sh" 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? <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 autogen.sh running './configure'? <antipode>If so, the relevant Guix phases expect autogen.sh to _not_ do that, you might need to patch that out. <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? <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 :) <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. <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 bug-guix@gnu.org 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 issues.guix.gnu.org <PotentialUser-51>Ok cool so if I read some other examples at issues.guix.gnu.org 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>hmm i was connected to berlin, then my session froze, and now i can't connect anymore <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 <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 <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 <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" <civodul>rekado_: re "guix install" and all, i think we should advocate for "guix shell" only in the context of research workflows <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. <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>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. ***mark_ is now known as mjw
<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 ld-linux-x86-64.so.2 available at /lib64/ld-linux-x86-64.so.2 <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 <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. <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 <apteryx>cbaines: hurd is even to address more than 4G of memory, even running if it's 32 bit (I forgot the details) <nckhexen>…but heads-up are always welcome. You missed me by a coffee. *antipode packaging some SRFI-NNN ***nikola` is now known as nikola
***nikola is now known as nikolar
***nikolar is now known as nikola_r
***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
<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 ;) <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>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 <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>i need your help! i what to replace xfce with stumpwm but dont know how to do this in right way <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 :) ***nikola` is now known as nikolar
***justache is now known as justHaunted
<jab>Hey guix! I have some good news! <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>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 qa.guix.gnu.org <jab>and do we want a debbugs-gnu-guix-browse-url-bug-in-issues ? to open the bug in issues.guix.gnu.org ? <lamp140>i recently installed the emacs-ement package and emacs cannot launch the package within emacs. Why?