IRC channel logs


back to list of logs

<ogey>It does not work . It has the same error
<antipode>ogey: For the upstream bug report, could I have a copy of the top of /proc/cpuinfo (for
<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>processor : 0
<ogey> vendor_id : GenuineIntel
<ogey> cpu family : 6
<ogey> model : 23
<ogey> model name : Intel(R) Core(TM)2 Duo CPU P840 @ 2.26GHz
<ogey> stepping : 10
<ogey> microcode : 0xa0b
<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)
<podiki[m]>or maybe I'm not understanding
<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
<podiki[m]>any reason why you want that git commit
<formbi>no, I just took the latest one
<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
<podiki[m]>formbi: literally today and this week somethings changed
<podiki[m]>although related issue
<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]>so you are right in the mix
<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>yeah, it did build for me now
<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
<formbi>how can I start an agent?
<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`
<podiki[m]>no trailing `
<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 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]>oh nice at least
<podiki[m]>yeah, not sure what dbus/polkit stuff is like to pass on to foreign distro
<podiki[m]>but glad it does work
<podiki[m]>maybe for foreign distro you just need the dbus/polkit rules added as your distro would? just guessing
<formbi>most likely
<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
<ogey>nckx sure
<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
<sneek>crono, you have 1 message!
<sneek>crono, nckx says:
<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?
<atka>sneek: botsnack
<sneek>atka: wb!!
<bullethead>if I run an "guix pull" then "guix system reconfigure /etc/config.scm" is there anything I have to do to update
<bullethead>anything else?
<bullethead>as privildeged user (english not my first language)
<bullethead>I speak mayan, LOL!
***LispyLights is now known as Aurora_v_kosmose
<efraim>dcunit3d: I did something similar trying to make a gparted guix ISO. might give you some inspiration.
<Guest11> gives a 502 Bad Gateway
<muradm>hi guix
<unmatched-paren>hello guix
<Guest11>i'm having troubles getting guix to compile a minimal operating-system (to an image file if that matters) with raspi-arm64-chainloader.
<Guest11>this is my system definition:
<Guest11>this is the error message:
<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?
*muradm reboot...
<Idjustliketointe>Packages cannot upgrade without substitutions after guix pull, this is happening every time
<Idjustliketointe> build of /gnu/store/...-openssl-1.1.1l.drv failed
<Idjustliketointe>Who can suggest what might be the cause?
<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/ 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
<cdo256>ok thanks
<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?
<drakonis>the existing daemon
<muradm>hello guix
<muradm>pulseaudio eat my brain
<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
<apteryx>I don't :-)
<mrvdb>is it intentional that packages for systems are included even if their builds fail on (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.
<mrvdb>on building guix itself from git repo (following to see if I can help fix some packages for ppc, I run into this:
<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
<mrvdb>ekaitz:trying that commit
<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?
<mrvdb>cool, thanks
<ekaitz>try it and ping me back if you have more issues
<mrvdb>will do
<podiki[m]>sneek: later tell PurpleSym for rocm just came across the Arch patches, like maybe there is something in there to enable support for the hardware you have on newer versions? (just saw an update today too)
<sneek>Got it.
<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.....
<ekaitz>mrvdb: glad to help! have fun!
<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>Cairn: (xinitrc) loads .xsession, not .xinitrc:
<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.
<nckx>…really, nckx?
*nckx don't no nothings.
<nckx>Cairn: Possibly helpful: (the title is tongue-in-cheek… I hope.)
<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.
*nckx away.
***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>Ahh, ok
<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
<Idjustliketointe> /QUIT
<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)
<Cairn>Oh hm
<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>podiki: I found this:
<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
<podiki[m]>did you update fc-cache?
<Cairn>Oh forgot to do that, one sec
<Cairn>Yep, issue persists
<drakonis>KarlJoad: which one?
<Cairn>One sec, forcing
<podiki[m]>hmm...I had a similar issue with numbers not appearing and i think it was font-dejavu that I needed
<Cairn>Aha! `fc-cache -r` did it
<Cairn>"really force" lol
<Cairn>Well there's that issue, thanks podiki.
<drakonis>anyways, i think you need shepherd to support bsds?
<podiki[m]>Cairn: great!
<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>Cairn: could work?
<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
<Cairn>Ah, ok
<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>the issue is the burden of maintenance
<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>not effortless though
<drakonis>there arent a lot of guarantees on whether it'll remain working forever
<drakonis>also patching things to support it
<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.
<jab>hey guix!
<nij->Anyone here uses guix pkg manager on macOS? Does it work?
<drakonis>hasnt been done yet
<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?
<drakonis>frankly, i have no idea
<nij->hmm.. what did the nix community do? I've heard that nix is doing ook there (but it's no lisp, sigh).
<drakonis>lots of hacks.
<nij->i see
<drakonis>they have dedicated macs for building
<drakonis>also a whole different repository for more macos support
<jackhill>nij-: for guile:
<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.
<avp_>Hello Guixers! I've sent a patch to Guix that adds "Qucs-S" -- an electonic circuit simulator GUI for different simulation kernels:
<drakonis>that could work
<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
<drakonis>macs probably have something? maybe?
<apteryx>avp: thanks, sounds interesting
<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 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]>if people will read it ;-)
<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>hi guix
<tissevert>trying to understand search-path-specification but something remains mysterious to me
<tissevert>are build environments fundamentaly different from shell environments ?
<tissevert>and if so, why ?
<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
<tissevert>any clue anyone ?
<apteryx>any cheap way (computationaly) to fix my tree following: error: failed to compile 'guix/build/clojure-build-system.scm': ?
<apteryx>i.e. not 'make clean-go && make'
<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
<arescorpio>window manager failuture ( for my )
<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>that'd be more useful indeed
<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>but I suppose I'll have to do it : )
<tissevert>what's the error you get compiling the clojure-build-system ?
<tissevert>is it the usual ABI-mismatch stuff ?
<apteryx>no, it's not clear cut like this
<apteryx>it looked like:
<apteryx>but I've since run 'make clean-go'...
<tissevert>and that fixed it ?
<apteryx>I think it will, I had that same problem in a different tree earlier, and it did
<apteryx>still building...
<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>ah ^^
<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
<tissevert>see you later
*vagrantc waves
<abhicherath[m]>How do i apply this patch:
<abhicherath[m]>I need go 1.18, not sure how to get it