IRC channel logs


back to list of logs

<nckx_>muradm: you have git configured to (also) send to bug-guix@ somehow?  Not sure how that would happen; --to= should override the default, but it clearly did happen somehow.
<muradm>nckx_: i suppose because git send email didn't put [bug#56699] in the subject
<nckx_>Subject has no effect on the bug tracker.
<nckx_>s/bug-guix/guix-patches/ in my earlier message; the former is possible but unlikely.
<muradm>here is the header from mail i sent with missing attachment
<nckx_>You CC'd
<nckx_>TBC I wrote that before reading that paste...
<muradm>here is the header from git send-email
<nckx_>That's not what I have: Cc: paren@...,
<nckx_>I am talking about the patches.
<muradm>nckx_: you get what is processed by debbugs
<muradm>but 57047 is caused by this i'm retty sure
<nckx_>If that were true, it would have 'processed' your cover letter in the same way.
<nckx_>Why didn't it?
<nckx_>muradm: That's not even the same mail.
<nckx_>You said git send-email.
<muradm>nckx_: exactly, the only technical difference between those two is subject line
<muradm>the one includes 56699, the other don't
<muradm>nckx_: there was 2 mails, one i sent from mail client, but forgot that actual patch (pay attention it says "attached", but there is no attachment)
<muradm>second, i sent in reply to directly from git send-email
<muradm>with only patch, no cover letter or so
<nckx_>'pay attention' - I am, although I'm feeling lonely.  'it says "attached"' - that's the cover letter I was referring to above.
<muradm>and that second one, while it processed --in-reply-to correctly (since it is linked to 56699), still it triggered new 57047
<muradm>wierd.. any way.. my laptop is at 2% already and i have to sleep.. good night
<nckx_>Right, the threading (based on message-id) is 'correct' here too.
<nckx_>muradm: Good night.
<muradm>sorry for mess with issues and mails..
<nckx_>Not your fault?  Please don't be.
<nckx_>We can always merge those, although closing them makes it less trivial (but not hard).
<nckx_>muradm: Don't let me keep you awake, but when you say 'header from git send-email', do you mean you logged what it actually sent from your machine/server?
<Cairn>Hey guix. If I'm reading this right, it seems like the default elogind action on lid close is suspend? (The `handle-lid-switch` variable)
<Cairn>Does look like it's happening on my system though. Is that actually something I need to add to my config?
<Cairn>Sorry I forgot to mention: I'm reading this:
<nckx_>No, it should be the default without adding anything (hence: default).  I'd start with a peek at the elogind.conf actually in use.  Should be visible in ps auxww or whatever.
<Cairn>Oh so it's not in /etc?
<Cairn>I ran ps auxww and found this line: `/gnu/store/*-elogind-246.10/libexec/elogind/elogind`
<Cairn>But I'm not sure if that's what I'm supposed to pay attention
<Cairn>I found `/gnu/store/*-elogind-246.10/etc/elogind/logind.conf`, but that's not in my `/run/current-system/etc`
<nckx_>Are there no arguments in the process list?  (The only system I have that runs elogind currently isn't, hence can't check.)
<Cairn>Sorry, what am I looking for?
<Cairn>The only line that mentions elogin when I run `ps auxww` is this: "root 423 0.0 0.0 430548 3828 ? Ss 10:58 0:00 /gnu/store/*-elogind-246.10/libexec/elogind/elogind"
<nckx_>Yeah, I just noticed that won't work.
<nckx_>I was expecting logind to be run with something like a '--configuration foo.conf' argument
<nckx_>but it ain't, it's worse, it's set as an environment variable in the shepherd service instead.
<Cairn>So how can I check for that then?
<nckx_>sudo cat /proc/423/environ | tr '\0' '\n'
<nckx_>I think...
<Cairn>Oh yeah, I see a file
<Cairn>Let me look at it
<nckx_>Yes look at the file.
<Cairn>Just like I see in the defaults. `HandleLidSwitch=suspend`
<nckx_>OK, so we know it's not a Guix service bug.
<Cairn>Why wouldn't it be working then
<Cairn>Great, that's progress
<nckx_>(I don't want to point out the obvious, but you're not docked or on external AC power... right?)
<Cairn>I have my charger plugged in... But I'm not using the doc feature
<Cairn>Wait, will it not suspend with the charger plugged in?
<nckx_>I don't think so.
<nckx_>No: handle-lid-switch-external-power -> ignore
<Cairn>I guess I didn't realize what that line meant
<nckx_>2 lines down, but you were too busy opening and closing your lid.
<Cairn>I just always have my charger plugged in. I might have configured that line years ago on my previous system, so I was expecting different behavior
<nckx_>I agree that they could have called it 'handle-lid-switch-battery'.
<nckx_>(They being upstream; us doing so would be too confusing.)
<Cairn>Yeah. No I guess it makes sense
<Cairn>I'll keep it as default. I'll just make sure to unplug when I want to suspend
<nckx_>But this rekindles a suspicion I had when you first asked: the way most Guix systems handle 'defaults' is honestly not great.
<Cairn>What about it wasn't handled great in this case?
<nckx_>Some might consider it a feature ('it's explicit! and that's good!'), but what I mean is that we tend to *always* write a default, so the software sees everything as explicitly configured.
<nckx_>Which with many daemons is not the same as omitting the value.
<nckx_>And yep
<nckx_>god dammit
<nckx_>I was right:
<nckx_>HandleLidSwitchExternalPower= is completely ignored by default (for backwards compatibility) — an explicit value must be set before it will be used to determine behaviour.
<nckx_>By being 'explicit', Guix is introducing a bug.
<nckx_>Not for the first time, although I forget which package I last noticed it on.
<nckx_>Probably CUPS.
<Cairn>Are you gonna change that?
<nckx_>It's usually CUPS.
<nckx_>Well, the reason it's currently like this is because it's easy to write services this way.   Fixing it would have to improve the overall logic, not just tweak a line.  I don't think I'll volunteer, but if you'd be willing to file a bug so it's at least public, I'd be much obliged.
<nckx_>(Genius: 'I won't do X, but I'll ask you to do Y' as if it's some kind of compromise on my part.)
<Cairn>And I was all but convinced you were making a reasonable compromise instead of giving me all the work! ;)
<nckx_>Of course: you are also welcome to go ahead and fix it, if you like.
<Cairn>I'll do my best to submit a bug. I'm a million years from being able to fix it though
<nckx_>If you insist on doing work we are powerless to stop you.
<nckx_>That's fine, and appreciated.
<Cairn>I can barely program in Elisp, and that's just cause Emacs tells me everything about itself. I haven't even read the Guile manual yet
<Cairn>Oh actually. Is there a documentation interface similar to Emacs's for Guile?
<Cairn>Like how you can jump to definitions and get docstrings in a formatted window and whatnot?
<superkamiguru>Don't mean to interrupt at all, but are there any recommendations for running a container as a service?
<bdju> tiled-1.8.1 fails to build
<nckx_>superkamiguru: You're not interrupting.  On-topic questions are always welcome.  Don't think I can be of help, though.  Guix provides some helpers to run Guix System services *in* containers, but that seems to be the inverse of what you want.
<nckx_>I get typing notifications for fellow Web chat users.  Weird.  I no like.
<nckx_>Cairn: 'Geiser' gets mentioned a lot, but I don't use it.
<nckx_>Docstrings aren't as common as they should be in Guix.
*nckx_ -> zzz, good night all.
<superkamiguru>Ok, no problem at all. I am currently trying to create a simple service that extends shepherd-root-service type, and then run the command to start the container with make-system-constructor.
<superkamiguru>Hopefully can figure that tout
<Cairn>Thanks for the Geiser recommendation nckx_! I'll probably set it after I read further into the manual.
<jts>hey y'all. how do you get the number of cores passed to guix build inside a package definition? i need build artifacts from a different package for a package i'm packaging and would like to use more than just one core for getting them
<sneek>Welcome back jts, you have 1 message!
<sneek>jts, podiki[m] says: I saw in the logs you mentioned packaging haxe? I was also giving it a shot, curious if you got it working
<podiki[m]>oh nevermind that jts, I packaged it and it was merged :-)
<jts>podiki[m]: that's awesome to hear! heck yeah!
<podiki[m]>look for "parallel-build?" and parallel-job-count
<jts>perfect, thanks!
<jts>also, now that we've got haxe, I just need to package Heaps ;)
<podiki[m]>yeah I didn't try making any "haxe-build-system" but haxe does include haxelib for managing libraries
<podiki[m]>so I tried heaps through that and samples I've seen, just worked for me
<jts>awesome! wow! thank you so much, I'm vibrating with excitement!
<podiki[m]>you can just install haxe and then use haxelib to manage the haxe stuff
<podiki[m]>glad to hear it! it is a cool language, now that I packaged it I gotta learn how to use it
<podiki[m]>neko and hashlink are also packaged, my brief tests with hashlink worked as well
<jts>oh, on a related note, how would one use package-source with new style input lists? I'm doing atm but would prefer the `(list input1 input2 ...)`
<podiki[m]>I always forget, maybe `("packagename" ,(package-source packagename)) ?
<podiki[m]>for a specific output it is `(,glib "bin") if that is helpful example
<jts>thanks, I'll fiddle with it :3
<bdju>is there a fix for guix saying my version is 0?
<Cairn>bdju: Where's it say that?
<bdju>when I do guix --version
<bdju>guix (GNU Guix) 0
<bdju>is the first line of output
<bdju>I vaguely recall it being discussed here or on the mailing list in the last few months, so I thought it was fixed. I haven't rebooted in a long time, so maybe that could be why it's still saying 0
<bdju>so it's said that for a while, I haven't made any crazy changes to my setup. and I'm on guix system
<bdju>but with 154 days uptime
<apteryx>how can I effect the environment of a dbus service launched daemon ?
<apteryx>e.g., accountsservice in Guix
<iyzsong>apteryx: it's started by the system dbus daemon, so the environment variables should inhert from 'dbus-shepherd-service'.
<Cairn>bdju: Oh interesting. My version also says 0.
<apteryx>iyzsong: that's what I thought, but cat'ing /proc/NNN/environ from the parent dbus-daemon (system) and its forked services, that doesn't seem true (that the child inherit from its env)
<apteryx>it probably controls that tightly
<apteryx>so I'll try sneaking my environment variable in the 'Exec' line, hoping that's invoked via a shell
<iyzsong>ah, okay
<apteryx>yep, there's a clear_environment proc in activation-helper.c (dbus), which has a comment: "Clears the environment, except for DBUS_STARTER_x,"
<apteryx>systemd has a fancy way to control d-bus environments, not sure how it does it
<apteryx>I think it exec directly. I'll wrap accountsservice's libexec/accountsservice
<apteryx>libexec/accounts-daemon, I mean
<jackhill>When a Qt app doesn't show (some?) of it's icons, what am I missing? In this case `guix shell kochmorse
<apteryx>perhaps an icon theme?
<apteryx>and XDG_DATA_DIRS
***dgcampea-2 is now known as dgcampea
<jackhill>hmmm, same problem with `guix shell oxygen-icons kochmorse` What package do I need for XDG_DATA_DIRS
<bdju>Cairn: oh okay. so it's not just me still
<Cairn>I installed in only the last few weeks
<Cairn>If that means anything about its longevity
<apteryx>jackhill: glib should do it
<apteryx>OK, I could fix the accountsservice issue; still to understand how to get the icons to show and the sessions to be found
<apteryx>(working on lightdm)
<jackhill>apteryx: no such luck with kochmorse
<jackhill>but I think there are only three buttons, and I've figured out what they all do by now :)
<apteryx>my experience is that Qt often embeds icons as resources in the binaries
<apteryx>it depends if the app comes with its own icons or not, I guess
<dcunit3d>how do I feed the linux kernel's PRNG with an external source using rng-tools? is this a question that can be answered here?
<dcunit3d>does rng-tools require a service to be running?
<iyzsong>dcunit3d: yes, and guix system has urandom-seed-service-type and rngd-service-type.
<ekaitz>hi all! easy question: how do I obtain the output dir of a package in the gexp?
<unmatched-paren>ekaitz: #$output :)
<ekaitz>unmatched-paren: thanks!!!
<civodul>hey, hello Guix!
<unmatched-paren>hello civodul
<mroh>hey civodul!
*civodul prepares to merge the pretty-printer work:
<unmatched-paren>civodul: `guix style -f` sound extremely useful, thanks for working on that! :D
<civodul>unmatched-paren: yes, i think it can be useful especially when you're not a die-hard Emacs/Vim user!
<civodul>like it can help pinpoint parens issues in /etc/config.scm
<rekado>I’m disappointed that nobody else stepped up to join the mentors team.
<unmatched-paren>i guess most people don't think themselves experienced enough to be a "mentor"
<rekado>we have quite a few committers. Surely there are more than two people who could help newcomers to get their patches accepted?
<ekaitz>rekado: should I join the mentors team?
<ekaitz>I can just help with packaging and a couple of things more
<ekaitz>now I think about it... didn't I already joined for the boostrapping part?
<ncbfg36>how would I go about forcing a kernel module to load on guix system? It looks like thinkpad_acpi doesn't load on coreboot systems unless forced and the only instructions I can find to do so involve /etc/modprobe.d on other linux systems. Running 'modprobe -f thinkpad_acpi' returns "Exec format error"
<ncbfg36>I'm looking at kernel-module-loader-service-type in the docs but it's not entirely clear to me how to specify options such as force_load=1
<civodul>rekado: yeah, i wonder what we could do to address that
<civodul>we've invited committers to talk about why they wouldn't review/apply stuff but haven't gotten much feedback
<civodul>perhaps we should make a few tasks mandatory, similar to how oss-security handles that?
<civodul>(i'm not a fan of this obviously, but if that's what it takes...)
<civodul>ekaitz: could be! i guess the main point is being able to guide people to get their package patches in shape for inclusion
<civodul>that requires familiarity with the patch submission guidelines, but that's really nothing difficult
<ekaitz>civodul: I'm not sure I'm the best for the job, my patches always get fixed by you but anyway, you can't count me in
<drakonis>civodul: the patch workflow pipeline could use some touching up
<civodul>ekaitz: heh, thanks for volunteering! :-)
<ekaitz>civodul: my only purpose in life is to be useful
<abrenon>hi guix
<rekado>ekaitz: the idea behind the mentor team is really just that there is a committment by the team members to coordinate patch review for newcomers.
<rekado>we don’t want to have reviewers step on each other’s toes, but we also don’t want new contributors to be discouraged
<ncbfg36>oh I figured it out. I was just confused about setting kernel arguments
<rekado>so we need a few things: the means to identify/list submissions by new contributors, and a few people who will priorize these submissions and coordinate to a) respond to the submitter quickly and b) shepherd their patch to completion (this may include dismissing it).
<ekaitz>rekado: so it's not that some of the patches will arrive to my inbox and I'd be in charge of them
<ekaitz>(that would be a nice thing)
<rekado>ekaitz: this can be done by making mumi send notifications
<ekaitz>rekado: that would be cool, send notifications in a round-robin or something like that to people in the mentoring team so they don't have to dig in every patch to see if requires attention or not
<rekado>I’m playing with “guix system container”; when I use “--network” I see that the container gets the same IP as the host. Is this expected? Can I give it another IP?
<apteryx>would there be an elegant way to provide an environment variable to the lightdm login greeter? It doesn't carry its parent (lightdm) environment variables, rather it seems its env is initialized anew from /etc/environment (PAM) and perhaps /etc/profile
<apteryx>the environment variable is only of use to itself (to find its configuration file)
<apteryx>the alternative is to hack the lightdm-gtk-greeter package to look its default config file at /etc/lightdm/gtk-greeter.conf
<apteryx>(and have our service extend etc-service-type)
<rekado>to answer my own question: I guess cni-plugins could be used to change how the network between host and container is configured.
<civodul>rekado: yeah, or we could use guile-netlink to set up bridge interfaces
<apteryx>should /etc/profile extend rather than set XDG_CONFIG_DIRS and XDG_DATA_DIRS? that seems too niche
<civodul>apteryx: presumably these are necessarily unset by the time /etc/profile is sourced, no?
<abrenon>I'm trying to understand stuff in opam's import (again), and I'm confused about where actual parsing of the opam file inside the imported repo happens
<abrenon>get-metadata (l. 211) sounds like a good candidate but I don't understand the ,@( from its calling site
<podiki[m]>apteryx: possibly related?
<abrenon>and I have no idea where match-pattern and records are defined, or if they are general guile function or opam-specific ones
<civodul>abrenon: hi! i guess 'get-metadata' returns a list (or an alist) and its call site "splices it" into the containing alist
<podiki[m]>some discussion there (and related issues) on xdg_config_dirs and profiles in particular
<unmatched-paren>abrenon: match is from (ice-9 match)
<unmatched-paren>and records are from (guix records)
<abrenon>thank you !
<civodul>abrenon, unmatched-paren: match-pattern is from (ice-9 peg)
<unmatched-paren>Oh, right, that's something different
<abrenon>oh, ok, so consistent with the peg:tree on the same line
<unmatched-paren>Okay, thanks civodul, I didn't know about that module :)
<civodul>a nifty thing to write parsers with
<podiki[m]>so I explicitly add my "desktop profile" to xdg_config_dirs to work around how guix sets xdg_config_dirs
<apteryx>civodul: what do you mean by 'necessarily unset'? I'd expect the login components spawned by lightdm to inherit its environment (which is furher refined by sourcing /etc/profile, IIUC).
<unmatched-paren>wow, guile has both peg and lalr in the standard library
<abrenon>ok, so peg provides the tooling for the parser
<abrenon>and records describe the syntax of the file
<abrenon>but if it's a general guix util, and not something specific to opam, how can that be ?
<abrenon>does opam format happens to be something we supported in guix already ?
<unmatched-paren>Ah, looks like the patterns are defined with define-peg-pattern
<apteryx>civodul: my use case here is allowing lightdm-gtk-greeter to find its configuration via XDG_CONFIG_DIRS, which I set on lightdm, but is overridden by /etc/profile
<unmatched-paren>abrenon: Oh, I didn't realize there was a `records` variable there
<unmatched-paren>(define-peg-pattern records body (and (* SP) (* (and (or record weird-record) (* SP)))))
<unmatched-paren>on line 78
<unmatched-paren>I thought you were asking about define-record-type* :)
<abrenon>ooooh I see
<abrenon>sorry ^^
<unmatched-paren>i guess SP is whitespace
<unmatched-paren>hah, weird-record :)
<abrenon>I had started greping the file but I guess I missed that one
<unmatched-paren>How exactly should I invoke GCC to get a cross build?
<unmatched-paren>Does using the (cc-for-target) `x86-64-linux-gnu-gcc -c foo.c -o foo.o` suffice?
<apteryx>podiki[m]: I think it's a different issue (since we do not have a pulseaudio daemon proper)
<unmatched-paren>Or is there some other thing I need to do?
<apteryx>pulseaudio daemon service*
<unmatched-paren>Okay, I'll make my question more specific to what I'm actually trying to do:
<unmatched-paren>If I write a makefile, does using ${CC} suffice for getting Guix cross-compilation to work?
<unmatched-paren>Or would I have to put some machinery in my (hand-written) ./configure to recognise the GNU configure target argument?
<apteryx>don't go down the hand-written configure path. You'll regret it.
<unmatched-paren>apteryx: Why?
<unmatched-paren>I'm specifically writing it so that the flags are compatible with GNU configure.
<unmatched-paren>e.g. it accepts --srcdir=... but doesn't act on it
<unmatched-paren>it'll actually make it easier to package, because i won't have to specify #:make-flags manually :)
<unmatched-paren>(as opposed to a package with just a makefile)
<unmatched-paren>That's half the reason I'm doing it; the other half is so that I don't have to use GNU extensions in my makefile.
<abrenon>I once wrote a configure that was essentially a call to sed to set the value of PREFIX in the
<unmatched-paren>This one will just write to instead of modifying the makefile directly
<civodul>apteryx: does lightdm-gtk-greeter have a wrapper to set XDG_*?
<civodul>should it?
<civodul>howdy samplet :-)
<samplet>Hi civodul!
<civodul>how's everything?
<civodul>i know you live far away but we'll have i think nice talks from the SWH folks at the ten years event in Paris
<civodul>i'm sure Disarchive will be part of the discussion :_)
<samplet>Yeah, I’m very tempted to go, but Paris is very far away.
<samplet>Things are okay, but I’m frustrated with how slow I’ve been. I was hoping to have Disarchive working on the SWH side back in the spring....
<civodul>(yeah, and as frustrating as it is, i think transcontinal flights "just" for conferences is a thing of the past)
<civodul>right, looks like you had +/- found a way forward to have the database right at SWH!
<civodul>that'd be sweet
<civodul>don't put pressure on you though, you've been doing awesome work all along :-)
<samplet>I’m working on the third (final?) implementation of it. Then there will be review, etc. I’ve made the mistake of putting other things (like PoG) on hold because it’s *almost* finished. lol
<civodul>heh, nice
<apteryx>civodul: it does for XDG_DATA_DIRS, but then you still need to write things to a fixed location
<civodul>samplet: so maybe you've seen: i just discovered that we/i had forgotten to turn on tar.xz disassembly at ci.guix, oops
<apteryx>such as the systemp profile or /etc
<samplet>I did see that! Thank you for addressing it. Bzip2 has been on my mind lately. Maybe we can coordinate better with that one. :)
<civodul>apteryx: from what i see, lightdm-gtk-greeter would put everything it needs as a prefix of XDG_DATA_DIRS, but i guess i'm overlooking something
<apteryx>its config is generated from the lightdm service
<apteryx>so it lives in a non static place (the store) unless we extend the profile-etc-service or etc-service-type with its location
<apteryx>I'm going the etc-service-type route now
<apteryx>(with a patch to lightdm-gtk-greeter that has its default config (CONFIG_FILE) set to /etc/lightdm/lightdm-gtk-greeter.conf
<unmatched-paren>Hmm, looks like pcc is broken
<unmatched-paren>Looks like my bug report might have been blocked by the spam filter
<unmatched-paren>because it had a log file, i guess
<unmatched-paren>Eh, I don't need to send that bug report. I figured out the problem, anyway, so I can just send a patch :)
<unmatched-paren>Oh, right /o\ i'm not subscribed to bug-guix :P
<apteryx>unmatched-paren: for the reasons autoconf exists :-) you'll always have forgotten some edge case or a switch, or introduced something incompatible with what is expected, and people will complain about it
<abrenon>so passing make flags with the output prefix is preferred ?
<unmatched-paren>apteryx: I'm not doing it for compatibility
<unmatched-paren>I'm being extremely careful to make my code completely POSIX/C11 compatible :)
<unmatched-paren>The two reasons I'm doing it are (1) easy use with gnu-build-system (2) allowing advanced build system features without using gmake-specific features
<unmatched-paren>e.g. without a configure script, I couldn't do feature flags without using $(if ...)
<unmatched-paren>which is a GNU extension
<unmatched-paren>So I guess I kind of am doing it for compatibility
<unmatched-paren>but not the autotools 'load of workarounds for missing features' thing
<abrenon>wow, peg aren't easy to tame
<abrenon>still can't figure if the problem is in the grammar itself or in the functions handling the AST
<abrenon>anyway, I'll have to figure it out later
<abrenon>see y'all
<civodul>glib depends on bash-completion since 8b8e6118769f4dedb835144c69a63636cb367ad1
<civodul>does anybody know why?
<civodul>it's not referenced (in the sense of "guix gc --references")
<civodul>and i suspect it's useless
<unmatched-paren>the pcc code wraps `long double` in a struct... `struct flt { long double fp; }; typedef struct flt FLT;` eww
<efraim>civodul: gnu/packages/patches/ruby-hydra-minimal-no-byebug.patch is missing on staging
<civodul>re glib, same for dbus and libelf, added in the same commit
<efraim>perhaps to install completions in the correct directory automagically?
<civodul>efraim: fixed the missing patch, apologies!
<efraim>I worked on the bash-completions test-suite for 2.11 for a few hours but couldn't get it to pass
<civodul>efraim: dunno
<civodul>but really, why would glib care about bash completinos?
<civodul>ah well it does install a few things under share/bash-completions
*unmatched-paren sends patch for the aforementioned pcc build failure
<efraim>it probably shouldn't need bash-completions
<unmatched-paren>here it is <> :)
***Noisytoot is now known as [
<unmatched-paren>Is this bug <> closable? If not, that's pretty concerning
<civodul>unmatched-paren: i suppose we've had time to get the new version of Nettle, no?
<unmatched-paren>civodul: I don't know
<unmatched-paren>Probably :)
<unmatched-paren>Yeah, we have 3.7.3 now
<unmatched-paren>3.7.2 contained the fix
<unmatched-paren>So I guess we can close that issue
<florhizome[m]>Can i remove multiple packages via regexp or so?
<florhizome[m]>for example everything with emacs-
<apteryx>hmm... "Failed to launch bus: Failed to connect to session bus" from lightdm gtk greeter logs
<unmatched-paren>florhizome[m]: guix package --list-installed | awk '/^emacs-.*/ { print $1 }' | xargs guix remove
<podiki[m]>apteryx: I meant the broader issue raised in the pulseuadio issue, that xdg_config_dirs is only set to the default user profile, if I remember correctly, rather than through search paths
<unmatched-paren>awk is useful :)
***Dynom_ is now known as Guest5898
<unmatched-paren>and underappreciated
<two[m]> * could be `grep ^emacs\` instead of awk
<two[m]>could be grep ^emacs` instead of awk
<two[m]>* could be `grep ^emacs`
<unmatched-paren>two[m]: That wouldn't work
<unmatched-paren>because --list-installed shows a detailed record of installed packages
<unmatched-paren>so we need to print the first field (the name)
<florhizome[m]>ty paren :) guix package could use some subcommands imo :‘)
<unmatched-paren>two[m]: e.g. emacs-ztree 1.0.6 out gnu/packages/emacs-xyz.scm:23089:4
<apteryx>the grep alternative would be 'grep ^emacs | cut -f1'
*unmatched-paren opens `man cut`
<unmatched-paren>apteryx: nice, didn't know about that option
<two[m]>oh sorry
<unmatched-paren>two[m]: Btw, did you edit that "could be ..." message?
<unmatched-paren>matrix seems to resend edited messages to IRC
<unmatched-paren>so just use a sed or *correction instead :)
<unmatched-paren>it's fine :)
<two[m]>i think formatting would be not good to show with s/
<unmatched-paren>the matrix bridge does a few annoying things
<unmatched-paren>the other one is the "View full message at ..." thing
<unmatched-paren>when you write a long message, it truncates it and you need to open a link to read the full thing
<two[m]>*`grep -o '^f[^ ]*'`
<two[m]>\*`grep -o '^emacs-[^ ]*'`
<apteryx>ah, lightdm clears the env itself for the child processes (seats) it launches: process_set_clear_environment (script, TRUE);
<apteryx>hehe, /usr/bin/dbus-launch, gotcha
<muradm>nckx: regarding git send headers, yes it is what i see in the output of git send-email and same i was observing in my exim mta logs
<haugh>What is meant by the term "lowerable object" as used by the file-append doc?... (full message at
<unmatched-paren>haugh: It means a file-like object, package, anything that can 'become' a store path
<unmatched-paren>(the thing -> derivation process is called lowering, and the derivation -> output process is building, i think)
<haugh>thanks, unmatched-paren
<unmatched-paren>haugh: for example, (file-append emacs "/bin/emacsclient") is a gexp that returns "/gnu/store/...-emacs-.../bin/emacsclient" when ungexped
<unmatched-paren>s/ungexped/used as a gexp/
<unmatched-paren>s/as a gexp/in a gexp/
<haugh>Haha yes, I'm still getting my head around gexpification
<unmatched-paren>i think i've sort of gotten my head around them, but it's one of those things where you have an intuition but it's really, really hard to describe :)
<haugh>Right, like quoting, it has an explicit element and an intuitive understanding of how that functionality is generally applied
<nckx>muradm: Not the answer I was hoping for, but thanks all the same ;-)
<unmatched-paren>this was helpful for understanding them
***jesopo is now known as jess
<nckx>unmatched-paren: I don't believe we *have* a blocking spam filter, and if we do you basically have to write Subject: Viagra for it to even care.
<unmatched-paren>nckx: Right, it was just taking an unusually long time to arrive in my mailbox.
<shcv[m]>how often do y'all do what I'll call "dynamic packages" - functions that generate packages from a few parameters, instead of fully declarative specs?
<shcv[m]>e.g. for pulling a single item out of a large repo, such as one font from nerd-fonts
***_koolazer is now known as koolazer
<muradm>nckx: hope dies last :D
<acrow>Anyone using guix-import-debian: I get a shutil:RegistryError. I'm trying to use it under python-pip-run. Anyone else see this?
<apteryx>guix-import-debian ?
<unmatched-paren>apteryx: <- apparently it exists
<unmatched-paren>strange that the author didn't contribute it as a `guix import` module
<apteryx>perhaps because it's authored in python
<unmatched-paren>Yeah, I mean "strange that they didn't write it in Scheme and contribute it as a `guix import` module" :)
<podiki[m]>neat though, if it saves some of the more routine stuff when there is no other importer
<apteryx>soon enough there'll be a need for debian-import-guix script
<podiki[m]>yes, got that, and agree
<apteryx>scratch that, there's already 'apt install guix' ;-)
<unmatched-paren>Maybe we could translate it to Scheme :) Could be a nice starting point for a native importer
<unmatched-paren>apteryx: Better: `apt install guix && guix pull && apt remove apt dpkg` :P
<unmatched-paren>... `&& sudo guix system reconfigure /path/to/default/config.scm`
<ekaitz>hi can anyone point me to a package that is always cross-compiled? does that exist already?
<unmatched-paren>Why would you have a package that's always cross-compiled?
<ekaitz>i'm thinking on, for example, a library for gaming console development which will never run guix
<acrow>I think Hartmut is a genius but I wish he had put this into a guix package. I think the fix may be almost trivial but testing it out is a python project.
<ekaitz>and is... idk a very small ARM device or a MIPS
<ekaitz>I would need to define a build system, probably, right?
<muradm>ekaitz: you want to work on a library? or package a library? as far as i'm aware every package is kinda cross-compiled, isn't it?
<unmatched-paren>They want to make a library that's *always* cross-compiled
<ekaitz>muradm: I want to package a toolchain for GameBoy Advance
<ekaitz>to say it plainly
<unmatched-paren>ekaitz: Oh, we have embedded toolchains
<ekaitz>and it needs some libs, that must be compiled for a GameBoy
<unmatched-paren>try `guix search arm toolchain`
<ekaitz>unmatched-paren: yes the arm one is enough I think, but how should I package a library for the GBA?
<unmatched-paren>i'm not sure, sorry
<unmatched-paren>argh, is down :(
<ekaitz>it should only build for the GBA and not for the current arch...
<muradm>ekaitz: i suppose you have to dig into supported-systems then
<unmatched-paren>problem is, supported-systems probably only supports specifying systems that Guix itself supports
<acrow>getting guix-import-debian is a side project brought about to write a package for mkcue -- which is demanded by, already in guix, abcde. The problem is that the only source for mkcue I've found and got free access to is in debian. I am not currently running debian (another long story). So, guix-import-debian seems useful to me.
<unmatched-paren>like aarch64, ppc64le, riscv64
<ekaitz>muradm: hm... and it fails when you try to install an arm thing on x86
<ekaitz>so the thing is this should build and install, but for development purposes only
<unmatched-paren>whereas i presume the GBA is some kind of 32-bit ARM
<ekaitz>unmatched-paren: it is yeah
<muradm>unmatched-paren: you always can fork guix and work in ./pre-inst-env
<ekaitz>so the question is: can I make a package only build with arm-none-eabi-gcc?
<muradm>until you have a result which can be proposed if it is the desire
<ekaitz>is there an arm-build-system or something like that?
<unmatched-paren>muradm: ekaitz doesn't want guix to run on arm32
<unmatched-paren>they want to be able to *cross-compile* to some embedded platform
<unmatched-paren>with one of the arm-*-toolchains
***ec_ is now known as ec
<muradm>ekaitz: build system is tools around build tools, like gnu-build-system is around autoconf/make, cargo-build-system around cargo, but in theory well equiped build tool is already capable of building for multiple targets.
<ekaitz>muradm: but how can I force a package only build for arm-whatever using the toolchain I choose?
<ekaitz>should I make a build-system?
<unmatched-paren>i don't think that will be necessary
<muradm>ekaitz: (package (supported-systems ... ))
<unmatched-paren>muradm: but that won't work here
<unmatched-paren>because they're not building the lib so that they can use it on their guix system
<unmatched-paren>they want to cross-compile it to a different system
<unmatched-paren>and it can *only* run on that different system
<unmatched-paren>ekaitz: Hmm. (arguments (list #:target "...")) maybe...?
<unmatched-paren>No, that won't work....
<muradm>unmatched-paren, ekaitz: if there is no desire to produce a package which is for guix environment, i suppose it would be overkill to make guix support another target
<unmatched-paren>muradm: Exactly.
<unmatched-paren>And it wouldn't really be possible to make Guix support Game Boy Advance anyway :P
<muradm>this is why i asked initially package or development only
<ekaitz>there must be a way to make this, not only for gameboy and consoles
<ekaitz>also for microcontrollers and stuff like that
<unmatched-paren>I'm afraid I'm not the person to help you with this
<ekaitz>another option is to insert it in source in the project and leave it like that
<ekaitz>no problem unmatched-paren :)
<muradm>ekaitz: what ever you want to do, can you do under debian for instance?
<unmatched-paren>ekaitz: aha! I found a sort-of-similar package i think
<unmatched-paren>try `guix edit proplib`, it might contain insights?
<unmatched-paren>it manually sets CROSS_LIBRARY_PATH and CROSS_C_INCLUDE_PATH
<unmatched-paren>and uses the propeller-gcc, and propeller-binutils packages
<ekaitz>unmatched-paren: yeah! that's the thing!
<unmatched-paren>Glad I could help, even if by accident :)
<atka>when it comes to wayland and tiling on guix, its pretty much just sway?
<unmatched-paren>(I was looking through the results of `guix search embedded`)
<unmatched-paren>atka: Well, we have weston :P
<ekaitz>thanks unmatched-paren and muradm !
<unmatched-paren>atka: Oh, yes, we also have dwl
<podiki[m]>atka: I don't know of other wayland tiling WMs more generally, but I'm not on wayland (mostly for that reason)
<unmatched-paren>atka: There's also "hikari" apparently
<atka>unmatched-paren: dwl is a nonstarter, development of foss software over discord...
<unmatched-paren>Oh, eww.
<podiki[m]>ah, one I didn't know about
<atka>too many keypresses :)
<atka>ctrl+t before everything gets old
<atka>though I do that on dvtm atm
<unmatched-paren>Oh, right, it'll have emacs keys since it's ratpoison-like
<unmatched-paren>I forgot about that :)
<atka>I'm very much a dwm user but trying to move to wayland
<muradm>atka: just curious, do you have issues with sway?
<unmatched-paren>atka: Is it the manual tiling in sway?
<atka>and other than forking and having a git repo for it, how does one compile their changes with guix
<atka>the manual tiling and the lack of bitmap fonts
<unmatched-paren>because an `i3-autotiling` package was recently merged that provides autotiling for sway and i3
<atka>though the latter can be worked around I suppose
<unmatched-paren>I'm using it right now :)
<unmatched-paren>`exec_always autotiling` in the config
<atka>I think I will give sway another try, anyone have an example of the bare minimum sway config,?
<atka>or is it in the cookbook?
<atka>preferably don't want to use %desktop-services
<unmatched-paren>atka: The minimal sway config is in the sway repo
<atka>unmatched-paren: I meant the guix side of it
<unmatched-paren>You just run `sway` from a tty
<unmatched-paren>no configuration required other than `~/.config/sway/config`
<unmatched-paren>does X require some setup on the Guix side?
<atka>dunno, never ran guix with a wm
<atka>I use it on servers until now
<muradm>atka: you can use %base-services and seatd-service-type
<unmatched-paren>Oh, yeah, if you want swaylock to work, you need to make it setuid
<atka>muradm: thanks, this is the kind of info I'm looking for
<muradm>then after login running "guix shell sway -- sway" should work for bare minimum
<unmatched-paren> <- I've got my sway-on-guix setup in home.scm, system.scm, and sway.conf here
<unmatched-paren>be aware that greetd isn't working right now
<muradm>atka: just be aware of 56690 issue
<unmatched-paren>at least, most greeters
<unmatched-paren>agreety works fine
<muradm>unmatched-paren: for bare minimum, you don't need greetd, default mingetty should work
<atka>awesome, thank you
<unmatched-paren>atka: Also, if you run seatd, you won't have polkit, which means no upower or pulse
<unmatched-paren>If you need those, use elogind instead
<atka>is pipewire up to snuff on guix yet?
<unmatched-paren>(polkit apparently uses elogind-specific APIs; it hasn't migrated to libseat, which provides an abstraction over both)
<muradm>atka: pipewire/pipewire-alsa/wireplumber works fine for me
<unmatched-paren>muradm: How do you configure it?
<unmatched-paren>There's no pipewire-service-type yet...
<atka>if I can get a minimal sway and pipewire config I will be very happy :)
<acrow>I see window manager discussions and I feel provoked to say that as an emacs user exwm has been a pleasant experience.
<unmatched-paren>atka: Once that greetd bug is fixed, you'll be able to get a minimal login screen, too
<unmatched-paren>(that's what greetd is for :))
<unmatched-paren>acrow: Well, that's an X window manager
<atka>unmatched-paren: thanks but I much prefer tty
<unmatched-paren>we're discussing wayland here
<muradm>unmatched-paren: they don't desire pipewire-service-type in my opnion :)
<atka>im a startx kinda guy
<unmatched-paren>No startx necessary for sway :)
<unmatched-paren>Just `sway`.
<atka>yes, I understand
<unmatched-paren>muradm: Oh, cool, thanks
<unmatched-paren>muradm: I guess since you can just put that in your sway config, we don't need a pipewire-service-type -- we need a pipewire-home-service-type! :D
<muradm>acrow: I bravely tried to survive under exwm for about 6 months on Arch, after switching to Guix I ditched that attempts.. mostly due to the environment flexibility of guix :)
<apteryx>hm, lxde is broken because of lxpanel failing to build
<unmatched-paren>apteryx: fallout from qt6?
<Lumine>I've been on exwm now since last christmas, works well, slight oddities but I'll figure them out one day
<acrow>muradm: did exwm cause problems? or did guix just provide many, many other opportunities to explore?
<muradm>unmatched-paren: while i understand why people desire "nix/guix home".. i am a bit against it.. and prefer to build my workflow in the way that, after the point OS logs me in and sources my .bashrc, it is my world now.
<atka>muradm: are you saying you don't use guix home?
<unmatched-paren>muradm: Eh, it's not invasive
<unmatched-paren>you might be thinking of guix home-manager
<unmatched-paren>which is quite invasive (it locks down your home dir)
<muradm>acrow: more opportunities, but problems also )
<unmatched-paren>It's just like /etc/config.scm but for $HOME instead of /
<unmatched-paren>so you can launch services that don't require root
<unmatched-paren>like pipewire :)
<unmatched-paren>and manage your dotfiles, a bit like stow, but better since along with installing your files it installs any necessary packages to use them
<muradm>unmatched-paren: if i want to run arch, gentoo or lfs on my old laptop, my home will work there :)
<unmatched-paren>It will work on them even with `guix home` :)
<unmatched-paren>It just does symlinking stuff.
<acrow>I've found that guix home fits in nicely when on a foreign distro bc it provides a herd service you cannot otherwise get.
<unmatched-paren>atka: "are you saying you don't use guix home?" HERETIC!!!
<acrow>I understand how muradm: feels though when on a native guix system.
<Lumine>home-manager has been working well for me, I don't feel very invaded yet :P
<unmatched-paren>Lumine: I'm pretty sure home-manager is obsolete now
<unmatched-paren> <- yep, no commits since 10 months ago
<unmatched-paren>it was probably discontinued when guix home was merged into guix core
<unmatched-paren>Ah, yes > Guix home manager was my attempt at creating a home manager for Guix. With
<unmatched-paren>the recent addition of the guix home command to guix, this repository is
<unmatched-paren>now deprecated. Note that this repository is not compatible with the new
<unmatched-paren>guix home. If you installed it, you should remove it and switch to the
<unmatched-paren>new guix home.
<unmatched-paren>Lumine: `guix home` doesn't lock down your /home like `guix home-manager` does
<unmatched-paren>it just makes the dotfiles you configure read-only
<unmatched-paren>not the whole dir
<Lumine>I see
<Lumine>Good to know
<Lumine>Getting rid of manager tomorrow
<unmatched-paren>And it's probably got more home-services than home-manager, since it's Official(R)
<unmatched-paren>...does home-manager even have services, or just dotfiles?
<muradm`>acrow: especially i use guix environment per dev project, and could not find sane way to open at least two projects under exwm. this was the show stopper
<muradm`>atka: no i don't use guix home
<unmatched-paren>Seems like it's just dotfiles, from poking around in the repo
<unmatched-paren>So I guess home is a significant improvement :)
<civodul`>Lumine: i wrote an intro that may be useful:
<muradm`>i used to have shepherd as my first process on login, but few weeks back i moved away from it
<atka_>muradm`: there are two of us! I tried guix home a couple times and it wasn't a pleasant experience
<unmatched-paren>muradm: Huh!?
<unmatched-paren>How do you not use shepherd on guix system? Is it even possible?
<unmatched-paren>atka_: What was the problem?
<Lumine>civodul`: I actually had that already bookmarked, but I was MIA from Guix almost since last February and had no idea what was happening with its development
<muradm`>unmatched-paren: first process on login, not first process on boot :D
<davidl>I want to do sudo npm install -g tern, but it fails ofc, snince /gnu/store is read only - how to get an npm binary installed to PATH?
<unmatched-paren>davidl: Write a node-tern guix package :D
<davidl>oh, that short and easy route xD
<unmatched-paren>Though it should be possible to install it somewhere in $HOME, right?
<davidl>maybe, hopefully
<unmatched-paren>It actually isn't as bad as you think it is.
<davidl>but idk how
<davidl>Im new to it.
<unmatched-paren>I think pip has that functionality
<unmatched-paren>sadly we don't have a `guix import npm` yet
<unmatched-paren>but it shouldn't be too hard
<muradm`>atka_: welcome to the club :D
***gmodena_ is now known as gmodena
<unmatched-paren>davidl: Have a look at gnu/packages/node-xyz.scm for a Node package reference
***lukedashjr is now known as luke-jr
<davidl>unmatched-paren: Im setting up awesome dev environments using emacs and guix, for python and javascript. My python setup is great, now Im gonna do javascript, and I need the tern-server.
<unmatched-paren>Netsplit? Loads of people left at once.
*unmatched-paren looks up tern-server
<davidl>Ok, thx, I'll check it out. I have so many packages to do...
<Lumine>Yep, netsplat
<unmatched-paren>Ohh, it's a code analysis engine
<davidl>I did fwknop, and more in separate channel, but frequently not enough time to get it to guix master.
<davidl>I did rust-grex once, but it bitrotted.
<podiki[m]>shouldn't npm install (no sudo) do a user install? (I don't use node, just guessing)
<podiki[m]>though doesn't mean it will actually work
<unmatched-paren>i believe guixrus has a grex package
<davidl>podiki[m]: I tihnk ur right - do u know what I should maybe add/append to PATH?
***stryan_ is now known as stryan
<davidl>unmacthed-paren: awesome, thanks for that link!
<unmatched-paren>davidl: You might want to invest in some javascript-language-server instead of an ad-hoc engine
<atka_>civodul`: there might be an issue with your home-configuration.scm example in that blog post, if you use that example on a fresh install of guix it will clobber your .bashrc and .bash_profile
<unmatched-paren>because then you can use the same client for all your code analysis
<Lumine>Is there an easy way to ditch home-manager without accidentally destroying half my /home?
<podiki[m]>did you just try "npm install" for it?
<davidl>unmatched-paren: do u have a suggestion for such server? I need it to be used from emacs.
***darosior2 is now known as darosior
***theruran_ is now known as theruran
<unmatched-paren>davidl: eslint i think
<unmatched-paren>not in guix yet though
<davidl>ok, thanks!
*davidl afk
<unmatched-paren>davidl: lists a lot of lsp servers
*muradm` zzz...
***muradm` is now known as muradm
<podiki[m]>what do you mean? if you already did guix install node then npm is in your PATH
<unmatched-paren>i think they mean "how do i get the installed Node packages in PATH"
<unmatched-paren>but maybe we shouldn't be teaching them to use lang package managers on Guix :D
<podiki[m]>emacs has lsp-mode and eglot for language server interfacing, as for an actual JS language server, that I don't know
<podiki[m]>(I've used eglot with python and it works nicely)
<unmatched-paren>Apparently there's a gazillion js language servers :P
<unmatched-paren>But of course.
<unmatched-paren>the JS ecosystem likes to repeat itself.
<unmatched-paren>podiki[m]: Yeah, I use it with ccls
<unmatched-paren>for C
<Lumine>Okay, so I'm using guix home and not home-manager, I got confused of the terms earlier. So it's all good. *hides*
<unmatched-paren>works great combined with bear :)
<unmatched-paren>Lumine: Ahhh
<unmatched-paren>That's why you thought it wasn't invasive :)
<Lumine>Yep .D
<unmatched-paren>Because `guix home-manager` *is* extremely invasive.
<Lumine>I shudder to think
<unmatched-paren>the JS ecosystem likes to repeat itself.
<unmatched-paren>Lumine: You have to create a /data/your-user, because $HOME is made read-only O_o
<unmatched-paren>hey, look at this cool new framework I made to print "the JS ecosystem likes to repeat itself."
<unmatched-paren>(This is the 54th library implementing that functionality, but it's better than the other 53 because it uses $HIP_NEW_PARADIGM.)
<Lumine>That does sound pretty invasive
<unmatched-paren>i think it would drive off a lot of users (including me, probably :D)
<Lumine>But yeah, was wondering the services comment earlier, because I was sure I had services enabled in home :)
<unmatched-paren>I just realized how meaningless my use of $THING would look to an average person. Funny how these things get embedded so deep in your brain :)
<Lumine>I'm excited about tomorrow morning, Guix is coming home, on my desktop :)
<klm1>hi guys! new user here. how can I remove the kdeconnect dependency of i3status-rust? It's very big. I tried (modify-inputs ... (delete "kdeconnect")), but it fails with `wrong-type-arg "string-append" "Wrong type (expecting ~A): ~S" ("string" #f) (#f)`, presumably because of
<unmatched-paren>klm1: It's possible it's some optional feature of that package
<unmatched-paren>you'll have to disable the feature
<m>do i need anything other than sushi to preview files in nautilus?
<unmatched-paren>Oh, wait
<unmatched-paren>You might need to patch it to remove the integration stuff
<unmatched-paren>i'm not sure
<unmatched-paren>try removing the "kdeconnect" string in that map form along with the input
<klm1>yeah, it looks to me like the kdeconnect dependency is hard-coded. But I just started with guix yesterday so I can't really tell what's going on.
<klm1>oh, I can try that - just copy-paste the whole package definition you mean?
<unmatched-paren>Well, you don't need to copy the whole thing
<unmatched-paren>one moment...
***avoidr_ is now known as avoidr
<unmatched-paren>klm1: I haven't tested this, but
<acrow>vagrantc: Finding debian source is not always very easy. For instance, where can I find an origin for "mkcue"? It's in debian, but can it be brought into guix? (for an origin declaration)
<unmatched-paren>acrow: Surely debian provides a catalog of packages from which origins can be queried?
<acrow>unmatched-paren: that is what I am hoping.
***Exagone313 is now known as Exa
***pdg_ is now known as pdg
***jpoiret4 is now known as jpoiret
***hendi_ is now known as hendi
<acrow>unmatched-paren: I thought that the guix-import-debian python package was going to make it easy but, after some fixes and figuring, my target package .dsc file did not point to a source (homepage). Of course, it is in debian at but I'm not sure how to retrieve it without wget. I think there must be an easier way.
<klm1>unmatched-paren thanks for giving me a head start :-) I think the old wrap-i3status still runs, though: