<civodul>that automatically sets JUPYTER_PATH <jackhill>lfam: oops, I overlooked that, but I definitely installed nss-certs. If I recall correctly both in my system profile and my user profile. <guixy>Got it working. I'm not sure how I missed JUPYTER_PATH all those times called env <lfam>Okay, I just wanted to make sure, jackhill <civodul>guixy: great that you got it working <lfam>jackhill: It sounds like a problem with not being able to find the certificates <jackhill>lfam: it is good to be sure :) Yeah, I think the certs aren't available inside the flatpak container (at least not in an expected place) <jackhill>some flatpak-ed applications, like firefox, ship their own trust roots I assume, but haven't fully investigated. <guixy>civodul: I have two old laptops I'm using as home servers. I want to let people in my household use them to learn python and scheme. It's also an exercise in writing guix services and thinking through security issues. <lfam>jackhill: It's highly likely that firefox includes its own certs. Firefox / Mozilla is *the* authority on certificates, and they actually create nss-certs as a byproduct of that <lfam>They lead the community that decides which certificate authorities can be trusted <jackhill>I was somewhat hoping that someone that pakages applications for flatpaks (e.g. the org.chromium.Chromium folks) would recognized what at gone wrong and then we could translate the solution to Guix, but I'm still not sure if it's a Guix-specific problem <civodul>guixy: oh i see, that's an interesting exercise <guixy>Is it worth sending my results as a patch? Most users probably would prefer to keep jupyter local. <rekado>guixy: yes, patches for a jupyter service sound useful. <guixy>It's nowhere near what I really want, but maybe others can help me get there. <rekado>guixy: often the hardest part is to get the ball rolling <rekado>I’ve often seen something simple and limited get expanded by others in the community <guixy>It installs all the desired notebooks to the system profile. I want them installed to a profile belonging to the account that runs the server. <guixy>Right now, I think that's gonna be very difficult with what we have. <leoprikler>xgqt[m]1: I think you're thinking into the direction of `guix environment`? <xgqt[m]1>leoprikler: maybe, reading about environment command rn since I didnt manage to find anything like I wanted. I thought `guix environment` was more like for containers <leoprikler>Guix environment can spawn containers, but it can also spawn just a simple subshell. <leoprikler>In particular, if you want an environment with all you need for developing Guix, but don't care about other environment stuffs, "guix environment guix" suffices. <xgqt[m]1>leoprikler: Is there a way to "save" this environment to share the way it is configured or whatnot? Or would I just create a shells cript <leoprikler>you can save the environment to a location by passing "-r" <leoprikler>if you want to port it over to another machine, you need guix pack instead <guixy>guix deploy doesn't recognize --dry-run <nij>leoprikler: thanks for reaching out. I install it but the issue didn't go away. <nij>I turned on my browser again from the terminal, and the error <nij>MediaEvent: {"error":"FFmpegDemuxer: no supported streams"} <nij>Which was fixed by packaging chromium for it to use older ffmpeg. <nij>I'm using qutebrowser. <leoprikler>okay, in that case installing gst plugins does nothing for you <derivates>Does everyone else experience a considerable delay to start LM when booting up? I always get a TTY prompt and after some time I wait for my LM (SLIM in my case) ? *gr0n likes qutebrowser a lot <nij>It does work on icecat (I have that plugins now). ***terpri__ is now known as terpri
<nij>gr0n high 5! right? BEst browser I'd say. <lfam>Qutebrowser is the same as chromium, so it should probably have the same fix <gr0n>nij: i sometimes go days without touching my mouse thanks to qutebrowser <nij>Same here. It's the best mouse-free browser I've experienced, gr0n. <nij>lfam: The error isn't exactly the same.. so I wonder. <lfam>Well, our Chromium package actually gets updated in a timely manner, whereas Qutebrowser / qtwebengine get updated along with Qt (so, maybe once a year) <lfam>So, it could be that it's still suffering this old bug <gr0n>i never notice these things because i use freetube for youtube and mpv for everything else, so qutebrowser never plays any media for me actually <bdju>are people talking about qutebrowser bugs? I haven't had sound in qutebrowser for months, and certain videos don't play. but I also do most stuff in mpv <nij>gr0n: never heard of freetube, but now i'm delighted <lfam>It would be great to have a bug report for this... <gr0n>nij: it's great, you connect it to an invidious instance and it can manage your subscriptions, etc <lfam>Anyways, I skimmed the relevant package definitions, and it seems like if Qutebrowser were to have mp4 support, it would come through ffmpeg <nij>gr0n: I'm interested in details. PM'd you :D <lfam>The other source of media support is gst-plugins-base, but that only includes a small selections of Xiph audio libraries <lfam>So, if ffmpeg isn't working, that's almost all media not working <pkill9>i think webengine needs proprietary codecs enabled <pkill9>i think the implementations are free <bdju>I run into some videos where the small embedded player doesn't work, but opening the video in a new tab works <nij>bdju: OH have you resolved that audio issue for qb? <pkill9>but they're possibly implementations of proprietary codecs, or something <pkill9>oh, then it's probably diffrerent issue <lfam>pkill9: They may be subject to patents, but that is something that we explicitly ignore <nij>I found that qb on guix system cannot invoke pulsemixer correctly. <nij>But if you launch other programs, such that pavucontrol or mpv, they invoke pulsemixer for qb, and voila you got sound. <bdju>getting deja vu here. I recall someone having me try some arcane series of steps with pulse stuff and it didn't work. plus I've got mpv and mpd using pulse fine <nij>I've lived with that fact for a week :D <pkill9>nij: could that be related to chromium not invoking pulseaudio correctly? <nij>Try closing your qb. Turn on pavucontrol. And turn on qb again. <pkill9>since qb uses webengine which is chromium embedded <lfam>Qtwebengine depends on pulseaudio, so it *could* be able to do the right thing, which is start pulseaudio on demand when necessary <nij>I dunno about chromium. But you can see it clearly by invoking qb from a terminal. <lfam>Any application that uses pulseaudio should start it on-demand <bdju>I'll humor you here but I'm pretty sure I really tried this <bdju>do I have to kill anything besides qb? <lfam>However, Qutebrowser is already far removed from Chromium, so who really knows <pkill9>i found in the past that chromium doesn't spawn pulse but grabs the audio device directly with alsa <pkill9>if pulseaudio isn't already running <bdju>well, I have music playing in mpd, mpv works fine too. so it's not all of pulse that's broken <lfam>pkill9: The ungoogled-chromium package? <pkill9>can't remember if it still does this <lfam>That's not supposed to happen :/ <lfam>It should start pulseaudio on demand <lfam>Guix applications are supposed to use pulseaudio <pkill9>i may have configured pulseaudio to keep running and not exit on idle, to workaround this issue <nij>I can file a bug report for audio/video issues for qb some time after work these days. <bdju>oooh I doo see some ALSA stuff in my term after launching QB <pkill9>that's why running pavucontrol may be 'fixing' qb not starting pulseaudio, if it's the same issue <pkill9>starting pavucontrol will spawn pulseaudio <lfam>We can retitle that bug appropriately <nij>lfam: including the video issue? <lfam>I'm certain it's the same root problem <nij>Why so? (I'm just curious.) <lfam>Like I said, audio and video support for Qutebrowser comes from ffmpeg, for the most part <lfam>And again, we can retitle that bug appropriately <pkill9>bdju: if it's the same problem as I've talked about, then put this in ~/.config/pulse/daemon.conf to prevent pulseaudio from exiting on idle: <lfam>And since ffmpeg broke for regular Chromium, we can expect it to have broken with all Chromium-derived programs <pkill9>i also used this for preventing my bluetooth headphones disconnecting after period of no audio <bdju>pkill9: if pulsemixer shows audio from other programs, is it the same problem? I'm *only* having qutebrowser problems <pkill9>i think it is the same problem yea <bdju>okay I'll give that a shot <pkill9>i'm not sure, it shouldn't be a problem to disable exit on idle anyways <nij>Interestingly, the audio bug went disappear when I'm trying to file it. <nij>But anyway, I will file the mp4 problem I got. <bdju>pkill9: I added that line to that file and killed pulse and it didn't seem to make a difference <bdju>also if it is using alsa, I probably have no sound because it's defaulting to the wrong soundcard... I use a USB soundcard primarily <pkill9>bdju: did you start pulse after killing it? <bdju>I had pavucontrol open when I killed it and then it starts up again on its own <pkill9>it just prevents pulse from exiting after a while, it doesn't fix the qutebrowser grabbing the audio device if pulse isn't running <pkill9>did you also restart qutebrowser? <bdju>yeah I closed qb, killed pulse, opened qb <bdju>with pavucontrol running and seeing it started again before I opened qb <bdju>which package contains alsamixer? <bdju>hmm alsa-utils probably if it's the same as arch <bdju>can't see to get sound out even after installing alsamixer and changing the soundcard <flatwhatson>has anyone else wished for submodule support in git-predicate? <lfam>File a bug and we can tag it "wishlist" <lfam>And to make it "best", in your submission, include an example of a problem it solves <nij>OOOH! I'm actually trying to set up arch on raspi for home surveillance, and found that guix might work! <nij>I'm a bit concerned though.. has anyone had experience for this? <flatwhatson>lfam: will do. briefly, git-predicate is useful for creating a local-file source for a package definition in a project's guix.scm (ie. building based on current source code checked out in the repository) <flatwhatson>but if your project uses submodules, those don't get included so you need to write a custom predicate around "git ls-files --recurse-submodules" <nij>pkill9: I'm new to home surveillance stuff before. Not sure which kinda packages I'd need to stream from a camera. <lfam>flatwhatson: That does sound like a missing feature! <lfam>The code probably dates to before we added support for Git submodules to git-fetch <raghavgururajan>lfam: Should one alter the commit message, while cherry-picking a commit from another branch? <lfam>I guess it depends on if it needs to be changed or not <lfam>Many times, I don't think it would need to be changed <raghavgururajan>I presumed the commit messages to be preserved while cherry-picking, to maintain the authenticity. But I doubt now, if it can apply to sign-off lines of commit messages. <lfam>Okay, first thing, "I wish you had given me the benefit of the doubt." <--- Yes <lfam>If something looks wrong, there's a better way to ask about it than what Mark wrote <lfam>I looked at the commit on core-updates <lfam>In Guix, we use of Signed-off-by to indicate that somebody who is not the author has pushed a patch on the author's behalf <lfam>Using `git show --format=full --show-signature f94cdc86f644984ca83164d40b17e7eed6e22091`, the log shows that the commit was signed by Leo Le Bouter, but "committed" by you <lfam>Anyways, it makes sense that Signed-off-by would be used <lfam>I think that what Mark is concerned about is that the commit removes the security fixes, but it's not clear that they should be removed <lfam>And less importantly, that the commit's title doesn't mention that <raghavgururajan>Yeah, that's why I didn't think of removing the sign-off line because the cherry-pick preserves the digital signature of original commit. <lfam>I have to go eat dinner but I'll be back later <raghavgururajan>IIRC, we updated package to latest version and guix lint didn't show any more CVEs. Also, I think the change was added as part of the cosmetic change commit, to cleanly apply succeeding patches. <raghavgururajan>Yeah, the commit title didn't mention the change but the commit message did. <guixy>Been working for the past day on a jupyter service. It seems fine for now as long as you don't need SSL encryption. I'll test it tomorrow to make sure it's stable. Expect patches soon. <guixy>If anyone wants to work on making it more secure outside localhost or a direct ethernet connection, I'll clean the code up and send it to them on request. <raghavgururajan>jackhill: You mean for cairo? I am still looking into it. I meant the update for glib. <jackhill>raghavgururajan: yeah, I was looking at the cairo one <raghavgururajan>> I wonder if this patch was made before the graft and something went wrong when merging them together? <rhou[m]><leoprikler "rhou: what does "get it to work "> I just imagined I install `guix install emacs emacs-magit` and I can open emacs and call `C-x g` to call magit in emacs <pocketroid>Greetings programs. Any of ya'll sushi connoisseurs? <wonko7>So I've got xscreensaver in a user profile <wonko7>but it's not installed in /run/setuid-programs <wonko7>does it have to be installed in a specific way for that? <brendyyn>wonko7: there is a setuid-program-service. maybe that needs to be used <rekado_>wonko7: if you want a program to appear in /run/setuid-programs you need to declare that in the operating-system configuration. <rekado_>there’s a setuid-programs field in the configuration <rekado_>it determines the contents of that directory <wonko7>ok, I'll go add it in config.scm somewhere, thanks <terpri>jackhill, ty for digging up that bug report (can't remember if i replied) <terpri>gnutls was changed to disable p11-kit integration recently (b/c broken on one platform) but the guix upgrade breaks if i undo that <terpri>so i'll note that on debbugs tomorrow <terpri>(i don't really know what p11-kit does exactly, but it has something to do with flatpak's host->app tls integration) <rekado_>raghavgururajan: I’m sorry this bully keeps popping in here to insult you :-/ ***nckx is now known as raghavgururajan9
<sneek>raghavgururajan9, you have 1 message! ***raghavgururajan9 is now known as nckx
<rekado_>xwx: ideally these commits would be squashed, but I can do that for you <rekado_>xwx: give me a few minutes (I’m building something else right now) and I’ll apply your patches. <efraim>new set of 32-bit PPC patches sent! ***rekado_ is now known as rekado
<rekado>bah, I’m still trying to build irods. The fact that it can only be built with clang means that I need to rebuild a whole bunch of C++ packages because clang and gcc have no compatible ABI. <cTeX>Hello, from Emacs ERC. :) <civodul>rekado: it can only be built with Clang? <civodul>not even GCC + libc++ (instead of libstdc++)? <cTeX>If I have issues with a foreign-distro installation of Guix, should I try the distribution's package of it, if available? <cTeX>I wasn't able to get Guix working correctly on Fedora 33. <cTeX>It appears that the daemon or service is not run, even after enabling and starting the service manually; when I ran `guix pull` or ...`install [emacs]` it would complain that a service needs to be available. <cTeX>I can't stay logged, though; I have an exam early Friday morning, and I am expecting an interviewer to call me in the morning. I'll check the channel logs for a reply some time tomorrow. Have a good night! <rekado>civodul: no, there are many errors when building with GCC, since GCC is a bit stricter about certain things (like order of initialization). There’s a long, but outdated patch set to make it build with GCC. <rekado>upstream is not interested in making it work with GCC, so the patch never got merged. <rekado>cTeX: could be that the daemon is prevented from doing work by SELinux <rekado>cTeX: you could either set SELinux to permissive mode or help us figure out what needs to change in our guix-daemon policy for SELinux. <civodul>rekado: and there's no way to get around it with -std=c++11 or whatever? <brendyyn>civodul: Thanks for reviewing the wrap program patches 🎉 <brendyyn>Do you mean you just applied it to your own core-updates to build your own system for testing before pushing? <civodul>brendyyn: yes, i'm testing this and other patches on core-updates to make sure nothing obvious broke <civodul>i'll push within a couple of hours i guess? <rekado>civodul: it uses c++17 already. I haven’t been able to get it to build with GCC. <brendyyn>civodul: I think the change of wrapper? to wrapped-program? will break python-build-system <civodul>brendyyn: though your patch does change python-build-system, right? <rekado>civodul: but I’ll try again with libc++ and GCC <civodul>brendyyn: yeah you addressed it already, we should be fine :-) <brendyyn>Did you test in a repl that the code wraps programs right? <civodul>there's just the extra error handling <efraim>where is %strict-tokenizer? from? I'm missing some library while building on core-updates <civodul>efraim: that's guile-lib's (htmlprag) module <leoprikler>rhou[m]: that is indeed possible, once you've reloaded your shell variables <leoprikler>the first use of emacs creates a new search path for EMACSLOADPATH, which has hitherto not been evaluated in your system <leoprikler>subsequent installations of emacs packages will work as you described <efraim>civodul: looks like it's in 0.2.7 but not in 0.2.6.1 <efraim>my powerpc box has 0.2.6.1 from debian <civodul>ah so you can't build (guix import go), right? <civodul>we should just not refer to it from the top level <efraim>i commented it out for now locally <leoprikler>Btw. speaking about Emacs, can someone look at 47661v2? Ideally, I want all of the Guix+Emacs users to shout at me for what nonsense I've done and fix it. <rhou[m]><leoprikler "rhou: that is indeed possible, o"> thanks will try to reload shell variables, you say EMACSLOADPATH should be present? <leoprikler>In particular, source ~/.guix-profile/etc/profile <leoprikler>guix outputs a somewhat cryptic message, that people tend to ignore, whenever a package adds or changes a search-path <civodul>leoprikler: isn't "cryptic" exaggerated? :-) <leoprikler>People, who know about shell variables might understand it, but I have family members using Guix, who know next to nothing about them. <yoctocell>leoprikler: I am trying the Emacs patches and rebuilding all my Emacs packages. Hopefully nothing will break :) <civodul>roughly, the "module" command is actually a shell function, so when you do "module load", it modifies environment variables of the running shell <leoprikler>but tbh I still favour Guix' design, as it's more functional <brendyyn>tbh i never figured out how to download and apply lots of patches so ive never tested any long patch series before <brendyyn>normally id just use the web interface to download one at a time <brendyyn>i just tried the magit invocation C-u M-x debbugs-gnu RET RET guix-patches n y, and then ran debbugs-gnu-apply-patch on a thread and got all sorts of errors, 3 emacs windows opening, and a bunch of unstaged changes applied to the repo <civodul>i just pipe the thing to "git am -s" from Gnus <brendyyn>i thought i was applying to emacs' repo as if i was hacking emacs its self <brendyyn>hmm ok i was thinking again i might try email in emacs again. is been a few years to recover from the last time i tried <civodul>piping from Gnus is okay for up to 10 patches <civodul>yoctocell: public-inbox means it can be cloned, right? <yoctocell>yeah, it's just a git repo which you can mirror <yoctocell>I "subscribe" to lists with public-inbox, it will download the whole archive for me <rekado>brendyyn: issues.guix.gnu.org has a /patch-set endpoint to let you download the whole patch series <brendyyn>rekado: how would i use that for example to get the v2 set for 47661 <mekeor[m]>is there a ticket for adding kde-plasma to guix? i couldn't find it in the issue-tracker… <rekado>brendyyn: for links on issue pages we use /issue/ <brendyyn>i always just put the number straight after the domain <rekado>brendyyn: yes, that’s how you get to the issue page <rekado>but on that page we use /issue/ (you’ll see that when you hover over any of the download links) <brendyyn>with just /patch-set/, it inserts #f into the name. *rekado can’t parse that sentence <brendyyn>it downloads a file called 47661-patch-set-#f.mbox <rekado>you aren’t actually supposed to construct the URL by yourself <rekado>I wanted to offer a link once we agree that this is a useful feature and that it actually works most of the time. <rekado>it’s pretty lonely to hack on that thing <civodul>rekado: we've all been selfishly/happily benefiting for your work on mumi <civodul>it's all pleasantly full of parens so we have no excuse not to contribute back <brendyyn>I'm trying to look for what procedure would allow for #f to become a string <civodul>yoctocell: what i meant is that you need to return "a thing" that creates a "bin" directory <civodul>and that puts your wrapper inside it <yoctocell>civodul: so would I do (computed-file "startx-xdg" GEXPS)? <brendyyn>mekeor[m]: I don't think it has but there is some talk on guix-devel. have a look there too <meo>I am impressed, guix just saved the day <nij>Hello! How do I check my sshd status on guix system? On arch it's just `sudo systemctl status sshd`. <nij>Ah I see.. I missed sudo. <nij>It only gives a minimal amount of information, comparing to `sudo systemctl status sshd` <nij>Anyway to let it elaborate? <meo>brendyyn: i have an aging box on which some stuff runs for other people and I didnt want to upgrade the debian distro <meo>i wanted emacs 27 & guile 3 on it <meo>started looking for deb builds and then "wait I can just install guix" <nij>Hmm, tried `sudo herd detailed-status ssh-daemon`.. but Error "herd: service 'ssh-daemon' does not have an action 'detailed-status'" <brendyyn>meo: i think shepherd isnt quite as fancy as systemd in that regard <nij>Hmmm after trying.. I think I figure that port 22 is indeed open on my guix system. However, when trying to ssh from another computer, my guix system seemed to have refused. <meo>brendyyn: I have views on systemd that no one wants to hear, so I guess it doesn't matter <nij>namely, running `ssh -p 22 nij@192.168.0.22` on my arch machine, I got <nij>"ssh:connect to host .. port 22: Connection refused" <nij>On arch I'd just go on and edit some ssh config file. But I bet it's different on Guix. <meo>nij: ss -ltn|grep :22 <meo>if that shows nothing, it means ssh isn't running/listening <nij>LISTEN 0 128 0.0.0.0:2222 0.0.0.0:* <nij>LISTEN 0 4096 *:22000 *:* <nij>LISTEN 0 128 [::]:2222 [::]:* <nij>What does this mean? (I seriously have to start learning some basics networking.) <meo>add -p to ss, as in ss -ltnp <meo>it'll tell you which process listens on those ports <nij>Hope it's not multiline posting.. someone stop me if it is.. <meo>this tells you how to configure ssh in a guix system <meo>well none of those are ssh, or on ssh ports <meo>no, /etc/services just gives names to ports <nij>I do have openssh-service in my config.scm (reconfigured, rebooted) <nij>withtout any customization. The manual says it's defaulted to port 22. <meo>so shepherd fails to start it? <nij>I can connect to my arch machine from my guix machine.. <meo>or maybe its firewalled <meo>ah no, nvm firewalled, derp <meo>then let's see what it's listening on: ss -ltp|grep ssh <meo>actually do that in sudo <nij>Wait actually let me reboot again. <nij>Oh it works! Sorry for the waste of time.. <nij>I'm too confused with networking and couldn't pin the details. <nij>Thanks meo for your patience :) <pkill9>ability to have guix reconfigure not update grub, have a static point to system <pkill9>so that there would be no point at which reconfigure could corrupt system <pkill9>downside is not being able to rollback to every system generation <pkill9>although there could be workaround to that mabye <iyzsong>pkill9: systemd-boot had implement a bootloader spec, and fedora have a patched grub for the spec, which will allow it <rekado>pkill9: you can already pass --no-bootloader <nckx>I *still* only available as a third-party patch? Is that for ideological reasons? <pkill9>rekado: does grub get updated atomically? <iyzsong>nckx: i don't know, and search blscfg in grub-devel returns nothing, maybe it's not submited... ***penguwin7 is now known as penguwin
<nckx>It's over 5 years old, but who knows. <apteryx>civodul: this derivation fail (during the test suite) on the emulated QEMU: /gnu/store/10g6s5fa6x229dqqnva4rpmywlc2ixx6-coreutils-8.32.drv, on the version-1.3.0 branch <pkill9>by update i mean the configuration <apteryx>*fails; via QEMU emulation*; good morning :-) <roptat>apteryx, any estimate for the release? anything I can help with? <apteryx>What is slowing it down at this point is 1) we do not have armhf-linux cuirass workers producing substitutes (and QEMU emulation is not always viable -- causes false positive failures) -- that's being worked on by Mathieu and 2) same for powerpc64le <apteryx>roptat: we'll also have to expound that WIP commit at the top of the version-1.3.0, although this can wait after RC1 is out <civodul>apteryx: you're offloading to the OSUOSL machine? <civodul>apteryx: "GUIX_DAEMON_SOCKET=ssh://guix-power9 guix build /gnu/store/10g6s5fa6x229dqqnva4rpmywlc2ixx6-coreutils-8.32.drv" works <nckx>Maybe apteryx means that it's not reachable from berlin yet. <civodul>nckx, apteryx: i've set up an SSH tunnel on berlin so we can talk to p9 from there <civodul>now we need to register its signing ke <nckx>Thanks civodul. A firewall request is pending (the SSH tunnels have proved fragile in the past) but it's a good stop-gap. <roptat>I suppose we used n-par-for-each to speed it up a bit, but translate-texi or po4a might not be safe to run in parallel <roptat>"Limit thread creation by 'n-par-for-each'. Going beyond can lead libgc 8.0.4 to abort with: mmap(PROT_NONE) failed" so we already had that issue and were limiting the number of threads anyway <civodul>apteryx: i've reconfigure berlin and it's now retrieving binaries from p9 via offloading <apteryx>civodul: I'm still cut from Berlin so I can't try myself :-/ <apteryx>by the way, sorry for repeating the question, but I still don't understand the firewall requirement thing; what is it about? Can't we have that OSUOSL reach berlin via the already opened wireguard port? <civodul>apteryx: the Wireguard thing may work, but i'm not familiar with it <civodul>so i did what i know: setting up a quick'n'dirty SSH tunnel in the meantime <nckx>apteryx: By the time I'd gathered enough information to set up wg, Ricardo had already requested the firewall exception. <nckx>I'm still a fan of as few layers as possible. wg is great for home-hosted build machines that regularly change IP. <nckx>civodul: It's our weakness. <apteryx>civodul: wg is refreshingly simple (very similar to SSH), and it has a keepalive toggle (supported in our wireguard-peer-configuration) that allows machines behind NAT to keep being reachable. <apteryx>FYI Mathieu has also explained the process well in doc/cuirass.org (guix-maintenance repo) <morgansmith>When does string freeze end? When we launch the new version? <apteryx>morgansmith: it's already ended on master; the release work is happening on the version-1.3.0 branch <apteryx>if everything builds fine with the powerpc and armhf offload machines connected to Berlin, a first RC should be available soon <morgansmith>offload machines? what are those? Do we have powerpc hardware in the CI now? <apteryx>there's a PowerPC VM graciously provided by OSUOSL, yes <apteryx>powerpc64le to be exact (the new architecture supported for the upcoming 1.3.0 release) <morgansmith>supported as in forgein distro support or like full guix system support? <morgansmith>powerpc + guix is going to be awesome! Does any other distro have a bootstrap seed as small as ours? If not then powerpc + guix would be the most auditable system available right? <meo>there's autossh for maintaining persistent ssh tunnels, idk if that helps, I used it successfully <apteryx>At least judging from the Makefile.am, not sure what the blockers are for adding it to the current "GUIX_SYSTEM_SUPPORTED_SYSTEMS ?= x86_64-linux i686-linux" variable; perhaps someone more in the know (lle-bout) can comment <boombim>hey guys. how can I use fonts which I installed with `guix` on debian system? <boombim>I mean I use guix as package manager on debian <morgansmith>There's a section in the manual dedicated to helping you with X11 fonts on a foreign distro <civodul>apteryx: yeah i should bite the bullet and learn how to use WG <morgansmith>boombim: 2.6.3 X11 Fonts. idk how I'm supposed to reference info pages. Hopefully that helps <frankD2>hey guys, what is the best way to configure emacs packages ? straight or guix ? <morgansmith>frankD2: guix installs the packages. Straight installs them in a different place. Straight is easier to use if you want to be on the bleeding edge. guix is better if you want stability and the ability to rollback version. I don't think either offer the ability to configure the package though. You can configure the packages in any way you want and it'll work regardless of if the packages are installed using straight or guix <frankD2>@morgansmith i'm having trouble trying to get doom-emacs magit-forge working, emacs couldn't fine sqlite3 binary, even after (setq sql-sqlite-program ***), Any idea ? <morgansmith>frankD2: Oh ya. Ok for guix system then installing packages using guix is superior. For the guix packages people package all the dependencies with it and set the paths right. For emacs packages without dependencies they're the same :P <frankD2>morgansmith: jgart[m] great !!! thanks will try to wrap my head around all of this wholesomeness <tissevert>I have a question about coding style inpackage definitions: looking at package definitions, I've seen the `(inputs …) «thing» (what type is that thing ? I haven't got a clue) use the comma as separator between keys and values like this : ("key" ,value) <tissevert>it looks like there's a good reason to write it like that related to fundamental scheme stuff I don't know <abcdw>jgart[m]: Oh, the invidious is pretty cool, thank you for pointing it out. <tissevert>what is this reason ? is it simply an arbitrary esthetic choice ? <morgansmith>tissevert: The quasiquote prevents evaluation of things contained within. The comma re-enables evaluation. so `("package" ,package) expands to a list with the first item being a string and the second being the actual package object obtained from the evaluation of "package" <roptat>tissevert, if you wrote `("package" package) instead, you'd get a list whose first element is the string "package" and the second is a symbol package (not evaluated, it's somewhat similar to an atom in prolog if you know that) <morgansmith>tissevert: Reading a bit of the guile manual or the rsr6 standard might be helpful. There is also a guile irc you can ask questions on too (but we're happy to answer questions here as well :)) <roptat>the comma (,) is called "unquote", and it works inside a quasi-quote (`), but not inside a quote (') <abcdw>frankD2: jgart[m]: The approach for managing emacs config with guix you mentioned is a little hacky. We recently finished home-emacs-service-type for `guix home`, this solution should be much cleaner, I'll make better examples in a few weeks. And maybe will write more details to guix cookbook or will make a stream on the topic. <morgansmith>tissevert: It's probably important to note that everything in scheme is a list and we don't use any seperators in the lists except whitespace. That's why we are able to repurpose comma to do a different thing <roptat>tissevert, there's also "unquote-splicing" (,@) which is the same as the quote, but removes one level of parenthesis (it can put more than one element at the current position) <tissevert>roptat: I don't know prolog but I thought there were atoms, isn't that what quote does in front of a string ? 'foo <roptat>`("package" package) is the same as (list "package" 'package) <tissevert>wait, I thought list was the same as prefixing with a quote, it was a quasi-quote ? <roptat>but `("package" ,package) is (list "package" package) which evaluates to something like (list "package" (package (name ...) ...)) <roptat>list builds a list, but it evaluates all its arguments <roptat>the quote and quasi-quote block evaluation and create a list <tissevert>yeah, but I thought you could write '() for the empty list instead of (list) <roptat>' and ` are the same, but you can unquote `, whereas you can't unquote ' <tissevert>morgansmith: ohhh so yes of course in that case they'de be equivalent <rekado>finished building irods. But it’s deeply unsatisfying to have all these clang-6-built library variants. <tissevert>«you can't unquote '» : wait, that means a list declared with '(…) can only contain immediate values (strings ? anything else ? ints maybe ?) and symbols ? at least no variables <morgansmith>when building emacs packages, do you always set the elisp dependencies as propagated inputs? <dongcarl>We likely need to skip a coreutils inotify test for v1.3.0: #47935. I've reported the underlying bug upstream and will keep track of it. <morgansmith>tissevert: You can later evaluate things in the list because you still have the data. I'm not quite sure of the syntax but I think something like this is valid (eval '(display "Hello World!")). The quote returns the literal list with no evaluation but then we give that data to the eval function which runs it <morgansmith>tissevert: The point I'm trying to get at is you can put variable names in a quoted list if you really want <tissevert>yeah, but they'll be temporarily «inactivated» into symbols, won't they ? <morgansmith>the symbol -> function lookup itself is delayed until you pass the data to the eval function <jgart[m]><roptat "but `("package" ,package) is (li"> to give one more example: `("package" ,package) can also be written as `("package" (unquote package)) <jgart[m]>Everybody prefers , instead unquote for obvious reasons <morgansmith>maybe we should mention that ' and ` are actually just short forms. so like '(my "list") == (quote my "list"). The idea of scheme is that everything a list and there is no other syntax. but then we added some. but that syntax can be expanded to the original syntax of just lists. dunno if that made sense. I'm probably using the term list in a confusing way... <jgart[m]>does anybody know why guile requires a second argument to eval (interaction-environment)? <jgart[m]>does it have to do with the underlying VM somehow? <tissevert>morgansmith: I hope not : ) but at list it makes sense with a functional definition of lists: nil or cons a (list a) so I guess it must not be too confusing *tissevert hopes integers are still native and not peano's ^^ <jgart[m]>I tried implementing peano arithmetic in scheme a few months ago. I have to get back to that fun someday... <tissevert>«tried»: was it that hard ? suddenly, scheme reaches a whole new level of scary <morgansmith>There are booleans, numbers, characters, strings, symbols, pairs, lists, vectors, and procedures. Those are the atoms of scheme. <jgart[m]>I probably have some stuff offline that I haven't pushed to that repo <tissevert>I have to go but thanks for the food for thought <civodul>i have a theory, now i'm trying to actually reproduce it <jackhill>civodul: looks like there is more unexpected CVE data <civodul>jackhill: oh really? new from yesterday? <jackhill>oh, wait, maybe not. I think I've gotten confused with between my guix checkout (./pre-inst-env) and my pulled guix. I guess I need to update the checkout. oops, sorry! <apteryx>mothacehe: do you know if I add my own machine as a wireguard peer to berlin, would it allow me to SSH in? <leoprikler>okay, why tf do italian docs break 'make' again? <roptat>leoprikler, which error do you get? <roptat>maybe you need to run ./bootstrap again <leoprikler>slightly old master + one unrelated patch of mine <roptat>did make recreate the texi file? <roptat>don't know what's happening, sounds like the texi was out of date, but not updated by make? <leoprikler>there's a missing dependency on doc/contributing.$LANG.texi <roptat>ah, maybe the translation for contributing.texi is not right? <roptat>it should be contributing.it.texi <roptat>I had to fix that for a few languages before my translation updates <leoprikler>info_TEXINFOS and TRANSLATED_INFO do not match up <roptat>I see, I must have forgotten TRANSLATED_INFO <roptat>ideally, we would instead list all languages for the cookbook and the manual, and derive TRANSLATED_INFO and info_TEXINFOS from them <leoprikler>I don't think we're allowed to do such make trickery <leoprikler>but we should be allowed to use $(TRANSLATED_INFO) inside info_TEXINFOS, wdyt? <guixy>the guix-jupyter kernel is unresponsive. How can I debug? <roptat>leoprikler, no TRANSLATED_INFO has some more files than info_TEXINFOS <roptat>contributing* should be in TRANSLATED_INFO, but not info_TEXINFOS <leoprikler>then we could do translated_info_TEXINFOS at least <leoprikler>but we'd still need to remember the contributing.* <roptat>that's why I wanted to have only one place where we'd define languages <irfus>`guix pull` throws the following error <roptat>can you share the code you used for your channel? <roptat>irfus, I think there's no quote in the name of the channel, try (name flat) <mothacehe>apteryx: yes, just to connect to berlin from overdrive1, looks like it works. <mothacehe>civodul: oh good, I see you also sent an email about that, I'll try to have a look tomorrow <irfus>the example in the manual has a quote in the name, should be fixed <roptat>can you send a patch? or at least a bug report, so we don't forget? <roptat>irfus, oh actually it's fixed already <roptat>so it's fixed in current manual, but you were probably reading the manual for the latest version (1.2.0) instead of devel (master branch) <apteryx>mothacehe: It is OK to redeploy berlin to try the wireguard peer experiment? I guess I only need to restart the wireguard service thereafter? <apteryx>ah, good point; I don't. I'll send a patch to guix-sysadmin after I've done my homeworks <irfus>roptat: that's right. I hadn't realised there was a separate devel version of the manual online. ***Noisytoot_ is now known as Noisytoot
<guixy>What are the minimum texlive packages necessary for exporting a jupyter notebook to pdf via LaTeX? ***iyzsong- is now known as iyzsong
***MidAutumnHotaru7 is now known as MidAutumnHotaru
***drakonis1 is now known as drakonis
<apteryx>lfam: I was asking a collegue about a solution for ARM CI; they pointed to the new Apple M1 chip. Being massed produced, it is affordable and apparently there's an effort to reverse engineer the GPU drivers. A Mac mini costs less than 1k for the base model (8 cores/8 GiB ram/256 GB SSD). I'm not a big fan of Apple, but perhaps an option to consider. <lfam>Yes, perhaps. That and the Ampere Altra are by far the fastest ARM CPUs <lfam>I wonder if the M1 is cost-effective compared to the Altra, especially when you factor in the headache of the M1 being an inappropriate form-factor (laptop or "mini" PC) <gr0n>you could rent a cloud instance for ARM builds as well. again, not ideal, but it might serve the purpose until Morello boards go out and more chips get produced? <lfam>We really prefer not to use cloud services for the build farm <apteryx>is it friendly to free software? E.g., unlocked bootloader et al. <lfam>The Altra is only about $15K with the top SOC and otherwise kitted out appropriately for us <lfam>I don't really know. It's basically brand new and I doubt any other GNU-y projects have bought one *vagrantc goes with retro-unobtainium <apteryx>at this price range it'd better be; otherwise it makes more sense to invest in hardware better aligned with free software such as a POWER9 talos <lfam>I mean, the only thing that we *need* to work is either an ethernet NIC or a USB3 port <lfam>We can assume the storage and RAM interfaces will work <lfam>And at this price, we could have them boot a Guix ISO in their office and test things <lfam>We discussed it on guix-sysadmin and decided, for now, not to buy one <gr0n>lfam: understandable... :) <lfam>For one thing, "hosting" is a different question for this kind of machine compared to e.g. the Honeycombs <rekado>guixy: this is always hard to say, unfortunately. Our modular texlive packages are very small, so you may need quite a few of them, but the exact set depends on what packages are used. <lfam>The power cost is not enormous but it would be noticeable. And we'd also want to buy a UPS to protect <lfam>What we really could use is colocation <lfam>apteryx: Your point about the Talos is valid. But, on the other hand, there are millions of people with raspberry pis <lfam>So, it would be nice to serve them well <apteryx>The nice thing about the mac mini is I wouldn't mind having it collecting dust in a corner of my appartment; I'm sure others too (fanless and tiny) <apteryx>but I'm worried about not being able to control the software on it, we'd have to see <lfam>Has anyone benchmarked the M1 mac minis for our use case? Can it actually sustain full load without a fan? <lfam>(I should just google phoronix etc) <lfam>The M1 is so compelling that I'm confident the community will solve the software issues <lfam>It will be a few years yet before anyone ships a competitor <nckx>...so how do we get Guix 1.3.0 spammed to all of Freenode? <lfam>I thought you would be the expert on that <nckx>jess: Tell us the secret. <nckx>How we can get our releases wallopped to all. <jess>we're starting to do more wallops and want cool news from projects that use our network <lfam>Maybe we should time the release announcement for when there are lots of us on IRC *vagrantc thought this was some joke about hiring a botnet or something <jess>it's a bit trial and error at the moment but if you've got a recent release or piece of news you're excited about, feel free to message me about it <lfam>I didn't look at the Data Service yet, so maybe things are okay. But it seems a little too red to me <apteryx>lfam: I'm been testing 'make release' with it merged into version-1.3.0 (locally) <apteryx>It seems doable (I'm still getting build failures until I can get a hold of Berlin to retry things there with real hardware) <nckx>jess: I'd noticed the recent NASA ones, and they worked. Thanks, we might take you up on that... <apteryx>no, that's weird. I'll setup wireguard when I have a chance. <lfam>I guess we really need to get to the bottom of it <jess>i did get a bit of positive feedback on the nasa one <apteryx>I'm able to telnet on port 22, but ssh hangs with no response <apteryx>it's like if it was filtered by a firewall or something <lfam>Like I said, I checked the iptables logs and did not see your IP <lfam>It must be happening upstream, maybe at the datacenter level <lfam>Did you talk to the MDC admins yet? <nckx>jess: Interesting, I wouldn't have assumed the reaction would have been positive, but am glad it was. <apteryx>lfam: no, I've just let guix-sysadmin know about it <jess>i think people like to hear nice little tidbits <lfam>Okay. I'm going to ping rekado in case "SSH hangs with no response" rings a bell <lfam>Or that should read, "SSH to berlin.gnu.org hangs with no response" <lfam>I'll get this right eventually <lfam>It's a wonder I can log in at all <lfam>I can also assist with a Wireguard tunnel through my own server if necessary <apteryx>Actually they probably already saw my email to guix-sysadmin, so I'm not sure what they can do more :-) <apteryx>perhaps no need to worry about it until I setup wireguard (I trust this will work, we did for 2 machines couple days ago and it was working fine) <lfam>Yeah, but even "dunno, that's weird!" is a response worth getting quickly <lfam>Do you have a date in mind for 1.3.0, apteryx? <vagrantc>just release it on April 18th with an appropriate UTC offset :) <nckx>jess: I agree, but well, this is IRC; trying something remotely new is always scary. I like the idea of more community news, especially if it's not just projects like Ubuntu that get to shine. I hope it works out. <nckx>That sounds like a (not so) subtle hint but really wasn't. <jess>freenode's done whimsical wallops in the past and they went ok, but yeah people aren't used to th em now <jess>i think it's a nice tool for getting better relationships with our communities <Guest75>is guix considered a non bloat distro/pkg mgr? <apteryx>Guest75: for the distro part, you're in charge, via your operating-system configuration. <apteryx>You can bloat it as much or as little as you like. <Guest75>oh, do you still think it is suitable to run on older hardware? <lfam>People do, but I think it's unsuitable <lfam>Guix is a build-from-source distro at heart, and old hardware tends to be slow <apteryx>Guest75: if you get an SSD, something such as a X200 is quite decent <lfam>When people complain about "bloat", GNU is usually their first target. In my opinion, "bloat" is features, and features are what it's all about <lfam>Yes, no matter what computer you use, you'll be happier using Guix with solid-state storage. Guix is extremely I/O intensive <vagrantc>guix definitely consumse more disk space than other more conventional distros <Rovanion>I made a stupid little documentation patch this december and forgot to mark it as a patch. Unsure if it still applies but if it does perhaps it can help someone in the future: https://issues.guix.gnu.org/45542 <Guest75>yeah, ur right. but idk what else to go with, especially because im trying to get a somewhat ok experience whilst using linux on my oldie laptop. can you guys help me come up with some solution? <lfam>vagrantc: Beyond space usage, Guix accesses I/O resources in some really unusual and intensive ways ***badpixel- is now known as badpixel
<lfam>Guest75: My advice for using Guix on an old laptop is to use an SSD and always use packages from the day before, rather than updating them immediately. That way, it's less likely that you'll have to build from source <lfam>Thanks for the pings Rovanion <lfam>These are on my todo list for the day <Guest75>it's an HDD. but im more of trying to play to see whats gonna be best for me in the meanwhile , before i upgrade <lfam>Alright. HDDs work fine! It's just that Guix is like a worst case for them <lfam>The software of the system will quickly become pathologically fragmented across the HDD <lfam>And software from Guix tends to make dozens of storage lookups at runtime... looking across the HDD <lfam>I recommend buying an SSD :) <lfam>If that's not an option, I would just try installing Guix on another distro and seeing if you like it <lfam>If you don't, then you still have the other distro <Dr8128>In that case, maybe use NixOS. Or does it have the same problem? <Guest75>well, it currently has lubuntu on it, do you think i should switch or could switch to anything else to gain some more performance boost? <lfam>Guest75: Lubuntu is probably close to the fastest OS you could use <lfam>Like I said, you can install Guix on top of lubuntu and try it out <lfam>You don't have to install the full Guix System <lfam>No, Guix can be installed as a standalone package manager on top of another distro <lfam>They won't interfere with each other significanly <lfam>Guix is the package manager, and Guix System is the full OS <lfam>For example, my primary workstation is Debian with Guix on top <Guest75>i see. in that case, thanks. so you dont think i will have any big performance boost if i go lower than lubuntu? <lfam>All the old-school distros will have roughly equal performance <Guest75>thanks for telling me :) upgrade time i guess <vagrantc>i need to split that into a separate bug report... <lfam>vagrantc: Yeah, that's one of the major pain points of Guix on another distro <vagrantc>i was so happy to enable that feature and have the package "just work" :) <lfam>My /usr/loca/bin has some shell scripts that unset those variables before launching programs <lfam>I don't really understand the issue. This works for me :) <vagrantc>building guix itself seems to at best make use of ~8 cores ... got a build with -j32 going and it never hits a load of higher than 8 <lfam>Yeah, I've also noticed that the parallelism is limited somehow <guixy>What package provides xelatex? <AleQu[m]>Hey folks, I have written and tested a new (and my first!) package definition. I'm trying to figure out what to do next, but I'm finding the manual 'Submitting patches' a bit unclear and wanted to check. It seems I need to: (a) clone the repository (which I'm assuming is <https://git.savannah.gnu.org/git/guix.git>), (b) insert my package definition in one of the bundles (let's say 'python-science.scm', though I'm not really <AleQu[m]>sure how to choose), (c) produce a patch with 'git format-patch', and (d) mail the patch to <guix-patches@gnu.org>. Is that enough? Did I miss something? <guixy>AleQu[m]: What does your package do? <guixy>Also it's good to run `guix lint` on the file you modified before you make a patch. And the format script. <apteryx>lfam: crazy. 'sudo herd restart networking' fixed my SSH network problem. I realized this was not MDC related after getting bit by the same problem with another server. <lfam>I wonder, had you changed any network-y stuff? <jgart[m]>Ale ニ Quã: guixy: If you'd like to turn off the cve linter you can issue say `guix lint -x cve package-name` :slight_smile: don't tell lle-bout I said to do that... oops <lfam>AleQu[m]: Ideally, you'd lint and build your package, which is described in the manual section Building From Git <lfam>If you don't do that, just mention it in the commit message of your patch file <apteryx>perhaps connected to my work VPN, which is usually on. <guixy>AleQu[m]: It sounds like the library you packaged is like python-igraph in gnu/packages/graph.scm or python-objgraph in gnu/packages/python-xyz.scm. You could put it in one of those files. The maintainers are not picky enough about where you put packages imho. <AleQu[m]>Thanks everyone, I'm taking notes. Oh, there's one more thing, I've written my definition accompanied by a tiny procedure that figures out the pythonpath to install to, to make it more readable. Does that go into the same file? Or should I undo the procedure and just incorporate it to the definition? <lfam>apteryx: I've had weird DNS issues in the past after turning wireguard on and off <apteryx>I haven't deployed any wireguard locally yet <lfam>AleQu[m]: Hm, that sounds unusual. It's not usually necessary to do that <lfam>The python-build-system usually handles everything <lfam>apteryx: Sure, but wireguard and other VPNs will both *do things* to DNS <AleQu[m]>It's a c++ library so it uses gnu-build-system <guixy>AleQu[m]: How does it figure out the right pythonpath? <lfam>AleQu[m]: It's a C++ library but does Python-y things? <guixy>If it's also a C++ library, I'd put it in gnu/packages/graph.scm <AleQu[m]>it's written in c++ but it's main interface is through python, but it can in principle be used directly with c++. <lfam>Maybe you can share it here now, or wait for review on the mailing lits <lfam>I can't help here now, but maybe somebody else can <lfam>It's possible you'll be asked to adjust this aspect of your package, but I can't say without knowing the details :) <jgart[m]>Ale ニ Quã: c++ libraries can also use cmake-build-system. I guess depending on how you think of it, almost every build-system currently uses gnu-build-system :slight_smile: <AleQu[m]>guixy: I get the version of the python input, then build a string '/lib/python[version-without-revison]/'site-packages'. <guixy>The installer doesn't do that itself? <guixy>I won't be able to review your code. I'll have to go soon. <AleQu[m]>The installer would install inside the python's output site-packages dir (in /gnu/store). I have to pass a parameter so it installs inside the package's output. <AleQu[m]>I've linted and built it, for now with '--load-path'. <apteryx>lfam: but it wasn't a dns problem because the host was resolved correctly <asdf-uiop>Hi! Is anyone else here using StumpWM on guix? I managed to get it to work, but I do not know how to get it to register the installed extensions, e.g. sbcl-stumpwm-cpu. <cTeX>After installing Guix on a foreign distro, installing glibc-locales, and creating my .bash_profile, I get this error: <cTeX>> bash: /home/btex/.config/guix/current/etc/profile/etc/profile: No such file or directory <cTeX>Note that before sourcing .bash_profile, I did attempt `guix pull`, but it failed stating, "guix pull: error: Git error: error inflating zlib stream". <cTeX>I then ran `guix package --search-paths -p "$HOME/.guix-profile"` before trying to source my .bash_profile, which reads as follows: <cTeX>[[ -f ~/.bashrc ]] && . ~/.bashrc <cTeX>export PATH="$HOME/.config/guix/current/bin:$PATH" <cTeX>export INFOPATH="$HOME/.config/guix/current/share/info:$INFOPATH" <cTeX>export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale <cTeX>GUIX_PROFILE="$HOME/.guix-profile" <cTeX>. "$GUIX_PROFILE/etc/profile" <cTeX>GUIX_PROFILE="$HOME/.config/guix/current/etc/profile" <cTeX>. "$GUIX_PROFILE/etc/profile" <cTeX>hash guix # Does this belong in my BASH Profile? <cTeX>Might that be why `. .bash_profile` was unsuccessful? <cTeX>I understand the process I followed is difficult to follow from the way I've communicated it, and I apologize for that and for this wall of text that I've submitted to the channel. I hoped to include enough information for it to be helpful, rather than only providing the error I recieved when sourcing my BASH Profile and saying, "this didn't work." :) Thanks for any help or suggestions, Guix! <bandali>[aside: for future reference, please use paste.debian.net instead of pasting multiple lines of text into irc :-)] <cbaines>your second message contains all the information necessary <cTeX>bandali: Thank-you, I'll keep that in mind. <cbaines>etc/profile shouldn't be repeated, so remove the etc/profile from where it's related to .config/guix/current <cTeX>bandali: Ah, I see that now. This was copied directly from the Info manual of Guix, so we've together identified something to patch. :) <cTeX>I'll also mention that I've experienced that error with `guix pull` in the system distribution of Guix, as well as on a foreign distro (Parabola). The second time that command is run it was successful, and it is presently "Computing [a] Guix derivation" for my current system. Is there something strange happening that might require a failure on the first run? A strange hidden state, perhaps? <cTeX>cbaines: I'll take a look at that commit; it might be that I was used v1.2.0-1 of the installer script and I haven't finished updating Guix yet, so my info manuals are outdated. <cTeX>cbaines: the error is in my third message to the channel; but here it is agian, "guix pull: error: Git error: error inflating zlib stream". <cbaines>hmm, I'm not familiar with that error, it might be useful to send the details to bug-guix@gnu.org ***kristianpaul is now known as krispaul
<cTeX>Okay, I'll do that soon. <jgart[m]>nckx: Sorry! I'm messaging across a matrix bridge. Now I understand Drew when he says "Also, their bridge is a major nuisance to IRC, which biases me against them. Please don't integrate your next chat app with IRC; just leave us alone, thanks." <jgart[m]>I think matrix needs an IEEE standard so to speak for their bridges <rekado>apteryx: perhaps your IP has been banned for too many authentication failures? We have some custom iptables rules in maintenance.git that could have that effect. <apteryx>rekado: sorry for the bother, there was something with my network; all I had to do to resolve it was 'sudo herd restart networking' (!) <AleQu[m]>jgart: well, it's not really an encoding issue, it's because we're both messaging from matrix so you mention me with my full matrix name, which doesn't correspond to my irc name because it contains spaces and the japanes character for number 2 (which may look like an encoding issue if you don't have a font to display it I'm guessing). Well, one could improve the bridge to convert the names inside mentions too, but well. I <AleQu[m]>personally think it works like a charm nowadays (it was a bit rough early on). <apteryx>I still don't get it, but it works, so that's that. <apteryx>nckx: the osuosl machine accessible on localhost port 2224 appears to be unreachable <apteryx>process 59198 acquired build slot '/var/guix/offload/localhost:2224/0'\nguix offload: error: failed to connect to 'localhost': Connection refused <guixy>Today I experienced yet another moment where a hacker's guide to guix would have made things so much easier. <guixy>I understand the source a little bit more now. But the newcomers with parenthephobia would give up if they realized they would have to go through the same experience. <apteryx>nckx: perhaps the tunnel has fallen for some reason. I'll restart it in screen. <zzappie>Hey guix! Anyone using marionette-eval here? Is there a way to get thrown excetption? I always get #f if things go wrong... <sneek>Welcome back zzappie, you have 1 message! <apteryx>nckx: ok I've re-established the tunnel with OSUOSL <zzappie>sneek later tal rlb, not useful at this point of time but hey, I didn't know about lokke <zzappie>sneek later tell rlb, not useful at this point of time but hey, I didn't know about lokke <jgart[m]><guixy "Today I experienced yet another "> guixy: Can you describe your moment? *raghavgururajan over-slept <mekeor>raghavgururajan: what time is it? :D <raghavgururajan>For some reason my Gajim highlights `raghavgururajan9` as a mention to my nick. xD <zzappie>conserning marionette-eval: catching exception worked with with-exception-handler with #:unwind? #t <derivates>Im getting a Scheme error when trying to replace (UUID "....) with (file-system-label "...") on my OS declaration. <derivates>I thought it was supposed to be similar? the error give is that its expecting a pair <derivates>Id post the error but Im on my phone and my PC is on a TTY right now <drakonis>try installing an irc package on your pc <drakonis>there is something else you're doing wrong, if that isnt working