IRC channel logs

2021-07-08.log

back to list of logs

<dstolfa>jackhill: so what you're bumping into is this https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/services/ssh.scm#n191
<jackhill>dstolfa: yes, I believe so
<dstolfa>obviously, this could be changed, but there's a certain benefit to providing virtual services, namely that users (and guix) could swap out defaults easily
<jackhill>yeah, I don't object to that. Maybe it would be nice have a procedure that modifies what a services a service provides
<dstolfa>there is one already :)
<vagrantc>efraim: oh, that's much further along!
<dstolfa>jackhill: see (modify-services ...)
<jackhill>dstolfa: oh? oh, I should read more carfully!
<jackhill>(and type more carefully too :))
<civodul>hmm binutils-mingw-w64-timestamp.patch does not apply to binutils-2.36.1 on core-updates, and it's not clear whether it's still needed
<civodul>dongcarl, janneke: WDYT? ↑
<sss1>hi all, does guix have adwaita theme for qt5 ?
<drakonis>qgnomeplatform?
<drakonis>or adwaita-dark?
<drakonis>the former? definitely not
<ngz>darth-cheney: If you're interested, I can share some configuration parts relative to "colmun view".
<darth-cheney>b
<rekado_>FYI the honeycomb boards I ordered a while ago are expected to arrive “end of July”
<cbaines>that's good :)
<cbaines>I got given a number of estimated delivery dates before the one I ordered finally shipped, but hopefully they've got their production issues sorted now
<bmk>Is there a package I need to grab for A2DP Bluetooth audio? Or is that non-free.
<sss1_>drakonis: i want to have uniform dark view for both qt and gtk, it was done via adwaita-dark + adwaita-qt on my old system, but i can use something different, i only need same of similar dark theme for both qt and gtk apps, i currently mixed my base (exherbo) system + nix + guix, nix does have adwaita-qt package, but looks like qt version from guix is not ompatible with this plugin, so style plugin
<sss1_>does not work, also plugin from my host systems also is not compatible (
<bmk>I mean, I suppose you could locally install a GTK theme and set QT to use GTK
<bmk>That's how I usually get a consistent look.
<sss1_>how can i do it nowdays ?
<sss1_>i have done this before, some time ago, like 5-10 years, unfortunately i have not remember much (
<bmk>Okay, you can download the files of a GTK theme, and place it in a directory in your home folder called .themes
<sss1_>it's done, gtk apps looks ok
<sss1_>i just stick with default adwaita-dark
<sss1_>wwhich is suffice
<bmk>Then depending on how you set your QT theme, you should set the plugin type to "GTK2"
<sss1_>2 ? or 3 ?
<bmk>Which WM are you using?
<sss1_>awesome
<bmk>QT doesn't have a GTK3 plugin, iirc, so you use GTK2 and it renders using GTK
<sss1_>it's ok
<sss1_>gtk2 also have sane look
<bmk>Uhh, I believe what you need is called QT5CT
<sss1_>it's done
<bmk>unless you have a preferred method
<bmk>Oh, it's all good? Nice
<bmk>Anyone have experience with A2DP Bluetooth audio on Guix? Or is that non-free?
<sss1_> https://i.imgur.com/psEQ14l.png
<sss1_>as you can see on screenshot, problems occurs only with guix apps
<sss1_>but i do not have currently qstyleplugin for gtk2
<sss1_>on screenshot you can see burning white style for flameshot and kwrite )
<sss1_>on the left gmpc which is gtk2/vala app
<bmk>Yeah, it's QT that's playing up here
<bmk>Did you set the enviroment variable for QT5CT and relogin?
<bmk>Let me check my .xinitrc from my other machine
<sss1_>yes, as you can see qt5ct itself and keepassxc does have proper style, but
<sss1_>as i said, it's adwaita-qt style
<sss1_>first of all i need to know how qt<>gtk style called
<bmk>okay, is QT_QPA_PLATFORMTHEME set to "qt5ct"?
<sss1_>yes
<sss1_>without it qt5ct and keepassxc will use default style
<bmk>okay
<bmk>Apparently that's at build configured
<sss1_>hm....
<bmk>QT_NO_STYLE_GTK may be set by default
<sss1_>i belive i have installed adwaita for gtk2/3
<bmk>so if you rebuild with that as false it should show up in QT5CT as GTK+ style
<bmk>add -gtkstyle to your build options should take care of it
<sss1_>question is, how to do all this for guix apps
<sss1_>i am realtively new user to guix
<sss1_>so may lack knowledge even in basic stuff
<bmk>guix edit qtbase, and see the section where it appends abunch of strings to configure?
<sss1_>it does have gtk module enabled
<sss1_>at leeast i see dependency
<bmk>Okay, I apologize, I'm not sure how I could explain this well over IRC
<bmk>Sorry
<sss1_>at least it does not have explicitly disabled
<sss1_>for sure
<bmk>It's not the dependency, it's like in the configure build options portion
<sss1_>yes yes, it is not aenabled, but also not disabled
<sss1_>so i guess qt configurator will stick to autodetect
<bmk>You'd need to enable that and rebuild
<bmk>The build of qt won't error out if it's not explicitly enabled and it can't build gtk
<sss1_>it's cmake option ?
<bmk>it's an option passed when running ./configure
<sss1_>ah, no, it does use bundled configure script ...
<sss1_>ok, and how can i made my changes persistent ?
<bmk>okay, save that file somewhere else
<bmk>and you can guix package -f /path/to/file
<sss1_> https://github.com/qt/qtbase/blob/dev/configure - i do not see anything about gtk
<bmk>To be fair this was off the top of my head: I'm sorry if I was wrong
<sss1_>ok ok
<sss1_>thx anyway
<sss1_>and any chance to have adwaita-qt style plugin in guix ?
<sss1_>also
<sss1_> https://bpa.st/ZEBA
<sss1_>and seems guix currently use qt6 as default
<sss1_>ok, thx for help anyway
<sss1_>funny
<MysteriousSilver>Hello! compiling a package returns cairo.h not found, how do i fix it? I have installed cairo cairo-xcb and cairomm
<lispmacs[work]>MysteriousSilver: you might confirm that cairo.h is at ~/.guix-profile/include/cairo/cairo.h for starters
<lispmacs[work]>when compiling stuff, I usually won't install the library in my profile, but instead us "guix environment --ad-hoc cairo" e.g.
<lispmacs[work]>and compile from within that environment
<lispmacs[work]>for convenience, but then also you don't have to wonder if environment variables have been properly set yet in your terminal
<lispmacs[work]>another big question would be what build system the code is using and how it looks for library paths
<lispmacs[work]>in a simple Makefile based program you might have to edit variables in the Makefile. But autotools based system will usually figure things out
<MysteriousSilver>~/.guix-profile/include/cairo/cairo.h exists and it uses the cmake build system
<lispmacs[work]>I don't know too much about cmake, sorry
<lispmacs[work]>If it were me, I would probably be looking at cmake --help, and then also checking with pkg-config to see if include paths are detected by pkg-config
<lispmacs[work]>after trying guix environment
<lispmacs[work]>I would also be using the "env" command to see what directories were in my include path
<MysteriousSilver>ok, will try it
<lispmacs[work]>MysteriousSilver: I think what this might come down to is that the source code is looking for "cairo.h", while the header is in "cairo/cario.h". I have in the past had to edit some code include statements to fix that sort of problem
<MysteriousSilver>Yeah, that might be the case. I'll try some minor tweaks to the source.
<podiki[m]>MysteriousSilver: what package btw? does it use gobject-introspection?
<MysteriousSilver>audacity, not sure
<podiki[m]>apteryx drakonis: we discussed libglvnd before and I was looking more into it with that Mesa update. Mesa has had libglvnd support for a while, we could enable it. But then I think everything that needs GL should use libglvnd as input
<drakonis>worth testing it out
<podiki[m]>but seems like that would be a good idea? anyway, at this point I think we can just use libglvnd as input everywhere if we want to go that route
<podiki[m]>I did it for the updated mesa, builds fine, dependencies should then use libglvnd (which I did for some, but wasn't about to do all)
<podiki[m]>I didn't run anything though, as on a foreign distro currently
<drakonis>i see
<podiki[m]>yeah so I'm not sure how that works when you run something, but for building works
<wirez>anyone move to guix from a bsd? why and how you like it?
<apteryx>podiki[m]: cool, sounds worth investigating. Does it provide immediate benefits? Or it's just the first piece of the puzzle?
<podiki[m]>apteryx: not sure, everything I learned about libglvnd I learned today :-P
<podiki[m]>but it should mean everything wanting GL can just use that, letting libglvnd handle which vendor implementation is to be used (not sure in guix how that works or what it means, especially without non-free stuff)
<apteryx>podiki[m]: we'll have to study what nixos did, I feel there's probably be something guix-specific to be done to make it fully work
<vagrantc>there being no good global defaults for GL ... that sounds promising ... but also gets into weird issues where you need some-gl-backend in your profile and maybe exporting some variable or something
<podiki[m]>right, something to expose the actual GL implementation available; using libglvnd for everything would be a starting point to that handoff
<vagrantc>it reminds me of fonts ... some packages "work" without fonts, but miss a *lot* ... but exactly which font you need to use is somewhat up to you
<podiki[m]>Mesa would always be available and a fallback no? or at least I'd assume, given how much is built on top of it
<vagrantc>really depends how libglvnd is designed
<podiki[m]>superseding mesa I think is where it gets tricky (e.g. non-free drivers that want their own gl used)
<vagrantc>that's easy in guix; non-free drivers aren't supported! :)
<podiki[m]>:-P
<podiki[m]>so I wonder what the free-only instances are where libglvnd is the solution (different hardware at different times? cross compiling?)
<vagrantc>which GL implementation should be default on arm platforms vs. x86 tends to be pretty different
<podiki[m]>now that I think about it, vulkan is a parallel problem no? there you have a vulkan loader to handle which vulkan implementation is used at runtime
<Aurora_v_kosmose>That Laminar program looks pretty interesting.
<Aurora_v_kosmose>It's a bit less friction to get up & running than cuirass, if naturally a bit more limited.
*Aurora_v_kosmose found yet another neat thing in the Guix manual.
***Kimapr2 is now known as Kimapr
<the_tubular>wirez, you should probably compare guix to another distro. guix use the linux as the kernel, like all the other distribution.
<the_tubular>Well, guix uses linux-libre
<efraim>which error is 137?
<efraim>ok, so looks like my build of julia on aarch64 was oom-killed after 32 hours
<wirez>the_tubular: ya but like maybe switching from a bsd to guix on a server couldn't handle the traffic or on the desktop this or that was improved
<wirez>i already know guix is the best linux distro
<wirez>seems like only thing bsd has on guix is freebsd root on zfs
<the_tubular>It shouldn't be that far off
<the_tubular>Also, yeah you got all the positive of the linux kernel and also the negative
<jonsger>when does CI pick up building core-updates?
***Kimapr5 is now known as Kimapr
<wirez>the_tubular: how far off you think rock solid guix root on zfs is?
<mothacehe>hey guix!
<wirez>ayo
<MysteriousSilver> http://ix.io/3shp Any idea why this fails?
<nckx>MysteriousSilver: You're doing the equivalent of ‘(audacity)’ somewhere in /tmp/audacity.scm, i.e. calling the package record as a procedure.
<MysteriousSilver>okay, i'll just remove the define-package and (package-name) thingy and it should work
<tissevert>hello guix
<nckx>Hi tissevert (and mothacehe).
<tissevert>o/ nckx
<MysteriousSilver>While defining packages, how do i know which module defines a variable?
<tissevert>guix search shows the file for each package in its results
<MysteriousSilver>:D
<tissevert>hmm, but maybe the variable you're talking about isn't a package ?
<MysteriousSilver>it is, but i thought it isn't, earlier
<tissevert>that's great : )
<MysteriousSilver>But, what should i do for stuff like search-patches?
<tissevert>« search-patches » ? I don't know what that is, but for everything that's not a package, I guess I would frantically grep $GUILE_LOAD_PATH (-R, not -r, because symlinks)
<MysteriousSilver>`echo $GUILE_LOAD_PATH | sed -s s/:/\\n/g | grep -R search-patches`?
<tissevert>huuh… ? ah I get it search-patches is the name of your variable
<tissevert>hmm that's funny your GUILE_LOAD_PATH actually has several components ?
<tissevert>here it's just a shortcut for /run/current-system/profile/share/guile/site/3.0 which I always forget
<MysteriousSilver>yeah
<tissevert>so yeah I guess it doesn't come out as handy as I expected it to be ^^
<tissevert>good news is, there are plenty of occurrences
<tissevert>so maybe it's not that hard to find
<tissevert>I'd also give a search to guix manual
<tissevert>in case it's explained there how to include it
<tissevert>sounds like a base function of guix
<tissevert>given the header in gnu/packages/webkit.scm which has one occurrence
<tissevert>I'd expect it to be in one of the less «specialized» includes so I don't know, maybe (gnu packages), (guix packages) or (guix utils) ?
<MysteriousSilver>is it due to a missing module or a improper package definition?
<tissevert>what is ?
<nckx>search-patches is defined in (gnu packages).
<nckx>If you develop in a git checkout you can just grep for ‘(define.* variable’, it's extremely reliable.
<MysteriousSilver>ah, now it works
<tissevert>ahah knew it ! : )
<MysteriousSilver>nckx: '(define.* variable' returns zero results for python-node-semver, any idea why?
***Kimapr8 is now known as Kimapr
<tissevert>MysteriousSilver: neither does greping python-node-semver directly, and I can't find it either in guix search, what makes you think this variable is defined ?
<MysteriousSilver>`guix import` had it
<tissevert>guix import ? hmmmm no I think it generates packages using formal rules, I don't think it can make sure all the dependencies it finds do exist
<tissevert>it might just mean you've gotta define it as well
<tissevert>(by importing, again, but I thought there was a way to make it recursively)
<tissevert>guix import pypi --help
<tissevert>there you go, -r, --recursive
<MysteriousSilver>it reports 'no source release'
<MysteriousSilver>huh
<nckx>Horrible.
<nckx>You'll have to package it from source using https://github.com/podhmo/python-semver.
<wirez>what's horrible?
<nckx>Providing only binary wheels.
<tissevert>: )
***xgqt_ is now known as xgqt
<raghavgururajan>Hello Guix!
<nckx>Hi raghavgururajan.
<PurpleSym>I’m seeing a weird error when using pygit2 from guix: ImportError: /gnu/store/4gffr26pb2zpasncanbp2ibamg1c5ms6-openssl-1.1.1k/lib/libssl.so.1.1: undefined symbol: EVP_idea_cbc, version OPENSSL_1_1_0
<efraim>can I use wrap-script to wrap with PYTHONPATH and with PATH?
<nckx>Yes.
<efraim>so (wrap-script <script-file> `("PYTHONPATH" ...) `("PATH" ...)) ?
<nckx>Looks good.
<wirez>guix have a rdp server?
<nckx>I don't think so.
<apteryx_>wirez: we have SPICE though
***rt is now known as robin
<apteryx_>perhaps its service needs new options exposed for configurablity though
***apteryx_ is now known as apteryx
<wirez>what's spice?
<nckx>apteryx: Server?
<raghavgururajan>Is it advisable to patch program path as /run/setuid-programs/program? as that path is not available on foregin distros.
<nckx>wirez: Remote display protocol similar to RDP but without the Microsoft baggage.
<wirez>is it still being updated or has it stagnated like vnc?
<wirez>updated, evolving
<raghavgururajan>wirez: There is remmina.
<raghavgururajan>Oh server, nvm.
<nckx>It's pretty stagnant TBH.
<nckx>But I don't know if that means unmaintained or just ‘stable’. It's definitely used in current products.
<raghavgururajan>For example, sudo. Should we patch it to /run/setuid-programs/sudo?
<mothacehe>civodul: hey! Would it be OK to push Maxime's bash-minimal/wrap-program series on core-updates? I'm currently rebasing it.
<mothacehe>Congrats for your recent fixes on that branch btw :)
<civodul>mothacehe: hey!
<civodul>yes we have a new evalution building stuff! https://ci.guix.gnu.org/eval/59144
<civodul>i think i haven't looked at the bash-minimal/wrap-program series
<mothacehe>it adds the bash-minimal input for every package that use wrap-program basically, in order to fix running cross-compiled wrappers
*civodul takes a quick look
<civodul>i had one comment on #5 (maybe applicable to other patches as well?), but overall it looks reasonable
<civodul>one thing that's slightly annoying is that "guix style" by default won't touch all these inputs due to the label/package name mismatch ("bash" vs. "bash-minimal")
<civodul>so we'll have to check them manually
<nckx>raghavgururajan: Depends on why (mainly: if) it needs to be patched in the first place.
<nckx>It's better if the software just respects $PATH.
<raghavgururajan>nckx: If unpatched, the app won't pickup sudo from /run/setuid-programs, when run in --pure or container right?
<mothacehe>civodul: Thanks. We could use "bash" to ease the transition but it potentially adds 12MiB to each package closure
<nckx>Oh dear, feature or bug. Hm.
<nckx>raghavgururajan: That's true. But that doesn't imply that patching it is good.
<civodul>mothacehe: no that's ok, it's not the end of the world
<civodul>"guix style" has an option to convert safe-but-rebuilding things
<civodul>so it should be okay in the end :-)
<nckx>raghavgururajan: You can manually set up the environment so PATH does point to the right sudo instead of the impotent one. If that's considered unreasonably esoteric the fix would be in guix environment, not patching software that arguably does the right thing.
<nckx>The real bug is: the broken sudo in a container is surprising to users.
<civodul>in other news, i got this unhelpful but interesting reply: https://sourceware.org/pipermail/libc-alpha/2021-July/128699.html
<civodul>could it be that our cross-compiler "-print-prog-name" option is broken?
<raghavgururajan>nckx: Hmm, okay.
<raghavgururajan>Btw, is there a way to find whether a program needs to be setuid root?
<civodul>mothacehe: since you have experience with embedded devel, cross-toolchain and all :-), do you know if known-good toolchains have things "aarch64-linux-gnu-gcc -print-prog-name=objdump" return the right thing?
<nckx>raghavgururajan: Good question! I wonder how reliable a ha^Wheuristic something like ‘objdump -T $(which sudo) | grep set[gu]id’ would be…
<nckx>Although I suspect the matter is too sensitive to leave to even an accurate one.
<raghavgururajan>I see.
<nckx>raghavgururajan super convinced one can tell.
<mothacehe>civodul: the debian GCC aarch64 cross-toolchain returns: /usr/lib/gcc-cross/aarch64-linux-gnu/8/../../../../aarch64-linux-gnu/bin/objdump
<mothacehe>which it is different from our output, but could tell you more about it.
<mothacehe>*couldn't
*raghavgururajan moves-on to next stuff xD
<raghavgururajan>So jgart and I are gonna kickstart gnome work again.
<nckx>That's wonderful.
<nckx>Give the people what they want!
<holzkristall>Hey, I've used guix in my main device for quite some time, and I have grown to love it. Since I am now trying to improve my security, I wondered if I could enable some kind of MAC (preferably SELinux)?
<holzkristall>The other option I have would be to use something like parabola, but Guix has been amazing so far ;-;
<dstolfa>holzkristall: does this help? https://guix.gnu.org/manual/en/html_node/SELinux-Support.html
<holzkristall>> Since Guix System does not provide an SELinux base policy, the daemon policy cannot be used on Guix System.
<holzkristall>Ah, a shame. Maybe there are other solutions, I'll keep looking. Thank you dstolfa though[
<holzkristall>!"
<nckx>holzkristall: To clarify: it's not a fundamental limitation of Guix. It could be written but it needs (a) champion(s). Not saying you should feel obligated, but it's not something that's going to be implemented on a rainy afternoon by someone bored.
<leoprikler>oh, but what if it's sunny and 40°C outside and you really have to stay inside so as to not die?
<dstolfa>speaking of dying and not dying... is anyone dying to review some patches regarding a rust package? (:
<holzkristall>I'd love to if I had the expertise - I tried to make a profile/role on CentOS for a web server but even that failed miserably ^^'
<holzkristall>Maybe some day :)
<holzkristall>But wouldn't that champion need to write the profile for *every* (at least more relevant) package?
<leoprikler>for the first roll-out probably yes
<leoprikler>I don't think there's a way to cheat SELinux in only doing half of the things
<mason>Half the things?
<mason>You can leave things unconfined by default if you want to implement policies slowly.
<mason>That said, if you're looking for a MAC, AppArmor might be a bit more approachable and it lends itself to piecemeal deployment.
<civodul>mothacehe: ah, so their GCC package must somehow copy "TRIPLET-objdump" under gcc's $libdir as "objdump"
<civodul>hmm
<holzkristall>mason: Thanks for the idea, but afaics Guix also does not support Apparmor
<mason>Right, but if you're starting from scratch, you have options.
<bmk> I managed to get A2DP working: Turns out it was just my headphones being
<bmk> funky, or installing bluez-alsa that did it
***moo[m]1 is now known as moo5-0[m]
<bmk>anyone doing some interesting hacky things today?
<holzkristall>mason: True. I bet that with the way guix system is set up, any MAC could have a lot of potential, the question is if role or path based makes more sense
<bmk> https://www.ebay.ie/itm/224521425076?hash=item34468510b4:g:gGUAAOSwoA1gkvA9
<bmk>I'm so considering this right now
<ngz>Ooooh a Lenovo from before the PrScr-key-on-space-row era.
<bmk>See, while I'd like to have an entirely free software computer
<bmk>I'd also like to have money for college
<bmk>Oh yeah, I should grab my FSF member cloak sometime
<apteryx>civodul: seems proot-static fails to build for aarch64-linux, breaking -RR on this platform
<apteryx>./execve/enter.c:335:36: error: ‘EXEC_PIC_ADDRESS’ undeclared (first use in this function)
<darth-cheney`>Hey all, I have perhaps a dumb question, but if I'm writing a config and I'm using a git-reference as the source, how do I compute the sha256?
<dstolfa>darth-cheney`: doesn't `guix hash` do what you want?
<darth-cheney`>Yeah but what am I hashing? A repo is a whole directory
<darth-cheney`>Am I meant to just do a recursive hash of everything?
<dstolfa>darth-cheney`: i think so yes, but i'm trying to find the info page that explains it in detail
<darth-cheney`>dstolfa: ok thanks
<dstolfa>darth-cheney`: does this help https://guix.gnu.org/cookbook/en/html_node/Extended-example.html
<darth-cheney`>dstolfa: yes it's in there, thanks!
***niko is now known as o
<zacchae[m]>Hmm, just updated my everything, and now pasystray is broken. Before I make a bug report, is anyone else having this problem? It says it can't find icons then segfaults.
<Noisytoot>Is there a ZNC service type for Guix?
<raghavgururajan>nckx: Before you started to use wayland+sway, do you still configuration to start xorg without display-manager?
<raghavgururajan>Anyone else here starts Xorg without display-manager?
<nckx>raghavgururajan: No, I used lightdm.
<raghavgururajan>Ah I see.
<nckx>Noisytoot: No.
<Noisytoot>How do you start ZNC?
<nckx>Sorry, I mean 🌈 not yet!
<nckx>Very much by hand.
<nckx>Much tech, very high available.
<podiki[m]>raghavgururajan: still on a foreign distro, but for a long time I didn't use a displaymanager (just startx with an .xinitrc, in fact I now run xinitrc as an xsession still, just through lightdm)
<raghavgururajan>podiki[m]: Thanks!
<podiki[m]>I liked it and still kinda do it that way cause I was never sure what the displaymanager was doing with environment variables, what it sourced, etc.
<podiki[m]>and since I wasn't launching a full desktop environment, just a windowmanager (i3, stump, xmonad)
<raghavgururajan>Oh we don't have lightdm-service. I thought we had for some reason.
<raghavgururajan>podiki[m]: I see. I just wanted to lauch dwm using startx.
<raghavgururajan>Is it possible to run `startx dwm` using shepherd-user-service?
<podiki[m]>not sure on guix, but otherwise startx will run your ~/.xinitrc as a script, so the last line should be something like "exec dwm"
<raghavgururajan>I see.
<raghavgururajan>Thanks for the pointer.
<podiki[m]>the default file normally lives in `/etc/X11/xinit/xinitrc`
<podiki[m]>but basically it sets some resources/variables and starts your WM
<podiki[m]>mind should still work as a standalone startx (again, not on guix so I can't comment there), but you can see it here: https://github.com/podiki/dot.me/tree/master/x11
<raghavgururajan>Thanks.
<podiki[m]>hope it helps! (and as one looking to put guix on my desktop after upgrades, do report back any guix-specific things you need to do)
<raghavgururajan>Sure thing. I am testing on VM.
<raghavgururajan>Which is the appropriate file to place this line `source /run/current-system/profile/etc/profile.d/nix.sh`? ~/.bashrc or ~/.bash_profile ?
<dstolfa>raghavgururajan: how is gnome 3.40 coming along? :)
<raghavgururajan>dstolfa: jgart and I are gonna kick-start the work again. Help is welcome.
<dstolfa>raghavgururajan: i don't really have time to help with the code itself, but i'm happy to give it a test run whenever you think it's ready!
<dstolfa>i've started working on `guix bisect` so that will be occupying my guix time for now :D
<raghavgururajan>dstolfa: Sure thing, I;ll let you know.
<raghavgururajan>Ah nice!
<civodul>mothacehe: looks like armhf-linux is no longer enabled for core-updates, which leads to a surprisingly high success ratio :-)
<civodul>ok if i re-enable it?
<nckx>raghavgururajan: .bash_profile.
<raghavgururajan>nckx: Ah. I was using it on bashrc and it was polluting my --pure env.
<raghavgururajan>Thanks!
<nckx>Yep, that's the result.
<raghavgururajan>nckx: Even when placing in .bash_profile?
<mothacehe>civodul: hehe, sure go ahead
<mothacehe>48%, so great!
<mothacehe>it was only 10% a few days ago
<leoprikler>raghavgururajan: no, bash_profile should not pollute pure environments
<raghavgururajan>Ah thanks!
<raghavgururajan>Same with ~/.profile as well?
<leoprikler>yup
<raghavgururajan>Hmm. I just noticed that ~/.profile is not specified anywhere, to be called.
<dstolfa>.5
<dstolfa>oops
<dongcarl>civodul: Hey! Is there a reason why you think binutils-mingw-w64-timestamp.patch might not be needed in binutils-2.36.1? It seems like they still don't respect SOURCE_DATE_EPOCH and needs patching
<dongcarl>The debian patch was updated for 2.35 and works when applied to 2.36.1 (after changing diff headers): https://salsa.debian.org/mingw-w64-team/binutils-mingw-w64/-/blob/master/debian/patches/specify-timestamp.patch
<Noisytoot>Which file would a ZNC service go in?
<roptat>maybe a new irc.scm file?
<raghavgururajan>Any one uses gpg-agent as ssh-agent on guix system? I am looking for configuration.
<nckx>ZNC is in messaging.scm.
<Noisytoot>Why is it not in irc.scm?
<roptat>because irc is a subset of messaging
<nckx>Because arbitrary probably-non-reasons. My point was merely that there's a messaging.scm in gnu/services/ already.
<nckx>roptat's right but then gnu/packages/irc.scm does exist 🤷
<Reinhilde>is guix' /etc/rc written in scheme?
<roptat>I'm thinking maybe irc.scm was created after znc was added
<roptat>but there's not always a good reason why a package is in a given file and not another
<drakonis>Reinhilde: yes
<drakonis>shepherd is scheme
<Reinhilde>drakonis: wh O:
<drakonis>i see you're checking out guix lol
<drakonis>the docs are good btw
<drakonis> https://guix.gnu.org/manual/en/html_node/Shepherd-Services.html for defining shepherd services
<apteryx>civodul: proot 5.2.0-alpha seems to build on aarch64-linux. I'll prepare a patch.
<drakonis>Reinhilde: why the sudden interest?
<Reinhilde>idk, i'm just idling here and i saw a discussion about a thing
<drakonis>ah i see
<drakonis>well, its a pretty great thing i guess
<Reinhilde>It seemed like .scm files were being described in the context of what i from freebsd-land would call /etc/rc
<drakonis>yes that is a thing
<dstolfa>yeah, shepherd is written in guile and all services are described in guile
<drakonis>scheme everything, scheme everywhere.
<mason>It's a bold scheme.
<drakonis>indeed
<Reinhilde>ah
<dstolfa>though... "service" in guix is quite a bit more than what people traditionally think of as a service
<drakonis>a service is more like a task, one could say
<drakonis>it doesnt have to run a daemon
<Reinhilde>aye
<dstolfa>and often (but not always) will produce some stuff in the store
<drakonis>also cron is in scheme
<drakonis>cron being in scheme is great.
<drakonis>you'd be surprised at how useful it is to have all of this be scheme libraries
<Noisytoot> https://www.gnu.org/software/mcron/
<drakonis>still waiting for the day i can embed the coreutils inside builds using scheme functions
<mbakke>drakonis: you mean like gash-utils? https://git.savannah.nongnu.org/cgit/gash/gash-utils.git/tree/gash/commands
<drakonis>yes
<raghav-web>Damn! Starting X server without a display-manager on guix system is harder than I thought.
<raghav-web>This is the error message after running `startx`: https://paste.debian.net/plain/1203834
<raghav-web>iyzsong: You around?
<nckx>Running xinit's startx script has never worked (maybe it should be deleted?), creating your own ‘startx’ with the value of (xorg-start-command) used to, years ago, at least.
<Noisytoot>Running "make" on master fails: "error: failed to load 'gnu/tests/install.scm':
<Noisytoot>ice-9/eval.scm:293:34: In procedure abi-check: #<record-type <kmscon-configuration>>: record ABI mismatch; recompilation needed"
<raghav-web>nckx: I see. We have a new xorg-server-service-type. It uses xorg-configuration as default value, but I don't see any /etc/X11 dir created.
<nckx>Noisytoot: You need to remake Guix. ‘make clean-go && make’.
<nckx>raghav-web: Why would it be?
<raghav-web>nckx: /etc/x11/xinitrc would contain default values for fonts, keyboard etc?
<nckx>If you say so. Doesn't sound familiar.
<vagrantc>i think i got startx working by making several things setuid root or something
<nckx>raghav-web: But… why?
<vagrantc>but then i found "sway" and happily switched to it instead as it "just works"
<nckx>Oh, running ‘$ sudo startx’ is implied in everything I said above. ‘$ startx’ has never worked AFAIK.
<nckx>Hipster gen-Z'ers with your rootless X'en.
<vagrantc>pretty sure startx as a regular user worked if you had enough things marked setuid
<raghav-web>hmm.
<nckx>Of course, but then you're manually changing stuff at that point.
<vagrantc>manually, as in my system configuration?
<nckx>Has never worked *in Guix*.
<nckx>Works fine in some other distros and if you manually change enough stuff in Guix, probably.
<vagrantc>basically used the same technique used for screen lockers, but with X itself and a few more binaries
<vagrantc>on guix
<vagrantc>Guix System, fwiw
<vagrantc>but ... that information is lost to time because sway works much easier. :)
<nckx>I wonder if this was before or after me, because I added $all_of_x to setuid-programs and it still didn't work.
<vagrantc>maybe you actually did $all_of_x_but_oops_missed_a_spot
<vagrantc>and it wasn't just X ... it was other random things ... it was tedious
<MichaelRaskin>I think setuid shell scripts do not work like you'd expect
<vagrantc>did i mention i like sway? :)
<jackhill>Hi, I'm trying to add swap-on-lvm. I've added (swap-devices (list "/dev/mapper/guix_vg0-swap")) to my config.scm, but when I reconfigure I get guix system: error: service 'swap-/dev/mapper/guix_vg0-swap' requires 'device-mapping-guix_vg0-swap', which is not provided by any service. Presumably I need to created a mapped device, but where?
<vagrantc>i really need to wrap my head around mapped devices and guix so i can use lvm again
<mroh>raghav-web: maybe, https://github.com/alezost/xdaemon (and his shepherd conf) could also be helpful.
<jackhill>heh, this is on an experiments vm so I can learn how it works :)
<raghav-web>gnu/services/xorg.scm has xorg-wrapper and xorg-start-command defined. But how do I use it?
<raghav-web>Also, this thread (https://lists.gnu.org/archive/html/help-guix/2018-07/msg00080.html) seems to be useful.
<drakonis>MichaelRaskin: strange seeing you here
<jackhill>My full config is https://paste.debian.net/1203836/ which does have a (targets (list "guix_vg0-swap" "guix_vg0-btrfs"))
<vagrantc>jackhill: surely you need another mapping layer in there, maybe some raid? :)
<mroh>jackhill: try adding `(mapped-devices (list (mapped-device (source "guix-vg0") (target "vg0-swap") (type lvm-device-mapping))))` to your oparation-system or so and use that in the swap definition.
<jackhill>mroh: no luck, same error (well now with the new name) https://paste.debian.net/1203839/
<jackhill>mroh: ah, I switched from using the /dev/mapper path to a uuid, and reconfigure is proceeding now
<mroh>jackhill: yay, good luck for the reboot! ;)
<nckx>…sorry, got called away. Thanks for that info vagrantc, that's great (if old) news; I've discussed this with ~5 people over the years and nobody ever reported your success.
<jackhill>second question: with the same configuration, reconfigure prints out 'guix system: warning: mapped-device '/dev/vda1' may not be mounted by the bootloader.' But everything seems to work. At least I can decrypt the disk and boot up. Is there a way to silence the warning? Parhaps I should try uuid there as well.
<jackhill>mroh: thanks!
<nckx>What's the cut-off point for CPU instructions again?
<nckx>Core 2?
<mroh>afaik, up to sse2 (including), so yes core 2, i guess.
<jackhill>mroh: yes, seems to work!
<jackhill>I would like to get the "warning mapped device may not be mounted" message to go away, but that's not a big deal. With the message there, it just feels like I'm doing something wrong :)
<nckx>mroh: Thanks.
<jackhill>nckx: have you done suspend-to-disk inside lvm/luks? with my resume=PARTUUID=foo linux cmdline, it looks for the memory image before decrypting the disk
<nckx>No.
<nckx>The current code does not handle encrypted swap at all.
<jackhill>ah, I see :) So this would be a change in our initramfs?
<nckx>Yep.
<nckx>boot-linux IIRC.
<nckx>* boot-system.
<jackhill>ok
<jackhill>thanks
<nckx>Try moving the whole resume-if-hibernated unless-block under the call to pre-mount.
<nckx>I think the mkdir /root block should be moved immediately before the setenv because pre-mount has no business mounting anything and would now corrupt hibernated file systems if it did.
<nckx>And of course don't forget to water your backups before you resume.
<jackhill>nckx: thanks for the pointers. I'm probably not going to get into it right now, but I'll add it to heap of things to fiddle with
<tricon>Would Asterisk's dual-license (one being GPL2) prevent it from being accepted into the official Guix channel?
<roptat>mh, on a foreign distro, doing "guix environment guix --pure, make clean, ./bootstrap, ./configure --localstatedir=/var, make, ./pre-inst-env guix help" -> "In procedure load-thunk-from-memory: incompatible bytecode version"
<roptat>I had to fight with --pure until I understood that by default /etc/bashrc loaded /etc/profile.d/*.sh
<roptat>but now I'm sure guix environment --pure works properly and doesn't get polluted (env answers a much smaller set of variables and don't show any reference to ~/.guix-profile)
<roptat>I don't understand why the bytecode is incompatible if I just built and run with the same (and only) guile from my environment...
<roptat>ah nevermind, my $PATH is still polluted
<nckx>tricon: Nothing wrong with dual-licencing. Just make sure that the GPL applies to the entire package.
<nckx>And that the package doesn't promote ‘…now download our cool non-free add-ons!!’ anywhere. Not specific to Asterisk, just in general.
<the_tubular>Anyone able to boot guix on a raspberrypi ?
<ruffni>i'm getting a "No such file or directory: sh" in a scons-build-system. if i enter a pure environment 'sh' works just fine. am i missing something?
<Noisytoot>How can I test a service with ./pre-inst-env?
<hunter>Hi there. Would like to seek advices regarding the manual compilation of Linux Kernel in Guix
<drakonis>have you tried reading the documentation?
<ruffni>Noisytoot: without a guix system running?
<dstolfa>Noisytoot: is this a service that requires root?
<dstolfa>if so, i'd advise you to override the savannah guix channel and use your own local git checkout as the guix channel and do it through that method
<drakonis> https://guix.gnu.org/en/cookbook/en/guix-cookbook.html#Customizing-the-Kernel
<dstolfa>it's the least painful one IME
<hunter>i referred to this website , https://www.programmersought.com/article/85351055625/
<drakonis>hmm
<drakonis>but have you tried guix's docs instead of this?
<hunter>no i havent. I'll give it a shot ..
<hunter>the doc that you are referring to is this https://guix.gnu.org/en/cookbook/en/guix-cookbook.html#Customizing-the-Kernel right ?
<drakonis>yes
<hunter>Thanks. appreciate it
<bricewge>raghavgururajan: There is a WIP for lightdm service, it's working fine
<Noisytoot>ruffni, I am using Guix System
<Noisytoot>dstolfa, It doesn't run as root, but it does create a user
<bricewge>raghavgururajan: There is no Guix specificity for using gpg-agent as a ssh-agent
<dstolfa>right, you should probably just have a replacement channel for guix from your local git checkout rather than savannah
<dstolfa>and then just do a `guix pull --disable-authentication` to get your code
<Noisytoot>How can I replace it (rather than adding another channel)?
<drakonis>you have to replace it in the channels list
<drakonis>there's a variable that contains a list of channels
<drakonis>%default-channels
<drakonis>you might want to do away with cons* if you use it instead of lists
<dstolfa>you don't need to do that at all
<dstolfa>you can just call the channel you added "guix"
<dstolfa>and that's it :)
<bricewge>raghavgururajan: You may want to look at this sheperd user service for gpg-agent
<jlicht>raghavgururajan: I found keychain to work pretty well for my gpg + ssh needs
<jlicht> https://www.funtoo.org/Keychain, and my shoddy attempt at a guix package: http://paste.debian.net/1203852/
<jlicht>and I believe tarsius wrote some keychain integration snippets for Emacs, if that is your cup of tea
<raghavgururajan>> bricewge‎: raghavgururajan: There is a WIP for lightdm service, it's working fine
<raghavgururajan>Nice, I'll try it.
<raghavgururajan>jlicht: Thanks!
<bricewge>It is working well been using it for months
<bricewge>I looked into running X manually in rootless manner last weekend, it didn't worked out. I'll try again this week.
<civodul>sneek: later tell maximed this new lint warning for #:tests? is awesome :-)
<sneek>Okay.