IRC channel logs
2024-11-07.log
back to list of logs
<meaty>Has anyone else had issues getting bluetooth headphones to work? I try to connect them in bluetoothctl and they either a) immediately disconnect twice with "br-connection-unknown" or, after restarting the bluetooth service, connect but don't appear in pavucontrol as a sink. ArchWiki reccomends installing pulseaudio-bluetooth or maybe pipewire-audio, neither of which exist <meaty>my bluetooth mouse works fine, it's just the headset <meaty>*looking at it now my headpones have changed their name in bluetoothctl from "Bose QC Ultra Headpones" to "LE-Bose[...]", despite having the same mac address[?], idk what's going on <meaty>ik it's not a hardware issue, this same setup had almost no issues* when I was using Nix (*I did have to forget and re-pair each time I connected though) <meaty>I just tried forgetting and re-pairing too, still no sink appearing <meaty>The wiki reccomends adding this line to /etc/bluetooth/main.conf, but I cannot find the equivalent in the bluetooth-configuration data type as described in the manual <mange>Sorry, all I can offer is my sympathy. Getting Bluetooth working on any distribution has always been a struggle for me. I haven't tried with a Guix system in a long time. <mange>It looks like you could inject that config, hackily, with something like (name "BlueZ\nEnable=Control,Gateway,Headset,Media,Sink,Socket,Source"), based on a quick read of gnu/services/desktop.scm <mange>That could at least confirm whether it works. A proper fix would be to patch the service to allow that config to be set properly. <meaty>could you elaborate? where would I place that phrase <mange>In the bluetooth-configuration object. <mange>The configuration file is written with (string-append ... "\nName = " (bluetooth-configuration-name config) "\nClass = " ...), so we can inject arbitrary stuff in there if we want to. :) <mange>It's not pretty, and I think there should almost always be a catch-all "just write this into the config", but since bluetooth-configuration doesn't have that we can hack it ourselves. <meaty>wierdly it is now stuck in low-quality phone call mode, but w/e <meaty>a step in the right direction <mange>My bluetooth headphones are always in low-quality phone call mode if there's anything on the system asking for a microphone. I think the protocols for high quality microphone stuff over Bluetooth are all vendor-specific propriety things. <meaty>aha, I actually had to disable certain capabilities, then tell it to never work in phone call mode <meaty>hopefully this Just Works (tm) from now on <mange>Are you leaving the name hack in your config? :/ <mange>I only intended that to be for experimentation! <meaty>what else is there to do lol <getstate>sent out a review for 74227 instead of 24228 :( <jaft_r>Only one I know of, outside of GuixSD. <marmar>how do I use weechat-matrix? most guides I read needs you to run the python script, but it fails. don't know if it needs a specific path or something else <sneek>Welcome back marmar, you have 2 messages! <sneek>marmar, nckhexen says: It depends on what you mean by add. There are no hidden defaults. (substitute-urls '("...us-east...")) will not query any other server. You must manually {ap,pre}pend %default-substitute-urls) <sneek>marmar, nckhexen says: if you want that. <Ironsmith>heya! in guix is it possible to list a (file-system) as a dependency of another (file-system)? <Ironsmith>i'm trying to do add `(dependencies (filter (file-system-mount-point-predicate "/early-mount") file-systems)` but i'm getting `file-systems: unbound variable` which makes sense since this is within (file-systems)'s definition (so it doesn't exist yet) <Ironsmith>that's another reason i wanted to try setting a (file-system) entry to a symbol via (let) but i keep getting `extraneous field initializers (let)` error even though it doesn't complain then the literal (file-system) is in place <Ironsmith>i tried setting `(needed-for-boot? #t)` in the (file-system) but the mount step in initrd is still under `#:mounts` instead of `#:pre-mount` <Ironsmith>what does `extraneous field initializers (let)` mean exactly? <Ironsmith>is there anything wrong with my definition? `(let ((early-mount (file-system (mount-point "/early-mount") (device (file-system-label "early-mount")) (type "ext4") (needed-for-boot? #t)))))` <meaty>Has anyone here use the Guix build of retroarch? I think it's been misconfigured, the menu option to download cores through the app is missing <meaty>I looked around and found this is common for distros/platforms which either have to come with the cores preinstalled (xbox) or which have the cores in their package manager, but guix has like, 2 cores packaged <meaty>looking into it further according to the info files 62% of the cores are gpl licensed <meaty>actually, some basic terminal math shows only 7.4% of the cores have nonfree licenses <meaty>based off of the retroarch-core-info package <meaty>(cd $(guix build retroarch-core-info)/lib/retroarch; grep 'license = ' * | sed 's/.*:license = //' | sort | uniq -c) #for a license breakdown <meaty>I wonder if we could instead patch retroarch-core-info to exclude the offending cores? <futurile>sneek: later tell Ironsmith regarding your Q about file mounts, you're probably best to post it to the guix-help mailing list, better chance of getting an answer on StackExchange <futurile>Morning all, hope you're having a bearable Thursday ;-) <Rutherther>tschwinge: hi. I mean I would expect that. The search paths are stored with the definition of the package. You don't know the package definition from the store path. So the information about search paths is lost. I am mainly quite surprised guix even allows guix install directly on gnu store paths <tschwinge>Rutherther: Interesting, thanks for looking into this. <tschwinge>So, what then is the right way of doing 'guix install --system=i686-linux gcc-toolchain@4.8.5' on a x86_64-linux system? ('guix install' doesn't support '--system=[...]'.) <futurile>I do that all the time, so it might be a bug. <yelninei>tschwinge: Does it work with guix shell (for a workaround)? <tschwinge>yelninei: Yes, 'guix shell --system=i686-linux [...]' works as expected -- but I'll have to think how to fiddle that into my non-interactive workflow/build scripts. <tschwinge>..., or should I "just" try to make '--system=[...]' work for 'guix install'/'guix package'? ;-) <Rutherther>tschwinge: ideally you could package the build scripts so they just use correct dependencies. Or you an also give them shebang with guix shell to provide the dependencies <PotentialUser-3>Here is a curious thing: I am using Librewolf for video conferences. I grant access to the camera and I can see myself, but other people cannot see me (and the test Zoom call confirms that). <Rutherther>PotentialUser-3: I have no idea, but did you try checking the console for any errors? also is it only zoom or also other platforms? <yelninei>tschwinge: You can pass a command to run in the new shell after a -- which should also work non-interactively <PotentialUser-3>I could not find any related "privacy" settings in Librewolf. Another possibility would be a problem with two threads accessing the camera device? But I'm going far off with this. <Rutherther>PotentialUser-3: I would be surprised if this was related to privacy settings, since if you already see yourself you already gave all the permissions... it seems very strange it would show it just to you and not send to the other party. So to me it seems more like some sort of a bug where the screen is not transferred to the server. But yeah, I don't know <Rutherther>PotentialUser-3: open developer tools, ie. Ctrl-Shift-i or right click and inspect. Then go to console tab, turn on your camera and see if new error has appeared <PotentialUser-3>Rutherther Nah, I could not recognize any clue there. Thank you for helping. I'll try another browser. <PotentialUser-3>Rutherther However, I tried it with qutebrowser, and there I was asked for permission to /record/ video (in addition to access to the camera), and it did work there. <Rutherther>PotentialUser-3: so in librewolf it did not ask for permission at all? I expected it did. On the left of url you should have permissions, and if you try to turn on your camera it should ask for permission there, then the site will get the permission temporarily <Rutherther>PotentialUser-3: but I think that as soon as you see yourself the permission should already be given <PotentialUser-3>Librewolf asked for permission to use the camera, the microphone, notifications. <PotentialUser-3>Qutebrowser asked permission to use the camera, the microphone, notifications, and video recording. <PotentialUser-73>If I understand things correctly, `with-patch` should replace all inputs in the dependency graph of a package with the patched version, but I'm having troubles with a rust package, and I suppose it's because the dependency is not in the 'inputs' field, but in the `#:cargo-inputs` parameter of the cargo-build-system <PotentialUser-73>First, would this analysis be correct? and secondly, is there a workaround then? or how would I approach this? Thanks in advance for any pointers <Rutherther>PotentialUser-73: yeah, it's because of cargo-inputs. I am afraid there is no built-in transform or function that would allow you to replace cargo-inputs. So if you wanted to do it you would probably have to write a function that would recursively replace the dependencies based on cargo-inputs. <PotentialUser-73>alright, thanks for the confirmation! I'll have to test how good my guile is... (spoiler: not that great yet '=D ) <rekado>so I can't tell if there are new build failures <Ironsmith>thanks futurile, i'll give the mailing list a shot! i didn't get the message from sneek though, or is there a special way to ping him? (i checked the #guix logs) <sneek>Welcome back Ironsmith, you have 1 message! <sneek>Ironsmith, futurile says: regarding your Q about file mounts, you're probably best to post it to the guix-help mailing list, better chance of getting an answer on StackExchange <Rutherther>Ironsmith: sneek will tell you the message when you actually send a ssage, yeah :D <PotentialUser-3>I see a significant backlog in the patch tracking database for Guix. <PotentialUser-3>Given that so many Guix "packages" are falling behind the most recent releases, could someone explain to me why contributions are being silently rejected? <rekado>they are not explicitly rejected; they are not processed. <rekado>the cause is a lack of patch review work <futurile>PotentialUser-3: if you care about being up to date on particular things, the easiest thing to do is to run your own channel - there's also other community channels you can follow <Rutherther>PotentialUser-3: also transformations are a great way to change stuff like version of a package. Of course it has limitations - It doesn't work if the build process changed, dependencies changed and also if the source is not one of the supported formats for the tools to be able to infer new source <PotentialUser-3>rekado I understood that. I saw some rejections in there. It is also clear that reviewing patches is unpaid work, and it is nice to have quality reviews. <PotentialUser-3>However, at the same time, using Guix System implies an additional effort over that is not present on the more popular distros. <PotentialUser-3>Looking at contributions in limbo for almost 6 months makes one consider if my contributions would meet the same fate. If me asking for help would be ignored. <PotentialUser-3>I am still new to Guix, so I am still trying to figure out how things are around here. <PotentialUser-3>futurile If I understood things correctly, my channel would distribute my packages/recipes. I would still need to write the packages for them. And, unless it is something trivial, I am unable to do it at the moment. <PotentialUser-3>I do have one such trivial update to submit, though. I hope to make more to learn how things ought to be done. But if things stay "stale" due to lack of feedback, it does not help. :-( <PotentialUser-3>futurile I would love seeing a list of community channels. Or, a way to "tip" a person that was quite helpful, like "hey, thank you for updating the package for FOO! Let me pay you a beer." <Rutherther>it's just encoding of some chinese/japanese (I don't know) characters. So maybe it makes sense to some people when written with those ones :D <PotentialUser-3>Rutherther Yes. And some times there is one test that is added and it breaks things because the build is done in an isolated environment. That is also a challenge I have been facing. Ignore the test or address the situation? <futurile>PotentialUser-3: there's some fairly common ones, nonguix and uh whatever the games channel is, but also some users keep channels so it's one way if you need to be ahead of Guix mainline <futurile>PotentialUser-3: I'm not suggesting it's a full solution - it's not. But the fact that we have a lot of patches and not enough committers looks pretty intractable <Rutherther>PotentialUser-3: for my own use case I wouldn't hesitate to use --without-tests as well. Or if I had more time I would figure out how to turn off that one specific test and put it to my channel <weary-traveler>i think splitting off guix packages that are "non-core" from guix and having a more permissive who-gets-to-commit policy for the majority of packages would help <PotentialUser-3>Rutherther That service is much faster than the "packages" page in the Guix website. I should bookmark it. <Rutherther>PotentialUser-3: oh, do you know about guix search? you don't need that packages page on guix website at all if you are using guix <futurile>weary-traveler: agreed, there have been discussions about this in the past but they never got to conclusion. And, there are some constraints in using the GNU infrastructure. <PotentialUser-3>Rutherther I know about it, but I'm not running Guix on all of my machines. <weary-traveler>futurile: from the most recent discussion it didn't seem like ludo' was opposed to it. could you elaborate on the "GNU infrastructure constraints" please? <futurile>weary-traveler: there's no ability to only add users to a section of the repo or a branch, it would have to be separate repo. <PotentialUser-3>jackhill Oh, I just hate that on btrfs! I usually got out of that situation by forcing a rebalance of the data. <futurile>weary-traveler: I had the initial clever idea of letting beginners commit to certain areas only, turned out that's a GitHub thing. So we couldn't stay with the a monorepo. Have to be more like ArchLinux does it as a separate repo. <weary-traveler>futurile: yeah - i think keeping different repos with different levels of trust is the way to go <jackhill>PotentialUser-3: yeah, I wondered about balance, but there seemed to be some space in the metadata pool too. I'll give the rebalance a go. <weary-traveler>futurile: that approach (different repos) could also be combined with submodules <PotentialUser-3>jackhill Yeah, do the metadata first. I think it goes faster. Filter by low percentage values for usage and increase the number in each invocation. This is more relevant when you go to the data block group. <pjals>Why is Guix insisting on building a development manifest of packages with #:target "i686-elf" with x86-64? Is it because I'm also using contatenate-manifests? <PotentialUser-3>futurile May I ask how the project has structured the access to the repository? I was expecting some delegation of responsibilities to different areas. Kind of like how it happens with the Linux kernel. <pjals>For some reason in the manifest entry no architecture is set. It doesn't have any indication that it's cross compiling, so it probably isn't. How can I fix this? <futurile>PotentialUser-3: there's 'teams' which focus in different areas. There's some committers who work across multiple different areas. There's not a technical constraint that prevents a committer from committing in different areas. And generally, that wouldn't be good for the project - this isn't Debian - I think the total authorised committers is just under 50. <pjals>Seems like it is not respecting the difference between native-inputs and inputs at all.. <Rutherther>pjals: "(package->development-manifest bash #:target "i686-elf")" gets me package gcc-cross-sans-libc-i686-elf, even in concatenate manifests <pjals>I think I figured it out, I need (setenv "CC" #$(cc-for-target)). So much for "package definitions do not have to mention them". <pjals>I was using my own package definition of a library, that's why. <pjals>Rutherther: Seems like that doesn't work either, when I set supported-systems of the package to '(), it says it "does not support x86_64-linux" <Rutherther>pjals: as far as I can tell supported-systems means systems that can be used for building the package, your system is x86_64-linux, so if you don't put x86_64-linux in it, it won't get built <pjals>But the documentation says that it's the list of systems supported by the package, which I assume it means it runs on? It mentions it is strings of the form architecture-kernel which seems to suggest I'm correct. <pjals>Rutherther: Also, even with the setenv, it seems to still be compiling for x86-64 when I want i686. <Rutherther>pjals: like if you are building the package via guix? I thought you were first trying to use a shell. So which is it? <pjals>I am building a library I need for my project purely with Guix. <Rutherther>pjals: so currently you have a guix package that you are running guix build --target i686-linux on, right? <Rutherther>pjals: so how does your build environment look like - as in, how does it know what gcc command to execute? <pjals>No, I have a package that I'm building the dependencies of through package->development-manifest with #:target "i686-elf" and those dependencies (and not native) are stubbornly not building for i686. <Rutherther>pjals: okay, so you are not building it purely with guix. You are just using guix to get the dependencies <pjals>Rutherther: The dependency is being built using Guix, and the dependency is the thing I am having problems with. <Rutherther>pjals: so then when you enter the shell you do not have i686-elf-gcc in your PATH? <pjals>Rutherther: I have a manifest that I am using by invoking `guix shell -L . -m manifest.scm` and it concatenates two manifests: A manifest generated by package->development-manifest where the package has a dependency newlib which is built using Guix, and another irrelevant manifest containing debugging utilities. I am invoking package->development-manifest with #:target "i686-elf", which should make the <pjals>development dependencies compile for i686-elf, even though they arent. <Rutherther>pjals: okay, I see the issue now. Seems like a bug then <pjals>Rutherther: What's even weirder is that according to commit d98a0203 (shell: ‘--development’ honors ‘--system’.), this bug should be fixed. <pjals>For reference, that commit is almost a year ago. <pjals>Rutherther: Ah, nevermind, that seems to be fixing a caller to package->development-manifest. Whoops! <pjals>Seems like package->development-manifest does not compile dependencies for a target. It simply gets the dependencies for compiling a package for a target. <pjals>Rutherther: Yes. I got confused. <Rutherther>pjals: it wrongly "gets dependencies for compiling a package for a target", since you won't be able to compile it if libraries for the target are missing <pjals>Rutherther: What do you mean? <Rutherther>pjals: package->development-manifest doesn't do its job <pjals>Rutherther: I think it has a useful job, but the documentation doesn't reflect that. Also this applies to all -D (i think), because the "issue" is in the package-development-inputs procedure. <pjals>Though if this really is an issue, this can be easily resolved by simply mapping on the return of package-development-inputs and using cross on them. <Rutherther>pjals: it's not resolved like that, since that wouldn't respect native inputs <pjals>Though, I feel like packages should resolve this themselves with a gexp in the configure flags. I'm going to try that first. <pjals>Seems like %current-target-system is simply not being set when building development packages. This is very strange. <pjals>I fixed the bug by setting %current-target-system in (bag-transitive-inputs), should I push this? <Rutherther>pjals: that's nice. I mean I am not completely sure, but to me it really does seem like a bug. I would expect to be able to build a package X for target I specify when I enter a shell with package->development-manifest. This prevents it, since the libraries are not provided <Rutherther>pjals: I see that it was ludovic, who added the current-system and current-target-system 4 years ago, with commit stating ensure bags are insensitive to current-system / current-target-system. So there must've been a reason for that <Rutherther>pjals: maybe it would make sense to open a discussion about it on the mailing list, CCing him? <pjals>Rutherther: Maybe I should just submit the patch and CC him there? <pjals>Andr-- Replicant seems like a run-of-the-mill FHS Linux distro, so probably? <Rutherther>pjals: thinking about this more, shouldn't bag-transitive-target-inputs function be used for inputs? <pjals>Rutherther: Yes, but bag-transitive-inputs is equivalent to package-inputs, which should also be specific to the target. <pjals>Rutherther: It's equivalent to the build-system's target-inputs. <Rutherther>pjals: oh, that's a thing? my bad then, yeah, if bag-inputs is mapped to package-inputs I would expect it to respect current-target-system specified by bag-target then <gnubio>pjals: uses very old linux kernel: 3.0.101 <nutcase>Hi. I'd like to add to a self defined package a single file that is not contained in the source. What is the best practice for that? <cbaines>rekado, QA only currently submits builds for the 1st branch in the queue to be merged <cbaines>the build farm and the data service don't really have the resources to attempt to do any more currently <Deltafire>how would i prevent boot from stalling if one of the file-systems is disconnected? <Deltafire>i've tried adding the nofail options and alto (mount-may-fail? #t) <rekado>cbaines: I see, thanks for clarifying