<jas4711>hi! i'm running guixsd on a machine that is intended for production use. during upgrades of it (guix pull + reconfigure), i wouldn't want it to start compiling things but only rely on prebuilt binaries. is it easy to configure the system for this mode of operation? i would expect it to be what people want for a production system
<tune>is youtube-dl getting updated soon? certain videos on youtube don't work with it right now, mainly music videos. I think I heard it was fixed in an update
<Gamayun>wingo: I always thought it was a bit of a shame that jitsi specifically set up their WebRTC for Chrome/-ium, since it seems Google have been using it to play their browser market share the same way Microsoft used to back in the day, instead of following standards.
<wingo>Gamayun: to be fair the standard did change a bit and i also don't know if it works with current firefox
<wingo>so it could be using a modern firefox is another valid fix
<wingo>happy to have a self-hostable free software video chat platform tho!
<Gamayun>Most other WebRTC based videoconferencing I've tried works the same, or better, in Firefox. But it's a while since I looked at it thoroughly.
<Gamayun>There's nextcloud for self-hosted part now. Though my server is much to anemic to be useful for that.
<crashcrash>Hello everyone! I have a problem using guix. My pc freezes while trying to install locales. The pc is odroid xu4 (xu3-lite, arm processor), OS is armbian. Maybe there's more info needed, please tell me.
<lfam>crashcrash: Hi! What command are you running that makes the computer freeze?
<lfam>Oh, sorry. I know that Armbian is a Debian derivative
<lfam>Can you also give some more details about how it "freezes"? Are you using the Linux console? Or a desktop environment?
<crashcrash>Hi, lfam! 1.So the command is "guix package -i glibc-locales".
<crashcrash>I use desktop environment. By freezes i mean, that i can't do anything except hard reset. Display locked, mouse locked and so on
<lfam>crashcrash: Hm, that's not good. What does it say before it stops responding?
<crashcrash>Actually, I can't remember. The case is that i can't copy it cause it was frozen. Maybe i can check some logs. Could you point some to me? Or I'll try installing once more and after that check logs.
<lfam>I wouldn't need to see the exact text. I'm just curious what it was doing. Like, was it downloading, compiling, installing?
<crashcrash>As I remember i can't see any error messages on the frozen screen. Maybe pc gets somewhat overloaded. CPU too busy or something like that
<lfam>Okay. Installing glibc-locales *shouldn't* require compilation or anything very expensive, if you have enabled substitutes. On the other hand, if the computer ran out of RAM during compilation and started swapping, it could appear to be frozen, although it would eventually finish and "unfreeze".
<crashcrash>An talking about OS, my armbian distro is based on ubuntu, not debian
<lfam>What I would do is try again, but from the Linux console (accessible with 'ctrl + alt + f2'). I would also do it in screen or tmux so I could watch `top` to watch if the computer is getting overloaded
<lfam>Oh, I didn't realize they switched to Ubuntu. I think it used to be based on Debian a few years ago
<janneke>i'm just about to push some minor fixes (probably a hard reset again)
<janneke>there's really some puzzles to be solved before we can really consider merging -- so any help *much* appreciated
<janneke>g_bor3: rekado has been looking at the hurd (cross-build) bootstrap and found (and fixed i believe) some problems
<janneke>not sure yet whether rekado and my problems are related...
<g_bor3>oh, nice. One thing I would be interested in is if there is anything missing for x86_64?
<janneke>g_bor3: not entirely sure what you're asking -- the Mes bootstrap is strictly x86 only atm; but using --system=i686-linux and/or -e '(begin (use-modules (guix packages) ...) (%current-system "i686-linux") ...' the x86 bootstrap can be built on x86_64
<janneke>there are some minor differences building on the i686-linux bootstrap natively on x86 or on x86_64; i think that has to with packages that still use `package-with-explicit-inputs' instead of (arguments (#:implicit-inputs #f ...
<janneke>i rewrote a couple of those but actually still wait for a clue what to do here
<g_bor3>nice, I did not know that. I guess I have seen this in the status report more architectures part...
<janneke>ah...right. on #bootstrappable, i heard of an effort that tries to bootstrap (for debian) all architectures from an iniial x86 bootstrap
<janneke>for a while that was my plan too, but i'm now working on a native x86_64 implementation of Mes
<janneke>that's still quite a bit of work, but once that's done we'll probably start looking at arm (or the hurd)
<janneke>so the 'more architectures' is probably on the 6months/year timescale
<g_bor3>ok, tomorrow I will try to find some time to have a look at wip-bootstrap.
<janneke>g_bor3: yay! (and if tomorrow some later day, that's just as yay too!)
<g_bor3>Anyway would there be a way to allow force pushing wip branches? Or does the current delete and repush workflow has some advantages over that?
<lfam>g_bor3: Force pushing is effectively the same as delete and repush. Not allowing forced pushes is basically a way to prevent expensive mistakes on Savannah
<janneke>yeah, i'm using :<delete> and push -- which feels pretty ugly (commit emails and such) -- but yeah, what lfam says
<lfam>ngz, joehillen: The problem you saw should be resolved by commit 875d0681768408997cda108457aaf10116da3732 (just pushed)
<janneke>i'm all for making silly mistakes more difficult -- i'm great at those :-/
<lfam>janneke, g_bor3: Force pushing is a common way that people try to "push" through Git problems they don't understand, so I think it's good for us to just avoid it