<guix-vits>nckx: in near 8 days old Guix commit the Wayland works good with a kitty (but sudo -i is unusable, due to "doubled echo of chars"), qutebrowser works and IceCat worked. But you may need to move out the i3 configs, as Sway showed itself glitchy with them.
<guix-vits>calher: better x-version of emacs: it can PDF
<guix-vits>raghav-gururajan: "press a Tab key a thousand times"? Sway has it, Gnome not. And errors (in Gnome Software, at least) get printed in such a small boxes... Only if the accessebility works better. Just i'm miss the buttons with a mouse... Keyboard has all the buttons right there.
<nckx>OriansJ: Last I tried (pre-Guix) it was a nightmare to package.
<OriansJ>nckx: well guix does certainly help deal with alot of developer sins
<raghav-gururajan>nckx Own HIG? I think HIG is drawn from Human-Computer Interaction (HCI) studies.
<leoprikler>KDE commits strongly to their HIG, but their HIG is: "If there's not yet a button to customize it, there should be."
<nckx>raghav-gururajan: There's no one true HIG. GNOME has theirs, KDE their own, every major commercial OS theirs. Otherwise they'd all look and feel the same.
<raghav-gururajan>OriansJ I think the goal is not to create perfect interface. It is to study how human perceive things and what differences are observed between humans so that a range a range of interfaces can be built that suits specific needs.
<raghav-gururajan>OriansJ You said that right. Neural Diversity. That is the subject of study.
<OriansJ>raghav-gururajan: the big problem is what is obvious and natural for one group of users is alien and hard to grasp for another group. So you can either choose to compromise and make it universally harder for everyone or sacrifice small groups to the benefit of a larger group
<raghav-gururajan>OriansJ There are some commanlities between everyone. Like all humans can only perceive certain range of wavelength and frequency. Light and Sound for example. But the studying the diversity is to discover the factors that causes the diversity and to develop a tool that can configured to different needs. For example, the study could reveal what kind of themes should be made available (light, dark or high contrast), what
<raghav-gururajan>kind of options can be put in settings that might be needed for the user to change, etc.)
<leoprikler>btw. does g-golf still use a C extension or is it all done with FFI?
<raghav-gururajan>I am taking from the view study, not in the view how it is implemented currently by desktop envs.
<daviid>leoprikler: the scheme mem will be gc correctly if an instanced is not refereneced ayore, but if you don't unref (which does the right thing on the C side ofthings for you), the C mem would leak ...
<str1ngs>but normally in GTK removing a widget from a container should unref it.
<daviid>leoprikler: if possible in guile-gi, it is possible in g-golf, i'm all hears on how to iprove the situation, but afaict, the user must call destroy, unref ... there is just no way to 'snarf from the magic' that a gobject inst isn't ref anymore, uless users decrease the ref-count ... no magic
<leoprikler>You use the cache when returning objects from a closure.
<daviid>leoprikler: ok, then you tell me: you run a callback or a signal, that returns a GObject instance pointer (just one of numerous examples), how do you identify to which, if any (it could be new) goops instace that was asociated with i the frst place?
<leoprikler>Well, in the case of guile-gi that's easy: I don't.
<daviid>leoprikler: right, any GI language binsing on earth, afaict, must provide a mechanism to maintain correspondances between GObject and the language instances
<leoprikler>that way, your object should still be garbage collected if it's not referenced anywhere else and you can use "unref on GC".
<leoprikler>however, you need to be careful when handing objects over to a function that transfers ownership
<daviid>leoprikler: I did think about, sing hweak ht, and i can't remember why i didn't take that route a the time, but as soon as things are a bit more complete and robust, I should carefully reconsider
<daviid>leoprikler: what would use guile-gi and/or g-golf for? any project
***jonsger1 is now known as jonsger
<leoprikler>Sadly nothing particular yet. I wrote an MPD interface ages ago with ad-hoc Guile bindings and I'd consider writing a better one once I can consider either of them "ready".
<leoprikler>Another feature, that at least guile-gi doesn't have would be the creation of girs and typelibs from Scheme.
<janneke>ah, some hardware debugging -- makes sense
<str1ngs>it's generally used to interface with a chip. so say you need to program a bios etc
<guix-vits>Maybe someone knows: What about "Rock" from PineStore? It is easy to assemble (no soldering)?
<shtwzrd>janneke: by it installs, do you mean bootloader and all? I'm still getting blackscreens on my sd card after `guix system init`ing it
<shtwzrd>also, for the pinebook pro, the way to debug u-boot is a UART connected through the headphone jack. You can get a cable from the pine64 guys that you can just plug in and it has usb on the other end so you can get output, but if you´ve already got a UART interface, you could fashion a connector from a spare headphone wire
<str1ngs>janneke: I'm debating add a user-data slot to emacy's <text-buffer> to be like how <window> works. this would avoid using local-variables to box say the graphical presenting widget? WDYT?
<shtwzrd>then to connect, you gotta open up the machine and flip a switch to disable audio
<janneke>KE0VVT: yeah, it took me quite a while to "get into" this
<str1ngs>janneke: it's really hard to over ride text buffers like scratch and messages
<shtwzrd>janneke: oo, no I haven't been keeping up the past few days, have not tried these patches. I have taken a stab at disabling jit for aarch64 though to see if that'll work around or guix pull issue. Patch looks good, I think I may give this a spin soon
<janneke>str1ngs: yes i'd say go for it -- the local variables really interfere in a way with the goops objects
<str1ngs>janneke: and then local-varibles can be used for mode's ie end user cunstomization
<shtwzrd>tsys has stated he intends to send the patches upstream asap. It is a little over a 100 commits diverged at this point which sounds a bit scary, but looking at the history it's mostly just in board and battery specific files which I imagine would be easy to get upstreamed. The worrisome parts are probably the couple of commits related to usb type-c
<KE0VVT>Can I download binary tarballs from Hydra?
<allana>guix-vits: hi, no good news. I had to pause yesterday and I am currently doing a "guix pull" before doing some experiments.
<janneke>efraim: ah, i'll have a look at arm; thanks for reminding me
<shtwzrd>janneke: I agree, it's an odd choice and probably my biggest disappointment with the machine. I would guess the motivation was BT 5.0 support; I haven't seen any blobless bluetooth 5 chips so far
<shtwzrd>The wifi/bluetooth module isn't on a socketable part of the machine. I have heard others mention an unused usb line on the SoC though -- longterm I think I wanna find a way to wire up a wifi dongle to that. Or cannibalize the webcam connection
<janneke>hmm, i'd really like pine64 to re-evaluate that choice
<janneke>they might even go towards ryf hardware -- not sure about the boot process
<shtwzrd>agreed, it's weird to go out of your way for an arm processor with a functioning open graphics stack, and then slam in a networking module that needs broadcom firmware.
<janneke>hopefully it's either unawareness or pragmatism, and easily fixed in a next iteraration
<janneke>i can appreciate the effort of getting a working machine out
<guix-vits>Are the SBCs from PINE Store is hard enough to assemble, so it is easier to buy an PINEBOOK (original case from the site)?
<shtwzrd>yeah, same. Definitely hoping for all libre compatible hw next time around. But hey, at least shoving a dongle into the left side usb port silences that high-pitch whine the thing makes when you connect it to AC :D
<gagbo>Hello, I'm starting to play a little with Guile and wanted to use guix on foreign host to handle guile packages. Is there a quick guide or some location I can look up to build a `guile-next` version of `guile-sdl2` package for example ? I don't know which files I should download and/or modify and how to build the derivation like a "shell.nix" or "default.nix" would
<efraim>janneke: I'm not sure what your plan is while you're testing on arm, but I do like the idea of having all the -boot0 packages. Makes it easier to normalize all the other inputs across the other architectures
<efraim>and we could in theory drop a couple of inputs from make-boostrap
<janneke>efraim: i agree; i would like to see bzip-boot0 fail like you said and then adding diffutils-boot0 or so
<raingloom>any idea what this is about? "automake-1.16: error: cannot open < ./doc/guix-cookbook.de.texi: No such file or directory"
<shtwzrd>I tried adding --disable-jit to the guile-3.0 package def and then doing a guix pull --url=/my/local/guix --commit=myhash, hoping this would allow me to get latest on ARM, but it still failed. I thought the issue was JIT related but maybe not? How can I be sure that it's building guix with my build of guile?
<civodul>shtwzrd: --disable-jit is already passed on ARMv7
<nckx>so (origin … (hash (base32 "staysthesame"))) but /gnu/store/abc-origin.drv → /gnu/store/efg-origin.drv.
<nckx>Hm. I hope that makes sense to anyone but me.
<zimoun>civodul: I have sent the v2 of sources.json.
<joshuaBP`>hey, do guix channels allow users to create and share custom services? I would imagine so...
<civodul>zimoun: great! will look at it hopefully later today
<shtwzrd>joshuaBP`: yep, you can distribute both packages and services that way.
<kahiru>hey, I'm trying to install guix on top of fedora. I have an lv formatted and mounted at /gnu and when I run the installer script I'm getting "A previous Guix installation was found. Refusing to overwrite.". Is there a workaround apart from doing the installation by hand?
<civodul>kahiru: in the installation script, can you replace -e "/gnu" with -e "/gnu/store" ?
<roptat>Or with a substitute server, you could have one machine build a commit and serve it to others
<nckx>I do something similar: I run guix pull on my substitute server, wait, then pull on my other machines. I don't explicitly use the same commit though. If something gets pushed in that window, tant pis.
<roptat>I update weekly, using a commit that was built on ci for all four architectures
<roptat>So I am always a bit behind, but I don't build guix everytime
<shtwzrd>I wonder -- what would be the cleverest way to deliberately pull a commit that has a very high percentage of what you need already built and available as substitutes on the official ci servers?
<roptat>But that's expensive, so not sure it's worth it
<shtwzrd>those are all better ideas than what I had in mind at least (finding a 'random' commit hash that's ~12 or 16 or so hours old and hoping for the best)
<roptat>I'm sure splitting modules further would help too, since the build farm would be able to reuse stuff from older commits more often, but this apparently has a negative impact on runtime performance of guix
<shtwzrd>roptat: runtime in what way? Like finding the specified package definition when invoking `guix package`?
<roptat>I'm not sure, I think it oas an argument I heard from ludo
<roptat>Also it'll make it harder to maintain properly
<shtwzrd>i'm sure the argument is good regardless. wish we could have our cake and eat it too somehow though. :)
<shtwzrd>I wonder how hackish it would be to cook up a way to exclude certain files from being considered in a pull. Probably bad because you have to be sure the module isn't a dependency for other modules. But it could be cool to only rebuild the part of the world you care about, when rebuilding the world.
<efraim>Someone had a channels file with a pk statement to peek at the lastest commit with a substitute for guix build
<civodul>str1ngs: the hook is just for Guix, we asked for it loooong ago
<grp>hello guys. I'm interested in switching from NixOS to GuixSD but I'd like to confirm something first: If all I'm changing is some daemon conf, will the system refuse to do it if I'm not connected to internet?
<civodul>well here, as long as you didn't run "guix pull" in the meantime, it should be fine
<civodul>but indeed, not running "guix pull" is the key
<nckx>grp: You can disable substitution or use --fallback, but I think that's not even necessary with Guix in your case.
<grp>nckx: well, I'm currently trying that very same thing out. Made a local copy of nixos-rebuild and added --option substitute false
<nckx>grp: And of course we're assuming that ‘changing some daemon conf’ isn't adding a new/different package to that daemon, adding new services, or changing one kind of service into a completely different kind (say wpa_supplicant → connman, I don't know).
<grp>killed my internet and tried to rebuild, builds fine but also normal nixos-rebuild... may need to wait till the cache expires or something
<grp>nckx: of course not, just change IPs, routes, and in this particular case that triggered my rage I was adding some override to a systemd service
<civodul>note that static networking support is not as good as we'd like currently...
<str1ngs>civodul ah good to know thanks. might that also explain how guix has multiple git repositories as well. I tried to find documentation on adding more but I could not find anything.
<civodul>str1ngs: if you need it for another project, you can file a Savannah support request
<str1ngs> civodul ah thanks for the info. I was going crazy trying to find out how to do then. then I have up.
<nckx>alextee[m]: That just means your firmware ignores <DEL> in CSM mode. Could be a bug. Maybe it handles a different key in CSM mode, because someone forgot to change both values. BIOS/UEFI firmware are basically just copy-pasted from one version to the next, one model to the next. This kind of stuff happens all the time.
<dongcarl>I'm also working from a computer that hasn't `guix pull`d in a while... On f5557bde1c3f2029ddfea9b1f803a7e91d5f782a...
<zdm>is there a list of usb wifi adapters that the guix project recommends? currently not installing guix as my main because im unsure what is supported for wifi, and i currently am using the iwlwifi driver for my t420
<raghav-gururajan>roptat Oh wait. I forgot. I think %*-desktop-packages will not be needed. Because each %*-desktop-services I planned will use their respective desktop meta-package, in which I will be placing these fonts.
<nckx>roptat: nckx: ‘Try this paste, it's too short and simple so I'm sure it will break, but it can serve as an example’ — ‘Thanks, it works as-is’ — ‘…oh.’
<nckx>I dunno, I always thought they had to be complicated or whatev. Nope.
<nckx>raghav-gururajan: It would still be nice to use a %foo-desktop-packages internally (and consistently across desktops) and export it so we can let users customise it some day.
<nckx>(service gnome-service-type (gnome-configuration (packages (delete … %gnome-desktop-packages …)))) ; you get the idea.
<raghav-gururajan>nckx Hmm. Would I be able to make a service use a package-list instead of package-name?
<janneke>joshuaBPMan: i'm having some sort of trouble reconfiguring to current master; not certain it's the kernel yet
<HappyEnt>joshuaBPMan: thats at least the first commit where it breaks for me. For some reason some kernel modules are not loaded anymore, namely i915, iwlwifi and I think some audio related kernel modules
<HappyEnt>joshuaBPMan: Adding i915 to the initrd modules kinda fixes gdm failing, but audio and wifi modules are still not loaded
<joshuaBPMan>HappyEnt: oh geez. Ok, that's kind of a massive bug. hahaha.
<bavier1>joshuaBPMan, HappyEnt: The 5.4-gnu release notes say "Adjusted deblobbing of ... i915 ..."
<joshuaBPMan>HappyEnt: now that does make sense when you say that kernel modules are not loading. I thought my linux box was booting pretty quickly. I could not start anything, and ifconfig failed to show my ethernet connection...