IRC channel logs

2021-03-19.log

back to list of logs

<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``>
***charles`` is now known as charles`
***charles` is now known as charles
<xelxebar>Guix! Hope everyone here is doing well.
<marusich>hello everyone
<marusich>and...goodnight :) It's late!
<marusich>Good morning to all of you across the pond.
<pocketroid>ja ne
<pocketroid>oh good evening, yeahl Greets
<civodul>Hello Guix!
<zimoun>hi!
<avalenn>Hello Guix!
<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>sneek later tell lfam hello! :-D - we have QEMU CVE-2021-3416, https://bugzilla.redhat.com/show_bug.cgi?id=1932827#c12 (10 individual commits to fix it..) lol
<sneek>Will do.
<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> https://ci.guix.gnu.org/build/73152/log/raw
<i1l>no way to remove geoclue from that?
<rekado>remove geoclue from geoclue?
<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.
<i1l>all i have, bye.
<lle-bout>sneek later tell lfam do we have to actually apply patches for those? https://xenbits.xen.org/xsa/advisory-368.html - seems there's no release issued
<sneek>Will do.
<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
<sturm>thanks :)
<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?
<lle-bout>sturm: or guix-devel thread at least
<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?
<leoprikler>(on guix pull)
<civodul>leoprikler: nope, sounds scary
<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.
<davexunit>okay, so copypasta it is.
<rekado>it only works for scripts that use # as the comment character
<efraim>thanks for the clarification
<rekado>wrap-program wraps anything
<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
<davexunit>yeah
<davexunit>that's what I'm doing now
<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: correct.
<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
<davexunit>rekado: thanks
<davexunit>I'm a bit rusty ;)
<rekado>it’s great you’re back to hack a bit on Guix!
<davexunit>thanks. just doing a quick fix.
<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?
<civodul>an illustrated call for testing: https://mastodon.online/@luis_felipe/105917109210886738 :-)
<roptat>hi cage_!
<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
<leoprikler>civodul: the Japanese reads "test pilot"
<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?
<roptat>bah no, it doesn't work
<cage_>roptat, that file exists on my system! Thank you!!
<roptat>\o/
<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
<PotentialUser-44>Hello!
<PotentialUser-44>Friends, I have this problem while running Inkscape:
<PotentialUser-44> https://files.catbox.moe/kbiy0k.png
<PotentialUser-44>Please help!
<roptat>PotentialUser-44, I think it's already fixed very recently, you should try again after "guix pull"
<PotentialUser-44>roptat: Oh, thank you
<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?
<PotentialUser-61>Hello!
<PotentialUser-61> http://paste.debian.net/1190019
<PotentialUser-61>I skipped these in "guix pull" command, what are these?
<roptat>optional dependencies that are missing at this stage, I don't think it's important
<PotentialUser-61>roptat: Thank you very much!
<roptat>mh... binfmt is tricky
<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>in terms of guix services
<dustyweb>I don't see it anywhere by grepping through things
<dustyweb>oh
<dustyweb>is it from shepherd?
<dustyweb>yep
<dustyweb>okay
<dustyweb>got it :)
<davexunit>yuppers
<civodul>:-)
<civodul>hey dustyweb!
<cage_>iguix system reconfigure fails with an error like: "cannot determine provenance of GUIX"
<cage_>any idea?
<roptat>have you run guix pull?
<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?
<cage_>as root
<roptat>with sudo, or as the root user?
<cage_>root 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>I still can't use binfmt...
<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.
<leoprikler>Now we use the F flag and static qemu
<leoprikler>See <http://git.savannah.gnu.org/cgit/guix.git/commit/?id=77c2f4e2068ebec3f384c826c5a99785125ff72c>
<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?
<roptat>civodul, yes I can
<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
<civodul>not sure about the others
<dustyweb>hi back, civodul !
<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>I guess I'll just have to write my own...
*davexunit falls down a well
<roptat>civodul, no it's on a foreign distro
<davexunit>"how hard could it be?"
<civodul>davexunit: but see roptat's Gitile: https://git.lepiller.eu/
<civodul>roptat: aaaah!
<davexunit>ooooh
<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
<davexunit>roptat: gitile is really neato!
<roptat>davexunit, thanks :)(
<roptat>:)
<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
<davexunit>again, "how hard could it be?"
<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
<roptat>sounds like a lot of trouble
<civodul>it could keep you busy for the decade to come :-)
<roptat>right :)
<davexunit>I don't need a robust tracker.
<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
<civodul>davexunit: there's also Radicle
<civodul>never used but it looks interesting
<davexunit>hmm I'll check that out
<roptat>so we have a similar need :)
<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.
<davexunit>"just" is doing some heavy lifting, I know.
<davexunit>I already have a project name: microbe ;)
<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"
<echosa>Ah, I see it.
<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
<ngz>Hello Guix.
<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
<echosa>Similar, but not exactly the same, error: https://paste.debian.net/hidden/bf7fdaed/
<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
<echosa>:-/
<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
<roptat>it's really not great :/
<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>echosa, no that should be fine
<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>So just keep brute-forcing it?
<roptat>right
<roptat>you might want to add your experience to https://issues.guix.gnu.org/47266
<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>davexunit: it's at https://git.elephly.net/?p=software/mumi.git;a=summary
<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>thank you!
<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>oh I found it! it's glib/fixed
<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'?
<leoprikler>note: this is evil
<roptat>no, that won't be enough the nar contains the expected store path
<roptat>I won't fool guix import
<lispmacs[work]>Hi, I get an exception when I try to build this system: https://bpa.st/GCMQ
<roptat>er, guix archive
<roptat>lispmacs[work], "Bad Response-code"?
<lispmacs[work]>roptat: here is the error dump: https://bpa.st/AKQA
<lispmacs[work]>and the hardware details: https://bpa.st/75EA
<roptat>lispmacs[work], the list in services is not closed where you think it is
<roptat>line 55 is missing a closing parenthesis
<roptat>and remove one from line 56
<lispmacs[work]>ah
<lispmacs[work]>roptat: thanks. hopefully the Parentheses Haters Club doesn't get wind of this
*roptat is interpreting the signs in guile backtraces
<roptat>:)
<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
<charles`>pkill9 do you mean like starter kits?
<pkill9>yea
<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>partially
<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
<raghavgururajan>Hello Guix!
<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.
<civodul>ngz and everyone who has bad-response issues: could you provide info as noted at https://issues.guix.gnu.org/47266#2 ? (for foreign distros)
<civodul>lispmacs[work]: ↑
<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>So it was in the way of my porting work
<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>I hope that helps clarify my thinking.
<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>Yeah, but they existed
<marusich>I think the hard part is the bootstrapping
*jackhill nods
<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
<raghavgururajan>Hello Guix!
<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
<jackhill>marusich: cool, thanks
<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
<marusich>maybe it's like tee
<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
<PotentialUser-60>How can I use the development environment instead?
<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
<raghavgururajan>PotentialUser-60, https://guix.gnu.org/manual/en/html_node/Development.html#Development
<charles`>I'm getting premission denied on a symlink when system reconfigure. Any idea how to fix it
<charles`>I've tried gc and pull
<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
<raghavgururajan>charles`, You did reconfogure as root right?
***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
<charles`>root worked, thank.
<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]>here is my system conf, as of a few seconds ago: https://bpa.st/3K6A
<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