jaeger changed the topic of #crux to: CRUX 3.7 | Homepage: https://crux.nu/ | Ports: https://crux.nu/portdb/ https://crux.ninja/portdb/ | Logs: https://libera.irclog.whitequark.org/crux/
tilman has quit [Ping timeout: 250 seconds]
tilman has joined #crux
groovy3shoes has quit [Quit: Leaving]
ppetrov^ has joined #crux
braewoods_ has quit [Ping timeout: 240 seconds]
guido_rokepo has joined #crux
braewoods has joined #crux
braewoods has quit [Remote host closed the connection]
SiFuh has quit [Remote host closed the connection]
SiFuh has joined #crux
braewoods has joined #crux
ivandi has joined #crux
ivandi has quit [Client Quit]
ivandi has joined #crux
groovy2shoes has joined #crux
<cruxbot> [opt.git/3.7]: stunnel: update to 5.70
<cruxbot> [opt.git/3.7]: fakeroot: update to 1.32.1
<cruxbot> [contrib.git/3.7]: bash-language-server: 4.10.1 -> 4.10.2
<cruxbot> [contrib.git/3.7]: botan: 3.1.0 -> 3.1.1
<cruxbot> [contrib.git/3.7]: fcft: 3.1.5 -> 3.1.6
<cruxbot> [contrib.git/3.7]: foot-terminfo: 1.14.0 -> 1.15.0
<cruxbot> [contrib.git/3.7]: foot: 1.14.0 -> 1.15.0
<cruxbot> [contrib.git/3.7]: libmediainfo: 23.06 -> 23.07
<cruxbot> [contrib.git/3.7]: mediainfo: 23.06 -> 23.07
<cruxbot> [contrib.git/3.7]: mono: 6.12.0.199 -> 6.12.0.200
<cruxbot> [contrib.git/3.7]: p5-business-isbn-data: 20230707.001 -> 20230714.001
<cruxbot> [contrib.git/3.7]: p5-file-listing: 6.15 -> 6.16
<cruxbot> [contrib.git/3.7]: python3-click: 8.1.4 -> 8.1.5
<cruxbot> [contrib.git/3.7]: python3-frozenlist: 1.3.3 -> 1.4.0
<cruxbot> [contrib.git/3.7]: python3-gevent: 22.10.2 -> 23.7.0
<cruxbot> [contrib.git/3.7]: python3-unpaddedbase64: added missing build dependencies
<cruxbot> [contrib.git/3.7]: python3-matrix-nio: 0.20.2 -> 0.21.0
<cruxbot> [contrib.git/3.7]: python3-pastel: added missing build dependencies
<cruxbot> [contrib.git/3.7]: qownnotes: 23.7.1 -> 23.7.2
<cruxbot> [contrib.git/3.7]: spdlog: 1.11.0 -> 1.12.0
maledictium has quit [Quit: WeeChat 3.8]
guido_rokepo has quit [Quit: guido_rokepo]
<ppetrov^> hey guys, are the collections in portdb somehow sscreened for activity? I mean, I see kde4 there, which is for sure quite old and was probably tested on a few releases back
<cruxbot> [opt.git/3.7]: rust: 1.70.0 -> 1.71.0
<cruxbot> [core.git/3.7]: libnghttp2: 1.55.0 -> 1.55.1
<SiFuh> ppetrov^: kde4 is an Alan repo. Alan repos are usually quite messy. There is no activity screening that I am aware. Usually when a user doesn't want to manage a repo they just contact jaeger
<SiFuh> But for Alan's alan repo, he does update a bit. I don't know about the kde4 as I don't use it.
<ppetrov^> thanks SiFuh
<ppetrov^> why are alan's repos 'messy'?
<ppetrov^> i have taken a few ports from him and updated them to the latest
<ppetrov^> also cpan2crux, a utility that he wrote is what made me switch to CRUX couple of years ago :-P
<SiFuh> I poach some of his ports too. I just don't think he takes the time and effort to be an obsesively compulsive pedantic perfectionist :-P
<ppetrov^> and ye his repo is the largest
<SiFuh> Here you will see what I mean
<SiFuh> And here too
<ppetrov^> i see...
maledictium has joined #crux
<farkuhar> https://www.mizrahi.com.ve/crux/ports/ Heh, look at the port that was most recently updated (2022-12-24 13:36). I seem to recall this port being involved in the gnupg build errors a few days ago.
<farkuhar> just a weird coincidence, no real connection between Alan's updating schedule and the opt/gnupg port.
<jaeger> The official portdb hides repos that it can't access or scrape properly. The unofficial portdb adds a tag pointing out how many times it has failed and when the last successful sync happened. Other than that, no particular activity screening
<farkuhar> it's been a while since I've had reason to test Firefox WebRTC performance with any audio backend besides pulseaudio/pipewire, but I just got a successful mic check with the sndio backend instead.
<SiFuh> Cool
<farkuhar> just reporting for the benefit of OpenBSD fans who like to see their good ideas adopted in Linux.
<SiFuh> I like sndiod a lot. sndiod_flags="-f rsnd/0 -F rsnd/1 -r 43200 -b2160"
<ukky> Mic works with ALSA too in Firefox. Just needs some tweaks, depending if Firefox is pre-built binary, or compiled.
<farkuhar> ukky: it's been my experience that recent versions of Firefox will only give you a drop-down menu of audio devices with the pulseaudio backend. With ALSA and sndio, only the default device is accessible.
<ukky> I am using apulse, to emulate pulseaudio interface for Firefox, when only ALSA is actually available on the system.
<farkuhar> but maybe ALSA would get more equal treatment in Firefox if I resurrected the ancient version that shows up in Alan's repo (from the time before the ALSA backend was demoted to Tier-3 or unsupported)
<ukky> I don't think you can make Firefox to directly interface ALSA in any recent Firefox version. Firefox dropped direct ALSA support, as far as I know.
<farkuhar> ukky: ah yes, I remember using apulse for exactly that purpose. But after volunteering to maintain the contrib/firefox port, these days I have at my fingertips a build with native ALSA support.
<ukky> farkuhar: I think this is related to ALSA support being dropped in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1345661
<farkuhar> unfortunately the native ALSA support does not include the enumeration of devices, which is why I now plan to test whether sndiod environment variables AUDIORECDEVICE and AUDIOPLAYDEVICE are respected in WebRTC apps.
<farkuhar> I remember being so excited in October 2020 to learn that OpenBSD finally allowed those two environment variables to be set independently, which meant that I could use USB speakers for playback, and a USB webcam for the microphone.
<ukky> You can configure ALSA to do that via ~/.asoundrc, specifying default playback and recording devices
<farkuhar> Well in October 2020 my only computer was a laptop running OpenBSD, so I didn't exactly have ALSA to play with. I do remember letting the kernel recompile overnight, and rebooting the next day to enjoy separate devices for playback and recording.
<farkuhar> But what finally drove me away from OpenBSD was its poor support for my Wacom tablet. I couldn't share handwritten notes very easily while videoconferencing, unless I was willing to dedicate serious desk space for a high-res document camera. Since I already had a secondhand Wacom tablet from a colleague, I switched to the OS that supported it better.
braewoods_ has joined #crux
braewoods has quit [Read error: Connection reset by peer]
<ukky> Lack of HW support, or too much resource requirements, are probably the reasons why people switch from one OS to the other.
groovy2shoes has quit [Ping timeout: 258 seconds]
groovy2shoes has joined #crux
<farkuhar> Switching the OS might be overkill, depending on the situation. In the case of drawing tablets, the sensitivity to stylus movement can vary even within a single OS, just by switching the desktop environment or compositor.
<farkuhar> On OpenBSD in 2020 there wasn't really any freedom to migrate away from Xenocara (to Wayland, for example), and the available X desktop environments did not exhibit much difference in their support for the Wacom tablet.
<farkuhar> But these days on CRUX, I notice slight differences in the stylus sensitivity, depending on whether I'm running Xorg, sway, or another Wayland compositor. All of them still offer a much smoother experience than what I remember from my days with OpenBSD.
<ukky> It should be possible to find where stylus sensitivity is set. Then configure it according on runtime environment.
<cruxbot> [contrib.git/3.7]: cargo-c: 0.9.20 -> 0.9.21
<farkuhar> Even if the OpenBSD of 2020 had offered more flexibility in the choice of DE, I think the smoothness of tablet input would still be constrained at the kernel level. I don't recall when configuring the OpenBSD kernel back then whether it was possible to enable absolute positioning for specific input devices, which is what you often want in a drawing tablet.
<ukky> I am not familiar with *BSD. Maybe they are good some other purpose. I have heard it is good for netwoking.
<farkuhar> The contrast when switching to Linux was obvious, at least in my use case. No matter which DE I logged into, the tablet input was properly handled at the kernel level, resulting in smooth handwritten notes (not the pixellated stuff I was getting when OpenBSD defaulted to the driver for a generic pointing device).
<ukky> Some users settle for 'good enough', or 'seems working'. But it would be a shame for a developer who would create 'good enough' driver for a HW device. Maybe *BSD emulates your device?
<farkuhar> No idea about how the driver gets selected in *BSD. I doubt it's the udev rules that I'm familiar with. But after settling down with CRUX, these days I don't have any machines running *BSD, not even a VM. I haven't bothered to go back and see how the OpenBSD drivers have improved in the span of a few years.
braewoods_ has quit [Remote host closed the connection]
ppetrov^ has quit [Quit: Leaving]
<cruxbot> [core.git/3.7]: rhash: 1.4.3 -> 1.4.4
dani-77 has joined #crux
dani-77 has quit [Client Quit]
<cruxbot> [contrib.git/3.7]: python3-m2r: added patch to build against mistune0
<ocb> SiFuh: you're into ghidra iirc?
<SiFuh> No
<cruxbot> [core.git/3.7]: cmake: rebuilt for rhash 1.4.4
farkuhar has left #crux [#crux]
<cruxbot> [core.git/3.7]: nftables: 1.0.7 -> 1.0.8
tilman has quit [Ping timeout: 245 seconds]
tilman has joined #crux