<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>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?
<roptat>and now it's stuck waiting for interaction...
<gordon1>how to figure out why certain profile exists? i have this /gnu/store/ir0m129lbvr1f0yl0sh4bpp3q8d8rk9f-profile.drv, guix gc --referrers is empty for it but guix gc refuses to collect it as garbage
<gordon1>btw there are bunch of such store entries that i struggle to find out the reason why they are still there
<roptat>it's probably linked from /var/guix/profiles
<civodul>gordon1: note that .drv is for "derivations", which are the build instructions to actually build the profile
<gordon1>no, i checked everything that is in guix gc --list-roots as well as checking every symlink from /var/guix/profiles
<unmatched-paren>all the problems i was having yesterday appear to actually have been kernel problems
<gordon1>cbaines: then how to find out why it is not collected as garbage? there has to be a way that guix gc decides to keep it
<gordon1>even more interesting, i have this dbus derivation /gnu/store/pqpnqcz1m1i6wg5d99wx1p5s43msqn9b-dbus-1.12.20.drv but no corresponding store item that contains dbus itself, i.e. no /gnu/store/longhash-dbus-1.12.20 meaning it never actually was executed, right?
<roptat>alright, now I get "Anthy: Failed to create profile directory", which is getpwuid(getuid())->pw_dir
<roptat>I suppose this doesn't work inside the build environment?
<unmatched-paren>changing the default tty worked for the ModemManager message, but there's still a few left: "Missing Free firmware (non-Free firmware loading is disabled)" and "Unable to load firmware /*(DEBLOBBED)*/ (-2)"; i presume that's because there's no firmware available for my wifi card (i'm using an thinkpenguin wifi adaptor)
<brandhout>Hi ! I'm trying to package a newer version of DWM for guix. Everyting runs but I've got a problem with the freetype2 dependency. The config.mk of DWM has a hardcoded reference to /usr/include/freetype2 as Cflag. I need to substitute this with the guix freetype path $(guix build freetype). Does someone have an example of this use case or some
<jpoiret>the only thing i can think of is mismatched ABI but that shouldn't happen with `guix pull`ed guixes
<jpoiret>can you start `guix repl`, then do `(use-modules (gnu system setuid) (gnu packages base)) <RET> (setuid-program? (setuid-program (program (file-append hello "/bin/hello")))) <RET>`
<jpoiret>ahhh but actually it's not this one that's responsible
<jpoiret>I suggest opening a bug report, because it is very weird that this is happening
<jpoiret>somehow, setuid-program? doesn't return #t for the elements of %setuid-programs
<jpoiret>so the field sanitizer of setuid-programs tries to wrap it in a new (setuid-program (program ...)) for backward-compatibility, leading to the original setuid-program record being lowered by being inserted into a gexp, which isn't possible, hence the error
<rekado>mbakke: commit e301f1a8ed11f9eacb2b7f525a7446dc00621a8b broke the ci.guix.gnu.org config
<samplet>I have some (bitrotted) patches that simplify commencement.scm using modern Gash that I’d like to return to eventually. If GHC 4 gets in the way, I might complain a bit, but I’m sure I’ll survive. :)
<apteryx>civodul: we've filled 15 TiB of compressed/raw NARs on the new 22 TiB array thus far; I think we should move swiftly to deprecate one of the compression schemes, it's too expensive at this point.
<roptat>a talk needs to be pre-recorded, with no drastic time constraints (between 15 and 45 minutes)
<roptat>a bof session is just a discussion session about a topic that you will lead/facilitate
<roptat>no need to prepare anything for a bof session. At this stage, it might be the easiest. If there's a topic you want to see during the guix days, it's the only way to make sure we'll talk about it ;)
<cbaines>apteryx, at the moment, the nar-herder doesn't really handle anything complex like nar compression. The actual creation of an lzip'ed nar occurs on the machine that built the thing (which is good for distributing the work and efficient sending over the network), and it's then sent back to the coordinator, which then runs a build success hook which contains the code to generate the narinfo file, and import the narinfo plus
<cbaines>compressed nars in to the nar-herder database
<cbaines>so, to directly answer your question, it's all ahead of time
<apteryx>civodul: getting rid of gzip would be a saving of at least 6.5 TiB, according to 'du -sh /mnt/btrfs-pool/@cache/guix/publish/gzip'
<apteryx>or about a third of the new array capacity
<podiki[m]>roptat: thanks for the reminder! I've been meaning to send in talk proposal (my experiences going all-in on guix from nothing, 6 months later)
<roptat>great! please send it as soon as possible!
<cbaines>apteryx, as I understand guix publish, the compressed nars on disk are treated as a cache. So things should still function if they are deleted (it'll just mean the compressed nar is generated on request)
<roptat>podiki[m], deadline for proposals is... tomorrow
<roptat>and deadline for a video of the talk is this Saturday (Feb. 12)
<cbaines>I think the guix publish cache has been treated as "storage" though, so there are probably cached compressed nars that correspond to store items no longer in the store, so deleting things from the cache might result in requests not being fulfilled
<apteryx>and it is guix-publish itself which generates them, according to some heuristics and the compression field of 'guix-publish-configuration' (for berlin, (compression '(("gzip" 9) ("lzip" 9) ("zstd" 19))))
<podiki[m]>roptat: so says my org-mode deadline too.... better get on it!
<apteryx>cbaines: if I understand, after removing gzip from the above configuration of 'guix-publish-configuration' for berlin, it wouldn't advertize gzip'd NARs anymore.
<apteryx>(and the associated gzip cache files could be safely deleted)
<apteryx>people running a daemon older than ~June 2019 wouldn't find any substitutes -- that seems reasonable; that's nearly 2 years, with the 1.3.0 release somewhere in the middle.
<cbaines>that seems rather recent to me, although my sense of time has been warped in the past couple of years
<cbaines>stopping providing gzip substitutes seems like a thing to plan, publically discuss a schedule for, then carry out
<zimoun>or, often I overlook at a news because I am focus on something else.
<civodul>apteryx: --news prints the last news, so it's kinda like the GNOME notifications: you can look at them later :-)
<apteryx>does it? it shows nothing for me currently
<zimoun>apteryx: I think “guix pull -l” is currently useless. Except if you run “guix pull” everyday. For instance, mine is displaing 205 new packages and 538 packages upgraded, and it is like that for several generations.
<apteryx>my guix is at ff14bc60e56fb0c6636da1da9a850b7b04abb367
<gnoo>how do i know the reverse dependencies of a service that is currently running ?
<zimoun>civodul: I think regular user are doing at best “guix pull” once a week. git log --after 2022-01-24 --oneline | grep Update | wc -l returns 201. Therefore, the output of “guix pull -l” is useless, I guess.
<KE0VVT>zimoun: It's hard to pull it all the time.
<zimoun>201 is for 2 weeks, for the last week, it is 162.
<zimoun>KE0VVT: yes, I agree. That’s my point. :-)
<zimoun>rekado: on foreign, all fresh, “guix install texlive-base”, then “pdflatex foo.tex” returns Font OT1/cmr/m/n/10.95=cmr10 at 10.95pt not loadable: Metric (TFM) file not found.
<civodul>i could give it another try to try to get debugging info
<civodul>but it's tricky because it hangs before syslogd is running
<civodul>and presumably before userland is running
<zimoun>civodul: --news displays only the news and changes for the last revision. I think it is fine as it is. Instead, it is --list-generations which displays too much
<lfam>After many failed boots, I have sometimes noticed the final lines of a kernel panic trace, but not enough of it to learn anything. I don't know how I can access this trace
<lfam>There's also some hints that it may be related to wireless drivers, wifi and / or bluetooth
<lfam>I wonder if nckx's affected machine has any wireless technology in use
<lfam>I think there was another problem in 5.15.16 related to nouveau / nvidia, but as far as I can tell, this is a separate issue
<lfam>Because, I don't think any of us have nvidida cards and 5.15.16 works for us
<mbakke>lfam: I have a Guix system configuration snippet that can assist with bisecting the kernel if you want to go that route
<mbakke>lfam: does the problem occur on vanilla linux?
<lfam>mbakke: I would like to bisect but I don't have access to capable hardware. The affected machine is a Thinkpad x200, so building the kernel takes many hours. And berlin spends most of its time in GC these days
<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
<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)?
<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
<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.
<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 ?
<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`