<Aurora_v_kosmose>lle-bout[m]: I was asking if you were already working on that Qubes equivalent, and some more info on your idea/work if it was so.
<lle-bout[m]>Aurora_v_kosmose: Work hasnt begun, I said I was thinking about it, but the idea is pretty simple, right now Qubes OS is a set of packages on top of Fedora, we would just have to make that a set of GNU Guix packages instead, then write shepherd services, etc.
<lle-bout[m]>One disappointment with Qubes OS for many is that it doesnt appear to be designed to be used in any other form than the Qubes OS distribution, I actually think it may not be that hard to take it out and use it elsewhere.
<lle-bout[m]>Aurora_v_kosmose: GNU Guix System is configured using Scheme, so there's no limitation in what you can do with it. What do you mean by portable? GNU Guix can compile and assemble the same software used by Qubes OS.
<lle-bout[m]>The finalized work will be a GNU Guix System configuration you can use (but also some packages upstreamed probably to make that shorter)
<lle-bout[m]>There's no limitation in what you can do with GNU Guix, all in all I think GNU Guix is probably a better package manager to base Qubes OS on than Fedora and dnf. In that it provides much more clean tooling to assemble systems and maintain them in a rather minimal way.
<Aurora_v_kosmose>It's certainly a better idea considering the way RedHat is going anyway.
<lle-bout[m]>GNU Guix needs more security auditing also, GNU Guile, GNU Shepherd and auditing of all services present in GNU Guix, that's plenty of probably (mostly) unexplored area w.r.t. finding vulnerabilities, and more people to do the day-to-day CVE patching process, I have hope this is coming together
<pkill9>runtime security would go well with the security of being able to track the graph of all the software
<Frosku>I've installed xdg-desktop-portal and xdg-desktop-portal-gtk but Flatpak is still complaining: Failed to call portal: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface ?org.freedesktop.portal.OpenURI? on object at path /org/freedesktop/portal/desktop -- any ideas?
<schmools>a beginner to guix so there might be a simple answer to this, but for some reason my guix install won't login with anything but the root account. my password wont get rejected it will just restart the login manager - happens in the terminal too so I don't think its a GDM thing...
<roptat>Frosku, majority of people here are sleeping now, so if you don't get an answer now, you can always ask on the mailing list, there might be more people who can answer: email@example.com
<Frosku>Whats your shell set as in /etc/passwd? Sounds like a shell issue
<roptat>I've never used flatpak, so I have no idea
<Aurora_v_kosmose>There was also that issue a while back with something missing from the default system configuration.
<roptat>could be the shell crashing if you set something funny in .bashrc or something, don't know if it's very likely
<bdju>maybe I just need to be in an additional group if it's a permission problem
<bdju>won't let my run with sudo `beep: Error: Running as root under sudo, which is not supported for security reasons.` `beep: Error: Set up permissions for the pcspkr evdev device file and run as non-root user instead.`
<bdju>I'm using %base-services rather than %desktop-services btw
<rhou[m]>I'm developing software in guix and was wondering where to put my package definition? In the same repository where my code is and use this repository as a channel or do I create a separate repo for my private channel?
<cbaines>rhou[m], is submitting it to guix an option?
<lle-bout[m]>civodul, mothacehe : the machine OSUOSL provides has quite a slow disk but I could also provide a VM on my machine at home, where I have even PCIe Gen4 SSDs that go 5000MB/s w, and 7000MB/s r
<bonz060_>cbaines: A little late to thank you, but anyways, thanks for pointing out that a conflict could be caused by the Python-roman package being at the bottom of a module... So I'm guessing that I have to keep in mind the order of commits when I push upstream right?
<cbaines>bonz060_, it's not about the order of commits, just when adding new packages, generally avoid adding them at the bottom of modules (unless you specifically want it to be there)
<leoprikler>some modules are also explicitly ordered alphabetically, so that's that
<sneek>lle-bout, raghavgururajan says: It have sent patches to #47643. Could you specify the spots you were referring to regarding comments, via replies? I'll edit and resend that patch. Also, could you start a new branch 'wip-gnome' on savannah please? Thanks!
<lle-bout>cbaines: hey! it seems your GPG key 3E89EEE7458E720D9754E0B25E28A33B0B84F577 has expired! Did you somehow extend it's expiration and forget to upload to Savannah? I also get that for BCA689B636553801C3C62150197A5888235FACAC owned by rekado!
<cbaines>lle-bout, hmm, I see it expiring soon (2021-05-17), but that's not yet. I'll extend the expiry date now though...
<lle-bout>cbaines: pub rsa4096 2010-11-07 [SC] [expired: 2019-05-18] - I see this
<lle-bout>did you upload a latest public key export to Savannah?
<balance>Hello please help, how to prevent error "guix system: error: more than one target service of type 'udev'", after executing "sudo guix system reconfigure /etc/config.scm" seems that this mistake in next patr of config.scm "(services (append (list ...) %base-services %desktop-services))"
<balance>trying to install something like virtualbox, libre variant
<pkill9>what is that balance? there is already qemu plus it's frontends
<cbaines>all I know currently is there's something a bit off with some of the system test derivations that the Guix Data Service is recording, I haven't looked further in to what's going on yet, but I hope to at some point
<pkill9>I think that like openbsd, we should consider lack of documentation to be a bug
<ekaitz><pkill9> I think that like openbsd, we should consider lack of documentation to be a bug
<civodul>lle-bout: great that you put out a call for help with guidelines!
<civodul>though remember that recruiting is never easy
<PotentialUser-96>hi guys, need help with network issue, guix(1.1/1.2) will not connect to internet (while trying to install it), tried real-hardware, virtualbox, no luck, amy ideas?
<lle-bout>civodul: I understand, I hope some people will show up if we are more in numbers the task will be much much easier and less stressful, we also need a tool to collaborate on reviewing RSS feed entries with adding comments, tags etc. in an efficientand easy way.
<lle-bout>Because right now, everyone is bound to repeat reviewing work, we have no way of sharing which RSS feed entry we reviewed.
<lle-bout>I am afraid now I will have to be late again, I've been keeping up ever since I started my first security-related commit in GNU Guix but now it's kind of falling apart
<civodul>lle-bout: it's okay, don't consider that you or anyone has to keep up
<civodul>and take some time off occasionally too, otherwise we'll all get crazy :-)
<cbaines>I hope keeping up with updates and security updates will get better, but as you say, I think the thing to focus on is making that easier for volunteers to do the work
<civodul>i think lfam could speak about this better than i do when it comes to security issues
<lle-bout>civodul: I understand, I would like to prioritize, the lint color tool would really help that, also if we get a collaborative security tracker for GNU Guix we can probably also prioritize by severity
<lle-bout>I think it would be really great to prioritize by severity, it would really lower stress
<civodul>lle-bout: all system admin is under version control, no need to have an account on the actual machines
<mothacehe>63 minutes on core-updates, that's a long evaluation!
<civodul>mothacehe: this one is a full rebuild, so it's probably going to take longer
<civodul>lle-bout: but really, i don't think sysadmin is the bottleneck here since we don't have tools or services to deploy in the first place
<lle-bout>civodul: I understand, I'll take some time off now because it's stressful, also the GNOME upgrade now, I feel like we need help reviewing, there's already been people, I feel like I want to pause my contributions to GNU Guix now because I have plenty of other stuff to handle.
<lle-bout>civodul: We could deploy Debian security tracker software
<civodul>lle-bout: i don't know but yeah, i'd suggest not imposing too much stress on yourself, for sure
<lle-bout>I will come back soon, just need some pause
<lubrito>Hi everybody! I'm an Outreachy applicant. I'm having a little problem with the ./configure step of the setup tools instructions for the Guix Data Service project. I've got this error message: "./configure: line 2365: syntax error near unexpected token `3.0'
<lubrito>./configure: line 2365: `GUILE_PKG(3.0 2.2)' ". I would appreciate if anyone could help me.
<lubrito>I'm running Guix on a Debian 11 (testing).
<roptat>for multiple services, you can replace that example with something like this: (eq? (service-kind service) gdm-service-type)) becomes (member (service-kind service) (list a b c)) where a, b and c are the service types you want to remove
<Vongazi>roptat, yes thats how i removed gdm, but i also want to remove ntpd
<tissevert>hmmm if I understand correctly, native-search-paths allows one to declare a variable containing a search path for say a programming language in the package declaring said language, but how is the variable actually brought to the user's environment ?
<tissevert>I can't see the variable I'm tracking in /etc/environment
<roptat>only if you have the package that defines the variable in the same profile as packages that would be added to that variable
<roptat>for instance, if you have only guile-cairo in your profile, you won't get GUILE_LOAD_PATH, unless you also have guile which is the package that defines it
<Noisytoot>This document uses the gender-neutral third-person pronouns “person” (which can be shortened to “perse”), “per”, “pers” and “perself.” These pronouns (aside from “perse”) were promoted, and perhaps invented, by Marge Piercy in Woman on the Edge of Time. They are used just like “she”, “her”, “hers” and “herself”, except that they apply regardless of gender. For example, “Person placed per new program under
<Noisytoot> the GNU GPL, to maintain freedom for all users of per work, and this way perse knows perse has done the right thing.” "
<vagrantc>Noisytoot: and notably more controversial
<Noisytoot>vagrantc, Is perse/per more controversial or they/them?
<vagrantc>one is actually part of the english language, and one is a recent invention by someone who has questionable authority on grammar or linguistics
<vagrantc>and one is in widespread use, and the other, to my knowledge, is not
<roptat>but who has authority on grammar or linguistics? :)
<vagrantc>i'd generally trust linguists, or if you must, grammaticians
<Noisytoot>vagrantc, "perse", "person", "perself", "per", and "pers" are unambiguous, as they either do not have other meanings, or the other meanings make no sense in the same context
<vagrantc>Noisytoot: but they require actual incorporation into english, which seems to me a great source of potential confusion and ambiguity? "is that a typo? some technical jargon? is it a scheme function?"
<roptat>when you specify a dependency, they just take whichever version was already compiled and available on maven central
<roptat>they don't recompile your dependencies, so as a java developer, you don't see the circularity
<roptat>and we create circular dependencies only because we want to keep only one version of the package, but if you had multiple versions, it would be more like a spiral of dependencies, where you go back one version on each round
<roptat>maybe you want to start from the default config?
<roptat>Noisytoot, good catch, it's missing, you can write that documentation and send a patch to firstname.lastname@example.org :)
<guixy><dir prefix="xdg"> adds a directory relative to XDG_DATA_HOME. The system fonts.cfg includes <dir prefix="xdg">fonts</dir>. So if I have the fonts in $XDG_DATA_HOME/fonts it should find those fonts without forgetting about the system fonts.
<guixy>I've tested it. It works for what I want, but I don't think it will work for fonts spread across multiple profiles.
<guixy> $XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.
<sss2>i need more recent standard than default c++11
<terpri_>i was trying to test zathura which has a core package and separate plugin packages for rendering pdf/djvu/etc., but the core zathura package is looking in its own nonexistent plugins dir in the store (/gnu/store/.../lib/zathura) and hence not working at all. what should it be doing instead, looking in the corresponding directory in the relevant profile? or perhaps using a new environment variable since there's not
<terpri_>an obvious way to find its profile at runtime?
<roptat>you can add them to the #:make-flags or #:configure-flags
<roptat>terpri_, you need to install zathura and its plugin in the same profile, then guix will set the right environment variable for you
<roptat>you might need to load etc/profile from that profile in order to get the new variables in your environment (guix should warn you)
<terpri_>roptat, ah, thanks, that works, i was using new screen windows and forgot that those aren't login shells :) whoops
<guixy>Ok, this is weird. drracket has font problems when I launch it with ~/.local/share/fonts linked to the /share/fonts directory in my fonts profile. It doesn't have font problems without that link.
<lfam>There are also some Python package graphs that just don't run the tests, and skipped the bootstrap dance entirely
<lfam>Like, we wrote the base of the package graph of certbot that way. Certbot has always worked fine
<guixy>python-hy keeps breaking because a dependency fails its tests.
<lfam>If we combine this work with a way to propagate #:disallowed-references up the package graph, it would be "safe" to programatically skip tests for this purpose
<lfam>At least, it would be an improvement to what we do now, which is pretty ad-hoc and under the radar
<lfam>If someone else submitted the certbot patches now, I might let them through or ask for revisions, based on my mood. They don't really meet our packaging standards
<terpri_>sss2, someone may have a complete answer, but you can take a look at how %patch-path is defined in gnu/packages.scm. it looks like you can set/add a directory to the GUIX_PACKAGE_PATH env var and use patch paths relative to that dir
<terpri_>sss2, and it appears to look for patches relative to <channel-dir>/share/guile/site for channels but i'm not sure about that ('package-path-entries' appears to effectively add that dir to the load path, and hence patch search path, for channels, afaict)
<terpri_>sss2, since kcollectd looks like it's set up to be used either in the channel or standalone, i think you could move the patches to <repo>/share/guile/site and search-patches should work as written with the channel, and with GUIX_PACKAGE_PATH=<repo>/share/guile/site set if you're building it as a standalone file
<terpri_>i haven't used search-patches outside of the main guix repo, though, so i could easily be wrong
<terpri_>(and yeah, it does look a bit complicated; i'd assume search-patches would use a directory layout similar to the guix repo's by default, and it looks nontrivial to customize the path...)
<terpri_>i'm also just skimming the definitions :) so my suggestions might be wrong
<civodul>terpri_: you can also use (local-file "./foo.patch") instead of 'search-patches'
***m6locks_ is now known as m6locks
<zzappie>Hey guix, how can I see what went wrong in bult-derivation?