<mbakke>Whoops, I forgot to ungraft jbig2dec. <nckx>lfam: Thanks for updating certbot. <lfam>nckx: My pleasure :) Sorry if you'd been waiting... <mbakke>This time let's freeze core-updates for reals :P <mbakke>nckx: Any last minute patches? :) ***ym_ is now known as ym
<aerth>go version ( outputs 1.10.3 ), but go build-system is 1.9.7, do i need to make a custom build-system? <aerth>how to specify the go version to use? <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 <tune>the guix version is over a month behind <civodul>tune: yeah i noticed it, we should update it <tune>I've never done anything like that before, just complaining as a user <grafoo>is there any need for another guix mirror? <grafoo>civodul: both code and derivations. <civodul>i'm not sure there's a real need for that right now <civodul>well, we have lots of mirrors of the code thanks to Git :-) ***snape` is now known as snape
<jas4711>civodul: thank you! i think i'll write this down on my list of things that is nice to fix eventually, and live with the unnecessary building etc meanwhile <grafoo>civodul: alright. feel free to ping me if there's any need in the future to build/serve derivations. we can spare about 100Mbit. <rekado>tune: would you like to give upgrading it a try? We can help you prepare a patch. <civodul>grafoo: note that if you want, you're welcome to run your own build farm with cuirass + 'guix publish' <grafoo>civodul: thx. i'll look into that. <tune>thanks for the offer, maybe in the future I can give it a try <wingo>is there a chromium package somewhere that builds with current guix? <wingo>i am so frustrated that i can't access the libre video meeting software we use at work with the libre browsers in guix! chromium is free software too and it works with jitsi <snape>We're waiting to a yes from mbakke <snape>we're waiting *from (I'm tired :p) *wingo glances meaningfully in mbakke 's direction <rekado>tune: the upgrade for youtube-dl has been merged. It’s just a “guix pull” away now :) <tune>awesome! thanks for letting me know <jlicht>my compliments to the folks who made the colorised output happen! I like it <rekado>jlicht: hah, spotted the one person who doesn’t use guix-build-log-minor-mode in an Emacs shell :) <jlicht>Emacs starts suffering from long-line-indigestion when I do ;-). <rekado>yeah, long lines are the Achilles heel of all fontified Emacs buffers. <jlicht>sssh, roptat, we'll be run out of the village if people find out we don't live in Emacs ;) <snape>I don't build in Emacs either, because of long lines. Worst bug ever :-) <civodul>that's terrible; i rebooted this morning because of that (i had tried to open the packages.json file that hpcguix-web produces) <civodul>rekado: i use guix-build-log-minor-mode :-), but i'm glad you pushed the colorized output patch! <mbakke>snape, wingo: I don't think the current Chromium patch meets FSDG standards (due to the tight Web Store integration). <mbakke>I will start working on version 69 shortly, and then try going "full ungoogled" and see if that helps. <wingo>i think it will be an important step to get it into guix <wingo>regarding "steering users toward unfree software", it's a bit of a spectrum; a web browser in and of itself might be seen as doing that, yet we don't require librejs to be enabled <wingo>so if removing the web store is on the roadmap, it could make sense to do that work once the package is in guix <wingo>just expressing an earnest desire to be able to use the free chromium browser :) <jlicht>wingo: You could always apply the patches as they are on a local checkout and install chromium. <wingo>i have done that in the past, they got out of date tho <wingo>and i think the build didn't finish in the end <mbakke>wingo: I'll throw up a channel for it, but you'll need a powerful (16G RAM) build machine. <ecbrown>is there a "tag" that can be used to denote that a particular package is known *not* to build on 32-bit, and so please don't be bucketed as a failure? <ecbrown>ah ok, thanks you i will look into this <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. <Gamayun>I tend to use appear.in for video chat. That doesn't have the man-in-the-middle prevention feature of jitsi though. <wingo>yeah lots of tradeoffs. work's sysadmins went for jitsi <wingo>which, cool. got to choose something :P <Gamayun>wingo: Jitsi does seem to work with the latest firefox. On arch at least. My guix laptop is across an ocean at the moment... <snape>Gamayun, wingo: we don't have Firefox on Guix ATM, unfortunately. <wingo>snape: right, the point was more about the cross product of libre web browsers vs libre video conferencing software; intersection with guix is a next step! <pkill9>civodul: what is the link to that snippet you posted that you put in ~/.config/guix/channels.scm to pull the latest guix commit that has substitutes available? <civodul>everybody will be looking for this snippet :-) <mbakke>nckx: I'm getting a hash mismatch for 'cloc'. <nckx>mbakke: Thanks. I'll take a look. <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>Also, what OS are you using? <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 <lfam>Anyways, that shouldn't matter for this <lfam>Also, when trying again, I would keep logs of what it's doing. `guix package -i glibc-locales 2>&1 | tee ~/guix-build-log` <crashcrash>Oh, ok, thank you! Maybe I try from console now and tell the result, ok? <ngz>hmmmm, is guix pull failing for you? <lfam>ngz: Their odroid xu-4 is freezing while trying to install glibc-locales <ngz>Sorry, I didn't mean to interfere with the current discussion. My question should have been "Is guix pull failing for someone else?" <ngz>At least, you don't get the locale error I have :) <lfam>I'm bisecting the pull failure <lfam>I just got substitutes for all of `guix pull` from a commit from yesterday :) First time! <ngz>I always build wine-staging from scratch =/ <lfam>I mean the components of Guix itself, not any of the packages <lfam>Just the things built by `guix pull` <g_bor3>janneke: I have seen the latest status report. It's great <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 <ngz>lfam: Great. I'm testing at once. <janneke>lfam: what i like a bit about gitlab, is that you can protect branches and force-push wip branches -- also a protection against mistakes <lfam>Like, it's configurable per branch? <ngz>lfam: Fixed, indeed. Thank you. <janneke>so you can protectt v* tags, and use test-v* tags to eh test :-) <janneke>you still have to be careful not fast-forwarding master with an commit that's less than great ;-) <g_bor3>lfam: istm this can be done with a hook. I have just looked around, but not sure how complicated it might get. I guess it might not worth the effort <g_bor3>And I am not sure that cam set it up on savannah either. <ngz>ooooohh a colored output... <ngz>It seems that the gory details of compilation are now hidden too <atw>hi g_bor, just stopping by <janneke>guile-final is building...updating wip-bootstrap now <civodul>ngz: it's hidden by 'guix package', but not 'guix build' IIRC <civodul>i'd say that if you've reached guile-final, probably everything is OK? <janneke>civodul: txn...i totally rewrote the wip-bootstrap branch in the hope it's now easier to test/review/merge <janneke>civodul: my biggest question (see latests pogress report mails) are about the `package-with-explicit-inputs' not seeming to work <janneke>i rewrote a handful of early bootstrap packages to use (arguments (#:implicit-inputs #f ...) instead <janneke>but haven't rewritten them all -- possibly `package-with-explicit-inputs' should be fixed -- or my head should be fixed :-) <janneke>but other than such "little" confusions, we're starting to be pretty OK :-) <janneke>civodul: the wip-bootstrap is now only 15 commits; 6 of those rewriting `package-with-explicit-inputs' <jonsger>oke. libreoffice update patch will come tomorrow. yet another rebuild <buenouanq>Will I be able to install GuixSD on the EOMA68 and/or the Librem5 is the real question? <pkill9>well it can be installed on ARM so I think it will be able to be installed on the EOMA68 cards from the crowdsupply <bavier`>buenouanq: we have some people monitoring the EOMA68 compatibility <civodul>janneke: 15 commits sounds much more reasonable, thank you :-) <janneke>civodul: yw! i hope most of the early commits that only prepare for Mes can easily be merged or fixed/rewritten <janneke>of course, the last two (adding all of Mes bootstrap) and grafting guix bootstrap onto that mes bootstrap ar pretty big patches now... ***Piece_Maker is now known as Acou_Bass