IRC channel logs


back to list of logs

<maximed>apteryx: interesting, when reviewing I usually prefer the changes to be split :p
<apteryx>sneek later tell maximed re about splitting same-package changes; there's a balance to be striken, and it can be subjective, yes :-)
<sneek>Will do.
<kitty1>yoyoyo, hows it going?
<atka>hi guix
<atka>when doing a manual install and providing your config.scm, do you specify somewhere to enable substitutes like with the installer?
<apteryx> at least (from the 1.3.0 installer) will be enabled automatically out-of-the-box
***alMalsamo is now known as lumberjack123
<atka>apteryx: thanks, it is pulling substitutes with no manual setup needed
<brendyn>In GNOME, what is it that makes pulseaudio immortal? killing it causes it to return instantly, but it's not a child process of anything. not sure how to track down what makes it restart
<podiki[m]>probably dbus
<podiki[m]>(just a guess)
<brendyn>thing is with guix is its you cant truly uninstall software without totally purging it from the dependency tree and building everything from source again
<brendyn>the funny thing is i totally removed the alsa service and pulseaudio service and yet pulseaudio still runs and successfully plays audio
<apteryx>brendyn: the default setup causes alsa to use pulseaudio, and pulseaudio to autospawn
<brendyn>apteryx, i've removed alsa-service-type and pulseaudio-service-type. pulseaudio is started in userland, outside of guix's control
<apteryx>so I'd guess you'd want pulseaudio? #f for alsa-service-type, and (client-conf (list "autospawn=no")) in your pulseaudio-configuration
<apteryx>OK, then I don't know. It's probably still useful to have autospawn=no, because applications can talk over d-bus to have pulseaudio started
<brendyn>apteryx, I'm creating a pipewire service to totally remove pulseaudio. I think the way guix sets up pulseaudio by default will need to change
<brendyn>apteryx, How have you been lately?
<brendyn>it worked. now pipewire is working in a VM
<brendyn>jpoiret, -L only loads packages. I want to load service definitions too.
<brendyn>I think one way is to use guix pull --url=... to pull the git repo. but that requires waiting to build everything
<unmatched-paren>what would a 'sec2 ctor' be? at boot i get: 'nouveau: sec2 ctor failed (-2)'
<unmatched-paren>i've seen posts on various web forums where the poster had a similar (but not the same) message, and the problem was that they were missing non-free firmware...
<unmatched-paren>would that mean that my graphics card doesn't work with nouveau?
<unmatched-paren>...maybe i'd be better off asking on #nouveau
<jpoiret>brendyn: re pipewire. Are you able to run it system-wide? i think it'd need some modifications to be able to run that way
<brendyn>jpoiret, I don't think it is recommended to do that
<jpoiret>yes, i agree
<jpoiret>we'd deviate too much from upstream
<brendyn>i got it running
<jpoiret>and niceties like using xdg-desktop-portal wouldn't work
<jpoiret>otherwise, running pipewire + wireplumber manually in a session works ok for me
<jpoiret>replaces pulseaudio out of the box and lets me do screensharing on wlroots compositors
<brendyn>did you also need to run pipewire-pulse?
<brendyn>In my vm, the pulseaudio config did not show any output devices
<brendyn>so i could not adjust volume
<jpoiret>yes, for pulseaudio replacement you need to run pipewire-pulse as well
<brendyn>i don't really understand what wireplumber actually does technically. audio didn't work until i ran wireplumber, but im not sure what it actually did
<jpoiret>basically, it's what is responsible for actually wiring things together
<jpoiret>applications can tag their own pipewire things (i can't recall the proper name) with what they'd like them to be wired to
<jpoiret>the doc is unfortunately obscure, but most of the wireplumber code is lua so not too unreadable
<brendyn>this is basically what my system-side config is
<brendyn>plus im using guix from git with some updates to pipewire
<brendyn>I would like to try switching guix to pipewire. the hard bit is figuring out pipewire/pipewire-pulse/wireplumber should be started by the user for all the different desktops etc
<jpoiret>brendyn: i agree
<jpoiret>the ideal thing would be to let it be managed by a user shepherd, with guix home
<brendyn>that is what this person has
<jpoiret>by the way, #~#$ is pretty unreadable, i'd suggest (file-append (pipewire-configuration-pipewire config) "/share/alsa/alsa.conf.d/50-pipewire.conf") ">\n" instead
<jpoiret>mixed-text-file already ungexps its arguments
<brendyn>i kinda hate file-append because to me it sounds like its going to append data to a file
<jpoiret>eh, right. But still, it's exactly what it's used for
<brendyn>i would probably use it when submitting a patchset
<brendyn>or i use #~(string-append #$foo "/bar")
<brendyn>currently, one has to delete their alsa service and pulseaudio service manually to add this pipewire service. is there a better way?
<jpoiret>no, that's expected
<jpoiret>i don't think a service deleting other services that are supposed to be there would be helpful
<brendyn>because my pipewire service includes some pulseaudio config
<jpoiret>notice that pulseaudio is not started by shepherd but rather on-demand through dbus, so you can just `pulseaudio -k` and `pipewire-pulse`
<jpoiret>or, you could even start it early before pulseaudio has a chance to get autostarted
<brendyn>it was necessary to set autospawn=no
<jpoiret>i've been able to run pipewire-pulse with the above, but maybe you had an application with audio playing at that moment, or something similar, that could've asked for pa to start again
<brendyn>i found in GNOME it restarted instantly every time
<jpoiret>ah, that may be why. I use sway
<brendyn>volume works in GNOME after including pipewire.conf
<bovid-19>hi guix!
<ekaitz>hi bovid-19
<bovid-19>I tried to use a snippet from, but it gives me this error: "comma-separated: unbound variable". I just went back to my old way to configure it, but if someone knows what I'm missing, I'm all eyes.
<jpoiret>bovid-19: i'd bet it's in (al utils)
<jpoiret>but i can't find the source for it
<jpoiret>tbh, it's just (string-join thelist ",")
<jlicht>hey guix!
<bovid-19>hi jlicht!
<lumberjack123>Are there any Electron apps in Guix?
<bovid-19>jpoiret: thank you! I thought it would be in (al utils) or one of the other custom modules, too, but grepping through the repository didn't find it.
<jlicht>lumberjack123: No, not now nor in the near future; cleanly building Electron itself is already challening (but possible); the web of JS dependencies around that makes it kind of a non-starter to meet the bar for inclusion in Guix
<lumberjack123>jlicht: Yes I just used yarn for my first time and it downloaded over 800MiB of modules!! I am flabbergasted...
<lumberjack123>But I do not see why JS code is a big deal, as long as V8 binary in Node.js is safely/reproducably compiled with g++
<lumberjack123>There is an Electron app I really want on Guix
<bovid-19>lumberjack123: maybe install it through nix?
<lumberjack123>Also I think there is shim code that g++ needs to compile for at least SQLite support
<lumberjack123>bovid-19: huh I never considered intalling nix on guix that seems odd... probably needs seperate nix-daemon C++ binary or what?
<bovid-19>There's a nix service
<jlicht>for Guix System, we even have a nix-service
<jlicht>I was too slow :)
<bovid-19>Your text was too long ;)
<bovid-19>And too correct
<lumberjack123>bovid-19: Yeah I foudn that via Searx thanks also there is guix on nix: but it looks configured for substitutes only which is lame
<lumberjack123>OKay what is so special about Nix that it can compile/package Electron app but Guix cannot?
<singpolyma>lumberjack123: less focus on builds from super pure sources, likely
<pinoaffe>lumberjack123: probably that they're less strict about licensing and building everything from source
<pinoaffe>you can do the same using guix, but those kinds of packages probably won't be accepted as "official" guix packages, whereas they might be accepted in the case of nix
<lumberjack123>As for license the app in question is GNU GPLv3 and Node.js is MIT license and V8 is 3-clause BSD, also SQLite is public domain... I do not know what the license all of the modules yarn downloaded were, is this the issue?
<bovid-19>Nix includes packages that just download official binaries. For guix, you'd have to have source packages for each item in the dependency tree.
<lumberjack123>bovid-19: Ohhh hmm so in nix they do not compile V8 from source or something for Electron apps or what else do they not compile?
<lumberjack123>I don't see why the dependencies for Electron apps cannot be built from source on Guix as long as license of modules is libre
<singpolyma>lumberjack123: they can be. It's just a lot of work and no one has
<singpolyma>The chromium source tree is a bit insane, but obviously there is a way to build it right, just not a one day kind of task
<jlicht>I think it's mostly the npm packages here that are problematic; it's no fun trying to build it all from sources, so Nix throws their hands up and just downloads the 'binaries' from the npm registry
<jlicht>last I checked, at least
<unmatched-paren>hello again guix :)
<unmatched-paren>i can't figure out how to package a kakoune plugin
<unmatched-paren>(yeah, i really should settle on one text editor :P)
<singpolyma>npm modules seem much less hard to me than chromium. I've done hundreds of npm modules it's just time consuming. Not full automatable I think
<unmatched-paren>i'm using the copy-build-system to install every .kak file to $out/share/kak/autoload, but it doesn't appear to be working
<singpolyma>unmatched-paren: does kak load from a search path that your env has set?
<jlicht>singpolyma: than you've had the good fortune of not yet reaching a package that depends on Gulp, Grunt and the like :)
<singpolyma>jlicht: I packaged gulp and grunt
<unmatched-paren>singpolyma: i'm not sure, i'll have a look in The Sauce
<singpolyma>Still need to do some gulp plugins that I need
<singpolyma>Need to do mocha soon so can start running tests on more packages
<unmatched-paren>it appears to use KAKOUNE_CONFIG_DIR
<raghavgururajan>IIUC, bordeaux is still down right?
<unmatched-paren>(from src/
<raghavgururajan>for substitutes I mean
<unmatched-paren>singpolyma: would the kak package need to specify that as a search path? (i've never used the search path feature)
<singpolyma>unmatched-paren: yes, if the plugins are meant to be installed to a profile alongside kak by the user, and then kak magically find them, that is the One Good Use for search path
<unmatched-paren>the kakoune package does not currently specify any search paths :( i guess i'll send a patch
<jlicht>singpolyma: do you have this work available online somewhere? I'm really interested!
<singpolyma>jlicht: it's in guixrus
<jlicht>singpolyma: mad props, the NODE_MODULES workaround typescript is quite elegant
<jlicht>s/typescript/for typescript
<unmatched-paren>interesting... the vim package doesn't specify one either
<bovid-19>singpolyma: this one: ?
<singpolyma>bovid-19: yes
<SeerLite[m]>unmatched-paren: I sent a patch to add search paths to Vim a few days ago but I have to fix some stuff and haven't gotten around to it
<unmatched-paren>this is correct, right, singpolyma?
<unmatched-paren>for some reason it still isn't working
<singpolyma>I think you want search path not native search path
<unmatched-paren>hm, k. i based it off the emacs package, which uses native-search-path
<singpolyma>I am not an expert on that specifically
<singpolyma>If you install the package and install kak in the same profile and reload the profile do you get the env var?
<unmatched-paren>wdym reload the profile?
<unmatched-paren>(the plugin package is already installed, btw)
<singpolyma>unmatched-paren: new env var you'll have to re-source the profile
<unmatched-paren>...oh, i haven't been doing that :P
<unmatched-paren>problem solved probably
<unmatched-paren>singpolyma: i tried installing both, logging out, and logging back in, but kak still refuses to find the plugin
<unmatched-paren>... i could just copy the auto-pairs.kak file into my ~/.config/kak and source it, but that would be cheating :)
<unmatched-paren> <- this uses native-search-paths, so maybe i should have kept it using that?
<unmatched-paren>aha! it works!
<unmatched-paren>well, it worked when i manually sourced, but as soon as i put `source $GUIX_PROFILE/etc/profile` in my bash_profile, logged out, and logged back in again, it stopped working...
<unmatched-paren>in trying to reproduce the 'consider setting the necessary environment variables' message, i stumbled upon: "emacs-minimal-27.2 35.2MiB" heh, minimal indeed
<unmatched-paren>ah, i think i need to do guix package --search-paths -p $GUIX_PROFILE | source
<unmatched-paren>okay, plan B: give up :)
<unmatched-paren>kak only seems to support 1 config path
<unmatched-paren>so i can't set it to both $HOME/.config/kak and the guix paths
<SeerLite[m]>unmatched-paren: You could do it like we're doing with Vim does and have a default config file that sources everything in the env var
<SeerLite[m]>Oh wait, kak doesn't source something like /etc/kakrc by default before sourcing .config/kak?
<SeerLite[m]>Ok nvm I can't think of how to do it
<unmatched-paren>SeerLite[m]: it *does* install a /share/kak/kakrc; thanks for the idea!
<unmatched-paren>so i guess i'd do something like `source %sh{ echo $GUIX_KAKOUNE_CONFIG_DIR | sed "s/:/ /g" }` to split `/foo/bar:/baz/quux` into `/foo/bar /baz/quux`...
<the_tubular>Plan C : emacs :)
<unmatched-paren>i used to use emacs but i prefer vi and co
<unmatched-paren>s/vi and co/vi and co./
<excalamus>hi Guix!
***Xenguy_ is now known as Xenguy
<nckx>Hi excalamus!
***jonsger1 is now known as jonsger
<sneek>Welcome back civodul, you have 2 messages!
<sneek>civodul, nckx says: No objections from me! Happy hurding.
<sneek>civodul, apteryx says: OK for me too; as long as you don't need to reconfigure berlin itself, it should be fine
<civodul>apteryx, nckx: i deployed the build nodes, but unfortunately their childhurd service still fails to start
<civodul>either it's a timing issue or the new "childhurd" service wasn't reloaded
<chaos1>Hi I'm trying to debug something with the openjfx package defined in guix/gnu/packages/java.scm, but I am not sure what are the right steps to do so.
<chaos1>The source code lives in mercurial under teh 8u202-ga tag, and is used to build the java-openjfx-build, java-openjfx-base, java-openjfx-graphics and java-openjfx-media packages
<chaos1>I would like to change a single line in the source code and rebuild the packages; so what I have done is to clone the openjfx project from the mercurial server to my localhost, and export the source code into a local directory, so that the source code is available on my pc
<chaos1>I then modified the source line i was interested in the local source code copy
<chaos1>Then, i switched into a guix environment with `guix environment guix --pure`, and rebuild the package with `./pre-inst-env guix build java-openjfx-graphics --with-sourcejava-openjfx-graphics@8.203=<path-to-the-modified-source-code>`
<chaos1>this has created the new version of the package as expected
<chaos1>though (as perhaps is expected) this package is not available from my normal guix profile, i.e. `guix search java-openjfx-graphics` will not list it
<chaos1>How do I make  a local dev build accessible to my normal guix environment?
***starchild is now known as alid
<raghavgururajan>chaos1: If you have a self-built binary, you can add the path of that binary to $PATH environment vairable; and start the program from terminal. It cannot be managed with guix as it isn't part of guix distribution.
<raghavgururajan>chaos1: Oh wait! You modified a package in the distribution and built it. Okay. Instead of `guix search`, do `./pre-inst-env guix search`.
<chaos1>I see thanks, both suggestions make sense, let me try them out
<raghavgururajan>You could also do, `./pre-inst-env guix environment --pure --ad-hoc package-name -- program-name`
<chaos1>thanks, my use case is so simple that the first suggestion did the trick (explicitly specifying the path tot he new package)
<chaos1>I have another question, this is independent of the above, no code was modified or new packages are created here
<chaos1>When I install the above libraries with a normal `guix install java-openjfx-graphics` say, the jar is installed as expected at ~/.guix-profile/share/java/java-openfx-graphics.jar as a symlink pointing to the corresponding /gnu/store path, but it is not available in the class path
<chaos1>e.g. I was expecting that the library can be found with javac say when I import it in the source file
<chaos1>but this is not the case, I have to explicitly mention the above path in the classpath
<chaos1>Is this expected behaviour? I would have expected that any java library I install with guix should be made available in the classpath
<dansa>Hi. I'm looking forward to buy a new computer for installing the GNU Guix. Is there a website somewhere that I can sort of just buy a computer that is fully supported by GNU Guix? (Or must I somehow build it myself or build a particular configuration for a company that builds and sells computers to sell me one?)
<dansa>In other words, I'm trying to play the role of the total-beginner who doesn't want to discover that a certain piece of hardware isn't supported. I'm looking for off-the-shelf, plug-n-play stuff.
<dansa>I'm already aware of catalogs of supported hardware, but this still leaves me with the job of either buying all parts and assembling it or building a shopping a card in some vendor. I'd love a one-click-buy to solve this problem. And it does like we all would have the interest in perhaps building a website that sort of keeps such information up to date.
<unmatched-paren>dansa: there are several at, and also; note that all the laptops on both sites are refurbished old ones except for the incredibly expensive Talos II, which is PowerPC so guix system won't work on it yet anyway
<unmatched-paren>i'm using a typical consumer laptop quite happily, though; the only thing i needed was a wifi dongle from
<pinoaffe>dansa: are you in the market for a laptop or a desktop?
<unmatched-paren>my 'typical consumer laptop' still has evil bios, but it otherwise is completely free
<pinoaffe>On a consumer laptop, afaik the only things that typically may cause issues are the wireless connectivity cards (anything from wifi, nfc, bluetooth, etc) and the graphics card
<pinoaffe>I personally use a lenovo t470, the wifi card it comes with OOTB is not supported in guix but I was able to buy a compatible wifi card with fully open source drivers that is supported in guix
<ternary>I need some help packaging squeekboard. It builds with meson, but meson calls cargo to build the rust portion of it. My original plan was to use the meson build system and insert the cargo configure phase, but now I've realized that the cargo dependencies are provided through the cargo-inputs argument, which meson obviously doesn't use, and now I don't know what to do
***jonsger1 is now known as jonsger
<unmatched-paren>i'm afraid i can't offer anything but sympathy :/
<unmatched-paren>'modern' build systems can be pretty questionable...
<ternary>I'm worried that my best option is going to be to just copy and paste the entire cargo configure phase so I can pass it all the necessary dependencies
<unmatched-paren>it works! i'm now able to correctly load a kak plugin from guix :)
<unmatched-paren>i inserted a for loop into the default kakrc that loads each directory in $GUIX_KAKOUNE_CONFIG_DIRS
<f1refly>when my system crashes, what log do I turn to on guix to figure out what happened?
<unmatched-paren>kernel panic? or something else?
<unmatched-paren>what exactly crashed? do you know?
<f1refly>I have no idea, my laptop suddenly rebooted
<f1refly>it happened the second time already
<f1refly>otherwise i'd just say it's probably a random hardware failure or something
<f1refly>the first time there was suddenly whitenoise playing for a split second, indicating that either the hardware is going bonkers or something overrode pulseaudios buffer
<f1refly>(from my understanding of how this could've happened)
<tooblu>trying to install a subset of glibc-locales, the new instructions provide an example bit of code for Canadian utf8 locales. I think I can adapt that for my purposes. What do I do with that bit of code after I've edited it? I tried putting it in a file, glibc-my-utf8-locales.scm, and running "guix package
<tooblu>--install-from-file=glibc-my-utf8-locales.scm", but that failed with: "guix package: error: cannot install non-package object: #<unspecified>"
<tooblu>here is the new locales instructions:
<kaelyn>@tooblu the error is because that example defines a variable containing the package, and "--install-from-file" expects the file to return a package object. The simple fix is to add "my-glibc-locales" (without quotes) on a new line at the bottom of glibc-my-utf8-locales.scm
<kaelyn>(to explain better: the return value of the last top-level expression to be evaluated in the file is used as the package. "(define some-var ...)" does not return anything, while just "some-var" returns the value of "some-var")
<tooblu>Kaelyn, thank you! That seems to have worked. I appreciate the reasons for removing glibc-utf8-locales, but the new instructions for not having to install the entire glibc-locales, which seem to be targeted at people like me, not-a-package-developer-just-want-to-install-guix-and-some-packages, seem to assume the new-to-guix person installing Guix
<tooblu>has Guix packaging experience.
<kaelyn>you're welcome!
<jlicht>finally found out why Guix System was so terribly slow on my new laptop; turns out there is a bug in my proprietary bios. Who'd thunk it? Either way, running thermald with --adaptive seems to get my CPU to clock a bit faster than 400MHz, which it was normally stuck at
<nckx>jlicht: I got a similar bug free with (and only with) Coreboot, so it's not all libre unicorns & rainbows. Alas.
<nckx>Machine clocks down to 1.2 GHz after a random uptime, and nothing but a reboot will fix it.
<nckx>jlicht: ‘A bit’ as in it should go higher?
<jlicht>nckx: 3.0 GHz; I still might be able to squeeze out a bit more single core performance in bursts /w 'TurboBoost', but at least things are usable.
<nckx>That seems about reasonable for ’sustained performance’.
<unmatched-paren>conclusion: 'firmware is hard'
<nckx>That's why they call it—meh.
<jlicht>I'm just happy the solution is not 'buy new laptop' :)
<atka>when installing guix to luks + btrfs are there any btrfs subvolumes that need to be present to boot? on other distros I usually just have a root "/" and home "/home" subvolume and don't mount the toplevel except for maintenance. is it required or recommended to have a "gnu" subvolume as well?
<nckx>I'll try the same command (though I'm not hopeful — Linux report's the CPU's unrestricted, it just refuses to live).
<jlicht>`thermald --no-daemon --adaptive' as root did the trick for me
<jlicht>What use is an `@acronym{...}'-wrapped acronym, if the fully written out form is not given in our texinfo manual?
<nckx>Which is separate from, yes, please, expand them wherever it makes sense ☺
<unmatched-paren>could somebody please review <>? it's a tiny change so it should be trivial to test
<jlicht>unmatched-paren; not having used kakoune (nor having a working pc), why would you not want there to be one directory to autoload *.kak files from? AFAIK, this is what will happen in a profile or environment
<unmatched-paren>jlicht: if you support multiple directories, you'd be able to install kak plugins on both the system and user profiles, right?
<unmatched-paren>it's unlikely that someone would want that, but it'd still be a bug if it doesn't support that
<unmatched-paren>why does vim depend on tcsh???
<jlicht>unmatched-paren: I'll take your word for it; I was just looking at how nix does this, and they seem to just do some symlink magic to make it work
<unmatched-paren>guix has its own search-path feature for exactly that kind of thing; i'm not sure if nix has something similar?
<jlicht>It's the substitute* parts that make me wonder if there's a more elegant way to achieve the same goal
<unmatched-paren>jlicht: the more elegant way would be a patch, but i'm lazy :)
<unmatched-paren>i know it's probably silly to ask this in a channel dominated by emacs users, but is there a good terminal (non-emacs) email client in guix? i tried packaging aerc but failed because golang
<Ribby>Just an opinion, I think that guix should have mfs.vfat, mkfs.exfat, fsck, parted, mklabel msdos, mklabel gpt, and mkpart. It might not be a customer retention strategy, but the ability to make OS copies/backups can be a selling point bonus. I am not sure if there's a 64 bit requirement, but it shouldn't be the case.
<unmatched-paren>do you mean in the base installation?
<Ribby>Will/may much appreciate to know. Yes.
<Aurora_v_kosmose>The manual still doesn't mention that the label tuples are optional now and can simply be package variables.
<unmatched-paren>Aurora_v_kosmose: won't it be in the devel manual
<Aurora_v_kosmose>unmatched-paren: It's still considered a dev/unstable change?
<jlicht>Aurora_v_kosmose; guix has a rolling release; every so often, a release is cut from current master, but these releases in general are meaningless
<Aurora_v_kosmose>unmatched-paren: Oh, looks like you're right.
<unmatched-paren>i've been told that you should _always_ look in the devel manual, because the release manual covers the release
<unmatched-paren>i still have no idea why the release manual even exists
<Aurora_v_kosmose>unmatched-paren: I'll definitely keep that in mind for the future.
<unmatched-paren>we should delete it tbh
<unmatched-paren>it only causes confusion like this...
<jlicht>the release manual has relevant sections for installing guix from a release tarball
<unmatched-paren>fair enough
<unmatched-paren>maybe we could split out the installation into a different manual
<nckx>Ribby: In the installer? I think most of those are already present. Not sure about parted.
<nckx>I've never used parted. It's a pretty unpleasant programme.
<Ribby>I tried flatpak for 32 bit, but it seems to be lacking in the compatibility department. Maybe they given up on the effort?
<Ribby>Okay, is there an alternative to parted?
<apteryx>I use parted, it's fine; others may prefer cfdisk or something else
<Ribby>I know that fdisk have bold labels.
<nckx>If the installer doesn't have parted installed, it should be a zero-byte change, since the GUI installer uses it already. If you'd want to submit a bug.
<Ribby>As long extra things are in the system server, it should suffice.
<Ribby>Different topic, anyone tried QubesOS before? Man, that virtualization emulation/compilation hub of virtual OS branches is just splitting hairs.
<Ribby>I only managed to get the net to work on the system updates. All other emulated OS have no go in terms of browser connection with internet service.
<Ribby>Probably suffering from a lack of driver support in terms of virtual OS.
<Aurora_v_kosmose>Ribby: I have and use it.
<Aurora_v_kosmose>Ribby: You sys-net qube needs whatever drivers are required to have networking with the hardware.
<Aurora_v_kosmose>That's typically an issue with wifi.
<Ribby>Well, as far as I know, the Mozilla Firefox doesn't seem to register, with either ethernet or wifi.
<Ribby>Maybe, it's a system update/upgrade thing. I should consult with the QubesOS team.
<Aurora_v_kosmose>Ribby: That's the application as it opens in the GuiVM/dom0 display, but it is running inside a qube, which itself relies on vchan-communication for networking with other qubes.
<Aurora_v_kosmose>So the earliest qube in the chain, the sys-net, not having appropriate drivers means no qube has networking.
<Aurora_v_kosmose>You can typically check by opening a terminal in sys-net and trying to ping anything.
<Ribby>Is driver support a problem for qubesos?
<Aurora_v_kosmose>Ribby: Not particularly more than it is for the distros running in its qubes.
<Aurora_v_kosmose>Debian typically doesn't include wifi drivers.
<unmatched-paren>does qubes run a distro for each application, then? i've never really looked into it
<Aurora_v_kosmose>Fedora includes more of them by default. So you might have to switch the sys-net to a fedora template just in order to download the drivers package to install in a Debian template you'd then use for the sys-net qube.
<Aurora_v_kosmose>unmatched-paren: Not necessarily. You can use it that way but typically due to resource constraints you separate qubes by security domain.
<Aurora_v_kosmose>So you'd have say... Emacs and Firefox in your work qube, and Emacs from another qube also running.
<Aurora_v_kosmose>Let's say "personal-guix"
<unmatched-paren>ah. i was going to ask about the performance implications of that...
<Ribby>Well, seeing that there's a fedora app store, it is quite obvious who qubesos is rooting for. It's no biggie, not a problem, nothing personal. :'(
<Ribby>I was about to rave and rant about Fedora not being GNU/Linux, but it is probably unnecessary.
<unmatched-paren>but fedora is gnu/linux... it runs a linux kernel with a gnu userspace. how would it not be gnu/linux?