<roptat>maybe the shepherd, since it crashes... you should add it to your report <roptat>could you restart the installer system and mount the installed system from another tty? that would let you access the files ***card.freenode.net sets mode: +o ChanServ
<roptat>but not on the installer system, right? <roptat>so can you boot the installer system and mount your system to access the log files? <mbakke>PotentialUser-46: what is the problem with dbus-system? <PotentialUser-46>"Failed to start message bus: Failed to bind socket "/var/run/dbus/system_bus_socket" <mbakke>PotentialUser-46: does /var/run/dbus exist in your chroot? <rndd>hi everyone! does anybody had this error "Unable to connect to graphical console: virt-viewer not installed. Please install the 'virt-viewer' package." with 'virt-viewer' installed on machine? <mbakke>oh, RIP PotentialUser-46 ... I wonder what went wrong with the dbus activation script <roptat>still parsing my Android.bp files... <guixy_>I'm using guix deploy to control what's on two remote systems. When I have (build-locally? #t) it works without error. When I have (build-locally? #f) it fails with ERROR: <guixy_> arguments: (system-error "open-file" "~A: ~S" ("No such file or directory" "/gnu/store/r5iyfxfnsvlj8g6hmjinv8220ia3bpi9-remote-exp.scm") (2)) <guixy_>https says "Your connection is not private" <rndd>hi everyone, i installed virt-viewer but there is only remote-viewer command <lfam>Thanks for the note ryanprior <rndd>guixy_: i'm looking for virt-viewer command <civodul>lle-bout: oh these are the discrepancies you and marusich reported earlier, right? <GNUtoo>hi, I'm a complete newbie to guile, and in my guix.scm I want to do something like that: #:make-flags (list "CFLAGS=-W -Wall -Wunused -Wunused-function") <GNUtoo>So my guix.scm builds fine and so on, and when there are test they pass too <GNUtoo>but when I do: (define %cflags (list "CFLAGS=-W -Wall -Wunused -Wunused-function")) and #:make-flags %cflags, then it fails to build due to some scheme error <GNUtoo>what concept should I look for in the guile manual to understand that error (and fix it) <guixy_>Is there an offload-service-type to configure what computers to offload builds to? <guixy_>I can always configure it by hand, but putting it in the system config would be nice. <guixy_>rndd, I get the same results. The manpage is there, but not the executable. <roptat>GNUtoo, you probably need to put ,%cflags with a comma <roptat>because the arguments are inside a quasiquote <pineapples>Anyone experiencing kernel oopses on 5.9.11 or 5.8.40 when powering their machine down? <guixy_>guix offload: error: failed to load machine file '/etc/guix/machines.scm': (unbound-variable #f "Unbound variable: ~S" (build-system) #f) ***jorge is now known as Guest83502
<lfam>pineapples: It shuts down okay for me with 5.9.11 on x86_64. Can you give any more details? <lfam>sneek: later tell pineapples: It shuts down okay for me with 5.9.11 on x86_64. Can you give any more details? <dissoc>im following the ganeti cluster blog post. i get an error: "guix system: error: service 'openvswitch-configuration' requires 'vswitchd', which is not provided by any service" <dissoc>what do i need to include for vswitchd? i cant find it anywhere <dissoc>i think i got it. i didnt realize i needed to add the openvswitch-service-type as well <jsoo>mbakke, cbaines: thanks for checking on exa. I think it may need some more work if the package gets upgraded. I saw some of their tests may work more reliably in recent patches <lispmacs>hi, did the latest guix pull break the gdm for anybody else? <lispmacs>or is it still working fine for everybody else? <lispmacs>maybe the question is confusing. Is there anybody who has reconfigured their system in the last day or two who is also using gnome? <lispmacs>if so, are you still able to reboot your system and login to gnome? <lispmacs>hmm, either I must be the last gnome user, or nobody else is brave enough to try a reconfigure <lispmacs>well, maybe this is a good excuse to figure out the emacs window manager <dannym>vagrantc: I'm currently trying to boot guix on the novena we got for Mes. <dannym>vagrantc: Did you manage to boot the novena using u-boot-novena you sent to the ML? <dannym>vagrantc: Because I tried guix system disk-image -s aarch64-linux novena.scm; and that eventually creates an ESP partition (which is useless in this case). U-Boot then complains about "FAT sector mismatch" for the ESP partition and *does not proceed to partition 2, which would have had guix, Linux kernel and all* <dannym>So I edit the sd card manually, removing the ESP partition the Guix system partition, and recreating the partition table entry for the guix system partition as partition 1 (as opposed to 2, as it was) <dannym>Then I get that /gnu/store/lwl*linux-libre*/lib/dtbs/imx6q-novena.dtb cannot be retrieved. <dannym>Do I need a custom novena kernel or what's the deal here? ***WarmasterJindrit is now known as Jin[m]
<lfam>lispmacs: You should get some answers about your problems with GDM eventually <dannym>My gdm also doesn't let me log in anymore <dannym>I'm now in irssi on Linux console <lispmacs>dannym: I was starting to wondering what was so special about my computer <lispmacs>kozo[m]: did you reboot into your new system? <kozo[m]>Can you not revert your generation with a roll-back? <lispmacs>well, certain, but that is not nearly as cool as hanging out in my virtual console emacs <lispmacs>these purple, red, and yellow theme colors look pretty awesome in a virtual console <lispmacs>now, I just have to patch emacs to display graphics in the framebuffer <lispmacs>or work on my other nefarious project, FORTHmacs <lispmacs>oops, that was supposed to be top secret <lfam>The staging branch was merged recently. My guess is it's related to that <lispmacs>well, I'm sure they do exhaustive testing on everything before a staging branch merge <lfam>I'm not sure how it was tested. I didn't participate in this update cycle <lispmacs>probably was tested by some rogue Guile AI <lfam>I'm building a GNOME VM now to test *raghavgururajan is working on pidgin <dannym>Ok, gdm problem fixed by removing gdm once and for all from my system configuration and replacing by slim <dannym>Also, SLIM was still complaining about not wanting to remove existing file ~/.xsession-errors, so I removed it for it <dannym>Now back in X with my usual ~/.xsession running, with no other workarounds <raghavgururajan>danny: You are talking about the wip-desktop or your personal config? <raghavgururajan>I guess we need to rebase master to wip-desktop, to resume the last bit of the wip-desktop work. <dannym>(Background: with todays "guix system reconfigure /etc/config.scm" I had been left unable to login via gdm, just like others. I fixed it by (1) replacing gdm by slim and (2) deleting ~/.xsession-errors) <kozo[m]>dannym: Do you mind sharing your code that will do that plesae? <efraim>dannym: we should probably change the gdm service (and other ones) to chown their directories in case they change UID/GID with a reconfigure <guix-vits>dannym: "we'll never roll-back, packages... desertires will get what gdm got!" <vagrantc>dannym: been a while since i tested the novena <vagrantc>dannym: but i think i used linux-libre and/or linux-libre-arm-generic <efraim>I've had better luck with linux-libre-arm-generic <vagrantc>pretty sure i got both working on the novena ... but that may be linux-libre 5.8 or so <vagrantc>so tested novena with linux-libre@5.8 a few months ago <vagrantc>but yeah, the -arm-generic kernel doesn't require tracking the right kernel modules ... <vagrantc>which ... change between major kernel versions now and then ... <Zambonifofex>rekado_: Would you mind if I wondered whether the build problems you had when you changed the `netdde` package's version seemed related to that change itself, or to some other change you might have applied at that time too? <Zambonifofex>Perhaps more interestingly, I wonder if I could do anything in order to be able to help figure out what the problem was. (Any guidance is appreciated, of course!) <janneke>Zambonifofex: probably the gnumach and hurd packages need to be updated ***soheil is now known as soheil_
***soheil_ is now known as soheil
<chrislck>guix *really* *really* needs a task-based Q&A FAQ <chrislck>because Q&A is currently limited to live irc sessions only <cbaines>What frequently asked questions do you think are lacking answers chrislck ? <chrislck>The type of questions I was asking yesterday :) <cbaines>interesting, what topics within Guix do you think would benefit from that interactive style? <chrislck>It needs to have more HOWTO and less hyperbole about scheme :) <cbaines>Can you point out some hyperbole? (I haven't read it, so I don't know) <cbaines>Feedback on the documentation is useful, but more specific criticism is more useful than general criticism <chrislck>(Not aiming to criticise guix nor guile) <chrislck>But learning guix when you're a seasoned schemer is a bit tedious <emys>hi I have a symlink .guix-profile/share/emacs/site-lisp/ivy-hydra.el -> /gnu/store/i0vbhylrx3c6cy8c1zi3v795kcgg5lab-emacs-ivy-0.13.1/share/emacs/site-lisp/ivy-hydra.el in my profile <emys>although I have deinstalled emacs-ivy <emys>i.e. no results for $ guix package -I | grep ivy <emys>could it be pulled in from another package? <emys>if yes, how can I find that? <cbaines>emys, maybe there's a better way, but this command might work: <cbaines>guix package -I | grep emacs | cut -f1 | xargs --verbose -I{} guix graph --path {} emacs-ivy <cbaines>You'll want to look for the guix graph commands that don't error, as that indicates that the package in question is potentially introducing emacs-ivy to your profile <cbaines>You'll need to check whether it's an input or propagated input though <emys>ok, emacs-org-ref pulls it it <nckx>Err, berlin's certbot wants to bind to port 80. Which ends as well as you'd expect. <chrislck>cbaines: a high-level overview diagram, illustrating: environment, package, profile; the various regular actions and associated guix actions, would be nice. <chrislck>if the various objects (environment, package, profile) are depicted as timelines, it'll be even better <dannym>kozo[m]: Replace %desktop-services by (remove (lambda (service) (eq? (service-kind service) gdm-service-type)) %desktop-services) <dannym>kozo[m]: Then add (service slim-service-type) to services <dannym>(in your operating system config.scm) <dannym>then rm ~/.xsession-errors (as regular user) <dannym>I think what actually fixed it is the last line <dannym>Btw, rolling back to a previous system generation (even two generations back) HAD NOT fixed the problem <cbaines>emys, cool :) Are you looking for some feedback on getting that in to Guix? <emys>sorry I was just composing a question and while putting together stack trace and so on I realized what the problem is (I think) <emys>so I'll go on with packaging <chrislck>cbaines: see an example gnucash task Q&A written by yours truly. It hides away all unnecessary beginner-gnucash tasks and writes Q&A specific for the particular task. Does it make sense to the non-gnucash initiate? <chrislck>(Disclaimer: I hack on Gnucash heavily as the resident schemer and do Australian BAS work) <emys>cbaines, I guess my problem is that ruby-rugged is bundling libgit2, I want to use the one from guix (feels better I guess), then it complains during build about the version not being compatible https://paste.gnome.org/pfce8cjxk <emys>and guix bundles libgit 1.0.x <emys>will see if I can bump this <cbaines>emys, I think it's actually looking for an older version, maybe try building with the older libgit2 in Guix <emys>now I guess it needs to be decided whether other packages are fine to be built with the newer libgit2 <cbaines>emys, maybe submit the libgit2 upgrade as it's own patch, I don't think there are many dependent packages <cbaines>chrislck, yeah, I can see that page being useful, and I do think Guix could use more guidance content for specific tasks <cbaines>although that's how I'd see it, as task specific guidance content. I don't think using a Q&A structure adds much if the questions are just ways of breaking up the guidance <chrislck>breaking up is useful -- the socratic method ;) <PotentialUser-55>Hi, how I can boot from Guixsd from grub to have a shell without login? Like the init to a shell to recover root password init=/bin/bash. <emys>cbaines, I will do (submitting libgit2 bump first) <emys>is it normal that the guix checkout is littered with changes in the po/ subdirectory after a build? <cbaines>Yeah, I normally discard them by doing git checkout po <emys>should I use the same ticket for my 2 ruby packags that I want to add to guix (and depend on libgit2)? <emys>or create separate issues? <cbaines>emys, separate issue, but it might be good to mention in the email creating it that it relates to the other issue about libgit2 <roptat>ok, I have a problem with my Android.bp files... they can reference files from other repositories for configuration defaults, which I didn't expect <roptat>this means I'll need to find a way to inject these defaults... either from the package definition, or by passing the required files as inputs to the package <bdju>thanks to whoever updated Sway! <bdju>I am using %base-services instead of %desktop-services and I start it from a TTY with `exec sway`, but on my last install I ran a modified %desktop-services where I'd replaced gdm with sddm, and that worked as well <mizukota[m]>hmm... I tried just "sway" from TTY and it didn't work <bdju>there's possibly some piece you're missing, but I'm not quite sure what it would be. I do run a dbus-service it looks like <nckx>mizukota[m]: I use SDDM as well: (service sddm-service-type (sddm-configuration (display-server "wayland") (auto-login-session "sway.desktop") ...)) <mizukota[m]>and also probably it gives an error when you don't have copied default config to user directory <nckx>I think it offers to do so for you. <mizukota[m]>the error wasnt very informative... I glad it's possible though <mizukota[m]>when i'll have ton of free time and sanity i'll try to create guix config without Xorg and without display server that will only use sway without xwayland and only wayland-compatible things <mizukota[m]>by the way when you do `guix system disk-image` with "raw" type of image, does it resize itself on first boot? <mbakke>I auto-start sway on TTY2, and have "exec swaylock" in the sway config such that it locks the screen when it starts <bdju>that's an interesting idea <mbakke>the idea is that if sway crashes while the screen is locked for whatever reason, it gets restarted and locks the screen again <mbakke>mizukota: you may need elogind-service as well <mbakke>(replace "my-username" with your username, obv) <mbakke>haven't figured out how to manage that through the configuration system yet.. ***rekado_ is now known as rekado
<guix-vits>mbakke: heh, ye. my XDG_SESSION_TYPE is "tty". IDK why sway not sets this at least(?) <guix-vits>tho idk about dbus, and if it's there, what pulls it in. just using a elogind. <nckx>Sway does not set XDG_SESSION_TYPE because Sway was written by Drew DeVault. <nckx>And It's The Log-in Manager's Job Damn It. <cbaines>I've just pushed a merge from master in to core-updates... hopefully I haven't broken anything! <sneek>Welcome back pineapples, you have 1 message! <sneek>pineapples, lfam says: It shuts down okay for me with 5.9.11 on x86_64. Can you give any more details? <lfam>Gotcha. I'm not using EFI, so I don't see it <lfam>Well, there should be new kernels soon enough, or maybe some EFI user can send a patch :) <terramorpha>Hi everyone, what is the state of cross compiling to windows on guix ? <pineapples>If it were up to me, I'd revert back to 5.9.10/5.8.39 for now <lfam>Can you send a bug report pineapples? <lfam>I'm curious if anybody else is having trouble <andi->Hey, just in the process of figuring out if I want to switch from NixOS to Guix (after several years…). In the new(?) graphical installer I selected English as language but now I can't select Germany as Region anymore. I believe that is a bug. <luis-felipe>pineapples, lfam : I'm using the kernel version 5.9.10 and EFI, but haven't experienced any issue. I don't understand the bug report (not my level). As a desktop user, when would I hit this? <lfam>luis-felipe: The bug affects 5.9.11, not 5.9.10 <lfam>IIUC correctly, the system will crash when shutting down or rebooting <pineapples>luis-felipe: Your machine will produce an oops during either the shutdown procedure, causing it to get locked up <lfam>Do you know if there is a fix commit in the pipeline, pineapples? Is anyone talking about it anywhere? <pineapples>Ifam: apart from that bug report, no, nobody's talking about it anywhere else. Rebooting or shutting down systemd-based distributions does not trigger the bug from my experience; only explicitly unmounting the efivars file system does <lfam>It's difficult to decide what to do... very little info to go on. <lfam>Even that kernel bug report seems to deliberately obscure things, by saying "An analogous patch was introduced to v5.4.80" but never actually saying which patch is to blame <lfam>I wonder if the stable maintainers even know about it <mbakke>terramorpha: is cross-compiling to windows failing for you? <pineapples>Regardless of the visibility of this bug, as it stands now, anyone who upgrades to the latest kernel will be unable to perform a clean reboot or shutdown on Guix System booted into the UEFI mode <lfam>Yes... anyone except for me apparently <lfam>I guess it would be good if I had a computer that used EFI to test these things <mbakke>lfam: you can use qemu -bios $(guix build ovm)/share/firmware/x86-64.efi (unsure about the file name) <lfam>I suppose that not all Guix users update their kernels immediately after I push... ;) <lfam>I would have expected more reports <lfam>I think that, since that bug report is so nonspecific, we won't see this fixed upstream for at least another release <lfam>I'm not confident about cherry-picking patches here. The stable kernels are already rube goldberg frankenstein creations and they are created by an expert <mbakke>heheh :-) by the way, it should be "ovmf" in the above command <lfam>I will figure out how to reproduce the bug in QEMU and then see about reverting the updates <lfam>In the meantime, `guix time-machine` should help <mbakke>since the backtrace in the bug report is from efivarfs, I'm almost certain that fe5186cf12e30facfe261e9be6c7904a170bd822 is the culprit <mbakke>which seems innocuous and standalone, i.e. independent of other patches <lfam>Yes, it seems likely that's the one <mbakke>anyway, would be good to see discussions from actual kernel developers about it <lfam>Yes. "Someone" should email Greg Kroah-Hartman <lfam>I'm sure he'd want to know <cbaines>Cuirass on ci.guix.gnu.org seems upset, both guix-master and guix-modular-master are failing <nckx>andi-: It's not a bug. The ‘region’ specifies the language, like ‘en_US’ vs. ‘en_GB’. There is no ‘en_DE’. It's not where you are (nothing to do with your timezone &c.), it's what you speak. It could be clarified though. <lfam>Is it related to the new dependency on guile-avahi, cbaines? <nckx>I think we just copied the wording from Debian or something. <lfam>Can anyone share a config.scm that would be suitable for virtualization with EFI? <andi->nckx: thanks for clarifying. I ran into another issue with a lengthy exception(?) after partitioning selection. Not sure now to work around that now. <lfam>Could I copy lightweight-desktop.texi? <nckx>...why does every commit to .*efi.* break someone's laptop... <lfam>Why do I still use BIOS on my new laptop? :) <nckx>andi-: Any way to share it? (Screenshot's fine.) <cbaines>lfam, wait, guix-modular-master is fine, but the Avahi related change is when guix-master broke <nckx>andi-: Or if you can export the text there's paste.debian.net. <nckx>Thanks, will look at it after moving rooms :) <andi->That one now is with the latest `image` I could find in hydra. It looked the same in the current release on the website. <nckx>Not that 1.2 should have any ‘known bugs’ yet... <jorge[m]>Instale guix hace poco y esto aparece que puedo hacer ? <nckx>andi-: Hrm, I won't be able to help you with that. If no-one else chimes in be sure to include the second half in a report to bug-guix at gnu dot org. <lfam>For the next release, we should have a BBB / IRC "test the installer" party <nckx>jorge[m]: Try running ‘fc-cache -rv’. If that doesn't help, try ‘guix install font-gnu-freefont’ and run it again. If that still doesn't help, paste its output to the Debian pastebin. <andi->44872 looks like my issue. I'll try to reproduce the workaround even thought the disk I am using was never used (it is a new vm image). <nckx>lfam: We need a huge repository of ‘weird 8-year-old partition tables people end up with in the wild’ against which to run tests 😉 <nckx>It generally works fine with pristine drives. <lfam>Yes... and between all of us, we have that collection! <luis-felipe>jorge[m]: Buenas, ¿Instalaste Guix en una distribución foránea o instalaste el sistema operativo GNU de Guix? ¿Y qué versión instalaste? <nckx>Sure but the Guix installer ain't touching mine. <andi->Ohhh I think I might have found the "bug". It is likely a user error. I selected /dev/sr0 (the string started with QEMU something something) and obvisouly I can't install onto the CD /o\ <pineapples>mbakke: I'm left wondering why does systemd not catch a segmentation fault during the shutdown procedure when booted into one of those kernels. Perhaps it doesn't umount the efivars filesystem to begin with? <nckx>andi-: I hope that was it! Still, we might filter out read-only devices to prevent ‘user error’ like that. <mbakke>pineapples: you mean the crash only occurs on non-systemd systems? <andi->nckx: it is installing now :-) <pineapples>mbakke: it only occurs on them if the user explicitly umounts the efivars filesystem from the CLI <andi->sometimes all you need is a rubber duck.. *nckx is no fun, I know lfam. <pineapples>err, I mean: it occurs on systemd systems when the user does that <mbakke>pineapples: did you find that out by testing manually? <nckx>andi-: By the way, the /download/latest x86_64 image I linked to redirects to .../1790, so don't bother trying it if you run into other bugz. <pineapples>mbakke: Well. I came across the bug by just powering down my Guix System machine. Then I tried to reproduce it in a vm, on which I'm running a systemd system, and it wouldn't happen there unless I explicitly unmounted the filesystem by myself. <andi->I actually started diving into cuirass already as the download link on …/1790 doesn't set the right content disposition header but from the code it should... <lfam>pineapples: So, the bug doesn't manifest in a VM in "normal" use? <lfam>Or, systemd handles it differently? <nckx>andi-: Guix's IceCat pops up a download dialogue as expected but ‘Content-Disposition: form-data; ...’ looks off indeed. <jorge[m]><luis-felipe "jorge: Buenas, ¿Instalaste Guix "> El sistema operativo GNU Guix la ultima version 1.2 <andi->There everything is listed correct <nckx>andi-: I get the same C-D header both on the ‘friendly’ /download/latest page and your ci.guix one, though. What did you get? <luis-felipe>jorge[m]: Try running ‘fc-cache -rv’. If that doesn't help, try ‘guix install font-gnu-freefont’ and run it again. If that still doesn't help, paste its │ apetresc <luis-felipe>jorge[m]: Intentá ejecutar: fc-cache -rv en un terminal. <nckx>I just don' t speak Spanish so can't follow your conversation in detail. <pineapples>Ifam: My bet is that systemd handles it differently from the Shepherd so the bug doesn't manifest itself there when shutting a system down <andi->nckx: when I curl it now I get Content-Disposition: form-data;filename=f5xk19n18h675da1symyin5rasqk4f2x-image.iso, firefox 83 just called the name 1790 <andi->err wasn't firefox that I used. I used wget.. <pineapples>However, unmounting the file system on either Guix System or a systemd system reproduces this bug every time <nckx>WORKSONSYSTEMD, INVALID, ONETRUEINIT, closing. <luis-felipe>jorge[m]: Si eso no resuelve el problema, intentá: guix install font-gnu-freefont y luego fc-cache -rv otra vez. <jorge[m]><luis-felipe "jorge: Try running ‘fc-cache -rv"> le di y nada <pineapples>Perhaps unmounting the efivars filesystem on shutdown is a mistake, no? <lfam>It *is* a point for systemd <lfam>I'm building a VM to test it now <andi->Reading the manual as it installs. Grafting sounds nice. After having dealt with large security fixed originated rebuilds on NixOS. The docs just mention that you add a fixup to the package. How/When will those fixed be added to the actual package and a "proper" rebuild executed? Is there a way I can still force a complete rebuild even when one could "graft" it? <nckx>andi-: Short version: the grafting commit, the one that simply adds a foo/fixed package and a ‘replacement’ field to the original foo, is pushed to master. Then master is merged into core-updates, followed by a ‘proper’ update that reverts the grafting and simply updates the foo package normally. c-u is a branch that is only occasionally merged back into master, after all its substitutes have been built on the CI. <nckx>You can substitute ‘staging’ for ‘c-u’ for packages that have between 300-1200 dependents instead of $the_world, but the principle is the same. *nckx AFK like all the cool kids. <kisaja[m]>didn't succeed building lives video editor today, as probably couldn't figure out how are dependency packages called in guix <Formbi>how to disable the formatting of guix output? <Formbi>it looks like a pile of crap in eshell <luis-felipe>jorge[m]: ¿Cómo te fue con la ejecución de "guix install font-gnu-freefont" y luego "fc-cache -rv" otra vez? <aitzkora>hi, someone knows the package where ldd is hidden ? <andi->glibc likely (but I am new to guix) <nckx>aitzkora: glibc, but the gcc-toolchain getting-started package seems to include it as well. <jorge[m]><luis-felipe "jorge: ¿Cómo te fue con la ejecu"> Se realizo a la mitad y se detuvo <luis-felipe>¿La instalación se detuvo o la actualización con fc-cache? <nckx>andi-: You can force an real rebuild by cherry-picking the core-updates/staging commit to a local master branch, then building off that, but there's no cheat flag on the CLI (nor would this make much sense, IMO). <andi->Yeah. I totally get it. I just wondered if there would be a programmatic way that a package would update its own definition from the grafts. <nckx>I think so. You can write code to transform the graph to make ‘replacement’ fields completely transparent, i.e. substitute the value of the replacement immediately. The resulting system/package graph will be a rebuilt world. <nckx>That's starting to go out pretty far into the woods though. Especially if you want the regular CLI (‘guix install ...’ etc.) tools to see this world too. <andi->I've got used to terrible CLI throughout the years on Nix. One of the biggest plus points I see in switching to Guix is that developing the package set is much closer to the actual build tooling. <andi->When I sat in this years fosdem guix talk I was about to just wipe my production system and switch. <luis-felipe>jorge[m]: A mí me pasaba que algunas aplicaciones no mostraban el texto normalmente, así que instalé el paquete font-google-noto, actualicé la caché de tipografías (fc-cache -rv) y después de eso no he tenido problemas. <nckx>andi-: Not sure I'd recommend that, OTOH it's exactly what I did :) <luis-felipe>jorge[m]: font-google-noto es un paquete pesado, casi 1 GB, si no me equivoco. <luis-felipe>jorge[m]: Si después de eso no se arregla el problema, yo también intentaría cerrar la sesión de escritorio y volver a abrirla. <nckx>luis-felipe: 1.5 GiB even. <aitzkora>I try to link dynamically against to libstdc++.so.6 : Where I could find it : in gcc-toolchain ? <aitzkora>find $GUIX_ENVIRONMENT/ -name "*stdc++*" <aitzkora>gives nothing when I am in an environment with gcc-toolchain loaded <jorge[m]><luis-felipe "jorge: A mí me pasaba que alguna"> ok,estoy en eso ahora son 771.1mb <andi->(use modules (gnu services xorg)) seems equivalent to (use-service-modules xorg), the docs use the former in a few places while the intro seems to be using the later. Is that correct? My guile isn't yet any good but the code in gnu.scm seems to suggest that. <nckx>andi-: Yes, the latter is purely Guix-specific (and package/service-specific) syntactic sugar for the former. <andi->Ok, back to trial and error getting sway to run through sddm :D <cbaines>ngz, hey! well, that just means that some part of trying to apply the patch with Git didn't seem to go right, it does sometimes error but seem to work though <cbaines>ngz, in this case, it looks like the generated branch matches the attached patch, so it seems fine <cbaines>if you click through, you should be able to find out that the package has successfully built (on x86_64-linux at least), which is good to know <ngz>cbaines: OK, thank you! <ngz>It is good to know indeed. <lfam>Does anyone have a working Guix VM config.scm that use EFI? <lfam>I tried using the lightweight-desktop template, but when I boot it using `qemu -bios $(guix build ovmf)/share/firmwareovmf_x64.bin ...` it does not finish booting <lfam>On the other hand, when I boot it with the QEMU defaults (some BIOS?), it boots fine but there is no /boot/efi and it doesn't appear to be using EFI <lfam>Or rather, in the latter case, /boot/efi exists but is empty <nckx>The latter is just plain BIOS (Sea-, IIRC) mode. Did you add an EFI GRUB bootloader to your system .scm when booting with the OVMF firmware? <nckx>(I assume not, since it boots fine on BIOS.) ***card.freenode.net sets mode: +o ChanServ
<lfam>The bootloader section of the lightweight-desktop template uses the 'grub-efi-bootloader'. Is that correct? <nckx>lfam: Hm, but doesn't the ‘system vm’ family do some (very crude) magic to the o-s record to replace the bootloader? <nckx>Can't really dive in now, sorry. <lfam>Not sure. I'm using `guix system vm-image` <nckx>I *think* it just replaces the bootloader wholesale, you could put inkscape there and it wouldn't matter. <lfam>Now there's an idea. I've that you can do anything with SVG *nckx chose a bad example since we do actually use inkscape in that area to generate the GRUB background. <lfam>I guess I'll pause work on this bug until I have a way to reproduce it <lfam>Hopefully it gets fixed upstream soon <nckx>Is it too risky to test this on bare metal & roll back? <nckx>This one o' them fancy brickin' bugs? <lfam>It's a kernel oops when halting or rebooting on EFI, in the latest LTS kernels <lfam>But, none of my computers use EFI <nckx>I do... but I don't use any of the mainstream kernels. <lfam>If you are based on the upstream longterm kernels, you should experience it with 5.9.11 or 5.4.80 <nckx>I'm can't move at all due to bcachefs upstream. <lfam>I'm somewhat pessimistic that it will be fixed in the next release since the bug report is lacking detail <nckx>I'm on 5.9.0-pf5 + crazy patches. <lfam>"A patch introduced between" and "An analogous patch was introduced to v5.4.80"... the reporter knows which patch but does not tell us <nckx>Have you asked them? Do you have a suspicion? If you can give me 2 disk images, one ‘broken’ and one with your suspected culprit reverted, I could boot them both... <nckx>(.scm images, not .iso, of course.) <lfam>pineapples is the person who experienced the bug. They might be able to offer more details or a reproducer <lfam>What kind of workflow would be required to share the "potential fix" kernel? <lfam>A branch on Savannah that you'd check out? <nckx>Something like that. But I assume pineapples has an EFI machine so my ‘booting stuff’ service is (ever more) worthless. <nckx>I've been using a custom kernel for 4+ years so I'm not exactly up-to-date on linux-libre customisations myself. ☺ <lfam>The state of the art has not advanced <lfam>(package (inherit linux-libre) (name "foo") (version "whatever") (source ...)) <apteryx>lfam: about vm-image: I think Ludo recently committed a fix to replace the bootleader with grub-bootloader. <lfam>It's good that it hasn't changed! It's super easy to customize <apteryx>so as nckx pointed out it shouldn't matter <apteryx>you shouldn't use the -bios flag to boot it <nckx>apteryx: But EFI is required. <apteryx>qemu defaults to use seabios which expects an old-fashioned BIOS <lfam>So, does this mean that the Guix VM tooling does not support EFI at all? <apteryx>I mean, which uses an old fashion bios out of the box (SeaBIOS) <apteryx>The code behind vm-image is soon to be retired, using the new image API (which disk-image already uses). <apteryx>when it does it'll work with EFI the same way disk-image currently does. <apteryx>in the mean time if you want an EFI image you could use 'guix system disk-image -t qcow2' to get a result similar to what 'guix system vm-image' does <pineapples>I would love to help, but I'm crazy busy right now so... <nckx>That is a pretty shit bug report even by Linux bugzilla standards. <lfam>I'm not familiar with what's "normal" there but I would be very frustrated if I received it <pineapples>Well. The one I submitted to your bug tracker isn't any better, but I'm expecting the bug report on the kernel bugzilla to do all the heavy lifting for me <pineapples>In any case, I'm willing to cooperate as soon as I'm free <lfam>I hope that if you know exactly which patch is to blame, as the bugzilla reporter seems to, that you'll tell us :) <nckx>IME there are the kernel hacker reports, the ‘newbie’/user bug reports (nothing wrong with that), and the ‘I'm insecure and want to sound smart so throw out vague details’ ones like this one, trying to sound like the first but not actually understand how they operate & respect free time. <nckx></rant>, nvm. (I've been spending too much time on Linux bugzilla lately.) <lfam>In any case, when getting frustrated by bug reports, it's a clear sign that it's time for dinner <nckx>Thanksgiving leftovers week 1. <lfam>Never liked turkey anyways <nckx>So did we, but we still have leftovers. <lfam>Lol, funny how that works <pineapples>Ifam: No idea which one is two blame. The two EFI-related patches that found their way into 5.9.11 are absent from 5.4.40, so I'm out of ideas as to what might have caused that regression <nckx>I'm also not seeing anything suspicious, pineapples. <bdju>is there a way to apply my manifest but skip everything lacking a substitute? that would be so nice <nckx>'Fraid not. You can get creative with ‘guix weather <package>’ but nothing built-in. <mbakke>apteryx: just a friendly reminder to also test python 2 variants when updating Python packages :-) <mbakke>anyone else having problems with gpg-agent after updating to the latest version of GnuPG? <lfam>What kind of problems mbakke? <mbakke>lfam: it seems to not find pinentry after the secret key has timed out, i.e. the initial pinentry prompt works, but when the key times out, programs accessing it (SSH, 'pass') just "hangs" <mbakke>instead of opening a new pinentry prompts <lfam>Hm... You might need to restart the whole gnupg "ecosystem" <mbakke>so latest version of dirmngr and gpg-agent <mbakke>I need to 'gpg-connect-agent -s killagent' to make things work again *lfam recovers from `make clean-go` <lfam>I wonder if pinentry needs to be updated. I don't see a newer version of the gcrypt FTP site <mbakke>lfam: I doubt it, but will try that UPDATESTARTUPTTY trick next time <mbakke>strange that the reporter does not mention which version of GnuPG they are using <lfam>Well, it's Debian, so version numbers are not that important <lfam>Not to mention they are using Debian testing, so all bets are off <mbakke>aha, I'm fairly certain this problem occured after 2.2.23 (or the related libksba updates) <mbakke>updating my manifest to use 2.2.24 now, but with the latest libksba, let's see.. <lfam>So, after the secret key "unlock" has timed out, subsequent attempts to unlock it fail because pinentry can't be found? <mbakke>lfam: something like that, yes ... unfortunately I lost the strace I had of it <lfam>I updated my gnupg and pinentry-gtk2 based on Guix a79041f0b583ef33 (HEAD) and I can't reproduce it :/ <lfam>I set a 10 second timeout <lfam>And I made sure to restart the agent <mbakke>lfam: OK, that's good, will try to reproduce more aggressively instead of just finding out when I need it to work :P <mbakke>lfam: I can't reproduce either with a 10s timeout <mbakke>well, I'll see, I have some automated jobs accessing the key, it might be that they are unable to find pinentry or lacks $DISPLAY or something, and ends up "locking" the agent <mbakke>huh, funny, gpg-agent is using 100% cpu now <lfam>In a cron job that uses gpg for secrets management, the command has to start like this: ". ~/.gnupg/gpg-agent.env && export GPG_AGENT_INFO && ..." <mbakke>lfam: well that's news to me, I don't have a gpg-agent.env executable, nor do I set GPG_AGENT_INFO anywhere <mbakke>oh I missed the dot in the beginning <mbakke>still don't have that gpg-agent.env file <mbakke>and this is a setup that has been unchanged for years :P <lfam>I think it's populated by the agent when it starts <mbakke>well, apart from a recent switch to Sway, which may be related <lfam>Oh man, I don't know... it works for me but I can't say I understand it <lfam>I'm often considering the cost/benefit of switching to something simpler <lfam>But since it keeps working, I leave it alone <lfam>And since I need it working for Guix <mbakke>I'd like to try out that shiny new Rust implementation, but am afraid of moving such an important piece of my setup to a moving target <mbakke>seems like Hartmut intends to maintain it though, which is nice :) <mbakke>OK, problem 1 is that my automated jobs are not spawning a graphical Pinentry prompt <mbakke>"ERR 83886383 Required environment variable not set <Pinentry>" <mbakke>however, accessing the secret key from a shell does start the prompt, instead of hanging, like the previous symptom <lfam>Hm, that doesn't happen for me either. If the key is not unlocked for an automated job, the job fails <mbakke>perhaps gpg-agent "locks down" after N amount of failed attempts? hmm.. <lfam>I haven't heard of that, but it could be <mbakke>it should probably just print an error in that case, instead of hanging indefinitely :P <mbakke>OK, so I can't reproduce the hanging gpg-agent, but I'll try to update my scripts so that they ask for my password instead of failing <mbakke>adding 'export DISPLAY=:0; export QT_QPA_PLATFORM=wayland;' before running the programs did the trick <mbakke>(I'm using pinentry-qt because pinentry-gtk had problems on Wayland) <mbakke>Gooberpatrol66: the user is set in the service definition, some run as root, some not 