<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. <nckx_>You CC'd 57047@debbugs.gnu.org <nckx_>TBC I wrote that before reading that paste... <nckx_>That's not what I have: Cc: paren@..., 57047@debbugs.gnu.org <nckx_>I am talking about the patches. <muradm>nckx_: you get what is processed by debbugs <nckx_>If that were true, it would have 'processed' your cover letter in the same way. <nckx_>muradm: That's not even the same mail. <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. <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? <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>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' <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 <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_>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_>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_>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? <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. <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>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 https://ttm.sh/wx6.txt 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? <bdju>when I do guix --version <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 ? <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>so I'll try sneaking my environment variable in the 'Exec' line, hoping that's invoked via a shell <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 <jackhill>When a Qt app doesn't show (some?) of it's icons, what am I missing? In this case `guix shell kochmorse ***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>OK, I could fix the accountsservice issue; still to understand how to get the icons to show and the sessions to be found <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>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 <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 <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 <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 <civodul>abrenon, unmatched-paren: match-pattern is from (ice-9 peg) <abrenon>oh, ok, so consistent with the peg:tree on the same line <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). <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 ? <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>(define-peg-pattern records body (and (* SP) (* (and (or record weird-record) (* SP))))) <abrenon>I had started greping the file but I guess I missed that one <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>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>I'm specifically writing it so that the flags are compatible with GNU configure. <unmatched-paren>it'll actually make it easier to package, because i won't have to specify #:make-flags manually :) <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 Makefile.in <unmatched-paren>This one will just write to config.mk instead of modifying the makefile directly <civodul>apteryx: does lightdm-gtk-greeter have a wrapper to set XDG_*? <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>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 <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 <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>Eh, I don't need to send that bug report. I figured out the problem, anyway, so I can just send a patch :) <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>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>but not the autotools 'load of workarounds for missing features' thing <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 <civodul>glib depends on bash-completion since 8b8e6118769f4dedb835144c69a63636cb367ad1 <civodul>it's not referenced (in the sense of "guix gc --references") <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>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 ***Noisytoot is now known as [
<civodul>unmatched-paren: i suppose we've had time to get the new version of Nettle, no? <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 ***Dynom_ is now known as Guest5898
<two[m]> * could be `grep ^emacs\` instead of awk <two[m]>could be grep ^emacs` instead of awk <unmatched-paren>because --list-installed shows a detailed record of installed packages <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` <two[m]>i think formatting would be not good to show with s/ <unmatched-paren>when you write a long message, it truncates it and you need to open a link to read the full thing <apteryx>ah, lightdm clears the env itself for the child processes (seats) it launches: process_set_clear_environment (script, TRUE); <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 <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) <unmatched-paren>haugh: for example, (file-append emacs "/bin/emacsclient") is a gexp that returns "/gnu/store/...-emacs-.../bin/emacsclient" when ungexped <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 ;-) ***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
<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? <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 <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 <ekaitz>hi can anyone point me to a package that is always cross-compiled? does that exist already? <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? <ekaitz>muradm: I want to package a toolchain for GameBoy Advance <ekaitz>and it needs some libs, that must be compiled for a GameBoy <ekaitz>unmatched-paren: yes the arm one is enough I think, but how should I package a library for the GBA? <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. <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 <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? ***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? <muradm>ekaitz: (package (supported-systems ... )) <unmatched-paren>because they're not building the lib so that they can use it on their guix system <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>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 <ekaitz>another option is to insert it in source in the project and leave it like that <muradm>ekaitz: what ever you want to do, can you do under debian for instance? <ekaitz>unmatched-paren: yeah! that's the thing! <atka>when it comes to wayland and tiling on guix, its pretty much just sway? <ekaitz>thanks unmatched-paren and muradm ! <podiki[m]>atka: I don't know of other wayland tiling WMs more generally, but I'm not on wayland (mostly for that reason) <atka>unmatched-paren: dwl is a nonstarter, development of foss software over discord... <atka>ctrl+t before everything gets old <atka>though I do that on dvtm atm <atka>I'm very much a dwm user but trying to move to wayland <muradm>atka: just curious, do you have issues with 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 <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 <atka>unmatched-paren: I meant the guix side of it <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 <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 <muradm>atka: just be aware of 56690 issue <muradm>unmatched-paren: for bare minimum, you don't need greetd, default mingetty should work <unmatched-paren>atka: Also, if you run seatd, you won't have polkit, which means no upower or pulse <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 <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 <atka>unmatched-paren: thanks but I much prefer tty <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 <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? <muradm>acrow: more opportunities, but problems also ) <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 :) <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. <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>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>Lumine: `guix home` doesn't lock down your /home like `guix home-manager` does <unmatched-paren>And it's probably got more home-services than home-manager, since it's Official(R) <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`>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 <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? <davidl>oh, that short and easy route xD <unmatched-paren>Though it should be possible to install it somewhere in $HOME, right? ***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 looks up tern-server <davidl>Ok, thx, I'll check it out. I have so many packages to do... <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) <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 <Lumine>Is there an easy way to ditch home-manager without accidentally destroying half my /home? <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
***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) <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>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.) <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 <m>do i need anything other than sushi to preview files in nautilus? <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? ***avoidr_ is now known as avoidr
<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 source.debian.org but I'm not sure how to retrieve it without wget. I think there must be an easier way.