<charles``>sorry lfam, I was dealing with something else. I build the iso with `./pre-inst-env guix system image -t iso9660 /etc/config.scm` then when I boot up vm in boxes, I get grub then just black screen. ***charles`` is now known as charles`
***charles` is now known as charles
<marusich>Good morning to all of you across the pond. <avalenn>what is the use of the label string in inputs field ? <avalenn>the doc says "each tuple has a label for the input (a string) as its first element" but I don't find where it is used <leoprikler>avalenn: it's used to search for specific inputs in the phases (see any use of assoc-ref really) <avalenn>Ok. So the build system uses the label. <lle-bout>efraim: tor security update 4.5.7 just appeared in my feed, so two days late, interesting <i1l>> ERROR: can't resolve libraries to shared libraries: geoclue-2 <i1l>no way to remove geoclue from that? <rekado>the g-ir-scanner invocation fails to find the library that was just built. Perhaps it needs an environment variable to be set to find it. <i1l>remove geoclue from webkit <i1l>or deps, or any. i mean it is mostly use-less. "provides single knob to rule the all location access permissions" <i1l>btw, other than aarch64 (builds) are successfull. <sturm>hi folks, I'm the current maintainer of MediaGoblin (photo/audio/video sharing etc). We're making good progress on packaging for Guix, but I'd really enjoy having a buddy with stronger Guix-fu to collaborate with on this. It's a Python project and we're about 90% there with the main Python dependencies. Would anyone be interested? <lle-bout>sturm: hey, not much time today but yes! do you know about the 'guix import pypi -r <pkg>' command? <sturm>lle-bout: great! yes that command has been very useful so far <lle-bout>sturm: keep me in the loop by email at lle-bout AT zaclys DOT net - also open a GNU Guix bug and share progress and updated patches? If it exists already, what is bug id? <sturm>lle-bout: I'll keep you in the loop, thanks. Currently I'm working on patch 47210 <sturm>I don't think we have a "meta" bug for MediaGoblin - do you think that's a good idea? <lle-bout>sturm: yes! it helps people see the actual goal and find motivation? <sturm>lle-bout: ok, I'll create something <lle-bout>sturm: I usually submit a bug for the main package and the patchset also contains all deps as individual commits <sturm>lle-bout: ok thanks, the good news is that most of the dependencies are already in guix master as Chris did a lot of work on it a while back, I've been doing it incrementally and also because we're using fairly mature packages <sturm>lle-bout: just need python-soundfile and we should be able to run the test suite 100%. There are other dependencies for the celery media processing, but not essential to have a basic system <sturm>lle-bout: packaging MediaGoblin itself hasn't been done yet ***zimoun` is now known as zimoun
<leoprikler>Is it normal for Guix to repeatedly allocate very large blocks? <civodul>leoprikler: if it's reproducible, let's talk and see how we can grab useful debugging info <davexunit>is there a convenient way to wrap a guile executable or do I have to copypasta all the stuff from, say, the haunt recipe? <efraim>there is a wrap-script function somewhere <rekado>wrap-script will not work for Guile scripts, though. <rekado>it only works for scripts that use # as the comment character <rekado>it’s just a little less elegant in my opinion <davexunit>there's an old project of mine called srt2vtt that is packaged. there's an open bug that it doesn't work and it's because it doesn't wrap the executable. <rekado>it should get a build phase that runs wrap-program on the script then <efraim>openjpeg fails 8 tests on core-updates on aarch64 and powerpc32 <roptat>civodul, it is reproducible, it takes a huge amount of RAM right after checking authenticity <roptat>(if that's what large blocks means) <roptat>I'd love for guix to use less ram <roptat>there are two times where it suddenly takes 128MB (each time), then ram consumption continues to grow slowly <PurpleSym>Even a simple `guix environment --ad-hoc hello` allocates 200MB for me. And it doesn’t release that, because it does not exec() the spawned shell. <leoprikler>civodul: not sure how reproducible it is; I got the warning twice during authentication (it seems) and once after compress-documentation <leoprikler>davexunit: if you execute your guile program through the "exec guile" trick, you can use a substitute* with that as key <apteryx>marusich: by the way, about switching to gtk+ without librsvg on core-updates for some platforms, this will have the effect of gdk-pixbuf not being able to load scalable SVG graphics (often used for embedded icons in GTK+ applications); still better than no support, but something to keep in mind <davexunit>leoprikler: I don't think I'm aware of that trick? is there a package that uses it? <jackhill>do we know why our rust doesn't support some platforms compared with upstream rust? <davexunit>phases don't need to return #t/#f anymore, right? <rekado>davexunit: on the “master” branch it may still complain about the lack of #t at the end. <rekado>but on core-updates that’s gone for good <rekado>it’s great you’re back to hack a bit on Guix! <leoprikler>"#!/bin/sh\nexec guile" is used by a number of launchers, but I am so far the only one, who has abused that pattern for patching in environment variables <roptat>should we create a separate output for idle (it's part of python)? it's a programming environment ("Integrated Development and Learning Environment") that depends on tk, and tk has its own output too. It's not required to build anything, and a separate output could reduce python package by 5MB <roptat>or we could make it part of the tk output, as alpine does for instance <roptat>fedory has a separate package for it <cage_>hi! Sorry for the stupid question but i just installed guixsd in a VM, how can i enable sshd? <roptat>you'd have to reconfigure the system to add the ssh service <fnstudio>civodul: what an image, that's the coolest distro "cover" ever! <cage_>roptat, thak you! The manual talk about guile files to reconfigure the system but i can understand if i have to start from scratch or i have to modify some files already located on the system <roptat>cage_, if you're lucky the VM already has the file that corresponds to the current system <roptat>that would be in /run/current-system/configuration.scm <roptat>if it doesn't exist, you'll have to start from scratch :/ <roptat>gah, guix pull failed on armhf, because of a test failure in glib <roptat>would it work to guix pull --without-test=glib? <cage_>roptat, that file exists on my system! Thank you!! <roptat>actually it's a timeout, not even a failure <roptat>83/259 glib:glib / 1bit-mutex TIMEOUT 90.04 s <roptat>oh, I see we already increased the timeouts <roptat>so either there's an issue, or 90s is still not enough <roptat>PotentialUser-44, I think it's already fixed very recently, you should try again after "guix pull" <vagrantc>i don't know that i've submitted many typo fixes <vagrantc>in theory i don't bother till the first release candidate tarball, then i try packaging for debian and run lintian which complains about spelling and grammar issues... <vagrantc>but maybe i should test the make dist tarball process again ... it's always a rough road and i'm happy to let someone else do that :) <morgansmith>does anyone else get a backtrace when running `guix refresh jack`? <roptat>how do I run binfmt on a foreign distro? <roptat>optional dependencies that are missing at this stage, I don't think it's important <roptat>I've installed it, I see /proc/sys/fs/binfmt_misc, and I can run /gnu/store/lgk876wh2bxxglplbwyymkx3sqzcbnk9-guile-3.0.2/bin/guile directly (it's an arm binary, on an x86 system) <roptat>but during the build I get /gnu/store/lgk876wh2bxxglplbwyymkx3sqzcbnk9-guile-3.0.2/bin/guile: no such file or directory <roptat>does the daemon need some option? <vagrantc>huh. i always run sway with just "exec sway" from console ... but now i see a suggestion to use dbus-run-session ... wonder what that does *davexunit pushed working version of srt2vtt since apparently 1 person uses it ;) <dustyweb>where does make-kill-destructor come from in guix? <dustyweb>I don't see it anywhere by grepping through things <cage_>iguix system reconfigure fails with an error like: "cannot determine provenance of GUIX" <acrow>The build of recent golang protobuf packages is stumping me. go-google-golang-org-protobuf and go-github-com-golang-protobuf apparently call for each other to build but they are libraries and so, I don't think, there is anything to build. Yet, during the phase 'setup-go-environment' with these packages including each other I get the error "In procedure symlink: File exists" error. I am confused. <roptat>it looks like you're using guix from the system instead of a guix from a guix pull profile <cage_>rotty, yes i launched guix pull as the system suggested :) <roptat>so, how do you run reconfigure? as user? <roptat>so you need to run guix pull as the root user, make sure you have ~root/.config/guix/current/bin first in $PATH for root and run "hash guix" <roptat>that's because users have separate guix pull profiles <roptat>so root doesn't have the same guix as your user <roptat>so how does binfmt work on guix system, why is it different from a foreign distro? <balance>Hello! Does anyone have a ready /mnt/etc/config.scm file with fsf certified soft for desktop system? Or where to download it? <leoprikler>I think until recently there was some special workaround to put Guix support into those containers. <davexunit>anyone have recommendations for an easily self-hostable git service? I use gitolite + cgit at the moment but I really need a bug tracker. I looked into gitea but it uses node so there's no way I'll be able to package that for guix. <civodul>roptat: binfmt support should Just Work; how does it not work for you? <civodul>davexunit: i think there's no bug tracker or fancy forge-like service in Guix <roptat>while setting up the build environment: executing `/gnu/store/lgk876wh2bxxglplbwyymkx3sqzcbnk9-guile-3.0.2/bin/guile': No such file or directory <roptat>civodul, this guile is an armhf guile, and I can run it ouside the guix environment <civodul>roptat: can you execute that file in a shell? <davexunit>civodul: I didn't think there was, but I was wondering if anyone knew of anything simple enough that I *could* package? <davexunit>I found a channel that provides gitea, but it just uses a tarball that has all the node/go deps bundled in <civodul>davexunit: ah! sr.ht looks like the friendliest among all the all-in-one tools <acrow>I thought that this is what propagated-inputs was intended to address, allowing multiple library packages to peacefully coexist. <civodul>roptat: did you (guix-support? #t) if you're using a Guix revision that still has it? *davexunit falls down a well <roptat>civodul, no it's on a foreign distro <roptat>I'm cheating a bit, the index.html is not part of gitile :p <civodul>roptat: then you need to pass --chroot-directory flags so that the binaries that appear in /proc/.../binfmt are visible inside the chroot <civodul>if you have to add /usr, you kinda lose <roptat>civodul, mh.. I think I'll loose ^^' <davexunit>so with a repo viewer, what's missing is access control management and a bug tracker <roptat>davexunit, I'd like to have that bug tracker at some point :) <davexunit>roptat: you have any plans/prototypes or just a wish at this point? <roptat>davexunit, I have a .sql file with some tables, that's all <roptat>to be honest, I'm not sure I really need a guile thing for that <civodul>it could keep you busy for the decade to come :-) <civodul>but... i like the spirit, davexunit :-) <davexunit>something easily self-hostable and not ancient/clunky so that I don't have to ask people to send patches to my personal email would be nice <civodul>as a yak-shaving-oriented project, Guix could be a user <davexunit>and I really don't want to move to someone else's service, especially not the big ones <davexunit>I don't think I could make a bug tracker good enough for guix. I need to set my sights way lower for the time being. <echosa>Hello all! My `guix pull` has been failing for a couple of days. Should I call it with --fallback, and if I do will it always compile for all future updates as well? Here's a paste of the error I'm getting. https://paste.debian.net/hidden/d20d0307/ <davexunit>I just need to thread comments/patches from users, track status, and display it all in a web browser. <roptat>echosa, the bad response line is just a network issue, you can retry multiple times if needed <echosa>@roptat I've retried several times yesterday and today. <roptat>make sure to use --commit=... so you retry the same guix commit each time, otherwise it starts over with newer files <echosa>I've never used --commit. How do I know what hash value to pass in? <roptat>from your error message, it says "1ab03fb74505458e7754dce338a5da29dc754d80" <roptat>civodul, had to pass /usr, /lib and /lib64, I don't feel very confident about that ^^' <echosa>Still getting the error, though not always in the same place. It's during different substitutions, each run, it seems, which definitely points to network issue. I just don't understand why it is suddenly consistently failing since yesterday or the day before. <echosa>I just did `guix gc` and `hash guix` to try to start from a "clean" state, and am now running `guix pull` again to see if that changes anything. <roptat>I don't think it'll change anything <roptat>if anything, guix gc has removed the parts you've already downloaded, so guix has to start again, so it's more likely you hit the error <cage_>roptat, it is working, thanks again! <echosa>This one doesn't seem to have a commit hash like the last error message did. <roptat>echosa, that's even before the step you were failing at before <roptat>that one is independent from the guix you pull, so you can retry <roptat>but it's really bad you have to experience that... <roptat>I know there are some reports, but I thought it was fixed <echosa>Right, ok, I ran guix pull again and I get an error closer to the first one again (with the same hash in the error output) but after "@ substituter-started /gnu/store/hwcky7446s952w0mwchhmm211ll07zrq-glibc-utf8-locales-2.31 substitute" instead this time. <roptat>the substituter is trying to download multiple substitutes if they're not in /gnu/store yet <roptat>so everytime you retry, it'll have more and more substitutes and fail on a different one (hopefully) <roptat>at some point it'll have everything and guix will be updated <echosa>:-/ Hm. Indeed. Also, not sure if it matters, but just today I'm noticing that sometimes I get this output near the beginning of a `guix pull` command. Is there any useful information here or can I safely ignore this? https://paste.debian.net/hidden/08d913ec/ <ngz>I experienced this recently. <ngz>(the Bad Response thing) <roptat>it's just missing optional dependencies that are not available yet at this stage <echosa>Ok. I'm just going to keep running "guix pull --commit=1ab03fb74505458e7754dce338a5da29dc754d80" over and over again for a while, then, and see if it ever makes it through. <echosa>Took five or so back-to-back runs, but it finally managed to finish. <echosa>Ah, but still getting bad response errors when running `guix update` after the pull finished. :-/ <echosa>Oh, cool. Definitely glad it's not just me. :-) Thanks for that. <davexunit>the guix debbugs web frontend is really slick <echosa>Brute-forcing got me through `guix upgrade` as well. Thanks roptat! <civodul>davexunit: yup, it's really pleasant <civodul>what would be doable and nice is to write a service for Debbugs <civodul>(because we still need the Perl Debbugs thingie behind) <roptat>I don't understand which packages are built during guix pull <roptat>package versions from the guix I currently have, or package versions from the guix I'm pulling? <echosa>Added my experience to that tracked issue. Thanks again! <roptat>looks like qemu is faster than real hardware <leoprikler>well, that obviously depends on the hardware, but there are cases in which this could be true <roptat>yeah, it gives a sense of how slow my real hardware can be ^^ <roptat>mh... interestingly, the test that timedout does not timeout anymore with qemu, it runs in 20s instead of timing out after 90s <roptat>but I have 3 more tests that did not time out on real hardware, and now time out <pkill9>did anyone get guix running on BSD? <leoprikler>If they did, you'd probably see a patch in the ML ;) <roptat>I don't understand where that glib comes from <roptat>there's no .drv file in the store with its hash in its content (grep returns nothing) <roptat>yet, it's being built by guix pull <leoprikler>I assume it's somehow related to the documentation, but I can't pinpoint it exactly <leoprikler>it seems to be pulled pretty close to texlive IIRC <roptat>but how come there's no referrer? I can't even get a graph to understand where it comes from, let alone which version of guix it is, and which file and line number <roptat>all I have is a stand alone derivation <roptat>so I don't even know what to fix <roptat>I have the guix revision I'm trying to pull on my x86 system, but "guix build glib" and "guix build -e '(@ (gnu packages glib) glib)'" return two different derivations that are not the one I'm trying to build <roptat>similarly from the arm system, from the current revision of guix, that's not it either <roptat>ok, so now I can build it without tests, how can I cheat and make that into a nar for the one with tests? <leoprikler>compute the output file name for the nar with the tests and then 'sudo cp'? <roptat>no, that won't be enough the nar contains the expected store path <roptat>lispmacs[work], "Bad Response-code"? <roptat>lispmacs[work], the list in services is not closed where you think it is <roptat>line 55 is missing a closing parenthesis <lispmacs[work]>roptat: thanks. hopefully the Parentheses Haters Club doesn't get wind of this *roptat is interpreting the signs in guile backtraces <roptat>I've been confused for years by these backtraces <roptat>oh no, without-tests doesn't work as expected, because the package redefines the check phase :/ <pkill9>we should have a more central repository of configurations <pkill9>actually it would be cool if someday a repository of guix configurations was integrated <pkill9>I want guix to be as easy to use for desktop system <pkill9>but the guix configurations could also include other setups, like for servers, like the current examples <roptat>we have a few options in the installer already <charles`>is it possible to configure gsettings with guix scheme? <leoprikler>there's guix home manager, but all you can really do with that is dump a whole file :( <roptat>well, there could be some bindings, if "someone" did that :) <leoprikler>apart from that you could write an activation service, that invokes the gsettings binary at startup <leoprikler>for native bindings we would need dbus in guile, which IIUC is only part of broader GI libraries currently <roptat>arg, the linking is taking forever... <marusich>apteryx, re: switching to gtk+ without librsvg on core-updates for some platforms, yes, that's an unfortunate consequence of librsvg's recent decision to depend upon rust. It is better to have a GTK+ that can do some things, rather than no GTK+ at all, but it's definitely something we need to fix. <marusich>The fix is probably to improve Rust support so that we can re-introduce the dependency on librsvg. <marusich>It is inevitable that many packages will eventually switch to use Rust. It's growing more and more popular. We'll need to have a good Rust story for our platforms. <marusich>I can't speak for the other system types, but on powerpc64le-linux, I intend to try my best to make it happen, though it may take time. <jackhill>marusich: as a curious observer, do we know what's causing our Rust failure on other platforms. Sounds like it's a problem unique to Guix? <marusich>Owning the hardware is a powerful motivator... <marusich>jackhill, well, for me personally, the main problem is that I really don't want to deal with Rust on powerpc64le-linux in the beginning, but I want Emacs, and Emacs depended upon rust via gtk+ -> librsvg. <marusich>The original issue was that Emacs (and any package depending indirectly or directly on librsvg) was explicitly only supporting x86_64-linux. <jackhill>marusich: makes total sense. I just think upstream rust supports at least aarch64, but was wondering where the problem was in the guix end. Probably bootstrapping, but just curious. <jackhill>I unfortunatley, don't yet have other hardware. I wish ppc64le were cheaper :) <marusich>I fixed that with commit 001fc29b43fd0beb365d536774fae96624309413 <marusich>So after that commit, the many packages that were previously x86_64-linux only, now "support" many systems again, which means Guix will not refuse to try building them outright. <marusich>The immediately preceding commit, 5d2863dfe4613d5091e61800fcd5a48922c8ce4e, fixes the issue just for emacs by avoiding Rust entirely on non-x86_64-linux systems. <jackhill>marusich: cool, making the other platforms a little bit more usably is probably a good first step <marusich>It is true that we might be able to expand upon 5d2863dfe4613d5091e61800fcd5a48922c8ce4e and actually re-introduce the librsvg dependency on some arches, but I don't know to what extent that is true (haven't tried it), and this puts us already in a better position for now. <marusich>And personally I really wanted to avoid debugging rust issues right now, and emacs was required to build guix <marusich>I think the next step for librsvg would be to try re-introducing it on core-updates for some arches and see if it works or not. For powerpc64le-linux, I can do that on my own hardware; I guess I could try the builds at least on other hardware using emulation. <marusich>It isn't my intent that gtk+ and emacs will forever live on without svg support.\ <leoprikler>what I would personally like for Guix is a transitive-supported-systems aware way of specifying inputs <leoprikler>like (dwim package-with-rusty-madness package-without-rusty-madness package-fallback-for-really-niche-arches …) <marusich>How do you mean? currently the supported systems percolate up, in that if a depends on b, the supported systems of a are the set-intersection of the supported systems of b. <jackhill>marusich: I appreciate it. I have to enjoy the journey vicariously while I'm still in x86_64-only land :) <marusich>My fear with that is that it could easily wind up making the package collection look very different for different arches <marusich>When I run "guix build emacs" on powerpc64le-linux, I want "the same" emacs that everyone else is using, to the extent that is possible. <marusich>It is good to share the same problems with others. <marusich>it is harder when your problems are unique. <marusich>You are more likely to have unique problems if the package is unique. <leoprikler>marusich: sure, but you can code around that, by ensuring you don't add any package, that would make your supported-systems needlessly small (*cough* rust *cough*) <jackhill>I do have ppc64be machine, but I think there's something wrong with it, and it's not clear how useful a BE port would be. <marusich>That said, something like that...a way to say something like "parameterize the package so that i use non-rusty things", could be useful <marusich>I think Pierre was working long ago on parameterized packages or something like that <marusich>jackhill, it is possible, but the work for powerpc64-linux has not proceeded as far as powerpc64le-linux. We found that powerpc64le-linux could be bootstrapped far enough to build guix and do guix pull etc., so we stuck with that <marusich>My understanding is that BE is going to be harder because it is generally less well-supported by the various tools (e.g., gcc) <marusich>A lot of distros are apparently aligning on LE instead of BE <marusich>So it seems like a powerpc64-linux system would be stuck with more unique problems to deal with <jackhill>marusich: right, and it looks like the future of Power is le? Maybe, I dunno, this crystal ball never did work very well. <marusich>It could work, but I guess nobody has really pushed it that far yet in Guix. <jackhill>Debian dropped support for BE for example. <marusich>I think the hard part is the bootstrapping <marusich>It's sort of a small miracle we were able to successfully bootstrap from gcc 5.5 on LE in the first place <marusich>I think this raises an interesting question about how we will bootstrap future architectures that cannot possibly work on GCC 5.5, but that's another question <marusich>It's nice to share the same bootstrap path with the other system types, again because this allows us to share the same problems. <marusich>But perhaps on future systems it will only be possible to start from GCC 17 or something <jackhill>hehe :) I'd like to figure out the problem wiht my BE machine, so that it doesn't power down randomly. With that problem it would be very fun to work on. <pkill9>anyone know how to run something like `echo test | bash -c source <file> ; cat` such that 'test' would get piped into cat? <marusich>jackhill, if you ever were curiuos, you could try powerpc64-linux using bootstrap tarballs generated here, but you'd have to do significant work to update your local copy of the Guix Git repository (and probably host a copy of it yourself somewhere) so you can really try it out: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41669#74 <jackhill>I'd also be happy to see the various mips ports revived, but the biggest mips hardware I have only has 512mb ram, so until I find bigger hardware, I can't see doing porting work. <marusich>The changes would be similar to what you see in the first few commits of the wip-ppc64le (or wip-ppc64le-for-master) branch <nckx>pkill9: ‘pee’ from ‘moreutils’. <marusich>I think you were actually involved in that bug report, already! <leoprikler>pee sounds like a peeritty silly name for a program <jackhill>marusich: indeed, well I am interested :) <nckx>leoprikler: ‘tee’ for pipes, but yes, also for schoolboys. <marusich>jackhill, if you want help at any time feel free to shoot me an email <marusich>I intend to focus on the LE port but have an interest in anything POWER9-related <pkill9>nckx: so how would i use `pee` with my example? <jackhill>marusich: okay. Oh I didn't think I mention by my BE host is an Apple G5, so, uh, not POWER9. I think my best bet is getting access to newer hardware first :) <apteryx>should warning and other user facing messages be properly capitalized full sentences? <pkill9>hmm looks like original should be working <marusich>jackhill, I dunno, maybe the fact that it's older means it's somehow better supported? <marusich>It could be fun to try. If you model commits based on what you see in wip-ppc64le, you could try it over a weekend or something maybe. <marusich>Granted, you likely will wind up facing a problem when you try to build stuff, but that's just how it goes. <marusich>And if you are successful, it could be worth sending patches :) <marusich>(even if you're not successful, but are interested in supporting the architecture) <jackhill>and I bet I'd learn a lot. Hopefully I can figurout out this random power off problem (currently running the hardware with Void Linux) <PotentialUser-60>Hello! I am trying to build a program and I've come across an issue. When I try to build I get this error: "Project ERROR: polkit-gobject-1 development package not found". I've tried installing the packages polkit, polkit-gnome, and polkit-qt, but doing so has not fixed this. <PotentialUser-60>In the program's documentation, it lists "libpolkit-gobject-1-dev >=0.105" as a dependency. ***pie_ is now known as PIE_
<leoprikler>I would suggest using development environments instead of your ~/.guix-profile to install the packages to. <leoprikler>It's probably one of polkit/polkit-gnome, but you might lack other stuff like pkg-config <ngz>civodul: It may be version 1955ef93b76e51cab5bed4c90f7eb9df7035355a, I'm not 100% sure as I updated the daemon since the recent warning. ***jess is now known as JESS
***JESS is now known as jess
***Noisytoot is now known as NOISYTOOT
<charles`>I'm getting premission denied on a symlink when system reconfigure. Any idea how to fix it <raghavgururajan>PotentialUser-60, Example: `guix environment --pure --ad-hoc dep1 dep2 ... depn` and then build prog inside that env. ***NOISYTOOT is now known as VERYNOISYTOOT
***jx97 is now known as jx96
<charles`>No, I thought guix was supposed to be run as unprivilaged user <lispmacs[work]>charles`: can build system profile as unpriviledged user, but must be root to install it ***VERYNOISYTOOT is now known as Noisytoot
<raghavgururajan>charles`: System zone is a super-set of user zone. In that case, you cannot have each user on same system reconfiguring that system differently. <lispmacs[work]>hi, I'm still tweaking the system config on my 32 bit x86 laptop, which is running lxqt + slim + elogind + connman. One problem I am running into is I don't seem to have the permissions as a normal desktop user to communicate with connman over dbus. I checked in the guix source and it looks like lxqt-desktop-service includes polkit settings, so I'm not sure where I've went wrong. <lispmacs[work]>in short, I can't change or view connman network settings unless I do so as root <lispmacs[work]>trying to figure out if there is something wrong with my conf (most likely) or some issue with the polkit setup by the service ***jpoiret3 is now known as jpoiret
***jx97 is now known as jx96
***sneek_ is now known as sneek
***fitzsim` is now known as fitzsim
<civodul>ngz: 1955ef93b76e51cab5bed4c90f7eb9df7035355a should be free of the bad-response bug; do let us know if it shows up again! <charles`>It seems that make install for guix isn't working for me. It appears to work, but the new guix isn't being used