<nckx>That said, supported != working, there's no reason not to try again if you haven't tried it with GRUB 2.06 yet.
<excalamus>I'm trying to figure out why icons aren't showing up in the Plover gui. The core dev there says that whatever is in the wheel should be included. I checked and they are, in the guixified location, site-packages/plover/assets. He asked about how it was packaged. Since it's using the python-build-system, that should about python setup.py install.
<excalamus>I had wondered if they needed to be run through pyrcc or something, but he didn't respond to that, so I assume not
<apteryx>lilyp: I think by the time we get around to pep 517, setuptools might have grown support for it (if it hasn't already)
<excalamus>looks like the assets are supposed to be accessed through the Qt resource system and are generated using some separate script
<excalamus>Plover expects that the =plover/gui_qt/resources_rc.py= generated by the build_ui phase gets called. Looks like that calls sys.executable, '-m', 'PyQt5.uic.pyuic',
<excalamus>that's what he says, but I also see a _build_resources code path that calls PyQt5.pyrcc_main, more like I would have excepted. Same difference, in a way. Looks like Guix needs to run some external script
<excalamus>interesting, looks like that's output to the log twice.
<robin>interesting, hexchat context menus turned into pure tofu after a 'guix upgrade' (and back to normal after a restart). probably a difficult sort of problem to solve in general
<excalamus>robin, thanks, I'd heard of it, but not read much into it
<robin>(i'll file a bug if i can reproduce it easily; perhaps it's a tractable problem related to profile hooks)
<excalamus>so, the plover/gui_qt/resources_rc.py file is created during the build. Not sure if that's supposed to be called automatically. If not, how would I go about calling that during guix building?
<excalamus>something like in the configure phase is my guess
<excalamus>okay, I see the phase outputs are labeled during build
<excalamus>looks like the resources_rc.py is generated in two phases, patch-generated-shebangs and in build. That explains why that appeared twice in the log. I assume the first time is for correcting a shebang, the second time for running through the setup.py? Are the build messages coming from Guix or from Python?
<robin>excalamus, what are the relevant build messages? (and you're correct about patch-generated-file-shebangs)
<robin>(or the build messages in general if it's easier to paste the log)
<apteryx>nckx: did you have a chance to try rtl8812au-aircrack-ng-linux-module? it nows builds fine, but still seem to have issue with the latest kernel (not sure why, but the interface appears as DOWN, and I couldn't find a way to make it UP -- perhaps I'm just being a noob).
*apteryx wants to test cufbc but keeps running into error: corrupt input while restoring '/gnu/store/bfs2wy8k4724az8r40vwainmh3axbc99-guile-ssh-0.13.1' from #<input: string 7f4d538a2690>
<robin>excalamus, to me they look more likely to be python build output. re: running it during the build, that depends on what it does, if it's even supposed to be run at build-time...
<excalamus>I think you're right. It's the resources.py file which needs to exist in the output. It's created but not copied, I guess
<excalamus>as I recall, the Qt build system writes resource files, pngs etc., to a python file as hex so that it's all in one spot. Then the resource system loads that
<apteryx>uh, the guix substitute process strace says: write(2, "In procedure lstat: No such file or directory: \"/gnu/store/bfs2wy8k4724az8r40vwainmh3axbc99-guile-ssh-0.13.1\"\n", 110) = 110
<excalamus>I got mixed up and thought the resources.py was the file which did the encoding. So, then I should be making sure that resources.py file gets copied. I'm upgrading packages now, so I'll have to try tomorrow morning. Not having done this before, my thought is to try using "arguments" with an after-build and using either copy-file or install-file
<robin>seem odd that the upstream install "phase" wouldn't copy it
<robin>i'd copy after the install phase, i think, since the output directory is more likely to already exist (before/after install because sometimes e.g. the check phase is between build and install, depending on the build system)
<apteryx>oh, seems --keep-failed is potentially dangerous; it causes the daemon to keep the derivation result in its cache *as* the result of the derivation (i.e., it doesn't differientiate later if it's a failed or succeeded one, at least from my testing so far)
<apteryx>that's how I got into that corrupted guile-ssh and ensuing 'corrupt input while restoring' message
<apteryx>actually, the deadly combo seems to be --check --rounds=N and --keep-failed
<vagrantc>ah, rekado updated diffoscope on core-updates-frozen
<apteryx>e.g., try: guix build --rounds=2 --check --keep-failed hello then stat the result
<apteryx>stat: cannot statx '/gnu/store/a462kby1q51ndvxdv3b6p0rsixxrgx1h-hello-2.10': No such file or directory
<vagrantc>hah, those were not that tests that were failing for me :)
<apteryx>clarification, only when using the above three options (--check, --rounds and --keep-failed) does it cause an empty store item to get registered
<apteryx>oriansj: it's a shame it doesn't mention a build log to look at; perhaps try rebuilding the problematic drv with 'guix build /gnu/store/234k0ms25z6w84f97qjxq36fwmzlkwml-guix-daemon-1.3.0-10.c3c5028.drv' to learn more?
<shoshin>hello! i've tried to set up unattened upgrades service, but it appears to not be running. i'm also not getting a log, but i found this in the mcron.log: ERROR: Couldn't read /var/log/unattended-upgrade.log file!
<vats>Hello, I'm trying to install a guix system with LVM on LUKS. I have one unencrypted partition mounted at /boot/efi and / and /home are on logical volumes in an encrypted physical volume. Moreover, /boot/grub is inside the encrypted root. The system fails to boot (grub doesn't load). Does /boot as a whole need to be left unencrypted or is leaving only /boot/efi unencrypted sufficient?
<drakonis>but why are you spending so much time looking for a distro instead of just statically linking libcurl yourself?
<shoshin>when running guix system, it seems i need to run `guix pull` as root to update, is this correct?
<safinaskar>drakonis: it seems you don't understand my question. let me repeat
<safinaskar>drakonis: first, libcurl is obviously the library, not binary
<safinaskar>drakonis: second, libcurl depends on lots of other libs, i will call them A, B, C etc
<safinaskar>drakonis: also i have simple program in C (this is program, not library)
<safinaskar>drakonis: the program depends on libcurl (and libcurl depends on A, B, C)
<cehteh>civodul: what do you think about my idea about abadoning the config.scm once the system is set up either by guix system reconfigure [--current] or guix system reconfigure --edit which both gettting the current config out of the store
<lilyp>I think we an make it optional, but in-place editing is not preferable to a plain file
<cehteh>eventually leading the path to having configury commands in guix system like guix system install openssh-service
<lilyp>Also, doing things via CLI feels kinda wrong – it'd be better to have a GUI or at least an editor plugin (*cough* emacs-guix *cough*), that can build systems from config "as you type"
<lilyp>Still, that's not a reconfigure workflow. What you'd usually do is edit the file, get a typo somewhere, edit it again, and so on until you are content
<cehteh>cli is the underlying infrastructure, i always want to have that in the first place, ofc would be nice to have gui/emacs for it but i dont want guix like the linux bluetooth stack which is(or at least was) almost impossible to configure by cli
<lilyp>spawing a new editor each and every time is bogus
<cehteh>in most cases i dont edit but i reconfigure on the current to deploy new kernel/package versions
<lilyp>yeah, but this common use-case can be simplified without going the route of editing in /tmp
<cehteh>just guix system reconfigure w/o any config can reconfigure on the 'current' config
<dissent>Why are there two prompts for to decrypt the hard drive on boot?
<dissent>And also, how does everyone manage to use the linux-libre kernel with more modern computers?
<jpoiret>dissent: first is GRUB asking, because the kernel and initramfs are located on the root filesystem (in the store), and then once more because the initramfs needs to decrypt and mount the root filesystem
<Olivetree>WARNING: IceCat 78 has not yet been released by the upstream IceCat project. This is a preview release, and does not currently meet the privacy-respecting standards of the IceCat project.
<Olivetree>How can I get a version which meets the privacy standards of IceCat? guix search only shows the current version, but surely some older version of guix has another version of IceCat
<jpoiret>mahmooz: i have no idea, maybe someone more knowledgeable can step in
<Olivetree>How do I find out which one is and install it?
<attila_lendvai>ouch: builder for `/gnu/store/fvrmlpdqirfy893jfjd6bdykwkgadncg-clutter-1.26.2.drv' failed due to signal 11 (Segmentation fault)
<excalamus>Olivetree, I've not done something like that before, but what comes to mind is to check for a version, something with an @ symbol. Otherwise, might that be a guix time-machine thing? That is, look in an older Guix for an older definition.
<jpoiret>there's no other packaged version unfortunately
<jpoiret>but yes, this is prime time-machine stuff
<jpoiret>although i find it weird that a *preview* version replaced the latest stable one
<excalamus>cool, thanks for confirming. (I've read a lot of the manual lately. Good to know it's sticking)
<Olivetree>It seemed like time-machine, but how do I search for previous version of that package?
<mahmooz>Since prebuilt substitutes are not currently available for Nonguix, you may find that guix system reconfigure recompiles the kernel frequently due to version bumps in the kernel package. An inferior can be used to pin the kernel version and avoid lengthy rebuilds.
<jpoiret>no, you shouldn't use it on a preexisting guix
<civodul>roptat: hey! the "devel" manual fails to build since the latest NLS update; specifically: "guix.es.texi:37008: @pxref hace referencia a un nodo inexistente (`Configurar el gestor de arranque.')"
<Olivetree>Merchandise from Guix directly would be the best in both worlds: you mass produce, sell expensive and the profits are the donations
<roptat>I'm not sure how this would work, legally speaking
<Olivetree>This way I get expensive merchandise but none of it goes to Guix. Then not much is left for donating
<lilyp>tbf it still goes to individual guix contributers
<lilyp>plus realistically speaking selling stuff is not a good way of getting donations anyway
<lilyp>unless you're buying newspaper for the Solipreis
<roptat>most of our money is held by the FSF, so maybe they could sell guix stuff on their shop; we also have guix europe, which is a French nonprofit, I know it's possible to sell stuff, but I'm not sure about the exact details of what you need to do it within the bounds of a nonprofit
<abrenon>about emojis, how do you usually type them ?
<abrenon>""I removed it because it wasn't working" is very likely just poor judgement" : if that's you're reaction I may have failed to convey my actual meaning and you must have misunderstood the situation I'm trying to describe
<abrenon>so thanks for the information about the particular variable, I think that's a huge help; but I think it'd also be useful for me to understand on which instance you're relying
<abrenon>re-reading the above, I think you haven't touched anything and are relying on the same default instance spawned by GDM
<abrenon>you didn't add it anywhere in your desktop / session startup configuration, right ?
<lilyp>All I did was ensure that those variables are set, which technically counts as session startup configuration
<abrenon>you're right, that's a way to configure startup !
<abrenon>I meant, you do not have a separate process spawned as your user in a file like, say, XFCE's autostart (I don't know anything about gnome, but I'd be surprised if there wasn't a similar mechanism to run process upon login)
<lilyp>But yeah, I use *gnome-desktop*'s ibus, and install my ibus packages system-wide along with gnome itself
<abrenon>thank you so much, that was very helpful ! I have hope again : )
<lilyp>IIRC you can kill gnome's ibus and spawn your own
<lilyp>but the gnome bridge still requires the im module
<wonko-tmp>I booted on a live system to check, I can luksOpen that partition with password I entered
<wonko-tmp>yeah, I typed the password in the grub prompt to be sure (as in in clear without a password prompt)
<jpoiret>we'd also need to move the pre-mount procedure in the initrd to before the resume hook, which I don't like very much as it's not really documented that that parameter should NOT mount file systems
<roptat>wonko-tmp, it might be that your grub is missing something important. if you had to insmod, it means your configuration is not correct from the start (or there's a bug somewhere in guix...)
<wonko-tmp>jpoiret: yeah, so that's the difference with my first setup, it was with luks1 headers
<qbt>I'm super tempted to switch to gnu guix from my current arch system, however i'm not really sure if it would be possible to get Zoom running smoothly on the system as it is unfortunately really the only non-free software i'm required to use for work at the moment.
<ison>Using guix-home how can I customize ~/.config/fontconfig/fonts.conf? It seems to be created by default. If I try to add a service for it there is a "duplicate entry" error message.
<qbt>heard flatpak works, but I'm not sure how good it'll work (never used it before)
<roptat>qbt, it worked for me in the browser, but I couldn't install the client (not that I'd want to anyway...)
<roptat>anyway, if you don't speak up, nothing will change, that's for sure
<qbt>roptat: yeah that's my worry, sort of difficult to propose it unless its as easy to get started as everyone is expecting these days... however, as the online-teaching seems to continue I have started gathering some articles, alternative software, etc so i can bring it up in a coherent and convincing way soon hopefully
<robin>lilyp, nice catch on the inputs-"inheriting"-propagated-inputs mistake with yt-dlp. thanks for the review, it's the first package i've upstreamed in a while :)
<robin>qbt, i just use the web client when i'm forced to use zoom. although that apparently has limited features compared to the official malwa^Wclients
<qbt>robin: ah yes, that's my issue! i need the 'advanced' features sadly :/
<robin>qbt, i'd expect the flatpak client to work well, or at least i can't think of any reasons it wouldn't
<qbt>in case I run into trouble, i'll follow up! hope to set everything up sometime this week :)
<podiki[m]>alternatives are good! (if in an official education context, do have to be aware of privacy laws for what you can use I think, but Zoom is not the only game in town)
<robin>qbt, fyi, you may know this already but #guix isn't a good place to discuss proprietary software, although general flatpak stuff is fine (as well as flathub, i'd expect, since they distribute plenty of free software too). i'll msg you a channel more suitable for anything zoom-specific
<dstolfa>zoom, while not being the only game in town, is sadly mandated for many things and it sucks :(
<qbt>No idea if that aspect has been brought up even.. we're using Zoom, Discord, Slack, you name it. I would love them to switch, but it's kind of hard now that it's been established, unless everything really does go back to irl teaching there might be some more wiggle-room
<jpoiret>simply seems like the early userspace is asking it to open a non-existing device (which is weird because it first finds it before passing it to cryptsetup)
<wonko-tmp>jpoiret: I have no idea what I'm doing (set!), what do you recommend?
<podiki[m]>tried to pull the batched-changes branch, failed with builder for `/gnu/store/yms5c5kl7mmhk0m7diqmsq41lhk7vyja-guix-package-cache.drv' failed to produce output path `/gnu/store/bjdidqfvyd4hsx1vfi7inbbkhlx7qczm-guix-package-cache'
<sneek>civodul, roptat says: the current guix package is not recent enough
<vagrantc>hmmm... using git describe gets me a "version" that seems to work out-of-the-box ... and unless i misunderstand something, it should usually increment the version ... e.g. it's basically version+patches since version+"g"commithash
<vagrantc>for a package that's already using git tags for versions...
<jpoiret>for patchsets, should I make changes to the doc in the same commit as the added feature or keep it in a separate commit?
<vagrantc>wonder if software heritage handles git describe style versions ...
<vivien>civodul, I know I’m late, but will the cached guix shell environment survive a garbage collection? If guix shell "does not talk to guix-daemon", how can it make sure that the environment won’t be garbage collected?
<jpoiret> with guix environment (just checked but i'll be sure to use it as well) you can just `guix environment -r gcroot ...` and it will create a file called gcroot in your env that is symlinked to the profile, and is registered as a gcroot
<jpoiret>so as long as that symlink is there, it won't be gced, and you just have to rm it to be able to gc it
<florhizome[m]>guix home does not accept the expressions generated by itself with “import” :/
<florhizome[m]>Trying to import my existing shells, the generated code is like ...(home-bash-configuration (bashrc (list (local-file “.bashrc”)))...) but I get invalid name “.bashrc” ..
<lilyp>jpoiret, vivien: `guix gc' still looks for active processes, so I doubt it'd collect a profile in active use
<vivien>Thank you, I didn’t know that, so I guess there’s no reason to worry.
<wonko-tmp>I had to chmod a+x /home & /gnu before being able to log as user
<wonko-tmp>is that expected or did I do something stupid?
<vivien>wonko-tmp, I have /home permissions set to root root, with drwxr-xr-x, same for /gnu
<jpoiret>basically, either 1) we try to diff the build cache (which is not really readable) and keep only what the `go install` added this time in the output and propagate it in other packages that require it (could not work at all, only hypothetical)
<jgart>We'll have to get creative and come up with new solutions and extend go-build-system then
<jpoiret>2) we write a complete build system using the manual `go tool compile` `go tool link` etc
<vivien>I get only one warning: (org.gnome.Nautilus:3075): GVFS-WARNING **: 21:37:04.174: The peer-to-peer connection failed: Timeout was reached. Falling back to the session bus. Your application is probably missing --filesystem=xdg-run/gvfsd privileges.
<nckx>Heh, I just rolled back to a previous system generation because of a similar thing (Creating session c1… destroying session c1, something like that, then nothing). Not saying it's related but it's an easy failure mode to enter.
<jonsger>nckx: the last good system i found is from c-u-f (I guess) on octobre 4th
<jonsger>reconfigure from master doesn't heal the problem
<nckx>drakonis: That won't set the same date without a reference/absolute timestamp, but maybe close enough is good enough.
<vivien>The epiphany freeze also has a The peer-to-peer connection failed… warning
<vivien>Just before that, I get: (WebKitWebProcess:2): dbind-WARNING **: 21:44:29.498: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-HvipfTkIhz: No such file or directory
<nckx>jonsger: And reconfiguring from the same ‘c-u-f (I guess)’ commit? If that fails it sounds like your system configuration changed.
<jab>sweet! it works! It'll now check your syntax!
<drakonis>honestly though, gotta have a rescue initrd at some point
<nckx>jab: It means that your current system was probably inited/reconfigured from a non-pulled guix, so e.g. ‘guix describe’ and Guix's downgrade detection don't have a full picture. Nothing to worry about unless you expected it to exist.
<nckx>drakonis: Guile REPL hell without tab-completion is KISS and true unix.
<nckx>Also infuriating: I know there's a new Tor releas, so I visit <https://www.torproject.org/releases/> — the releases page for Tor, one might say — and it mentions Tor exactly nowhere, much less its releases; only the Tor Browser Bundle.