<slyfox>is there a verbose way to trace 'guix refresh' operation? I wonder what would be the easies way to debug failure: '$ ./pre-inst-env guix refresh mc' -> 'gnu/packages/mc.scm:41:13: warning: 4.8.26 is greater than the latest known version of mc (4.6.1)'
<str1ngs>slyfox: I think that output is intended. but it's possible your guix is older? what verion of mc does guix show mc produce?
<slyfox>It's: 8d80a708535546394deaea6489245ecc09b29131 'Date: Sun Aug 15 16:58:40 2021 -0400'
<roptat>I'm trying to have clang generate makefile dependencies, but it complains one of the header files is missing. Indeed, I'm trying to make it generate that so that make knows it has to generate that header first... is there a way to solve this?
<roptat>I'm building a cpp file that includes a generated header. There's no makefile, it's the soong build system for android, so I generate one from the Android.bp description. The makefile needs to generate the header before it attempts to build the cpp file
<roptat>so I thought I could generate a dependency file with the C compiler (-M and friends), but that seems to require all the headers already
<roptat>(I need something like "a.o: b.h", and there are makefile rules for building b.h and a.o)
<thorwil>hi! geeqie used to work, but now fails to start with “(geeqie:15752): Gdk-ERROR **: 09:18:20.939: The program 'geeqie' received an X Window System error.” and “Details: serial 176 error_code 11 request_code 149 (unknown) minor_code 2”
<thorwil>this is on a foreign distro, so i would like to know, if anyone can reproduce that.
<cehteh>ok doesnt work, no vpn, other things to do
<dstolfa>networkmanager works really well under redhat systems, but it has always failed me under anything else
<sailorCat>Hi, I somehow got an error "Symbol’s function definition is void: make-closure" when I restart the emacs-next package after few attempts I decided to get a new fresh installation. But seems `guix package -r emacs-next && guix package -i emacs-next` didn't do it for me. What is the way to fully reinstall a package in guix?
<mfg>I can't help you, but the emacs-next package is almost one year old
<mfg>that is the commit it uses is from August 31 2020
<minikN>Hello, does someone have instructions on how to install composer (php) with guix? I installed it manually according to https://getcomposer.org/download/, I also installed the offical php package in a profile. But I can't execute composer: /usr/bin/env 'php': no such file or directory. Is there a better way to install php & composer?
<mfg>minikN: if you installed it in a profile, have you loaded that profile?
<roptat>so, I probably decided on the wrong approach. I basically reimplemented the whole build system in guile, without making the same assumptions that we're building all at once from the complete source tree
<roptat>I fixed many issues I had with the cc_* type of targets, but now I need to implement the whole build commands and option parsing for the java_* targets
<abrenon>is that the make-makefile-rule and friends ?
<rekado>you’d import these hundreds of NPM packages and then move on.
<roptat>yeah, in a blueprint file you have different type of targets (like cc_library, cc_binary, ...) and each target has its own rules. So soong-cc implements them by generating the right makefile-rule objects, given the configuration and type, then the soong-build-system knows how to generate a Makefile from the and run make
<roptat>it's handy, you can comment without changing lines, like (+ 1 #;(compute-something) 3) -> 4
<abrenon>that's great ! so they're kind of sub-inline comments
<roptat>yeah, but they can also span multiple lines if you comment a complex s-expression
<abrenon>so, just comments-as-any-syntax-construct : ) cool
<roptat>so, I'm still missing code for handling java targets, I could create the packages for fastboot, I need to work on the importer so it's easier to recreate/reimport the packages each time there's a version change that could change the dependencies, and I should take the targets (host/device mostly) into account
<roptat>I'm still not entirely sure if the difference is simply the target triple, or if there can be different targets for the same triple
<abrenon>hmmm so "only one more package to go" but still a lot of work I see : )
<podiki[m]>I just separated all my packages into profiles, so default is empty. I added glib to a profile to make sure I got XDG_DATA_DIRS exported from that profile to pick up dbus files, yet still seems you need dbus-run-session
<raghavgururajan>podiki[m]: You may have to run dbus-daemon as user, via dbus-run-session, so that dbus-enabled apps can communicate with the daemon.
<podiki[m]>raghavgururajan: does that entail modifying the default dbus service then?
<podiki[m]>or can I just do that on top of system dbus?
<raghavgururajan>dbus-service as in config.scm? If so that's system-level dbus-daemon. For some reason, apps run by user doesn't communicate with system-level daemon.
<raghavgururajan>What that snippet does is, when you login as user, the dbus-daemon session is started (along with shepherd) and exports correct variables. That dbus daemon runs as long as shepherd is running.
<podiki[m]>yeah, just restarted. my test case is running a flatpak applications, as that needs to talk to dbus on startup. it complains it can't find the service file it wants unless I use dbus-run-session
<podiki[m]>thanks! (i'm also learning more about dbus daemons now...)
<raghavgururajan>str1ngs: There is no separate branch for gtk4, but wip-gnome branch is used for gtk4. There updates in that branch that is required by gtk4. The patches in #48554 are to applied and developed on that branch.
<raghavgururajan>podiki[m]: The variable "DBUS_SESSION_BUS_ADDRESS" is exported by that snippet, which is good.
<raghavgururajan>podiki[m]: For flatpak, you may have to extent the XDG_DATA_DIRS to flatpak's share-dir.
<cossidini>im trying to get stumpwm to run on aarch64 with guix but the build fails for sbcl. the ci server shows that sbcl build fails too. is there a way to check if it has ever successfuly been built?
<cehteh>rekado: that downloads a binary blob into /tmp and executes it, which wont be working in guix for now
<podiki[m]>raghavgururajan: yes, as well as the .local/share.. place flatpak wants to look, but that's for apps installed there to appear in eg launchers. I can add what it wants just in case (though /var/.. doesn't exist on guix of course)
<cehteh>i am currently dont even know where to start when i want to repackage it .. can i guix edit rust save the file $somewhere (is it really edit? or just 'view') and then at least for me build and install it before sending a patch?
<cehteh>well sory i am nagging about this, i coudl read the docs, but i am in a hurry packing stuff leaving tomorrow by train
<podiki[m]>raghavgururajan: seems to mainly affect Element (matrix client). It wants the flatpak portal to run on startup and wont' find it without dbus-launch
<raghavgururajan>podiki[m]: I have a confusion. Was it the app installed by flatpak or installed by guix in one of the extra-profiles, that doesn't coonect to the dbus?
<podiki[m]>flatpak is installed in the desktop profile (my default profile is now empty), and app is installed by flatpak and run by flatpak. flatpak has some dbus stuff it wants to launch (e.g. to open links or such)
***ec is now known as tl
<podiki[m]>but based on that issue I linked earlier, this seems to be a general problem if your dbus services are not in the default profile
<podiki[m]>so I guess I can investigate why system dbus doesn't use xdg_data_dirs (which should get dbus from all profiles), or somehow running a user daemon that is then used by programs instead of using the system one
<podiki[m]>it is installed via --user (don't think you can otherwise without sudo)
<podiki[m]>I should remove the dbus shepard lines and see what the default gdm dbus env is, to compare; but seems like launched by system is not respecting xdg_data_dirs (or is launched earlier and only with default like /etc/ to look at?)
<podiki[m]>my other guess it so try another WM (I just have awesome installed) to see if it is how I launch my WM messing with dbus. but again, worked without any workarounds when all was in same profile, so pretty sure that is the issue
<podiki[m]>(also going to investigate dbus and xdg_data_dirs more broadly)
<raghavgururajan>podiki[m]: When you remove dbus shepherd line, let me know if "DBUS_SESSION_BUS_ADDRESS" is still exported in env.
<iskarian>yoctocell, thanks for testing, and for sharing your generic-git updater! I'm not sure how I feel about using properties, or at least requiring properties when we can guess - I'd rather it enable support without editing packages where possible
<iskarian>And if I'm reading it right (I'm not super familiar with (guix git)) this updater has to clone the repo for every package it's checking?
<sneek>justin, marusich says: It's possible to build an ISO-9660 image for GuixSD, but since the feature was added recently, a pre-built image isn't available yet. To build your own, run 'guix system disk-image -t iso9660 gnu/system/install.scm' from the root directory of the Guix source tree.
<podiki[m]>raghavgururajan: I'm still stuck on the xdg-desktop-portal dbus refusing to find some of it's service files, but no leads. I'll probably make my xsession cleaner and look at what stuff gnome does with dbus. very odd though
<acrow>I am running GuixSD, pulled this morning from master. I've installed the gramps package and whenever it is started I get the following error message, "grampsgui.py: line 538: GTK translations missing, GUI will be broken, especially for RTL languages!". This is just informational but it bugs me. I have no other examples of this happening but I keep thinking I'm not installing something else I need like, and I've already done this one,
<acrow>shared-mime-info. Running en_US and I've specified (operating-system ..(locale "en_US.utf8")...). Anyone else have other ideas?
<acrow>I see that the ubuntu community solves this same problem by installing the package 'language-pack-gnome-en'. Do we have an analog to that that I'm missing?
<acrow>Of course I'm running the xfce window-manager and not gnome.
<acrow>I think you are correct ruffni that PulseAudio is a default and nothing else is needed from shepherd but you might want to be sure you put yourself in the 'audio' group to have it work as other than root.