IRC channel logs
back to list of logs
<KE0VVT>Is (keyboard-layout "gb" "dvorak") valid? <the_tubular>Anyone know how to setup Mac randomizer with Network Manager using guix ? <the_tubular>OR maybe even without network manager, but I feel like it's pretty important to guix <paladhammika>the_tubular: also interested in doing this for myself just haven't done so yet. you would have to make a shepherd service. <paladhammika>the_tubular: look in the reference manual for g-expressions and shepherd root services. you'll have to make a "one shot" service which runs at boot. <the_tubular>I'll give it a shot, but I'm still confused about the difference between shepherd services and services <paladhammika>the_tubular: i don't think there is a difference -- someone correct me if I'm wrong
***Xenguy_ is now known as Xenguy
<jaft>Hullo! I was wondering if anyone has had any success with having their Android phones get detected? I'm using GVFS with Thunar; I originally posted about my issue at https://www.reddit.com/r/GUIX/comments/s55e8m/smartphone_detection_with_gvfs/ and the gist was that I noticed that my udev 69-libmtp.rules file on my Debian machine had a ton more entries than the one served up by Guix. With a little help, I was able to add an updated <jaft>version, with everything the Debian machine has, to udev-rules which caused Thunar to recognize my Android when I plugged it in but was still unable to mount it, any. <jaft>Clicking on the device resulted in no interaction and right-clicking the listed device and manually selecting "Mount" resulted in the message, "No mtp devices found," still. I haven't gotten anywhere beyond that, sadly.
***califax- is now known as califax
<apteryx>jaft: there's an android-udev-rules package in guix you can use to extend the udev service <apteryx>that should do it, although if your phone is very new, you may need to update the package first <jaft>Ah! That's fantastic; I couldn't figure out where Debian was getting their device list from so, at the very least, it should avoid that issue, for me. I'm gonna try it out. Thnaks a ton! <apteryx>there should even be an example in 'info guix' about it <apteryx>info guix -> i udev-rules-service RET <apteryx>press space once, example should be in the middle of the screen <paladhammika>hello guix. i'm attempting to solve why no audio goes through my input. most of the suggestions I see online involve tweaking something in /etc/modprobe.d/ but no such directory exists in guix, are these files stored anywhere.
***sneek_ is now known as sneek
<munksgaard>Is there a way to convert a nix derivation to guix?
***aya is now known as gyara
***Guest42 is now known as davidl
<lfam>Yeah, that's the bug that's killing aarch64 support <cbaines>apteryx, if that behaviour is actually a bug in Guile, I guess it's going to be difficult to fix <cbaines>re-architecting the Cuirass workers to either use threads rather than forking, or fork using safer paths in Guile (open-pipe*, system*) <apteryx>aren't guile-fibers about threads? I thought the issue occurs before of guile-fibers, but I haven't delved into the specifics (yet). <lilyp>fibers are more lightweight than threads, but yeah, they're nondet if that's the problem <cbaines>apteryx, I don't think Cuirass uses fibers within the remote worker. <cbaines>THe Guile docs say forking is unsafe from a process with multiple threads <cbaines>and given Guile's GC uses threads, my guess is that if you're using the GC, you can't just call primitive-fork and expect it to always work fine <apteryx>hmm... Wouldn't that mean that using primitive-fork would be generally unsafe in Guile, as Guile can decide to run its GC anytime, right? <apteryx>that sounds like a bug in Guile :-/. Users of its API shouldn't worry about shooting themselves in the foot like that. I'll bring it into #guile. <cbaines>I think I had similar issues back when I wrote the job processing in the Guile data service <apteryx>neat; seems we have something actionable to work on. I'll reference this thread to the Guix discussion, thanks! <cbaines>The guix-data-service still uses primitive-fork, but calls execlp soon after in the new process, which I think is the important bit <apteryx>hmm, actually the problem would be forking in threads, rather spawning threads from forks <cbaines>maybe Guile's not always displaying the warning when it should <florhizome[m]>Hey guix, how can I just have guix home “register” a config file, so it will safe it in this generation and in the next ones, and I can use rollbacks on it, without letting guix do anything on the file content?
***darosior5 is now known as darosior
<cbaines>apteryx, actually looking at the Guile code, maybe it's not as related as I thought. The GC related thread is stopped before forking, so maybe there is only one running thread when Cuirass forks <efraim>apteryx: regarding frozen aarch64 build machines, anecdotally when I limit my pine64 to use 2 cores of the 4 I haven't gotten system lockups <cbaines>that said, I'm guessing there must be something related to what the Curiass remote workers are doing that triggers this <cbaines>I've had other GC issues with the Guix Build Coordinator agents, but I don't think I've had a lockup issue <apteryx>efraim: odd. Perhaps a useful data point. <rekado>sneek: later tell zimoun Yes, with itemize it fails because the tcrm1000 font file isn’t found. It’s provided by texlive-fonts-ec. <efraim>ok, finally got webrtc-audio-processing building on all architectures (except mips64el, don't have that one hooked up currently) <efraim>rekado: "Don't long for headers"? <Haider>General question, when I use profiles (manifest files) to install Emacs packages, dont actually showup in Emacs. However, If I install them as a global package in my /etc/config.scm they manage to show up. What am I doing wrong here? <efraim>do you have emacs in your profile or in /etc/config.scm? <Haider>Emacs is just installed using my config.scm <Haider>does emacs have to be installed locally using the profiles(manifests)? <rekado>efraim: this is Perl 5.14 from Guix Past <efraim>rekado: I figured as much the last time you were working on it <efraim>I also noticed that there's a ghc-4.08.2 release for powerpc-linux <jpoiret>Haider: yes, emacs has to be installed in the same profile as the emacs packages <jpoiret>this is because of how search-paths work in guix <Haider>Thank you. Will try that now (trying to make my system more reproducable and not use "use-package" as much) <jpoiret>basically, search-paths are something that belong to the package that uses them, here emacs, so you've got to have the base package installed along with its "plugins" for all of the search-paths to be computed properly <jpoiret>this ensures that if you do a `guix shell emacs somepackages`, you will have an emacs with only those packages available
***bdju_ is now known as bdju
<futurile>hmm I sent a patch and wanted to send some comments that didn't need to be in the git commit. It's resulted in two deb-bugs (#53859, #53860). What did I do wrong? I did: git send-email --compose ../001-blah.patch <jpoiret>futurile: you need debbugs to assign a bug # before you can send follow up emails <jpoiret>you'd then have to send to the NNNN@debbugs.gnu.org email address <Haider>yes, im back again. (sorry for all the nooby questions including this one) but for some reason, none of the packages installed by the profiles are actually accessable using a terminal. All of the profiles are active. <attila_lendvai>shouldn't the shepherd make-kill-destructor wait for the process to exit? without that `herd restart foo` restarts too early. <apteryx>I remember working around that with some waitpid in the stop for the jami-service-type <apteryx>I guess it's a rarely exercised condition in the service tests (the restart), or that it somehow doesn't matter for most services <the_tubular>jpoiret, umm didn't know about that emacs thing. I haven't test this out yet. <the_tubular>What if I install emacs with a manifest and with a config.scm <the_tubular>Will I be able to use every emacs-* packages installed with my config and in my manifest ? <jpoiret>now that i think about it, it should since activating a profile only extends the env vars not override them <the_tubular>I'll definitely test this out. But my VMs are down at the moment...! <apteryx>rekado: thanks for fiing the texlive font maps; I have this in my local todo: "** TODO LaTeX updmap, hyphen, etc profile hook" <apteryx>seems you took care of the first item :-). <the_tubular>Just to make sure I understand right, as long as I have emacs in my system config and my manifest, I should be able to use emacs "plugins' (I don't know what they are called) that are both in my system config and my manifest ? <jpoiret>the usual pitfall to avoid is that you need emacs to also be installed in the profiles that add emacs packages for the env variable to be updated <pkal>What is the easiest way to check out the source of a guix package? <jpoiret>pkal: what do you mean by "source"? the package definition in the guix sources, or the actual source code used to build the packaged? <pkal>jpoiret: I'd like to work on the source of a package to prepare a diff. What I am looking for is something like an imaginary command "guix hack foo" that downloads the source, check in out in the current directory and starts a shell with all the development dependencies installed. <pkal>Ideally if the package has a git source, then with a git checkout too <jpoiret>guix build -S package will give you the source in the store, that you can copy outside, but i'm not sure it will have the .git with it <jpoiret>starting the shell is just a matter of doing `guix shell -D package` <pkal>What is bothering me now is that guix shell -D is trying to build the package I am debugging. <KE0VVT>How do I set up a ReadyMedia/MiniDLNA service? <pkal>I figured it out, "-D -L . foo" is not the same as "-L . -D foo"
***califax- is now known as califax
<KE0VVT>Does anybody have a media server on Guix?