<kabouik>Getting there slowly: https://0x0.st/opfo.jpg I am not sure what fixed the TUI install, either the server was having hiccups, or something was not working with my RJ45 (and wlan when I tried a nonguix image). I could ping the server, but the TUI would fail to fetch any substitutes. It worked immediately when I used a RJ45-USB adapter; first try. <vldn>what is this neat little device? <vldn>and how much does it cost? <vldn>there was a network maintenance @ Kabouik <kabouik>That's a Pocket 3 vldn, and sadly it's damn expensive (it has okay specs though): 1100 or 600 euros depending on the model. I made a bet there, if it can replace my laptop and I can get used to the keyboard and lower screen estate compared to my 13" with no frustration, then it's a win since it has better specs. If not, that's an expensive and frustrating toy. :< <kabouik>Yes we discussed the maintenance vldn, but I find it weird that I started having the issue before the maintenance (3am CET+2) and still got it at 4pm today, then it immediately worked when I used a USB dongle. <vldn>i had some ping to the ci issues on my vps too <vldn>maybe the dns needs to update or something <vldn>is it arm or x64 hardware? <kabouik>I tried from home and work, got the same issue from both <Cairn>kabouik: Is it fully libre, or are you running any extra drivers/ <kabouik>I had to use Linux kernel here for wlan Cairn <nckx>There were no DNS changes. <vldn>will look a bit into this device <nckx>If kabouik loves theirs, I might get one. <vldn>seems a good replacement for my razer blade 13" from 2016 :D <kabouik>I can't vouch for it yet, I received it this weak. But it's good build quality at least and so far the fan is barely noticeable (except in BIOS), but I haven't done any demanding task. Except guix system reconfigure but I went afk and didn't hear it. <vldn>my razer is most of the time passive <vldn>fan noise around the clock would be annoying <kabouik>This thing is 8" though, with i7, so cooling is a whole different story. I hope it stays quiet as it is right now. <Cairn>I'm still thinking that if I go for something mobile, I'm gonna try for something from Pine64. <Cairn>Sure, less compatibility because of ARM, but it'll just be a portable text editing machine I suppose <Cairn>The PineTab is back in stock apparently <bdju>mroh: thanks for the response earlier. I installed python-secretstorage now. I would rather not use gnome-keyring. do you know if it's possible to use keepassxc as the keyring? I do that for nheko's secret storage, but not sure if python-keyring or yt-dlp would support that. so far just installing python-secretstorage did not get me any further. <dthompson>kabouik: that pocket 3 setup looks real nice! <dthompson>I am currently in the sad position of not having a dedicated guix laptop. I do everything on an ubuntu laptop that belongs to my employer. <pashencija[m]><Cairn> "The PineTab is back in stock..." <- I would recommend adding some money and ordering PBP. Lack of ram is a deal breaker on guix <Cairn>pashencija: I already own a laptop. My interest is devices without built-in keyboards. <Cairn>pashencija: Is it a deal breaker for an idle system though? Or just when interacting with Guix? <pashencija[m]>Well, I doubt 2gb is enough for guix pull or guix system reconfigure unless you use a lot of swap <Cairn>I was thinking about trying to manage the device from another one. I know there are a few different methods to do that. Not sure how much of the issue that'd solve though <Cairn>pashencija: No, not really. I just know the Pine64 exists. It hasn't been that much of a priority for me. <Cairn>Doesn't need to be a big one. <kaelyn>Good day #guix! It's been almost two weeks since I sent in my vulkan updates and the new vulkan-validationlayers package, so wanted to give it a quick bump: https://issues.guix.gnu.org/57297 (if/when they land, I want to update them further on core-updates) <Cairn>pashencija: Oh neat. Looks like a cool device. <Cairn>Funnily enough, I was actually just about to mention that I was considering the pinephone pro <Cairn>Maybe I should just set my sights on that then <Cairn>Well I'd only be using it to run Emacs on top of Guix anyway <Cairn>No, I'd be using it with a keyboard. Just my own split mechanical board. <Cairn>My issue is with built-in keyboards, since they're redundant to my preferred keyboard <pashencija[m]>Rk3399 is great for being supported in upstream Linux, upstream uboot etc. Pleasure to use with guix <Cairn>pashencija: Is that the base board of any of Pine64's stuff? Or would I need to tinker with making my own display, case, etc. with it? <Cairn>It's the Pinephone one, haha <Cairn>I just didn't know which board you were talking about. Now I realize it's the board inside the PinePhone Pro <Cairn>kaelyn: Do you need to wait to update your patches, or could you send a V2 with the updates you want? <kabouik>That moment when you're setting up a new computer and don't feel at home anywhere, and suddenly you get your shell config and .rc file back, with autocompletion. <kabouik>Feels like sinking in the couch after a long day of work. <kabouik>I'm starting to feel comfortable with the keyboard size nckx; not with the non standard position of ; and ' yet. <the_tubular>Yeah the day I'll be "done" with my guix config, I'll do this all day long kabouik <pkill9>what would it take to fiz the problem of grafts preventing guix from knowing what the final derivation is? <AwesomeAdam54321>If I need to add a line to a Makefile.in, I should use a one-liner patch, right? <lilyp>Cairn: using Emacs with an on-screen keyboard is not ideal, but possible if your keyboard has sticky control keys <lilyp>e.g. allowing you to press C-s by first pressing C, then s. <declan>Hey, Guix. I am playing with Guix's inferiors feature. In this snippet https://bpa.st/JU5A , I am trying to install rust@1.6 from =core-updates= branch. My problem here is, how to install rust:cargo output as well using =lookup-inferior-packages= <nckx>AwesomeAdam54321: That depends. A substitute* can be just as good, better, or worse, depending on what you need to match or add. <nckx>pashencija[m]: It's fine. I've been using emacs a lot on my phone, and it doesn't suck more than anything designed for the thing. Sucks less than some 'apps' even. <nckx>AwesomeAdam54321: I don't follom. <nckx>Patches can contain tabs... <AwesomeAdam54321>nckx: What I meant was I don't think substitute* should have tabs, so I should go with the patch <nckx>IMO at least that should not be a factor in your decision, but the decision is yours, and it seems like you've actually made up your mind. <AwesomeAdam54321>nckx: I don't know how to put a tab in Emac's scheme mode, so I should find out <nckx>Or \t. See what looks best. <nckx>Sent from my Emacsphone®. Bye for now! <declan>nckx: Try to enable =indent-tabs-mode= for =Makefile.in= ? <jpoiret>sneek, later tell declan: In general, you can install specific outputs in a manifest by using (list package "output") instead of just package <sneek>Welcome back declan, you have 1 message! <sneek>declan, jpoiret says: In general, you can install specific outputs in a manifest by using (list package "output") instead of just package <jpoiret>I wasn't sure how it would work with inferiors :p <jpoiret>nckx: how do you manage using multiple C- commands in a row? Termux doesn't support holding down a modifier key very well <jpoiret>if Termux is what you're using of course <declan>nckx: Oh, I thought you were editing =Makefile= using Emacs. Need to disable =indent-tabs-mode= for that buffer. Never mind.. <PotentialUser-50>Hi everyone! I was looking for a way to check the integrity of the installation iso file. Is there by any chance, somewhere a checksum file on the guix site, or on github? <rekado>kaelyn: the first patch in that series “updates” spirv-headers from 1.5.3 to 1.2.198.0. Is that downward jump expected? <jpoiret>civodul: could you have a look at https://issues.guix.gnu.org/57513 when you have some time? it's the installer segfault that i've mentioned before, i was able to track it down thanks some brave soul's core dump <jpoiret>the reason it flew under the radar was that the issue would crop up with MBR drives with logical partitions <reza[m]>Does anybody know in which package lualatex-math.sty is? <reza[m]>When I install texlive complete it is there, but I can't figure out in which package it is in granular installation <reza[m]>Also guix import texlive lualatex-math gives an error <rekado>probably need subversion to be installed <efraim>adjusting libunwind's make-flags to be architecture specific without changing the derivation is proving harder than I expected <efraim>reza[m]: I didn't find lualatex-math.sty in the store on my machine <reza[m]>efraim: Me neither but compiling a document with texlive full using latex package unicode-math shows it being loaded with \listfiles <reza[m]>It is mentioned in the unicode-math documentation that it is a dependency <reza[m]><rekado> "what error?" <- Something along the lines of file not found <rekado>that’s what the importer gives me <jpoiret>rekado: why do i get weird unicode characters at the end of each line? <jpoiret>ah, i thought it was a website issue <rekado>(it’s fci-mode that doesn’t snapshot well) <jpoiret>oh, i was using whitespace-mode to highlight the characters going over the limit, but fci-mode might be less intrusive <Obikawa>Hello. I looked through a bunch of blog posts and documentation pages. From that I got an impression, that Guix does not have package maintainers like other distribution do. Is that correct? I have submitted my first patch a week ago, and had no response. I am trying to understand the process, but there is almost no useful information. <rekado>Obikawa: this is correct. We’re maintaining packages collectively. <rekado>but there are problems with patch review <rekado>they were not so severe at smaller scale <rekado>one attempt to mitigate the problem was the proposal to more formally define teams <rekado>see etc/teams.scm in the source tree <rekado>and for new contributors there were supposed to be mentors who help get new contributions over the finish line more quickly <rekado>sadly, the response to this organizational change hasn’t been quite as … enthusiastic as expected <rekado>so … while this situation evolves, let’s resort to a short term solution: <rekado>can you send us the issue number of your patch submission? <rekado>then I’ll take a look later today <rekado>Obikawa: the Contributing section is supposed to contain all instructions, but as our processes are in flux it doesn’t talk much about how the review happens. <lilyp>Obikawa: Propagated inputs are usually frowned upon. Instead, try to find the location in which gpg is invoked and use a substitute* <Obikawa>lilyp: The gpgconf program is required at runtime. I could test having it in `inputs` again - I will mail the findings in the issue. <lilyp>Obikawa: in lib/agent/keyring.py, you need to substitute* util.which('gpgconf') with the actual gpgconf <rekado>Obikawa: I sent a review via email <rekado>it may be better to respect PATH first and fall back to gnupg from the inputs <rekado>not sure if that makes sense from the perspective of a user of trezor-agent <Obikawa>Wow, yet another bunch of things to learn. Thank you. <lilyp>rekado: I don't think that can easily be done though, as the OSError is raised in which <rekado>just patching the invocation would be just fine then <Obikawa>lilyp: I need to programmaticaly find the Guix Store path to the gpgconf executable and insert it in the util.which - right? <lilyp>(search-input-file inputs "bin/gpgconf") <Obikawa>lilyp: Right... I will take it slow now. I will continue the discussion later in the issue itself. <efraim>libunwind on staging has different test failures per architecture, fixing up a bunch of them now <florhizome[m]>when I try to guix pull on core-updates (with —allow-downgrades) it fails with producing guix-package-cage <rekado>the package cache may fail when there are undefined package variables <florhizome[m]>builder for ….guix-package-cache.dev failed to produce output path ….guix-package-cage <rekado>can you look at the associated log file? <rekado>I think you can do “guix build --log-file …-guix-package-cache.drv” ***wingo_ is now known as wingo
<efraim>it looks like the libunwind test suite might only be run on x86_64, everything else has a different collection of failing tests <antipode>The mirroring patches should be ready now #57515 <florhizome[m]><rekado> "I think you can do “guix build -..." <- how do i best view this <muradm>is there channel having samsung unified driver for printer? <vldn>how to use guile-ncurses ? <vldn>the normale use-module (ncurses curses) seems not to find the module <antipode>vldn: Seems to work over here: guix shell guile guile-ncurses -- guile -c '(use-modules (ncurses curses)) (display "ok")' <vldn>yeah within the one liner it works for me too.. <lilyp>vldn: you're probably lacking guile in your profile <vldn>and i had a stupid typo and just included ncurses instead of the module.. -.- <rekado>florhizome[m]: the result might be a URL for a substituted build, or it could be a local log that’s compressed or not dependent on daemon settings. <rekado>if it’s compressed you can use zless on the result to view it. <vldn>btw we are close to 400 users in the irc :) <rekado>the log should be pretty short; often you’ll see right away that it aborted because of an unbound variable <vldn>maybe a lot of them are double accounts xD <rekado>the cause of that could be an outdated third-party channel <florhizome[m]>It seems a package in a third-party channel is using an outdated reference to icu4c ***wielaard is now known as mjw
<efraim>civodul: I'd send it back, it worked on all the architectures I tested it on <efraim>looks like the test just took too long <civodul>ah alright, so let's see if it happens again *civodul looks at "make assert-binaries-available" <civodul>would be nice to publish a release, no? :-) <efraim>I almost feel like a monthly snapshot would be better :) <efraim>plus we have a staging merge coming up <lilyp>what would be the point of the snapshot though? It's not guaranteed to be more well-tested than anything on master at any point in time, no? <muradm>texlive texlive-base : 3,556.8 MB will be downloaded O_O <lilyp>orneb: Guix System comes with the default substitute servers (berlin, bordeaux) already enabled <martin0x13[m]><lilyp> "orneb: Guix System comes with..." <- I use only the guix package manager. What to do in this case? <AwesomeAdam54321>I'm currently trying to package pnet(from dotGNU), and it's failing to compile because it needs a private header file from libgc <lilyp>martin0x13[m]: in this case you have to add the substitute servers as described in the manual <lilyp>AwesomeAdam54321: Copy the private header at build time <lilyp>i.e. (add-after 'unpack 'add-missing-header ...) <kabouik>Anyone managed to use --demuxer-lavf-o-set=input_format=mjpeg in mpv (to show a webcap stream for instance)? I have mjpg-streamer and ffmpeg installed, but no dice in Guix (it works on my other systems, but maybe I'm missing a package). <kabouik>mjpeg is known to dramatically increase performance in other systems (Arch wiki mentions 5 to 30 FPS between YUYV and MJPEG) <lilyp>kabouik: maybe you need to build ffmpeg with mjpeg-streamer as input? <orneb>lilyp: so GuixSD would always install substitutes when available even if I omit the substitute server declaration in my config file? <orneb>lilyp: *from the official server <kabouik>Erm, I hope not lilyp, that would be a lot of work and maintenance hell for just showing my webcam in 30 fps. :/ <lilyp>adding an input to a package shouldn't be a big deal, plus if it's shown to work it'll likely be accepted upstream <kabouik>What would be the workflow to try that locally? I don't remember how to alter the .scm of an upstream package and rebuild it with modifications for testing. <lilyp>orneb: by default, it will consult the "official" servers, but you can configure it to take any (or indeed no) server <lilyp>kabouik: use a package file and write (package (inherit ffmpeg) [your changes...]) <lilyp>alternatively, if you use manifests, you can declare packages in the files as well <dthompson>rekado: do you remember why you changed the tiled package to fetch from git rather than using github release archives in commit 902068b43664b862dfcbb9172f41778d576e3ae0? it's from 2018. <dthompson>is it a preference to not use github archives or was there some issue back then that made the archive for tiled no good? <kabouik>I'm missing the basics. What I did is `guix environment --ad-hoc ffmpeg mjpg-streamer` but then have forgotten again how to write the .scm file from scratch. <jpoiret>dthompson: github-generated tarballs often change because of github <jpoiret>whereas git checkouts aren't supposed to change (unless someone moves a tag or force-pushes) <dthompson>jpoiret: interesting. I have never encountered that myself, but I'm not surprised. <mbakke>lilyp: I think module imports need to be adjusted for the tox move <lilyp>did that cause some failure? <mbakke>from 'guix time-machine' (and presumably 'guix pull'): (exception unbound-variable (value #f) (value "Unbound variable: ~S") (value (python-tox)) <dthompson>I'm trying to update the Tiled package but it looks like 1.8.6 is as far as we can upgrade right now. the 1.9.0 release removed qmake support and replaced it with qbs, a tool that was deprecated a few years ago. fun! <efraim>gst-plugins-base has a bunch of failures on staging on riscv64-linux <lilyp>mbakke: okay, networking.scm needs an import <lilyp>as do diffoscope, django and magic-wormhole <lilyp>is there a quick and dirty way to check that I got everything? <lilyp>(as in doesn't require a ton of package builds) <efraim>./pre-inst-env guix package -A erlang <orneb>lilyp: where is this documented in the manual (how to disable the official servers too)? <vldn>wooooop wooop it's finally working :) <vldn>if someone is interested in system deployment and replacing the running base host system <vldn>a little guix-system-infect script for a debian 11 host without efi (till now) <vldn>with detection of partition names and hostname etc. <vldn>but really simple at the moment, but works for me, with latest guix binarys instead of 1.3.0 <lilyp>vldn for the record, which hoster did you try? <vldn>i'm running on alexhost, a kvm vps <vldn>really cheap one for 11 dollar a year with 1.5gig ram and 10g hdd <lilyp>AwesomeAdam54321: (package-<the-field> <the-package>) <vldn>but it should not be so hard to run the script on other vps or local host systems <vldn>just edit the generated config file <vldn>it should be host system independent i think, but i added debian for the safety <vldn>not using any systemd stuff, maybe ubuntu could be a problem because of the /etc/ moving stuff, they need other files for networking then debian i think, don't know <lilyp>efraim, mbakke: should be fixed now 🤞️ <lilyp>vldn: since you're copying the old etc, root ssh is optional, right? <vldn>after the reboot herd is started with it's own ssh <vldn>and the guix libre kernel takes over <efraim>ok, I'm fixing gst-plugins-base on staging for other architectures <kabouik>Getting no audio on my fresh install: "sof-audio-pci-intel-tgl 0000:00:1f.3: error: sof firmware file is missing, you might need to download it from https://github.com/thesofproject/sof-bin/", but that git repo contains an installer which I assume would not work with the Guix file structure <jpoiret>kabouik: the sof binaries are not free <kabouik>Ok, didn't know that. I may ask in the other channel then. I didn't know sound cards had non-free firmwares. <lilyp>I think the one truth about hardware is: if it exists, there's non-free firmware for it <kabouik>Problem is even with sof-firmware installed from nonguix, pavucontrol still only shows a dummyt output <lilyp>have you tried restarting the pulse server? <Cairn><lilyp> "Cairn: using Emacs with an on-..." <- You must have misunderstood. I have a physical keyboard that I'd like to use. What I'm trying to do is avoid the redundancy of my device having its own keyboard along with a built-in keyboard. <Cairn>Sorry, I know this is super late of a response. Just woke up. <Cairn>If I were to get a PinePhone for example, I would explicitly never enable touchscreen features. <lilyp>I'm p sure that it's just using the default gnome osk <lilyp>which ought to be easy enough to disable <Cairn>I don't understand what you mean <Cairn>I wouldn't install anything but Emacs <lilyp>there are few terminal-only phones :P <unmatched-paren>AAAAAGHLGHAA aerc just released ANOTHER new version :( guess i'll have to send [PATCH v9] gnu: Add aerc <apteryx>civodul: hi! Is it normal that 'guix shell' super fast cache is not directly shared with 'guix shell -m manifest.scm' ? <unmatched-paren>Though this may take some time to materialize, as my laptop's network connection is out of action and will be for a while... <Cairn><lilyp> "there are few terminal-only..." <- Guess that'll be mine then <kaelyn>rekado: thank you for the review! I'll send a V2 to address your second two points. Regarding the spirv-headers versioning, the last tag of the old scheme was 1.5.4 from Oct/Nov 2020, after which it is tagged with the sdk-1.[23].y.z versions used by the other Vulkan SDK components. <rekado>kaelyn: it’s not a big deal because it’s unlikely people have installed that package into their profiles; just want to point out that 1.5.4 would be considered newer by Guix, so it wouldn’t automatically upgrade when using ‘guix upgrade’. <rekado>but there’s nothing you can do about it. <lilyp>dthompson: ahem, it's M-x eshell <rekado>eshell is fun, but a very different beast <rekado>(favorite feature about M-x shell is jumping from prompt to prompt and deleting stuff I don’t care about) ***mark__ is now known as mjw
<civodul>the integration with guix-build-log-minor-mode is wonderful, too <Luk6655>Perhaps someone knows how to modify (via inheritance, or transformation) this in gnu/services/desktop.scm "(define (elogind-configuration-file config)" basically I need to add another config option. <dgcampea>where can I place a "htpasswd" file that gets read by nginx? <rekado>ah, rust packaging is so annoying :( <rekado>dgcampea: you can put it wherever you tell nginx to look. <rekado>Luk6655: unfortunately, I don’t think you can do that easily :( <rekado>Luk6655: the elogind-configuration also doesn’t offer an escape hatch, so you can’t easily add arbitrary text to the config file. <Luk6655>rekado: Are things like this "supposed to be" configurable in guix? I wonder what is the design idea at play here? Are we to add every config option to the desktop.scm where elogind is defined? <Luk6655> It feels quite wrong to have to modify the code of the OS to add a config option in a service conf file... <rekado>for most services we offer an ‘escape hatch’ that allows you to inject arbitrary strings into config files <Luk6655>I see, any idea why this one doesn't have one? <rekado>that the elogind configuration record doesn’t allow you to do that is an oversight. <Luk6655>could you point me to an example of similar service with one, perhaps? Then I could use it as a template and add one myself. <Luk6655>I know xorg has extra config or similar <nckx>civodul: Hi! You said hibernation wasn't working for you? <rekado>kaelyn: excellent! I’ll merge it later today. <abhiseck>I am learning about pkg-config. When I run `pkg-config --list-all' in guix system, the output is blank. Why is that? <rekado>pkg-config looks for libraries in default locations that don’t exist on Guix System. <rekado>and you probably don’t have a search path set that would be used as an alternative. <rekado>try again inside of a guix shell that contains some libs <rekado>example: guix shell pkg-config curl libx11 -- pkg-config --list-all <rekado>pkg-config has a search path declaration, so when it is installed into a profile it will set a search path to directories of the same profile <rekado>klm: will take a look later tonight <rekado>klm: thanks for sticking with it! <abhiseck>It works. Thanks for the help rekado :-) <rekado>kaelyn: looks like this will have to go to core-updates <rekado>vulkan-headers leads to a rebuild of 1000+ packages <rekado>I wonder if we should add it to core-updates or just a new branch <efraim>Core-updates should be fine, unless you want it sooner <rekado>how soon would a core-updates merge be? <rekado>I have a slight preference to building it out on a separate branch then. Also makes it easier to spot breakage. <efraim>That's fine with me. Just make it x86_64 only <podiki[m]>I'm a fan of more feature branches to avoid the huge core-updates merge we had last time <podiki[m]>speaking of...staging is built and will be merged soon? <efraim>the kde updates were just merged into staging, it needs some time to be tested and we need to wait for some of the slower architectures to build <kaelyn>rekado: thanks for pushing the patchset to a branch! I missed that vulkan-headers triggered so many rebuilds (the dangers of doing "guix refresh -l vulkan-headers" instead of "./pre-inst-env guix refresh -l vulkan-headers" in the presence of local channels). <klm>rekado: great, thank you :-) ***Dynom_ is now known as Guest2850
<efraim>is there a path from vulkan-headers to rust? <jackhill>guix graph says no: "guix graph: error: no path from 'vulkan-headers@1.2.164' to 'rust@1.59.0'" commit 8c5246677cced7389068ab8af1ba61dbcb26ba28 from master <apteryx>we have multiple shepherd instances using 100% CPU on berlin; any clue why? <apteryx>anonip also saturates 3 cores; I wonder if it's fast enough to keep up with the steady guix publish log flow <mbakke>rekado: perhaps it would be better to rebase the update-vulkan-headers branch on 'staging'? so we don't have to do those 1000s rebuilds twice <lilyp>can we add a feature to guix build that displays progress in terms of packages built? <lilyp>e.g. let's say I do a bootstrap until gtk, I want to know something like "100 packages left" <vldn>would be so cool :) @lilyp <vldn>built (/progress) 14/329 <grobx[m]>any advice how to use oh-my-zsh in guix home? (so that it will be reproducible) <florhizome[m]>is there something other then the email thread about guix teams ? :) <podiki[m]>there is a file in the repo that keeps track of teams in a data structure <lilyp>grobx[m]: IIRC oh-my-zsh is just another package manager that simply places files in the right location; you can replace that by guix (home) <lilyp>particularly, guix package to handle installing zsh functions etc. and guix home for configuration <grobx[m]>I'm trying to use guile-studio with emacs-next-pgtk (guix shell emacs-next-pgtk guile-studio), but seems that the emacs packages are not installed in site-list, for instance there's no run-geiser when I start emacs <kabouik>Do I need a package for /sys/class/power_suppply/BAT0/uevent to be refreshed dynamically? I am running cat on it and it always shows the same, un less I reboot <lilyp>perhaps tail -f is superior to cat here? <lilyp>we need to rewrite cat in rust and name it 🐈 <lilyp>emojicode is also acceptable as long as it compiles to rust <nckx>Now that I can't unsee it, I'm actually surprised nobody has written an all-emojo-/bin coreutils in Rust or Zig or Zuul or whatever. <nckx>efraim: Guix's locale problems protected you? <efraim>I actually don't remember why it didn't work. I had it around as a WIP for years <nckx>Anyway: kabouik: I wasn't aware that i3status used /uevent. It has also always worked for me. <vldn>ahahanice never heart of emojicode <Andronikos>Hello, I am using Guix Binary. I tried playing Minetest but I just spin around. My view is always locked to the sky like videogames in a VM without GPU. Why? <apteryx>so you are using a binary Guix installation on top of a foreign distribution, which has OpenGL support? <Andronikos>Yes. If I install it through my distro package manager I do not have any problems. <apteryx>Andronikos: are you using nvidia proprietary drivers per chance? <nckx>I just grepped the code for /uevent TBH. <nckx>kabouik: /uevent aside, do the other relevant files in that directory update? <nckx>Would be a weird bug if so, but then it's a weird bug already. <apteryx>Andronikos: I've heard people having issues with Guix's mesa when the underlying system is configured for nvidia <apteryx>it would probably work better if you could use free drivers (proided by mesa) on your host distro <lilyp>aren't we using the nvidia-blessed binary blob loader to address this already? <nckx>kabouik: I won't be back for a while, but my next wonder would be what ‘acpi’ prints. AFAIK (but I didn't check) it doesn't use that interface. I find it bizarre that, IIUC, your kernel is downright lying to you about your power reserves… <Andronikos>Tried that some times ago but I don't get it to working. Guess I will try that at a later time. I guess that also explains why I have problems with X11? I am going to create a paste. <nckx>kabouik: Also, maybe try downgrading to a significantly older kernel, just in case? Long shot, I know. o/ <kabouik>acpi is lying to me too, reporting the exact same nattery percentage that has not changed except at reboots. I never observed anything like that on any machine or Guix but this is also the first time I have Guix on a machine with a battery. <kabouik>Looking online how to downgrade kernel in Guix, thanks for the hint. <mbakke>network-manager-applet propagates some inputs, and the comment refers to a non-existent .pc file ... anyone familiar who can take a look? <apteryx>Luckily the nvidia driver seems bound to disappear in the future, with nvidia having made the move to "free drivers" (coupled with proprietary firmware) *mbakke pushes small GNOME updates, only tested in a VM <antipode>Andronikas: With "locked to the sky", do you mean that you are seeing the Minetest sky, with its sun and clouds, but can't look anywhere else but up? <apteryx>Andronikos: I guess it's related to your Guix OpenGL failures on top of nvidia driver, yes <apteryx>mbakke: cool! I have a few nearly ready to go too <apteryx>I think my last one was gnome-shell, blocked by gjs <mbakke>apteryx: there is a newer gjs on 'staging' FWIW <apteryx>yes, but porting it to master was not as trivial as I'd hoped <mbakke>...and I have a local patch to fix the build on 'core-updates', can clean it up if that's where you are working <apteryx>no, I was attempting to update the gdm/gnome-shell related components before reporting a bug about XDMCP not working, if the bug is still there <mbakke>is it feasible to go full GNOME 42 on 'core-updates'? :-) <apteryx>it is not feasible on master? we already have a few 42 components <mbakke>dunno, would expect a newer GLib and such to be required <apteryx>glib can't be touched, but for most projects 2.70 is good enough still <mbakke>speaking of core-updates, I now have GNOME, ungoogled-chromium and IceCat building on my branch with GCC 11, glibc 2.35 and Python 3.10 ... time to submit the patches :-) <apteryx>an interesting thing with gnome 42 is that projects are finally moving to libsoup 3 <apteryx>hopefully we can drop that silly webkit-with-libsoup2 soon <Andronikos>apteryx: Yes I mean that. I can basically only look straight up in 90 degrees to the sky. Thanks for the help. I am going to get the free drivers working and try it again. As far as I know those new Nvidia free drivers are only for newer cards like GeForce 1650. <grobx[m]><grobx[m]> "I'm trying to use guile-studio..." <- I found a solution, just `guix shell emacs-next-pgtk -D guile-studio` <antipode>Andronikos: Assuming you meant apteryx -> me, that sounds like Minetest is rendering fine. *antipode starts minetest <antipode>Androniko: if you move the cursor, does the point-of-view change? <antipode>if you move it down sufficiently far enough, you should be looking at the ground. <antipode>Wait, a fixed 'looks-up-in-the-sky' could be a driver bug -- <antipode>-- the OpenGL API has some functions with matrixes for determining the reference frame. <antipode>Andronikos: (on cargo run) Try emptying your Rust build cache & retry, maybe some old build interacts refer to deleted old libX11 <Andronikos>As I said, I can only look up straight in the sky 90 degrees. I can do what I want my mouse view does automatically move up. Also it is extremely fast. I have seen such behaviour only in video games I play in a VM without a dedicated video card. I can create a video if you want to show you how it looks. I did also a retry with the Gentoo pacage which results to the same behavoiur. Guess it is more of an issue with the Nvidia driver a <antipode>It is a hypothesis, but another possible hypothesis is that the input system (keyboard, mouse, in Minetest itself or its configuration or a lower component) went wrong somewhere. <Andronikos>I did a "cargo clean" and "cargo run" which results to the same error. <antipode>One of these rust crates (rust-wayland-sys, or maybe it was another one) do by default dlopen("whatever.so"). <antipode>You might have to enable or disable the feature to make it actually link to whatever.so <antipode>Actually, looking at antioxidant-packages.scm, if my notes are correct, then rust-wayland-sys does not have an option to do that. <antipode>You can try working-around that by setting LD_LIBRARY_PATH. <antipode>(I do not know if rust-wayland-sys is used in your case) <Andronikos>No it is not. It is a dependency for a package I use. <lilyp>regarding webkit, has anyone had any success building webkit with gtk4 yet? <lilyp>it's a requirement for newer versions of gfeeds and probably komikku as well <apteryx>haven't tried, but it webkit supports it now, it should just work <apteryx>perhaps with --enable-gtk4 or something <lilyp>the reason I'm asking is because my experiments have always resulted in some weird build error claiming that libsoup2 and libsoup3 symbols were mixed ***nikken_ is now known as nikken
***alethkit_ is now known as alethkit
***hendi_ is now known as hendi
***voroskoi_ is now known as voroskoi
***richardhuxton_ is now known as richardhuxton
***dctrud_ is now known as dctrud
***fnurkla_ is now known as fnurkla
***fluffyballoon_ is now known as fluffyballoon
***abcdw_ is now known as abcdw
***\f_ is now known as \f
***j0ni_ is now known as j0ni
***reproducible_ is now known as reproducible
***unmatched-paren_ is now known as unmatched-paren
***chipb_ is now known as chipb
***cylb_ is now known as cylb
***raingloom_ is now known as raingloom
***lh_ is now known as lh
***reyman_aw_ is now known as reyman_aw
***artyn_ is now known as artyn
***colbyhub_ is now known as colbyhub
***Fd9a_ is now known as Fd9a
***cnx_ is now known as cnx
***kodmin_ is now known as kodmin
***sleepydog_ is now known as sleepydog
***johnhamelink_ is now known as johnhamelink
***cap2 is now known as cap
***dominicm_ is now known as dominicm
***_ctb_ is now known as _ctb
***sheertj_ is now known as sheertj
***monadgauge_ is now known as monadgauge
***theothornhill_ is now known as theothornhill
***user3456_ is now known as user3456
***jpoiret7 is now known as jpoiret
***KindOne_ is now known as KindOne
