IRC channel logs
2023-05-06.log
back to list of logs
<zacchae[m]>oh wow, guix git repo is over half a gig? That must incude some binaries, no? That would be a LOT of source code <lilyp>it shouldn't include binaries <zacchae[m]>lilyp: Really? I think guix used to have more binaries in the past, but maybe they weren't checked in to git. If that's the case, we should celebrate if we ever reach a full GiB! <lilyp>wdym more binaries? if you mean we didn't always have full source bootstrap: sure, that's true, but those packages were pointing to binaries in the web <nikita>git can grow a lot for just text. pkgsrc-wip (went from svn to git at some point), 20 years, .git alone has almost 600 mb <mirai>there's also the translation syncs <zacchae[m]>crosses fingers as he builds a profile with updated gcc <mfs5173>does anyone know if there's any reason I wouldn't be able to `guix deploy` to an installation image running on a usb with cow-store running? <lemos[m]><zacchae[m]> "lemos: ./pre-inst-env is..." <- oh <lemos[m]>thanks, i will check again and look for things i missed <zacchae[m]>mfs5173: generally, USB images are static, so guix deploy doesn't make much sense as it would reboot to a reset environment <ae_chep>So libffi@3.4.4 is in main channels, and so is glib@2.73.3. Glib requires libffi@3.3 . Does that mean we're due a glibc update? <bdju>gentle reminder (to no one in particular) about bug #63239 which I suspect didn't hit the mailing list properly but is viewable in the web ui <ae_chep>And then zlib also brings up conflicting entries. First entry zlib@1.2.13 (prop from glib@2.72.3) second entry zlib@1.2.11 (prop from glib@2.73.3) . I don't know how to fix this (on a foreign distro) <lilyp>Ehm, why are you pulling in two versions of glib? <lilyp>Note, glib != glibc – the former is a basic library for GNOME, the latter is the GNU libc. <jgart[m]>>adding #:allow-other-keys to the definition will ignore unknown keywords. <jgart[m]>then it goes off on a tangent about #:rest unrelated <jgart[m]>no examples of common usages or mental model for using it <iyzsong>maybe actually no use for passed but not named keyboard arguments? (aka ignore) <mfg[m]>zacchae: if you build the package with guix, then gcc should find libstdc++ and use it correctly. But yeah for binaries you need a workaround, there have been discussions about it on the ML, I think <jgart[m]>is there a way to disable tests currently from the CLI when running guix build foo? <jgart[m]>should the following run the tests or not run the tests? <jgart[m]>guix build vis --without-tests=nnn --check <GNUtoo>jpoiret: thanks a lot for the help yesterday, I finally managed to make it work with -e '(list (@@ (gnu packages commencement) gcc-final) "lib")' (I needed 2 @ else it would complain about not finding gcc-final) <ennoausberlin>cy in my channel. So guix pull takes forever and runs out of memory finally. What is the best way to debug this? I suspect python-pytest@3.7.1 <ae_chep>lilyp: I am _not_ pulling in multiple versions of glib. It's why I'm saying I don't know how to fix this <ngz>This sounds like a lot of fun. <unmatched-paren>(it is, unfortunately, The Coronation [mentally add exaggerated flowing handwriting] today...) <fiesh>I was hella stoked, but they reduced church service from traditional 3 hours to a measly 2 hours :-((( <roooy[m]>!!! Enjoy the most profitable financial market (crypto market ) as you get 100% profit...and you can also make up to $100k or more in 3days send me a private message and ask me HOW on TG <rekado>after the core-updates merge I updated another laptop; now ibus no longer works <rekado>by that I mean that ibus only sees xkb input methods <rekado>it does not see the installed ibus-libpinyin <rekado>any ideas how to configure the libpinyin input method? <next4th>fcitx5 is working for me, let me try ibus.. <rekado>it’s as if ibus no longer respects the IBUS_COMPONENT_PATH <rekado>(I moved the old registry cache out of the way, because it contains references to now outdated locations in /gnu/store) <rekado>the new registry does not include the locations for libpinyin <rekado>I deleted the registry *again* and then recreated it by restarting the ibus daemon with “ibus restart” <next4th>rekado: yes, i can't use libpinyin, but ibus-rime works.. <rekado>the new registry file now *does* contain references to ibus-libpinyin <rekado>configuring the input method fails, though <rekado>ibus-setup-libpinyin fails with a gi error, so maybe it needs to be wrapped <rekado>about that registry: we should generate it in a profile hook, so that it always corresponds to what has been installed <rekado>it could be a problem that not all input methods will be installed in the same profile (e.g. user profile + system profile) <next4th>rekado: yes, that's the problem. btw ibus-libpinyin works for me too (using gsettings keyfile backend, since no dconf in my xfce) <rekado>next4th: I don’t think this would help on its own. We need to generate the registry at a time when the only thing Guix knows is the *current* profile. <next4th>well, profile hook can only build for one profile though.. <rekado>so these would be multiple steps: extend ibus to look for registries on a search path, generate an IM registry in a profile hook, extend ibus to merge multiple registries, then set search path to system and user profile. <rekado>the profile hook generating the registry for the user profile cannot know about the system profile <rekado>so we need to change ibus to look in more than one location and merge the info. <next4th>yeah, or disable the register cache, always lookup all components at startup. need to see the code to make a choice.. <next4th>rekado: if i read the code of ibus right (ibusobservedpath.c), it use file_hash in addition of mtime, so it should works on guix too. only need is to merge IBUS_COMPONENT_PATH from multiple profiles. <minima>it looks like the search engine on logs.guix.gnu.org is stuck at jan 2023? what i mean is that it doesn't seem to report any result past that time, like if it needed a nudge or something? <rekado>it’s just really low priority, it seems :) <rekado>it’s been like this for months and it gets updated whenever someone re-inits the db <rekado>but it should actually do this automatically <rekado>there’s a bug in that service, and I haven’t been able to make time to investigate <minima>it also looks like some days don't show up on the log page (e.g. the first few days of the last couple of months) <minima>unrelated, i seem to get this error that says "libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE" <minima>here's what i did: i entered my local guix checkout, run git pull, then launched "guix shell --pure -D guix help2man git strace", then finally "./pre-inst-env guix search hello" <minima>(incidentally, i suppose it's good practice to follow git pull with make authenticate?) <rekado>minima: that’s another known bug. The logger fails to close the log file for the last day of the month and keeps logging. <rekado>until we restart it it just keeps appending to the old log file <rekado>so the logs are all there, just in the wrong file <rekado>one day I’ll fix it if nobody else feels strongly enough about it to patch it. <minima>oh i see, sure, that's fine - thanks <rekado>at the end of the last day of the month the current day will not be < than (tm:mday time). <minima>oh i see, yeah it has to check the month too - well and the year, otherwise it'd also fail on 1st Jan <mirai>wouldn't it be better to leave this to rottlog (or another log rotator) instead? <mirai>goggles-bot simply writes to a file and upon receiving a SIGHUP/SIGUSR1/etc. “reopens” the file it logs to (which can then be implemented as a 'reopen action on shepherd) <rekado>mirai: sounds good. I’d be happy to apply patches to that end. <rekado>minima: yes, at new year I noticed it first. <minima>although in my case, it's triggered by a "./pre-inst-env guix search hello" instead <rekado>have you touched/edited anything in /gnu/store? <rekado>consider using guix gc --verify=repair,contents <rekado>the above command should be able to fix it <TristanCottam[m]>I'm already getting a bunch of path /gnu/store/(...) was modified! warnings <mirai>apteryx: do you see a $XDG_RUNTIME_DIR/mpd/socket file for the mpd user? <ngz>rekado: May you ping me when you have some spare minutes? I'd like to discuss one small idea about texlive build system with you. Thanks! <mirai>do I need to do anything after guix install emacs-debbugs to get it working? <mirai>M-x debbugs-gnu isn't recognized <juli>does anyone know why i might be getting an "error: output: unbound variable" when using `#$output' in a g-expression? there are other packages in this file using g-expressions so i know the module is imported; i see other packages in this file which use `#$ouput' in analogous positions <juli>huh, turns out the issue is... using it inside a `#$(file-append ...)' form??? <juli>i switched it to `(string-append #$ouput ...)' but the documentation explicitly demonstrates `#$(file-append output ...)' <juli>(type here, not in the code) <Sughosha>Hey all, is there any update on the update of GNOME to 43 in Guix? GNOME has r <Sughosha>Gnome has already released version 44, but in Guix we are still on version 42. <janneke>civodul: silly question, why not use/make a guile-gnutls tarball release? <juli>wait does `file-append' not work with output??? <cbaines>juli, I don't think it would, just because you can ungexp output, doesn't mean it's valid everywhere a gexp is <cbaines>file-append should work with any gexp though <cbaines>juli, where did you see (file-append output ? <juli>I was mistaken; it was coreutils not ouput <juli>although i've run into an interesting new issue... which is that i can't make commits to my local checkout of the Guix repository? <juli>for gpg-related reasons? <old>oh my god. thanks for the person that added with-configure-flags transformation <darosior>Hey all. I'm trying to get my Rust program to build against an older glibc in a Guix container. For now i'm simply trying with glibc-2.29. I've got a toolchain using `make-gcc-toolchain`. I'm trying to get rust to be using this toolchain using `package-with-c-toolchain`, but i keep getting an obscure scheme error when building the derivation. I may <darosior>be misunderstanding the "label" argument of `package-with-c-toolchain` there.. <ieugen[m]>hi, anyone know why I can't install a pacakge (tree-sitter-cli) from guix channel, even though I have the channel and I have guix pull just now ? <ieugen[m]>guix install: error: tree-sitter-cli: unknown package <civodul>janneke: yes, we'll have to use a tarball <civodul>it's kinda backwards from a bootstrapping perspectives <elevenkb>let's say you're offloading based on a custom guix installation. does guix automatically send itself over SSH to the build server? <civodul>elevenkb: hi! when offloading, the machine you offload to must have Guix already installed <civodul>it doesn't have to be Guix System, but the 'guix' command must be in $PATH and guix-daemon must be up and running <mihi>about bootstrapping: When next Guix version is released and I install it on a foreign distro, then install a package written in C without using substitutes, will it bootstrap gcc all the way from M2-Planet or will it use the gcc of my host distro? And if the former, will it download the guile seed or will it use my host guile? <mihi>nvm, got an answer in #bootstrappable already :) <vagrantc>mihi: using the debian packaged guix it cannot use the host guile for anything guix builds, because that is not available to guix-daemon's build environment <vagrantc>mihi: the debian-packaged guix is basically a trust path to get to running guix stuff (e.g. you already trust debian's keys, install the debian guix, run guix pull, now (most of) your guix operations are running guix binaries for everything <vagrantc>you basically can't get reproducible builds of guix stuff by using debian's guile ... so the debian guile bootstraps to the guix guile, if that makes sense <mihi>yeah, it does. It contradicts janneke's point that "guile is just a driver for the bootstrap and should not affect any resulting binary", but I understand why you did not want to run the risk. <lilyp>On one hand, yes, Guile is just a driver, but at some point implementation details start to matter