<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.
<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: 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?
<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?
<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
<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 :)
<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 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>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>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/
<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
<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>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.
<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
<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
<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.