IRC channel logs

2022-03-13.log

back to list of logs

<unmatched-paren>there *are* linux distros that are not gnu/linux (see alpine), but fedora is not one of them
<Ribby>Well, I'm not really sure. I just have a gut feeling about its development history. There's got to be a reason for qubes to prefer fedora store over debian. I'm getting into 'there's a reason for something', but I'm overthinking than necessary.
<Aurora_v_kosmose>Ribby: Not really. Dom0 runs on Fedora but they've got Debian and have added Gentoo templates not too long ago.
<Aurora_v_kosmose>Dom0 is honestly entirely incidental and serves as nothing more than a control hub.
<Aurora_v_kosmose>unmatched-paren: You can run individual firefox instances spawned from dispVM/disposable-vm templates, which will run in individual self-deleting-on-close VMs.
<Aurora_v_kosmose>Works very well when used in conjunction with Whonix templates/qubes to spawn disposable TorBrowser instances.
<Ribby>I was trying to open up a Tor browser, but I failed in a GUI sense.
<Aurora_v_kosmose>Adding Guix into qubes is somewhat finicky because of the way the root filesystem is typically running on a disposable partition backed by read-only partition from the template outside the control of the given appvm trying to use Guix. It doesn't cause issues at runtime, but it will mean no persistence.
<Aurora_v_kosmose>Overlayfs & setting things so Guix writes to directories overlayed from /rw to /gnu (and a few others in my notes) entirely fixes the issue.
<Aurora_v_kosmose>Currently a bug in Debian with glib & Guix makes it necessary to hinder the /etc/profile.d/guix.sh file otherwise it causes general failure of most things graphical on that qube.
<Aurora_v_kosmose>(has to do with conflicting glib versions)
<Aurora_v_kosmose>The bug is Debian-specific. Debian AppVMs/Qubes inherit it from Debian.
<unmatched-paren>i finally managed to stop doing the thing where i intentionally enter a wrong sha256 hash in a package definition then try to build it and copy the correct hash from the error message with this shell script: https://paste.debian.net/1233985/
<Ribby>Okay, so basically, debian have designs that conflict with the qubes virtual bootloader hub.
<Aurora_v_kosmose>Ribby: Basically yeah. The gnome terminal service for example fails on boot for such Debian VMs when graphical programs happen to be installed in Guix that use glib.
<Aurora_v_kosmose>It also breaks a number of other things.
<Aurora_v_kosmose>Just adding a "return 0" at the top of /etc/profile.d/guix.sh fixes it.
<unmatched-paren>gnome-terminal has a service?
<Aurora_v_kosmose>Of course if you want to conveniently use Guix then you need to load that file at some point anyway, so I recommend copying it unmolested somewhere else first (inside the templatevm) and manually sourcing it from terminal when you use Guix stuff.
<Aurora_v_kosmose>unmatched-paren: Yeah, Gnome terminal is a bit weird. Its daemonized structure also makes it unusable in dispvms/dvms
<unmatched-paren>s/Gnome terminal is a bit weird/Gnome is a bit weird/
<Aurora_v_kosmose>The specifics don't come to mind quite right atm, but it's a known issue. Recommendation is to instead use another graphical terminal in dispvms.
<Aurora_v_kosmose>unmatched-paren: That is true.
<unmatched-paren>:)
<Ribby>Coming from Red Hat's funding to Fedora's development, I can see why Qubes went for a matter of convenience.
<unmatched-paren>ah, of course, it uses a daemon to allow you to run multiple terminal clients with only one driver backend running
<unmatched-paren>but surely the load of a vt backend would be far lighter than a GTK3 client application?
<unmatched-paren>sounds like premature optimization to me
*Aurora_v_kosmose shrugs
<Aurora_v_kosmose>In any case, the way it tries to fork the only GUI program open at the time and closes it when spawning another is, I think, a race condition.
<unmatched-paren>apparently even foot has a daemon mode. maybe there's some major overhead to pty handling that i don't know about?
<Aurora_v_kosmose>nvm, the issue is that the spawning program has to remain open
<Aurora_v_kosmose>If you create a dvm for Emacs, spawn Firefox, and close Emacs, the dvm will shutdown.
<Aurora_v_kosmose>So yeah, that's what gnome-terminal does that doesn't interact well.
<Aurora_v_kosmose>xterm is pretty much the standard debugging terminal for qubes. All templates have it.
<Ribby>To me, qubes is like an emulation taking on too many resources just to balance out multiple OS. I get that each OS have their own specifications for certain situations, but qubes is going to be a sinking ship.
<Aurora_v_kosmose>Qubes is a way to securely manage VM/containers for the sake of security.
<Aurora_v_kosmose>You could, in theory, build Windows versions of the programs it uses to communicate with guests & host, and have Windows appvms too.
<Ribby>Basically, it's a sandbox in case something goes amiss?
<Aurora_v_kosmose>Ribby: Pretty much.
<Ribby>I did tried to get into the bandwagon. Maybe I don't have enough experience with virtual machines.
<Aurora_v_kosmose>With some niceties such as secure explicit clipboard transfer between VMs & such (instead of accidentally leaking it across VMs like you might with homebrew virt-manager).
<Aurora_v_kosmose>Eventually, the API maturing & being developed further, they plan to create Qubes Air. Which is effectively the ability to use remote machines as compute backends the same as it currently uses Xen VMs.
<Aurora_v_kosmose>That way you could say... use a low-end laptop and a bunch of cheap (perhaps Libre) SBCs instead of a workstation.
<Aurora_v_kosmose>That would effectively be a superset of using Xpra with a bunch of SBCs.
<Ribby>As long the qubes itself isn't infected, it should work out in theory.
<Aurora_v_kosmose>Indeed.
<Aurora_v_kosmose> https://www.qubes-os.org/news/2018/01/22/qubes-air/
<Aurora_v_kosmose>Part of the Administation API improvements related to the intended decoupling from Xen woudl allow, for instance, to add seL4 as a backend to run things on.
<Ribby>By hypothesis, I'm not confident/sure enough for a low-end laptop and sbcs to handle qubes functions, let alone have its own security measures, system hardware or software wise.
<Ribby>Decoupling from Xen? Could be a good thing!
<Ribby>Just speculation, of course.
<Aurora_v_kosmose>Ribby: You could run the minimum GUIVM, netvm and firewallvm on a low-end netbook, then using the SBCs as raw qubes of their own.
<Aurora_v_kosmose>This is somewhat wasteful of hardware in-case one gets pwn'd, but doesn't require anywhere near as much resources as using them as VM-running hosts of their own.
<Aurora_v_kosmose>I say minimum but if you feel like completely disregarding recommend security practices, you can run all the minimum qubes/vms I mentioned inside one single qube.
<Aurora_v_kosmose>It does however mean that anything pwning you through your network stack will then be able to entirely take over your session.
<Aurora_v_kosmose>(Which is why the sys-net vm is usually separated from everything else and does nothing but networking)
<Aurora_v_kosmose>A malicious sys-net is no more dangerous than a malicious ISP.
<Aurora_v_kosmose>Well, unless something goes horribly wrong with what's isolating sys-net, in this case that's Xen.
<Ribby>I'm trying to figure out how qubes is best used. It's like a real Unix server network.
<Aurora_v_kosmose>It's very much a coordinator for contained security domains.
<Aurora_v_kosmose>While Arcan is a GUI-first take on Plan9.
<Aurora_v_kosmose>(Over-the-network parts WIP)
<Aurora_v_kosmose>The architecture of Qubes is a bit confusing unless you already were homebrewing containment VMs yourself prior (I was).
<Ribby>Denial of service attacks could get sophisticated in terms of identifying the vm qubes. If attacks can hit all vms at once, qubes might have a problem figuring out the processes.
<Aurora_v_kosmose>Ribby: You can decide how many vcpus you assign to a qube.
<Aurora_v_kosmose>The only real DoS you could do that would affect them all would be to try & kill the sys-net qube. (Though you could have many of them, if you have many PCIe NICs)
<Aurora_v_kosmose>And I say all... but network-less qubes would be entirely unaffected.
<Ribby>But yeah, I think you are right about the potential of qubes being in sbc, with quebs on a hub computer.
<Ribby>maybe sys-net qube needs its own sub qubes.
<Aurora_v_kosmose>Ribby: Currently only a single Net qube is assignable for a given qube (such as sys-firewall being assigned sys-net), but presumably that could be modified so you have sys-net-{1..4} all assigned as network providers for sys-firewall.
<Aurora_v_kosmose>Or you could just manually switch when one of them goes down, since you can change the Net qube for a qube at runtime.
<Ribby>I'm not sure if qubes is for research or for practical applications. It's hard to tell.
<Aurora_v_kosmose>Both.
<Aurora_v_kosmose>It's active research into secure compartmentalization in computing.
<Aurora_v_kosmose>At the OS level.
<Aurora_v_kosmose>Consider it an (eventually) backend-agnostic manager for arbitrary secure backends to run contained workloads on, whether those backends be remote machines, Xen VMs, Genode processes or seL4 processes.
<Aurora_v_kosmose>(Or anything else, my listing is not exhaustive.)
***rdrg109_ is now known as rdrg109
<Ribby>I think it could also go into the bootloader level as well.
<Ribby>Maybe, because qubes is like an emulator, it should act like a bootloader?
<Ribby>*emulator for OS.
<Ribby>It seems that qubes right now, is a bootloader OS. I think that's what is it.
<Aurora_v_kosmose>That's pretty much its intent, yeah.
<Aurora_v_kosmose>With a relatively user-friendly UI.
<Ribby>That's true, it being in the works.
<Aurora_v_kosmose>Yeah.
<Aurora_v_kosmose>dom0 being Linux-based is mostly for convenience and also because the first backed they decided to prototype with, Xen, intends for dom0 to be a Linux instance.
<Ribby>Virtualization and bootloading is quite similar. I'm sure there are differences too.
<Ribby>I was about to ask, "Why not have the bootloader be the OS? That is GNU Grub as OS?"
<Aurora_v_kosmose>The agnosticism regarding the ultimate backend running workloads is the primary difference Qubes intends, as far as I understand it.
<Aurora_v_kosmose>Administration of filesystems, logs & such are also familiar with most people in Linux, so dom0 as Linux facilitates debugging.
<Aurora_v_kosmose>Otherwise they'd need to make new programs for all those things.
<Aurora_v_kosmose>(Or at least port existing ones)
<Ribby>I'm not sure about emulating OS vms, and how they will yet provide a basis for secure compartmentalization. I thought qubes is actually an OS, but with compartmental hardware/system/software modules. Maybe multiple OS platform emulations are a bit ambitious?
<Aurora_v_kosmose>The specifics of how Qubes uses Xen VMs for isolation, and the CPU settings & they use for such, are a bit beyond my relatively high-level knowledge.
<Aurora_v_kosmose>Ribby: It is an ambitious project, but it's ultimately necessary given that no one seems intent on switching over to the few capability-based secure OSes around
<Aurora_v_kosmose>(And in theory such an OS could suffer from exploitable bugs which containment with Qubes could make harder to exploit)
<Ribby>It's like a software version of multiple shared servers.
<Aurora_v_kosmose>Monolithic memory-unsafe ambient-authority ridden C kernels won the war and we all suffer for it.
<Ribby>front-end, back-end, yes.
<Ribby>Oh, I forgot about sandboxes.
<Aurora_v_kosmose>I think Qubes still would have a place even if properly memory-managed OSes (and object-oriented OSes) were the main thing in use, but it wouldn't be quite as dramatically obvious that it's needed.
<Ribby>Maybe, in the future, multiple OS emulations will find a purpose?
<Ribby>Oh, I g2g, it is a pleasure to have this discussion. The more is known.
<Ribby>Away msg.
<Aurora_v_kosmose>Ribby: Ah, feel free to chat again.
<Aurora_v_kosmose>Ribby: A note whenever you check your logs: Arguably such emulation already does, but ultimately the programs & work done on them is what matters for most people. It's also why, as a Linux user prior, all of my qubes are Linux instances with no loss in work done or potential (well, GPU is a bit complicated).
<the_tubular>How can I remove gdm ?
<oriansj>the_tubular: you just don't include it in your system config
***alMalsamo is now known as lumberjack123
<the_tubular>Ohh that makes sense, I must have missed it in the config I did with the installer :/
<oriansj>it would be under the services bit
<the_tubular>Thanks :)
<oriansj>if you are going for absolute minimal config; there are a few things you can do to strip things down
<oriansj>for example going full explicit: https://paste.debian.net/1234001/
<Aurora_v_kosmose>the_tubular: I'm fairly fond of lightdm myself, if you feel like keeping a display manager.
<the_tubular>Yeah, don't need no display manager
<oriansj>well slim is the lightest display manager guix has (it unfortunately doesn't work for wayland desktops like sway) if one wanted to go that route but it isn't actually required for desktop or graphical applications and especially not something one would want on a server.
<atka>does guix have an issue booting btrfs filesystems that were created with --checksum xxhash?
<atka>scanning for btrfs filesystems: btrfs error: error │ agronholm
<atka> │ | allocating xxhash64 hashy
<atka>sorry for the mess, anyway changing my filesystem to use crc32 works
<apteryx>atka: I don't see why it wouldn't work; it seems the kernel has support for XXHASH
<apteryx>c.f.: zgrep XXHASH /proc/config.gz - > CONFIG_CRYPTO_XXHASH=m CONFIG_XXHASH=y
<apteryx>ah but you'd need to add the module to the initrd
<atka>ahh yep, didn't do that
<atka>I'm still green, I'll have to look into that
<atka>apteryx: something along these lines? (initrd-modules (append (list xxhash %base-initrd-modules)))
<apteryx>the module name should be a string
<apteryx>and %base-initrd-modules is a list, so you need to (cons "xxhash" %base-initrd-modules)
<atka>alright, thanks, I'll play around with it
<apteryx>OK! I'll catch some zz, good luck!
<atka>thanks, goodnight
<raghavgururajan>Hello Guix!
<unmatched-paren>hello guix :)
<unmatched-paren>should i enable thermald? `ps aux | grep thermald` only returns the grep process itself
<nouun>I've been using guile for scripting and was wondering if there's a way to hide the 'note: source file new than ...' message.
<unmatched-paren>i checked `lscpu` and it looks like the cores are all running at less than half the maximum speed, and i'm not sure whether that's a good or a bad thing...
<unmatched-paren>there was a brief discussion yesterday about thermald and cpu clock speed, so i decided to check mine -.o.-
<unmatched-paren>i have basically zero knowledge of hardware
<unmatched-paren>cpu MHz : 2300.000
<unmatched-paren>CPU max MHz: 4900.0000
<unmatched-paren>well, i did `sudo thermald` and so far nothing has exploded
<unmatched-paren>hm, that's strange: gnu/services/pm.scm has a ? 'unknown character' tile in it
<unmatched-paren>either it won't copy or it only appears in kakoune...
<bovid-19>hello guix!
<unmatched-paren>\o
<unmatched-paren>does guix support seatd yet?
<unmatched-paren>(i'm asking way too many questions :P)
<raghavgururajan>sneek, later tell unmatched-paren: You can enable thermald using thermald-service-type, *if* your CPU is supported.
<sneek>Okay.
<unmatched-paren>how would i try to fix this: 'error: conflicting types for ‘mktemp’' when packaging a C program?
<sneek>unmatched-paren, you have 1 message!
<sneek>unmatched-paren, raghavgururajan says: You can enable thermald using thermald-service-type, *if* your CPU is supported.
<unmatched-paren>it looks like glibc declares mktemp twice for some reason?
<unmatched-paren>i tried it with GCC, Clang, and CProc and all three reject it
<unmatched-paren>i would try with tcc but its build fails for me
<unmatched-paren>raghavgururajan: yeah, i enabled it. it's working fine.
<pmk>Hi guix. I have a question: I am trying to define a package, but the source needs a patch before it can be built correctly. I currently have the definition in a private channel and I placed the patch in a subdirectory ~patches/~ under the root of my channel but when building the package does not seem to be able to find the patch. Should I be doing something differently?
<unmatched-paren>pmk: this channel: https://github.com/BIMSBbioinfo/guix-bimsb puts them at the top level, maybe try that?
<unmatched-paren>wait, are you building the package with `guix (build|package) -f FILE.scm`?
<pmk>unmatched-paren: I will try the top level. I've tried both using the file and just the channel. Both have failed
<pmk>Thanks for the help.
<unmatched-paren>i might be talking complete nonsense though :)
<unmatched-paren>try looking at this email thread too: https://www.mail-archive.com/help-guix@gnu.org/msg06315.html
<f1refly>what support channel would be right to ask about the guix build system? I still don't understand how to tell the cargo-build-system not to try to package an optional dependency :/
<nouun>I'm trying to install a guile dependency through 'guix shell guile-semver' but I'm still unable to use semver and it's no where under $GUIX_ENVIRONMENT, am I missing something?
<nouun>Cancel that, took a look at another package and figured I could use guix shell.
***Guest5602 is now known as roptat_
***roptat_ is now known as roptat
<alethkit>Hiya! Attempting to set a keyboard variant via https://guix.gnu.org/manual/en/html_node/Keyboard-Layout.html results in "guix system reconfigure" throwing a "Wrong type to apply: <keyboard layout record>" error
<alethkit>This seems to happen with any keyboard variant (although I only tested the ones on the documentation, in addition to my own configuration)
<SeerLite[m]>How are you setting the keyboard layout? Are you doing it just like the operating-system example in that manual page?
<alethkit>Yup!
<alethkit>Let me attach a snippet from my config: https://paste.debian.net/hidden/d7715f4a/
<SeerLite[m]>alethkit: Ah, your issue is you're setting the xorg-configuration to the keyboard-layout
<SeerLite[m]>Should be (xorg-configuration (xorg-configuration (keyboard-layout ...
<SeerLite[m]>So that xorg-configuration is set to a xorg-configuration with the keyboard-layout keyboard-layout
<SeerLite[m]>:S
<nckx>Simples.
<nckx>(It reads weird, but read it as (set-xorg-configuration-to (make-xorg-configuration (set-keyboard-layout-to (make-keyboard-layout …)))).)
<nckx>f1refly: This IRC channel (when busy) or help-guix at gnu dot org.
<alethkit>It feels like a half-baked DSL
<alethkit>Which I guess is exactly what it is
<alethkit>would be nice if the naming was saner
<raghavgururajan>f1refly: Singapore?
<nckx>Consistency trumps brevity here, I think. It's just record syntax, so you don't have to learn a cool new service DSL.
<raghavgururajan>f1refly: Never mind! Wrong person. I was thinking of pickfire.
<alethkit>Are there docs for record syntax? Would be nice to know for next time!
<nckx>raghavgururajan: Singapore is not an official Guix help channel.
<nckx>alethkit: Good question. I don't find a good (=simple, short) example for people just interested in the structure in the manual.
<maximed>alethkit: FWIW, the record syntax for keyboard layouts is the same as the layout for packages (except for other field names of course)
<sneek>Welcome back maximed, you have 1 message!
<sneek>maximed, apteryx says: re about splitting same-package changes; there's a balance to be striken, and it can be subjective, yes :-)
<maximed>more generally, xorg-configuration, keyboard layouts, packages and operating-system records use the same underlying syntax
<pmk>unmatched-paren: Just for documentation's sake, patching worked for me when the patch was at the root dir of the channel. It worked both with the -f flag and without it.
<Haider>I have a problem, that is I changed a username of one of my gnu guix accounts, however, the name doesnt change in elogind.
<Haider>I am most likely doing something wrong, but I have no idea what that is
<SeerLite[m]>It'd be nice to be able to refer to the LTS version of a package without having to know the version number
<SeerLite[m]>Something like linux-libre@lts or node@lts
<SeerLite[m]>I mean with specifications in the CLI of course
<SeerLite[m]>Haider: How did you change the username?
<nckx>(They're off-line, if they intend to return you can use ‘sneek: later tell […]:’)
<SeerLite[m]>Ohh, I didn't notice they left. Thanks
<SeerLite[m]>sneek: later tell Haider: How are you changing the username? Did you change it in operating-system in the config file and then reboot?
<sneek>Got it.
<nckx>I know that the GECOS (‘real’ or ‘friendly name’ or whatever you want to call it) field is treated as precious state: once the user account exists, Guix won't overwrite it. It's also frequently used in friendly login managers. I wonder if that's what they mean.
<nckx>Less sure about the unix username. I'd expect Guix to update it unconditionally, but I'm not going to test that here…
<SeerLite[m]>Oh, that might be it. Guix doesn't have a way to declare that, does it? I think NixOS does
<nckx>It does, in the comment field, but it's only set once when the account is created. If you change it and reconfigure Guix will keep the existing value, by design, so users can change their name independent of the sysadmin.
<nckx>s/in the/as the/
<nckx>(comment "Bob's sister") in the manual :)
<SeerLite[m]>Heh yeah I had just found the explanation in the manual
<SeerLite[m]>I see. Though something's not clear to me: Does Guix never change it or does it only change it so long as it hasn't been changed by the user? The manual makes me think it's the latter
<nckx> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/build/accounts.scm#n488
<nckx>I don't think there's any way to tell *who* set it, SeerLite[m], so if one exists it's kept, no matter the origin.
<nckx>This logic is also unique to the GECOS field so if Haider was talking about the ‘unix’ username… something strange is afoot.
<nckx>It should always be overwritten at boot.
<nckx>If not earlier.
<raghavgururajan>nckx: There is a developer from Singapore who does suckless tools videos on YT. I just misread the nick.
<nckx>:)
<nckx>raghavgururajan: Do they also frequent #guix?
<raghavgururajan>nckx: Nah! I was surprised to see them here. Their nick is pickfire, but got confused with firefly.
***iyzsong- is now known as iyzsong
<itd_>Hi. Does patch [0] look sensible (tried to follow 4e0c4ab; am unsure about "gnu/local.mk")? For me it fixes python-mypy on i686-linux [1]. Thanks! [0] https://paste.debian.net/hidden/74259174 (based on [2]) [1] https://ci.guix.gnu.org/build/484670/details [2] https://github.com/python/mypy/pull/12332
<SeerLite[m]>Would it be possible to make Guix suspend the actual build process when sending a SIGSTOP to the `guix build` command (or ^Z from the terminal)?
<nckx>Probably.
<nckx>itd_: The patch itself (I can't speak for the patch in the patch :) looks good. Minor: please keep local.mk entries alphabetical, and IMO the patch name doesn't need to be repeated in the changelog (just ‘Use it’, as you wrote ‘Add it’).
<nckx>& thanks!
<mroh>SeerLite: https://lists.gnu.org/archive/html/guix-devel/2020-11/msg00048.html
<SeerLite[m]>mroh: Thanks for the link! I guess it's too hacky/hard to implement into Guix, but there's a workaround of parsing the output of `guix processes`
<nckx>> which can have side effects
<nckx>Hmm, good point, although I send builds SIGSTOP… a lot?
<nckx>It's definitely not transparent, though, that's true.
<nckx>It also seems like setting a higher bar than the current status quo, when talking about ‘forwarding’ a ^Z that's happening anyway (without the expected effect), vs. creating a new command-line option.
<alethkit>Do window managers come with configuration records of their own, or are you supposed to manage them via guix home/configuration files?
<nckx>The latter, alethkit.
<alethkit>Thank you!
<the_tubular>It's pretty much the answer for everything alethkit :)
<the_tubular>guix home is still very "underused" from what I understand it should be able to do.
<jlicht>Does someone happen to have a kubernetes-from-source package definition stashed away somewhere?
<alethkit>the_tubular: I assume that it's due to it being quite new?
<the_tubular>Yes, guix-home is very recent