<charles`>Does anyone why my system guix isn't being updated after running `make install` after building guix? <raghavgururajan>charles`: For upgrading/updating system, you do `guix system reconfigure path-to-config.scm` as root. At the end of the process, guix will automatically switch to new system profile. <raghavgururajan>You *might* need to restart the system or do `herd restart service-name` as root. <charles`>how does it know where to find the new guix? <cbaines>charles`, are you using Guix as a system, or Guix on a foreign distro? <cbaines>In either case, you probably don't want to do make install <charles`>on guix system. I just built a new guix and want to integrate it into my current system <cbaines>so you want to use the exact code you have in your local Git repository? <nckx>pkill9: <hmm looks like original should be working> = ? <charles`>I know about ./pre-inst-env, but I want it to integrate into the system <cbaines>charles`, right, so Guix has multiple different parts, there's the guix-daemon, the package definitions and the system and service stuff <charles`>All I really care about right now is the service (and package?) definitions <cbaines>charles`, doing ./pre-inst-env guix system reconfigure ... will use the system and service stuff from your local Git repository, but note that the guix-daemon will still be from the guix package (rather than using your local repo) <cbaines>charles`, the package definitions are a bit different, you could run guix commands using ./pre-inst-env and I guess the other approach would be to somehow guix pull from your local Git repository <cbaines>for reference, you can use (current-guix) within the guix-configuration to get the guix-daemon to reflect your local Git repository as well (although it sounds like that might be unnecessary for you) <charles`>and like raghavgururajan said, I have to run that reconfigure as root? I get "no code for module (gcrypt hash)" <nckx>How can ‘echo test | bash -c source <file> ; cat’ pipe ‘test’ to cat? They are two unrelated commands (‘;’). <nckx>You need one command connected to two subcommands through some kind of tee, either using ‘pee’ or by constructing one manually (‘tee’ with named pipes, or swapping around file descriptors, which is what ‘pee’ does behind the scenes). <vagrantc>charles`: i frequently use "guix pull --url=/path/to/guix.git --commit=a1b2c3d4e... or --branch= if you have the branch specified <pkill9>how do i find out which device is USB 1-1.4 <pkill9>if it is ethernet, then it means either there is a bug in the kernel, or my hardware is the cause of random disconnects <apteryx>weird, I'm hiting a problem building the daemon in my tree <apteryx>even after make distclean and ./bootstrap and ./configure --localstatedir=/var anew <apteryx>wait; interpreter /gnu/store/7w04gv6m92n40dainn4s6xr3l20r90xw-qemu-5.1.0/bin/qemu-arm; I don't see why QEMU should be involved at all in building the sources of Guix <apteryx>it seems that the QEMU emulator gets picked up to execute some binary through the misc_fmt flags registered <apteryx>but I'm not working in a --system=armhf-linux environment... <apteryx>acrow: I stumbled upon the same ugly golang-protobuf bootstrap <apteryx>it wants to bootstrap itself from former versions intertwined with the github variant <apteryx>I've now improved the go importer in the hope of being better equipped dealing with this (through a --pin-versions option), but I'm stuck on the above weird problem building my tree *apteryx does guix pull && guix system reconfigure <apteryx>marusich: one thing I've realized is a can of worms is having propagation of both gdk-pixbuf and gdk-pixbuf+svg; I've settled the matter on staging to always use the later, otherwise you'd have situations where icons are not drawn because the application happened to link against the wrong gdk-pixbuf variant <apteryx>I guess if we're very carefull to propagate gdk-pixbuf rather than gdk-pixbuf+svg for a given system that could work, but it's easy to mess something up <apteryx>so I agree with your conclusion that the definition solution will be to fix rust for other platforms <apteryx>mmh, the problem of being unable to build the daemon because of QEMU's interference persist after a reboot; is anyone else reproducing it? Perhaps something to do with the recent changes to binfmt-qemu? It was just touching flags, not the way binaries are registered but... <apteryx>well this error output doesn't make sense <apteryx>it still mentions qemu-5.1.0 but the binfmt-qemu regitsered entries with qemu-5.2.0 <apteryx>OK... I used a 'guix environment -C guix --ad-hoc git' environment, git clean -xfdd, then ./bootstrap, ./configure --localstatedir=/var and make guix-daemon progressed (but is lacking sqlite stuff apparently) <apteryx>nix/libstore/local-store.cc:259:10: fatal error: schema.sql.hh: No such file or directory <apteryx>left the env, ran with 'guix environment guix --pure --ad-hoc git' this time, cleared the repo again with git clean -xfdd, then the usual bootstrap configure... and make seems to build happily again. Phew. What was that. <raghavgururajan>sneek, later tell lle-bout: As you were working on CVEs, did you by any chance, find any CVE on any packages in linphone.scm? As they become too obsolete, I have updated them in #47274. Not sure if they still have any. ***apteryx is now known as Guest6344
***apteryx_ is now known as apteryx
***PIE_ is now known as pie_
*raghavgururajan hasn't slept <rekado_>“guix copy /gnu/store/… --to=aws” doesn’t work for me, but “ssh aws” works fine. I get this error: In procedure userauth-gssapi!: Wrong type argument in position 1 (expecting connected session): #<session ec2-user@ec2-....eu-central-1.compute.amazonaws.com:22 (disconnected) 7fa3c2352fe0> <rekado_>I wonder if it respects all of ~/.ssh/config <rekado_>the problem seems to be that “IdentityAgent none” is not respected, so it attempts to authenticate will all of my SSH keys before trying the one that is specified with IdentityFile <rekado_>the fix for me is to unset SSH_AUTH_SOCK, but it would be nice if this wasn’t necessary <fnstudio>i think i've launched a guix package --upgrade (still running) from within a guix environment "session", is that crossing-the-streams kind of bad? *pkill9 is removing magic from his system config <nckx>pkill9: Noo, don't let the magic out. <nckx>fnstudio: It's no kinds of bad. A guix environment simply changes which packages are available to use (visible, more or less). It doesn't make your user profile invisible (try ‘guix environment --pure --ad-hoc guix -- guix package -I’). <nckx>At worst, I think, you might use an older version of Guix itself as in the above example, but it's pretty contrived. <pkill9>nckx: now you are cursed with convoluted and unmanageable state <nckx>So it's 2007 and I'm using Gentoo again but also no COVID or Facebook. <pkill9>I like the inverted monkey's paw <sneek>lle-bout, you have 1 message! <sneek>lle-bout, raghavgururajan says: As you were working on CVEs, did you by any chance, find any CVE on any packages in linphone.scm? As they become too obsolete, I have updated them in #47274. Not sure if they still have any. <lle-bout>raghavgururajan: not sure, didnt have time to investigate there so much, been following feeds so only *new* CVEs then results of '$ guix lint -c cve' but did not process through everything yet, things are either fixed or reported in debbugs with 'security' tag <lle-bout>raghavgururajan: I am looking at your patches again, are you free now? I am! <fnstudio>nckx: oh awesome, thanks, glad i don't have to kill it and restart the download of texlive :) <fnstudio>which makes me think that i should investigate the possibility of keeping a "self-updating" guix mirror in my local network to speed up the upgrade process <nckx>Huzzah! Me too, but only because I finally got a haircut, not for a good reason. What's yours? <lle-bout>nckx: ahah why is that not a good reason :-) - I don't know just did all the dishes in a squat I am in now and slept well <lle-bout>I don't always know why I am happy I think it's mostly due to eating well / sleeping well, not witnessing social violence or other disappoiting situations for a while <lle-bout>I am trying to use Sway and disable XWayland, I found out QT apps in GNU Guix don't work on Wayland <nckx>fnstudio: If you have the CPU power you could set up a local substitute server to actually build everything while you sleep, quite a few people do that. But a ‘low CPU’ substitute server that basically only publishes ‘guix build world|manifest --source’ is interesting... <lle-bout>I use emacs from flatwhatson's channel so that supports pure GTK3+ backend (so Wayland) <lle-bout>I have silly font / icon problems, it's annoying <nckx>lle-bout: You're totally right, you don't need good reasons to be happy. <nckx>And all of those are good reasons :) <lle-bout>nckx: all new CVEs for the week-end are more or less cleared <nckx>Is a flatwhatson related to flatpacks? <lle-bout>I'll send a v2 that doesnt use package/inherit <lle-bout>nckx: it's a guix channel it has yet to be released native-comp and pgtk emacs :-) <fnstudio>nckx: cool, yes the low cpu option would be the most convenient in my current set up, but i'll explore both <nckx>I've just added and am pulling it. <lle-bout>nckx: would be nice if we actually had a metapackage called "world" that referenced all packages that exist in GNU Guix <nckx>fnstudio: Just to be clear, it's not an existing option per se, but you should be able to write a Cuirass job that only builds sources with a bit of thinking. <fnstudio>nckx: oh ok, and i'd like that to be set up in a way so that i don't have to fully trust my local machine (eg sitting in a dmz zone) <fnstudio>(just thinking out loud, not expecting a solution :)) <nckx>[Assuming ‘your local machine’ is the ‘server’] Well, your client should still validate the content hashes for all substituted origins, even if a rogue server provided a valid signature. And these sha256 hashes are currently very strong AFAWK. <roptat>I think I have a plan: build glib/fixed without tests, make the store read-write, copy the result to the store path of the one with tests, add it to the database, create a signed nar for it, gc it, and send it to my armhf server <roptat>if only the "linking target ..." step did not get stuck... <roptat>this is weird: glib/test builds and does not get stuck, but my package that basically inherits from it and removes the check phase gets stuck at the build phase during linking <fnstudio>yeah sorry, i meant "local machine" as in "the local mirror" but that wasn't well phrased at all; cool, yes, as i thought the hash ckecks would cover my case already *lle-bout logs out to log back in again <roptat>I don't get it, I modify a phase that's run after the build phase, and the behavior of the build phase is changed <lle-bout>dex is a really good autostart program for sway, especially for gnome-keyring stuffs <nckx>lle-bout: What's the advantage over launching it directly from your Sway configuration? (The dex description in Guix is meaningless.) <lle-bout>nckx: well gnome-keyring is a bit special <lle-bout>nckx: what do you use for fetching maildir with mu4e? <lle-bout>I don't want to put my email password as plain text in a file <lle-bout>I would like to use libsecret to fetch the password <lle-bout>offlineimap sounds nice but python2, isync doesnt seem to support having password elsewhere than plain text in config <nckx>lle-bout: I do just the latter. ¯\_(ツ)_/¯ <yoctocell>I use pass to output the password for my account <nckx>lle-bout: [Why] can't you use GPG with mbsync? <nckx>Not familiar with libsecret. <lle-bout>Maybe I should but I am concerned the communities around pass arent as mature as keepass <lle-bout>Especially I have a really good Android app for keepass called Keepass4Droid <lle-bout>Which autofills great and auto-adds URL of sites into pass entries when you manually select them so it works better the next time <lle-bout>I saw the Password Store For Android app on FDroid which looks interesting but havent tried switching yet <jlicht>does guix have something similar to 'nix-build -vv', which prints each copied source file from their equivalent of 'local-file' <lle-bout>nckx: considering Emacs has libsecret integration it can also integrate with KeepassXC given I use it as my libsecret daemon <lle-bout>nckx: libsecret basically is some standard API for keychains/keyrings on the desktop <lle-bout>or not on the desktop but it's a dbus api <lle-bout>nckx: I think libsecret is a really good mechanism and well implemented also in gnome-keyring <jlicht>lle-bout: it works with emacs' auth-source? If so, cool! <lle-bout>jlicht: yes there's a libsecret backend :-) <roptat>oh! giving it less cores made the build pass, no need to change anything \o/ <roptat>except: In procedure mkstemp!: No such file or directory <roptat>oh nevermind, it's the no-test variant still <roptat>arg, because of the presence of /usr etc, it built to lib64 instead of lib, that's why it failed <roptat>I'll have to build on a guix system I guess <jlicht>roptat: how the tables have turned ;) <nckx>lle-bout: I'll pass (N.P.I.) on libsecret but I've now GPG-encrypted my authinfo. Happy? Good. <jlicht>is it SecOps-Shame-Saturday already? I have some entries of my own :) <roptat>I think libreplanet is starting soon :) <lle-bout>Who is a GNU Guix committer and would like access to a powerful AMD Epyc 7nm server for GNU Guix offloading? <lle-bout>roptat: Equinix Metal is adding Ampere Altra to it's server portfolio, maybe after that I can rent one and share, not sure, since they seem to only offer overkill configs it might be too expensive <lle-bout>Also I am not sure if armhf is actually supported by the Ampere Altra chips <arxbrt>Hello. I'm using ecryptfs-utils on guix. But when I run ecryptfs-mount-private, it shows "setreuid: Operation not permitted" <lle-bout>It would be nice if we had a secure way of sharing access to GNU Guix offloading machines, like some sort of shared store with split ownership <nckx>arxbrt: Does running it as root help? If not, or if you want to actually setuid, and you're running Guix System, add (file-append ecryptfs-utils "/bin/ecryptfs-mount-private") to your operating-system's setuid-programs field. <lle-bout>Either way, I think with VMs since I have ZFS deduplication on, the /gnu/store-s wouldnt actually consume so much duplicated space. <nckx>And probably some others like ...-umount-... (it's a list). <arxbrt>nckx, thank you very much. I'll try <lle-bout>The security issue is that for offloading to work the server needs to trust the store key of GNU Guix offloading clients, which means they can spoof any store item with any contents (including malware) <nckx>‘Offloading access‘ == ‘full control’. <lle-bout>The problem with VMs is that they are not efficient in terms of resource sharing and the problem with LXC or other containers is that GNU Guix build sandbox doesnt work inside them. <lle-bout>Nested unprivileged containers/namespaces.. can't wait for that <lle-bout>GNU Guix offloading is so handy, but maybe there would be a way offloading could work without having to authorize store public key of clients? <lle-bout>Clients would trust the offload machine's store key but not the contrary <lle-bout>So it would mean instead of transferring store items directly it would transfer the derivations and the offload machine would rebuild them <lle-bout>A bit less efficient but once the store is populated with all these derivations it would work fine <lle-bout>arxbrt: I advise you (setuid-programs (append (list (file-append <lle-bout> ecryptfs-utils "/bin/ecryptfs-mount-private")) %setuid-programs)) - so you don't lose the default ones <lle-bout>re: secure offload sharing - this way I can share access to my build machines without putting myself in danger <arxbrt>lle-bout: Thank you very much. I'm trying it <lle-bout>Better granularity on what you trust a store public key for *jackhill is excited about watching the Software Heritage talk at libreplanet right now! <roptat>my guix daemon is from yesterday, yet I can't use binfmt anymore <roptat>I don't have guix-support? anymore, because it's not supported anymore <cdegroot>Quick random question - I'm trying to build something in a container, but the build scripts use `/usr/bin/env` which my container doesn't have. I can make it each time it starts, but that is tedious. Is there some package that'll add that? Smells like a very standard *nix thing to have. <cbaines>I sometimes find restarting the qemu-binfmt shepherd service, then restarting the daemon helps <roptat>cdegroot, we don't really have these "*nix" stuff, we don't follow the fhs <cdegroot>Well, /usr/bin/env predates the FHS, by some decades I think. Hence me using the "*nix" term ;-). <cdegroot>(ok, "decades" may be overblown, but "a long time" for sure lol). <roptat>if that's when building a package with guix, you can substitute that for the full path of the program you're trying to use <cdegroot>Yeah, but scripts call scripts and then it breaks. <roptat>there's a phase that replaces all the shebangs at the beginning of a build for instance <roptat>if that's a guix system, then you can use the etc-service-type <roptat>there's another service you can use to create /usr/bin/env <cdegroot>For now, `mkdir -p /usr/bin; cp `which env` /usr/bin` works but I like my container to be more reproducible than that :) <roptat>cdegroot, special-files-service-type <cdegroot>(now figure out how to add /usr/bin/env in a command-line `-e` guix environment argument ;)) <roptat>if you're using a container (--container or -C), you can use --expose=/usr/bin/env=bin/env (or the other way around) <cdegroot>Geez.... I should learn to a) RTFM and b) use my brains a bit. Thanks :) <cdegroot>--expose=$GUIX_PROFILE/bin/env=/usr/bin/env <cdegroot>does what I want (for now. One day GUIX_PROFILE won't be the profile I'll be using for the build, but for now, it's Good Enough[tm]). <arxbrt>nckx, lle-bout: I tried to add ecryptfs-mount-private to setuid-programs field, and it appears in /run/setuid-programs directory <arxbrt>But when I use that command, "setreuid: Operation not permitted" was showed again <arxbrt>Is there any tutorial for ecrypting home directory on Guix system? ***lle-bout` is now known as lle-bout
<lle-bout>arxbrt: I don't have it on so I wouldnt know, but keep investigating why that error would happen, did you check the binary is indeed setuid and that it needs to be setuid? Check which binary actually need to be setuid if any <arxbrt>lle-bout: Thanks. I'm using manjaro on my desktop, and I searched /usr/bin. There's no ecryptfs-* command with SUID set <arxbrt>And then I tried to set all the ecryptfs commands to setuid-programs, but also setreuid error occured <lle-bout>arxbrt: how is it run there on Manjaro? The ecryptfs commands? As what user? As what point during login? <arxbrt>No error. I've been using ecryptfs on manjaro <arxbrt>lle-bout: But I noticed. when I encrypted my home directory on Guix, `sudo` can't be used <arxbrt>sudo: /run/current-system/profile/bin/sudo must be owned by uid 0 and have the setuid bit set <cdegroot>Is there a reason there's no libstdc++ package? I'm looking at the package definition, and only make-libstdc++ is exported. <cdegroot>Yeah, but what if you only need the runtime? <cdegroot>(I'm making things hard on myself: my first Guix package is .NET which has a.... somewhat arcane installation procedure ;-)) <cdegroot>(strange, I have gcc-toolchain installed but libstdc++ is still not there) <jlicht>cdegroot: afaik, nobody with a web presence figured out how to bootstrap .net yet <cdegroot>I've never shied back for hard puzzles ;-). <jlicht>not to say that it can't be done, so good luck ;) <cdegroot>(but I wish Microsoft would publish their Debian package build process, that'd save me a ton of time). <cdegroot>(I guess that even for them, the scripts are embarrassing :P) <cdegroot>But yeah, I've given myself a bit of time still for a source build before I give up and wrap a binary distribution. <cdegroot>roptat: I have gcc-toolchain, but no libstdc++. Looking in the store, I see it in packages called `gcc-<version>-lib` but these packages don't seem to be directly installable; my GUIX_ENVIRONMENT inside the container doesnt contain symlinks to them. I'll keep digging though :) <cdegroot>(I guess I need to do more patchelf stuff to the downloaded .net binary, just figuring out how to reliably find the paths involved) <cdegroot>(I guess I need to do more patchelf stuff to the downloaded .net bootstrap binary, just figuring out how to reliably find the paths involved) <cdegroot>Yay, creating and compiling a C++ hello, world and using that to set the rpath of the dotnet executable worked. Magic :) <lle-bout>arxbrt: what does your (setuid-programs ..) entry look like in your operating-system definition? <lle-bout>arxbrt: setuid programs are in /run/setuid-programs so encrypting /home shouldnt affect it <jfred>is that guix revision too old or something? <lle-bout>jfred: there's a point it doesnt work yes, unfortunately I think we can't have it work before it was implemented <cbaines>I'm not sure it works like that, although Guix may need improving to work with older revisions <cbaines>I also get an error with that revision though e4a744da9f772b0073759b4c09f622fd50159944 but that could mean that specific revision is just broken, I'm unsure <rekado_>;;; [2021/03/20 17:12:50.841665, 0] write_to_channel_port: [GSSH ERROR] Remote channel is closed: #<input-output: channel (open) 7f4310b77820> <roptat>\o/ managed to build with a bit more timeout <rekado_>the signing key of the source has already been imported on the target; I wonder why the channel is closed. <roptat>arg, I pushed an incorrect commit ./ <jfred>cbaines: maybe related to the guile 2 -> 3 migration? <jfred>based on the error message... maybe time-machine can't go back to pre-guile-3? <avalenn>apteryx, acrow, could it be that some dependencies of google-protobuf are only for testing? <avalenn>I'd like to advance on packaging this one too as it is key to a lot of Go software. ***markw is now known as mjw
<apteryx>avalenn: no, they are needed for its bootstrap ***jx97 is now known as jx96
<davidl_>Anyone who has a working cuirass config with their custom channels that is using a recent version of cuirass? <apteryx>rekado_: I have a patch doing away with the patched guile-lib package in doc/build.scm. I've built the HTML manual using './pre-inst-env guix environment guix --pure -- make doc/guix.fr.html' and checked the resulting files. Any other test I should do? <apteryx>avalenn: perhaps the next update to the go importer will help us; I've yet to try it. I can ping you when it's ready to review <avalenn>apteryx: thanks. I will wait for your ping then. <apteryx>currently testing the guile-lib update doesn't break anything. Next in line is the go importer update, which builds on it. <clacke>Is anyone using IBus input methods or other input methods in Guix? <apteryx>I'm a bit annoyed that switching language input has some latency to it <clacke>(it's not.called GuixSD anymore, right?) <clacke>my sidecar Guix apps do not recognize my IMs <clacke>are there special env vars set for Guix specifically? <charles`>vagrantc, guix pulling from my working tree says that git can't locate remote-tracking branch 'origin/keyring' <vagrantc>charles`: oh, you'll need to checkout the keyring branch ... and annoyingly keep it up to date <apteryx>clacke: probably XDG_DATA_DIRS, let me check <apteryx>I have this in my ~/.bash_profile: export IBUS_COMPONENT_PATH="$HOME/.guix-profile/share/ibus/component${IBUS_COMPONENT_PATH:+:}$IBUS_COMPONENT_PATH" <charles`>vagrantc, by keep up to date you mean git pull? <apteryx>also export GTK_IM_MODULE=xim, export XMODIFIERS=@im=ibus, and export QT_IM_MODULE=xim. I recall reading about these are 'wrong' according to one of the current maintainer of ibus, but at the time I had to set it this way to get it working across all applications <clacke>but I think your mix of ibus and xim looks surprising <vagrantc>charles`: yes, whenever there are keyring updates, you need your local keyring branch to be in sync, otherwise the guix authentication stuff will fail when pulling from your local branch <clacke>I'll try xim next time, I think ibus-daemon runs an xim compat layer anyway <apteryx>clacke: that's probably more correct. As I said this was a hack required to get it working in some places (icecat? gnucash? can't remember) <clacke>apteryx: thanks, can't verify right now but you gave me something to try and now I know it's supposed to work and works on System <charles`>it looks like I have to sign my commit too <vagrantc>charles`: i guess if you're doing local commits without signing them, it won't matter, as you'll need to use "guix pull --disable-authentication ..." <charles`>Heh, that certainly helps. I can't even find the package that provides gpg. Is there a guix equivillent of `dnf provides <command-name>` <nckx>charles`: gnupg, and no. <nckx>arxbrt: Did you manage to solve your problem? <lfam>sneek: later tell lle-bout: I have always ignore Xen entirely. It's not used by Guix, many of the "fixes" are in the kernel, and I think that, in general, high-security virtualization is not a feasible goal for a volunteer project <lfam>I didn't even realize we had a xen package now <lfam>I probably won't change my approach, however <nckx>We've had it for quite a while, I've used it once or twice. <lfam>Yeah, I see it was added in 2019. I'm sure I noticed at the time, but I forgot <lfam>Got any sense of it's still widely used in "industry" (cloud hosting?) <nckx>I can't give a meaningful answer to widely, but it's still used above noise level by less gargantuan VPS providers. Possibly the lower-end ones, but I might be making that up entirely. <lfam>sneek: later tell lle-bout: About QEMU CVE-2021-3416, we can concatenate the 10 commits into a single patch file, from qemu.git, for example: `git format-patch --stdout 705df5466c98f3efdd2b68d3b31dad86858acad7^..37cee01784ff0df13e5209517e1b3594a5e792d1` <lfam>sneek: later tell lle-bout: In the past I personally did not rush to fix these QEMU denial of service bugs. They seem to discovered all time. Maybe once a month I'd fix them all at once. <lfam>The thing with the QEMU bugs is... it's a game of whackamole <lfam>We can never say that the package is "fixed" <lfam>Very complicated software with an old C codebase <lfam>Yeah, extremely similar situation <lfam>The nice thing about Linux is they are able to issue regular releases <nckx>Is QEMU so understaffed? <lfam>It's just not as important <lfam>And likely understaffed compared to Linux. I haven't checked but I'd guess it has less than 10% the developers. Does anyone even get paid to work on it full-time? <nckx>The vast majority of services that supposedly run on ‘Linux’ actually run on (GNU/Linux/)QEMU/Linux. I believe you if you say the perception is that it's ‘less important’ but it's a very foolish one. <lfam>Are they actually using QEMU? Or just KVM? <lfam>I find it hard to believe that AWS EC2 and similar services are running QEMU <lfam>Most of these bugs in QEMU come from emulation of hardware, which isn't necessary in the cloud <nckx>lfam: Hm, you're right, seems AWS uses something else. <nckx>(Why do people still use AWS? Anyway.) <apteryx>lfam: I'm pretty sure Red Hat is invested in QEMU <nckx>lfam: Necessary or not, it is common. <lfam>That makes sense apteryx, since many of these bug reports come from RH *nckx → dinner. Stay safe everyone. Don't virtualise with strangers. <apteryx>There's a talk about Jami on libreplanet right now, streamed live if anyone is interested <lfam>I suppose that the appeal of AWS is not understood, one can assume they have an unusual perspective :) <lfam>I mean, if the appeal is not understood <mdevos>I have two patches that (partially) fix a bug I reported. Should I send it to guix-patches (correct mailing list) or NNNNN@debbugs.gnu.org (bug & patch are linked together)? <sneek>Welcome back mdevos, you have 1 message! <sneek>mdevos, nckx says: Eh, didn't feel your ping in #46564 (autoconf-wrapper) but thanks for making the change! <MrtnDk[m]><sneek "Welcome back mdevos, you have 1 "> mdevos <vagrantc>wow, substitutes for aarch64 seem to be doing a *lot* better than ~6 weeks ago