<ogey>It does not work . It has the same error <antipode>Maybe it's a slight AMD / Intel difference in rounding or such. <formbi>podiki[m]: hmm, I tried to swap the 1.2.4 into your definition and it wants dbus and quazip <ogey>How much of the top do you want? <antipode>The same stuff as I copied in the bug report. <antipode>(Except, you know, with the values of _your_ system) <ogey>ok right now I am not on the internet with my laptop so I will have to type it in manually <podiki[m]>formbi: huh, weird. oh, was there some qt updates in guix recently? not sure if they went through and if either of us have those updates, only thing popping to mind <formbi>the 1.2.2 built, then I swapped in the 1.2.4 and it wants the stuff <podiki[m]>what do you mean swapped in? in my test I just did guix build corectrl --with-latest=corectrl (since I have the package def locally in my guix) <podiki[m]>which should be the same as updating version and source hash <ogey> vendor_id : GenuineIntel <ogey> model name : Intel(R) Core(TM)2 Duo CPU P840 @ 2.26GHz <podiki[m]>formbi: you've mixed the git version with the other source url, so it did not do a new checkout (the hash is wrong for 1.2.4) <nckx>antipode: Speaking of fontpens (oops, I didn't push the ‘fix’ yet — will do): I think it might fail on Intel, succeed on AMD, but the sample size is too small to say. <formbi>it's the hash of the latest git version <nckx>Sample size being it built on a berlin node (AMD) and fails on my Intel laptop :) <podiki[m]>but from my definition if you update version to 1.2.4 and hash to 1pmlkilk4ibzx1dsk1gc3mxczfz456jfa1as4lsxwqs4w8yawqyx it builds <podiki[m]>oh, well could be a change more recent after 1.2.4 then <nckx>Oh, you added a data point. <formbi>let's see with the proper 1.2.4 then <podiki[m]>I'd recommend the latest release number, to keep things hopefully more sane <formbi>but if we used the latest thing, we'd be prepared for the future release <ogey>I actually have an AMD computer and I could try building it there as well <podiki[m]>generally we track releases if they have them unless there is a reason, and one can use transformations to do build from latest git <podiki[m]>the downside, as you see,is that the build is in flux so I wouldn't go there yet unless the fixes in those commits are needed (then could add them as patches on top of 1.2.4 if they apply cleanly) <podiki[m]>it does sound like, in my quick skim, these could be good changes for the issues with dbus/authentication that is tricky with corectrl. but I have briefly used the version I linked you; needed a polkit agent started manually for me since I'm not in a DE ***Xenguy_ is now known as Xenguy
<nckx>ogey: Can you pull & try again? <formbi>so I guess you could send the package to Guix if it works <formbi>but I'm not in a DE either so it doesn't start for me <podiki[m]>I'd want to clean up the wrap-program (get rid of it in favor of patching paths in corectrl), maybe other stuff <podiki[m]>try `guix shell polkit-gnome` and then $GUIX_ENVIRONMENT/libexec/polkit-gnome-authentication-agent-1` <formbi>Cannot register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Passed session and the session the caller is in differs. They must be equal for now. <formbi>could that be because of running on a foreign distro? <podiki[m]>oh on a foreign distro...no idea for the dbus/polkit stuff sorry <podiki[m]>as on my guix system also have corectrl polkit and dbus services in my configuration (to pick up the rules) <formbi>at least it does work as root (not that I'd like to use it like that…) <podiki[m]>yeah, not sure what dbus/polkit stuff is like to pass on to foreign distro <podiki[m]>maybe for foreign distro you just need the dbus/polkit rules added as your distro would? just guessing <podiki[m]>anyway, feel free to clean up that package def ;-) but I could probably quicklymake it guix ready and submit a patch <podiki[m]>hang on to your version, sounds like it'll be useful for next release <dcunit3d>what's the best way to configure things like /etc/profile and /root/.bashrc for a root user on a new guix system? <dcunit3d>i'm working on an ISO for making PGP/SSH keys and as an offline certificate authority <dcunit3d>i need to add some guix-home-like behavior for the root user and for the other main login user. for now, this system won't be persisted. i'll just load the ISO and mount an encrypted disk <dcunit3d>i see that i can add things with the extra/special-file services, but how can I get the scripts sourced? <dcunit3d>i'm not quite proficient enough to write services quickly (and i'd be cargo-culting anyways), so for initializing services i just want to make some bash scripts to launch some things. <dcunit3d>looking at the code in ./gnu/services/{base.scm,shadow.scm} and ./gnu/service.scm, it seems that the =/etc/skel= is created from files inlined in the code. can i use compose/extend to append to those files? <dcunit3d>it's not a huge priority (for me, since i'm just trying to GTD), but before i added step-cli and step-ca, it's pretty much fully free software. so that was pretty cool to see <dcunit3d>however, those two are golang projects (so is everything CA, apparently) and they seem to have a bunch of custom/modified golang deps. so i just created some step-cli-bin and step-ca-bin packages. <dcunit3d>so two questions, i guess: what's the best way to glue things together for these two users for this ISO? <dcunit3d>and are there any alternatives for certificate management? i've found a bunch of golang, a few active java projects and one or two bash-based projects, but i don't know how to vet them. <ogey>Hi I am still upgrading the system but It seems like the python pen part built fine so I think everything else will work. I will tell you when it finishes fully. <ogey>The system upgraded after pull. Thanks for the update. <oriansj>does anyone have a gitea build definition I can use? <crono>Has anyone been getting a 502 bad gateway for issues.guix.gnu.org? <podiki[m]>crono: yes, it has been down for several days, it is known by the people that will fix it <lilyp>is there any ETA or are we completely in the dark? <bullethead>if I run an "guix pull" then "guix system reconfigure /etc/config.scm" is there anything I have to do to update <bullethead>as privildeged user (english not my first language) ***LispyLights is now known as Aurora_v_kosmose
<Guest11>issues.guix.gnu.org gives a 502 Bad Gateway <Guest11>i'm having troubles getting guix to compile a minimal operating-system (to an image file if that matters) with raspi-arm64-chainloader. <muradm>Guest11: raspi-arm64-chainloader is a package, which you are putting in bootloader-configuration structure's bootloader field <muradm>basically error says that unexpected value (wrong type argument) <muradm>for arm, may be you want u-boot? <Idjustliketointe>Packages cannot upgrade without substitutions after guix pull, this is happening every time <Guest11>thanks. i think i got confused by the phrasing in the package description for raspi-arm64-chainloader "bootloader for the ARM part of a Raspberry Pi". i'm not sure if it's possible to boot a raspi through normal (i mean U-Boot) terms. (make-u-boot-pacakge) just takes the standard u-boot and sets the configuration to the string passed.. i know this <Guest11>is the somewhat wrong channel to ask, but maybe someone can hint me to my fundamental misunderstanding of the issue at hand? ***wielaard is now known as mjw
<cdo256>Hello :). I'm trying to install the guix system 1.3.0 and I'm up to `guix system init ...`. It fails on grub-install to create a grub-efi-bootloader. The error message says that .../i386-pc/modinfo.sh doesn't exist. It doesn't, but I don't see why it isn't looking in .../x86_64-pc/. How could I fix this? Is it possible to specify this in the guix system configuration file? <drakonis>i would recommend using a newer image right now <vldn>mh how to install pidgin plugins? <vldn>okay, just install... :D <drakonis>by the way, is there any explanation as to why parallel jobs leads to reproducibility issues? <drakonis>i remember this coming up a while back and i was left puzzled by the idea <drakonis>does it not have a way to queue builds in a way that it doesn't lead to that? <muradm>keeps starting and kicking off pipewire-pulse <apteryx>muradm: try autospawn=no in your pulseaudio-configuration's client-conf field <muradm>i don't have pulseaudio-service-type at all... still <apteryx>the service is only used to *configure* pulseaudio, it doesn't run it <apteryx>so maybe you should add it and have the clients (which can be any app built with pulseaudio support) refrain from auto starting it <muradm>good pointer thanks, for set it in ~/.config/pulse/client.conf, let's see <muradm>apteryx: may be you also know who starts xdg-desktop-portal? :D <mrvdb>is it intentional that packages for systems are included even if their builds fail on ci.guix.gnu.org? (case in point, exiv2 for powerpc64le-linux) <Guest11>mrvdb: i think the intention is to only push changes that actually compile. but bugs happen <mrvdb>invisible though, or at least unnoticed since feb. <mrvdb>perhaps my expectations need re-adjusting. <ekaitz>mrvdb: can you try to build for this commit: 6a6d9a858ef07571089f2f87466641f1374666b0 <ekaitz>it should, because I did build that <ekaitz>or maybe clean the directory completely and build again <ekaitz>mrvdb: I can reproduce your error <ekaitz>mrvdb: I'm bisecting just in case <ekaitz>mrvdb: did you try with make clean && make ? <ekaitz>mrvdb: just tested, making a clean build fixes the issue: make clean && make <mrvdb>ekaitz: on master checkout or on that commit? <ekaitz>try it and ping me back if you have more issues <akonai>Is it possible to tell Guix to keep the .git repository in the source tree while building a package, with git-fetch? It seems to delete it <mrvdb>ekaitz: git guix builds fine now. thanks for your time. Now to find out what to work on first..... <Cairn>Hey, I see in 10.8.6 X Window that the default pre-X script in GDM is `(xinitrc)`. Issue is that my `~/.xinitrc` isn't being loaded when I log in. Does it mean something else? <nckx>Don't ask me why or what's moar correkt, but .xsession certainly sounds more ‘familiar’ to me. <Cairn>Ah, fair enough. So I can just add my .xinitrc contents to .xsession. Let me give it a shot. <nckx>akonai: I don't think so, IIRC because it's not reproducible, but it shouldn't ever be needed anyway. <nckx>(You never need .git to build the software.) <nckx>Some build scripts try to sniff the git revision but they can be convinced to use the package-version through a variable/configure/make flag (great) or through patching (less great, but hey). <Cairn>Also, I'm just getting started with Guix System; is there a clean way to do guix object lookups in Emacs? Kinda like Emacs's `C-h o` or `C-h d`? <Cairn>Or else, where are the Guix source files on my system? <nckx>Apparently you can get an IDE-like experience (or close to it) by using ‘Geiser’, but unfortunately it has never actually worked for me. <nckx>I use a local Guix git checkout so don't no the answer to the 2nd question. <Cairn>Oh interesting. I'll take a look, thanks! <mrvdb>so, exiv2 is suffering from an upstream bug on ppc64; making it fail tests. is the appropriate action to disable ppc64 for that package? if so, how does that work? if not, what is the action to take? <nckx>mrvdb: Well, the correct answer is ‘fix the tests’, but with that out of the way… :) If the resulting exiv2 actually appears to work fine on PPC64, you can set ‘#:tests? (not (target-ppc64le?))’, so it evaluates to #f only then. If the resulting output is garbage that won't run, use supported-systems (examples abound in (gnu packages)). <nckx>To be clear: you'd only use one of either work-around. <nckx>mrvdb: But if there's an upstream patch available, use that. <mrvdb>so we allow packaging with failing tests? it's an overflow bug apparently <nckx>We do, if the failure is considered ‘bogus’ (lots of packager leeway in defining that). We probably do it too much. But time is scarce. <nckx>Well, is the resulting exiv2 a crashy useless mess on PPC64, or does it run fine in practice? (False dichotomies yay.) <nckx>You could also disable only specific tests on PPC64. What I'm trying to say is, you have options, unfortunately. ***mark_ is now known as mjw
<akonai>nckx: yeah, I just encountered a program that tries to use its git repo for --version purpose. Unfortunate. ***Dynom_ is now known as Guest6909
<Cairn>system reconfigure says (target) is depricated, but I get an error when using targets. So which do I use? <davidl>Cairn: can you paste your targets line? <Cairn>Well, the line with (target) is `(target "/boot/efi")` in the bootloader section <davidl>if using targets, it needs to be like: (targets (list Ä) <davidl>if using targets, it needs to be like: (targets (list "mydevice")) <Cairn>That makes sense then. I'll switch it now <Maya[m]1>hi, i have installed opensmtpd and opensmtpd-filter-rspamd, but i don’t know how to join them together? i need to set up <Maya[m]1>`filter “rspamd” proc-exec “some/path/libexec/filter-spamd”` <Maya[m]1>but I cannot seem to find a way to get this path <Maya[m]1>i know I could use gexp, but that is not available as it is not a buikd context, rather a simple-file context <Maya[m]1>nevermind i just found out text-file* exists <Cairn>I'm having a bit of trouble understanding some font issues. For one, I can't quite get Terminus loaded into rxvt-unicode like I'd like <Cairn>I'm using this line in .Xresources: `URxvt.font: -*-terminus-bold-*-*-*-28-*-*-*-*-*` <Cairn>I'm coming from Arch, and that never seemed to have issues. I do have Terminus installed, but when I use the line `URxvt.font: xft:Terminus:size=28` the output doesn't look like terminus at all. It's all distorted. <Cairn>The first line simply keeps urxvt from loading. The second line outputs a distorted font that might be a really small version of Terminus upscaled? But neither work as expected. <Cairn>A weirder issue is that a lot of numbers and symbols won't load in icecat. Like, they're invisible, even in the URL bar. <podiki[m]>Cairn: the icecat issues sounds familiar, I think you need to have some expected default fonts installed as well (not remembering their names off the top of my head) <KarlJoad>Just as an interesting question/thought experiment, what would be required for Guix to run on a BSD? <Cairn>Let me see if I can find which <Cairn>I can't link to the font heading cause I can't use numbers in the browser yet, haha. But under the font heading, it mentions some essential fonts. I downloaded them all, and it doesn't seem to have fixed the issue <Cairn>Oh forgot to do that, one sec <podiki[m]>hmm...I had a similar issue with numbers not appearing and i think it was font-dejavu that I needed <Cairn>Well there's that issue, thanks podiki. <drakonis>anyways, i think you need shepherd to support bsds? <Cairn>drakonis: What about just Guix the package manager on top of a bsd? <KarlJoad>drakonis: I don't know. I have an interest in NetBSD right now, but the simpler one would probably be FreeBSD. <Cairn>As for the terminal issue I'm having, I found out that fonts.dir exists with terminus. I've tried several of the pre-built font strings there, and each one makes urxvt refuse to book. <podiki[m]>this is common enough maybe it should be part of icecat package or something.... probably worth a bug report if one doesn't exist (unfortunately the nicer debbugs front end it down right now) <Cairn>podiki: I agree, especially since it's listed in the manual as an existing issue, it should just be a dependency <drakonis>it would be an exercise in making guix capable of running on other platforms <podiki[m]>Cairn: and the manual is for on foreign distros, but this is true on Guix System as well <podiki[m]>i'm not sure the mechanics of including or not fonts in packages (and needing the fc-cache), but yes, we should make that smoother <Cairn>drakonis: I can only imagine what a nightmare it would be. <drakonis>plus keeping it running on operating systems can be a challenge <drakonis>its something only worth pursuing if there's people that can maintain it <KarlJoad>My thinking too. But from a theoretical perspective (say we had enough maintenance, support, etc.) how "bad" would it be? <drakonis>there arent a lot of guarantees on whether it'll remain working forever <drakonis>the hardest part is guaranteeing equal support for them <Cairn>This font stuff just won't work with urxvt. I can't understand the issue. <drakonis>if you ever look into something like the ports tree for any of the bsds, you'll see a lot of patches that are specific to them <Cairn>I've pointed xset +fp to the fonts.dir provided by terminus, and xlsfonts lists the font strings I need for Terminus, but when I set one of them with URxvt.font:, it simply refuses to open urxvt. <drakonis>anyways, part of the initial effort would be to split up guix's source tree without making it too complex to have patches for other systems <jackhill>I vaguely remember there being some mailing list threads about this. Of course, Guix already supports two kernels, Linux and Hurd, so the framework is there. And Debian/kFreeBSD is a great project to learn from about what some of the porting effort would be like. <KarlJoad>Cool. So not impossible, but not easy. I do not have the time or skills to do anything like that right now, so it remains a hypothetical. <jackhill>KarlJoad: and the question of is it worth it I suppose depends on why you want to do it. One of my interests in Guix is reproducable (scientific) computations, and my reason to port Guix to a BSD kernel would be to allow scientists who already use those platforms to use Guix to develop and run their computations. <jackhill>Having another kernel in the mix could negatively affect reproducability. Although, if the computations differ, it could be very educational. <nij->Anyone here uses guix pkg manager on macOS? Does it work? <drakonis>requires incredibly nontrivial amounts of effort to support <jab>drakonis: does macOS support/use glibc ? <drakonis>it most certainly does not use a recent version <jab>drakonis: does guile3 compile on macOS? <nij->hmm.. what did the nix community do? I've heard that nix is doing ook there (but it's no lisp, sigh). <drakonis>also a whole different repository for more macos support <jackhill>yeah, I remember looking at all the hoops Nix had to jump through and getting turned off. <jackhill>I wonder if we'd get more bang for our buck with seamless Linux-VM integration, so folks on these other platforms could run `guix` in their native environment, but all daemon, subshells, commands launched would be in the VM. <drakonis>last time this topic came up, that was a good approach to avoid changing too much just for a niche target ***avp_ is now known as avp
<drakonis>i think each of the three bsds has a virtual machine module at this point in time <morganw>I think on macOS there is some kind of container framework that providers use to run build jobs <jab>I've been getting nginx 502 bad gateway errors on issues.guix.gnu.org for a few days now. Anyone else getting that? <dlowe>I haven't been able to get to it <jackhill>jab: dlowe: I believe it's a known problem. <jackhill>nckx`: should we put something in the topic? <podiki[m]>this idea sorta came up on the mailing list, but maybe we need a nice and easy "status.guix." type page to show what's up or not <tissevert>trying to understand search-path-specification but something remains mysterious to me <tissevert>are build environments fundamentaly different from shell environments ? <tissevert>I have a very simple package defining a search-path-specification (files '("lib/SJW")) <tissevert>and two packages with a copy-build-system installing directories there <tissevert>when I open a development shell from a guix package mentioning the 3 packages as native-inputs, the corresponding path variable contains only one folder : /gnu/store/…-profile/lib/SJW <tissevert>when I try to actually build the package and print the path variable from the Makefile, it contains the path corresponding to the 2 copy-build-system packages, separated by ':' <tissevert>I don't understand why the behaviour needs to be different, and I can't figure how to prevent it from being different if that's possible <apteryx>any cheap way (computationaly) to fix my tree following: error: failed to compile 'guix/build/clojure-build-system.scm': ? <apteryx>tissevert: build systems use search paths exclusively; they do not assemble a profile <apteryx>'guix shell' or 'guix environment' do assemble a profile, so instead of having the individual components in the search paths they include just that of the profile <tissevert>apteryx: ok thanks, so it means there is no way out of this and my program looking for this variable should support absolutely lists of paths and not only a single path ? <apteryx>you could also hack a union (faking a profile) in the build system of your tool, but that's ugly compared to simply honoring multiple paths in the search path environment variable of your tool <tissevert>ohhh : / why always the necessity to do things right and support more general stuff ? <tissevert>I liked it when it was expecting a single folder to be its package DB and you could simply put links there ^^ <tissevert>what's the error you get compiling the clojure-build-system ? <apteryx>but I've since run 'make clean-go'... <apteryx>I think it will, I had that same problem in a different tree earlier, and it did <tissevert>that'd be so weird, it looks really serious with a #f instead of a cons <tissevert>I wonder how that can happen with compilation left-overs <apteryx>Guile doesn't do a very good job at tracking macro expansion changes and rebuilding the needed modules <apteryx>(I think it doesn't try at all, actually) <tissevert>well thanks again for the tip about search paths <tissevert>temperature is slowly getting under 28°C so I might be able to get some sleep and I won't miss that chance